Re: Change in kernel PPS GPIO handling?
by Stefan Wahren
Hi Peter,
Am 31.03.22 um 15:19 schrieb Peter Robinson:
> Hi Stefan,
>
>>>> At least the 32 bit issues on Raspberry Pi 4 are expected since the
>>>> kernel config doesn't have ARM_LPAE enabled.
>>>>
>>> Okay, here is the explanation for the different behavior on Raspberry Pi
>>> 400 and Raspberry Pi 4 B. The Raspberry Pi 400 has a newer BCM2711 SoC
>>> (Stepping C0), which have less DMA restrictions for the emmc2 interface
>>> (responsible for SD card access). For the Raspberry Pi 4 B there are
>>> older boards which have Stepping B0 and all the new boards should have
>>> Stepping C0 [1].
>>>
>>> Unfortunately there is no 100% reliable way to detect the stepping from
>>> the kernel side. So currently the Raspberry Pi firmware patches the
>>> dma-ranges in the firmware DT [2]. So in case U-Boot [3] or another
>>> bootloader ignores this firmware DT and read a fresh DTB the right
>>> dma-ranges get lost. Finally this results in unexpected behavior as soon
>>> the emmc2 switches to DMA mode [4].
>>>
>> Okay, at least i found a fix [1] for the 64 bit boot issues (Original
>> Fedora 35, Linux 5.14) with RPi 400/RPi 4 Stepping C0. This requires the
>> DTB files to be updated and U-Boot to choose between the B0 and the C0
>> variant of the Rpi 4 DTB file.
> Thanks for the update on this, great news. In the case of the RPi-400
> are they all the C0 stepping? I don't see the 400 in your patch.
Yes, please look at [1]
The patch changes makes bcm2711.dtsi default to C0. So all including RPi
4 boards (RPi 4, CM4, RPi 400) will be affected and all new boards don't
need to care about it.
> Is there a documented way of detecting the stepping that can be used
> in U-Boot I can use to create a patch there, or did you have a test
> patch for this?
I searched in the Raspberry Pi forum and there was the statement that
there is no direct (official) way to detect the SoC stepping. A
possibility might be to detect the DMA range provided by the firmware
FDT (U-Boot has dev_get_dma_range() for this) and based on the value
decide which DTB should be loaded (bcm2711-rpi-4-b.dtb for C0 and
bcm2711-rpi-4-b-b0.dtb for B0).
> Do you plan to send this patch upstream, if so feel free to add me to
> the cc and in the mean time I'll test it.
Yes. I didn't send it yet, because the merge window is currently open
and i want to rebase it on 5.18-rc1. The patch itself is a little bit
controversial (fix which introduce new file and change behavior).
Best regards
>
>> Unfortunately this doesn't fix the SD card issues on 32 bit.
> That's less of a problem, Fedora 36 will be the last version of Fedora
> to support 32 bit and I've always suggested people run 64 bit Fedora
> on their RPi4 and most people do tend to do that.
>
> Thanks,
> Peter
[1] - https://github.com/raspberrypi/firmware/issues/1704
2 years
Re: Change in kernel PPS GPIO handling?
by Peter Robinson
Hi Stefan,
> >> At least the 32 bit issues on Raspberry Pi 4 are expected since the
> >> kernel config doesn't have ARM_LPAE enabled.
> >>
> > Okay, here is the explanation for the different behavior on Raspberry Pi
> > 400 and Raspberry Pi 4 B. The Raspberry Pi 400 has a newer BCM2711 SoC
> > (Stepping C0), which have less DMA restrictions for the emmc2 interface
> > (responsible for SD card access). For the Raspberry Pi 4 B there are
> > older boards which have Stepping B0 and all the new boards should have
> > Stepping C0 [1].
> >
> > Unfortunately there is no 100% reliable way to detect the stepping from
> > the kernel side. So currently the Raspberry Pi firmware patches the
> > dma-ranges in the firmware DT [2]. So in case U-Boot [3] or another
> > bootloader ignores this firmware DT and read a fresh DTB the right
> > dma-ranges get lost. Finally this results in unexpected behavior as soon
> > the emmc2 switches to DMA mode [4].
> >
> Okay, at least i found a fix [1] for the 64 bit boot issues (Original
> Fedora 35, Linux 5.14) with RPi 400/RPi 4 Stepping C0. This requires the
> DTB files to be updated and U-Boot to choose between the B0 and the C0
> variant of the Rpi 4 DTB file.
Thanks for the update on this, great news. In the case of the RPi-400
are they all the C0 stepping? I don't see the 400 in your patch.
Is there a documented way of detecting the stepping that can be used
in U-Boot I can use to create a patch there, or did you have a test
patch for this?
Do you plan to send this patch upstream, if so feel free to add me to
the cc and in the mean time I'll test it.
> Unfortunately this doesn't fix the SD card issues on 32 bit.
That's less of a problem, Fedora 36 will be the last version of Fedora
to support 32 bit and I've always suggested people run 64 bit Fedora
on their RPi4 and most people do tend to do that.
Thanks,
Peter
2 years
Re: Change in kernel PPS GPIO handling?
by Stefan Wahren
Am 11.03.22 um 17:37 schrieb Stefan Wahren:
> Am 05.03.22 um 12:34 schrieb Stefan Wahren:
>> Am 04.03.22 um 21:50 schrieb Stefan Wahren:
>>> Am 03.03.22 um 02:29 schrieb Chris Adams:
>>>> Once upon a time, Stefan Wahren <stefan.wahren(a)i2se.com> said:
>>>>> Hi Chris,
>>>>>
>>>>> Am 02.03.22 um 10:51 schrieb Peter Robinson:
>>>>>>> I have an RPi4 running Fedora 35. It hadn't been updated in a while, so
>>>>>>> I applied updates today. When I boot to the kernel 5.16.11-200, I lose
>>>>>>> the PPS device from my GPS hat. Boot back to 5.14.16-301.fc35 and it
>>>>>>> works.
>>>>>>>
>>>>>>> I'm booting with EFI firmware, and with a device tree config.txt that
>>>>>> All our firmware are EFI, that's the only way we support booting, is
>>>>>> it the default U-Boot based one or are you using the edk2 one?
>>>>>>
>>>>>>> has "dtoverlay=pps-gpio,gpiopin=4" in it. I removed the /boot/dtb
>>>>>>> symlink and set /etc/u-boot.conf to not re-add it.
>>>>>>>
>>>>>>> When I boot 5.16, I see /proc/device-tree, and it has
>>>>>>> /proc/device-tree/pps@4 in it (and the contents look correct), but
>>>>>>> loading the pps-gpio kernel module just gives:
>>>>>>>
>>>>>>> pps-gpio: probe of pps@4 failed with error -22
>>>>>> Any chance you can tell us which kernel it started with, 5.14.x to
>>>>>> 5.16.x is a big window to debug and looking at kernel logs for
>>>>>> drivers/pps there's been no changes in that space in the 5.15+ kernels
>>>>>> at all.
>>>>>>
>>>>>> I wonder if it's a change/regression in the firmware overlay <->
>>>>>> kernel interface.
>>>>> do you use the DTB file from 5.14.x or 5.16x?
>>>>>
>>>>> I guess this is related to this commit:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?...
>>>>>
>>>>> Unfortunately this is a change which requires this DTS fix:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?...
>>>>>
>>>>> So DTB and kernel must "match".
>>>> Okay, so what's the best way to do that?
>>>>
>>>> I have EFI firmware from https://github.com/pftf/RPi4 in /boot/efi, and
>>>> the /boot/dtb symlink removed. The bcm2711-rpi-4-b.dtb file in
>>>> /boot/efi is from the RPi4_UEFI_Firmware_v1.32.zip file. I have a
>>>> config.txt in /boot/efi that references overlays in /boot/efi/overlays
>>>> from RPM bcm283x-overlays (like pps-gpio)..
>>>>
>>>> I'm not quite sure how I need to fit all this together.
>>> Let me recap the situation. mainline and rpi vendor tree are independent
>>> in development. Synchronization (incl. device tree) happens in both
>>> directions.
>>>
>>> U-Boot bootloader decided to keep an own copy of the mainline DT files
>>> (which is currently based on an older 5.15 version which lacks the
>>> gpio-ranges property). According to this statement [1] the EDK2 UEFI
>>> decided to use the rpi vendor tree and don't care about the mainline DT
>>> files.
>>>
>>> I'm sorry but as a spare-time kernel developer, i don't have to time to
>>> fight against all this mess.
>>>
>>> I hope i will have some time for debugging in the near future ...
>>>
>>> [1] - https://github.com/pftf/RPi4/issues/193
>>>
>> Today i tried Fedora 35 Minimal for my first time, here are my test results:
>>
>> Raspberry Pi 400 32 bit => bus width issue
>> Raspberry Pi 400 64 bit => hangs while show graphics
>> Raspberry Pi 4 B 4 GB 32 bit => kernel crash
>> Raspberry Pi 4 B 4 GB 64 bit => boot into setup
>> Raspberry Pi 4 B 8 GB 32 bit => black screen, fails to start kernel?
>> Raspberry Pi 4 B 8 GB 64 bit => boot into setup
>>
>> At least the 32 bit issues on Raspberry Pi 4 are expected since the
>> kernel config doesn't have ARM_LPAE enabled.
>>
> Okay, here is the explanation for the different behavior on Raspberry Pi
> 400 and Raspberry Pi 4 B. The Raspberry Pi 400 has a newer BCM2711 SoC
> (Stepping C0), which have less DMA restrictions for the emmc2 interface
> (responsible for SD card access). For the Raspberry Pi 4 B there are
> older boards which have Stepping B0 and all the new boards should have
> Stepping C0 [1].
>
> Unfortunately there is no 100% reliable way to detect the stepping from
> the kernel side. So currently the Raspberry Pi firmware patches the
> dma-ranges in the firmware DT [2]. So in case U-Boot [3] or another
> bootloader ignores this firmware DT and read a fresh DTB the right
> dma-ranges get lost. Finally this results in unexpected behavior as soon
> the emmc2 switches to DMA mode [4].
>
Okay, at least i found a fix [1] for the 64 bit boot issues (Original
Fedora 35, Linux 5.14) with RPi 400/RPi 4 Stepping C0. This requires the
DTB files to be updated and U-Boot to choose between the B0 and the C0
variant of the Rpi 4 DTB file.
Unfortunately this doesn't fix the SD card issues on 32 bit.
Best regards
[1] -
https://github.com/lategoodbye/rpi-zero/commit/d3b2bcf1ca8c0d21625fbf11d0...
2 years
Re: Fedora Server 36 VGA output on a Raspberry Pi 3b
by Peter Robinson
On Tue, Mar 15, 2022 at 10:47 PM Brandon Nielsen <nielsenb(a)jetfuse.net> wrote:
>
> On 3/15/22 3:04 PM, Peter Robinson wrote:
> >> Was hoping to add a bit of test coverage, and ran into a strange issue.
> >>
> >> The beta Server compose[0] boots, but there is no VGA output after the
> >> initial rainbow, u-boot, GRUB, and "Booting..." text (using an HDMI->VGA
> >> adapter) on a Raspberry Pi 3b. Cockpit works so boot clearly succeeded.
> >>
> >> Fedora Minimal for the same compose[1] works as expected with text based
> >> initial setup appearing over VGA.
> >>
> >> Is this a known issue or intended behavior? I couldn't find anything in
> >> Bugzilla.
> >
> > The HDMI to VGA adapters have always been as ropey as hell on the RPi,
> > in fact they were never particularly great even on the OLPCs back in
> > the day either.
> >
> > They're also very variable from device to device so it's very much a
> > case of it may or may not work but we don't really get a lot of
> > reports either way these days TBH.
> >
> > P
>
> I figured that was probably the case. The only thing of note I see in
> the logs is:
>
> Feb 16 00:01:21 fedora kernel: of_clk_hw_onecell_get: invalid index 15
> Feb 16 00:01:21 fedora kernel: [drm:vc4_vec_bind [vc4]] *ERROR* Failed
> to get clock: -2
> Feb 16 00:01:21 fedora kernel: vc4-drm soc:gpu: failed to bind
> 3f806000.vec (ops vc4_vec_ops [vc4]): -2
>
> Interesting that I don't see the issue on minimal.
It's not really, your not driving the the 3D engine or trying to push
it's resolution to the max that the display can support and hence
juggling between the usually straight forward EDID report-able display
and what the VGA interface can do. For text you can generally request
the basics and it'll work, for graphics you wan the best so you need
to actively query and that generally fails in this game of musical
chairs.
2 years, 1 month
Re: Fedora Server 36 VGA output on a Raspberry Pi 3b
by Brandon Nielsen
On 3/15/22 3:04 PM, Peter Robinson wrote:
>> Was hoping to add a bit of test coverage, and ran into a strange issue.
>>
>> The beta Server compose[0] boots, but there is no VGA output after the
>> initial rainbow, u-boot, GRUB, and "Booting..." text (using an HDMI->VGA
>> adapter) on a Raspberry Pi 3b. Cockpit works so boot clearly succeeded.
>>
>> Fedora Minimal for the same compose[1] works as expected with text based
>> initial setup appearing over VGA.
>>
>> Is this a known issue or intended behavior? I couldn't find anything in
>> Bugzilla.
>
> The HDMI to VGA adapters have always been as ropey as hell on the RPi,
> in fact they were never particularly great even on the OLPCs back in
> the day either.
>
> They're also very variable from device to device so it's very much a
> case of it may or may not work but we don't really get a lot of
> reports either way these days TBH.
>
> P
I figured that was probably the case. The only thing of note I see in
the logs is:
Feb 16 00:01:21 fedora kernel: of_clk_hw_onecell_get: invalid index 15
Feb 16 00:01:21 fedora kernel: [drm:vc4_vec_bind [vc4]] *ERROR* Failed
to get clock: -2
Feb 16 00:01:21 fedora kernel: vc4-drm soc:gpu: failed to bind
3f806000.vec (ops vc4_vec_ops [vc4]): -2
Interesting that I don't see the issue on minimal.
2 years, 1 month
Re: Change in kernel PPS GPIO handling?
by Stefan Wahren
Am 05.03.22 um 12:34 schrieb Stefan Wahren:
> Am 04.03.22 um 21:50 schrieb Stefan Wahren:
>> Am 03.03.22 um 02:29 schrieb Chris Adams:
>>> Once upon a time, Stefan Wahren <stefan.wahren(a)i2se.com> said:
>>>> Hi Chris,
>>>>
>>>> Am 02.03.22 um 10:51 schrieb Peter Robinson:
>>>>>> I have an RPi4 running Fedora 35. It hadn't been updated in a while, so
>>>>>> I applied updates today. When I boot to the kernel 5.16.11-200, I lose
>>>>>> the PPS device from my GPS hat. Boot back to 5.14.16-301.fc35 and it
>>>>>> works.
>>>>>>
>>>>>> I'm booting with EFI firmware, and with a device tree config.txt that
>>>>> All our firmware are EFI, that's the only way we support booting, is
>>>>> it the default U-Boot based one or are you using the edk2 one?
>>>>>
>>>>>> has "dtoverlay=pps-gpio,gpiopin=4" in it. I removed the /boot/dtb
>>>>>> symlink and set /etc/u-boot.conf to not re-add it.
>>>>>>
>>>>>> When I boot 5.16, I see /proc/device-tree, and it has
>>>>>> /proc/device-tree/pps@4 in it (and the contents look correct), but
>>>>>> loading the pps-gpio kernel module just gives:
>>>>>>
>>>>>> pps-gpio: probe of pps@4 failed with error -22
>>>>> Any chance you can tell us which kernel it started with, 5.14.x to
>>>>> 5.16.x is a big window to debug and looking at kernel logs for
>>>>> drivers/pps there's been no changes in that space in the 5.15+ kernels
>>>>> at all.
>>>>>
>>>>> I wonder if it's a change/regression in the firmware overlay <->
>>>>> kernel interface.
>>>> do you use the DTB file from 5.14.x or 5.16x?
>>>>
>>>> I guess this is related to this commit:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?...
>>>>
>>>> Unfortunately this is a change which requires this DTS fix:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?...
>>>>
>>>> So DTB and kernel must "match".
>>> Okay, so what's the best way to do that?
>>>
>>> I have EFI firmware from https://github.com/pftf/RPi4 in /boot/efi, and
>>> the /boot/dtb symlink removed. The bcm2711-rpi-4-b.dtb file in
>>> /boot/efi is from the RPi4_UEFI_Firmware_v1.32.zip file. I have a
>>> config.txt in /boot/efi that references overlays in /boot/efi/overlays
>>> from RPM bcm283x-overlays (like pps-gpio)..
>>>
>>> I'm not quite sure how I need to fit all this together.
>> Let me recap the situation. mainline and rpi vendor tree are independent
>> in development. Synchronization (incl. device tree) happens in both
>> directions.
>>
>> U-Boot bootloader decided to keep an own copy of the mainline DT files
>> (which is currently based on an older 5.15 version which lacks the
>> gpio-ranges property). According to this statement [1] the EDK2 UEFI
>> decided to use the rpi vendor tree and don't care about the mainline DT
>> files.
>>
>> I'm sorry but as a spare-time kernel developer, i don't have to time to
>> fight against all this mess.
>>
>> I hope i will have some time for debugging in the near future ...
>>
>> [1] - https://github.com/pftf/RPi4/issues/193
>>
> Today i tried Fedora 35 Minimal for my first time, here are my test results:
>
> Raspberry Pi 400 32 bit => bus width issue
> Raspberry Pi 400 64 bit => hangs while show graphics
> Raspberry Pi 4 B 4 GB 32 bit => kernel crash
> Raspberry Pi 4 B 4 GB 64 bit => boot into setup
> Raspberry Pi 4 B 8 GB 32 bit => black screen, fails to start kernel?
> Raspberry Pi 4 B 8 GB 64 bit => boot into setup
>
> At least the 32 bit issues on Raspberry Pi 4 are expected since the
> kernel config doesn't have ARM_LPAE enabled.
>
Okay, here is the explanation for the different behavior on Raspberry Pi
400 and Raspberry Pi 4 B. The Raspberry Pi 400 has a newer BCM2711 SoC
(Stepping C0), which have less DMA restrictions for the emmc2 interface
(responsible for SD card access). For the Raspberry Pi 4 B there are
older boards which have Stepping B0 and all the new boards should have
Stepping C0 [1].
Unfortunately there is no 100% reliable way to detect the stepping from
the kernel side. So currently the Raspberry Pi firmware patches the
dma-ranges in the firmware DT [2]. So in case U-Boot [3] or another
bootloader ignores this firmware DT and read a fresh DTB the right
dma-ranges get lost. Finally this results in unexpected behavior as soon
the emmc2 switches to DMA mode [4].
Best regards
[1] -
https://www.jeffgeerling.com/blog/2021/raspberry-pi-4-model-bs-arriving-n...
[2] -
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commi...
[3] - https://forums.raspberrypi.com/viewtopic.php?t=319125
[4] - https://bugzilla.redhat.com/show_bug.cgi?id=2011423
2 years, 1 month
Re: Help getting Fedora working on my rpi3
by Eric Curtin
On Wed, 23 Feb 2022 at 11:26, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> On Wed, Feb 23, 2022 at 9:40 AM Eric Curtin <ecurtin(a)redhat.com> wrote:
> >
> > On Wed, 23 Feb 2022 at 09:02, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> > >
> > > > I'm trying to get Fedora working on my Raspberry Pi 3b+, and have some questions/issues I don't see addressed in the docs. First off, for this hardware, should I be using the aarch64 or armhfp images? I've been trying with aarch64 and that boots, but just wanted to doublecheck. Second, is it possible to get Gnome running? The "hardware status" wiki page says XFce is recommended, but it's not clear whether that means Gnome won't work, or if it's just not recommended. I tried the Workstation image and the firstboot wizard runs successfully, but then when attempting to login, gnome-shell crashes after chugging for a couple minutes and dumps me back at the gdm login screen. I tried adding 'cma=192M' to kernel args as suggested on the wiki, but no change.
> > >
> > > You should use aarch64, we're retiring armhfp post F-36. The problem
> > > with GNOME is that you need to allocate 256Mb of RAM for the GPU for
> > > it to work and then remaining ~768Mb doesn't give you a lot of space
> > > to run an OS and app. Given those constraints it works to some
> > > definition of "work".
> > >
> > > > If the answer turns out to be the Gnome isn't going to work and I have to go with Xfce, I don't see an Xfce spin built for aarch64, only armhfp, is that correct? Is that what I should be using?
> > >
> > > There is XFCE for aarch64.
> >
> > One option is to try and use the server edition which I believe
> > installs no Desktop Environment,:
> > https://getfedora.org/en/server/download/
> >
> > And install via:
> >
> > sudo dnf groupinstall "Xfce Desktop"
> >
> > Gnome 3 does work reasonably well on rpi4, but as of now I'm not sure
> > that's on Fedora's officially supported list.
>
> If by reasonably well you mean that it runs a completely unaccellated
> desktop rendered primarily on the CPU sure. The reason RPi4 is still
> not officially supported on Fedora is because the accelerated graphics
> isn't upstream, I've picked this up and are attempting to get the bits
> upstream but time will tell there.
I am grateful to hear this.
>
> Basically all RPi devices are unobtainable ATM and I don't think here
> is "go and buy more HW because the experience is less bad" is the
> right response to this thread TBH.
>
I apologize. I was trying to share that this has not been my
experience on rpi4 "gnome-shell crashes after chugging for a couple
minutes and dumps me back at the gdm login screen", but the wrong
response I understand.
2 years, 1 month
Re: Help getting Fedora working on my rpi3
by Peter Robinson
On Wed, Feb 23, 2022 at 9:40 AM Eric Curtin <ecurtin(a)redhat.com> wrote:
>
> On Wed, 23 Feb 2022 at 09:02, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> >
> > > I'm trying to get Fedora working on my Raspberry Pi 3b+, and have some questions/issues I don't see addressed in the docs. First off, for this hardware, should I be using the aarch64 or armhfp images? I've been trying with aarch64 and that boots, but just wanted to doublecheck. Second, is it possible to get Gnome running? The "hardware status" wiki page says XFce is recommended, but it's not clear whether that means Gnome won't work, or if it's just not recommended. I tried the Workstation image and the firstboot wizard runs successfully, but then when attempting to login, gnome-shell crashes after chugging for a couple minutes and dumps me back at the gdm login screen. I tried adding 'cma=192M' to kernel args as suggested on the wiki, but no change.
> >
> > You should use aarch64, we're retiring armhfp post F-36. The problem
> > with GNOME is that you need to allocate 256Mb of RAM for the GPU for
> > it to work and then remaining ~768Mb doesn't give you a lot of space
> > to run an OS and app. Given those constraints it works to some
> > definition of "work".
> >
> > > If the answer turns out to be the Gnome isn't going to work and I have to go with Xfce, I don't see an Xfce spin built for aarch64, only armhfp, is that correct? Is that what I should be using?
> >
> > There is XFCE for aarch64.
>
> One option is to try and use the server edition which I believe
> installs no Desktop Environment,:
> https://getfedora.org/en/server/download/
>
> And install via:
>
> sudo dnf groupinstall "Xfce Desktop"
>
> Gnome 3 does work reasonably well on rpi4, but as of now I'm not sure
> that's on Fedora's officially supported list.
If by reasonably well you mean that it runs a completely unaccellated
desktop rendered primarily on the CPU sure. The reason RPi4 is still
not officially supported on Fedora is because the accelerated graphics
isn't upstream, I've picked this up and are attempting to get the bits
upstream but time will tell there.
Basically all RPi devices are unobtainable ATM and I don't think here
is "go and buy more HW because the experience is less bad" is the
right response to this thread TBH.
2 years, 1 month
Re: Help getting Fedora working on my rpi3
by Eric Curtin
On Wed, 23 Feb 2022 at 09:02, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> > I'm trying to get Fedora working on my Raspberry Pi 3b+, and have some questions/issues I don't see addressed in the docs. First off, for this hardware, should I be using the aarch64 or armhfp images? I've been trying with aarch64 and that boots, but just wanted to doublecheck. Second, is it possible to get Gnome running? The "hardware status" wiki page says XFce is recommended, but it's not clear whether that means Gnome won't work, or if it's just not recommended. I tried the Workstation image and the firstboot wizard runs successfully, but then when attempting to login, gnome-shell crashes after chugging for a couple minutes and dumps me back at the gdm login screen. I tried adding 'cma=192M' to kernel args as suggested on the wiki, but no change.
>
> You should use aarch64, we're retiring armhfp post F-36. The problem
> with GNOME is that you need to allocate 256Mb of RAM for the GPU for
> it to work and then remaining ~768Mb doesn't give you a lot of space
> to run an OS and app. Given those constraints it works to some
> definition of "work".
>
> > If the answer turns out to be the Gnome isn't going to work and I have to go with Xfce, I don't see an Xfce spin built for aarch64, only armhfp, is that correct? Is that what I should be using?
>
> There is XFCE for aarch64.
One option is to try and use the server edition which I believe
installs no Desktop Environment,:
https://getfedora.org/en/server/download/
And install via:
sudo dnf groupinstall "Xfce Desktop"
Gnome 3 does work reasonably well on rpi4, but as of now I'm not sure
that's on Fedora's officially supported list.
> _______________________________________________
> 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, 1 month
Re: Raspberry Pi hardware accelerated media support
by Peter Robinson
Hi Neal,
> I was just looking up Fedora's hardware support for the Raspberry Pi
> platform vs the Raspberry Pi OS, and I noticed in the FAQ that we
> indicate that the camera and accelerated media stuff doesn't work in
> Fedora[1].
We have basic support for the old camera interface that is driven by
the firmware. The problem with that one is that it's not particularly
effective for many use cases.
When you refer to "accelerated media stuff" I'm going to assume you
mean video decode offload and not accelerated 3D rendering. They're
two completely different topics.
> I know that previously this depended on weird blobs and a fork of the
> OpenMAX libraries, but it seems today that Raspberry Pi OS' kernel
> uses v4l2 for this and has some staging drivers that seem suitable for
> upstream[2]. Taking a look at the latest in Linus' tree yields that
> most of it isn't staged there yet[3], and searching linux-arm-kernel@
> doesn't *seem* to yield any recent patch submission for them[4].
The staging drivers you reference are basically "support services" and
don't actually do anything to do with the video decode. There's been
absolutely zero work done that I am aware of to get any of the
accelerated video decoding upstream although there has been a bunch of
work down stream.
The camera on the other hand has had a recent spurt of work [2] to get
the new non firmware driver upstream which has the ability to drive
both the older gen v2 camera as well as the new higher res one so that
may actually make it sooner rather than later although it does depend
on two other v4l series of patches so soon is a relative term here.
> All of this to ask: does anyone know what the plan around this stuff
> is and when we might see this in Fedora Linux? Am I missing something
> in particular that would make this clearer, like a tracker of some
> kind or something?
The plan is we'll support it when it goes upstream, the tracker is
basically the upstream kernel.. Personally as I do all the Raspberry
Pi work in Fedora I see trackers for all this pointless as they just
end up being dumping grounds for people to say "me too" or "I really
want this" which basically I already know and provides no value as
most of this is out of our control as you need access to HW specs and
the ability to write low level drivers as well as the time to do so
which we basically don't have.
> Thanks in advance and best regards!
>
> [1]: https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#_does_the_a...
> [2]: https://github.com/raspberrypi/linux/tree/rpi-5.15.y/drivers/staging/vc04...
> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/d...
> [4]: https://lore.kernel.org/linux-arm-kernel/
[1] https://cateee.net/lkddb/web-lkddb/VIDEO_BCM2835.html
[2] https://www.spinics.net/lists/linux-media/msg206846.html
2 years, 2 months