QtAV Revisited

Ok, so having a bit of free time to pursue QtAV on cubieboard and following the lead developer's pointers on the previous post, I managed to capture some footage of the results I got so far.

First and foremost, some technical data:

• using my Cubieboard A20 for this test
• running Cubian X Desktop, stock version (no modifications done to either script.bin, kernel, X...)
• natively compiled Qt 5.1.0 for the device
• included all the pre-compiled dependencies supplied by Wang:
• cedarv dev files
• ffmpeg armhf
• QtAV 1.4.1 from Wang's github project:
• https://github.com/wang-bin/QtAV.git > master branch > commit fade1e4669c42373a3b70c2b1a3a7cb89c29bc71

The first run was using the ffmpeg decoder, the second run was using cedarv (failed) and the third run also with cedar succeeded, but the results were pretty much on par with the existing problems with cedar decoding on A10/A20.

If you notice something missing or if you've had proper success beyond this point, please don't hesitate in posting below and sharing your setup with everyone else!

QtAV

Hi,

I've been working on other projects recently, but while browsing around for all things video accelerated, I came accross QtAV.

QtAV seems to be what was missing in order to integrate Qt and hardware video acceleration on Cubieboard!

I haven't tested yet, don't know if it supports the libcedarx proprietary blobs and/or libvdpau-sunxi but if the youtube videos are anything to go on, it looks pretty promising...!

If you didn't know about it, here's the Github Project page, and if you have, add a comment below with your experiences with it!

... Would it be worth it for Qt5Box's next release?

Gstreamer Hyperloop

So I've been trying to get Gstreamer and Qt to play nice with each other on Cubieboard, but so far, no go.

Distinct attempts so far have been as follows:

1. Hacking QtMultimedia to specifically invoke the working vdpausink pipeline
1. this seems to be handled by  qtmultimedia/src/plugins/gstreamer/mediaplayer/qgstreamerplayersession.cpp on the Qt5 sources, on the VM host.
2. Setting the default playbin2 pipeline on GStreamer to use the vdpau elements, with GST_RANK_PRIMARY + 1
1. this seems to be handled by gst-plugins-bad-0.10.23/sys/vdpau/gstvdpau.c in the embedded rootfs (check the previous Gstreamer + libvpau-sunxi post)

Scenario #1 got me all the way to invoking VDPAU to a black screen from Qt and scenario #2 won't go all the way even from gst-launch on account of qtdemux:

playsink gstplaysink.c:2922:is_raw_pad:<playsink0:video_sink> Caps contains raw and non-raw structures:

video/x-vdpau-video, chroma-type=(int)0, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ];
video/x-raw-yuv, format=(fourcc)I420, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ];
video/x-raw-yuv, format=(fourcc)YV12, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ];
video/x-raw-yuv, format=(fourcc)NV12, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ]

A third possibility is to go with qtgstreamer, an alternative to QtMultimedia - still working that angle as well!

Qt5Box 0.3 - some issues

Just a quick update on v0.3:

I just noticed that the Cubieboard A10 SD Card images haven't been updated for the misconfigurations reported on the previous README:

• Setting proper permissions on /opt (both framebuffer and X11)
• Changing the automatic login user on /etc/slim.conf from "wickwire" to "cubie" (X11)

These fixes have been corrected on 0.3, towards 0.4 with hopefully I'll launch with Qt 5.4.x when it comes out.

I'll also attempt to include libvdpau+GStreamer on A10 X11 and Cubietruck X11, if I can!

Qt5Box 0.3 - "Isaac"

Finally, Qt5Box 0.3 is out! 

This release includes a Jenkins CI setup, which I've been using to perform automated Qt5 cross-compile jobs, as well as accelerated GStreamer support using libvdpau-sunxi (only available on X11, and specifically to Qt5Box, only on the Cubieboard A20 X11 SD Card Image).

I didn't have time yet to reproduce the steps on Cubieboard A10 and Cubietruck, but basically everything's documented here in the blog, in previous posts.

Using Jenkins, I've been able to successfully include about 60 variations on Qt5, from all stable releases beginning on 5.0.0 all the way up to 5.3.2, for each Cubieboard device, and both X11 and Framebuffer.

Hopefully with Jenkins I'll be able to roll out the next Qt5Box versions faster - Qt 5.4 is just around the corner and there's always the possibility of including more devices than just the Cubieboard family!

Last but not least, a special thank you to Isaac Chavarria a.k.a. Ikeeki for lending me his working Cubieboard A10, which was vital to get things going for this release...!

Cubieboard: GStreamer 0.10 + libvdpau-sunxi

It's been a while since I've posted in the blog, but while I'm still to release any new versions of Qt5Box, there's still some exploring to be done with hardware accelerated video on Cubieboard.

Using X11 and libvdpau-sunxi, it's possible to have hardware accelerated video on Cubieboard, and confirm it with mplayer - just check the sunxi wiki steps for that.

But what about GStreamer? Read on...

Step 1: libvdpau-sunxi and mplayer

- based on Cubian images for Cubieboard
- add sunxi_cedar_mod to /etc/modules

sudo apt-get install libvdpau-dev vdpauinfo libvdpau-sunxi

http://linux-sunxi.org/Cedrus

- set permissions in udev rules
- reserve memory for the VPU
- add VDPAU_DRIVER=sunxi to /etc/environment

sudo apt-get install mplayer2

wget sintel mp4 trailers

DISPLAY=:0 mplayer -ao alsa:device=hw=1.0 -vo vdpau -vc ffmpeg12vdpau,ffh264vdpau, sintel_trailer-480p.mp4

(at this point, 480p, 720p, 1080p should work properly with mplayer)

Step 2: libvdpau-sunxi and GStreamer

sudo apt-get install libasound2-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libgstreamer-plugins-bad0.10* gstreamer0.10-plugins-ugly gstreamer0.10-alsa gstreamer0.10-plugins-good gstreamer0.10-tools gtk-doc-tools

DISPLAY=:0 gst-launch-0.10 playbin2 uri=file:///home/cubie/sintel_trailer-480p.mp4 video-sink="autovideosink" audio-sink="faad ! audioconvert ! alsasink device=hw:1,0"

(no vdpau yet - video is distorted, audio is working over HDMI)

sudo apt-get autoremove
sudo apt-get install faad libfaad-dev libfaad2
sudo apt-get clean

wget http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-0.10.23.tar.xz

./autogen.sh && make -j 3 && sudo make install

sudo ln -s /usr/local/lib/gstreamer-0.10/libgstvdpau.so /usr/lib/arm-linux-gnueabihf/gstreamer-0.10/
sudo ln -s /usr/local/lib/libgstvdp-0.10.so.23 /usr/lib/libgstvdp-0.10.so.23
sudo ln -s /usr/local/lib/libgstvdp-0.10.so.23.0.0 /usr/lib/libgstvdp-0.10.so.23.0.0

