RPi4B goes to black screen with vc4-kms-v3d after commit#1e494f1

[yullaw]

Decription of issue:
RPi4B goes to the black screen of TV LG 42LK450-ZB (2012). The booting process with 4 raspberries is visible, after that the black screen only. The TV doesn't complain about "No signal", the GUI sound can be hear (test with LibreELEC 10.0.1). With RPiOS Lite doesn't appear the CLI with login.

How to reproduce:

• fresh install 2021-05-07-raspios-buster-armhf-lite.zip
• CLI with login reached
• sudo apt update
• sudo apt full-upgrade
• sudo rpi-update
• reboot
• CLI and login reached
• card removed and config.txt modified from dtoverlay=vc4-fkms-v3d to dtoverlay=vc4-kms-v3d
• card inserted back, booting with 4 raspberries appeared, then it goes to black screen
• on TV selected HDMI1 and then HDMI3 back where the RPi4B is connected to -> CLI and login reached

Up to the commit#beeeb4f working fine and CLI/GUI reached.
After the commit#1e494f1 the CLI/GUI is not reached.

• sudo rpi-update 1e494f150046bd04331ab0b19e4e5322eb7b7773
• reboot
• no login in CLI
• on the TV select different HDMI port and go back to original HDMI

For more details please see the discussion with all logs and results:

• https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0/?postID=162536#post162536

Many thanks

[zehnerGIT]

Is the root cause for this issue and #1648 the same?

More and more LibreELEC users (including me) are affected by this problem and all communication is in the other issue

[popcornmix]

Is the root cause for this issue and #1648 the same?

It doesn't sound like it as the linked issue was due to using OpenMAX (firmware side) hdmi audio when kms was enabled (kernel side hdmi video). LibreELEC has never shipped a build that mixes the two.

[popcornmix]

@yullaw I've had difficulty reproducing this. Can you post your edid?

base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid

Can you reproduce issue without hdmi attached? Assuming, say your monitor defaults to 1920x1080@60 when working,
then add to /boot/cmdline.txt (on same line) video=HDMI-A-1:1920x1080@60D

Test first with monitor attached and working firmware and check all is good.
Test next with monitor attached and non-working firmware and check it fails.
Now check with monitor unplugged. If it still fails then it should be easier to reproduce.

[yullaw]

@popcornmix :

• fresh install 2021-05-07-raspios-buster-armhf-lite.zip
  pi@raspberrypi:~ $ base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid AP///////wAebQEAAQEBAQEVAQOAEAl4Cu6Ro1RMmSYPUFShCABxT4GAAQEBAQEBAQEBAQEBAjqA GHE4LUBYLEUAoFoAAAAeGyFQoFEAHjBIiDUAoFoAAAAcAAAA/QA6Ph5TEAAKICAgICAgAAAA/ABM RyBUVgogICAgICAgAeICAybxThAfhBMFFAMCEiAhIhUBJhUHUAlXB2cDDAAwALgt4wUDAQEdgBhx HBYgWCwlAKBaAAAAngEdAHJR0B4gbihVAKBaAAAAHgI6gBhxOC1AWCxFAKBaAAAAHgEdALxS0B4g uChVQKBaAAAAHgAAAAAAAAAAAAAAAAAAAAAAeQ==

sudo apt update|tee update.txt update.txt
sudo apt full-upgrade|tee full-upgrade.txt full-upgrade.txt
sudo reboot
sudo rpi-update|tee rpi-update.txt rpi-update.txt
sudo reboot

• video=HDMI-A-1:1920x1080@60D inserted to /boot/cmdline.txt in the same line
• the CLI and login is appeared after reboot
• config.txt modified from dtoverlay=vc4-fkms-v3d to dtoverlay=vc4-kms-v3d
• black TV screen
• dmesg|tee dmesg.txt dmesg.txt
• modetest|tee modetest.txt modetest.txt
• video=HDMI-A-1:1920x1080@60D removed from /boot/cmdline.txt
• after reboot -> black TV screen
• config.txt reverted and reboot -> all good!

Firmware update to the latest version:
sudo rpi-update 5dc3fda106fb65f8b377bb8072453081b455dd5f|tee rpi-update_5dc3fda.txt rpi-update_5dc3fda.txt
it is already up-to-date...

• config.txt modified from dtoverlay=vc4-fkms-v3d to dtoverlay=vc4-kms-v3d

Firmware downgrade to beeeb4f - rpi-update_beeeb4f.txt:

• sudo rpi-update beeeb4f8b63ee819f1a701cf6189daabb35dcf42|tee rpi-update_beeeb4f.txt
• all good!

All outputs from the command line you can find in the attachment.

[popcornmix]

Did you test with latest firmware, video=HDMI-A-1:1920x1080@60D and hdmi cable unplugged?
I assume you can test whether it is happy or not by ssh-ing in and checking dmesg.

[yullaw]

@popcornmix

