On Fri, 1 Nov 2024 at 12:36, Chris Adams via arm <arm@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Once upon a time, Peter Robinson <pbrobinson@xxxxxxxxx> said: > > > I have a couple of Raspberry Pi 4Bs with a couple of different GPS HATs. > > > Both GPS HATs work similar - they use the main serial port pins to > > > transmit the NMEA sentences, several every second once they have GPS > > > sync. Since u-boot stops on serial input, this keeps them from booting > > > unattended. > > > > This a problem we've sadly had for ever [1], and it's been discussed > > upstream in U-Boot too (I have tagged messages in my inbox somewhere). > > There's not yet a good solution, although I was thinking about it the > > other day. > > Heh, nice. I got back looking at it with the release of Fedora 41 > (trying to test all my broken issues to close or update :) ). I'm on > the BZ, but dug some more to see if I was missing something. > > > > With a fresh Fedora 41 install, I see u-boot start and then get the EFI > > > boot menu, which stops until I hit ENTER when the GPS HAT is attached. > > > > > > I tried setting bootdelay to -2 but that seems to stop the EFI boot menu > > > from autobooting no matter what (e.g. pulled the HAT off and it still > > > stopped there). > > > > Why -2? That might be something worth looking into separately. > > Trying things, https://docs.u-boot.org/en/latest/usage/environment.html > says that -2 is "autoboot with no delay and not check for abort". But > it looks like maybe the EFI menu doesn't apply the values the same way? > It is a bit interesting that it always seems to get to the EFI menu now, > not abort at the u-boot prompt (like it used to). Although IIRC having > the EFI menu is relatively new? It's actually a generic menu but adds efi pieces for boot stuff, we enabled it for F-40 as it makes it much easier for people to do things like boot off a USB stick for reinstall etc. > Is there any way to edit the EFI variables to change the menu timeout > (including maybe a similar "don't check for abort" value), or does it > always use the bootdelay setting? I don't think so. > > > I also changed stdin/stdout/stderr to remove serial, that didn't seem to > > > have any effect. > > > > No, it doesn't, U-boot very much wants a serial console, there has > > been a little improvement upstream here though which should be in > > 2025.01 (I think). > > Okay, will keep a watch out. > > > > I assume people don't have these problems with the "official" Raspberry > > > Pi OS - do they build u-boot with different options from Fedora that > > > allow fully disabling the u-boot serial console mode? > > > > They don't use U-Boot, they boot directly from the VC firmware to the > > kernel using ancient interfaces. > > Oh, okay. That explains things. > > With one GPS HAT, I have a systemd unit that as the last thing on > shutdown will send a warm reset command to the GPS module, which takes > long enough to start sending NMEA sentences again that the boot process > has run. > > But that's the one that I haven't been able to run a kernel past 6.6, > because something causes it to hard reset and stop at u-boot about 20-30 > seconds after boot, possibly when the GPS starts sending PPS on GPIO? > That one does use a non-default GPIO pin (4, default for pps-gpio > overlay is 18). Can you clarify this? The "stop at u-boot about 20-30 seconds after boot" doesn't make sense, you should be well into the kernel and even login after 20-30 seconds, well past U-Boot. Also not sure how PPS on a gpio would affect early boot. Peter -- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
