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.