I am working with a custom carrier board which resembles a simplified Dev Kit.
At this time, I have an issue with the HDMI interface which causes the system to fail to detect the NVME Memory devices when connected. We have tried a HDMI analyzer device between the Jetson Board and the monitor.
This is giving us inexplicable results. With just an unconnected HDMI cable, The debug serial port gets to a login state and properly acts as a serial terminal. With the Analyzer in place, I get a unexpected termination of activity with the processor being shut down. I would like to understand what the system is complaining about when the following is posted:
ERROR: Exception reason=0 syndrome=0xbe000011
ERROR: **************************************
ERROR: RAS Uncorrectable Error in IOB, base=0xe010000:
ERROR: Status = 0xec000612
ERROR: SERR = Error response from slave: 0x12
ERROR: IERR = CBB Interface Error: 0x6
ERROR: Overflow (there may be more errors) - Uncorrectable
ERROR: MISC0 = 0xc4520040
ERROR: MISC1 = 0x6cc860000000000
ERROR: MISC2 = 0x0
ERROR: MISC3 = 0x0
ERROR: ADDR = 0x8000000003f400c0
ERROR: **************************************
ERROR: sdei_dispatch_event returned -1
ERROR: **************************************
ERROR: RAS Uncorrectable Error in ACI, base=0xe01a000:
ERROR: Status = 0xe8000904
ERROR: SERR = Assertion failure: 0x4
ERROR: IERR = FillWrite Error: 0x9
ERROR: Overflow (there may be more errors) - Uncorrectable
ERROR: ADDR = 0x8000000003f400c0
ERROR: **************************************
ERROR: sdei_dispatch_event returned -1
ERROR: Powering off core
When the HDMI is connected, the system boots to the EUFI loader and can be convinced to go to shell instead of looking for bootp servers on ethernet.
When in shell, the map command only shows
F51: Alias(s) F1:
MemmoryMapped(0xB,0x47200000,0x47230FFFF)
F52: Alias(s) F0:
Fv(49A79A15-8F69-4BE7-A30C-A172F44ABCE7)
with no persistant storage seen.
Debug logs attached
Is there a process to share proprietary information with NVIDIA only? I am expecting the block diagram to be available shortly, but the schematic might take more persistance. It is my understanding that items posted here are available to anyone.
You’re correct that anything posted here would be public.
A higher level diagram showing just the HDMI and NVMe connections would be helpful for us to better understand your setup. Can you share the HDMI analyzer model/part number? Schematics should not be needed right now.
The HDMI analyzer is a BZBGEAR model BG-AVTPG_MINI-G2.
The remote HW guy tells me that HDMI cables from different vendors produce different results, none functional. The one is use has the name ANKER molded into the connectors.
A hot connect to HDMI analyzer causes the the system to reboot and then fail with the same “Powering off Core” diagnostic
Still hoping for some idea of which lines could cause this issue, If you suspect board crostalk, please tell me. We are using a rather condensed backbplane but it has been designed for just this kind of product.
I will suggest that because a plug-in/hot plug event triggers an i2c query using power from the Jetson (monitors use the HDMI to power their queries of capability so they can function even when turned off) that you start by looking at the power for the DDC query. Does the voltage look correct prior to plug-in? If the monitor is plugged in from the start, and not hot plugged, what does the voltage for powering this i2c look like, e.g., is it correct and stable?
If it is, try putting an i2c analyzer in the DDC and looking to see if the traffic is correct when powering on with the monitor already connected.
Try powering the i2c from your own external power source, but still having the DDC traffic otherwise working normally (perhaps with an i2c analyzer in the line).
Basically, try to find out if the power provided by the HDMI is related to the failure. If not, then check if the i2c traffic is valid. If it is valid, and if the DDC query is not causing a failure through pulling too much current in the i2c query, then try to simply provide a manual trigger of hot plug and see if the GPIO related to the hot plug pin itself is a triggering event. If hot plug is causing the issue via the detect pin, then you can look at both wiring and device tree for that specific pin.
If the i2c can be powered, triggered, and function when only this is used, then you know it is about the other wiring. If this is what fails, then you are kind of lucky because the issue is probably about detection and i2c issues rather than the rest of the wiring.
Different cables acting differently though does tend to say there is some sort of signal issue, but you can at least look at things like clocks and see if it seems plausible that the connection should work; if clocks are wrong, or perhaps have low quality waveforms, then you have something simpler to debug (you could check waveforms at various locations along the route). It’s just a way to look at the HDMI in pieces rather than all at once.
