I have enable SC16IS7XX driver using make menuconfig and get error after build kernel.
I am using below steps.
JETSON_NANO_KERNEL_SOURCE=$(pwd)
TEGRA_KERNEL_OUT=$JETSON_NANO_KERNEL_SOURCE/build
KERNEL_MODULES_OUT=$JETSON_NANO_KERNEL_SOURCE/modules
TOOLCHAIN_PREFIX=/home/cimcon/2-Nano-jetson/Jetson-tool-chain/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
make menuconfig
make -C . ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra CROSS_COMPILE=${TOOLCHAIN_PREFIX} -j8 --output-sync=target zImage
How did you configure prior to the menuconfig? If this did not start with a known working configuration, then I’d expect a lot of errors even if you configured some subset of the kernel.
Also, is this cross compile or native compile? Sounds like native, which is easiest, but want to make sure. More important though is whether or not you are using the compile “O=/some/where” to put temporary output somewhere other than the kernel source tree.
The compile steps look valid to me. When you run the “make menuconfig” is your output location guaranteed to have first been cleared (e.g., “make mrproper”) and then basic setup via “make tegra_defconfig”? I’m wondering if old code is conflicting. In theory, if using menuconfig, then any previous config which was valid would also be valid after setting an item. The part which is confusing is that it cannot find “.config” even though you have set “O=...”. It looks like every build and configure step used the “O=...” argument, and so this should not be an issue. Would you double check to see if every build and configure step used the same “O=...” option?
Q1) I have build SC16IS7XX device using bellow link and install in our PC (Linux_for_Tegra/source/public/kernel/kernel-4.9/modules)modules dir. Please let me know how can integrate it on running jetson nano commands?
Q2) Can i connect other I2c Ic in CAM_I2C_SDA/CAM_I2C_SCL I2C. if yes then what will be i2c bus no ? and how will disable camera driver which is connected on CAM_I2C??
Within the kernel source there will be some subdirectory where the module shows up. Just as a contrived example, first cd to the modules themselves on the running system: cd /lib/modules/$(uname -r)/kernel
Notice that each subdirectory here mirrors where a driver would be found after compile in kernel source. So if you built the serial UART driver ftdi_sio.ko, then it would be in this subdirectory of both kernel source and install location under “/lib/modules/$(uname -r)/kernel”: drivers/usb/serial/ftdi_sio.ko
If you’ve built modules and then installed them to some temporary location by a command such as this (you’d have had to have set environment variables TEGRA_KERNEL_OUT and TEGRA_MODULES_OUT to some empty directory): make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
…then this would mirror the the full install path.
Wherever that install path is would be where you’d copy the kernel module. You could then reboot or run “sudo depmod -a”. After this, if the module works, it should be available. You could manually run “sudo insmod ...” to insert the module file if you were at the file’s location, but this wouldn’t normally be needed after the above.
I don’t know about what is enabled in i2c, someone else will need to answer that. Devices on i2c do not normally have the ability to self-report unless they are using USB or PCI slots. If you happen to have i2c devices on an active i2c bus, then they might “just work” if you know the address to use. Mostly I think someone will need to provide details of adding a camera to the device tree, but it is something I can’t answer.
I couldn’t tell you which device tree to use. You might want to give an example use-case of what it is you want to accomplish, e.g., if you are asking how to install a device tree, versus if you are asking how to modify the device tree.
Assuming you have device tree content targeting the SC16IS7XX I2C IC, then yes, this would be the tree you would modify on the host PC so that flash would propagate this during every flash. However, you could also edit (via reverse compile, edit, recompile) directly the same device tree file directly on the Jetson in the “/boot” (or subdirectory of) directory if the extlinux.conf file has an FDT key/value pair pointed at that device tree.
Incidentally, that file name ending with name suffix “.dts” is the source version, and this always gets converted to the binary “.dtb” version for actual use in boot. The dtc command can convert back and forth between the two forms. When you build the binary in the kernel the kernel source happens to have a copy of dtc, but you can also install the dtc command directly on a Jetson or host PC if it is missing. You’d install via “sudo apt-get install device-tree-compiler”.
An example of decompiling a binary so you can edit (pretend the file name is “example_file.something”, and that “something” is either “.dtb” or “.dts” depending on whether it is source or binary): dtc -I dtb -O dts -o example_file.dts example_file.dtb
An example of converting source back to binary: dtc -I dts -O dtb -o example_file.dtb example_file.dts
Note that source (“.dts”) files can be edited with an ordinary text editor.