I am searching for a solution for a specific problem. More of us need to work with 1 Xavier AGX system and everybody uses a different L4T version, but flashing a new version every time takes to much time. I know it is possible to boot from SD card, USB, etc. and that’s the plan, but the problem lies in the AGX boot firmware because it says “Jetson AGX Xavier series devices use boot firmware that is stored only on internal eMMC memory. Consequently this type of device cannot boot from USB or NVMe SSD until its internal eMMC has been flashed.”
Do you maybe know which partitions in “sdmmc_boot Partition” and “sdmmc_user Partition” I need to flash to make AGX work properly? Is it 1 specific firmware or is it everything that contains ‘firmware’ in the description?
Is it possible to flash the sdmmc_boot parts as a whole with a simple command or do I need to flash it 1 by 1?
I’m searching the inet but can’t find an answer…
Thanks in advance.
Would it work if I make a bash script that executes all of the “flashes”?
For example sudo ./flash.sh -r -k <sdmmc_boot partition> jetson-agx-xavier-devkit mmcblk0p1
Or it wouldn’t work because you need to put the AGX in force recovery mode after every flash?
I can’t answer, but it might be useful to know that recovery mode is only used during flash. When a flash completes the Jetson self-reboots. Recovery mode makes the Jetson a custom USB device understood by the “driver package”, which is what the flash software is. Theoretically, if you had non-rootfs (not APP) partitions which were large enough for any content you might add, and if that content is you are adding is correctly signed, then a running Jetson could use the “dd” command to write the new partition. There is a good chance that if everything does not match it won’t boot. One of the nice things about flash is that it signs everything correctly and makes sure each partition has matching content. A typical embedded system does not have a BIOS, and many of those partitions are the equivalent of a BIOS, so you are often messing around with overwriting the equivalent of bits and pieces of your BIOS when you write to some of those partitions. There is a lot which can go wrong.
Note that if you were to flash your Jetson on command line, and were to log this, then you could see which images go to which partition. Example flash with log: sudo ./flash.sh jetson-xavier mmcblk0p1 2>&1 | tee log_flash.txt
What you may not notice if you don’t look closely is the signing part of it. If you were to use the additional option “--no-flash”, then it wouldn’t flash, but it would produce the same flash content…not useful until you realize that this leaves the signed content and does not delete it. So you might do this to see what the signed content is: sudo ./flash.sh --no-flash jetson-xavier mmcblk0p1 2>&1 | tee log_flash.txt
It is my opinion though that using signed files like this has so much that can go wrong and takes a degree of practice and confidence that making this work with multiple developers is asking for trouble (it is difficult enough to not make the system unbootable even with a single developer doing this). You would definitely want a rootfs/APP clone before you attempt this since a single failure means no running operating system, and the running operating system is need to put that signed content in place.
Of course if you looked at the flash logs and were able to find the content source, and modified that instead (perhaps identified by a flash log), then the job would probably be done correctly each time (and it is perhaps possible to do so without flashing the rootfs/APP itself, which would make this quite fast). Each developer could have their own modified “Linux_for_Tegra/” content and would not need to understand how to sign and use dd to fit individual partitions. Sorry, I don’t know what content would need to change, and if your content happened to be larger than the original partition, then there would also be an XML file to edit. Also, perhaps you would have to pad binary content you’ve created to fit a particular partition…don’t know.
I don’t know. You can certainly flash QSPI. Someone from NVIDIA would have to answer that (perhaps there is a way by editing XML files even if not by default).