Today OpenQA mostly runs on virtual machines, but it can get really tricky to find bugs triggered by real hardware. There are only few interfaces required to interact with a machine though:

1) HDMI<br> 2) USB keyboard<br> 3) CD-ROM<br> 4) Remote Power Switching<br>

For 1, I ordered a few HDMI frame grabbers that will only arrive after Hackweek. 2 and 3 should be possible to implement using the USB gadget support in Linux which a lot of ARM devices support - I can definitely donate a Beaglebone Black to whoever is interested. Power switching is a solved problem.

With all these bits in place and a bit of plumbing we should be able to run tests on actual hardware, hopefully extending our test coverage to more tricky scenarios.

Succeeded in emulating USB-mass-storage and USB-keyboard and serial. Also made a RPC for it, so you can use it in code running on any machine. See the <a href="">demo video</a>

Code is in <a href="">a github branch</a>

This allows to boot any machine off a virtual USB-CDROM and automate with keystrokes.

Still to do: emulate a tablet with absolute pointer coordinates and capture screen output.

Looking for mad skills in:

openqa arm usb hdmi

This project is part of:

Hack Week 12


  • almost 5 years ago: bmwiedemann liked Bare Metal OpenQA
  • almost 5 years ago: bmwiedemann started Bare Metal OpenQA
  • almost 5 years ago: algraf removed keyword stm32 from Bare Metal OpenQA
  • almost 5 years ago: a_faerber liked Bare Metal OpenQA
  • almost 5 years ago: joeyli liked Bare Metal OpenQA
  • Show History


    • ancorgs
      almost 5 years ago by ancorgs | Reply

      I guess you are aware of the IPMI and KVM2USB openQA backends and the discussions about real hardware support in the openQA mailing list (sorry, I don't know where to find the archives) that leaded to try IPMI as a first approach.

    • coolo
      almost 5 years ago by coolo | Reply

      the kvm2usb part is basically rusty code and could use some polishing - using HDMI grabber sounds like a good plan, especially if they don't require closed source drivers like the kvm2usb need.

    • algraf
      almost 5 years ago by algraf | Reply

      I just realized that we don't need to jump through hoops with the stm32 board or other cruftyness but instead we can just use the USB gadget support in Linux! So I guess the big task here would be to write a driver for the frame grabber, but that one will still take a few weeks to arrive :(.

      That means for now, the main goal of this project would be to script up working USB hid and mass storage emulation by leveraging the already existing Linux infrastructure. Then add some plumbing to hook it up into OpenQA. Then wait until the hdmi grabber arrives ;).

    • algraf
      almost 5 years ago by algraf | Reply

      For reference:

    • bmwiedemann
      almost 5 years ago by bmwiedemann | Reply

      Btw: from my experience with the kvm2usb, most hardware-specific bugs found are in the graphics drivers (apart from things like having 2 ethernet-ports with one being unconnected, which can be emulated in KVM)

    • matwey
      over 4 years ago by matwey | Reply

      Hm... I think we have to enable modules for usb gadgets in our arm kernel-default.

    Similar Projects

    work on sunxi a64 cpufreq driver (for teres-1, pine64) by mbrugger

    With the teres-1 [1] laptop we have a first arm...

    openSUSE/SLE/Mainline U-boot for some not-yet-supported ARM64 boards by ldevulder

    The Khadas VIM ( is an a...