My goal is to have a firmware that can be upgraded on-the-field via ethernet.I have already implemented code that can receive the binary, write it to the second code flash bank and boot from it.
My problem is that, if I understand correctly, what I implemented will only work as long as all future FW releases will never require a change in TrustZone secure/non-secure boundaries, and that I cannot guarantee.Changing the boundaries can only be achieved via SCI, but that requires physical access, which I want to avoid.
I have never worked on an MCU that features TrustZone, I do not need this feature at all.Would it be possible to make my code entirely "non-secure"?That way, I can just set the boundaries once via SCI and then I will never need to change them again.Or, is there any other way I can avoid this issue?
Assuming you are talking about RA6M4/5, the startup state is always "secure" so you can't have entire non-secure state. The need for non-secure RAM comes about because of EDMAC peripheral, which is configured for non-secure operation. You need to allocate EDMAC buffers to a non-secure RAM region. Current RAM assignment is to put those buffers at the end of RAM.
Your current RAM allocation :-
secure + NSC RAM, | non-secure ethernet buffers + leftover RAM
The secure/non-secure RAM partition is at some 8-kbyte boundary. You can move back the boundary by multiples of 8-kbyte to create a
non-secure RAM buffer.
secure + NSC RAM, | non-secure RAM buffer + non-secure ethernet buffers + leftover RAM
You can use non-secure RAM buffers from secure code, or you can expand your ethernet buffers should you need it in the future.
Hopefully this will help cope with changes in system without re-writing the secure/non-secure RAM boundary. The entire code is in secure area for a flat project.
Hello CS Yep,
Many thanks for the insight.
CS Yep said:You can use non-secure RAM buffers from secure code
Does that mean I can just partition the RAM be fully non-secure and the secure code will work anyway?I have tried it already, I have partitioned setting secure and NSC RAM size to 0, I did not notice any issue after a short test.Is there any drawback on this approach?
I have verified that the partition was actually set, here is the output of "rfp-cli" program with "-read-flashoptions" option: Renesas Flash Programmer CLI V1.09 ... Connected to R7FA6M5AG2CBG Reading data from the device ... [Read flash options] ... DLM State: DPL Boundary: 1536,0,8,0,0
Renesas Flash Programmer CLI V1.09
...
Connected to R7FA6M5AG2CBG
Reading data from the device
[Read flash options]
DLM State: DPL
Boundary: 1536,0,8,0,0
If you need to run codes in RAM and all your RAM are non-secure, your codes in RAM will be non-secure code and cannot access any secure peripheral. Would you need run code in RAM in future? MCU comes off factory in linear mode. If you want to change it to dual-bank mode, I think you need to run flash driver and part of that driver need to be executed from RAM (i.e. it has to be secure RAM). It is better to keep some secure RAM.
I verified all the peripheral are set as non-secure, the macro "BSP_TZ_SECURE_BUILD" is set to 0, so the registers "PSAR*" remain to their default values.
About what you said regarding the flash driver, I am indeed using the MCU to dual-bank mode, but I did not encounter issues, am I missing something?
Thank you for your time.
The flash sequencer has its own, special security attribution. Make sure you don't control it from non-secure access(aka codes running on RAM). Your MCU is in secure state, but all peripherals (except FACI) are non-secure. It's the first time we are seeing this. Unfortunately I don't have any clue what will happen down the road, with other tools/RFP, debuggers, DLM transitions etc.,
Hello CS Yep, your support has been very helpful, thank you very much!