On Thu, Sep 05, 2013 at 01:54:58PM +0100, Wookey wrote:
+++ Antonio Terceiro [2013-09-04 20:41 -0300]:
On Tue, Sep 03, 2013 at 05:44:13PM +0100, Wookey wrote:
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.
The card can apparently be exposed as a fat filesystem over USB (usb-storage). Is that cable plugged in?
It is.
Is there a lava mechanism for accessing this and updating it?
Yes, but at the moment it's only used to replace the UEFI binary with the one that comes with the test disk image. It would be possible to add some code that will also replace other files in there.
Is this code that we have to add to lava and then release into production, or can we issue interactive_boot_cmds sendline/expect foo to get this done for now?
The interactive_boot_cmds thing is used to interact with the bootloader (e.g. sending uboot/uefi commands) over the serial connection after the board is booted into it, so I don't think that would be useful in this case where you want to run commands on the host to fiddle with the Vexpress USB storage.
(Which machine is actually issuing those commands in lava? I haven't got the architecture properly understood in my head, which makes this confusing to think about. Although I guess the idea is that lava wraps all that so I shouldn't need to know.
So LAVA works like this:
- there is a LAVA master server, which serves the web UI and the XMLRPC API - there are multiple worker servers. Each worker node has potentially many boards connected to it. The worker node is responsible for actually running the jobs that get assigned to their boards.
+---- [worker] ---+--- [board] | +--- [board] | [master] ------+---- [worker] ---+--- [board] | +--- [board] | +---- [worker] ---+--- [board] +--- [board]
Each vexpress board is plugged via USB to the host that controls it, and we have special code that handles the support for reflashing the firmware via the USB mass storage interface. So you are right in which you don't need to care about which the actual connections: whatever worker/board pair that gets the job will be able to deal with it.
I think I do need to know the device name of this SD-card if we are doing mount;change file;unmount in interactive_boot_cmds.
You cannot really send arbitrary commands to run on the LAVA server.
And presumably $something needs to remember to put the default one back again after this job runs, which is the real reason why lava needs to support it properly?
Correct.
So how the UEFI replacing works is that lava will mount the USB storage interface, make a backup of the UEFI binary there, copy over the UEFI binary provided by the test image, and boot. When recovering the board (for a new job for example), LAVA will restore the UEFI binary from the backup.
One easy way to support this use case would be to also read board.txt from the image in the same directory where the UEFI binary already is, and use that to replace the board.txt before booting.
But it would be overkill to require a new image to be built just for this: will the xen testing have its own special image?
If yes, then we are lucky and you could just include the desired boot.txt in the image, and I could write the code on the LAVA side to handle it.
If not (i.e. you will be using stock images), then we need to figure out another mechanism for passing the desired board.txt, which shouldn't be hard, but will require more effort than the easy way.