Writing partition APP with system.img *** Error: Flashing the device failed. ] 031%

hello Andrey1984,

yes, massflash only support with eMMC modules.
however,
there’s tool to support that if you’re working Jetson Xavier NX with external storage, (i.e. NVMe)

please check below for more details.
$OUT/JetPack-4.5.1/Linux_for_Tegra/tools/kernel_flash/README.txt

@JerryChang Using production nx/agx, having a cloned APP partition created from one device, can we use this nvmflash method to get rid of remnants of the mac addresses from the original unit from that the APP image was cloned?

I don’t know if this applies for your case, but there are times when network device information is set up in udev. You might want to check if there is anything related to your MAC address in a subdirectory of “/etc/udev”.

1 Like

@JerryChang
In which exactly location the cloned image should reside?
Given I have the cloned image in the folder /home/nvidia/backup
However running the nvmassflashgen from /home/nvidia/generate_flash
Where the pre-existing image shoudl reside before running the nvmassflash command? Just executing nvmflash.sh after creating the mfi folder with nvmassflashgen script doesn’t appear to result in the unit booting.

did you mean you’ve extract the mfi_* package, running the nvmflash.sh to flash the target to repo the failure?
since this topic has been solved, could you please initial another new topic and share the steps; we would also like to reproduce the issue locally for investigation.
thanks!

Exactly, from a woking unit, I get the mfi package by executing

./nvmassflashgen.sh jetson-xavier mmcblk0p1

then after connecting a new unit after unpacking the package after processing the ./nvmflash.sh the jetson won’t boot

posted new thread to Nvmassflashgen cloned partition won't boot on other units

thank you, let’s follow-up with Topic 189508.

@JerryChang Thank you for following up, but
could you extend if the reuse of existing system.ing reffers to reuse of the APP partition from the source device or it refers to the particular PATH with particular system.img file that is pressumed to be present at the Host PC somewhere? If yes where excatly?

Here the question that requires a clarification also is either the ./nvmassflash.gen generates system.img using a conencted device which is in recovery mode so it loads all the partitions from it or if the nvmassflashgen.sh generates system.img from Linux_for_Tegra folder
Could you extend on particular details, please? Does the generator use both linux_for_tegra, but also the device as ta source?

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…

  1. Linux_for_Tegra/rootfs/” is populated by the sample rootfs.
  2. The “apply_binaries.sh” script adds packages and files in common to all of the Jetsons with that release.
  3. The final flash command takes into account arguments (e.g., if the target is a jetson-tx2-devkit then the result is different than if the argument is jetson-xavier) and populates an 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