Rasclock (PCF2127 ) Hardware Clock FreeBSD 12.0

[Ian Lepore]

On Thu, 2019-07-18 at 23:01 +0300, Stefan Parvu wrote:
> Sone differences between our systems
> 
>  * Im using Rasclock 4.0, you are in 4.2 
> 

I wouldn't expect that to make any difference, it's a PCF2129[A]T chip
in both cases (the difference between the AT and T chips is temperature
range).

>  * Im using RBPI3B+, you are in RBPI2
> 
> Not sure if these really matter but just in case Im mentioning.
> 
> > 
> > It occurred to me: are you sure you're using the fixed driver?  One of
> > the problems before the fix was that a read would succeed, but return
> > the wrong values.  So the status register reads might be getting a
> > wrong value and interpretting that as the "battery failed bit is set”.
> > One thing that comes to mind:  you're using this as a module, but is
> > the nxprtc driver already built in to the kernel?  I think if it is and
> > you added nxprtc_load=YES to loader.conf, it'll load the module but
> > then still use the driver already in the kernel.
> 
> huh. Are you saying the nxprtc driver is already built-in the kernel ? 
> Why ? Shouldn’t that be just a driver what you can load on demand,
> if users need ?
> 

I guess not, on arm64.  On armv7 it is in the generic kernel.

> Yes, I do have under loader.conf nxprtc_load=“YES”. But still some questions 
> here:
> 
> * if I do not load the driver under loader.conf, nothing works, I cannot see the
> clock or use it anyhow 
> 
> * how can I make sure there is NO nxprtc within kernel ? Can I see the routines
> function calls somehow, if i kldunlod the nxprtc driver ?
> 
> I do believe Im using the right thing after your commit. I can again double check that
> 

I guess if it only works when you load the driver, that's a good sign
it's not in the kernel.  You can also do 'kldstat' and if it's in the
output, it was loaded and is being used.

-- Ian