UF2 Loader release

Thank you very much for this code, and to the people who made the components you used. I have managed to port the bootloader over to my platform and have a very very untidy codebase, but it works. I can now successfully flash UF2s from SD card. Lots of testing and tidying to do…

Thanks again

1 Like

As always happens, a spanner appeared…

I have done some tidying up and that went well. unfortunately I have found that my main UF2, which uses TinyUSB, does not appear on USB when run from the UF2Loader. Could this be the interrupt problem I see mentioned above? I’ve added a call to enable interrupts at the start of main() and it hasn’t helped.

I just get this:

86475.661227] usb 1-2.1: new full-speed USB device number 49 using xhci_hcd

and no USB devices appear.

Update: This also happens on the PicoCalc when booting the PicoCalc version of the UF2 using the Picocalc UF2Loader with none of my changes, so I don’t think I’ve broken anything.

Has anyone loaded a UF2 that uses TinyUSB and had it working? Maybe I can have a look at some code and see what’s up.

UPDATE2: It helps if, after you have changed your UF2 code you copy the file to the SD card. It’s difficult to keep track of what has changed and where it needs to go, SD card apps directory, root directory, or to the RP2350 directory. Anyway, looks like it’s working now, so the enable interrupts was the problem I think. Now I just need to fix my flash data. I’m using th eold RP2040 calls so wil have to move to the later 2350 ones I think.

1 Like

It’s not that complicated - apps always go into the picoX-apps directory. The only uf2s that go anywhere else are BOOT2040.UF2 and BOOT2350.UF2, which go into the root. I actually have a make target that copies everything automatically to the right places, because I do it so often.

It is possible to continue using the old calls on the rp2350, but the offset changes. It’s no longer address-XIP_BASE, it has to be address-XIP_BASE+(FLASH_SECTOR_SIZE*2) - which is very unlikely to change but probably should be derived from the partition API anyway, in case it’s running in some non-uf2loader environment in the future.

:slight_smile: Yes, I know where it goes, but I just didn’t copy it there. Dah! My fault.

i put something in the flash and had a look for it and didn’t find it, I’ll have another look.

This shows it in use, for anyone who is interested:

1 Like

Am currently using a pico 2w on my picocalc and have loaded the sdcard reader software (followed the jblanked video). Jblanked OS’s work. However, some other uf2’s only produce a black screen on loading. Is there a version of the origional PicoWare MMBasic program that will work with the UF2 Loader? Thanks for any guidance or information.

I’ve now found my data, and it seems to be 0x2000 bytes before where my code expects it. What was surprising to me was that reading and writing don’t still work, just at a different address. Then I remembered that writing uses an offset from the start of flash and reading uses the address. So that is explained. I then had a look at the ATRANSn registers with and without the UF2Loader and saw this:

Without UF2Loader:

ATRANS Registers
ATRANS0:04000000
ATRANS1:04000400
ATRANS2:04000800
ATRANS3:04000C00

With UF2Loader:
ATRANS Registers
ATRANS0:03FE0002
ATRANS1:00000400
ATRANS2:00000400
ATRANS3:00000400

I’m going to have a look at these registers in my code so that I can detect the offset I need in writes to make them align with the reads. The values make sense, except for ATRANS1..ATRANS3 which don’t seem to be set correctly with UF2Loader. I have 16Mb on the Pimoroni Pico Plus 2, so that is a problem if I ever use more than 4Mb. Do you have plans to extend this to 16Mb? It’s not a problem for me on my platform as I have my own UF2Loader and can adjust that, but I also have a Pimoroni Pico Plus 2 in my PicoCalc.

I’m thinking of adjusting the reset values in the ATRANS registers as they should have auto-detected the flash size, or will that not work?

Just like to report that Webmite_pico2_w.uf2 is not fixed enough, for pico2w.

UF2 Loader 2.3 loading that uf.2 , than after start, going back to UF2 Loader screen with listed uf2

I already implemented it, but the flash size is not autodetected. It uses the size of the app partition (has to be defined at compile time), which is set in the cmake file from the PICO_FLASH_SIZE_BYTES value. If you’re just building with PICO_BOARD=pico2, it’ll build for a 4MB flash. You’ll have to use a different board definition with the right flash size value.

Should Webmite work without the loader? It goes back to the USB device directory screen after the transfer.

I’m at the pointy end of moving house right now so I can’t do much in the way of troubleshooting for at least a couple of days. Is it just remaining in the uf2loader menu, or is it actually rebooting and then ending up back in the menu? The latter really shouldn’t be possible.

(Note: rebooting and then crashing before modifying the LCD contents so it still shows the menu, but nothing works, is much more likely)

Doesn’t the bootloader size the flash? When I don’t use the UF2Loader bootloader I see the ATRANS registers set to 16Mb, I think, so isn’t it possible to look at the ATRANS registers and subtract $2000 from the base field of each one?

The rom bootloader sets up the ATRANS registers according to the partition table. If there is no partition table, sure, that’ll end up being all of flash.

Since uf2loader defines a partition table, that takes priority - and the size of the app partition is set at compile time.

Once you’ve correctly built for the appropriate platform, parsing the atrans registers will give you the right numbers. And you don’t “subtract $2000 from each one” - the low bits being 2 tell you to add 0x2000 to your flash offset, because 0x2000 is the offset of the first byte on the app partition (what your app thinks is 0x10000000.)

Just to reiterate, the offset is address-XIP_BASE+(FLASH_SECTOR_SIZE * (ATRANS0 & QMI_ATRANS0_BASE_BITS))

this is the case… on my side.

Thanks, does this work with the 2w?

Having some issues with several firmwares trying to load them trough the uf2 bootloader… being new to it I am wondering if it is a setup issue or problems within the firmware themselves. Or something with the bootloader?

The nes and picoware firmware boot but are unresponsive.

The wezterm, ulisp, microPython and lua firmwares crash and reboot in a loop.

The fuzix firmware freeze with error “panic: no root”

Picomite (a specific version) and the gameboy emulator firmware do run well.

I tried most of these firmware stand-alone and they run ok - regardless, just seing them display something tells me the issue is not the uf2 version I use. Unless they are older variants? Should they be rebuilt? Am I running a too old build of them?

Maybe I am missing something? Ideas welcomed. Thx

Did you install bios 1.4? There’s a bug in the old keyboard drivers many apps were built with that literally tell the BIOS to restart the system during init - pre 1.4 bioses ignored that command but 1.4 implemented it. Reinstalling bios 1.2 hides the issue.

Fuzix needs a separate partition on the SD card with it’s root filesystem.

Sounds like you’re using builds that predate SDK 2.2.0, which fixes this.

I did update to bios 1.4. Would it be better to keep 1.2? That’s odd.. I guess updating the apps would be better?

Weird thing is - say wezterm reboots like this when booted trough uf2 loader, but works when installed stand-alone. Is the init problem only when booting trough bootloader?

I will look about the fuzix Partition, thanks for pointing it out.

For the rest it seems like it’s a matter of getting rebuilt variants of the uf2 with the updated sdk?