On Tue, Jul 19, 2016 at 7:46 AM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 18.7.2016 14:05, Mario Six wrote:
>> In certain circumstances it comes in handy to be able to boot into a second
>> U-Boot. But as of now it is not possible to boot a U-Boot binary that is
>> inside
>> a FIT image, which is problematic for projects that e.g. need to guarantee a
>> unbroken chain of trust from SOC all the way into the OS, since the FIT
>> signing
>> mechanism cannot be used.
>>
>> This patch adds the capability to load such FIT images.
>>
>> An example its snippet (utilizing signature verification) might look like the
>> following:
>>
>> images {
>> kernel@1 {
>> description = "2nd stage U-Boot image";
>> data = /incbin/("u-boot-dtb.img.gz");
>> type = "kernel";
>
> Isn't this type weird for u-boot itself?
>
> The rest is good.
>
> Thanks,
> Michal
It is, but the problem is that adding a new type, like "ubootimage," or
something like that, would not be as easy as with the platform-specific image
types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
to account for this new type in common/bootm.c (essentially, add a lot of
additional "|| images.os.type == IH_TYPE_UBOOT").
I didn't think that it was worth the hassle, and it would have the additional
minor problem that it would effectively be a synonym of "kernel," so you could
declare a regular kernel as having type "ubootimage," and U-Boot would happily
boot it; to prevent that we'd have to do more checks, like, e.g. check the os
value against the type and only boot if the combination makes sense or some
such.
It would be nicer to have a dedicated type, but I think it's too much effort
for such a fringe use case; should it become popular, though, I'll happily add
a new type :-)
Best regards,
Mario
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
