coreboot: Add coreboot firmware table driver

[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
• HP Chromebook 11 G4
• HP Chromebook 11 G5
• HP Chromebook 11 G6 EE
• HP Chromebook 14 G4
• HP Chromebook 14 G5
• HP Chromebook x360 11 G1 EE
• HP Chromebook x360 11 G2 EE
• HP Chromebook x360 14 G1
• Acer C720
• Acer Chromebook 11
• Lenovo N22

Test Plan

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

Every Chromebooks run coreboot.

[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.

[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.

[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)

[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]

[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.

[seuros]

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

[seuros]

fixed standalone module build.

[seuros]

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

[seuros]

fix buildworld build

[seuros]

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

[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.

[seuros]

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

[seuros]

clean up and sync with latest version of coreboot.

[seuros]

For context: the easiest and cheapest way to test this driver is to install FreeBSD on a Chromebook. They all ship with Coreboot.

I’m currently installing FreeBSD on a pile of Chromebooks destined for recycling,
and this driver has been usefull for identifying systems with defective soldered RAM.
That lets me quickly separate the faulty units from the good ones.

This is just one example of everything that happens before we even reach the FreeBSD bootloader:

ID   Stage                                      Stamp (us)   Delta (us)
     ---- ---------------------------------------- ------------ ------------
       11 start of bootblock                            -147903            0
       12 end of bootblock                              -120690        27212
       13 starting to load romstage                     -120685            4
       17 starting LZ4 decompress                        -59875        60809
       18 finished LZ4 decompress                        -59552          323
       14 finished loading romstage                      -59548            4
        1 start of romstage                              -51745         7802
      970 fsp memory init load                            57488       109234
       17 starting LZ4 decompress                         81370        23882
       18 finished LZ4 decompress                        102826        21455
        2 before RAM initialization                      103448          621
      950 fsp memory init start                          139358        35910
      951 fsp memory init end                            322904       183545
        3 after RAM initialization                       376520        53615
        4 end of romstage                                475993        99473
      100 start of postcar                               497608        21614
      101 end of postcar                                 497609            0
        8 starting to load ramstage                      500540         2931
       15 starting LZMA decompress                       531972        31431
       16 finished LZMA decompress                       548759        16787
        9 finished loading ramstage                      565979        17219
       10 start of ramstage                              588389        22410
       30 early chipset initialization                   591348         2958
      971 fsp silicon init load                          630179        38831
       15 starting LZMA decompress                       684384        54205
       16 finished LZMA decompress                       684583          198
      954 fsp silicon init start                         698013        13429
      955 fsp silicon init end                           849107       151094
       31 device enumeration                             904787        55680
       40 device configure                              1434922       530135
      956 fsp enumerate start                           2729757      1294834
      957 fsp enumerate end                             2729806           49
       50 device enable                                 2729819           12
       60 device initialization                         3020629       290810
       70 device setup done                             4172136      1151506
       75 cbmem post                                    4179469         7332
       80 write tables                                  4179484           15
       85 finalize chips                                4897437       717952
       90 starting to load payload                      4904968         7531
       15 starting LZMA decompress                      4964119        59150
       16 finished LZMA decompress                      5207066       242947
      958 fsp finalize start                            5224938        17872
      959 fsp finalize end                              5235104        10165
      960 fsp end-of-firmware start                     5235110            6
      961 fsp end-of-firmware end                       5238513         3403
       99 selfboot jump                                 5350585       112072

[adrian]

any other feedback before i land this?

[ngie]

• @ziaee needs to provide a ship-it for the manpage changes.

The change seems reasonable to me.

[adrian]

i booted this on a couple of non core boot devices just to make sure nothing goes sideways. so far so good.