Re: Suggestion Computer-On-Module implementations
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
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 <siro@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-leave@coreboot.org
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:jwerner@chromium.org] Sent: woensdag 10 juli 2019 03:23 To: Patrick Rudolph <siro@das-labor.org> Cc: Felix Held <felix-coreboot@felixheld.de>; Coreboot <coreboot@coreboot.org> 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 <siro@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-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Tue, Jul 9, 2019 at 10:59 PM Frans Hendriks <fhendriks@eltan.com> wrote:
The COM board is 'subset' of mainboard. Suggestion is splitting COM board support (which is not a complete mainboard) from carrier support.
we had this type of board in LinuxBIOS v1 with some PPC systems and followed a similar approach.
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.
Thanks, sorry, I really misunderstood what this was about then. In this case, if the same baseboard can be used with different SOMs (like Nico said), I agree that adding a different toplevel directory makes sense. (Otherwise, the variant approach should be good enough.)
On 10.07.19 07:58, Frans Hendriks wrote:
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 more appropriate term (from embedded world) is SoM - system on module.
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.
Depending on how the kernel is actually booted, there're only few things to customize for the bootloader, eg. serial port, sd phy's, etc. (most of the stuff might be put into DT) Have a look at how busybox handles these things. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287
On 09.07.19 12:41, Patrick Rudolph 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.
It should, it just has different connectors than we are used to.
The configuration (devicetree.cb) heavily depends on the carrier board,
In my experience it's the other way around. Nico
participants (6)
-
Enrico Weigelt, metux IT consult -
Frans Hendriks -
Julius Werner -
Nico Huber -
Patrick Rudolph -
ron minnich