Based on report on forum here:
https://esp32.com/viewtopic.php?f=13&t=6382&p=27514
Previous versions were much more relaxed about what could be in the partition
table, erroring out avoids unexpected changes on upgrade like different
partition offsets.
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.
Allows you to move the partition table, it gives more space for the bootloader.
Added a new utility - parttool.py. This utility can search for the offset and/or size of the partitions by name and type/subtype. Use for getting APP_OFFSET and PHY_DATA_OFFSET.
The linker(esp32.bootloader.ld) made changes that allow you to write a custom bootloader code more.
TW14125
Currently paritions marked as encrypted by gen_esp32part.py are not
recognized as such and encrypted writes don't work.
This is part of espressif/esp-idf#253
The following issues mentioned during MR!341 review were fixed:
1) Core dump test application description
2) Usage of CONFIG_ESP32_ENABLE_COREDUMP_TO_FLASH and CONFIG_ESP32_ENABLE_COREDUMP_TO_UART
3) FLASH_GUARD_START macro usage is fixed in flash API
4) Core dump module logging facility
5) cache util functions doc updated
6) interactive delay before print core dump to uart
7) core dump partion support in build system
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
