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

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [110427 07:41]:
> * Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> [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.

Cheers,

Tony