From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Schmelzer Date: Tue, 25 Aug 2015 14:52:13 +0200 Subject: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot In-Reply-To: <1440505624.9743.19.camel@collins> References: <1436968946-16025-6-git-send-email-contact@paulk.fr> <20150728145914.GT25532@bill-the-cat> <55DC29F9.8060701@schmelzer.or.at> <1440505624.9743.19.camel@collins> Message-ID: <55DC64FD.8010808@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, thanks for answer. On 25.08.2015 14:27, Paul Kocialkowski wrote: > 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? Yes i do so. On at least one BuR board this is the only possibility for very first startup. Once U-Boot is loaded via UART we fetch the rest from TFTP and burn it into eMMC flash connected to MMC1. >> 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. Okay, i understand - this keeps track with my understanding. >> 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. I don't think, there is everything right. Have a closer look to the #ifdef. #if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \ (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \ (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)) I have enabled CONFIG_SPL_YMODEM_SUPPORT, look at bur_am335x_common.h. > 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. No, due to the fact that defined(BOOT_DEVICE_USBETH) is allways true (spl.h) and i don't have CONFIG_SPL_USBETH_SUPPORT enabled, the #ifdef above: defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) becomes true and the followed switch/case does the rest. >> 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. Yes, thats possible von AM335x. I will have a close look if it is necessary to implement here some fallback. But probably not, because the most likely case is that "full" U-Boot supports Ethernet and the SPL doesn't and not otherwise :-) best regards, Hannes