FatdogArm on Odroid-XU4

A kind gentleman who goes by the nickname of "pjf" on Puppy Linux forum gave me an Odroid-XU4 to play with.

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.

Posted on 6 Apr 2016, 00:11 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm on Raspiberry Pi 2

There were some interest in running FatdogArm on Raspberry Pi 2 (raspi2 for short). While FatdogArm will never run on the original Raspberry Pi for many reasons (the biggest one: unsupported ARMv6 architecture), raspi2 has a modern quad-core Cortex A7 (=ARMv7 architecture) CPU running at 900 MHz, and comes with 1GB RAM standard. Not stellar, but not bad either.

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.

Posted on 15 Feb 2016, 23:25 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Bluetooth support for Cubox-i

Bluetooth was the last feature of FatdogArm that wasn't working on Cubox-i (it works on the Nexus 7). The last time I looked on it was on April this year. My main problem was I always get the message "can't set hci protocol" near the end of firmware upload, when using the built-in hci driver with brcm_patchram_plus (similar message when using the external hciattach).

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 those configs enabled.

I'm going to upload a new kernel for cubox-i later. If you're interested to use it *now*, then leave me a message.

With this, the FatdogArm platform support for cubox-i is considered complete.

Posted on 17 Sep 2015, 00:02 - Categories: FatdogArm Linux Arm Fatdog64
Comments - Edit - Delete

Misc updates - PSIP, FatdogArm, xlogin

I have implemented multi-account support in psip, a long-time asked feature. You can keep multiple accounts but only one can be active at a time. PSIP will be included in the upcoming Fatdog64 701 release.

FatdogArm Beta3 has been released - with new Nexus7 2012 support, dual-core support fror OLPC XO-4, and improved touch support overall. Thanks to 01micko and mavrothal for their tests, feedback and suggestions. Check out the release notes.

xlogin is a very small Xorg login manager, more basic that slim which is included in Fatdog, but it has one thing that slim does not - it supports network operation and XDMCP. Jon (the original author) stopped development long time ago (about 2008 looking at the file dates), but I found this useful, so I picked up the code, cleaned it, fixed it where it didn't work - and I have my fork here.

Among other changes, it now works with authorisation (MIT-MAGIC-COOKIE stuff), and I have re-coded xlogin-rootjpeg to use stb_image so it no longer depends on libjpeg - plus ability to resize the image on the fly.

Posted on 20 Apr 2015, 05:21 - Categories: FatdogArm Linux Arm Fatdog64
Comments - Edit - Delete

FatdogArm on Nexus 7

A kind gentleman who prefers to remain anonymous gave me an Asus Nexus 7 2012 ("grouper") last year so that I could put FatdogArm on it. Due to various circumstances, I was not able to look into it until very recently.

The same gentleman informed me that most of the works should have been done since Ubuntu team has managed to boot Ubuntu on it as early as 2013, and there was a development called Multirom that enables dual/multi-booting of various OS on Nexus 7, making it even more convenient.

Well, I was late to the game, but late is better than never. I finally had the chance to try to get it going. The Nexus 7 given to me was in a pristine condition, stock firmware, not rooted. So I upgraded it to Android Lollipop 5.1, rooted it, installed Multirom on it (manually). Perhaps I will write the steps a little later.
Then I grabbed Ubuntu Nexus 7 kernel and modified it for FatdogArm, and after some little tinkering, here is an image.

Framebuffer, framebuffer console, wifi, sound, touchscreen, USB-OTG all works thanks to Ubuntu hardwork of porting mainline kernel to support Nexus 7. I have not tested other devices (accelerometer, camera, compass, etc).

It is still early days but I hope I can upload a beta3 version of FatdogArm with basic support for the Nexus 7 (and the recently rebuild SMP kernel for XO-4) soon.

Posted on 1 Apr 2015, 0:59 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

SMP-enabled kernel for OLPC XO-4

I had known even before I received the laptop over a year ago that the Marvell Armada PXA2128 Soc used in XO-4 featured a dual-core CPU, but for some reason the kernel didn't support that.

I recently got tipped by forum member mavrothal, my partner in development of FatdogArm for the OLPC, that the OLPC kernel for XO-4 finally got dual-core capability, who had built the latest git master from the kernel and got SMP kernel working.

