SPI setup on Jetson Nano production SoM (p3448-0002, b01) L4T 32.2.0

lucam · August 20, 2019, 8:22pm

Hi all,

I am currently trying to replicate the SPI (aka spi0 tegraX1, spi1 Jetson Nano) device tree configuration done in the Devkit to the production SoM with a custom board.

Following several threads on this forum

and similar

all is working on the DevKit, with a modified tegra210-p3448-0000-p3449-0000-a02 device tree.

Now, with p3448-0002, the selected device tree is the tegra210-p3448-0002-p3449-0000-b00, where the previous patches seem not to work anymore.

The spidev peripheral is correctly detected (as /dev/spidev0.0) yet the /sys/kernel/debug/tegra_gpio still shows the 0x1F value over the GPIOC pins.

Can you support us?

Thank you (again),
Luca

JerryChang · August 21, 2019, 3:21am

hello lucam,

you may also check the pinmux spreadsheet for configure the GPIOs.
suggest you access application note, Jetson Nano Developer Kit 40-Pin Expansion Header Configuration, for the steps to customize.
thanks

lucam · August 21, 2019, 6:45am

Hi JerryChang,

thank you for the hint. Indeed I am using it at the moment, few questions:

the DA_09565-001 document specifies that the generated dtsi files are meant to be used for Cboot pinmuxing. Is this also related to Linux kernel? Later on, in the Cboot section, it is stated "The pinmux settings in device tree files are only applied by CBoot, and not reapplied by the Linux kernel. ". However, in the “Update the CBoot Pinmux” section, the kernel is indeed referenced. I am a little confused…
pin 95, SPI0_CS0 Jetson, SPI1_CS0 BallName, is marked as "Please check with Nvidia before using functions that end with a ‘*’ ". Can you confirm that can be still used as SPI Chip Select?

Thank you,
Luca

EDIT: attached you may find the two dtsi generated by excel spreadsheet.
tegra210-jetson_nano_module-gpio-default.dtsi.txt (2 KB)
tegra210-jetson_nano_module-pinmux.dtsi.txt (38.1 KB)

JerryChang · August 21, 2019, 8:04am

hello lucam,

BTW,
may I know which documentation you mention of DA_09565-001,
thanks

lucam · August 21, 2019, 8:17am

Hi JerryChang,

excuse me, I just picked the document name.

It does refer to the application note “Jetson Nano Developer Kit 40-Pin Expansion Header Configuration” you were referring to in the previous post.

Thank you
Luca

lucam · August 21, 2019, 2:57pm

Hi JerryChang,

I followed the “Update the CBoot Pinmux” section, with the attached xlsm. The generated dtsi files have been moved as required by the documentation. However the pinout muxing is not modified by CBoot, see picture attached.

Luca
[This file was removed because it was flagged as potentially malicious] (499 KB)

JerryChang · August 22, 2019, 2:39am

hello lucam,

To enable SPI, you should modify pinmux settings in U-Boot. please also check similar issue, Topic 1055398 for details.

BTW, you might also check Jetson Nano Boot Flow chapter for the boot flow.
thanks

lucam · August 22, 2019, 7:13am

Hi JerryChang,

thank you. I am following your steps to properly configure the pinmux.

Regarding the “Jetson Nano Boot Flow” and “Jetson Nano Developer Kit 40-Pin Expansion Header Configuration”, I do not understand which is the relation between the generated dtsi for CBoot and the header file to Uboot. If now I get it correctly, the pinmuxing is ONLY configured by uboot and not CBoot, correct?
Exporting the CSV text from the Excel spreadsheet is not working for Excel 2010 version, since UTF-8 encoding is not available and the csv-to-board.py is not accepting it.

Thank you,
Luca

Tib1f · August 22, 2019, 7:27pm

@lucam

I could not export in UTF-8 in excel either.
The workaround I found on the web is to open the *.csv file with Notepad and do “Save As” selecting the UTF-8 option.

If you do succeed with the given procedure, thank you to let me know. Maybe I will find what I am doing wrong.

@JerryChang

I don’t know if you have read the topic you are refering to (1055398) up to the end. But if you do, you’ll see that I have stop trying to use SPI. For now, I have wasted way too much time trying to make it work, just trying to follow the instruction given by Nvidia.
I would prefer to have to focus primarily on my application, and not on Uboot, Cboot, DT or whatever else is needed to make SPI work. I think setting up SPI should not take more than a few hours (not to say minutes).
I hope Nvidia will publish a complete document that works soon, or that I manage to find what I did wrong when I try again.

lucam · August 22, 2019, 9:00pm

@lucam

I could not export in UTF-8 in excel either.
The workaround I found on the web is to open the *.csv file with Notepad and do “Save As” selecting the UTF-8 option.

If you do succeed with the given procedure, thank you to let me know. Maybe I will find what I am doing wrong.

@JerryChang

I don’t know if you have read the topic you are refering to (1055398) up to the end. But if you do, you’ll see that I have stop trying to use SPI. For now, I have wasted way too much time trying to make it work, just trying to follow the instruction given by Nvidia.
I would prefer to have to focus primarily on my application, and not on Uboot, Cboot, DT or whatever else is needed to make SPI work. I think setting up SPI should not take more than a few hours (not to say minutes).
I hope Nvidia will publish a complete document that works soon, or that I manage to find what I did wrong when I try again.

