...
- Closely following e2studio/FSP
- Project/make files
- S project
- src
- include
- test
- NS project
- src
- include
- test
- Scripts
- Tools
- Docs
3.4
...
Booting
One SDK booting flow supports three statessupports booting for MCU with Trust Zone support or without. In booting, three roles can be supported: Factory (Renesas), OEM/ODM (unsealed), end user (sealed). For MCU with TZ support, the booting processing supports all three roles, each represented by a state:
- Factory (STATE_FACTORY) – Factory mode. MCU runs factory bootloader in S mode. Both secure and non-secure code/data can be read and written. Factory mode can only be entered from unsealed state with factory command and factory password known only to Renesas. Factory state is always exits to seal state with a self-reset.
- Sealed (STATE_SEALED) – Sealed state is where application runs. After reset, factory bootloader quickly check if it should enter the factory state; if not it will immediately transition to sealed state and jumps to the application.
- Unsealed Unsealed (STATE_UNSEALED) – Unsealed state is only entered from the sealed state with unsealed command and customer password. Unsealed state runs in NS mode and supports additional commands.
Figure 2. Privilege states of MCU with TZ support.
For MCU without TZ support, such as CM0+ and RL78, only OEM/ODM role is supported. The booting state transitions look like the below:
- Sealed (STATE_SEALED) – Sealed state is where application runs. After reset, factory bootloader quickly check if it should enter the factory state; if not it will immediately transition to sealed state and jumps to the application.
...
- entered right after reset. This state support basic command set required by the application.
- Unsealed (STATE_UNSEALED) – Unsealed state is only entered from the sealed state with unsealed command and customer password. Unsealed state supports additional commands beyond the basic set.
Note that since there is no TZ support, code/data hiding is not possible, for IP protection Renesas must be the one doing any required firmware customization, and deliver just the compiled binary.
Figure 3. Privilege states of MCU without TZ support.
3.4.1 Top-level pseudo code
Below shows the factory bootloader pseudo code which would run right after reset:
Code Block | ||||
---|---|---|---|---|
| ||||
void factory_bootloader() { uint8_t cmd; uint8_t param[MAX_PARAM_SZ] = {0}; gs_dev_state = gsf_dev_state; if (gs_dev_state == STATE_FACTORY) { flash_write(&gsf_dev_state, STATE_SEALED); while (true) { bool rc = read_cmd(&cmd, param); if (rc == OK) { if (cmd == CMD_RESET) { sys_reset(); } else { rc = process_factory_cmd(cmd, param); } } print error(rc); } } NS_entry(); } |
Note even if TZ is not supported by the MCU, the factor_bootloader() function can still be included, as it will immediately jump to NS_entry() and run the application. See NS_entry() definition below.
The NS_entry() is the non-secure entry function. Customer may optionally to implement customer bootloader() in NS_entry() or before the application code is called:
...
- Introduction
- Pseudo code of motherboard application stack
- Security
- Communication - RTT requires RA4E1 board modification
- Algorithm API - include daughter card detection
- AFE API - multi-daughter cards
6.0 References
ddd