TX2 hdmi HDCP issue.

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

We enable the HDMI HDCP in the kernel with TX2 (R28.1). We run the X directly without the lightdm, but the HDCP authentication always fail. It is ok with TX1, it seems the kernel 4.4 have some sort of security layer than TX1.

[   36.345970] PD DISP2 index4 DOWN
[   36.346148] PD DISP1 index3 DOWN
[   36.346234] PD DISP0 index2 DOWN
[   36.467091] PD DISP0 index2 UP
[   36.467977] PD DISP1 index3 UP
[   36.468069] PD DISP2 index4 UP
[   36.469652] Parent Clock set for DC plld2
[   36.472748] tegradc 15210000.nvdisplay: hdmi: pclk:148500K, set prod-setting:prod_c_150M
[   36.574296] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   36.574301] nvhdcp: Error: Error opening trusted session
[   36.574304] nvhdcp: Error: nvhdcp failure - renegotiating in 1 second
[   38.050469] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   38.050473] nvhdcp: Error: Error opening trusted session
[   38.050475] nvhdcp: Error: nvhdcp failure - renegotiating in 1 second
[   39.050394] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   39.119755] nvhdcp: Error: Error opening trusted session
[   39.181828] nvhdcp: Error: nvhdcp failure - renegotiating in 1 second
[   40.258382] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   40.327825] nvhdcp: Error: Error opening trusted session
[   40.389812] nvhdcp: Error: nvhdcp failure - renegotiating in 1 second
[   41.466396] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   41.535827] nvhdcp: Error: Error opening trusted session
[   41.597842] nvhdcp: Error: nvhdcp failure - renegotiating in 1 second
[   42.674185] te_open_trusted_session:ERROR(-19) in tipc_create_channel
[   42.742567] nvhdcp: Error: Error opening trusted session
[   42.805898] nvhdcp: Error: nvhdcp failure - too many failures, giving up!
#2

Sorry in advance that DHCP is not enabled in any L4T based tegra BSP.
We cannot share experience here.

#3

Hi WayneWWW,
The problem should be separated with the “uvc camera issue”. Sorry, reply to the wrong thread.

Since we have the HDCP working for TX1 already. For TX2, from the TRM, it descried that the HDMI support both HDCP1.4 and HDCP 2.2, we are trying to make it work.

#4

Hi Wayne,

Does NVIDIA plan to support HDCP on a future TX2 L4T release? It looks like L4T R28.1 release supports HDCP with Android Trusty sessions but those are not supported on the L4T Linux platform, correct?

I’ve instrumented the kernel/display/drivers/video/tegra/dc/hdmihdcp.c file in R28.1 by disabling the CONFIG_TEGRA_NVDISPLAY #define locally in that file and adding some debug in the non-Trusty HDCP code sections. As reported by usaarizona the code fails at line 1514 with a “An key generation timeout”.

The timeout occurs when the code is waiting for either AN_VALID or SROM_ERR to be set in the NV_SOR_TMDS_HDCP_CTRL register after setting the RUN bit. Neither of those bits are set but the MPRIME_VALID and SPRIME_VALID values are set in the register.

A port of the L4T 24.1 version of hdmihdcp.c which runs correctly on the TX1 fails on R28.1 in exactly the same manner when run on the TX2. Are there any changes in the TMDS HDCP register set or behavior between the TX1 and TX2 that could account for this? The hdmi_reg.h file between the two platforms are essentially identical.

Thanks,

Paul

#5

Does NVIDIA plan to support HDCP on a future TX2 L4T release? It looks like L4T R28.1 release supports HDCP with Android Trusty sessions but those are not supported on the L4T Linux platform, correct?
-> Yes, HDCP is not supported on L4T. No plan for it either.

I’ve instrumented the kernel/display/drivers/video/tegra/dc/hdmihdcp.c file in R28.1 by disabling the CONFIG_TEGRA_NVDISPLAY #define locally in that file and adding some debug in the non-Trusty HDCP code sections. As reported by usaarizona the code fails at line 1514 with a “An key generation timeout”.

The timeout occurs when the code is waiting for either AN_VALID or SROM_ERR to be set in the NV_SOR_TMDS_HDCP_CTRL register after setting the RUN bit. Neither of those bits are set but the MPRIME_VALID and SPRIME_VALID values are set in the register.

A port of the L4T 24.1 version of hdmihdcp.c which runs correctly on the TX1 fails on R28.1 in exactly the same manner when run on the TX2. Are there any changes in the TMDS HDCP register set or behavior between the TX1 and TX2 that could account for this? The hdmi_reg.h file between the two platforms are essentially identical.
-> Please refer to TX2 TRM and TX1 TRM for this part.

#6

Hi Wayne,

Thanks for your reply.

I’m confused by your first answer. Are you saying that there are no plans to support HDCP in future L4T releases for the TX2?

Regarding the second response, I had already compared the TRMs between the two parts and the HDCP control register layout and semantics. They are identical hence the question.

Paul

#7

I cannot guarantee, but currently there is no plan.

#8

Thank you for the clarification.

#9

This is a problem for us. We’re developing a product which is used in applications where HDCP is required. This product is being sold on the TX1 platform, but we’re moving to the TX2 platform because the TX1 will not be available after a couple more years. Therefore, we have to have HDCP support on the TX2. The TRMs for the TX1 and the TX2 both seem to have identical support for HDCP, so why did it work on the TX1, but doesn’t work on the TX2?

We need help with this.

#10

Please contact nvidia sales for highlighting this problem. Thanks.

#11

Who should I contact at nvidia sales?

#12

Hi cdb83,

Assuming you’re located in US, please try https://www.nvidia.com/en-us/contact/

Thanks