Re: PCIe slot on Raspberry Pi CM4
by Randy DuCharme
I realize this is of zero help - but had similar issues wit F38. I
needed my RPi to be working so shifted over to Manjaro.
Zero issues !
Jus' sayin'
On 9/3/2023 9:33 PM, James Clark wrote:
> I am trying to connect an i210-T1 to the PCIe slot on a Raspberry Pi
> CM4 with the official IO board. The problem is it won't boot. I tried
> this in Fedora 38 initially. Now I've installed a recent nightly
> (Fedora-Server-39-20230828.n.0.aarch64.raw.xz) and I've connected a
> USB TTL adapter. It appears to be a U-Boot problem. I get the
> following over and over again
>
> U-Boot 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000)
>
> DRAM: 992 MiB (effective 7.9 GiB)
> RPI Compute Module 4 (0xd03141)
> Core: 212 devices, 16 uclasses, devicetree: board
> MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> In: serial,usbkbd
> Out: serial,vidconsole
> Err: serial,vidconsole
> Net: eth0: ethernet@7d580000
> PCIe BRCM: link up, 2.5 Gbps x1 (SSC)
> "Error" handler, esr 0xbf000002
> elr: 00000000000b52b0 lr : 00000000000b526c (reloc)
> elr: 000000003df812b0 lr : 000000003df8126c
> x0 : 000000000000dead x1 : 0000000000100000
> x2 : 0000000000008000 x3 : 00000000fd508000
> x4 : 000000003db399f0 x5 : 0000000000000001
> x6 : 000000003df82bb8 x7 : 000000003db39fc0
> x8 : 000000003df82c90 x9 : 000000003db3992c
> x10: 0000000000000002 x11: 0000000000000140
> x12: 000000003db39918 x13: 000000003db39fc0
> x14: 00000000ffffffff x15: 000000003db39b78
> x16: 000000003df82c90 x17: 0000000000c0c0c0
> x18: 000000003db47d60 x19: 000000003db399f0
> x20: 0000000000000001 x21: 000000003db53f00
> x22: 0000000000000000 x23: 0000000000010000
> x24: 000000003dfc58fc x25: 000000000001ff00
> x26: 000000000000ffff x27: 0000000000000000
> x28: 000000003db53b10 x29: 000000003db39950
>
> Code: 350001f4 f94017e0 39400000 92401c00 (d5033fbf)
> Resetting CPU ...
>
> resetting ...
>
> James
>
>
>
> _______________________________________________
> 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
--
Randall DuCharme (Radio AD5GB)
Powered entirely by Open Source software.
7 months, 3 weeks
Re: Fedora Minimal 36 installation on raspberry pi 2B
by Gregory Carter
DNF no longer has sufficient resources on my PI 3, after a recent update,
to work anymore.
The slooooooow creap of fixes, patches and related support elements to make
ARM a well supported option on Fedora is taking its toll.
I know microdnf has been discussed a few times, but here is another
alternative which worked for me.
Another way of dealing with dnf memory issues is to add swap space using a
swap file on my Raspberry PI 3+
This corrects a memory deficit of about 200MB on my PI 3's working set of
physical RAM pages, which kicks me out of the remote shell.
Here is the steps I used to start using dnf again:
I decided I would put the swap file off the /mnt so I made a directory for
it:
mkdir /mnt/swapfiles
Then I made the swapfile I picked 5G, if you don't have that sort of space
you might need to experiment with an appropriate size, maybe 2G?
fallocate -l 5G /mnt/swapfiles/swpf1
An Alternative is to use dd to make the swp if you happen to be
running a slimmed down installation and do not have fallocate
installed.
dd if=/dev/zero of=/mnt/swapfiles/swpf1 bs=1024 count=5048576
Set the access rights on the swapfile like so:
chmod 600 /mnt/swapfiles/swpf1
Tell Linux about the swapfile:
mkswap /mnt/swapfiles/swpf1
Activate the swapfile:
swapon /mnt/swapfiles/swpf1
I only use the swap file when I am loading or patching with DNF, so I
did not put the swapfile configuration into my fstab file.
So I just execute a swapon before I do a "dnf update".
My reason for doing so is to eliminate any unwanted writes to the
sdcard that are not absolutely required.
Which helps extend the life of the sdcard.
If you want to add the swapfile so that it is always on, you have to
add a line to the /etc/fstab file like so:
/mnt/swapfiles/swpf1 swap swap defaults 0 0
i hope you found this helpful. I know I did. :-)
On Fri, Jan 20, 2023 at 3:39 PM Irene Diez <idiez(a)redhat.com> wrote:
> Hello there,
>
> I'm trying to install Fedora-Minimal-36-1.5.armhfp.raw on my raspberry pi
> 2B. Installation was a success but the device runs out of memory when
> trying to install anything via dnf and I get kicked out of the shell.
>
> I've followed the installation instructions in
> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual,
> which specify that this model is supported since Fedora 29; so, is it there
> anything that I'm missing for Fedora to work?
>
> Thanks,
>
> Irene
> _______________________________________________
> 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
>
1 year, 2 months
Re: Fedora-Minimal-36-1.5 on raspberry pi 2B
by DancesWithCars
Run console not windowed
might save some RAM
Used to be an init level what it is now
other may be able to fill in
Just a workaround,
yeah it's bloated (aka piggy)
and running on anorexic (🩻)
for lack of better terms
On Fri, Jan 20, 2023, 23:34 Gregory Carter <gjcarter2(a)gmail.com> wrote:
> Oh thats a easy fix. Just dnf update a couple of packages at a time,
> don't try to do it all at once.
>
> i.e. don't do a "dnf update"
>
> Do a "dnf update kernel" for example.
>
> If you can't run dnf for even one package update I would install something
> else as you are going to run into more problems than just dnf.
>
> Thats just the START of your problems.
>
> On Fri, Jan 20, 2023 at 4:12 PM Troy Dawson <tdawson(a)redhat.com> wrote:
>
>> Unfortunately this isn't a matter of arm vs x86_64, it's a matter of the
>> dnf with it's repo's have gotten too big to fit in memory.
>>
>> This is the discussion on the devel list
>> "Heads-up / for discussion: dnf not working with 1G of RAM or less"
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>>
>> It's a bit of a long read.
>> I did see two or three work-arounds.
>> 1 - Add a swap partition and/or swapfile
>> 2 - Use microdnf (but you have to figure out how to install it. see
>> workaround 1)
>> 3 - Use dnf5 (see workaround 2, and it's still missing some features)
>>
>> There might be other workarounds that I missed. As I said, it's a bit of
>> a read.
>>
>>
>> On Fri, Jan 20, 2023 at 2:56 PM Gregory Carter <gjcarter2(a)gmail.com>
>> wrote:
>>
>>>
>>> https://developer.arm.com/documentation/ddi0464/f/Programmers-Model/About...
>>>
>>> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
>>>
>>> I do not believe that is supported platform for F37 out of the box.
>>>
>>> You may have to build a custom kernel/package set on something that
>>> small to run F37.
>>>
>>> 1Gig is really scraping the bottom of the barrel to run the default
>>> image you downloaded.
>>>
>>> Plus I would use the raw image, not the armhfp.
>>>
>>> But to start I would strip out all of the desktop components in the
>>> image like KDE/GNOME/X and Wayland.
>>>
>>> On Fri, Jan 20, 2023 at 3:42 PM Irene Diez <idiez(a)redhat.com> wrote:
>>>
>>>> Hello there,
>>>>
>>>> I'm trying to install Fedora-Minimal-36-1.5.armhfp.raw on my raspberry
>>>> pi 2B. Installation was a success but the device runs out of memory
>>>> when trying to install anything via dnf and I get kicked out of the
>>>> shell.
>>>>
>>>> I've followed the installation instructions in
>>>> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual,
>>>> which specify that this model is supported since Fedora 29; so, is
>>>> there anything that I'm missing for Fedora to work?
>>>>
>>>> Thanks,
>>>>
>>>> Irene
>>>> _______________________________________________
>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
1 year, 3 months
Re: Fedora-Minimal-36-1.5 on raspberry pi 2B
by Gregory Carter
Oh thats a easy fix. Just dnf update a couple of packages at a time, don't
try to do it all at once.
i.e. don't do a "dnf update"
Do a "dnf update kernel" for example.
If you can't run dnf for even one package update I would install something
else as you are going to run into more problems than just dnf.
Thats just the START of your problems.
On Fri, Jan 20, 2023 at 4:12 PM Troy Dawson <tdawson(a)redhat.com> wrote:
> Unfortunately this isn't a matter of arm vs x86_64, it's a matter of the
> dnf with it's repo's have gotten too big to fit in memory.
>
> This is the discussion on the devel list
> "Heads-up / for discussion: dnf not working with 1G of RAM or less"
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> It's a bit of a long read.
> I did see two or three work-arounds.
> 1 - Add a swap partition and/or swapfile
> 2 - Use microdnf (but you have to figure out how to install it. see
> workaround 1)
> 3 - Use dnf5 (see workaround 2, and it's still missing some features)
>
> There might be other workarounds that I missed. As I said, it's a bit of
> a read.
>
>
> On Fri, Jan 20, 2023 at 2:56 PM Gregory Carter <gjcarter2(a)gmail.com>
> wrote:
>
>>
>> https://developer.arm.com/documentation/ddi0464/f/Programmers-Model/About...
>>
>> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
>>
>> I do not believe that is supported platform for F37 out of the box.
>>
>> You may have to build a custom kernel/package set on something that small
>> to run F37.
>>
>> 1Gig is really scraping the bottom of the barrel to run the default image
>> you downloaded.
>>
>> Plus I would use the raw image, not the armhfp.
>>
>> But to start I would strip out all of the desktop components in the
>> image like KDE/GNOME/X and Wayland.
>>
>> On Fri, Jan 20, 2023 at 3:42 PM Irene Diez <idiez(a)redhat.com> wrote:
>>
>>> Hello there,
>>>
>>> I'm trying to install Fedora-Minimal-36-1.5.armhfp.raw on my raspberry
>>> pi 2B. Installation was a success but the device runs out of memory
>>> when trying to install anything via dnf and I get kicked out of the
>>> shell.
>>>
>>> I've followed the installation instructions in
>>> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual,
>>> which specify that this model is supported since Fedora 29; so, is
>>> there anything that I'm missing for Fedora to work?
>>>
>>> Thanks,
>>>
>>> Irene
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
1 year, 3 months
Re: Fedora-Minimal-36-1.5 on raspberry pi 2B
by Troy Dawson
Unfortunately this isn't a matter of arm vs x86_64, it's a matter of the
dnf with it's repo's have gotten too big to fit in memory.
This is the discussion on the devel list
"Heads-up / for discussion: dnf not working with 1G of RAM or less"
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
It's a bit of a long read.
I did see two or three work-arounds.
1 - Add a swap partition and/or swapfile
2 - Use microdnf (but you have to figure out how to install it. see
workaround 1)
3 - Use dnf5 (see workaround 2, and it's still missing some features)
There might be other workarounds that I missed. As I said, it's a bit of a
read.
On Fri, Jan 20, 2023 at 2:56 PM Gregory Carter <gjcarter2(a)gmail.com> wrote:
>
> https://developer.arm.com/documentation/ddi0464/f/Programmers-Model/About...
>
> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
>
> I do not believe that is supported platform for F37 out of the box.
>
> You may have to build a custom kernel/package set on something that small
> to run F37.
>
> 1Gig is really scraping the bottom of the barrel to run the default image
> you downloaded.
>
> Plus I would use the raw image, not the armhfp.
>
> But to start I would strip out all of the desktop components in the image
> like KDE/GNOME/X and Wayland.
>
> On Fri, Jan 20, 2023 at 3:42 PM Irene Diez <idiez(a)redhat.com> wrote:
>
>> Hello there,
>>
>> I'm trying to install Fedora-Minimal-36-1.5.armhfp.raw on my raspberry
>> pi 2B. Installation was a success but the device runs out of memory
>> when trying to install anything via dnf and I get kicked out of the
>> shell.
>>
>> I've followed the installation instructions in
>> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual,
>> which specify that this model is supported since Fedora 29; so, is
>> there anything that I'm missing for Fedora to work?
>>
>> Thanks,
>>
>> Irene
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
1 year, 3 months
Re: wondering about a few kernel config options
by Ian McInerney
On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe <dusty(a)dustymabe.com> wrote:
>
>
> On 4/27/22 12:27, Ian McInerney wrote:
> > On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson <pbrobinson(a)gmail.com
> <mailto:pbrobinson@gmail.com>> wrote:
> >
> > Hey Dusty,
> >
> > > > Hey jforbes,
> > > >
> > > > I'm looking at buying a quartz64 ARM board (relatively new board
> > > > from pine64 kind of like a Raspberry Pi) [1]. I think there are
> > > > some config options in the kernel that need to be set. I found
> where
> > > > someone opened a PR for Arch [2]. I compared that with what we
> have
> > > > in the Fedora aarch64 kernel config and here's what would need
> to change:
> > > >
> > > > CONFIG_MMC_SDHCI_OF_DWCMSHC is not set -> y
> > > > CONFIG_MOTORCOMM_PHY=m -> y
> > > >
> > > > Is changing kernel config options a big ask or a reasonable
> request?
> >
> > Is it a big ask? No, is it a reasonable request? No.
> >
> > These are arm devices so please come to the arm list/maintainers with
> > these requests?
> >
> >
> > IMO asking Justin was a perfectly valid start to exploring these
> options, because he is the Fedora kernel maintainer. And Justin reached out
> to this list to solicit input and opinions, so was there really any harm
> done?
> >
> >
> >
> > > This should not be a problem. I am CCing
> arm(a)lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org>
> > > so that others are aware. I will try to remember for 5.17.5
> tomorrow,
> > > but on vacation travelling by motorcycle this week, so if I forget,
> > > remind me early next week.
> >
> > Why do they need to be built in? They don't. One is a SDHCI driver
> and
> > the other is an ethernet PHY, both are dealt with in initrd just fine
> > and have no reason to be built in, we deal with these just fine
> across
> > 100s of other devices in initrd.
> >
> >
> > Link [2] provided in the initial email forwarded to the list says that
> module loading for the motorcomm PHY does not work because the chip has a
> zeroed out manufacturer ID and so it gets associated to the generic driver
> first and then can't be associated with the proper driver later. Moving the
> driver from a module to being built into the kernel is mentioned under the
> troubleshooting section of the Pine64 wiki (
> https://wiki.pine64.org/wiki/Quartz64#No_Ethernet_Connectivity <
> https://wiki.pine64.org/wiki/Quartz64#No_Ethernet_Connectivity>) as being
> the fix for this issue.
> >
> > Looking at the driver history, it was noted that the OUI is empty during
> the initial driver review https://lkml.org/lkml/2021/5/14/522 <
> https://lkml.org/lkml/2021/5/14/522>, and nothing further was noted other
> than the possibility of an OUI conflict. So this appears to be needed to
> fix a quirk in the hardware where motorcomm didn't include their OUI even
> though they were assigned one.
> >
> > That being said, I am not sure what the likelihood of a conflict with
> another PHY reporting the same (empty) OUI part would be, and so I am not
> sure if this would usurp the generic driver in any cases it shouldn't if it
> were to be built into the kernel instead of as a module.
> >
> > As for the other config (CONFIG_MMC_SDHCI_OF_DWCMSHC), there is no note
> about if it needs to be a module or built-in, so it can probably be loaded
> by the Quartz64 as a module. The original requester probably suggested it
> as a built-in because that is what the other enablement PR in the other
> distro did.
>
> Thanks Ian.
>
> From your evaluation does it look like the following is true:
>
> CONFIG_MOTORCOMM_PHY=m -> y - might be needed for this specific hardware
> but we don't know if it's safe to do.
> CONFIG_MMC_SDHCI_OF_DWCMSHC needs to be set and having it be a loadable
> module should be fine?
>
That summary makes sense to me, and I think the one that could be done
immediately would be setting CONFIG_MMC_SDHCI_OF_DWCMSHC=m, since enabling
a new module is probably not controversial.
As for the CONFIG_MOTORCOMM_PHY entry, I did see that there is a device
tree currently under review upstream for the Quartz64-B (
https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344....),
but it doesn't include any compatibility entry for selecting the motorcomm
PHY driver. I haven't experimented with this yet, but I wonder if adding an
entry to the device tree would allow the proper driver to be loaded from a
module once this device tree is accepted into upstream. I have reached out
to the original device tree author (who also contributed the motorcomm
driver) to get their thoughts on this. If the device tree entry will work,
then it means the motorcomm driver could be built as a module instead.
-Ian
>
> Thanks for the help!
> Dusty
>
1 year, 12 months
Re: Raspberry Pi PoE HAT
by Brad Smith
Fedora Arm Community -
Ben Herrick and I exchanged several messages about Fedora 36 and
Fedora 35. I was successful in getting the POE Hat fan to work with
Fedora 36 (beta) using a couple of the steps as outlined in the Fedora
wiki for RPI Hats but was not as successful with Fedora 35. I suspect
it should work as long as current firmware files are used (e.g.
start4.elf) but in my very limited testing with FC35, I could not get
the board to boot and I was too lazy to pull the headless board from
the rack to plug a monitor and keyboard to see where the boot was
stalling.
My original process involving a custom upstream device tree to
integrate with the POE Hat fan device driver still works fine for FC35
and FC34.
For Fedora 36 (beta) I found that if I followed the steps in the wiki
to load the firmware device tree (rm /boot/dtb and set FirmwareDT=true
in /etc/u-boot.conf) then the POE Hat fan would just work as long as I
also made sure the upstream_kernel=1 option in config.txt was
commented out.
I did not need to add the rpi-poe or i2c dtoverlay lines to
config.txt. This process worked on 3 RPi4 boards that were updated
from FC35 using dnf system upgrade and which use u-boot. A fourth RPi4
using UEFI was also updated to FC36 beta with upstream_kernel=1
commented out and the POE Hat fan also worked without any additional
configuration. All 4 boards are 8 GB and all 4 POE Hats are the
original model.
The device tree can be inspected at /proc/device-tree and will show a
directory called pwm-fan which is the hook needed for the upstream fan
device driver. lsmod can be used to display the presence of the
pwm_raspberrypi_poe device driver that makes all of this happen as
long as the linux kernel is 5.13 or newer (if i recall correctly).
Glad to answer any questions.
regards
Brad
On Mon, Apr 18, 2022 at 7:15 AM Ben Herrick <intrep(a)tauran.net> wrote:
>
> Fedora ARM mailing list,
>
> I've been trying to get the fan on my Raspberry Pi PoE HAT working with Fedora 35 and 36 Beta. I'm using the aarch64 raw image.
>
> I came across the instructions on the wiki page here: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs#PoE_Hat
>
> Unfortunately, the line in config.txt from the wiki didn't work for me.
>
> The lines that did work on Fedora 36 Beta for aarch64 are below:
>
> dtoverlay=i2c
> dtoverlay=pwm-raspberrypi-poe
>
> I'm also able to set the fan parameters with the below:
>
> dtparam=poe_fan_temp0=70000,poe_fan_temp0_hyst=10000
> dtparam=poe_fan_temp1=60000,poe_fan_temp1_hyst=10000
> dtparam=poe_fan_temp2=50000,poe_fan_temp2_hyst=10000
> dtparam=poe_fan_temp3=40000,poe_fan_temp3_hyst=10000
>
> Note that these same lines didn't work for me on Fedora 35 aarch64.
>
> I'm hoping others can replicate my experience and the wiki can be updated to help others.
>
> Please let me know if you have any questions or concerns.
>
> -Ben Herrick
>
> _______________________________________________
> 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 on the list, report it: https://pagure.io/fedora-infrastructure
2 years
Re: Clarification of RPi 4 support
by Peter Robinson
On Mon, Apr 4, 2022 at 4:34 PM Ben Cotton <bcotton(a)redhat.com> wrote:
>
> Hi ARM folks,
>
> It came to my attention today that the Quick Docs say that Raspberry
> Pi 4 is supported[1], but the Wiki page[2] says it's not. I assume the
> Quick Docs edit is incorrect, but I wanted to make sure before I start
> making changes.
That is correct, it "mostly works" but there is no accelerated
graphics and there's a few other key bits missing which means it's not
yet supported.
> If there's a reason I *shouldn't* remove RPi 4 from the Quick Docs
> page, please let me know on list or in
> https://pagure.io/fedora-docs/quick-docs/issue/441
Can we also delete the FAQ section as well and just direct them to the
wiki, I have no idea who added this but I don't ever remember being
consulted.
> (Note that this could also impact the blocker status[3] of RHBZ 2053729)
I agree that should be a blocker, the network the non desktop side of
things is basically supported. There's also a fix that the kernel term
were planning on pulling in with 5.17.2 so we already have a fix ready
for that.
> [1] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
> [2] https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_4
> [3] https://pagure.io/fedora-qa/blocker-review/issue/709
>
>
> Thanks,
> BC
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> 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 on the list, report it: https://pagure.io/fedora-infrastructure
2 years
