Subject: Re: Patch: Generic TODR for ARM ports
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Peter Postma <peter@pointless.nl>
List: port-hpcarm
Date: 09/18/2006 13:00:25
On Sun, Sep 17, 2006 at 11:28:47PM +0400, Valeriy E. Ushakov wrote:
> 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:
> > > 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://handhelds.org/moin/moin.cgi/HaRET)
> might be useful in tracking the brightness bug.
> 

Very useful actually, I've used it a while ago. This is what I've discovered:
in hpc_machdep.c, the following line causes the screen to be very bright
when booting windows CE.

memset((void *)KERNEL_BASE, 0, KERNEL_TEXT_BASE - KERNEL_BASE);

With HaRET, I've inspected that memory area and it seems that windows CE
stores the brightness at physical address 0xc0014400 bits 2-3 and the
contrast at physical address 0xc0014400 bits 0-1. I've rebooted a few
times and it seems that it's always this address.

I'm not sure how to "fix" that. My attempts to execute code when rebooting
to write another value to that address have failed so far.
Suggestions are welcome.

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

I'm not sure if they suffer from it.

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

It probably only uses the OS timer, but I'm not sure.

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

-- 
Peter Postma