46528ea5ee
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> |
||
|---|---|---|
| .github | ||
| arch | ||
| audio | ||
| binfmt | ||
| boards | ||
| cmake | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| dummy | ||
| fs | ||
| graphics | ||
| include | ||
| libs | ||
| mm | ||
| net | ||
| openamp | ||
| pass1 | ||
| sched | ||
| syscall | ||
| tools | ||
| video | ||
| wireless | ||
| .asf.yaml | ||
| .codespell-ignore-lines | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmessage | ||
| .pre-commit-config.yaml | ||
| .yamllint | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| INVIOLABLES.md | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| ReleaseNotes | ||
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
Getting Started
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
Documentation
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
Supported Boards
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
Contributing
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
License
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.