[PATCH] cmd: ums: Enable by default for sunxi

[Sean Anderson]

On 7/6/21 12:11 PM, Maxime Ripard wrote:
> On Tue, Jul 06, 2021 at 04:57:32PM +0100, Andre Przywara wrote:
>> On Tue, 6 Jul 2021 19:56:24 +0530
>> Jagan Teki <jagan at amarulasolutions.com> wrote:
>>
>> Hi Jagan,
>>
>> thanks for the response!
>>
>> > On Tue, Jul 6, 2021 at 4:53 AM Andre Przywara <andre.przywara at arm.com> wrote:
>> > >
>> > > The ums command (presenting a U-Boot block device as a USB mass storage
>> > > device) is very useful for accessing eMMC devices via USB-OTG.
>> > >
>> > > At the moment we enable USB fastboot by default for Allwinner devices,
>> > > so it makes sense to do the same with USB mass storage, which is
>> > > actually more versatile and can be accessed on any USB host easily.
>> > >
>> > > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> > > ---
>> > >  cmd/Kconfig | 1 +
>> > >  1 file changed, 1 insertion(+)
>> > >
>> > > diff --git a/cmd/Kconfig b/cmd/Kconfig
>> > > index a9fb4eead29..7b1c96910a8 100644
>> > > --- a/cmd/Kconfig
>> > > +++ b/cmd/Kconfig
>> > > @@ -1347,6 +1347,7 @@ config CMD_USB_MASS_STORAGE
>> > >         bool "UMS usb mass storage"
>> > >         select USB_FUNCTION_MASS_STORAGE
>> > >         depends on BLK && USB_GADGET
>> > > +       default y if ARCH_SUNXI && USB_MUSB_GADGET
>> >
>> > UMS or any secondary-emmc accessible are considered in production
>> > u-boot config instead of mainline u-boot since we have fastboot
>> > already available for this kind of purpose. This might be one of the
>> > reason not conisidered UMS by default till now, atleast on Allwinner.
>>
>> Well, I consider fastboot inferior to UMS. I understand that
>> Android phone hackers use it all the time, but I think having a block
>> device is far more versatile - you can partition it as you like, create
>> and populate a filesystem, dd an image to it, extract or update
>> firmware, etc. - most without extra software, even on Windows or Mac.
>> I think fastboot offers a reboot command, but are there other killer
>> reasons for it?

During manufacturing it is very convenient to be able to run arbitrary
commands with ACMD/UCMD, or particular commands like partconf. Fastboot
also allows loading things directly to ram, which is nice for loading a
ramdisk/kernel when you don't have network/mass storage.

There is also no way to stop UMS other than by yanking the cord or by
hitting Ctrl-C (though I am working on this).

> And having the ums command in addition to fastboot does
>> not hurt, both would still work.
>
> fastboot abstracts away the storage medium, whereas UMS doesn't. You
> cannot run UMS on a NAND or SPI-NOR, while this causes no issue at all
> to fastboot.
>
> Similarly, UMS exposes the whole partition to the host. You then need to
> have a driver for that FS on that machine, otherwise you just can't
> access it.

You can expose just one partition like

ums 0 mmc 0:2

you can also expose multiple partitions like

ums 0 mmc 0:1,0:2,0.1,0.2

--Sean

> Sure, it's convenient, but it's far from being ubiquitous and the silver
> bullet you claim it is.
>
>> So are there any real arguments for not adding ums as well? I am not
>> sure many people tweak their config, so I would like to offer a decent
>> out-of-the-box experience, even for casual users.
>
> As usual, we also have to balance that with the size limit, but I'm not
> sure it's an issue these days?
>
> Maxime
>