[U-Boot] [PATCH v1] fastboot: handle flash write to GPT partition

[Lukasz Majewski]

Hi Steve,

> Hi Lukasz,
> 
> On 14-12-08 03:21 AM, Lukasz Majewski wrote:
> > Hi Steve,
> >
> >> 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 <srae at broadcom.com>
> >> ---
> >>
> >>   README          |  7 +++++++
> >>   common/fb_mmc.c | 19 ++++++++++++++++---
> >>   2 files changed, 23 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/README b/README
> >> index 66770b6..3b6ef7f 100644
> >> --- a/README
> >> +++ b/README
> >> @@ -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
> >> diff --git a/common/fb_mmc.c b/common/fb_mmc.c
> >> index fb06d8a..89fbf23 100644
> >> --- a/common/fb_mmc.c
> >> +++ b/common/fb_mmc.c
> >> @@ -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;
> >
> > 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?
> 
> No -- this "technique" seems to be fine (for the Primary GPT)....
> 
> >
> > 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?

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.

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

> 
> >
> > 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!
> >
> 
> Thanks, Steve



-- 
Best regards,

Lukasz Majewski

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