S32R45 M7 bootloader downloads u-boot image from flash and activates A53

ssong · ‎05-23-2022

Following is the scenario we want:

** Flash Layout for boot **

---------------------------------------------------------------------------------------

Exported Blob |

(IVT + QSPI reconf + DCD + HSE + Application bootloader(M7)) |

---------------------------------------------------------------------------------------

Application for M7 |

---------------------------------------------------------------------------------------

u-boot for A53 |

--------------------------------------------------------------------------------------

1. Application bootloader downloads Application for M7 and u-boot for A53

2. Application bootloader activates A53 and M7

3. u-boot in A53 configures hardware and downloads kernel for A53 from DRAM

4. u-boot jumps to kernel for A53

Is this possible scenario for S32R45? If so, can we make u-boot only image without IVT+QSPI reconf+DCD+HSE? What I found in mamual is the way of makeing u-boot image with them. Otherwise, Are there any other guided scenario for M7 bootloader to activate A53 in NXP?

Attached image is the S32DS bootsource configuration for better understanding

aiweixin · ‎01-03-2023

Hi,

I want to create a bootloader project to start up M7 and A53 core，how can i do for it?

Can you help me, Some doc or idea?

Additionally, where can i configure it as shown in attached image?

GaryRK · ‎01-03-2023

Hello,

Please refer to the S32R45 Platform Software Integration package which contains the bootloader example. You can download this package from your NXP.com account, go to Software Licensing and Support then Software Accounts and navigate Automotive SW - S32R45 Standard Software -> Automotive SW - S32R45 - Platform Software Integration.

If you download and install the Platform Software Integration package into S32 Design Studio then the documentation for the bootloader is available here:

<S32DS install path>\S32DS\software\PlatformSDK_S32XX_2021_12\PlatformSoftwareIntegration\2022_03_0\documentation

aiweixin · ‎01-03-2023

Hi Gary,

I find the Bootloader Integration Example in the Platform_Software_Integration_S32R45 don't start A53 core, or I didn't understand it correctly.

Question link: https://community.nxp.com/t5/S32-Design-Studio/How-to-create-a-bootloader-project-to-start-up-both-M...

Can you help me?

GaryRK · ‎05-24-2022

Hello ssong,

Yes this is a valid boot scenario for S32R45. The NXP BootROM FW will read and process the [IVT + QSPI reconf + DCD + HSE] then boot the [Application bootloader (M7)] which can load the [Application for M7] and then [u-boot for A53].

I don't understand this question: "can we make u-boot only image without IVT+QSPI reconf+DCD+HSE?"

The [IVT + QSPI reconf + DCD + HSE] is needed only for the primary bootloader (or application) which is loaded by the NXP BootROM FW. For the scenario you describe it is not necessary to pre-pend these structures to the u-boot image because it is your [application bootloader (M7)] that will perform the loading of u-boot, not the BootROM FW.

You can also configure to have the BootROM FW target the A53 as boot core and boot u-boot directly, it does not need to be the M7 core that starts first. Is this what you mean? The S32R45 Linux BSP boots like this.

ssong · ‎05-26-2022

After we build u-boot image, we got the binary image which contains not only u-boot but also IVT+QSPI reconf + DCD +HSE.

u-boot should be the secondary bootloader that operate in A53 so that it doesn't need to contain IVT + QSPI reconf, etc

What we got in Linux BSP which is provided from NXP, it contains a file [fip.s32-qspi] It also contains u-boot plus IVT+QSPI reconf + DCD + HSE

GaryRK · ‎05-26-2022

Okay I understand now. It's correct that u-boot as the secondary bootloader does not need the BootROM FW data structures pre-pended so we can use the u-boot binary directly.

To get the u-boot binary you will need to build u-boot from source using the instructions in the BSP user manual, latest version is:

Linux BSP 32.0 User Manual for S32R45 platforms

2.2.2 Setting up and building U-Boot bootloader

Then you will find u-boot.bin in the build output files - use this file.

ssong · ‎05-27-2022

Thanks, we got u-boot.bin as follows. It seems that it has only u-boot image.

We need to locate it in SRAM, especially on 0x34300000. The application bootloader(m7) copies u-boot.bin from external flash to SRAM(0x34300000) and A53 core starts with it.

However u-boot.bin seems to be built to start with 0xffaa0000 based on map file. Could we change the start address of u-boot.bin to 0x34000000? If so, how can we do it?

ssong · ‎05-30-2022

u-boot.bin's start address changed with the modification of board\freescale\s32-gen1\Kconfig's SYS_DATA_BASE default value from 0xffaa0000 to 0x34300000

Please confirm this way of modification is correct.

Do we have to change SYS_DATA_BASE accordingly?. It seems that we don't need to change it as we analyze the .map file.

Next step is that u-boot, located in SRAM(0x34300000), loads linux kernel and shell prompt should be appeared. We built Linux kernel based on [2.2.3 Setting up and building the Linux kernel]. What could be the next step? Kernel image can't be copied to sram because it is bigger than SRAM total space. It might be copied to SD card and u-boot loads it into DRAM. Please guide us to make this done

alejandrolozan1 · ‎05-30-2022

Hello,

Yes, you have to modify both macros to change the starting point of uboot. This can be achieved in the menuconfig as shown below.

Saludos,

Alejandro

ssong · ‎06-02-2022

