topic Re: S32R45 M7 bootloader downloads u-boot image from flash and activates A53 in Other NXP Products

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

ssong — Tue, 24 May 2022 06:43:38 GMT

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

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

GaryRK — Tue, 24 May 2022 14:35:20 GMT

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.

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

ssong — Thu, 26 May 2022 09:25:15 GMT

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

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

GaryRK — Thu, 26 May 2022 17:26:51 GMT

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.

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

ssong — Fri, 27 May 2022 08:49:11 GMT

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?

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

ssong — Mon, 30 May 2022 08:34:57 GMT

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

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

alejandrolozan1 — Mon, 30 May 2022 17:40:22 GMT

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

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

ssong — Fri, 03 Jun 2022 01:30:14 GMT

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?

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

alejandrolozan1 — Fri, 03 Jun 2022 12:47:17 GMT

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

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

ssong — Tue, 07 Jun 2022 09:37:31 GMT

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?

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

alejandrolozan1 — Wed, 08 Jun 2022 16:49:35 GMT

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

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

ssong — Thu, 09 Jun 2022 01:40:01 GMT

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.

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

ssong — Thu, 09 Jun 2022 05:16:04 GMT

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.

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

eddy_bts — Fri, 10 Jun 2022 06:16:18 GMT

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?

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

eddy_bts — Fri, 10 Jun 2022 07:30:04 GMT

Another question is that:

When we build ATF, we couldn't find a was to change fip image's load address.

It seems to be fixed as 0x34300980 as below. That's why we add FIP_MEMORY_OFFSET with 0x34300980.

Can we change this address? Entry point might change accordingly.

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

alejandrolozan1 — Fri, 10 Jun 2022 16:30:42 GMT

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

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

alejandrolozan1 — Fri, 10 Jun 2022 18:27:51 GMT

Hi,

The load address is calculated depending on the size of dtb and a fip header (dummy_fip file). The image is built in the next way:

DUMYY_FIP_HEADER: Load address

DTB: BL2 address - DTB size

BL2 start and entry point at 0x3430_2000

Saludos,

Alejandro

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

eddy_bts — Wed, 15 Jun 2022 01:50:57 GMT

Anyone who can answer?

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

GaryRK — Wed, 15 Jun 2022 09:10:02 GMT

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.

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

ZhiguoZhong — Fri, 28 Oct 2022 07:01:41 GMT

Hello,

Have you successfully customized these two addresses?

About Load address and Entry point in ATF.

I have no idea about Load address...