• video=HDMI-A-1:1920x1080@60D is in cmdline.txt
• config.txt with dtoverlay=vc4-kms-v3d
• update to latest firmware
• HDMI cable is unplugged
• power cable out/in
• dmesg|tee dmesg_2.txt dmesg_2.txt

Please guide me

[popcornmix]

I would say that is working. Plug in hdmi at this point - do you get an image?
Now reboot and ssh in and run dmesg. Are there errors?

[yullaw]

@popcornmix

• HDMI cable plugged in -> I get the image
• reboot
• no image
• dmesg_3.txt

[popcornmix]

In the last case does unplugging and replugging hdmi have any effect?

Not seeing much difference in demsg for working vs not working.
I'd like you to get the failing case without the monitor plugged in (which I don't think you have yet), which means it's more likely to be reproducible without your specific display.

Can you:

sudo cp /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid /lib/firmware/edid.dat

and add to cmdline.txt drm.edid_firmware=edid.dat (in addition to video= line).

Reboot with hdmi unplugged. ssh in get dmesg. Try pluggin in hdmi.

[yullaw]

If I unplug/plug in the HDMI cable, no new lines in dmesg. No image so far. If I change HDMI source on the TV and go back, I do have the image.

sudo cp /sys/devices/platform/gpu/drm/card0/card0-HDMI-A-1/edid /lib/firmware/edid.dat

rebooted.
dmesg_4.txt

[popcornmix]

When you captured dmesg_4.txt, that was with hdmi unplugged? Was screen blank when plugged in? Did picture appear with either subsequent unplug/replug or change of HDMI source?

If I change HDMI source on the TV and go back, I do have the image.

So, without any changes but using latest rpi-update firmware, you normally boot to a blank screen. Does switching HDMI source make image come back in this case?

[yullaw]

Yes, the HDMI cable was unplugged. Now I plugged in and got the image. 3 times plugged out/in -> I have image always

In case when I do not reach the image (after reboot), I have to solve it by changing of the HDMI source on TV

[yullaw]

Next test:

• power cable and HDMI cable of RPi4B unplugged , TV is turned off
• turn on TV and select the correct HDMI source ("No signal" appeared)
• plug in power cable (and wait until the green led is not flashing)
• plug in the HDMI cable
• image reached!

It looks like the TV needs to be "refreshed" for a signal coming from RPi4B with the latest firmware.

But all is working fine until the firmware beeeb4f

I understand that we need to catch the error message. No luck.

[yullaw]

@popcornmix : New day, new idea brings better results

New procedure:

• new image 2021-10-30-raspios-bullseye-armhf-lite.zip fresh installed on a brind new 32GB card
• after appeared partition resizing and auto reboot immediately it goes to a black screen
• manually on TV via controller it was switched from HDMI 3 to HDMI 1 and go back to HDMI 3, an image is reached
• ssh enabled in raspi-config
• after reboot (3 times repeated to be sure) via ssh, no luck - no image
• via ssh modify the cmdline.txt (add video=HDMI-A-1:1920x1080@60D drm.debug=0x04) and checked config.txt for dtoverlay=vc4-kms-v3d
• then I played with the configuration in raspi-config:
  Display Options -> Underscan -> Enable
  Display Options -> Pixel Doubling -> Enable
  Display Options -> Screen Blanking -> Enable
  Finish -> Reboot

Please note that the change into "Display Options" the effect is unstable, sometime the effect is reached, sometime not. However it helps to reach the image after reboot.
During that modify these outputs are listed:
pi@raspberrypi:~ $ sudo raspi-config
/usr/bin/raspi-config: 443: xrandr: not found
dpkg-query: no packages found matching xscreensaver

Image with a login reached! Ok, then the logs saved
journalctl-k_working_image.txt
dmesg_working_image.txt

The HDMI was disconnected and connected, the image was back, logs with follows:
journalctl-k_working_image_after_replug.txt
dmesg_working_image_after_replug.txt

Then reboot via ssh again, no image with follows:
journalctl-k_nonworking_image.txt
dmesg_nonworking_image_after_reboot.txt

The HDMI was disconnected and connected, no image:
journalctl-k_nonworking_image_after_replug.txt
dmesg_nonworking_image_after_reboot_replug.txt

I hope now you can see better, what could be wrong.

EDIT:
Comparing the journalctl logs:
in working - no line with
Finished Apply Kernel Variables
brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

in nonworking included:
Finished Apply Kernel Variables
brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

can it be something to do with this issue?

[yullaw]

@popcornmix: Still I confirm, that the firmware:

• ≤ commit#beeeb4f working fine, multiple soft reboots via ssh and the image reached always
• ≥ commit#1e494f1 is not working, multile soft reboots via ssh, the image is reached ramdomly (e.g. 10 reboots -> 2 times CLI reached)

even the RaspiOS Bullseye Lite (eeprom, bootloader) is fully upgraded.

[yullaw]

@popcornmix: EDID of the TV was uploaded to https://edid.tv/edid/1150/

