On 9/28/2026 7:46 AM, Andrew Jones wrote:
On Thu, Sep 17, 2026 at 02:44:03PM -0300, Daniel Henrique Barboza wrote:
Add tests for the recently added riscv-server-ref machine:

- a new test_opensbi.py test.  The idea is to have a quick test that can
catch trivial regressions that would prevent OpenSBI to finish;
- a new Linux boot "thorough" test that will boot the machine up to the
buildroot prompt.
- a TPM specific selftest for the riscv-server-ref board.  The test
will be skipped if there's no 'swtpm' in the host.

Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Chao Liu <[email protected]>
Reviewed-by: Nutty Liu <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Sunil V L <[email protected]>
---
  tests/functional/riscv64/meson.build        |  2 +
  tests/functional/riscv64/test_opensbi.py    |  4 +
  tests/functional/riscv64/test_server_ref.py | 90 +++++++++++++++++++++
  3 files changed, 96 insertions(+)
  create mode 100755 tests/functional/riscv64/test_server_ref.py

diff --git a/tests/functional/riscv64/meson.build 
b/tests/functional/riscv64/meson.build
index d1a3e6c2bf..2d22e49efd 100644
--- a/tests/functional/riscv64/meson.build
+++ b/tests/functional/riscv64/meson.build
@@ -3,6 +3,7 @@
  test_riscv64_timeouts = {
    'boston' : 120,
    'k230' : 120,
+  'server_ref' : 120,
    'tuxrun' : 120,
  }
@@ -15,6 +16,7 @@ tests_riscv64_system_thorough = [
    'endianness',
    'boston',
    'k230',
+  'server_ref',
    'sifive_u',
    'tt_atlantis',
    'tuxrun',
diff --git a/tests/functional/riscv64/test_opensbi.py 
b/tests/functional/riscv64/test_opensbi.py
index 0f8beb7e7a..367e131164 100755
--- a/tests/functional/riscv64/test_opensbi.py
+++ b/tests/functional/riscv64/test_opensbi.py
@@ -36,5 +36,9 @@ def test_riscv_virt(self):
          self.set_machine('virt')
          self.boot_opensbi()
+ def test_riscv_server_ref(self):
+        self.set_machine('riscv-server-ref')
+        self.boot_opensbi()
+
  if __name__ == '__main__':
      QemuSystemTest.main()
diff --git a/tests/functional/riscv64/test_server_ref.py 
b/tests/functional/riscv64/test_server_ref.py
new file mode 100755
index 0000000000..ad29094dbe
--- /dev/null
+++ b/tests/functional/riscv64/test_server_ref.py
@@ -0,0 +1,90 @@
+#!/usr/bin/env python3
+#
+# Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+"""
+riscv-server-ref board test
+"""
+
+import os
+import tempfile
+import subprocess
+
+from qemu_test import QemuSystemTest, Asset
+from qemu_test import wait_for_console_pattern
+from qemu_test import skipIfMissingCommands
+
+class RiscvServerRefTest(QemuSystemTest):
+    """
+    Test the riscv-server-ref board
+    """
+
+    ASSET_KERNEL = Asset(
+        ('https://github.com/danielhb/qemu-machine-boot/raw/refs/heads/'
+         'master/riscv/images/virt64/buildroot/Image'),
+        '6bacc876c769c1bb6057d2bf549eba67fbe83916e8223f9fe21c8e8fff665a36')
+
+    ASSET_ROOTFS = Asset(
+        ('https://github.com/danielhb/qemu-machine-boot/raw/refs/heads/'
+         'master/riscv/images/virt64/buildroot/rootfs.ext2'),
+        'f00bb88749f945d80675540a1338bd1ccb226574685a5b6c65ab44027d0411a8')
+
+    def do_test_boot_linux_test(self, tpmstate_dir=None):
+        self.set_machine('riscv-server-ref')
+        kernel_path = self.ASSET_KERNEL.fetch()
+        rootfs_path = self.ASSET_ROOTFS.fetch()
+
+        self.vm.add_args('-kernel', kernel_path)
+        self.vm.add_args('-append', 'rw rootwait root=/dev/sda')
+        self.vm.add_args('-drive',
+            f'file={rootfs_path},format=raw,id=hd0,snapshot=on,if=none')
+        self.vm.add_args('-device', 'ich9-ahci,id=ahci0')
+        self.vm.add_args('-device', 'ide-hd,drive=hd0,bus=ahci0.0')

Any reason not to use nvme here like the documented command line does? We
could drop AHCI in that case.

Didn't find a way of booting a nvme type disk with "-kernel" that produces an 
output
compatible with boot_linux_test.

In the (hopefully near) future, when we have an upstream EDK2 firmware 
compatible with
this board, we'll revisit this test.  We want to have the same command line 
we're
reporting in the docs.

For now we want a sanity check to see if the board is sane.  Using AHCI is good 
enough.


Thanks,
Daniel



Thanks,
drew


Reply via email to