[U-Boot] 83xx fails to boot with moderately sized kernels

[Ira W. Snyder]

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