ESP-IDF Partition Table support #1676
Comments
|
Currently in progress at https://github.com/mikee47/Sming/tree/feature/partition-tables |
slaff
pushed a commit
that referenced
this issue
Feb 8, 2021
!!! WARNING: BREAKING CHANGE !!! SPI_SIZE and DISABLE_SPIFFS directives are removed! If you have an application that is using spiffs make sure to add the following line in your component.mk and remove the `DISABLE_SPIFFS` directive, if present. ``` HWCONFIG := spiffs ``` If your application is not using spiffs then just remove the `DISABLE_SPIFFS` directive. For more information take a look at the [migration document](https://sming.readthedocs.io/en/feature-partition-tables/upgrading/4.2-4.3.html). More information about the changes can be seen below: ========================================== Implement class-based API for Sming with support for all architectures. See #1676 for discussion. Summary of changes: * Create new `Storage` component and port low-level Esp32 partition support * Use `gen_esp32part.py` tool as basis for new `hwconfig.py` tool. Integrate into build system. Add new targets. * Implement a C++ API. `Partition::SubType::App` and `Partition::SubType::Data` are strong enums used to identify all the standard types, but the base API still uses type/subtype so custom types can be accommodated. * Revise esp8266 sector layout - see updated documentation. This places all the critical information at the start of flash, whereas previously it was at the end. This avoids issues where flash size is set incorrectly. * Custom `sysParam` data partition sub-type used for esp8266 system parameters and RF calibration data. * Add support for 'external' devices (e.g. SPIRAM, supplementary flash, EEPROM, etc.) using a custom `Storage` partition type. Applications register a `Storage::Device` object implementation with the Partition API to register these external devices with a C++ interface for them. * Disentangle SPIFFS from rBoot - OTA upgrading uses partition API. * Drive SPIFFS image creation from partition table entries - more flexible, multiple images. * Generate build variables directly from hardware config file (see `out/.../hwconfig.mk`). Preserve existing build variables where possible, document changes. * Document hardware configuration with schema and incorporate validation. This can assist with fixing malformed configurations and supplements checks included in the partition tool. * Add `Basic_Storage` sample to more thoroughly demonstrate usage * Update documentation * Test (HostTests) on all arches * Remove `DISABLE_SPIFFS`, `SPI_SIZE` and `SPIFF_SIZE` build variables from all samples, including those in submodules. * Include samples and tests within submodules to CI * Add check to ensure image size will fit within partition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Further to #1333 porting Sming to Esp32 (and other platforms) the next roadblock we're likely to run into is the use of partition tables. This is an ESP-IDF feature, provided for the Esp32 and Esp8266 RTOS platforms. See Here for an overview.
Instead of accessing flash memory directly (e.g. using
flashmem_read), a module/component (such as SPIFFS) uses the Partition API (e.g.esp_partition_read). It prevents inadvertent access to other areas of flash (configuration, application, etc.). It also offers proper modular support, so an application could have multiple SPIFFS partitions, etc. if required. Custom flash partitions can be defined for other uses.As such partitions offer significant benefits for ease of use, flexibility, modularisation and customisation for applications so should form a core part of the Sming framework.
Adopting this mechanism is a pre-requisite for Esp32 support, and opens the door for easy adoption of other features like nvs_flash.
I've opened this Issue so we can explore exactly how this will work for Sming, and how it can support user projects.
Proposal
At present there is no unified way to describe the flash partition layout for Sming, instead relying on various pre-compiler definitions to set addresses.
What I propose is implementing/updating the following components for the Esp8266 platform, using the esp_partition API instead of #defined values. Reference code is available in the Esp32 IDF and Esp8266 RTOS.
parttool.py) for creating the binary partition table image from a .csv filespi_flash_read()is equivalent toflashmem_read()as it takes care of alignment issues.spiffsgen.pyinstead ofspiffyto provide more flexible building options. Flash memory access is via esp_partition_' calls instead of direct flash access (partitions always at offset 0).rboot-overrides.cremoved, separated completely from spiffsPartition support was added in non-OS SDK V3.0 but is more basic than ESP-IDF and uses a different API. See README.md. We'd revise the startup code to build the required table for
system_partition_table_regist()using the esp_partition API. Earlier SDK versions should not require any special consideration.Application building
RBOOT_SPIFFS_0andRBOOT_SPIFFS_1would no longer be used. (The implication is that SPIFFS_0 is associated with ROM0, and SPIFFS_1 with ROM1, but looking atrboot-overrides.cit appears to use SPIFFS_0 if defined and ignore the other.)parttool.py. The partition table could maybe share the rboot boot sector, or we'd reserve a space elsewhere for it.The text was updated successfully, but these errors were encountered: