[CC coreboot@coreboot.org]
Am 01.07.2012 16:45 schrieb Henrique de Moraes Holschuh:
On Mon, 25 Jun 2012, Carl-Daniel Hailfinger wrote:
You do know that all Thinkpad T60/X60 can replace the BIOS with coreboot?
How would that work? About half the stuff the firmware does is an interaction between the EC and the SMBIOS, did anyone reverse engineer that?
Actually, yes. You can achieve quite a lot if you have IDA Pro and a few high-end logic analyzers at hand.
Or are you guys just running the EC in whatever state it cold-starts at? You can probably get away with it for a while on a T60/X60, but...
Well, at least make sure to have thinkpad-acpi and use something to monitor the kernel log, so that if the EC starts alarming that the machine is going to catch fire, thinkpad-acpi will LOG_ALERT and LOG_CRIT to the kernel log, and something will tell you to DO SOMETHING ASAP. Gnome thinks it knows better, and *actively* refuses[1] to output even the two "your box is about to do something REALLY bad" highest priority log levels. KDE is not that irresponsible and will alert you.
[1] as in: it was done on purpose, because "users don't know what to do with those messages anyway".
The information about assisted machine suicide on GNOME is actually quite interesting, I don't know how this is handled on a machine running coreboot.
Regards, Carl-Daniel
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
[CC coreboot@coreboot.org]
Am 01.07.2012 16:45 schrieb Henrique de Moraes Holschuh:
On Mon, 25 Jun 2012, Carl-Daniel Hailfinger wrote:
You do know that all Thinkpad T60/X60 can replace the BIOS with coreboot?
How would that work? About half the stuff the firmware does is an interaction between the EC and the SMBIOS, did anyone reverse engineer that?
Actually, yes. You can achieve quite a lot if you have IDA Pro and a few high-end logic analyzers at hand.
All what was required is to connect the logic analyzer to the LPC bus that is used for communication with the embedded controller. Reversing the ACPI code was pretty useful to get an idea what the EC registers are for. To ease reading the bus traffic, i reversed the Tektronix Plugin API that is used on my logic analyzer and wrote a LPC bus decoder. (example screenshot: http://stackframe.org/LPC/tek_lpc.JPG)
Or are you guys just running the EC in whatever state it cold-starts at? You can probably get away with it for a while on a T60/X60, but...
Well, at least make sure to have thinkpad-acpi and use something to monitor the kernel log, so that if the EC starts alarming that the machine is going to catch fire, thinkpad-acpi will LOG_ALERT and LOG_CRIT to the kernel log, and something will tell you to DO SOMETHING ASAP. Gnome thinks it knows better, and *actively* refuses[1] to output even the two "your box is about to do something REALLY bad" highest priority log levels. KDE is not that irresponsible and will alert you.
[1] as in: it was done on purpose, because "users don't know what to do with those messages anyway".
The information about assisted machine suicide on GNOME is actually quite interesting, I don't know how this is handled on a machine running coreboot.
The fan control is actually done in Hardware in the X60/T60 EC. So basically all coreboot needs to do on init time is to program the EC to do automatic fan control. You can of course have your own FAN control tables, or program the EC to do fan control in software. But for the reason already stated above i never did that.
Sven.
On Mon, 02 Jul 2012, Carl-Daniel Hailfinger wrote:
[CC coreboot@coreboot.org]
Am 01.07.2012 16:45 schrieb Henrique de Moraes Holschuh:
On Mon, 25 Jun 2012, Carl-Daniel Hailfinger wrote:
You do know that all Thinkpad T60/X60 can replace the BIOS with coreboot?
How would that work? About half the stuff the firmware does is an interaction between the EC and the SMBIOS, did anyone reverse engineer that?
Actually, yes. You can achieve quite a lot if you have IDA Pro and a few high-end logic analyzers at hand.
Indeed. That's way beyond what I can do, here. Is there any way to get a (clean room style) documentation about what you guys found? It could help improve the Linux drivers...