From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Date: Wed, 15 Jul 2015 02:35:43 +0200 Subject: [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot In-Reply-To: <20150714191721.GB25532@bill-the-cat> References: <1435789184-6815-1-git-send-email-contact@paulk.fr> <1435789184-6815-6-git-send-email-contact@paulk.fr> <20150702191043.GT28577@bill-the-cat> <1435866813.2758.14.camel@aldrin> <559E29CB.3040706@ti.com> <1436430458.2326.7.camel@collins> <20150714191721.GB25532@bill-the-cat> Message-ID: <1436920543.4934.2.camel@collins> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: