linux-kernel - Re: [PATCH RFC 15/17] microblaze: Convert from _fdt_start to __dtb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Nov 2013 15:21:12 +0100
From:	Michal Simek <monstr@...str.eu>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	microblaze-uclinux@...e.uq.edu.au, devicetree@...r.kernel.org
Subject: Re: [PATCH RFC 15/17] microblaze: Convert from _fdt_start to __dtb_start

On 11/13/2013 03:02 PM, Geert Uytterhoeven wrote:
> On Wed, Nov 13, 2013 at 2:40 PM, Michal Simek <monstr@...str.eu> wrote:
>>>> QUESTION: The padding of the DTB is gone, is this OK?
>>>
>>> Removing this kernel padding should be fine. I can't remember
>>> why it was there from the beginning.
>>
>> I know why is this here. The reason is process how dtb is passed
>> to the kernel via command line. head.S code just copy that dtb to
>> the same location where compiled-in dts is expected and kernel
>> doesn't need to care about position of dtb because this copy is
>> done without MMU. And the full kernel is covered by 2 tlbs and
>> we don't need to use another TLB for dtb mapping.
>>
>> It means pad matters a lot. Because u-boot ITS format doesn't use
>> simpleImage target but the kernel need to have a space for copying
>> dtb to this kernel location.
>>
>> Let me think about if there is an easy way to handle dtbs
>> which are passed from bootloader.
> 
> You can add to asm-generic/sections.h:
> 
> #ifndef ARCH_DTB_PADDING
> #define ARCH_DTB_PADDING
> #endif
> 
> and change KERNEL_DTB() to:
> 
> #define KERNEL_DTB()                                                    \
>        STRUCT_ALIGN();                                                 \
>        VMLINUX_SYMBOL(__dtb_start) = .;                                \
>        *(.dtb.init.rodata)                                             \
>        ARCH_DTB_PADDING                                \
>        VMLINUX_SYMBOL(__dtb_end) = .;
> 
> Then microblaze can predefine ARCH_DTB_PADDING in its
> <asm/sections.h>.
> 
> Still, it will crash badly if the external DTB is larger than
> ARCH_DTB_PADDING.

yes but the question is if our bootflow is correct or not.
Because the problem is still with ARCH_DTB_PADDING value.
In past we have extended this padding from 16k to 32k.

We are setting up one tlb for early console and we can just do the same
for dtb and fix kernel for this cases. Then we don't need to waste
of memory for allocating space for dtb.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)