SOM for embedded computing: SGET.org Qseven and Smarc

[aventuri]

Hello,
this post talks about "system on module" (SOM) so it's not completely on topic in this place, but didn't found any better..

recently i've seen Olimex pushing their new SOM module (supposed to be multi SOC..) and i found it quite interesting for developing a carrier with some kind of future-proofness..

then, googling here and there i found the standard Qseven and Smarc form the SGET.ORG consortium.

Anyway, these kind of standardized solutions are not matching well the flood of powerful low cost SOCs like Allwinner Rockchip Amlogic, neither Exynos or Snapdragon, but rely on the higher end offering from Intel Atom, Xilinx Zynq and Freescale/NXP iMX6..  so this puzzles me a bit.

so my question is:
* do you have experience on these Qseven solutions / modules? are these cost effective, in the end?
* do you think a standard approach is better over a proprietary solution or it doesn't make a real difference?

[tszaboo]

I wouldn't touch these chinese SOCs with a ten feet pole. They are not documented at all, you just get a barely working Linux distro and you are on your own. If there is an issue, which requires change in drivers, you are screwed, since no documentation.
Intel and AMD makes products obsolete before you can download the specification.
Go with Motorola / Freescale / NXP / Nexperia (?) / Qualcomm(?). iMX 28/6/7/8 or similar.

There are also other priorities, like the availability of the module and support. Dont just go with the cheapest one. I dont think a "standard" is better than a custom. Also, check Toradex.

[dgtl]

I've had experience with 2 major SOM manufacturers. At trade shows, the salesmen sell you how easy everything is and how they take care of the hard part. The real world is that they cannot have tested all possible configurations that the modules can be used in. As the products were made, some issues came up with both manufacturers modules with some peripherals, that they probably did not test (ie imx6 camera interface). At that point, there was no communications from them anymore and we were on our own. Even worse, we had a black box in the system that we had to get working. Probably they don't care if you are not a large customer. At the same time, for large volumes it does make sense to put the SoC on the board, not use any modules.
Anyway, lesson learned. Copypasting evaluation board schematics and layout is not that much more work than designing in a module with questionable documentation and large SODIMM connector. When doing the first way, you at least know what to expect. Otherwise, you may still have to do everything yourself, but add some reverse engineering to that.

Things get different if you choose a SoC with no documentation and without open source software (ie X86 stuff etc). Then you just cannot do it yourself from ground up, either the module works or you're doomed.

[funkathustra]

so my question is:
* do you have experience on these Qseven solutions / modules? are these cost effective, in the end?
* do you think a standard approach is better over a proprietary solution or it doesn't make a real difference?

To answer your second question, I don't think there's any reason to standardize the SOM module. There's a bazillion SoCs out there, and they all have different sets of peripherals. How would you possibly come up with a SOM form-factor that fits all of them?

The only time I've seen universal SoMs used in a project is in industrial systems that were built to replace a PC. There, size/power consumption doesn't matter.

But everywhere else, products need to be *small* and battery-operated. That's hard to do with a one-size-fits-all SoM architecture.

And what do you get from that approach? The ability to swap out SoM modules without redesigning a board? I've never gotten far into a project and thought, "oh, gee, I'd really like to completely switch CPU architectures, but then I would have to spend an afternoon re-routing my board! Yuck!"

Why? Because, in the end, PCB layout for a SOM is trivial --- but porting a BSP from one architecture to another is far more yucky.

And that's the thing that SoM manufacturers don't tell you: sure, they'll give you a reference BSP, but there's a *ton* of kernel work required to get your system up and running, and none of that is stuff that a SoM manufacturer can accomplish.

I wouldn't touch these chinese SOCs with a ten feet pole. They are not documented at all, you just get a barely working Linux distro and you are on your own. If there is an issue, which requires change in drivers, you are screwed, since no documentation.

Completely disagree. The AllWinner stuff I've done before integrates really nicely into my Yocto-based environment, and doesn't feel any different than when I'm targetting an i.MX6 or a TI job. The reference manuals are perfectly fine --- no worse than any other.

