FatdogArm Beta2 release
FatdogArm Beta2 is a minor release, mainly:- bugfixes and upstream update from Fatdog64 700
- updated kernel package for Odroid U2/U3 with r4p0 Mali driver
- introducing support for cubox-i (Freescale i.MX6DL/i.MX6Q SoC)
Release note here.
Get it from here or any of ibiblio mirrors.
Comments - Edit - Delete
1080p video playback on cubox-i
I have been experimenting with hardware acceleration for video playback on i.MX6 (cubox-i), that came with Freescale BSP. The most recent released for Freescale BSP is version 3.10.17, for their kernel GA 3.10.17.Hardware acceleration of anything is a fickle thing, because there are non-standard ways of doing things (one may disagree and says that there are too many standards to choose from: vdpau, vaapi, openmax, gstreamer, and others). In the end, different hardware vendors supports their hardware with different libraries.
Freescale chooses to use gstreamer to support video playback acceleration. It comes are a set of open-source gstreamer plugins, which links to closed-source VPU* and IPU* libraries, for gstreamer 0.10. Yeah that's the old version but it still works. Freescale has a newer (semi-official?) "community"(?) gstreamer 1.0 libraries but the support is not identical with 0.10 libraries.
[*Note: VPU is Freescale's hardware video processing unit, and IPU is Freescale's hardware Image Processing Unit]
The 0.10 libraries are purely VPU/IPU based and does not depend on a working GPU. It has a few plugins: a demux plugin ("aiurdemux") that recognises certain common formats like AVI, MKV, WEBM, MP4 and others, a VPU-assisted video decoder ("vpudec") and a video renderer (sink) that is IPU-assisted (mfw_v4lsink), among others.
If this sounds like alien language, let me translate it for you: "demux" is the one that splits a media file into its video and audio component (so they can be routed and processed by different components). "video decoder" is the one that decompress the video file and outputs raw video data, and "video renderer" is the component that takes that raw video data and display it on screen (possibly converting the formats in between).
Together they form a hardware accelerated video playback pipeline that can play 1080p video effortlessly with less than 10% CPU usage. As a comparison, even the quad-core i.MX6Q cannot play 1080p video smoothly using only its ARM cores alone.
There are just a few hiccups. The plugins apparently can't rotate the playback when you launch it using gst-launch (e.g see here - although if you use the gplay tool it would work), and if you try to use the plugin to play video on a rotated display (rotated using xrandr etc), then video playback gets totally wrong. This is mainly because certain parts of plugin follows X coordinate orientation, while other parts of it are stuck with real CRTC coordinates (that is, they aren't rotated).
I've done some fixes on that and the gstreamer plugins can now play video in any orientation (even from gst-launch) as well as in any display orientation. As a bonus, I have the code that makes video playback rotated following the display rotation automatically. Of course, because the final rendering is done by IPU, this is only possible if the size of the video output is not more than 1024x1024 pixels - this is an IPU limitation which isn't easily bypassed.
Combined with this: gstreamer npapi plugin, one can make an alternative video player plugin that provides accelerated video playback (compared to xine-plugin or vlc-plugin, for example); and when built with the "fixed" version, the video will play correctly on any display orientation. I know that, I've built one myself. It runs nicely on FatdogArm :)
Comments - Edit - Delete
FatdogArm on Cubox-i - update
FatdogArm now runs with Cubox-i i2w and i4p; supporting all features of FatdogArm plus i.MX6-specific hardware acceleration (vivante video driver, VPU, gstreamer, ALSA hardware resampler). Cubox-i is the *the only* ARM platform I have where you xrandr works correctly and you can change resolution on the fly. Kudos to Freescale to make this happen.On the other hand, the only thing currently not working on Cubox-i is the GPU (OpenGLES stuff). I have an open thread in the forum here: http://www.solid-run.com/community/post9713.html#p9713. All my other ARM platforms have their GPUs running, this is the only platform which it isn't (you've got Xorg hard lockups when trying to run any OpenGLES programs with GPU acceleration).
Comments - Edit - Delete
FatdogArm on Cubox-i
As part of an on-going project that I'm doing with someone, I have received Cubox-i devices and is currently porting FatdogArm to them. It is still early days, but I've got FatdogArm running on Cubox-i i4p.Comments - Edit - Delete
FatdogArm Beta1 kernel packages re-uploaded
If you have downloaded FatdogArm Beta1 recently, please re-download the kernel packages again. The ones I uploaded before have one leftover settings from my development that I forgot to turn off: they have SSH server enabled by default. You can easily turn them off using the Control Panel --> Services Manager, or justchmod -x /etc/init.d/S50dropbear
but it is a hassle.
The newly-uploaded kernel packages have SSH disabled by default.
Note: I have just re-uploaded the kernel packages, and it usually takes about 24 hours for the mirrors to sync. So either hit ibiblio.org directly or wait 24 hours from this post before hitting your favorite mirror.
Comments - Edit - Delete
FatdogArm Beta1 is released.
After being in the cooker for over two months, I can happily announced the next release of FatdogArm: the Beta1 release.Get it from ibiblio.org as usual, or from one of ibiblio's popular mirrors: nluug.nl and uoc.gr if you're in Europe, or aarnet.edu if you are in Australia. Many thanks for ibiblio and the mirrors for providing this public service.
Read the release notes first; and if you are new to FatdogArm, please also read the INSTALL instructions. Unlike many of Linux ARM distributions out there, FatdogArm is *not* distributed as images.
Forum announcement here.
FatdogArm Beta1 is the second-generation of FatdogArm; despite its name it is *not* a continuation of Alpha: it is in fact a full-rebuild using LFS 7.4 as the base (I would like to claim "the latest LFS" but LFS 7.5 had just been released as I was gearing for release, oh well) with glibc 2.18 and gcc 4.8.1 but otherwise with many of the packages remain identical with its Alpha counterpart (updates are only done for stability reasons).
The major goal of Beta is a change of hardware platform (from VFPv3-d32 to VFPv3-d16 *without* NEON) to enable it to run on larger class of hardware; as well as a fully-reproducible build system. As a bonus, Beta1 also supports 3D GPU acceleration for all supported platforms, which are: Odroid-U2, Odroid-U3, A10/Mele A1000, A20/Cubieboard2, OLPC XO-1.75 and OLPC XO-4.
Just like Alpha4, Beta1 also ships as a "meta-distribution" (now conveniently provided as a tarball instead of fossil repository) that enables you to build your own customised version as you see fit: headless console-only version; etc. All the kernel sources are provided (kernels were cross-compiled using Linaro cross-toolchain)) so you can also also build new modules etc if you need.
Special thanks to mavrothal and 01micko for OLPC XO support and testing.
Enjoy.
Comments - Edit - Delete
Gearing for FatdogArm Beta1 release
In preparation for FatdogArm Beta1 release, I have removed Alpha3 images and binaries from ibiblio to make some space. Alpha4 will remain for the moment, I will probably remove them when Beta is considered "stable" enough.I have also updated the article about how to run FatdogArm in Qemu (and the example shell script) for use with Alpha4 onwards (which no longer ships as images) - the instruction will also be useful for Beta1 when it is released.
Comments - Edit - Delete
3D hardware acceleration on FatdogArm Beta
FatdogArm beta hits another milestone today: I've got 3D hardware acceleration running on Mele/Cubieboard2 and Odroid-U2. As it happens all of them use the Mali GPU variants.It's quite cool to watch es2gears and glmark2-es2 running on all these boards.
As a reference, here are their glmark2-es2 scores:
Mele A1000 (A10) - 53
Cubieboard2 (A20) - 63
Odroid-U2 (Exynos4412) - 123
Remember that FatdogArm Beta is built with VFPv3-d16 (just like Debian armhf) and no NEON.
The 3D acceleration on all these uses the same Xorg driver (fbturbo) and the appropriate version of Mali blobs, all coming from sunxi-mali (from linux-sunxi repository).
All of this is made possible by the hard work of linux-sunxi folks; especially Siarhei Siamashka (ssvb) who maintains xf86-video-fbturbo (formerly xf86-video-sunxi), Luc Verhaegen (libv) who maintains the sunxi-mali repo (Luc is also the man behind the Lima open-source Mali driver effort), and Dmitriy Beykun (rzk) who ported version 20 of Mali kernel interface from upstream to Odroid kernel.
Thanks guys!
Note: I managed to get 3D acceleration done (but not tested) on XOs much earlier last year (with dovefb/libgfx-marvell); but in FatdogArm beta it will ship disabled by default as enabling it will corrupt the display on some circumstances.
Comments - Edit - Delete
FatdogArm Beta reaches parity with Alpha4 today
As the title says. The (unreleased) Beta version of FatdogArm reaches functional parity with Alpha4 today. All that is needed to be done now is testing on all the supported platforms; then we should be good for release.Comments - Edit - Delete
FatdogArm Alpha4 for Odroid-U2 - fixed
I had a major fumble. My instructions and the FatdogArm kernel package for U2 didn't work. The reasons are double whammy:1. I built the latest u-boot, but that latest u-boot doesn't work on U2.
2. I gave the wrong instructions for installing the boot loader.
Both have been fixed now - I have updated the U2 kernel package with the latest working u-boot version (commit 286a81158f01dcb08e16d77790c21fd2a40afc6c) and I have also updated the boot-loader installation instructions: basically, do not use bs=1024 for U2.
Thanks for Mick who directed me to this conclusion. He also more or less confirms that Alpha4 works on U3 too (sort of - he's still testing it).
Comments - Edit - Delete