Even though SYS_TEXT_BASE, SYS_DATA_BASE changed from DRAM to SRAM, u-boot seems to access to DRAM, especially 0xD00000000 on function(write_msg_to_smt) as below:

shm_buf->buf is the pointer to 0xD0000000 which has not been initialized in M7 bootloader.

There seems to be two ways for this:

1) M7 bootloader initializes external DRAM

2) u-boot initializes external DRAM before access to it.

I tried way 1) with DDR tool in S32Ds, but failed. Could you give us the example project for it?

Could you let me know the way of initializing DRAM in u-boot?

alejandrolozan1 · ‎06-03-2022

Hi,

In latest BSP (BSP32) the DDR initialization was moved to the ATF. U-boot does not perform this initialization anymore.

In fact, if you want to use BSP32 I would suggest you to start taking a look at ATF first.

The default and quite general boot process is this :

ATF is loaded in SRAM and starts execution
Initializes DDR and moves Uboot to DDR
ATF releases control to U-Boot.

If you want the M7 to act as the first load stage, I would suggest you execute this bootloader in a SRAM section different from the ATF. If your bootloader is not too large, maybe you can fit bootloader and ATF+Uboot (fip.s32) in the SRAM. Of course you have to be also aware of the clock changes as the ATF manages this.

Saludos,

Alejandro

ZhiguoZhong · ‎02-19-2023

Hello，

So, can I modify the size of the fip header to satisfy the customization of the load address？how to do?

thanks!

ssong · ‎06-07-2022

Thanks for the hint.

fip.bin was generated as follows:

> make CROSS_COMPILE=/home/sanghoon/toolchain/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ARCH=aarch64 PLAT=s32r45evb BL33=/home/sanghoon/u-boot/u-boot-s32.bin FIP_MEMORY_OFFSET=0x34300980

fip.bin, which has bl2+bl31+bl33, was loaded in SRAM(base=0x34300980) and M7 bootloader jumped to 0x34302000 so that layout is as follows:

------------------------------ 0x34302000

bl2

------------------------------ 0x34323DA0 (0x343023420+980)

bl31

------------------------------

bl2 initialize and use the SRAM for their data section from 0x34323DC0 until 0x34340000 and it overlaps bl31's code section. Unfortunately, bl31's code section is corrupted by data of bl2.

Could you let me know how to solve it?

alejandrolozan1 · ‎06-08-2022

Hi,

There are a few things that do not make sense to me, can you clarify?

1. You say M7 jumps to 0x34302000... but the ATF should be executed by the A53.

2. How can you tell of this overlap? did you modify the ATF? if so, what did you modify?

3. Are you getting the same behavior without this FIP_MEMORY_OFFSET=0x34300980?

Saludos,

Alejandro

ssong · ‎06-08-2022

1. You say M7 jumps to 0x34302000... but the ATF should be executed by the A53.

-> Sorry for the confusion. M7 activates A53 and A53 starts from 0x34302000. M7 jumps to his application.

2. How can you tell of this overlap? did you modify the ATF? if so, what did you modify?

-> All modification is listed in diff.txt which is the result of [git diff]. Two modifications has been added since the last question. Those are:

bl2.ld.S/bl2_el3.ld.S : Omit the NOLOAD symbol to fill .bss section as zero in binary.

s32_bl2_el3.c : Modify mmu table in order to resolve logical-to-physical address mapping failure which is derived from linker change.

With those modification. U-boot shell appeared as follows:

Something weird is that PCIe and eth0 setup fails. SDK directly was given from NXP still has same problem.

3. Are you getting the same behavior without this FIP_MEMORY_OFFSET=0x34300980?

-> FIP_MEMORY_OFFSET has been kept as 0x34300980 on u-boot shell apperance.

ssong · ‎06-08-2022

eth0 functions well.

log on the screen below counfused me.

"eth0: eth_eqosEQOS phy: sgmii fixed link"

phy: sgmii fixed link might be for eth1. It's better to let it go to the next line.

alejandrolozan1 · ‎06-10-2022

Hi,

Even in NXP EVB with the default fip.s32 image the ethernet 1 and pcie fail. This is expected if the SGMII phy is not initialized nor connected to GMAC1 and PCIe is expected to fail in case there aren't any PCIe devices connected so the link works succesfully.

So this behavior is expected.

Saludos,

Alejandro

eddy_bts · ‎06-09-2022

In M7 bootloader which was provided in S32DS, Power_Ip_MC_RGM_ConfigureCore API resets M7_0 Core so that M7 bootloader can't proceed anymore.

Below temporal code has been added in-between not to reset M7_0 core.

Can we the API make M7_0 core not to be reset by the API with the configuration change? Otherwise, some bugs exist in code?

GaryRK · ‎06-15-2022

Hi,

Yes it is possible to configure the Mcu driver to avoid this reset of M7_0 core when the bootloader is running. Here are the steps:

Open the S32 Config Tools Peripheral tool on the bootloader project.
On the left hand side there is the Components view, select Mcu_1.
Then navigate through tabs McuModuleConfiguration -> McuModeSettingConf -> McuPartitionConfiguration -> McuPartition0Config.
Under McuCore0Configuration un-check the box "CM7_0 Under MCU Control".

See below image for reference.

eddy_bts · ‎06-14-2022

Anyone who can answer?