Hello,
I took an image of the Orin NX I have. I want to transfer this image to a different Orin NX but its SSD is different. Is this possible? That is, can I copy an image taken from an SSD to a different SSD? Thanks.
If you want the same partition size, then you could use dd (which works over Ethernet). If you want different partition sizes, then I’d use rsync. However, realize that two different Jetsons, even if the same model, usually won’t “just work” from a cloned SSD. The boot content and content setting up the environment before transfer to the SSD has to also be the same, and the o/s itself is just one partition. Cloning SSDs is simple, but that is only a small part if you are creating duplicate Jetsons.
Hello @linuxdev,
Actually I couldnt understand clearly that you said ‘ However, realize that two different Jetsons, even if the same model, usually won’t “just work” from a cloned SSD. The boot content and content setting up the environment before transfer to the SSD has to also be the same, and the o/s itself is just one partition. Cloning SSDs is simple, but that is only a small part if you are creating duplicate Jetsons.’
Can you explain it with more explanation again please?
A comparison to a PC might help start the explanation. Sorry, this is going to be long, despite the short answer being more or less “boot has to reach the partition to use it”. 😅
A PC has a BIOS, and that BIOS is a self-contained operating system designed specifically just for that motherboard’s hardware and hardware layout. The latter is important because only plug-n-play hardware can self-report as to what it is. There is a lot of hardware out there which cannot be queried. The BIOS more or less hard wires knowledge (actually, it is firmware from a BIOS flash) of what clocks and power rails to bring up in which order. The ability to detect a hard drive implies that all clocks and power rails came up in the proper order, and that there is a driver for that hard drive which knows which physical address to find that controller at. There is even a program to examine what storage is at the end of that controller, and to detect partition schemes. There is the old style BIOS scheme, and also UEFI, whereby the partition schemes differ. A BIOS which does not understand UEFI cannot boot a UEFI partition. Vice versa, if a UEFI BIOS does not also enable the older “legacy” style BIOS, then UEFI could not boot an older partition scheme. There is also the idea that there is likely more than one disk controller on a PC’s motherboard, and the BIOS, whether UEFI or legacy, has to know to search them. The BIOS screen you can reach at start of boot with the right key is an interface to interact with things which can be altered.
A Jetson does not have a BIOS of any kind. A normal flash of a Jetson not only flashes the operating system, and the bootloader, it also flashes everything a BIOS would do. That equivalent of a BIOS is more or less specialized in a Jetson and is not a general purpose BIOS you can do ordinary “BIOS things” with. There are a few things, but it is not generalized. Flash flashes the BIOS, and thus also the BIOS environment, such as what device to boot to.
For reference, L4T is just what you call Ubuntu after you’ve added the NVIDIA content. This might include things like a modified kernel and firmware or drivers. Here is a list of L4T releases for Jetson (historically, there are much older releases for Tegra, but those did not have a GPU and were not called “Jetson”):
https://developer.nvidia.com/linux-tegra
A useful bit of history when thinking about this: The boot chain itself has undergone a lot of changes over the years. I have an old Tegra 3 system, and it used a third party version of L4T 16. It was the absolute minimum boot chain to go to an operating system. If you wanted to work on most BIOS type function, then you’d be recompiling boot software for bare metal and maybe at times working in assembler.
The Jetson line started with the TK1 in 2013. This was not all that different from earlier software, but it was L4T R19.x and very quickly evolved into L4T R21.x. This was the last 32-bit system developed, and used the Das U-Boot bootloader, as did many other embedded systems. What was different is the effort to reach that bootloader since there was no BIOS. Everything was still entirely custom for the TK1 up until the bootloader itself ran.
This is when some effort started going towards a more unified boot system (not just the bootloader, but also everything leading up to the bootloader). This is also when things started going to 64-bit, and much of the boot chain was invalidated. For example, it used to be a compressed zImage for the kernel, but the U-Boot decompression was not designed to work with the larger sizes and address space of 64-bit, so this is when Jetsons started using the uncompressed Image format. This probably seems irrelevant, but it is part of the long answer you probably were not asking for. Everything leading up to the bootloader, the bootloader itself, and the kernel loading was very custom.
The TX1 was what came next, and this is what the older plain “Nano” is. In around R24.x (not really released for most use) the boot chain and kernel used a lot of the 32-bit mode and did not really take advantage of 64-bit entirely. This is because 64-bit ARM had not been written by anyone yet, it was brand new. Then we got into R25.x and started seeing less 32-bit software and more and more had migrated to 64-bit. U-Boot itself more or less started going away, although the specifications of what U-Boot did was absorbed into the boot chain and environment. Meaning that it still looked like U-Boot and acted like U-Boot if you looked at the correct subset of function. This leads into R27.x which was more or less all 64-bit, and once the kernel was running and the root filesystem mounted, it became standard. Still, everything up to getting there was custom.
R32.x was what I would call the first release where things were nicely fit together and not so much custom, but still, it was U-Boot, and people at NVIDIA started looking for something capable of a more abstract and generic boot chain (which in this case also means the “BIOS chain”, my made up phrase). Old style master boot record (MBR) BIOS was phased out, and partition schemes were entirely UEFI style (this is actually something which occurred much earlier so far as BIOS scheme, but now we are talking about the software reaching the boot content and not just the partition itself). Keep in mind this is what I am saying people “started thinking about”. Standardization and generic abstraction of boot.
Regarding UEFI, this allows a more pseudo-object-oriented approach to boot. A BIOS still has to bring up clocks and power rails in the right order (you’ll see references to the BPMP, Boot Power Management Processor), which is in the middle of all of this, but at some point UEFI then presents a uniform abstract interface which does make the Jetson truly work like a PC after that point…one no longer needs a specialty boot loader, and it is possible to do some UEFI style environment customization. Still, one must flash the Jetson to get to that point where the UEFI exists.
It was in L4T R34.x that experimentation started for migrating to UEFI, and in L4T R35.x that new software was released related to this; simultaneously this is when Xavier was introduced. R35.x was partially UEFI, but still not fully so. A custom kernel and some Jedi mind tricks with device tree were still somewhat “not a complete UEFI”. But it was a major step in that direction.
In R36.x, which so far only Orin works with (Orin also works with R35.x) UEFI migration was complete. This is when the kernel and bootloader could be from mainline and not an NVIDIA modified version. Think about that: The kernel version and source configuration and patches of R35.x kernels and earlier required modifications so the boot stages could start Linux. The rootfs is the operating system, and an incorrect boot content mixed with an incorrect rootfs would not boot.
Now think again about what I said earlier: There is no hardware BIOS with its own memory, and so when you flash, you are also flashing the equivalent of a BIOS and all of that BPMP code for power rails and clocks. If you have two Jetson Orins, and they have an identical rootfs, but you did not flash the earlier boot code on one of them, then boot will never reach the kernel and it’ll never start. The BIOS is missing, or the boot chain does not know where to point the boot to.
If and only if both Jetson Orins have the same boot and BIOS-equivalent software on them already will an exact clone of a partition do exactly what you want. The trick is that each of those Jetsons must have been flashed at least once with all of that other content; in that case it would work, although there are still partition UUIDs to worry about since some boot content naming a UUID could have been part of the previous flash of the non-rootfs content.
If all Jetsons are Orin or newer (newer is not yet out, but will be released soon), and if they have been flashed with the non-rootfs content compatible with the rootfs, then all is ok.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.