Commit graph

60 commits

Author SHA1 Message Date
Tom Rini
55cdbb8d4e ARM: SPL: Add <asm/spl.h> and <asm/arch/spl.h>
Move the SPL prototypes from <asm/omap_common.h> into <asm/spl.h> and
add <asm/arch/spl.h> for arch specific portions of CONFIG_SPL_FRAMEWORK.

Signed-off-by: Tom Rini <trini@ti.com>
2012-09-27 09:49:57 -07:00
Tom Rini
861a86f460 omap-common: SPL: Add CONFIG_SPL_DISPLAY_PRINT / spl_display_print()
Only omap4/5 currently have a meaningful set of display text and overo
had been adding a function to display nothing.  Change how this works to
be opt-in and only turned on for omap4/5 now.

Signed-off-by: Tom Rini <trini@ti.com>
2012-09-27 09:48:38 -07:00
Koen Kooi
a532278074 omap4 i2c: add support for i2c bus 4
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
2012-09-06 06:01:09 +02:00
Tom Rini
41aebf8106 omap4/5/am33xx: Make lowlevel_init available to all armv7 platforms
Make the lowlevel_init function that these platforms have which just
sets up the stack and calls a C function available to all armv7
platforms.  As part of this we change some of the macros that are used
to be more clear.  Previously (except for am335x evm) we had been
setting CONFIG_SYS_INIT_SP_ADDR to a series of new defines that are
equivalent to simply referencing NON_SECURE_SRAM_END.  On am335x evm we
should have been doing this initially and do now.

Cc: Sricharan R <r.sricharan@ti.com>
Tested-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Tom Rini <trini@ti.com>
2012-09-01 14:58:19 +02:00
Lokesh Vutla
38f25b125e OMAP4+: Force DDR in self-refresh after warm reset
Errata ID:i727

Description: The refresh rate is programmed in the EMIF_SDRAM_REF_CTRL[15:0]
REG_REFRESH_RATE parameter taking into account frequency of the device.
When a warm reset is applied on the system, the OMAP processor restarts
with another OPP and so frequency is not the same. Due to this frequency
change, the refresh rate will be too low and could result in an unexpected
behavior on the memory side.

Workaround:
The workaround is to force self-refresh when coming back from the warm reset
with the following sequence:
• Set EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x2
• Set EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM to 0x0
• Do a dummy read (loads automatically new value of sr_tim)
This will reduce the risk of memory content corruption, but memory content
can't be guaranteed after a warm reset.

This errata is impacted on
OMAP4430: 1.0, 2.0, 2.1, 2.2, 2.3
OMAP4460: 1.0, 1.1
OMAP4470: 1.0
OMAP5430: 1.0

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
2012-07-07 14:07:35 +02:00
Lokesh Vutla
702395073f ARM: OMAP3+: Detect reset type
Certain modules are not affected by means of
a warm reset and need not be configured again.
Adding an API to detect the reset reason warm/cold.

This will be used to skip the module configurations
that are retained across a warm reset.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-07-07 14:07:34 +02:00
SRICHARAN R
e423a8f76d ARM: OMAP4: Correct the lpddr2 io settings register value.
To meet certain timing requirements on the lpddr2 cmd and data phy
interfaces ,lpddr iopads have to be configured as differential buffers
and a Vref has to be internally generated and provided to these buffers.

Correcting the above settings here.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-07-07 14:07:24 +02:00
Lokesh Vutla
753bae8c5d OMAP5: DPLL core lock for OMAP5432
No need to Unlock DPLL initially.
DDR3 can work at normal OPP from initialozation

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2012-07-07 14:07:24 +02:00
Aneesh V
03f69dc6fd omap4+: Avoid using __attribute__ ((__packed__))
Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. "packed" will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.

Signed-off-by: Aneesh V <aneesh@ti.com>
2012-05-15 08:31:26 +02:00
SRICHARAN R
d417d1db5f OMAP3+: reset: Create a common reset layer.
The reset.S has the function to do a warm reset on OMAP
based socs. Moving this to a reset.c file so that this
acts a common layer to add any reset related functionality
for the future.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:25 +02:00
SRICHARAN R
c1fa3c37af OMAP4/5: device: Add support to get the device type.
Add support to identify the device as GP/EMU/HS.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:24 +02:00
SRICHARAN R
002a2c0c66 OMAP4/5: Make the sysctrl structure common
Make the sysctrl structure common, so that it can
be used in generic functions across socs.
Also change the base address of the system control module, to
include all the registers and not simply the io regs.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:24 +02:00
SRICHARAN R
087189fb54 OMAP4/5: Make the silicon revision variable common.
The different silicon revision variable names was defined for OMAP4 and
OMAP5 socs. Making the variable common so that some code can be
made generic.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:24 +02:00
SRICHARAN R
8de17f4617 OMAP5: palmas: Configure nominal opp vdd values
The nominal opp vdd values as recommended for
ES1.0 silicon is set for mpu, core, mm domains using palmas.

