I assume the device would install by itself, if not in force recovery mode, always.
so how to make the device install not in forced recovery mode (get the device out of the force recovery mode)?
also display is not showing anything, as in forced recovery mode should be. but the device should not be in frc.
edit: I assume a qspi rom flash went wrong, and it is always in the frc mode.
so I’m attempting to do the manual over usb cable connection re-flash of the device.
“Error: probing the target board failed. Make sure the target board is connected through USB port and is in recovery mode.”
lsusb output: 0955:7f21 NVIDIA Corp. APX. as by documentation, the presence of USB device indicates recovery mode. so either the documentation is not correct or the flash.sh has a bug.
Forced recovery mode is only from either power up or power reset while the recovery button is held down (it is like the shift key on the keyboard for capital letters, except it applies to power…you don’t need to keep holding it down). Boot might be failing, but if you didn’t put it in forced recovery, it isn’t in recovery mode and simply not booting as expected. Sometimes it is even booting, but the GUI doesn’t work right, and it only appears to not be booting. When you get to that point, you always want a serial console boot log (which incidentally offers a second login method immune to network and local monitor issues). See: https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
The part of “Error: probing the target board failed. Make sure the target board is connected through USB port and is in recovery mode.” would truly be a flash error. If part of the flash worked, but you saw this, then I would expect boot failure until flash succeeds. I will add a special note relative to this: Any time you require recovery mode, expect to start recovery mode again (fresh start) before performing two operations in a row. You cannot attempt to flash twice without a new recovery mode between flashes. You cannot attempt to clone twice in a row without a new recovery mode between attempts. Flash itself will automatically reboot if it succeeds, and you will no longer be in recovery mode; the stage where it offers to install optional software is after the automatic first boot account setup, and runs over ssh (not recovery mode).
It appears you are using a VM. The error you are experiencing means your VM is not configured to keep the USB device. During a flash the USB will disconnect and reconnect, and unless you configured your VM correctly, it means the USB is lost. That is something the VM manufacturer would have to answer how to configure correctly, the Jetson has no control over this. The flash software itself has no knowledge or control over that situation (part of the purpose of a VM is that the software running in it is secure since that software has no knowledge, nor control, over the VM). The officially supported documents will suggest Ubuntu 18 for a Nano flash, and a VM is not Ubuntu if not configured correctly (which is something not supported by NVIDIA).
Some people do get VMs to work, but they either get lucky on configuration, or else find the correct configuration. The official docs would suggest perhaps dual booting with Ubuntu rather than using a VM. Do note that if you have a VM, then the filesystem type must be ext4; if you use NTFS (or any non-Linux filesystem type) the flash will only appear to succeed.
I remember flashing (and bricking) the jetson nano 2g device from the desktop of the jetson nano, with the OS firmware, after that it did not work. the flash tool from the linux driver package does not flash anything, it fails right from the start. I shorted bot the “heat sink side” FRC and J40 FRC. no recovery mode allegedly, but from the USB device presence indicates FRC mode, but still the flash utility does not work. I set the configuration name by hand on the command line, to the jetson nano 2g dev kit, so no trouble there. flash twice? it did not even flash once, the referred flashing is from the desktop of the device while it was working. serial log? its bricked to the point that nothing such would not be displayed.
so I have a bricked device. the usb flash must reset the qspi firmware, or it will not work. if the usb flashing is also bricked then sad times.
no I’m using a rpi4 linux in pure metal linux raspian (debian). where did you come to this VM conclusion. I doubt anything you say is correct. even if you are a “forced top contributor” I doubt all you say is legit and working.
Please be aware that there won’t be any person that can 100% say what is going on by just reading your comment.
The information you provided is not enough to tell what is going on.
Please at least share the error log you saw from host to flash the jetson.
VM is the most cases that cause problem that is why linuxdev thinks it could be due to VM.
Also, please be aware that the flash tool can only run on x86_64 ubuntu host.
its rpi4 64-bit version of the raspbian. the tool starts/seem to run properly. I tried that before on 32-bit raspbian on rpi zero on which it did not work.
thats what I already quoted is most of the error log. there is something above it before the error.
L4T BSP Information:
R32 , Revision 7.1
Error: [insert the quoted part here]
would the raspbian recent 64-bit be fully compatible, as a debian derivative, similar to the ubuntu versions?
anyways I would need to either run the suggested ubuntu versions on my computer (x86_64 desktop) or getting the UART output log.
on the host flashing device, rpi4, the error line is exactly as said before (nothing else):
“Error: probing the target board failed. Make sure the target board is connected through USB port and is in recovery mode.”
imho thats very narrow linux target. but you of course do you.
so you also say that you cant use another jetson device to do the flashing.
even if the target is an arm system, the jetson systems.
I need to install it on a x86_64 computer then it seems.
the quick start flash guide only says:
The host computer must run Ubuntu 16.04 LTS or 18.04 LTS,
so I assumed any linux system, arm would do.
well, the issue (qspi firmware bricking) is resolved now.
resolution: using ubuntu 23.10 on x86_64 pc, flashing the most recent R32 7.4 L4T package, was completed. also it was always in the forced recovery mode after firmware write failure from the jetson nano desktop firmware update tool.
there should be an update to the jetson nano flash install quick start guide, to make it specific that it needs a x86_64 ubuntu linux, as the host.
none of the critical web pages (quick start guide and download page) mentions its for x86_64 only. it should be mentioned in every place mentioning requirements and compatibility, for the platform its for.
FYI, the actual flash part of the program is a compiled binary for desktop PC architecture on Linux. Much of the rest of the program simply uses Linux tools, e.g., to create an ext4 filesystem. Some of the software is actually designed to run through QEMU, so it is a bit more complicated than just compiling the desktop PC architecture part to run on 64-bit ARM. On the other hand, you are right, a lot of people would like to be able to run from 64-bit ARM. The part you’re probably not aware of is that the flash software also works with some other hardware which is not Jetson hardware, and although I’m just guessing, I think that has a lot to do with not providing a version running on ARM. I am not denying that an ARM-based host would be useful, but if you were buying a computer game or a compiler tool, then you would usually not expect it to arrive with both a desktop PC version, but also an ARM version.
Something I do want to mention though is that the term “bricking” is used wrong by most people in the forum. Any system which can be flashed is not bricked, and a failed system which simply needs to be flashed correctly should not be referred to as bricked. The term itself comes from boards which have a BIOS, and Jetsons don’t have a BIOS. A BIOS is essentially a very low level operating system that brings up power rails and clocks in the correct sequence. On a PC motherboard, if there is not a backup BIOS, and if that BIOS is corrupted, then the only way to “fix” that PC is to literally unsolder the memory used to boot the BIOS, program it, and solder it back on. Such a failure is functional only as a “brick” because only the factory has the content to fix that memory, and most likely the act of unsoldering and resoldering the BIOS memory would destroy the board.
Jetsons have the equivalent of a BIOS only in software which is stored either in QSPI memory, or for eMMC models, perhaps in eMMC partitions. Flash itself is pretty much incapable of bricking any Jetson. There are some things people can do on the i2c bus to ruin the ability to be flashed, but you’d have to actually try to do that.
well, until it got fixed, re-flashed, it was effectively bricked for me for a long time. stumbling into the re-flashing solution took a long time, as the path to it was not especially clear. and I did not get any clear solution from the forums before this, from other related forum questions in the same recovery mode topic.
for a long time I did not know that you have to re-flash it, using a bit complex flashing tools, after it got a failed firmware desktop tools flash failure. so two road blocks: recovery mode confirmation and using the flash tool, which ended up being more complex than expected, to get the tool even doing what it is supposed to do, the host system parameters etc.
I’m glad its no longer in the inoperable state. no matter the terminology, as I’m not tied to any established nomenclature.