From nobody Sat Feb 19 11:59:02 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F2DB119D5738 for ; Sat, 19 Feb 2022 11:59:22 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K16YQ0bJxz3vJ0 for ; Sat, 19 Feb 2022 11:59:22 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id x5so19896937edd.11 for ; Sat, 19 Feb 2022 03:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fxxE1cKO/kFyzkZgiuV8hyKAjBsm2d+d79+QAlBJ83A=; b=PtfJ4fZ+6Pcm+AroDqjSHpdSNRoCSf0RbBOmbLr+oUDUtpqLaQ93b7WQ00IGIuB6Wl i/eoQBMGxFraMgNfUXAhv0vyxj4/woNFDolwQexiZvP26MBLg9q0bo4HSQMOqHY/z2ir WS42QGt7qBKWZD77OrEkHNQu18FNSgYAmX9mJQGvdT4v9F3KaTGJnTACGzz8Hf6RtDa4 RdJP+upVir28heSVxsiJ/ZKuL3oRtpA6IGAYVmyRP+2Tbr6KEUwBOGCwwj/fdvbQ47j5 52n0B+9E76CERVkuk5B0+uFrgGSz0aebBRJ+K7scGcLjrcFKCNN/Ssv1VfIHBfGqT5yZ 5uqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fxxE1cKO/kFyzkZgiuV8hyKAjBsm2d+d79+QAlBJ83A=; b=qaaGw+z7WmNytYNL39oWIb9qhQldhawUvKKFx8QvlqTXmsJpEAJorVFixkWiKZd1wg Is0mtfBHR+DMhvnwYDJZ3T3aPpqTESEsL47VnvduN/He56raJUXeAmyjOsc0B8DmVqO5 uOcX/AW7IND0rNlHpctTVwDBI4Pu/8BPG5XL7wdvl2M97miLP97AHvf+314dQzA5C6vX ZWcRkHcfF4yVJ9s9jdZ0whZQdGNzTiR4/rpCC9Uh7gmH0JkKQWmlTBFG6vWf+Gg7nViS ee72xBEZi9Z+mwDaokroJs5gd1NNzbuvjs9kO4dKPiKTWOzK7UyP95HbLAfRbY6amqgZ aEOA== X-Gm-Message-State: AOAM5330SiwUgufD5qM6Jc8LDOgKnMhdPJVHekxor7e987hlMBHYPGTC selpFLR4lKuYmhNZfU2nXcgngGx+wU0YQ/p3FWEK3OVeK8s= X-Google-Smtp-Source: ABdhPJygmpk45Tv6W0q+EJBfyNTN3vS1CbGtjATBZ89nwCO1aPY/4yYmjCXgRKIYAO8xoqyhRjROUmlj40YeKekzWrI= X-Received: by 2002:a50:c056:0:b0:40f:9c6d:7701 with SMTP id u22-20020a50c056000000b0040f9c6d7701mr12354557edd.110.1645271960129; Sat, 19 Feb 2022 03:59:20 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au> In-Reply-To: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au> From: Archimedes Gaviola Date: Sat, 19 Feb 2022 19:59:02 +0800 Message-ID: Subject: Re: DS3231 RTC module not detected To: Brian Scott Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000be136e05d85dba10" X-Rspamd-Queue-Id: 4K16YQ0bJxz3vJ0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PtfJ4fZ+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.995]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.68:email]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.68:email]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000be136e05d85dba10 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 19, 2022 at 1:02 PM 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: on iicbus0 > > rtc0: 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: 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


=
On Sat, Feb 19, 2022 at 1:02 PM Brian= Scott <bscott@bunyatech.com.= au> wrote:
archimedes.gaviola@gmail.c= om> wrote:
>> 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:
> 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 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.
> 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 r= ight 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 t= he power is removed (I believe it gets flushed out on a clean shutdown thou= gh). Perhaps that is the problem?
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>=C2=A0 =C2=A0-- 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC
ident=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC-P= I
nooptions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 effec= t
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 alrea= dy detects the module. This is with 13.0-RELEASE.

<= div>root@fbsd13:~ # kldload ds3231
ds32310: <Maxim DS3231 RTC&= gt; at addr 0xd0 on iicbus0
ds32310: registered as a time-of-day clock, = resolution 1.000000s

freebsd@fbsd13:~ % sysctl= -a | grep ds3231
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value: =C2=A0/boot/kernel/= ds3231.ko
dev.ds3231.0.32khz_enable: 1
dev.ds3231.0.sqw_mode: interru= pt
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: ii= cbus0
dev.ds3231.0.%pnpinfo: name=3Dds3231@68 compat=3Dmaxim,ds3231
d= ev.ds3231.0.%location: addr=3D0xd0
dev.ds3231.0.%driver: ds3231
dev.d= s3231.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 apprecia= ted.

Thanks,
Archimedes
--000000000000be136e05d85dba10--