Dear Daniel,
The applications I used under M7 core are IPCF_Example_multi_instance_S32G399_M7_0/1 included in S32G3 software bundle.
The M7 BootLoader creation and configuration steps are:
1. Import the Bootloader_S32G3XX_ASR_4.4_M7 project from Integration_Reference_Examples_S32G3_2023_02 folder into EB;
2. Load configuration, disable Rm item and Rm_Init item in SysDal plugin;
3. Edit boot sources as below:
The reset handler of those boot sources are gotten respectively from the ATF building output, the Reset_Handler keyword of IPCF_Example_multi_instance_S32G399_M7_0.map file and the intc_vector keyword of IPCF_Example_multi_instance_S32G399_M7_1.map file.
4. Configure Boot image fragments of linux_bsp_atf as below:
The load address is gotten from ATF building output.
5. Configure Boot image fragments of ipc_app_m7_0 as below:
The address is gotten from int_sram_c0 keyword in IPCF_Example_multi_instance_S32G399_M7_0.map. The size of IPCF_Example_multi_instance_S32G399_M7_0.bin file is 768KB.
6. Configure Boot image fragments of ipc_app_m7_1 as below:
The address is gotten from int_sram_c1 keyword in IPCF_Example_multi_instance_S32G399_M7_1.map. The size of IPCF_Example_multi_instance_S32G399_M7_1.bin file is 768KB too.
7. Configure the boot core as below:
8. Delete project output, generate project, then build the BootLoader by calling launch.bat in Cygwin.
BTW, I have tried to disable secure boot, but it has no affect on board bootup result.
Then I burned all the images mentioned above to Nor flash, wrote prebuilt image to SD card and replaced the fip.s32 file in card. The board can bootup OK in SD card boot mode but failed in Nor flash boot mode.
FYI.
Thanks.
Hi,
Thanks for your feedback. For what we can see, we understand with the following configuration:
That you are using the default linker provided under the IPCF demo for S32G399. If so, we understand that the example is not prepared for using it as per the AN13750, since the "description.txt" file describes the expected steps to be followed, which are to load the binaries directly from u-boot, not through the usage of the NXP bootloader.
Since we understand you are trying the first steps to use the NXP bootloader, we recommend using the linker provided under the AN13750SW (the ones available under the IPCF examples) and modify a blink example with this linker. If done correctly, you should see a led being toggled under your RDB3 and Linux booting.
Again, IPCF examples were not prepared to be used as mentioned under the AN13750, that is why AN13750SW provides the examples to be used.
Please, let us know.
Hi,
With this we are referring to using the provided linker under the AN13750SW IPCF example, and modify the "Siul2_Dio_ToggleLed_S32G399A_M7" example's linker with it, something as shown below:
If done correctly, your M7_0 source should look as follows under the Bootloader:
This will only be a first step, so that we know it is working.
As for why when only the A53_0 core was enabled it didn't work, we assume that M7_0 core was left unattended (since there was no app linked to it) hence it may have cause the behavior.
Please, let us know.
Dear Daniel,
I have tried as what you told, and the LED toggle demo is running (I modified source code to let the blue LED flicker for 1000 times, and it works).
But for A53, u-boot cannot load kernel and always halt after showing "pcie@40400000: RC/EP configuration not set correctly", just the same as before.
I think there must be something wrong during ATF building. Please help me to find the reason.
And I have 2 more questions here:
1) Could you please tell me the u-boot source version, the ATF source version, the dtc version and the version of any other components/tools needed by ATF building which are used by your teams for IPCF application on RDB3 board?
2) In AN13750, it says I must apply the patch to modify the alignment of ATF. In fact I just modified the s32_common.mk file and didn't execute the patch command, because I don't know if I must do this for RDB3, and where and how to get the patch. Is it possible that this situation cause the ATF issue?
Thanks.
Dear Daniel,
The boot source configure of my BL (ATF and LED toggle demo) is as below:
Boot image fragments of Linux ATF:
For Linux image building, the steps I followed are:
1) Download toolchain;
2) Build u-boot:
A) Clone u-boot source code, checkout to bsp35.0-2020.04;
B) Build u-boot:
make CROSS_COMPILE=/home/lhj/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- s32g399ardb3_defconfig
make CROSS_COMPILE=/home/lhj/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-
3) Build ATF
A) Install libssl-dev and openssl;
B) Install dtc
C) Clone ATF source code and checkout to bsp35.0-2.5;
D) Edit s32_common.mk file set FIP_ALIGN := 64;
E) Build ATF
make CROSS_COMPILE=/home/lhj/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ARCH=aarch64 PLAT=s32g399ardb3 BL33=/home/lhj/fsl-auto-yocto-bsp/u-boot/u-boot-nodtb.bin
The result of ATF building is:
Image Layout
IVT: Offset: 0x1000 Size: 0x100
AppBootCode Header: Offset: 0x1200 Size: 0x40
Application: Offset: 0x1240 Size: 0x30800
Boot Core: A53_0
IVT Location: SD/eMMC
Load address: 0x342faf00
Entry point: 0x34302000
4) Build Linux
A) Clone Kernel source code and checkout to bsp35.0-5.10.145-rt;
B) Build:
make ARCH=arm64 CROSS_COMPILE=/home/lhj/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- s32cc_defconfig
make ARCH=arm64 CROSS_COMPILE=/home/lhj/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-
Note: Although the kernel image and dtb files are generated successfully, I did not use them so far.
5) For usage of image files:
A) The fip.bin file built by myself was burned to nor flash at beginning address 0x100000;
B) For SD card, the prebuilt image fsl-image-auto-s32g399ardb3.sdcard (unzipped from binaries_auto_linux_bsp35.0_s32g3_pfe.tgz file included in S32G3 software bundle) was written first, then the fip.s32 file built by myself was replaced. The Image and s32g399a-rdb3.dtb file built by myself were not used yet.
FYI
Thanks.
Hi,
Given the steps you are mentioning, we believe you have not used the AN13750SW linker, as per our previous description, since the address you show is the following:
And the one that from using the AN13750SW linker should be the following:
Still, we have changed our linker to, as per our current knowledge, be the same the one you are using (the one available under the IPCF_Example_multi_instance_S32G399_M7_0 example). Our result is the following:
With this, we compile the Bootloader. Create the following IVT:
Where the DCD and QSPI parameters can't be seen, but are the ones provided under the following paths:
C:\nxp\Integration_Reference_Examples_S32G3_2022_06\code\framework\realtime\swc\bootloader\platforms\S32G3XX\res\flash\S32G3XX_QuadSPI_133MHz_DDR_configuration.bin
C:\nxp\Integration_Reference_Examples_S32G3_2023_02\code\framework\realtime\swc\bootloader\platforms\S32G3XX\res\flash\S32G3XX_DCD_InitSRAM.bin
Since we disable HSE under the Bootloader, we do not provide any HSE-FW under the IVT:
Our Bootloader.c file looks as follows (only modifications done to it):
Then flash as per AN13750 explains:
Erase from 0x0 to 0x400000. Then flash as follows:
- 0x0 -> Blob of the IVT shown previously
- 0x100000 -> fip.bin
- 0x200000 -> Siul2_Dio_ToggleLed_S32G399A_M7.bin (where Reset_Handler address is 0x34100010, this can be confirmed under the *.map file)
With this, we are able to see the LED (under PA_06) being toggled under uboot and see the full Linux boot (when the Linux boot starts, the LED stops toggling, since we did not reconfigure anything under the Linux DTB):
The full log will be attached to this post.
At the end, we understand we are following your setup, as per our current understanding, and can see both cores running no problem.
Please, let us know.
Hi,
As for the test I provided before, I only applied the FIP_ALIGN patch to be equal to 64. After that, I build the uboot and ATF as per AN13750 (with the branch set to BSP35.0, without the mmc patch, the platform to be RDB3 and the links to the github repository instead of CodeAurora).
With that, we are seeing the correct outcome from our side.
If you are only doing a toggle, toggle example does not configure any clocks, hence there should not be a problem. If you are configuring clocks, then all clock inits should be done under the Bootloader.
Still, we can recommend also opening an NXP online ticket, if you require any code/file sharing.
Please, let us know.