[yullaw]

@popcornmix:

Working way:

• For the resolution of Rainbow cube + 4 Raspberries with boot process:
  add to /boot/config.txt:
  hdmi_group=1
hdmi_mode=20 or just 1

• For next resolution is controled by video=HDMI-A-1:1920x1080@60D in cmdline.txt or using EDID.

• The CLI and login is reached always.

Both modes control its resolution separately. The first resolution affects the later resolution, that it means if any hdmi_group and hdmi_mode is existing, the second resolution is not "set" and black screen only.

Also it works for me to solve the LibreELEC ( see comment on LibreELEC )

[macmpi]

Got pretty much similar symptom out a PiZero 1.3 with 2022-01-28-raspios-bullseye-armhf-lite and kernel 5.15.16.

Pi hdmi linked to Sony TV: CLI and login are displayed on screen.
Pi hdmi is linked to Yamaha HDMI amp, which then is linked to same TV: screen goes black after ttyAMA0 related boot message.

Copied edid firmware files into /lib/firmware/, and tried the video=HDMI-A-1:1280x1024@60D and drm.edid_firmware=edid.dat trick in second case with no more success. Note edid file was in a sligtly different location:
/sys/devices/platform/soc/soc\:gpu/drm/card0/card0-HDMI-A-1/edid
Amp with TV: https://edid.tv/edid/1333/
TV only: https://edid.tv/edid/1334/

