A divider of 5 is required to get the right period value to be
set for a given sysclk frequency. This is a fixed-constant for
all sysclks.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Locking control_core_mmr_lock1 register results in regions 0x00000100
to 0x0000079F locked out(includes key registers for bandgap etc). This
means that any write accesses will fail to reflect results without a
clear notification.
So, leave the control module unlocked.
TODO: SPL should reflect consistent behavior for entire Control module
space which includes LOCK_1-5 regions left open -> if this is done,
this should be implemented in a generic location independent of the
current logic.
Reported-by: Yan Liu <yan-liu@ti.com>
Reported-by: Mugunthan V <mugunthanvnm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
build recalibrate_io_delay only for SPL logic - SHOULD NOT be used in
DDR execution context (example in u-boot).
Reported-by: Yan Liu <yan-liu@ti.com>
Reported-by: Mugunthan V <mugunthanvnm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
If changing to AVS0 voltage is required for development purpose,
there will be some IO timing error versus datasheet. The below
sequence is required to recalibrate the IOs after AVS is done.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The bit DDR3_RST_DEF_VAL inside CTRL_DDR_IO represents the default value
of the ddr reset value for DDR3 before the EMIF takes over. We must have
this bit set high so that on exit from DeepSleep0 within the kernel the
reset line has the proper value.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The register secure_emif_sdram_config in control module is copied to
the EMIF sdram_config register when it is coming out of DeepSleep0 in
order to ensure that the EMIF comes up for the correct type of DDR.
Without this, resume can hang from within the kernel.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Per a suggestion from the hardware team, program the emif_pwr_mgmt_ctrl
and emif_pwr_mgmt_ctrl_shdw registers within the EMIF to hold the
desired delay in cycles that the EMIF waits without an access to enter
self-refresh, in this case 8192 cycles. With this, code desiring to
enter self refresh only has to toggle one bit to enable it.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
After enabling a module, SW has to wait on IDLEST bit
until it is Fully functional. This wait is missing for UART module
and there is a immediate access of UART registers after this. So there
is a chance of hang on this module( This can happen when we are running
from MPU SRAM). So waiting for IDLEST bit.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
commit ef236f2929
(DRA7: Add support for ES1.1 silicon ID code)
from upstream does not contain the TI internal changes necessary.
The missing change for emif is now incorporated
Reported-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ES1.1 silicon is a very minor variant of ES1.0. Add priliminary support
for ES1.1 IDCODE change.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
A generic is_dra7xx cpu check is useful for grouping
all the revisions under that. This is used in the
subsequent patches.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Schematic indicates GPIO5_7 is to be used for VTT regulator control
rather than GPIO0_21 so modify enable_vtt_regulator to reflect this.
Without this some boards will experience DDR3 corruption and fail to
boot.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
This patch enables dynamically powering down the
IO receiver when not performing a read.
This optimizes both active and standby power consumption.
This bit is not set on EVM SK and EVM 1.5 and later boards.
Setting the same.
This has been tested on PG2.0 EVM1.5, EVM1.2, EVM-SK, BBB.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Satyanarayana, Sandhya <sandhya.satyanarayana@ti.com>
As per the latest 0.6 version of DM for OMAP5430 ES2.0,
MPU_GCLK is given as 1000MHz. In order to achieve this DPLL_MPU
should be locked at 2000MHz. Fixing the same and cleaning the
previously used dpll values.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In EMIF4 blocks of AM335x/TI81XX there is a register at 0x54 called
INT_CONFIG/PBBPR that has a field called PR_OLD_CONFIG that can be
changed depending on workloads of the system to ensure that accesses to
some areas don't cause accesses to other areas to be "stalled". This
can be seen for example as screen jitter when playing videos.
Signed-off-by: Tom Rini <trini@ti.com>
Most of TI's SoC platform have in-buit GPMC (General Purpose Memory Controller)
which can be used to interface different types of external memories like:
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
This patch:
- As the GPMC hardware engine is common across all OMAPx and AMxxxx platforms,
so GPMC initialization code from all platforms is merged into single file:
arch/arm/cpu/armv7/omap-common/mem-common.c
- But as different platforms support different operating clock frequencies,
So, same memory device can have different GPMC configuration values on
different platforms (like memory signal timing values of same device may
differ on different platforms). Hence actual GPMC configuration parameters
are still kept separately in following platform specific header files:
AM33xx: [unchanged] arch/arm/include/asm/arch-am33xx/mem.h
OMAP3: [modified] arch/arm/include/asm/arch-omap3/mem.h
OMAP4: [new] arch/arm/include/asm/arch-omap4/mem.h
OMAP5: [new] arch/arm/include/asm/arch-omap5/mem.h
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch adds OMAP5 platform specific information to enable GPMC controller,
which can interface different types of external memories like:
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch adds OMAP4 platform specific information to enable in-built GPMC and
ELM controller, which can interface following types of external memories:
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
Signed-off-by: Pekon Gupta <pekon@ti.com>
Commit "armv7: hw_data: change clock divider setting"
updates the setting for m6 divider for 20MHz sys_clk frequency.
But missed to update for other sys_clk frequencies. Doing the same.
Reported-by: Rajendran, Vinothkumar <vinothr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Commit "ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039"
introduces the following build error.
arch/arm/cpu/armv7/omap-common/libomap-common.o: In function `do_bug0039_workaround':
/home/lokesh/exp/mainline/u-boot/arch/arm/cpu/armv7/omap-common/emif-common.c:1284: undefined reference to `get_bug_regs'
This is because of missing function call in OMAP4. Adding a weak function
for this.
Reported-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Commit "ARM: OMAP5: DRA7xx: Add workaround for ARM errata 798870"
introduces the follwoing build warning for OMAP5 and build break for OMAP4.
hwinit-common.c: In function 's_init':
hwinit-common.c:132:2: warning: implicit declaration of function 'arm_errata_798870' [-Wimplicit-function-declaration]
As this function is called for both OMAP5 and OMAP4 and defined only for OMAP5
causing a build error for OMAP4
Fixing by moving this function common to OMAP4/5.
This will not break any functionality on OMAP4 as it checks for A15.
Reported-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
omap_elm.h is a generic header used by OMAP ELM driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related
defines and declarations scattered in SoC platform specific header files
like include/asm/arch-xx/cpu.h
However, GPMC hardware remains same across all platforms thus this patch merges
GPMC data scattered across different arch-xx specific header files into single
header file include/asm/arch/omap_gpmc.h
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
OMAP NAND driver can detect Page-size and OOB-size of NAND device from ONFI
params or nand_id[] table. And based on that it defines ECC layout.
This patch
1) removes following board configs used for defining NAND ECC layout
- GPMC_NAND_ECC_LP_x16_LAYOUT (for large page x16 NAND)
- GPMC_NAND_ECC_LP_x8_LAYOUT (for large page x8 NAND)
- GPMC_NAND_ECC_SP_x16_LAYOUT (for small page x16 NAND)
- GPMC_NAND_ECC_SP_x8_LAYOUT (for small page x8 NAND)
2) removes unused #defines in common omap_gpmc.h depending on above configs
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
Currently there are two sets of omap_gpmc.h header files
(a) arch/arm/include/asm/omap_gpmc.h
common header file for all platforms, containing defines and declarations used
by GPMC NAND driver.
(b) arch/arm/include/asm/arch-xx/omap_gpmc.h
SoC platform specific header file containing defines like ECC layout.
This patch removes platform specific arch-xx/omap_gpmc.c because:
- GPMC hardware engine is common for all SoC platforms hence only (a) is enough
- ECC layout is now defined in omap_nand.c driver itself based on ecc-scheme
selected. Hence all ECC layout declarations in (b) are redundant.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
chip->ecc.hwctl() is used for preparing the H/W controller before read/write
NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.)
Though all ECC schemes in OMAP NAND driver use GPMC controller for generating
ECC syndrome (for both Read/Write accesses). But but in current code
HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this.
This patch
(1) removes omap_hwecc_init() and omap_hwecc_init_bch()
as chip->ecc.hwctl will re-initializeGPMC before every read/write call.
omap_hwecc_init_bch() -> omap_enable_ecc_bch()
(2) merges the GPMC configuration code for all ECC schemes into
single omap_enable_hwecc(), thus adding scalability for future ECC schemes.
omap_enable_hwecc() + omap_enable_ecc_bch() -> omap_enable_hwecc()
Signed-off-by: Pekon Gupta <pekon@ti.com>
GPMC controller is common IP to interface with both NAND and NOR flash devices.
Also, it supports max 8 chip-selects, which can be independently connected to
any of the devices.
But ROM code expects the boot-device to be connected to only chip-select[0].
Thus to resolve conflict between NOR and NAND boot. This patch:
- combines NOR and NAND configs spread in board files to common gpmc_init()
- configures GPMC based on boot-mode selected for SPL boot.
Signed-off-by: Pekon Gupta <pekon@ti.com>
BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
+-----------------------------------+-----------------+-----------------+
|ECC Scheme | ECC Calculation | Error Detection |
+-----------------------------------+-----------------+-----------------+
|OMAP_ECC_BCH8_CODE_HW |GPMC |ELM H/W engine |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC |S/W BCH library |
+-----------------------------------+-----------------+-----------------+
Current implementation limits the BCH8_CODE_HW only for AM33xx device family.
(using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have
ELM hardware module, and can support ECC error detection using ELM.
This patch
- removes CONFIG_AM33xx
Thus this driver can be reused by all devices having ELM h/w engine.
- adds omap_select_ecc_scheme()
A common function to handle ecc-scheme related configurations. This
can be used both during device-probe and via user-space u-boot commads
to change ecc-scheme. During device probe ecc-scheme is selected based
on CONFIG_NAND_OMAP_ELM or CONFIG_NAND_OMAP_BCH8
- enables CONFIG_BCH
S/W library (lib/bch.c) required by OMAP_ECC_BCHx_CODE_HW_DETECTION_SW
is enabled by CONFIG_BCH.
- enables CONFIG_SYS_NAND_ONFI_DETECTION
for auto-detection of ONFI compliant NAND devices
- updates following README doc
doc/README.nand
board/ti/am335x/README
doc/README.omap3
Signed-off-by: Pekon Gupta <pekon@ti.com>
ELM hardware engine which is used for ECC error detection, is present on all
latest OMAP SoC (like OMAP4xxx, OMAP5xxx, DRA7xxx, AM33xx, AM43xx). Thus ELM
driver should be moved to common drivers/mtd/nand/ folder so that all SoC
having on-chip ELM hardware engine can re-use it.
This patch has following changes:
- mv arch/arm/include/asm/arch-am33xx/elm.h arch/arm/include/asm/omap_elm.h
- mv arch/arm/cpu/armv7/am33xx/elm.c drivers/mtd/nand/omap_elm.c
- update Makefiles
- update #include <asm/elm.h>
- add CONFIG_NAND_OMAP_ELM to compile driver/mtd/nand/omap_elm.c
and include in all board configs using AM33xx SoC platform.
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch adds workaround for ARM errata 798870 which says
"If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock."
Signed-off-by: Praveen Rao <prao@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[1]: http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Matt Porter <matt.porter@linaro.org>
Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Tom Rini <trini@ti.com>
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>
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C).
Adding details for the same.
Below is the brief description of DDR3 init sequence(SW leveling):
-> Enable VTT regulator
-> Configure VTP
-> Configure DDR IO settings
-> Disable initialization and refreshes until EMIF registers are programmed.
-> Program Timing registers
-> Program leveling registers
-> Program PHY control and Temp alert and ZQ config registers.
-> Enable initialization and refreshes and configure SDRAM CONFIG register
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
Adding LPDDR2 init sequence and register details for the same.
Below is the brief description of LPDDR2 init sequence:
-> Configure VTP
-> Configure DDR IO settings
-> Disable initialization and refreshes until EMIF registers are programmed.
-> Program Timing registers
-> Program PHY control and Temp alert and ZQ config registers.
-> Enable initialization and refreshes and configure SDRAM CONFIG register
-> Wait till initialization is complete and the configure MR registers.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This is a known issue on AM4372 that when there is a burst read to a
non-cacheable EMIF address space and the burst crosses 1K address boundary will
result in a hang. Since U-boot runs from DDR, there is a possibility that above
case occurs. So enable caches at the beginning of U-boot.
*This is a temporary fix and not meant for mainline.*
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Commit "am335x: Enable RTC 32K OSC clock" describes the dependency
to enable RTC clks in bootloader. This is not true for AM4372.
In EPOS EVM RTC is not powered (VDDS_RTC grounded to 0). In GP EVM no
need to enble RTC in bootloader. So moving RTC enbling to its respective clock file.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Sricharan R
Nishanth Menon
Sourav Poddar
Dave Gerlach
Lokesh Vutla
Satyanarayana, Sandhya
Dan Murphy
Tom Rini
Pekon Gupta
Mugunthan V N
Praveen Rao
Roger Quadros