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 <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
