Have orin nano., running latest jetpack 6, just fine. However need to revert to jetpack 5.1.x. Using sdk manager is there anything special needed to do?? Put in a new ext4 SD card and set sdkmgr for jetpack 5.1.5 and jumpered force reset.
SDK starts the download to the Jetson, goes for a while to about 90%, then gets very sloooooow, then fails exec_command 85155 blocks, then (error code 11)… tried a few times. Anything being overlooked?
get sdk install errors like:
failed to read rcm_state
skip generating mem_bct because sdram_config is not defined
This jetson was working fine under jetpack 6
Hi,
Please use QR code app with Data Matrix format supported to scan the barcode in the modules and share the results with us to review.
Thanks
You can never give a clear answer …what would a barcode from the unit prove?
There are some revisions in hardware when electronic component availability changes. Different manufacturers of parts with different revisions can require different software releases. It isn’t possible to say which release sometimes without knowing the revision.
WHO CARES —this unit has been working100% fine with all the latest jetpack6 etc, everything the latest up to date.
NOW we need to go back to jetpack5 for some reasons...do we simply open up sdkmanger and select jetpack 5 flashing?
One JetPack can be used to work with earlier releases as well if you start like this:
sdkmanager --archived-versions
I don’t know if it is the case, but if you start like that, then you migth be able to pick other releases without earlier issues. There is also a command line method which would reveal a lot about what is going on, and perhaps even “just work”. Command line though depends on the flash target. By this I mean that if you have a commercial module and flash to eMMC, or a dev kit and it flashes SD card (really it is QSPI that gets flashed on the module itself), these are default flashes; when you change to flashing NVMe, or some non-standard flash, e.g., anything with eMMC flashing SD card is non-standard, the command line changes. What is your exactly flash target? This could give you a way to simplify on command line which might work better and bypass needing JetPack/SDK Manager.
TO BE CLEAR we have an orin nano dev setup we bought from mouser or digikey, and have been using jetpack6, with all the latest. We want to completely forget all about that, put in a new blank SD card, turn on SDKmanger and select to flash and use jetpack 5 to investigate some issues of another jetpack5 system …is that all that is needed to be done? Not sure what you mean by qspi If not what are the steps?
More or less what you described does perform a QSPI flash. Every Jetson flash is more or less simultaneously flashing the BIOS, boot chain, and o/s. If you have a dev kit without eMMC, using an SD card slot for o/s, then the non-o/s content is in QSPI memory. That memory is part of the module itself. In the case of an eMMC module, then that non-o/s content is in signed partitions of the eMMC. Normal flash does this. If you’ve flashed once with JetPack 5.x (L4T R35.x), then any SD card which is also L4T R35.x should work. If you’ve flashed once with JetPack 6.x (L4T R36.x), then any SD card for L4T R36.x should work. You could not cross boot content with o/s content if they are from a different major release version. You can, as you say, flash once with JetPack/SDKM 5.x to install the equivalent of BIOS and boot chain for any L4T 35.x release SD card; that content would be in the module itself.
You should be able to start like this and see both current and earlier releases:
sdkmanager --archived-versions
Incidentally, you don’t have to flash the SD card too. You could, and if you want to know what was going on, then you might want to save your original L4T R36.x SD card, and flash with a new SD card to the latest R36.x. Then you could test your old o/s SD card which was also R36.x. If it works, then the problem was in the QSPI memory and the SD card is probably good the way it is. If it doesn’t work after one flash with the correct software, then it is likely the SD card content itself is or was bad. In that case you can extract important parts of that SD card to save and to maybe apply to a new SD card so you don’t lose anything important.
It is simple to do as you were planning, to just flash with a new SD card. Then work on that major version. If you want more details on flashing just the QSPI content (to quickly switch between a board supporting L4T R35.x to R36.x or back), ask here. The gist is that you’d do this quickly on command line (not writing that o/s saves a lot of time). Command line allows you to flash only QSPI. If you go to your “Linux_for_Tegra/” directory, and run the command “ls jetson*.conf”, then any file name you see is a flash target (but you’d leave off the trailing “.conf”). You’ll notice some of those have “qspi” in their name, and those are fast to flash. In theory it would leave alone the SD card itself. Just ask if you want to know a command line flash for just QSPI using one of those targets.