From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Date: Tue, 25 Aug 2015 14:27:04 +0200 Subject: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot In-Reply-To: <55DC29F9.8060701@schmelzer.or.at> References: <1436968946-16025-6-git-send-email-contact@paulk.fr> <20150728145914.GT25532@bill-the-cat> <55DC29F9.8060701@schmelzer.or.at> Message-ID: <1440505624.9743.19.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 25 ao?t 2015 ? 10:40 +0200, Schmelzer Hannes a ?crit : > Hi Paul, Tom, > > i am failing bring up my AM335x boards (tseries, kwb) with bare UART > connection since introducing this change. Does this mean that you're trying to get the device to load the full U-Boot binary over UART? > For my understanding this function should be called allways if chip > has basically support for some BOOT_DEVICE_x __AND__ there is no > implementation for it - the function should prevent target from > stalling with selecting another (hopefully working) boot-device. > Right ? This is a fallback mechanism that allows selecting the boot device from the SYS_BOOT pins when the U-Boot SPL was loaded from peripheral booting (USB or UART) by the bootrom and that the U-Boot SPL has no support for continuing boot through that same peripheral (USB or UART). It does require omap_sys_boot_device to be implemented for each platform (currently, only am33xx doesn't have a proper one). The point is that it selects another *memory* (read, not peripheral) boot device that the U-Boot SPL may be able to handle. In any case, it offers a way to *maybe* put the U-Boot SPL on the right track instead of being unable to boot at all. > I am not sure at this time how to deal with the facts ... i see > several possibilities: > > a) > i have to implement some "omap_sys_boot_device" function in my boards > - this would maybe sometimes comfortable but i think this is not > inventors mind. It would be more convenient to implement it in some > common place for AM335x or OMAP. But what do with the information > about SYS_BOOT pins ? they always represent a boot-order ... which > boot-device should it take ? That function is not supposed to be board-specific at all, but to be platform-specific. This is not the way to select the proper boot device, which is done by reading the boot info structure passed by the bootrom (first thing in omap-common/lowlevel_init.S). > b) and/or something is wrong with the #ifdef ... construct at line #67 > - > In fact there is a problem with > defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) > > basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my > configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so > the following switch/case calls in case of BOOT_DEVICE_UART this weak > function. If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented. The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT. UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT. > further i think that this construct isn't complete yet, because it > wants to handle all peripheral booting on AM335x or OMAP in general. > > following peripherals are currently handled: > > BOOT_DEVICE_UART > BOOT_DEVICE_USB > BOOT_DEVICE_USBETH > > but there is also > BOOT_DEVICE_CPGMAC > > Summary i think this changeset isn't complete. Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx. > On 28.07.2015 16:59, Tom Rini wrote: > > > On Wed, Jul 15, 2015 at 04:02:23PM +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. > > > > > > Signed-off-by: Paul Kocialkowski > > Applied to u-boot/master, thanks! > > > > > > > > _______________________________________________ > > U-Boot mailing list > > U-Boot at lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > -------------- 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: