If a partition offset is not aligned to 4 kB, erase operations will
fail, even if they are aligned to 4 kB relative to the partition
start. This is because the underlying esp_flash_erase_range function
only works when the address is aligned to 4 kB.
Not making this an error for now, since applications might be using
read-only non-4kB aligned partitions, which still work fine.
Will change this behavior in IDF 5.0, requiring 4 kB alignment for all
partitions.
Closes https://github.com/espressif/esp-idf/issues/7295
Closes https://github.com/espressif/esp-idf/issues/7350
...only. Previously this check was done for both app and data
partitions. While checking that data partition size is aligned is
a _good thing_, the check would only occur when secure boot was on.
It was when in the partition table there is a partition with type="data" and suptype=""(empty),
in this case type=1, suptype=0. It is similar to otadata partition.
This commit fixes it, now it will handle it as type=1, suptype=6 (ESP_PARTITION_SUBTYPE_DATA_UNDEFINED).
A manufactory tool needs to retrieve info about partitions. With a new flag - "--part_list" we can get a list of partitions with the same type/subtype and easily iterate by it.
- name and flag arguments
- added flag "--part_list" to get a list of partitions with the same type/subtype
- save prev behavior of the get_partition_info command (return the only first item)
- added host test
Added:
* set a secure version in app/bootloader.
* description anti-rollback to ota part
* emulate the secure_version write and read operations
* efuse_em partition.
* a description about a rollback for native_ota_example.
Closes: TW26335
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
