r32.3 UBoot PinMux settings. Is documentation wrong?

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hi anyone

I refer to the r32.3 documentation link below.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fadaptation_and_bringup_nano.html%23wwpID0E0TR0HA

So I want to change the pinmux for boot and it seems that this has now changed although the documentation does not reflect this change. The documentation under the title “Pinmux Changes” and “Porting U-Boot” mentions that to change the pinmux config to include your new pinmux-config-.h to the board/// directory. Ok so that is all good and what I was used to prior to R32.3. But now in the U-Boot R32.3 source there is no pinmux-config-.h used in the board///.c any longer.

What am I missing here? Where do I now change my boot pinmux changes?

Is the documentation wrong now with r32.3?

Thanks.

2

Hi peterxr95h,

Yes, this pinmux initialization has moved to cboot so u-boot is not needed anymore.

You could directly change the pinmux in device tree. No need to specify it for u-boot.

3

Ok understand thank you Wayne.

So while here, does cboot use overlays or just the dtb?

I am having trouble making my pinmux and Gpio settings apply to the registers when using device tree. So I have been using the following commands to set the mux and Gpio pins after booting.

$ sudo busybox devmem 0x6000d408 32 0xa0 # set PS5 gpio (GPIO Controller 5, CNF 2)
$ sudo busybox devmem 0x6000d418 32 0xa0 # set PS5 (GPIO Controller 5, OE 2)
$ sudo busybox devmem 0x6000d428 32 0x20 # set PS5 (GPIO Controller 5, OUT 2) drive 1
$ sudo busybox devmem 0x6000d428 32 0x00 # set PS5 (GPIO Controller 5, OUT 2) drive 0

$ sudo busybox devmem 0x70003050 32 0x00 PINMUX_AUX_SPI1_MOSI_0
$ sudo busybox devmem 0x70003054 32 0x40 PINMUX_AUX_SPI1_MISO_0, input enable
$ sudo busybox devmem 0x70003058 32 0x00 PINMUX_AUX_SPI1_SCK_0
$ sudo busybox devmem 0x7000305c 32 0x00 PINMUX_AUX_SPI1_CS0_0

Thanks.

4

I think it only reads the dtb. What problem do you hit?

5

Ok thanks,

The devmem writes in my above post to the SPI PINMUX_AUX_SPI1 enable my SPI pins and spidev is controlling the pins/peripheral ok. I know there are plenty of posts regarding SPI but I am just using SPI as an example here. If I do not do the devmem writes then the pins are not configured as sfio. But I thought that the pinmux entries in the DTS files were to do this when setup as per below.

pinmux: pinmux@700008d4 {
	pinmux_default: common {
		spi1_mosi_pc0 {
			nvidia,pins = "spi1_mosi_pc0";
			nvidia,function = "spi1";
			nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
			nvidia,tristate = <TEGRA_PIN_DISABLE>;
			nvidia,enable-input = <TEGRA_PIN_DISABLE>;
		};

		spi1_miso_pc1 {
			nvidia,pins = "spi1_miso_pc1";
			nvidia,function = "spi1";
			nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
			nvidia,tristate = <TEGRA_PIN_DISABLE>;
			nvidia,enable-input = <TEGRA_PIN_ENABLE>;
		};

		spi1_sck_pc2 {
			nvidia,pins = "spi1_sck_pc2";
			nvidia,function = "spi1";
			nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
			nvidia,tristate = <TEGRA_PIN_DISABLE>;
			nvidia,enable-input = <TEGRA_PIN_DISABLE>;
		};

		spi1_cs0_pc3 {
			nvidia,pins = "spi1_cs0_pc3";
			nvidia,function = "spi1";
			nvidia,pull = <TEGRA_PIN_PULL_UP>;
			nvidia,tristate = <TEGRA_PIN_DISABLE>;
			nvidia,enable-input = <TEGRA_PIN_DISABLE>;
		}; 

	};
};

And also with GPIO I want to drive some pins on boot but I do not want the pins being hogged by the linux gpio Sysfs. The below allows me to drive the pins but it does actually hog the pin preventing some user side stuff from being able to export the pin.

gpio: gpio@6000d000 {
	mreset_gpio {
		gpio-hog;
		gpios = <TEGRA_GPIO(S, 5) 0>;
		output-high;
		label = "microcontroller-reset";
		status = "okay";
	};
    };

So I guess my real problem / question is how and where exactly set the pinux, and the Gpio so that the registers are configured on boot.

Thanks again.

