Hi all,
when trying to use the initrd flash method (e.g. for use with the new mass-flash method introduced in JP5) for flashing a Jetson Xavier NX on our own carrier board implementation, we run into the issue that the host system is waiting infinitely on booting up the target boards.
While reading through the forum, it came out that there was a faulty / contra-dictional description in the legacy L4T Documentation (Jetson Module Adaptation and Bring-Up: Jetson Xavier NX Series — Jetson Linux
Developer Guide 34.1 documentation (nvidia.com)) and the Xavier NX DevKit Board Reference Schematics. In short words:
- to use a USB Port as a OTG Port (as mentioned in the recent L4T docs), an ID Signal has to be connected to the corresponding Pin on the USB-Connector. Because in the reference schematics, no such pin is connected but the default image is configured to use the port in OTG Mode, this implementation is and was dysfunctional for the Xavier NX DevKit carrier board.
- Because we aligned our carrier board schematics to the reference, we also don’t have this pin on our board connected.
Our customer needs this implementation for mass-flash purposes, so we think about:
- using an unused GPIO pin to strip a signal to the ID Pin on the Micro B Connector as shown in For an on-the-go port
- modify the DT to use this pin as shown in The USB Connector Class
Following this documentation, we run (again!) in several issues:
- The used GPIO_Q0 Pin is non-existent in pinmux, reference board schematics or signal/pin mappings in DT
- In Jetson Module Adaptation and Bring-Up: Jetson Xavier NX Series — Jetson Linux Developer Guide documentation (nvidia.com), the used pin is GPIO_PZ1?
Furhermore, other than experienced with all L4T BSP version prior than 35.1, in 35.3.1 there is written:
This is the
USBConnectorClassdevice node and property list based on the device tree structure and the table of GPIO states and corresponding output cable states for GPIO_PZI that is customized for Jetson Xavier NX, where the ID pin that is floating the port is fixed in the device role:
So, beside mentioning the misleading issues above, we currently want:
- to know which pin we can actually use
- and if we need further configuration beside the one found in the L4T Documentation?
