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?
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.
[This file was removed because it was flagged as potentially malicious] (499 KB)
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.
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.
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.
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.
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.
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.
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?
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. ".