hello Andrey1984,
the flash process will generates system.img to your local host machine, and write the binary to $OUT/Linux_for_Tegra/bootloader/system.img. it’ll also convert the Raw image to sparse image.
however, if the -r options has assigned, it skip building and reuse existing system.img for the process.
Hi @JerryChang
Thank you for following up!
when you pointed out that system.img will be generated unless the key -r is specified, did you mean that the image will be generated from the APP partition of the unit? From available in Linux_for_Tegra rootfs package without using the APP partition of the conencted unit?
Could you also clarify if the resulting system.img will be generated e.g. into the sdkmanager Linux_For_Tegra bootloader foler? Or otherwise what do you mean as $OUT path? do you reffer to the sdkmanager generated folder or the compressed folder of the resulting tar.gz archive?
“bootloader/system.img” and “bootloader/system.img.raw” are generated from “Linux_for_Tegra/rootfs/” unless “-r” is used.
hello Andrey1984,
it’s my assumption of the default JetPack installation path as “$OUT”,
for example, ~/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_AGX_XAVIER/
the flash script it generates system.img from rootfs package. it doesn’t looks for connected target to create an image.
when the -r commands used, it takes the exist system.img, ($OUT/Linux_for_Tegra/bootloader/system.img) and flash that into APP partition.
the process it only reads APP partition via connected device when you have assign -G options, which is back-up and clone commands, it reads and writes the back-up image to your local host.
Hi @JerryChang
Thank you for your response!
When you said “the flash script it generates system.img from rootfs package.”
does it pertain to the flash.sh script or nvmassflashgen.sh script? I am concerned in the latter rather than in the former at this point.
AV
both of them. system.img is created by your local host rootfs package.
@JerryChang
If both of them do populate the system.img from the rootfs, does it mean that nvmassflashgen.sh does not address the custom board specificities at all while creating the deployable package?
The second one, the flash.sh, However, doesn’t populate the system.img from the default rootfs package, as it seems to me, right? How do you mean the flash.sh creates system.img from the rootfs package? Could you extend, please?
Coudl you clarify which exactly script does address cloning of a reference unit for deployment to multiple units given they are custom carrier board production units?
I think this is the same for both mass flash and regular use of flash.sh, but I am only stating this for a single “flash.sh” command…
Linux_for_Tegra/rootfs/” is populated by the sample rootfs.apply_binaries.sh” script adds packages and files in common to all of the Jetsons with that release.extlinux.conf along with some model-specific files, e.g., the kernel Image and device tree. Not sure what all of the different things are which would be customized, but it is entirely from the kernel and/or boot chain.If you flash on command line I recommend you append " 2>&1 | tee log_flash.txt" and it should actually tell you what is populated to “rootfs/” prior to creating an image. On the other hand, if you’ve used the “-r” option, then no such boot content setup will occur since no system.img is created. I really like logging from command line since it seems more informative in a smaller space than are the SDKM logs.
hello Andrey1984,
you may check the flash messages, it’s a time consuming step to make a system.img
here’s an example,
populating kernel to rootfs... done.
populating initrd to rootfs... done.
populating kernel_tegra194-p2888-0001-p2822-0000.dtb to rootfs... done.
Making system.img...
...
Sync'ing system.img ... done.
Converting RAW image to Sparse image... done.
system.img built successfully.
according to Jetson Module Adaptation and Bring-Up, you’ll need to have your own customizations, such as board configuration, MB1 configurations, pinmux/GPIO/PMIC changes…etc; so, you’ll have new cfg files to apply those customizations.
for example,
please refer to p3668.conf.common, it’s a general configuration file for Xavier NX, you’ll see all cfg file used by default. since you’re having customize board, you should replace the cfg file to adapt to your board design.
@JerryChang Will it work if I just copy the cfg files from the MFI provided by the vendor? otherwse how manually address all these cfg aspects for recreation from scratch? Can not they be dumped automatically from the custom jetson production unit with inmstalled OS?
@linuxdev
I am concerned a little bit of how to delete the duplicate for ethernet device 1 which I have in duplet after recovering from the image with nvmflash.sh - it results in the unit to that the image was recovered having in Enthernet conenction listed two devices with incorrect mac address [ of the source of APP clone] and with correct mac address;
I am looking for terminal command to delete the errorneous one
Could you advise?
Thanks
Upd:
Specifically nm-connection-editor shows in Ethernet section for device selection a list of devices with the default one selected being incorrect that would be from the origin of the APP clone
In some cases the MAC is used (or created) in udev. If this is the case, then simply delete the udev rule from the clone before flashing with the clone. Do you see any files in “/etc/udev” (probably in “rules.d/”) which might look at an ethernet device?
In other cases I’d think the MAC information would be external to the rootfs and any duplication would be from outside partitions (and/or QSPI if SD card model). One example where such a thing might be inherited is if the device tree itself contains the MAC. Since the device tree inside of “/boot” is only used if the extlinux.conf has the “FDT” entry, then the only case of the cloned rootfs being an issue is if the device tree in “/boot” is named via the extlinux.conf. There is of course still the possibility that the partition-based device tree also has something related to MAC.