(ARMv7 A15 dual core)

I've covered how I set up my home LAVA lab and how I got two iMX.53 boards running, the next step was to sort out the LAVA server.

My initial setup relied on using my Thinkpad as the server. This was somewhat convenient as that's how I develop the code, but didn't help me run jobs like health checks because the laptop was usually somewhere other than on the home LAN. There had been a long-standing problem with using LAVA on ARM - the uwsgi support didn't compile - but the code being used was old. As the same code has been in Debian for a long time, I suspected that this was fixed with a newer version. So as part of migrating LAVA to django1.6, apache2.4, postgres9.3, django-tables2 0.13 and a few other updated dependencies, I have been using the version of uwsgi from Debian unstable for quite a while without problems on x86. A simple tweak to the LAVA setup scripts and a newer version of uwsgi became available and it builds just fine on armhf. (I haven't tried armel because Linaro is ARMv7 or newer and we don't test with ARMv5/ARMv6 boards, so there's no point in trying armel - it's not likely to be an issue for this fix though.) (Only the current lava-deployment-tool methods need to actually compile uwsgi directly from upstream without any patches - the packaging which will replace l-d-t uses precompiled binaries, just as any admin would expect.)

That initial install was on one of the iMX.53 boards, which ran as slowly as anyone who has used an iMX.53 would expect. I haven't run test jobs on that install, it had a hard enough time serving the frontend.

Clearly some more cores would be a good step and when an arndale became available for the home lab, the next step was to get a SATA drive onto the arndale, put Debian unstable on that and then deploy LAVA to the arndale using the Debian packages. As a bonus, these packages are built for django1.6 (using an unreleased branch).

Sounds simple enough. It works on iMX.53, it should work on an arndale. Well, it does - but only after some unexpected faff.

arndale, u-boot and SATA

I hate u-boot - every single time I ever touch it, the little I know about any other u-boot device is completely useless. Uniformity is a good thing - infinite permutations are just rope to hang ourselves with `cute embedded nonsense hacks <https://plus.google.com/+JonMasters/posts/j5Vdu1LKv3b>`_ and I'm bored of that whole scene.

So, boot the arndale, interrupt the bootloader to get to the prompt. What's the first thing most people would want? help. Denied - this particular u-boot has been compiled without the ability to display any help messages. u-boot has just sunk further into the depths of "please can we have something else which is uniform across devices".

OK, well maybe I can get by without help. sata init - unknown command 'sata'. (Go away, do something else for a bit.)

The arndale isn't one of the newest boards in the ARMv7 world, LAVA has been using them for a while, so someone has probably done some work to fix this &#8230;. nope. There's a workaround - a nice detailed guide by Phil Endecott which details that the kernel needs to continue to be loaded from SD and then the SATA can be used for just the rootfs.

Mildly annoyed (I was hoping to be able to update the arndale kernel without the hassle of mounting the SD card at all), the rest was straight-forward.

Preparing the SATA and installing Debian

Due to the complexity of some of the transitions currently ongoing in Debian ahead of the Jessie release freeze, uwsgi is not in Debian testing right now so this install has to be Debian unstable. That's OK, I've been running Debian unstable on all my machines for several years now - usually updating ~5 times a week.

# parted /dev/sda -s unit mb mktable msdos
# parted /dev/sda -s unit mb mkpart primary 1 -- "-0"
# mkfs.ext4 /dev/sda1
# mount /dev/sda1 /mnt/root/

(note the -- in the mkpart command, that catches me out most times I try this. Without it, the special -0 gets interpreted as an option to parted but parted doesn't then tell you how to fix it, it just complains about an unknown option.)

The SD image I am using is a LAVA master image, based on Ubuntu, so it was easy to put debootstrap onto it.

# apt-get install debootstrap
# debootstrap --arch=armhf sid /mnt/root/ http://ftp.uk.debian.org/debian
# chroot /mnt/root/

Inside the chroot, it's Debian as usual:

apt-get update
apt-get install emdebian-archive-keyring
passwd

emdebian-archive-keyring is a package I (ab)use to sign my LAVA packaging as it has the advantage of being in Debian and Ubuntu going back to the time of Lenny, so it is always available from a repository which has already been authenticated to apt and doesn't involve downloading some random key from a website.

I use passwd manually because this rootfs won't be using auto-login, it will have regular users. root passwords can be automated, if necessary.

Thinking about login, remember to give the rootfs a usable tty. (The LAVA master image has a nasty habit of mangling editors like nano and vi when used over serial, so I'm using echo.) For the arndale you need:

# echo T0:23:respawn:/sbin/getty -L ttySAC2 115200 vt102 >> ./etc/inittab<
# echo >> ./etc/securetty
# echo ttySAC2 >> ./etc/securetty

Then to make the hostname useful, adapt this to your needs:

echo 127.0.0.1       arndale.codehelp arndale >> ./etc/hosts

Finally, get the network running at boot and add the LAVA repository:

# echo auto lo eth0 > ./etc/network/interfaces.d/arndale
# echo iface lo inet loopback >> ./etc/network/interfaces.d/arndale
# echo iface eth0 inet dhcp >> ./etc/network/interfaces.d/arndale
# echo deb http://people.linaro.org/~neil.williams/lava sid main >> ./etc/apt/sources.list.d/lava.list
# apt-get update
# exit

Once the LAVA packaging is finalised, the packages will be uploaded to a normal Linaro PPA, I'll update the packages to use an 'official' download location and we'll move to using sane version string handling. For now, the packages are still in development.

Code for the packaging is in Alioth but there are issues with anonymous access to the pkg-linaro-lava repositories currently, so I've also pushed to http://github.com/Linaro if you are interested in building the packages yourself. See also my packaging guide which is also linked from the Links page on my own site.

With that done, time to reboot, set the SATA drive as the rootfs using the horrid u-boot and install LAVA:

# reboot
> setenv bootargs console=tty0 console=ttySAC2,115200n8 drm_kms_helper.edid_firmware=edid-1920x1080.fw  root=/dev/sda1
> boot

'login':

# apt-get install postgresql

After this operation, 63.0 MB of additional disk space will be used:

# apt-get install lava-server

After this operation, 231 MB of additional disk space will be used:

# a2dissite 000-default
# a2ensite lava-server
# apache2ctl restart
# service lava-server restart

Take note of the IP address of your new ARM LAVA server and sign in with your regular details, e.g. using OpenID before creating a temporary superuser:

# lava-server manage createsuperuser --username default --email=user@example.com

Choose a temporary password, log out, log in as the temporary superuser, promote your regular user to superuser and default owner of unrestricted devices in the django admin interface. Finally, log out and login as regular user to delete the temporary user. (Yes, that probably could do with some improvement - remind me later and I'll see if a known user can be promoted from the command line.)

See also Senthil's recent post on LAVA unit tests. Getting those to run without so many steps is also on the TODO list.

Results

IP Address: 127.0.0.1
Is Master? : True
Uptime: 6:02:23.700000
Architecture: armv7l
Platform: Linux-3.10.1.0-1-linaro-arndale-armv7l-with-debian-jessie-sid
Insignal Arndale evaluation board based on EXYNOS5250
System memory: 1998MiB