Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?
(It just takes a long time for the OS to recognize a USB device. And you have to press the reset button yourself in order to enter the bootloader. With something like J-Link, your build script can handle pressing the reset button and sending the code, saving you quite a bit of time between iterations.)
I make open source espresso machine hardware (github.com/variegated-coffee), and it's nice to be able to give users a wired way to update firmwares that doesn't require extra hardware.
However, the appeal of mounting as a mass storage device is not for iterative development (as you mentioned). Invariably something breaks, and the easiest way to get back on track is to reflash their default blank firmware using the mass storage interface.
UMS seems like a nice idea when you first hear about it, but it doesn't really offer much once you look at it closer. The only proper argument for it is "no special software needed", but it a world where picotool is `apt install picotool` away that's not very advantageous anyway and only causes automount annoyances.
UMS shines where you have a device with a filesystem in its flash that you can access to actually manage the files stored there. Super useful for stuff like MicroPython. In contrast, pseudo-mass storage like on RP2040 doesn't seem very useful at all. It makes it appear more approachable, but only superficially.
I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there. Plop a tiny switch on the PCB, and even if I screw up an OTA update customers will still be able to flash with no special tools (if the device has a USB port, that is).
I also use it as a recovery state for panics, makes the device impossible to brick by a panic loop.
That's orthogonal to mass storage mode. ROM bootloaders were standard in this class of microcontrollers for years, but they usually don't use UMS. One could argue that UMS is perhaps better than some custom incompatible solutions, but then that's what DFU is there for - a standard way to flash things over USB.
Small to medium production runs are always a bit of a pain, because you have to do a lot of coordination with the factory when it comes to tooling. You have to ship a custom programmer, get them to install the drivers on whatever OS they are using, and then find a way to write custom code to interact with the programmer and deal with all the possible error conditions.
The RP2040? A simple script which detects the presence of a RPI-labelled flash drive, copies a file, and repeats. Written in half an hour. Drivers? Not an issue. Hardware? Everyone has a USB cable lying around already. Error conditions? It either succeeds, or it doesn't - the OS handles the rest.
If the bootloader itself was faulty, the device would be bricked.
When the bootloader is not read-only, you can upload another bootloader.
This is great in a different way because custom bootloaders allow for more flexibility.
For example, you may want to keep two copies of your firmware on the chip: One that you're uploading, and one you can fall back to if the most recent one has problems. This protects you against failure during firmware upload or post-deployment failure, because you only overwrite one of the two. So if the device switches off while flashing it, and you boot back up, a custom bootloader can just default to the older copy.
But... what if you update the bootloader and it fails?
Then you can't use the bootloader to upload new firmware. Bricked.
To unbrick a bootloader you need to overwrite the bootloader using alternative methods that don't involve the bootloader, which usually involves attaching wires to the print. This is highly inconvenient in a production setting: Maybe your hardware is encased, embedded in a bigger thing, or located on a pole on a mountain top in a different country.
So a read-only bootloader is a safe choice, and you can make other workarounds wrt. flexibility.
My gut says if you're worried about this in the bootloader, it might be doing too much.
When I actually have these conversations with security guys, it's because they've either missed their window on contributing to part selection (in one case because that team hadn't been hired yet!) or no one consulted them in the first place. In both cases the solution is to write some guidelines and get the EEs to use them during part selection in the future.
Stage 1 bootloader is the one in ROM and it normally just reads stage 2 from the flash chip. Stage 2 then initialises the flash properly, and you can have further stages like [2] to implement the trial-rollback procedure.
Stage 1 is a safety net, even if the trial-rollback procedure goes terribly wrong the device can still be unbricked over USB.
[1]: https://blog.usedbytes.com/2021/12/pico-serial-bootloader/
By the way - real commercial MCUs have boot ROMs with connected watchdogs, trial boots, and recovery boot processes.
The bootloader allows you to update the device with new firmware. MCU are different than computers. And since you can't overwrite the bootloader, you can't brick the MCU. You can always just reset it.
fwiw; I've never bricked an MCU buy flashing something weird onto it. The hobbyist MCUs sold are typically quite easy to re-flash with new firmware.
I've never seen other uC accidentally blowing out bootloaders, though. They have clever tricks that prevents write access on a firmware area while also allowing such firmware area updates.
I suspect the author might have heard about some horror stories like AVR's intentional in-circuit programming disabling feature accidentally triggering due to configuration errors upstream to developers or sporadic errors in data transfer, which "just" needs requires +12V input to unlock. Presumably the 2040 won't have such gotchas that scares hobbyists.