Skip to content

Add FLASH option to pico_package_uf2_output #2545

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

Merged
merged 4 commits into from
Jul 15, 2025
Merged

Conversation

will-v-pi
Copy link
Contributor

@will-v-pi will-v-pi commented Jun 30, 2025

Allows passing FLASH instead of 0x10000000 (eg pico_package_uf2_output(hello_serial FLASH)) to package a UF2 to flash

Also adds a pico_ensure_load_map(TARGET) function, to ensure a load_map is added to the binary (eg for universal no_flash binaries)

Allows passing FLASH instead of 0x10000000 (eg pico_package_uf2_output(hello_serial FLASH))
@will-v-pi will-v-pi added this to the 2.1.2 milestone Jun 30, 2025
@will-v-pi will-v-pi requested a review from kilograham June 30, 2025 09:12
@lurch
Copy link
Contributor

lurch commented Jun 30, 2025

Would it also make sense to add an "SRAM" option?

@will-v-pi
Copy link
Contributor Author

Would it also make sense to add an "SRAM" option?

Not really - packaging is where you put an SRAM binay in Flash, so it can be stored in non volatile memory, and the bootrom copies it to SRAM at runtime. It doesn't make sense to do the opposite and package a Flash binary to SRAM. It might make sense to package an SRAM binary from one bit of SRAM to another, but you'd be specifying a custom address for that anyway.

@lurch
Copy link
Contributor

lurch commented Jun 30, 2025

Perhaps it's also worth making a companion PR to pico-examples demonstrating this feature being used? 🙂 (which obviously can't be merged until this PR has been merged)

@will-v-pi
Copy link
Contributor Author

Yeah, once this is merged, I'll replace all the pico_package_uf2_output(... 0x10000000) in pico-examples with this

@will-v-pi
Copy link
Contributor Author

Would it also make sense to add an "SRAM" option?

Not really - packaging is where you put an SRAM binay in Flash, so it can be stored in non volatile memory, and the bootrom copies it to SRAM at runtime. It doesn't make sense to do the opposite and package a Flash binary to SRAM. It might make sense to package an SRAM binary from one bit of SRAM to another, but you'd be specifying a custom address for that anyway.

Actually, looking through the examples, we do use packaging to SRAM for universal binaries, as a way to ensure they have a load map. But rather than adding an SRAM option for this, the better option would be a pico_ensure_load_map function or similar (which pico_package_uf2_output could call)

@kilograham
Copy link
Contributor

I'm a bit confused; you always want to package it into flash, no? so perhaps allowing you to omit the argument is better?

@will-v-pi
Copy link
Contributor Author

I'm a bit confused; you always want to package it into flash, no? so perhaps allowing you to omit the argument is better?

I've switched it to this, as currently yes, you do always want to package it into flash

@kilograham kilograham merged commit d70cccd into develop Jul 15, 2025
11 checks passed
@kilograham kilograham deleted the better-package branch July 15, 2025 21:53
will-v-pi added a commit to raspberrypi/pico-examples that referenced this pull request Jul 22, 2025
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.

3 participants