Hi Heinrich, On Sun, 9 Feb 2025 at 09:10, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 09.02.25 17:02, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 9 Feb 2025 at 08:53, Heinrich Schuchardt > > <heinrich.schucha...@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.schucha...@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?
It uses the compatible strings from the running devicetree. If you know that it is wrong, or too generic, you could enhance fit_conf_find_compat() to take a compatible string-list instead of an FDT blob, then add a SYSID for reading that from your board's sysinfo driver. How does it work at present? > > > > >> > >> 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. OK, I can see that the current thing is inconsistent, so I don't mind. Regards, Simon