I think you’ve got the wrong end of the stick here.
There are many places that peripheral firmware could be stored:
- embedded within the peripheral that needs it itself - and no action by the operating system is required at boot time (the peripheral firmware is already where it needs to be)
- on a separate, dedicated flash chip that exists largely or solely for the purposes of holding firmware (aka firmware jail) - and the peripheral firmware is copied by the operating system from the flash chip to the peripheral at boot time
- on the operating system disk - and the peripheral firmware is copied by the operating system from the disk to the peripheral at boot time
The primary goal of Purism’s design is to avoid specifically the third of those options i.e. no peripheral firmware on the disk.
It is also noted that for peripheral firmware that relates to the boot disk, it is difficult or impossible to have the firmware on the disk anyway (chicken and egg problem). So most storage devices opt for the first of those options.
The approach taken will differ from peripheral to peripheral, and from product to product.
Also note that, regarding the first option, it may or may not be possible to update the firmware at all. It is assumed that there is some way of updating the firmware with the second option. It is obvious that the firmware can be updated with the third option.
That’s definitely not right. In any modern computer, there are a heap of blobs, although some of them may be invisible and some of them may not in practice be able to be updated (for a variety of reasons).
At a minimum, the WiFi card has a blob (but the source of the blob differs between the original WiFi card - blob is embedded - and the more recent WiFi card - blob is in firmware jail) - but also the power delivery controller has firmware, the touchscreen controller has firmware, the GPS module has firmware, the smartcard reader has firmware, and of course the cellular modem has firmware. And as discussed the eMMC drive would have firmware. Maybe I missed some.
With all these blobs, and all these potentially hostile peripherals, different strategies are employed to manage that. One of the main strategies is that the peripheral does not have direct access to memory - a communication bus can only be used where the host can only ever be the bus master etc.
Another strategy, as used with WiFi, is that ideally all traffic is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). The same strategy, as used with disk storage, is that ideally all content is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). In either case, ideally content is also integrity protected (so even if the hostile blob is maliciously altering content, the host can detect that). By default that does not occur with disk storage although theoretically LUKS has an option for the brave for that.
My understanding is that uboot resides on the eMMC drive. So it is more in the nature of a primary bootloader than firmware. Being on the disk, it can of course be written to.
The terms “flash” and “reflash” are confusing here - because noone ever talks about reflashing a USB flash drive, we just talking about writing to it - even though all of the following are in fact flash storage: NVMe disk, SATA SSD, USB flash drive, USB portable SSD, eMMC drive, SD card, flash chip. There are great differences in how they are accessed but ultimately they are all flash storage.