Yes it makes sense. Let’s do the step 2 now.
Do you really understand what I am asking you to do now?
I though that the command without the -r -k APP will overwrite the whole image.raw to the unit, but I guess it reflashed from scratch the unit. So now the unit is in mode as it was after SDK programming, where I need to configure the user name, etc…
Let me recap what I am trying to ask you to do… looks like you toally don’t understand what you are doing now… I don’t care about what was flashed on that board before. What I am asking now is doing the clean setup with below.
If you claim there is an issue with image cloned, then below steps shall give us the error again. But this time you will have more logs to check because we have new console setting in kernel cmdline.
- You flash both jetson TX2, first one on devkit while another one on your custom board. And you shall see both side have this console setting. → Now you are doing this step. Please confirm if console setting is seen.
- Clone the image from devkit case to your custom board with the command you used. Boot up the device and make sure the kernel command line still has these properties. And you shall see the full log.
Is it clear now? I don’t want to tell this again so please ask right now if you still have any question.
No, we do not have the new console configuration, as you don’t tell me which configuration file to modify, and I’ve to modify the configuration files on the without any success.
Unless tyou advise where I should put the keep_bootcon configuration, the only thing that I can do is copy the image from my cloned unit to a new unit and check if the unit boots OK.
Ok, then I have to say the same comment again…
If you are trying to say the kernel command line are not showing up…
I think you should share how you flashed the board and the boot up log so that other people can find out why something can work/cannot work…
I think where you modified the configuration is fine. Actually, I am no jetson god so cannot 100% remember every config file would take effect since I have to take care about every SoC.
Please do share the log file so that we can check why it does not take effect.
I’m sorry but I don’t understand the phrase “how you flashed the board”
This is how I flashed
sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1
all logs are provided during discussion, for eaxmple this is the log on the host:
If this is not what you meant please elaborate.
I mean the boot up log which includes the bootloader log and kernel log as your first comment shared.
What you share during this whole thread is just lots of commands and your description. They are not any kind of log.
Please look at the first message of this discussion there is a terminal log from the unit which is embedded in the message and an uploaded file which is the log from the host during flashing. Which other logs do you have in mind?
I just want to ask
Have you flashed the board with new console setting yet?
No, I do not where to set these settings.
Err… as I said… I think you have modified the correct file p2771-0000.conf.common. That is why I asked you to do the full flash…
But as another previous comment said… if there is something wrong, I need the new log to see why it didn’t take effect. Is it clear now?
Honestly, I don’t expect to teach you as a kid here, so I think you should have the common sense to make some decision by yourself.
OK so I have applied the update in p2771-0000.conf.common as following:
....
ROOTFSSIZE=28GiB;
# CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2”;
CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
target_board=“t186ref”;
...
and applied the flash command
sudo ./flash.sh jetson-tx2 mmcblk0p1
which generated a new image on the host and flashed it to the new unit. This is the log from the unitUnit Terminal with p2771-0000.conf.common modifications.txt (23.2 KB) , BTW I cannot identify the keep_bootcon flag there.
PS, I’ve copied the Image file from the cloned unit to a new unit and the unit was booted OK. The new unit is the one that I’be applied the clearing flash (sudo ./flash.sh jetson-tx2 mmcblk0p1)
Regards.
Looks like it does not take effect.
W> WARN: Fail to override “console=none” in commandline
Please check if flash.sh has console setting too.
@WayneWWW hi,
So, I’ve removed the modification from the p2771-0000.conf.common file, and added the modification to the flash.sh file as following (under the 0x18 tegrad id):
...
elif [ "${target_rootdev}" = "cloning_root" ]; then
if [ "${tegraid}" = "0x21" ]; then
# Nano
CMDLINE_ADD="console=ttyS0,115200n8 sdhci_tegra.en_boot_part_access=1";
elif [ "${tegraid}" = "0x18" ]; then
# TX2
#CMDLINE_ADD="console=ttyS0,115200n8";
CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
elif [ "${tegraid}" = "0x19" ]; then
# Xavier
CMDLINE_ADD="console=ttyTCU0,115200n8";
else
echo "Unknown tegraid/board,exiting..";
exit 1
fi;
...
Then I’ve flashed the unit with:
sudo ./flash.sh jetson-tx2 mmcblk0p1
and the terminal log is following:console none at flash.sh.txt (23.3 KB)
BTW, the modification to the p2771-0000.conf.common file and flash.sh file are applied during the Cboot which is overwritten by the uboot and then overwritten again by the kernel, and I guess that in order to display kernel panic the modification has to take place during kernel boot - which is still a pazzle where it has to be applied.
In the meantime, let me thank you for the continuous support.
Regards.
Looks like cboot rejects the setting again. Let me check what is going on. Will be back later.
It may take time to check since I am not able to reach the jetson now.
Another suggestion here is, if you can upgrade to jetpack4.6, please upgrade.
Even if there is indeed an issue on jetpack4.5.1, we will start the fix/debug on jetpack4.6, since it is the latest release.
Thus, always try the latest release first if possible.
This is incorrect:
What this does is clone the single partition with label “APP”. That partition is the rootfs partition, and all other partitions are used for boot.
There is unfortunately no single command to clone the other content. However, that content is read-only after boot, and you could clone that content via the dd command. Note that this would still leave the content of metadata at the start of the disk uncloned unless you were to dd copy from the first sector to the sector prior to the first known partition sector. Even so, this would not do you much good.
If you flash with the “-r” option, as you are doing, but were to leave out the “-k APP”, then you’d get the rootfs you wanted and the surrounding non-rootfs would be flashed with the “standard” content and should work provided the flash software release is the same release which had produced the rootfs.
If you have any customization of non-rootfs content, then you might consider making those edits or changes on the host PC with the altered content. Then the host PC would flash your altered content instead of the “standard” content.
It should also be noted that those non-rootfs partitions are signed as they are flashed. If signing is incorrect, then boot will be rejected. By default the flash key is NULL, but the content is still signed using that NULL key. If you were to just use a dd copy of a partition content on your host PC, then boot would fail because you’d be getting a signed copy of a signed content (dual signed) instead of a signed copy of just the expected content. dd copies the signing which could be removed.
If your Jetson has the security fuses burned, then the signing uses a secret key which you would have generated, and no NULL signing would boot.
Perhaps one of the biggest “hiccups” would be if you use a third party carrier board. The third party manufacturer would have provided the board support package, and this would in turn have been derived from the standard tools, e.g., flash.sh. You could provide any custom boot content changes in their software instead of from the development kit software, and this should work (the third party would have basically made the changes to the BSP software I mentioned above, and you could make changes to their changes).
Note that the biggest difference between a third party carrier board and a development kit would be the device tree for routing of various configurable pins on the module. It is also possible they added a driver for some extra hardware if it has hardware the dev kit lacks.
Regarding image size, the generated image from flash software will create images only in sizes which are multiples of MiB or GiB. This is for the rootfs only though. I have never tried to clone or flash with sizes which are not MiB or GiB aligned, and I suppose it could be done, but there would also possibly be negative consequences. If you got that exact size of image from a clone, then it is possible this was the actual rootfs size. Can you loopback mount that image? If so, then it is probably a valid image, but I do not know the consequences. Keep in mind that a clone produces both a raw “backup.img.raw” and a sparse “backup.img”, and I am assuming in any loopback mount you are using the raw image, not the sparse image (if your image is sparse, then this could explain why the size was off…it would imply that the sparse image was nearly full since the size approaches the entire partition size). An example of loopback mounting as a test:
sudo mount -o loop /where/ever/backup.img.raw /mnt
# See if anything is there:
ls /mnt
# Unmount:
sudo umount /mnt
It is useful to know that a sparse image from a clone simply labels empty parts of the partition, whereas the raw image actually copies the empty content. If there is no empty content, then the sparse image equals the size of the raw image. If this is the case, then what is the size of your raw clone?
Btw, flash does not care if you use a raw or sparse image, the result is the same. On the other hand you cannot manipulate and examine and work with a sparse image the way you can with a raw image. A raw image can be used to create a sparse image using the mksparse app with a NULL filler byte.
Note: On any system you are developing on always remove the “quiet” tag from the “/boot/extlinux/extlinux.conf” so you get full boot logs.
hi @linuxdev,
I was using the procedure with the APP with r28.2 and it worked fine for multiple duplications per as stated in Jetson/TX2 Cloning - eLinux.org, but let leave it aside.
Let’s make it simple: I have Jet-Packed 4.5.1 a TX2 module on our custom board (no special encryptions), modified a driver and the device tree and finally copied some applications to there. How do I clone this TX2 module to other TX2 modules (modules that were directly received from Nvidia’s factory)?
I am not sure why your comment sounds like you think it is a common bug that everyone would hit this.
How do I clone this TX2 module to other TX2 modules (modules that were directly received from Nvidia’s factory)?
Actually, I feel your issue is just due to your custom board.
You said there is “modified driver” and “device tree”. But did you ever clone these things from the first module to the second module that runs on custom board?
Also, if you need modified driver and device tree, then why it sounds like sdkmanager can work on your board according to your previous comment? Which one is true?