EDID not loaded on BalenaOS 6.4 and later

I have a custom board/display for my Raspberry Pi CM4. It’s worked great for the last two years or so, up until and including Linux kernel 6.1.77-v8 in/around Balena OS 6.4.2. Today I tried to upgrade to BalenaOS 6.4.3+rev1 and now the display on my device isn’t working any longer. I have pinpointed it to the updated Linux kernel in 6.12.1-v8 and it’s probably due to the fact that my hardware doesn’t have an EDID EEPROM chip (it’s a driver chip connected directly to the HDMI output on the CM4 and I’ve had to specify a cmdline.txt option to set the video mode). But now with the latest kernel I’m getting this error in dmesg:

[    0.626997] vc4-drm gpu: [drm] *ERROR* Failed to get ddc i2c adapter by node

followed by a ton of:

[    0.895312] vc4-drm gpu: [drm] HDMI Sink doesn't support RGB, something's wrong.

And the display isn’t working. My application starts up, but I can’t see anything. I’ve tried a variety of ways to set the edid with a custom file, but for the life of me I can’t figure it out. I saw this post:

But it’s either out-dated, or it doesn’t work. I’ve tried to put my edid.dat file in various locations, granted it may not actually be there during boot time, but I figured at least it would be in /mnt/boot since that’s where the cmdline.txt is loaded from, but I still get this in dmesg:

[    1.006250] [drm] Initialized vc4 0.0.0 for gpu on minor 0
[    1.006364] vc4-drm gpu: Direct firmware load for /mnt/boot/edid.dat failed with error -2
[    1.006373] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:33:HDMI-A-1] Requesting EDID firmware "/mnt/boot/edid.dat" failed (err=-2)
[    1.007292] vc4-drm gpu: Direct firmware load for /mnt/boot/edid.dat failed with error -2
[    1.007297] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:33:HDMI-A-1] Requesting EDID firmware "/mnt/boot/edid.dat" failed (err=-2)
[    1.008667] vc4-drm gpu: [drm] HDMI Sink doesn't support RGB, something's wrong.

This is what the section in cmdline.txt looks like: drm.edid_firmware=/mnt/boot/edid.dat.

I don’t know if it’s hard-coded in the kernel to only allow a relative path under /lib/firmware, or what could be the issue?

I also opened a Github issue for this as it seems to be a regression from earlier versions and possibly related to a load order change (vs actual kernel change): Regression in BalenaOS 6.4.3: drm.edid_firmware Fails with ENOENT (-2) Due to vc4 Load Before Filesystem Mount · Issue #3635 · balena-os/meta-balena · GitHub

Hello @HakanL thanks for all the details you shared.

Let me ping the OS team to see how we can help you more!

Keep us posted on any progress you make!

1 Like

Any update? This prevents me from upgrading the OS and unfortunately with no downgrade option it can brick my devices. I noticed nobody tagged the Github issue I created, is that not the correct way to report issues?

Hello @HakanL did you end up having a solution? Sorry for letting you hanging this way.

Have you tried using io.balena.features.firmware, see the documentation here? You might need to reload your driver though as it probably won’t work at boot.

This message was heavily edited as I was giving you way too complex information, and we actually already have that on hand.

Bests,

Yann

Hello @ycardaillac , so I ended up not using the custom edid file as I couldn’t get it to work. The root issue I was trying to solve was to not having to update the cmdline.txt to set 32-bit framebuffer, but it seems that even with a EDID chip it seems to default to 16-bit, so I abandoned the idea to use a custom edid file. I do believe the issue is still there, but it’s not needed by myself any more.

The mapping of the lib/firmware is an interesting concept, though my problem wasn’t to load a custom driver (no need) nor a custom firmware, but to load a custom EDID file. In the end I ended up still having to manually modify the cmdline.txt to get 32-bit framebuffer for my display hardware. Now if there was a feature to map /mnt/boot/ into a container, that would’ve solved a lot of things for me, then my application could’ve just updated the cmdline.txt and rebooted. The fact that I have to manually login to the host os to update this file is a major issue.