EFUSE User Guide
Overview
eFuse (electronic fuse) is a type of One-Time Programmable (OTP) non-volatile memory. It is widely used in chips to permanently store critical information such as device identification, configuration parameters, security keys, and debug permissions.
How to Use eFuse
To enable eFuse, call
bk_efuse_driver_init().To read data from a specific eFuse address, call
bk_efuse_read_byte(addr, data).To write data to a specific eFuse address, call
bk_efuse_write_byte(addr, data).
Note
If the CONFIG_EFUSE macro is set to y, the system will initialize the eFuse module during the driver initialization phase. Once the eFuse module is powered, you can access its addresses through specific functions.
Note
If you need to write eFuse keys from the upper layer using the BKFIL tool, please refer to the OTP/EFUSE Configuration section in the SMP Development Framework.
eFuse Bit Definitions
The EFUSE contains 4x8, a total of 32 bits, with each bit having different meanings. They can be configured through BKFIL.
Index |
Name |
Description |
|---|---|---|
0 1 2 3 4 5 6 7 8~19 20 21 22 23 24~28 29 30 31 |
Security Boot Enable Security Boot Debug Mode Fast Boot Disable Boot Mode Security Boot Clock Select Random Delay Enable Direct Jump Enable Security Boot Critical Error Reserved Attack NMI Enable SPI to AHB Disable Auto Reset Enable [0] Auto Reset Enable [1] Reserved Flash AES Enable SPI Download Disable Reserved |
0: Security boot disabled; 1: Security boot enabled. 0: Enable security boot debug info; 1: Disable security boot debug info. 0: Enable fast boot; 1: Disable fast boot. 0: Traditional download mode; 1: Security boot mode. 0: Use XTAL clock for security boot; 1: Use PLL for security boot. 0: Random delay disabled; 1: Random delay enabled. 0: Disable direct jump in security boot; 1: Enable direct jump in security boot. 0: Do not suppress critical error messages in security boot; 1: Suppress critical error messages. Reserved. 0: No NMI on attack detection; 1: Trigger NMI on attack detection. 0: SPI to AHB path enabled; 1: SPI to AHB path disabled. Auto-reset on temperature/voltage anomalies. Auto-reset on temperature/voltage anomalies. Reserved. 0: Flash AES encryption disabled; 1: Flash AES encryption enabled. 0: SPI download enabled; 1: SPI download disabled. Reserved. |
BIT(0) - Security Boot Enable
Two bits in EFUSE are related to enabling security boot:
BIT(3)- Boot Mode: sets the boot mode.0indicates traditional download mode (UART download supported),1indicates security boot mode. Security boot must also be enabled viaBIT(0)after selecting security boot mode.
BIT(0)- Enables security boot. Effective only whenBIT(3)is set to1.
When BIT(0) is set to 0, security boot is disabled. In this case, BL1 considers the public key in the IMAGE valid and does not compare it with the OTP public key hash; it only performs IMAGE integrity verification. Thus, the system can still boot even if the OTP public key hash is not configured.
When BIT(0) is set to 1, security boot is enabled and the OTP public key hash must be configured, otherwise the system will fail to boot.
BIT(1) - Security Boot Debug Mode
BL1 defines two levels of debug messages to help users locate issues, controlled by EFUSE BIT(1)/BIT(7). BIT(1) controls normal debug messages; BIT(7) controls critical errors.
Normal debug messages include process logs in addition to error messages.
Critical errors refer to issues that cause BL1 boot failure. Currently supported critical errors in BL1 include:
Error Code |
Description |
|---|---|
0x1 0x2 0x3 0x11 0x12 0x13 0x14 0x15 0x16 0x21 0x22 0x23 0x1xxx 0x8yyyyyyy |
EFUSE read error 1 EFUSE read error 2 FLASH read error 1 CPU Exception NMI CPU Exception MemManage CPU Exception HardFault CPU Exception BusFault CPU Exception UserFault CPU Exception SecurityFault OTP is empty Public key is empty Jump BIN verification failed OTP read failure Signature verification failed |
Where xxx indicates the OTP offset, and yyyyyyy indicates the specific point of verification failure.
During critical error reporting, only the error code will be printed, e.g., “E16” indicates a CPU SecurityFault exception.
Note
When critical errors are enabled, BL1 does not initialize the UART during security boot, unless an unrecoverable critical error occurs, in which case UART will be initialized to print the error. Therefore, enabling critical errors does not affect normal boot functionality nor cause security risks.
Important
During the development phase, especially before successfully configuring security boot on any board, it is recommended to enable normal debug logs to obtain more debug information. Once familiar with security boot configuration or during mass production, normal logs should be disabled. However, critical errors are recommended to remain enabled even in production.
BIT(2) - Fast Boot Disable
BIT(2) controls the fast boot feature. 0 enables fast boot; 1 disables it.
Fast boot controls the system wakeup flow from deep sleep. When enabled, the system skips security boot after waking from deep sleep and directly jumps to the application. When disabled, the system performs a full security boot similar to a power-on reset.
Important
Fast boot improves startup speed but reduces security. Disabling fast boot improves security but increases startup time. Applications should choose based on actual requirements.
BIT(3) - Boot Mode
Please refer to BIT0.
BIT(4) - Security Boot Clock Select
BIT(4) enables high-frequency mode for security boot. 0 uses XTAL (typically 26 MHz) as the clock source for CPU and FLASH. 1 enables PLL for high-frequency mode. High-frequency mode improves security boot performance and is recommended for performance-sensitive applications.
BIT(5) - Random Delay Enable
BIT(5) enables random delays. 0 disables random delay; 1 enables it. When enabled, BL1 inserts random delays before calling critical functions to mitigate fault injection attacks.
Note
Enabling random delay increases security boot time. Unless fault injection protection is a high priority, enabling this feature is generally not recommended.
BIT(6) - Direct Jump
BIT(6) configures the jump method after signature verification in BL1. 0 indicates indirect jump; 1 indicates direct jump.
With indirect jump, BL1 jumps to an intermediate BIN after verification, and the intermediate BIN then jumps to the target IMAGE. With direct jump, BL1 jumps directly to the verified IMAGE after signature verification.
Note
In indirect jump mode, the intermediate BIN is also included in the signature verification, ensuring security.
BIT(7) - Security Boot Critical Error
Please refer to BIT1.
BIT(20) - Attack NMI
BIT(20) configures whether to trigger an NMI (Non-Maskable Interrupt) when a fault injection attack is detected. 0 disables hardware-level attack detection; 1 enables it and triggers an NMI upon attack detection.
Note
For applications that require enhanced protection against fault injection attacks, it is recommended to enable this feature.
BIT(29) - Flash AES Enable
BIT(29) enables Flash AES encryption. 0 disables Flash AES; 1 enables Flash AES encryption.
BIT(30) - SPI Download Disable
Controls whether SPI download is allowed. 0 enables SPI download; 1 disables it.
Important
To avoid security risks, SPI download should be disabled in production firmware. However, during development, before successfully deploying security boot, it is advisable to keep SPI download enabled so that firmware can still be flashed via SPI if security boot configuration fails. Otherwise, a failed security boot configuration could result in an unrecoverable bricked device.