(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 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 . 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
Next!
I m working on some code upstream to make it easier to add devices from the command line. The aim is that a set of simple commands will set up an initial device, run a job on that device and submit a result bundle to the LAVA server as job #1. This gives some assurance that everything has gone well.
Now I can finally add health checks for the iMX.53 boards and start regular tests on those boards. The cubie boards will wait for a later blog post, there are interesting problems with the bootloader and serial connections. That s a whole different rant.
We had a pretty busy day today. Sarah dropped Zoe off at around 8:30am. I
reminded Zoe that she'd forgotten to give Sarah her crown that she'd made at
Playgroup the previous day, so she gave that to her.
After Sarah left, I let Zoe watch a little bit of TV while I finished getting
myself organised.
We drove to Brazilian Jiu Jitsu class today, because I wanted to go directly to
the Planetarium afterwards.
Zoe's BFF Megan came to BJJ class today for a trial class. Zoe was very
excited. Megan picked everything up really quickly, and the girls had a good
time. She didn't want to wear her uniform today though. I managed to get out of
her later that she felt it made her sweaty. I told her it was probably all the
running around that made her sweaty, not the uniform.
We went out for a coffee with Megan, her Dad and her little sister afterwards.
We found a little take away shop around the corner. Not quite the place that
did babyccinos unfortunately, so Megan's Dad very cleverly got a chocolate milk
and split it three ways with the girls and called it a "milkshake".
I've realised that for Science Friday, I've pretty much been doing solely
chemistry so far, so I wanted to throw in a bit of astronomy this week. The Sir
Thomas Brisbane Planetarium had just recently reopened after getting a
spanky new projector because 1978 called and wanted theirs back.
Unfortunately, they weren't showing Perfect Little Planet
today, but the slightly more specific Black Holes: Journey into the
Unknown. I wanted Zoe to see something in the auditorium, so I
thought we'd give it a shot anyway.
I think we got to the Planetarium at around 11am, and the next show was at
1:30pm, so we had a bit of a look around the foyer for a bit, which Zoe quite
enjoyed. They had a life-size model of Neil Armstrong's spacesuit, and a scale
model of a Saturn V rocket. Zoe quite enjoyed both of them. I'll have to dig up
some Youtube footage of a Saturn V launch.
We then headed over to the cafe in the adjacent Botantic Gardens, and had a
reasonable lunch. After lunch we wandered around the Botanic Gardens to kill
some time, so you could say that today's Science Friday also included a goodly
amount of botany as well. We went into the Tropical Dome and looked at the fish
in the lily pond, and toured the fern garden, before heading back.
We timed it pretty well, and got back to the Planetarium with about 10 minutes
to kill. I'd prepped Zoe for the presentation, and told her that she needed to
keep quiet, and if we had to leave we wouldn't be able to go back in again, and
she could whisper to me if she needed to. I have to say, she was so well
behaved. She sat through the whole 45 minute presentation and the projected
tour of the night sky.
I guess the presentation was sufficiently visually interesting to hold her
attention for the duration. There was certainly a lot of "wow" out of her. I
was so proud of how she went that I had to go and buy her an ice cream as a
reward.
After that, we went for a drive around Mount Coot-tha. I pointed out the TV
towers that we can see from our balcony, and then she fell asleep on the way
home.
She didn't wake up particularly happy from her late, short nap, when we got
home, but once she got herself sorted out, we baked the cookies that we'd made
yesterday. They came out very nicely indeed. Once they were all baked, we
dropped off a dozen to Megan's place, and then came home to have dinner.
Bedtime went pretty well. I hope she has a good night's sleep, as we have a big
day tomorrow.
As Jan has previously 
In case you have spare time at the weekend ahead, it may be worth to spend it with great 
When I was recently talking about load-balancers, and automatically adding back-ends, not just removing bad ones that go offline, I obviously spent a while looking over some.
There are several dedicated load-balancers packaged for Debian GNU/Linux, including:
A new minor release 0.11.1 of
I switched to 
I wrote about 
Go language has a strong type system unlike C, and some times this
will be head ache when we want to interact with C data types with Cgo
or just to convert a Go type to lets say byte slice. I recently faced
the same problem and after poking around things, I learned the Go
provides unsafe package which can be used to work around the Go's
type system.
After a number of years in Debian, in various roles, I decided to 
"Given a Debian system with just the set of essential packages installed,
find a single package name that, together with its dependencies, will
increase the used diskspace of the system by as much as possible."
My entry: openarena.
Off to bed, now.