6
  1. I just checked and notice the overlays may also work. Have you tried it before?

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fhw_setup_jetson_io.html

  1. For your second issue, I am not very sure about it. You don’t want hog the pin through gpio sysfs nor hogged by dtb. Then what is your expectation?

If you want it to change freely after boot up, then you need to use the gpio sysfs.

7

Thanks Wayne and sorry but I got caught up in the bush fires here in Oz.

For the GPIO stuff I am ok with for now. It happened to be a bad script that was not unexporting the GPIO when an error occurred.

So back to the PinMux. It seems that whatever I do, the pinmux registers are not written to. The GPIO_CNF registers for port c still have values for Gpio and not sfio as per my debug output below.

Below are my DTS entries. I am thinking that since R32.3.1 that maybe the pinmux registers are not set by the DTB file when the module boots. Maybe we are being forced to do it via an overlay DTBO file in the /boot directory. I guess that is the real question here, can we set custom pinmux values the main DTB file, or do we need to do it in the overlay???

I have not tried the Jetson-io tool because I am not using devkit but my own custom carrier board and so the jetson-io tool has all sorts of drama because of naming etc. I do not want to use the jetson-io tool. I want this done on the host side and not the target.

pinmux@700008d4 {
			spi1_mosi_pc0 {
				nvidia,pins = "spi1_mosi_pc0";
				nvidia,function = "spi1";
				nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			};

			spi1_miso_pc1 {
				nvidia,pins = "spi1_miso_pc1";
				nvidia,function = "spi1";
				nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			};

			spi1_sck_pc2 {
				nvidia,pins = "spi1_sck_pc2";
				nvidia,function = "spi1";
				nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			};

			spi1_cs0_pc3 {
				nvidia,pins = "spi1_cs0_pc3";
				nvidia,function = "spi1";
				nvidia,pull = <TEGRA_PIN_PULL_UP>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			}; 
       };

Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
A: 0:0 64 40 40 24 00 00 000000
B: 0:1 f0 50 00 20 00 00 000000
C: 0:2 1f 00 00 18 00 00 000000
D: 0:3 00 00 00 00 00 00 000000
E: 1:0 40 40 00 00 00 00 000000
F: 1:1 00 00 00 00 00 00 000000
G: 1:2 0c 04 04 04 00 00 000000
H: 1:3 fd 99 00 60 00 00 000000
I: 2:0 07 07 03 00 00 00 000000
J: 2:1 f0 00 00 00 00 00 000000
K: 2:2 00 00 00 00 00 00 000000
L: 2:3 00 00 00 00 00 00 000000
M: 3:0 00 00 00 00 00 00 000000
N: 3:1 00 00 00 00 00 00 000000
O: 3:2 00 00 00 00 00 00 000000
P: 3:3 00 00 00 00 00 00 000000
Q: 4:0 00 00 00 00 00 00 000000
R: 4:1 00 00 00 00 00 00 000000
S: 4:2 a0 a0 00 00 00 00 000000
T: 4:3 01 01 01 00 00 00 000000
U: 5:0 00 00 00 00 00 00 000000
V: 5:1 03 01 01 03 00 00 000000
W: 5:2 00 00 00 00 00 00 000000
X: 5:3 78 08 08 30 00 60 606000
Y: 6:0 06 00 00 06 00 00 000000
Z: 6:1 0f 09 00 00 00 04 000400
AA: 6:2 00 00 00 00 00 00 000000
BB: 6:3 01 00 00 01 00 00 000000
CC: 7:0 92 80 80 10 00 12 121200
DD: 7:1 01 00 00 00 00 00 000000
EE: 7:2 00 00 00 00 00 00 000000
FF: 7:3 00 00 00 00 00 00 000000

Thanks.

8

Hi Peter,

I just checked with my nano and enabled it in the main dtb instead of the overlay. The spi is now enabled as sfio.

9

That’s good news Wayne. It’s good to know that it should work so I must have other problems. It seems like the DT has been changed but just not the registers. I must be doing something really stupid somewhere and will have to eat my hat. Maybe there is something relationship between this problem I am having and the sdmmc CD problem in a different post. I just have to find the magic switch.

It still does not work for me. Below is what I see from debugfs.

