S32G RDB2 A53 kernel panic after M7 application start

[glenfujimori]

1. Start an IPCF multi M7 core demo or IPCF single M7 core demo using startm7 from u-boot. The M7 App starts and runs without issues; console output on UART1.

2. Type 'boot' in u-boot to start A53 Linux. Console output on UART0.

3. Kernel panics almost immediately:

=> boot
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2
PFE: emac0: sgmii emac1: none emac2: rgmii
pfeng_cfg_mode_enable: Invalid PFE device
switch to partitions #0, OK
mmc0 is current device
13756424 bytes read in 623 ms (21.1 MiB/s)
Booting from mmc ...
44164 bytes read in 22 ms (1.9 MiB/s)
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 0000000083000000, end 000000008300dc83
fixup: pfe0 set to 00:01:be:be:ef:11
fixup: pfe1 set to 00:01:be:be:ef:22
fixup: pfe2 set to 00:01:be:be:ef:33

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.10.120-rt70+g0b76731696c1 (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #1 SMP PREEMPT Mon Sep 12 13:23:16 UTC 2022
[ 0.000000] Machine model: NXP S32G274A-RDB2
[ 0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '115200n8')
[ 0.000000] printk: bootconsole [linflex0] enabled
[ 0.000000] SError Interrupt on CPU0, code 0xbf000000 -- SError
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.120-rt70+g0b76731696c1 #1
[ 0.000000] Hardware name: NXP S32G274A-RDB2 (DT)
[ 0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 0.000000] pc : setup_arch+0x164/0x58c
[ 0.000000] lr : setup_arch+0x15c/0x58c
[ 0.000000] sp : ffffffc010c83ef0
[ 0.000000] x29: ffffffc010c83ef0 x28: 0000000080b30018
[ 0.000000] x27: 00000000ffaa27f8 x26: 0000000000000000
[ 0.000000] x25: 00000000ffb38bf0 x24: 00000000ffe0e1c8
[ 0.000000] x23: ffffffc010d22000 x22: ffffffc010c8e380
[ 0.000000] x21: fffffffefe600094 x20: ffffffc010cd7148
[ 0.000000] x19: ffffffc010000000 x18: 0000000000000030
[ 0.000000] x17: 0000000000001800 x16: 0000000000000000
[ 0.000000] x15: ffffffc010c8e7e8 x14: ffffffffffffffff
[ 0.000000] x13: 0000000000000000 x12: 0000000000000028
[ 0.000000] x11: 0000000000000015 x10: 0101010101010101
[ 0.000000] x9 : 3334ff6b6e6e6f5e x8 : 7f7f7f7f7f7f7f7f
[ 0.000000] x7 : 736d647164676e62 x6 : 000006161d090b74
[ 0.000000] x5 : 740b091d16060000 x4 : 0000000000000000
[ 0.000000] x3 : ce6ded8ca0000000 x2 : 000000000000000c
[ 0.000000] x1 : 0000000000000000 x0 : 0000000000000080
[ 0.000000] Kernel panic - not syncing:
[ 0.000000] Asynchronous SError Interrupt
[ 0.000000] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

4. Reset board. Type 'boot' in u-boot without starting M7 app. A53 Linux boots and runs without issue.

5. Command used to start M7 app:

bootm7=dcache off; mw.q 34000000 0 100000; tftp 80000000 sample.bin; cp.q 80000000 34300000 600000/8; startm7 34501000

NOTE: if I issue the dcache off, mw.q and tftp commands and then enter 'boot', Linux A53 will start up normally.  If I issue the dcache off, mw.q, tftp and cp.q commands and then 'boot', Linux A53 will panic.

6. u-boot version: U-Boot 2020.04+g6391b468b1 (Sep 12 2022 - 14:11:05 +0000)

7. Using LinuxBSP 34.0;  Linux version 5.10.120-rt70+g0b76731696c1

8. This panic does not occur on earlier Linux BSP version 28.

9. Using SW32G_IPCF_4.6.0_D2205 and SW32_RTD_4_4_3_0_3_D2206 to build the M7 app.

[Daniel-Aguirre]

Hi,

We are seeing that you start the M7 from 0x34501000, whereas the example should start on 0x34401000.

Also, when copying the application to internal SRAM you are adding a division by 8, which we might be misunderstanding.

The "description.txt" provided in the project details the commands expected from the u-boot side to load the application into SRAM and start the M7 core. the commands should be the following:

dcache off
mw.q 0x34000000 0x0 0x100000
fatload mmc 0:1 0x80000000 IPCF_Example_S32G274_M7_0.bin
cp.q 0x80000000 0x34300000 0x60000
startm7 0x34401000
boot

Since you are tftping your image, we understand you are loading the image to DDR then copying to internal SRAM, for which we don't see the problem in that change. Still, if possible, you could try to follow the commands are they are presented, to understand if you have trouble with that.

We are following the steps as shown on the "description.txt" and don't see this specific behavior. 

Please, let us know if this information was helpful or not.

[Markus_Schroeder]

Just a short remark here, the documentation inside the IPCF package "SW32G_IPCF_4.6.0_D2205_UserManual.pdf" on page 30 says:

whereby 0x60000 has one '0' too much, which makes quite a difference.

That took us some time to figure that out.

It seems, the original post has the same problem.

[wangzhenkai]

i have the same question