Error Tx1 ISO

Hi everyone,

I hope that everything is fine.

I’m new in this area, and I’m trying to use TX1 with a 4g-usb, but when I add this hardware, I’m noticed with:

ISO9660 (and Rockridge extensions) is a filesystem used on CDs and DVDs (Rockridge extensions add long filenames from Windows CDs/DVDs on top of ISO9660). I am betting you don’t see “CONFIG_ISO9660_FS” when checking for kernel features:
zcat /proc/config.gz | grep 'ISO9660'

The “=n” means not available as either integrated or module format.

The gist is that you will want to follow the “kernel customization” docs which come with your particular release (more on that below) and add the kernel module for this. The docs give information for replacing and installing a kernel, but you don’t need to do this. Once the module is built it is just a single file copy and you are done (well, it might be another if there is another requirement for character sets/encodings, but it won’t be difficult, and you can start with just the ISO9660 module).

Each Jetson release has docs specific to that release. This is the “L4T” release. See:
head -n 1 /etc/nv_tegra_release

Once you have that, go to the URL for that release:

If for example it is R32.7.2, then you would go to that, and kernel source and docs would be available with that specific release. TX2 and TX1 kernel source are actually going to be the same if they are from the same release. Any document reference to a T210 is a TX1 (the T210 is the SoC chip a TX1 uses).

Before you start write down the result of “uname -r”. You’ll see a base kernel version, along with a suffix like “-tegra”. The kernel source itself has the base version, but the suffix comes from a setting at compile time, the CONFIG_LOCALVERSION. Follow the docs to set config to default, but then make sure you set CONFIG_LOCALVERSION to “-tegra”. If the new kernel build matches in this way, then you can add a module (like ISO9660) with just a file copy and no flash or special step. You’re basically making a clone of the existing kernel, and then adding a module, and thus the module is compatible with what is already there to simplify install.

This is only part of the info, but you can ask for clarification as you go. Don’t bother with flash, it is unnecessary. Build the full kernel as a kind of “test” as to whether you are set up correctly, and then build modules. Then simple steps can be provided to copy that one file when you are ready.

Also, there might also be another step related to Rockridge extensions, not sure, but that might just be a package install and might not require a kernel module. Or it might not even be needed. We’ll find out.

You’ll want to use the official docs, but here is a long explanation of what is actually pretty simple if you’ve done it once:

Hi @linuxdev,

I tried to update all things in Ubuntu. And start work with what you tell me, the version is 28.1.

I’m really new in this area, and I didn’t make it following the documentation that you sent me.

In ubuntu with graphics, doesn’t have app and I can’t open terminal, so, probably i need to resolve this problem in login terminal when TX1 is boot.

Can you help?

R28.x is very old and has had many bug fixes in R32.x. Is there a possibility you could upgrade to the latest R32.x first? This wouldn’t change the kernel module build, but overall bug fixes would make this less frustrating.

So far as not being able to open a terminal, you previously created a screenshot…did the GUI work before, but then fail? Was there a step or change which you can identify as the moment when the terminal stopped working? Do you still have serial console and/or ssh access?

So man, I can’t update this TX1, because the program that I have inside it’s in this version for while.

I don’t know why, but after some minutes, the GUI works and open the terminal, but I realized some flicks (screen flickering), but it stopped.

I really need to resolve this problem about ISO rsrs

What i need to do now? What is the next step?

Thanks buddy.

This is actually easier than it sounds below, but I’m including information which people might find useful for this older version and for steps which might only be needed once (adding tools and such only needs to be done once). I think instructions are a bit easier on newer releases. Questions are likely, but the docs are relatively complete even if they suggest extra steps you don’t need.

Note: References to “zImage” refer to the compressed kernel. Building this builds “Image”, the uncompressed kernel. I want to emphasize you don’t need either, but building “Image” is a useful test of whether it is correctly configured and tools are set up correctly. All you need is a module file, not a full install or flash.

I would suggest that since you have valuable content, then you might want to clone to have a backup (which can also be loopback mounted and examined). Just beware that a partition clone is a huge file. Consider testing if your software could run on a recent R32.x (a clone would be a way to keep content even if things fail, but if you have a second TX1, then obviously that would be better).

For the GUI issue you could post a copy of the log file. The most recent log can be found via:
ls -ltr /var/log/Xorg.*.log | tail -n 1
(it is possible to figure out GUI issues with that file)

You would want to download the kernel source for your specific release.

Within the “source_release.tbz2” you export CROSS_COMPILE=/usr/local/crosstool-ng/4.8.5/bin/aarch64-unknown-linux-gnu-
(keep kernel_src-tx1.tbz2 handy in case you want to use a clean version, throw out the source_release.tbz2)

At that location you have the source for the kernel, but it is unconfigured. Steps then depend on whether it is being compiled natively on a Jetson, or cross compiled from a host PC (cross compile is recommended for a TX1).

The “Documentation” would be used next. Note that this is a tar package of a web page set. You’d want to unpack the docs in an empty directory (or perhaps the directory which had the source “sources/” subdirectory):
tar xvf NVIDIA_Tegra_Linux_Driver_Package.tar

This produces “Start_L4T_Docs.html”, which you would point your web browser at. For example, if you have this unpacked as user “ubuntu” at “/home/ubuntu/Downloads/tmp”:
…which would redirect you to:

From there look for “Kernel Customization”. Ignore the part of using git, you’ve already performend the “manual download”. What you’re interested in is the “Building the NVIDIA Kernel” part. Note that the URL for R28.1 has “Tools”, and the one you’ll be interested in is the “GCC 4.8.5 Tool Chain for 64-bit BSP”. Once this is installed you will have your cross environment tools and won’t need to install that again. In the setup before compiling you will see:
export CROSS_COMPILE=<crossbin>
…this refers to the “bin/” subdirectory of the cross tools. and will the install location plus the suffix:
...install path.../bin/aarch64-unknown-linux-gnu-

With that set up you can configure and build. I suggest build the full kernel Image once after configuring to make sure all is set up correctly. After that build modules. The module you want (if it has been configured) will be there. Configuring is basically to start with the “export” given in the docs, followed by “make O=$TEGRA_KERNEL_OUT tegra21_defconfig” (the tegra21 refers to t210, which is the TX1 SoC).

Once you have run the tegra21_defconfig you will want to set the CONFIG_LOCALVERSION. In the docs they use a kernel output location specified in “$TEGRA_KERNEL_OUT”. If for example we have set up this as “~/kernel_build” (it is up to you where to put this, but use an empty location), then it will produce a “.config” file there. You would edit this, find “CONFIG_LOCALVERSION”, and set to the correct suffix string. If your running system responds to “uname -r” as “4.9.140-tegra” (this is newer than that kernel, so it will differ), then the “-tegra” is the suffix, and the edit would be:

If you were to only build modules, then you would need to propagate config via “make O=$TEGRA_KERNEL_OUT modules_prepare”, but if you build “make O=$TEGRA_KERNEL_OUT Image” first, this also propagates the config, and so you could skip “modules_prepare”. Once build is done you could find the module:
find . -name *9660*.ko

Ignore all document install steps other than to copy that one file to the correct place in the Jetson. It’ll be somewhere under “/lib/modules/$(uname -r)/kernel/”. If in your case it is located in the compile location as “fs/isofs/...something.ko”, then you’d copy to “/lib/modules/$(uname -r)/kernel/fs/isofs/...something.ko”. One can then “modprobe -a” to update the system’s knowledge, or reboot. This will probably work after that.

Here is an example of actual steps once tools exist and the source is there, but keep in mind this compiles more than you want or need…stop once modules are built, and only install a single module via a file copy and not using flash and not updating the Image file itself (and adjust locations of tools and such for your install):

# If not installed, install libncurses5-dev:
sudo apt-get install libncurses5-dev

export CROSS_COMPILE=/usr/local/crosstool-ng/4.8.5/bin/aarch64-unknown-linux-gnu-
export ARCH=arm64
export SRC=/home/ubuntu/jetson/R28.1/src/kernel/kernel-4.4
export STAGE=/home/ubuntu/jetson/R28.1/build
export TEGRA_KERNEL_OUT=/home/ubuntu/jetson/R28.1/build/stage
export TEGRA_MODULES_OUT=/home/ubuntu/jetson/R28.1/build/modules
export TEGRA_FIRMWARE_OUT=/home/ubuntu/jetson/R28.1/build/firmware

