I wanna install JP 5.1.2 on SD card 1 to try some new feature on Issac GEM, Meanwhile all my vital code and environment located on SD card 2 which is installed with JP 4.5.1.
Question1: Could SD card 2 (JP 4.5.1) works normal after developer kit QSPI updated ?
Question2: If Q1 is NOT, How to down grade JP5.X to JP4.5.1 on xavier nx developer kit? I can not find any botton on mother board to force the xavier nx developer kit into RCM.
I will not update my QSPI until get offical support. I do not wanna lose all my code and environment.
Question2: If Q1 is NOT, How to down grade JP5.X to JP4.5.1 on xavier nx developer kit? I can not find any botton on mother board to force the xavier nx developer kit into RCM.
→ I don’t know which board you are using. If this is NV developer kit, we have devkit user guide on the download center. If this is a custom board from specific vendor, then you need to check the datasheet shared by the vendor.
I will not update my QSPI until get offical support. I do not wanna lose all my code and environment.
I think your vital data are all on the SD. Software change on QSPI may not matter to it.
Use the most recent JetPack found by looking at the most recent L4T R32.x. Then start sdkmanager via: sdkmanager --archivedversions
Pick the release you want. This should be able to flash QSPI, and the SD card would need to be changed separately I think. Note that if you have alternate requirements for your carrier board, then you might need patches. For command line flashes, take a look at the files with name “*.conf” in the “Linux_for_Tegra/” directory of the flash software (assuming it is a dev kit; edits may again be required for custom third party carrier boards). The flash targets are the name of the “*.conf” files, but with the “.conf” not used. So if you were to flash on command line for target “jetson-xavier-nx-devkit-qspi”, this means it is looking for file “jetson-xavier-nx-devkit-qspi.conf”. If that file exists, then it can be a flash release for that target.
Note that many of those “*.conf” files are actually symbolic links. Check: ls -l jetson*.conf
The “human” name, e.g., something stating “jetson-xavier” in its file name, is usually a symbolic link pointing at the more “technical” name. That technical name is usually a combination of the module’s version and the carrier board’s version. This part is not important unless you have some odd combination of carrier board with module.