Can't start A53 core with GoldVIP bootloader

[Ben6]

Hi,

I'm using S32G-VNP-RDB2, with software version is GoldVIP_1.5. I'd like to customize the bootloader project and run my M7 app, while running linux on A53 at the same time.

I first tried to follow the step in  GoldVIP-Developer-Guide to reconfigure the bootloader. Rm and all the safety boot modules were removed. The boot source was kept unchanged for testing (default is ATF and CAN-GW). I was able to build and deploy the image to nor-flash, but when boot from flash, UART0 only output BootTimeMeasurement messages, and nothing else.

To verify that boot process was correctly executed, I reconfigured and deployed the bootloader, to load my own M7 App. It seems that M7 could run normally (except that no output on PFE_MAC2).

So my question is, how can I make A core work? 

[Daniel-Aguirre · Accepted solution]

Hi,

There is an Application Note [AN13750 - Enabling Multicore Application on S32G2 using S32G2 Platform Software Integration] which is available under the S32G2 product page (link: S32G2 Safe and Secure Vehicle Network Processor | NXP Semiconductors). This AN explains (to my personal opinion) better how the bootloader can be customized to boot 3 M7's and a A53 running Linux.

This does not use the same bootloader example provided on GoldVIP, uses the one provided in the "Integration Reference Examples" available under the Automotive Software Package Manager or Flexera. Still, if you are looking to boot both M7 and A53, this AN should give you a better start.

Please, let us know.

[Ben6]

Thank you for your reply,

I tried to used the project provided in Integration Reference Examples, and was able to boot A53 and M7 individually (e.g. running ATF with no M7 App bin in flash), but still can't run M7 App and ATF at the same time. 

I believe I ran into the issue mentioned in this document: " S32G Bootloader Customization ", it says that there might be conflict between MCAL configuration of bootloader, ATF and M7 App. Since this document only covered some of the MCAL module (Mcu, Port, etc), I wonder if there are any more detailed description on which peripherals or resources were used by ATF?

Also, I tried to modified the CAN-GW project, by changing the LLCE_CAN controller and relative PortPin configuration (figure shown below), in order to compare with my own M7 App. And I found that some hardware controller would failed to send/receive (e.g. BCAN12), while others (e.g. BCAN6, BCAN14) would work. Are there any possible explanation for this?

[ShenYi]

Hi @Ben6 ,
I believe I ran into the issue mentioned in this document: " S32G Bootloader Customization ", it says that there might be conflict between MCAL configuration of bootloader, ATF and M7 App.
----------Have you solved this problem? I have met the same problem, I would like to know your current situation. Thanks.

[Ben6]

Hi @ShenYi ,

I had get over this problem. Basically, you could use the concept in  this document: "S32G Bootloader Customization" to solve the conflict of shared peripherals. Another thing is, you need to modify your m7 app linker to make sure it won't overlap with ATF/uboot, you might have to disable mpu, I-cache, D-cache as well.

Notice that since the software versions are constantly updating, you'll find most of the document outdated, so you 'll need to investigate your BSP to know the actual configuration. Once the above issue are solved, you should be get things running.

[ShenYi]

Hi,
Thanks for your reply. I have solved this problem today. The reason is the conflict of CAN_PE_CLK between AFT and M7.

[Daniel-Aguirre]

Hi,

As for the specifics of which modules are being used by the ATF, there is no document (to our knowledge) available for this. Still, the AN13750 shows how the u-boot, ATF and Linux are fetched and built, providing the device-tree used by ATF itself. This should have the information you are looking.

For the CAN_GW topic, could you elaborate more on this? How it is that some BCAN's are failing to send/receive messages?

The quick explanation is that they might not be configured properly, but this is just for the information we have at the moment.

We could recommend looking into the S32DS + RTD + LLCE setup, which also has LLCE related examples and could be easier to understand how to setup the usage of different BCAN's inside LLCE. Just remember that S32DS + RTD + LLCE should be compatible one with each other.

Please let us know.

[Ben6]

Hi,

For the CAN-GW project, I tested with the exact same use case demonstrated in the GoldVIP documents, where some scripts (e.g. can-slow-path.sh) are executed on A53 to generated CAN frames passing to M7 and calculate network statics. The only difference is that LLCE CanController_1 changes from BCAN1 to others. When using BCAN12, the networks statics indicated 100% lost frame.  

Since other BCANs are confirmed to work (no lost frames) when testing with the same condition, I don't really think it's a configuration problem. Anyway, Here's some configurations I changed (or confirmed):

    Port: Add PortPins for LLCE_CAN12_TX/RX

    Mcu: no need to change, since all LLCE CAN channels used the same clock source

    Os: no need to change, since all interrupts for LLCE are already configured

Besides, I have already tested RTD + LLCE examples before, all LLCE CAN channels was confirmed to work when running only M7 core. This problem only happens in CAN-GW, so I suspect this has something to do with the integration with A53 side? 

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

There is a limitation known on the LLCE module that says the following [Page 13, LLCE Firmware User Guide, v1.0.4]:

"When using multiple hosts, each of them can have maximum 8 channels assigned, and the allocation must be done in 2 distinct groups: channels 0-7 for Host0 and channels 8-15 for Host1. Each of this split is called "Host Interface" (HIF). This restricted allocation comes from the interrupt routing of the FIFOs used as interface between LLCE firmware and CAN driver, which shares the same interrupt line along 8 FIFOs."

Seems odd that you are able to map without this restriction until arriving to BCAN12, but again, the above is a known limitation of the provided LLCE Firmware.

Please, let us know.