I use Jetpack 3.1 for TX1 now. and
if I rebuild the jetpack 3.1 source code and dtsi file.Does it Must use the USB cable to re-flashing OS?
I use Jetpack 3.1 for TX1 now. and
Flashing must use the micro-B USB cable. In some cases there are device tree changes you can get around using dd, but if you can use flash you are better off (and if the dd goes wrong you’ll need the USB cable to re-flash anyway).
What is the “using dd”?
“dd” is a tool for raw writing of data to a disk…a bit-for-bit image instead of a file. Partitions and binary images can be copied this way. A common example is that a CD/DVD-ROM may have a file system type of ISO9660…if one copies files it must be first mounted and support for the file system type is required…with dd the “image” could be copied and result in a copy of the actual bits without regard for what the file system contains. Basically a bit clone tool.
Every flash is essentially the equivalent of a remote controlled dd…the recovery mode Jetson is essentially a “smart” version of a dd tool which the driver package can use to copy bytes with. On a running system, if the data is not changing, then it may be possible to do the equivalent with dd. There are a lot of possibilities for failure which would leave the system unable to boot when doing this. Should this happen you no longer have dd available because it requires the system to successfully boot.
One could use the flash.sh script to write the partition containing the device tree for a device tree update. If this fails, you would simply flash again.
You could use dd from a running Linux to write the device tree partition as well since this partition is not changing…the partition is read and loaded into memory prior to the Linux kernel taking over. The requirement of the data not changing while you use it is satisfied, but a failure during the operation (or from the device tree being invalid) implies boot would no longer work.
You could not use dd to back up or restore the root partition while it is mounted and in use…results would likely be corrupt or not reliable. You could boot to an alternate rootfs on SD card, and then the version running from SD card could safely dd copy or write the rootfs of the eMMC since this meets the requirement of the partition not changing during access.
The correct partition for the device tree changes with release version, and there are in fact multiple places where device tree might be present. U-Boot itself (and the boot process in general prior to Linux loading) may have some hardware setup needs, and those needs may be set up with a separate device tree subset prior to loading the full device tree (the Linux kernel uses the full device tree). The flash.sh script knows about these finer divisions, plus it deals with differences between various L4T versions, so this is the safe way of updating.
If you are using R28.2 and a TX2, then you would see from “gdisk -l /dev/mmcblk0” that there is a DTB partition, number 14. If you wanted to back this up you could do this:
sudo dd if=/dev/mmcblk0p14 of=partition14_backup.bin bs=512
You could even reverse compile this binary file and verify what is in its tree:
dtc -I dtb -O dts -o extracted_version.dts partition14_backup.bin
You could edit the extracted dts, convert it back to dtb format, and then dd it back to partition 14 (assuming the dtb still fits in the size of the partition):
# ...edit something... dtc -I dts -O dtb -o updated_version.dtb dd if=updated_version.dtb of=/dev/mmcblk0p14 bs=512 # Hope it works, reboot.
When you flash you are updating many partitions…not just the rootfs. These partitions all need to work together. Should your dd update fail in just one place and you reboot, then you will no longer be able to boot without the USB cable flash. If you don’t have that ability you shouldn’t mess with dd…and if doing a full release change, then you shouldn’t use dd for the method anyway.
There are cases where changing the device tree for the stage where the Linux kernel takes control in which dd is reasonably safe as a method of flash for just that partition. The trouble is that if your dtb is not correct then you are still back in the “can no longer boot without flash” category. You have to be confident that not only do you know how to use dd, you also must be confident that your device tree is guaranteed to be correct.
If you’re just making kernel changes you can copy the new Image to /boot/ on the board. Don’t do that if you’re changing between l4t version, only if you’re recompiling the kernel with different options and want to do a fast update.
You can also flash just the dtb without wiping the entire board, but you still need the usb-cable.