This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Cannot clone Android GPT-partitioned sdcards

Other Parts Discussed in Thread: 4460

Setup
---
I use a flash card duplicator to duplicate a 8GB master sdcard containing 11 partitions GPT-partitioned for Android-4.0.4 (ext4, fat32, and x-loader, u-boot). This master sdcard is copied to 20 slave cards. The duplicator machine copies and compares, i.e. checking that slave data are correct.

Problem
---
Some slave sdcards boot correctly on target device. Some do not at all. The x-loader is not even executed (no UART printouts).

What did I try?
---
1. I disregarded the last 512MB of the card to deal with disparity in card sizes. I mean I reduced the 11th partition (userdata) by 512MB in u-boot (board/omap4.../mmc.c > do_format()). That way I am sure data fits in any sdcard. Some slave sdcards still fail though.
2. [GPT table header][1] is present in two places: After the protective-MBR, on the second block (current LBA) and at the last block of the device (backup LBA). In my example, the last block

My question
-----------
1. Does the OMAP4460's ROM code make a sanity check of the GPT before executing x-loader?
2. Does the x-loader make a sanity check of the GPT partition table before printing anything on the console? By reading lib/board.c > *init_sequence, it seems not. Here, you state that the secondary GPT is not used on older chipsets.
3. Using this sdcard duplicator is key to save time in production. Would it be a good idea to reduce number of blocks in u-boot/board/omap4.../mmc.c > do_format() to deal with that problem (disregard the waste of space...)?


[1]: http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_.28LBA_1.29

  • In OMAP 4460 TRM chapter 27 it is described the boot process, in section "27.4.7.6 eMMC/eSD Embedded Memories and MMC/SD Cards" it is described the process to boot from memory, in other sections of the chapter there are other interesting readings, in the mentioned section you can find the different combinations to use fat16 or fat32, and if the mmc has different fats it indicates which one is used, and it described the process to check if it is from fat16 and what process it used, or fat32 that requires a boot flag to be set and that the partition has certain characteristics.

    What I can think is that the used program to clone the images could be missing one of this flags or sectors, depending on the used configuration.

    By reading your post again, I can think in next possible issue.

    In section "27.4.7.6 eMMC/eSD Embedded Memories and MMC/SD Cards" it is mentioned that ROM fat code uses only four partition entries this for compatibility with Windows systems, that means using 11 partitions in the Linux way where the restriction to use only 4 primary partitions doesn't apply. For Windows Systems it is possible to use more partitions but it requires the use of a extended partition to add the rest of the partition. I didn't read it ROM code supports extended partition or not,  it seems not in the TRM it only mentions that has only 4 partition entries to work, the max I have tried are 8 partitions. TRM indicates too the process that is followed to identify the partition and it's format.

  • Hi Manuel,

    Thanks for pointing the right page in the TRM, I will have a look at it.
    I found out a way around my issue: in u-boot / fastboot code, do_format() checks the number of blocks of the MMC device. I artificially reduced this number, to make sure that fastboot does not write data on the last blocks. Then slave MMC with smaller capacity (less blocks) will be able to clone the master MMC perfectly.
    It works :-)

    Thanks,
    Emeric