$ cat defconfig
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory
make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h
$ less src/soc/intel/alderlake/Kconfig
string "Location of FSP headers"
$ less src/drivers/intel/fsp2_0/Kconfig
string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD
depends on ADD_FSP_BINARIES
depends on FSP_CAR
default "\$(obj)/Fsp_T.fd" if FSP_FULL_FD
The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig
> Generic Drivers
(src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk
drwxr-x--- 2 james james 4096 Oct 29 2020 .
drwxr-x--- 9 james james 4096 Jun 14 19:04 ..
-rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h
-rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h
-rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
There has been some talk recently in a smaller group where coreboot needs
to improve the most in public perception, and how to get there.
Consensus has been that we're doing a pretty bad job at promoting all the
hardware that we support in each coreboot version.
There's board-status which I started _years_ ago in the hope that somebody
picks up the slack, but everybody has been busy, myself included. By now
the collected information of the last 7.5 years is compiled into a 12MB
HTML file that takes ages to render on moderate hardware (beware:
https://www.coreboot.org/status/board-status.html), and the process to
collect that data is mostly manual using pretty poor tooling. (Most of the
links on that page don't even work anymore (which I'll fix) due to
gitweb/cgit/gitiles changes on review.coreboot.org (and I only noticed by
Meanwhile, there are several parties that boot test the hardware they care
about regularly, with (often internal) information about how well coreboot
We can't expect all those existing systems to converge into a single
testing framework, but we could make it a single test result reporting
To this end, I invite people interested in that topic to chime in on this
email thread so that we can discuss what we could do to provide a common
place with information about which coreboot versions are bootable on which
boards in a way that makes sense for everybody: users who are interested in
such data as well as testers that already collect it but have no way to
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
I am trying to install windows 8 on coreboot (4.11 branch) + seabios.
The installation stops with the following error message:
Your PC needs to restart.
Please hold down the power button.
Error Code: 0x0000005c
I investigated the error message and found Microsoft's explanation
of 0x0000005c error code. But I don't know how to fix it.
I would appreciate it if anyone can help me figure out the solution.
I spent today trying to get the Supermicro X11SSH-TF working with
the latest Coreboot 4.14 from git.
Board is at vendor firmware 2.5 (latest) and also most recent BMC firmware.
Luckily, writing the image has been possible via the vendor BMC (which
preferably I would like to also replace with u-bmc once Coreboot runs).
After reboot into CB, the screen stays blank. I do not have a serial
connection available at the moment. I do have the BMC, though:
The vendor BMC recognizes the Coreboot image and correctly displays
header information such as build time and version (4.14). Also, the
BMC does read the POST code from Coreboot. It rather quickly cycles
through values and ends up at 0xE3 every time. And stops there.
According to the sources, that step is related to memory init. So to
be sure, I swapped out the Samsung 2x16GB ECC modules with standard
Non-ECC Corsair DDR4. Both functional with the Supermicro firmware,
both POSTing to 0xE3 with Coreboot.
Is there any chance a recent commit has broken stuff with this board?
I read reports that this board worked for some people, so I must have
made a mistake?
Basically I followed the documentation, used the provided configuration
options and supplied the me.bin and descriptor.bin extracted from the
original firmware and kept the rest to defaults. Fsp is taken from the
3rd party repo. Is that fine for this platform?
I would appreciate any pointers or ideas what might hinder success. Will
there be debug output written to the serial console?
If anybody has the board working, could he/she share his
configuration, Coreboot version and 3rd party blobs used?
Also, once I get to run I would love to improve the documentation, so
that people new to the subject like me have an easier time. I went
through a couple of pitfalls that I would like to explain so others
can follow in my footsteps.
I have disabled the Intel ME firmware on a motherboard with Union Point
chipset, and wanted to use intelmetool to confirm that the ME indeed
has been disabled:
# intelmetool -m
Can't find ME PCI device
I have tried to create a patch that adds Union Point support:
@@ -437,6 +437,7 @@
#define PCI_DEVICE_ID_INTEL_LEWISBURG_IE2 0xA1F9 /* IE Lewisburg #2 */
#define PCI_DEVICE_ID_INTEL_LEWISBURG_IE3 0xA1FC /* IE Lewisburg #3 */
#define PCI_DEVICE_ID_INTEL_CANNONLAKE 0xA360 /* Cannon Lake */
+#define PCI_DEVICE_ID_INTEL_UNIONPOINT 0xA2BA /* Union Point */
#define PCI_DEV_HAS_SUPPORTED_ME(x) ( \
((x) == PCI_DEVICE_ID_INTEL_COUGARPOINT_1) || \
@@ -491,4 +492,5 @@
((x) == PCI_DEVICE_ID_INTEL_LEWISBURG_IE2) || \
((x) == PCI_DEVICE_ID_INTEL_LEWISBURG_IE3) || \
((x) == PCI_DEVICE_ID_INTEL_CANNONLAKE) || \
+ ((x) == PCI_DEVICE_ID_INTEL_UNIONPOINT) || \
However, this does not seem to work:
# intelmetool -d -m
ME PCI device is hidden
RCBA addr: 0x00000000
Can't find ME PCI device
I got the information for the patch by running lspci -nn on another
completely identical system, as the HECI device is not showing on the
one I'm talking about here, after the ME has been disabled.
00:16.0 Communication controller : Intel Corporation 200 Series
PCH CSME HECI #1 [8086:a2ba]
Any ideas on what I can do to make intelmetool work with the Union
Thanks in advance.
Issue #312 has been reported by Patrik Tesarik.
Bug #312: [Tianocore] gcc11: UefiPayloadPkg build fails
* Author: Patrik Tesarik
* Status: New
* Priority: Normal
* Assignee: Matt DeVillier
* Target version:
With gcc11 the build of UefiPayloadPkg fails because the brotli code fails.
This bug is fixed 'already' today (after 3 Months) in upstream brotli: https://github.com/google/brotli/pull/893
And the issue was already discussed in upstream EDK2, but it seems to me that the submodule reference(?) not fixed yet.
However, this ticket should make the maintainer of https://github.com/MrChromebox/edk2 aware that a pull of that brotli fix is trickles down somehow. Not sure what's the right way to go here.
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Back in 2017 there was some brief discussion of how to compile coreboot for apollolake, with some uncertainty about the IFWI segment. Does anyone know the current status of coreboot support for apollolake/geminilake? In particular, to replace a Chromebook boot rom?
The coreboot configuration options are confusing in the sense that the intended outcome of particular settings is not explained. For instance, there is coreboot code compiled addressing the Intel FSP, but there are no FSP files generated in the resulting coreboot.rom.
Working from a Chromebook bios upgrade image, it seems that many components might simply be copied from there, but then, there seems to be no tool to extract the complete IFWI segment from an existing bios image, except in pieces that would require reassembly. Is there some way that an existing IFWI segment can be extracted and used in another compiled coreboot image? Or, is there "security" code in the IFWI segment that will prevent a compatible working coreboot rom built in this way?