All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <contact@paulk.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
Date: Tue, 25 Aug 2015 14:27:04 +0200	[thread overview]
Message-ID: <1440505624.9743.19.camel@collins> (raw)
In-Reply-To: <55DC29F9.8060701@schmelzer.or.at>

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@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>

  reply	other threads:[~2015-08-25 12:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15 14:02 [U-Boot] [PATCH v5 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
2015-07-15 14:02 ` [U-Boot] [PATCH v5 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
2015-07-28 14:58   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 2/8] omap: SPL boot devices cleanup and completion Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 3/8] omap-common: Boot device define instead of hardcoded value Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 4/8] siemens-am33x-common: Hardcoded value instead of non-included define Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-08-25  8:40     ` Schmelzer Hannes
2015-08-25 12:27       ` Paul Kocialkowski [this message]
2015-08-25 12:52         ` Hannes Schmelzer
2015-08-25 14:44           ` Paul Kocialkowski
2015-07-15 14:02 ` [U-Boot] [PATCH v5 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 7/8] omap4: " Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-15 14:02 ` [U-Boot] [PATCH v5 8/8] omap5: " Paul Kocialkowski
2015-07-28 14:59   ` [U-Boot] [U-Boot, v5, " Tom Rini
2015-07-26 16:29 ` [U-Boot] [PATCH v5 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1440505624.9743.19.camel@collins \
    --to=contact@paulk.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.