[U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Tue, Jul 19, 2016 at 8:47 AM, Michal Simek <michal.simek at xilinx.com> wrote:
> On 19.7.2016 08:45, Mario Six wrote:
>> On Tue, Jul 19, 2016 at 7:46 AM, Michal Simek <michal.simek at 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 at 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 at 1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel at 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