From mboxrd@z Thu Jan 1 00:00:00 1970 From: Schmelzer Hannes Date: Tue, 25 Aug 2015 10:40:25 +0200 Subject: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot In-Reply-To: <20150728145914.GT25532@bill-the-cat> References: <1436968946-16025-6-git-send-email-contact@paulk.fr> <20150728145914.GT25532@bill-the-cat> Message-ID: <55DC29F9.8060701@schmelzer.or.at> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Paul, Tom, i am failing bring up my AM335x boards (tseries, kwb) with bare UART connection since introducing this change. -- U-Boot SPL 2015.10-rc2-00079-g35f2192-dirty (Aug 25 2015 - 07:34:24) boot device - 0 SPL: Unsupported Boot Device (0)! ### ERROR ### Please RESET the board ### --- The source of my problem is the __weak function in omap-common/boot-common.c __weak u32 omap_sys_boot_device(void) { return BOOT_DEVICE_NONE; } which one is called on line #82 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 ? 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 ? 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. 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. How we want to deal with this facts ? best regards, Hannes 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