[some of you got a version of this by private mail, but there's no real reason to limit the distribution...]
Hi guys, I had this blueprint assigned for 2013.02: https://blueprints.launchpad.net/lava-dispatcher/+spec/calxeda-highbank-support and unfortunately I didn't get time to implement it completely. I did make some progress, in terms of a general idea and a start of an implementation. I'm braindumping here so that if someone tries to work on this while I'm on leave they don't have to start from scratch. The general idea is similar to the way master images work for developer boards, but instead of the master image living in another partition of the device's storage it lives in an initrd that can be booted via PXE. If you poke around on gateway starting with /etc/dnsmasq.conf you can see how this works. The way I've been producing the initrd's so far is by having this: http://paste.ubuntu.com/5563262/ in a file called /usr/share/initramfs-tools/hooks/master-extras on calxeda02-00-00 (it has quantal installed, user: ubuntu, password: mypassword), running sudo update-initramfs -k all -c and scp-ing the generated initrd into the appropriate location on gateway. This is all very tedious, but it's worked so far... The other side of course is some dispatcher code to drive it all. I have started this here: http://bazaar.launchpad.net/~mwhudson/lava-dispatcher/highbank-support/view/head:/lava_dispatcher/device/highbank.py but I haven't even tried to run this once so it's probably full of all sorts of stupid errors. It also contains a good deal of cut-and-paste from master.py -- probably some kind of base class would make sense in the end there. I didn't want to put a web server in the initrd so my plan was to use netcat -- but http provides a little more guarantee that the transfer actually worked, so maybe getting _some_ kind of httpd in the initrd is worth it, I dunno. Currently it expects the "hwpack" to just be a deb of the kernel which is installed via dpkg -i chrooted into the unpacked rootfs to generate the initrd and put the dtb in the right place and all that sort of thing. It's unclear if there will ever be "real" hwpacks and linaro-media-create support for highbank -- and dpkg -i-ing the kernel deb is all this would do anyway really. Some random follow on points: * Bootloaders are loaded via a completely different mechanism for highbank, so support for bootloader testing will have to be done differently (in very vague outline it would be a bit like vexpress I suppose) * There has been some interest in automatic testing of netinstallers. The above wouldn't enable this. * Testing netinstallers and PXE booting in general will require some level of dynamism in the configuration of network booting, obviously. There are a few ways this could be done: * Do netbooting explicitly by talking to u-boot (i.e. no PXE) * Have dnsmasq point at a tftp service that is not backed by the filesystem so we can generate PXE configs on the fly according to how we want to test a device at a particular time (MAAS, Canonical's metal-as-a-service product, works like this). * Somehow put each device being tested in an isolated vlan/broadcast domain with a per-test DHCP implementation. Would be nice but sounds hard in many ways. * There's no inherent reason why we couldn't put the master image in an initrd for developer boards, which would relieve us of the need to muck about with partition indices. Cheers, mwh _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
