raspberrypi / bookworm-feedback

13 stars 1 forks source link

Can't load custom EDID - ENOENT error #300

Open biosmanager opened 1 month ago

biosmanager commented 1 month ago

I try to load a custom EDID for a special display. I copied the modified EDID to /lib/firmware/custom_edid.bin and modified cmdline.txt to include drm.edid_firmware=HDMI-A-1:custom_edid.bin. However, DRM is not able to load this EDID and gives the following error:

[    0.999360] vc4-drm axi:gpu: Direct firmware load for custom_edid.bin failed with error -2
[    0.999366] vc4-drm axi:gpu: [drm] *ERROR* [CONNECTOR:32:HDMI-A-1] Requesting EDID firmware "custom_edid.bin" failed (err=-2)

-2 corresponds to ENOENT which means that the EDID file is not found by DRM. I ensured that that custom_edid.bin has 644 permissions. This seems to be a bug.

popcornmix commented 1 month ago

Are you booting from sdcard or something else? You may need to add the edid to initramfs to ensure it is available when drm driver probes (which could be before the filesystem is mounted).

biosmanager commented 1 month ago

Oh, I see. So I have to manually edit how the initramfs is built to include the file there? Upon checking the logs again, it seems that the normal SD filesystem is mounted after DRM loads.

popcornmix commented 1 month ago

Personally I've always found sdcard, or nfs to be mounted before drm probes and wants to load the edid. But I have seen reports from others that filesystem was not available and rebuilding initramfs with edid included fixed the issue.

The kernel does probe drivers in parallel across the four cores, so the exact ordering that occurs does tend to vary. Ideally if a kernel driver is dependant on another that is unavailable is should return -EPROBE_DEFER which means "try to probe me again later". I'm not sure if drm not doing that is an accidental omission or whether it wouldn't make sense. @6by9 may know more.

6by9 commented 1 month ago

DRM and all the elements that make up the vc4 driver do defer probe if any element is missing. However a file system read failure isn't a failure at the probe level, it's well after that when the connector becomes active.

Quickest test to confirm whether it is initramfs is to set the auto_initramfs=1 in config.txt to 0.

biosmanager commented 1 month ago

Upon quickly checking the source code it seems that DRM loads the EDID by using request_firmware. Would defer probe still apply in this case?

@6by9 I don't quite get what changing auto_initramfs would change. Right now I can't get DRM to load the EDID from the normal filesystem.

6by9 commented 1 month ago

EPROBE_DEFER is an option to be returned from the probe or bind functions of a driver.

DRM is calling request_firmware due to drm_get_edid having been called by the hotplug detect handler of the HDMI connector, which is a long way after the probe or bind, so EPROBE_DEFER is not an option.

For DRM to be starting at 0.999secs after kernel boot all the associated modules have to be part of the initramfs. Disabling the initramfs will result in the DRM module loading being deferred until after the SD card filesystem has been brought up, at which point your EDID file will also be available.

marcomto commented 1 week ago

DRM and all the elements that make up the vc4 driver do defer probe if any element is missing. However a file system read failure isn't a failure at the probe level, it's well after that when the connector becomes active.

Quickest test to confirm whether it is initramfs is to set the auto_initramfs=1 in config.txt to 0.

Thank you very much, setting auto_initramfs=0 worked for me.