rpi3 and Adafruit GPS Hat

[Michael Mitchell]

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 at ralphsmith.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 23, 2018, at 11:24 AM, Ian Lepore <ian at freebsd.org> wrote:
>> 
>>> On Mon, 2018-07-23 at 17:20 +0200, Per olof Ljungmark wrote:
>>>> On 07/23/18 16:46, Ian Lepore wrote:
>>>> 
>>>>> On Mon, 2018-07-23 at 11:40 +0200, Per olof Ljungmark wrote:
>>>>> 
>>>>>> On 07/23/18 10:46, David Cornejo wrote:
>>>>>> 
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>> 
>>>> 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.
>>>> 
>>>> 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).
>>>> 
>>>>     remote      refid   st t when poll reach   delay   offset  jitter
>>>> ======================================================================
>>>> 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
>>>> 
>>>> 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.
>>>> 
>>> 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.
>>> 
>>> 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..."
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Thanks,
>>> 
>>> //per
>>> 
>> 
>> 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.
> 
> Not using the stock uboot, you will need to modify it. I have this working on 12-CURRENT for the Pi 2, I haven’t 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=188164+0+archive/2018/freebsd-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’t send console output to the uart as well. 
> 
> Ralph
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"