Merging Allwinner support [LWN.net]

Merging Allwinner support

Posted Jun 27, 2013 17:54 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Merging Allwinner support by boog
Parent article: Merging Allwinner support

The issue with Luke's idea here is that he's ignored existing, popular industry standards. Had the Rhombus Tech system been based around the Qseven specification (which existed before EOMA-68) or the SMARC specification (which came after EOMA-68 but has more traction than EOMA-68 does), there would be products already. Indeed, producing a "profile" of Qseven (basically saying you must implement Qseven with all of these interfaces to qualify) would have resulted in being able to produce product back in 2008, and you would now be able to upgrade from that to an iMX6 or AMD G-series module.

Note that back in 2008, Qseven already covered SATA, gigE, USB 2.0, PCIe, DisplayPort, HDMI and audio interfaces. CAN and SPI got added in 2010, in a backwards compatible fashion.

to post comments

Merging Allwinner support

Posted Jun 29, 2013 21:05 UTC (Sat) by boog (subscriber, #30882) [Link] (5 responses)

You may disagree with the reasons for not following the QSeven route, but that standard was considered (see "Alternative Standards" section near the bottom):

http://elinux.org/Embedded_Open_Modular_Architecture

Specific reasons appear to include: user-swappable, defined overall dimensions, all interfaces non-optional (the existence of incompatible boards seems to have been considered a problem).

Merging Allwinner support

Posted Jul 4, 2013 15:19 UTC (Thu) by farnz (subscriber, #17727) [Link]

That's why I suggested a derivative of Qseven, rather than a straight endorsement of Qseven as-is; by making EOMA "Qseven, but with these compatible changes", it would be easier to break the chicken-and-egg cycle of any board design.

Right now, to use EOMA, I need to convince a processing board maker to build me an EOMA board, and an interface board maker to build me an EOMA carrier. If EOMA was a Qseven derivative, I would face the easier option of convincing a Qseven board maker to produce me an EOMA-compliant derivative of product they already sell, even if that meant new connectors and packaging. As it is, I might design Qseven-based product in the future; there seems to be very little chance of my employer even considering EOMA.

Merging Allwinner support

Posted Sep 16, 2014 15:29 UTC (Tue) by lkcl (guest, #60496) [Link] (3 responses)

it's a lot more than just those reasons.

let's look at what the goals of the rhombus tech project are, and then you begin to appreciate where the EOMA68 standard is coming from. the mission is:

" to create modular environmentally-conscious mass-volume products that are long-term upgradeable by the end user "

now let's see if Q-Seven fits that goal.

Q) Can a Q-Seven module be installed by the average end-user without any harm or damage?
A) No it cannot.

- Firstly it has "optional interfaces" making it impossible for the average end-user to work out what they should be doing.
- Secondly it has bare contacts which mean that the average 8-year-old or the average 80-year-old is never going to understand or care about anti-static precautions.

Q) Can a Q-Seven module fit safely (or at all) into a wallet?
A) No it cannot.

Modules conforming to the Q-Seven Standard are designed to be factory-installed by qualified engineers.

Q) Can a Q-Seven module be installed, removed and reinstalled 20,000 times?
A) No it cannot.

by contrast PCMCIA (which EOMA68 re-uses) has an extremely large insertion and removal cycle run. MXM connectors typically have an insertion lifetime of 25 cycles (or whatever it is, it's extremely low).

does this start to give you some idea of what the differences are, and why Q-Seven is neither a competitor to EOMA68 nor can it even be under consideration as the basis for a mass-volume modular appliance standard?

> all interfaces non-optional (the existence of incompatible boards seems to have
> been considered a problem).

mmm... kinda :) ok, let's imagine that you are an average person. you've bought a tablet
and you've bought {INSERT VENDOR CPU CARD HERE}. it has "optional SATA" which you don't
care about, because you have a tablet.

now you go out and buy a laptop. it has a SATA HDD. but the CPU Card that you bought
doesn't WORK with SATA because SATA is quotes optional quotes on the Standard and the
CPU Card you bought doesn't HAVE a SATA interface.

now you think "okay, so i could make that USB, right? the base units could have, optionally,
a USB-to-SATA converter, right?"

