Building coreboot from source (official script)


Ah, I see the “error: branch ‘librem’ not found” is expected on first build:

# checkout master so we can delete the librem branch
git checkout master
# delete it, in case it's our first run, do || true
git branch -D librem || true
git checkout -b librem "$COREBOOT_TAG"
# need to update submodules after the checkout
git sup

So, not sure why I get the hash mis-match at the end. I’m running Debian Strech 9.8 btw.


that script is only designed to update devices already running coreboot, not ones still running the old AMI firmware (surprised there’s any of those left TBH). But dmidecode says you’re running an older coreboot 4.5, release, so I’m a bit confused here.

looking at, under building coreboot on your own machine, it links to the correct/updated build script, lists dependencies, and builds everything else needed (cbfstool, etc). Can you start fresh there and let me know if you still run into issues?


You didn’t read the whole story … that dmidecode output is after I successfully used a different script (linked in the story). But for that other script to work I needed the tools built by the main upgrade script (and I had to very slightly adjust that older Librem13v1 script to use them). I did start fresh with the main update script after getting the old Librem 13v1 script to work.


man, I tried, it’s a mountain of text, and most of it wasn’t relevant to your current issue

so now, the issue is that you’re building using the current updater script, and not getting the correct hash? What’s your build environment (distro/kernel)?


it’s a mountain of text, and most of it wasn’t relevant to your current issue

It is all relevant. It is how I got to the current firmware state. It answers your questions before you ask them. It also includes a suggestion to link to for Librem 13v1 owners somewhere more prominent, and the need to improve the instructions for or tool-prepping of that script.

What’s your build environment (distro/kernel)?

I did mention Debian 9 Stretch. I’m using the latest default kernel, which is linux-image-4.9.0-8-amd64 (4.9.144-3)

I’m not asking for first-line tech support. I figured out how to solve my own problems to a pretty great extent. The latest firmware I built would probably work fine. Even though it checks hashes of the binary components it extracts from the current firmware, and builds its own toolchain, it’s probably one of these things that is slightly different for my system and causes the final result to have a different hash. Maybe it doesn’t checksum all binary parts, and my my_cleaner-stripped ME is a bit different. (Thus the detailed yet concise history.)


that script is old/deprecated, and 99% of 13v1 users are already running coreboot and don’t need it. For those that aren’t I’ll provide a binary firmware updater package. I just don’t have time to go back and clean up all the old stuff and get the current stuff into better shape as well

the ME firmware region isn’t part of the calculated hash, only the BIOS region containing coreboot. It’s specifically excluded because an older version of the script offered the option to not run me_cleaner, which would result in two different hashes. But yes, still possible for some unaccounted for variables to be influencing the hash. I could completely eliminate that using coreboot’s ‘timeless’ option, but at the cost of the build date not being valid, which isn’t ideal.


Update: I managed to get the expected reproducible hash. It seems I had to remove the binaries I had copied to /usr/local/bin/ in order to make the older ami-to-coreboot script work (cbfstool, ifdtool, rmodtool, flashrom, me_cleaner). They should be the exact same since I copied them from the coreboot build tree built by the latest but maybe the paths were baked into some build output somehow? Or the phase of the moon is right this time, I dunno.

Also, seems to be down right now, I had to find acpica-unix2-20161222.tar.gz from another mirror online and manually put it in the tarballs dir in the coreboot tree.


One more update: actually flashing fails without some manual tweaking, due to:

This coreboot image (Purism:Librem 13 v1) does not appear to
be correct for the detected mainboard (Purism:Librem 13).
Aborting. You can override this with -p internal:boardmismatch=force.


hmm, you must have quite an older version of coreboot on there then. I’d prefer not to script in the boardmismatch option in case someone selects the wrong board, but maybe I can handle that single case.


Building and flashing on Gentoo succeeded with the latest build script! All you need is to find all the dependencies.


I find that good to hear. Was thinking about experimenting with building under Gentoo myself.


Hello everybody,
I was having (yet again) the problem, that I could not download the IntelME-Package via megadown, when using the official build script.

I downloaded the most recent script and dist-upgraded the system to sure that everything is up to date.

The script gave me this output:

Downloading ME 11 Repository from!2ElyFQDT!cC0gTlH8rB9EWD4MGX0mVElT94BauqFn-dBKuoEselc
Please be patient while the download finishes…
Reading link metadata…

and then it just stopped. When I went to the link I could download the package

1450d7ea985fbcf0ea79ba61bdc71ed3c5de52a6a82f14c07120b6b321e97352 /home/user/Downloads/Intel CSME 11.0 Firmware Repository Pack r53.rar

When I copy that file to coreboot/megadown and rename it to “me_11_repository.rar” I get the same error.
Which is because the official script (per default) wants to have everything fresh and deletes any existing files. Furthermore I copied the file to coreboot/megadown. This is the wrong location. The IntelME-Package has to go to just coreboot/ and be renamed to “me_11_repository.rar”.

How are your expirences?

what I am wondering: Why is this even needed? My IntelME is disabled. Shouldn’t this be obsolete?


Had the same problem with the link two days ago. But could copy it with the link into a browser. The I put the file like you did into the coreboot directory a me_11_repository.rar. I think the script checks the files checksum. If it is wrong then it deletes the file and wants to download it again.

It worked for me and the result was correct as expected.

Are you sure the file you downloaded was correct. If the script deletes the file then it was not. If the file is still there you maybe renamed it wrong and the script could not find it or the file is ok now and the script is now passed this step and you have another error.


Am after quite some while trying to run again, more for the fun of it. Aside from the mega related download glitch just reported, which I worked around by manually downloading, the cross-compilation of coreboot fails:

Skipping submodule ‘3rdparty/blobs’
HOSTCC cbfstool/fmd.o
In file included from /home/sboresch/stuff/morestuff/coreboot/util/cbfstool/fmd.c:19:0:
fmd_parser.y:54:20: error: ‘union flashmap_flags’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
In file included from /home/sboresch/stuff/morestuff/coreboot/util/cbfstool/fmd.c:19:0:
fmd_parser.y:30:23: error: field ‘flags’ has incomplete type
cc1: all warnings being treated as errors
make: *** [util/cbfstool/ build/util/cbfstool/fmd.o] Error 1

Anyone has clue what’s going on there??



PS: this is on a librem 13v3, pureos up 2 date. gcc is still gcc-7, but I believe at this point a cross compiler (not the system compiler) is used …