From nobody Sun Nov 07 13:42:15 2021 X-Original-To: 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 E144D18542F9 for ; Sun, 7 Nov 2021 13:42:54 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HnFmt5FK1z4ZrD for ; Sun, 7 Nov 2021 13:42:51 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 1A7DgMEF071105 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Sun, 7 Nov 2021 14:42:24 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1636292545; bh=FhlB+6oss/SGBZsq9HkZviWT2VALkyc8r3o4DFs8Vwg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=sHgnnK1LPm8XHQqbnuMBSTgP3SeUpreuHI3nmGtNaIuwQSLqNrPgkUTqwOZQja2vW l116C9auhyORA6X/3zHzxFYzAcWSSRMKkc4a//zBEArRNE/2BBafzOhA6VyCFX/Glh BE1TmBRvYNDDOjIWeMpJMj3fT3w6rcDxwl/h4L+s= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 1A7DgHeH015315 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 7 Nov 2021 14:42:17 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.16.1/8.16.1) with ESMTP id 1A7DgHhq027555; Sun, 7 Nov 2021 14:42:17 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.16.1/8.16.1/Submit) id 1A7DgFVN027554; Sun, 7 Nov 2021 14:42:15 +0100 (CET) (envelope-from ticso) Date: Sun, 7 Nov 2021 14:42:15 +0100 From: Bernd Walter To: Brian Scott Cc: arm@freebsd.org Subject: Re: DS3231 v. MAX77620 Message-ID: Reply-To: ticso@cicely.de References: 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 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 13.0-RELEASE-p3 amd64 X-Spam-Status: No, score=0.5 required=4.5 tests=BAYES_00=-1.9,KHOP_HELO_FCRDNS=0.398,SPF_HELO_NONE=0.001,SPF_NONE=0.001,URI_TRY_3LD=1.997 autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on spamd.cicely.de X-Rspamd-Queue-Id: 4HnFmt5FK1z4ZrD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Nov 07, 2021 at 12:30:51PM +1100, Brian Scott wrote: > Hi All, > > I just plugged a DS3231 (RTC) into a RPi4 running 13.0 Release. Not > strictly necessary but I had one on my desk and it's a weekend. Added an > appropriate dtb overlay and loaded the ds3231.ko via loader.conf. Done > this a few times before on other boards and not expecting any drama. > > Instead of showing up during boot as a DS3231, it appears to be probed > as a MAX77620 (which fails) and  leaves the real device unavailable to > the ds3231 driver. > > > Nov  5 17:23:00 427269616e-60 kernel: iic0: on iicbus0 > Nov  5 17:23:00 427269616e-60 kernel: rtc0: at addr 0xd0 > on iicbus0 > > Nov  5 17:23:00 427269616e-60 kernel: rtc0: Error when reading reg 0x02, > rv: 35 > Nov  5 17:23:00 427269616e-60 kernel: rtc0: Failed to configure RTC > Nov  5 17:23:00 427269616e-60 kernel: device_attach: rtc0 attach returned 5 This is on a 13.0-RELEASE with a Pi3B: iic0: on iicbus0 rtc0: at addr 0xd0 on iicbus0 ugen1.1: at usbus1 uhub0 on usbus1 uhub0: on usbus1 rtc0: registered as a time-of-day clock, resolution 1.000000s With this overlay: # cat /boot/dtb/overlays/rpi-DS3231.dts /dts-v1/; /plugin/; &i2c1 { status = "okay"; rtc: rtc@68 { compatible = "maxim,ds3231"; reg = <0x68>; }; }; Never consideered it wrong, since it worked and thought the hardware is just compatible. But obviously this is not the ds3231 driver in sys/dev/iicbus. However, I also couldn't get the same DS3231 module running on my Pi4. There is something else going on with the Pi4 beside the driver issue, since the wrong drivers works with the hardware on a Pi3. For me the RTC also was just a nice to have, not a requirement, so I hadn't spend time into debugging it either. > > After some investigation I have found that all I need to provoke these > messages is the dtb overlay loaded. Exactly the same messages are > generated without the ds3231.ko module and even when no physical device > is present. > > Looking at max77620_rtc_probe in > sys/arm64/nvidia/tegra210/max77620_rtc.c shows: > > static int > max77620_rtc_probe(device_t dev) > { > struct iicbus_ivar *dinfo; > dinfo = device_get_ivars(dev); > if (dinfo == NULL) > return (ENXIO); > if (dinfo->addr != MAX77620_RTC_I2C_ADDR << 1) > return (ENXIO); > device_set_desc(dev, "MAX77620 RTC"); > return (BUS_PROBE_DEFAULT); > } > > This device will attempt to attach to anything with address == > MAX77620_RTC_I2C_ADDR (0x68) that is found in the device tree. However, > https://learn.adafruit.com/i2c-addresses/the-list lists: > > 0x68 This address is really popular with real time clocks, almost all of > them use 0x68! AMG8833 IR Thermal Camera Breakout (0x68 or 0x69) DS1307 > RTC (0x68 only) DS3231 RTC (0x68 only) ICM-20649 Accel+Gyro (0x68 or > 0x69) ITG3200 Gyro (0x68 or 0x69) MPU-9250 9-DoF IMU (0x68 or 0x69) > MPU-60X0 Accel+Gyro (0x68 or 0x69) PCF8523 RTC (0x68 only) > > A seven bit device address is clearly not enough to uniquely identify a > type of device and so shouldn't be used like this in the driver. > > Either the driver should use ofw_bus_search_compatible (although I > believe there is no entry for the rtc in the linux device tree) or at > least made conditional on the parent device (the MAX77620) being in the > device tree. > > As I said earlier, this doesn't matter a huge amount for me at this > stage because in my current application time will be configured by ntp. > In the future it will matter more. While it may well be that the target > device cannot be identified any other way, this doesn't belong in GENERIC. > > Thanks for reading, > > Brian Scott > -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.