"newt target label" command question

[aditi hilbert <ad...@runtime.io>]

Hi,

I’d like to verify my understanding.

1. When I run “newt target label" for a certain target build it generates the manifest.json file in the project/<project-name>/bin/<target-name> directory - correct? If it is actually appending an image header to the image, the .bin image must also change. Is that right? What else is changed? What about a target without a .bin image (e.g. bin2img)?

2. Is version number the only input allowed now or can we add other labels to the image header? In the future?

3. Can I undo the label? Looks like if I run the command again with a different version number it overwrites the version.

thanks,
aditi

Re: "newt target label" command question

[marko kiiskila <ma...@runtime.io>]

> On Feb 25, 2016, at 10:25 AM, Sterling Hughes <st...@apache.org> wrote:
> 
>> 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.

It does call build to make sure you’re working on the latest .bin. Assuming the dependencies work, no
actual work takes place there.

> 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?

I wasn’t happy with ‘label' either. Left it as is in search of a better one.
‘create-image’ sounds better.

Re: "newt target label" command question

[Sterling Hughes <st...@apache.org>]

> 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

Re: "newt target label" command question

[marko kiiskila <ma...@runtime.io>]

Good questions.

> On Feb 24, 2016, at 6:13 PM, aditi hilbert <ad...@runtime.io> wrote:
> 
> Hi,
> 
> I’d like to verify my understanding.
> 
> 1. When I run “newt target label" for a certain target build it generates the manifest.json file in the project/<project-name>/bin/<target-name> directory - correct? If it is actually appending an image header to the image, the .bin image must also change. Is that right? What else is changed? What about a target without a .bin image (e.g. bin2img)?

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.

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

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

> 
> 3. Can I undo the label? Looks like if I run the command again with a different version number it overwrites the version.

Yes. The tool creates the image file from binary every time it’s executed.