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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
