[PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage

[Grant Likely]

On Fri, Apr 29, 2011 at 4:26 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Tony Lindgren <tony at atomide.com> [110427 07:41]:
>> * Nicolas Pitre <nico at fluxnic.net> [110427 07:37]:
>> > On Wed, 27 Apr 2011, Tony Lindgren wrote:
>> > >
>> > > I guess the issue is that when setup_machine_fdt gets called we only
>> > > have minimal MMU mapping done.
>> >
>> > In head.S (the final kernel image one) there is a 1MB mapping
>> > established when r2 contains a valid ATAG/DTB pointer.  See commit
>> > 4d901c42 (you even ACK'd it).
>>
>> Yeah thanks was just looking at that too :) Need to debug further..
>
> OK figured this one out. Looks like we have an issue where kernel BSS
> can easily overlap the appended DT data. Then kernel __mmap_switched
> will clear the BSS and DT data.
>
> This happens for example with omap2plus_defconfig where we have:
>
> $ stat -c "%s" arch/arm/boot/Image
> 6405100
>
> $ size kernel/built-in.o
>   text    data     bss     dec     hex filename
>  660576  110852 5475500 6246928  5f5210 kernel/built-in.o
>
> If the compressed image is smaller than BSS, then we end up
> having DT data in the BSS area. In this case the compressed
> image is about 2.3 MB for LZMA.
>
> The uncompress code does not know about the kernel BSS,
> and does not necessarily relocate anything depending on the
> compressed image load address.
>
> So in which code do we want to relocate the DT data?
>
> We could do it based on estimated BSS size in uncompress code,
> or based on the real BSS size in __mmap_switched before BSS
> gets reset.

How about telling the wrapper what the final size will be by scraping
the __bss_end value out of System.map?

g.