On 14/12/2023 08.33, Masahiro Yamada wrote:
> On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>>
> One more question to confirm if I can use this
> for my practical use-cases.
>
> Is U-Boot able to handle FIT (includes kernel + DTs)
> and a separate initrd?
>
> # bootm <fit-address>:<conf-name> <ramdisk-address>
>
>
> Presumably, it would be difficult to inject initramdisk
> into image.fit later, so I am hoping bootm would work like that,
> but I did not delve into U-Boot code.
I recently had occasion to use this, and it actually already works
out-of-the-box, but perhaps it could be better documented. Though you
need not only the ramdisk address but also the size, as in
<addr>:<size>, and of course CONFIG_SUPPORT_RAW_INITRD.
My use case is bootstrapping: I have one FIT image (consisting of
kernel, dtbs and an initramfs) which is the one that will be written to
the target. But for bootstrapping, I (obviously) need to boot with a
different initramfs that contains the bootstrap logic. Since this
project uses fastboot, what I do is: upload the alternative initramfs,
move it out of the way ('cause fastboot only supports one single target
buffer), upload the FIT image, and "bootm $fitaddr $initrdaddr:$initrdsize".
> If it works, is it possible to verify the integrity of initrd?
No, I don't think so. In my case the FIT image is signed, and the kernel
and chosen dtb does get verified, but not the contents of the initrd.
I'm not sure how that should happen - in any case, in the fastboot case,
the host can run arbitrary shell commands so not much U-Boot can do.
Rasmus
