Awesome ! Thank you so much, this will make my Life much easeier 
I found my Pico 2w and will start trying to flash it with your fork.
Thanks again!
Take a look on my forks the based conditional size is done. It was a mistake it’s 256Kb not 512Kb
1 Like
I see the fork now! I’ll build your fork and run additional tests. 
Thank you!
Could you please create a pull request once it’s ready? That way, I can merge your changes into the main branch. 
1 Like
Thank you !
Hi @adwuard,
I’ve been digging through all the cool stuff coming out of the community and I’ve gotta say, your SD_Boot project looks awesome!
Not sure if you’re planning to keep developing it, but I figured I’d throw in a couple of ideas just in case.
1) Avoiding the need to recompile Apps
Right now, having to recompile applications to make them work with PicoCalc_SD_Boot feels like a bit of a roadblock, honestly.
But I think that could be solved on the Pi Pico 2/2W. The new RP2350 chip has a really interesting feature - Address Translation (see page 364 of the RP2350 datasheet, section 5.1.19).
In short, it lets you store the App anywhere on SPI flash and then remap that address space so it appears as if it’s stored at the beginning of the flash at 0x10000000. In this case Apps could be used as-is, without needing to be recompiled to match the actual flash layout.
2) Support for .uf2 files
At the moment, SD_Boot supports .bin files on the SD card, which works, but a lot of apps are distributed as .uf2. It’d be super useful to support that format too.
The original pico bootrom already capable of converting .uf2 to binary, so maybe that code could be reused? It’d just need to apply the right offset to avoid overwriting SD_Boot itself - which your code already handles nicely anyway.
3) USB Mass Storage mode for SD card
Would be really handy if, while in the SD_Boot menu, the SD card could be exposed as a USB mass storage device - kinda like how the original bootrom works exposing the SPI flash.
That way you could just drag-and-drop files over USB instead of having to eject the SD card and use a reader.
Again, the pico bootrom might have some reusable code to make this work.
Anyway, just wanted to say thanks for building this, and share a few ideas that came to mind. Looking forward to seeing where it goes!
3 Likes
Hi @1more,
Thank you for your constructive and detailed feedback on how to improve this project! This is truly excellent advice and helps point in a good direction! I will definitely plan these into the next improvement for the project.
1) Avoiding the need to recompile Apps
Very interesting! I didn’t know the RP2350 had the concept of an A/B image. This could help with the frustration of recompiling all the apps. Unfortunately, it’s RP2040, which doesn’t work. Maybe this project should be “Pico2 Only” for optimal usage experience.
2) Support for .uf2 files
This is very insightful. Currently, I have no deep knowledge of the layout between .uf2 and .bin. For now I just know .uf2 may contain metadata than raw .bin firmware. I will need to dig deeper to see how can .bin be extracted properly.
3) USB Mass Storage mode for SD card
This is a good idea. There are a couple of MTP examples available. Add support for MTP should be possible too. This will be added to improvement TODOs.
Again, thank you for your truly amazing advice and feature requests!
Edward
7 Likes
Status Update:
Got a good news! I spent some time, and got USB Drive feature working. Now I am able to mirror 32GB SD card and have it work over USB MSC Device Mode. 
The transfer speed seems decent for firmware transfer. Will need to do more testing to ensure robust read writes.
This is active develop branch I am working on: GitHub - adwuard/Picocalc_SD_Boot at edward/feat/usb
12 Likes
My suggestions (and congrats!):
First of all, your firmware is excellent — it’s a major step forward for development on the PicoCalc. Great job!
A few ideas to consider:
• Add a splash screen while the SD card is connecting, to improve the overall user experience.
• Automatically launch an application named autostart.bin (or autostart_rp2350.bin for the Pico 2) at startup. This would enable games or apps to run right from the firmware, bringing us closer to a real “game console mode.”
• In my opinion, the USB Mass Storage mode for the SD card doesn’t need to be built into the core firmware. It could easily be a separate application, to keep the firmware lightweight and focused.
Thanks again for your great work — it’s exciting to see PicoCalc evolving like this!
Awesome Work ! I love the fact that I can switch between firmwares on the fly. I wonder if it’s possible to compile micro Python for the Pico 2 in the .bin format ?
There is a PIC switch in GCC that you should be able to use.
-fpic
Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC, 28k on AArch64 and 32k on the m68k and RS/6000. The x86 has no such limit.)
Position-independent code requires special support, and therefore works only on certain machines. For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent.
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
so pico 2 shouldnt be a requirement if you set the right compiler flags
Edit: Also relevant Position-Independent Code with GCC for ARM Cortex-M | MCU on Eclipse
2 Likes