Skip to content
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.

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

CI: Better build size debugging #927

Closed
wants to merge 4 commits into from
Closed

Conversation

Gadgetoid
Copy link
Member

@Gadgetoid Gadgetoid commented Apr 8, 2024

This is a little bit of a redux of the issue I raised here: micropython/micropython#8680

And the PR here: micropython/micropython#8761

Neither of these have had any traction for a while, due to an impasse with the way flash sizes are declared with Pico's bi_decl being incompatible with how we might want to supply (or retrieve from) flash sizes in memmap_mp.ld.

The general idea is to split FLASH into APP and FILESYSTEM so we have an early failure if the two happen to overlap.

Without a linker error to catch this, a MicroPython build will generate a filesystem at runtime and overwrite itself in potentially catastrophic ways.

Making this tooling work requires adding an memmap_mp.ld to each board directory. Since this does not inherit the flash size from mpconfigboard.h it removes the previous "single source of truth" for flash size and... this can easily catch you out.

In all cases the linker variable _flash_app_size should be ACTUAL_FLASH_SIZE - MICROPY_HW_FLASH_STORAGE_BYTES. Eg: For Pico this is 2048 (2MB) - 1408 (1.4MB) = 640k.

@Gadgetoid
Copy link
Member Author

Judging by the before and after of Tiny 2040 (8MB) the ulab module - as configured - weighs in at about 92k.

@Gadgetoid
Copy link
Member Author

Having a long, hard think about how much appetite I have to babysit Yet Another Patch 😆

Add a patch for CMakeLists.txt which adds -Wl,--print-memory-usage so
we can get at least some useful information about which builds are
running close to the limits.
Using a custom patch against MicroPython's CMakeLists.txt this will
optionally use a memmap_mp.ld file from the *board* directory and
allow us to check if the allocated app flash overflows.

Linker scripts need configured on a per board basis.
This build has plenty of room for fancy extras.

Replaces #570
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant