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).
In this thread https://firstname.lastname@example.org/thread/FTHN… 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.
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
Before I dig in without knowing the code: x86emu currently (
In file included from src/device/oprom/x86emu/x86emui.h:65,
src/device/oprom/x86emu/debug.c: In function 'x86emu_dump_regs':
src/device/oprom/x86emu/debug.h:46:22: error: implicit declaration of
function 'printk'; did you mean 'printf'?
#define printf(x...) printk(BIOS_DEBUG, x)
src/device/oprom/x86emu/debug.c:366:5: note: in expansion of macro
printf("\tAX=%04x ", M.x86.R_AX );
I append the config. Also, there's noone in MAINTAINER for it, and
appearently it's not build-tested :(
Hello and thank you in advance for your time.
I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
8262SE and coreboot installed. I bought from another supplier 4 memory
sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread should
work with coreboot. I am able to start the assembled system and to get
serial output. According to the logs, coreboot first does the
initialisation and training of the memory and then start working on the
PCIs. At one point in the boot sequence, I get the following message:
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
Jumping to boot code at 000ff06e(b7cc1000)
CPU0: stack: 00150000 - 00151000, lowest used address 001509e0, stack
used: 1568 bytes
entry = 0x000ff06e
lb_start = 0x00100000
lb_size = 0x00116270
buffer = 0xbfdd3000
Then it stalls for like 20-30 seconds and the booting process restarts
from the beginning. I had considered different options in order to boot
and I would like to know if someone would have any recommendations.
Right now my priority is to get the system up and working. I can worry
about installing coreboot later, but having it now is for sure a plus:
1) Buy a new chip with the original ASUS BIOS in order to boot the
2) Externally flash the chip I have right now with a newer version of
coreboot. I probably have enough things at home to flash it, but I have
not found information from ASUS. In coreboot there is some information
but very general and not enough for my knowledge. As far as I have read
from flashrom, I should be able to flash it using a Raspberry Pi or a
BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
know which model is the BIOS chip to check if it is supported.
3) The moderboard datasheet has a section called: "Force BIOS
recovery setting", which says that in order to flash the proprietary
BIOS, it is as simple as changing a jumper an inserting an USB stick. I
would have already done it if I would not be reluctant to believe that
it is that simple.
Which are your thoughts about this ideas? Any other one that would be
simpler and would let me boot the full system?
Thank you very much,
NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
configurations both 1.35 and 1.5V. Logs are slightly different, in the
training section, but the problem while booting remains. A USB stick
with Debian Installer has been plugged-in during since boot process
I believe the recommendation is to start with one of the boards
closest to what you have (ie. one of the boards with the same
northbridge, southbridge, and superio), try to figure out any
adjustments you can tell it needs and test and debug.
The northbridge is part of the cpu and depends on which cpu you
install. For the fx series it would be agesa family 15tn. I'm not sure
how the cpu support works, depending on your build, you may only get
support for certain processor families? I don't think the agesa code
is very well supported.
You posted your flashrom log in place of your superiotool log, but the
manual says it has an ITE superio. There are amd sb700 boards on
boardstatus with either the ITE IT8712F or ITE IT8718F.
For flashing you would need a testclip and something to drive it. The
dual bios feature won't help with coreboot, since it isn't jumper/
hardware switched based that I can tell.
I was going to mention needing to figure out the option rom or
graphics init for the onboard graphics, but it looks like your using a
separate video card, so it can probably be ignored.
Hopefully this helps you and I didn't get too much of it wrong.
Has anything changed with the syntax highlighting on Gerrit recently?
I'm seeing many function parameters in orange (which is hard to read
on a green background), and signs that it misparsed the code somehow
(e.g. coloring opening braces different than closing ones). Example
On 4/29/19 7:23 PM, Matteo Carlini wrote:
> Hi Marek,
> Thanks for raising the topic across the communities. The question is probably how many people from the various projects are going to attend Plumbers this year in Lisbon, so to create some critical mass.
> The TF.org project is planning a significant presence at the Open Source Firmware Conference happening the week before in California (https://osfc.io/), sponsoring the event and submitting few engineering topics. This is another great opportunity to meet and chat on Boot/Firmware topics as well.
The conf being in the US is a barrier for some, for various reasons.
Another upside of LPC miniconf is that you have the kernel people there,
who are taking over once the bootloader starts them, so it would give us
an unique opportunity to synchronize with their needs.
I had some exchange(s) on IRC and Alex Graf mentioned that rather then a
pure bootloader miniconf, we should also pull in OpTee and other such
"resident service provider" projects, since the kernel also communicates
with those and they're installed before the kernel takes over.
> Having a boot miniconf the week after in Europe may be a natural extension, but I'm wondering if people would be willing to travel and attend two similar events in a row...
I cannot answer that, maybe the result of this email can :)