I wonder if this can help with the extremely irritating bug (intentional?) on the X270 where if you give it a third party 9-cell battery, it will raise CPU_PROCHOT all the damn time, and my processor would drop to below 1Ghz clock speeds.
Back when I used to have an X270 I had a shell script that ran on boot which poked a register to disable thermal throttling handling. Not at all ideal, but it made the machine usable in the absence of official Lenovo batteries which they stopped manufacturing pretty damn quickly.
You can use ThrottleStop[1] to disable PROCHOT on non-standard battery. I encountered similar issue with throttling on my Dell Precision laptop when I was charging it via 60 W USB-C charger instead of proprietary barrel-type 130 W plug. The system triggered a warning about low power charger and initiated aggressive cpu frequency scaling. By using ThrottleStop, I was able to use type-c 60W charger on lightweight tasks (such as web browsing, older games) just fine.
Dell likes to pull this stunt on other devices too. Like their 1L desktops in the OptiPlex line that I managed for many years. Even though we were using genuine Dell power adapters, if they became slightly unplugged but remained powered, they would enable PROCHOT.
This was fine until the machines randomly started setting PROCHOT on genuine power adapters that were fully plugged in. Eventually I just deployed a configuration with PDQ to all the machines that ran ThrottleStop in the background with a configuration that disabled PROCHOT on login.
Unfortunately, I couldn't get it to consistently disable PROCHOT pre-login, so students and teachers in my labs would consistently wait 3-4 minutes while the machines chugged along at 700 MHz as they prepared their accounts.
I was the happy owner of ThinkPad X1 Extreme g1. It had that bug out of the box, new original battery. Once it thermal throttles, it never goes back to full GHz. It throttled pretty soon, cause big CPU small chassis. Yes, I had a script like that.
It is still somewhere on a shelf, so maybe its day will come again.
Nice to finally know what was happening to my x270 after so many years. Well good thing it doesn't happen when connected to power nowadays is my home server
Possibly. Usually this is handled by the embedded controller, and not sure if that was reversed or not. You may be able to tristate the GPIO line that tells the CPU that a pin means PROCHOT, which would allow you to ignore the ECs attempts to do this.
As a former owner of a T470, Lenovo included a pretty beefy component from intel that was supposed to be feature complete by itself for dynamically managing thermals, including funky ideas like detecting if you were potentially using the laptop on your legs etc. and reducing thermals then, but giving full power when running plugged on the desk.
Time comes for delivery, Lenovo finds out that intel did a half-assed job (not the first time, compare Rapid Start "hibernation" driver earlier) and the result is kabylake T470 (and X270 which share most of the design) having broken thermals when running anything other than windows without special intel driver, thus leading to funny tools that run in a loop picking at an MSR in the CPU in a constant whack-a-mole with piece of code deep in firmware.
Some people prefer to know exactly what their computer does, either to enable debugging in obscure cases or due to security concerns.
Thanks to Intel, who has invented the completely unnecessary System Management Mode, to compensate for the laziness of Microsoft, who could not be bothered to update MS-DOS and Windows with some features required in modern computers, now the BIOS has the ability to do whatever it wants on your computer, without this being detectable by the owner.
Hopefully the BIOS writers do not abuse this, and the many problems caused by BIOSes are due to unintentional bugs and not due to malice, but it would still better to be certain that your firmware does not do anything nefarious.
When debugging hardware problems, it is also much simpler when you are certain about what the computer really does, instead of not knowing whether the BIOS takes control when certain hardware events happen, overriding any policies that you may try to implement in your operating system.
Replacing the proprietary BIOS still does not provide complete control over what you own, as there are auxiliary CPUs with their own agenda, but it is still much closer to full control than when you do not know what the BIOS does.
That still doesn't answer the question of why it's better. Unless you're paranoid about an OEM backdoor, I think this is cool but not worth the effort.
I'm not sure that's paranoia (as others have pointed out, OEM firmwares have had security problems before), but sure, let's ignore security problems for a moment.
1. Firmware contains bugs. Old proprietary firmware tends to not get fixes. If you switch to an open source version, you can get the bugs fixed.
2. Libreboot claims to be faster to boot than the vendor firmware. Depending on the particular device/firmware, that wouldn't surprise me at all.
I think firstly is the FOSS obsession and backdoor paranoia from evangelists, and secondly and the more practical one is that the proprietary IBM BIOS is full of bugs and anti-consumer blacklists and whitelists designed to limit repairability and upgradeability, which stil boggle my mind on how those laptops got such a good image on that front.
Yes, if you live and organize your life around things that are unlikely to happen to you, but only because they've happened ONCE to someone else, typically a high value target by state actors, that's called paranoia.
Most people are not gonna be targeted via BIOS hacks. From state actors to online scammers they all have easier ways to getting your data remotely.
As far as I'm aware, it has less functionality than the OEM, so you use it to _remove_ features (good and/or bad).
Aside from that, I suppose it means you can run a more up to date firmware if yours is no longer maintained, but I'm not sure what that means in practical terms.
There's also the "hyper paranoid" fork "canoeboot" which has no proprietary blobs, and presumably _even less_ functionality.
The short answer is; if you don't know why you want it or need it, you probably don't.
As far as I can tell, this is the only reason, you'll likely lose a bunch of functionality (that's been my experience); so "principle" is the only reason I'm aware of (or minimalism, but that's a principle too is it not?).
I suppose if nothing else, you can run a more up to date firmware if the vendor stopped supporting yours, but I have no idea what that means in a practical sense.
Really cool! I wish that Coreboot was available for more recent Thinkpads. I have a Z13 Gen2 which I plan to use until it falls apart, and would love to liberate it with Coreboot. But alas, I can't.
How's your experience with that? It's on the top of my dream laptop list but it's expensive and the second gen is more so....looks like they killed off the line right before it got to the sweet spot (ryzen ai max line) just like the surface laptop which makes me sad.
There were a lot of reports about those things having power or heat firmware problems?
I have one for work; I was excited to receive it, I’ve never been more disappointed with a laptop bearing the ThinkPad brand. Lots of intermittent issues with graphics, BT audio, and performance.
because the x280 and x270 are similar enough I didn't need to try very hard to get it to post or boot a live USB to further investigate (effectively acting as a decent template for me to work off of)
The console viewing itself was provided by `cbmem -1`, which I could run via a NixOS live USB with nixpkgs#coreboot-utils
You can sometimes find the serial lines if you are careful. Otherwise you can use the flashrom to store the output, and read it back out after each failure. It is much easier to just poke around and find the serial if you can, either from schematics (it seems the author has these) or by hand with a lot of patience or board scrying.
pretty cool work!
Though it leaves me wondering if coreboot/bios code can directly interface with thermal-management and battery controller , shouldn't it be feasible to improve upon battery life by exposing some interface to OS, like apple laptops ?
The PROCHOT discussion in this thread is a good example. Lenovo stops making batteries, third party ones trigger artificial throttling, and the only fix is poking registers with a boot script. With coreboot you can just... fix it properly.
More broadly: faster boot times (sub-second POST is common), no vendor bloat or hidden phone-home behavior in the firmware, and you can actually audit what runs before your OS loads. That last one matters more than people think. Your BIOS has full access to everything on the machine before any OS-level security even starts.
I'm glad you saw it as humor- thats how it was intended. I love my wife dearly but we spend our free time very differently. I'm an engineer, she's an epidemiologist. I'm more creative and like to build things, she's more interested in watching the news. We do have great conversations about cosmology and physics though.
Back when I used to have an X270 I had a shell script that ran on boot which poked a register to disable thermal throttling handling. Not at all ideal, but it made the machine usable in the absence of official Lenovo batteries which they stopped manufacturing pretty damn quickly.
[1]: https://www.techpowerup.com/download/techpowerup-throttlesto...
Dell disables that tinkering on some models of XPS in BIOS/EC so ThrottleStop won't to jack.
This was fine until the machines randomly started setting PROCHOT on genuine power adapters that were fully plugged in. Eventually I just deployed a configuration with PDQ to all the machines that ran ThrottleStop in the background with a configuration that disabled PROCHOT on login.
Unfortunately, I couldn't get it to consistently disable PROCHOT pre-login, so students and teachers in my labs would consistently wait 3-4 minutes while the machines chugged along at 700 MHz as they prepared their accounts.
It is still somewhere on a shelf, so maybe its day will come again.
As a former owner of a T470, Lenovo included a pretty beefy component from intel that was supposed to be feature complete by itself for dynamically managing thermals, including funky ideas like detecting if you were potentially using the laptop on your legs etc. and reducing thermals then, but giving full power when running plugged on the desk.
Time comes for delivery, Lenovo finds out that intel did a half-assed job (not the first time, compare Rapid Start "hibernation" driver earlier) and the result is kabylake T470 (and X270 which share most of the design) having broken thermals when running anything other than windows without special intel driver, thus leading to funny tools that run in a loop picking at an MSR in the CPU in a constant whack-a-mole with piece of code deep in firmware.
Why though? Not a single reason mentioned in post about why would it be better than whatever stock BIOS the laptop is shipped with.
Thanks to Intel, who has invented the completely unnecessary System Management Mode, to compensate for the laziness of Microsoft, who could not be bothered to update MS-DOS and Windows with some features required in modern computers, now the BIOS has the ability to do whatever it wants on your computer, without this being detectable by the owner.
Hopefully the BIOS writers do not abuse this, and the many problems caused by BIOSes are due to unintentional bugs and not due to malice, but it would still better to be certain that your firmware does not do anything nefarious.
When debugging hardware problems, it is also much simpler when you are certain about what the computer really does, instead of not knowing whether the BIOS takes control when certain hardware events happen, overriding any policies that you may try to implement in your operating system.
Replacing the proprietary BIOS still does not provide complete control over what you own, as there are auxiliary CPUs with their own agenda, but it is still much closer to full control than when you do not know what the BIOS does.
Unfortunately, they have. Multiple examples from the excellent Cathode Ray Dude:
https://www.youtube.com/watch?v=q5M0TwnkWUM https://www.youtube.com/watch?v=ssob-7sGVWs
This can be confusing on HN, I know.
Reading https://libreboot.org/#why-use-libreboot might provide further enlightenment.
1. Firmware contains bugs. Old proprietary firmware tends to not get fixes. If you switch to an open source version, you can get the bugs fixed.
2. Libreboot claims to be faster to boot than the vendor firmware. Depending on the particular device/firmware, that wouldn't surprise me at all.
Yes, if you live and organize your life around things that are unlikely to happen to you, but only because they've happened ONCE to someone else, typically a high value target by state actors, that's called paranoia.
Most people are not gonna be targeted via BIOS hacks. From state actors to online scammers they all have easier ways to getting your data remotely.
Lenovo does have a history with installing a very obvious spyware rootkit on their consumer PCs[0].
[0]https://support.lenovo.com/us/en/product_security/ps500035-s...
As far as I'm aware, it has less functionality than the OEM, so you use it to _remove_ features (good and/or bad).
Aside from that, I suppose it means you can run a more up to date firmware if yours is no longer maintained, but I'm not sure what that means in practical terms.
There's also the "hyper paranoid" fork "canoeboot" which has no proprietary blobs, and presumably _even less_ functionality.
The short answer is; if you don't know why you want it or need it, you probably don't.
I suppose if nothing else, you can run a more up to date firmware if the vendor stopped supporting yours, but I have no idea what that means in a practical sense.
There were a lot of reports about those things having power or heat firmware problems?
I’ve messed around with porting coreboot on two desktop platforms but always had the benefit of a HW serial port…
The console viewing itself was provided by `cbmem -1`, which I could run via a NixOS live USB with nixpkgs#coreboot-utils
More broadly: faster boot times (sub-second POST is common), no vendor bloat or hidden phone-home behavior in the firmware, and you can actually audit what runs before your OS loads. That last one matters more than people think. Your BIOS has full access to everything on the machine before any OS-level security even starts.
Ah, todsacerdoti. ;)
(the user who posted my blog post is not me :p)