Could you guys explain your board layout a little more for those of us not familiar with your project? Is this SOM/COM something that runs coreboot code, or just something that the SoC running coreboot code talks to? In the latter case, I would say that it's a peripheral and thus its code belongs under src/drivers/ (e.g. maybe src/drivers/som/<vendor>/<model>). (Although there is some precedent with src/ec and src/superio to have this stuff at top-level... I guess the question is whether this module has the same kind of exceptional position on the board as those other chips.)
On Tue, Jul 9, 2019 at 3:42 AM Patrick Rudolph <s...@das-labor.org> wrote: > > Hi Frans and Felix, > > On 2019-07-09 11:56 AM, Felix Held wrote: > > Hi Frans! > > > >> Proposal is creating a COM directory ‘src/com’ where the module > >> manufacturer and module name are used. (Similar to mainboard). > >> In this src/com directory common module support is placed. > >> mainboard will use this COM module and contains the ‘variant’ code. > > > > Sounds like a good idea to me; I wouldn't call the directory src/com > > though since my first association with that name would be some sort of > > communication device support. Maybe src/som (system on module)? > > > > Technically a SOM/COM wont work at all without a carrier board. > The configuration (devicetree.cb) heavily depends on the carrier board, > but on the > other hand the GPIO configuration is likely SOM specific. > > I guess it's a good idea to put *non mainboard-specific* code in src/som > (or whatever). > On the other hand as already said the variant scheme works quite well. > > > I think I talked with Nico and siro on that some months ago on IRC, so > > it would be good if they could also comment on this. > > > > I think the other option we talked about was having the module as a > > base and the official carrier board as mainboard variant and then use > > the module code in a mainboard with the vendor being the vendor of the > > carrier module which is a variant of the other mainboard code. > > Putting this into a separate directory is probably the cleaner option > > though. > > > > If the variants approach works well for that, I'd like to keep using > > that and not introducing some new infrastructure; if that causes some > > major pain, it might also be worth investigating how to improve things > > there. > > > > Regards > > Felix > > > If we decide to go either way the documentation should be updated to > explain this decision. > > Regards, > Patrick > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
