image_types_qcom: flash raw FIT image to dtb partition for u-boot

[aswinm94]

u-boot can load a raw FIT image directly from a partition without requiring a FAT filesystem wrapper. When the bootloader provider is u-boot, deploy the raw qclinuxfitImage to the dtb partition instead of the vfat-wrapped dtb image used by UEFI bootloaders.

This avoids the overhead of a FAT filesystem on the dtb partition and aligns with u-boot's native ability to parse and load a raw FIT image containing multiple DTBs directly from block storage.

[lumag]

It doesn't feel like a good idea to me. The less deviation we have between boot flows, the better.

[ricardosalveti]

Yeah, this will create a different behavior per bootloader used, which is not good. And when the user switch back to UEFI manually or by not reflashing everything, the behavior will be different and might not work.

[b49020]

@lumag @ricardosalveti actually the boot team plans to migrate to raw multi DTB FIT as well via moving the DTB signatures to another XBL configuration (@ricardosalveti may remember discussions with boot team here). In case of U-Boot, we are going to leverage upstream aligned FIT signatures only which will be embedded in the FIT image itself and it's reasonable ask as to why the FAT container is really needed. We have upstream U-Boot community comments around that already here [1].

And when the user switch back to UEFI manually or by not reflashing everything, the behavior will be different and might not work.

I do agree with the expectations that we should avoid deviations among different boot stacks but at the same point we should try to avoid open source implementation carrying the redundant baggage of downstream implementations. Especially how multi DTBs signatures are supported with downstream UEFI aren't acceptable upstream which makes this FAT container approach redundant. So there is already implementation difference here with respect to secure boot.

[1] https://lore.kernel.org/all/4264e62d-2b59-48d3-a619-aa2a7c6dee89@cherry.de/

[lumag]

@b49020 then we should adapt UEFI implementation to follow upstream recommendations.

[lumag]

@b49020 could you please start the internal discussion with the boot team?

[b49020]

@b49020 then we should adapt UEFI implementation to follow upstream recommendations.

Ideally yes as that's how the UEFI implementation will get true Arm SystemReady compliance.

@b49020 could you please start the internal discussion with the boot team?

Added you to an existing email thread ongoing with the boot team.

[ricardosalveti]

@lumag @ricardosalveti actually the boot team plans to migrate to raw multi DTB FIT as well via moving the DTB signatures to another XBL configuration (@ricardosalveti may remember discussions with boot team here).

I remember the discussion but I don't think I saw a commitment to move to this approach, what I believe they added was support for the firmware to skip the fit validation on signature failures (when uefi secure boot is enabled but not qcom secure boot) since the firmware is also providing a default DTB (outside FIT).

Can you also loop me in the discussion?

[ricardosalveti]

Also, we are using both fit-dtb and combined-dtb based on what is available by the target, so if we move to raw partition we would need to keep both ways working.

[ricardosalveti]

And when the user switch back to UEFI manually or by not reflashing everything, the behavior will be different and might not work.

I do agree with the expectations that we should avoid deviations among different boot stacks but at the same point we should try to avoid open source implementation carrying the redundant baggage of downstream implementations.

That is fine if we manage to update both implementations at the same time, otherwise we will create a different behavior based on the boot firmware used, which is not great.

From my perspective we should merge this change once both implementations are in sync.

[b49020]

@ricardosalveti

Can you also loop me in the discussion?

I see your replies on the internal discussion, so I suppose we are in sync there.

Also, we are using both fit-dtb and combined-dtb based on what is available by the target, so if we move to raw partition we would need to keep both ways working.

From upstream U-Boot point of view, there is only going to be one method supported which will be FIT-DTB using raw partition.

I do agree with the expectations that we should avoid deviations among different boot stacks but at the same point we should try to avoid open source implementation carrying the redundant baggage of downstream implementations.

That is fine if we manage to update both implementations at the same time, otherwise we will create a different behavior based on the boot firmware used, which is not great.

It's an ideal scenario where you expect to synchronize the downstream vs upstream implementations.

From my perspective we should merge this change once both implementations are in sync.

Fair enough, what we can do for now is to carry in staging tree a downstream U-Boot patch to enable FIT-DTB loading from FAT partition in case loading from raw partition fails. Surely we won't be able to carry it all along where at some point we need to conclude if downstream implementation migrates to raw partition or not.

[ricardosalveti]

That is fine if we manage to update both implementations at the same time, otherwise we will create a different behavior based on the boot firmware used, which is not great.

It's an ideal scenario where you expect to synchronize the downstream vs upstream implementations.

As I raised internally, it is even more complicated than I expected because the upstream edk2 implementation is also expecting to use RAW, so ideally we should all just move to RAW (@lool also something that will affect the way we are generating the build artifacts for debian).

From my perspective we should merge this change once both implementations are in sync.

Fair enough, what we can do for now is to carry in staging tree a downstream U-Boot patch to enable FIT-DTB loading from FAT partition in case loading from raw partition fails. Surely we won't be able to carry it all along where at some point we need to conclude if downstream implementation migrates to raw partition or not.

Yeah, this is not great either, as we do want for upstream to just work.

Guess the only real option would be to try to get our downstream to move to RAW, but wonder if this could potentially impact QLI 2.0 (capsule updates from vfat to raw, etc).