We have now several SOMs for A13, A20, AM3352, RK3188.
Each of them with different layout and pinouts as our initial intention was to expose all possible features of every processor.
The experience we got from selling the SOMs for the past 5 years is that 99% of customers do not need all specific interfaces, but few common interfaces.
For instance very few customer need 12 UARTs and 6 I2C in their design, but almost all need Ethernet, HDMI, SATA etc.
Another important point is that soon or later the project they working on scale up and they need more memory or more processor power and with the current SOMs they have no option but redesign.
Every big customer need longevity assurance. They do not want to change their design every couple of years when the SOC manufacturer obsolete their processors, they do not want to re-design every 6 month when new processor with 4-6-8-10-12-24 cores appear to the market with preliminary buggy software support.
So with the years one another idea evolved – we should try to make one universal SOM layout with known interfaces on known pinout, so if customer need more memory he just switch to SOM with same pinout but more memory, if need more power he switch to SOM with same pinout but more powerful SOC.
We have experience with Allwinner, Rockchip and TI, so we considered these processors as potential new SOM SOCs:
A20, A64, RK3399, AM335X
After long discussions we decided that the universal SOM should have these signals:
- USB-OTG
- USB-HOST1
- USB-HOST2
- HSIC
- USB3
- PCIe
- Ethernet1 Megabit/Gigabit
- Ethernet2 Megabit/Gigabit
- WiFi+BLE
- SATA
- SD-CARD
- CAN
- IR
- CSI
- HDMI
- VGA
- Audio In
- Audio Out
- SPDIF
- UEXT1 -> SPI1, I2C1, UART1
- UEXT2 -> SPI2, I2C2, UART2
The first SOM204 we made is obviously for A20.
Here are the schematics of A20-SOM204 and SOM204-EVB.
Here is our A20-SOM204 prototype:
Features are: 1GB RAM, 4/8/16/32/64GB eMMC Flash, Gigabit Ethernet interface, 2K EEPROM,
Optional features not assembled by default: SPI Flash with hardware WP, Second Megabit Ethernet.
With this SOM we tested A20 with two Ethernet interfaces: one Gigabit and one Megabit working together. The practice prove A20 can have two separate working Ethernets, but there is one issue both share same clock, so if the both Ethernet works together they can be only Megabit.
The second SOM204 module we work on is with A64.
The features are 2GB RAM, 4/8/16/32/64GB eMMC, Gigabit Ethernet interface, 2K EEPROM
Optional features not assembled by default: SPI Flash with hardware WP, Second Gigabit Ethernet (USB-Gigabit), SATA (USB-SATA), CAN.
The third SOM204 module we work on is with RK3399.
The features are 4GB RAM, 4/8/16/32/64GB eMMC, Gigabit Ethernet, PCIe, USB3, 2K EEPROM
Optional features not assembled by default: SPI Flash with hardware WP, Second Gigabit Ehternet (USB-Gigabit), SATA (USB-SATA), CAN.
A20-SOM204 and SOM204-EVB will be for sale in November. Prices will be comparable to existing A20-SOM A20-SOM-EVB.
A20-SOM204 is separate product and not meant to replacement A20-SOM neigher we have intentions to discontinue A20-SOM. Both products will be active and in production.
Software support for all SOM204 modules will include Android and Linux.
olimex 
Oct 03, 2017 @ 20:16:47
AweSOM! 🙂
Oct 03, 2017 @ 20:33:04
hahaha that is another secret project of ours, where did you learn for it?
Oct 03, 2017 @ 23:09:22
Can’t tell, I’m under NDA 😀
Oct 04, 2017 @ 05:18:00
Good initiative. But there are already several SoM standards like Q7, SMARC, EDM, CoreExpress… Did you have a look at those? If yes, why did you choose to roll your own?
Oct 04, 2017 @ 06:40:00
Nice move, although it is a pity you don’t have RK3288 in the pipeline.
Oct 04, 2017 @ 08:03:04
we have, mostly because RK3288 has mainline Linux support, but with lower priority than RK3399 which is newer and more powerful!
Oct 04, 2017 @ 21:22:55
I hope RK3288 is just a typo since RK3328 should be the more interesting choice (amazingly fast USB3, less expensive, less heat, dual Ethernet, ARMv8 AES crypto extensions). The time you’re ready with an RK3328 SoM software support will also be ready.
Oct 05, 2017 @ 08:05:16
RK3288 is not typo, although there are others typos in the post which I will correct 🙂 It’s always tempting to make board with the latest and greatest chip and RK3328 is better than RK3288 but RK3288 has better software support as being older, this is interesting for me, I’m tired of dealing with new chips with only PMU and GPIO support in mainline for year and using android kernels and broken binary blob drivers to build linux until proper mainline support cover all their features. For all our further boards we will be conservative and make boards only when we see good linux support.
When we started the laptop A64 was relatively new chip. We were ready with the hardware approx one year after we started, but A64 user experience was worse than A20 for almost one more year which prevent us to release the laptop! This is what happens when you use new chips with missing Linux support, you can make toy running Android but nothing which you can actually use with Linux.
Oct 04, 2017 @ 23:08:32
https://www.cnx-software.com/2017/10/04/olimex-introduces-universal-systems-on-module-with-204-pin-so-dimm-edge-connector/#comment-546621
Oct 05, 2017 @ 08:21:23
So obviously you have not checked software support situation with RK3328 *at all*, didn’t realize that Rockchip themselves partially backport stuff for their 4.4LTS ‘vendor kernel’ from their own mainline kernel submissions (since RK3328 just like RK3288 and 3399 are amongst their ‘open source’ SoCs), have not found Heiko Stübner’s and others work…
Anyway: I run 4.14 on my RK3328s without much issues due to https://github.com/ayufan-rock64/linux-mainline-kernel/commits/master though 4.4LTS is yet to be preferred.
And if your decisions which Rockchip SoC to choose today are based on experiences with Allwinner in the past you couldn’t be more wrong.
Oct 05, 2017 @ 10:06:03
> “new chips with only PMU and GPIO support in mainline”
Huh?
I think I know at least a little bit what I’m talking about but if you refer here to A64 as an example _missing_ PMU support is still more or less the only reason why A64 laptops (the one I worked on a little bit is Pinebook) are not already running with mainline kernel but with the outdated, smelly Allwinner 3.10.x BSP thingie instead (and yes, Linux works there and A64 even if we have to rely on an ugly Android kernel with tons of patches on top is good for more than just Android toys)
Again: you couldn’t be more wrong basing decisions for SoCs from vendor R (who actively supports Linux development, upstreams his own code to mainline u-boot/kernel, is supportive on solving issues, gets in touch with community and hardware vendors) on experiences in the past with SoCs from vendor A (which still more or less cares about nothing else than Android and all the real work has to be done by awesome linux-sunxi community which obviously takes some time)
RK3328 kernel status:
– RK Android 3.10 kernel: no idea since I don’t give a sh*t about Android
– RK Linux 4.4LTS kernel: here more or less everything works already with some improvements to come, eg. better VPU support — I’m not that much into this area but you should get the idea by checking LibreELEC for RK3328. BTW: 4.4LTS is one of those with extended support (6 years!)
– Mainline: already ok for headless use cases, situation will constantly and also soon improve since RK themselves actively contribute (and I don’t see much of a difference between their work on RK3399 and RK3328)
Unlike with Allwinner where you really don’t want to run your device with their smelly BSP kernel/u-boot offerings I would call situation with RK totally different since their 4.4LTS branch **is useable**.
If I look at your SoM standard with several high-speed interfaces on the connector it really makes no sense to me to choose RK3288 over RK3328. 🙂
Oct 04, 2017 @ 09:40:35
Do you have enough power lanes to accomodate power delivery for more powerful processors?
Oct 04, 2017 @ 10:33:10
we do
Oct 04, 2017 @ 19:27:16
Why not max ram on the A64?
Oct 04, 2017 @ 21:19:19
Cause there’s only one DRAM vendor selling sufficient 12Gb modules and they’re too expensive anyway.
Oct 05, 2017 @ 08:05:47
right on the spot, to add – and hard to find
Oct 05, 2017 @ 10:33:38
“With this SOM we tested A20 with two Ethernet interfaces: one Gigabit and one Megabit working together. The practice prove A20 can have two separate working Ethernets, but there is one issue both share same clock, so if the both Ethernet works together they can be only Megabit.”
This is not true. Nothing is shared, except the system bus clock, which is fast enough for gigabit anyway. Furthermore, you can route GMAC to the PA pingroup and EMAC to the PH pingroup. They are completely separate. The EMAC can only do up to 100Mbps, and probably doesn’t have DMA support (I haven’t checked).
Oct 05, 2017 @ 11:51:32
This is exactly how they are wired:
Click to access A20-SOM204_Rev_A.pdf
but so far we can’t make GMAC and EMAC working together with same clock.
Did you try A20 with both GMAC and EMAC working? Can you share some more configuration info?
Stefan posted this issue on Linux-Sunxi mailing list, but no one has replied so far:
https://groups.google.com/forum/#!topic/linux-sunxi/sDXfamLUodw
so I guess there is no one else who try to accomplish this.
Oct 05, 2017 @ 12:17:22
I believe you are the first vendor to attempt this. Prior to this no board has this kind of setup, so you’re unlikely to get an answer from the community.
Oct 05, 2017 @ 12:28:17
any speculation then what to try ? 🙂
Oct 07, 2017 @ 12:33:46
have you tried to use the external 125MHz clock from the gmac-phy
btw. I don’t like the D5,D7 of the DEV board
they cost about 6% of power (USB/OTG-power is limited)
and eg. for A20: isn’t there a ideal diode within the AXP209
(then you maybe need a diode in front of R92/SOM)
Oct 06, 2017 @ 02:55:47
This is very nice, well done Olimex! 🙂
I notice on https://www.olimex.com/Products/SOM204/ that you’re also providing LiPo management in the design, which is an excellent feature.
This could become a very successful product range. The long-lived standard interfaces, ability to upgrade, and a fixed physical form factor encourages people to invest in them.
Morgaine.
Oct 06, 2017 @ 13:10:31
One final comment on why choosing RK3288 over RK3328 is IMO a huge step into the wrong direction.
From a software perspective it looks like this *today*: http://opensource.rock-chips.com/wiki_Status_Matrix (and in reality as both developer and user running Linux on RK3328 I’ve to admit that there are still some open issues wrt USB3 and Ethernet but at least we already found workarounds for this and since RK folks themselves are pretty supportive I expect all issues being resolved soon in both RK’s 4.4LTS and mainline kernel).
I would really love to see an OSHW design from Olimex with storage performance that doesn’t suck any more since the best you currently offer is A20 based but Allwinner’s ‘native SATA’ simply sucks from a performance point of view. Please check the numbers: https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192
Pine64 = A64 + JMS578, Banana Pi Pro = A20, ROCK64 = RK3328 + JMS578. An RK3288 wouldn’t be on the list since even slower than A64 since AFAIK there still no UAS can be used (USB Attached SCSI — see http://linux-sunxi.org/USB/UAS ).
RK3288 is nice in devices that do *not* need much interfaces but high single thread performance, good graphics (performance) and these devices need either active cooling or a large surface area for proper passive heat dissipation (eg. a Chromebook). If you stopped all your work on H3 designs for thermal reasons I really wonder why you consider RK3288 at all. Looking at RK3328 clocked at 1296 MHz on the other hand: two of my 3 ROCK64 don’t wear a heatsink and even when compiling stuff no throttling happens. It needed an openssl benchmark to trigger some minimal throttling — see below.
RK3328’s internal Fast Ethernet PHY and GbE with external PHY work at the same time without any issues and another important detail for customers looking after encryption is that RK3328 unlike RK3288 supports ARMv8 AES crypto extensions. You get 14 times the performance with just a minimal higher consumption increase: https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829 (see next page of the thread for my consumption measurements)
Please compare the numbers for ROCK64 (RK3328) with those for ODROID-HC1 (the A17 cores in RK3288 will perform somewhat similar to the A15 cores in the Exynos5422 which means that you will not even get 10% of the RK3328 AES performance since throttling will further ruin the results since RK3288 needs an insane amount of power with corresponsing heat generated to run at upper clockspeeds, I would not even think about holding the 2.0 GHz for more than a few seconds).
If stuff like FDE (full disk encryption) or securing connections by encryption are an issue for your customers ignoring ARMv8 AES acceleration could become an issue.
Oct 07, 2017 @ 00:21:29
Why do you argue against RK3288 instead of simply pointing out, that RK3328 would also be of interest for the reasons you gave? I, for one, am looking forward to the RK3288 SOM but won’t speak up against an additional RK3328 design. There are people with different SOC preferences for various reasons.
Oct 07, 2017 @ 10:23:39
Tsvetan wrote “RK3328 is better than RK3288 but RK3288 has better software support as being older, this is interesting for me”, first part of the sentence is true, 2nd not since based on experiences with Allwinner and ignoring RK reality.
According to Olimex they consider thermal issues critical for them and their customers so good luck with both RK3288 and RK3399 anyway *on such a SoM*. All the various advantages RK3288 has over RK3328 (CSI, various LCD connection types, theoretical high multi-threaded performance for example) are either questionable (since interfaces not used on the SoM connector) or will simply not work as expected (since throttling). It’s still a SoM for embedded situations/applications and not TERES II (for such a laptop IMO the only reasonable choice would be a RK3288 today).
I spent the last 1.5 years waiting for some Olimex designs that were either stopped (for thermal reasons, no H3 boards) or delayed over and over again or maybe forever (for software reasons). What’s wrong with trying to prevent this happening again and bringing in some community experiences/knowledge covering both thermal and software situation?
Oct 07, 2017 @ 12:08:04
BTW: I’m really curious which use cases you try to address with RK3288 on such a *SoM* (and not a tablet or laptop where this SoC could and can shine)?
Since all the experiences we (as community, mostly Armbian community in this case) already made are just… alarming when thinking about putting such a beast on a rather small SoM. The heatsink you see here is an insufficient joke for example: https://forum.armbian.com/index.php?/topic/4614-asus-tinker-board/
Willy Tarreau chose something like this https://forum.mqmaker.com/t/miqi-based-build-farm-finally-up-and-running/605/24 to get his RK3288 build farm not throttling any more (and he’s fine with 90°C thermal treshold). Use cases that need high sustained performance — something RK3288 is capable of — definitely require appropriate cooling otherwise you will end up with 800MHz max RK3288 cpufreq for sure.
The only sufficient passive cooling solution for SoCs like RK3288 I’ve seen so far is something like this: https://forum.armbian.com/index.php?/topic/4983-odroid-hc1/ (4 x Cortex-A15 at 2GHz plus a bunch of A7, CPU performance is roughly comparable to RK3288). Metal enclosure acting as giant heatsink works. Since I’m no hardware guy I wonder whether such a concept could work with SoMs too? Since if not I really wonder which benefits a RK3288 could provide in this situation.
Oct 07, 2017 @ 11:06:47
A provision for heatsink (mechanical holes) may be …
Oct 09, 2017 @ 21:08:18
Is the PCB design of SOM204 will be available on github?
Oct 15, 2017 @ 16:01:41
SOM is *NOT* open source!
(NDA)
Oct 18, 2017 @ 23:17:36
hello,
it’s good to see you getting on an interoperable mood at least for SOC offering, but i’m wondering why you did not commit with previous established standard like SGET.org Qseven & SMARC …
wouldn’t such an open commitment give to your customers more trust in your value added solutions?
otherwise, did you see in those standards some shortsights that lead you on your own way?
Oct 19, 2017 @ 17:00:40
There are plenty of standards. Yet most of them are either weird or pointless or put unreasonable demands. Harsh truth is that standards weren’t created with modern embedded challenges in mind. Somehow, in the world of embedded, “standards” does not rings a bell. Embedded is a lot about custom in-situ solutions. Modules like these are good tool to get there really fast, if you’re not up for developing own systems of this scale.
These modules are “proprietary”, it means “vendor lock”. However, out of all vendors, Olimex is nearly best one to lock on if you need long-term solution. Then Olimex knows how to do embedded right. Unlike these weird standard creators. Added value? Hell, Olimex things are “added value” on their own. Someone have to come and create things better than “standard” crap like PCs, etc. Why don’t you just go buy ATX MB full of other loud wannabe-standard crap like UEFI and ACPI? Oh, wait, it gives so much headache in embedded and vendors do not really care how their proprietary stuff performs with Linux? But you’ll have added value of standards, lol. Feel free to use WEP and SSL with 40-bit keys, after all they are (or were) standards. Just because something is “standard” it does not imply it is something good. And whole H.264/H.265 saga has been a really decent showcase what standards have become these days. It gone as far as uniting MS, Google, Cisco, Nvidia, AMD, ARM, Intel and many others under umbrella of Open Media Alliance. So they at last could create some high-quality workable codec. Ironically, they’re not a standards body, nor this effort being promoted as creation of standard or something like that.
Oct 19, 2017 @ 19:07:47
hi, thanx in advance for taking the time for such a long rebuttal..
anyway you did not convince me completely that at least “a standard pinout” for SOM is not a good thing (TM) to aim for!
your examples about completely different contexts and issues with their own “mess” should mean that standard are ALWAYS failing? i don’t think so..
so please let’s keep this thread on track relatively to SOM and pinouts in the market..
Oct 20, 2017 @ 22:08:17
Good news. The Intel next to me goes to the cellar as soon as there’s a reasonably priced Arm with 4gb ram running linux.
Nov 28, 2017 @ 09:17:53
Hi , could we expect to see this on the store this year ?
Dec 21, 2017 @ 09:33:30
Since November is finished, is there an updated estimated date for availability?
Jan 03, 2018 @ 13:26:56
Hi,
Same question for us ! 🙂 and we need the 4Gb version.
It should be available before summer 2018 or after ?
JF
Jan 03, 2018 @ 15:18:56
Received this message now by email:
A20-SOM204 is in production
A64-SOM204 (4 core A53, 2GB RAM) and RK3328-SOM204 (4 core A53, 4GB RAM) are in development to be available in March-April 2018
RK3399-SOM204 (6 core, 4GB RAM) is planned for development in second half of 2018
Best regards
Tsvetan