Date: Sun, 20 Feb 2022 12:42:47 +0100 From: Michal Meloun <meloun.michal@gmail.com> To: Brian Scott <bscott@bunyatech.com.au>, freebsd-arm@freebsd.org Subject: Re: DS3231 RTC module not detected Message-ID: <cc3f4ec5-1a41-b034-180b-9a07d963706f@freebsd.org> In-Reply-To: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au> References: <CAJFbk7EtkjnFBJgr-L3faxaQ2saNgEQ%2BLRPWbRySpwY8wJRh=Q@mail.gmail.com> <F2EFEDCC-1E00-4221-8AF9-3744A7AC359C@dons.net.au> <CAJFbk7Ed2R8M2xAkJQAjiivZie=8Ca_Rt50YEG4P3yWzQLQhrg@mail.gmail.com> <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cc3f4ec5-1a41-b034-180b-9a07d963706f>