Bug 4009 - Investigate feasibility of Linux client for ARM devices
Summary: Investigate feasibility of Linux client for ARM devices
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client platforms (show other bugs)
Version: 3.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.0.0
Assignee: Aaron Sowry
URL:
Keywords:
Depends on: 4357
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 13:35 CEST by Peter Åstrand
Modified: 2012-11-28 12:19 CET (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Peter Åstrand cendio 2011-09-29 13:35:06 CEST
In issue12611 we got an request for an ARM client for Linux. Citrix has one.
Comment 2 Aaron Sowry cendio 2012-09-05 16:30:11 CEST
This looks cute (if it ever materialises):

http://cubieboard.org

Cortex A8 (ARMv7) with hard-float and NEON SIMD support. And a SATA port!
Comment 3 Aaron Sowry cendio 2012-09-06 10:48:05 CEST
(In reply to comment #1)
> * What kind of customer interest are there for cheap ARM based thin terminals?

This is difficult to know without doing some research, so I will make a point of asking around when I talk to customers. Until then, we know that customers such as Queen Mary University are very interested in this type of solution, for two reasons:

- Budget limitations require cheap hardware

- They are technically competent enough to manage and maintain the system themselves, without paying for proprietary central management systems such as SCOUT etc.

Technical universities in general are therefore probably quite interested in a cheap ARM-based platform.

> * What kind of products are available?

There are a ridiculous number of cheap ARM-based boards coming out of China, so we're spoiled for choice really. Companies such as Wyse and HP are also releasing ARM-based units these days, but I think that focusing on these defeats the purpose a little - we should instead focus on generic Linux-based ARM platforms.

We should perhaps try to find a reliable supplier who can provide a good, cheap ARMv7-based SoC.
Comment 4 Aaron Sowry cendio 2012-09-11 15:52:55 CEST
Some information regarding the most popular ARM Linux distributions:


Debian
------
Debian has/had 3 ARM builds:

- arm   (FAIAP obsolete)
- armel (targeting ARMv4 and above, no hard-float support)
- armhf (targeting ARMv7, hard-float and Thumb-2 support)

The armhf port is probably the most interesting, since most[1] ARMv7 implementations seem to support NEON. Hard-float may also give us some performance improvements. The Debian ARM ports will be based on eglibc.

The downside with Debian armhf is that it is slated for release with Debian 7.0, which will be announced... well... it's anyone's guess, really.

[1] Cortex-A8 requires NEON, but it is optional in Cortex-A9 implementations. We should be careful therefore as to what we recommend.


Fedora
------
From what I can tell, Fedora has two active ARM builds:

- armv5tel (targeting ARMv5, no hard-float support)
- armv7hl  (targeting ARMv7, with hard-float support)

According to [2], Fedora 18 will support:

- Devices with VFP3 or later FPU and v7 or higher instruction sets such as
        QEMU Simulator
        OLPC XO-1.75
        Enterprise hardware that we will use as build servers (Marvell Armada-XP, Calxeda Highbank).
        Panda, Beagle, and Origen Development boards.
        Trimslice (Tegra) and EfikaMX (iMX) hardware. 
- Devices with VFP2, older (or no FPU), and v5 or higher instruction sets such as
        QEMU Simulator
        Raspberry Pi
        Most Marvell Kirkwood plug type devices ( eg Guruplug, Sheevaplug, and Dreamplug) 


Unless it gets pushed back again, Fedora 18 is scheduled for release later this month.

[2] http://fedoraproject.org/wiki/Features/FedoraARM
Comment 5 Aaron Sowry cendio 2012-09-11 16:20:57 CEST
Unknowns:

- Debian (armhf) specifies Thumb-2 support explicitly, where as Fedora doesn't mention anything. Perhaps Thumb-2 support is implicit in ARMv7, though.

- Debian (armhf) specifies VFPv3-D16, however Fedora specifies only "VFPv3 or higher". There are 3 different versions of VFPv3 - which do we compile for? If it is unclear, then VFPv3-D16 should presumably be safe.

- Debian (armhf) uses the triplet "arm-linux-gnueabihf", which we can probably use to find out what compiler flags are used. What does Fedora use?
Comment 6 Aaron Sowry cendio 2012-09-13 10:32:35 CEST
Regardless of how we decide to approach this, we probably need some hardware. There's quite a lot available, here are a few:


PandaBoard
----------
http://www.tigal.com/product/2372/

+ This is apparently what Debian use to compile their ARM builds natively on, so it should be well supported

+ OMAP4460 Cortex-A9 CPU, which seems to have all the fancy stuff we need (ARMv7, NEON, Thumb-2, hard-float)

- Proprietary POWERVR GPU which apparently is problematic under Linux (see [1])

- Not the cheapest of options

[1] http://alastordmcblog.blogspot.ie/2012/09/debian-on-pandaboard-graphics.html


BeagleBoard
-----------
http://beagleboard.org/hardware-xM

+ OMAP3530 Cortex-A8 CPU which seems to meet our requirements

+ Supported explicitly by the Fedora ARM project, so should be well supported

- Proprietary POWERVR GPU


OrigenBoard
-----------
http://www.origenboard.org/

+ Modular, so theoretically possible to change CPUs etc if we need to

+ Open drivers available for the GPU in the Linux kernel

+ Supported explicitly by the Fedora ARM project

- Expensive, and probably overkill for what we need


TrimSlice
---------
http://trimslice.com/web/

+ Complete package, including housing/chassis. Basically ready to be used as a thin-client OOTB - they even have rebranding options

+ Supported by the Fedora ARM project

- NVIDIA (Tegra 2) chipset

- No NEON support
Comment 7 Aaron Sowry cendio 2012-09-18 13:50:28 CEST
The initial study can probably be deemed complete now; we know roughly what we need to build. The only thing remaining is to determine how popular ARM Linux really is in practise, and whether it's worth devoting the time to it. Closing.

Note You need to log in before you can comment on or make changes to this bug.