As a result, FatdogArm now supports Odroid-XU4. The support is pre-eliminary - it's mainly kernel supports; the usual hardware acceleration stuff aren't supported yet.
The kernel package for Odroid-XU4 (and also XU3 - these two are software-compatible with each other) is here: http://distro.ibiblio.org/fatdog/arm/releases/beta4/kernel-packages/, or on any of ibiblio's mirrors.
This work is still in flux, though, as I'm still tweaking the kernel. It's now my 3rd compile. It may change. And while you can find beta4 SFS there, I haven't really released it and I may still make some changes soon.
Odroid-XU4 is a little machine that could. The SoC is Samsung Exynos 5422. It comes with 8 cores (ARM BIG.little architecture - 4x 2GHz cores, and 4x 1.7GHz cores), *ALL( of which can be run simultaneously under HMP mode.
It is so powerful that:
a) I can decode h.264 1080p video and render it to 1080p, with AAC audio, using software only (no hardware acceleration).
b) I can watch youtube using html5, with audio, without any stutter.
I've never been able to do this in my previous board. It is the fastest little board I've ever used, bar none.
It comes with a cost though. All those speed doesn't come from nothing. It is no longer fanless like Odroid-U2; XU4 comes with a fan. The power supply now can provide juice up to 4A - but this probably to support 2 USB3 ports on its board too.
PS: I used 3.10.y kernel. The 4.2 kernel is marked as EXPERMENTAL by hardkernel and currently lacks many of the fine improvements you can find in 3.10, like sound, and HMP support. It was created to be able to boot Debian server, but I find that even for server work, this is no good because it lacks the ability to schedule the cores properly. And furthermore, it seems to have been abandoned (last update is Aug 2015, while 3.10 is updated just a week ago).
PPS: An oh, on the same URL, you can find official Raspi2 kernel packages too. This is my official kernel packages, which I built from source, and of which I can also supply its kernel source SFS. The berryboot-based kernel are still available in its old link but I'm going to take it down soon.
Comments - Edit - Delete
Thanks to the help of forum member "mories" and the berryboot 2.0 kernel/modules, it was possible to get FatdogArm on raspi2: http://murga-linux.com/puppy/viewtopic.php?p=878960#878960. It's available here: http://distro.ibiblio.org/fatdog/arm/releases/raspi2/.
But I could not test it myself since I didn't own a raspi2 myself. Now, a kind gentleman who prefers to remain nameless has given me a raspi2 board, together with a very nice cover.
Though I am very busy these days, this inspired me to get the basics going on. I've just built a kernel directly from Raspi's official kernel source distribution (branch 4.1.y). Together with the closed-source bootloader (also from Raspi's official firmware distribution), I've managed to get it to boot to desktop.
This is still a long way to get raspi2 to become a tier-1 supported platform (we need to configure various hardware acceleration modules), but at least it is now running under its own kernel.
When things is a bit more stable I'm going to prepare a proper raspi2 kernel package, replacing the berryboot-based package we have right now. And perhaps publish beta4.
Comments - Edit - Delete
There were a lot of people who reported these, and only got the shrugs ... "works for me" type of replies. Most of the "solutions" to this problem concerns about variation of parameters to use on brcm_patchram_plus, as well various links to different versions of .hcd file dumps. However, most of the messages ended there. There were no confirmation whether or not the fix works, and whether there are possibly other causes. And no-one said anything about the kernel.
As it turns out, the kernel *was* the problem. The bluetooth host hardware in cubox-i is connected via MMC SDIO, using the serial interface. To support serial bluetooth devices correctly, the kernel needs BT_HCIUART_* to be enabled. The default defconfig from SolidRun 3.10 kernel did't enable these , and there were no notes whatsoever saying these configs are needed at all . I have been using Solidrun's defconfigs (= manufacturer knows best, etc) - and badly beaten by it, wasting hours on unnecessary debugging
Curiously, SolidRun 3.14 kernel defconfig *does* have these enabled - so they *do* know. Why this isn't documented elsewhere - I have no idea. Go and ask them.
Anyway, as soon as the kernel is rebuilt, bluetooth works. I tested it by getting it paired and connected with a bluetooth speaker and bluetooth keyboard. Both works nicely.
I have integrated these findings into a package called imx6-bluetooth, and have uploaded it to the repo. However, it won't work unless you use a kernel with