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
Merged
merged 2 commits into from
Jun 26, 2025
Merged

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

merged 2 commits into from
Jun 26, 2025

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 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.

@iabdalkader
Copy link
Contributor Author

Can we unblock this PR if the current solution is acceptable? We have a demo/example that doesn't work without this.

dpgeorge
dpgeorge approved these changes Jun 26, 2025
View reviewed changes
Copy link
Member

@dpgeorge dpgeorge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late review.

This looks fine to me, it's a reasonable solution that gets things working. In the future it can be refined/improved and generalised to other ports.

I built ARDUINO_GIGA firmware and inspected the elf to see that the _gc_blocks_table_start memory looked correct.

@iabdalkader @dpgeorge
stm32/main: Add support for additional GC blocks.
cbe5063 
Add support for defining additional GC blocks via linker scripts.  A board
would need to define `_gc_blocks_table_start` and `_gc_blocks_table_end`
and within that region have pairs of (address, length) for each GC block
to add.

Signed-off-by: iabdalkader <[email protected]>
@iabdalkader @dpgeorge
stm32/boards/ARDUINO_GIGA: Define additional GC blocks in SDRAM.
5c6da11 
Signed-off-by: iabdalkader <[email protected]>
@dpgeorge dpgeorge force-pushed the add_stm32_gc_blocks branch from 6261a76 to 5c6da11 Compare June 26, 2025 02:13
@dpgeorge dpgeorge merged commit 5c6da11 into micropython:master Jun 26, 2025
10 checks passed
@iabdalkader iabdalkader deleted the add_stm32_gc_blocks branch June 26, 2025 06:55
@iabdalkader
Copy link
Contributor Author

@sebromero

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dpgeorge dpgeorge dpgeorge approved these changes

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