rm -rf ~/.gstreamer-0.10/ && gst-inspect-0.10 | grep vdpau

vdpau:  vdpausink: VDPAU Sink
vdpau:  vdpauvideopostprocess: VdpauVideoPostProcess
vdpau:  vdpaumpeg4dec: VDPAU Mpeg4 Decoder
vdpau:  vdpauh264dec: VDPAU H264 Decoder
vdpau:  vdpaumpegdec: VDPAU Mpeg Decoder

DISPLAY=:0 gst-launch-0.10 playbin2 uri=file:///home/cubie/sintel_trailer-480p.mp4 video-sink="vdpauh264dec ! vdpauvideopostprocess ! vdpausink" audio-sink="faad ! audioconvert ! alsasink device=hw:1,0"

Failed to open VDPAU backend libvdpau_sunxi.so: cannot open shared object file: No such file or directory

sudo ln -s /usr/lib/arm-linux-gnueabihf/vdpau/libvdpau_sunxi.so.1 /usr/lib/libvdpau_sunxi.so

Failed to open VDPAU backend /usr/lib/libvdpau_sunxi.so: undefined symbol: XTranslateCoordinates

(the mplayer line works OK with vdpau video support and alsa audio through HDMI)

sudo apt-get purge libvdpau-sunxi

(leave libvdpau-dev installed)

git clone https://github.com/linux-sunxi/libvdpau-sunxi.git

cd libvdpau-sunxi
make
sudo make install

(mplayer and GStreamer working now)

reboot

- mplayer cmdline working
- gstreamer cmdline working

Qt5Box v0.3 in the works

Having Qt5 marry GStreamer along with GStreamer acceleration for embedded is still to be, although from previous posts, both platforms are working decently enough on Cubieboard.

That said, Qt5Box v0.2 is all about Qt5 alone - no QtMultimedia, QtWebkit - and in even though QtMultimedia currently doesn't seem to support video acceleration (and with QML as well), it still manages to get something done if the video is SD.

Maybe there are some applications at present, concerning SD Webcams or SD video playback - that would be accessible.

So Qt5Box v0.3 will at least have (hopefully) GStreamer integration which is pretty straight-forward, and as for Webkit, still considering if that's an advantage as well!

Qt5Box v0.2 - Cubieboard A10 Fixes

Ok, so my cubieboard A10 model is severely crippled when it comes to video output, but I went ahead and tried to build Cubie A10 targets in Qt5Box.

Recently though, a member of the community reached out and decided to donate his cubieboard A10 to the project - and a big, big thank you goes out to him for his gesture.

Isaac Chavarria, a.k.a. ikeeki has been doing some outstanding work in the Cubieboard community and you're welcome to follow up on his work with Cubiuntu.

That said, I went on to test Qt5Box with Cubieboard A10. If you own one of these and wish to take Qt5Box v0.2 for a spin, then take these notes with you:

cb1-rootfs a.k.a. Cubieboard A10 Framebuffer:

- /opt needed write permissions for app deployment

after booting your cubieboard from the supplied SD Card image, change permissions to /opt like so:

# chmod -R a+rwx /opt/

that way, Qt Creator will be able to deploy the app files to your cubieboard.



cb1-rootfs-x11 a.k.a. Cubieboard A10 X11:
- /opt needed write permissions for app deployment (same as above)

- updated /etc/slim.conf with the correct user for auto-login
(having the wrong user set up would prevent slim from starting up properly and as a result of that, no Desktop)

Edit /etc/slim.conf and update the following line:

default_user        cubie

... and this is it for Cubieboard A10.


Of course, these fixes should be included in the next version of Qt5Box, once it's out!

Qt5Box v0.2 is out!

Just finished uploading Qt5Box v0.2 to my Box.com account.

- This new version includes support for all the Cubieboard devices - A10, A20, Cubietruck
- Changed the default Ubuntu environment to gnome-classic without effects, in order to save on resources and usability
- Qt Creator is already included and pre-configured as usual, Qt 5.3.0 is already pre-compiled as well

For access to the files, you can either PM me in the Cubieforums or through here and supply a valid email address, to be granted access on the Box.com account.

The Virtualbox OVA file is about 16GB in size and once imported to Virtualbox, the VM will eat away at least 100GB of HDD.

More details in the README.1st doc, as usual.

Coding Chase - Projects

oneSSHot

Qt5Box

Cubieboard - Qt 5.3.0 [X11]

After building Qt 5.3.0 for Cubieboard A20 on Framebuffer, I went ahead with another build for X11. I wasn't expecting much hassle, but in the end, some "dirty hacks" were required to be able to cross-compile it, using the same steps and configure lines as with Qt 5.2.1.

As far as I could tell and also from what I gathered on IRC, the wows I got aren't so much Qt's responsability, but rather the Mali library headers for EGL, GLES, etc that may need updating.

In any case, getting past those hurdles and getting QtCinematicExperience to work required these modifications:

qtbase/src/gui/kernel/qplatformcursor.h

#include <QtGui/QCursor>

#   ifdef CursorShape
#       define X_CursorShape CursorShape
#       undef CursorShape
#   endif

QT_BEGIN_NAMESPACE


qtbase/src/platformsupport/eglconvenience/qeglplatformcursor.cpp


#include "qeglplatformintegration_p.h"

#   ifdef CursorShape
#       define X_CursorShape CursorShape
#       undef CursorShape
#   endif

QT_BEGIN_NAMESPACE


qtbase/src/platformsupport/eglconvenience/qeglplatformcontext.cpp

#include <QtCore/qtextstream.h>
#include "qeglplatformcontext_p.h"

Cubieboard, Qt 5 on Framebuffer and VSync

My personal goals with Qt 5 and Cubieboard have always been to try to get the most bang for my buck.

On cubieboard A20/cubietruck, using r3p2-01rel02 Mali libraries and some tweaking in the fex script it's actually possible to make use of all the power in the GPU and see the FPS go up.

On framebuffer though, going on 80+ FPS and above, it becomes noticeable that some animations display a sort of tearing effect: the vertical refresh rate of the screens is unable to keep up with the actual frame rate and the end result isn't that clean.

Following up on that same issue,which was posted on the cubieforums thread a while back, I managed to find the time to test one solution that popped up - a disabled function inside the framebuffer files in the sunxi kernel.

Enabling the function and re-compiling the kernel did the trick and I think it actually solved the issue.

While waiting to hear back from the user who reported the issue, I posted a couple of videos on youtube hoping to be able to demonstrate the issue (the sun orb going around), and the apparent solution:

