fastboot: handle flash write to GPT partition

PATCH New Steve Rae 3 participants 6 messages Dec 4, 2014 – Dec 9, 2014

Share & tools

Steve Rae

author

2014-12-04 22:36 UTC #0 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.

Signed-off-by Steve Rae <[email protected]>

---

 README          |  7 +++++++
 common/fb_mmc.c | 19 ++++++++++++++++---
 2 files changed, 23 insertions(+), 3 deletions(-)

README +7 -0

index 66770b6..3b6ef7f 100644
@@ -1769,6 +1769,13 @@ The following options need to be configured:
 		regarding the non-volatile storage device. Define this to
 		the eMMC device that fastboot should use to store the image.
 
+		CONFIG_FASTBOOT_GPT_NAME
+		The fastboot "flash" command supports writing the downloaded
+		image to the Protective MBR and the Primary GUID Partition
+		Table. This occurs when the specified "partition name" on the
+		"fastboot flash" command line matches this value.
+		Default is GPT_ENTRY_NAME (currently "gpt") if undefined.
+
 - Journaling Flash filesystem support:
 		CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, CONFIG_JFFS2_NAND_SIZE,
 		CONFIG_JFFS2_NAND_DEV

common/fb_mmc.c +16 -3

index fb06d8a..89fbf23 100644
@@ -4,12 +4,17 @@
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
+#include <config.h>
 #include <common.h>
 #include <fb_mmc.h>
 #include <part.h>
 #include <aboot.h>
 #include <sparse_format.h>
 
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
 /* The 64 defined bytes plus the '\0' */
 #define RESPONSE_LEN	(64 + 1)

@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t *info,
 void fb_mmc_flash_write(const char *cmd, void *download_buffer,
 			unsigned int download_bytes, char *response)
 {
-	int ret;
 	block_dev_desc_t *dev_desc;
 	disk_partition_t info;
+	lbaint_t blksz;
 
 	/* initialize the response buffer */
 	response_str = response;

@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void *download_buffer,
 		return;
 	}
 
-	ret = get_partition_info_efi_by_name(dev_desc, cmd, &info);
-	if (ret) {
+	if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+		printf("%s: updating GUID Partition Table (including MBR)\n",
+		       __func__);
+		/* start at Protective MBR */
+		info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA - 1);
+		blksz = dev_desc->blksz;
+		info.blksz = blksz;
+		/* assume that the Partition Entry Array starts in LBA 2 */
+		info.size = (2 + (GPT_ENTRY_NUMBERS * GPT_ENTRY_SIZE) / blksz);
+	} else if (get_partition_info_efi_by_name(dev_desc, cmd, &info)) {
 		error("cannot find partition: '%s'\n", cmd);
 		fastboot_fail("cannot find partition");
 		return;

Signature · 1 line

1.8.5

Marek Vasut

2014-12-06 13:00 UTC #1 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

Quoted 5 lines · Steve Rae

Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.
Signed-off-by Steve Rae <[email protected]>

Lukasz, what do you think please ?

In my option, there's nothing really explicitly problematic:

Reviewed-by Marek Vasut <[email protected]>

Best regards,
Marek Vasut

Lukasz Majewski

2014-12-08 11:24 UTC #2 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

Hi Marek,

Quoted 8 lines · Steve Rae

Quoted 5 lines
Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.
Signed-off-by Steve Rae <[email protected]>
Lukasz, what do you think please ?

I've just commented to this e-mail.

Quoted 7 lines

In my option, there's nothing really explicitly problematic:
Reviewed-by Marek Vasut <[email protected]>
Best regards,
Marek Vasut

BTW: Marek, do you plan to send USB PR to Tom in a near future?

Signature · 5 lines

Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Lukasz Majewski

2014-12-08 11:21 UTC #3 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

In reply to Steve Rae

Hi Steve,

Quoted 85 lines

Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.

Signed-off-by Steve Rae <[email protected]>

---

 README          |  7 +++++++
 common/fb_mmc.c | 19 ++++++++++++++++---
 2 files changed, 23 insertions(+), 3 deletions(-)

README +0 -0

index 66770b6..3b6ef7f 100644
@@ -1769,6 +1769,13 @@ The following options need to be configured:
 		regarding the non-volatile storage device. Define

this to the eMMC device that fastboot should use to store the image.

README +2 -0

+		CONFIG_FASTBOOT_GPT_NAME
+		The fastboot "flash" command supports writing the

downloaded

README +1 -0

+		image to the Protective MBR and the Primary GUID

Partition

README +1 -0

+		Table. This occurs when the specified "partition

name" on the

README +2 -0

+		"fastboot flash" command line matches this value.
+		Default is GPT_ENTRY_NAME (currently "gpt") if

undefined. +
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV

common/fb_mmc.c +14 -3

index fb06d8a..89fbf23 100644
@@ -4,12 +4,17 @@
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
+#include <config.h>
 #include <common.h>
 #include <fb_mmc.h>
 #include <part.h>
 #include <aboot.h>
 #include <sparse_format.h>
 
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
 /* The 64 defined bytes plus the '\0' */
 #define RESPONSE_LEN	(64 + 1)

@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
 *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const char
 *cmd, void *download_buffer, unsigned int download_bytes, char
 *response) {
-	int ret;
 	block_dev_desc_t *dev_desc;
 	disk_partition_t info;
+	lbaint_t blksz;
 
 	/* initialize the response buffer */
 	response_str = response;

@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void
 *download_buffer, return;
 	}
 
