Flash encryption support
Flash encryption support in build system, tooling
To come in future MR:
* On-device key generation on first boot (for production devices), need to finalise testing of bootloader entropy seeding.
* spi_flash_encrypted_write to support non-32-byte block writes (at least optionally.)
* I think a lot of the bootloader_support component can possibly be rolled into "spiflash" and other components, to use a common API.
See merge request !240
- ROM function uart_tx_wait_idle may have a bug which causes the function to return before the final character is fully transmitted.
This replaces uart_tx_wait_idle declaration with a static inline definition which fixes the issue.
- Also replaces the use of uart_tx_flush with uart_tx_wait_idle in esp_restart, to remove garbage in console output on restart.
- rtc_printf is temporary replaced with a no-op, pending a new release of librtc.a. Current release assumes that UART0 is used for output,
and switches UART0 baud rate while doing frequency changes and printing some log output. This doesn’t work if a different UART is used for output.
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
SHA acceleration integrated to mbedTLS incl. TLS sessions
Uses hardware SHA acceleration where available, fails over to software where not available.
Ref TW7112
See merge request !232
spi_flash_erase_range: Allow for 32KB blocks not 64KB blocks
SPI flash hardware sends 52h command, which is a 32KB erase.
There is a matching bug in the ROM SPIEraseArea code, unless
flashchip->block_size is modified first.
See merge request !249
SPI flash hardware sends 52h command, which is a 32KB erase.
There is a matching bug in the ROM SPIEraseArea code, unless
flashchip->block_size is modified first.
SHA hardware allows each of SHA1, SHA256, SHA384&SHA512 to calculate digests
concurrently.
Currently incompatible with AES acceleration due to a hardware reset problem.
Ref TW7111.
We reserve 4KB Slow RTC memory to save RF calibation result and BT NVS data.
If not all these Slow RTC momory Blocks are used, we will open the other parts.
App can contain a stub program resident in RTC fast memory. Bootloader
will load the stub on initial boot. If the device wakes from deep sleep,
the stub is run immediately (before any other data is loaded, etc.)
To implement a custom wake stub, implement a function in your program:
```
void RTC_IRAM_ATTR esp_wake_deep_sleep(void)
{
esp_default_wake_deep_sleep();
// other wake logic
}
```
... and it will replace the default implementation.
1. timer reg file for both time group 0 and time group 1, not only timer group 0
2. fix bug that io mux header file mismatch with chip
3. fix bug that some BASE address not correct
4. add some static function to eagle.fpga32.rom.addr.v7.ld
5. add interrupts usage table
6. add some comments for rom code functions
found small mistake in it
we have:
PROVIDE ( ets_aes_crypt = 0x4005c9b8 );
PROVIDE ( ets_aes_disable = 0x4005c8f8 );
PROVIDE ( ets_aes_enable = 0x4005c8cc );
PROVIDE ( ets_aes_set_endian = 0x4005c928 );
PROVIDE ( ets_aes_setkey_dec = 0x4005c994 );
PROVIDE ( ets_aes_setkey_enc = 0x4005c97c );
Signed-off-by: Ivan Grokhotkov <ivan@espressif.com>
