One of the challenges of using UF2 files with RP2 devices is you can see what's in them, make assumptions about what that will deliver, but can't easily tell what they will actually do, what will ultimately be put in Flash or where. From dragging and dropping a UF2, or uploading with 'picotool', it's a completely invisible process, a black box system.

The best one can do is dump the entirety of Flash after uploading and see if that matches expectations. Then you have to figure out why not if it doesn't.

What would be useful is some sort of RP2 Bootloader Emulator with Virtual Flash which doesn't require a physical RP2, can be used to better see what's going on.

A fast-track for that may be a Bootloader Emulator, supporting MSD and USB upload modes, which runs as the executable on an RP2. But a pure software solution would be best,

I had considered doing that myself but I'm not a proficient C programmer and don't know C++ at all. Trying to do it in Python is a non-starter given the effort of replicating the 'picotool' parts and the Boot ROM accurately and keeping up to date with any changes there may be.

A Python-based UF2 uploader might have some utility in itself but, unless it replicates 'picotool' exactly, it's not much of an Emulator.

Has anyone seen anything like this already or has any ideas on how to deliver something useful ?

Where are you getting these unknown UF2 files from?

Electronic and Computer Engineer
Pi Interests: Home Automation, IOT, Python and Tkinter

They usually appear as a result of the development process, when merging UF2 or creating a UF2 with other than a single image plus an E10 Fix. The most common example will be a 'universal UF2' which contains an RP2040 and RP235X image, but may contain executable plus data partitions, and can be more advanced as here - viewtopic.php?t=388069

As there, it's not just the UF2 but how it interacts with any partitioning regime in place in the target device.

Partitioning allows some pretty clever stuff to be done but the more complicated a partitioning scheme is the harder it can be to craft a UF2 which suits that.

Having something which helps verify a UF2 and partitioning scheme will do what is required can currently only be done by trying it and seeing, with little insight available as to why things have ended up as they have. Or asking an expert who already knows.

There's little opportunity for gaining a comprehensive understanding of the upload capabilities without studying and understanding the documentation, Boot ROM code and 'picotool' code, trying it on real hardware.

I also think it's useful to be able to try things without it having to be potentially destructive testing with real hardware. I'd like to mess about with all manner of partitions, Family ID, code protections, signings, hashing, and OTP settings, to see what affects they have, to better understand things. I'd rather prove something does what is expected under emulation than on a real chip and then have to throw that in a bin.

When tests may be destructive there is a tendency to test only that something appears to work. It introduces reluctance to test what doesn't work or edge cases. Things which one might ideally want to test or should be testing.

One could argue, if such an RP2 Bootloader Emulator had been created as part of the RP235X development process, the bug which the E10 Fix is needed to work around on A2 silicon would have been identified, found and corrected, before silicon was finalised and no one would have had to deal with the complications and consequences of that.

It may also have allowed identification during development of the E18 'bricked device' issue, the E22 'will need to upload via SWD to allow things to work again' issue, plus E13, E14, E15, E19, E23 and E25 issues.

But that would depend on how closely and accurately an emulator matches the reality of the physical chip.

It's generally accepted that having emulators and simulators allows more extensive and comprehensive testing than 'try it and see' on physical chips, is usually easier and cheaper, and can pay dividends when it does identify an issue. Plus it's useful for gaining a better understanding of things, appreciation for what something can do.

Last edited by hippy on Fri May 23, 2025 1:34 pm, edited 1 time in total.

Can use SWD debugger to see how the BOOTROM works, it's not destructive, also can see Flash (live), peripherals etc.
The only irreversible thing would be OTP settings, though some settings can be simulated without permanently writing to it.

gmx wrote: ↑

Fri May 23, 2025 1:34 pm

Can use SWD debugger to see how the BOOTROM works, it's not destructive, also can see Flash (live), peripherals etc.
The only irreversible thing would be OTP settings, though some settings can be simulated without permanently writing to it.

A software solution allows testing without any hardware, and is usually simpler to do. It's avoiding the convoluted nature of how it might otherwise be done which is the key purpose of emulation. It makes it easier, more straight-forward, lowers the bar for entry.

Single-stepping or run-to-breakpoint, noting where execution got to, what registers and variables contain, having to figure out what that means is usually inferior to a bunch of 'if' and 'printf' which can do that for you. It's not possible to add that to the ROM code, but it is usually trivial to add to an emulation of the same

Also, when SWD debugging, I believe USB is disabled ( or soon breaks anyway ), so I am not sure how one would debug Bootloading via MSD or Bootloading via USB. I am not convinced it would allow the testing I would like to do.

Actually USB is working well if you don't interrupt it in its critical moments, even though it's just the Windows driver complaining, managed to recover also that, might be annoying, but it's not a show stopper.

Look, picotool in BOOTSEL mode under debugger: Can use watchpoints, realtime tracing... bootrom is available with debug info (thanks to @kilograham).
And you can use the debugger itself (console, or programmatic) to make live Flash operations (sector erase, write, read etc.).

I think RPi used FPGA version to test.

gmx wrote: ↑

Fri May 23, 2025 3:33 pm

