After compile and flash the R32.1 source core,TX2 stop at “Started Update UTMP about System Runlevel Changes”,and the screen keep blink.
How to fix this error?
One does not normally compile the source code…it is provided pre-built in the form of the sample rootfs (the root file system sample this is built on is purely Ubuntu open source…compiling the source would be similar to compiling every package on a desktop Ubuntu system to install instead of using the pre-built packages). A normal flash through SDK Manager simply downloads this into the “rootfs/” folder and then overlays the NVIDIA hardware-accelerated libraries on top of it. Flash does not compile anything.
More details would be useful. Are you building a custom system and not using the SDK Manager? Or was this just a flash using SDK Manager?
If you did perform a regular flash maybe you could post serial console boot logs (video can fail even when the system otherwise boots normally). For serial console information see:
[url]http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/[/url]
Note: There is some compiling on the host after the TX2 has been rebooted and the extra packages get installed. The compiling is of the sample apps for CUDA and not the operating system.
I followed the steps in sections “Kernel Customization” which provided by NVIDIA_Tegra_Linux_Driver_Package, it seems like I forgot to install the kernel modules. Does lack of kernel module will cause the error?
when excute the command
“sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install
INSTALL_MOD_PATH=Linux_for_Tegra/rootfs/”
a lot of choices should to make, where to find the introductions?
What it comes down to is that the kernel version and the kernel config item “CONFIG_LOCALVERSION” sets up what the command “uname -r” replies with. Modules are searched for at:
/lib/modules/$(uname -r)/
This means that if your “uname -r” (base kernel version plus CONFIG_LOCALVERSION) is constant, then modules will still be found even with a new kernel. Conversely, even if you use the original kernel version and configuration, but fail to set a matching “CONFIG_LOCALVERSION”, then the modules will be missing until you install them.
The modules are features. You can add features in two formats: Either integrated into the kernel, or as a module (not all features can be built as a module, but most drivers can). If you do not change the integrated features, then it is custom to keep the “CONFIG_LOCALVERSION” such that “uname -r” does not change…and to thus reuse existing modules, but perhaps add a new module. If you change integrated features, then it is custom (and sometimes mandatory, but not always mandatory) to also change the “uname -r” via changing “CONFIG_LOCALVERSION”. This is because some modules can load into the kernel based on the integrated features…if the integrated features change, then module load could fail or not behave as expected (it is better to not find out after you’ve dedicated to using a kernel that it has problems).
Missing modules can have different effects. Some missing modules might do something you won’t even notice. Others will break features. More could possibly even crash the system or prevent boot. So it is important that modules be correctly found.
Because you are using the kernel customization docs can I assume you are cross compiling on your host PC? Also, do you still have a TX2 booting with the original unmodified kernel? I ask because the best starting configuration is the configuration of the original kernel you wish to modify. A running Jetson has file “/proc/config.gz”. This is not a real file, it is instead content in RAM produced by the running kernel, and other than “CONFIG_LOCALVERSION” being empty, this is an exact match of the kernel’s configuration at the time it was built. You will see reference to “make” steps with an “_defconfig” target. Presumably the defconfig is close to this default config.gz, but it isn’t guaranteed (and I’m pretty sure it is not an exact copy).
Since the base kernel version of R32.1 is “4.9.140”, and since “uname -r” is “4.9.140-tegra”, then you know the suffix “-tegra” is what “CONFIG_LOCALVERSION” needs to be set to in order to keep a matching “uname -r”. If you save a pristine copy of config.gz somewhere safe, and add a copy to your build output location, gunzip it (the “.gz” is compressed), rename it to “.config”, and edit “CONFIG_LOCALVERSION” like this, then you are in the perfect starting config with this edit:
CONFIG_LOCALVERSION="-tegra"
With this in place you would not use any “make” with “defconfig”. This would already be done. If you use an option editor like “make menuconfig” or “make nconfig” (my favorite), then the only change needed would be to add whatever edit you in need of. If you add that edit as a module (versus integrated), then after completing compile all you would need to do is copy the file to the right location somewhere in “/lib/modules/$(uname -r)/” (the subdirectory typically matches that in the kernel source, so if it is somewhere in “drivers/”, then you’ll find that same somewhere within “drivers/” of “/lib/modules/$(uname -r)/”). No flash would be required to add a module, but you might want to flash again if you can’t boot (in part because you always want to save a pristine safe copy of “/proc/config.gz” and this won’t be possible with a modified kernel).