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

[Paul Kocialkowski <contact@paulk.fr>]

Le jeudi 09 juillet 2015 ? 13:29 +0530, Lokesh Vutla a ?crit :
> 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,

The bootrom is not making any USB ethernet gadget available, it's using
its own USB bulk protocol that is defined on the TRM. But I reckon it's
"USB booting" either way.

> you should be able to load u-boot also. USB ethernet gadget should be
> enabled in SPL.

I'm not saying it should not. This would be a useful feature and loading
both parts via USB makes sense.

> >> 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.

My patch simply adds a feature. Why does it matter if it's consistent or
not with the way people at TI thought it should be used?

Also, the behaviour my patch implements has nothing specific to the OMAP
and is a fallback mechanism. It will only be used when the device has no
other working boot method.

Are you suggesting we should let the device hang in that case?

I agree it could be useful to print some error message indicating that
the fallback is being used, so that users know there is something wrong
with the intended boot method.

> > 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.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150709/ac3d26ee/attachment.sig>