jetson_clocks fail after kernel rebuild..

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.