Have to say alsa audio is also an issue, even in the first use-case (pi direct to TV):
speaker-test -c2 -twav -l7 plays the left part, but not the right part
When connected to Amp, it does not play anything :(
With legacy setup (no v4-kms-v3d and dtparam=audio=on) any setup did work fine.

Appreciate any clue to get amp configuration working (including alsa audio).

[popcornmix]

Copied edid firmware files into /lib/firmware

did you do this when display was working (directly connected to TV without AVR)?

[macmpi]

did you do this when display was working (directly connected to TV without AVR)?

Yes, in both cases, all devices connected and powered-on.
On edid.tv site, we can see the difference AVR introduces to screen spec (TV alone is 4K, but AVR is not)

[popcornmix]

Does edid look correct? e.g. compare
md5sum /sys/devices/platform/soc/soc\:gpu/drm/card0/card0-HDMI-A-1/edid

when you are booted with no display (AVR connected) and video=HDMI-A-1:1280x1024@60D and drm.edid_firmware=edid.dat.

And then run again with the config.txt lines removed and directly connected to TV?

In first of these cases, does switching the Pi's hdmi connection directly to TV produce an image? (i.e. after booting with no image, unplug hdmi cable from AVR input and insert into TV).

[macmpi]

In first of these cases, does switching the Pi's hdmi connection directly to TV produce an image? (i.e. after booting with no image, unplug hdmi cable from AVR input and insert into TV).

Yes, it does! with video=HDMI-A-1:1280x1024@60D drm.edid_firmware=AVRedid.dat
It now also works if I connect TV to AVR, and... audio too! (got up to 1920x1080@60D)
Thanks so much!

Edid files are different in 3 cases (I posted files on edid.tv site in case it can help):
AVR+TV: https://edid.tv/edid/1333/
TV only: https://edid.tv/edid/1334/
AVR only: https://edid.tv/edid/1335/

It is more sensitive to tweak than with legacy gpu: any chance this edid debunking will not be necessary in a close future?
A detailed how-to guide would definitely help.

[popcornmix]

If you have drm.edid_firmware=AVRedid.dat specified then you should see the same edid whatever you are connected to (the contents of the AVRedid.dat file).
If you are seeing different edid's, then it sounds like it's not being loaded correctly.
You have the edid file here: /lib/firmware/AVRedid.dat? Can you post dmesg output (which should show success or failure to read this file).

[macmpi]

If you have drm.edid_firmware=AVRedid.dat specified then you should see the same edid whatever you are connected to (the contents of the AVRedid.dat file).

Yes indeed, that's the case: it's all good.
My comment on other edid.dat was just a recap of previous trials: sorry for the confusion.

Now, in pre vc4-kms-v3d situation, I could set hdmi_safe=1 in config.txt and in most cases not bother about it, whatever monitor/AVR I would deploy on.
Now, in vc4-kms-v3d use-case, it seems I have to work-out the magic to find proper parameters (and eventual edid.dat debunking) to add into cmdline.txt, and this has become deployment-specific...

For instance, currently first boot stage with GPU respects hdmi_safe=1, and latter linux part is with cmdline.txt parameters...
First boot stage will be consistent across deployments, second stage will not, and may even break.

Any chance at some point Pi Firmware may transparently work-out the magic and translate (for exemple) hdmi_safe=1 stuff into relevant kernel parameters for it to load? This would offer appreciated users' peace-of-mind for that driver transition, and would probably apply to any other distribution.

[popcornmix]

hdmi_* settings are handled by the firmware and generally don't have kernel side equivalents (note: the kernel never reads config.txt and unless there is an exact mapping to a cmdline.txt setting (which kernel does see) or a device tree property (that the kernel sees and the firmware can adjust) then the firmware can have no effect on the kms driver.

Now, many people use the kernel kms driver on many other platforms, so generally there are (different) mechanisms for achieving similar goals. This is the right solution. It means once you've learnt if your equipment requires specific quirks, then the same will apply when you run linux on an x86 desktop or any other linux platform.

Note: hdmi_safe won't just work fully on any monitor/AVR. It will have very limited functionality, and is likely missing support for specific resolutions, CEC, audio etc.

The kernel does have a roughly similar mechanism using drm.edid_firmware=<fake_edid>
where fake_edid on one of

	"edid/800x600.bin",
	"edid/1024x768.bin",
	"edid/1280x1024.bin",
	"edid/1600x1200.bin",
	"edid/1680x1050.bin",
	"edid/1920x1080.bin",

but I'd say if you can capture and use a valid edid, it's more likely to behave well.

[macmpi]

Thanks a lot for that detailed info: maybe some bits could enhance/clarify current doc on hdmi settings in the context of vc4-kms-v3d.

Indeed those fake_edid do not enable audio on my AVR, and forcing it with hdmi_force_edid_audio=1 in config.txt did not work either.

I guess I've been quite lucky thus far with hdmi_safe=1 and legacy audio and video drivers: I may stick with that then for my portable hdmi setups (audio is key, video is only for console debug).
Thanks again for the helpful hints.

[macmpi]

@popcornmix I'm still puzzled by the audio-side issue in TV+AVR situation.
Your suggested workaround with drm.edid_firmware=AVRedid.dat works, but looking closely at edid-decode edid files (AVR alone edid, and combo AVR+TV edid), it turns out the audio side data description is same in both edid files:
Both advertise Basic audio support, and detailed spec is same:

  Audio Data Block
    Linear PCM, max channels 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    Linear PCM, max channels 8
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    AC-3, max channels 6
      Supported sample rates (kHz): 48 44.1 32
      Maximum bit rate: 640 kb/s
    DTS, max channels 7
      Supported sample rates (kHz): 96 88.2 48 44.1 32
      Maximum bit rate: 1536 kb/s
    Dolby Digital+, max channels 8
      Supported sample rates (kHz): 48 44.1
    MAT (MLP), max channels 8
      Supported sample rates (kHz): 192 96 48
    DTS-HD, max channels 8
      Supported sample rates (kHz): 192 96 48
  Speaker Allocation Data Block
    Speaker map:
      FL/FR - Front Left/Right
      LFE1 - Low Frequency Effects 1
      FC - Front Center
      BL/BR - Back Left/Right
      RLC/RRC - Rear Left/Right of Center (Deprecated)

Some code that interprets edid must do something wrong then with vc4-kms driver failing to deliver audio when AVRedid.dat is not supplied, while available AVR+TV edid has consistent audio info...
What info can I eventually supply to help debug that?

[popcornmix]

Can you test with rpi-update kernel?
That has an upstream fix which could possibly help.

[macmpi]

Thanks for the follow-up & note @popcornmix
I did test after rpi-update:
Linux raspberrypi 5.15.34+ #1544 Tue Apr 19 13:10:49 BST 2022 armv6l GNU/Linux

But unfortunately alsa audio test still did not work unless I supply AVRedid.dat file in cmdline.txt: so it's not fully fixed yet on that usecase.
Interestingly, on the video side, I did see a few more lines than before after ttyAMA0 message, but still black screen later-on if AVRedid.dat is not supplied.

[yullaw]

@popcornmix
A fresh installation of Raspberry Pi OS 11 (bullseye)(32bit) aslo still causing random GUI reaching after reboot. For more details see attached outputs.

As I can see, the video resolution is set to 1920x1080M@60 for a boot, the CLI screen is overscanned, then the GUI is appeared corectly to my configuration 1360x768 for TV. But sometimes GUI reached, sometimes not.

journalctl-b.txt
journalctl-b_blank_screen.txt
inxi-F.txt
rpi-eeprom-update.txt

[Jin33334]

the documentation in the internet is not good for this issue.

modify config.txt for dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

[rapsys]

The change to dtoverlay=vc4-fkms-v3d in config.txt fixed it for me.

I have a dell wfp3008, a hdmi cable buyed at berrybase (advertised as rpi compatible), with default configuration dtoverlay=vc4-kms-v3d the monitor advertise a no signal after the framebuffer switch to kms mode.

With dtoverlay=vc4-fkms-v3d it works fine, I see the frambuffer switch to kms mode but the screen continue to display the right contents.

[popcornmix]

@rapsys Are you running RPiOS bullseye?
Can you report output of "vcgencmd version" and "uname -a".

[rapsys]

@rapsys Are you running RPiOS bullseye? Can you report output of "vcgencmd version" and "uname -a".

My hardware is a cm4/8GbRam/32GbFlash/Wlan/Bt on a Waveshare Compute Module 4 PoE Board (B) :
https://www.berrybase.de/raspberry-pi-compute-module-4-8gb-ram-32gb-flash-wlan-bt
https://www.waveshare.com/wiki/Compute_Module_4_PoE_Board_(B)

I installed the distribution : Raspberry Pi OS (64-bit) Lite.

I did a apt-get update & apt-get upgrade & rpi-update

$ cat /etc/debian_version
11.5
$ vcgencmd version
Oct 26 2022 11:09:05
Copyright (c) 2012 Broadcom
version c72ad6b26ff40c91ef776b847436094ee63fabee (clean) (release) (start)
$ uname -a
Linux cm4.local 5.15.76-v8+ #1597 SMP PREEMPT Fri Nov 4 12:16:41 GMT 2022 aarch64 GNU/Linux

If you need more informations tell me.

I may not keep the raspberry os forever and intend to install a mageia 9 aarch64 in replacement of the raspberryos if I succeed.

[rapsys]

$ sudo apt-get update
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Hit:3 http://deb.debian.org/debian bullseye-updates InRelease
Hit:4 http://archive.raspberrypi.org/debian bullseye InRelease
Reading package lists... Done
$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$ sudo rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Your firmware is already up to date (delete /boot/.firmware_revision to force an update anyway)

[popcornmix]

When booted with default kms driver, can you run:

find /sys -name edid -exec edid-decode {} \; | pastebinit

and post the url returned.

And also report output of:

sudo grep HOTPLUG /sys/kernel/debug/dri/0/hdmi0_regs 

[rapsys]

I don't understand, with dtoverlay=vc4-fkms-v3d in config.txt ?
Or with not working dtoverlay=vc4-kms-v3d in config.txt ?
(I can access it by ssh so I am able to run commands even blind)

[popcornmix]

I'd like you to use the kms driver and ssh in.
What's the problem with using ssh?

[rapsys]

I'd like you to use the kms driver and ssh in. What's the problem with using ssh?

No problem with ssh, it was my only access until the change to from kms to fkms.

I will do it later tonight

[rapsys]

I have no hdmi0_regs file.

With dtoverlay=vc4-kms-v3d in config.txt :

# ls /sys/kernel/debug/dri/0
bo_stats  clients  gem_names  measure_clock  name  v3d_ident  v3d_regs

# ls /sys/kernel/debug/dri/1
HDMI-A-1  Writeback-1  crtc-0  crtc-2  crtc-4  crtc0_regs  crtc2_regs  crtc4_regs   gem_names   hdmi1_regs  hvs_gamma  hvs_underrun      name   txp_regs
HDMI-A-2  clients      crtc-1  crtc-3  crtc-5  crtc1_regs  crtc3_regs  framebuffer  hdmi0_regs  hvs_dlists  hvs_regs   internal_clients  state

# grep HOTPLUG /sys/kernel/debug/dri/1/hdmi0_regs 
            HDMI_HOTPLUG = 0x00000000

# find /sys -name edid 
/sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
/sys/devices/platform/gpu/drm/card1/card1-Writeback-1/edid
/sys/devices/platform/gpu/drm/card1/card1-HDMI-A-2/edid

# find /sys -name edid -exec edid-decode {} \; | pastebinit
https://paste.debian.net/1259919/

All files are empty :
# cat /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid /sys/devices/platform/gpu/drm/card1/card1-Writeback-1/edid /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-2/edid

# dmesg | grep -E '(drm|vc4)'
[    3.499371] systemd[1]: Starting Load Kernel Module drm...
[    3.788780] systemd[1]: modprobe@drm.service: Succeeded.
[    3.794123] systemd[1]: Finished Load Kernel Module drm.
[    5.525657] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[    6.675137] fb0: switching to vc4 from simple
[    6.728162] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.822735] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    6.828991] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    7.018661] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    7.068648] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    7.068937] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
[    7.096578] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    7.097099] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    7.097497] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.097853] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.098307] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.098665] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.099008] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.123217] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[    7.124931] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[   17.375844] vc4-drm gpu: [drm] Cannot find any crtc or sizes

