I just wanted to upgrade the L4T.
No, the latest version to support TX2 is JetPack 4.6.3.
Thank you.
That means no more update for TX2. Anyway TX2 is fading out.
We will contiune releasing the security and critical issue fixed on JetPack 4.6.x baseline…
Thank you.
By the way, if the rootfs is pointed to external drive, where will the update/upgrade files go or which drive will be updated/upgraded?
Updates depend on model. If this is an eMMC model, then anything related to boot goes in non-rootfs partitions. User space packages always go to the rootfs. In the case of an SD card model (where the SD card exists on the module itself, and there is no eMMC) the boot related content goes to QSPI memory on the module. No Jetson has a BIOS, and so you could consider as simultaneously flashing the BIOS (the equivalent) and the operating system. Until you get to the JetPack5.x+ releases the boot content is tightly coupled to the rootfs (TX2s can’t use JetPack5.x; even then the earlier stages of UEFI are tightly coupled, but it then abstracts and uses pretty much generic boot content which is more like a traditional PC).
Thank you.
If the file system is pointed to SSD then the SSD will be updated, is this the case?
Boot target is more or less a pointer to the rootfs. Boot content itself is still in either eMMC (if not an SD card model) or QSPI (if not an eMMC model). The SSD will never contain bootloader, nor boot content (which includes the content which is equivalent to the BIOS).
One common problem people run into is that sometimes they set up correct external boot to something like an SSD (and thus have customized boot content), and then there is an update which does not know about the customizations…the customizations would be lost. If you make a customization, and want to know it is to not be modified during updates, you should ask on the forums about this. Incidentally, customizations can include anything on a third party carrier board which is not an exact match to the electrical layout of the dev kits sold by NVIDIA. This is what the flash software from the third party carrier board manufacturer will have modified, and even if it isn’t a regular update, then flashing using the non-modified NVDIA software could erase the third party modifications (the lesson being that you have to use the software from the third party manufacturer, or at least know which packages to blacklist).
I cannot personally say which parts of SSD boot you have to be careful with for updates. Someone else would have to answer this.
Incidentally, rootfs settings are more or less a pointer to a target. Chain loading is possible. For example, one might have an SD card model, and QSPI would point to SD card; then the SD card might point to the SSD. Any change anywhere in that chain of pointers could cause boot to fail (or to boot to the wrong device). It is not possible to put the initial pointer to boot device anywhere except the module’s internal storage (if an eMMC model, then eMMC; if an SD card model, then that pointer must first be in QSPI).
Thank you.
I will try later on to see what happen,
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.