10:12 a.m.
I have a Raspberry Pi 4B running Fedora 38 (server edition) that I use
as a little occasional server for random things. Since it doesn't
always have NTP available, I added an RTC module, and added
"dtoverlay=i2c-rtc,ds1307" to /boot/efi/config.txt (no other change);
all is good.
Now I have a short-term need to use it as a desktop, so I put the XFCE
spin on a different uSD card. I made the same edit to config.txt... and
it doesn't work. No RTC.
I've loaded all the Fedora updates, including the firmware with
"rpi-uboot-update", but it still doesn't work. If I swap back to the
"server" uSD card, it sees the RTC.
The only difference I can see is that the original card is 32G and the
new card is 64G (so "SDXC")... would that be an issue to the firmware
loader?
--
Chris Adams <linux(a)cmadams.net>
10:29 a.m.
On Wed, Aug 23, 2023 at 4:12 PM Chris Adams <linux(a)cmadams.net> wrote:
I have a Raspberry Pi 4B running Fedora 38 (server edition) that I use
as a little occasional server for random things. Since it doesn't
always have NTP available, I added an RTC module, and added
"dtoverlay=i2c-rtc,ds1307" to /boot/efi/config.txt (no other change);
all is good.
Now I have a short-term need to use it as a desktop, so I put the XFCE
spin on a different uSD card. I made the same edit to config.txt... and
it doesn't work. No RTC.
I've loaded all the Fedora updates, including the firmware with
"rpi-uboot-update", but it still doesn't work. If I swap back to the
"server" uSD card, it sees the RTC.
The only difference I can see is that the original card is 32G and the
new card is 64G (so "SDXC")... would that be an issue to the firmware
loader?
I doubt it.
Ddi you follow this section of the HATs/Overlay docs?
https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_P...
10:41 a.m.
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
Ddi you follow this section of the HATs/Overlay docs?
https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_P...
It's my understand that that section is obsolete. I did not do that on
my "server" uSD card, and it loads the RTC overlay correctly.
--
Chris Adams <linux(a)cmadams.net>
10:49 a.m.
On Wed, Aug 23, 2023 at 4:41 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
> Ddi you follow this section of the HATs/Overlay docs?
>
https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_P...
It's my understand that that section is obsolete. I did not do that on
my "server" uSD card, and it loads the RTC overlay correctly.
I don't know where you got that idea from. As the Raspberry Pi
maintainer it's currently not.
In ostree based systems we don't ship a kernel DT so it automatically
uses the firmware DT so if your "server install" you're using ostree
that is probably why.
11:24 a.m.
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
On Wed, Aug 23, 2023 at 4:41 PM Chris Adams <linux(a)cmadams.net>
wrote:
>
> Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
> > Ddi you follow this section of the HATs/Overlay docs?
> >
https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_P...
>
> It's my understand that that section is obsolete. I did not do that on
> my "server" uSD card, and it loads the RTC overlay correctly.
I don't know where you got that idea from. As the Raspberry Pi
maintainer it's currently not.
I thought I read here that that shouldn't be followed anymore. My
mistake.
In ostree based systems we don't ship a kernel DT so it
automatically
uses the firmware DT so if your "server install" you're using ostree
that is probably why.
Nope, it's just the server image vs. the XFCE image. I have a couple of
Pi 4s running Fedora 38 "server" that are loading overlays (one just the
RTC, one also getting PPS from a GPS HAT and disabling wifi/BT) without
doing anything other than editing config.txt (both still have the
standard /boot/dtb symlink).
--
Chris Adams <linux(a)cmadams.net>
2:10 p.m.
Just to re-test: I wrote the following two images (using the same uSD
card, so not it either):
Fedora-Server-38-1.6.aarch64.raw.xz
Fedora-Xfce-38-1.6.aarch64.raw.xz
Wrote them out on a F37 system with arm-image-installer like:
arm-image-installer --image <image> --media /dev/sda --addkey
../.ssh/id_ed25519.pub --resizefs --target rpi4
then, before moving the card to the Pi, mounted the first partition and
changed config.txt to include "dtoverlay=i2c-rtc,ds1307" (no other
change, so /boot/dtb symlink still present). When I boot the Server
image, it sees the RTC, when I boot the Xfce image, it does not.
On the Xfce image, if I also remove the /boot/dtb symlink, it sees the
RTC.
So there's some inconsistency between images (maybe it's just that the
Server image is not working as expected?), but I guess I have a working
setup.
--
Chris Adams <linux(a)cmadams.net>
6:18 p.m.
On Wed, Aug 23, 2023 at 8:10 PM Chris Adams <linux(a)cmadams.net> wrote:
Just to re-test: I wrote the following two images (using the same uSD
card, so not it either):
Fedora-Server-38-1.6.aarch64.raw.xz
Fedora-Xfce-38-1.6.aarch64.raw.xz
Wrote them out on a F37 system with arm-image-installer like:
arm-image-installer --image <image> --media /dev/sda --addkey
../.ssh/id_ed25519.pub --resizefs --target rpi4
then, before moving the card to the Pi, mounted the first partition and
changed config.txt to include "dtoverlay=i2c-rtc,ds1307" (no other
change, so /boot/dtb symlink still present). When I boot the Server
image, it sees the RTC, when I boot the Xfce image, it does not.
I suspect the /boot partition on server is XFS and on XFCE it's ext4?
U-Boot can't load off XFS so it falls back to the FW provided DT and
hence basically is the same as not having the link there.
On the Xfce image, if I also remove the /boot/dtb symlink, it sees
the
RTC.
So there's some inconsistency between images (maybe it's just that the
Server image is not working as expected?), but I guess I have a working
setup.
Suspect it's a difference in filesystems for /boot.
10:25 a.m.
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
I suspect the /boot partition on server is XFS and on XFCE it's
ext4?
U-Boot can't load off XFS so it falls back to the FW provided DT and
hence basically is the same as not having the link there.
Ahh, this was indeed it. I switched /boot on the XFCE image to XFS and
it did indeed follow the config.txt entry for the RTC (so same as
removing the /boot/dtb symlink).
Interesting to know... learn more about the oddities of ARM booting all
the time. :) Maybe should the aarch64 images all use an ext4 /boot for
consistency and to avoid confusion?
Thanks.
--
Chris Adams <linux(a)cmadams.net>
12:33 p.m.
Once upon a time, Chris Adams <linux(a)cmadams.net> said:
Ahh, this was indeed it. I switched /boot on the XFCE image to XFS
and
it did indeed follow the config.txt entry for the RTC (so same as
removing the /boot/dtb symlink).
Oh, but when I run the XFCE image (with ext4 /boot as shipped) and
remove /boot/dtb... X just errors out with "no screens found". So I
can't do that either, unless there's something to change in config.txt
to match (or at least be close enough) to the kernel-provided device
tree.
--
Chris Adams <linux(a)cmadams.net>
12:38 p.m.
Once upon a time, Chris Adams <linux(a)cmadams.net> said:
> Ahh, this was indeed it. I switched /boot on the XFCE image to XFS and
> it did indeed follow the config.txt entry for the RTC (so same as
> removing the /boot/dtb symlink).
Oh, but when I run the XFCE image (with ext4 /boot as shipped) and
remove /boot/dtb... X just errors out with "no screens found". So I
can't do that either, unless there's something to change in config.txt
to match (or at least be close enough) to the kernel-provided device
tree.
All the bits for screen enablement using upstream drivers should be
there by default. What else have you done to your config.txt? What
exactly is the revision of RPi?
1:09 p.m.
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
All the bits for screen enablement using upstream drivers should be
there by default. What else have you done to your config.txt? What
exactly is the revision of RPi?
All I've done to the XFCE image is "dnf update", add the dtoverlay for
the RTC, and rm /boot/dtb. If I put /boot/dtb back, I get video (but
then no RTC).
I did try a couple of other things in config.text:
- hdmi_enable_4kp60=1
- enable_uart=0
But making either of those changes (both or one at a time) resulted in
not even getting the u-boot screen on HDMI (so I set them back to
as-shipped).
It's a 4B with 8G RAM. /sys/firmware/devicetree/base/model says rev 1.5
(I guess that's the right place to look?).
--
Chris Adams <linux(a)cmadams.net>
1:16 p.m.
Once upon a time, Chris Adams <linux(a)cmadams.net> said:
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
> All the bits for screen enablement using upstream drivers should be
> there by default. What else have you done to your config.txt? What
> exactly is the revision of RPi?
All I've done to the XFCE image is "dnf update", add the dtoverlay for
the RTC, and rm /boot/dtb. If I put /boot/dtb back, I get video (but
then no RTC).
Oh one correction: I also did rpi-uboot-update.
--
Chris Adams <linux(a)cmadams.net>
12:37 p.m.
On Thu, Aug 24, 2023 at 4:25 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
> I suspect the /boot partition on server is XFS and on XFCE it's ext4?
> U-Boot can't load off XFS so it falls back to the FW provided DT and
> hence basically is the same as not having the link there.
Ahh, this was indeed it. I switched /boot on the XFCE image to XFS and
it did indeed follow the config.txt entry for the RTC (so same as
removing the /boot/dtb symlink).
Interesting to know... learn more about the oddities of ARM booting all
the time. :) Maybe should the aarch64 images all use an ext4 /boot for
consistency and to avoid confusion?
TBH I would sooner just move to firmware provided DT so we don't have
to ship DT as part of the kernel at all. I've been slowly working on
that but I'm not quite there yet and it's one of those items for "when
I have some spare time" which has been very little of late as I've
been looking at other things.
1:11 p.m.
Once upon a time, Peter Robinson <pbrobinson(a)gmail.com> said:
TBH I would sooner just move to firmware provided DT so we don't
have
to ship DT as part of the kernel at all. I've been slowly working on
that but I'm not quite there yet and it's one of those items for "when
I have some spare time" which has been very little of late as I've
been looking at other things.
So I think I read something along these lines here before, and that's
where I took the "don't touch /boot/dtb" idea from. Sorry about that
confusion.
And also, thanks for your help and work!
--
Chris Adams <linux(a)cmadams.net>
11:50 a.m.
Use the pool Luke!
Install chrony (an NTP-like server). By default it uses the NTP POOL
servers *.fedora.pool.ntp.org
You can have milliseconds precision, without the drift of a RTC.
Perhaps syncing with you other π with GPS/PPS over NTP -- join the pool.
--
Ing. Héctor Daniel Cortés González <hdcg(a)ier.unam.mx> | Thou shalt not
antes 'Aztec Eagle' Turbo <turbo@c <turbo(a)lsl.com.mx>ie.unam.mx>
|
take the name
http://www.ier.unam.mx/academicos/hdcg/ | of root
RHCE 110-903-861. Linux User #13086. | in vain.
------------------------------------------------------------------------
perl6 -e '(1 x $_) !~~ /^(11+)$0+$/ && .say while ++ $_'
El mié, 23 ago 2023 a la(s) 09:12, Chris Adams (linux(a)cmadams.net) escribió:
I have a Raspberry Pi 4B running Fedora 38 (server edition) that I
use
as a little occasional server for random things. Since it doesn't
always have NTP available, I added an RTC module, and added
"dtoverlay=i2c-rtc,ds1307" to /boot/efi/config.txt (no other change);
all is good.
Now I have a short-term need to use it as a desktop, so I put the XFCE
spin on a different uSD card. I made the same edit to config.txt... and
it doesn't work. No RTC.
I've loaded all the Fedora updates, including the firmware with
"rpi-uboot-update", but it still doesn't work. If I swap back to the
"server" uSD card, it sees the RTC.
The only difference I can see is that the original card is 32G and the
new card is 64G (so "SDXC")... would that be an issue to the firmware
loader?
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
arm mailing list -- arm(a)lists.fedoraproject.org
To unsubscribe send an email to arm-leave(a)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
11:58 a.m.
Once upon a time, Héctor Daniel Cortés González <hdcg(a)ier.unam.mx> said:
Install chrony (an NTP-like server). By default it uses the NTP POOL
servers *.fedora.pool.ntp.org
I'm quite familiar with NTP... but it does require Internet access or a
local time source, which I won't (reliably) have available for this
particular use.
--
Chris Adams <linux(a)cmadams.net>
12:22 p.m.
Understood.
An USB dongle? There are with RTC, GPS and even for WWVB :-)
--
Ing. Héctor Daniel Cortés González <hdcg(a)ier.unam.mx> | Thou shalt not
antes 'Aztec Eagle' Turbo <turbo@c <turbo(a)lsl.com.mx>ie.unam.mx>
|
take the name
http://www.ier.unam.mx/academicos/hdcg/ | of root
RHCE 110-903-861. Linux User #13086. | in vain.
------------------------------------------------------------------------
perl6 -e '(1 x $_) !~~ /^(11+)$0+$/ && .say while ++ $_'
El mié, 23 ago 2023 a la(s) 10:58, Chris Adams (linux(a)cmadams.net) escribió:
Once upon a time, Héctor Daniel Cortés González
<hdcg(a)ier.unam.mx> said:
> Install chrony (an NTP-like server). By default it uses the NTP POOL
> servers *.fedora.pool.ntp.org
I'm quite familiar with NTP... but it does require Internet access or a
local time source, which I won't (reliably) have available for this
particular use.
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
arm mailing list -- arm(a)lists.fedoraproject.org
To unsubscribe send an email to arm-leave(a)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
12:28 p.m.
Once upon a time, Héctor Daniel Cortés González <hdcg(a)ier.unam.mx> said:
Understood.
An USB dongle? There are with RTC, GPS and even for WWVB :-)
I've already bought a perfectly-functioning RTC... not looking for
suggestions for alternatives.
--
Chris Adams <linux(a)cmadams.net>
259
days inactive
260
days old
17 comments
3 participants
participants (3)
-
Chris Adams -
Héctor Daniel Cortés González -
Peter Robinson