I want to init and configure pinmux pins in uboot,how i will generate this pin mux file in TX2,where all the details of pins are given.
i want to define in below folder
You can directly configure the pinmux by the cfg file generated by spreadsheet.
so if we have to done any changes in pinu mux configuration i have to first do changes in pinmux sheet and then i have to genertate this pinmux conf file,right?
Any spreadsheet available for GPIO also?so on uboot i have to do pin mux configuration and gpio setting both like TX1?
The pinmux spreadseheet includes all the available pins on Jetson TX2 module. It means GPIOs are included too.
so this below pin mux conf file for TX2 4Gb is already writing in emmc during flashing so i dont have to do anything for that it will automatically set all pin during bootup,right?
actually I am not sure whether your board is using this file or not. But if your flash log shows this cfg, then this is the one in use.
i have downloaded the pinmux sheet
how i will map a pin from actual tegra pin of main board.
if i take example of pin GPIO9_MOTION_INT
GPIO9_MOTION_INT G14 CAN_GPIO2 E30 F28 unused_CAN_GPIO2 GPIO3_PAA.02
what will be the actual pin number for pin GPIO9_MOTION_INT.
will it be PAA pin or something else,i need proper pin on tegra so that i can
calculate actual pin number from gpio offset.
The Pin # is G14 (see column B). The GPIO is AA.02 (see column G after the GPIO3_P part of the naming).
so for all pins that is defined in pinmux sheet its gpio name is GPIO3_P part of the name,i can pick GPIO name from here,right?
so for GPIO9_MOTION_INT ,GPIO is AA.02
for AA pin AON GPIO controller: #define TEGRA_AON_GPIO_PORT_AA 5
so actual GPIO number in tegra device i can calculate is = 256 + 5*8 +2 =398
The same way i can calculate all pins GPIO number for tegra device,is it correct?
Well, you don’t have your math quite right. :-)
256 + 5*8 + 2 does not equal 398.
256 + 5*8 + 2 does equal 298.
It’s much easier to create a simple table in a spreadsheet or other mechanism that you can just lookup. Take a look here for a simple and reliable way you can track down those #s:
it was my typo mistake and thanks for this simple table it is very useful…
one thing i want to ask,if i have to change any pin configuration in pin mux spread sheet,so should i do changes in spread sheet and generate .cfg file or we can directly do changes in pinmux .cfg file???
As per my custom board design i want to change pinmux file…tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg
in pinmux sheet of TX2 for many pins they have not given GPIO name for that pins how we can calculate actual GPIO number.
lets take Example of pin F7,A49 how it will get its actual pin number in TX2
Most of them can be found by examining
Unfortunately, if you check out Why some pins should have GPIO function but not marked in TX2 pinmux document? it looks like NVIDIA has removed their own/my spreadsheet with all of the GPIOs listed properly because “it was flagged as potentially malicious”. If I try to re-upload the file they flag it again as being dangerous. I can try sending it to you directly if you would like.
F7 = GPIO N.02
A49 = ???
I’m not sure where you got this pin number. Are you working on the Jetson TX2?
yes i am working on Jetson TX2 4GB module,i am not able to get gpio number of many pins,for below pins they have not given any information.
SPI2_CLK - H14
SPI2_MISO - H15
please send the file it will be helpful.
my email id - firstname.lastname@example.org
So here is how you find those GPIO names:
- Open up
- Find the IC Ball Name in the pixmux xlsm of the interested pin/signal.
- For SPI2_CLK/H14, you should see
C175of the pinmux xlsm spreadsheet.
- Search for “gpio_wan5” in the .cfg file.
- You should find:
pinmux.0x0243d018 = 0x00000402; # gpio_wan5_ph0: spi1, tristate-disable, input-disable, lpdr-disable
- The GPIO is the in the comments after gpio_wan5_p.
- The GPIO is H.00 in this case.
Repeated for SPI2_MISO/H15:
- For SPI2_MISO/H15, you should see
C176of the pinmux xlsm spreadsheet.
- Search for “gpio_wan6” in the .cfg file.
- You should find:
pinmux.0x0243d010 = 0x00000456; # gpio_wan6_ph1: spi1, pull-down, tristate-enable, input-enable, lpdr-disable
- The GPIO is the in the comments after gpio_wan6_p.
- The GPIO is H.01 in this case.
Thanks for the explanation it is really very helpful.
one thing i want to ask for this pin mux sheet of TX2 ,this sheet is for TX2 EVK.
I have my own customized board in which i have used TX24GB module,so i need to update this pin mux sheet as per my custom board right?
And after that i need to create .cfg file with customized pin mux sheet.
Yes, the pinmux spreadsheet is for the default Jetson TX2 Development Kit.
It all depends how far you have deviated from the Jetson TX2 Development Kit design. If you have made minor changes, you may be able to make those in the DT and delay their initialization/configuration till the kernel boots. If you have made significant changes and need them early in the boot process, you would want to utilize the latest NVIDIA pinmux spreadsheet as your starting point and make your changes in the pinmux spreadsheet. Following all of your changes you use the built-in spreadsheet macro/button to generate the DTSI files. There should be plenty of information in the NVIDIA documentation and other forum posts to walk you step-by-step through the process of regenerating the pinmux .cfg file and programming it to your board.
some of the pins are not mentioned in pinmux sheet of TX2.
how i will get its actual pin number for below pins it is also not mentioned in the .cfg file.
These pins are mention in Jetson TX2 Series OEM Product Design Guide but i didnot get any entry for this in .cfg or pin mux sheet.
can you please help me on this.
There is a GPIO1_CAM_PWR#/F7 that is mapped to GPIO N.02. That is very close to your name.
Remember your interfacing with a SoM. Not every signal/pin on the SoM makes its way back to the Tegra X2 SoC. If a particular SoM pin is the output from the PMIC or a power supply (i.e., charging status, reset, etc.) they aren’t going to have SoC pins nor will they be controllable as GPIOs. Both
RESET_OUT# seem to me to be signals that would be exclusively driven by hardware components such as a PMIC. I would not be surprised if they don’t go all the way back to the SoC and they do not have a controllable GPIO associated with them.