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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
