worked like a charm for me, thanks for your work! coreinfo works fine, now the only thing left seems to be memtest86+ being outdated and better replaced with memtest86.
Thanks so much! The information you provided was very helpful.
1 Like
yep, I wrote it in the original post :
although, I probably should have said “different distro” instead of “different OS”.
cool. And yeah, memtest seems outdated, it doesn’t recognize DDR4, it thinks it’s DDR3, and it inevitably crashes in SMP mode or whatever that mode is when you press F1. Memtest86+ is however version 5.01, which is the latest release, but dates back from 2013. The memtest86 program seems to not be free, and while they have a ‘free edition’, i don’t see a link to download its source code. I found a ‘src.tgz’ file inside the iso download but I can’t get it to compile… anyways, we’ll see.
The coreinfo issue was a problem in the configuration, the problem with memtest, is that it’s outdated in the coreboot bundle.
@all: it’s good to know that it worked for everyone who tried it so far, but you all missed one feedback… at the end, it just says “Enter your choice (y/N)”, but doesn’t say what the choice is for… the message should have been “Do you want to flash coreboot now (y/N) ?”. It’s minor of course, but any feedback is important. Thanks! 
3 Likes
Hi. What should I do if the hash doesn’t match?
1 Like
I get the following when running the script:
HOSTCC cbfstool/cbfstool.o
Makefile.inc:109: recipe for target '/home/arlo/Desktop/coreboot/util/cbfstool/cbfstool.o' failed
Renamed ./coreboot/ to ./coreboot-backup and tried again. This time:
I am a little curious, I am the proud owner of a librem 15v3, running PureOS release 8,
>lsb_release -a
No LSB modules are available.
Distributor ID: PureOS
Description: PureOS GNU/Linux 8
Release: 8
Codename: green
with kernel
uname -r
4.12.0-1-amd64
yet @kakaroto mentions the coreboot build allows one to udpate ones machine to the latest version,
yet his post is only 10 days old. Is @kakaroto talking about PureOS 5 kernel 4.6) as the latest version? am I missing something?
Or is this the version of coreboot itself?
2 Likes
In my case the script stopped while grabbing the required binary blobs from my local machine (Librem 13 v2) with this error message:
Found file cpu_microcode_blob.bin at 0x3d1440, type microcode, size 96256
The CPU microcode update on your machine is an outdated version
Please download the latest microcode update from : https://downloadcenter.intel.com/download/26925/Linux-Processor-Microcode-Data-File?product=122139
Then place the intel-ucode/06-4e-03 file from the archive into coreboot/3rdparty/blobs/mainboard/purism/librem13v2/cpu_microcode_blob.bin
I did that, the script continued, but then I got this:
WARNING: Built coreboot image hash does not match the expect reproducible build hash
Maybe I should add that I have version 4.6-00b9f4-Purism-1 while the changelog lists only 4.6-a86d1b-Purism-X versions 
As I understand it, 4.6-00b9f4 means coreboot version 4.6 until and including commit 00b9f4. If this is correct and 4.6-a86d1b-Purism-1 was the Initial Librem 13 v2 coreboot port as mentioned in the changelog I seem to have a beta version of that initial coreboot port… 
1 Like
Humm… if you can compress (gzip/bzip2/rar/zip/7z) the file and upload it somewhere then send me the link in a private message, I can look at the differences and figure out why the hash is different for you, then hopefully figure out how to fix the script.
I have no idea why you’re having that compilation error. was there no other error messages ? Just that one line ? For your second test, it looks like you simply lost internet connection while it was downloading the coreboot repository, I suggest you just delete the coreboot directory and retry the script again.
Yes, that’s the coreboot version. You can see it with the command ‘dmidecode -t 0’
yeah… for some reason, you do seem to have a machine running an older coreboot version. I have no idea why,I didn’t realize any of the machines were flashed with that version. Either way, it’s good that you can update it now.
The fact that that’s what you have locally shouldn’t in any way affect the resulting build, so once you send me your build and I figure out why it’s hash is different from what it should be, then you should be able to update your machine.
Thanks everyone for testing.
1 Like
Thanks to @stefann, I’ve fixed the issue that was causing the hash to not match [1].
You should re-download the script now and re-run it, and it should work this time. If you still have issues, let me know!
[1] the problem was SeaBIOS itself, the coreboot config stated to build the latest git master of SeaBIOS but of course, there were new commits in git in the past few days, which made the hash different. I’ve now changed the config to tell it to build a specific version of SeaBIOS and that should fix it.
EDIT: I’ve just added a new option to let you neutralize the ME. I’d appreciate it if some of you could test it and see if there are any side effects that you can notice. The biggest one I want to test for is whether you have any reboot or power off issues when you run the neutralized ME.
If you have issues, and want to restore the ME to a normal state, then flash the coreboot-l13v2.rom or coreboot-l15v3.rom image.
1 Like
Reporting a typo: mircocode instead of microcode. Does the script detect if the installed version of coreboot is the same as the target version and exit if so?
Thanks! Fixed the typo.
And no, the script doesn’t detect your installed version because it’s not an updater script, it’s a build script. So it’s meant for you to build coreboot from source, regardless of the version you have (which might be useful in case you think someone installed a modified&malicious version of coreboot, but which appears as the same version as the one you have). The updater script, once itself has been updated to support skylake machines will check for new versions instead (and I think I’ll also make it check hash of current firmware in case it’s the latest one).
1 Like
I used the script from yesterday (the one without the option to neutralize the ME) and it worked – I have coreboot version 4.6-a86d1b-Purism-5 now
I’m not sure this is new (I didn’t check the kernel messages for a long time) and I don’t know if it is related but I get this warning now:
[ 23.316870] Not enough lanes (0) for DP on port E
[ 23.316887] ------------[ cut here ]------------
[ 23.316941] WARNING: CPU: 0 PID: 359 at /build/linux-fHlJSJ/linux-4.12.6/drivers/gpu/drm/i915/intel_dp.c:5924 intel_dp_init_connector+0x8f9/0x1120 [i915]
[ 23.316947] Modules linked in: snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core intel_rapl snd_compress x86_pkg_temp_thermal intel_powerclamp coretemp arc4 i915(+) kvm_intel snd_hda_intel kvm ath9k ath9k_common irqbypass ath9k_hw ath3k intel_cstate btusb snd_hda_codec btrtl ath btbcm btintel mac80211 intel_uncore video intel_rapl_perf bluetooth iTCO_wdt snd_hda_core snd_hwdep cfg80211 snd_pcm drm_kms_helper snd_timer snd ecdh_generic processor_thermal_device drm int340x_thermal_zone rfkill serio_raw pcspkr soundcore evdev iTCO_vendor_support joydev shpchp sg i2c_algo_bit intel_soc_dts_iosf intel_pch_thermal topstar_laptop battery ac sparse_keymap button parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic
[ 23.316994] fscrypto ecb mbcache algif_skcipher af_alg hid_logitech_hidpp hid_logitech_dj usbhid hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd psmouse ahci libahci xhci_pci i2c_i801 libata xhci_hcd usbcore scsi_mod usb_common
[ 23.317014] CPU: 0 PID: 359 Comm: systemd-udevd Not tainted 4.12.0-1-amd64 #1 Debian 4.12.6-1
[ 23.317018] Hardware name: Purism Librem 13 v2/Librem 13 v2, BIOS 4.6-a86d1b-Purism-5 07/27/2017
[ 23.317021] task: ffff9ae0f45e8080 task.stack: ffffbcdfc0c38000
[ 23.317050] RIP: 0010:intel_dp_init_connector+0x8f9/0x1120 [i915]
[ 23.317052] RSP: 0018:ffffbcdfc0c3b9c8 EFLAGS: 00010282
[ 23.317055] RAX: 0000000000000025 RBX: ffff9ae0f8e38000 RCX: 0000000000000000
[ 23.317057] RDX: 0000000000000000 RSI: ffff9ae0fec0dee8 RDI: ffff9ae0fec0dee8
[ 23.317059] RBP: ffff9ae0f8e38000 R08: 0000000000000000 R09: 000000000000023e
[ 23.317062] R10: 000000000000000b R11: ffffffffa60cddcd R12: ffff9ae0f8e46800
[ 23.317064] R13: 0000000000000004 R14: 0000000000000000 R15: ffff9ae0f72fa000
[ 23.317066] FS: 00007f64c6b3f8c0(0000) GS:ffff9ae0fec00000(0000) knlGS:0000000000000000
[ 23.317070] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 23.317072] CR2: 000055b6e983a068 CR3: 0000000173ee7000 CR4: 00000000003406f0
[ 23.317074] Call Trace:
[ 23.317101] ? intel_ddi_init+0x390/0x450 [i915]
[ 23.317128] ? intel_modeset_init+0xd9c/0x1890 [i915]
[ 23.317152] ? intel_i2c_reset+0x3e/0x40 [i915]
[ 23.317174] ? intel_setup_gmbus+0x2c5/0x2e0 [i915]
[ 23.317197] ? i915_driver_load+0xb07/0x1370 [i915]
[ 23.317200] ? mutex_lock+0xe/0x30
[ 23.317204] ? acpi_dev_found+0x5f/0x70
[ 23.317207] ? local_pci_probe+0x3f/0x90
[ 23.317210] ? pci_device_probe+0x150/0x170
[ 23.317213] ? driver_probe_device+0x293/0x440
[ 23.317216] ? __driver_attach+0xda/0xe0
[ 23.317219] ? driver_probe_device+0x440/0x440
[ 23.317222] ? driver_probe_device+0x440/0x440
[ 23.317225] ? bus_for_each_dev+0x67/0xb0
[ 23.317228] ? bus_add_driver+0x16a/0x260
[ 23.317230] ? driver_register+0x57/0xc0
[ 23.317233] ? 0xffffffffc0c26000
[ 23.317235] ? do_one_initcall+0x4e/0x190
[ 23.317238] ? __vunmap+0x71/0xb0
[ 23.317240] ? __vunmap+0x71/0xb0
[ 23.317243] ? do_init_module+0x5b/0x1fe
[ 23.317247] ? load_module+0x2635/0x2b90
[ 23.317251] ? SYSC_finit_module+0xc6/0xf0
[ 23.317253] ? SYSC_finit_module+0xc6/0xf0
[ 23.317256] ? do_syscall_64+0x7c/0xf0
[ 23.317259] ? entry_SYSCALL64_slow_path+0x25/0x25
[ 23.317262] Code: 00 00 00 e9 6d fa ff ff 49 c7 86 00 0b 00 00 b0 d2 b8 c0 e9 be f7 ff ff 89 c2 31 f6 48 c7 c7 78 69 be c0 83 c2 41 e8 8d e0 7e e4 <0f> ff 31 c0 e9 c0 f9 ff ff ba 01 00 00 00 be 68 4d 01 00 48 89
[ 23.317285] ---[ end trace 22d3ab54fb15cf20 ]---
I get the same warning message when I use the up to date script and run the neutralized ME. I’ll test this image some more and tell you if there are any side effects.
1 Like
It worked this time, so I guess you were right. Will report any unusual behavior around hibernating if I see it.
Here’s a dumb question… if my Librem doesn’t have any OS yet, can/should I run the script from a live USB?
Alternatively, can I run it on a second machine and if so what details from my Librem do I need?
1 Like
Humm… I remember seeing that as well, but can’t remember if it disappeared on its own, if I did something to fix it or if I just stopped noticing it. Either way, I think it’s not an issue because it’s just complaining about the display port not having enough lanes (being disabled?), and the crash is clearly a bug in the kernel driver itself… humm… possibly it stopped happening when the kernel/OS got upgraded?
oh, just tested on the L13 and L15, and it’s still there, yeah… so I just stopped noticing it. I’ve created a task for it so it doesn’t get forgotten again. Thanks for reporting it.
Not a dumb question at all. Yes, you can run it from a live USB and it should work. If it doesn’t, then alternatively, you can run it on a separate machine, but you will need two things :
- Dump the flash from the librem manually
- Flash the new coreboot image manually
If you run the script on the live USB, it will compile flashrom then dump your flash. You could then interrupt the process and copy the coreboot-orig.rom file over to your second machine, then run the script, when it asks about where to get the blobs, choose option 2 (grab them from the pre-dumped file). Then once the build is finished, copy the coreboot-l1[35]v[23].rom file it generated and flash it on the librem using this command :
coreboot/flashrom/flashrom -p internal:laptop=force_I_want_a_brick -w coreboot-l13v2.rom
(this is assuming it was built for l13v2, and you run it from the same dir you ran the script earlier, since flashrom will be built under coreboot/flashrom sub-directory)
2 Likes
I just wanted to tell you that after testing coreboot with the neutralized ME for one week now (8–10 hours a day) I didn’t have any issues at all. Everything works as expected.
1 Like
When I run the script on a fresh install of Debian Stretch I get the following error:
# ./build_coreboot.sh
Cloning into 'coreboot'...
remote: Counting objects: 16570, done
remote: Finding sources: 100% (296/296)
remote: Total 371074 (delta 42), reused 370902 (delta 42)
Receiving objects: 100% (371074/371074), 88.33 MiB | 449.00 KiB/s, done.
Resolving deltas: 100% (285045/285045), done.
./build_coreboot.sh: line 116: make: command not found
git: 'sup' is not a git command. See 'git --help'.
Did you mean this?
push
#
I’m guessing you have an alias for the git sup command? Is it this? -
git config --global alias.sup 'submodule update --init --recursive'The alias gets installed with the “make gitconfig” command. Your problem is this :
make: command not found
I am however surprised that the error in the make didn’t cause the script to abort. I’ll check tomorrow if I forgot to set the -e option in the script
2 Likes