Hi Ahmad, On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > Hello Simon, > > On 29.11.23 20:44, Simon Glass wrote: > > Hi Ahmad, > > > > On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >> > >> On 29.11.23 20:27, Simon Glass wrote: > >>> On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >>>> On 29.11.23 20:02, Simon Glass wrote: > >>>>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >>>>>> The specification says that this is the root U-Boot compatible, > >>>>>> which I presume to mean the top-level compatible, which makes sense to me. > >>>>>> > >>>>>> The code here though adds all compatible strings from the device tree though, > >>>>>> is this intended? > >>>>> > >>>>> Yes, since it saves needing to read in each DT just to get the > >>>>> compatible stringlist. > >>>> > >>>> The spec reads as if only one string (root) is supposed to be in the list. > >>>> The script adds all compatibles though. This is not really useful as a bootloader > >>>> that's compatible with e.g. fsl,imx8mm would just take the first device tree > >>>> with that SoC, which is most likely to be wrong. It would be better to just > >>>> specify the top-level compatible, so the bootloader fails instead of taking > >>>> the first DT it finds. > >>> > >>> We do need to have a list, since we have to support different board revs, etc. > >> > >> Can you give me an example? The way I see it, a bootloader with > >> compatible "vendor,board" and a FIT with configuration with compatibles: > >> > >> "vendor,board-rev-a", "vendor,board" > >> "vendor,board-rev-b", "vendor,board" > >> > >> would just result in the bootloader booting the first configuration, even if > >> the device is actually rev-b. > > > > You need to find the best match, not just any match. This is > > documented in the function comment for fit_conf_find_compat(). > > In my above example, both configuration are equally good. > Can you give me an example where it makes sense to have multiple > compatibles automatically extracted from the device tree compatible? > > The way I see it having more than one compatible here just has > downsides. I don't have an example to hand, but this is the required mechanism of FIT. This feature has been in place for many years and is used by ChromeOS, at least. > > >> The configuration already has a compatible entry. What extra use is the compatible > >> entry in the FDT node? > > > > It allows seeing the compatible stringlist without having to read the > > FDT itself. I don't believe it is necessary though, so long as we are > > scanning the configurations and not the FDT nodes. > > I think it's better to drop this if it has no use. OK. I cannot think of a use for it. Regards, Simon
