Suggestion Computer-On-Module implementations

[Frans Hendriks]

Hi All,

Variants can be used for mainboards. The variants are used for boards within the same mainboard manufacturer directory.
Computer-On-Module (COM) can be used on different carriers which do not have same manufacturer.

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.

What's the opinion on this suggestion?

Met vriendelijke groet / Best regards,
Frans Hendriks

Eltan B.V.
www.eltan.com

[Felix Held]

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)?

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

[Nico Huber]

On 09.07.19 08:57, Frans Hendriks wrote:
> Variants can be used for mainboards. The variants are used for boards within the same mainboard manufacturer directory.
> Computer-On-Module (COM) can be used on different carriers which do not have same manufacturer.
>
> 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.

Yes, that sounds reasonable. I don't care much about the directory name
but Felix made a good point.
> mainboard will use this COM module and contains the 'variant' code.

Agreed. I think this is the best solution. However I'm not sure how
easy/hard this will be to set up. Currently, the base and all variants
live in one common directory structure.

And there is one downside if we apply the current variant scheme: It
would work well enough for carrier boards that are specifically designed
for one project and the use with one specific COM. However, if you con-
sider more generic carrier boards (e.g. those evaluation carriers by
COMe vendors) or any carrier board that would be used with different
COMs, you'd have to copy the carrier-board code as a variant for each of
the COMs.

So for the long run, I propose to treat COMs like this: In their device-
tree, tag all devices that are connected to the COM interface with the
name given by the interface standard (if there is any). The carrier
boards would then not have a single devicetree but sub trees rooting at
each of the named interfaces. This way, one could just select in Kconfig
which (compatible) COM they have on the carrier ;)

I'll try to find the time to write down some example devicetree how
this could look like.

Nico