On Wed, 2024-11-06 at 16:40 +0000, Conor Dooley wrote: > On Wed, Nov 06, 2024 at 01:03:08PM +0100, Matthias Schiffer wrote: > > On Tue, 2024-11-05 at 18:55 +0000, Conor Dooley wrote: > > > On Tue, Nov 05, 2024 at 11:40:20AM +0100, Matthias Schiffer wrote: > > > > On Mon, 2024-11-04 at 18:47 +0000, Conor Dooley wrote: > > > > > On Mon, Nov 04, 2024 at 10:47:25AM +0100, Matthias Schiffer wrote: > > > > > > The TQMa62xx is a SoM family with a pluggable connector. The MBa62xx is > > > > > > the matching reference/starterkit carrier board. > > > > > > > > > > Why all the wildcards? Why isn't there a compatible per device in the > > > > > family? > > > > Because all variants use the same Device Tree. There is also only one compatible and one (main) DTSI > > for the AM62 SoC family, which our Device Trees are based on. > > So what varies between the members of the family? There are currently 6 SoCs in the family: - AM6254 - AM6252 - AM6251 - AM6234 - AM6232 - AM6231 They differ in: - Existence of GPU (AM625 vs AM623) - Number of Cortex-A53 cores (last digit) All of these use ti,am625 as their SoC-level compatible. The differences are currently handled by U- Boot, which checks various feature flags in the SoC registers and patches the OS DTB accordingly by removing CPU nodes and disabling the GPU node if necessary. > > > > > For the compatible string we've chosen the TQMa6254 as the representative for the TQMa62xx family. > > > > > > And all the boards in the family are the exact same? > > > > There is a single TQMa62xx PCB, which has some AM62 family SoC installed (AM6254 in the case of the > > TQMa6254, but all AM62 are possible). TQMa62xx is also the name used for marketing when not talking > > about a specific SoC variant: > > https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma62xx/ > > > > Some SoM variants with different RAM/eMMC/SPI-NOR/... do exist, but they don't have separate device > > trees (firmware may patch some variant information into the DTB however, like the correct RAM size). > > > > Choosing one representative for the family including the SoC variant number, but not distinguishing > > minor variants matches the level of detail used for our other SOMs already supported by mainline > > Linux (like the TQMa64xxL and various i.MX-based platforms). > > I don't like any of this wildcard stuff at all, who is to say that the > next soc you put on your SoM won't be an am62a7, which has a specific > compatible in the kernel? Your fallback then would be ti,am62a7 not > ti,am625. Probably someone will say "that's the am62a family not the > am62 family" - but that exact thing is why I hate all of this > wildcarding. It's barely any more effort to have a tqm6231 and a tqm6254 > compatible than what you're doing with wildcard but it is unambiguous. Our intention here is to have one SOM compatible string for each SoC compatible string. As all SoC variants use the same compatible ti,am625, we've chosen to do the same (using tq,am625-tqma6254 as the representative.) A hypothetical SOM using a ti,am62a7 would obviously not use the tq,am625-tqma6254 compatible string. At no point we're including wildcards in our compatible strings - we're reusing a specific compatible string for multiple compatible variants. Or is what you're taking issue with the wildcard in the description string in the YAML? That one I don't have much of an opinion on. Best, Matthias > > > -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider https://www.tq-group.com/
