BUILD_PROTECTED defaults ESP32S3_APP_FORMAT_LEGACY to y, so a protected build
has always needed the ESP-IDF second-stage bootloader. Nothing about the
protected layout requires it: the kernel and user images are described
entirely by ESP32S3_KERNEL_OFFSET, ESP32S3_KERNEL_IMAGE_SIZE and
ESP32S3_KERNEL_RAM_SIZE, and esp32s3_userspace() maps the user image itself.
Three obstacles stood in the way.
Those three symbols were gated on ESP32S3_APP_FORMAT_LEGACY, but
protected_memory.ld needs all of them for KIROM, KDROM, UIROM, UDROM, KDRAM
and UDRAM. Without them the region lengths underflow to 2**64-1 and the
kernel/user RAM split lands nowhere, which the hardware reports as a DRAM0
PMS monitor violation once the first user process runs. The offset becomes
0x0 for simple boot, where the image is flashed at the start of the device.
protected_memory.ld had no case for a 32 MB part, so FLASH_SIZE was
undefined there and ROM, UIROM and UDROM underflowed the same way.
flat_memory.ld has had the case all along.
kernel-space.ld defined none of the symbols simple boot needs
(_image_irom_*, _image_drom_*, _bss_*), and kept none of the early code
resident. __start() runs bootloader_init() and map_rom_segments() before any
flash mapping exists, so everything they reach has to be in RAM -- including
map_rom_segments() itself, which unmaps the MMU it is running from, and
nuttx_enter_critical(), reached from rtc_clk_init() by way of regi2c. These
mirror what esp32s3_sections.ld already does for the flat build.
Verified on an ESP32-S3-WROOM-2 (32 MB octal flash), esp32s3-devkit:knsh with
FLASH_MODE_OCT: boots to NSH and runs ostest, where it reaches the same
timedmutex abort as every other target. The legacy path is untouched.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
This commit updates the common-source integration for Xtensa-based
Espressif devices (ESP32, ESP32-S2, and ESP32-S3). This is part of a larger
common-source update split by architecture for better maintainability.
Major components updated:
- IRQ allocator refactoring with intr_alloc integration
- Common-source drivers (GPIO, RMT, I2C, SPI, UART, etc.)
- Espressif components upgrade to release/master.b-test
- Peripheral drivers (ADC, PWM, LEDC, MCPWM, PCNT, Temperature Sensor, etc.)
- Wireless adapters (Wi-Fi and BLE)
- esp_timer migration to the common-source path for Xtensa devices
- Common-source power management implementation (auto-sleep and wakeup paths)
- Board defconfigs for all Xtensa Espressif boards
- SMP support improvements for ESP32-S3
- Critical section handling improvements
Key architectural changes:
- IRQ Allocator: The new interrupt allocator enables multiple mapping
options from interrupt sources to CPU interrupts, providing flexibility
required by modern peripherals. Although this introduces breaking changes
to the interrupt handling API, the required ARCH_MINIMAL_VECTORTABLE
Kconfig option is explicitly checked during startup to ensure proper
configuration. This validation prevents runtime issues from configuration
mismatches.
- Xtensa-specific interrupt handling via esp_xtensa_intr.c providing
NuttX-native implementations of xt_ints_on/off and interrupt handlers,
avoiding conflicts with NuttX's core Xtensa macros.
- Timer/RTC unification: ESP32/ESP32-S2/ESP32-S3 move from chip-specific
RTC/RT-timer code to common-source Espressif integration, including
esp_timer_adapter/esp_rtc paths and the required bringup/defconfig updates.
- Power management consolidation: Xtensa PM follows the common-source
implementation, including common-source auto-sleep behavior, UART/Wi-Fi
wakeup coordination, and tickless-safe sleep flow compatibility.
Note: This is a large commit to maintain bisectability. Breaking the
changes into smaller commits would result in non-building intermediate
states across the common-source infrastructure update.
Tested configurations:
- All defconfigs were tested, including `ostest`.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.com>
This defconfig uses the legacy bootloader (based on ESP-IDF's
bootloader) and, due a recent update on SPI flash support, its
initialization was missing data to be moved to the IRAM during the
boot process.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.com>
Adds SYS_STARTUP_FN which calls constructors and init functions on
common source code. Requires compatibility changes on linker script.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Update internal reference to get the most updated Espressif's
libraries. Those libraries are based on branch `release/v5.1` of
the ESP-IDF and include `v5.1.4` version of it.
The Simple Boot feature for Espressif chips is a method of booting
that doesn't depend on a 2nd stage bootloader. Its not the
intention to replace a 2nd stage bootloader such as MCUboot and
ESP-IDF bootloader, but to have a minimal and straight-forward way
of booting, and also simplify the building.
This commit also removes deprecated code and makes this bootloader
configuration as default for esp32s3 targets and removes the need
for running 'make bootloader' command for it.
Other related fix, but not directly to Simple Boot:
- Instrumentation is required to run from IRAM to support it during
initialization. `is_eco0` function also needs to run from IRAM.
- `rtc.data` section placement was fixed.
- Provide arch-defined interfaces for efuses, in order to decouple
board config level from arch-defined values.
Signed-off-by: Almir Okato <almir.okato@espressif.com>
- Added Wi-Fi related symbols to the kernel-space linker;
- Allocate more RAM to the kernel (to be useb by the Wi-Fi driver).
- Create a specific defconfig.
