I had to rebuild the kernel with ‘xpad’ support but then the jetson_clocks stopped working…
I get this:
nvidia@xavier1:~$ sudo ./jetson_clocks.sh
[sudo] password for nvidia:
./jetson_clocks.sh: line 265: /sys/devices/17000000.gv11b/devfreq/17000000.gv11b/min_freq: No such file or directory
Error: Failed to max GPU frequency!
I suspect I am missing a specific kernel module/driver…
where I can get the default JetPack 4.1.1 Kernel’s .config file ??
Thanks!!
cheers.
The kernel config is under kernel/kernel-4.9/arm/arm64/config.
Unfortunately, that path you provided does not exist… :(
There is however a
kernel/kernel-4.9/arch/arm64/configs
And that contains 7 different configs… which one is the one that the Xavier is built with ?
I loaded tegra_defconfig and modified it and that is the one that gave me the jetson_clocks error…
-rw-r--r-- 1 usr usr 10486 Nov 29 22:46 defconfig
-rw-r--r-- 1 usr usr 7637 Nov 29 22:46 ranchu64_defconfig
-rw-r--r-- 1 usr usr 19732 Nov 29 22:46 tegra_android_defconfig
-rw-r--r-- 1 usr usr 23285 Nov 29 22:46 tegra_defconfig
-rw-r--r-- 1 usr usr 4374 Nov 29 22:46 tegra_early_boot_defconfig
-rw-r--r-- 1 usr usr 16499 Nov 29 22:46 tegra_gnu_linux_defconfig
-rw-r--r-- 1 usr usr 24 Nov 29 22:46 tegra_gnu_linux_defconfig_debug.config
lrwxrwxrwx 1 usr usr 26 Nov 29 22:46 tegra_gnu_linux_early_boot_defconfig -> tegra_early_boot_defconfig
lrwxrwxrwx 1 usr usr 38 Nov 29 22:46 tegra_t186ref_gnu_linux_early_boot_defconfig_debug.config -> tegra_gnu_linux_d
Just a note: Those files in “/sys” are actually from a driver’s output, and are not real files. If the file disappeared, then it is because the feature went away in the kernel config.
Thanks - Any tips on which .config file is used by Jetpack would solve my problem :)
I think I figured it out and I m now running a sucessfully cross-compiled kernel with everything working.
I copied the original .config from /proc/config.gz right after original Jetpack install / flash
Then I used xconfig to load the .config and added xpad for kernel make.
then I cross-compiled and flashed the new kernel…
Issue 1 - the /lib/modules are not copied over when you flash the kernel, so you need to manually transfer the contents of “kernel_supplements.tbz2” for your specific kernel string from “uname -a”
Issue 2 - I got general “module load” failures from systemd-modules-load.service and I had to disable a few services from loading. for example my logitech mouse/keyboard failed to load universal dongle module… so I had to disable offending modules…
To fix issue 2 : Check your “systemctl status systemd-modules-load.services” for failures and then look at the journal for that specific PID using “journalctl _PID=xxx” then fix it… I had to remove bluetooth and parralel port printer drivers from loading…
Now everything seems to work just fine, including jetson_clocks !
Btw, the CONFIG_LOCALVERSION kernel config adds a suffix to the name which appears from “uname -r”. So if the base kernel version is “4.4.38”, and your “uname -r” shows “4.4.38-tegra” from the original kernel, then it implies that CONFIG_LOCALVERSION was “-tegra” at that time. The modules are searched for in:
/lib/modules/$(uname -r)/
If you have a new kernel with the same original version, but different CONFIG_LOCALVERSION, then you need to install new modules as well. If you kept CONFIG_LOCALVERSION, such that “uname -r” remains constant regardless of which kernel you have, then the modules will be reused from the same location.
I usually go to a new CONFIG_LOCALVERSION if I change a base integrated feature of the kernel (more so when removing a base feature than adding a new feature). If you happen to know that the config is compatible despite a new “uname -r”, then you could just recursively copy the old module directory into the new “/lib/modules/$(uname -r)/” location.