Dear sir:
I am new to jetson, i have opened CONFIG_PRINTK_TIME in kernel config, but it did not take effect in the kernel uart log message, how can i check? Tks!
I haven’t tried changing that parameter, but did you add this using a config editor (versus editing the “.config” directly)? I assume you used “=y”, which in turn implies the entire kernel (and possibly all modules) would need to be rebuilt. Once you built the kernel, what was your install procedure for putting the new kernel in place? Once booted, what do you see from “uname -r”?
Do note that on a running system you can see a copy of the actual configuration the kernel is using. This file produces an exact copy of the configuration of that kernel other than it won’t show the “CONFIG_LOCALVERSION” (once CONFIG_LOCALVERSION is set up this becomes a 100% perfect match for the running kernel):
/proc/config.gz
Basically you will want to copy config.gz to some other location, gunzip config.gz, and see if your changes made it in. Alternately:
zcat /proc/config.gz | grep 'CONFIG_PRINTK'
(to see all CONFIG items with “PRINTK” in their name)
Dear sir:
I have checked the output file .config of tegra_defconfig. The config CONFIG_PRINTK_TIME=y.
After i changed, then i do the following operations:
1.make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
2.make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j
3. Replace <release_packagep>/Linux_for_Tegra/kernel/Image with a copy of:
$TEGRA_KERNEL_OUT/arch/arm64/boot/Image
4. Replace the contents of Linux_for_Tegra/kernel/dtb/ with the contents of:
$TEGRA_KERNEL_OUT/arch/arm64/boot/dts/
- flash the system by the command:
sudo ./flash.sh jetson-nano-devkit-emmc mmcblk0p1
Is this a native compile on the Jetson, or a cross compile on a host PC? If this is a cross compile you would use the “ARCH=arm64”, but if this is native, then you would not use this.
Then to build the actual kernel I would use target “Image” rather than building everything.
Note that if your CONFIG_LOCALVERSION does not match what was running, then you’d need to install all modules as well. When you answer “=y” there is a chance you might want to install all of the modules again using a new “CONFIG_LOCALVERSION” to use a different module directory (some “integrated” features…meaning non-module…might be sufficiently invasive to require modules to also be rebuilt…don’t know for your case).
Btw, you don’t have to flash to install a kernel unless you want the kernel in a partition instead of in the rootfs. An example of why you might do this is if security fuses are burned (in which case only the signed partition is allowed). The LINUX key/value pair in extlinux.conf points at the kernel in “/boot”, and is higher priority than is the partition based kernel.
Also, once booted, what do you see from this content which is reported by the running kernel:
zcat /proc/config.gz | grep 'CONFIG_PRINTK_TIME'
Dear sir:
Tks!
This is a cross compile on a host PC.
Did you also name your cross tools during the compile? For cross compile you’d have to use a valid release version of the cross tools for that kernel, and I did not see any mention in your commands of naming a cross tool chain. The official docs mention not only how to do this, but also that you can find the exactly versioned cross tools at the same location you’d find the flash software.
What follows is not exactly correct for your case, editing would be needed, and the official docs regarding kernel customization provide what you need, but this is a “pseudo” example of what a compile might look like. This does more than you need since it is also for demo purposes. Thus, this includes things you won’t need and uses locations and content which would likely be wrong on your system. Use the official docs for the simplest way of doing this, but this might explain some things about temporary output locations the docs don’t explain:
# The cross toolchain has all of the build commands in it, but they are all
# prefixed with "aarch64-linux-gnu-". A build macro substitutes this so if
# the compile uses "gcc", then it results in actually calling
# "/usr/bin/aarch64-linux-gnu-gcc".
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
export ARCH=arm64
export SRC=/home/myself/Documents/embedded/L4T/R32.1/src/kernel/kernel-4.9
export STAGE=/home/myself/Documents/embedded/L4T/build
export TEGRA_KERNEL_OUT=/home/myself/Documents/embedded/L4T/build/stage
export TEGRA_MODULES_OUT=/home/myself/Documents/embedded/L4T/build/modules
export TEGRA_FIRMWARE_OUT=/home/myself/Documents/embedded/L4T/build/firmware
# STAGE: /home/myself/Documents/embedded/L4T/build
# Note that you would only rm content if there was a previous build
# that you don't want getting in the way. The goal is that on a new
# build you would want to start with clean temporary directories,
# and that's what the rm commands below are for. Ignore the rm if
# you are starting with empty directories (it is ok to keep the previous
# .config file if it is known correct).
#
# Special note: Removing "something/*" removes the content within a
# directory, whereas removing "something/" removes the directory itself.
# The reason why this is important is that "something/*" does not see
# files beginning with ".", and there is temporary content starting with
# file name "." in the directory which gets removed and added back. The
# other directories don't have any content which would be missed by
# not seeing the dot "." files.
rm -Rf /home/myself/Documents/embedded/L4T/build/stage/
mkdir -p /home/myself/Documents/embedded/L4T/build/stage/
rm -Rf /home/myself/Documents/embedded/L4T/build/modules/*
rm -Rf /home/myself/Documents/embedded/L4T/build/firmware/*
cd /home/myself/Documents/embedded/L4T/R32.1/src/kernel/kernel-4.9
# Note that this mrproper runs in the original source code directory. Only the
# temporary locations should have any modification or temporary output.
sudo make mrproper
# This runs mrproper in temporary directories. Mostly I'd ignore this and just
# use the previously shown rm of temp locations to clean those. Demonstrates
# there is more than one way to do this.
make O=$TEGRA_KERNEL_OUT mrproper
# The "clean" target is similar to "mrproper", but less thorough.
make O=$TEGRA_KERNEL_OUT clean
cp /home/myself/Documents/embedded/L4T/R32.1/tx1/src/config-4.4.140-tegra "${TEGRA_KERNEL_OUT}"/.config
chmod u+w "${TEGRA_KERNEL_OUT}"/.config
# I use the vi editor, you probably want something else if you don't know vi
# since it is a high learning curve. This could actually be skipped entirely by
# making all config from the "make nconfig" step. I use an editor on the
# CONFIG_LOCALVERSION of the ".config" since I know there are no chain
# dependencies and it is easier than searching for "localversion" in the
# nconfig tool, but nconfig can do this as well. Ask about CONFIG_LOCALVERSION
# if you have any questions.
vi "${TEGRA_KERNEL_OUT}"/.config
# This just verifies what you've set CONFIG_LOCALVERSION to. A stock NVIDIA
# kernel will use CONFIG_LOCALVERSION="-tegra".
egrep CONFIG_LOCALVERSION "${TEGRA_KERNEL_OUT}"/.config
# tegra_defconfig changes the ".config" to a sane starting point. If you use
# the "/proc/config.gz" to get your ".config", then you'd skip this. If the
# /proc/config.gz is from an unmodified Jetson, then the result will be the
# same as tegra_defconfig.
make O=$TEGRA_KERNEL_OUT tegra_defconfig
# This is what I'd use to customize since nconfig has a symbol search option.
make O=$TEGRA_KERNEL_OUT nconfig
# The actual kernel. I suggest always compiling this once to make sure
# it sanity checks even if you don't need the actual Image file. This also
# propagates dependencies.
make -j4 O=$TEGRA_KERNEL_OUT Image
# Unless you are in need of the device tree you won't need this.
make -j4 O=$TEGRA_KERNEL_OUT dtbs
# This builds all of the modules. Won't work right unless you propagated
# config earlier via building the Image target, or else using
# "make modules_depend".
make -j4 O=$TEGRA_KERNEL_OUT modules
# This outputs modules to the temp location in a directory tree exactly
# matching what the actual kernel module directory looks like. Makes
# it easy to recursively copy the content into the module location. Just
# be sure you copy to the Jetson's module location and not the host
# PC's location.
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
# It would be quite rare to need firmware install. Shown only for demonstration.
make O=$TEGRA_KERNEL_OUT firmware_install INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT
Just to emphasize, you made these changes originally on the host PC to the rootfs, which works great for making the content available to a newly flashed Jetson without other steps. However, we are interested in not reflashing the Jetson just to see what is wrong. What we want is a running Jetson with your flashed content so that we can test module insert to see what actually happens. You can’t do that from the host PC.
Dear sir:
I have checked the config.gz file. The CONFIG_PRINTK_TIME=y . You can check the attachment.
config.gz (37.1 KB)
According to that it should work. Do you also have modules for that kernel under subdirectories of this:
/lib/modules/$(uname -r)/kernel
Is that content on the running Jetson? What you see on the host PC is not necessarily useful. If you literally run the Jetson and type the following command, then it will embed the output of “uname -r” into that command, and this is a reflection of the kernel itself telling you its version:
ls /lib/modules/$(uname -r)/kernel/
(if this shows content when run directly on the Jetson, then your kernel is set up correctly for the modules in that location)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.