On Fri, 28 Jun 2024 at 08:33, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > Hi Elliot, > > On Fri, 21 Jun 2024 at 23:40, Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote: > > > > Hi Simon, > > > > On Thu, Jun 06, 2024 at 10:00:54AM -0600, Simon Glass wrote: > > > On Wed, 5 Jun 2024 at 11:17, Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote: > > > > On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote: > > > > > Hi Elliot, > > > > > > > > > > I am just picking up the discussion here, which was started on another thread. > > > > > > > > > > I can't see why this new feature is needed. We should be able to use > > > > > compatible strings, as we do now. I added a 'usage' section to the FIT > > > > > spec [1] which might help. I also incorporated the board revision and > > > > > variant information and some notes on how to add to the available > > > > > suffixes. > > > > > > > > > > Does that handle your use case? > > > > > > > > -rev and -sku don't fit the versioning scheme for QTI devices, so this > > > > isn't a generic enough approach. Patch 5 in this series describes the > > > > versioning scheme for us. > > > > > > > > In the other thread, we had talked about using some regex based approach > > > > for matching the root node compatible. I haven't had chance to work on > > > > that proposal and will try to get to it in the next couple weeks. > > > > > > OK, I look forward to it. Please do check the FIT best match approach > > > and see how it might be extended to handle your requirements. So far I > > > have not seen a need for regexes, but it is certainly a possibility. > > > > > > > I spent some time collecting feedback from the team on using compatible > > strings + regex-style approach and we're not able to add a regex library > > into firmware, so this approach unfortunately won't work for us. > > Because we have more axes of board identification than chromebook, using > > FIT's compatible strings isn't a scalable solution for us. I don't think > > we have incompatible problems, we only have more than 2-3 axes of > > information. > > I understand that. I assume that you have a lot of devices that use > the same SoC but different PMICs, displays, etc. Some of these can be > handled in the bootloader, e.g. by detecting hardware and applying an > overlay, or enabling/disabling a node in the DT. It can be useful to > have a hardware-readable ID to indicate things which cannot be probed, > e.g. with GPIOs or ADC + resistors. > > Another option is to give names to your projects, so that machines > with the same SoC but major hardware differences end up with a > different name (see rk3399-xx.dts for examples). > > I'm sure you are already doing some/all of these things. I still feel > (so far) that you don't need to invent something new here. > > Re "FIT's compatible strings isn't a scalable solution for us", how is > what you are doing different from other vendors? Is it the sheer > number of variations, or something else? Here I am referring to the actual number of separate boards which appear in the wild, not the multiplication of the number of axes which produced them.