-	ret = get_partition_info_efi_by_name(dev_desc, cmd, &info);
-	if (ret) {
+	if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+		printf("%s: updating GUID Partition Table (including
 MBR)\n",
+		       __func__);
+		/* start at Protective MBR */
+		info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA - 1);
+		blksz = dev_desc->blksz;
+		info.blksz = blksz;
+		/* assume that the Partition Entry Array starts in

LBA 2 */

common/fb_mmc.c +1 -0

+		info.size = (2 + (GPT_ENTRY_NUMBERS *

GPT_ENTRY_SIZE) / blksz);

common/fb_mmc.c +1 -0

+	} else if (get_partition_info_efi_by_name(dev_desc, cmd,

&info)) { error("cannot find partition: '%s'\n", cmd);

common/fb_mmc.c void fb_mmc_flash_write(const char *cmd, void *download_buffer, · line 96

Quoted 2 lines

common/fb_mmc.c +0 -0

 		fastboot_fail("cannot find partition");
 		return;

Sorry for a late reply. I've just come back from a short holidays.

I'm curious if you have encountered any problems with GPT replaced in that way?

It seems strange to me that you only change primary GPT partition without taking care of the secondary (backup) one.

From my experience when you export your eMMC to Host PC via UMS, host's PC tools will complain about mismatch in the GPT tables.

Moreover, I would suggest transactional update of GPT by checking GPT image CRC before writing. In this way you can always perform recovery if needed.

Signature · 5 lines

Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Steve Rae

author

2014-12-08 18:21 UTC #4 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

Hi Lukasz,

Quoted 92 lines · Lukasz Majewski

Hi Steve,

Quoted 84 lines

Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.

Signed-off-by Steve Rae <[email protected]>

---

  README          |  7 +++++++
  common/fb_mmc.c | 19 ++++++++++++++++---
  2 files changed, 23 insertions(+), 3 deletions(-)

README +0 -0

index 66770b6..3b6ef7f 100644
@@ -1769,6 +1769,13 @@ The following options need to be configured:
  		regarding the non-volatile storage device. Define

this to the eMMC device that fastboot should use to store the image.

README +2 -0

+		CONFIG_FASTBOOT_GPT_NAME
+		The fastboot "flash" command supports writing the

downloaded

README +1 -0

+		image to the Protective MBR and the Primary GUID

Partition

README +1 -0

+		Table. This occurs when the specified "partition

name" on the

README +2 -0

+		"fastboot flash" command line matches this value.
+		Default is GPT_ENTRY_NAME (currently "gpt") if

undefined. +
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV

common/fb_mmc.c +14 -3

index fb06d8a..89fbf23 100644
@@ -4,12 +4,17 @@
   * SPDX-License-Identifier:	GPL-2.0+
   */
 
+#include <config.h>
  #include <common.h>
  #include <fb_mmc.h>
  #include <part.h>
  #include <aboot.h>
  #include <sparse_format.h>
 
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
  /* The 64 defined bytes plus the '\0' */
  #define RESPONSE_LEN	(64 + 1)

@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
 *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const char
 *cmd, void *download_buffer, unsigned int download_bytes, char
 *response) {
-	int ret;
  	block_dev_desc_t *dev_desc;
  	disk_partition_t info;
+	lbaint_t blksz;
 
  	/* initialize the response buffer */
  	response_str = response;

@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void
 *download_buffer, return;
  	}
 
-	ret = get_partition_info_efi_by_name(dev_desc, cmd, &info);
-	if (ret) {
+	if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+		printf("%s: updating GUID Partition Table (including
 MBR)\n",
+		       __func__);
+		/* start at Protective MBR */
+		info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA - 1);
+		blksz = dev_desc->blksz;
+		info.blksz = blksz;
+		/* assume that the Partition Entry Array starts in

LBA 2 */

common/fb_mmc.c +1 -0

+		info.size = (2 + (GPT_ENTRY_NUMBERS *

GPT_ENTRY_SIZE) / blksz);

common/fb_mmc.c +1 -0

+	} else if (get_partition_info_efi_by_name(dev_desc, cmd,

Quoted 3 lines

&info)) { error("cannot find partition: '%s'\n", cmd);
fastboot_fail("cannot find partition"); return;

Sorry for a late reply. I've just come back from a short holidays.

Quoted 2 lines

I'm curious if you have encountered any problems with GPT replaced in that way?

No -- this "technique" seems to be fine (for the Primary GPT)....

Quoted 3 lines

It seems strange to me that you only change primary GPT partition without taking care of the secondary (backup) one.

It seems that the device operates correctly with or without the Backup GPT, and it doesn't seem to matter if they are the same or not. Thus, we have gone back and forth on this one - should we automatically update the Backup GPT whenever the Primary GPT is updated, or should there be a second step (possibly a "fastboot oem" command) to update the Backup GPT... (currently, we are proposing the latter)
What would you suggest?

Quoted 3 lines

From my experience when you export your eMMC to Host PC via UMS, host's
PC tools will complain about mismatch in the GPT tables.

( I have never done this - what tools are you using? Could you provide instructions for me to try? Thanks! )

Quoted 4 lines

Moreover, I would suggest transactional update of GPT by checking GPT image CRC before writing. In this way you can always perform recovery if needed.

This is a good idea - I'll look into it - Thanks!

Quoted 1 line

Thanks, Steve

Lukasz Majewski

2014-12-09 08:22 UTC #5 lore raw

PATCH 1/1 fastboot: handle flash write to GPT partition

Hi Steve,

Quoted 107 lines

Hi Lukasz,
Quoted 95 lines · Lukasz Majewski
Hi Steve,
Quoted 87 lines
Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table.
Signed-off-by Steve Rae <[email protected]>
---
  README          |  7 +++++++
  common/fb_mmc.c | 19 ++++++++++++++++---
  2 files changed, 23 insertions(+), 3 deletions(-)
README +0 -0
index 66770b6..3b6ef7f 100644
@@ -1769,6 +1769,13 @@ The following options need to be configured:
  		regarding the non-volatile storage device. Define
this to the eMMC device that fastboot should use to store the image.
README +2 -0
+		CONFIG_FASTBOOT_GPT_NAME
+		The fastboot "flash" command supports writing the
downloaded
README +1 -0
+		image to the Protective MBR and the Primary GUID
Partition
README +1 -0
+		Table. This occurs when the specified "partition
name" on the
README +2 -0
+		"fastboot flash" command line matches this value.
+		Default is GPT_ENTRY_NAME (currently "gpt") if
undefined. +
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
common/fb_mmc.c +5 -0
index fb06d8a..89fbf23 100644
@@ -4,12 +4,17 @@
   * SPDX-License-Identifier:	GPL-2.0+
   */
 
+#include <config.h>
  #include <common.h>
  #include <fb_mmc.h>
  #include <part.h>
  #include <aboot.h>
  #include <sparse_format.h>
 
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
  /* The 64 defined bytes plus the '\0' */
  #define RESPONSE_LEN	(64 + 1)
 
@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
 *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const
char *cmd, void *download_buffer, unsigned int download_bytes, char *response) {
common/fb_mmc.c +9 -3
-	int ret;
  	block_dev_desc_t *dev_desc;
  	disk_partition_t info;
+	lbaint_t blksz;
 
  	/* initialize the response buffer */
  	response_str = response;
@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void
 *download_buffer, return;
  	}
 
