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

Timur Tabi timur at freescale.com
Fri Sep 10 07:19:45 EST 2010


Ira W. Snyder wrote:
> I have no idea how to determine this.
> 
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_bats function yet.

I just spoke to Kumar, and he said that the 8MB is just historical.  We ran
into the same exact problem that you ran into, except it was with a normal
kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back
and made the same change to 83xx boards.

So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all
83xx systems.  However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ <=
the actual amount of RAM in the system, so we need to make sure that
CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship
with only 8MB of RAM.  My guess is that no such board exists, but I will get
confirmation.

However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me:

/*
 * For booting Linux, the board info and command line data
 * have to be in the first 8 MB of memory, since this is
 * the maximum mapped by the Linux kernel during initialization.
 */

This same comment says 16MB on 85xx systems, so I don't think the statement
about "maximum mapped by the Linux kernel" is really true.  Maybe someone
else can shed some light on this.

> I think the MPC8349EA would be a 603 CPU, meaning that we could increase
> CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).

Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means.  I
was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of
the size of the mapping that U-Boot creates for the kernel.  When the kernel
initializes the MMU for its own purposes, does it limit anything to 16MB?  I
seriously doubt it.

> You'll see that your patch now relocated the FDT. It didn't cause any
> problems. I'll post to the thread on the U-Boot ML.

Yes, please.  I need someone to confirm that he tested my patch.

-- 
Timur Tabi
Linux kernel developer at Freescale



More information about the Linuxppc-dev mailing list