Re: [PATCH v2 0/3] Add RITY devicetree preparation support

["Carlo Caione" <ccaione@baylibre.com>]

On Sun Aug 30, 2026 at 10:54 PM CEST, Peter Robinson wrote:
> On Sun, 30 Aug 2026 at 21:47, Marek Vasut <marek.vasut@mailbox.org> 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