topic Re: How to boot S32G2 - M7 cores from external Flash ? in S32G

How to boot S32G2 - M7 cores from external Flash ?

SSyb — Tue, 14 Feb 2023 08:08:24 GMT

Dear all,
I am working with an S32G274A Board (the RDB2), my scope is currently the
M7-cores 0 and 1 only. I come from a more traditional Microcontroller world (my customers also),
we intend to let the target (i.e. the M7_0 and M7_1) boot from the external Macronix Flash.
And we would like to keep things simple for the moment (and ignore the A53s if possible)
The application is a classic AUTOSAR target application stack (including RTD MCAL and OS), it works fine when loading froma Lauterbacj debugger.

I have been reading the chapters on the poot process and Reset system in the reference manual, and some application notes
(AN12422, AN13185).
Maybe I am lost in details, what I am still missing is the big picture:

What is the easiest way to boot the M7_0 and M7_1 from the external Macronix QSPI flash ?
i.e.
- Can this be done without an extra boot loader ? (I would prefer to not use one for the moment)
- can I link the .text segment to the flash and execute from there (what is the address area in that case: the AHB buffer ?)
- or is it easier to link everything to the SRAM ? in that case: who will copy the .text segment to the SRAM ? the S32G2 BootROM ? or the application startup code has to take care of this ?

In case a Bootloader like UBOOT is unavoidable (I have not worked with it yes):
- does the Bootloadert run on the M7 or the A53 ?
- how does the boot configuration come into play ? I do not have a file system in the external QSPI flash.

any hints welcome

best regards,
Stefan

Re: How to boot S32G2 - M7 cores from external Flash ?

SSyb — Tue, 14 Feb 2023 08:48:31 GMT

B.t.w. I am using the Greenhills ARM compiler and a customer build environment (Cmake)

Re: How to boot S32G2 - M7 cores from external Flash ?

Daniel-Aguirre — Tue, 14 Feb 2023 22:33:57 GMT

Hi,

We may recommend looking into the following community thread, were something similar is being talked about:

The Boot Flow for S32G - NXP Community

As for your questions, below will be some comments on this:

- Can this be done without an extra boot loader ? (I would prefer to not use one for the moment)

The multicore boot from an external interface (NOR Flash in this case) is not possible without an application bootloader that fetches the related code and starts the needed cores. We can recommend looking into AN13750 available on the S32G2 product page (link: S32G2 Safe and Secure Vehicle Network Processor | NXP Semiconductors). This application note talks about a multicore application and the steps needed to replicate the application.

- can I link the .text segment to the flash and execute from there (what is the address area in that case: the AHB buffer ?)

At this moment, there is no XIP integration/example for S32G2. The Reference Manual talks about this feature, but not much information is given.

- or is it easier to link everything to the SRAM ? in that case: who will copy the .text segment to the SRAM ? the S32G2 BootROM ? or the application startup code has to take care of this ?

It depends on what code you are trying to fetch. The code that is fetched by S32G2 BootROM (which is executed on the M7_0 core, this cannot be changed) is the one we referred to as "Application Bootloader" which is the one addressed on the IVT itself.

After the "Application Bootloader" is fetched, S32G2 BootROM passes the control over to the respective Boot Target (which can be either M7_0 or A53_0) and then the Boot Target executes the "Application Bootloader" and will do as the developer described in the code.

As a summary:

- For a multicore application, a bootloader is needed. NXP provides one, as described in the AN13750.

- S32G BootROM fetches the code (named "Application Bootloader") addressed on the IVT itself. This is done with M7_0

- This "Application Bootloader" will be executed on the Boot Target (M7_0 or A53_0) and will be the one responsible for fetching the remaining code and configuring/starting the other available cores on the platform.

For the last questions, u-boot is not specifically needed for M7's multicore application.

Please, let us know.

Re: How to boot S32G2 - M7 cores from external Flash ?

SSyb — Wed, 15 Feb 2023 07:56:52 GMT

Hi Daniel-Aguirre,

thanks for the information and the hints to the material. I will read through this and digest. Will come back when I have more questions to this.
best regards,
Stefan

Re: How to boot S32G2 - M7 cores from external Flash ?

Daniel-Aguirre — Wed, 15 Feb 2023 15:32:11 GMT

Thanks,

Please, let us know.

Re: How to boot S32G2 - M7 cores from external Flash ?

SSyb — Wed, 15 Feb 2023 15:53:39 GMT

Hi Daniel-Aguirre,

As you suggested, I am looking into the NXP Bootloader now, and see whether I can adapt the configuration for my needs (from: Integration_Reference_Examples_S32G2_2022_06)

I can build the Bootloader already. When looking into AN13750 and in the Tresos configuration, I have the following questions to sharpen my understanding

Can I assume the Integration_Reference_Examples_S32G2_2022_06 MCAL configuration of the Bootloader is fit for the RDB2 board ?

The bootloader project contains configuration for flash sectors in the MCAL Fls module:

Are they relevant for the bootloader ? (see screenshot) Background: in my user application, I am using a different area of the Flash for non-volatile data. this requires different flash sectors (in a different address area of the flash). But my application code falls Fls_Init again later, so I think these two phases are different worlds, the bootloader has its Flash blocks (and the flash regions where the images are stored), the user application uses another flash region, both don't interfere.

in General: When switching to the Application image (from the bootloader), I assume that all MCAL configuration can be done from scratch - correct ? Can the application image MCAL use a different clock configuration Port configuration, Fls config and QSPI configuration than the bootloader ? Or do the needs of the final App image have to be considered/anticipated in the bootloader MCAL already ? Background: in my user application (which is a proper AUTOSAR stack), I am calling all the MCAL init functions again (Fls_Init, Mcu_Init, Port_Init etc...), with an MCAL configuration that is part of my user application project.

what requirements to the startup code of the user application are then left ? initialize the RAM ?

thanks a lot and best regards,

Stefan

Re: How to boot S32G2 - M7 cores from external Flash ?

Daniel-Aguirre — Wed, 15 Feb 2023 22:26:42 GMT

Hi,

We have the following comments regarding your questions:

Can I assume the Integration_Reference_Examples_S32G2_2022_06 MCAL configuration of the Bootloader is fit for the RDB2 board?

This should be true, given that RDB2 is a development platform that integrates S32G274A in it. It has both the external NOR Flash from Macronix and the SD slot required for Linux.

The bootloader project contains configuration for flash sectors in the MCAL Fls module:

Are they relevant for the bootloader?

Given that the AN13750 does not talk about the possibility of disabling them and that the Fls module should be the one used to fetch the code from the external NOR Flash, we assume this is necessary.

In General: When switching to the Application image (from the bootloader), I assume that all MCAL configuration can be done from scratch - correct ? Can the application image MCAL use a different clock configuration Port configuration, Fls config and QSPI configuration than the bootloader ? Or do the needs of the final App image have to be considered/anticipated in the bootloader MCAL already ?

The applications that are loaded into the M7 cores do their initialization as if there was none done before. We can assume that you can configure your application as needed not worrying about the bootloader, following the AN13750 steps.

On this topic, even BootROM has its own routine implemented, meaning that the bootloader may be re-initializing something that was already initialized.

what requirements to the startup code of the user application are then left ? initialize the RAM ?

If the initialization that the bootloader has do complies with what the customer is doing, the customer could jump directly to the application. Still, this may cause difficulties trying to debug a problem if there is no configuration code on the application or even can cause non-defined behavior.

For myself, the user application should be configured as if nothing was done prior to it, just beware of the shared modules between cores.

Please, let us know if this information was helpful or not.

Re: How to boot S32G2 - M7 cores from external Flash ?

SSyb — Tue, 21 Feb 2023 10:04:18 GMT

Ok, so I can now boot my classic AUTOSAR image from external Flash on cores M7_0 and M7_1, with the help of the NXP example Bootloader from the Integration_Reference_Examples_S32G2_2022_06 bundle.

I have a questions / request for confirmation though that the AN13750 and the user guide did not address, as far as I could see:

Same image on both cores: it is common to an AUTOSAR classic stack that it can handle multiple cores (i.e. OS works in multicore-style, core 0 is master, core 1 slave etc.). but there is only one image. some parts of the code use the core identity register (through the Os_GetCoreId() API) to decide whether or not to run. I feel such use case is not addressed in the Bootloader. What I had to do now is to

create a boot configurations (OK)
create 2 boot sources
every boot source has its own image container, but in both cases the image is the same (starts at the same address in Flash, loaded to the same address in SRAM)

I had to do this because

when trying with the same boot source I get a compilation error later
I found out that I have to given different addresses in the "Reset_Handler" address field, otherwise it does not work. the slave core is started at the address of it's int_vec_table (that seems to be written in to the MC_ME address register), the master core gets only the instruction poiner moved by the boot loader -> to the real Reset_Handler function.

Consequence: I think the DMA transfer is done twice for the same data, which increases the boot time I guess.

Questions:

Is it correct that the two boot sources are supposed to have different start addresses even though it is the same image (i.e. the master core M7_0, which is also the core where the Bootloader runs, needs to jump to the Reset_Handler, whereas the the slave core M7_1 start address is used to put into the MC_ME core 1 ADDR register and (so it seems) only works when giving it the interrupt vector table address ?
Is there a way to avoid that the same Flash mage is loaded to the same SRAM area twice ?

I think after the confirmation we can close this thread.

best regards,

Stefan