[U-Boot] [RFC PATCH v2 4/5] dra7x: boot: add dfu bootmode support

[Tom Rini]

On Mon, Jul 25, 2016 at 02:17:35PM +0000, B, Ravi wrote:
> Hi Tom
> 
> >> +++ b/arch/arm/include/asm/arch-omap5/spl.h
> >> @@ -20,7 +20,7 @@
> >>  #define BOOT_DEVICE_QSPI_1	0x0A
> >>  #define BOOT_DEVICE_QSPI_4	0x0B
> >>  #define BOOT_DEVICE_UART	0x43
> >> -#define BOOT_DEVICE_USB		0x45
> >> +#define BOOT_DEVICE_DFU		0x45
> 
> >So you're breaking regular USB gadget support with this change, on these platforms, yes?
> 
> You are correct. This platform does not support BOOT_DEVICE_USB support.
> The BOOT_DEVICE_USB is basically the USBHOST-MSC support (CONFIG_SPL_USB_SUPPORT), i.e, boot from mass storage device.

So, we have 3 SoCs that share these values here, and we need to be
correct for all of them.  What does 0x45 mean, on OMAP5, DRA7xx and
AM57xx, in terms of what, and how, the ROM loaded something in?

> Yes, this platform don't have USBHOST-MSC support, hence BOOT_DEVICE_USB is not valid for this device and removed, and also does not support BOOT_DEVICE_USBETH as well.

When you say platform and device, do you mean SoC, or the specific EVM
you're working with?

> Instead BOOT_DEVICE_DFU  is defined for USB-Gadget-DFU support, i.e, boot from USB-DFU.

It sounds like you're saying here that 0x45, for DRA7xx/AM57xx means
"ROM enumerated a USB gadget (of type what?) and was given a payload".
This is what, on TI platforms, usually happens with 0x45.  Sometimes
it's a USB RNDIS device and bootp (am33xx, am43xx), sometimes it's a
something else (I honestly forget what OMAP4 did, I think it was just a
vendor class self-defined and spec-allowed thing).  What is happening in
this case, and how do we get this first part in?

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160725/e62d1610/attachment.sig>