On Sun, Oct 20, 2013 at 11:40 AM, Peter Robinson pbrobinson@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.