Cubieboard A20 - Qt 5.3.0 - FB without vsync

Cubieboard A20 - Qt 5.3.0 - FB with vsync

Qt 5.3.0 + Qt5 Cinematic Experience

After having Qt 5.3.0 running on my Cubieboard A20, I decided to run the usual Qt Cinematic Experience app from QuitCoding.

I got the Qt5_CinematicExperience_rpi_1.0.tgz version, same as usual, and while expecting to get the action, I got this instead:


Qt5_CinematicExperience.qml:26:5: Type MainView unavailable 
         MainView { 
         ^
/content/MainView.qml:241:9: Type SettingsView unavailable 
             SettingsView { 
             ^
/content/SettingsView.qml:88:13: Type Switch unavailable 
                 Switch { 
                 ^
/content/Switch.qml:9:21: Cannot assign a value to a signal (expecting a script to be run) 
         property string onText: "On" 

                         ^


This issue showed up on both systems - my laptop and cubieboard, and while not entirely sure why that was, the solution came out of editing Switch.qml and SettingsView.qml and doing the following replacements:

onText > textON
offText > textOFF

... and Cinematic Experience runs once more on both platforms! :)

Qt 5.3.0 and Cubieboard

Qt 5.3.0 came out a few days ago, so I set some time aside to test it out on Cubieboard, like I had done with previous versions.

The cross-compilation works just the same, I've only tested the framebuffer procedure on Cubieboard A20 but basically it all cross-compiled and installed fine.

From the beginning, I've been interested in being able to build the sdcard image system from scratch, using the sunxi-bsp, linaro rootfs, the mali libraries, and finally the cross-compiled Qt libraries on top of it all.

This time around I decided to cut some corners and simplify the base image generation process. Considering that there's an "official" distribution out there - Cubian, I decided to save myself some time and use that.

Going through Cubian's resources, I grabbed the Cubian-base-r5-a20.img.

Cubian images are still supporting Mali r3p0, so I headed over to ssvb's materials on github and cloned his most recent sunxi kernel branch

git clone -b 20140116-mali-r3p2-01rel2 https://github.com/ssvb/linux-sunxi.git

From these sources, I used git to extract the specific commit where ssvb introduced support for r3p2-01rel2

git format-patch -1 5bf12905ff1faa38af4c47ff0752d3f5f12f5644

This commit changes a few files and adds a new directory in the kernel sources, targeted at r3p2-01rel2.

I cleaned the resulting patch a little, taking out the changes to the files in that new directory - which isn't present in Cubian kernel sources at this time, so might as well take them out, and just copy the whole dir into the Cubian kernel sources.

I got the Cubian kernel sources, applied my modified patch and copied over the additional r3p2-01rel2 directory - and then set out to cross-compile it, including modules.

Once that was done, the next step was to copy the uImage and modules binaries over to the Cubian-base-r5-a20 SD Card.

Booting up the system, I confirmed I now had a Cubian CLI image, for cubieboard A20, supporting r3p2-01rel2.

I moved on to installing the r3p2-01rel2 Mali userspace libraries as usual and then cross-compiling Qt 5.3.0 as usual.

Note: while cross-compiling the kernel was done with the Cubian recommended toolchain (code sourcery), cross-compiling Qt was still done using the Linaro toolchain - it's possible that cubian's also works, however there's a relevant step before running Qt's configure - fixLibraryPaths - and this step seems to work best with the Linaro toolchain.

I've uploaded the patches to my box.com account, hopefully I'll have the time soon to publish an image on the cubieforums account.

Qt 5.x for Cubieboard - A10/A20 general notions

At the moment, I'm without a working A10 Cubieboard, so the work I keep publishing is mostly A20 oriented.

But if you own an A10, there's absolutely no reason for you not to play around with Qt 5 on it.

On A20, in order to take full advantage of the Mali GPU, the r3p2-01rel2 Mali libraries or above are needed. But this usually requires adding some patches to the kernel, prior to everything else.

On A10, the optimizations aren't so meaningful, which means you can skip this kernel hacking step and just use a stock image, which will support r3p0 Mali.

So for the A10 SoC, you may as well follow these simpler steps:

1- decide whether you want to have Qt with or without X

2- get Cubian for A10

3- install the Mali libraries - r3p0 - and confirm that you get the colored test triangle

Natively compiling Qt5:

If you decide to natively compile Qt5, stop here and follow this sunxi guide (use whichever new stable release is available instead of the stated 5.1.1 version, adapt in case you're going for framebuffer instead of X11).

Cross-compiling Qt5:

4- make an image file out of the SD Card and move on to your development host machine

5- if you have a 64bit OS, make sure it's ready to deal with 32bit libraries/binaries

6- grab a working toolchain - I've been using Linaro GCC but the recommended toolchain for Cubian is also a possibility

7- grab the latest stable Qt5 sources (this link is for 5.3, linux sources. Adjust to your host OS)

8- cross-compile Qt5 using these instructions, from step 4 onwards - just use the patches if needed, the device mkspec files for cubieboard and the configure line.

Qt 5.2.1 pre-made images - revisited

Recently, a cubieforums user commented on the Qt5 thread with issues regarding Qt Creator configurations, when adding the pre-compiled Qt 5.2.1 environment, specifically, when attempting to use the Linaro ARM gcc binaries.

I took some time to verify the issue and post a step-by-step quick guide, receiving positive feedback from the user in question - and as such, I thought it might also have a place here in the blog.

To recap, I built the environment using an 64bit host system, while the Cubieboard environment itself works with a 32bit instructions set.

If, instead of going through the hard road of cross-compiling the Qt source code on your own environment, you've attempted to use my development suite for rapid deployment and faced this - or other problems, below is a step-by-step Quick Guide for setting up the pre-compiled Qt 5.2.1 environment available for download at cubieforums.

The base will be a Virtualbox Virtual Machine which will house the development environment with Qt Creator, the cross-compiled Qt 5.2.1 binaries and overall, a clean solution for you to start coding in Qt and deploying your creations to Cubieboard, rather than spend any more time getting to this point.

------------------------- Quick Guide -------------------------

Step #1 : Virtualbox > Ubuntu 14.04 LTS Desktop Clean Install

Step #2 : switched to the Documents dir

wickwire@qt5box:~/Documents$

Step #3 : grabbed the linaro arm gcc

wickwire@qt5box:~/Documents$ wget http://releases.linaro.org/13.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2

Step #4 : decompressed the archive

wickwire@qt5box:~/Documents$ tar xvjpf gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2

Step #5 : descended to the bin dir

wickwire@qt5box:~/Documents$ cd gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/

Step #6 : executed the arm-gcc binary and confirmed the problem

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ ./arm-linux-gnueabihf-g++

-bash: ./arm-linux-gnueabihf-g++: No such file or directory

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ 

Step #7 : updated apt-get

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ sudo apt-get update

Step #8 : searched for ia32-libs - 32bit support under x64

wickwire@qt5box:~/Documents$ sudo apt-get install ia32-libs

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Package ia32-libs is not available, but is referred to by another package.

This may mean that the package is missing, has been obsoleted, or

is only available from another source

However the following packages replace it:

  lib32z1 lib32ncurses5 lib32bz2-1.0

E: Package 'ia32-libs' has no installation candidate

Step #9 : installed the suggested replacement packages

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0

Step #10 : executed the arm gcc binary again

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ ./arm-linux-gnueabihf-g++

./arm-linux-gnueabihf-g++: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$

Step #11 : installed the missing libstdc package, 32bit version 

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ sudo apt-get install libstdc++6:i386

Step #12 : executed the arm gcc binary - success!

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$ ./arm-linux-gnueabihf-g++ -v

Using built-in specs.

COLLECT_GCC=./arm-linux-gnueabihf-g++

COLLECT_LTO_WRAPPER=/home/wickwire/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.2/lto-wrapper

Target: arm-linux-gnueabihf

Configured with: /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/gcc-linaro-4.8-2013.09/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install --with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --enable-multilib --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2013.09 - Linaro GCC 2013.09' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-gold --with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long --with-mode=thumb

Thread model: posix

gcc version 4.8.2 20130902 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.09 - Linaro GCC 2013.09) 

wickwire@qt5box:~/Documents/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin$

------------------------- Quick Guide -------------------------

From this point on, you should only have to

- decompress the qt5cb2fb or qt5cb2x11 tar.bz2 archives to /usr/local/ on the VM OS

- and then run

/usr/local/qt5cb2fb/bin/qmake -v

to obtain the expected Qt 5.2.1 pre-compiled libraries path:

QMake version 3.0

Using Qt version 5.2.1 in /opt/qt5.cubieboard2.workbench/cubie-rootfs/usr/local/qt5cb2fb/lib

From here, you'll need to mount the downloaded SD Card image to /opt/qt5.cubieboard2.workbench/cubie-rootfs so that qmake is able to find the corresponding cross-compiled Qt 5.2.1 libraries, on the VM OS.

This same image should be written to an available microSD card and loaded onto your Cubieboard device - so as to have two identical systems, the native one running on Cubieboard and the VM installed one, which will be used to cross-compile your future Qt5 Apps.

Set up Qt Creator by adding the Linaro GCC binary + the qmake binary + the remote ssh access to your Cubieboard and that should be all!

QtZumoTruck

Going through some of the stuff in the office study, I came up with an idea - how about a remotely controlled vehicle - yet another one - but with Qt 5.2.1 in the mix?

Maybe not the simplest setup, but certainly a great one for learning/testing.
I got hold of an Arduino Uno R3 that was lying around, slapped a Zumo robot on it and connected it to a Cubietruck.

What came out of this got named QtZumoTruck and it has been quite the entertainment around here!

Ok so I'm not the handiest guy around when it comes to shortening usb cables, but it worked and it lightened the load - although to be honest, the little Zumo packs quite a punch and was able to handle the weight of the all the components previous to being stripped down!

As stated, the Zumo has its own Arduino libraries to handle the two microgear motors, I just added serial port communications to it by following this blog.

And then, on to Cubietruck. Cubietruck is quite awesome, in the sense that it already has built-in battery management - it recharges the battery while on power socket and commutes between power sources without affecting the running OS.

I got the battery off of an old HTC Tattoo smartphone and soldered a couple of wires to be able to connect it to the Cubietruck.

Reading the battery state is also possible under /sysfs, which comes in handy to measure remaining battery.

I installed Cubian (server version) on a microSD card, set up the WiFi for the onboard chipset and also mjpeg-streamer to stream live video over a connected Logitech C160 USB webcam, based off of the sunxi wiki.

Once the Arduino got connected to one of the USB ports on the Cubietruck, the /dev/ttyACM0 device was created and I was in business!
I used minicom on Cubietruck, over ssh, to test interaction with Zumo.

Having WiFi and video streaming on Cubietruck and having Zumo accept serial port commands to control the motors, what was left was to combine the two in an attempt to remotely control the little car over IP.

Possibly not the most immediate choice of framework, but I obviously went with Qt.

Qt 5.2.1 includes QtSerialPort which is specifically oriented at serial port communication. Working with the terminal example, I added QtTCPSocket and made Cubietruck act as a TCP Socket-to-Serial gateway.

So with Cubietruck controlling Zumo over serial port and receiving the commands over TCP socket, I made a simple TCP socket client and that's it!

From old Socket-to-GPIO code I had, I tweaked both Server and Client to work with Serial and fit with the Zumo's needs.

When the Client has focus on the Desktop, using the arrow keys sends messages over the TCP socket to the Server.
The Server picks up the message in question and sends the equivalent command over serial port to Zumo, which in turn handles the motors.

Since the serial port code is sequential, to avoid having to press forward and then stop to halt and change command, I used Qt's events to:

- send a forward command on up arrow key press event
- send a full stop command on any arrow key release event

... and so on for the remaining directions.

There is still a lot of polishing code-wise, but onwards with the first run!

WiFi signal was pretty decent although I did get a few break ups in video reception when getting far away from the access point, located inside.

The video feed was at 640x480 resolution and between 25 and 30fps, which is pretty good - and the whole system feels quite responsive!

And in the end, the whole solution from TCP to Serial uses a graphical framework, without caring much for... graphics.

Yes, Qt is that impressive.

Sapo Codebits 2014

A couple of weeks back, Sapo Codebits VII happened.

I had never been, but a friend - and veteran of sorts in these matters - convinced me into going.

... and boy, did it pay off. The event was awesome, the talks, the workshops - even squeezing in some time to do a simple notifications bot with nodeJS and Raspberry Pi, just for kicks!

The venue, the spirit, the drive... if you're anything like me and you're reading this, you have to check it out!

Hopefully next year they'll be back, and so will I...! :)

Cubieboard A20: GStreamer VDPAU

So following my previous post, I started messing around with GStreamer and VDPAU.

GStreamer includes VDPAU support in the gst-plugins-bad package, on the 0.10 branch.

Since I've been using Linaro Ubuntu as the OS for my experiments with Qt5, I sticked with it for GStreamer as well and soon found out that VDPAU support was nowhere to be found.

So, back to basics - I uninstalled the plugins-bad package provided by Linaro Ubuntu and picked up the sources for it. After some tweaking and fiddling, I got it to natively compile on my Cubieboard A20 - and not long after that, I had:

linaro@linaro-alip:~$ gst-inspect-0.10 | grep vdpau

vdpau:  vdpaumpegdec: VDPAU Mpeg Decoder

vdpau:  vdpauh264dec: VDPAU H264 Decoder

vdpau:  vdpaumpeg4dec: VDPAU Mpeg4 Decoder

vdpau:  vdpauvideopostprocess: VdpauVideoPostProcess

vdpau:  vdpausink: VDPAU Sink

 

... but things didn't turn out that great - I stumbled on the following error:

Failed to open VDPAU backend /usr/lib/arm-linux-gnueabihf/libvdpau_sunxi.so: undefined symbol: XTranslateCoordinates

 

So after asking for help on #linux-sunxi at freenode, the clever folks there got me past it and here's the result :)

Qt 5.2.1 + GStreamer - HW Acceleration

Yesterday, a user posted his work with Cubieboard, Qt 5 and GStreamer on the Forum Thread. While it is unclear if this was achieved with A10 or A20 (the dealxtreme package that was referred to doesn't clarify if it's an A10 or an A20 board) I decided to take my recent build for a spin and see if the GStreamer performance was in any way similar/better/worse than what was presented.

Having said that, I published a video on my youtube channel comparing video playback for both the video used by semlanik (DiVX) and another Big Buck Bunny sample, using h264 - using my setup.

As stated, on my side this was all done using Qt 5.2.1 and stock GStreamer 0.10, integrated with QtMultimedia, from the work done last month - not much effort there, QtMultimedia/GStreamer integration is pretty straight-forward, no optimizations done to GStreamer as I haven't yet started working on those.

The DiVX video is playing normally and with graphical effects on top - I used the included qmlvideofx sample app, cross-compiled from Qt Creator on my laptop and remotely deployed over SSH to Cubieboard (A20).

When selecting the h264 video, problems arise. I've replied to semlanik in hope of confirming (or not) the current issues with h264 on his side as well, hopefully he'll reply soon.

Regarding GStreamer acceleration, one possibility would be to use the Cedrus project, integrate libvdpau-sunxi with GStreamer on Cubie (and quite possibly this would only work on an X11 environment, due to VDPAU requirements).

Another possibility would be to resort to libhybris.

For a quick run-down regarding accelerated video on Cubie, there's also this interesting wiki page.

Qt5 + GStreamer + Cubieboard [X11/FB]

New Development Sets available at the cubieforums repositories: (see June 2014 announcements)

- Cubieboard A20 only
- Qt 5.2.1 with GStreamer integration
- qt-declarative-camera example was cross-compiled and worked successfully, is present in both FB/X11 images for in the Cubieboard A20 sections

- I tested it with two usb webcam models:

Colour output: Logitech C160 Webcam

Black and White output: Hercules HD Twist Webcam


Only tested the Hercules Webcam on GStreamer and didn't fiddle much with it, will check it out with the declarative-camera example and see how that goes.

Qt5 on Embedded - USB Webcams

Well, so by now Qt5 graphics on Cubieboard devices are pretty much stable and displaying solid performance - so what now?

Last year I did some research on Qt5, GStreamer and Raspberry Pi. Back then, I was using a Raspberry Pi, an old USB Webcam, an IR Sensor and a bright white LED.

Some coding magic with QZXing and a short while later I had a nifty QRCode Decoding app, running on Raspberry Pi:

- the sensor would be triggered by placing a card against an acrylic plate
- the app would use the webcam to snap a picture
- the app would analyse the picture with QZXing and decode any existing QRCode within
- the decoded string would be passed on from the C++ layer worker thread, to the main event loop and the QML layer - to update a Text element.
- as an added bonus, I included the snapped picture on QML and I also added a LED later on to act as flash to ensure proper lighting when the picture was snapped.

I recently uploaded the code to my bitbucket account, back then I had to modify QXZing to work with Qt 5 since it was 4.7.

While this proof of concept worked, Qt was relying on an external command - streamer - using QProcess - and I always thought of going back and integrating the webcam in Qt, the proper way. Also, the Pi's CPU was getting some load with the whole thing.

Fast forward it to today and with cubieboard's performance, and even a conventional dual core SoC has the potential to improve the experience.

I've managed to produce new development environments for Cubieboard A20 (sd card images and cross-compiled qmake for the dev host) where Qt5, by the means of QtMultimedia, has GStreamer integration, these are being uploaded to the cubieforums hosting solution

While GStreamer on Cubie isn't (yet) hardware accelerated, for this specific case, it works - my old USB webcam works fine either on Framebuffer or X11, and since it supports MJPEG, I get 30 FPS @640x480 with medium/low CPU stress.

Hopefully I'll be able to update the QRDecoder example to include proper USB Webcam handling, rather than rely on streamer.

Later on I'll also try to integrate an NFC shield I never got to use - let's see how that one goes...!

Cubieforums Support

The folks at cubieforums.com were outstanding and I'm currently uploading the pre-made images there as well - more updates on this to be made on the community thread!

Check out the link > http://dl.cubieforums.com/ikeeki/IMAGES/ww/cubieboard/

• the linaro gcc archive can be found at official website
• the qt 5.2.1 sources archive can be found at the official website

These backups include the sd card images, the related dev host qmake files and the mkspecs/patches.

Box.com Bandwidth Cap

My Box.com monthly limit has been reached - so as an alternative, I've created slimmed down archives on my secondary box.com account:

https://app.box.com/qt5-cubieboard

If you're using a cubieboard 2 or a cubietruck, then by downloading the official cubian image for your device and copying over the binaries from the slimmed archives, you should be able to have the Qt5 Cinematic Experience running at full speed, as well as set things up for developing your own Qt5 apps.

READMEs are included and you can read more about it on the community thread:

http://www.cubieforums.com/index.php?topic=173.msg13330#msg13330

Cubietruck Qt 5.2.1 [X11]

And X11 is working too - still using Cubian as described in the previous post. Trying to figure out a lighter way to distribute the work, without depleting box.com resources.

Cubietruck Qt 5.2.1 [Framebuffer]

Currently uploading Cubian images to the box.com images account. I went with Cubian this time because my cubietruck didn't seem to work properly with ssvb's branch, even with usual patches for 2GB RAM, reduced memory clock, etc etc etc...

Cubietruck has the same SoC as Cubieboard 2, so as far as Qt5 cross-compilation is concerned, it is the same. The challenge this time, for me, was the added features on Cubietruck, such as built-in wifi and bluetooth.

Cubian git sources, currently at 3.4.79, only consider mali r3p0 - so I had to do some kernel merging to include the r3p2-01rel2 version in there.

But it worked, so in the end I got mali, ethernet, wifi and bluetooth going!

I had been able to cross-compile Qt5 for Cubietruck a while back, so that wasn't new - but back then I really didn't care much for the remaining hardware, which I ended up looking at this time around.

X11 version still to come, but for now, some rest is in order...!

Cubieboard Qt5 Files

The Box.com account got a lot of traffic added lately and the monthly cap was hit in no time. The sd card images are quite big and since most people (hopefully) will rather have the specific mkspecs and patches files, and do the work themselves, I've set up a second account with these essential files for building.

That way, those who wish to build stuff themselves will still have access to the necessary files, without having to wait for traffic cap resets.

Images URL: https://app.box.com/qt5-cubieboard-images

Mkspecs + patches URL: https://app.box.com/qt5-cubieboard

Cubieboard (A20) - X11 Q 5.2.1

New image set currently being uploaded to Box.com:

- The README file contains all the relevant information
- I had to make some adjustments to the linux-cubieboard2-g++ mkpecs files
- The cross-compilation ./configure line for this one is:

./configure -opengl es2 \
-device linux-cubieboard2-g++ \
-device-option CROSS_COMPILE=/opt/qt5.cubieboard2.workbench/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/arm-linux-gnueabihf- \
-sysroot /opt/qt5.cubieboard2.workbench/cubie-rootfs \
-opensource \
-confirm-license \
-optimized-qmake \
-release \
-make libs \
-prefix /usr/local/qt5cb2x11 \
-no-pch \
-nomake examples \
-nomake tests \
-no-eglfs \
-no-linuxfb \
-qt-xcb \
-v


So Cubieboard 2 seems all set, both framebuffer and X11 cross-compiled environments!

Cubieboard CPR

Taking a break from Qt5 on Cubieboard A20, I decided to recover an older A10 cubieboard I had around.

This A10 was one of the first units to come out, has gone to war and back and the HDMI port is broken. At a given time I used a breadboard for cubie A10 with VGA support but couldn't seem to find it anywhere, so I had to go in blind.

I decided to make this unit into a house server unit, it works perfectly connected to the USB port on one of the TP-Link routers and I thought about using it for controlling other network elements around here as well as run some scripts and such.

With the HDMI gone, I decided to make use of the NAND and save myself and SD Card, so I went ahead and started going at it with available NAND images.

My first attempt lead me to Cubian, the official distro - and everything was working fine until I noticed I might have to change some stuff in the kernel.

I decided to get back to the typical linaro rootfs + sunxi kernel approach and get the latest, so this sunxi wiki page had what I needed.

Generating a LiveSuit image was half the work,I used the latest linaro ubuntu saucy server rootfs with sunxi-bsp and in no time, I had the img file needed to flash the NAND.

Flashing the NAND wasn't without incidents though, as my Linux Mint host wouldn't install the awusb driver needed for the PC to detect cubie on OTG USB connect.

The LiveSuit zip file included a Chinese README pdf which didn't help much, as my Chinese isn't that great, but in the end I managed to build, install and load the driver, and flash cubie.

Once flashed, another hurdle: no out-of-the-box SSH access, and no HDMI either. SD Card time with Cubian, chroot into the NAND system and ssh installation - success.

And when all seemed OK, I noticed the available space on the running NAND system was really low - the whole system was running off of the NAND on a 600MB partition.

Resizing/reorganizing the NAND was in order but that did prove difficult, so as a mental note, below are the commands I used, after the system was already installed, to merge partitions and resize things, using Cubian from microSD.

root@Cubian:~# nand-part -f a10 /dev/nand 2048 "bootloader 131072" "env 4096" "rootfs 7841792"
root@Cubian:~# fsck -f /dev/nandc
root@Cubian:~# resize2fs /dev/nandc

Explanation on all of this is available at this blog post although in my case, somehow it didn't go so smoothly, hence the notes above...

In any case, at present the NAND only has two partitions - boot with about 64MB in size and root with the remaining, for a total of 4GB!

Cubieboard (A20) - FB Qt 5.2.1

Quick Update:

All files have been uploaded and checked for integrity.

https://app.box.com/qt5-cubieboard-images

Qt 5.2.1 on sunxi mali libraries r3p2-01rel1 (framebuffer) files are being uploaded to my Box.com account, there's a readme included to help set everything up.

It is possible that after a while of running the Cinematic Experience, the screen blanks out. Using a usb keyboard and pressing Space will recover it, but since that's not much of a solution, try the following:

- log in on cubie and as root, mount the boot partition
- create a uEnv.txt file and include the following line, only:

extraargs=console=tty0 consoleblank=0

- save the file and reboot. It should be enough to stop the screen from blanking.

Unfortunately this file didn't get included in the image, so for long term app execution, it might come in handy!

Follow up discussion in the community forum thread

Cubieboard Qt5 Resource Files

Ok, so with the help of the Cubieboard community, I've managed to my initial goal of having Qt5 running on Cubieboard (A10/A20) and Cubietruck.

The detailed guide on how to achieve this was posted before, there's the official community thread, so the next step is: generating environments so that everyone can test and code Qt5 apps and mainly, have some fun with it!

On this Box.com url you will (hopefully) find updated image sets which will include all the necessary pre-compiled files for you to start coding with Qt5 and running your apps on your Cubieboard, using the sunxi Mali libraries:

https://app.box.com/qt5-cubieboard-images

There's a README which hopefully will help you set everything up nicely, and right now I only have an older Qt 5.1.1 image set uploaded, but hopefully soon I'll be able to produce more image sets, so stay tuned!

Qt5 on Cubieboard (A10/A20)

Since last year, I've been working with the Cubieboard community in order to have Qt5 running on Cubie, using the sunxi mali libraries. I started off with Cubieboard A10, then moved on to Cubieboard 2 (A20) and finally Cubietruck (also A20).

My main goal was to be able to cross-compile Qt5 (because native compile takes forever on these embedded devices) and be able to control the entire process, from SD Card image generation to Qt5 App development.

Below is the complete guide to achieve this, it is quite extensive and I advise doing regular SD Card backups along the way:


Cubieboard (A20 Soc, should also work with A10)

Main objectives:

1) Produce a working SD Card image for cubieboard, supporting the latest Mali libraries from sunxi.
2) Cross-Compile Qt5 latest stable version using said libraries
3) Test performance using QuitCoding's Cinematic Experience Demo

