Trying to get SPI2 working on Jetson NANO Production Module

You may need to refer the following instruction to download the source and build the kernel image.
NVIDIA Jetson Linux Developer Guide : Kernel Customization | NVIDIA Docs

Could you update to JP4.6.4(R32.7.4) in your case?

Hey,
1.) I know how to edit, compile and flash device tree’s. My question was more about what changes on original device tree source have to be executed to get the resulting device tree.
I can decompile the device tree, but this gives me a lot of differences. It would be easier to know what was the base (the Jetpack version) of the working device tree and what were the exact changes on the source.

2.) I am stuck with jetpack 4.5. But I think If you show me the necessary changes of 1) I can replicate it for jetpack 4.5 I think!

No matter 4.6.4 or 4.5 you use, the steps should be similar as Jetson Nano SPI Bus Not Working - #10 by KevinFFF I shared before.

It seems you’ve verified with JP4.6.4 on the devkit so that you should know the exact modifications and steps.
For eMMC module, it would be different from the pinmux configuration. Its pinmux for SPI could not be configured through the Jetson-IO.

You should use pinmux spreadsheet to configure the pins for SPI usage.
Please refer to the following instruction to use pinmux spreadsheet.
NVIDIA Jetson Linux Developer Guide : Jetson Module Adaptation and Bring-Up - Pinmux Changes

I tried it, cannot get it to work. Something must be different in the compiled device tree from the described steps…

changes_made_to_enable_spi1_and_spi2_on_jetson_nano_production_module.txt (4.4 KB)

I have uploaded my changes as a patch.

You could check if you see me doing anything wrong. But it’s basically change spi functionality in pinmux and remove gpios, isn’t it?

Do you modify the same lines for JP4.6.4 and it could work?

May I know why you could not use the latest JP4.6.4 for you case? (It seems worked and also been verified from you.)

Do you modify the same lines for JP4.6.4 and it could work?

As I wrote above:

EMMC 4.6.4 using jetson-io
→ jetson-io not working. Manually applying device tree changes did not have effect on spi register, so did not work. (I did not find out, why) BUT using compiled dtb from this thread About using spi on Jetson NANO - #69 by ShaneCCC
did work. I could not figure out what was different to mine, but there are many “diffs” but around spi it seems very similar.

May I know why you could not use the latest JP4.6.4 for you case? (It seems worked and also been verified from you.)

We have many projects and all of them are based on Jetpack 4.5. It would not be a good choice to switch one project to 4.6.

We will update all projects to Orin Generation and Jetpack 6, when available.

Could you share result of the following command on your board with JP4.5?

$ sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -i spi
$ sudo cat /sys/kernel/debug/tegra_gpio

From above in the thread:

Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 A: 0:0 64 40 40 04 00 00 000000
 B: 0:1 f0 00 00 00 00 00 000000
 C: 0:2 1f 00 00 00 00 00 000000
 D: 0:3 00 00 00 00 00 00 000000
 E: 1:0 40 00 00 00 00 00 000000
 F: 1:1 00 00 00 00 00 00 000000
 G: 1:2 0c 00 00 00 00 00 000000
 H: 1:3 fd 99 00 60 00 00 000000
 I: 2:0 07 07 02 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 80 80 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 00 02 00 00 000000
 W: 5:2 00 00 00 00 00 00 000000
 X: 5:3 78 08 08 70 00 60 606000
 Y: 6:0 06 04 00 02 00 00 000000
 Z: 6:1 0f 08 00 04 00 00 000000
AA: 6:2 00 00 00 00 00 00 000000
BB: 6:3 01 00 00 00 00 00 000000
CC: 7:0 92 80 80 12 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
Bank: 1 Reg: 0x70003050 Val: 0x0000e044 -> spi1_mosi_pc0
Bank: 1 Reg: 0x70003054 Val: 0x0000e044 -> spi1_miso_pc1
Bank: 1 Reg: 0x70003058 Val: 0x0000e044 -> spi1_sck_pc2
Bank: 1 Reg: 0x7000305c Val: 0x0000e048 -> spi1_cs0_pc3
Bank: 1 Reg: 0x70003060 Val: 0x0000e048 -> spi1_cs1_pc4
Bank: 1 Reg: 0x70003064 Val: 0x00006044 -> spi2_mosi_pb4
Bank: 1 Reg: 0x70003068 Val: 0x00006044 -> spi2_miso_pb5
Bank: 1 Reg: 0x7000306c Val: 0x00006044 -> spi2_sck_pb6
Bank: 1 Reg: 0x70003070 Val: 0x00006048 -> spi2_cs0_pb7
Bank: 1 Reg: 0x70003074 Val: 0x00006048 -> spi2_cs1_pdd0

It seems reporting the wrong value. Those pins are still used as GPIO.

Could you decompile the <Linux_for_Tegra>/kernel/boot/kernel_XXX.dtb and check the nvidia,function for SPI pins?

I found this thread and the corresponding patch. I think this might be the reason why the gpios are not changing.

Gonna report as soon as I tested.

It is working now.
I had to apply the patch from above, then the gpio pins were configured correctly and spi loopback test is working.

Best regards,
Johannes

Maybe can you tell me how to update the changes of gpio-tegra.c ? Is it compiled into kernel image? Updating kernel image does not seem to change it.

Complete reflash did change it.

obj-$(CONFIG_GPIO_TEGRA)	+= gpio-tegra.o

It is a driver if it would be built in kernel image determined by CONFIG_GPIO_TEGRA.
You should flash the whole board to apply it.

Sorry, I do not get it.
So is it a driver or not?

I thought it is either compiled into kernel image which can be replaced by /boot/Image or it is a kernel module which can be replaced alone as .ko file.

What or where can it also be that is has to be reflashed?

It is not in the rootfs? Does that mean I could reflash with my cloned system.img from another jetson and it would apply?

Yes.

Currently, CONFIG_GPIO_TEGRA is configured as “y” and it will be built in to kernel and loaded automatically.

If you don’t want to load it during boot, you could configure it as “m” and it will be built as a loadable module and you could load it manually after boot.

So I could just replace the Image file /boot/Image and I do not need to reflash completly. Is that correct?

For some reason, this does not work in my case.

Do you want to load it automatically during boot up?

Could you clarify that what’s your use case?

Yes. It should load up automatically.

I have a jetson system on which I changed a lot in the rootfs. That is why I only clone new jetsons with the image from the jetson. Now I had apply the kernel patch.

Normally I would apply the patch, compile it and then just replace the /boot/Image file in my rootfs.

But this time, it seems to not be working, since the GPIO configuration is still wrong.

I would like to not reflash because then I have to do the changes on rootfs again. That is why I would like to only update file(s) in the rootfs to apply the changes regarding the GPIO kernel patch.

To enable SPI2, you don’t need to re-flash the board.
You could just enable it through modifying the device tree.

Could you provide the current /boot/dtb/kernel_XXX.dtb from your board for further check?