Last week I encountered a problem that I have never seen before with a recently acquired Socket 7 motherboard. The board was a Gigabyte GA-586HX (Rev. 1.58), a relatively uninteresting older Socket 7 board based on the well-regarded Intel 430HX chipset.
Apart from automatic voltage detection, the one distinguishing feature of this board is six memory slots rather than the usual four. That makes memory upgrading easier, although in order to get the full 512MB, one would still need at least two of the somewhat hard to find 128MB SIMMs.
What made this particular board much more interesting was that although it wasn’t in original packaging and had memory and CPU installed (four 4MB SIMMs—worthless; a K5 PR133 “goldcap” CPU—at least interesting), it looked completely unused. No signs of wear, no discoloration, and rather tellingly, no dust.
The board as such appeared to work well, but it had one very strange problem: It wouldn’t remember any BIOS settings. No matter what I changed in the setup, on next boot the old settings were back. The only thing that I could change was the date and time.
Experimentation didn’t shed any light on the problem either. It was perfectly possible to write the CMOS RAM, but as soon as the system was rebooted, the old CMOS memory contents would be back.
The system behaved as if the RTC battery was dead, except it didn’t complain about any such problem and the clock never got reset.
Coming back to the problem board several days later, I noticed a very strange phenomenon: The CMOS settings were reset again (as expected), and the clock was not. However, the clock did not advance while the board was powered off! The date shown was still January 2015, but several days behind.
At this point it was almost certain that there had to be something wrong with the RTC/battery chip. The part was a ST M48T86PC1, apparently manufactured towards the end of 1996. The board designers at least had the decency to use a socketed RTC, so replacing the part could be done without any difficulty (or soldering).
Once the original RTC was swapped for a Dallas DS12887+ manufactured in 2012, lo and behold, changed BIOS setup settings started to stick! And the clock didn’t stop when the board was powered off, either.
It is still unclear what exactly happened with the old RTC. One part of the puzzle was rather stupid BIOS behavior: By default, the POST won’t stop on any errors (and won’t even print any error messages). Which means that when the CMOS RAM is for whatever reason invalid, the BIOS will use default values—without even mentioning that anything might be amiss.
The “frozen clock” behavior is quite strange though, and currently I have no explanation for it. Anyone?
[Offtopic: CMOS]
I cannot seem to find a modern utility to save/restore BIOS settings from/to CMOS. Why? Isn’t there a uniform interface for doing so, or some other fundamental barrier? I would imagine there is a healthy demand for such an app.
Which OS? Linux has an nvram device to read and write it directly. BTW, on UEFI machines the BIOS settings are usually stored in EFI vars instead of the RTC.
There are DOS utilities for AT compatibles which do that. For more modern PCs, yes, there is a problem — it’s not really standardized how CMOS RAM past 128/256 bytes might be accessed. Such storage is basically not part of the architecture and the firmware uses it for its own purposes, and only the firmware needs to know how to access it.
With EFI there is a NVRAM which is part of the architecture (and it might be implemented in various ways, not necessary actual NVRAM), although I don’t think BIOS settings are usually stored there.
They are, for the most part, because the flash can be write protected while the cmos cannot. When vendors mess that up, we get this. (page 24+ specifically) There are utilities that parse the setup tables in the bios image to find out which bytes are which settings.
This RTC M48T86PC1 should be fully compatible to DS12887 usually. So what’s the difference between DS12887 and DS12887+?
GA-586HX was quite cheap choice in 1996, but lack of wide TAG-RAM limited the cacheable area to 64 MB. Not a problem if you disembowelled a 486-mainboard for SRAM DIPs. I think the Octek Rhino 9 was the only single CPU HX board that supported 512 MB out of the box.
The “plus” just indicates a newer lead-free and I think RoHS compliant device. There should no functional difference. The DS12887+ I used definitely works much better than the old M48T86PC1. I did not notice any problems.
I added the missing tag ram to my GA-586HX… the chips are still available and not expensive, if one doesn’t have a stash already. The 512KB onboard cache is nice because that’s not something that can be upgraded. From what I understand, the COAST caches were too unreliable so manufacturers just soldered the things on the board, but that prevented upgrades.
For people searching a DS12887 with external replaceable battery.
Project Model:
http://www.vogons.org/viewtopic.php?f=46&t=37404&start=20#p330169
Pics:
http://www.vogons.org/viewtopic.php?f=46&t=37404&start=40#p360426
As for the question of how this could occur. The issue clearly seems to be power-related since it went away when power was on. It could be that the time is stored in a different way inside the chip than is the BIOS settings. After all, the time has to be frequently updated but the BIOS settings not. Maybe the mechanism for the BIOS settings have higher demand for power than the mechanism for the RTC and thus more easily lose the settings – or maybe the BIOS-part of the chip is connected in a different way.
By the way, did it maintain the clock even when the battery was not there?
Cool stuff. Any “official” way to buy those?
The problem didn’t quite disappear when the power was on — even a warm reset still lost the CMOS settings, although not time. But yes, it sure looks like the clock is implemented differently than the RAM.
Anyway, the battery is sealed inside the RTC. So I can’t say if removing the battery would completely reset everything. Yes, I could destroy the casing and break the contacts but I am not sufficiently interested 🙂
OK 🙂 Amazing the battery is not replaceable.
BTW, is anyone aware of motherboards that actually charge the battery when the power is on? That would be pretty smart. Most good boards only use the battery when the computer is completely unplugged (or the PSU switched off) meaning that it is still usable even if the battery is dead (as long as one doesn’t unplug it) – presumably the motherboard can draw a small amount of power from the PSU even though it appears completely switched off.
Rechargeable batteries were tried already, before the sealed RTC/battery parts. They went out of vogue as soon as enough people realized that the rechargeables leak and can destroy the entire board. If someone could make a rechargeable that can’t leak/swell/explode and survives tens of thousands of cycles, it’d be great, but replaceable lithium batteries are the best solution so far.
Another option could be Timekeeper RTCs available from ST which use Zeropower SRAM technology. So you can look for M48T02-70PC1 as replacement for DIP RTCs. Perhaps other manufacturers have similar products? The source of the problem could be induced by irregular voltage (and/or low temperature) that cheap board desings not prevent.
I’m still figuring my way around the cache chip ids to upgrade it to the full 512kb cachable. I love this board. It’s one of the best HX boards, very stable, lots of ram slots and it supports 233mmx without modding.