Adding Avenger96 Board to LAVA Lab

Adding Avenger96 Board to LAVA Lab

This topic documents the steps required for adding Avenger96 board to LAVA lab.

Connect to serial console

On Avenger96 board, U-Boot and Linux boot logs as well as a standard Linux console is accessible on the debug UART1 connected to pin 11 and 13 on the low-speed expansion connector.

Wire end version TTL-232RG USB-serial converter with signal levels 1.8V CMOS should be used for serial connection. e.g. TTL-232RG-VREG1V8-WE. Refer to the below picture to connect serial wires to Avenger96 low-speed expansion connector.

Serial Wire Avenger96 low-speed Connector
Black: GND Pin1: GND
Yellow: RxD Pin11: UART1_TxD
Orange: TxD Pin13: UART1_RxD

Disable u-boot autoboot

The U-Boot 2018.09 on emmc is buggy and lacks the below features required for network boot in LAVA.

  • autoboot cannot be disabled as saveenv command is not available.
  • U-Boot dhcp command unable to get IP and reported address not set.

Upgrading emmc u-boot is quite complicated. Alternatively, we will install the latest OS image to SD-Card and switch boot mode to SD-Card.

  1. Download the latest OS image. As the link for v6.9 image is protected, V6.5 image can be used instead. See Starter Image Changelog - Wiki-DB for download link.

  2. Download Etcher SD Card installation tool for your host machine.

  3. Follow the Etcher prompt to flash SD Card with the above image.

  4. Configure boot config DIP switch as below to set boot mode to SD-Card(Standard).

    Switch 1 - Boot 0 Switch 2 - Boot 1 Switch 3 - Boot 2
    1 0 1
  5. Boot the board from SD-Card, enter the u-boot command line and run the below commands to disable autoboot.

    Hit any key to stop autoboot:  0 
    STM32MP> setenv bootdelay -1
    STM32MP> saveenv 
    Saving Environment to MMC... Writing to redundant MMC(0)... OK
    STM32MP> reset
    

Add LAVA configurations

Add serial adapter to ser2net.conf

Edit /etc/ser2net.conf to add serial adapter for your board.

Here is an example. Adjust port and serial device ID when needed.

7001:telnet:0:/dev/serial/by-id/usb-FTDI_TTL232RG-VREG1V8_FT3F09A8-if00-port0:115200 8DATABITS NONE 1STOPBIT LOCAL

Restart ser2net service. Example for systemctl:

systemctl restart ser2net

Add device dictionary to LAVA server

Add device type /etc/lava-server/dispatcher-config/device-types/avenger96.jinja2. MR has been raised to add the device type to the next LAVA release.

{# set device_type = "avenger96" #}
{% extends 'base-uboot.jinja2' %}

{% set console_device = console_device|default('ttySTM0') %}
{% set baud_rate = baud_rate|default(115200) %}
{% if extra_kernel_args %}
{% set extra_kernel_args = "rootwait rw earlyprintk console=ttySTM0,115200 " + extra_kernel_args %}
{% else %}
{% set extra_kernel_args = "rootwait rw earlyprintk console=ttySTM0,115200" %}
{% endif %}

{% set bootloader_prompt = bootloader_prompt|default('STM32MP>') %}
{% set interrupt_prompt = interrupt_prompt|default('STM32MP>') %}
{% set boot_message = 'Starting kernel' %}

{% set bootm_kernel_addr = bootm_kernel_addr|default('0xc2000000') %}
{% set bootm_ramdisk_addr = bootm_ramdisk_addr|default('0x45000000') %}
{% set bootm_dtb_addr = bootm_dtb_addr|default('0xc4000000') %}

{% set base_ip_args = 'ip=::::stm32mp157a::dhcp kmac=dev:eth0,addr:' %}
{% set uboot_mkimage_arch = 'arm' %}
{% set action_timeout_power_off = 15 %}

Add device dictionary file /etc/lava-server/dispatcher-config/devices/avenger96-01.jinja2. Adjust device index and the below example to adapt your case.

{% extends 'avenger96.jinja2' %}
{% set connection_command = 'telnet localhost 7001' %}
{% set hard_reset_command = 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null pi@10.173.106.175 relay-module.py -c CH3 -s reboot' %}
{% set power_off_command = 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null pi@10.173.106.175 relay-module.py -c CH3 -s off' %}
{% set power_on_command = 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null pi@10.173.106.175 relay-module.py -c CH3 -s on' %}

{% set sync_to_lava = {'device_type': 'avenger96', 'worker': 'worker01', 'tags': ['avenger96-01']} %}

If you are adding device to OSTC LAVA instance, send the above device dictionary to LAVA Config. It will be deployed automatic once merged to master branch.

Test your device in LAVA

Submit a LAVA job to test if everything works. LAVA job example LAVA | Scheduler | Jobs | 73

1 Like

Can this be done with ASOS builds instead of DH Electronics builds?

The DH Electronics builds is for getting latest u-boot. This LAVA job example LAVA | Scheduler | Jobs | 73 used ASOS build for netboot testing.

Right but that was my point. Is the u-boot from DH Electronics more recent? Perhaps we should update something on our end?

I don’t think it is more recent. On my board, it is actually running an older build as the latest image cannot be downloaded. For the moment, I just need an version has netboot support.

Are we able to build ASOS SD installer for avenger96 now? Are we going to test u-boot itself? If that is the case, ASOS build should be used instead.

Per my understanding, netboot is more useful for kernel testing, if we want to test bootloader as well, we will need a different way for image deployment.

I see what you mean now.

I don’t know if we can build installer images yet. I assume those are SD cards that install an OS to eMMC, right?

I don’t think we will be testing u-boot itself today but we will be testing our own u-boot scripts at some point, mainly for the OTA logic. It would be good to be able to completely control those during the testing process, as the OTA code will not be able to work without having control over the bootloader script.

I think for now we should have an ability to, with a fixed uboot and perhaps hacked config, do kernel&rootfs boot tests, followed by “boot-and-run-some-programs” tests like we want to do with CTS suite.

Once OTA stack becomes complete enough to move from the initial target of Raspberry Pi 4, we will need the ability to boot an arbitrary image from an SD card (or eMMC) and iterate through various test scenarios that perform all kinds of bootloader modifications.

One test I would love to write is an upgrade to a broken image, which can recover automatically with a watchdog enabled in the bootloader. One more constraint on this is that as a part of the Transactional OS work, we will define a new partitioning scheme. That may or may not impact your automation work.

I shouldn’t use installer which is misleading. It is actually images that can be installed to SD-Card using dd, then we can boot the board from the SD-Card directly. I don’t see a way to install OS to emmc using SD-Card yet.

This Avenger96 Image Programming - Wiki-DB is how to flash emmc/sdcard using flasher tool which has command line version and supported in LAVA already. I tried the method with ASOS build, it always return mtd: nor device not found. I think this is something should be investigated for the OTA test scenario you mentioned.

Yes, we should start with netboot for kernel/rootfs/cts testing, and then look into sdcard /emmc flashing when required. The flasher deployment method is way more complicated as we need another relay board to control boot mode so that we can switch between boot and deployment mode. We will need to rework the board to solder wires to the dip switch terminals and set dip switch to “off”. This is how it was done for stm32mp157c-dk2. At least on Avenger96, I think it is possible to simply the control as the below U-Boot command is available now.

STM32MP> stm32prog 
stm32prog - <link> <dev> [<addr>] [<size>]
start communication with tools STM32Cubeprogrammer on <link> with Flashlayout at <addr>

Usage:
stm32prog <link> = serial|usb
<dev>  = device instance
<addr> = address of flashlayout
<size> = size of flashlayout

In that case I believe we do have them. We just don’t publish those from CI but we have instructions on how to build them from source with bitbake: 96Boards Avenger96 — All Scenarios OS 0.1.99 documentation

Can you report that against meta-ohos please?

As for the rest, it does seem complex. I don’t have an opinion either way, I was trying to understand what you were doing more than trying to influence that.

Couple of things to note:

  1. Interrupt prompt in upstream LAVA avenger96 device type configuration is wrong. Sorry I didn’t pick that up in the review. When we set this up correctly, there will be no need to mess with boot order on the avenger itself, LAVA will interrupt the autoboot on it’s own.
    Something like this:
   {% set interrupt_prompt = interrupt_prompt|default('Hit any key to stop autoboot') %}
  1. lava-docker-worker has this file by default /etc/default/tftp-hpa where LAVA picks up the path of the TFTP directory. I’ll document that this needs to be updated alongside the host configuration of the tftp server. This is probably due to the fact that I’ve installed tftp service on the host and not in the separate container. I’ll explore further.

@stevanr per our conversation, the below step #5 for disabling u-boot auto is missing here. It looks like I cannot edit the topic anymore. I will check with forum admins.

  1. Boot the board from SD-Card, and enter the u-boot command line to disable autoboot.
Hit any key to stop autoboot:  0 
STM32MP> setenv bootdelay -1
STM32MP> saveenv 
Saving Environment to MMC... Writing to redundant MMC(0)... OK
STM32MP> reset

The first post has been updated with the step #5 included.

1 Like