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):
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)