Issue with Enabling HSE Features in Multicore Bootloader on S32G399ARDB3 Board

ashwini2024 · ‎01-21-2025

I am enabling HSE features on the A-core and bootloader of the S32G399A RDB3 board using Yocto BSP 40.

I am enabling HSE features in A core and bootloader , where its a multicore bootloader but we are observing that the control does not transition to U-Boot from bootloader , but parallelly m core autosar application is running. To debug the issue, I disabled the M-core, but the control still does not transition to U-Boot. This suggests there is an issue with the control flow reaching U-Boot.

Here are the details of my setup:

DISTRO_FEATURES:append = " hse "
NXP_FIRMWARE_LOCAL_DIR = "/yocto-s32g3/folder"

DCD:            Offset: 0x200       Size: 0x1c
IVT:            Offset: 0x1000      Size: 0x100
HSE Firmware:   Offset: 0x1200
HSE SYS Image: Offset: 0x62400     Size: 0xc000
AppBootCode Header: Offset: 0x6e400 Size: 0x40
Application:    Offset: 0x6e440     Size: 0x2f800
I kept the load address as 0x346062c0 in the bootloader. And also the QSPI flash address to be 0x26e440 in bootloader.

Memory Layout:

Bootloader: Address 0x0
A-core Application: Flashed at 0x200000
M-core Application: Flashed at 0x400000

In this configuration, the control does not transition to U-Boot.

[NOTE]: 1.While booting A core alone we are observing the same issue and when hse is disabled on a core we are able to see the log

2.With A core as standalone [SD-card mode] it is booting.

1)What adjustments are required in the image layout, load address, or firmware configurations to support HSE features in A core?
2)Is there any specific configuration we have to do in bootloader for the HSE enabled A core ?

alejandro_e · ‎01-21-2025

Hello @ashwini2024,

From the information of your Yocto configuration I assume you followed section 10.2 Building HSE Features with Yocto of the BSP40 user manual. Following the steps described in that section, at the end of it, there is an example of how to modify your configuration [page 77]:

Please let me know if adding these options changes the behavior.

In case the behavior is the same, please let me know the following:

What are the steps you are following to test the u-boot access to the HSE functionality?
Which HSE version are you using?
Which RTD version are you using?
Which are the initialized and deinitialized modules in your bootloader?
When you mention "Bootloader: Address 0x0", do you men the whole blob? this is the bootloader with the IVT
What I understand from your description is that the booting in general is working, for both the A and the M cores, the problem you describe is u-boot access to the HSE functionalities. Is my understanding correct?
Can you describe which HSE functionalities exactly are you expecting from u-boot and what is the objective in your project of said functionalities?

Thanks in advance for all the information.

ashwini2024 · ‎01-22-2025

I am working on BSP 40 HSE version is HSE_VERSION="0_2_22_0" and enabling HSE features in the A-core and bootloader. I am using a multicore bootloader, but I am observing that the control does not transition to U-Boot from the bootloader, while the M-core AUTOSAR application is running in parallel. To debug the issue, I disabled the M-core, but the control still does not transition to U-Boot. This suggests an issue with the control flow reaching U-Boot.

The A-core log includes the following image layout:

Image Layout:

DCD: Offset: 0x200, Size: 0x1c
IVT: Offset: 0x1000, Size: 0x100
HSE Firmware: Offset: 0x1200
HSE SYS Image: Offset: 0x62400, Size: 0xc000
AppBootCode Header: Offset: 0x6e400, Size: 0x40
Application: Offset: 0x6e440, Size: 0x2f800

Boot Core: A53_0

IVT Location: SD/eMMC

Load Address: 0x346062c0

Entry Point: 0x34610000

I kept the load address as 0x346062c0 in the bootloader and set the QSPI flash address to 0x26e440 in the bootloader.

Flashing details:

Bootloader: Address 0x0
A-core Application: Flashed at 0x200000
M-core Application: Flashed at 0x400000

The following is my blob :

The following shows the configurations on EB which suggests the source address in QSPI:

I suspect that the offset 0x1200 might be causing the issue and am considering the possibility of updating it on the A53 core.

