Platform: Jetson Nano
Custom board
Kernel Version: 4.9.253
L4T Version: 32.7.2
JetPack 4.6.3
I’m using the NV_Jetson_Nano_Module_Pinmux_Config_Raven v1.01
I’m trying to enable SPI1 and 2 by using the pinmux spredsheet for the nano, then pasting the files into the respective .dtsi files in the prog-platform folder however, when i decompile the device tree that was loaded onto the nano after flashing, the pinmux portion of SPI still shows “rsdv1” as the “nvidia,function” instead of “spi”, and tristate is enabled.
I overrode the .dtsi files that I believe was being used to alter the pinmux, after saving a backup of them, and used the log generated when compiling the kernel to trace back the dts files used to create the device tree. I feel like I traced them all, but it doesn’t look like any of the dtbo’s are overriding what I’m trying to do. I’m not sure where to start diagnosing the problem.
I’m thinking it’s this one because I didn’t notice any other dtb it was using in the flash log. Although there are many other .dtb and .dtbo’s in the boot folder of the nano, so I’m not sure how they all work together. The one I’ve included above is in the /boot/dtb/ folder, whereas all the other dtbs and dtbos are in /boot/.
I checked the file: tegra210-porg-gpio-p3448-0000-b00.dtsi, and it looks like port b and c that are used for SPI aren’t there. I also checked a few others like tegra210-porg-gpio-p3448-0002-b00.dtsi because there are several of these and ports b and c also weren’t there. There was only one other one that still had ports b and C and I removed those entries, then re-compiled the kernel. Here’s tegra210-porg-gpio-p3448-0000-b00.dtsi:
I have all of these in my prog folder. I made a few copies to keep a backup of the ones I modified.
I’m thinking the tegra210-porg-gpio-p3448-0000-b00.dtsi one is the correct one but in the kernel build log I remember seeing some of those other ones where used, so I modified them all to be the same because I wasn’t 100% if one was overriding another.
This is the config I have. I didn’t need to modify anything. Looks like spi was enabled, possibly because in the .config file I changed “CONFIG_SPI_SPIDEV=y” a while ago.
I haven’t yet no, but I’ll try that today. For spidev0.0 I tried to talk to the FRAM chip we have connected to it and for spidev1.0 I tried observing the outputs of miso mosi sck and cs on an oscilloscope but nothing changes. CS is also always high.
Your pinmux values are still wrong for SPI usage.
You should check if the configuration in pinmux spreadsheet has been applied correctly to your BSP package and flash into your board first.
Do you have Jetson Nano devkit with R32.7.3 to verify?
When I enter the commands in step 6, I noticed in the build log that there’s a warning about SPI.
Warning (reg_format): “reg” property in /fragment@1/overlay/spi@0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for /fragment@1/overlay/spi@0
Warning (avoid_default_addr_size): Relying on default #size-cells value for /fragment@1/overlay/spi@0
One other thing, when I enter the commands in step 6:
$ cd <src_path>/kernel/kernel-4.9/
$ make ARCH=arm64 tegra_defconfig
$ make ARCH=arm64 dtbs
It doesn’t look like it’s actually recompiling the dtb’s even though I see logs it’s doing that, because the boot folder where those things are put stays empty. I usually delete what’s in the boot folder so make sure it’s generating new files as I’m unsure if it would override the existing files. If I recompile the entire kernel then the dtb’s are all rebuilt as usual. Not too sure if those two commands are doing anything.
I have the dev kit, but wasn’t using it. I noted it was a custom board on my initial post. We need the ability to control the device tree.
The JetsonIO interface I aready tried and a photo is already posted on this topic a bit earlier. It shows the spi pins are enabled on the 40 pin header.
Does the warning about spi in the logs above mean anything?
Before I was going to put it into the devkit I decided to try the loop back on our custom board just for fun, and the spidev_test worked perfectly. I can see the clock on our oscilloscope. This was for spidev1.0 which is our spi1 pins on the SoM. Haven’t tried the spi0 with our FRAM chip yet but we’ll get to that next week and open a new topic if we get into issues.
The only thing is that regarding the busybox devmem values you said where wrong previously, they are all still the same and it works anyway. I’m not sure why, but I’m happy it works right now.
I’m not entirely sure what I did to fix it. But I restarted the entire process to do the pinmux in the excel sheet, copied the contents of the .dtsi files in the right files in prog-platforms. I ran make clean, then make mrpropper. I used menuconfig this time instead of editing the .config manually to enable spidev=y. Then recompiled the entire kernel.
I really appreciate your patience, I know this went on for a while.
