A while ago I got a Thinkpad 760EL at auction (9547-a4f) for a reasonable price; it works quite solidly but had a major problem of the trackpoint not working, causing the system to refuse to boot. The actual error code being:
08611 - corresponds to "8611: System bus error. I/F between 8042 and IPDC
(Pointing device error when TrackPoint III is enabled.)"
I dismantled the entire thing right down to the cpu, put it back together, and still didn't have any luck. Eventually, I discovered if you press ctrl-d in the "config" section of easysetup, you get a hex editor to edit the cmos contents directly. After fiddling, I discovered that byte 0x20 of "Base 128 Cmos" had some interesting features. According to the tpctl docs, bits 1 and 2 set whether to enable the trackpoint. I couldn't make these do much, but found the following:
Bit 5 - when set, the system runs very slowly, as if the memory bus is
slowed.
Bit 6 - when set, disable the Trackpoint and boot even with errors <- this
is what I was looking for.
Bit 7 - unless this is set, the laptop locks/reboots/blanks soon after starting
whatever OS/program is running. Unsure why I need to set this, as it is off
by default.
As an example, the base128 section of my 760EL has:
52 ff 46 ff 15 ff 06 07 02 03 26 02 70 80 00 00
40 00 f0 00 03 80 02 ff ff 7f 00 00 00 00 11 00
02 20 c9 8a 13 fc 70 e2 03 39 51 00 80 03 09 89
ff ff 20 01 00 00 80 03 00 00 00 00 00 00 00 00
98 88 00 01 00 03 00 04 00 0b f0 00 00 ff ff ff
*snip*
The highlighted 02 byte should change
to 62 to ignore the trackpoint failing
(bit 6) and to stop lockups on boot (bit 7). UPDATE: read further before
changing these values.
You might need to fiddle about with some other bytes too, byte 0x21 or the lower bits of 0x20 seem promising. Let me know if others are successful and I'll add that info.
Updated 9 May 2005:
Micha has let me know that he managed to get a 560E working by changing the
02 byte to
20.
In order to get to the hex editor, he had to go to the test page,
‘Exit’, then press Ctrl-D. A hexdump (pre-editing) from the 560E
follows:
03 99 56 99 16 99 00 08 05 05 26 02 50 80 00 00 40 00 F0 00 03 80 02 00 BC 7F 00 00 00 46 11 00 02 00 C9 F1 00 00 00 00 00 77 77 00 00 02 05 F2 (02 -> 20) 00 BC 20 11 00 00 00 02 00 00 00 00 00 00 00 00 9A 88 02 01 00 03 00 04 00 0B F0 00 00 FF FF FF 00 06 50 28 0C 00 F0 14 0C 00 F0 3C 14 00 FF FF FF 00 06 03 61 05 0A 01 96 80 39 04 FF F0 00 00 C9 04 04 0C 0C 0F 00 00 0A 2E 02 82 49 53 B2 00
Updated 21 July 2005:
Pieter Agten writes that he has also found using 20 to be more
effective than 62. Using 62, he found that X11
displays wouldn't work correctly, setting it to 20 fixed that.
After getting the actual laptop booting, I was playing about with the IBM dos util disks, and found that they could boot a floppy even if a supervisor password was set, and boot from floppy was disabled... The start of the disk is the obvious place to look. Below is the start of Debian's woody rescue.bin:
Normal: 0000000: eb3c 9053 5953 4c49 4e55 5800 0201 0100 .<.SYSLINUX..... 0000010: 02e0 0040 0bf0 0900 1200 0200 0000 0000 ...@............ 0000020: 0000 0000 0000 29c3 dd84 284e 4f20 4e41 ......)...(NO NA 0000030: 4d45 2020 2020 4641 5431 3220 2020 fafc ME FAT12 .. 0000040: 31c9 8ed1 bc00 7c8e c1b1 08bf b054 f3a5 1.....|......T.. 0000050: 8ed9 fb88 1624 7cf6 c280 7428 f645 f07f .....$|...t(.E.. 0000060: 750a 8d75 f8bf 1c7c b102 f3a5 b408 cd13 u..u...|........ Modified: 0000000: eb3c 9049 424d 2035 2033 7900 0201 0100 .<.IBM 5 3y..... 0000010: 02e0 0040 0bf0 0900 1200 0200 0000 0000 ...@............ 0000020: 0000 0000 0000 29e8 1753 154e 4f20 4e41 ......)..S.NO NA 0000030: 4d45 2020 2020 4641 5431 3220 2020 fafc ME FAT12 .. 0000040: 31c9 8ed1 bc00 7c8e c1b1 08bf b054 f3a5 1.....|......T.. 0000050: 8ed9 fb88 1624 7cf6 c280 7428 f645 f07f .....$|...t(.E.. 0000060: 750a 8d75 f8bf 1c7c b102 f3a5 b408 cd13 u..u...|........
Spot the difference... This method will only work with a supervisor password (which also sets the HD password to be the same), if there is _just_ a HD password, it won't work, as even the BIOS doesn't know what it is. It won't remove the supervisor password, however it could let you access the disk contents if it has a corrupt boot sector and the supervisor password is forgotten etc.
Update: just found this site which has various info.
Another Update (1 April 2005): For newer laptops, looks like the same type of problem still exists, but with WakeOnLan packets this time. See Frank Bussink's post to full-disclosure.
If you've got any comments/other findings, I'd like to hear from you. In particular, if the hexediting works, please let me know. It could be that my laptop is just strange.
Matt Johnston - matt (at) ucc.asn.au