Difference between revisions of "R-Car/LAVA"

From eLinux.org
Jump to: navigation, search
m (corrected lava-dispatcher-host link)
m (fix syntax highlighting. doesn't support modern web templating)
 
(8 intermediate revisions by the same user not shown)
Line 17: Line 17:
 
If you are managing your LAVA instance using [https://github.com/kernelci/lava-docker lava-docker] (a project that simplifies LAVA instances using Docker) you can automate this by setting the option in your boards.yaml:
 
If you are managing your LAVA instance using [https://github.com/kernelci/lava-docker lava-docker] (a project that simplifies LAVA instances using Docker) you can automate this by setting the option in your boards.yaml:
  
<syntaxhighlight lang=yaml>
+
<syntaxhighlight lang=text>
 
       ser2net_options:
 
       ser2net_options:
 
         - LOCAL
 
         - LOCAL
Line 30: Line 30:
  
 
=== Device definitions ===
 
=== Device definitions ===
<TBA 1. extending device dictionary>
+
For LAVA to control ADB/Fastboot on the host and DUT the following LAVA variables need to be set:
 +
<syntaxhighlight lang=text>
 +
fastboot_deploy_uboot_commands
 +
fastboot_serial_number
 +
adb_serial_number
 +
device_info
 +
</syntaxhighlight>
 +
 
 +
''fastboot_deploy_uboot_commands'' details the u-boot commands required to deploy using fastboot. The remaining variables are used for DUT discovery by fastboot and ADB.
 +
 
 +
Defaults for these variables can be added to the R-Car device-type templates in LAVA with code like this:
 +
<syntaxhighlight lang=text>
 +
{% set fastboot_deploy_uboot_commands = fastboot_deploy_uboot_commands|default(['fastboot']) %}
 +
{% set fastboot_serial_number = fastboot_serial_number|default("0000000000") %}
 +
{% set adb_serial_number = adb_serial_number|default(fastboot_serial_number) %}
 +
{% set device_info = device_info|default([{'board_id': fastboot_serial_number}]) %}
 +
</syntaxhighlight>
 +
 
 +
Note: At the time of writing (version 2021.05) LAVA contains LXC related code that fails test jobs if the adb/fastboot serial_number variable is set in the device-type template but the DUT device dictionary does not have a unique number. This is a feature of LAVA and applies to all boards. You may therefore consider what device-type template you update if you wish to avoid the need to provide numbers for DUTs that do not use fastboot/adb. For example if your R-Car H3 boards with Kingfisher fitted are typically used for AOSP but other boards are not then you might update the template r8a7795-h3ulcb-kf.jinja2 rather than rcar-gen3-common.jinja2, which is common device-type template for all R-Car boards in upstream LAVA.
 +
 
 +
Then the unique serial number for each DUT can be set in its LAVA device dictionary.
 +
For example:
 +
<syntaxhighlight lang=text>
 +
{% set fastboot_serial_number = '00025269' %}
 +
{% set adb_serial_number = '00025269' %}
 +
</syntaxhighlight>
  
<TBA 2. extending device-type template>
+
The device-type templates and device dictionary can be got, edited and updated from a remote LAVA instance using the LAVA lavacli utility, e.g:
 +
<syntaxhighlight lang=text>
 +
lavacli device-types template get <name>
 +
lavacli device-types template set <name> <template.jinja2>
 +
</syntaxhighlight>
  
<2.1. LXC side effect>
 
 
==== Using lava-docker ====
 
==== Using lava-docker ====
If you are using lava-docker you tell LAVA the serial number for the DUT in the boards.yaml.
+
If you are using lava-docker the device dictionary can be updated for the DUT in the boards.yaml.
 
This can be done in a ''custom_option'' block for the DUT.  
 
This can be done in a ''custom_option'' block for the DUT.  
  
 
For example:
 
For example:
<syntaxhighlight lang=yaml>
+
<syntaxhighlight lang=text>
 
     custom_option:
 
     custom_option:
 
     - "set fastboot_serial_number = '00012345'"
 
     - "set fastboot_serial_number = '00012345'"
Line 46: Line 74:
 
</syntaxhighlight>
 
</syntaxhighlight>
 
=== Flashing AOSP ===
 
=== Flashing AOSP ===
<TBA how to flash using R-Car flash script>
+
The R-Car Android BSP includes the script fastboot.sh to simplify flashing of an Android image. Below is an example LAVA test job yaml for flashing an R-Car platform with this script.
 +
 
 +
The most important point for designing your own jobs is that it has two main sections to complete the flashing. First a boot action that boots the platform and executes the u-boot command 'fastboot' so u-boot can be used by fastboot on the host to flash the board. Secondly a test action then executes the script fastboot.sh from the location of the image to be flashed.
 +
 
 +
Of course an actual test job will contain additional test actions after these to perform actual tests. It would also be a good idea to move these flash actions into templates that can be included in test job yaml files rather than being directly included inline as here.
 +
 
 +
The example sets r8a7795-h3ulcb-kf (R-Car H3 Starter Kit with Kingfisher expansion board fitted) as the device-type but the content could be used for any R-Car platform. A docker container called ''android_platform_tools'' is used on the host to run adb/fastboot. Using a docker container is optional but highly recommended to allow for different versions of host tooling to be used. The ''ls'' and ''adb'' shell commands are optional and included to show the files available to the script and confirm Android is running after it has been flashed.
 +
 
 +
<syntaxhighlight lang=text>
 +
device_type: r8a7795-h3ulcb-kf
 +
job_name: flash ASOP then run adb
 +
priority: medium
 +
visibility: public
 +
timeouts:
 +
  job:
 +
    minutes: 60
 +
  action:
 +
    minutes: 15
 +
  connection:
 +
    minutes: 2
 +
actions:
 +
- boot:
 +
    prompts:
 +
    - "=>"
 +
    timeout:
 +
      minutes: 15
 +
    method: bootloader
 +
    bootloader: u-boot
 +
    commands: ['fastboot']
 +
- test:
 +
    docker:
 +
      image: android_platform_tools
 +
      local: true
 +
    timeout:
 +
      minutes: 30
 +
    definitions:
 +
    - from: inline
 +
      name: fastboot-oem-format
 +
      path: inline/fastboot.yaml
 +
      repository:
 +
        metadata:
 +
          format: Lava-Test Test Definition 1.0
 +
          name: fastboot-oem
 +
          description: fastboot oem
 +
        run:
 +
          steps:
 +
          - cd <location of your image to be flashed in docker container android_platform_tools>
 +
          - ls -l
 +
          - ./fastboot.sh --noresetenv
 +
          - ./adb devices
 +
          - ./adb wait-for-device
 +
          - ./adb shell ls -l /
 +
</syntaxhighlight>

Latest revision as of 10:01, 26 August 2021

Introduction

This page contains information on using the LAVA CI project on R-Car platforms.

It is not intended as a complete 'end to end' tutorial on running LAVA. There are numerous sources for such tutorials including the official LAVA documentation. Instead, the aim is to explain nuances of using R-Car platforms in LAVA and to accelerate integration.

Glossary

DUT = Device Under Test, e.g. hardware platform to be tested

Serial console

LAVA interacts with the DUT via a serial console. A typical test job will involve restarting the DUT through a power cycle. This can be for multiple reasons. Power cycling means each job starts with the same setup for example. Another is restarting after flashing the DUT to use the flashed software.

The challenge is therefore for LAVA to maintain a serial console connection through such resets. Some R-Car platforms reset the serial on power on causing LAVA to lose the ser2net/telnet console link and therefore its ability to control the DUT. This can be mitigated by setting the LOCAL option for the DUT in the LAVA Worker ser2net configuration file.

Using lava-docker

If you are managing your LAVA instance using lava-docker (a project that simplifies LAVA instances using Docker) you can automate this by setting the option in your boards.yaml:

      ser2net_options:
        - LOCAL

ADB/Fastboot/Android/AOSP

AOSP brings a complication to a LAVA instance because of the need to run tools such as ADB and Fastboot on the Host which then communicate with the DUT. LAVA needs to be able to handle running different versions of these tools and to support the DUT discovery and communication.

Different host tooling versions are supported by running them on the host in LXC or Docker containers. LXC is now considered legacy support and Docker is strongly recommended. See the LAVA documentation for details. When LAVA is itself running in a Docker container, such as when using lava-docker, the host tooling containers are run as a sibling of the LAVA container not a child.

Fastboot and ADB use serial numbers to find DUTs. LAVA uses the host package lava-dispatcher-host to find the DUT and share it into the Docker container specified in the test job. For that to succeed we must describe each serial number to LAVA. How to do that for R-Car is described in the section on device definitions below.

Device definitions

For LAVA to control ADB/Fastboot on the host and DUT the following LAVA variables need to be set:

fastboot_deploy_uboot_commands
fastboot_serial_number
adb_serial_number
device_info

fastboot_deploy_uboot_commands details the u-boot commands required to deploy using fastboot. The remaining variables are used for DUT discovery by fastboot and ADB.

Defaults for these variables can be added to the R-Car device-type templates in LAVA with code like this:

{% set fastboot_deploy_uboot_commands = fastboot_deploy_uboot_commands|default(['fastboot']) %}
{% set fastboot_serial_number = fastboot_serial_number|default("0000000000") %}
{% set adb_serial_number = adb_serial_number|default(fastboot_serial_number) %}
{% set device_info = device_info|default([{'board_id': fastboot_serial_number}]) %}

Note: At the time of writing (version 2021.05) LAVA contains LXC related code that fails test jobs if the adb/fastboot serial_number variable is set in the device-type template but the DUT device dictionary does not have a unique number. This is a feature of LAVA and applies to all boards. You may therefore consider what device-type template you update if you wish to avoid the need to provide numbers for DUTs that do not use fastboot/adb. For example if your R-Car H3 boards with Kingfisher fitted are typically used for AOSP but other boards are not then you might update the template r8a7795-h3ulcb-kf.jinja2 rather than rcar-gen3-common.jinja2, which is common device-type template for all R-Car boards in upstream LAVA.

Then the unique serial number for each DUT can be set in its LAVA device dictionary. For example:

{% set fastboot_serial_number = '00025269' %}
{% set adb_serial_number = '00025269' %}

The device-type templates and device dictionary can be got, edited and updated from a remote LAVA instance using the LAVA lavacli utility, e.g:

lavacli device-types template get <name>
lavacli device-types template set <name> <template.jinja2>

Using lava-docker

If you are using lava-docker the device dictionary can be updated for the DUT in the boards.yaml. This can be done in a custom_option block for the DUT.

For example:

    custom_option:
    - "set fastboot_serial_number = '00012345'"
    - "set adb_serial_number = '00012345'"

Flashing AOSP

The R-Car Android BSP includes the script fastboot.sh to simplify flashing of an Android image. Below is an example LAVA test job yaml for flashing an R-Car platform with this script.

The most important point for designing your own jobs is that it has two main sections to complete the flashing. First a boot action that boots the platform and executes the u-boot command 'fastboot' so u-boot can be used by fastboot on the host to flash the board. Secondly a test action then executes the script fastboot.sh from the location of the image to be flashed.

Of course an actual test job will contain additional test actions after these to perform actual tests. It would also be a good idea to move these flash actions into templates that can be included in test job yaml files rather than being directly included inline as here.

The example sets r8a7795-h3ulcb-kf (R-Car H3 Starter Kit with Kingfisher expansion board fitted) as the device-type but the content could be used for any R-Car platform. A docker container called android_platform_tools is used on the host to run adb/fastboot. Using a docker container is optional but highly recommended to allow for different versions of host tooling to be used. The ls and adb shell commands are optional and included to show the files available to the script and confirm Android is running after it has been flashed.

device_type: r8a7795-h3ulcb-kf
job_name: flash ASOP then run adb
priority: medium
visibility: public
timeouts:
  job:
    minutes: 60
  action:
    minutes: 15
  connection:
    minutes: 2
actions:
- boot:
    prompts:
    - "=>"
    timeout:
      minutes: 15
    method: bootloader
    bootloader: u-boot
    commands: ['fastboot']
- test:
    docker:
      image: android_platform_tools
      local: true
    timeout:
      minutes: 30
    definitions:
    - from: inline
      name: fastboot-oem-format
      path: inline/fastboot.yaml
      repository:
        metadata:
          format: Lava-Test Test Definition 1.0
          name: fastboot-oem
          description: fastboot oem
        run:
          steps:
          - cd <location of your image to be flashed in docker container android_platform_tools>
          - ls -l
          - ./fastboot.sh --noresetenv
          - ./adb devices
          - ./adb wait-for-device
          - ./adb shell ls -l /