sequoia: The final kernel image would overwrite the device tree

sequoia: The final kernel image would overwrite the device tree

[Geert Uytterhoeven]

	Hi Ben,

Current kernel (2.6.31-rc4) fails to boot on sequoia:

| ## Booting image at 00100000 ...
|    Image Name:   Linux-2.6.31-rc4-00003-g52c6890-
|    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
|    Data Size:    1680490 Bytes =  1.6 MB
|    Load Address: 00400000
|    Entry Point:  00400458
|    Verifying Checksum ... OK
|    Uncompressing Kernel Image ... OK
| CPU clock-frequency <- 0x27bc86a4 (667MHz)
| CPU timebase-frequency <- 0x27bc86a4 (667MHz)
| /plb: clock-frequency <- 9ef21a9 (167MHz)
| /plb/opb: clock-frequency <- 4f790d4 (83MHz)
| /plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
| /plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
| /plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
| /plb/opb/serial@ef600500: clock-frequency <- 42ecac (4MHz)
| /plb/opb/serial@ef600600: clock-frequency <- 42ecac (4MHz)
| Memory <- <0x0 0x0 0xffff000> (255MB)
| ethernet0: local-mac-address <- 00:10:ec:00:f1:df
| ethernet1: local-mac-address <- 00:10:ec:80:f1:df
| 
| zImage starting: loaded at 0x00400000 (sp: 0x0ff2ba18)
| Allocating 0x85e77c bytes for kernel ...
| The final kernel image would overwrite the device tree?

Git bisect told me the bad guy is:

| commit 5d38902c483881645ba16058cffaa478b81e5cfa
| Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| Date:   Wed Jun 17 17:43:59 2009 +0000
| 
|     powerpc: Add irqtrace support for 32-bit powerpc

However, disabling CONFIG_PROVE_LOCKING also fixes the problem.

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: sequoia: The final kernel image would overwrite the device tree

[Geert Uytterhoeven]

On Tue, 28 Jul 2009, Geert Uytterhoeven wrote:
> Current kernel (2.6.31-rc4) fails to boot on sequoia:
> 
> | ## Booting image at 00100000 ...
> |    Image Name:   Linux-2.6.31-rc4-00003-g52c6890-
> |    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
> |    Data Size:    1680490 Bytes =  1.6 MB
> |    Load Address: 00400000
> |    Entry Point:  00400458
> |    Verifying Checksum ... OK
> |    Uncompressing Kernel Image ... OK
> | CPU clock-frequency <- 0x27bc86a4 (667MHz)
> | CPU timebase-frequency <- 0x27bc86a4 (667MHz)
> | /plb: clock-frequency <- 9ef21a9 (167MHz)
> | /plb/opb: clock-frequency <- 4f790d4 (83MHz)
> | /plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
> | /plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
> | /plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
> | /plb/opb/serial@ef600500: clock-frequency <- 42ecac (4MHz)
> | /plb/opb/serial@ef600600: clock-frequency <- 42ecac (4MHz)
> | Memory <- <0x0 0x0 0xffff000> (255MB)
> | ethernet0: local-mac-address <- 00:10:ec:00:f1:df
> | ethernet1: local-mac-address <- 00:10:ec:80:f1:df
> | 
> | zImage starting: loaded at 0x00400000 (sp: 0x0ff2ba18)
> | Allocating 0x85e77c bytes for kernel ...
> | The final kernel image would overwrite the device tree?
> 
> Git bisect told me the bad guy is:
> 
> | commit 5d38902c483881645ba16058cffaa478b81e5cfa
> | Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> | Date:   Wed Jun 17 17:43:59 2009 +0000
> | 
> |     powerpc: Add irqtrace support for 32-bit powerpc
> 
> However, disabling CONFIG_PROVE_LOCKING also fixes the problem.

I did some more investigations.

If CONFIG_PROVE_LOCKING is not set:

| zImage starting: loaded at 0x00400000 (sp: 0x0ff2b670)
| Allocating 0x74a764 bytes for kernel ...
| platform_ops.vmlinux_alloc = 0x00000000
| _end = 0x78e000
| gunzipping (0x00000000 <- 0x0040e000:0x00781b34)...done 0x360460 bytes

