r32.3 UBoot PinMux settings. Is documentation wrong?

peterxr95h · January 8, 2020, 12:24am

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.

WayneWWW · January 8, 2020, 2:43am

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.

peterxr95h · January 8, 2020, 5:13am

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.

WayneWWW · January 8, 2020, 5:58am

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

peterxr95h · January 8, 2020, 7:39am

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.

WayneWWW · January 8, 2020, 8:03am

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

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.

peterxr95h · January 10, 2020, 7:44am

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.

WayneWWW · January 13, 2020, 6:28am

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.

peterxr95h · January 13, 2020, 6:41am

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

WayneWWW · January 13, 2020, 6:59am

I think we could check the basic here.

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

peterxr95h · January 13, 2020, 8:15am

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)

WayneWWW · January 13, 2020, 8:35am

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.

WayneWWW · January 13, 2020, 8:47am

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.

peterxr95h · January 13, 2020, 9:05am

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]

peterxr95h · January 13, 2020, 9:24am

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.

carolyuu · January 13, 2020, 9:33am

Hi peterxr95h,

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

WayneWWW · January 13, 2020, 9:37am

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.

peterxr95h · January 13, 2020, 10:24am

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.

WayneWWW · January 14, 2020, 7:39am

Yes, I tried it on devkit :-)

peterxr95h · January 15, 2020, 11:56am

Yes documentation is wrong.

Thank you.

Topic		Replies	Views
Check pinmux on spi0&1 on jetson-nano Developer Tools spi	22	3248	October 12, 2021
SPI setup issues with Jetson Nano B01 DevKit Jetson Nano spi	128	2978	October 27, 2023
/dev/spi0.0 not work in l4t32.3.1 Jetson Nano	21	3115	October 14, 2021
Did anybody get SPI interface working on TX1? Jetson TX1	37	11997	October 18, 2021
SPI setup on Jetson Nano production SoM (p3448-0002, b01) L4T 32.2.0 Jetson Nano	22	4501	October 18, 2021
For the love of god....make SPI easy to enable!!!! Jetson TX2	7	1489	October 18, 2021
The Document Pinmux error. Jetson TX2	16	1605	October 18, 2021
Jetson Nano + L4T R32.3.1: SPI not working even after enabling via jetson-io.py Jetson Nano	10	2151	October 14, 2021
Jetson xavier NX SPI2 pinmux issue Jetson Xavier NX spi , pinmux	18	2033	October 18, 2021
TX2 J21 config pinmux as gpio in jetpack4.2 Jetson TX2 gpio , pinmux	24	2705	October 18, 2021

r32.3 UBoot PinMux settings. Is documentation wrong?

Related topics