Hello,
Device with jetpack version 3.3 = device A
Device with jetpack version 4.4 = device B
I took the image of device B and tried to write it onto device A for my university graduation project with the command below:
sudo dd if = /sdcard_address… of=/mmcblk_address… status = progress bs = 4M && sync
this command takes my image and tries to write it onto device’s mmcblk but their GUID partition tables are different from each other. I tried to copy GPT and “sudo dd” the device but it didn’t work can you help me to update my device A with the image of device B.
I used the link I found in the forum but it’s a bit different than my problem:
Remote TX1/TX2 OTA upgrade from Jetpack 3.0 to Jetpack 4.4.1 - Jetson & Embedded Systems / Jetson TX1 - NVIDIA Developer Forums
That post should contain everything you need. You can write the GPTs with sgdisk - you’ll need to copy over the bootloader devices too (mmcblk0boot0 and mmcblk0boot1).
If you’re attempting to do this on an already booted device, you won’t be able to write the rootfs partition without unmounting it (pivot_root?).
Since my mother tongue is not English I might have understand wrong, I apologize for misunderstanding.
I have 2 devices each of them works fine but one of them with jetpack 3.3 the other one is with jetpack 4.4.
They both have no internet connection available and I can only access them via SSH connection.
The problem is that I took my image from jetpack 4.4 and then tried to set it up for the other device. I transfer them with my SD card.
In the link below as far as I understand there is some steps which requires internet connection. I ignored those steps but I couldn’t quite understand which steps are important for me. I am doing steps as follows;
1- Getting image from the device with jetpack v4.4 (I have 2 image 1 with .img extension the other one with .img.raw)
2- doing sudo sgdisk --backup=$path_to_gpt.bin_file /dev/SDcard
3- I connect device J3.3 and transfer files in it’s SD card
After running the commands below it says CRC doesn’t match (also some warnings) and the mmcblk view doesn’t change.
4- sudo sgdisk $path_to_gpt.bin_file /dev/SDCard
5- sudo partprobe -s /dev/mmcblk0
6- sudo dd if=img_path of=mmcblk_path bs=4M status=progress && sync (writing my image)
As it comes around %85-90 my connection goes down and I can not create new SSH connection. Also, I can not run any command in it. Always says Segmentation Fault because its GPTable doesn’t same with the device with jetpack 4.4.
My problem can be explained like this and I also want to ask one more question too. If I successfully change the GPT table of the device with jetpack v3.3 would I still connect it with SSH? or would I be kicked ? If I will be kicked once changing the GP Table I can create a service file and it runs when I’m not there. Does that makes sense ?
If you’re transferring the image files via physically swapping an SD card, why can’t you reflash the 3.3 device over USB given that you have access to it?
Just to be clear, are both devices booting and running from eMMC, and you’re using the SD card to move stuff between them?
Do the two devices have the same sized rootfs partition (/dev/mmcblk0p1)?
To do what you want, you’ll need to:
Make an ext4 filesystem on the SD card
- Copy the GPT table from the 4.4 device into a file, and put that on the SD card
- Copy each
mmcblk0 partition from the 4.4 device into files, and put them on the SD card
- Copy the
mmcblk0boot0 and mmcblk0boot1 partitions into files, and put them on the SD card
- Plug the SD card into the 3.3 device
- On the 3.3 device, mount a new
tmpfs rootfs, proc, dev-tmpfs and sysfs, then pivot_root into the new root to allow you to unmount mmcblk0p1. You can use a tool like takeover to do this and manage the swapping of the init process etc.
- After the
pivot_root, you should be able to write the sgdisk partition table, partprobe, and copy the data and bootloader partitions over.
If your rootfs partition is the same size between 3.3 and 4.4, you can bypass the (risky) pivot_root step and keep the rootfs partition the same, and manage the upgrade via an apt dist-upgrade (first --download only on a machine with internet, then copy the .deb files into the right place on the 3.3 deviec, then do the dist-upgrade).
My device that has Jetpack 3.3 on it has a gpt table like the one below.
mmcblk0boot0
mmcblk0boot1
mmcblkrpmb 0 byte in each devices
mmcblk0
-mmcblk0p1
-…
-mmmcblk0p29
mmcblk1
-----sd card
the other device that has jetpack 4.4 on it has a table like the one below.
mmcblk0boot0
mmcblk0boot1
mmcblkrpmb 0 byte in each devices
mmcblk0
-mmcblk0p1
-…
-mmmcblk0p33
mmcblk2
-----sd card
around 6 or 7 type loop disks (I am not sure if they are even disks.)
What I tried is simply copying EMMC to SD card and then change /etxtlinux/extlinux.conf file and boot from SD card. This works well but when I delete EMMC while OS running on SD card system does not reboot. When I flash EMMC with new OS it boots from SD Card. This is one of my problem and I couldn’t find the reason under the hood.
I also tried to copy gpt table on jetpack 4.4 and write it on to emmc card. After preparing its partition table properly. I wrote my jetpack 4.4 image on to the prepared partition table and change the extlinux.conf file on the OS that runs on SD card. But it constantly reboots itself and never opens up. I also can’t sudo dd the mmcblk0boot0 and mmcblk0boot1.
Now I have managed to copy SD card of jetpack 4.4 and write it on to Device Jetpack 3.3’s emmc.
Then wrote all of my images with APP partition too…
I also can sudo dd the mmcblk0boot0 and mmcblk0boot1 with sudo /bin/bash -c ‘echo 0 > /sys/blocks/mmcblk0boot0&1/force_ro’
After that I made them read only again.
But in the link I provided you (eh-steve) did not sudo dd the APP partition. Instead of that you’re doing something different which I could not understand. Can you provide me more details please. I am having trouble to patch my kernel.
Why do we patch ? Won’t it accept when I just simply sudo dd my boot0&1 images.
I also could not understand the part you say:
- On the 3.3 device, mount a new
tmpfs rootfs, proc, dev-tmpfs and sysfs, then pivot_root into the new root to allow you to unmount mmcblk0p1. You can use a tool like takeover to do this and manage the swapping of the init process etc.
Why do I need it and how can I do that ?
Lastly, one of my question stands still.
- What I tried is simply copying EMMC to SD card and then change /etxtlinux/extlinux.conf file and boot from SD card. This works well but when I delete EMMC while OS running on SD card system does not reboot. When I flash EMMC with new OS it boots from SD Card. This is one of my problem and I couldn’t find the reason under the hood.