I’m currently porting a (working) application from r32.7.3 to r35.4.1 - with a few changes, because we’re going to require the RT patches to the kernel. I have the kernel rebuilt with RT patches, and it’s running, but I’m having trouble communicating with a SPI device (that works fine under r32.7.3).
Looking at the output of sudo /opt/nvidia/jetson-io/config-by-pin.py, it seems like the SPI pins are not enabled - and this is after using sudo /opt/nvidia/jetson-io/jetson-io.py to enable them in a custom .dtbo file - rebooting doesn’t seem to enable them, and my application can’t talk to the device over SPI (even after modprobe spidev - which creates /dev/spidev0.0).
Questions:
is this due to building a kernel with the RT patches? Should I be changing the pin mapping a different way?
is this some other change between r32.7.3 and r35.4.1? I’m also having trouble with another custom driver, but I suspect it’s the same issue (with the pin mapping not getting set correctly by a custom .dtb)
I just reinstalled everything with the default kernel (under r35.4.1), and sure enough, the .dtb file started working as expected - I can now talk to my device over SPI.
So, I guess my new question is: given that I have to rebuild my kernel with the RT patches, how do I effectively change the pin configurations in the rebuilt kernel? I’m surprised the overlay isn’t working correctly…
The tests I did above were on two different USB disks, both installed with ./tools/kernel_flash/l4t_initrd_flash.sh - one disk with the stock kernel, one with the patch (RT) kernel. The emmc of the xavier NX was untouched between them.
However, the USB disk with the stock kernel read /boot/extlinux/extlinux.conf from /dev/sda1, but the USB disk with the RT-patched kernel always reads /boot/extlinux/extlinux.conf from /dev/mmcblk0p1 ! So, when I put the correct DTB on mmcblk0p1, I can get the SPI device working with the RT-patched kernel.
The only thing I don’t understand is why the USB disk with the RT-patched kernel doesn’t read /boot from sda1 - but I guess I’ll be looking into that.
are you referring to where the system loads the kernel (, and also read /boot/extlinux/extlinux.conf), or what the system mounts as the rootfs?
If you are talking about the former one, then it’s solely decided by UEFI, and should have nothing to do with contents in the storage device; if you are talking about the latter one, are the two USB drive flashed with the same command?
Yeah, after more testing, it appears to be related to one specific USB drive - the rootfs mounts from it just fine, but UEFI does not see it as a bootable drive. I don’t see any error reporting related to it, but the behavior definitely follows one of the drives.