# dmesg | pastebinit
https://paste.debian.net/1259920/

# cat /boot/config.txt | pastebinit 
https://paste.debian.net/1259921/

[rapsys]

With dtoverlay=vc4-fkms-v3d in config.txt :

# dmesg | grep -E '(drm|vc4)'
[    3.493793] systemd[1]: Starting Load Kernel Module drm...
[    3.776315] systemd[1]: modprobe@drm.service: Succeeded.
[    3.782047] systemd[1]: Finished Load Kernel Module drm.
[    5.520456] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[    6.399777] fb0: switching to vc4 from simple
[    6.425978] vc4-drm gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
[    6.430308] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[    6.736964] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

# find /sys/kernel/debug/dri -name hdmi0_regs
#

# find /sys -name edid
/sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid

# edid-decode /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 10 ac 37 40 4c 32 39 32
21 14 01 03 80 41 29 78 ea 8f 95 ad 4f 32 b2 25
0f 50 54 a5 4b 00 81 80 a9 40 71 4f 81 00 b3 00
01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
36 00 81 91 21 00 00 1a 00 00 00 ff 00 47 35 30
31 48 30 38 4b 32 39 32 4c 0a 00 00 00 fc 00 44
45 4c 4c 20 33 30 30 38 57 46 50 0a 00 00 00 fd
00 31 56 1d 5e 11 00 0a 20 20 20 20 20 20 01 37

