TX1 bring-up issue on a new custom motherboard

Robotics & Edge Computing Jetson Systems Jetson TX1
1

I’ve an issue with a custom motherboard for a TX1 module.

Here is the test scenario:

  • TX1 module has been completely flashed on a TX1 Developer Kit and is functional. The Boot Recovery mode work fine for flashing and after flashing the Linux system is working.
  • I take the module and place it on my custom motherboard
  • Power-up without boot-recovery signal. All the power supplies are enabled by the module. I get the 1000 Mbps link on the GBE interface but I never have any outgoing activity on the network. I can’t ping the TX1.
  • Reset the board on force-recovery mode.
  • Power supplies are still OK, GBE link OK and the “nvidia” device appears on my Linux workstation.
  • If I try flashing the TX1 on my motherboard, the post-install script is stuck just after the message “Boot Rom communication completed” and nothing more happens.

I think that maybe something different stop the TX1 module during early boot phase either in normal or recovery mode (maybe a missing pull-up? another I/O which is used differently on my board?) but I can’t find any documentation about that.

My workstation setup is a VM but I suppose that if it works with the developer kit it’s not the issue. I also try several changes (using L4T 3.0 instead of 3.1, using Ubuntu 14.04 and 16.04, … but no change…)

Any idea?

2

hello cniclaes,

since you’re working with custom motherboard,
please refer to Jetson TX1 OEM Product Design Guide in the Jetson Download Center
thanks

3

What you are describing is not specific to a custom motherboard…this is an issue with using a VM host (a VM host is not supported). I do not know the details, but people who have made this work reported specifically naming the Jetson for pass through to the VM as USB2, along with increasing related USB buffer. Your custom board might work, the failure could be because of the VM.

4

Hello,

I found the issue and I share the solution since I think I won’t be the only one in the future.

The specific behavior I had was due to a conflict between strap-on option on UART signals (as described in OEM Manual on chapter 11.5) and a level-shifter device (TI TXS0104E) on these UART signals.

The TXS0104E chip is an “automatic” bidirectional level shifter that unfortunately integrates pull-up resistors on all ports that conflicts with strap-on pull-down options. I’ll change my design and use another level translator.