Does Nvidia have plans to ship future Orin Nano dev kits with the new QSPI bootloaders to avoid the installation problems many customers are having? When I purchased the expensive Orin Nano, it was not clear that a separate dedicated Ubuntu machine was also needed. This was not an issue with the many Jetson Nano boards I’ve obtained and setup with the SD card image method with no issues.
2 Likes
I can’t answer, but I wanted to add some trivia related to this.
SD card models do indeed have the boot content in QSPI, but it isn’t limited to that. Like the eMMC models, there is also no BIOS. The initial setup of rails and clocks which a BIOS would perform is essentially its own bare metal micro operating system, and occurs before the boot chain ever starts. Neither eMMC nor SD card models have a BIOS, and both have all of this in software.
SD card models are for dev kits, and they come with content flashed on them already (within the QSPI). However, it is quite common that the existing content is out of date, and cannot boot more recent SD cards, and so those too much get the equivalent of the BIOS and boot chain flashed via another Linux host PC. That content works for a range of SD card releases, but it isn’t infinite (and definitely differs between major releases). For that you could flash the QSPI with that external Linux host PC. For eMMC models it is still flashing that content, although it might be in eMMC instead of QSPI (there are some “pointer-like” settings naming the boot device which would be in the eMMC model’s QSPI; eMMC has QSPI, it just isn’t used exactly the same way as an SD card dev kit model).
If you don’t need to flash any SD card model dev kit, it is because you got lucky about the release version. With an eMMC model there isn’t any “getting lucky” since you are flashing via host PC anyway to get the rootfs (and SD card models have rootfs on SD, the rest is “elsewhere”).
One SD card model issue which guarantees needing to flash is normally going from one major release to another, e.g., from L4T R35.x to L4T R36.x.
The shorter answer is that Jetsons are custom USB devices when in recovery mode, and they need another computer with the driver to the custom USB device. Jetsons do not have a BIOS, so this is necessary.
If you were to put a real hardware BIOS on this, then you would have more components, using more power, more physical space, and more cost. It would also become possible to “brick” a Jetson. A lot of people think that when a computer can’t boot, that it is “bricked”, but this is completely incorrect. Being bricked implies no software method exists to turn the Jetson into anything other than a paper weight or boat anchor. You can’t normally brick a Jetson via flash since it is just a custom USB device, but adding that BIOS would also mean true bricking is possible.
It’s clear that the Orin Nano boot content does not reside in the SD card but rather somewhere on the developer kit. And the only way to update the bootloader is through the SDK Manager.
I purchased a cheap Ubuntu 20.04 mini pc with 8gb of RAM (via amazon for $99) and successfully installed SDK Manager 2.0.0. I’m ready to upgrade the Orin Nano bootloader.
Question: is it possible to update the Orin Nano dev kit bootloader WITHOUT the SD card installed? I want to have the option later of swapping-in either an SD card image of Jetpack 6.0 DP or Jetpack 5.12. Also, is Jetpack 5.12 compatible with the updated bootloaders?
If you purchased it for $99, then it means it is a Jetson Nano, a more compact form of the Jetson TX1. The Jetson Orin Nano is many generations newer and more powerful. As a result, the compatible software for the two will be entirely different. An additional complication is that if the carrier board is not an electrical layout match to the developer’s kit carrier board, then the device tree will differ, and the manufacturer of that carrier board would have to provide either the flash software, or else a patch to the NVIDIA flash software (or there is actually a third possibility, that the manufacturer will state that it is an exact match and thus you can use the NVIDIA flash software).
The Orin uses only JetPack 5.x or newer (which flashes L4T R35.x or newer). The older Nano (TX1) uses only L4T R32.x or earlier (L4T is what gets flashed, JetPack 4.x works with R32.x or earlier and is the flash front end software).
Ubuntu 20.04 is not compatible with the older Nano TX1 (L4T R32.x is Ubuntu 18.04). Make sure this is or is not an Orin; the price suggests this is not Orin.
My new Ubuntu mini pc is not a Jetson Nano. It’s a Wo-We machine from Amazon. It has 8gb of RAM and a small but sufficient 128gb SSD.
Ubuntu version from the Wo-We terminal is as follows:
:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
And the sdkmanager version from the terminal:
:~$ sdkmanager --ver
2.0.0.11405
As I said, I’m ready to update the Orin Nano bootloader with the sdkmanger. Question: is it possible to flash the updated bootloader WITHOUT the SD card installed? I want to have the option later of swapping-in either an SD card image of Jetpack 6.0 DP or Jetpack 5.12.
Also, is Jetpack 5.12 compatible with the updated bootloader?
1 Like
The We-Wo itself shouldn’t change anything about flash so long as it has enough disk space. 128 GB might be enough.
To answer though will require knowing is this the NVIDIA developer’s kit which has the SD card slot on the module? Or is this an eMMC model of module on a third party carrier board?
If this is an SD-card-only developer’s kit, then QSPI is normally flashed without flashing the SD card. Often people do this, and then run one of the prebuilt SD card images. As far as this being “bootloader only”, that’s kind of a loaded question with this particular hardware since Jetsons don’t have a BIOS. Flashing QSPI is essentially both a bootloader and BIOS flash, and it sets up a pointer to the actual starting boot media, but you should be able to flash without the SD card. You might want to flash on command line.
When you’ve installed sdkmanager you will find you have a directory named after the particular version:
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/
There are several kinds of command line flash there, or you can also uncheck some of the items in the JetPack GUI and flash with that. For command line you’d name the target hardware. Within “Linux_for_Tegra/” check these files:
ls -l *.conf
If you remove the “.conf” file name extension, then those are the targets. Each target is comprised of content for the module, and other content for the carrier board. The ones with a more readable name starting with “jetson-” are just symbolic links (aliases) for the hard files which are named after module model number and carrier board model number. If you used a third party manufacturer’s carrier board, then they would most likely provide a new device tree and carrier board content along with a modified .conf file. Note some of those files are named with QSPI, and that is the non-rootfs content for an SD card model (eMMC models change that information).
Note: One QSPI release is compatible with a large range of rootfs content. That rootfs must be from the same major release as the QSPI release. Sometimes a later rootfs release will need QSPI updated, but they will be the same major release. You cannot mix a JetPack 5 and 6 QSPI and rootfs, nor could you mix a JetPack 4 and 5 QSPI and rootfs. In some cases an early QSPI release of a particular major release will be incompatible with the rootfs of a later release within that major version.
I guess not. Just use a different card.
Yes, NVidia should make this more clear. But this will not change due to the underlying architecture of the Jetson modules. Plus: production modules don’t have uSD cards at all. Orin NX is only available as production module.
Second: The primary target for these boards are companies. You seem to be a mere tinkerer. For companies the Linux PC requirement is a non-issue - the salaries are the expensive part.
Third: The Jetson modules only exist because there are SOCs that can be repurposed from the automotive world. Automotive makes the money that allow these SOCs to be build. And many features like secure boot originate from the automotive world. Just have this in mind.
Background info:
- GOAL: Flash Orin Nano Dev Kit with updated QSPI bootloader compatible with Jetpack 6.0 DP, and only Flash with simple command line approach. Separately, use preloaded SD card with Jetpack 6.0 DP installed via simple and robust SD Card Image approach (already done with Win10 PC).
- Flash on Ubuntu 20.04.6 machine: Wo-We mini-pc from Amazon
- Target device: NVIDIA Jetson Orin Nano Dev Kit from Sparkfun
Was very stuck but making progress now. Although sdkmanager 2.0.0.11405 was installed a few days ago, I could not find the Linux_for_Tegra folder. Then I learned that you have to run sdkmanager first and go through steps 1 through 4 in order to download the Orin Nano Dev Kit flash package. I did this without the Orin Nano Dev Kit connected and all the files downloaded correctly.
I exited out of sdkmanager. In a terminal, I went to the Linux_for_Tegra directory where the flash.sh script resides. If you don’t do this, the flash.sh will not be seen. For my system, the Linux_for_Tegra is here:
:~$ /home/ubuntu/nvidia/nvidia_sdk/JetPack_6.0_DP_Linux_DP_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
All the necessary files and scripts to perform the command line flash without the sdkmanager are in place. To check this, I ran the following flash command without the Orin Nano Dev Kit connected:
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit mmcblk0p1
The output was as follows:
#################################
#L4T BSP Information:
#R36 , REVISION: 2.0
#User release: 0.0
##################################
ECID is
Error: probing the target board failed.
Make sure the target board is connected through
USB port and is in recovery mode.
My next steps to execute the QSPI flash from the command line without the sdkmanager are as follows:
- Put the Orin Nano Nano Dev Kit in recovery mode, connect it to the ubuntu machine via a USB cable, power up the Orin Nano Dev Kit
- Check to make sure that ubuntu machine sees the Orin Nano Dev Kit
- Execute command line flash:
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit mmcblk0p1
Questions for the community:
- Is the sd card required just for the QSPI bootloader flash? @linuxdev seems to thinks so. Can others verify?
- Is there a command line script to check if the Orin Nano Dev Kit is connected? I want to do this before the flash.sh step.
lsusb should show an USB device with vendor ID 0955. This is your Jetson board in recovery mode. When not in recovery mode there is no such device.
I do not have an SD card model to experiment with, and things have changed with JP 6 DP. I am not saying that you need an SD card to flash, but I am saying that I don’t know for certain, although I suspect that with the correct command line, no SD card is needed for what you are flashing. Someone with an Orin Nano would have to verify.
I do want to suggest your memory location target is wrong. mmcblk0p1 is for eMMC, and mmcblk1p1 is for SD card models. This is the pointer I may have mentioned earlier, that when you flash the boot content you are also setting a pointer to a boot device. The SD card is mmcblk1p1.
One complication is that if you wish to aim at an external device for the Jetson to use as rootfs, then you would typically flash with one of the other scripts:
tools/kernel_flash/l4t_initrd_flash.sh
(this has a README in that directory as well)
If you are just using the SD card on an SD card model, then you don’t need initrd flash unless you are doing something special. Same for eMMC models. When you do that the rootfs is different, and so is the boot content because it is using an initrd to point at the boot device instead of directly from the bootloader.
I believe you don’t need initrd flash, but it is worth mentioning what this is if you don’t know about the initial ramdisk boot method. When a bootloader runs, and it is about to transfer control to the next operating system (the Linux kernel) it needs to read that kernel into memory, and usually configuration information (such as extlinux.conf). Linux uses these on an ext4 filesystem in most cases. Sometimes though it uses a different filesystem type, or there might be some special requirement that has to be running, e.g., it could be XFS filesystem type, or it could be RAID and need a volume manager. The bootloader could no longer read this because it only understands ext4, so you have these possibilities:
- Rebuild the boot software to understand the extra boot requirements, e.g., port XFS or volume manager to the boot software running bare metal (very difficult).
- Use another filesystem type which is understood already, and put the edits in that other filesystem type so Linux is the one that must understand this instead of the bootloader.
This latter approach is what an initrd accomplishes. It is just a tree structure that works like a simplified filesystem inside the bootloader, and pretty much every o/s can work with this, and the bootloader can work with this. You put the kernel there, without any modifications, but add a loadable kernel module for the other content, e.g., an XFS or volume manager module. Since it is in RAM, and using a simple “cpio archive”, it can load the module there as the Linux kernel loads. Problem solved, you are now running Linux and the bootloader doesn’t need to care. Then a pivot root or similar is performed by the Linux kernel to make the new rootfs the actual disk device. When you initrd flash you are putting that intermediary RAM filesystem in to load external devices and filesystem types that the bootloader does not understand, then the RAM is released and simply goes away. Space magic!
In the case of an initrd flash you might find new requirements about whether or not the memory device needs to be present. I can’t say for certain, I don’t have external devices to experiment with.
I will suggest that you just look at the files you see from Linux_for_Tegra/ with:
ls -l jetson*.conf
Find the one that describes your SD card model, and try flashing that with no SD card present, e.g., maybe you see “jetson-orin-nano-qspi.conf”, then make the target that name without the “.conf” suffix, and pick target SD card via “mmcblk1p1” (I will suggest a full flash of QSPI and not limiting to bootloader as a test):
sudo ./flash.sh -r jetson-orin-nano-qspi mmcblk1p1
The “-r” is so it won’t generate a rootfs image. Remember that generating the image or not generating that image is all that does, and it is not used to say to actually flash or not flash some component.
If the above works with no SD card, you’re all set because bootloader or subtargets of the QSPI will also be on QSPI. I recommend you log every command line flash that might be useful to see details of what is being done via appending " 2>&1 | tee log_flash.txt" to the end of it. Example:
sudo ./flash.sh -r jetson-orin-nano-qspi mmcblk1p1 2>&1 | tee log_flash.txt
(note that mmcblk1p1 is a pointer to a target, and it is not necessarily something that gets flashed)
@linuxdev, thanks for catching the pointer argument intended for SD cards. I will not be using a NVMe or other boot device, so I don’t think I need the “l4t_initrd_flash.sh” script. This is the corrected command line for flashing the QSPI bootloader for SD cards:
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit mmcblk1p1
Separately, I have been having issues with my ubunti mini PC by Wo-We. The screen pixelates and seizes into a green screen after switching on the machine. It has nothing to do with sdkmanager. Other unfortunate users have experienced this. It started happening after running “sudo apt upgrade”. So I will return this device, and start again with ubuntu 22.04 on my Win 10 PC with WSL2.
I suggest you flash the QSPI target, not jetson-orin-nano-devkit. Use -r to avoid generating an image. Don’t tell it to just flash bootloader, although you could; note that all of the content in QSPI is the same every flash, and this would include the bootloader you’ve put in place (if you’ve put it in the right place). I think (but am not certain) that leaving the SD card out would not be an issue (and it would guarantee an experiment that does not modify the SD card). Regardless of what command line flash you make, I suggest logging it. Example:
sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit mmcblk1p1 2>&1 | tee flash_bootloader.txt
Then you can see if the file you put in place was actually used.
Do be sure your bootloader fits into the space assigned to it in the XML file.
Beware that WSL2 probably has its own issues. If you get it configured correctly, then it will probably work, but it will require a learning curve to get the USB to always go to the VM and not fail on disconnect/reconnect.
@xplanescientist:
This is very true. ANY virtual environment is a recipe for failure in this case unless you have ample experience on Windows AND Linux AND the virtualisation environment and know exactly what you are doing. Been there, done it.
Maybe you can add an extra SSD to your existing Windows PC and setup dualboot, or shink the Windows partition in order to make room for a Linux partition.
1 Like
That is exactly what I would also recommend: Add a second disk to the PC and dual boot. Since it is Orin I would recommend Ubuntu 22.04 (I personally prefer KDE, so I would use KUbuntu). You could use Ubuntu 20.04 if you might also be working with JetPack 5 (L4T R35.x) instead of JetPack 6.
1 Like
Since “jetson-orin-nano-devkit.conf” points to “p3768-0000-p3767-0000-a0.conf”, all the files with the same cryptic root name are:
p3768-0000-p3767-0000-a0-maxn.conf*
p3768-0000-p3767-0000-a0-nvme.conf*
p3768-0000-p3767-0000-a0-qspi.conf*
p3768-0000-p3767-0000-a0.conf*
So the QSPI target you must be referring to is:
p3768-0000-p3767-0000-a0-qspi.conf*
To clarify, the QSPI bootloader flash command you are suggesting is this?
sudo ./flash.sh --no-systemimg -c -r bootloader/generic/cfg/flash_t234_qspi.xml p3768-0000-p3767-0000-a0-qspi mmcblk1p1 2>&1 | tee flash_bootloader.txt
Hopefully the WSL2 flash approach will work as it has for some in this forum. All the flash related files seem to be present for the command line flash. I’m not using the sdkmanager so there’s no need to “change the linux kernel” as Nvidia has suggested - I certainly don’t want to go there. As long as the Orin Nano Dev Kit shows up as an USB device with vendor ID 0955, I should be good to go. However, QSPI flashing without the SD card is probably an untried event, so we’ll see how it goes.
If that fails, I’m eyeing a new dedicated ubuntu machine by Cybergeek with 16gb of RAM for $160 and keep linux completely separate from my Win10 PC. Although I have to say WSL2 works really well for my purposes in science and engineering. The days of dealing with cygwin and all the idiosyncrasies and compatibility issues are gone.
For what it’s worth, I highly recommend Nvidia include the updated QSPI bootloaders in new Orin Nano Dev Kits (or modules if that is where it resides), and/or simplify the flashing process (command line approach) to increase your customer base. The $499 price is locking many out. Requiring a separate ubuntu machine and the added cost and time will lock more out, and inundate the forum with issues related to boot.
I don’t have a specific recommendation for the command since I use an eMMC model, but typically what someone would do is just an ordinary flash with -r, and then when naming the target with QSPI in its name, it should do the right thing. That would flash all non-rootfs content (which is what QSPI has). I’m not sure if just flashing a bootloader would work, although the odds of success go up if your new bootloader is small enough to fit into the existing space. Just don’t put the SD card in while testing, and if it is required, then use an SD card which is merely a clone of the first. Cloning SD cards as a whole (or partitions) is trivial in Linux. If you want to clone your SD card then just ask for methods on Linux. For Windows, although I’ve not used it, probably Balena Etcher would do this.
Note that the real flash software is the “driver package” (the Jetson is a custom USB device when in recovery mode, and the “driver package” is a custom USB driver; the “flash.sh” script is part of the driver package, and in fact all of “Linux_for_Tegra/” that is not in “rootfs/” is driver package). JetPack is just a GUI frontend to the driver package, and SDK Manager is a network layer on top of JetPack. The only thing JetPack adds, beyond convenience, is that once flash completes and the Jetson fully boots, it can also add compatible optional software, e.g., CUDA. When flashing with JetPack it will download the proper software, unpack it, and set it up for flash; then it calls the driver package for actual flash.
Make no mistake though, the PC kernel does matter. Features such as loopback require that kernel driver/feature be enabled. Similar for the ext4 filesystem. The actual flash software generates the rootfs image using loopback and other kernel features, and if your WSL2 kernel does not have those, then it will fail. If you were to use an NTFS partition for the flash software, then the flash would succeed, but the result would not function. There are all kinds of little details which might make using any VM difficult.
Regarding that last paragraph, not all flash operations have the same requirements. For example, if you don’t generate a rootfs partition, and only use the preexisting signed binary content (meaning non-rootfs content; this is part of the flash content, and isn’t generated during flash), then you probably won’t see any error for a missing loopback function, but you’d still need ext4 (ext4 is just an example, and probably isn’t an issue, but there may be other features required).
If you do get an inexpensive PC like what you’ve linked to work I’m sure other people would like to hear about it also.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.