From nobody Sun Feb 20 11:42:47 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 DD1EA19D2D5B for ; Sun, 20 Feb 2022 11:42:49 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4K1k7s00hwz4jP8 for ; Sun, 20 Feb 2022 11:42:49 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id u18so23722540edt.6 for ; Sun, 20 Feb 2022 03:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:date:mime-version:user-agent:reply-to :subject:content-language:to:references:in-reply-to :content-transfer-encoding; bh=mdiBaoRzR/zD0rSDak2DcOink6r1vYsC1lYH5qAMHdg=; b=n1A+jmn+iODb1Yxg2tVcHfKQF3w7g6NCSZXjoRUsCpZpwR5RP2iCOHm3v0uTSyfVPj GVmu4hpFLBM5HSffkcCWCMqr1uNTGSaZ894/RJsQARHJWVTbtCjAqKr8dzUTuP5nBMnF iCVDM2qXpp0GAH0PTp5tZXPCR4fQDGR+q/f+SMeI1hkq3D1Cr8aAwe9/J3gISY8qORZP Rwku+KXc04yWwgWowpd+uBqxeQ7vjamV/zFhwCQuDO7bywDQEm9uCcVNsKiYULKJ83BG Bj+KMMJ89JyNaQyjYAup5nTUSQVa+Pg7PBe1YBIRTRLJ2JMYig1f52gL4KduOHvVYHat cHCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:date:mime-version :user-agent:reply-to:subject:content-language:to:references :in-reply-to:content-transfer-encoding; bh=mdiBaoRzR/zD0rSDak2DcOink6r1vYsC1lYH5qAMHdg=; b=toOlFcs5uhFJAy+4dDIBeq45EKdCksFxMATi7h3o64yZokMXLT5kZkWWcT0IiKpacd LBgPjXFqtTNfjDhSyYb19nPIxCirGyKuNIduFgT+TDKKTxiBYX7Xv3294eZSZXbA7Rmv Yvr7BWoGGmoxaZYrK3vMKVKcQwpE+XgnSr7QUiZCurn/H9WSTSvpxhzf0Jz8g5+sKTz7 +yW6tI9tG+UyawMpXGe5o7TiwssmA/LLsQPfWKzRFfxvwsc02kBXbKVbT4PJ6iRyNzLN g1MqQuMOi6aiXOPHD6D9J0R0ci7KsrAXnTcgmIThcwwRa4ZgcrJkvlSt2j2hsLz1uGzs 3MtQ== X-Gm-Message-State: AOAM530kD7YWcph7b9lZ7zXM2AeqbKClcHQBu42tNFe6UhINdrAVsWj+ jrINPoSqW/MVcmHrk9/FCWbn3UOGcBE= X-Google-Smtp-Source: ABdhPJz6HDuuCl4pQldaN6mEOgymn02cu8YgiF+Kzn8zWylaPC7NYrZ+zNEug9kTXlJ6s5r6QGNBzA== X-Received: by 2002:a05:6402:42ca:b0:408:ed7:b011 with SMTP id i10-20020a05640242ca00b004080ed7b011mr16190527edc.6.1645357367840; Sun, 20 Feb 2022 03:42:47 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id m25sm4144011ejl.38.2022.02.20.03.42.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Feb 2022 03:42:47 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Message-ID: Date: Sun, 20 Feb 2022 12:42:47 +0100 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 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Reply-To: mmel@freebsd.org Subject: Re: DS3231 RTC module not detected Content-Language: en-US To: Brian Scott , freebsd-arm@freebsd.org 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K1k7s00hwz4jP8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=n1A+jmn+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-0.87 / 15.00]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; NEURAL_HAM_LONG(-0.98)[-0.978]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.11)[0.114]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 >>> 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. > > Cheers, > > > Brian > > Thanks for report, it should be fixed in a534b50e245d Michal