so finally figured this out, the megadown script was failing if the output file already existed, instead of overwriting, when the hash didn’t match expected. I’ve pushed a fix to address this, so please let me know if you continue to experience the issue
Tried it again with a completely new folder and it still hangs at the same step…
@MrChromebox Purism’s coreboot article points out, that with the script, we can choose to flash coreboot:
- With or without the Intel ME neutralized
- With or without CPU microcode updates applied
- The default storage boot order, boot menu delay, presence of MemTest86+ as a boot option or not, etc.
None of these options present themselves when I flash coreboot.
How do I alter the script such that I can flash coreboot with the ME intact and CPU microcode updates applied?
1 Like
@taohansen that information is unfortunately not up to date, none of those options are available from the current build script. I’ve submitted corrections to that page which are being reviewed before being posted. I also plan on revamping the build script to coincide with the coreboot 4.9 update.
If you’d like to build with an intact ME, simply comment out or remove lines 783-787 from build_coreboot.sh (which call ME cleaner) before running it.
CPU Microcode updates are required to be loaded on all platforms using Intel’s FSP (firmware support package), the device simply won’t boot without it. So why we could offer the no-microcode option on the non-FSP/Broadwell-based 13v1/15v2, it’s not currently an option for newer devices which use FSP.
The bootorder is not currently modifiable by the build script, not sure why this was removed. There’s a separate bootorder adjustment script (which I updated) whose location escapes me at the moment. I do plan on re-integrating it with main build script, as well as offering the option to prioritize boot from external devices vs internal storage.
I have removed the lines in question and flashed successfully. Unfortunately, whatever the script did also knocked out detection of my wifi card, an Intel AC-9260. This card was detected and functioned normally before flashing the firmware.
Any suggestions for how I can restore detection of the card? ifconfig -a and lspci fail to show the interface or card.
@taohansen that would imply that the script didn’t patch the downloaded ME binary (to configure the PCIe lanes, among other things), but that wasn’t what got cut out. What device are you using, and do you what what firmware you had on there previously? If this is a result of a misconfigured ME, then re-flashing with a correctly configured one will be the resolution. But first need to figure out why/how this happened
I reflashed firmware with all defaults and still don’t have a wireless interface. Bluetooth, provided by the same chip, is detected and functions normally. rfkill shows only bluetooth.
It’s a Librem13v2. Previous firmware was 4.7-Purism-4.
I’m not able to replicate that here on my 13v2. just reflashed and swapped in an intel 8260, detected fine via lspci and works when booted with kernel w/wifi firmware blob. Can you provide the firmware boot log, maybe that will show something? From the directory with the update/build script:
cd coreboot/util/cbmem
make
sudo ./cbmem -1c > cbmem.log
then throw the log on pastebin (eg)
Thanks for testing the hardware with me. I’m stumped. I’m looking at all the system logs and nothing leads me to believe that my machine has any idea my wireless card exists.
EDIT: It looks like my firmware partition table is bad?
ME: FW Partition Table : BAD
that’s the expected output for a disabled/neutered ME on a Skylake/Kabylake device (another thing in the update to the coreboot page that’s pending). Looking at your boot log, your wireless card is not being detected – it should be attached to PCI device 0:1c.0 (PCIe root port 5) and be assigned to bus 1 (1:00.0) but there’s no sign of that. The root port is detected, enabled, and assigned resources, but no attached device is found.
I thought maybe it had something to do with your having NVMe, since that’s another PCIe device, but installing one in my 13v2 didn’t change anything (still works here). I suspect it may be an issue with the card or slot - have you tried reseating it? To rule out the firmware update completely, I can provide you a link to download and instructions to flash the previous version (4.8.1-Purism3) – just shoot me a PM
Okay, I have a question though.
If, for some reason, the Coreboot flashing doesn’t work, am I going to brick the machine? Is there a backup BIOS or keyboard shortcut to recover the Coreboot BIOS?
If I do brick it, will I need some kind of hardware SPI flasher to correct it? I am moderately concerned about that.
1 Like
Correct, a failed/bad flash would likely result in a brick. We’ve never had that happen, but if it did, recovery via a cheap SPI flash programmer (eg, a ch341a USB device + chip clip) would be necessary.
Oh, good to know! Yeah, the Librem13v4 has trouble booting up sometimes, and there’s also an issue where the backslash key emits an angle bracket character instead.
So I’m looking to see if a BIOS update can fix that, for example.
trouble booting up sometimes? the ME being disabled can cause a few second delay on cold boots sometimes, but that’s about it.
the pipe key ( | ) displaying > is an EC bug (that we’re unable to fix unfortunately); PureOS has a fix already (incoming for v4 devices if not already fixed) and several posts on the forums on how to mitigate on other OSes
When running the build_coreboot script, it stops at this point:
Downloading ME 11 Repository from https://mega.nz/#!2ElyFQDT!cC0gTlH8rB9EWD4MGX0mVElT94BauqFn-dBKuoEselc
Running the ./megadown manually with that url gives this result:
MEGA bad link
So I am guessing the files have been (re)moved.
Would you please take a look?
I have just downloaded using a browser.
I’m not sure why some people are having this issue, but I can’t reproduce it. The link is definitely not bad, and as noted above it can be downloaded in a browser without issue. It’s something I hope to eliminate in a future update though.
I had the same issue as well and traced my problem to an TLS/SSL issue with the download site. Once I relaxed the settings in firefox I was able to manually get the megadown file & re-run the script successfully.
Today I attempted to install coreboot on a Librem 13v1 that still had non-coreboot bios (AMI I think?) and it was a bit of an adventure. I first attempted a bit over a year ago and was not successful, I think because I could not find the appropriate versions of all required tools. I tried again now because the process seems more ironed-out and supported than before, and there’s this nice-looking page: https://puri.sm/coreboot/
Running the latest version of the script, I choose my model, and then I have to choose to extract from current coreboot or provide a coreboot build … obviously neither can work for me yet, but I choose option 1, and it continues for a while, building some necessary tools, before erroring out failing to extract some parts from the current firmware.
Then I find the script appropriate for Librem 13v1 somewhere in the middle of this huge topic - https://github.com/purism/purism-librem-coreboot-updater/blob/master/purism-librem-coreboot-updater.sh - this should probably be linked to from the main coreboot page. This must be a later version of what I tried to use before, when I had issues finding various tools, like cbfstool and ifdtool, I can’t easily find packages for those, and it doesn’t say where to get them. But this time, I can find these in the coreboot build tree from the first attempt. So I copy cbfstool, rmodtool, and ifdtool that were just built by the update-only script, to /usr/local/bin/, and I copy me_cleaner.py to /usr/local/bin/me_cleaner, and I found UEFIExtract at https://github.com/LongSoft/UEFITool/releases and manually installed it to /usr/local/bin/ too. Finally, I modified purism-librem-coreboot-update.sh to remove the explicit /usr/bin/ from the paths of all these tools, and it worked, and now I’m running coreboot. Great.
That theoretically installs an older version of coreboot, so I go back to the prominently linked update-only script, to try that again. It can now successfully extract the needed parts from the current firmware, good. But it attempts to check out a coreboot branch that does not exist? Note “error: branch ‘librem’ not found.” in:
Receiving objects: 100% (695/695), 140.31 KiB | 0 bytes/s, done.
Resolving deltas: 100% (549/549), completed with 204 local objects.
From https://source.puri.sm/coreboot/coreboot
* [new branch] heads -> purism/heads
* [new branch] l15v2-test -> purism/l15v2-test
* [new branch] librem13v2_sata_fix -> purism/librem13v2_sata_fix
* [new branch] librem_4.7 -> purism/librem_4.7
* [new branch] librem_4.8 -> purism/librem_4.8
* [new branch] librem_4.9 -> purism/librem_4.9
* [new branch] librem_pre_4.8 -> purism/librem_pre_4.8
* [new branch] master -> purism/master
* [new tag] 4.7-Purism-5 -> 4.7-Purism-5
* [new tag] 4.8.1-Purism-4 -> 4.8.1-Purism-4
* [new tag] 4.7-Purism-1 -> 4.7-Purism-1
* [new tag] 4.7-Purism-2 -> 4.7-Purism-2
* [new tag] 4.7-Purism-3 -> 4.7-Purism-3
* [new tag] 4.7-Purism-4 -> 4.7-Purism-4
* [new tag] 4.8.1-Purism-1 -> 4.8.1-Purism-1
* [new tag] 4.8.1-Purism-2 -> 4.8.1-Purism-2
* [new tag] 4.8.1-Purism-3 -> 4.8.1-Purism-3
Already on 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
error: branch 'librem' not found.
warning: unable to rmdir 3rdparty/fsp: Directory not empty
M 3rdparty/blobs
M 3rdparty/chromeec
M 3rdparty/libgfxinit
M 3rdparty/libhwbase
M 3rdparty/vboot
Switched to a new branch 'librem'
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to c8765826f4c2d10db0b660defccc84f7bce11af0.
Submodule path '3rdparty/arm-trusted-firmware': rebased into 'c8765826f4c2d10db0b660defccc84f7bce11af0'
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to 998982d714a08481bb4944f456929be06b5e696f.
Submodule path '3rdparty/blobs': rebased into '998982d714a08481bb4944f456929be06b5e696f'
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to 860fe2962d40ee901369d1dc67f4aa7a7a42ba4d.
Submodule path '3rdparty/chromeec': rebased into '860fe2962d40ee901369d1dc67f4aa7a7a42ba4d'
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to 67cf6d8f2bd36d8f78f48dfb927789d007b7740f.
Submodule path '3rdparty/libgfxinit': rebased into '67cf6d8f2bd36d8f78f48dfb927789d007b7740f'
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to 9de64c77f0567ac3fbcc4ce62a7090a6bae84360.
Submodule path 'util/nvidia/cbootimage': rebased into '9de64c77f0567ac3fbcc4ce62a7090a6bae84360'
Submodule path '3rdparty/arm-trusted-firmware': checked out '693e278e308441d716f7f5116c43aa150955da31'
Submodule path '3rdparty/blobs': checked out '78a02a7f9d979fcc864638cc40084e662476095f'
Submodule path '3rdparty/chromeec': checked out '927b64a0ba8f6362daf2e9a6c7eabf23815ae95a'
Submodule path '3rdparty/libgfxinit': checked out '7628493a7e7acaba93d607db008a59ec8fa8eebe'
Submodule path '3rdparty/libhwbase': checked out '66859712e4817288591908d737dbf41ddea31c3a'
Submodule path '3rdparty/vboot': checked out '392211f0358919d510179ad399d8f056180e652e'
Submodule path 'util/nvidia/cbootimage': checked out '64045f993c2cd8989838aeaad3d22107d96d5596'
Coreboot toolchain version changed from 0 to 1.50
So at the end of the build process, I get an unexpected hash:
Finished building coreboot for Librem 13 v1
WARNING: Built coreboot image hash does not match the expect reproducible build hash
Built: 68d0122944685d973fc830704b3419a547cd37913b1d428ca6ff18e0305a9337
Expected: 149f68641a282fd3369cf98133ddafeb7e415f664cd6260a30d479f20010620b
I suppose I shouldn’t install this because it was quite possibly not built from an appropriate branch? I’ll stick with what I have for now. Which is, according to dmidecode:
BIOS Information
Vendor: coreboot
Version: 4.5-1503-gfe41ae9
Release Date: 04/07/2017
ROM Size: 8192 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
BIOS is upgradeable
Selectable boot is supported
ACPI is supported
Targeted content distribution is supported
BIOS Revision: 4.0
Firmware Revision: 0.0
I hope all that wasn’t too much spam, and helps iron-out some details for us poor Librem 13v1 owners 
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.