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.

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

any other feedback before i land this?