From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Date: Sun, 26 Jul 2015 18:29:16 +0200 Subject: [U-Boot] [PATCH v5 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device In-Reply-To: <1436968946-16025-1-git-send-email-contact@paulk.fr> References: <1436968946-16025-1-git-send-email-contact@paulk.fr> Message-ID: <1437928156.2629.1.camel@collins> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: