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