On 8/31/26 9:54 AM, Carlo Caione wrote:
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).
Can you extend the existing code instead of adding yet another
incomplete parallel implementation of it ?
The RITY boot contract supports (among other things):
- selecting the base DTB and an ordered overlay list at runtime through
the environment
This is scriptable , see loaddtos/loaddtoscustom in
https://github.com/dh-electronics/meta-dhsom-imx-bsp/blob/main/recipes-bsp/u-boot/files/dh-imx-dhsom/boot.cmd
.
- loading those files from either block-backed filesystems or UBI/UBIFS
You can load fitImage from wherever you want.
- accepting both raw DT files and individually signed FIT-wrapped DT
files
See above.
- preparing the same resulting DT for both the normal EFI boot path and
the legacy boot path
See 'fdt apply' in the script above.
- allowing Genio tooling, in particular genio-flash --load-dtbo, to
modify the overlay selection without rebuilding the image (important)
See mkimage -F parameter.
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.
You could pull both images and configurations out of fitImage , look at
imxtract .
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.
I think this is the main reason, because all the rest can be solved with
already in-tree content.
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.
Non-generic goop like that makes maintenance harder. Can you instead
introduce some adaptation layer/tool which would convert images back and
forth ?
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 :)
It would be much better to reuse existing generic well tested code than
introduce ad-hoc new special-case for specific SoC.
