From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lokesh Vutla Date: Thu, 9 Jul 2015 13:29:07 +0530 Subject: [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot In-Reply-To: <1435866813.2758.14.camel@aldrin> 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> Message-ID: <559E29CB.3040706@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. >