Bulk erase is not happening properly on dra7 due to erase timing constraints,
add a delay so that erase timing constraints are properly met.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Tested-by: Yebio Mesfin <ymesfin@ti.com>
All parts of the pinmux information must be in the first 4 KiB. In
order to avoid some rather ugly linker script changes to ensure a
specific data segment was early enough, go back to asm for these pinmux
changes.
Signed-off-by: Tom Rini <trini@ti.com>
The fdt_high variable controls how high into memory the FDT can be moved
as part of booting the kernel. We had been disabling this feature as by
default we move to the very top of memory which can often be part of
highmem and so not visible to the kernel yet. However, in other cases
the kernel BSS can overwrite the FDT at the location we use, and we
wouldn't detect this case. The answer is to re-enable relocation, but
ensure it will be in kernel-visible memory still.
Signed-off-by: Tom Rini <trini@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>
As per OMAP3530 TRM referenced below [1]
For large-page NAND, ROM code expects following ecc-layout for HAM1 ecc-scheme
- OOB[1] (offset of 1 *byte* from start of OOB) for x8 NAND device
- OOB[2] (offset of 1 *word* from start of OOB) for x16 NAND device
Thus ecc-layout expected by ROM code for HAM1 ecc-scheme is:
*for x8 NAND Device*
+--------+---------+---------+---------+---------+---------+---------+
| xxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] | ...
+--------+---------+---------+---------+---------+---------+---------+
*for x16 NAND Device*
+--------+--------+---------+---------+---------+---------+---------+---------+
| xxxxx | xxxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] |
+--------+--------+---------+---------+---------+---------+---------+---------+
This patch fixes ecc-layout *only* for HAM1, as required by ROM-code
For other ecc-schemes like (BCH8) ecc-layout is same for x8 or x16 devices.
[1] OMAP3530: http://www.ti.com/product/omap3530
TRM: http://www.ti.com/litv/pdf/spruf98x
Chapter-25: Initialization Sub-topic: Memory Booting
Section: 25.4.7.4 NAND
Figure 25-19. ECC Locations in NAND Spare Areas
Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch fixes 'data-abort' while correcting bit-flips in BCH16 ecc-scheme,
when number of bit-flip counts was greater than 8.
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch adds CONFIG_SPL_NAND_DEVICE_WIDTH to specify bus-width of NAND device
CONFIG_SPL_NAND_DEVICE_WIDTH == 16: NAND device with x16 bus-width
CONFIG_SPL_NAND_DEVICE_WIDTH == 8: NAND device with x8 bus-width
Need for a separate CONFIG_xx arise from following situations.
(1) SPL NAND drivers does not have framework to parse ONFI parameter page.
(2) if !defined(CONFIG_SYS_NAND_SELF_INIT)
|- board_nand_init()
|- nand_scan()
|- nand_scan_ident()
|- nand_scan_tail()
This means board_nand_init() is called before nand_scan_ident(). So NAND
controller is initialized before the actual probing of NAND device.
However some controller (like GPMC) need to be specifically configured for
bus-width of NAND device.
In such cases, bus-width of the NAND device should be known in advance
of actual device probing. Hence, CONFIG_SPL_NAND_DEVICE_WIDTH is useful.
(3) Non-ONFI compliant devices need some mechanism to specify device bus-width
to driver.
Signed-off-by: Pekon Gupta <pekon@ti.com>
In 48ec5291, only TX path was optimized; this does the same also for RX
path. This results in huge increase of TFTP throughput on custom am3352
board (from 312KiB/s to 1.8MiB/s) and eliminates occasional transfer
timeouts.
Signed-off-by: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Tom Rini <trini@ti.com>
This patch
- Adds pin-mux for x8 parallel NAND device (MT29F4G08AB) present on AM43xx_EVM
- As above NAND device has blocksize=256k, pagesize=4k, oobsize=224, so by
design ROM code expects SPL to be flashed using BCH16 ECC scheme. Hence
CONFIG_NAND_OMAP_ECCSCHEME = OMAP_ECC_BCH16_CODE_HW is enabled.
- Specifies MTD partition table which needs same as kernel DTS for AM43xx_EVM.
- Populates other CONFIG_xx parameters required for NAND Boot on AM43xx
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch
- Groups all CONFIG_xx required for enabling parallel NAND on AM335x_EVM
into single file include/configs/am335x_evm.h
- Updates MTD partition table to include backup partitions for
u-boot, environment and u-boot-spl-os.
- Aligns MTD partitions (except for SPL partitions) such that partition offsets
and sizes remain constant for all NAND devices with blocksize=128k or 256k.
(because MTD partitions need to be aligned with blocksize boundary)
Signed-off-by: Pekon Gupta <pekon@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>
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page >= 26 * (page-size / 512)
Signed-off-by: Pekon Gupta <pekon@ti.com>
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page >= 26 * (page-size / 512)
Signed-off-by: Pekon Gupta <pekon@ti.com>
Increase read only segment size so that more peheripheral support can be
added to SPL like Ethernet or USB. The OCMC ram size is 256K, so allocating
~220K for read only segment.
Signed-off-by: Mugunthan V N <mugunthanvnm@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>
Updating EMIF_PHY_CTRL and adding EMIF_READ_WRITE_EXECUTION_THRESHOLD
registers.
In EMIF_PHY_CTRL:
Updating [4:0]READ_LATENCY to 8, because at higher frequencies like 400MHz the
read latency expected will be CL+3 as per tests from HW folks.
Clearing [19]PHY_DIS_CALIB_RST bit as this is used onl for debug
purpose. With out this resume is not working(Still waiting for PHY team to
come back for better explanation).
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>
NAND boot mode on AM335x EVM has been verified, and steps
to use it has been documented and update in this README
Signed-off-by: Pekon Gupta <pekon@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Tom Rini <trini@ti.com>
chip->ecc.correct() is used for detecting and correcting bit-flips during read
operations. In omap-nand driver it implemented as:
(a) omap_correct_data(): for h/w based ECC_HAM1 scheme
(b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
for ECC_BCH8 scheme using GPMC and software lib/bch.c
(c) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW
for ECC_BCH8 scheme using GPMC and ELM
This patch updates (c)
- checks for calc_ecc[]==0x00 so that error_correction is not required for
known good pages.
- adds scalability for other ECC_BCHx scheme by merging following
omap_rotate_ecc_bch() + omap_fix_errors_bch() => omap_correct_data_bch()
- fixing logic for bit-flip correction based on error_loc[count]
Signed-off-by: Pekon Gupta <pekon@ti.com>
chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by
processing the data passed during Read/Write accesses.
All H/W based ECC schemes use GPMC controller to calculate ECC syndrome.
But each BCHx_ECC scheme has its own implemetation of post-processing and
fetching ECC syndrome from GPMC controller.
This patch updates OMAP_ECC_BCH8_CODE_HW ECC scheme in following way:
- merges multiple chip->calculate API for different ECC schemes
omap_calculate_ecc() + omap_calculate_ecc_bch() + omap_calculate_ecc_bch_sw()
==> omap_calculate_ecc()
- removes omap_ecc_disable() and instead uses it as inline.
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>
This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed
CONFIG_xx used for selecting NAND ecc-schemes.
This patch aims at solving following issues.
1) Currently ecc-scheme is tied to SoC platform, which prevents user to select
other ecc-schemes also supported in hardware. like;
- most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite
the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with
software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW).
- most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware
supports BCH16 ecc-scheme also.
2) Different platforms use different CONFIG_xx to select ecc-schemes, which
adds confusion for user while migrating platforms.
- *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only
8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW)
whereas ELM hardware engine supports other ecc-schemes also like; BCH4,
and BCH16 (in future).
- *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error
correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW).
- *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library
Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency
on SoC platform and NAND driver. And user can select ecc-scheme independently
foreach board.
However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still
depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand)
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>
Introduce the usage of QSPI CH for DRA7xx instead of the default and
dummy CHSETTINGS. This CH is only valid for DRA7xx based devices and
is intended to speed up the boot for QSPI_1 device.
Change-Id: I9ab902f0597a758a48732b4dac18adc2e840f7ab
Signed-off-by: Carlos Leija <cileija@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Generalize CH structure to support different CH types based on the fact
that every configuration header entry is composed of a header section
and a data section with the settings intended to configure.
Change-Id: Ib32606dda9f9988cae5b85652f8e8c5bc21919d6
Signed-off-by: Carlos Leija <cileija@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Dan Murphy
Pekon Gupta
Sourav Poddar
Tom Rini
Vladimir Koutny
Mugunthan V N
Lokesh Vutla
Praveen Rao
Carlos Leija
Roger Quadros