I'm trying to get OpenBSD to install on an x220 Thinkpad with
Coreboot/SeaBIOS but I'm running into two problems: the ethernet device
doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0 wouldn't
load because the EEPROM had an invalid signature. I have no idea why
OpenBSD doesn't see my HDD though. It's strange because everything works
fine under Linux. And I cannot seem to mount a usb drive under the
OpenBSD installer to attach dmesg errors.
I originally posted this as a bug report to bug report mailing list but
Theo said it would be better suited for Coreboot's and wasn't a bug in
OpenBSD.
https://review.coreboot.org/21774
In case anyone else didn't notice - It is a sandy/ivy system with IOMMU.
This is great and should help get coreboot in to the corporate user world.
Greetings,
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).
Sincerely,
-Matt
In this thread https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.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.
Thanks!
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
usual).
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
different story.
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
P.
Hi,
Before I dig in without knowing the code: x86emu currently (
0987e43aa05bfbafbfdd4952638b79a5084369f8 )
doesn't build:
In file included from src/device/oprom/x86emu/x86emui.h:65,
from src/device/oprom/x86emu/debug.c:40:
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'?
[-Werror=implicit-function-declaration]
#define printf(x...) printk(BIOS_DEBUG, x)
^~~~~~
src/device/oprom/x86emu/debug.c:366:5: note: in expansion of macro
'printf'
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 :(
thanks
martin
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[1] 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:
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
POST: 0x7b
Jumping to boot code at 000ff06e(b7cc1000)
POST: 0xf8
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
system.
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,
Pablo.
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
begins.
[1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
tml
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
attached.