This commit allows the configuration of an absolute path for the custom
partitions.csv file via the Kconfig option CONFIG_PARTITION_TABLE_CUSTOM_FILENAME.
Closes https://github.com/espressif/esp-idf/issues/12264
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
This fixes the issue that "idf.py partition-table" had to be run
manually in order for the partition table to be generated, when
building for linux target.
All the partition handling API functions and data-types were moved from the 'spi_flash' component to the new one named 'esp_partition'. See Storage 5.x migration guide for more details
This adds a warning in cases where the smallest partition is nearly full.
A test with a specially crafted partition table is created for the smallest partition warning.
If the threshold or the template itself change, change the factory app partition size as well.
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).
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
handling (only when nvs encryption is enabled)
* NVS Encryption will now be turned on by default with flash encryption
* Updated the flash encryption example to shocase NVS encryption
along with information on how to configure and use NVS encryption
* Updated respective test case
* Added two partition tables for NVS encryption
i) Table 1- Single factory app, no OTA, encrypted NVS
ii) Table 2- Factory app, Two OTA, encrypted NVS
- Add the function esptool_py_flash_to_partition to flash a binary
image to a named partition. If encryption is enabled, this function
will also determine if the partition needs to be encrypted or not
according the its type, subtype and flag in the CSV file (if any).
- Use idf.py encrypted-flash will now flash both encrypted and
non-encrypted file if any (spiffs for example) using esptool.py's
--encrypt-files option.
Closes IDF-2387
Relates to IDF-723
Relates to IDF-2231
Previous versions of PartitionType only required type and subtype as
arguments for the constructor. Make the new part_list argument optional to
keep backwards compatibilty
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
* partition api changed from spi_flash* API to
esp_partition* API and is abstracted as a C++
interface.
* The old nvs encryption is still possible
* changed default unit test app partition table
* Partitions coming from esp_partition API are
checked for generic flash encryption. If yes,
an error is returned since generic flash
encryption isn't compatible with nvs
encryption
* esp32, esp32s2 tests don't require nvs_flash
but mbedtls now
Closes IDF-1340
Closes IDF-858
