Because address space is mapped in 64KB pages, it was possible for unauthenticated data after the
app .bin to become mapped into the flash cache address space.
This problem is solved by 2 changes:
* "esptool elf2image --secure-pad" will pad the image so that the signature block ends close to the
64KB boundary. Due to alignment constraints it will be 12 bytes too short after signing (but
with flash encryption, these 12 bytes are still encrypted as part of the last block and can't be
arbitrarily changed).
* By default, secure boot now requires all app partitions to be a multiple of 64KB in size.
Makes app image booting more reliable (256-bit rather than 8-bit verification.)
Some measurements, time to boot a 655KB app.bin file and run to app_main() execution.
(All for rev 1 silicon, ie no 340ms spurious WDT delay.)
80MHz QIO mode:
before = 300ms
after = 140ms
40MHz DIO mode:
before = 712ms
after = 577ms
40MHz DIO mode, secure boot enabled
before = 1380ms
after = 934ms
(Secure boot involves two ECC signature verifications (partition table, app) that take approx 300ms each with 80MHz CPU.)
Fixes issue with GPIO 0 being enabled as an output on ESP32D2WD (or when setting SPI pins in efuse)
and not using Quad-I/O modes.
Ref: https://esp32.com/viewtopic.php?f=2&t=2205
Originally marked "Reset with ESP32R0 Windows workaround", but proven to be
necessary on some other platforms as well. This is now integrated into the
default esptool.py reset behaviour.
Closes#305https://github.com/espressif/esp-idf/issues/305
* New "espefuse.py set_flash_voltage" command to easily set a fix
VDD_SDIO regulator voltage (1.8V, 3.3V or disabled).
* Fixes bugs when flashing files with non-4-byte aligned lengths
(doesn't effect esp-idf image files)
* README improvements
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
Angus Gratton