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

[Paul Kocialkowski]

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 <contact at paulk.fr>
> > 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: <http://lists.denx.de/pipermail/u-boot/attachments/20150825/f6ae12e5/attachment.sig>