725233: PLD instructions executed with PLD data forwarding
enabled can result in a processor deadlock
This deadlock can happen when NEON load instructions are used together
with cache preload instructions (PLD). The problematic conditions
can be triggered in-the-wild by NEON optimized functions from pixman
library (http://cgit.freedesktop.org/pixman), which perform dynamic
adjustment of prefetch distance.
The workaround disables PLD data forwarding by setting PLD_FWD bit
in L2 Cache Auxiliary Control Register as recommended in ARM Cortex-A8
errata list.
The deadlock can only happen on r1pX revisions of Cortex-A8 (used in
OMAP34xx/OMAP35xx). Performance impact of the workaround is practically
non-existant.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
In function get_osc_clk_speed(), do not change/ update
the divider for SYS_CLK as it can has cascading effect
on the other derived clocks.
Sudden change in divider value can lead to inconsistent
behavior in the system - often leading to crashes.
The problem was found when working with OMAP3EVM using
DM3730 processor card.
The patch has been tested with OMAP3530 on OMAP3EVM as
well
Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Hiremath Vaibhav <hvaibhav@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
According to the PPC reference implementation the udelay() function is
responsible for resetting the watchdog timer as frequently as needed.
Most other architectures do not meet that requirement, so long-running
operations might result in a watchdog reset.
This patch adds a generic udelay() function which takes care of
resetting the watchdog before calling an architecture-specific
__udelay().
Signed-off-by: Ingo van Lil <inguin@gmx.de>
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon <nm@ti.com>
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Fixes issues identified by Dirk:
- build issue for zoom2
- warnings for all other OMAP3 platforms using nand/onenand etc
Signed-off-by: Nishanth Menon <nm@ti.com>
v7_flush_dcache_all, because it depends on omap ROM code is not
generic. Rename the function to 'invalidate_dcache' and move it
to the omap cpu directory.
Collect the other omap cache routines l2_cache_enable and
l2_cache_disable with invalide_dcache into cache.S. This
means removing the old cache.c file that contained l2_cache_enable
and l2_cache_disable.
The conversion from cache.c to cache.S was done most through
disassembling the uboot binary. The only significant change was
to change the comparision for the return of get_cpu_rev from
cmp r0, #0
beq earlier_than_label
Which was lost information to
cmp r0, #CPU_3XX_ES20
blt earlier_than_label
The paths through the enable routine were verified by
adding an infinite loop and seeing the hang. Then
removing the infinite loop and seeing it continue.
The disable routine is similar enough that it was not
tested with this method.
Run tested by cold booting from nand on beagle and zoom1.
Compile tested on MAKEALL arm.
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>
For some time there have been repeated reports about build problems
with some ARM (cross) tool chains. Especially issues about
(in)compatibility with the tool chain provided runtime support
library libgcc.a caused to add and support a private implementation
of such runtime support code in U-Boot. A closer look at the code
indicated that some of these issues are actually home-made. This
patch attempts to clean up some of the most obvious problems and make
building of U-Boot with different tool chains easier:
- Even though all ARM systems basicy used the same compiler options
to select a specific ABI from the tool chain, the code for this was
distributed over all cpu/*/config.mk files. We move this one level
up into lib_arm/config.mk instead.
- So far, we only checked if "-mapcs-32" was supported by the tool
chain; if yes, this was used, if not, "-mabi=apcs-gnu" was
selected, no matter if the tool chain actually understood this
option. There was no support for EABI conformant tool chains.
This patch implements the following logic:
1) If the tool chain supports
"-mabi=aapcs-linux -mno-thumb-interwork"
we use these options (EABI conformant tool chain).
2) Otherwise, we check first if
"-mapcs-32"
is supported, and then check for
"-mabi=apcs-gnu"
If one test succeeds, we use the first found option.
3) In case 2), we also test if "-mno-thumb-interwork", and use
this if the test succeeds. [For "-mabi=aapcs-linux" we set
"-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the
Linux kernel does.
- Some EABI conformant tool chains cause external references to
utility functions like raise(); such functions are provided in the
new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must
make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Dirk Behme <dirk.behme@googlemail.com>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Acked-by: Sergey Kubushyn <ksi@koi8.net>
Tested-by: Magnus Lilja <lilja.magnus@gmail.com>
Tested-by: Andrzej Wolski <awolski@poczta.fm>
Tested-by: Gaye Abdoulaye Walsimou <walsimou@walsimou.com>
Tested-by: Tom Rix <Tom.Rix@windriver.com>
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Embedd chip select configuration into struct for gpmc config
instead of having it completely separated as suggested by
Wolfgang Denk on
http://lists.denx.de/pipermail/u-boot/2009-May/052247.html
Signed-off-by: Matthias Ludwig <mludwig@ultratronik.de>
Because of the reset_cpu is soc specific, should be move to soc
Cc: Dirk Behme <dirk.behme@googlemail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Many of the help messages were not really helpful; for example, many
commands that take no arguments would not print a correct synopsis
line, but "No additional help available." which is not exactly wrong,
but not helpful either.
Commit ``Make "usage" messages more helpful.'' changed this
partially. But it also became clear that lots of "Usage" and "Help"
messages (fields "usage" and "help" in struct cmd_tbl_s respective)
were actually redundant.
This patch cleans this up - for example:
Before:
=> help dtt
dtt - Digital Thermometer and Thermostat
Usage:
dtt - Read temperature from digital thermometer and thermostat.
After:
=> help dtt
dtt - Read temperature from Digital Thermometer and Thermostat
Usage:
dtt
Signed-off-by: Wolfgang Denk <wd@denx.de>
The function and interface clocks for each GPIO bank, except the first, must
be explicitly turned on. These are controlled by the config level defines
CONFIG_OMAP3_GPIO_n where n is from 2 to 6.
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>
Acked-by: Dirk Behme <dirk.behme@googlemail.com>
all arm boards except a few use the same cpu linker script
so move it to cpu/$(CPU)
that could be overwrite in following order
SOC
BOARD
via the corresponding config.mk
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Port version 2.6.27 of the linux kernel's omap gpio interface to u-boot.
The orignal source is in linux/arch/arm/plat-omap/gpio.c
See doc/README.omap3 for instructions on use.
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>
The u-boot.lds file is common for all omap boards.
Move a cleaned up version to the cpu layer and add makefile logic to use it.
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>
actually the timer init use the interrupt_init as init callback
which make the interrupt and timer implementation difficult to follow
so now rename it as int timer_init(void) and use interrupt_init for interrupt
btw also remane the corresponding file to the functionnality implemented
as ixp arch implement two timer - one based on interrupt - so all the timer
related code is moved to timer.c
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Remove duplicated interrupt code. Original, identical code can be found
in lib_arm/interrupts.c
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
Signed-off-by: Sanjeev Premi <premi@ti.com>
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument; which is ignored.
This patch removes all uses of board-type, related definitions
and functions.
Signed-off-by: Sanjeev Premi <premi@ti.com>
Use the functions print_cpuinfo() and checkboard() to
display the cpu and board specific information.
These functions reuse content from the existing function
display_board_info() - which has been removed.
Also, updated the existig OMAP3 configurations to
define:
- CONFIG_DISPLAY_CPUINFO
- CONFIG_DISPLAY_BOARDINFO
Signed-off-by: Sanjeev Premi <premi@ti.com>
Fixes this compile error:
board.c: In function 'do_switch_ecc':
board.c:339: error: 'cmd_tbl_t' has no member named 'help'
make[1]: *** [board.o] Error 1
make[1]: Leaving directory `/db/psp_git/users/a0756819/u-boot/cpu/arm_cortexa8/omap3'
make: *** [cpu/arm_cortexa8/omap3/libomap3.a] Error 2
This is due to the fact that current command uses long
help for the usage print even if the CONFIG_SYS_LONGHELP
is not enabled. (Thanks Jean-Christophe for explanation).
Signed-off-by: Sanjeev Premi <premi@ti.com>
Divisor field is called PTV not PVT.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
This patch adds OMAP3 cpu type auto detection based on OMAP3 register
and removes hardcoded values.
Signed-off-by: Steve Sakoman <sakoman@gmail.com>
Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>