[PATCH RFT v4 3/3] fastboot: integrate block flashing back-end

[Tom Rini]

On Thu, Jun 05, 2025 at 10:16:54AM +0200, Neil Armstrong wrote:
> On 22/05/2025 16:39, Tom Rini wrote:
> > On Thu, May 22, 2025 at 02:37:07PM +0200, Neil Armstrong wrote:
> > 
> > > From: Dmitrii Merkurev <dimorinny at google.com>
> > > 
> > > 1. Get partition info/size
> > > 2. Erase partition
> > > 3. Flash partition
> > > 4. BCB
> > > 
> > > Signed-off-by: Dmitrii Merkurev <dimorinny at google.com>
> > > Reviewed-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
> > > Tested-by: Mattijs Korpershoek <mkorpershoek at kernel.org>
> > > Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
> > > ---
> > >   drivers/fastboot/Kconfig      | 29 +++++++++++++++++++++++++++++
> > >   drivers/fastboot/Makefile     |  1 +
> > >   drivers/fastboot/fb_command.c |  8 ++++++++
> > >   drivers/fastboot/fb_common.c  | 22 ++++++++++++++++++----
> > >   drivers/fastboot/fb_getvar.c  |  8 +++++++-
> > >   5 files changed, 63 insertions(+), 5 deletions(-)
> > 
> > I know this was posted before I replied with more feedback moments ago.
> > 
> > [snip]
> > > @@ -193,6 +197,31 @@ config FASTBOOT_MMC_USER_NAME
> > >   	  defined here.
> > >   	  The default target name for erasing EMMC_USER is "mmc0".
> > > +config FASTBOOT_FLASH_BLOCK_INTERFACE_NAME
> > > +	string "Define FASTBOOT block interface name"
> > > +	depends on FASTBOOT_FLASH_BLOCK
> > > +	default ""
> > > +	help
> > > +	  The fastboot "flash" and "erase" commands support operations
> > > +	  on any Block device, this should specify the block device name
> > > +	  like ide, scsi, usb, sata, nvme, virtio, blkmap, mtd...
> > > +	  The mmc block device type can be used but most of the features
> > > +	  available in the FASTBOOT_MMC will be missing.
> > > +	  Consider using FASTBOOT_MMC on a MMC block device until all
> > > +	  features are migrated.
> > 
> > A default like "" in order to un-stick configs that are now here and
> > enabling the option is wrong. If we're enabling new functionality for
> > platforms, it needs to be configured correctly. This leads to building
> > code on platforms that won't be used on the platform so we've likely
> > added run-time bloat for no benefit.
> 
> I agree but what's the solution ? I'll prefer having no default as it was initially.

No defaults is correct here, yes. It's just that the primary
dependencies need to be fixed so that platforms don't get stuck on the
prompt on features they won't actually use either.

Seeing what boards get stuck, and then having an idea on what
dependencies trip them up is tricky. What I usually do in this
situation, to see what platform is stuck on the prompt is:
- In one terminal, fire off tools/qconfig -sC. Then wait for it to
  seemingly be stuck with just one or two platforms left to finish
  syncing.
- In another terminal, 'ps uxwwww | grep make' to see what the build
  directory of one of those stuck platforms is, then manually save off
  the .config file, begin investigation.

That should provide what platform is asking this question and not having
a reasonable answer. Then it's a matter of seeing if it makes sense for
this platform to be here and so just needs to be migrated to this
functionality or if it's here because of some dependency problem, for
example what I was talking about in the previous part of this series.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250605/f88f9281/attachment.sig>