Re: Official support Odroid hardware and other ARM development boards.
Thanks for the feedback Luke.
On 02/27/2014 04:53 AM, Luke Kenneth Casson Leighton wrote:
On Thu, Feb 27, 2014 at 1:26 AM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
Hi Luke,
On 02/26/2014 05:44 PM, Luke Kenneth Casson Leighton wrote:
On Wed, Feb 26, 2014 at 11:46 PM, Reg Lnx <regier.kunkel@gmail.com> wrote:
Thank you Karsten.
It answers a lot of questions and it makes sense. I think we can say the
very same about the odroid, it has some non free things too.
indeed it does. i've been working at every opportunity possible to
get a software-libre compliant *desirable* processor available for
general use. four years and counting. it's getting boring.
I jumped in late and haven't read the entire thread, but what
do you consider "desirable"?
desirable in the context of both end-user pricing and modern end-user
features. let's take the announcement of an FSF-Endorseable laptop
very recently as a good example. if you look closely at the specs,
you find it was something like a 5-year-old laptop. how can a 5 year
old laptop be desirable to the average person on the street?
:) I suppose that depends on the street...
So it looks like we still don't have a 100% open source computer.
Ahem.... You can run our boards with 100% open source, and I think
our quad-core GHz i.MX6
are they available for $USD 50 because you're selling them in volumes
of 100k+ units? rockchips 28nm GPL-violating quad-core RK3188 is $USD
12. compared to $36 for a *more power-hungry* 40nm quad-core iMX6.
Nope. As much as we might like it, we're not in the consumer space.
(btw, if you're interested, i can put you in touch with a company
that can get you China-based pricing for the iMX6. for various very
good reasons Freescale operate *different* pricing for S.E. Asia and
the EU/USA).
Thanks for the offer, but the bulk of our costs aren't really in
the CPU (we do U.S. based manufacturing, too).
which would you think would be more desirable? $99 products with
worse battery life, or $50 products with better battery life?
unfortunately, the iMX6 is considered "old" already. the pricing
doesn't help, either.
:) We'll be shipping this "old" processor for another 10 years.
Most of our world revolves around longevity and stability, not
bleeding edge.
There's one key piece that's normally closed-source (the GPU), but
there's an open-source alternative here:
https://github.com/laanwj/etna_viv
yes. i've been advocating the use of Vivante to the Fabless
Semiconductor companies i'm in contact with, exactly for the reason
that etnaviv exists.
Yeah. The folks involved have done some amazing work.
unfortunately the iMX6 still has proprietary VPU firmware. if that
were to be reverse-engineered then it would mean that the iMX6 would
be the *very* first FSF-Endorseable ARM SoC... that was still just
about classifiable as "desirable". but only just.
I'm not quite sure how this differs from Microcode on an X86-based
product.
There are also some open-source bits with licenses other than
GPL/LGPL provided by Freescale (notably, some of the VPU code),
but the restrictions are pretty reasonable: Don't use on non-Freescale
processors...
unfortunately the fact that it is *possible* to install proprietary
firmware means that it's non-FSF-Endorseable. to be
FSF-Endorseable... it's complicated, but in this case it would be
necessary to power down the VPU entirely at a system-board-level and
for it to *never* be possible to power the VPU back up. ever.
now, if it was a separate chip (or peripheral), where the firmware
was uploaded as a one-off to get the hardware up-and-running: that's
ok. if the firmware was hard-coded into a library (rather than being
a separate blob uploaded into the SoC's memory) then it would qualify
under the GPL's "System Library" exemptions. but the iMX6 VPU
firmware arrangement is neither of these things, so unfortunately it
doesn't qualify.
I'm not sure I understand the distinction. The VPU is really a
separate processor, though shipped as a part of the same package.
Again, ahem... We try very hard to give back when we can.
... because as a mid-level-volume company that's also a software
service and solutions provider you fully recognise the value that's
being provided by the software libre community.
which is great!
i was NOT referring to boundarydevices - or companies like boundarydevices.
Thanks. The value of the community stares me in the face every day...
i was referring to large mass-volume companies such as AMLogic,
Mediatek, and LG, and the likes, all of whom *knowingly* commit
endemic GPL violations on a massive scale. LG actually consider it a
FAILURE ON THEIR PART IF YOU EVEN NOTICE THAT THERE IS GPL SOURCE CODE
USED IN THEIR PRODUCTS. rather than work with the software libre
community, they paid a team of lawyers a considerable amount of money
on how to devise a sophisticated tivoisation and DRM scam.
does boundarydevices knowingly and deliberately commit GPL
violations?? of course they don't. because you are in a different
market where you provide solutions, not appliances.
Right. Our customers are the ones shipping appliances.
Our job is to enable them (and encourage them to leave
tux alone!).
Essentially everything we provide is open-source,
awesome! that's because you Get It.
Because it's obvious.
but, working from the ground up is the only way that this situation
is going to change. The Plan:
1) make some successful desirable mass-volume hardware that respects
software freedom
2) sell lots of it
3) put the money made back into funding software libre
4) put the rest back into solving a non-free issue whilst not
compromising the profitability needed for the next iteration round the
loop
5) repeat from 1.
I don't know what you consider "lots", and we don't put **all** of
our money back into free software, but we do spend time and money
on various open-source projects, so I'll take some exception to the
brush you've used to paint us "greedy manufacturers"...
you work with the software libre community. your business model is
completely different.
We'd love to have an "easy button" for folks wanting to use our
boards with Debian.
and, as the iMX6 is one of the few ARM SoCs with long-term
committment from its manufacturer, Freescale, unlike many of the
china-based SoCs with their nova-burst lifecycles this would actually
make some sort of sense.
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.
SABRE Lite lives in this weird place because we did it jointly
with Freescale so we've needed "approval" to change.
the primary focus eric should be on Debian Installer. the mistake
that linaro keep making is to deliver "images, images, images". no
end-user installing a system wants the crap choices made by some
random tit of an engineer. vastly-extended download times,
reconfiguring an ext4 filesystem live, having to buy *exactly* the
right sd/mmc card size (or waste huge sections of it), forcibly having
to deinstall unwanted packages?? these are *not* fun things that
people want to waste their time on.
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.
by contrast Debian Installer can be a few mbytes worth of download,
is small enough to fit into memory over a PXE boot, leaving the main
boot media free and available for a fresh install.
The downside of the installer is that SD speeds are **so slow**.
eMMC is much better, and SATA is very usable.
PXE boot is really just a matter of configuring the boot loader
appropriately. There's a lot of work on the U-Boot ML on this
topic right now.
eric: the iMX6 is one of the few SoCs with EFI boot from SATA, isn't it?
I don't know about EFI, but we absolutely boot to SATA through U-Boot,
and this or eMMC are very much suggested for running either Debian
or Ubuntu distributions.
The faster CPUs and memory subsystems of this generation of processor
have finally made using traditional distributions possible, but
I/O bandwidth can still be an issue.
We hope to get DDR200 speeds on UHS SD cards in the future, but we're
not there yet.
Regards,
Eric
Reply to: