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@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@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