Can you provide guidance on whether the offset 0x1200 could be causing this issue and if there are any additional steps or configurations I should verify to ensure a proper transition to U-Boot?

alejandro_e · ‎01-23-2025

Hello @ashwini2024,

The offset of 0x1200 should not be a problem, since it is the NXP implementation and cannot be changed. Can you help answering all questions I asked before? particularly these:

Which are the initialized and deinitialized modules in your bootloader? This is because u-boot starts and tries to initialize an already initialized module it fails, it needs to be deinitialized
What I understand from your description is that the booting in general is working, for both the A and the M cores, the problem you describe is u-boot access to the HSE functionalities. Is my understanding correct?
When you say "the control still does not transition to U-Boot" do you mean that u-boot is not starting at all or do you mean that u-boot is not capable of accessing the HSE features?
If it does not boot at all, please share the boot prints you see in the terminal, if any.
If you mean that it does not have access to the HSE features, please share with me which HSE features are you expecting from u-boot.

Thanks in advance for the information.

ashwini2024 · ‎01-23-2025

@alejandro_e

Thank you for the reply.
1) The initialised and deinitialised modules in the bootloader are as following :

2) Why does the A-core boot successfully in standalone mode using SD card boot, but fail to boot and get stuck when using serial boot mode? Here’s the error snippet:

alejandro_e · ‎01-27-2025

Hello @ashwini2024,

Have you being able to use this multicore bootloader in the past? before adding the HSE functionalities?

You mentioned that you are flashing the A-core image in address 0x200000 but I see in your screenshots that you are using a different source address, 0x26e440, if you check AN13750 in page 12 and 20, the load address and the address in which you flash the image have to match:

Also please note the match between the Load address (from the u-boot compilation log) and the load image at in Tresos, and the match between Entry point (from the u-boot compilation log) and the Reset handler address in Tresos:

Let me know if this changed the behavior in any way.

Best regards

ashwini2024 · ‎01-27-2025

Yes, the multicore bootloader is functional.
I tried with that, but the response is still the same.
The Control is stuck .

alejandro_e · ‎01-29-2025

Hello @ashwini2024,

Can you give me more details about what are you flashing in address 0x200000? What exactly do you mean by "A-core Application"?

Also, you mention that booting directly from SD card enables the A core booting, can you describe what are you flashing into the SD and the steps you are following to flash?

Thanks in advance for the information.

ashwini2024 · ‎01-29-2025

Hello @alejandro_e ,

Thank you for the reply.

I am flashing fip.s32-sdcard [present in location yocto-s32/build/tmp/deploy/images/s32g399ardb3] to the NOR flash at 0x200000.

And in the SD card im copying the file ros-image-core.rootfs.sdcard [present in location yocto-s32/build/tmp/deploy/images/s32g399ardb3] using command :

sudo dd if=./ros-image-core-foxy.rootfs.sdcard of=/dev/sdb bs=1M && sync

alejandro_e · ‎01-30-2025

Hello @ashwini2024,

Thanks for the information, can you use the fip.s32-qspi instead of the .s32-sdcard when flashing to the NOR Flash?

Let me know the behavior after this change.

Thanks in advance

ashwini2024 · ‎01-30-2025

Thank you @alejandro_e for the reply.

Why do u suggest flashing fip.s32-qspi to the NOR ?
And is it possible for you to share the step by step details to enable HSE on both cores with the multicore bootloader.

Thanks in advance for the information.

alejandro_e · ‎01-31-2025

Hello @ashwini2024,

I suggested to flash the qspi version because you are booting from qspi, performing some test I can see that using the fip.s32-sdcard results in the A53 cores not booting and using the fip.s32-qspi does boot the A53 cores. Can you help me with a test? can you boot only the fip.s32-qspi in address 0x00 of the qspi, then boot from qspi and let me know if you can see u-boot starting?

About the step by step guide, I was not able to find such document for the S32G3, however there is one for the S32G2, the AN13750 includes some steps related to the HSE. you can also check the Bootloader User Manual that comes with the Gold VIP package, which you can download from AUTO-SW-PACKAGE-MANAGER :

After installing the Gold VIP package you can find the user manual in the documentation folder.

Let me know if this information helped you.

ashwini2024 · ‎02-06-2025

