Patch: Generic TODR for ARM ports

I've created a patch which converts the remaining ARM ports
over to
generic todr.  (evbarm and hpcarm). 

As part of this code, I removed the conditional check in
common ARM code
for this conversion -- since this converts the remaining
ports, it is
reasonable to unidef the code.

I do not have any ARM equipment.  However the change was
largely
"mechanical", and it should be safe.  I've test
compiled all the hpcarm
kernels, and I'm compiling most of the evbarm kernels as I
write this. 
I don't expect any problems.

I'd appreciate it if folks could review and test these
changes, and if
the relevant port-masters or responsible parties can
indicate to me when
it is safe to commit the changes.

The patch itself is located at
ftp://ftp.NetBSD.org/pub/NetBSD/misc/gdamore/arm-todr.diff

Enjoy!

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecom
puter.com/
Phone: 951 325-2134  Fax: 951 325-2191

On Sat, Sep 16, 2006 at 10:09:17PM -0700, Garrett D'Amore
wrote:
> I've created a patch which converts the remaining ARM
ports over to
> generic todr.  (evbarm and hpcarm). 
> 
> As part of this code, I removed the conditional check
in common ARM code
> for this conversion -- since this converts the
remaining ports, it is
> reasonable to unidef the code.
> 
> I do not have any ARM equipment.  However the change
was largely
> "mechanical", and it should be safe.  I've
test compiled all the hpcarm
> kernels, and I'm compiling most of the evbarm kernels
as I write this. 
> I don't expect any problems.
> 
> I'd appreciate it if folks could review and test these
changes, and if
> the relevant port-masters or responsible parties can
indicate to me when
> it is safe to commit the changes.
> 
> The patch itself is located at
>
ftp://ftp.NetBSD.org/pub/NetBSD/misc/gdamore/arm-todr.diff
> 
> Enjoy!
> 

Thanks for doing this. The hpcarm changes look and work
fine, but the
following 3 messages are shown when booting, and when coming
out suspend
mode:

WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!

I can add an RTC driver, but I'm not sure how useful that
would be, the
RTC value is invalid at boot-time and the jornada doesn't
do real suspend
so we won't need it for that.

Anyway, I've converted hpcarm to use timecounters and they
seem to work fine:

timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "clockinterrupt"
frequency 100 Hz quality 0
timecounter: selected timecounter
"clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "saost_count" frequency
3686400 Hz quality 100
timecounter: selected timecounter "saost_count"
frequency 3686400 Hz quality 100
timecounter: selected timecounter "saost_count"
frequency 3686400 Hz quality 100

./timetest -v -v -c -t 120 -A
Will test active counter and counters with positive quality
from saost_count(q=1
00, f=3686400 Hz) clockinterrupt(q=0, f=100 Hz)
dummy(q=-1000000, f=1000000 Hz)
Testing time for monotonicity of timecounter
"saost_count" for 120 seconds...
000121
claimed resolution 271 nsec (3690036.900369 Hz) or better,
observed observed minimum non zero delta 9222 nsec
switching to timecounter "clockinterrupt"...
Testing time for monotonicity of timecounter
"clockinterrupt" for 120 seconds...
000121
claimed resolution 10000000 nsec (100.000000 Hz) or better,
observed minimum non zero delta 9999999 nsec
TEST SUCCESSFUL

I can put the diffs online for review, but they are really
trivial.

-- 
Peter Postma

On Sun, Sep 17, 2006 at 16:46:32 +0200, Peter Postma wrote:

> I can add an RTC driver, but I'm not sure how useful
that would be,
> the RTC value is invalid at boot-time

hpcboot passes current time to the kernel as part of
bootinfo.  It
will be off by several seconds by the time the kernel
starts, but
that's still better than fs time.

BTW, why is RTC time invalid?

SY, Uwe
-- 
uweptc.spbu.ru                         |       Zu Grunde
kommen
http://snark.ptc.spbu.
ru/~uwe/          |       Ist zu Grunde gehen

On Sun, Sep 17, 2006 at 08:05:13PM +0400, Valeriy E. Ushakov
wrote:
> On Sun, Sep 17, 2006 at 16:46:32 +0200, Peter Postma
wrote:
> 
> > I can add an RTC driver, but I'm not sure how
useful that would be,
> > the RTC value is invalid at boot-time
> 
> hpcboot passes current time to the kernel as part of
bootinfo.  It
> will be off by several seconds by the time the kernel
starts, but
> that's still better than fs time.
> 

Ok, but that will probably not help because netbsd is
usually booted from
factory defaults (because of the screen brightness bug), so
the clock is
then at 2000-01-01.

> BTW, why is RTC time invalid?
> 

The value is the uptime in seconds, even when the date is
changed in
windows CE. So it seems that windows CE doesn't use it at
all...

-- 
Peter Postma

On Sun, Sep 17, 2006 at 19:34:16 +0200, Peter Postma wrote:

> On Sun, Sep 17, 2006 at 08:05:13PM +0400, Valeriy E.
Ushakov wrote:
> > On Sun, Sep 17, 2006 at 16:46:32 +0200, Peter
Postma wrote:
> > 
> > > I can add an RTC driver, but I'm not sure
how useful that would be,
> > > the RTC value is invalid at boot-time
> > 
> > hpcboot passes current time to the kernel as part
of bootinfo.  It
> > will be off by several seconds by the time the
kernel starts, but
> > that's still better than fs time.
> > 
> 
> Ok, but that will probably not help because netbsd is
usually booted from
> factory defaults (because of the screen brightness
bug), so the clock is
> then at 2000-01-01.

Ah, and kloader is not supported either.

BTW, I wonder if HaRET (http://handh
elds.org/moin/moin.cgi/HaRET)
might be useful in tracking the brightness bug.

Does linux suffer from it?  Linux on 720 status page at
http:
//handhelds.org/moin/moin.cgi/HpJornada720 says that
brightness
and contrast setting work.


> > BTW, why is RTC time invalid?
> 
> The value is the uptime in seconds, even when the date
is changed in
> windows CE. So it seems that windows CE doesn't use it
at all...

Could it be that they use some other clock, e.g. in a
companion chip?

Consulting Linux sources might be useful.  In the worst case
there's
always objdump --disassemble-all 

SY, Uwe
-- 
uweptc.spbu.ru                         |       Zu Grunde
kommen
http://snark.ptc.spbu.
ru/~uwe/          |       Ist zu Grunde gehen

Garrett D'Amore wrote:
> I've created a patch which converts the remaining ARM
ports over to
> generic todr.  (evbarm and hpcarm). 
> 
> As part of this code, I removed the conditional check
in common ARM code
> for this conversion -- since this converts the
remaining ports, it is
> reasonable to unidef the code.
> 
> I do not have any ARM equipment.  However the change
was largely
> "mechanical", and it should be safe.  I've
test compiled all the hpcarm
> kernels, and I'm compiling most of the evbarm kernels
as I write this. 
> I don't expect any problems.
> 
> I'd appreciate it if folks could review and test these
changes, and if
> the relevant port-masters or responsible parties can
indicate to me when
> it is safe to commit the changes.
...

I used this patch to teach me how to convert a new evbarm
board (the 
code for which will be submitted for review Real Soon Now),
and it works 
fine.  Here's my questions on the patch...

sys/arch/evbarm/ifpga/pl030_rtc.c: plrtc_attach() does not
call 
todr_attach()?

sys/arch/arm/footbridge/isa/dsrtc.c: dsrtc_write() and
dsrtc_read() 
continue to return 1 for success, which the generic TODR
code will treat 
as an error return?

It's a nice improvement, thanks.

--
TAllan