I am really surprised that firmware images are not just .tar.gz files renamed to .bin :/. That's how I would have implemented a distribution of new firmware.
And how do you partition boot-loaders, kernels, and rootfs and such in that tar.gz?
Embedded device will be hard coded to look at a fixed point and start booting from there, there’s no UEFI. How will you ensure boot-loaders get unpacked precisely where they need to be?
And that doesn’t even touch the idea of having a router understand a file system before any firmware code is loaded.
I think firmware images are typically not the fixed ROM code the CPU first encounters upon startup, even if they contain U-Boot. Especially if stored in NAND flash they probably aren't.
AR7 platform, for example, the MIPS core runs a small ROM that initializes RAM, then reads some blocks from flash. Not sure how much code you'd need to unpack a tar.gz but completely possible.
They're "like PCs" in the sense that the instruction set has of the CPUs has caught up and in theory you can attach more complicated peripherals. However, unless your embedded product has MMC flash attached (for many applications it doesn't due to cost + physical size) you're SOL for the following reasons:
1. For M4s your storage is typically some kind of SPI flash which doesn't act like the traditional desktop flash you're dealing with. You have to manually specify the address you're reading/writing & you have to do it on block boundaries (multiple KB). You're generally looking at 8-64MB.
2. For M0 your storage is typically flash built-in with potentially even more restrictions.
3. These devices have very little RAM. Decompression means you have to have a way of enforcing constraints on the amount of space you'll need. Aside from the space needed regularly for decompression you may need to buffer the decompressed content in-memory to align with block boundaries. All of this means development time, increased costs & risk for something you may not be able to pull of.
If your vendor actually internally compresses their image then great but generally they don't for all the same reasons (+ sometimes this is touching ROM code in the chip).
One thing hinted at by the other comment thread, but not brought up: in the embedded world, read-write filesystems as you know them are less common, and usually a failsafe mode is desirable. OpenWRT, for instance, uses a JFFS overlay on top of a squashfs (at least in a recent-ish build for a router I have). So you change out the squashfs (and try to figure out what to do with the overlay filesystem), rather than replacing individual files.
Embedded device will be hard coded to look at a fixed point and start booting from there, there’s no UEFI. How will you ensure boot-loaders get unpacked precisely where they need to be?
And that doesn’t even touch the idea of having a router understand a file system before any firmware code is loaded.
Routers really are quite different from PCs.