Re: DS3231 RTC module not detected

On 19.02.2022 6:01, Brian Scott wrote:
> 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
> 
>

Thanks for report,
it should be fixed in a534b50e245d

Michal