The big problem that plagued these SoCs for years was long-term availability. Production moves rapidly in China, so you're sort of expected to buy your 5k units, pump out the design, and then move onto the next thing. Us lazy, slow American companies move at a snail's pace, and want to keep pumping out the same dumb industrial control/monitoring project for 15 years without having to update/innovate, so we need long-term commitments from our silicon vendors.

[lundmar]

This SOM is really nice and comes with good Linux support:

https://www.solid-run.com/freescale-imx6-family/imx6-som

[lukier]

This SOM is really nice and comes with good Linux support:

https://www.solid-run.com/freescale-imx6-family/imx6-som

Thanks for the link.

At first I was like: "they want how much!?!", it is quite a bit compared to various OrangePi Zero boards and the like with similar specs (1 GHz, 512 MB RAM) and even featuring things that cost extra (WiFi module, MagJack and USB connectors etc) that SoM doesn't have.

But then I've noticed how professional these modules are. the amount of documentation provided, product change notices, reliability reports, longevity up to 2022 etc. Taking all that into account it doesn't look that bad.

[lundmar]

But then I've noticed how professional these modules are. the amount of documentation provided, product change notices, reliability reports, longevity up to 2022 etc. Taking all that into account it doesn't look that bad.

Exactly - one has to consider the full package. Also, I like that their SOMs are more compact than most other offerings.

[lukier]

You can roll out your own board and use NXP official BSP. Their BSP is very thorough and there's no need to use a board mfg's own BSP.
But in case you do need a particular feature of a mfg's own BSP, since they are open source, you can just get them for free.
NXP even has a book published by PACKT documenting how to use their iMX6 BSP.

That is true in this case as the IC is quite open-source friendly. I guess the reason to go SoM is different - I don't have either time or skills to design 6-8 layer board with DDR3. By the time I would get it right I would spend much more money than even the expensive professional SoMs cost. It also depends heavily on volume.

[aventuri]

thanx for all the contributions.. great community!

let me recap a bit after the first day what i understood:

• no one talks about a success story about any standardized SOM connector; it's a fact! it looks like there's no real gain. that's why they are out for around 10 years but didn't achieve full consensus
• a factor to be considered for the "SOM approach" is anyway the presumed volume of the production. SOM are tailored for Q. between 100-1000?
• this thread has derailed toward a "how to simply design a SOC/RAM link"! it looks a "more sexy" theme than "when/which SOM put on a board" :-)
• it's not clear how much a BSP is key or not when moving from one SOC/SOM to another. me i'm fan of buildroot  so i like "light approach" where one's in control. Yocto looks to me too "corporate" (if you know what i mean..)

[lundmar]

it's not clear how much a BSP is key or not when moving from one SOC/SOM to another. me i'm fan of buildroot  so i like "light approach" where one's in control. Yocto looks to me too "corporate" (if you know what i mean..)[/li][/list]

To me it is important that the SOMs BSP comes with a recent, well functioning, stable Linux kernel and boot loader. The best way to make sure of this is to test the SOM in combination with a supported motherboard so that one can test the various kernel features of interest as thoroughly as possible. In worst case you will experience crashy drivers causing instability forcing you to spend a lot of time hunting and eliminating bugs within the Linux kernel space. Even if you identify the bugs you might end up in trouble trying to fix them by backporting bugfix patches from more recent Linux kernels simply because the code base has grown too different. One want to avoid this situation so testing the Linux kernel before choosing your SOM is a very good activity that can save you a lot of development cost. Also worth considering is that you don't want a too old kernel if you have security concerns.

When it comes to userspace I would choose buildroot over Yocto any day. Yocto is fine if it works but if something fails to build or if you need to do modifications you will have to invest a lot more time - the noise and bloat level of Yocto is fascinating. In my opinion, buildroot is simpler and better structured thus better and adequate for most small to medium sized systems.