Merging Allwinner support [LWN.net]

Merging Allwinner support

Posted Jun 20, 2013 22:53 UTC (Thu) by boog (subscriber, #30882)
In reply to: Merging Allwinner support by pboddie
Parent article: Merging Allwinner support

I agree that a good deal of context is missing. Leighton is pursuing an ambitious personal attempt to kickstart standardised arm-style hardware that runs properly free software. That's certainly a laudible aim. It's based around a pluggable "system" (for want of a better word). From my (quite inexpert) point of view it seems a very interesting idea with a real chance of success:
http://rhombus-tech.net/
(I'm looking forward to getting my hands on such a system.)

So people unaware of the project might easily be annoyed by Leighton, but they would be missing the point that he is investing a great deal of effort towards a valuable goal; the approach he is taking is original and clearly results from a lot of personal reflection and some real experience. He's certainly not just in it for the trolling of kernel developers.

It does seem plausible that some of the progess being made with Allwinner simply reflects the fact that he is pushing against an opening door. Note that the project is not tied to Allwinner.

to post comments

Merging Allwinner support

Posted Jun 21, 2013 2:48 UTC (Fri) by roc (subscriber, #30627) [Link] (6 responses)

Luke has had interactions with other projects --- Samba, Webkit, Mozilla at least that I know of. Look them up.

Merging Allwinner support

Posted Jun 21, 2013 8:09 UTC (Fri) by boog (subscriber, #30882) [Link] (5 responses)

I think there are two separate issues here. Most people seem interested in criticising Leighton's interactional behaviour. Instead, I wanted to make the point that I see value, originality, progress and a (perhaps surprising) chance of success in his current project, which is certainly very worthwhile from a free software point of view. Nothing regrading the underlying project motivitaing Leighton appeared in the article, giving the impression that he was simply criticising kernel developers for fun, which I consider a real misrepresentation of the situation (it may accurately reflect the impression gained by kernel developers).

For those (like roc) particularly interested in discussing the social aspects rather than the underlying project, I guess I can imagine that a younger Leighton would have proved disruptive in larger projects. However, despite the apparently impulsive approach, the current project clearly results from some strategic thinking and long-term effort. I've been following/lurking the eoma project for a while and I've seen no behaviour that isn't motivated by good intentions and - to me - a defensible analysis of the current situation. In the latest kerfuffle, he was/is trying to draw the attention of developers to what he perceives to be a fundamental problem in arm hardware. That there is currently a problem is hardly in doubt. The final outcome and solution (if any) is not so easy to predict, but I think it would be hasty to say that Leighton is obviously wrong.

Merging Allwinner support

Posted Jun 21, 2013 11:53 UTC (Fri) by pboddie (guest, #50784) [Link]

I think people are too eager to criticise others when many are (or have been) in the same boat. Furthermore, the climate of discussion around many projects does lead people to be confrontational instead of conciliatory, so many people perceive that the best approach is to just demand or assert things rather than to gently tease out advice and opinions and to gradually persuade and encourage people to agree on the right course of action. In this particular case, the perceived urgency of the situation didn't encourage the apparently necessary tiptoeing around, and the usual "when it's done" responses are probably hard to stomach when an opportunity seems about to be lost.

With regard to reputations, I've dealt with people that no-one else wants to deal with, and although such people can exhibit annoying patterns of behaviour, one does come away with the impression that such people are genuinely trying to improve things and are not just playing some "trolling" game for the fun of it. Sadly, a lot of established contributors to projects seem to have the impression that every newcomer or outsider is by default only there to see some of the glamour rub off on them, and thus they treat newcomers with suspicion rather than take advantage of the opportunity of someone showing up with enthusiasm for that project. Such enthusiasm can drain away pretty quickly, after all.

I'm sure that a lot of people don't regard such matters as a problem, but I've also seen sentiments expressed in favour of blocking or censoring "difficult" people in a community, so I don't think anyone should be complacent about this kind of thing at all.

Merging Allwinner support

Posted Jun 23, 2013 20:01 UTC (Sun) by mato (guest, #964) [Link] (3 responses)

I second this. I've also been lurking on debian-arm and know of Leighton only from his efforts on the EOMA/Rhombus project where he has indeed been putting a lot of long-term efforts towards a worthwhile goal.

Further, having done some significant business in Korea, I'm inclined to think that the "suggestion" Leighton is being ridiculed for in the article, namely

that he apologize on behalf of the Linux kernel community for "not consulting with you (allwinner) on the decision to only accept device tree" elicited both amazement and anger—for obvious reasons

in fact shows that he is in a position "on the ground" at Allwinner and knows how the local culture works. In Korea (and China, Taiwan, Japan, ...) there is an extremely strong culture of conflict avoidance and fear of "losing face". Leighton's suggestion would be exactly the kind of statement I would make to Allwinner senior management were I in a position to be negotiating a situation like this.

Merging Allwinner support

Posted Jun 24, 2013 18:26 UTC (Mon) by boog (subscriber, #30882) [Link] (2 responses)

Indeed. Although not apparent in the summary email quoted in the article, it was clear on arm-netbook that the "apology" bit simply emerged as a presentational gambit, suggested moreover by Leighton's associates, not by him. Seems it is the done thing when asking favours from influential people or companies.

The whole thing was completely overblown. Leighton was in a position to influence people meeting Allwinner top brass and simply wished to make the most of the meeting for the benefit of free software, albeit at very short notice. The time pressure short circuited the background explanations that it turns out are essential when dealing with kernel developers.

Merging Allwinner support

Posted Jun 25, 2013 16:24 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

The amusing thing about this, of course, is that one must apparently also "apologise" on behalf of successful SoC vendors for not consulting with kernel developers. Everybody likes to think they are free of cultural baggage, I'm sure.

Merging Allwinner support

Posted Jun 25, 2013 17:05 UTC (Tue) by nevets (subscriber, #11875) [Link]

Apologize for what?

The kernel is GPL, you can do whatever you like with it as long as you continue to provide the changes under the GPL guidelines. I don't see the kernel developers saying "you must apologize to us for not working with us". I saw several comments to let them keep their work out of tree. Their work is also under the GPL, and can be pulled in properly by anyone that wants to follow the Linux Kernel rules.

The whole "apologize" comment had no place in that conversation. If Luke needs to follow social customs and "apologize" on behalf of the kernel developers to gain favor from the managers at Allwinner, he could do that off the public lists.

In other words, if you are dealing as a liaison for two different cultures, you need to act the part of the culture you are dealing with. For Asian companies, that usually means being very humble and playing the political correctness game.

For dealing with the Linux community, just give out the facts. Saying that a decision has to be made in 4 days, but never say what will happen when the time runs out, as well as pushing, we need to accept the other implementation that DT already has without any technical reason but "it works for a successful company", shows that Luke didn't properly handle the situation at all.

There's no need to have to give an "apology" to the kernel community. Just state what has happened and see what you get. The answer was pretty quick: Device Tree, or show us why their system is better for *everyone*. Also, other workarounds were given too, doing a script for the conversion of fex to DT. But it did seems that Luke wasn't happy with these answers, and only wanted the kernel developers to change their mind. Which he gave no real reason to do so.

Perhaps he's doing a great job at pushing Open Source in otherwise closed companies. But he should also know how to deal with the Open Source developers in a more productive and diplomatic way.

Merging Allwinner support

Posted Jun 27, 2013 17:54 UTC (Thu) by farnz (subscriber, #17727) [Link] (6 responses)

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.

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...