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

[Paul Kocialkowski <contact@paulk.fr>]

Le mardi 14 juillet 2015 ? 15:17 -0400, Tom Rini a ?crit :
> On Thu, Jul 09, 2015 at 10:27:38AM +0200, Paul Kocialkowski wrote:
> > 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.
> 
> So, I've been thinking about this a bit.  The current default case is
> IMHO the one we want things to continue to default to.  And the code
> does that, right?

That's correct, this is what I had in mind. This is just a fallback and
should only change something when the device would not be able to boot
at all otherwise.

> You're just adding in code to allow for "came via $X, load next from
> SD" which is really handy on OMAP3 (and OMAP4 and OMAP5/DRA7xx) where
> we have a USB gadget boot mode that U-Boot doesn't also support.  We
> could kludge it and say "came via ROM USB squirt, start up USB RNDIS".
> Or we could kludge it and say "came via ROM USB squirt, poke the SD
> slot".  So long as the current cases are the default for the boards
> that use them, and I believe they are, I'm OK with doing what the
> people using the setup want.

Great! I'll still make another version, with the few comments that have
developped in this discussion (see some of my previous emails) and I
think it'll be good to go. I didn't want to do it sooner in case I had
to drop the whole series.

Thanks for the review,

-- 
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/20150715/06e1e23d/attachment.sig>