Various errata exist in the Cortex-A9 CPU, and may be worked around by
setting some bits in a CP15 diagnostic register. Add code to implement
the workarounds, enabled by new CONFIG_ options.
This code was taken from the Linux kernel, v3.8, arch/arm/mm/proc-v7.S,
and modified to remove the logic to conditionally apply the WAR (since we
know exactly which CPU we're running on given the U-Boot configuration),
and use r0 instead of r10 for consistency with the rest of U-Boot's
cpu_init_cp15().
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Conflicts:
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
board/ait/cam_enc_4xx/u-boot-spl.lds
board/davinci/da8xxevm/u-boot-spl-da850evm.lds
board/davinci/da8xxevm/u-boot-spl-hawk.lds
board/vpac270/u-boot-spl.lds
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Turn __bss_start and __bss_end__ from linker-generated
to compiler-generated symbols, causing relocations for
these symbols to change type, from R_ARM_ABS32 to
R_ARM_RELATIVE.
This should have no functional impact, as it affects
references to __bss_start and __bss_end__ only before
relocation, and no such references are done.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Many SPL linker scripts needlessly include linker lists (aka LGAs).
Remove them whenever possible; keep it only in the seven am335x_evm
variants (am335x_evm, am335x_evm_uart[1-5], am335x_evm_spiboot),
where there is actual content in output section .u_boot_list.
This commit keeps all u-boot.bin and u-boot-spl.bin in ARM targets
byte-identical.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Output section .u_boot_list was left unmapped in
u-boot-spl.lds for omap-common, causing the location
counter to roll back to bteween .rodata and .data,
making __image_copy_end and _end symbols wrong.
Mapping output section .u_boot_list to memory .sram
fixes these symbols' mapping.
This modifies the SPL binary but has no functional
impact, as __image_copy_end and _end are never used
in SPLs and u_boot_list is empty for all 29 boards
affected (omap4_sdp4430 eco5pk igep0030 am335x_evm_uart3
omap3_beagle am3517_crane igep0032 mt_ventoux pcm051
am3517_evm omap3_evm_quick_mmc am335x_evm_uart2
am335x_evm_spiboot am335x_evm_uart1 omap3_evm igep0030_nand
omap3_overo igep0020 am335x_evm omap4_panda omap5_evm
am335x_evm_uart4 devkit8000 tricorder mcx twister
omap3_evm_quick_nand am335x_evm_uart5 igep0020_nand).
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
As the CPU name is not configurable, using CPU string directly
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
In master we had already taken a patch to fix the davinci GPIO code for
CONFIG_SOC_DM646X and in u-boot-ti we have additional patches to support
DA830 (which is CONFIG_SOC_DA8XX && !CONFIG_SOC_DA850). Resolve these
conflicts manually and comment the #else/#endif lines for clarity.
Conflicts:
arch/arm/include/asm/arch-davinci/gpio.h
drivers/gpio/da8xx_gpio.c
Signed-off-by: Tom Rini <trini@ti.com>
Adding CPU detection support for the DRA752 ES1.0 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>
Adding new board files for DRA7XX socs.
The pad registers layout is changed completely from OMAP5
So introducing the new structure here and also adding the
minimal data.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishant Kamat <nskamat@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
[trini: Adapt omap_mmc_init call for last 2 params]
Signed-off-by: Tom Rini <trini@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>
Control module register addresses are changed from OMAP5
to DRA7XX socs.
So adding the necessary changes for the same.
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>
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
The 1 in wkup domain is not enabled because smart i/os
of wkup domain work with default compensation 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>
Cc: Tom Rini <trini@ti.com>
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Cc: Tom Rini <trini@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>
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Cc: Tom Rini <trini@ti.com>
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Cc: Tom Rini <trini@ti.com>
Cc: Nishanth Menon <nm@ti.com>
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@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>
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new 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>
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects.
Changes in V4:
- Fix checkpatch errors (TAB -> space mangling)
Changes in V3:
- Fix line wrapping
Changes in V2:
- Indicate this is for AM33xx (not OMAP2)
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Some ONENAND related defines use the term ONE_NAND instead of
ONENAND, as the technology name is ONENAND this patch replaces
all these defines.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Currently, omap3_dss_panel_config() sets gfx_format to a value that is hardcoded
in the code. This forces anyone who wants to use a different gfx_format to make
adjustments after calling omap3_dss_panel_config(). This could be avoided if the
value of gfx_format were parameterized as input for omap3_dss_panel_config().
Make gfx_format a field in struct panel_config, and update existing structs to
set this field to the value that was originally hard coded.
Cc: Wolfgang Denk <wd@denx.de>
Cc: Jeroen Hofstee <jeroen@myspectrum.nl>
Cc: Tom Rini <trini@ti.com>
Cc: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
The various mmc_host_def.h files are almost identical.
Reduce code duplication by moving the similar definitions to a common
header file.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Based on
http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
we need to re-work our sequence in config_sdram slightly to match what
the TRM describes as the correct sequence. In our current (incorrect)
sequence some edge cases may fail to initalize correctly.
Signed-off-by: Tom Rini <trini@ti.com>
This does not actually change normal behaviour, but adds a check that
should detect corruption of relocation data (e.g. by using BSS data
prior to relocation).
Also add additional debugging output when enabled.
During this investigation, two situations have been seen:
1. calculate_relocation_address():
uintptr_t size = (uintptr_t)&__bss_end - (uintptr_t)&__text_start;
turns into
111166f: b8 83 c4 17 01 mov $0x117c483,%eax
whih is beyond the end of bss:
0117b484 g .bss 00000000 __bss_end
Somehow the __bss_end here is 255 bytes ahead.
2. do_elf_reloc_fixups():
uintptr_t size = (uintptr_t)&__bss_end - (uintptr_t)&__text_start;
Here the __text_start is 0 in the file:
1111d9f: bb a0 e0 13 01 mov $0x113e0a0,%ebx
1111da4: 81 ef 00 00 00 00 sub $0x0,%edi
As it happens, both of these are in pre-relocation code.
For these reasons we silent check and ignore bad relocations.
Signed-off-by: Simon Glass <sjg@chromium.org>
With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate
it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present BSS data is including in the image, which wastes binary space.
Remove it by rearranging the sections so that BSS is last.
Signed-off-by: Simon Glass <sjg@chromium.org>
With this symbol we can easy append something (e.g. an FDT) to the U-Boot
binary and access it from within U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Add new global_data members to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
The memory layout calculations are done in calculate_relocation_address(),
and coreboot has its own version of this function. But in fact all we
really need is to set the top of usable RAM, and then the base version
will work as is.
So instead of allowing the whole calculate_relocation_address() function
to be replaced, create board_get_usable_ram_top() which can be used by
a board to specify the top of the area where U-Boot relocations to.
Signed-off-by: Simon Glass <sjg@chromium.org>
This implementation uses opendir()/readdir() to access the directory
information and then puts it in a linked list for the caller's use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
Add Bf60x resume from hibernate support
Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Sonic Zhang <sonic.adi@gmail.com>
Spi driver for bf60x is different from old one, so implement a new
driver for it.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Sonic Zhang <sonic.adi@gmail.com>
Add rsi/sdh support for bf60x.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Sonic Zhang <sonic.adi@gmail.com>
