Confusing Port/Pad/Lane/(U)PHY assignments in USB-Plattform Adaptation for Xavier NX

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
, ,
1

Hello,

we are developing a custom carrier board for the p3668 SOM based on the p3509-0000 Carrier-Board.
The Design is following the Guidelines found at the Nvidia Download Portal and only has a few modifications regarding:

  • USB
    • USB1 signal pairs → dedicated USB 2.0 Type A Adapter (no hub)
    • USB2 signal pairs + UPHY5 → dedicated USB 3 Type A Adapter (no hub)
  • DP only
    • the HDMI Display Out is replaced by a second DP-Out and should be used as the primary boot up display

While the Carrier Board Schematics are structured very clear and follow consistent Pin-Namings, the Platform Adaptation and Bring-Up Guide seems to follow some totally different notation, which are very confusing:

  1. According to the “Go through the Schematics” Chapter, USB1_D and USBSS_* Pins are connected to the USB3.1 Hub on the p3509 Board. In Reference Schematics, these are referenced as USB1 and UPHY5, whereas in the Guide, the conclusion is that:
- The USB2 signal pair is wired to `UTMI pad 1` (USB2 port 1).
- The USB 3 signal pairs are wired to `UPHY lane 1` (USB 3.1 port 2).

While the first statement seems rather logical (despite it is not clear what here the “pad” should be), the second statement speaks of lane 1 instead of UPHY4, and is enumerated as a “second” port (the NX only has one per default).

  1. Earlier in the Document, the sentence

As UPHY lanes are shared between PCIE, SATA, UFS, and XUSB, UPHY lanes must be assigned according to the custom carrier board’s requirements.

leads to the expectation, that a UPHY assignment could have been made, which is different to the notation in the
Schematics Ref.. But in contrast to the Guides for other Jetson Boards (e.g. TX2), the section explicitly lacks a
description of this configuration.

  1. Then,

The name of each parameter description subnode in pads and ports must be in the form <type>-<port_number>, where <type> is “usb2” or “usb3”, and <port_number> is the associated port number.

…but in the example, there is a node USB3-2 under pads/usb3/lanes, but a node USB3-0 under ports which is referencing to usb2 signals on Port 1 (probably this doesn’t mean the same in this and the aforementioned contexts)!

  1. The DT-Option is described by

nvidia,usb2-companion: USB2 port (0, 1, or 2) to which the port is mapped.

So which “port” is mapped here to which “port”? Why first signal names with leading incrementing numbers, and now only numbers?

  1. Additionally, according to the

Note: As the Realtek hub is always connected to the root hub port on a P3509, you need not control hub power, just enable it with VDD_3V3_SYS. Therefore, you must set dummy regulators for U7 on the P3509 carrier board.

…it should exists some dummy regulator reference in the example, but no vbus-supply or nvidia,oc-pin Options can be found in none of the nodes. Because we dont have a hub which is responsive on its behalf for these settings, we connect directly to an external Type A Connector, so we would probably need these settings properly configured (no dummy).

Nevertheless, no matter if we put a dummy or nothing, the USB3 Connector has no connection. This is indepently from the naming, port numbering or VBUS/OC settings we tried: all leads to the same result!

cfg-example-tegra194-p3509-disp.dtsi (3.1 KB)

For the configuration of the display outs, there is nearly no documentation targeting a dynamic assignment. A quick copy, paste/replace of the existing HDMI-Node in the DeviceTree /w the slightly adapted DP-Port Node leads to a dark Display at boot-up. Surprisingly, there exists a whole chapter of extracting some X11 values and transformations to .dts code, but none of the used Notations (“Windows”,“Head”,…) is explained, nor the reconfiguration to use custom display outs /w DP- or HDMI-Only is mentioned with a single word.

tegra194-p3509-disp.dtsi (3.0 KB)

Am I reading the wrong Docs, or could you please give me an insight which could perhaps lead me to a better understanding of these adaptation tasks?

Regards,
Jan

3

Hi,
For custom board design, please check product design guide:
https://developer.nvidia.com/jetson-xavier-nx-product-design-guide-v10

Table 6-3. USB SS and PCIe Lane Mapping is the reference and we suggest follow it.

4

We followed the guidelines but USB3 is not working. Also, the document clarifies only the UPHY assignment to lane 1 (see 2.) , but not the other questions!

5

For the display head and sor, you can directly read the TRM of jetson Xavier. It will have explanation about the concept of nvdisplay (head) and SOR.

There is no document to directly teach how to modify the display device tree. Generally, if you replace HDMI with DP, you just need to replace those set to HDMI to the DP.

For example, sor1 has “nvidia,active-panel” which was set to &sor1_hdmi_display. If HDMI_DP1 now is for a DP port, you should modify it to &sor1_dp_display.

For further error, you can share the full dmesg.

7

Ok, but where should i apply those changes? The only file in which the node “sor1” exists, is the root dts file which i get if decompile the generated dtb.

Doing the modification there cannot be a solution for production purposes, because u dont want to decompile and change the corresponding dts manually after each kernel compilation.

I followed the instructions given in the L4T User Guide and created an own cfg (and dts) file for our custom carrier board, but how to do any DT mods from there? If i add &sor1 { nvidia,active-panel = <&sor1_dp_display> }
to the dts, it won’t compile du to syntax errors.

It seems like the whole process of doing any kind of DT mods for the nvidia platform drivers is not explained anywhere. On other platforms i worked on, there was only one single dts and all modifications had to be made in there.
If there is a special way to do this for Tegra, why the docu stops with “create your own configurations as copies of existant”? Or am i missing some key information around this topic?

8

The source code is provided in the download center.
You can modify the dts there.

You may hit syntax error because you modify from the finalized dtb/dts directly which does not accept such &sor1_dp_display syntax.