I'm following the instructions of the Build HOWTO section of the Coreboot Wiki (https://www.coreboot.org/Build_HOWTO) and I'm having some
issues.
Following the quote from the wiki "It is worth checking the Supported Motherboards (https://coreboot.org/status/board-status.html) page to see if
your mainboard is known to work with a particular version of coreboot. If your board is listed and
you want to try a known-working version, click the "upstream tree" link to find the commit hash and
then check it out in git:"
So I find the commit hash and run:
git checkout 87e36c442e33388493f259bfa14db460a4f02753
Which returns the output:
warning: unable to rmdir '3rdparty/intel-sec-tools': Directory not empty
warning: unable to rmdir '3rdparty/qc_blobs': Directory not empty
warning: unable to rmdir '3rdparty/stm': Directory not empty
Updating files: 100% (8604/8604), done.
M 3rdparty/amd_blobs
M 3rdparty/arm-trusted-firmware
M 3rdparty/blobs
M 3rdparty/chromeec
M 3rdparty/fsp
M 3rdparty/intel-microcode
M 3rdparty/libgfxinit
M 3rdparty/libhwbase
M 3rdparty/vboot
Note: switching to '87e36c442e33388493f259bfa14db460a4f02753'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
If I try to proceed with:
git submodule update --checkout
I receive the output:
fatal: remote error: upload-pack: not our ref 0ac1af437d2cc461b94bd2cdaa195e86dd481d37
Fetched in submodule path '3rdparty/amd_blobs', but it did not contain 0ac1af437d2cc461b94bd2cdaa195e86dd481d37. Direct fetching of that commit failed.
I'm not that familiar with git so I apologize if this is a simple problem. Sorry for the spam too, I missclicked the return key.
I'm following the instructions of the Build HOWTO section of the Coreboot Wiki (https://www.coreboot.org/Build_HOWTO) and I'm having some
issues.
Following the quote from the wiki "It is worth checking the Supported Motherboards (https://coreboot.org/status/board-status.html) page to see if
your mainboard is known to work with a particular version of coreboot. If your board is listed and
you want to try a known-working version, click the "upstream tree" link to find the commit hash and
then check it out in git:"
So I find the commit hash and run:
git checkout 87e36c442e33388493f259bfa14db460a4f02753
Which returns the output:
warning: unable to rmdir '3rdparty/intel-sec-tools': Directory not empty
warning: unable to rmdir '3rdparty/qc_blobs': Directory not empty
warning: unable to rmdir '3rdparty/stm': Directory not empty
Updating files: 100% (8604/8604), done.
M 3rdparty/amd_blobs
M 3rdparty/arm-trusted-firmware
M 3rdparty/blobs
M 3rdparty/chromeec
M 3rdparty/fsp
M 3rdparty/intel-microcode
M 3rdparty/libgfxinit
M 3rdparty/libhwbase
M 3rdparty/vboot
Note: switching to '87e36c442e33388493f259bfa14db460a4f02753'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
If I try to proceed with:
git submodule update --checkout
I receive the output:
Hello Coreboot Developers!
First, I want to say that it is really a joy to work with Coreboot. The code is
well-written and of high-quality. :)
I'm currently trying to get Tianocore EDK2 running as a Coreboot payload in Qemu
and meeting with limited success, though. I have a working configuration for the
qemu q35 target. Building it for and running it with the 440fx/piix4 chipset
results in the crash below.
Is PIIX4 supported with Coreboot/EDK2 or should this configuration be avoided?
I also appreciate any pointers in how to debug a situation like this. It looks
like the crash happens in EDK2. Is there a way to get an ELF file that objdump
understands, so I can see where in EDK2 code this issue originates from?Â
BS: BS_PAYLOAD_LOAD run times (exec / console): 64 / 2 ms
Jumping to boot code at 0x008008c0(0x7ff9b000)
!!!! X64 Exception Type - 00(#DE - Divide Error)Â CPU Apic ID - 00000000 !!!!
RIPÂ - 000000007F92FAB0, CSÂ - 0000000000000038, RFLAGS - 0000000000000202
RAXÂ - 000000007F938C20, RCX - 000000007F938C20, RDX - 0000000000000008
RBXÂ - 0000000000000008, RSP - 000000007FF4B278, RBP - 000000007FF666E0
RSIÂ - 000000007FF65910, RDI - 0000000000000001
R8Â Â - 000000007FF63480, R9Â - 0000000000000038, R10 - 000000007F93CF08
R11Â - 000000007FF64F08, R12 - 0000000000000000, R13 - 0000000000000080
R14Â - 000000007FF66760, R15 - 000000007FAA9118
DSÂ Â - 0000000000000030, ESÂ - 0000000000000030, FSÂ - 0000000000000030
GSÂ Â - 0000000000000030, SSÂ - 0000000000000030
CR0Â - 0000000080010011, CR2 - 0000000000000000, CR3 - 000000007FC01000
CR4Â - 0000000000000228, CR8 - 0000000000000000
DR0Â - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3Â - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007FBED718 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007F93A018 0000000000000FFF,  TR - 0000000000000000
FXSAVE_STATE - 000000007FF4AED0
!!!! Can't find image information. !!!!
Thanks!
Julian
Sorry, at the moment I could only suggest to "find" a Windows 7 USB,
do a clean install & drivers installation and use this Belkasoft tool
according to ultimate VGABIOS extraction writeup - that's if you need
it quick. However, if you'll achieve a similar access with Lime,
please let us know: it is much better if stuff like this could be done
with the opensource software and no Windows hassle.
On Fri, Apr 16, 2021 at 10:52 PM Peter Stuge <peter(a)stuge.se> wrote:
>
> Gian Lorenzo Spisso wrote:
> > Thank you so much for your reply.
> >
> > Indeed, after a bit of research I've stumbled upon Lime which is a kernel
> > module allowing the dump of the whole memory which I'm doing right now.
>
> Oh good, that's worth a try.
>
>
> > Do you have any pointer on how to locate the bit I'm interested in?
>
> Here's a hex dump of the first 80 bytes of my VGA BIOS:
>
> 0000000: 55aa 80e9 a9e3 3030 3030 3030 3030 3030 U.....0000000000
> 0000010: 3030 b021 e9a1 2059 4000 e00a 3030 4942 00.!.. Y@...00IB
> 0000020: 4d20 5647 4120 436f 6d70 6174 6962 6c65 M VGA Compatible
> 0000030: 2042 494f 532e 2003 5b00 6b00 7900 8bc0 BIOS. .[.k.y...
> 0000040: 5043 4952 8680 a227 0000 1800 0000 0003 PCIR...'........
>
> Bytes 0 and 1, 0x55 and 0xaa, mark the start of the option ROM,
> and offsets 0x44-48 (0x86 0x80 0xa2 0x27) contain the PCI ID of the
> graphics hardware that this option ROM is for.
>
> The PCI ID of my graphics hardware is 8086:27a2; note that the two
> 16-bit numbers are stored little-endian in the image.
>
> Searching for this in e.g. a large file again needs some programming,
> because the individual bytes (0x55, 0xaa, or the ID bytes) will occur
> quite frequently.
>
> One option might be to first look for some text strings in the
> internal VGA option ROM and see if they occur in more locations in
> the new memory dump, to then search only those regions manually.
>
>
> > I am alsok wondering, should I make sure my gpu is running since
> > its a discrete card for the vbios to be loaded in memory?
>
> Hm, I think that will depend on the particular hardware design of
> your GPU and of your mainboard. The GPU should not be powered down,
> because the option ROM is probably only accessible through the GPU.
>
>
> Finally, if the software approach fails, another method may be to look
> for the flash chip on the mainboard and read it out with hardware means.
>
>
> Kind regards
>
> //Peter
--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
Hi,
I'm trying to build Coreboot with Nix [1] and am facing some issues. I'm
wondering whether someone has already tried this before and can give some
pointers. My specific problem is how to nicely package the toolchain that
coreboot requires.
Any hints are appreciated. :)
I did discover https://nixos.wiki/wiki/Coreboot, but this doesn't help with the
toolchain issue when coreboot is built as a Nix derivation...
Thanks!
Julian
[1] https://nixos.org/
As I'm trying to port all existing CBFS uses to the new APIs that
support verification, the CONFIG_SMMSTORE_IN_CBFS option is a bit of a
problem: It's the only CBFS use case where coreboot is actually trying
to write back into CBFS, and thus needs access to the raw flash
offsets of files (which is something I'm trying to stop from leaking
out of the abstraction).
Does anyone still need this? As far as I know it was just a hack
invented to backport SMMSTORE onto a Chromebook that couldn't make
FMAP changes anymore, and we never ended up using it after all. Anyone
still using SMMSTORE today should be putting it in a separate FMAP
section. Would anyone mind if I just remove the CBFS option?
Hello, the folllowing is probably not the best-worded E-mail ever (especially as someone completely new here even though a laptop I use has been running Coreboot for some time), but I hope it can still be understood anyway and without coming off in a negative way.
Tl;DR:
1. Possible new Asus p8h61-m-lx2 port
2. Coreboot + PCI-E dGPU + Windows install how (if someone here has expertise in setting up something like that)?
3. where/how to get i3-2100 vbios?
1. I was tempted by a relatively well-priced p8h61-m-lx2 with the hope of compatibility with the p8h61-m-lx preset, but I couldn't get the p8h61-m-lx2 to work with the p8h61-m-lx's preset, and while I haven't tried the one made for the p8h61-m-lx3 I have run Autoport on the p8h61-m-lx2 and (p.s. I don't really know what I'm doing) after some copying and pasting from the p8h61-m-lx folder and commenting out some of the lines Autoport generated it seems to boot. I think it may be a good idea to upload those Autoport results, but how exactly would I do that? (uploading the entire Coreboot directory complete with the GCC I believe would've been built inside of it along with various binary blobs would probably not be very wise?) I suspect just uploading the src/mainboard/system_manufacturer directory that was generated may be enough (or maybe do a new git clone of coreboot's repository manually 'patching' that with the generated folder plus some renaming and some edits to the relevant Kconfig files and uploading the 'patched' version somewhere?) but perhaps I missed something else Autoport spat out.
Working: ps/2 keyboard (in Seabios at least), i3-2100 iGPU with libgfxinit, PCI-E dGPU (booted with nomodeset but my video card doesn't seem to play well with Linux with the default settings regardless of BIOS) either with Graphics initialisation set to none or to the Card's vbios, Ethernet, Sound output to headphones, (probably all) USB ports, USB headers (only tested one at a time but all seem to work), PCI-E USB 3.0 card (only tested in Seabios).
Problem: I only had one Sata storage drive connected and it seems only the one SATA port to which it was connected when I ran Autoport worked once Coreboot was installed (ran Autoport at least twice and different ports when Autoport ran seem to have resulted in different operational ports under Coreboot).
Untested: Suspend, etc
2. Does anyone have experience of Installing Windows on a desktop Sandy/Ivy Bridge (or perhaps Haswell, using a patch that was never merged notwithstanding) system with coreboot on it (set to use a dGPU's vbios, I don't think Windows' installer can be accessed when booting with libgfxinit)? I'm thinking about trying to install Windows on the system with coreboot present but as coreboot's documentation warned I was met with a BSOD. The closest I seem to have come to a solution is booting that system (with coreboot set to load a vbios blob) into a distro and then using SSDTtime to extract what I believe can be referred to as the ACPI's .aml file, decompiling that with iasl, and then have the result of that replace the dsdt.asl present in the motherboard's directory, and then rebuild coreboot and flash the resulting BIOS.
The problem then for me was that while the computer somehow made it to the windows installer without a bluescreen, I couldn't get any input from the keyboard or mouse to work.
I'm honestly about out of ideas and ready to give up on that exercise, but I suppose asking here one last time if someone actually has done something like that successfully before actually giving up can't hurt.
3. One idea I haven't properly tested on the p8h61-m-lx2: does someone know where a vbios for the i3-2100 can be obtained? One thing I haven't really tried is installing Windows with the iGPU's vbios (a laptop from that era being able to run windows 10 for me when compiled with the vbios was the reason I thought the entire idea of coreboot + dGPU + Windows should be possible). I've got an i3-2100, how can I get the correct vbios file for it (assuming it would work as well as on the laptop?). I've tried the vbios files from I believe "Driver Revision: https://downloadcenter.intel.com/download/22520/Intel-Graphics-Media-Accele… but none seem to work at all. While the web page implies that it only works with earlier iGPUs the readmes in the actual archive did make a reference to 2nd-gen processors, which kind of gave me hope.
Assuming I do manage to make it work with an iGPU vbios, would planning to have Windows be able to use a dGPU be overoptimistic?
Thanks in advance for the response.
Hello everyone,
I know this question had been asked many times, but is it possible to have Coreboot on modern hardware?
After looking at a video ([https://www.youtube.com/watch?v=Tt3bXZXsrE4](https://www.youtube.com/watch?…) I learned that some people were able to put coreboot on recent thinkpads by soldering a new BIOS chip.
After some research on the Internet, I found out coreboot couldn’t be port to modern hardware because of an Intel technology which encrypt the bios (I might be wrong, if so, sorry). On the other end, companies like System76 are able to ship modern processor with Coreboot.
I’d be more than happy to tinker with my hardware, so how you would you do to put coreboot on a recent thinkpad by replacing the bios chip?
Thanks in advance.
Hello so i was talking to my friend about coreboot but i saw that only the SFF version of the compaq 8200 was compatible and so i wanted to know why that is? Also will coreboot be available for the compaq 8200 in the future?
Sent with [ProtonMail](https://protonmail.com) Secure Email.