On Fri, 1 Nov 2024 at 12:36, Chris Adams via arm
<arm@lists.fedoraproject.org> wrote:
>
> Once upon a time, Peter Robinson <pbrobinson@gmail.com> 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@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment