It's not related to a project but general support for computer-on-module (COM) boards. COM board is a single-board computers containing CPU, Memory, Chipset (SoC). These boards don't contain the standard connectors for I/O. These boards need to be placed on a carrier board (baseboad), which provides the standard I/O connectors and the power. The connection between the COM and carrier boards is a Qseven/Com Express/ETX/etc connector. Also non-standard connection is possible.
coreboot is running on COM boards, but the coreboot configuration/settings would depend on the used carrier board. The carrier can also contains EC, SIO devices. In embedded market using COM is very common. The COM board is 'subset' of mainboard. Suggestion is splitting COM board support (which is not a complete mainboard) from carrier support. Regards, Frans -----Original Message----- From: Julius Werner [mailto:[email protected]] Sent: woensdag 10 juli 2019 03:23 To: Patrick Rudolph <[email protected]> Cc: Felix Held <[email protected]>; Coreboot <[email protected]> Subject: [coreboot] Re: Suggestion Computer-On-Module implementations 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 <[email protected]> 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 -- [email protected] To unsubscribe send an > email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
