Scriptable boot sequences have already landed to an extent, but I have a few changes landing soon (I hope) that will make them a bit more reliable. It is all basically expect/send to some approximation. If you can use that sort of logic Tyler and I both have experience with it and can help (not sure about the rest of the LAVA team).
I currently use this to flash new images onto boards using uboot and tftp in my home lab then hack around the fact that the image I just flashed doesn't auto-login.
I hope to change how this works a bit soon so I can configuration separate for boards, images and tests. Currently the extra config I need for an image is either held in the board or test config. This should allow for writing a test that references an image config file. #include all over again :-)
The job looks like this at the moment:
{ "device_type": "some device", "actions": [ { "command": "deploy_linaro_kernel", "parameters": { "kernel": "file:///path/to/zImage", "ramdisk": "file:///path/to/jffs2", "dtb": "... used to crash without this, left it in, unused ..." } }, { "command": "boot_linaro_image", "parameters": { "interactive_boot_cmds": true, "options": [ "setenv ipaddr '192.168.1.50'", "setenv serverip ${lava_server_ip}", "setenv update_k1_lava 'tftp ${lava_kernel} && sha1sum $loadaddr $filesize; nand erase k1; nand write k1 $filesize; set loadaddr 0x08000000; tftp ${lava_ramdisk} && sha1sum $loadaddr $filesize; nand erase r1; nand write r1 $filesize; set loadaddr 0x8000'", "run update_k1_lava", "sendline boot", "expect Machine: Entropic STB Krome platform", "expect login:", "sendline root" ] } }, { "command": "lava_test_shell", "parameters": { "testdef_urls": [ "http://192.168.1.11/tests/ls.yaml" ], "timeout": 1800 } }, { "command": "submit_results", "parameters": { "stream": "/anonymous/dooferlad/", "server": "http://192.168.1.10/RPC2/" } } ], "timeout": 18000, "job_name": "Run ls for ultimate testing!" }
Note the interactive_boot_cmds has some "sendline <string>" lines and some "<string>" lines. The difference is that sendline doesn't wait for the bootloader prompt. Most of the time you don't need to do sendline/expect, but if you want to do something a bit unusual, such as wait for a login prompt and type root (as above), they come in useful.
James
On 3 September 2013 17:44, Wookey wookey@wookware.org wrote:
I am trying to set up a Xen CI job on lava. The components are built (Xen hypervisor, xen tools deb package, Xen-enabled kernel, standard minimal rootfs). Now I'm working out what the lava job should look like.
Xen requires a non-standard boot with the hypervisor loaded as well as the kernel before booting (and rootfs unpacked).
Julien says we need to do (at least some of) the config on this page before running XEN: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Vexpress which involves disabling the A7 (required), and one way of loading the stuff in the right places, which there may be uboot/uefi-based alternatives to?). This config is done in images.txt and board.txt files.
Those files apparently live on the second, internal, microSD card. I presume that deploy_linaro_image only writes to the main SD card. Certainly the hwpack (http://releases.linaro.org/13.08/ubuntu/vexpress/hwpack_linaro-vexpress_2013...) does not contain an images.txt or board.txt file)
The card can apparently be exposed as a fat filesystem over USB (usb-storage). Is that cable plugged in? Is there a lava mechanism for accessing this and updating it?
What firmware version (boot monitor) is in the machine in the lab? What is currently in the images.txt, board.txt files it is booting with? Is 'sys_flags' bringup already selected or not?
Who knows about this stuff?
If we can't change those files in lava jobs then I believe that the xen CI task is currently blocked until one of these becomes true:
- Xen runs on the standard vexpress config
- Xen runs on arndale properly
- A mechanism for changing these files is developed
The Xen card: https://cards.linaro.org/browse/VIRT-75
Wookey
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation