Hi Mattijs, On Tue, 29 Sep 2026 14:30, Mattijs Korpershoek <[email protected]> wrote:
>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 ... >Can we explain how this is any different please ? Thanks for pointing out the existing GPT handling in fb_mmc.c. Our use case is recovery through Snagboot. Instead of flashing a GPT image pre-built on host, we need to construct the GPT on the target during recovery because some GPT header fields (for ex. LastUsableLBA) depend on the actual disk size which may not be available when a GPT image is prepared on the host. For this reason, we use the already available u-boot's 'gpt write' command. The host passes the partition information to u-boot, and 'gpt write' constructs the corresponding GPT at runtime using the disk size reported by the device. This also allows final partition to use 'size=-', so that its size is calculated dyanmically from the remaining space. Fastboot 'oem run' is enabled for Snagboot recovery build only, so that a script running on host such as Snagboot's Snagfactory module, can pass the 'gpt write' command along with partition info to u-boot to construct GPT in the recovery process. Best regards Sumit Singh Dhami
