Sneakily document size of dram2_uninit #4360
Conversation
| reserved_rom_stack_app : ORIGIN = 0x3ffe5230, len = 11264 | ||
|
|
||
| dram2_seg : ORIGIN = 0x3ffe7e30, len = 98767 /* the rest of DRAM after the rom data segments and rom stacks in the middle */ | ||
| dram2_seg : ORIGIN = 0x3ffe7e30, len = 98768 /* the rest of DRAM after the rom data segments and rom stacks in the middle */ |
There was a problem hiding this comment.
Off by one, new length now places the end at exactly 0x40000000
|
This PR, especially adding chip features to esp-alloc seems entirely unreasonable. The data itself is pretty useful, though, as nothing really documents how much memory can be used. Should we maybe add the sizes to somewhere in the readme, similar to the peripheral support table? |
|
Maybe a first step to (some day) have all the relevant information to generate memory.x
I first thought we could just list it for all chips in the docs but we usually don't do that, so the README might be a better idea? |
|
We can also have a constant in esp-hal or esp-bootloader-esp-idf so that the users don't have to know the value, or they/we can simplify supporting multiple devices. Listing the info on the |
Interesting idea - probably esp-bootloader-esp-idf would be a good place for that |
|
Can we somehow get esp-bootloader-esp-idf to create the memory region for the linker scripts? |
That should work, yes |
We can just add our out directory to the to the search-path and create The only "drawback" is users will get a slightly confusing linker error (file not found) - maybe we could use |
bugadani
force-pushed
the
dram2
branch
2 times, most recently
from
7ec9996 to
5c9971d
Compare
|
I didn't do the linker script changes, but now it's the bootloader crate that enables the attribute, and documents the available memory. |
2 participants
As the reclaimed RAM is a consequence of the esp-idf bootloader, this PR adds documentation, and gates the
ram(reclaimed)attributed by esp-bootloader-esp-idf.