Fedora 33 Workstation on the RPI4 with UEFI runs fine for me. However, I can't figure out how to get accelerated video working. Without UEFI, Fedora 33 with kernel 5.10.7 seems to enable accelerated video without any further configuration. There is a /boot/efi/config.txt in this case. It contains things like
gpu_mem=32 start_x=1 upstream_kernel=1 dtoverlay=upstream mask_gpu_interrupt1=0x100
Where would one put these setttings for UEFI boot?
Thanks. Eberhard
Fedora 33 Workstation on the RPI4 with UEFI runs fine for me. However, I can't figure out how to get accelerated video working. Without UEFI, Fedora 33 with kernel 5.10.7 seems to enable accelerated video without any further configuration. There is a /boot/efi/config.txt in this case. It contains things like
gpu_mem=32 start_x=1 upstream_kernel=1 dtoverlay=upstream mask_gpu_interrupt1=0x100
Where would one put these setttings for UEFI boot?
So you'd follow this guide below for DT overlay support in Fedora [1] but the upstream DT should enable this by default so if it's working and complete it should "just work" . The thing to note that vc4 is but one of the components around acceleration on the RPi4.
The way SoCs work when it comes to the build in graphics that we see on a more tradition host where we see a self contained GPU that handles it all as one is that the bits that are used to form the display pipeline. On the older RPis the vc4 driver handled both the rendering unit, the display engine (bits that take the rendered bits and prepare them to be blitted to the outputs) and the outputs such as HDMI or DSI.
The RPi4 has changed this up some and the 3D render unit is now driven by the v3d component and associated driver, and the display engine and bridges such as HDMI are driven by the vc4 component.
The vc4 work landed upstream in 5.10 but the v3d components haven't as yet, so there is potentially the possibility to have some improvements there but I'm not sure how much of it actually works and if all of it is there from the vc4 side and if not what is missing. I've briefly looked but I've not had time to debug it as yet because as far as I'm concerned accelerated graphics on the rpi4 is unsupported in F-33 and is still under consideration for F-34.
ATM I'm focusing on other things like early boot and actually making the USB work consistently.
Peter
[1] https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/H...
Thanks for the explanations and the link. As I wrote it works out of the box when doing a *non* UEFI install. My question, however, is about an installation that uses the RPI UEFI firmware. I tried things like enabling devicetree in the UEFI menu and also what's described in the Peter's link [1], but to no avail. Has anybody managed to get the vc4 stuff working with an UEFI install? Eberhard
On Fri, Jan 15, 2021 at 8:12 PM Eberhard Schruefer eschruefer@ca-musings.de wrote:
Thanks for the explanations and the link. As I wrote it works out of the box when doing a *non* UEFI install. My question, however, is about an installation that uses the RPI UEFI firmware. I tried things like enabling devicetree in the UEFI menu and also what's described in the Peter's link [1], but to no avail. Has anybody managed to get the vc4 stuff working with an UEFI install?
When you say "UEFI install" do you mean the Tianocore firmware? Because the standard Fedora uses UEFI via U-Boot. So you need to clarify there.
Sorry for not being clear. Yes, I mean the Tianocore firmware.
So I've added Jeremy to my reply as he's the maintainer of this firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not sure it's intended to work.
As the driver would need ACPI support and the firmware would need the appropriate ACPI tables to describe the hardware. I'm not sure what the plans there are for support for the GPU on that firmware is, the timeline or if there is any plans there.
Peter
Hi,
On 1/15/21 2:29 PM, Peter Robinson wrote:
Sorry for not being clear. Yes, I mean the Tianocore firmware.
So I've added Jeremy to my reply as he's the maintainer of this firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not sure it's intended to work.
As the driver would need ACPI support and the firmware would need the appropriate ACPI tables to describe the hardware. I'm not sure what the plans there are for support for the GPU on that firmware is, the timeline or if there is any plans there.
Plans yes, no dates.
I would suggest that if it works with a mainline overlay it should be possible to put that in the overlay's directory and add it to the config.txt and change it from ACPI->DT in the firmware. But.. at the moment you also should probably make sure your also changing the SD config for DT too (it will be in the next release).
So at the moment your sorta going to have to hack it on your own, the few of us patching the uefi firmware have our hands full with various boot failures that have crept up over the last month too :(
(PXE, USB and SD failures have been burning most of my spare time, did you know people were iscsi booting the rpi too? LOL)
(PXE, USB and SD failures have been burning most of my spare time,
did you know people were iscsi booting the rpi too? LOL)
Hi, for us we are iScsi booting our Arm servers (ThunderX2, Kunpeng 920, A64FX) and found a few things needed fixing in PXE too.
So, yes only fair the RPi gets the opportunity too.
Paul.
On Fri, 2021-01-15 at 17:21 -0600, Jeremy Linton wrote:
Hi,
On 1/15/21 2:29 PM, Peter Robinson wrote:
Sorry for not being clear. Yes, I mean the Tianocore firmware.
So I've added Jeremy to my reply as he's the maintainer of this firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not sure it's intended to work.
As the driver would need ACPI support and the firmware would need the appropriate ACPI tables to describe the hardware. I'm not sure what the plans there are for support for the GPU on that firmware is, the timeline or if there is any plans there.
Plans yes, no dates.
I would suggest that if it works with a mainline overlay it should be possible to put that in the overlay's directory and add it to the config.txt and change it from ACPI->DT in the firmware. But.. at the moment you also should probably make sure your also changing the SD config for DT too (it will be in the next release).
So at the moment your sorta going to have to hack it on your own, the few of us patching the uefi firmware have our hands full with various boot failures that have crept up over the last month too :(
(PXE, USB and SD failures have been burning most of my spare time, did you know people were iscsi booting the rpi too? LOL) _______________________________________________ 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
Hi,
On 1/15/21 2:29 PM, Peter Robinson wrote:
Sorry for not being clear. Yes, I mean the Tianocore firmware.
So I've added Jeremy to my reply as he's the maintainer of this firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not sure it's intended to work.
As the driver would need ACPI support and the firmware would need the appropriate ACPI tables to describe the hardware. I'm not sure what the plans there are for support for the GPU on that firmware is, the timeline or if there is any plans there.
There are plans but no dates. :) So, no it doesn't work at the moment.
As mentioned putting the dt overlays/etc on the sd card and flipping it to DT mode to see if that works is a good place to start if you want to try getting it working. Although if your also trying to boot from SD you will need to wait until the next firmware release to also use wifi/etc because the default DTs don't entirely know how to change the SD/Wifi pin routing.
I think the half dozen or so of us fixing stuff on that platform also have our hands full with various boot failures at the moment. Once that gets cleared up we can start looking at further ACPI functionality extensions.
I would suggest opening a bug on the github page, and/or jumping on the discord channel.
Thanks for your input and all the work you have done! When I find time I might still try various things and if successful, I will report back. For the time being I will simply use the rpi as a headless machine and wait until this is ready on your site. Eberhard
So, I've come to this mail list specifically for this topic and I'm reading this now and learning I have to try that myself. Basically I was hoping installing mesa-20.3 which is having VC4 support is going to just get the correct driver running, but it didn't. I tried along all possible mixes of `dtoverlay` values and other things for `dtb` and `u-boot` but I only bricked two fedora installations without luck at all.
Are there any other things that I might give a shot with? For reference Manjaro ARM got gpu support on RPi 4 just with mesa-20.3, is there anything I can copy over from Manjaro ARM for testing purposes?
Am 15.01.21 um 20:21 schrieb Peter Robinson:
The RPi4 has changed this up some and the 3D render unit is now driven by the v3d component and associated driver, and the display engine and bridges such as HDMI are driven by the vc4 component.
The vc4 work landed upstream in 5.10 but the v3d components haven't as yet, so there is potentially the possibility to have some improvements there but I'm not sure how much of it actually works and if all of it is there from the vc4 side and if not what is missing. I've briefly looked but I've not had time to debug it as yet because as far as I'm concerned accelerated graphics on the rpi4 is unsupported in F-33 and is still under consideration for F-34.
The upstream v3d driver isn't ready for bcm2711 yet. In order to support Nicolas (current RPi-kernel maintainer), i send some minor patches to the kernel mailing list [1] during the holidays, which have been accepted. But there is more work to do like adapting the bcm2835-power driver for bcm2711 (incl. v3d support).
Regards Stefan
[1] - https://lore.kernel.org/dri-devel/20210106150929.qsyuosde6i5q3isc@gilmour/T/
On Fri, Jan 22, 2021 at 7:51 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Am 15.01.21 um 20:21 schrieb Peter Robinson:
The RPi4 has changed this up some and the 3D render unit is now driven by the v3d component and associated driver, and the display engine and bridges such as HDMI are driven by the vc4 component.
The vc4 work landed upstream in 5.10 but the v3d components haven't as yet, so there is potentially the possibility to have some improvements there but I'm not sure how much of it actually works and if all of it is there from the vc4 side and if not what is missing. I've briefly looked but I've not had time to debug it as yet because as far as I'm concerned accelerated graphics on the rpi4 is unsupported in F-33 and is still under consideration for F-34.
The upstream v3d driver isn't ready for bcm2711 yet. In order to support Nicolas (current RPi-kernel maintainer), i send some minor patches to the kernel mailing list [1] during the holidays, which have been accepted. But there is more work to do like adapting the bcm2835-power driver for bcm2711 (incl. v3d support).
Thanks for the update Stefan, that's useful.
Peter
-
Eberhard Schruefer -
Jeremy Linton -
Mahmoud Abduljawad -
paul.isaacs＠linaro.org -
Peter Robinson -
Stefan Wahren