On Fri, Apr 29, 2011 at 4:26 AM, Tony Lindgren <[email protected]> wrote: > * Tony Lindgren <[email protected]> [110427 07:41]: >> * Nicolas Pitre <[email protected]> [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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
