[U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

[Hannes Schmelzer <hannes@schmelzer.or.at>]

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