download the code. OK.
jhan@jhan-linux:~/nVidia/document/TX1/Linux_for_Tegra$ ./source_sync.sh -k tegra-l4t-r23.2 -u tegra-l4t-r23.2
ToolChain install. OK
sudo mkdir /opt/linaro
sudo chmod -R 775 /opt/linaro
sudo chown -R $USER /opt/linaro
cp gcc-linaro-5.3-2016.02-x86_64_aarch64-linux-gnu.tar.xz /opt/linaro
cp gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz /opt/linaro
cd /opt/linaro/
tar -xf gcc-linaro-5.3-2016.02-x86_64_aarch64-linux-gnu.tar.xz
tar -xf gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz
Specify the path to the toolchain. OK
mkdir -p $DEVDIR/images/modules
mkdir -p $DEVDIR/images/packages
export CROSS_COMPILE=/opt/linaro/gcc-linaro-5.3-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export CROSS32CC=/opt/linaro/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
export KERNEL_MODULES_OUT=$DEVDIR/images/modules
export ARCH=arm64
Clean your kernel and configuration. OK
cd $DEVDIR/TX1/Linux_for_Tegra_tx1/sources/kernel_source/
make mrproper
Apply following change to avoid error: r7 cannot be used in asm here. OK
kernel_source/arch/arm64/kernel/vdso32/Makefile
kernel_source/drivers/platform/tegra/tegra21_clocks.c
change two files.
Configure your kernel. Not OK.
make tegra21_defconfig
After making tegra21_defconfig I got the following error report:
HOSTCC scripts/basic/fixdep
GEN /home/asser/stage/Makefile
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
Where did you get the kernel source? This should be in any kernel released by NVIDIA for the TX1.
Note also that the URL you gave implies you have set up some other directories, but that you execute the commands from the kernel source directory. the “O=” mentioned puts temporary and generated content in a different directory while preserving the original kernel source. If the “O=” option is used inconsistently, then some parts of the process would perhaps be completed in the wrong place.
Thanks for your replay.
Basically, I follow the following URL to set up TX1. Compiling Tegra X1/X2 source code - RidgeRun Developer Wiki
After I’ve completely done the things on the page I was stopped at step 5 of “BUILD KERNEL” part.
The version of kernel source I used is tegra-l4t-r24.2.1.
I am not sure what’s the meaning of {L4T_OUT}. Can I set it as ~/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/sources/kernel_source？
I am not familiar with these stuffs. Thank you again.
I don’t see “{L4T_OUT}” listed in that URL, but here is some general info if you are not familiar with the Linux environment…
When you work on the command line (text console) you have available “environment variables”. These can be custom set, or they can be used in other commands via substitution. To illustrate, here are a couple of them which are displayed via the “echo” command:
echo $HOME
echo $SHELL
The variables are “HOME” and “SHELL”. The “$” says to substitute with the value. Had you used echo with just “HOME” or “SHELL”, then it would have replied “HOME” or “SHELL”. The “$” is the magic to substitute. Note that you can put curly braces around this and it is the same thing…useful when two substitutes might be confusing, e.g.:
echo ${HOME}
echo ${SHELL}
In the ridgerun web page several environment variables are custom set for use with commands, e.g.:
cd $DEVDIR/TX1/Linux_for_Tegra_tx1/sources
…this assumes you have previously set up DEVDIR with the name of where your development directory is. Assuming your home directory is “/home/ubuntu” these two commands would both produce a place for development which you could call DEVDIR:
mkdir /home/ubuntu/jetson
mkdir ${HOME}/jetson
You could set up the DEVDIR at that point via either of these commands:
In that article you can assume anything with a “$” prefix needs to be set first. You can test if it is set with “echo $WHATEVER” or “echo ${WHATEVER}”. The “{L4T_OUT}” might be something JetPack assumes, I don’t know…but somewhere you probably need to use “mkdir” to create a temporary output location, and then set this via “export L4T_OUT=/where/ever/it/is”. Once this is done anything using “{L4T_OUT}” will succeed.
You can use sudo on “make mrproper”, but in general should not use sudo for build steps on a kernel…file permissions will be altered and then only root can deal with it. Typically sudo is only used during an install step, and then only if the install is to the same machine the build is on.
…you’ll see several “O=something” entries. These are for separating generated files from the original source. This is useful with the “make tegra21_defconfig”…or “make O=$TEGRA_KERNEL_OUT tegra21_defconfig”. The command itself is run from the kernel source, the output and changes end up at $TEGRA_KERNEL_OUT.
The person with the original post had this show up as well:
…tegra21_defconfig is not part of x86, so it is picking the Jetson defconfig from the PC’s architecture…which is wrong. The question is why it thinks you are building for a desktop PC architecture instead of an arm64 architecture. Were the environment variables set first, especially this one (you should see “arm64” if you “echo $ARCH”:
To start with you probably need to fix the permissions caused by the “sudo make”. Option one, delete the source and anything in the output locations, then unpack the source again without sudo; option two, from your kernel source tree directory, and assuming you are logged in as user “ubuntu”:
…is that when you use sudo your environment variables go away and the ARCH and compilers you set up in environment variables no longer exist (when you sudo you are user “root”…it was your other user you set up the environment variables such as “ARCH”). sudo probably got in the way with some of the temp files now being locked in to the missing “ARCH” setup which your regular user can’t change. Being in the kernel source when you run “sudo make mrproper” would fix that for the kernel source tree, but if the “somewhere” of “make -O=somewhere mrproper” used an environment variable then “somewhere” would be lost and it would have never fixed your output directory…sudo does not know about “O=somewhere”.
Once permissions are cleaned up try again with no use of sudo.
But it still needs permission.
It didn’t work by useing
chmod 777 source_sync.sh
Here is the error
Downloading default kernel source…
fatal: could not create leading directories of ‘/home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/sources/kernel_source’: Permission denied
/home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/sources/kernel_source source sync failed!
Downloading default u-boot source…
fatal: could not create leading directories of ‘/home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/sources/u-boot_source’: Permission denied
/home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/sources/u-boot_source source sync failed!
I also tried
./JetPack-L4T-3.0-linux-x64.run
to install the whole things again.
But it asked for permission too.
The “Permission denied” seems to say that the directory you are currently in when running the download or file edit is what denies the permission. The current directory can be named by “.”. Compare that to your login user name:
whoami
ls -ld .
touch test_if_i_can_write_here.txt
rm test_if_i_can_write_here.txt
Perhaps earlier use of sudo changed ownership of where you are to root. Permissions may have been changed for content within the parent directory, but the parent directory itself still matters even if the other directories allow edits.
One thing to be aware of (not an error, but could get in the way) is that directories/files with only a numeric ID are items with an ID which does not exist on your host. These do need to be preserved in the rootfs subdirectory, but outside of rootfs these are a problem. Example from your above ls:
(Just for information, user ID 1001 is user “nvidia” in the sample rootfs…user ID 1000 is user “ubuntu” in the sample rootfs…to know which user ID belongs to who on the PC you would view “/etc/passwd”).
The “rootfs” directory should be owned by you, not a non-existent user ID. Root user is required to manipulate anything without a user ID (and ID 1001 is without a user on your PC). This means you used sudo to unpack things, which is a mistake at this stage. Unpacking a sample rootfs requires sudo, but unpacking the driver package should not use sudo.
Related information: Whenever you upack a tar file as root (using sudo) the numeric ID of the file owner is preserved. Whenever you unpack a tar file as a non-root user ownership will always go to the numeric ID of the person doing the unpack. In most cases you want the ID to be translated to the person doing the unpacking. In the case of the sample rootfs it must be unpacked as root because the file system being unpacked eventually becomes part of a different computer (the Jetson) where those IDs are actually correct. If it goes into a remote system the ID should be preserved…if it goes into your PC host, then IDs need to become that of the regular user doing the unpacking.
Perhaps the easiest way to proceed would be to delete the entire Linux_for_Tegra directory and unpack the driver package again without sudo…then in rootfs unpack sample rootfs with sudo. The directory from which the unpack of the driver package occurs would need to be owned by your regular user, not root…otherwise you will get permission denied. If you ever altered permissions of the content in the rootfs subdirectory your flash will work, but the Jetson won’t boot correctly…you would have to start over anyway.
That wiki page uses source_sync.sh which would provide an updated kernel version if there is a new kernel. So the answer depends on whether you want to just get whatever source code is pushed most recently, or if you want to always have a particular version until manually changing to a new version. This could be significant, but I think updates are not often, so for at least part of the time there is no difference between the two. It’s sort of a “try it and see which appeals to you”.
Is there other website that I can chose?
I just need the easiest one so far.
So after done this:
export CROSS_COMPILE=/usr/local/gcc-linaro-5.2-2015.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export CROSS32CC=/usr/local/gcc-linaro-5.2-2015.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
export ARCH=arm64
export TEGRA_KERNEL_OUT=${L4T_OUT}/stage
export TEGRA_MODULES_OUT=${L4T_OUT}/modules
export TEGRA_FIRMWARE_OUT=${L4T_OUT}/firmware
make mrproper
make O=$TEGRA_KERNEL_OUT mrproper
make O=$TEGRA_KERNEL_OUT tegra21_defconfig
make O=$TEGRA_KERNEL_OUT menuconfig
make -j4 O=$TEGRA_KERNEL_OUT zImage
make -j4 O=$TEGRA_KERNEL_OUT dtbs
make -j4 O=$TEGRA_KERNEL_OUT modules
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
make O=$TEGRA_KERNEL_OUT firmware_install INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT
The kernel itself is the “Image” file (“zImage” is the compressed version, but U-Boot seems to be 32-bit and does not support zImage decompression…at least that is my guess) and is a simple copy to the “/boot” directory. It would be best to not overwrite the existing Image file. Notice that the “/boot/extlinux/extlinux.conf” names the Image file, and you could edit the name “Image” in extlinux.conf to be something like “Image-custom” (this has no effect on “uname -r”, nor on where modules go). Typically I save a backup of Image as “Image-original” in case I make a mistake. You could also add a second boot entry and leave the original entry as is…in which case you’d need a serial console to pick the other entry at boot time…if that boot entry is good, then you can set the alternate entry as default.
If “uname -r” did not change you can just add whatever modules from the modules output directory tree into the Jetson modules directory following whatever directory tree the new module is in. Typically you’d run “sudo depmod -a” and either reboot or “sudo modprobe <whatever_the_module_is>”.
If “uname -r” changed (or if you failed to set CONFIG_LOCALVERSION) you’ll need to copy the entire produced to the new “/lib/modules/$(uname -r)/”. Typically you’ll want to manually do a recursive copy of the original module directory’s subdirectory “extra/” into this new “uname -r” location (this is true for a TX1 and K1, but it looks like the newer TX2 does not use this on R27.1).
Normally the initrd file does not change…if it does, then the instructions are the same as for the Image file, except the extlinux.conf names it with the INITRD key/value pair instead of the LINUX key/value pair. Unless something was changed to support new hardware configuration the same is true of the device tree file…normally this won’t change, but if it does, it is named in extlinux.conf via the FDT key/value pair…this too is a simple file copy. As usual, try to not overwrite original versions…and if you have a serial console, you’ll want to try an alternate boot entry before committing, followed by setting the new entry as default if the boot does as desired.
I try to keep file names related to the “uname -r”. So my original Image might become “Image-3.10.96-tegra_original”, a new Image might be “Image-3.10.96-test1”. Naming as such will make it clear to both yourself and others what the kernels are long after you’ve forgotten what you’ve edited.
But I get another error at step 14.
Here is my output:
Using rootfs directory of: /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the NVIDIA user space components to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the BSP test tools to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the NVIDIA gst test applications to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the chromium browser to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the configuration files for the supplied root filesystem to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Creating a symbolic link nvgstplayer pointing to nvgstplayer-1.0
Creating a symbolic link nvgstcapture pointing to nvgstcapture-1.0
Adding symlink libcuda.so → libcuda.so.1.1 in target rootfs
Adding symlink libGL.so → libGL.so.1 in target rootfs
Adding symlink libnvbuf_utils.so → libnvbuf_utils.so.1.0.0 in target rootfs
Adding symlink libcuda.so → tegra/libcuda.so in target rootfs
Adding symlink libEGL.so → libEGL.so.1 in target rootfs
Adding symlink /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs/usr/lib/aarch64-linux-gnu/libdrm_nvdc.so → /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs/usr/lib/aarch64-linux-gnu/tegra/libdrm.so.2
Adding symlink nvidia_icd.json → /etc/vulkan/icd.d/nvidia_icd.json in target rootfs
Adding symlinks for systemd nv.service and nvfb.service
Disable the ondemand service by changing the runlevels to ‘K’
Extracting the firmwares and kernel modules to /home/asser/JetPack-L4T-3.0/64_TX1/Linux_for_Tegra_64_tx1/rootfs
Extracting the kernel headers to /usr/src in target rootfs
sed: can’t read /README: No such file or directory