[U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

[Lokesh Vutla <lokeshvutla@ti.com>]

On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote:
> Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
>> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
>>> OMAP devices might boot from peripheral devices, such as UART or USB.
>>> When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot)
>>> from that peripheral device, but in most cases, this is not a valid boot device.
>>>
>>> This introduces a fallback option that reads the SYS_BOOT pins, that are used by
>>> the bootrom to determine which device to boot from. It is intended for the
>>> SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the
>>> U-Boot SPL can load the next stage from a valid location.
>>>
>>> Practically, this options allows loading the U-Boot SPL through USB and have it
>>> load the next stage according to the memory device selected by SYS_BOOT instead
>>> of stalling.
>>
>> Can you elaborate on this more please?  The normal flow is that you load
>> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
>> then U-Boot via USB RNDIS.  It sounds like you're changing things so
>> that you load first via UART and then via say SD (or whatever the pins
>> would be set for) unless you have the bits enabled for loading the next
>> stage via that peripheral, which is the default case.
> 
> Well to be honest, I haven't tried loading the main U-Boot binary via
> the USB ethernet gaget, after loading the U-Boot SPL via USB with the
> omap bootrom. Perhaps this would have worked just as well, but it isn't
> enabled for the OMAP3 and I thought it would be easier to just load from
> e.g. the MMC.
No, this is not the normal convention.
Since you are able to load SPL via USB ethernet gadget,
you should be able to load u-boot also. USB ethernet gadget should be enabled in SPL.
> 
>> Now, I know you didn't do this just for fun, so what's the use case you
>> have here exactly?  Thanks!
> 
> My use case is a bit specific: the device I have only has UART Tx
> available (so I cannot send anything) and USB available. Hence, I needed
> a way to load the main U-Boot binary from a place I could easily reflash
> (the external sdcard in my case).
> 
> Do you think it would be worth adding support for USB ethernet on omap
> platforms?
> 
> By the way, this patch set doesn't conflict with anything, and could
> still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
> defined.
Even though it does not conflict, this is not how omap platforms are being done.
SPL and u-boot are always loaded via the same boot device.
I would really not recommend this patch.

Thanks and regards,
Lokesh
> 
> That is, provided that I make my code check for BOOT_DEVICE_USBETH and
> not do anything if it is defined, so that we can have both
> BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value)
> and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or
> not.
>