RaspberryPi: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
(Removed links redirecting to malware)
 
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{LangSwitch}}
[[Category:Devices]]
[[Category:Devices]]
* Note: the information on this page is outdated. Updated build and deploy steps coming soon.
* For an up-to-date guide for cross-compiling Qt 5.6 targeting eglfs and Raspbian Jessie, see [[RaspberryPi2EGLFS]].
* See also: [[:Category:QtonPi|QtonPi]] [[RaspberryPi_Beginners_Guide]]


== Raspberry Pi (BCM2835): Device Information ==
== Raspberry Pi (BCM2835): Device Information ==


{|
{| class="wikitable"
!Architecture
! style="text-align:left;"|Architecture
!'''ARMv6'''
! style="text-align:left;"|ARMv6
|-
|-
|CPU
|CPU
Line 28: Line 32:
=== Qt 5 port functional state (against Raspbian Wheezy (primary reference platform)) ===
=== Qt 5 port functional state (against Raspbian Wheezy (primary reference platform)) ===


|''. Feature|''. State|_. Additional info|<br />|Hardware accelerated cursor|Done|upstream|<br />|Wayland support|Done|upstream|<br />|Hardware decoding of images|To Do||<br />|Scenegraph tailoring|To Do||<br />|HardFP support|Done|Requires v8 patch|<br />|Qt Multimedia|Done|Requires gst-omx|<br />|Webkit integration|To Do|webgl, tex mapper|
{| class="wikitable"
! style="text-align:left;"|Feature
! State
! Additional info
|-
|Hardware accelerated cursor
|Done
|upstream
|-
|Wayland support
|Done
|upstream
|-
|Hardware decoding of images
|To Do
|
|-
|Scenegraph tailoring
|To Do
|
|-
|HardFP support
|Done
|Requires v8 patch
|-
|Qt Multimedia
|Done
|Requires gst-omx
|-
|Webkit integration
|To Do
|webgl, tex mapper
|}


=== Additional information ===
=== Additional information ===


'''''' "The Raspberry Pi is a credit-card sized computer that plugs into your TV and a keyboard. It’s a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video. We want to see it being used by kids all over the world to learn programming."


'''''' "Raspberry Pi Foundation FAQ":http://www.raspberrypi.org/faqs
* "The Raspberry Pi is a credit-card sized computer that plugs into your TV and a keyboard. It’s a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video. We want to see it being used by kids all over the world to learn programming."
 
* [http://www.raspberrypi.org/faqs Raspberry Pi Foundation FAQ]


== Hardware Details ==
== Hardware Details ==


Low end ARM11 CPU running at ~700 BogoMIPS.<br />VideoCore IV GPU is capable of running QtQuick2/SceneGraph at high resolutions.<br />Both CPU and GPU share main memory.
Low end ARM11 CPU running at ~700 BogoMIPS. <br>
VideoCore IV GPU is capable of running QtQuick2/SceneGraph at high resolutions. <br>
Both CPU and GPU share main memory. <br>


== Linux Platform ==
== Linux Platform ==
Line 46: Line 85:
* the pre-built Raspbian snapshots
* the pre-built Raspbian snapshots


The Raspberry Pi Foundation provides a few different distributions which can be downloaded "here":http://www.raspberrypi.org/downloads
The Raspberry Pi Foundation provides a few different distributions which can be downloaded [http://www.raspberrypi.org/downloads here]


'''Please note: Not all platforms are created equal: The "Raspbian Wheezy image":http://www.raspberrypi.org/downloads is a very functional distro with piping hot firmware and good support on the OS vendor side, so that is the first class citizen when following these instructions. Deviating from its usage will probably introduce additional complexity and will carry you away from the primary testing platform'''
'''Please note: Not all platforms are created equal: The [http://www.raspberrypi.org/downloads Raspbian Wheezy image] is a very functional distro with piping hot firmware and good support on the OS vendor side, so that is the first class citizen when following these instructions. Deviating from its usage will probably introduce additional complexity and will carry you away from the primary testing platform'''


=== Raspbian "Wheezy" image (First class citizen) ===
=== Raspbian "Wheezy" image (First class citizen) ===
Line 54: Line 93:
==== My home rolled Linaro (crosstool-ng generated) toolchain ====
==== My home rolled Linaro (crosstool-ng generated) toolchain ====


Since the Linaro toolchain is an order of magnitude more charismatic when cross compiling, you will probably want to be reading our "notes":http://wiki.qt.io/ToolchainInformation on using it. Since I have to bleed profusely in order to get a functioning Linaro toolchain on my Arch install, I have provided it "here":http://blueocean.qmh-project.org/gcc-4.7-linaro-rpi-gnueabihf.tbz
Since the Linaro toolchain is an order of magnitude more charismatic when cross compiling, you will probably want to be reading our [http://wiki.qt.io/ToolchainInformation notes] on using it. Since I have to bleed profusely in order to get a functioning Linaro toolchain on my Arch install, I have provided it [http://blueocean.qmh-project.org/gcc-4.7-linaro-rpi-gnueabihf.tbz here]


"gcc-4.7-linaro-rpi-gnueabihf":http://blueocean.qmh-project.org/gcc-4.7-linaro-rpi-gnueabihf.tbz
[http://blueocean.qmh-project.org/gcc-4.7-linaro-rpi-gnueabihf.tbz gcc-4.7-linaro-rpi-gnueabihf]


==== Required changes (Rolling, should be empty) ====
==== Required changes (Rolling, should be empty) ====
Line 66: Line 105:
Undo crippling GL defaults, possibly stemming from my incorrect indication in the Pi hooks that the GLESv2 impl support GL buffer queuing. One thing is for certain, the consistent timer below is not something you want in affect on your Pi. (On the stage at Qt CS, infront of a crowd, one of whom is whistling the Kill Bill theme)
Undo crippling GL defaults, possibly stemming from my incorrect indication in the Pi hooks that the GLESv2 impl support GL buffer queuing. One thing is for certain, the consistent timer below is not something you want in affect on your Pi. (On the stage at Qt CS, infront of a crowd, one of whom is whistling the Kill Bill theme)


[sirspudd<code>bb|:qt5/qtdeclarative]$ git show<br />commit 82c9f3187ce79e1aef57479b0cc7b7274c0bd85e<br />Author: Donald Carr <donald.carr</code>nokia.com><br />Date: Wed Aug 8 09:52:34 2012 ''0000
[sirspudd@bb|:qt5/qtdeclarative]$ git show <br>
<br /> Disable fixed animation step before it disables me
commit 82c9f3187ce79e1aef57479b0cc7b7274c0bd85e <br>
<br />diff —git a/src/quick/items/qquickwindowmanager.cpp b/src/quick/items/qquickwindowmanager.cpp<br />index 3cced7a..90c2dc9 100644<br />— a/src/quick/items/qquickwindowmanager.cpp<br />'' b/src/quick/items/qquickwindowmanager.cpp<br /><code><code> –137,16 ''137,6 <code><code> QQuickWindowManager '''QQuickWindowManager::instance()<br /></code><br /> else if (qmlForceThreadedRenderer())<br /> fancy = true;
Author: Donald Carr <donald.carr@nokia.com> <br>
<br />- // Enable fixed animation steps…<br />- QByteArray fixed = qgetenv("QML_FIXED_ANIMATION_STEP");<br />- bool fixedAnimationSteps = bufferQueuing;<br />- if (fixed == "no")<br />- fixedAnimationSteps = false;<br />- else if (fixed.length())<br />- fixedAnimationSteps = true;<br />- if (fixedAnimationSteps)<br />- QUnifiedTimer::instance(true)->setConsistentTiming(true);<br />-<br /> if (!theInstance) {<br /> theInstance = fancy<br /> ? (QQuickWindowManager''') new QQuickRenderThreadSingleContextWindowManager<br /><code>
Date: Wed Aug 8 09:52:34 2012 ''0000 <br>
<br />h4. Toolchain considerations
 
<br />This is bleeding edge and carries the latest snapshot of the firmware. Anyone doing active development against the BCM libraries will probably want to be living in this realm. Targeting this system requires a Linaro (Raspbian multiarch cognizant) compiler. Without this, you will find yourself scrambling to indicate that relevant libraries are lurking in $lib/arm-linux-gnueabi paths. If you know how to make this play nice, please feel free to edumicate me (Donald Carr) on the niceties.
Disable fixed animation step before it disables me
<br />I built my toolchain by following these instructions:
diff —git a/src/quick/items/qquickwindowmanager.cpp <br> b/src/quick/items/qquickwindowmanager.cpp <br>
<br />https://launchpadlibrarian.net/110971284/README.txt
index 3cced7a..90c2dc9 100644 <br>
<br />and an Ubuntu 10.04 schroot. There is no point fighting it, before stooping to this behavior, I was facing spurious build failures all over the show.
— a/src/quick/items/qquickwindowmanager.cpp <br>
<br />h4. Known issues
++++ b/src/quick/items/qquickwindowmanager.cpp <br>
<br />For qtjsbackend the following patch is needed:<br />"usingHardFloat automatic detection faux pas":https://codereview.qt.io/#change,27256
<code>
<br />h3. Arch Linux
–137,16 +137,6
<br />Arch has been tested and sommer (just) works. The firmware tends to be bleeding edge, so the Wheezy images firmware notes will possibly be of relevance.
</code>
<br />h3. Buildroot
QQuickWindowManager *QQuickWindowManager::instance()
<br />One of our engineers has been investing time in a home rolled hardfp distribution based on Buildroot. The recipe is available here:
<code>
<br />https://github.com/nezticle/RaspberryPi-BuildRoot.git
else if (qmlForceThreadedRenderer())
<br />Given the preponderance of hardfp performance over its register ignorant peers, this will be useful in eking every last drop of performance out of the hardware.
fancy = true;
<br />h2. Building Qt from scratch
 
<br />h3. Helper scripts
- // Enable fixed animation steps…
<br />These "scripts":https://gitorious.org/cross-compile-tools/cross-compile-tools will be cited at relevant sections and are intended as a rough guide as to the automation of labourious tasks.
- QByteArray fixed = qgetenv("QML_FIXED_ANIMATION_STEP");
<br />Use when prompted at your own discretion.
- bool fixedAnimationSteps = bufferQueuing;
<br />We generate the nightly Qt snapshots using the following "scripts":git://gitorious.org/packaging-scripts/packaging-scripts.git
- if (fixed == "no")
<br />These are filthy and exist purely to get the job done with as little effort/time expenditure on our part possible.
- fixedAnimationSteps = false;
<br />h3. Adjusting the root filesystem for development
- else if (fixed.length())
<br />Qt 5 has a hard dependency on libudev for hot pluggable hardware detection/support. This mandates the installation of the libudev-devel package. (Or the filthy use of an arbitrary libudev.h and the creation of a libudev.so symlink, which is how we roll in the trenches(When life gives you mustard gas, eat franks!)) (This consideration will fall away with the release of the next Raspbian reference image)
- fixedAnimationSteps = true;
<br />In order to use the root filesystem from the SD card, mount the rootfs partition as a loopback device. The offset for mount can change with different images, please query the partition offset with fdisk (see http://www.syslinux.org/wiki/index.php/Hard_disk_images ).<br /></code><br />eg (or the official Raspbian image(s)):
- if (fixedAnimationSteps)
<br />$ #mount -o loop,offset=62914560 /opt/stores/broadcom/raspberry-pi/2012-07-15-wheezy-raspbian.img /mnt/rasp-pi-rootfs<br /><code><br />In order to be able to use the '''—sysroot''' option during the Qt build process, you have to resolve all absolute library links inside the mounted rootfs, but replacing full qualified symlinks with relative ones, otherwise the linker will pickup your host libraries and promptly barf.
- QUnifiedTimer::instance(true)->setConsistentTiming(true);
<br />The magical fixQualifiedLibraryPaths script in the cross-compile-tools repo above should go some distance to easing this chore. Simply pass it the rootfs and the compiler and it will attempt to fix the symlinks accordingly.
-
<br />You will also need to create several missing symlinks, notably: libstdc.so (/usr/lib) and libgcc_s.so (/lib) (and any other friends of the forest who rear their frothy maws with the earnest intent to munch on you)
if (!theInstance) {
<br />This might seem hacky but it is important that we pass the reference Raspbian image to the code sourcery toolchain to ensure that we are linking against the right system libraries, and not toolchain libs in conflict with the libraries on the actual device.
theInstance = fancy
<br />h3. Additional packages  
? (QQuickWindowManager''') new QQuickRenderThreadSingleContextWindowManager
<br />The additional packages extend the scope of Qt functionality and are optional in as much as the base Raspbian image has all the development files required for GLESv2 and input support.
</code>
<br />Additional packages are documented "here":http://wiki.qt.io/Category:Software-FAQ along with the associated ramifications
 
<br />I personally install it on the device, shuttle across the .deb, unarchive it and unpack the data.tar.gz over the original mounted image.
==== Toolchain considerations ====
<br />h2. Qt 5 on the Raspberry Pi (BCM2835)
This is bleeding edge and carries the latest snapshot of the firmware. Anyone doing active development against the BCM libraries will probably want to be living in this realm. Targeting this system requires a Linaro (Raspbian multiarch cognizant) compiler. Without this, you will find yourself scrambling to indicate that relevant libraries are lurking in $lib/arm-linux-gnueabi paths. If you know how to make this play nice, please feel free to edumicate me (Donald Carr) on the niceties.
<br />h3. Installing Qt 5 nightlies from the repo  
 
<br />We are generating Qt 5 nightlies for the Raspberry PI reference Raspbian image, and these are available here:
I built my toolchain by following these instructions:
<br />http://archive.qmh-project.org/rpi-wheezy/debian
 
<br />this is not currently shipped as part of the Raspbian reference image, and hence
https://launchpadlibrarian.net/110971284/README.txt
<br />you have to add:
 
<br />deb http://archive.qmh-project.org/rpi-wheezy/debian unstable main
and an Ubuntu 10.04 schroot. There is no point fighting it, before stooping to this behavior, I was facing spurious build failures all over the show.
<br />to your source list and then you need to do to get piping hot Qt 5 action in your life is:
 
<br />apt-get update<br />apt-get install qt50-snapshot
==== Known issues ====
<br />We generate these packages using "this":https://gitorious.org/packaging-scripts set of scripts
For qtjsbackend the following patch is needed:
<br />h3. Building Qt  
[https://codereview.qt.io/#change,27256 usingHardFloat automatic detection faux pas]
<br />This will build everything in-source, if you want to build out-of-source execute '''configure''' and '''qmake''' for additional modules from within a separate empty folder.
 
<br />If you use either squeeze or archlinux, you need to provide the distro name as a device option for the '''configure''' script:<br /></code><br />-device-option DISTRO=[squeeze,arch]<br /><code>
=== Arch Linux ===
<br />h3. qtbase
Arch has been tested and sommer (just) works. The firmware tends to be bleeding edge, so the Wheezy images firmware notes will possibly be of relevance.
<br /></code><br />$ cd <qtbase><br />$ ./configure -prefix <your prefix> -release  -device linux-rasp-pi-g''+ -make libs  -device-option CROSS_COMPILE=<your toolchain path>/bin/arm-none-linux-gnueabi-<br /> -sysroot <your sysroot path><br />$ make install<br /><code>
 
=== Buildroot ===
One of our engineers has been investing time in a home rolled hardfp distribution based on Buildroot. The recipe is available here:
 
https://github.com/nezticle/RaspberryPi-BuildRoot.git
 
Given the preponderance of hardfp performance over its register ignorant peers, this will be useful in eking every last drop of performance out of the hardware.
 
A more recent approach to build a basic Qt5 development environment and bootable Linux distribution with Buildroot is here:
 
https://github.com/pbouda/buildroot-qt-dev
 
At the moment, this compiles Qt5 with multimedia module, OpenGL and SSL support and gives you access to the running Raspberry via SSH. You will also get a full cross-compilation environment to build your Qt apps and libraries for the Raspberry. More information is available in the README on GitHub.
 
== Building Qt from scratch ==
=== Helper scripts ===
These [https://gitorious.org/cross-compile-tools/cross-compile-tools scripts] will be cited at relevant sections and are intended as a rough guide as to the automation of labourious tasks.
 
Use when prompted at your own discretion.
 
We generate the nightly Qt snapshots using the following "scripts":git://gitorious.org/packaging-scripts/packaging-scripts.git
 
These are filthy and exist purely to get the job done with as little effort/time expenditure on our part possible.
 
=== Adjusting the root filesystem for development ===
Qt 5 has a hard dependency on libudev for hot pluggable hardware detection/support. This mandates the installation of the libudev-devel package. (Or the filthy use of an arbitrary libudev.h and the creation of a libudev.so symlink, which is how we roll in the trenches(When life gives you mustard gas, eat franks!)) (This consideration will fall away with the release of the next Raspbian reference image)
 
In order to use the root filesystem from the SD card, mount the rootfs partition as a loopback device. The offset for mount can change with different images, please query the partition offset with fdisk (see http://www.syslinux.org/wiki/index.php/Hard_disk_images ).
<code>
eg (or the official Raspbian image(s)):
 
$ #mount -o loop,offset=62914560 /opt/stores/broadcom/raspberry-pi/2012-07-15-wheezy-raspbian.img /mnt/rasp-pi-rootfs
</code>
In order to be able to use the '''—sysroot''' option during the Qt build process, you have to resolve all absolute library links inside the mounted rootfs, but replacing full qualified symlinks with relative ones, otherwise the linker will pickup your host libraries and promptly barf.
 
The magical fixQualifiedLibraryPaths script in the cross-compile-tools repo above should go some distance to easing this chore. Simply pass it the rootfs and the compiler and it will attempt to fix the symlinks accordingly.
 
You will also need to create several missing symlinks, notably: libstdc.so (/usr/lib) and libgcc_s.so (/lib) (and any other friends of the forest who rear their frothy maws with the earnest intent to munch on you)
 
This might seem hacky but it is important that we pass the reference Raspbian image to the code sourcery toolchain to ensure that we are linking against the right system libraries, and not toolchain libs in conflict with the libraries on the actual device.
 
=== Additional packages ===
The additional packages extend the scope of Qt functionality and are optional in as much as the base Raspbian image has all the development files required for GLESv2 and input support.
 
Additional packages are documented [http://wiki.qt.io/Category:Software-FAQ here] along with the associated ramifications
 
I personally install it on the device, shuttle across the .deb, unarchive it and unpack the data.tar.gz over the original mounted image.
 
== Qt 5 on the Raspberry Pi (BCM2835) ==
=== Installing Qt 5 nightlies from the repo ===
 
The links are no longer valid and redirect to a site which will try to install malware so they have been removed for safety purposes. If there are new locations for the packages, then please remove this line when updating.
 
We are generating Qt 5 nightlies for the Raspberry PI reference Raspbian image, and these are available here:
 
(link redacted)
 
this is not currently shipped as part of the Raspbian reference image, and hence
 
you have to add:
 
deb (link redacted) unstable main
 
to your source list and then you need to do to get piping hot Qt 5 action in your life is:
 
apt-get update
apt-get install qt50-snapshot
 
We generate these packages using [https://gitorious.org/packaging-scripts this] set of scripts
 
=== Building Qt ===
This will build everything in-source, if you want to build out-of-source execute '''configure''' and '''qmake''' for additional modules from within a separate empty folder.
 
If you use either squeeze or archlinux, you need to provide the distro name as a device option for the '''configure''' script:
<code>
-device-option DISTRO=[squeeze,arch]
</code>
 
=== qtbase ===
<code lang="bash">
$ cd <qtbase>
$ ./configure -prefix <your prefix> -release  -device linux-rasp-pi-g''+ -make libs  -device-option CROSS_COMPILE=<your toolchain path>
/bin/arm-none-linux-gnueabi-
-sysroot <your sysroot path>
$ make install
</code>


=== Other modules ===
=== Other modules ===
Line 120: Line 244:
Depending on your needs/desires you can now use your freshly minted qmake to (shadow) build whatever Qt 5 modules you require, using the following approach:
Depending on your needs/desires you can now use your freshly minted qmake to (shadow) build whatever Qt 5 modules you require, using the following approach:


</code><br />$ cd <qt_module_dir><br />$ <your prefix>/bin/qmake<br />$ make<br />$ make install<br /><code><br />At a bare minimum we would recommend: qtjsbackend and qtdeclarative
<code>
$ cd <qt_module_dir>
$ <your prefix>/bin/qmake
$ make
$ make install
</code>
At a bare minimum we would recommend: qtjsbackend and qtdeclarative


=== Runtime information ===
=== Runtime information ===
Line 136: Line 266:
Now we're going to have to cross compile libffi and wayland. First we need to set up our environment with the following environment variables:
Now we're going to have to cross compile libffi and wayland. First we need to set up our environment with the following environment variables:


</code><br />export RPI_SYSROOT=/mnt/rasp-pi-rootfs<br />export TOOLCHAIN=$HOME/raspberry/arm-2011.09<br />export QTDIR=$HOME/raspberry/qt5/qtbase<br />export PATH=$QTDIR/bin:$TOOLCHAIN/bin:$PATH<br />export PREFIX=/opt/myqt<br />export PKG_CONFIG_PATH="$RPI_SYSROOT/usr/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/share/pkgconfig"<br />export PKG_CONFIG_SYSROOT_DIR="$RPI_SYSROOT"<br />export PKG_CONFIG_ALLOW_SYSTEM_LIBS=1<br />export PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1<br />export CPP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-cpp<br />export CC=$TOOLCHAIN/bin/arm-none-linux-gnueabi-gcc<br />export CXX=$TOOLCHAIN/bin/arm-none-linux-gnueabi-g++<br />export CFLAGS="—sysroot=$RPI_SYSROOT"<br />export CXXFLAGS="—sysroot=$RPI_SYSROOT"<br />export CPPFLAGS="—sysroot=$RPI_SYSROOT"<br />export LD=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ld<br />export LDFLAGS="—sysroot=$RPI_SYSROOT"<br />export AS=$TOOLCHAIN/bin/arm-none-linux-gnueabi-as<br />export STRIP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-strip<br />export AR=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ar<br /><code>
<code lang="bash">
export RPI_SYSROOT=/mnt/rasp-pi-rootfs
export TOOLCHAIN=$HOME/raspberry/arm-2011.09
export QTDIR=$HOME/raspberry/qt5/qtbase
export PATH=$QTDIR/bin:$TOOLCHAIN/bin:$PATH
export PREFIX=/opt/myqt
export PKG_CONFIG_PATH="$RPI_SYSROOT/usr/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/share/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="$RPI_SYSROOT"
export PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
export PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
export CPP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-cpp
export CC=$TOOLCHAIN/bin/arm-none-linux-gnueabi-gcc
export CXX=$TOOLCHAIN/bin/arm-none-linux-gnueabi-g++
export CFLAGS="—sysroot=$RPI_SYSROOT"
export CXXFLAGS="—sysroot=$RPI_SYSROOT"
export CPPFLAGS="—sysroot=$RPI_SYSROOT"
export LD=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ld
export LDFLAGS="—sysroot=$RPI_SYSROOT"
export AS=$TOOLCHAIN/bin/arm-none-linux-gnueabi-as
export STRIP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-strip
export AR=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ar
</code>


Make sure to replace the RPI_SYSROOT, TOOLCHAIN, and QTDIR variables with your equivalents. PREFIX should be whatever you used when configuring Qt above. Now we're ready to cross compile. First, for libffi:
Make sure to replace the RPI_SYSROOT, TOOLCHAIN, and QTDIR variables with your equivalents. PREFIX should be whatever you used when configuring Qt above. Now we're ready to cross compile. First, for libffi:


</code><br />git clone git://github.com/atgreen/libffi.git<br />cd libffi<br />./configure —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX<br />make<br />sudo make install<br /><code>
<code lang="bash">
git clone git://github.com/atgreen/libffi.git
cd libffi
./configure —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX
make
sudo make install
</code>


Unfortunately this produces a pkg-config file that has a redundant prefix. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/libffi.pc and remove the $RPI_SYSROOT part from the "prefix=" line, leaving it just as $PREFIX.
Unfortunately this produces a pkg-config file that has a redundant prefix. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/libffi.pc and remove the $RPI_SYSROOT part from the "prefix=" line, leaving it just as $PREFIX.
Line 148: Line 305:
Make sure to run these in a clean environment, not the cross compile environment we set up earlier. You may copy wayland-scanner to anywhere as long as it ends up in the $PATH later on.
Make sure to run these in a clean environment, not the cross compile environment we set up earlier. You may copy wayland-scanner to anywhere as long as it ends up in the $PATH later on.


</code><br />git clone git://anongit.freedesktop.org/wayland/wayland<br />cd wayland<br />git checkout $WAYLAND_SHA1<br />./autogen.sh<br />make<br />cp src/wayland-scanner $QTDIR/bin<br /><code>
<code lang="bash">
git clone git://anongit.freedesktop.org/wayland/wayland
cd wayland
git checkout $WAYLAND_SHA1
./autogen.sh
make
cp src/wayland-scanner $QTDIR/bin
</code>


Now to build wayland for the target. Again make sure the cross compile environment above is sourced. This time we disable the scanner, as we don't want it as an arm binary.
Now to build wayland for the target. Again make sure the cross compile environment above is sourced. This time we disable the scanner, as we don't want it as an arm binary.


</code><br />cd wayland<br />git clean -dxf<br />./autogen.sh —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX —disable-scanner<br />make<br />sudo make install<br /><code>
<code lang="bash">
cd wayland
git clean -dxf
./autogen.sh —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX —disable-scanner
make
sudo make install
</code>


Again we need to fix some pkgconfig files. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/wayland-client.pc and wayland-server.pc as for libffi.pc above, removing the $RPI_SYSROOT from the prefix variable. This is required for qtwayland to successfully build.
Again we need to fix some pkgconfig files. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/wayland-client.pc and wayland-server.pc as for libffi.pc above, removing the $RPI_SYSROOT from the prefix variable. This is required for qtwayland to successfully build.
Line 158: Line 328:
Now we get to, as we say in Norway, the raisin in the sausage, namely qtwayland. Since we have a hardware integration / buffer sharing mechanism utilizing eglCreateGlobalImageBRCM, we configure it with brcm_egl. This means both raster and opengl based clients will be able to run. The -lffi addition is necessary for some reason I haven't figured out.
Now we get to, as we say in Norway, the raisin in the sausage, namely qtwayland. Since we have a hardware integration / buffer sharing mechanism utilizing eglCreateGlobalImageBRCM, we configure it with brcm_egl. This means both raster and opengl based clients will be able to run. The -lffi addition is necessary for some reason I haven't figured out.


</code><br />export QT_WAYLAND_GL_CONFIG=brcm_egl<br />cd qtwayland<br />cd src<br />qmake<br />make &amp;&amp; sudo make install<br />cd ../examples/<br />qmake<br />make &amp;&amp; sudo make install<br /><code>
<code lang="bash">
export QT_WAYLAND_GL_CONFIG=brcm_egl
cd qtwayland
cd src
qmake
make && sudo make install
cd ../examples/
qmake
make && sudo make install
</code>


I ran into some issues where make failed due to requiring sudo permissions, but following the steps above should give you a working install.
I ran into some issues where make failed due to requiring sudo permissions, but following the steps above should give you a working install.


Now it's time to test the stuff we've built. I typically do "rsync -av $RPI_SYSROOT/$PREFIX root</code>rpi:$PREFIX", but whatever floats your boat.
Now it's time to test the stuff we've built. I typically do "rsync -av $RPI_SYSROOT/$PREFIX root@rpi:$PREFIX", but whatever floats your boat.


ssh into the device, and go to the examples/qtwayland/qml-compositor folder, then do as follows:
ssh into the device, and go to the examples/qtwayland/qml-compositor folder, then do as follows:


<code><br />export XDG_RUNTIME_DIR=/tmp<br />./qml-compositor -platform eglfs<br /></code>
<code lang="bash">
export XDG_RUNTIME_DIR=/tmp
./qml-compositor -platform eglfs
</code>


The XDG_RUNTIME_DIR is where the wayland socket ends up. You should now have the qml-compositor running in all its glory, time to add some clients.
The XDG_RUNTIME_DIR is where the wayland socket ends up. You should now have the qml-compositor running in all its glory, time to add some clients.
Line 172: Line 354:
If you've built and installed wiggly from qtbase/examples/widgets/wiggly, here's how to run it:
If you've built and installed wiggly from qtbase/examples/widgets/wiggly, here's how to run it:


<code><br />export XDG_RUNTIME_DIR=/tmp<br />./wiggly -platform wayland&amp;amp;<br />./wiggly -platform wayland&amp;amp;<br /></code>
<code lang="bash">
export XDG_RUNTIME_DIR=/tmp
./wiggly -platform wayland&
./wiggly -platform wayland&
</code>


This launches two beautiful wiggly instances as wayland clients. You may also run "qmlscene -platform wayland" on any QML 2 example, or any other Qt OpenGL / QML 2 based application. Bon Appétit!
This launches two beautiful wiggly instances as wayland clients. You may also run "qmlscene -platform wayland" on any QML 2 example, or any other Qt OpenGL / QML 2 based application. Bon Appétit!

Latest revision as of 07:11, 12 January 2016

En Ar Bg De El Es Fa Fi Fr Hi Hu It Ja Kn Ko Ms Nl Pl Pt Ru Sq Th Tr Uk Zh

Raspberry Pi (BCM2835): Device Information

Architecture ARMv6
CPU ARM11
RAM 256MB OR 512MB since October 2012 (shared with GPU)
GPU VideoCore IV
OpenGL OpenGL ES 2.0
Multimedia OpenMax IL 1.1.2
Qt 5.0 (eglfs/QPA) Supported, with OpenGL ES 2.0

Qt 5 port functional state (against Raspbian Wheezy (primary reference platform))

Feature State Additional info
Hardware accelerated cursor Done upstream
Wayland support Done upstream
Hardware decoding of images To Do
Scenegraph tailoring To Do
HardFP support Done Requires v8 patch
Qt Multimedia Done Requires gst-omx
Webkit integration To Do webgl, tex mapper

Additional information

  • "The Raspberry Pi is a credit-card sized computer that plugs into your TV and a keyboard. It’s a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video. We want to see it being used by kids all over the world to learn programming."

Hardware Details

Low end ARM11 CPU running at ~700 BogoMIPS.
VideoCore IV GPU is capable of running QtQuick2/SceneGraph at high resolutions.
Both CPU and GPU share main memory.

Linux Platform

If you are not interested in building everything yourself then consider:

  • the pre-built Raspbian snapshots

The Raspberry Pi Foundation provides a few different distributions which can be downloaded here

Please note: Not all platforms are created equal: The Raspbian Wheezy image is a very functional distro with piping hot firmware and good support on the OS vendor side, so that is the first class citizen when following these instructions. Deviating from its usage will probably introduce additional complexity and will carry you away from the primary testing platform

Raspbian "Wheezy" image (First class citizen)

My home rolled Linaro (crosstool-ng generated) toolchain

Since the Linaro toolchain is an order of magnitude more charismatic when cross compiling, you will probably want to be reading our notes on using it. Since I have to bleed profusely in order to get a functioning Linaro toolchain on my Arch install, I have provided it here

gcc-4.7-linaro-rpi-gnueabihf

Required changes (Rolling, should be empty)

v8 ARMv6 hardfp support:

https://codereview.qt.io/27256

Undo crippling GL defaults, possibly stemming from my incorrect indication in the Pi hooks that the GLESv2 impl support GL buffer queuing. One thing is for certain, the consistent timer below is not something you want in affect on your Pi. (On the stage at Qt CS, infront of a crowd, one of whom is whistling the Kill Bill theme)

[sirspudd@bb|:qt5/qtdeclarative]$ git show
commit 82c9f3187ce79e1aef57479b0cc7b7274c0bd85e
Author: Donald Carr <donald.carr@nokia.com>
Date: Wed Aug 8 09:52:34 2012 0000

Disable fixed animation step before it disables me diff —git a/src/quick/items/qquickwindowmanager.cpp
b/src/quick/items/qquickwindowmanager.cpp
index 3cced7a..90c2dc9 100644
— a/src/quick/items/qquickwindowmanager.cpp
++++ b/src/quick/items/qquickwindowmanager.cpp

137,16 +137,6

QQuickWindowManager *QQuickWindowManager::instance()

 else if (qmlForceThreadedRenderer())
 fancy = true;

- // Enable fixed animation steps…
- QByteArray fixed = qgetenv("QML_FIXED_ANIMATION_STEP");
- bool fixedAnimationSteps = bufferQueuing;
- if (fixed == "no")
- fixedAnimationSteps = false;
- else if (fixed.length())
- fixedAnimationSteps = true;
- if (fixedAnimationSteps)
- QUnifiedTimer::instance(true)->setConsistentTiming(true);
-
 if (!theInstance) {
 theInstance = fancy
 ? (QQuickWindowManager''') new QQuickRenderThreadSingleContextWindowManager

Toolchain considerations

This is bleeding edge and carries the latest snapshot of the firmware. Anyone doing active development against the BCM libraries will probably want to be living in this realm. Targeting this system requires a Linaro (Raspbian multiarch cognizant) compiler. Without this, you will find yourself scrambling to indicate that relevant libraries are lurking in $lib/arm-linux-gnueabi paths. If you know how to make this play nice, please feel free to edumicate me (Donald Carr) on the niceties.

I built my toolchain by following these instructions:

https://launchpadlibrarian.net/110971284/README.txt

and an Ubuntu 10.04 schroot. There is no point fighting it, before stooping to this behavior, I was facing spurious build failures all over the show.

Known issues

For qtjsbackend the following patch is needed: usingHardFloat automatic detection faux pas

Arch Linux

Arch has been tested and sommer (just) works. The firmware tends to be bleeding edge, so the Wheezy images firmware notes will possibly be of relevance.

Buildroot

One of our engineers has been investing time in a home rolled hardfp distribution based on Buildroot. The recipe is available here:

https://github.com/nezticle/RaspberryPi-BuildRoot.git

Given the preponderance of hardfp performance over its register ignorant peers, this will be useful in eking every last drop of performance out of the hardware.

A more recent approach to build a basic Qt5 development environment and bootable Linux distribution with Buildroot is here:

https://github.com/pbouda/buildroot-qt-dev

At the moment, this compiles Qt5 with multimedia module, OpenGL and SSL support and gives you access to the running Raspberry via SSH. You will also get a full cross-compilation environment to build your Qt apps and libraries for the Raspberry. More information is available in the README on GitHub.

Building Qt from scratch

Helper scripts

These scripts will be cited at relevant sections and are intended as a rough guide as to the automation of labourious tasks.

Use when prompted at your own discretion.

We generate the nightly Qt snapshots using the following "scripts":git://gitorious.org/packaging-scripts/packaging-scripts.git

These are filthy and exist purely to get the job done with as little effort/time expenditure on our part possible.

Adjusting the root filesystem for development

Qt 5 has a hard dependency on libudev for hot pluggable hardware detection/support. This mandates the installation of the libudev-devel package. (Or the filthy use of an arbitrary libudev.h and the creation of a libudev.so symlink, which is how we roll in the trenches(When life gives you mustard gas, eat franks!)) (This consideration will fall away with the release of the next Raspbian reference image)

In order to use the root filesystem from the SD card, mount the rootfs partition as a loopback device. The offset for mount can change with different images, please query the partition offset with fdisk (see http://www.syslinux.org/wiki/index.php/Hard_disk_images ).

eg (or the official Raspbian image(s)):

$ #mount -o loop,offset=62914560 /opt/stores/broadcom/raspberry-pi/2012-07-15-wheezy-raspbian.img /mnt/rasp-pi-rootfs

In order to be able to use the —sysroot option during the Qt build process, you have to resolve all absolute library links inside the mounted rootfs, but replacing full qualified symlinks with relative ones, otherwise the linker will pickup your host libraries and promptly barf.

The magical fixQualifiedLibraryPaths script in the cross-compile-tools repo above should go some distance to easing this chore. Simply pass it the rootfs and the compiler and it will attempt to fix the symlinks accordingly.

You will also need to create several missing symlinks, notably: libstdc.so (/usr/lib) and libgcc_s.so (/lib) (and any other friends of the forest who rear their frothy maws with the earnest intent to munch on you)

This might seem hacky but it is important that we pass the reference Raspbian image to the code sourcery toolchain to ensure that we are linking against the right system libraries, and not toolchain libs in conflict with the libraries on the actual device.

Additional packages

The additional packages extend the scope of Qt functionality and are optional in as much as the base Raspbian image has all the development files required for GLESv2 and input support.

Additional packages are documented here along with the associated ramifications

I personally install it on the device, shuttle across the .deb, unarchive it and unpack the data.tar.gz over the original mounted image.

Qt 5 on the Raspberry Pi (BCM2835)

Installing Qt 5 nightlies from the repo

The links are no longer valid and redirect to a site which will try to install malware so they have been removed for safety purposes. If there are new locations for the packages, then please remove this line when updating.

We are generating Qt 5 nightlies for the Raspberry PI reference Raspbian image, and these are available here:

(link redacted)

this is not currently shipped as part of the Raspbian reference image, and hence

you have to add:

deb (link redacted) unstable main

to your source list and then you need to do to get piping hot Qt 5 action in your life is:

apt-get update apt-get install qt50-snapshot

We generate these packages using this set of scripts

Building Qt

This will build everything in-source, if you want to build out-of-source execute configure and qmake for additional modules from within a separate empty folder.

If you use either squeeze or archlinux, you need to provide the distro name as a device option for the configure script:

-device-option DISTRO=[squeeze,arch]

qtbase

$ cd <qtbase>
$ ./configure -prefix <your prefix> -release  -device linux-rasp-pi-g''+ -make libs  -device-option CROSS_COMPILE=<your toolchain path>
/bin/arm-none-linux-gnueabi-
 -sysroot <your sysroot path>
$ make install

Other modules

Depending on your needs/desires you can now use your freshly minted qmake to (shadow) build whatever Qt 5 modules you require, using the following approach:

$ cd <qt_module_dir>
$ <your prefix>/bin/qmake
$ make
$ make install

At a bare minimum we would recommend: qtjsbackend and qtdeclarative

Runtime information

We would like to get Wayland up and running on the Pi but this requires modifications to EGL that need to be provided by the chipset vendor, Broadcom in this case. We therefore explicit set the default plugin to be the eglfs plugin which is ideal for single process use cases like set top boxes. (This can be overridden by explicitly using -platform if you see fit).

Building and running qtwayland (legacy)

Please note: The current Qt Wayland sha1 is shipped as part of the Wheezy image and simply building the qtwayland module against the Wheezy sysroot should succeed. These instructions persist for the sake of anyone strapped to Raspbian Squeeze or any other distribution.

These instructions cover how to get qtwayland up and running.

First, clone and build qtjsbackend and qtdeclarative per the instructions above.

Now we're going to have to cross compile libffi and wayland. First we need to set up our environment with the following environment variables:

export RPI_SYSROOT=/mnt/rasp-pi-rootfs
export TOOLCHAIN=$HOME/raspberry/arm-2011.09
export QTDIR=$HOME/raspberry/qt5/qtbase
export PATH=$QTDIR/bin:$TOOLCHAIN/bin:$PATH
export PREFIX=/opt/myqt
export PKG_CONFIG_PATH="$RPI_SYSROOT/usr/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/lib/pkgconfig:$RPI_SYSROOT/$PREFIX/share/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="$RPI_SYSROOT"
export PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
export PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
export CPP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-cpp
export CC=$TOOLCHAIN/bin/arm-none-linux-gnueabi-gcc
export CXX=$TOOLCHAIN/bin/arm-none-linux-gnueabi-g++
export CFLAGS="—sysroot=$RPI_SYSROOT"
export CXXFLAGS="—sysroot=$RPI_SYSROOT"
export CPPFLAGS="—sysroot=$RPI_SYSROOT"
export LD=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ld
export LDFLAGS="—sysroot=$RPI_SYSROOT"
export AS=$TOOLCHAIN/bin/arm-none-linux-gnueabi-as
export STRIP=$TOOLCHAIN/bin/arm-none-linux-gnueabi-strip
export AR=$TOOLCHAIN/bin/arm-none-linux-gnueabi-ar

Make sure to replace the RPI_SYSROOT, TOOLCHAIN, and QTDIR variables with your equivalents. PREFIX should be whatever you used when configuring Qt above. Now we're ready to cross compile. First, for libffi:

git clone git://github.com/atgreen/libffi.git
cd libffi
./configure —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX
make
sudo make install

Unfortunately this produces a pkg-config file that has a redundant prefix. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/libffi.pc and remove the $RPI_SYSROOT part from the "prefix=" line, leaving it just as $PREFIX.

As for wayland, we first need to build it for the host to get the wayland-scanner binary which reads wayland extension .xml's and produces C interfaces. You might need to install libffi-dev and libexpat-dev on your host as well for this. You also need to set WAYLAND_SHA1 according to the wayland_sha1.txt in the qtwayland repo, so that we get a compatible version.

Make sure to run these in a clean environment, not the cross compile environment we set up earlier. You may copy wayland-scanner to anywhere as long as it ends up in the $PATH later on.

git clone git://anongit.freedesktop.org/wayland/wayland
cd wayland
git checkout $WAYLAND_SHA1
./autogen.sh
make
cp src/wayland-scanner $QTDIR/bin

Now to build wayland for the target. Again make sure the cross compile environment above is sourced. This time we disable the scanner, as we don't want it as an arm binary.

cd wayland
git clean -dxf
./autogen.sh —host=arm-linux —prefix=$RPI_SYSROOT$PREFIX —disable-scanner
make
sudo make install

Again we need to fix some pkgconfig files. Edit $RPI_SYSROOT/$PREFIX/lib/pkgconfig/wayland-client.pc and wayland-server.pc as for libffi.pc above, removing the $RPI_SYSROOT from the prefix variable. This is required for qtwayland to successfully build.

Now we get to, as we say in Norway, the raisin in the sausage, namely qtwayland. Since we have a hardware integration / buffer sharing mechanism utilizing eglCreateGlobalImageBRCM, we configure it with brcm_egl. This means both raster and opengl based clients will be able to run. The -lffi addition is necessary for some reason I haven't figured out.

export QT_WAYLAND_GL_CONFIG=brcm_egl
cd qtwayland
cd src
qmake
make && sudo make install
cd ../examples/
qmake
make && sudo make install

I ran into some issues where make failed due to requiring sudo permissions, but following the steps above should give you a working install.

Now it's time to test the stuff we've built. I typically do "rsync -av $RPI_SYSROOT/$PREFIX root@rpi:$PREFIX", but whatever floats your boat.

ssh into the device, and go to the examples/qtwayland/qml-compositor folder, then do as follows:

export XDG_RUNTIME_DIR=/tmp
./qml-compositor -platform eglfs

The XDG_RUNTIME_DIR is where the wayland socket ends up. You should now have the qml-compositor running in all its glory, time to add some clients.

If you've built and installed wiggly from qtbase/examples/widgets/wiggly, here's how to run it:

export XDG_RUNTIME_DIR=/tmp
./wiggly -platform wayland&
./wiggly -platform wayland&

This launches two beautiful wiggly instances as wayland clients. You may also run "qmlscene -platform wayland" on any QML 2 example, or any other Qt OpenGL / QML 2 based application. Bon Appétit!

Building and running Webkit (prone to drowning your pony in a hazard of tentacles)

Wheezy

  • Install the additional dependencies noted above
  • explicitly export PKG_CONFIG_LIBDIR (eg. export PKG_CONFIG_LIBDIR=/mnt/rasp-pi-rootfs/usr/lib/pkgconfig) as Webkit will use pkg-config
  • ./Tools/Scripts/build-webkit —qt —release —no-webgl

Qt 4 on the Raspberry Pi (BCM2835)

Qt 4 runs on the Pi with minor modification and using the following spec:

https://gitorious.org/qt-platform-mkspecs/qt-platform-mkspecs/trees/master/4.8/linux-rasp-pi-g++