Revision as of 12:44, 16 October 2012

Mer on Raspberry Pi

This page details the steps required to bring up a development environment which can be used to create a basic Mer image.

The hardware adaptation is maintained in the project CE:Adaptation:RaspberryPi

Working

• Boot with 128M/128M memory split (128M for the ARM, 128M for the GPU)
• Wired networking
• Gstreamer HW accelerated decode using gst-omx
• Audio output through HDMI/audio jack(at least after manual modprobe snd-bcm2835)
• OpenGL ES 2 (not X.Org integrated)
• OpenMax IL decode/render (not X.Org integrated)

Not working

• HW accelerated Gstreamer video render
• HW accelerated GStreamer video encode
• HW accelerated Gstreamer audio decode/encode
• Accelerated X.Org
• Accelerated Qt
• Qt 5.0
• Qt 4.8

Install Mer SDK

Using the instructions at http://wiki.merproject.org/wiki/Platform_SDK#Mer_platform_SDK install Mer SDK on your host Linux system. The SDK has been designed to not rely on the host system so you can use your favourite distro.

Get an account on the community OBS server, ping lbt on #mer freenode IRC channel.

edit .oscrc to set server to api.pub.meego.com and set user and password

To test the installation follow the instructions for building the SDK image.

Building a Mer Core Image

Here we use the SDK to build an image which can be written to an sdcard which will include bootloader, kernel and a base filesystem which boots X and starts qmlviewer.

Get kickstart file

curl -k -O  https://github.com/snowcap-electronics/kickstarts/raw/master/rpi/mer-rpi.ks

To work around a mic issue zypper in the following package to the SDK

sudo zypper in syslinux-extlinux

Use the mic tool to create the image using the kickstart file

sudo mic create raw mer-rpi.ks -o . --pkgmgr=yum --arch=armv6l

Once the image has been produced write to your sdcard (you may need to use sudo below if groups are not properly set):

dd of=/dev/sdX if=mer-rpi-mmcblk0p.raw bs=4M

Place in RaspberryPi and boot.

Host SDK Development using SB2

Cross-compiling on the host SDK (as opposed to compiling natively on device) is possible by creating a target (an unpacked rootfs) and using sb2 to "emulate" the ARM device.

Step-by-step Setup

Step one is to create the target rootfs. This can be done with mic using the same kickstart file used to create the image:

sudo mic create fs mer-rpi.ks -o /path/to/target --arch=armv6l

This will create a /path/to/target/mer-rpi directory with a rootfs that contains all the default packages from that ks.

Step two is changing the permissions so we can write anywhere on the rootfs:

sudo chown -R $USER.mer mer-rpi

Step three is initializing the sb2 target (yes, a lot of options there):

cd mer-rpi
sb2-init -A armv6l -M armv6l -d -L --sysroot=/ -C --sysroot=/ -c /usr/bin/qemu-arm-dynamic -m sdk-build -n -N -t / mer-rpi /opt/cross/bin/armv6l-meego-linux-gnueabi-gcc

There will be errors from sb2-init (concerning ld and host-gcc), but it should be safe to ignore them.

Step four is to fix a quirk about /var/run in the target being a symlink, sb2 doesn't like this:

rm var/run
mkdir var/run

Step five is to rebuild and refresh the packaging system so we can install devel packages:

sb2 -m sdk-install -R rpm --rebuilddb
sb2 -t mer-rpi -m sdk-install -R zypper ref

Building RPi Examples

As an example of how to use sb2 to build, we shall build the RPi examples. (TBD: sane way to get them)

First off, we know beforehand that we will need the rpi graphics and freetype devel packages installed to compile the examples. Usually the exact dependencies are either in the README or INSTALL of the project or (sadly often) found out by building and failing. We also need make and gcc in the target to compile.

To install, we will use sb2 in sdk-install mode and also request to fake that we are root user (as we did in setup too). This will enable us to write to the rootfs, normally it is considered read-only, and trick the tools to think we have super powers:

sb2 -m sdk-install -R zypper install gcc make gfx-rpi-devel gfx-rpi-libEGL-devel gfx-rpi-libGLESv2-devel gfx-rpi-libOMXIL-devel freetype-devel 

NOTE: sometimes it's necessary to be on the top directory of the target to successfully run commands in the sdk-install mode. If a command fails mysteriously, try that first.

Next we create a symbolic link from /usr (where the libs should be) to mer-pi/opt/vc (where the libs are in RPi "official" images). This way we avoid changing the include paths in the project (which would be a valid fix as well):

ln -s /usr opt/vc

Then we simply go to the hello_pi directory and invoke the build script (which just goes through the example directories calling make in them) through sb2:

sb2 ./rebuild.sh

If everything is set up right, you should in a moment have cross-compiled binaries to copy to your device.

NOTE: couple of examples (hello_audio & hello_video) need -lpthread to be added to their LDFLAGS to link succesfully, due to the ilclient helper lib requiring it.

The same principle works for most other projects as well, just install the dependencies and run the build commands through sb2.

(TBD: how to install non-packaged dependencies?)

Maintainers

For questions, suggestions and contributions you can ping the following persons in #mer @ Freenode

• cristi
• kulve
• vgrade
• zuh

For maintainers

Qt5 Platform Plugin

