From owner-freebsd-arm@freebsd.org Thu Jul 18 20:16:59 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CC5DBB05BF for ; Thu, 18 Jul 2019 20:16:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50F25701A5 for ; Thu, 18 Jul 2019 20:16:59 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1563481016; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=uZjsGdga+e7RWuA9oKTy8PFuMe+v0NdXTEvO1BzgyrlI6Mocausuv2NgeEC3oxqrqvawn8KIf82Sj LIQy3LX3fbPhbZH6E/nBD8xVSn7J0Z7D9djMb2as2U5q95jk8y5tLGTFAHf00SRxrIXtybHZ+O7fym hSDKGJE9Mit0OOu74F4Sn+RR7HjZtc6g5lbK8O0JKEwM8aSUpO/RhapjpIXuyAiLRmMB4DAgxgaP5Z Yv7CS2ILpTgvLNhnmxG4AJMH+HrJcRCl9OzDDlffXSobZ9ToI9h/lpEDZTSa0wvFsQUHEuQsxsPCiC 4FIfXbJDc4q0M3nWLXQRTSqWqjQcGaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=4BgCVrMeEq7LpJ4NHdpLaT/AJAjGHgBddqRbCPDtgkQ=; b=D9+3wI8KhdLLbuDDUx9CF4weLZ9N77qbwtgV80pYosm5ixphoHwvcJCjb9Pvn1Vj0J4tzLss8wSLw fsjQ47BUk0AyKo2HvYGUg+mceSIyb5nlERCg6K08MAw9IIaO0v2n0H54ySC5ettlQlPKoo+dpqtEC1 RepqW7lobDyqCeuEmrrncfN0sW8jxpvnMTpXDdXoKscAwqLU1wAEvK7bXq87vU9iHQqhPhQ5f6iCih PVryHHRtQOQY2SEODLOOS0lt43/pQ/4vK4wICrdE8CnhRnQPf+g+OfI+iEPj6qbWN6H5ETxQLF/O6O Q+wkTkEBv94WlXhi2fRmYyr717i/pzw== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=4BgCVrMeEq7LpJ4NHdpLaT/AJAjGHgBddqRbCPDtgkQ=; b=ZPaeT5JozqFPllCiejx7qjxOhZ0easVfzCvERRHAFUUaVC1Mls6/HwFZ5b9gwdTlE6sloV1xxnFH0 VLFGJ1IdIv6oGyweefTCMBaMQD/0OEd606eCS9ggKquZi/k6/GWU2AHbE1AThDmOCNS1tysuqYeCyB Va/brGuzL6Hyov/Ei8+P6XnKKFekAk/1yj4bKa0apSd10f9KDAf+DWid9LiSppRIbF2ODSw7ivwbV+ vDfmfPP6glc3+O9jHh77zXjnAZ9o6HsrkVMyWUC2Sitnm7Tl/Iqj82VC5Efz5yetpU1xQ2BdEl0adW 7L7k9cLfv23o7BpocGjDcBHNyLZj6EQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: fb66fcad-a998-11e9-9a90-0794651146a4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id fb66fcad-a998-11e9-9a90-0794651146a4; Thu, 18 Jul 2019 20:16:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6IKGq5P045771; Thu, 18 Jul 2019 14:16:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Rasclock (PCF2127 ) Hardware Clock FreeBSD 12.0 From: Ian Lepore To: Stefan Parvu , freebsd-arm@freebsd.org Date: Thu, 18 Jul 2019 14:16:52 -0600 In-Reply-To: References: <41A4CA5C-B487-490F-8A19-2D51F43E1004@kronometrix.org> <95616620-bbaf-dbc3-49eb-3e2562638d49@bunyatech.com.au> <74E3E782-8481-4B5B-A0AF-A04590C27D6D@kronometrix.org> <790afcb5f0809a89b45982958a85f1539fec05c7.camel@freebsd.org> <36088812-2135-4433-BC49-0BC433EC6767@kronometrix.org> <86CC4711-47AC-45C6-B6D3-71C9FFDD4A91@kronometrix.org> <2ec7d7f63de31065b9cab396c662fe24f0107078.camel@freebsd.org> <2AC05799-7D11-4200-8D16-38E3718470BB@kronometrix.org> <91E26684-07A0-4F03-92BC-8D49359B1358@kronometrix.org> <5F33E59B-7EA5-4B8B-A95A-CD1FB569ACDC@kronometrix.org> <6a39f74088d2984b5426e8585b5f7e864a6766f8.camel@freebsd.org> <571EABD9-364C-4D91-9177-CC25CB382D76@kronometrix.org> <2dd107308cb7fc21bab793218d8e37039dbc108e.camel@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 50F25701A5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 20:16:59 -0000 On Thu, 2019-07-18 at 23:01 +0300, Stefan Parvu wrote: > Sone differences between our systems > > * Im using Rasclock 4.0, you are in 4.2 > I wouldn't expect that to make any difference, it's a PCF2129[A]T chip in both cases (the difference between the AT and T chips is temperature range). > * Im using RBPI3B+, you are in RBPI2 > > Not sure if these really matter but just in case Im mentioning. > > > > > It occurred to me: are you sure you're using the fixed driver? One of > > the problems before the fix was that a read would succeed, but return > > the wrong values. So the status register reads might be getting a > > wrong value and interpretting that as the "battery failed bit is set”. > > One thing that comes to mind: you're using this as a module, but is > > the nxprtc driver already built in to the kernel? I think if it is and > > you added nxprtc_load=YES to loader.conf, it'll load the module but > > then still use the driver already in the kernel. > > huh. Are you saying the nxprtc driver is already built-in the kernel ? > Why ? Shouldn’t that be just a driver what you can load on demand, > if users need ? > I guess not, on arm64. On armv7 it is in the generic kernel. > Yes, I do have under loader.conf nxprtc_load=“YES”. But still some questions > here: > > * if I do not load the driver under loader.conf, nothing works, I cannot see the > clock or use it anyhow > > * how can I make sure there is NO nxprtc within kernel ? Can I see the routines > function calls somehow, if i kldunlod the nxprtc driver ? > > I do believe Im using the right thing after your commit. I can again double check that > I guess if it only works when you load the driver, that's a good sign it's not in the kernel. You can also do 'kldstat' and if it's in the output, it was loaded and is being used. -- Ian