Nvmassflashgen cloned partition won't boot on other units

If you are refering to the file I previously copied the fragment from then I have read it multiple times before but I do not have it at hands right now.
Could you extend which steps are requiredto start with the online method? Still you maybe could attach the txt as the reference, please?

hello Andrey1984,

I think the problem is you have cloned partition for your use-case, which we don’t fully test this part so far.

could you please confirm…
by using the cloned image, you’re able to enable flash.sh to deploy the release image to other platforms.
also, without the cloned image, the massflash script able to create the mfi package and able to flash other platforms successfully, right?

I’m still not clear which step you’ve overwrite the cloned image, could you please use the cloned image to create mfi package; you may also share the commands and also the output logs for reference,
thanks

Hi @JerryChang Thank you for following up!
How is it going?
Exactly.
What I was able to do is to do APP clone then restore it wither with flash.sh or with nvmflash.gen after fusing with other MFI package provided by vendor[that doesn’t have some drivers still that is why restoring of APP from cloned image is used to fill the gaps]
But no nvmassflash script can not generate any package at all as it doesn’t read from Jetson but from HOST PC

by using the cloned image, you’re able to enable flash.sh to deploy the release image to other platforms.

Yes, true positive
2. 

also, without the cloned image, the massflash script able to create the mfi package and able to flash other platforms successfully, right?

No, true negative

The problem is that generated by nvmassflashgen MFI package is generated from Host PC exclusively it does know nothing about custom carrier board drivers so it won’t flash in any booteable manner

If you use the custom board config when you generate massflash blob, will it be able to work?

I remember that ConnectTech provides their own board config file in Linux_for_Tegra.

@WayneWWW
Thank you for following up.
I am not sure regarding the blob terminology
I would have to check with referenced by you readme file probably to get it.
However, if you have it at hands you could share it perhaps.
IF under blob you mean the mfi package then it creates , but doesn’t address any custom carrier board specificity.
If under blob you imply meaning of something else it is difficult to understand without procuring the mentioned txt readme file refrenced by you earlier probably, so if you have it you could post it maybe as attachment?

The complication is the unit used is a product of multiple vendors [ at least 3] so while it is syslogic it is based on connecttech but also uses third layer setup. So I am just considering it as Black box custom carrier board Jetson device with installed functioning OS that needs to be deployed to other devices from a reference unit

Blob just means the mfi package.

the problem with mfi package is that it just uses Host PC
when mfi is created no Jetson information is read
that is the problem because from Host PC it can only do a blob [mfi] for devkit unit using the default sources? probably?
but for customizing the default sources I do not know how to do it exactly
Though I have a mfi package from intermediatory vendor that kind of works but I need to get it customized

Maybe you should reply this thread when you are able to access the BSP and the board.
It sounds like all your comment today are just guessing and some unclear descriptions. Which really has no help.

Please stop guessing or asking us to help you at this moment. I really don’t have anything to share here.

Just do the experiment with your board when you have time. Share the log to us.

Some information like below are not necessary. I don’t want to know that and it does not provide any useful information either.

The complication is the unit used is a product of multiple vendors [ at least 3] so while it is syslogic it is based on connecttech but also uses third layer setup

Thank you for following up
During last three weeks I used to do flashing / package creation attempts like 30-40 times in various configurations.
If the situation changes or I have more logs I will reply to the thread again

The real problem here is you don’t really provide any useful information. Only thing I know is

  1. You are using a custom board

  2. You use “./nvmassflashgen.sh jetson-xavier mmcblk0p1” to flash the board and you said “it won’t boot”.

  3. Now you said “it won’t flash”.

Something like “30-40 times in various configurations.” has 0 information. What should I say about that? Even a log can provide more info than this.

Also, I am not sure why you use “jetson-xavier” here. It means you are referring to “jetson-xavier.conf” in your BSP. By default, this board config is only for jetson xavier devkit. I don’t think it will directly work on custom board. You should ask the custom board vendor to provide their own board confg.

That was why I asked do you have knowledge about how flash.sh works. Because flash.sh should use the same board config as nvmassflash.

@WayneWWW
Thank you for your reply

  1. yes, using custom carrier board
  2. yes, nvmassflashgen was used, but nvmassflashgen doesn’t flash a device but creates mfi package. Then after creating mfi package units can be flashed with nvmflash.sh. The flashing completes but from devkit image the unit won’t boot.[unless it is a devkit unit]
  3. no it meant that the flashing completes, but unit won’t boot.
    When using flash.sh we used custom cloned APP partition with flash.sh menthod only. The unit would boot using it. The rest was addressed by prior application by nvmflash.sh with vendors package

What is the exact command that you use to flash this custom board with flash.sh?

with flash sh there is no issue flashing the carrier board using the APP clone command

sudo ./flash.sh -r -k APP jetson-xavier mmcblk0p1

Are you doing all these works under the package that the vendor provides to you? As I said, original board config “jetson-xavier.conf” only works with devkit.

Can you share me the board config of your “jetson-xavier”?

Are you doing all these works under the package that the vendor provides to you?

Yes. I think I managed to fuse cloned custom APP partition into the MFI provided by vendor so it works with nvmflash.sh

Can you share me the board config of your “jetson-xavier”?

could you point out where exactly to find the board config files, please? are they within MFI package? or need to be read from the Jetson unit ?

Now it has a MFI package provided by the vendor??? Seriously, I really don’t know what you are doing.

The board config just under the Linux_for_Tegra. That “jetson-xavier” indicates “jetson-xavier.conf”. I already told this two times. Is it really that hard to understand?

If I create a file 123456.conf under Linux_for_Tegra, then I can use command “sudo ./flash.sh 123456 mmcblk0p1” to flash board.

Is it more easier to understand now?

the vendor did not supply Linux for tegra folder
only MFI package that is not customized
the MFI package doesn’t have jetson-xavier.conf
However, thank you for your response.
I got to the office so checking more thoroughly right now

I am not sure why your vendor provides you MFI package. If you still have any problem with their MFI package, please consult with the vendor.

The MFI package from them only proves that our tool also supports the custom carrier board because your vendor is most likely also using the same massflashgen tool from our default BSP.

problem is not with MFI from the vendor
problem is with doing a deployable MFI package in place from customized Jetson that has been flashed already then customized with adding extra drivers from next vendor in the vendor chain[ as there are at least three manufactureres/vendors engaged]

Yes, check the readme file first when you can access the board. I guess you are just trying the offline method so you told me the host cannot know the board.
Also, just share the commands, and log next time. That is the real info we need.