add dtbo file to xavier nx kirkstone branch (efi boot)

[intera91]

am working on a xavier nx on our custom board and must load a dtbo file describing the 40 pins header in order to connect to a SPI IIO sensor (icm 20689)

before the efi boot (dunfell) it was about copying the dtbo file to /boot ... that is apparently no longer the case.

Is there a resource somewhere (that I have not been able to find) that would describe how to achieve this ??

so far I have tried unsuccessfully to add the following to local.conf

KERNEL_DEVICETREE_APPLY_OVERLAYS = "tegra194-p3668-all-p3509-0000-hdr40.dtbo"
OVERLAY_DTB_FILE = "tegra194-p3668-all-p3509-0000-hdr40.dtbo"

and the following lines to my machine definition:

OVERLAY_DTB_FILE = "tegra194-p3668-all-p3509-0000-hdr40.dtbo"

none of these result in my /sys/bus ... populating the relevant spi directories with the aforementioned device.

Any help appreciated

Thanks

[madisongh]

Have you already looked at discussions #1223 and #1604, and the wiki page on using overlays? Are you including the necessary driver(s) in your build?

[intera91]

Yes and tried to learn from them. the output of

grep 'spi1' /sys/kernel/debug/pinctrl/2430000.pinmux/pinmux-pins

pin 160 (SPI1_SCK_PZ3): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_sck_pz3
pin 161 (SPI1_MISO_PZ4): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_miso_pz4
pin 162 (SPI1_MOSI_PZ5): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_mosi_pz5
pin 163 (SPI1_CS0_PZ6): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_cs0_pz6
pin 164 (SPI1_CS1_PZ7): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function spi1 group spi1_cs1_pz7

the same command with spi2 returns nothing

but the device icm20689 is still not appearing in /sys/bus/iio/devices where our application is looking for it furthermore

lsmod | grep 6050
inv_mpu6050_spi        16384  0
inv_mpu6050            36864  1 inv_mpu6050_spi

lets me know that the relevant module is loaded.

I have also created a defconfig stub :

CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
CONFIG_IIO_BUFFER_CB=y
CONFIG_IIO_BUFFER_DMA=y
CONFIG_IIO_BUFFER_DMAENGINE=y
CONFIG_IIO_BUFFER_HW_CONSUMER=y
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
CONFIG_IIO_CONFIGFS=y
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
CONFIG_IIO_SW_DEVICE=y
CONFIG_IIO_SW_TRIGGER=y
CONFIG_IIO_TRIGGERED_EVENT=y

CONFIG_INV_MPU6050_IIO=m
CONFIG_INV_MPU6050_SPI=m

CONFIG_IIO_HRTIMER_TRIGGER=y
CONFIG_IIO_INTERRUPT_TRIGGER=y
CONFIG_IIO_TIGHTLOOP_TRIGGER=y
CONFIG_IIO_SYSFS_TRIGGER=y

All of the above and still no /sys/bus/iio/devices/iio:device1 to communicate with

[madisongh]

That looks OK, but it's always hard to tell with overlays. Look under /proc/device-tree on the running device to see if the overlay actually got applied, and then cross-check under /sys/devices/platform to see if that SPI bus is under there and the IMU device shows up on that bus.

[intera91]

Here we can see:

$ pwd
/proc/device-tree/spi@3230000/spi@0
$ cat compatible && echo
invensense,icm20689

so the overlay does apply most apparently

and

$ pwd
/sys/devices/platform
$ ls | grep 323
3230000.spi

however I find no trace of the sensor past that ...

[madisongh]

Anything in the kernel log from the driver about why the probe might have failed? If not, you may have to add some debug logging, or at least inspect the driver source code, to track down why it's not registering the device.

[intera91]

thus far:

$ dmesg | grep inv-mpu
[   10.860765] inv-mpu6000-spi spi2.0: mounting matrix not found: using identity...
[   10.860970] inv-mpu6000-spi spi2.0: Could not find IRQ 0
[   10.861174] inv-mpu6000-spi: probe of spi2.0 failed with error -22

[intera91]

Problem found in line 1462 of inv_mpu_core.c

old version:

desc = irq_get_irq_data(irq);
	if (!desc) {
		dev_err(dev, "Could not find IRQ %d, continuing without IRQ\n", irq);
		use_irq = false;
		// return -EINVAL;
	}

So we could use the sensor without an IRQ which we did as the IRQ pin is NC on the board ...

new version of the kernel driver:

desc = irq_get_irq_data(irq);
if (!desc) {
	dev_err(dev, "Could not find IRQ %d\n", irq);
	return -EINVAL;
}

so that explains ;-)