From dedekind at infradead.org  Fri Feb  1 02:22:26 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Fri, 01 Feb 2008 09:22:26 +0200
Subject: [PATCH][MTD-UTILS] ubi-tools: fix ubinize
In-Reply-To: <47A1E795.5010407@nokia.com>
References: <47A1E795.5010407@nokia.com>
Message-ID: <1201850546.23305.9.camel@sauron>

On Thu, 2008-01-31 at 17:21 +0200, Adrian Hunter wrote:
> ubinize reserves 2 eraseblocks for the volume table at the start of the
> output file and then never seeked back to the start of the file.
> 
> Signed-off-by: Adrian Hunter <ext-adrian.hunter at nokia.com>

Pushed, thank you!

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From spodstavin at ru.mvista.com  Fri Feb  1 07:19:17 2008
From: spodstavin at ru.mvista.com (Sergey Podstavin)
Date: Fri, 01 Feb 2008 15:19:17 +0300
Subject: [PATCH] final version of PXA3xx nand controller support
Message-ID: <1201868357.3266.117.camel@localhost.localdomain>

It's the final version of PXA3xx nand controller support patch.

Best wishes,
Sergey Podstavin.



>From 0d68fa368e08059bea1a44b75152c24ef5ec6805 Mon Sep 17 00:00:00 2001
From: Sergey Podstavin <spodstavin at localhost.localdomain>
Date: Fri, 1 Feb 2008 15:10:05 +0300
Signed-off-by: Eric Miao <eric.y.miao at gmail.com>
Signed-off-by: Sergey Podstavin <spodstavin at ru.mvista.com>
Subject: [PATCH] PXA3xx nand controller support

---
 arch/arm/mach-pxa/pxa3xx.c             |    1 +
 arch/arm/mach-pxa/zylonite.c           |   64 ++-
 drivers/mtd/nand/Kconfig               |    6 +
 drivers/mtd/nand/Makefile              |    1 +
 drivers/mtd/nand/pxa3xx_nand.c         | 1214
++++++++++++++++++++++++++++++++
 include/asm-arm/arch-pxa/pxa3xx_nand.h |  196 +++++
 6 files changed, 1481 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mtd/nand/pxa3xx_nand.c
 create mode 100644 include/asm-arm/arch-pxa/pxa3xx_nand.h

diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 0b2a15e..013b414 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -184,6 +184,7 @@ static struct clk pxa3xx_clks[] = {
 	PXA3xx_CK("LCDCLK", LCD,    &clk_pxa3xx_hsio_ops, &pxa_device_fb.dev),
 	PXA3xx_CK("CAMCLK", CAMERA, &clk_pxa3xx_hsio_ops, NULL),
 
+	PXA3xx_CK("NANDCLK", NAND, &clk_pxa3xx_hsio_ops, NULL),
 	PXA3xx_CKEN("UARTCLK", FFUART, 14857000, 1, &pxa_device_ffuart.dev),
 	PXA3xx_CKEN("UARTCLK", BTUART, 14857000, 1, &pxa_device_btuart.dev),
 	PXA3xx_CKEN("UARTCLK", STUART, 14857000, 1, NULL),
diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
index 7731d50..2b09c9d 100644
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -18,6 +18,8 @@
 #include <linux/interrupt.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -26,7 +28,7 @@
 #include <asm/arch/pxafb.h>
 #include <asm/arch/zylonite.h>
 #include <asm/arch/mmc.h>
-
+#include <asm/arch/pxa3xx_nand.h>
 #include "generic.h"
 
 #define MAX_SLOTS	3
@@ -249,6 +251,65 @@ static void __init zylonite_init_mmc(void)
 static inline void zylonite_init_mmc(void) {}
 #endif
 
+struct mtd_partition pxa3xx_mtd_partition_info[] = {
+	[0] = {
+		.name		= "Bootloader",
+		.offset		= 0,
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	},
+	[1] = {
+		.name		= "Kernel",
+		.size		= 0x00200000,
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	},
+	[2] = {
+		.name		= "Filesystem",
+		.size		= 0x03000000, /* only mount 48M fs */
+	},
+	[3] = {
+		.name		= "MassStorage",
+		.size		= 0x0, /* It will be set at probe function */
+		.offset		= MTDPART_OFS_APPEND, /* Append after fs */
+	},
+	[4] = {
+		.name		= "BBT",
+		.size		= 0x0, /* It will be set at probe function */
+		.offset		= MTDPART_OFS_APPEND, /* Append after fs */
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	}
+};
+
+#define		PXA3XX_MTD_PART_NUM	ARRAY_SIZE(pxa3xx_mtd_partition_info)
+
+static struct resource nand_resources[] = {
+	[0] = {
+		.start	= 0x43100000,
+		.end	= 0x431000ff,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= -1,	/* for run-time assignment */
+		.end	= -1,
+		.flags	= IORESOURCE_IRQ,
+	}
+};
+
+struct pxa3xx_nand_platform_data pxa3xx_nand_data = {
+	.parts		= pxa3xx_mtd_partition_info,
+	.nr_parts	= PXA3XX_MTD_PART_NUM,
+};
+
+static struct platform_device nand_device = {
+	.name		= "pxa3xx-nand",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(nand_resources),
+	.resource	= nand_resources,
+	.dev		= {
+		.platform_data = &pxa3xx_nand_data,
+		.coherent_dma_mask = 0xffffffffUL,
+	}
+};
+
 static void __init zylonite_init(void)
 {
 	/* board-processor specific initialization */
@@ -265,6 +326,7 @@ static void __init zylonite_init(void)
 
 	zylonite_init_lcd();
 	zylonite_init_mmc();
+	platform_device_register(&nand_device);
 }
 
 MACHINE_START(ZYLONITE, "PXA3xx Platform Development Kit (aka
Zylonite)")
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..2be073f 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -84,6 +84,12 @@ config MTD_NAND_TS7250
 config MTD_NAND_IDS
 	tristate
 
+config MTD_NAND_PXA3xx
+	tristate "NAND flash support for PXA3xx"
+	depends on MTD_NAND && PXA3xx
+	help
+	  This enables the driver for the NAND flash device on Zylonite board
+
 config MTD_NAND_AU1550
 	tristate "Au1550/1200 NAND support"
 	depends on SOC_AU1200 || SOC_AU1550
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 3ad6c01..ecb7968 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MTD_NAND_BF5XX)		+= bf5xx_nand.o
 obj-$(CONFIG_MTD_NAND_PPCHAMELEONEVB)	+= ppchameleonevb.o
 obj-$(CONFIG_MTD_NAND_S3C2410)		+= s3c2410.o
 obj-$(CONFIG_MTD_NAND_DISKONCHIP)	+= diskonchip.o
+obj-$(CONFIG_MTD_NAND_PXA3xx)		+= pxa3xx_nand.o
 obj-$(CONFIG_MTD_NAND_H1900)		+= h1910.o
 obj-$(CONFIG_MTD_NAND_RTC_FROM4)	+= rtc_from4.o
 obj-$(CONFIG_MTD_NAND_SHARPSL)		+= sharpsl.o
diff --git a/drivers/mtd/nand/pxa3xx_nand.c
b/drivers/mtd/nand/pxa3xx_nand.c
new file mode 100644
index 0000000..4ddec37
--- /dev/null
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -0,0 +1,1214 @@
+/*
+ * drivers/mtd/nand/pxa3xx_nand.c
+ *
+ * Copyright (C) 2005 Intel Corporation
+ * Copyright (C) 2006 Marvell International Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/dma.h>
+
+#include <asm/arch/pxa-regs.h>
+#include <asm/arch/pxa3xx_nand.h>
+
+static int use_dma = 1;
+module_param(use_dma, bool, 0444);
+MODULE_PARM_DESC(use_dma, "enable DMA for data transfering to/from NAND
HW");
+
+static struct pxa3xx_nand_cmdset smallpage_cmdset = {
+	.read1		= 0x0000,
+	.read2		= 0x0050,
+	.program	= 0x1080,
+	.read_status	= 0x0070,
+	.read_id	= 0x0090,
+	.erase		= 0xD060,
+	.reset		= 0x00FF,
+	.lock		= 0x002A,
+	.unlock		= 0x2423,
+	.lock_status	= 0x007A,
+};
+
+static struct pxa3xx_nand_cmdset largepage_cmdset = {
+	.read1		= 0x3000,
+	.read2		= 0x0050,
+	.program	= 0x1080,
+	.read_status	= 0x0070,
+	.read_id	= 0x0090,
+	.erase		= 0xD060,
+	.reset		= 0x00FF,
+	.lock		= 0x002A,
+	.unlock		= 0x2423,
+	.lock_status	= 0x007A,
+};
+
+static struct pxa3xx_nand_timing samsung512MbX16_timing = {
+	.tCH	= 10,
+	.tCS	= 0,
+	.tWH	= 20,
+	.tWP	= 40,
+	.tRH	= 30,
+	.tRP	= 40,
+	.tR	= 11123,
+	.tWHR	= 110,
+	.tAR	= 10,
+};
+
+static struct pxa3xx_nand_flash samsung512MbX16 = {
+	.timing		= &samsung512MbX16_timing,
+	.cmdset		= &smallpage_cmdset,
+	.page_per_block	= 32,
+	.page_size	= 512,
+	.flash_width	= 16,
+	.dfc_width	= 16,
+	.num_blocks	= 4096,
+	.chip_id	= 0x46ec,
+};
+
+static struct pxa3xx_nand_timing micron_timing = {
+	.tCH	= 10,
+	.tCS	= 25,
+	.tWH	= 15,
+	.tWP	= 25,
+	.tRH	= 15,
+	.tRP	= 25,
+	.tR	= 25000,
+	.tWHR	= 60,
+	.tAR	= 10,
+};
+
+static struct pxa3xx_nand_flash micron1GbX8 = {
+	.timing		= &micron_timing,
+	.cmdset		= &largepage_cmdset,
+	.page_per_block	= 64,
+	.page_size	= 2048,
+	.flash_width	= 8,
+	.dfc_width	= 8,
+	.num_blocks	= 1024,
+	.chip_id	= 0xa12c,
+};
+
+static struct pxa3xx_nand_flash micron1GbX16 = {
+	.timing		= &micron_timing,
+	.cmdset		= &largepage_cmdset,
+	.page_per_block	= 64,
+	.page_size	= 2048,
+	.flash_width	= 16,
+	.dfc_width	= 16,
+	.num_blocks	= 1024,
+	.chip_id	= 0xb12c,
+};
+
+static struct pxa3xx_nand_flash *builtin_flash_types[] = {
+	&samsung512MbX16,
+	&micron1GbX8,
+	&micron1GbX16,
+};
+
+#define NDTR0_tCH(c)	(min((c), 7) << 19)
+#define NDTR0_tCS(c)	(min((c), 7) << 16)
+#define NDTR0_tWH(c)	(min((c), 7) << 11)
+#define NDTR0_tWP(c)	(min((c), 7) << 8)
+#define NDTR0_tRH(c)	(min((c), 7) << 3)
+#define NDTR0_tRP(c)	(min((c), 7) << 0)
+
+#define NDTR1_tR(c)	(min((c), 65535) << 16)
+#define NDTR1_tWHR(c)	(min((c), 15) << 4)
+#define NDTR1_tAR(c)	(min((c), 15) << 0)
+
+/* convert nano-seconds to nand flash controller clock cycles */
+#define ns2cycle(ns, clk)	(int)(((ns) * (clk / 1000000) / 1000) + 1)
+
+static void pxa3xx_nand_set_timing(struct pxa3xx_nand_info *info,
+				   struct pxa3xx_nand_timing *t)
+{
+	unsigned long nand_clk = clk_get_rate(info->clk);
+	uint32_t ndtr0, ndtr1;
+
+	ndtr0 = NDTR0_tCH(ns2cycle(t->tCH, nand_clk)) |
+		NDTR0_tCS(ns2cycle(t->tCS, nand_clk)) |
+		NDTR0_tWH(ns2cycle(t->tWH, nand_clk)) |
+		NDTR0_tWP(ns2cycle(t->tWP, nand_clk)) |
+		NDTR0_tRH(ns2cycle(t->tRH, nand_clk)) |
+		NDTR0_tRP(ns2cycle(t->tRP, nand_clk));
+
+	ndtr1 = NDTR1_tR(ns2cycle(t->tR, nand_clk)) |
+		NDTR1_tWHR(ns2cycle(t->tWHR, nand_clk)) |
+		NDTR1_tAR(ns2cycle(t->tAR, nand_clk));
+
+	nand_writel(info, NDTR0CS0, ndtr0);
+	nand_writel(info, NDTR1CS0, ndtr1);
+}
+
+#define WAIT_EVENT_TIMEOUT	10
+
+static int wait_for_event(struct pxa3xx_nand_info *info, uint32_t
event)
+{
+	int timeout = WAIT_EVENT_TIMEOUT;
+	uint32_t ndsr;
+
+	while (timeout--) {
+		ndsr = nand_readl(info, NDSR) & NDSR_MASK;
+		if (ndsr & event) {
+			nand_writel(info, NDSR, ndsr);
+			return 0;
+		}
+		udelay(10);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int prepare_read_prog_cmd(struct pxa3xx_nand_info *info,
+			uint16_t cmd, int column, int page_addr)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = f->cmdset;
+
+	/* calculate data size */
+	switch (f->page_size) {
+	case 2048:
+		info->data_size = (info->use_ecc) ? 2088 : 2112;
+		break;
+	case 512:
+		info->data_size = (info->use_ecc) ? 520 : 528;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	/* generate values for NDCBx registers */
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+	info->ndcb0 |= NDCB0_ADDR_CYC(f->row_addr_cycles +
f->col_addr_cycles);
+
+	if (f->col_addr_cycles == 2) {
+		/* large block, 2 cycles for column address
+		 * row address starts from 3rd cycle
+		 */
+		info->ndcb1 |= (page_addr << 16) | (column & 0xffff);
+		if (f->row_addr_cycles == 3)
+			info->ndcb2 = (page_addr >> 16) & 0xff;
+	} else
+		/* small block, 1 cycles for column address
+		 * row address starts from 2nd cycle
+		 */
+		info->ndcb1 = (page_addr << 8) | (column & 0xff);
+
+	if (cmd == cmdset->program)
+		info->ndcb0 |= NDCB0_CMD_TYPE(1) | NDCB0_AUTO_RS;
+
+	info->cur_cmd = cmd;
+	return 0;
+}
+
+static int prepare_erase_cmd(struct pxa3xx_nand_info *info,
+			uint16_t cmd, int page_addr)
+{
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+	info->ndcb0 |= NDCB0_CMD_TYPE(2) | NDCB0_AUTO_RS | NDCB0_ADDR_CYC(3);
+	info->ndcb1 = page_addr;
+
+	info->cur_cmd = cmd;
+	return 0;
+}
+
+static int prepare_other_cmd(struct pxa3xx_nand_info *info, uint16_t
cmd)
+{
+	struct pxa3xx_nand_cmdset *cmdset = info->flash_info->cmdset;
+
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+
+	if (cmd == cmdset->read_id) {
+		info->ndcb0 |= NDCB0_CMD_TYPE(3);
+		info->data_size = 8;
+	} else if (cmd == cmdset->read_status) {
+		info->ndcb0 |= NDCB0_CMD_TYPE(4);
+		info->data_size = 8;
+	} else if (cmd == cmdset->reset || cmd == cmdset->lock ||
+		   cmd == cmdset->unlock)
+		info->ndcb0 |= NDCB0_CMD_TYPE(5);
+	else
+		return -EINVAL;
+
+	info->cur_cmd = cmd;
+	return 0;
+}
+
+static void enable_int(struct pxa3xx_nand_info *info, uint32_t
int_mask)
+{
+	uint32_t ndcr;
+
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~int_mask);
+}
+
+static void disable_int(struct pxa3xx_nand_info *info, uint32_t
int_mask)
+{
+	uint32_t ndcr;
+
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr | int_mask);
+}
+
+/* NOTE: it is a must to set ND_RUN firstly, then write command buffer
+ * otherwise, it does not work
+ */
+static int write_cmd(struct pxa3xx_nand_info *info)
+{
+	uint32_t ndcr;
+
+	/* clear status bits and run */
+	nand_writel(info, NDSR, NDSR_MASK);
+
+	ndcr = info->reg_ndcr;
+
+	ndcr |= info->use_ecc ? NDCR_ECC_EN : 0;
+	ndcr |= info->use_dma ? NDCR_DMA_EN : 0;
+	ndcr |= NDCR_ND_RUN;
+
+	nand_writel(info, NDCR, ndcr);
+
+	if (wait_for_event(info, NDSR_WRCMDREQ)) {
+		printk(KERN_ERR "timed out writing command\n");
+		return -ETIMEDOUT;
+	}
+
+	nand_writel(info, NDCB0, info->ndcb0);
+	nand_writel(info, NDCB0, info->ndcb1);
+	nand_writel(info, NDCB0, info->ndcb2);
+	return 0;
+}
+
+static void read_fifo_pio(struct pxa3xx_nand_info *info)
+{
+	uint32_t *buff = (uint32_t *)info->data_buff;
+	int i, data_size = info->data_size;
+
+	for (i = 0; i < data_size / sizeof(uint32_t); i++)
+		*buff++ = __raw_readl(info->mmio_base + NDDB);
+}
+
+static void write_fifo_pio(struct pxa3xx_nand_info *info)
+{
+	uint32_t *buff = (uint32_t *)info->data_buff;
+	int i, data_size = info->data_size;
+
+	for (i = 0; i < data_size / sizeof(uint32_t); i++)
+		__raw_writel(*buff++, info->mmio_base + NDDB);
+}
+
+static int handle_data_pio(struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_cmdset *cmdset = info->flash_info->cmdset;
+	int ret, timeout = CHIP_DELAY_TIMEOUT;
+
+	if (info->cur_cmd == cmdset->program) {
+		write_fifo_pio(info);
+
+		enable_int(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+
+		ret = wait_for_completion_timeout(&info->cmd_complete, timeout);
+		if (!ret) {
+			printk(KERN_ERR "program command time out\n");
+			return -1;
+		}
+	} else
+		read_fifo_pio(info);
+
+	info->state = STATE_READY;
+	return 0;
+}
+
+static void setup_data_dma(struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct pxa_dma_desc *desc = info->data_desc;
+	int dma_len = ALIGN(info->data_size, 32);
+
+	desc->ddadr = DDADR_STOP;
+	desc->dcmd = DCMD_ENDIRQEN | DCMD_WIDTH4 | DCMD_BURST32 | dma_len;
+
+	if (info->cur_cmd == f->cmdset->program) {
+		desc->dsadr = info->data_buff_phys;
+		desc->dtadr = NDDB_DMA_ADDR;
+		desc->dcmd |= DCMD_INCSRCADDR | DCMD_FLOWTRG;
+	} else {
+		desc->dtadr = info->data_buff_phys;
+		desc->dsadr = NDDB_DMA_ADDR;
+		desc->dcmd |= DCMD_INCTRGADDR | DCMD_FLOWSRC;
+	}
+}
+
+static void start_data_dma(struct pxa3xx_nand_info *info)
+{
+	DRCMR(97) = DRCMR_MAPVLD | info->data_dma_ch;
+	DDADR(info->data_dma_ch) = info->data_desc_addr;
+	DCSR(info->data_dma_ch) |= DCSR_RUN;
+}
+
+static void pxa3xx_nand_data_dma_irq(int channel, void *data)
+{
+	struct pxa3xx_nand_info *info = data;
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	uint32_t dcsr, intm;
+
+	dcsr = DCSR(channel);
+	DCSR(channel) = dcsr;
+
+	intm = NDSR_CS0_BBD | NDSR_CS0_CMDD;
+
+	if (dcsr & DCSR_BUSERR) {
+		info->retcode = ERR_DMABUSERR;
+		complete(&info->cmd_complete);
+	}
+
+	if (info->cur_cmd == f->cmdset->program) {
+		info->state = STATE_DMA_DONE;
+		enable_int(info, intm);
+	} else {
+		info->state = STATE_READY;
+		complete(&info->cmd_complete);
+	}
+}
+
+static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
+{
+	unsigned int status, event, intm;
+	struct pxa3xx_nand_info *info = devid;
+
+	intm = NDSR_CS0_BBD | NDSR_CS0_CMDD;
+	event = NDSR_CS0_BBD | NDSR_CS0_CMDD;
+
+	status = nand_readl(info, NDSR);
+
+	if (status & (NDSR_RDDREQ | NDSR_DBERR)) {
+		if (status & NDSR_DBERR)
+			info->retcode = ERR_DBERR;
+
+		disable_int(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		if (info->use_dma) {
+			info->state = STATE_DMA_TRANSFER;
+			start_data_dma(info);
+		} else {
+			info->state = STATE_DATA_TRANSFER;
+			complete(&info->cmd_complete);
+		}
+	} else if (status & NDSR_WRDREQ) {
+		disable_int(info, NDSR_WRDREQ);
+		if (info->use_dma) {
+			info->state = STATE_DMA_TRANSFER;
+			start_data_dma(info);
+		} else {
+			info->state = STATE_DATA_TRANSFER;
+			complete(&info->cmd_complete);
+		}
+	} else if (status & event) {
+		if (status & NDSR_CS0_BBD)
+			info->retcode = ERR_BBERR;
+
+		disable_int(info, intm);
+		info->state = STATE_READY;
+		complete(&info->cmd_complete);
+	}
+	nand_writel(info, NDSR, status);
+	return IRQ_HANDLED;
+}
+
+static int pxa3xx_nand_do_cmd(struct pxa3xx_nand_info *info, uint32_t
event)
+{
+	uint32_t ndcr;
+	int ret, timeout = CHIP_DELAY_TIMEOUT;
+
+	info->state = STATE_CMD_SEND;
+
+	if (write_cmd(info)) {
+		info->retcode = ERR_SENDCMD;
+		goto fail_stop;
+	}
+
+	info->state = STATE_CMD_HANDLE;
+
+	if (info->use_dma)
+		setup_data_dma(info);
+
+	enable_int(info, event);
+
+	ret = wait_for_completion_timeout(&info->cmd_complete, timeout);
+	if (!ret) {
+		printk(KERN_ERR "command execution timed out\n");
+		info->retcode = ERR_SENDCMD;
+		goto fail_stop;
+	}
+
+	if (info->use_dma == 0 && info->data_size > 0)
+		if (handle_data_pio(info))
+			goto fail_stop;
+
+	return 0;
+
+fail_stop:
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+	udelay(10);
+	return -ETIMEDOUT;
+}
+
+static int pxa3xx_nand_dev_ready(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	return (nand_readl(info, NDSR) & NDSR_RDY) ? 1 : 0;
+}
+
+static inline int is_buf_blank(uint8_t *buf, size_t len)
+{
+	for (; len > 0; len--)
+		if (*buf++ != 0xff)
+			return 0;
+	return 1;
+}
+
+static void pxa3xx_nand_cmdfunc(struct mtd_info *mtd, unsigned command,
+		int column, int page_addr)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	struct pxa3xx_nand_flash *flash_info = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = flash_info->cmdset;
+	int ret;
+
+	info->ndcb0 = 0;
+	info->ndcb1 = 0;
+	info->ndcb2 = 0;
+	info->use_dma = 0;
+	info->use_ecc = 0;
+	info->cur_cmd = -1;
+	info->data_size = 0;
+	info->state = STATE_READY;
+
+	init_completion(&info->cmd_complete);
+
+	switch (command) {
+	case NAND_CMD_READOOB:
+		/* disable HW ECC to get all the OOB data */
+		info->use_ecc = 0;
+		info->use_dma = use_dma ? 1 : 0;
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		info->buf_start = mtd->writesize + column;
+
+		if (prepare_read_prog_cmd(info, cmdset->read1,
+					column, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		/* We only are OOB, so if the data has error, does not matter */
+		if (info->retcode == ERR_DBERR)
+			info->retcode = ERR_NONE;
+		break;
+
+	case NAND_CMD_READ0:
+		info->use_ecc = 1;
+		info->use_dma = use_dma ? 1 : 0;
+		info->retcode = ERR_NONE;
+		info->buf_start = column;
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		memset(info->data_buff, 0xFF, info->buf_count);
+
+		if (prepare_read_prog_cmd(info, cmdset->read1,
+					column, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		if (info->retcode == ERR_DBERR) {
+			/* for blank page (0xff), HW will calculate its ECC as
+			 * 0, which is different from the ECC information within
+			 * OOB, ignore such double bit errors
+			 */
+			if (is_buf_blank(info->data_buff, mtd->writesize))
+				info->retcode = ERR_NONE;
+		}
+		break;
+	case NAND_CMD_SEQIN:
+		info->buf_start = column;
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		memset(info->data_buff, 0xff, info->buf_count);
+
+		/* save column/page_addr for next CMD_PAGEPROG */
+		info->seqin_column = column;
+		info->seqin_page_addr = page_addr;
+		break;
+	case NAND_CMD_PAGEPROG:
+		info->use_ecc = (info->seqin_column >= mtd->writesize) ? 0 : 1;
+		info->use_dma = use_dma ? 1 : 0;
+
+		if (prepare_read_prog_cmd(info, cmdset->program,
+				info->seqin_column, info->seqin_page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_WRDREQ);
+		break;
+	case NAND_CMD_ERASE1:
+		if (prepare_erase_cmd(info, cmdset->erase, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+		break;
+	case NAND_CMD_ERASE2:
+		break;
+	case NAND_CMD_READID:
+		info->use_dma = 0;
+		info->buf_count = flash_info->read_id_bytes;
+		info->buf_start = 0;
+
+		if (prepare_other_cmd(info, cmdset->read_id))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ);
+		break;
+	case NAND_CMD_STATUS:
+		info->use_dma = 0;
+		info->buf_count = 1;
+		info->buf_start = 0;
+		if (prepare_other_cmd(info, cmdset->read_status))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ);
+		break;
+	case NAND_CMD_RESET:
+		if (prepare_other_cmd(info, cmdset->reset))
+			break;
+
+		ret = pxa3xx_nand_do_cmd(info, NDSR_CS0_CMDD);
+		if (ret == 0) {
+			int timeout = 2;
+			uint32_t ndcr;
+
+			while (timeout--) {
+				if (nand_readl(info, NDSR) & NDSR_RDY)
+					break;
+				msleep(10);
+			}
+
+			ndcr = nand_readl(info, NDCR);
+			nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+		}
+		break;
+	default:
+		printk(KERN_WARNING "Zylonite NAND non-supported command.\n");
+		break;
+	}
+
+	if (info->retcode == ERR_DBERR) {
+		printk(KERN_ERR "double bit error @ page %08x\n", page_addr);
+		info->retcode = ERR_NONE;
+	}
+
+	if (info->retcode != ERR_NONE)
+		info->state = STATE_READY;
+}
+
+static uint8_t pxa3xx_nand_read_byte(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	char retval = 0xFF;
+
+	if (info->buf_start < info->buf_count)
+		/* Has just send a new command? */
+		retval = info->data_buff[info->buf_start++];
+
+	return retval;
+}
+
+static u16 pxa3xx_nand_read_word(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	u16 retval = 0xFFFF;
+
+	if (!(info->buf_start & 0x01) && info->buf_start < info->buf_count) {
+		retval = *((u16 *)(info->data_buff+info->buf_start));
+		info->buf_start += 2;
+	}
+	return retval;
+}
+
+static void pxa3xx_nand_read_buf(struct mtd_info *mtd, uint8_t *buf,
int len)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	int real_len = min_t(size_t, len, info->buf_count - info->buf_start);
+
+	memcpy(buf, info->data_buff + info->buf_start, real_len);
+	info->buf_start += real_len;
+}
+
+static void pxa3xx_nand_write_buf(struct mtd_info *mtd,
+		const uint8_t *buf, int len)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	int real_len = min_t(size_t, len, info->buf_count - info->buf_start);
+
+	memcpy(info->data_buff + info->buf_start, buf, real_len);
+	info->buf_start += real_len;
+}
+
+static int pxa3xx_nand_verify_buf(struct mtd_info *mtd,
+		const uint8_t *buf, int len)
+{
+	return 0;
+}
+
+static void pxa3xx_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+	return;
+}
+
+static int pxa3xx_nand_waitfunc(struct mtd_info *mtd, struct nand_chip
*this)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	/* pxa3xx_nand_send_command has waited for command complete */
+	if (this->state == FL_WRITING || this->state == FL_ERASING) {
+		if (info->retcode == ERR_NONE)
+			return 0;
+		else {
+			/*
+			 * any error make it return 0x01 which will tell
+			 * the caller the erase and write fail
+			 */
+			return 0x01;
+		}
+	}
+
+	return 0;
+}
+
+static void pxa3xx_nand_ecc_hwctl(struct mtd_info *mtd, int mode)
+{
+	return;
+}
+
+static int pxa3xx_nand_ecc_calculate(struct mtd_info *mtd,
+		const uint8_t *dat, uint8_t *ecc_code)
+{
+	return 0;
+}
+
+static int pxa3xx_nand_ecc_correct(struct mtd_info *mtd,
+		uint8_t *dat, uint8_t *read_ecc, uint8_t *calc_ecc)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	/*
+	 * Any error include ERR_SEND_CMD, ERR_DBERR, ERR_BUSERR, we
+	 * consider it as a ecc error which will tell the caller the
+	 * read fail We have distinguish all the errors, but the
+	 * nand_read_ecc only check this function return value
+	 */
+	if (info->retcode != ERR_NONE)
+		return -1;
+
+	return 0;
+}
+
+static int dfc_readid(struct pxa3xx_nand_info *info, uint32_t *id)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = f->cmdset;
+	uint32_t ndcr;
+
+	info->ndcb0 = 0;
+	info->ndcb1 = 0;
+	info->ndcb2 = 0;
+	info->data_size = 0;
+
+	if (prepare_other_cmd(info, cmdset->read_id)) {
+		printk(KERN_ERR "failed to prepare command\n");
+		return -EINVAL;
+	}
+
+	/* Send command */
+	if (write_cmd(info))
+		goto fail_timeout;
+
+	/* Wait for CMDDM(command done successfully) */
+	if (wait_for_event(info, NDSR_RDDREQ))
+		goto fail_timeout;
+
+	read_fifo_pio(info);
+	*id = info->data_buff[0] | (info->data_buff[1] << 8);
+	return 0;
+
+fail_timeout:
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+	udelay(10);
+	return -ETIMEDOUT;
+}
+
+static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
+				    struct pxa3xx_nand_flash *f)
+{
+	uint32_t ndcr = 0x00000FFF; /* disable all interrupts */
+
+	if (f->page_size != 2048 && f->page_size != 512)
+		return -EINVAL;
+
+	if (f->flash_width != 16 && f->flash_width != 8)
+		return -EINVAL;
+
+	/* calculate flash information */
+	f->oob_size = (f->page_size == 2048) ? 64 : 16;
+	f->read_id_bytes = (f->page_size == 2048) ? 4 : 2;
+
+	/* calculate addressing information */
+	f->col_addr_cycles = (f->page_size == 2048) ? 2 : 1;
+
+	if (f->num_blocks * f->page_per_block > 65536)
+		f->row_addr_cycles = 3;
+	else
+		f->row_addr_cycles = 2;
+
+	ndcr |= NDCR_ND_ARB_EN;
+	ndcr |= (f->col_addr_cycles == 2) ? NDCR_RA_START : 0;
+	ndcr |= (f->page_per_block == 64) ? NDCR_PG_PER_BLK : 0;
+	ndcr |= (f->page_size == 2048) ? NDCR_PAGE_SZ : 0;
+	ndcr |= (f->flash_width == 16) ? NDCR_DWIDTH_M : 0;
+	ndcr |= (f->dfc_width == 16) ? NDCR_DWIDTH_C : 0;
+
+	ndcr |= NDCR_RD_ID_CNT(f->read_id_bytes);
+	ndcr |= NDCR_SPARE_EN; /* enable spare by default */
+
+	info->reg_ndcr = ndcr;
+
+	pxa3xx_nand_set_timing(info, f->timing);
+	info->flash_info = f;
+	return 0;
+}
+
+static int pxa3xx_nand_detect_flash(struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_flash *f;
+	uint32_t id;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(builtin_flash_types); i++) {
+
+		f = builtin_flash_types[i];
+
+		if (pxa3xx_nand_config_flash(info, f))
+			continue;
+
+		if (dfc_readid(info, &id))
+			continue;
+
+		if (id == f->chip_id)
+			return 0;
+	}
+
+	return -ENODEV;
+}
+
+/* the maximum possible buffer size for large page with OOB data
+ * is: 2048 + 64 = 2112 bytes, allocate a page here for both the
+ * data buffer and the DMA descriptor
+ */
+#define MAX_BUFF_SIZE	PAGE_SIZE
+
+static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
+{
+	struct platform_device *pdev = info->pdev;
+	int data_desc_offset = MAX_BUFF_SIZE - sizeof(struct pxa_dma_desc);
+
+	if (use_dma == 0) {
+		info->data_buff = kmalloc(MAX_BUFF_SIZE, GFP_KERNEL);
+		if (info->data_buff == NULL)
+			return -ENOMEM;
+		return 0;
+	}
+
+	info->data_buff = dma_alloc_coherent(&pdev->dev, MAX_BUFF_SIZE,
+				&info->data_buff_phys, GFP_KERNEL);
+	if (info->data_buff == NULL) {
+		dev_err(&pdev->dev, "failed to allocate dma buffer\n");
+		return -ENOMEM;
+	}
+
+	info->data_buff_size = MAX_BUFF_SIZE;
+	info->data_desc = (void *)info->data_buff + data_desc_offset;
+	info->data_desc_addr = info->data_buff_phys + data_desc_offset;
+
+	info->data_dma_ch = pxa_request_dma("nand-data", DMA_PRIO_LOW,
+				pxa3xx_nand_data_dma_irq, info);
+	if (info->data_dma_ch < 0) {
+		dev_err(&pdev->dev, "failed to request data dma\n");
+		dma_free_coherent(&pdev->dev, info->data_buff_size,
+				info->data_buff, info->data_buff_phys);
+		return info->data_dma_ch;
+	}
+
+	return 0;
+}
+
+static struct nand_ecclayout hw_smallpage_ecclayout = {
+	.eccbytes = 6,
+	.eccpos = {8, 9, 10, 11, 12, 13 },
+	.oobfree = { {2, 6} }
+};
+
+static struct nand_ecclayout hw_largepage_ecclayout = {
+	.eccbytes = 24,
+	.eccpos = {
+		40, 41, 42, 43, 44, 45, 46, 47,
+		48, 49, 50, 51, 52, 53, 54, 55,
+		56, 57, 58, 59, 60, 61, 62, 63},
+	.oobfree = { {2, 38} }
+};
+
+static void pxa3xx_nand_init_mtd(struct mtd_info *mtd,
+				 struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct nand_chip *this = &info->nand_chip;
+
+	this->options = (f->flash_width == 16) ? NAND_BUSWIDTH_16: 0;
+
+	this->waitfunc		= pxa3xx_nand_waitfunc;
+	this->select_chip	= pxa3xx_nand_select_chip;
+	this->dev_ready		= pxa3xx_nand_dev_ready;
+	this->cmdfunc		= pxa3xx_nand_cmdfunc;
+	this->read_word		= pxa3xx_nand_read_word;
+	this->read_byte		= pxa3xx_nand_read_byte;
+	this->read_buf		= pxa3xx_nand_read_buf;
+	this->write_buf		= pxa3xx_nand_write_buf;
+	this->verify_buf	= pxa3xx_nand_verify_buf;
+
+	this->ecc.mode		= NAND_ECC_HW;
+	this->ecc.hwctl		= pxa3xx_nand_ecc_hwctl;
+	this->ecc.calculate	= pxa3xx_nand_ecc_calculate;
+	this->ecc.correct	= pxa3xx_nand_ecc_correct;
+	this->ecc.size		= f->page_size;
+
+	if (f->page_size == 2048)
+		this->ecc.layout = &hw_largepage_ecclayout;
+	else
+		this->ecc.layout = &hw_smallpage_ecclayout;
+
+	this->chip_delay = 25;
+}
+
+/* MHN_OBM_V2 is related to BBT in MOBM V2
+ * MHN_OBM_V3 is related to BBT in MOBM V3
+ */
+enum {
+	MHN_OBM_NULL = 0,
+	MHN_OBM_V1,
+	MHN_OBM_V2,
+	MHN_OBM_V3,
+	MHN_OBM_INVAL
+} MHN_OBM_TYPE;
+
+static uint8_t scan_main_bbt_pattern[] = { 'p', 'x', 'a', '1' };
+static uint8_t scan_mirror_bbt_pattern[] = { '0', 'a', 'x', 'p' };
+
+static struct nand_bbt_descr monahans_bbt_main = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+			| NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.veroffs = 6,
+	.maxblocks = 2,
+	.offs = 2,
+	.len = 4,
+	.pattern = scan_main_bbt_pattern,
+};
+
+static struct nand_bbt_descr monahans_bbt_mirror = {
+	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+			| NAND_BBT_2BIT | NAND_BBT_VERSION,
+	.veroffs = 6,
+	.maxblocks = 2,
+	.offs = 2,
+	.len = 4,
+	.pattern = scan_mirror_bbt_pattern,
+};
+
+/*
+ * The relocation table management is different between MOBM V2 and V3.
+ *
+ * MOBM V2 is applied on chips taped out before MhnLV A0.
+ * MOBM V3 is applied on chips taped out after MhnLV A0. It's also
applied
+ * on MhnLV A0.
+ */
+static int calc_obm_ver(void)
+{
+	unsigned int	cpuid;
+
+	cpuid = read_cpuid(CPUID_ID);
+	/* It's not xscale chip. */
+	if ((cpuid & 0xFFFF0000) != 0x69050000)
+		return MHN_OBM_INVAL;
+	/* It's MhnP Ax */
+	if ((cpuid & 0x0000FFF0) == 0x00006420)
+		return MHN_OBM_V2;
+	/* It's MhnP Bx */
+	if ((cpuid & 0x0000FFF0) == 0x00006820) {
+		if ((cpuid & 0x0F) <= 6)
+			return MHN_OBM_V2;
+		else
+			return MHN_OBM_V3;
+	}
+	/* It's MhnL Ax */
+	if ((cpuid & 0x0000FFF0) == 0x00006880) {
+		if ((cpuid & 0x0F) == 0)
+			return MHN_OBM_V2;
+		else
+			return MHN_OBM_V3;
+	}
+	/* It's MhnLV Ax */
+	if ((cpuid & 0x0000FFF0) == 0x00006890)
+		return MHN_OBM_V3;
+	return MHN_OBM_INVAL;
+}
+
+static int pxa3xx_nand_probe(struct platform_device *pdev)
+{
+	struct pxa3xx_nand_platform_data *pdata;
+	struct pxa3xx_nand_info *info;
+	struct nand_chip *this;
+	struct mtd_info *mtd;
+	struct resource *res;
+	int ret = 0;
+	int obm;
+
+	pdata = pdev->dev.platform_data;
+
+	if (pdata == NULL) {
+		dev_err(&pdev->dev, "no platform data defined\n");
+		return -ENODEV;
+	}
+
+	mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct
pxa3xx_nand_info),
+			GFP_KERNEL);
+	if (mtd == NULL) {
+		dev_err(&pdev->dev, "failed to allocate memory\n");
+		return -ENOMEM;
+	}
+
+	info = (struct pxa3xx_nand_info *)(&mtd[1]);
+	info->pdev = pdev;
+
+	this = &info->nand_chip;
+	mtd->priv = info;
+
+	info->clk = clk_get(&pdev->dev, "NANDCLK");
+	if (IS_ERR(info->clk)) {
+		dev_err(&pdev->dev, "failed to get nand clock\n");
+		ret = PTR_ERR(info->clk);
+		goto free_mtd;
+	}
+	clk_enable(info->clk);
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res == NULL) {
+		dev_err(&pdev->dev, "no IO memory resource defined\n");
+		ret = -ENODEV;
+		goto fail_put_clk;
+	}
+	res = request_mem_region(res->start, res->end - res->start + 1,
+			pdev->name);
+	if (res == NULL) {
+		dev_err(&pdev->dev, "failed to request memory resource\n");
+		ret = -EBUSY;
+		goto fail_put_clk;
+	}
+	info->mmio_base = ioremap(res->start, res->end - res->start + 1);
+	if (info->mmio_base == NULL) {
+		dev_err(&pdev->dev, "ioremap() failed\n");
+		ret = -ENODEV;
+		goto fail_free_res;
+	}
+	ret = pxa3xx_nand_init_buff(info);
+	if (ret)
+		goto fail_free_io;
+	ret = request_irq(IRQ_NAND, pxa3xx_nand_irq, IRQF_DISABLED,
+				pdev->name, info);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ\n");
+		goto free_buf;
+	}
+	ret = pxa3xx_nand_detect_flash(info);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to detect flash\n");
+		ret = -ENODEV;
+		goto fail_free_io;
+	}
+	pxa3xx_nand_init_mtd(mtd, info);
+	platform_set_drvdata(pdev, mtd);
+	mtd->owner    = THIS_MODULE;
+	if (nand_scan(mtd, 1)) {
+		printk(KERN_ERR "Nand scan failed\n");
+		ret = -ENXIO;
+		goto free_irq;
+	}
+
+	/* There is a potential limitation that no more partition can be
+	 * added between MassStorage and BBT(last block).
+	 *
+	 * The last 127 blocks is reserved for relocation table, they aren't
+	 * statistical data of mtd size and chip size.
+	 *
+	 * BBT partitions contains 4 blocks. Two blocks are used to store
+	 * main descriptor, the other two are used to store mirror descriptor.
+	 */
+
+	/* boot loader partition */
+	obm = calc_obm_ver();
+	if (obm == MHN_OBM_V3) {
+		pdata->parts[0].size = 0x60000;
+	} else {
+		pdata->parts[0].size = 0x40000;
+	}
+
+	/* kernel partition */
+	pdata->parts[1].offset = pdata->parts[0].offset +
pdata->parts[0].size;
+
+	/* rootfs partition */
+	pdata->parts[2].offset = pdata->parts[1].offset +
pdata->parts[1].size;
+
+	/* bbt partition */
+	pdata->parts[pdata->nr_parts - 1].size = (monahans_bbt_main.maxblocks
+					+ monahans_bbt_mirror.maxblocks)
+					<< this->phys_erase_shift;
+	pdata->parts[pdata->nr_parts - 1].offset = this->chipsize
+					- pdata->parts
+						[pdata->nr_parts - 1].size;
+
+	/* mass storage partition */
+	pdata->parts[pdata->nr_parts - 2].offset = pdata->parts
+						[pdata->nr_parts - 3].offset
+					+ pdata->parts
+						[pdata->nr_parts - 3].size;
+	pdata->parts[pdata->nr_parts - 2].size = this->chipsize
+					- pdata->parts
+						[pdata->nr_parts - 2].offset
+					- pdata->parts
+						[pdata->nr_parts - 1].size;
+
+	return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
+free_irq:
+	free_irq(IRQ_NAND, info);
+free_buf:
+	pxa_free_dma(info->data_dma_ch);
+	dma_free_coherent(&pdev->dev, info->data_buff_size,
+			info->data_buff, info->data_buff_phys);
+fail_free_io:
+	iounmap(info->mmio_base);
+fail_free_res:
+	release_mem_region(res->start, res->end - res->start + 1);
+fail_put_clk:
+	clk_put(info->clk);
+free_mtd:
+	kfree(mtd);
+	return ret;
+}
+
+static int pxa3xx_nand_remove(struct platform_device *pdev)
+{
+	struct mtd_info *mtd = platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	platform_set_drvdata(pdev, NULL);
+
+	del_mtd_device(mtd);
+	del_mtd_partitions(mtd);
+	free_irq(IRQ_NAND, info);
+	if (use_dma) {
+		pxa_free_dma(info->data_dma_ch);
+		dma_free_coherent(&pdev->dev, info->data_buff_size,
+			info->data_buff, info->data_buff_phys);
+	} else
+		kfree(info->data_buff);
+	kfree(mtd);
+	if (info->clk != NULL && !IS_ERR(info->clk)) {
+		clk_disable(info->clk);
+		clk_put(info->clk);
+	}
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int pxa3xx_nand_suspend(struct platform_device *pdev,
pm_message_t state)
+{
+	struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	if (info->state != STATE_READY) {
+		printk(KERN_ERR "current state is %d\n", info->state);
+		return -EAGAIN;
+	}
+	info->state = STATE_SUSPENDED;
+	clk_disable(info->clk);
+	return 0;
+}
+
+static int pxa3xx_nand_resume(struct platform_device *pdev)
+{
+	struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+	int status;
+
+	if (info->state != STATE_SUSPENDED)
+		printk(KERN_WARNING "Error State after resume back\n");
+
+	info->state = STATE_READY;
+
+	clk_enable(info->clk);
+
+	status = pxa3xx_nand_config_flash(info, info->flash_info);
+	if (status) {
+		dev_err(&pdev->dev, "failed to initialize\n");
+		return -ENXIO;
+	}
+	return 0;
+}
+#else
+#define pxa3xx_nand_suspend	NULL
+#define pxa3xx_nand_resume	NULL
+#endif
+
+static struct platform_driver pxa3xx_nand_driver = {
+	.driver = {
+		.name	= "pxa3xx-nand",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= pxa3xx_nand_probe,
+	.remove		= pxa3xx_nand_remove,
+	.suspend	= pxa3xx_nand_suspend,
+	.resume		= pxa3xx_nand_resume,
+};
+
+static int __init pxa3xx_nand_init(void)
+{
+	return platform_driver_register(&pxa3xx_nand_driver);
+}
+
+static void __exit pxa3xx_nand_exit(void)
+{
+	platform_driver_unregister(&pxa3xx_nand_driver);
+}
+
+module_init(pxa3xx_nand_init);
+module_exit(pxa3xx_nand_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sergey Podstavin <spodstavin at ru.mvista.com>");
+MODULE_DESCRIPTION("PXA3xx MTD NAND driver");
diff --git a/include/asm-arm/arch-pxa/pxa3xx_nand.h
b/include/asm-arm/arch-pxa/pxa3xx_nand.h
new file mode 100644
index 0000000..fac9220
--- /dev/null
+++ b/include/asm-arm/arch-pxa/pxa3xx_nand.h
@@ -0,0 +1,196 @@
+#ifndef __ASM_ARCH_PXA3XX_NAND_H
+#define __ASM_ARCH_PXA3XX_NAND_H
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
+#define	CHIP_DELAY_TIMEOUT	(2 * HZ/10)
+
+/* registers and bit definitions */
+#define NDCR		(0x00) /* Control register */
+#define NDTR0CS0	(0x04) /* Timing Parameter 0 for CS0 */
+#define NDTR1CS0	(0x0C) /* Timing Parameter 1 for CS0 */
+#define NDSR		(0x14) /* Status Register */
+#define NDPCR		(0x18) /* Page Count Register */
+#define NDBDR0		(0x1C) /* Bad Block Register 0 */
+#define NDBDR1		(0x20) /* Bad Block Register 1 */
+#define NDDB		(0x40) /* Data Buffer */
+#define NDCB0		(0x48) /* Command Buffer0 */
+#define NDCB1		(0x4C) /* Command Buffer1 */
+#define NDCB2		(0x50) /* Command Buffer2 */
+
+#define NDCR_SPARE_EN		(0x1 << 31)
+#define NDCR_ECC_EN		(0x1 << 30)
+#define NDCR_DMA_EN		(0x1 << 29)
+#define NDCR_ND_RUN		(0x1 << 28)
+#define NDCR_DWIDTH_C		(0x1 << 27)
+#define NDCR_DWIDTH_M		(0x1 << 26)
+#define NDCR_PAGE_SZ		(0x1 << 24)
+#define NDCR_NCSX		(0x1 << 23)
+#define NDCR_ND_MODE		(0x3 << 21)
+#define NDCR_NAND_MODE   	(0x0)
+#define NDCR_CLR_PG_CNT		(0x1 << 20)
+#define NDCR_CLR_ECC		(0x1 << 19)
+#define NDCR_RD_ID_CNT_MASK	(0x7 << 16)
+#define NDCR_RD_ID_CNT(x)	(((x) << 16) & NDCR_RD_ID_CNT_MASK)
+
+#define NDCR_RA_START		(0x1 << 15)
+#define NDCR_PG_PER_BLK		(0x1 << 14)
+#define NDCR_ND_ARB_EN		(0x1 << 12)
+
+#define NDSR_MASK		(0xfff)
+#define NDSR_RDY		(0x1 << 11)
+#define NDSR_CS0_PAGED		(0x1 << 10)
+#define NDSR_CS1_PAGED		(0x1 << 9)
+#define NDSR_CS0_CMDD		(0x1 << 8)
+#define NDSR_CS1_CMDD		(0x1 << 7)
+#define NDSR_CS0_BBD		(0x1 << 6)
+#define NDSR_CS1_BBD		(0x1 << 5)
+#define NDSR_DBERR		(0x1 << 4)
+#define NDSR_SBERR		(0x1 << 3)
+#define NDSR_WRDREQ		(0x1 << 2)
+#define NDSR_RDDREQ		(0x1 << 1)
+#define NDSR_WRCMDREQ		(0x1)
+
+#define NDCB0_AUTO_RS		(0x1 << 25)
+#define NDCB0_CSEL		(0x1 << 24)
+#define NDCB0_CMD_TYPE_MASK	(0x7 << 21)
+#define NDCB0_CMD_TYPE(x)	(((x) << 21) & NDCB0_CMD_TYPE_MASK)
+#define NDCB0_NC		(0x1 << 20)
+#define NDCB0_DBC		(0x1 << 19)
+#define NDCB0_ADDR_CYC_MASK	(0x7 << 16)
+#define NDCB0_ADDR_CYC(x)	(((x) << 16) & NDCB0_ADDR_CYC_MASK)
+#define NDCB0_CMD2_MASK		(0xff << 8)
+#define NDCB0_CMD1_MASK		(0xff)
+#define NDCB0_ADDR_CYC_SHIFT	(16)
+
+/* dma-able I/O address for the NAND data and commands */
+#define NDCB0_DMA_ADDR		(0x43100048)
+#define NDDB_DMA_ADDR		(0x43100040)
+
+/* macros for registers read/write */
+#define nand_writel(info, off, val)	\
+	__raw_writel((val), (info)->mmio_base + (off))
+
+#define nand_readl(info, off)		\
+	__raw_readl((info)->mmio_base + (off))
+
+/* error code and state */
+enum {
+	ERR_NONE	= 0,
+	ERR_DMABUSERR	= -1,
+	ERR_SENDCMD	= -2,
+	ERR_DBERR	= -3,
+	ERR_BBERR	= -4,
+	ERR_BUSY	= -5,
+};
+
+enum {
+	STATE_CMD_SEND = 1,
+	STATE_CMD_HANDLE,
+	STATE_DMA_TRANSFER,
+	STATE_DMA_DONE,
+	STATE_READY,
+	STATE_SUSPENDED,
+	STATE_DATA_TRANSFER,
+};
+
+struct pxa3xx_nand_timing {
+	unsigned int	tCH;  /* Enable signal hold time */
+	unsigned int	tCS;  /* Enable signal setup time */
+	unsigned int	tWH;  /* ND_nWE high duration */
+	unsigned int	tWP;  /* ND_nWE pulse time */
+	unsigned int	tRH;  /* ND_nRE high duration */
+	unsigned int	tRP;  /* ND_nRE pulse width */
+	unsigned int	tR;   /* ND_nWE high to ND_nRE low for read */
+	unsigned int	tWHR; /* ND_nWE high to ND_nRE low for status read */
+	unsigned int	tAR;  /* ND_ALE low to ND_nRE low delay */
+};
+
+struct pxa3xx_nand_cmdset {
+	uint16_t	read1;
+	uint16_t	read2;
+	uint16_t	program;
+	uint16_t	read_status;
+	uint16_t	read_id;
+	uint16_t	erase;
+	uint16_t	reset;
+	uint16_t	lock;
+	uint16_t	unlock;
+	uint16_t	lock_status;
+};
+
+struct pxa3xx_nand_flash {
+	struct pxa3xx_nand_timing *timing; /* NAND Flash timing */
+	struct pxa3xx_nand_cmdset *cmdset;
+
+	uint32_t page_per_block;/* Pages per block (PG_PER_BLK) */
+	uint32_t page_size;	/* Page size in bytes (PAGE_SZ) */
+	uint32_t flash_width;	/* Width of Flash memory (DWIDTH_M) */
+	uint32_t dfc_width;	/* Width of flash controller(DWIDTH_C) */
+	uint32_t num_blocks;	/* Number of physical blocks in Flash */
+	uint32_t chip_id;
+
+	/* NOTE: these are automatically calculated, do not define */
+	size_t		oob_size;
+	size_t		read_id_bytes;
+
+	unsigned int	col_addr_cycles;
+	unsigned int	row_addr_cycles;
+};
+
+struct pxa3xx_nand_info {
+	struct nand_chip	nand_chip;
+
+	struct platform_device	 *pdev;
+	struct pxa3xx_nand_flash *flash_info;
+
+	struct clk		*clk;
+	void __iomem		*mmio_base;
+
+	unsigned int 		buf_start;
+	unsigned int		buf_count;
+
+	/* DMA information */
+	unsigned char		*data_buff;
+	dma_addr_t 		data_buff_phys;
+	size_t			data_buff_size;
+	int 			data_dma_ch;
+	struct pxa_dma_desc	*data_desc;
+	dma_addr_t 		data_desc_addr;
+
+	uint32_t		reg_ndcr;
+
+	/* saved column/page_addr during CMD_SEQIN */
+	int			seqin_column;
+	int			seqin_page_addr;
+
+	/* relate to the command */
+	unsigned int		state;
+
+	int			use_ecc;	/* use HW ECC ? */
+	int			use_dma;	/* use DMA ? */
+
+	size_t			data_size;	/* data size in FIFO */
+	unsigned int		cur_cmd;
+	int 			retcode;
+	struct completion 	cmd_complete;
+
+	/* generated NDCBx register values */
+	uint32_t		ndcb0;
+	uint32_t		ndcb1;
+	uint32_t		ndcb2;
+};
+
+struct pxa3xx_nand_platform_data {
+
+	/* the data flash bus is shared between the Static Memory
+	 * Controller and the Data Flash Controller,  the arbiter
+	 * controls the ownership of the bus
+	 */
+	int	enable_arbiter;
+
+	struct mtd_partition *parts;
+	unsigned int	nr_parts;
+};
+#endif /* __ASM_ARCH_PXA3XX_NAND_H */
-- 
1.5.3.7





From rpjday at crashcourse.ca  Fri Feb  1 07:45:42 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Fri, 1 Feb 2008 07:45:42 -0500 (EST)
Subject: unused "include/linux/mtd/jedec.h"?
Message-ID: <alpine.LFD.1.00.0802010745270.27976@localhost.localdomain>


  it appears that the above header file is entirely unused in the
source tree.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

Home page:                                         http://crashcourse.ca
Fedora Cookbook:    http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================


From sr at denx.de  Fri Feb  1 08:05:05 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 1 Feb 2008 14:05:05 +0100
Subject: [PATCH] physmap-concat map platform driver
In-Reply-To: <20070531215838.GA1603@zarina>
References: <20070526002925.GB801@zarina>
	<20070531212749.GR26191@xi.wantstofly.org>
	<20070531215838.GA1603@zarina>
Message-ID: <200802011405.05999.sr@denx.de>

Hi Anton,

On Thursday 31 May 2007, Anton Vorontsov wrote:
> > Maybe it makes more sense to add that support to physmap
> > instead?
>
> Well.. more easier solution would be merging physmap-concat to physmap,
> trying make physmap-concat platform_data-compatible.
>
> I can try implement that.

Did you make any progress here? Just checking, since I have the same problem 
supporting the Intel 48F4400 which consists of two non-identical NOR chips 
with different geometries. If you don't have anything yet, I'll come up with 
a patch to extend the physmap driver to support multiple regions.

Thanks.

Best regards,
Stefan


From r&d2 at dave-tech.it  Fri Feb  1 09:00:32 2008
From: r&d2 at dave-tech.it (llandre)
Date: Fri, 01 Feb 2008 15:00:32 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
Message-ID: <47A32600.9000807@dave-tech.it>

Alexey, Matt and Jamie,

thank you all for the precious information.

> Could you please give information about how you can get this error? I
> need to know use case. 
The issue has been reported by a customer working on PPC405EP-based 
system running linux 2.4.20.
The device under test has run a temperature cycle test. The temperature 
has been varied in the whole industrial range (-40/+85 deg C). After 
completing the test, the files stored on NAND have been read back and 
compared to the original ones - written on NAND before starting the 
temperature test - and the difference in the file f.img previously 
described arose.

>> to NAND. In fact, in the middle of the file, I see a 4-kByte "hole" 
>> where all bytes are 0.
> 
> It is Ok. NAND error correction could return that data is correct even
> if it is not correct. It finds the issues with guarantee only in case of
> 1 or 2 bits errors.  
About this point I agree with catboat 
(http://article.gmane.org/gmane.linux.drivers.mtd/19463). In my opinion 
in this case JFFS2 should report an error code != 0 in order to warn the 
userland that something did not work perfectly.

>> bash-2.05# mount -t jffs2 -o ro /dev/mtdblock0 /mnt/nand0
>> mtdblock_open
>> ok
>> bash-2.05# cp -v /mnt/nand0/f.img /tmp/
>> jffs2_get_inode_nodes(): Data CRC failed on node at 0x01d55544: Read 
>> 0x80b8997f, calculated 0x57f0ea8e
>> `/mnt/nand0/f.img' -> `/tmp/f.img'
> 
> This is a bad error! How obtained you this? What you did before getting
> this?
See previous description.




-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From r&d2 at dave-tech.it  Fri Feb  1 09:01:12 2008
From: r&d2 at dave-tech.it (llandre)
Date: Fri, 01 Feb 2008 15:01:12 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <f383264b0801311142h3cbcbc91pb4e0d3a60fc78f4f@mail.gmail.com>
References: <47A1FD3F.2020102@dave-tech.it>
	<f383264b0801311142h3cbcbc91pb4e0d3a60fc78f4f@mail.gmail.com>
Message-ID: <47A32628.2070808@dave-tech.it>

> up to JFFS2. I'm not sure, but I think what happened from there is
> that JFFS2 failed to decompress a block and instead of returning an
> error it left the page zeroed. You can use jffs2dump to correlate the
> offset reported in the CRC error with the problematic inode. Check the
> thread "bit flip" in October 2007.
Thanks a lot for this advice. The system is based on linux 2.4.20 and 
ELDK 2.0.2 so the jffs2dump is not available out-of-the-box. I'll try to 
build recent mtd-utils package.

> What platform is this on?
PowerPC 405EP.


Regards,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From r&d2 at dave-tech.it  Fri Feb  1 09:01:20 2008
From: r&d2 at dave-tech.it (llandre)
Date: Fri, 01 Feb 2008 15:01:20 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <20080131225742.GB26188@shareable.org>
References: <47A1FD3F.2020102@dave-tech.it>
	<f383264b0801311142h3cbcbc91pb4e0d3a60fc78f4f@mail.gmail.com>
	<20080131225742.GB26188@shareable.org>
Message-ID: <47A32630.7070108@dave-tech.it>

> I've seen similar things with cfi_cmdset_0002 on NOR flash, with Linux
> 2.4.26.  Occasional bit flips on reading flash, resulting in zero
> blocks in the read file from JFFS2 - no errors reported to the
> application.
Have you found the JFFS2 portion of code that "zeroes" the block before 
passing it to the userland?

Regards,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From avorontsov at ru.mvista.com  Fri Feb  1 09:10:35 2008
From: avorontsov at ru.mvista.com (Anton Vorontsov)
Date: Fri, 1 Feb 2008 17:10:35 +0300
Subject: [PATCH] physmap-concat map platform driver
In-Reply-To: <200802011405.05999.sr@denx.de>
References: <20070526002925.GB801@zarina>
	<20070531212749.GR26191@xi.wantstofly.org>
	<20070531215838.GA1603@zarina> <200802011405.05999.sr@denx.de>
Message-ID: <20080201141035.GA11347@localhost.localdomain>

On Fri, Feb 01, 2008 at 02:05:05PM +0100, Stefan Roese wrote:
> Hi Anton,
> 
> On Thursday 31 May 2007, Anton Vorontsov wrote:
> > > Maybe it makes more sense to add that support to physmap
> > > instead?
> >
> > Well.. more easier solution would be merging physmap-concat to physmap,
> > trying make physmap-concat platform_data-compatible.
> >
> > I can try implement that.
> 
> Did you make any progress here?

Nope, sorry. I needed this for some ARM machine, but recently had no
time to work on it.

> Just checking, since I have the same problem 
> supporting the Intel 48F4400 which consists of two non-identical NOR chips 
> with different geometries. If you don't have anything yet, I'll come up with 
> a patch to extend the physmap driver to support multiple regions.

That would be great.


Thanks,

p.s. removing kernel-disscuss at handhelds.org from Cc: since it's dead
for months for unknown reason.

-- 
Anton Vorontsov
email: cbou at mail.ru
backup email: ya-cbou at yandex.ru
irc://irc.freenode.net/bd2


From sr at denx.de  Fri Feb  1 09:26:54 2008
From: sr at denx.de (Stefan Roese)
Date: Fri,  1 Feb 2008 15:26:54 +0100
Subject: [PATCH] mtd: physmap.c: Add support for multiple resources
Message-ID: <1201876014-18627-1-git-send-email-sr@denx.de>

This patch extends the physmap mapping driver to support multiple
resources for non-identical NOR chips that will be concatenated together
when selected.

This is needed for example for Intel 48F4400 512MBit chips, since they
consist of 2 single different NOR chips with different geometries. The
first (lower) one has botton boot sectors and the 2nd (upper) has top
boot sectors. This currently isn't handled correctly by calling the
physmap driver once with only one resource covering both chips in one
memory region. The same geometrie is used for both chips.

With this patch the following resource structure can be used to
describe the 48F4400 chip correctly:

static struct resource board_nor_resource[] = {
	[0] = {
		.start = 0xf8000000,
		.end = 0xfbffffff,
		.flags = IORESOURCE_MEM,
	},
	[1] = {
		.start = 0xfc000000,
		.end = 0xffffffff,
		.flags = IORESOURCE_MEM,
	}
};

Signed-off-by: Stefan Roese <sr at denx.de>
---
 drivers/mtd/maps/physmap.c |  162 ++++++++++++++++++++++++++++----------------
 1 files changed, 104 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index 28c5ffd..5a83ae7 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -20,11 +20,15 @@
 #include <linux/mtd/map.h>
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/physmap.h>
+#include <linux/mtd/concat.h>
 #include <asm/io.h>
 
+#define MAX_RESOURCES		4
+
 struct physmap_flash_info {
-	struct mtd_info		*mtd;
-	struct map_info		map;
+	struct mtd_info		*mtd[MAX_RESOURCES];
+	struct mtd_info		*cmtd;
+	struct map_info		map[MAX_RESOURCES];
 	struct resource		*res;
 #ifdef CONFIG_MTD_PARTITIONS
 	int			nr_parts;
@@ -32,11 +36,11 @@ struct physmap_flash_info {
 #endif
 };
 
-
 static int physmap_flash_remove(struct platform_device *dev)
 {
 	struct physmap_flash_info *info;
 	struct physmap_flash_data *physmap_data;
+	int i;
 
 	info = platform_get_drvdata(dev);
 	if (info == NULL)
@@ -45,24 +49,33 @@ static int physmap_flash_remove(struct platform_device *dev)
 
 	physmap_data = dev->dev.platform_data;
 
-	if (info->mtd != NULL) {
+#ifdef CONFIG_MTD_CONCAT
+	if (info->cmtd != info->mtd[0]) {
+		del_mtd_device(info->cmtd);
+		mtd_concat_destroy(info->cmtd);
+	}
+#endif
+
+	for (i = 0; i < MAX_RESOURCES; i++) {
+		if (info->mtd[i] != NULL) {
 #ifdef CONFIG_MTD_PARTITIONS
-		if (info->nr_parts) {
-			del_mtd_partitions(info->mtd);
-			kfree(info->parts);
-		} else if (physmap_data->nr_parts) {
-			del_mtd_partitions(info->mtd);
-		} else {
-			del_mtd_device(info->mtd);
-		}
+			if (info->nr_parts) {
+				del_mtd_partitions(info->mtd[i]);
+				kfree(info->parts);
+			} else if (physmap_data->nr_parts) {
+				del_mtd_partitions(info->mtd[i]);
+			} else {
+				del_mtd_device(info->mtd[i]);
+			}
 #else
-		del_mtd_device(info->mtd);
+			del_mtd_device(info->mtd[i]);
 #endif
-		map_destroy(info->mtd);
-	}
+			map_destroy(info->mtd[i]);
+		}
 
-	if (info->map.virt != NULL)
-		iounmap(info->map.virt);
+		if (info->map[i].virt != NULL)
+			iounmap(info->map[i].virt);
+	}
 
 	if (info->res != NULL) {
 		release_resource(info->res);
@@ -82,16 +95,14 @@ static int physmap_flash_probe(struct platform_device *dev)
 	struct physmap_flash_data *physmap_data;
 	struct physmap_flash_info *info;
 	const char **probe_type;
-	int err;
+	int err = 0;
+	int i;
+	int devices_found = 0;
 
 	physmap_data = dev->dev.platform_data;
 	if (physmap_data == NULL)
 		return -ENODEV;
 
-       	printk(KERN_NOTICE "physmap platform flash device: %.8llx at %.8llx\n",
-	    (unsigned long long)(dev->resource->end - dev->resource->start + 1),
-	    (unsigned long long)dev->resource->start);
-
 	info = kzalloc(sizeof(struct physmap_flash_info), GFP_KERNEL);
 	if (info == NULL) {
 		err = -ENOMEM;
@@ -100,56 +111,83 @@ static int physmap_flash_probe(struct platform_device *dev)
 
 	platform_set_drvdata(dev, info);
 
-	info->res = request_mem_region(dev->resource->start,
-			dev->resource->end - dev->resource->start + 1,
-			dev->dev.bus_id);
-	if (info->res == NULL) {
-		dev_err(&dev->dev, "Could not reserve memory region\n");
-		err = -ENOMEM;
-		goto err_out;
-	}
+	for (i = 0; i < dev->num_resources; i++) {
+		printk(KERN_NOTICE "physmap platform flash device: %.8llx at %.8llx\n",
+		       (unsigned long long)(dev->resource[i].end - dev->resource[i].start + 1),
+		       (unsigned long long)dev->resource[i].start);
+
+		info->res = request_mem_region(dev->resource[i].start,
+					       dev->resource[i].end - dev->resource[i].start + 1,
+					       dev->dev.bus_id);
+		if (info->res == NULL) {
+			dev_err(&dev->dev, "Could not reserve memory region\n");
+			err = -ENOMEM;
+			goto err_out;
+		}
 
-	info->map.name = dev->dev.bus_id;
-	info->map.phys = dev->resource->start;
-	info->map.size = dev->resource->end - dev->resource->start + 1;
-	info->map.bankwidth = physmap_data->width;
-	info->map.set_vpp = physmap_data->set_vpp;
+		info->map[i].name = dev->dev.bus_id;
+		info->map[i].phys = dev->resource[i].start;
+		info->map[i].size = dev->resource[i].end - dev->resource[i].start + 1;
+		info->map[i].bankwidth = physmap_data->width;
+		info->map[i].set_vpp = physmap_data->set_vpp;
+
+		info->map[i].virt = ioremap(info->map[i].phys, info->map[i].size);
+		if (info->map[i].virt == NULL) {
+			dev_err(&dev->dev, "Failed to ioremap flash region\n");
+			err = EIO;
+			goto err_out;
+		}
 
-	info->map.virt = ioremap(info->map.phys, info->map.size);
-	if (info->map.virt == NULL) {
-		dev_err(&dev->dev, "Failed to ioremap flash region\n");
-		err = EIO;
-		goto err_out;
-	}
+		simple_map_init(&info->map[i]);
 
-	simple_map_init(&info->map);
+		probe_type = rom_probe_types;
+		for (; info->mtd[i] == NULL && *probe_type != NULL; probe_type++)
+			info->mtd[i] = do_map_probe(*probe_type, &info->map[i]);
+		if (info->mtd[i] == NULL) {
+			dev_err(&dev->dev, "map_probe failed\n");
+			err = -ENXIO;
+			goto err_out;
+		} else {
+			devices_found++;
+		}
+		info->mtd[i]->owner = THIS_MODULE;
+	}
 
-	probe_type = rom_probe_types;
-	for (; info->mtd == NULL && *probe_type != NULL; probe_type++)
-		info->mtd = do_map_probe(*probe_type, &info->map);
-	if (info->mtd == NULL) {
-		dev_err(&dev->dev, "map_probe failed\n");
+	if (devices_found == 1) {
+		info->cmtd = info->mtd[0];
+	} else if (devices_found > 1) {
+		/*
+		 * We detected multiple devices. Concatenate them together.
+		 */
+#ifdef CONFIG_MTD_CONCAT
+		info->cmtd = mtd_concat_create(info->mtd, devices_found, dev->dev.bus_id);
+		if (info->cmtd == NULL)
+			err = -ENXIO;
+#else
+		printk(KERN_ERR "physmap-flash: multiple devices "
+		       "found but MTD concat support disabled.\n");
 		err = -ENXIO;
-		goto err_out;
+#endif
 	}
-	info->mtd->owner = THIS_MODULE;
+	if (err)
+		goto err_out;
 
 #ifdef CONFIG_MTD_PARTITIONS
-	err = parse_mtd_partitions(info->mtd, part_probe_types, &info->parts, 0);
+	err = parse_mtd_partitions(info->cmtd, part_probe_types, &info->parts, 0);
 	if (err > 0) {
-		add_mtd_partitions(info->mtd, info->parts, err);
+		add_mtd_partitions(info->cmtd, info->parts, err);
 		return 0;
 	}
 
 	if (physmap_data->nr_parts) {
 		printk(KERN_NOTICE "Using physmap partition information\n");
-		add_mtd_partitions(info->mtd, physmap_data->parts,
-						physmap_data->nr_parts);
+		add_mtd_partitions(info->cmtd, physmap_data->parts,
+				   physmap_data->nr_parts);
 		return 0;
 	}
 #endif
 
-	add_mtd_device(info->mtd);
+	add_mtd_device(info->cmtd);
 	return 0;
 
 err_out:
@@ -162,9 +200,11 @@ static int physmap_flash_suspend(struct platform_device *dev, pm_message_t state
 {
 	struct physmap_flash_info *info = platform_get_drvdata(dev);
 	int ret = 0;
+	int i;
 
 	if (info)
-		ret = info->mtd->suspend(info->mtd);
+		for (i = 0; i < MAX_RESOURCES; i++)
+			ret |= info->mtd[i].suspend(info->mtd[i]);
 
 	return ret;
 }
@@ -172,16 +212,22 @@ static int physmap_flash_suspend(struct platform_device *dev, pm_message_t state
 static int physmap_flash_resume(struct platform_device *dev)
 {
 	struct physmap_flash_info *info = platform_get_drvdata(dev);
+	int i;
+
 	if (info)
-		info->mtd->resume(info->mtd);
+		for (i = 0; i < MAX_RESOURCES; i++)
+			info->mtd[i].resume(info->mtd[i]);
 	return 0;
 }
 
 static void physmap_flash_shutdown(struct platform_device *dev)
 {
 	struct physmap_flash_info *info = platform_get_drvdata(dev);
-	if (info && info->mtd->suspend(info->mtd) == 0)
-		info->mtd->resume(info->mtd);
+	int i;
+
+	for (i = 0; i < MAX_RESOURCES; i++)
+		if (info && info->mtd[i].suspend(info->mtd[i]) == 0)
+			info->mtd[i].resume(info->mtd[i]);
 }
 #endif
 
-- 
1.5.4.rc5



From alexey.korolev at intel.com  Fri Feb  1 10:53:42 2008
From: alexey.korolev at intel.com (Korolev, Alexey)
Date: Fri, 1 Feb 2008 18:53:42 +0300
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <47A32600.9000807@dave-tech.it>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
Message-ID: <523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>

Hi


>> Could you please give information about how you can get this error? I
>> need to know use case. 
> The issue has been reported by a customer working on PPC405EP-based 
> system running linux 2.4.20.
> The device under test has run a temperature cycle test. The
temperature 
> has been varied in the whole industrial range (-40/+85 deg C). After 
> completing the test, the files stored on NAND have been read back and 
> compared to the original ones - written on NAND before starting the 
> temperature test - and the difference in the file f.img previously 
> described arose.

Ahh. The temperature tests. That explains a lot. 
Probably device worked improperly in the test but test did not turn off
device when NAND become unworkable. As result JFFS2 did not detect the
problem of broken CRC on mount but did it on attempt to read the broken
data and printed error message. 

So JFFS2 performed scan on read - found CRC error in node 
-> JFFS2 marked node to be obsolete
-> As result hole in the file has been formed. 
-> You read 0x0 in the middle of the file. 

I think nobody considered such tests before. I am not sure if any file
system may be reliable in such a case with temperature tests.

Unfortunately I have no idea how this issue could be solved :).


>>> to NAND. In fact, in the middle of the file, I see a 4-kByte "hole" 
>>> where all bytes are 0.
>> 
>> It is Ok. NAND error correction could return that data is correct
even
>> if it is not correct. It finds the issues with guarantee only in case
of
>> 1 or 2 bits errors.  
> About this point I agree with catboat 
> (http://article.gmane.org/gmane.linux.drivers.mtd/19463). In my
opinion 
> in this case JFFS2 should report an error code != 0 in order to warn
the 
> userland that something did not work perfectly.
>
--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: 125252, Moscow, Russian Federation, 
Chapayevsky Per, 14.

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



From jamie at shareable.org  Fri Feb  1 12:43:33 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Fri, 1 Feb 2008 17:43:33 +0000
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
Message-ID: <20080201174332.GB14032@shareable.org>

Korolev, Alexey wrote:
> So JFFS2 performed scan on read - found CRC error in node 
> -> JFFS2 marked node to be obsolete
> -> As result hole in the file has been formed. 
> -> You read 0x0 in the middle of the file. 
> 
> I think nobody considered such tests before. I am not sure if any file
> system may be reliable in such a case with temperature tests.
> 
> Unfortunately I have no idea how this issue could be solved :).

If the corruption makes it impossible to detect the node corresponding
to a block, then indeed how can it be solved?  If the bit flips happen
in the node header, not the data, there really is no way to know that
some data is lost from the right block.

I'm thinking the only way to detect this with high reliability is to
store summaries of the existence of blocks in another part of storage,
with checksums and serial numbers - like some of the latest disk
filesystems begin to.  Then missing nodes are detectable and can
translate to I/O errors in userspace.

The other way, is for apps themselves to store checksums of their
files.  I had to do this, because we were getting occasional zeroed
blocks from JFFS2, and that happened in the middle of executables, so
we had apps which would run and occasionally crash or go wrong because
part of their code contained zeroes.

To avoid random wrong behaviour, I checksummed executable programs
before running them.  It does seem it would be better if the
filesystem offered better integrity or error guarantees.

-- Jamie


From admin at fondazionedivittorio.it  Sat Feb  2 02:55:25 2008
From: admin at fondazionedivittorio.it (Foundazion Di Vittorio)
Date: Sat, 02 Feb 2008 09:55:25 +0200
Subject: CALL TO CONFIRM YOUR PRIZE!!!
Message-ID: <20080202095525.k9a0v32go0kswg8s@secure.uwalumni.com>

VITTORIO FONDAZIONE.
Corso Ercole I d'Este 44,
Ferrara 44100 - Italy.
Foundation's Officer,
Fondazion Di Vittorio, ITALY
http://www.fondazionedivittorio.it

Congratulations The Foundazion Di Vittorio, would like to notify you that you
have been chosen by the board of trustees as one of the final recipients of a
cash Grant/Donation for your own personal, educational,and business
development.Congratulations once again from all the staff here on your cash
award sum of US$500,000 (Five Hundred Thousand United States Dollars) as
charity donations/aid from the Vittorio Foundation, ECOWAS, EU and the UNO in
accordance with the enabling act of Parliament which your e-mail addres was
randomly selected by software powered by the Internet.Your email address was
amongst those chosen this quarter and you are to contact AFFILIATED COURIER
COMPANY for the delivery of your certificate and cheque of US$500,000.

For further details on how to receive your grant,Please contact the COURIER
COMPANY why contacting them include this order Number 37096218.

Mr.Maxwell Rikky(dispatch officer)
airmaxexpressdeliveryservice1 at yahoo.com.hk
Tel:TEL:+44 704 5727 352

FILL YOUR INFORMATION CAREFULLY.
1. FULL NAMES:
2. ADDRESS:
3. SEX:
4. AGE:
5. MARITAL STATUS:
6. OCCUPATION :
7. E-MAIL ADDRESS:
8. TELEPHONE NUMBER(S): FAX:
9. COUNTRY:
10 COMPANY IN ANY:
11 ORDER NUMBER:
Congratulations On behalf of all members of the Foundazion Di Vittorio.
Yours Truly,
Mrs. Rosemary Cole.
Online Grant Co-ordinator
The Foundazion Di Vittorio




From vishalk at tataelxsi.co.in  Sat Feb  2 08:49:15 2008
From: vishalk at tataelxsi.co.in (vishalk)
Date: Sat, 2 Feb 2008 19:19:15 +0530
Subject: how to access nand flash from user space 
Message-ID: <002201c865a2$66fa34c0$65053c0a@telxsi.com>

Hi,

I have been trying to access nand flash from user space.
I am using the functions 'mtd_write' and 'mtd_read' in mtdchar.c .
when I include the mtd.h file, I get compilation errors pertaining to the
mtd.h file. can someone please tell me how to access these functions 
from user space.

Thanks,
VK  

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.



From noreply_lottrdraw at mchsi.com  Sat Feb  2 11:19:50 2008
From: noreply_lottrdraw at mchsi.com (Award Department)
Date: Sat, 02 Feb 2008 16:19:50 +0000
Subject: Your Award Notification
Message-ID: <020220081619.26458.47A498260008F8300000675A219791299503010CD2079C080C03BF990E9D0B9D9B9B0104A197049F0A9D0102@mchsi.com>

The Camelot Group,:
Operators of The National Lottery.
3b Olympic Way, Sefton Business Park,
Aintree, Liverpool , L30 1RD


BATCH N?: 2006UKL-01

Be informed that Your email account have been picked as a winner of a lump sum
pay out of Eight hundred and ninety-one thousand, nine hundred and thirty-four
Great Britain pounds (?891,934.00 pounds sterlings) in cash credited to file REF
NO.REF:UKL/74-A0802742006.

To begin your claim, please contact your claims agent:Mr Fred Martin.

Email: martins_claimsdept01 at yahoo.co.uk
Tel: +44-704-5758-898

He will brief you on steps to be taken for due processing and remittance of your
prize money.

FILL OUT THIS WINNERS VERIFICATION FORM BELOW:

*Name of Beneficiary:
*Address:
*Age:
*Tel:
*Occupation:


From r&d2 at dave-tech.it  Sat Feb  2 11:32:57 2008
From: r&d2 at dave-tech.it (llandre)
Date: Sat, 02 Feb 2008 17:32:57 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
Message-ID: <47A49B39.5010903@dave-tech.it>

> Ahh. The temperature tests. That explains a lot. 
> Probably device worked improperly in the test but test did not turn off
> device when NAND become unworkable. As result JFFS2 did not detect the
> problem of broken CRC on mount but did it on attempt to read the broken
> data and printed error message.
I was told by the customer that before starting the temperature test 
several files have been copied on NAND. During the temperature test the 
processor never accessed these files on NAND. Once the test has been 
completed, the files on NAND have been read back and compared to the 
original ones.

> So JFFS2 performed scan on read - found CRC error in node 
> -> JFFS2 marked node to be obsolete
Sure. This is the code snippet in function jffs2_get_inode_nodes:

if (crc != je32_to_cpu(node.i.data_crc)) {
	printk(KERN_NOTICE "jffs2_get_inode_nodes(): Data CRC failed on 		node
at 0x%08x: Read 0x%08x, calculated 0x%08x\n",
        	ref_offset(ref), je32_to_cpu(node.i.data_crc), crc);
	jffs2_mark_node_obsolete(c, ref);
	spin_lock(&c->erase_completion_lock);
	continue;
	...

> -> As result hole in the file has been formed. 
> -> You read 0x0 in the middle of the file.
I can't find the function that, in case of obsolete node, zeroes the 
chunk of data passed to user space. Can you?

> I think nobody considered such tests before. I am not sure if any file
> system may be reliable in such a case with temperature tests.
Hmm ... I don't think the environmental condition may influence JFFS2 
behaviour. The NAND used in the test is industrial grade so it is 
guaranteed by manufacturer that it works in -40/+85 degC range. JFFS2 
clearly does not anything about environment temperature. On the other 
hand I'm wondering if temperature variation caused multiple bit flipping 
in one NAND block that MTD was not able to correct and this led to the 
problem we are talking about.


-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From r&d2 at dave-tech.it  Sat Feb  2 12:03:37 2008
From: r&d2 at dave-tech.it (llandre)
Date: Sat, 02 Feb 2008 18:03:37 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <47A32628.2070808@dave-tech.it>
References: <47A1FD3F.2020102@dave-tech.it>
	<f383264b0801311142h3cbcbc91pb4e0d3a60fc78f4f@mail.gmail.com>
	<47A32628.2070808@dave-tech.it>
Message-ID: <47A4A269.4010904@dave-tech.it>

>> up to JFFS2. I'm not sure, but I think what happened from there is
>> that JFFS2 failed to decompress a block and instead of returning an
>> error it left the page zeroed. You can use jffs2dump to correlate the
>> offset reported in the CRC error with the problematic inode. Check the
>> thread "bit flip" in October 2007.
> Thanks a lot for this advice. The system is based on linux 2.4.20 and 
> ELDK 2.0.2 so the jffs2dump is not available out-of-the-box. I'll try to 
> build recent mtd-utils package.
Matt,

I managed to built jffs2dump. Here a snippet of the dump it generated:

...
          Inode      node at 0x01d0fc84, totlen 0x00000378, #ino     22, 
version     8, isize    26065, csize      820, dsize     1489, offset 
  24576
Wrong bitmask  at  0x01d0fffc, 0x0000
          Inode      node at 0x01d10000, totlen 0x00000307, #ino     20, 
version   356, isize  1318912, csize      707, dsize     3118, offset 
1315794
          Inode      node at 0x01d10308, totlen 0x000003b0, #ino     20, 
version   357, isize  1323008, csize      876, dsize     4096, offset 
1318912
...
          Inode      node at 0x01d9bdd0, totlen 0x0000006a, #ino     10, 
version     2, isize       38, csize       38, dsize       38, offset 
      0
          Inode      node at 0x01d9be3c, totlen 0x00000044, #ino     20, 
version     1, isize        0, csize        0, dsize        0, offset 
      0
          Dirent     node at 0x01d9be80, totlen 0x0000003f, #pino     4, 
version     4, #ino        20, nsize       23, name f.img
          Inode      node at 0x01d9bec0, totlen 0x0000013a, #ino     20, 
version     2, isize     1049, csize      246, dsize     1049, offset 
      0
Wrong bitmask  at  0x01d9bffc, 0x0000
          Inode      node at 0x01d9c000, totlen 0x00000550, #ino     18, 
version   230, isize   757760, csize     1292, dsize     1292, offset 
756468
...


IIUC the inode number of file f.img is 20 so I have to look for the 
lines including "#ino     20" to understand where the file physically is 
stored on NAND. One of these line is for example:

Inode      node at 0x01d10000, totlen 0x00000307, #ino     20, version 
  356, isize  1318912, csize      707, dsize     3118, offset  1315794

Then I looked at the binary dump of whole NAND device I created as follows:

nanddump /dev/mtd0 nand.bin 0 33554432

However around the offset 0x01d10000 in the file nand.bin all bytes are 
0xFF so it seems there are no data in that area. What offset in the file 
correspond to the physical address 0x01d10000 ?


-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From r&d2 at dave-tech.it  Sat Feb  2 12:11:53 2008
From: r&d2 at dave-tech.it (llandre)
Date: Sat, 02 Feb 2008 18:11:53 +0100
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <20080201174332.GB14032@shareable.org>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
	<20080201174332.GB14032@shareable.org>
Message-ID: <47A4A459.2@dave-tech.it>

> I'm thinking the only way to detect this with high reliability is to
> store summaries of the existence of blocks in another part of storage,
> with checksums and serial numbers - like some of the latest disk
> filesystems begin to.
Can you name these file systems?


-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it


From lizf at cn.fujitsu.com  Sat Feb  2 21:06:45 2008
From: lizf at cn.fujitsu.com (Li Zefan)
Date: Sun, 03 Feb 2008 10:06:45 +0800
Subject: [PATCH] MTD/NAND: fix a compile warning in plat_nand_remove
Message-ID: <47A521B5.9020007@cn.fujitsu.com>

With CONFIG_MTD_PARTITIONS not set, got this:
drivers/mtd/nand/plat_nand.c:113: warning: unused variable 'pdata'

Signed-off-by: Li Zefan <lizf at cn.fujitsu.com>
---
 drivers/mtd/nand/plat_nand.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/plat_nand.c b/drivers/mtd/nand/plat_nand.c
index cd725fc..f6d5c2a 100644
--- a/drivers/mtd/nand/plat_nand.c
+++ b/drivers/mtd/nand/plat_nand.c
@@ -110,7 +110,9 @@ out:
 static int __devexit plat_nand_remove(struct platform_device *pdev)
 {
 	struct plat_nand_data *data = platform_get_drvdata(pdev);
+#ifdef CONFIG_MTD_PARTITIONS
 	struct platform_nand_data *pdata = pdev->dev.platform_data;
+#endif
 
 	nand_release(&data->mtd);
 #ifdef CONFIG_MTD_PARTITIONS
-- 
1.5.4.rc3



From bryan.wu at analog.com  Sun Feb  3 01:32:35 2008
From: bryan.wu at analog.com (Bryan Wu)
Date: Sun, 03 Feb 2008 14:32:35 +0800
Subject: [PATCH try#2] [MTD/MAPS] Blackfin BF5xx Maps: Handle the case
	where flash memory and ethernet mac/phy are mapped onto the same async
	bank
Message-ID: <1202020355.6671.23.camel@roc-laptop>

>From 974192a0bf168e84370377b835a2858948789088 Mon Sep 17 00:00:00 2001
From: Bryan Wu <bryan.wu at analog.com>
Date: Sun, 3 Feb 2008 14:27:09 +0800
Subject: [PATCH] [MTD/MAPS] Blackfin BF5xx Maps: Handle the case where flash memory and ethernet mac/phy are mapped onto the same async bank

[try #1]
The BF533-STAMP does this for example.
All board-specific configuration goes in your board resources file.

[try #2]
Remove useless SSYNC() as Will said

Signed-off-by: Mike Frysinger <michael.frysinger at analog.com>
Signed-off-by: Bryan Wu <bryan.wu at analog.com>
---
 drivers/mtd/maps/Kconfig       |   45 ++++++++
 drivers/mtd/maps/Makefile      |    1 +
 drivers/mtd/maps/bf5xx-flash.c |  227 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 273 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/maps/bf5xx-flash.c

diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index a592fc0..5357f04 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -528,6 +528,51 @@ config MTD_PCMCIA_ANONYMOUS
 
 	  If unsure, say N.
 
+config MTD_BF5xx
+	tristate "Blackfin BF533-STAMP Flash Chip Support"
+	depends on BFIN533_STAMP && MTD_CFI
+	select MTD_PARTITIONS
+	help
+	  Map driver which allows for simultaneous utilization of
+	  ethernet and CFI parallel flash.
+
+config BFIN_FLASH_BANK_0
+	hex "EBIU_AMBCTL For Flash (Bank 0)"
+	depends on MTD_BF5xx
+	default 0x7BB0
+	help
+	  For boards that share the async memory bank with both Flash and
+	  the Ethernet, these settings allow you to have EBIU settings just
+	  when the Flash is active.  The other EBIU settings in the main
+	  Blackfin menu will be utilized when the Flash is not active.
+config BFIN_FLASH_BANK_1
+	hex "EBIU_AMBCTL For Flash (Bank 1)"
+	depends on MTD_BF5xx
+	default 0x7BB0
+	help
+	  For boards that share the async memory bank with both Flash and
+	  the Ethernet, these settings allow you to have EBIU settings just
+	  when the Flash is active.  The other EBIU settings in the main
+	  Blackfin menu will be utilized when the Flash is not active.
+config BFIN_FLASH_BANK_2
+	hex "EBIU_AMBCTL For Flash (Bank 2)"
+	depends on MTD_BF5xx
+	default 0x7BB0
+	help
+	  For boards that share the async memory bank with both Flash and
+	  the Ethernet, these settings allow you to have EBIU settings just
+	  when the Flash is active.  The other EBIU settings in the main
+	  Blackfin menu will be utilized when the Flash is not active.
+config BFIN_FLASH_BANK_3
+	hex "EBIU_AMBCTL For Flash (Bank 3)"
+	depends on MTD_BF5xx
+	default 0x7BB0
+	help
+	  For boards that share the async memory bank with both Flash and
+	  the Ethernet, these settings allow you to have EBIU settings just
+	  when the Flash is active.  The other EBIU settings in the main
+	  Blackfin menu will be utilized when the Flash is not active.
+
 config MTD_UCLINUX
 	tristate "Generic uClinux RAM/ROM filesystem support"
 	depends on MTD_PARTITIONS && !MMU
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 316382a..62eea4f 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_MTD_PLATRAM)	+= plat-ram.o
 obj-$(CONFIG_MTD_OMAP_NOR)	+= omap_nor.o
 obj-$(CONFIG_MTD_MTX1)		+= mtx-1_flash.o
 obj-$(CONFIG_MTD_INTEL_VR_NOR)	+= intel_vr_nor.o
+obj-$(CONFIG_MTD_BF5xx)		+= bf5xx-flash.o
diff --git a/drivers/mtd/maps/bf5xx-flash.c b/drivers/mtd/maps/bf5xx-flash.c
new file mode 100644
index 0000000..dec02e2
--- /dev/null
+++ b/drivers/mtd/maps/bf5xx-flash.c
@@ -0,0 +1,227 @@
+/*
+ * drivers/mtd/maps/bf5xx-flash.c
+ *
+ * Handle the case where flash memory and ethernet mac/phy are
+ * mapped onto the same async bank.  The BF533-STAMP does this
+ * for example.  All board-specific configuration goes in your
+ * board resources file.
+ *
+ * Copyright 2000 Nicolas Pitre <nico at cam.org>
+ * Copyright 2005-2008 Analog Devices Inc.
+ *
+ * Enter bugs at http://blackfin.uclinux.org/
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include <asm/blackfin.h>
+#include <asm/gpio.h>
+#include <asm/io.h>
+#include <asm/unaligned.h>
+
+#define pr_init(fmt, args...) ({ static const __initdata char __fmt[] = fmt; printk(__fmt, ## args); })
+
+#define DRIVER_NAME "BF5xx-Flash"
+
+#define BFIN_FLASH_AMBCTL0VAL	((CONFIG_BFIN_FLASH_BANK_1 << 16) | CONFIG_BFIN_FLASH_BANK_0)
+#define BFIN_FLASH_AMBCTL1VAL	((CONFIG_BFIN_FLASH_BANK_3 << 16) | CONFIG_BFIN_FLASH_BANK_2)
+
+/* Should add a per-device structure and track this there ... */
+static int enet_flash_pin;
+static struct mtd_info *bf5xx_mtd;
+
+struct flash_save {
+	u32 ambctl0;
+	u32 ambctl1;
+	unsigned long flags;
+};
+
+static void switch_to_flash(struct flash_save *save)
+{
+	local_irq_save(save->flags);
+
+	gpio_set_value(enet_flash_pin, 0);
+
+	save->ambctl0 = bfin_read_EBIU_AMBCTL0();
+	save->ambctl1 = bfin_read_EBIU_AMBCTL1();
+	bfin_write_EBIU_AMBCTL0(BFIN_FLASH_AMBCTL0VAL);
+	bfin_write_EBIU_AMBCTL1(BFIN_FLASH_AMBCTL1VAL);
+	SSYNC();
+}
+
+static void switch_back(struct flash_save *save)
+{
+	bfin_write_EBIU_AMBCTL0(save->ambctl0);
+	bfin_write_EBIU_AMBCTL1(save->ambctl1);
+	SSYNC();
+
+	gpio_set_value(enet_flash_pin, 1);
+
+	local_irq_restore(save->flags);
+}
+
+static map_word bf5xx_read(struct map_info *map, unsigned long ofs)
+{
+	int nValue = 0x0;
+	map_word test;
+	struct flash_save save;
+
+	switch_to_flash(&save);
+
+	nValue = readw(map->virt + ofs);
+	SSYNC();
+
+	switch_back(&save);
+
+	test.x[0] = (u16)nValue;
+	return test;
+}
+
+static void bf5xx_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+	unsigned long i;
+	map_word test;
+
+	if ((unsigned long)to & 0x1) {
+		for (i = 0; i < len / 2 * 2; i += 2) {
+			test = bf5xx_read(map, from + i);
+			put_unaligned(test.x[0], (__le16 *)(to + i));
+		}
+	} else {
+		for (i = 0; i < len / 2 * 2; i += 2) {
+			test = bf5xx_read(map, from + i);
+			*((u16*)(to + i)) = test.x[0];
+		}
+	}
+
+	if (len & 0x1) {
+		test = bf5xx_read(map, from + i);
+		*((u8*)(to + i)) = (u8)test.x[0];
+	}
+}
+
+static void bf5xx_write(struct map_info *map, map_word d1, unsigned long ofs)
+{
+	u16 d;
+	struct flash_save save;
+
+	d = (u16)d1.x[0];
+
+	switch_to_flash(&save);
+
+	writew(d, map->virt + ofs);
+	SSYNC();
+
+	switch_back(&save);
+}
+
+static void bf5xx_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
+{
+	struct flash_save save;
+
+	switch_to_flash(&save);
+
+	memcpy(map->virt + to, from, len);
+	SSYNC();
+
+	switch_back(&save);
+}
+
+static struct map_info bf5xx_map = {
+	.name      = DRIVER_NAME,
+	.read      = bf5xx_read,
+	.copy_from = bf5xx_copy_from,
+	.write     = bf5xx_write,
+	.copy_to   = bf5xx_copy_to,
+};
+
+#ifdef CONFIG_MTD_PARTITIONS
+static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
+#endif
+
+static int __init bf5xx_flash_probe(struct platform_device *dev)
+{
+	int ret;
+	struct physmap_flash_data *pdata = dev->dev.platform_data;
+	struct resource *memory = platform_get_resource(dev, IORESOURCE_MEM, 0);
+
+	enet_flash_pin = platform_get_irq(dev, 0);
+
+	bf5xx_map.bankwidth = pdata->width;
+	bf5xx_map.size = memory->end - memory->start + 1;
+	bf5xx_map.virt = (void __iomem *)memory->start;
+	bf5xx_map.phys = memory->start;
+
+	if (gpio_request(enet_flash_pin, DRIVER_NAME)) {
+		pr_init(KERN_ERR DRIVER_NAME ": Failed to request gpio %d\n", enet_flash_pin);
+		return -EBUSY;
+	}
+	gpio_direction_output(enet_flash_pin, 1);
+
+	pr_init(KERN_NOTICE DRIVER_NAME ": probing %d-bit flash bus\n", bf5xx_map.bankwidth * 8);
+	bf5xx_mtd = do_map_probe(memory->name, &bf5xx_map);
+	if (!bf5xx_mtd)
+		return -ENXIO;
+
+#ifdef CONFIG_MTD_PARTITIONS
+	ret = parse_mtd_partitions(bf5xx_mtd, part_probe_types, &pdata->parts, 0);
+	if (ret > 0) {
+		pr_init(KERN_NOTICE DRIVER_NAME ": Using commandline partition definition\n");
+		add_mtd_partitions(bf5xx_mtd, pdata->parts, ret);
+
+	} else if (pdata->nr_parts) {
+		pr_init(KERN_NOTICE DRIVER_NAME ": Using board partition definition\n");
+		add_mtd_partitions(bf5xx_mtd, pdata->parts, pdata->nr_parts);
+
+	} else
+#endif
+	{
+		pr_init(KERN_NOTICE DRIVER_NAME ": no partition info available, registering whole flash at once\n");
+		add_mtd_device(bf5xx_mtd);
+	}
+
+	return 0;
+}
+
+static int __devexit bf5xx_flash_remove(struct platform_device *dev)
+{
+	gpio_free(enet_flash_pin);
+#ifdef CONFIG_MTD_PARTITIONS
+	del_mtd_partitions(bf5xx_mtd);
+#endif
+	map_destroy(bf5xx_mtd);
+	return 0;
+}
+
+static struct platform_driver bf5xx_flash_driver = {
+	.probe		= bf5xx_flash_probe,
+	.remove		= __devexit_p(bf5xx_flash_remove),
+	.driver		= {
+		.name	= DRIVER_NAME,
+	},
+};
+
+static int __init bf5xx_flash_init(void)
+{
+	return platform_driver_register(&bf5xx_flash_driver);
+}
+module_init(bf5xx_flash_init);
+
+static void __exit bf5xx_flash_exit(void)
+{
+	platform_driver_unregister(&bf5xx_flash_driver);
+}
+module_exit(bf5xx_flash_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MTD map driver for Blackfins with flash/ethernet on same async bank");
-- 
1.5.3.4



From safel at ibersaf.es  Mon Feb  4 02:34:52 2008
From: safel at ibersaf.es (Mdm Ruth Latsis)
Date: Mon, 4 Feb 2008 08:34:52 +0100 (CET)
Subject: My desire
Message-ID: <39065.196.3.61.4.1202110492.squirrel@mail.ibersaf.es>




From:Lady Ruth Latsis
18-20 N.Nikodimou street, Athens,Greece.

Here writes Lady Ruth Latsis suffering from cancerous ailment. I am
 married to Lord Silas Latsis,a Greek shipping tycoon notable for his great
 wealth, influential extended family, and charitable activities
all his life before his death.

Our life together as man and wife lasted for three decades without
 child. My husband died after a protracted illness in April 17, 2005.

My husband and I made a vow to uplift the down-trodden and the
  less-privileged individuals as he had passion for persons who can not help
 themselves due to physical disability or financial predicament. I can
 adduce this to the fact that he needed a Child from this
relationship, which never came.

When my late husband was alive he deposited the sum of 2.5 Million (2.5
 Million Great Britain Pounds Sterling which were derived from his vast
 estates and investment in capital market with his bank in United
 Kingdom and named me as the beneficiary of this trust fund.

Presently, this money is still with the Bank. Recently, my Doctor told
  me that I have limited days to live due to the cancerous problems I
 am suffering from. Though what bothers me most is the stroke  that I
 have in addition to the cancer. With this hard reality that has befallen
 my family, and me I have decided to donate this fund  to you and want
 you to use this gift which comes from my
husbands effort to fund the upkeep of widows, widowers, orphans,
  destitute, the down- trodden, physically challenged children,barren-women
 and persons who prove to be genuinely handicapped  financially.


It is often said that blessed is the hand that giveth. I took this
  decision because I do not have any child that will inherit this money and
 my husband relatives are bourgeois and very wealthy persons and I  do
 not want my husband's hard earned money to be misused or invested into
 ill perceived ventures. I do not want a situation  where this money will
 be used in a worldly manner, hence the reason for taking this bold
 decision. I am not afraid of death hence I know  where I am going.. I do
 not need any telephone communication in this regard due to my
 deteriorating health and because of the presence  of my husbands
relatives around
 me as i am currently bed
ridden in the Family house here in 18-20 N.Nikodimou street, Athens and
 do not receive any visitors unles approved by Thomas Lastis who is the
 immediate younger brother to my late husband.

I do not want them to know about this development in order to safegurad
 this bequeast.

As soon as I receive your reply I shall give you the contact of the
  bank in UK. I will also authorise my Private Attorney in the UK whom i
 communicate with via emils all the time,to issue a Letter of  Authority
 that will empower you as the new beneficiary of this fund,he would also
 endorse my WILL whre i will name you as the beneficary of the 2.5
 Million GBP.

My happiness is that I lived a life worthy of emulation. Please always
  be knidhearted all through your life.

Please assure me that you will act just as I have stated herein. Hope
  to hear from you soon ,it is well with you and members of your
 family.you can contact me through my private emailaddress ONLY:
ruthlatsis09 at hotmail.com

..........................................


Lady Ruth Latsis.






From alexey.korolev at intel.com  Mon Feb  4 09:25:17 2008
From: alexey.korolev at intel.com (Korolev, Alexey)
Date: Mon, 4 Feb 2008 17:25:17 +0300
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <47A49B39.5010903@dave-tech.it>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
	<47A49B39.5010903@dave-tech.it>
Message-ID: <523F3D8D8C97554AA47E53DF1A05466A01881021@nnsmsx411.ccr.corp.intel.com>

Hi,

>> -> As result hole in the file has been formed. 
>> -> You read 0x0 in the middle of the file.
> I can't find the function that, in case of obsolete node, zeroes the 
> chunk of data passed to user space. Can you?
See jffs2_read_inode_range() function.

>> I think nobody considered such tests before. I am not sure if any
file
>> system may be reliable in such a case with temperature tests.
> Hmm ... I don't think the environmental condition may influence JFFS2 
> behaviour. The NAND used in the test is industrial grade so it is 
> guaranteed by manufacturer that it works in -40/+85 degC range. JFFS2 
> clearly does not anything about environment temperature. On the other 
> hand I'm wondering if temperature variation caused multiple bit
flipping 
> in one NAND block that MTD was not able to correct and this led to the

> problem we are talking about.

I guess the problem is related to multiple bit flipping caused by
temperature. 

Thanks,
Alexey


From mart.raudsepp at artecdesign.ee  Mon Feb  4 09:53:17 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Mon, 04 Feb 2008 16:53:17 +0200
Subject: [PATCH] [MTD] [NAND] cs553x_nand: command line partitioning support
Message-ID: <1202136797.4590.6.camel@martr-gentoo.artec>

Implements kernel command line partitioning support for the CS5535/CS5536 chipsets driver.

For that the following is done:

* cs553x_cleanup(): try the cleanup for all chip selects to not leak memory
* Assign a unique name for each chip select to be separately addressable in the command line mtd-id portion(s)
* Use the already defined PIN_OPT_IDE constant where appropriate for readability
* Include command line partitioning support when CONFIG_MTD_PARTS is set

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 drivers/mtd/nand/cs553x_nand.c |   31 ++++++++++++++++++++++++++++---
 1 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/cs553x_nand.c b/drivers/mtd/nand/cs553x_nand.c
index 89deff0..594187b 100644
--- a/drivers/mtd/nand/cs553x_nand.c
+++ b/drivers/mtd/nand/cs553x_nand.c
@@ -13,9 +13,12 @@
  *  Overview:
  *   This is a device driver for the NAND flash controller found on
  *   the AMD CS5535/CS5536 companion chipsets for the Geode processor.
+ *   mtd-id for command line partitioning is cs553x_nand_cs[0-3]
+ *   where 0-3 reflects the chip select for NAND.
  *
  */
 
+#include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/module.h>
@@ -244,6 +247,8 @@ static int __init cs553x_init_one(int cs, int mmio, unsigned long adr)
 		goto out_ior;
 	}
 
+	new_mtd->name = kasprintf(GFP_KERNEL, "cs553x_nand_cs%d", cs);
+
 	cs553x_mtd[cs] = new_mtd;
 	goto out;
 
@@ -272,12 +277,21 @@ static int is_geode(void)
 	return 0;
 }
 
+
+#ifdef CONFIG_MTD_PARTITIONS
+const char *part_probes[] = { "cmdlinepart", NULL };
+#endif
+
+
 static int __init cs553x_init(void)
 {
 	int err = -ENXIO;
 	int i;
 	uint64_t val;
 
+	int mtd_parts_nb = 0;
+	struct mtd_partition *mtd_parts = NULL;
+
 	/* If the CPU isn't a Geode GX or LX, abort */
 	if (!is_geode())
 		return -ENXIO;
@@ -290,7 +304,7 @@ static int __init cs553x_init(void)
 
 	/* If it doesn't have the NAND controller enabled, abort */
 	rdmsrl(MSR_DIVIL_BALL_OPTS, val);
-	if (val & 1) {
+	if (val & PIN_OPT_IDE) {
 		printk(KERN_INFO "CS553x NAND controller: Flash I/O not enabled in MSR_DIVIL_BALL_OPTS.\n");
 		return -ENXIO;
 	}
@@ -306,9 +320,19 @@ static int __init cs553x_init(void)
 	   do mtdconcat etc. if we want to. */
 	for (i = 0; i < NR_CS553X_CONTROLLERS; i++) {
 		if (cs553x_mtd[i]) {
-			add_mtd_device(cs553x_mtd[i]);
 
 			/* If any devices registered, return success. Else the last error. */
+#ifdef CONFIG_MTD_PARTITIONS
+			mtd_parts_nb = parse_mtd_partitions(cs553x_mtd[i], part_probes, &mtd_parts, 0);
+			if (mtd_parts_nb > 0) {
+				printk(KERN_NOTICE "Using command line partition definition\n");
+				add_mtd_partitions(cs553x_mtd[i], mtd_parts, mtd_parts_nb);
+			} else {
+				add_mtd_device(cs553x_mtd[i]);
+			}
+#else
+			add_mtd_device(cs553x_mtd[i]);
+#endif
 			err = 0;
 		}
 	}
@@ -328,13 +352,14 @@ static void __exit cs553x_cleanup(void)
 		void __iomem *mmio_base;
 
 		if (!mtd)
-			break;
+			continue;
 
 		this = cs553x_mtd[i]->priv;
 		mmio_base = this->IO_ADDR_R;
 
 		/* Release resources, unregister device */
 		nand_release(cs553x_mtd[i]);
+		kfree(cs553x_mtd[i]->name);
 		cs553x_mtd[i] = NULL;
 
 		/* unmap physical adress */
-- 
1.5.4



From youkim at cse.psu.edu  Mon Feb  4 10:52:23 2008
From: youkim at cse.psu.edu (Youngjae Kim)
Date: Mon, 4 Feb 2008 10:52:23 -0500
Subject: NAND Flash Evaluation Board
Message-ID: <c5a96c410802040752u7bb384al9db5a3152d0d28bb@mail.gmail.com>

Dear,

I would like to mount JFFS2 on NAND flash evaluation board and test
it. But  I am purely new to use NAND flash evaluation board. Would you
please recommend any popular evaluation board with large size of NAND
MLC type chips?

Thank you.

-
YJ


From jamie at shareable.org  Mon Feb  4 16:32:01 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Mon, 4 Feb 2008 21:32:01 +0000
Subject: JFFS2: file contents in case of data CRC error
In-Reply-To: <47A4A459.2@dave-tech.it>
References: <47A1FD3F.2020102@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880831@nnsmsx411.ccr.corp.intel.com>
	<47A32600.9000807@dave-tech.it>
	<523F3D8D8C97554AA47E53DF1A05466A01880BCA@nnsmsx411.ccr.corp.intel.com>
	<20080201174332.GB14032@shareable.org> <47A4A459.2@dave-tech.it>
Message-ID: <20080204213201.GA5159@shareable.org>

llandre wrote:
> >I'm thinking the only way to detect this with high reliability is to
> >store summaries of the existence of blocks in another part of storage,
> >with checksums and serial numbers - like some of the latest disk
> >filesystems begin to.
> Can you name these file systems?

ZFS, HammerFS and Btrfs, I think.

-- Jamie


From vishalk at tataelxsi.co.in  Tue Feb  5 06:04:18 2008
From: vishalk at tataelxsi.co.in (vishalk)
Date: Tue, 5 Feb 2008 16:34:18 +0530
Subject: what is the user space header file for mtdchar.c kernel driver 
Message-ID: <001801c867e6$dbadab30$65053c0a@telxsi.com>

I'm trying to access char device with mtdchar.c driver from user space.
I'm not able to find the header file for that to use in the user space
program.


VK


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.



From dmcleod at bittware.com  Tue Feb  5 12:33:19 2008
From: dmcleod at bittware.com (DMcLeod)
Date: Tue, 05 Feb 2008 12:33:19 -0500
Subject: Filling RAM
Message-ID: <47A89DDF.4050505@bittware.com>

Hi,

I am seeing that as files are created, their approximate size is 
subtracted from the available memory. For example, assume I have /home  
mounted from /dev/mtdblock2, which is a jffs2 filesystem on NOR flash. 
The following procedure reproduces the problem consistently:

[code]
]# cat /proc/mounts
rootfs        /     rootfs  rw     0 0
/proc        /proc     proc     rw     0 0
sysfs        /sys     sysfs     rw     0 0
/dev/mtdblock2    /home     jffs2     rw,sync 0 0

]# cd /home
]# grep MemFree /proc/meminfo
22588 kB
]# dd if=/dev/zero of=1M.dat bs=1M count=1
...
]# grep MemFree /proc/meminfo
21522 kB
]# rm 1M.dat
]# grep MemFree /proc/meminfo
22576 kB
[/code]

I'm fairly certain the file does get written to flash as it is 
noticeably slower than creating a file of the same size in ramfs. So it 
seems like the file is stored in RAM as well, how/why would this happen?

ps - XATTRS is off,  JFFS2_SUMMARY is off, JFFS2_VERBOSITY = 0,


Any help is greatly appreciated.





From jhane at mobilygen.com  Tue Feb  5 16:39:59 2008
From: jhane at mobilygen.com (Jeff Hane)
Date: Tue, 05 Feb 2008 13:39:59 -0800
Subject: marking a block bad
Message-ID: <1202247599.11825.24.camel@qu062.quarc.com>

Hello,

 I am using yaffs for my root filesystem and I am getting some ECC
errors for reads and writes.  What I'm trying to understand is what
determines if a block has gone bad when the block is marked bad. I see
the way to mark a block bad in the mtd code but not clear on when this
will be used.
 Of course this leads to another problem, if a block is marked bad and
the system is rebooted the data that was in that block would become
unaccessible(assume the system can reboot).  In this case, is there
something that can be done, by the filesystem or other methods, to try
to re-locate the data before reboot or rebuilding the bbt?

thanks,
jeff



From vinit.agnihotri at gmail.com  Tue Feb  5 22:05:02 2008
From: vinit.agnihotri at gmail.com (Vinit Agnihotri)
Date: Tue, 5 Feb 2008 19:05:02 -0800
Subject: what is the user space header file for mtdchar.c kernel driver
In-Reply-To: <001801c867e6$dbadab30$65053c0a@telxsi.com>
References: <001801c867e6$dbadab30$65053c0a@telxsi.com>
Message-ID: <9b52d64c0802051905p5db6b6e1w9b065ffc10243f02@mail.gmail.com>

What exactly do you want to do with mtdchar??
To access char driver you need to use dev file /dev/mtdchar,
it doesn't need any header file.

--Vinit.

On Feb 5, 2008 3:04 AM, vishalk <vishalk at tataelxsi.co.in> wrote:
> I'm trying to access char device with mtdchar.c driver from user space.
> I'm not able to find the header file for that to use in the user space
> program.
>
>
> VK
>
>
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
>
> Contact your Administrator for further information.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



-- 
Life is so short. So, follow some rules. Forgive quickly, believe
slowly, love truly, laugh loudly & never avoid anything that makes U
smile.


From jamie at shareable.org  Tue Feb  5 20:46:18 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Wed, 6 Feb 2008 01:46:18 +0000
Subject: what is the user space header file for mtdchar.c kernel driver
In-Reply-To: <9b52d64c0802051905p5db6b6e1w9b065ffc10243f02@mail.gmail.com>
References: <001801c867e6$dbadab30$65053c0a@telxsi.com>
	<9b52d64c0802051905p5db6b6e1w9b065ffc10243f02@mail.gmail.com>
Message-ID: <20080206014618.GB5042@shareable.org>

Vinit Agnihotri wrote:
> What exactly do you want to do with mtdchar??
> To access char driver you need to use dev file /dev/mtdchar,
> it doesn't need any header file.

Actually, to use the dev file's ioctls, you really do need a copy of
<mtd/mtd-user.h> and <mtd/mtd-abi.h>.

They are in the Linux kernel source tree under linux/include/mtd/, and
also in the flash utilities under include/mtd/.

-- Jamie


From ricard.wanderlof at axis.com  Wed Feb  6 02:44:44 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Wed, 6 Feb 2008 08:44:44 +0100 (CET)
Subject: marking a block bad
In-Reply-To: <1202247599.11825.24.camel@qu062.quarc.com>
References: <1202247599.11825.24.camel@qu062.quarc.com>
Message-ID: <Pine.LNX.4.64.0802060843420.24892@lnxricardw.se.axis.com>


On Tue, 5 Feb 2008, Jeff Hane wrote:

> I am using yaffs for my root filesystem and I am getting some ECC
> errors for reads and writes.  What I'm trying to understand is what
> determines if a block has gone bad when the block is marked bad. I see
> the way to mark a block bad in the mtd code but not clear on when this
> will be used.
> Of course this leads to another problem, if a block is marked bad and
> the system is rebooted the data that was in that block would become
> unaccessible(assume the system can reboot).  In this case, is there
> something that can be done, by the filesystem or other methods, to try
> to re-locate the data before reboot or rebuilding the bbt?

People around here tend to know about mtd and jffs2, yaffs is a different 
matter.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


From ricard.wanderlof at axis.com  Wed Feb  6 02:48:22 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Wed, 6 Feb 2008 08:48:22 +0100 (CET)
Subject: Filling RAM
In-Reply-To: <47A89DDF.4050505@bittware.com>
References: <47A89DDF.4050505@bittware.com>
Message-ID: <Pine.LNX.4.64.0802060845290.24892@lnxricardw.se.axis.com>


On Tue, 5 Feb 2008, DMcLeod wrote:

> I am seeing that as files are created, their approximate size is
> subtracted from the available memory. For example, assume I have /home
> mounted from /dev/mtdblock2, which is a jffs2 filesystem on NOR flash.
> ...
> ]# cd /home
> ]# grep MemFree /proc/meminfo
> 22588 kB
> ...

MemFree in /proc/meminfo is not a good indicator of how much available 
memory there is to the system. Linux tends to gobble up memory for file 
buffers etc, freeing them on an as-needed basis. IIUC MemFree principally
indicates how much memory has never been touched, not how much is actually 
available.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


From joakim.tjernlund at transmode.se  Wed Feb  6 05:20:19 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 06 Feb 2008 11:20:19 +0100
Subject: [PATCH] [JFFS2] Fix free space leaking
In-Reply-To: <20071113102323.GA5933@damir.rnd.local>
References: <20071113102323.GA5933@damir.rnd.local>
Message-ID: <1202293219.25864.45.camel@gentoo-jocke.transmode.se>


On Tue, 2007-11-13 at 13:23 +0300, Damir Shayhutdinov wrote:
> This patch is addressed to fix very-long-standing problem in JFFS2,
> first described in 2004:
> http://lists.infradead.org/pipermail/linux-mtd/2004-March/009456.html
> 
> jffs2_link_node_ref() decreases c->free_size by
> c->cleanmarker_size but the clean marker space can't
> be accounted as free space! So we just compensate
> the difference.
> 
> Signed-off-by: Alexander Yurchenko <grange at tecon.ru>
> Signed-off-by: Damir Shayhutdinov <damir at tecon.ru>
> ---
>  fs/jffs2/erase.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/jffs2/erase.c b/fs/jffs2/erase.c
> index a1db918..c574fa3 100644
> --- a/fs/jffs2/erase.c
> +++ b/fs/jffs2/erase.c
> @@ -454,6 +454,17 @@ static void jffs2_mark_erased_block(struct jffs2_sb_info *c, struct jffs2_eraseb
>  		jeb->free_size = c->sector_size;
>  		/* FIXME Special case for cleanmarker in empty block */
>  		jffs2_link_node_ref(c, jeb, jeb->offset | REF_NORMAL, c->cleanmarker_size, NULL);
> +		/*
> +		 * XXX: I'm not sure this is correct but it prevents
> +		 * c->free_size from slow leaking under a frequent file
> +		 * overwriting.
> +		 * jffs2_link_node_ref() decreases c->free_size by
> +		 * c->cleanmarker_size but the clean marker space can't
> +		 * be accounted as free space! So we just compensate
> +		 * the difference.
> +		 */
> +		c->free_size += c->cleanmarker_size;
> +		c->used_size -= c->cleanmarker_size;
>  	}
>  
>  	down(&c->erase_free_sem);

What happened to this patch? Just forgotten or was it rejected?

   Jocke


From rpurdie at rpsys.net  Wed Feb  6 05:34:34 2008
From: rpurdie at rpsys.net (Richard Purdie)
Date: Wed, 06 Feb 2008 10:34:34 +0000
Subject: [RFC PATCH 1/3]] Add mtd panic_write function pointer
In-Reply-To: <1201607964.5017.48.camel@localhost.localdomain>
References: <1201607964.5017.48.camel@localhost.localdomain>
Message-ID: <1202294074.8393.1.camel@dax.rpnet.com>

I've now shared these 3 patches as a git branch based on top of the
current mtd-2.6 tree:

git://git.o-hand.com/linux-rpurdie mtd-panicwrite

Cheers,

Richard




From EstherWynn82 at yahoo.co.uk  Wed Feb  6 07:34:59 2008
From: EstherWynn82 at yahoo.co.uk (Canadian Pharmacy)
Date: Wed, 6 Feb 2008 06:34:59 -0600
Subject: no more male pattern hair loss
Message-ID: <000b01c8688a$65333750$f43ffec9@201.254.63.244>

NO MORE MALE PATTERN HAIR LOSS...

Drug Name : Propecia (Finasteride) 

Drug Uses : This medication is used to treat male pattern hair loss. 

How Taken : Take one tablet daily or as directed by your doctor. This drug may be taken with or without meals. This drug usually must be taken regularly for 3 months for the benefits to be noticeable. Once treatment is stopped, any gain in hair quantity will be lost. 

Drug Class and Mechanism

Propecia prevents the conversion of testosterone to dihydrotestosterone (DHT) in the body. DHT is involved in the development of benign prostatic hyperplasia (BPH) and hair loss. 

Please visit our site for more details.

Type the URL below without spaces to visit us

h t t p : / / b u r n h i t . c o m /




From joakim.tjernlund at transmode.se  Sat Feb  2 14:30:08 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Sat, 2 Feb 2008 20:30:08 +0100
Subject: SV: Jffss2_write_super erasing all the blocks
In-Reply-To: <ED07EE9DB42A8945877C9794BA15040801A516FF@xmb-sjc-229.amer.cisco.com>
References: <47A1FD3F.2020102@dave-tech.it>
	<ED07EE9DB42A8945877C9794BA15040801A516FF@xmb-sjc-229.amer.cisco.com>
Message-ID: <000001c865d2$06136110$123a2330$@tjernlund@transmode.se>

This is a long standing issue that I tried to address fairly recently.
Please search the archive and you should find some posts/patch from
me about this.

 Jocke

> -----Ursprungligt meddelande-----
> Fr?n: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] F?r Nikhil
> Bansal (nikbansa)
> Skickat: den 31 januari 2008 20:22
> Till: linux-mtd at lists.infradead.org
> ?mne: Jffss2_write_super erasing all the blocks
> 
> Hi,
> 
> I have a question about JFFS2 fs. In my setup, I am running JFFS2 on AMD
> Spansion flash (NOR flash). What I noticed was that whenever I erase a
> file from my flash, I see that jffs2_write_super function gets called
> which in turn calls jffs2_erase_pending_blocks(0) which goes ahead and
> deletes all the pending blocks. While this erase is going on super block
> is locked and we can not perform any other operation with JFFS2.
> 
> Can someone please explain the logic behind this or if there is
> something I am missing here?
> 
> Thanks,
> Nikhil
> 
> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org
> [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of llandre
> Sent: Thursday, January 31, 2008 8:54 AM
> To: linux-mtd at lists.infradead.org
> Subject: JFFS2: file contents in case of data CRC error
> 
> I have a JFFS2 partition on 32MByte NAND device.
> When reading a specific file - see below for details - JFFS2 reports a
> Data CRC error but function nand_correct_data never returns -1, so I
> assume ECC algorithm is able to correct errors.
> However the file is not equal to the original one that has been written
> to NAND. In fact, in the middle of the file, I see a 4-kByte "hole"
> where all bytes are 0.
> Anybody can help me about understanding if this is the expected
> behaviour of JFFS2?
> Thanks in advance.
> 
> 
> bash-2.05# mount -t jffs2 -o ro /dev/mtdblock0 /mnt/nand0 mtdblock_open
> ok bash-2.05# cp -v /mnt/nand0/f.img /tmp/
> jffs2_get_inode_nodes(): Data CRC failed on node at 0x01d55544: Read
> 0x80b8997f, calculated 0x57f0ea8e `/mnt/nand0/f.img' -> `/tmp/f.img'
> 
> --
> llandre
> 
> DAVE Electronics System House - R&D Department
> web:   http://www.dave.eu
> email: r&d2 at dave-tech.it
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 




From vapier at gentoo.org  Tue Feb  5 20:03:48 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 5 Feb 2008 20:03:48 -0500
Subject: [patch] mtd maps: document MTD_PHYSMAP module name in kconfig
Message-ID: <200802052003.49527.vapier@gentoo.org>

Help out users by telling them the module name in the Kconfig help when using
the MTD_PHYSMAP option.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index a592fc0..2f15330 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -21,6 +21,9 @@ config MTD_PHYSMAP
 	  particular board as well as the bus width, either statically
 	  with config options or at run-time.
 
+	  To compile this driver as a module, choose M here: the
+	  module will be called physmap.
+
 config MTD_PHYSMAP_START
 	hex "Physical start address of flash mapping"
 	depends on MTD_PHYSMAP


From vicky.irobot at gmail.com  Sat Feb  2 13:01:25 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Sat, 02 Feb 2008 23:31:25 +0530
Subject: how to access nand flash from user space
In-Reply-To: <002201c865a2$66fa34c0$65053c0a@telxsi.com>
References: <002201c865a2$66fa34c0$65053c0a@telxsi.com>
Message-ID: <47A4AFF5.8030901@gmail.com>

vishalk wrote:
> Hi,
>
> I have been trying to access nand flash from user space.
> I am using the functions 'mtd_write' and 'mtd_read' in mtdchar.c .
> when I include the mtd.h file, I get compilation errors pertaining to the
> mtd.h file. can someone please tell me how to access these functions 
> from user space.
>   
Hmm...could you paste the error log please. That might be of some help 
to help you.

> Thanks,
> VK  
>
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
>
> Contact your Administrator for further information.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 125 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080202/d8d23fb3/attachment.vcf 

From vicky.irobot at gmail.com  Sat Feb  2 13:05:29 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Sat, 02 Feb 2008 23:35:29 +0530
Subject: how to access nand flash from user space
In-Reply-To: <47A4AFF5.8030901@gmail.com>
References: <002201c865a2$66fa34c0$65053c0a@telxsi.com>
	<47A4AFF5.8030901@gmail.com>
Message-ID: <47A4B0E9.60600@gmail.com>

Max Stirling wrote:
> vishalk wrote:
>> Hi,
>>
>> I have been trying to access nand flash from user space.
>> I am using the functions 'mtd_write' and 'mtd_read' in mtdchar.c .
How do you use mtd_read and mtd_write functions when they are static? 
Are you meaning to say from your user application you open the 
/dev/mtdchar and do a read and write?
>> when I include the mtd.h file, I get compilation errors pertaining to 
>> the
>> mtd.h file. can someone please tell me how to access these functions 
>> from user space.
>>   
> Hmm...could you paste the error log please. That might be of some help 
> to help you.
>
>> Thanks,
>> VK 
>> The information contained in this electronic message and any 
>> attachments to this message are intended for the exclusive use of the 
>> addressee(s) and may contain proprietary, confidential or privileged 
>> information. If you are not the intended recipient, you should not 
>> disseminate, distribute or copy this e-mail. Please notify the sender 
>> immediately and destroy all copies of this message and any 
>> attachments contained in it.
>>
>> Contact your Administrator for further information.
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>   
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 125 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080202/d588d18f/attachment.vcf 

From vicky.irobot at gmail.com  Mon Feb  4 09:19:32 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Mon, 04 Feb 2008 09:19:32 -0500
Subject: mtdblock mount issue
Message-ID: <47A71EF4.2090202@gmail.com>

Hi,

I am trying to mount a cramfs partition from flash. I have the low level 
driver written and MTDBLOCK_RO module is enabled in MTD,

My mount fails with invalid argument error.

/mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument/

I am using a 512 byte NAND flash 16byte spare.

I can find cramfs in /proc/filesytems and the mtdblock is under 
/proc/devices.

I had enabled a few debug statements in the mtdblock_ro and the low 
level nand driver code. I find that the mount is reading 32 pages after 
which it fails with invalid argument. Below is the log.

If you see the log below, the flow of code is

 cramfs_read ==> do_blktrans_request ==> mtdblock_readsect ==> 
mt_read(my low level read function which returns success)

I even dumped the hex of the data being read by my low level driver 
module and found to match the cramfs image that I wrote to the flash.


######################*LOG*##########################

/home # mkdir crfs
/home # cat /proc/devices | grep mtdblock
 31 mtdblock
/home # cat proc/filesystems | grep cramfs
    cramfs
/home #
/home # mknod /dev/mtdblock b 31 0
/home # mount -t cramfs /dev/mtdblock /home/crfs
mount: /dev/mtdblock is write-protected, mounting read-only
cramfs_read
do_blktrans_request nsect:8 block:0
mtdblock_readsect
mt_read offset:0
mt_read status:0
mtdblock_readsect
mt_read offset:512
mt_read status:0
mtdblock_readsect
mt_read offset:1024
mt_read status:0
mtdblock_readsect
mt_read offset:1536
mt_read status:0
mtdblock_readsect
mt_read offset:2048
mt_read status:0
mtdblock_readsect
mt_read offset:2560
mt_read status:0
mtdblock_readsect
mt_read offset:3072
mt_read status:0
mtdblock_readsect
mt_read offset:3584
mt_read status:0
do_blktrans_request nsect:8 block:0
mtdblock_readsect
mt_read offset:4096
mt_read status:0
mtdblock_readsect
mt_read offset:4608
mt_read status:0
mtdblock_readsect
mt_read offset:5120
mt_read status:0
mtdblock_readsect
mt_read offset:5632
mt_read status:0
mtdblock_readsect
mt_read offset:6144
mt_read status:0
mtdblock_readsect
mt_read offset:6656
mt_read status:0
mtdblock_readsect
mt_read offset:7168
mt_read status:0
mtdblock_readsect
mt_read offset:7680
mt_read status:0
do_blktrans_request nsect:8 block:0
mtdblock_readsect
mt_read offset:8192
mt_read status:0
mtdblock_readsect
mt_read offset:8704
mt_read status:0
mtdblock_readsect
mt_read offset:9216
mt_read status:0
mtdblock_readsect
mt_read offset:9728
mt_read status:0
mtdblock_readsect
mt_read offset:10240
mt_read status:0
mtdblock_readsect
mt_read offset:10752
mt_read status:0
mtdblock_readsect
mt_read offset:11264
mt_read status:0
mtdblock_readsect
mt_read offset:11776
mt_read status:0
do_blktrans_request nsect:8 block:0
mtdblock_readsect
mt_read offset:12288
mt_read status:0
mtdblock_readsect
mt_read offset:12800
mt_read status:0
mtdblock_readsect
mt_read offset:13312
mt_read status:0
mtdblock_readsect
mt_read offset:13824
mt_read status:0
mtdblock_readsect
mt_read offset:14336
mt_read status:0
mtdblock_readsect
mt_read offset:14848
mt_read status:0
mtdblock_readsect
mt_read offset:15360
mt_read status:0
mtdblock_readsect
mt_read offset:15872
mt_read status:0
cramfs_read
mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument
/home #

########################################################


I hope I have provided the maximum information. Looking forward for some 
help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 48 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080204/12869aed/attachment.vcf 

From rgadams at motorola.com  Wed Feb  6 11:20:06 2008
From: rgadams at motorola.com (Adams Richard-W36112)
Date: Wed, 6 Feb 2008 11:20:06 -0500
Subject: mtdblock mount issue
In-Reply-To: <47A71EF4.2090202@gmail.com>
References: <47A71EF4.2090202@gmail.com>
Message-ID: <A2EC06CB0E393B4C8EB220B286B7083E058EFCAC@ct11exm60.ds.mot.com>

> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org 
> [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of 
> Max Stirling
> Sent: Monday, February 04, 2008 6:20 AM
> To: linux-mtd at lists.infradead.org
> Subject: mtdblock mount issue
> 
> Hi,
> 
> I am trying to mount a cramfs partition from flash. I have 
> the low level driver written and MTDBLOCK_RO module is enabled in MTD,
> 
> My mount fails with invalid argument error.
> 
> /mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument/
> 
> I am using a 512 byte NAND flash 16byte spare.
> 
> I can find cramfs in /proc/filesytems and the mtdblock is 
> under /proc/devices.
> 
> I had enabled a few debug statements in the mtdblock_ro and 
> the low level nand driver code. I find that the mount is 
> reading 32 pages after which it fails with invalid argument. 
> Below is the log.
> 
> If you see the log below, the flow of code is
> 
>  cramfs_read ==> do_blktrans_request ==> mtdblock_readsect 
> ==> mt_read(my low level read function which returns success)
> 
> I even dumped the hex of the data being read by my low level 
> driver module and found to match the cramfs image that I 
> wrote to the flash.
> 
> 
> ######################*LOG*##########################
> 
> /home # mkdir crfs
> /home # cat /proc/devices | grep mtdblock
>  31 mtdblock
> /home # cat proc/filesystems | grep cramfs
>     cramfs
> /home #
> /home # mknod /dev/mtdblock b 31 0
> /home # mount -t cramfs /dev/mtdblock /home/crfs
> mount: /dev/mtdblock is write-protected, mounting read-only
> cramfs_read
> do_blktrans_request nsect:8 block:0
> mtdblock_readsect
> mt_read offset:0
> mt_read status:0
> mtdblock_readsect
> mt_read offset:512
> mt_read status:0
> mtdblock_readsect
> mt_read offset:1024
> mt_read status:0
> mtdblock_readsect
> mt_read offset:1536
> mt_read status:0
> mtdblock_readsect
> mt_read offset:2048
> mt_read status:0
> mtdblock_readsect
> mt_read offset:2560
> mt_read status:0
> mtdblock_readsect
> mt_read offset:3072
> mt_read status:0
> mtdblock_readsect
> mt_read offset:3584
> mt_read status:0
> do_blktrans_request nsect:8 block:0
> mtdblock_readsect
> mt_read offset:4096
> mt_read status:0
> mtdblock_readsect
> mt_read offset:4608
> mt_read status:0
> mtdblock_readsect
> mt_read offset:5120
> mt_read status:0
> mtdblock_readsect
> mt_read offset:5632
> mt_read status:0
> mtdblock_readsect
> mt_read offset:6144
> mt_read status:0
> mtdblock_readsect
> mt_read offset:6656
> mt_read status:0
> mtdblock_readsect
> mt_read offset:7168
> mt_read status:0
> mtdblock_readsect
> mt_read offset:7680
> mt_read status:0
> do_blktrans_request nsect:8 block:0
> mtdblock_readsect
> mt_read offset:8192
> mt_read status:0
> mtdblock_readsect
> mt_read offset:8704
> mt_read status:0
> mtdblock_readsect
> mt_read offset:9216
> mt_read status:0
> mtdblock_readsect
> mt_read offset:9728
> mt_read status:0
> mtdblock_readsect
> mt_read offset:10240
> mt_read status:0
> mtdblock_readsect
> mt_read offset:10752
> mt_read status:0
> mtdblock_readsect
> mt_read offset:11264
> mt_read status:0
> mtdblock_readsect
> mt_read offset:11776
> mt_read status:0
> do_blktrans_request nsect:8 block:0
> mtdblock_readsect
> mt_read offset:12288
> mt_read status:0
> mtdblock_readsect
> mt_read offset:12800
> mt_read status:0
> mtdblock_readsect
> mt_read offset:13312
> mt_read status:0
> mtdblock_readsect
> mt_read offset:13824
> mt_read status:0
> mtdblock_readsect
> mt_read offset:14336
> mt_read status:0
> mtdblock_readsect
> mt_read offset:14848
> mt_read status:0
> mtdblock_readsect
> mt_read offset:15360
> mt_read status:0
> mtdblock_readsect
> mt_read offset:15872
> mt_read status:0
> cramfs_read
> mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument
> /home #
> 
> ########################################################
> 
> 
> I hope I have provided the maximum information. Looking 
> forward for some 
> help.
> 

You need to mount the file system as read only. I believe I've seen this
error when I've mounted a squashfs (also a read only file system)
without specifying the read only option.

Try this command:
mount /dev/mtdblock /home/crfs  -t cramfs -o ro

Rick


From lost404 at gmail.com  Wed Feb  6 13:48:55 2008
From: lost404 at gmail.com (Damir Shayhutdinov)
Date: Wed, 6 Feb 2008 21:48:55 +0300
Subject: [PATCH] [JFFS2] Fix free space leaking
In-Reply-To: <1202293219.25864.45.camel@gentoo-jocke.transmode.se>
References: <20071113102323.GA5933@damir.rnd.local>
	<1202293219.25864.45.camel@gentoo-jocke.transmode.se>
Message-ID: <679044850802061048n3ed4dbf5g33cef09ee22987de@mail.gmail.com>

> What happened to this patch? Just forgotten or was it rejected?
Just forgotten, it seems. Anyway, I tested it in Linux 2.6.22 and it works.


From scottwood at freescale.com  Wed Feb  6 16:36:21 2008
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 6 Feb 2008 15:36:21 -0600
Subject: [PATCH] Freescale enhanced Local Bus Controller FCM NAND support.
Message-ID: <20080206213621.GA17028@loki.buserror.net>

Signed-off-by: Nick Spence <nick.spence at freescale.com>
Signed-off-by: Scott Wood <scottwood at freescale.com>
---
 drivers/mtd/nand/Kconfig         |    9 +
 drivers/mtd/nand/Makefile        |    1 +
 drivers/mtd/nand/fsl_elbc_nand.c | 1244 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 1254 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/fsl_elbc_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 0a840d5..4a3c675 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -321,4 +321,13 @@ config MTD_NAND_ORION
 	  No board specific support is done by this driver, each board
 	  must advertise a platform_device for the driver to attach.
 
+config MTD_NAND_FSL_ELBC
+	tristate "NAND support for Freescale eLBC controllers"
+	depends on MTD_NAND && PPC_OF
+	help
+	  Various Freescale chips, including the 8313, include a NAND Flash
+	  Controller Module with built-in hardware ECC capabilities.
+	  Enabling this option will enable you to use this to control
+	  external NAND devices.
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index e35f5ea..80d575e 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -31,5 +31,6 @@ obj-$(CONFIG_MTD_NAND_PLATFORM)		+= plat_nand.o
 obj-$(CONFIG_MTD_ALAUDA)		+= alauda.o
 obj-$(CONFIG_MTD_NAND_PASEMI)		+= pasemi_nand.o
 obj-$(CONFIG_MTD_NAND_ORION)		+= orion_nand.o
+obj-$(CONFIG_MTD_NAND_FSL_ELBC)		+= fsl_elbc_nand.o
 
 nand-objs := nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
new file mode 100644
index 0000000..b025dfe
--- /dev/null
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -0,0 +1,1244 @@
+/* Freescale Enhanced Local Bus Controller NAND driver
+ *
+ * Copyright (c) 2006-2007 Freescale Semiconductor
+ *
+ * Authors: Nick Spence <nick.spence at freescale.com>,
+ *          Scott Wood <scottwood at freescale.com>
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+
+
+#define MAX_BANKS 8
+#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */
+#define FCM_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait for FCM */
+
+struct elbc_bank {
+	__be32 br;             /**< Base Register  */
+#define BR_BA           0xFFFF8000
+#define BR_BA_SHIFT             15
+#define BR_PS           0x00001800
+#define BR_PS_SHIFT             11
+#define BR_PS_8         0x00000800  /* Port Size 8 bit */
+#define BR_PS_16        0x00001000  /* Port Size 16 bit */
+#define BR_PS_32        0x00001800  /* Port Size 32 bit */
+#define BR_DECC         0x00000600
+#define BR_DECC_SHIFT            9
+#define BR_DECC_OFF     0x00000000  /* HW ECC checking and generation off */
+#define BR_DECC_CHK     0x00000200  /* HW ECC checking on, generation off */
+#define BR_DECC_CHK_GEN 0x00000400  /* HW ECC checking and generation on */
+#define BR_WP           0x00000100
+#define BR_WP_SHIFT              8
+#define BR_MSEL         0x000000E0
+#define BR_MSEL_SHIFT            5
+#define BR_MS_GPCM      0x00000000  /* GPCM */
+#define BR_MS_FCM       0x00000020  /* FCM */
+#define BR_MS_SDRAM     0x00000060  /* SDRAM */
+#define BR_MS_UPMA      0x00000080  /* UPMA */
+#define BR_MS_UPMB      0x000000A0  /* UPMB */
+#define BR_MS_UPMC      0x000000C0  /* UPMC */
+#define BR_V            0x00000001
+#define BR_V_SHIFT               0
+#define BR_RES          ~(BR_BA|BR_PS|BR_DECC|BR_WP|BR_MSEL|BR_V)
+
+	__be32 or;             /**< Base Register  */
+#define OR0 0x5004
+#define OR1 0x500C
+#define OR2 0x5014
+#define OR3 0x501C
+#define OR4 0x5024
+#define OR5 0x502C
+#define OR6 0x5034
+#define OR7 0x503C
+
+#define OR_FCM_AM               0xFFFF8000
+#define OR_FCM_AM_SHIFT                 15
+#define OR_FCM_BCTLD            0x00001000
+#define OR_FCM_BCTLD_SHIFT              12
+#define OR_FCM_PGS              0x00000400
+#define OR_FCM_PGS_SHIFT                10
+#define OR_FCM_CSCT             0x00000200
+#define OR_FCM_CSCT_SHIFT                9
+#define OR_FCM_CST              0x00000100
+#define OR_FCM_CST_SHIFT                 8
+#define OR_FCM_CHT              0x00000080
+#define OR_FCM_CHT_SHIFT                 7
+#define OR_FCM_SCY              0x00000070
+#define OR_FCM_SCY_SHIFT                 4
+#define OR_FCM_SCY_1            0x00000010
+#define OR_FCM_SCY_2            0x00000020
+#define OR_FCM_SCY_3            0x00000030
+#define OR_FCM_SCY_4            0x00000040
+#define OR_FCM_SCY_5            0x00000050
+#define OR_FCM_SCY_6            0x00000060
+#define OR_FCM_SCY_7            0x00000070
+#define OR_FCM_RST              0x00000008
+#define OR_FCM_RST_SHIFT                 3
+#define OR_FCM_TRLX             0x00000004
+#define OR_FCM_TRLX_SHIFT                2
+#define OR_FCM_EHTR             0x00000002
+#define OR_FCM_EHTR_SHIFT                1
+};
+
+struct elbc_regs {
+	struct elbc_bank bank[8];
+	u8 res0[0x28];
+	__be32 mar;             /**< UPM Address Register */
+	u8 res1[0x4];
+	__be32 mamr;            /**< UPMA Mode Register */
+	__be32 mbmr;            /**< UPMB Mode Register */
+	__be32 mcmr;            /**< UPMC Mode Register */
+	u8 res2[0x8];
+	__be32 mrtpr;           /**< Memory Refresh Timer Prescaler Register */
+	__be32 mdr;             /**< UPM Data Register */
+	u8 res3[0x4];
+	__be32 lsor;            /**< Special Operation Initiation Register */
+	__be32 lsdmr;           /**< SDRAM Mode Register */
+	u8 res4[0x8];
+	__be32 lurt;            /**< UPM Refresh Timer */
+	__be32 lsrt;            /**< SDRAM Refresh Timer */
+	u8 res5[0x8];
+	__be32 ltesr;           /**< Transfer Error Status Register */
+#define LTESR_BM   0x80000000
+#define LTESR_FCT  0x40000000
+#define LTESR_PAR  0x20000000
+#define LTESR_WP   0x04000000
+#define LTESR_ATMW 0x00800000
+#define LTESR_ATMR 0x00400000
+#define LTESR_CS   0x00080000
+#define LTESR_CC   0x00000001
+#define LTESR_NAND_MASK (LTESR_FCT | LTESR_PAR | LTESR_CC)
+	__be32 ltedr;           /**< Transfer Error Disable Register */
+	__be32 lteir;           /**< Transfer Error Interrupt Register */
+	__be32 lteatr;          /**< Transfer Error Attributes Register */
+	__be32 ltear;           /**< Transfer Error Address Register */
+	u8 res6[0xC];
+	__be32 lbcr;            /**< Configuration Register */
+#define LBCR_LDIS  0x80000000
+#define LBCR_LDIS_SHIFT    31
+#define LBCR_BCTLC 0x00C00000
+#define LBCR_BCTLC_SHIFT   22
+#define LBCR_AHD   0x00200000
+#define LBCR_LPBSE 0x00020000
+#define LBCR_LPBSE_SHIFT   17
+#define LBCR_EPAR  0x00010000
+#define LBCR_EPAR_SHIFT    16
+#define LBCR_BMT   0x0000FF00
+#define LBCR_BMT_SHIFT      8
+#define LBCR_INIT  0x00040000
+	__be32 lcrr;            /**< Clock Ratio Register */
+#define LCRR_DBYP    0x80000000
+#define LCRR_DBYP_SHIFT      31
+#define LCRR_BUFCMDC 0x30000000
+#define LCRR_BUFCMDC_SHIFT   28
+#define LCRR_ECL     0x03000000
+#define LCRR_ECL_SHIFT       24
+#define LCRR_EADC    0x00030000
+#define LCRR_EADC_SHIFT      16
+#define LCRR_CLKDIV  0x0000000F
+#define LCRR_CLKDIV_SHIFT     0
+	u8 res7[0x8];
+	__be32 fmr;             /**< Flash Mode Register */
+#define FMR_CWTO     0x0000F000
+#define FMR_CWTO_SHIFT       12
+#define FMR_BOOT     0x00000800
+#define FMR_ECCM     0x00000100
+#define FMR_AL       0x00000030
+#define FMR_AL_SHIFT          4
+#define FMR_OP       0x00000003
+#define FMR_OP_SHIFT          0
+	__be32 fir;             /**< Flash Instruction Register */
+#define FIR_OP0      0xF0000000
+#define FIR_OP0_SHIFT        28
+#define FIR_OP1      0x0F000000
+#define FIR_OP1_SHIFT        24
+#define FIR_OP2      0x00F00000
+#define FIR_OP2_SHIFT        20
+#define FIR_OP3      0x000F0000
+#define FIR_OP3_SHIFT        16
+#define FIR_OP4      0x0000F000
+#define FIR_OP4_SHIFT        12
+#define FIR_OP5      0x00000F00
+#define FIR_OP5_SHIFT         8
+#define FIR_OP6      0x000000F0
+#define FIR_OP6_SHIFT         4
+#define FIR_OP7      0x0000000F
+#define FIR_OP7_SHIFT         0
+#define FIR_OP_NOP   0x0	/* No operation and end of sequence */
+#define FIR_OP_CA    0x1        /* Issue current column address */
+#define FIR_OP_PA    0x2        /* Issue current block+page address */
+#define FIR_OP_UA    0x3        /* Issue user defined address */
+#define FIR_OP_CM0   0x4        /* Issue command from FCR[CMD0] */
+#define FIR_OP_CM1   0x5        /* Issue command from FCR[CMD1] */
+#define FIR_OP_CM2   0x6        /* Issue command from FCR[CMD2] */
+#define FIR_OP_CM3   0x7        /* Issue command from FCR[CMD3] */
+#define FIR_OP_WB    0x8        /* Write FBCR bytes from FCM buffer */
+#define FIR_OP_WS    0x9        /* Write 1 or 2 bytes from MDR[AS] */
+#define FIR_OP_RB    0xA        /* Read FBCR bytes to FCM buffer */
+#define FIR_OP_RS    0xB        /* Read 1 or 2 bytes to MDR[AS] */
+#define FIR_OP_CW0   0xC        /* Wait then issue FCR[CMD0] */
+#define FIR_OP_CW1   0xD        /* Wait then issue FCR[CMD1] */
+#define FIR_OP_RBW   0xE        /* Wait then read FBCR bytes */
+#define FIR_OP_RSW   0xE        /* Wait then read 1 or 2 bytes */
+	__be32 fcr;             /**< Flash Command Register */
+#define FCR_CMD0     0xFF000000
+#define FCR_CMD0_SHIFT       24
+#define FCR_CMD1     0x00FF0000
+#define FCR_CMD1_SHIFT       16
+#define FCR_CMD2     0x0000FF00
+#define FCR_CMD2_SHIFT        8
+#define FCR_CMD3     0x000000FF
+#define FCR_CMD3_SHIFT        0
+	__be32 fbar;            /**< Flash Block Address Register */
+#define FBAR_BLK     0x00FFFFFF
+	__be32 fpar;            /**< Flash Page Address Register */
+#define FPAR_SP_PI   0x00007C00
+#define FPAR_SP_PI_SHIFT     10
+#define FPAR_SP_MS   0x00000200
+#define FPAR_SP_CI   0x000001FF
+#define FPAR_SP_CI_SHIFT      0
+#define FPAR_LP_PI   0x0003F000
+#define FPAR_LP_PI_SHIFT     12
+#define FPAR_LP_MS   0x00000800
+#define FPAR_LP_CI   0x000007FF
+#define FPAR_LP_CI_SHIFT      0
+	__be32 fbcr;            /**< Flash Byte Count Register */
+#define FBCR_BC      0x00000FFF
+	u8 res11[0x8];
+	u8 res8[0xF00];
+};
+
+struct fsl_elbc_ctrl;
+
+/* mtd information per set */
+
+struct fsl_elbc_mtd {
+	struct mtd_info mtd;
+	struct nand_chip chip;
+	struct fsl_elbc_ctrl *ctrl;
+
+	struct device *dev;
+	int bank;               /* Chip select bank number           */
+	u8 __iomem *vbase;      /* Chip select base virtual address  */
+	int page_size;          /* NAND page size (0=512, 1=2048)    */
+	unsigned int fmr;       /* FCM Flash Mode Register value     */
+};
+
+/* overview of the fsl elbc controller */
+
+struct fsl_elbc_ctrl {
+	struct nand_hw_control controller;
+	struct fsl_elbc_mtd *chips[MAX_BANKS];
+
+	/* device info */
+	struct device *dev;
+	struct elbc_regs __iomem *regs;
+	int irq;
+	wait_queue_head_t irq_wait;
+	unsigned int irq_status; /* status read from LTESR by irq handler */
+	u8 __iomem *addr;        /* Address of assigned FCM buffer        */
+	unsigned int page;       /* Last page written to / read from      */
+	unsigned int read_bytes; /* Number of bytes read during command   */
+	unsigned int column;     /* Saved column from SEQIN               */
+	unsigned int index;      /* Pointer to next byte to 'read'        */
+	unsigned int status;     /* status read from LTESR after last op  */
+	unsigned int mdr;        /* UPM/FCM Data Register value           */
+	unsigned int use_mdr;    /* Non zero if the MDR is to be set      */
+	unsigned int oob;        /* Non zero if operating on OOB data     */
+	char *oob_poi;           /* Place to write ECC after read back    */
+};
+
+/* These map to the positions used by the FCM hardware ECC generator */
+
+/* Small Page FLASH with FMR[ECCM] = 0 */
+static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = {
+	.eccbytes = 3,
+	.eccpos = {6, 7, 8},
+	.oobfree = { {0, 5}, {9, 7} },
+	.oobavail = 12,
+};
+
+/* Small Page FLASH with FMR[ECCM] = 1 */
+static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = {
+	.eccbytes = 3,
+	.eccpos = {8, 9, 10},
+	.oobfree = { {0, 5}, {6, 2}, {11, 5} },
+	.oobavail = 12,
+};
+
+/* Large Page FLASH with FMR[ECCM] = 0 */
+static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = {
+	.eccbytes = 12,
+	.eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56},
+	.oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} },
+	.oobavail = 48,
+};
+
+/* Large Page FLASH with FMR[ECCM] = 1 */
+static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
+	.eccbytes = 12,
+	.eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58},
+	.oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} },
+	.oobavail = 48,
+};
+
+/*=================================*/
+
+/*
+ * Set up the FCM hardware block and page address fields, and the fcm
+ * structure addr field to point to the correct FCM buffer in memory
+ */
+static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+	int buf_num;
+
+	ctrl->page = page_addr;
+
+	out_be32(&lbc->fbar,
+	         page_addr >> (chip->phys_erase_shift - chip->page_shift));
+
+	if (priv->page_size) {
+		out_be32(&lbc->fpar,
+		         ((page_addr << FPAR_LP_PI_SHIFT) & FPAR_LP_PI) |
+		         (oob ? FPAR_LP_MS : 0) | column);
+		buf_num = (page_addr & 1) << 2;
+	} else {
+		out_be32(&lbc->fpar,
+		         ((page_addr << FPAR_SP_PI_SHIFT) & FPAR_SP_PI) |
+		         (oob ? FPAR_SP_MS : 0) | column);
+		buf_num = page_addr & 7;
+	}
+
+	ctrl->addr = priv->vbase + buf_num * 1024;
+	ctrl->index = column;
+
+	/* for OOB data point to the second half of the buffer */
+	if (oob)
+		ctrl->index += priv->page_size ? 2048 : 512;
+
+	dev_vdbg(ctrl->dev, "set_addr: bank=%d, ctrl->addr=0x%p (0x%p), "
+	                    "index %x, pes %d ps %d\n",
+	         buf_num, ctrl->addr, priv->vbase, ctrl->index,
+	         chip->phys_erase_shift, chip->page_shift);
+}
+
+/*
+ * execute FCM command and wait for it to complete
+ */
+static int fsl_elbc_run_command(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+
+	/* Setup the FMR[OP] to execute without write protection */
+	out_be32(&lbc->fmr, priv->fmr | 3);
+	if (ctrl->use_mdr)
+		out_be32(&lbc->mdr, ctrl->mdr);
+
+	dev_vdbg(ctrl->dev,
+	         "fsl_elbc_run_command: fmr=%08x fir=%08x fcr=%08x\n",
+	         in_be32(&lbc->fmr), in_be32(&lbc->fir), in_be32(&lbc->fcr));
+	dev_vdbg(ctrl->dev,
+	         "fsl_elbc_run_command: fbar=%08x fpar=%08x "
+	         "fbcr=%08x bank=%d\n",
+	         in_be32(&lbc->fbar), in_be32(&lbc->fpar),
+	         in_be32(&lbc->fbcr), priv->bank);
+
+	/* execute special operation */
+	out_be32(&lbc->lsor, priv->bank);
+
+	/* wait for FCM complete flag or timeout */
+	ctrl->irq_status = 0;
+	wait_event_timeout(ctrl->irq_wait, ctrl->irq_status,
+	                   FCM_TIMEOUT_MSECS * HZ/1000);
+	ctrl->status = ctrl->irq_status;
+
+	/* store mdr value in case it was needed */
+	if (ctrl->use_mdr)
+		ctrl->mdr = in_be32(&lbc->mdr);
+
+	ctrl->use_mdr = 0;
+
+	dev_vdbg(ctrl->dev,
+	         "fsl_elbc_run_command: stat=%08x mdr=%08x fmr=%08x\n",
+	         ctrl->status, ctrl->mdr, in_be32(&lbc->fmr));
+
+	/* returns 0 on success otherwise non-zero) */
+	return ctrl->status == LTESR_CC ? 0 : -EIO;
+}
+
+static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+{
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+
+	if (priv->page_size) {
+		out_be32(&lbc->fir,
+		         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+		         (FIR_OP_CA  << FIR_OP1_SHIFT) |
+		         (FIR_OP_PA  << FIR_OP2_SHIFT) |
+		         (FIR_OP_CW1 << FIR_OP3_SHIFT) |
+		         (FIR_OP_RBW << FIR_OP4_SHIFT));
+
+		out_be32(&lbc->fcr, (NAND_CMD_READ0 << FCR_CMD0_SHIFT) |
+		                    (NAND_CMD_READSTART << FCR_CMD1_SHIFT));
+	} else {
+		out_be32(&lbc->fir,
+		         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+		         (FIR_OP_CA  << FIR_OP1_SHIFT) |
+		         (FIR_OP_PA  << FIR_OP2_SHIFT) |
+		         (FIR_OP_RBW << FIR_OP3_SHIFT));
+
+		if (oob)
+			out_be32(&lbc->fcr, NAND_CMD_READOOB << FCR_CMD0_SHIFT);
+		else
+			out_be32(&lbc->fcr, NAND_CMD_READ0 << FCR_CMD0_SHIFT);
+	}
+}
+
+/* cmdfunc send commands to the FCM */
+static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
+                             int column, int page_addr)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+
+	ctrl->use_mdr = 0;
+
+	/* clear the read buffer */
+	ctrl->read_bytes = 0;
+	if (command != NAND_CMD_PAGEPROG)
+		ctrl->index = 0;
+
+	switch (command) {
+	/* READ0 and READ1 read the entire buffer to use hardware ECC. */
+	case NAND_CMD_READ1:
+		column += 256;
+
+	/* fall-through */
+	case NAND_CMD_READ0:
+		dev_dbg(ctrl->dev,
+		        "fsl_elbc_cmdfunc: NAND_CMD_READ0, page_addr:"
+		        " 0x%x, column: 0x%x.\n", page_addr, column);
+
+
+		out_be32(&lbc->fbcr, 0); /* read entire page to enable ECC */
+		set_addr(mtd, 0, page_addr, 0);
+
+		ctrl->read_bytes = mtd->writesize + mtd->oobsize;
+		ctrl->index += column;
+
+		fsl_elbc_do_read(chip, 0);
+		fsl_elbc_run_command(mtd);
+		return;
+
+	/* READOOB reads only the OOB because no ECC is performed. */
+	case NAND_CMD_READOOB:
+		dev_vdbg(ctrl->dev,
+		         "fsl_elbc_cmdfunc: NAND_CMD_READOOB, page_addr:"
+			 " 0x%x, column: 0x%x.\n", page_addr, column);
+
+		out_be32(&lbc->fbcr, mtd->oobsize - column);
+		set_addr(mtd, column, page_addr, 1);
+
+		ctrl->read_bytes = mtd->writesize + mtd->oobsize;
+
+		fsl_elbc_do_read(chip, 1);
+		fsl_elbc_run_command(mtd);
+		return;
+
+	/* READID must read all 5 possible bytes while CEB is active */
+	case NAND_CMD_READID:
+		dev_vdbg(ctrl->dev, "fsl_elbc_cmdfunc: NAND_CMD_READID.\n");
+
+		out_be32(&lbc->fir, (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+		                    (FIR_OP_UA  << FIR_OP1_SHIFT) |
+		                    (FIR_OP_RBW << FIR_OP2_SHIFT));
+		out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT);
+		/* 5 bytes for manuf, device and exts */
+		out_be32(&lbc->fbcr, 5);
+		ctrl->read_bytes = 5;
+		ctrl->use_mdr = 1;
+		ctrl->mdr = 0;
+
+		set_addr(mtd, 0, 0, 0);
+		fsl_elbc_run_command(mtd);
+		return;
+
+	/* ERASE1 stores the block and page address */
+	case NAND_CMD_ERASE1:
+		dev_vdbg(ctrl->dev,
+		         "fsl_elbc_cmdfunc: NAND_CMD_ERASE1, "
+		         "page_addr: 0x%x.\n", page_addr);
+		set_addr(mtd, 0, page_addr, 0);
+		return;
+
+	/* ERASE2 uses the block and page address from ERASE1 */
+	case NAND_CMD_ERASE2:
+		dev_vdbg(ctrl->dev, "fsl_elbc_cmdfunc: NAND_CMD_ERASE2.\n");
+
+		out_be32(&lbc->fir,
+		         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+		         (FIR_OP_PA  << FIR_OP1_SHIFT) |
+		         (FIR_OP_CM1 << FIR_OP2_SHIFT));
+
+		out_be32(&lbc->fcr,
+		         (NAND_CMD_ERASE1 << FCR_CMD0_SHIFT) |
+		         (NAND_CMD_ERASE2 << FCR_CMD1_SHIFT));
+
+		out_be32(&lbc->fbcr, 0);
+		ctrl->read_bytes = 0;
+
+		fsl_elbc_run_command(mtd);
+		return;
+
+	/* SEQIN sets up the addr buffer and all registers except the length */
+	case NAND_CMD_SEQIN: {
+		__be32 fcr;
+		dev_vdbg(ctrl->dev,
+		         "fsl_elbc_cmdfunc: NAND_CMD_SEQIN/PAGE_PROG, "
+		         "page_addr: 0x%x, column: 0x%x.\n",
+		         page_addr, column);
+
+		ctrl->column = column;
+		ctrl->oob = 0;
+
+		fcr = (NAND_CMD_PAGEPROG << FCR_CMD1_SHIFT) |
+		      (NAND_CMD_SEQIN << FCR_CMD2_SHIFT);
+
+		if (priv->page_size) {
+			out_be32(&lbc->fir,
+			         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+			         (FIR_OP_CA  << FIR_OP1_SHIFT) |
+			         (FIR_OP_PA  << FIR_OP2_SHIFT) |
+			         (FIR_OP_WB  << FIR_OP3_SHIFT) |
+			         (FIR_OP_CW1 << FIR_OP4_SHIFT));
+
+			fcr |= NAND_CMD_READ0 << FCR_CMD0_SHIFT;
+		} else {
+			out_be32(&lbc->fir,
+			         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+			         (FIR_OP_CM2 << FIR_OP1_SHIFT) |
+			         (FIR_OP_CA  << FIR_OP2_SHIFT) |
+			         (FIR_OP_PA  << FIR_OP3_SHIFT) |
+			         (FIR_OP_WB  << FIR_OP4_SHIFT) |
+			         (FIR_OP_CW1 << FIR_OP5_SHIFT));
+
+			if (column >= mtd->writesize) {
+				/* OOB area --> READOOB */
+				column -= mtd->writesize;
+				fcr |= NAND_CMD_READOOB << FCR_CMD0_SHIFT;
+				ctrl->oob = 1;
+			} else if (column < 256) {
+				/* First 256 bytes --> READ0 */
+				fcr |= NAND_CMD_READ0 << FCR_CMD0_SHIFT;
+			} else {
+				/* Second 256 bytes --> READ1 */
+				fcr |= NAND_CMD_READ1 << FCR_CMD0_SHIFT;
+			}
+		}
+
+		out_be32(&lbc->fcr, fcr);
+		set_addr(mtd, column, page_addr, ctrl->oob);
+		return;
+	}
+
+	/* PAGEPROG reuses all of the setup from SEQIN and adds the length */
+	case NAND_CMD_PAGEPROG: {
+		int full_page;
+		dev_vdbg(ctrl->dev,
+		         "fsl_elbc_cmdfunc: NAND_CMD_PAGEPROG "
+		         "writing %d bytes.\n", ctrl->index);
+
+		/* if the write did not start at 0 or is not a full page
+		 * then set the exact length, otherwise use a full page
+		 * write so the HW generates the ECC.
+		 */
+		if (ctrl->oob || ctrl->column != 0 ||
+		    ctrl->index != mtd->writesize + mtd->oobsize) {
+			out_be32(&lbc->fbcr, ctrl->index);
+			full_page = 0;
+		} else {
+			out_be32(&lbc->fbcr, 0);
+			full_page = 1;
+		}
+
+		fsl_elbc_run_command(mtd);
+
+		/* Read back the page in order to fill in the ECC for the
+		 * caller.  Is this really needed?
+		 */
+		if (full_page && ctrl->oob_poi) {
+			out_be32(&lbc->fbcr, 3);
+			set_addr(mtd, 6, page_addr, 1);
+
+			ctrl->read_bytes = mtd->writesize + 9;
+
+			fsl_elbc_do_read(chip, 1);
+			fsl_elbc_run_command(mtd);
+
+			memcpy_fromio(ctrl->oob_poi + 6,
+			              &ctrl->addr[ctrl->index], 3);
+			ctrl->index += 3;
+		}
+
+		ctrl->oob_poi = NULL;
+		return;
+	}
+
+	/* CMD_STATUS must read the status byte while CEB is active */
+	/* Note - it does not wait for the ready line */
+	case NAND_CMD_STATUS:
+		out_be32(&lbc->fir,
+		         (FIR_OP_CM0 << FIR_OP0_SHIFT) |
+		         (FIR_OP_RBW << FIR_OP1_SHIFT));
+		out_be32(&lbc->fcr, NAND_CMD_STATUS << FCR_CMD0_SHIFT);
+		out_be32(&lbc->fbcr, 1);
+		set_addr(mtd, 0, 0, 0);
+		ctrl->read_bytes = 1;
+
+		fsl_elbc_run_command(mtd);
+
+		/* The chip always seems to report that it is
+		 * write-protected, even when it is not.
+		 */
+		setbits8(ctrl->addr, NAND_STATUS_WP);
+		return;
+
+	/* RESET without waiting for the ready line */
+	case NAND_CMD_RESET:
+		dev_dbg(ctrl->dev, "fsl_elbc_cmdfunc: NAND_CMD_RESET.\n");
+		out_be32(&lbc->fir, FIR_OP_CM0 << FIR_OP0_SHIFT);
+		out_be32(&lbc->fcr, NAND_CMD_RESET << FCR_CMD0_SHIFT);
+		fsl_elbc_run_command(mtd);
+		return;
+
+	default:
+		dev_err(ctrl->dev,
+		        "fsl_elbc_cmdfunc: error, unsupported command 0x%x.\n",
+		        command);
+	}
+}
+
+static void fsl_elbc_select_chip(struct mtd_info *mtd, int chip)
+{
+	/* The hardware does not seem to support multiple
+	 * chips per bank.
+	 */
+}
+
+/*
+ * Write buf to the FCM Controller Data Buffer
+ */
+static void fsl_elbc_write_buf(struct mtd_info *mtd, const u8 *buf, int len)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	unsigned int bufsize = mtd->writesize + mtd->oobsize;
+
+	if (len < 0) {
+		dev_err(ctrl->dev, "write_buf of %d bytes", len);
+		ctrl->status = 0;
+		return;
+	}
+
+	if ((unsigned int)len > bufsize - ctrl->index) {
+		dev_err(ctrl->dev,
+		        "write_buf beyond end of buffer "
+		        "(%d requested, %u available)\n",
+		        len, bufsize - ctrl->index);
+		len = bufsize - ctrl->index;
+	}
+
+	memcpy_toio(&ctrl->addr[ctrl->index], buf, len);
+	ctrl->index += len;
+}
+
+/*
+ * read a byte from either the FCM hardware buffer if it has any data left
+ * otherwise issue a command to read a single byte.
+ */
+static u8 fsl_elbc_read_byte(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+
+	/* If there are still bytes in the FCM, then use the next byte. */
+	if (ctrl->index < ctrl->read_bytes)
+		return in_8(&ctrl->addr[ctrl->index++]);
+
+	dev_err(ctrl->dev, "read_byte beyond end of buffer\n");
+	return ERR_BYTE;
+}
+
+/*
+ * Read from the FCM Controller Data Buffer
+ */
+static void fsl_elbc_read_buf(struct mtd_info *mtd, u8 *buf, int len)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	int avail;
+
+	if (len < 0)
+		return;
+
+	avail = min((unsigned int)len, ctrl->read_bytes - ctrl->index);
+	memcpy_fromio(buf, &ctrl->addr[ctrl->index], avail);
+	ctrl->index += avail;
+
+	if (len > avail)
+		dev_err(ctrl->dev,
+		        "read_buf beyond end of buffer "
+		        "(%d requested, %d available)\n",
+		        len, avail);
+}
+
+/*
+ * Verify buffer against the FCM Controller Data Buffer
+ */
+static int fsl_elbc_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	int i;
+
+	if (len < 0) {
+		dev_err(ctrl->dev, "write_buf of %d bytes", len);
+		return -EINVAL;
+	}
+
+	if ((unsigned int)len > ctrl->read_bytes - ctrl->index) {
+		dev_err(ctrl->dev,
+		        "verify_buf beyond end of buffer "
+		        "(%d requested, %u available)\n",
+		        len, ctrl->read_bytes - ctrl->index);
+
+		ctrl->index = ctrl->read_bytes;
+		return -EINVAL;
+	}
+
+	for (i = 0; i < len; i++)
+		if (in_8(&ctrl->addr[ctrl->index + i]) != buf[i])
+			break;
+
+	ctrl->index += len;
+	return i == len && ctrl->status == LTESR_CC ? 0 : -EIO;
+}
+
+/* This function is called after Program and Erase Operations to
+ * check for success or failure.
+ */
+static int fsl_elbc_wait(struct mtd_info *mtd, struct nand_chip *chip)
+{
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+
+	if (ctrl->status != LTESR_CC)
+		return NAND_STATUS_FAIL;
+
+	/* Use READ_STATUS command, but wait for the device to be ready */
+	ctrl->use_mdr = 0;
+	out_be32(&lbc->fir,
+	         (FIR_OP_CW0 << FIR_OP0_SHIFT) |
+	         (FIR_OP_RBW << FIR_OP1_SHIFT));
+	out_be32(&lbc->fcr, NAND_CMD_STATUS << FCR_CMD0_SHIFT);
+	out_be32(&lbc->fbcr, 1);
+	set_addr(mtd, 0, 0, 0);
+	ctrl->read_bytes = 1;
+
+	fsl_elbc_run_command(mtd);
+
+	if (ctrl->status != LTESR_CC)
+		return NAND_STATUS_FAIL;
+
+	/* The chip always seems to report that it is
+	 * write-protected, even when it is not.
+	 */
+	setbits8(ctrl->addr, NAND_STATUS_WP);
+	return fsl_elbc_read_byte(mtd);
+}
+
+static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+	unsigned int al;
+
+	/* calculate FMR Address Length field */
+	al = 0;
+	if (chip->pagemask & 0xffff0000)
+		al++;
+	if (chip->pagemask & 0xff000000)
+		al++;
+
+	/* add to ECCM mode set in fsl_elbc_init */
+	priv->fmr |= (12 << FMR_CWTO_SHIFT) |  /* Timeout > 12 ms */
+	             (al << FMR_AL_SHIFT);
+
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->numchips = %d\n",
+	        chip->numchips);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->chipsize = %ld\n",
+	        chip->chipsize);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->pagemask = %8x\n",
+	        chip->pagemask);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->chip_delay = %d\n",
+	        chip->chip_delay);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->badblockpos = %d\n",
+	        chip->badblockpos);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->chip_shift = %d\n",
+	        chip->chip_shift);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->page_shift = %d\n",
+	        chip->page_shift);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->phys_erase_shift = %d\n",
+	        chip->phys_erase_shift);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecclayout = %p\n",
+	        chip->ecclayout);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.mode = %d\n",
+	        chip->ecc.mode);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.steps = %d\n",
+	        chip->ecc.steps);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.bytes = %d\n",
+	        chip->ecc.bytes);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.total = %d\n",
+	        chip->ecc.total);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.layout = %p\n",
+	        chip->ecc.layout);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->flags = %08x\n", mtd->flags);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->size = %d\n", mtd->size);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->erasesize = %d\n",
+	        mtd->erasesize);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->writesize = %d\n",
+	        mtd->writesize);
+	dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->oobsize = %d\n",
+	        mtd->oobsize);
+
+	/* adjust Option Register and ECC to match Flash page size */
+	if (mtd->writesize == 512) {
+		priv->page_size = 0;
+		clrbits32(&lbc->bank[priv->bank].or, ~OR_FCM_PGS);
+	} else if (mtd->writesize == 2048) {
+		priv->page_size = 1;
+		setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
+		/* adjust ecc setup if needed */
+		if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
+		    BR_DECC_CHK_GEN) {
+			chip->ecc.size = 512;
+			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
+			                   &fsl_elbc_oob_lp_eccm1 :
+			                   &fsl_elbc_oob_lp_eccm0;
+			mtd->ecclayout = chip->ecc.layout;
+			mtd->oobavail = chip->ecc.layout->oobavail;
+		}
+	} else {
+		dev_err(ctrl->dev,
+		        "fsl_elbc_init: page size %d is not supported\n",
+		        mtd->writesize);
+		return -1;
+	}
+
+	/* The default u-boot configuration on MPC8313ERDB causes errors;
+	 * more delay is needed.  This should be safe for other boards
+	 * as well.
+	 */
+	setbits32(&lbc->bank[priv->bank].or, 0x70);
+	return 0;
+}
+
+static int fsl_elbc_read_page(struct mtd_info *mtd,
+                              struct nand_chip *chip,
+                              uint8_t *buf)
+{
+	fsl_elbc_read_buf(mtd, buf, mtd->writesize);
+	fsl_elbc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
+
+	if (fsl_elbc_wait(mtd, chip) & NAND_STATUS_FAIL)
+		mtd->ecc_stats.failed++;
+
+	return 0;
+}
+
+/* ECC will be calculated automatically, and errors will be detected in
+ * waitfunc.
+ */
+static void fsl_elbc_write_page(struct mtd_info *mtd,
+                                struct nand_chip *chip,
+                                const uint8_t *buf)
+{
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+
+	fsl_elbc_write_buf(mtd, buf, mtd->writesize);
+	fsl_elbc_write_buf(mtd, chip->oob_poi, mtd->oobsize);
+
+	ctrl->oob_poi = chip->oob_poi;
+}
+
+static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
+{
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+	struct nand_chip *chip = &priv->chip;
+
+	dev_dbg(priv->dev, "eLBC Set Information for bank %d\n", priv->bank);
+
+	/* Fill in fsl_elbc_mtd structure */
+	priv->mtd.priv = chip;
+	priv->mtd.owner = THIS_MODULE;
+	priv->fmr = 0; /* rest filled in later */
+
+	/* fill in nand_chip structure */
+	/* set up function call table */
+	chip->read_byte = fsl_elbc_read_byte;
+	chip->write_buf = fsl_elbc_write_buf;
+	chip->read_buf = fsl_elbc_read_buf;
+	chip->verify_buf = fsl_elbc_verify_buf;
+	chip->select_chip = fsl_elbc_select_chip;
+	chip->cmdfunc = fsl_elbc_cmdfunc;
+	chip->waitfunc = fsl_elbc_wait;
+
+	/* set up nand options */
+	chip->options = NAND_NO_READRDY | NAND_NO_AUTOINCR;
+
+	chip->controller = &ctrl->controller;
+	chip->priv = priv;
+
+	chip->ecc.read_page = fsl_elbc_read_page;
+	chip->ecc.write_page = fsl_elbc_write_page;
+
+	/* If CS Base Register selects full hardware ECC then use it */
+	if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
+	    BR_DECC_CHK_GEN) {
+		chip->ecc.mode = NAND_ECC_HW;
+		/* put in small page settings and adjust later if needed */
+		chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
+				&fsl_elbc_oob_sp_eccm1 : &fsl_elbc_oob_sp_eccm0;
+		chip->ecc.size = 512;
+		chip->ecc.bytes = 3;
+	} else {
+		/* otherwise fall back to default software ECC */
+		chip->ecc.mode = NAND_ECC_SOFT;
+	}
+
+	return 0;
+}
+
+static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
+{
+	struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+
+	nand_release(&priv->mtd);
+
+	if (priv->vbase)
+		iounmap(priv->vbase);
+
+	ctrl->chips[priv->bank] = NULL;
+	kfree(priv);
+
+	return 0;
+}
+
+static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
+                               struct device_node *node)
+{
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+	struct fsl_elbc_mtd *priv;
+	struct resource res;
+#ifdef CONFIG_MTD_PARTITIONS
+	static const char *part_probe_types[]
+		= { "cmdlinepart", "RedBoot", NULL };
+	struct mtd_partition *parts;
+#endif
+	int ret;
+	int bank;
+
+	/* get, allocate and map the memory resource */
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret) {
+		dev_err(ctrl->dev, "failed to get resource\n");
+		return ret;
+	}
+
+	/* find which chip select it is connected to */
+	for (bank = 0; bank < MAX_BANKS; bank++)
+		if ((in_be32(&lbc->bank[bank].br) & BR_V) &&
+		    (in_be32(&lbc->bank[bank].br) & BR_MSEL) == BR_MS_FCM &&
+		    (in_be32(&lbc->bank[bank].br) &
+		     in_be32(&lbc->bank[bank].or) & BR_BA)
+		     == res.start)
+			break;
+
+	if (bank >= MAX_BANKS) {
+		dev_err(ctrl->dev, "address did not match any chip selects\n");
+		return -ENODEV;
+	}
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	ctrl->chips[bank] = priv;
+	priv->bank = bank;
+	priv->ctrl = ctrl;
+	priv->dev = ctrl->dev;
+
+	priv->vbase = ioremap(res.start, res.end - res.start + 1);
+	if (!priv->vbase) {
+		dev_err(ctrl->dev, "failed to map chip region\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	ret = fsl_elbc_chip_init(priv);
+	if (ret)
+		goto err;
+
+	ret = nand_scan_ident(&priv->mtd, 1);
+	if (ret)
+		goto err;
+
+	ret = fsl_elbc_chip_init_tail(&priv->mtd);
+	if (ret)
+		goto err;
+
+	ret = nand_scan_tail(&priv->mtd);
+	if (ret)
+		goto err;
+
+#ifdef CONFIG_MTD_PARTITIONS
+	/* First look for RedBoot table or partitions on the command
+	 * line, these take precedence over device tree information */
+	ret = parse_mtd_partitions(&priv->mtd, part_probe_types, &parts, 0);
+	if (ret < 0)
+		goto err;
+
+#ifdef CONFIG_MTD_OF_PARTS
+	if (ret == 0) {
+		ret = of_mtd_parse_partitions(priv->dev, &priv->mtd,
+		                              node, &parts);
+		if (ret < 0)
+			goto err;
+	}
+#endif
+
+	if (ret > 0)
+		add_mtd_partitions(&priv->mtd, parts, ret);
+	else
+#endif
+		add_mtd_device(&priv->mtd);
+
+	printk(KERN_INFO "eLBC NAND device at 0x%zx, bank %d\n",
+	       res.start, priv->bank);
+	return 0;
+
+err:
+	fsl_elbc_chip_remove(priv);
+	return ret;
+}
+
+static int __devinit fsl_elbc_ctrl_init(struct fsl_elbc_ctrl *ctrl)
+{
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+
+	/* clear event registers */
+	setbits32(&lbc->ltesr, LTESR_NAND_MASK);
+	out_be32(&lbc->lteatr, 0);
+
+	/* Enable interrupts for any detected events */
+	out_be32(&lbc->lteir, LTESR_NAND_MASK);
+
+	ctrl->read_bytes = 0;
+	ctrl->index = 0;
+	ctrl->addr = NULL;
+
+	return 0;
+}
+
+static int __devexit fsl_elbc_ctrl_remove(struct of_device *ofdev)
+{
+	struct fsl_elbc_ctrl *ctrl = dev_get_drvdata(&ofdev->dev);
+	int i;
+
+	for (i = 0; i < MAX_BANKS; i++)
+		if (ctrl->chips[i])
+			fsl_elbc_chip_remove(ctrl->chips[i]);
+
+	if (ctrl->irq)
+		free_irq(ctrl->irq, ctrl);
+
+	if (ctrl->regs)
+		iounmap(ctrl->regs);
+
+	dev_set_drvdata(&ofdev->dev, NULL);
+	kfree(ctrl);
+	return 0;
+}
+
+/* NOTE: This interrupt is also used to report other localbus events,
+ * such as transaction errors on other chipselects.  If we want to
+ * capture those, we'll need to move the IRQ code into a shared
+ * LBC driver.
+ */
+
+static irqreturn_t fsl_elbc_ctrl_irq(int irqno, void *data)
+{
+	struct fsl_elbc_ctrl *ctrl = data;
+	struct elbc_regs __iomem *lbc = ctrl->regs;
+	__be32 status = in_be32(&lbc->ltesr) & LTESR_NAND_MASK;
+
+	if (status) {
+		out_be32(&lbc->ltesr, status);
+		out_be32(&lbc->lteatr, 0);
+
+		ctrl->irq_status = status;
+		smp_wmb();
+		wake_up(&ctrl->irq_wait);
+
+		return IRQ_HANDLED;
+	}
+
+	return IRQ_NONE;
+}
+
+/* fsl_elbc_ctrl_probe
+ *
+ * called by device layer when it finds a device matching
+ * one our driver can handled. This code allocates all of
+ * the resources needed for the controller only.  The
+ * resources for the NAND banks themselves are allocated
+ * in the chip probe function.
+*/
+
+static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
+                                         const struct of_device_id *match)
+{
+	struct device_node *child;
+	struct fsl_elbc_ctrl *ctrl;
+	int ret;
+
+	ctrl = kzalloc(sizeof(*ctrl), GFP_KERNEL);
+	if (!ctrl)
+		return -ENOMEM;
+
+	dev_set_drvdata(&ofdev->dev, ctrl);
+
+	spin_lock_init(&ctrl->controller.lock);
+	init_waitqueue_head(&ctrl->controller.wq);
+	init_waitqueue_head(&ctrl->irq_wait);
+
+	ctrl->regs = of_iomap(ofdev->node, 0);
+	if (!ctrl->regs) {
+		dev_err(&ofdev->dev, "failed to get memory region\n");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ctrl->irq = of_irq_to_resource(ofdev->node, 0, NULL);
+	if (ctrl->irq == NO_IRQ) {
+		dev_err(&ofdev->dev, "failed to get irq resource\n");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ctrl->dev = &ofdev->dev;
+
+	ret = fsl_elbc_ctrl_init(ctrl);
+	if (ret < 0)
+		goto err;
+
+	ret = request_irq(ctrl->irq, fsl_elbc_ctrl_irq, 0, "fsl-elbc", ctrl);
+	if (ret != 0) {
+		dev_err(&ofdev->dev, "failed to install irq (%d)\n",
+		        ctrl->irq);
+		ret = ctrl->irq;
+		goto err;
+	}
+
+	for_each_child_of_node(ofdev->node, child)
+		if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
+			fsl_elbc_chip_probe(ctrl, child);
+
+	return 0;
+
+err:
+	fsl_elbc_ctrl_remove(ofdev);
+	return ret;
+}
+
+static const struct of_device_id fsl_elbc_match[] = {
+	{
+		.compatible = "fsl,elbc",
+	},
+	{}
+};
+
+static struct of_platform_driver fsl_elbc_ctrl_driver = {
+	.driver = {
+		.name	= "fsl-elbc",
+	},
+	.match_table = fsl_elbc_match,
+	.probe = fsl_elbc_ctrl_probe,
+	.remove = __devexit_p(fsl_elbc_ctrl_remove),
+};
+
+static int __init fsl_elbc_init(void)
+{
+	return of_register_platform_driver(&fsl_elbc_ctrl_driver);
+}
+
+static void __exit fsl_elbc_exit(void)
+{
+	of_unregister_platform_driver(&fsl_elbc_ctrl_driver);
+}
+
+module_init(fsl_elbc_init);
+module_exit(fsl_elbc_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Freescale");
+MODULE_DESCRIPTION("Freescale Enhanced Local Bus Controller MTD NAND driver");
-- 
1.5.3.8


From vicky.irobot at gmail.com  Thu Feb  7 01:16:53 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Thu, 07 Feb 2008 11:46:53 +0530
Subject: mtdblock mount issue
In-Reply-To: <A2EC06CB0E393B4C8EB220B286B7083E058EFCAC@ct11exm60.ds.mot.com>
References: <47A71EF4.2090202@gmail.com>
	<A2EC06CB0E393B4C8EB220B286B7083E058EFCAC@ct11exm60.ds.mot.com>
Message-ID: <47AAA255.4050009@gmail.com>

Adams Richard-W36112 wrote:
>> -----Original Message-----
>> From: linux-mtd-bounces at lists.infradead.org 
>> [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of 
>> Max Stirling
>> Sent: Monday, February 04, 2008 6:20 AM
>> To: linux-mtd at lists.infradead.org
>> Subject: mtdblock mount issue
>>
>> Hi,
>>
>> I am trying to mount a cramfs partition from flash. I have 
>> the low level driver written and MTDBLOCK_RO module is enabled in MTD,
>>
>> My mount fails with invalid argument error.
>>
>> /mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument/
>>
>> I am using a 512 byte NAND flash 16byte spare.
>>
>> I can find cramfs in /proc/filesytems and the mtdblock is 
>> under /proc/devices.
>>
>> I had enabled a few debug statements in the mtdblock_ro and 
>> the low level nand driver code. I find that the mount is 
>> reading 32 pages after which it fails with invalid argument. 
>> Below is the log.
>>
>> If you see the log below, the flow of code is
>>
>>  cramfs_read ==> do_blktrans_request ==> mtdblock_readsect 
>> ==> mt_read(my low level read function which returns success)
>>
>> I even dumped the hex of the data being read by my low level 
>> driver module and found to match the cramfs image that I 
>> wrote to the flash.
>>
>>
>> ######################*LOG*##########################
>>
>> /home # mkdir crfs
>> /home # cat /proc/devices | grep mtdblock
>>  31 mtdblock
>> /home # cat proc/filesystems | grep cramfs
>>     cramfs
>> /home #
>> /home # mknod /dev/mtdblock b 31 0
>> /home # mount -t cramfs /dev/mtdblock /home/crfs
>> mount: /dev/mtdblock is write-protected, mounting read-only
>> cramfs_read
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:0
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:512
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:1024
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:1536
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:2048
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:2560
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:3072
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:3584
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:4096
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:4608
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:5120
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:5632
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:6144
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:6656
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:7168
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:7680
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:8192
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:8704
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:9216
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:9728
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:10240
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:10752
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:11264
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:11776
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:12288
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:12800
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:13312
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:13824
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:14336
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:14848
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:15360
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:15872
>> mt_read status:0
>> cramfs_read
>> mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument
>> /home #
>>
>> ########################################################
>>
>>
>> I hope I have provided the maximum information. Looking 
>> forward for some 
>> help.
>>
>>     
>
> You need to mount the file system as read only. I believe I've seen this
> error when I've mounted a squashfs (also a read only file system)
> without specifying the read only option.
>
> Try this command:
> mount /dev/mtdblock /home/crfs  -t cramfs -o ro
>
> Rick
>   
Thanks mate.  After some debugging I found that in cramfs_read function 
it calls read_cache_page and the returned superblock magic is not 
correct from cramfs_read.

I am not sure whatz gone wrong since in my low level driver code I 
dumped the data that is being copied to the buffer that readsect from 
block_ro passed and the magic was right there.

Have to dig into what might be causing this wrong data to be returned by 
read_cache_page. One more thing that I noticed was that for every run 
the magic in the page that read_cache_page returns is different !!!

I am using linux kernel 2.6.10, the latest kernel calls 
read_mapping_page_async in cramfs_read. Not sure if this was a fix to 
what I have been seeing or something wrong here.


-- 
Max Stirling



From augulis.darius at gmail.com  Thu Feb  7 11:08:40 2008
From: augulis.darius at gmail.com (Darius)
Date: Thu, 07 Feb 2008 18:08:40 +0200
Subject: Problem: Can't mount jffs2 filesystem
Message-ID: <fofaee$hdc$1@ger.gmane.org>

Hi All,

I have ARM920T board with two 128M 16bit NOR FLASH devices configured as 
one 256M 32bit device. I want to mount my root filesystem (jffs2) at 
boot time. There is boot log of my 2.6.24 vanilla kernel:

[    0.000000] Linux version 2.6.24 (Darius at localhost.localdomain) (gcc 
version 4.0.2) #19 Thu Feb 7 16:55:32 EET 2008
[    0.000000] CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=00003177
[    0.000000] Machine: Motorola MX1ADS
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 16384
[    0.000000]   DMA zone: 128 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 16256 pages, LIFO batch:3
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] CPU0: D VIVT write-back cache
[    0.000000] CPU0: I cache: 16384 bytes, associativity 64, 32 byte 
lines, 8 sets
[    0.000000] CPU0: D cache: 16384 bytes, associativity 64, 32 byte 
lines, 8 sets
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 16256
[    0.000000] Kernel command line: 
mtdparts=physmap-flash.0:128k,2M(kernel),-(rootfs) root=/dev/mtdblock2 
rootfstype=jffs2 ro debug ignore_loglevel
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[    0.000000] console [ttySMX0] enabled
[    0.010000] Dentry cache hash table entries: 8192 (order: 3, 32768 
bytes)
[    0.010000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.030000] Memory: 64MB = 64MB total
[    0.030000] Memory: 63536KB available (1164K code, 103K data, 76K init)
[    0.040000] Calibrating delay loop... 47.92 BogoMIPS (lpj=239616)
[    0.230000] Mount-cache hash table entries: 512
[    0.230000] CPU: Testing write buffer coherency: ok
[    0.270000] Time: imx_timer1 clocksource has been installed.
[    0.280000] VFS: Disk quotas dquot_6.5.1
[    0.290000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.300000] JFFS2 version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
[    0.300000] Allocated 270656 bytes for deflate workspace
[    0.310000] Allocated 42284 bytes for inflate workspace
[    0.310000] Registering JFFS2 compressor "zlib"
[    0.320000] Compressor "zlib", prio 60
[    0.320000] Registering JFFS2 compressor "rtime"
[    0.330000] Compressor "zlib", prio 60
[    0.330000] Compressor "rtime", prio 50
[    0.340000] JFFS2: default compression mode: priority
[    0.340000] fuse init (API version 7.9)
[    0.350000] io scheduler noop registered
[    0.350000] io scheduler anticipatory registered
[    0.360000] io scheduler deadline registered
[    0.360000] io scheduler cfq registered (default)
[    0.370000] Serial: IMX driver
[    0.370000] imx-uart.0: ttySMX0 at MMIO 0xe0006000 (irq = 30) is a IMX
[    0.380000] imx-uart.1: ttySMX1 at MMIO 0xe0007000 (irq = 24) is a IMX
[    0.410000] RAMDISK driver initialized: 16 RAM disks of 4096K size 
1024 blocksize
[    0.420000] physmap platform flash device: 02000000 at 10000000
[    0.430000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
[    0.440000]  Amd/Fujitsu Extended Query Table at 0x0040
[    0.440000] physmap-flash.0: CFI does not contain boot bank location. 
Assuming top.
[    0.450000] number of CFI chips: 1
[    0.450000] cfi_cmdset_0002: Disabling erase-suspend-program due to 
code brokenness.
[    0.460000] 3 cmdlinepart partitions found on MTD device physmap-flash.0
[    0.470000] Creating 3 MTD partitions on "physmap-flash.0":
[    0.470000] 0x00000000-0x00020000 : "Partition_000"
[    0.480000] mtd: Giving out device 0 to Partition_000
[    0.480000] 0x00020000-0x00220000 : "kernel"
[    0.490000] mtd: Giving out device 1 to kernel
[    0.490000] 0x00220000-0x02000000 : "rootfs"
[    0.500000] mtd: Giving out device 2 to rootfs
[    0.500000] block2mtd: version $Revision: 1.30 $
[    0.510000] MTDSB: dev_name "/dev/root"
[    0.510000] MTDSB: path_lookup() returned 0, inode c3c69554
[    0.520000] List of all partitions:
[    0.520000] No filesystem could mount root, tried:  jffs2
[    0.530000] Kernel panic - not syncing: VFS: Unable to mount root fs 
on unknown-block(0,0)

Why VFS can't open mtdblock2? I have enabled such settings like block 
layer, all pseudo filesystems, jffs2 filesystem. All things are built in 
kernel, nothing as module.
I need hint how to access my root filesystem. Below is MTD driver config:

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set

#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLKDEVS is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_XIP is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x10000000
CONFIG_MTD_PHYSMAP_LEN=0x2000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=4
# CONFIG_MTD_ARM_INTEGRATOR is not set
# CONFIG_MTD_IMPA7 is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# UBI - Unsorted block images
#
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_GLUEBI=y

#
# UBI debugging options
#
CONFIG_MTD_UBI_DEBUG=y
CONFIG_MTD_UBI_DEBUG_MSG=y
# CONFIG_MTD_UBI_DEBUG_PARANOID is not set
# CONFIG_MTD_UBI_DEBUG_DISABLE_BGT is not set
# CONFIG_MTD_UBI_DEBUG_USERSPACE_IO is not set
# CONFIG_MTD_UBI_DEBUG_EMULATE_BITFLIPS is not set
# CONFIG_MTD_UBI_DEBUG_EMULATE_WRITE_FAILURES is not set
# CONFIG_MTD_UBI_DEBUG_EMULATE_ERASE_FAILURES is not set

#
# Additional UBI debugging messages
#
CONFIG_MTD_UBI_DEBUG_MSG_BLD=y
CONFIG_MTD_UBI_DEBUG_MSG_EBA=y
CONFIG_MTD_UBI_DEBUG_MSG_WL=y
CONFIG_MTD_UBI_DEBUG_MSG_IO=y
# CONFIG_PARPORT is not set
# CONFIG_PNP is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_MISC_DEVICES is not set


All info about MTD and jffs2 is very welcome!

Darius.



From sergei.sharonov at halliburton.com  Thu Feb  7 11:28:00 2008
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 7 Feb 2008 16:28:00 +0000 (UTC)
Subject: mtdblock mount issue
References: <47A71EF4.2090202@gmail.com>
Message-ID: <loom.20080207T155530-907@post.gmane.org>


> I am trying to mount a cramfs partition from flash. 

A word of warning. CRAMFS is broken in kernels < 2.6.18. As far as I can tell,
under heavy load (e.g. reading multiple files in parallel that are not cached)
it may fail with decompression errors. I think the issue is not exactly with
cramfs but with some interaction with page cache. Backporting just cramfs files
to 2.6.15 did not help. If you have drop_caches interface (kernel > 2.6.16 or
just backport it) it is easy to reproduce. Otherwise it happens _very_
infrequently because most of the time files are already cached. However the
consequences are severe - corrupted executables, etc.
Here is a script to reproduce the problem:

===============================================
# Copy large file from cramfs to tmpfs
cp /bin/smbd /tmp/

# First concurrent access to files/directories 
while [ 1 ]; do cat /bin/* > /dev/null; done &

# Second concurrent access to test file and cache flush
for((i=0;i<99999;i++)) do echo -n "cycle=$i "; 
  cmp /bin/smbd /tmp/smbd ; 
  echo 3 > /proc/sys/vm/drop_caches ; 
done
===============================================

Note that /bin is in cramfs. smbd can be any large file.
I've also seen statements that drop_caches interface is not 100% reliable.
Nevertheless I have experienced decompression errors even without forcing 
cache purge.
Above script has caused failures on PowerPC/2.6.16 and ARM9/2.6.15.
2.6.18 and 2.6.23 seem ok.

Regards,

Sergei 

P.S. Yes, cramfs has little to do with MTD but since ppl here use it with flash
I felt it was a good idea to post this warning.



From dwmw2 at infradead.org  Sat Feb  9 03:36:56 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Feb 2008 08:36:56 +0000
Subject: [PATCH] basic pxa3 nand controller support
In-Reply-To: <f17812d70801211619u6d2a89bdt19f1b67b1c188470@mail.gmail.com>
References: <1200916396.6263.6.camel@localhost.localdomain>
	<f17812d70801211619u6d2a89bdt19f1b67b1c188470@mail.gmail.com>
Message-ID: <1202546216.5469.356.camel@pmac.infradead.org>


On Tue, 2008-01-22 at 08:19 +0800, eric miao wrote:
> Hi Sergey,
> 
> Thanks for trying the driver. I guess this is generally OK, but there
> are several concerns:

Eric, did you ever get any response to this? 

-- 
dwmw2



From rpjday at crashcourse.ca  Sat Feb  9 14:43:05 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Sat, 9 Feb 2008 14:43:05 -0500 (EST)
Subject: [PATCH] MTD:  Delete unused jedec.h header file.
Message-ID: <alpine.LFD.1.00.0802091438130.18228@localhost.localdomain>


Remove the apparently unreferenced include/linux/mtd/jedec.h header
file.

Signed-off-by: Robert P. J. Day <rpjday at crashcourse.ca>

---

  is this header file being used these days?  because it keeps showing
up in my scan for unused header files, and i've submitted a patch to
delete it but ... there it is.

  can someone clarify this one way or the other?  thanks.

diff --git a/include/linux/mtd/jedec.h b/include/linux/mtd/jedec.h
deleted file mode 100644
index 9006feb..0000000
--- a/include/linux/mtd/jedec.h
+++ /dev/null
@@ -1,66 +0,0 @@
-
-/* JEDEC Flash Interface.
- * This is an older type of interface for self programming flash. It is
- * commonly use in older AMD chips and is obsolete compared with CFI.
- * It is called JEDEC because the JEDEC association distributes the ID codes
- * for the chips.
- *
- * See the AMD flash databook for information on how to operate the interface.
- *
- * $Id: jedec.h,v 1.4 2005/11/07 11:14:54 gleixner Exp $
- */
-
-#ifndef __LINUX_MTD_JEDEC_H__
-#define __LINUX_MTD_JEDEC_H__
-
-#include <linux/types.h>
-
-#define MAX_JEDEC_CHIPS 16
-
-// Listing of all supported chips and their information
-struct JEDECTable
-{
-   __u16 jedec;
-   char *name;
-   unsigned long size;
-   unsigned long sectorsize;
-   __u32 capabilities;
-};
-
-// JEDEC being 0 is the end of the chip array
-struct jedec_flash_chip
-{
-   __u16 jedec;
-   unsigned long size;
-   unsigned long sectorsize;
-
-   // *(__u8*)(base + (adder << addrshift)) = data << datashift
-   // Address size = size << addrshift
-   unsigned long base;           // Byte 0 of the flash, will be unaligned
-   unsigned int datashift;       // Useful for 32bit/16bit accesses
-   unsigned int addrshift;
-   unsigned long offset;         // linerized start. base==offset for unbanked, uninterleaved flash
-
-   __u32 capabilities;
-
-   // These markers are filled in by the flash_chip_scan function
-   unsigned long start;
-   unsigned long length;
-};
-
-struct jedec_private
-{
-   unsigned long size;         // Total size of all the devices
-
-   /* Bank handling. If sum(bank_fill) == size then this is linear flash.
-      Otherwise the mapping has holes in it. bank_fill may be used to
-      find the holes, but in the common symetric case
-      bank_fill[0] == bank_fill[*], thus addresses may be computed
-      mathmatically. bank_fill must be powers of two */
-   unsigned is_banked;
-   unsigned long bank_fill[MAX_JEDEC_CHIPS];
-
-   struct jedec_flash_chip chips[MAX_JEDEC_CHIPS];
-};
-
-#endif

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

Home page:                                         http://crashcourse.ca
Fedora Cookbook:    http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================


From Christophe.Lohr at enst-bretagne.fr  Mon Feb 11 11:39:32 2008
From: Christophe.Lohr at enst-bretagne.fr (Christophe Lohr)
Date: Mon, 11 Feb 2008 17:39:32 +0100
Subject: how to mount this mtd filesystem image?
Message-ID: <47B07A44.6030003@enst-bretagne.fr>

Hi,
I?m not sure to be on the right mailing list?

My problem is as follow: I have an mtd dump file. This is not a jffs2 
file system image. It looks like a plain old flash file system, but 
which one? How may I get the content of this file system?

00000000 46 66 73 23 00 03 01 00 c0 ff ff ff ff ff ff ff |Ffs#............|
00000010 2f 66 66 73 2d 72 6f 6f 74 00 ff ff ff ff ff ff |/ffs-root.......|
00000020 2e 6a 6f 75 72 6e 61 6c 00 ff ff ff c0 00 03 00 |.journal........|
00000030 02 00 00 00 c0 00 04 00 03 00 00 00 c0 00 05 00 |................|
00000040 04 00 00 00 c0 00 06 00 05 00 00 00 c0 00 07 00 |................|
00000050 06 00 00 00 c0 00 08 00 07 00 00 00 c0 00 09 00 |................|
(...)

Any help is welcome.
Thanks and regards.
Christophe





From wojciech.kromer at dgt.com.pl  Mon Feb 11 17:14:28 2008
From: wojciech.kromer at dgt.com.pl (Wojciech Kromer)
Date: Mon, 11 Feb 2008 23:14:28 +0100
Subject: MEMSETOOBSEL in nandwtrite
Message-ID: <47B0C8C4.4060009@dgt.com.pl>

Which one have to be updated: nandwrite with nandwrite MEMSETOOBSEL ioctl or kernel?
I have latest git snapshot from mtd-utils and mtd-2.6.
There is still MEMSETOOBSEL inside nandwrite, and it's not implemented in kernel.

Any news on this sibjest?




From will_wagner at carallon.com  Tue Feb 12 06:33:33 2008
From: will_wagner at carallon.com (Will Wagner)
Date: Tue, 12 Feb 2008 11:33:33 +0000
Subject: First access to mounted jffs2 partition is slow
Message-ID: <47B1840D.1010702@carallon.com>

Hello,

I have an ARM11 system with a JFFS2 partition in NAND flash. It works 
but the first time it is accessed after mounting it can be very slow.

These are the steps I am performing:

# flash_eraseall /dev/mtd4
Erasing 128 Kibyte @ 5fe0000 -- 99 % complete.
# time mount /dev/mtdblock4 /flash -t jffs2
real    0m 1.25s
user    0m 0.01s
sys     0m 0.13s
# time ls flash		- with an empty filsystem, this takes no time
real    0m 0.00s
user    0m 0.01s
sys     0m 0.00s
# cp /sdcard/bigfile flash/	- bigfile is ~8MB
# umount /flash
# time mount /dev/mtdblock4 /flash -t jffs2
real    0m 2.63s
user    0m 0.01s
sys     0m 0.50s
# time ls flash		- first time we do this it takes a long time
bigfile
real    0m 11.79s
user    0m 0.00s
sys     0m 0.18s
# time ls flash		- subsequent reads are fast
bigfile
real    0m 0.00s
user    0m 0.01s
sys     0m 0.00s


It was my understanding that the only slow step should be mounting the 
partition when it checks the entire filesystem. Is that correct? Is it 
normal that the first file operation on the partition is slow and then 
all others are fast? That the mount is slow is not a problem but would 
be good if we could make the first access faster even if it means the 
mount must get slower.

This is using Linux 2.6.19.2 with uClibc 0.9.29, busybox 1.9.0 and 
mtd-utils 1.1.0

Thanks,

Will.

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Senior Project Engineer                  Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------




From centralcorre2008 at orange.net  Tue Feb 12 07:03:32 2008
From: centralcorre2008 at orange.net (centralcorre2008 at orange.net)
Date: Tue, 12 Feb 2008 12:03:32 +0000 (GMT)
Subject: Ireland Power Promo
Message-ID: <57585052.1202817812943.JavaMail.wbs51@mspap530>

POWER PROMO IRELAND
20b Barrow Street,
Ringsend, Dublin 4,
Ireland.
www.lotto.ie
 
It is our pleasure to inform you through this medium that Your emailaddress won a prize of 320,000.00 Euros in Power Promo Ireland.
 
Reference number: 0863-4532ES/Ql
Batch numbers: HSLUK/2038/00
 
CONTACT YOUR CLAIMS OFFICER DIRECTLY USING BELOW DETAILS:
 
Yours faithfull,
 
Processing Director: Mr. Anthony Comewell
Tel/Fax: (353) 81 842 3524
Email: proceagent at iol.pt




From matthieu.castet at parrot.com  Tue Feb 12 07:05:11 2008
From: matthieu.castet at parrot.com (Matthieu CASTET)
Date: Tue, 12 Feb 2008 13:05:11 +0100
Subject: First access to mounted jffs2 partition is slow
In-Reply-To: <47B1840D.1010702@carallon.com>
References: <47B1840D.1010702@carallon.com>
Message-ID: <47B18B77.1060602@parrot.com>

Hi,

Will Wagner wrote:
> Hello,
> 
> I have an ARM11 system with a JFFS2 partition in NAND flash. It works 
> but the first time it is accessed after mounting it can be very slow.
I had a similar problem on ARM9 (see 
http://thread.gmane.org/gmane.linux.drivers.mtd/20340/focus=20355 )



Matthieu


-- 
Matthieu Castet
Ing?nieur D?veloppement Logiciel
Parrot SA
174 Quai de Jemmapes
75010 Paris, France

T?l: +33 (0) 1 48 03 74 78
Fax: +33 (0) 1 48 03 06 66
Email: matthieu.castet at parrot.fr
http://www.parrot.biz


From stephane.chazelas at emerson.com  Tue Feb 12 08:47:51 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Tue, 12 Feb 2008 13:47:51 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
Message-ID: <chaz20080212134751.GI30304@artesyncp.com>

Hi Joern,

this patch addresses a number of small issues mainly regarding
the output made by this driver to dmesg:
  - Some of the "blkmtd"'s had not been changed to "block2mtd"
    which caused display problem
  - the parse_err() macro was displaying "block2mtd: " twice

Also, one can add a block2mtd mtd device with things like:

echo /dev/loop3,$((256*1024)) |
  sudo tee /sys/module/block2mtd/parameters/block2mtd

but individual mtds cannot be removed. You can only do a
modprobe -r block2mtd to remove *all* the block2mtd mtds.

This patch proposes to add the cabability with:

echo /dev/loop3,remove |
  sudo tee /sys/module/block2mtd/parameters/block2mtd

Signed-off-by: Stephane Chazelas <stephane.chazelas at emerson.com>

--- drivers/mtd/devices/block2mtd.c~	2007-09-11 03:50:29.000000000 +0100
+++ drivers/mtd/devices/block2mtd.c	2008-02-12 13:30:16.000000000 +0000
@@ -305,7 +305,7 @@ static struct block2mtd_dev *add_device(
 	}
 	list_add(&dev->list, &blkmtd_device_list);
 	INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
-			dev->mtd.name + strlen("blkmtd: "),
+			dev->mtd.name + strlen("block2mtd: "),
 			dev->mtd.erasesize >> 10, dev->mtd.erasesize);
 	return dev;
 
@@ -366,9 +366,9 @@ static inline void kill_final_newline(ch
 }
 
 
-#define parse_err(fmt, args...) do {		\
-	ERROR("block2mtd: " fmt "\n", ## args);	\
-	return 0;				\
+#define parse_err(fmt, args...) do {	\
+	ERROR(fmt, ## args);		\
+	return 0;			\
 } while (0)
 
 #ifndef MODULE
@@ -376,6 +376,31 @@ static int block2mtd_init_called = 0;
 static char block2mtd_paramline[80 + 12]; /* 80 for device, 12 for erase size */
 #endif
 
+static void remove_device_by_name(const char *name)
+{
+	struct list_head *pos, *next;
+	int name_offset = strlen("block2mtd: ");
+
+	list_for_each_safe(pos, next, &blkmtd_device_list) {
+		struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
+		if (!strcmp(name, dev->mtd.name + name_offset)) {
+			int err;
+			block2mtd_sync(&dev->mtd);
+			err = del_mtd_device(&dev->mtd);
+			if (err == 0) {
+				INFO("mtd%d: [%s] removed",
+						dev->mtd.index, name);
+				list_del(&dev->list);
+				block2mtd_free_device(dev);
+			} else
+				ERROR("mtd%d: [%s] cannot remove: %d",
+						dev->mtd.index, name, err);
+
+			return;
+		}
+	}
+	ERROR("no such device: %s", name);
+}
 
 static int block2mtd_setup2(const char *val)
 {
@@ -406,6 +431,10 @@ static int block2mtd_setup2(const char *
 		parse_err("device name too long");
 
 	if (token[1]) {
+		if (!strcmp("remove", token[1])) {
+			remove_device_by_name(name);
+			return 0;
+		}
 		ret = parse_num(&erase_size, token[1]);
 		if (ret) {
 			kfree(name);
@@ -474,7 +503,7 @@ static void __devexit block2mtd_exit(voi
 		block2mtd_sync(&dev->mtd);
 		del_mtd_device(&dev->mtd);
 		INFO("mtd%d: [%s] removed", dev->mtd.index,
-				dev->mtd.name + strlen("blkmtd: "));
+				dev->mtd.name + strlen("block2mtd: "));
 		list_del(&dev->list);
 		block2mtd_free_device(dev);
 	}


From equity.loan27 at comcast.net  Tue Feb 12 08:50:11 2008
From: equity.loan27 at comcast.net (equity.loan27 at comcast.net)
Date: Tue, 12 Feb 2008 13:50:11 +0000
Subject: LOAN OFFER!!!
Message-ID: <021220081350.7849.47B1A4100009DE2800001EA92207003201C9CD020E0104D2979B079A9E0A@comcast.net>

Greetings to you, Welcome to Equity Loans and Investments! We are an asset Based financial loan company that does personal and business loans.We offer great rates starting at 5% yearly and 0.4% monthly! Great Terms! 1 - 40 years! Let us help you with your financial needs! We are not FICO score or credit bureau driven but looks at our client?s needs and assets! Let us help you by tailoring a loan package to YOU not your Credit Score. All you need do is to contact me via my email; Name: Mr. Allen Cole
Email:equityinvestments at live.com


From christophe.lohr at cegetel.net  Tue Feb 12 09:03:55 2008
From: christophe.lohr at cegetel.net (Christophe Lohr)
Date: Tue, 12 Feb 2008 15:03:55 +0100
Subject: how to mount this mtd filesystem image?
In-Reply-To: <47B19690.10009@gmail.com>
References: <47B07A44.6030003@enst-bretagne.fr> <47B19690.10009@gmail.com>
Message-ID: <47B1A74B.5020908@cegetel.net>

Max Stirling:

>>
>> My problem is as follow: I have an mtd dump file. This is not a jffs2 
>> file system image. It looks like a plain old flash file system, but 
>> which one? How may I get the content of this file system?
>>
>> 00000000 46 66 73 23 00 03 01 00 c0 ff ff ff ff ff ff ff 
>> |Ffs#............|
>> 00000010 2f 66 66 73 2d 72 6f 6f 74 00 ff ff ff ff ff ff 
>> |/ffs-root.......|
>> 00000020 2e 6a 6f 75 72 6e 61 6c 00 ff ff ff c0 00 03 00 
>> |.journal........|
>> 00000030 02 00 00 00 c0 00 04 00 03 00 00 00 c0 00 05 00 
>> |................|
>> 00000040 04 00 00 00 c0 00 06 00 05 00 00 00 c0 00 07 00 
>> |................|
>> 00000050 06 00 00 00 c0 00 08 00 07 00 00 00 c0 00 09 00 
>> |................|
>>
> The first four bytes are the magic numbers telling which flash fs this 
> might be.
>
> I did a search for those numbers and couldn't find any reference to 
> this anywhere. Try doing "file <your-mtd-dump-file> this might give 
> more information

The answer is:     "data"
:-(

Note: in fact, this file system is used by a "Nucleus Plus" system 
executed by a DSP, side to an ARM proc (that executes a Linux). It might 
be very specific to Nucleus Plus.



From jwboyer at linux.vnet.ibm.com  Tue Feb 12 10:02:04 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Tue, 12 Feb 2008 09:02:04 -0600
Subject: how to mount this mtd filesystem image?
In-Reply-To: <47B1A74B.5020908@cegetel.net>
References: <47B07A44.6030003@enst-bretagne.fr> <47B19690.10009@gmail.com>
	<47B1A74B.5020908@cegetel.net>
Message-ID: <20080212090204.66828fd7@zod.rchland.ibm.com>

On Tue, 12 Feb 2008 15:03:55 +0100
Christophe Lohr <christophe.lohr at cegetel.net> wrote:

> Max Stirling:
> 
> >>
> >> My problem is as follow: I have an mtd dump file. This is not a jffs2 
> >> file system image. It looks like a plain old flash file system, but 
> >> which one? How may I get the content of this file system?
> >>
> >> 00000000 46 66 73 23 00 03 01 00 c0 ff ff ff ff ff ff ff 
> >> |Ffs#............|
> >> 00000010 2f 66 66 73 2d 72 6f 6f 74 00 ff ff ff ff ff ff 
> >> |/ffs-root.......|
> >> 00000020 2e 6a 6f 75 72 6e 61 6c 00 ff ff ff c0 00 03 00 
> >> |.journal........|
> >> 00000030 02 00 00 00 c0 00 04 00 03 00 00 00 c0 00 05 00 
> >> |................|
> >> 00000040 04 00 00 00 c0 00 06 00 05 00 00 00 c0 00 07 00 
> >> |................|
> >> 00000050 06 00 00 00 c0 00 08 00 07 00 00 00 c0 00 09 00 
> >> |................|
> >>
> > The first four bytes are the magic numbers telling which flash fs this 
> > might be.
> >
> > I did a search for those numbers and couldn't find any reference to 
> > this anywhere. Try doing "file <your-mtd-dump-file> this might give 
> > more information
> 
> The answer is:     "data"
> :-(
> 
> Note: in fact, this file system is used by a "Nucleus Plus" system 
> executed by a DSP, side to an ARM proc (that executes a Linux). It might 
> be very specific to Nucleus Plus.

I recall some tool being in mtd-utils called "mk.ffs" (or something
similar) at one point.  It's since been deleted as it was considered
old and obsolete.  I'm not sure of anything that still has support for
that.

josh


From joern at logfs.org  Tue Feb 12 10:21:24 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Tue, 12 Feb 2008 16:21:24 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080212134751.GI30304@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
Message-ID: <20080212152124.GA21878@lazybastard.org>

On Tue, 12 February 2008 13:47:51 +0000, Stephane Chazelas wrote:
> 
> this patch addresses a number of small issues mainly regarding
> the output made by this driver to dmesg:
>   - Some of the "blkmtd"'s had not been changed to "block2mtd"
>     which caused display problem
>   - the parse_err() macro was displaying "block2mtd: " twice

Fairly obvious fixes.

> Also, one can add a block2mtd mtd device with things like:
> 
> echo /dev/loop3,$((256*1024)) |
>   sudo tee /sys/module/block2mtd/parameters/block2mtd
> 
> but individual mtds cannot be removed. You can only do a
> modprobe -r block2mtd to remove *all* the block2mtd mtds.
> 
> This patch proposes to add the cabability with:
> 
> echo /dev/loop3,remove |
>   sudo tee /sys/module/block2mtd/parameters/block2mtd

Sounds sane enough.  But I do have some reservations about the
implementation.  It would be best if you split the patch in two.  One
with the obvious stuff above and one for this.

The core of remove_device_by_name() is shared with block2mtd_exit(),
so a common helper would be good.  Your error handling is better, so
let's keep that version.

And independently of your patch a mutex protecting the device list from
simultaneous modifications would be good to have.

Side note: I may not have internet access until 19th or so.

J?rn

-- 
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson


From sr at denx.de  Tue Feb 12 11:03:01 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 12 Feb 2008 17:03:01 +0100
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful partition
	scan
Message-ID: <1202832181-1783-1-git-send-email-sr@denx.de>

The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD] Factor out OF
partition support from the NOR driver.") introduced an problem. Now the
physmap_of driver returns with error upon the first unsuccessful
partition scan (parse_mtd_partitions()). This is not wanted, since even
when the RedBoot/cmdlinepart partition scan is unsuccessful, the other
scan's (of_mtd_parse_partitions(), parse_obsolete_partitions()) should be
done nevertheless.

This patch fixes this problem.

Signed-off-by: Stefan Roese <sr at denx.de>
---

Scott, could you please take a look at this patch and add you ACK if you
think it is ok?

Thanks.

 drivers/mtd/maps/physmap_of.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..9808c0d 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -224,24 +224,16 @@ static int __devinit of_flash_probe(struct of_device *dev,
 	/* First look for RedBoot table or partitions on the command
 	 * line, these take precedence over device tree information */
 	err = parse_mtd_partitions(info->mtd, part_probe_types,
-	                           &info->parts, 0);
-	if (err < 0)
-		return err;
+				   &info->parts, 0);
 
 #ifdef CONFIG_MTD_OF_PARTS
-	if (err == 0) {
+	if (err < 0)
 		err = of_mtd_parse_partitions(&dev->dev, info->mtd,
-		                              dp, &info->parts);
-		if (err < 0)
-			return err;
-	}
+					      dp, &info->parts);
 #endif
 
-	if (err == 0) {
+	if (err < 0)
 		err = parse_obsolete_partitions(dev, info, dp);
-		if (err < 0)
-			return err;
-	}
 
 	if (err > 0)
 		add_mtd_partitions(info->mtd, info->parts, err);
-- 
1.5.4.1



From stephane.chazelas at emerson.com  Tue Feb 12 11:10:34 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Tue, 12 Feb 2008 16:10:34 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080212152124.GA21878@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<20080212152124.GA21878@lazybastard.org>
Message-ID: <chaz20080212161034.GJ30304@artesyncp.com>

2008-02-12 16:21:24 +0100, J?rn Engel:
> On Tue, 12 February 2008 13:47:51 +0000, Stephane Chazelas wrote:
> > 
> > this patch addresses a number of small issues mainly regarding
> > the output made by this driver to dmesg:
> >   - Some of the "blkmtd"'s had not been changed to "block2mtd"
> >     which caused display problem
> >   - the parse_err() macro was displaying "block2mtd: " twice
> 
> Fairly obvious fixes.
> 
> > Also, one can add a block2mtd mtd device with things like:
> > 
> > echo /dev/loop3,$((256*1024)) |
> >   sudo tee /sys/module/block2mtd/parameters/block2mtd
> > 
> > but individual mtds cannot be removed. You can only do a
> > modprobe -r block2mtd to remove *all* the block2mtd mtds.
> > 
> > This patch proposes to add the cabability with:
> > 
> > echo /dev/loop3,remove |
> >   sudo tee /sys/module/block2mtd/parameters/block2mtd
> 
> Sounds sane enough.  But I do have some reservations about the
> implementation.  It would be best if you split the patch in two.  One
> with the obvious stuff above and one for this.

Hi J?rn,

OK, I can do that. Would the "simple" fix go to the
trivial at kernel.org Trivial Patch Monkey?

> The core of remove_device_by_name() is shared with block2mtd_exit(),
> so a common helper would be good.  Your error handling is better, so
> let's keep that version.

Well, yes that raised a concern to me, the "exit" function
returns "void". If the del_mtd_device fails with EBUSY at the
moment (such as when a /dev/mtdblock<x> is mounted), we ignore
it and go on with freeing everything leaving a dangling mtd.

Is there a way around that?

Another problem is that it's not easy to check whether a mtd
creation was successful or not. Basically, you have to write to
a /sys file and then parse /proc/mtd to get the result.

What about having a /dev/block2mtd (with owner/permissions that
could allow non-root users to use it), with 2 ioctls:

- one to "link" a block dev to a mtd that would take as
  parameter a fd to an open block dev (again allowing for
  flexible permissions) and would return the number of the
  allocated mtd and success/failure in errno. Upon sucess it
  would increase the refcnt of block2mtd.

- and one to "release" the link. That would fail if the mtd is
  in use and decrease block2mtd's refcnt upon success.

A bit like the loop devices (or /dev/ptmx) actually. What do you
think?

(also, with the /sys interface, isn't there a potential problem
with chroots wrt the path given to the /sys file?)

> And independently of your patch a mutex protecting the device list from
> simultaneous modifications would be good to have.
> 
> Side note: I may not have internet access until 19th or so.
[...]

I'll dig a little deeper, but I think I'll need some advice/help
at some point, I'm not a Linux kernel expert.

Regards,
Stephane


From dmcleod at bittware.com  Tue Feb 12 12:21:43 2008
From: dmcleod at bittware.com (DMcLeod)
Date: Tue, 12 Feb 2008 12:21:43 -0500
Subject: First access to mounted jffs2 partition is slow
In-Reply-To: <47B1840D.1010702@carallon.com>
References: <47B1840D.1010702@carallon.com>
Message-ID: <47B1D5A7.4000509@bittware.com>

Will Wagner wrote:
> Hello,
>
> I have an ARM11 system with a JFFS2 partition in NAND flash. It works 
> but the first time it is accessed after mounting it can be very slow.
>
> These are the steps I am performing:
>
> # flash_eraseall /dev/mtd4
> Erasing 128 Kibyte @ 5fe0000 -- 99 % complete.
> # time mount /dev/mtdblock4 /flash -t jffs2
> real    0m 1.25s
> user    0m 0.01s
> sys     0m 0.13s
> # time ls flash		- with an empty filsystem, this takes no time
> real    0m 0.00s
> user    0m 0.01s
> sys     0m 0.00s
> # cp /sdcard/bigfile flash/	- bigfile is ~8MB
> # umount /flash
> # time mount /dev/mtdblock4 /flash -t jffs2
> real    0m 2.63s
> user    0m 0.01s
> sys     0m 0.50s
> # time ls flash		- first time we do this it takes a long time
> bigfile
> real    0m 11.79s
> user    0m 0.00s
> sys     0m 0.18s
> # time ls flash		- subsequent reads are fast
> bigfile
> real    0m 0.00s
> user    0m 0.01s
> sys     0m 0.00s
>
>
> It was my understanding that the only slow step should be mounting the 
> partition when it checks the entire filesystem. Is that correct? Is it 
> normal that the first file operation on the partition is slow and then 
> all others are fast? That the mount is slow is not a problem but would 
> be good if we could make the first access faster even if it means the 
> mount must get slower.
>
> This is using Linux 2.6.19.2 with uClibc 0.9.29, busybox 1.9.0 and 
> mtd-utils 1.1.0
>
> Thanks,
>
> Will.
>
>   

We fought that same exact problem for some time. It turned out being 
that we had set the verbosity (something like FS_JFFS2_DEBUG=2) to the 
highest setting. It literally took 30s or more to do an 'ls' the first 
time.

HTH


--------------------------------------------------
Dennis McLeod
dmcleod at bittware.com
http://www.bittware.com
(603) 226 0404 x514
--------------------------------------------------




From trimarchi at gandalf.sssup.it  Tue Feb 12 13:03:56 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 12 Feb 2008 19:03:56 +0100
Subject: First access to mounted jffs2 partition is slow
In-Reply-To: <47B1D5A7.4000509@bittware.com>
References: <47B1840D.1010702@carallon.com> <47B1D5A7.4000509@bittware.com>
Message-ID: <47B1DF8C.4090500@gandalf.sssup.it>

Hi,
> Will Wagner wrote:
>   
>> Hello,
>>
>> I have an ARM11 system with a JFFS2 partition in NAND flash. It works 
>> but the first time it is accessed after mounting it can be very slow.
>>
>> These are the steps I am performing:
>>
>> # flash_eraseall /dev/mtd4
>> Erasing 128 Kibyte @ 5fe0000 -- 99 % complete.
>> # time mount /dev/mtdblock4 /flash -t jffs2
>> real    0m 1.25s
>> user    0m 0.01s
>> sys     0m 0.13s
>> # time ls flash		- with an empty filsystem, this takes no time
>> real    0m 0.00s
>> user    0m 0.01s
>> sys     0m 0.00s
>> # cp /sdcard/bigfile flash/	- bigfile is ~8MB
>> # umount /flash
>> # time mount /dev/mtdblock4 /flash -t jffs2
>> real    0m 2.63s
>> user    0m 0.01s
>> sys     0m 0.50s
>> # time ls flash		- first time we do this it takes a long time
>> bigfile
>> real    0m 11.79s
>> user    0m 0.00s
>> sys     0m 0.18s
>> # time ls flash		- subsequent reads are fast
>> bigfile
>> real    0m 0.00s
>> user    0m 0.01s
>> sys     0m 0.00s
>>
>>     
I think that is a problem of jffs2 and I think that is related to the 
time spent during the fstat64 system but
I'm not sure. I have little experince with jffs2.

Regards Michael



From scottwood at freescale.com  Tue Feb 12 13:06:34 2008
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 12 Feb 2008 12:06:34 -0600
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <1202832181-1783-1-git-send-email-sr@denx.de>
References: <1202832181-1783-1-git-send-email-sr@denx.de>
Message-ID: <47B1E02A.3090709@freescale.com>

Stefan Roese wrote:
> The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD] Factor out OF
> partition support from the NOR driver.") introduced an problem. Now the
> physmap_of driver returns with error upon the first unsuccessful
> partition scan (parse_mtd_partitions()). This is not wanted, since even
> when the RedBoot/cmdlinepart partition scan is unsuccessful, the other
> scan's (of_mtd_parse_partitions(), parse_obsolete_partitions()) should be
> done nevertheless.
> 
> This patch fixes this problem.
> 
> Signed-off-by: Stefan Roese <sr at denx.de>
> ---
> 
> Scott, could you please take a look at this patch and add you ACK if you
> think it is ok?

I was under the impression -- and looking at the code seems to back that 
up -- that parse_mtd_partitions() returns zero if the scan was 
unsuccessful due to the lack of a partition table, and negative only if 
there's a real error.

Under what conditions are you actually seeing this fail?

-Scott


From sr at denx.de  Tue Feb 12 14:15:08 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 12 Feb 2008 20:15:08 +0100
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <47B1E02A.3090709@freescale.com>
References: <1202832181-1783-1-git-send-email-sr@denx.de>
	<47B1E02A.3090709@freescale.com>
Message-ID: <200802122015.08811.sr@denx.de>

On Tuesday 12 February 2008, Scott Wood wrote:
> Stefan Roese wrote:
> > The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD] Factor out OF
> > partition support from the NOR driver.") introduced an problem. Now the
> > physmap_of driver returns with error upon the first unsuccessful
> > partition scan (parse_mtd_partitions()). This is not wanted, since even
> > when the RedBoot/cmdlinepart partition scan is unsuccessful, the other
> > scan's (of_mtd_parse_partitions(), parse_obsolete_partitions()) should be
> > done nevertheless.
> >
> > This patch fixes this problem.
> >
> > Signed-off-by: Stefan Roese <sr at denx.de>
> > ---
> >
> > Scott, could you please take a look at this patch and add you ACK if you
> > think it is ok?
>
> I was under the impression -- and looking at the code seems to back that
> up -- that parse_mtd_partitions() returns zero if the scan was
> unsuccessful due to the lack of a partition table, and negative only if
> there's a real error.
>
> Under what conditions are you actually seeing this fail?

When CONFIG_MTD_REDBOOT_PARTS is not defined for example it returns with -22 
(EINVAL).

Best regards,
Stefan


From scottwood at freescale.com  Tue Feb 12 14:27:10 2008
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 12 Feb 2008 13:27:10 -0600
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <200802122015.08811.sr@denx.de>
References: <1202832181-1783-1-git-send-email-sr@denx.de>
	<47B1E02A.3090709@freescale.com> <200802122015.08811.sr@denx.de>
Message-ID: <47B1F30E.4000509@freescale.com>

Stefan Roese wrote:
> On Tuesday 12 February 2008, Scott Wood wrote:
>> Under what conditions are you actually seeing this fail?
> 
> When CONFIG_MTD_REDBOOT_PARTS is not defined for example it returns with -22 
> (EINVAL).

Ah, I see -- it seems the cmdline partition code behaves differently 
than the redboot code.

Your patch changes it to treat zero as success, however -- which breaks 
some other cases.  The test should be "err <= 0", which is what 
parse_mtd_partiitions() itself uses in its loop.

-Scott


From sr at denx.de  Tue Feb 12 14:37:27 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 12 Feb 2008 20:37:27 +0100
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <47B1F30E.4000509@freescale.com>
References: <1202832181-1783-1-git-send-email-sr@denx.de>
	<200802122015.08811.sr@denx.de> <47B1F30E.4000509@freescale.com>
Message-ID: <200802122037.27864.sr@denx.de>

On Tuesday 12 February 2008, Scott Wood wrote:
> >> Under what conditions are you actually seeing this fail?
> >
> > When CONFIG_MTD_REDBOOT_PARTS is not defined for example it returns with
> > -22 (EINVAL).
>
> Ah, I see -- it seems the cmdline partition code behaves differently
> than the redboot code.
>
> Your patch changes it to treat zero as success, however -- which breaks
> some other cases.  The test should be "err <= 0", which is what
> parse_mtd_partiitions() itself uses in its loop.

OK, I'll fixup another version of this patch tomorrow.

Thanks.

Best regards,
Stefan


From kyungmin.park at samsung.com  Wed Feb 13 01:55:38 2008
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Wed, 13 Feb 2008 15:55:38 +0900
Subject: [PATCH][MTD][OneNAND] Fix unlock all in Double Density Package (DDP)
Message-ID: <20080213065538.GA22073@party>

Fix unlock all in Double Density Package (DDP)

Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 8d7d21b..15a62db 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -2052,7 +2052,7 @@ static int onenand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
  *
  * Check lock status
  */
-static void onenand_check_lock_status(struct onenand_chip *this)
+static int onenand_check_lock_status(struct onenand_chip *this)
 {
 	unsigned int value, block, status;
 	unsigned int end;
@@ -2070,9 +2070,13 @@ static void onenand_check_lock_status(struct onenand_chip *this)
 
 		/* Check lock status */
 		status = this->read_word(this->base + ONENAND_REG_WP_STATUS);
-		if (!(status & ONENAND_WP_US))
+		if (!(status & ONENAND_WP_US)) {
 			printk(KERN_ERR "block = %d, wp status = 0x%x\n", block, status);
+			return 0;
+		}
 	}
+
+	return 1;
 }
 
 /**
@@ -2081,9 +2085,11 @@ static void onenand_check_lock_status(struct onenand_chip *this)
  *
  * Unlock all blocks
  */
-static int onenand_unlock_all(struct mtd_info *mtd)
+static void onenand_unlock_all(struct mtd_info *mtd)
 {
 	struct onenand_chip *this = mtd->priv;
+	loff_t ofs = 0;
+	size_t len = this->chipsize;
 
 	if (this->options & ONENAND_HAS_UNLOCK_ALL) {
 		/* Set start block address */
@@ -2099,23 +2105,19 @@ static int onenand_unlock_all(struct mtd_info *mtd)
 		    & ONENAND_CTRL_ONGO)
 			continue;
 
+		/* Check lock status */
+		if (onenand_check_lock_status(this))
+			return;
+
 		/* Workaround for all block unlock in DDP */
 		if (ONENAND_IS_DDP(this)) {
-			/* 1st block on another chip */
-			loff_t ofs = this->chipsize >> 1;
-			size_t len = mtd->erasesize;
-
-			onenand_do_lock_cmd(mtd, ofs, len, ONENAND_CMD_UNLOCK);
+			/* All blocks on another chip */
+			ofs = this->chipsize >> 1;
+			len = this->chipsize >> 1;
 		}
-
-		onenand_check_lock_status(this);
-
-		return 0;
 	}
 
-	onenand_do_lock_cmd(mtd, 0x0, this->chipsize, ONENAND_CMD_UNLOCK);
-
-	return 0;
+	onenand_do_lock_cmd(mtd, ofs, len, ONENAND_CMD_UNLOCK);
 }
 
 #ifdef CONFIG_MTD_ONENAND_OTP


From sr at denx.de  Wed Feb 13 06:19:52 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 13 Feb 2008 12:19:52 +0100
Subject: [PATCH v2] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
Message-ID: <1202901592-19718-1-git-send-email-sr@denx.de>

The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD] Factor out OF
partition support from the NOR driver.") introduced an problem. Now the
physmap_of driver returns with error upon the first unsuccessful
partition scan (parse_mtd_partitions()). This is not wanted, since even
when the RedBoot/cmdlinepart partition scan is unsuccessful, the other
scan's (of_mtd_parse_partitions(), parse_obsolete_partitions()) should be
done nevertheless.

This patch fixes this problem.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 drivers/mtd/maps/physmap_of.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..09a78ea 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -224,24 +224,16 @@ static int __devinit of_flash_probe(struct of_device *dev,
 	/* First look for RedBoot table or partitions on the command
 	 * line, these take precedence over device tree information */
 	err = parse_mtd_partitions(info->mtd, part_probe_types,
-	                           &info->parts, 0);
-	if (err < 0)
-		return err;
+				   &info->parts, 0);
 
 #ifdef CONFIG_MTD_OF_PARTS
-	if (err == 0) {
+	if (err <= 0)
 		err = of_mtd_parse_partitions(&dev->dev, info->mtd,
-		                              dp, &info->parts);
-		if (err < 0)
-			return err;
-	}
+					      dp, &info->parts);
 #endif
 
-	if (err == 0) {
+	if (err <= 0)
 		err = parse_obsolete_partitions(dev, info, dp);
-		if (err < 0)
-			return err;
-	}
 
 	if (err > 0)
 		add_mtd_partitions(info->mtd, info->parts, err);
-- 
1.5.4.1



From markus.franke at informatik.tu-chemnitz.de  Wed Feb 13 07:30:04 2008
From: markus.franke at informatik.tu-chemnitz.de (Markus Franke)
Date: Wed, 13 Feb 2008 13:30:04 +0100
Subject: dual-port ram driver implementation as MTD device?
Message-ID: <20080213133004.burs2nmq8cwww8ww@mail.tu-chemnitz.de>

Dear MTD developers/users,

I am working on a custom board around the MCF5484 processor and  
uClinux. The processor offers up to six chip-selects for accessing  
external memory devices. A dual-port ram is connected to CS2 and I am  
about to write a proper linux driver for this device. I came across  
MTD and I am wondering whether I should develop an MTD RAM device  
driver (similar to drivers/mtd/chips/map_ram.c) or whether a standard  
linux character device driver would be more appropriate in my  
situation. Any comments on this are appreciated.

With best regards,
Markus Franke




From leon.woestenberg at gmail.com  Wed Feb 13 08:41:50 2008
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Wed, 13 Feb 2008 14:41:50 +0100
Subject: What part of the code puts CFI Flash into write-mode and read-mode?
Message-ID: <c384c5ea0802130541i160a3888pac00f2cdc37222ed@mail.gmail.com>

Hello,

I'ld like to make a trace of whether a CFI FlashROM is in read- or
write mode, but have difficulty understanding where this transition
occurs in the MTD source code.

Can someone give me a pointer?


Regards,
-- 
Leon


From nico at cam.org  Wed Feb 13 08:54:39 2008
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 13 Feb 2008 08:54:39 -0500 (EST)
Subject: What part of the code puts CFI Flash into write-mode and
	read-mode?
In-Reply-To: <c384c5ea0802130541i160a3888pac00f2cdc37222ed@mail.gmail.com>
References: <c384c5ea0802130541i160a3888pac00f2cdc37222ed@mail.gmail.com>
Message-ID: <alpine.LFD.1.00.0802130853200.2732@xanadu.home>

On Wed, 13 Feb 2008, Leon Woestenberg wrote:

> Hello,
> 
> I'ld like to make a trace of whether a CFI FlashROM is in read- or
> write mode, but have difficulty understanding where this transition
> occurs in the MTD source code.
> 
> Can someone give me a pointer?

Searrch for lines that look like:

	chip->state = FL_WRITING;

or

	chip->state = FL_WRITING_TO_BUFFER;

Etc.


Nicolas


From bunk at kernel.org  Wed Feb 13 16:30:08 2008
From: bunk at kernel.org (Adrian Bunk)
Date: Wed, 13 Feb 2008 23:30:08 +0200
Subject: [2.6 patch] mtdoops.c: make struct oops_cxt static again
Message-ID: <20080213213008.GW3383@cs181133002.pp.htv.fi>

struct oops_cxt needlessly became global.

Signed-off-by: Adrian Bunk <bunk at kernel.org>

---
--- linux-2.6/drivers/mtd/mtdoops.c.old	2008-02-11 23:19:45.000000000 +0200
+++ linux-2.6/drivers/mtd/mtdoops.c	2008-02-11 23:19:55.000000000 +0200
@@ -23,31 +23,31 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/console.h>
 #include <linux/vmalloc.h>
 #include <linux/workqueue.h>
 #include <linux/sched.h>
 #include <linux/wait.h>
 #include <linux/delay.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
 #include <linux/mtd/mtd.h>
 
 #define OOPS_PAGE_SIZE 4096
 
-struct mtdoops_context {
+static struct mtdoops_context {
 	int mtd_index;
 	struct work_struct work_erase;
 	struct work_struct work_write;
 	struct mtd_info *mtd;
 	int oops_pages;
 	int nextpage;
 	int nextcount;
 
 	void *oops_buf;
 
 	/* writecount and disabling ready are spin lock protected */
 	spinlock_t writecount_lock;
 	int ready;
 	int writecount;
 } oops_cxt;


From bunk at kernel.org  Wed Feb 13 16:30:10 2008
From: bunk at kernel.org (Adrian Bunk)
Date: Wed, 13 Feb 2008 23:30:10 +0200
Subject: [2.6 patch] make mtd/nand/cs553x_nand.c:part_probes[] static
Message-ID: <20080213213010.GX3383@cs181133002.pp.htv.fi>

This patch makes the needlessly global part_probes[] static.

Signed-off-by: Adrian Bunk <bunk at kernel.org>

---
054adb5b7a0d1ebaef61192ccf78df37aec42270 diff --git a/drivers/mtd/nand/cs553x_nand.c b/drivers/mtd/nand/cs553x_nand.c
index 8dab696..3370a80 100644
--- a/drivers/mtd/nand/cs553x_nand.c
+++ b/drivers/mtd/nand/cs553x_nand.c
@@ -279,7 +279,7 @@ static int is_geode(void)
 
 
 #ifdef CONFIG_MTD_PARTITIONS
-const char *part_probes[] = { "cmdlinepart", NULL };
+static const char *part_probes[] = { "cmdlinepart", NULL };
 #endif
 
 



From hamish at cloud.net.au  Wed Feb 13 23:30:35 2008
From: hamish at cloud.net.au (Hamish Moffatt)
Date: Thu, 14 Feb 2008 15:30:35 +1100
Subject: Redboot FIS entry upgrade from Linux
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A4E3A9955@venus.imagineil.tv>
References: <FF584854D6FFE547AB2F7515A798AC3A4E3A9955@venus.imagineil.tv>
Message-ID: <20080214043035.GB1449@cloud.net.au>

On Sun, Jan 13, 2008 at 06:31:20PM +0200, Jacob Avraham wrote:
> Hi,
> 
> Say I have a zImage or ramdisk image as a file listed in FIS,
> which I use to  "fis load" from Redboot.
> Now I want to upgrade an image from Linux, so in addition to
> writing into the specific mtd partition I need to update the FIS
> directory entry checksum value.
> 
> Are there any utils to facilitate that?
> Or maybe such where not developed because it's not a good idea?

(Sorry, I'm a bit behind on this list.)

There's a utility here which can modify the RedBoot FIS table:
http://svn.chezphil.org/utils/trunk/fis.c

I added support for updating the checksums. You can get my patch here:
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/package/fis/fis-001-checksum.patch?rev=20951&view=auto

Like you, I update the kernel/initrd from linux then use fis to update
the checksums so that RedBoot will still load the image.

Hamish
-- 
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>


From mart.raudsepp at artecdesign.ee  Thu Feb 14 02:16:47 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Thu, 14 Feb 2008 09:16:47 +0200
Subject: [2.6 patch] make mtd/nand/cs553x_nand.c:part_probes[] static
In-Reply-To: <20080213213010.GX3383@cs181133002.pp.htv.fi>
References: <20080213213010.GX3383@cs181133002.pp.htv.fi>
Message-ID: <1202973407.4560.3.camel@martr-gentoo.artec>


?hel kenal p?eval, K, 2008-02-13 kell 23:30, kirjutas Adrian Bunk:
> This patch makes the needlessly global part_probes[] static.
> 
> Signed-off-by: Adrian Bunk <bunk at kernel.org>

Acked-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

Note that many other drivers in mtd/nand have the same part_probes array
global instead of static.




From jacmet at sunsite.dk  Thu Feb 14 07:49:04 2008
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Thu, 14 Feb 2008 13:49:04 +0100
Subject: [PATCH] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <200802122037.27864.sr@denx.de> (Stefan Roese's message of "Tue\,
	12 Feb 2008 20\:37\:27 +0100")
References: <1202832181-1783-1-git-send-email-sr@denx.de>
	<200802122015.08811.sr@denx.de> <47B1F30E.4000509@freescale.com>
	<200802122037.27864.sr@denx.de>
Message-ID: <87wsp7r9dr.fsf@macbook.be.48ers.dk>

>>>>> "Stefan" == Stefan Roese <sr at denx.de> writes:

 Stefan> On Tuesday 12 February 2008, Scott Wood wrote:
 >> >> Under what conditions are you actually seeing this fail?
 >> >
 >> > When CONFIG_MTD_REDBOOT_PARTS is not defined for example it returns with
 >> > -22 (EINVAL).
 >> 
 >> Ah, I see -- it seems the cmdline partition code behaves differently
 >> than the redboot code.
 >> 
 >> Your patch changes it to treat zero as success, however -- which breaks
 >> some other cases.  The test should be "err <= 0", which is what
 >> parse_mtd_partiitions() itself uses in its loop.

 Stefan> OK, I'll fixup another version of this patch tomorrow.

I would prefer to fix up cmdlinepart.c instead, as missing cmdline
data isn't really an error.

>From 7cc1d55f9704a9df1053aefd21fd5db98ac4c983 Mon Sep 17 00:00:00 2001
From: Peter Korsgaard <jacmet at sunsite.dk>
Date: Thu, 14 Feb 2008 13:46:13 +0100
Subject: [PATCH] cmdlinepart: Missing partition info is not an error

Return 0 partitions instead of -EINVAL on no mtdpart= argument on kernel
cmdline or missing partition info for device.
---
 drivers/mtd/cmdlinepart.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index b44292a..08b82c9 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -308,9 +308,6 @@ static int parse_cmdline_partitions(struct mtd_info *master,
 	struct cmdline_mtd_partition *part;
 	char *mtd_id = master->name;
 
-	if(!cmdline)
-		return -EINVAL;
-
 	/* parse command line */
 	if (!cmdline_parsed)
 		mtdpart_setup_real(cmdline);
@@ -341,7 +338,7 @@ static int parse_cmdline_partitions(struct mtd_info *master,
 			return part->num_parts;
 		}
 	}
-	return -EINVAL;
+	return 0;
 }
 
 
-- 
debian.1.5.3.7.1-dirty


-- 
Bye, Peter Korsgaard


From jacmet at sunsite.dk  Thu Feb 14 09:14:49 2008
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Thu, 14 Feb 2008 15:14:49 +0100
Subject: [PATCH v2] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <1202901592-19718-1-git-send-email-sr@denx.de> (Stefan Roese's
	message of "Wed\, 13 Feb 2008 12\:19\:52 +0100")
References: <1202901592-19718-1-git-send-email-sr@denx.de>
Message-ID: <87skzvr5eu.fsf@macbook.be.48ers.dk>

>>>>> "Stefan" == Stefan Roese <sr at denx.de> writes:

 Stefan> The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD]
 Stefan> Factor out OF partition support from the NOR driver.")
 Stefan> introduced an problem. Now the physmap_of driver returns with
 Stefan> error upon the first unsuccessful partition scan
 Stefan> (parse_mtd_partitions()). This is not wanted, since even when
 Stefan> the RedBoot/cmdlinepart partition scan is unsuccessful, the
 Stefan> other scan's (of_mtd_parse_partitions(),
 Stefan> parse_obsolete_partitions()) should be done nevertheless.

Doesn't it make more sense to fix the real problem (E.G. cmdlinepart.c
flagging missing partition info as an error) - See the patch I posted
earlier today.

-- 
Bye, Peter Korsgaard


From sr at denx.de  Thu Feb 14 10:44:06 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 14 Feb 2008 16:44:06 +0100
Subject: [PATCH v2] mtd: Fix physmap_of to not exit upon unsuccessful
	partition scan
In-Reply-To: <87skzvr5eu.fsf@macbook.be.48ers.dk>
References: <1202901592-19718-1-git-send-email-sr@denx.de>
	<87skzvr5eu.fsf@macbook.be.48ers.dk>
Message-ID: <200802141644.07115.sr@denx.de>

On Thursday 14 February 2008, Peter Korsgaard wrote:
> >>>>> "Stefan" == Stefan Roese <sr at denx.de> writes:
>
>  Stefan> The patch 9a310d21196f38f6ad0ad146057548653e495c09 ("[MTD]
>  Stefan> Factor out OF partition support from the NOR driver.")
>  Stefan> introduced an problem. Now the physmap_of driver returns with
>  Stefan> error upon the first unsuccessful partition scan
>  Stefan> (parse_mtd_partitions()). This is not wanted, since even when
>  Stefan> the RedBoot/cmdlinepart partition scan is unsuccessful, the
>  Stefan> other scan's (of_mtd_parse_partitions(),
>  Stefan> parse_obsolete_partitions()) should be done nevertheless.
>
> Doesn't it make more sense to fix the real problem (E.G. cmdlinepart.c
> flagging missing partition info as an error) - See the patch I posted
> earlier today.

Yes, this is probably even better. I just tested it successfully on my board.

Do you plan to post a "real patch" with Signed-off-by? You can add my Acked-by 
too then.

BTW: I would really like to see one of the solutions go into 2.6.25 since it's 
really a bug fix.

Thanks.

Best regards,
Stefan


From jacmet at sunsite.dk  Thu Feb 14 11:00:10 2008
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Thu, 14 Feb 2008 17:00:10 +0100
Subject: [PATCH] cmdlinepart: Missing partition info is not an error
Message-ID: <87lk5nr0j9.fsf@macbook.be.48ers.dk>

Return 0 partitions instead of -EINVAL on no mtdpart= argument in kernel
cmdline or missing partition info for device.

Signed-off-by: Peter Korsgaard <jacmet at sunsite.dk>
Acked-by: Stefan Roese <sr at denx.de>
---
 drivers/mtd/cmdlinepart.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index b44292a..08b82c9 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -308,9 +308,6 @@ static int parse_cmdline_partitions(struct mtd_info *master,
 	struct cmdline_mtd_partition *part;
 	char *mtd_id = master->name;
 
-	if(!cmdline)
-		return -EINVAL;
-
 	/* parse command line */
 	if (!cmdline_parsed)
 		mtdpart_setup_real(cmdline);
@@ -341,7 +338,7 @@ static int parse_cmdline_partitions(struct mtd_info *master,
 			return part->num_parts;
 		}
 	}
-	return -EINVAL;
+	return 0;
 }
 
 
-- 
debian.1.5.3.7.1-dirty


-- 
Bye, Peter Korsgaard


From cliff.brake at gmail.com  Thu Feb 14 14:29:35 2008
From: cliff.brake at gmail.com (Cliff Brake)
Date: Thu, 14 Feb 2008 14:29:35 -0500
Subject: what are correct sumtool and nandwrite options for NAND flash?
Message-ID: <f96d234e0802141129w2a1691dfy949caec909fc25f1@mail.gmail.com>

Hello,

I'm trying to determine the correct sumtool, and nandwrite options for
the following NAND flash device:

root at cm-x270:/usb/tmp$ mtd_debug info /dev/mtd5
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_CAP_NANDFLASH
mtd.size = 67108864 (64M)
mtd.erasesize = 131072 (128K)
mtd.writesize = 2048 (2K)
mtd.oobsize = 64
regions = 0

My question is how do I get the OOB data into the flash image, and
convince nandwrite to use it.  I have been doing the following:

sumtool -i <input_file> -o <output_file> -e  -p;
flash_eraseall -j /dev/mtd5
nandwrite /dev/mtd5 <output_file>

I'm not sure what happens to the OOB data in the input image file when
I use the above method?  Is it simply mixed up in the image and not
actually written to the 64 byte OOB space?  The above method seems to
work, so I have ignored it thus far.

My question is should I be using the nandwrite -o option?  Looking at
the source it does not look like the OOB data gets written to the OOB
region unless this option is used.

if I try:
nandwrite -o /dev/mtd5 <output_file>

I get the following:
Input file is not page aligned
Data was only partially written due to error
: Success

Appreciate any pointers as to the correct way to do this.

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com


From andrey at cozybit.com  Thu Feb 14 15:34:08 2008
From: andrey at cozybit.com (Andrey Yurovsky)
Date: Thu, 14 Feb 2008 12:34:08 -0800
Subject: what are correct sumtool and nandwrite options for NAND flash?
In-Reply-To: <f96d234e0802141129w2a1691dfy949caec909fc25f1@mail.gmail.com>
References: <f96d234e0802141129w2a1691dfy949caec909fc25f1@mail.gmail.com>
Message-ID: <45e8e6c40802141234u23331420yd865322ae7bf02bc@mail.gmail.com>

You don't want OOB data written (-n) in this case.  For this chip, you
have 128KiB erase blocks.  You can make your image:

$ mkfs.jffs2 -e 128KiB -n -p -d somedir -o image-tmp.jffs2

sum it:

$ sumtool  -e 128KiB -n -p -i image-tmp.jffs2 -o image.jffs2

...and write it:

# flash_erase_all /dev/mtdX
# nandwrite /dev/mtdX image.jffs2

  -Andrey

On 2/14/08, Cliff Brake <cliff.brake at gmail.com> wrote:
> Hello,
>
>  I'm trying to determine the correct sumtool, and nandwrite options for
>  the following NAND flash device:
>
>  root at cm-x270:/usb/tmp$ mtd_debug info /dev/mtd5
>  mtd.type = MTD_NANDFLASH
>  mtd.flags = MTD_CAP_NANDFLASH
>  mtd.size = 67108864 (64M)
>  mtd.erasesize = 131072 (128K)
>  mtd.writesize = 2048 (2K)
>  mtd.oobsize = 64
>  regions = 0
>
>  My question is how do I get the OOB data into the flash image, and
>  convince nandwrite to use it.  I have been doing the following:
>
>  sumtool -i <input_file> -o <output_file> -e  -p;
>  flash_eraseall -j /dev/mtd5
>  nandwrite /dev/mtd5 <output_file>
>
>  I'm not sure what happens to the OOB data in the input image file when
>  I use the above method?  Is it simply mixed up in the image and not
>  actually written to the 64 byte OOB space?  The above method seems to
>  work, so I have ignored it thus far.
>
>  My question is should I be using the nandwrite -o option?  Looking at
>  the source it does not look like the OOB data gets written to the OOB
>  region unless this option is used.
>
>  if I try:
>  nandwrite -o /dev/mtd5 <output_file>
>
>  I get the following:
>  Input file is not page aligned
>  Data was only partially written due to error
>  : Success
>
>  Appreciate any pointers as to the correct way to do this.
>
>  Thanks,
>  Cliff
>
>
>  --
>  =======================
>  Cliff Brake
>  http://bec-systems.com
>
>  ______________________________________________________
>  Linux MTD discussion mailing list
>  http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From bbarnett at dash.net  Thu Feb 14 15:44:04 2008
From: bbarnett at dash.net (Blair Barnett)
Date: Thu, 14 Feb 2008 12:44:04 -0800
Subject: what are correct sumtool and nandwrite options for NAND flash?
In-Reply-To: <f96d234e0802141129w2a1691dfy949caec909fc25f1@mail.gmail.com>
References: <f96d234e0802141129w2a1691dfy949caec909fc25f1@mail.gmail.com>
Message-ID: <1203021844.5507.29.camel@bbarnett-desktop>

On Thu, 2008-02-14 at 14:29 -0500, Cliff Brake wrote:
> Hello,
> 
> I'm trying to determine the correct sumtool, and nandwrite options for
> the following NAND flash device:
> 
> root at cm-x270:/usb/tmp$ mtd_debug info /dev/mtd5
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 67108864 (64M)
> mtd.erasesize = 131072 (128K)
> mtd.writesize = 2048 (2K)
> mtd.oobsize = 64
> regions = 0
> 
> My question is how do I get the OOB data into the flash image, and
> convince nandwrite to use it.  I have been doing the following:
> 
> sumtool -i <input_file> -o <output_file> -e  -p;
> flash_eraseall -j /dev/mtd5
> nandwrite /dev/mtd5 <output_file>
> 
> I'm not sure what happens to the OOB data in the input image file when
> I use the above method?  Is it simply mixed up in the image and not
> actually written to the 64 byte OOB space?  The above method seems to
> work, so I have ignored it thus far.
> 
> My question is should I be using the nandwrite -o option?  Looking at
> the source it does not look like the OOB data gets written to the OOB
> region unless this option is used.
> 
> if I try:
> nandwrite -o /dev/mtd5 <output_file>
> 
> I get the following:
> Input file is not page aligned
> Data was only partially written due to error
> : Success
> 
> Appreciate any pointers as to the correct way to do this.
> 
> Thanks,
> Cliff
> 

Hi Cliff,

sumtool doesn't create an image with embedded OOB data by default. You
can check for yourself by doing a hexdump of the image and looking at
the data that is placed at 2049 (1 byte after the first 2k page. If OOB
data is there, it will be obvious. If it's (as I surmise) the next 2k
page, then no oob data is embedded in the image.

I think what you want is 

sumtool -e 131072 -c  -p -i <input_file> -o <output_file>
nandwrite -o -j /dev/mtd5 <output_file>

-blair




From ezk at cs.sunysb.edu  Thu Feb 14 17:16:21 2008
From: ezk at cs.sunysb.edu (Erez Zadok)
Date: Thu, 14 Feb 2008 17:16:21 -0500
Subject: jffs2 console printk storm
Message-ID: <200802142216.m1EMGLDo032715@agora.fsl.cs.sunysb.edu>

Hi David,

This has been a problem I've seen for a while.  I've generated a jffs2 image
of an empty directory (I don't recall the version of the jffs2 utils I've
used to generate it).  I mount the jffs2 image something like this:

# cp jffs2-empty.img /tmp/fs.0
# losetup /dev/loop0 /tmp/fs.0
# modprobe block2mtd block2mtd=/dev/loop0,128ki
# mount -t jffs2 mtd0 /n/lower/b0

Then I start running my tests in it (in /n/lower/b0).  I get a lot of these
two kinds of console printk messages (esp. the first one):

  CLEANMARKER node found at 0x00810000, not first node in block (0x00800000)
  Empty flash at 0x0080ff70 ends at 0x00810000

I don't know how serious the messages are, but jffs2 seems to work fine for
me even with those many kernel messages scrolling off of my screen.  I could
not find a way to turn off these warnings: jffs2's debugging config options
allow me to turn on more messages, but not to turn off these.

Is there a way to prevent these messages from showing up?  Are they serious?
Is my jffs2 image bad/corrupt?  If so, how should I fix it?

In the mean time, I've been using the small patch below to turn the above
two messages into jffs2 debugging messages.

Thanks,
Erez.


diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 272872d..16f428c 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -646,8 +646,8 @@ scan_more:
 			inbuf_ofs = ofs - buf_ofs;
 			while (inbuf_ofs < scan_end) {
 				if (unlikely(*(uint32_t *)(&buf[inbuf_ofs]) != 0xffffffff)) {
-					printk(KERN_WARNING "Empty flash at 0x%08x ends at 0x%08x\n",
-					       empty_start, ofs);
+					D1(printk(KERN_WARNING "Empty flash at 0x%08x ends at 0x%08x\n",
+						  empty_start, ofs));
 					if ((err = jffs2_scan_dirty_space(c, jeb, ofs-empty_start)))
 						return err;
 					goto scan_more;
@@ -840,7 +840,7 @@ scan_more:
 					return err;
 				ofs += PAD(sizeof(struct jffs2_unknown_node));
 			} else if (jeb->first_node) {
-				printk(KERN_NOTICE "CLEANMARKER node found at 0x%08x, not first node in block (0x%08x)\n", ofs, jeb->offset);
+				D1(printk(KERN_NOTICE "CLEANMARKER node found at 0x%08x, not first node in block (0x%08x)\n", ofs, jeb->offset));
 				if ((err = jffs2_scan_dirty_space(c, jeb, PAD(sizeof(struct jffs2_unknown_node)))))
 					return err;
 				ofs += PAD(sizeof(struct jffs2_unknown_node));


From kmpark at infradead.org  Fri Feb 15 02:12:22 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Fri, 15 Feb 2008 16:12:22 +0900
Subject: Abnormal behavior with JFFS2 on latest kernel
Message-ID: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>

Hi,

I got following messages.
INFO: task pdflush:56 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

What are the meanings?
Too mush running GC in JFFS2 or others?

BR,
Kyungmin Park

/ # /mtd-utils/eraseall /dev/mtd4
/ # mount -t jffs2 /dev/mtdblock4 /jffs2
/ # iozone -A -s 128m -q 32k -U /jffs2 -f /jffs2/test -e
        Iozone: Performance Test of File I/O
                Version $Revision: 3.260 $
                Compiled for 32 bit mode.
                Build: linux-arm

	Run began: Fri Feb 15 15:39:56 2008

        Auto Mode 2. This option is obsolete. Use -az -i0 -i1
        File size set to 131072 KB
        Using Maximum Record Size 32 KB
        Include fsync in write timing
        Command line used: iozone -A -s 128m -q 32k -U /jffs2 -f /jffs2/test -e
        Output is in Kbytes/sec
        Time Resolution = 0.000030 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.

              KB  reclen   write rewrite    read    reread
          131072       4    3708    3693    15294    15295
          131072       8    3736    3732    15482    15479
          131072      16INFO: task pdflush:56 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
pdflush       D c0216a1c     0    56      2
[<c0216680>] (schedule+0x0/0x41c) from [<c0216f68>] (io_schedule+0x2c/0x48)
[<c0216f3c>] (io_schedule+0x0/0x48) from [<c0063b54>] (sync_page+0x50/0x5c)
 r5:00000000 r4:c3c63c38
[<c0063b04>] (sync_page+0x0/0x5c) from [<c02172b8>] (__wait_on_bit_lock+0x60/0x)
[<c0217258>] (__wait_on_bit_lock+0x0/0x94) from [<c006469c>] (__lock_page+0x88/)
[<c0064614>] (__lock_page+0x0/0x98) from [<c00654ac>] (read_cache_page_async+0x)
 r5:00000000 r4:c03178c0
[<c006536c>] (read_cache_page_async+0x0/0x1b8) from [<c0124fcc>] (jffs2_gc_fetc)
[<c0124fa0>] (jffs2_gc_fetch_page+0x0/0x64) from [<c0121780>] (jffs2_garbage_co)
 r4:0682c000
[<c0120cd4>] (jffs2_garbage_collect_live+0x0/0x11ac) from [<c01225cc>] (jffs2_g)
[<c0121e80>] (jffs2_garbage_collect_pass+0x0/0x844) from [<c0126b18>] (jffs2_fl)
[<c0126a58>] (jffs2_flush_wbuf_gc+0x0/0x18c) from [<c0124bf8>] (jffs2_write_sup)
 r8:c3c63f40 r7:c02ae520 r6:c02aea94 r5:00000000 r4:c3d22a00
[<c0124bb4>] (jffs2_write_super+0x0/0x48) from [<c008a314>] (sync_supers+0x94/0)
 r5:c3d22c40 r4:c3d22c00
[<c008a280>] (sync_supers+0x0/0xd8) from [<c006b578>] (wb_kupdate+0x54/0x144)
 r6:c02a62d0 r5:c3c63fa0 r4:c3c63fac
[<c006b524>] (wb_kupdate+0x0/0x144) from [<c006c828>] (pdflush+0x118/0x1e8)
 r8:c02a62d0 r7:c02ae560 r6:c3c62000 r5:c3c63fa0 r4:c3c63fac
[<c006c710>] (pdflush+0x0/0x1e8) from [<c0050038>] (kthread+0x54/0x80)
 r8:00000000 r7:00000000 r6:00000000 r5:c006c710 r4:fffffffc
[<c004ffe4>] (kthread+0x0/0x80) from [<c003de0c>] (do_exit+0x0/0x66c)
 r5:00000000 r4:00000000
INFO: task iozone:219 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iozone        D c0216a1c     0   219    215
[<c0216680>] (schedule+0x0/0x41c) from [<c02164d4>] (__down+0xa4/0xfc)
[<c0216430>] (__down+0x0/0xfc) from [<c02163cc>] (__down_failed+0xc/0x20)
 r8:c381ae00 r7:00000000 r6:c381adc0 r5:00000000 r4:0000682a
[<c01182b8>] (jffs2_write_begin+0x0/0x3c0) from [<c00660cc>] (generic_file_buff)
[<c0065fbc>] (generic_file_buffered_write+0x0/0x65c) from [<c0066e58>] (__gener)
[<c0066908>] (__generic_file_aio_write_nolock+0x0/0x580) from [<c0066f00>] (gen)
[<c0066e88>] (generic_file_aio_write+0x0/0xf4) from [<c008870c>] (do_sync_write)
[<c008865c>] (do_sync_write+0x0/0xf4) from [<c0088810>] (vfs_write+0xc0/0xf8)
 r8:c0020224 r7:c3c2ff78 r6:41200000 r5:c3d9a5e0 r4:00004000
[<c0088750>] (vfs_write+0x0/0xf8) from [<c0088904>] (sys_write+0x48/0x74)
 r7:00000004 r6:c3d9a5e0 r5:00000000 r4:06828000
[<c00888bc>] (sys_write+0x0/0x74) from [<c001fa20>] (ret_fast_syscall+0x0/0x2c)
 r6:00000000 r5:00004000 r4:00002000



From joakim.tjernlund at transmode.se  Fri Feb 15 03:47:17 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Fri, 15 Feb 2008 09:47:17 +0100
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
Message-ID: <1203065237.5419.74.camel@gentoo-jocke.transmode.se>


On Fri, 2008-02-15 at 16:12 +0900, Kyungmin Park wrote:
> Hi,
> 
> I got following messages.
> INFO: task pdflush:56 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> 
> What are the meanings?
> Too mush running GC in JFFS2 or others?
> 
> BR,
> Kyungmin Park

It is probably erasing lots of blocks and that takes a while, minutes
some times. I once sent a patch to address this but the patch is racy
w.r.t module unload. Look in the archive after patches from me.

 Jocke


From dedekind at infradead.org  Fri Feb 15 03:54:07 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Fri, 15 Feb 2008 10:54:07 +0200
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
Message-ID: <1203065647.23414.6.camel@sauron>

On Fri, 2008-02-15 at 16:12 +0900, Kyungmin Park wrote:
> I got following messages.
> INFO: task pdflush:56 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> 
> What are the meanings?
> Too mush running GC in JFFS2 or others?

Hi Kyungmin,

did not look at this, but off the top of my head this might be related
to the latest VFS changes (write_begin()/write_end() instead of
prepare_write()/commit_write()). Just a hint where you might try to
look.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From kmpark at infradead.org  Fri Feb 15 03:56:56 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Fri, 15 Feb 2008 17:56:56 +0900
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <1203065237.5419.74.camel@gentoo-jocke.transmode.se>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065237.5419.74.camel@gentoo-jocke.transmode.se>
Message-ID: <005001c86fb0$b9bc6d00$1fa9580a@swcenter.sec.samsung.co.kr>

> > I got following messages.
> > INFO: task pdflush:56 blocked for more than 120 seconds.
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >
> > What are the meanings?
> > Too mush running GC in JFFS2 or others?
> >
> > BR,
> > Kyungmin Park
> 
> It is probably erasing lots of blocks and that takes a while, minutes
> some times. I once sent a patch to address this but the patch is racy
> w.r.t module unload. Look in the archive after patches from me.
> 

You mean this one?
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index d1d4f27..b2e71c7 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -115,7 +115,7 @@ static inline void jffs2_refile_wbuf_blocks(struct jffs2_sb_

                D1(printk(KERN_DEBUG "Removing eraseblock at 0x%08x from erasabl
                list_del(this);
-               if ((jiffies + (n++)) & 127) {
+               if ((jiffies + (n++)) & 127 && !list_empty(&c->erasable_list)) {
                        /* Most of the time, we just erase it immediately. Other
                           spend ages scanning it on mount, etc. */
                        D1(printk(KERN_DEBUG "...and adding to erase_pending_lis

It's already applied, but it's same.

BR,
Kyungmin Park



From joakim.tjernlund at transmode.se  Fri Feb 15 03:59:11 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Fri, 15 Feb 2008 09:59:11 +0100
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <005001c86fb0$b9bc6d00$1fa9580a@swcenter.sec.samsung.co.kr>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065237.5419.74.camel@gentoo-jocke.transmode.se>
	<005001c86fb0$b9bc6d00$1fa9580a@swcenter.sec.samsung.co.kr>
Message-ID: <1203065951.5419.84.camel@gentoo-jocke.transmode.se>


On Fri, 2008-02-15 at 17:56 +0900, Kyungmin Park wrote:
> > > I got following messages.
> > > INFO: task pdflush:56 blocked for more than 120 seconds.
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > >
> > > What are the meanings?
> > > Too mush running GC in JFFS2 or others?
> > >
> > > BR,
> > > Kyungmin Park
> > 
> > It is probably erasing lots of blocks and that takes a while, minutes
> > some times. I once sent a patch to address this but the patch is racy
> > w.r.t module unload. Look in the archive after patches from me.
> > 
> 
> You mean this one?
> diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
> index d1d4f27..b2e71c7 100644
> --- a/fs/jffs2/wbuf.c
> +++ b/fs/jffs2/wbuf.c
> @@ -115,7 +115,7 @@ static inline void jffs2_refile_wbuf_blocks(struct jffs2_sb_
> 
>                 D1(printk(KERN_DEBUG "Removing eraseblock at 0x%08x from erasabl
>                 list_del(this);
> -               if ((jiffies + (n++)) & 127) {
> +               if ((jiffies + (n++)) & 127 && !list_empty(&c->erasable_list)) {
>                         /* Most of the time, we just erase it immediately. Other
>                            spend ages scanning it on mount, etc. */
>                         D1(printk(KERN_DEBUG "...and adding to erase_pending_lis
> 
> It's already applied, but it's same.

Nope, the patch is probably named 
"[JFFS2] Stop erasing blocks when rebooting."

  Jocke


From kmpark at infradead.org  Fri Feb 15 04:02:23 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Fri, 15 Feb 2008 18:02:23 +0900
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <1203065647.23414.6.camel@sauron>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065647.23414.6.camel@sauron>
Message-ID: <005601c86fb1$7c79f100$1fa9580a@swcenter.sec.samsung.co.kr>

> On Fri, 2008-02-15 at 16:12 +0900, Kyungmin Park wrote:
> > I got following messages.
> > INFO: task pdflush:56 blocked for more than 120 seconds.
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >
> > What are the meanings?
> > Too mush running GC in JFFS2 or others?
> 
> Hi Kyungmin,
> 
> did not look at this, but off the top of my head this might be related
> to the latest VFS changes (write_begin()/write_end() instead of
> prepare_write()/commit_write()). Just a hint where you might try to
> look.
> 

Then can I use the ubifs? I mean ubifs is already changed for latest VFS changes.
Now I just want to test new driver with latest kernel.

Thank you,
Kyungmin Park



From dedekind at infradead.org  Fri Feb 15 04:08:58 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Fri, 15 Feb 2008 11:08:58 +0200
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <005601c86fb1$7c79f100$1fa9580a@swcenter.sec.samsung.co.kr>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065647.23414.6.camel@sauron>
	<005601c86fb1$7c79f100$1fa9580a@swcenter.sec.samsung.co.kr>
Message-ID: <1203066538.23414.11.camel@sauron>

On Fri, 2008-02-15 at 18:02 +0900, Kyungmin Park wrote:
> > On Fri, 2008-02-15 at 16:12 +0900, Kyungmin Park wrote:
> > > I got following messages.
> > > INFO: task pdflush:56 blocked for more than 120 seconds.
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > >
> > > What are the meanings?
> > > Too mush running GC in JFFS2 or others?
> > 
> > Hi Kyungmin,
> > 
> > did not look at this, but off the top of my head this might be related
> > to the latest VFS changes (write_begin()/write_end() instead of
> > prepare_write()/commit_write()). Just a hint where you might try to
> > look.
> > 
> 
> Then can I use the ubifs? I mean ubifs is already changed for latest VFS changes.
> Now I just want to test new driver with latest kernel.

No, in opposite, we have not changed it yet. The old calls were not
removed from VFS and will be kept there for few releases. So we still
use them - this helps to use the same UBIFS sources for older kernels.
But later we'll switch to newer calls which are in fact much better for
UBIFS then the old ones.

But yes, you of course can use UBIFS.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From thomas.petazzoni at free-electrons.com  Thu Feb 14 10:50:25 2008
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 14 Feb 2008 16:50:25 +0100
Subject: [PATCH] mtd: fix minor typo in the MTD map driver for SHARP SL series
Message-ID: <20080214165025.765f0637@crazy>

Hi,

Here is a small patch to fix a minor typo in the MTD map driver for
Sharp SL series devices.

Thanks,

Thomas

---

Fix minor typo in printk() message in the MTD map driver for Sharp SL
series devices.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/mtd/maps/sharpsl-flash.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/drivers/mtd/maps/sharpsl-flash.c
===================================================================
--- linux.orig/drivers/mtd/maps/sharpsl-flash.c
+++ linux/drivers/mtd/maps/sharpsl-flash.c
@@ -92,7 +92,7 @@
 	parts = sharpsl_partitions;
 	nb_parts = ARRAY_SIZE(sharpsl_partitions);
 
-	printk(KERN_NOTICE "Using %s partision definition\n", part_type);
+	printk(KERN_NOTICE "Using %s partition definition\n", part_type);
 	add_mtd_partitions(mymtd, parts, nb_parts);
 
 	return 0;

-- 
Thomas Petazzoni, Free Electrons
Free Embedded Linux Training Materials
on http://free-electrons.com/training
(More than 1500 pages!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080214/1cc692ab/attachment.bin 

From vicky.irobot at gmail.com  Fri Feb  8 05:31:55 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Fri, 08 Feb 2008 16:01:55 +0530
Subject: mtdblock mount issue
In-Reply-To: <loom.20080207T155530-907@post.gmane.org>
References: <47A71EF4.2090202@gmail.com>
	<loom.20080207T155530-907@post.gmane.org>
Message-ID: <47AC2F9B.60009@gmail.com>

Sergei Sharonov wrote:
>> I am trying to mount a cramfs partition from flash. 
>>     
>
> A word of warning. CRAMFS is broken in kernels < 2.6.18. As far as I can tell,
> under heavy load (e.g. reading multiple files in parallel that are not cached)
> it may fail with decompression errors. I think the issue is not exactly with
> cramfs but with some interaction with page cache. Backporting just cramfs files
> to 2.6.15 did not help. If you have drop_caches interface (kernel > 2.6.16 or
> just backport it) it is easy to reproduce. Otherwise it happens _very_
> infrequently because most of the time files are already cached. However the
> consequences are severe - corrupted executables, etc.
> Here is a script to reproduce the problem:
>
> ===============================================
> # Copy large file from cramfs to tmpfs
> cp /bin/smbd /tmp/
>
> # First concurrent access to files/directories 
> while [ 1 ]; do cat /bin/* > /dev/null; done &
>
> # Second concurrent access to test file and cache flush
> for((i=0;i<99999;i++)) do echo -n "cycle=$i "; 
>   cmp /bin/smbd /tmp/smbd ; 
>   echo 3 > /proc/sys/vm/drop_caches ; 
> done
> ===============================================
>
> Note that /bin is in cramfs. smbd can be any large file.
> I've also seen statements that drop_caches interface is not 100% reliable.
> Nevertheless I have experienced decompression errors even without forcing 
> cache purge.
> Above script has caused failures on PowerPC/2.6.16 and ARM9/2.6.15.
> 2.6.18 and 2.6.23 seem ok.
>
> Regards,
>
> Sergei 
>
> P.S. Yes, cramfs has little to do with MTD but since ppl here use it with flash
> I felt it was a good idea to post this warning.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>   
thanks for the info. I think I will check out squashfs then.

But before that I wanted to fix the issue that I am seeing. There might 
be something wrong in my implementation?

BTW I thought this was the right mailing list, since I am trying to 
mount cramfs image using MTD. Can you point me to the right mailing list?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 48 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080208/6ead3ec8/attachment.vcf 

From vicky.irobot at gmail.com  Fri Feb  8 05:40:15 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Fri, 08 Feb 2008 16:10:15 +0530
Subject: Is mtdblock_ro to be used only with 512byte page size flash only?
Message-ID: <47AC318F.2040909@gmail.com>

In mtdblock_ro code, mtdblock_readsect function calls mtd->read passing 
a hard coded parameter of 512 (the third parameter).

Is this refering to 512 bytes data which is like one page in case of the 
flash I am using? If that is the case then can this block RO code be 
used only with flash which has a 512 data size?

M.S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 48 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080208/a58eff76/attachment.vcf 

From vicky.irobot at gmail.com  Fri Feb  8 06:22:44 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Fri, 08 Feb 2008 16:52:44 +0530
Subject: Is mtdblock_ro to be used only with 512byte page size flash only?
In-Reply-To: <47AC318F.2040909@gmail.com>
References: <47AC318F.2040909@gmail.com>
Message-ID: <47AC3B84.30501@gmail.com>

Max Stirling wrote:
> In mtdblock_ro code, mtdblock_readsect function calls mtd->read 
> passing a hard coded parameter of 512 (the third parameter).
>
> Is this refering to 512 bytes data which is like one page in case of 
> the flash I am using? If that is the case then can this block RO code 
> be used only with flash which has a 512 data size?
>
> M.S
Ok this is the sector size.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 48 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080208/18ab7e4d/attachment.vcf 

From vicky.irobot at gmail.com  Tue Feb 12 07:52:32 2008
From: vicky.irobot at gmail.com (Max Stirling)
Date: Tue, 12 Feb 2008 18:22:32 +0530
Subject: how to mount this mtd filesystem image?
In-Reply-To: <47B07A44.6030003@enst-bretagne.fr>
References: <47B07A44.6030003@enst-bretagne.fr>
Message-ID: <47B19690.10009@gmail.com>

Christophe Lohr wrote:
> Hi,
> I?m not sure to be on the right mailing list?
>
> My problem is as follow: I have an mtd dump file. This is not a jffs2 
> file system image. It looks like a plain old flash file system, but 
> which one? How may I get the content of this file system?
>
> 00000000 46 66 73 23 00 03 01 00 c0 ff ff ff ff ff ff ff |Ffs#............|
> 00000010 2f 66 66 73 2d 72 6f 6f 74 00 ff ff ff ff ff ff |/ffs-root.......|
> 00000020 2e 6a 6f 75 72 6e 61 6c 00 ff ff ff c0 00 03 00 |.journal........|
> 00000030 02 00 00 00 c0 00 04 00 03 00 00 00 c0 00 05 00 |................|
> 00000040 04 00 00 00 c0 00 06 00 05 00 00 00 c0 00 07 00 |................|
> 00000050 06 00 00 00 c0 00 08 00 07 00 00 00 c0 00 09 00 |................|
> (...)
>
> Any help is welcome.
> Thanks and regards.
> Christophe
>
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>   
The first four bytes are the magic numbers telling which flash fs this 
might be.

00000000 46 66 73 23


#define CRAMFS_MAGIC    0x28cd3d45


I did a search for those numbers and couldn't find any reference to this 
anywhere. Try doing "file <your-mtd-dump-file> this might give more 
information

for eg:

->file test.cramfs.img
test.cramfs.img: Linux Compressed ROM File System data, little endian 
size 65536 version #2 sorted_dirs CRC 0xf23fc956, edition 0, 46 blocks, 
16 files.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: vicky_irobot.vcf
Type: text/x-vcard
Size: 48 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080212/803972f3/attachment.vcf 

From kmpark at infradead.org  Fri Feb 15 04:35:20 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Fri, 15 Feb 2008 18:35:20 +0900
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <1203065951.5419.84.camel@gentoo-jocke.transmode.se>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065237.5419.74.camel@gentoo-jocke.transmode.se>
	<005001c86fb0$b9bc6d00$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065951.5419.84.camel@gentoo-jocke.transmode.se>
Message-ID: <007d01c86fb6$1705db90$1fa9580a@swcenter.sec.samsung.co.kr>

> 
> Nope, the patch is probably named
> "[JFFS2] Stop erasing blocks when rebooting."
> 

No it's same; we have to find another one.

KB  reclen   write rewrite    read    reread
          131072       4    3420    3683    15320    15341
          131072       8INFO: task iozone:227 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iozone        D c021685c     0   227    222
[<c02164c0>] (schedule+0x0/0x41c) from [<c0216314>] (__down+0xa4/0xfc)
[<c0216270>] (__down+0x0/0xfc) from [<c021620c>] (__down_failed+0xc/0x20)
 r8:c3815c70 r7:00000000 r6:c3815c30 r5:00000000 r4:00004078
[<c01182b8>] (jffs2_write_begin+0x0/0x3c0) from [<c00660cc>] (generic_file_buff)
[<c0065fbc>] (generic_file_buffered_write+0x0/0x65c) from [<c0066e58>] (__gener)
[<c0066908>] (__generic_file_aio_write_nolock+0x0/0x580) from [<c0066f00>] (gen)
[<c0066e88>] (generic_file_aio_write+0x0/0xf4) from [<c008870c>] (do_sync_write)
[<c008865c>] (do_sync_write+0x0/0xf4) from [<c0088810>] (vfs_write+0xc0/0xf8)
 r8:c0020224 r7:c3d5df78 r6:41200000 r5:c3d9a220 r4:00002000
[<c0088750>] (vfs_write+0x0/0xf8) from [<c0088904>] (sys_write+0x48/0x74)
 r7:00000004 r6:c3d9a220 r5:00000000 r4:04078000
[<c00888bc>] (sys_write+0x0/0x74) from [<c001fa20>] (ret_fast_syscall+0x0/0x2c)
 r6:00000000 r5:00002000 r4:00004000
INFO: task jffs2_gcd_mtd4:257 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jffs2_gcd_mtd D c021685c     0   257      2
[<c02164c0>] (schedule+0x0/0x41c) from [<c0216da8>] (io_schedule+0x2c/0x48)
[<c0216d7c>] (io_schedule+0x0/0x48) from [<c0063b54>] (sync_page+0x50/0x5c)
 r5:00000000 r4:c3f07cb0
[<c0063b04>] (sync_page+0x0/0x5c) from [<c02170f8>] (__wait_on_bit_lock+0x60/0x)
[<c0217098>] (__wait_on_bit_lock+0x0/0x94) from [<c006469c>] (__lock_page+0x88/)
[<c0064614>] (__lock_page+0x0/0x98) from [<c00654ac>] (read_cache_page_async+0x)
 r5:00000000 r4:c0320ea0
[<c006536c>] (read_cache_page_async+0x0/0x1b8) from [<c0124fcc>] (jffs2_gc_fetc)
[<c0124fa0>] (jffs2_gc_fetch_page+0x0/0x64) from [<c0121758>] (jffs2_garbage_co)
 r4:0407a000
[<c0120cac>] (jffs2_garbage_collect_live+0x0/0x11ac) from [<c01225a4>] (jffs2_g)
[<c0121e58>] (jffs2_garbage_collect_pass+0x0/0x844) from [<c0123cb0>] (jffs2_ga)
[<c0123b88>] (jffs2_garbage_collect_thread+0x0/0x168) from [<c003de0c>] (do_exi)
 r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:00000000

Thank you,
Kyungmin Park



From joakim.tjernlund at transmode.se  Fri Feb 15 04:49:47 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Fri, 15 Feb 2008 10:49:47 +0100
Subject: Abnormal behavior with JFFS2 on latest kernel
In-Reply-To: <007d01c86fb6$1705db90$1fa9580a@swcenter.sec.samsung.co.kr>
References: <004601c86fa2$201a78d0$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065237.5419.74.camel@gentoo-jocke.transmode.se>
	<005001c86fb0$b9bc6d00$1fa9580a@swcenter.sec.samsung.co.kr>
	<1203065951.5419.84.camel@gentoo-jocke.transmode.se>
	<007d01c86fb6$1705db90$1fa9580a@swcenter.sec.samsung.co.kr>
Message-ID: <1203068987.5419.94.camel@gentoo-jocke.transmode.se>


On Fri, 2008-02-15 at 18:35 +0900, Kyungmin Park wrote:
> > 
> > Nope, the patch is probably named
> > "[JFFS2] Stop erasing blocks when rebooting."
> > 
> 
> No it's same; we have to find another one.

OK, it was worth a try. Sorry but I don't have
any more ideas.

 Jocke


From bigeasy at tglx.de  Fri Feb 15 06:21:10 2008
From: bigeasy at tglx.de (Sebastian Siewior)
Date: Fri, 15 Feb 2008 12:21:10 +0100
Subject: [PATCH] [MTD] [NAND] add out label in rfc_from4
Message-ID: <20080215112110.GA32528@www.tglx.de>

This has been probably forgotten in commit f5bbdacc419.

Signed-off-by: Sebastian Siewior <bigeasy at linutronix.de>
---
I hope that is the right fix.

 drivers/mtd/nand/rtc_from4.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/rtc_from4.c b/drivers/mtd/nand/rtc_from4.c
index 47429b0..ace1915 100644
--- a/drivers/mtd/nand/rtc_from4.c
+++ b/drivers/mtd/nand/rtc_from4.c
@@ -461,6 +461,7 @@ static int rtc_from4_errstat(struct mtd_info *mtd, struct nand_chip *this,
 		kfree(buf);
 	}
 
+out:
 	rtn = status;
 	if (er_stat == 0) {	/* if ECC is available   */
 		rtn = (status & ~NAND_STATUS_FAIL);	/*   clear the error bit */
-- 
1.5.3.5



From bigeasy at tglx.de  Fri Feb 15 06:24:43 2008
From: bigeasy at tglx.de (Sebastian Siewior)
Date: Fri, 15 Feb 2008 12:24:43 +0100
Subject: [PATCH] [MTD] [NAND] fix possible Ooops in rfc_from4
Message-ID: <20080215112443.GB32528@www.tglx.de>

I found this while I was looking how the rs_lib is working.
The rs_decoder is initialized _after_ the nand core code is reading
BBT and _after_ the adding the partition table. The driver has a
private BBT description which is in located in flash data so we Ooops
if there is a bitflip.

Signed-off-by: Sebastian Siewior <bigeasy at linutronix.de>
---
This patch moves rs_init part two levels up and changes to error
handling to the goto format. Patch is compile tested.

 drivers/mtd/nand/rtc_from4.c |   51 ++++++++++++++++++++++++-----------------
 1 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/rtc_from4.c b/drivers/mtd/nand/rtc_from4.c
index 9189ec8..47429b0 100644
--- a/drivers/mtd/nand/rtc_from4.c
+++ b/drivers/mtd/nand/rtc_from4.c
@@ -478,6 +478,7 @@ static int __init rtc_from4_init(void)
 	struct nand_chip *this;
 	unsigned short bcr1, bcr2, wcr2;
 	int i;
+	int ret;
 
 	/* Allocate memory for MTD device structure and private data */
 	rtc_from4_mtd = kmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
@@ -537,6 +538,22 @@ static int __init rtc_from4_init(void)
 	this->ecc.hwctl = rtc_from4_enable_hwecc;
 	this->ecc.calculate = rtc_from4_calculate_ecc;
 	this->ecc.correct = rtc_from4_correct_data;
+
+	/* We could create the decoder on demand, if memory is a concern.
+	 * This way we have it handy, if an error happens
+	 *
+	 * Symbolsize is 10 (bits)
+	 * Primitve polynomial is x^10+x^3+1
+	 * first consecutive root is 0
+	 * primitve element to generate roots = 1
+	 * generator polinomial degree = 6
+	 */
+	rs_decoder = init_rs(10, 0x409, 0, 1, 6);
+	if (!rs_decoder) {
+		printk(KERN_ERR "Could not create a RS decoder\n");
+		ret = -ENOMEM;
+		goto err_1;
+	}
 #else
 	printk(KERN_INFO "rtc_from4_init: using software ECC detection.\n");
 
@@ -549,8 +566,8 @@ static int __init rtc_from4_init(void)
 
 	/* Scan to find existence of the device */
 	if (nand_scan(rtc_from4_mtd, RTC_FROM4_MAX_CHIPS)) {
-		kfree(rtc_from4_mtd);
-		return -ENXIO;
+		ret = -ENXIO;
+		goto err_2;
 	}
 
 	/* Perform 'device recovery' for each chip in case there was a power loss. */
@@ -566,28 +583,20 @@ static int __init rtc_from4_init(void)
 #endif
 
 	/* Register the partitions */
-	add_mtd_partitions(rtc_from4_mtd, partition_info, NUM_PARTITIONS);
+	ret = add_mtd_partitions(rtc_from4_mtd, partition_info, NUM_PARTITIONS);
+	if (ret)
+		goto err_3;
 
-#ifdef RTC_FROM4_HWECC
-	/* We could create the decoder on demand, if memory is a concern.
-	 * This way we have it handy, if an error happens
-	 *
-	 * Symbolsize is 10 (bits)
-	 * Primitve polynomial is x^10+x^3+1
-	 * first consecutive root is 0
-	 * primitve element to generate roots = 1
-	 * generator polinomial degree = 6
-	 */
-	rs_decoder = init_rs(10, 0x409, 0, 1, 6);
-	if (!rs_decoder) {
-		printk(KERN_ERR "Could not create a RS decoder\n");
-		nand_release(rtc_from4_mtd);
-		kfree(rtc_from4_mtd);
-		return -ENOMEM;
-	}
-#endif
 	/* Return happy */
 	return 0;
+err_3:
+	nand_release(rtc_from4_mtd);
+err_2:
+	free_rs(rs_decoder);
+err_1:
+	kfree(rtc_from4_mtd);
+	return ret;
+
 }
 
 module_init(rtc_from4_init);
-- 
1.5.3.5



From gruzdev at nateks.ru  Fri Feb 15 13:26:41 2008
From: gruzdev at nateks.ru (Mikhail Gruzdev)
Date: Fri, 15 Feb 2008 21:26:41 +0300
Subject: How to hardcode NOR Flash parameters (wrong CFI table) ?
Message-ID: <004b01c87000$52c8a050$2f0fa8c0@idle>

Hello.

I have NOR flash chip(Spansion S29GL032N04) with wrong CFI table information 
(Erase Region 2 Information).
My do_map_probe("cfi_probe", &nor_map) function call fails due to geometry 
mismatch.
So I decided to hardcode _all_ flash chip information without any probing at 
all.

Are there any examples? I don't want to miss something while digging into 
mtd sources.
Doesn't it the preferable way for embedded systems?

Thanks! 



From suryavanshivj at LNTEBG.com  Sat Feb 16 02:06:45 2008
From: suryavanshivj at LNTEBG.com (Vanita Suryavanshi)
Date: Sat, 16 Feb 2008 12:36:45 +0530
Subject: cloning jffs2 file system
Message-ID: <47B6D8DD02000076000005C4@EBGMAIL2.MAIL.LNTEBG.COM>

Dear Sir,
Seeking of help.
We have developed jffs2 file system using block2mtd driver.
Our compact flash has 2 partitions.
First partition is boot partition having fat file system.This contains syslinux bootloader and kernel.
Second partition is jffs2 partition, formatted using flash_eraseall -j /dev/mtd0
and put the file system using dd.
Flash is working fine.

But to burn large number flash,this method is not suitable.
So If I have a working flash with jffs2 can I make multiple flash using any tool like norton ghost.
Norton ghost does not support jffs2. Is there any other tool or method for doing this.

Thanks & Regards,

Best Regards,
Vanita Suryavanshi
Design Engineer,
Automation Systems Center,
Navi Mumbai.



From dwmw2 at infradead.org  Sat Feb 16 08:52:32 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 16 Feb 2008 13:52:32 +0000
Subject: jffs2 console printk storm
In-Reply-To: <200802142216.m1EMGLDo032715@agora.fsl.cs.sunysb.edu>
References: <200802142216.m1EMGLDo032715@agora.fsl.cs.sunysb.edu>
Message-ID: <1203169952.31173.110.camel@pmac.infradead.org>


On Thu, 2008-02-14 at 17:16 -0500, Erez Zadok wrote:
> Hi David,
> 
> This has been a problem I've seen for a while.  I've generated a jffs2 image
> of an empty directory (I don't recall the version of the jffs2 utils I've
> used to generate it).  I mount the jffs2 image something like this:
> 
> # cp jffs2-empty.img /tmp/fs.0
> # losetup /dev/loop0 /tmp/fs.0
> # modprobe block2mtd block2mtd=/dev/loop0,128ki
> # mount -t jffs2 mtd0 /n/lower/b0
> 
> Then I start running my tests in it (in /n/lower/b0).  I get a lot of these
> two kinds of console printk messages (esp. the first one):
> 
>   CLEANMARKER node found at 0x00810000, not first node in block (0x00800000)
>   Empty flash at 0x0080ff70 ends at 0x00810000
> 
> I don't know how serious the messages are, but jffs2 seems to work fine for
> me even with those many kernel messages scrolling off of my screen.

Your image is built with the wrong eraseblock size -- mkfs.jffs2
defaults to 64KiB eraseblocks, and you seem to have used that default,
but your flash "device" has 128KiB eraseblocks, since that's the
argument you gave to block2mtd.

Recreate your image with -e128KiB, or change the eraseblock size on your
virtual device.

-- 
dwmw2



From trimarchi at gandalf.sssup.it  Sat Feb 16 08:53:11 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Sat, 16 Feb 2008 14:53:11 +0100
Subject: jffs2 failing after reboot on dataflash. 2.6.24
Message-ID: <47B6EAC7.7070208@gandalf.sssup.it>

Hi,

I use a dataflash for jffs2. The filesystem seems to work correctly but 
at the first reboot
I have some different and some file corruption. This is the different of 
two dump:

9475c9475,9489
< Empty space: 18268, dirty space: 0
---
 > Empty space found from 0x00444cec to 0x00444de0
 >          Inode      node at 0x00444de0, totlen 0x0000041b, #ino    
681, version    67, isize    66031, csize      983, dsize     2701, 
offset    49632
 > Wrong bitmask  at  0x004451fc, 0x0000
 > Empty space found from 0x00445200 to 0x00504f00
 >          Inode      node at 0x00504f00, totlen 0x00000590, #ino    
681, version    68, isize    66031, csize     1356, dsize     3168, 
offset    49632
 >          Inode      node at 0x00505490, totlen 0x00000044, #ino    
681, version    69, isize    66031, csize        0, dsize     1056, 
offset    52800
 >          Inode      node at 0x005054d4, totlen 0x00000531, #ino    
681, version    70, isize    66031, csize     1261, dsize     3168, 
offset    53856
 >          Inode      node at 0x00505a08, totlen 0x00000044, #ino    
681, version    71, isize    66031, csize        0, dsize     1056, 
offset    57024
 >          Inode      node at 0x00505a4c, totlen 0x00000641, #ino    
681, version    72, isize    66031, csize     1533, dsize     3168, 
offset    58080
 >          Inode      node at 0x00506090, totlen 0x00000044, #ino    
681, version    73, isize    66031, csize        0, dsize     1056, 
offset    61248
 >          Inode      node at 0x005060d4, totlen 0x0000063b, #ino    
681, version    74, isize    66031, csize     1527, dsize     3168, 
offset    62304
 >          Inode      node at 0x00506710, totlen 0x00000044, #ino    
681, version    75, isize    66031, csize        0, dsize      559, 
offset    65472
 >          Dirent     node at 0x00506754, totlen 0x00000032, #pino   
673, version   680, #ino       682, nsize       10, name pulldom.py
 >          Padding    node at 0x00506788, totlen 0x00000038
 > Empty space: 2933884, dirty space: 4

The file #ino 681 is corrupted.

The first is the original images creates with mkfs.jffs2, the second one 
is the filesystem after the first reboot. I don't understand
why there new inode created, that invalidate my image.

Regards Michael



From hj.lee.0215 at gmail.com  Sat Feb 16 04:23:20 2008
From: hj.lee.0215 at gmail.com (Hyojeong Lee)
Date: Sat, 16 Feb 2008 18:23:20 +0900
Subject: I want to mount nandsim as vfat using nftl
Message-ID: <d50b16a50802160123u35507765h83524d52ff21c3e4@mail.gmail.com>

I want to mount nandsim as vfat using nftl.
For the reason of my board, I should use linux 2.6.11.9.
And in that version, nftl_format utility is not available.

I compiled MTD, nftl, nandsim and so on.
(nandsim is not tristate in the version of 2.6.11.9 so I couldn't make it as
a module)

I can see
dev:        size     erasesize  name
mtd0:  00800000 0020000 "NAND simulator partition"
in /proc/mtd

and I can see /dev/mtdblock0

I want to make a situation as follows

FAT
-------
NFTL
-------
MTD
-------
NANDSIM


I tried
mknod /dev/nftla b 93 0
mknod /dev/nftla1 b 93 1
fdisk /dev/nftla

but the kernel says that
"Unable to open /dev/nftla"

I tried insmod nftl.ko on every point I could try.
But same error occurs.

What I should do to achieve my goal?
Or where can I get information?

regards,
Hyojeong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/linux-mtd/attachments/20080216/e4998455/attachment.html 

From emillionawardunits at yahoo.de  Sat Feb 16 11:25:34 2008
From: emillionawardunits at yahoo.de (Emily Brooks)
Date: Sat, 16 Feb 2008 10:25:34 -0600 (CST)
Subject: Prize And Award Winning Notification!
Message-ID: <2177.213.185.118.203.1203179134.squirrel@blessedjjireh.serverspeople.net>




Computer Ballot Sweepstakes Email Award 2008.
(Euro million loteria Espanol Award 2008).
www.loteria.com
Paseo De La castellana
15-89, 28008 Madrid.
Spain , Branch.


  YOUR E-MAIL ADDRESS WON THIS YEAR EURO MILLION LOTTERY.


Sir/Madam,

  We wish to congratulate you over your email success in our computer
balloting held on FEBUARY 13TH,2008. This is a Millennium Scientific
Computer Game in which email addresses were used. It is a promotional
program aimed at encouraging internet users; therefore you do not need
to buy ticket to enter for it. You have been approve for the star prize
of ?987,248,00 (Nine Hundred And Eighty Seven Thousand, Two Hundred And
forty Eight Euros Only).To claim your winning prize you are to contact
the appointed claim agent as soon as possible for the immediate release
of your winnings with the following information below:



Name:.............................
Age:..............................
Sex:..............................
Address:..........................
Email:............................
Phone:............................
Occupation:.......................
Company:..........................
Country:..........................


Mr Goodluck Pereda
Liberty Seguros Trust Agency.
Mario Cabre Sin Numero,
28016, Madrid - Spain
E-mail: (goodluckkpereda at aim.com)

Ref No.ES/037/11/06/MD
Batch No: WNTO/7416/VA/ES
Lucky No: 07-13-31.54-640
Serial No: MUOTI/82536

 The Validity period of the winnings is for 20 working days hence you are
expected to make your claims immediately, any claim not made before this
date will be returned to the MINISTERIO DE E CONOMIA Y HACIENDA .

     Note:You are advised to keep this winning very confidential until you
receive your lump prize in your account or optional cheque issuance
to you,This is a protective measure put in place to avoid people
applying for your winnig fund,as we have had cases like this before.


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
The information transmitted is intended only for the person or entity to
whom or which it is addressed.Unauthorised use, disclosure orcopying is
strictly prohibited.The sender accepts no liability for the improper
ransmission of this communication nor for any delay in its receipt.



From 12o3l at tiscali.nl  Sat Feb 16 12:14:35 2008
From: 12o3l at tiscali.nl (Roel Kluin)
Date: Sat, 16 Feb 2008 18:14:35 +0100
Subject: [PATCH] drivers/mtd/onenand/onenand_base.c unlikely(x) || unlikely(y)
	=> unlikely(x || y)
Message-ID: <47B719FB.4020107@tiscali.nl>

Not yet tested.
---
Replace unlikely(x) || unlikely(y) by unlikely(x || y)

Signed-off-by: Roel Kluin <12o3l at tiscali.nl>
---
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 8d7d21b..7334b4a 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1336,7 +1336,7 @@ static int onenand_panic_write(struct mtd_info *mtd, loff_t to, size_t len,
 	}
 
 	/* Reject writes, which are not page aligned */
-        if (unlikely(NOTALIGNED(to)) || unlikely(NOTALIGNED(len))) {
+        if (unlikely(NOTALIGNED(to) || NOTALIGNED(len))) {
                 printk(KERN_ERR "onenand_panic_write: Attempt to write not page aligned data\n");
                 return -EINVAL;
         }
@@ -1466,7 +1466,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
 	}
 
 	/* Reject writes, which are not page aligned */
-        if (unlikely(NOTALIGNED(to)) || unlikely(NOTALIGNED(len))) {
+        if (unlikely(NOTALIGNED(to) || NOTALIGNED(len))) {
                 printk(KERN_ERR "onenand_write_ops_nolock: Attempt to write not page aligned data\n");
                 return -EINVAL;
         }


From cbouatmailru at gmail.com  Sun Feb 17 16:37:34 2008
From: cbouatmailru at gmail.com (Anton Vorontsov)
Date: Mon, 18 Feb 2008 00:37:34 +0300
Subject: [PATCH] mtd: maps/physmap: fix oops in suspend/resume/shutdown ops
Message-ID: <20080217213734.GA4091@zarina>

- - - -
# reboot
...
[   42.351266] Flash device refused suspend due to active operation (state 0)
[   42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078
[   42.360060] pgd = c7d9c000
[   42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000
[   42.372902] Internal error: Oops: 17 [#1]
[   42.376911] Modules linked in:
[   42.379980] CPU: 0    Not tainted  (2.6.25-rc2-10642-ge8f2594-dirty #73)
[   42.380000] PC is at physmap_flash_shutdown+0x28/0x54
...
[   42.380000] Backtrace:
[   42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24)
[   42.380000]  r5:28121969 r4:c0229e08
[   42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88)
[   42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c)
[   42.380000]  r4:00000000
[   42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48)
[   42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8)
[   42.380000]  r4:01234567
[   42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c)
[   42.380000]  r7:00000058 r6:00000004 r5:00000001 r4:00000000
[   42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078)
[   42.650051] ---[ end trace 6d6c26a0fc3141de ]---
Segmentation fault
INIT: no more processes left in this runlevel
- - - -

While looping for mtd[i]s, we should stop at the mtd[i] == NULL.

This patch also removes unnecessary "if (info)" checks:
suspend/resume/shutdown ops are executed only if probe() is succeeded,
so info is guaranteed to be !NULL.

Signed-off-by: Anton Vorontsov <cbouatmailru at gmail.com>
---
 drivers/mtd/maps/physmap.c |   15 +++++++--------
 1 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index f00e04e..bc4649a 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -202,9 +202,8 @@ static int physmap_flash_suspend(struct platform_device *dev, pm_message_t state
 	int ret = 0;
 	int i;
 
-	if (info)
-		for (i = 0; i < MAX_RESOURCES; i++)
-			ret |= info->mtd[i]->suspend(info->mtd[i]);
+	for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
+		ret |= info->mtd[i]->suspend(info->mtd[i]);
 
 	return ret;
 }
@@ -214,9 +213,9 @@ static int physmap_flash_resume(struct platform_device *dev)
 	struct physmap_flash_info *info = platform_get_drvdata(dev);
 	int i;
 
-	if (info)
-		for (i = 0; i < MAX_RESOURCES; i++)
-			info->mtd[i]->resume(info->mtd[i]);
+	for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
+		info->mtd[i]->resume(info->mtd[i]);
+
 	return 0;
 }
 
@@ -225,8 +224,8 @@ static void physmap_flash_shutdown(struct platform_device *dev)
 	struct physmap_flash_info *info = platform_get_drvdata(dev);
 	int i;
 
-	for (i = 0; i < MAX_RESOURCES; i++)
-		if (info && info->mtd[i]->suspend(info->mtd[i]) == 0)
+	for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
+		if (info->mtd[i]->suspend(info->mtd[i]) == 0)
 			info->mtd[i]->resume(info->mtd[i]);
 }
 #else
-- 
1.5.3.7



From trimarchimichael at yahoo.it  Sun Feb 17 18:26:20 2008
From: trimarchimichael at yahoo.it (Michael Trimarchi)
Date: Sun, 17 Feb 2008 23:26:20 +0000 (GMT)
Subject: Support for write-buffer verification.
Message-ID: <660543.38112.qm@web26202.mail.ukl.yahoo.com>

Hi,
the support is broken for the dataflash. The option can be set from config, but
it does't work. Two possibility:

add it for dataflash
change the Kconfig to avoid selection

Regards michael


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html


From kmpark at infradead.org  Mon Feb 18 02:48:52 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Mon, 18 Feb 2008 16:48:52 +0900
Subject: [PATCH] drivers/mtd/onenand/onenand_base.c unlikely(x) ||
	unlikely(y) => unlikely(x || y)
In-Reply-To: <47B719FB.4020107@tiscali.nl>
References: <47B719FB.4020107@tiscali.nl>
Message-ID: <007701c87202$b87c8b10$1fa9580a@swcenter.sec.samsung.co.kr>

> Not yet tested.
> ---
> Replace unlikely(x) || unlikely(y) by unlikely(x || y)
> 
> Signed-off-by: Roel Kluin <12o3l at tiscali.nl>
Ack-by: Kyungmin Park <kyungmin.park at samsung.com>



From haver at vnet.ibm.com  Mon Feb 18 08:28:08 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Mon, 18 Feb 2008 14:28:08 +0100
Subject: [PATCH] ubi-utils: Move bin2nand and nand2bin to mtd-utils
	subdirectory
Message-ID: <1203341288.8085.5.camel@august>

Hi Artem & David,

as discussed some time ago with Artem, we figured out that nand2bin and
bin2nand are not directly UBI related. The tools are of general use to
create data-images for burning directly into NAND chips e.g. for
manufacturing purposes. Therefor I created a patch to move it to the
top-level mtd-utils directory:

http://git.infradead.org/?p=users/haver/mtd-utils.git;a=commit;h=adade51d57a57028af6a187cacd6289fdc890eb8

Please have a look and pull if the changes are ok.

Thanks,

Frank

-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080218/a5c790ec/attachment-0001.bin 

From haver at vnet.ibm.com  Mon Feb 18 08:49:40 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Mon, 18 Feb 2008 14:49:40 +0100
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
Message-ID: <1203342580.8085.23.camel@august>

Hi Artem,

I saw that you moved the old ubi-toolchain to the old-tools directory
with the comment "sort-me-out" in your git-commits.

We need the tool-chain to generate PFI files for the code-update
process. Those pfi-files are suited to be used in streaming mode
together with the pfiflash utility. We use the for NOR and NAND flash
system the same pfi. Therefor the pfi format does not contain flash
geometry information e.g. vid-hdr-offset, erase-block size.

I, and maybe some others on the CC list, would like to see those tools
moved from the "sort-me-out" section again into the ubi-tools directory.
Please let us know, what you think, needs to be done to get this done.

Thanks,

Frank
-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080218/9e66eff0/attachment-0001.bin 

From dedekind at infradead.org  Mon Feb 18 10:16:12 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Mon, 18 Feb 2008 17:16:12 +0200
Subject: [PATCH] ubi-utils: Move bin2nand and nand2bin to mtd-utils
	subdirectory
In-Reply-To: <1203341288.8085.5.camel@august>
References: <1203341288.8085.5.camel@august>
Message-ID: <1203347772.3758.1.camel@sauron>

On Mon, 2008-02-18 at 14:28 +0100, Frank Haverkamp wrote:
> as discussed some time ago with Artem, we figured out that nand2bin and
> bin2nand are not directly UBI related. The tools are of general use to
> create data-images for burning directly into NAND chips e.g. for
> manufacturing purposes. Therefor I created a patch to move it to the
> top-level mtd-utils directory:

I'd suggest to also add a readme file and put the information about the
tools there - something similar to your commit message.

Otherwise the patch is OK with me - with dwmw2's ack I could push it.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From dedekind at infradead.org  Mon Feb 18 10:28:36 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Mon, 18 Feb 2008 17:28:36 +0200
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203342580.8085.23.camel@august>
References: <1203342580.8085.23.camel@august>
Message-ID: <1203348516.3758.14.camel@sauron>

On Mon, 2008-02-18 at 14:49 +0100, Frank Haverkamp wrote:
> We need the tool-chain to generate PFI files for the code-update
> process. Those pfi-files are suited to be used in streaming mode
> together with the pfiflash utility. We use the for NOR and NAND flash
> system the same pfi. Therefor the pfi format does not contain flash
> geometry information e.g. vid-hdr-offset, erase-block size.

Yeah. I tried to use the tools but they did not generate correct UBI
images. I tried to fix this and found out that the internals are too
messy to be maintainable, at least by me.

I cleaned-up what I could, made the utilities consistent, small, and
easy to maintain.

Vs. the PFI stuff, I also tried to clean-up this, but gave up after few
days, and just implemented another utility - ubinize.

I know what is PFI and I decided not to do this, because pfi =
configuration ini file + ubi images. I figured that it does not make
much sense to inroduce this additional magic format.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From anemo at mba.ocn.ne.jp  Mon Feb 18 10:43:37 2008
From: anemo at mba.ocn.ne.jp (Atsushi Nemoto)
Date: Tue, 19 Feb 2008 00:43:37 +0900 (JST)
Subject: at91_nand question
Message-ID: <20080219.004337.74388852.anemo@mba.ocn.ne.jp>

Hi.  Looking at at91_nand.c, I found that this driver does not
controls NCE signal during normal operations.  The driver only enables
NCE on at91_nand_probe() and disables NCE on at91_nand_remove().

Is this normal behavior?  I thought a nand driver should control NCE
signal on cmd_ctrl routine.  If the nand driver supported only one
chip, it can omit NCE control?

Though it seems work fine as is, I wonder keeping chipselect signal
low all the time is normal.

---
Atsushi Nemoto


From ricard.wanderlof at axis.com  Mon Feb 18 11:02:40 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Mon, 18 Feb 2008 17:02:40 +0100 (CET)
Subject: at91_nand question
In-Reply-To: <20080219.004337.74388852.anemo@mba.ocn.ne.jp>
References: <20080219.004337.74388852.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.LNX.4.64.0802181701090.3508@lnxricardw.se.axis.com>


On Tue, 19 Feb 2008, Atsushi Nemoto wrote:

> Hi.  Looking at at91_nand.c, I found that this driver does not
> controls NCE signal during normal operations.  The driver only enables
> NCE on at91_nand_probe() and disables NCE on at91_nand_remove().
>
> Is this normal behavior?  I thought a nand driver should control NCE
> signal on cmd_ctrl routine.  If the nand driver supported only one
> chip, it can omit NCE control?
>
> Though it seems work fine as is, I wonder keeping chipselect signal
> low all the time is normal.

I think it is necessary for some flash chips. E.g. to erase, one cannot 
just issue an erase command and make NCE go inactive, as making NCE go 
inactive stops the erase procedure until asserted again.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


From tglx at linutronix.de  Mon Feb 18 11:01:28 2008
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 18 Feb 2008 17:01:28 +0100 (CET)
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203342580.8085.23.camel@august>
References: <1203342580.8085.23.camel@august>
Message-ID: <alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>

On Mon, 18 Feb 2008, Frank Haverkamp wrote:

> Hi Artem,
> 
> I saw that you moved the old ubi-toolchain to the old-tools directory
> with the comment "sort-me-out" in your git-commits.
> 
> We need the tool-chain to generate PFI files for the code-update
> process. Those pfi-files are suited to be used in streaming mode
> together with the pfiflash utility. We use the for NOR and NAND flash
> system the same pfi. Therefor the pfi format does not contain flash
> geometry information e.g. vid-hdr-offset, erase-block size.
> 
> I, and maybe some others on the CC list, would like to see those tools
> moved from the "sort-me-out" section again into the ubi-tools directory.
> Please let us know, what you think, needs to be done to get this done.

I really do not understand why this move was done anyway. We can move
stuff into retirement when we have a full replacement there.

Just shuffling functional tools around is useless and makes the life
of developers, users and package maintainers harder for no good
reason.

I did not update for some time, but did now and noticed that my
packaging scripts need a real overhaul for no benefit.

Yours grumpy,

	tglx


From jwboyer at linux.vnet.ibm.com  Mon Feb 18 11:53:24 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Mon, 18 Feb 2008 10:53:24 -0600
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203353343.8085.48.camel@august>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>
Message-ID: <20080218105324.1734f9d5@weaponx>

On Mon, 18 Feb 2008 17:49:03 +0100
Frank Haverkamp <haver at vnet.ibm.com> wrote:

> Hi Thomas,
> 
> On Mon, 2008-02-18 at 17:01 +0100, Thomas Gleixner wrote:
> > I did not update for some time, but did now and noticed that my
> > packaging scripts need a real overhaul for no benefit.
> > 
> 
> I talked to Artem. He told me that the tools had deficiencies that
> prevented him using them. E.g. that he could not put the vid-hdr the
> offset he wanted it to put. He promissed me to write up the deficiencies
> so that we can work on them. I am sure that after fixing, we can move
> the tools back to their old location.

I have a patch for the vid header thing.  I also have a patch for
bin2nand/nand2bin since they are hard coded to use the SmartMedia ECC
byte ordering.

> Of course it would be nice, if we could move the tools back even before
> the fixup, to avoid changing our build scripts. Let us discuss that with
> Artem tomorrow.

I'm a bit grumpy about the move as well, not because they were moved,
but because there's a dozen or so completely useless commits in the
repo.  But, oh well.

josh


From gordonfarquharson at gmail.com  Mon Feb 18 13:34:11 2008
From: gordonfarquharson at gmail.com (Gordon Farquharson)
Date: Mon, 18 Feb 2008 11:34:11 -0700
Subject: [PATCH] [MTD] [NOR] Add support for the ST M29W400DB flash chip.
In-Reply-To: <97a0a9ac0801082035r2dacab1cu40a6bfc4e7fedb1a@mail.gmail.com>
References: <97a0a9ac0801082035r2dacab1cu40a6bfc4e7fedb1a@mail.gmail.com>
Message-ID: <97a0a9ac0802181034w6f31ac3dj36b18ea409b8f988@mail.gmail.com>

I submitted this patch to the list at the beginning of January in the
hope that it would be included in 2.6.25. I know that the merge window
for 2.6.25 is closed, but is it still possible to get this into
2.6.25? It is not a significant change. This chip is used in the GLAN
Tank NAS.

Thanks.

Gordon

On Jan 8, 2008 9:35 PM, Gordon Farquharson <gordonfarquharson at gmail.com> wrote:
> Add support for the ST M29W400DB flash chip.
>
> Signed-off-by: Gordon Farquharson <gordonfarquharson at gmail.com>
>
> ---
>
> diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
> index 6405938..0b4f481 100644
> --- a/drivers/mtd/chips/jedec_probe.c
> +++ b/drivers/mtd/chips/jedec_probe.c
> @@ -135,6 +135,7 @@
>  #define M29W160DT      0x22C4
>  #define M29W160DB      0x2249
>  #define M29W040B       0x00E3
> +#define M29W400DB      0x00EF
>  #define M50FW040       0x002C
>  #define M50FW080       0x002D
>  #define M50FW016       0x002E
> @@ -1498,7 +1499,22 @@ static const struct amd_flash_info jedec_table[] = {
>                 .regions        = {
>                         ERASEINFO(0x10000,8),
>                 }
> -        }, {
> +       }, {
> +               .mfr_id         = MANUFACTURER_ST,
> +               .dev_id         = M29W400DB,
> +               .name           = "ST M29W400DB",
> +               .devtypes       = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
> +               .uaddr          = MTD_UADDR_0x0555_0x02AA,
> +               .dev_size       = SIZE_512KiB,
> +               .cmd_set        = P_ID_AMD_STD,
> +               .nr_regions     = 4,
> +               .regions        = {
> +                       ERASEINFO(0x04000,1),
> +                       ERASEINFO(0x02000,2),
> +                       ERASEINFO(0x08000,1),
> +                       ERASEINFO(0x10000,7)
> +               }
> +       }, {
>                 .mfr_id         = MANUFACTURER_ST,
>                 .dev_id         = M50FW040,
>                 .name           = "ST M50FW040",
>

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676


From tglx at linutronix.de  Mon Feb 18 16:26:21 2008
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 18 Feb 2008 22:26:21 +0100 (CET)
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203353343.8085.48.camel@august>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>
Message-ID: <alpine.LFD.1.00.0802182214000.7583@apollo.tec.linutronix.de>

On Mon, 18 Feb 2008, Frank Haverkamp wrote:
> Hi Thomas,
> 
> On Mon, 2008-02-18 at 17:01 +0100, Thomas Gleixner wrote:
> > I did not update for some time, but did now and noticed that my
> > packaging scripts need a real overhaul for no benefit.
> > 
> 
> I talked to Artem. He told me that the tools had deficiencies that
> prevented him using them.

I really give a sh*t whether Artem can use them or not. He is not the
center of the universe. If he needs them changed, then he should send
a patch or a suitable replacement for the tool, which does not force
others to fixup their scripts and build tools for no benefit. This is
not a sandbox, this are tools used in production environments.

Artem, please stop this nonsense right now. You can create your own
world if you have the urge to do so, but please keep stuff others use
intact. This "I don't like that old crap" attitude is an arrogant and
at the same time ignorant childish behaviour, which has no place in a
serious project.

> E.g. that he could not put the vid-hdr the
> offset he wanted it to put. He promissed me to write up the deficiencies
> so that we can work on them. I am sure that after fixing, we can move
> the tools back to their old location.

No, they go back to their place immediately, period.

Yours even more grumpy,

      tglx


From eric.y.miao at gmail.com  Tue Feb 19 01:35:20 2008
From: eric.y.miao at gmail.com (eric miao)
Date: Tue, 19 Feb 2008 14:35:20 +0800
Subject: [PATCH 0/4] pxa: cleaned up patch set for pxa3xx NAND controller
Message-ID: <f17812d70802182235l56914c2ai4f87d8c41f1aa4d7@mail.gmail.com>

I cleaned up the previous patch a bit, and added support for zylonite
and littleton. And this version is intended for merging upstream.

The minor changes from the previous submitted version are:

1. removed un-used ERR_BUSY

2. sanitized states, and use different states for reading/writing, thus
eliminate the unnecessary "info->cur_cmd" field, another consequence
of this DMA setup is now performed in interrupt handler, and this
change should be quite safe.

3. use IORESOURCE_DMA defined in the device for DRCMR(x)
register indexing

4. use IORESOURCE_IRQ defined in the device for IRQ number

5. use __raw_{read, write}sl() instead of {read, write}_fifo_pio()

6. filling un-used info->ndcbx with 0 so it doesn't bother to initialize
them to zeros every time in the beginning of _cmdfunc()

7. combine CMD_READID and CMD_STATUS, they share almost
same code

8. corrected some mistakes in the exiting path of pxa3xx_nand_probe()

Thanks Sergey Podstavin, for your effort on testing out the previous
version, yet I'm quite satisifed with your version due to the following
reasons:

1. the badblock management code in the Marvell released NAND driver is
   actually not clean enough, so the that part of the code was removed
   on purpose, hopefully someone later can come up with a clean enough
   version

2. The OBM version code is way too ugly to be embedded into a generic
   NAND controller driver, so that part of the code was also removed
   on purpose. Besides, along with the development of OBM, the legacy
   versions will be slowly obsoleted, so it's really un-necessary to
   calculate the OBM version within new code.

3. [include/asm-arch/arm-pxa/pxa3xx_nand.h] should really include
   platform _only_ code, the NAND controller registers are better
   to be defined within pxa3xx_nand.c itself.

4. the above statement is also true for driver specific structures and
   constants

5. We should really make individual patches for the support of various
   platforms, instead of making this a big patch

-- 
Cheers
- eric


From eric.y.miao at gmail.com  Tue Feb 19 01:36:45 2008
From: eric.y.miao at gmail.com (eric miao)
Date: Tue, 19 Feb 2008 14:36:45 +0800
Subject: [PATCH 1/4] mtd: preliminary NAND support for pxa3xx
Message-ID: <f17812d70802182236v5a51d51dvaa65fabfc5d10de5@mail.gmail.com>

>From 12fe7ee7cc0630c8a543860215d21f1c2c9ba72f Mon Sep 17 00:00:00 2001
From: eric miao <eric.miao at marvell.com>
Date: Thu, 14 Feb 2008 15:48:23 +0800
Subject: [PATCH] mtd: preliminary NAND support for pxa3xx

This is preliminary since:

1. It supports only _one_ chip select at the moment. As there is no
   existing platforms available using two chip selects of the NAND
   controller, it shall really not include code for supporting the
   2nd chip select for now, as such code cannot be verified.

2. It resorts to the default and simpliest memory based badblock
   table

3. Only limited types of nand flash are currently supported. Most
   PXA3xx processors come with on-chip NAND flash dies, so there
   isn't much flexibility for other types of NAND.

4. The NAND controller should be configured to detect the device's
   ID, thus making it difficult to use nand_scan_ident() to assist
   the detection process (though it's not impossible)

TODO: fix all the above limitations of cuz :-)

Signed-off-by: eric miao <eric.miao at marvell.com>
Cc: Sergey Podstavin <spodstavin at ru.mvista.com>
---
 drivers/mtd/nand/Kconfig               |    7 +
 drivers/mtd/nand/Makefile              |    1 +
 drivers/mtd/nand/pxa3xx_nand.c         | 1249 ++++++++++++++++++++++++++++++++
 include/asm-arm/arch-pxa/pxa3xx_nand.h |   18 +
 4 files changed, 1275 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/pxa3xx_nand.c
 create mode 100644 include/asm-arm/arch-pxa/pxa3xx_nand.h

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4a3c675..363a477 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -279,6 +279,13 @@ config MTD_NAND_AT91
 	  Enables support for NAND Flash / Smart Media Card interface
 	  on Atmel AT91 processors.

+config MTD_NAND_PXA3xx
+	bool "Support for NAND flash devices on PXA3xx"
+	depends on MTD_NAND && PXA3xx
+	help
+	  This enables the driver for the NAND flash device found on
+	  PXA3xx processors
+
 config MTD_NAND_CM_X270
 	tristate "Support for NAND Flash on CM-X270 modules"
 	depends on MTD_NAND && MACH_ARMCORE
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 80d575e..54a332b 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
 obj-$(CONFIG_MTD_NAND_AT91)		+= at91_nand.o
 obj-$(CONFIG_MTD_NAND_CM_X270)		+= cmx270_nand.o
 obj-$(CONFIG_MTD_NAND_BASLER_EXCITE)	+= excite_nandflash.o
+obj-$(CONFIG_MTD_NAND_PXA3xx)		+= pxa3xx_nand.o
 obj-$(CONFIG_MTD_NAND_PLATFORM)		+= plat_nand.o
 obj-$(CONFIG_MTD_ALAUDA)		+= alauda.o
 obj-$(CONFIG_MTD_NAND_PASEMI)		+= pasemi_nand.o
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
new file mode 100644
index 0000000..0b61e51
--- /dev/null
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -0,0 +1,1249 @@
+/*
+ * drivers/mtd/nand/pxa3xx_nand.c
+ *
+ * Copyright (C) 2005 Intel Corporation
+ * Copyright (C) 2006 Marvell International Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/dma.h>
+
+#include <asm/arch/pxa-regs.h>
+#include <asm/arch/pxa3xx_nand.h>
+
+#define	CHIP_DELAY_TIMEOUT	(2 * HZ/10)
+
+/* registers and bit definitions */
+#define NDCR		(0x00) /* Control register */
+#define NDTR0CS0	(0x04) /* Timing Parameter 0 for CS0 */
+#define NDTR1CS0	(0x0C) /* Timing Parameter 1 for CS0 */
+#define NDSR		(0x14) /* Status Register */
+#define NDPCR		(0x18) /* Page Count Register */
+#define NDBDR0		(0x1C) /* Bad Block Register 0 */
+#define NDBDR1		(0x20) /* Bad Block Register 1 */
+#define NDDB		(0x40) /* Data Buffer */
+#define NDCB0		(0x48) /* Command Buffer0 */
+#define NDCB1		(0x4C) /* Command Buffer1 */
+#define NDCB2		(0x50) /* Command Buffer2 */
+
+#define NDCR_SPARE_EN		(0x1 << 31)
+#define NDCR_ECC_EN		(0x1 << 30)
+#define NDCR_DMA_EN		(0x1 << 29)
+#define NDCR_ND_RUN		(0x1 << 28)
+#define NDCR_DWIDTH_C		(0x1 << 27)
+#define NDCR_DWIDTH_M		(0x1 << 26)
+#define NDCR_PAGE_SZ		(0x1 << 24)
+#define NDCR_NCSX		(0x1 << 23)
+#define NDCR_ND_MODE		(0x3 << 21)
+#define NDCR_NAND_MODE   	(0x0)
+#define NDCR_CLR_PG_CNT		(0x1 << 20)
+#define NDCR_CLR_ECC		(0x1 << 19)
+#define NDCR_RD_ID_CNT_MASK	(0x7 << 16)
+#define NDCR_RD_ID_CNT(x)	(((x) << 16) & NDCR_RD_ID_CNT_MASK)
+
+#define NDCR_RA_START		(0x1 << 15)
+#define NDCR_PG_PER_BLK		(0x1 << 14)
+#define NDCR_ND_ARB_EN		(0x1 << 12)
+
+#define NDSR_MASK		(0xfff)
+#define NDSR_RDY		(0x1 << 11)
+#define NDSR_CS0_PAGED		(0x1 << 10)
+#define NDSR_CS1_PAGED		(0x1 << 9)
+#define NDSR_CS0_CMDD		(0x1 << 8)
+#define NDSR_CS1_CMDD		(0x1 << 7)
+#define NDSR_CS0_BBD		(0x1 << 6)
+#define NDSR_CS1_BBD		(0x1 << 5)
+#define NDSR_DBERR		(0x1 << 4)
+#define NDSR_SBERR		(0x1 << 3)
+#define NDSR_WRDREQ		(0x1 << 2)
+#define NDSR_RDDREQ		(0x1 << 1)
+#define NDSR_WRCMDREQ		(0x1)
+
+#define NDCB0_AUTO_RS		(0x1 << 25)
+#define NDCB0_CSEL		(0x1 << 24)
+#define NDCB0_CMD_TYPE_MASK	(0x7 << 21)
+#define NDCB0_CMD_TYPE(x)	(((x) << 21) & NDCB0_CMD_TYPE_MASK)
+#define NDCB0_NC		(0x1 << 20)
+#define NDCB0_DBC		(0x1 << 19)
+#define NDCB0_ADDR_CYC_MASK	(0x7 << 16)
+#define NDCB0_ADDR_CYC(x)	(((x) << 16) & NDCB0_ADDR_CYC_MASK)
+#define NDCB0_CMD2_MASK		(0xff << 8)
+#define NDCB0_CMD1_MASK		(0xff)
+#define NDCB0_ADDR_CYC_SHIFT	(16)
+
+/* dma-able I/O address for the NAND data and commands */
+#define NDCB0_DMA_ADDR		(0x43100048)
+#define NDDB_DMA_ADDR		(0x43100040)
+
+/* macros for registers read/write */
+#define nand_writel(info, off, val)	\
+	__raw_writel((val), (info)->mmio_base + (off))
+
+#define nand_readl(info, off)		\
+	__raw_readl((info)->mmio_base + (off))
+
+/* error code and state */
+enum {
+	ERR_NONE	= 0,
+	ERR_DMABUSERR	= -1,
+	ERR_SENDCMD	= -2,
+	ERR_DBERR	= -3,
+	ERR_BBERR	= -4,
+};
+
+enum {
+	STATE_READY	= 0,
+	STATE_CMD_HANDLE,
+	STATE_DMA_READING,
+	STATE_DMA_WRITING,
+	STATE_DMA_DONE,
+	STATE_PIO_READING,
+	STATE_PIO_WRITING,
+};
+
+struct pxa3xx_nand_timing {
+	unsigned int	tCH;  /* Enable signal hold time */
+	unsigned int	tCS;  /* Enable signal setup time */
+	unsigned int	tWH;  /* ND_nWE high duration */
+	unsigned int	tWP;  /* ND_nWE pulse time */
+	unsigned int	tRH;  /* ND_nRE high duration */
+	unsigned int	tRP;  /* ND_nRE pulse width */
+	unsigned int	tR;   /* ND_nWE high to ND_nRE low for read */
+	unsigned int	tWHR; /* ND_nWE high to ND_nRE low for status read */
+	unsigned int	tAR;  /* ND_ALE low to ND_nRE low delay */
+};
+
+struct pxa3xx_nand_cmdset {
+	uint16_t	read1;
+	uint16_t	read2;
+	uint16_t	program;
+	uint16_t	read_status;
+	uint16_t	read_id;
+	uint16_t	erase;
+	uint16_t	reset;
+	uint16_t	lock;
+	uint16_t	unlock;
+	uint16_t	lock_status;
+};
+
+struct pxa3xx_nand_flash {
+	struct pxa3xx_nand_timing *timing; /* NAND Flash timing */
+	struct pxa3xx_nand_cmdset *cmdset;
+
+	uint32_t page_per_block;/* Pages per block (PG_PER_BLK) */
+	uint32_t page_size;	/* Page size in bytes (PAGE_SZ) */
+	uint32_t flash_width;	/* Width of Flash memory (DWIDTH_M) */
+	uint32_t dfc_width;	/* Width of flash controller(DWIDTH_C) */
+	uint32_t num_blocks;	/* Number of physical blocks in Flash */
+	uint32_t chip_id;
+
+	/* NOTE: these are automatically calculated, do not define */
+	size_t		oob_size;
+	size_t		read_id_bytes;
+
+	unsigned int	col_addr_cycles;
+	unsigned int	row_addr_cycles;
+};
+
+struct pxa3xx_nand_info {
+	struct nand_chip	nand_chip;
+
+	struct platform_device	 *pdev;
+	struct pxa3xx_nand_flash *flash_info;
+
+	struct clk		*clk;
+	void __iomem		*mmio_base;
+
+	unsigned int 		buf_start;
+	unsigned int		buf_count;
+
+	/* DMA information */
+	int			drcmr_dat;
+	int			drcmr_cmd;
+
+	unsigned char		*data_buff;
+	dma_addr_t 		data_buff_phys;
+	size_t			data_buff_size;
+	int 			data_dma_ch;
+	struct pxa_dma_desc	*data_desc;
+	dma_addr_t 		data_desc_addr;
+
+	uint32_t		reg_ndcr;
+
+	/* saved column/page_addr during CMD_SEQIN */
+	int			seqin_column;
+	int			seqin_page_addr;
+
+	/* relate to the command */
+	unsigned int		state;
+
+	int			use_ecc;	/* use HW ECC ? */
+	int			use_dma;	/* use DMA ? */
+
+	size_t			data_size;	/* data size in FIFO */
+	int 			retcode;
+	struct completion 	cmd_complete;
+
+	/* generated NDCBx register values */
+	uint32_t		ndcb0;
+	uint32_t		ndcb1;
+	uint32_t		ndcb2;
+};
+
+static int use_dma = 1;
+module_param(use_dma, bool, 0444);
+MODULE_PARM_DESC(use_dma, "enable DMA for data transfering to/from NAND HW");
+
+static struct pxa3xx_nand_cmdset smallpage_cmdset = {
+	.read1		= 0x0000,
+	.read2		= 0x0050,
+	.program	= 0x1080,
+	.read_status	= 0x0070,
+	.read_id	= 0x0090,
+	.erase		= 0xD060,
+	.reset		= 0x00FF,
+	.lock		= 0x002A,
+	.unlock		= 0x2423,
+	.lock_status	= 0x007A,
+};
+
+static struct pxa3xx_nand_cmdset largepage_cmdset = {
+	.read1		= 0x3000,
+	.read2		= 0x0050,
+	.program	= 0x1080,
+	.read_status	= 0x0070,
+	.read_id	= 0x0090,
+	.erase		= 0xD060,
+	.reset		= 0x00FF,
+	.lock		= 0x002A,
+	.unlock		= 0x2423,
+	.lock_status	= 0x007A,
+};
+
+static struct pxa3xx_nand_timing samsung512MbX16_timing = {
+	.tCH	= 10,
+	.tCS	= 0,
+	.tWH	= 20,
+	.tWP	= 40,
+	.tRH	= 30,
+	.tRP	= 40,
+	.tR	= 11123,
+	.tWHR	= 110,
+	.tAR	= 10,
+};
+
+static struct pxa3xx_nand_flash samsung512MbX16 = {
+	.timing		= &samsung512MbX16_timing,
+	.cmdset		= &smallpage_cmdset,
+	.page_per_block	= 32,
+	.page_size	= 512,
+	.flash_width	= 16,
+	.dfc_width	= 16,
+	.num_blocks	= 4096,
+	.chip_id	= 0x46ec,
+};
+
+static struct pxa3xx_nand_timing micron_timing = {
+	.tCH	= 10,
+	.tCS	= 25,
+	.tWH	= 15,
+	.tWP	= 25,
+	.tRH	= 15,
+	.tRP	= 25,
+	.tR	= 25000,
+	.tWHR	= 60,
+	.tAR	= 10,
+};
+
+static struct pxa3xx_nand_flash micron1GbX8 = {
+	.timing		= &micron_timing,
+	.cmdset		= &largepage_cmdset,
+	.page_per_block	= 64,
+	.page_size	= 2048,
+	.flash_width	= 8,
+	.dfc_width	= 8,
+	.num_blocks	= 1024,
+	.chip_id	= 0xa12c,
+};
+
+static struct pxa3xx_nand_flash micron1GbX16 = {
+	.timing		= &micron_timing,
+	.cmdset		= &largepage_cmdset,
+	.page_per_block	= 64,
+	.page_size	= 2048,
+	.flash_width	= 16,
+	.dfc_width	= 16,
+	.num_blocks	= 1024,
+	.chip_id	= 0xb12c,
+};
+
+static struct pxa3xx_nand_flash *builtin_flash_types[] = {
+	&samsung512MbX16,
+	&micron1GbX8,
+	&micron1GbX16,
+};
+
+#define NDTR0_tCH(c)	(min((c), 7) << 19)
+#define NDTR0_tCS(c)	(min((c), 7) << 16)
+#define NDTR0_tWH(c)	(min((c), 7) << 11)
+#define NDTR0_tWP(c)	(min((c), 7) << 8)
+#define NDTR0_tRH(c)	(min((c), 7) << 3)
+#define NDTR0_tRP(c)	(min((c), 7) << 0)
+
+#define NDTR1_tR(c)	(min((c), 65535) << 16)
+#define NDTR1_tWHR(c)	(min((c), 15) << 4)
+#define NDTR1_tAR(c)	(min((c), 15) << 0)
+
+/* convert nano-seconds to nand flash controller clock cycles */
+#define ns2cycle(ns, clk)	(int)(((ns) * (clk / 1000000) / 1000) + 1)
+
+static void pxa3xx_nand_set_timing(struct pxa3xx_nand_info *info,
+				   struct pxa3xx_nand_timing *t)
+{
+	unsigned long nand_clk = clk_get_rate(info->clk);
+	uint32_t ndtr0, ndtr1;
+
+	ndtr0 = NDTR0_tCH(ns2cycle(t->tCH, nand_clk)) |
+		NDTR0_tCS(ns2cycle(t->tCS, nand_clk)) |
+		NDTR0_tWH(ns2cycle(t->tWH, nand_clk)) |
+		NDTR0_tWP(ns2cycle(t->tWP, nand_clk)) |
+		NDTR0_tRH(ns2cycle(t->tRH, nand_clk)) |
+		NDTR0_tRP(ns2cycle(t->tRP, nand_clk));
+
+	ndtr1 = NDTR1_tR(ns2cycle(t->tR, nand_clk)) |
+		NDTR1_tWHR(ns2cycle(t->tWHR, nand_clk)) |
+		NDTR1_tAR(ns2cycle(t->tAR, nand_clk));
+
+	nand_writel(info, NDTR0CS0, ndtr0);
+	nand_writel(info, NDTR1CS0, ndtr1);
+}
+
+#define WAIT_EVENT_TIMEOUT	10
+
+static int wait_for_event(struct pxa3xx_nand_info *info, uint32_t event)
+{
+	int timeout = WAIT_EVENT_TIMEOUT;
+	uint32_t ndsr;
+
+	while (timeout--) {
+		ndsr = nand_readl(info, NDSR) & NDSR_MASK;
+		if (ndsr & event) {
+			nand_writel(info, NDSR, ndsr);
+			return 0;
+		}
+		udelay(10);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int prepare_read_prog_cmd(struct pxa3xx_nand_info *info,
+			uint16_t cmd, int column, int page_addr)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = f->cmdset;
+
+	/* calculate data size */
+	switch (f->page_size) {
+	case 2048:
+		info->data_size = (info->use_ecc) ? 2088 : 2112;
+		break;
+	case 512:
+		info->data_size = (info->use_ecc) ? 520 : 528;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	/* generate values for NDCBx registers */
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+	info->ndcb1 = 0;
+	info->ndcb2 = 0;
+	info->ndcb0 |= NDCB0_ADDR_CYC(f->row_addr_cycles + f->col_addr_cycles);
+
+	if (f->col_addr_cycles == 2) {
+		/* large block, 2 cycles for column address
+		 * row address starts from 3rd cycle
+		 */
+		info->ndcb1 |= (page_addr << 16) | (column & 0xffff);
+		if (f->row_addr_cycles == 3)
+			info->ndcb2 = (page_addr >> 16) & 0xff;
+	} else
+		/* small block, 1 cycles for column address
+		 * row address starts from 2nd cycle
+		 */
+		info->ndcb1 = (page_addr << 8) | (column & 0xff);
+
+	if (cmd == cmdset->program)
+		info->ndcb0 |= NDCB0_CMD_TYPE(1) | NDCB0_AUTO_RS;
+
+	return 0;
+}
+
+static int prepare_erase_cmd(struct pxa3xx_nand_info *info,
+			uint16_t cmd, int page_addr)
+{
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+	info->ndcb0 |= NDCB0_CMD_TYPE(2) | NDCB0_AUTO_RS | NDCB0_ADDR_CYC(3);
+	info->ndcb1 = page_addr;
+	info->ndcb2 = 0;
+	return 0;
+}
+
+static int prepare_other_cmd(struct pxa3xx_nand_info *info, uint16_t cmd)
+{
+	struct pxa3xx_nand_cmdset *cmdset = info->flash_info->cmdset;
+
+	info->ndcb0 = cmd | ((cmd & 0xff00) ? NDCB0_DBC : 0);
+	info->ndcb1 = 0;
+	info->ndcb2 = 0;
+
+	if (cmd == cmdset->read_id) {
+		info->ndcb0 |= NDCB0_CMD_TYPE(3);
+		info->data_size = 8;
+	} else if (cmd == cmdset->read_status) {
+		info->ndcb0 |= NDCB0_CMD_TYPE(4);
+		info->data_size = 8;
+	} else if (cmd == cmdset->reset || cmd == cmdset->lock ||
+		   cmd == cmdset->unlock) {
+		info->ndcb0 |= NDCB0_CMD_TYPE(5);
+	} else
+		return -EINVAL;
+
+	return 0;
+}
+
+static void enable_int(struct pxa3xx_nand_info *info, uint32_t int_mask)
+{
+	uint32_t ndcr;
+
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~int_mask);
+}
+
+static void disable_int(struct pxa3xx_nand_info *info, uint32_t int_mask)
+{
+	uint32_t ndcr;
+
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr | int_mask);
+}
+
+/* NOTE: it is a must to set ND_RUN firstly, then write command buffer
+ * otherwise, it does not work
+ */
+static int write_cmd(struct pxa3xx_nand_info *info)
+{
+	uint32_t ndcr;
+
+	/* clear status bits and run */
+	nand_writel(info, NDSR, NDSR_MASK);
+
+	ndcr = info->reg_ndcr;
+
+	ndcr |= info->use_ecc ? NDCR_ECC_EN : 0;
+	ndcr |= info->use_dma ? NDCR_DMA_EN : 0;
+	ndcr |= NDCR_ND_RUN;
+
+	nand_writel(info, NDCR, ndcr);
+
+	if (wait_for_event(info, NDSR_WRCMDREQ)) {
+		printk(KERN_ERR "timed out writing command\n");
+		return -ETIMEDOUT;
+	}
+
+	nand_writel(info, NDCB0, info->ndcb0);
+	nand_writel(info, NDCB0, info->ndcb1);
+	nand_writel(info, NDCB0, info->ndcb2);
+	return 0;
+}
+
+static int handle_data_pio(struct pxa3xx_nand_info *info)
+{
+	int ret, timeout = CHIP_DELAY_TIMEOUT;
+
+	switch (info->state) {
+	case STATE_PIO_WRITING:
+		__raw_writesl(info->mmio_base + NDDB, info->data_buff,
+				info->data_size << 2);
+
+		enable_int(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+
+		ret = wait_for_completion_timeout(&info->cmd_complete, timeout);
+		if (!ret) {
+			printk(KERN_ERR "program command time out\n");
+			return -1;
+		}
+		break;
+	case STATE_PIO_READING:
+		__raw_readsl(info->mmio_base + NDDB, info->data_buff,
+				info->data_size << 2);
+		break;
+	default:
+		printk(KERN_ERR "%s: invalid state %d\n", __FUNCTION__,
+				info->state);
+		return -EINVAL;
+	}
+
+	info->state = STATE_READY;
+	return 0;
+}
+
+static void start_data_dma(struct pxa3xx_nand_info *info, int dir_out)
+{
+	struct pxa_dma_desc *desc = info->data_desc;
+	int dma_len = ALIGN(info->data_size, 32);
+
+	desc->ddadr = DDADR_STOP;
+	desc->dcmd = DCMD_ENDIRQEN | DCMD_WIDTH4 | DCMD_BURST32 | dma_len;
+
+	if (dir_out) {
+		desc->dsadr = info->data_buff_phys;
+		desc->dtadr = NDDB_DMA_ADDR;
+		desc->dcmd |= DCMD_INCSRCADDR | DCMD_FLOWTRG;
+	} else {
+		desc->dtadr = info->data_buff_phys;
+		desc->dsadr = NDDB_DMA_ADDR;
+		desc->dcmd |= DCMD_INCTRGADDR | DCMD_FLOWSRC;
+	}
+
+	DRCMR(info->drcmr_dat) = DRCMR_MAPVLD | info->data_dma_ch;
+	DDADR(info->data_dma_ch) = info->data_desc_addr;
+	DCSR(info->data_dma_ch) |= DCSR_RUN;
+}
+
+static void pxa3xx_nand_data_dma_irq(int channel, void *data)
+{
+	struct pxa3xx_nand_info *info = data;
+	uint32_t dcsr;
+
+	dcsr = DCSR(channel);
+	DCSR(channel) = dcsr;
+
+	if (dcsr & DCSR_BUSERR) {
+		info->retcode = ERR_DMABUSERR;
+		complete(&info->cmd_complete);
+	}
+
+	if (info->state == STATE_DMA_WRITING) {
+		info->state = STATE_DMA_DONE;
+		enable_int(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+	} else {
+		info->state = STATE_READY;
+		complete(&info->cmd_complete);
+	}
+}
+
+static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
+{
+	struct pxa3xx_nand_info *info = devid;
+	unsigned int status;
+
+	status = nand_readl(info, NDSR);
+
+	if (status & (NDSR_RDDREQ | NDSR_DBERR)) {
+		if (status & NDSR_DBERR)
+			info->retcode = ERR_DBERR;
+
+		disable_int(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		if (info->use_dma) {
+			info->state = STATE_DMA_READING;
+			start_data_dma(info, 0);
+		} else {
+			info->state = STATE_PIO_READING;
+			complete(&info->cmd_complete);
+		}
+	} else if (status & NDSR_WRDREQ) {
+		disable_int(info, NDSR_WRDREQ);
+		if (info->use_dma) {
+			info->state = STATE_DMA_WRITING;
+			start_data_dma(info, 1);
+		} else {
+			info->state = STATE_PIO_WRITING;
+			complete(&info->cmd_complete);
+		}
+	} else if (status & (NDSR_CS0_BBD | NDSR_CS0_CMDD)) {
+		if (status & NDSR_CS0_BBD)
+			info->retcode = ERR_BBERR;
+
+		disable_int(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+		info->state = STATE_READY;
+		complete(&info->cmd_complete);
+	}
+	nand_writel(info, NDSR, status);
+	return IRQ_HANDLED;
+}
+
+static int pxa3xx_nand_do_cmd(struct pxa3xx_nand_info *info, uint32_t event)
+{
+	uint32_t ndcr;
+	int ret, timeout = CHIP_DELAY_TIMEOUT;
+
+	if (write_cmd(info)) {
+		info->retcode = ERR_SENDCMD;
+		goto fail_stop;
+	}
+
+	info->state = STATE_CMD_HANDLE;
+
+	enable_int(info, event);
+
+	ret = wait_for_completion_timeout(&info->cmd_complete, timeout);
+	if (!ret) {
+		printk(KERN_ERR "command execution timed out\n");
+		info->retcode = ERR_SENDCMD;
+		goto fail_stop;
+	}
+
+	if (info->use_dma == 0 && info->data_size > 0)
+		if (handle_data_pio(info))
+			goto fail_stop;
+
+	return 0;
+
+fail_stop:
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+	udelay(10);
+	return -ETIMEDOUT;
+}
+
+static int pxa3xx_nand_dev_ready(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	return (nand_readl(info, NDSR) & NDSR_RDY) ? 1 : 0;
+}
+
+static inline int is_buf_blank(uint8_t *buf, size_t len)
+{
+	for (; len > 0; len--)
+		if (*buf++ != 0xff)
+			return 0;
+	return 1;
+}
+
+static void pxa3xx_nand_cmdfunc(struct mtd_info *mtd, unsigned command,
+		int column, int page_addr )
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	struct pxa3xx_nand_flash * flash_info = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = flash_info->cmdset;
+	int ret;
+
+	info->use_dma = (use_dma) ? 1 : 0;
+	info->use_ecc = 0;
+	info->data_size = 0;
+	info->state = STATE_READY;
+
+	init_completion(&info->cmd_complete);
+
+	switch (command) {
+	case NAND_CMD_READOOB:
+		/* disable HW ECC to get all the OOB data */
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		info->buf_start = mtd->writesize + column;
+
+		if (prepare_read_prog_cmd(info, cmdset->read1, column, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		/* We only are OOB, so if the data has error, does not matter */
+		if (info->retcode == ERR_DBERR)
+			info->retcode = ERR_NONE;
+		break;
+
+	case NAND_CMD_READ0:
+		info->use_ecc = 1;
+		info->retcode = ERR_NONE;
+		info->buf_start = column;
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		memset(info->data_buff, 0xFF, info->buf_count);
+
+		if (prepare_read_prog_cmd(info, cmdset->read1, column, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ | NDSR_DBERR);
+
+		if (info->retcode == ERR_DBERR) {
+			/* for blank page (all 0xff), HW will calculate its ECC as
+			 * 0, which is different from the ECC information within
+			 * OOB, ignore such double bit errors
+			 */
+			if (is_buf_blank(info->data_buff, mtd->writesize))
+				info->retcode = ERR_NONE;
+		}
+		break;
+	case NAND_CMD_SEQIN:
+		info->buf_start = column;
+		info->buf_count = mtd->writesize + mtd->oobsize;
+		memset(info->data_buff, 0xff, info->buf_count);
+
+		/* save column/page_addr for next CMD_PAGEPROG */
+		info->seqin_column = column;
+		info->seqin_page_addr = page_addr;
+		break;
+	case NAND_CMD_PAGEPROG:
+		info->use_ecc = (info->seqin_column >= mtd->writesize) ? 0 : 1;
+
+		if (prepare_read_prog_cmd(info, cmdset->program,
+				info->seqin_column, info->seqin_page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_WRDREQ);
+		break;
+	case NAND_CMD_ERASE1:
+		if (prepare_erase_cmd(info, cmdset->erase, page_addr))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_CS0_BBD | NDSR_CS0_CMDD);
+		break;
+	case NAND_CMD_ERASE2:
+		break;
+	case NAND_CMD_READID:
+	case NAND_CMD_STATUS:
+		info->use_dma = 0;	/* force PIO read */
+		info->buf_start = 0;
+		info->buf_count = (command == NAND_CMD_READID) ?
+				flash_info->read_id_bytes : 1;
+
+		if (prepare_other_cmd(info, (command == NAND_CMD_READID) ?
+				cmdset->read_id : cmdset->read_status))
+			break;
+
+		pxa3xx_nand_do_cmd(info, NDSR_RDDREQ);
+		break;
+	case NAND_CMD_RESET:
+		if (prepare_other_cmd(info, cmdset->reset))
+			break;
+
+		ret = pxa3xx_nand_do_cmd(info, NDSR_CS0_CMDD);
+		if (ret == 0) {
+			int timeout = 2;
+			uint32_t ndcr;
+
+			while (timeout--) {
+				if (nand_readl(info, NDSR) & NDSR_RDY)
+					break;
+				msleep(10);
+			}
+
+			ndcr = nand_readl(info, NDCR);
+			nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+		}
+		break;
+	default:
+		printk(KERN_ERR "non-supported command.\n");
+		break;
+	}
+
+	if (info->retcode == ERR_DBERR) {
+		printk(KERN_ERR "double bit error @ page %08x\n", page_addr);
+		info->retcode = ERR_NONE;
+	}
+}
+
+static uint8_t pxa3xx_nand_read_byte(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	char retval = 0xFF;
+
+	if (info->buf_start < info->buf_count)
+		/* Has just send a new command? */
+		retval = info->data_buff[info->buf_start++];
+
+	return retval;
+}
+
+static u16 pxa3xx_nand_read_word(struct mtd_info *mtd)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	u16 retval = 0xFFFF;
+
+	if (!(info->buf_start & 0x01) && info->buf_start < info->buf_count) {
+		retval = *((u16 *)(info->data_buff+info->buf_start));
+		info->buf_start += 2;
+	}
+	return retval;
+}
+
+static void pxa3xx_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	int real_len = min_t(size_t, len, info->buf_count - info->buf_start);
+
+	memcpy(buf, info->data_buff + info->buf_start, real_len);
+	info->buf_start += real_len;
+}
+
+static void pxa3xx_nand_write_buf(struct mtd_info *mtd,
+		const uint8_t *buf, int len)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	int real_len = min_t(size_t, len, info->buf_count - info->buf_start);
+
+	memcpy(info->data_buff + info->buf_start, buf, real_len);
+	info->buf_start += real_len;
+}
+
+static int pxa3xx_nand_verify_buf(struct mtd_info *mtd,
+		const uint8_t *buf, int len)
+{
+	return 0;
+}
+
+static void pxa3xx_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+	return;
+}
+
+static int pxa3xx_nand_waitfunc(struct mtd_info *mtd, struct nand_chip *this)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	/* pxa3xx_nand_send_command has waited for command complete */
+	if (this->state == FL_WRITING || this->state == FL_ERASING) {
+		if (info->retcode == ERR_NONE)
+			return 0;
+		else {
+			/*
+			 * any error make it return 0x01 which will tell
+			 * the caller the erase and write fail
+			 */
+			return 0x01;
+		}
+	}
+
+	return 0;
+}
+
+static void pxa3xx_nand_ecc_hwctl(struct mtd_info *mtd, int mode)
+{
+	return;
+}
+
+static int pxa3xx_nand_ecc_calculate(struct mtd_info *mtd,
+		const uint8_t *dat, uint8_t *ecc_code)
+{
+	return 0;
+}
+
+static int pxa3xx_nand_ecc_correct(struct mtd_info *mtd,
+		uint8_t *dat, uint8_t *read_ecc, uint8_t *calc_ecc)
+{
+	struct pxa3xx_nand_info *info = mtd->priv;
+	/*
+	 * Any error include ERR_SEND_CMD, ERR_DBERR, ERR_BUSERR, we
+	 * consider it as a ecc error which will tell the caller the
+	 * read fail We have distinguish all the errors, but the
+	 * nand_read_ecc only check this function return value
+	 */
+	if (info->retcode != ERR_NONE)
+		return -1;
+
+	return 0;
+}
+
+static int __readid(struct pxa3xx_nand_info *info, uint32_t *id)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct pxa3xx_nand_cmdset *cmdset = f->cmdset;
+	uint32_t ndcr;
+	uint8_t  id_buff[8];
+
+	if (prepare_other_cmd(info, cmdset->read_id)) {
+		printk(KERN_ERR "failed to prepare command\n");
+		return -EINVAL;
+	}
+
+	/* Send command */
+	if (write_cmd(info))
+		goto fail_timeout;
+
+	/* Wait for CMDDM(command done successfully) */
+	if (wait_for_event(info, NDSR_RDDREQ))
+		goto fail_timeout;
+
+	__raw_readsl(info->mmio_base + NDDB, id_buff, 2);
+	*id = id_buff[0] | (id_buff[1] << 8);
+	return 0;
+
+fail_timeout:
+	ndcr = nand_readl(info, NDCR);
+	nand_writel(info, NDCR, ndcr & ~NDCR_ND_RUN);
+	udelay(10);
+	return -ETIMEDOUT;
+}
+
+static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
+				    struct pxa3xx_nand_flash *f)
+{
+	struct platform_device *pdev = info->pdev;
+	struct pxa3xx_nand_platform_data *pdata = pdev->dev.platform_data;
+	uint32_t ndcr = 0x00000FFF; /* disable all interrupts */
+
+	if (f->page_size != 2048 && f->page_size != 512)
+		return -EINVAL;
+
+	if (f->flash_width != 16 && f->flash_width != 8)
+		return -EINVAL;
+
+	/* calculate flash information */
+	f->oob_size = (f->page_size == 2048) ? 64 : 16;
+	f->read_id_bytes = (f->page_size == 2048) ? 4 : 2;
+
+	/* calculate addressing information */
+	f->col_addr_cycles = (f->page_size == 2048) ? 2 : 1;
+
+	if (f->num_blocks * f->page_per_block > 65536)
+		f->row_addr_cycles = 3;
+	else
+		f->row_addr_cycles = 2;
+
+	ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0;
+	ndcr |= (f->col_addr_cycles == 2) ? NDCR_RA_START : 0;
+	ndcr |= (f->page_per_block == 64) ? NDCR_PG_PER_BLK : 0;
+	ndcr |= (f->page_size == 2048) ? NDCR_PAGE_SZ : 0;
+	ndcr |= (f->flash_width == 16) ? NDCR_DWIDTH_M : 0;
+	ndcr |= (f->dfc_width == 16) ? NDCR_DWIDTH_C : 0;
+
+	ndcr |= NDCR_RD_ID_CNT(f->read_id_bytes);
+	ndcr |= NDCR_SPARE_EN; /* enable spare by default */
+
+	info->reg_ndcr = ndcr;
+
+	pxa3xx_nand_set_timing(info, f->timing);
+	info->flash_info = f;
+	return 0;
+}
+
+static int pxa3xx_nand_detect_flash(struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_flash *f;
+	uint32_t id;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(builtin_flash_types); i++) {
+
+		f = builtin_flash_types[i];
+
+		if (pxa3xx_nand_config_flash(info, f))
+			continue;
+
+		if (__readid(info, &id))
+			continue;
+
+		if (id == f->chip_id)
+			return 0;
+	}
+
+	return -ENODEV;
+}
+
+/* the maximum possible buffer size for large page with OOB data
+ * is: 2048 + 64 = 2112 bytes, allocate a page here for both the
+ * data buffer and the DMA descriptor
+ */
+#define MAX_BUFF_SIZE	PAGE_SIZE
+
+static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
+{
+	struct platform_device *pdev = info->pdev;
+	int data_desc_offset = MAX_BUFF_SIZE - sizeof(struct pxa_dma_desc);
+
+	if (use_dma == 0) {
+		info->data_buff = kmalloc(MAX_BUFF_SIZE, GFP_KERNEL);
+		if (info->data_buff == NULL)
+			return -ENOMEM;
+		return 0;
+	}
+
+	info->data_buff = dma_alloc_coherent(&pdev->dev, MAX_BUFF_SIZE,
+				&info->data_buff_phys, GFP_KERNEL);
+	if (info->data_buff == NULL) {
+		dev_err(&pdev->dev, "failed to allocate dma buffer\n");
+		return -ENOMEM;
+	}
+
+	info->data_buff_size = MAX_BUFF_SIZE;
+	info->data_desc = (void *)info->data_buff + data_desc_offset;
+	info->data_desc_addr = info->data_buff_phys + data_desc_offset;
+
+	info->data_dma_ch = pxa_request_dma("nand-data", DMA_PRIO_LOW,
+				pxa3xx_nand_data_dma_irq, info);
+	if (info->data_dma_ch < 0) {
+		dev_err(&pdev->dev, "failed to request data dma\n");
+		dma_free_coherent(&pdev->dev, info->data_buff_size,
+				info->data_buff, info->data_buff_phys);
+		return info->data_dma_ch;
+	}
+
+	return 0;
+}
+
+static struct nand_ecclayout hw_smallpage_ecclayout = {
+	.eccbytes = 6,
+	.eccpos = {8, 9, 10, 11, 12, 13 },
+	.oobfree = { {2, 6} }
+};
+
+static struct nand_ecclayout hw_largepage_ecclayout = {
+	.eccbytes = 24,
+	.eccpos = {
+		40, 41, 42, 43, 44, 45, 46, 47,
+		48, 49, 50, 51, 52, 53, 54, 55,
+		56, 57, 58, 59, 60, 61, 62, 63},
+	.oobfree = { {2, 38} }
+};
+
+static void pxa3xx_nand_init_mtd(struct mtd_info *mtd,
+				 struct pxa3xx_nand_info *info)
+{
+	struct pxa3xx_nand_flash *f = info->flash_info;
+	struct nand_chip *this = &info->nand_chip;
+
+	this->options = (f->flash_width == 16) ? NAND_BUSWIDTH_16: 0;
+
+	this->waitfunc		= pxa3xx_nand_waitfunc;
+	this->select_chip	= pxa3xx_nand_select_chip;
+	this->dev_ready		= pxa3xx_nand_dev_ready;
+	this->cmdfunc		= pxa3xx_nand_cmdfunc;
+	this->read_word		= pxa3xx_nand_read_word;
+	this->read_byte		= pxa3xx_nand_read_byte;
+	this->read_buf		= pxa3xx_nand_read_buf;
+	this->write_buf		= pxa3xx_nand_write_buf;
+	this->verify_buf	= pxa3xx_nand_verify_buf;
+
+	this->ecc.mode		= NAND_ECC_HW;
+	this->ecc.hwctl		= pxa3xx_nand_ecc_hwctl;
+	this->ecc.calculate	= pxa3xx_nand_ecc_calculate;
+	this->ecc.correct	= pxa3xx_nand_ecc_correct;
+	this->ecc.size		= f->page_size;
+
+	if (f->page_size == 2048)
+		this->ecc.layout = &hw_largepage_ecclayout;
+	else
+		this->ecc.layout = &hw_smallpage_ecclayout;
+
+	this->chip_delay= 25;
+}
+
+static int pxa3xx_nand_probe(struct platform_device *pdev)
+{
+	struct pxa3xx_nand_platform_data *pdata;
+	struct pxa3xx_nand_info *info;
+	struct nand_chip *this;
+	struct mtd_info *mtd;
+	struct resource *r;
+	int ret = 0, irq;
+
+	pdata = pdev->dev.platform_data;
+
+	if (pdata == NULL) {
+		dev_err(&pdev->dev, "no platform data defined\n");
+		return -ENODEV;
+	}
+
+	mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct pxa3xx_nand_info),
+			GFP_KERNEL);
+	if (mtd == NULL) {
+		dev_err(&pdev->dev, "failed to allocate memory\n");
+		return -ENOMEM;
+        }
+
+	info = (struct pxa3xx_nand_info *)(&mtd[1]);
+	info->pdev = pdev;
+
+	this = &info->nand_chip;
+	mtd->priv = info;
+
+	info->clk = clk_get(&pdev->dev, "NANDCLK");
+	if (IS_ERR(info->clk)) {
+		dev_err(&pdev->dev, "failed to get nand clock\n");
+		ret = PTR_ERR(info->clk);
+		goto fail_free_mtd;
+	}
+	clk_enable(info->clk);
+
+	r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "no resource defined for data DMA\n");
+		ret = -ENXIO;
+		goto fail_put_clk;
+	}
+	info->drcmr_dat = r->start;
+
+	r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "no resource defined for command DMA\n");
+		ret = -ENXIO;
+		goto fail_put_clk;
+	}
+	info->drcmr_cmd = r->start;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "no IRQ resource defined\n");
+		ret = -ENXIO;
+		goto fail_put_clk;
+	}
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "no IO memory resource defined\n");
+		ret = -ENODEV;
+		goto fail_put_clk;
+	}
+
+	r = request_mem_region(r->start, r->end - r->start + 1, pdev->name);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "failed to request memory resource\n");
+		ret = -EBUSY;
+		goto fail_put_clk;
+	}
+
+	info->mmio_base = ioremap(r->start, r->end - r->start + 1);
+	if (info->mmio_base == NULL) {
+		dev_err(&pdev->dev, "ioremap() failed\n");
+		ret = -ENODEV;
+		goto fail_free_res;
+	}
+
+	ret = pxa3xx_nand_init_buff(info);
+	if (ret)
+		goto fail_free_io;
+
+	ret = request_irq(IRQ_NAND, pxa3xx_nand_irq, IRQF_DISABLED,
+				pdev->name, info);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ\n");
+		goto fail_free_buf;
+	}
+
+	ret = pxa3xx_nand_detect_flash(info);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to detect flash\n");
+		ret = -ENODEV;
+		goto fail_free_irq;
+	}
+
+	pxa3xx_nand_init_mtd(mtd, info);
+
+	platform_set_drvdata(pdev, mtd);
+
+	if (nand_scan(mtd, 1)) {
+		dev_err(&pdev->dev, "failed to scan nand\n");
+		ret = -ENXIO;
+		goto fail_free_irq;
+	}
+
+	return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
+
+fail_free_irq:
+	free_irq(IRQ_NAND, info);
+fail_free_buf:
+	if (use_dma) {
+		pxa_free_dma(info->data_dma_ch);
+		dma_free_coherent(&pdev->dev, info->data_buff_size,
+			info->data_buff, info->data_buff_phys);
+	} else
+		kfree(info->data_buff);
+fail_free_io:
+	iounmap(info->mmio_base);
+fail_free_res:
+	release_mem_region(r->start, r->end - r->start + 1);
+fail_put_clk:
+	clk_disable(info->clk);
+	clk_put(info->clk);
+fail_free_mtd:
+	kfree(mtd);
+	return ret;
+}
+
+static int pxa3xx_nand_remove(struct platform_device *pdev)
+{
+	struct mtd_info *mtd = platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	platform_set_drvdata(pdev, NULL);
+
+	del_mtd_device(mtd);
+	del_mtd_partitions(mtd);
+	free_irq(IRQ_NAND, info);
+	if (use_dma) {
+		pxa_free_dma(info->data_dma_ch);
+		dma_free_writecombine(&pdev->dev, info->data_buff_size,
+				info->data_buff, info->data_buff_phys);
+	} else
+		kfree(info->data_buff);
+	kfree(mtd);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int pxa3xx_nand_suspend(struct platform_device *pdev,
pm_message_t state)
+{
+	struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	if (info->state != STATE_READY) {
+		dev_err(&pdev->dev, "driver busy, state = %d\n", info->state);
+		return -EAGAIN;
+	}
+
+	return 0;
+}
+
+static int pxa3xx_nand_resume(struct platform_device *pdev)
+{
+	struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
+	struct pxa3xx_nand_info *info = mtd->priv;
+
+	clk_enable(info->clk);
+
+	return pxa3xx_nand_config_flash(info);
+}
+#else
+#define pxa3xx_nand_suspend	NULL
+#define pxa3xx_nand_resume	NULL
+#endif
+
+static struct platform_driver pxa3xx_nand_driver = {
+	.driver = {
+		.name	= "pxa3xx-nand",
+	},
+	.probe		= pxa3xx_nand_probe,
+	.remove		= pxa3xx_nand_remove,
+	.suspend	= pxa3xx_nand_suspend,
+	.resume		= pxa3xx_nand_resume,
+};
+
+static int __init pxa3xx_nand_init(void)
+{
+	return platform_driver_register(&pxa3xx_nand_driver);
+}
+module_init(pxa3xx_nand_init);
+
+static void __exit pxa3xx_nand_exit(void)
+{
+	platform_driver_unregister(&pxa3xx_nand_driver);
+}
+module_exit(pxa3xx_nand_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("PXA3xx NAND controller driver");
diff --git a/include/asm-arm/arch-pxa/pxa3xx_nand.h
b/include/asm-arm/arch-pxa/pxa3xx_nand.h
new file mode 100644
index 0000000..81a8937
--- /dev/null
+++ b/include/asm-arm/arch-pxa/pxa3xx_nand.h
@@ -0,0 +1,18 @@
+#ifndef __ASM_ARCH_PXA3XX_NAND_H
+#define __ASM_ARCH_PXA3XX_NAND_H
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
+struct pxa3xx_nand_platform_data {
+
+	/* the data flash bus is shared between the Static Memory
+	 * Controller and the Data Flash Controller,  the arbiter
+	 * controls the ownership of the bus
+	 */
+	int	enable_arbiter;
+
+	struct mtd_partition *parts;
+	unsigned int	nr_parts;
+};
+#endif /* __ASM_ARCH_PXA3XX_NAND_H */
-- 
1.5.3.8


-- 
Cheers
- eric


From eric.y.miao at gmail.com  Tue Feb 19 01:37:28 2008
From: eric.y.miao at gmail.com (eric miao)
Date: Tue, 19 Feb 2008 14:37:28 +0800
Subject: [PATCH 2/4] pxa: add pxa3xx NAND device and clock sources
Message-ID: <f17812d70802182237n581c9698vbeea87d506eaf114@mail.gmail.com>

>From de5ebfd2cef21a6342a540583df87b6c8a591dcc Mon Sep 17 00:00:00 2001
From: eric miao <eric.miao at marvell.com>
Date: Tue, 19 Feb 2008 11:16:12 +0800
Subject: [PATCH] pxa: add pxa3xx NAND device and clock sources

A pxa3xx_set_nand_info() is also introduced to set the PXA3xx NAND driver
specific platform_data structure pointer.

Signed-off-by: eric miao <eric.miao at marvell.com>
Cc: Sergey Podstavin <spodstavin at ru.mvista.com>
---
 arch/arm/mach-pxa/devices.c            |   43 ++++++++++++++++++++++++++++++++
 arch/arm/mach-pxa/devices.h            |    2 +
 arch/arm/mach-pxa/pxa300.c             |   11 ++++++++
 arch/arm/mach-pxa/pxa320.c             |   11 ++++++++
 include/asm-arm/arch-pxa/pxa3xx_nand.h |    2 +
 5 files changed, 69 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index bfccb80..af5dd95 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -11,6 +11,7 @@
 #include <asm/arch/irda.h>
 #include <asm/arch/i2c.h>
 #include <asm/arch/ohci.h>
+#include <asm/arch/pxa3xx_nand.h>

 #include "devices.h"

@@ -660,4 +661,46 @@ void __init pxa3xx_set_mci3_info(struct
pxamci_platform_data *info)
 	pxa_register_device(&pxa3xx_device_mci3, info);
 }

+static struct resource pxa3xx_resources_nand[] = {
+	[0] = {
+		.start	= 0x43100000,
+		.end	= 0x43100054,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_NAND,
+		.end	= IRQ_NAND,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		/* DRCMR register index for data transfer */
+		.start	= 97,
+		.end	= 97,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		/* DRCMR register index for command transfer */
+		.start	= 98,
+		.end	= 98,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static u64 pxa3xx_nand_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device pxa3xx_device_nand = {
+	.name		= "pxa3xx-nand",
+	.id		= -1,
+	.dev		= {
+		.dma_mask = &pxa3xx_nand_dma_mask,
+		.coherent_dma_mask = DMA_BIT_MASK(32),
+	},
+	.resource	= pxa3xx_resources_nand,
+	.num_resources	= ARRAY_SIZE(pxa3xx_resources_nand),
+};
+
+void __init pxa3xx_set_nand_info(struct pxa3xx_nand_platform_data *info)
+{
+	pxa_register_device(&pxa3xx_device_nand, info);
+}
 #endif /* CONFIG_PXA3xx */
diff --git a/arch/arm/mach-pxa/devices.h b/arch/arm/mach-pxa/devices.h
index 96c7c89..95fbd01 100644
--- a/arch/arm/mach-pxa/devices.h
+++ b/arch/arm/mach-pxa/devices.h
@@ -23,4 +23,6 @@ extern struct platform_device pxa27x_device_ssp2;
 extern struct platform_device pxa27x_device_ssp3;
 extern struct platform_device pxa3xx_device_ssp4;

+extern struct platform_device pxa3xx_device_nand;
+
 void __init pxa_register_device(struct platform_device *dev, void *data);
diff --git a/arch/arm/mach-pxa/pxa300.c b/arch/arm/mach-pxa/pxa300.c
index 5477e0a..8afdd6b 100644
--- a/arch/arm/mach-pxa/pxa300.c
+++ b/arch/arm/mach-pxa/pxa300.c
@@ -15,9 +15,14 @@

 #include <linux/module.h>
 #include <linux/kernel.h>
+#include <linux/platform_device.h>

 #include <asm/hardware.h>
 #include <asm/arch/mfp-pxa300.h>
+#include <asm/arch/pxa3xx-regs.h>
+
+#include "devices.h"
+#include "clock.h"

 static struct pxa3xx_mfp_addr_map pxa300_mfp_addr_map[] __initdata = {

@@ -79,11 +84,17 @@ static struct pxa3xx_mfp_addr_map
pxa310_mfp_addr_map[] __initdata = {
 	MFP_ADDR_END,
 };

+static struct clk common_clks[] = {
+	PXA3xx_CKEN("NANDCLK", NAND, 156000000, 0, &pxa3xx_device_nand.dev),
+};
+
 static int __init pxa300_init(void)
 {
 	if (cpu_is_pxa300() || cpu_is_pxa310()) {
 		pxa3xx_init_mfp();
 		pxa3xx_mfp_init_addr(pxa300_mfp_addr_map);
+
+		clks_register(common_clks, ARRAY_SIZE(common_clks));
 	}

 	if (cpu_is_pxa310())
diff --git a/arch/arm/mach-pxa/pxa320.c b/arch/arm/mach-pxa/pxa320.c
index 9edaafd..5a568b4 100644
--- a/arch/arm/mach-pxa/pxa320.c
+++ b/arch/arm/mach-pxa/pxa320.c
@@ -15,10 +15,15 @@

 #include <linux/module.h>
 #include <linux/kernel.h>
+#include <linux/platform_device.h>

 #include <asm/hardware.h>
 #include <asm/arch/mfp.h>
 #include <asm/arch/mfp-pxa320.h>
+#include <asm/arch/pxa3xx-regs.h>
+
+#include "devices.h"
+#include "clock.h"

 static struct pxa3xx_mfp_addr_map pxa320_mfp_addr_map[] __initdata = {

@@ -74,11 +79,17 @@ static struct pxa3xx_mfp_addr_map
pxa320_mfp_addr_map[] __initdata = {
 	MFP_ADDR_END,
 };

+static struct clk pxa320_clks[] = {
+	PXA3xx_CKEN("NANDCLK", NAND, 108000000, 0, &pxa3xx_device_nand.dev),
+};
+
 static int __init pxa320_init(void)
 {
 	if (cpu_is_pxa320()) {
 		pxa3xx_init_mfp();
 		pxa3xx_mfp_init_addr(pxa320_mfp_addr_map);
+
+		clks_register(pxa320_clks, ARRAY_SIZE(pxa320_clks));
 	}

 	return 0;
diff --git a/include/asm-arm/arch-pxa/pxa3xx_nand.h
b/include/asm-arm/arch-pxa/pxa3xx_nand.h
index 81a8937..427fa8a 100644
--- a/include/asm-arm/arch-pxa/pxa3xx_nand.h
+++ b/include/asm-arm/arch-pxa/pxa3xx_nand.h
@@ -15,4 +15,6 @@ struct pxa3xx_nand_platform_data {
 	struct mtd_partition *parts;
 	unsigned int	nr_parts;
 };
+
+void pxa3xx_set_nand_info(struct pxa3xx_nand_platform_data *info);
 #endif /* __ASM_ARCH_PXA3XX_NAND_H */
-- 
1.5.3.8


-- 
Cheers
- eric


From eric.y.miao at gmail.com  Tue Feb 19 01:38:05 2008
From: eric.y.miao at gmail.com (eric miao)
Date: Tue, 19 Feb 2008 14:38:05 +0800
Subject: [PATCH 3/4] pxa: add PXA3xx NAND support for Zylonite
Message-ID: <f17812d70802182238o9f7d009q8b4049e78e06017e@mail.gmail.com>

>From 060877de6089c9541b775bd361b4ab78726ea874 Mon Sep 17 00:00:00 2001
From: eric miao <eric.miao at marvell.com>
Date: Tue, 19 Feb 2008 11:16:49 +0800
Subject: [PATCH] pxa: add PXA3xx NAND support for Zylonite

Signed-off-by: eric miao <eric.miao at marvell.com>
Cc: Sergey Podstavin <spodstavin at ru.mvista.com>
---
 arch/arm/mach-pxa/zylonite.c |   52 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
index 7731d50..2a0caa4 100644
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -26,6 +26,7 @@
 #include <asm/arch/pxafb.h>
 #include <asm/arch/zylonite.h>
 #include <asm/arch/mmc.h>
+#include <asm/arch/pxa3xx_nand.h>

 #include "generic.h"

@@ -249,6 +250,56 @@ static void __init zylonite_init_mmc(void)
 static inline void zylonite_init_mmc(void) {}
 #endif

+#if defined(CONFIG_MTD_NAND_PXA3xx) || defined(CONFIG_MTD_NAND_PXA3xx_MODULES)
+static struct mtd_partition zylonite_nand_partitions[] = {
+	[0] = {
+		.name        = "Bootloader",
+		.offset      = 0,
+		.size        = 0x060000,
+		.mask_flags  = MTD_WRITEABLE, /* force read-only */
+	},
+	[1] = {
+		.name        = "Kernel",
+		.offset      = 0x060000,
+		.size        = 0x200000,
+		.mask_flags  = MTD_WRITEABLE, /* force read-only */
+	},
+	[2] = {
+		.name        = "Filesystem",
+		.offset      = 0x0260000,
+		.size        = 0x3000000,     /* 48M - rootfs */
+	},
+	[3] = {
+		.name        = "MassStorage",
+		.offset      = 0x3260000,
+		.size        = 0x3d40000,
+	},
+	[4] = {
+		.name        = "BBT",
+		.offset      = 0x6FA0000,
+		.size        = 0x80000,
+		.mask_flags  = MTD_WRITEABLE,  /* force read-only */
+	},
+	/* NOTES: We reserve some blocks for PXA3xx BBM at the end of NAND.
+	 * And the max relocation blocks is not same on different platform.
+	 * Please take care it when define the partition table.
+	 */
+};
+
+static struct pxa3xx_nand_platform_data zylonite_nand_info = {
+	.enable_arbiter	= 1,
+	.parts		= zylonite_nand_partitions,
+	.nr_parts	= ARRAY_SIZE(zylonite_nand_partitions),
+};
+
+static void __init zylonite_init_nand(void)
+{
+	pxa3xx_set_nand_info(&zylonite_nand_info);
+}
+#else
+static inline void zylonite_init_nand(void) {}
+#endif
+
 static void __init zylonite_init(void)
 {
 	/* board-processor specific initialization */
@@ -265,6 +316,7 @@ static void __init zylonite_init(void)

 	zylonite_init_lcd();
 	zylonite_init_mmc();
+	zylonite_init_nand();
 }

 MACHINE_START(ZYLONITE, "PXA3xx Platform Development Kit (aka Zylonite)")
-- 
1.5.3.8



-- 
Cheers
- eric


From eric.y.miao at gmail.com  Tue Feb 19 01:38:46 2008
From: eric.y.miao at gmail.com (eric miao)
Date: Tue, 19 Feb 2008 14:38:46 +0800
Subject: [PATCH 4/4] pxa: add PXA3xx NAND support for Littleton
Message-ID: <f17812d70802182238g6000916bx848145ffee4044d2@mail.gmail.com>

>From 6c41de6f63c5f34b2687ce033c50f937f870cae6 Mon Sep 17 00:00:00 2001
From: eric miao <eric.miao at marvell.com>
Date: Tue, 19 Feb 2008 11:17:16 +0800
Subject: [PATCH] pxa: add PXA3xx NAND support for Littleton

Signed-off-by: eric miao <eric.miao at marvell.com>
Cc: Sergey Podstavin <spodstavin at ru.mvista.com>
---
 arch/arm/mach-pxa/littleton.c |   52 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/littleton.c b/arch/arm/mach-pxa/littleton.c
index 0a4b54c..a610829 100644
--- a/arch/arm/mach-pxa/littleton.c
+++ b/arch/arm/mach-pxa/littleton.c
@@ -37,6 +37,7 @@
 #include <asm/arch/gpio.h>
 #include <asm/arch/pxafb.h>
 #include <asm/arch/ssp.h>
+#include <asm/arch/pxa3xx_nand.h>
 #include <asm/arch/littleton.h>

 #include "generic.h"
@@ -300,6 +301,56 @@ static void littleton_init_lcd(void)
 static inline void littleton_init_lcd(void) {};
 #endif /* CONFIG_FB_PXA || CONFIG_FB_PXA_MODULES */

+#if defined(CONFIG_MTD_NAND_PXA3xx) || defined(CONFIG_MTD_NAND_PXA3xx_MODULES)
+static struct mtd_partition littleton_nand_partitions[] = {
+	[0] = {
+		.name        = "Bootloader",
+		.offset      = 0,
+		.size        = 0x060000,
+		.mask_flags  = MTD_WRITEABLE, /* force read-only */
+	},
+	[1] = {
+		.name        = "Kernel",
+		.offset      = 0x060000,
+		.size        = 0x200000,
+		.mask_flags  = MTD_WRITEABLE, /* force read-only */
+	},
+	[2] = {
+		.name        = "Filesystem",
+		.offset      = 0x0260000,
+		.size        = 0x3000000,     /* 48M - rootfs */
+	},
+	[3] = {
+		.name        = "MassStorage",
+		.offset      = 0x3260000,
+		.size        = 0x3d40000,
+	},
+	[4] = {
+		.name        = "BBT",
+		.offset      = 0x6FA0000,
+		.size        = 0x80000,
+		.mask_flags  = MTD_WRITEABLE,  /* force read-only */
+	},
+	/* NOTES: We reserve some blocks for PXA3xx BBM at the end of NAND.
+	 * And the max relocation blocks is not same on different platform.
+	 * Please take care it when define the partition table.
+	 */
+};
+
+static struct pxa3xx_nand_platform_data littleton_nand_info = {
+	.enable_arbiter	= 1,
+	.parts		= littleton_nand_partitions,
+	.nr_parts	= ARRAY_SIZE(littleton_nand_partitions),
+};
+
+static void __init littleton_init_nand(void)
+{
+	pxa3xx_set_nand_info(&littleton_nand_info);
+}
+#else
+static inline void littleton_init_nand(void) {}
+#endif
+
 static void __init littleton_init(void)
 {
 	/* initialize MFP configurations */
@@ -312,6 +363,7 @@ static void __init littleton_init(void)
 	platform_device_register(&smc91x_device);

 	littleton_init_lcd();
+	littleton_init_nand();
 }

 MACHINE_START(LITTLETON, "Marvell Form Factor Development Platform
(aka Littleton)")
-- 
1.5.3.8



-- 
Cheers
- eric


From haver at vnet.ibm.com  Mon Feb 18 11:49:03 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Mon, 18 Feb 2008 17:49:03 +0100
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
Message-ID: <1203353343.8085.48.camel@august>

Hi Thomas,

On Mon, 2008-02-18 at 17:01 +0100, Thomas Gleixner wrote:
> I did not update for some time, but did now and noticed that my
> packaging scripts need a real overhaul for no benefit.
> 

I talked to Artem. He told me that the tools had deficiencies that
prevented him using them. E.g. that he could not put the vid-hdr the
offset he wanted it to put. He promissed me to write up the deficiencies
so that we can work on them. I am sure that after fixing, we can move
the tools back to their old location.

Of course it would be nice, if we could move the tools back even before
the fixup, to avoid changing our build scripts. Let us discuss that with
Artem tomorrow.

Regards,

Frank

-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080218/0b4cf200/attachment.bin 

From suryavanshivj at LNTEBG.com  Mon Feb 18 22:41:11 2008
From: suryavanshivj at LNTEBG.com (Vanita Suryavanshi)
Date: Tue, 19 Feb 2008 09:11:11 +0530
Subject: Fwd: cloning jffs2 file system
Message-ID: <47BA9D2F020000760000061C@EBGMAIL2.MAIL.LNTEBG.COM>



Best Regards,
Vanita Suryavanshi
Design Engineer,
Automation Systems Center,
Navi Mumbai.
-------------- next part --------------
An embedded message was scrubbed...
From: "Vanita Suryavanshi" <suryavanshivj at LNTEBG.com>
Subject: cloning jffs2 file system
Date: Sat, 16 Feb 2008 12:36:45 +0530
Size: 1065
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20080219/19e66f7b/attachment.mht 

From haver at vnet.ibm.com  Tue Feb 19 03:47:36 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Tue, 19 Feb 2008 09:47:36 +0100
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <20080218105324.1734f9d5@weaponx>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>  <20080218105324.1734f9d5@weaponx>
Message-ID: <1203410856.7714.7.camel@august>

Hi Josh,

On Mon, 2008-02-18 at 10:53 -0600, Josh Boyer wrote:
> I also have a patch for
> bin2nand/nand2bin since they are hard coded to use the SmartMedia ECC
> byte ordering.

I added fixes to be more flexible in the fashion the tools place the
OOB-ECC bytes already some time ago. Please have a look if those changes
already do what you had in mind here.

Yesterday I sent a patch to move the location of bin2nand and nand2bin
since those tools are not UBI related. If David accepts the change, you
will find them at a different spot (but anyhow, you were on CC list for
that patch).

Regards,

Frank


-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080219/7f97fd88/attachment-0001.bin 

From dedekind at infradead.org  Tue Feb 19 04:34:17 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Tue, 19 Feb 2008 11:34:17 +0200
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203353343.8085.48.camel@august>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>
Message-ID: <1203413657.3758.25.camel@sauron>

On Mon, 2008-02-18 at 17:49 +0100, Frank Haverkamp wrote:
> I talked to Artem. He told me that the tools had deficiencies that
> prevented him using them. E.g. that he could not put the vid-hdr the
> offset he wanted it to put. He promissed me to write up the deficiencies
> so that we can work on them. I am sure that after fixing, we can move
> the tools back to their old location.
> 
> Of course it would be nice, if we could move the tools back even before
> the fixup, to avoid changing our build scripts. Let us discuss that with
> Artem tomorrow.

I can return the tools to the state they were before I touched them, is
it OK for you?

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From richard.genoud at gmail.com  Tue Feb 19 06:14:20 2008
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 19 Feb 2008 12:14:20 +0100
Subject: [PATCH] NAND hardware ECC controller on at91sam9263 / at91sam9260
Message-ID: <47BABA0C.8070500@gmail.com>

This is a patch to use the hardware ECC controller of
the AT91SAM9260 and AT91SAM9263 for the AT91 nand.
On AT91 NAND, there's now a choice between ECC soft,
ECC hard or no ECC (for debug).

It has been tested on AT91SAM9263 with 8 bits large
and small page NAND.


kernel version : 2.6.25-rc2

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>

---
 arch/arm/mach-at91/at91sam9260_devices.c |    9 +-
 arch/arm/mach-at91/at91sam9263_devices.c |    9 +-
 drivers/mtd/nand/Kconfig                 |   41 ++++
 drivers/mtd/nand/at91_nand.c             |  361 +++++++++++++++++++++++++++++-
 include/asm-arm/arch-at91/at91_ecc.h     |   12 +-
 include/asm-arm/arch-at91/at91sam9260.h  |   21 ++
 include/asm-arm/arch-at91/at91sam9263.h  |   27 +++
 7 files changed, 466 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 105f840..f494d92 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -288,11 +288,16 @@ static struct at91_nand_data nand_data;
 #define NAND_BASE	AT91_CHIPSELECT_3
 
 static struct resource nand_resources[] = {
-	{
+	[0] = {
 		.start	= NAND_BASE,
 		.end	= NAND_BASE + SZ_256M - 1,
 		.flags	= IORESOURCE_MEM,
-	}
+	},
+	[1] = {
+		.start	= AT91SAM9260_ECC,
+		.end	= AT91SAM9260_ECC + SZ_512 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
 };
 
 static struct platform_device at91sam9260_nand_device = {
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 0b12e1a..fc0d50a 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -358,11 +358,16 @@ static struct at91_nand_data nand_data;
 #define NAND_BASE	AT91_CHIPSELECT_3
 
 static struct resource nand_resources[] = {
-	{
+	[0] = {
 		.start	= NAND_BASE,
 		.end	= NAND_BASE + SZ_256M - 1,
 		.flags	= IORESOURCE_MEM,
-	}
+	},
+	[1] = {
+		.start	= AT91SAM9263_ECC0,
+		.end	= AT91SAM9263_ECC0 + SZ_512 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
 };
 
 static struct platform_device at91sam9263_nand_device = {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4a3c675..360f073 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -278,6 +278,47 @@ config MTD_NAND_AT91
 	help
 	  Enables support for NAND Flash / Smart Media Card interface
 	  on Atmel AT91 processors.
+choice
+	prompt "ECC management for NAND Flash / SmartMedia on AT91"
+	depends on MTD_NAND_AT91
+
+config MTD_NAND_AT91_ECC_HW
+	bool "Hardware ECC"
+	depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9260
+	help
+	  Uses hardware ECC provided by the at91sam9260/at91sam9263 chip
+	  instead of software ECC.
+	  The hardware ECC controller is capable of single bit error
+	  correction and 2-bit random detection per page.
+
+	  NB : hardware and software ECC schemes are incompatible.
+	  If you switch from one to another, you'll have to erase your
+	  mtd partition.
+
+	  If unsure, say Y
+
+config MTD_NAND_AT91_ECC_SOFT
+	bool "Software ECC"
+	help
+	  Uses software ECC.
+
+	  NB : hardware and software ECC schemes are incompatible.
+	  If you switch from one to another, you'll have to erase your
+	  mtd partition.
+
+config MTD_NAND_AT91_ECC_NONE
+	bool "No ECC (testing only, DANGEROUS)"
+	depends on DEBUG_KERNEL
+	help
+	  No ECC will be used.
+	  It's not a good idea and it should be reserved for testing
+	  purpose only.
+
+	  If unsure, say N
+
+	  endchoice
+
+endchoice
 
 config MTD_NAND_CM_X270
 	tristate "Support for NAND Flash on CM-X270 modules"
diff --git a/drivers/mtd/nand/at91_nand.c b/drivers/mtd/nand/at91_nand.c
index c9fb2ac..45f2568 100644
--- a/drivers/mtd/nand/at91_nand.c
+++ b/drivers/mtd/nand/at91_nand.c
@@ -9,6 +9,15 @@
  *  Derived from drivers/mtd/spia.c
  *	 Copyright (C) 2000 Steven J. Hill (sjhill at cotw.com)
  *
+ *
+ *  Add Hardware ECC support for AT91SAM9260 / AT91SAM9263
+ *     Richard Genoud (richard.genoud at gmail.com), Adeneo Copyright (C) 2007
+ *
+ *     Derived from Das U-Boot source code
+ *     		(u-boot-1.1.5/board/atmel/at91sam9263ek/nand.c)
+ *     (C) Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
+ *
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
@@ -29,11 +38,59 @@
 #include <asm/arch/board.h>
 #include <asm/arch/gpio.h>
 
+#ifdef CONFIG_MTD_NAND_AT91_ECC_HW
+#define hard_ecc	1
+#else
+#define hard_ecc	0
+#endif
+
+#ifdef CONFIG_MTD_NAND_AT91_ECC_NONE
+#define no_ecc		1
+#else
+#define no_ecc		0
+#endif
+
+/* Register access macros */
+#define ecc_readl(add, reg)				\
+	__raw_readl(add + AT91_ECC_##reg)
+#define ecc_writel(add, reg, value)			\
+	__raw_writel((value), add + AT91_ECC_##reg)
+
+#include <asm/arch/at91_ecc.h> /* AT91SAM9260/3 ECC registers */
+
+/* oob layout for large page size
+ * bad block info is on bytes 0 and 1
+ * the bytes have to be consecutives to avoid
+ * several NAND_CMD_RNDOUT during read
+ */
+static struct nand_ecclayout at91_oobinfo_large = {
+	.eccbytes = 4,
+	.eccpos = {60, 61, 62, 63},
+	.oobfree = {
+		{2, 58}
+	},
+};
+
+/* oob layout for small page size
+ * bad block info is on bytes 4 and 5
+ * the bytes have to be consecutives to avoid
+ * several NAND_CMD_RNDOUT during read
+ */
+static struct nand_ecclayout at91_oobinfo_small = {
+	.eccbytes = 4,
+	.eccpos = {0, 1, 2, 3},
+	.oobfree = {
+		{6, 10}
+	},
+};
+
 struct at91_nand_host {
 	struct nand_chip	nand_chip;
 	struct mtd_info		mtd;
 	void __iomem		*io_base;
 	struct at91_nand_data	*board;
+	struct device		*dev;
+	void __iomem		*ecc;
 };
 
 /*
@@ -82,6 +139,215 @@ static void at91_nand_disable(struct at91_nand_host *host)
 		at91_set_gpio_value(host->board->enable_pin, 1);
 }
 
+/*
+ * write oob for small pages
+ */
+static int at91_nand_write_oob_512(struct mtd_info *mtd,
+		struct nand_chip *chip, int page)
+{
+	int chunk = chip->ecc.bytes + chip->ecc.prepad + chip->ecc.postpad;
+	int eccsize = chip->ecc.size, length = mtd->oobsize;
+	int len, pos, status = 0;
+	const uint8_t *bufpoi = chip->oob_poi;
+
+	pos = eccsize + chunk;
+
+	chip->cmdfunc(mtd, NAND_CMD_SEQIN, pos, page);
+	len = min_t(int, length, chunk);
+	chip->write_buf(mtd, bufpoi, len);
+	bufpoi += len;
+	length -= len;
+	if (length > 0)
+		chip->write_buf(mtd, bufpoi, length);
+
+	chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+	status = chip->waitfunc(mtd, chip);
+
+	return status & NAND_STATUS_FAIL ? -EIO : 0;
+
+}
+
+/*
+ * read oob for small pages
+ */
+static int at91_nand_read_oob_512(struct mtd_info *mtd,
+		struct nand_chip *chip,	int page, int sndcmd)
+{
+	if (sndcmd) {
+		chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
+		sndcmd = 0;
+	}
+	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+	return sndcmd;
+}
+
+/*
+ * Calculate HW ECC
+ *
+ * function called after a write
+ *
+ * mtd:        MTD block structure
+ * dat:        raw data (unused)
+ * ecc_code:   buffer for ECC
+ */
+static int at91_nand_calculate(struct mtd_info *mtd,
+		const u_char *dat, unsigned char *ecc_code)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct at91_nand_host *host = nand_chip->priv;
+	uint32_t *eccpos = nand_chip->ecc.layout->eccpos;
+	unsigned int ecc_value;
+
+	/* get the first 2 ECC bytes */
+	ecc_value = ecc_readl(host->ecc, PR) & AT91_ECC_PARITY;
+
+	ecc_code[eccpos[0]] = ecc_value & 0xFF;
+	ecc_code[eccpos[1]] = (ecc_value >> 8) & 0xFF;
+
+	/* get the last 2 ECC bytes */
+	ecc_value = ecc_readl(host->ecc, NPR) & AT91_ECC_NPARITY;
+
+	ecc_code[eccpos[2]] = ecc_value & 0xFF;
+	ecc_code[eccpos[3]] = (ecc_value >> 8) & 0xFF;
+
+	return 0;
+}
+
+/*
+ * HW ECC read page function
+ *
+ * mtd:        mtd info structure
+ * chip:       nand chip info structure
+ * buf:        buffer to store read data
+ */
+static int at91_nand_read_page(struct mtd_info *mtd,
+		struct nand_chip *chip, uint8_t *buf)
+{
+	int eccsize = chip->ecc.size;
+	int eccbytes = chip->ecc.bytes;
+	uint32_t *eccpos = chip->ecc.layout->eccpos;
+	uint8_t *p = buf;
+	uint8_t *oob = chip->oob_poi;
+	uint8_t *ecc_pos;
+	int stat;
+
+	/* read the page */
+	chip->read_buf(mtd, p, eccsize);
+
+	/* move to ECC position if needed */
+	if (eccpos[0] != 0) {
+		/* This only works on large pages
+		 * because the ECC controller waits for
+		 * NAND_CMD_RNDOUTSTART after the
+		 * NAND_CMD_RNDOUT.
+		 * anyway, for small pages, the eccpos[0] == 0
+		 */
+		chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
+				mtd->writesize + eccpos[0], -1);
+	}
+
+	/* the ECC controller needs to read the ECC just after the data */
+	ecc_pos = oob + eccpos[0];
+	chip->read_buf(mtd, ecc_pos, eccbytes);
+
+	/* check if there's an error */
+	stat = chip->ecc.correct(mtd, p, oob, NULL);
+
+	if (stat < 0)
+		mtd->ecc_stats.failed++;
+	else
+		mtd->ecc_stats.corrected += stat;
+
+	/* get back to oob start (end of page) */
+	chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
+
+	/* read the oob */
+	chip->read_buf(mtd, oob, mtd->oobsize);
+
+	return 0;
+}
+
+/*
+ * HW ECC Correction
+ *
+ * function called after a read
+ *
+ * mtd:        MTD block structure
+ * dat:        raw data read from the chip
+ * read_ecc:   ECC from the chip (unused)
+ * isnull:     unused
+ *
+ * Detect and correct a 1 bit error for a page
+ */
+static int at91_nand_correct(struct mtd_info *mtd, u_char *dat,
+		u_char *read_ecc, u_char *isnull)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct at91_nand_host *host = nand_chip->priv;
+	unsigned int ecc_status;
+	unsigned int ecc_word, ecc_bit;
+
+	/* get the status from the Status Register */
+	ecc_status = ecc_readl(host->ecc, SR);
+
+	/* if there's no error */
+	if (likely(!(ecc_status & AT91_ECC_RECERR)))
+		return 0;
+
+	/* get error bit offset (4 bits) */
+	ecc_bit = ecc_readl(host->ecc, PR) & AT91_ECC_BITADDR;
+	/* get word address (12 bits) */
+	ecc_word = ecc_readl(host->ecc, PR) & AT91_ECC_WORDADDR;
+	ecc_word >>= 4;
+
+	/* if there are multiple errors */
+	if (ecc_status & AT91_ECC_MULERR) {
+		/* check if it is a freshly erased block
+		 * (filled with 0xff) */
+		if ((ecc_bit == AT91_ECC_BITADDR)
+				&& (ecc_word == (AT91_ECC_WORDADDR >> 4))) {
+			/* the block has just been erased, return OK */
+			return 0;
+		}
+		/* it doesn't seems to be a freshly
+		 * erased block.
+		 * We can't correct so many errors */
+		dev_dbg(host->dev, "at91_nand : multiple errors detected."
+				" Unable to correct.\n");
+		return -EIO;
+	}
+
+	/* if there's a single bit error : we can correct it */
+	if (ecc_status & AT91_ECC_ECCERR) {
+		/* there's nothing much to do here.
+		 * the bit error is on the ECC itself.
+		 */
+		dev_dbg(host->dev, "at91_nand : one bit error on ECC code."
+				" Nothing to correct\n");
+		return 0;
+	}
+
+	dev_dbg(host->dev, "at91_nand : one bit error on data."
+			" (word offset in the page :"
+			" 0x%x bit offset : 0x%x)\n",
+			ecc_word, ecc_bit);
+	/* correct the error */
+	if (nand_chip->options & NAND_BUSWIDTH_16) {
+		/* 16 bits words */
+		((unsigned short *) dat)[ecc_word] ^= (1 << ecc_bit);
+	} else {
+		/* 8 bits words */
+		dat[ecc_word] ^= (1 << ecc_bit);
+	}
+	dev_dbg(host->dev, "at91_nand : error corrected\n");
+	return 1;
+}
+
+/*
+ * Enable HW ECC : unsused
+ */
+static void at91_nand_hwctl(struct mtd_info *mtd, int mode) { ; }
+
 #ifdef CONFIG_MTD_PARTITIONS
 const char *part_probes[] = { "cmdlinepart", NULL };
 #endif
@@ -94,6 +360,8 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 	struct at91_nand_host *host;
 	struct mtd_info *mtd;
 	struct nand_chip *nand_chip;
+	struct resource *regs;
+	struct resource *mem;
 	int res;
 
 #ifdef CONFIG_MTD_PARTITIONS
@@ -108,8 +376,13 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	host->io_base = ioremap(pdev->resource[0].start,
-				pdev->resource[0].end - pdev->resource[0].start + 1);
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem) {
+		printk(KERN_ERR "at91_nand: can't get I/O resource mem\n");
+		return -ENXIO;
+	}
+
+	host->io_base = ioremap(mem->start, mem->end - mem->start + 1);
 	if (host->io_base == NULL) {
 		printk(KERN_ERR "at91_nand: ioremap failed\n");
 		kfree(host);
@@ -119,6 +392,7 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 	mtd = &host->mtd;
 	nand_chip = &host->nand_chip;
 	host->board = pdev->dev.platform_data;
+	host->dev = &pdev->dev;
 
 	nand_chip->priv = host;		/* link the private data structures */
 	mtd->priv = nand_chip;
@@ -132,7 +406,32 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 	if (host->board->rdy_pin)
 		nand_chip->dev_ready = at91_nand_device_ready;
 
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!regs && hard_ecc) {
+		printk(KERN_ERR "at91_nand: can't get I/O resource "
+				"regs\nFalling back on software ECC\n");
+	}
+
 	nand_chip->ecc.mode = NAND_ECC_SOFT;	/* enable ECC */
+	if (no_ecc)
+		nand_chip->ecc.mode = NAND_ECC_NONE;
+	if (hard_ecc && regs) {
+		host->ecc = ioremap(regs->start, regs->end - regs->start + 1);
+		if (host->ecc == NULL) {
+			printk(KERN_ERR "at91_nand: ioremap failed\n");
+			res = -EIO;
+			goto err_ecc_ioremap;
+		}
+		nand_chip->ecc.mode = NAND_ECC_HW_SYNDROME;
+		nand_chip->ecc.calculate = at91_nand_calculate;
+		nand_chip->ecc.correct = at91_nand_correct;
+		nand_chip->ecc.hwctl = at91_nand_hwctl;
+		nand_chip->ecc.read_page = at91_nand_read_page;
+		nand_chip->ecc.bytes = 4;
+		nand_chip->ecc.prepad = 0;
+		nand_chip->ecc.postpad = 0;
+	}
+
 	nand_chip->chip_delay = 20;		/* 20us command delay time */
 
 	if (host->board->bus_width_16)		/* 16-bit bus width */
@@ -149,8 +448,53 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 		}
 	}
 
-	/* Scan to find existance of the device */
-	if (nand_scan(mtd, 1)) {
+	/* first scan to find the device and get the page size */
+	if (nand_scan_ident(mtd, 1)) {
+		res = -ENXIO;
+		goto out;
+	}
+
+	if (nand_chip->ecc.mode == NAND_ECC_HW_SYNDROME) {
+		/* ECC is calculated for the whole page (1 step) */
+		nand_chip->ecc.size = mtd->writesize;
+
+		/* set ECC page size and oob layout */
+		switch (mtd->writesize) {
+		case 512:
+			nand_chip->ecc.layout = &at91_oobinfo_small;
+			nand_chip->ecc.read_oob = at91_nand_read_oob_512;
+			nand_chip->ecc.write_oob = at91_nand_write_oob_512;
+			ecc_writel(host->ecc, MR, AT91_ECC_PAGESIZE_528);
+			break;
+		case 1024:
+			nand_chip->ecc.layout = &at91_oobinfo_large;
+			ecc_writel(host->ecc, MR, AT91_ECC_PAGESIZE_1056);
+			break;
+		case 2048:
+			nand_chip->ecc.layout = &at91_oobinfo_large;
+			ecc_writel(host->ecc, MR, AT91_ECC_PAGESIZE_2112);
+			break;
+		case 4096:
+			nand_chip->ecc.layout = &at91_oobinfo_large;
+			ecc_writel(host->ecc, MR, AT91_ECC_PAGESIZE_4224);
+			break;
+		default:
+			/* page size not handled by HW ECC */
+			/* switching back to soft ECC */
+			nand_chip->ecc.mode = NAND_ECC_SOFT;
+			nand_chip->ecc.calculate = NULL;
+			nand_chip->ecc.correct = NULL;
+			nand_chip->ecc.hwctl = NULL;
+			nand_chip->ecc.read_page = NULL;
+			nand_chip->ecc.postpad = 0;
+			nand_chip->ecc.prepad = 0;
+			nand_chip->ecc.bytes = 0;
+			break;
+		}
+	}
+
+	/* second phase scan */
+	if (nand_scan_tail(mtd)) {
 		res = -ENXIO;
 		goto out;
 	}
@@ -179,9 +523,15 @@ static int __init at91_nand_probe(struct platform_device *pdev)
 	if (!res)
 		return res;
 
+#ifdef CONFIG_MTD_PARTITIONS
 release:
+#endif
 	nand_release(mtd);
+
 out:
+	iounmap(host->ecc);
+
+err_ecc_ioremap:
 	at91_nand_disable(host);
 	platform_set_drvdata(pdev, NULL);
 	iounmap(host->io_base);
@@ -202,6 +552,7 @@ static int __devexit at91_nand_remove(struct platform_device *pdev)
 	at91_nand_disable(host);
 
 	iounmap(host->io_base);
+	iounmap(host->ecc);
 	kfree(host);
 
 	return 0;
@@ -233,4 +584,4 @@ module_exit(at91_nand_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Rick Bronson");
-MODULE_DESCRIPTION("NAND/SmartMedia driver for AT91RM9200");
+MODULE_DESCRIPTION("NAND/SmartMedia driver for AT91RM9200 / AT91SAM9");
diff --git a/include/asm-arm/arch-at91/at91_ecc.h b/include/asm-arm/arch-at91/at91_ecc.h
index ff93df5..0dc4e6b 100644
--- a/include/asm-arm/arch-at91/at91_ecc.h
+++ b/include/asm-arm/arch-at91/at91_ecc.h
@@ -13,26 +13,28 @@
 #ifndef AT91_ECC_H
 #define AT91_ECC_H
 
-#define AT91_ECC_CR		(AT91_ECC + 0x00)	/* Control register */
+/* ECC registers offsets */
+#define AT91_ECC_CR		0x00				/* Control register */
 #define		AT91_ECC_RST		(1 << 0)		/* Reset parity */
 
-#define AT91_ECC_MR		(AT91_ECC + 0x04)	/* Mode register */
+#define AT91_ECC_MR		0x04				/* Mode register */
 #define		AT91_ECC_PAGESIZE	(3 << 0)		/* Page Size */
 #define			AT91_ECC_PAGESIZE_528		(0)
 #define			AT91_ECC_PAGESIZE_1056		(1)
 #define			AT91_ECC_PAGESIZE_2112		(2)
 #define			AT91_ECC_PAGESIZE_4224		(3)
 
-#define AT91_ECC_SR		(AT91_ECC + 0x08)	/* Status register */
+#define AT91_ECC_SR		0x08				/* Status register */
 #define		AT91_ECC_RECERR		(1 << 0)		/* Recoverable Error */
 #define		AT91_ECC_ECCERR		(1 << 1)		/* ECC Single Bit Error */
 #define		AT91_ECC_MULERR		(1 << 2)		/* Multiple Errors */
 
-#define AT91_ECC_PR		(AT91_ECC + 0x0c)	/* Parity register */
+#define AT91_ECC_PR		0x0c				/* Parity register */
 #define		AT91_ECC_BITADDR	(0xf << 0)		/* Bit Error Address */
 #define		AT91_ECC_WORDADDR	(0xfff << 4)		/* Word Error Address */
+#define		AT91_ECC_PARITY		(0xffff << 0)		/* Parity */
 
-#define AT91_ECC_NPR		(AT91_ECC + 0x10)	/* NParity register */
+#define AT91_ECC_NPR		0x10				/* NParity register */
 #define		AT91_ECC_NPARITY	(0xffff << 0)		/* NParity */
 
 #endif
diff --git a/include/asm-arm/arch-at91/at91sam9260.h b/include/asm-arm/arch-at91/at91sam9260.h
index c8934fe..b2be92b 100644
--- a/include/asm-arm/arch-at91/at91sam9260.h
+++ b/include/asm-arm/arch-at91/at91sam9260.h
@@ -79,6 +79,27 @@
 #define AT91_BASE_SYS			0xffffe800
 
 /*
+ * System Peripherals physical base addresses.
+ */
+#define AT91SAM9260_ECC		0xffffe800
+#define AT91SAM9260_SDRAMC	0xffffea00
+#define AT91SAM9260_SMC		0xffffec00
+#define AT91SAM9260_MATRIX	0xffffee00
+#define AT91SAM9260_CCFG	0xffffef10
+#define AT91SAM9260_AIC		0xfffff000
+#define AT91SAM9260_DBGU	0xfffff200
+#define AT91SAM9260_PIOA	0xfffff400
+#define AT91SAM9260_PIOB	0xfffff600
+#define AT91SAM9260_PIOC	0xfffff800
+#define AT91SAM9260_PMC		0xfffffc00
+#define AT91SAM9260_RSTC	0xfffffd00
+#define AT91SAM9260_SHDWC	0xfffffd10
+#define AT91SAM9260_RTT		0xfffffd20
+#define AT91SAM9260_PIT		0xfffffd30
+#define AT91SAM9260_WDT		0xfffffd40
+#define AT91SAM9260_GPBR	0xfffffd50
+
+/*
  * System Peripherals (offset from AT91_BASE_SYS)
  */
 #define AT91_ECC	(0xffffe800 - AT91_BASE_SYS)
diff --git a/include/asm-arm/arch-at91/at91sam9263.h b/include/asm-arm/arch-at91/at91sam9263.h
index 018a647..acf6bb1 100644
--- a/include/asm-arm/arch-at91/at91sam9263.h
+++ b/include/asm-arm/arch-at91/at91sam9263.h
@@ -75,6 +75,33 @@
 #define AT91_BASE_SYS			0xffffe000
 
 /*
+ * System Peripherals physical base addresses.
+ */
+#define AT91SAM9263_ECC0	0xffffe000
+#define AT91SAM9263_SDRAMC0	0xffffe200
+#define AT91SAM9263_SMC0	0xffffe400
+#define AT91SAM9263_ECC1	0xffffe600
+#define AT91SAM9263_SDRAMC1	0xffffe800
+#define AT91SAM9263_SMC1	0xffffea00
+#define AT91SAM9263_MATRIX	0xffffec00
+#define AT91SAM9263_CCFG	0xffffed10
+#define AT91SAM9263_DBGU	0xffffee00
+#define AT91SAM9263_AIC		0xfffff000
+#define AT91SAM9263_PIOA	0xfffff200
+#define AT91SAM9263_PIOB	0xfffff400
+#define AT91SAM9263_PIOC	0xfffff600
+#define AT91SAM9263_PIOD	0xfffff800
+#define AT91SAM9263_PIOE	0xfffffa00
+#define AT91SAM9263_PMC		0xfffffc00
+#define AT91SAM9263_RSTC	0xfffffd00
+#define AT91SAM9263_SHDWC	0xfffffd10
+#define AT91SAM9263_RTT0	0xfffffd20
+#define AT91SAM9263_PIT		0xfffffd30
+#define AT91SAM9263_WDT		0xfffffd40
+#define AT91SAM9263_RTT1	0xfffffd50
+#define AT91SAM9263_GPBR	0xfffffd60
+
+/*
  * System Peripherals (offset from AT91_BASE_SYS)
  */
 #define AT91_ECC0	(0xffffe000 - AT91_BASE_SYS)



From jwboyer at linux.vnet.ibm.com  Tue Feb 19 07:29:30 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Tue, 19 Feb 2008 06:29:30 -0600
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203410856.7714.7.camel@august>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august> <20080218105324.1734f9d5@weaponx>
	<1203410856.7714.7.camel@august>
Message-ID: <20080219062930.5998990f@zod.rchland.ibm.com>

On Tue, 19 Feb 2008 09:47:36 +0100
Frank Haverkamp <haver at vnet.ibm.com> wrote:

> Hi Josh,
> 
> On Mon, 2008-02-18 at 10:53 -0600, Josh Boyer wrote:
> > I also have a patch for
> > bin2nand/nand2bin since they are hard coded to use the SmartMedia ECC
> > byte ordering.
> 
> I added fixes to be more flexible in the fashion the tools place the
> OOB-ECC bytes already some time ago. Please have a look if those changes
> already do what you had in mind here.

No, they don't.  That was a major part of what I needed (so thank you!),
but ecc layout isn't the same as ecc byte ordering.  I'll post a patch
soonish.

> Yesterday I sent a patch to move the location of bin2nand and nand2bin
> since those tools are not UBI related. If David accepts the change, you
> will find them at a different spot (but anyhow, you were on CC list for
> that patch).

Yes I saw that.  We don't need to wait for David.  I'll look it over
today.

josh


From haver at vnet.ibm.com  Tue Feb 19 04:57:43 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Tue, 19 Feb 2008 10:57:43 +0100
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <1203413657.3758.25.camel@sauron>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>  <1203413657.3758.25.camel@sauron>
Message-ID: <1203415063.7714.12.camel@august>

Hi Artem,

On Tue, 2008-02-19 at 11:34 +0200, Artem Bityutskiy wrote:
> I can return the tools to the state they were before I touched them,
> is
> it OK for you?

that would be very nice of you. And if you could still create the list
of deficiencies e.g. that the modification of the vid-hdr-offset is
missing it would be also nice.

Thanks,

Frank

-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080219/62e7ba60/attachment-0001.bin 

From haver at vnet.ibm.com  Tue Feb 19 07:56:03 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Tue, 19 Feb 2008 13:56:03 +0100
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <20080219062930.5998990f@zod.rchland.ibm.com>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august> <20080218105324.1734f9d5@weaponx>
	<1203410856.7714.7.camel@august>
	<20080219062930.5998990f@zod.rchland.ibm.com>
Message-ID: <1203425764.8598.10.camel@august>

Hi Josh,

On Tue, 2008-02-19 at 06:29 -0600, Josh Boyer wrote:
> No, they don't.  That was a major part of what I needed (so thank
> you!),
> but ecc layout isn't the same as ecc byte ordering.  I'll post a patch
> soonish.

I already thought that ;-). Fine nice that we will get a new feature
into the tool.

Frank

-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080219/c7e51617/attachment.bin 

From joern at logfs.org  Tue Feb 19 10:08:22 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Tue, 19 Feb 2008 16:08:22 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080212161034.GJ30304@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<20080212152124.GA21878@lazybastard.org>
	<chaz20080212161034.GJ30304@artesyncp.com>
Message-ID: <20080219150822.GA29587@lazybastard.org>

[ Just returned home. ]

On Tue, 12 February 2008 16:10:34 +0000, Stephane Chazelas wrote:
> 
> OK, I can do that. Would the "simple" fix go to the
> trivial at kernel.org Trivial Patch Monkey?

That or to me or to dwmw2...  I'm not too picky about the path, as long
as it gets merged eventually.

> > The core of remove_device_by_name() is shared with block2mtd_exit(),
> > so a common helper would be good.  Your error handling is better, so
> > let's keep that version.
> 
> Well, yes that raised a concern to me, the "exit" function
> returns "void". If the del_mtd_device fails with EBUSY at the
> moment (such as when a /dev/mtdblock<x> is mounted), we ignore
> it and go on with freeing everything leaving a dangling mtd.
> 
> Is there a way around that?

For module unload we should be safe.  Errors are only returned if the
device doesn't exist (a clear bug) or if the device is still being used.
Module refcounting should prevent the latter case, so either way we have
a bug if del_mtd_device returns an error.

When removing the device via your proposed interface we should simply
return the error to userspace, if the interface permits.  Sysfs doesn't
seem to permit error returns, so we should keep the device alive and do
nothing.

> Another problem is that it's not easy to check whether a mtd
> creation was successful or not. Basically, you have to write to
> a /sys file and then parse /proc/mtd to get the result.

Agreed, sysfs' lack of error indication isn't ideal.

> What about having a /dev/block2mtd (with owner/permissions that
> could allow non-root users to use it), with 2 ioctls:
> 
> - one to "link" a block dev to a mtd that would take as
>   parameter a fd to an open block dev (again allowing for
>   flexible permissions) and would return the number of the
>   allocated mtd and success/failure in errno. Upon sucess it
>   would increase the refcnt of block2mtd.
> 
> - and one to "release" the link. That would fail if the mtd is
>   in use and decrease block2mtd's refcnt upon success.
> 
> A bit like the loop devices (or /dev/ptmx) actually. What do you
> think?

Could work.  Passing the fd raises several alarm bells.  Arnd, any
comments from you?

In general I'd like to see some good reasons for adding an ioctl (or any
other) interface first.  Creating interfaces is hard and you rarely get
a second chance to fix the mess you created before you knew all the
consequenses.

> (also, with the /sys interface, isn't there a potential problem
> with chroots wrt the path given to the /sys file?)

There may be.  Can you check if there is?

J?rn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan


From m_edake at yahoo.com  Tue Feb 19 10:04:12 2008
From: m_edake at yahoo.com (Mangesh Edake)
Date: Tue, 19 Feb 2008 07:04:12 -0800 (PST)
Subject: JFFS2 as rootfs on DataFlash
Message-ID: <109598.62836.qm@web50805.mail.re2.yahoo.com>

Hello all,

I am using atmel dataflash (AT45DB321D) to store the
jffs2 image which is a rootfs. I am downloading the
image to SDRAM and then writing this image to
dataflash using uboot copy (cp) command like this,
u-boot# cp 21000000 14a000 192000

Once I boot the system, jffs2 is mounted as rootfs but
then I continuously get the "Node header CRC failed"
messages and then finally kernel panic with no init
found. 

I'm using mkfs.jffs2 to create an image like,
mkfs.jffs2 -p -l -e 0x2100 -s 0x210 -n -d
/home/me/rootdir -o jffs2.img

I am totally lost and cannot figure out the reason for
the errors. I'd appericiate if anybody help to find
out the reason. 

Following is the ouput LOG.
----------------------------

JFFS2 write-buffering enabled buffer (528) erasesize
(8448)
VFS: Mounted root (jffs2 filesystem) read-write.

Freeing init memory: 76K

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02fc70. {0807,0000,05c2764e,ab6f10c8}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02fbfc. {fb1d,98f7,00000034,00000001}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02fb88. {4269,67af,b497cad1,31616468}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02faa0. {8f02,47b6,00000000,00000000}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02fa2c. {584b,9ef4,e0011985,0000002c}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02f9b8. {8f02,47b6,00000804,f3086019}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02f944. {fb1d,98f7,00000046,00000001}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header 
       .
       .

Warning: unable to open an initial console.

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x0df814. {000e,0000,000000ef,000000f1}

JFFS2 notice: (1) read_unknown: unknown
RWCOMPAT_DELETE nodetype 0X2000 at 0x0df78c
JFFS2 notice: (634) jffs2_get_inode_nodes: Node header
CRC failed at 0x00017c. {6ee6,7d26,00000003,0000005f}

JFFS2 warning: (634) jffs2_do_read_inode_internal: no
data nodes found for ino #5


       .
       .


JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x02c168. {fb1d,98f7,00000062,00000001}

JFFS2 notice: (1) jffs2_get_inode_nodes: Node header
CRC failed at 0x000630. {89ed,0000,00000000,00031db0}

JFFS2 error: (1) jffs2_do_read_inode_internal: CRC
failed for read_inode of inode 2 at physical location
0x2c794

Kernel panic - not syncing: No init found.  Try
passing init= option to kernel.




  --
  Best Regards...
Mangesh Edake.


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 



From trimarchi at gandalf.sssup.it  Tue Feb 19 10:38:21 2008
From: trimarchi at gandalf.sssup.it (trimarchi at gandalf.sssup.it)
Date: Tue, 19 Feb 2008 16:38:21 +0100
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <109598.62836.qm@web50805.mail.re2.yahoo.com>
References: <109598.62836.qm@web50805.mail.re2.yahoo.com>
Message-ID: <20080219163821.gmq5orqmcksgo8wg@feanor.sssup.it>

Quoting Mangesh Edake <m_edake at yahoo.com>:
Hi,
> Hello all,
>
> I am using atmel dataflash (AT45DB321D) to store the
> jffs2 image which is a rootfs. I am downloading the
> image to SDRAM and then writing this image to
> dataflash using uboot copy (cp) command like this,
> u-boot# cp 21000000 14a000 192000
>
> Once I boot the system, jffs2 is mounted as rootfs but
> then I continuously get the "Node header CRC failed"
> messages and then finally kernel panic with no init
> found.
>
> I'm using mkfs.jffs2 to create an image like,
> mkfs.jffs2 -p -l -e 0x2100 -s 0x210 -n -d
> /home/me/rootdir -o jffs2.img
>
Remove -s 0x210 is wrong. If you put the sector size
to 0x210 you have same tricky problem of the garbage
collector that during the live collect remove data,
because it thinks that is an hole.

> I am totally lost and cannot figure out the reason for
> the errors. I'd appericiate if anybody help to find
> out the reason.
>
> Following is the ouput LOG.
> ----------------------------
Clean all the dataflash before, or padding the size with 0xff
If using an u-boot system add the command for erasing dataflash.

Regards Michael


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From anemo at mba.ocn.ne.jp  Tue Feb 19 10:40:52 2008
From: anemo at mba.ocn.ne.jp (Atsushi Nemoto)
Date: Wed, 20 Feb 2008 00:40:52 +0900 (JST)
Subject: at91_nand question
In-Reply-To: <Pine.LNX.4.64.0802181701090.3508@lnxricardw.se.axis.com>
References: <20080219.004337.74388852.anemo@mba.ocn.ne.jp>
	<Pine.LNX.4.64.0802181701090.3508@lnxricardw.se.axis.com>
Message-ID: <20080220.004052.11965069.anemo@mba.ocn.ne.jp>

On Mon, 18 Feb 2008 17:02:40 +0100 (CET), Ricard Wanderlof <ricard.wanderlof at axis.com> wrote:
> > Though it seems work fine as is, I wonder keeping chipselect signal
> > low all the time is normal.
> 
> I think it is necessary for some flash chips. E.g. to erase, one cannot 
> just issue an erase command and make NCE go inactive, as making NCE go 
> inactive stops the erase procedure until asserted again.

Do you mean busy period between erase command and read-status command?
The nand framework does not try to inactivte NCE for that period.

I'm wondering why at91_nand keeps NCE active after all bus operation
are done.

---
Atsushi Nemoto


From trimarchi at gandalf.sssup.it  Tue Feb 19 14:15:48 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 19 Feb 2008 20:15:48 +0100
Subject: [PATCH] Add write verify on dataflash.
Message-ID: <47BB2AE4.1000206@gandalf.sssup.it>

Add the write verification buffer to the dataflash. The
mtd_dataflash has the CONFIG_DATAFLASH_WRITE_VERIFY so
is better a change to Kconfig.

Signed-off-by: Michael Trimarchi <trimarchimichael at yahoo.it>
---
 fs/jffs2/wbuf.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index d1d4f27..ba49f19 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -1236,12 +1236,24 @@ int jffs2_dataflash_setup(struct jffs2_sb_info *c) {
        if (!c->wbuf)
                return -ENOMEM;

+#ifdef CONFIG_JFFS2_FS_WBUF_VERIFY
+       c->wbuf_verify = kmalloc(c->wbuf_pagesize, GFP_KERNEL);
+       if (!c->wbuf_verify) {
+               kfree(c->oobbuf);
+               kfree(c->wbuf);
+               return -ENOMEM;
+       }
+#endif
+
        printk(KERN_INFO "JFFS2 write-buffering enabled buffer (%d) 
erasesize (%d)\n", c->wbuf_pagesize, c->sector_size);

        return 0;
 }

 void jffs2_dataflash_cleanup(struct jffs2_sb_info *c) {
+#ifdef CONFIG_JFFS2_FS_WBUF_VERIFY
+       kfree(c->wbuf_verify);
+#endif
        kfree(c->wbuf);
 }

--
1.5.2.1.174.gcd03



From Caldwell_Darrell at yahoo.com  Tue Feb 19 14:38:23 2008
From: Caldwell_Darrell at yahoo.com (reuters Ponce)
Date: Tue, 19 Feb 2008 23:38:23 +0400
Subject: |>entists Directory in the USA
Message-ID: <655569k8jya0$l3085bf0$8190k7q0@Delldim5150






Brand New 2008 D.entistry Contact List in the US

+ 164,671 De'ntists with City, State, Zip
+ 158,837 Postal Addresses
+ 163,292 Phone Nos
+ 77,033 Facsimile Numbers
+ 45,351 Email Addresses

Until Feb 22 the reduced price is $295 (reg $391)

Send an email to louislansky at hotmail.com  to inquire about this and other Directory we have








to get off our database please put 93430 in the subject


From arnd at arndb.de  Tue Feb 19 17:33:38 2008
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 19 Feb 2008 23:33:38 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080219150822.GA29587@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
Message-ID: <200802192333.39707.arnd@arndb.de>

On Tuesday 19 February 2008, you wrote:
> > What about having a /dev/block2mtd (with owner/permissions that
> > could allow non-root users to use it), with 2 ioctls:
> > 
> > - one to "link" a block dev to a mtd that would take as
> > ? parameter a fd to an open block dev (again allowing for
> > ? flexible permissions) and would return the number of the
> > ? allocated mtd and success/failure in errno. Upon sucess it
> > ? would increase the refcnt of block2mtd.
> > 
> > - and one to "release" the link. That would fail if the mtd is
> > ? in use and decrease block2mtd's refcnt upon success.
> > 
> > A bit like the loop devices (or /dev/ptmx) actually. What do you
> > think?
> 
> Could work. ?Passing the fd raises several alarm bells. ?Arnd, any
> comments from you?

Given that loop works in this way, I certainly see that as doable,
but then I'd vote for using the existing ioctl semantics of
LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
comes with an ioctl interface for mtd devices.
I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
so you can actually use the existing losetup tool.
That way, we wouldn't have to introduce a new API, just extend
an existing one to work on more things.

	Arnd <><


From joern at logfs.org  Wed Feb 20 01:43:22 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Wed, 20 Feb 2008 07:43:22 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <200802192333.39707.arnd@arndb.de>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
Message-ID: <20080220064321.GB29587@lazybastard.org>

On Tue, 19 February 2008 23:33:38 +0100, Arnd Bergmann wrote:
> 
> Given that loop works in this way, I certainly see that as doable,
> but then I'd vote for using the existing ioctl semantics of
> LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
> comes with an ioctl interface for mtd devices.
> I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
> so you can actually use the existing losetup tool.
> That way, we wouldn't have to introduce a new API, just extend
> an existing one to work on more things.

I like this approach.  It somewhat collides with the mtd principle of
having a seperate module for every 2-3 lines of code, but maybe that is
not a bad thing after all.

Onto my list of code to write on rainy afternoons (and secretly hoping
for others to do it instead).

J?rn

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens


From dedekind at infradead.org  Wed Feb 20 05:10:00 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Wed, 20 Feb 2008 12:10:00 +0200
Subject: ubi-utils: Moving mkpfi, pfiflash, ... to old-tools
In-Reply-To: <alpine.LFD.1.00.0802182214000.7583@apollo.tec.linutronix.de>
References: <1203342580.8085.23.camel@august>
	<alpine.LFD.1.00.0802181656260.7583@apollo.tec.linutronix.de>
	<1203353343.8085.48.camel@august>
	<alpine.LFD.1.00.0802182214000.7583@apollo.tec.linutronix.de>
Message-ID: <1203502200.3758.31.camel@sauron>

On Mon, 2008-02-18 at 22:26 +0100, Thomas Gleixner wrote:
> I really give a sh*t whether Artem can use them or not. He is not the
> center of the universe. If he needs them changed, then he should send
> a patch or a suitable replacement for the tool, which does not force
> others to fixup their scripts and build tools for no benefit. This is
> not a sandbox, this are tools used in production environments.
> 
> Artem, please stop this nonsense right now. You can create your own
> world if you have the urge to do so, but please keep stuff others use
> intact. This "I don't like that old crap" attitude is an arrogant and
> at the same time ignorant childish behaviour, which has no place in a
> serious project.
> 
> > E.g. that he could not put the vid-hdr the
> > offset he wanted it to put. He promissed me to write up the deficiencies
> > so that we can work on them. I am sure that after fixing, we can move
> > the tools back to their old location.
> 
> No, they go back to their place immediately, period.
> 
> Yours even more grumpy,

I apologize for this. Indeed that was not nice and arrogant. The tools
are returned to their previous place.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From ken8804 at gmail.com  Wed Feb 20 09:07:03 2008
From: ken8804 at gmail.com (Ken Chan)
Date: Wed, 20 Feb 2008 09:07:03 -0500
Subject: MTD - NAND (Micron MT29F16G08)
Message-ID: <4ffb81490802200607n3d5f6ad5h12f4a53399a32466@mail.gmail.com>

Hi,
I am trying to get my NAND Flash (Micron MT29F16G08 -- 2 GBytes NAND) going.
Based on the data sheet, the page size is 4KB, the Spare area size (i.e.
OOB) is 218 Bytes, the Block size is 512KB.
I am using Linux Kernel 2.6.16 and it does not support this NAND Flash
because of the OOB is 218 Bytes.
I checked the Linux Kernel (2.6.24) and same thing applied.

Here are my questions:
1) How can I build a data structure "struct nand_oobinfo nand_oob_218"?
What shall I put for those eccpos[]?
2) If I don't want to create that new data structure, what is the
alternative method to bring up that NAND Flash?
3) Do anyone have similar problem using that kind of NAND Flash?

Thanks
ken


From stephane.chazelas at emerson.com  Wed Feb 20 09:36:46 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 14:36:46 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080219150822.GA29587@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<20080212152124.GA21878@lazybastard.org>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
Message-ID: <chaz20080220143646.GJ4539@artesyncp.com>

2008-02-19 16:08:22 +0100, J?rn Engel:
> [ Just returned home. ]

Hi J?rn,

I've got to admit I've been a little too busy to look at it
myself. I'll send a patch for the obvious fixes soon though.

[...]
> > Well, yes that raised a concern to me, the "exit" function
> > returns "void". If the del_mtd_device fails with EBUSY at the
> > moment (such as when a /dev/mtdblock<x> is mounted), we ignore
> > it and go on with freeing everything leaving a dangling mtd.
> > 
> > Is there a way around that?
> 
> For module unload we should be safe.  Errors are only returned if the
> device doesn't exist (a clear bug) or if the device is still being used.
> Module refcounting should prevent the latter case, so either way we have
> a bug if del_mtd_device returns an error.

At the moment, when we bind a mtd device to a block device, we
don't increase the refcount. When a mtdblock on a block2mtd, the
refcount is not increased either (the mtdblock's one is I
guess).

When you unload block2mtd, the block2mtd exit code tries and
remove the mtd bindings. If it fails, it exits anyway, leaving
some dangling stuff. That's why I suggested that the exit code
doesn't do the cleaning but that the requirement of cleaning
things up is  put upon the user before he is allowed to unload
the module (increasing the refcount every time block2mtd is used
to map a mtd to a block device).

> When removing the device via your proposed interface we should simply
> return the error to userspace, if the interface permits.  Sysfs doesn't
> seem to permit error returns, so we should keep the device alive and do
> nothing.

Agreed, that's what I was doing in my patch. But I wasn't doing
anything with the refcount, this was still handled as before,
that is we relied on the exit code to do the clean up.

Best regards,
Stephane


From stephane.chazelas at emerson.com  Wed Feb 20 09:43:39 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 14:43:39 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <200802192333.39707.arnd@arndb.de>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
Message-ID: <chaz20080220144339.GK4539@artesyncp.com>

2008-02-19 23:33:38 +0100, Arnd Bergmann:
> On Tuesday 19 February 2008, you wrote:
> > > What about having a /dev/block2mtd (with owner/permissions that
> > > could allow non-root users to use it), with 2 ioctls:
> > > 
> > > - one to "link" a block dev to a mtd that would take as
> > > ? parameter a fd to an open block dev (again allowing for
> > > ? flexible permissions) and would return the number of the
> > > ? allocated mtd and success/failure in errno. Upon sucess it
> > > ? would increase the refcnt of block2mtd.
> > > 
> > > - and one to "release" the link. That would fail if the mtd is
> > > ? in use and decrease block2mtd's refcnt upon success.
> > > 
> > > A bit like the loop devices (or /dev/ptmx) actually. What do you
> > > think?
> > 
> > Could work. ?Passing the fd raises several alarm bells. ?Arnd, any
> > comments from you?
> 
> Given that loop works in this way, I certainly see that as doable,
> but then I'd vote for using the existing ioctl semantics of
> LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
> comes with an ioctl interface for mtd devices.
> I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
> so you can actually use the existing losetup tool.
> That way, we wouldn't have to introduce a new API, just extend
> an existing one to work on more things.
[...]

Hi Arnd,

note that for "loop", you have /dev/loop0, /dev/loop1... which
makes it a pain to handle

For block2mtd, you don't need several device files in /dev, you
only need one to pass ioctls down to create mtd devices.

That may end up creating new /dev devices via mtdblock or
mtdblock_ro for instance.

So I'm not sure reusing the "loop" ioctls is a good idea.

Cheers,
Stephane


From nancydreaming at gmail.com  Wed Feb 20 10:00:00 2008
From: nancydreaming at gmail.com (Nancy)
Date: Wed, 20 Feb 2008 23:00:00 +0800
Subject: ubifs: can't mount ubifs as rootfs
Message-ID: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>

Dear all,
        As you can see at last, ubifs can't mount ubifs as rootfs,
why? How can I make it right?
        same kernel image, just different kernel command line.

PAVO # boot
TFTP from server 192.168.1.20; our IP address is 192.168.1.187
Filename 'yrtan/uImage.26'.
Load address: 0x80600000
Loading: *#T T
 ################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###############################################################
done
Bytes transferred = 1984678 (1e48a6 hex)
Unknown command 'dhcpboot' - try 'help'
## Booting image at 80600000 ...
   Image Name:   Linux-2.6.22
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1984614 Bytes =  1.9 MB
   Load Address: 80100000
   Entry Point:  80529000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.6.22 (yrtan at st.linux) (gcc version 4.1.2) #3 PREEMPT
 Wed Feb 20 19:24:25 CST 2008
CPU revision is: 0ad0024f
System clocks setup: cclk=336MHZ hclk=112MHZ pclk=112MHZ mclk=112MHZ
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
User-defined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Built 1 zonelists.  Total pages: 16256
Kernel command line: mem=64m console=ttyS0,57600 ip=off
 ethaddr=00:a0:dd:ec:ff ubi.mtd=3 root=ubi0:ubifs rw rootfstype=ubifs
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32
 bytes.
Primary data cache 16kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 59324k/65536k available (3473k kernel code, 6156k reserved,
 783k data, 168k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
Total 4MB memory at 0x3c00000 was reserved for IPU
PM initialize
JFFS2 version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
UBIFS error (pid 1): compr_init: cannot initialize compressor LZO
yaffs Feb 20 2008 12:05:35 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
LCDC: PixClock:9081081 LcdClock:25846153
Console: switching to colour frame buffer device 60x34
fb0: jz-lcd frame buffer device, using 512K of video memory
JzSOC onchip RTC installed !!!
JzSOC Watchdog Timer: timer margin 60 sec
JzSOC: char device family.
JzSOC Camera Interface Module (CIM) driver registered
Ingenic CMOS camera sensor driver registered
Jz generic touch screen driver registered
JZ4740 SAR-ADC driver registered
UDC starting monitor thread
JZ UDC hotplug driver installed
Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ sharing
 disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Jz CS8900A driver for Linux (V0.02)
eth%d: CS8900A rev E detected
block2mtd: version $Revision: 1.30 $
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB
 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 522 at 0x082bf800
Creating 6 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x00400000 : "NAND BOOT partition"
0x00400000-0x00800000 : "NAND KERNEL partition"
0x00800000-0x08000000 : "NAND ROOTFS partition"
0x08000000-0x10000000 : "NAND DATA1 partition"
0x10000000-0x20000000 : "NAND DATA2 partition"
0x20000000-0x40000000 : "NAND VFAT partition"
UBI: attached mtd3 to ubi0
UBI: MTD device name:            "NAND DATA1 partition"
UBI: MTD device size:            128 MiB
UBI: physical eraseblock size:   262144 bytes (256 KiB)
UBI: logical eraseblock size:    258048 bytes
UBI: number of good PEBs:        511
UBI: number of bad PEBs:         1
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             298
UBI: total number of reserved PEBs: 213
UBI: number of PEBs reserved for bad PEB handling: 5
UBI: max/mean erase counter: 2/1
UBI: background thread "ubi_bgt0d" started, PID 699
jz-ohci jz-ohci.0: JZ OHCI
jz-ohci jz-ohci.0: new USB bus registered, assigned bus number 1
jz-ohci jz-ohci.0: irq 3, io mem 0x13030000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
JZ SD/MMC card driver registered
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
JzSOC On-Chip I2S controller registered (DAC: DMA(play):2/IRQ34,
 ADC: DMA(record):3/IRQ35)
JZ I2S OSS audio driver initialized
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "ubi0:ubifs" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available
 partitions:
1f00       3584 mtdblock0 (driver?)
1f01       3584 mtdblock1 (driver?)
1f02     120320 mtdblock2 (driver?)
1f03     128512 mtdblock3 (driver?)
1f04     257024 mtdblock4 (driver?)
1f05     519168 mtdblock5 (driver?)
1f06      51408 mtdblock6 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
 unknown-block(2,0)





U-Boot 1.1.6 (Oct  9 2007 - 09:41:44)

Board: Ingenic PAVO (CPU Speed 336 MHz)
DRAM:  64 MB
Flash:  0 kB
NAND:1024 MiB
In:    serial
Out:   lcd
Err:   lcd
Hit any key to stop autoboot:  3  2  1  0
TFTP from server 192.168.1.20; our IP address is 192.168.1.187
Filename 'yrtan/uImage.26'.
Load address: 0x80600000
Loading:
 *#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###############################################################
done
Bytes transferred = 1984678 (1e48a6 hex)
Unknown command 'dhcpboot' - try 'help'
## Booting image at 80600000 ...
   Image Name:   Linux-2.6.22
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1984614 Bytes =  1.9 MB
   Load Address: 80100000
   Entry Point:  80529000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.6.22 (yrtan at st.linux) (gcc version 4.1.2) #3 PREEMPT
 Wed Feb 20 19:24:25 CST 2008
CPU revision is: 0ad0024f
System clocks setup: cclk=336MHZ hclk=112MHZ pclk=112MHZ mclk=112MHZ
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
User-defined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Built 1 zonelists.  Total pages: 16256
Kernel command line: mem=64m console=ttyS0,57600 ip=dhcp
 nfsroot=192.168.1.20:/nfsroot/root26 rw ethaddr=00:a0:dd:ec:ff ubi.mtd=3
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32
 bytes.
Primary data cache 16kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 59324k/65536k available (3473k kernel code, 6156k reserved,
 783k data, 168k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
Total 4MB memory at 0x3c00000 was reserved for IPU
PM initialize
JFFS2 version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
UBIFS error (pid 1): compr_init: cannot initialize compressor LZO
yaffs Feb 20 2008 12:05:35 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
LCDC: PixClock:9081081 LcdClock:25846153
Console: switching to colour frame buffer device 60x34
fb0: jz-lcd frame buffer device, using 512K of video memory
JzSOC onchip RTC installed !!!
JzSOC Watchdog Timer: timer margin 60 sec
JzSOC: char device family.
JzSOC Camera Interface Module (CIM) driver registered
Ingenic CMOS camera sensor driver registered
Jz generic touch screen driver registered
JZ4740 SAR-ADC driver registered
UDC starting monitor thread
JZ UDC hotplug driver installed
Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ sharing
 disabled
??????????5%=?????????????)?RAMDISK driver
 initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Jz CS8900A driver for Linux (V0.02)
eth%d: CS8900A rev E detected
block2mtd: version $Revision: 1.30 $
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB
 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 522 at 0x082bf800
Creating 6 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x00400000 : "NAND BOOT partition"
0x00400000-0x00800000 : "NAND KERNEL partition"
0x00800000-0x08000000 : "NAND ROOTFS partition"
0x08000000-0x10000000 : "NAND DATA1 partition"
0x10000000-0x20000000 : "NAND DATA2 partition"
0x20000000-0x40000000 : "NAND VFAT partition"
UBI: attached mtd3 to ubi0
UBI: MTD device name:            "NAND DATA1 partition"
UBI: MTD device size:            128 MiB
UBI: physical eraseblock size:   262144 bytes (256 KiB)
UBI: logical eraseblock size:    258048 bytes
UBI: number of good PEBs:        511
UBI: number of bad PEBs:         1
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             298
UBI: total number of reserved PEBs: 213
UBI: number of PEBs reserved for bad PEB handling: 5
UBI: max/mean erase counter: 2/1
UBI: background thread "ubi_bgt0d" started, PID 699
jz-ohci jz-ohci.0: JZ OHCI
jz-ohci jz-ohci.0: new USB bus registered, assigned bus number 1
jz-ohci jz-ohci.0: irq 3, io mem 0x13030000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
JZ SD/MMC card driver registered
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
JzSOC On-Chip I2S controller registered (DAC: DMA(play):2/IRQ34,
 ADC: DMA(record):3/IRQ35)
JZ I2S OSS audio driver initialized
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.135
IP-Config: Complete:
      device=eth0, addr=192.168.1.135, mask=255.255.255.0,
 gw=192.168.1.56,
     host=192.168.1.135, domain=st.jz.com, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=192.168.1.20, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.20
Looking up port of RPC 100005/1 on 192.168.1.20
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 168k freed
Algorithmics/MIPS FPU Emulator v1.5
init started: BusyBox v1.8.2 (2008-01-09 19:22:01 CST)
starting pid 726, tty '': '/etc/init.d/rcS'
Starting udevd ...
starting pid 764, tty '': '/bin/sh'
#cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00040000 "NAND BOOT partition"
mtd1: 00400000 00040000 "NAND KERNEL partition"
mtd2: 07800000 00040000 "NAND ROOTFS partition"
mtd3: 08000000 00040000 "NAND DATA1 partition"
mtd4: 10000000 00040000 "NAND DATA2 partition"
mtd5: 20000000 00040000 "NAND VFAT partition"
mtd6: 03234000 0003f000 "ubifs"
# mount -t ubifs ubi0:ubifs /mnt
crc16: exports duplicate symbol crc16 (owned by kernel)
ubi: exports duplicate symbol ubi_is_mapped (owned by kernel)
UBIFS: mounted UBI device 0, volume 0
UBIFS: minimal I/O unit size:   2048 bytes
UBIFS: logical eraseblock size: 258048 bytes (252 KiB)
UBIFS: file system size:        50061312 bytes (48888 KiB, 47 MiB, 194
 LEBs)
UBIFS: journal size:            2580480 bytes (2520 KiB, 2 MiB, 10
 LEBs)
UBIFS: data journal heads:      1
UBIFS: default compressor:      LZO
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
tmpfs                    29772        48     29724   0% /dev
ubi0:ubifs               47724     39720      8004  83% /mnt
#

----
Best wishes,
Nancy

From stephane.chazelas at emerson.com  Wed Feb 20 10:00:21 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 15:00:21 +0000
Subject: [PATCH 2.6.25-rc2] block2mtd: logging typo fixes
Message-ID: <chaz20080220150021.GM4539@artesyncp.com>

Hi joern,

this patch addresses a number of small issues mainly regarding
the output made by this driver to dmesg:
  - Some of the blkmtd's had not been changed to block2mtd which
    caused display problem
  - the parse_err() macro was displaying "block2mtd: " twice

Signed-off-by: Stephane Chazelas <stephane.chazelas at emerson.com>

--- drivers/mtd/devices/block2mtd.c~	2008-02-20 14:56:56.942145223 +0000
+++ drivers/mtd/devices/block2mtd.c	2008-02-20 14:57:15.802131021 +0000
@@ -305,7 +305,7 @@ static struct block2mtd_dev *add_device(
 	}
 	list_add(&dev->list, &blkmtd_device_list);
 	INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
-			dev->mtd.name + strlen("blkmtd: "),
+			dev->mtd.name + strlen("block2mtd: "),
 			dev->mtd.erasesize >> 10, dev->mtd.erasesize);
 	return dev;
 
@@ -366,9 +366,9 @@ static inline void kill_final_newline(ch
 }
 
 
-#define parse_err(fmt, args...) do {		\
-	ERROR("block2mtd: " fmt "\n", ## args);	\
-	return 0;				\
+#define parse_err(fmt, args...) do {	\
+	ERROR(fmt, ## args);		\
+	return 0;			\
 } while (0)
 
 #ifndef MODULE
@@ -474,7 +474,7 @@ static void __devexit block2mtd_exit(voi
 		block2mtd_sync(&dev->mtd);
 		del_mtd_device(&dev->mtd);
 		INFO("mtd%d: [%s] removed", dev->mtd.index,
-				dev->mtd.name + strlen("blkmtd: "));
+				dev->mtd.name + strlen("block2mtd: "));
 		list_del(&dev->list);
 		block2mtd_free_device(dev);
 	}


From dedekind at infradead.org  Wed Feb 20 10:10:27 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Wed, 20 Feb 2008 17:10:27 +0200
Subject: ubifs: can't mount ubifs as rootfs
In-Reply-To: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>
References: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>
Message-ID: <1203520227.3758.40.camel@sauron>

Hi,

On Wed, 2008-02-20 at 23:00 +0800, Nancy wrote:
> Dear all,
>         As you can see at last, ubifs can't mount ubifs as rootfs,
> why? How can I make it right?
>         same kernel image, just different kernel command line.

I think you do not have this patch:

http://git.infradead.org/?p=users/dedekind/ubifs-v2.6.22.git;a=commitdiff;h=9c04728f3cb585f1e0b3df4f0ae2aec1bf73e392;hp=aad43553d81d1b79f64cde3c81b71bfc3036d098

You probably use old UBIFS. Keep in mind, it is constantly developed so
you should always try the latest one if you have problems.

There are 2.6.22, 2.6.23, and 2.6.24 ubifs backports BTW,
see http://www.linux-mtd.infradead.org/doc/ubifs.html#L_source

AFAIR you use 2.6.22, so here it is:

git://git.infradead.org/~dedekind/ubifs-v2.6.22.git

Just download it - it has all the need patches. But I encourage you to
use the lates development tree.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From joern at logfs.org  Wed Feb 20 10:29:10 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Wed, 20 Feb 2008 16:29:10 +0100
Subject: [PATCH 2.6.25-rc2] block2mtd: logging typo fixes
In-Reply-To: <chaz20080220150021.GM4539@artesyncp.com>
References: <chaz20080220150021.GM4539@artesyncp.com>
Message-ID: <20080220152910.GB5539@lazybastard.org>

On Wed, 20 February 2008 15:00:21 +0000, Stephane Chazelas wrote:
> 
> this patch addresses a number of small issues mainly regarding
> the output made by this driver to dmesg:
>   - Some of the blkmtd's had not been changed to block2mtd which
>     caused display problem
>   - the parse_err() macro was displaying "block2mtd: " twice
> 
> Signed-off-by: Stephane Chazelas <stephane.chazelas at emerson.com>
Acked-by: Joern Engel <joern at lazybastard.org>

David, please apply.

J?rn

-- 
"Error protection by error detection and correction."
-- from a university class


From ricard.wanderlof at axis.com  Wed Feb 20 11:25:27 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Wed, 20 Feb 2008 17:25:27 +0100 (CET)
Subject: MTD - NAND (Micron MT29F16G08)
In-Reply-To: <4ffb81490802200607n3d5f6ad5h12f4a53399a32466@mail.gmail.com>
References: <4ffb81490802200607n3d5f6ad5h12f4a53399a32466@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0802201723410.3508@lnxricardw.se.axis.com>


On Wed, 20 Feb 2008, Ken Chan wrote:

> Hi,
> I am trying to get my NAND Flash (Micron MT29F16G08 -- 2 GBytes NAND) going.
> Based on the data sheet, the page size is 4KB, the Spare area size (i.e.
> OOB) is 218 Bytes, the Block size is 512KB.
> I am using Linux Kernel 2.6.16 and it does not support this NAND Flash
> because of the OOB is 218 Bytes.
> I checked the Linux Kernel (2.6.24) and same thing applied.
>
> Here are my questions:
> 1) How can I build a data structure "struct nand_oobinfo nand_oob_218"?
> What shall I put for those eccpos[]?
> 2) If I don't want to create that new data structure, what is the
> alternative method to bring up that NAND Flash?
> 3) Do anyone have similar problem using that kind of NAND Flash?

Just a guess here, does it matter that the exact oob size is not 
supported? As long as there are enough bytes for what is needed (bad block 
indicator, ECC data, and jffs2 cleanmarkers if using jffs2 filesystem) it 
might not matter what the exact size is. Most flashes support reading and 
writing less than a full page or oob.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


From joern at logfs.org  Wed Feb 20 11:30:42 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Wed, 20 Feb 2008 17:30:42 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080220144339.GK4539@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
	<chaz20080220144339.GK4539@artesyncp.com>
Message-ID: <20080220163042.GC5539@lazybastard.org>

On Wed, 20 February 2008 14:43:39 +0000, Stephane Chazelas wrote:
> 
> note that for "loop", you have /dev/loop0, /dev/loop1... which
> makes it a pain to handle
> 
> For block2mtd, you don't need several device files in /dev, you
> only need one to pass ioctls down to create mtd devices.
> 
> That may end up creating new /dev devices via mtdblock or
> mtdblock_ro for instance.
> 
> So I'm not sure reusing the "loop" ioctls is a good idea.

/me notes that you dislike both existing interfaces and would prefer a
third.  How likely is it that you will still like the new interface two
years down the road?  How likely is it that everyone else will agree
with you?

In the end, a painful interface is still less painful than a choice of
several incompatible ones.  I used to think different and have burned my
fingers often enough to learn the lesson. :)

J?rn

-- 
Mac is for working,
Linux is for Networking,
Windows is for Solitaire!
-- stolen from dc


From joern at logfs.org  Wed Feb 20 11:42:27 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Wed, 20 Feb 2008 17:42:27 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080220143646.GJ4539@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<20080212152124.GA21878@lazybastard.org>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<chaz20080220143646.GJ4539@artesyncp.com>
Message-ID: <20080220164226.GF5539@lazybastard.org>

On Wed, 20 February 2008 14:36:46 +0000, Stephane Chazelas wrote:
> 
> At the moment, when we bind a mtd device to a block device, we
> don't increase the refcount. When a mtdblock on a block2mtd, the
> refcount is not increased either (the mtdblock's one is I
> guess).

That is a bug then.

J?rn

-- 
The story so far:
In the beginning the Universe was created.  This has made a lot
of people very angry and been widely regarded as a bad move.
-- Douglas Adams


From stephane.chazelas at emerson.com  Wed Feb 20 11:55:13 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 16:55:13 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080220164226.GF5539@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<20080212152124.GA21878@lazybastard.org>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<chaz20080220143646.GJ4539@artesyncp.com>
	<20080220164226.GF5539@lazybastard.org>
Message-ID: <chaz20080220165513.GU4539@artesyncp.com>

2008-02-20 17:42:27 +0100, J?rn Engel:
> On Wed, 20 February 2008 14:36:46 +0000, Stephane Chazelas wrote:
> > 
> > At the moment, when we bind a mtd device to a block device, we
> > don't increase the refcount. When a mtdblock on a block2mtd, the
> > refcount is not increased either (the mtdblock's one is I
> > guess).
> 
> That is a bug then.
[...]

Well, given that there is no API to unbind a mtd to a block
device, otherwise, we would never be able to unload block2mtd.
So fare, unloading block2mtd was the only way to unbind a mtd
from a block device.

Cheers,
Stephane


From stephane.chazelas at emerson.com  Wed Feb 20 12:02:31 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 17:02:31 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080220163042.GC5539@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
	<chaz20080220144339.GK4539@artesyncp.com>
	<20080220163042.GC5539@lazybastard.org>
Message-ID: <chaz20080220170231.GV4539@artesyncp.com>

2008-02-20 17:30:42 +0100, J?rn Engel:
> On Wed, 20 February 2008 14:43:39 +0000, Stephane Chazelas wrote:
> > 
> > note that for "loop", you have /dev/loop0, /dev/loop1... which
> > makes it a pain to handle
> > 
> > For block2mtd, you don't need several device files in /dev, you
> > only need one to pass ioctls down to create mtd devices.
> > 
> > That may end up creating new /dev devices via mtdblock or
> > mtdblock_ro for instance.
> > 
> > So I'm not sure reusing the "loop" ioctls is a good idea.
> 
> /me notes that you dislike both existing interfaces and would prefer a
> third.  How likely is it that you will still like the new interface two
> years down the road?  How likely is it that everyone else will agree
> with you?
> 
> In the end, a painful interface is still less painful than a choice of
> several incompatible ones.  I used to think different and have burned my
> fingers often enough to learn the lesson. :)
[...]

Hi J?rn,

sorry, I wasn't very clear.

With "loop", you're doing an ioctl() to /dev/loop<x> so that
/dev/loop<x> become a block device associated with a given file.

Applying that strictly to block2mtd wouldn't make sense.

At the moment, when you create a new block2mtd, the only thing
you see is an entry in /proc/mtd.

You don't access that mtd device directly (there's no
/dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x>
if you have "block2mtd" for instance.

Here, what you need, is an API that gets a block device (with fd
or path) and an erase size and that returns a mtd identifier.

Best regards,
Stephane


From joern at logfs.org  Wed Feb 20 12:22:50 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Wed, 20 Feb 2008 18:22:50 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080220170231.GV4539@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
	<chaz20080220144339.GK4539@artesyncp.com>
	<20080220163042.GC5539@lazybastard.org>
	<chaz20080220170231.GV4539@artesyncp.com>
Message-ID: <20080220172250.GA6873@lazybastard.org>

On Wed, 20 February 2008 17:02:31 +0000, Stephane Chazelas wrote:
> 
> sorry, I wasn't very clear.
> 
> With "loop", you're doing an ioctl() to /dev/loop<x> so that
> /dev/loop<x> become a block device associated with a given file.
> 
> Applying that strictly to block2mtd wouldn't make sense.
> 
> At the moment, when you create a new block2mtd, the only thing
> you see is an entry in /proc/mtd.
> 
> You don't access that mtd device directly (there's no
> /dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x>
> if you have "block2mtd" for instance.

Actually, there is /dev/mtd<x>.  Enable CONFIG_MTD_CHAR.

> Here, what you need, is an API that gets a block device (with fd
> or path) and an erase size and that returns a mtd identifier.

Erase size is a real difference, agreed.  Otherwise the loop analogy is
quite good.  Occasionally people are asking for file->mtd translation as
well.

J?rn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918


From stephane.chazelas at emerson.com  Wed Feb 20 12:30:53 2008
From: stephane.chazelas at emerson.com (Stephane Chazelas)
Date: Wed, 20 Feb 2008 17:30:53 +0000
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <20080220172250.GA6873@lazybastard.org>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
	<chaz20080220144339.GK4539@artesyncp.com>
	<20080220163042.GC5539@lazybastard.org>
	<chaz20080220170231.GV4539@artesyncp.com>
	<20080220172250.GA6873@lazybastard.org>
Message-ID: <chaz20080220173053.GX4539@artesyncp.com>

2008-02-20 18:22:50 +0100, J?rn Engel:
> On Wed, 20 February 2008 17:02:31 +0000, Stephane Chazelas wrote:
> > 
> > sorry, I wasn't very clear.
> > 
> > With "loop", you're doing an ioctl() to /dev/loop<x> so that
> > /dev/loop<x> become a block device associated with a given file.
> > 
> > Applying that strictly to block2mtd wouldn't make sense.
> > 
> > At the moment, when you create a new block2mtd, the only thing
> > you see is an entry in /proc/mtd.
> > 
> > You don't access that mtd device directly (there's no
> > /dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x>
> > if you have "block2mtd" for instance.
> 
> Actually, there is /dev/mtd<x>.  Enable CONFIG_MTD_CHAR.

Yes, my point ;). "block2mtd" creates a "mtd" out of a block
device and "mtdchar" and "mtdblock" create the "char" and
"block" devices out of the "mtd". This is a different concept
from "loop". With "loop", you make a block device out of a file,
but you do the ioctl on the target loop block device itself.
With block2mtd, you can't do that.

> > Here, what you need, is an API that gets a block device (with fd
> > or path) and an erase size and that returns a mtd identifier.
> 
> Erase size is a real difference, agreed.  Otherwise the loop analogy is
> quite good.  Occasionally people are asking for file->mtd translation as
> well.
[...]

Actually, that's what I use block2mtd for, in combination with
"loop" to mount jffs2 filesystem images (always wondered if
there wasn't a simpler way, BTW (other than mtdram))

Cheers,
Stephane


From ken8804 at gmail.com  Wed Feb 20 17:00:18 2008
From: ken8804 at gmail.com (Ken Chan)
Date: Wed, 20 Feb 2008 17:00:18 -0500
Subject: MTD - NAND (Micron MT29F16G08)
In-Reply-To: <Pine.LNX.4.64.0802201723410.3508@lnxricardw.se.axis.com>
References: <4ffb81490802200607n3d5f6ad5h12f4a53399a32466@mail.gmail.com>
	<Pine.LNX.4.64.0802201723410.3508@lnxricardw.se.axis.com>
Message-ID: <4ffb81490802201400j2ae2fd61l227345968b32281@mail.gmail.com>

> Just a guess here, does it matter that the exact oob size is not
> supported? As long as there are enough bytes for what is needed (bad block
> indicator, ECC data, and jffs2 cleanmarkers if using jffs2 filesystem) it
> might not matter what the exact size is. Most flashes support reading and
> writing less than a full page or oob.
>

I tried to use "oob_64" and format the NAND Flash to use jffs2 filesystem.
The format part went well.  It detected a few bad sectors.....
After the format finished, I tried to do "mount -t jffs2
/dev/mtdblock8 /nand" but I got
the following exception error message:

sh-2.05b# mount -t jffs2 /dev/mtdblock8 /nand

[  617.996658] Oops: kernel access of bad area, sig: 11 [#1]
[  618.019446] NIP: FFFFFFFC LR: FFFFFFFF CTR: 00000000
[  618.049179] REGS: cb615b00 TRAP: 0400   Not tainted  (2.6.16.1)
[  618.084642] MSR: 00029200 <EE,ME>  CR: 28004482  XER: 20000000

ken



On Wed, Feb 20, 2008 at 11:25 AM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
>
>
> On Wed, 20 Feb 2008, Ken Chan wrote:
>
> > Hi,
> > I am trying to get my NAND Flash (Micron MT29F16G08 -- 2 GBytes NAND) going.
> > Based on the data sheet, the page size is 4KB, the Spare area size (i.e.
> > OOB) is 218 Bytes, the Block size is 512KB.
> > I am using Linux Kernel 2.6.16 and it does not support this NAND Flash
> > because of the OOB is 218 Bytes.
> > I checked the Linux Kernel (2.6.24) and same thing applied.
> >
> > Here are my questions:
> > 1) How can I build a data structure "struct nand_oobinfo nand_oob_218"?
> > What shall I put for those eccpos[]?
> > 2) If I don't want to create that new data structure, what is the
> > alternative method to bring up that NAND Flash?
> > 3) Do anyone have similar problem using that kind of NAND Flash?
>


From linux01 at architechnical.net  Wed Feb 20 19:31:34 2008
From: linux01 at architechnical.net (Pete MacKay)
Date: Wed, 20 Feb 2008 19:31:34 -0500 (EST)
Subject: Mark OneNAND bad block good again?
Message-ID: <60098.69.30.58.166.1203553894.squirrel@architechnical.net>

Does anyone with OneNAND savvy (KP?) know if a block that's marked bad can
be restored again somehow?  We've tried overwriting the OOB and erasing
but the controller always sets the ERROR bit without changing the BB
value.  We've got some boards with corrupted OneNANDs due to low-level
programming errors overwriting the BB byte, but I maintained a list of
factory-marked bad blocks for these units before they went out (having
made this mistake previously myself ;).

I know we've got a mix of rev M, A, and B chips, and I swear I remember
being able to do this on a prototype unit when the OneNAND first came out,
but maybe I'm just senile.

Thanks!
Pete



From kmpark at infradead.org  Wed Feb 20 19:51:04 2008
From: kmpark at infradead.org (Kyungmin Park)
Date: Thu, 21 Feb 2008 09:51:04 +0900
Subject: Mark OneNAND bad block good again?
In-Reply-To: <60098.69.30.58.166.1203553894.squirrel@architechnical.net>
References: <60098.69.30.58.166.1203553894.squirrel@architechnical.net>
Message-ID: <003001c87423$d99f9210$1fa9580a@swcenter.sec.samsung.co.kr>

Hi,

As I know, there's no tool to mark some block bad or vice versa.

It uses only development time.
Yes, it's not normal way. You SHOULD do this your own risk.

If you know the initial bad blocks, runtime bad blocks, erase all with skipping BBT. Or
Erase wanted block only.

Modify onenand_erase().

#if 0
		/* Check if we have a bad block, we do not erase bad blocks */
                if (onenand_block_isbad_nolock(mtd, addr, 0)) {
                        printk (KERN_WARNING "onenand_erase: attempt to erase a bad block at addr 0x%08x\n", (unsigned int) addr);
                        instr->state = MTD_ERASE_FAILED;
                        goto erase_exit;
                }
#endif

And call onenand_erase() after onenand_probe() at your module.
e.g., If you want to erase n block
struct erase_info instr = {
	.addr = n << mtd->erasesize,
	.len = mtd->erasesize,
};
onenand_erase(mtd, &instr);

Thank you,
Kyungmin Park

> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On
> Behalf Of Pete MacKay
> Sent: Thursday, February 21, 2008 9:32 AM
> To: linux-mtd at lists.infradead.org
> Subject: Mark OneNAND bad block good again?
> 
> Does anyone with OneNAND savvy (KP?) know if a block that's marked bad can
> be restored again somehow?  We've tried overwriting the OOB and erasing
> but the controller always sets the ERROR bit without changing the BB
> value.  We've got some boards with corrupted OneNANDs due to low-level
> programming errors overwriting the BB byte, but I maintained a list of
> factory-marked bad blocks for these units before they went out (having
> made this mistake previously myself ;).
> 
> I know we've got a mix of rev M, A, and B chips, and I swear I remember
> being able to do this on a prototype unit when the OneNAND first came out,
> but maybe I'm just senile.
> 
> Thanks!
> Pete
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



From nancydreaming at gmail.com  Thu Feb 21 00:25:34 2008
From: nancydreaming at gmail.com (Nancy)
Date: Thu, 21 Feb 2008 13:25:34 +0800
Subject: ubifs: can't mount ubifs as rootfs
In-Reply-To: <1203520227.3758.40.camel@sauron>
References: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>
	<1203520227.3758.40.camel@sauron>
Message-ID: <bae050c10802202125j64891cc5xac1694e8a5b9915@mail.gmail.com>

On 2/20/08, Artem Bityutskiy <dedekind at infradead.org> wrote:
> Hi,
>
> On Wed, 2008-02-20 at 23:00 +0800, Nancy wrote:
> > Dear all,
> >         As you can see at last, ubifs can't mount ubifs as rootfs,
> > why? How can I make it right?
> >         same kernel image, just different kernel command line.
>
> I think you do not have this patch:
>
> http://git.infradead.org/?p=users/dedekind/ubifs-v2.6.22.git;a=commitdiff;h=9c04728f3cb585f1e0b3df4f0ae2aec1bf73e392;hp=aad43553d81d1b79f64cde3c81b71bfc3036d098
>
> You probably use old UBIFS. Keep in mind, it is constantly developed so
> you should always try the latest one if you have problems.
>
> There are 2.6.22, 2.6.23, and 2.6.24 ubifs backports BTW,
> see http://www.linux-mtd.infradead.org/doc/ubifs.html#L_source
>
> AFAIR you use 2.6.22, so here it is:
>
> git://git.infradead.org/~dedekind/ubifs-v2.6.22.git
>
> Just download it - it has all the need patches. But I encourage you to
> use the lates development tree.
>
> --
> Best regards,
> Artem Bityutskiy (???????? ?????)
>

    Thank you very much sir !!!
    I will encourage my project manager to use the latest development tree  :- )
    You are someone I admire the most, not only the elegant code,
normative code comments and design documents ( that's rare in
opensource), but also .....oh, how to say in english ( my poor
english! )
    I will improve my english skill.
    How to become a programmer like you? Could you give me some suggestion?

--
Best wishes,
Nancy

From dhlii at dlasys.net  Thu Feb 21 02:05:52 2008
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Thu, 21 Feb 2008 02:05:52 -0500
Subject: Block devices
Message-ID: <47BD22D0.9060008@dlasys.net>

    Sometime recently it seems to have become possible to disable the
whole block device subsystem.
    Though in my tests I can't quit build with it disabled.

     Anyway, for an embedded device this might be appealing.
    how does this interact with initramfs and flash ?
   
    Can I boot an initramfs kernel without a block device ?
    Can I write a filesystem driver for a flash device that does not
require a block device ?
    Are their any examples of something even close ?

   

      







-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein



From dedekind at infradead.org  Thu Feb 21 02:20:59 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Thu, 21 Feb 2008 09:20:59 +0200
Subject: ubifs: can't mount ubifs as rootfs
In-Reply-To: <bae050c10802202125j64891cc5xac1694e8a5b9915@mail.gmail.com>
References: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>
	<1203520227.3758.40.camel@sauron>
	<bae050c10802202125j64891cc5xac1694e8a5b9915@mail.gmail.com>
Message-ID: <1203578459.3758.48.camel@sauron>

On Thu, 2008-02-21 at 13:25 +0800, Nancy wrote:
>     I will encourage my project manager to use the latest development tree  :- )

And also keep in mind, the UBIFS on-flash format is not yet completely
settled and might change. For example, adding extended attributes will
change it.

>     You are someone I admire the most, not only the elegant code,
> normative code comments and design documents ( that's rare in
> opensource), but also .....oh, how to say in english ( my poor
> english! )

Err, thanks :-)

>     How to become a programmer like you? Could you give me some suggestion?

That's not a big deal :-) Anyway, its better to stay in technical area
when writing to the mailing lists.

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From indraneel.m at samsung.com  Thu Feb 21 04:40:09 2008
From: indraneel.m at samsung.com (Indraneel)
Date: Thu, 21 Feb 2008 15:10:09 +0530
Subject: Block devices
In-Reply-To: <47BD22D0.9060008@dlasys.net>
References: <47BD22D0.9060008@dlasys.net>
Message-ID: <47BD46F9.9000708@samsung.com>

David,
First things first. Don't post to multiple mailing lists at the same time.

David H. Lynch Jr. wrote:
>     Sometime recently it seems to have become possible to disable the
> whole block device subsystem.

Yes it is possible. Works for me on 2.6.22-rc5.

>     Though in my tests I can't quit build with it disabled.
> 
>      Anyway, for an embedded device this might be appealing.
>     how does this interact with initramfs and flash ?
>    
>     Can I boot an initramfs kernel without a block device ?

Yes this is also possible. And that's why initramfs is fast.

>     Can I write a filesystem driver for a flash device that does not
> require a block device ?

AFAIK, for a flash file system you need a Block Device. But you can 
write a character driver to access the flash without a Block Device.

>     Are their any examples of something even close ?

  drivers/mtd/mtdchar.c

Regards,
Indro

> 
>    
> 
>       
> 
> 
> 
> 
> 
> 
> 



From trimarchi at gandalf.sssup.it  Thu Feb 21 05:10:38 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 21 Feb 2008 11:10:38 +0100
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <20080219163821.gmq5orqmcksgo8wg@feanor.sssup.it>
References: <109598.62836.qm@web50805.mail.re2.yahoo.com>
	<20080219163821.gmq5orqmcksgo8wg@feanor.sssup.it>
Message-ID: <47BD4E1E.9090102@gandalf.sssup.it>

Hi
>> I am totally lost and cannot figure out the reason for
>> the errors. I'd appericiate if anybody help to find
>> out the reason.
>>
>> Following is the ouput LOG.
>> ----------------------------
>>     
> Clean all the dataflash before, or padding the size with 0xff
> If using an u-boot system add the command for erasing dataflash.
>
> Regards Michael
>
>   
Do you have some news?

Regards Michael



From jamie at shareable.org  Thu Feb 21 03:45:08 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Thu, 21 Feb 2008 08:45:08 +0000
Subject: Block devices
In-Reply-To: <47BD46F9.9000708@samsung.com>
References: <47BD22D0.9060008@dlasys.net> <47BD46F9.9000708@samsung.com>
Message-ID: <20080221084508.GB20156@shareable.org>

Indraneel wrote:
> >     Can I write a filesystem driver for a flash device that does not
> > require a block device ?
> 
> AFAIK, for a flash file system you need a Block Device. But you can 
> write a character driver to access the flash without a Block Device.

I think JFFS2 (flash file system) does not require a block device.  If
you mount /dev/mtdblockN with JFFS2, it actually looks up the
corresponding MTD character device and uses that instead.  The same is
probably true of the other dedicated flash filesystems.

-- Jamie


From joern at logfs.org  Thu Feb 21 06:11:48 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Thu, 21 Feb 2008 12:11:48 +0100
Subject: [PATCH] [JFFS2] Fix free space leaking
In-Reply-To: <1202293219.25864.45.camel@gentoo-jocke.transmode.se>
References: <20071113102323.GA5933@damir.rnd.local>
	<1202293219.25864.45.camel@gentoo-jocke.transmode.se>
Message-ID: <20080221111148.GA10791@lazybastard.org>

On Wed, 6 February 2008 11:20:19 +0100, Joakim Tjernlund wrote:
> On Tue, 2007-11-13 at 13:23 +0300, Damir Shayhutdinov wrote:
> > This patch is addressed to fix very-long-standing problem in JFFS2,
> > first described in 2004:
> > http://lists.infradead.org/pipermail/linux-mtd/2004-March/009456.html
> > 
> > jffs2_link_node_ref() decreases c->free_size by
> > c->cleanmarker_size but the clean marker space can't
> > be accounted as free space! So we just compensate
> > the difference.
> > 
> > Signed-off-by: Alexander Yurchenko <grange at tecon.ru>
> > Signed-off-by: Damir Shayhutdinov <damir at tecon.ru>
> > ---
> >  fs/jffs2/erase.c |   11 +++++++++++
> >  1 files changed, 11 insertions(+), 0 deletions(-)
> > 
> > diff --git a/fs/jffs2/erase.c b/fs/jffs2/erase.c
> > index a1db918..c574fa3 100644
> > --- a/fs/jffs2/erase.c
> > +++ b/fs/jffs2/erase.c
> > @@ -454,6 +454,17 @@ static void jffs2_mark_erased_block(struct jffs2_sb_info *c, struct jffs2_eraseb
> >  		jeb->free_size = c->sector_size;
> >  		/* FIXME Special case for cleanmarker in empty block */
> >  		jffs2_link_node_ref(c, jeb, jeb->offset | REF_NORMAL, c->cleanmarker_size, NULL);
> > +		/*
> > +		 * XXX: I'm not sure this is correct but it prevents
> > +		 * c->free_size from slow leaking under a frequent file
> > +		 * overwriting.
> > +		 * jffs2_link_node_ref() decreases c->free_size by
> > +		 * c->cleanmarker_size but the clean marker space can't
> > +		 * be accounted as free space! So we just compensate
> > +		 * the difference.
> > +		 */
> > +		c->free_size += c->cleanmarker_size;
> > +		c->used_size -= c->cleanmarker_size;
> >  	}
> >  
> >  	down(&c->erase_free_sem);
> 
> What happened to this patch? Just forgotten or was it rejected?

No idea, but it might help to add dwmw2 to Cc:.

J?rn

-- 
Joern's library part 4:
http://www.paulgraham.com/spam.html


From dwmw2 at infradead.org  Thu Feb 21 06:39:29 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 21 Feb 2008 20:39:29 +0900
Subject: [PATCH] [JFFS2] Fix free space leaking
In-Reply-To: <20080221111148.GA10791@lazybastard.org>
References: <20071113102323.GA5933@damir.rnd.local>
	<1202293219.25864.45.camel@gentoo-jocke.transmode.se>
	<20080221111148.GA10791@lazybastard.org>
Message-ID: <1203593969.15409.45.camel@shinybook.infradead.org>


On Thu, 2008-02-21 at 12:11 +0100, J?rn Engel wrote:
> No idea, but it might help to add dwmw2 to Cc:.

dwmw2 moderately confused by it. I don't see why it's correct to account
for the space as 'free' when it isn't really. If it's causing a
persistent leak, shouldn't we deal with that when the block is erased
instead?

-- 
dwmw2



From nancydreaming at gmail.com  Thu Feb 21 09:36:37 2008
From: nancydreaming at gmail.com (Nancy)
Date: Thu, 21 Feb 2008 22:36:37 +0800
Subject: ubifs: can't mount ubifs as rootfs
In-Reply-To: <1203578459.3758.48.camel@sauron>
References: <bae050c10802200700v238b98c4t4eec9a4232395a2b@mail.gmail.com>
	<1203520227.3758.40.camel@sauron>
	<bae050c10802202125j64891cc5xac1694e8a5b9915@mail.gmail.com>
	<1203578459.3758.48.camel@sauron>
Message-ID: <bae050c10802210636o7f353639h5974882fbf8d5976@mail.gmail.com>

> And also keep in mind, the UBIFS on-flash format is not yet completely
> settled and might change. For example, adding extended attributes will
> change it.

> >     How to become a programmer like you? Could you give me some suggestion?
>
> That's not a big deal :-) Anyway, its better to stay in technical area
> when writing to the mailing lists.

   Ok, I will.  Thanks!  *^_^*

--
Best wishes,
Nancy


From hhgxyfld at 163.com  Thu Feb 21 01:03:08 2008
From: hhgxyfld at 163.com (hhgxyfld)
Date: Thu, 21 Feb 2008 14:03:08 +0800 (CST)
Subject: Some questions about PXA271
Message-ID: <20596824.271791203573788165.JavaMail.coremail@bj163app105.163.com>

 
 
 Hi Simon
 I have some problems when I debugged PXA271, I am trying to seek the an solution, I get to know you have some questions about PXA271 long time ago. So you must know this chip very much, I hope you can give me some help when you can, I am Chinese so my English is not good enough, forgive me.
 
 I want to know whether you have the BSP about PXA271 ,if you have, maybe you can send one to me , I will appreciate you very much.
 
 what's more,I want to make friends with you if you will.
 
  Looking forward to hear from you when you can.
 
  Best wishes From 
    
  Leon
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/linux-mtd/attachments/20080221/9204213a/attachment.html 

From m_edake at yahoo.com  Thu Feb 21 11:01:06 2008
From: m_edake at yahoo.com (Mangesh Edake)
Date: Thu, 21 Feb 2008 08:01:06 -0800 (PST)
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <47BD4E1E.9090102@gandalf.sssup.it>
Message-ID: <389154.92868.qm@web50802.mail.re2.yahoo.com>

Hi Michel,

Many thanks for your reply. 

I tried with removing -s 0x210 option, so command now
looks like,
mkfs.jffs2 -p -l -e 0x2100 -n -d /home/me/rootdir -o
jffs2.img

At the same time I added erase command in the u-boot
as suggested by you. But unfortunately the result is
same...

However I found that dataflash driver in u-boot
doesnot deal with extra 16-bytes (oob) and doesnot
write any JFFS2 specific magic bitmask, node crc,
cleanmarker etc. info to the oob. But the nand flash
(legacy) driver does the same in u-boot. Also
kernel-mtd driver for at45 dataflash is missing with
read_oob, write_oob functions whereas mtd-nand uses
those routines. So my concern is, while copying the
jffs2 image to dataflash is it necessory to write
jffs2 specific info in oob region..? My assumption is,
this info should be present in image itself and
mkfs.jffs2 must take care of this while creating an
image. (Please corret me if I'm wrong...)
I've also seen code of nandwrite (mtd utility) where
it uses -j option that takes care of jffs2_oobinfo.

So I've two problems-
i) the way I download an image (cp from u-boot method)
is wrong ? or
ii) am I creating a wrong image..? 
Please reply...

P.S. Attached here is the jffs2 image dump created as,
jffs2dump -l -c jffs2.img > dump.txt

--
Thanks and Regards,
Mangesh Edake.

 


--- michael <trimarchi at gandalf.sssup.it> wrote:

> Hi
> >> I am totally lost and cannot figure out the
> reason for
> >> the errors. I'd appericiate if anybody help to
> find
> >> out the reason.
> >>
> >> Following is the ouput LOG.
> >> ----------------------------
> >>     
> > Clean all the dataflash before, or padding the
> size with 0xff
> > If using an u-boot system add the command for
> erasing dataflash.
> >
> > Regards Michael
> >
> >   
> Do you have some news?
> 
> Regards Michael
> 
> 


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump.txt
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20080221/6c76843f/attachment-0001.txt 

From hch at infradead.org  Thu Feb 21 11:48:36 2008
From: hch at infradead.org (Christoph Hellwig)
Date: Thu, 21 Feb 2008 11:48:36 -0500
Subject: Block devices
In-Reply-To: <47BD22D0.9060008@dlasys.net>
References: <47BD22D0.9060008@dlasys.net>
Message-ID: <20080221164836.GA4209@infradead.org>

On Thu, Feb 21, 2008 at 02:05:52AM -0500, David H. Lynch Jr. wrote:
>     Can I boot an initramfs kernel without a block device ?

Yes.

>     Can I write a filesystem driver for a flash device that does not
> require a block device ?

Yes.

>     Are their any examples of something even close ?

For that particular flash case there's just jffs2 in the kernel tree,
with some more flash filesystems under development.  You can of
course have network and in-memory filesystems aswell.



From ivan.djelic at parrot.com  Thu Feb 21 12:58:49 2008
From: ivan.djelic at parrot.com (Ivan Djelic)
Date: Thu, 21 Feb 2008 17:58:49 +0000 (UTC)
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
Message-ID: <loom.20080221T171743-57@post.gmane.org>

Hello All,

While working on a NAND flash MTD driver, I came across the following piece of
code in the Blackfin bf5xx NAND flash controller driver:

>From linux-2.6.24.2, file bf5xx_nand.c:418, function bf5xx_nand_dma_rw():

	/*
	 * Before starting a dma transfer, be sure to invalidate/flush
	 * the cache over the address range of your DMA buffer to
	 * prevent cache coherency problems. Otherwise very subtle bugs
	 * can be introduced to your driver.
	 */
	if (is_read)
		invalidate_dcache_range((unsigned int)buf,
				(unsigned int)(buf + page_size));
	else
		flush_dcache_range((unsigned int)buf,
				(unsigned int)(buf + page_size));

Since 'buf' is allocated outside MTD, are we allowed to assume it is
cache-aligned ? Because if it's not, invalidating dcache on read is not enough
to prevent cache coherency problems. For instance, a cache line partially
spanning across the buffer address range could be flushed just after DMA has
completed, corrupting DMA data in the process...
Or am I missing something, since I am not familiar with the Blackfin arch ?

Thanks,

Ivan




From trimarchi at gandalf.sssup.it  Thu Feb 21 13:50:23 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 21 Feb 2008 19:50:23 +0100
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <389154.92868.qm@web50802.mail.re2.yahoo.com>
References: <389154.92868.qm@web50802.mail.re2.yahoo.com>
Message-ID: <47BDC7EF.5060603@gandalf.sssup.it>

Mangesh Edake wrote:
Hi
> Hi Michel,
>
> Many thanks for your reply. 
>
> I tried with removing -s 0x210 option, so command now
> looks like,
> mkfs.jffs2 -p -l -e 0x2100 -n -d /home/me/rootdir -o
> jffs2.img
>
> At the same time I added erase command in the u-boot
> as suggested by you. But unfortunately the result is
> same...
>
> However I found that dataflash driver in u-boot
> doesnot deal with extra 16-bytes (oob) and doesnot
> write any JFFS2 specific magic bitmask, node crc,
> cleanmarker etc. info to the oob. But the nand flash
> (legacy) driver does the same in u-boot. Also
> kernel-mtd driver for at45 dataflash is missing with
> read_oob, write_oob functions whereas mtd-nand uses
> those routines. So my concern is, while copying the
> jffs2 image to dataflash is it necessory to write
> jffs2 specific info in oob region..? My assumption is,
> this info should be present in image itself and
> mkfs.jffs2 must take care of this while creating an
> image. (Please corret me if I'm wrong...)
> I've also seen code of nandwrite (mtd utility) where
> it uses -j option that takes care of jffs2_oobinfo.
>   
No,
using in linux flash_eraseall to clean your partition. Maybe start from 
a ramdisk.
It is the only partinion? If no, you must remember to align it at a 
block size.
Example my partionin start from 0x131400

setenv bootargs console=ttyS0,115200 mem=8M rootfstype=jffs2 
root=/dev/mtdblock1
rw mtdparts=spi0.1-AT45DB321x:1221k(ARMboot)ro,- at 1221k(root)

For the creation use:
mkfs.jffs2 -d romfs -l -p -e 0x2100 -v -n -o images/ramdisk.img > log.txt

Let me know!!

Regards Michael






From gordonfarquharson at gmail.com  Thu Feb 21 16:06:44 2008
From: gordonfarquharson at gmail.com (Gordon Farquharson)
Date: Thu, 21 Feb 2008 14:06:44 -0700
Subject: [PATCH] [MTD] [NOR] Add support for the ST M29W400DB flash chip.
In-Reply-To: <97a0a9ac0802181034w6f31ac3dj36b18ea409b8f988@mail.gmail.com>
References: <97a0a9ac0801082035r2dacab1cu40a6bfc4e7fedb1a@mail.gmail.com>
	<97a0a9ac0802181034w6f31ac3dj36b18ea409b8f988@mail.gmail.com>
Message-ID: <97a0a9ac0802211306t2732c4d5h9f529f2a9a2a3bc2@mail.gmail.com>

Hi

Did anybody get the email below? Please let me know if I am sending it
to the wrong group because I have not received any response.

Thanks.

Gordon

On Mon, Feb 18, 2008 at 11:34 AM, Gordon Farquharson
<gordonfarquharson at gmail.com> wrote:
> I submitted this patch to the list at the beginning of January in the
>  hope that it would be included in 2.6.25. I know that the merge window
>  for 2.6.25 is closed, but is it still possible to get this into
>  2.6.25? It is not a significant change. This chip is used in the GLAN
>  Tank NAS.
>
>  Thanks.
>
>  Gordon
>
>
>
>  On Jan 8, 2008 9:35 PM, Gordon Farquharson <gordonfarquharson at gmail.com> wrote:
>  > Add support for the ST M29W400DB flash chip.
>  >
>  > Signed-off-by: Gordon Farquharson <gordonfarquharson at gmail.com>
>  >
>  > ---
>  >
>  > diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
>  > index 6405938..0b4f481 100644
>  > --- a/drivers/mtd/chips/jedec_probe.c
>  > +++ b/drivers/mtd/chips/jedec_probe.c
>  > @@ -135,6 +135,7 @@
>  >  #define M29W160DT      0x22C4
>  >  #define M29W160DB      0x2249
>  >  #define M29W040B       0x00E3
>  > +#define M29W400DB      0x00EF
>  >  #define M50FW040       0x002C
>  >  #define M50FW080       0x002D
>  >  #define M50FW016       0x002E
>  > @@ -1498,7 +1499,22 @@ static const struct amd_flash_info jedec_table[] = {
>  >                 .regions        = {
>  >                         ERASEINFO(0x10000,8),
>  >                 }
>  > -        }, {
>  > +       }, {
>  > +               .mfr_id         = MANUFACTURER_ST,
>  > +               .dev_id         = M29W400DB,
>  > +               .name           = "ST M29W400DB",
>  > +               .devtypes       = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
>  > +               .uaddr          = MTD_UADDR_0x0555_0x02AA,
>  > +               .dev_size       = SIZE_512KiB,
>  > +               .cmd_set        = P_ID_AMD_STD,
>  > +               .nr_regions     = 4,
>  > +               .regions        = {
>  > +                       ERASEINFO(0x04000,1),
>  > +                       ERASEINFO(0x02000,2),
>  > +                       ERASEINFO(0x08000,1),
>  > +                       ERASEINFO(0x10000,7)
>  > +               }
>  > +       }, {
>  >                 .mfr_id         = MANUFACTURER_ST,
>  >                 .dev_id         = M50FW040,
>  >                 .name           = "ST M50FW040",
>  >
>
>  --
>  Gordon Farquharson
>  GnuPG Key ID: 32D6D676
>



-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676


From cooloney at kernel.org  Thu Feb 21 21:52:49 2008
From: cooloney at kernel.org (Bryan Wu)
Date: Fri, 22 Feb 2008 10:52:49 +0800
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <loom.20080221T171743-57@post.gmane.org>
References: <loom.20080221T171743-57@post.gmane.org>
Message-ID: <386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>

On Fri, Feb 22, 2008 at 1:58 AM, Ivan Djelic <ivan.djelic at parrot.com> wrote:
> Hello All,
>
>  While working on a NAND flash MTD driver, I came across the following piece of
>  code in the Blackfin bf5xx NAND flash controller driver:
>

Thanks, I am always here to answer questions, -;)

>  >From linux-2.6.24.2, file bf5xx_nand.c:418, function bf5xx_nand_dma_rw():
>
>         /*
>          * Before starting a dma transfer, be sure to invalidate/flush
>          * the cache over the address range of your DMA buffer to
>          * prevent cache coherency problems. Otherwise very subtle bugs
>          * can be introduced to your driver.
>          */
>         if (is_read)
>                 invalidate_dcache_range((unsigned int)buf,
>                                 (unsigned int)(buf + page_size));
>         else
>                 flush_dcache_range((unsigned int)buf,
>                                 (unsigned int)(buf + page_size));
>
>  Since 'buf' is allocated outside MTD, are we allowed to assume it is
>  cache-aligned ? Because if it's not, invalidating dcache on read is not enough
>  to prevent cache coherency problems. For instance, a cache line partially
>  spanning across the buffer address range could be flushed just after DMA has
>  completed, corrupting DMA data in the process...

Oh, I am not fully understand your concern.  The code is invalidating
or flushing buf before DMA operation.
And invalidate and flush operation is OK for buf which is not
cache-aligned on Blackfin arch. it also should be
OK for other arch.

-Bryan


From dwmw2 at infradead.org  Fri Feb 22 02:05:08 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 22 Feb 2008 16:05:08 +0900
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
References: <loom.20080221T171743-57@post.gmane.org>
	<386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
Message-ID: <1203663909.5771.26.camel@shinybook.infradead.org>


On Fri, 2008-02-22 at 10:52 +0800, Bryan Wu wrote:
> Oh, I am not fully understand your concern.  The code is invalidating
> or flushing buf before DMA operation.
> And invalidate and flush operation is OK for buf which is not
> cache-aligned on Blackfin arch. it also should be
> OK for other arch.

The problem occurs when your buffer is not aligned at the beginning of a
cache line. If there is other data on the _same_ cache line as your
buffer, and you invalidate the cache, then you may cause data loss
outside the buffer.

Also, in some systems you must make sure that allocations to be used for
DMA are from a certain memory pool.

As for the original question... I'm not sure. At the moment I don't
believe it's true that all such buffers are suitable for DMA. Perhaps it
would be sensible for us to redefine the MTD API so that it is required
(and fix the users).

For a long time, flash I/O was always done by the CPU instead of DMA, so
it wasn't an interesting question. I did start wondering when I
implemented support for the CAF? controller on OLPC, but then that
turned out to need bounce buffers anyway so it escaped my attention
again.

-- 
dwmw2



From ivan.djelic at parrot.com  Fri Feb 22 03:45:33 2008
From: ivan.djelic at parrot.com (Ivan Djelic)
Date: Fri, 22 Feb 2008 09:45:33 +0100
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
References: <loom.20080221T171743-57@post.gmane.org>
	<386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
Message-ID: <20080222084533.GA2543@parrot.com>

On Fri, Feb 22, 2008 at 10:52:49AM +0800, Bryan Wu wrote:
> >         /*
> >          * Before starting a dma transfer, be sure to invalidate/flush
> >          * the cache over the address range of your DMA buffer to
> >          * prevent cache coherency problems. Otherwise very subtle bugs
> >          * can be introduced to your driver.
> >          */
> >         if (is_read)
> >                 invalidate_dcache_range((unsigned int)buf,
> >                                 (unsigned int)(buf + page_size));
> >         else
> >                 flush_dcache_range((unsigned int)buf,
> >                                 (unsigned int)(buf + page_size));
> >
> >  Since 'buf' is allocated outside MTD, are we allowed to assume it is
> >  cache-aligned ? Because if it's not, invalidating dcache on read is not enough
> >  to prevent cache coherency problems. For instance, a cache line partially
> >  spanning across the buffer address range could be flushed just after DMA has
> >  completed, corrupting DMA data in the process...
> 
> Oh, I am not fully understand your concern.  The code is invalidating
> or flushing buf before DMA operation.
> And invalidate and flush operation is OK for buf which is not
> cache-aligned on Blackfin arch. it also should be
> OK for other arch.

Well, consider the following scenario, in which 'buf' is not cache-aligned:

1) function bf5xx_nand_dma_rw() is called for reading data.

2) dcache is partially invalidated on a range containing 'buf': this range is
cache-aligned, of course.

3) at this point, imagine some variable residing nearby 'buf' (in the same
cache line interval) is read and modified, resulting in a cache line being
fetched and modified (hence becoming dirty).

4) DMA transfer happens, modifying data in memory.

5) now, the dirty cache line from 3) can be flushed to memory anytime...
corrupting DMA data, because its contents were read *before* the DMA transfer !

Or consider this other scenario:

1) and 2) same as above.

3) some variable residing nearby 'buf' (in the same cache line interval) is
read (not modified), resulting in a cache line being fetched. Cache line is not
dirty.

4) DMA transfer happens.

5) now, if you read data from 'buf', you will get wrong (stale) data because the
cache line contents were read *before* the DMA transfer.


To avoid those kind of problems you would need a reliable way to prevent the
cache from messing with your buffer during the whole DMA transfer.

Ivan


From haver at vnet.ibm.com  Fri Feb 22 03:47:35 2008
From: haver at vnet.ibm.com (Frank Haverkamp)
Date: Fri, 22 Feb 2008 09:47:35 +0100
Subject: [PATCH] ubi-utils: Fixup pddcustomize
Message-ID: <1203670055.8489.4.camel@august>

Subject: ubi-utils: pddcustomize fixup update volume
From: Frank Haverkamp <haver at vnet.ibm.com>

Somehow calling ubi_update_start was forgotten and caused the
tool not to write but silently ignore the write.

Signed-off-by: Frank Haverkamp <haver at vnet.ibm.com>
---
 ubi-utils/src/bootenv.c      |    2 +-
 ubi-utils/src/pddcustomize.c |   16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

--- mtd-utils.git.orig/ubi-utils/src/bootenv.c
+++ mtd-utils.git/ubi-utils/src/bootenv.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) International Business Machines Corp., 2006
+ * Copyright (c) International Business Machines Corp., 2008
  *
  * 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
--- mtd-utils.git.orig/ubi-utils/src/pddcustomize.c
+++ mtd-utils.git/ubi-utils/src/pddcustomize.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) International Business Machines Corp., 2006
+ * Copyright (c) International Business Machines Corp., 2008
  *
  * 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
@@ -46,7 +46,7 @@
 #include "libubi.h"
 #include "ubimirror.h"
 
-#define PROGRAM_VERSION "1.5"
+#define PROGRAM_VERSION "1.6"
 
 #define DEFAULT_DEV_PATTERN    "/dev/ubi%d"
 #define DEFAULT_VOL_PATTERN    "/dev/ubi%d_%d"
@@ -369,7 +369,7 @@ ubi_write_bootenv(uint32_t devno, uint32
 	int rc = 0;
 	char path[PATH_MAX];
 	FILE* fp_out = NULL;
-	size_t nbytes ;
+	size_t nbytes;
 
 	rc = bootenv_size(env, &nbytes);
 	if (rc) {
@@ -387,6 +387,13 @@ ubi_write_bootenv(uint32_t devno, uint32
 	fp_out = fopen(path, "r+");
 	if (fp_out == NULL) {
 		err_msg("Cannot fopen volume:%d number:%d\n", devno, id);
+		rc = -EBADF;
+		goto err;
+	}
+
+	rc = ubi_update_start(ulib, fileno(fp_out), nbytes);
+	if (rc != 0) {
+		err_msg("Cannot start update for %s\n", path);
 		goto err;
 	}
 
@@ -396,7 +403,6 @@ ubi_write_bootenv(uint32_t devno, uint32
 			devno, id);
 		goto err;
 	}
-
 err:
 	if( fp_out )
 		fclose(fp_out);
@@ -495,6 +501,8 @@ main(int argc, char **argv) {
 		rc = write_bootenv(args.file_in, env);
 	else
 		rc = ubi_write_bootenv(EXAMPLE_UBI_DEVICE, boot_volno, env);
+
+	printf("rc=%d\n", rc);
 	if (rc != 0) {
 		goto err;
 	}

-- 
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Gesch?ftsf?hrung: Herbert Kircher, Sitz der Gesellschaft: B?blingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 001-ubi-utils-fixup-pddcustomize.patch
Type: text/x-patch
Size: 2685 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080222/a58a57f9/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5269 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080222/a58a57f9/attachment-0003.bin 

From ivan.djelic at parrot.com  Fri Feb 22 03:54:03 2008
From: ivan.djelic at parrot.com (Ivan Djelic)
Date: Fri, 22 Feb 2008 09:54:03 +0100
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <20080222084533.GA2543@parrot.com>
References: <loom.20080221T171743-57@post.gmane.org>
	<386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
	<20080222084533.GA2543@parrot.com>
Message-ID: <20080222085403.GA2870@parrot.com>

On Fri, Feb 22, 2008 at 09:45:33AM +0100, Ivan Djelic wrote:
> > Oh, I am not fully understand your concern.  The code is invalidating
> > or flushing buf before DMA operation.
> > And invalidate and flush operation is OK for buf which is not
> > cache-aligned on Blackfin arch. it also should be
> > OK for other arch.
> 
> Well, consider the following scenario, in which 'buf' is not cache-aligned:
> 
> 1) function bf5xx_nand_dma_rw() is called for reading data.
> 
> 2) dcache is partially invalidated on a range containing 'buf': this range is
> cache-aligned, of course.
> 
> 3) some variable residing nearby 'buf' (in the same cache line interval) is
> read (not modified), resulting in a cache line being fetched. Cache line is not
> dirty.

Also, the variable contents in 3) may also be corrupted because of the
invalidation in 2).


From dedekind at infradead.org  Fri Feb 22 03:51:17 2008
From: dedekind at infradead.org (Artem Bityutskiy)
Date: Fri, 22 Feb 2008 10:51:17 +0200
Subject: [PATCH] ubi-utils: Fixup pddcustomize
In-Reply-To: <1203670055.8489.4.camel@august>
References: <1203670055.8489.4.camel@august>
Message-ID: <1203670277.3758.51.camel@sauron>


On Fri, 2008-02-22 at 09:47 +0100, Frank Haverkamp wrote:
> Subject: ubi-utils: pddcustomize fixup update volume
> From: Frank Haverkamp <haver at vnet.ibm.com>
> 
> Somehow calling ubi_update_start was forgotten and caused the
> tool not to write but silently ignore the write.
> 
> Signed-off-by: Frank Haverkamp <haver at vnet.ibm.com>

[dedekind at golum mtd-utils.git]$ git-am haver.eml
Applying ubi-utils: pddcustomize fixup update volume
.dotest/patch:11: trailing whitespace.
 * Copyright (c) International Business Machines Corp., 2008
.dotest/patch:20: trailing whitespace.
 * Copyright (c) International Business Machines Corp., 2008
.dotest/patch:28: trailing whitespace.
 * 1.6 Fixed broken volume update
.dotest/patch:37: trailing whitespace.
#define PROGRAM_VERSION "1.6"
.dotest/patch:46: trailing whitespace.
        size_t nbytes;
error: patch failed: ubi-utils/src/bootenv.c:1
error: ubi-utils/src/bootenv.c: patch does not apply
error: patch failed: ubi-utils/src/pddcustomize.c:1
error: ubi-utils/src/pddcustomize.c: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".

-- 
Best regards,
Artem Bityutskiy (???????? ?????)



From ricard.wanderlof at axis.com  Fri Feb 22 07:15:26 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Fri, 22 Feb 2008 13:15:26 +0100 (CET)
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <389154.92868.qm@web50802.mail.re2.yahoo.com>
References: <389154.92868.qm@web50802.mail.re2.yahoo.com>
Message-ID: <Pine.LNX.4.64.0802221308540.6032@lnxricardw.se.axis.com>


On Thu, 21 Feb 2008, Mangesh Edake wrote:

> However I found that dataflash driver in u-boot
> doesnot deal with extra 16-bytes (oob) and doesnot
> write any JFFS2 specific magic bitmask, node crc,
> cleanmarker etc. info to the oob. But the nand flash
> (legacy) driver does the same in u-boot. Also
> kernel-mtd driver for at45 dataflash is missing with
> read_oob, write_oob functions whereas mtd-nand uses
> those routines. So my concern is, while copying the
> jffs2 image to dataflash is it necessory to write
> jffs2 specific info in oob region..? My assumption is,
> this info should be present in image itself and
> mkfs.jffs2 must take care of this while creating an
> image. (Please corret me if I'm wrong...)

The only JFFS2 data present in the OOB is the cleanmarker indicator for 
blocks that are unused, i.e. where the data is =0xFF. For blocks that are 
used, all JFFS2 info is in the ordinary data area.

Since the JFFS2 driver automagically writes cleanmarkers to unused blocks 
when mounting (after erasing them first), it is not necessary to have 
(oob) cleanmarkers in the filesystem image produced by mkfs.jffs2, and 
indeed there is no option to do so IIRC.

The said, we've seen that the erase/cleamarker write during initial mount 
of a JFFS2 filesystem consumes a lot of cpu time, and this can be 
minimized by writing all the cleanmarkers before mounting. It is possible 
that nandwrite -j would do this (we don't use nandwrite to write the 
initial image in our products so I don't have any experience with this).

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


From joern at logfs.org  Sat Feb 23 10:33:21 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Sat, 23 Feb 2008 16:33:21 +0100
Subject: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
In-Reply-To: <chaz20080220173053.GX4539@artesyncp.com>
References: <chaz20080212134751.GI30304@artesyncp.com>
	<chaz20080212161034.GJ30304@artesyncp.com>
	<20080219150822.GA29587@lazybastard.org>
	<200802192333.39707.arnd@arndb.de>
	<chaz20080220144339.GK4539@artesyncp.com>
	<20080220163042.GC5539@lazybastard.org>
	<chaz20080220170231.GV4539@artesyncp.com>
	<20080220172250.GA6873@lazybastard.org>
	<chaz20080220173053.GX4539@artesyncp.com>
Message-ID: <20080223153321.GC29143@lazybastard.org>

On Wed, 20 February 2008 17:30:53 +0000, Stephane Chazelas wrote:
> > 
> > Actually, there is /dev/mtd<x>.  Enable CONFIG_MTD_CHAR.
> 
> Yes, my point ;). "block2mtd" creates a "mtd" out of a block
> device and "mtdchar" and "mtdblock" create the "char" and
> "block" devices out of the "mtd". This is a different concept
> from "loop". With "loop", you make a block device out of a file,
> but you do the ioctl on the target loop block device itself.
> With block2mtd, you can't do that.

The fact is that there is _no_ interface to manage mtd.  Part of the
reason is this tradition to have seperate modules every couple of lines
of code.  In other subsystems, CONFIG_MTD_CHAR would not exist and the
code always be compiled in.  Simply to get _some_ interface to handle
the device that is always there.

Without going much deeper into that discussion, I consider it acceptable
to depend on CONFIG_MTD_CHAR for things like device removal.  If you
want device removal and explicitly don't want the extra code from
mtdchar.c, send a patch or go find 500 bytes to save elsewhere. ;)

With that out of the way, the question remains which interface we should
have.  Independently of mimicking loop, I would like to have a generic
interface for all mtd, not just block2mtd.  Whether it is "echo 1 >
/sys/.../mtd/mtdN/remove" or an ioctl(), I don't care much about.

> Actually, that's what I use block2mtd for, in combination with
> "loop" to mount jffs2 filesystem images (always wondered if
> there wasn't a simpler way, BTW (other than mtdram))

Logfs can use a block device directly, which still leaves loop.
Enhancing block2mtd to work with files shouldn't be too hard.  If anyone
want a fun project to hack on...

J?rn

-- 
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike


From pavel at ucw.cz  Sat Feb 23 18:57:42 2008
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 24 Feb 2008 00:57:42 +0100
Subject: jffs2: -ENOSPC when truncating file?!
Message-ID: <20080223235742.GE2202@elf.ucw.cz>

Hi!

I'm trying to free space by truncating big file, and I get:

root at fic-gta01:~# ls -al gps.nmea 
-rw-r--r--    1 root     root      2332070 Feb 19 22:13 gps.nmea
root at fic-gta01:~# > gps.nmea 
-sh: cannot create gps.nmea: No space left on device
root at fic-gta01:~# rm gps.nmea
root at fic-gta01:~# > gps.nmea
root at fic-gta01:~# 

:-(

Kernel is not-so-ancient, on openmoko:

root at fic-gta01:~# uname -a
Linux fic-gta01 2.6.24 #1 PREEMPT Mon Feb 18 21:30:53 GMT 2008 armv4tl
unknown
root at fic-gta01:~# 


								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From dwmw2 at infradead.org  Sat Feb 23 19:36:07 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 24 Feb 2008 09:36:07 +0900
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <20080223235742.GE2202@elf.ucw.cz>
References: <20080223235742.GE2202@elf.ucw.cz>
Message-ID: <1203813368.5771.174.camel@shinybook.infradead.org>


On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote:
> Hi!
> 
> I'm trying to free space by truncating big file, and I get:
> 
> root at fic-gta01:~# ls -al gps.nmea 
> -rw-r--r--    1 root     root      2332070 Feb 19 22:13 gps.nmea
> root at fic-gta01:~# > gps.nmea 
> -sh: cannot create gps.nmea: No space left on device
> root at fic-gta01:~# rm gps.nmea
> root at fic-gta01:~# > gps.nmea
> root at fic-gta01:~# 

You need to write a log entry indicating the new length of the file.
There is no space for new log entries.

There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
we should add a special case for truncation too, so that it can also use
the extra pool of free space.

-- 
dwmw2



From joern at logfs.org  Sun Feb 24 01:57:52 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Sun, 24 Feb 2008 07:57:52 +0100
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <1203813368.5771.174.camel@shinybook.infradead.org>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
Message-ID: <20080224065751.GA31293@lazybastard.org>

On Sun, 24 February 2008 09:36:07 +0900, David Woodhouse wrote:
> On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote:
> > 
> > I'm trying to free space by truncating big file, and I get:
> > 
> > root at fic-gta01:~# ls -al gps.nmea 
> > -rw-r--r--    1 root     root      2332070 Feb 19 22:13 gps.nmea
> > root at fic-gta01:~# > gps.nmea 
> > -sh: cannot create gps.nmea: No space left on device
> > root at fic-gta01:~# rm gps.nmea
> > root at fic-gta01:~# > gps.nmea
> > root at fic-gta01:~# 
> 
> You need to write a log entry indicating the new length of the file.
> There is no space for new log entries.
> 
> There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
> we should add a special case for truncation too, so that it can also use
> the extra pool of free space.

Could a na?ve implementation of this get exploited by doing a large
number of truncates that just shave single bytes off various files?

Looks like the safe way to do it would be to write out a replacement
node for the truncated node, if the special case ever triggers.

J?rn

-- 
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001


From pavel at ucw.cz  Sun Feb 24 02:24:23 2008
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 24 Feb 2008 08:24:23 +0100
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <1203813368.5771.174.camel@shinybook.infradead.org>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
Message-ID: <20080224072423.GF2202@elf.ucw.cz>

On Sun 2008-02-24 09:36:07, David Woodhouse wrote:
> 
> On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote:
> > Hi!
> > 
> > I'm trying to free space by truncating big file, and I get:
> > 
> > root at fic-gta01:~# ls -al gps.nmea 
> > -rw-r--r--    1 root     root      2332070 Feb 19 22:13 gps.nmea
> > root at fic-gta01:~# > gps.nmea 
> > -sh: cannot create gps.nmea: No space left on device
> > root at fic-gta01:~# rm gps.nmea
> > root at fic-gta01:~# > gps.nmea
> > root at fic-gta01:~# 
> 
> You need to write a log entry indicating the new length of the file.
> There is no space for new log entries.
> 
> There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
> we should add a special case for truncation too, so that it can also use
> the extra pool of free space.

Yes, that would be nice. I somehow assumed that truncate can't fail
for -ENOSPC ... I was trying to actually free some space on the
filesystem...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From onyebuchijohn123 at yhoo.fr  Sun Feb 24 01:44:01 2008
From: onyebuchijohn123 at yhoo.fr (mr mike john)
Date: Sun, 24 Feb 2008 01:44:01 H0200
Subject: CONTACT HIM IMMEDIATELY
Message-ID: <20080224024935.B198F2A2776@mail.losparciales.com>

Dearest Friend, 
I am very happy to inform you that i have suceeded in transferring those funds out of my Country (Benin Republic) with the help of a new partner from paraguay,
though it did not work as planned on your side due to one reason or the other
 I appreciate greatly your understanding and concern,especially the effort you made to assist me In fulfiment of that I made an international Bank Draft cheque worth of $800,000.00 USD in your name to compensate you for your past effort and attempt to assist me,
 Now contact my secretary onyebu reuben in my country he will assist you in having the Bank Draft,You will reach him through his E-mail: address (fedexexpr_delivercompnay07 at yahoo.com) Or (phone number
+229-9387-2699)he will give you all the necessary assistance, so feel free to get in touch with him to send the Draft to you without any delay. 
  Sincerely Yours, 
  Best Regards, 
BARRISTER mr mike john




From dwmw2 at infradead.org  Sun Feb 24 05:57:32 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 24 Feb 2008 18:57:32 +0800
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <20080224065751.GA31293@lazybastard.org>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
	<20080224065751.GA31293@lazybastard.org>
Message-ID: <1203850653.13749.9.camel@shinybook.infradead.org>


On Sun, 2008-02-24 at 07:57 +0100, J?rn Engel wrote:
> Could a na?ve implementation of this get exploited by doing a large
> number of truncates that just shave single bytes off various files?

Yeah, which is why _my_ na?ve implementation would do it for
truncate-to-zero instead of just _any_ truncate (which could even be
truncate-to-larger).

A more complex version might allow _any_ transaction to eat into the
ALLOC_DELETION pool if it is ultimately going to reduce the amount of
space taken on the file system -- even overwriting 'real' data with
zeroes which compress better. That's going to be hard to calculate in
the general case though.

If allowing only truncate-to-zero isn't good enough, perhaps we could
allow truncation to use the ALLOC_DELETION pool when it's going to
obsolete at least one full data node. That's not so hard to check.

-- 
dwmw2



From joern at logfs.org  Sun Feb 24 06:08:58 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Sun, 24 Feb 2008 12:08:58 +0100
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <1203850653.13749.9.camel@shinybook.infradead.org>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
	<20080224065751.GA31293@lazybastard.org>
	<1203850653.13749.9.camel@shinybook.infradead.org>
Message-ID: <20080224110858.GC31293@lazybastard.org>

On Sun, 24 February 2008 18:57:32 +0800, David Woodhouse wrote:
> On Sun, 2008-02-24 at 07:57 +0100, J?rn Engel wrote:
> > Could a na?ve implementation of this get exploited by doing a large
> > number of truncates that just shave single bytes off various files?
> 
> Yeah, which is why _my_ na?ve implementation would do it for
> truncate-to-zero instead of just _any_ truncate (which could even be
> truncate-to-larger).

Truncate-to-larger is trivial to check.  Almost every filesystem does it
somewhere, including JFFS2. ;)

But yeah, truncate-to-zero should catch the common case.

> If allowing only truncate-to-zero isn't good enough, perhaps we could
> allow truncation to use the ALLOC_DELETION pool when it's going to
> obsolete at least one full data node. That's not so hard to check.

I would simply always write out a "full" replacement node, i.e. the
complete tail page for the file.  No need to check if an old node gets
obsoleted, we just made sure it does.  Anyway, it is your baby, so you
get to change the dirty diapers and pick your favorite pair of clean
ones.

J?rn

-- 
Joern's library part 3:
http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf


From jamie at shareable.org  Sun Feb 24 11:11:35 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Sun, 24 Feb 2008 16:11:35 +0000
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <20080224072423.GF2202@elf.ucw.cz>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
	<20080224072423.GF2202@elf.ucw.cz>
Message-ID: <20080224161135.GA4918@shareable.org>

Pavel Machek wrote:
> > You need to write a log entry indicating the new length of the file.
> > There is no space for new log entries.
> > 
> > There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
> > we should add a special case for truncation too, so that it can also use
> > the extra pool of free space.
> 
> Yes, that would be nice. I somehow assumed that truncate can't fail
> for -ENOSPC ... I was trying to actually free some space on the
> filesystem...

Same here!  When I got ENOSPC from truncate, trying to free some
space, I was so surprised (and a bit disappointed) that I assumed
removal could fail too.  So now I'm pleasantly surprised to learn I
can at least remove a file.

It does seem odd that truncate to zero length can fail.  It is
guaranteed to free up one or more data nodes, so there should be
enough space for the size change node, provided GC is invoked when
necessary and the node sizes are compatible for this in corner cases.

-- Jamie


From pavel at ucw.cz  Sun Feb 24 14:02:07 2008
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 24 Feb 2008 20:02:07 +0100
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <1203850653.13749.9.camel@shinybook.infradead.org>
References: <20080223235742.GE2202@elf.ucw.cz>
	<1203813368.5771.174.camel@shinybook.infradead.org>
	<20080224065751.GA31293@lazybastard.org>
	<1203850653.13749.9.camel@shinybook.infradead.org>
Message-ID: <20080224190207.GA18908@elf.ucw.cz>

On Sun 2008-02-24 18:57:32, David Woodhouse wrote:
> 
> On Sun, 2008-02-24 at 07:57 +0100, J?rn Engel wrote:
> > Could a na??ve implementation of this get exploited by doing a large
> > number of truncates that just shave single bytes off various files?
> 
> Yeah, which is why _my_ na??ve implementation would do it for
> truncate-to-zero instead of just _any_ truncate (which could even be
> truncate-to-larger).
> 
> A more complex version might allow _any_ transaction to eat into the
> ALLOC_DELETION pool if it is ultimately going to reduce the amount of
> space taken on the file system -- even overwriting 'real' data with
> zeroes which compress better. That's going to be hard to calculate in
> the general case though.
> 
> If allowing only truncate-to-zero isn't good enough, perhaps we could
> allow truncation to use the ALLOC_DELETION pool when it's going to
> obsolete at least one full data node. That's not so hard to check.

I believe truncate-to-zero is good enough.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From abelyako at googlemail.com  Mon Feb 25 02:48:10 2008
From: abelyako at googlemail.com (Alexander Belyakov)
Date: Mon, 25 Feb 2008 10:48:10 +0300
Subject: jffs2: -ENOSPC when truncating file?!
In-Reply-To: <20080223235742.GE2202@elf.ucw.cz>
References: <20080223235742.GE2202@elf.ucw.cz>
Message-ID: <fe810cf0802242348w625a7e7bj1a5476d6c79662@mail.gmail.com>

On Sun, Feb 24, 2008 at 2:57 AM, Pavel Machek <pavel at ucw.cz> wrote:
> Hi!
>
>  I'm trying to free space by truncating big file, and I get:
>
>  root at fic-gta01:~# ls -al gps.nmea
>  -rw-r--r--    1 root     root      2332070 Feb 19 22:13 gps.nmea
>  root at fic-gta01:~# > gps.nmea
>  -sh: cannot create gps.nmea: No space left on device
>  root at fic-gta01:~# rm gps.nmea
>  root at fic-gta01:~# > gps.nmea
>  root at fic-gta01:~#
>
>  :-(
>
>  Kernel is not-so-ancient, on openmoko:

Hi!

JFFS2 has known bug in GC leading to -ENOSPC upon file removal. Time
ago I've sent a patch with detailed explanations of what is going on.
Probably your case is the same.

Here is the patch
http://lists.infradead.org/pipermail/linux-mtd/2007-December/020091.html
(though infradead mailing list archive is missing most of messages
from this thread)

And here are some details
http://lists.infradead.org/pipermail/linux-mtd/2007-June/018756.html

Alexander


From basicmark at yahoo.com  Mon Feb 25 04:54:58 2008
From: basicmark at yahoo.com (Mark Underwood)
Date: Mon, 25 Feb 2008 09:54:58 +0000 (GMT)
Subject: NAND driver
Message-ID: <751269.90312.qm@web36904.mail.mud.yahoo.com>

I?m writing a NAND driver for an ASIC. The NAND controller has been designed to handle page read &
writes with little SW intervention using interrupts or DMA, so I plan to implement the
write_page_raw & read_page_raw functions.
However, looking through nand_base.c it looks like not all NAND access go through these functions
so to start with I have implemented the cmd_ctrl function & supplied the IO_ADDR_R & IO_ADDR_W
address with the thinking that these would be a fall back when the access doesn't go through the
raw functions.
Unfortunately it seems the single write functionality of the controller is broken. The page  read
& write functionality only allow me to work in 512byte blocks so I can't write OOB that way. Can
you confirm that there are cases where OOB is written separately and if so do you have any
suggestions for getting around this problem?

Many thanks,

Mark



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/


From cooloney at kernel.org  Mon Feb 25 05:29:34 2008
From: cooloney at kernel.org (Bryan Wu)
Date: Mon, 25 Feb 2008 18:29:34 +0800
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <1203663909.5771.26.camel@shinybook.infradead.org>
References: <loom.20080221T171743-57@post.gmane.org>
	<386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
	<1203663909.5771.26.camel@shinybook.infradead.org>
Message-ID: <386072610802250229k18b4354dpb6b9d525df0cfd27@mail.gmail.com>

On Fri, Feb 22, 2008 at 3:05 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
>  On Fri, 2008-02-22 at 10:52 +0800, Bryan Wu wrote:
>  > Oh, I am not fully understand your concern.  The code is invalidating
>  > or flushing buf before DMA operation.
>  > And invalidate and flush operation is OK for buf which is not
>  > cache-aligned on Blackfin arch. it also should be
>  > OK for other arch.
>
>  The problem occurs when your buffer is not aligned at the beginning of a
>  cache line. If there is other data on the _same_ cache line as your
>  buffer, and you invalidate the cache, then you may cause data loss
>  outside the buffer.
>

Yes, I understand that. I prefer to make sure this buffer issue in the
MTD core API.

>  Also, in some systems you must make sure that allocations to be used for
>  DMA are from a certain memory pool.
>
>  As for the original question... I'm not sure. At the moment I don't
>  believe it's true that all such buffers are suitable for DMA. Perhaps it
>  would be sensible for us to redefine the MTD API so that it is required
>  (and fix the users).
>

Exactly, maybe xxx_nand_dma_read() and xxx_nand_dma_write().
The buffer for this DMA functions should be cache-aligned.

>  For a long time, flash I/O was always done by the CPU instead of DMA, so
>  it wasn't an interesting question. I did start wondering when I
>  implemented support for the CAF? controller on OLPC, but then that
>  turned out to need bounce buffers anyway so it escaped my attention
>  again.
>

We might need to add DMA support in the MTD NAND interface, because
more and more SoC support on-chip NAND controller with DMA support.

Thanks a lot
-Bryan Wu


From cooloney at kernel.org  Mon Feb 25 06:15:19 2008
From: cooloney at kernel.org (Bryan Wu)
Date: Mon, 25 Feb 2008 19:15:19 +0800
Subject: [MTD/NAND] Blackfin NFC driver DMA bug ?
In-Reply-To: <20080222085403.GA2870@parrot.com>
References: <loom.20080221T171743-57@post.gmane.org>
	<386072610802211852r466ba76m427d8705b3d86ad9@mail.gmail.com>
	<20080222084533.GA2543@parrot.com> <20080222085403.GA2870@parrot.com>
Message-ID: <386072610802250315l2b7bbed0ma00b13ef68a2a486@mail.gmail.com>

On Fri, Feb 22, 2008 at 4:54 PM, Ivan Djelic <ivan.djelic at parrot.com> wrote:
> On Fri, Feb 22, 2008 at 09:45:33AM +0100, Ivan Djelic wrote:
>  > > Oh, I am not fully understand your concern.  The code is invalidating
>  > > or flushing buf before DMA operation.
>  > > And invalidate and flush operation is OK for buf which is not
>  > > cache-aligned on Blackfin arch. it also should be
>  > > OK for other arch.
>  >
>  > Well, consider the following scenario, in which 'buf' is not cache-aligned:
>  >
>  > 1) function bf5xx_nand_dma_rw() is called for reading data.
>  >
>  > 2) dcache is partially invalidated on a range containing 'buf': this range is
>  > cache-aligned, of course.
>  >
>
> > 3) some variable residing nearby 'buf' (in the same cache line interval) is
>  > read (not modified), resulting in a cache line being fetched. Cache line is not
>  > dirty.
>
>  Also, the variable contents in 3) may also be corrupted because of the
>  invalidation in 2).
>

Thanks a lot for the clarification.

If can be fixed in drivers or in MTD API, maybe MTD API is good place
to fix it completely as David mentioned.
I will found some way to fix it in my driver firstly.

Regards,
-Bryan Wu


From joern at logfs.org  Mon Feb 25 07:50:26 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Mon, 25 Feb 2008 13:50:26 +0100
Subject: [PATCH][JFFS2] Fix garbage collector block search
In-Reply-To: <fe810cf0801180828g7a48b6a1u69e35f832185b5eb@mail.gmail.com>
References: <E1J2Trs-000IFE-00.abelyako-mail-ru@f65.mail.ru>
	<20080114132843.GA15710@lazybastard.org>
	<fe810cf0801150424j25f35131v83692a3193a45a3b@mail.gmail.com>
	<20080115133350.GA22338@lazybastard.org>
	<fe810cf0801180828g7a48b6a1u69e35f832185b5eb@mail.gmail.com>
Message-ID: <20080225125026.GA12429@lazybastard.org>

[ I have already written a reply, but somehow that got lost.  Sorry
about the delay. ]

On Fri, 18 January 2008 19:28:08 +0300, Alexander Belyakov wrote:
> On 1/15/08, J?rn Engel <joern at logfs.org> wrote:
> >
> > Right now the important thing is to dig deeper and understand the nature
> > of this bug.  You can reproduce it, that is good.  We also know that it
> > makes a difference whether the block is on one list or the other.  But
> > we don't know yet, what difference exactly it makes.
> 
> Question. What is success criteria for jffs2_garbage_collect_pass() execution?
> 
> Why asking? In the case described above jffs2_find_gc_block() fails to
> find erase block for garbage collection but falling into
> jffs2_flush_wbuf_pad(c) which produces amount of erasing blocks. So
> jffs2_garbage_collect_pass() sees no single block for garbage
> collection, but filesystem still recieves fresh erasing blocks upon
> execution.
> 
> Is it success or failure? Theoretically.

Maybe the best answer to this is in jffs2_do_reserve_space:
        /* this needs a little more thought (true <tglx> :)) */

The exit criterium of jffs2_do_reserve_space() should be one of a)
enough free space was found or b) there is not enough free space.  If
the function returns with b) while there actually is more space to be
freed by calling jffs2_flush_wbuf_pad(), that is a bug.

Is this the case?  If it is, there should be blocks on the
erasable_pending_wbuf_list.  And that case is handled (correctly at
first glance) in jffs2_find_nextblock.

That is about as much digging as I will do.  My personal interest is
more in replacing JFFS2 than hunting arcane bugs in it. ;)

J?rn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong


From Bruce_Leonard at selinc.com  Mon Feb 25 23:55:58 2008
From: Bruce_Leonard at selinc.com (Bruce_Leonard at selinc.com)
Date: Mon, 25 Feb 2008 20:55:58 -0800
Subject: Question about the size field of mtd_info
Message-ID: <OF364D6CEB.467C00F3-ON882573FB.001A64F5-882573FB.001B164C@selinc.com>

I'm new to MTD (and writting drivers for Linux :-/ ), and I'm not sure 
about a result I'm seeing in mtd_info->size.  I'm putting together a NAND 
flash driver that ultimately will have 8G of flash attached to it in 2G, 
4G, and 8G stuffing options.  When I'm working with the 2G board 
everything looks fine, but when I jumped to the 4G board I found something 
interesting.  (I don't want to call it a bug, because I don't know how 
things work yet, so I'll stick with "interesting".)  With the 2G board 
mtd_info->size = 0x80000000, which is resonable, however, on the 4G board 
mtd_info->size = 0x0.  That makes sense because 4G= 0x100000000, one bit 
more than can be held in a 32-bit value which is how big mtd_info->size 
is, but it sure makes a mess of the calculations that use mtd_info->size. 
My question is, is this a bug or am I doing something wrong?

Thanks.

Bruce


From joern at logfs.org  Tue Feb 26 02:10:10 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Tue, 26 Feb 2008 08:10:10 +0100
Subject: Question about the size field of mtd_info
In-Reply-To: <OF364D6CEB.467C00F3-ON882573FB.001A64F5-882573FB.001B164C@selinc.com>
References: <OF364D6CEB.467C00F3-ON882573FB.001A64F5-882573FB.001B164C@selinc.com>
Message-ID: <20080226071009.GA20428@lazybastard.org>

On Mon, 25 February 2008 20:55:58 -0800, Bruce_Leonard at selinc.com wrote:
> 
> I'm new to MTD (and writting drivers for Linux :-/ ), and I'm not sure 
> about a result I'm seeing in mtd_info->size.  I'm putting together a NAND 
> flash driver that ultimately will have 8G of flash attached to it in 2G, 
> 4G, and 8G stuffing options.  When I'm working with the 2G board 
> everything looks fine, but when I jumped to the 4G board I found something 
> interesting.  (I don't want to call it a bug, because I don't know how 
> things work yet, so I'll stick with "interesting".)  With the 2G board 
> mtd_info->size = 0x80000000, which is resonable, however, on the 4G board 
> mtd_info->size = 0x0.  That makes sense because 4G= 0x100000000, one bit 
> more than can be held in a 32-bit value which is how big mtd_info->size 
> is, but it sure makes a mess of the calculations that use mtd_info->size. 
> My question is, is this a bug or am I doing something wrong?

It is either a bug or a design limitation, depending on your mood.
Patches to change this are welcome, in particular when the submitter is
willing to work on them until they are merge-worthy.

J?rn

-- 
This above all: to thine own self be true.
-- Shakespeare


From m_edake at yahoo.com  Tue Feb 26 02:18:38 2008
From: m_edake at yahoo.com (Mangesh Edake)
Date: Mon, 25 Feb 2008 23:18:38 -0800 (PST)
Subject: JFFS2 as rootfs on DataFlash
In-Reply-To: <47BDC7EF.5060603@gandalf.sssup.it>
Message-ID: <813562.16599.qm@web50809.mail.re2.yahoo.com>

Hello Michel,

> No,
> using in linux flash_eraseall to clean your
> partition. Maybe start from 
> a ramdisk.
In this case flash_eraseall will demand for write_oob
which is absent in my dataflash kernel driver. 

> It is the only partinion? If no, you must remember
> to align it at a 
> block size.
> Example my partionin start from 0x131400
My partition starts at 0x14a000, which is a multiple
of block size 0x2100.

> 
> setenv bootargs console=ttyS0,115200 mem=8M
> rootfstype=jffs2 
> root=/dev/mtdblock1
> rw
>
mtdparts=spi0.1-AT45DB321x:1221k(ARMboot)ro,- at 1221k(root)
I'm already creating mtd partitons statically in my
driver and would not prefer to create through
commandline.

> For the creation use:
> mkfs.jffs2 -d romfs -l -p -e 0x2100 -v -n -o
> images/ramdisk.img > log.txt
> 
Doing same!

Please tell me for my dataflash, does the behaviour of
creating image, writing image and reading-writing to
flash should look like exactly as nand-flash or so..?
Incase of Nandflash, data and oob is treated
separately, means normal read-write functions are for
512 bytes and oob functions for 16-byte oob. Even I
think, image creation for nand is mostly done with
eraseblock size in multiples of 512 (0x200) bytes.
e.g mkfs.jffs2 -e 0x4000 etc   
So should I do the same?

--
Thanks and Regards,
Mangesh Edake.



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


From shizheng at mail.ustc.edu.cn  Tue Feb 26 02:41:06 2008
From: shizheng at mail.ustc.edu.cn (shizheng)
Date: Tue, 26 Feb 2008 15:41:06 +0800
Subject: Does jffs support sequential programming of NAND flash?
Message-ID: <404011746.16520@ustc.edu.cn>

Hi,all:
We are building a filesystem on large-block nand flash K9K4G08U0M.

It has a program limitation that the program addressing should
be done in sequential order in a block, i.e. random page address
programming is prohibited.

We are new to jffs, so I wanna know if yaffs support such kind of
NAND device.

best wishes, shizheng




From basicmark at yahoo.com  Tue Feb 26 04:04:27 2008
From: basicmark at yahoo.com (Mark Underwood)
Date: Tue, 26 Feb 2008 09:04:27 +0000 (GMT)
Subject: NAND driver
In-Reply-To: <751269.90312.qm@web36904.mail.mud.yahoo.com>
Message-ID: <631124.21101.qm@web36909.mail.mud.yahoo.com>


--- Mark Underwood <basicmark at yahoo.com> wrote:

> I?m writing a NAND driver for an ASIC. The NAND controller has been designed to handle page read
> &
> writes with little SW intervention using interrupts or DMA, so I plan to implement the
> write_page_raw & read_page_raw functions.
> However, looking through nand_base.c it looks like not all NAND access go through these
> functions
> so to start with I have implemented the cmd_ctrl function & supplied the IO_ADDR_R & IO_ADDR_W
> address with the thinking that these would be a fall back when the access doesn't go through the
> raw functions.
> Unfortunately it seems the single write functionality of the controller is broken. The page 
> read
> & write functionality only allow me to work in 512byte blocks so I can't write OOB that way. Can
> you confirm that there are cases where OOB is written separately and if so do you have any
> suggestions for getting around this problem?
> 
> Many thanks,
> 
> Mark
> 

I forgot to say that I'm working on a 2.6.21.1 kernel.

After some pondering I managed to implement the single write functionality by abusing the command
fifo and playing with GPIO pins.

Looking through nand_base.c I notice that although I can pass in *_page_raw operations in the
nand_chip structure they are not used in the *_page_swecc functions but instead they call the
internal *_page_raw functions directly. I propose just to replace the direct calls with indirect
ones (via the function pointers in the nand_chip structure). Does this proposal sound OK?

Mark

> 
> 
>       ___________________________________________________________ 
> Rise to the challenge for Sport Relief with Yahoo! For Good  
> 
> http://uk.promotions.yahoo.com/forgood/
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/


From gangadhark at tataelxsi.co.in  Tue Feb 26 07:24:52 2008
From: gangadhark at tataelxsi.co.in (Gangadhar Kodishala)
Date: Tue, 26 Feb 2008 17:54:52 +0530
Subject: NAND jffs2 partition problem
Message-ID: <OEEHIIIJHDGOBJFAANGNKEEGCBAA.gangadhark@tataelxsi.co.in>

Hi All,

My NAND jffs2 partition is of size 6MB and I use only 5MB of it for root
filesystem image.
I am trying to use the extra 1MB space for the user-specific data like the
version information.

My bootloader checks this version information for selecting the latest
version of root filesystem.

But when I boot with the JFFS2 file system mounted with this partition, the
extra 1 MB space is
written with 0xFF. So the next time when my bootloader checks for the
version information I get
all 0xff.

How do I make use of this extra space for storing my user-specific data ?

Regards,
Gangadhar


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.



From gerickson at nuovations.com  Tue Feb 26 13:26:48 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Tue, 26 Feb 2008 10:26:48 -0800
Subject: [PATCH] [MTD-UTILS]: Add Optional ZLIB and LZO CFLAGS and LDFLAGS
Message-ID: <C3E999E8.D9D2%gerickson@nuovations.com>

This patch adds support for allowing the specification of unique CFLAGS and
LDFLAGS for both LZO and ZLIB. In addition, it allows for independently
specifying both PREFIX and EXEC_PREFIX.

The former is useful in some cross-compilation environments where the LZO
and ZLIB versions being built against are not those installed in the
standard locations.

The latter is useful when installing mtd-utils in a multi-architecture
installation area.

Compiled, linked and tested successfully in both a i686-unknown-linux to
powerpc-unknown-linux cross-compilation environment as well as a native
i686-unknown-linux environment

Signed-off-by: Grant Erickson <gerickson at nuovations.com>

---
diff -aruN mtd-utils-1.1.0/Makefile mtd-utils-1.1.0.N/Makefile
--- mtd-utils-1.1.0/Makefile    2007-08-03 06:55:51.000000000 -0700
+++ mtd-utils-1.1.0.N/Makefile    2008-02-26 09:51:46.000000000 -0800
@@ -1,12 +1,14 @@
 
 # -*- sh -*-
 
-SBINDIR=/usr/sbin
-MANDIR=/usr/man
-INCLUDEDIR=/usr/include
+PREFIX=/usr
+EXEC_PREFIX=$(PREFIX)
+SBINDIR=$(EXEC_PREFIX)/sbin
+MANDIR=$(PREFIX)/man
+INCLUDEDIR=$(PREFIX)/include
 #CROSS=arm-linux-
 CC := $(CROSS)gcc
-CFLAGS := -I./include -O2 -Wall
+CFLAGS := -I./include $(ZLIBCFLAGS) $(LZOCFLAGS) -O2 -Wall
 
 ifeq ($(origin CROSS),undefined)
   BUILDDIR := .
@@ -58,7 +60,7 @@
             $(BUILDDIR)/compr_zlib.o \
             $(BUILDDIR)/compr_lzo.o \
             $(BUILDDIR)/compr.o
-    $(CC) $(LDFLAGS) -o $@ $^ -lz -llzo2
+    $(CC) $(LDFLAGS) -o $@ $^ $(ZLIBLDFLAGS) -lz $(LZOLDFLAGS) -llzo2
 
 $(BUILDDIR)/flash_eraseall: $(BUILDDIR)/crc32.o
$(BUILDDIR)/flash_eraseall.o
     $(CC) $(LDFLAGS) -o $@ $^
--




From gordonfarquharson at gmail.com  Tue Feb 26 16:39:54 2008
From: gordonfarquharson at gmail.com (Gordon Farquharson)
Date: Tue, 26 Feb 2008 14:39:54 -0700
Subject: [PATCH] [MTD] [NOR] Add support for the ST M29W400DB flash chip
Message-ID: <97a0a9ac0802261339w6eb6143fx87ddca8bcb0add87@mail.gmail.com>

Please could somebody acknowledge this patch. I have sent it to
linux-mtd several times and received no response [1]. It was
originally posted to linux-mtd on 2008-01-08 in the hope that it would
be included in 2.6.25.

Thanks.

[1] http://lists.infradead.org/pipermail/linux-mtd/2008-January/020291.html

---

Add support for the ST M29W400DB flash chip. which is used on the GLAN Tank NAS.

Signed-off-by: Gordon Farquharson <gordonfarquharson at gmail.com>

---

diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 4be51a8..51ec937 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -135,6 +135,7 @@
 #define M29W160DT	0x22C4
 #define M29W160DB	0x2249
 #define M29W040B	0x00E3
+#define M29W400DB	0x00EF
 #define M50FW040	0x002C
 #define M50FW080	0x002D
 #define M50FW016	0x002E
@@ -1498,7 +1499,22 @@ static const struct amd_flash_info jedec_table[] = {
 		.regions	= {
 			ERASEINFO(0x10000,8),
 		}
-        }, {
+	}, {
+		.mfr_id		= MANUFACTURER_ST,
+		.dev_id		= M29W400DB,
+		.name		= "ST M29W400DB",
+		.devtypes	= CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+		.uaddr		= MTD_UADDR_0x0555_0x02AA,
+		.dev_size	= SIZE_512KiB,
+		.cmd_set	= P_ID_AMD_STD,
+		.nr_regions	= 4,
+		.regions	= {
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x02000,2),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x10000,7)
+		}
+	}, {
 		.mfr_id		= MANUFACTURER_ST,
 		.dev_id		= M50FW040,
 		.name		= "ST M50FW040",

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676


From paulius.zaleckas at teltonika.lt  Tue Feb 26 18:42:39 2008
From: paulius.zaleckas at teltonika.lt (Paulius Zaleckas)
Date: Wed, 27 Feb 2008 01:42:39 +0200
Subject: [PATCH] MTD-XIP: Use generic xip_iprefetch() instead of asm volatile
	(...)
Message-ID: <fq285f$isa$1@ger.gmane.org>

Untested, but shouldn't break anything...
Makes MTD_XIP arch independent. I guess this is why xip_iprefetch() was made for.

Signed-off-by: Paulius Zaleckas <paulius.zaleckas at teltonika.lt>

---
  drivers/mtd/chips/cfi_cmdset_0001.c |    4 ++--
  drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++--
  drivers/mtd/chips/cfi_probe.c       |    2 +-
  drivers/mtd/chips/cfi_util.c        |    2 +-
  4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 1707f98..c54d0b6 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -1007,10 +1007,10 @@ static int __xipram xip_wait_for_operation(
  			chip->state = newstate;
  			map_write(map, CMD(0xff), adr);
  			(void) map_read(map, adr);
-			asm volatile (".rep 8; nop; .endr");
+			xip_iprefetch();
  			local_irq_enable();
  			spin_unlock(chip->mutex);
-			asm volatile (".rep 8; nop; .endr");
+			xip_iprefetch();
  			cond_resched();

  			/*
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 389acc6..f71cd70 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -717,10 +717,10 @@ static void __xipram xip_udelay(struct map_info *map, struct flchip *chip,
  			chip->erase_suspended = 1;
  			map_write(map, CMD(0xf0), adr);
  			(void) map_read(map, adr);
-			asm volatile (".rep 8; nop; .endr");
+			xip_iprefetch();
  			local_irq_enable();
  			spin_unlock(chip->mutex);
-			asm volatile (".rep 8; nop; .endr");
+			xip_iprefetch();
  			cond_resched();

  			/*
diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
index 60e11a0..648a0a5 100644
--- a/drivers/mtd/chips/cfi_probe.c
+++ b/drivers/mtd/chips/cfi_probe.c
@@ -39,7 +39,7 @@ struct mtd_info *cfi_probe(struct map_info *map);
  #define xip_allowed(base, map) \
  do { \
  	(void) map_read(map, base); \
-	asm volatile (".rep 8; nop; .endr"); \
+	xip_iprefetch(); \
  	local_irq_enable(); \
  } while (0)

diff --git a/drivers/mtd/chips/cfi_util.c b/drivers/mtd/chips/cfi_util.c
index 2e51496..72e0022 100644
--- a/drivers/mtd/chips/cfi_util.c
+++ b/drivers/mtd/chips/cfi_util.c
@@ -65,7 +65,7 @@ __xipram cfi_read_pri(struct map_info *map, __u16 adr, __u16 size, const char* n

  #ifdef CONFIG_MTD_XIP
  	(void) map_read(map, base);
-	asm volatile (".rep 8; nop; .endr");
+	xip_iprefetch();
  	local_irq_enable();
  #endif

-- 



From nico at cam.org  Wed Feb 27 10:46:53 2008
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 27 Feb 2008 10:46:53 -0500 (EST)
Subject: [PATCH] MTD-XIP: Use generic xip_iprefetch() instead of asm
	volatile (...)
In-Reply-To: <fq285f$isa$1@ger.gmane.org>
References: <fq285f$isa$1@ger.gmane.org>
Message-ID: <alpine.LFD.1.00.0802271046180.3167@xanadu.home>

On Wed, 27 Feb 2008, Paulius Zaleckas wrote:

> Untested, but shouldn't break anything...
> Makes MTD_XIP arch independent. I guess this is why xip_iprefetch() was made for.
> 
> Signed-off-by: Paulius Zaleckas <paulius.zaleckas at teltonika.lt>

Acked-by: Nicolas Pitre <nico at cam.org>


> 
> ---
>   drivers/mtd/chips/cfi_cmdset_0001.c |    4 ++--
>   drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++--
>   drivers/mtd/chips/cfi_probe.c       |    2 +-
>   drivers/mtd/chips/cfi_util.c        |    2 +-
>   4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index 1707f98..c54d0b6 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -1007,10 +1007,10 @@ static int __xipram xip_wait_for_operation(
>   			chip->state = newstate;
>   			map_write(map, CMD(0xff), adr);
>   			(void) map_read(map, adr);
> -			asm volatile (".rep 8; nop; .endr");
> +			xip_iprefetch();
>   			local_irq_enable();
>   			spin_unlock(chip->mutex);
> -			asm volatile (".rep 8; nop; .endr");
> +			xip_iprefetch();
>   			cond_resched();
> 
>   			/*
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 389acc6..f71cd70 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -717,10 +717,10 @@ static void __xipram xip_udelay(struct map_info *map, struct flchip *chip,
>   			chip->erase_suspended = 1;
>   			map_write(map, CMD(0xf0), adr);
>   			(void) map_read(map, adr);
> -			asm volatile (".rep 8; nop; .endr");
> +			xip_iprefetch();
>   			local_irq_enable();
>   			spin_unlock(chip->mutex);
> -			asm volatile (".rep 8; nop; .endr");
> +			xip_iprefetch();
>   			cond_resched();
> 
>   			/*
> diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
> index 60e11a0..648a0a5 100644
> --- a/drivers/mtd/chips/cfi_probe.c
> +++ b/drivers/mtd/chips/cfi_probe.c
> @@ -39,7 +39,7 @@ struct mtd_info *cfi_probe(struct map_info *map);
>   #define xip_allowed(base, map) \
>   do { \
>   	(void) map_read(map, base); \
> -	asm volatile (".rep 8; nop; .endr"); \
> +	xip_iprefetch(); \
>   	local_irq_enable(); \
>   } while (0)
> 
> diff --git a/drivers/mtd/chips/cfi_util.c b/drivers/mtd/chips/cfi_util.c
> index 2e51496..72e0022 100644
> --- a/drivers/mtd/chips/cfi_util.c
> +++ b/drivers/mtd/chips/cfi_util.c
> @@ -65,7 +65,7 @@ __xipram cfi_read_pri(struct map_info *map, __u16 adr, __u16 size, const char* n
> 
>   #ifdef CONFIG_MTD_XIP
>   	(void) map_read(map, base);
> -	asm volatile (".rep 8; nop; .endr");
> +	xip_iprefetch();
>   	local_irq_enable();
>   #endif
> 
> -- 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 


Nicolas


From leoli at freescale.com  Thu Feb 28 07:17:31 2008
From: leoli at freescale.com (Li Yang)
Date: Thu, 28 Feb 2008 20:17:31 +0800
Subject: [PATCH] MTD: fix partition scan control logic in physmap_of and
	fsl_elbc_nand
Message-ID: <1204201051-13107-1-git-send-email-leoli@freescale.com>

The generic rule for partition scan is to try all supported
partition types before an usable partition table is found.
However the original code returns unsuccessful when there is
an error in any of the partition types.

Signed-off-by: Li Yang <leoli at freescale.com>
Cc: Stefan Roese <sr at denx.de>
Cc: Peter Korsgaard <jacmet at sunsite.dk>
---
I later found that Stefan has proposed a similar patch for physmap_of
and Peter proposed another patch to fix cmdlinepart instead.
I'd say that even after cmdlinepart patch is applied the scan control
logic still needs to be fixed.

 drivers/mtd/maps/physmap_of.c    |   12 ++----------
 drivers/mtd/nand/fsl_elbc_nand.c |    7 +------
 2 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..5ebbbc4 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -225,23 +225,15 @@ static int __devinit of_flash_probe(struct of_device *dev,
 	 * line, these take precedence over device tree information */
 	err = parse_mtd_partitions(info->mtd, part_probe_types,
 	                           &info->parts, 0);
-	if (err < 0)
-		return err;
 
 #ifdef CONFIG_MTD_OF_PARTS
-	if (err == 0) {
+	if (err <= 0)
 		err = of_mtd_parse_partitions(&dev->dev, info->mtd,
 		                              dp, &info->parts);
-		if (err < 0)
-			return err;
-	}
 #endif
 
-	if (err == 0) {
+	if (err <= 0)
 		err = parse_obsolete_partitions(dev, info, dp);
-		if (err < 0)
-			return err;
-	}
 
 	if (err > 0)
 		add_mtd_partitions(info->mtd, info->parts, err);
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b025dfe..72e9bd9 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -1054,16 +1054,11 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
 	/* First look for RedBoot table or partitions on the command
 	 * line, these take precedence over device tree information */
 	ret = parse_mtd_partitions(&priv->mtd, part_probe_types, &parts, 0);
-	if (ret < 0)
-		goto err;
 
 #ifdef CONFIG_MTD_OF_PARTS
-	if (ret == 0) {
+	if (ret <= 0)
 		ret = of_mtd_parse_partitions(priv->dev, &priv->mtd,
 		                              node, &parts);
-		if (ret < 0)
-			goto err;
-	}
 #endif
 
 	if (ret > 0)
-- 
1.5.4.rc4



From manfred.schlaegl at gmx.at  Thu Feb 28 17:37:32 2008
From: manfred.schlaegl at gmx.at (=?ISO-8859-1?Q?Schl=E4gl?= Manfred jun.)
Date: Thu, 28 Feb 2008 23:37:32 +0100
Subject: Global changelogs about
Message-ID: <1204238252.3435.21.camel@lisa.alm.archives.at>

Hi!
My name is Schlaegl Manfred and I'm new on the list. I spent the last
two week on viewing and analyzing source codes of mtd+nand and jffs2.
I like to proof the consitency(wear-leveling, bad-block handling, etc.)
for our requirements so I need some information about
critical-changes(bugfixes,etc) of mtd+nand in the last view years. For
example a changelog of critical changes or something.

Second: We are currently using kernels 2.6.12 and 2.6.15. Are there any
critical bugs or problems of mtd+nand known on this kernel-versions?


Thank you very much in advance.
	Manfred Schlaegl





From joern at logfs.org  Thu Feb 28 18:50:48 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Fri, 29 Feb 2008 00:50:48 +0100
Subject: Global changelogs about
In-Reply-To: <1204238252.3435.21.camel@lisa.alm.archives.at>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
Message-ID: <20080228235048.GA24195@lazybastard.org>

On Thu, 28 February 2008 23:37:32 +0100, Schl?gl Manfred jun. wrote:
> 
> My name is Schlaegl Manfred and I'm new on the list. I spent the last
> two week on viewing and analyzing source codes of mtd+nand and jffs2.
> I like to proof the consitency(wear-leveling, bad-block handling, etc.)
> for our requirements so I need some information about
> critical-changes(bugfixes,etc) of mtd+nand in the last view years. For
> example a changelog of critical changes or something.
> 
> Second: We are currently using kernels 2.6.12 and 2.6.15. Are there any
> critical bugs or problems of mtd+nand known on this kernel-versions?

I hope you do realize the rudeness of your request.  I still have a lot
of dirty laundry to wash, would you be willing to take care of it?
Maybe water my plants?  Take out the trash?

If you want to participate, send patches, review code, report bugs or
provide documentation.  Otherwise leave and don't come back.

J?rn

-- 
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then  CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source


From gerickson at nuovations.com  Thu Feb 28 19:30:38 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Thu, 28 Feb 2008 16:30:38 -0800
Subject: Writing JFFS2 to Samsung K9F1208U0B NAND on AMCC PPC405EX/r
	Kilauea/Haleakala
Message-ID: <C3EC922E.DAF1%gerickson@nuovations.com>

I am attempting to create and write a JFFS2 file system to the Samsung
K9F1208U0B NAND part on an AMCC PPC405EXr "Haleakala" board and seem to be
running into a hurdle or two.

Given the Samsung K9F1208U0B's 16 KiB erase block and 512 B page sizes, I
invoked mkfs.jffs2 with:

% mkfs.jffs2 -n -b -s 512 -e 16 KiB -d /export/haleakala -o haleakala.img

I then erase the device with 'flash_eraseall' using the '-j' option:

# flash_eraseall -j /dev/mtd9
Erasing 16 Kibyte @ 3f94000 -- 99 % complete. Cleanmarker written at
3f94000.

However, when I attempt to lay down the file system image with nandwrite
(again, using the '-j' option), I get a driver error:

# nandwrite -j /dev/mtd9 haleakala.img
MEMSETOOBSEL: Inappropriate ioctl for device

Eliding the '-j' option, I get errors about page alignment:

# nandwrite /dev/mtd9 haleakala.img
Input file is not page aligned
Data was only partially written due to error: Success

The output from 'mtd_debug':

# mtd_debug info /dev/mtd9
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_CAP_NANDFLASH
mtd.size = 66682880 (63M)
mtd.erasesize = 16384 (16K)
mtd.writesize = 512
mtd.oobsize = 16 
regions = 0

The version of mtd-utils is 1.1.0 from the MTD FTP site.

This occurs with either hand-built kernels using the GIT repo or
'git://www.denx.de/git/linux-2.6-denx.git' the latest pre-built kernel
posted to the AMCC-partner (DENX) site:

    ftp://ftp.denx.de/pub/linux/images/amcc/kilauea/uImage-g8adfc2c

# uname -a
Linux haleakala 2.6.25-rc2-00492-g8adfc2c #1 Sat Feb 23 23:10:15 CET 2008
ppc unknown

Anyone have success with writing a JFFS2 file system on these boards or have
any insight into the errors above?

Regards,

Grant Erickson




From manfred.schlaegl at gmx.at  Fri Feb 29 03:42:57 2008
From: manfred.schlaegl at gmx.at (=?ISO-8859-1?Q?Schl=E4gl?= Manfred jun.)
Date: Fri, 29 Feb 2008 09:42:57 +0100
Subject: Global changelogs about
In-Reply-To: <20080228235048.GA24195@lazybastard.org>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
	<20080228235048.GA24195@lazybastard.org>
Message-ID: <1204274577.3408.25.camel@lisa.alm.archives.at>

Am Freitag, den 29.02.2008, 00:50 +0100 schrieb J?rn Engel:
> On Thu, 28 February 2008 23:37:32 +0100, Schl?gl Manfred jun. wrote:
> > 
> > My name is Schlaegl Manfred and I'm new on the list. I spent the last
> > two week on viewing and analyzing source codes of mtd+nand and jffs2.
> > I like to proof the consitency(wear-leveling, bad-block handling, etc.)
> > for our requirements so I need some information about
> > critical-changes(bugfixes,etc) of mtd+nand in the last view years. For
> > example a changelog of critical changes or something.
> > 
> > Second: We are currently using kernels 2.6.12 and 2.6.15. Are there any
> > critical bugs or problems of mtd+nand known on this kernel-versions?
> 
> I hope you do realize the rudeness of your request.  I still have a lot
> of dirty laundry to wash, would you be willing to take care of it?
> Maybe water my plants?  Take out the trash?
My request wasn't meant like that. I don't wanted to affront the people
here. I just wanted to know, if such a list of critical bugs or problems
exist for the last few years. Don't you think such a list would be
useful for people who want to get in mtd(+nand) using and development?

 If such a list not exist i'll create it by my self and make it public
to you and the others. I know: It's MY work to do, I just not wanted to
do work twice. 

> 
> If you want to participate, send patches, review code, report bugs or
> provide documentation.  Otherwise leave and don't come back.
Providing documentation, results of my testing, etc. .. just what i like
to do currently... 

Again, I'm sorry .. I hope, you understand the reason of my request.
I've already found a starting-point for working on mtd. Source and
documentation about mtd ist very well, but I thought, this further
information would have been very useful for me, to do expedient work on
mtd.

> 
> J?rn
> 

respects
	Manfred



From joern at logfs.org  Fri Feb 29 03:43:45 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Fri, 29 Feb 2008 09:43:45 +0100
Subject: swap file over jffs2 partition
In-Reply-To: <47C772E9.2000000@gmx.net>
References: <47C772E9.2000000@gmx.net>
Message-ID: <20080229084345.GA16507@lazybastard.org>

On Fri, 29 February 2008 04:50:17 +0200, Dimitrios Apostolou wrote:
> 
> I intend to build a diskless linux system (root over NFS). Because it
> has 1GB of embedded flash storage, I'm thinking of using this as swap 
> (I've been bitten many times by the problems linux has with *no* 
> swap...). And to avoid wearing out the flash storage too fast, I 'm 
> thinking to format the 1GB partition as JFFS2, and create the swapfile 
> on top of it.
> 
> I'm not so experienced with JFFS and I don't know if it's too heavy for
> the CPU, for swapping. Or if there are other issues I 'll face. What do
> you think about it? Any other ways you 'd propose?
> 
> Sorry for sending this at LKML but jffs-dev mailing list seems to be 
> off. And JFFS is the only in-kernel filesystem that does wear-leveling, 
> right?

Replying in reverse order...

The relevant mailing list is linux-mtd, added to Cc:.  JFFS and JFFS2
are two different things, JFFS is older and was removed from the kernel
not too long ago.

The real fun comes not from CPU usage, but from interactions with the
memory management subsystem.  In a nutshell, JFFS2 may require memory in
order to write data.  When the system is under memory pressure, it needs
JFFS2 to write out pages, which will try to allocate memory.  It is
theoretically possible to deadlock the system in this way.

On the plus side, the write path of JFFS2 is relatively simple and
extremely low-latency.  It shouldn't be too hard to review the code and
handle all problem cases wrt. memory allocations.

One issue that is hard to solve is space reservation.  JFFS2 compresses
data and allows users to write as long as there is space remaining.  It
is possible to swap out data that compresses well, have some other
process fill up the filesystem, then try to swap out data that
compresses badly and get -ENOSPC in return.  As a system administrator
you can prevent others from ever writing to JFFS2 - and you better do!

J?rn

-- 
Joern's library part 5:
http://www.faqs.org/faqs/compression-faq/part2/section-9.html


From manfred.schlaegl at gmx.at  Fri Feb 29 03:50:29 2008
From: manfred.schlaegl at gmx.at (=?ISO-8859-1?Q?Schl=E4gl?= Manfred jun.)
Date: Fri, 29 Feb 2008 09:50:29 +0100
Subject: Writing JFFS2 to Samsung K9F1208U0B NAND on AMCC PPC405EX/r
	Kilauea/Haleakala
In-Reply-To: <C3EC922E.DAF1%gerickson@nuovations.com>
References: <C3EC922E.DAF1%gerickson@nuovations.com>
Message-ID: <1204275029.3408.31.camel@lisa.alm.archives.at>

Am Donnerstag, den 28.02.2008, 16:30 -0800 schrieb Grant Erickson:
> I am attempting to create and write a JFFS2 file system to the Samsung
> K9F1208U0B NAND part on an AMCC PPC405EXr "Haleakala" board and seem to be
> running into a hurdle or two.
> 
> Given the Samsung K9F1208U0B's 16 KiB erase block and 512 B page sizes, I
> invoked mkfs.jffs2 with:
> 
> % mkfs.jffs2 -n -b -s 512 -e 16 KiB -d /export/haleakala -o haleakala.img

> I then erase the device with 'flash_eraseall' using the '-j' option:
> 
> # flash_eraseall -j /dev/mtd9
> Erasing 16 Kibyte @ 3f94000 -- 99 % complete. Cleanmarker written at
> 3f94000.
> 
> However, when I attempt to lay down the file system image with nandwrite
> (again, using the '-j' option), I get a driver error:
> 
> # nandwrite -j /dev/mtd9 haleakala.img
> MEMSETOOBSEL: Inappropriate ioctl for device
> 
> Eliding the '-j' option, I get errors about page alignment:
> 
> # nandwrite /dev/mtd9 haleakala.img
> Input file is not page aligned
> Data was only partially written due to error: Success
> 
> The output from 'mtd_debug':
> 
> # mtd_debug info /dev/mtd9
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 66682880 (63M)
> mtd.erasesize = 16384 (16K)
> mtd.writesize = 512
> mtd.oobsize = 16 
> regions = 0
> 
> The version of mtd-utils is 1.1.0 from the MTD FTP site.
> 
> This occurs with either hand-built kernels using the GIT repo or
> 'git://www.denx.de/git/linux-2.6-denx.git' the latest pre-built kernel
> posted to the AMCC-partner (DENX) site:
> 
>     ftp://ftp.denx.de/pub/linux/images/amcc/kilauea/uImage-g8adfc2c
> 
> # uname -a
> Linux haleakala 2.6.25-rc2-00492-g8adfc2c #1 Sat Feb 23 23:10:15 CET 2008
> ppc unknown
> 
> Anyone have success with writing a JFFS2 file system on these boards or have
> any insight into the errors above?
> 
> Regards,
> 
> Grant Erickson
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

You have to pad(-p) your image, so that it's size is a multiple of page
size
% mkfs.jffs2 -n -b -s 512 -p 512 -e 16 KiB -d /export/haleakala -o
haleakala.img

Then you should be able to write it with:
% nandwrite /dev/mtd9 haleakala.img

greetings
	manfred




From joern at logfs.org  Fri Feb 29 03:57:48 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Fri, 29 Feb 2008 09:57:48 +0100
Subject: Global changelogs about
In-Reply-To: <1204274577.3408.25.camel@lisa.alm.archives.at>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
	<20080228235048.GA24195@lazybastard.org>
	<1204274577.3408.25.camel@lisa.alm.archives.at>
Message-ID: <20080229085748.GB16507@lazybastard.org>

On Fri, 29 February 2008 09:42:57 +0100, Schl?gl Manfred jun. wrote:
>
> My request wasn't meant like that. I don't wanted to affront the people
> here. I just wanted to know, if such a list of critical bugs or problems
> exist for the last few years. Don't you think such a list would be
> useful for people who want to get in mtd(+nand) using and development?
> 
>  If such a list not exist i'll create it by my self and make it public
> to you and the others. I know: It's MY work to do, I just not wanted to
> do work twice. 

No such list exists, afaik.  Generally people tend to either use the
latest kernels or backport drivers/mtd/ and fs/jffs2/ along with any
dependencies to their respective kernels.

> Again, I'm sorry .. I hope, you understand the reason of my request.

No worries.  This lists gets a fair share of both "my kernel is five
years old, but I want all bugfixes and performance improvements from the
newest code" and "can you provide free consulting".  Neither is greeted
with much enthusiasm and your mail appeared to match both.

J?rn

-- 
They laughed at Galileo.  They laughed at Copernicus.  They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
-- unknown


From manfred.schlaegl at gmx.at  Fri Feb 29 04:19:48 2008
From: manfred.schlaegl at gmx.at (=?ISO-8859-1?Q?Schl=E4gl?= Manfred jun.)
Date: Fri, 29 Feb 2008 10:19:48 +0100
Subject: Global changelogs about
In-Reply-To: <20080229085748.GB16507@lazybastard.org>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
	<20080228235048.GA24195@lazybastard.org>
	<1204274577.3408.25.camel@lisa.alm.archives.at>
	<20080229085748.GB16507@lazybastard.org>
Message-ID: <1204276788.3593.17.camel@lisa.alm.archives.at>

Am Freitag, den 29.02.2008, 09:57 +0100 schrieb J?rn Engel:
> On Fri, 29 February 2008 09:42:57 +0100, Schl?gl Manfred jun. wrote:
> >
> > My request wasn't meant like that. I don't wanted to affront the people
> > here. I just wanted to know, if such a list of critical bugs or problems
> > exist for the last few years. Don't you think such a list would be
> > useful for people who want to get in mtd(+nand) using and development?
> > 
> >  If such a list not exist i'll create it by my self and make it public
> > to you and the others. I know: It's MY work to do, I just not wanted to
> > do work twice. 
> 
> No such list exists, afaik. 
Thank you. Thats what i wanted to know.

>  Generally people tend to either use the
> latest kernels or backport drivers/mtd/ and fs/jffs2/ along with any
> dependencies to their respective kernels.
> 
> > Again, I'm sorry .. I hope, you understand the reason of my request.
> 
> No worries.  This lists gets a fair share of both "my kernel is five
> years old, but I want all bugfixes and performance improvements from the
> newest code" and "can you provide free consulting".  Neither is greeted
> with much enthusiasm and your mail appeared to match both.
First of all: I'm not a leecher. I don't subscribed to this list to get
free support from you. That my first post was such a question was more
or less by chance.

Back to the list: I don't wanted this bug-list to build a 2.6.12 with
newest code.. I wanted this list to get an black on white impression of
the firmness of mtd over time. To see if there were some critical bugs
solved in near past. To see some statistical issues. If you think, such
an approach is stupid, it's your oppinion and i'll respect it, if you
give me some reasons..
Again: My interrest does not belong to solve only my current issues.. I
just wanted to get an impression of mtd over time.


> 
> J?rn
> 
respects
	Manfred




From liudows2 at gmail.com  Fri Feb 29 07:52:49 2008
From: liudows2 at gmail.com (liu yang)
Date: Fri, 29 Feb 2008 20:52:49 +0800
Subject: question about struct map_info
Message-ID: <4558af040802290452q653549f5m199f71050fb359e1@mail.gmail.com>

Hi, all.

In the MTD driver for nor flash,  we should define a 'map_info'
struct. But what is the use of
map_info->read/write ? What is the difference between
map_info->read/write and mtd_info->read/write ?
I think the fs layer should call mtd_info->read/write, but not
map_info->read/write. Who is the caller of map_info->read/write?

Thanks!

liu yang


From jwboyer at linux.vnet.ibm.com  Fri Feb 29 09:17:07 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Fri, 29 Feb 2008 08:17:07 -0600
Subject: Writing JFFS2 to Samsung K9F1208U0B NAND on AMCC PPC405EX/r
	Kilauea/Haleakala
In-Reply-To: <C3EC922E.DAF1%gerickson@nuovations.com>
References: <C3EC922E.DAF1%gerickson@nuovations.com>
Message-ID: <20080229081707.2fa09f98@zod.rchland.ibm.com>

On Thu, 28 Feb 2008 16:30:38 -0800
Grant Erickson <gerickson at nuovations.com> wrote:

> I am attempting to create and write a JFFS2 file system to the Samsung
> K9F1208U0B NAND part on an AMCC PPC405EXr "Haleakala" board and seem to be
> running into a hurdle or two.
> 
> Given the Samsung K9F1208U0B's 16 KiB erase block and 512 B page sizes, I
> invoked mkfs.jffs2 with:
> 
> % mkfs.jffs2 -n -b -s 512 -e 16 KiB -d /export/haleakala -o haleakala.img
> 
> I then erase the device with 'flash_eraseall' using the '-j' option:
> 
> # flash_eraseall -j /dev/mtd9
> Erasing 16 Kibyte @ 3f94000 -- 99 % complete. Cleanmarker written at
> 3f94000.
> 
> However, when I attempt to lay down the file system image with nandwrite
> (again, using the '-j' option), I get a driver error:
> 
> # nandwrite -j /dev/mtd9 haleakala.img
> MEMSETOOBSEL: Inappropriate ioctl for device

This has been broken since the ECC rework went into the kernel.  I hear
there are patches floating around to fix it.  Maybe they will magically
appear today...

josh


From brijesh.s.singh at gmail.com  Fri Feb 29 09:53:35 2008
From: brijesh.s.singh at gmail.com (Brijesh Singh)
Date: Fri, 29 Feb 2008 20:23:35 +0530
Subject: Global changelogs about
In-Reply-To: <1204276788.3593.17.camel@lisa.alm.archives.at>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
	<20080228235048.GA24195@lazybastard.org>
	<1204274577.3408.25.camel@lisa.alm.archives.at>
	<20080229085748.GB16507@lazybastard.org>
	<1204276788.3593.17.camel@lisa.alm.archives.at>
Message-ID: <6b5362aa0802290653l274f3c6fwcaabf10d6f2926d6@mail.gmail.com>

With all respect,I think this discussion(Miscommunication) is going
too far..And it is not in members interest either.

Sorry in advance.(Incase someone didn't like interruption. )


---
Brijesh


On Fri, Feb 29, 2008 at 2:49 PM, Schl?gl Manfred jun.
<manfred.schlaegl at gmx.at> wrote:
> Am Freitag, den 29.02.2008, 09:57 +0100 schrieb J?rn Engel:
>
> > On Fri, 29 February 2008 09:42:57 +0100, Schl?gl Manfred jun. wrote:
>  > >
>  > > My request wasn't meant like that. I don't wanted to affront the people
>  > > here. I just wanted to know, if such a list of critical bugs or problems
>  > > exist for the last few years. Don't you think such a list would be
>  > > useful for people who want to get in mtd(+nand) using and development?
>  > >
>  > >  If such a list not exist i'll create it by my self and make it public
>  > > to you and the others. I know: It's MY work to do, I just not wanted to
>  > > do work twice.
>  >
>  > No such list exists, afaik.
>  Thank you. Thats what i wanted to know.
>
>
>  >  Generally people tend to either use the
>  > latest kernels or backport drivers/mtd/ and fs/jffs2/ along with any
>  > dependencies to their respective kernels.
>  >
>  > > Again, I'm sorry .. I hope, you understand the reason of my request.
>  >
>  > No worries.  This lists gets a fair share of both "my kernel is five
>  > years old, but I want all bugfixes and performance improvements from the
>  > newest code" and "can you provide free consulting".  Neither is greeted
>  > with much enthusiasm and your mail appeared to match both.
>  First of all: I'm not a leecher. I don't subscribed to this list to get
>  free support from you. That my first post was such a question was more
>  or less by chance.
>
>  Back to the list: I don't wanted this bug-list to build a 2.6.12 with
>  newest code.. I wanted this list to get an black on white impression of
>  the firmness of mtd over time. To see if there were some critical bugs
>  solved in near past. To see some statistical issues. If you think, such
>  an approach is stupid, it's your oppinion and i'll respect it, if you
>  give me some reasons..
>  Again: My interrest does not belong to solve only my current issues.. I
>  just wanted to get an impression of mtd over time.
>
>
>  >
>  > J?rn
>  >
>  respects
>         Manfred
>
>
>
>
>
>  ______________________________________________________
>  Linux MTD discussion mailing list
>  http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From joern at logfs.org  Fri Feb 29 10:26:18 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Fri, 29 Feb 2008 16:26:18 +0100
Subject: Global changelogs about
In-Reply-To: <1204276788.3593.17.camel@lisa.alm.archives.at>
References: <1204238252.3435.21.camel@lisa.alm.archives.at>
	<20080228235048.GA24195@lazybastard.org>
	<1204274577.3408.25.camel@lisa.alm.archives.at>
	<20080229085748.GB16507@lazybastard.org>
	<1204276788.3593.17.camel@lisa.alm.archives.at>
Message-ID: <20080229152617.GA19809@lazybastard.org>

On Fri, 29 February 2008 10:19:48 +0100, Schl?gl Manfred jun. wrote:
> 
> Back to the list: I don't wanted this bug-list to build a 2.6.12 with
> newest code.. I wanted this list to get an black on white impression of
> the firmness of mtd over time. To see if there were some critical bugs
> solved in near past. To see some statistical issues. If you think, such
> an approach is stupid, it's your oppinion and i'll respect it, if you
> give me some reasons..

Possibly the best approach would be to subscribe to the commit-list,
read all the patches and assess their meaning wrt. your list.  I can
send you my archive, reaching back to November 2006, if you want that.

It is a large amount of work and I doubt its practical use.  However,
an effort that forces people to think about code and learn something
cannot be completely useless.  So by all means, go wild! :)

J?rn

-- 
Geld macht nicht gl?cklich.
Gl?ck macht nicht satt.


From jimis at gmx.net  Fri Feb 29 12:29:53 2008
From: jimis at gmx.net (Dimitrios Apostolou)
Date: Fri, 29 Feb 2008 19:29:53 +0200
Subject: swap file over jffs2 partition
In-Reply-To: <20080229084345.GA16507@lazybastard.org>
References: <47C772E9.2000000@gmx.net> <20080229084345.GA16507@lazybastard.org>
Message-ID: <47C84111.6030103@gmx.net>

J?rn Engel wrote:
> On Fri, 29 February 2008 04:50:17 +0200, Dimitrios Apostolou wrote:
>> I intend to build a diskless linux system (root over NFS). Because it
>> has 1GB of embedded flash storage, I'm thinking of using this as swap 
>> (I've been bitten many times by the problems linux has with *no* 
>> swap...). And to avoid wearing out the flash storage too fast, I 'm 
>> thinking to format the 1GB partition as JFFS2, and create the swapfile 
>> on top of it.
>>
>> I'm not so experienced with JFFS and I don't know if it's too heavy for
>> the CPU, for swapping. Or if there are other issues I 'll face. What do
>> you think about it? Any other ways you 'd propose?
>>
>> Sorry for sending this at LKML but jffs-dev mailing list seems to be 
>> off. And JFFS is the only in-kernel filesystem that does wear-leveling, 
>> right?
> 
> Replying in reverse order...
> 
> The relevant mailing list is linux-mtd, added to Cc:.  JFFS and JFFS2
> are two different things, JFFS is older and was removed from the kernel
> not too long ago.

Thanks and sorry for intruding LKML. It seems that even wikipedia has 
wrong address for the mailing list, see the last link of the article:

http://en.wikipedia.org/wiki/JFFS2

> 
> The real fun comes not from CPU usage, but from interactions with the
> memory management subsystem.  In a nutshell, JFFS2 may require memory in
> order to write data.  When the system is under memory pressure, it needs
> JFFS2 to write out pages, which will try to allocate memory.  It is
> theoretically possible to deadlock the system in this way.

Interesting. I guess nobody has experimented with it yet so I'll try. 
Unfortunately it seems I'll face another problem, that JFFS2 doesn't 
support having a swap-file at all. Why would this happen? More info:

http://dev.laptop.org/ticket/6469

> 
> On the plus side, the write path of JFFS2 is relatively simple and
> extremely low-latency.  It shouldn't be too hard to review the code and
> handle all problem cases wrt. memory allocations.
> 
> One issue that is hard to solve is space reservation.  JFFS2 compresses
> data and allows users to write as long as there is space remaining.  It
> is possible to swap out data that compresses well, have some other
> process fill up the filesystem, then try to swap out data that
> compresses badly and get -ENOSPC in return.  As a system administrator
> you can prevent others from ever writing to JFFS2 - and you better do!

Of course! I intend to use all the 1GB of flash only for swap, the 
system will be practically diskless. And I don't think enabling 
compression for such a task would be wise.

> 
> J?rn
> 

Thanks for the help,
Dimitris


From gerickson at nuovations.com  Fri Feb 29 13:55:34 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Fri, 29 Feb 2008 10:55:34 -0800
Subject: Writing JFFS2 to Samsung K9F1208U0B NAND on AMCC PPC405EX/r
	Kilauea/Haleakala
In-Reply-To: <1204275029.3408.31.camel@lisa.alm.archives.at>
Message-ID: <C3ED9526.DB2F%gerickson@nuovations.com>

On 2/29/08 12:50 AM, Manfred jun. Schl?gl wrote:
> Am Donnerstag, den 28.02.2008, 16:30 -0800 schrieb Grant Erickson:
>> I am attempting to create and write a JFFS2 file system to the Samsung
>> K9F1208U0B NAND part on an AMCC PPC405EXr "Haleakala" board and seem to be
>> running into a hurdle or two.
>> 
>> Given the Samsung K9F1208U0B's 16 KiB erase block and 512 B page sizes, I
>> invoked mkfs.jffs2 with:
>> 
>> % mkfs.jffs2 -n -b -s 512 -e 16 KiB -d /export/haleakala -o haleakala.img
> 
>> I then erase the device with 'flash_eraseall' using the '-j' option:
>> 
>> # flash_eraseall -j /dev/mtd9
>> Erasing 16 Kibyte @ 3f94000 -- 99 % complete. Cleanmarker written at
>> 3f94000.
>> 
>> However, when I attempt to lay down the file system image with nandwrite
>> (again, using the '-j' option), I get a driver error:
>> 
>> # nandwrite -j /dev/mtd9 haleakala.img
>> MEMSETOOBSEL: Inappropriate ioctl for device
>> 
>> Eliding the '-j' option, I get errors about page alignment:
>> 
>> # nandwrite /dev/mtd9 haleakala.img
>> Input file is not page aligned
>> Data was only partially written due to error: Success

> You have to pad(-p) your image, so that it's size is a multiple of page
> size
> % mkfs.jffs2 -n -b -s 512 -p 512 -e 16 KiB -d /export/haleakala -o
> haleakala.img
> 
> Then you should be able to write it with:
> % nandwrite /dev/mtd9 haleakala.img
> 
> greetings
> manfred

Manfred:

Danke sch?n. Your suggestion of adding padding ('-p 512') along with
Andrey's suggestion to remove the deprecated '-j' options to flash_eraseall
and nandwrite did the trick:

# mount -t jffs2 /dev/mtdblock9 /import/
# df -h
Filesystem                Size      Used Available Use% Mounted on
...
/dev/mtdblock9           63.6M     14.4M     49.2M  23% /import

Regards,

Grant




From joern at logfs.org  Fri Feb 29 14:57:40 2008
From: joern at logfs.org (=?utf-8?B?SsO2cm4=?= Engel)
Date: Fri, 29 Feb 2008 20:57:40 +0100
Subject: swap file over jffs2 partition
In-Reply-To: <47C84111.6030103@gmx.net>
References: <47C772E9.2000000@gmx.net> <20080229084345.GA16507@lazybastard.org>
	<47C84111.6030103@gmx.net>
Message-ID: <20080229195740.GA24630@lazybastard.org>

On Fri, 29 February 2008 19:29:53 +0200, Dimitrios Apostolou wrote:
> 
> Thanks and sorry for intruding LKML. It seems that even wikipedia has 
> wrong address for the mailing list, see the last link of the article:
> 
> http://en.wikipedia.org/wiki/JFFS2

Fixed.  Not that I actually read the page and checked for other
errors...

> Interesting. I guess nobody has experimented with it yet so I'll try. 
> Unfortunately it seems I'll face another problem, that JFFS2 doesn't 
> support having a swap-file at all. Why would this happen? More info:
> 
> http://dev.laptop.org/ticket/6469

Yes, this still requires a bit of work.  Peter Zijlstra has a patch for
the memory-management side of it, someone has to fix up jffs2 as well.
I'll add support to logfs fairly soon.

> Of course! I intend to use all the 1GB of flash only for swap, the 
> system will be practically diskless. And I don't think enabling 
> compression for such a task would be wise.

It might, actually.  Assuming your average swap page compresses to 50%,
it means that you use half the bandwidth to flash and get twice the
lifetime before blocks wear out.  Whether the performance gets better or
worse depends on the relative speeds of your CPU and flash.

J?rn

-- 
Joern's library part 10:
http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx


From augulis.darius at gmail.com  Thu Feb 28 02:24:26 2008
From: augulis.darius at gmail.com (Darius)
Date: Thu, 28 Feb 2008 09:24:26 +0200
Subject: [PATCH] Boot XIP kernel for IMX
Message-ID: <fq5nlh$h6g$2@ger.gmane.org>

Adds possibility to boot XIP kernel from flash for IMX.
I have tested it with M9328MXLADS V2.0 board.
It does NOT support write to flash, it only does support booting xip 
kernel. Somebody can continue and make feature to have rw rootfs in the 
flash with XIP kernel together:)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-imx-xip-support-2.6.24.3
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20080228/0ba08b4a/attachment.ksh 

From gordonfarquharson at gmail.com  Fri Feb 29 01:45:29 2008
From: gordonfarquharson at gmail.com (Gordon Farquharson)
Date: Thu, 28 Feb 2008 23:45:29 -0700
Subject: [PATCH] [MTD] [NOR] Add support for the ST M29W400DT and
	M29W400DB flash chips
Message-ID: <97a0a9ac0802282245h65967c30lf7cb6e9f87c021b3@mail.gmail.com>

Hi Andrew

On Tue, Feb 26, 2008 at 2:39 PM, Gordon Farquharson
<gordonfarquharson at gmail.com> wrote:

>  Add support for the ST M29W400DB flash chip. which is used on the GLAN Tank NAS.
>
>  Signed-off-by: Gordon Farquharson <gordonfarquharson at gmail.com>

Thank you very much for including this patch in your -mm tree. During
my testing, I found that the unlock address in this patch must be
updated because jedec_table[] contains byte addresses [1]. My previous
patch worked with 2.6.23, but doesn't with 2.6.24 and 2.6.25-rc3. In
the updated patch (below), I have also added the top boot device
(M29W400DT) to the table for completeness, and cleaned up a some of
the formatting in the file.

It would be great if you could update the patch in your tree with the
patch below.

Thanks very much.

Gordon

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cec80bf2cc5283f2f00c34f474be857e5c9f6f65

---

Add support for the ST M29W400DT and M29W400DB flash chips. The latter
is used on the GLAN Tank NAS.

Signed-off-by: Gordon Farquharson <gordonfarquharson at gmail.com>

---

diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 4be51a8..00159f5 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -132,6 +132,8 @@
 #define M29F800AB	0x0058
 #define M29W800DT	0x00D7
 #define M29W800DB	0x005B
+#define M29W400DT	0x00EE
+#define M29W400DB	0x00EF
 #define M29W160DT	0x22C4
 #define M29W160DB	0x2249
 #define M29W040B	0x00E3
@@ -1426,7 +1428,7 @@ static const struct amd_flash_info jedec_table[] = {
 			ERASEINFO(0x08000,1),
 			ERASEINFO(0x10000,15),
 		}
-       }, {
+	}, {
 		.mfr_id		= MANUFACTURER_ST,	/* FIXME - CFI device? */
 		.dev_id		= M29W800DT,
 		.name		= "ST M29W800DT",
@@ -1456,6 +1458,36 @@ static const struct amd_flash_info jedec_table[] = {
 			ERASEINFO(0x08000,1),
 			ERASEINFO(0x10000,15)
 		}
+	},  {
+		.mfr_id         = MANUFACTURER_ST,
+		.dev_id         = M29W400DT,
+		.name           = "ST M29W400DT",
+		.devtypes       = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+		.uaddr          = MTD_UADDR_0x0AAA_0x0555,
+		.dev_size       = SIZE_512KiB,
+		.cmd_set        = P_ID_AMD_STD,
+		.nr_regions     = 4,
+		.regions        = {
+			ERASEINFO(0x04000,7),
+			ERASEINFO(0x02000,1),
+			ERASEINFO(0x08000,2),
+			ERASEINFO(0x10000,1)
+		}
+	}, {
+		.mfr_id         = MANUFACTURER_ST,
+		.dev_id         = M29W400DB,
+		.name           = "ST M29W400DB",
+		.devtypes       = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+		.uaddr          = MTD_UADDR_0x0AAA_0x0555,
+		.dev_size       = SIZE_512KiB,
+		.cmd_set        = P_ID_AMD_STD,
+		.nr_regions     = 4,
+		.regions        = {
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x02000,2),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x10000,7)
+		}
 	}, {
 		.mfr_id		= MANUFACTURER_ST,	/* FIXME - CFI device? */
 		.dev_id		= M29W160DT,
@@ -1486,7 +1518,7 @@ static const struct amd_flash_info jedec_table[] = {
 			ERASEINFO(0x08000,1),
 			ERASEINFO(0x10000,31)
 		}
-        }, {
+	}, {
 		.mfr_id		= MANUFACTURER_ST,
 		.dev_id		= M29W040B,
 		.name		= "ST M29W040B",
@@ -1498,7 +1530,7 @@ static const struct amd_flash_info jedec_table[] = {
 		.regions	= {
 			ERASEINFO(0x10000,8),
 		}
-        }, {
+	}, {
 		.mfr_id		= MANUFACTURER_ST,
 		.dev_id		= M50FW040,
 		.name		= "ST M50FW040",
@@ -1510,7 +1542,7 @@ static const struct amd_flash_info jedec_table[] = {
 		.regions	= {
 			ERASEINFO(0x10000,8),
 		}
-        }, {
+	}, {
 		.mfr_id		= MANUFACTURER_ST,
 		.dev_id		= M50FW080,
 		.name		= "ST M50FW080",
@@ -1522,7 +1554,7 @@ static const struct amd_flash_info jedec_table[] = {
 		.regions	= {
 			ERASEINFO(0x10000,16),
 		}
-        }, {
+	}, {
 		.mfr_id		= MANUFACTURER_ST,
 		.dev_id		= M50FW016,
 		.name		= "ST M50FW016",

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676


From yoush at cs.msu.su  Wed Feb 27 15:48:07 2008
From: yoush at cs.msu.su (Nikita V. Youshchenko)
Date: Wed, 27 Feb 2008 23:48:07 +0300
Subject: [PATCH] mtd: support for bit-reversed CFI cmd/query
Message-ID: <200802272348.13180@blacky.localdomain>

commit 049aa6336a85de3143a3dc9cb3f4c87ecc8896b3
Author: Nikita Youshchenko <yoush at cs.msu.su>
Date:   Wed Feb 27 20:25:22 2008 +0000

    mtd: support for bit-reversed CFI cmd/query
    
    Some embedded boards have flash chips connected with reversed bit order.
    Example for 16-bit width:
     chip D0 is bus D15
     chip D1 is bus D14
     ...
     chip D15 is bus D0
    It works perfectly for data access, however probing and issuing CFI commands
    for such chips require bit reversing. This patch adds support for this.
    
    Signed-off-by: Nikita Youshchenko <yoush at cs.msu.su>

diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
index 6d8f30d..0471cd0 100644
--- a/drivers/mtd/chips/Kconfig
+++ b/drivers/mtd/chips/Kconfig
@@ -57,7 +57,8 @@ config MTD_CFI_NOSWAP
 	  enabled, means that the CPU will not do any swapping; the chips
 	  are expected to be wired to the CPU in 'host-endian' form.
 	  Specific arrangements are possible with the BIG_ENDIAN_BYTE and
-	  LITTLE_ENDIAN_BYTE, if the bytes are reversed.
+	  LITTLE_ENDIAN_BYTE, if the bytes are reversed. Also it is possible
+	  to revert bit order in 'magic commands'.
 
 	  If you have a LART, on which the data (and address) lines were
 	  connected in a fashion which ensured that the nets were as short
@@ -72,6 +73,10 @@ config MTD_CFI_BE_BYTE_SWAP
 config MTD_CFI_LE_BYTE_SWAP
 	bool "LITTLE_ENDIAN_BYTE"
 
+config MTD_CFI_BIT_SWAP
+	bool "Reverse bit order"
+	select BITREVERSE
+
 endchoice
 
 config MTD_CFI_GEOMETRY
diff --git a/include/linux/mtd/cfi_endian.h b/include/linux/mtd/cfi_endian.h
index 25724f7..195edae 100644
--- a/include/linux/mtd/cfi_endian.h
+++ b/include/linux/mtd/cfi_endian.h
@@ -52,6 +52,24 @@
 #define cfi16_to_cpu(x) (x)
 #define cfi32_to_cpu(x) (x)
 #define cfi64_to_cpu(x) (x)
+#elif defined(CONFIG_MTD_CFI_BIT_SWAP)
+#include <linux/bitrev.h>
+#define cpu_to_cfi8(x) (x)
+#define cfi8_to_cpu(x) (x)
+#define cpu_to_cfi16(x) ({ u16 y = (x); \
+		           (bitrev8(y & 255) << 8) | bitrev8(y >> 8); \
+			})
+#define cfi16_to_cpu(x) ({ u16 y = (x); \
+		           (bitrev8(y & 255) << 8) | bitrev8(y >> 8); \
+			})
+#define cpu_to_cfi32(x) (x)
+#define cfi32_to_cpu(x) (x)
+#define cpu_to_cfi64(x) ({ u64 y = (x); \
+		           (bitrev32(y & 0xffffffff) << 32) | bitrev32(y >> 32); \
+			})
+#define cfi64_to_cpu(x) ({ u64 y = (x); \
+		           (bitrev32(y & 0xffffffff) << 32) | bitrev32(y >> 32); \
+			})
 #else
 #error No CFI endianness defined
 #endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080227/7a5f591d/attachment.bin