I will build an image this weekend, monday latest.
Holds a new kernel based on much appreciated armbian efforts, hope this will help, but no guarantee of course.
How is it going?
Armbian kernel had a few things missing, a kernel rebuild will be done tonight and an image aftwerwards. Tough oneā¦
OK, armbian kernel probably ok, I found out why the armbian kernel is not booting.
It needs changes to the build script, planned for tomorrow.
Hello! Any news about that?
Sorry, no news, did not find the time yet. But going steady for the top of my list of TODOs.
We still do not have a stable kernel 4.x based image for cuboxi, mainly because of pops and crackles on usb audio. and veeeeery slow network.
Iām giving it one more go in the next couple of days, but in case it still does not work there is nothing we can doā¦
Really sorry about thisā¦
Please keep at it. Personally I have been waiting since 2016 for results here, and would have thought twice about buying a cubox if Iād known of the wait. But the reason for the cubox is the sound quality through optical.
Please be aware that some users are using optical cable not USB.
So to make this abandonware because of a mistaken belief that users are using USB, would be to mis-read the user base.
Cubox is the product that provides optical! Raspberry Pi did not for a very long time, and for all I know, maybe it still does not. I was happy to pay the much higher price for a cubox for optical.
Thank you for your work. We believe it will be worth the wait!
Donāt know if itās any use but as well as a Volumio on Cubox-i user Iām one of the OSMC developers and youāre welcome to try adapting our Vero OSMC kernel which is based on 4.4.0 but has many many patches to fix issues and make it stable for use with Kodi, so it may be a good starting point for Volumio on Cubox-i as well.
The original Vero was a custom dual core Cubox-i with Gigabit Ethernet, so our kernel is only tested for this configuration and is known not to work for Quad core but it probably wouldnāt take much work to support other Cubox-i variants like quad core. But it should work as-is for any Dual core model.
The kernel sources are here:
github.com/osmc/vero-linux/commits/master
And our build script is here:
github.com/osmc/osmc/blob/maste ā¦ c/build.sh
Our build system is self hosting on OSMC, so can be built on any armv7 device such as Cubox-i or Raspberry Pi 2 or later running OSMC, Debian Stretch or Raspbian Stretch.
To build:
git clone https://github.com/osmc/osmc
cd osmc/package/kernel-osmc
make vero
The user running make will need sudo rights to create and enter a chroot build environment and the output will be a Debian kernel package.
You may wish to use your own build scripts and perhaps just look at our kernel patches and build script.
Hope that helps - Iād hate for Cubox-i support to be dropped - even with the old 3.14 kernel it is working perfectly for me with USB audio with no crackling - in fact the whole reason Iām using my Vero/Cubox-i for Volumio is due to the unsolvable USB crackling issue that the Raspberry Pi kernel/hardware suffers fromā¦
PS regarding poor Ethernet performance - if you are testing with a Cubox-i with Gigabit Ethernet there is a known performance issue which cannot be fixed in software where performance will be very poor if the Ethernet switch port does not have hardware Flow control enabled.
The only solutions/workarounds are to either enable flow control on the Ethernet switch, change to a switch that supports flow control, or force the Ethernet speed to 100Mbit using ethtool.
Edit: Sam (lead OSMC developer) has just corrected me and says that Gigabit is properly fixed in our kernel now and can work at near full speed. I was not aware of that. 
Ok, this seems a very promising path, thanks for the hints.
Iāll start with it tonight and see how far I can get before leaving for 2 weeks.
Fingers crossedā¦
As for usb audio vs. optical: as usb audio quality (when usb is working properly) is way superior over optical I will only release a version which covers both.
@DBMandrak: so I only need āhttp://github.com/osmc/vero-kernelā and I will have all patches included? (working with that just now)
Or is the build script applying patches to the kernel source?
Our kernel build process is not my area of expertise (thatās Samās) but I know the basics.
Thanks for reminding me - there are some patches applied by the build script but I believe all but one of them are not essential. Theyāre mostly additional or alternative out of tree USB Ethernet drivers, USB wireless drivers, DVB tuner drivers etc that probably arenāt relevant for Volumio using the built in Ethernet and Wifi.
The build scripts pull patches from the directory below, only patches starting with vero (not vero2, vero364) will be applied:
github.com/osmc/osmc/tree/maste ā¦ mc/patches
The kernel .config is one of the patches - vero-027-add-kernel-config.patch. If not all patches are applied some minor fixups might be needed for .config for options that donāt exist etc.
Youāll probably also need to revert the two commits in the kernel tree that add the vero device tree and disable building of all other device trees.
I also forgot to mention, if you do try to use our build scripts to generate a quick test kernel, although you can build on Debian/Raspbian you would need to add
deb apt.osmc.tv stretch main
to /etc/apt/sources.list and add the apt public key as the build process installs a toolchain package from our repo which provides the chroot build environment. Another easy way to build a quick test kernel would be to just install OSMC on a Pi 2 or Pi 3, apt-get install git and build-essential, then clone the repo and build as I posted earlier. OSMC on Pi 2 / Pi 3 can build a kernel suitable for the Cubox-i.
One modification in our kernel that one of the patches applies is to call /sbin/splash_early as init (we have a wrapper script there which performs other actions then calls normal systemd init) but I think from memory we still fall back to normal init locations. Our kernel also uses an initramfs to boot based on standard boot options passed from uEnv.txt.
The initramfs scripting is in init and init.d/vero in:
github.com/osmc/osmc/tree/maste ā¦ tramfs-src
Hope that helps.
OK, I built the kernel with the source repo you pointed me to.
Used our own kernel config (because of overlayfs, squashfs and iptables support), it seems to have compiled ok.
Iāll continue with it tomorrow, thanks for the support!
Edit: we only need the kernel, everything else is in our build scripts
crossing my fingers. I am dying to use my cubox-I for volumio 2! It is hooked up via optical S/PDIF to my receiver. I only have a small library on it for now because of the crashes if I put my whole library on it. Even with the small one after a little while of playing it dies!
Hoping that the two week break was good.
yes it was.
And before you ask: no, no working image yet.
I started last weekend but struggle with a kernel panic after running the volumio initramfs.
As it appears, the new kernel reports a different hardware name (Vero instead of Freescale), I did not expect that and might have to change some Cubox-specific settings to fix it.
Hope to do this soon, but really, we are very busy here, Cubox is not the only thing on my plate, Be a little patient, a link to a new image gets posted as soon as it is ready (not this week).
- GĆ© -
unfortunately the vero kernel has not been much of a help either, after fixing the initramfs problems, the boot process ends with an endless loop āsystemd[1] Time has changedā.
Not that I did not try, but Iām giving up the kernel update to 4.x.y.
It just takes me too much time, time I would rather spend on things that bring volumio on other platforms forwards.
This does not mean Cubox is dead, but new versions will limited to versions with kernel version 3.14.
In case someone else wants to have a go at a mainline kernel, then I will be happy to offer my support.
Edit: I have one!! The slightly modified 4.15.18-cubox Version from the armbian people seems to be OK.
Testing now and will report back
Meanwhile I started the build of cuboxi version 2.414, which will be added to the opening post as the current supported cubox version.
I invite people to test this version and give feedback if there is anything out of the normal.
Never say never 
I have succesfully tested the newest image, based on Kernel 4.15.18
It is considered stable enough for you to test and use, feedback welcome.
The opening post has been updated for the link to volumio for cuboxi version 2.417
ā GĆ© ā
formatting my card now to test, canāt wait!
not booting for me