summaryrefslogtreecommitdiffstats
path: root/arch/arm/cpu/armv7/omap-common
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>
* omap3: bugfix in timer on rolloverDaniel Gorsulowski2016-06-241-1/+1
| | | | Signed-off-by: Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
* 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>
* armv7: fix order of OMAP die ID printingLadislav Michl2016-06-061-2/+2
| | | | | Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* arm: omap: Introduce vcores_init functionKeerthy2016-06-021-0/+11
| | | | | | | | The pmic registers for variants of am57xx boards are different hence we need to assign them carefully based on the board type. Add a function to assign omap_vcores after the board detection. Signed-off-by: Keerthy <j-keerthy@ti.com>
* ARM: OMAP4+: Fix DPLL programming sequenceLokesh Vutla2016-05-271-3/+5
| | | | | | | | | | All the output clock parameters of a DPLL needs to be programmed before locking the DPLL. But it is being configured after locking the DPLL which could potentially bypass DPLL. So fixing this sequence. Reported-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com>
* ARM: omap-common: Add device type to CPU stringDaniel Allred2016-05-271-2/+20
| | | | | | | | | | | | | | Update the CPU string output so that the device type is now included as part of the CPU string that is printed as the SPL or u-boot comes up. This update adds a suffix of the form "-GP" or "-HS" for production devices, so that general purpose (GP) and high security (HS) can be distiguished. Applies to all OMAP5 variants. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ti: omap-common: Add commands for generating secure SPL imagesDaniel Allred2016-05-271-0/+66
| | | | | | | | | | | | | | | | | | Adds a centralized config_secure.mk in omap-common for OMAP-style TI secure devices to use for boot image generation Depending on the boot media, different images are needed for secure devices. These commands generates u-boot*_HS_* files that need to be used to boot secure devices. Please refer to README.ti-secure for more information. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ti: omap-common: Add Kconfig file for secure device supportMadan Srinivas2016-05-271-0/+17
| | | | | | | | | | | | | | | | | | | | | | | Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on when building images for secure devices. This flag is used to invoke the secure image creation tools for creating a boot image that can be used on secure devices. This flag may also be used to conditionally compile code specific to secure devices. This terminology will be used by all OMAP architecture devices, hence introducing to a common location. With the creation of Kconfig for omap-common, moved the sourcing of the Kconfig files for the omap3/4/5 and am33xx devices from arch/arm/KConfig to the omap-common one. Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Daniel Allred <d-allred@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* 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>
* ARM: DRA7: Add ABB setup for all domainsNishanth Menon2016-04-251-0/+24
| | | | | | | | | | | | | ABB should be initialized for all required domains voltage domain for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If we do not do this, kernel configuring just the frequency using the default boot loader configured voltage can fail on many corner lot units and has been hard to debug. This specifically is a concern with DRA7 generation of SoCs since other than VDD_MPU, all other domains are only permitted to setup the voltages to required OPP only at boot. Reported-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* ARM: OMAP5: Enable ABB configuration for MM voltage domainNishanth Menon2016-04-251-0/+9
| | | | | | | | | | Since we setup the voltage and frequency for the MM domain, we *must* setup the ABB configuration needed for the domain as well. If we do not do this, kernel configuring just the frequency using the default boot loader configured voltage can fail on many corner lot units. Reported-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* ARM: OMAP5/DRA7: Move ABB TXDONE mask to voltage structureNishanth Menon2016-04-251-2/+2
| | | | | | | | | | | ABB TX_DONE mask will vary depending on ABB module. For example, 3630 never had ABB on IVA domain, while OMAP5 does use ABB on MM domain, DRA7 has it on all domains with the exception of CORE, RTC. Hence, move the txdone mask definition over to structure describing voltage domain. Signed-off-by: Nishanth Menon <nm@ti.com>
* ARM: OMAP5/DRA7: Get rid of control_std_fuse_opp_vdd_mpu_2Nishanth Menon2016-04-251-2/+2
| | | | | | | | | | | | | This information is already available under vcores->volts.efuse.reg. There is no reason for duplicating the information since AVS Class 0 definitions are common for OMAP5 and DRA7 and defined with STD_FUSE_OPP_* macros. This allows a central location of defining the ABB and voltage definitions especially since they are reused. This also makes it simpler to prevent mistakes involved when changing the boot OPP for the device. Signed-off-by: Nishanth Menon <nm@ti.com>
* spl: arm: Make sure to include all of the u_boot_list entriesTom Rini2016-03-161-1/+1
| | | | | | | | | | | | | | Starting with 96e5b03 we use a linker list for partition table information. However since we use this in SPL we need to make sure that the SPL linker scripts include these as well. While doing this, it's best to simply include all linker lists to future proof ourselves. Cc: Andreas Bießmann <andreas.devel@googlemail.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reported-by: Nishanth Menon <nm@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* arm: omap-common: Guard some parts of the code with CONFIG_OMAP44XX/OMAP54XXTom Rini2016-03-161-1/+7
| | | | | | | | | | On OMAP4 platforms that also need to calculate their DDR settings we are now getting very close to the linker limit size. Since OMAP44XX is only seen with LPDDR2, remove some run time tests for LPDDR2 or DDR3 as we will know that we don't have it for OMAP44XX. Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* omap-common: clocks-common: Setup USB DPLL when MUSB is in usePaul Kocialkowski2016-03-151-2/+4
| | | | | | | | On (at least) OMAP4, the USB DPLL is required to be setup for the internal PHY to work properly. The internal PHY is used by default with the MUSB USB OTG controller. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* omap-common: Remove deprecated arch_cpu_init codePaul Kocialkowski2016-03-151-13/+0
| | | | | | | save_omap_boot_params is called from spl_board_init in the SPL context. Thus, there is no reason to duplicate that call on arch_cpu_init. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* omap-common: Rename set_muxconf_regs_essential to set_muxconf_regsPaul Kocialkowski2016-03-151-2/+2
| | | | | | | There is no distinction between essential and non-essential mux configuration, so it doesn't make sense to have an "essential" prefix. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* ARM: OMAP4+: Allow arch specfic code to use early DMLokesh Vutla2016-03-141-9/+21
| | | | | | | | | | | Early system initialization is being done before initf_dm is being called in U-Boot. Then system will fail to boot if any of the DM enabled driver is being called in this system initialization code. So, rearrange the code a bit so that DM enabled drivers can be called during early system initialization. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7: emif: Enable interleaving for higher address spaceLokesh Vutla2016-03-141-0/+2
| | | | | | | | Given that DRA7/OMAP5 SoCs can support more than 2GB of memory, enable interleaving for this higher memory to increase performance. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7: emif: Check for enable bits before updating leveling outputLokesh Vutla2016-03-141-16/+22
| | | | | | | | | Read and write leveling can be enabled independently. Check for these enable bits before updating the read and write leveling output values. This will allow to use the combination of software and hardware leveling. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7: emif: Fix DDR init sequence during warm resetLokesh Vutla2016-03-141-1/+3
| | | | | | | | | | | | | Commit (20fae0a - ARM: DRA7: DDR: Enable SR in Power Management Control) enables Self refresh mode by default and during warm reset the EMIF contents are preserved. After warm reset EMIF sees that it is idle and puts DDR in self-refresh. When in SR, leveling operations cannot be done as DDR can only accept SR exit command, so its hanging during warm reset. In order to fix this reset the power management control register before EMIF initialization if it is a warm reset. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7: emif: Fix updating of refresh ctrl shadowLokesh Vutla2016-03-141-1/+5
| | | | | | | | On DRA7, refresh ctrl shadow should be updated with the final value. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP4/5: Add generic board detection hookKipisz, Steven2016-03-141-0/+11
| | | | | | | | | | | | | | | | | | | Many TI EVMs have capability to store relevant board information such as DDR description in EEPROM. Further many pad configuration variations can occur as part of revision changes in the platform. In-order to support these at runtime, we for a board detection hook which is available for override from board files that may desire to do so. NOTE: All TI EVMs are capable of detecting board information based on early clocks that are configured. However, in case of additional needs this can be achieved within the override logic from within the board file. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP4/5: Centralize early clock initializationKipisz, Steven2016-03-142-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Early clock initialization is currently done in two stages for OMAP4/5 SoCs. The first stage is the initialization of console clocks and then we initialize basic clocks for functionality necessary for SoC initialization and basic board functionality. By splitting up prcm_init and centralizing this clock initialization, we setup the code for follow on patches that can do board specific initialization such as board detection which will depend on these basic clocks. As part of this change, since the early clock initialization is centralized, we no longer need to expose the console clock initialization. NOTE: we change the sequence slightly by initializing console clocks timer after the io settings are complete, but this is not expected to have any functioanlity impact since we setup the basic IO drive strength initialization as part of do_io_settings. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-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>
* arm: omap-common: do not build timer when CONFIG_TIMER definedMugunthan V N2016-01-201-0/+6
| | | | | | | | | | To prepare timer driver to DM/DT conversion do not build the exiting timer driver when CONFIG_TIMER is defined. But since omap's SPL doesn't support DM yet so built timer driver only for SPL build when CONFIG_TIMER is defined. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* armv7: Add missing newline after OMAP die IDLadislav Michl2016-01-201-2/+2
| | | | | Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Acked-by: Enric Balletbo Serra <enric.balletbo@collabora.com>
* 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: Common get_board_serial function to pass serial through ATAGPaul Kocialkowski2015-10-221-0/+18
| | | | | | | | | Since there is a common function to grab the serial number from the die id bits, it makes sense have one to parse that serial number and feed it to the serial ATAG. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
* omap-common: Common function to display die id, replacing omap3-specific versionPaul Kocialkowski2015-10-221-0/+10
| | | | | | | | | This introduces omap_die_id_display to display the full die id. There is no need to store it in an environment variable, that no boot script is using anyway. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
* omap-common: Common serial and usbethaddr functions based on die idPaul Kocialkowski2015-10-221-22/+27
| | | | | | | | | Now that we have a common prototype to grab the omap die id, functions to figure out a serial number and usb ethernet address can use it directly. Those also get an omap_die_id prefix for better consistency. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
* omap-common: Common omap_die_id definitionPaul Kocialkowski2015-10-221-0/+5
| | | | | | | | This introduces a common definition for omap_die_id, that aims at providing a common interface for accessing omap platform's die id bits. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7: emif: Fix disabling/enabling of refreshesLokesh Vutla2015-09-111-3/+3
| | | | | | | | | clrsetbits_le32/clrbits_le32 takes mask of the bits as input that are needed to be set/clear. But emif driver passes the shift of the bits. Fixing it here. Reported-by: Mark Mckeown <m-mckeown@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.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>
* ARM: OMAP5: Add support for disabling clocks in ubootKishon Vijay Abraham I2015-08-171-0/+53
| | | | | | | | | Add do_disable_clocks() to disable clock domains and module clocks. These clocks are enabled using do_enable_clocks(). Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Jagan Teki <jteki@openedev.com>
* 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-274-55/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* ARM: DRA7: emif: Fix DDR init sequence during warm resetLokesh Vutla2015-06-151-2/+2
| | | | | | | | | Unlike OMAP5, EMIF PHY used in DRA7 will be left in unknown state after warm reset, emif needs to be configured to bring it back to a known state. So configure EMIF during warm reset. Reported-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* am33xx: Re-enable SW levelling for DDR2Tom Rini2015-06-152-4/+9
| | | | | | | | | | | | | The recent changes for hw leveling on am33xx were not intended for DDR2 boards, only DDR3. Update emif_sdram_type to take a sdram_config value to check against. This lets us pass in the value we would use to configure, when we have not yet configured the board yet. In other cases update the call to be as functional as before and check an already programmed value in. Tested-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Tom Rini <trini@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* ARM: DRA7: Add support for IO delay configurationLokesh Vutla2015-06-121-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | On DRA7, in addition to the regular muxing of pins, an additional hardware module called IODelay which is also expected to be configured. This "IODelay" module has it's own register space that is independent of the control module. It is advocated strongly in TI's official documentation considering the existing design of the DRA7 family of processors during mux or IODelay recalibration, there is a potential for a significant glitch which may cause functional impairment to certain hardware. It is hence recommended to do muxing as part of IOdelay recalibration. IODELAY recalibration sequence: - Complete AVS voltage change on VDD_CORE_L - Unlock IODLAY config registers. - Perform IO delay calibration with predefined values. - Isolate all the IOs - Update the delay mechanism for each IO with new calibrated values. - Configure PAD configuration registers - De-isolate all the IOs. - Relock IODELAY config registers. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* ARM: DRA7: DDR3: Add support for HW levelingLokesh Vutla2015-06-121-21/+125
| | | | | | | | DRA7 EMIF supports Full leveling for DDR3. Adding support for the Full leveling sequence. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* 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>
* ARM: DRA7: Set serial number environment variableDileep Katta2015-04-231-0/+13
| | | | | | | | | | | | | | | | | This patch populates serial number environment variable from die_id_0 and die_id_1 register values for DRA7xx boards. The function is added in omap common code so that this can be re-used. Serial# environment variable will be useful to show correct information in "fastboot devices" commands. Ref: http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=a6bcaaf67f6e4bcd97808f53d0ceb4b0c04d583c Signed-off-by: Angela Stegmaier <angelabaker@ti.com> Signed-off-by: Dileep Katta <dileep.katta@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* ahci: mmio_base is a virtual addressScott Wood2015-04-182-4/+4
| | | | | | | | | | | | | | 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>
* ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with omap_smc1Nishanth Menon2015-03-132-1/+3
| | | | | | | | | | | | omap_smc1 is now generic enough to remove duplicate omap3_gp_romcode_call logic that omap3 introduced. As part of this change, move to using the generic lowlevel_init.S for omap3 as well. Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP: Change set_pl310_ctrl_reg to be genericNishanth Menon2015-03-131-7/+11
| | | | | | | | | | | | | | | | | | | set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup PL310 control register, however, that is something that is generic enough to be used for OMAP5 generation of processors as well. The only difference being the service being invoked for the function. So, convert the service to a macro and use a generic name (same as that used in Linux for some consistency). While at that, also add a data barrier which is necessary as per recommendation. While at this, smc #0 is maintained as handcoded assembly thanks to various gcc version eccentricities, discussion thread: http://marc.info/?t=142542166800001&r=1&w=2 Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
OpenPOWER on IntegriCloud