[GSoC 2026] automated testing framework for Haiku EFI bootloader

tahamirza · March 28, 2026, 4:06pm

Hi,

I am Taha Mirza, 2nd year CS student, I have already introduced my self. I was working on unit testing for the support kit and figure out inconsistent coding structures some using fixtures, some with callers/suties. After some directions though mentor, I decided to transit to something really matters to haiku the most, the thing is, there is no testing framework available for Haiku EFI bootloader.

Context
After power on, the uefi motherboards firmware look for the haiku_loader.efi in ESP partition. Now it loades into memory start executing, it finds the partiion information from UEFI through Protocols like EFI_BLOCK_IO_PROTOCOL to read raw disk, then builds the bootable menu from the BFS(haiku file system). now comes finding kernel here in BFS, and then finally kernal takes control. But before the kernal working officially starts, HEISENBUG (not reproducible) booting errors may occur.

Briefly what i see though code:
1.UEFI executes → efi_main(efi_handle image, efi_system_table *systemTable) that uses Protocols to look for raw disk for kernel loading. After that,

2.main(&args) starts the kernal and uefi finally handles the control.

Problem:

1.failed to find kernel due to inconsistent report of firmware/motherboard/hardware

2. no way to reproduce the booting errors due to no testing available

3. lack of testing infrastructure here.

Do we Really need a testing framework for EFI bootoader ?
No real simulation of EFI firmware or hardware edge cases.
No infrastructure to inject or test problematic partition tables, firmware bugs, or random failures.
No automated test suite for the EFI loader path.
No way to reliably reproduce or debug random boot failures (like the EFI loader not finding a boot partition).
No coverage for real-world, user-facing bugs in the boot process.

Framework:

Figure out the shadow header problem (“efi_platform.h”, EFI_BLOCK_IO, EFI_STATUS, UINTN does not exist in our os)
Write mock EFI structs
Figure out how to compile bootloader code on a host
Write their own fake disk images, kBootServices, HandleProtocol
Connect everything to CppUnit

Questions/Feedback:
I understand the shadow header idea — replacing efi_platform.h with a host-compatible version. But I am not sure where exactly the type conflicts happen.
Any suggestion to make the tesitng framework possible would be appreciated.

PeterW · March 28, 2026, 9:04pm

Did you have help from AI with the text?

Anyway, some things seem strange to me. You don’t need to write a bootloader for EFI Haiku. You can use GNU EFI to write EFI related code. There’s no need for mock EFI structs. There’s no need for raw disk access at EFI level.

Or did I misunderstand something? Then sorry, anybody correct me.

tahamirza · March 28, 2026, 10:19pm

I am not writing new bootloader for EFI, the draft needs clarity i took references from AI but wrote myself.
Actually, I am building testing framwork for it so that the bootloader itself be easily tested to reproduce errors.

Mentor Kapix, himself faced issue, loader wasnt able to find the bootable partition, these errors sometimes occurs and sometimes dont.

currently there is no test coverage for the bootloader of haiku. In order to test, how do i provide him worng inputs - worng order of partitions ? and compare with expected?

key issue is to somehow provide controlled input to the bootloader to reproduce expected errors, this is needed to do test in few mili sec instead of complete hardware’s firmware input which requires much more time.

Why moacking?
controlled input, which we cannot control through firmware.
reproducing the expected error
Run test scenarios, without needing a VM, UEFI firmware.
quickly runs the test.

i might be wrong and i would appreciate corrections,

PeterW · March 28, 2026, 10:37pm

I don’t see a way to test without some VM. Anyone sees a way?

VoloDroid · March 31, 2026, 5:11pm

Sure, why not. That’s the whole idea behind writing mocks, to be able to test it in a controlled local environment. Have a look:

github.com/tianocore/edk2

UnitTestFrameworkPkg/ReadMe.md

master

# Unit Test Framework Package

## About

This package provides unit test frameworks capable of building tests for multiple contexts including
the UEFI shell environment and host-based environments. It allows for unit test development to focus
on the tests and leave error logging, result formatting, context persistence, and test running to the framework.
The unit test framework works well for low level unit tests as well as system level tests and
fits easily in automation frameworks.

### Framework

The first unit test framework is called **Framework** and is implemented as a set of EDK II libraries.
The Framework supports both host-based unit tests and target-based unit tests that share the same
source style, macros, and APIs. In some scenarios, the same unit test case sources can be built
for both host-based unit test execution and target-based unit test execution. Host-based unit tests
that require mocked interfaces can use the mocking infrastructure provided by
[cmocka](https://api.cmocka.org/) that is included in the UnitTestFrameworkPkg as a submodule.

### GoogleTest

This file has been truncated. show original

tahamirza · March 31, 2026, 5:16pm

mocking would allow us to control the UEFI hardware input to the Firmware.
We still need QEMU environment to run the firmware? isnt it ?

I am able to reach here.

Here is my Proposal

the final workflow I am able to reach,

KapiX · March 31, 2026, 5:30pm

It seems you have revoked access to the proposal file.

tahamirza · March 31, 2026, 5:32pm

i have edit the permission

tahamirza · March 31, 2026, 5:34pm

Last minutes ….

I have mention this package as well though i havent explored it yet.
Should i submit it ?

tahamirza · March 31, 2026, 5:36pm

I have messed up.

the submisison has closed ….

tahamirza · March 31, 2026, 5:46pm

Got it, thank god, it was glitch and took my soul instantly.
I have submit the proposal

Thank you Haiku Community.