BSPs, cpus, and boards

General
1

Still navigating into the deep waters here, so I thought I’d put a couple of questions I’m working on into the forum in case an ‘old timer’ :slight_smile: wants to chime in.

So I’m developing a BSP for the nrf5340. Its an ARMv8M architecture chip (Cortex M33) which is a beefed up Cortex M4F. The existing ./score/cpu/arm/ code is ARMv7M. I could use that because the M33 is backwards compatible with the ARMv7M stuff but since I will be needing the security stuff my code needs the ARMv8M features. Gcc has compiler (and multilib) support so no issues there. This situation presents me with the question, should I make ./score/cpu/cm33, ./score/cpu/armv8, or add more spice to the arm files to make them work on v8 as well? Those files are already pretty busy with various things and my current choice is to start fresh because I can write code with fewer #ifdefs and its easier to debug. I notice that aarch64 was added rather than shoehorn that into arm so that seems to endorse my current plan.

That raises another question though, when you ‘build RTEMS tools’ you build something like 7/rtems-arm but would I build 7/rtems-cm33 ? I guess this question boils down what the recipe for tools are such that as long as I get the current gcc and binutils for arm I’m going to be able to compile for my CPU.

Any insights into how these are related? If at all? After getting the cpu files sorted I’ll get the nrf5340 bsp files put together. That might answer some questions? Hard to say.

–Chuck

2

Hello Chuck,

the files should already work with ARMv8M. The STM32U5 is also a M33 and I think one of my colleagues or I added the most important defines in the relevant files already. gcc is build with the relevant multilibs. If you build the 7/rtems-arm toolchain using RSB, you should get an arm-rtems7/lib/thumb/cortex-m33 directory. If you add -mcpu=cortex-m33 like in the abi.yml of the STM32U5, you should use these libraries.

Best regards

Christian

3

Thanks, that is a great pointer.

Do you know where you pick up your start.S file? I’ll look at the STM32U5 stuff, the tricky bit is the secure realm stuff which v7 doesn’t know about but v8m (and v8r) do. (oh any my main development machine is currently offline while I replace the SSD and restore from the recent backup).

4

The STM32U5 uses the shared startup code from bsps/arm/shared/start/start.S. For that BSP, no secure monitor or similar was used. It was possible to just ignore most of the secure realm. Do you plan to use Trusted Firmware M? In that case, you most likely will need some adaptions. Maybe you can also re-use some of the code for aarch64 for that.

5

Yes, I’m going to run the Nordic bluetooth stack on the ‘network’ core and it requires booting it into the trusted firmware mode. (Well at least it looks like it does from what I’ve seen when they use it in Zephyr)