Re: Version(s) working with BlizzardPPC

[Kulwant B. <kul...@bt...>]

Hello Andi, 

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

Yes, it would appear so. 

>> 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.

Makes sense. 

> 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..

hmmm....

> 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.

I will try both and see what happens. 

Kind Regards, 

Kulwant