Got it. It is compiling now.
1 Like
I posed the question of if v3d should work with upstream 5.16 in the rpi forums. Letâs see if I get a legit response, I wonât hold my breath.
As a note, I wonder if disable_fw_kms_setup=1 would be of help.
So far the v3d modules are not loading. Getting close to me having to leave.
500 new lines of code and still no luck? Grrr
If basic v3d is not working⌠why the code changes for v3dv? Just does not make sense to me.
One would think by enabling v3d it would pull in all that was needed. All of that Q&A when it dropped to the command line should have what was needed. I am cross compiling now with âmake defconfigâ using a fresh tree and no manjaro configs involved at all. I had to enable v3d but it did not jump to the command line with Q&Aâs. I also had to increase the cma from 32 to 256.
I read in some post, that the upstream kernel kms was picky about the EDID and would just quit, if it did not like it.
There must be some way to get it to work, or this commit that landed in 5.15 would make no sense at all, it adds userspace performance monitoring. And the kernel docs make no mention of vc4 or v3d not working. But then again, I have zero evidence of it actually working.
Edit: And the Mesa docs have only this to say concerning the vc4: (rpi verses upstream)
âMesaâs vc4 graphics driver supports multiple implementations of Broadcomâs VideoCore IV GPU. It is notably used in the Raspberry Pi 0 through Raspberry Pi 3 hardware, and the driver is included as an option as of the 2016-02-09 Rasbpian release using raspi-config. On most other distributions such as Debian or Fedora, you need no configuration to enable the driver.â
No reference to the rpi kernel patches for the vc4 or v3d, at least that I can find.
After downloading the 3.8GB file and installing Fedora 35, I find that CONFIG_DRM_V3D=m is not set in the kernel config that is installed with the aarch64 image. They do use vc4 + llvmpipe but not v3d.
Edit: So again, v3d does not seem to be used by any distro using the upstream kernel⌠yet patches and docs all seem to indicate it works. And still no response to my rpi forum post.
I never did get v3d modules to load up.
I am beginning to wonder if it is preliminary work in the kernel.
Ok, seems maybe I have an answer⌠I donât like it, but it is what it is.
There is no way v3d will work on the rpi4 until this file adds the bcm2711:
v3d_drv.c
static const struct of_device_id v3d_of_match[] = {
{ .compatible = "brcm,7268-v3d" },
{ .compatible = "brcm,7278-v3d" },
+ { .compatible = "brcm,2711-v3d" },
{},
};
It seems the bcm7268 and bcm7278 exist somewhere in the world, and they use the v3d driver. The v3d code was written for them, NOT the bcm2711. From what I gather, the biggest sticking point is making a compatible bcm2711_power module (kms related). So it would seem that v3d on the rpi4, with the upstream kernel, is not even close at this point.
1 Like
I currently get these errors when attempting to load the vc4 module with 5.16.2-3-MANJARO-ARM.
$ sudo dmesg
[ 9.024005] of_clk_hw_onecell_get: invalid index 4
[ 9.024045] vc4_hvs fe400000.hvs: Couldn't get core clock
[ 9.024075] vc4-drm gpu: failed to bind fe400000.hvs (ops vc4_hvs_ops [vc4]): -2
[ 9.024363] vc4-drm gpu: master bind failed: -2
[ 9.024402] vc4-drm: probe of gpu failed with error -2
The vc4 module loads, but does not get used:
$ lsmod | grep vc4
vc4 245760 0
cec 73728 1 vc4
drm_kms_helper 286720 1 vc4
drm 606208 2 drm_kms_helper,vc4
I have tried with both the upstream and the rpi device -tree, same results.
I have been seeing that also messing with the v3d stuff. I think something changed with 5.16.2 upstream. There are reported issues with it in the arch-arm forums. Have you done an upgrade on the unstable branch? The kernel has changed with using compressed firmware.
I am up-to-date on the latest unstable. Changes⌠sheesh. I was hoping the vanilla kernel would have fewer breaking changes.
Edit: Well, not broken as software rendering works, just no vc4 atm.
I went back to 5.16.0 and tested 5.17.0-rc1 and they both have those errors. Have they been there all along?
@0n0w1c Here is the upstream 5.17.0-rc1 kernel I compiled today if you want to play with it. It is on hold from being in the repo for some compile issues with a device some other boards have. The pi4 is not affected with this. This will not work on other devices as I have removed all patches that concerns other boards.
https://drive.google.com/file/d/1VGO1PsxNy3utepwGC5kcsxuSOKjOP8hN/view?usp=sharing
I tried going back a version and it had the error. I have tried so many things, not sure about when the errors. I know that I have had vc4 working on the upstream. Sort of confused about it.
With an rpi kernel, this is what loading the vc4 looks like:
$ dmesg | grep vc4
[ 5.779780] fb0: switching to vc4drmfb from simple
[ 5.819978] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 5.823480] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 5.823580] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input6
[ 5.855212] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 5.871094] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 5.871187] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input7
[ 5.875529] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[ 5.907346] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[ 5.907585] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input8
[ 5.922277] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[ 5.922472] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[ 5.922600] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.922720] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.922830] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.922919] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.923038] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.927148] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[ 6.039057] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
I notice the addresses are different with the rpi4 kernel.
If you look at the second post up above, I had vc4 working and I was futilely trying to get the headphones working. So we know it worked then.
Same error with 5.17.0-rc1-1.
I suppose this could be due to a change in the bootloader. It looks like the version that vc4 worked was 5.16.1-1. That is the version I re-tried, and vc4 failed.
It is the bootloader. If I rollback to the 20220104 version and reboot, vc4 works. Currently with 5.17-0-rc1-1, but I am sure it will work with 5.16 too.
1 Like