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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
signature.asc
Description: This is a digitally signed message part
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
