Cannot flash Jetson TX2 when using ODMDATA for USB/PCIe Lane Config #5

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

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.

Thanks

2

Hi,
Please try clean re-flash.
Currently ODMDATA cannot be updated alone and we are checking it. Here is a relevant post.

3

Hi,

My latest testing reveals the following…

I cannot re-flash the module in the custom carrier with ODMDATA=0x2090000 in p2771-0000.conf.common using the following command:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

I get the same failure each time, a TBoot-CPU Recovery hang.

I can re-flash the module in the standard carrier board (699-82597-0000-501 = carrier revision B04) with ODMDATA=0x2090000 in p2771-0000.conf.common using the following command:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

I can re-flash the module in the custom carrier with ODMDATA=0x1090000 in p2771-0000.conf.common using the following command:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

However, there is something I don’t understand. With a new Jetson module as received from the supplier, historical testing has shown that:

I can re-flash the module in the custom carrier with ODMDATA=0x2090000 in p2771-0000.conf.common using the following command:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

So this last bit of information is confusing. Perhaps it should be treated as an anomaly that has less importance for now.

4

Hi clifffwv17,

I think it is more like a hardware design issue because the error in your flash log indicates it fails to do usbf_enum.

Does #3 imply this may be happen to different tx2 modules?

However, there is something I don’t understand. With a new Jetson module as received from the supplier, historical testing has shown that:

I can re-flash the module in the custom carrier with ODMDATA=0x2090000 in p2771-0000.conf.common using the following command:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

Could you make a clear comment or summary for what case can work/not work? Also, what is the jetpack release version you are using?

5

Hi,

This is what I know for sure at the moment using the command sudo ./flash.sh -r jetson-tx2 mmcblk0p1:
I cannot re-flash the module in the custom carrier with ODMDATA=0x2090000 in p2771-0000.conf.common.
I can re-flash the module in the standard carrier board (699-82597-0000-501 = carrier revision B04) with ODMDATA=0x2090000 in p2771-0000.conf.common.
I can re-flash the module in the custom carrier with ODMDATA=0x1090000 in p2771-0000.conf.common.

I have created a workaround for now. The command specified above causes these temporary files to be created:
br_bct_BR.bct and mb1_bct_MB1_sigheader.bct.encrypt
These are then downloaded to the target, and I assume these are stored somewhere temporary for the unit to boot into recovery mode with. These files contain ODMDATA. I have made a copy of these files when ODMDATA=0x1090000. I have changed the file tegraflash_internal.py to always use these copies. With this workaround in place, I have not seen any problem using the command specified above when using ODMDATA=0x2090000.

So I have this workaround, but I still have a problem when performing a partial flash, e.g. with command:
sudo ./flash.sh -k kernel-dtb jetson-tx2 mmcblk0p1
However, this is something I can probably live with.

There is a possible additional fix I can think of for this problem:
1/ Change the flash script to always send those files br_bct_BR.bct and mb1_bct_MB1_sigheader.bct.encrypt when performing a partial flash (or clone).

Another point I would like to make is that when the TBoot-CPU Recovery hang occurred, the console output mentioned SUPER SPEED. Why is USB forced recovery taking into account super speed USB (i.e. USB 3) when the carrier board only has a USB 2 micro B connector?

As usual, any useful feedback would be appreciated.

Many thanks.