[fedora-arm] Fwd: decent reasonably-priced armhf system with sata, gigabit ethernet, dual-core processor and 2gb of RAM

[luke.leighton]

On Sun, Oct 20, 2013 at 11:40 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> >  Does it do hardware virtualization,
>>>
>>>  http://www.arm.com/products/processors/cortex-a/cortex-a7.php
>>>
>>>  apparently yes.  which is pretty amazing.
>>
>> OK.  A bit of background about why I (keep) asking about this:
>>
>> We're looking for a development platform on which people can do KVM,
>> libvirt, virt-*, libguestfs, etc.
>>
>> The criteria are basically:
>>
>>  - cheap
>>
>>  - available to purchase now in many countries
>>
>>  - ordinary human beings can install Fedora & make KVM work
>
> On the above 3 believe me I've been looking long and hard for a A15/A7
> device that meets those specs that we can actively support in Fedora.
> I'm yet to find one!
>
>> The Samsung Chromebook is kinda the default now.  It's not especially
>> cheap, although not too expensive.  However the main problem is that
>> HYP mode is crippled out of the box, and enabling it can't be done by
>> regular humans.
>
> Agreed here.
>
>> I'm currently testing the ODROID-XU.  Not with any success, it has to
>> be said -- too much peculiar hardware, like uncommon HDMI connectors,
>> homebrew eMMC, and incompatible UART -- I need to visit an electrical
>> shop before I can find out why it's refusing to boot.
>
> I've looked at the ODROID* devices on numerous occasions with the view
> of supporting them in Fedora but their upstreaming of their kernel
> patches is basically non existent or close to truly dreadful which
> makes it impossible for us to support well OOTB.

 i've said it dozens of times, based on experience way back in 2005
from working with *nine* separate HTC-designed smartphones (each of
which was running wince), but it's worth reiterating.

 the situation that all arm-based gnu/linux distros face is the stark
reality of ARM systems having absolutely no concept of a BIOS of any
kind in any way.  having repeated this enough times in enough forums i
think it's finally beginning to be recognised.

 there isn't going to be a "solution": the sooner that's accepted the
easier things will become for people.  they can e.g. pick a particular
SoC or a particular piece of harware and get that up-to-scratch for
example, rather than going "wtf??".

 in the x86 world, the problem goes away by virtue of the x86 world
being effectively a total design monopoly: external peripherals,
monolithic BIOS and so on.  the hilarious irony is that as intel tries
to cross over into the ARM world (e.g. the Quark X1000) they apply
those "external peripherals" design rules with what will turn out to
be disastrous results.

 i never thought i'd say that a monopoly is actually a good thing, but
it is.  the alternative is that in any two near-identical bits of
ARM-based hardware even when they use the exact same CPUs and even the
exact same ICs the chances of them being able to use the exact same
kernel is absolutely zero.  all it takes is for the designers to have
used a different GPIO pin for a different purpose than the other
design and that's it, you're f*****d.

now multiply that across 650 ARM licensees each making in total
thousands of different SoCs, now multiply that across tens of
thousands of peripheral ICs many of which do not have
publicly-accessible datasheets, and then multiply that across the
number of products.

... is it any wonder then, that when reverse-engineering 9 HTC
smartphones we ended up with *TWO HUNDRED AND FIFTY*
platform-dependent files?  the only reason there were *only* as few as
250 files was because the designs all used the same Intel PXA 270
processor and they all used the same external peripheral-extender IC
(we called it "ASIC3").

basically what i'm trying to get across is that if you, fedora-arm,
continue to wait until this situation "stabilises", you are going to
be waiting for a very very long time.

now, i'm dealing with this from a different angle: standardising the
hardware via something called EOMA68.  we throw a stake in the ground:
there are *zero* optional interfaces; you get SATA, Ethernet, USB2,
I2C, RGB/TTL and 8 pins of GPIO on a credit-card-sized module
(re-using PCMCIA if anyone's interested).  on the other side of the
interface (I/O boards) you're forced to extend the I/O using e.g.
embedded controllers and so on.

in effect EOMA68 is the embedded equivalent of the "x86 PC" concept
which revolved originally around the ISA bus and more recently the
PCIe bus [with USB hubs, video cards and other peripherals hanging off
of that].  and as such the general idea is that it becomes a stable
base around which linux kernels across a wide range of SoCs *not just*
ARM ones can focus and plan for.

it's a tough choice, but basically the choice is either hardware
standards (and extra hardware cost) or absolute chaos.

l.