Confirmed on Intel Clearwater (e7500 chipset w/ RTC built in to NatSemi superio).
On Tue, 10 Dec 2002, Kevin Hester wrote:
Re: proof that this feature is in the mc146818
Sure, I agree - proof good. Saddly, the only datasheets I can find on the net are for newer clones on this chip. The common dallas semi part datasheet doesn't show the register usage (arrgh!). However, this via clone does show register usage (attached).
For REGISTERA it says that DV0-DV2 must have the value of 010 to turn on the oscillator. The default value of these bits are zero and the award BIOS on my board will init these bits correctly if found to be zero.
The problem occurs in the linux hwclock tool. In rtc.c it spins waiting for the second count to change. If the RTC has not had the oscillator enabled, the second count does not change.
For the patches I've submitted, I've simply called rtc_init(0) from the vt8601 southbridge init. I didn't want to change other systems right now.
Ron mentioned he had seen this exact behavior on some 440bx(?) board he was working on. If someone is out there with some different chip set, you can do an experiment:
- Shut the system down
- Remove the battery
- Wait a good long time
- Insert the battery
- Boot linuxbios & linux. If hwclock hangs, then you have this problem.
On Tuesday 10 December 2002 18:11, Eric W. Biederman wrote:
Kevin Hester firstname.lastname@example.org writes:
First I'd like to describe a problem I've encountered:
I have a virgin motherboard that has never been powered up before. i.e. this board was not manufactured elsewhere and a 'standard' BIOS has never been used on it.
When booting this board I discovered an interesting problem: the boot would hang when the "hwclock" tool was invoked by /etc/rcS.d/<some script that reads the rtc>.
The underlying problem is that this common linux utility is reading the RTC via the standard IO ports 70-71. Within this RTC window all of the dallas semiconductor RTC clones use a few bits in register 0x0a to enable the clock when power is down. The default values of these bits do not enable the clock - presumably to avoid draining the battery until the boards are first placed into production.
I've modified my version of linuxbios to ensure that these bits are set to enable the RTC updates. My question is, where is the best place to make this change?
Assuming your RTC hardware is in your southbridge: src/southbridge/<manufacturer>/<chipset>/rtc.c or something like that.
It is my experience that only for reading the real time clock is a real time clock a real time clock. The control functions which are handled rarely tend to be specific to an individual implementation. Though there are generally similarities within a family of implementations.
- In some non linuxbios component (i.e. some little app run at boot
In linuxbios, but restricted to my mainboard.
In linuxbios, but in 'common' code that applies to all intel boards.
In linuxbios common code that applies to your southbridge. For now it will probably work best to have that code called from your mainboard, and others who need it can call that code as well.\
I'm in favor of option 3, but I thought I'd ask first. I think this problem would apply to any board. The reason we haven't seen it before is that most folks are running linux bios on boards that once had a standard bios. The standard bios has already 'activated' the RTC updates.
I suspect being the second BIOS on the boards has certainly had something to do with it. But given how much chips vary this may simply be an oddity of your particular variation of the board.
What do you think?
Until I see proof that this feature was in the original motorola mc146818 real time clock, and has been in all implementations there after, I don't want the code to apply all boards indescrimanently.