Well I can tell you that the CACHE chips are impossible to get at this time, as I've research them and you can't even get new old stock. And they use an infill in the perimeter, after soldering, that I assume is heavily needed to prevent component cracking or damage due to thermal expansion.
Here's the deal, it's possible, possible..... that the caching errors are due to incorrect voltage being fed to the SRAM. CACHE = SRAM, FYI
Here's my previous work on fuel PIMM:
https://forums.irixnet.org/thread-3238.html
The ENV chip is very easy to replace on a PIMM...for me. However the ENV chip has to have been damaged originally, from my understanding the standby 5V system from the Fuel power supply does not feed into the PIMM. Hence power supply 5V problems that kill mainboard ENV chips don't normally affect the fuel PIMM ENV chip. But a malfunction in the PIMM's VRM would be able to damage the ENV chip. I believe that the PIMM's VRM takes the 12V input to create its other (lower) voltages. And the ENV chip is directly connected, through limiting resistor networks, to all the VRM output voltages for monitoring. Going above those voltage ranges WILL DAMAGE A DS1780 sensor legs on the offending voltage...maybe more.
In the case of the thread above, one of the PAIR of SMB high-speed Diodes next to the first FETs in the fuel's MAIN 12V VRM went short, causing the voltage on the PIMM 5V to rise to about 6.5v (if memory serves) because it shorted on the HIGH MOSFET....great. When ENV chip became damaged it reported it as 9v! Because those diodes aren't made anymore, that is the forward bias of those diode is considered archaic for some reason, I had to replace the diode pair with a new set of high-speed diodes. Those diodes are used to handle the back EMF spike caused by the FET closure. The original parts had a forward bias of 600 mV, however no one sells diodes with that bias anymore in that size. All I could find was 700 mV forward bias high-speed diodes. So that's what I bought and had to replace both of them because they NEED open at the same time. Else one would open before the other and take the brunt of the spike and things would be very bad. As the diodes were used basically parallel-ish. After I replaced the pair of diodes and replace the DS1780... things appeared good on the surface. I forget if I change the nearby FETs or not due to concern about internal FET diode body breakdown from loss of their back EMF diodes. Normally the FET body can take it for a little while but it's not designed to take that kind of punishment (avalanche). That's why they added the diode to relieve the FET of the back EMF burden. I may have changed out the FET pair under caution... If I did it would be in the thread.
Jan-Jaap made the important recommendation after I had fixed what I found in the VRM region that the ENV chip may have in fact suffered damage on one of its several sensor legs and it was still misreporting a single voltage, even though everything else about it seem to work period. That recommendation ended up being correct which I was able to confirm with my equipment by testing just the 5V sensor leg on the ENV chip using a 200 mV ultra low stimulus signal from my test equipment to rule out semiconductor interference. It showed that I actually got incorrect impedance through the chip compared to working PIMM's DS1780, proving that the internal DS1780 circuit that runs the 5V sensing leg had been altered, in a bad way, by the event and was not normal. Since the VRM now worked the replacement ENV chip remains undamaged and functional.
Now the problem is the repaired PIMM has never been fully tested in another fuel. I'm between issues right now and don't have a test board to try the CPU that's programmed to that speed. I fixed a 600 MHz PIMM, but the stuff I'm running is currently 700 MHz and I'm not in the position to reprogram a mainboard right now. Other experiments have to come first before that happens. The CPU is taken as functioning but because I don't have an under clocked (or properly configured to the correct clock speed) mainboard at the moment the CPU claims it has caching errors while also being misconfigured. However a forum member pointed out that the caching errors are actually perfectly normal if you have a (wrong) HIGHER CPU configuration and halting due to misconfiguration.
I'm still hopeful that my PIMM SRAM actually works, but everything else seems to function including loading the PROM code until tests stop it (before GUI, in POD mode halted due to misconfig).
After I get myself unstuck from an equipment problem, I will eventually continue my work on manually flashing PROMs on Fuel, once I do that I'll be able to hopefully manually go between either several (or all) configurations without running the mainboards. Once I have that known ability I'm going to reprogram a mainboard to finally test this repaired PIMM.
So all I can really offer is to say that you probably have VRM damage on the CPU PIMM. If the CPU is still recognized then it's not dead, I can't 100% guarantee anything about your SRAM, as far as I know we will not be able to transplant SRAM BGA chips from PIMM to PIMM, due to the adhesive use to stabilize them and the inability to reapply it even if I got it off and soldered the chip. I am open to finding an unused stash of SRAM, but my investigation made the claim that the footprint of the BGA pattern on these IBM SRAM chips was nonstandard. I was unable to find any SRAM that mimics this footprint. So that meant I had to find IBM SRAM of the exact same model. I was unable to do so. But I haven't looked for a couple years. The SRAM BGA chips are small enough where they could be done by hand and you don't need a rework machine to do them. But after carefully carving away the adhesive while successfully extracting the old chip off the board without damaging any of the pads and putting a new one on I'm unsure what the success rate would be. I also found that on the advanced high-level manufacturer PROM diagnostics, in POD, ...I thought... gave a location where the exact chip(s) that the errored were on the stenciled grid/label system on the PIMM. I'm almost positive that the output code literally gave the two four or five digit codes that matched one or more of the stencil labels next to the SRAM BGA chips. So I thought the on-board PROM was able to actually tell you which SRAM chips specifically it didn't like. Which would obviously help repair. But I think you have to set the POD diagnostics to highest level.
I am unfortunately pretty busy right now but I still have my repaired 600 PIMM and a new 500 PIMM available to take readings against if you wanted to try to give basic repair or evaluation a shot. Obviously there's a limit to what I can do right now, but I can definitely check out places in the VRM when compared to other PIMMs and I can try to fix any spots that are bad plus install a new DS1780.
Also if you just want to replace it outright, I'd be interested the PIMM as a research/repair subject.
Let me know.
NEED -> 