add the GPMI controller driver for IMX23/IMX28
Subsystems (2)
v8 cover add the GPMI controller driver for IMX23/IMX28
The patch is based on branch "imx-for-3.1" of tree :
git://git.pengutronix.de/git/imx/linux-2.6.git
The general-purpose media interface(GPMI) controller is a flexible interface to up to several NAND flashs.
The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
With the help of BCH, the GPMI controller can choose to do the hardware ECC or not.
This driver is a _pure_ MTD NAND controller driver now.
To Walfram & Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the ecclayout to do the job. Could you give me some hint? thanks.
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
The driver also depends on another DMA patch by Shawn:
[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
Test environment:
Using imx23 and imx28 boards for test.
imx23 (burn the rootfs to NAND):
console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs gpmi_debug_init
imx28 :
#console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait gpmi_debug_init #console=ttyAMA0,115200 root=/dev/nfs ip=:::::eth0:dhcp nfsroot=10.192.242.11:/root/nfs_root/imx28 gpmi_debug_init
v7 --> v8:
[0] rename the name from GPMI-NFC to GPMI-NAND
[1] remove the hal layer, and change it to function library.
[2] Do not use ~0 to initialize the DMA address.
[3] fix the issue : several DMA channels share the same IRQ.
[4] DMA timeout issue. I use the .config created by make mxs_defconfig and the bug never occur. It seems some other module has impact to the DMA.
Of course, you should enable the UBIFS,MTD_CHAR and GPMI for the .config. You can also disable the SPIN-LOCK/MUTEX debug features.
[5] add function to print out the GPMI registers.
[6] others.
v6 --> v7:
[0] remove the function wrapping the clock.
[1] use the module_param() for debugging.
[2] use the new interface of MTD partitions.
replace add_mtd_partitions() with mtd_device_register().
[3] use pr_info() to print log.
[4] add __devinit for some functions, etc.
[5] add gpmi_nfc to control the GPMI-NFC driver's initialization.
[6] others.
v5 --> v6:
[0] split out the IMX23/IMX28 arch code to separate patches.
[1] fix bug : missing empty item in the end of platform_id array.
[2] inconsistent identation.
[3] others
v4 --> v5:
[0] rename the files.
[1] fix PM bug
[2] remove the rom_helper code, and move the necessary initialization code to the main file.
[3] change the macros from CPU_IS_* to GPMI_IS_*
[4] remove the default partition layout init code. revert back the partition parsing command line code.
[5] others
v3 --> v4:
[0] use the nand_ids{} as the nand database, drop my own database.
[1] remove the patch for DMA enginer, Shawn will submit his own version.
[2] use the platform_id to distinguish different Archs.
[3] fix the strange coding style.
[4] others.
v2 --> v3:
[0] merge the imx23 and imx28 into one file(including the header file).
[1] remove the unuse registers in the headers.
[2] fix DMA bugs
[3] add bus width field to nand_attr{}
[4] others
v1 --> v2:
[0] merge the common files into the gpmi-nfc-main.c
[1] change the code to get the clock.
[2] remove the timing in the nand_device_info{}
[3] fix DMA errors
[4] add the nand_device_info.[ch] to generic code
[5] use the chip->onfi_version for the ONFI nand
[6] useless init
[7] others
Huang Shijie (3):
MTD : add the common code for GPMI-NAND controller driver MTD : add helper functions library and header files for GPMI NAND
driver
MTD : add GPMI-NAND driver in the config and Makefile
drivers/mtd/nand/Kconfig | 11 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/gpmi-nand/Makefile | 3 + drivers/mtd/nand/gpmi-nand/bch-regs.h | 88 ++ drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 978 ++++++++++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1987 ++++++++++++++++++++++++++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 390 +++++++ drivers/mtd/nand/gpmi-nand/gpmi-regs.h | 174 +++ 8 files changed, 3632 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/gpmi-nand/Makefile create mode 100644 drivers/mtd/nand/gpmi-nand/bch-regs.h create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-lib.c create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.c create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.h create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-regs.h
PATCH v8 1/3 MTD : add the common code for GPMI-NAND controller driver
These files contain the common code for the GPMI-NAND driver.
--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1987 ++++++++++++++++++++++++++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 390 +++++++ 2 files changed, 2377 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.c create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.h
drivers/mtd/nand/gpmi-nand/gpmi-nand.c new file +1987 -0
@@ -0,0 +1,1987 @@ +/* +* Freescale GPMI NAND Flash Driver +* +* Copyright (C) 2010-2011 Freescale Semiconductor, Inc. +* Copyright (C) 2008 Embedded Alley Solutions, Inc. +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License along +* with this program; if not, write to the Free Software Foundation, Inc., +* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +*/ +#include "gpmi-nand.h" + +/* add our owner bbt descriptor */ +static uint8_t scan_ff_pattern[] = {0xff }; +static struct nand_bbt_descr gpmi_bbt_descr = { + .options =0 , + .offs =0 , + .len =1 , + .pattern = scan_ff_pattern +}; + +/* debug control */ +int gpmi_debug; +module_param (gpmi_debug, int,S_IRUGO |S_IWUSR ); +MODULE_PARM_DESC (gpmi_debug,"print out the debug infomation." ); + +/* enable the gpmi-nand. */ +static bool enable_gpmi_nand; + +static ssize_t show_ignorebad (struct device *dev, +struct device_attribute *attr,char *buf) +{ +struct gpmi_nand_data *this =dev_get_drvdata (dev); +struct mil *mil = &this->mil; + +return sprintf (buf,"%d\n" , mil->ignore_bad_block_marks); +} + +static ssize_t +store_ignorebad (struct device *dev,struct device_attribute *attr, +const char *buf,size_t size) +{ +struct gpmi_nand_data *this =dev_get_drvdata (dev); +struct mil *mil = &this->mil; +const char *p = buf; +unsigned long v; + +if (strict_strtoul (p,0 , &v) <0 ) +return -EINVAL ; + +if (v >0 ) + v =1 ; + +if (v != mil->ignore_bad_block_marks) { +if (v) { +/* +* This will cause the NAND Flash MTD code to believe +* that it never created a BBT and force it to call our +* block_bad function. +* +* See mil_block_bad for more details. +*/ + mil->saved_bbt = mil->nand.bbt; + mil->nand.bbt =NULL ; + }else { +/* +* Restore the NAND Flash MTD's pointer +* to its in-memory BBT. +*/ + mil->nand.bbt = mil->saved_bbt; + } + mil->ignore_bad_block_marks = v; + } +return size; +} + +static DEVICE_ATTR(ignorebad, 0644, show_ignorebad, store_ignorebad); +static struct device_attribute *device_attributes[] = { + &dev_attr_ignorebad, +}; + +static irqreturn_t bch_irq (int irq,void *cookie) +{ +struct gpmi_nand_data *this = cookie; + +gpmi_clear_bch (this); +complete (&this->bch_done); +return IRQ_HANDLED ; +} + +/* calculate the ECC strength by hand */ +static inline int get_ecc_strength (struct gpmi_nand_data *this) +{ +struct mtd_info *mtd = &this->mil.mtd; +int ecc_strength =0 ; + +switch (mtd->writesize) { +case 2048 : + ecc_strength =8 ; +break ; +case 4096 : +switch (mtd->oobsize) { +case 128 : + ecc_strength =8 ; +break ; +case 224 : +case 218 : + ecc_strength =16 ; +break ; + } +break ; +case 8192 : + ecc_strength =24 ; +break ; + } + +return ecc_strength; +} + +bool is_ddr_nand (struct gpmi_nand_data *this) +{ +struct nand_chip *chip = &this->mil.nand; + +/* ONFI nand */ +if (chip->onfi_version !=0 ) +return true; + +/* TOGGLE nand */ + +return false; +} + +static inline int get_ecc_chunk_size (struct gpmi_nand_data *this) +{ +/* the ONFI/TOGGLE nands use 1k ecc chunk size */ +if (is_ddr_nand (this)) +return 1024 ; + +/* for historical reason */ +return 512 ; +} + +int common_nfc_set_geometry (struct gpmi_nand_data *this) +{ +struct bch_geometry *geo = &this->bch_geometry; +struct mtd_info *mtd = &this->mil.mtd; +unsigned int metadata_size; +unsigned int status_size; +unsigned int chunk_data_size_in_bits; +unsigned int chunk_ecc_size_in_bits; +unsigned int chunk_total_size_in_bits; +unsigned int block_mark_chunk_number; +unsigned int block_mark_chunk_bit_offset; +unsigned int block_mark_bit_offset; + +/* We only support BCH now. */ + geo->ecc_algorithm ="BCH" ; + +/* +* We always choose a metadata size of 10. Don't try to make sense of +* it -- this is really only for historical compatibility. +*/ + geo->metadata_size_in_bytes =10 ; + +/* ECC chunks */ + geo->ecc_chunk_size_in_bytes =get_ecc_chunk_size (this); + +/* +* Compute the total number of ECC chunks in a page. This includes the +* slightly larger chunk at the beginning of the page, which contains +* both data and metadata. +*/ + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size_in_bytes; + +/* +* We use the same ECC strength for all chunks, including the first one. +*/ + geo->ecc_strength =get_ecc_strength (this); +if (!geo->ecc_strength) { +pr_info ("Page size:%d, OOB:%d\n" , mtd->writesize, mtd->oobsize); +return -EINVAL ; + } + +/* Compute the page size, include page and oob. */ + geo->page_size_in_bytes = mtd->writesize + mtd->oobsize; + +/* +* ONFI/TOGGLE nand needs GF14, so re-calculate DMA page size. +* The ONFI nand must do the recalculation, +* else it will fail in DMA in some platform(such as imx50). +*/ +if (is_ddr_nand (this)) + geo->page_size_in_bytes = mtd->writesize + + geo->metadata_size_in_bytes + + (geo->ecc_strength *14 *8 / geo->ecc_chunk_count); + + geo->payload_size_in_bytes = mtd->writesize; +/* +* In principle, computing the auxiliary buffer geometry is NFC +* version-specific. However, at this writing, all versions share the +* same model, so this code can also be shared. +* +* The auxiliary buffer contains the metadata and the ECC status. The +* metadata is padded to the nearest 32-bit boundary. The ECC status +* contains one byte for every ECC chunk, and is also padded to the +* nearest 32-bit boundary. +*/ + metadata_size =ALIGN (geo->metadata_size_in_bytes,4 ); + status_size =ALIGN (geo->ecc_chunk_count,4 ); + + geo->auxiliary_size_in_bytes = metadata_size + status_size; + geo->auxiliary_status_offset = metadata_size; + +/* Check if we're going to do block mark swapping. */ +if (!this->swap_block_mark) +return 0 ; + +/* +* If control arrives here, we're doing block mark swapping, so we need +* to compute the byte and bit offsets of the physical block mark within +* the ECC-based view of the page data. In principle, this isn't a +* difficult computation -- but it's very important and it's easy to get +* it wrong, so we do it carefully. +* +* Note that this calculation is simpler because we use the same ECC +* strength for all chunks, including the zero'th one, which contains +* the metadata. The calculation would be slightly more complicated +* otherwise. +* +* We start by computing the physical bit offset of the block mark. We +* then subtract the number of metadata and ECC bits appearing before +* the mark to arrive at its bit offset within the data alone. +*/ + +/* Compute some important facts about chunk geometry. */ + chunk_data_size_in_bits = geo->ecc_chunk_size_in_bytes *8 ; + +/* ONFI/TOGGLE nand needs GF14 */ +if (is_ddr_nand (this)) + chunk_ecc_size_in_bits = geo->ecc_strength *14 ; +else + chunk_ecc_size_in_bits = geo->ecc_strength *13 ; + + chunk_total_size_in_bits = + chunk_data_size_in_bits + chunk_ecc_size_in_bits; + +/* Compute the bit offset of the block mark within the physical page. */ + block_mark_bit_offset = mtd->writesize *8 ; + +/* Subtract the metadata bits. */ + block_mark_bit_offset -= geo->metadata_size_in_bytes *8 ; + +/* +* Compute the chunk number (starting at zero) in which the block mark +* appears. +*/ + block_mark_chunk_number = + block_mark_bit_offset / chunk_total_size_in_bits; + +/* +* Compute the bit offset of the block mark within its chunk, and +* validate it. +*/ + block_mark_chunk_bit_offset = + block_mark_bit_offset - + (block_mark_chunk_number * chunk_total_size_in_bits); + +if (block_mark_chunk_bit_offset > chunk_data_size_in_bits) { +/* +* If control arrives here, the block mark actually appears in +* the ECC bits of this chunk. This wont' work. +*/ +pr_info ("Unsupported page geometry : %u:%u\n" , + mtd->writesize, mtd->oobsize); +return -EINVAL ; + } + +/* +* Now that we know the chunk number in which the block mark appears, +* we can subtract all the ECC bits that appear before it. +*/ + block_mark_bit_offset -= + block_mark_chunk_number * chunk_ecc_size_in_bits; + +/* +* We now know the absolute bit offset of the block mark within the +* ECC-based data. We can now compute the byte offset and the bit +* offset within the byte. +*/ + geo->block_mark_byte_offset = block_mark_bit_offset /8 ; + geo->block_mark_bit_offset = block_mark_bit_offset %8 ; + +return 0 ; +} + +struct dma_chan *get_dma_chan (struct gpmi_nand_data *this) +{ +int chip = this->mil.current_chip; + +BUG_ON (chip <0 ); +return this->dma_chans[chip]; +} + +/* Can we use the upper's buffer directly for DMA? */ +void prepare_data_dma (struct gpmi_nand_data *this,enum dma_data_direction dr) +{ +struct mil *mil = &this->mil; +struct scatterlist *sgl = &mil->data_sgl; +int ret; + + mil->direct_dma_map_ok = true; + +/* first try to map the upper buffer directly */ +sg_init_one (sgl, mil->upper_buf, mil->upper_len); + ret =dma_map_sg (this->dev, sgl,1 , dr); +if (ret ==0 ) { +/* We have to use our own DMA buffer. */ +sg_init_one (sgl, mil->data_buffer_dma,PAGE_SIZE ); + +if (dr ==DMA_TO_DEVICE ) +memcpy (mil->data_buffer_dma, mil->upper_buf, + mil->upper_len); + + ret =dma_map_sg (this->dev, sgl,1 , dr); +BUG_ON (ret ==0 ); + + mil->direct_dma_map_ok = false; + } +} + +/* This will be called after the DMA operation is finished. */ +static void dma_irq_callback (void *param) +{ +struct gpmi_nand_data *this = param; +struct mil *mil = &this->mil; +struct completion *dma_c = &this->dma_done; + +complete (dma_c); + +switch (this->dma_type) { +case DMA_FOR_COMMAND : +dma_unmap_sg (this->dev, &mil->cmd_sgl,1 ,DMA_TO_DEVICE ); +break ; + +case DMA_FOR_READ_DATA : +dma_unmap_sg (this->dev, &mil->data_sgl,1 ,DMA_FROM_DEVICE ); +if (mil->direct_dma_map_ok == false) +memcpy (mil->upper_buf, mil->data_buffer_dma, + mil->upper_len); +break ; + +case DMA_FOR_WRITE_DATA : +dma_unmap_sg (this->dev, &mil->data_sgl,1 ,DMA_TO_DEVICE ); +break ; + +case DMA_FOR_READ_ECC_PAGE : +case DMA_FOR_WRITE_ECC_PAGE : +/* We have to wait the BCH interrupt to finish. */ +break ; + +default : +BUG (); + } +} + +int start_dma_without_bch_irq (struct gpmi_nand_data *this, +struct dma_async_tx_descriptor *desc) +{ +struct completion *dma_c = &this->dma_done; +int err; + +init_completion (dma_c); + + desc->callback = dma_irq_callback; + desc->callback_param = this; +dmaengine_submit (desc); + +/* Wait for the interrupt from the DMA block. */ + err =wait_for_completion_timeout (dma_c,msecs_to_jiffies (1000 )); + err = (!err) ? -ETIMEDOUT :0 ; +if (err) { +pr_info ("DMA timeout, last DMA :%d\n" , this->last_dma_type); +if (gpmi_debug &GPMI_DEBUG_CRAZY ) { +gpmi_show_regs (this); +panic ("-----------DMA FAILED------------------" ); + } + } +return err; +} + +/* +* This function is used in BCH reading or BCH writing pages. +* It will wait for the BCH interrupt as long as ONE second. +* Actually, we must wait for two interrupts : +* [1] firstly the DMA interrupt and +* [2] secondly the BCH interrupt. +* +* @this: Per-device data structure. +* @desc: DMA channel +*/ +int start_dma_with_bch_irq (struct gpmi_nand_data *this, +struct dma_async_tx_descriptor *desc) +{ +int err; + +/* Prepare to receive an interrupt from the BCH block. */ +init_completion (&this->bch_done); + +/* start the DMA */ +start_dma_without_bch_irq (this, desc); + +/* Wait for the interrupt from the BCH block. */ + err =wait_for_completion_timeout (&this->bch_done, +msecs_to_jiffies (1000 )); + err = (!err) ? -ETIMEDOUT :0 ; +if (err) +pr_info ("bch timeout!!!\n" ); +return err; +} + +static int __devinit acquire_register_block (struct gpmi_nand_data *this, +const char *resource_name,void **reg_block_base) +{ +struct platform_device *pdev = this->pdev; +struct resource *r; +void *p; + + r =platform_get_resource_byname (pdev,IORESOURCE_MEM , resource_name); +if (!r) { +pr_info ("Can't get resource for %s\n" , resource_name); +return -ENXIO ; + } + +/* remap the register block */ + p =ioremap (r->start,resource_size (r)); +if (!p) { +pr_info ("Can't remap %s\n" , resource_name); +return -ENOMEM ; + } + + *reg_block_base = p; +return 0 ; +} + +static void release_register_block (struct gpmi_nand_data *this, +void *reg_block_base) +{ +iounmap (reg_block_base); +} + +static int __devinit acquire_interrupt (struct gpmi_nand_data *this, +const char *resource_name, +irq_handler_t interrupt_handler,int *lno,int *hno) +{ +struct platform_device *pdev = this->pdev; +struct resource *r; +int err; + + r =platform_get_resource_byname (pdev,IORESOURCE_IRQ , resource_name); +if (!r) { +pr_info ("Can't get resource for %s\n" , resource_name); +return -ENXIO ; + } + +BUG_ON (r->start != r->end); + err =request_irq (r->start, interrupt_handler,0 , resource_name, this); +if (err) { +pr_info ("Can't own %s\n" , resource_name); +return err; + } + + *lno = r->start; + *hno = r->end; +return 0 ; +} + +static void release_interrupt (struct gpmi_nand_data *this, +int low_interrupt_number,int high_interrupt_number) +{ +int i; +for (i = low_interrupt_number; i <= high_interrupt_number; i++) +free_irq (i, this); +} + +static bool gpmi_dma_filter (struct dma_chan *chan,void *param) +{ +struct gpmi_nand_data *this = param; +struct resource *r = this->private; + +if (!mxs_dma_is_apbh (chan)) +return false; +/* +* only catch the GPMI dma channels : +* for mx23 : MX23_DMA_GPMI0 ~ MX23_DMA_GPMI3 +* (These four channels share the same IRQ!) +* +* for mx28 : MX28_DMA_GPMI0 ~ MX28_DMA_GPMI7 +* (These eight channels share the same IRQ!) +*/ +if (r->start <= chan->chan_id && chan->chan_id <= r->end) { + chan->private = &this->dma_data; +return true; + } +return false; +} + +static void release_dma_channels (struct gpmi_nand_data *this) +{ +unsigned int i; +for (i =0 ; i <DMA_CHANS ; i++) +if (this->dma_chans[i]) { +dma_release_channel (this->dma_chans[i]); + this->dma_chans[i] =NULL ; + } +} + +static int __devinit acquire_dma_channels (struct gpmi_nand_data *this, +const char *resource_name, +unsigned *low_channel,unsigned *high_channel) +{ +struct platform_device *pdev = this->pdev; +struct gpmi_nand_platform_data *pdata = this->pdata; +struct resource *r, *r_dma; +unsigned int i; + + r =platform_get_resource_byname (pdev,IORESOURCE_DMA , resource_name); + r_dma =platform_get_resource_byname (pdev,IORESOURCE_IRQ , +GPMI_NAND_DMA_INTERRUPT_RES_NAME ); +if (!r || !r_dma) { +pr_info ("Can't get resource for DMA\n" ); +return -ENXIO ; + } + +/* used in gpmi_dma_filter() */ + this->private = r; + +for (i = r->start; i <= r->end; i++) { +struct dma_chan *dma_chan; +dma_cap_mask_t mask; + +if (i - r->start >= pdata->max_chip_count) +break ; + +dma_cap_zero (mask); +dma_cap_set (DMA_SLAVE , mask); + +/* get the DMA interrupt */ +if (r_dma->start == r_dma->end) { +/* only register the first. */ +if (i == r->start) + this->dma_data.chan_irq = r_dma->start; +else + this->dma_data.chan_irq =NO_IRQ ; + }else + this->dma_data.chan_irq = r_dma->start + (i - r->start); + + dma_chan =dma_request_channel (mask, gpmi_dma_filter, this); +if (!dma_chan) + goto acquire_err; + +/* fill the first empty item */ + this->dma_chans[i - r->start] = dma_chan; + } + + *low_channel = r->start; + *high_channel = i; +return 0 ; + +acquire_err: +pr_info ("Can't acquire DMA channel %u\n" , i); +release_dma_channels (this); +return -EINVAL ; +} + +static int __devinit acquire_resources (struct gpmi_nand_data *this) +{ +struct resources *r = &this->resources; +int error; + +/* Attempt to acquire the GPMI register block. */ + error =acquire_register_block (this, +GPMI_NAND_GPMI_REGS_ADDR_RES_NAME , + &r->gpmi_regs); +if (error) + goto exit_gpmi_regs; + +/* Attempt to acquire the BCH register block. */ + error =acquire_register_block (this, +GPMI_NAND_BCH_REGS_ADDR_RES_NAME , + &r->bch_regs); +if (error) + goto exit_bch_regs; + +/* Attempt to acquire the BCH interrupt. */ + error =acquire_interrupt (this, +GPMI_NAND_BCH_INTERRUPT_RES_NAME , + bch_irq, + &r->bch_low_interrupt, + &r->bch_high_interrupt); +if (error) + goto exit_bch_interrupt; + +/* Attempt to acquire the DMA channels. */ + error =acquire_dma_channels (this, +GPMI_NAND_DMA_CHANNELS_RES_NAME , + &r->dma_low_channel, + &r->dma_high_channel); +if (error) + goto exit_dma_channels; + +/* Attempt to acquire our clock. */ + r->clock =clk_get (&this->pdev->dev,NULL ); +if (IS_ERR (r->clock)) { +pr_info ("can not get the clock\n" ); + error = -ENOENT ; + goto exit_clock; + } +return 0 ; + +exit_clock: +release_dma_channels (this); +exit_dma_channels: +release_interrupt (this, r->bch_low_interrupt, r->bch_high_interrupt); +exit_bch_interrupt: +release_register_block (this, r->bch_regs); +exit_bch_regs: +release_register_block (this, r->gpmi_regs); +exit_gpmi_regs: +return error; +} + +static void release_resources (struct gpmi_nand_data *this) +{ +struct resources *r = &this->resources; + +clk_put (r->clock); +release_register_block (this, r->gpmi_regs); +release_register_block (this, r->bch_regs); +release_interrupt (this, r->bch_low_interrupt, r->bch_low_interrupt); +release_dma_channels (this); +} + +static int __devinit init_hardware (struct gpmi_nand_data *this) +{ +int error; + +/* +* This structure contains the "safe" GPMI timing that should succeed +* with any NAND Flash device +* (although, with less-than-optimal performance). +*/ +struct nand_timing safe_timing = { + .data_setup_in_ns =80 , + .data_hold_in_ns =60 , + .address_setup_in_ns =25 , + .gpmi_sample_delay_in_ns =6 , + .tREA_in_ns =-1 , + .tRLOH_in_ns =-1 , + .tRHOH_in_ns =-1 , + }; + +/* Initialize the hardwares. */ + error =gpmi_init (this); +if (error) +return error; + + this->timing = safe_timing; +return 0 ; +} + +/* Creates/Removes sysfs files for this device.*/ +static void manage_sysfs_files (struct gpmi_nand_data *this,int create) +{ +struct device *dev = this->dev; +struct device_attribute **attr; +unsigned int i; +int error; + +for (i =0 , attr = device_attributes; + i <ARRAY_SIZE (device_attributes); i++, attr++) { + +if (create) { + error =device_create_file (dev, *attr); +if (error) { +while (--attr >= device_attributes) +device_remove_file (dev, *attr); +return ; + } + }else { +device_remove_file (dev, *attr); + } + } +} + +static int read_page_prepare (struct gpmi_nand_data *this, +void *destination,unsigned length, +void *alt_virt,dma_addr_t alt_phys,unsigned alt_size, +void **use_virt,dma_addr_t *use_phys) +{ +struct device *dev = this->dev; + +if (virt_addr_valid (destination)) { +dma_addr_t dest_phys; + + dest_phys =dma_map_single (dev, destination, + length,DMA_FROM_DEVICE ); +if (dma_mapping_error (dev, dest_phys)) { +if (alt_size < length) { +pr_info ("Alternate buffer is too small\n" ); +return -ENOMEM ; + } + goto map_failed; + } + *use_virt = destination; + *use_phys = dest_phys; + this->mil.direct_dma_map_ok = true; +return 0 ; + } + +map_failed: + *use_virt = alt_virt; + *use_phys = alt_phys; + this->mil.direct_dma_map_ok = false; +return 0 ; +} + +static inline void read_page_end (struct gpmi_nand_data *this, +void *destination,unsigned length, +void *alt_virt,dma_addr_t alt_phys,unsigned alt_size, +void *used_virt,dma_addr_t used_phys) +{ +if (this->mil.direct_dma_map_ok) +dma_unmap_single (this->dev, used_phys, length,DMA_FROM_DEVICE ); +} + +static inline void read_page_swap_end (struct gpmi_nand_data *this, +void *destination,unsigned length, +void *alt_virt,dma_addr_t alt_phys,unsigned alt_size, +void *used_virt,dma_addr_t used_phys) +{ +if (!this->mil.direct_dma_map_ok) +memcpy (destination, alt_virt, length); +} + +static int send_page_prepare (struct gpmi_nand_data *this, +const void *source,unsigned length, +void *alt_virt,dma_addr_t alt_phys,unsigned alt_size, +const void **use_virt,dma_addr_t *use_phys) +{ +struct device *dev = this->dev; + +if (virt_addr_valid (source)) { +dma_addr_t source_phys; + + source_phys =dma_map_single (dev, (void *)source, length, +DMA_TO_DEVICE ); +if (dma_mapping_error (dev, source_phys)) { +if (alt_size < length) { +pr_info ("Alternate buffer is too small\n" ); +return -ENOMEM ; + } + goto map_failed; + } + *use_virt = source; + *use_phys = source_phys; +return 0 ; + } +map_failed: +/* +* Copy the content of the source buffer into the alternate +* buffer and set up the return values accordingly. +*/ +memcpy (alt_virt, source, length); + + *use_virt = alt_virt; + *use_phys = alt_phys; +return 0 ; +} + +static void send_page_end (struct gpmi_nand_data *this, +const void *source,unsigned length, +void *alt_virt,dma_addr_t alt_phys,unsigned alt_size, +const void *used_virt,dma_addr_t used_phys) +{ +struct device *dev = this->dev; +if (used_virt == source) +dma_unmap_single (dev, used_phys, length,DMA_TO_DEVICE ); +} + +static void mil_free_dma_buffer (struct gpmi_nand_data *this) +{ +struct device *dev = this->dev; +struct mil *mil = &this->mil; + +if (mil->page_buffer_virt &&virt_addr_valid (mil->page_buffer_virt)) +dma_free_coherent (dev, mil->page_buffer_size, + mil->page_buffer_virt, + mil->page_buffer_phys); +kfree (mil->cmd_buffer); +kfree (mil->data_buffer_dma); + + mil->cmd_buffer =NULL ; + mil->data_buffer_dma =NULL ; + mil->page_buffer_virt =NULL ; + mil->page_buffer_size =0 ; +} + +/* Allocate the DMA buffers */ +static int mil_alloc_dma_buffer (struct gpmi_nand_data *this) +{ +struct bch_geometry *geo = &this->bch_geometry; +struct device *dev = this->dev; +struct mil *mil = &this->mil; + +/* [1] Allocate a command buffer. PAGE_SIZE is enough. */ + mil->cmd_buffer =kzalloc (PAGE_SIZE ,GFP_DMA ); +if (mil->cmd_buffer ==NULL ) + goto error_alloc; + +/* [2] Allocate a read/write data buffer. PAGE_SIZE is enough. */ + mil->data_buffer_dma =kzalloc (PAGE_SIZE ,GFP_DMA ); +if (mil->data_buffer_dma ==NULL ) + goto error_alloc; + +/* +* [3] Allocate the page buffer. +* +* Both the payload buffer and the auxiliary buffer must appear on +* 32-bit boundaries. We presume the size of the payload buffer is a +* power of two and is much larger than four, which guarantees the +* auxiliary buffer will appear on a 32-bit boundary. +*/ + mil->page_buffer_size = geo->payload_size_in_bytes + + geo->auxiliary_size_in_bytes; + + mil->page_buffer_virt =dma_alloc_coherent (dev, mil->page_buffer_size, + &mil->page_buffer_phys,GFP_DMA ); +if (!mil->page_buffer_virt) + goto error_alloc; + + +/* Slice up the page buffer. */ + mil->payload_virt = mil->page_buffer_virt; + mil->payload_phys = mil->page_buffer_phys; + mil->auxiliary_virt = mil->payload_virt + geo->payload_size_in_bytes; + mil->auxiliary_phys = mil->payload_phys + geo->payload_size_in_bytes; +return 0 ; + +error_alloc: +mil_free_dma_buffer (this); +pr_info ("allocate DMA buffer error!!\n" ); +return -ENOMEM ; +} + +static void mil_cmd_ctrl (struct mtd_info *mtd,int data,unsigned int ctrl) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; +int error; + +/* +* Every operation begins with a command byte and a series of zero or +* more address bytes. These are distinguished by either the Address +* Latch Enable (ALE) or Command Latch Enable (CLE) signals being +* asserted. When MTD is ready to execute the command, it will deassert +* both latch enables. +* +* Rather than run a separate DMA operation for every single byte, we +* queue them up and run a single DMA operation for the entire series +* of command and data bytes. NAND_CMD_NONE means the END of the queue. +*/ +if ((ctrl & (NAND_ALE |NAND_CLE ))) { +if (data !=NAND_CMD_NONE ) + mil->cmd_buffer[mil->command_length++] = data; +return ; + } + +if (!mil->command_length) +return ; + + error =gpmi_send_command (this); +if (error) +pr_info ("Chip: %u, Error %d\n" , mil->current_chip, error); + + mil->command_length =0 ; +} + +static int mil_dev_ready (struct mtd_info *mtd) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; + +return gpmi_is_ready (this, mil->current_chip); +} + +static void mil_select_chip (struct mtd_info *mtd,int chip) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; + +if ((mil->current_chip <0 ) && (chip >=0 )) +gpmi_begin (this); +else if ((mil->current_chip >=0 ) && (chip <0 )) +gpmi_end (this); +else + ; + + mil->current_chip = chip; +} + +static void mil_read_buf (struct mtd_info *mtd,uint8_t *buf,int len) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; + +logio (GPMI_DEBUG_READ ); +/* save the info in mil{} for future */ + mil->upper_buf = buf; + mil->upper_len = len; + +gpmi_read_data (this); +} + +static void mil_write_buf (struct mtd_info *mtd,const uint8_t *buf,int len) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; + +logio (GPMI_DEBUG_WRITE ); +/* save the info in mil{} for future */ + mil->upper_buf = (uint8_t *)buf; + mil->upper_len = len; + +gpmi_send_data (this); +} + +static uint8_t mil_read_byte (struct mtd_info *mtd) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +struct mil *mil = &this->mil; +uint8_t *buf = mil->data_buffer_dma; + +mil_read_buf (mtd, buf,1 ); +return buf[0 ]; +} + +/** +* mil_handle_block_mark_swapping() - Handles block mark swapping. +* +* Note that, when this function is called, it doesn't know whether it's +* swapping the block mark, or swapping it *back* -- but it doesn't matter +* because the the operation is the same. +* +* @this: Per-device data. +* @payload: A pointer to the payload buffer. +* @auxiliary: A pointer to the auxiliary buffer. +*/ +static void mil_handle_block_mark_swapping (struct gpmi_nand_data *this, +void *payload,void *auxiliary) +{ +struct bch_geometry *nfc_geo = &this->bch_geometry; +unsigned char *p; +unsigned char *a; +unsigned int bit; +unsigned char mask; +unsigned char from_data; +unsigned char from_oob; + +/* Check if we're doing block mark swapping. */ +if (!this->swap_block_mark) +return ; + +/* +* If control arrives here, we're swapping. Make some convenience +* variables. +*/ + bit = nfc_geo->block_mark_bit_offset; + p = payload + nfc_geo->block_mark_byte_offset; + a = auxiliary; + +/* +* Get the byte from the data area that overlays the block mark. Since +* the ECC engine applies its own view to the bits in the page, the +* physical block mark won't (in general) appear on a byte boundary in +* the data. +*/ + from_data = (p[0 ] >> bit) | (p[1 ] << (8 - bit)); + +/* Get the byte from the OOB. */ + from_oob = a[0 ]; + +/* Swap them. */ + a[0 ] = from_data; + + mask = (0x1 << bit) -1 ; + p[0 ] = (p[0 ] & mask) | (from_oob << bit); + + mask = ~0 << bit; + p[1 ] = (p[1 ] & mask) | (from_oob >> (8 - bit)); +} + +static int mil_ecc_read_page (struct mtd_info *mtd,struct nand_chip *nand, +uint8_t *buf,int page) +{ +struct gpmi_nand_data *this = nand->priv; +struct bch_geometry *nfc_geo = &this->bch_geometry; +struct mil *mil = &this->mil; +void *payload_virt; +dma_addr_t payload_phys; +void *auxiliary_virt; +dma_addr_t auxiliary_phys; +unsigned int i; +unsigned char *status; +unsigned int failed; +unsigned int corrected; +int error; + +logio (GPMI_DEBUG_ECC_READ ); + error =read_page_prepare (this, buf, mtd->writesize, + mil->payload_virt, mil->payload_phys, + nfc_geo->payload_size_in_bytes, + &payload_virt, &payload_phys); +if (error) { +pr_info ("Inadequate DMA buffer\n" ); + error = -ENOMEM ; +return error; + } + auxiliary_virt = mil->auxiliary_virt; + auxiliary_phys = mil->auxiliary_phys; + +/* go! */ + error =gpmi_read_page (this, payload_phys, auxiliary_phys); +read_page_end (this, buf, mtd->writesize, + mil->payload_virt, mil->payload_phys, + nfc_geo->payload_size_in_bytes, + payload_virt, payload_phys); +if (error) { +pr_info ("Error in ECC-based read: %d\n" , error); + goto exit_nfc; + } + +/* handle the block mark swapping */ +mil_handle_block_mark_swapping (this, payload_virt, auxiliary_virt); + +/* Loop over status bytes, accumulating ECC status. */ + failed =0 ; + corrected =0 ; + status = auxiliary_virt + nfc_geo->auxiliary_status_offset; + +for (i =0 ; i < nfc_geo->ecc_chunk_count; i++, status++) { +if ((*status ==STATUS_GOOD ) || (*status ==STATUS_ERASED )) +continue ; + +if (*status ==STATUS_UNCORRECTABLE ) { + failed++; +continue ; + } + corrected += *status; + } + +/* +* Propagate ECC status to the owning MTD only when failed or +* corrected times nearly reaches our ECC correction threshold. +*/ +if (failed || corrected >= (nfc_geo->ecc_strength -1 )) { + mtd->ecc_stats.failed += failed; + mtd->ecc_stats.corrected += corrected; + } + +/* +* It's time to deliver the OOB bytes. See mil_ecc_read_oob() for +* details about our policy for delivering the OOB. +* +* We fill the caller's buffer with set bits, and then copy the block +* mark to th caller's buffer. Note that, if block mark swapping was +* necessary, it has already been done, so we can rely on the first +* byte of the auxiliary buffer to contain the block mark. +*/ +memset (nand->oob_poi, ~0 , mtd->oobsize); + nand->oob_poi[0 ] = ((uint8_t *) auxiliary_virt)[0 ]; + +read_page_swap_end (this, buf, mtd->writesize, + mil->payload_virt, mil->payload_phys, + nfc_geo->payload_size_in_bytes, + payload_virt, payload_phys); +exit_nfc: +return error; +} + +static void mil_ecc_write_page (struct mtd_info *mtd, +struct nand_chip *nand,const uint8_t *buf) +{ +struct gpmi_nand_data *this = nand->priv; +struct bch_geometry *nfc_geo = &this->bch_geometry; +struct mil *mil = &this->mil; +const void *payload_virt; +dma_addr_t payload_phys; +const void *auxiliary_virt; +dma_addr_t auxiliary_phys; +int error; + +logio (GPMI_DEBUG_ECC_WRITE ); +if (this->swap_block_mark) { +/* +* If control arrives here, we're doing block mark swapping. +* Since we can't modify the caller's buffers, we must copy them +* into our own. +*/ +memcpy (mil->payload_virt, buf, mtd->writesize); + payload_virt = mil->payload_virt; + payload_phys = mil->payload_phys; + +memcpy (mil->auxiliary_virt, nand->oob_poi, + nfc_geo->auxiliary_size_in_bytes); + auxiliary_virt = mil->auxiliary_virt; + auxiliary_phys = mil->auxiliary_phys; + +/* Handle block mark swapping. */ +mil_handle_block_mark_swapping (this, + (void *) payload_virt, (void *) auxiliary_virt); + }else { +/* +* If control arrives here, we're not doing block mark swapping, +* so we can to try and use the caller's buffers. +*/ + error =send_page_prepare (this, + buf, mtd->writesize, + mil->payload_virt, mil->payload_phys, + nfc_geo->payload_size_in_bytes, + &payload_virt, &payload_phys); +if (error) { +pr_info ("Inadequate payload DMA buffer\n" ); +return ; + } + + error =send_page_prepare (this, + nand->oob_poi, mtd->oobsize, + mil->auxiliary_virt, mil->auxiliary_phys, + nfc_geo->auxiliary_size_in_bytes, + &auxiliary_virt, &auxiliary_phys); +if (error) { +pr_info ("Inadequate auxiliary DMA buffer\n" ); + goto exit_auxiliary; + } + } + +/* Ask the NFC. */ + error =gpmi_send_page (this, payload_phys, auxiliary_phys); +if (error) +pr_info ("Error in ECC-based write: %d\n" , error); + +if (!this->swap_block_mark) { +send_page_end (this, nand->oob_poi, mtd->oobsize, + mil->auxiliary_virt, mil->auxiliary_phys, + nfc_geo->auxiliary_size_in_bytes, + auxiliary_virt, auxiliary_phys); +exit_auxiliary: +send_page_end (this, buf, mtd->writesize, + mil->payload_virt, mil->payload_phys, + nfc_geo->payload_size_in_bytes, + payload_virt, payload_phys); + } +} + +static int mil_hook_block_markbad (struct mtd_info *mtd,loff_t ofs) +{ + registerstruct nand_chip *chip = mtd->priv; +struct gpmi_nand_data *this = chip->priv; +struct mil *mil = &this->mil; +int ret; + + mil->marking_a_bad_block = true; + ret = mil->hooked_block_markbad (mtd, ofs); + mil->marking_a_bad_block = false; +return ret; +} + +/** +* mil_ecc_read_oob() - MTD Interface ecc.read_oob(). +* +* There are several places in this driver where we have to handle the OOB and +* block marks. This is the function where things are the most complicated, so +* this is where we try to explain it all. All the other places refer back to +* here. +* +* These are the rules, in order of decreasing importance: +* +* 1) Nothing the caller does can be allowed to imperil the block mark, so all +* write operations take measures to protect it. +* +* 2) In read operations, the first byte of the OOB we return must reflect the +* true state of the block mark, no matter where that block mark appears in +* the physical page. +* +* 3) ECC-based read operations return an OOB full of set bits (since we never +* allow ECC-based writes to the OOB, it doesn't matter what ECC-based reads +* return). +* +* 4) "Raw" read operations return a direct view of the physical bytes in the +* page, using the conventional definition of which bytes are data and which +* are OOB. This gives the caller a way to see the actual, physical bytes +* in the page, without the distortions applied by our ECC engine. +* +* +* What we do for this specific read operation depends on two questions: +* +* 1) Are we doing a "raw" read, or an ECC-based read? +* +* 2) Are we using block mark swapping or transcription? +* +* There are four cases, illustrated by the following Karnaugh map: +* +* | Raw | ECC-based | +* -------------+-------------------------+-------------------------+ +* | Read the conventional | | +* | OOB at the end of the | | +* Swapping | page and return it. It | | +* | contains exactly what | | +* | we want. | Read the block mark and | +* -------------+-------------------------+ return it in a buffer | +* | Read the conventional | full of set bits. | +* | OOB at the end of the | | +* | page and also the block | | +* Transcribing | mark in the metadata. | | +* | Copy the block mark | | +* | into the first byte of | | +* | the OOB. | | +* -------------+-------------------------+-------------------------+ +* +* Note that we break rule #4 in the Transcribing/Raw case because we're not +* giving an accurate view of the actual, physical bytes in the page (we're +* overwriting the block mark). That's OK because it's more important to follow +* rule #2. +* +* It turns out that knowing whether we want an "ECC-based" or "raw" read is not +* easy. When reading a page, for example, the NAND Flash MTD code calls our +* ecc.read_page or ecc.read_page_raw function. Thus, the fact that MTD wants an +* ECC-based or raw view of the page is implicit in which function it calls +* (there is a similar pair of ECC-based/raw functions for writing). +* +* Since MTD assumes the OOB is not covered by ECC, there is no pair of +* ECC-based/raw functions for reading or or writing the OOB. The fact that the +* caller wants an ECC-based or raw view of the page is not propagated down to +* this driver. +* +* @mtd: A pointer to the owning MTD. +* @nand: A pointer to the owning NAND Flash MTD. +* @page: The page number to read. +* @sndcmd: Indicates this function should send a command to the chip before +* reading the out-of-band bytes. This is only false for small page +* chips that support auto-increment. +*/ +static int mil_ecc_read_oob (struct mtd_info *mtd,struct nand_chip *nand, +int page,int sndcmd) +{ +struct gpmi_nand_data *this = nand->priv; + +/* clear the OOB buffer */ +memset (nand->oob_poi, ~0 , mtd->oobsize); + +/* Read out the conventional OOB. */ + nand->cmdfunc (mtd,NAND_CMD_READ0 , mtd->writesize, page); + nand->read_buf (mtd, nand->oob_poi, mtd->oobsize); + +/* +* Now, we want to make sure the block mark is correct. In the +* Swapping/Raw case, we already have it. Otherwise, we need to +* explicitly read it. +*/ +if (!this->swap_block_mark) { +/* Read the block mark into the first byte of the OOB buffer. */ + nand->cmdfunc (mtd,NAND_CMD_READ0 ,0 , page); + nand->oob_poi[0 ] = nand->read_byte (mtd); + } + +/* +* Return true, indicating that the next call to this function must send +* a command. +*/ +return true; +} + +static int mil_ecc_write_oob (struct mtd_info *mtd, +struct nand_chip *nand,int page) +{ +struct gpmi_nand_data *this = nand->priv; +struct device *dev = this->dev; +struct mil *mil = &this->mil; +uint8_t *block_mark; +int block_mark_column; +int status; +int error =0 ; + +/* Only marking a block bad is permitted to write the OOB. */ +if (!mil->marking_a_bad_block) { +dev_emerg (dev,"This driver doesn't support writing the OOB\n" ); +WARN_ON (1 ); + error = -EIO ; + goto exit; + } + +if (this->swap_block_mark) + block_mark_column = mtd->writesize; +else + block_mark_column =0 ; + +/* Write the block mark. */ + block_mark = mil->data_buffer_dma; + block_mark[0 ] =0 ;/* bad block marker */ + + nand->cmdfunc (mtd,NAND_CMD_SEQIN , block_mark_column, page); + nand->write_buf (mtd, block_mark,1 ); + nand->cmdfunc (mtd,NAND_CMD_PAGEPROG ,-1 ,-1 ); + + status = nand->waitfunc (mtd, nand); + +/* Check if it worked. */ +if (status &NAND_STATUS_FAIL ) + error = -EIO ; +exit: +return error; +} + +/** +* mil_block_bad - Claims all blocks are good. +* +* In principle, this function is *only* called when the NAND Flash MTD system +* isn't allowed to keep an in-memory bad block table, so it is forced to ask +* the driver for bad block information. +* +* In fact, we permit the NAND Flash MTD system to have an in-memory BBT, so +* this function is *only* called when we take it away. +* +* We take away the in-memory BBT when the user sets the "ignorebad" parameter, +* which indicates that all blocks should be reported good. +* +* Thus, this function is only called when we want *all* blocks to look good, +* so it *always* return success. +* +* @mtd: Ignored. +* @ofs: Ignored. +* @getchip: Ignored. +*/ +static int mil_block_bad (struct mtd_info *mtd,loff_t ofs,int getchip) +{ +return 0 ; +} + +static int __devinit nand_boot_set_geometry (struct gpmi_nand_data *this) +{ +struct boot_rom_geometry *geometry = &this->rom_geometry; + +/* +* Set the boot block stride size. +* +* In principle, we should be reading this from the OTP bits, since +* that's where the ROM is going to get it. In fact, we don't have any +* way to read the OTP bits, so we go with the default and hope for the +* best. +*/ + geometry->stride_size_in_pages =64 ; + +/* +* Set the search area stride exponent. +* +* In principle, we should be reading this from the OTP bits, since +* that's where the ROM is going to get it. In fact, we don't have any +* way to read the OTP bits, so we go with the default and hope for the +* best. +*/ + geometry->search_area_stride_exponent =2 ; + +if (gpmi_debug &GPMI_DEBUG_INIT ) +pr_info ("stride size in page : %d, search areas : %d\n" , + geometry->stride_size_in_pages, + geometry->search_area_stride_exponent); +return 0 ; +} + +static const char *fingerprint ="STMP" ; +static int __devinit mx23_check_transcription_stamp (struct gpmi_nand_data *this) +{ +struct boot_rom_geometry *rom_geo = &this->rom_geometry; +struct mil *mil = &this->mil; +struct mtd_info *mtd = &mil->mtd; +struct nand_chip *nand = &mil->nand; +unsigned int search_area_size_in_strides; +unsigned int stride; +unsigned int page; +loff_t byte; +uint8_t *buffer = nand->buffers->databuf; +int saved_chip_number; +int found_an_ncb_fingerprint = false; + +/* Compute the number of strides in a search area. */ + search_area_size_in_strides =1 << rom_geo->search_area_stride_exponent; + +/* Select chip 0. */ + saved_chip_number = mil->current_chip; + nand->select_chip (mtd,0 ); + +/* +* Loop through the first search area, looking for the NCB fingerprint. +*/ +pr_info ("Scanning for an NCB fingerprint...\n" ); + +for (stride =0 ; stride < search_area_size_in_strides; stride++) { +/* Compute the page and byte addresses. */ + page = stride * rom_geo->stride_size_in_pages; + byte = page * mtd->writesize; + +pr_info (" Looking for a fingerprint in page 0x%x\n" , page); + +/* +* Read the NCB fingerprint. The fingerprint is four bytes long +* and starts in the 12th byte of the page. +*/ + nand->cmdfunc (mtd,NAND_CMD_READ0 ,12 , page); + nand->read_buf (mtd, buffer,strlen (fingerprint)); + +/* Look for the fingerprint. */ +if (!memcmp (buffer, fingerprint,strlen (fingerprint))) { + found_an_ncb_fingerprint = true; +break ; + } + + } + +/* Deselect chip 0. */ + nand->select_chip (mtd, saved_chip_number); + +if (found_an_ncb_fingerprint) +pr_info (" Found a fingerprint\n" ); +else +pr_info (" No fingerprint found\n" ); +return found_an_ncb_fingerprint; +} + +/* Writes a transcription stamp. */ +static int __devinit mx23_write_transcription_stamp (struct gpmi_nand_data *this) +{ +struct device *dev = this->dev; +struct boot_rom_geometry *rom_geo = &this->rom_geometry; +struct mil *mil = &this->mil; +struct mtd_info *mtd = &mil->mtd; +struct nand_chip *nand = &mil->nand; +unsigned int block_size_in_pages; +unsigned int search_area_size_in_strides; +unsigned int search_area_size_in_pages; +unsigned int search_area_size_in_blocks; +unsigned int block; +unsigned int stride; +unsigned int page; +loff_t byte; +uint8_t *buffer = nand->buffers->databuf; +int saved_chip_number; +int status; + +/* Compute the search area geometry. */ + block_size_in_pages = mtd->erasesize / mtd->writesize; + search_area_size_in_strides =1 << rom_geo->search_area_stride_exponent; + search_area_size_in_pages = search_area_size_in_strides * + rom_geo->stride_size_in_pages; + search_area_size_in_blocks = + (search_area_size_in_pages + (block_size_in_pages -1 )) / + block_size_in_pages; + +pr_info ("-------------------------------------------\n" ); +pr_info ("Search Area Geometry\n" ); +pr_info ("-------------------------------------------\n" ); +pr_info ("Search Area in Blocks : %u\n" , search_area_size_in_blocks); +pr_info ("Search Area in Strides: %u\n" , search_area_size_in_strides); +pr_info ("Search Area in Pages : %u\n" , search_area_size_in_pages); + +/* Select chip 0. */ + saved_chip_number = mil->current_chip; + nand->select_chip (mtd,0 ); + +/* Loop over blocks in the first search area, erasing them. */ +pr_info ("Erasing the search area...\n" ); + +for (block =0 ; block < search_area_size_in_blocks; block++) { +/* Compute the page address. */ + page = block * block_size_in_pages; + +/* Erase this block. */ +pr_info (" Erasing block 0x%x\n" , block); + nand->cmdfunc (mtd,NAND_CMD_ERASE1 ,-1 , page); + nand->cmdfunc (mtd,NAND_CMD_ERASE2 ,-1 ,-1 ); + +/* Wait for the erase to finish. */ + status = nand->waitfunc (mtd, nand); +if (status &NAND_STATUS_FAIL ) +dev_err (dev,"[%s] Erase failed.\n" , __func__); + } + +/* Write the NCB fingerprint into the page buffer. */ +memset (buffer, ~0 , mtd->writesize); +memset (nand->oob_poi, ~0 , mtd->oobsize); +memcpy (buffer +12 , fingerprint,strlen (fingerprint)); + +/* Loop through the first search area, writing NCB fingerprints. */ +pr_info ("Writing NCB fingerprints...\n" ); +for (stride =0 ; stride < search_area_size_in_strides; stride++) { +/* Compute the page and byte addresses. */ + page = stride * rom_geo->stride_size_in_pages; + byte = page * mtd->writesize; + +/* Write the first page of the current stride. */ +pr_info (" Writing an NCB fingerprint in page 0x%x\n" , page); + nand->cmdfunc (mtd,NAND_CMD_SEQIN ,0x00 , page); + nand->ecc.write_page_raw (mtd, nand, buffer); + nand->cmdfunc (mtd,NAND_CMD_PAGEPROG ,-1 ,-1 ); + +/* Wait for the write to finish. */ + status = nand->waitfunc (mtd, nand); +if (status &NAND_STATUS_FAIL ) +dev_err (dev,"[%s] Write failed.\n" , __func__); + } + +/* Deselect chip 0. */ + nand->select_chip (mtd, saved_chip_number); +return 0 ; +} + +static int __devinit mx23_boot_init (struct gpmi_nand_data *this) +{ +struct device *dev = this->dev; +struct mil *mil = &this->mil; +struct nand_chip *nand = &mil->nand; +struct mtd_info *mtd = &mil->mtd; +unsigned int block_count; +unsigned int block; +int chip; +int page; +loff_t byte; +uint8_t block_mark; +int error =0 ; + +/* +* If control arrives here, we can't use block mark swapping, which +* means we're forced to use transcription. First, scan for the +* transcription stamp. If we find it, then we don't have to do +* anything -- the block marks are already transcribed. +*/ +if (mx23_check_transcription_stamp (this)) +return 0 ; + +/* +* If control arrives here, we couldn't find a transcription stamp, so +* so we presume the block marks are in the conventional location. +*/ +pr_info ("Transcribing bad block marks...\n" ); + +/* Compute the number of blocks in the entire medium. */ + block_count = nand->chipsize >> nand->phys_erase_shift; + +/* +* Loop over all the blocks in the medium, transcribing block marks as +* we go. +*/ +for (block =0 ; block < block_count; block++) { +/* +* Compute the chip, page and byte addresses for this block's +* conventional mark. +*/ + chip = block >> (nand->chip_shift - nand->phys_erase_shift); + page = block << (nand->phys_erase_shift - nand->page_shift); + byte = block << nand->phys_erase_shift; + +/* Select the chip. */ + nand->select_chip (mtd, chip); + +/* Send the command to read the conventional block mark. */ + nand->cmdfunc (mtd,NAND_CMD_READ0 , mtd->writesize, page); + +/* Read the conventional block mark. */ + block_mark = nand->read_byte (mtd); + +/* +* Check if the block is marked bad. If so, we need to mark it +* again, but this time the result will be a mark in the +* location where we transcribe block marks. +* +* Notice that we have to explicitly set the marking_a_bad_block +* member before we call through the block_markbad function +* pointer in the owning struct nand_chip. If we could call +* though the block_markbad function pointer in the owning +* struct mtd_info, which we have hooked, then this would be +* taken care of for us. Unfortunately, we can't because that +* higher-level code path will do things like consulting the +* in-memory bad block table -- which doesn't even exist yet! +* So, we have to call at a lower level and handle some details +* ourselves. +*/ +if (block_mark !=0xff ) { +pr_info ("Transcribing mark in block %u\n" , block); + mil->marking_a_bad_block = true; + error = nand->block_markbad (mtd, byte); + mil->marking_a_bad_block = false; +if (error) +dev_err (dev,"Failed to mark block bad with " +"error %d\n" , error); + } + +/* Deselect the chip. */ + nand->select_chip (mtd,-1 ); + } + +/* Write the stamp that indicates we've transcribed the block marks. */ +mx23_write_transcription_stamp (this); +return 0 ; +} + +static int __devinit nand_boot_init (struct gpmi_nand_data *this) +{ +nand_boot_set_geometry (this); + +/* This is ROM arch-specific initilization before the BBT scanning. */ +if (GPMI_IS_MX23 (this)) +return mx23_boot_init (this); +return 0 ; +} + +static void show_bch_geometry (struct bch_geometry *geo) +{ +pr_info ("---------------------------------------\n" ); +pr_info (" BCH Geometry\n" ); +pr_info ("---------------------------------------\n" ); +pr_info ("ECC Algorithm : %s\n" , geo->ecc_algorithm); +pr_info ("ECC Strength : %u\n" , geo->ecc_strength); +pr_info ("Page Size in Bytes : %u\n" , geo->page_size_in_bytes); +pr_info ("Metadata Size in Bytes : %u\n" , geo->metadata_size_in_bytes); +pr_info ("ECC Chunk Size in Bytes: %u\n" , geo->ecc_chunk_size_in_bytes); +pr_info ("ECC Chunk Count : %u\n" , geo->ecc_chunk_count); +pr_info ("Payload Size in Bytes : %u\n" , geo->payload_size_in_bytes); +pr_info ("Auxiliary Size in Bytes: %u\n" , geo->auxiliary_size_in_bytes); +pr_info ("Auxiliary Status Offset: %u\n" , geo->auxiliary_status_offset); +pr_info ("Block Mark Byte Offset : %u\n" , geo->block_mark_byte_offset); +pr_info ("Block Mark Bit Offset : %u\n" , geo->block_mark_bit_offset); +} + +static int __devinit mil_set_geometry (struct gpmi_nand_data *this) +{ +struct bch_geometry *geo = &this->bch_geometry; +int error; + +/* Free the temporary DMA memory for reading ID. */ +mil_free_dma_buffer (this); + +/* Set up the NFC geometry which is used by BCH. */ + error =bch_set_geometry (this); +if (error) { +pr_info ("set geometry error : %d\n" , error); +return error; + } +if (gpmi_debug &GPMI_DEBUG_INIT ) +show_bch_geometry (geo); + +/* Alloc the new DMA buffers according to the pagesize and oobsize */ +return mil_alloc_dma_buffer (this); +} + +static int mil_pre_bbt_scan (struct gpmi_nand_data *this) +{ +struct nand_chip *nand = &this->mil.nand; +struct mtd_info *mtd = &this->mil.mtd; +struct nand_ecclayout *layout = nand->ecc.layout; +int error; + +/* fix the ECC layout before the scanning */ + layout->eccbytes =0 ; + layout->oobavail = mtd->oobsize; + layout->oobfree[0 ].offset =0 ; + layout->oobfree[0 ].length = mtd->oobsize; + + mtd->oobavail = nand->ecc.layout->oobavail; + +/* Set up swap block-mark, must be set before the mil_set_geometry() */ +if (GPMI_IS_MX23 (this)) + this->swap_block_mark = false; +else + this->swap_block_mark = true; + +/* Set up the medium geometry */ + error =mil_set_geometry (this); +if (error) +return error; + +/* extra init : enable the TOGGLE or ONFI. */ + +/* NAND boot init, depends on the mil_set_geometry(). */ +return nand_boot_init (this); +} + +static int mil_scan_bbt (struct mtd_info *mtd) +{ +struct nand_chip *nand = mtd->priv; +struct gpmi_nand_data *this = nand->priv; +int error; + +/* Prepare for the BBT scan. */ + error =mil_pre_bbt_scan (this); +if (error) +return error; + +/* use the default BBT implementation */ +return nand_default_bbt (mtd); +} + +static const char *cmd_parse[] = {"cmdlinepart" ,NULL }; +static int __devinit mil_partitions_init (struct gpmi_nand_data *this) +{ +struct gpmi_nand_platform_data *pdata = this->pdata; +struct mil *mil = &this->mil; +struct mtd_info *mtd = &mil->mtd; + +/* use the command line for simple partitions layout */ + mil->partition_count =parse_mtd_partitions (mtd, cmd_parse, + &mil->partitions,0 ); +if (mil->partition_count) +return mtd_device_register (mtd, mil->partitions, + mil->partition_count); + +/* The complicated partitions layout uses this. */ +if (pdata->partitions && pdata->partition_count >0 ) +return mtd_device_register (mtd, pdata->partitions, + pdata->partition_count); +return mtd_device_register (mtd,NULL ,0 ); +} + +static void mil_partitions_exit (struct gpmi_nand_data *this) +{ +struct mil *mil = &this->mil; +struct mtd_info *mtd = &mil->mtd; + +mtd_device_unregister (mtd); +kfree (mil->partitions); + mil->partition_count =0 ; +} + +/* Initializes the MTD Interface Layer */ +static int __devinit gpmi_nfc_mil_init (struct gpmi_nand_data *this) +{ +struct gpmi_nand_platform_data *pdata = this->pdata; +struct mil *mil = &this->mil; +struct mtd_info *mtd = &mil->mtd; +struct nand_chip *nand = &mil->nand; +int error; + +/* Initialize MIL data */ + mil->current_chip =-1 ; + mil->command_length =0 ; + mil->page_buffer_virt =NULL ; + mil->page_buffer_size =0 ; + +/* Initialize the MTD data structures */ + mtd->priv = nand; + mtd->name ="gpmi-nand" ; + mtd->owner =THIS_MODULE ; + nand->priv = this; + +/* Controls */ + nand->select_chip = mil_select_chip; + nand->cmd_ctrl = mil_cmd_ctrl; + nand->dev_ready = mil_dev_ready; + +/* +* Low-level I/O : +* We don't support a 16-bit NAND Flash bus, +* so we don't implement read_word. +*/ + nand->read_byte = mil_read_byte; + nand->read_buf = mil_read_buf; + nand->write_buf = mil_write_buf; + +/* ECC-aware I/O */ + nand->ecc.read_page = mil_ecc_read_page; + nand->ecc.write_page = mil_ecc_write_page; + +/* High-level I/O */ + nand->ecc.read_oob = mil_ecc_read_oob; + nand->ecc.write_oob = mil_ecc_write_oob; + +/* Bad Block Management */ + nand->block_bad = mil_block_bad; + nand->scan_bbt = mil_scan_bbt; + nand->badblock_pattern = &gpmi_bbt_descr; + +/* Disallow partial page writes */ + nand->options |=NAND_NO_SUBPAGE_WRITE ; + +/* +* Tell the NAND Flash MTD system that we'll be handling ECC with our +* own hardware. It turns out that we still have to fill in the ECC size +* because the MTD code will divide by it -- even though it doesn't +* actually care. +*/ + nand->ecc.mode =NAND_ECC_HW ; + nand->ecc.size =1 ; + +/* use our layout */ + nand->ecc.layout = &mil->oob_layout; + +/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */ + this->bch_geometry.payload_size_in_bytes =1024 ; + this->bch_geometry.auxiliary_size_in_bytes =128 ; + error =mil_alloc_dma_buffer (this); +if (error) + goto exit_dma_allocation; + +printk (KERN_INFO "GPMI-NFC : Scanning for NAND Flash chips...\n" ); + error =nand_scan (mtd, pdata->max_chip_count); +if (error) { +pr_info ("Chip scan failed\n" ); + goto exit_nand_scan; + } + +/* Take over the management of the OOB */ + mil->hooked_block_markbad = mtd->block_markbad; + mtd->block_markbad = mil_hook_block_markbad; + +/* Construct partitions as necessary. */ + error =mil_partitions_init (this); +if (error) + goto exit_partitions; +return 0 ; + +exit_partitions: +nand_release (&mil->mtd); +exit_nand_scan: +mil_free_dma_buffer (this); +exit_dma_allocation: +return error; +} + +void gpmi_nand_mil_exit (struct gpmi_nand_data *this) +{ +struct mil *mil = &this->mil; + +mil_partitions_exit (this); +nand_release (&mil->mtd); +mil_free_dma_buffer (this); +} + +static int __devinit gpmi_nand_probe (struct platform_device *pdev) +{ +struct gpmi_nand_platform_data *pdata = pdev->dev.platform_data; +struct gpmi_nand_data *this; +int error; + + this =kzalloc (sizeof (*this),GFP_KERNEL ); +if (!this) { +pr_info ("Failed to allocate per-device memory\n" ); +return -ENOMEM ; + } + +/* Set up our data structures. */ +platform_set_drvdata (pdev, this); + this->pdev = pdev; + this->dev = &pdev->dev; + this->pdata = pdata; + +/* setup the platform */ +if (pdata->platform_init) { + error = pdata->platform_init (); +if (error) + goto platform_init_error; + } + +/* Acquire the resources we need. */ + error =acquire_resources (this); +if (error) + goto exit_acquire_resources; + +/* Set up the GPMI/BCH hardware. */ + error =init_hardware (this); +if (error) + goto exit_nfc_init; + +/* Initialize the MTD Interface Layer. */ + error =gpmi_nfc_mil_init (this); +if (error) + goto exit_mil_init; + +manage_sysfs_files (this, true); +return 0 ; + +exit_mil_init: +exit_nfc_init: +release_resources (this); +platform_init_error: +exit_acquire_resources: +platform_set_drvdata (pdev,NULL ); +kfree (this); +return error; +} + +static int __exit gpmi_nand_remove(struct platform_device *pdev) +{ +struct gpmi_nand_data *this =platform_get_drvdata (pdev); + +manage_sysfs_files (this, false); +gpmi_nand_mil_exit (this); +release_resources (this); +platform_set_drvdata (pdev,NULL ); +kfree (this); +return 0 ; +} + +static const struct platform_device_id gpmi_ids[] = { + { + .name ="imx23-gpmi-nand" , + .driver_data =IS_MX23 , + }, { + .name ="imx28-gpmi-nand" , + .driver_data =IS_MX28 , + }, {}, +}; + +/* This structure represents this driver to the platform management system. */ +static struct platform_driver gpmi_nand_driver = { + .driver = { + .name ="gpmi-nand" , + }, + .probe = gpmi_nand_probe, + .remove =__exit_p (gpmi_nand_remove), + .id_table = gpmi_ids, +}; + +static int __init gpmi_nand_init (void ) +{ +int err; + +if (!enable_gpmi_nand) +return 0 ; + + err =platform_driver_register (&gpmi_nand_driver); +if (err ==0 ) +printk (KERN_INFO "GPMI NFC driver registered. (IMX)\n" ); +else +pr_err ("i.MX GPMI NFC driver registration failed\n" ); +return err; +} + +static void __exit gpmi_nand_exit(void) +{ +platform_driver_unregister (&gpmi_nand_driver); +} + +static int __init gpmi_nand_setup (char *__unused) +{ + enable_gpmi_nand = true; +return 1 ; +} +__setup ("gpmi_nand" , gpmi_nand_setup); + +static int __init gpmi_debug_setup (char *__unused) +{ + gpmi_debug =GPMI_DEBUG_INIT ; + enable_gpmi_nand = true; +return 1 ; +} +__setup ("gpmi_debug_init" , gpmi_debug_setup); + +module_init (gpmi_nand_init); +module_exit (gpmi_nand_exit); + +MODULE_AUTHOR ("Freescale Semiconductor, Inc." ); +MODULE_DESCRIPTION ("i.MX GPMI NAND Flash Controller Driver" ); +MODULE_LICENSE ("GPL" );
drivers/mtd/nand/gpmi-nand/gpmi-nand.h new file +390 -0
390 lines not on this page · raw message
Signature · 1 line
1.7.0.4
PATCH v8 2/3 MTD : add helper functions library and header files for GPMI NAND driver
In reply to Huang Shijiebch-regs.h : registers file for BCH modulegpmi-regs.h: registers file for GPMI modulegpmi-lib.c: helper functions library.
--- drivers/mtd/nand/gpmi-nand/bch-regs.h | 88 +++ drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 978 ++++++++++++++++++++++++++++++++ drivers/mtd/nand/gpmi-nand/gpmi-regs.h | 174 ++++++ 3 files changed, 1240 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/gpmi-nand/bch-regs.h create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-lib.c create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-regs.h
drivers/mtd/nand/gpmi-nand/bch-regs.h new file +88 -0
@@ -0,0 +1,88 @@ +/* +* Freescale GPMI NAND Flash Driver +* +* Copyright 2008-2011 Freescale Semiconductor, Inc. +* Copyright 2008 Embedded Alley Solutions, Inc. +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License along +* with this program; if not, write to the Free Software Foundation, Inc., +* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +*/ +#ifndef __GPMI_NAND_BCH_REGS_H +#define __GPMI_NAND_BCH_REGS_H + +/*============================================================================*/ +#define HW_BCH_CTRL 0x00000000 +#define HW_BCH_CTRL_SET 0x00000004 +#define HW_BCH_CTRL_CLR 0x00000008 +#define HW_BCH_CTRL_TOG 0x0000000c + +#define BM_BCH_CTRL_COMPLETE_IRQ_EN (1 << 8) +#define BM_BCH_CTRL_COMPLETE_IRQ (1 << 0) + +/*============================================================================*/ +#define HW_BCH_STATUS0 0x00000010 +#define HW_BCH_MODE 0x00000020 +#define HW_BCH_ENCODEPTR 0x00000030 +#define HW_BCH_DATAPTR 0x00000040 +#define HW_BCH_METAPTR 0x00000050 +#define HW_BCH_LAYOUTSELECT 0x00000070 + +/*============================================================================*/ +#define HW_BCH_FLASH0LAYOUT0 0x00000080 + +#define BP_BCH_FLASH0LAYOUT0_NBLOCKS 24 +#define BM_BCH_FLASH0LAYOUT0_NBLOCKS (0xff << BP_BCH_FLASH0LAYOUT0_NBLOCKS) +#define BF_BCH_FLASH0LAYOUT0_NBLOCKS (v) \ + (((v) << BP_BCH_FLASH0LAYOUT0_NBLOCKS) & BM_BCH_FLASH0LAYOUT0_NBLOCKS) + +#define BP_BCH_FLASH0LAYOUT0_META_SIZE 16 +#define BM_BCH_FLASH0LAYOUT0_META_SIZE (0xff << BP_BCH_FLASH0LAYOUT0_META_SIZE) +#define BF_BCH_FLASH0LAYOUT0_META_SIZE (v) \ + (((v) << BP_BCH_FLASH0LAYOUT0_META_SIZE)\ + & BM_BCH_FLASH0LAYOUT0_META_SIZE) + +#define BP_BCH_FLASH0LAYOUT0_ECC0 12 +#define BM_BCH_FLASH0LAYOUT0_ECC0 (0xf << BP_BCH_FLASH0LAYOUT0_ECC0) +#define BF_BCH_FLASH0LAYOUT0_ECC0 (v) \ + (((v) << BP_BCH_FLASH0LAYOUT0_ECC0) & BM_BCH_FLASH0LAYOUT0_ECC0) + +#define BP_BCH_FLASH0LAYOUT0_DATA0_SIZE 0 +#define BM_BCH_FLASH0LAYOUT0_DATA0_SIZE \ + (0xfff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE) +#define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE (v) \ + (((v) << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)\ + & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) + +/*============================================================================*/ +#define HW_BCH_FLASH0LAYOUT1 0x00000090 + +#define BP_BCH_FLASH0LAYOUT1_PAGE_SIZE 16 +#define BM_BCH_FLASH0LAYOUT1_PAGE_SIZE \ + (0xffff << BP_BCH_FLASH0LAYOUT1_PAGE_SIZE) +#define BF_BCH_FLASH0LAYOUT1_PAGE_SIZE (v) \ + (((v) << BP_BCH_FLASH0LAYOUT1_PAGE_SIZE) \ + & BM_BCH_FLASH0LAYOUT1_PAGE_SIZE) + +#define BP_BCH_FLASH0LAYOUT1_ECCN 12 +#define BM_BCH_FLASH0LAYOUT1_ECCN (0xf << BP_BCH_FLASH0LAYOUT1_ECCN) +#define BF_BCH_FLASH0LAYOUT1_ECCN (v) \ + (((v) << BP_BCH_FLASH0LAYOUT1_ECCN) & BM_BCH_FLASH0LAYOUT1_ECCN) + +#define BP_BCH_FLASH0LAYOUT1_DATAN_SIZE 0 +#define BM_BCH_FLASH0LAYOUT1_DATAN_SIZE \ + (0xfff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE) +#define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE (v) \ + (((v) << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE) \ + & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) +#endif
drivers/mtd/nand/gpmi-nand/gpmi-lib.c new file +978 -0
978 lines not on this page · raw message
drivers/mtd/nand/gpmi-nand/gpmi-regs.h new file +174 -0
174 lines not on this page · raw message
Signature · 1 line
1.7.0.4
PATCH v8 3/3 MTD : add GPMI-NAND driver in the config and Makefile
In reply to Huang Shijieadd the GPMI-NAND driver in the relevant Kconfig and Makefile in the MTD.
--- drivers/mtd/nand/Kconfig | 11 +++++++++++ drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/gpmi-nand/Makefile | 3 +++ 3 files changed, 15 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/gpmi-nand/Makefile
drivers/mtd/nand/Kconfig +11 -0
@@ -423,6 +423,17 @@ config MTD_NAND_NANDSIM The simulator may simulate various NAND flash chips for the MTD nand layer. +config MTD_NAND_GPMI_NAND + bool "GPMI NAND Flash Controller driver" + depends on MTD_NAND && (SOC_IMX23 || SOC_IMX28) + select MTD_PARTITIONS + select MTD_CMDLINE_PARTS + help + Enables NAND Flash support for IMX23 or IMX28. + The GPMI controller is very powerful, with the help of BCH + module, it can do the hardware ECC. The GPMI supports several + NAND flashs at the same time. + config MTD_NAND_PLATFORM tristate "Support for generic platform NAND driver" help
drivers/mtd/nand/Makefile +1 -0
@@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_BCM_UMI) += bcm_umi_nand.o nand_bcm_umi.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o +obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ nand-objs := nand_base.o nand_bbt.o
drivers/mtd/nand/gpmi-nand/Makefile new file +3 -0
@@ -0,0 +1,3 @@ +obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi_nand.o +gpmi_nand-objs += gpmi-nand.o +gpmi_nand-objs += gpmi-lib.o
Signature · 1 line
1.7.0.4
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Huang ShijieQuoted 2 lines
The general-purpose media interface(GPMI) controller is a flexible interface to up to several NAND flashs.
...
Quoted 4 lines
To Walfram & Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the ecclayout to do the job. Could you give me some hint? thanks.
Have you checked mxc_nand.c for example? There is
static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
.eccbytes = 5,
.eccpos = {6, 7, 8, 9, 10},
.oobfree = {{0, 5}, {12, 4}, }
}defined as one layout. Now, you could define one where oobfree is empty and eccbytes as big as the oob-area.
Quoted 8 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.htmlThe driver also depends on another DMA patch by Shawn:
[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
This makes it difficult for testers/reviewers. Please try to get a git-branch from Freescale or Linaro.
Quoted 3 lines
[4] DMA timeout issue. I use the .config created by
make mxs_defconfigand the bug never occur. It seems some other module has impact to the DMA.
Sadly, I can't confirm that. DMA timeout happens with my config as well as with the mxs_defconfig. ubiformat breaks immediately when trying to write.
Problem is that I am away from my dev-machine for a few days. I can do limited tests remotely but not develop actively right now. But if you need logs...
Thanks,
Wolfram
Signature · 9 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110721/77ffac8f/attachment-0001.sig>
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 9 lines
Quoted 2 lines
The general-purpose media interface(GPMI) controller is a flexible interface to up to several NAND flashs.
...
Quoted 4 lines
To Walfram & Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the ecclayout to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There is
Quoted 9 lines
static struct nand_ecclayout nandv1_hw_eccoob_smallpage = { .eccbytes = 5, .eccpos = {6, 7, 8, 9, 10}, .oobfree = {{0, 5}, {12, 4}, } }defined as one layout. Now, you could define one where oobfree is empty and eccbytes as big as the oob-area.
thanks. I will check the code.
Quoted 11 lines
Quoted 8 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.htmlThe driver also depends on another DMA patch by Shawn:
[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.htmlThis makes it difficult for testers/reviewers. Please try to get a git-branch from Freescale or Linaro.
Shawn will merge my patches to his Linaro branch.
Quoted 5 lines
Quoted 3 lines
[4] DMA timeout issue. I use the .config created by
make mxs_defconfigand the bug never occur. It seems some other module has impact to the DMA.Sadly, I can't confirm that. DMA timeout happens with my config as well as with the
mxs_defconfig. ubiformat breaks immediately when trying to write.
Please check the attachment:
[1] my_config is my tested .config file, you can test it.
[2] a.sh is my testing shell script which also tests the ubiformat.
Best Regards
Huang Shijie
Quoted 7 lines
Problem is that I am away from my dev-machine for a few days. I can do limited tests remotely but not develop actively right now. But if you need logs...
Thanks,
Wolfram
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: my_config
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110722/0317e8b2/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.sh
Type: application/x-sh
Size: 347 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110722/0317e8b2/attachment-0001.sh>
v8 cover add the GPMI controller driver for IMX23/IMX28
Quoted 26 lines · Huang Shijie
Hi,
Quoted 9 lines
Quoted 2 lines
The general-purpose media interface(GPMI) controller is a flexible interface to up to several NAND flashs.
...
Quoted 4 lines
To Walfram & Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the ecclayout to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There isQuoted 9 lines
static struct nand_ecclayout nandv1_hw_eccoob_smallpage = { .eccbytes = 5, .eccpos = {6, 7, 8, 9, 10}, .oobfree = {{0, 5}, {12, 4}, } }defined as one layout. Now, you could define one where oobfree is empty and eccbytes as big as the oob-area.
thanks. I will check the code.
Quoted 6 lines
Quoted 6 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
The driver also depends on another DMA patch by Shawn:
[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.htmlThis makes it difficult for testers/reviewers. Please try to get a git-branch from Freescale or Linaro.
Shawn will merge my patches to his Linaro branch.
git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
Shijie, please check and test it. I only did a build test.
Signature · 2 lines
Regards, Shawn
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi Wolfram:
Quoted 27 lines · Huang Shijie
Quoted 26 lines
Hi,
Quoted 9 lines
Quoted 2 lines
The general-purpose media interface(GPMI) controller is a flexible interface to up to several NAND flashs.
...
Quoted 4 lines
To Walfram& Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the ecclayout to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There isQuoted 9 lines
static struct nand_ecclayout nandv1_hw_eccoob_smallpage = { .eccbytes = 5, .eccpos = {6, 7, 8, 9, 10}, .oobfree = {{0, 5}, {12, 4}, } }defined as one layout. Now, you could define one where oobfree is empty and eccbytes as big as the oob-area.
thanks. I will check the code.
Quoted 6 lines
Quoted 6 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
The driver also depends on another DMA patch by Shawn:
[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.htmlThis makes it difficult for testers/reviewers. Please try to get a git-branch from Freescale or Linaro.
Shawn will merge my patches to his Linaro branch.
git://git.linaro.org/people/shawnguo/linux-2.6.gitmxs-gpmi
Please test the GPMI driver based this git tree.
I tested, and the DMA-timeout does not occur any more.
I notice that Shawn added two more patched to /arch/arm/config/mxs_defconfig:
[1] ARM: mxs_defconfig: Add mx23evk and mx28evk build
[2] ARM: mxs_defconfig: Change CONFIG_RTC_CLASS 'm' to 'y'
Please check it. Maybe your kernel code misses them.
Of course, you can use the my_config (i sent you last mail) for .config.
Best Regards
Huang Shijie
Quoted 2 lines
Shijie, please check and test it. I only did a build test.
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.
I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs gpmi_debug_init
During boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
...
(see log file in attach line 89)
When trying flash_erraseall /dev/mtd1 I get:
Erasing 128 Kibyte @ 20000 -- 0 % complete [ 16.700000] [gpmi_read_data : 832 ] step 1 error
[ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_read_data : 832 ] step 1 error
libmtd: error!: MEMERA[ 16.740000] [ gpmi_send_command : 749 ] step 1 error
SE64 ioctl failed for eraseblock[ 16.750000] [ mil_cmd_ctrl : 894 ]
Chip: 0, Error -1
1 (mtd1)
error 5 (Input/output error)flash_erase: error!: /dev/mtd1: MTD Erase failure
error 5 (Input/output error)
...
(see log file in attach line 128 and further)
Environment:
- patches on a 2.6.39.1 kernel (needed to modify the patch a little for changed mtd add/del interface).
- using this on our own mx23 based board, so also added some board init code for that.
Quoted 52 lines · Huang Shijie
Hi Wolfram:
Quoted 51 lines · Huang Shijie
Quoted 49 lines
Hi,
Quoted 21 lines
Quoted 4 lines
The general-purpose media interface(GPMI) controller is a flexible interface
to up to several NAND flashs....
Quoted 6 lines
To Walfram& ?Artem:
? ? About how to disable the JFFS2 to use the OOB:
? ? I read the code, and I still have no idea about how to use the ecclayout
? ? to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There isstatic struct
nand_ecclayoutnandv1_hw_eccoob_smallpage= { ? ? ? ? .eccbytes = 5,
? ? ? ? .eccpos = {6, 7, 8, 9, 10},
? ? ? ? .oobfree = {{0, 5}, {12, 4}, }
}Quoted 4 lines
defined as one layout. Now, you could define one where oobfree is empty and
eccbytes as big as the oob-area.thanks. I will check the code.
Quoted 12 lines
Quoted 12 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
? ? ? ?[1]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
? ? ? ?[2]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
? ? ? ?[3]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
? ? ? ?[4]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.htmlQuoted 8 lines
Quoted 3 lines
The driver also depends on another DMA patch by Shawn:
? ? ? ?[0]
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.htmlThis makes it difficult for testers/reviewers. Please try to get a git-branch
from Freescale or Linaro.Shawn will merge my patches to his Linaro branch.
I don't see the DMA patch in the git?
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
git://git.linaro.org/people/shawnguo/linux-2.6.gitmxs-gpmiPlease test the GPMI driver based this git tree.
I will try that on an mx23evk board.
Quoted 9 lines
I tested, and the DMA-timeout does not occur any more.
I notice that Shawn added two more patched to /arch/arm/config/mxs_defconfig:
[1] ARM:mxs_defconfig: Add mx23evk and mx28evk build
[2] ARM:mxs_defconfig: ChangeCONFIG_RTC_CLASS'm' to 'y'Please check it. Maybe your kernel code misses them.
I don't see any of this in the git?
Quoted 17 lines
Of course, you can use the
my_config(i sent you last mail) for .config.Best Regards
Huang ShijieQuoted 2 lines
Shijie, please check and test it. ?I only did a build test.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Thanks for your test.
Quoted 35 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)When trying
flash_erraseall/dev/mtd1I get:
Erasing 128 Kibyte @ 20000 -- 0 % complete [ 16.700000] [gpmi_read_data: 832 ] step 1 error[ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_send_command : 749 ] step 1 error [ 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1 [ 16.700000] [ gpmi_read_data : 832 ] step 1 errorlibmtd: error!: MEMERA[ 16.740000] [
gpmi_send_command: 749 ] step 1 error
SE64 ioctl failed for eraseblock[ 16.750000] [mil_cmd_ctrl: 894 ]
Chip: 0, Error -1
1 (mtd1)
error 5 (Input/output error)flash_erase: error!:/dev/mtd1: MTD Erase failure
error 5 (Input/output error)
...
(see log file in attach line 128 and further)
Quoted 3 lines
Environment:
- patches on a 2.6.39.1 kernel (needed to modify the patch a little for changed mtd add/del interface).
Please test the driver on :
git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
or on
git://git.pengutronix.de/git/imx/linux-2.6.git imx-for-3.1
I found the .config may influence the DMA.
I guess there is some module which has impact to the DMA. So You should use the right .config first, you can get the right .config by two ways:
[1] use the 'make mxs_defconfig' in the imx-for-3.1 branch of
tree: git://git.pengutronix.de/git/imx/linux-2.6.git
[2] use the attachment which is tested by me.
Best Regards
Huang Shijie
Quoted 57 lines
- using this on our own mx23 based board, so also added some board init code for that.
Quoted 44 lines · Huang Shijie
Hi Wolfram:
Quoted 43 lines · Huang Shijie
Quoted 42 lines
Hi,
Quoted 17 lines
Quoted 3 lines
The general-purpose media interface(GPMI) controller is a flexible interface
to up to several NAND flashs....
Quoted 5 lines
To Walfram& Artem:
About how to disable the JFFS2 to use the OOB:
I read the code, and I still have no idea about how to use the
ecclayout
to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There isstatic struct nand_ecclayout nandv1_hw_eccoob_smallpage = { .eccbytes = 5, .eccpos = {6, 7, 8, 9, 10}, .oobfree = {{0, 5}, {12, 4}, } }Quoted 4 lines
defined as one layout. Now, you could define one where oobfree is empty and
eccbytes as big as the oob-area.thanks. I will check the code.
Quoted 11 lines
Quoted 11 lines
The driver depends on another GPMI-NAND device patch set, you can find them at :
[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html [3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html [4]http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
Quoted 7 lines
Quoted 3 lines
The driver also depends on another DMA patch by Shawn:
[0]http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
This makes it difficult for testers/reviewers. Please try to get a git-branch
from Freescale or Linaro.Shawn will merge my patches to his Linaro branch.
I don't see the DMA patch in the git?
Quoted 2 lines
Quoted 1 line
git://git.linaro.org/people/shawnguo/linux-2.6.gitmxs-gpmiPlease test the GPMI driver based this git tree.
I will try that on an mx23evk board.
Quoted 2 lines
I tested, and the DMA-timeout does not occur any more.
Quoted 23 lines
Quoted 6 lines
I notice that Shawn added two more patched to /arch/arm/config/mxs_defconfig:
[1] ARM:mxs_defconfig: Add mx23evk and mx28evk build
[2] ARM:mxs_defconfig: ChangeCONFIG_RTC_CLASS'm' to 'y'Please check it. Maybe your kernel code misses them.
I don't see any of this in the git?
Quoted 15 lines
Of course, you can use the
my_config(i sent you last mail) for .config.Best Regards
Huang ShijieQuoted 2 lines
Shijie, please check and test it. I only did a build test.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: my_config
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110727/ac087c9b/attachment-0001.ksh>
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.
Quoted 13 lines
Quoted 13 lines
When trying
flash_erraseall/dev/mtd1I get:
Erasing 128 Kibyte @ 20000 -- ?0 % complete [ ? 16.700000] [gpmi_read_data: 832 ] step 1 error
[ ? 16.700000] [gpmi_send_command: 749 ] step 1 error
[ ? 16.700000] [mil_cmd_ctrl: 894 ] Chip: 0, Error -1
[ ? 16.700000] [gpmi_send_command: 749 ] step 1 error
[ ? 16.700000] [mil_cmd_ctrl: 894 ] Chip: 0, Error -1
[ ? 16.700000] [gpmi_send_command: 749 ] step 1 error
[ ? 16.700000] [mil_cmd_ctrl: 894 ] Chip: 0, Error -1
[ ? 16.700000] [gpmi_read_data: 832 ] step 1 error
libmtd: error!: MEMERA[ ? 16.740000] [gpmi_send_command: 749 ] step 1 error
Quoted 8 lines
Quoted 8 lines
SE64 ioctl failed for eraseblock[ ? 16.750000] [
mil_cmd_ctrl: 894 ]
Chip: 0, Error -1
?1 (mtd1)
? ? ? ? error 5 (Input/output error)flash_erase: error!:/dev/mtd1: MTD Erase failure
? ? ? ? ? ? ?error 5 (Input/output error)
...
(see log file in attach line 128 and further)
Also still same issue here.
Quoted 7 lines
Quoted 4 lines
Environment:
- patches on a 2.6.39.1 kernel (needed to modify the patch a little for changed mtd add/del interface).Please test the driver on :
?git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
I have used this branch.
Quoted 7 lines
or on
?git://git.pengutronix.de/git/imx/linux-2.6.git ?imx-for-3.1
Quoted 8 lines
I found the .config may influence the DMA.
I guess there is some module which has impact to the DMA. So You should use the right .config first, you can get the right .config by two ways:
[1] use the 'makemxs_defconfig' in the imx-for-3.1 branch of ?tree:git://git.pengutronix.de/git/imx/linux-2.6.git[2] use the attachment which is tested by me.
I have used this config file. Only thing changed to the config file is (uboot savenv not working):CONFIG_CMDLINE="console=ttyAMA0,115200 mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs gpmi_debug_init"CONFIG_CMDLINE_FORCE=y
br,
Koen
Quoted 104 lines
Best Regards
Huang ShijieQuoted 96 lines
- using this on our own mx23 based board, so also added some board init code for that.
Quoted 55 lines · On Fri, Jul 22, 2011 at 10:07 AM, Huang Shijie<[email protected]> ?wrote:
Hi Wolfram:
Quoted 53 lines · Huang Shijie
Quoted 51 lines
Hi,
Quoted 21 lines
Quoted 4 lines
The general-purpose media interface(GPMI) controller is a flexible interface
to up to several NAND flashs....
Quoted 6 lines
To Walfram& ? ?Artem:
? ? About how to disable the JFFS2 to use the OOB:
? ? I read the code, and I still have no idea about how to use the ecclayout
? ? to do the job. Could you give me some hint? thanks.Have you checked
mxc_nand.cfor example? There isstatic struct
nand_ecclayoutnandv1_hw_eccoob_smallpage= { ? ? ? ? .eccbytes = 5,
? ? ? ? .eccpos = {6, 7, 8, 9, 10},
? ? ? ? .oobfree = {{0, 5}, {12, 4}, }
}Quoted 5 lines
defined as one layout. Now, you could define one where oobfree is empty
and
eccbytes as big as the oob-area.thanks. I will check the code.
Quoted 13 lines
Quoted 13 lines
The driver depends on another GPMI-NAND device patch set, you can find
them at :
? ? ? ?[1]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
? ? ? ?[2]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
? ? ? ?[3]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
? ? ? ?[4]
http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.htmlQuoted 8 lines
Quoted 3 lines
The driver also depends on another DMA patch by Shawn:
? ? ? ?[0]
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.htmlThis makes it difficult for testers/reviewers. Please try to get a git-branch
from Freescale or Linaro.Shawn will merge my patches to his Linaro branch.
I don't see the DMA patch in the git?
Quoted 3 lines
Quoted 1 line
git://git.linaro.org/people/shawnguo/linux-2.6.gitmxs-gpmiPlease test the GPMI driver based this git tree.
I will try that on an mx23evk board.
Quoted 8 lines
I tested, and the DMA-timeout does not occur any more.
I notice that Shawn added two more patched to /arch/arm/config/mxs_defconfig:
[1] ARM:mxs_defconfig: Add mx23evk and mx28evk build
[2] ARM:mxs_defconfig: ChangeCONFIG_RTC_CLASS'm' to 'y'Please check it. Maybe your kernel code misses them.
I don't see any of this in the git?
Quoted 15 lines
Of course, you can use the
my_config(i sent you last mail) for .config.Best Regards
Huang ShijieQuoted 2 lines
Shijie, please check and test it. ?I only did a build test.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 25 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Lothar Wa?mann
Signature · 9 lines
___________________________________________________________ Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info at karo-electronics.de ___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 28 lines · Lothar Wa?mann
Hi,
Quoted 25 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)
Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)
Regards,
Koen
Quoted 14 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 38 lines · Koen Beel
Hi,
Quoted 28 lines · Lothar Wa?mann
Hi,
Quoted 25 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 6 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
No, I'm working on a TX28.
Lothar Wa?mann
Signature · 9 lines
___________________________________________________________ Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info at karo-electronics.de ___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Koen Beel? 2011?07?29? 15:40, Koen Beel ??:
Quoted 30 lines
Hi,
Quoted 27 lines · Lothar Wa?mann
Hi,
Quoted 24 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Does it conflict with the GPMI?
Quoted 3 lines
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
I tested the code in mx23evk.
After boot the kernel and login the shell, I met a problem:
the flash_eraseall can not run with the log:
"Floating point exception"
:(
Quoted 1 line
- revision number of board (I have tested on rev C1)
Revision number is C.
Quoted 2 lines
- kernel parameter used (see previous mail for mine)
"console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait gpmi_debug_init"
Best Regards
Huang Shijie
Quoted 16 lines
Regards,
KoenQuoted 13 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
Quoted 42 lines · Huang Shijie
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 41 lines
Hi,
Quoted 36 lines · On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<[email protected]> ?wrote:
Hi,
Quoted 32 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 21 lines · On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<[email protected]> ?wrote:
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA
:1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
For now I see the same problem on both the evk (no sd/sdio card) and on my real target hardware (fixed sdio chip).
Quoted 12 lines
Quoted 4 lines
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:I tested the code in mx23evk.
After boot the kernel and login the shell, I met a problem:
?theflash_eraseallcan not run with the log:
"Floating point exception"
:(
Quoted 7 lines
Quoted 1 line
- revision number of board (I have tested on rev C1)
Revision number is C.
Quoted 3 lines
- kernel parameter used (see previous mail for mine)
"console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait
gpmi_debug_init"
You have a rootfs on an SD card? And gpmi is working? No conflicts on dma or something?
Have you hard coded the mtdparts in the init code? I pass something like "mtdparts=gpmi-nand:20m(boot),-(user)" as kernel parameter, but you don't...
Quoted 29 lines
Best Regards
Huang ShijieQuoted 17 lines
Regards,
KoenQuoted 13 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 38 lines · Huang Shijie
Quoted 37 lines
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 36 lines
Hi,
Quoted 32 lines · Lothar Wa?mann
Hi,
Quoted 29 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 20 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is THE prime reason
which caused the DMA timeout.
I am debuging the IMX6Q now, and meet the same problem.
Quoted 13 lines
For now I see the same problem on both the evk (no sd/sdio card) and on my real target hardware (fixed sdio chip).
Quoted 10 lines
Quoted 3 lines
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:I tested the code in mx23evk.
After boot the kernel and login the shell, I met a problem:
theflash_eraseallcan not run with the log:
"Floating point exception"
:(
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
- revision number of board (I have tested on rev C1)
Revision number is C.
Quoted 2 lines
- kernel parameter used (see previous mail for mine)
"console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait
gpmi_debug_init"You have a rootfs on an SD card? And gpmi is working? No conflicts on
I ever put the rootfs in the NAND. But I put the rootfs in the SD card now.
The GPMI is working. No confilct on DMA now. But I do not do much test on the NAND, such as bonnie++. So it need to further test.
Best Regards
Huang Shijie
Quoted 30 lines
dma or something?
Have you hard coded the mtdparts in the init code? I pass something like "mtdparts=gpmi-nand:20m(boot),-(user)" as kernel parameter, but you don't...Quoted 25 lines
Best Regards
Huang ShijieQuoted 15 lines
Regards,
KoenQuoted 12 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Quoted 44 lines · Huang Shijie
Hi,
Quoted 43 lines · Huang Shijie
Quoted 42 lines
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 41 lines
Hi,
Quoted 29 lines · Lothar Wa?mann
Hi,
Quoted 26 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 20 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is THE prime reason
which caused the DMA timeout.I am debuging the IMX6Q now, and meet the same problem.
I do not follow on this. SD on i.mx6q does not use apbh-dma at all. How will it conflict with gpmi regarding to dma timeout?
Signature · 2 lines
Regards, Shawn
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Huang ShijieQuoted 44 lines · Huang Shijie
Hi,
Quoted 43 lines · Huang Shijie
Quoted 42 lines
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 41 lines
Hi,
Quoted 29 lines · Lothar Wa?mann
Hi,
Quoted 26 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 20 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is THE prime reason
which caused the DMA timeout.I am debuging the IMX6Q now, and meet the same problem.
I do not follow on this. SD on i.mx6q does not use apbh-dma at all. How will it conflict with gpmi regarding to dma timeout?
Signature · 2 lines
Regards, Shawn
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Huang ShijieQuoted 44 lines · Huang Shijie
Hi,
Quoted 43 lines · Huang Shijie
Quoted 42 lines
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 41 lines
Hi,
Quoted 29 lines · Lothar Wa?mann
Hi,
Quoted 26 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 20 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is THE prime reason
which caused the DMA timeout.I am debuging the IMX6Q now, and meet the same problem.
I do not follow on this. SD on i.mx6q does not use apbh-dma at all. How will it conflict with gpmi regarding to dma timeout?
Signature · 2 lines
Regards, Shawn
v8 cover add the GPMI controller driver for IMX23/IMX28
? 2011?08?02? 16:12, Shawn Guo ??:
Quoted 48 lines · Huang Shijie
Quoted 47 lines
Hi,
Quoted 46 lines · Huang Shijie
Quoted 37 lines
? 2011?07?29? 15:40, Koen Beel ??:
Quoted 36 lines
Hi,
Quoted 32 lines · Lothar Wa?mann
Hi,
Quoted 29 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 20 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Does it conflict with the GPMI?
Well I don't know if it conflicts. From what Lothar says I assume there might be a conflict between gpmi and sdio.
Quoted 9 lines
Quoted 6 lines
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is THE prime reason
which caused the DMA timeout.I am debuging the IMX6Q now, and meet the same problem.
I do not follow on this. SD on i.mx6q does not use apbh-dma at all. How will it conflict with gpmi regarding to dma timeout?
The SD shares the same lines with GPMI, such NANDF_WE/NANDF_RE, NANDF_ALE, NANDF_CS0.
If the SD card is working, the GPMI will not.
Huang Shijie
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Koen BeelHi,
Quoted 38 lines · Koen Beel
Hi,
Quoted 28 lines · Lothar Wa?mann
Hi,
Quoted 25 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 9 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)
It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.
Perhaps someone can make anything out of that.
Lothar Wa?mann
Signature · 9 lines
___________________________________________________________ Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info at karo-electronics.de ___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
Quoted 50 lines · Lothar Wa?mann
Hi,
Quoted 38 lines · Koen Beel
Hi,
Quoted 28 lines · Lothar Wa?mann
Hi,
Quoted 25 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA :1
[ ? ?3.560000] [start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 9 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)
Quoted 8 lines
It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Perhaps someone can make anything out of that.
I have checked and the function dma_irq_callback is never called during my tests. This means the DMA transfer does not even works once.
Also no clue here ...
Quoted 14 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
Quoted 1 line · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines
Hi,
Quoted 3 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <[email protected]>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <[email protected]>
Quoted 47 lines · wrote:
Quoted 47 lines
Quoted 31 lines
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Hi,
Thanks for your test.
Quoted 19 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,last DMA
:1
[ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)Quoted 6 lines
Quoted 2 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.
Quoted 6 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver looks a bit crappy to me, but let's believe it works ;-)
Quoted 17 lines
Quoted 5 lines
Lothar Wa?mann
--
___________________________________________________________Quoted 7 lines
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init (So I removed the ubi rootfs stuff, see previous mails).
Its booting fine now without complaining about dma timeouts.
Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000" message for every erase block.
Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat /dev/mtd1 its stopping with a dma timeout. Every subsequent action (e.g. using ubiformat or flash_eraseall) using that dma channel is failing.
I have put a printk in mxs-dma.c around line 387:
if (mxs_chan->status == DMA_IN_PROGRESS && !append)
{
pr_err("dma already in progess!\n");
return NULL;
}I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at DMA_IN_PROGRESS
Any input or feedback is welcome.
Regards,
Koen
Quoted 68 lines · Marek Vasut
Quoted 1 line · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines
Hi,
Quoted 3 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <[email protected]>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <[email protected]>
Quoted 49 lines · wrote:
Quoted 48 lines
Quoted 31 lines
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Hi,
Thanks for your test.
Quoted 19 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA:1
[ ? ?3.560000] [
start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 6 lines
Quoted 2 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Perhaps someone can make anything out of that.
Quoted 26 lines
Quoted 4 lines
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver looks a bit crappy to me, but let's believe it works ;-)
Quoted 17 lines
Quoted 5 lines
Lothar Wa?mann
--
___________________________________________________________Quoted 7 lines
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log1
Type: application/octet-stream
Size: 2644 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110801/32011204/attachment-0001.obj>
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 4 lines
Hi,
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel does not
fix it.
Anyway, I will do more test on the mx23 board myself.
Quoted 5 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
Quoted 4 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
This is a very dangerous interface.
Quoted 4 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.
echo 0x20 > /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
to show the GPMI register when the DMA timeout occurs.
Best Regards
Huang Shijie
Quoted 106 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:if (mxs_chan->status == DMA_IN_PROGRESS&& !append) { pr_err("dma already in progess!\n"); return NULL; }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 85 lines · Marek Vasut
Quoted 1 line · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines
Hi,
Quoted 3 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<[email protected]>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<[email protected]>
Quoted 43 lines · wrote:
Quoted 43 lines
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,last DMA
:1
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
[ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 5 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver looks a bit crappy to me, but let's believe it works ;-)
Quoted 15 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 11 lines · Huang Shijie
Hi,
Quoted 5 lines
Hi,
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel does not
fix it.
Anyway, I will do more test on the mx23 board myself.
Strange indeed. I suspect that the BSP used another way to mark bad blocks.
Quoted 10 lines
Quoted 8 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
That's mainly because the ubi stuff is not done at startup.
Quoted 7 lines
Quoted 5 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes toThis is a very dangerous interface.
I know but it solved an issue here. Now flash_eraseall seems to be working again without that ignorebad turned on (only finds one bad erase blcok).
Again: I suspect that the BSP used another way to mark bad blocks.
Quoted 9 lines
Quoted 5 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.echo
0x20>/sys/devices/platform/imx23-gpmi-nand/gpmi_debugto show the GPMI register when the DMA timeout occurs.
Don't have this sysfs interface here. I also don't see where it is registered in the driver code.
Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
log file attached.
Regards,
Koen
Quoted 134 lines
Best Regards
Huang ShijieQuoted 127 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:? ? if (
mxs_chan->status== DMA_IN_PROGRESS&& ?!append) ? ? {
? ? ? ?pr_err("dma already in progess!\n");
? ? ? ? return NULL;
? ? }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 104 lines · On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<[email protected]> ?wrote:
Quoted 2 lines · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<[email protected]>
Quoted 9 lines · wrote:
Quoted 9 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar
Wa?mann<[email protected]>Quoted 10 lines · wrote:
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Hi,
Quoted 6 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<[email protected]>
Quoted 48 lines · wrote:
Quoted 48 lines
Quoted 32 lines
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Hi,
Thanks for your test.
Quoted 19 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA:1
[ ? ?3.560000] [
start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 6 lines
Quoted 2 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 6 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver
looks a bit crappy to me, but let's believe it works ;-)Quoted 16 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log2
Type: application/octet-stream
Size: 2896 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110802/c00871d9/attachment.obj>
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 24 lines
Hi,
Quoted 9 lines · Huang Shijie
Hi,
Quoted 4 lines
Hi,
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel does not
fix it.
Anyway, I will do more test on the mx23 board myself.Strange indeed. I suspect that the BSP used another way to mark bad blocks.
Quoted 8 lines
Quoted 7 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
That's mainly because the ubi stuff is not done at startup.
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes toThis is a very dangerous interface.
I know but it solved an issue here. Now
flash_eraseallseems to be working again without that ignorebad turned on (only finds one bad erase blcok).
Could you mail me your flash_eraseall?
Mine does not work.
so I can test your flash_eraseall first.
Best Regards
Huang Shijie
Quoted 132 lines
Again: I suspect that the BSP used another way to mark bad blocks.
Quoted 7 lines
Quoted 4 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.echo
0x20>/sys/devices/platform/imx23-gpmi-nand/gpmi_debugto show the GPMI register when the DMA timeout occurs.
Don't have this sysfs interface here. I also don't see where it is registered in the driver code.
Anyway I have hardcodedGPMI_DEBUG_CRAZYingpmi_debug_setup.log file attached.
Regards,
KoenQuoted 114 lines
Best Regards
Huang ShijieQuoted 109 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:if (mxs_chan->status == DMA_IN_PROGRESS&& !append) { pr_err("dma already in progess!\n"); return NULL; }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 87 lines · Marek Vasut
Quoted 1 line · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<[email protected]>
Quoted 7 lines · wrote:
Quoted 7 lines
Hi,
Quoted 4 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar
Wa?mann<[email protected]>Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<[email protected]>
Quoted 43 lines · wrote:
Quoted 43 lines
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,last DMA
:1
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
[ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 5 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver
looks a bit crappy to me, but let's believe it works ;-)Quoted 15 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 39 lines · Huang Shijie
Hi,
Quoted 38 lines
Hi,
Quoted 5 lines · On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<[email protected]> ?wrote:
Hi,
Quoted 3 lines
Hi,
Quoted 8 lines
Quoted 2 lines
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel
does not
fix it.
Anyway, I will do more test on the mx23 board myself.Strange indeed. I suspect that the BSP used another way to mark bad blocks.
Quoted 9 lines
Quoted 7 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
That's mainly because the ubi stuff is not done at startup.
Quoted 5 lines
Quoted 4 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
This is a very dangerous interface.
I know but it solved an issue here. Now
flash_eraseallseems to be working again without that ignorebad turned on (only finds one bad erase blcok).Could you mail me your
flash_eraseall?
Mine ?does not work.
You want my flash_eraseall binary?
I build all userspace, kernel, bootloader and toolchain using buildroot ( http://buildroot.uclibc.org/download.html ), which also includes all flash tools like flash_eraseall and ubiformat. In the buildroot menuconfig check the packages under 'Package Selection for the target > Hardware handling > mtd/jffs2 utilities' Buildroot will build everything needed to get a working system, including toolchain, uclibc, ... I really recommend that.
Right now I use a kernel with the full rootfs as initramfs (standard option in buildroot). I just load the uImage (contains kernel and initramfs) using tftp in uboot. This way I'm not dependent on mmc/nfs/nand (no eth or mmc on my actual target and nand/ubi not yet working). Only downside is that I use some memory for it and I don't have any persistent storage on the rootfs right now.
I have adapted buildroot a little to build the kernel out of tree.
Anyway, if you want my flash_eraseall binary, see attachment.
Regards,
Koen
Quoted 166 lines
so I can test your
flash_eraseallfirst.Best Regards
Huang ShijieQuoted 158 lines
Again: I suspect that the BSP used another way to mark bad blocks.
Quoted 8 lines
Quoted 4 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.echo
0x20> ?/sys/devices/platform/imx23-gpmi-nand/gpmi_debugto show the GPMI register when the DMA timeout occurs.
Don't have this sysfs interface here. I also don't see where it is registered in the driver code.
Anyway I have hardcodedGPMI_DEBUG_CRAZYingpmi_debug_setup.log file attached.
Regards,
KoenQuoted 137 lines
Best Regards
Huang ShijieQuoted 132 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:? ? if (
mxs_chan->status== DMA_IN_PROGRESS&& ? ?!append) ? ? {
? ? ? ?pr_err("dma already in progess!\n");
? ? ? ? return NULL;
? ? }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 109 lines · On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<[email protected]> ?wrote:
Quoted 3 lines · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar
Wa?mann<[email protected]>Quoted 9 lines · wrote:
Quoted 9 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar
Wa?mann<[email protected]>Quoted 11 lines · wrote:
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Hi,
Quoted 7 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang
Shijie<[email protected]>Quoted 50 lines · wrote:
Quoted 50 lines
Quoted 34 lines
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Hi,
Thanks for your test.
Quoted 19 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA:1
[ ? ?3.560000] [
start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 8 lines
Quoted 2 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when
accessing an SD card. Without SD card I can use the flash without any
errors.Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 6 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the
driver
looks a bit crappy to me, but let's believe it works ;-)Quoted 16 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_eraseall
Type: application/octet-stream
Size: 149 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110802/83a12a4e/attachment.obj>
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Koen BeelHi Koen:
I tested the driver in mx23evk board, and I do not find the DMA-timeout error.
The following is my test environment:
[0] Hardware:
MX23EVK PCB REV C
[1] SW:
kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi .config: my_config , you can find it in my previous email.
cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwaitgpmi_debug_init mtdparts=gpmi-nand:20m(boot),-(user)
[2] test shell script:
================================
echo 0x20 > /sys/module/gpmi_nand/parameters/gpmi_debug flash_eraseall /dev/mtd1
ubiformat /dev/mtd1flash_eraseall /dev/mtd1
ubiattach /dev/ubi_ctrl -m 1
ubimkvol /dev/ubi0 -N test -m
mount -t ubifs ubi0:test tmp
bonnie++ -d tmp -u 0 -s 2 -r 1
bonnie++ -d tmp -u 0 -s 2 -r 1
bonnie++ -d tmp -u 0 -s 2 -r 1
umount tmp
ubidetach /dev/ubi_ctrl -m 1
================================
[3] conclusion
It runs well in my mx23 board, and no DMA-TIMEOUT occur.
I think there is some conflict in your board.
BTW:
I split the MTD to 20M and (the rest size).
The flash_eraseall works well.
If i do not split the MTD, the flash_eraseall will not work. I guest overflow occurs in some place.
Best Regards
Huang Shijie
Quoted 162 lines · Huang Shijie
Quoted 9 lines
Hi,
Quoted 4 lines
Hi,
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel does not
fix it.
Anyway, I will do more test on the mx23 board myself.Strange indeed. I suspect that the BSP used another way to mark bad blocks.
Quoted 8 lines
Quoted 7 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
That's mainly because the ubi stuff is not done at startup.
Quoted 5 lines
Quoted 4 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes toThis is a very dangerous interface.
I know but it solved an issue here. Now
flash_eraseallseems to be working again without that ignorebad turned on (only finds one bad erase blcok).
Again: I suspect that the BSP used another way to mark bad blocks.Quoted 7 lines
Quoted 4 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.echo
0x20>/sys/devices/platform/imx23-gpmi-nand/gpmi_debugto show the GPMI register when the DMA timeout occurs.
Don't have this sysfs interface here. I also don't see where it is registered in the driver code.
Anyway I have hardcodedGPMI_DEBUG_CRAZYingpmi_debug_setup.log file attached.
Regards,
KoenQuoted 114 lines
Best Regards
Huang ShijieQuoted 109 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:if (mxs_chan->status == DMA_IN_PROGRESS&& !append) { pr_err("dma already in progess!\n"); return NULL; }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 87 lines · Marek Vasut
Quoted 1 line · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<[email protected]>
Quoted 7 lines · wrote:
Quoted 7 lines
Hi,
Quoted 4 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar
Wa?mann<[email protected]>Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<[email protected]>
Quoted 43 lines · wrote:
Quoted 43 lines
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Hi,
Thanks for your test.
Quoted 16 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,last DMA
:1
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
[ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 5 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the driver
looks a bit crappy to me, but let's believe it works ;-)Quoted 15 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 4 lines · Huang Shijie
Hi Koen:
I tested the driver in mx23evk board, and I do not find the DMA-timeout error.
Strange.
Quoted 4 lines
The following is my test environment:
[0] Hardware:
? ? ? MX23EVK PCB REV C
I have the same hardware. But also on our own hardware (mx23, but different dram and different nand) it's failing with the same output as on the evk (see log file in previous mail).
Quoted 5 lines
[1] SW:
? ?kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi ? ?.config:my_config, you can find it in my previous email. ? ?cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwaitgpmi_debug_initmtdparts=gpmi-nand:20m(boot),-(user)
I use that git and your config file. Only thing i have changed to the config is to integrate the initramfs rootfs.
Would it be possible for you to test using rootfs in initramfs? Now you are using the mmc card as rootfs which is on the dma engine and bus.
Quoted 5 lines
[2] test shell script:
================================echo
0x20>/sys/module/gpmi_nand/parameters/gpmi_debug
As said, don't have that gpmi_debug sysfs entry. Sure you don't have any other modification done which are not in that git branch?
Quoted 12 lines
flash_eraseall/dev/mtd1ubiformat/dev/mtd1flash_eraseall/dev/mtd1ubiattach/dev/ubi_ctrl-m 1 ubimkvol/dev/ubi0-N test -m mount -t ubifs ubi0:test tmp bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 umount tmp
ubidetach/dev/ubi_ctrl-m 1
Quoted 5 lines
================================
[3] conclusion
? It runs well in my mx23 board, and no DMA-TIMEOUT occur. I think there is some conflict in your board.
Don't know what conflict I would have with my board. I just use the board without anything (mmc, lcd, ...) attached to it.
Quoted 3 lines
BTW:
? I split the MTD to 20M and (the rest size).
So do I.
Quoted 2 lines
The
flash_eraseallworks well.
If i do not split the MTD, theflash_eraseallwill not work.
That's strange because I use flash_eraseall on my mtd1 which is 108 MB. I don't know how you boot but my uboot is in mtd0, so don't use that part to test
Quoted 211 lines
I guest overflow occurs in some place.
Best Regards
Huang ShijieQuoted 51 lines · On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<[email protected]> ?wrote:
Quoted 5 lines
Hi,
Quoted 3 lines
Hi,
Quoted 8 lines
Quoted 2 lines
Don't think it's a hardware issue. After all it is working on the mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community kernel
does not
fix it.
Anyway, I will do more test on the mx23 board myself.Strange indeed. I suspect that the BSP used another way to mark bad blocks.
Quoted 9 lines
Quoted 7 lines
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user)gpmi_debug_init(So I removed the ubi rootfs stuff, see previous mails).Its booting fine now without complaining about dma timeouts.
ok.
That's mainly because the ubi stuff is not done at startup.
Quoted 6 lines
Quoted 4 lines
Have tried
flash_eraseall/dev/mtd1. Now it's complaining and thinking all blocks are bad. So a "flash_erase: Skipping bad block at1db00000" message for every erase block.
Writing 1 to/sys/devices/platform/imx23-gpmi-nand/ignorebad, makes toThis is a very dangerous interface.
I know but it solved an issue here. Now
flash_eraseallseems to be working again without that ignorebad turned on (only finds one bad erase blcok).
Again: I suspect that the BSP used another way to mark bad blocks.Quoted 8 lines
Quoted 4 lines
go a little further giving 'only one' error but I doubt it's working at all. See attached log file.
When the trying ubiformat
/dev/mtd1its stopping with a dma timeout.echo
0x20> ?/sys/devices/platform/imx23-gpmi-nand/gpmi_debugto show the GPMI register when the DMA timeout occurs.
Quoted 146 lines
Don't have this sysfs interface here. I also don't see where it is registered in the driver code.
Anyway I have hardcodedGPMI_DEBUG_CRAZYingpmi_debug_setup.log file attached.
Regards,
KoenQuoted 137 lines
Best Regards
Huang ShijieQuoted 132 lines
Every subsequent action (e.g. using ubiformat or
flash_eraseall) using that dma channel is failing.
I have put a printk inmxs-dma.caround line 387:? ? if (
mxs_chan->status== DMA_IN_PROGRESS&& ? ?!append) ? ? {
? ? ? ?pr_err("dma already in progess!\n");
? ? ? ? return NULL;
? ? }I see that printk also in the log file in attach. Seems like the mxs-dma is failing at some point and for the rest of the time always keeps it's status at
DMA_IN_PROGRESSAny input or feedback is welcome.
Regards,
KoenQuoted 109 lines · On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<[email protected]> ?wrote:
Quoted 3 lines · Koen Beel
On Fri, Jul 29, 2011 at 2:41 PM, Lothar
Wa?mann<[email protected]>Quoted 9 lines · wrote:
Quoted 9 lines
Hi,
Quoted 5 lines · Koen Beel
Hi,
On Fri, Jul 29, 2011 at 9:20 AM, Lothar
Wa?mann<[email protected]>Quoted 11 lines · wrote:
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Hi,
Quoted 7 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
On Wed, Jul 27, 2011 at 3:53 AM, Huang
Shijie<[email protected]>Quoted 50 lines · wrote:
Quoted 50 lines
Quoted 34 lines
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Hi,
Thanks for your test.
Quoted 19 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ ? ?2.560000] [start_dma_without_bch_irq: 392 ] DMA timeout, last DMA:1
[ ? ?3.560000] [
start_dma_with_bch_irq: 427 ] bch timeout!!!
...
(see log file in attach line 89)Quoted 8 lines
Quoted 2 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when
accessing an SD card. Without SD card I can use the flash without any
errors.Quoted 8 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.Quoted 6 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.Also no clue here ...
Aren't you getting some undervolt on the powerrail for example ? btw the
driver
looks a bit crappy to me, but let's believe it works ;-)Quoted 16 lines
Quoted 11 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
__________________________________________________________________________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel_______________________________________________
linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
hi:
Quoted 7 lines
Quoted 4 lines
The following is my test environment:
[0] Hardware:
MX23EVK PCB REV CI have the same hardware. But also on our own hardware (mx23, but different dram and different nand) it's failing with the same output as on the evk (see log file in previous mail).
I will check the schematic of mx23 tomorrow, and find what will cause conflict with GPMI.
Quoted 8 lines
Quoted 5 lines
[1] SW:
kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi .config:my_config, you can find it in my previous email.
cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwaitgpmi_debug_initmtdparts=gpmi-nand:20m(boot),-(user)I use that git and your config file. Only thing i have changed to the config is to integrate the initramfs rootfs.
Would it be possible for you to test using rootfs in initramfs? Now
could you tell me how can i test the rootfs in initramfs? I have no idea about how to test it.
Quoted 10 lines
you are using the mmc card as rootfs which is on the dma engine and bus.
Quoted 4 lines
[2] test shell script:
================================echo
0x20>/sys/module/gpmi_nand/parameters/gpmi_debugAs said, don't have that
gpmi_debugsysfs entry. Sure you don't have any other modification done which are not in that git branch?
The sysfs entry does exit.
Please check carefully.
The code in gpmi-nand.c defines it.
Quoted 20 lines
Quoted 12 lines
flash_eraseall/dev/mtd1ubiformat/dev/mtd1flash_eraseall/dev/mtd1ubiattach/dev/ubi_ctrl-m 1 ubimkvol/dev/ubi0-N test -m mount -t ubifs ubi0:test tmp bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 umount tmp
ubidetach/dev/ubi_ctrl-m 1Quoted 5 lines
================================
[3] conclusion
It runs well in my mx23 board, and no DMA-TIMEOUT occur.
I think there is some conflict in your board.Don't know what conflict I would have with my board. I just use the board without anything (mmc, lcd, ...) attached to it.
Quoted 8 lines
Quoted 2 lines
BTW:
I split the MTD to 20M and (the rest size).So do I.
Quoted 2 lines
The
flash_eraseallworks well.
If i do not split the MTD, theflash_eraseallwill not work.That's strange because I use
flash_eraseallon my mtd1 which is 108 MB. I don't know how you boot but my uboot is in mtd0, so don't use that
I boot the kernel by the USB with sb_loader.
Best Regards
Huang Shijie
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 19 lines · Huang Shijie
hi:
Quoted 8 lines
Quoted 4 lines
The following is my test environment:
[0] Hardware:
? ? ? MX23EVK PCB REV CI have the same hardware. But also on our own hardware (mx23, but different dram and different nand) it's failing with the same output as on the evk (see log file in previous mail).
I will check the schematic of mx23 tomorrow, and find what will cause conflict with GPMI.
Quoted 7 lines
Quoted 6 lines
[1] SW:
? ?kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi ? ?.config:my_config, you can find it in my previous email. ? ?cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwaitgpmi_debug_initmtdparts=gpmi-nand:20m(boot),-(user)
Quoted 6 lines
Quoted 3 lines
I use that git and your config file. Only thing i have changed to the config is to integrate the initramfs rootfs.
Would it be possible for you to test using rootfs in initramfs? Nowcould you tell me how can i test the rootfs in initramfs? I have no idea about how to test it.
Via the linux menuconfig:
- Check the option "General setup > Initial RAM filesystem and RAM disk (initramfs/initrd) support"
- Fill in "General setup > Initramfs source file(s)" (e.g. the path to a cpio archive of the rootfs, or just the directory containing the extracted rootfs).
Quoted 9 lines
Quoted 9 lines
you are using the mmc card as rootfs which is on the dma engine and bus.
Quoted 3 lines
[2] test shell script:
================================
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
echo
0x20> ?/sys/module/gpmi_nand/parameters/gpmi_debugAs said, don't have that
gpmi_debugsysfs entry. Sure you don't have any other modification done which are not in that git branch?The sysfs entry does exit.
Please check carefully.
The code ingpmi-nand.cdefines it.
Ok, I see the module_param entry at the beginning of gpmi-nand.c. Must have overlooked it as in previous mail you mentioned the path was /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
But no problem, it's working now.
Quoted 45 lines
Quoted 26 lines
Quoted 14 lines
flash_eraseall/dev/mtd1ubiformat/dev/mtd1flash_eraseall/dev/mtd1ubiattach/dev/ubi_ctrl-m 1 ubimkvol/dev/ubi0-N test -m mount -t ubifs ubi0:test tmp bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 bonnie++ -d tmp -u 0 -s 2 -r 1 umount tmp
ubidetach/dev/ubi_ctrl-m 1Quoted 5 lines
================================
[3] conclusion
? It runs well in my mx23 board, and no DMA-TIMEOUT occur. I think there is some conflict in your board.Don't know what conflict I would have with my board. I just use the board without anything (mmc, lcd, ...) attached to it.
Quoted 2 lines
BTW:
? I split the MTD to 20M and (the rest size).Quoted 7 lines
So do I.
Quoted 2 lines
The
flash_eraseallworks well.
If i do not split the MTD, theflash_eraseallwill not work.That's strange because I use
flash_eraseallon my mtd1 which is 108 MB. I don't know how you boot but my uboot is in mtd0, so don't use thatI boot the kernel by the USB with
sb_loader.Best Regards
Huang Shijie_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Koen Beel? 2011?07?29? 23:00, Koen Beel ??:
Quoted 56 lines · Lothar Wa?mann
Quoted 55 lines
Hi,
Quoted 36 lines · Koen Beel
Hi,
Quoted 27 lines · Lothar Wa?mann
Hi,
Quoted 24 lines · Koen Beel
Hi,
I have test on mx23evk board. Still see the same issues.
Quoted 19 lines · Huang Shijie
Hi,
Thanks for your test.
Quoted 15 lines
Hi,
It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifsgpmi_debug_initDuring boot I get already get DMA timeout:
[ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1 [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!...
(see log file in attach line 89)Quoted 6 lines
Quoted 3 lines
I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
Quoted 9 lines
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Are you also testing on the mx23evk board? Really strange it is not reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)It's getting ever more strange. I only have problems with concurrent access to the flash and SD-card when I do file system based accessed to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash works well, while mounting the SD card and doing an 'ls' produces immediate BCH DMA timeouts.
Quoted 3 lines
Quoted 1 line
Perhaps someone can make anything out of that.
I have checked and the function
dma_irq_callbackis never called during my tests. This means the DMA transfer does not even works once.
If the GPMI do not work well, it will not toggle the DMA to work, so the DMA may timeout.
Huang Shijie
Quoted 15 lines
Also no clue here ...
Quoted 13 lines
Lothar Wa?mann
--
___________________________________________________________Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
v8 cover add the GPMI controller driver for IMX23/IMX28
In reply to Koen BeelQuoted 6 lines
Quoted 3 lines
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Removing the SD didn't help here as well. Koen, which bootloader do you use?
Signature · 9 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110803/2c19e95c/attachment.sig>
v8 cover add the GPMI controller driver for IMX23/IMX28
Hi,
Quoted 9 lines · Wolfram Sang
Quoted 6 lines
Quoted 3 lines
Do you have an SD card in the system? I'm getting the same error when accessing an SD card. Without SD card I can use the flash without any errors.
No SD card in the system. At least not on my mx23evk board. My real target hardware has a SDIO wifi chip.
Removing the SD didn't help here as well. Koen, which bootloader do you use?
i'm using uboot in nand flash.
(build an sb file containing power_prep, boot_prep and uboot en flashed to nand using kobs-ng tool)
In my setup uboot loads a uImage from tftp. This uImage contains the full rootfs as initramfs. So no need for mmc, nfs or nand.
If someone would like to try using my uImage for mx23evk, you can download it here:
https://www.transferbigfiles.com/025d4f2a-38da-266a-66d1-1d7a05b1b938?rid=J3Qh9b7Vb1ORXFtzU589fw%3d%3d
Regards,
Koen
Quoted 14 lines
--
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Wolfram Sang ? ? ? ? ? ? ? ?| Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)iEYEARECAAYFAk45JNYACgkQD27XaX1/VRt1hACdFt1CQltiTWSwcoaNXsmJqkS0 ycQAn3oPqxZYK/wmtd5S9Gh5dj+5YM73
=jJs2
-----END PGP SIGNATURE-----