Tims minnowboard test provisioning

From eLinux.org
Jump to: navigation, search

Tim is (in early 2018), trying to come up with a provisioning system for the Minnowboard turbot in his lab.

He put out a request for information on the automated-testing e-mail list, and got back lots of options. See https://lists.yoctoproject.org/pipermail/automated-testing/2018-January/subject.html#152

Here is an evaluation of those options, along with his own test experiences setting this up for his lab:


  • If possible to avoid hardware, that would be good.
    • I don't mind special hardware
  • I want to boot the machine for testing as similar to how it will be used in production as possible
    • This means that automatic boot from sdcard is preferable to network boot, or especially boot with network filesystem.
  • fewer package dependencies is better
  • fewer runtime host dependencies is better


  • the default configuration of the board is to boot using grub, from the sdcard
  • the default control of booting is via hdmi screen and keyboard
    • how easy is it to configure grub to be usable over serial console (I'd rather not)
  • can you control this with timing?
    • boot to stable kernel as default
    • boot to kernel under test using keystrokes (to USB?)

host-controlled USB keyboard options

One way to control boot would be with a host-controlled USB keyboard. That is, use a device that allows the host computer to send keystrokes through the USB port.

Here are some options:


  • use LAVA, with network download of kernel and ramdisk (suggested by Matt Hart)
  • use labgrid and SD-USB-Mux (suggested by Robert Schwebel)
  • use ci-rt project stuff for this (suggested by Thomas Gleixner)
    • supports debian-packaged kernels - good for kbuild?
    • presumably this uses r4d for low-level board control, and libvirt and
      • r4d requires sqlite3 python-sqlalchemy python-pysimplesoap snimpy snmp-mibs-downloader
      • daemon must be running at all times (ugh)
    • presumably starts new kernel using kexec
      • does it support non-x86_64? What platforms support kexec?
  • use efi network boot of grub, then temp kernel and initramfs to write to USB, then reboot to grub again and boot
    • not sure if this uses serial console grub (probably)
    • uses efi network boot and dnsmask to deliver grub to target
    • uses LAVA to control grub for both boots
    • NOTE: this one actually provisions something

overview of provisioning/booting options

  • install kernel to SD card, boot from grub (kernel selection at boot)
  • install kernel to USB flash, boot from grub (kernel selection at boot?)
  • install kernel to host, boot from network
  • install kernel to target fs, kexec boot from local file

action items

  • get an SD-USB-Mux for testing from Robert Schwebel
  • can a wireless SD card be used for this?
  • find out if r4d relies on kexec support
  • find out if configuring grub for serial port control requires rebuilding grub
  • test grub with serial control
  • see if LAVA grub control can be separated from rest of LAVA
  • see if temp kernel and initramfs for writing to SD card or USB already exist
  • see if scripts for
  • find out about efi network boot
  • find out about grub serial console
  • find out about dnsmasq

Completed action items

resulting solution

I ended up using a Teensy 3.2 Arduino board, to emulate a USB keyboard to send the machine keystrokes on startup to navigate the firmware menus.

Here are some details: The Teensy module simulates a USB keyboard. I have loaded the "Etherkey" sketch: https://github.com/Flowm/etherkey on the Teensy, and I control the USB keyboard emulation using commands sent to the Teensy via it's uart.

That is, the host computer sends commands to the Teensy board (via the Teensy's serial port) that are then communicated to the Minnowboard as keystrokes from a USB keyboard.

The USB side of the Teensy is connected to the MinnowBoard. The UART side of the Teensy is connected a serial-to-USB cable, which is then connected to my Linux host computer.

This might be confusing because there are now USB connections on both sides of the Teensy. But that's just for ease of communicating via serial with the host. I'm reading and writing to the Teensy uart via a Linux USB serial device. On my host, this appears as /dev/ttyUSB1.

I wrote a python program called "teensy-usb.py" which can send commands (specified on the command line on the host) to the Teensy for presentation to the Minnowboard as USB keystrokes. That program is upstream in the Etherkey sketch source repository, in the "client" directory.

The hardware I'm using for the serial-to-USB cable is an FTDI TTL232R-3V3 cable, with a simple 3-wire header connecting the Teensy uart pins (and ground) to the FTDI header.