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

[Paul Kocialkowski <contact@paulk.fr>]

Le mercredi 15 juillet 2015 ? 16:02 +0200, Paul Kocialkowski a ?crit :
> 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.

Tom, it's been more than a week since we last discussed this series.

Anything holding it back at this point, with the changes introduced in
v5?

Thanks!

> 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.
> 
> _______________________________________________
> 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/20150726/e9575986/attachment.sig>