Date: Mon, 23 Jul 2018 08:51:40 -0700 From: Michael Mitchell <mmitchel@gmail.com> To: Ralph Smith <ralph@ralphsmith.org> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi3 and Adafruit GPS Hat Message-ID: <23DA127A-B954-44A8-8BA3-4D4F1E0D11A2@gmail.com> In-Reply-To: <002D469F-26E0-492A-BEB7-8A61A56ECABF@ralphsmith.org> References: <47f49a55-66b0-1c02-4530-4701a3bd0c43@nethead.se> <20180718170157.GA40221@night.db.net> <ba31ee27-1d17-8616-96b2-b982268f0dc2@nethead.se> <CAFnjQbt395y4xyHEp52GAHW9X9bHvdCAT9q-gKA2--RvQvqTtA@mail.gmail.com> <7a14173c-cc28-6dc7-3787-a5b77a396b30@nethead.se> <1532357176.1344.130.camel@freebsd.org> <fa3a6cb6-d73e-1b7f-e470-e9c88e3ea6ee@nethead.se> <1532359478.1344.142.camel@freebsd.org> <002D469F-26E0-492A-BEB7-8A61A56ECABF@ralphsmith.org>
next in thread | previous in thread | raw e-mail | index | archive | help
hi all: maybe this would be the supported u-boot method to give up the serial output messages during startup: https://github.com/u-boot/u-boot/blob/master/doc/README.silent = <https://github.com/u-boot/u-boot/blob/master/doc/README.silent>; just a thought mdm > On Jul 23, 2018, at 8:37 AM, Ralph Smith <ralph@ralphsmith.org> wrote: >=20 >=20 >=20 > Sent from my iPhone >=20 >> On Jul 23, 2018, at 11:24 AM, Ian Lepore <ian@freebsd.org> wrote: >>=20 >>> On Mon, 2018-07-23 at 17:20 +0200, Per olof Ljungmark wrote: >>>> On 07/23/18 16:46, Ian Lepore wrote: >>>>=20 >>>>> On Mon, 2018-07-23 at 11:40 +0200, Per olof Ljungmark wrote: >>>>>=20 >>>>>> On 07/23/18 10:46, David Cornejo wrote: >>>>>>=20 >>>>>>=20 >>>>>> this might be a little blasphemous, but for grins I tried an = Oncore with >>>>>> PPS to a GPIO and running the serial through a TTL-USB serial = cable and >>>>>> that seems to work ok. >>>>>>=20 >>>>>> there's probably some good reason that this is a bad idea. >>>>> Depends on what precision you are after, but for lowest possible = jitter >>>>> you need to use the uart, the difference is in magnitudes. >>>>>=20 >>>> Technically that may be correct, but it's meaningless. On a usb 1.x >>>> adapter there may be ~500us of jitter from one measurement to the = next. >>>> On a usb 2.x adapter the jitter drops to typically ~60us. Those = values >>>> are pretty much in the noise for ntpd, which uses a median filter = to >>>> smooth any serious jitter out of the measurements. >>>>=20 >>>> Here are some real-world measurements. The pps source for all 3 = inputs >>>> is the same gps-disciplined rubidium oscillator, so all the jitter = is >>>> within the uart, usb hardware, and freebsd drivers. The usb = adapters >>>> are both FTDI chips, which have a fixed latency on reporting a = change >>>> on the DCD pin (pin-change status messages are only delivered once = a >>>> millisecond on ftdi chips). >>>>=20 >>>> remote refid st t when poll reach delay offset = jitter >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> xPPS(0) .uart. 0 l 6 16 377 0.000 1.097 = 0.001 >>>> xPPS(1) .usb1. 0 l 4 16 377 0.000 -0.051 = 0.773 >>>> oPPS(2) .usb2. 0 l 4 16 377 0.000 -0.001 = 0.035 >>>> *dvb.hippie.lan .GPS. 1 u 12 64 377 1.234 1.296 = 2.707 >>>> +utcnist2.colora .NIST. 1 u 1 64 377 13.605 3.940 = 2.729 >>>>=20 >>>> You can see in this case ntpd actually chose the usb2 pps input as = the >>>> system peer. It did so because at startup the clock offset was = closer >>>> than the uart, and the difference in jitter between the two wasn't >>>> significant, so the ntpd code that prevents clock-hopping chose to >>>> stick with the peer with the smaller offset. >>>>=20 >>> Yes, I was technically correct but of course you are right too - >>> however, the main problem is not the jitter but rather that I am = unable >>> to switch off the serial console and stop the u-boot loader from >>> receiving NMEA data. The Adafruit GPS Hat is made to sit right on = the Pi >>> 40-pin header, as you probably know. >>>=20 >>> To quote one of the posters in the thread I linked to: >>> "... I am seriously baffled by how difficult (nearly impossible) it = had >>> been to get rid of the serial console..." >>>=20 >>> Unfortunately I am not fluid enough to figure out where to make the >>> changes, the advices I've seen so far is not applicable to = 12-CURRENT in >>> an easy way. >>>=20 >>> And that is also why I wrote bugreport 229976. It may be that all = the >>> folks involved with FreeBSD/ARM are serious developers so they do = not >>> see it as a problem but for me it is, being more on the >>> application/administration side of things. >>>=20 >>> Thanks, >>>=20 >>> //per >>>=20 >>=20 >> Unfortunately, I can't help with the rpi part of this, since it's >> related to the firmware and uboot, and that part of the rpi world has >> changed drastically since I was involved with it years ago. I know = you >> can build a custom uboot that disables serial console support >> completely, but I don't know if there's a way to achieve that with = the >> stock uboot. >=20 > Not using the stock uboot, you will need to modify it. I have this = working on 12-CURRENT for the Pi 2, I haven=E2=80=99t tried it on the Pi = 3. I documented how I modified u-boot for 11-STABLE in = https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D188164+0+archive/2018/free= bsd-arm/20180204.freebsd-arm, this should apply to the current u-boot = port as well. You will also meet to modify the DTB so the system = doesn=E2=80=99t send console output to the uart as well.=20 >=20 > Ralph > _______________________________________________ > 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?23DA127A-B954-44A8-8BA3-4D4F1E0D11A2>