that’s right. The manifest file contains items which describe the build. I.e.
info about what packages were included, their
version numbers, time of the build, target definition etc.
The reason I added this was because I did not want to have to build bin2img, a
separate target, just to assign
a version number to an image.
Previously what you had to do (when you wanted to have a meaningful version
number for your build), was
to execute ‘newt target build’ for your target and run bin2img manually.
Part of this was hidden by the download scripts, which executed bin2img
automatically, but the version number
assignment was problematic.
Now you can execute ‘newt target label’, and this builds your image, creates
image file with header file and version
number on it. Also creating this manifest file in the process. In fact, I was
going to get rid of bin2img tool completely.
+1
Our targets don’t contain info about whether image header is required or not.
So it is up to the user to know
whether they execute ‘newt target build’ only or ‘newt target label’.
So build creates the ELF file, and label creates the image that the
bootloader can... boot. Is that correct?
I assume these are broken into 2 steps, because you don't want to
re-build the target when you build the image.
I think label is a little confusing, I get it: you are labeling the
binary, but I think we should name it more explicitly: what about
create-image?
>> 2. Is version number the only input allowed now or can we add other
labels to the image header? In the future?
There is something else also. I changed the image format such that you can have
TLVs at the end of image.
First TLV I added was SHA over the image; bootloader checks that this matches
the binary before executing
it. Next I would add optional signature TLV (RSA or similar) calculated over
the SHA. This so that you can create
products where bootloader only allows signed images to boot.
+1
Sterling
