[GTALUG] Cubox Dev Platform OS images?

[Scott Sullivan]

On 12/16/2014 04:55 PM, Thomas Milne wrote:
> Hey sorry to bug you, I am unemployed again and in dire need of a
> project :-)
>
> If you have that image or if you know a way I could generate my own, I
> tried searching but everything now is about the Cubox-i.
>
> Solidrun might have an original image but I would really like to have
> Debian armhf which is I assume what you have installed?

Ah, I knew there was something bugging me.

Thomas, wanting a armhf port for the cubox is, to use a bit of 
hyperbole, like wanting an 64bit port for your i686. Allow me to set up 
some background information then explain.

Debian's armhf port is for ARMv7 instruction set hardware which mandated 
the inclusion of floating point hardware.
https://wiki.debian.org/ArmHardFloatPort

Debian's armel is for older arm instruction sets that where a floating 
point hardware was not mandatory in the chips.
https://wiki.debian.org/ArmEabiPort

Your Cubox uses a Marvell Kirkwood system on a chip (SoC). That SoC was 
base on a ARMv5 instruction set. As such it is supported by the armel 
port only. Much like 32bit intel hardware is only supported by the i386.

So, asking for armhf is inapporiate as your hardware can't run it. But 
the armel port should be keeping up todate with all the package updates 
just like i386 follows amd64. So I don't think your goal has change, 
which is get as modern a debian you can on the cubox. Just know you need 
to be looking at the armel port.


On that note, I found this little message outlining Mainline Kernel 
support for the cubox. The Marvel Kirkwood SoC has been well supported 
for many years now, and with the move to Device Tree the cubox can be 
supported with a far more generic kernel.

https://lkml.org/lkml/2014/5/26/562

A Device Tree is basically a listing handed to the kernel that tells it 
how the SoC may be uniquely wired to other devices on the circuit board. 
SoC, unlike intel computers, will multiplex function on their pins to 
allow device designers to pick and choose what functions they will use. 
It's part of why they can be put in such small form factor devices, at 
the cost of software complexity.

Specifically for you Thomas, you'll need to take an armel port of debian 
and the dts (Device Tree) for the cubox and combine them. Go hunting for 
information on other Marvell Kirkwood Devices for examples (the PogoPlug 
v2 and Dreamplug, being two examples I personally own).





Now just general information expanding on the armel vs armhf.


ARMv4, ARMv5 and ARMv6 hard was an interesting matrix of common 
capabilities due to the nature of optional phyical hardware blocks. The 
means there had to be some careful choices by the debain maintainers.

https://wiki.debian.org/ArmEabiPort#Choice_of_minimum_CPU


The gist of the above is that some devices CPU instruction will not be 
taken advantage of even if the SoC _does_ have the optional hardware. 
The greatest current example of this is the Raspberry Pi, an ARMv6 
device which does have floating point hardware. This meant that while 
the armel port will run on the Raspberry Pi's Broadcom SoC, it's not at 
full performance. The Raspbian Distro is a port of debian targeting the 
specifically available hardware in the Broadcom SoC for all the 
performance benefits that can bring.

-- 
Scott Sullivan