I'm trying to use Fedora 28 Minimal on a Raspberry Pi 3 to set up an NTP server using a GPS hat, specifically intended for this purpose:
https://www.tindie.com/products/nsayer/skytraq-venus838lpx-t-timing-gps-modu... (That link initially shows the non-Raspberry Pi version; click the second photo for the Pi version.)
Booting Fedora from the MicroSD fails, apparently due to U-Boot thinking that the UART has "pressed a key" to abort the boot. I get a U-Boot prompt, followed by lots of garbage (presumably due to baud rate mismatch).
Is there any easy way to get U-Boot to not listen to the UART?
I've tried this with 32-bit and 64-bit Fedora 28 on a Pi 3B and a Pi 3B+, with the same results. Without hte GPS hat it boots fine.
Thanks!
Best regards, Eric
On Mon, Jul 23, 2018 at 4:44 AM, Eric Smith spacewar@gmail.com wrote:
I'm trying to use Fedora 28 Minimal on a Raspberry Pi 3 to set up an NTP server using a GPS hat, specifically intended for this purpose:
https://www.tindie.com/products/nsayer/skytraq-venus838lpx-t-timing-gps-modu... (That link initially shows the non-Raspberry Pi version; click the second photo for the Pi version.)
Booting Fedora from the MicroSD fails, apparently due to U-Boot thinking that the UART has "pressed a key" to abort the boot. I get a U-Boot prompt,
From the prompt you should be able to types "boot" and it should continue to boot.
followed by lots of garbage (presumably due to baud rate mismatch).
Or the GPS already sending NMEA data.
Is there any easy way to get U-Boot to not listen to the UART?
Off hand I'm not sure, there was a patch set that did auto enable based on the what the firmware reported.
I've tried this with 32-bit and 64-bit Fedora 28 on a Pi 3B and a Pi 3B+, with the same results. Without hte GPS hat it boots fine.
Yes, so it seems like the GPS is probably trying to send data which is in turn interrupting the boot process.
On Mon, Jul 23, 2018 at 2:50 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jul 23, 2018 at 4:44 AM, Eric Smith spacewar@gmail.com wrote:
I'm trying to use Fedora 28 Minimal on a Raspberry Pi 3 to set up an NTP server using a GPS hat, specifically intended for this purpose:
Yes, so it seems like the GPS is probably trying to send data which is in turn interrupting the boot process.
I had the same problem (except I was using the Adafruit version), and my only solution at the time was to switch back to Raspbian. The GPS starts sending data over the UART as soon as it is powered up so there's really no chance for the user to do anything. Barring some sort of hardware/software changes on the GPS HAT that would prevent it from sending data over the UART until it got a signal from the Pi I think that U-Boot will need to be changed so that it ignores the UART.
On Mon, Jul 23, 2018 at 9:43 AM, Jeffrey Ollie jeff@ocjtech.us wrote:
I had the same problem (except I was using the Adafruit version), and my only solution at the time was to switch back to Raspbian.
Yes, mine works fine with Raspbian also. I just don't much like using Debian-based distributions because I have been using Red Hat and Fedora since 1995.
[OT] It probably makes no difference in practice for a typical NTP server, but the Geppetto board is based on a GPS chip with firmware optimized for a fixed location time reference. After it does an initial site survey it assumes that it doesn't move, and purportedly can offer better performance on the PPS output.
On Mon, Jul 23, 2018 at 1:50 AM, Peter Robinson pbrobinson@gmail.com wrote:
From the prompt you should be able to types "boot" and it should continue to boot.
There won't normally be a keyboard on the machine, and I need it to recover from power failures.
followed by lots of garbage (presumably due to baud rate mismatch).
Or the GPS already sending NMEA data.
It's sending NMEA data, but U-Boot sees it as garbage, presumably due to baud rate mismatch.
Is there any easy way to get U-Boot to not listen to the UART?
Off hand I'm not sure, there was a patch set that did auto enable based on the what the firmware reported.
I was hoping that there was a configuration option that could be set somewhere (maybe in a text file in the boot partition) to tell U-Boot not to open the serial port at all.
From the prompt you should be able to types "boot" and it should continue to boot.
There won't normally be a keyboard on the machine, and I need it to recover from power failures.
Sure, my point is that there's a means to make it continue.
followed by lots of garbage (presumably due to baud rate mismatch).
Or the GPS already sending NMEA data.
It's sending NMEA data, but U-Boot sees it as garbage, presumably due to baud rate mismatch.
The speed mismatch is irrelevant here, U-Boot is looking for some input IE press any key and it'll interrupt boot, it could be valid NMEA data at the right speed and it'll do the same.
Is there any easy way to get U-Boot to not listen to the UART?
Off hand I'm not sure, there was a patch set that did auto enable based on the what the firmware reported.
I was hoping that there was a configuration option that could be set somewhere (maybe in a text file in the boot partition) to tell U-Boot not to open the serial port at all.
Not that I'm aware of off hand, although it's not a feature I've been asked about so I could have missed it. A quick grep through the upstream U-Boot logs and I get [1], you might want to email the u-boot list to see if it could be tweaked. I, with my Raspberry Pi on Fedora maintainers hat on, don't have the time to chase this at the moment but would be happy to assist where I can and of course will accept patches. i work on the RPi in Fedora in my own time and it already takes up a significant amount of the little spare time I have.
Peter
[1] http://git.denx.de/?p=u-boot.git;a=commit;h=55b8a2ddaae407c8e9b4afe5cf33f848...
-
Eric Smith -
Jeffrey Ollie -
Peter Robinson