GPIO address with respect to pin name

Autonomous Machines Jetson & Embedded Systems Jetson TX1
#1

Hello nVIDIA,

I’m looking for GPIO physical address for pin A17 and A18, they are listed under USB2.0, I’m referring to page 37 of DATA SHEET NVIDIA Jetson TX1 System-on-Module (DS-07224-010_v1.0).

If I bypass A18 with a resistor then USB3.0 works. If I know the address then I can have a tiny driver to set it to active high. The better way would be to do this through device tree under xusb. I’m not sure how to do it.

Any help is highly appreciated.

Thanks,
Hakim

#2

There is a pinmux file in download center (http://developer.nvidia.com/embedded/dlc/jetson-tx1-module-pinmux), you can find the pin A18. And why you need to keep A18 always high since it will be high automatically when USB device plug in?

#3

Our carrier board uses PCIe-1 as USB2/3. I’ve this file and I tried to generate DTS file in the past but found that it produced the same DTS file with and without our required changes. We need the following

unused_PEX_RX0N PEX1_RX0N USB_SS2_RXN USB_SS2_RXN
unused_PEX_RX0P PEX1_RX0P USB_SS2_RXP USB_SS2_RXP
unused_PEX_TX0N PEX1_TX0N USB_SS2_TXN USB_SS2_TXN
unused_PEX_TX0P PEX1_TX0P USB_SS2_TXP USB_SS2_TXP

Then I followed this thread

https://devtalk.nvidia.com/default/topic/925646/jetson-tx1/tx1-usb3-0-design/post/4864090/#4864090

to configure DTS file and got both USB2.0 and USB3.0 with the register bypass for USB1_EN_OC# pin. We really don’t want to this hardware change rather we’d like to use this pin USB1_EN_OC#, it does not go high when we connect USB device, it does not produce wake up interrupt and the whole USB is off. Let me know what I can do more.

Thanks,
Hakim

#4

Hello, Hakim:
You can change the GPIO output value by either:

  1. add code in kernel driver, request gpio pin, set output value of that GPIO pin.
  2. edit the file u-boot/board/nvidia/{board}/pinmux-config-xxx.h, check xxx_gpio_inits.

please take a look at “arch/arm64/boot/dts/tegra210-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi”
There’s the statement:
/*
* When booting with U-Boot, U-Boot will program the entire
* pinmux itself, based on its own configuration tables. To
* avoid the kernel performing redundant pinmux configuration,
* U-Boot deletes the pinctrl-names property above. In that
* scenario, all of the pinmux data below is ignored. In any
* other scenario, the following pinmux data is still applied
* by the kernel.
*/

br
Chenjian

#5

Hello Chenjian,

Thanks a lot for reply, it’s highly appreciated. The project on hold, I’ll be back at the end of this month again.

Hakim

#6