02 03 22 f5 4f 01 02 03 04 05 06 07 10 11 12 13
14 15 16 1f 23 0d 07 07 83 0f 00 00 65 03 0c 00
10 00 01 1d 00 72 51 d0 1e 20 6e 28 55 00 ba 88
21 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00
ba 88 21 00 00 9e 8c 0a d0 8a 20 e0 2d 10 10 3e
96 00 ba 88 21 00 00 18 8c 0a a0 14 51 f0 16 00
26 7c 43 00 ba 88 21 00 00 98 02 3a 80 18 71 38
2d 40 58 2c 45 00 ba 88 21 00 00 1e 00 00 00 c2

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: DEL
    Model: 16439
    Serial Number: 842609228
    Made in: week 33 of 2010
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 65 cm x 41 cm
    Gamma: 2.20
    DPMS levels: Standby Suspend Off
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6777, 0.3085
    Green: 0.1982, 0.6982
    Blue : 0.1464, 0.0595
    White: 0.3134, 0.3291
  Established Timings I & II:
    IBM     :   720x400    70.082 Hz   9:5    31.467 kHz  28.320 MHz
    DMT 0x04:   640x480    59.940 Hz   4:3    31.469 kHz  25.175 MHz
    DMT 0x06:   640x480    75.000 Hz   4:3    37.500 kHz  31.500 MHz
    DMT 0x09:   800x600    60.317 Hz   4:3    37.879 kHz  40.000 MHz
    DMT 0x0b:   800x600    75.000 Hz   4:3    46.875 kHz  49.500 MHz
    DMT 0x10:  1024x768    60.004 Hz   4:3    48.363 kHz  65.000 MHz
    DMT 0x12:  1024x768    75.029 Hz   4:3    60.023 kHz  78.750 MHz
    DMT 0x24:  1280x1024   75.025 Hz   5:4    79.976 kHz 135.000 MHz
  Standard Timings:
    DMT 0x23:  1280x1024   60.020 Hz   5:4    63.981 kHz 108.000 MHz
    DMT 0x33:  1600x1200   60.000 Hz   4:3    75.000 kHz 162.000 MHz
    DMT 0x15:  1152x864    75.000 Hz   4:3    67.500 kHz 108.000 MHz
    DMT 0x1c:  1280x800    59.810 Hz  16:10   49.702 kHz  83.500 MHz
    DMT 0x3a:  1680x1050   59.954 Hz  16:10   65.290 kHz 146.250 MHz
  Detailed Timing Descriptors:
    DTD 1:  1920x1200   59.950 Hz   8:5    74.038 kHz 154.000 MHz (641 mm x 401 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   6 Vback  26 Vpol N
    Display Product Serial Number: 'G501H08K292L'
    Display Product Name: 'DELL 3008WFP'
  Display Range Limits:
    Monitor ranges (GTF): 49-86 Hz V, 29-94 kHz H, max dotclock 170 MHz
  Extension blocks: 1
Checksum: 0x37

----------------

Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 5
  Video Data Block:
    VIC   1:   640x480    59.940 Hz   4:3    31.469 kHz  25.175 MHz
    VIC   2:   720x480    59.940 Hz   4:3    31.469 kHz  27.000 MHz
    VIC   3:   720x480    59.940 Hz  16:9    31.469 kHz  27.000 MHz
    VIC   4:  1280x720    60.000 Hz  16:9    45.000 kHz  74.250 MHz
    VIC   5:  1920x1080i  60.000 Hz  16:9    33.750 kHz  74.250 MHz
    VIC   6:  1440x480i   59.940 Hz   4:3    15.734 kHz  27.000 MHz
    VIC   7:  1440x480i   59.940 Hz  16:9    15.734 kHz  27.000 MHz
    VIC  16:  1920x1080   60.000 Hz  16:9    67.500 kHz 148.500 MHz
    VIC  17:   720x576    50.000 Hz   4:3    31.250 kHz  27.000 MHz
    VIC  18:   720x576    50.000 Hz  16:9    31.250 kHz  27.000 MHz
    VIC  19:  1280x720    50.000 Hz  16:9    37.500 kHz  74.250 MHz
    VIC  20:  1920x1080i  50.000 Hz  16:9    28.125 kHz  74.250 MHz
    VIC  21:  1440x576i   50.000 Hz   4:3    15.625 kHz  27.000 MHz
    VIC  22:  1440x576i   50.000 Hz  16:9    15.625 kHz  27.000 MHz
    VIC  31:  1920x1080   50.000 Hz  16:9    56.250 kHz 148.500 MHz
  Audio Data Block:
    Linear PCM:
      Max channels: 6
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Speaker Allocation Data Block:
    FL/FR - Front Left/Right
    LFE1 - Low Frequency Effects 1
    FC - Front Center
    BL/BR - Back Left/Right
  Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
    Source physical address: 1.0.0.0
  Detailed Timing Descriptors:
    DTD 2:  1280x720    60.000 Hz  16:9    45.000 kHz  74.250 MHz (698 mm x 392 mm)
                 Hfront  110 Hsync  40 Hback 220 Hpol P
                 Vfront    5 Vsync   5 Vback  20 Vpol P
    DTD 3:  1920x1080i  60.000 Hz  16:9    33.750 kHz  74.250 MHz (698 mm x 392 mm)
                 Hfront   88 Hsync  44 Hback 148 Hpol P
                 Vfront    2 Vsync   5 Vback  15 Vpol P Vfront +0.5 Odd Field
                 Vfront    2 Vsync   5 Vback  15 Vpol P Vback  +0.5 Even Field
    DTD 4:   720x480    59.940 Hz   3:2    31.469 kHz  27.000 MHz (698 mm x 392 mm)
                 Hfront   16 Hsync  62 Hback  60 Hpol N
                 Vfront    9 Vsync   6 Vback  30 Vpol N
    DTD 5:  1440x480i   59.940 Hz   3:1    15.734 kHz  27.000 MHz (698 mm x 392 mm)
                 Hfront   38 Hsync 124 Hback 114 Hpol N
                 Vfront    4 Vsync   3 Vback  15 Vpol N Vfront +0.5 Odd Field
                 Vfront    4 Vsync   3 Vback  15 Vpol N Vback  +0.5 Even Field
    DTD 6:  1920x1080   60.000 Hz  16:9    67.500 kHz 148.500 MHz (698 mm x 392 mm)
                 Hfront   88 Hsync  44 Hback 148 Hpol P
                 Vfront    4 Vsync   5 Vback  36 Vpol P
Checksum: 0xc2

[rapsys]

After upgrading to last kernel, with dtoverlay=vc4-kms-v3d in config.txt :

# find /sys/kernel/debug/dri -name hdmi0_regs 
/sys/kernel/debug/dri/1/hdmi0_regs
# grep HOTPLUG /sys/kernel/debug/dri/1/hdmi0_regs
            HDMI_HOTPLUG = 0x00000000
# find /sys -name edid
/sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
/sys/devices/platform/gpu/drm/card1/card1-Writeback-1/edid
/sys/devices/platform/gpu/drm/card1/card1-HDMI-A-2/edid
# cat /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid /sys/devices/platform/gpu/drm/card1/card1-Writeback-1/edid /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-2/edid
# uname -a
Linux cm4.local 5.15.76-v8+ #1597 SMP PREEMPT Fri Nov 4 12:16:41 GMT 2022 aarch64 GNU/Linux
# dmesg | grep -E '(drm|vc4)'
[    3.521203] systemd[1]: Starting Load Kernel Module drm...
[    3.799950] systemd[1]: modprobe@drm.service: Succeeded.
[    3.806200] systemd[1]: Finished Load Kernel Module drm.
[    5.489972] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[    7.038758] fb0: switching to vc4 from simple
[    7.119900] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    7.126596] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    7.126799] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    7.133889] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    7.148060] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    7.148347] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
[    7.153636] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    7.154124] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    7.154491] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.154839] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.155179] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.155454] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.155802] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    7.160076] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[    7.160734] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[   17.380339] vc4-drm gpu: [drm] Cannot find any crtc or sizes

