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.
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
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
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.
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!
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.
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.