I didn't have the time back then, but yesterday I finally got the chance to play with it. I built the kernel myself too, and I needed to update the OFW firmware to at least q7c04 for the dual-core kernel to run, but everything is smooth - new kernel booted and worked flawlessly with both cores enabled. All the existing functionalities continue to work, but the rc.platform will require a little patch because the ID code that I used to identify XO-4 has changed.

I will upload the new kernel, with update instructions (mainly pointing back to OLPC on how to update the firmware etc), and a new FatdogArm sfs with the required rc.platform change.

It has been a long time since the last FatdogArm beta2 release, so I may as well update some of the other packages too and call it beta3. Watch this space for further announcement.

After updating the OLPC firmware, the old original Fedora/Sugar in XO-4 will stop running. The fix is to download a newer build of the OS and install it to the laptop.

I need to say that I continue to be impressed and amazed of how OLPC implements these processes (both updating firmware and updating the internal OS). They are simple, easy, foolproof and very informative.

This is a far cry from similar processes of other commercial offerings. Especially since I had to deal with UEFI recently - if only UEFI implements half of what OLPC does with its Open Firmware, it would have been immensely more useful. Something's got to be better than BIOS, but UEFI isn't the one - OpenFirmware certainly is.

I applaud the engineering that went into the design and implementation of these features. There must have been a lot of thinking, and a lot of effort to examine of how the processes on standard PC broke down or failed in one way or another - and they made it really better.

This is of course on top of other excellent features of OLPC laptop - and I don't even mean the advertised educational benefits - but things like physical robustness, ease of maintenance, quality selection and durability of its components. Sure, this does not make it the lowest cost laptop (or even a lower cost tablet), but quality has its price and an investment of an OLPC laptop will far out-weight its cost and last far longer than any other laptops (or tablets) designed for similar purposes.

Personal note - I still think that a laptop is a far more useful for education than a tablet, regardless of the recent fad. If you are a decision maker and considering to get some sort of tablets or OLPC laptops, I'd highly recommend you go with OLPC XO-4. As a bonus, an XO-4 with touch screen (XO-4 touch) can function as a tablet too - just flip its screen. That is how versatile it is.

Disclaimer: I am saying all the above not because I am affiliated with OLPC (the only indirect relationship I have with OLPC is that I am doing a non-commercial community project for the OLPC XOs - that is, FatdogArm). I really like the OLPC laptop, I really like OLPC mission, and I really wish and hopeful that OLPC as an organisation will succeed and continue to focus on these quality offerings.

Posted on 28 Mar 2015, 19:30 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm Beta2 sfs re-uploaded

The main change is that xorg-server is now built with these two patches: http://forum.odroid.com/viewtopic.php?p=37553&f=7#p37553 and http://forum.odroid.com/viewtopic.php?p=35833&f=7#p35833 for better performance and stability. Thanks Daniel (aka dsd). This change only improves Odroid, and has no impact in other platforms as only Odroid uses DRI2 interface at the moment (Allwinner: fbdev, OLPC/Marvell: DRI1, Cubox-i/Freescale: DRI1).

Coupled with a few updates in the repo and youtube-dl, it is now possible to write a simple script that will stream video and play it fullscreen on Odroid/Cubox-i directly from youtube. Perhaps I'll share that script later.

Posted on 8 Oct 2014, 5:33 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

3D hardware acceleration for cubox-i

I have finally managed to get 3D acceleration working on cubox-i. This has been long-time coming.

Initial testing of the 3D acceleration always caused a hard lock-up on Xorg. System was still alive, and was still responsive (if you use SSH), but Xorg completey died, you can't even switch VT anymore.

Today I have finally found the solution - Freescale provided a patch for libdrm, *and* Xorg must be re-compiled against this patched libdrm. This was found as early as March by forum member "notwa", but I didn't take this seriously because:
a) it was intended for kernel 3.0.35 while I used 3.10.30 kernel
b) I actually patched libdrm but didn't rebuild xorg-server as I thought it was unnecessary (I reviewed xorg-server source to find where exactly the patched change could have impact, and couldn't see it).

Today I found that another forum member "catwich" had the same problem I had, and confirmed that "notwa" solution worked - if followed in full. I decided to have a go myself on FatdogArm, and look and behold - it worked! es2gears, glmark2 and glmark2-es2 all worked. What a joy!

The updated drivers will be in the repository as usual. As a closing note, I also built gst-plugins-gl (containing "glimagesink" - see my earlier post about hardware accelerated video playback pipeline), and it works well as an alternative to mfw_v4lsink.

