Nvmassflashgen cloned partition won't boot on other units

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

any ideas?

ref: Mass Flash on with connect tech carrier board - #5 by Andrey1984

hello Andrey1984,

just would like to confirm, is these two Jetson-Xavier with the same SKU?

@JerryChang yes, they have the same module also the same carrier board
which command do you use to confirm the SKU is the same?
So far what worked was cloning/restoring APP partition with flash.sh
but the complication is that as it is a custom board, also as the manufacturer provided the initiall installation image with mfi package from 4.5.1 Jetpack, but the custom APP that gets applied after is from Jetpack 4.5.1 which works with flash.sh somehow, but after getting processed it by nvmassflashgen from the customized product of the steps mentioned above though just cloning the APP partition seems workingm but nvmassflashgen ade nvmflash won’t working

Q1: does execution of the nvmassflash.sh preserve all custom carrier board specificities including but not limited to device tree kernel components APP partition etc?
Or it just renders a generic system.omg APP partition that won’t fit a custom carrier board at all but only default nvidia SKU units?
this command would return 2888-0001

cat /proc/device-tree/nvidia,dtsfilename

@JerryChang could you also clarify, if Jetpack 4.6.1 Linux for tegra folder can be used to create & restore image of a device or for device with 4.5or it needs necessarily be the Jetpack 4.5 Linux for tegra nvmassflashgen.sh/ nvmflash.sh folder/files?

Hi @JerryChang
How is it going?
Any update on the procedure of flashing unit using nvmflash.sh,
given the vendor suppliees the MFI package that then needs to be applied woth APP partition flashing so it takes two flash attempts?
How can it be done in a way a unit installed with two steps above will only require one flashing, e.g made from configured unit using the nvmflash.sh? Will it address the remnants of the source of the clone in a way the MAC addresses etc will be not present at new units restored from the image made from the reference unit?

What I can do as for now:

  1. use nvmflash provided by manufacturer
    [ it flashes but kind of won’t have applications/system configurations]
  2. I can substitute the image in the MFI folder from the manufacturers deliverable with custom created system.img that was created from other Jetson
  3. I run nvmflash, but there will be remnants from the source jetson APP like network mac addresses, connection names, etc

What I would like to do is to generate a package from a Jetson that gets little bit customized manually via setting up applications/drivers/parameters so that it could be recovered with nvmflash to other devices in a way it won’t have the remnants like Mac address/ conenction name etc

hello Andrey1984,

we have a public holiday for a long weekend, we’ll try to arrange resources to reproduce the issue locally.

hello Andrey1984,

am I understand correctly you would try to clone JP-4.5 APP partition and restore it into JP-4.6 to flash the image?
it’s not a suggest approach since they’re having different kernel versions, using different version JP to clone and restore may hit some unknown issue.

Hi @JerryChang
Thank you for following up.
No, it is not the case. I am just operating with JP4.5.1 in this discourse.
I got production units to figure out deployment from one reference production unit to other production units so it could be used for simple flashing.
As my investigation has shown the nvmassflashgen package doesn’t address the use case at all? so it doesn’t create neither system.img not specific custom board data is acuired by it ? Could you clarify, please? So nvmassflashgen is not applicable as a standalone solution for distributing OS image from reference unit to other units with the same SKU?
In particular I did hope that as nvidia released nvmassflashgen for production use it would have addressed creating imge from a production unit for deployment to other productino units with nvmflash.sh automatically. But it doesn’t seem the case?

hello Andrey1984,

we did not try update system.img of the mfi package to re-flash the target.
we try create package on device-A Xavier and run nvmflash on device-B Xavier, they’re success.

Thank you for following up.
Could you extend if they success on default nvidia devkit boards only or success on custom carrier board AGX? Both? neither of the two?

hello Andrey1984,

we have only test on DevKits, (i.e. default NV devkit boards)

