Debugging programs in bare-metal S32G-VNP-RDB3

[ricardofranca]

Hello,

As discussed in https://community.nxp.com/t5/S32G/Using-S32K399A-A53-primary-core-in-bare-metal/m-p/2194502#M15372, I am assessing the performance of the S32G399A using its RDB and some custom-made application. While I managed to run some small functions directly over U-Boot, the processor started crashing when I tried to fit a larger application - still, it is just some 300KB of code and data and it certainly uses less than 4KB of stack.

I could run the same application over the U-Boot used in the PowerPC-based T1040D4-RDB, but I have no idea about the problem I am facing when trying to do the same for the S32G-VNP-RDB3 because there is not even a board reset - the "go" command simply never returns.

As I have also recently purchased an LS1028ARDB, I tried the same there and got the same problem, which makes me think that there may be some stack pointer configuration or other aspect inherent to the Cortex-A processors that I should take into account when running my code from U-Boot.

Do you have any insights on how to run "slightly complex" code over U-Boot for these ARM-based processors?

As a friend of mine had a spare ARM20 connector and we have the complete Green Hills environment, I decided to use it with this board. I had some issues, first because the debugger was not being able to halt the processor (which I could do it myself manually), then it was unable to copy the executable code to RAM (neither SRAM nor SDRAM) due to some "memory write error - translation fault, first level". Is there any extra configuration I must do in the board for it to work in the Green Hills environment (which seems to support S32G399A)?

As both questions are part of a single objective of "get S32G running", I am putting them together, but I can split them in two posts if necessary.

Thanks,

Ricardo

[alejandro_e]

Hello @ricardofranca,

Thanks for contacting us again. Regarding the GreenHills part of your question. I am not going to be able to support you with that, I do no have access to GreenHills software nor the debug tools. Please contact GreenHills for support on that topic.

Regarding the u-boot + M7 part of your problem, please share the following details so I can analyze your problem better:

• which u-boot version are you using? or which BSP version are you using as a starting point.
• what is the exact procedure you are using to load the M7 code into u-boot and then load and execute it in the M7 SRAM. Please describe the general Compilation process and commands use in u-boot.

Thanks

[ricardofranca]

Hello @alejandro_e ,

My bad! I forgot to mention that I am trying to use the A53_0 core. For the moment, I do not need any other...

I am using the U-Boot version that came with my board: 2020.04+g6286902c94. I build my code with the Green Hills compiler (without any start files as the environment is already set by U-Boot), upload it to the DDR or SRAM using the U-Boot loadb command, then run it using "go" and the address of my main(). As I cannot really debug anything when deploying code like this, I can only think about some stack-related issue.

As for the Green Hills environment, I managed to get things working (I ran my application in the DDR) but I still have a question that is not dependent on the environment itself: while I can toggle the board LED with simple U-Boot commands by configuring MSCR6 as output buffer (I put the value 0x21_0000 in address 0x4009c258) and then setting or resetting GPDO6 byte (0x4009d305), I suppose there is something I must configure in SIUL2 if I am not relying on U-Boot: my application that ran on Green Hills debugger could write on the addresses above (and neighboring registers were showing consistent values like those I saw in U-Boot), but, still, the LED itself did not toggle. How does U-Boot configure SIUL2? Is the source code of the U-Boot version shipped with this board available?

Thanks,

Ricardo

[alejandro_e]

Hello again @ricardofranca,

I was under the assumption that you were well familiarized with the source code for our BSP. sorry for the misunderstanding, now that I know that, I would recommend porting your application from the green hills to the u-boot source code. You can check all BSP related code in nxp-auto-linux, at the moment the most relevant ones are u-boot and arm-trusted-firmware you will need both to generate a bootable binary. Once you have you can define a new command that runs the application you want, for example, you can check the gpio.c as a base both for a new command and to manipulate the GPIOs, you can download the documentation to know how to build everything in AUTO-SW-PACKAGE-MANAGER:

For example, in BSP44 you will need to check 3.2.2.2 Building the U-Boot bootloader and 3.2.3.2 Building the Linux Kernel, you can do it in a Linux native machine, Linux VM or even in WSL, the latter is the easiest in my opinion, if you decide to do so and you will try the Yocto build, please check the following post Build-NXP-Auto-Linux-Yocto-BSP-on-Windows-using-WSL to avoid any problems with Yocto. 

If you decide to port your code to the U-Boot code, you now can print to the terminal, which you can see in any terminal by connecting a usb cable in J2- UART0 to a computer.

Let me know if you have more questions

[ricardofranca]

Hello,

Thanks for your assistance! I finally had my code running (though I ended up using the Green Hills environment because I was being too clumsy trying to set things up by myself). As I last question, I would like to know how prefetching works in this processor, as I noticed that I was getting the same (extremely fast) execution time using the internal SRAM or the external LPDDR4 - until I inserted hundreds of thousands of NOP instructions before running my benchmark to ensure the L2 cache had no useful information. It would seem the prefetcher was able to prefetch most (or all) of my code even before the first run of my function... Where can I find further information regarding the prefetcher and the L2 cache?

Thanks,

Ricardo

[alejandro_e]

Hello @ricardofranca,

In our manuals we do not share much info regarding the core architecture, this includes the prefetching process. However, you can check section A53 Cluster General Purpose Registers (A53_GPR) of the S32G3 Reference Manual[Rev. 4, 02/2024], and for more detailed information you can check Arm's documentation, for example Arm Cortex-A53 MPCore Processor Technical Reference Manual r0p4. You could also contact Arm's support team in https://developer.arm.com/support-hub.

Let me know if this information was useful