Deploying with L4T/flash.sh breaks on my carrier board

Hi crevit,

Sorry that I didn’t follow all your thread previously since there are multiple users here.

We need t clarify each person’s case. For Undertow10, we already knew that he puts a HUB on PEX_RFU and USB1.

Could you also briefly introduce your current status?

Hi Undertow10,

Can you pls share the schematics of usb hub chip on USB_SS1 lines and on USB_SS0 lines?

Hi Trumany,

The USB Hub chip on our non-functional boards is on PEX_RFU pins, not USB_SS1 or USB_SS0. We do have another device on USB_SS1. USB_SS0 is unused, as we need those lanes for PEX1 instead.

Are you asking for our schematic of the working board or the non-working board?

What specifically are you looking to learn? I posted the TX2 pinout portion of our schematics in post #25.

sorry typo, should be config USB_SS#1 = PEX_RFU port. We are investigating why the usb hub on PEX_RFU lines will cause flashing on USB0 port fail as you said. If you can share the connection of this hub board, will be helpful to understand.

Our schematic is attached. I’ve edited a few pages together to simplify the viewing.

Trumany, It looked like you were replying to my post about a similar situation to Undertow’s. I can’t easily get you a schmatic until after Dec 1. But I can give you an Idea about the specifics of our carrier and how the behavior is different than that which undertow sees.

crveit                                             undertow
a. Config5                                            config3
b. usb3-0  unused                                     unused
c. usb2-0 used as otg port                            assume it is the same
d. usb2-1 and usb3-1 go to TUS8041 hub                Unknown Device on port1
e. usb2-2 goes to a TUS4041 hub                       USB2-2 and USB3-2 to a hub
f. the usb3-2 is not used for config5 (pcie)

I am a little uncertain which port the PEX-RFU lines are used for but if they are for USB3-2 we are not using them but do see similar issues flashing. The odd thing about our carrier is that we can flash the original Nvidia system to our board (config2) but when we flash our config5 payload the flash hangs as shown in the first couple post on this thread. Holding both hubs in reset during forced recovery mode allows the flash process to work for config5 images. (With how early in the flash process this happens I am not sure what has actually been sent over to the TX2i. Perhaps the ODMDATA and maybe the Pinmux config Although the only change I can think of in our pinmux file is enabling AUD_MCLK for audio use. So, this is probably related just to the ODMDATA!? I doubt the DTB file has been sent and that is where all the big changes happen.)

Seeing Undertow’s experience and mine makes me think that any signals on either USB3-1 or USB3-2 can cause problems during the Flash process (When ODMDATA has been changed to something other than config2).
Hope that info helps you figure this out.

Hi crveit,

Which port is using for flash on your board? Are you using this one?
>>usb2-1 and usb3-1 go to TUS8041 hub

>>The odd thing about our carrier is that we can flash the original Nvidia system to our board (config2) but when we flash our config5 payload the flash hangs as shown in the first couple post on this thread.

Could you share what is the difference between config2 and config5 payload?
I guess it is the dtb and ODMDATA, right? If so, could you help do experiment…

Test

  1. Fix the dtb and vary the ODMDATA only.
    -> Use the same dtb but different ODMDATA of config 2 and config 5. Flash the board to see if which can/cannot work

  2. Fix the ODMDATA and vary the dtb.

>>Holding both hubs in reset during forced recovery mode allows the flash process to work for config5 images.
Why need to put “both hubs” in reset? Will it work if you only put one hub to reset during forced recovery mode?

No special findings in SCH. So it is important to keep USB pin status unchanged during power on if add a hub to any port. Power on hub later or set the pins of hub to high-Z might be the solution.

Hi Undertow10, can you pls share the SCH of USB0 port? Thanks.

USB0 port attached.

Hi Undertow10,

We just confirmed with internal team… There is no support for USB1 as flash port.

Hi Wayne,

We are not using USB1 as flash port. We are using USB0 as flash port, as shown in my schematic.

Sorry that I have not been as responsive on this thread. Wayne asked a few posts ago what USB port we were using to flash. We are also using USB2-0 just like the nvidia carrier and like undertow’s as well. seems like the only difference is that the target board config for each of us. Our USB2-0 is used as a USB2 only port in OTG mode config5. After using the clue that undertow10 gave about holding any hubs hooked up to the other ports in reset during flash I have been flashing on our boards with great success. I’ll try to keep participating here when I have time. unfortunately I have another high priority bug to kill before Christmas.

Happy Holidays to all of you! Thanks for all the help here in the forum!

Hi Undertow10,

Then I don’t get your confirmation in #30. In #29, I asked you to confirm

  1. The working board:
    USB Hub + USB_SS0+ USB1 -> working
    No Hub + USB_SS0+ USB1 -> working

  2. The NG board:
    USB hub + PEX_RFU +USB1 -> NG
    No Hub + PEX_RFU+ USB1 -> working

and you told me “yes, that’s correct” in #30.

Could you confirm again?

We have an internal USB hub chip connected to USB1 + PEX_RFU. The flash operation happens over USB0.

  1. The flash operation on USB0 fails if the USB hub chip is connected to USB1 + PEX_RFU.

  2. On an older PCB revision, the flash operation on USB0 worked fine if the USB hub chip was connected to USB1 + USB_SS0.

I just checked with internal hardware team and found no error in your design.

Thus, I think this issue might be related to uphy mapping. However, unlike what we did in kernel/dtb/ODMDATA in adaptation guide, such programming should be done in bootrom or bootloader. Thus, it is a new issue.

We will put more resources into this issue internally. Thanks for your patience.

Hi crveit and Undertow10,

Sorry for late reply. Are you still working on this? I would like to share a binary for you to test.
Also, what release are you using now?

Hi Wayne,

We’ve worked around it by disabling the USB hub with a spare GPIO pin that is not activated until the kernel boots. We’ve been shipping with this fix since December, and changing our process now would just complicate things.

I’m happy to test a binary, but it may be a little while until I can get to it.

Thanks!

Hi Undertow10,

Which release are you using? Our binary is for your last design with hub.

Hi Undertow10,

Please try to flash with below binary file replaced under Linux_for_Tegra/bootloader/.
nvtboot_recovery_cpu.tar.gz (99.4 KB)