Live Interview: Luke Leighton of Rhombus Tech
Today we're doing a live interview from 18:30 GMT until 20:30 GMT with
long time contributor Luke Leighton of Rhombus Tech. An advocate of
Free Software, he's been round the loop that many are now also exploring:
looking for mass-volume Factories in China and ARM processor manufacturers
that are truly friendly toward Free Software (clue: there aren't any). He's currently working on the first
card for the EOMA-68
modular computer card specification based around the Allwinner A10,
helping the KDE Plasma Active Team with their upcoming
Vivaldi
Tablet, and even working to
build devices around a new embedded processor with the goal of gaining
the FSF's Hardware Endorsement. Ask him anything. (It's no secret that
he's a Slashdot reader, so expect answers from lkcl.)
yaay always wanted to do that :)
You hear a lot of horror stories about unscrupulous factories stealing the basic IP from smaller customers. Is this something you're concerned about, and how would you deal with it if it did happen?
well, to be honest, i mean, what exactly are they going to "steal" here? think about it: linux is more expensive than windows because the number of CDs that it goes onto is greater. and if they "steal" the source code, and try to "hoard" it? congratulations to them: they just cut themselves off from community resources! so i'm really not that concerned about the software, although it's both hilarious and often frustrating to watch them try.
with the EOMA projects, however, it's a different matter: not because it's "stealing" per se but because of the risk of non-interoperability. i've posted about this before, about my uncle (anthony pickford) who used patent law to protect against dangerous copy-cat medicines [which were killing people - literally]. so we've followed his example, and have submitted 3 patents. patents tend not to go down too well in amongst the free software community - myself included - so i made them as extreme as i possibly could, on the grounds that i hope like hell that any companies which we ever need to go after will actually complain enough to get the patent system itself limited or shut down.
I don't think I needed anybody to tell me that one.
you might not - but there are a few people who don't know, and who want to find out for themselves. it's good that they do that, because when it all goes to shit, they're the ones who it's easiest to work with. it's not just academic for them: they now KNOW what the problem is (because they lost money or time over it)
Why should they care about Free Software? All they want to do is Charge Money, and the wishes of a bunch of free software advocates doesn't mean anything to them.
well, take a look at the allwinnertech.com web site. the community surrounding the allwinner a10 processor has grown sufficiently large that a number of community-driven entrepreneurial boards such as the cubieboard, hackberry and so on are actually listed as "Dev Boards" on allwinner's official web site.
if you recall HTC had a keyboard-based phone? techies and geeks loved it. when HTC's next phone wasn't a keyboard-based one, it absolutely tanked.
bottom line: don't underestimate the level of influence that free software people can have.
The good news is, they'll steal the free designs as readily as they steal the other ones.
Are we under the illusion there is a high-volume plant where management is thinking "gee, if we could only get some work from Free Software people, we'd be set".
it's much more fundamental than that. these are factories that in some cases quite literally make shoes, or jumpers, or... socks and handbags on the same floor or building. the owner went one day "i know i'll diversify: let me just go buy some PCB manufacturing equipment". the level of software expertise they have is LITERALLY zero. they buy ready-made designs, ready-made [GPL-violating] software images, and so on.
I like free stuff, but the religion which is Free Software seem to lose sight of the fact that the rest of the world isn't as interested as they are.
well, you need to read the articles online about how the Linux Steam/Valve Team got together with the Intel 3D Graphics Team. one of them described it as "the most productive work meeting they'd ever had".
there really *is* a business case for using free software. tie that in with the fact that many engineers buy stacks of tablets hoping to be able to buy 1,000 of them and use them as the basis for their custom products, but then they find that no, the source code isn't available, and bear in mind that geeks are some of the most influential people on forums which the average users frequent, and you start to realise that it's a bit bigger than you think.
I made a "Ask Slashdot" about the topic a month or so ago hoping to raise some discussion about it, but apparently Slashdot editors didn't like the idea, possibly because I lambasted the Allwinner A10 quite clearly. To keep this comment short I'll just drop a few select quotes from the wiki pages:
Integrate G2D support for 2D acceleration, right now Mali drivers sometimes are slower than FBDEV in 2D tasks ( http://linux-sunxi.org/Mali400 )
,
* No output modules support apart from cedarfb which uses raw framebuffer access (not compatible with xf86-video-mali and any other driver/device that wants to write raw at the same moment). * No support for GUI of the VLC, only command line VLC is supported * 1080p and such movies with high bitrate sometimes buffer too slow and frames are dropping. * No support for OSD because of lack of YUV420 ( http://linux-sunxi.org/VLC )
, http://linux-sunxi.org/XBMC#Optimize_XBMC_for_the_Allwinner_A10_SoC_used_in_most_media_players_and_tablets ,
Disadvantages Allwinner's CedarX technology and libraries:
Allwinner's own CedarX proprietary libraries have no clear usage license, so even if the source code for some versions is available the terms-of-use is unknown in open source software.
The Android glue code is implemented as a "media player" (parallel to Android's Stagefright multimedia framework) instead of as standard OpenMAX (OMX) components and API's.
This "media player" has limitations when it comes to playing back content pointed to by Android URIs and some web-based content.
There is no glue code for any other multimedia frameworks on GNU/Linux systems. The use of OpenMAX (OMX) instead would have rendered this a non-issue, with existing projects like GstOpenMAX (GStreamer OpenMAX). ( http://linux-sunxi.org/CedarX )
All these things quite well show the lack of commitment and complete blindness towards all the possibilities these kinds of SoCs could enable if only the software and the licenses were up to snuff. This brings me to the question: why choose the A10 when there are SoCs that atleast support the standard way of accelerating video through OpenMAX and/or GStreamer? Who does everyone seem to use Mali-400 when it's apparently very poorly supported? Is there any manufacturer who is even PLANNING to some day do a SoC with properly maintained and supported software package -- or better yet, release the programming documents to the wild so people can implement F/OSS software packages?
Sadly it seems like SOC development outpaces your ability to actually put it into a platform. Is this still going to continue for the foreseeable future?
good question! this first one was always going to be the hardest. it's taken.... almost a year to eventually find all the parts and suppliers. Mid-Mount HDMI was a bitch to track down. we'll still need to do the PCMCIA casework, and so on, which will need $6k for the endplate to be modified.
once that first one is done, however, we'll not only have pre-established relationships with all the suppliers, but we'll likely already have spare stock of some of the parts, *and* have the schematics to be able to cut/paste to create the next one, and so on and so forth.
so i fully expect subsequent cards to be vaaastly quicker development time. but, even there, it depends on the level of cooperation of the SoC vendor. if they don't provide EVB schematics, we can expect the PCB development to take longer. etc. etc.
remember - this is a project which will be going for at least the next decade. we're just getting started.
So first we get an report on the near completion of the EOMA board. Three months later, before it has time to prove itself (how many have been sold?), lkcl (probably Luke Leighton) gets into the limelight again with a seemingly not so well thought out proposal to build his own microcontroller . Standard quote of lkcl (paraphrased): "I don't know nothing, so I can't discuss how to overcome that well known restriction.". And now, a week later, an - bascially unannounced and unprepared - interview with this self-declared revolutionary.
All to give more spotlight to Rhombus Tech,
This is not News for nerds. This is product placement.
What can you tell us about the new SOC?
well, people have worked out that it's using ICubeCorp's design.
I've heard that instead of a separate GPU that it contains more 3d type instructions as part of the native architecture.
yes. if you're familiar with MIPS64 and/or ARC (from synopsys) and/or Tensilica's DSPs, it's more like an extended instruction set that gets "farmed off" in some cases to entirely different engines, with their own pipelines. in this case, it's a suite of engines with their own hardware threads.
How long before we actually see these being produced?
from funding to actual silicon? as we're basically doing nothing more than "take some hard macros, add them, and put it through the verification tools" i.e. there is NO development (because the core has already been done, and proven), we've set a target of 8 months.
actually what we're probably going to do is simply add USB-3 host to the existing 65nm design, bump it up to 8 cores (from 2), and then have a *separate* team design a "USB3 Peripheral IC" with SATA-III, Gigabit Ethernet and so on. even if the two wafers end up on the same chip. what's great about that is that that USB3 peripheral IC is itself a great stand-alone product, so we're talking to a couple of teams (including some open hardware designers) about how to get this done.
And which compilers are they targeting for this new instruction set?
they have a compiler expert from SGI on-board, so they've ported Open64. and it has LLVM support as well. amazingly. open64 is an entirely different compiler, but a long time ago when it was started, they took the gcc front-end GPLv2 source code and used that - just wrote a different back-end. so, for the most part, the options are pretty much identical so you can do "EXPORT CC=..." and go from there.
(something to do with the architecture, Open64 is a better choice for them than beginning from gcc's back-end).