Gooddays everyone，
I amend the new kernel and generate the Image， zImage files with the order ‘make menuconfig, make zImage’.Then I transplanted the new Image, zImage to the TX2 board with the order ‘ sudo ./flash.sh jetson-tx2 mmcblk0p1’.
However, when I open the TX2, I found the speed of the board didn’t change that made me confused.
The flash process itself will take mostly what is in the “Linux_for_Tegra/rootfs/” directory and turn that into the actual root filesystem image. While creating that rootfs the actual “rootfs/boot/” content is usually edited, including the Image file (look at the sha1sum of “Linux_for_Tegra/kernel/Image”, and “Linux_for_Tegra/rootfs/boot/Image”, then compare to the checksum of your modified kernel). Are you sure your Image actual made its way in? FYI, a simple file copy would work directly to the Jetson, a full flash is not necessary.
Keep in mind that if the kernel changes, then the “uname -r” will probably change too (unless you specifically configured to keep the same “uname -r”). Modules are searched for at “/lib/modules/$(uname -r)/”, and if your kernel changes this, then you must also install new modules at the new location.
If you want to see the actual config of the running kernel, then take a look at “zcat /proc/config.gz”. Do your changes show up in that?
In terms of making a new kernel, I always recommend starting with the same initial config, and then editing via something like “make menuconfig” or “make nconfig”. If you have the “/proc/config.gz” of the unmodified kernel, and save this somewhere safe, and if you also update the “CONFIG_LOCALVERSION” to match the suffix of the “uname -r”, then it should match and be a perfect starting point. For example, if your “uname -r” is something like “4.4.38-tegra”, then you would want your ‘CONFIG_LOCALVERSION=“-tegra”’. This in combination with a “4.4.38” release kernel should give you “4.4.38-tegra”.
There are many configs which won’t have any effect. We often hear about “bloated” kernels, and “bloated” software. If too much code has to run, then more RAM is used, so on. The default config will not need to use swap. Drivers which are in the format of a module won’t even load unless they are used. Integrated drivers might in some way cause a minor slowing if there are a lot of them even if not used, but significant speed-ups probably require planning and looking at the details of what is slow.
You will probably need to describe what was slow, and what it is you’ve reconfigured (after verifying your kernel actually made it in) to try and change this.
Also, you can change power profiles which were designed to control power useage. To set to max performance profile, run “sudo nvpmodel -m 0”. To then force clocks and fans to max under that configuration, run “sudo jetson_clocks”. This could speed things up if the Jetson was just conserving energy.
1 Like
Thanks，I‘m already solved the problem