Step 1, Building the STOCK SD Card Image

The Sunxi wiki supplies some steps on how to achieve this. You can always use a prebuilt image (cubian, cubiuntu, whatever) but my take on this is to have end-to-end control over the whole process.

This is the general guide to follow when wanting to build a custom image from scratch:

http://linux-sunxi.org/FirstSteps

This process can be quite cumbersome, so there is an alternative to this:

http://linux-sunxi.org/BSP

Using the Board Support Package alternative, generating the initial image is a lot easier. You'll just have to focus on three things:

1) the cross-compile gcc you'll be using
2) the rootfs you'll be using
3) an SD Card class 4 (but 10 would be better) 4GB or more (though 4GB would be ideal in my opinion)

So, use Linux as the dev host (I used Linux Mint x64) and install all the dependencies required in the guide.
Grab the gcc-linaro-arm-linux-gnueabihf-4.8-2013.09 gcc and make sure it's in your env PATH

Next up, clone the sunxi-bsp git repository and start working:

- use ./configure <board> to select your board (cubieboard2 for example)
- make

then to generate the SD Card, follow the guide:

./scripts/sunxi-media-create.sh [device] [hwpack] [rootfs]

[device] is the /dev/ device for the sd card (not the partitions)

[hwpack] is the reference hwpack that results from the make output

