Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)

From: "Ira W. Snyder" <[email-masked]>
Date: Thu, 9 Sep 2010 13:31:42 -0700

On Thu, Sep 09, 2010 at 03:13:17PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That easily overruns the location where U-Boot puts the FDT. Is this a
> > U-Boot bug, meaning I should post this information on the U-Boot
> > mailing list?
> 
> Possibly.
> 
> I am under the impression that the memory in the boot block that contains
> the FDT is marked as "reserved" in the device tree, so that the kernel
> doesn't overwrite it.  However, that obviously isn't helpful if we haven't
> parsed the device tree yet.
> 
> What concerns me is this in U-Boot:
> 
> /*
>  * For booting Linux, the board info and command line data
>  * have to be in the first 16 MB of memory, since this is
>  * the maximum mapped by the Linux kernel during initialization.
>  */
> #define CONFIG_SYS_BOOTMAPSZ	(16 << 20)	/* Initial Memory map for Linux*/
> 
> If the 16MB mapping limit is true, then does this mean that the Linux's BSS
> is larger than the memory that is mapped?  If so, that means that Linux
> can't even access all of its BSS at this point.  Somehow, I doubt that.
> 
> Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ?  Combined with my
> always-relocate-fdt, I think this will force the FDT to be placed higher in
> memory.
> 

That did it!

I'm using include/configs/MPC8349EMDS.h. On that board,
CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
the kernel now boots.

I'll make a post to the U-Boot list asking if this should be boosted for
MPC8349EMDS (and others?). It is easy to build a kernel that overruns
this limit. Other than debugging options, my kernel is fairly minimal,
only a few drivers are built in.

I'm using your always-relocate-fdt patch. Your patch made no difference
to the FDT location. U-Boot with and without your patch both work fine,
as soon as I boosted CONFIG_SYS_BOOTMAPSZ to 16MB.

With your patch:
   Booting using the fdt blob at 0x226a278
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
   Loading Device Tree to 00ff8000, end 00fff78f ... OK

Without your patch:
   Booting using the fdt blob at 0x226a278
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
   Loading Device Tree to 00ff8000, end 00fff78f ... OK

Thanks,
Ira