-	ret = get_partition_info_efi_by_name(dev_desc, cmd,
 &info);
-	if (ret) {
+	if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+		printf("%s: updating GUID Partition Table
 (including MBR)\n",
+		       __func__);
+		/* start at Protective MBR */
+		info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA -
 1);
+		blksz = dev_desc->blksz;
+		info.blksz = blksz;
+		/* assume that the Partition Entry Array starts in
LBA 2 */
common/fb_mmc.c +1 -0
+		info.size = (2 + (GPT_ENTRY_NUMBERS *
GPT_ENTRY_SIZE) / blksz);
common/fb_mmc.c +1 -0
+	} else if (get_partition_info_efi_by_name(dev_desc, cmd,
Quoted 3 lines
&info)) { error("cannot find partition: '%s'\n", cmd);
fastboot_fail("cannot find partition"); return;
Sorry for a late reply. I've just come back from a short holidays.
Quoted 2 lines
I'm curious if you have encountered any problems with GPT replaced in that way?
No -- this "technique" seems to be fine (for the Primary GPT)....
Quoted 3 lines
It seems strange to me that you only change primary GPT partition without taking care of the secondary (backup) one.

Quoted 7 lines

It seems that the device operates correctly with or without the Backup GPT, and it doesn't seem to matter if they are the same or not. Thus, we have gone back and forth on this one - should we automatically update the Backup GPT whenever the Primary GPT is updated, or should there be a second step (possibly a "fastboot oem" command) to update the Backup GPT... (currently, we are proposing the latter) What would you suggest?

I'd suggest updating both of them.

However, it is important to check all available CRC's in the received image.

In my opinion a separate command for Secondary GPT - "fastboot oem" - seems like an overkill.

Quoted 7 lines

Quoted 4 lines
From my experience when you export your eMMC to Host PC via UMS,
host's PC tools will complain about mismatch in the GPT tables.
( I have never done this - what tools are you using? Could you provide instructions for me to try? Thanks! )

For Exynos based boards (e.g. Odroid-U3, Trats2) it is possible to use USB mass storage gadget (ums command in u-boot prompt), which exports the content of eMMC to host PC and is treated as an ordinary USB stick.

Also you can try "parted" linux utility.

Quoted 10 lines

Quoted 5 lines
Moreover, I would suggest transactional update of GPT by checking GPT image CRC before writing. In this way you can always perform recovery if needed.
This is a good idea - I'll look into it - Thanks!
Quoted 1 line
Thanks, Steve

Signature · 5 lines

Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group