ppc32 doesn't boot when linkaddr=0x00900000

hi
I am new to this list. Hope this is the right place to ask.

I am working with a PPC405GP board, and as far as I understand, the
support for ppc40x platforms like Acadia and Walnut were dropped with
kernel 5.8.0, so this seems like a pretty straightforward question,
but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't
shown a really clear, up-to-date answer.

In k4.11 .. k5.7.19, when the kernel size is bigger than 8 MB, the
final kernel doesn't boot but rather arch/powerpc/boot/main.c dies
before the first message from the kernel shows up.

Why?

Digging deeper I see the relation between the kernel size and link_addr

        # Round the size to next higher MB limit
        round_size=$(((strip_size + 0xfffff) & 0xfff00000))

        round_size=0x$(printf "%x" $round_size)
        link_addr=$(printf "%d" $link_address)

and this is where link_addr is involved

        text_start="-Ttext $link_address"

My kernels are compiled for cuboot, and the code that invokes "kentry"
is entirely located in arch/powerpc/boot/main.c

I instrumned that module, and this is what I see on the condole

The following is the same kernel, compiled with the same .config, but
with two link_addr values

A) with link_addr=0x0080.0000
image loaded from 0x00800000
SP=0x03eb1b80
kernel_size = 7411084 bytes
copying 256 bytes from kernel-image at 0x0080f000 to elfheader
elf_info.loadsize = 0x00700e68
elf_info.memsize  = 0x0074234c
allocating 7611212 bytes for the new kernel
copying ...
from = 0x0081f000
to = 0x00000000
size = 7343720
flush_cache, 32Mbyte flushed
cmdline: uboot bootargs overridden
cmdline=[console=ttyS0,115200 root=/dev/sda2 rootfstype=ext2 rw
init=/sbin/init ]
Finalizing device tree... flat tree at 0xf23b80
ft_addr=0xf23b80
my tp1: success
kernel booting ....
(it boots)

B) with link_addr=0x0080.0000
image loaded from 0x00900000
SP=0x03eb1b80
kernel_size = 7411084
copying 256 bytes from kernel-image at 0x0090f000 to elfheader
elf_info.loadsize = 0x00700e68
elf_info.memsize  = 0x0074234c
allocating 7611212 bytes for the new kernel
copying ...
from = 0x0091f000
to = 0x00000000
size = 7343720
flush_cache, 32Mbyte flushed
cmdline: uboot bootargs overridden
cmdline=[console=ttyS0,115200 root=/dev/sda2 rootfstype=ext2 rw
init=/sbin/init ]
Finalizing device tree... flat tree at 0x1023b80
ft_addr=0x1023b80
my tp2: success
my tp3: success
invalidate_cache 0x00000000+0x02000000
my tp4: (point of no return)
calling kentry()...
kernel booting ....
(it dies at this point, but without a debugger it's like watching
something fall into a black hole)

Any ideas?
I am lost ...

Carlo

Hi,

Le 25/09/2021 à 11:49, cp a écrit :

hi
I am new to this list. Hope this is the right place to ask.

I am working with a PPC405GP board, and as far as I understand, the
support for ppc40x platforms like Acadia and Walnut were dropped with
kernel 5.8.0, so this seems like a pretty straightforward question,
but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't
shown a really clear, up-to-date answer.

In k4.11 .. k5.7.19, when the kernel size is bigger than 8 MB, the
final kernel doesn't boot but rather arch/powerpc/boot/main.c dies
before the first message from the kernel shows up.

Why?

That's the fourth time I receive your email. Please give us time to 
analyse it, there is no point in sending it again and again unless you 
have additional information to provide.

Christophe

Hi,

Le 25/09/2021 à 11:49, cp a écrit :

hi
I am new to this list. Hope this is the right place to ask.

I am working with a PPC405GP board, and as far as I understand, the
support for ppc40x platforms like Acadia and Walnut were dropped with
kernel 5.8.0, so this seems like a pretty straightforward question,
but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't
shown a really clear, up-to-date answer.

In k4.11 .. k5.7.19, when the kernel size is bigger than 8 MB, the
final kernel doesn't boot but rather arch/powerpc/boot/main.c dies
before the first message from the kernel shows up.

Why?

...

The following is the same kernel, compiled with the same .config, but
with two link_addr values

A) with link_addr=0x0080.0000

...

Finalizing device tree... flat tree at 0xf23b80

...

B) with link_addr=0x0080.0000

...

Finalizing device tree... flat tree at 0x1023b80

...

Any ideas?
I am lost ...

As you can see above, when it works you have "flat tree at 0xf23b80", 
when it fails you have "flat tree at 0x1023b80".

The reason for the failure is likely that ppc 40x only maps 16 Mbytes at 
startup, so when your device tree is outside that map if fails.

See 
https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L656

Called from 
https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L56

As you can see it maps one 16Mbytes page.

Allthough I'm not an expert on 40x I think it should be easy to map a 
second 16Mbytes page to get 32Mbytes mapped. I will send a patch later 
today for you to test.

Christophe

hi,
this is my first patch-test report.

Today I have successfully tested Christophe Leroy's patch.
I had to manually edit lines, but it worked with a kernel sized 9.1MByte :D

used toolchain:
- powerpc-unknown-linux-gnu-binutiles-v2.34
- powerpc-unknown-linux-gnu-gcc-v9.3.0

host:
- macmini-intel, Gentoo cross-compiler

target:
- AMCC PPC405GP

wrapper:
- cuboot

Applied to kernel-v5.2.1-vanilla

Attached I report here is the difference between the original file and mine.

Thanks guys!
Carlo

----------------
Map 32Mbytes rather than 16MB of memory at startup

--- arch/powerpc/kernel/head_40x.S.original     2021-09-27

16:32:04.536000000 -0000

+++ arch/powerpc/kernel/head_40x.S      2021-09-27 16:32:04.532000000 -0000

@@ -38,6 +38,8 @@
 #include <asm/export.h>
 #include <asm/asm-405.h>

+#include <linux/sizes.h> /* hack, include/linux/sizes.h defines "SZ_16M" */
+
 #include "head_32.h"

 /* As with the other PowerPC ports, it is expected that when code

@@ -839,18 +841,25 @@
        mtspr   SPRN_PID,r0
        sync

-       /* Configure and load one entry into TLB slots 63 */
+       /* Configure and load one entry into TLB slots 62/63 */ /* hacked */
        clrrwi  r4,r4,10                /* Mask off the real page number */
        ori     r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */

        clrrwi  r3,r3,10                /* Mask off the effective page number */
        ori     r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))

-        li      r0,63                    /* TLB slot 63 */
-
+//-- hack begin
-----------------------------------------------------------------------------
+// TLB 63 is used for first 16M page
+// TLB 62 is for the second 16M page
+//        li      r0,63                    /* TLB slot 63 */ /* original */
+        li      r0,62                    /* TLB slot 62 */ /* hacked */
+// ------------------------------------------------------------------------------------------
        tlbwe   r4,r0,TLB_DATA          /* Load the data portion of the entry */
        tlbwe   r3,r0,TLB_TAG           /* Load the tag portion of the entry */
-
+// ------------------------------------------------------------------------------------------
+        addis   r4,r4,SZ_16M@h           /* added, hacked */
+        addis   r3,r3,SZ_16M@h           /* added, hacked */
+//-- hack end -----------------------------------------------------------------------------


        isync

        /* Establish the exception vector base