In this thread https://firstname.lastname@example.org/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.
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 :)
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.
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...
[Arm & TrustedFirmware.org]
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek
> Vasut via TF-A
> Sent: 29 April 2019 14:39
> To: Marek Vasut <marek.vasut(a)gmail.com>
> Cc: u-boot-custodians(a)lists.denx.de; tf-a(a)lists.trustedfirmware.org;
> Subject: [TF-A] [LPC] Bootloader miniconf
> I was pondering whether it would make sense to organize a bootloader
> miniconf at Linux Plumbers . The Linux kernel is what we often start, the
> bootloader projects generally do similar things, hence I think being able to
> meet face-to-face and discuss how to make things better/nicer would be
> Feel free to expand the CC list to other interested parties.
> Thoughts ?
>  https://www.linuxplumbersconf.org/
> Best regards,
> Marek Vasut
> TF-A mailing list
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------- Weitergeleitete Nachricht --------
Betreff: Re: [coreboot] Re: Fwd: Re: Fwd: F2A85M IOMMU still not
working for RIchland CPUS
Datum: Thu, 18 Apr 2019 16:24:42 +0200
Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe>
An: Mike Banon <mikebdp2(a)gmail.com>, coreboot(a)coreboot.org
sudo dmesg | grep microcode
[ 1.177705] microcode: CPU0: patch_level=0x0600111f
[ 1.177708] microcode: CPU1: patch_level=0x0600111f
[ 1.177715] microcode: CPU2: patch_level=0x0600111f
[ 1.177722] microcode: CPU3: patch_level=0x0600111f
[ 1.177761] microcode: Microcode Update Driver: v2.2.
works like a charm.
please inform me if this is still the case: (from libreboot side)
are there any other blobs present in my rom now besides microcode ?
/* my build rom in attachment for inspection. (no vbios included as i
mentioned before radeon gpus are not working, i am running an NV GT210 atm)
AMD SMU firmware
Handles some power management for PCIe devices (without this, your
laptop will not work properly) and several other power management
The firmware is signed, although on older AMD hardware it is a symmetric
key, which means that with access to the key (if leaked) you could sign
your own modified version and run it. Rudolf Marek (coreboot hacker)
found out how to extract this key in this video demonstration
and based on this work, Damien Zammit (another coreboot hacker)
partially replaced it <https://github.com/zamaudio/smutool/> with free
firmware, but on the relevant system (ASUS F2A85-M) there were still
other blobs present (Video BIOS, and others) preventing the hardware
from being supported in libreboot.
Am 18.04.19 um 15:08 schrieb Mike Banon:
> Thank you, Nekoboi. If I understand it correctly: you haven't changed
> anything at coreboot or its' configuration, but your IOMMU suddenly
> started to work? ;-) (unknown what got it working?) Also, please could
> you make almost the same coreboot build, with the only difference is
> these microcodes installed by the unofficial patch:
> , and then try it again with the same Linux to see if it's still
> working. With this patch applied, the microcode level should be
> 0x0600111f (...1f instead of ...0f) to confirm the successful
> On Thu, Apr 18, 2019 at 1:35 PM Kinky Nekoboi
> <kinky_nekoboi(a)nekoboi.moe> wrote:
> IOMMU and system still booting without linux kernel level microcode
> Am 18.04.19 um 11:38 schrieb Kinky Nekoboi:
>> -------- Weitergeleitete Nachricht --------
>> Betreff: Re: [coreboot] Re: Fwd: F2A85M IOMMU still not working
>> for RIchland CPUS
>> Datum: Thu, 18 Apr 2019 11:38:16 +0200
>> Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe>
>> An: Mike Banon <mikebdp2(a)gmail.com> <mailto:email@example.com>
>> CPU : A8-6600K
>> [ 1.271514] microcode: CPU0: patch_level=0x0600110f
>> [ 1.271521] microcode: CPU1: patch_level=0x0600110f
>> [ 1.271532] microcode: CPU2: patch_level=0x0600110f
>> [ 1.271538] microcode: CPU3: patch_level=0x0600110f
>> [ 1.271583] microcode: Microcode Update Driver: v2.2.
>> i compiled from the master tree, build on 16. April 2019
>> no microcode was included in that build.
>> next step i will try if, the problems occur again if i remove
>> updates via llinux kernel.
>> here is cbmem output as attachment
>> Am 18.04.19 um 06:08 schrieb Mike Banon:
>>>> also it seems that IOMMU is working now...
>>> Congratulations with these amazing news! Please tell, what version of
>>> coreboot you've currently installed? Also, have you used this
>>> microcode updating patch from DangerousPrototypes page before building
>>> your current coreboot build?
>>>> maybe cause i have microcode updates in the kernel included this time ?
>>> By the way, the microcode updates provided by Linux are _older_ than
>>> what this "microcode updating patch" is providing : simply because AMD
>>> has shared their latest update with some proprietary UEFI makers but
>>> didn't share them with the opensource world (and so we had to get them
>>> by manually extracting). But if the kernel sees that a newer microcode
>>> version is loaded, it doesn't replace it. Please, could you check and
>>> tell, what microcode version do you see as installed?
>> coreboot mailing list -- coreboot(a)coreboot.org <mailto:firstname.lastname@example.org>
>> To unsubscribe send an email to coreboot-leave(a)coreboot.org <mailto:email@example.com>
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
I was pondering whether it would make sense to organize a bootloader
miniconf at Linux Plumbers . The Linux kernel is what we often start,
the bootloader projects generally do similar things, hence I think being
able to meet face-to-face and discuss how to make things better/nicer
would be beneficial.
Feel free to expand the CC list to other interested parties.