coreboot: Add coreboot firmware table driver

[guest-seuros]

Summary

Nexus-attached driver that discovers and parses coreboot's LBIO tables
from physical memory. Exposes firmware metadata (version, build info,
mainboard, serial config, TSC frequency, CBMEM entries) via sysctl
hw.coreboot.*, the firmware console ring buffer via /dev/coreboot_console,
and structured CBMEM entry access via /dev/cbmem ioctl interface.

Tested on:

• Qotom Q535G6 (Kabylake)
• Intel NUC D54250WYK (Haswell)
• Intel NUC D33217GKE (Ivy Bridge)
• Dell 3100 2-in-1 (Gabbiter)
• Dell 3100 (Fleex)
• Lenovo IdeaPad 320s
• Lenovo ThinkPad T480

Test Plan

This requires a machine with recent coreboot version, older version fall gracefully in the value that they don't expose.

[guest-seuros]

I tested this in multiple board as each hardware expose a different set of registry.

The Dells and the Thinkpad are standard coreboot machines, the others i corebooted them. (currently trying to pipeline them to get into coreboot mainline)

I also have a userland utility that use these sysctl instead of parsing the memory log.

[ziaee]

Wow, this is interesting. I've been running FreeBSD coreboot for many years, I'll test this next week on my APU2.

share/man/man4/coreboot.4

4

please consider seeing style(9) for the preferred way to do this now

[imp]

This is cool functionality. Are there any of the tagged data times that the boot loader should be looking at to pass into the kernel via its metadata interface that we get from other locations and coreboot doesn't provide those interfaces so we leave it blank?
Or are we already doing this, and this commit just exposes the data in a new way.
love 'dmesg for coreboot' parts especially.

[guest-seuros]

@imp This initial driver is basic for now and expose activity/timing that happen since power-on. You can see the Dram training, and any delay on the EUFI/Bios

The userland utility is here, once the code is stable and this driver accepted, i could propose to coreboot to adopt the code for freebsd. Their code is linux only.

The coreboot's cbmem approach is just parsing memory.
the cbmem-freebsd leverage this driver to by using the sysctl.

Installing this driver lead me to discover i had a defective ram in one machine and also it exposed D55662.

The are some possible deduplication possible such as passing the framebuffer and cpu frequency directly from coreboot to the kernel but... the Lenovos expose it, the others don't.

This could be interesting for appliances that want to boot in seconds. (firewalls/NAS)

share/man/man4/coreboot.4

4

i update my template file snippet.

Thanks

[kib]

share/man/man4/coreboot.4

62

IMO using some mdoc list or enumeration would be somewhat better WRT the structuring of the text.

69

I think it is better to say 'A character device that exposes the read-only access to the CBMEM firmware console ring buffer', or similar. cdevs cannot be read-only, but access they provide can.

330

I thought that BUGS/CAVEATS should come before HISTORY.

sys/dev/coreboot/coreboot.c

37

sys/param.h is not needed. sys/systm.h is guaranteed to provide it.

103

Could the signature placed at paddr 0?

1144

Why the re-check is needed? scan only returns non-zero if the signature is correct.

1164

Could it be that we find some random signature bytes, which are really not the signature, and lock on them? Then, of course, the sanity checking failing, and the driver does not attach.

I mean, if validation failed, should we continue to scan for signature and retry if found again?

1318

This code seems to be duplicated at least once. Could it be moved to a helper function instead of copy/pasting?

sys/dev/coreboot/coreboot.h

110

What do you mean by 'starts at physical address'?

202

What is the format for timestamp? Is it unix time in seconds?

609

You do not need 'extern'.

sys/dev/coreboot/coreboot_cbmem.c

183

I suggest to use make_dev_s(9). It avoids the race with si_drv1 being NULL some time after the devfs node is created. Also you could request an error instead of panic if the node name was somehow already used.

[guest-seuros]

Address reviewer feedback: make_dev_s, extract map helper, header fixes, man page style

[kib]

include/Makefile

155

We have tradition calling userspace headers for device ioctls like DEVio.h, so in this case it would be corebootio.h.

sys/dev/coreboot/coreboot_cbmem.c

37

sys/param.h is not needed

82

IMO you do not need neither open nor close methods.

107

The check is not needed after the switch to make_dev_s(9)

[guest-seuros]

Address review feedback: rename coreboot_ioctl.h to corebootio.h, remove open/close cdev methods, remove si_drv1 NULL check (make_dev_s), refactor identify to use coreboot_map_table and loop on false positives, fix man page (CAVEATS order, cdev description, interface list), clarify comments

[ngie]

This is really awesome -- thank you for doing all of this work on the driver.

