CLOSED. MPU9255 on spi0

Hi,

I have my carrier board with installed mpu9255:

So it is connected on:
SPI0_MOSI F4
SPI0_MISO E4
SPI0_CLK E3
SPI0_CS0# F3

My kernel tegra21_defconfig has:
config_spi=y
config_spi_tegra114=y
config_spi_master=y
config_spi_spidev=y

But i can’t see spi device /dev/spidev3.0

Dmesg says:
spi-tegra114 7000d400.spi: Static pin conf used
spi-tegra114 7000da00.spi: Static pin conf used

Also spidev.ko not found. It was built in kernel, am i right?
grep spi modules.builtin says:
drivers/spi/spi-tegra114.ko

And i found spi.o, spidev.o and spi-tegra114.o in drivers/spi build dir.

Should i fix dts?

Best regards, Viktor.

lsmod only shows what modules are present. This will give you the exact configuration which was compiled, and then grep for your module:

zcat /proc/config.gz | grep -i spidev

Looks like this is neither built in nor a module. If you start with the existing config.gz you could build CONFIG_SPI_SPIDEV as a module and put it in the right directory (under “/lib/modules/$(uname -r)/”).

Thanks. Will try build as module.

Hi,

I have rebuilt kernel with CONFIG_SPI_SPIDEV = m:

sudo make -j4 O=$TEGRA_KERNEL_OUT tegra21_defconfig &&
sudo make -j4 O=$TEGRA_KERNEL_OUT zImage &&
sudo make -j4 O=$TEGRA_KERNEL_OUT dtbs &&
sudo make -j4 O=$TEGRA_KERNEL_OUT modules &&
sudo make -j4 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH_=$TEGRA_KERNEL_OUT/modules

Append to /etc/modules !!!<- not needed
spidev

Now the spidev is loaded as module and lsmod shows it.

But i think it is the same as built-in spidev in my case.
mpu9255 still does not present in /dev

Should i also use CONFIG_SPI_MASTER?

I think that i should edit dts.

First i decompile dtb in /boot

// tdb to dts
sudo dtc -I dtb -O dts -o tegra210-jetson-tx1-p2597-2180-a01-devkit.dts ./tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb

Then i added spi3_0 rule to spi@7000da00 section:

spi3_0 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = “linux,spidev”, “spidev”;
reg = <0x0>;
spi-max-frequency = <0x17d7840>;
nvidia,enable-hw-based-cs;
nvidia,cs-setup-clk-count = <0x1e>;
nvidia,cs-hold-clk-count = <0x1e>;
nvidia,rx-clk-tap-delay = <0x1f>;
nvidia,tx-clk-tap-delay = <0x0>;
};

And then i compile dtb:

// dts to dtb
sudo dtc -I dts -O dtb -o tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb ./tegra210-jetson-tx1-p2597-2180-a01-devkit.dts

What else i shoud fix?

Best regards, Viktor.

Should update dtb with dd:
sudo dd if=tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb of=/dev/mmcblk0p13

Copying to /boot disabled in jetpack 3.1

Now /dev/spidev3.0 is present

But i cant find imu with RTIMULib.

Dts default params for spi@7000da00 are correct?

[UPDATED]
I made test with https://github.com/Nick-Currawong/RTIMULib2
And with setting mpu9255 chipselect 0 in RTIMULib2.ini i receiving data only one time.

After that tegra reboot.

[UPDATED]

After disabling pressure sensor and setting kalman filter in settings ini then mpu9255 works now.

Solved.
Thanks to all.

I don’t know enough to help with SPI config once the driver is in place. All I can do is offer some notes. Device tree is high on the list of what might need to change for the SPI detect, but someone else will need to comment on what to check on finding the imu. We need to know the version of L4T being used before it is possible to know what must be done for a device tree update…this has been a moving target for the last few releases. See:

head -n 1 /etc/nv_tegra_release

Random notes:

  • How to update a device tree depends on L4T release. R28.1 allowed dd into the correct partition if the partition was large enough. R28.2 and up sign the device tree, so you can't dd this.
  • You don't need to build zImage, you can just build Image (it'll be faster and consume less disk space).
  • After a "make dtbs" target you should find the dtb, you don't need to separately run dtc.
  • You probably won't want to start with the device tree produced in a "make tegra21_defconfig". When you have a running system you usually want to start with "/proc/config.gz" (new Jetson owner hint: Save an archive copy of this file and the output of "uname -r" when you get a new Jetson, and again after each successful flash or replacement of the kernel). In earlier L4T releases the default target and shipped Jetson would have been the same tree, but there seem to be differences since a few releases back.
    • If you start with "/proc/config.gz", then the CONFIG_LOCALVERSION is the only part of the device tree which is not an exact match to the running system. You can add this in with an editor.
    • Modules are found in "/lib/modules/$(uname -r)/". "uname -r" is from the base kernel version plus the CONFIG_LOCALVERSION. If your running system is "4.4.38-tegra", then CONFIG_LOCALVERSION was "-tegra" when that kernel was compiled. Had you replaced your kernel itself without setting this it would have been looking for modules in the wrong place.
    • You don't need to build the kernel itself for your purposes. You can instead start with "make modules_prepare". On the other hand, it should be considered a sanity check to compile the full kernel at least once, so I would have advised doing so anyway (at least for the first compile of that source with that config).

Good advices. Thanks. Will use it.

Tell me please, if i will update to 28.2 then copy DTB to /boot will disabled, dd will disabled, but how i will update DTB? Only via host with flash?

Correct. The flash.sh script is the only way to update the dtb in R28.2. I know there have been inquiries regarding how to do the signing with open source tools (and thus a way to go back to using dd), but so far that doesn’t exist. Use R28.2.1 if you do…R28.2 is deprecated now.

Example with flash.sh:

sudo ./flash.sh -r -k DTB -d <path/to/device tree> mmcblk0p1 jetson-tx1

Thanks.