# STAGE: /home/ubuntu/jetson/R28.1/build
rm -Rf /home/ubuntu/jetson/R28.1/build/stage/*
rm -Rf /home/ubuntu/jetson/R28.1/build/stage/.[a-z]*
rm -Rf /home/ubuntu/jetson/R28.1/build/modules/*
rm -Rf /home/ubuntu/jetson/R28.1/build/firmware/*tegra21_defconfig

cd $SRC

# mrproper makes sure all starts clean. Running it removestegra21_defconfig a .config. There are two
# possible .config files: One at the source itself if no "`O=/some/where`" is specified,
# plus one at the "O=/some/where" location, and we want source itself to always
# be pristine. Always use "O=/some/where" other than when cleaning out original
# source.
make mrproper
make O=$TEGRA_KERNEL_OUT mrproper
make O=$TEGRA_KERNEL_OUT clean
make O=$TEGRA_KERNEL_OUT tegra21_defconfig

# Use your favorite editor, pico is just an example:
pico "${TEGRA_KERNEL_OUT}"/.config

# "nconfig" or "menuconfig" are GUI editors of config. You just need to search for symbol
# "iso9660", and "nconfig" can do this. Then enable it with "m" to make it as a module.
make O=$TEGRA_KERNEL_OUT nconfig

# You won't need zImage. The step is here though, and using it is a good test of correct config,
# plus it propagates config throughout the source.
make -j4 O=$TEGRA_KERNEL_OUT zImage
# This is the step which creates the ISO9660 module:
make -j4 O=$TEGRA_KERNEL_OUT modules
# This is not used by you, but dtbs is shown (skip dtbs build):
make -j4 O=$TEGRA_KERNEL_OUT dtbs

# The INSTALL_MOD_PATH to $TEGRA_MODULES_OUT just makes it easier to find what you
# want. It'd be in a subdirectory of $TEGRA_MODULES_OUT, and in turn the "lib/modules/$(uname -r)/kernel/" subdirectory (the module is already built, this is just a copy):
# Ignore firmware:

I managed to do the downloads, but as I’m a beginner I don’t know what this CROSS_COMPILE would be… but doing an analysis I realized that there is no CROSS-NG on my system… Could you help me to proceed?

Any compile requires a compiler, plus often other tools, e.g., a linker. The usual compiler on Linux is gcc. When cross compiling the tools need to run on the desktop PC architecture, but work with arm64/aarch64 code. Thus you have your normal arm64/aarch64 tools ported to run on the desktop PC. The “CROSS_COMPILE” names a “prefix” of where to find those tools.

The build scripts normally just say to use “gcc”, but if “CROSS_COMPILE” exists, then it prefixes this. The common convention is to prefix the name of the cross tool with the architecture, but keep the suffix the same. For example, this is one possible “CROSS_COMPILE”:

If you were to cd to “/usr/bin”, a system which has that tool would leave “aarch64-linux-gnu-gcc” there (and probably also an assembler and linker with “aarch64-linux-gnu-” there as well).

For that example the compile script would name “gcc” to compile, but due to the prefix, it would really call and use “/usr/bin/aarch64-linux-gnu-gcc”. So the prefix is where your cross tools are found. The CROSS-NG probably has its own location, with a “bin/” subdirectory, and inside that likely a series of executable tools starting with some prefix likie “aarch64-linux-gnu-”. That full path up to and including the prefix, but excluding the suffix, would be what you would export as “CROSS_COMPILE”. This also allows multiple cross tools for different architectures and even different releases of the same tool. Cross NG was used for the older TX1, so you have the right idea. Where is the “bin/” directory for Cross NG, and what file prefix is used there?

I have all the things downloaded in the /home/downloads, exactly that I sent you before. I don’t know how can I continue for fix it.

What i need to do? I have source files, tegra files

I’m so begginer…

The Crosstool NG is not necessarily installed to the same sample location I gave, and is not necessarily even installed as a regular package (though various releases are available via apt, it isn’t necessarily what you want). Which L4T release are you using? See:
head -n 1 /etc/nv_tegra_release

Then go to the downloads page for that specific release. See:
(you mentioned R28.1 earlier)

Within that it will have tools for download. Find " * GCC 4.8.5 Tool Chain for 64-bit BSP". You’ll need to unpack that in an empty destination location, e.g., from “/usr/local/crosstool” could be created, and then unpacked from there with sudo.

I created the dir ‘/usr/local/crosstool’ and put the extract gcc-4.8.5 there.

Now I’ve this:

What I need to do now? I’m really lost with a lot of information. If you can help me step by step, I will be happy :)

It is easier to use command line, and then you can copy and paste instead of images. So for example, if you do this, what do you see?

cd /usr/local/crosstool/install
find . -type d maxdepth 2

Eventually we’ll find a “bin/” subdirectory, but it might require more unpack first.

Hi @linuxdev, so now I’ve this:

Do you have an email for that we can talk more faster?

It is usually better to post on forums since everyone can find the information for future use.

It should be “-maxdepth 2” instead of “maxdepth 2”. However, you found what you need. There is a “bin/” subdirectory, and the content of that will tell you the prefix used in “CROSS_COMPILE”.

If you cd to “/usr/local/crosstool/install/bin”, and run the command “ls”, what do you see? Typing “pwd” from there would show:

One of the files you will find in that directory will be named after architecture, then end with “gcc”. This is the cross gcc. If you look at the “prefix” of the name given for the cross gcc, e.g., perhaps it is “aarch64-linux-gnu-” (adjust for what it really is), then you would do this before building software:
export CROSS_COMPILE=/usr/local/crosstool/install/bin/aarch64-linux-gnu-

After that your CROSS_COMPILE would use the correct cross tool. There won’t be a separate install via “apt” unless you have a different tool (perhaps a different brand or release version). The content of “/usr/local/crosstool/install/bin” is in fact a set of tools for building the TX1’s architecture while running from the PC.

Hi @linuxdev, I followed your steps, and I got that:

Which is the best?
- export CROSS_COMPILE=/usr/local/crosstool/install/bin/aarch64-unknown-linux-gnu
- export CROSS_COMPILE=/usr/local/crosstool/install/bin/aarch64-unknown-linux-gnu-gcc

And after that, what I need to do?

You will:

export CROSS_COMPILE=/usr/local/crosstool/install/bin/gnu-aarch64-unknown-linux-gnu-

Note that the trailing hyphen (“-”) is important. Thus, when the compiler wants “gcc” it will prepend the CROSS_COMPILE and find that exact “gnu-aarch64-unknown-linux-gnu-gcc”.

Or, if it wanted “ld” or “ar”, then that prefix would find the right one.

Then just follow the docs for cross compile. There is a section under the R28.1 docs for “kernel customization” which lists this. My earlier note in this thread should be sufficient if you’ve used that export of CROSS_COMPILE.

Just be careful to not use flash for installing the actual file. For a module you just need the copy of that module, but I still recommend building the Image target first as a test to see if all is well.

unfortunately that still didn’t work…

What you show as done so far is correct. I don’t know in R28.1 what the correct defconfig is, but in the past specific defconfig’s were used for different SoCs. Nowadays mostly it is just “tegra_defconfig” rather than a specific “tegra21_defconfig”, but I would think that if the docs in R28.1 said to use this, then it is probably correct (R28.1 is old enough that the “tegra21_defconfig” is probably correct). Did you run that command from the top of the kernel source code? Most people would not unpack kernel source in “/home”, and if you are in the wrong directory at the start, then this would possibly be an issue (although I suspect it would just say “no Makefile found”).

Also, did you download this from the R28.1 kernel source URL? Or was this from another URL? Or from git?

i don’t know where to find the top of the kernel directory. I executed in /home.

I downloaded it which was in the Linux_for_Tegra documentation, you can see it here below:

What is the next step?

Typing the command ‘make’ I had this problem:

Please, help me step by step. I’m really begginer in this world.
If it’s possible, send me your e-mail for we talk more faster, and after I can post the resolution here.