RTC or OS date/time problem?

RTC or OS date/time problem?

Post by mclacso » Thu, 09 Dec 2004 12:09:46


We have a VME system with three (3) Motorola VME162 CPU. The OS of this
system was just recently upgraded to OS-9/68K V3.0.3 from OS-9/68K V2.4
since the system was not on active online operation for a few years.
Our problem now is everytime the system is rebooted, or reset or
"setime -s" command is issued, the system date - specifically the year
will revert back to 19xx meaning if the current date is set to December
8, 2004 then after a reboot or "setime -s" the system date will become
December 8, 1904. Though you can set the date back to the correct date
using setime then you have to do it after each system reboot/reset.
The problem is common to the three CPUs.
Is this a RTC (bad battery) or OS (v3.0.3 is supposed to be Y2K
compliant?) problem? Your opinion is highly appreciated.
 
 
 

RTC or OS date/time problem?

Post by Jeff Skeb » Thu, 09 Dec 2004 22:33:51


> We have a VME system with three (3) Motorola VME162 CPU. The OS of this
> system was just recently upgraded to OS-9/68K V3.0.3 from OS-9/68K V2.4
> since the system was not on active online operation for a few years.
> Our problem now is everytime the system is rebooted, or reset or
> "setime -s" command is issued, the system date - specifically the year
> will revert back to 19xx meaning if the current date is set to December
> 8, 2004 then after a reboot or "setime -s" the system date will become
> December 8, 1904. Though you can set the date back to the correct date
> using setime then you have to do it after each system reboot/reset.
> The problem is common to the three CPUs.
> Is this a RTC (bad battery) or OS (v3.0.3 is supposed to be Y2K
> compliant?) problem? Your opinion is highly appreciated.


This doesn't sound like a bad battery problem or else
the time-of-day info would be lost. I believe the RTC
chip on the MVME162 can only store two BCD digits (00-99)
and that the century information must be surmised by
software. The pre-Y2K version of rtclock added '1900'
to whatever two digits were stored in the 48T08 to yield
a maximum year of 1999. The Y2K version of rtclock
assumed a start of 1970 and so should be good until
the year 2069.

The fact that your year is reverting to 1904 sounds like
the old version of rtclock is perhaps being used. Are
you using at least Ed #4 of rtclock? Ed #3 of rtclock
was used until V3.0.2 (pre-Y2K). The rtclock module
(filename is rtc162) should look something like the
following for OS-9 V3.0.3 or later

Header for: rtclock
Module size: $1E4 #484
Owner: 0.0
Module CRC: $6F3BE1 Good CRC
Header parity: $126E Good parity
Edition: $4 #4
Ty/La At/Rev $201 $A000
Permission: $555 -----e-r-e-r-e-r
Exec off: $3C #60
Data size: $0 #0
68000 Sub Mod, Object Code, Sharable, System State Process

- JeffS

 
 
 

RTC or OS date/time problem?

Post by Jeff Skeb » Thu, 09 Dec 2004 22:56:14


Another possibility which just sprang to mind is that
perhaps you have Ed #4 of rtclock in your 'OS9Boot'
file on disk but also have Ed #3 of rtclock in ROM
which is being found first when the kernel starts.
So be sure to check with 'ident -m rtclock'. To avoid
the effort of reburning your EPROM you could always
bump the 'revision' number of the Ed #4 rtclock module
in OS9Boot (using fixmod) so that it takes precedence
over the ROM'd one.
 
 
 

RTC or OS date/time problem?

Post by mclacso » Fri, 10 Dec 2004 17:28:50

I did the "ident -m rtclock" and it looks like that we have the Edition
#3 rtclock in our system. The terminal output listed below:

$ ident -m rtclock
Header for: rtclock
Module size: $1D8 #472
Owner: 0.0
Module CRC: $59BE78 Good CRC
Header parity: $1241 Good parity
Edition: $3 #3
Ty/La At/Rev $201 $A000
Permission: $555 -----e-r-e-r-e-r
Sub Mod, 68000 obj, Sharable, System State Process
Now, how to correct this deficiency?
 
 
 

RTC or OS date/time problem?

Post by Jeff Skeb » Fri, 10 Dec 2004 22:41:54


> I did the "ident -m rtclock" and it looks like that we have the Edition
> #3 rtclock in our system. The terminal output listed below:
>
> $ ident -m rtclock
> Header for: rtclock
> Module size: $1D8 #472
> Owner: 0.0
> Module CRC: $59BE78 Good CRC
> Header parity: $1241 Good parity
> Edition: $3 #3
> Ty/La At/Rev $201 $A000
> Permission: $555 -----e-r-e-r-e-r
> Sub Mod, 68000 obj, Sharable, System State Process
> Now, how to correct this deficiency?
>

I guess the question then is "how did the old rtclock"
module Edition #3 get into your system?" The rtc162
file supplied with V3.0.3 OS-9 MVME162 BSP should have
been rtclock Ed #4.

1) Check to ensure that you have the V3.0.3 Ed #4
rtc162 file on your disk. I believe that file
should have been supplied in the following
directory...

/h0/MWOS/OS9/68040/PORTS/MVME162/CMDS/BOOTOBJS

2) If so, was a new 'OS9Boot' generated which made use of
all the new V3.0.3 system modules, including rtclock?
Check to determine which edition is being loaded from
OS9Boot by executing the following...

$ ident -q /h0/OS9Boot !grep rtclock

3) If the above indicates that OS9Boot contains rtclock
Ed #3, then you will need to generate a new OS9Boot.
If, however, OS9Boot does contain rtclock Ed #4, it may
be that either rtclock Ed #3 exists in ROM/EPROM/NVRAM
or else the OS9Boot file on your disk is not actually
linked correctly and some other sectors are being read
in lieu of OS9Boot. Find the file descriptor sector
for /h0/OS9Boot by executing...

$ dir -e /h0/os9boot

and check to ensure that the sector number displayed
matches the sector number stored at the three-byte
DD_BT field (System bootstrap LSN at offset 0x15) in
the disk's Identification Sector.

$ dump /h0@

The 3 bytes beginning at offset 0x15 in the above dump
should exactly match the sector number for OS9Boot
given in the above dir. If not, you will need to
generate a new OS9Boot using the os9gen utility.

If the 3 bytes do match, than it is probable that the
Ed #3 rtclock is present in ROM/EPROM/NVRAM. In this
case you will need to increment the revision number of
rtclock on your disk. I believe the syntax would be
something like...

$ chd /h0/MWOS/OS9/68040/PORTS/MVME162/CMDS/BOOTOBJS
$ copy rtc162 rtc162.orig
$ fixmod -ua=a001 rtc162

in order to give the rtclock module (in file rtc162) a
higher revision number than its original 'At/Rev' of
$A000. You will then need to generate a new OS9Boot
using the os9gen utility.

The above is from memory and may not be 100% accurate
but check with the OS-9 manual to be sure.

- JeffS