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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
