USB Not working from Jetpack 5 -> Jetpack 6

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
1

Bringing up a new board with AGX Orin Industrial on a custom carrier board.

When flashing with SDKManager on ubuntu 22 with Jetpack 6.1, lsusb is empty, and no xusb devices are discovered / registered at boot. The USB C ports properly turn on and supply power, but no data seems to be transferring.

Tried with Ubuntu 18 Jetpack 5.1.4 SDKManager and after flash, the usb C hubs are properly discovered at boot, show up in lsusb, and recognize / mount external drives.

For both configurations, I changed ODMDATA to remove gbe, and set the eeprom read size to 0, no other modifications have been made.

Can’t seem to find any information on why this could be on the forums or elsewhere, would appreciate a pointer in the right direction

2

Hi,

If you are designing a custom base board, then it means some adaptation configurations are needed.
Otherwise, your board may not work fine.

For Orin AGX series, you could refer to below document
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=universal%20serial%20bus#jetson-agx-orin-platform-adaptation-and-bring-up
(please be aware that above link is for rel-36.3/jetpack6.0)

This document includes below configuration

  1. pinmux change & GPIO configuration
  2. EEPROM change as most custom boards do not have an EEPROM on it.
  3. Kernel porting
  4. PCIe configuration
  5. USB configuration
  6. MGBE configuration
  7. RGMII configuration

Thanks!

3

Hi,
I’ve been following this guide to get up to speed for a week or so, but I didn’t seem to need any usb configuration, since our pin mappings on our board match the ones from the pinmux spreadsheet already, which explains why they work in jetpack 5. My main question is how to track down what’s so different in jetpack 6 that they no longer work?

Should I diff the devicetrees between the jetpack 5 and 6 builds to investigate? Is there some other thing I can use?

5

Just one question. Does your carrier board use Cypress PD controllers as NV devkit carrier board to control the type C port?

6

image
We use standalone USB mux HD3SS2522RHUR to connect to USB type-C connector, which should automatically handle 5v and orientation.
What modifications would I need to make to the typec to get it to work? Do I even need that block?

7

Just to clarify the concept first

  1. It is not correct even in rel-35 on your board. Default device tree provided by us is only for NV developer kit. NV devkit is using cypress PD for both type C ports. If that thing didn’t exist on your board, then you should modify device tree.

  2. Sometimes driver have error tolerance that it can still run even your device tree is only partially correct. That is the case on rel-35. But on rel-36, the upstream kernel driver does not allow such thing anymore. Thus, your usb is not working anymore.

  3. There is document here for how to modifying device tree.
    Jetson AGX Orin Platform Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide 1 documentation

8

Since we are just using the HD3SS2522RHUR mux and not the Cypress PD chip, could you please assist us in what modification we need to do to the below

typec@8 {
    status = "okay";
    compatible = "cypress,cypd4226";
    firmware-name = "nvidia,jetson-agx-xavier";
    reg = <0x08>;
    interrupt-parent = <&gpio>;
    interrupts = <TEGRA234_MAIN_GPIO(Y, 4) IRQ_TYPE_LEVEL_LOW>;
    ccg_typec_con0: connector@0 {
        compatible = "usb-c-connector";
        reg = <0>;
        label = "USB-C";
        data-role = "host";
    };
    ccg_typec_con1: connector@1 {
        compatible = "usb-c-connector";
        reg = <1>;
        label = "USB-C";
        data-role = "dual";
        port {
            #address-cells = <1>;
            #size-cells = <0>;
            port@0 {
                reg = <0>;
                hs_ucsi_ccg_p1: endpoint {
                    remote-endpoint = <&hs_typec_p1>;
                };
            };
            port@1 {
                reg = <1>;
                ss_ucsi_ccg_p1: endpoint {
                    remote-endpoint = <&ss_typec_p1>;
                };
            };
        };
    };
};
9

Please seek the vendor for that HD3SS2522RHUR mux software solution.

We won’t know how to program a arbitrarily usb mux. This needs the help from the vendor.
Just like we had the help from Cypress for their PD controller to write their DT.

10

It does not need programming. We were asking if we were to drop the cypress PD check, what changes do we have to make to the device tree.

11

You definitely need to remove the remote endpoint between this ccg_typec_conX and the usb driver part.

The rest of things depend on your schematic and you need to read the document to modify.

Things may not be that easy to just “drop Cypress PD and everything would work fine”.

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.