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

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.

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

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]

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)

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.