[popcornmix]

This is your problem:

$ grep HOTPLUG /sys/kernel/debug/dri/1/hdmi0_regs
HDMI_HOTPLUG = 0x00000000

The hotplug detect signal comes in on pin 19 of hdmi cable and is asserted by display to indicate display is connected.
The hdmi spec says the edid (which describes the capabilities of display) can only be read when hotplug is asserted.

The kms driver follows the spec more accurately that the fkms.

Most likely you have a faulty cable that doesn't connect the hotplug detect. Less likely the display is faulty and doesn't assert hotplug.

You can try to narrow this down by testing with other hdmi cables and other displays.

If you add video=HDMI-A-1:D to cmdline.txt (end of existing line) it will assume hotplug is asserted and may work around your hardware issue. But fixing the underlying problem is preferable and necessary for some features (e.g. 4kp60 or displays that change reported capabilities based on menu options like enabling deep colour).

[rapsys]

This is your problem:

$ grep HOTPLUG /sys/kernel/debug/dri/1/hdmi0_regs
HDMI_HOTPLUG = 0x00000000

The hotplug detect signal comes in on pin 19 of hdmi cable and is asserted by display to indicate display is connected. The hdmi spec says the edid (which describes the capabilities of display) can only be read when hotplug is asserted.

Most likely you have a faulty cable that doesn't connect the hotplug detect. Less likely the display is faulty and doesn't assert hotplug.

