[U-Boot] 83xx fails to boot with moderately sized kernels
Ira W. Snyder
iws at ovro.caltech.edu
Fri Sep 10 20:10:23 CEST 2010
On Fri, Sep 10, 2010 at 01:29:48PM +0200, Stefan Roese wrote:
> Hi Ira & Wolfgang,
>
> On Friday 10 September 2010 13:18:55 Wolfgang Denk wrote:
> > > Does anyone know the true maximum value for CONFIG_SYS_BOOTMAPSZ on Linux
> > > (if one even exists)?
> >
> > The CONFIG_SYS_BOOTMAPSZ thing is as old as U-Boot and PPCBoot
> > exists, i. e. well over a decade. IIRC there was such a limitation on
> > the then current 2.2.13 Linux kernels, at least on MPC8xx and PPC40x
> > systems, which is where all started from.
> >
> >
> > I am pretty sure that as long as nobody ran into any problems, nobody
> > looked into that code, so it was copied from architecture to
> > architecture without much thinking, if any.
>
> I looked at it a bit over a year ago and commited this change for the AMCC/APM
> eval boards:
>
> commit 6942efc2be1b90054fa4afa5cda7023469fe08b9
> Author: Stefan Roese <sr at denx.de>
> Date: Tue Jul 28 10:50:32 2009 +0200
>
> ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB for big kernels
>
> This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the
> initial TLB on 40x PPC's in the Linux kernel. With this change even bigger
> Linux kernels (> 8MB) can be booted.
>
> This patch also sets CONFIG_SYS_BOOTM_LEN to 16MB (default 8MB) to enable
> decompression of bigger images.
>
> Signed-off-by: Stefan Roese <sr at denx.de>
>
>
> So we have this 16MiB initial TLB restriction at least for PPC405 (not
> PPC440). I'm pretty sure that 83xx has no such tight restrictions.
>
I've just gone through both the 40x code (as a source for comparison)
and the 6xx code (generic 32-bit powerpc: 83xx, 85xx, others?).
arch/powerpc/kernel/setup_32.c's machine_init() function is the first
thing to access the device tree. The full MMU setup has not been done at
this point; the initial MMU configuration is used at this point. The
initial MMU configuration is done in arch/powerpc/kernel/head_32.S's
initial_bats() function. On 6xx, it creates a 256MB mapping:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
Inside U-Boot, common/image.c's boot_relocate_fdt() function uses
lmb_alloc_base() to allocate memory to hold the FDT for Linux. That
shouldn't return an invalid memory location. (It doesn't return a
pointer to unpopulated memory on a board.)
Based on that, I think it should be fine to increase
CONFIG_SYS_BOOTMAPSZ to 256MB on all 32-bit 6xx processors. This
includes 83xx and 85xx. Is 86xx included too (IIRC, it has 64bit modes)?
A boot test on my MPC8349EMDS confirms that it works:
Booting using the fdt blob at 0x2242d6c
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 0fe97000, end 0fe9e84f ... OK
[ 0.000000] Using MPC834x MDS machine description
[ 0.000000] Linux version 2.6.31.12-00018-g306aebe [output trimmed]
Would you prefer a patch only for the MPC8349EMDS, or should I try and
convert the other boards too? How should I know which boards are safe?
Grep for CONFIG_E300?
Thanks,
Ira
More information about the U-Boot
mailing list