[rootfs] - for this one, I've used linaro rootfs:
either this one > linaro-precise-alip-20121124-519
or this newer one > linaro-raring-server-20130826-474

I've done some research for Qt5 on framebuffer mostly, so the server version (no X11) served me right, but choose whatever rocks your boat, considering your Qt5 needs later on.

Once that's done, you'll hopefully have a stock SD card image ready to work.

Things you can tweak at this level:

1) modify your script.bin file, to change output from HDMI to VGA, enable GPIO, etc.
2) modify the linux-sunxi stock kernel - enable functionalities, whatever you need.

After firing the SD Card on Cubie for the first time, you may want to set up a few things like ssh and fixed MAC Address so that you're able to assign static IPs over DHCP for example.

Once your stock card is ready, you may shutdown cubie and pop the card back on your linux host machine and to a sanity backup like so:

# dd bs=1M if=/dev/<card_device> of=/opt/sdcard.img;sync

Step 2, Building/Installing the Mali tweaked Kernel

SD card backup or not, mount the SD Card, specifically the root partition.

I'm not sure if but the time of this writing the stock 3.4 sunxi kernel already has the correct patches for the latest Mali libraries. I've followed ssvb's work on this and found best to just stick to his github repo and his kernels:

https://github.com/ssvb/linux-sunxi

