0

I have an image (more specifically a wic image for those who are familiar with Yocto framework) that contains a partition table along with its 4 partitions. It's size is bit less than 1GB.

In order to write this image to the eMMC:

  • I first load it to RAM through TFTP
=> tftp 0x600000000 <image>.wic
  • Then I write the image from RAM to the eMMC
=> mmc write 0x600000000 0x0 0x1FFFFF
  • The image gets written correctly and I can list the 4 partitions. So far, so good.
=> mmc part

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000800      0x0000681f      "boot"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cd5df8ce-ded3-4cf4-b364-33d7a4b24953
  2     0x00006820      0x000139e7      "first"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   3acc4557-2273-462a-a2bd-d130b3a5745d
  3     0x00014000      0x000fefff      "second"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   efe25a87-e0ba-401e-8bf6-e81ae29cbc35
  4     0x000ff000      0x001e9fff      "third"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   150f9151-7710-42f4-b819-3b3bd506a2bf

Now I want to duplicate the image in the eMMC so that I end up with 8 partitions like so:

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000800      0x0000681f      "boot"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cd5df8ce-ded3-4cf4-b364-33d7a4b24953
  2     0x00006820      0x000139e7      "first"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   3acc4557-2273-462a-a2bd-d130b3a5745d
  3     0x00014000      0x000fefff      "second"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   efe25a87-e0ba-401e-8bf6-e81ae29cbc35
  4     0x000ff000      0x001e9fff      "third"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   150f9151-7710-42f4-b819-3b3bd506a2bf
  5     0x00000800      0x0000681f      "boot"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cd5df8ce-ded3-4cf4-b364-33d7a4b24953
  6     0x00006820      0x000139e7      "first"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   3acc4557-2273-462a-a2bd-d130b3a5745d
  7     0x00014000      0x000fefff      "second"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   efe25a87-e0ba-401e-8bf6-e81ae29cbc35
  8     0x000ff000      0x001e9fff      "third"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   150f9151-7710-42f4-b819-3b3bd506a2bf

So I write again the same image to eMMC with an offset (to not override the existing one)

=> mmc write 0x600000000 0x200000 0x3FFFFF

MMC write: dev # 1, block # 2097152, count 4194303 ... 4194303 blocks written: OK

However, I don't get the 8 partitions I was expecting but only 4 partitions:

=> mmc rescan
=> mmc part

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000800      0x0000681f      "boot"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cd5df8ce-ded3-4cf4-b364-33d7a4b24953
  2     0x00006820      0x000139e7      "first"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   3acc4557-2273-462a-a2bd-d130b3a5745d
  3     0x00014000      0x000fefff      "second"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   efe25a87-e0ba-401e-8bf6-e81ae29cbc35
  4     0x000ff000      0x001e9fff      "third"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   150f9151-7710-42f4-b819-3b3bd506a2bf
Rachid K.
  • 4,490
  • 3
  • 11
  • 30
nader
  • 49
  • 9
  • I am curious though: was repairing the partition table using `testdisk` successful ? Because the thing that I realized is that each partition has a unique GUID identifier. And so I guess that If you duplicate your partitions you would have duplicate GUID as well, which could cause some issues. Or maybe `testdisk` was able to assign new partition GUID ? – Victor Deleau Jan 31 '20 at 15:04
  • 1
    I haven't tried `testdisk` yet, but I accepted your answer because it helped me understand the root cause of my problem. I will try to fix my partition table using ´testdisk´ or another tool and come back to you :) – nader Jan 31 '20 at 15:15
  • @VictorDeleau I tried testdisk and I was able to change the geometry of my disk image and double the number of cylinders. That resulted in doubling the image size, which is expected. I wrote this image on the eMMC, then i wrote another image at an offset but I was only able to see 4 partitions and not 8 partitions. I guess I need to change the geometry of my disk image AFTER it has been written to the eMMC in order for that to work. And since I am working in a u-boot environment (and not linux), this complicates the stuff because I would need to do manual modification of the eMMC memory.. – nader Feb 13 '20 at 08:08
  • @VictorDeleau ..not to mention having to recalculate the CRC32 and re-inject it into memory which could be a hassle. Nevertheless, testdisk was quite useful in gaining more insight to my problem and it was relatively easy to use. My new approach is trying to use uboot command line "gzwrite" wich is able to uncompress an 8 partitions image from RAM to eMMC, bypassing RAM size limitation. – nader Feb 13 '20 at 08:12

1 Answers1

1

When you write an image that contains one or more partitions, you also write the partition table, which is expected to be at some offset or your memory by u-boot (according to this post it must be 0x60000000). So if you write your image again somewhere else, u-boot will still refer to the partition table from your first writing operation, which itself contains the memory address of your first 4 partitions. Your second partition table is somewhere else on the disk, but u-boot doesn't know.

You can try to repair the partition table using the testdisk command line utility. It will scan the whole disk and hopefully it will find that there is 8 partitions in total, and create a new partition table at 0x60000000 that refers to all of them.

Victor Deleau
  • 875
  • 5
  • 17