On Sun Aug 30, 2026 at 10:54 PM CEST, Peter Robinson wrote: > On Sun, 30 Aug 2026 at 21:47, Marek Vasut <[email protected]> wrote:
[...] >> >>> RITY images select a base devicetree and an ordered list of overlays >> >> >> >> What's an RITY image? >> > >> > Fair enough. Since this is all MediaTek-specific code, I took the term >> > for granted, sorry about that. Anyway, RITY is MediaTek’s Genio IoT >> > Yocto SDK. By a "RITY image", I mean a boot image produced by that SDK. >> >> Can this instead use fitImage core code which can already apply DTOs on >> top of base DT ? > > Or boot using UEFI and be generic, deal with the DT overlays with > standard U-Boot mechanisms. Hi Marek, hi Peter, In principle, yes, we could use FIT core, or the EFI bootmeth together with the extension-board framework, to implement parts of this. The problem is that neither currently covers the complete interface we need (and we are using). The RITY boot contract supports (among other things): - selecting the base DTB and an ordered overlay list at runtime through the environment - loading those files from either block-backed filesystems or UBI/UBIFS - accepting both raw DT files and individually signed FIT-wrapped DT files - preparing the same resulting DT for both the normal EFI boot path and the legacy boot path - allowing Genio tooling, in particular genio-flash --load-dtbo, to modify the overlay selection without rebuilding the image (important) Now, the core problem is that using FIT core for the complete operation would require changing the image producer and on-media format so that the selected DTB and overlays are represented by a FIT configuration. The EFI payload would still be discovered independently. Also the EFI extension-board support is useful for automatically detected hardware, but it does not currently consume the user-configurable ordered overlay list, cover the UBI/UBIFS and legacy boot cases, or handle the individually signed DT files. One of our objectives is to allow existing RITY users to replace the vendor U-Boot with upstream U-Boot without also changing their images, tooling and environment interface. Changing the RITY interface and image layout would prevent that kind of drop-in transition, and it is something we would prefer to avoid (at least at this stage). This is why we are proposing the functionality as a platform-specific well-compartmentalized command. If preserving that existing contract is not considered sufficient justification for platform-specific code, please let me know. In that case we will need to reconsider the approach and find another way forward (still unclear which :) Thanks, -- Carlo Caione