Go for the mali branches and clone the latest:

https://github.com/ssvb/linux-sunxi/tree/20140116-mali-r3p2-01rel2

Once you have it, you'll be OK to build it manually, for the ARM arch on Cubie:

cd linux-sunxi
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sun7i_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j5 uImage modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=output modules_install

You'll obtain an output directory with firmware and modules - copy those directories to the /lib/firmware and /lib/modules dirs on the sd card, and also the uImage file (the newly compiled kernel) somewhere around arch/arm/boot....

Unmount the card, fire it up again on cubie, run uname -a and make sure it's using the ssvb's kernel.
(at this point it's up to you to shutdown and do another sd card backup or not)

Step 3, Install the Mali libraries

http://linux-sunxi.org/Binary_drivers

Set the proper permissions and work your way to install the binary drivers. From git, you get the framebuffer and also X11 binary blobs, install whichever suits your needs and your chosen sd card rootfs type (server/desktop)

Just after the git submodule update, when getting to the make install step, instead do:

# make config VERSION=r3p2-01rel1 ABI=armhf EGL_TYPE=framebuffer
# make
# make install

/* for X11 */

EGL_TYPE=x11

/* for X11 */

NOTE:

at make install:

../../../Makefile.split:4: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

If you get an error during make/make install about an incorrectly formed Makefile.split file, follow the message, edit the Makefile.split file and replace all 8 space indentations at the beginning of the lines, with 1 tab on each line.

Once the binary drivers are installed, there's a test example which you'll build and run. Getting a coloured triangle like in the video below will confirm that the libraries are working properly:

framebuffer > http://www.youtube.com/watch?v=45ry-PXneCU#t=125

sd card backup decision time!

Step 4, Cross-Compiling Qt5

Ok, so by now Qt5 is all we're missing.

This box.com link should set you up for this step. The Qt5 stable version in there is outdated, since then I've managed to successfully build version 5.2.0 as well, but you can go further.

- Grab the latest stable version from qt-project (by the time you read this, check if newer versions are available):

http://download.qt-project.org/archive/qt/5.2/5.2.1/single/qt-everywhere-opensource-src-5.2.1.tar.xz

Cross-compiling Qt5 will require some dependencies being installed to the env host, as well as the mounted sd card image.

Prepare the host:

sudo apt-get install ia32-libs (consider installing these if your host OS is x64)

update 2014-10-11:
On Ubuntu 14.04 x64 this package doesn't exist anymore, so consider doing the following steps:

sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 libstdc++6:i386


Next, prepare the sd card system (these are only needed if later on you'd like to also build QtWebkit. For that, Qt must be cross-compiled with these deps installed on the embedded OS)

sudo apt-get install flex bison gperf libicu-dev libxslt-dev ruby

Create an SD card image using dd on the cross compile host (I'm using Linux Mint) - check the paths!

dd bs=1M if=/dev/mmcblk0 of=/opt/qt5.cubieboard2A20.workbench/linaro.1211.ssvb.malifb.Qt511.QtWebkit.img;sync

Mount the SD Card image, just the OS partition (exclude the boot partition)
With linux you have "parted" to find the byte offset:
parted <sdcardimage>
> unit B
> p
this will show the partitions on the SD Card image, use the starting byte for the root partition, where de system lies
In my case:
mount -o loop,offset=68157440 /opt/qt5.cubieboard2A20.workbench/linaro.1211.ssvb.malifb.Qt511.QtWebkit.img /opt/qt5.cubieboard2A20.workbench/cubie2-rootfs/

git clone git://gitorious.org/cross-compile-tools/cross-compile-tools.git

Fix the library paths between the sd card image and the compiler - this should only have to be done once

./fixQualifiedLibraryPaths /opt/qt5.cubieboard2.workbench/cubie-rootfs /opt/qt5.cubieboard2/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/arm-linux-gnueabihf-g++

Uncompress the Qt5 archive as root and copy over the mkspec files for cubieboard:

cp -R linux-cubieboard2-g++ ./qt-everywhere-opensource-src-5.1.1/qtbase/mkspecs/devices/

(these mkspecs are based on the beagleboard files, included in the Qt5 sources)


/* For framebuffer */

(from the box.com archives)
cp -R qeglfshooks_stub.cpp ./qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/eglfs/qeglfshooks_stub.cpp


NOTE: on later Qt5 sources, the qeglfshooks_stub I have may not cut it. You may need to manually edit the file and change it, if so, do it according to this:

Modified qeglfshooks_stub.cpp for 5.2.0, only needed to modify EGLNativeWindowType QEglFSHooks::createNativeWindow like in 5.1.1:

EGLNativeWindowType QEglFSHooks::createNativeWindow(QPlatformWindow *platformWindow,
                                                    const QSize &size,
                                                    const QSurfaceFormat &format)
{
    Q_UNUSED(platformWindow);
    Q_UNUSED(size);
    Q_UNUSED(format);
    //return 0;

    static struct mali_native_window native_window = {
        .width = (short unsigned int)size.width(),
        .height = (short unsigned int)size.height(),
    };
    return &native_window;
}




/* For framebuffer */


Get ready to compile Qt5 for framebuffer (adapt the configure line paths to your own)

cd qt-everywhere-opensource-src-5.1.1

Important: Check all your paths below

./configure \
-opengl es2 \
-device linux-cubieboard2-g++ \
-device-option CROSS_COMPILE=/opt/sdcard.cubieboard.workbench/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/arm-linux-gnueabihf- \
-sysroot /opt/qt5.cubieboard2A20.workbench/cubie2-rootfs \
-opensource \
-confirm-license \
-optimized-qmake \
-release \
-make libs \
-prefix /usr/local/qt5cb2 \
-no-pch \
-nomake examples \
-nomake tests \
-no-xcb \
-eglfs \
-v

Check the config.summary file, mine is below - again this is the framebuffer version:

cat qt-everywhere-opensource-src-5.1.1/qtbase/config.summary 

   Configure summary

Building on:   linux-g++ (x86_64, CPU features: mmx sse sse2)
Building for:  devices/linux-cubieboard2-g++ (arm, CPU features: neon)
Platform notes:

            - Also available for Linux: linux-kcc linux-icc linux-cxx
        
qmake vars .......... styles += mac fusion windows QMAKE_CFLAGS_FONTCONFIG = -I/opt/qt5.cubieboard2A20.workbench/cubie2-rootfs/usr/include/freetype2   QMAKE_LIBS_FONTCONFIG = -L/opt/qt5.cubieboard2A20.workbench/cubie2-rootfs/usr/lib/arm-linux-gnueabihf -lfontconfig -lfreetype   DEFINES += QT_NO_LIBUDEV DEFINES += QT_NO_XCB DEFINES += QT_NO_XKBCOMMON PRECOMPILED_DIR = .pch/release-shared OBJECTS_DIR = .obj/release-shared MOC_DIR = .moc/release-shared RCC_DIR = .rcc/release-shared UI_DIR = .uic/release-shared sql-drivers =  sql-plugins =  sqlite qmake switches ......... 

Build options:
  Configuration .......... accessibility audio-backend c++11 clock-gettime clock-monotonic compile_examples concurrent cross_compile egl eglfs evdev eventfd fontconfig full-config getaddrinfo getifaddrs iconv icu inotify ipv6ifname large-config largefile linuxfb medium-config minimal-config mremap neon nis opengl opengles2 pcre png qpa qpa reduce_exports reduce_relocations release rpath shared small-config system-freetype system-zlib v8 xlib xrender 
  Build parts ............  libs
  Mode ................... release
  Using C++11 ............ yes
  Using PCH .............. no
  Target compiler supports:
    iWMMXt/Neon .......... no/yes

Qt modules and options:
  Qt D-Bus ............... no
  Qt Concurrent .......... yes
  Qt GUI ................. yes
  Qt Widgets ............. yes
  JavaScriptCore JIT ..... yes (To be decided by JavaScriptCore)
  QML debugging .......... yes
  Use system proxies ..... no

Support enabled for:
  Accessibility .......... yes
  ALSA ................... no
  CUPS ................... no
  FontConfig ............. yes
  Iconv .................. yes
  ICU .................... yes
  Image formats: 
    GIF .................. yes (plugin, using system library)
    JPEG ................. yes (plugin, using bundled copy)
    PNG .................. yes (in QtGui, using bundled copy)
  Glib ................... no
  GStreamer .............. no
  GTK theme .............. no
  Large File ............. yes
  libudev ................ no
  Networking: 
    getaddrinfo .......... yes
    getifaddrs ........... yes
    IPv6 ifname .......... yes
    OpenSSL .............. no
  NIS .................... yes
  OpenGL ................. yes (OpenGL ES 2.x)
  OpenVG ................. no
  PCRE ................... yes (bundled copy)
  pkg-config ............. yes 
  PulseAudio ............. no
  QPA backends: 
    DirectFB ............. no
    EGLFS ................ yes
    KMS .................. no
    LinuxFB .............. yes
    XCB .................. no
  Session management ..... yes
  SQL drivers: 
    DB2 .................. no
    InterBase ............ no
    MySQL ................ no
    OCI .................. no
    ODBC ................. no
    PostgreSQL ........... no
    SQLite 2 ............. no
    SQLite ............... yes (plugin, using bundled copy)
    TDS .................. no
  udev ................... no
  xkbcommon .............. no
  zlib ................... yes (system library)


Important bits:

  QPA backends: 
    DirectFB ............. no
    EGLFS ................ yes
    KMS .................. no
    LinuxFB .............. yes
    XCB .................. no


(For QtWebkit, as a side note, ICU must be available as well)


make -j 5 && make install


Once Qt5 builds:
the library files will be placed in /usr/local/qt5cb2 in the sd card rootfs
the qmake binary will be placed in /usr/local/qt5cb2 on the dev host

My host took less than 1h to build everything successfully, QtWebkit as well

Step 5, Cross-Compiling Qt5 Apps

Ok, by now you should have:

- a working SD Card image, with the latest mali libraries and installed Qt5 libraries
- a Qt5 development environment on your host

Make sure the SD Card image is unmounted and burn it on a card:

# dd bs=1M if=/path/cubie.img of=<sd device>; sync

Start cubieboard and make sure it's fully functional, and then get back to the development host.

On the host, you'll need to install and configure Qt Creator. Grab it from qtproject (http://qt-project.org/downloads)

To configure it, you will need to:

- set up the GCC compiler - use the linaro gcc
- set up the qmake binary - use the qmake binary from /usr/local/qt5cb2
- mount the SD card image you have, just the root partition
- set up the device, use cubie's ssh credentials

And that's it. Create an empty project, Qt Creator will generate a blank view with "Hello World" written on it, and build/deploy it to Cubie. If needed, check path permissions on Cubie to make sure that Qt Creator can deploy the files over ssh, and you're done!

Videos below show QuitCoding' Cinematic Experience running on mali libraries (framebuffer version) - pretty decent FPS!

http://www.youtube.com/watch?v=me5mHAKS1MA
http://www.youtube.com/watch?v=qedtjOUPDAw