[U-Boot] [PATCH v5 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device

[Paul Kocialkowski]

Changes since v4:
* Take care of BOOT_DEVICE_USBETH and don't use the fallback when it's defined
  and active. This way, we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB
  defined to the same value and use USB eth or not based on
  CONFIG_SPL_USBETH_SUPPORT.
* boot_params casting clarification.

Changes since v3:
* Tested on the OMAP5 uEVM, adjusted SYS_BOOT interpretation.
* Typo fixup, other minor cleanups.

Changes since v2:
* ifdef save_boot_params definition and save_omap_boot_params calls with
  CONFIG_SPL to only use all this when U-Boot is loaded from the U-Boot SPL.
  This was always the case on != omap3 omap platforms, but is no longer the
  case with omap3 support (since some devices like the RX-51 are OMAP HS and
  have proprietary bootloaders loading U-Boot, and might even need some specific
  code instead).

The first part of this changeset introduces OMAP3 support for the common omap
boot code, as well as a major cleanup of the common omap boot code.

First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.

The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.

The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.

The second part of this changeset adds support for reading the SYS_BOOT pins on
omap devices (no am33xx support yet) in order to fallback to the
memory-preferred boot device described by the pins when peripheral booting is
used. In particular, this allows loading the U-Boot SPL through either UART or
USB and still having it to load U-Boot from memory when UART or USB are not
valid boot devices.

This whole changeset was build-tested on all omap boards (omap3, omap4, omap5,
am33xx) and tested at run-time on the Nokia RX-51 (N900), the LG Optimus Black
(not supported yet) and the OMAP5 EVM.