Getting spidev working immediately after flash

Autonomous Machines Jetson & Embedded Systems Jetson Nano
, ,
1

Hi,

I’m using a production module on my own custom carrier board.
I want to the have my flashing procedure setup such that spidev works ‘out of box’ after a fresh flash to the module.
By this I mean not having to run
sudo modprobe spidev
after boot and already having permissions to the gpio group so that I can for example immediately succeed in running spidev_test without sudo.

Following the documentation to compile the device tree I see that the compatible property for the spi nodes is
compatible = "tegra-spidev";
which as a result means I have to run modprobe to install spidev, whereas if I change it to
compatible = "spidev";
like it is on the devkits, the spidev module is already loaded on boot.

Is it safe to make this change? Will there any negative consequences to doing so and why is it different between the devkit device trees and the one that gets compiled from source?

As for permissions, my carrier board doesn’t have display so I’m using the l4t_create_default_user.sh provided on these forums to create my user in advance as I’m obviously in a headless setup.
Is this still the recommended way to create a user for a headless setup?
How can I have the default user already have gpio and i2c group permissions upon flash so that I can use spidev and i2c in userspace without sudo like on the devkits? (after the devkit header pinmux is configured)

3

Have reference to below to try.

https://www.cyberciti.biz/faq/how-can-i-log-in-as-root/

4

Hi Shane,

I know how to log in as root, that doesn’t answer any of my questions though haha.

To be more explicit, if you understand my post, can you please answer each sentence that ends in a question mark.

Thank you :)

5
  1. Suppose yes
  2. Don’t have idea maybe try if any command able change to property like chmod
6

Thank you.

That’s good to know and I’ll try editing the l4t_create_default_user.sh script to add those groups by default if no better method for creating a default user in a headless environment exists.

So why is it that the devkits’ device trees use compatible = "tegra-spidev";, while compiling from source gives compatible = "spidev";?
Why have the two different versions?
It’s convenient without the tegra- as it then does not require running modprobe spidev each boot (even though that can be automated).

7

Suppose the …/kernel/kernel-4.9/drivers/spi/spidev.c also modify to tegra-spidev

static const struct of_device_id spidev_dt_ids[] = {
        { .compatible = "rohm,dh2228fv" },
        { .compatible = "lineartechnology,ltc2488" },
        { .compatible = "tegra-spidev" },
        {},
};
8

It already is exactly that when downloaded with source_sync.sh which is what I compiled and am using for the kernel, but I still have to run modprobe spidev where as I don’t if I only change the device tree to spidev

9

Don’t have idea why. However you can add modprobe spidev to /etc/init.d as solution.

10

Thanks, it is a solution I was aware of. I was hoping to understand why this is not needed when compatible = "spidev"; in the device tree so I could patch it at the root cause in the kernel/device tree source, so I might investigate further.

11

Suppose it’s harmless for modify it back to spidev.

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.