We have encountered an unexpected behavior while working with an HDMI display. It appears that our application has managed to write to the EDID register in the LCD, causing it to stop functioning properly.
It seems that our display is connected to I2C#3 at either address 0x50 or 0x54. According to the DDC specification, the EDID driver should only have the capability to read and display information. How is it possible that the display driver allows writing to the display?
Does anyone know how to prevent or block this behavior?
We are using Jetson NX with JP44.1 and Kernel 4.9.
Unless you have a third party carrier board with something very wrong, this is not possible. The way DDC works (DDC is the wiring, i2c is the protocol, and EDID2 is the format of the data read) is that the power to the i2c hardware in the monitor is powered via the HDMI cable, and when this occurs, read of i2c is possible. The monitor itself should not allow writing. The actual i2c read of DDC is not capable of write, but it is at address 0x50. The trick here though is that there is more than one i2c bus. The dev kits do have an i2c memory being used at address 0x50, but a different bus. This means that if you accidentally read 0x50 from the wrong bus, then you’ll get the content of the internal memory.
There is no possibility that the write function for i2c would output to the DDC wires. Are you using a third party carrier board? If so, then lane routing can be modified via device tree, and using the wrong device tree could in theory lead to writing to the wrong bus. However, the internal memory of that i2c bus at 0x50 which is not intended for DDC would also not normally write. Normally this would be available for reading. If an i2c operation were to read the internal memory bus at 0x50, and if this were also superimposed onto the DDC’s i2c, then it is possible that both would be reading at the same time. Could that cause damage? Perhaps, I do not know. Certainly it would make the data look corrupt.
How do you know the monitor is failing? Did you put this on another computer and read the DDC/EDID data?
Linuxdev thank you for your reply.
We are currently using our custom-designed carrier board based on the devkit files. As a result, the DDclines are connected to pins 100 and 98, corresponding to I2C bus #3 at address 0x50.
We have been informed by the display manufacturer that our display has failed due to corrupted firmware in the EDID space, where “zeros” (0x0) were found. We have requested the manufacturer to secure the display from further writing, but we are also exploring options to prevent random writing in the driver or kernel code.
Is there any guidance or path available to help us block this unwanted writing in the display driver or kernel? We would greatly appreciate any assistance or recommendations in resolving this issue.
Someone from NVIDIA would have to answer that. I can tell you though that if the bus is wrong during an i2c write, it could at least attempt to write to the i2c of the DDC wires (the data being written might be recognized if you look below at the i2c analyzer option). Most monitors would expressly reject this write. If for some reason the monitor did not reject that write, then I suspect an error in device tree setup or i2c power bus setup has swapped something. Maybe it is as simple as a pin which normally goes high or normally goes low during some state, but it is inverted when not used. Don’t know.
Something which would be useful, since you’ve stated that it is a copy of the dev kit reference carrier board, would be this combination:
- Serial console boot log without the monitor.
- Follow “
dmesg --follow”, and note which log lines show up as a result of plugging in the monitor. One would be able to track hot plug events and previous i2c setup.
If you have an i2c protocol analyzer, then consider tracking what traffic occurs upon HDMI plugin. Compare that to the traffic which occurs if HDMI is plugged in before even starting. Make sure to monitor the power rail for the DDC during both tests. I think someone from NVIDIA could spot what is going on from that.
I would also double check any device tree settings related to i2c.
Incidentally, since the monitor is already corrupt, it would not hurt to monitor traffic to it.
Thanks, I will order an i2c protocol analyzer to sniff the bus for suspicious writing.
I also wait to get more information from the Nvidia team, as I mention before the HDMI connection is copied from the dev kit.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.