Re: Version(s) working with BlizzardPPC

[Andreas <aw...@sw...>]

Hi Kulwant

On Sun, 2003-12-14 at 04:20, Kulwant Bhogal wrote:

> > If it doesn't work yet, you could also rename the hwclockfirst.sh call,
> > although it doesn't seem to write to the clock.
> 
> >      # cd etc/rcS.6/
> >      # mv S18hwclockfirst.sh offS18hwclockfirst.sh
> 
> > But I would heavily advise against it, because then nothing is setting
> > the system clock (system clock != hardware clock), which could lead to
> > strange behaviour of the system.
> 
> Well, I did try that (because all else before that had failed) and I got:

Which means it already crashes when trying to simply READ the clock.

> Loading /etc/console/boottime.kmap.gz
> 
> kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk hwclock/230
> task = c65dc000[230] 'hwclock'

/sbin/hwclock tries to read the time from the RTC. You have to know that
the system clock gets set by the hardware clock during boot, and
afterwards the hardware clock is not going to be probed again (except
during shutdown, when the hwclock.sh script tries to write back the
system time to the hardware clock). The system clock generates it's own
interrupts, so the hardware clock is mainly there to keep the time when
the system is powered off. C.f. man hwclock.

Though in /drivers/char/rtc.c there's a comment mentioning something
about periodic syncs (every 11 min) by time.c (line 54).. So you're
system should at least run for 11 min uninterrupted..

> mm-> pgd c6e2c000 last syscall: 6
> 
> GPR00:   00001072  C65DDE10   C65DC000   00000001   00008000  00000000
> C6E09D80    C980000
> 
> GPR08:  0000000B   00000000   C0180000  C67EC08C   2422
> 
> and then it rebooted before I could write down the rest of it.

I have no clue here. According to
http://lxr.linux.no/diff/drivers/char/rtc.c?a=ppc;diffval=2.4.18;diffvar=v the rtc driver got changed between 2.4.18 and 2.4.19, but no difference between 2.4.19 and 2.4.20. Though there may also be some apus specific changes not documented here. The changes seem to have something to do with sysctl, though I don't know what exactly (sysctl stuff seems to got added to 2.4.19).

What you could also do is to

  # mv /sbin/hwclock /sbin/OFFhwclock

although this is really really ugly!! But it should prevent the system
from interacting with the hardware clock.

Afterwards set the system clock using

  # date 1214200003

(for December 14 (1214), 8 p.m. (2000), 2003 (03)). You'd have to do run
date every time you boot your system.

But this is definitely not how a productive system should be run! So,
try to get the dmesg output anyway and post it.

-- 
Best wishes,
Andi