You can try to narrow this down by testing with other hdmi cables and other displays.

The used cable is this one, it is advertised to work optimaly for rpi :
https://www.berrybase.de/high-speed-hdmi-kabel-mit-ethernet-weiss?number=31893

Due to my past of militing against DRM, this is the only hdmi cable I have that I buyed for the rpi without other option.
I am unable to test with an other cable hdmi cable I don't have and don't intend to buy...

I only have my dell WFP3008 screen, I followed the procedure described there to make sure the edid is advertised :
https://josh.st/2008/05/02/dell-2707wfp-lcd-monitor-service-menu/
https://www.dell.com/community/Monitors/Dell-3008WFP-DVI-D-re-occuring-port-failure-for-many-users/td-p/3174085/page/11

I found an unresolved bug in kms with this same screen maybe related :
https://bugs.freedesktop.org/show_bug.cgi?id=23495

I can't conclude, but it's more than likely that my old screen from 2010-2011 don't respect the spec or has not the hotplug feature implemented correctly...

If you add video=HDMI-A-1:D to cmdline.txt (end of existing line) it will assume hotplug is asserted and may work around your hardware issue. But fixing the underlying problem is preferable and necessary for some features (e.g. 4kp60 or displays that change reported capabilities based on menu options like enabling deep colour).

Your suggestion of extra cmdline works, what does it do ?

As a side note, adding only hdmi_force_hotplug=1 to config.txt don't work.

Would it be possible to add this in the documentation as an errata ?
With keywords hdmi screen lost while booting and other related words ?

The kms driver follows the spec more accurately that the fkms.

I understand that it's good to follow the spec, but I would advocate that I am not the first one who encountered this problem and loosing the screen while booting is kind of a problem...

Wouldn't it be more wise to change kms to probe anyway and complain in the kernel message about the out of spec cable or screen ?

[popcornmix]

Your suggestion of extra cmdline works, what does it do ?

See here or here.
'D’ will force the display to be enabled and use digital output.

As a side note, adding only hdmi_force_hotplug=1 to config.txt don't work.

No - config.txt is only used by the firmware, so affects the fkms driver, but not the kernel side kms driver (which uses cmdline.txt)

Would it be possible to add this in the documentation as an errata ?

These are standard linux options, that apply to all platforms (including x86). They are not Pi specific.
Your display will not work on any platform supporting kms/drm without a working hotplug signal (or a cmdline setting to force it).

[rapsys]

These are standard linux options, that apply to all platforms (including x86). They are not Pi specific. Your display will not work on any platform supporting kms/drm without a working hotplug signal (or a cmdline setting to force it).

I never had these problems with this display using dvi and then displayport câble with radeon kms driver...
(only had to force the resolution as it was reset too low after kms switch)

Anyway thank's for your help in getting the output to work ;)

[popcornmix]

There is a potential update for this issue (screen going blank at point of transition of kms driver on a pi4) in latest rpi-update kernel. It would be useful if anyone who experiences this issue can test and report back.
See: raspberrypi/linux#5317

[macmpi]

AFAIC, that fix does not change situation on my setup (AVR+SonyTV): video blanking still here, and no audio either (hoped the AVMUTE-thingy might fix it)...
Supplying AVRedid.dat file and related cmdline.txt parameter solves both as previously.
FWIW, here is my raspinfo

[popcornmix]

@macmpi your issue wasn't related to original poster's issue (it didn't start safter commit#1e49ef1), so your report should really have been in a separate issue.

Scanning back through your posts, it sounds like your AVR is at fault in producing an edid with timings your TV can't handle. An AVR should merge the capabilities of the TV's edid and the AVR's to produce an edid that only has modes supported by both. Assuming this is the case, then using a custom edid file is the right workaround. I don't think we can do any better.

[Rohlik]

@popcornmix I tested that firmware along with 5.15.90-v7+ kernel but screen still isn't turned on during boot.
So for me is still dtoverlay=vc4-fkms-v3d solution only working way.

[ajay01994]

Hi guys As mentioned by @Rohlik dtoverlay=vc4-fkms-v3d. did work for my raspberry pi 4b while fixing the blue screen issue ,however my HDMI CEC isn't working post changing to (fkms). Any help over this would be appreciated

[ajay01994]

Has the issue fixed / resolved ?

[circuitmike]

Definitely hasn't been resolved. I just did a brand-new install of Raspberry Pi OS (lite version) on a Pi 4 and I had to comment out dtoverlay=vc4-kms-v3d entirely. Switching to fkms did cause the monitor to get a signal (so it switched to "awake" mode, as indicated by the color of the LED on its front panel) but the display was still blank.