From nobody Sat Feb 19 12:19:25 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 49D8719D85D6 for ; Sat, 19 Feb 2022 12:19:45 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 4K170w3zPrz4Qpj for ; Sat, 19 Feb 2022 12:19:44 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ej1-x634.google.com with SMTP id hw13so21119593ejc.9 for ; Sat, 19 Feb 2022 04:19:44 -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=dqS5ELeAFd9VmJoGq89TIlH6k7zukrW2mRFD4BYXeVM=; b=cIizrFRVMRhLRrPyAYYycJu9qJISdBbuGdypEJFAoTFAiSUDlVcjryHVJ2iwGas0EI GJa541HxWATJjxEKNNFWfcGV/7aVQiVk5/srWG1neME18EOuZWuL2tCyi/cmB8TSydGK Y1DgGv2zDlNho8ELol+OR97y7BZXrPlSRCtSMrq0WJbEKgZprZJzjpRLgZx1LS0TA1tG WiW+7xHG07+JzuIItlMegdCyPCrpNsoEpLUt5Xh0cr05kjuHf9qC+EM7kWkEUNe/Q3vX 40A1qg8Io8RibpDcXmqIIiDKdJkJ28jat+bzO6/yyXjpycmBEeGoGauSUukDFUIraBzE Tk4A== 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=dqS5ELeAFd9VmJoGq89TIlH6k7zukrW2mRFD4BYXeVM=; b=CQl2PP85X27ZPJL/uhaILES0OCL0F+gafeutIJ56MUBIsRk1Rhs12m0Ya6xcSTlUQe Ril1Uymg7Xe7M9wC+iuwUCAL7DGi54S60gRANQdx9L0a2cOeFsW9YPpp/AMGxYV7mZfG jI44HOH6yTJ6SmhRSP3NzXR8Jbp59XjhmeypkRlFTHkxjsjf2dFi0qMuecoACCauTbKv OcaLdRAbXVMuPccStl21hhP65HDkTUFg5CxmtmzTKmILVfZTT/RKJh4ucepd0fib+kUz EwyfokwUd2rJT5wLnYUgkrFIJc4KDc80oYMJh0z+DS3wStfbbGdwAyx7Q9b321Heb1KF ow/Q== X-Gm-Message-State: AOAM531TSZJHQvPbWlbmoV2oeIuNNVJORbVTCUt1Jl0EhAcu4FlmdYnK l62jYfx+K5qnxiEKe3utiCZAM0X6YUbKyML1MValhpEF X-Google-Smtp-Source: ABdhPJyRf5+5j6MPvKKZmE3lX5+xVPEdUFuME5WVCJuSyS4FuO6hzNSTbGhHH7TRxg5w/a9bjhwALHQlJbnm2UsceOs= X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id b17-20020a1709063cb100b006ce2a975ademr9695466ejh.728.1645273183465; Sat, 19 Feb 2022 04:19:43 -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> In-Reply-To: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> From: Archimedes Gaviola Date: Sat, 19 Feb 2022 20:19:25 +0800 Message-ID: Subject: Re: DS3231 RTC module not detected To: "Daniel O'Connor" Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a8b40205d85e03ff" X-Rspamd-Queue-Id: 4K170w3zPrz4Qpj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cIizrFRV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; 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(-1.00)[-1.000]; 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)[]; 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)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000a8b40205d85e03ff Content-Type: text/plain; charset="UTF-8" On Sat, Feb 19, 2022 at 6: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? > Thanks for your feedback Daniel! With the exact DS3231 driver all the concerns I've mentioned were answered. Once it is set manually via date or ntpdate, the clock will now continue even if your system is shutdown (with unplug power cable) or even detaching the module from the RPi4 system for some time and then attaching it back will now be "real-time". You can bring your DS1307 with the exact driver as well. Thanks a lot for your help, it is well appreciated. Archimedes --000000000000a8b40205d85e03ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 19, 2022 at 6:52 AM Danie= l O'Connor <darius@dons.net.au= > 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 creati= ng a ds3231.dtso file and then compiling it with dtc to generate a ds3231.d= tbo. 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 whi= ch is doing well without any issue. Now, the moment I shutdown the system a= nd 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 shu= tdown or detached from power due to the battery that will sustain the conti= nuity 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 Open= BSD too. Below are the system info. Is there anything I've missed? Free= BSD 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 1= 00% sure it was advancing correctly - I didn't take a precise note of w= hen 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 secon= ds)

Which suggests to me that the clock could be up to 30 minutes off if the po= wer is removed (I believe it gets flushed out on a clean shutdown though). = Perhaps that is the problem?

Thanks for your= feedback Daniel! With the exact DS3231 driver all the concerns I've me= ntioned were answered. Once it is set manually via date or ntpdate, the clo= ck will now continue even if your system is shutdown (with unplug power cab= le) or even detaching the module from the RPi4 system for some time and the= n attaching it back will now be "real-time".

You can bring your DS1307 = with the exact driver as well. Thanks a lot for your help, it is well appre= ciated.
=C2=A0
Archimedes
--000000000000a8b40205d85e03ff--