Here are my following questions:
I can’t answer all of it, but AGX Orin is incompatible with DriveOS (which is a separate line of hardware, although it does have some shared components).
Then what does Jetson Orin eval board comes with on the Eval board Linux???
If I want to reflash the Orin Images how to do it steps
Some terms would help…
What gets flashed to a Jetson is “Linux for Tegra”, or “L4T”. This is just Ubuntu plus NVIDIA drivers. The actual flash software is known as the “driver package” because a Jetson in recovery mode is a custom USB device, and that driver is what knows how to flash it. JetPack/SDK Manager is just the GUI front end to flashing.
You’d need to flash once when you get a Jetson as it won’t usually work without flash. You’d need the correct release of Ubuntu on a host PC to run the flash. If you used command line instead of JetPack/SDKM, then it is more difficult, but it does allow a wider range of Linux host PC software to flash. It is JetPack which traditionally installs the extras though, like CUDA or other options.
L4T and JetPack/SDKM releases tend to be tied together. Orin can work with either L4T R35.x or R36.x (which corresponds to JetPack 5.x or 6.x). I would suggest go here and check the documents the most recent release of R35.x and R36.x (there are other things tied to each release, you might want R35.x or R36.x):
DriveOS is a different operating system, although it is also based on Ubuntu.
What is different between Driveos and L4T and JetPack???
Can I do the following with either LT4 or JetPack
Can you provide docs for it
Jack
DriveOS includes hardware with “functional safety”. Generally, that’s the realm of the ARM Cortex-R series, whereas Jetsons don’t have that (there is an exception that the Audio Processing Engine and Image Signal Processors are based on a Cortex-R, but those are not for general use). This is why automobile manufacturers would use the DriveOS hardware and not a Jetson.
L4T is just Ubuntu that was adapted to Jetsons. Mostly it is plain Ubuntu with boot chain modifications since Jetsons don’t have an actual BIOS (when you flash a Jetson you are also basically doing the equivalent of a CMOS BIOS flash). There is no functional safety, and there is nothing that allows “deterministic” (time-guaranteed) behavior. This is more like your desktop PC.
The L4T docs are what you want for o/s information. That is determined from this L4T release URL (you’d be picking either L4T R35.x or R36.x):
https://developer.nvidia.com/linux-tegra
There are further documents which go into more details about all kinds of things here (I’ve preselected for AGX Orin):
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_agx_orin
Beware though that those docs include things which are not part of the o/s itself at times, and they might be confusing if you are just starting to dig in (for example, docs might be about the Tegra chip itself, when you might instead be thinking about the module or carrier board; you have to be careful to look at the correct part).
One would normally flash the AGX Orin when it first arrives. I’m assuming it is an NVIDIA developer’s kit and not an NVIDIA module on a third party manufacturer’s carrier board (must would be in common, but details would change). If you simply use the JetPack/SDK Manager GUI from an Ubuntu 20.04 host PC, then it will create the filesystem, add drivers, make a full image, and flash it. Everything. This starts in recovery mode with the correct USB cable connected.
Note that when a Jetson is flashed that it will automatically reboot at the end of the flash. JetPack uses the fully booted system to install many of the options you might have picked. Although the Jetson was in recovery mode, at this later stage, it is actually now fully booted and no longer in recovery mode. For this stage to complete you would have had to have completed the first boot account setup steps for login.
As far as compiling software goes, the Orin is quite capable of building software natively. Mostly it is a question of whether you have enough disk space. Cross compile is also possible, but that can take a lot more understanding. Cross compiling a kernel is not difficult because it is “bare metal” (it doesn’t link to any libraries or environment; linking is where cross tools and compiling can get a bit complicated). The software which is “user space” and not “bare metal” requires much more information.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.