With this, support for cubox-i platform is now considered complete (apart from bluetooth support, but that's minor stuff ... may be later). All these work with FatdogArm beta2. I updated the release note to reflect this fact but if you have already downloaded the SFS and the kernel package, there is no need to download again as there is no change there: all the drivers are in the repository and those are the ones that got updated.

Posted on 6 Oct 2014, 1:23 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Hardware-accelerated video playback on Odroid U2/U3 - part 2

Near the end of my previous post, I said that while the video playback was decent, it was not as smooth as expected, and that "memeka" from the odroid forum suggested to use cluttersink instead of glimagesink.

I have now built and tested cluttersink, and indeed cluttersink shows smoother playback than glimagesink. There is one small difference: cluttersink doesn't respect aspect ratio, it will just scale up everything to its window size; while glimagesink does honour aspect ratio (but you can disable it if you don't need it).

Here is an example pipeline that plays an mp4 file, both audio and video, with full video acceleration using cluttersink:
gst-launch-1.0 filesrc location=/path/to/media.mp4 ! qtdemux name=m m. ! queue ! h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! v4l2video8dec ! v4l2video10convert ! cluttersink m. ! queue ! faad ! audioconvert  ! alsasink

The same pipeline, simplified using decodebin:
gst-launch-1.0 filesrc location=/path/to/media.mp4 ! decodebin name=m m. ! queue ! v4l2video10convert ! cluttersink m. ! queue ! audioconvert ! autoaudiosink

cluttersink is available in "gst2-clutter" package in the repository.

I also re-uploaded Odroid U2/U3 kernel package for FatdogArm Beta2, now with MFC firmware (which is needed for hardware acceleration). Thanks to forum member "mories" who informed me that I forgot to do that. Beta2 sfs is also re-uploaded, now with updated glib (2.38.2 now, it was 2.36.3 previously) which is needed for cluttersink and its libraries, among other small fixes.

Posted on 4 Oct 2014, 16:48 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Hardware-accelerated video playback on Odroid U2/U3

Thanks to the effort of many people, I have uploaded gstreamer 1.x libraries (1.4.3) (gstreamer2 and gst2-plugins-* in the repository) which provide support for video playback acceleration on Odroid U2/U3 on FatdogArm.

The accelerated pipeline in Odroid U2/U3 goes like this:
- hardware decoding (Samsung S5P MFC codec) - use v4l2video8dec
- hardware colourspace conversion (Samsung FIMC) - use v4l2video10convert
- GPU-assisted rendering - use glimagesink

There were a few hassles to finally get to this.

The hardware decoding was quite a breeze. The kernel has supported the MFC codec for a while. The userspace support was done by a gstreamer plugin called mfcdec, but this was finally deprecated and replaced with v4l2-based decoder in the most recent gstreamer version.

Hardware colourspace conversion didn't work due to a bug in libv4l2, as found out by forum member "memeka" in this post. The library basically assumes that all v4l2 devices can use DMABUF interface to v4l2 devices, but Samsung FIMC kernel drivers don't support that, only normal mmap-ed access. Disabling libv4l2 forces gstreamer to use its own internal code which works with either. So, following his advice, FatdogArm gstreamer libraries are built without libv4l2 dependency. However, the default colourspace converter for gst-play and playbin is unchanged and is still the software decoder (videoconvert) - because forcing the default to Samsung converter results in colour artifacts. If you need to use hardware colourspace converter, you will need to build the pipeline yourself (and if you do this yourself, there is no artifact - the artifact is only seen when using gst-playback/playbin with hardware converter, which is odd).

GPU-assisted rendering is done by glimagesink. This component replaces eglglessink in earlier gstreamer version. Due to a long-standing bug in Mali driver (documented here, found in r3p2 and still exist in r4p0), it doesn't always work (well - it *mostly* doesn't work on my tests). To make it work, I patched the binary driver (it's also in the repo as libmail-odroid).

The result of the acceleration is decent, but it is not as smooth as I hope. "memeka" in another forum post said that the best sink is cluttersink (better than glimagesink). We'll see about that later.

To test that it is all working, try this pipeline (it is one long line):
gst-launch-1.0 filesrc location=/path/to/media.mp4 typefind=true ! qtdemux name=m m.video_0 ! h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! v4l2video8dec ! v4l2video10convert ! glimagesink

This pipeline will only play the video and there is no buffering, but you get the idea.

Posted on 3 Oct 2014, 6:41 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Pages: [1] [2] [3] [4] [5]