Skip to content

ports/stm32: Add support for additional GC blocks. #17019

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

ports/stm32: Add support for additional GC blocks. #17019

wants to merge 2 commits into from

Conversation

iabdalkader
Copy link
Contributor

@iabdalkader iabdalkader commented Mar 27, 2025 •
edited
Loading

Summary

This patch adds support for defining additional GC blocks (for split heap) via linker scripts. While split GC on its own is very useful, there isn't a standard way to actually use it, so maybe this will be a step towards that.

For the Giga board, a few blocks in SDRAM/SRAM are also enabled as an example.

Testing

I tested on the Giga, checked the blocks addresses an sizes passed to gc_add and mem_free. This change is enabled conditionally when split heap is enabled, so should not have any effect on other boards as none use split heaps.

Trade-offs and Alternatives

If linker scripts were processed through CPP, we could define these blocks in board config files and make the linker script section common. Since this is not the case, this table structure will have to be duplicated if other boards want to use this. I've tried to add a common linker script (common_gc_table.ld) but without CPP it's very hard to make this generic (the conditionals supported by ld script are very basic).

Also, the blocks are defined in a particular order so that faster SRAM blocks are, hopefully, searched first. We wouldn't have to rely on this, if we had this feature: #16644

@iabdalkader
ports/stm32: Add support for additional GC blocks.
12753ef 
Add support for defining additional GC blocks via linker scripts.

Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
@iabdalkader
boards/ARDUINO_GIGA: Define additional GC blocks in SDRAM.
6261a76 
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
@iabdalkader iabdalkader force-pushed the add_stm32_gc_blocks branch from f72e02c to 6261a76 Compare March 27, 2025 12:55
@github-actions GitHub Actions
Copy link

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@Gadgetoid
Copy link
Contributor

Short term this would have made a lot of sense for PSRAM on the RP2, too, though we don't have the luxury of per-board linker scripts yet.

And additionally the linked issue relates to the wider problems with PSRAM on the RP2, a platform which exposes DMA and PIO to the end user in ways that could quickly trip them up when a buffer by chance falls into PSRAM.

@iabdalkader
Copy link
Contributor Author

I hope we can find a way to standardize this, eventually, at least the C code in main.c could be common code, and ports could define the "gc table" in any way that works (via linker scripts, in board.c etc... However, for now I'm just trying to add more heap to the Giga as we have an app that's running out of memory and an unused 8MBytes SDRAM :)

And additionally the linked issue relates to the wider problems with PSRAM on the RP2, a platform which exposes DMA and PIO to the end user in ways that could quickly trip them up when a buffer by chance falls into PSRAM.

That's another strong case for implementing the memory map feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
port-stm32
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@iabdalkader @Gadgetoid @dpgeorge