The iMX53 Quick Start Board has been a mainstay of the Debian armhf port and has been part of LAVA until recently. It's a natural choice for seeing how LAVA and Debian can work together more closely. So, in the first steps to getting my home lab running, I set about restoring two of these boards to LAVA support.</p>

iMX.53 quickstart board

I will be looking into each of the possible boot methods with these boards, but the way to start is with a LAVA master image on an SD card. With the pause in iMX53 development within LAVA, this raises a couple of issues:

  • u-boot on the iMX53 is old and the Linaro image tools have advanced without making allowances for the unsupported mx53loco type.

    • For LAVA, this means that u-boot on the iMX53 does not understand ext4 and although there are guides on updating it, I wanted to stay with the original, at least at the start.

    • Using ext4 will lead to this error:

      mmc0: error 110 whilst initialising SD card
  • iMX53 quick start boards come with a working Ubuntu installation on an SD card but the release is Lucid Lynx 10.04LTS. LAVA has been on Precise Pangolin 12.04LTS for some time.

    • This causes issues with debootstrap which cannot unpack packages from Debian sid due to changes in the compression format inside the .deb files. It is possible to use wheezy and note that lucid, by default, will produce armel. Use `--arch=armhf, then apt-get upgrade and apt-get dist-upgrade to testing and then to sid (not in one single step). Remember to mount proc before starting the upgrade.

LAVA master image on iMX53

The LAVA master image is more recent and can fix these problems. See lava-image-creation - preparing a master image

$ git clone git://
$ cd lava-master-image-scripts

Use patch -p1 to apply this patch (apologies for the line wrapping in the blog):

diff --git a/lava-create-master b/lava-create-master
index 2e1d0e8..a1e6131 100755
--- a/lava-create-master
+++ b/lava-create-master
@@ -366,7 +366,7 @@ make_master() {
         verbose " * Building vanilla image with linaro-media-create..."
         if ! linaro-media-create \
             --dev $LMC_DEV \
-            --rootfs ext4 \
+            --rootfs ext3 \
             --image-file $CACHE_DIR/pristine-images/$dev-vanilla.img \
             --image-size 1G \
             --align-boot-part \

$ sudo ./lava-create-master imx53

Without the patch applied, I simply removed the SD card, mounted the third partition on my main machine and created a tarball of the contents:

$ sudo mount /dev/mmcblk0p3 /mnt/
$ pushd /mnt
$ sudo tar -czf /tmp/imx53-rootfs.tgz ./*
$ popd
$ sudo umount /mnt/

Reformat p3 to ext3 (or ext2 if you prefer)

$ sudo mkfs.ext3 /dev/mmcblk0p3

Put the rootfs back onto the replacement ext3 partition.

$ sudo mount /dev/mmcblk0p3 /mnt/
$ pushd /mnt
$ sudo tar -xzvf /tmp/imx53-rootfs.tgz
$ popd
$ sudo sync
$ sudo umount /mnt/

The bootscript is buggy, so run:

> run loaduimage > run mmcboot

Then fix bootscript or you won't be able to reboot: Simplest way may be to set u-boot to ignore boot.scr

> setenv script
> saveenv
> reset

Device configuration in LAVA

I found screen to be a bit awkward as a serial connection, (use Ctrl-A : quit) to quit. I tried autologin for the lucid image but that was not needed for the master image which uses the linaro overlay. The PDU commands are for my own setup. The daemon (the machine running the pdu daemon scripts), hostname (the hostname or IP of the PDU itself) and the port numbers will change between labs. Again, the blog has changed the line endings.

device_type = mx53loco
hostname = imx53-01
connection_command = telnet hobbes 4002
#login_prompt = lucid-desktop login:
#password_prompt = Password:
#username = lucid
#password = lucid
hard_reset_command = /usr/bin/pduclient --daemon localhost --hostname pdu --command reboot --port 05
power_off_cmd = /usr/bin/pduclient --daemon localhost --hostname pdu --command off --port 05
power_on_cmd = /usr/bin/pduclient --daemon localhost --hostname pdu --command on --port 05
testboot_offset = 3

Critical testboot_offset is currently undocumented. Without it, you will see:

** Partition 4 not valid on device 0 **

You can trace this back in a LAVA test log to:

setenv bootcmd "fatload mmc 0:4 0x70000000 uImage; fatload mmc 0:4 0x72000000 uInitrd;
fatload mmc 0:4 0x71ff0000 board.dtb; bootm 0x70000000 0x72000000 0x71ff0000"

The correct line needs to use mmc 0:5 in each case.

This is what testboot_offset modifies - the default is 2:

setenv bootcmd "fatload mmc 0:4 0x70000000 uImage; fatload mmc 0:5 0x72000000 uInitrd;
fatload mmc 0:5 0x71ff0000 board.dtb; bootm 0x70000000 0x72000000 0x71ff0000"

Hacking session in LAVA

A hacking session in LAVA is a way of getting an SSH login directly into a deployed test image, as root. It's a test image, so look around, trash stuff, build stuff, reboot the board. When you are done, use stop-hacking and the test completes, leaving the master image unchanged, ready for the next rootfs to go onto the test image you were using.

This will be improved in later blog entries but as a starter and so that you can play with the SATA drive with a recent installation, this is the JSON for a LAVA job which gives you an SSH session inside the LAVA test image on an iMX53. The test image comes from Linaro releases 12.01. I haven't set up a proxy yet, so to save time, I downloaded it once and used a local file:// URL in the testjob.


the rootfstype parameter - without this, LAVA will helpfully format the partition onto which the rootfs is installed to ext4, with predictable results. (This bug is currently being fixed in LAVA so that LAVA uses the same filesystem as the downloaded image. All part of making LAVA less presumptive.)

The smoke-tests-basic testdef is gratuitous and can be removed but this particular run won't be quick - it took over an hour to get into the hacking session, but future topics here will improve that - so the extra few minutes for the smoke-tests is not a big win.

Change the value for GATEWAY to something sane for your network, change the value for PUB_KEY to your SSH public key. Change the image location to something which works for your setup.

   "health_check": false,
   "job_name": "iMX53-hacking",
   "logging_level": "DEBUG",
   "device_type": "mx53loco",
   "timeout": 900,
   "actions": [
           "command": "deploy_linaro_image",
           "parameters": {
               "image": "file:///home/linaro/lava/mx53loco-ubuntu-desktop.img.gz",
               "rootfstype": "ext3"
           "command": "lava_test_shell",
           "parameters": {
               "testdef_repos": [
                       "git-repo": "git://",
                       "testdef": "ubuntu/smoke-tests-basic.yaml"
                       "git-repo": "",
                       "parameters": {
                           "GATEWAY": "",
                           "PUB_KEY": "...."
                       "testdef": "hacking-session-debian.yaml"
               "timeout": 18000
           "command": "submit_results_on_host",
           "parameters": {
               "server": "http://sylvester.codehelp/RPC2/",
               "stream": "/anonymous/codehelp/"

(Use to reformat.)

I was part of the way through running debootstrap on the SATA drive when ser2net timed out because I hadn't changed the values at that time.

Configuring set2net for LAVA

ser2net can run on any machine capable of providing the serial connections, including a dedicated device.

Decide on a port range to use on the machine running ser2net.

If the device has more than one network interface, ensure that ser2net only offers connections on the relevant interface by prefixing the port with the IP address or hostname.

telnet is generally the easiest ser2net state to use with LAVA:

#  <TCP port>:<state>:<timeout>:<device>:<options>
#     TCP port
#            Name   or  number of the TCP/IP port to accept con-
#            nections from for this device.  A port number may
#            be of the form [host,]port, such as,2000
#            or localhost,2000.  If this is specified, it will
#            only bind to the IP address specified. Otherwise
#            it will bind to all the ports on the machine.
#,4000:telnet:600:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner

Clear the timeout or long running jobs will fail.,4000:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner,4001:telnet:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT banner

I've tried relatively carefully to preserve the instructions here from my notes. However, if you do try this yourself and there are problems, let me know and I'll update.

I'm also planning on putting all of the config files, patches, JSON examples and other code into a git repo fairly soon to make things easier.