Date: Sat, 19 Feb 2022 19:59:02 +0800 From: Archimedes Gaviola <archimedes.gaviola@gmail.com> To: Brian Scott <bscott@bunyatech.com.au> Cc: freebsd-arm@freebsd.org Subject: Re: DS3231 RTC module not detected Message-ID: <CAJFbk7EzJ7ekLvHEEiGx3q_tvEJyXti1ZO6uKJJ81f7=JTiy7Q@mail.gmail.com> 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
--000000000000be136e05d85dba10
Content-Type: text/plain; charset="UTF-8"
On Sat, Feb 19, 2022 at 1:02 PM Brian Scott <bscott@bunyatech.com.au> 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.
>
Okay, that explains. After re-compiling the kernel my system now already
detects the module. This is with 13.0-RELEASE.
root@fbsd13:~ # kldload ds3231
ds32310: <Maxim DS3231 RTC> at addr 0xd0 on iicbus0
ds32310: registered as a time-of-day clock, resolution 1.000000s
freebsd@fbsd13:~ % sysctl -a | grep ds3231
value: /boot/kernel/ds3231.ko
dev.ds3231.0.32khz_enable: 1
dev.ds3231.0.sqw_mode: interrupt
dev.ds3231.0.sqw_freq: 8192
dev.ds3231.0.bbsqw: 0
dev.ds3231.0.temp_conv: 0
dev.ds3231.0.temperature: 39.1C
dev.ds3231.0.%parent: iicbus0
dev.ds3231.0.%pnpinfo: name=ds3231@68 compat=maxim,ds3231
dev.ds3231.0.%location: addr=0xd0
dev.ds3231.0.%driver: ds3231
dev.ds3231.0.%desc: Maxim DS3231 RTC
dev.ds3231.%parent:
I'm on my way with 14.0-CURRENT kernel recompilation.
Thanks a lot Brian for sharing the info and resolution! It is well
appreciated.
Thanks,
Archimedes
--000000000000be136e05d85dba10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 19, 2022 at 1:02 PM Brian=
Scott <<a href=3D"mailto:bscott@bunyatech.com.au">bscott@bunyatech.com.=
au</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On 19/2/22 9:52 am, Daniel O'Connor wrote:<br>
><br>
>> On 19 Feb 2022, at 00:52, Archimedes Gaviola <<a href=3D"mailto=
:archimedes.gaviola@gmail.com" target=3D"_blank">archimedes.gaviola@gmail.c=
om</a>> wrote:<br>
>> Thanks for the info! I followed similar with your DS1307 RTC by cr=
eating a ds3231.dtso file and then compiling it with dtc to generate a ds32=
31.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address but w=
hen I run an i2c scan, the address detected is 68. Does this should match?<=
br>
> Mine was detected similarly:<br>
> iic0: <I2C generic I/O> on iicbus0<br>
> rtc0: <MAX77620 RTC> at addr 0xd0 on iicbus0<br>
> usbus0: 5.0Gbps Super Speed USB v3.0<br>
> rtc0: registered as a time-of-day clock, resolution 1.000000s<br>
><br>
> I am not sure why it shows up like that but it does seem to work.<br>
><br>
>> 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 syst=
em 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 rem=
ains as it was before shutting down and then upon bootup system clock conti=
nues. 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 c=
ontinuity of the clock. I'm sure that I'm having good DS3231 module=
s 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.<br>
> 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..<br>
><br>
> Unfortunately it's not physically with me so I can't test it r=
ight now.<br>
><br>
> I do note this sysctl:<br>
> machdep.rtc_save_period: Save system time to RTC with this period (in =
seconds)<br>
><br>
> Which suggests to me that the clock could be up to 30 minutes off if t=
he power is removed (I believe it gets flushed out on a clean shutdown thou=
gh). Perhaps that is the problem?<br>
><br>
> --<br>
> Daniel O'Connor<br>
> "The nice thing about standards is that there<br>
> are so many of them to choose from."<br>
>=C2=A0 =C2=A0-- Andrew Tanenbaum<br>
><br>
><br>
Hi people,<br>
<br>
I had the same problem a few months ago.<br>
<br>
The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to <br>
unilaterally claim anything at address 68. It doesn't understand the <b=
r>
DS3231 and fails to operate properly, but in claiming the device, the <br>
ds3231 driver doesn't get a chance. This is compounded by the MAX77620 =
<br>
driver being compiled into the kernel by default so the loadable module <br=
>
doesn't get to try until after the wrong driver has claimed it.<br>
<br>
The only answer at present is to build a custom kernel without the <br>
unwanted driver. My kernel config is:<br>
<br>
include=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC<br>
ident=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC-P=
I<br>
nooptions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SOC_NVIDIA_TEGRA210<br>
<br>
Ideally, the TEGRA210 code would be fixed or removed from the GENERIC <br>
kernel but that doesn't seem to have happened despite the adverse effec=
t <br>
on the many clock devices that live at address 68 and will already be in <b=
r>
use.<br>
<br>
I dislike building a custom kernel because everything else I do strives <br=
>
to use precompiled binaries whenever possible.<br></blockquote></div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">
<div>Okay, that explains. After re-compiling the kernel my system now alrea=
dy detects the module. This is with 13.0-RELEASE.<br></div><div><br></div><=
div>root@fbsd13:~ # kldload ds3231</div><div>ds32310: <Maxim DS3231 RTC&=
gt; at addr 0xd0 on iicbus0<br>ds32310: registered as a time-of-day clock, =
resolution 1.000000s<br></div><div><br></div><div>freebsd@fbsd13:~ % sysctl=
-a | grep ds3231<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 value: =C2=A0/boot/kernel/=
ds3231.ko<br>dev.ds3231.0.32khz_enable: 1<br>dev.ds3231.0.sqw_mode: interru=
pt<br>dev.ds3231.0.sqw_freq: 8192<br>dev.ds3231.0.bbsqw: 0<br>dev.ds3231.0.=
temp_conv: 0<br>dev.ds3231.0.temperature: 39.1C<br>dev.ds3231.0.%parent: ii=
cbus0<br>dev.ds3231.0.%pnpinfo: name=3Dds3231@68 compat=3Dmaxim,ds3231<br>d=
ev.ds3231.0.%location: addr=3D0xd0<br>dev.ds3231.0.%driver: ds3231<br>dev.d=
s3231.0.%desc: Maxim DS3231 RTC<br>dev.ds3231.%parent:</div><div><br></div>=
<div>
I'm on my way with 14.0-CURRENT kernel recompilation.
</div><div><br></div><div>
Thanks a lot Brian for sharing the info and resolution! It is well apprecia=
ted.<br></div><div><br></div><div>Thanks,</div><div>Archimedes<br>
</div>
</div></div>
--000000000000be136e05d85dba10--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJFbk7EzJ7ekLvHEEiGx3q_tvEJyXti1ZO6uKJJ81f7=JTiy7Q>