RPi4B/Kodi goes to black screen with vc4-kms-v3d after commit 19272ccd69049aaf42c78a235a0bf37dbabd5ea7 #1648
Comments
|
That commit did have a later fix: Does the problem still occur with that? If it does can you post your edid, and I'll see it I can reproduce. |
|
How much later is the fix? Of course I also tried it initially about 2-3 days ago with the latest version with the same error Ah, I guess you mean this one: 5d61ab7 In the meantime i have already read out the edid data: HTH |
|
Here is again the complete dmesg output with current firmware from today. The firmware that still works looks like this: However I see that the audio error messages are there too, but only this one |
|
I'd like the raw edid. e.g. paste output of: |
|
No problem |
|
Can this be related? https://beta.raspberrypi.org/forums/viewtopic.php?p=1938658#p1938658 |
|
What effect does changing |
It works for me! Is this the official solution, or there will be an update fixing this issue? |
|
We'd like to fix it but so far haven't reproduced. |
|
@popcornmix I tried to locate the problem further yesterday and found what I was looking for. This is my cmdline |
|
Using PI:HDMI (i.e. firmware driving hdmi audio) together with vc4-kms-v3d (i.e. arm driving hdmi hardware) is not a supported configuration. Both ends can access hdmi registers without knowledge of what the other side is doing, and crashes are not unexpected. We should perhaps try harder to reject use of the firmware hdmi audio driver when kms is enabled. |
I know that and I have also read several posts about how this should be prevented. |
|
Maybe this issue is related to the problems I am having: https://forums.raspberrypi.com/viewtopic.php?p=1944172#p1943655 I am seeing this on Lakka, which is based on Libre-ELEC. I did not have this issue on 5.10.39, but had it sporadically (maybe 40% of boots) on 5.10.63 and 100% of the time on 5.15.0. So far, I've only seen it happen on my rev 1.4 Pi 4 and only on my 4K TV (LG OLED65CX). Changing from KMS to FKMS makes the issue disappear. See the linked post for full description and log printouts. For me, reproducing it is as simple as putting the image below (Lakka development image with kernel 5.15.0) on an SD card and booting it on a Pi 4 4GB rev 1.4 board on the LG OLED65CX. |
|
Sorry for slightly misleading information earlier. The sporadic nature of this issue and my lack of time for testing led me to make some incorrect conclusions. The rev 1.1 and the rev 1.4 boards seem about equally affected. Both have major issues with 4K when testing with the 5.10.63 and 5.15.0 kernels on Lakka. 5.10.39 has no issues on any of the boards, whether running 4K or 1080P. Below are the full test results. Each config was booted five times and the result recorded. Each boot was a cold boot.
|
|
@Brunnis are you able to narrow it down further? |
|
@popcornmix Actually, I am just switching between the Lakka images, so not changing the system from defaults in any way so far. Can you suggest any steps/commands that would help in narrowing it down? |
|
Easiest to reproduce with RPiOS bullseye (then we'll know what you are running and have a better chance of reproducing). From there you can identify the exact update which caused this. See: If you click on each commit the end of the url contains a git hash. Run |
|
I've ran a bunch of reboots using Bullseye lite 32-bit, but cannot reproduce the issue there. Lakka is 64-bit, but both use the same kernel (5.10.63). The output of vcgencmd version is: Lakka 3.6 64-bit: Bullseye 32-bit lite: Last week I tried Bullseye 64-bit desktop and that also seemed to work fine. Don't really know how to proceed, to be honest. |
|
It seems lakka is using start_x. You can add start_x=1 to bullseye config.txt just in case that makes a difference (I wouldn't expect it to). Are they both using But if the issue doesn't occur with RPiOS bullseye, then there's not much we can do. |
|
It's probably worth checking that Lakka includes overlay_map.dtb in /boot (or wherever they mount the boot partition). You can also see if |
|
@popcornmix start_x=1 made no difference. Both are indeed using vc4-kms-v3d. @pelwell Lakka does not include overlay_map.dtb. Is that an issue? |
|
It would mean the usual config.txt file is loading the Pi 0-3 version of the kms overlay. Try changing the line to |
|
Ah - I should have said to check in the |
|
Ahh, Lakka is actually using dtoverlay=vc4-kms-v3d-pi4 by default. Sorry for overlooking that earlier. Regarding the overlays subdirectory, that was actually where I looked, since I figured that would be the correct place. 😊 I'll let you know if I get anywhere with further testing. |
|
I found a successful workaround for the no HDMI issue that at least works on Lakka 3.6 with the 5.10.63 kernel: Add "video=HDMI-A-1:1920x1080M@60" to cmdline.txt. So, it seems something sporadically fails (more than 50% of boots) when trying to use 4K 30Hz. Don't know yet if this particularly affects the LG OLED CX, as I don't have any more 4K TVs around. I actually belive I tested this workaround early on in my testing of kernel 5.15.0 and it didn't help there, but I need to confirm that. Doubtful if this is related to the original issue described here, but I thought I'd let you know of this slight progress. |
|
I also have the black screen problem. However, when using a plain micro hdmi to hdmi cable all is fine. When using a micro hdmi adapter and a standard hdmi cable, it fails with a black screen. Tested on Raspbian bullseye and Recalbox 8.0.0 (both of them use kms by default) Going back to fkms makes both cables work, so this does not look like a cable problem. |
Sounds a bit like the adapter is breaking something (possibly reading the edid). (one will report missing file, the other should show something). Do this when using the kms driver, from ssh if you have blank screen. |
|
With the adapter plugged-in, edid is empty (card-0-HDMI-A-1 does not exist)
The issue appeared between kernel 5.10.13 and 5.10.79. Also, at power-up, a signal is sent to the TV until vc4 (drm) is loaded . This is even more visible with raspbian where one can see the linux system loading and at some point (when vc4 is loaded, I think), the screen goes black and no signal is sent anymore. |
|
If you can't read the edid using a specific adapter then the adapter is faulty (most likely no not connecting the hotplug detect line). |
|
Is there something that could explain that it works flawlessly on old kernels with the same adapter ? |
|
There was a bug in the kernel driver where we would read the edid without hotplug being asserted which is against spec (and caused issues with re-enabling scrambling after switching hdmi input). |
|
Finally, the video option solved this issue. Thank you @popcornmix. |
|
So what was the solution for the Argon case? |
|
@popcornmix we just released the new Recalbox 8.0.1 with the
But it cause other issues, as it seems to avoid the kernel to take any arguments of config.txt (hdmi_mode in this case) Is there a documentation or source code anywhere that could let us understand how this video=XXX is parsed and used ? |
|
Info on the |
|
Thank you @popcornmix for the information. I'm sorry but I must admit we don't know what to think about this issue. 100% of the hdmi worked well. Does that mean that a certain percentage of hdmi cables/tv were working by chance ? Cannot it be considered as a feature and not a bug then ? I may be wrong but I think several distributions are touched by this bug, and right now we are even thinking about rolling back to the old kernel and firmware version as we don't know what to do. Please help me not doing this 😅 |
|
@digitalLumberjack I tried it and it doesn't work. I did have a bridged solder point on HDMI which I fixed and validated with my my multimeter. Am I supposed to put the whole statement video=HDMI-A-1:D video=HDMI-A-2:D in the cmdline.txt or just one or the other as in video=HDMI-A-1:D? |
|
@popcornmix I understand how much disdain you have for the argon and others like it but I do "love" mine, specifically for the ssd functionality. Software work arounds are par for the course in development. |
We put that in cmdline.txt at the end of the line. Don't know if it fixes anything for the argon though. |
|
@digitalLumberjack Thanks, I appreciate you trying to help. Will try outside of case and report back. |
|
"disdain" is a strong word that doesn't apply here - saying that they "cause a lot of unreliability issues for hdmi" is just a statement of fact. |
|
Test results:
Notes: I followed the trace and it is connected. There are no components, it's a straight pass through, just like my my micro HDMI adapter. What could be the issue? |
None of our users reported faultly Argon case until then. Maybe they were all luky. The situation for end users is a lot worse since this "fix". Our users are not technical people at all. They are mostly players. Lambda users don't care or even know if they have "fautly hardware". The only things they see is "It's no longer working". |
|
@popcornmix has spent years fixing the corner cases in the old firmware-based HDMI driver. It will take a while for the remaining issues with the new driver to be resolved, but they will. |
|
I agree with @bkg2k 's sentiment but also understand @popcornmix 's desire to do things the right way, but, as I've said before, not everything is done the "right" way and this change has trashed a lot of systems. Electronics are littered with corrections and or errors that we usually find a way around. I hope @popcornmix does find a way to fix things so Libreelec is compatible with more devices. I think the amlogic et al. boxes are getting expensive and hard to find, which is why I switched to the RPI 2 years ago. This thread is getting dangerously close to a flame war so I will let @popcornmix get on with it and no longer comment. Furthermore I am offering a $40 donation bounty when this issue is fixed. I know it's not much but I think we should ALL encourage the Libreelec team. I would encourage others in this thread to add to the bounty, ESPECIALLY if you are a vendor. Fair is fair. |
|
Asking lamba users to add some cmdline option only when it does'nt work is not an option. Did I miss something? What fix is this? |
So changing this in the flash/distro.config gives me video on the Argon but I lose audio outputs. Is there a way to fix it? I tried both HDMI ports. This is what I have now in distro.cfg: and cmdline.txt: boot=UUID=2801-4448 disk=UUID=6f37a636-034d-4f7d-9eeb-a1453c0cf6ba quiet |
No flame war here. We're in a serious thread. |
|
@bkg2k Are you talking about changing dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d? I did that and now I get Argon video but lost all audio capability. Apparently there is an audio bug when using fkms. @popcornmix I noticed you committed a change to the RPI GitHub last night to to fix the fkms no sound issue. Did this make it into the libreelec nightlies? |
I don't believe there has been any recent change like this. You may have been seeing a spurious github notification that occurs when rebasing newer kernel trees - if a commit references an issue you get a notification on each rebase. |
|
As I've mentioned previously, I worked around my issues with black screen during boot on my 4K TV by setting 1920x1080 via the kernel command line. This was using Lakka 3.6 and solved the problem 100 % for me. Now Lakka 3.7 has finally been released and they've determined that the issue was caused by more recent Pi firmware. A downgrade to 1.20210831 has apparently solved the issue (as verified by others). See release notes mentioning this here: https://www.lakka.tv/articles/2022/03/01/lakka-3.7/ @ToKe79 may know more, since he implemented this change. |
Where is that file location |
|
|
I believe these issues are all related to being unable to read the edid. There are workarounds for this, using manual configuration, but fixing the hardware is the better solution. Adding something like |
popcornmix
added
the
Close within 30 days
|
Listen to @popcornmix 👆👆 !! My RPI4 with kodi on ArchARM had symptoms described here and in other locations. It used to work. Last year it started having troubles. After trying a lot of things with fkms in config.txt, passing edid.dat to the kernel and what not. I finally bought a new HDMI cable (DIGITUS HDMI/A ST-Micro HDMI ST 2m) replacing a Micro-HDMI Adapter and a Standard HDMI Cable and everything works as indented. Thank you for your patience with us fools. |
|
I had the same experience as @fuchsmich. I had my RPI in storage for a few months, and when I powered it back on I got this issue. After tons of messing around, I purchased a brand new HDMI cable, and everything returned to working. So I guess it was a layer-1 issue? |
This commit leads to a black screen (TV says no signal) after Kodi is started.
This occurs with all tested kernel versions (5.10.60 - 5.10.75 and 5.14.14) and with both Kodi 19 and Kodi 20.
In dmesg the messages appear:
If I use vc4-fkms-v3d (which I have always used so far) this problem no longer occurs
This means the firmware files that are present in /boot, not the kernels itself
Until one commit before the one above, the problem does not occur, so it must definitely be the commit arm_loader: Add message to release firmware framebuffer 19272cc
My /boot/config is
The text was updated successfully, but these errors were encountered: