If someone is looking for ssh terminal firmware that can be installed directly from SD card, I uploaded a ready-made version of wezterm here. Enjoy!
Hi I came across a problem with the Pico 2 Bootloader for UF2 Loader that I couldn’t find an answer to on the forum, so after some testing this is what I discovered.
The problem is that the bootloader_pico2.uf2 from versions 2.1, 2.2 and 2.3 don’t flash properly in bootsel mode on a fresh pico2, pico2w. What happens is it looks like it works but within 30 secs it automatically reboots into bootsel mode to signify a failed flash has taken place.
The only solution to this problem is to first flash with the first bootloader_pico2.uf2 from Aug 13, 2025 which I think is the 2.0 release. This one installs properly and when checked the boot menu displays on the picocalc. Then you can put the pico 2 into bootsel mode and flash the 2.3 bootloader_pico2.uf2 which then flashes properly and loads the 2.3 boot menu.
It only works when its done as an upgrade. I’m not sure what changed after the 2.0 release, but it only affects the rp2350 boards and not the rp2040 which flashes properly no matter what release is used.
Hope this helps others like me that never tested this great menu loader from the start. As I was certainly scratching my head and wondering why others were saying 2.3 was working for them on the rp2350 but I couldn’t get it to flash.
1 Like
Given that I just successfully flashed a new Pico 2W with the latest version of my bootloader, I suspect there’s nothing actually wrong with the newer versions and you’ve just been inadvertently led astray by a piece of information you’re missing. Specifically this:
it looks like it works but within 30 secs it automatically reboots into bootsel mode to signify a failed flash
From 2.1 onwards, ending up in bootsel is what uf2loader does when it can’t load the UI for any reason. So that’s not enough information to know it was incorrectly flashed, and in fact that’s the less likely explanation.
While I won’t claim to know what actually happened on your end, something that could have happened is that you had an SD card issue all along, which prevented the UI from booting and causing the bootloader to fall back to bootsel. When you finally installed 2.0 and it instead sat in an infinite loop, you then went looking elsewhere for other issues and fixed the real problem, which allowed the later versions to also run properly.
This is why I include a diagnostic uf2 binary in the release; it tests everything the bootloader needs to successfully boot the UI and displays the test results on the LCD.
Hi pelrun
I’ve explained exactly what happened to me and the solution that I went through for the rp2350 pico 2, the rp2040 pico’s I had no problems with.
I used pico 2’s that hadn’t been used before I had 2 of them one of them with wifi, and the bootloader_pico2.uf2 was installed before I even attempted to install the board in the PicoCalc, as that part will install on any pico of the right type. The SD Card wasn’t the issue at all.
I even went as far as compiling the project on my computer in case it was a download issue from the internet. I’m not saying your experience is wrong but I didn’t post before spending a couple of days working out why it wasn’t working for me. If someone else experiences what I did then there is a work around now.
I really like your software it really makes the PicoCalc a better device.
Edit :- I’ve went back and checked with my PicoCalc fitted with a pico2w, I nuked the flash with the raspberry pi official flash_nuke.uf2, and I get the same results as before it takes a while but eventually I can get the 2.3 bootloader_pico2.uf2 to stick using the advise in my first post. There is a problem as far as I can see. Hopefully you can reproduce what I’m seeing using the flash_nuke.uf2 file first on your own pico2.
As the guy who wrote this thing, there’s literally no mechanism present (not in the ROM code, and certainly not in my code - both of which I’m intimately familiar with, thanks) that could result in the behaviour you describe. Nothing in the 2.0 build remains if you flash anything else on top of it. And there’s no difference between a new-in-box Pico and one that’s had it’s flash completely erased*. But just in case, I’ve tested both, in the past 24 hours, and didn’t see anything unusual.
Also, flash_nuke is less effective than using picotool - especially if you’re having problems flashing a uf2. I’d strongly suggest using that if copying to the bootsel drive is flaky (and there are a whole host of issues around the bootsel drive depending on your OS.)
If you can demonstrate replicating this in a way that makes it clear it’s not user error, I’ll happily fix a bug.
*RP2350 has an OTP area, but I’m not writing to it.
I’ve just released UFLoader v2.4.1, with improvements to the SD card speed and USB mass storage. Hopefully USB now works for those running Windows and Mac.
You can update only BOOT2040.uf2/BOOT2350.uf2 if you’re on bootloader v2.3, but you’ll need to update everything if you’re on an earlier version.
4 Likes
Thanks @pelrun for accepting my PR to fix the Windows/macOS USB problem. Your refactoring unfortunately “reverted” the fix. I have already submitted a PR with a solution.
EDIT: this response was for the v2.4 POST, i clicked the wrong reply button 
1 Like
Bum. I didn’t even have to look at it to know what I must have done. I’ll pull 2.4 and put up a 2.4.1.
v2.4.1 is now up, fixing the dumb bug.
1 Like
Is there a plan to support non-contiguous UF2 images like the ones from zeptoforth?
I managed to patch zeptoforth to use it with the UF2 Loader (by modifying the assembly flash functions and at the moment only fat32 support is missing), but to be able to flash it I had to modify the zeptoforthmake_uf2.py script to fill the gaps in the file.
This was necessary because the UF2 Loader rejects it when hitting the gap as a “bad UF2 file”.
This way the UF2 file is fairly big compared to the original zeptoforth UF2s but at least it works.
Yes, zeptoforth does have weird UF2 files. It was never originally meant to work with UF2 loader – it existed well before UF2 loader ever did. Thanks for your work on this – feel free to submit a pull request for this once you’ve got it nailed down.
Note that the real reason why I do not distribute UF2 files for zeptoforth on the PicoCalc other than the kernels is that there are just too many possible combinations of configuration items (e.g. text-only versus graphical, font size, flash size, no networking versus zeptoIPv4 versus zeptoIPv6, PSRAM availability, etc.) for it to be practical, and I do not distribute UF2 files containing CYW43439 drivers because the CYW43439 firmware binaries I use are, to my knowledge, technically not free as in freedom even though they are gratis.
Not really, though I’ll accept a patch. It’s a little more involved than just disabling the check that causes it to abort, though.
I created a PR that works for me (on the RP2350) but i think it still needs some testing.
1 Like
I created a PR but there are still some points to consider
Thanks for working on this. Ultimately we would probably want to have a separate build process for building for those who want to use the UF2 loader, because I would want to keep the non-UF2 loader build process intact.
When trying to set ssid on that version of wezterm, flashed trough the bootloader, I get an SdError(FormatError(“Partition type not supported”))
Is there something I should be doing?