Yes, i checked with flashing the fip.s32-qspi at 0x0 location and it is showing Bad Linux image.

ashwini2024 · ‎02-06-2025

Reset status: Power-On Reset
NOTICE: v2.5(release):bsp40.0-2.5-dirty
NOTICE: Built : 08:41:20, Mar 21 2024
NOTICE: Booting BL31

U-Boot 2022.04+gd482def7e3+p0 (Mar 21 2024 - 08:40:56 +0000)

SoC: NXP S32G399A rev. 1.1
CPU: ARM Cortex-A53 r0p4 @ max 1300 MHz
Model: NXP S32G399A-RDB3
DRAM: 3.5 GiB
Core: 307 devices, 25 uclasses, devicetree: board
MMC: FSL_SDHC: 0

Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

s32cc_serdes_phy serdes@40480000: Using mode 0 for SerDes subsystem
pci_s32cc pcie@40400000: Configuring as RootComplex
pci_s32cc pcie@40400000: Failed to get link up

serial@401c8000
Err: serial@401c8000

Board revision: RDB3 Revision F

PCIe: BusDevFun VendorId DeviceId Device Class Sub-Class
pcie@40400000 RootComplex
| 01:00.00 0x1957 0x4300 Bridge device 0x04

Net:
Warning: ethernet@4033c000 (eth0) using random MAC address - 16:7e:75:a3:92:f6
eth0: ethernet@4033c000

Found PFE version 0x0101 (S32G3)
Too large ELF file, size: 4294836224
PFE firmware file '<NULL>@0x030a0000:<NULL>' loading failed: -27

Found PFE version 0x0101 (S32G3)
Too large ELF file, size: 4294836224
PFE firmware file '<NULL>@0x030a0000:<NULL>' Loading failed: -27

Hit any key to stop autoboot: 0

Booting from flash...
Reading 15532032 byte(s) at offset 0x00000000
Reading 196608 byte(s) at offset 0x0e000000
Reading 32571392 byte(s) at offset 0x000e0000
Bad Linux ARM64 Image magic!

The above is the error I am facing.

alejandro_e · ‎02-06-2025

Hello @ashwini2024,

Good to know that you can boot u-boot from the QSPI, now to boot the kernel please execute the following commands in the u-boot command line:

=> setenv bootcmd "mmc dev ${mmcdev}; if mmc rescan; then if run loadimage; then run mmcboot; fi; fi"
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK

For this you will need to insert an SD card with the .sdcard image flashed on it, so u-boot can find the Kernel image in the respective partition.

After that please reboot your board, it should load the Linux kernel normally.

in case you keep having problems please send the output of the following command from the u-boot command line:

=> printenv

Let me know the result of this change.

ashwini2024 · ‎02-06-2025

I am unable to boot with the bootloader using fip.qspi despite following the required flashing and configuration steps, and I would like to understand the possible reasons for this issue and any debugging steps you recommend.

ashwini2024 · ‎02-06-2025

I am succesfully able to boot and the control goes to login root.

alejandro_e · ‎02-10-2025

Hello @ashwini2024,

When using the full QSPI bootloader, are you still having the same exact behavior you were seeing at the start of this post?

Thanks for the information.

ashwini2024 · ‎02-10-2025

Hello @alejandro_e ,

Thank you for the reply.

Could you elaborate on that ? I am not sure about full QSPI bootloader you are referring to?

Thanks in advance for the information.

alejandro_e · ‎02-11-2025

Hello @ashwini2024,

Sorry for not explaining correctly. What I mean is that, now you are able to correctly boot when using only the fip.s32-qspi, which only boots the A53 side (ATF, u-boot and finally Linux), in that last message my question was, when you integrate this new fip.s32 into the multicore bootloader (the one that previously prevented the A53 cores from booting) do you get the same behavior as when you posted this question? or are you now able to boot the A53 and M7 cores correctly at the same time?

Thanks in advance for the information.

ashwini2024 · ‎02-12-2025

We are able to boot our NXP Multicore bootloader with HSE integrated with HSE disabled on A core ,we are only facing issue if i try to integrate HSE on A core application with Multicore boot that has HSE integrated .
My RTD version is RTD-4_0_2.