Getting GPT from Jetpack 4.4

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.

Taking one point at a time:

Then wrote all of my images with APP partition too…

If you did this while the rootfs filesystem was mounted, you’ve probably taken an inconsistent snapshot and ext4 will likely want to repair it on the next mount. dd’ing a block device should only be done when the filesystem on it is not mounted, or at most mounted read-only.

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’m not writing the APP partition directly because that’s the rootfs and it will be mounted in the running kernel. You can’t safely DD a block device whose filesystem is mounted and writeable. That’s why I’m saying you’ll need to use something like takeover or pivot_root to allow your kernel to switch to a different init process and rootfs to give you a chance to dd the new APP partition. If you don’t do this, you’ll likely overwrite blocks on the disk which the filesystem/kernel expects not to change from under it, and this will likely cause an eventual kernel panic (e.g. the live kernel might sync/flush cached pages into blocks that now no longer correspond to those pages in the new version of the filesystem).

In my post, what I do instead of dd’ing the whole block device is keep the original rootfs filesystem in place, and make changes to all the package versions etc. via apt dist-upgrade and swap the kernel/boot/Image manually. This avoids a need for a pivot_root and should ultimately be less risky, as dd of ~16GB could fail at any time and will definitely result in a bricked device, whereas a failed apt dist-upgrade can probably be retried if the system is still booted.

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 ?

Because you shouldn’t dd a partition with a mounted filesystem, and because you can’t unmount the rootfs without providing an alternative rootfs (the kernel and broader OS needs a rootfs). This is why the pivot_root syscall exists. The new rootfs is a tmpfs because you don’t have any free disks to use, so you can use a ram disk. The OS needs aprocfs (/proc),dev-tmpfs(/dev), sysfs (/sys) to continue to control the hardware, so these need to be mounted into the new rootfs before the pivot_root and unmounting of mmcblk0p1. The init process binary (systemd) will be on the old rootfs and so will need to be swapped too. takeover.sh handles most of this, but you can read what it does and try it yourself.

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.

You don’ t need to patch the kernel on Jetpack 3.3, only on Jetpack 3.0 (3.10.96), and as I’ve mentioned in my original post:

In the case of R24.2.1, the kernel (3.10.96-tegra) doesn’t expose the mmcblk0boot0 and mmcblk0boot1 devices unless patched with the below

  • 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.

Are you sure about what your boot chain is here? This sounds like the early stage BCT + bootloader chain (NVTBoot → CBoot → UBoot) are still on the eMMC not the SD card, and so you haven’t actually replaced the boot chain like you thought (or the boot chain is attempting to launch kernel from a non-existent SD card). It’s probably worth reviewing the early stage bootloader logs via UART to see exactly what’s going on.

The BCT and early stage bootloaders are on the mmcblk0boot0/mmcblk0boot1 block devices. If device B is booting from an SD card, the BCT for that setup will be totally different, and you won’t be able to simply copy it onto the eMMC device and expect it to work. You’d need to create a new set of BCT images from a 4.4 device whose boot chain is configured to boot kernel from eMMC instead.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.