Standard test job for beaglebone-black

If you do not have access to a beaglebone-black device in a LAVA instance yet, you will still benefit from following the example as an introduction to integrating a range of ARMv7 U-Boot devices into LAVA.

Standard test jobs for other devices

If you do not have a beaglebone-black available, there are very similar standard test jobs available for arndale, cubietruck and panda devices. “These files are very similar; typically the only substantive changes come down to the DTB for the relevant device type.

Standard test job for beaglebone-black

The first standard job for a beaglebone-black is a simple ramdisk test job.

Features of a ramdisk test job

  • Minimal system - sometimes based on a full OS like Debian or OpenEmbedded, sometimes a custom built system. In this standard test job, the ramdisk is built by installing the associated kernel package in a Debian system. The ramdisk is not a full system, certain utilities are omitted or replaced with minimal alternatives from busybox.

  • Custom prompt - (initramfs) needs to be specified instead of a login prompt like root@debian.

  • Modifications - LAVA needs to modify the ramdisk if a test action is specified in a ramdisk test job to be able to add the scripts which support the operation of the test shell. Once modified, LAVA has to repack the ramdisk, including adding a U-Boot header if the device requires one.

Features of an NFS test job

  • Full system - a basic bootstrap of the OS like Debian, Ubuntu or Fedora with configured users and a full init system, e.g. systemd. When building a new rootfs, ensure the root user password is set or cleared, many systems will use a random root password until set. Network configuration may also be needed, e.g. to use DNS.

  • Standard prompt - typically root@jessie: or similar. When building or modifying a rootfs, ensure that the prompt is described alongside the rootfs tarball so that other users are able to use the file.

  • Modifications - LAVA needs to modify the rootfs if a test action is specified in an NFS test job to be able to add the scripts which support the operation of the test shell. If modules are provided, these are added to the rootfs as well.

Deploy

U-Boot support in LAVA supports a variety of deployment methods. This standard job will use the Debian ARMMP kernel package. The standard build script for this test job prepares a simple root filesystem and installs the ARMMP kernel. The installation scripts in Debian generate a suitable ramdisk and the script builds a tarball (.tar.gz) of the kernel modules from the package.

  • kernel - vmlinuz

  • dtb - dtbs/am335x-boneblack.dtb

  • ramdisk - initramfs.cpio.gz

  • modules - modules.tar.gz

Specific options

The modules.tar.gz and initramfs.cpio.gz are both compressed using gzip and this must be specified in the test job definition.

Finally, although the ramdisk was built on a Debian system, the ramdisk itself does not behave in the same way as a full Debian system. It lacks critical components like apt, so the test job specifies that the test shell can only expect basic compatibility by specifying oe for OpenEmbedded.

actions:
# DEPLOY_BLOCK
- deploy:
    timeout:
      minutes: 4
    to: tftp
    kernel:
      url: http://example.com/vmlinuz-4.9.0-4-armmp
      type: zimage
    ramdisk:
      url: http://example.com/initrd.img-4.9.0-4-armmp.gz
      compression: gz
    # modules
    modules:
      url: http://example.com/modules.tar.gz
      compression: gz
    # despite this being a Debian initramfs, it is not a complete Debian rootfs, so use oe compatibility
    dtb:
      url: http://example.com/am335x-boneblack.dtb

Boot

U-Boot support in LAVA supports a variety of deployment methods. This standard job will use the ramdisk commands from the device type template.

- boot:
    method: u-boot
    commands: ramdisk
    prompts:
    # escape the brackets to ensure that the prompt does not match
    # kernel debug lines which may mention initramfs
    - '\(initramfs\)'
    timeout:
      minutes: 2

Test

The limitation of a ramdisk deployment is that certain tools (like apt) are not available, so the test definition used with this test job is a fairly minimal smoke-test. Avoid test definitions which specify packages to be installed in the install: deps: list.

- test:
    timeout:
      minutes: 5
    definitions:
    - repository: http://git.linaro.org/lava-team/lava-functional-tests.git
      from: git
      path: lava-test-shell/smoke-tests-basic.yaml
      name: smoke-tests