lkml.org 
[lkml]   [1999]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: i386/RTC: old problem, new solution?
On 20 May 99, at 17:10, Riley Williams wrote:

> Hi Ulrich.
>
> ===8<=== CUT ===>8===
>
> >> That's not quite what I understood your original email to be
> >> referring to. Let's go for gold here and look at the boot
> >> procedure:
>
> >> 1. Reset button is pressed, and the ROM BIOS gets control.
>
> >> 2. Amongst the tasks taken by ALL of the ROM BIOS's that I've
> >> come across is to set the system's idea of the time from
> >> the RTC if an RTC is found. Therefore, the system clock is
> >> set BEFORE the kernel even gets a look in.
>
> > The "system clock" is a collection of variables in the kernel,
> > maintained by the kernel. I hope you agree. As The BIOS starts
> > before Linux is in RAM, the BIOS can't set the time for Linux. I
> > hope you also agree.
>
> My understanding was that Linux reads the ROM BIOS clock and
> initialises its system clock from that, in which case the BIOS
> effectively initialises Linux's system clock.

No: The RTC is a piece of hardware that is addressed directly as the
serial ports and disc controllers. No need for a BIOS.

>
> >> Granted, the ROM BIOS has no idea of timezones, but there's
> >> precious little we can do about that.
>
> > <soapbox>
> > Well, Microsoft does not know about timezones, so why should a
> > BIOS care to allow setting one? WE can do little about that, but
> > i wonder why you can read the serial number of your CPU via DMI,
> > and you can read the temperature of your mainboard, but you
> > can't read the timezone.
>
> > Maybe the BIOS developers are captured in a darf cellar and they
> > don't ever meet reality.
> > </soapbox>
>
> LOL!!! That wouldnae surprise me though...
>
> >> 3. When the ROM BIOS has finished whatever else it has been
> >> told to do, it looks at the various drives, and ends up
> >> loading the kernel image into memory via whatever procedure
> >> the user has selected. It then executes the image so loaded
> >> into memory.
>
> >> It is at THIS stage in the proceedings that we first get an
> >> opportunity to do something, and we already noted that the
> >> RTC has previously been read and assigned to the system time.
>
> > In case you want to look at it: LINUX reads the time from the
> > hardware (=RTC) during boot. That's why the time is set.
>
> Are you sure about this? I understood that it used the relevant ROM
> BIOS call to read the BIOS clock before switching to protected mode,
> and just used the value returned from that.

I only found this on a quick scan:

!
! Read the CMOS clock. Return the seconds in al
!
gettime:
push cx
mov ah,#0x02
int 0x1a
mov al,dh ! dh contains the seconds
and al,#0x0f
mov ah,dh
mov cl,#0x04
shr ah,cl
aad
pop cx
ret

and This will be against your theory:

__initfunc(void time_init(void))
{
xtime.tv_sec = get_cmos_time();
xtime.tv_usec = 0;
...

[...]

> > DST makes things harder: How can you know (after powering the
> > system up) whether the RTC is already time-corrected or not?
>
> There are basically three cases here:
>
> 1. The RTC chip has a register that says whether DST is in use,
> and that register is correctly set and reliable.

If the bit is unchanged by other OSes it could be used. I doubt it.

>
> 2. The RTC chip has a register that says whether DST is in use,
> but that register is not reliably set.
>
> 3. The RTC chip does not have a register that says whether DST
> is in use.
>
> I believe Win9x assumes case (1), as it throws up a warning screen if
> it has shifted the RTC in to or out of DST.

Yes and one version repeatedly changed time back one hour. I agree
that the RTC should be set to UTC, but I'd like to have the correct
time in DOSish systems too.

Regards,
Ulrich


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.455 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site