Cannot Boot A53 Linux from M7 on RDB3

[lihongjun]

Dear NXP,

I am trying to let RDB3 board boot from M7/nor, launch linux from A53/SD_card and run multicore IPCF demos.

The details of the images I built are as below:
1) M7_0 bootloader: secure boot, Crypto and Rm are all disabled;
2) IVT and bt_m7_blob.bin: boot target is M7, boot device is QSPI serial flash, DCD configured, HSE not configured.
3) u-boot: version = bsp35.0-2020.04, board = s32g399ardb3;
4) kernel: version = bsp35.0-5.10.145-rt, defconfig = s32cc_defconfig;
5) ATF: version = bsp35.0-2.5, plat = s32g399ardb3, BL33 = /home/lhj/fsl-auto-yocto-bsp/u-boot/u-boot-nodtb.bin
For dtc,  current version is 1.6.0, meanwhile version 1.5.0 or 1.7.0 has been tried too.

The issues are:
1) When set board boot from NOR Flash:
It cannot boot and shows below messages:
NOTICE: Reset status: Power-On Reset
ERROR: Failed to check FDT integrity
PANIC at PC : 0x0000000034306878

2) When set board boot from SD card, use the pre-built image:
It can boot and launch kernel successfully.

3) When set board boot from SD card, use the pre-built image and only replace the manually-built fip.s32 file in SD card:
It can boot and launch kernel successfully.

4) When set board boot from SD card, use the pre-built image and replace the manually-built Image or s32g399a-rdb3.dtb file in SD card:
It can boot, but u-boot cannot launch the kernel, shows below messages:

NOTICE: Reset status: Power-On Reset
NOTICE: BL2: v2.5(release):bsp35.0-2.5-dirty
NOTICE: BL2: Built : 15:44:39, Nov 6 2023
NOTICE: BL2: Booting BL31

U-Boot 2020.04 (Nov 06 2023 - 14:46:46 +0800)

CPU: NXP S32G399A rev. 1.1
Model: NXP S32G399A-RDB3
DRAM: 3.5 GiB
Ignore unsupported SCMI protocol 19
MMC: FSL_SDHC: 0
Loading Environment from MMC... OK
Configuring PCIe0 as RootComplex
PCIe0: Failed to get link up
PCI: Failed autoconfig bar 1c
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Board revision: RDB3 Revision F
Net: EQOS phy: rgmii @ 1

Warning: eth_eqos (eth0) using random MAC address - da:09:e1:22:aa:ae
eth0: eth_eqosFailed to get speed of XPCS for emac1_xpcs PFE: emac0: sgmii emac1: sgmii emac2: rgmii
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2

Hit any key to stop autoboot: 0
Failed to get speed of XPCS for emac1_xpcsPFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2
PFE: emac0: sgmii emac1: sgmii emac2: rgmii
pfeng_cfg_mode_enable: Invalid PFE device
switch to partitions #0, OK
mmc0 is current device
Booting from net ...
Failed to get speed of XPCS for emac1_xpcs PFE: emac0: sgmii emac1: sgmii emac2: rgmii
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2
eth_eqos Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Failed to get speed of XPCS for emac1_xpcsPFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2
eth_eqos Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Failed to get speed of XPCS for emac1_xpcsPFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2
Bad Linux ARM64 Image magic!
=>

It seems that the M7 bootloader works, but the kernel and device-tree I built are not correct, isn't it? If so, please tell me why and how to build them correctly.

Thanks.

[lihongjun]

Dear Daniel,

Actually, u-boot 35.0 and ATF 35.0 were used at first, the FIP_ALIGN variable in s32_common.mk was changed to 64 manually. Under this condition u-boot always halt after showing "pcie@40400000: RC/EP configuration not set correctly". Then the mmc_init() was added to s32_mmc.c and the outcome was the same. The log file was attached.

So I checked out u-boot and ATF to 33.0, applied 0001-fip-align-and-mmc-init.patch. Then rebuild u-boot and ATF. Under this condition the u-boot can be loaded successfully, and kernel can be loaded manually from u-boot. The log file was attached too.

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for the logs. Seems odd that mixing the builds lets you proceed no problem. Mixing BSP versions is not recommended from our side. 

For a last resort, you should be able to also patch the mmc part under your ATF sources:

"arm-trusted-firmware\drivers\nxp\s32\mmc\s32_mmc.c"

