Booting a recent kernel on the APQ8060 Qualcomm DragonBoard

My DragonBoard

The original APQ8060 DragonBoard, also the first DragonBoard ever.

Most recent test was done with kernel v4.20-rc4 on 2018-11-29. MMC/SD, GPIO, LEDs, ethernet and all sensors are working.


I got this board from some Qualcomm guys at the Embedded Systems Conference "Design West" in San Jose in april 2012. The board was pushed as the first Qualcomm attempt for a developer board for their platforms around september 2011, as they contracted to BSQUARE to provide support and education for this board. (See this blog post from Qualcomm's Brian Spencer, or this video from Charbax, there is also an roadmap document showing a few DragonBoards.) Here is some idiomatic terminology you need:


This board only talks the fastboot boot protocol. (No U-Boot or such.) So you need to get this tool. On Fedora, simply:

dnf -y install android-tools

This will get you the command-line tool fastboot.

To get the board into fastboot mode so that a new kernel (or image, or whatever) can be uploaded to it, remove the battery connector and DC plug so that the board is completely unpowered, then press and hold down the 5 key on the keypad while inserting the DC plug. At this point the board is in the state where you can run the fastboot command line.

Since this manouver is tricky I have simply mounted a common light switch on the power cable to my DragonBoard. This works like a charm: flick it off, hold down 5 flick it on. We're in fastboot mode.

Boot a mainline Linux kernel

With some hands-on a mainline Linux kernel can actually boot to prompt on the Dragonboard since v3.14-rc1. Some bugs were introduced with the switch to mach-qcom in kernel v3.15 but should be fixed in kernel v3.17.

SOLVED IN v4.9-rc1 no more ugly fixes needed. On my Dragonboard there was a problem with the ATAGs passed to the kernel: these indicate that the first memory area is at 0x40200000-0x42dfffff but Linux needs to boot from an even memory boundary, 0x40200000 will not work. For this reason you need to apply this ugly patch (older version for mach-msm)that adjusts the first ATAG to claim memory 0x40000000-0x42dfffff instead. I don't know if newer little kernels (the thing that runs fastboot) are fixed in this regard.

To compile a fresh APQ8060 DragonBoard kernel you first need a cross compiler such as the Linaro GCC toolchain. Then you can use my makefile and my rootfs CPIO image - put this in your $HOME directory (in case you're interested that was generated using this script) in the main Linux source tree like this:

linux$ make -f apq8060.mak config && make -f apq8060.mak build

Here are pre-compiled images that you can use and test if you like:

So to boot a mainline kernel all you need is to replace the boot.img-zImage with something freshly compiled. However the TTY name is also changed in mainline from ttyHSL to ttyMSM so the parameter needs changing. Actually, with a mainline zImage kernel all you need is:

fastboot --base 40200000 --cmdline "console=ttyMSM0,115200,n8" boot zImage

(Elder versions of fastboot substitute -b for --base and -c for --cmdline.) After this your board should boot to prompt on the serial port.


Here is the device tree for the APQ8060 board in the upstream Linux kernel. You can see all hardware that has been properly documented and has corresponding Linux drivers. It includes the MSM8660 SoC device tree which defines all the low-level SoC devices.

Kernel TODO list

The kernel efforts are based on the vendor tree, currently a v3.4 kernel. It is very unclear if Qualcomm will ever attempt to forward-port this kernel tree to newer kernels than v3.4, especially for APQ8060/MSM8660. You can clone the vendor tree like this:

  git clone git:// linux-msm
  cd linux-msm
  git checkout -b android-msm-3.4 refs/heads/q3.4/android-msm-3.4

While that is happening or not happening, I am sometimes working with the upstream support for this chipset according to the TODO list:

EEPROM contents

The board has an Atmel AT24c128 16KiB EEPROM which according to the manual is used for "device ID". When you extract the contents over I2C with a simple dd if=/sys/bus/nvmem/devices/0-00520/nvmem of=/eeprom.bin and look at it in a hex editor it looks like this:

DragonBoard EEPROM dump

The rest of the data is just 0xff ad nauseam.

According to the Internetz "CDT" means Configuration Data Table and the information here means:

Split the supplied boot image and boot the parts

There are various tools for peeling apart the supplied boot.img into its constituents. The one that finally worked for me was named unpackbootimg, and produced a number of files, most notably the kernel zImage and the ramdisk. When you have these parts the following magic boots it:

fastboot -b 40200000 -c "console=ttyHSL0,115200,n8 androidboot.hardware=qcom" -p 2048 boot boot.img-zImage boot.img-ramdisk.gz

Building all of Android or just the stock kernel

This is pretty painful.