[PATCH 1/2] boot: continue in fit_find_config_node()

[Heinrich Schuchardt]

On 09.02.25 17:02, Simon Glass wrote:
> Hi Heinrich,
> 
> On Sun, 9 Feb 2025 at 08:53, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
>>
>> On 09.02.25 15:29, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Sun, 9 Feb 2025 at 04:52, Heinrich Schuchardt
>>> <heinrich.schuchardt at canonical.com> wrote:
>>>>
>>>> If a single configuration node lacks a description, this does not rule out
>>>> that another node with a description matches. Anyway we have the default
>>>> configuration as a fallback.
>>>>
>>>> So continue if a description is missing.
>>>>
>>>
>>> That field is mandatory, so we should really fail if it is missing.
>>>
>>> What problem are you trying to solve here?
>>
>> Sure the field is needed to make a configuration selectable.
> 
> It's actually normally informational. Have you looked a

If the field is informational, we should not worry if it is missing.

> CONFIG_FIT_BEST_MATCH? That is how this is supposed to be done. But
> with starfive_visionfive2 I see:
> 
> # CONFIG_FIT_BEST_MATCH is not set

How would CONFIG_FIT_BEST_MATCH match strings in the EEPROM to a FIT 
configuration?

> 
>>
>> But as long as we can find a good configuration we should boot instead
>> of leaving the user with a bricked device.
> 
> The more likely impact is that people won't bother adding the field on RISC-V.

The current runtime check is inconsistent: You will get an error if the 
first config lacks a description but may not get an error if the last 
one lacks it. And you are potentially bricking bootable devices.

The right place to check is mkimage. Here you can bail out if a string 
is missing without bricking devices.

Best regards

Heinrich