Hi @Tib1f,
thank you for your reply. I will try to open it again with a notepad. The only workaround I found is to directly modify the configs/p3450-porg.board file in the tegra-pinmux-scripts utility. And the board-to-uboot script does the rest. Not sure about the right configuration for SPI, because it shows other pin differences.

@JerryChang

Indeed I tried the method, yet the system become unstable (nvgpu kernel panic, see attachment) without successfully login into Linux. I stress that it was correctly working with 32.1 and a00 module revision, with the development kit. Now having the production SoM with custom board, it is very frustrating to spend so much time in debugging Nvidia tools, as also Tib1f has pointed out.

Hope you might help us getting Jetson Nano production SoM (p3448-0002, b01) fully operational with DT interfaces.

Thank you
Luca
log_boot.txt (7.21 KB)

_KmL · August 22, 2019, 9:19pm

Hi all,

I’m having similar issues with SPI on the Jetson Nano dev board after the 32.2 L4T update.
The method detailed in this thread [url]https://devtalk.nvidia.com/default/topic/1050427/jetson-nano/enabling-spidev-on-the-jetson-nano-is-hanging-when-flashing/1[/url]doesn’t seem to work anymore since it no longer updates the GPIO Pinmux.

I will try to modify the tegra210-p3448-0000-p3349-000.b00.dts file tomorrow. In fact, this new DTS is being used by the standard .img issued by Nvidia. Keeping you updated…

Thanks,
Kamel

Tib1f · August 23, 2019, 12:10pm

Hello Kamel,

Just a quick summary of my current knowledge and thinking.
There seems to be multiple hardware revision. I asked what are the differences but did not get an answer.

a00 with R32.1 : OK (from lucam)
a01 : no info
a02 with R32.2 : NOK (my experience)
b00 : no info
b01 with R32.2 : NOK? (from lucam)

The curent pinmux spreadsheet does not allow booting on a02. They sent me a file which have differences on non user accessible pins configuration that allow booting. So I think that they have new documents that they did not publish yet.
To make it work, probably the pinmux spreadsheet should have a board selector, to set the correct pins configuration for each board.
But more realisticaly, they will now not support boards prior to b01, the production version.
I am not going for a system that “happens to work”. So I am waiting for a more stable release of all the package (hardware/software), and I’ll switch then.

What is your board version?

Best regards

ShaneCCC · August 26, 2019, 8:23am

@KmL
Could you have much detail information after update to r32.2
And it’s better to have a new thread for the SPI problem.

lucam · August 26, 2019, 8:44am

Hi @shaneCCC, @JerryChang,

Regarding the current thread, it seems to me that all published messages involve the “SPI issue”. As pointed out by @Tib1f, the SPI issue now extends to different SoM revisions, not only to the b00, b01 included in the thread title. @Kamel also pointed out the problem with L4T 32.2…

Hope you might find a solution soon, our development is currently stuck and we are running out of time.

Thank you
Luca

ShaneCCC · August 26, 2019, 9:05am

@lucam
So for your case it’s working for r32.1 but didn’t working for r32.2?
Did you cat /sys/kernel/debug/tegra_gpio to check the pin status?

lucam · August 26, 2019, 9:26am

Hi ShaneCCC,

I have only tested with r32.2, since module revision b00/b01 seems supported only there (as far as I remember, there is no mention of eMMC flashing configuration in the 32.1 release).

The /sys/kernel/debug/tegra_gpio returns 1F over the C pin rows (used by SoM SPI1), even when I have the /dev/spidev0.0 device available.

Thank you,
Luca

ShaneCCC · August 26, 2019, 10:09am

@lucam
Have a reference to below link to set the GPIO to correct status.

Add below to your DT.

default {
	gpio-hog;
	function;
 	gpios = <0x10 0x0 0x11 0x0 0x12 0x0 0x13 00 0x14 0x0>;
};

lucam · August 26, 2019, 10:31am

Hi @ShaneCCC,

I did already included this configuration to the device tree, as already suggested at the beginning of this thread.

However, which DTS should be modified? the one in sources/kernel/kernel4.9? The one in Uboot? Or rather the pinmuxing defined in the CBoot?
If I get it correctly, it is up to the CBoot to properly setup the pinmuxing. Is that correct?

Thank you,
Luca

ShaneCCC · August 26, 2019, 11:11am

The DTS for the kernel should be locate …/sources/hardware/nvidia/platform/t210/

lucam · August 26, 2019, 11:38am

Could you confirm that it is the kernel DTS to be modified and not the uboot pinmuxing header file nor the CBoot config?

From message #3 in this thread:
The Nvidia document DA_09565-001, “Jetson Nano Developer Kit 40-Pin Expansion Header Configuration” specifies that the generated dtsi files are meant to be used for Cboot pinmuxing. Is this also related to Linux kernel? Later on, in the Cboot section, it is stated "The pinmux settings in device tree files are only applied by CBoot, and not reapplied by the Linux kernel. ".

Luca