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.
@kakaroto it’s entirely possible it’s something else, but based on my priors here I’m leaning toward it being 4.7-Purism-4. In the interim I’ve noticed I wake up and the machine has powered off and the battery is dead (presumably either not sleeping properly or using too much power in sleep)
Are there particular logs I can capture that would help you?
Hey! I’ve got a few questions regarding the coreboot port:
I’ve been replacing the bootsplash in the coreboot port with my own for a while now, and I never had problems using it. I am aware, that it produces a false hash with a different bootsplash, than the one provided by you, but I just changed one entry in your script from ‘==’ to ‘!=’ and it flashed just fine.
Now my question is, how big is the security risk when I do this? And can I somehow generate a ‘correct’ checksum for my version, that compensates for the different bootsplash picture?
Also since the newest version of your script I am not able to flash my bootsplash anymore, the image flashes correctly, but on bootup I just get a “text version” of a bootsplash and no actual bootsplash. Any guesses on why it doesn’t work on the new version? I’d be happy to have my bootsplash back xD
Is there a possibility to set a BIOS password for coreboot? And how would I do it?
Are there any settings I can change in coreboot or is all fixed? Haven’t seen any settings yet``
You ahave effectively turned off any image verification. The script can’t differentiate wheather the checksums differ due to replaced bootsplash or corrupted some other part. It happily will flash whatever you feed it, be it working image with diffrenet bootsplash or some broken build. You might brick your laptop and it would come without any warning.
There, first symptom of imminent bricking. Damaged image - since bootsplash does not work - but flashed without any warning. You will also get no warning if the part that does the boot gets damaged.
That’s the way to go, but details are beyond me. Untill you figure this out, I’d recommend to live with the standard bootsplash.
Another unscheduled power off. Some data:
–When I restarted, battery was showing 59%. Last time this happened it was showing 58%. I think coincidence.
–I was a few minutes into playing a video file (computationally demanding, sort-of?). Last time this happened I was also playing a video file.
–The computer did not feel particularly warm immediately after the random power off
–dmesg did not show anything I thought noteworthy, but I’m not an expert. Happy to set up whatever logging might be helpful
I didn’t experience this with older versions of coreboot, and I don’t think I’ve made any significant changes, so I’m inclined to think it’s something with chip power management.
I’ve recognized that there are issues with Qubes RC5 and Evo 960. Firmware Version 3 was kind of awful. Version 4 has reduced the whining noise, but I am unsure about the performance. The main problem is the fan noise. It’s horrible between 80 or 90°C. There is a (beep-beep-like chirp) noise, when booting, but not when charging. If I set CPU governors to powersave the noise will be reduced, but also the performance.
There are still issues with the fan and battery drain. If you are using some different kernel options for the i915 GPU firmware, the fan isn’t such noisy and you will get more performance at all.
So, is there concensus that 4.7-Purism-4 works well? I’m on 4.6 still and would like to see if 4.7 improves Qubes issues any, but I’m not looking forward to power or restart problems…
I’m not sure if there is a concensus. But for me Version 4.7 with Qubes works nearly well. I suggest to try the actual version, you could switch back, if you have a backup of the coreboot rom. Normally the script does that for you. I guess it will reduce the issues. But yes, there are issues with Qubes. I’ ve never recognized any real power or restart problems.
The only thing I’ve seen, was that all the USB ports are still have power even if you switch off the system or cut the power supply. That’s a bit odd, especially if you have an USB SATA disk connected. It would make sense, if you use e.g. Wake-on-LAN.