IBM Thinkpad 600E bios mod for processor update

Don't ask how to hack password. (BIOS Passwords)
Katch
BIOS Rookie
Posts: 40
Joined: Wed Feb 02, 2005 11:07 pm

I don't have my 600E anymore but just found this on a windows registry forum,

;Enable L2 Cache
;dword:00000100= 256KB, dword:00000200 = 512KB, dword:00000400 = 1024KB

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"SecondLevelDataCache"=dword:00000100

can't remmember if we ever tried this so have a go see if it cooks.

Oh and http://www.xabk.co.uk

Haven't had time to finish revising it or optimising a couple of the images but it's close enough.
Thinkpad T20 - 900 MHz (Looking for 1 GHz) 512 Mb - 40Gb 5200rpm - Mini PCI wireless Mod installed behind LCD - (Looking for Slim DVDRW)
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

To mod the 600E bios I can see two main approaches
(1) Study 600X bios how it enables/handles L2 and patch that part to 600E bios

(2) Keep L2 disabled in the bios by CMOS data bit (as 127 error mod) but add a patch to bios to enable L2 upon exit.

-------------

I believe (1) is difficult to do because 600X bios may have several places where the L2 is enabled, and it may be difficult to find them all.

(2) has difficulty where to find a good exit point so that L2 becomes activated only once after the boot, and also after suspend-resume (Fn-F4).

(2) has advantage because it is easy to calculate and control the checsum effect of the new code.

(2) has advantage since we have the L2 enabling codepatch from the Linux patch

If we knew the checksum algorithm then we could make the checksum change neutral by modifying some FF filled part of the BIOS.

All abovethings conisdered I vote for approach (2)
Sebi
BIOS Newbie
Posts: 22
Joined: Fri Mar 11, 2005 12:46 am

Sharedoc wrote:I believe (1) is difficult to do because 600X bios may have several places where the L2 is enabled, and it may be difficult to find them all.

(2) has difficulty where to find a good exit point so that L2 becomes activated only once after the boot, and also after suspend-resume (Fn-F4).

(2) has advantage because it is easy to calculate and control the checsum effect of the new code.

(2) has advantage since we have the L2 enabling codepatch from the Linux patch

If we knew the checksum algorithm then we could make the checksum change neutral by modifying some FF filled part of the BIOS.

All abovethings conisdered I vote for approach (2)
The checksum algorithm is easy: sum up the contents of the eeprom, byte by byte. Checksum is good if the sum is zero. The only thing I don´t know is where the checksum byte(s) (i.e., the offset to zero) is stored. Should be either at the beginning or end of eeprom contents. But we could simply use the version number or date code for that (stored at the end of the binary file).

I don´t think there´s more than one place where L2 is enabled. It´s more likely there´s only one subroutine, and this routine may be called more than once (but I don´t see a reason to do so; could enable L2 at some time and leave it on then). It´s also not difficult to find L2 routines; as some special instructions are used to do so (rdmsr, wrmsr). These commands only appear few times in the binary file. Gave some possible locations in earlier posts.

As for the backup eeprom: I´m having a spare 28F004 flying around. I´ll try to solder it to the board piggypack-style. Think the RP signal will be suitable for switching between the two chips.
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

There may be a third approach as a variant of (2)

(3) Insert a L2-on-patch between reset jump vector and bios start entry point. This may be even area that is not controlled by bios checksum calculation.

--------

RP-signal? Reset/Deep power down. Whatabout disconnecting traditional /CE input?
Last edited by Sharedoc on Sat May 28, 2005 8:59 pm, edited 1 time in total.
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

Let's speculate approach (3) forward because it looks the easiest, because we don't have to unpack/pack bios at all.

The end of the bios image contains the reset vector at address 7FFF0

EA 5B E0 00 F0

which means

JMP F000:E05B


We can modify any jump adress instead of F000:E05B to point to our patch.
In the patch we just need to have code to set processor L2 on, set L2 off in CMOS data (to eliminate 127 error) and then finish with jump to F000:E05B

We need to find a place to put the patch somewhere where it is not counted to the bios checksum.

If this is not possible, we need to try to make the patch sum-neutral, so that the bios checksum keeps the same as before.

Propably reset vector and 11 bytes after the reset vector (contains bios date) are not counted to the checksum. Anyway 11 bytes is propably not enough for patch.

Now, where do we find the code to set the L2 on? Linux guys, can you help, you had the code in the Linux kernel patch already...
Last edited by Sharedoc on Sat May 28, 2005 9:19 pm, edited 1 time in total.
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

I have also a spare 28F004 from a dead 600X motherboard.

I could desolder it from 600X and solder it to 600E in parallel to the original flash. And make a wire jumper to /CE input to select which flash chip is active. But it is quite challenging work, and may ruin the motherboard if soldering goes wrong.

Has anyone studied in detail how the IBM flashing program actually works? Sebi, can you help here?

I wonder is there any other flashing program working for 600E than IBM's own floppy based?
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

Sebi,

I wonder if (1) could be done is a checksum neutral way? Maybe some innocent part of the bios code could altered to compensate for 600E code to 600X code arithemetic sum difference?
Sebi
BIOS Newbie
Posts: 22
Joined: Fri Mar 11, 2005 12:46 am

Sharedoc wrote:I have also a spare 28F004 from a dead 600X motherboard.

I could desolder it from 600X and solder it to 600E in parallel to the original flash. And make a wire jumper to /CE input to select which flash chip is active. But it is quite challenging work, and may ruin the motherboard if soldering goes wrong.

Has anyone studied in detail how the IBM flashing program actually works? Sebi, can you help here?

I wonder is there any other flashing program working for 600E than IBM's own floppy based?
Tried that, however, my 2nd eeprom doesn´t work. Switching over to the original eeprom works well, and I have checked the connections for the new one over and over again. Also tried to flash the new eeprom, this also failed (says some hardware error occured). Maybe my 2nd flash chip has gone?! Any other ideas? Hopefully you´ll have more luck, sharedoc. Soldering wasn´t a big problem, used some flux and a fine solder tip.

I didn´t study the flasher in detail, just replaced the bios file on the disk with my patched version. The flash tool for the 600x (doesn´t need a boot disk, can be started from within Win) works for 600e too.

IMHO there´s no code that´s not calculated by the checksum. The checksum algorithm takes all the 512kb of the flash chip and sums it up. But there are some parts filled with 0x00 that could be used to inject some L2 code. The problem might be that the bios on some point tries to initialize the cpu and thus disables all caches. So (3) might not be very useful. As soon as I´m getting my backup eeprom to work I´m continuing to compare 600x and 600e bios. They are very similiar, and we know 600x can handle pIII. I think I´ve found the cache routine already (see earlier postings here), but can´t find the PII/PIII distinction (both bioses contain the same routine). IMO it´s some check that fires the 127 error, not the cache init itself. Could be a size check as PII has 512kb half-speed cache instead of 256kb full-speed. But haven´t found yet...

As for the checksum I´d take the date code at the end of the file. Space for the patch could be at 0x7e800, there´s a large area filled with 0x00 in the bios file I´m having here (INET36WW)

Code for proper L2 initialisation can be taken from the linux kernel module from this page: http://www.maths.ox.ac.uk/~challet/module/module.html

Cheers,
Sebi
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

Sebi,

My worry is that the binary bios image you are studying is packed and so it is not the true bios executable binary file. If this is true, it does not make sense to try disassemble it.

First, an executable file needs to be extracted from it. I know how to do it with one tool (using Bios1.35.1 utility from www.geocities.com/mbockelkamp), but I am not sure if the tools extracts right. The tool cannot pack back, which limits its usefullness.
Sebi
BIOS Newbie
Posts: 22
Joined: Fri Mar 11, 2005 12:46 am

I started the disassembly at the reset vector. All parts I disassembled from there disassembled cleanly, all references contained valid code. Until now I found no unpacking routine nor packed code. The cache init routine is very similiar to the routine used by the linux kernel module, so I´m quite sure this routine isn´t packed. Also, 600e and 600x bios contains identical routines, which would be very unlikely if the bios has been packed.

Sebi
Raceboy
New visitors - please read the rules.
Posts: 7
Joined: Sat Apr 02, 2005 10:13 am

Sebi, 600E is equipped with PII Dixon core which has 256 on-die full speed cache, just like PIII.
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

Sebi,

About the your 2nd 28F004 not working: maybe it is something to do with 28F004 boot block protection?

If your second 28F004 is coming from non-IBM machine, it propably contains something else in boot block.

There are some test points near the 28F004, some of which may act as jumper to enable boot block flash.

Can you read contents of 2nd 28F004?
Sharedoc
Notebook Genius
Posts: 679
Joined: Mon Aug 18, 2003 8:46 pm
Location: Finland

Approach (4): What if we cheat that the PIII processor is PII, i.e. change after each CPUID instruction the content of returned value registers to contain PII CPUID.
Sebi
BIOS Newbie
Posts: 22
Joined: Fri Mar 11, 2005 12:46 am

Sharedoc,

the 2nd 28f004 comes from an almost dead 600e board, so it should be fine. Maybe the chip has been damaged upon desoldering or soldering to the board. I´ll try to get another chip and try again. What about your backup eeprom ? Did it work? Anybody else? Would be great to have a testing board....

Raceboy:

Right you are, missed that point. So there almost no differences between pII and pIII... I replaced the pIII-500 with the pII-366 again. The pIIIcache-module works with both chips in the same way, so cache init can´t be too different. Found 2 differences: pIII says model/stepping 681, while pII-366 reports 66a, and pIII cache is 8way associative instead of 4way for pII.

This is the point I don´t understand: the bios checks first if cpuid(0) returns the "GenuineIntel" (0xc470d). If yes, it checks that ah gives 0x06 (family code of pII/III; 0xc4738) for cpuid(1) - that´s all I found before cache init. No distinction btw. pII/pIII. But maybe it´s before that point? There´s also no check for any cmos bytes or any fired error 127 as far as I can see.

Can anybody confirm my findings? The complete routine starts at 0xc43d7. What am I missing?
Sebi
BIOS Newbie
Posts: 22
Joined: Fri Mar 11, 2005 12:46 am

Sharedoc wrote:Approach (4): What if we cheat that the PIII processor is PII, i.e. change after each CPUID instruction the content of returned value registers to contain PII CPUID.
Think that would be a bad idea. As the pIII has a slightly different cache from pII it might require a slightlty different initialisation. The linux module does some calculation on cache size and other parameters before actually turing on.

What about (5): find out where the 127 is triggered and start from there!

Sebi
Post Reply