In some reading I have no clue if it is related but a guy recompiled the rpi 5.10 kernel and he said he did this for video:
UPDATE: Video driver can be loaded by adding the dtoverlay to the uefi config.txt
DISPLAY=:0 xrandr
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767
The guy claimed this to be a guide but explained very little:
https://www.reddit.com/r/raspberry_pi/comments/gte2lp/raspberry_pi_4_uefi_boot/
I have the dtoverlay in config.txt and it worked with the Tumbleweed config. I have not been able to get it to work with the Manjaro kernel config. It very well may be that the dtoverlay is not working, it acts like thatā¦ wish I knew more than I do. I do have a /proc/device-tree/gpu so I think maybe it is getting loaded, just not sure.
Edit: There are ACPI references in the DRM codeā¦ so it could be ACPI related too.
Edit 2: And I have tried both kms and fkms, no difference as far as this issue is concerned. Both the vc4 and the v3d modules will load, just no device found as there is no message generated.
I believe the dtoverlay is for v3d. vc4 has no overlay and the vc4 is not found, so while dtoverlay may not be working, I think the issue is with the vc4.
Edit 3: I just happened to glance while building vc04-services a few warnings are generatedā¦ this is connected to one of the bcm* filesā¦ hmm. I should have built this using screenā¦ grrr.
I have pushed upgraded linux-rpi4-rc packages to the testing and unstable branches that has the wifi issue fixed. You can now use wpa_supplicant again instead of the temporary fix above.
linux-rpi4-rc 5.12.rc5-2
linux-rpi4-rc-headers 5.12.rc5-2Selecting the EFI framebuffer only, fixes the discoloration of both the raspberries and llvmpipe. But still no vc4 deviceā¦ evidently not related. Going to try now with only the bcm2708 frame buffer selected.
Edit: vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB)
Command line on normal install:
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@60 smsc95xx.macaddr=DC:A6:32:BB:1C:0C vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=1 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 usbhid.mousepoll=8 audit=0
This part is not passed to my UEFI kernel:
vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000
Edit: I added the above to the UEFI kernel command line. vc-mem now shows the correct values, however, still no vc4.
I captured the compile warning this time, I do not think it is related. I think the v4l2 is for video decoding.
In file included from ./include/media/v4l2-subdev.h:15,
from ./include/media/v4l2-device.h:13,
from drivers/staging/vc04_services/bcm2835-isp/bcm2835-v4l2-isp.c:15:
drivers/staging/vc04_services/bcm2835-isp/bcm2835-v4l2-isp.c: In function ābcm2835_isp_get_supported_fmtsā:
./include/linux/kern_levels.h:5:18: warning: format ā%uā expects argument of type āunsigned intā, but argument 4 has type ālong unsigned intā [-Wformat=]
5 | #define KERN_SOH "\001" /* ASCII Start Of Header */
| ^~~~~~
./include/media/v4l2-common.h:58:9: note: in definition of macro āv4l2_printkā
58 | printk(level "%s: " fmt, (dev)->name , ## arg)
| ^~~~~
./include/linux/kern_levels.h:11:18: note: in expansion of macro āKERN_SOHā
11 | #define KERN_ERR KERN_SOH "3" /* error conditions */
| ^~~~~~~~
./include/media/v4l2-common.h:61:14: note: in expansion of macro āKERN_ERRā
61 | v4l2_printk(KERN_ERR, dev, fmt , ## arg)
| ^~~~~~~~
drivers/staging/vc04_services/bcm2835-isp/bcm2835-v4l2-isp.c:1237:4: note: in expansion of macro āv4l2_errā
1237 | v4l2_err(&dev->v4l2_dev,
| ^~~~~~~~
CC [M] drivers/media/dvb-frontends/rtl2832.o
Edit: I modified the cma value and that change is not reflected in dmesg. It continues to default cma to 64MB. I think this is further evidence that the dtoverlay=vc4-kms-v3d-pi4,cma-512 is not working properly, or at all for UEFI. My efforts continue.
The bcm2708 framebuffer does function. No raspberries but the colors are wonky again in llvmpipe. So it would seem the best framebuffer for UEFI is indeed the EFI framebuffer. That much figured out. 
The vc_mem settings could be the issueā¦ but these addresses are not set in stone. How do I find out what addresses I need for EFI? Could be the same, dunno.
I ran into the other day testing the new kodi that if any value was set with gpu_mem= then vc4-kms-v3d-pi4,cma-512 would not get assigned. This is with fbturbo being disabled. I also noticed I had to use vc4-kms-v3d as with the -pi4 nothing worked right for some reason.
If you do test with fbturbo enabled then have gpu_mem=512 and use vc4-fkms-v3d only.
Thanksā¦ I was planning to test with vc4-kms-v3d and I do recall reading about removing gpu_mem for kodi, worth a try for sure. I also have found 0x3ec00000 and 0x40000000 respectively for RPi4, so I will give that a try too.
Typo? vc4-fkms-v3d or vc4-kms-v3d-pi4?
That line is for if you are going to test with fbturbo enabled only.
When using fbturbo gpu mem uses gpu_mem=. With out fbturbo enabled then gpu mem uses cma.
But there is no vc4-fkms-v3d-pi4.dbto file. Just fkms without the -pi4 or kms with -pi4.
Am I missing an overlay file?
You are right. I changed the post
This is from the Tumbleweed image (as downloaded), kernel 5.11.6:
linux:~ # dmesg | grep vc
[ 67.690720] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[ 67.695599] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[ 67.696056] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[ 67.702280] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[ 67.702460] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 67.702586] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[ 67.702675] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 67.702751] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 67.702828] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 67.702892] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 67.702964] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 67.703162] fb0: switching to vc4drmfb from EFI VGA
[ 67.727492] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[ 67.837180] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
linux:~ # dmesg | grep fb
[ 8.136079] efifb: probing for efifb
[ 8.136402] efifb: framebuffer at 0x3e2fe000, using 8100k, total 8100k
[ 8.136413] efifb: mode is 1920x1080x32, linelength=7680, pages=1
[ 8.136423] efifb: scrolling: redraw
[ 8.136428] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 8.157932] fb0: EFI VGA frame buffer device
[ 67.703162] fb0: switching to vc4drmfb from EFI VGA
[ 67.837180] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
They use the efi fb, good, works for me too. Quite a few messages from the loading of vc4-drm. But nothing about vc_mem at all. This is all so confusing.
And I just now found this thread. So vc_mem was a red herring.
And I am back to having no clue why the gpu is not being detected. Iāll mess around a bit with the config.txt but I have already tried many changes.
And as for overlaysā¦ I have the argononed 3rd party dtoverlay loaded and it uses multiple dtparams and it worksā¦ once I got the device tree passed. This is why the vc4 is so perplexingā¦ the vc4 must be in the device-tree, there is no overlay, no parameters are passed to the kernel, and the kernel seems to be configured properly.
Iāll try with mkinicpio, maybe dracut is failing me.
Edit: I tried taking a look at Fedora 34 betaā¦ which uses the 5.11.11 kernel after the updates. They too can successfully load the vc4 driver, but that is about it. They are still using u-boot and llvmpipe, and so far I have been unsuccessful doing anything else with it.
Edit: Tried Arch ARM but it wonāt boot, timeout waiting on the SD drive. rtfm
The larger distros compile most everything but do not compile the v3d moduleā¦ kind of weird. Even Arch ARM ignores it, which surprised me.
@Darksky This statement is more true than I imagined, when I typed it. I sure hope you have not been wasting too much time thinking about my issueā¦ if so, I sincerely apologize.
The issue was most of my overlay files were zero blocks (most beginning with āaā were fine). My argonone overlay was fine, so it workedā¦ I never gave the overlay files themselves a second thought.
Your EFI bootable kernel works, and I thank you very much.
$ uname -a; glxinfo | grep āOpenGL renderā
Linux abbynormal 5.12.0-rc5-2-MANJARO-ARM #1 SMP PREEMPT Wed Mar 31 07:28:48 CDT 2021 aarch64 GNU/Linux
OpenGL renderer string: V3D 4.2
Edit: And I will add, that I like this setup quite a bit, it will be my new daily driver.
Glad you got it working. You need to open up a thread as a guide after you get all of your thoughts together so others that want to pursue your adventure can have a separate thread to work with getting it to work.
I wonder why the vc4 depended on the overlay files? I assumed the bcm2711-rpi-4-b.dtb would have the vc4 definition, along with all of the on-board hardware.
Edit: I consider the system to have been in an invalid state, so I wonāt lose sleep over this.
The command /opt/vc/bin/dtoverlay -l does not behave as I expected.
It returns that I have no overlays loaded, but I do have the vc4-kms-v3d-pi4 overlay loaded.
Does this only work if used in userspace to load an overlay?
What I am after is a way to āchangeā the device tree, to be able to switch it when a kernel is selected via grub. To effectively āreplaceā the device tree assembled by start4.elf. I believe grub supports passing a .dbt, so I think maybe I can āswapā the .dbt on the flyā¦ maybe, hopefully.
While an older device tree should work with a newer kernel, I would prefer to load the appropriate .dbt with the selected kernel. I think this is possible. But then I would need to apply the overlays, which I think /opt/vc/bin/dtoverlay can doā¦ maybe.
Edit: Ok, I think that I have confirmed this. I removed the argonone overlay from config.txt and disabled the service and rebooted. I then loaded the overlay with /opt/bin/dtoverlay and started argononed, it works. So this is all in user space, what loads with the kernel is outside of the scope of the utility.
Seems so:
Note:
dtoverlay -lonly lists dynamically loaded modules and only those can be removed withdtoverlay -r. Anything that was loaded via/boot/config.txtis considered part of the base device tree. Some overlays have to be added this way and canāt be loaded bydtoverlay.
Ah, excellent, thank you for confirmingā¦ now, if only the vc4-kms-v3d-pi4 will allow dynamic loading. But if not, llvmpipe works pretty well. I could live without v3d for this.
Next up is the grub/dtb swap test.
Edit: Hmm, how to know if I successfully loaded a different device tree?
Edit 2: Well, possibly a properly constructed devicetree might work. I was sort of successful in loading a new DBT via grub. It booted and all was not correct, so I know I am overriding the dbt by start4.elf. But when I loaded the vc4-kms-v3d-pi4 overlay via the dtoverlay command, I lost video.
Why are you using vc4-kms-v3d-pi4 instead of vc4-kms-v3d. I had issues here using vc4-kms-v3d-pi4 not loading things up right when I was testing kodi. The pi people in the past said to use vc4-kms-v3d instead.
As I understand it, the overlay_map loads vc4-kms-v3d-pi4, if you use vc4-kms-v3d on a RPi4. But I could be wrong. More specifically, I have not found an instance where vc4-kms-v3d works while vc4-kms-v3d-pi4 fails. But no really good reason, I just kind of got in the habit of using -pi4.
Rename the .dtb (assuming what you meant ). Here I added -512 for 5.12 kernel.
device_tree=bcm2711-rpi-4-b-512.dtb