cpu/esp32: configurable linker scripts #19077
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
Area: cpu
gschorcht
added
Type: enhancement
gschorcht
changed the title
gschorcht
force-pushed
the
cpu/esp32/configurable_linker_scripts
branch
3 times, most recently
from
53d6dd1 to
c82e194
Compare
The additional dependency of the ELFFILE variable on a LD_SCRIPTS variable allows to define rules for the generation of the used ld files from configurable LD templates.
Using the vendor `memory.ld.in` instead of a static `memory.ld`, from which the actual used `memory.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Using `sectoins.ld.in` instead of a static `sections.ld`, from which the actual used `sections.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom section layout.
gschorcht
force-pushed
the
cpu/esp32/configurable_linker_scripts
branch
from
c82e194 to
5b4a88a
Compare
gschorcht
force-pushed
the
cpu/esp32/configurable_linker_scripts
branch
2 times, most recently
from
7db1bfb to
590cb82
Compare
gschorcht
force-pushed
the
cpu/esp32/configurable_linker_scripts
branch
from
590cb82 to
8381cd3
Compare
|
Build succeeded! And happy new year! 🎉 |
|
@benpicco Thanks for reviewing and merging. |
bors bot
added a commit
that referenced
this pull request
Jan 18, 2023
19079: cpu/esp32: add periph_flashpage support r=kaspar030 a=gschorcht ### Contribution description This PR provides the `periph_flashpage` support for ESP32x SoCs. For byte-aligned read access to constant data in the flash, the MMU of all ESP32x SoCs allows to map a certain number of 64 kByte pages of the flash into the data address space of the CPU. This address space is called DROM. Normally the whole DROM address space is assigned to the section `.rodata`. The default flash layout used by all ESP32x SoCs is: | Address in Flash | Content | |:-----------------------|:-----------| | `0x0000` or `0x1000` | bootloader | | `0x8000` | parition table | | `0x9000` | `nvs` parition with WiFi data | | `0xf000` | `phy_init` partition with RF data | | `0x10000` | `factory` partition with the app image | The factory partition consists of a number of 64 kByte pages for the sections `.text`, `.rodata`, `.bss` and others. The `.text` and `rodata` sections are page-aligned and are simply mapped into the instruction address space (IROM) and the data address space (DROM), respectively. All other sections are loaded into RAM. If the `periph_flashpage` module is used, the `periph_flashpage` driver - decreases the size of the `.rodata` section in DROM address space by `CONFIG_ESP_FLASHPAGE_CAPACITY`, - adds a section `.flashpage.writable` of size `CONFIG_ESP_FLASHPAGE_CAPACITY` at the end of DROM address space that is mapped into data address space of the CPU, - reserves a region of size `CONFIG_ESP_FLASHPAGE_CAPACITY` starting from `0x10000` in front of the image partition `factory` and - moves the image partition `factory` by `CONFIG_ESP_FLASHPAGE_CAPACITY` to address `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY`. The new flash layout is then: | Address in Flash | Content | |:-----------------------|:-----------| | `0x0000` or `0x1000` | bootloader | | `0x8000` | parition table | | `0x9000` | `nvs` parition with WiFi data | | `0xf000` | `phy_init` partition with RF data | | `0x10000` | flashpage region | | `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY` | `factory` partition with the app image | This guarantees that the flash pages are not overwritten if a new app image with changed size is flashed. `CONFIG_ESP_FLASHPAGE_CAPACITY` has to be a multiple of 64 kBytes. ~The PR includes PR #19077 and PR #19078 for the moment to be compilable.~ ### Testing procedure The following tests should pass. ``` USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/periph_flashpage flash term ``` ``` USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/mtd_flashpage flash term ``` ### Issues/PRs references Depends on PR #19077 Depends on PR #19078 Co-authored-by: Gunar Schorcht <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This PR provides configurable linker scripts for ESP32x SoCs.
Using the vendor
memory.ld.infile and asections.ld.infile instead of the static versions of these files, from which the actual usedmemory.ldandsections.ldare generated using the C preprocessor, allows to use the configuration insdkconfig.has well as Kconfig to define a custom memory layout. For example, it is no longer necessary to maintain differentmemory.ldfiles for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.Note for the review: The
memory.ld.infiles are now simply copies of the manufacturer'smemory.ld.infiles. However, it is not possible to use the vendor'smemory.ld.infiles directly, because they have to be extended further on, e.g. for theperiph_flashpageimplementation.This PR is prerequisite for the
periph_flashpagesupport in PR #19079.Testing procedure
Green CI.
Issues/PRs references
Prerequisite for PR #19079