Hi,
Would appriciate yur help with this out of the box frustrating issue:
We ordered two new Jetsons Nano 4GB, with the Waveshare dev kit.
They arrived intact, I powered them on, updated the operating system(apt update), and it asked for a reboot.
Since the reboot, neither will boot and they’re stuck on the NVIDIA BOOT screen.
Power led is red on both.
Right now I have two bricks in my office instead of 2 new Jetsons…
feel free to ask for more info as needed.
It’s really difficult to actually brick a Jetson. That usually means the BIOS is failing, but Jetsons don’t have a BIOS (they have the equivalent in software, and this gets updates in a flash via becoming a custom USB device). The complication is that unless Waveshare says this is supposed to use NVIDIA’s flash software (which is used for developer kits), then you would have to use Waveshare’s flash content to perform a flash. When a third party carrier board is involved the device tree will usually differ, and the third party carrier board manufacturer will do one of the following:
Tell the end user it is ok to use NVIDIA’s dev kit flash software (in which case their carrier board is an exact electrical layout match to NVIDIA’s).
Provide a patch to NVIDIA’s flash software (usually in the form of a device tree firmware patch).
Or provide a rebranded version of NVIDIA’s flash software (differing mostly in device tree).
I don’t know what the serial console setup is like on Waveshare, but if you have a serial console, then most likely the system is at least partially booting and it could tell you where the failure is at (it is common that only the GUI fails, but otherwise the system is fully booted). On the other hand, if the update replaced some part of Waveshare’s device tree with NVIDIA’s, then that part of the system would fail (and this often includes the video output).
If this were a developer’s kit, then you could refer to this for serial console questions, but if you can find Waveshare’s information on serial console, then that would be far better:
Keep in mind while working on this that flashing again would pretty much get past this, but (A) it would be nice to know what went wrong in the first place, and (B) it will be Waveshare’s software which is needed for any flash if serial console does not reveal the issue. Also, if you do get serial console up, and if the system is running (there is a significantly high chance that the system is running), then you could examine the output from “dmesg”. If you go to use Waveshare’s tech support, then they will likely want the “dmesg” output and/or serial console information; otherwise they’ll start by having you flash.
Thank you for the quick response!
By brick i ment not booting, its stuck on the first NVIDIA logo screen, trying to get more info on boot using your suggestions,
2 questions:
If I try flashing and updating the ubuntu again after, is there a risk I’ll end up with the same issue?
On which 3rd party dev-kit makers i can get NVIDIA flash tools to work?
Brick has the meaning that the BIOS or some part of the system has failed which can only be repaired by unsoldering the memory and fixing in an external memory flash tool.
Without the serial console log there really isn’t much which can be predicted.
The maker of your carrier board is where you would get the flash tools. Which brand is it, or what company did you buy it from? If it is a dev kit, then NVIDIA tools would work. That carrier board’s brand is the key since this is what determines required modifications to the device tree.
I use dev kit from Waveshare.
Tried to work with the official nvidia image but it didnt worked,
trying with the Waveshare image now, hope it will fix it.
My concern is that after re-flashing the image and running apt upgrade it will occur again.
Waveshare would have a support URL or documentation on the flash. Without this the wrong packages would be used. I can’t say for sure that this will fix the issue, but if the update used the NVIDIA dev kit device tree instead of Waveshare’s, then this would cause such a failure. I will recommend that you flash and test once.
Do keep in mind that if you have a Jetson which has some content on it you want to save, then you can first clone the rootfs partition (this is the actual operating system partition). This differs from the backup/restore script. Clone provides both a “raw” clone (a bit-for-bit exact duplicate) of the o/s partition, and a “sparse” clone (same as raw, but does not clone empty disk space; as disk space fills, sparse size approaches the same size as the raw image). The sparse image can only be used for rootfs restore, but the raw image can be loopback mounted, examined, modified, or used for restore. You wouldn’t necessarily just restore after a failed upgrade, but you could in fact adjust what gets flashed onto your new Jetson by use of something like rsync of selected directories (e.g., “/home” and the users and groups) and you would not lose the valuable content.
What is your update command? You could log this also during the update to remotely store the log on the Linux host PC. This is particularly easy if you have serial console running because you can perform the update from the serial console, and use the serial console program to log the entire session.
Alternatively, there are ways to copy whatever you see during an update and send it over ssh to another computer to save it as a plain text file. Serial console is trivial to use though, and serial console survives almost anything you can do to the Jetson to break it during an update. Serial console also further allows saving the boot log right after the update so we can see what went wrong. It is hard to overemphasize how much use that serial console is for debugging and development.
Hopefully though, if the flash uses Waveshare’s software, then the packaging will be set up such that the update won’t be a problem.
If your “flashing waveshare’s image” only means you replace the sdcard, then it does not really flash the board.
Putting the board into recovery mode and flash it from another x86 host is needed. But still need Waveshare to provide the package for x86 host to use.
Thanks @WayneWWW for that, its makes so much sense, after i tried plenty of sd images without sucess…
trying to get more details of the board flashing process on waveshare
Got answer with working solution from Waveshare, Just follow instructions on image, tested and working.
Hope this will help other developers experiencing same issue,