[Lava-users] Customizing the deployment and booting actions

Steve McIntyre steve.mcintyre at linaro.org
Wed Nov 8 16:38:57 UTC 2017


Hi Alfonso,

On Wed, Nov 08, 2017 at 04:24:41PM +0000, Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA SE 1) wrote:
>
>in our current project we have some devices that are not "directly" 
>supported by lava. I would like to ask for you opinion on which would be 
>the correct way to proceed.
>
>The main problem is that our devices have a EFI implementation in the 
>firmware that is making the task of installing uboot very hard. To avoid 
>this, we thought about serving the image through an "emulated" usb 
>stick. On that regard, we made some progress by setting up a secondary 
>device that would use the linux g_mass_storage module to serve the image 
>through the USB otg port.
>
>Our setup is then:
>
>1) The actual testing device
>2) The secondary device which only serves the image with g_mass_storage
>3) The host machine running the lava-slave application.
>
>We thought that we could add a new device-type template to the lava 
>server that would somehow override the deployment and boot actions to 
>address our setup. We tried to look into the base.jinja2 file for some 
>sort of entry point that would allow us to, for example, run a script 
>that would first send the image to the secondary device and secondly run 
>the g_mass_storage module with the image file.

It sounds like you're trying to do something like what's supported via
LAVA's "secondary media" support?

  https://validation.linaro.org/static/docs/v2/secondary-media.html

although you might be adding more complexity to your tests that
way. If your devices already boot via UEFI, could you configure them
to net-boot from UEFI instead, and run your tests that way?

Cheers,
-- 
Steve McIntyre                                steve.mcintyre at linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs



More information about the Lava-users mailing list