On 20 February 2018 at 12:44, Tim Jaacks tim.jaacks@garz-fricke.com wrote:

Hello,

I am evaluating LAVA as a candidate for software release testing on our devices. I have already set up a LAVA instance with a Beaglebone Black board running regular health checks.

Our own devices do not use a standard bootloader

Why do you need an in-house bootloader? (Hint: Just because you can / have is the worst possible reason.) Honestly, just find some other way to do it - it will likely be much quicker.

We have U-Boot, UEFI, Grub, fastboot, PXE, depthcharge and flashing tools for IoT.

, but a custom one developed by our team. It has the following characteristics:

• Always boots to a shell (no interruption needed)
• OS is installed on internal eMMC by calling an installation script
• Installation script and OS images are deployed to the device via TFTP by

calling a bootloader command sequence

• Installed OS is booted via a bootloader command sequence

* lack of support from any other developers / devices / frameworks. :-)

Supporting a new bootloader is a very complex and time-consuming process for any test framework. It typically takes several months. Once done, there is an ongoing maintenance burden as the code for the supported bootloaders continues to advance.

So LAVA has already implemented TFTP as a deployment method, which I can re-use. As far as I understand, this deployment method copies the files to the machine's TFTP server directory, so that they are available to the device for download. However, the actual download (from TFTP server to device) is implemented as a command sequence in the boot method. Is that correct? At least, this is what I see in the base-uboot.jinja2 device type template.

I thought that it should be possible to re-use the "u-boot" bootloader class for our own bootloader, since the basic concepts (calling bootloader commands for TFTP download, calling bootloader commands for OS execution) are similar. The only difference might be that we don't need interruption, but that seems to be handled by the "needs_interrupt" parameter, which I could set to False.

Are these assumptions correct from an experienced LAVA point of view? Would this be a reasonable approach for getting LAVA to work with our own bootloader? Or is it necessary to implement our own bootloader python class in lava_dispatcher/actions/boot/?

You need a new Strategy Class, as per the documentation. You must not overload the "method: u-boot" support for anything except U-Boot. You must create a new boot method.

You need a battery of unit tests with sample jobs, pipeline_references and specific assertion checks that the values are set correctly.

Internally, you can inherit from the Bootloader* classes (which the U-Boot support also uses) but the syntax MUST distinguish between this bootloader and the existing bootloaders. That syntax must be carried over to the test job submission syntax and the device configuration. These devices do not support U-Boot, so must not try to re-use base-uboot.jinja2 or any of the uboot specific overrides.

If the device already supports one of the supported bootloaders, it would be best to abandon your in-house bootloader.

Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!

Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

---

Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users