static bool s32_is_card_emmc(void)
{
struct mmc_cmd cmd;
+
+ s32_mmc_init();

Help us verifying if this lets you proceed with BSP35.0 only image. If not, let us know your findings for us to continue investigating.

We apologize.

Please, let us know.

[lihongjun]

Dear Daniel,

I have already add the code line "s32_mmc_init();" as you mentioned to file s32_mmc.c, but issue is the same. 

May I need to configure the bootloader to initialize all required clock resources to solve this problem? If so, the details of operation are required.

Is it possible that you set up a online Teams meeting about this issue with me?

Thanks. 

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

When you are saying "May I need to configure the bootloader to initialize all required clock resources to solve this problem?"", are you implementing additional functionality to the Linux boot and the M7 application?

From our side, we are not configuring any additional clocks under the M7 app (no clk_init function) and the Linux image is left as default, no modifications (aside from the ATF). 

Please, let us know.

[lihongjun]

Dear Daniel,

I didn't add any function to Linux boot and M7 application.

What I want is let bootloader boot the M7 IPCF demo from nor flash and A53 linux from SD card, then run IPCF ping-pong messaging program. 

I originally thought that it's simple and can be done after configure and build an M7 BL, the M7_0/1 IPCF sample, ATF(using BSP V35.0 u-boot and ATF V35.0), and run the pre-built ipc modules from SD card, because similar steps were introduced by document AN13750.

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. S32G3 IPCF examples are not defined to be boot from a Bootloader, but being loaded through u-boot, hence using them as they are by default might not provide the correct outcome.

As seen under the AN13750, new IPCF examples are provided (AN13750SW), which should be used with the steps mentioned in there. The IPCF default examples should not be used.

Since S32G3 does not have a multicore application note, IPCF examples might require additional modifications, but we are not aware of the required modifications at this moment.

We explained how to load a simple blink application to the M7 and seeing the default boot log for BSP35.0. The steps we shared are working for us and we are not able to reproduce the situation you are seeing. 

Given this last comment, we understand that the M7 application was not a blink example, but was the IPCF example, which might the reason. Still, we could be misunderstanding it. We do apologize.

We can also recommend either contacting your local NXP FAE/DFAE since they should be able to provide on-site support and see the same behavior your are seeing. You could also open an NXP online service ticket, since there SW sharing could be done from our side.

Again, we apologize for any inconvenience this is causing.

Please, let us know.

[lihongjun]

Dear Daniel,

Thank you for your help. For the ATF issue, I will try to find solution with Chinese FAE. Before this issue is solved, I will try to run IPCF demo from u-boot. But it seems that the IPCF demo in AN13750SW is designed for S32G274, not for S32G399. If I must use them, what shall I do to build them under S32DS and run them on RDB3?

And, to verify if the ATF issue is hardware-related, could you please test the ATF image I built on your board, and tell me the outcome message? The image files(fip.bin and fip.s32 zipped) were compressed and attached. The load address of fip.bin should be 0x342faf00.

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. For the tests that we did, we are not seeing problems from your FIP images.

The IPCF examples (not AN13750SW) are to be run from uboot, you should not see problems from your side.

As for AN13750SW examples for RDB3, we understand that the team is working on a similar application note to AN13750, but it is still under development. We do apologize.

Please, let us know.

[lihongjun]

Dear Daniel,

I will try as you told, but might this is not the root cause of the issue. Because I have tried to configure the BL only boot ATF on A53_0 core, not boot the two M7_0/1 demos, and the issue is still there.

Thanks. 

[lihongjun]

Dear Daniel,

If just write prebuilt image to SD card and set board boot from SD card, it will bootup successfully, and login prompt will be shown at last.

But it will show "failed to check FDT integrity" if the board is set to boot from nor-flash. 

Thanks. 

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

To verify if the fip.bin was built correctly, you could try to create an IVT with the fip.bin as the Application Bootloader and A53_0 as boot core. If there is no problem with the binary, then you should be able to boot from NOR Flash and see an output in the console.

Also, we may have not explained adequately, we were referring as if in the following step:

4) When set board boot from SD card, use the pre-built image and replace the manually-built Image or s32g399a-rdb3.dtb file in SD card:

Have you tried without "replace the manually-built Image or s32g399a-rdb3.dtb". Just modify the fip.s32 under the pre-built image, don't change any other file.

Please, let us now.

[lihongjun]

Dear Daniel,

I made the IVT with fip.bin I built and A53_0 as boot core, and the board can boot from NOR flash and run linux kernel successfully.

If I only replace the fip.s32 file in SD card and keep all other images unchanged, it can boot directly from SD card, and the kernel can be launched too. 

Thanks.