RPI4B 64bit vc4-kms-v3d blank screen during post #5195
Comments
|
This is not a firmware bug - moving to the Linux repo. |
There are a few stages during boot where hdmi is output. Do you see output in some of them?
Booting to desktop does hide some of the console output, so booting to console may be a simpler case to investigate. |
|
I've tested your edid on my Pi and it seems fine. I boot to console in 1920x1080@60 mode. You could try capturing the edid: and then use the captured edid and a specified mode. Add this to end of cmdline.txt (same line) Can you ssh in and run commands when display is blank? |
|
Thank you for the reply. The first thing I tired, was capturing the monitor edid and loading it via cmdline.txt (with and without using the video attribute) but it hasn't worked (haven't tried on the TV yet). I have now stored the edid (via SSH) while the monitor displayed blank (haven't tried the TV yet), and the edid is exactly the same as when power cycled: Pressing the power button on the monitor also doesn't do it. I have to physically remove it's power. |
|
It is exactly the same on the TV. The /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid is the same as after switching source (you just have to remember to remove the loaded edid from the cmdline first!). On this device just switching the source makes it work. I also tried another HDMI cable to no avail. In the process I also discovered that using the stable EEPROM bootloader (Tue Aug 2 15:55:05 UTC 2022 (1659455705)) causes my Pi to hang at rainbow if I issue a reboot command with 7 power led flashes, while shutdown or power cycling boots normally. The critical branch (Tue Apr 26 10:24:28 UTC 2022 (1650968668)) does not do this and reboots normally. This probably warrants another bug report in the firmware section. |
Yes. Sounds like an unrelated issue. |
I'd like to be sure whether, after the power cycle of the display, the display becomes happy with the existing signal we output, or whether some hotplug toggling that occurs causes us to switch to a hdmi signal the display likes better. Can you use this in cmdline.txt: I believe now the pi will not be able to detect any cable unplug or power cycle of display. It may also be interesting to look at: Perhaps copy that file somewhere before and after the power cycle and diff them just to see if anything changes. |
|
I've setup the Pi to startx on tty7 (lightdm) and did some testing. All the testing is on the monitor. With With Here is the |
|
I don't think you've run the test I described in my previous post. I want you to repeat this with this in config.txt Do you still get blank screen at end of boot, and do you get output back after power cycling the monitor? |
You seem to be running with X active in the first case and X inactive (possibly switched to a different VT) in the second case. |
Yes. Everything stays the same as before. I see the rainbow screen and the framebuffer but after kms takes over it goes blank. I can bring it back with power cycling the monitor. The only difference is, with vc4.force_hotplug=1, I can boot without hdmi cable attached and if I attach it later when the KMS is in charge, I get output without the need to power cycle the monitor. This does not work without vc4.force_hotplug=1.
Sorry about that one, didn't notice I switched ttys. Retested again with X disabled, the dri state before and after remain the same. |
|
And it is exactly the same on the TV. I can even use the monitors edid in the cmdline.txt and produce the same results (get output by plugging the HDMI after KMS takes over or by switching source on the TV). Just to rule out if this particular Pi is a bit wonky, I tried this sdcard with this image in two other RPI4B on both the TV and the monitor and the results are the same. |
|
That is strange. I believe the signal we are outputting is identical before and after the display power cycle, so the fix is the display resetting its state which sounds like a display problem. But as this is a very rare issue (I'm not sure I've seen this reported), it seems inconceivable you have two unrelated displays with this issue. Just a sanity check. What does |
|
It reports Both of displays are old (2009 and 2012). I tried it now with again two different even older monitors (these are not FHD) that only have DVI ports, so I used a HDMI-DVI adapter and removed the cmdline.txt stuff. One is a Hannsg 19" at 1280x1024 and works. The other is a AIC 22" at 1680x1050 and displays no rainbow and no frame buffer but "signal out of range", however when the KMS takes over the output is restored. As the deprecated firmware FKMS version works without the need to power cycle or source switch on the TV, is there any edid trickery I can do, to make it work with KMS without the hassle of pulling cables? |
|
I wonder if the issue is the switchover that occurs from firmware to kms driver (effectively the TV sees two hdmi mode changes a few seconds apart). It's a longshot but add to cmdline.txt: That will generate more drm debugging and also delay debug messages to 1 per second. |
|
The Now the boot up is taking about 180s, and once systemd starts spawning services it starts flying (no more ~1/s, more like 10/s, not sure if any slower than without boot delay). I noticed, that the mode change occurs somewhere near the end of systemd spawning services. Before that the output is always visible and not changing mode. Now I am not sure where KMS mode change occurs (4th point in your first reply), perhaps something else is changing mode later on? Anyway, did a couple of test with You can compare kernwoxwcmd.log (kern.log with debug, delay, edid, video, hotplug and without starting X) with kernmonitor.log (kern.log without those bootloader/kernel parameters also without starting X) from opening post. |
I don't believe that to be true. |
|
Yes, you are right! I've must have missed copy&pasting that while messing with loading the edid from file before opening this report. Sorry for the miss information. |
aside this debug workaround, is a permanent firmware/driver fix possible? |
|
macmpi, this issue is a very specific failure mode which sounds like a problem with the display (power cycling the display fixes it, even though the signal received is the same before and after power cycle). I don't believe there is a reliable workaround yet (sounds like significant delays only sometimes avoids the issue). Are you saying you have exactly the same issue? |
|
The issue with the LG TV in the initial report reads a lot like this firmware issue raspberrypi/firmware#1647 - which also mentions an LG TV of the same vintage. As that issue was narrowed down to a firmware-only change I suspect something in the FW->KMS handover (timing maybe?) might have changed that results in the TV not wanting to show a picture. A shot in the dark: the vc4 KMS driver doesn't seem to implement AVMUTE support while changing modes. ISTR I read some reports on LE slack or forums (could have been on Rockchip or Allwinner devices) that some TVs didn't like (some?) mode changes unless AVMUTE was set before mode change and cleared after. Might be worth adding AVMUTE support to the driver, maybe that helps (getting the timing right might be a bit tricky as IIRC AVMUTE can only be changed at the beginning of each frame and any clock changes have to be delayed until the GCP has been transmitted) |
It looked similar on a Toshiba TV with PiZeroW, but I do not have that TV with me right now to confirm if it is exactly same issue. |
|
I had same issue with LG 34WK95U-W using CM4 commenting out this lines solves the issue, but why? |
@HiassofT : very enlightening indeed thanks. |
|
@HiassofT
"Source transmission of the General Control Packet is optional" suggests this isn't something required and a display shouldn't behave badly if it is missing. |
|
Same problem with 2022-09-22-raspios-bullseye-arm64.img |
|
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. |
|
I can confirm that with the rpi-update commit 20169be87eee199ab8c958a02ef923597f15f944 the firmware to kms handover works on both displays from the opening comment! Good work! |
|
@JerryK13 Great to hear. This issue has taken a while to understand. |
This solved my problem |
Describe the bug
On a fresh Raspberry Pi OS Lite 64bit (September 22nd 2022) and also rpi-updated to ed6ef1c57077cc3969ae62a4bd9dc1abe5e2a7b7 (kernel 5.15.70-v8+) using the default vc4-kms-v3d the display turns blank during post on two different displays while vc4-fkms-v3d works as intended.
The first display is a Samsung 2494HM monitor
base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
edid-decode output:
Switching source or unplugging/plugging the HDMI cable on this display does nothing. However if I unplug the display power cable and plug it back, the display comes to life. After that, the sound is not working, unless I put the snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_compat_alsa=0 in cmdline.txt. I am attaching kern.log with the events
kernmonitor.log
The second display is a LG 42LM3400-ZA TV
base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
edid-decode output:
On this display, just switching the source to something else then back brings it back to life. For the sound I haven't tested this one without entries in cmdline.txt. I am attaching kern.log of the events
kerntv.log
All logs, decodes and edids were obtained after switching source or power cycling the display.
Is there something obviously wrong with these edids? At least I would like to know what to modify and then load the modified edid via drm.edid_firmware.
Thank you!
The text was updated successfully, but these errors were encountered: