RTEMS | Draft: bsps/riscv/esp32: Stop the data region where the ROM's own data begins (!1558)
Sam Price (@TheSamPrice)
gitlab at rtems.org
Tue Nov 3 04:19:33 UTC 2026
Sam Price created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1558
Project:Branches: TheSamPrice/rtems:esp32c3-rom-data-reserve to rtems/rtos/rtems:main
Author: Sam Price
The `RAM` region runs to `0x3fcd0000`, the end of internal SRAM, but the ROM keeps its own data from `0x3fcce710` upward. So the last 6384 bytes of the region are memory the ROM believes it owns.
ESP-IDF stops at the same address. `esp_system/ld/memory.ld` ends `dram0_0_seg` at `0x403CE710` on the instruction bus, which is `0x3FCCE710` on the data bus.
No failure has been traced to the overlap, and this doesn't claim to fix one. But the exposure isn't conditional on any driver: this BSP calls ROM code on every path (`ets_*`), and the PHY and WiFi libraries call their ROM halves through their own address literals, which no link-time check can see. If it ever bites, it corrupts whatever the allocator placed last, on a path that only runs sometimes.
- **New option `ESP32C_DRAM_ROM_RESERVE_SIZE`, default `0x18f0`.** That is exactly `0x3fcd0000 - 0x3fcce710`, taken off the top of `RAM`. Setting it to 0 restores the old layout.
- **Cost:** 6384 bytes of work area. No sections move, because `.work` is the only thing sized from what's left of `RAM`.
- **New linker symbol `esp32c_dram_rom_reserve_begin`.** A program can read the boundary from the image it's running instead of copying the constant.
**Default value:** this changes the default memory layout of the existing BSP, so I'm flagging it for review. I chose `0x18f0` because the matching ESP-IDF value is the one a reviewer can check. Defaulting to 0 would keep today's layout but leave the overlap.
**Testing:** `riscv/esp32c3db` and its samples build with no warnings. In `hello.exe`, `RamEnd`, `bsp_section_work_end` and `esp32c_dram_rom_reserve_begin` are all `0x3fcce710`, up from `0x3fcd0000`.
This touches the same `MEMORY` block in `linkcmds.yml` as the IRAM-region MR. Whichever merges second needs a trivial rebase.
Assisted-by: Claude Opus 5 (1M context) <noreply at anthropic.com>
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1558
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-1w6g1fl4k5lyed1d8qtxouaom-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20261103/1193d618/attachment.htm>
More information about the bugs
mailing list