Re: Official support Odroid hardware and other ARM development boards.
Hi Luke,
On 02/27/2014 03:02 PM, Luke Kenneth Casson Leighton wrote:
On Thu, Feb 27, 2014 at 6:18 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
Thanks for the feedback Luke.
no problem sah. btw, the sabre lite pcb cad/cam files i received
from one of your associates were really useful. i was able to create
- with a lot of effort(!) an EOMA68-iMX6 design. sadly nobody's come
forward with the funds to see it through to production, but hey...
:)
At least you're not hitting us up left and right for support,
like some of the other folks who've done this...
I'm not sure I understand the distinction. The VPU is really a
separate processor, though shipped as a part of the same package.
right. if it *was* a separate processor - a separate chip or a
separate peripheral - then that wouldn't be a problem. apart from
anything, it would be possible to simply... not put that separate
processor onto the PCB, and you'd have a fully-endorseable product.
but, if you did that, especially with video processing, the power
needed to sustain the bandwidth required to communicate inter-chip
would be so high that it would no longer be possible to call it a "low
power SoC". or even an SoC at all!
SoCs - systems-on-a-chip are a unique and serious problem for FSF
Endorseability because the endorsement rules are *very* specific.
when faced with the "total integration" of SoCs, even a single piece
of proprietary firmware can jeapordise an entire SoC from being
chosen.
so, sadly, the market is divided into two types of SoCs:
1) those that are "desirable" (as in, mass-market, mass-volume, low
price, good features).
2) those that aren't (because typically they don't have a VPU, or a
GPU, or they're old and so there's been time to do the required
reverse-engineering).
those that are in category 1 in the ARM (and MIPS) SoC world... *all*
of them require some form of proprietary firmware blob. i really mean
*all* of them. and i've been looking now for over six years. not
one!
those that are in category 2 are such a small and specialist market
that it is cost-prohibitive to even consider supplying the (small)
FSF-Endorseable market with product based around them.
[this is why i designed the EOMA68 platform, btw, so that the majority
of the cost of product development could be focussed in the "base" -
the chassis, then later we could look at doing an FSF-Endorseable CPU
Card with less features]
Interesting. We'll have to take a look at that.
especially if you're planning to sell the sabre-lite for a few more
years yet. btw, it's got 2gb RAM, hasn't it?
Nitrogen6X has 2GiB (as an option at the moment). Upcoming product
will have 4GiB.
oo that's very unusual. you'd have a niche there within the debian
(and other distro) worlds especially for the compile farms, where the
more RAM the better, because of the issues associated with the linker
phase in debug compiles taking up vaaaaast amounts of RAM. the effect
is just... staggering. a link phase that would normally be an hour
can often be *TWO DAYS* because the cross-referencing is so vast that
if the entire binary isn't fully RAM-resident, ld basically
permanently thrashes the OS.
It's amazing how bloated compiling has become, especially for
projects like Qt that use a lot of C++...
SABRE Lite lives in this weird place because we did it jointly
with Freescale so we've needed "approval" to change.
oh dear :)
Right. Laci (on CC) is working right now to get Debian packaging of
our 3.10.17 kernel, though he's targeting Ubuntu first because Unity
plays nicely with a touch screen.
ubuntu also uses debian installer. i understand that they still cut
much of this stuff over from debian, where they haven't continued the
silliness of an entire fork of the debian distro.... *sigh* :)
Ever try telling programmers what to do? (of course you have, so
you know that from many vantage points, freedom looks like chaos).
Cheers,
Eric
Reply to: