Since the CS of a device connected to the GPMC was
stored in the global variable, it was not possible to
use multiple devices. In this patch the CS is stored per
device in its 'struct omap_nand_info'. This makes it
possible to use up to 'GPMC_MAX_CS' NAND Flash devices
connected to U-boot.
Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
In case when 4K page keystone RBL layout is used the compilation
error is appeared. That's because the #ifdef has to be placed under
struct name. This patch correct it.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Make it configurable to disable subpage writes like the DaVinci NAND
driver already does.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
cc: Scott Wood <scottwood@freescale.com>
snyc with linux v3.15:
commit 1860e379875dfe7271c649058aeddffe5afd9d0d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Jun 8 11:19:54 2014 -0700
Linux 3.15
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>
while playing with the new mtd/ubi/ubifs sync, found some
small updates for it:
- add del_mtd_partition() to include/linux/mtd/mtd
- mtd: add a debug_printf
- remove some not used functions
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>
resync ubi subsystem with linux:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
A nice side effect of this, is we introduce UBI Fastmap support
to U-Boot.
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Joerg Krause <jkrause@posteo.de>
It's usually a common pattern to free() the memory that we allocated.
Implement this here to stop leaking memory.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
The Keystone SoCs use the same NAND driver as Davinci.
This patch adds opportunity to write Keystone U-boot image to NAND
device using appropriate RBL ECC layout. This is needed only if RBL
boots U-boot from NAND device and that's supposed that raw u-boot
partition is used only for writing image.
The main problem is that default Davinci ECC layout is different from
Keystone RBL layout. To read U-boot image the RBL needs that image was
written using RBL ECC layout.
The BBT table is written using default Davinci layout and has to
be updated using one. The BBT can be updated only while erasing
chip or by forced bad block assigning, so erase function has to
use native ecc layout in order to be able to write BBT correctly.
So if we're writing to NAND U-boot address we use RBL layout for
others we use default ECC layout.
Also remove definition for CONFIG_CMD_NAND_ECCLAYOUT as there is no
reasons to use ECC layout commands. It was added by mistake.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
enable the W#/Vpp signal to disable writing to the status
register on ST MICRON flashes like the N25Q128 thorugh
the new config option CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Internal SRAM has been incresed from 8KB to 16KB for IFC cotroller ver 2.0.
Update the page offset calculation logic to support the same.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
IFC controller v1.1.0 requires internal SRAM initialize by reading
NAND flash. Higher controller versions have provided "SRAM init" bit in
NCFGR register space.
update SRAM initialize logic to reflect the same.
Also print error message in case of Page read error.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
The number of chip select used by IFC controller vary from one SoC to other.
For eg. P1010 has 4, T4240 has 8.
Update MAX_BANKS same as SoC defined
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
clang warns this check is silly; it is since s is
a local variable.
u-boot/drivers/mtd/cfi_flash.c:2363:13: warning: comparison of
array 's' not equal to a null pointer is always true
else if ((s != NULL) && (strcmp(s, "yes") == 0)) {
cc: Stefan Roese <sr@denx.de>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
The definitions inside emif_defs.h concern davinci nand driver and
should be in it's header. So create header file for davinci nand
driver and move definitions from emif_defs.h and nand_defs.h to it.
Acked-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
[trini: Fixup more davinci breakage]
Signed-off-by: Tom Rini <trini@ti.com>
Currently, flash quad bit is set in "spi_flash_validate_params" and later
at the end in the same api, we write 0 to status register for few flashes,
thereby overriding the quad bit set. This fix moves the quad bit setting
outside this api in "spi_flash_probe_slave"
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch add support for BCH16_ECC to omap_gpmc driver.
*need to BCH16 ECC scheme*
With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes
Flash devices have become more suspectible to bit-flips. Thus stronger
ECC schemes are required for protecting the data.
But stronger ECC schemes have come with larger-sized ECC syndromes which require
more space in OOB/Spare. This puts constrains like;
(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>
GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL: SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
which is called before probing for devices, hence any ONFI parameter
information is not available during GPMC initialization.
Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.
This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.
Signed-off-by: Pekon Gupta <pekon@ti.com>
As per following Sections in ONFI Spec, NAND_CMD_READID should use only
lower 8-bit for transfering command, address and data even on x16 NAND device.
*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus. The host shall not issue commands that use a word data width on x16
devices until the host determines the device supports a 16-bit data bus width
in the parameter page."
*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
16-bit width. All address and command line transfers shall use only the lower
8-bits of the data bus. During command transfers, the host may place any value
on the upper 8-bits of the data bus. During address transfers, the host shall
set the upper 8-bits of the data bus to 00h."
Thus porting following commit from linux-kernel to ensure that column address
is not altered to align to x16 bus when issuing NAND_CMD_READID command.
commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
mtd: nand: force NAND_CMD_READID onto 8-bit bus
Author: Brian Norris <computersforpeace@gmail.com> (preserving authorship)
The NAND command helpers tend to automatically shift the column address
for x16 bus devices, since most commands expect a word address, not a
byte address. The Read ID command, however, expects an 8-bit address
(i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
0x20).
This fixes the column address for a few drivers which imitate the
nand_base defaults.
Signed-off-by: Pekon Gupta <pekon@ti.com>
Porting below commit from linux-tree, preserving original authorship & commit log
commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
Author: Brian Norris <computersforpeace@gmail.com>
mtd: nand: don't use read_buf for 8-bit ONFI transfers
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree)
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch
omap-elm.c: replaces -ve integer value returned during errorneous condition,
with proper error-codes.
omap-gpmc.c: updates omap-gpmc driver to pass error-codes returned from
omap-elm driver to upper layers
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch tries to avoid some local pointer dereferences, by using common
local variables in omap_correct_data_bch()
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch renames 'struct nand_bch_priv' which currently holds private data only
for BCH ECC schemes, into 'struct omap_nand_info' so that same can be used for
all ECC schemes
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This utilizes existing mxs_nand support layer to provide a method to load an
image off nand for SPL. The flash device will be detected in order to support
multiple flash devices instead of having layout hard coded at build time.
Cc: Stefan Roese <sr@denx.de>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Andy Ng <andreas2025@gmail.com>
Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Tapani Utriainen <tapani@technexion.com>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add support of loading image, binary for MMC and SPI during SPL boot.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
SPI driver perform its operation(read/write) on 64KB buffer chunk for data
greater than 64KB. This buffer chunk is allocated from system heap.
During SPL boot, 768KB of data is read from SPI flash.
Here, heap size may not be sufficient enough to full-fill 64KB buffer
requirement of SPI driver. So break down u-boot read operation at 8KB of chunk.
Also, fix a warning i.e. "unused variable buf" during CONFIG_FSL_CORENET
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
nand_spl_load_image() can also be used for non TPL framework.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
This patch introduces a configurable mechanism to disable
subpage writes in the DaVinci NAND driver.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>
This mainly converts the am335x_spl_bch driver to the "normal" format
which means a slight change to nand_info within the driver.
Acked-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Tom Rini <trini@ti.com>
The commit 6af8dc3ebc broke support for
S25FL032P and S25FL064P by carelessly removing the code handling special
page size for these two SPI NOR flashes and unifying the code under the
assumption that Extended JEDEC ID of 0x4d00 always implies 512b page size.
Add special case handling for these two SPI NOR flashes.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Squash the malloc()+memset() combo in favor of calloc().
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Acked-by: Marek Vasut <marex@denx.de>
Squash the malloc()+memset() combo in favor of calloc().
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Both of these chips have 256kB big sectors, thus the _256K suffix,
compared to their _64K counterparts, which have 64kB sectors. Also,
they have four times less sectors than their _64K counterparts.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Prepare for nand spl boot support. It supports nand software ECC and
hardware PMECC.
This patch is take <drivers/mtd/nand/nand_spl_simple.c> as reference.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
As ppc4xx currently only supports the deprecated nand_spl infrastructure
and nobody seems to have time / resources to port this over to the newer
SPL infrastructure, lets remove NAND booting completely.
This should not affect the "normal", non NAND-booting ppc4xx platforms
that are currently supported.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tirumala Marri <tmarri@apm.com>
Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Tom Rini <trini@ti.com>
Tested-by: Matthias Fuchs <matthias.fuchs@esd.eu>
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>
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>
IFC registers can be of type Little Endian or big Endian depending upon
Freescale SoC. Here SoC defines the register type of IFC IP.
So update acessor functions with common IFC acessor functions to take care
both type of endianness.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: York Sun <yorksun@freescale.com>
Using the TPL method for nand boot by sram was already
supported. Here add some code for mpc85xx ifc nand boot.
- For ifc, elbc, esdhc, espi, all need the SPL without
section .resetvec.
- Use a clear function name for nand spl boot.
- Add CONFIG_SPL_DRIVERS_MISC_SUPPORT to compile the fsl_ifc.c
in spl/Makefile;
Signed-off-by: Po Liu <Po.Liu@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
The omap_gpmc allows switching ecc at runtime. Since
the NAND_SUBPAGE_READ flag is only set, it is kept when
switching to hw ecc, which is not correct. This leads to
calling chip->ecc.read_subpage which is not a valid
pointer. Therefore clear the flag when switching ecc so
reading in hw mode works again.
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Remove the flag SECT_4K for device N25Q128 as the 4K-byte
sub sector erase granularity is available only for top/bottom
8 sectors in some of the N25Q128 chips.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This config will use for defining greater than single flash support.
currently - DUAL_STACKED and DUAL_PARALLEL.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch added support for accessing dual memories in
parallel connection with single chipselect line from controller.
For more info - see doc/SPI/README.dual-flash
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch added support for accessing dual memories in
stacked connection with single chipselect line from controller.
For more info - see doc/SPI/README.dual-flash
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
QEB code comprises of couple of flash register read/write operations,
this patch moved flash register operations on to sf_op
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added macronix flash quad read/write commands support and
it's up to the respective controller driver usecase to
configure the respective commands by defining SPI RX/TX
operation modes from include/spi.h on the driver.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch adds set QEB support for macronix flash devices
which are trying to program/read quad operations.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Moved the flash params table from sf_probe.c and
placed on to sf_params.c, hence flash params file will
alter based on new addons.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch enabled RD_FULL and WR_QPP for supported flashes
in micron, winbond and spansion.
Remaining parts will be add in future patches.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch provides support to set the quad enable bit on flash.
quad enable bit needs to set before performing any quad IO
operations on respective SPI flashes.
Currently added set quad enable bit for winbond and spansion flash
devices. stmicro flash doesn't require to set as qeb is volatile.
remaining flash devices support will add in future patches.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch provides support to program a flash config register.
Configuration register contains the control bits used to configure
the different configurations and security features of a device.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch add quad commands support like
- QUAD_PAGE_PROGRAM => for write program
- QUAD_OUTPUT_FAST ->> for read program
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Current sf uses FAST_READ command, this patch adds support to
use the different/extended read command.
This implementation will determine the fastest command by taking
the supported commands from the flash and the controller, controller
is always been a priority.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Fix unaligned access in OneNAND core. The problem is that the ffchars[] array
is an array of "unsigned char", but in onenand_write_ops_nolock() can be passed
to the memcpy_16() function. The memcpy_16() function will treat the buffer as
an array of "unsigned short", thus triggering unaligned access if the compiler
decided ffchars[] to be not aligned.
I managed to trigger the problem with regular ELDK 5.4 GCC compiler.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>
claim spi bus while doing memory copy, this will set up
the spi controller device control register before doing
a memory read.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Tested-by: Yebio Mesfin <ymesfin@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Add support for Macronix MX25L2006E SPI flash.
Signed-off-by: Luka Perkov <luka@openwrt.org>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
All other hex values in sf_probe.c are in lower case so we should
fix this one too.
Signed-off-by: Luka Perkov <luka@openwrt.org>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
If we change to software ecc and then back to hardware ecc, the nand ecc ops
pointers are populated with incorrect function pointers. This is related to the
way nand_scan_tail() handles assigning functions to ecc ops:
If we are switching to software ecc/no ecc, it assigns default functions to the
ecc ops pointers unconditionally, but if we are switching to hardware ecc,
the default hardware ecc functions are assigned to ops pointers only if these
pointers are NULL (so that drivers could set their own functions). In the case
of omap_gpmc.c driver, when we switch to sw ecc, sw ecc functions are
assigned to ecc ops by nand_scan_tail(), and when we later switch to hw ecc,
the ecc ops pointers are not NULL, so nand_scan_tail() does not overwrite
them with hw ecc functions.
The result: sw ecc functions used to write hw ecc data.
Clear the ecc ops pointers in omap_gpmc.c when switching ecc types, so that
ops which were not assigned by the driver will get the correct default values
from nand_scan_tail().
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
When switching ecc mode, omap_select_ecc_scheme() assigns the appropriate values
into the current nand chip's ecc.layout struct. This is done under the
assumption that the struct exists only to store values, so it is OK to overwrite
it, but there is at least one situation where this assumption is incorrect:
When switching to 1 bit hamming code sw ecc, the job of assigning layout data
is outsourced to nand_scan_tail(), which simply assigns into ecc.layout a
pointer to an existing struct prefilled with the appropriate values. This struct
doubles as both data and layout definition, and therefore shouldn't be
overwritten, but on the next switch to hardware ecc, this is exactly what's
going to happen. The next time the user switches to software ecc, they're
going to get a messed up ecc layout.
Prevent this and possible similar bugs by explicitly using the
private-to-omap_gpmc.c omap_ecclayout struct when switching ecc mode.
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic
platform" (d016dc42ce) changed the way
software ECC is configured, both during boot, and during ecc switch, in a way
that is not backwards compatible with older systems:
Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring
for software ecc, relying on nand_scan_tail() to select a default for ecc.size
(256), while the new version of omap_gpmc.c assigns ecc.size = pagesize,
which is likely to not be 256.
Since 1 bit hamming sw ecc is only meant to be used by legacy devices, revert
to the original behavior.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
[scottwood@freescale.com: wrap some long lines]
Signed-off-by: Scott Wood <scottwood@freescale.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>
Tested-by: Stefan Roese <sr@denx.de>
This adds a SPI flash driver which simulates SPI flash clients.
Currently supports the bare min that U-Boot requires: you can
probe, read, erase, and write. Should be easy to extend to make
it behave more exactly like a real SPI flash, but this is good
enough to merge now.
sjg@chromium.org added a README and tidied up code a little.
Added a required map_sysmem() for sandbox.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This allows us to put the SPI flash chip inside the SPI interface node,
with U-Boot finding the correct bus and chip select automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
Existing eSPI SPL framework assumes booting from spi-image
with boot_format header which contains final u-boot Image
offset and size. No such header is present in case of
corenet devices like T1040 as corenet deivces use PBI-RCW
based intialization.
So, for corenet deives, SPL bootloader use values provided
at compilation time. These values can be defined in board
specific config file.
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Acked-by: York Sun <yorksun@freescale.com>
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/misc
and fix the header file includes.
Signed-off-by: York Sun <yorksun@freescale.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>
[scottwood@freescale.com: fixed unused variable warning]
Signed-off-by: Scott Wood <scottwood@freescale.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>
Current IFC driver supports till 4K page size NAND flash.
Add support of 8K NAND flash
- Program Spare region size in csor_ext
- Add nand_ecclayout for 4 bit & 8 bit ecc
- Defines constants
- Add support of 8K NAND boot.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
CC: Liu Po <po.liu@freescale.com>
nand_ecclayout is present in mtd.h at Linux.
Move this structure to mtd.h to comply with Linux.
Also, increase the ecc placement locations to 640 to suport device having
writesize/oobsize of 8KB/640B. This means that the maximum oobsize has gone
up to 640 bytes and consequently the maximum ecc placement locations have
also gone up to 640.
Changes from Prabhabkar's version (squashed into one patch to preserve
bisectability):
- Added _LARGE to MTD_MAX_*_ENTRIES
This makes the names match current Linux source, and resolves
a conflict between
http://patchwork.ozlabs.org/patch/280488/
and
http://patchwork.ozlabs.org/patch/284513/
The former was posted first and is closer to matching Linux, but
unlike Linux it does not add _LARGE to the names. The second adds
_LARGE to one of the names, and depends on it in a subsequent patch
(http://patchwork.ozlabs.org/patch/284512/).
- Made max oobfree/eccpos configurable, and used this on tricorder,
alpr, ASH405, T4160QDS, and T4240QDS (these boards failed to build
for me without doing so, due to a size increase).
On tricorder SPL, this saves 2576 bytes (and makes the SPL build
again) versus the new default of 640 eccpos and 32 oobfree, and
saves 336 bytes versus the old default of 128 eccpos and 8 oobfree.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
CC: Vipin Kumar <vipin.kumar@st.com>
[scottwood@freescale.com: changes as described above]
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Thomas Weber <weber@corscience.de>
Cc: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Cc: Stefan Roese <sr@denx.de>
Cc: York Sun <yorksun@freescale.com>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
as per controller description,
"While programming a NAND flash, status read should never skipped.
Because it may happen that a new command is issued to the NAND Flash,
even when the device has not yet finished processing the previous request.
This may result in unpredictable behaviour."
IFC controller never polls for R/B signal after command send. It just return
control to software. This behaviour may not occur with NAND flash access.
because new commands are sent after polling R/B signal. But it may happen
in scenario where GPCM-ASIC and NAND flash device are working simultaneously.
Update the controller driver to take care of this requirement
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Conflicts:
arch/arm/cpu/arm926ejs/mxs/Makefile
board/compulab/cm_t35/Makefile
board/corscience/tricorder/Makefile
board/ppcag/bg0900/Makefile
drivers/bootcount/Makefile
include/configs/omap4_common.h
include/configs/pdnb3.h
Makefile conflicts are due to additions/removals of
object files on the ARM branch vs KBuild introduction
on the main branch. Resolution consists in adjusting
the list of object files in the main branch version.
This also applies to two files which are not listed
as conflicting but had to be modified:
board/compulab/common/Makefile
board/udoo/Makefile
include/configs/omap4_common.h conflicts are due to
the OMAP4 conversion to ti_armv7_common.h on the ARM
side, and CONFIG_SYS_HZ removal on the main side.
Resolution is to convert as this icludes removal of
CONFIG_SYS_HZ.
include/configs/pdnb3.h is due to a removal on ARM side.
Trivial resolution is to remove the file.
Note: 'git show' will also list two files just because
they are new:
include/configs/am335x_igep0033.h
include/configs/omap3_igep00x0.h
enable the RBL/UBL ECC layout through
CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define
see for more info:
http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Prior to SPDX licensing this file was GPL-2.0 with Freescale granting
rights for "or later" for their contributed code. We incorrectly moved
this file to GPL-2.0+, so correct it to GPL-2.0. In addition we cannot
easily denote in the file where or what code is "or later", so just set
that aside for now and the file as a whole is GPL-2.0 regardless.
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: Tom Rini <trini@ti.com>
NAND_ECC_SOFT was the only option available while the SOFT_BCH option
may also be used.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Acked-by: Scott Wood <scottwood@freescale.com>
As the spi flash transfer to multiple parts, it is forgot to add
Atmel AT25DF321 spi flash support, which broken several Atmel EK
boards which this chip. So, add it
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Added GPL-2.0+ SPDX-License-Identifier for missed sf
source files.
Signed-off-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.
For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
UBI: fixable bit-flip detected at PEB 1027
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
UBI: fixable bit-flip detected at PEB 4083
UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
UBI DBG: erase_worker: erase PEB 4083 EC 55
UBI DBG: sync_erase: erase PEB 4083, old EC 55
UBI DBG: do_sync_erase: erase PEB 4083
UBI DBG: sync_erase: erased PEB 4083, new EC 56
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
...
This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
There is no page_size for ramtron flashes,
so just print the detected flash and it's size.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Qspi controller can have a memory mapped port which can be used for
data read. Added support to enable memory mapped port read.
This patch enables the following:
- It enables exchange of memory map address between mtd and qspi
through the introduction of "memory_map" flag.
- Add support to communicate to the driver that memory mapped
transfer is to be started through introduction of new flags like
"SPI_XFER_MEM_MAP" and "SPI_XFER_MEM_MAP_END".
This will enable the spi controller to do memory mapped configurations
if required.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Use flash->page_size arg in print_size() instead of
flash->sector_size while printing detected flas part details.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Now the common probing is handled in spi_flash_probe.c
hence removed the unneeded flash drivers.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Compared to other spi flashes, ramtron has a different
probing and implementation on flash ops, hence moved
ramtron probe code into ramtron driver.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
From Micron, 512MB onwards, flash requires to poll flag status
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
SECT_4K, SECT_32K and SECT_64K opeartions are performed to
to specific flash by adding a SECT* flag on respective
spi_flash_params.flag param.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Few of the flashes(Atmel, Macronix and SST) require to
clear BP# bits in flash power ups.
So clear these BP# bits at probe time, so-that the flash
is ready for user operations.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Most of the SST flashes needs to write up using SST_WP, AAI
Word Program, so added a flag param on spi_flash_params table.
SST flashes, which supports SST_WP need to use a WP write
sst_write_wp instead of common flash write.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added AT45DB* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added SST25* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
Added S25FL* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added W25* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added MX25L* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
