Hi Ahmad, On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > Hello Simon, > > On 30.11.23 21:30, Simon Glass wrote: > > On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >> On 29.11.23 20:44, Simon Glass wrote: > >>> 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. > > I see the utility of a FIT configuration with > > compatible = "vendor,board-rev-a", "vendor,board-rev-b"; > > I fail to see a utility for a configuration with > > compatible = "vendor,board", "vendor,SoM", "vendor,SoC"; > > Any configuration that ends up being booted because "vendor,SoC" was matched is > most likely doomed to fail. Therefore, I would suggest that only the top level > configuration is written into the FIT configurations automatically. Firstly, I am not an expert on this. Say you have a board with variants. The compatible string in U-Boot may be something like: "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", "rockchip,rk3288"; If you then have several FIT configurations, they may be something like: "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron", "rockchip,rk3288"; "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", "rockchip,rk3288"; "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron", "rockchip,rk3288"; You want to choose the second one, since it is a better match than the others. +Doug Anderson who knows a lot more about this than me. Regards, Simon
