Hello, I am attempting to flash a custom NVIDIA Jetson Xavier NX"201F" to perform a clean install of the Linux version on the machine. I cannot sign on to the current OS because it automatically boots into a browser sales screen (it is a machine used for display/sensors on digital screens)
I received a custom BSP with instructions from whom I believe to be the vendor but I am getting the following error:
“Error: probing the target board failed. Make sure the target board is connected through USB port and is in recovery mode.”
There is likely something different for the carrier board since it is likely not a developer’s kit. Firmware changes when going from one carrier board design to another.
If we are to treat this as a manual install of flash software on a host PC, then these notes apply:
The “driver package” is the actual flash software. When unpacked this creates almost everything in the “Linux_for_Tegra/” subdirectory when it unpacks. This content would never be unpacked as root (don’t use sudo). It does need to be on an ext4 filesystem type.
After unpacking and creating “Linux_for_Tegra/” there will be a nearly empty (perhaps there is a README) subdirectory “Linux_for_Tegra/rootfs/”. Unpacking the sample root filesystem (or whatever might be provided) into this does require sudo.
Once this is all unpacked, then in the “Linux_for_Tegra/” directory you would run this with sudo: sudo ./apply_binaries.sh
(this only needs to happen once, it applies NVIDIA content into the rootfs)
At this point any flash procedure can be performed. You’d need to make sure the Jetson is in recovery mode and correct USB connection exists. I am assuming it is all custom at this point because default software for a dev kit would not use the install.sh, but would instead use other commands.
Mostly you will get variations of this, but flashing once should have created this file: Linux_for_Tegra/bootloader/system.img.raw
(which creates the system.img; the raw version is more useful, but slow to flash, and so the sparse version is added; we will only look at the raw version)
If you can loopback mount the system.img.raw, then you can examine it and find information on the host PC. If you created directory “/mnt/jetson”, then you could mount it like this if you are at “Linux_for_Tegra/bootloader/”: sudo mount -o loop ./system.img.raw /mnt/jetson
(or you could unmount with "sudo umount /mnt/jetson)
When mounted you should be able to cd to “/mnt/jetson” and run “ls -aF” and see everything. Because your rootfs content is custom, probably the first thing you’d want to do is find out what release this is based on. cd to “/mnt/jetson/etc” and “cat nv_tegra_release” and “cat nv_boot_control.conf” and post that content. It might also be interesting to see the content of the “etc/issue” file.
Beware though that there isn’t much help for customized systems like this because so much would have changed in both software and firmware. What I posted above should still be valid even for a custom installation, but there might not be more anyone can say. I suppose it might be of interest to see what is in the “install.sh” script (you could attach it to the thread; serial console boot logs are normally useful, but I’ll wait since this is not a dev kit).
nv_tegra_release: # R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 1 19:57:35 UTC 2023
I’ve attached image of new error. I have the full BSP package from the vendor but it seems secure boot is enabled and I’m not sure where to get the keys from.
The vendor of this board (AVerMedia) no longer sells it. They sent me the BSP via sharepoint but I’m not sure if they have the keys. This a board from Cooler Screens but they are going under and likely unwilling to provide support. All these custom boards from them will likely be bricked since there’s no way of reflashing them
All of the non-rootfs partitions are signed with a key for eMMC models. The default is a NULL key for dev kits and new modules, and for those, flash is not a problem (the default flash key is NULL). The rootfs itself is not coded with any kind of key. The flash content which creates the equivalent of a BIOS and the rest of the boot chain has to be compatible with the rootfs release. Since that content does not have a key, and since apparently the rootfs is not from that exact non-rootfs version, it fails. The key means there is no way to flash the non-rootfs content and boot chain in any way (keys must match to flash that).
On the other hand, if you were to purchase a commercial module and put a new one in without burning the fuses, then that software you have would “likely” be able to flash it. You’d be starting completely over. The only reason this might be useful is if you like the carrier board and any chassis it is mounted in, but you are right that the original Xavier NX hardware is no longer useful without keys from whoever gave it to you.
Incidentally, the only device tree and kernel and some other things which are allowed are from the partition; this is a side-effect of security key fuses being burned.