and the rest of the kernel boots (note: it hangs later on with "BUG: spinlock
lockup on CPU#0, swapper/1, cf8b6908" with today's kernel, will look into
that later).

However, nm says _end = c074b000?


If CONFIG_PROVE_LOCKING=y:

| zImage starting: loaded at 0x00400000 (sp: 0x0ff2ba18)
| Allocating 0x85e784 bytes for kernel ...
| platform_ops.vmlinux_alloc = 0x00000000
| _end = 0x792000
| The final kernel image would overwrite the device tree?

and it reboots.

However, nm says _end = c085f000.

So in both cases _end is not correct in arch/powerpc/boot/main.c:prep_kernel()?
But depending on CONFIG_PROVE_LOCKING, the test for
((unsigned long)_end < ei.memsize) gives different results, and the kernel
boots or doesn't boot?

  
With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: sequoia: The final kernel image would overwrite the device tree

[Benjamin Herrenschmidt]

On Fri, 2009-08-07 at 17:48 +0200, Geert Uytterhoeven wrote:
> | Allocating 0x85e784 bytes for kernel ...
> | platform_ops.vmlinux_alloc = 0x00000000
> | _end = 0x792000
> | The final kernel image would overwrite the device tree?
> 
> and it reboots.
> 
> However, nm says _end = c085f000.
> 
> So in both cases _end is not correct in
> arch/powerpc/boot/main.c:prep_kernel()?
> But depending on CONFIG_PROVE_LOCKING, the test for
> ((unsigned long)_end < ei.memsize) gives different results, and the
> kernel
> boots or doesn't boot?
> 
Well, "Allocating 0x85e784" looks right...

My experience, however, with a Canyonlands board, is that uBoot has
a bug that makes it always allocate the device-tree below 8M and clash
with the kernel when it gets too big.

I think Stefan fixed that recently, you may need to rebuild your uboot,
I'll let him tell you the details about the fix.

Cheers,
Ben.

Re: sequoia: The final kernel image would overwrite the device tree

[Wolfgang Denk]

Dear Ben,

In message <1249678991.10143.1.camel@pasglop> you wrote:
> 
> My experience, however, with a Canyonlands board, is that uBoot has
> a bug that makes it always allocate the device-tree below 8M and clash
> with the kernel when it gets too big.
> 
> I think Stefan fixed that recently, you may need to rebuild your uboot,
> I'll let him tell you the details about the fix.

Right. These are the relevant commits; they went into mainline some
time ago:

commit 27dd5f8e1062684f1ba685760409d9b2ab6691bf
Author: Stefan Roese <sr@denx.de>
Date:   Tue Jul 28 10:56:03 2009 +0200

    ppc4xx: amcc: Move "kernel_addr_r" etc to higher locations (> 16MB)
    
    This patch moves the load addresses for kernel, fdt and ramdisk to higher
    addresses (>= 16MB). This enables booting of bigger kernel images (e.g.
    lockdep enabled).
    
    Signed-off-by: Stefan Roese <sr@denx.de>

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>


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every solution breeds new problems.

Re: sequoia: The final kernel image would overwrite the device tree

[Geert Uytterhoeven]

On Sat, 8 Aug 2009, Wolfgang Denk wrote:
> In message <1249678991.10143.1.camel@pasglop> you wrote:
> > My experience, however, with a Canyonlands board, is that uBoot has
> > a bug that makes it always allocate the device-tree below 8M and clash
> > with the kernel when it gets too big.
> > 
> > I think Stefan fixed that recently, you may need to rebuild your uboot,
> > I'll let him tell you the details about the fix.
> 
> Right. These are the relevant commits; they went into mainline some
> time ago:
> 
> commit 27dd5f8e1062684f1ba685760409d9b2ab6691bf
> Author: Stefan Roese <sr@denx.de>
> Date:   Tue Jul 28 10:56:03 2009 +0200
> 
>     ppc4xx: amcc: Move "kernel_addr_r" etc to higher locations (> 16MB)
>     
>     This patch moves the load addresses for kernel, fdt and ramdisk to higher
>     addresses (>= 16MB). This enables booting of bigger kernel images (e.g.
>     lockdep enabled).

Ah, thanks, that explains it.

I'll make sure my kernel images get smaller again ;-)

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010