[josteink]

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.

Routers really are quite different from PCs.

[tenebrisalietum]

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.

[monocasa]

> And how do you partition boot-loaders, kernels, and rootfs and such in that tar.gz?

In the past, each of those would be a separate MTD partition with a seperate device file. You just dd them over those files.

[bshipp]

True enough, but I think they used to be even more unique and over time they've become more like PCs.

One of these days I'm going to log in to the admin interface and find candy crush installed.

[vlovich123]

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).