Building coreboot from source (official script)


#21

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.


After installing second M2 SSD, PureOS is not booting automatically
#22

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?


#23

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).


#24

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 :slight_smile:

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.


#25

It worked this time, so I guess you were right. Will report any unusual behavior around hibernating if I see it.


#26

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?


#27

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)


#28

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.


#29

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'

#30

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


#31

Aha! of course, its a fresh install of debian, no Make.
i’m just installing the build-essential package that should fix it.


#32

The top of the script has a comment about all the dependencies you’ll need. It will probably fail if any of them are missing.


#33

How do I test Intel ME and AMT have been disabled?


#34

https://puri.sm/coreboot/


#35

@kakaroto I did what (I guess) you wrote at https://puri.sm/coreboot/ in section Checking whether or not the Intel ME is neutralized in your image but the first seven lines don’t match… Here’s my output:

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: D3 Support              : NO
ME: D0i3 Support            : YES
ME: Low Power State Enabled : NO
ME: Power Gated             : NO
ME: CPU Replaced            : NO
ME: CPU Replacement Valid   : YES
ME: Current Working State   : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode  : Normal
ME: Error Code              : <NULL>
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : 0x65
ME: Power Down Mitigation   : NO
ME: FPF status               : unfused
ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: D3 Support              : NO
ME: D0i3 Support            : YES
ME: Low Power State Enabled : NO
ME: Power Gated             : NO
ME: CPU Replaced            : NO
ME: CPU Replacement Valid   : YES
ME: Current Working State   : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode  : Normal
ME: Error Code              : <NULL>
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : 0x65
ME: Power Down Mitigation   : NO
ME: FPF status               : unfused

I used your script to install coreboot with neutralized ME (see above) and I thought it worked… Since I just did what I read and don’t understand the output at all – could you tell me what it means?


#36

Hello Mladen,

I flashed my Libre13v2 but my ME test has different results than expected.

REDACTED@mojo:~/coreboot/util/cbmem$ sudo ./cbmem -c | grep ^ME

ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code :
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
REDACTED@mojo:~/coreboot/util/cbmem$ cat /proc/cpuinfo | grep microcode | wc
4 12 68


#37

Yeah… that information is for the Librem 13 v1. It’s much harder to verify if the ME is disabled on the skylake system and that was the last thing I was working on. The way I do it is to just dump the flash and used a hex editor to check if the ME in it is neutralized or not (zeroed out modules and removed partitions), but obviously that’s not practical for anyone.

Unfortunately, I think coreboot is booting so fast on the skylake systems that it finishes booting and probing the ME before the ME encounters its first “module missing” error and crashes.
There’s the intelmetool in coreboot which could be used to talk to the ME and see if it responds to requests or not, but it hasn’t been ported to skylake yet I think. I suppose that for now, you just need to trust that if you flashed it and enabled me neutralization, that it is indeed neutralized.


#38

Tried the current script today in the vain hope this might fix issues with the new Qubes4.0rc2 not recognizing IOMMU/VT-D as enabled. Unexpectedly though it produced some fatals & warnings and finally broke when it found the hash of the downloaded ME repo to be wrong.

Script was run from a fresh PureOS with additional necessary packages installed on a Librem13v2. I logged the whole output: http://dumptext.com/10v1R18M

Hereby pinging @kakaroto about this. Any ideas what might have gone wrong?


#39

@avog: well that’s interesting, thanks for the log. I tested and I got the same issue. It looks like the mediafire link had its file updated. The ME repository pack went from r48 to r49. I always thought the medialink files were static, so I thought the r49 (when they’d upload it) would be a new link, but it looks like that’s not how it works. Anyways, I’ve updated the script to handle the new filename and hash, so just the script and rerun it, it should work now.
Note however, that the IOMMU stuff still isn’t enabled. That will still require some time to get implemented.


#40

Thanks @kakaroto, it’s working again. And like many others I’m very much looking forward to “the IOMMU stuff” being enabled. :slight_smile: My Librem has been sitting here waiting to run a fully functional Qubes installation ever since I got it.