but now you've made matters even worse: you now have *two* possible routes by which SATA
could be provided: one is via USB-to-SATA (optional) and the other is (optional) SATA on the
CPU Card... how on earth do you route those through to a single SATA HDD??

so it is infinitely simpler just to say "these are the interfaces that MUST be provided, and
that's the end of the discussion". and the benefits are that, as a "Sales Pitch", the average
salesman can say "Just Buy Anything In This Range: It Will Work".

now, here's where we have to get honest :) by "non-optional" we actually mean that each
"non-optional" interface can have *HARDWARE*-level speed negotiation, *including*
negotiating the use of extra pins... *IF* available.

so, for example, there is Micro-SD now on the latest version of EOMA68. Micro-SD can have
1, 2 or 4 pins, and there is also speed negotiation that can take place (at the hardware as
well as at the OS level).

so let's imagine that a CPU Card has support for only 2 I/O pins. you plug that CPU Card into
a device that has 4 I/O pins: *AUTOMATICALLY* you get only 2 of those pins connected... but
that's okay because the SD/MMC Standard allows I/O to be either 1, 2 or 4 pins.

likewise for Gigabit Ethernet, you can either use 4 wires (10/100) or, if the other 4 are
connected (either at the CPU Card or on the Base Unit), you can get Gigabit Ethernet.

likewise for USB3, USB3 *already* has hardware backwards-compatibility down to USB2
because if either the CPU Card or the Base Unit do not have the USB3 wires they will at
the very least have the USB2 wires.

so we say "non-optional" but there is a lot of wiggle-room to cover SoCs all the way
from a $2 ultra-low-cost QFP chip, right the way up to a $40 quad or octal core monster.

so the HONEST salesman will, out of the corner of his mouth and in a sotto voice,
tell you that you "get what you pay for", in other words "yeah it'll work, but you're
better off sunny-jim paying for the faster CPU Card because it has faster hardware
and you'll be able to do more".

and the nice thing is that the honest salesman will, in a year or two's time, get more
repeat business because in a year or two's time that "average person" will come back
and ask him for a faster CPU Card.

and that average person will be happy because instead of having to throw away the
entire product as land-fill they will only need to spend a fraction of the cost of a
"monolithic" unit buying the latest-and-greatest fastest CPU Card...

Merging Allwinner support

Posted Sep 16, 2014 15:41 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (2 responses)

Footnote: gigabit Ethernet's actually a bad example, because I have encountered (and dealt with the software implications of) combinations of gigabit PHY and gigabit switch that would misnegotiate if the connection between them only provided the two pairs needed for 100Mbit. Specifically, they'd successfully autonegotiate a gigabit connection, then fail to actually send useful network packets because you can't do gigabit without all four pairs.

Merging Allwinner support

Posted Sep 17, 2014 7:32 UTC (Wed) by lkcl (guest, #60496) [Link] (1 responses)

interesting... that sounds bad, and i am curious as to how that actually occurs, and to know what the circumstances are where GbE would be negotiated when the PHY (on a CPU Card) is only 10/100 capable and cannot (and will not) *ever* advertise that it has GbE capabilitiy. it sounds like either a firmware fault with the switch or a hardware (design) fault of some kind.

Merging Allwinner support

Posted Sep 22, 2014 16:43 UTC (Mon) by james (guest, #1325) [Link]

This sounds to me like an issue with the cable, not the NIC or switch.

In particular, there exist Cat 5 splitters which enable you to run two 10/100 connections over a single Cat 5 cable run (one example from a quick Google search). They're purely electrical, and you need two, one at each end. Each has two sockets: one is a pass-through for the two pairs a normal 10/100 Ethernet connection uses, and the other uses the other two pairs of a Cat 5 connection.

These are less than elegant, but in certain circumstances (no budget or time to do it properly, and particularly historically) they're not such a bad solution provided everyone involved is aware of their limitations.

I haven't come across anyone doing this actually in the cabling itself for networking, although I'm very sure people have tried it. I've seen people doing a similar one-pair-of-Cat-5-per-socket for digital telephony with Cat 5 wiring, and that's bad enough...