From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ira W. Snyder Date: Fri, 10 Sep 2010 11:10:23 -0700 Subject: [U-Boot] 83xx fails to boot with moderately sized kernels In-Reply-To: <201009101329.48145.sr@denx.de> References: <20100909225241.GI3496@ovro.caltech.edu> <20100910111855.A392B136327@gemini.denx.de> <201009101329.48145.sr@denx.de> Message-ID: <20100910181022.GA18510@ovro.caltech.edu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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 > > > 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