Cross compile Linux for ARM using LLVM/clang on Arch Linux

LLVMLinux project logo

LLVMLinux project logo

The LLVMLinux team made quite some progress in enabling LLVM/clang to build the Linux kernel. There has also been a talk at the Collaboration Summit 2015 in Santa Rosa (slides). So I thought, give it a try and compile a kernel for my ARM based board of choice. The upstream Linux kernel is not yet ready to be built using LLVM/clang, some patches are still required. Therefor I used the kernel from the LLVMLinux git server.

The nice thing about LLVM/clang is that it supports multiple targets. The binaries provided by the Arch repositories support several ARM targets:

$ pacman -S clang
$ llc --version
 LLVM version 3.5.1
 Optimized build.
 Built Jan 14 2015 (03:18:15).
 Default target: x86_64-unknown-linux-gnu
 Host CPU: core-avx-i

 Registered Targets:
 aarch64 - AArch64 (little endian)
 aarch64_be - AArch64 (big endian)
 arm - ARM
 arm64 - AArch64 (little endian)
 arm64_be - AArch64 (big endian)
 armeb - ARM (big endian)

Read more »

Starting BuildBot using systemd Service unit

This post shows how to create Service unit files for systemd which let start and restart BuildBot on Linux distributions using systemd. This unit files depend on a working VirtualEnv installation of BuildBot in the /srv/buildbot directory. It also runs BuildBut with the user/group “buildbot”. Two unit files are necessary to start the master and slave instance respectively. Instead of using the buildbot/buildslave commands, the twistd binary is executed directly in foreground. twistd is an application/service framework for Python, which BuildBot makes use of.


Description=BuildBot master service

Environment="VIRTUAL_ENV=/srv/buildbot/sandbox" "PATH=/srv/buildbot/sandbox/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
ExecStart=/srv/buildbot/sandbox/bin/twistd \
          --nodaemon --no_save --pidfile= --python=master/buildbot.tac


buildbot-slave.service Read more »

Fixing a broken Git repository

After having several hard kernel crashes, some of my files ended up empty on my disk. I then got errors like:

error: object file .git/objects/81/b43db0dadcafe18eef75c60c57cc496d523d83 is empty
error: object file .git/objects/fb/9b5b3daa56c7833be66f0eaac2b5a906474627 is empty

I can recommend this Wiki page on which tells how recovery basically should be done. This post shows some of those steps a bit more “hands-on”. I started with moving this corrupt (empty) object away, and then got this message when doing some git operations:

fatal: unable to read 81b43db0dadcafe18eef75c60c57cc496d523d83

Read more »

Make it two: Tuxes on one SoC

Vybrid SoC

Vybrid SoC running two Linux instances

In earlier posts I already wrote about Vybrid, a Freescale ARM SoC consisting of one Cortex-A5 and one Cortex-M4 (microcontroller) CPU. Normally, one would run a Firmware on the Cortex-M4 and Linux on the Cortex-A5 (which is quite well supported by contemporary kernels). But since we have two CPU’s with architectures supported by Linux (ARMv7-A and ARMv7-M), so why not running two independent Linux kernels in one SoC?

Read more »

libopencm3 bare-metal Vybrid examples

As I wrote yesterday, I’m currently hacking on libopencm3 for bare-metal Vybrid development. This effort advanced quite a bit, the GitHub repository now contains code to use the UART and GPIOs from the Cortex-M4.

The Hardware I use consists of a Toradex Colibri VF61 on a Iris Carrier Board. The code should also run fine on Freescales Vybrid Tower board (TWR-VF65GS10). Currently I use the preinstalled Linux BSP consisting of U-Boot, Linux 3.0 Kernel and a OpenEmbedded based root file system. Read more »

Vybrid bare-metal fun

Freescale Vybrid SoC

Freescale Vybrid SoC

In preparation to my talk at BetterEmbedded I had a deeper look into the second core of Freescales Vybrid VF6xx SoC. I wanted to create a bare-metal test firmware for the Cortex-M4 processor. As the Cortex-M4 is a companion of the Cotex-A5 in the same SoC, its boot process is different compared to a normal Microcontroller (e.g. STM32F4 or similar). Microcontroller usually boot directly from memory mapped NOR flash.

