I have a dedicated PC for my Ultrium drive. I've decided to severely cheap out on the hardware for this machine since I only use it a few times a month. So not really giving it much thought I got the cheapest stuff I could find: a Fujitsu D2151-A1 mobo with a Celeron D CPU. As it turned out the Celeron was in fact Prescott based so I was looking at 56C idle temps despite 1 large fan strapped onto the heat-pipe CPU cooler right next to the large PSU fan. The overall power consumption of the system was around 90W.
I was getting over-temp warnings from the Ultrium drive from time to time, which does a fair bit of heating on it's own (though not as much as the CPU)
I've decided to get rid of the Prescott to improve the situation so I got a cheap Celeron 420, which is Conroe based and has about half the TDP of the Prescott.
As is usually the case there was a reason for the hardware being extremely cheap. The Fujitsu mobo couldn't handle the Conroe CPU. It was essentially limited to the old Pentium/Celeron D power hogs. D'oh! But wait.. There's an A2 revision of the board that handles Conroe cores, maybe success is just a bios mod away?
Not really..
It turned out the main reason the mobo didn't support Conroe CPUs is that the Conroes use a slightly different power system design.
There are a couple of key differences.
- The number of VID pins (thus the bit-length of the VID code) that specify the VCore requirements of the CPU has increased from 6 to 7-8. Thus the VID code supplied by the chip can't be used directly by the mobo.
- The VCCIOPLL pin has replaced the VCCPLL pin. They are right next to each other, but VCCIOPLL is not connected in the older system.
- The VRDSEL pin has changed. In the older system it's ground. But it should not be connected to ground anymore.
Thanks and credit goes to the original author of this mod who I couldn't really track down due to the first forum of it's appearance having disappeared (from what I could tell).
The green lands should be connected together, the red one should be masked.
Masking is not really an issue. Connecting them together is a horrible experience. Sure you could use conductive ink/paint. It's the best solution if you have some at home. In my case, since I'm not spending $20 on a new mobo I'm also not spending $15 on conductive ink.
You could also use copper or aluminum tape but the roll I have didn't have conductive glue so it was useless here.
I did try very hard to superglue both cleaned up copper tape and tin foil but in the end the top (VID) block of the mod refused to work properly so I gave in and soldered a piece of wire through all of them, heh.
Since the VCCIOPLL foil mod "stuck" and worked as expected I didn't feel a need to replace it with solder. The result looks completely horrible but.. it does work.
The 3 green lands on the side are for MSID (Market sector id) pins.. It didn't seem to have any effect for me so I ended up removing the short.
The mobo started up.. and what I got was:
"Genuine Intel(R) 800Mhz"
and a microcode warning.
Well that's to be expected I thought. I'll just update the microcode and have it detect the CPU's correct speed and that's it.
Not so much.. The microcode update did zilch to solve the speed issue, and I also couldn't boot any modern operating system. Linux died on trying to start the kernel. Windows died after loading up acpitabl.sys (DOS worked fine though.)
Well that's not good, but maybe I can use the BIOS from the A2 revision of the board which does support this CPU and that'll be it. It took a lot of effort, where I initially socketed the bios and was planning to use an external programmer since neither Fujitsu's tool or the standard Phoenix tools wanted to allow flashing raw images without any checks but several hours later I found that flashrom works pretty great. Now I just needed an A2 bios, but Fujitsu packs them into their own proprietary format.. How do I get a raw image? Turns out someone has already solved this problem too: Veit Kannegieser coded up an unpacker (search for "SNIPAC" here ) Nice. (Link fixed in 2020. Let me know if it's broken again.)
UPDATE Sept. 2016:
Thanks to Dieter I can now correct an omission in this article.
Quote:
"Decode the D2151_A2.OCF file with Veit Kannegiessers phoenixdeco (e_snipack.exe)
snip the bytes at address 00 to 0x6F (112 dec) at the beginning of the produced file
And snip one byte at it's end. The resulting file must have a length of 524.288 bytes."
After removing the first 112 bytes the file should start with 0xF0, 0xF6 and after removing the byte from the end the file size should equal 524288 bytes (0x80000). You can use a hex editor or if you have GNU tools in your OS just do: dd if=unpacked.bin of=biosraw.bin bs=1 skip=112 count=524288
That should give you a flashable file.
You should also do a full erase on the flash chip first before flashing the new image. I don't remember if this was necessary for me but it definitely works this way.
Hint: If you brick the board by restarting after a failed write or something you might still be able to use the floppy-disk based recovery feature ( assuming you still have one :-) )
I was fully expecting to get a brick when I pressed the reset button but surprisingly the A2 bios started right up without any errors. Complained about missing microcode patch which I updated again, but sadly.. The CPU was still running at 800Mhz. On the bright side Windows booted up fine now. Yay! Progress!
I looked around and saw that the FSB was at 100Mhz instead of 200Mhz. So that's what I needed to change. The problem with this board is that neither does it's bios allow any manual configuration of the FSB nor does it have a clock generator chip that is programmable through SMBus, so software solutions are.. not really possible besides hacking the BIOS which seemed too complicated to be worth it. I did notice that this board has Industrial revisions which have their own bioses (D2151-Sx) so I tried flashing the S2 bios but that didn't have any relevant settings either so I took a look at the clock generator chip. It's a CY28410.
According to the datasheet it has 3 pins (FS_A, FS_B, and FS_C) that control the FSB frequency like so:
(MID I suspect stands for middle, the pin is in MID when it's at 1.2V)
So since the FSB was at 100Mhz I was looking at the first configuration.
There are a few ways to go about changing this. I MIGHT have considered pin lifting if the 3 pins were right next to each other on one corner of the chip, but they're basically all over the place, so I would've definitely ended up damaging the board or the chip, but more likely both.
So I decided to just find where the pins are connected and cut the traces.
FS_C is at the top and disconnecting it is relatively easy since the trace doesn't go under the chip, It's only a bit of a pain because of how short it is but it's fairly easy to cut accurately with an xacto knife. I cut it and the speed jumped to 1.06GHz (0-0-1, 133Mhz * 8 = 1064Mhz)
Both FS_B and FS_A run under the chip though.. Argh..
I managed to trace FS_B to a quad 10K resistor pack to the right of the clock generator chip. I removed the resistor pack. The top resistor seemed to be unrelated so I put a single 10k 0805 there.
The bottom resistor from the pack was never used. The second was connected to FS_C but I've already cut that so it's irrelevant. The third one was FS_B.
Now as for FS_A it's on a trace that starts from a via to the left of the resistor pack goes under the pack(doesn't connect to any of it's pads) and disappears under the capacitor like so:
I just cut that near the via. The pins have a weak internal pull-down (probably.. since I'm not seeing random FSB configurations popping up after just cutting the traces) so this means that since I've cut FS_C and FS_A they are now both logic low meaning 0.
Since FS_B was 0 to begin with we should now be at 0-0-0 which is 266Mhz FSB, and indeed a startup confirms the CPU is at 2.13GHz (266Mhz x 8 = 2128Mhz) . Now I just needed to pull FS_B high to reach 200Mhz, which will result in 1.6Ghz, the stock speed of the Celeron 420. I did consider leaving it OCed mainly because I'm lazy and not having to connect a pullup means less work but the system wasn't running stable with it. Could've been the 533Mhz RAM's fault. Overclocking wasn't really my objective so I didn't investigate further. I proceeded to add the pullup instead.
FS_B has a trace connecting to another via supposedly going off to wherever it's controlled from originally. I cut that trace and soldered a piece of Kynar wire to the resistor pack's pad, which should now be connected directly to the FS_B pin. I then put a 10k resistor on top of a ceramic cap's shoulder (because it was the easiest place to get 3.3V from) and connected the wire to the resistor pulling the FS_B pin high.
And as the startup confirms:
SUCCESS!
System seems stable, and the CPU idles at 40C without any fan of it's own (just the PSU fan running) which is a great improvement over the Prescott space heater.
Later I've also found this alternative version of the pinmod:
here that may work just the same and trades some of the pin shorting for masking which is never a bad thing.
UPDATE Sept. 2016:
Fujitsu D2164-A1
Dieter (who also commented below) managed to apply this method to the D2164-A1(1). A board used in the Esprimo 5905 slim-case machines.
These ones |
Note that while these boards do use a standard ATX24 connector Dieter says they don't work with off the shelf power supplies. On the bright side, at least they don't damage them if you try.
The boards don't look that similar but apparently they're similar enough in hardware for the D2151 bioses to work on the D2164. This bypasses the issue of the D2164 not having a revision that supports Core2/Conroe CPUs to take the BIOS from. You can just use the D2151-A2/S2 bios instead.
First the pinmod:
You can follow my butchery above or use conductive ink as mentioned. Maybe you can find a good DIY recipe if you search around nowadays. Dieter chose a similar solution:
Then, the clock generator has to be modified. The chip is identical on both boards but the layout differs somewhat.
Dieter's clockgen mod with pin lifting instead of trace cutting |
Next do a full erase on the flash chip first (important) and then flash the D2151-A2(or S2) bios you've prepared aand..
Huzzah! |
Thanks, Dieter!
Wow! I think is more a bet with yourself than an upgrade!
ReplyDeleteCongratulations.
Hmmh,
ReplyDeleteI found this great article as I am working on a similar project. Have another Siemens Fujitsu Mobo with intel 945G chipset which is limited to slow P4 cooking plates.
I have a problem decoding the flash software from the compressed state as the tool creates a supposed to be binary file, but that is 113 Bytes too large to fit into the flash.
I would be interested how you managed to work around that.
Btw: stuff worth for reading on your site for many days.
Greetings Dieter
Glad you found it useful.
DeleteThere is still a header on the file after the unpack step that's only used by the Fujitsu flasher tool. I trimmed bytes off the beginning while comparing it with the old bios image I read out using flashrom. At one point stuff will line up ie. strings and structures will be at the same offset in both files, that's when you know you've removed the header. IIRC there's a pretty prominent string near or at the beginning of the raw image which is easy to spot in the SNIPAC unpack as well so just open up both files in a hex editor and remove enough bytes from the beginning of the unpacked image for that to be at the same offset as in the raw one.
It might be 113 bytes, but I don't remember now and it could potentially be more with the image not filling the entire chip so I'd double-check with the above method to be sure.
Let me know how it goes. If you can confirm the size of the header I'll update the post with the information.
Thanks,
Viktor
i got here randomly and have no idea what's going on. do you use the clock generator to change the cpu speed? how are they at all related?
ReplyDeleteThe clock gen chip is responsible for generating the FSB, yes. With a compatible CPU the FSB would be properly generated based on the state of the ID pins(lands) on the CPU. The newer CPUs are not compatible with these old motherboards in this aspect though, hence the pin masking/bridging to get the FSB freq to match. Also the Vcore. So you basically have a 99.9% pinout match except for these things.
DeleteGot esprimo e5915 w 2344-a2, w former release of bios i got qx6700 running in it but w any newer version of bios it wont, only my dual core e6300, guess they somehow restricted some cpus from running in newer version of bioses, thought that ive bricked the bios but i recovered and updated different kinds of update versions several times, after that i tried changing ram and cpu and found out that no version of bios newer than the former one works w anything that has more than 2 cores...
ReplyDelete