summaryrefslogtreecommitdiffstats
path: root/arch/arm/cpu/armv7/omap-common/boot-common.c
Commit message (Collapse)AuthorAgeFilesLines
* common: Pass the boot device into spl_boot_mode()Marek Vasut2016-06-261-1/+1
| | | | | | | | | | | | | | | | | | The SPL code already knows which boot device it calls the spl_boot_mode() on, so pass that information into the function. This allows the code of spl_boot_mode() avoid invoking spl_boot_device() again, but it also lets board_boot_order() correctly alter the behavior of the boot process. The later one is important, since in certain cases, it is desired that spl_boot_device() return value be overriden using board_boot_order(). Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Bießmann <andreas@biessmann.org> [add newly introduced zynq variant] Signed-aff-by: Andreas Bießmann <andreas@biessmann.org>
* armv7: omap-common: make SPL board_mmc_init() weakHeiko Schocher2016-06-091-1/+1
| | | | | | | make this function weak, so board code can setup in SPL MMC init with board special values. Signed-off-by: Heiko Schocher <hs@denx.de>
* Revert "omap3: Use raw SPL by default for mmc1"Tom Rini2016-05-021-0/+2
| | | | | | | | | | | | | Unfortunately with this change we now are unable to do FS mode boots from MMC1 as with the way the code works today we will always load and assume that the hard-coded raw location contains U-Boot. Further, we cannot fix this by just changing other logic to try FS-then-RAW as it would also make us have to ignore what order the ROM is telling us to try. This reverts commit 22d90d560a2b01c47f180e196e6c6485eb8e65db. Signed-off-by: Tom Rini <trini@konsulko.com>
* omap3: Use raw SPL by default for mmc1Alexander Graf2016-03-081-2/+0
| | | | | | | | | | | Now that we fall back to the FS code path when we don't find u-boot at the raw sector offset, there is no good reason to not default to raw boot. With this patch, I can successfully boot u-boot from a raw sector offset on beagle-xm. Signed-off-by: Alexander Graf <agraf@suse.de>
* armv7: omap-common: Rework SPL board_mmc_init()Tom Rini2015-12-141-0/+1
| | | | | | | | | | | | | | Since the changes in a1e56cf the way that we had board_mmc_init() structured for OMAP parts (so that we always report device 0) are no longer functional. For now, make the case of booting from the second device initialize both devices (we have no devices that only have the second device as MMC). A further rework and consolidation of the functions should be done at a later date. Tested on Beaglebone Black (SD and eMMC boot). Reported-by: Vagrant Cascadian <vagrant@debian.org> Signed-off-by: Tom Rini <trini@konsulko.com>
* omap-common: SYS_BOOT fallback logic correction and support for more devicesPaul Kocialkowski2015-08-281-10/+22
| | | | | | | | | | | | | | | | | | | | | The SYS_BOOT-based fallback shouldn't only check for one of the conditions of use and then let the switch/case handle each boot device without enforcing the conditions for each type of boot device again. For instance, this behaviour would trigger the fallback for UART when BOOT_DEVICE_UART is defined, CONFIG_SPL_YMODEM_SUPPORT is enabled (which should be a show-stopper) and e.g. BOOT_DEVICE_USB is enabled and not CONFIG_SPL_USB_SUPPORT. Separating the logic for USB and UART solves this. In addition, this adds support for more peripheral devices (USBETH and CPGMAC) to the fallback mechanism. Note that the USBETH boot device should always be different from the USB boot device (each should match a different bootrom handoff case). Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Acked-by: Hannes Schmelzer <oe5hpm@oevsv.at> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
* omap-common: SYS_BOOT-based fallback boot device selection for peripheral bootPaul Kocialkowski2015-07-271-7/+45
| | | | | | | | | | | | | | | | | OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device. This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location. Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* omap-common: Boot device define instead of hardcoded valuePaul Kocialkowski2015-07-271-2/+2
| | | | | | | Now that SPL boot devices are clearly defined, we can use BOOT_DEVICE_QSPI_4 instead of a hardcoded value. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* omap-common: Common boot code OMAP3 support and cleanupPaul Kocialkowski2015-07-271-52/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This 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. All of this is only relevant when the U-Boot SPL is used. In cases it is not, save_boot_params should fallback to its weak (or board-specific) definition. save_omap_boot_params should not be called in that context either. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* usb: Fastboot function config for better consistency with other functionsPaul Kocialkowski2015-07-221-1/+1
| | | | | | | | | | | | USB download gadget functions such as thor and dfu have a separate config option for the USB gadget part of the code, independent from the command part. This switches the fastboot USB gadget to the same scheme, for better consistency. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Lukasz Majewski <l.majewski@samsung.com> Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
* fastboot: ARM: OMAP5: Enable reboot-bootloaderDileep Katta2015-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | Implemented fb_set_reboot_flag() for OMAP5 to set an environment variable 'dofastboot' when reboot-bootloader called. This environment variable will be checked in boot command and fastboot will be called if the variable is set. If the bootcmd env variable of OMAP5 common is overwritten with board-specific command, then these changes will not apply. This was originally intended for DRA7 platform, but now applies to all OMAP5. Ref: http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=19da2e436e9806259cf1f4988b9e046ab256bf2c Signed-off-by: Angela Stegmaier <angelabaker@ti.com> Signed-off-by: Dileep Katta <dileep.katta@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Make it check for !CONFIG_ENV_IS_NOWHERE as we can't saveenv() in that case] Signed-off-by: Tom Rini <trini@konsulko.com>
* ahci: mmio_base is a virtual addressScott Wood2015-04-181-1/+1
| | | | | | | | | | | | | | Don't store it in a u32. Don't dereference the bus address as if it were a virtual address (fixes 284231e49a2b4 ("ahci: Support splitting of read transactions into multiple chunks")). Fixes crash on boot in MPC8641HPCN_36BIT target. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Vadim Bendebury <vbendeb@chromium.org> Acked-by: York Sun <yorksun@freescale.com>
* TI ARMv7: Don't use GD before crt0.S has set itTom Rini2015-01-161-0/+10
| | | | | | | | | | | | | | | | | Prior to this change we set the gd pointer early so that we can store data in it. This becomes problematic for DM changes as well as being odd in general. Re-work the code paths so that we don't need to set the gd pointer so early and instead can rely upon the normal setting of it. In order to do this we do need to move certain calls from s_init into spl_board_init(), mainly preloader_console_init and save_omap_boot_params. Tested on: Beaglebone Black, AM43xx GP EVM, Beagleboard, Beagleboard xM, OMAP5 uEVM, DRA7xx EVM Signed-off-by: Tom Rini <trini@ti.com> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* arm: omap: reset sata on bootDmitry Lifshitz2015-01-051-0/+9
| | | | | | | | | | | | | On OMAP platforms (like OMAP5) Linux kernel fails to detect a SATA device if it is used by U-Boot. It happens because U-Boot does not reset SATA controller before boot. Reset the controller on OS boot so that Linux will have a clean state to work with. Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Reviewed-by: Tom Rini <trini@ti.com>
* arm: am33xx: Handle NAND+I2C boot-device the same way as NANDStefan Roese2014-12-041-2/+13
| | | | | | | | | | | | | | Re-map NAND&I2C boot-device to the "normal" NAND boot-device. Otherwise the SPL boot IF can't handle this device correctly. Somehow booting with Hynix 4GBit NAND H27U4G8 on Siemens Draco leads to this boot-device passed to SPL from the BootROM. With this change, Draco boots just fine into main U-Boot. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Samuel Egli <samuel.egli@siemens.com>
* arm: omap: add support for am57xx devicesFelipe Balbi2014-12-041-1/+1
| | | | | | | | just add a few ifdefs around because this device is very similar to dra7xxx. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* Rename some defines containing FAT in their name to be filesystem genericGuillaume GARDET2014-10-271-2/+2
| | | | | | | | | | | Rename some defines containing FAT in their name to be filesystem generic: MMCSD_MODE_FAT => MMCSD_MODE_FS CONFIG_SPL_FAT_LOAD_ARGS_NAME => CONFIG_SPL_FS_LOAD_ARGS_NAME CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME => CONFIG_SPL_FS_LOAD_PAYLOAD_NAME CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION => CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> Cc: Tom Rini <trini@ti.com>
* dra7xx_evm: Add QSPI_4 support, qspiboot build targetTom Rini2014-04-171-0/+11
| | | | | | | | | | | | We previously only supported QSPI_1 (single) support. Add QSPI_4 (quad) read support as well. This means we can be given one of two boot device values, but don't care which it is, so perform a fixup on the QSPI_4 value. We add a qspiboot build target to better show how you would use QSPI as a boot device in deployment. When we boot from QSPI, we can check the environment for 'boot_os' to control Falcon Mode. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
* SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to CONFIG_SPL_FRAMEWORKTom Rini2014-02-071-1/+12
| | | | | | | | | | | We use the switch CONFIG_SUPPORT_EMMC_BOOT today to enable some additional features of the eMMC boot partitions. Add support for being told that we have booted from one of these partitions to the spl framework and implement this on TI OMAP/related. Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Signed-off-by: Tom Rini <trini@ti.com> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* am335x: Enable CONFIG_OMAP_WATCHDOG supportTom Rini2013-11-011-0/+4
| | | | | | | There is a board-specific portion for calling watchdog enable itself, in main U-Boot. Signed-off-by: Tom Rini <trini@ti.com>
* am33xx: Add am33xx_spl_board_init function, callTom Rini2013-09-201-0/+3
| | | | | | | | We need to allow for a further call-out in spl_board_init. Call this am33xx_spl_board_init and add a __weak version. This function may be used to scale the MPU frequency up, depending on board needs. Signed-off-by: Tom Rini <trini@ti.com>
* ARM: AM43xx: Add build supportLokesh Vutla2013-08-151-1/+2
| | | | | | Add AM43xx support in the required places Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-241-9/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.cTom Rini2013-06-051-0/+39
| | | | | | | | | | | We need to call the save_omap_boot_params function on am33xx/ti81xx and other newer TI SoCs, so move the function to boot-common. Only OMAP4+ has the omap_hw_init_context function so add ifdefs to not call it on am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx boards. Reviewed-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP: Cleanup boot parameters usageSRICHARAN R2013-05-101-17/+14
| | | | | | | | | | | The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R <r.sricharan@ti.com> [trini: Add igep0033 hunk] Signed-off-by: Tom Rini <trini@ti.com>
* omap_hsmmc: add driver check for write protectionNikita Kiryanov2013-03-081-2/+2
| | | | | | | | Add check for write protection in omap mmc driver. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Reviewed-by: Tom Rini <trini@ti.com>
* omap_hsmmc: implement driver check for card detectionNikita Kiryanov2013-03-081-2/+2
| | | | | | | Implement driver check for card detection. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
* am33xx: support for booting via usbethIlya Yanok2013-02-181-0/+3
| | | | | | | | This patch adds BOOT_DEVICE define for USB booting and fixes spl_board_init function to call arch_misc_init (this is the place there musb is initialized). Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
* OMAP: include sys_proto.h from boot-commonIlya Yanok2012-12-101-0/+1
| | | | | | | Include asm/arch/sys_proto.h for gpmc_init prototype. Without this we get a warning while building for AM335x. Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
* SPL: Move the omap SPL framework to common/splTom Rini2012-09-271-1/+1
| | | | | | | | | | | | | Add a new flag, CONFIG_SPL_FRAMEWORK to opt into the common/spl SPL framework, enable on all of the previously using boards. We move the spl_ymodem.c portion to common/ and spl_mmc.c to drivers/mmc/. We leave the NAND one in-place as we plan to replace it later in this series. We use common/spl to avoid linker problems with respect to merging constant strings in objects. Otherwise all strings in common/ will be linked in and kept which grows SPL in size too much. Signed-off-by: Tom Rini <trini@ti.com>
* ARM: SPL: Move gpmc_init() to spl_board_init()Tom Rini2012-09-271-0/+7
| | | | | | | | This is an OMAP/related-specific function, move calling it to spl_board_init() and turn on CONFIG_SPL_BOARD_INIT on the boards that enabled NAND and didn't enable this already. Signed-off-by: Tom Rini <trini@ti.com>
* ARM: SPL: Make spl_mmc.c more genericTom Rini2012-09-271-0/+16
| | | | | | | | Move the default omap/related-centric board_mmc_init to arch/arm/cpu/armv7/omap-common/boot-common.c and move the type defines to <asm/spl.h>. Also use mmc->read_bl_len rather than MMCSD_SECTOR_SIZE Signed-off-by: Tom Rini <trini@ti.com>
* ARM: SPL: Rename omap_boot_mode to spl_boot_mode()Tom Rini2012-09-271-1/+1
| | | | Signed-off-by: Tom Rini <trini@ti.com>
* ARM: SPL: Rename omap_boot_device to spl_boot_deviceTom Rini2012-09-271-1/+1
| | | | Signed-off-by: Tom Rini <trini@ti.com>
* ARM:AM33XX: Add SPL support for AM335X EVMChandan Nath2012-01-161-0/+49
This patch is added to support SPL feature on AM335X platform. In this patch, MMC1 is configured as boot device for SPL and support for other devices will be added in the next patch series. Signed-off-by: Chandan Nath <chandan.nath@ti.com> Signed-off-by: Tom Rini <trini@ti.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
OpenPOWER on IntegriCloud