On 10/25/24 02:58, ToddAndMargo via xfce wrote:
> On 10/24/24 22:41, Ian Laurie via xfce wrote:
>>>>>> Fedora 40
>>>>>> xfce 4.18
>>>>>>
>>>>>> I cannot start xfce from lightdm. It tried, give me
>>>>>> a bunch of errors about xinit: unable to connect to
>>>>>> x server
>>>>>>
>>>>>> But xfce starts fine from the command lien with startx
>>>>>>
>>>>>> ??????????
Cancel the request. It is an issue with lightdm. I replace
it with lxdm and problems solved.
I am stuck in the "endless loop" problem that is plaguing
lightdm users. I have searched my ass off an everyone
with the issue can not find a cure.
So I disabled lightdm and installed lxdm. It ain't as pretty
BUT IT WORKS!!!!
I even have autologin configured. And it lets me
switch back and forth between Xfce and MATE.
My keeper on lxdm:
lxdm auto login:
# vi /etc/lxdm/lxdm.conf
[base]
## uncomment and set autologin username to enable autologin
# autologin=todd
autologin=todd
## default session or desktop used when no systemwide config
# session=/usr/bin/startlxde
session=/usr/bin/startxfce4
-T
--
_______________________________________________
xfce mailing list -- xfce@lists.fedoraproject.org
To unsubscribe send an email to xfce-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/xfce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Info
Friday, November 1, 2024
[fedora-arm] Re: Disabling serial console in u-boot
Once upon a time, Peter Robinson <pbrobinson@gmail.com> said:
> Oh yes, I remember that one now.
Heh I do find the weird problems.
> > I need to swap out the SD card for a clean Fedora 41 server image and
> > see if it still happens (I expect it will since kernel 6.11 on F39 still
> > does). I was kind of hoping I could reproduce it with the other GPS
> > HAT, but it doesn't happen there. That's when I thought about the
> > difference between the two being which GPIO PIN the PPS signal is on
> > (think I had it backwards before - the one that crashes has PPS on the
> > default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
> >
> > It doesn't make much sense for the GPIO PPS signal to be the issue (even
> > when the overlay configuring PPS isn't loaded), but... not sure what
> > else it might be. The only other difference between the two HATs is
> > that the one on the crashing Pi has an integrated RTC, while the other
> > one does not.
>
> What's the integrated RTC? Does it have an integrated watchdog
> feature? I wonder if the kernel driver had a update to enable a
> watchdog or some similar feature on the RTC and it's triggering a
> reset because something isn't clearing it as the HW is expecting.
The RTC is an rv3028. The GPS HAT is the Uputronics GPS/RTC board.
I do normally have the watchdog service running, configured for
/dev/watchdog (habit on headless servers which is how I'm using this).
I only see /dev/watchdog0, which is the Pi's BCM2835 watchdog.
The reboot does also happen with a default config.txt, which means the
RTC and PPC aren't configured and recognized by the kernel.
I'll start with a plain clean F41 server image on a different card, hook
up a monitor, start from a cold boot, and see what I can see.
Thanks for your help. I've used Linux on non-x86 type hardware, but not
in a long time, and not like ARM until more recently, so still a
learning curve for me.
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
> Oh yes, I remember that one now.
Heh I do find the weird problems.
> > I need to swap out the SD card for a clean Fedora 41 server image and
> > see if it still happens (I expect it will since kernel 6.11 on F39 still
> > does). I was kind of hoping I could reproduce it with the other GPS
> > HAT, but it doesn't happen there. That's when I thought about the
> > difference between the two being which GPIO PIN the PPS signal is on
> > (think I had it backwards before - the one that crashes has PPS on the
> > default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
> >
> > It doesn't make much sense for the GPIO PPS signal to be the issue (even
> > when the overlay configuring PPS isn't loaded), but... not sure what
> > else it might be. The only other difference between the two HATs is
> > that the one on the crashing Pi has an integrated RTC, while the other
> > one does not.
>
> What's the integrated RTC? Does it have an integrated watchdog
> feature? I wonder if the kernel driver had a update to enable a
> watchdog or some similar feature on the RTC and it's triggering a
> reset because something isn't clearing it as the HW is expecting.
The RTC is an rv3028. The GPS HAT is the Uputronics GPS/RTC board.
I do normally have the watchdog service running, configured for
/dev/watchdog (habit on headless servers which is how I'm using this).
I only see /dev/watchdog0, which is the Pi's BCM2835 watchdog.
The reboot does also happen with a default config.txt, which means the
RTC and PPC aren't configured and recognized by the kernel.
I'll start with a plain clean F41 server image on a different card, hook
up a monitor, start from a cold boot, and see what I can see.
Thanks for your help. I've used Linux on non-x86 type hardware, but not
in a long time, and not like ARM until more recently, so still a
learning curve for me.
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
[fedora-arm] Re: Disabling serial console in u-boot
On Fri, 1 Nov 2024 at 17:36, Chris Adams via arm
<arm@lists.fedoraproject.org> wrote:
>
> Once upon a time, Peter Robinson <pbrobinson@gmail.com> said:
> > 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.
>
> Oh it boots fine, then crashes after about 20-30 seconds back to a
> u-boot prompt. IIRC when I hooked up a monitor, I didn't see any kernel
> oops, just back to u-boot.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2264560
>
> It's very weird, and I'm just speculating that the 20-30 seconds is
> about how long it takes for the GPS HAT to start sending PPS pulses.
Oh yes, I remember that one now.
> I need to swap out the SD card for a clean Fedora 41 server image and
> see if it still happens (I expect it will since kernel 6.11 on F39 still
> does). I was kind of hoping I could reproduce it with the other GPS
> HAT, but it doesn't happen there. That's when I thought about the
> difference between the two being which GPIO PIN the PPS signal is on
> (think I had it backwards before - the one that crashes has PPS on the
> default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
>
> It doesn't make much sense for the GPIO PPS signal to be the issue (even
> when the overlay configuring PPS isn't loaded), but... not sure what
> else it might be. The only other difference between the two HATs is
> that the one on the crashing Pi has an integrated RTC, while the other
> one does not.
What's the integrated RTC? Does it have an integrated watchdog
feature? I wonder if the kernel driver had a update to enable a
watchdog or some similar feature on the RTC and it's triggering a
reset because something isn't clearing it as the HW is expecting.
--
_______________________________________________
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
<arm@lists.fedoraproject.org> wrote:
>
> Once upon a time, Peter Robinson <pbrobinson@gmail.com> said:
> > 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.
>
> Oh it boots fine, then crashes after about 20-30 seconds back to a
> u-boot prompt. IIRC when I hooked up a monitor, I didn't see any kernel
> oops, just back to u-boot.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2264560
>
> It's very weird, and I'm just speculating that the 20-30 seconds is
> about how long it takes for the GPS HAT to start sending PPS pulses.
Oh yes, I remember that one now.
> I need to swap out the SD card for a clean Fedora 41 server image and
> see if it still happens (I expect it will since kernel 6.11 on F39 still
> does). I was kind of hoping I could reproduce it with the other GPS
> HAT, but it doesn't happen there. That's when I thought about the
> difference between the two being which GPIO PIN the PPS signal is on
> (think I had it backwards before - the one that crashes has PPS on the
> default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
>
> It doesn't make much sense for the GPIO PPS signal to be the issue (even
> when the overlay configuring PPS isn't loaded), but... not sure what
> else it might be. The only other difference between the two HATs is
> that the one on the crashing Pi has an integrated RTC, while the other
> one does not.
What's the integrated RTC? Does it have an integrated watchdog
feature? I wonder if the kernel driver had a update to enable a
watchdog or some similar feature on the RTC and it's triggering a
reset because something isn't clearing it as the HW is expecting.
--
_______________________________________________
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
[fedora-arm] Re: Disabling serial console in u-boot
Once upon a time, Peter Robinson <pbrobinson@gmail.com> said:
> 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.
Oh it boots fine, then crashes after about 20-30 seconds back to a
u-boot prompt. IIRC when I hooked up a monitor, I didn't see any kernel
oops, just back to u-boot.
https://bugzilla.redhat.com/show_bug.cgi?id=2264560
It's very weird, and I'm just speculating that the 20-30 seconds is
about how long it takes for the GPS HAT to start sending PPS pulses.
I need to swap out the SD card for a clean Fedora 41 server image and
see if it still happens (I expect it will since kernel 6.11 on F39 still
does). I was kind of hoping I could reproduce it with the other GPS
HAT, but it doesn't happen there. That's when I thought about the
difference between the two being which GPIO PIN the PPS signal is on
(think I had it backwards before - the one that crashes has PPS on the
default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
It doesn't make much sense for the GPIO PPS signal to be the issue (even
when the overlay configuring PPS isn't loaded), but... not sure what
else it might be. The only other difference between the two HATs is
that the one on the crashing Pi has an integrated RTC, while the other
one does not.
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
> 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.
Oh it boots fine, then crashes after about 20-30 seconds back to a
u-boot prompt. IIRC when I hooked up a monitor, I didn't see any kernel
oops, just back to u-boot.
https://bugzilla.redhat.com/show_bug.cgi?id=2264560
It's very weird, and I'm just speculating that the 20-30 seconds is
about how long it takes for the GPS HAT to start sending PPS pulses.
I need to swap out the SD card for a clean Fedora 41 server image and
see if it still happens (I expect it will since kernel 6.11 on F39 still
does). I was kind of hoping I could reproduce it with the other GPS
HAT, but it doesn't happen there. That's when I thought about the
difference between the two being which GPIO PIN the PPS signal is on
(think I had it backwards before - the one that crashes has PPS on the
default pin, 18, while the one that doesn't has PPS on GPIO pin 4).
It doesn't make much sense for the GPIO PPS signal to be the issue (even
when the overlay configuring PPS isn't loaded), but... not sure what
else it might be. The only other difference between the two HATs is
that the one on the crashing Pi has an integrated RTC, while the other
one does not.
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
[389-users] Re: [EXT] Re: Using modifyTimeStamp in queries
Thanks! Which index should I put on modifyTimestamp?
Tim Darby
From: William Brown via 389-users <389-users@lists.fedoraproject.org>
Sent: Thursday, October 31, 2024 16:52
To: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
Cc: Darby, Tim - (tdarby) <tdarby@arizona.edu>; William Brown <wbrown@suse.de>
Subject: [EXT] [389-users] Re: Using modifyTimeStamp in queries
Sent: Thursday, October 31, 2024 16:52
To: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
Cc: Darby, Tim - (tdarby) <tdarby@arizona.edu>; William Brown <wbrown@suse.de>
Subject: [EXT] [389-users] Re: Using modifyTimeStamp in queries
External Email
On 1 Nov 2024, at 08:51, tdarby--- via 389-users <389-users@lists.fedoraproject.org> wrote:
We have an application that needs to query for and return thousands of entries with modifyTimeStamp greater than a given time. This is turning out to be too slow for this app and so I'm wondering if there's any way to speed this up other than throwing more CPU at it.
Is modifyTimestamp indexed?
Have you raised your idlscanlistlimit to 999999999?
Sounds like you have a full table scan going on. The above two changes will fix it.
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
[fedora-arm] Re: Disabling serial console in u-boot
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
<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
[fedora-arm] Re: Disabling serial console in u-boot
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?
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 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).
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
> > 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?
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 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).
--
Chris Adams <linux@cmadams.net>
--
_______________________________________________
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
Subscribe to:
Posts (Atom)