The size of partition of type APP should be multiple of 4 KB. Partition
generation tool now make this as a mandatory requirement. This is
minimum flash erase size. If the size of the APP type partition is not
aligned to 4 KB then the last erase operation could go beyond the allocated
partition and hence may fail. This issue would only be observed when the
firmware size grows very close to the allocated partition size, and hence
causing the OTA update to fail.
For already deployed devices on-field with the size of APP partition not
aligned to flash sector boundary, it is best to ensure that firmware
size always remains within the lower 4 KB boundary of the total
allocated space. While migrating to ESP-IDF 5.3 release, partition table
for an existing project can be adjusted accordingly for the build to
succeed.
Found during discussion in https://github.com/espressif/esp-idf/pull/12460
For Secure Boot v2 case, unsigned image is first padded to next 64K
aligned boundary and then a signature block of 4K gets appended. Thus
an app partition whose size is 4K aligned should be allowed here.
For Secure Boot v1 case, app partition size must be 64K aligned as the
signature block lies at the very end of 64K boundary.
Relevant:
57b601ab7f
change: alignment for data partitions is now 4kB instead of 4B
remove: STRICT_DATA_ALIGNMENT variable
remove: warning tests for misaligned partitions
add: assertion test for misaligned partitions
add: breaking change documentation
ESP32-S2 and ESP32-S3
supports up to 1 GB of external flash and RAM
add support for
- 32MB
- 64MB
- 128MB ( example NOR spiFLASH 1G-BIT W25Q01JVZEIQ Winbond 0xEF 0x40 0x21 )
Merges https://github.com/espressif/esp-idf/pull/7688
Signed-off-by: Ivan Grokhotkov <ivan@espressif.com>
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