I didn't know about Coreboot until you posted this differential. I had similar ideas to this over a decade ago, but it was always vaporware -- glad to see someone did an awesome job making Coreboot possible (of course Intel did it because they are in the business of selling silicon).

If the GH group description is to be trusted, it looks like Coreboot supports non-Intel architectures.

Moreover, if Coreboot support was added to a platform, does that nuke the need for all of the vendor-specific drivers like asmc (just use ACPI/FDT), or does Coreboot's presence merely augment those drivers so the drivers can still continue to be used? [for those that might be unaware, asmc talks with the System Management Controller on Mac devices, which IIRC is a separate microprocessor]

[guest-seuros]

I didn’t know about Coreboot until you posted this differential.

Funny story: I discovered I had a coreboot machine accidentally. I was digging through a System76 motherboard looking for a FullMAC Wi-Fi card and noticed the firmware tables looked strange. Turned out it was coreboot.

If the GH group description is to be trusted, it looks like Coreboot supports non-Intel architectures.

Yes, coreboot supports multiple architectures (ARM, RISC-V, etc). In practice the supported boards outside x86 are still fairly niche.

For this driver I intentionally limited the implementation to x86 platforms that I could test on real hardware, rather than enabling everything and hoping it works.

There are additional features we could expose later once we have broader testing.

If Coreboot support was added to a platform, does that nuke the need for vendor drivers like asmc?

No -- coreboot doesn't replace those.

Coreboot replaces the platform firmware layer (BIOS/UEFI), but hardware controllers like Apple’s SMC still exist as independent microcontrollers on the board (it a Renesas). Drivers like asmc would still communicate with them normally. The RE work was done years ago in https://github.com/c---/applesmc-next ..

In other words, coreboot mainly provides the initialization and ACPI/SMBIOS tables, and the OS drivers operate on top of that just like they would with vendor firmware.

Mac example

Corebooting a Mac is also not trivial. It requires physically flashing the SPI ROM, and the system effectively becomes a generic PC platform after the flash (macOS will no longer boot).

Additionally, newer Macs with the T2 chip enforce Apple's secure boot chain, which effectively blocks replacing the firmware with anything else.

Another interesting direction after landing this driver would be experimenting with a coreboot payload targeting FreeBSD.

Instead of going through a full BIOS/UEFI flow and bootloader chain, a payload could jump directly to the FreeBSD kernel. This is especially interesting for appliance-style systems.

For example, the board I ported (Qotom Q535G6, Kaby Lake) originally took around 50 seconds to reach a usable system. After replacing the vendor firmware with coreboot, the boot time dropped to about 8 seconds to userland.

That improvement mostly comes from removing the long vendor firmware initialization/discovery phase.

For dedicated appliances such as OPNsense or other firewall/network devices, a minimal firmware -> payload -> kernel path could potentially reduce boot times even further.

This concept works with linux, so there is 0 reason why a Freebsd equivalent can't exist.

PS: The system76 machine is not listed above, because i fried it while touching registries at the bios level. (learned you can flip voltage)

[kib]

sys/dev/coreboot/coreboot.c

43

Please order sys/ headers after sys/systm.h alphabetically.

52

We usually use the <> and full path from sys/ for includes. I suspect using the 'current directory' for finding includes could even break some build scenarios.

sys/dev/coreboot/coreboot_console.c

38

sys/param.h is not needed.
Please order includes alphabetically.
Please use <> for coreboot.h.

For all places.

[ngie]

share/man/man4/coreboot.4

294–298

Shouldn't unloading the module reset the sysctl(9) value to the default, unless set via kenv(8)?

sys/dev/coreboot/coreboot.c

136

Stopped reviewing here.

[guest-seuros]

Address review: fix includes added by IDE linter (kib), clarify sysctl reset on module unload (ngie)

[guest-seuros]

fixed standalone module build.

[guest-seuros]

squash in-kernel build support: add sys/conf/files entry, etc/mtree/BSD.include.dist coreboot dir, and include/Makefile Ndev/coreboot exclusion

[guest-seuros]

fix buildworld build

[guest-seuros]

fix copyright headers: use short SPDX form per style(9)

[guest-seuros]

rename to corebootio

[ziaee]

Please refactor the manual to use standard freebsd sections like HARDWARE, FILES, SYSCTLS, and IOCTLS. Breaking them down into a structured format lets people jump to what they need instead of having to remember where each individual thing they might want to reference is located in every single manual, or read every entire manual when they're trying to do something.

share/man/man4/coreboot.4

33–46

See vt.4 for a good looking example of how we do this.

[guest-seuros]

Address review: refactor man page to standard sections (HARDWARE, IOCTLS, SYSCTL VARIABLES); fix section order (CAVEATS after AUTHORS per mandoc)

[guest-seuros]

clean up and sync with latest version of coreboot.