Hi,
I am using the jetson nano production module for facial recognition products. I have an image file that has all required libraries installed ready to use for jetson nano. But for the production module, I can able to flash jetpack SDK through SDK manager only. using SDK manager I couldn’t find any option to flash our custom image. Can anyone tell me how to flash custom image file to jetson nano production module?
SDKmanager will download a driver package to you host machine as Linux_for_Tegra. The default patch is “~/nvidia”.
To flash the board, you can refer to the quick start guide to understand how to use flash.sh inside the Linux_for_Tegra.
Also, I am not sure what kind of “custom image” you are using . Production module is unlike sdcard based module which has a sdcard image as all in one. All the files are inside the Linux_for_Tegra driver package.
Note that if it is an eMMC model, then you can modify the host PC’s flash content to use your custom software, e.g., via a clone, but it isn’t clear what you are including in “custom image”.
Custom image I meant is… I have installed jetpack 4.4 in my developer kit and above it I have installed all required libraries I want…which took me 5hrs. So I have taken copy of that sd card image with me. So I want to use this sd card image to my Jetson production emmc module without wasting 5hrs time again for libraries installation.
Is the SD card image from a development kit? If so, then the hardware differs from the eMMC model. Much of the rootfs clone from an SD card would work for rootfs on the eMMC, but not all of it. The boot chain differs between the two models, and the two rootfs cannot be used as a direct swap between the two types of hardware. Are we speaking of mixing an SD card model with an eMMC model?
FYI, even if that is the case, if you have certain content, then you can copy that content into the flash software’s “Linux_for_Tegra/rootfs/” and have the content already be present upon flash. The flash software would handle the proper boot chain for eMMC or dev kit model, while customized non-boot content would “just work” upon flash. Are any of your modifications to boot content? This includes kernel, kernel module, initrd, and device tree.
Hi,
If I copy the rootfs content of my sd card with emmc roots then can i able to access all the libraries are present inside the rootfs?
So far as the rootfs goes, if you set your filesystem to read-only prior to copy to SD card, then this should work for that partition (there are ways to go read-only, e.g., through Magic-SysRq keys, which I can explain later). Flashing to a new eMMC unit would still be required, it is unlikely you could boot directly from the SD card without work.
As background, consider that there is content inside of the module other than the rootfs (things in the boot chain) needed before boot can point itself to any device for continuing boot from the prior stage. eMMC models do not come pre-flashed, and only flash can add that content. There are also differences in that content for some older releases versus newer releases, and in some cases the rootfs might be dependent on small edits in that earlier boot content. If the eMMC model you are transferring the content to is flashed via the PC’s flash software, and if the flashed version is a match for the SD card clone, and if that SD card clone is used as the rootfs content, then it should work. If the two eMMC models do not have the same early boot content matching, then there will be a tendency for this to fail. If the two models are different hardware revisions, then even if you use two eMMC models of the same revision, it is possible for boot to fail.
If you really want this to work, then you should understand some things about the flash process. First, the host PC content in “Linux_for_Tegra/rootfs/” is used to create a partition image, “Linux_for_Tegra/bootloader/system.img”. The content of rootfs/ is by default a purely Ubuntu image, and then NVIDIA direct hardware acceleration drivers are added to this, along with some boot content. Most of the content which is unrelated to the release and boot is an exact match of the rootfs/ directory.
Then, upon flashing, parameters passed to the flash.sh script (JetPack/SDKM is just a front end to this and does not actually do any flashing of its own) cause content in “rootfs/boot/” (and perhaps initrd and device trees) to be updated for the specific Jetson hardware (including board revision) to be copied into the “rootfs/”. Once this is updated, the “bootloader/system.img” is created. It is this “boot content modified” system.img which is flashed.
If you were to clone the rootfs of an SD card, then this is presumably a match for what would be in the “bootloader/system.img`”. If you were to copy this (and only this) to the new Jetson, then you would be missing all of this boot content editing, and unless that content were already in place, then boot would fail (remember that the eMMC model also has flash content you cannot necessarily see in QSPI memory).
If you were to loopback mount your SD card rootfs partition as an overlay on top of “rootfs/” (mounting something there does not harm the original content, but it does make that content invisible and replaces that content with the newly mounted device until the mount is removed), and perform a “full” flash without “reusing” anything, then you would also get the correct boot content flashed (including things you cannot see in QSPI). That content, if flash.sh is told correctly about which board is being booted, will be correctly updated, The SD card clone would have some of its boot content overwritten with whatever was required for that revision, but otherwise the SD card content would be untouched.
Similarly, if you recursively copy the content from the SD card into the “rootfs/” content, then you would be doing the same as a loopback mount, but it would be a copy instead of the SD card which has its boot content modified.
If you do copy a rootfs (APP partition label) to an SD card, then you must avoid crossing filesystems. Not every file is part of the SD card, e.g., most of “/dev” should not be copied, and nothing from “/sys” or “/proc” should ever be copied. A simple recursive copy of the partition to SD card would not be valid. The dd command (if the partition is read-only) would do the right thing, or perhaps with the correct options “rsync” would do this correctly. Just a cp command would create an incorrect copy.
You could use Magic SysRq to put the rootfs/APP into read-only mode. If you have a keyboard attached, then monitor “dmesg --follow” on a terminal as you issue these keyboard key combinations:
You will see a “sync” followed by a remount read-only. If using a serial console only, then you’d need to substitute with some echo statements to “/proc/sysrq-trigger”, e.g.:
sudo echo 's' > /proc/sysrq-triggersudo echo 'u' > /proc/sysrq-triggerFor an eMMC model though a clone using the host PC is superior. Your clone from a read-only running system will include file locks, temp files, so on. A clone will copy the content of a properly shut down system.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.