ARM SoCs in general contain a small, internal boot ROM where the cores start from. This boot ROM then tries to boot from different devices, such as NAND or SD-Card. For the Vybrid SoCs normally the Cotex-A5 is the boot CPU, which in my case is running Linux from NAND (the Timesys BSP). On startup, the Cortex-M4 is in an unclocked state and need to be started from the Linux side. With the Timesys BSP, a Vybrid specific kernel module called mcc is provided. This kernel module not only implements the Multi-Core Communication library but also allows to load an image into RAM and start the secondary CPU. The utility mqxboot allows to access this functionality from userspace. This components implement the boot procedure for the Cortex-M4 described in chapter 19.11, “Running Secondary Core”, of the Vybrid Reference Manaul.

The secondary core has not access to a NOR storage as it would have in a microcontroller. Instead the firmware runs completely from RAM. Read more »

Ubuntu: AD authentication after system upgrade

After a System upgrade from Ubuntu Precise Pangolin to Trusty Tahr I wasn’t able to connect to the server using SMB. The server is part of a active directory. Reading the documentation through, I figured out that wbinfo worked flawless, but the user was not found when using id.

$ wbinfo -u

$ id my.user
id: my.user: no such user

/etc/nsswitch.conf need be configured right (winbind must be configured), but it was in my case:

passwd: compat winbind
group: compat winbind
shadow: compat

Using strace, I figured out that wasn’t found by id. In the end, the solution was easy as that:

$ sudo apt-get install libnss-winbind
$ sudo service winbind restart
winbind stop/waiting
winbind start/running, process 3399
$ id my.user
uid=10006(my.user) gid=10002(domain user) groups=...

git send-email and SMTP with SSL

On Fedora 20, when using git send-email I always got this error:

Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: encryption=ssl port=465 at /usr/libexec/git-core/git-send-email line 1255.

Even using the suggested parameter –smtp-debug 1 did not help, I get the exactly same output with that parameter. In the end, it turned out the self-signed certificate is not accepted right away (which of course is good) but lead to no specific error message (which is not so good). However, using the parameter –smtp-ssl-cert-path “” disables certificate verification, which already allowed me to send the e-mail.

However, one want to install the certificate in a way that its always accepted. git send-email relies on OpenSSL certificate database. In order to add an additional CA certificate one has to add it to /etc/pki/tls/certs and create a symlink to its hash.

$ curl -o myroot.crt
$ openssl x509 -noout -in myroot.crt -fingerprint

If you are paranoid, and you should be nowadays, verify your fingerprint at this point 🙂

# mv myroot.crt /etc/pki/tls/certs
# cd /etc/pki/tls/certs
# openssl x509 -in myroot.crt -out myroot.pem -outform PEM
# ln -s myroot.pem `openssl x509 -hash -noout -in myroot.pem`.0

This works also for Arch Linux, however the OpenSSL certificates are located under /etc/ssl/certs/. Also for SMTP with SSL to work, the following packages are needed

pacman -S perl-net-smtp-ssl perl-authen-sasl

Enable dark Theme in Gnome Terminal 3.12

Use dark theme in Gnome 3.12

Use dark theme in Gnome 3.12

The new Gnome Terminal does not enable the dark theme automatically by itself, you need to explicitly enable it using the “Use dark theme variant” option. Its documented in the official Gnome help, but in there “Profile Preference” is mentioned, which is wrong! In Gnome 3.12 that option is under “Edit => Preference”!

EXSYS USB-to-serial Adapter and stable device names

EXSYS provides multi serial-port adapters connected over USB. I recently ordered the 8-port device EX-1338HMV. From a hardware perspective, the device is made very solid, ready for industrial use. The connectors, USB as well as power, are secured by additional screws, so tensions on the cables should be an issue.

As soon as I connected the USB cable, the serial ports worked without using any external power adapter, however depending how much the connected device actually draw, external power might be needed.

The device has FTDI chips inside, which was the reason I opted for this solution. FTDI chips have a good reputation in providing high quality USB-to-serial adapters with high accuracy. The FTDI chips are connected through two internal USB hubs, as can be shown using lsusb:

/: Bus 03.Port 1: Dev 1,, Driver=xhci_hcd/4p, 480M
   |__ Port 1: Dev 14, If 0,, Driver=hub/7p, 480M
   |__ Port 1: Dev 15, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 2: Dev 16, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 3: Dev 17, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 4: Dev 18, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 5: Dev 19, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 6: Dev 20, If 0, Specific Class, Driver=ftdi_sio, 12M
   |__ Port 7: Dev 21, If 0,, Driver=hub/4p, 480M
       |__ Port 1: Dev 22, If 0, Specific Class, Driver=ftdi_sio, 12M
       |__ Port 2: Dev 23, If 0, Specific Class, Driver=ftdi_sio, 12M

Read more »