could you please clarify which step you’ve the cloned system.img writes to broken the process.
you should be able to run flash.sh to include -r options and deploy the flashing.
did you overwrite mfi_/system.img with the cloned image to repo the failure?

Hi @JerryChang
Thank you for following up.
However, I recollect from previous nvidia responses from the forum that nvmassflash/nvflash is not supported with NX devkits, right?
I am dealing with production NX devices in the given contextm they have specific drivers for specific custom devices. As for now there is no need to do AGX massflashing but in production context.

nvmassflash should work with every production module. Where did you see it does not support NX?

I think we should clarify that such tool may not support “sdcard module”. But If this is production module case, then we shall support.

Hi @WayneWWW
Thank you for your response
I saw that nvmassflash.sh doesn’t support NX devkit without eMMC.
However, by definition a production module is using a custom carrier board If nvmassflash doesn’t support a custom carrier board products [without using flash.sh which is a separate tool] , but neither it supports NX devkit as it has no eMMC.
How does nvmassflash.sh support making a production deployable package in ordde to deploy from one production jetson device with carrier board to other production modules? Could you extend please which exactly steps are required to deploy a working OS of a production modue custom carrier board Jetson to other xustom carrier board jetsons with hte same sku automatically? with just creating the deployment package from existing device so it will not only have all required drivers etc but also take care of network mac addresses for network interfaces etc?


If nvmassflash doesn’t support a custom carrier board products

Sorry that I don’t know what is your exact problem here. nvmassflash shall also work with custom board.

Please just tell us what is your goal. What was the command you used and failed? Did you try to do any cross version update/back up here? For example, try to use some backup file from jetpack4.6 to deploy to jetpack4.5.

Also, want to know that do you have the knowledge about how to flash a custom carrier board without problem?
I don’t suggest user to just directly try massflash when they don’t even know how the flash.sh tool works.

@WayneWWW Thank you for following up
The goal is to deploy a reference unit OS [ with all drivers]to other jetsons in production environment.
The second goal is to figure over-the-air upgrade / flashing for units
I did not find any way how nvmassflashgen could take an image from the reference production Jetson unit so I was not able to find any supported options to create a deployment package with nvmassflashgen
If you could share steps how to do a deployment package from a reference unit that will have all drivers in place it would resolve the issue maybe. But so far I found that it will be a subject of manual edition of multiple configuration files within some folder with default OS installation on Host PC? that is not very obvious to me how to implement unfortunately
As I understand nmassflashgen is agnostic regarding the Jetson reference unit from that deployment package is to be created as nvmasflashgen works exclusively with Host PC that knows nothing about Jetson unit package for deployment would need to be done from
But for host PC is it not clear how to create the package so it will work flawlessly on other Jetson units, as it was supposed to be a package created from already working unit, not from Host PC

Did you ever read “README_Massflash.txt” file in your BSP folder?

You should use the online method to generate blob file from device A and this device type should match the other device B,C,D,E… etc. This is the most common way to guarantee that your devices will be flashed with the same BSP.

@WayneWWW Thank you fo ryour reply.
Do you reffer to the readme file that contains the folowing or some other readme file? Coudl you attach the file you are reffering to as reference?

                                 BOARDID  BOARDSKU  FAB  BOARDREV
     jetson-xavier-nx-devkit-emmc     3668     0001      100  N/A
     jetson-nano-devkit-emmc          3448     0002      200  N/A
     jetson-agx-xavier-devkit (16GB)  2888     0001      400  H.0
     jetson-agx-xavier-devkit (32GB)  2888     0004      400  K.0
     jetson-agx-xavier-devkit-8gb     2888     0006      400  B.0
     jetson-tx2-devkit                3310     1000      B02  N/A
     jetson-tx2-devkit-tx2i           3489     0000      300  A.0
     jetson-tx2-devkit-4gb            3489     0888      300  F.0
     jetson-tx1-devkit                2180     0000      400  N/A

Yes, I am referring to that file. There are online and offline method. You should check the online one.