Hi Sumit,
On Mon, Sep 28, 2026 at 12:10, Sumit Singh Dhami <[email protected]>
wrote:
> This work is done as part of Snagboot support for Qualcomm Lemans-EVK to
> help flash GPT via u-boot 'gpt write' command. It addresses the following
> issues:
> - Incorrect first/last LBA computation for devices whose block size is
> not 512 bytes.
> - No option available in 'gpt write' to set full 64-bit gpt partition
> attributes.
> - Fastboot EP_BUFFER_SIZE is not configurable and set to 4096 bytes which
> overflows when long command strings are passed. (We faced this issue when
> we passed 'gpt write' via 'fastboot oem run' with a very long partition
> list).
>
> The changes are followed by a final patch that adds all the config options
> required for writing a GPT via 'gpt write' over fastboot to
> qcom-snagboot.config file.
I've not looked that much into detail in this series, but enabling
"fastboot oem run" feels wrong to me. "oem run" is a debug command. I
don't recommend shipping any board by default with it.
Also, more generally, I don't see to understand why it needs to be
implemented this way? (Sending "gpt write" via "fastboot oem run")
It seems to me that we already handle gpt flashing in fastboot.
See: drivers/fastboot/fb_mmc.c
"""
#if CONFIG_IS_ENABLED(EFI_PARTITION)
if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
dev_desc = fastboot_mmc_get_dev(response);
if (!dev_desc)
return;
printf("%s: updating MBR, Primary and Backup GPT(s)\n",
__func__);
if (is_valid_gpt_buf(dev_desc, download_buffer)) {
printf("%s: invalid GPT - refusing to write to flash\n",
__func__);
fastboot_fail("invalid GPT partition", response);
return;
}
if (write_mbr_and_gpt_partitions(dev_desc, download_buffer)) {
printf("%s: writing GPT partitions failed\n", __func__);
fastboot_fail("writing GPT partitions failed",
response);
return;
}
part_init(dev_desc);
printf("........ success\n");
fastboot_okay(NULL, response);
return;
}
#endif
"""
Can we explain how this is any different please ?
