pico-bootrom VS uf2

Espressif is years ahead.

Original RPi-pico has only few one-ups on ESP - BSD-licensed bootrom [0] and PIO.

PicoW doesn't have any, at all. Disappointingly lazy move from pi foundation.

[0] https://github.com/raspberrypi/pico-bootrom/

Crosslinking the two posts: https://github.com/raspberrypi/pico-bootrom/issues/17

I would think that the bootloader code wouldn't use any funky IP blocks - it's not some sort of driver code into which applications call, it's just a special application that runs before anything else. It has to be able to talk UART (or some other interface), check signatures, and write flash. All of these the user code can do as well.

There are many "user-space" bootloaders as well for various chips. The factory bootloader is only different in that it sits in ROM. For example, RP2040 ROM bootloader is here https://github.com/raspberrypi/pico-bootrom

And the UF2 reference from Microsoft: https://github.com/microsoft/uf2/blob/master/README.md

I'm compiling a very stripped down example from https://github.com/embassy-rs/nrf-softdevice that should just loop forever and turn an LED on and off. I convert from a binary to the uf2 using this script linked in the adafruit bootloader repository. The command I run is uf2conv.py -c -b 0x26000 -f 0xADA52840. When running file on my binary the output is UF2 firmware image, family Nordic NRF52840, address 0x026000, 42 total blocks, exactly the same as on the ZMK image that works without a problem.

How can I (someone with no electronics or programming experience) configure my own layout using QMK Config and then compile it into a .uf2 file that works on the Sea-Picro with my Ferris Sweep?

In case you haven't seen the UF2 file format, it's specifically designed to be robust w.r.t ensuring that the content makes it to the target intact despite common OS quirks.

https://github.com/microsoft/uf2

  - Data is divided into 512 byte blocks, which lines up with the mass storage transfer size.

The bootloader uses the UF2 protocol, which is cleverly designed to allow "drag and drop" flashing over USB mass storage.

I'd strongly recommend using an application-specific USB bootloader if possible. The UF2 firmware update protocol is particularly slick, as it allows users to upload new firmware over USB mass storage and requires no staging space; if using this is an option, I'd go for it.

The mentioned UF2 standard (UF2 - mdf5 checksum) actually offers the option to specifiy an MD5 checksum. Which is heavier on resources.