TPS SET0/SET1 register is selected by a GPIO pin on OMAP4460 platforms.
Currently we control this pin with a mux configuration as part of
boot sequence.
Current configuration results in the following voltage waveform:
|---------------| (SET1 default 1.4V)
| --------(programmed voltage)
| <- (This switch happens on mux7,pullup)
vdd_mpu(TPS) -----/ (OPP boot voltage)
--------- (programmed voltage)
vdd_core(TWL6030) -----------------------/ (OPP boot voltage)
Problem 1) |<----- Tx ------>|
timing violation for a duration Tx close to few milliseconds.
Problem 2) voltage of MPU goes beyond spec for even the highest of MPU OPP.
By using GPIO as recommended as standard procedure by TI, the sequence
changes to:
-------- (programmed voltage)
vdd_mpu(TPS) ------------/ (Opp boot voltage)
--------- (programmed voltage)
vdd_core(TWL6030) -------------/ (OPP boot voltage)
NOTE: This does not attempt to address OMAP5 - Aneesh please confirm
Reported-by: Isabelle Gros <i-gros@ti.com>
Reported-by: Jerome Angeloni <j-angeloni@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP Voltage controller is used to generically talk to
PMICs on OMAP3,4,5 over I2C_SR. Instead of replicating code
in multiple SoC code, introduce a common voltage controller
logic which can be re-used from elsewhere.
With this change, we replace setup_sri2c with omap_vc_init which
has the same functionality, and replace the voltage scale
replication in do_scale_vcore and do_scale_tps62361 with
omap_vc_bypass_send_value. omap_vc_bypass_send_value can also
now be used with any configuration of PMIC.
NOTE: Voltage controller controlling I2C_SR is a write-only data
path, so no register read operation can be implemented.
Reported-by: Isabelle Gros <i-gros@ti.com>
Reported-by: Jerome Angeloni <j-angeloni@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Add parameters to the OMAP MMC initialization function so the board can
mask host capabilities and set the maximum clock frequency. While the
OMAP supports a certain set of MMC host capabilities, individual boards
may be more restricted and the OMAP may need to be configured to match
the board. The PRG_SDMMC1_SPEEDCTRL bit in the OMAP3 is an example.
Signed-off-by: Jonathan Solnit <jsolnit@gmail.com>
Before we can send a command we need both the DATI (command inhibit on
mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear.
The previous behavior of only checking on DATI was insufficient on some
cards and incorrect behavior in any case. This makes the code check
for both bits being clear and makes the error print more clear as
to what happened. DATI_CMDDIS is removed as it was unused elsewhere
in the code and stood for 'DATI is set, cmds are disabled still'.
Fix originally spotted by Peter Bigot.
Tested-by: Peter A. Bigot <bigotp@acm.org>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Tom Rini <trini@ti.com>
Tested-by: Andreas Müller <schnitzeltony@googlemail.com>
Clean up added ehci-omap.c and make it generic for re-use across
omap-soc having same ehci ip block. Also pass the modes to be configured
from board file and configure the ports accordingly. All usb layers
are not cache aligned, till then keep cache off for usb ops as ehci will use
internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip block
data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only conflicting
sysc reg shifts remove others and move to common header file.
* pass the board data for beagle/panda accordinly to use
ehci ports.
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Fix boot issue on ES2.0 Panda by tuning some
IO settings. The CONTROL_EFUSE_2 register has
to be over-ridden in software for 4430 boards.
Commit 23e9f0723e
wrongly did this for CONTROL_EFUSE_1. Reverting
this and doing it for CONTROL_EFUSE_2.
Signed-off-by: Aneesh V <aneesh@ti.com>
Tested-by: Raúl Porcel <armin76@gentoo.org>
During misc_init_r, make sure to setup the clocks
properly for the USB hub on the pandaboard. With
this in place, the USB hub and the ethernet works
on the pandaboard.
Signed-off-by: Chris Lalancette <clalancette@gmail.com>
Acked-by: Aneesh V <aneesh@ti.com>
Configuration header(CH) is 512 byte header attached to an OMAP
boot image that will help ROM code to initialize clocks, SDRAM
etc and copy U-Boot directly into SDRAM. CH can help us in
by-passing SPL and directly boot U-boot, hence it's an alternative
for SPL. However, we intend to support both CH and SPL for OMAP4/5.
Initialization done through CH is limited and is not equivalent
to that done by SPL. So U-Boot has to distinguish between the
two cases and handle them accordingly. This patch takes care
of doing this.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Add the emif configurations required for omap5 soc.Add the
correct ddr part configurations required for omap5 evm board.
EDB8164B3PH from ELPIDA is the part used on the board.
Also changes are done to retain some part of the code
common for OMAP4/5 and keep only the remaining in the Soc
specific directories.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Adding the correct configurations required for
dplls, clocks, for omap5 Soc.
Also changes are done to retain some part of the code common
for OMAP4/5 and move only the remaining to the Soc specific
directories.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
This patch adds the minimal support for OMAP5. The platform and machine
specific headers and sources updated for OMAP5430.
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture.
It's a dual core SOC with GIC used for interrupt handling and SCU for cache
coherency.
Also moved some part of code from the basic platform support that can be made
common for OMAP4/5. Rest is kept out seperately. The same approach is followed
for clocks and emif support in the subsequent patches.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Fixing them here so that when the files are reused in
subsequent patches for omap5, avoids new checkpatch
warnings.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
We add an weak version of omap_rev_string in omap-common/spl.c
and while at it drop the omap3 version. Move the prototype over
to <asm/omap_common.h> with the other SPL functions.
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
OMAP4460 has a different set of values for the ID code, so moving the
old ones to be related just with 4430.
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@linaro.org>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Config VMMC voltage to 3V for MMC/SD card slot
and PBIAS settings needed for OMAP4
Fixes MMC/SD detection on boot from eMMC.
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Tuning some IO settings for better performance and power.
And consolidate all such IO settings at one place.
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
SDRAM init was not working on ES1.0 due to a programming
error. A pointer that was passed by value to a function
was set in function emif_get_device_details(), but the effect
wouldn't be seen in the calling function. The issue came
out while testing for ES1.0 because ES1.0 doesn't have any
SDRAM chips connected to CS1
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
TPS62361 is the new power supply used in OMAP4460 that
supplies vdd_mpu.
VCORE1 from Phoenix supplies vdd_core and VCORE2 supplies
vdd_iva. VCORE3 is not used in OMAP4460.
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
- Add MMC raw and FAT mode boot support for OMAP
- Provide a means by which parameters passed by ROM-code
can be saved in u-boot.
- Save boot mode related information passed by OMAP4 ROM-code
and use it to determine where to load the u-boot from
- Assumes that the image has a mkimage header. Gets the
payload size and load address from this header. If the
header is not detected assume u-boot.bin as payload
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
- Provide alternate implementations of board_init_f()
board_init_r() for OMAP spl.
- Provide linker script
- Initialize global data
- Add serial console support
- Update CONFIG_SYS_TEXT_BASE to allow for SPL's bss and move
it to board config header from config.mk
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Calculate EMIF register values based on AC timing parameters
from the SDRAM datasheet and the DDR frequency rather than
using the hard-coded values.
For a new board the user doen't have to go through the tedious
process of calculating the register values. Instead, just
provide the AC timings from the device data sheet as input
and the driver will automatically calculate the register values.
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules
3. Setting up the right voltage on voltage rails
This work draws upon previous work done for x-loader by:
Santosh Shilimkar <santosh.shilimkar@ti.com>
Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
- separate mux settings into essential and non essential parts
- essential part is board independent as of now(so move it
to SoC directory). Will help in having single SPL for all
boards.
- Non-essential part(the pins not essential for u-boot to function)
need to be phased out eventually.
- Correct mux data by aligning to the latest settings in x-loader
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
The basic hardware init of OMAP4(s_init()) can happen in 4
different contexts:
1. SPL running from SRAM
2. U-Boot running from FLASH
3. Non-XIP U-Boot loaded to SDRAM by SPL
4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
Configuration Header feature
What level of hw initialization gets done depends on this
context. Add a utility function to find this context.
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
OMAP boards currently use a legacy mmc driver. This patch adds a new
mmc driver which will work with the generic mmc driver in u-boot.
This new driver will work with both OMAP3 and OMAP4 boards.
This patch does not remove the old driver. It should remain in the
tree until all boards that use it switch to the new driver.
Signed-off-by: Sukumar Ghorai <s-ghorai@ti.com>
Tested-by: Steve Sakoman <steve@sakoman.com>
Calculate the SDRAM size from DMM configuration registers instead of using
hard-coded values. This gives correct values for all different boards.
It's assumed that DMM sections do not overlap memory areas.
Signed-off-by: Aneesh V <aneesh@ti.com>
Tested-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Using the reset command on OMAP36XX/37XX and OMAP4 caused a hang. This
patch uses the reset bit appropriate for each CPU architecture.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
The functions in syslib.c can be shared, so this patch moves it from
cpu/omap3 to cpu/omap-common
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Add functional multiplexing support for OMAP4 pads.
Configure all the pads for the OMAP4430 SDP
and OMAP4 Panda boards
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
This patch adds a gpmc_init function for OMAP4 and adds calls to
gpmc_init for existing OMAP4 boards: panda and sdp4430
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
This patch modifies the omap24xx driver so that it will also work with OMAP4.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
The architecture independent header is moved to drivers/mmc, and the architecture
dependent headers reside in asm/arch-omap3 and asm/arch-omap4
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
This patch adds minimum support for OMAP4. Code which can be shared
between OMAP3 and OMAP4 is placed in arch/arm/cpu/armv7/omap-common
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Nishanth Menon
Jonathan Solnit
Tom Rini
Govindraj.R
Andreas Müller
Aneesh V
Chris Lalancette
Sricharan
Ricardo Salveti de Araujo
Balaji T K
Sukumar Ghorai
Steve Sakoman