In this thread https://email@example.com/thread/FT... we found a bug in seabios. Its choosing the wrong option rom in the case when for example on a Intel G41 board you have the internal Intel GPU and have added a external PCIe GPU. Then coreboot switches over to the external GPU for the graphical output but seabios use the option rom for the Intel G41 GPU. In case of x4x/G41 this results in no ability to have a graphical boot mode and thus its not possible to boot some linux live images.
In the linked thread a workaround is been found: "In the "Devices" menu of coreboot, set "Graphics initialization" to "None" ".
This breaks the functionality to have coreboot output with the internal GPU when you pull out the PCIe GPU. The switch should happen automaticly and without the need to recompile/reconfigure coreboot. Changes like https://review.coreboot.org/c/coreboot/+/18504 was made to make this happen.
Would be great if this seabios issue could be fixes.
From what I can find, Linux can only chainload another linux kernel. (via
kexec) Does this mean that a Linux payload like LinuxBoot cannot be used to
boot Windows or another OS, either directly or by chainloading another
payload from CBFS?
It's nice that a Linux payload can provide superior flexibility and
configurability than UEFI with the added benefit of a battle-hardened
environment, but the ability to only boot a Linux OS seems like a pretty
significant limitation (if this is indeed the case).
There is motherboard based on the Intel Rangeley Atom C2000 (C2758) series processor. How to enable the SMBus0 in coreboot? If I use OEM BIOS or BIOS from Intel (EDVLCRB1.86B.0048.R00.1508181657_MPK) for mohon peak crb, then I see on the SMBus0 (i2c-1 in Fedora 28) memory DIMM spd (0x50 & 0x52), clock generator (0x69) and other devices. If I use a coreboot based bios for the Mohon peak platform - I do not see any devices on i2c-1. I see an data exchange on the SMBus0 with oscilloscope at boot time only. When I send "i2cdetect -y 1" command in Linux no activity on SMBus0 and no device found.
It seems that after the switch to a new UI some bits were missed in transition.
Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap): git review
remote: error: branch refs/publish/master/lenovo_z61t_no_ctrl_swap:
remote: You need 'Create' rights to create new references.
remote: User: lemenkov
remote: Contact an administrator to fix the permissions
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
! [remote rejected] HEAD ->
refs/publish/master/lenovo_z61t_no_ctrl_swap (prohibited by Gerrit:
not permitted: create)
error: failed to push some refs to
Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap):
I didn't change anything - so I guess the issue is on the Gerrit's side.
With best regards, Peter Lemenkov.
Recently I had an interesting discussion with a system administrator
who is responsible for several hundred PCs, Routers etc.
His argument was: Imagine it would take you 15 minutes to install a
patch on a computer (all windows machines of course...). If your
company has 1000 computers and you send one admin to install the
patches, it will take him >31 work days, working 8h a day.
That's why, he said, companies are interested in software allowing them
to install stuff on the OS / hard drive remotely through the firmware
I, not dealing with large networks, had never thought about it this
way. But it does make a lot of sense to me, it's about real money (as
So I guess that's indeed a huge reason why Intel and AMD created
Frankenstein, running below UEFI and Kernel. It probably doesn't
explain so much why it's necessary to disallow you switching IME off or
why it needs control about absolutely everything, but that's a
So I'm wondering: What would you do about this reality? Could there be
a different solution other than software in Ring -1 having its sausage
fingers on everything?
Sure, the programmers in a company could install their stuff on their
own, but the office folks, the HR and PR guys and the lawyers? Hmm.
And whether we like it or not, even awesome companies almost
exclusively supply their employees with windows machines and they just
demand solutions allowing their IT-departements to fix everything as
cheap and as easy as possible
with this mail I'm officially starting the 4.10 release process.
As per the first step of our checklist
(Documentation/releases/checklist.md), I hereby announce the intent to
release coreboot 4.10 in about 2 weeks. I'm aiming for May 28th to avoid
releasing into the weekend or on Memorial Day in the US, but I'll likely
lock down the commit we'll designate 4.10 during those days to give some
room for testing.
I created a copy of the checklist on
https://piratenpad.de/p/coreboot4.10-release-checklist, also including the
current state of the 4.10 release notes.
Please test the boards you have around and provide fixes, please be careful
with intrusive changes (and maybe postpone them until after the release)
and please update the release notes (Documentation/releases/
coreboot-4.10-relnotes.md or near the bottom of the etherpad doc, I'll
carry them over into our git repo then).
As promised with the 4.9 release there won't be deprecations after 4.10.
However we need to finalize our set of deprecations we want to announce
with 4.10 that will happen after the 4.11 release (those also belong in the
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
over the past year I did some research on AMD’s controversial Secure Processor (formerly known as Platform Security Processor or PSP). Its firmware is stored in an undocumented area of UEFI images and so I wrote a tool that can parse it. I thought some of you might be interested in that: https://github.com/cwerling/psptool <https://github.com/cwerling/psptool>
It is accompanied by PSPTrace, which can correlate an SPI capture of a boot procedure to the AMD firmware entries so you can deduct some boot logic from it.
A coworker noticed that nvramtool (and the nvramtool man page) both refer to the option CONFIG_HAVE_OPTION_TABLE as the option set to include cmos.layout into the coreboot tables.
"%s: Item %s not found in coreboot table. Apparently, the "
"coreboot installed on this system was built without specifying "
However, CONFIG_HAVE_OPTION_TABLE is set by the board to indicate whether the board is cmos.layout capable. The actual option is CONFIG_USE_OPTION_TABLE, which depends upon CONFIG_HAVE_OPTION_TABLE. The code in src/lib/coreboot_table.c only adds the lb record to the coreboot tables if CONFIG_USE_OPTION_TABLE is set.
The other choice is to make src/lib/coreboot_table.c add the lb record if the board has a cmos.layout (CONFIG_HAVE_OPTION_TABLE) but then userland will have access to a layout that is ignored. I suppose this is what happens if you set CONFIG_STATIC_OPTION_TABLE. This doesn't seem like the right answer to me.
I think this is only cosmetic, but should I submit a patch to change this so that others are not also sidetracked?