USB related clocks are sometimes unstable

We are working on custom carrier board for Jetson Nano module.

On our custom board, sometimes 10-second timeout may occur during the detection of an embeded USB-HUB in L4T Cboot, as shown below.

OK:
[0002.962] xhci0: 64 bytes context size, 32-bit DMA
[0003.002] usbus0: 5.0Gbps Super Speed USB v3.0
[0003.022] uhub0: <Nvidia XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
[0003.672] uhub0: 9 ports with 9 removable, self powered
[0004.712] uhub1: <vendor 0x0424 product 0x2514, class 9/0, rev 2.00/b.b3, addr 1> on usbus0
[0004.732] uhub1: MTT enabled
[0005.512] uhub1: 4 ports with 4 removable, self powered
[0006.902] failed to get HID devices
[0006.906] failed to init xhci or no usb device attached
[0006.913] display_console_ioctl: No display init

NG:
[0003.015] xhci0: 64 bytes context size, 32-bit DMA
[0003.055] usbus0: 5.0Gbps Super Speed USB v3.0
[0003.075] uhub0: <Nvidia XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
[0003.725] uhub0: 9 ports with 9 removable, self powered
[0013.055] get polling status timeout
[0013.058] failed to init xhci or no usb device attached
[0013.066] display_console_ioctl: No display init

For an embeded USB-HUB, it is connected to USB2_D_N/P (Pins 121/123).

connection:
USB2_D_N/P => embedded USB_HUB

In addition, when the NG occurs, there may be an additional wait of about 160 seconds before the U-Boot transition.

[0013.613] WARNING: Failed to pass NS DRAM ranges to TOS, err: -7
[0013.619] Updated memory info to DTB
[0013.628] set vdd_core voltage to 1075 mv
[0013.632] setting 'vdd-core' regulator to 1075000 micro volts
[0171.626] failed to get HID devices
[0171.646] Found secure-pmc; disable BPMP

U-Boot 2016.07-00023-g0614bca5a4-dirty (Jul 29 2020 - 15:20:18 +0900)

Furthermore, if the system is booted to Kernel, a -71 error always occurs and the USB-HUB is not recognized until power reset board.

Starting kernel ...

[    1.017551] tegradc tegradc.1: dpd enable lookup fail:-19
[    1.523398] Host read timeout at address 545c00c4
[    1.785582] imx219 7-0010: imx219_board_setup: error during i2c read probe (-121)
[    1.793122] imx219 7-0010: board setup failed
[    1.821274] imx219 8-0010: imx219_board_setup: error during i2c read probe (-121)
[    1.828793] imx219 8-0010: board setup failed
[    1.918284] pca953x 0-0075: failed reading register
[    2.315900] cgroup: cgroup2: unknown option "nsdelegate"
[    2.366007] usb 1-3: device not accepting address 2, error -71
[    2.698278] usb 1-3: Device not responding to setup address.
[    2.910034] usb 1-3: device not accepting address 3, error -71
[    3.513521] using random self ethernet address
[    3.526041] using random host ethernet address
[    3.886159] usb 1-3: device descriptor read/64, error -71

About this problem, we checked the waveform of USB D+/D- at the time of CBoot.
The pulse seems to be stretched out in some places like below.

OK

NG

Also, it seems to be resetting the USB several times until it reaches timeout.

OK


NG

Could you tell us how we should address this issue?

We dumped registers around the Clock and Reset (CAR) after the U-Boot transition.
As a result, we found that the following PLLU-related registers were always different when the problem occurred.

OK:
U-Boot # md 0x60006000
60006000: 00000800 1c93428a 00000000 028ec5d2    .....B..........
60006010: 80409171 020080c1 81f00228 00000000    q.@.....(.......
60006020: 20008888 80000000 20004444 80000001    ... ....DD. ....
60006030: 00000001 00000000 00000000 00000000    ................
60006040: 00000000 00000000 00000000 00000000    ................
60006050: 50000011 00000000 00000000 00000493    ...P............
60006060: 00000000 00000000 00005c00 00000010    .........\......
60006070: 00000000 00000002 00000000 00000000    ................
60006080: 00108002 00000002 40000000 08000000    ...........@....
60006090: 4c007d03 00000000 00000000 00000010    .}.L............
600060a0: 48115408 00000003 00030003 00040010    .T.H............
600060b0: 00803003 00000002 00000000 12000000    .0..............
600060c0: 4be11902 00020003 00000000 60000000    ...K...........`  //CLK_RST_CONTROLLER_PLLU_BASE_0
600060d0: 00211001 00000000 00000000 00040000    ..!.............
600060e0: 48003502 00040000 0e007d02 00006200    .5.H.....}...b..
600060f0: 00000000 00000000 00000000 00000000    ................

NG:
U-Boot # md 0x60006000
60006000: 00000800 1c93428a 00000000 028ec5d2    .....B..........
60006010: 80409171 020080c1 81f00228 00000000    q.@.....(.......
60006020: 20008888 80000000 20004444 80000001    ... ....DD. ....
60006030: 00000001 00000000 00000000 00000000    ................
60006040: 00000000 00000000 00000000 00000000    ................
60006050: 50000011 00000000 00000000 00000494    ...P............
60006060: 00000000 00000000 00005c00 00000010    .........\......
60006070: 00000000 00000002 00000000 00000000    ................
60006080: 00108002 00000002 40000000 08000000    ...........@....
60006090: 4c007d03 00000000 00000000 00000010    .}.L............
600060a0: 48115408 00000003 00030003 00040010    .T.H............
600060b0: 00803003 00000002 00000000 12000000    .0..............
600060c0: 4be12502 00020003 00000000 60000000    .%.K...........` //CLK_RST_CONTROLLER_PLLU_BASE_0
600060d0: 00211001 00000000 00000000 00040000    ..!.............
600060e0: 48003502 00040000 0e007d02 00006200    .5.H.....}...b..
600060f0: 00000000 00000000 00000000 00000000    ................