$ sudo cat /sys/kernel/debug/pinctrl/pinctrl-handles | grep spi1
    type: MUX_GROUP controller 700008d4.pinmux group: spi1_mosi_pc0 (32) function: spi1 (54)
    type: CONFIGS_GROUP controller 700008d4.pinmux group spi1_mosi_pc0 (32)config pull=0
    type: MUX_GROUP controller 700008d4.pinmux group: spi1_miso_pc1 (33) function: spi1 (54)
    type: CONFIGS_GROUP controller 700008d4.pinmux group spi1_miso_pc1 (33)config pull=0
    type: MUX_GROUP controller 700008d4.pinmux group: spi1_sck_pc2 (34) function: spi1 (54)
    type: CONFIGS_GROUP controller 700008d4.pinmux group spi1_sck_pc2 (34)config pull=0
    type: MUX_GROUP controller 700008d4.pinmux group: spi1_cs0_pc3 (35) function: spi1 (54)
    type: CONFIGS_GROUP controller 700008d4.pinmux group spi1_cs0_pc3 (35)config pull=0
    type: MUX_GROUP controller 700008d4.pinmux group: spi1_cs1_pc4 (36) function: rsvd1 (42)
    type: CONFIGS_GROUP controller 700008d4.pinmux group spi1_cs1_pc4 (36)config pull=2

sudo cat /sys/kernel/debug/tegra_gpio
Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 A: 0:0 64 40 40 24 00 00 000000
 B: 0:1 f0 50 00 20 00 00 000000
 C: 0:2 1f 00 00 18 00 00 000000

sudo cat /sys/kernel/debug/pinctrl/700008d4.pinmux/pinmux-pins 
pin 16 (SPI1_MOSI PC0): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_mosi_pc0
pin 17 (SPI1_MISO PC1): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_miso_pc1
pin 18 (SPI1_SCK PC2): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_sck_pc2
pin 19 (SPI1_CS0 PC3): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_cs0_pc3
pin 20 (SPI1_CS1 PC4): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function rsvd1 group spi1_cs1_pc4


But clearly my PINMUX registers do not reflect what is in the DT.

sudo busybox devmem 0x70003050 32
0x0000E040
sudo busybox devmem 0x70003054 32
0x0000E040
10

I think we could check the basic here.

Could you share the runtime device tree in /proc/device-tree/pinmux@700008d4 ?

11

Sure. Here it is but now I am going nuts and made it worse.

I no longer have:
pin 16 (SPI1_MOSI PC0): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_mosi_pc0
pin 17 (SPI1_MISO PC1): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_miso_pc1
pin 18 (SPI1_SCK PC2): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_sck_pc2
pin 19 (SPI1_CS0 PC3): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_cs0_pc3
pin 20 (SPI1_CS1 PC4): 700008d4.pinmux (GPIO UNCLAIMED) (HOG) function rsvd1 group spi1_cs1_pc4

I now have:
pin 16 (SPI1_MOSI PC0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 17 (SPI1_MISO PC1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 18 (SPI1_SCK PC2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 19 (SPI1_CS0 PC3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 20 (SPI1_CS1 PC4): (MUX UNCLAIMED) (GPIO UNCLAIMED)

Thanks.
pinmuxdts.txt (36.4 KB)

12

Hi peterxr95h,

That is not what I meant. Please just check the status under /proc/device-tree/pinmux@700008d4/.
Locate the spi pin you need to look into and see if the “nvidia,function” is what you need.

13

btw, if it is getting worse, you could also try this thread.

https://devtalk.nvidia.com/default/topic/1069112/jetson-nano/jetson-nano-developer-kit-spi-hell/1

Though it is actually using the jetson-io tools as previous suggestion.

14

Ahh sorry, try again…

/proc/device-tree/pinmux@700008d4/header-40pin-pinmux/spi1_mosi/
name: spi1_mosi_pc0
nvidia,function: spi1
nvidia,pull: [0x0000 0x0100]
nvidia,enable-input: [0x0000 0x0100]
nvidia,pins: spi1_mosi_pc0
nvidia,tristate: [0x0000 0x0000]

15

Thanks Wayne. I have been monitoring that post. I just want some confidence on a host build environment for the pinmux settings.

Is it possible you can share with me your DTS file you mentioned in post #8 ?

Thanks.

16

Hi peterxr95h,

Please reference attached DTS files.
Nano-dtsi.tar (50 KB)

17

I am wondering if this “header-40pin-pinmux” makes your case worse… there is not such label in default pinmux setting. All the configuration is under “common”.

You could also directly use the pinmux spreadsheet to generate the dtsi files. I also use that spreadsheet too.

18

Yes I have questioned that one multiple times and I started with common. I have gone back to common. I only went with the header-40pin-pinmux as that is what I see in the jetson-io overlay.

Thank you for your dts files. I have tried with the same results, not working for me. Just for clarification, I am using production module and not devkit. I am assuming you tried with the devkit?

Maybe I should go back to devkit and try.

Thanks for persisting with me.

19

Yes, I tried it on devkit :-)

20

Yes documentation is wrong.

Thank you.