Setting up a Pandaboard for KWin development

The Pandaboard is a nice little ARM powered device which is meant for development and suited for example to test KWin on real OpenGL ES hardware. This weekend I decided to set it up again, I had done it before, I had installed KWin on the PI, so I’m not a complete NOOB for ARM hardware. I wanted to test a few things and see how the latest changes to master do on a non x86 architecture.

I got the memo about Linux is for normal users and not for LEET, but I do not understand why it has to be so difficult to setup a device which is meant for development. In the past it was as simple as dd an image to an SD-card, plug it in and done. Well those times are over.

My requirement for a base distributions are rather small:

  • Up to date kdelibs, because compiling is slow on the device
  • Working drivers for GL hardware

With this combination we can rule out most distributions like for example Debian (issues with both) or openSUSE (no drivers). I decided to try Linaro 13.02 which offers an image for Pandaboard and is Ubuntu 12.10 based, which means we can easily install KDE packages.

Linaro is still rather simple: dd to SD card, plug in and go. Just that you don’t get any output on the screen. I already thought my Pandaboard was broken. What’s a little bit tricky is that the Pandaboard has two HDMI connectors (one as HDMI, one as DVI) and at least openSUSE reports that only the real HDMI works. But with Linaro I did not get anything on either screen or TV.

So I had to connect to the Serial port to get some output. And look there: it boots. Once I was logged in I was able to figure out that the system is pretty basic, e.g. no X installed. But even after installing X I did not get anything on the screen: it complained about missing /dev/fb0. That was then the point where I considered trying a different distribution. (Search did not help).

Next choice was Kubuntu. This also used to be rather simple: dd to SD card. Downloaded daily build of 13.04, dd to SD card, plugged in and screen turns on. But instead of starting the system, the installer is started. Well since 12.10 you need to install. Obviously the system is not able to install to the SD card which is plugged in. So I got an USB stick, dd to stick, plugged in and nothing. The pandaboard doesn’t boot from USB stick. Now it got difficult: search for a second SD card. Found one, dd image to the second card, moved the first SD card to a card reader, plugged everything in and installed to the SD card at the card reader.

After installation, I swapped the SD cards, plugged in and nothing. System doesn’t boot. Well maybe the system expects at a different device, so I plugged the card reader in again, tried to boot and nothing.

OK, I installed a daily built of an unreleased version, so maybe I should try 12.10. Not so up to date kdelibs, but probably good enough for KWin. Did the same procedure again, installed and doesn’t boot.

Now what? I could try a base Ubuntu instead of Kubuntu. But as the installer is to my knowledge shared I do not expect that it will work. And also I’m too scared that Ubuntu will come without drivers and with Compiz. I don’t want llvmpipe on the desktop, I definitely don’t want llvmpipe on ARM. And I had seen Compiz with drivers on the pandaboard – so no that’s too scary.

While searching for a solution to the problems I was facing, I also stumbled over Ubuntu Core. It didn’t look like anything I want to try, but at this stage I was at the point to decide whether I use a distro like openSUSE without drivers or try something which might give me drivers.

Now with the linked wiki page I would not have been able to install it, because it’s an interesting system. Luckily the omappedia contains an instruction. Basically the system comes with nothing. No editor, no network, no console, no way to log in, just nothing. But even with the introduction it gets interesting. For example it links a PPA which is not available for quantal or raring. Do I not need it anymore? Will my system be broken afterwards? (it turned out that the packages are nowadays included).

The most interesting aspects were that it doesn’t start with networking enabled. The wiki page lists a command to start networking, but I did not manually adjust resolv.conf because I thought DHCP would set it. Well it didn’t and in the running system you cannot change it because there’s no editor.

After quite some fiddling with the system I finally was at a state where startx succeeded and loaded into the KDE Plasma desktop. Looked good even compositing working OOTB (of course only XRender). So I enabled my keyboard/mouse combo and nothing. Searching for this problem recommended to check whether the usb module is loaded. Yeah, come on, I’m not stupid. Well better be sure:

lsmod | grep usb

nothing. Hmm get’s interesting. Modprobe fails, depmod fails – /lib/modules/ does not exist. The linux image was not installed. That was the point where I decided to install full kubuntu-desktop instead of just kde-workspace. The device is slow, it took a few hours.

By now I have the system running and KWin master built from source (took another few hours). It looks like it has drivers for the system. At least a shipped demo application for OpenGL ES 1.1 is working – the demo application for OpenGL ES 2.0 is failing because it has a hard coded path to the shader file. Installing the driver was also fun, it comes as a DKMS package and the first installation try failed with a crashing g++. That’s something I already knew from my last try with the pandaboard. Gcc might crash, restarting solves it.

Unfortunately I don’t have KWin running on OpenGL ES yet on this hardware. It fails somewhere in the init buffer configs code. But it was already worth the effort. The code is already extended with much more error checks as I needed to find where exactly it is failing. Also compiling on ARM found a few more C++11 narrowing conversion warnings (floats). Given that we want to enable C++11 for KWin in 4.11 it’s good to know that there is still some work to do on non x86 hardware. Would be nice to get that CI covered.

27 thoughts on “Setting up a Pandaboard for KWin development

  1. As much as I love Linux you always have to be ready to get into troubles, sometimes even with the simplest things and then debug and try to solve the problem an entire day or may be even days.

    1. That’s what you get when get in bed with platforms relying on proprietary drivers. I don’t know when Martin got his PandaBoard, so he might not have a choice back then but what he describes are typical problems of proprietary drivers.

      1. You know an ARM developer device which has working OpenGL ES 2.0 (that is with X) and does not require proprietary drivers? I’m interested. And no the PI neither has free drivers nor working drivers for X.

        1. Well, not a specific board but the free Aredeno driver (snapdragon SoC) seem to make good progress. Since the developer now works full-time for Red Hat, I’m sure it’ll end up in Fedora 19.

    2. I don’t think that’s particularly fair. What he’s doing here is something that’s not even possible on other platforms.

      Essentially he is trying to install a desktop operating system on hardware that has more in common with a smartphone.

      Agreed, it should be easier, but I don’t think comparisons with other platforms really work here.

      Most of my linux machines more or less just work.

  2. I have worked with quite a few embedded boards and other embedded hardware, and it always sucks. Always. I hear that the Raspberry Pi is the least painful currently.
    You can be happy if the driver quality is such that no hardware that you need stops working after a while (was the case for USB ports on the Beagle board for the first 2.5 years of the Beagle’s existence, with HDD and network in use), you don’t need to port patches from some vendor kernel or need to scrape them together from different mailing lists, you don’t need to get a special version of the boot loader from a git branch hosted on a site you’ve never heard of… I have done all of these things.

    1. I also had these kind of problems with embedded linux devices. If the manufacturer doesn’t prepare everything for you … then you are (most of the times) screwed. Also with their help it is possible that you won’t get good results.

      For example there were 2 boards and both of them had CAN peripheral … and the kernels that came with the boards didn’t have a driver for it. Manufacturer did send me some drivers, one was something experimental and for the other board they ported it to from a newer kernel … you might have guessed it … they weren’t very stable…

      And don’t get me started on bringing Qt to another board … I ended up kind of preparing my own “distribution” with some parts mearged from different boards … also not very stable :)

      1. This is the kind of thing we’re trying to address within the Yocto Project / OpenEmbedded. I’m not sure what the current state of the board support package (BSP) for the pandaboard is, but we’re at least trying to avoid the “separate platform for every vendor” problem that has plagued the industry.

    2. yeah the Raspberry Pi is really a pleasure to set up. Unfortunately the drivers do not support X properly, so (not yet) useful for me to hack on KWin ;-)

    1. That’s cool. Thanks for telling me. I might give it a try on another SD card – Mer is quite interesting as it’s also used for Plasma Active. On the other hand it’s RPM based and I have no clue how to setup my system for compiling from source ;-)

      1. We use OBS, with some effort it’s learnable, and is building away & packaging projects from source.

        Mer is so pluggable/scalable, that for me, +having read this blog article, was the easiest to put a working hardware adaptation (which -is- a hard thing essentially, so you want to take complexities and/or constrains/closedness out of the way)

        1. Well, OBS ends up in creating *.rpm, so per each edit of the source a new package has to be built… IMHO for little edits that’s an overkill (and even compiling on the pandaboard could be faster, after the first compilation and with proper build caching of course)

          1. and even compiling on the pandaboard could be faster, after the first compilation and with proper build caching of course

            For KWin I currently need only to edit one file. And then compilation is relatively fast – less than 5 min. Nothing compared to the 3 hours initial building ;-)

            So yes going over OBS is quite some overhead and probably unsuited for my KWin hacking needs.

              1. at the moment I’m on the cost for setting up the cross compile environment vs. compiling on device, still on the device side ;-) I don’t work on it during working hours so I don’t care that it takes long. If I’m just typing in a command once every five minutes while reading a book, it hardly matters.

                1. yes, compiling on device natively would be just another option. So OBS is just a release engineer’s tool really, to setup a working binary env and deps. From then on hacking ensues until maturity :D

                2. For cross compilation, take a look into sb2: https://wiki.merproject.org/wiki/Platform_SDK_and_SB2

                  If you’d like a rather easier alternative, there’s also the (admittedly underdocumented, I should fix that one day) mb script – which basically acts as a wrapper around rsync and rpmbuild to build packages from a live source tree.

                  For instance, if I have a sb2 target called “nemo”, and I’m in ~/code/myproject, and I have a ‘rpm/foo.spec’, then I can run:
                  mb build -t nemo rpm/foo.spec, and it’ll handle rsync of the source tree to the right place (avoiding unnecessary rebuild) and build a package, using the sb2 ‘nemo’ target. You can then scp that directly to device and install/upgrade it.

          2. obs becomes quite fast if you use ccache, which is just a single parameter for “osc build”.

            you can do minor edits inside the build chroot, “osc chroot”, and restart building from there.

      2. You can create a cross-compile package for Icecream and run the build on target hardware while the compile jobs execute on your desktop machine(s). That’s a nice option for somewhat beefy embedded hardware like the Panda.
        See here
        http://linux.die.net/man/7/icecream
        or “man icecream”.

  3. > And also I’m too scared that Ubuntu will come without drivers and with Compiz. I don’t want llvmpipe on the desktop, I definitely don’t want llvmpipe on ARM. And I had seen Compiz with drivers on the pandaboard – so no that’s too scary.

    Its funny – you might expect this to be really slow, but in fact, llvmpipe relatively well here as long as you’re not running at a high resolution. The main problem on both the arm drivers and llvmpipe is the fillrate limitation caused by the full-screen blit on every frame, but there’s not too much we can do about that until the other drivers get buffer_age support like nvidia (but even then it will likely be too late and history will have moved on)

  4. Hey,
    I’m not sure if you’re still interested in kubuntu. On my pandaboard there is something running like Kubuntu 12.10. I’ve created the sdcard with 12.04 and did a distribution upgrade to 12.10. This was not really fast and as far as I remember there have been a few smaller problems during upgrade. But now I’m running kernel version 3.5.0-221-omap4 and kde 4.9.5.
    There have been several problems with the plasma-desktop in every version I’ve tried on the pandaboard. For example, all buttons in the widget add panel do not work. Drivers seems to be there since glmark2-es2 works fine. But I can not play any videos with this version in any player.
    So there are many open issues for a kde developer ;) . Perhaps it’s also possible to upgrade to 13.04 using do-release-upgrade.

Comments are closed.