I’m having issues when running this script on my Librem 13 V2 with TPM.
Which coreboot image do you want to build:
1 - Librem 13 v1 (Version : 4.7-Purism-2)
2 - Librem 15 v2 (port not finished)
3 - Librem 13 v2 (Version : 4.7-Purism-3)
4 - Librem 15 v3 (Version : 4.7-Purism-3)
Enter your choice (default: 1): 3
How do you want to extract binary blob files:
1 - Extract from the current machine (must be same as target machine and run coreboot)
2 - Extract from a pre-built coreboot image (filename must be coreboot-orig.rom)
3 - Files are copied manually (copy to coreboot/3rdparty/blobs/mainboard/purism/librem_skl/)
The following files are needed :
descriptor.bin - The Intel Descriptor - SHA256: d5110807c9d67cea6d546ac62125d87042a868177241be4ae17a2dbedef10017
me.bin - The Intel Management Engine image - SHA256: 3042150c7f655293a69bcf886836732fc451439ae551a2babf3173f4f0d9a8d3
vbt.bin - The Video BIOS Table - SHA256: 51fa214ca44a61b171662d4c2ca6adc1aa3dc6c3d7a24bf9ae5f249f012d61c0
fspm.bin - The Intel Firmware Support Package - SHA256: 7a1acc72073969e6753bbfe145f06c3f4d35e2516cb241641eae968705e2cc46
fsps.bin - The Intel Firmware Support Package - SHA256: 0dac94d249473e9d366597fd1f96a0232fb7bf045a3d08f16784961273351822
vgabios.bin - The VGA BIOS - SHA256: 18d861485b86f93dad2b294cebd40b99eb03493d32b514e731ddb8dcf3a1ce83
cpu_microcode_blob.bin - The CPU Microcode Update - SHA256: 9c84936df700d74612a99e6ab581640ecf423d25a0b74a1ea23a6d9872349213
The vbt.bin, fspm.bin and fsps.bin can automatically be downloaded, the me.bin can also be
downloaded, configured and patched so it will match the expected SHA256.
Enter your choice (default: 1): 2
Already up to date.
Using ‘sudo dmidecode’ to grab the local machine’s serial number
Could not open file: No such file or directory
Which is odd as sudo dmidecode --version shows it is installed and working. Any ideas?
$ sudo dmidecode --version
3.1
$ uname -a
Linux librem 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux
The error “Could not open file: No such file or directory” is from a section of the script that is run after getting the machine’s serial number. See the snippet below:
./util/ifdtool/ifdtool -x …/coreboot-orig.rom
If dmiedcode was not installed, the error would be like so:
sudo: dmidecode: command not found
It looks like you chose 2 for this prompt:
How do you want to extract binary blob files:
1 - Extract from the current machine (must be same as target machine and run coreboot)
2 - Extract from a pre-built coreboot image (filename must be coreboot-orig.rom)
3 - Files are copied manually (copy to coreboot/3rdparty/blobs/mainboard/purism/librem_skl/)
[…]
Enter your choice (default: 1): 2
Instead since you do not have coreboot-orig.rom, you should choose 1, assuming your Librem 13v2 does run coreboot.
No, option 2 is not. Coreboot is essentially a framework for the BIOS and needs a payload, which in this case is SeaBIOS. If you have SeaBIOS, you have Coreboot. Option one is correct.
Checking back in to see if there is a solution to the power off overheating issue yet. Again today, I had 3 power offs, on battery, turbo disabled, simply streaming amazon video while typing a document.
I’m getting concerned about file corruption with how many hard power offs I keep having. The not on boot says CPU package temperature has exceeded limits.
If it is not fixable, how can I go back to before this coreboot update? I didnt have any problems and only upgraded it to unlock my TPM and since Purism recommended it on their webpage.
EDIT: and while I’m here, here’s an update: still working on figuring out the temperature increase issue, some progress made, but no definite solution yet.
I updated the version that came out 2 weeks ago, 4.7-Purism-3. Is there another update from that as that is the version that I keep having the power / temp problems with. Thank you.
EDIT: I may have wrote that confusingly. What I meant to say was that two weeks ago, when that update was released, I performed the update to 4.7-Purism-3. I have had over a dozen heat related shutdowns since then with and without turbo enabled.
I’m surprised! Did you check with ‘dmidecode’ and made sure you are indeed on 4.7-Purism-3 ? Maybe it only built it but didn’t actually flash it and you thought it did ? I’m surprised to see that you have this issue still, considering you’re the only one with the problem (as far as I know). Can you ssh into your machine from somewhere else and have “watch -n 1 sensors” running (apt-get install lm-sensors) to see the temperatures it reached when the shutdown happens ?
My only guess right now is that you don’t have the fixed version.
weird then! But if you managed to build it on the machine without having it shutdown, that’s already pretty good…
Yeah, it should save the last temps to file but that’s assuming the ‘tee’ will write/flush to disc and that the write to disc doesn’t corrupt the file if it happens during the shutdown. I’d personally avoid writing to disc if you know the machine is about to shutdown.
I don’t have any hard data for you, but anecdotally even with 4.7-Purism-3 my 15v3 battery doesn’t last as long, I have to be careful about random power-offs, and I can’t rely on it to sleep for very long without depleting the battery.
If there are particular logs that’d be helpful lmk, will try to provide.
Thanks for all the hard work, this is a great project to be a part of!
@daehawc is not the only one with this problem. I mentioned this earlier in the thread but perhaps did not make it clear that I am also running 4.7-Purisim-3, confirmed with dmidecode, and have experienced several hard shutdowns since the update, usually when on battery.
@hazybluedot: Your only other comment in this thread was from before the Purism-3 update was released.
Ok, so that’s problematic, do you have any way to reproduce this crash? I’ve been testing with the command ‘stress -c 4’ so far, but is there something in particular that could increase the temperature higher than what the stress test would do ? Could it be related to when the CPU and the GPU are stressed together ?
Woops, looks like I was thinking of a different thread. The crash has not be 100% reproducible but I also haven’t spent a ton of time looking into it. I do not think it is limited to times both the CPU and GPU are stressed together though because it has happened when I’m doing non-GPU intensive tasks, for example running two instances of a deduplication backup utility at the same time while doing some analysis in Rstudio (though it is possible R is offloading computation to the GPU?). It also seems to only occur when running on battery power with Intel turbo boost enabled though I have not done a systematic turbo boost on/off comparison yet.
I’ve only had a few moments to do any testing so far but I i have noticed about a 15-20 degree drop since re-running the 4.7-Purisim-3 build. Like I mentioned, I installed the -3 build right after it was released but it did seem to take significantly longer to build this time around. Not sure if something got skipped last time or not. dmidecode did show -3. My resting temps are currently sitting in the 37 range and when launching vlc for an mp4 video I now only spike to about 65 instead of 80-90 plus or immediate poweroff. I almost exclusively had the poweroff when streaming Amazon Video or loading VLC for a movie. Maybe tied with the GPU and CPU.
So far, I’m hesitant to say but I think deleting my build folder and rebuilding again seems to have improved things. I’ll let you know if I have any more issues.
So… good news! I figured it out yesterday and we’ve tested it on a few machines and it seems that the bug is fixed. It was indeed a problem with the FSP 2.0 which had a new ‘Loadline’ setting that wasn’t there in FSP 1.1, and since it wasn’t getting set, it was setting the load line to the default of 0 Ohm which is wrong. I don’t really understand much of it to be honest but I think this and that explains it in more detail.
Either way, the important thing is that if you update the build script and update your coreboot to 4.7-Purism-4, it should work much much better now, the temperature rises smoothly, it stabilizes around 80C to 85C instead of the previous 95C, the frequency remains at 2.9GHz or 3GHz (it used to drop from 3GHz to 400MHz as soon as the high temperature was reached, then jump up and down), and the fan doesn’t go full speed until needed, etc… Hopefully, this should also fix battery issues as I suspect the unregulated AC and DC load lines to the CPU were causing the battery to drain faster than normal.
@daehawc, @mpc, @hazybluedot, @all, Please update and let me know if you still notice any issues.
@daehawc, @Dwaff: the hashes are verified and the flash is also verified after flashing and the version numbers are unique, so flashing or building more than once will not make any difference. If you deleted the coreboot directory though, then the build will take an hour or so because it will rebuild the cross compiler (gcc and its dependencies) which takes time, and that only happens on the first build. The build script itself will do a ‘make clean’ though so running the script will always ensure it’s a clean build either way. If you deleted the coreboot directory though that explains why the build took much longer to finish, it was because the cross compiler got re-built. And that would still have had no effect since, like I said, the final binary’s hash is verified by the build script, so the coreboot images are always identical.
Initial testing here is very promising: temperatures seem to have significantly stabilized upon initial testing (both inside and outside of the Turbo-range). The threshold for which fans will start to spin now has to be exceeded for a longer period of time (a single peak crossing the 50C mark will no longer set off the fans; the temperature should be above 50C for several seconds now, according to the temperature graphs).
Note: testing is done on Arch Linux right now, still utilizing power management tools (such as Thermald).
Assuming this paper is still relevant, I’m guessing that some of the stabilisation is due to (voltage) overshoot stabilisation, or is this not the case?
TLDR: temperature is proportional to voltage^2, so the applying kakaroto’s loadline information, the code might either 1) stabilize voltage (overshoot) by resistive loading (akin to the input impedance of amplifiers) 2) apply (additionally) more complex mechanisms to regulate voltage.
On a seemingly related note, when the laptop is charging (and in use), the top-right corner does not seem to emit as much noise as it did after the last update. I’ll keep testing this for a while to see if this holds up, but for now I’ll regard it as a promising step in (for lack of a better word) power management.
Unfortunately with 4.7-Purism-4 I think I had a temp-induced unscheduled shutdown shortly after starting a demanding video task. I’ve set no_turbo to 1 for now.