I've spent sometime this weekend setting up a package to hopefully build a Qt Platform Plugin which will mean we don't need to rebuild the whole of Qt5 with the RPi mkspec.

With lots of help from Stskeeps I've done the following :-

I linkpac'd qtbase to a new project at

https://build.pub.meego.com/package/files?package=qtplatformplugin-rpi&project=home%3Avgrade%3AraspPiQt5Plugin

and created a new spec file based on the qtwaylandplugin with the aim of just doing a qmake/make in the src/plugins/platforms directory utilising qeglfshooks_pi.cpp. Added the rpi-gfx package to provide EGL/GLES and bcm/vcos bits.

https://build.pub.meego.com/package/live_build_log?arch=armv7el&package=qtplatformplugin-rpi&project=home%3Avgrade%3AraspPiQt5Plugin&repository=Mer_Core_armv6l

I used the package-config files from rpi-gfx package (thanks kulve) and added qeglfshooks_pi.cpp to the .pro file

Current status is

And a discussion on the upside down, inside out issue below from #mer

[12:40] <vgrade__> sroedal: I have created a platform plugin based on eglfs using hooks for the raspberrypi, running qmlscene I get the following mixed up output, https://twitter.com/vgrade/status/257968860643340288/photo/1/large any ideas? [12:41] <vgrade__> sroedal: it looks upside down and back to front [12:41] <Bostik> ah, I've seen that before [12:42] <sroedal> vgrade__: must be something in qeglfsbackingstore.cpp [12:42] <sroedal> vgrade__: or does QML 2 render upside down as well? [12:42] <Bostik> we "fixed" that by applying a simple transformation matrix on the image, but the real reason probably comes from somewhere deeper [12:43] <Bostik> mismatched coordinate systems, it might have been [12:43] <vgrade__> sroedal: Bostik so the cause could be in many places [12:44] <Bostik> vgrade__: aye, but my guess is mesa and/or whatever sits on top of the display driver [12:45] <sroedal> vgrade__: what hooks btw? [12:45] <vgrade__> Bostik: no mesa in this stack [12:45] <sroedal> we had some flipped coordinate issues with kms, but that should be unrelated [12:46] <Stskeeps> vgrade__: cat /dev/urandom > /dev/fb0 [12:46] <Stskeeps> which side does it come from, bottom, or top? [12:46] <vgrade__> sroedal: took eglfs_hooks_pi.cpp from the Pi mkspecs dir [12:46] <vgrade__> Stskeeps: not home right now [12:47] <Stskeeps> ok [12:48] <sroedal> vgrade__: but the important question is whether hellowindow or OpenGL windows also are flipped [12:48] <sroedal> vgrade__: in your screenshot you have a raster window, which is rendered with a different code path [12:50] <vgrade__> sroedal: why do you say raster window? because its not fullscreen? [12:52] <vgrade__> sroedal: I changed the function in the hook code to return height/2 width/2 to make sure it was using the hook code [12:52] <sroedal> vgrade__: nope, because it's a QWidget, rendered with QBackingStore [12:52] <sroedal> vgrade__: using a QWindow with surface type QSurface::RasterSurface [12:53] <vgrade__> sroedal: ok [12:53] <sroedal> eglfs still renders it using OpenGL in the end, via a texture [12:53] <vgrade__> sroedal: I'm very new to this please bear with me [12:54] <Stskeeps> vgrade__: try minimer when home [12:54] <vgrade__> sroedal: so that's how you could "fix" it by changing how the texture is drawn [12:54] <vgrade__> Stskeeps: wilko [12:55] <vgrade__> thanks for the help guys [12:55] <vgrade__> lunch [13:24] <sroedal> vgrade__: how we would fix it depends on whether it's an issue for both OpenGL and Raster windows :) [13:25] <vgrade__> sroedal: ok, I'll get more info tonight [13:25] <vgrade__> just reading , http://www.digipedia.pl/usenet/thread/15030/5965/ [13:27] <sroedal> vgrade__: hmm, right

Catch me (vgrade) on #mer if you want to get involved.

Wiki page TODO

• Add: QtCreator Instructions

Updating packages

bootloader-rpi

git clone https://github.com/raspberrypi/firmware.git
rm firmware/boot/kernel*
tar zcf firmware-boot-<git sha>.tgz firmware/boot

gfx-rpi

git clone https://github.com/raspberrypi/firmware.git
tar zcf firmware-opt-<git sha>.tgz firmware/hardfp/opt/vc/ firmware/opt/vc/

gst-omx-rpi

git clone git://anongit.freedesktop.org/gstreamer/gst-omx
cd gst-omx
git checkout -b raspberry remotes/origin/raspberry
./autogen.sh && make dist
mv gst-omx-0.10.0.1.tar.gz gst-omx-raspberry-0.10.0.1-<git sha>.tar.gz

gst-plugins-bad-free, gst-plugins-base

• Branched from Mer Core
• gst-plugins-base upgraded to 0.10.36
• Added --with-audioresample-format=float for ARMv6 in gst-plugins-base.spec

kernel-adaptation-rpi

• Download latest .tar.gz from https://github.com/raspberrypi/linux (branch rpi-3.2.27)

mkimage-rpi

git clone https://github.com/raspberrypi/tools.git
tar zcf tools-mkimage-<git sha>.tar.gz tools/mkimage