This commit changes the working directory
where the build process occurs.
Before this commit, build process occurred under the source
tree for both in-tree and out-of-tree build.
That's why we needed to add $(obj) prefix to all generated
files in makefiles like follows:
$(obj)u-boot.bin: $(obj)u-boot
Here, $(obj) is empty for in-tree build, whereas it points
to the output directory for out-of-tree build.
And our old build system changes the current working directory
with "make -C <sub-dir>" syntax when descending into the
sub-directories.
On the other hand, Kbuild uses a different idea
to handle out-of-tree build and directory descending.
The build process of Kbuild always occurs under the output tree.
When "O=dir/to/store/output/files" is given, the build system
changes the current working directory to that directory and
restarts the make.
Kbuild uses "make -f $(srctree)/scripts/Makefile.build obj=<sub-dir>"
syntax for descending into sub-directories.
(We can write it like "make $(obj)=<sub-dir>" with a shorthand.)
This means the current working directory is always the top
of the output directory.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Gerhard Sittig <gsi@denx.de>
The commit
f3f98bb0 : "ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls"
removed the config option aimed towards moving that stuff into kernel, which
renders some code unreachable. Remove that code.
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
When core power domain hits oswr, then DDR3 memories does not come back
while resuming. This is because when EMIF registers are lost, then the
controller takes care of copying the values from the shadow registers.
If the shadow registers are not updated with the right values, then this
results in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The struct incorrectly referenced SMPS1 for all three power
domains. Fixed this by using SMPS2 and SMPS5 as appropriate.
Add some comments and choose voltage values that correspond
to voltage selection codes.
Signed-off-by: Lubomir Popov <l-popov@ti.com>
OMAP4 panda rev A6 is a 4430 es2.3 IC with an updated memory
part.
The panda rev A6 uses Elpida 2x4Gb memory and no longer uses Micron
so the timings needs to be updated
Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAP4470 SDP SoM has EDB8164B3PF PoP memory on board.
This memory has 4Gb x 2CS = 8Gb configuration.
Add configuration for runtime calculation and precalculated cases.
Patch is based on a draft Lubomir's patch [1].
[1] http://lists.denx.de/pipermail/u-boot/2013-April/150851.html
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
[taras@ti.com: cleaned up patch and fixed precalculated values]
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4470 reference design uses TWL6032 PMIC
with a following connection scheme:
VDD_CORE = TWL6032 SMPS2
VDD_MPU = TWL6032 SMPS1
VDD_IVA = TWL6032 SMPS5
Set voltage and frequency values according to
OMAP4470 Data Manual Operating Condition Addendum v0.7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Voltage scaling can be done in two ways:
-> Using SR I2C
-> Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The omap4460_volts struct was incorrectly referencing tps62361
instead of twl6030 as PMIC for the core and mm voltages (the
tps is used for mpu supply only). This shall lead to bad OPP
settings while booting kernel. Fixing it.
Fix some comments as well.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
Commit "8602114 omap: emif: configure emif only when required"
breaks SDRAM_AUTO_DETECTION.
The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection)
done in do_sdram_init(). The above commit moves dmm_init() above
do_sdram_init() because of which dmm_init() uses uninitialized
emif_sizes[].
So instead of using global emif_sizes[], get sdram details locally
and calculate emif sizes.
Reported-by: Michael Cashwell <mboards@prograde.net>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA752 uses DDR3. Populating the corresponding structures
with DDR3 data.
Writing into MA registers if only MA is present in that soc.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
A new DPLL DDR is added in DRA7XX socs. Now clocks to
EMIF CD is from DPLL DDR. So DPLL DDR should be locked
before initializing RAM.
Also adding other dpll data which are different from OMAP5 ES2.0.
SYS_CLK running at 20MHz is introduced in DRA7xx socs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
PRCM register addresses are changed from OMAP5 ES2.0 to DRA7XX.
So adding the necessary register changes for DRA7XX socs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Change OPP settings as per the latest 0.5 version of
addendum for OMAP5430 ES2.0. omap4/hw_data.c is touched
here to add dummy dividers.
While here correcting OPP_NOM mpu, core frequency for
OMAP4430 ES2.x
Note that OMAP5430 ES1.0 support is still kept alive and
would be removed in a cleanup later.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Cc: Tom Rini <trini@ti.com>
Cc: Nishanth Menon <nm@ti.com>
A seperate omap_sys_ctrl_regs structure is defined for
omap4 & 5. If there is any change in control module for
any of the ES versions, a new structure needs to be created.
In order to remove this dependency, making the register
structure generic for all the omap4+ boards.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Currently there is quite a lot of code which
is duplicated in the clocks code for OMAP 4 and 5
Socs. Avoiding this here by moving the clocks
data to a SOC specific place and the sharing the
common code.
This helps in addition of a new Soc with minimal
changes.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
The current PRCM structure prototype directly matches the hardware
register layout. So there is a need to change this for every new silicon
revision which has register space changes.
Avoiding this by making the prototye generic and populating the register
addresses seperately for all Socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
USB clocks will be required for fastboot, tftp
related functionalities. Move these clocks to
essential group inorder to have the functionality
working when non-essential clocks are not enabled.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
GPMC clocks are currently getting enabled as a part
non-essential clocks. This will be required during
NOR boot. Move this to essential group to keep the
functionality, when non-essential clocks are not
enabled.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
The external phy is present in the case OMAP5 soc is currently
configured in emif-common.c. This results in having dummy structures
for those Socs which do not have a external phy. So by having a weak
function in emif-common and overriding it in OMAP5, avoids the use
of dummy structures.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
This reduced M,N couple corresponds to the advised value from
TI HW team.
Tested on 4460 Pandaboard, it also provides peripheral clocks
closer to the advised values.
Signed-off-by: Sebastien Jan <s-jan@ti.com>
In OMAP5432 EMIF controlller supports DDR3 device.
This patch adds support for ddr3 device intialization and configuration.
Initialization sequence is done as specified in JEDEC specs.
This also adds support for ddr3 leveling.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Booting up these cores (dsp / ivahd / cortex-m3) is bad without
firmware running on them, and they will hang preventing any kind
of sleep transitions later on with the kernel.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: R Sricharan <r.sricharan@ti.com>
If this is done in the bootloader, the FS-USB will later be stuck into
intransition state, which will prevent the device from entering idle.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
This macro is generally useful to make it available in common.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Tom Rini <trini@ti.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
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>
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>
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>
The OMAP5 silicon has new DDR PHY design, which includes a external PHY
as well. So configuring the ext PHY parameters here. Also the EMIF timimg
registers and a couple of DDR mode registers needs to be updated based on
the testing from the actual silicon.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
OMAP4 requires that parent domains scale ahead of dependent domains.
This is due to the restrictions in timing closure. To ensure
a consistent behavior across all OMAP4 SoC, ensure that
vdd_core scale first, then vdd_mpu and finally vdd_iva.
As part of doing this refactor the logic to allow for future
addition of OMAP4470 without much ado. OMAP4470 uses different
SMPS addresses and cannot be introduced in the current code
without major rewrite.
Reported-by: Isabelle Gros <i-gros@ti.com>
Reported-by: Jerome Angeloni <j-angeloni@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
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>
We do not have thermal management or Smartreflex
enabled at U-Boot level. So, it's better to stick
to OPP100 for MPU instead of the OPP Turbo that is
used now. Adjust the VDD_MPU accordingly.
Tested-by: Sebastien Jan <s-jan@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Adding ehci clock enabling mechanism part of clock framework.
When essential clocks are enabled during init phase usb host
clocks can also be enabled from clock framework.
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Stefano Babic <sbabic@denx.de>
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>
The value from TRIM is not working for some 4430 silicons.
So, override with hw team recommended value. However, for
4460 TRIM value shall be used as long as the part is trimmed
This fixes boot problem on some OMAP4430 ES2.0 Panda boards
out there.
Cc: Steve Sakoman <sakoman@gmail.com>
Signed-off-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>
