From nobody Sat Feb 19 05:01:41 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 B98AB19DD180 for ; Sat, 19 Feb 2022 05:02:02 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmse03.mailcluster.com.au (vmse03.mailcluster.com.au [IPv6:2401:fc00:0:14::11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0xHr5yHbz4mHF for ; Sat, 19 Feb 2022 05:02:00 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmcp43.digitalpacific.com.au ([101.0.119.58]) by vmse03.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1nLHsN-0001l0-UE for freebsd-arm@freebsd.org; Sat, 19 Feb 2022 16:01:48 +1100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=57D4nckx8D01msoE9INv52l5emYnQyfYZov3APD+oYk=; b=e6BVje09QDH2X0hrqISOUI0nM4 fRIsd1QKVugUmPgBvtDSXWxlW65KNDZ86gjiUY5tu719Se2nOqOg5SrRPtUdmCM0C3v+j3Imvnxhg 8KtLU3W6PnYnQ+f3qQvCXgNIzN+aQ78go0dZvSWe+5EtT0bJtuOz7JeXc1qmuAxIFZ/AmT9BT98iS uWMTjGwB3stoexooCCQAnqhMGscNgczrbhEIayh1chl35wjE54ZJEg6CnGKnpkxtMWHG5biDDf97q rf67K5mmLr8ueM6IXv5R/g80mVQKkTveILG5D5u/jDa0/xaKdDMRIgzy0XE0y+8ZBv7U70faxi5ND rDuy/irA==; Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:45488 helo=[10.0.1.106]) by vmcp43.digitalpacific.com.au with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nLHsM-00BFxd-EY for freebsd-arm@freebsd.org; Sat, 19 Feb 2022 16:01:42 +1100 Message-ID: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au> Date: Sat, 19 Feb 2022 16:01:41 +1100 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 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: DS3231 RTC module not detected To: freebsd-arm@freebsd.org References: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> From: Brian Scott In-Reply-To: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: bscott@bunyatech.com.au X-Authenticator: dovecot_plain X-Originating-IP: 101.0.119.58 X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au X-SpamExperts-Username: 101.0.119.58 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/aj9iD2d1pqP5BYrP21CA3PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4bk/BERpQBBfwDmwK4QZ5tjABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyjwYONoRaT/P0bWwmOx4gR8p8Gnm YnDDwZLHsvD3pj+LvuKTBmuOVTCmQ/b22sw+yoj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC64 m+k59xMAqz9bfz2u3IufXgzJJmjXk7fyp6dRgNba57y0+NUW6SiQze/aT7qNfwLF4DEPUxAkEvKE S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbuUCVbnFmfwLrtFboZlI4VlsjUqWShwiJykPEul jbtoq1z1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE= X-Report-Abuse-To: spam@vmse01.mailcluster.com.au X-Rspamd-Queue-Id: 4K0xHr5yHbz4mHF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bunyatech.com.au header.s=default header.b=e6BVje09; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:0:14::11 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bunyatech.com.au]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[bunyatech.com.au:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2401:fc00:0:14::11:from] X-ThisMailContainsUnwantedMimeParts: N 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