Also used the right sequence to enable the vcores as per
a previous patch from Nishant Menon, which can be dropped now.
	http://lists.denx.de/pipermail/u-boot/2012-March/119151.html

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:23 +02:00
Nishanth Menon
3acb553439 OMAP4460: TPS Ensure SET1 is selected after voltage configuration
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>
2012-05-15 08:31:22 +02:00
Nishanth Menon
a78274b205 OMAP3+: Introduce generic logic for OMAP voltage controller
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>
2012-05-15 08:31:22 +02:00
Jonathan Solnit
bbbc1ae921 ARM:OMAP+:MMC: Add parameters to MMC init
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>
2012-05-15 08:31:22 +02:00
Tom Rini
a7778f8fbe omap_hsmmc: Wait for CMDI to be clear
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>
2012-02-15 17:42:22 -06:00
Govindraj.R
43b62393da ehci-omap: Clean up added ehci-omap.c
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>
2012-02-12 10:11:31 +01:00
Andreas Müller
761ca31e47 omap_rev_string: output to stdout
* avoid potential buffer overflows
* allow SPL-build not to output "Texas Instruments Revision detection unimplemented"

Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
Signed-off-by: Tom Rini <trini@ti.com>
2012-01-16 08:40:13 +01:00
Aneesh V
fe7104b307 omap4: fix boot issue on ES2.0 Panda
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>
2012-01-16 08:40:11 +01:00
Chris Lalancette
df65a3fe35 omap4_panda: Initialize the USB phy
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>
2011-12-19 17:52:44 +01:00
Aneesh V
9404758e9b omap4460: add ES1.1 identification
Signed-off-by: Aneesh V <aneesh@ti.com>
2011-12-06 23:59:34 +01:00
Sricharan
78f455c055 omap4/5: Add support for booting with CH.
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>
2011-11-15 22:25:50 +01:00
Sricharan
bb772a5944 omap5: emif: Add emif/ddr configurations required for omap5 evm
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>
2011-11-15 22:25:50 +01:00
Sricharan
2e5ba48928 omap5: clocks: Add clocks support for omap5 platform.
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>
2011-11-15 22:25:50 +01:00
Sricharan
508a58fa8e omap5: Add minimal support for omap5430.
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>
2011-11-15 22:25:50 +01:00
Sricharan
933efe641a omap: Checkpatch fixes
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>
2011-11-15 22:25:50 +01:00
Tom Rini
cc3f705843 OMAP3 SPL: Provide weak omap_rev_string
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>
2011-10-27 21:56:35 +02:00
Ricardo Salveti de Araujo
8f6a027f62 omap4: adding revision detection for 4460 ES1.1
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@linaro.org>

 2 files changed, 17 insertions(+), 1 deletions(-)
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-10-27 21:56:33 +02:00
Ricardo Salveti de Araujo
20033c9f87 omap4: replacing OMAP4_CONTROL with OMAP4430_CONTROL
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>
2011-10-27 21:56:33 +02:00
Balaji T K
14fa2dd00f mmc: omap: config VMMC, MMC1_PBIAS
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>
2011-09-30 22:00:55 +02:00
Aneesh V
4ecfcfaa9e omap4: IO settings
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>
2011-09-13 08:25:16 +02:00
Aneesh V
025bc4254b omap4: make SDRAM init work for ES1.0 silicon
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>
2011-09-13 08:25:15 +02:00
Aneesh V
34455b04fc omap4: fix build warning due to signed unsigned comparison
Signed-off-by: Aneesh V <aneesh@ti.com>
2011-09-04 11:34:09 +02:00
Aneesh V
080a46eaf1 omap: fix gpio related build breaks
Signed-off-by: Aneesh V <aneesh@ti.com>
Acked-by: Dirk Behme <dirk.behme@googlemail.com>
2011-09-04 11:33:36 +02:00
Aneesh V
b4dc644291 omap4: clock init support for omap4460
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:20 +02:00
Aneesh V
d506719f7f omap4: support TPS programming
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>
2011-08-03 12:49:20 +02:00
Aneesh V
25223a68e5 omap: reuse omap3 gpio support in omap4
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:20 +02:00
Aneesh V
924eb369e3 omap4: sdram init changes for omap4460
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:20 +02:00
Aneesh V
5ab12a9eeb omap4: add omap4460 revision detection
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:20 +02:00
Aneesh V
8cf686e19b omap: add MMC and FAT support to SPL
- 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>
2011-08-03 12:49:20 +02:00
Aneesh V
bcae721162 omap: add basic SPL support
- 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>
2011-08-03 12:49:20 +02:00
Aneesh V
095aea293b omap4: calculate EMIF register values
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>
2011-08-03 12:49:19 +02:00
Aneesh V
2ae610f030 omap4: add sdram init support
Add support for the SDRAM controller (EMIF).

Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:19 +02:00
Aneesh V
3776801d0a omap4: add clock support
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>
2011-08-03 12:49:19 +02:00
Aneesh V
ad577c8a48 omap4: add OMAP4430 revision check
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-08-03 12:49:19 +02:00
Aneesh V
469ec1e353 omap4: cleanup pin mux data
- 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>
2011-08-03 12:49:19 +02:00
Aneesh V
d2f18c275e omap4: utility function to identify the context of hw init
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>
2011-08-03 12:49:19 +02:00
Aneesh V
8b457fa828 armv7: adapt omap4 to the new cache maintenance framework
adapt omap4 to the new layered cache maintenance framework

Signed-off-by: Aneesh V <aneesh@ti.com>
2011-07-04 10:55:25 +02:00