Re: Official support Odroid hardware and other ARM development boards.
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...
> 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]
>> 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.
> 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* :)
Reply to: