[PATCH v4 07/10] rockchip: binman: Include a compatible string in each configuration

[Quentin Schulz]

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 <sjg at chromium.org>
>>>
>>> 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/20250409-fit-compat-v1-0-56df89ef486a@cherry.de/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