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

Michal Simek michal.simek at xilinx.com
Tue Jul 19 08:47:01 CEST 2016


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




More information about the U-Boot mailing list