We are using a custom carrier board with the Jetson TX2 configured for USB/PCIe lane config 5. We achieved the configuration by changing ODMDATA from 0x1090000 to 0x2090000, along with some device tree changes. The changes work well in normal use, i.e. we have 3 PCIe devices working along with USB2 and USB3 hubs.
However, once the unit has been flashed using this ODMDATA value, it cannot be flashed again. The console shows a hang in the TBoot-CPU recovery, e.g. when using the following command on the PC to update the device tree:
sudo ./flash.sh -k kernel-dtb jetson-tx2 mmcblk0p1
These are the last few lines of the console output from Jetson:
[0028.663] I> tegrabl_usbf_priv_init:2583 full init:: [0028.667] I> SUPER SPEED
[0028.703] W> FAILED IN WAIT FOR EVENT err = 0x178bc02c
[0028.708] E> usbf_enum failed err = 0x178bc02c
[0028.713] E> Failed to open transport
[0028.716] I> exiting nv3p server
[0028.719] E> Failed to open nv3p socket
[0028.723] C> RCM boot failed
[0028.726] C> ERROR: Highest Layer Module = 0x17, Lowest Layer Module = 0x17,
Aux Info = 0x0, Reason = 0x11
[0028.735] I> TBoot-CPU Recovery hang
When using the original value of ODMDATA (0x1090000) then flashing completes, e.g. a successful console output:
[0033.513] I> tegrabl_usbf_priv_init:2583 full init:: [0033.518] I> SUPER SPEED
[0044.294] I> transport_usbf_priv_open USB configuration success
[0044.359] I> Writing kernel-dtb partition
[0044.362] I> Total write size is 278016 bytes
[0044.395] I> Write successful.
[0044.428] I> Rebooting : reset-coldboot
The standard Jetson carrier board does not exhibit this problem, so something on the custom carrier board is causing TBoot to fail, perhaps it is one of the USB hub devices. I cannot disable these hub devices as they are connected to a system reset signal.
If I could achieve USB/PCIe lane config #5 using the original value of ODMDATA (0x1090000), then I would take that approach, but from what I have read on the forums, I believe this is not possible - anyone please correct me if I am wrong. Is it not possible to change lane ownership as the kernel boots instead of changing ODMDATA?
If I had the source code for TBoot then I could add some more diagnostics.
We are using L4T version R28.2.1.
Any solutions, suggestions, or other forms of help would be most appreciated.