An open place to share compliance results of board's firmwares with BIOS, UEFI, ACPI, Multiboot... Anything your software (bootloader, OS...) may rely on.
Every non ad hoc operating system relies highly on standardized interfaces that the firmware and the bootloader(s) are largely responsible for (e.g., the physical memory mapping, EFI services). Non compliant firmwares are likely to cause serious problems and undefined behaviours (e.g., bootloader errors, power management issues). Since firmwares of proprietary boards cannot be replaced with better ones, you could end up with an unusable board. So far, you can only hope and cross your fingers to purchase a board with a firmware correctly implementing the features your OS expects.
Every firmware developer should provide these results. Until then, feel free to share with the community, especially if your results show important errors... Standard testing tools such as Firmware Test Suite (FWTS) or Linux UEFI Validation (LUV) are freely available and allow you to test your firmware with a live CD/USB very simply.
You can use http://rawgit.com/ to render html results without cloning the repository (demo). Raw text files are also generated by the testing tools.
Live images are available and are the easiest way to test your firmware without modifying your OS setup. Simply download it, copy it on a USB key, and boot from it (telling your firmware to do so). Please follow the official documentation of the tool you chose.
Allows to test BIOS, UEFI and ACPI interfaces.
The Firmware Test Suite is officially recommended by the UEFI Board of Directors for ACPI Self-Certification Test.
The easiest way to run it is using the live image. It does everything for you: from running the tools according to the test suites you selected, to saving the results in the key. You can then send the result with a pull request ;)
Install or compile FWTS from the sources.
Usage example:
# root privileges required
$ mkdir my-test && cd my-test
$ fwts -d -f --log-type plaintext,html --batch
# ask fwts to run every non-interactive tests available (--batch), dump firmware log files (-d),
# log the results in HTML (--log-type), and recreate new logs (-f).
$ ls
results.html acpi.log lspcidump.log dmesg.log ...Refer to the reference for more details about available test suites.
Linux UEFI Validation. Similar to FWTS.
The easiest way to run it is also using the live image. It does everything for you: from running the tool, to saving the results in the key. You can then send the resulting directory with a pull request ;)
This repository is meant to be very simple and as straightforward as possible. Results are classified by vendor, board, firmware version, test suite/tool, firmware configuration variants:
<vendor>/<board-tree>/<firmware>/<version>/<testing-tool>/<test-variant>/<test-outputs>
The test-variant should be named after the firmware's settings and described by its README.md.
These firmware settings should influence the results. For example, disabling firmware's secure boot
makes associated test suite fail. Note that tools like FWTS allow you to unselect test suites if
you want to disable some according to your settings. FWTS is also generally able to skip disabled
features.
Structure example of a (not-recommended) Intel NUC DE3815THYKE:
intel
├── nuc
│ ├── de3815tykhe
│ │ ├── README.md
│ │ └── visual-bios
│ │ └── TYBYT10H.86A.0046.2015.1014.1057
│ │ ├── fwts
│ │ │ ├── uefi-linux
│ │ │ │ ├── acpidump.log
│ │ │ │ ├── cpuinfo.log
│ │ │ │ ├── dmesg.log
│ │ │ │ ├── lspci.log
│ │ │ │ ├── README.md
│ │ │ │ ├── results.html
│ │ │ │ └── results.log
│ │ │ └── uefi-windows
│ │ │ ├── acpidump.log
│ │ │ ├── cpuinfo.log
│ │ │ ├── dmesg.log
│ │ │ ├── lspci.log
│ │ │ ├── README.md
│ │ │ ├── results.html
│ │ │ └── results.log
│ │ └── luv
│ │ ├── uefi-linux
│ │ │ ├── luv.html
│ │ │ ├── README.md
│ │ │ ├── parsed
│ │ │ │ ├── bits
│ │ │ │ ├── chipsec
│ │ │ │ ├── efivarfs-test
│ │ │ │ ├── fwts
│ │ │ │ └── kernel-efi-warnings
│ │ │ └── raw
│ │ │ ├── bits
│ │ │ ├── chipsec
│ │ │ ├── efivarfs-test
│ │ │ ├── fwts
│ │ │ └── kernel-efi-warnings
│ │ └── uefi-windows
│ │ └── README.md
│ └── README.md
└── README.md
If the location is still unclear, place your result folder wherever you think it should be and create a pull request that will be reviewed before merging.
Include at least HTML results for easier reading and plain text results to allow diffing between test variants. Optionaly as much logs as you want, especially if you are reporting bugs to firmware teams.