First, files in “
/dev” are “device special files” (mostly). Otherwise known as “pseudo” files. They don’t exist on the filesystem, and are really drivers pretending to be files in order to communicate with the world outside of the kernel. It is possible to create such a file manually, but the saying is that “the lights are on, but nobody is home”. Such files do nothing because the driver is not running.
Of the files that are there, it is generally the driver or the
udev system which controls their naming and permissions. Using
chmod on them might work, but is generally frowned upon even if it does work. The system set them up that way for a reason. Changing a name or permission is normally done by editing a
udev rule. Adding them is normally be making sure the driver is running.
When logged in to the Jetson (or to any Linux PC), if you run the command “
df -H -T” it will show all mounted filesystems and their types, along with usage information. For you, I suggest running this command to illustrate:
df -H -T / /dev
The above shows both the root of the whole filesystem, which should be type
ext4, and “
/dev”, which is type “
udev”. These are different disks, whereby
/dev is virtual. To learn about
udev you might look at this tutorial:
Note that in “
/etc/udev” that some of the rules there are actual files, and others are symbolic links into system files somewhere in a lib directory’s
udev subdirectory. To activate something on the regular unmodified
udev setup you would add a symbolic link into the correct “
/etc/udev” subdirectory; to modify a rule which already exists, you would instead copy the file to the correct subdirectory of “
/etc/udev”, and then edit that file. You could deactivate that file by removing it from the “
/etc/udev” subdirectory. You would never edit any of the system files under a “
/lib” or “
Thus, you don’t add those files in the rootfs…they do not yet exist and it isn’t the rootfs which contains them. You would do whatever is needed to make sure the driver is present (the possibility of a “
/dev” file existing), and then make whatever arrangement is needed for the driver to see the hardware (which is what triggers actual driver load, and thus the existence of the “
/dev” pseudo file).
If a driver is integrated into the kernel, then there is no need to make sure the driver is available. For that case you’d only need to make sure the kernel knows to load the driver. If the driver is in the form of a module, then you’d simply make sure the driver knows how to find the device it works with.
Some devices are “plug-n-play”. Some buses know how to query devices. USB and PCI are good examples. Even a monitor’s HDMI or DisplayPort cable has that ability. Other devices cannot be queried, and the only way a driver knows to load is if it is manually told where to look, along with other arguments to pass to the driver (e.g., a physical address, perhaps a protocol). This latter is not needed for a plug-n-play device, but for many others (including
i2c), this is the realm of the device tree.
The official docs mention how to work with the device tree (the docs from your L4T release…see “
head -n 1 /etc/nv_tegra_release” to find which L4T you are running; incidentally this is just Ubuntu plus Linux drivers). Then find the docs for that release through this listing of releases:
(incidentally, JetPack/SDK Manager is the installer software, but L4T is what gets installed)
Also, search for “
PINMUX” here at the official downloads URL:
The PINMUX spreadsheet has macros you can enable. Then, if all of the settings are unchanged but for the specific dev kit you have, then this would produce the same device tree. If you then edit a parameter, e.g., something for i2c setup, then you could use the modified device tree. That tree is usually part of the flash process, although there are ways to test it and update without flashing in most cases (a simple file copy plus a minor edit to “
/boot/extlinux/extlinux.conf” to name a new FDT value…which would point to the alternate name instead of the original file name, preferably from an entirely new boot entry to leave the old one as a backup).
As a checklist:
- Is the driver available? There would be a “
CONFIG_...something...” for that item in “
- Is the device “plug-n-play”? If so, no need to worry, but if not, then you need to use the PINMUX spreadsheet macros to install an edited device tree.
- Need permissions changed? Then add your user to the right group, or edit the