Skip to content

fix: Change the QEMU testing blog post #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
walterchris merged 1 commit into from
Apr 16, 2026
Merged

fix: Change the QEMU testing blog post #26

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 2 additions & 17 deletions src/blog/2026-04-16-qemu-to-hardware-testing-approach.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,22 +77,7 @@ jobs:
BINARIES: firmware=obmc-phosphor-image-canopy-qemu.static.mtd
```

The hardware workflow is more involved. HPE ProLiant Gen11 systems use a GXP SoC with a secure boot chain that requires signed firmware. The build step injects a signing key, and the firmware job concatenates the OpenBMC image with the GXP bootblock to produce a complete 32 MB flash image before uploading to FirmwareCI:

```yaml
# .github/workflows/build-hpe-proliant-g11.yml
- name: Prepare flash image
run: |
cat obmc-phosphor-image-hpe-proliant-g11.static.mtd \
9e-gxp-dl360.rom > flash-image-hpe-proliant-g11.rom
size=$(stat --printf='%s' flash-image-hpe-proliant-g11.rom)
if [ "$size" -ne 33554432 ]; then
echo "::error::Flash image size is ${size}, expected 33554432 (32MB)"
exit 1
fi
```

The size check is a simple guard — if the flash image is not exactly 32 MB, something went wrong in the build or the bootblock concatenation, and there is no point flashing it onto hardware.
The hardware workflow is similar but the build is more involved. HPE ProLiant Gen11 systems use a GXP SoC with a secure boot chain that requires signed firmware. The build step injects a signing key and appends the GXP bootblock, producing a complete 32 MB flash image directly. The resulting binary is uploaded to FirmwareCI without any post-build processing.

The hardware pipeline also has a `firmwareci-main` job that only runs on pushes to `main` (not on PRs). This triggers a more comprehensive test suite that includes boot timing regressions, fan control validation, and VUART console verification — tests that take longer and exercise the physical server more aggressively.

Expand All @@ -102,7 +87,7 @@ The hardware pipeline also has a `firmwareci-main` job that only runs on pushes

The QEMU DUT starts a `qemu-system-arm` process with an AST2600 EVB, forwards SSH to port 2222 and Redfish to port 2443, waits 100 seconds for boot, then runs the test suite.

The hardware DUT uses `newdutctl` to control a physical HPE DL320 Gen11 in the lab. The test sequence: power off, write the firmware image to a flash emulator connected to the server's SPI bus, power on, wait for the "Phosphor OpenBMC" boot banner on the serial console (10-minute timeout), then run the test suite. This is hardware-in-the-loop testing — the BMC boots real firmware on a real GXP SoC.
The hardware DUT uses [`dutctl`](https://github.com/BlindspotSoftware/dutctl) to control a physical HPE DL320 Gen11 in the lab. The test sequence: power off, write the firmware image to a flash emulator connected to the server's SPI bus, power on, wait for the "Phosphor OpenBMC" boot banner on the serial console (10-minute timeout), then run the test suite. This is hardware-in-the-loop testing — the BMC boots real firmware on a real GXP SoC.

## What we test

Expand Down
Loading