This will bypass the stuck in serial console and let it boot up. We can check the desktop issue after this one gets done.
If you don’t understand what we are doing, then it is the explanation:
In the first boot after each fresh reflash, it requires user to configure the user account and password to proceed the boot up, if you don’t do it, then the boot will get stuck.
For now, we just bypass this configuration and check why the desktop GUI cannot show up on your device.
My question is how do I do this if I am unable to boot into my device ? Do I take the SD card out and put it into my local machine ? If I do that I can’t find the “BSP” folder.
It might be useful to know that SD card dev kits (which have the SD card slot directly on the module) have the operating system on the SD card, but the equivalent of a BIOS plus boot content is in QSPI memory. That memory is directly on the module, and it is the JetPack/SDK Manager which updates QSPI. If that content is not correct (and compatible with the SD card content), then it won’t work correctly. So you need to flash the module itself.
BSP is just “board support package”. Nothing is actually downloaded with that name. Some terminology you might find useful:
L4T is “Linux for Tegra”, and is what actually gets flashed. This is Ubuntu plus NVIDIA drivers (mostly it is Ubuntu in operation, but needs NVIDIA instructions to install).
JetPack/SDK Manager is a GUI front end to flash software, and runs on a separate host PC.
Because of SDK Manager (SDKM is a smart network layer on top of JetPack) can download and install all flash software to the host PC you don’t normally need to worry about anything other than having enough disk space.
JetPack/SDKM will have a subdirectory in the actual flash location of “Linux_for_Tegra/”. This is where the real flash software is at. Somewhere under “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/” if you’ve run JetPack and told it to install anything.
The real flash software (not the GUI front end) is known as the “driver package”. You can see this on the web page for downloading JetPack for your specific release. You don’t normally need to download this manually. This is more or less what I’d call the “Board Support Package” (BSP), and is included via running JetPack.
For the sake of trivia, the rest of the BSP is the “sample root filesystem” (this populates to “Linux_for_Tegra/rootfs/” and is the actual operating system which gets flashed (there are a couple of boot related edits to this during flash). Also, the reason the “driver package” has that name is that a Jetson in recovery mode is a custom USB device needing a custom driver…the “driver package” understands a recovery mode Jetson over USB.
The L4T release is what gets flashed, and its version is tied to the JetPack/SDKM release. If you’ve picked one, then you’ve also picked the other. I suggest you use the latest L4T release compatible with the Nano (which would be an R32.x release). Go here, and the URL it leads to will be the same regardless of whether you pick this via L4T release or JetPack release:
A Nano dev kit (produced by NVIDIA, and not using a third party carrier board, and without eMMC) uses the SD card for the operating system. The Nano dev kit has a lot of other memory on the module itself (QSPI memory), and that memory contains the equivalent of what a BIOS would contain, along with boot software. You flash the Nano with JetPack/SDKM, and this can create an SD card, or you can use a pre-built SD card if it is from a release compatible with what you’ve flashed to QSPI. Nano dev kits have QSPI content when you purchase them, but there is a strong chance the QSPI content is quite old and not compatible with the SD card content if you use a recent SD card release. You should flash the Nano itself with JetPack/SDKM.
Note that successful boot normally requires a first boot account setup. You won’t be able to ssh in unless the first boot account has been completed (you’d be using that account’s name and password for the ssh). ssh is how the “optional” content is added (e.g., CUDA). If it cannot ssh, then chances are the operating system installed correctly (assuming JetPack flashed it), and that it just needs that account first. This can be done either via an HDMI monitor or via serial console (I very highly recommend getting serial console set up, it is cheap and very useful/versatile/reliable since it does not require any drivers the way HDMI does). Then again, it is possible that if the system does not boot it would also fail ssh, but most of the time it is just because first boot account setup did not complete. When flash completes, the Jetson will automatically reboot, and that is when JetPack wants the login account for ssh.