Starting the real time clock on virgin systems

[Kevin Hester]

Hi,

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.

Kevin


On Tuesday 10 December 2002 18:11, Eric W. Biederman wrote:
> Kevin Hester <kevinh at ispiri.com> writes:
> > Hi all,
> >
> > 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.
>
> > 1) In some non linuxbios component (i.e. some little app run at boot
> > time)
> >
> > 2) In linuxbios, but restricted to my mainboard.
> >
> > 3) 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.
>
> Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vt82c885.pdf
Type: application/pdf
Size: 74090 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20021210/6b4e60a9/attachment.pdf>