On Tue, Jul 19, 2016 at 8:47 AM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 19.7.2016 08:45, Mario Six wrote:
>> 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 :-)
>
> Is the type property even required for this case?
>
> Thanks,
> Michal
I just tried to boot one without the type, and apparently it is required:
## Loading kernel from FIT Image at 02000000 ...
Using 'config@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@1' kernel subimage
Description: 2nd stage U-Boot image
Type: Unknown Image
Compression: gzip compressed
Data Start: 0x020000d4
Data Size: 206485 Bytes = 201.6 KiB
Sign algo: sha256,rsa4096:ccdc
Sign value: ...
Verifying Hash Integrity ... sha256,rsa4096:ccdc+ OK
No U-Boot ARM Kernel Image Image
ERROR: can't get kernel image!
That makes sense, since common/bootm.c checks the image type in several places.
Best regards,
Mario
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
