Jeremy Tregunna 
Trying to be open here, and since this is my first time designing a
firmware image format, just looking for feedback.
As a bit of background, this format is meant to provide incremental (read:
not reflash firmware, just replace existing images on the filesystem or add
new ones, or remove existing ones), as well as wholesale kernel and root
filesystem upgrades.
I've worked out that the most my image can be is approximately 22 MB
uncompressed given my current load on my boards.
The layout is as such:
Type: 8-bit
Hardware ID: 16-bit
Update ID: 32-bit
Archive ID: 8-bit
Customer ID: 32-bit
PDUDescription: 1024-bit
Dependant Update ID: 32-bit
PDUStart: 32-bit
PDUEnd: 32-bit
PDUChecksum: 32-bit
Reserved: 128-bit
The "Type" is just a type of update, be it internal (incremental or
wholesale), or distributable (incremental or wholesale). Extraction methods
on board will not accept internal types as installable on the device unless
it's a development board with special base firmware on it to begin with.
The hardware id is just that, a 16-bit number identifying the hardware
being used. Update ID is a 32-bit number serialized representing this
particular update. Archive ID is the type of archive stored (all images
payload data unit (pdu) must be an archive of some sort), valid types are
"zip", "tar", "tar compressed with gzip" and others. PDU description is a
short (maximum 128-byte) string describing what the update is for, so it
can be printed on the web interface allowing the user to verify it meets
the one they downloaded. NUL terminated, so obviously max size is 127
bytes.
Dependant Update ID is akin to the Update ID, just lists the Update ID of
any previous image that it is dependant on. So for instance, any
incremental releases made after a wholesale upgrade will have their
dependant ID set to the Update ID of that wholesale upgrade.
PDU start/end are the offsets in *this* file where the payload data unit is
stored. In addition, a simple CRC32 is done at image creation, and verified
on extraction by way of comparison to the PDU Checksum field. And finally,
I've allocated 128-bits of additional storage for future expansion in case
there's something I've missed.
Now most in here are probably going to ask the obvious question, "where's
the kernel start/end, filesystem start/end offsets in the case of a
wholesale upgrade?" and well, I thought about including that in this header
and did in an earlier version. However, the values are static, I control
the partition layout, so for those updates, the script will define them
that does the upgrade.
Inside the PDU archive is a dir containing the payloads (i.e., kernel +
rootfs), a bin/ dir for pre-install, install and post-install data, and an
installable manifest which stores itself on flash, for all the updates
since the last wholesale update. This way, if another incremental update
depends on another incremental update, we can check that during the
pre-install.
Seems pretty flexible to me, but before i etch it in limestone
(understanding that i may need to make it crumble for some better in the
future), I just want some opinions.
My apologies for the lengthy post.