On Thu, Feb 27, 2014 at 6:18 PM, Eric Nelson <[email protected]> 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* :) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/capweedy+cadr-2z-rzripui-cevbpfpmwjao257v2-joshc...@mail.gmail.com
