Hi Jonas, Simon,
On 4/9/25 5:05 PM, Jonas Karlman wrote:
Hi Quentin,
On 2025-04-09 12:02, Quentin Schulz wrote:
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
From: Simon Glass <[email protected]>
Provide a compatible string in the config nodes that U-Boot can use to
help decide which configuration to use.
Can you tell us more about this?
I think the VBE can use this to determine what config/fdt would be used
in a multi-dtb FIT image.
This also sparked an idea to use this compatible for board selection in SPL
instead of the description (fdtfile) field. I have started to play around
with a board_fit_config_compatible_match() a few patches in at [1], e.g.:
- WIP: boot: fit: add board_fit_config_compatible_match()
- WIP: rockchip: implement fit config compatible match for boards
[1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/for-next
That could also be used for having board specific TPL+SPL and use a
single multi-dtb FIT with U-Boot proper and multiple fdt/config nodes,
one for each board.
I don't think mkimage -l/dumpimage -l actually provide that information
and the docs are sparse as to what "so that things work correctly with
FIT's configuration-matching algortihm." means.
Looking a bit into tools/binman/ftest.py it seems like it's a way to
expose the DT compatible property from within the first entry in `fdt`
array property (a DTB) into the configuration node in the fit image.
Seems like it's a bit more involved than that, c.f.
https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Thanks both of you for the pointers.
I think it'd make sense to update dumpimage/mkimage/etc... to dump that
information as well?
I think so too, I know there are a few load/entry addresses for some
image type that is also not shown by dumpimage. This is something that
can be improved in a different series.
I've sent something for this compatible conf node property:
https://lore.kernel.org/u-boot/[email protected]/T/#t
But indeed, seems like we're missing printing the "script" property and
many others related to signing for example. There's also a few image
properties that are only printed based on the type, e.g. "Architecture"
only for kernel, standalone, ramdisk, firmware and fdt types, "OS" onylk
for kernel, ramdisk and firmware. Not sure what the reasoning is.
Cheers,
Quentin
