so here’s a comparison between my 15v2 (left) and your 2nd cbmem log (right):
https://www.diffchecker.com/26Ytt2sQ
the only differences are the previous power state, amount of RAM, bootorder, and some timestamps. So there’s nothing on the coreboot side which would indicate any problem.
can you provide the output of ‘sudo lspci -nn’ please? the wifi module should be present at 2:00.0
Ok, now it all makes sense… When you wrote that it looked like the ME image was missing some things, I remembered that just after flashing, I tried to checked if the ME had been cleaned. And by mistake (typing too fast and with [tab]), I ran me_cleaner on the freshly flashed system. So it must have removed some stuff from the already cleaned ME, making these bugs… (lspci did not have anything for the wifi module)
Now I’ve deleted my cached version of your firmware (basically deleting everything in the firmware/ directory of your script), and I have re-run your script. Tadaa! it works, the wifi is found and works! I’ll try putting back the i915.enable_psr kernel parameter and let you know…
[A few minutes later] I can confirm, “shutdown” works properly, and all my i915 kernel parameters work fine: i915.enable_psr=1 i915.enable_dc=2 i915.enable_fbc=1. And the boot is much faster. I was the bug here… So thanks again a lot for your help!
So, sorry it was my mistake (well, if me_cleaner could detect that it has already run, this would also be safer). But thanks for your hint, that was the key!
no worries, I’m glad we got it figured out pretty quickly. I’ll add a note/warning to the script that the images already have ME Cleaner applied, and that doing so a 2nd time could cause issues.
Ok, a little less upbeat than in my previous post… With Coreboot, the kernel command line options “i915.enable_psr=1” and “i915.enable_fbc=1” work but “i915.enable_dc=2” (enable deeper energy saving states) as well as “ath9k.ps_enable=1” (power saving mode for the wifi card) make the system crash at boot while they used to work when still using the AMI bios (with the same kernel version).
I’m not familiar with any of those command-line params, but given they aren’t defaults, that suggests the features aren’t stable enough to be enabled by default. I also know that the AMI firmware incorrectly advertises some features it doesn’t support, and disables some it should enable. I’d have to do some research on the appropriateness of the i915 ones for a Broadwell GT2 GPU, and then see if they should be supported, why they are causing a crash.
have you tried enabling the parameters one at a time to see which is responsible for the crashing?
#########################################
## Purism Librem firmware updater 1.0 ##
#########################################
Which Librem device do you have?
# Broadwell/5th-Gen
1 - Librem 13 v1
2 - Librem 15 v2
# Skylake/6th-Gen
3 - Librem 13 v2
4 - Librem 13 v3
5 - Librem 15 v3
# Kabylake/7th-Gen
6 - Librem 13 v4
7 - Librem 15 v4
My spidey sense tells me it's a Librem 13 v2
running firmware coreboot 4.6-a86d1b-Purism-5
Enter your choice (1-7): 5
Which firmware type would you like to flash?
1 - Standard (v4.8.1-Purism-4)
2 - PureBoot (v4.8.1-Purism-4-HEADS-beta-2)
Enter your choice: 1
Checking for usable version of flashrom
$ echo $?
1
I ran sudo apt install flashrom and then ran the script again. The script then said
Checking for usable version of flashrom
Cloning flashrom git repo...done
Building flashrom from source...done
ok… 
About to flash now. If I’m not back in 5 minutes… just wait longer.
Do you want to flash the coreboot update now (y/N) ? y
coreboot flashing in progress. Do NOT interrupt this process.
Initializing internal Flash Programmer
ERROR!!! Error flashing coreboot!
doh.
Guess I have to do the iomem=relaxed thing. Can I do that by pressing escape at boot and fiddling around?
pastebin the time/date-stamped flashrom log
(I’ll add that note to the script)
Hmm, in grub I pressed c and then added iomem=relaxed to one of the lines…
Now I have this error in my flashrom log:
Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific).
coreboot last image size (not ROM size) is 16777216 bytes.
Manufacturer: Purism
Mainboard ID: Librem 15 v3
This coreboot image (Purism:Librem 15 v3) does not appear to
be correct for the detected mainboard (Purism:Librem 13 v2).
Aborting. You can override this with -p internal:boardmismatch=force.
Restoring PCI config space for 00:1f:5 reg 0xdc
But my laptop really is a Librem 15 v3. It’s printed on the bottom. Did someone put wrong bios on my laptop at the factory?
let’s figure that out. can you pastebin the output from (sudo) dmidecode? May also need you to download or build the coreboot cbmem utility to pull the firmware boot log
edit: cbmem download: https://mrchromebox.tech/files/util/cbmem.tar.gz
extract, then run: sudo ./cbmem -1c > cbmem.log
and pastebin the full output
dmidecode: https://0bin.net/paste/s495FMgvlDIBY2R-#Gwdx1zCKAX6AdM8+CzEGVB18wW2v-dBGEMIsad0Z4sJ
cbmem: https://0bin.net/paste/NL0Y2EqjuvB3MkRG#nLX-3rl30zIWyPjW5pBSdqz5x93gl0jv0/4sbCp3gzy
flashrom log: https://0bin.net/paste/syd3CCd7ZSw5lx1I#UBaxkSwCp4mNqFQwTVWiNHyF7DIhOMlbGKSNon0My0S
sorry, I can’t post anymore today it seems, getting an alert I’ve reached the max for a new user 
edit: added cbmem and flashrom logs
edit 2:
OK, let’s try ghostbin
https://ghostbin.com/paste/2f7y9
edit 3:
I have no idea why the above ghostbin disappeared. Let’s try again
https://ghostbin.com/paste/ef3h9
edit 4:
It does have the numpad on the right. I’ll try adding -p internal:boardmismatch=force.
still no dice. email me mrchromebox at gmail?
Assuming you do have a 15" model (has numberpad to right of keyboard), then it definitely has the wrong firmware on it, and we can work around this by simply editing the script to add the required flashrom parameter to ignore the device name mismatch
Well, I have some bad news… after playing for hours with different kernel parameters, finally removing every single parameter (beside “iomem=relaxed quiet splash”), it is still quite unstable. Once the system has booted properly, it works great. But I often have to try 5-10 times booting until everything works (either it is “booting from hard drive” and it stays stuck there, or X crashes or there is no wifi, or no touchpad). I have also never been able to enter the “corebootinfo” payload. And half of the time, shutting down does not power off the laptop but it remains stuck in a state that drains the battery quite fast (I’ve left it once for maybe 15-30 minutes to see if it would eventually power off, it did not but after starting again, the battery had discharged quite a lot). As I understand (after reading about Coreboot and SeaBios), this could be a problem of SeaBios not presenting all the devices, right?
this is quite surprising, and not something I can replicate on my 15v2 here.
Does your system have both m.2 and SATA SSDs?
When you bring up the SeaBIOS boot menu, are all installed drives listed?
There’s no reason for X to crash. What distro/kernel are you running?
coreinfo not working again seems odd, works fine here
I currently have an m.2 ssd and a SATA hard drive. I have also one difference compared to “stock” Librem: my ram modules were draining too much power in suspend mode, emptying the battery very fast. So around a year and a half after, I’ve requested a replacement to the ram modules maker. Even if the new ones have the same specs than the original ones, could it be that they have small differences? I have the feeling that if I let the memory test running for a few minutes before starting the os, then it starts without problems… I’ll do more tests, I will try to run memtest and then coreinfo…
Otherwise, I am using Debian Buster with stock 4.19.0-4 kernel (and everything was running fine with the AMI bios).
[Edit] I’ve tried running memtest (up to the patterns testing) and then Coreinfo… and it works! It seems more and more that it has to do with the RAM handling.
you’ve run a full memtest and everything passes?
I have seen some instances where on the 13v1 that USB devices can fail to be detected on a cold boot, but are after hitting CTRL+ALT+DEL (so a warm reboot), but I’ve not seen that issue with internal drives. I can try loading both in my 15v2 and see if I can reproduce.
coreinfo running only after running another payload and rebooting is just bizarre, I’m at a loss there.
To be safe, can you update coreboot again using the new update utility (https://source.puri.sm/coreboot/utility) - there’s chance that the build you’re running is missing or has a bad microcode file, and want to rule that out.
I’m totally lost… I’ve reflashed coreboot with your new update utility, no problems, except that the boot order that I’ve provided to the script is not use when booting (I’ve reflashed several times, requesting ssd, then hdd and I always get hdd if I don’t manually select the ssd).
But I still have the same difficulties in booting. I’ve been able to enter Coreinfo several times, but now memtest fails (ie the computer locks up) at test #2, 21%. I’ve tried removing one of the ram module, it the hangs in the same test at 42% (no matter which memory module I remove, same results). So it seems to hang at one specific memory location. If I run the parallel version of the test, it hangs at test 31, 5% (with two memory modules, ie 16G). I have also removed my sata hard drive, it makes no changes.
If I don’t play around with memtest, I can boot after several tries… I still also experience some failed shutdowns (ie the OS is gone but the cpu still runs full blast until long-pressing the power button). I have really no clue what is going on… Could the boot logs (from Coreboot) provide some hints?
it will definitely help me fix the bootorder issue, for the rest maybe? Pull it per my instructions earlier in this thread (Building coreboot from source (official script))
will be closing this topic, as this coreboot build script is now deprecated. Please move all discussion to the topic for the new Librem coreboot Utility/Updater Script.
thanks!