[LEDE-DEV] [RFC] sysupgrade image format

[Felix Fietkau]

On 2016-06-10 10:55, John Crispin wrote:
> Hi,
> 
> some comments inline
> 
> On 09/06/2016 20:41, Alexander Couzens wrote:
>> Hi,
>> 
>> I'm posting the results of a small group who talked about the
>> sysupgrade image format at the battlemesh in Porto.
>> 
>> sysupgrade
>> ##########
>>  * don't limit our format by vendor image limitations
> 
> i dont understand what is meant by this
Limitations such as not having a board id to prevent flashing
incompatible images.

>>  * should contain meta information
>>  * meta data like compatible boards, lede version, ..
>>  * meta data gets appended as Trailer to be compatible
> 
> that wont work for images that have a checksum at the end
I don't think any of our sysupgrade images have a checksum at the end.
The -factory.bin image format remains unaffected by this proposal.

>>  * trailer got automatic removed by jffs2 format on first-boot
> 
> only works if the kernel is located before the roots and if the image
> actually uses jffs2
In the case of rootfs + kernel, the trailer might end up on flash, but
in a harmless place. Note: it will only end up on flash if a new
sysupgrade image was flashed over a firmware that does not understand
this metadata. In all other cases it will be stripped before flashing
starts.

>>  * meta data is a tar ball (compressed)
>> 
>> sysupgrade.img := image + meta + trailer
>> 
>> Trailer
>> #######
>>  * 8 byte version field (of the trailer) + additional unknown
>>    informations
> 
> why 8 bytes ? would kvl or json not be much more appropriate ?
This is just a fixed length field we can use in case we have to change
the layout/format of the main metadata area. Ideally the version here
would never change after the format is defined.

>>  * 4 byte length of the metadata
> 
> putting the length at the end of a file is always weird. why no have a
> header, that would save us having to seek the end and not be sure if the
> file is completed
To ensure that the sysupgrade images are backwards compatible for
upgrading from devices running older firmware.

>>  * x byte crypto signature
> who would be owner of the key ?
Whatever key is put in during the build process. For releases this would
be a key that is part of the lede keyring. For custom builds it could be
the main build key.

- Felix