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