Difference between revisions of "RaspberryPi qOrbiter"

From LinuxMCE
Jump to: navigation, search
m ("Useful" Qt links)
(added chroot env setup details)
Line 4: Line 4:
 
-256MB of RAM is insufficient to build lmce.  MakeRelease and MakeRelease_PrepFiles both fail with out of memory errors due to the limited memory available on the RPi.
 
-256MB of RAM is insufficient to build lmce.  MakeRelease and MakeRelease_PrepFiles both fail with out of memory errors due to the limited memory available on the RPi.
 
-Cross-compiling will be required.  More notes to follow.
 
-Cross-compiling will be required.  More notes to follow.
 +
==Debian Chroot Environment==
 +
One approach is to set up a debian chroot environment, and use qemu with pass though emulation.
 +
See http://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2BAC8-debootstrap_approach
 +
===Specifically for the Pi with raspbian image===
 +
''sudo needed for all of these commands''
 +
 +
Install some necessaries
 +
# apt-get install binfmt-support qemu qemu-user-static debootstrap
 +
 +
Next set up the chroot env, create your directory, calling it what you like, if it doesn't exist.
 +
# mkdir debian_armhf_wheezy
 +
 +
Bootstrap your new environment
 +
# qemu-debootstrap --arch armhf wheezy debian_armhf_wheezy http://archive.raspbian.org/raspbian
 +
 +
Mount /proc and friends
 +
# mount -t proc proc debian_armhf_wheezy/proc
 +
# mount -t sysfs sysfs debian_armhf_wheezy/sys
 +
# mount -o bind /dev debian_armhf_wheezy/dev
 +
 +
Not necessary, but you can also mount your existing src directory, if you have one, into your new chroot env.
 +
# mount --bind $HOME/path/to/my/src debian_armhf_wheezy/home/<user>/lmce/src
 +
 +
Now you are ready to chroot into your new env and get going
 +
# LC_ALL=C chroot debian_armhf_wheezy
 +
 +
Use ''apt-get update'' and ''apt-get install <pkg>'' to install needed packages in your chrooted env.
  
 
==Cross Compilation setup==
 
==Cross Compilation setup==

Revision as of 12:11, 24 July 2012

Device Specification

-The Raspberry Pi is an ARM based computer the size of a credit card. 700Mhz, 256MB RAM, Ethernet, 2xUSB, GPIO

-256MB of RAM is insufficient to build lmce. MakeRelease and MakeRelease_PrepFiles both fail with out of memory errors due to the limited memory available on the RPi. -Cross-compiling will be required. More notes to follow.

Debian Chroot Environment

One approach is to set up a debian chroot environment, and use qemu with pass though emulation. See http://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2BAC8-debootstrap_approach

Specifically for the Pi with raspbian image

sudo needed for all of these commands

Install some necessaries

# apt-get install binfmt-support qemu qemu-user-static debootstrap

Next set up the chroot env, create your directory, calling it what you like, if it doesn't exist.

# mkdir debian_armhf_wheezy

Bootstrap your new environment

# qemu-debootstrap --arch armhf wheezy debian_armhf_wheezy http://archive.raspbian.org/raspbian

Mount /proc and friends

# mount -t proc proc debian_armhf_wheezy/proc
# mount -t sysfs sysfs debian_armhf_wheezy/sys
# mount -o bind /dev debian_armhf_wheezy/dev

Not necessary, but you can also mount your existing src directory, if you have one, into your new chroot env.

# mount --bind $HOME/path/to/my/src debian_armhf_wheezy/home/<user>/lmce/src

Now you are ready to chroot into your new env and get going

# LC_ALL=C chroot debian_armhf_wheezy

Use apt-get update and apt-get install <pkg> to install needed packages in your chrooted env.

Cross Compilation setup

Initially this section will have information specific to getting Qt on Pi going. Its pre-packaged and fairly easy to install.

At the time of writing Qt on Pi tarball is at version 0.2. Get the tarball here http://www.raspberrypi.org/downloads at the bottom of the page. This has a premade SD image plus the toolchain and sysroot install required for cross compilation.

If you are about to install this on your current machine with a working Qt development environment DON'T

You will need to either set up a VM or a chroot environment as the qt5 shipped with this image isn't setup to install alongside an x86 install. They plan on having these play nice in future releases.

Qt5, Toolchain and sysroot install

This is documented on the QtonPi wiki but basically after you have downloaded the qtonpi tarball extract the three files within. Then as root extract [opt-qt5-current.tar.bz2] and [toolchain-and-sysroot-armv5tel.tar.bz2]

$ cd /
$ sudo tar -jxvf /path to extracted image files/opt-qt5-current.tar.bz2
$ sudo tar -jxvf /path to extracted image files/toolchain-and-sysroot-armv5tel.tar.bz2

Qt creator

The tarball comes with a recent version of qtcreator, but since then qt2.5 RC has come out, Should be safe enough to use that instead. Just install that by executing the .bin installer. Hold that thought, qt2.5 creator RC doesn't have the deploy steps set up

