Hi all,
I’m using jetson tx2 board.I downloaded the kernel and root file system from following link:
https://developer.nvidia.com/embedded/linux-tegra
after loading the kernel to tx2 i'm getting login console.
username :nvidia and ubuntu
but i can't able to login.while login again it comes to login screen.this is the problem i'm
facing.
I extracted and compiled all files with sudo privilege only
sudo tar xvpf Tegra210_Linux_R23.2.0_armhf.tbz2
sudo tar xvpf Tegra210_Linux_R23.2.0_armhf.tbz2
sudo mount /dev/mmcblk1p1 Linux_for_Tegra/rootfs
cd Linux_for_Tegra/rootfs
sudo tar xvpf ../../Tegra_Linux_Sample-Root-Filesystem_R23.2.0_armhf.tbz2
sudo ./apply_binaries.sh
Above the steps i followed to create .DTB and image file.
Can anyone tell how to resolve this issue? and why i can't able to login?
Seems you’re trying to run an old TX1 (armhf is 32 bits) rootfs on a TX2.
Yes, R23.2 is very old. R28.1 is the current version. Unless you have a really good reason I’d go to R28.1. Back when the original 64-bit ARM came out there wasn’t much software built for aarch64…it was all armhf/arm32. User space back then used the arm32 compatibility mode…which has terrible performance. The TK1 might even be faster than a TX2 if the TX2 is in 32-bit compatibility mode. Then there is the issue that R23.2 was very new and has since had many bugs fixed.
However, even with R23.2, the apply_binaries.sh step was incorrect. What this does from the default location is to overlay the sample rootfs in the “rootfs/” directory with NVIDIA drivers. If you apply binaries and then do the recursive copy of rootfs to SD card mount point this will be sufficient. Using apply_binaries.sh after the copy won’t work unless you use the “-r PATH” option to apply_binaries.sh to name the SD card mount point (default is “./rootfs/”, “-r” overrides the default). The case of apply_binaries.sh after the copy implies apply_binaries.sh never took place where you wanted it.
Even if you did everything correct it won’t matter if you didn’t format mmcblk1p1 as ext4. If you did format this correctly, and if your host has certain ext4 options enabled by default, then the U-Boot boot loader won’t be able to see the partition. You’d have to disable those options during the format of mmcblk1p1.
To know if your system defaults to using the 64-bit extensions which are incompatible you’d check “/etc/mke2fs.conf”. If in the ext4 block’s “features” you see these, then this won’t be compatbile without extra options (similar options with “64” in them are ok…it is this specific set of options which are not ok):
metadata_csum
64bit
An example of specifically disabling those options during a mkfs.ext4 would be:
sudo mkfs.ext4 -O ^metadata_csum,^64bit /dev/mmcblk1p1
(the carrot/hat character “^” disables the option)
Hi,
Thanks for the information.And one more problem is wlan and wifi,hdmi also not working with this
one.because ,Is that problem with R23.1 old version ?
I just realized something…this is listed as a TX2, but I see t210 references (t210 is a Tegra210, which in turn is a TX1, not a TX2). Is this really a TX1? If not, then R23.x and R24.x are completely incompatible. The TX1 and TX2 can both use R28.1 if the correct driver package is used (they share a sample rootfs, but use different-but-similar driver packages). Initially a TX2 starts with R27.0.1. No TX1 can run on R27.x.
The very first TX1s which came out had a possibility of a mismatched firmware setup which could cause WiFi to fail. HDMI has been far more of an issue on earlier releases and seems much improved by the time you get to R28.1 (there is still a 4k HDMI bug, but mostly everything works). In cases where HDMI failed in the past it might have been due to a rejected mode and simply not seen in logs unless verbose mode logging is enabled.