Re: DS3231 RTC module not detected

On 19/2/22 9:52 am, Daniel O'Connor wrote:
>
>> On 19 Feb 2022, at 00:52, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
>> Thanks for the info! I followed similar with your DS1307 RTC by creating a ds3231.dtso file and then compiling it with dtc to generate a ds3231.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address but when I run an i2c scan, the address detected is 68. Does this should match?
> Mine was detected similarly:
> iic0: <I2C generic I/O> on iicbus0
> rtc0: <MAX77620 RTC> at addr 0xd0 on iicbus0
> usbus0: 5.0Gbps Super Speed USB v3.0
> rtc0: registered as a time-of-day clock, resolution 1.000000s
>
> I am not sure why it shows up like that but it does seem to work.
>
>> With this setup I could update the date and time now by initiating an ntpdate to match our time plus invoking tzsetup command for my timezone which is doing well without any issue. Now, the moment I shutdown the system and plug back the power cable (with disconnected Ethernet cable just to make sure NTP servers are not called for updates upon restart) the time remains as it was before shutting down and then upon bootup system clock continues. I am expecting that it should be real time even if the RPi4 system is shutdown or detached from power due to the battery that will sustain the continuity of the clock. I'm sure that I'm having good DS3231 modules as I also tested my existing and another new spare and it is tested with OpenBSD too. Below are the system info. Is there anything I've missed? FreeBSD 13.0-RELEASE have the same outcome and behavior.
> That is strange, I tested powering mine off and it kept time but I am not 100% sure it was advancing correctly - I didn't take a precise note of when I powered it off etc..
>
> Unfortunately it's not physically with me so I can't test it right now.
>
> I do note this sysctl:
> machdep.rtc_save_period: Save system time to RTC with this period (in seconds)
>
> Which suggests to me that the clock could be up to 30 minutes off if the power is removed (I believe it gets flushed out on a clean shutdown though). Perhaps that is the problem?
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>   -- Andrew Tanenbaum
>
>
Hi people,

I had the same problem a few months ago.

The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to 
unilaterally claim anything at address 68. It doesn't understand the 
DS3231 and fails to operate properly, but in claiming the device, the 
ds3231 driver doesn't get a chance. This is compounded by the MAX77620 
driver being compiled into the kernel by default so the loadable module 
doesn't get to try until after the wrong driver has claimed it.

The only answer at present is to build a custom kernel without the 
unwanted driver. My kernel config is:

include         GENERIC
ident           GENERIC-PI
nooptions       SOC_NVIDIA_TEGRA210

Ideally, the TEGRA210 code would be fixed or removed from the GENERIC 
kernel but that doesn't seem to have happened despite the adverse effect 
on the many clock devices that live at address 68 and will already be in 
use.

I dislike building a custom kernel because everything else I do strives 
to use precompiled binaries whenever possible.

Cheers,


Brian