Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2019 13:46:17 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        James Shuriff <james@opentech.cc>
Cc:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: rpi3 clock drift
Message-ID:  <fa6236f5196a6d65b8e08c2178b95bfd95cb8515.camel@freebsd.org>
In-Reply-To: <MWHPR06MB3134E3913675771F14E3C4B3AA460@MWHPR06MB3134.namprd06.prod.outlook.com>
References:  <alpine.BSF.2.21.99999.352.1911271039470.281@autopsy.pc.athabascau.ca> <MWHPR06MB3134EC22EC3148DA800B2B7DAA440@MWHPR06MB3134.namprd06.prod.outlook.com> <alpine.BSF.2.21.99999.352.1911272214050.28592@autopsy.pc.athabascau.ca> <20191129052800.GA37113@server.rulingia.com> <alpine.BSF.2.21.99999.352.1911282333250.90234@autopsy.pc.athabascau.ca> <65be6d3628a8d35084f7c98266582090f59b18be.camel@freebsd.org> <alpine.BSF.2.21.99999.352.1911291053140.17959@autopsy.pc.athabascau.ca> <MWHPR06MB313445553D73F019FEEAF50EAA460@MWHPR06MB3134.namprd06.prod.outlook.com> <731a9e57ba62d5a6ede74fdde3fd82543484813b.camel@freebsd.org> <MWHPR06MB3134455800AD75C949D86D8FAA460@MWHPR06MB3134.namprd06.prod.outlook.com> <MWHPR06MB3134E3913675771F14E3C4B3AA460@MWHPR06MB3134.namprd06.prod.outlook.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2019-11-29 at 20:37 +0000, James Shuriff wrote:
> I dumped the FDT from the system I built from source and I cannot
> find any reference to 0x337F980 (54 MHz). I looked at the FreeBSD
> source file generic_timer.c and it looks like it's grabbing the
> frequency from FDT but I cannot figure out where it's getting the 54
> MHz from. clk_osc in the FDT is still showing 0x124f800 (19.2 MHz) on
> the system with the bad clock.
> 
> - James Shuriff
> 

Well, it tries to find a property named clock-frequency, but if that's
not found, it silently falls back to calling get_freq() which does
get_el0(cntfrq), which I guess must read it from a timer hardware
register.  I have no idea how that value gets into the hardware
register; maybe uboot sets it up.  (I don't do much with arm64, I'm
mostly an armv7 person.)

If you're building your dtb from source, you could add a clock-
frequency property, but it's not clear to me which node the property
goes on.  Soc?  One of the cpus?  Does the timer have its own node? 
I'm not sure.

-- Ian


> -----Original Message-----
> From: James Shuriff
> Sent: Friday, November 29, 2019 1:36 PM
> To: 'Ian Lepore' <ian@freebsd.org>
> Cc: Ross Alexander <rwa@athabascau.ca>; freebsd-arm@freebsd.org
> Subject: RE: rpi3 clock drift
> 
> Thanks! I pulled the FDT from the Raspberry Pi running FreeBSD's RPI3
> image (with the clock functioning). I think I found it on clock@3:
> 
> clocks {
> 
> compatible = "simple-bus";
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> clock@3 {
> 
> compatible = "fixed-clock";
> reg = <0x3>;
> #clock-cells = <0x0>;
> clock-output-names = "osc";
> clock-frequency = <0x124f800>;
> phandle = <0x4>;
> };
> clock@4 {
> 
> compatible = "fixed-clock";
> reg = <0x4>;
> #clock-cells = <0x0>;
> clock-output-names = "otg";
> clock-frequency = <0x1c9c3800>;
> phandle = <0x18>;
> };
> };
> 
> clock@3 is clk_osc and clock@4 is clk_usb. I believe this is coming
> from bcm2710-rpi-3-b.dtb on the FAT partition, as I decompiled it and
> found the same clock defs. However the clock defs are the same in the
> file that's on my busted system.
> 
> - James Shuriff
> 
> -----Original Message-----
> From: Ian Lepore <ian@freebsd.org>
> Sent: Friday, November 29, 2019 1:16 PM
> To: James Shuriff <james@opentech.cc>; Ross Alexander <
> rwa@athabascau.ca>; freebsd-arm@freebsd.org
> Subject: Re: rpi3 clock drift
> 
> On Fri, 2019-11-29 at 18:06 +0000, James Shuriff wrote:
> > Can you help me determine where the timecounter frequency is being
> > pulled from? I believe that 54 MHz value is being pulled from the
> > FDT
> > I just don't know where specifically. My board is supposed to be
> > 19.2
> > MHz. I booted up FreeBSD's own RPI3 image and I got 19.2 MHz and
> > didn't have any drift issues. Only when I use the environment I
> > built
> > from source do I get 54 MHz, as if an RPI 4 DTB somehow made it
> > into
> > the build.
> > 
> 
> You can get a definitive look at the fdt data in use by decompiling
> it on the running system, like this:
> 
>   sysctl -b hw.fdt.dtb | dtc -I dtb -O dts >/tmp/active.dts
> 
> That would help you confirm your theory by finding which node has the
> 54mhz value in it.  What to do beyond that, I'm not sure.  RPi fdt
> data always confuses me.  I think these days it's loaded from the
> msdos partition by uboot, but I'm not sure of that.
> 
> > I'm also interested in getting an RTC hat. I know how to build
> > support
> > for it in the bootloader and OS but how do you tell FreeBSD to
> > start
> > using it for system timing once it's connected?
> > 
> > - James Shuriff
> > 
> 
> The only thing an RTC does is initially set the system time once at
> boot.  (On systems that support suspend/resume, it also resets the
> kernel clock on resume from sleep/low-power modes.)  There is no way
> to use an RTC as the system timecounter.
> 
> To use an RTC to set the time intially at boot, you only need to load
> its driver via the loader.conf setting and enable the i2c device with
> an fdt overlay.  The device driver registers itself as an RTC, and
> the kernel automatically sets the time from the registered RTC that
> has the best resolution.
> 
> -- Ian
> 
> ________________________________
>  DISCLAIMER: This message and any attachments are intended solely for
> the use of the recipient and may contain confidential information. If
> you have received this message in error please delete it and promptly
> notify the sender, James Shuriff (james@opentech.cc<mailto:
> james@opentech.cc>).
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org
> "




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fa6236f5196a6d65b8e08c2178b95bfd95cb8515.camel>