I have jetson tx1 with 4.4.15-tegra. I am trying to build 4.4.38-tegra because my ttyACM is not getting detected.
I followed jetson tx1 buildkernel tutorial on jetson hacks. There are some make errors while running ./makeKernel.sh because of which Image file is not getting created in /arch/arm64/boot/
Is there any way I can surpass this?
If not, is there any way to make ttyACM version as 4.4.15 so that version magic string doesnt block my USB?
thanks in advance!
R28.1 comes with 4.4.38, I am curious where the 4.4.15 is from? Either way, you only need the module, not the entire kernel (though it is wise to make sure the config compiles as a kernel prior to using it for just a module). It might be necessary to find out what you are using the 4.4.15 kernel for…personally I’d just use the source_sync.sh script directly on the Jetson, use the “/proc/config.gz” plus a CONFIG_LOCALVERSION to match, and build that. Once this works, I’d use “make nconfig” to find and enable the module. If you stray from the official NVIDIA kernel it is going to get complicated fast.
Thanks for the response. As I am new to all this, can you please explain how to do the source sync and rebuilding?
In the driver package, which produces directory “Linux_for_Tegra/”, there will be a script called “source_sync.sh”. Note that JetPack downloads the driver package since it is only a front end during flash, so you will have this directory and file regardless of whether you use JetPack or just download the driver package. The source_sync.sh script itself can be copied elsewhere…I have a copy on the Jetson itself, not just on the host.
source_sync.sh downloads the kernel source and some subdirectories related to firmware. Some locations within the kernel source (under certain configurations) will use a relative path outside of the kernel tree which reference the firmware files in this extra content…this is why source_sync.sh is the way to go when getting kernel source for R28.1.
The actual command is:
./source_sync.sh -u tegra-l4t-r28.1
One mistake people sometimes make is to not set CONFIG_LOCALVERSION. Your existing configuration in “/proc/config.gz” is an exact match for your running system…except for CONFIG_LOCALVERSION. The kernel looks for modules in “/lib/modules/$(uname -r)/”. The “uname -r” command itself has as its components the kernel source version (e.g., “4.4.38”) and a suffix from CONFIG_LOCALVERSION. If CONFIG_LOCALVERSION is “-tegra”, then “uname -r” will be “4.4.38-tegra”, and modules would be searched for by the kernel from this build at “/lib/modules/4.4.38-tegra/”. If you miss the CONFIG_LOCALVERSION, then modules may not be found…or you will need a new module directory. If you are in a menu editor (e.g., “make nconfig” or “make menuconfig”) it is “General setup → Local version”.
The source_sync.sh script may append a “+” to your CONFIG_LOCALVERSION as well (it’s kind of annoying). You may find the module will work in the original directory if you just install modules and not the Image.
Here are details:
https://devtalk.nvidia.com/default/topic/1028931/jetson-tx2/aws-greengrass-core-on-nvidia-jetson-tx2-requirements/post/5233943/#5233943
Note that most instructions you find refer to cross-compiling…on R28.1 you can also compile natively on the TX1. For a TX1 with four CPU cores you could compile with “-j4” instead of “-j6” from a TX2. If you are cross compiling on a host with 8 cores you could use “-j8” (“-j1” is fine everywhere…it just uses a single CPU core).