Within Qt creator you need to point it at your cross tool chain compiler+debugger:

  1. Tools->Options->Build&Run then Tool Chains
  2. then select add, in the drop-down pick GCC
  3. Select GCC and browse for compiler to
/opt/qtonpi/bin/armv5tel-qtonpi-linux-gnueabi-gcc

and for the debugger

/opt/qtonpi/bin/armv5tel-qtonpi-linux-gnueabi-gdb

Save these selections by clicking Apply and OK

Raspberry Pi Setup

Virtual using qemu

As I don't have a rpi yet I used qemu to do some initial testing. My setup was a 12.04 VM. You can either install qemu

sudo apt-get install qemu-system

Or you can build qemu from git. You only need to do this if the qemu on your distro doesn't support the Broadcom SOC (ARM1176 core) on the Pi. In order to boot your image you will need a suitable kernel for your emulator, there is one available here http://dl.dropbox.com/u/45842273/zImage_3.1.9 Boot your virtual Pi

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 rw panic=1" qtonpi-sdcard-0.2.img -redir tcp:5022::22

add

console=ttyAMA0

to the -append param to have the boot console re-directed to the terminal.

the -redir tcp:5022::22 redirects port 22 (ssh) on the virtual Pi to port 5022 on the host enabling you to ssh in.

ssh pi@localhost -p5022

Raspberry Pi Setup

I used the image I was using above and wrote it to an SD card.If you are on windows make sure your machine can handle larger cards By default the qtonpi release doesn't have the network if enabled. On each boot you can run

ifup eth0

or

dhclient eth0

or

just edit /etc/sysconfig/network-scripts/ifcfg-eth0 and set the ONBOOT option equal to YES and be done with it.

Also you need to set the time and date after each boot - no RTC on the rPi

Code Changes

According to the current Qt Documentation adding

greaterThan(QT_MAJOR_VERSION, 4) {
       QT += widgets
       QT += quick1
   } else {
       QT += declarative
   }

to the pro file loads the correct modules for both Qt4/Qt5.

04/07/2012 - see ticket trac #1497 code checked into svn.

"Useful" Qt links

http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5

https://qt-project.org/wiki/New_Signal_Slot_Syntax

http://qt-project.org/wiki/Qt-5Features

http://qt-project.org/wiki/QML1-vs-QML2

A recent but good addition http://doc-snapshot.qt-project.org/5.0/qtquick-porting-qt5.html#porting-c-code

I don't know whether these apply to how Qt5 will be when it is released, but they don't completely correspond to it in its current state, so don't believe all you read.

Raspberry Pi distros

Looking at http://elinux.org/RPi_Distributions there are quite a few to choose from.

Which is the best fit? I don't know.

I'm starting with QtonPi but I don't know if a full fedora release is necessary. This is actually a trimmed down fedora release no X, graphics written direct to fb

Mer/Meego might be a good fit too.

qOrbiter on Pi

QtonPi 0.2 image

trimmed down fedora remix with qt5 pre-installed, no gui.

Status

28/05/2012 - Unfortunately I have not been able to get my compiled qOrbiter to run on my virtual setup. Depending on the combination of kernel I use and/or SD image I either get an illegal instruction or and error creating a vchiq instance.

And given that the vchiq lib stuff is to do with the GPU, which is initialised in firmware, this may be a bit of an impass until I get actual hardware.

30/05/2012 - Have just received my rPi and my previously compiled qOrbiter starts and gets past the vchiq/illegal instruction I had. I have other issues before I get it going but all going in the right direction.

02/06/2012 - qOrbiter splash screen loads, communicates with dcerouter, gets config - then boom my network dies. I don't know if its rPi specific or some porting issue with qOrbiter. I see smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped scroll past me. My ssh connection dies as a result so I need to be logged in on the rPi. Needs more investigation...

06/06/2012 - got past n/w problem, now home screen loads. Also had to disable qml screen saver. The shader effect component is supposed to be available via QtQuick 2.0 and not need the labs plugin, but this appears not to be the case. It is likely it is just not in the snapshot yet.

08/06/2012 - It seems there is no mouse support in the current 0.2 qtonpi SD image. This is a deal breaker until 0.3 image is released. Mouse support has been checked into git so is available if we roll our own qt5.

Next image - Debian Wheezy

Investigating a debian wheezy port at the moment - should eek out a bit more speed using hardfp. There are qt50-snapshots available for the target. May need to set up a separate toolchain.

Status

11/06/2012 - existing qOrbiter won't run on target, need to link against newer qt5 sysroot on host.

19/06/2012 - have rebuilt and linked qOrbiter against qt5 from git. Up and running again on my Raspberry Pi. The default CPU/GPU split of 192/64 allows qOrbiter to run, lower one - 244/32 gives an error creating the display surface. Will bump up split to 128/128 if I get display issues.

22/06/2012 - as I thought, I had to move the split to 128/128 and now I get no GL memory errors and the background effects work on the home screen. I need to find out why switching threads away from the qml engine is failing.