Actually USB is working well if you don't interrupt it in its critical moments, even though it's just the Windows driver complaining, managed to recover also that, might be annoying, but it's not a show stopper.

Can use watchpoints, realtime tracing... bootrom is available with debug info (thanks to @kilograham).
And you can use the debugger itself (console, or programmatic) to make live Flash operations (sector erase, write, read etc.).

All sounds like a lot of effort and bit complicated to me. Fine if prepared to get to grips with that but there has got to be an easier way.

I suppose my goal is 'dumbing it down', reducing user effort, making things simpler to test and saving having to think whether a solution will work. Reducing the entry level as said. I don't believe it should be necessary for anyone to buy a Debug Probe or an RP2 board with the appropriate amount of Flash to do what can be done with just software.

Take this typical example of an executable image with an E10 Fix - We think we know what that UF2 will do if downloaded by drag-and-drop but we can have an emulator confirm it for us - Yay! Our understanding was correct.

The write to end of Flash might surprise some but those of us who know were expecting that, already know that will corrupt any data held at the end of Flash. And know the E10 Fix sector can be moved.

So what if we have the E10 Fix provide the last sector of the executable which saves one erase-write, and avoids corrupting the end of Flash ? We think that will work and we can emulate it to confirm the outcome - Yay! We're really on a roll. It did what we wanted it to.

But then someone throws water on our parade by reminding us of partitions, tells us what we have done is flawed, won't work if we have partitions.

And we can test that claim - Bugger. It's game over.

That should have been obvious but we can try all sorts of ideas and test those without wasting time using hardware, until we accept it can only work without partitions, not with.

If we had attempted this with hardware it would likely have been a miserable experience. The incomplete executable would probably have hung or in some way crashed. We would have had to download or examine the Flash to see that part of the executable was 'missing', was somewhere other than it needs to be, and maybe have to figure out why that was.

With the emulator I am imagining it pretty much tells us what happened and why, and near instantly.

This was a trivial example. Imagine if someone has a more complicated scenario and comes to the forum to say "I've signed and secured my Pico 2 code but now it won't accept my drag-and-drop downloads".

What do we tell them; "dunno" and wish them luck with figuring it out ?

Without there being any insight into what's happening that's probably the best we can do unless prepared to indulge in debugging something which could be tortuous to get to the bottom of, something we might not relish doing even if it were our own problem.

An emulator would be a great help in determining if it should still be accepting those downloads or explaining why it isn't. It might not be perfect for all cases but seems to me better than a shrug and "no idea".

I believe use as a diagnostic aid, while providing the ability to play around and try things out, with no risk of detrimental consequences would make it worthwhile.

Ah, so you need something imaginary without knowing how it really works.

gmx wrote: ↑

Fri May 23, 2025 8:17 pm

Ah, so you need something imaginary without knowing how it really works.

How do you mean by imaginary ?

The output above from my 'rp2-emulate' app is what I have. It's just not very good in accurately replicating what the Boot ROM and 'picotool' does.

And what is it that I don't understand how it works ?

The real hardware running the real BootROM, using a real Flash chip (which can behave differently).
And I said 'without knowing', not that you understand or not.

Maybe a higher level partitioning tool would be more useful and easier to implement.

If you have an aversion to SWD, can use:

5.6. USB PICOBOOT Interface
The PICOBOOT interface is a low level USB protocol for interacting with the RP2350 while it is in BOOTSEL mode. This
interface may be used concurrently with the USB Mass Storage Interface.
It provides for flexible reading from and writing to RAM or Flash, rebooting, executing code on the device and a handful
of other management functions.
Constants and structures related to the interface can be found in the SDK header picoboot.h in the SDK

I think E10 erasure can be mitigated by reading the previous content of the entire sector, then written back as it was.

gmx wrote: ↑

Fri May 23, 2025 11:10 pm

The real hardware running the real BootROM, using a real Flash chip (which can behave differently).

At some level all Flash chips are equivalent or the RP2 won't work with them. That level will be Sector Erase, Page Write, Page Read and Read Unique ID. I don't believe it will be necessary to handle any differences below that level, at least not to start with.

gmx wrote: ↑

Fri May 23, 2025 11:10 pm

Maybe a higher level partitioning tool would be more useful and easier to implement.

Possibly but that's not Flash emulation. Flash emulation would IMO be the useful tool for verifying that such a tool had crafted a partitioning scheme and UF2 which worked with it.

gmx wrote: ↑

Fri May 23, 2025 11:10 pm

If you have an aversion to SWD, can use: 5.6. USB PICOBOOT Interface

The point is to be able to emulate drag-and-drop uploads and those done using 'picotool', to reveal and better understand what the outcome will be, and to do it purely with software.

gmx wrote: ↑

Fri May 23, 2025 11:10 pm

I think E10 erasure can be mitigated by reading the previous content of the entire sector, then written back as it was.

Maybe but the emulator has to emulate drag-and-drop uploads, has to emulate what the Bootloader MSD interface does. It has to emulate what we have, not what it could be.

That also applies to the Bootloader USB interface. And 'picotool' and whatever it does.

This emulation isn't intended to deliver improvements directly. It is purely for revealing what happens. It might however enable the application of such techniques to be tested and verified.