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 …


Hey @Ardvan
you are correct.

if [ “$sha” != “$ME_RAR_SHA” ]; then
[leaving out lines for the sake of brevity]
rm -f …/$rar_filename 2>/dev/null

I just realized that I have copied over an old version of me_11_repository. The file I downloaded has the correct (read: expected sha256). Will switch the files and try again.


Same issue, it’s severe because without an update of the BIOS, my Librem 13 v2 wont stop shutting down when I make it work a little hard because fans don’t spin fast enough. I am stuck with my work until this is fixed.



Not really sure, what is going on, but I can confirm that the coreboot-script comes with crossgcc. The background is that your Librem has a 64it CPU, but Coreboot is compiled for 32bit. Hence the crosscompiler is needed. Also I think the coreboot-team patched this GCC, because there are some tweaks to the linker, that “normal” GCC sometimes cannot handle.
There is an option is Coreboot’s config that reads:

Many toolchains break when building coreboot since it uses quite unusual linker features.

The option is called CONFIG_ANY_TOOLCHAIN. To me this means that coreboot will per default build it’s own, tweaked version of CrossGCC.

Can you calrify, when the error occors? I guess you are using the vanilla script? When have you downloaded it?



On my end, it seems that when encountering the error, running the script again fixes the issue, even though it’s weird to have an error on first run.

I also had that mega issue and had to fix it, then re-run the script.

So I ran the script once, met the mega issue.
Ran the script again, met the flags compilation error.
Ran it again and it worked.

Hope this helps.



thanks for the quick reply. Trying to give some answers to your questions:

I am attempting to build with ‘’, which I downloaded from the ‘usual’ place’ (I wish there would be a clean download link with changelogs somewhere.) For the record, this is the md5sum:


and it must be newer than the one I used to build coreboot-4.8.1-7-g30300027ce-4.8.1-Purism-3 presently on my system as there are entries for the librems 13v4 and 15v4.

I guess my first point is that while I could build 8-9 months ago, the build now fails. Whether this is a change in, a change in the toolchain resulting from newer versions that were installed in PureOS, or changes in the coreboot source code I can’t tell.

The compile error happens when the freshly built (cross) compiler attempts to build the actual coreboot firmware. I add a longer output from the build output at the end of this post. This should help pinpoint where things go wrong.

For the record, I also encountered the mega download problem, but this is easy to workaround, and the attempt to automatically download this stuff almost never worked in the past. Further, my machine is a librem13v3, PureOS is regularly updated, and for whatever reasons my default comiler is still gcc/g++ v7 (although gcc8 is installed as well).

Could you try a fresh recompile/build (pulling everything from git – this is what I did, I ran in a pristine directory, not trying to update older builds?

Thanks for your help!


… [much more earlier output …]

You can now run IASL ACPI compiler from /home/sboresch/stuff/morestuff/coreboot/util/crossgcc/xgcc
# configuration written to /home/sboresch/stuff/morestuff/coreboot/.config
Skipping submodule ‘3rdparty/blobs’
# configuration written to /home/sboresch/stuff/morestuff/coreboot/.config
HOSTCC util/sconfig/lex.yy.o
HOSTCC util/sconfig/
HOSTCC util/sconfig/main.o
HOSTCC util/sconfig/sconfig (link)
SCONFIG mainboard/purism/librem_skl/variants/librem13v2/devicetree.cb
CC bootblock/mainboard/purism/librem_skl/static.o
CC bootblock/arch/x86/boot.o
CC bootblock/arch/x86/bootblock_crt0.o
CC bootblock/arch/x86/cpu_common.o
GEN build.h
CC bootblock/arch/x86/id.o
CC bootblock/arch/x86/memcpy.o
CP bootblock/arch/x86/memlayout.ld
CC bootblock/arch/x86/memset.o
CC bootblock/arch/x86/mmap_boot.o
CC bootblock/arch/x86/timestamp.o
CC bootblock/commonlib/cbfs.o
CC bootblock/commonlib/iobuf.o
CC bootblock/commonlib/lz4_wrapper.o
CC bootblock/commonlib/mem_pool.o
CC bootblock/commonlib/region.o
CC bootblock/console/console.o
CC bootblock/console/die.o
CC bootblock/console/init.o
CC bootblock/console/post.o
CC bootblock/console/printk.o
CC bootblock/console/vsprintf.o
CC bootblock/console/vtxprintf.o
CC bootblock/cpu/intel/fit/fit.o
CC bootblock/cpu/x86/lapic/boot_cpu.o
CC bootblock/cpu/x86/mtrr/earlymtrr.o
CC bootblock/cpu/x86/pae/pgtbl.o
CC bootblock/cpu/x86/tsc/delay_tsc.o
CC bootblock/device/device_simple.o
CC bootblock/device/i2c.o
CC bootblock/drivers/i2c/designware/dw_i2c.o
CC bootblock/drivers/pc80/rtc/mc146818rtc.o
CC bootblock/drivers/pc80/rtc/mc146818rtc_boot.o
CC bootblock/drivers/spi/bitbang.o
CC bootblock/drivers/spi/boot_device_rw_nommap.o
CC bootblock/drivers/spi/spi-generic.o
CC bootblock/drivers/spi/spi_flash.o
CC bootblock/lib/boot_device.o
CC bootblock/lib/bootblock.o
CC bootblock/lib/bootmode.o
HOSTCC cbfstool/fmaptool.o
HOSTCC cbfstool/cbfs_sections.o
HOSTCC cbfstool/fmap_from_fmd.o
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
sboresch@sbpuri:~/stuff/morestuff$ cd coreboot/
sboresch@sbpuri:~/stuff/morestuff/coreboot$ less .config
sboresch@sbpuri:~/stuff/morestuff/coreboot$ make
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’


Exact same issue here (Librem 13v2). I downloaded the script today, ran it on a fully updated PureOS, had to download that one MEGA file manually, and got the same error about ‘union flashmap_flags’ and whatnot. Running the script again also magically fixed the issue for me.