The value of PLLU_DIV seems to be different.

reg											addr		OK			NG
CLK_RST_CONTROLLER_PLLU_BASE_0				0x600060c0	0x4be11902	0x4be12502
CLK_RST_CONTROLLER_OSC_FREQ_DET_STATUS_0	0x6000605c	0x00000493	0x00000494

Refer to [Tegra_X1_TRM_DP07225001_v1.3p.pdf]…

PLL_U must be properly configured in the Boot ROM. DO NOT change the parameters of
PLL_U while the unit is running. The same applies to the USB_PHY_PLL.

How does Boot ROM set the PLL_U value?
Why do PLL_U values sometimes differ?

Is it possible to resolve the -71 error by resetting the OK value to the PLL_U on the Kernel?

I know that CBoot’s source code is Non-public.
Is there any workaround from SW on this issue at CBoot?
Is it possible to change the behavior of CBoot’s PLL settings, for example, by modifying the DTB?

Hi shinichiro.adachi,

I think firstly we need to know

  1. Why and how does this issue happen to your board only but not to other users’ carrier board. Is there any special design on your board that causes this problem?

  2. Why do you check cboot? Do you need the usb functionality in cboot? If you don’t need it, is disabling usb init in cboot could resolve this issue?

Hi WayneWWW,

1.Why and how does this issue happen to your board only but not to other users’ carrier board.
Is there any special design on your board that causes this problem?

Our board just connects USB2_D_N/P (Pins 121/123) to Embedded-HUB directly.

20200722_JetsonNano_CustomBoard_SCH_USB_part1


I found similar issues below.


2.Why do you check cboot? Do you need the usb functionality in cboot?

No, it’s not necessary at all. We want to disable usb detection at CBoot.
But source code of CBoot is non-public.
Now we only use following prebuild binary in L4T.

Linux_for_Tegra/bootloader/t210ref/cboot.bin

Could you tell me how to disable usb init in CBoot?

If you don’t need it, is disabling usb init in cboot could resolve this issue?

Even if nothing is connected to USB2 port in Bootloader,
the -71 error occurs if a USB device is connected after booting Linux Kernel.

I think this is because PLL_U(0x600060c0) irregular value still remain after booting Linux Kernel.

Hi,

There is a simple way to disable it in cboot. Please go to flash_l4t_t210_emmc_p3448.xml and remove below line.

< filename> rp4.blob < /filename>

After this step, cboot will not have xusb firmware so the initiation will not work in cboot.
Please see if it can workaround your issue.

Hi,

There is a simple way to disable it in cboot. Please go to flash_l4t_t210_emmc_p3448.xml and remove below line.

Thank you for your advice.
Temporary I wiped out RP4 partition.

root@root-desktop:~# dd if=/dev/zero of=/dev/mmcblk0p11
dd: writing to '/dev/mmcblk0p11': No space left on device
513+0 records in
512+0 records out
262144 bytes (262 kB, 256 KiB) copied, 0.0549181 s, 4.8 MB/s

And confirmed that disabled usb initialization in CBoot like below.
The bootup time is also faster!!

[0002.534] xusb is supported
[0002.540] error while finding nvidia,portmap
[0003.044] firmware blob is not loaded and initialized
[0003.049] no usb firmware found on blob
[0003.053] xhci0: Could not load usb firmware
[0003.069] xhci0: WARNING: Probe and attach failed!
[0003.073] failed to init xhci or no usb device attached
[0003.081] display_console_ioctl: No display init

This seems to solve the problem with CBoot. Thanks again!

However, we have concerns about the following.

  1. Our board has one USB 3.0 Host port.
    There seems to placed the firmware blob of XUSB in RP4, but even if I remove it, will it not affect the USB3.0 function of the Linux kernel? Is CBoot the only one that references RP4?

  2. Even if we disable USB initialization with CBoot, the -71 error occurs after kernel startup.
    The reason for this is probably that the PLL_U value is 0x4be12502, which is different from the usual.

    U-Boot # md 0x60006000

    600060c0: 4be12502 00020003 00000000 60000000 .%.K…`

    [ 1.896202] pca953x 0-0075: failed reading register
    [ 2.324376] cgroup: cgroup2: unknown option “nsdelegate”
    [ 2.357971] usb 1-3: device not accepting address 2, error -71
    [ 2.898005] usb 1-3: device not accepting address 3, error -71

20200730_No_XusbFirmware_but71error.txt (21.4 KB)

Could you give me some advice on this problem?

Hi,

There seems to placed the firmware blob of XUSB in RP4, but even if I remove it, will it not affect the USB3.0 function of the Linux kernel? Is CBoot the only one that references RP4?

Dumping the dmesg could tell you whether the usb firmware in kernel is still working or not.
It should still work. But you should check it by yourself directly.

Even if we disable USB initialization with CBoot, the -71 error occurs after kernel startup.
The reason for this is probably that the PLL_U value is 0x4be12502, which is different from the usual.
U-Boot # md 0x60006000

600060c0: 4be12502 00020003 00000000 60000000 .%.K…`

[ 1.896202] pca953x 0-0075: failed reading register
[ 2.324376] cgroup: cgroup2: unknown option “nsdelegate”
[ 2.357971] usb 1-3: device not accepting address 2, error -71
[ 2.898005] usb 1-3: device not accepting address 3, error -71

We need to check this with internal team.

1 Like

Hi,

Just notice you have filed similar issue here.

Please use that topic to track the remaining issue directly.

1 Like