Fwd: decent reasonably-priced armhf system with sata, gigabit ethernet, dual-core processor and 2gb of RAM
i posted this to the debian-arm list but it occurred to me that you guys might appreciate having a decent desktop-style system as well as something with enough RAM to do compiles of some of the larger packages without needing to run into swap space, as well.
joe (posting on arm-netbooks) has managed to get a sub-17-second boot to desktop out of the A20 when it's matched with 1gbyte 800mhz DDR3 RAM and a decent SATA SSD: now imagine what happens when that's 2gbyte 1333mhz DDR3 RAM :)
enjoy.
l.
---------- Forwarded message ---------- From: luke.leighton luke.leighton@gmail.com Date: Thu, Oct 17, 2013 at 12:56 PM Subject: decent reasonably-priced armhf system with sata, gigabit ethernet, dual-core processor and 2gb of RAM To: ARM debian-arm@lists.debian.org
http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-October/009073.html http://store.r0ck.me/blogs/news/9361679-cubietruck-is-ready-to-order-now
this is from tom cubie who did the very successful cubieboard. specs look pretty damn good and pricing out of china is $90.
i think this is the first reasonably-priced armhf system with interfaces that would actually like... be actually like... interesting? y'know? to debian power users? :) over the past 18 months typically everything else with 2gb RAM or SATA or Gigabit Ethernet has been $150 to $250 and in one extreme case over $600. to actually get all of those *and* built-in WIFI/BT *and* dual monitors (HDMI and VGA) for only $90 is nothing short of bloody miraculous.
anyway. enjoy.
l.
On Thu, Oct 17, 2013 at 02:30:15PM +0100, luke.leighton wrote:
i posted this to the debian-arm list but it occurred to me that you guys might appreciate having a decent desktop-style system as well as something with enough RAM to do compiles of some of the larger packages without needing to run into swap space, as well.
joe (posting on arm-netbooks) has managed to get a sub-17-second boot to desktop out of the A20 when it's matched with 1gbyte 800mhz DDR3 RAM and a decent SATA SSD: now imagine what happens when that's 2gbyte 1333mhz DDR3 RAM :)
I was looking at the A20 a while back. This has a Cortex-A7 -compatible processor, right? Does it do hardware virtualization, ideally without too much hacking?
Rich.
On Oct 19, 2013, at 9:02 AM, Richard W.M. Jones wrote:
On Thu, Oct 17, 2013 at 02:30:15PM +0100, luke.leighton wrote:
i posted this to the debian-arm list but it occurred to me that you guys might appreciate having a decent desktop-style system as well as something with enough RAM to do compiles of some of the larger packages without needing to run into swap space, as well.
joe (posting on arm-netbooks) has managed to get a sub-17-second boot to desktop out of the A20 when it's matched with 1gbyte 800mhz DDR3 RAM and a decent SATA SSD: now imagine what happens when that's 2gbyte 1333mhz DDR3 RAM :)
I was looking at the A20 a while back. This has a Cortex-A7 -compatible processor, right? Does it do hardware virtualization, ideally without too much hacking?
Hardware virtualization support for the Cortex A-7 is just now going into the ARM kernel. See http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/205060.ht...
Here is a link to the A20 home page http://linux-sunxi.org/A20 where you should be able to find A20 specific documentation.
If you need cubietruck specific information I would start here http://cubieboard.org/support/
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Sat, Oct 19, 2013 at 5:02 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Oct 17, 2013 at 02:30:15PM +0100, luke.leighton wrote:
i posted this to the debian-arm list but it occurred to me that you guys might appreciate having a decent desktop-style system as well as something with enough RAM to do compiles of some of the larger packages without needing to run into swap space, as well.
joe (posting on arm-netbooks) has managed to get a sub-17-second boot to desktop out of the A20 when it's matched with 1gbyte 800mhz DDR3 RAM and a decent SATA SSD: now imagine what happens when that's 2gbyte 1333mhz DDR3 RAM :)
I was looking at the A20 a while back. This has a Cortex-A7 -compatible processor, right?
strictly speaking this is the wrong question: it *is* a Cortex A7. if it was "compatible" that would imply that it was some sort of clone, which it's not. allwinner are licensees of ARM cores, including the Cortex A7.
Does it do hardware virtualization,
http://www.arm.com/products/processors/cortex-a/cortex-a7.php
apparently yes. which is pretty amazing.
On Sat, Oct 19, 2013 at 07:31:20PM +0100, luke.leighton wrote:
On Sat, Oct 19, 2013 at 5:02 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Oct 17, 2013 at 02:30:15PM +0100, luke.leighton wrote:
i posted this to the debian-arm list but it occurred to me that you guys might appreciate having a decent desktop-style system as well as something with enough RAM to do compiles of some of the larger packages without needing to run into swap space, as well.
joe (posting on arm-netbooks) has managed to get a sub-17-second boot to desktop out of the A20 when it's matched with 1gbyte 800mhz DDR3 RAM and a decent SATA SSD: now imagine what happens when that's 2gbyte 1333mhz DDR3 RAM :)
I was looking at the A20 a while back. This has a Cortex-A7 -compatible processor, right?
strictly speaking this is the wrong question: it *is* a Cortex A7. if it was "compatible" that would imply that it was some sort of clone, which it's not. allwinner are licensees of ARM cores, including the Cortex A7.
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
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.
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 think I'm in a bit of a peculiar position because I care a lot more about having a serial port or a VGA port, than having a powerful GPU.
Rich.
On Sat, Oct 19, 2013 at 7:45 PM, Richard W.M. Jones rjones@redhat.com wrote:
I'm currently testing the ODROID-XU.
i got the odroid-u2. installation report here: http://lkcl.net/reports/odroid-u2.html
yes, there is no buffer on the RS232 port. you *really* have to watch out. henrik (hno) knows the full technical details, but basically TTL "off" (0) on UART is 3.3V (opposite of what you think it might be). so when you power down, the USB-to-RS232 converter is basically providing random 3.3V power *into* the processor. This Is Generally Bad.
henrik knows how to sort this out (resistors, diode) but basically *do not* have the USB-to-RS232 converter plugged in when the power is off. if you want to get at the boot sequence, then either a) tough b) get in there quick and repeat until success! :)
i had no problems, concerns or issues about either a) the use of micro-hdmi. just get a cable. b) the sd/mmc. i got 2. 1 is an 8gb eMMC, the other was a micro-sd converter so i could plug in a standard micro-sd card. the 8gb eMMC was lightning-quick.
what did i do with it? i installed xrdp and then ran *five* simultaneous desktop sessions on it. 6 made it keel over because i hadn't set up any swap space (and you shouldn't really set up swap onto an MMC card unless you expect to replace it regularly).
so yeah basically the exynos 44xx series absolutely rocks. it's a Cortex A9 though so no virtualisation, but with xrdp being successful i genuinely didn't care. if you want a Cortex A15, go for an arndaleboard. you'll get really good performance and virtualisation.
but, price-performance wise they're all completely outclassed by an A20. don't expect speed miracles compared to an A15 or an A9, but the interfaces (SATA, Gig-Eth) and the 2gb RAM more than make up for the "lowly" dual-core A7 aspect.
btw: exynos processors have treacherous-zone capabilities and on-board secret-boot flash. unfortunately all the suppliers of exynos boards activate it, thus banning you from replacing the bootloader and often banning you from replacing u-boot as well. by contrast allwinner processors are "unbrickable". pull a pin high and you go straight into USB "loader" mode. which has been reverse-engineered and software-libre (GPLv3+) sources are available for command-line bootstrapping with a [GPL-compliant, community-managed and publicly available] modified u-boot.
l.
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. Add to this the Exynos upstream support is not much better, I've been told by Linaro people that the support for Exynos multi platforms support will land upstream "soon" for way too long (going back to the 3.7 days) and I've basically given up hope and I strongly suggest not to bother with anything at all that's Exynos based.
I think I'm in a bit of a peculiar position because I care a lot more about having a serial port or a VGA port, than having a powerful GPU.
At the moment I believe the best bet for this sort of support will be the Allwinner SOCs (and I never thought I'd be typing that) and we'll work with Hans to ensure his remix is usable and that we support as much as possible upstream to make his life as easy as possible.
The best support for A15 we have at the moment is the Calxeda Midway devices but they're neither cheap nor widely available yet unfortunately.
Peter
Hi,
On 10/20/2013 12:40 PM, Peter Robinson wrote:
<snip>
At the moment I believe the best bet for this sort of support will be the Allwinner SOCs (and I never thought I'd be typing that) and we'll work with Hans to ensure his remix is usable and that we support as much as possible upstream to make his life as easy as possible.
Allow me to jump in here :) Now that we've a basically working kernel based on 3.4 android sources, the linux-sunxi community is recently focussing more and more on upstream work so we are slowly getting to a point were using allwinner devices with an upstream kernel may be feasible. This will likely be like the early trimslice days, so no video output support, but lan support is already in place upstream and usb support is on its way.
The big remaining issue upstream is mmc / sdcard support, but I've good hopes there too.
Once that is in place users will basically be able to choose:
1) Use plain Fedora, which will hopefully eventually support kvm on the cortex A7 (this requires using an upstream kernel), which means loosing things like video output, audio in/out, etc. (for now).
2) Use a linux-sunxi kernel, which means almost all peripherals will work, but no kvm support.
I hope to be able to start working on upstream allwinner support soon-ish, I'm more or less done with my work on the 3.4 kernel, everything just works there now (more or less). But I've been quite busy recently with other stuff.
Regards,
Hans
At the moment I believe the best bet for this sort of support will be the Allwinner SOCs (and I never thought I'd be typing that) and we'll work with Hans to ensure his remix is usable and that we support as much as possible upstream to make his life as easy as possible.
Allow me to jump in here :) Now that we've a basically working kernel based on 3.4 android sources, the linux-sunxi community is recently focussing more and more on upstream work so we are slowly getting to a point were using allwinner devices with an upstream kernel may be feasible. This will likely be like the early trimslice days, so no video output support, but lan support is already in place upstream and usb support is on its way.
The big remaining issue upstream is mmc / sdcard support, but I've good hopes there too.
Once that is in place users will basically be able to choose:
- Use plain Fedora, which will hopefully eventually support kvm on
the cortex A7 (this requires using an upstream kernel), which means loosing things like video output, audio in/out, etc. (for now).
- Use a linux-sunxi kernel, which means almost all peripherals will
work, but no kvm support.
I hope to be able to start working on upstream allwinner support soon-ish, I'm more or less done with my work on the 3.4 kernel, everything just works there now (more or less). But I've been quite busy recently with other stuff.
That's good news, from Richard's PoV the upstream with mmc/network/serial/virt support is probably more than enough to begin with.
Peter
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.
On 10/20/2013 01:00 PM, luke.leighton wrote:
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.
The problem isn't the lack of BIOS - the problem is the lack of standards, specifically related to bootstrapping ARM CPUs. Perhaps I am nitpicking, since the two amount to the same thing in practical terms.
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??".
I'm not so sure that is the case. As is has usually been the case in the past, I suspect the first overwhelmingly popular product will be what sets the standard that everything else is going to have to support in order to be considered.
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.
I think you are confusing monopoly with consensus.
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.
It sounds more like the problem is that the ARM "standard" isn't in fact a standard but more of a guideline that nobody sticks to.
... 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").
The good old days of the HTC Universal. :)
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.
I'm not sure this is really related to the previous paragraphs - it doesn't mean that a different EOMA68 card implementing all of the same interfaces will be bootable using the same bootloader or kernel.
Gordan
On Sun, Oct 20, 2013 at 12:51:30PM +0100, Peter Robinson wrote:
At the moment I believe the best bet for this sort of support will be the Allwinner SOCs (and I never thought I'd be typing that) and we'll work with Hans to ensure his remix is usable and that we support as much as possible upstream to make his life as easy as possible.
Allow me to jump in here :) Now that we've a basically working kernel based on 3.4 android sources, the linux-sunxi community is recently focussing more and more on upstream work so we are slowly getting to a point were using allwinner devices with an upstream kernel may be feasible. This will likely be like the early trimslice days, so no video output support, but lan support is already in place upstream and usb support is on its way.
The big remaining issue upstream is mmc / sdcard support, but I've good hopes there too.
Once that is in place users will basically be able to choose:
- Use plain Fedora, which will hopefully eventually support kvm on
the cortex A7 (this requires using an upstream kernel), which means loosing things like video output, audio in/out, etc. (for now).
- Use a linux-sunxi kernel, which means almost all peripherals will
work, but no kvm support.
I hope to be able to start working on upstream allwinner support soon-ish, I'm more or less done with my work on the 3.4 kernel, everything just works there now (more or less). But I've been quite busy recently with other stuff.
That's good news, from Richard's PoV the upstream with mmc/network/serial/virt support is probably more than enough to begin with.
Right, as Peter says.
Also I've just ordered a Cubietruck, so we'll see how that goes.
Rich.
-
Gordan Bobic -
Hans de Goede -
lkcl . -
Peter Robinson -
Richard W.M. Jones -
rihoward1＠gmail.com