From computersforpeace at gmail.com  Wed Dec  1 01:11:50 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Tue, 30 Nov 2010 22:11:50 -0800
Subject: [PATCH 7/8] nandwrite: add check for negative blockalign
In-Reply-To: <AANLkTi==NGjgX38mUKfziKQAknmOJyZmB4Db3WPEh5MJ@mail.gmail.com>
References: <1291017722-23985-1-git-send-email-computersforpeace@gmail.com>
	<1291017722-23985-7-git-send-email-computersforpeace@gmail.com>
	<AANLkTi==NGjgX38mUKfziKQAknmOJyZmB4Db3WPEh5MJ@mail.gmail.com>
Message-ID: <4CF5E726.3010501@gmail.com>

On 11/29/2010 12:05 AM, Mike Frysinger wrote:
> On Mon, Nov 29, 2010 at 03:02, Brian Norris wrote:
>> +               errmsg_die("Can't specify a negative blockalign '%d'",
>> +                               blockalign);
> 
> personally, i'd avoid quotes on non-string types.  maybe also mention
> the command line option that is "blockalign" ?

I'm sending some "v2" patches related to these err messages. I'm not
sure what the best, descriptive messages are, but I tried.

Brian


From computersforpeace at gmail.com  Wed Dec  1 01:18:23 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Tue, 30 Nov 2010 22:18:23 -0800
Subject: [PATCH v2 5/8] nanddump: check for negative inputs
In-Reply-To: <1291017722-23985-5-git-send-email-computersforpeace@gmail.com>
References: <1291017722-23985-5-git-send-email-computersforpeace@gmail.com>
Message-ID: <1291184303-4596-1-git-send-email-computersforpeace@gmail.com>

Includes error messages for negative device offsets and negative lengths,
telling the user what the offending option and value were.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 nanddump.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/nanddump.c b/nanddump.c
index b0dd7dc..9f52878 100644
--- a/nanddump.c
+++ b/nanddump.c
@@ -173,6 +173,13 @@ static void process_options(int argc, char * const argv[])
 		}
 	}
 
+	if (start_addr < 0)
+		errmsg_die("Can't specify negative offset with option -s: %lld",
+				start_addr);
+
+	if (length < 0)
+		errmsg_die("Can't specify length with option -l: %lld", length);
+
 	if (quiet && pretty_print) {
 		fprintf(stderr, "The quiet and pretty print options are mutually-\n"
 				"exclusive. Choose one or the other.\n");
-- 
1.7.0.4




From computersforpeace at gmail.com  Wed Dec  1 01:19:44 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Tue, 30 Nov 2010 22:19:44 -0800
Subject: [PATCH v2 7/8] nandwrite: add check for negative blockalign
In-Reply-To: <1291017722-23985-7-git-send-email-computersforpeace@gmail.com>
References: <1291017722-23985-7-git-send-email-computersforpeace@gmail.com>
Message-ID: <1291184384-4665-1-git-send-email-computersforpeace@gmail.com>

Includes error messages for negative blockalign, telling the user what
the offending option and value were.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 nandwrite.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/nandwrite.c b/nandwrite.c
index 5373a89..2e45136 100644
--- a/nandwrite.c
+++ b/nandwrite.c
@@ -218,6 +218,10 @@ static void process_options(int argc, char * const argv[])
 		exit(EXIT_FAILURE);
 	}
 
+	if (blockalign < 0)
+		errmsg_die("Can't specify negative blockalign with option -b:"
+				" %d", blockalign);
+
 	argc -= optind;
 	argv += optind;
 
-- 
1.7.0.4




From computersforpeace at gmail.com  Wed Dec  1 01:20:46 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Tue, 30 Nov 2010 22:20:46 -0800
Subject: [PATCH v2 8/8] nandwrite: use common.h "errmsg_die"
In-Reply-To: <1291017722-23985-8-git-send-email-computersforpeace@gmail.com>
References: <1291017722-23985-8-git-send-email-computersforpeace@gmail.com>
Message-ID: <1291184446-4730-1-git-send-email-computersforpeace@gmail.com>

errmsg_die() should be nearly the equivalent of the error message used
here. This saves a few lines.

Also edited the error message to include the offending option and got
rid of the quotes.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 nandwrite.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/nandwrite.c b/nandwrite.c
index 2e45136..7f459cb 100644
--- a/nandwrite.c
+++ b/nandwrite.c
@@ -212,11 +212,9 @@ static void process_options(int argc, char * const argv[])
 		}
 	}
 
-	if (mtdoffset < 0) {
-		fprintf(stderr, "Can't specify a negative device offset `%lld'\n",
-				mtdoffset);
-		exit(EXIT_FAILURE);
-	}
+	if (mtdoffset < 0)
+		errmsg_die("Can't specify negative device offset with option"
+				" -s: %lld", mtdoffset);
 
 	if (blockalign < 0)
 		errmsg_die("Can't specify negative blockalign with option -b:"
-- 
1.7.0.4




From computersforpeace at gmail.com  Wed Dec  1 02:12:30 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Tue, 30 Nov 2010 23:12:30 -0800
Subject: [PATCH v3 5/8] nanddump: check for negative inputs
In-Reply-To: <1291184303-4596-1-git-send-email-computersforpeace@gmail.com>
References: <1291184303-4596-1-git-send-email-computersforpeace@gmail.com>
Message-ID: <1291187550-17545-1-git-send-email-computersforpeace@gmail.com>

Includes error messages for negative device offsets and negative lengths,
telling the user what the offending option and value were.

Previous patch left out the "negative" in the error message.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 nanddump.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/nanddump.c b/nanddump.c
index b0dd7dc..6a6f904 100644
--- a/nanddump.c
+++ b/nanddump.c
@@ -173,6 +173,13 @@ static void process_options(int argc, char * const argv[])
 		}
 	}
 
+	if (start_addr < 0)
+		errmsg_die("Can't specify negative offset with option -s: %lld",
+				start_addr);
+
+	if (length < 0)
+		errmsg_die("Can't specify negative length with option -l: %lld", length);
+
 	if (quiet && pretty_print) {
 		fprintf(stderr, "The quiet and pretty print options are mutually-\n"
 				"exclusive. Choose one or the other.\n");
-- 
1.7.0.4




From agust at denx.de  Wed Dec  1 04:38:07 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 1 Dec 2010 10:38:07 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101130163541.44c48a94@wker>
References: <20101129195014.19224240@wker> <4CF4D4CA.8040906@aimvalley.nl>
	<20101130163541.44c48a94@wker>
Message-ID: <20101201103807.1e432cfb@wker>

On Tue, 30 Nov 2010 16:35:41 +0100
Anatolij Gustschin <agust at denx.de> wrote:
...
> On Tue, 30 Nov 2010 11:41:14 +0100
> Norbert van Bolhuis <nvbolhuis at aimvalley.nl> wrote:
> 
> > Did you read the mail discussions
> > "UBIFS Corrupt during power failure"
> > dated april 2009 from Eric Holmberg.
> > 
> > He did some great work in making UBIFS on NOR flash
> > more reliable for power-cuts.
> 
> I have partially read the thread "UBIFS Corrupt during power 
> failure", especially the discussion from March, May, June and July
> 2009 but not the whole discussion from April.
> 
> > One of the problems was UBI/UBIFS assumes a (CFI) write
> > buffer size of 8 bytes. Maybe this is still the case.
> > I think for your NOR flash it is 64 bytes though.
> 
> Thanks for the hint!
> 
> Yes, I remember Eric saying that he used 8 byte write buffers but
> still had some failures. Therefore I didn't try to reduce the write
> buffer size up to now. But these problems seem to be fixed meanwhile.
> 
> The write buffer size used in the CFI driver is indeed 64 bytes. Now
> I'm running the tests with write buffer size reduced to 8 bytes and
> it looks much better now. After 295 test cycles I haven't seen the
> issue so far.

Further testing with a CFI 8 byte write buffer shows that there are
other issues. Now we end up with the corrupted VID header and cannot
attach the MTD device. I'm going to send the debug log to the list.

Thanks,
Anatolij

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From nvbolhuis at aimvalley.nl  Wed Dec  1 04:47:01 2010
From: nvbolhuis at aimvalley.nl (Norbert van Bolhuis)
Date: Wed, 01 Dec 2010 10:47:01 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
References: <20101129195014.19224240@wker>	<4CF4D4CA.8040906@aimvalley.nl>	<20101130163541.44c48a94@wker>
	<AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
Message-ID: <4CF61995.9080609@aimvalley.nl>

boaz ben david wrote:
> Sorry to bump the thread but I'm having issues which I think are similiar
> with MLC NAND flash.
> Will reducing the write buffer help here too?
> 
> Thanks.
> 
> Boaz.
> 


no.
The CFI write buffer size is an attribute specific for NOR flash only.

---
N. van Bolhuis


From agust at denx.de  Wed Dec  1 04:55:18 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 1 Dec 2010 10:55:18 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
References: <20101129195014.19224240@wker> <4CF4D4CA.8040906@aimvalley.nl>
	<20101130163541.44c48a94@wker>
	<AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
Message-ID: <20101201105518.206635e6@wker>

On Tue, 30 Nov 2010 20:18:56 +0200
boaz ben david <boazbd at gmail.com> wrote:

> Sorry to bump the thread but I'm having issues which I think are similiar
> with MLC NAND flash.
> Will reducing the write buffer help here too?

I don't know. Your issues may look similar but without
knowing the details it is not possible to say. Most
probably no. I reduced the write buffer size in the CFI
driver. The issues we observed seem to be NOR flash
specific.

Best regards,
Anatolij


From agust at denx.de  Wed Dec  1 07:05:34 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 1 Dec 2010 13:05:34 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101129195014.19224240@wker>
References: <20101129195014.19224240@wker>
Message-ID: <20101201130534.5b95ce83@wker>

Hi,

On Mon, 29 Nov 2010 19:50:14 +0100
Anatolij Gustschin <agust at denx.de> wrote:
...
> The power failure test is simulated by triggering an external reset
> of the board while a simple program is writing data into a file on
> the UBIFS partition. Each test cycle consists of the following steps:
> 
>  - booting the kernel
>  - attaching the MTD device
>  - mounting the UBIFS partition
>  - starting a program for writing the test data into a file on the
>    mounted UBIFS partition (only if mounting of this partition
>    succeeded)
>  - triggering a reset after about 15 sec.
> 
> After a number of test cycles we end up with corrupted partition
> which cannot be recovered any more and mounting the partition
> does not succeed.

So, reducing the write buffer size to 8 bytes seem to be
first quick solution for the problem observed. The problem
didn't show up so far, but after approximately 1500 test
cycles another issue appeared: it is not possible to attach
the MTD device now. The kernel log is included below (note,
the hexdump of the trailing part of the PEB #39 containing
0xff is trimmed).

UBI DBG (pid 1284): ctrl_cdev_ioctl: attach MTD device
UBI: attaching mtd5 to ubi0
UBI DBG (pid 1284): io_init: min_io_size      1
UBI DBG (pid 1284): io_init: hdrs_min_io_size 1
UBI DBG (pid 1284): io_init: ec_hdr_alsize    64
UBI DBG (pid 1284): io_init: vid_hdr_alsize   64
UBI DBG (pid 1284): io_init: vid_hdr_offset   64
UBI DBG (pid 1284): io_init: vid_hdr_aloffset 64
UBI DBG (pid 1284): io_init: vid_hdr_shift    0
UBI DBG (pid 1284): io_init: leb_start        128
UBI DBG (pid 1284): io_init: max_erroneous    20
UBI: physical eraseblock size:   262144 bytes (256 KiB)
UBI: logical eraseblock size:    262016 bytes
UBI: smallest flash I/O unit:    1
UBI: VID header offset:          64 (aligned 64)
UBI: data offset:                128
UBI DBG (pid 1284): ubi_scan: process PEB 0
UBI DBG (pid 1284): process_eb: scan PEB 0
UBI DBG (pid 1284): ubi_scan_add_used: PEB 0, LEB 0:39, EC 69, sqnum 13113, bitflips 0
UBI DBG (pid 1284): add_volume: added volume 0
UBI DBG (pid 1284): ubi_scan: process PEB 1
UBI DBG (pid 1284): process_eb: scan PEB 1
UBI DBG (pid 1284): ubi_scan_add_used: PEB 1, LEB 0:30, EC 115, sqnum 12939, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 2
UBI DBG (pid 1284): process_eb: scan PEB 2
UBI DBG (pid 1284): ubi_scan_add_used: PEB 2, LEB 0:23, EC 60, sqnum 13101, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 3
UBI DBG (pid 1284): process_eb: scan PEB 3
UBI DBG (pid 1284): ubi_scan_add_used: PEB 3, LEB 0:35, EC 105, sqnum 13096, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 4
UBI DBG (pid 1284): process_eb: scan PEB 4
UBI DBG (pid 1284): ubi_scan_add_used: PEB 4, LEB 0:20, EC 84, sqnum 12664, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 5
UBI DBG (pid 1284): process_eb: scan PEB 5
UBI DBG (pid 1284): ubi_scan_add_used: PEB 5, LEB 0:34, EC 66, sqnum 13104, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 6
UBI DBG (pid 1284): process_eb: scan PEB 6
UBI DBG (pid 1284): ubi_scan_add_used: PEB 6, LEB 0:26, EC 57, sqnum 13109, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 7
UBI DBG (pid 1284): process_eb: scan PEB 7
UBI DBG (pid 1284): ubi_scan_add_used: PEB 7, LEB 0:17, EC 61, sqnum 13102, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 8
UBI DBG (pid 1284): process_eb: scan PEB 8
UBI DBG (pid 1284): ubi_scan_add_used: PEB 8, LEB 0:15, EC 96, sqnum 13073, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 9
UBI DBG (pid 1284): process_eb: scan PEB 9
UBI DBG (pid 1284): ubi_scan_add_used: PEB 9, LEB 0:7, EC 0, sqnum 0, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 10
UBI DBG (pid 1284): process_eb: scan PEB 10
UBI DBG (pid 1284): ubi_scan_add_used: PEB 10, LEB 0:37, EC 128, sqnum 13097, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 11
UBI DBG (pid 1284): process_eb: scan PEB 11
UBI DBG (pid 1284): ubi_scan_add_used: PEB 11, LEB 0:13, EC 71, sqnum 7046, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 12
UBI DBG (pid 1284): process_eb: scan PEB 12
UBI DBG (pid 1284): ubi_scan_add_used: PEB 12, LEB 0:10, EC 0, sqnum 0, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 13
UBI DBG (pid 1284): process_eb: scan PEB 13
UBI DBG (pid 1284): ubi_scan_add_used: PEB 13, LEB 0:4, EC 58, sqnum 13108, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 14
UBI DBG (pid 1284): process_eb: scan PEB 14
UBI DBG (pid 1284): ubi_scan_add_used: PEB 14, LEB 0:12, EC 0, sqnum 0, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 15
UBI DBG (pid 1284): process_eb: scan PEB 15
UBI DBG (pid 1284): ubi_scan_add_used: PEB 15, LEB 2147479551:0, EC 1, sqnum 1, bitflips 0
UBI DBG (pid 1284): add_volume: added volume 2147479551
UBI DBG (pid 1284): ubi_scan: process PEB 16
UBI DBG (pid 1284): process_eb: scan PEB 16
UBI DBG (pid 1284): ubi_scan_add_used: PEB 16, LEB 2147479551:1, EC 1, sqnum 2, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 17
UBI DBG (pid 1284): process_eb: scan PEB 17
UBI DBG (pid 1284): ubi_scan_add_used: PEB 17, LEB 0:27, EC 97, sqnum 13075, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 18
UBI DBG (pid 1284): process_eb: scan PEB 18
UBI DBG (pid 1284): ubi_scan_add_used: PEB 18, LEB 0:31, EC 58, sqnum 13100, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 19
UBI DBG (pid 1284): process_eb: scan PEB 19
UBI DBG (pid 1284): ubi_scan_add_used: PEB 19, LEB 0:22, EC 85, sqnum 13119, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 20
UBI DBG (pid 1284): process_eb: scan PEB 20
UBI DBG (pid 1284): ubi_scan_add_used: PEB 20, LEB 0:0, EC 1, sqnum 3, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 21
UBI DBG (pid 1284): process_eb: scan PEB 21
UBI DBG (pid 1284): ubi_scan_add_used: PEB 21, LEB 0:14, EC 90, sqnum 13092, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 22
UBI DBG (pid 1284): process_eb: scan PEB 22
UBI DBG (pid 1284): ubi_scan_add_used: PEB 22, LEB 0:22, EC 83, sqnum 13095, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 19, sqnum 13119, EC 85
UBI DBG (pid 1284): compare_lebs: first PEB 22 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 22, EC 83
UBI DBG (pid 1284): ubi_scan: process PEB 23
UBI DBG (pid 1284): process_eb: scan PEB 23
UBI DBG (pid 1284): ubi_scan_add_used: PEB 23, LEB 0:39, EC 71, sqnum 13089, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 23 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 23, EC 71
UBI DBG (pid 1284): ubi_scan: process PEB 24
UBI DBG (pid 1284): process_eb: scan PEB 24
UBI DBG (pid 1284): ubi_scan_add_used: PEB 24, LEB 0:32, EC 71, sqnum 13114, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 25
UBI DBG (pid 1284): process_eb: scan PEB 25
UBI DBG (pid 1284): ubi_scan_add_used: PEB 25, LEB 0:11, EC 58, sqnum 7343, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 26
UBI DBG (pid 1284): process_eb: scan PEB 26
UBI DBG (pid 1284): ubi_scan_add_used: PEB 26, LEB 0:21, EC 71, sqnum 13090, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 27
UBI DBG (pid 1284): process_eb: scan PEB 27
UBI DBG (pid 1284): ubi_scan_add_used: PEB 27, LEB 0:41, EC 63, sqnum 13032, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 28
UBI DBG (pid 1284): process_eb: scan PEB 28
UBI DBG (pid 1284): ubi_scan_add_used: PEB 28, LEB 0:40, EC 63, sqnum 13103, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 29
UBI DBG (pid 1284): process_eb: scan PEB 29
UBI DBG (pid 1284): ubi_scan_add_used: PEB 29, LEB 0:18, EC 69, sqnum 12937, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 30
UBI DBG (pid 1284): process_eb: scan PEB 30
UBI DBG (pid 1284): ubi_scan_add_used: PEB 30, LEB 0:5, EC 78, sqnum 13074, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 31
UBI DBG (pid 1284): process_eb: scan PEB 31
UBI DBG (pid 1284): ubi_scan_add_used: PEB 31, LEB 0:25, EC 94, sqnum 13093, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 32
UBI DBG (pid 1284): process_eb: scan PEB 32
UBI DBG (pid 1284): ubi_scan_add_used: PEB 32, LEB 0:16, EC 89, sqnum 13025, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 33
UBI DBG (pid 1284): process_eb: scan PEB 33
UBI DBG (pid 1284): ubi_scan_add_used: PEB 33, LEB 0:28, EC 97, sqnum 13094, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 34
UBI DBG (pid 1284): process_eb: scan PEB 34
UBI DBG (pid 1284): ubi_scan_add_used: PEB 34, LEB 0:36, EC 71, sqnum 13106, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 35
UBI DBG (pid 1284): process_eb: scan PEB 35
UBI DBG (pid 1284): ubi_scan_add_used: PEB 35, LEB 0:33, EC 78, sqnum 13091, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 36
UBI DBG (pid 1284): process_eb: scan PEB 36
UBI DBG (pid 1284): ubi_scan_add_used: PEB 36, LEB 0:25, EC 76, sqnum 13118, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 31, sqnum 13093, EC 94
UBI DBG (pid 1284): compare_lebs: second PEB 36 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 31, EC 94
UBI DBG (pid 1284): ubi_scan: process PEB 37
UBI DBG (pid 1284): process_eb: scan PEB 37
UBI DBG (pid 1284): ubi_scan_add_used: PEB 37, LEB 0:29, EC 70, sqnum 13105, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 38
UBI DBG (pid 1284): process_eb: scan PEB 38
UBI DBG (pid 1284): ubi_scan_add_used: PEB 38, LEB 0:38, EC 63, sqnum 13107, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 39
UBI DBG (pid 1284): process_eb: scan PEB 39
UBI DBG (pid 1284): ubi_io_read_vid_hdr: bad magic number at PEB 39: 00000000 instead of 55424921
UBI error: check_corruption: PEB 39 contains corrupted VID header, and the data does not contain all 0xFF, this may be a non-UBI PEB or a severe VID header corruption which requires manual inspection
Volume identifier header dump:
	magic     00000000
	version   1
	vol_type  1
	copy_flag 0
	compat    0
	vol_id    0
	lnum      3
	data_size 0
	used_ebs  0
	data_pad  0
	sqnum     13050
	hdr_crc   26036a6e
Volume identifier header hexdump:
00000000: 00 00 00 00 01 01 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 32 fa 00 00 00 00 00 00 00 00 00 00 00 00 26 03 6a 6e  ..............2.............&.jn
UBI DBG (pid 1284): check_corruption: hexdump of PEB 39 offset 128, length 262016
00000000: 31 18 10 06 e3 e5 ed bf 73 92 16 00 00 00 00 00 20 00 00 00 0a 00 00 00 40 04 00 00 00 00 00 00  1.......s....... ....... at .......
00000020: 31 18 10 06 8b 01 d7 0b 74 92 16 00 00 00 00 00 40 00 00 00 08 00 00 00 29 00 00 00 b8 91 02 00  1.......t....... at .......).......
00000040: 01 00 00 00 00 00 00 0a 00 01 0a 90 00 00 00 5b 00 00 00 01 4b a9 90 10 c7 71 0b a0 00 00 00 0a  ...............[....K....q......
00000060: 31 18 10 06 98 31 db 12 75 92 16 00 00 00 00 00 40 00 00 00 08 00 00 00 22 00 00 00 d0 fb 03 00  1....1..u....... at .......".......
00000080: 02 00 00 00 5d a8 bd 01 00 00 00 00 00 00 00 0a 00 01 06 78 00 00 00 40 00 00 00 00 00 00 00 00  ....]..............x... at ........
000000a0: 31 18 10 06 cc c7 0e aa d9 92 16 00 00 00 00 00 40 00 00 00 08 00 00 00 1b 00 00 00 00 00 00 00  1............... at ...............
000000c0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
000000e0: 31 18 10 06 5c fd 18 54 58 93 16 00 00 00 00 00 40 00 00 00 08 00 00 00 1f 00 00 00 00 00 00 00  1...\..TX....... at ...............
00000100: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000120: 31 18 10 06 b6 40 29 83 d7 93 16 00 00 00 00 00 40 00 00 00 08 00 00 00 17 00 00 00 00 00 00 00  1....@)......... at ...............
00000140: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000160: 31 18 10 06 89 f2 ce 34 56 94 16 00 00 00 00 00 40 00 00 00 08 00 00 00 11 00 00 00 00 00 00 00  1......4V....... at ...............
00000180: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
000001a0: 31 18 10 06 83 0e 1f 10 d5 94 16 00 00 00 00 00 40 00 00 00 08 00 00 00 28 00 00 00 00 00 00 00  1............... at .......(.......
000001c0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
000001e0: 31 18 10 06 17 a4 15 87 54 95 16 00 00 00 00 00 40 00 00 00 08 00 00 00 1d 00 00 00 00 00 00 00  1.......T....... at ...............
00000200: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000220: 31 18 10 06 41 17 90 d5 d3 95 16 00 00 00 00 00 40 00 00 00 08 00 00 00 24 00 00 00 00 00 00 00  1...A........... at .......$.......
00000240: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000260: 31 18 10 06 e1 2a f8 3a 52 96 16 00 00 00 00 00 40 00 00 00 08 00 00 00 26 00 00 00 00 00 00 00  1....*.:R....... at .......&.......
00000280: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
000002a0: 31 18 10 06 bc 25 14 e4 d1 96 16 00 00 00 00 00 40 00 00 00 08 00 00 00 18 00 00 00 00 00 00 00  1....%.......... at ...............
000002c0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
000002e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
00000300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
*
0003ff40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0003ff60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
UBI DBG (pid 1284): add_corrupted: add to corrupted: PEB 39, EC 103
UBI DBG (pid 1284): ubi_scan: process PEB 40
UBI DBG (pid 1284): process_eb: scan PEB 40
UBI DBG (pid 1284): ubi_scan_add_used: PEB 40, LEB 0:33, EC 71, sqnum 13116, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 35, sqnum 13091, EC 78
UBI DBG (pid 1284): compare_lebs: second PEB 40 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 35, EC 78
UBI DBG (pid 1284): ubi_scan: process PEB 41
UBI DBG (pid 1284): process_eb: scan PEB 41
UBI DBG (pid 1284): ubi_scan_add_used: PEB 41, LEB 0:21, EC 59, sqnum 13115, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 26, sqnum 13090, EC 71
UBI DBG (pid 1284): compare_lebs: second PEB 41 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 26, EC 71
UBI DBG (pid 1284): ubi_scan: process PEB 42
UBI DBG (pid 1284): process_eb: scan PEB 42
UBI DBG (pid 1284): ubi_scan_add_used: PEB 42, LEB 0:2, EC 60, sqnum 12221, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 43
UBI DBG (pid 1284): process_eb: scan PEB 43
UBI DBG (pid 1284): ubi_scan_add_used: PEB 43, LEB 0:14, EC 71, sqnum 13117, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 21, sqnum 13092, EC 90
UBI DBG (pid 1284): compare_lebs: second PEB 43 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 21, EC 90
UBI DBG (pid 1284): ubi_scan: process PEB 44
UBI DBG (pid 1284): process_eb: scan PEB 44
UBI DBG (pid 1284): ubi_io_read_vid_hdr: no VID header found at PEB 44, only 0xFF bytes
UBI DBG (pid 1284): add_to_list: add to free: PEB 44, EC 66
UBI DBG (pid 1284): ubi_scan: process PEB 45
UBI DBG (pid 1284): process_eb: scan PEB 45
UBI DBG (pid 1284): ubi_scan_add_used: PEB 45, LEB 0:3, EC 68, sqnum 13098, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 46
UBI DBG (pid 1284): process_eb: scan PEB 46
UBI DBG (pid 1284): ubi_scan_add_used: PEB 46, LEB 0:19, EC 64, sqnum 13112, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 47
UBI DBG (pid 1284): process_eb: scan PEB 47
UBI DBG (pid 1284): ubi_scan_add_used: PEB 47, LEB 0:15, EC 57, sqnum 13099, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 8, sqnum 13073, EC 96
UBI DBG (pid 1284): compare_lebs: second PEB 47 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 8, EC 96
UBI DBG (pid 1284): ubi_scan: process PEB 48
UBI DBG (pid 1284): process_eb: scan PEB 48
UBI DBG (pid 1284): ubi_scan_add_used: PEB 48, LEB 0:19, EC 58, sqnum 13084, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 48 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 48, EC 58
UBI DBG (pid 1284): ubi_scan: process PEB 49
UBI DBG (pid 1284): process_eb: scan PEB 49
UBI DBG (pid 1284): ubi_scan_add_used: PEB 49, LEB 0:6, EC 58, sqnum 13085, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 50
UBI DBG (pid 1284): process_eb: scan PEB 50
UBI DBG (pid 1284): ubi_scan_add_used: PEB 50, LEB 0:1, EC 57, sqnum 12220, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 51
UBI DBG (pid 1284): process_eb: scan PEB 51
UBI DBG (pid 1284): ubi_scan_add_used: PEB 51, LEB 0:41, EC 57, sqnum 13110, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 27, sqnum 13032, EC 63
UBI DBG (pid 1284): compare_lebs: second PEB 51 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 27, EC 63
UBI DBG (pid 1284): ubi_scan: process PEB 52
UBI DBG (pid 1284): process_eb: scan PEB 52
UBI DBG (pid 1284): ubi_scan_add_used: PEB 52, LEB 0:26, EC 57, sqnum 13086, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 52 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 52, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 53
UBI DBG (pid 1284): process_eb: scan PEB 53
UBI DBG (pid 1284): ubi_scan_add_used: PEB 53, LEB 0:24, EC 61, sqnum 13111, bitflips 0
UBI DBG (pid 1284): ubi_scan: process PEB 54
UBI DBG (pid 1284): process_eb: scan PEB 54
UBI DBG (pid 1284): ubi_scan_add_used: PEB 54, LEB 0:4, EC 58, sqnum 13061, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 54 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 54, EC 58
UBI DBG (pid 1284): ubi_scan: process PEB 55
UBI DBG (pid 1284): process_eb: scan PEB 55
UBI DBG (pid 1284): ubi_scan_add_used: PEB 55, LEB 0:24, EC 66, sqnum 13088, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 55 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 55, EC 66
UBI DBG (pid 1284): ubi_scan: process PEB 56
UBI DBG (pid 1284): process_eb: scan PEB 56
UBI DBG (pid 1284): ubi_scan_add_used: PEB 56, LEB 0:25, EC 64, sqnum 13067, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 56 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 56, EC 64
UBI DBG (pid 1284): ubi_scan: process PEB 57
UBI DBG (pid 1284): process_eb: scan PEB 57
UBI DBG (pid 1284): ubi_scan_add_used: PEB 57, LEB 0:32, EC 58, sqnum 13063, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 24, sqnum 13114, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 57 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 57, EC 58
UBI DBG (pid 1284): ubi_scan: process PEB 58
UBI DBG (pid 1284): process_eb: scan PEB 58
UBI DBG (pid 1284): ubi_scan_add_used: PEB 58, LEB 0:31, EC 57, sqnum 13076, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 58 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 58, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 59
UBI DBG (pid 1284): process_eb: scan PEB 59
UBI DBG (pid 1284): ubi_scan_add_used: PEB 59, LEB 0:41, EC 57, sqnum 13087, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 51, sqnum 13110, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 59 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 59, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 60
UBI DBG (pid 1284): process_eb: scan PEB 60
UBI DBG (pid 1284): ubi_io_read_ec_hdr: no EC header found at PEB 60, only 0xFF bytes
UBI DBG (pid 1284): add_to_list: add to erase: PEB 60, EC -1
UBI DBG (pid 1284): ubi_scan: process PEB 61
UBI DBG (pid 1284): process_eb: scan PEB 61
UBI DBG (pid 1284): ubi_scan_add_used: PEB 61, LEB 0:40, EC 55, sqnum 6127, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 28, sqnum 13103, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 61 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 61, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 62
UBI DBG (pid 1284): process_eb: scan PEB 62
UBI DBG (pid 1284): ubi_scan_add_used: PEB 62, LEB 0:14, EC 58, sqnum 5577, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 43, sqnum 13117, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 62 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 62, EC 58
UBI DBG (pid 1284): ubi_scan: process PEB 63
UBI DBG (pid 1284): process_eb: scan PEB 63
UBI DBG (pid 1284): ubi_scan_add_used: PEB 63, LEB 0:19, EC 57, sqnum 5528, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 63 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 63, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 64
UBI DBG (pid 1284): process_eb: scan PEB 64
UBI DBG (pid 1284): ubi_scan_add_used: PEB 64, LEB 0:35, EC 54, sqnum 5597, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 3, sqnum 13096, EC 105
UBI DBG (pid 1284): compare_lebs: first PEB 64 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 64, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 65
UBI DBG (pid 1284): process_eb: scan PEB 65
UBI DBG (pid 1284): ubi_scan_add_used: PEB 65, LEB 0:36, EC 54, sqnum 5578, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 65 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 65, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 66
UBI DBG (pid 1284): process_eb: scan PEB 66
UBI DBG (pid 1284): ubi_scan_add_used: PEB 66, LEB 0:39, EC 57, sqnum 5531, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 66 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 66, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 67
UBI DBG (pid 1284): process_eb: scan PEB 67
UBI DBG (pid 1284): ubi_scan_add_used: PEB 67, LEB 0:3, EC 57, sqnum 5534, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 45, sqnum 13098, EC 68
UBI DBG (pid 1284): compare_lebs: first PEB 67 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 67, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 68
UBI DBG (pid 1284): process_eb: scan PEB 68
UBI DBG (pid 1284): ubi_scan_add_used: PEB 68, LEB 0:37, EC 58, sqnum 5581, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 10, sqnum 13097, EC 128
UBI DBG (pid 1284): compare_lebs: first PEB 68 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 68, EC 58
UBI DBG (pid 1284): ubi_scan: process PEB 69
UBI DBG (pid 1284): process_eb: scan PEB 69
UBI DBG (pid 1284): ubi_io_read_ec_hdr: no EC header found at PEB 69, only 0xFF bytes
UBI DBG (pid 1284): add_to_list: add to erase: PEB 69, EC -1
UBI DBG (pid 1284): ubi_scan: process PEB 70
UBI DBG (pid 1284): process_eb: scan PEB 70
UBI DBG (pid 1284): ubi_scan_add_used: PEB 70, LEB 0:20, EC 56, sqnum 5491, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 70 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 70, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 71
UBI DBG (pid 1284): process_eb: scan PEB 71
UBI DBG (pid 1284): ubi_scan_add_used: PEB 71, LEB 0:29, EC 56, sqnum 5492, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 71 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 71, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 72
UBI DBG (pid 1284): process_eb: scan PEB 72
UBI DBG (pid 1284): ubi_scan_add_used: PEB 72, LEB 0:19, EC 55, sqnum 5555, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 72 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 72, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 73
UBI DBG (pid 1284): process_eb: scan PEB 73
UBI DBG (pid 1284): ubi_scan_add_used: PEB 73, LEB 0:5, EC 56, sqnum 5508, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 30, sqnum 13074, EC 78
UBI DBG (pid 1284): compare_lebs: first PEB 73 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 73, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 74
UBI DBG (pid 1284): process_eb: scan PEB 74
UBI DBG (pid 1284): ubi_scan_add_used: PEB 74, LEB 0:35, EC 57, sqnum 5543, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 3, sqnum 13096, EC 105
UBI DBG (pid 1284): compare_lebs: first PEB 74 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 74, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 75
UBI DBG (pid 1284): process_eb: scan PEB 75
UBI DBG (pid 1284): ubi_scan_add_used: PEB 75, LEB 0:23, EC 56, sqnum 5510, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 75 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 75, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 76
UBI DBG (pid 1284): process_eb: scan PEB 76
UBI DBG (pid 1284): ubi_scan_add_used: PEB 76, LEB 0:38, EC 55, sqnum 5461, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 76 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 76, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 77
UBI DBG (pid 1284): process_eb: scan PEB 77
UBI DBG (pid 1284): ubi_scan_add_used: PEB 77, LEB 0:28, EC 57, sqnum 5544, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 33, sqnum 13094, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 77 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 77, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 78
UBI DBG (pid 1284): process_eb: scan PEB 78
UBI DBG (pid 1284): ubi_scan_add_used: PEB 78, LEB 0:4, EC 56, sqnum 5496, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 78 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 78, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 79
UBI DBG (pid 1284): process_eb: scan PEB 79
UBI DBG (pid 1284): ubi_scan_add_used: PEB 79, LEB 0:4, EC 57, sqnum 5546, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 79 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 79, EC 57
UBI DBG (pid 1284): ubi_scan: process PEB 80
UBI DBG (pid 1284): process_eb: scan PEB 80
UBI DBG (pid 1284): ubi_scan_add_used: PEB 80, LEB 0:34, EC 54, sqnum 5547, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 5, sqnum 13104, EC 66
UBI DBG (pid 1284): compare_lebs: first PEB 80 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 80, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 81
UBI DBG (pid 1284): process_eb: scan PEB 81
UBI DBG (pid 1284): ubi_scan_add_used: PEB 81, LEB 0:17, EC 56, sqnum 5502, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 7, sqnum 13102, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 81 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 81, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 82
UBI DBG (pid 1284): process_eb: scan PEB 82
UBI DBG (pid 1284): ubi_scan_add_used: PEB 82, LEB 0:19, EC 56, sqnum 5503, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 82 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 82, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 83
UBI DBG (pid 1284): process_eb: scan PEB 83
UBI DBG (pid 1284): ubi_scan_add_used: PEB 83, LEB 0:37, EC 56, sqnum 5504, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 10, sqnum 13097, EC 128
UBI DBG (pid 1284): compare_lebs: first PEB 83 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 83, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 84
UBI DBG (pid 1284): process_eb: scan PEB 84
UBI DBG (pid 1284): ubi_scan_add_used: PEB 84, LEB 0:25, EC 54, sqnum 5521, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 84 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 84, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 85
UBI DBG (pid 1284): process_eb: scan PEB 85
UBI DBG (pid 1284): ubi_scan_add_used: PEB 85, LEB 0:39, EC 54, sqnum 5355, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 85 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 85, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 86
UBI DBG (pid 1284): process_eb: scan PEB 86
UBI DBG (pid 1284): ubi_scan_add_used: PEB 86, LEB 0:21, EC 56, sqnum 5505, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 41, sqnum 13115, EC 59
UBI DBG (pid 1284): compare_lebs: first PEB 86 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 86, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 87
UBI DBG (pid 1284): process_eb: scan PEB 87
UBI DBG (pid 1284): ubi_scan_add_used: PEB 87, LEB 0:18, EC 56, sqnum 5506, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 29, sqnum 12937, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 87 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 87, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 88
UBI DBG (pid 1284): process_eb: scan PEB 88
UBI DBG (pid 1284): ubi_scan_add_used: PEB 88, LEB 0:38, EC 56, sqnum 5511, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 88 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 88, EC 56
UBI DBG (pid 1284): ubi_scan: process PEB 89
UBI DBG (pid 1284): process_eb: scan PEB 89
UBI DBG (pid 1284): ubi_scan_add_used: PEB 89, LEB 0:4, EC 55, sqnum 5447, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 89 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 89, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 90
UBI DBG (pid 1284): process_eb: scan PEB 90
UBI DBG (pid 1284): ubi_scan_add_used: PEB 90, LEB 0:27, EC 54, sqnum 5497, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 90 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 90, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 91
UBI DBG (pid 1284): process_eb: scan PEB 91
UBI DBG (pid 1284): ubi_io_read_ec_hdr: no EC header found at PEB 91, only 0xFF bytes
UBI DBG (pid 1284): add_to_list: add to erase: PEB 91, EC -1
UBI DBG (pid 1284): ubi_scan: process PEB 92
UBI DBG (pid 1284): process_eb: scan PEB 92
UBI DBG (pid 1284): ubi_scan_add_used: PEB 92, LEB 0:26, EC 54, sqnum 5448, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 92 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 92, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 93
UBI DBG (pid 1284): process_eb: scan PEB 93
UBI DBG (pid 1284): ubi_scan_add_used: PEB 93, LEB 0:20, EC 55, sqnum 5467, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 93 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 93, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 94
UBI DBG (pid 1284): process_eb: scan PEB 94
UBI DBG (pid 1284): ubi_scan_add_used: PEB 94, LEB 0:27, EC 55, sqnum 5469, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 94 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 94, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 95
UBI DBG (pid 1284): process_eb: scan PEB 95
UBI DBG (pid 1284): ubi_io_read_ec_hdr: no EC header found at PEB 95, only 0xFF bytes
UBI DBG (pid 1284): add_to_list: add to erase: PEB 95, EC -1
UBI DBG (pid 1284): ubi_scan: process PEB 96
UBI DBG (pid 1284): process_eb: scan PEB 96
UBI DBG (pid 1284): ubi_scan_add_used: PEB 96, LEB 0:15, EC 54, sqnum 5367, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 47, sqnum 13099, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 96 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 96, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 97
UBI DBG (pid 1284): process_eb: scan PEB 97
UBI DBG (pid 1284): ubi_scan_add_used: PEB 97, LEB 0:36, EC 55, sqnum 5450, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 97 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 97, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 98
UBI DBG (pid 1284): process_eb: scan PEB 98
UBI DBG (pid 1284): ubi_scan_add_used: PEB 98, LEB 0:17, EC 55, sqnum 5451, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 7, sqnum 13102, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 98 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 98, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 99
UBI DBG (pid 1284): process_eb: scan PEB 99
UBI DBG (pid 1284): ubi_scan_add_used: PEB 99, LEB 0:6, EC 54, sqnum 5371, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 49, sqnum 13085, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 99 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 99, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 100
UBI DBG (pid 1284): process_eb: scan PEB 100
UBI DBG (pid 1284): ubi_scan_add_used: PEB 100, LEB 0:14, EC 54, sqnum 5397, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 43, sqnum 13117, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 100 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 100, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 101
UBI DBG (pid 1284): process_eb: scan PEB 101
UBI DBG (pid 1284): ubi_scan_add_used: PEB 101, LEB 0:19, EC 55, sqnum 5452, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 101 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 101, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 102
UBI DBG (pid 1284): process_eb: scan PEB 102
UBI DBG (pid 1284): ubi_scan_add_used: PEB 102, LEB 0:21, EC 55, sqnum 5454, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 41, sqnum 13115, EC 59
UBI DBG (pid 1284): compare_lebs: first PEB 102 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 102, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 103
UBI DBG (pid 1284): process_eb: scan PEB 103
UBI DBG (pid 1284): ubi_scan_add_used: PEB 103, LEB 0:18, EC 55, sqnum 5455, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 29, sqnum 12937, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 103 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 103, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 104
UBI DBG (pid 1284): process_eb: scan PEB 104
UBI DBG (pid 1284): ubi_scan_add_used: PEB 104, LEB 0:22, EC 55, sqnum 5456, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 19, sqnum 13119, EC 85
UBI DBG (pid 1284): compare_lebs: first PEB 104 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 104, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 105
UBI DBG (pid 1284): process_eb: scan PEB 105
UBI DBG (pid 1284): ubi_scan_add_used: PEB 105, LEB 0:23, EC 55, sqnum 5457, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 105 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 105, EC 55
UBI DBG (pid 1284): ubi_scan: process PEB 106
UBI DBG (pid 1284): process_eb: scan PEB 106
UBI DBG (pid 1284): ubi_scan_add_used: PEB 106, LEB 0:36, EC 54, sqnum 5424, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 106 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 106, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 107
UBI DBG (pid 1284): process_eb: scan PEB 107
UBI DBG (pid 1284): ubi_scan_add_used: PEB 107, LEB 0:31, EC 54, sqnum 5381, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 107 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 107, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 108
UBI DBG (pid 1284): process_eb: scan PEB 108
UBI DBG (pid 1284): ubi_scan_add_used: PEB 108, LEB 0:35, EC 54, sqnum 5385, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 3, sqnum 13096, EC 105
UBI DBG (pid 1284): compare_lebs: first PEB 108 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 108, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 109
UBI DBG (pid 1284): process_eb: scan PEB 109
UBI DBG (pid 1284): ubi_scan_add_used: PEB 109, LEB 0:28, EC 54, sqnum 5386, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 33, sqnum 13094, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 109 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 109, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 110
UBI DBG (pid 1284): process_eb: scan PEB 110
UBI DBG (pid 1284): ubi_scan_add_used: PEB 110, LEB 0:34, EC 54, sqnum 5387, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 5, sqnum 13104, EC 66
UBI DBG (pid 1284): compare_lebs: first PEB 110 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 110, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 111
UBI DBG (pid 1284): process_eb: scan PEB 111
UBI DBG (pid 1284): ubi_scan_add_used: PEB 111, LEB 0:17, EC 53, sqnum 5346, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 7, sqnum 13102, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 111 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 111, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 112
UBI DBG (pid 1284): process_eb: scan PEB 112
UBI DBG (pid 1284): ubi_scan_add_used: PEB 112, LEB 0:33, EC 53, sqnum 5277, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 112 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 112, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 113
UBI DBG (pid 1284): process_eb: scan PEB 113
UBI DBG (pid 1284): ubi_scan_add_used: PEB 113, LEB 0:20, EC 54, sqnum 5388, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 113 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 113, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 114
UBI DBG (pid 1284): process_eb: scan PEB 114
UBI DBG (pid 1284): ubi_scan_add_used: PEB 114, LEB 0:30, EC 53, sqnum 5279, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 1, sqnum 12939, EC 115
UBI DBG (pid 1284): compare_lebs: first PEB 114 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 114, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 115
UBI DBG (pid 1284): process_eb: scan PEB 115
UBI DBG (pid 1284): ubi_scan_add_used: PEB 115, LEB 0:25, EC 53, sqnum 5280, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 115 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 115, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 116
UBI DBG (pid 1284): process_eb: scan PEB 116
UBI DBG (pid 1284): ubi_scan_add_used: PEB 116, LEB 0:29, EC 54, sqnum 5389, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 116 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 116, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 117
UBI DBG (pid 1284): process_eb: scan PEB 117
UBI DBG (pid 1284): ubi_scan_add_used: PEB 117, LEB 0:27, EC 54, sqnum 5390, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 117 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 117, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 118
UBI DBG (pid 1284): process_eb: scan PEB 118
UBI DBG (pid 1284): ubi_scan_add_used: PEB 118, LEB 0:26, EC 54, sqnum 5391, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 118 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 118, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 119
UBI DBG (pid 1284): process_eb: scan PEB 119
UBI DBG (pid 1284): ubi_scan_add_used: PEB 119, LEB 0:24, EC 54, sqnum 5392, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 119 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 119, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 120
UBI DBG (pid 1284): process_eb: scan PEB 120
UBI DBG (pid 1284): ubi_scan_add_used: PEB 120, LEB 0:27, EC 53, sqnum 5286, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 120 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 120, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 121
UBI DBG (pid 1284): process_eb: scan PEB 121
UBI DBG (pid 1284): ubi_scan_add_used: PEB 121, LEB 0:26, EC 53, sqnum 5287, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 121 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 121, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 122
UBI DBG (pid 1284): process_eb: scan PEB 122
UBI DBG (pid 1284): ubi_scan_add_used: PEB 122, LEB 0:24, EC 53, sqnum 5288, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 122 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 122, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 123
UBI DBG (pid 1284): process_eb: scan PEB 123
UBI DBG (pid 1284): ubi_scan_add_used: PEB 123, LEB 0:15, EC 54, sqnum 5393, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 47, sqnum 13099, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 123 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 123, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 124
UBI DBG (pid 1284): process_eb: scan PEB 124
UBI DBG (pid 1284): ubi_scan_add_used: PEB 124, LEB 0:14, EC 54, sqnum 5394, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 43, sqnum 13117, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 124 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 124, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 125
UBI DBG (pid 1284): process_eb: scan PEB 125
UBI DBG (pid 1284): ubi_scan_add_used: PEB 125, LEB 0:4, EC 54, sqnum 5395, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 125 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 125, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 126
UBI DBG (pid 1284): process_eb: scan PEB 126
UBI DBG (pid 1284): ubi_scan_add_used: PEB 126, LEB 0:33, EC 54, sqnum 5396, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 126 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 126, EC 54
UBI DBG (pid 1284): ubi_scan: process PEB 127
UBI DBG (pid 1284): process_eb: scan PEB 127
UBI DBG (pid 1284): ubi_scan_add_used: PEB 127, LEB 0:18, EC 53, sqnum 5297, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 29, sqnum 12937, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 127 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 127, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 128
UBI DBG (pid 1284): process_eb: scan PEB 128
UBI DBG (pid 1284): ubi_scan_add_used: PEB 128, LEB 0:22, EC 53, sqnum 5298, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 19, sqnum 13119, EC 85
UBI DBG (pid 1284): compare_lebs: first PEB 128 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 128, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 129
UBI DBG (pid 1284): process_eb: scan PEB 129
UBI DBG (pid 1284): ubi_scan_add_used: PEB 129, LEB 0:16, EC 53, sqnum 5299, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 32, sqnum 13025, EC 89
UBI DBG (pid 1284): compare_lebs: first PEB 129 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 129, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 130
UBI DBG (pid 1284): process_eb: scan PEB 130
UBI DBG (pid 1284): ubi_scan_add_used: PEB 130, LEB 0:23, EC 53, sqnum 5300, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 130 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 130, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 131
UBI DBG (pid 1284): process_eb: scan PEB 131
UBI DBG (pid 1284): ubi_scan_add_used: PEB 131, LEB 0:31, EC 53, sqnum 5301, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 131 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 131, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 132
UBI DBG (pid 1284): process_eb: scan PEB 132
UBI DBG (pid 1284): ubi_scan_add_used: PEB 132, LEB 0:39, EC 53, sqnum 5302, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 132 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 132, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 133
UBI DBG (pid 1284): process_eb: scan PEB 133
UBI DBG (pid 1284): ubi_scan_add_used: PEB 133, LEB 0:33, EC 53, sqnum 5303, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 133 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 133, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 134
UBI DBG (pid 1284): process_eb: scan PEB 134
UBI DBG (pid 1284): ubi_scan_add_used: PEB 134, LEB 0:28, EC 53, sqnum 5304, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 33, sqnum 13094, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 134 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 134, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 135
UBI DBG (pid 1284): process_eb: scan PEB 135
UBI DBG (pid 1284): ubi_scan_add_used: PEB 135, LEB 0:30, EC 53, sqnum 5305, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 1, sqnum 12939, EC 115
UBI DBG (pid 1284): compare_lebs: first PEB 135 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 135, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 136
UBI DBG (pid 1284): process_eb: scan PEB 136
UBI DBG (pid 1284): ubi_scan_add_used: PEB 136, LEB 0:25, EC 53, sqnum 5306, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 136 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 136, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 137
UBI DBG (pid 1284): process_eb: scan PEB 137
UBI DBG (pid 1284): ubi_scan_add_used: PEB 137, LEB 0:34, EC 53, sqnum 5307, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 5, sqnum 13104, EC 66
UBI DBG (pid 1284): compare_lebs: first PEB 137 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 137, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 138
UBI DBG (pid 1284): process_eb: scan PEB 138
UBI DBG (pid 1284): ubi_scan_add_used: PEB 138, LEB 0:20, EC 52, sqnum 5175, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 138 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 138, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 139
UBI DBG (pid 1284): process_eb: scan PEB 139
UBI DBG (pid 1284): ubi_scan_add_used: PEB 139, LEB 0:5, EC 53, sqnum 5309, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 30, sqnum 13074, EC 78
UBI DBG (pid 1284): compare_lebs: first PEB 139 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 139, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 140
UBI DBG (pid 1284): process_eb: scan PEB 140
UBI DBG (pid 1284): ubi_scan_add_used: PEB 140, LEB 0:29, EC 53, sqnum 5312, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 140 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 140, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 141
UBI DBG (pid 1284): process_eb: scan PEB 141
UBI DBG (pid 1284): ubi_scan_add_used: PEB 141, LEB 0:27, EC 53, sqnum 5313, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 141 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 141, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 142
UBI DBG (pid 1284): process_eb: scan PEB 142
UBI DBG (pid 1284): ubi_scan_add_used: PEB 142, LEB 0:26, EC 53, sqnum 5314, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 142 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 142, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 143
UBI DBG (pid 1284): process_eb: scan PEB 143
UBI DBG (pid 1284): ubi_scan_add_used: PEB 143, LEB 0:24, EC 53, sqnum 5315, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 143 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 143, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 144
UBI DBG (pid 1284): process_eb: scan PEB 144
UBI DBG (pid 1284): ubi_scan_add_used: PEB 144, LEB 0:38, EC 52, sqnum 5179, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 144 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 144, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 145
UBI DBG (pid 1284): process_eb: scan PEB 145
UBI DBG (pid 1284): ubi_scan_add_used: PEB 145, LEB 0:3, EC 52, sqnum 5181, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 45, sqnum 13098, EC 68
UBI DBG (pid 1284): compare_lebs: first PEB 145 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 145, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 146
UBI DBG (pid 1284): process_eb: scan PEB 146
UBI DBG (pid 1284): ubi_scan_add_used: PEB 146, LEB 0:24, EC 52, sqnum 5182, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 146 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 146, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 147
UBI DBG (pid 1284): process_eb: scan PEB 147
UBI DBG (pid 1284): ubi_scan_add_used: PEB 147, LEB 0:29, EC 52, sqnum 5183, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 147 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 147, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 148
UBI DBG (pid 1284): process_eb: scan PEB 148
UBI DBG (pid 1284): ubi_scan_add_used: PEB 148, LEB 0:19, EC 52, sqnum 5184, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 148 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 148, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 149
UBI DBG (pid 1284): process_eb: scan PEB 149
UBI DBG (pid 1284): ubi_scan_add_used: PEB 149, LEB 0:15, EC 52, sqnum 5185, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 47, sqnum 13099, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 149 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 149, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 150
UBI DBG (pid 1284): process_eb: scan PEB 150
UBI DBG (pid 1284): ubi_scan_add_used: PEB 150, LEB 0:14, EC 52, sqnum 5186, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 43, sqnum 13117, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 150 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 150, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 151
UBI DBG (pid 1284): process_eb: scan PEB 151
UBI DBG (pid 1284): ubi_scan_add_used: PEB 151, LEB 0:3, EC 51, sqnum 5028, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 45, sqnum 13098, EC 68
UBI DBG (pid 1284): compare_lebs: first PEB 151 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 151, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 152
UBI DBG (pid 1284): process_eb: scan PEB 152
UBI DBG (pid 1284): ubi_scan_add_used: PEB 152, LEB 0:16, EC 51, sqnum 5029, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 32, sqnum 13025, EC 89
UBI DBG (pid 1284): compare_lebs: first PEB 152 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 152, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 153
UBI DBG (pid 1284): process_eb: scan PEB 153
UBI DBG (pid 1284): ubi_scan_add_used: PEB 153, LEB 0:17, EC 52, sqnum 5187, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 7, sqnum 13102, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 153 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 153, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 154
UBI DBG (pid 1284): process_eb: scan PEB 154
UBI DBG (pid 1284): ubi_scan_add_used: PEB 154, LEB 0:22, EC 52, sqnum 5188, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 19, sqnum 13119, EC 85
UBI DBG (pid 1284): compare_lebs: first PEB 154 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 154, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 155
UBI DBG (pid 1284): process_eb: scan PEB 155
UBI DBG (pid 1284): ubi_scan_add_used: PEB 155, LEB 0:37, EC 52, sqnum 5189, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 10, sqnum 13097, EC 128
UBI DBG (pid 1284): compare_lebs: first PEB 155 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 155, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 156
UBI DBG (pid 1284): process_eb: scan PEB 156
UBI DBG (pid 1284): ubi_scan_add_used: PEB 156, LEB 0:36, EC 52, sqnum 5190, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 156 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 156, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 157
UBI DBG (pid 1284): process_eb: scan PEB 157
UBI DBG (pid 1284): ubi_scan_add_used: PEB 157, LEB 0:23, EC 52, sqnum 5191, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 157 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 157, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 158
UBI DBG (pid 1284): process_eb: scan PEB 158
UBI DBG (pid 1284): ubi_scan_add_used: PEB 158, LEB 0:4, EC 52, sqnum 5193, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 13, sqnum 13108, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 158 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 158, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 159
UBI DBG (pid 1284): process_eb: scan PEB 159
UBI DBG (pid 1284): ubi_scan_add_used: PEB 159, LEB 0:31, EC 52, sqnum 5194, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 159 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 159, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 160
UBI DBG (pid 1284): process_eb: scan PEB 160
UBI DBG (pid 1284): ubi_scan_add_used: PEB 160, LEB 0:39, EC 52, sqnum 5195, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 160 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 160, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 161
UBI DBG (pid 1284): process_eb: scan PEB 161
UBI DBG (pid 1284): ubi_scan_add_used: PEB 161, LEB 0:33, EC 52, sqnum 5196, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 161 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 161, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 162
UBI DBG (pid 1284): process_eb: scan PEB 162
UBI DBG (pid 1284): ubi_scan_add_used: PEB 162, LEB 0:28, EC 52, sqnum 5197, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 33, sqnum 13094, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 162 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 162, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 163
UBI DBG (pid 1284): process_eb: scan PEB 163
UBI DBG (pid 1284): ubi_scan_add_used: PEB 163, LEB 0:30, EC 52, sqnum 5198, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 1, sqnum 12939, EC 115
UBI DBG (pid 1284): compare_lebs: first PEB 163 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 163, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 164
UBI DBG (pid 1284): process_eb: scan PEB 164
UBI DBG (pid 1284): ubi_scan_add_used: PEB 164, LEB 0:25, EC 52, sqnum 5199, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 164 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 164, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 165
UBI DBG (pid 1284): process_eb: scan PEB 165
UBI DBG (pid 1284): ubi_scan_add_used: PEB 165, LEB 0:35, EC 52, sqnum 5200, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 3, sqnum 13096, EC 105
UBI DBG (pid 1284): compare_lebs: first PEB 165 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 165, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 166
UBI DBG (pid 1284): process_eb: scan PEB 166
UBI DBG (pid 1284): ubi_scan_add_used: PEB 166, LEB 0:27, EC 52, sqnum 5201, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 166 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 166, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 167
UBI DBG (pid 1284): process_eb: scan PEB 167
UBI DBG (pid 1284): ubi_scan_add_used: PEB 167, LEB 0:20, EC 52, sqnum 5202, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 167 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 167, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 168
UBI DBG (pid 1284): process_eb: scan PEB 168
UBI DBG (pid 1284): ubi_scan_add_used: PEB 168, LEB 0:26, EC 52, sqnum 5203, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 168 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 168, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 169
UBI DBG (pid 1284): process_eb: scan PEB 169
UBI DBG (pid 1284): ubi_scan_add_used: PEB 169, LEB 0:5, EC 52, sqnum 5205, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 30, sqnum 13074, EC 78
UBI DBG (pid 1284): compare_lebs: first PEB 169 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 169, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 170
UBI DBG (pid 1284): process_eb: scan PEB 170
UBI DBG (pid 1284): ubi_scan_add_used: PEB 170, LEB 0:38, EC 52, sqnum 5206, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 170 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 170, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 171
UBI DBG (pid 1284): process_eb: scan PEB 171
UBI DBG (pid 1284): ubi_scan_add_used: PEB 171, LEB 0:24, EC 52, sqnum 5207, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 171 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 171, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 172
UBI DBG (pid 1284): process_eb: scan PEB 172
UBI DBG (pid 1284): ubi_scan_add_used: PEB 172, LEB 0:29, EC 52, sqnum 5208, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 172 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 172, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 173
UBI DBG (pid 1284): process_eb: scan PEB 173
UBI DBG (pid 1284): ubi_scan_add_used: PEB 173, LEB 0:19, EC 52, sqnum 5209, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 173 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 173, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 174
UBI DBG (pid 1284): process_eb: scan PEB 174
UBI DBG (pid 1284): ubi_scan_add_used: PEB 174, LEB 0:29, EC 51, sqnum 5052, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 174 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 174, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 175
UBI DBG (pid 1284): process_eb: scan PEB 175
UBI DBG (pid 1284): ubi_scan_add_used: PEB 175, LEB 0:15, EC 52, sqnum 5210, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 47, sqnum 13099, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 175 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 175, EC 52
UBI DBG (pid 1284): ubi_scan: process PEB 176
UBI DBG (pid 1284): process_eb: scan PEB 176
UBI DBG (pid 1284): ubi_scan_add_used: PEB 176, LEB 0:19, EC 53, sqnum 5316, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 176 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 176, EC 53
UBI DBG (pid 1284): ubi_scan: process PEB 177
UBI DBG (pid 1284): process_eb: scan PEB 177
UBI DBG (pid 1284): ubi_scan_add_used: PEB 177, LEB 0:36, EC 51, sqnum 5058, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 177 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 177, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 178
UBI DBG (pid 1284): process_eb: scan PEB 178
UBI DBG (pid 1284): ubi_scan_add_used: PEB 178, LEB 0:23, EC 51, sqnum 5059, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 178 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 178, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 179
UBI DBG (pid 1284): process_eb: scan PEB 179
UBI DBG (pid 1284): ubi_scan_add_used: PEB 179, LEB 0:41, EC 51, sqnum 5060, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 51, sqnum 13110, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 179 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 179, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 180
UBI DBG (pid 1284): process_eb: scan PEB 180
UBI DBG (pid 1284): ubi_scan_add_used: PEB 180, LEB 0:39, EC 51, sqnum 5061, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 180 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 180, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 181
UBI DBG (pid 1284): process_eb: scan PEB 181
UBI DBG (pid 1284): ubi_scan_add_used: PEB 181, LEB 0:33, EC 51, sqnum 5062, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 181 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 181, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 182
UBI DBG (pid 1284): process_eb: scan PEB 182
UBI DBG (pid 1284): ubi_scan_add_used: PEB 182, LEB 0:38, EC 51, sqnum 5063, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 182 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 182, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 183
UBI DBG (pid 1284): process_eb: scan PEB 183
UBI DBG (pid 1284): ubi_scan_add_used: PEB 183, LEB 0:31, EC 51, sqnum 5064, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 183 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 183, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 184
UBI DBG (pid 1284): process_eb: scan PEB 184
UBI DBG (pid 1284): ubi_scan_add_used: PEB 184, LEB 0:30, EC 51, sqnum 5065, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 1, sqnum 12939, EC 115
UBI DBG (pid 1284): compare_lebs: first PEB 184 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 184, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 185
UBI DBG (pid 1284): process_eb: scan PEB 185
UBI DBG (pid 1284): ubi_scan_add_used: PEB 185, LEB 0:6, EC 51, sqnum 5067, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 49, sqnum 13085, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 185 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 185, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 186
UBI DBG (pid 1284): process_eb: scan PEB 186
UBI DBG (pid 1284): ubi_scan_add_used: PEB 186, LEB 0:25, EC 51, sqnum 5068, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 36, sqnum 13118, EC 76
UBI DBG (pid 1284): compare_lebs: first PEB 186 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 186, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 187
UBI DBG (pid 1284): process_eb: scan PEB 187
UBI DBG (pid 1284): ubi_scan_add_used: PEB 187, LEB 0:35, EC 51, sqnum 5069, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 3, sqnum 13096, EC 105
UBI DBG (pid 1284): compare_lebs: first PEB 187 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 187, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 188
UBI DBG (pid 1284): process_eb: scan PEB 188
UBI DBG (pid 1284): ubi_scan_add_used: PEB 188, LEB 0:27, EC 51, sqnum 5070, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 17, sqnum 13075, EC 97
UBI DBG (pid 1284): compare_lebs: first PEB 188 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 188, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 189
UBI DBG (pid 1284): process_eb: scan PEB 189
UBI DBG (pid 1284): ubi_scan_add_used: PEB 189, LEB 0:32, EC 51, sqnum 5071, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 24, sqnum 13114, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 189 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 189, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 190
UBI DBG (pid 1284): process_eb: scan PEB 190
UBI DBG (pid 1284): ubi_scan_add_used: PEB 190, LEB 0:20, EC 51, sqnum 5072, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 4, sqnum 12664, EC 84
UBI DBG (pid 1284): compare_lebs: first PEB 190 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 190, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 191
UBI DBG (pid 1284): process_eb: scan PEB 191
UBI DBG (pid 1284): ubi_scan_add_used: PEB 191, LEB 0:26, EC 51, sqnum 5073, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 6, sqnum 13109, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 191 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 191, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 192
UBI DBG (pid 1284): process_eb: scan PEB 192
UBI DBG (pid 1284): ubi_scan_add_used: PEB 192, LEB 0:18, EC 51, sqnum 5074, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 29, sqnum 12937, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 192 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 192, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 193
UBI DBG (pid 1284): process_eb: scan PEB 193
UBI DBG (pid 1284): ubi_scan_add_used: PEB 193, LEB 0:24, EC 51, sqnum 5075, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 53, sqnum 13111, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 193 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 193, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 194
UBI DBG (pid 1284): process_eb: scan PEB 194
UBI DBG (pid 1284): ubi_scan_add_used: PEB 194, LEB 0:19, EC 51, sqnum 5076, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 46, sqnum 13112, EC 64
UBI DBG (pid 1284): compare_lebs: first PEB 194 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 194, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 195
UBI DBG (pid 1284): process_eb: scan PEB 195
UBI DBG (pid 1284): ubi_scan_add_used: PEB 195, LEB 0:14, EC 51, sqnum 5077, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 43, sqnum 13117, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 195 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 195, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 196
UBI DBG (pid 1284): process_eb: scan PEB 196
UBI DBG (pid 1284): ubi_scan_add_used: PEB 196, LEB 0:3, EC 51, sqnum 5079, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 45, sqnum 13098, EC 68
UBI DBG (pid 1284): compare_lebs: first PEB 196 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 196, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 197
UBI DBG (pid 1284): process_eb: scan PEB 197
UBI DBG (pid 1284): ubi_scan_add_used: PEB 197, LEB 0:17, EC 51, sqnum 5080, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 7, sqnum 13102, EC 61
UBI DBG (pid 1284): compare_lebs: first PEB 197 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 197, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 198
UBI DBG (pid 1284): process_eb: scan PEB 198
UBI DBG (pid 1284): ubi_scan_add_used: PEB 198, LEB 0:37, EC 51, sqnum 5081, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 10, sqnum 13097, EC 128
UBI DBG (pid 1284): compare_lebs: first PEB 198 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 198, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 199
UBI DBG (pid 1284): process_eb: scan PEB 199
UBI DBG (pid 1284): ubi_scan_add_used: PEB 199, LEB 0:22, EC 51, sqnum 5082, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 19, sqnum 13119, EC 85
UBI DBG (pid 1284): compare_lebs: first PEB 199 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 199, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 200
UBI DBG (pid 1284): process_eb: scan PEB 200
UBI DBG (pid 1284): ubi_scan_add_used: PEB 200, LEB 0:36, EC 51, sqnum 5083, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 34, sqnum 13106, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 200 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 200, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 201
UBI DBG (pid 1284): process_eb: scan PEB 201
UBI DBG (pid 1284): ubi_scan_add_used: PEB 201, LEB 0:23, EC 51, sqnum 5084, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 2, sqnum 13101, EC 60
UBI DBG (pid 1284): compare_lebs: first PEB 201 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 201, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 202
UBI DBG (pid 1284): process_eb: scan PEB 202
UBI DBG (pid 1284): ubi_scan_add_used: PEB 202, LEB 0:41, EC 51, sqnum 5085, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 51, sqnum 13110, EC 57
UBI DBG (pid 1284): compare_lebs: first PEB 202 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 202, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 203
UBI DBG (pid 1284): process_eb: scan PEB 203
UBI DBG (pid 1284): ubi_scan_add_used: PEB 203, LEB 0:39, EC 51, sqnum 5086, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 0, sqnum 13113, EC 69
UBI DBG (pid 1284): compare_lebs: first PEB 203 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 203, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 204
UBI DBG (pid 1284): process_eb: scan PEB 204
UBI DBG (pid 1284): ubi_scan_add_used: PEB 204, LEB 0:33, EC 51, sqnum 5087, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 40, sqnum 13116, EC 71
UBI DBG (pid 1284): compare_lebs: first PEB 204 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 204, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 205
UBI DBG (pid 1284): process_eb: scan PEB 205
UBI DBG (pid 1284): ubi_scan_add_used: PEB 205, LEB 0:38, EC 51, sqnum 5088, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 38, sqnum 13107, EC 63
UBI DBG (pid 1284): compare_lebs: first PEB 205 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 205, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 206
UBI DBG (pid 1284): process_eb: scan PEB 206
UBI DBG (pid 1284): ubi_scan_add_used: PEB 206, LEB 0:31, EC 51, sqnum 5089, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 18, sqnum 13100, EC 58
UBI DBG (pid 1284): compare_lebs: first PEB 206 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 206, EC 51
UBI DBG (pid 1284): ubi_scan: process PEB 207
UBI DBG (pid 1284): process_eb: scan PEB 207
UBI DBG (pid 1284): ubi_scan_add_used: PEB 207, LEB 0:29, EC 51, sqnum 5090, bitflips 0
UBI DBG (pid 1284): ubi_scan_add_used: this LEB already exists: PEB 37, sqnum 13105, EC 70
UBI DBG (pid 1284): compare_lebs: first PEB 207 is newer, copy_flag is unset
UBI DBG (pid 1284): add_to_list: add to erase: PEB 207, EC 51
UBI DBG (pid 1284): ubi_scan: scanning is finished
UBI error: check_what_we_have: 1 PEBs are corrupted and preserved
Corrupted PEBs are: 39
UBI: max. sequence number:       13119
UBI DBG (pid 1284): process_lvol: check layout volume
UBI DBG (pid 1284): ubi_eba_init_scan: initialize EBA sub-system
UBI error: ubi_eba_init_scan: no enough physical eraseblocks (0, need 1)
UBI error: ubi_eba_init_scan: 1 PEBs are corrupted and not used
UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -28
ubiattach: error!: cannot attach mtd5
           error 28 (No space left on device)
UBI DBG (pid 1287): ubi_open_volume_path: open volume ubi0:homefs, mode 1
UBI DBG (pid 1287): ubi_open_volume_nm: open device 0, volume homefs, mode 1
UBIFS error (pid 1287): ubifs_get_sb: cannot open "ubi0:homefs", error -19

Kernel log ends here.

Additional limited dump of the PEB 39 (from offset 0 to 0xe0)
is included below since the EC header dump is not done in the
kernel log. We can see that the EC header's magic is ok, but
VID header's magic is zero.

My question is:
Is it possible that the reset occured while running in
nor_erase_prepare() just after clearing the VID header magic,
but before clearing the EC header magic?

If I clear the PEB 39 EC header's magic in U-Boot and then
boot Linux and try to attach the MTD device again, attaching
succeeds. Then, mounting the UBIFS partition succeeds, too.

Partial PEB 39 dump:
=> md f4500000 0xe0
f4500000: 55424923 01000000 00000000 00000067    UBI#...........g
f4500010: 00000040 00000080 753746f3 00000000    ... at ....u7F.....
f4500020: 00000000 00000000 00000000 00000000    ................
f4500030: 00000000 00000000 00000000 84069610    ................
f4500040: 00000000 01010000 00000000 00000003    ................
f4500050: 00000000 00000000 00000000 00000000    ................
f4500060: 00000000 00000000 00000000 000032fa    ..............2.
f4500070: 00000000 00000000 00000000 26036a6e    ............&.jn
f4500080: 31181006 e3e5edbf 73921600 00000000    1.......s.......
f4500090: 20000000 0a000000 40040000 00000000     ....... at .......
f45000a0: 31181006 8b01d70b 74921600 00000000    1.......t.......
f45000b0: 40000000 08000000 29000000 b8910200    @.......).......
f45000c0: 01000000 0000000a 00010a90 0000005b    ...............[
f45000d0: 00000001 4ba99010 c7710ba0 0000000a    ....K....q......
f45000e0: 31181006 9831db12 75921600 00000000    1....1..u.......
f45000f0: 40000000 08000000 22000000 d0fb0300    @.......".......
f4500100: 02000000 5da8bd01 00000000 0000000a    ....]...........
f4500110: 00010678 00000040 00000000 00000000    ...x... at ........
f4500120: 31181006 ccc70eaa d9921600 00000000    1...............
f4500130: 40000000 08000000 1b000000 00000000    @...............
f4500140: 02000000 00000000 00000000 00000000    ................
f4500150: 00000000 00000000 00000000 00000000    ................
f4500160: 31181006 5cfd1854 58931600 00000000    1...\..TX.......
f4500170: 40000000 08000000 1f000000 00000000    @...............
f4500180: 02000000 00000000 00000000 00000000    ................
f4500190: 00000000 00000000 00000000 00000000    ................
f45001a0: 31181006 b6402983 d7931600 00000000    1....@).........
f45001b0: 40000000 08000000 17000000 00000000    @...............
f45001c0: 02000000 00000000 00000000 00000000    ................
f45001d0: 00000000 00000000 00000000 00000000    ................
f45001e0: 31181006 89f2ce34 56941600 00000000    1......4V.......
f45001f0: 40000000 08000000 11000000 00000000    @...............
f4500200: 02000000 00000000 00000000 00000000    ................
f4500210: 00000000 00000000 00000000 00000000    ................
f4500220: 31181006 830e1f10 d5941600 00000000    1...............
f4500230: 40000000 08000000 28000000 00000000    @.......(.......
f4500240: 02000000 00000000 00000000 00000000    ................
f4500250: 00000000 00000000 00000000 00000000    ................
f4500260: 31181006 17a41587 54951600 00000000    1.......T.......
f4500270: 40000000 08000000 1d000000 00000000    @...............
f4500280: 02000000 00000000 00000000 00000000    ................
f4500290: 00000000 00000000 00000000 00000000    ................
f45002a0: 31181006 411790d5 d3951600 00000000    1...A...........
f45002b0: 40000000 08000000 24000000 00000000    @.......$.......
f45002c0: 02000000 00000000 00000000 00000000    ................
f45002d0: 00000000 00000000 00000000 00000000    ................
f45002e0: 31181006 e12af83a 52961600 00000000    1....*.:R.......
f45002f0: 40000000 08000000 26000000 00000000    @.......&.......
f4500300: 02000000 00000000 00000000 00000000    ................
f4500310: 00000000 00000000 00000000 00000000    ................
f4500320: 31181006 bc2514e4 d1961600 00000000    1....%..........
f4500330: 40000000 08000000 18000000 00000000    @...............
f4500340: 02000000 00000000 00000000 00000000    ................
f4500350: 00000000 00000000 00000000 00000000    ................
f4500360: ffffffff ffffffff ffffffff ffffffff    ................
f4500370: ffffffff ffffffff ffffffff ffffffff    ................

Thanks,
Anatolij



From nvbolhuis at aimvalley.nl  Wed Dec  1 08:06:49 2010
From: nvbolhuis at aimvalley.nl (Norbert van Bolhuis)
Date: Wed, 01 Dec 2010 14:06:49 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <AANLkTikci0e2jaHCarA9HG86b_C-1UUcT_PMy-Q_mBrP@mail.gmail.com>
References: <20101129195014.19224240@wker>	<4CF4D4CA.8040906@aimvalley.nl>	<20101130163541.44c48a94@wker>	<AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>	<20101201105518.206635e6@wker>
	<AANLkTikci0e2jaHCarA9HG86b_C-1UUcT_PMy-Q_mBrP@mail.gmail.com>
Message-ID: <4CF64869.4020902@aimvalley.nl>

Artem Bityutskiy wrote:
> On Wed, Dec 1, 2010 at 11:55 AM, Anatolij Gustschin <agust at denx.de> wrote:
> 
>> On Tue, 30 Nov 2010 20:18:56 +0200
>> boaz ben david <boazbd at gmail.com> wrote:
>>
>>> Sorry to bump the thread but I'm having issues which I think are similiar
>>> with MLC NAND flash.
>>> Will reducing the write buffer help here too?
>> I don't know. Your issues may look similar but without
>> knowing the details it is not possible to say. Most
>> probably no. I reduced the write buffer size in the CFI
>> driver. The issues we observed seem to be NOR flash
>> specific.
>>
> 
> Hi,
> 
> let me try to explain this. Both UBI and UBIFS have a notion of min_io_size.
> It is
> NAND page size in case of NAND. In case of NOR, UBI reports min_io_size as
> 1.
> So UBI assumes NOR flash writes one byte at a time.
> 
> Since UBIFS align all flash nodes to 8 bytes, UBIFS assumes min_io_size for
> NOR is 8 bytes. See fs/ubifs/super.c:
> 
>         /*
>          * UBIFS aligns all node to 8-byte boundary, so to make function in
>          * io.c simpler, assume minimum I/O unit size to be 8 bytes if it is
>          * less than 8.
>          */
>         if (c->min_io_size < 8) {
>                 c->min_io_size = 8;
>                 c->min_io_shift = 3;
>         }
> 
> Then the UBIFS scanning and recovery code is trying to be very picky about
> how
> nodes are corrupted. We wanted to distinguish between corruptions caused by
> power cuts and corruptions caused by something else. UBIFS policy is that it
> should
> gracefully recover from all corruptions cause by power cuts, and it does not
> try to
> recover from other types of corruptions.
> 
> Thus, in journal recovery code, if we see that we have good node, good node,
> good
> node, then some trash, we analyse this trash. We check that the amount of
> trash is
> not longer than maximum UBIFS node size aligned up to min_io_size, and then
> after
> this go all 0xFFs. And some other checks. See no_more_nodes() function.
> 
> In your case what happens is that we look that the amount of corrupted data
> is longer
> than common header size (all nodes start with the common header) aligned up
> to
> the min_io_size. And since we assume data is written min_io_size bytes at a
> time
> (8 bytes, next 8 bytes, etc in your case), we assume that the common header
> was
> successfully written, and we check it. But it is corrupted in your case,
> simply because
> you write 64 bytes at a time, no 8. And we reject the flash.
> 
> So all you need to do is to teach UBIFS to look at CFI write buffer size,
> and make
> min_io_size to be the same. Then it should work fine.
> 
> Try hacking UBIFS and make min_io_size to be 64. If it works, you can
> provide a
> nice solution - add corresponding field to mtd_info structure and teach UBI
> to look
> at it.
> 


A while ago I hacked mtd/ubi to hold CFI write buffer size in oobsize
in case of NOR flash. We have NOR devices with 64 (SPANSION) and 1024
(Numonyx? Axcell? M29EW) bytes write buffer size.
I never submitted it to this list because I considered it a hack
(and was rather busy).

I'm even more busy now, but I can cook up the patches and send them if
you want (hopefully I have time this evening or tomorrow).

It's only for testing (private kernel) since I assume it's not acceptable
to abuse oobsize this way (for NOR flash) ?

---
N. van Bolhuis.




From alexander.stein at systec-electronic.com  Wed Dec  1 08:37:16 2010
From: alexander.stein at systec-electronic.com (Alexander Stein)
Date: Wed, 1 Dec 2010 14:37:16 +0100
Subject: UBI error: nor_erase_prepare: cannot invalidate PEB 76,
	write returned -5 read returned 2
Message-ID: <201012011437.16978.alexander.stein@systec-electronic.com>

Hello,

I'm observing the given error after starting Linux. ubiattach is called from 
within the init-script. Currently I'm running v2.6.34. The filesystem is 
mounted read-only as expected.
It gets curious that afterwards in u-boot the corresponding sector is complety 
empty, read 0xff. It seems the sector cannot be written, although it is empty.
Has anybody an idea about such phenomenon? Oh, before it forget, I use a 
Numonyx Axcell M29EW NOR-Flash 128MiB.

Best regards
Alexander


From agust at denx.de  Wed Dec  1 10:44:47 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 1 Dec 2010 16:44:47 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101201130534.5b95ce83@wker>
References: <20101129195014.19224240@wker>
	<20101201130534.5b95ce83@wker>
Message-ID: <20101201164447.2215bc58@wker>

On Wed, 1 Dec 2010 13:05:34 +0100
Anatolij Gustschin <agust at denx.de> wrote:
... 
> My question is:
> Is it possible that the reset occured while running in
> nor_erase_prepare() just after clearing the VID header magic,
> but before clearing the EC header magic?

yes, it is possible and it seems this is the reason for
that next issue we've observed. Adding the call to the
machine restart callback in nor_erase_prepare() just before
clearing EC header magic to simulate this hypothetical case
we see:
...
UBI DBG (pid 1287): ubi_eba_read_leb: read 160 bytes from offset 80112 of LEB 0:10, PEB 12
UBI DBG (pid 1287): ubi_close_volume: close device 0, volume 0, mode 1
nor_erase_prepare: ### RESET before clearing EC magic in peb # 177, off: 0xf6780000

and now we dump the EC and VID headers and some UBIFS
nodes of the PEB # 177:

=> md f6780000 50
f6780000: 55424923 01000000 00000000 00000034    UBI#...........4
f6780010: 00000040 00000080 753746f3 00000000    ... at ....u7F.....
f6780020: 00000000 00000000 00000000 00000000    ................
f6780030: 00000000 00000000 00000000 6533c6f3    ............e3..
f6780040: 00000000 01010000 00000000 00000004    ................
f6780050: 00000000 00000000 00000000 00000000    ................
f6780060: 00000000 00000000 00000000 00003343    ..............3C
f6780070: 00000000 00000000 00000000 478a9cae    ............G...
f6780080: 31181006 f0deeea3 20b21600 00000000    1....... .......
f6780090: 20000000 0a000000 49040000 00000000     .......I.......
f67800a0: 31181006 5412d762 21b21600 00000000    1...T..b!.......
f67800b0: 40000000 08000000 1c000000 30920300    @...........0...
f67800c0: 01000000 0001c808 0001c808 00000005    ................
f67800d0: 00040000 00000001 0001cc60 0005cc60    ...........`...`
f67800e0: 31181006 2a49116c 22b21600 00000000    1...*I.l".......
f67800f0: 40000000 08000000 16000000 60230100    @...........`#..
f6780100: 02000000 00000000 bfaf7600 c0000000    ..........v.....
f6780110: 00000000 00000000 00000000 00000000    ................
f6780120: ffffffff ffffffff ffffffff ffffffff    ................
f6780130: ffffffff ffffffff ffffffff ffffffff    ................

After booting Linux and attaching the MTD device I can see
very similar things happen:
...
UBI DBG (pid 1277): ubi_scan: process PEB 177
UBI DBG (pid 1277): process_eb: scan PEB 177
UBI DBG (pid 1277): ubi_io_read_vid_hdr: bad magic number at PEB 177: 00000000 instead of 55424921
UBI error: check_corruption: PEB 177 contains corrupted VID header, and the data does not contain all 0xFF, this may be a non-UBI PEB or a severe VID header corruption which requires manual inspection
Volume identifier header dump:
	magic     00000000
	version   1
	vol_type  1
	copy_flag 0
	compat    0
	vol_id    0
	lnum      4
	data_size 0
	used_ebs  0
	data_pad  0
	sqnum     13123
	hdr_crc   478a9cae
Volume identifier header hexdump:
00000000: 00 00 00 00 01 01 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33 43 00 00 00 00 00 00 00 00 00 00 00 00 47 8a 9c ae  ..............3C............G...
UBI DBG (pid 1277): check_corruption: hexdump of PEB 177 offset 128, length 262016
00000000: 31 18 10 06 f0 de ee a3 20 b2 16 00 00 00 00 00 20 00 00 00 0a 00 00 00 49 04 00 00 00 00 00 00  1....... ....... .......I.......
00000020: 31 18 10 06 54 12 d7 62 21 b2 16 00 00 00 00 00 40 00 00 00 08 00 00 00 1c 00 00 00 30 92 03 00  1...T..b!....... at ...........0...
00000040: 01 00 00 00 00 01 c8 08 00 01 c8 08 00 00 00 05 00 04 00 00 00 00 00 01 00 01 cc 60 00 05 cc 60  ...........................`...`
00000060: 31 18 10 06 2a 49 11 6c 22 b2 16 00 00 00 00 00 40 00 00 00 08 00 00 00 16 00 00 00 60 23 01 00  1...*I.l"....... at ...........`#..
00000080: 02 00 00 00 00 00 00 00 bf af 76 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..........v.....................
000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
*
0003ff60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
UBI DBG (pid 1277): add_corrupted: add to corrupted: PEB 177, EC 52
...
UBI DBG (pid 1277): ubi_io_read_vid_hdr: no VID header found at PEB 207, only 0xFF bytes
UBI DBG (pid 1277): add_to_list: add to free: PEB 207, EC 52
UBI DBG (pid 1277): ubi_scan: scanning is finished
UBI error: check_what_we_have: 1 PEBs are corrupted and preserved
Corrupted PEBs are: 177
UBI: max. sequence number:       13124
UBI DBG (pid 1277): process_lvol: check layout volume
UBI DBG (pid 1277): ubi_eba_init_scan: initialize EBA sub-system
UBI error: ubi_eba_init_scan: no enough physical eraseblocks (0, need 1)
UBI error: ubi_eba_init_scan: 1 PEBs are corrupted and not used
UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -28
ubiattach: error!: cannot attach mtd5
           error 28 (No space left on device)
UBI DBG (pid 1280): ubi_open_volume_path: open volume ubi0:homefs, mode 1
UBI DBG (pid 1280): ubi_open_volume_nm: open device 0, volume homefs, mode 1

So, this is a problem with not atomic clearing of the magic numbers
in EC and VID header.

Anatolij


From siribarne at grid-net.com  Wed Dec  1 13:20:32 2010
From: siribarne at grid-net.com (Steve Iribarne)
Date: Wed, 01 Dec 2010 10:20:32 -0800
Subject: bud_replay size question
Message-ID: <4CF691F0.9010607@grid-net.com>

Hi List.

We had a problem here in our released product where we would get the 
dreaded "Error reading superblock!".

First some stats:

ARM processor (iMX25)
U-Boot version (U-Boot 2009.06-rc2-svn3608)  <- I know this is 
autogenerated but what the heck...

I still don't know how to reproduce the problem but I know what is 
causing the issue.

The issue is that ubifs_get_sb fails.  The reason it fails is that 
insert_node (u-boot/fs/ubifs/replay.c) runs out of memory.  So I can fix 
the problem by giving u-boot more space for malloc (increase the size of 
CONFIG_SYS_MALLOC_LEN)

This is all fine and dandy but I really don't like updating the bootrom 
in the field.  So I'm trying to get this value correct.

I have approx. 58MB to play with here.

Our file system lives on a NAND flash that is 256MB total but I have it 
broken up into 3 partitions.
1 is 10MiB and the other two (the ones that really hold most of the 
data) have 100MiB each.

What I'm trying to determine is how to figure out how big the replay_bud 
LEB list can get based on my configuration.  Is there such a thing or am 
I just dreaming?

Thanks.
-stv

-- 
Steve Iribarne
Sr. Software Engineer
Embedded Devices




From kmpark at infradead.org  Wed Dec  1 19:24:16 2010
From: kmpark at infradead.org (Kyungmin Park)
Date: Thu, 02 Dec 2010 09:24:16 +0900
Subject: [PATCH] mtd: OneNAND: Fix 4KiB pagesize OOB handling
Message-ID: <20101202002416.GA807@july>

From: Kyungmin Park <kyungmin.park at samsung.com>

Original 4KiB pagesize chip (SLC) doesn't support OOB operations at Spec.
And it's also same at Flex-OneNAND.

Remove the MLC macro if possible and use 4KiB pagesize macro since MLC has 4KiB pagesize.

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 4d6e6c5..c38bf9c 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -400,8 +400,7 @@ static int onenand_command(struct mtd_info *mtd, int cmd, loff_t addr, size_t le
 		value = onenand_bufferram_address(this, block);
 		this->write_word(value, this->base + ONENAND_REG_START_ADDRESS2);
 
-		if (ONENAND_IS_MLC(this) || ONENAND_IS_2PLANE(this) ||
-		    ONENAND_IS_4KB_PAGE(this))
+		if (ONENAND_IS_2PLANE(this) || ONENAND_IS_4KB_PAGE(this))
 			/* It is always BufferRAM0 */
 			ONENAND_SET_BUFFERRAM0(this);
 		else
@@ -430,7 +429,7 @@ static int onenand_command(struct mtd_info *mtd, int cmd, loff_t addr, size_t le
 		case FLEXONENAND_CMD_RECOVER_LSB:
 		case ONENAND_CMD_READ:
 		case ONENAND_CMD_READOOB:
-			if (ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this))
+			if (ONENAND_IS_4KB_PAGE(this))
 				/* It is always BufferRAM0 */
 				dataram = ONENAND_SET_BUFFERRAM0(this);
 			else
@@ -1353,7 +1352,7 @@ static int onenand_read_oob_nolock(struct mtd_info *mtd, loff_t from,
 
 	stats = mtd->ecc_stats;
 
-	readcmd = ONENAND_IS_MLC(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
+	readcmd = ONENAND_IS_4KB_PAGE(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
 
 	while (read < len) {
 		cond_resched();
@@ -1429,7 +1428,7 @@ static int onenand_read(struct mtd_info *mtd, loff_t from, size_t len,
 	int ret;
 
 	onenand_get_device(mtd, FL_READING);
-	ret = ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this) ?
+	ret = ONENAND_IS_4KB_PAGE(this) ?
 		onenand_mlc_read_ops_nolock(mtd, from, &ops) :
 		onenand_read_ops_nolock(mtd, from, &ops);
 	onenand_release_device(mtd);
@@ -1464,7 +1463,7 @@ static int onenand_read_oob(struct mtd_info *mtd, loff_t from,
 
 	onenand_get_device(mtd, FL_READING);
 	if (ops->datbuf)
-		ret = ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this) ?
+		ret = ONENAND_IS_4KB_PAGE(this) ?
 			onenand_mlc_read_ops_nolock(mtd, from, ops) :
 			onenand_read_ops_nolock(mtd, from, ops);
 	else
@@ -1558,7 +1557,7 @@ int onenand_bbt_read_oob(struct mtd_info *mtd, loff_t from,
 
 	column = from & (mtd->oobsize - 1);
 
-	readcmd = ONENAND_IS_MLC(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
+	readcmd = ONENAND_IS_4KB_PAGE(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
 
 	while (read < len) {
 		cond_resched();
@@ -1612,7 +1611,7 @@ static int onenand_verify_oob(struct mtd_info *mtd, const u_char *buf, loff_t to
 	u_char *oob_buf = this->oob_buf;
 	int status, i, readcmd;
 
-	readcmd = ONENAND_IS_MLC(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
+	readcmd = ONENAND_IS_4KB_PAGE(this) ? ONENAND_CMD_READ : ONENAND_CMD_READOOB;
 
 	this->command(mtd, readcmd, to, mtd->oobsize);
 	onenand_update_bufferram(mtd, to, 0);
@@ -2079,7 +2078,7 @@ static int onenand_write_oob_nolock(struct mtd_info *mtd, loff_t to,
 
 	oobbuf = this->oob_buf;
 
-	oobcmd = ONENAND_IS_MLC(this) ? ONENAND_CMD_PROG : ONENAND_CMD_PROGOOB;
+	oobcmd = ONENAND_IS_4KB_PAGE(this) ? ONENAND_CMD_PROG : ONENAND_CMD_PROGOOB;
 
 	/* Loop until all data write */
 	while (written < len) {
@@ -2098,7 +2097,7 @@ static int onenand_write_oob_nolock(struct mtd_info *mtd, loff_t to,
 			memcpy(oobbuf + column, buf, thislen);
 		this->write_bufferram(mtd, ONENAND_SPARERAM, oobbuf, 0, mtd->oobsize);
 
-		if (ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this)) {
+		if (ONENAND_IS_4KB_PAGE(this)) {
 			/* Set main area of DataRAM to 0xff*/
 			memset(this->page_buf, 0xff, mtd->writesize);
 			this->write_bufferram(mtd, ONENAND_DATARAM,
@@ -3041,7 +3040,7 @@ static int do_otp_read(struct mtd_info *mtd, loff_t from, size_t len,
 	this->command(mtd, ONENAND_CMD_OTP_ACCESS, 0, 0);
 	this->wait(mtd, FL_OTPING);
 
-	ret = ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this) ?
+	ret = ONENAND_IS_4KB_PAGE(this) ?
 		onenand_mlc_read_ops_nolock(mtd, from, &ops) :
 		onenand_read_ops_nolock(mtd, from, &ops);
 
@@ -3413,7 +3412,11 @@ static void onenand_check_features(struct mtd_info *mtd)
 		break;
 	}
 
-	if (ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this))
+	/* The MLC has 4KiB pagesize. */
+	if (ONENAND_IS_MLC(this))
+		this->options |= ONENAND_HAS_4KB_PAGE;
+
+	if (ONENAND_IS_4KB_PAGE(this))
 		this->options &= ~ONENAND_HAS_2PLANE;
 
 	if (FLEXONENAND(this)) {
@@ -3847,7 +3850,7 @@ static int onenand_probe(struct mtd_info *mtd)
 	/* The data buffer size is equal to page size */
 	mtd->writesize = this->read_word(this->base + ONENAND_REG_DATA_BUFFER_SIZE);
 	/* We use the full BufferRAM */
-	if (ONENAND_IS_MLC(this) || ONENAND_IS_4KB_PAGE(this))
+	if (ONENAND_IS_4KB_PAGE(this))
 		mtd->writesize <<= 1;
 
 	mtd->oobsize = mtd->writesize >> 5;


From dedekind1 at gmail.com  Wed Dec  1 22:21:22 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:21:22 +0200
Subject: [PATCH v2] mtd: Fix section mismatch on sst25l
In-Reply-To: <1290789104-1097-1-git-send-email-fabio.estevam@freescale.com>
References: <1290789104-1097-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <1291260082.14534.1.camel@koala>

On Fri, 2010-11-26 at 14:31 -0200, Fabio Estevam wrote:
> Building the kernel with 'make CONFIG_DEBUG_SECTION_MISMATCH=y?
> 
> resulted in:
> 
> WARNING: vmlinux.o(.data+0x15938): Section mismatch in reference from
> the variable sst25l_driver to the function .init.text:sst25l_probe()
> The variable sst25l_driver references
> the function __init sst25l_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

Pushed to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Wed Dec  1 22:27:08 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:27:08 +0200
Subject: [PATCH 1/8] nanddump/nandwrite: use "simple_" str functions
In-Reply-To: <1291017722-23985-1-git-send-email-computersforpeace@gmail.com>
References: <1291017722-23985-1-git-send-email-computersforpeace@gmail.com>
Message-ID: <1291260428.14534.2.camel@koala>

On Mon, 2010-11-29 at 00:01 -0800, Brian Norris wrote:
> Per Mike Frysinger's suggestion, we check for strtoll() and strtoull()
> errors by using the "common.h" helper functions simple_strtoll() and
> simple_strtoull().
> 
> Signed-off-by: Brian Norris <computersforpeace at gmail.com>

Pushed the series, picked newest patches, thanks a lot!

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



From dedekind1 at gmail.com  Wed Dec  1 22:31:24 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:31:24 +0200
Subject: [PATCH 1/3] mtd: FSMC NAND remove PARTITION macro and fix
	compile noise
In-Reply-To: <1291035126-17770-1-git-send-email-linus.walleij@stericsson.com>
References: <1291035126-17770-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1291260684.14534.3.camel@koala>

On Mon, 2010-11-29 at 13:52 +0100, Linus Walleij wrote:
> This removes the PARTITION macro that David didn't like and also
> removes a local variable that was dangling unused in some #ifdefs
> by being a bit more clever.
> 
> Signed-off-by: Linus Walleij <linus.walleij at stericsson.com>

Pushed this to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Wed Dec  1 22:35:34 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:35:34 +0200
Subject: UBIFS oops after remount ro
In-Reply-To: <20101129170223.GF23237@leila.ping.de>
References: <20101126135005.GV23237@leila.ping.de>
	<1290785057.2552.14.camel@localhost>
	<20101129131807.GB23237@leila.ping.de>
	<1291040469.2141.10.camel@koala> <20101129151729.GE23237@leila.ping.de>
	<1291049157.2141.17.camel@koala> <20101129170223.GF23237@leila.ping.de>
Message-ID: <1291260934.14534.6.camel@koala>

On Mon, 2010-11-29 at 18:02 +0100, Wolfgang Wegner wrote:
> Hi Artem,
> 
> On Mon, Nov 29, 2010 at 06:45:57PM +0200, Artem Bityutskiy wrote:
> > 
> > I cannot judge for sure, but this looks like non-UBIFS issue in 2.6.32,
> > so merging the stable 2.6.32.X tree can help. I make sense in general to
> > merge stable tree as well.
> 
> the problem is I still have some "marvell" tree
> (from git.marvell.com/orion.git) and am not sure if there is anything
> special in it.

Mostly vendors change drivers and board files. They usually do not touch
core functionality. So you can try to merge 2.6.32

> Would the "stock" 2.6.35.x from
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> be an option in your opinion, too? I seem to remember the marvell tree
> was completely merged in between (right now digging through the commits
> to make it clear), so I could get an all shiny, new kernel when having
> to do any kind of merge at all...

Probably 2.6.35 would be good.

Anyway, the problem is that I do not really have time to drive you
through debugging of your issue. I only have time to get "big" results
from you and provide some help in form of my opinion :-(

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



From dedekind1 at gmail.com  Wed Dec  1 22:41:01 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:41:01 +0200
Subject: UBIFS oops after remount ro
In-Reply-To: <1291260934.14534.6.camel@koala>
References: <20101126135005.GV23237@leila.ping.de>
	<1290785057.2552.14.camel@localhost>
	<20101129131807.GB23237@leila.ping.de>
	<1291040469.2141.10.camel@koala> <20101129151729.GE23237@leila.ping.de>
	<1291049157.2141.17.camel@koala> <20101129170223.GF23237@leila.ping.de>
	<1291260934.14534.6.camel@koala>
Message-ID: <1291261261.14534.7.camel@koala>

On Thu, 2010-12-02 at 05:35 +0200, Artem Bityutskiy wrote:
> On Mon, 2010-11-29 at 18:02 +0100, Wolfgang Wegner wrote:
> > Hi Artem,
> > 
> > On Mon, Nov 29, 2010 at 06:45:57PM +0200, Artem Bityutskiy wrote:
> > > 
> > > I cannot judge for sure, but this looks like non-UBIFS issue in 2.6.32,
> > > so merging the stable 2.6.32.X tree can help. I make sense in general to
> > > merge stable tree as well.
> > 
> > the problem is I still have some "marvell" tree
> > (from git.marvell.com/orion.git) and am not sure if there is anything
> > special in it.
> 
> Mostly vendors change drivers and board files. They usually do not touch
> core functionality. So you can try to merge 2.6.32

Err, I meant 2.6.32.x, of course, the so-called -stable tree which Greg
KH maintains.

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



From dedekind1 at gmail.com  Wed Dec  1 22:46:15 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:46:15 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101129195014.19224240@wker>
References: <20101129195014.19224240@wker>
Message-ID: <1291261575.14534.12.camel@koala>

On Mon, 2010-11-29 at 19:50 +0100, Anatolij Gustschin wrote:
> Hello,
> 
> using kernel 2.6.34.7 with applied UBI/UBIFS back-port patches from
> 2.6.34 UBIFS back-port tree and an UBIFS filesystem in a partition
> on Spansion NOR Flash S29GL512P (2 x16 chips in a 32-bit bank) we are
> not able to mount the filesystem after around 30 power cut test
> cycles. Has anyone seen similar issues before?

Hi, so, as other people indicated, the problem comes from the write
buffer size. In short, UBIFS issue you see is because of incorrect UBIFS
assumptions how your flash writes data. The right way to fix it, IMO,
is to report your write buffer size in 'struct mtd_info' and make
UBI/UBIFS use it as min_io_size. Now min_io_size is 1 for NOR in UBI and
8 in UBIFS, hardcoded.

Try to make mtd->writesize = 8 in your setup, and test again, it should
work better.

If you are interested to know why exactly UBIFS dies, what it complains
about, I can try to provide some explanation.

HTH.

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



From dedekind1 at gmail.com  Wed Dec  1 22:47:39 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:47:39 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101129203306.GA22692@postdiluvian.org>
References: <20101129195014.19224240@wker>
	<20101129203306.GA22692@postdiluvian.org>
Message-ID: <1291261659.14534.13.camel@koala>

On Mon, 2010-11-29 at 15:33 -0500, Mark Mason wrote:
> I have seen something similar in the last few months with Samsung
> K9WAG08U1B-PIB0 chips on a PowerPC 8260.  Sadly I can't be much help
> since I no longer have access to the hardware and don't have detailed
> notes anymore, but I did experience UBI/UBIFS corruption that
> prevented mounting after power cycle tests.  The frequency was
> approximately what you quote, and there was a high volume of writes to
> NAND.
> 
> Reformatting the NAND was not a big problem for us, so we went with a
> workaround and never had a chance to track down the actual problem
> before the product shipped.
> 
> Wish I could be more help.

Well, you could have reported it, I usually try to provide at least some
help...

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



From dedekind1 at gmail.com  Wed Dec  1 22:50:15 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:50:15 +0200
Subject: [PATCH v4 1/2] mtd: NOR flash driver for OMAP-L137/AM17x
In-Reply-To: <1291111325-25784-1-git-send-email-savinay.dharmappa@ti.com>
References: <1291111325-25784-1-git-send-email-savinay.dharmappa@ti.com>
Message-ID: <1291261815.14534.14.camel@koala>

On Tue, 2010-11-30 at 15:32 +0530, Savinay Dharmappa wrote:
> From: David Griego <dgriego at mvista.com>
> 
> OMAP-L137/AM17x has limited number of dedicated EMIFA
> address pins, enough to interface directly to an SDRAM.
> If a device such as an asynchronous flash needs to be
> attached to the EMIFA, then either GPIO pins or a chip
> select may be used to control the flash device's upper
> address lines.
> 
> This patch adds support for the NOR flash on the OMAP-L137/
> AM17x user interface daughter board using the latch-addr-flash
> MTD mapping driver which allows flashes to be partially
> physically addressed. The upper address lines are set by
> a board specific code which is a separate patch.
> 
> Signed-off-by: David Griego <dgriego at mvista.com>
> Signed-off-by: Aleksey Makarov <amakarov at ru.mvista.com>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> Signed-off-by: Savinay Dharmappa <savinay.dharmappa at ti.com>

Pushed these to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Wed Dec  1 22:51:39 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 05:51:39 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <4CF4D4CA.8040906@aimvalley.nl>
References: <20101129195014.19224240@wker>  <4CF4D4CA.8040906@aimvalley.nl>
Message-ID: <1291261899.14534.15.camel@koala>

On Tue, 2010-11-30 at 11:41 +0100, Norbert van Bolhuis wrote:
> Did you read the mail discussions
> "UBIFS Corrupt during power failure"
> dated april 2009 from Eric Holmberg.
> 
> He did some great work in making UBIFS on NOR flash
> more reliable for power-cuts.
> 
> One of the problems was UBI/UBIFS assumes a (CFI) write
> buffer size of 8 bytes. Maybe this is still the case.
> I think for your NOR flash it is 64 bytes though.

Would be nice if someone exposed this write buffer size in struct
mtd_info, then UBI/UBIFS could just use it.

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



From dedekind1 at gmail.com  Wed Dec  1 23:01:32 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 06:01:32 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101201164447.2215bc58@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker>
Message-ID: <1291262492.14534.23.camel@koala>

On Wed, 2010-12-01 at 16:44 +0100, Anatolij Gustschin wrote:
> On Wed, 1 Dec 2010 13:05:34 +0100
> Anatolij Gustschin <agust at denx.de> wrote:
> ... 
> > My question is:
> > Is it possible that the reset occured while running in
> > nor_erase_prepare() just after clearing the VID header magic,
> > but before clearing the EC header magic?
> 
> yes, it is possible and it seems this is the reason for
> that next issue we've observed. Adding the call to the
> machine restart callback in nor_erase_prepare() just before
> clearing EC header magic to simulate this hypothetical case
> we see:
> ...
> UBI DBG (pid 1287): ubi_eba_read_leb: read 160 bytes from offset 80112 of LEB 0:10, PEB 12
> UBI DBG (pid 1287): ubi_close_volume: close device 0, volume 0, mode 1
> nor_erase_prepare: ### RESET before clearing EC magic in peb # 177, off: 0xf6780000
> 
> and now we dump the EC and VID headers and some UBIFS
> nodes of the PEB # 177:
> 
> => md f6780000 50
> f6780000: 55424923 01000000 00000000 00000034    UBI#...........4
> f6780010: 00000040 00000080 753746f3 00000000    ... at ....u7F.....
> f6780020: 00000000 00000000 00000000 00000000    ................
> f6780030: 00000000 00000000 00000000 6533c6f3    ............e3..
> f6780040: 00000000 01010000 00000000 00000004    ................
> f6780050: 00000000 00000000 00000000 00000000    ................
> f6780060: 00000000 00000000 00000000 00003343    ..............3C
> f6780070: 00000000 00000000 00000000 478a9cae    ............G...
> f6780080: 31181006 f0deeea3 20b21600 00000000    1....... .......
> f6780090: 20000000 0a000000 49040000 00000000     .......I.......
> f67800a0: 31181006 5412d762 21b21600 00000000    1...T..b!.......
> f67800b0: 40000000 08000000 1c000000 30920300    @...........0...
> f67800c0: 01000000 0001c808 0001c808 00000005    ................
> f67800d0: 00040000 00000001 0001cc60 0005cc60    ...........`...`
> f67800e0: 31181006 2a49116c 22b21600 00000000    1...*I.l".......
> f67800f0: 40000000 08000000 16000000 60230100    @...........`#..
> f6780100: 02000000 00000000 bfaf7600 c0000000    ..........v.....
> f6780110: 00000000 00000000 00000000 00000000    ................
> f6780120: ffffffff ffffffff ffffffff ffffffff    ................
> f6780130: ffffffff ffffffff ffffffff ffffffff    ................
> 
> After booting Linux and attaching the MTD device I can see
> very similar things happen:
> ...
> UBI DBG (pid 1277): ubi_scan: process PEB 177
> UBI DBG (pid 1277): process_eb: scan PEB 177
> UBI DBG (pid 1277): ubi_io_read_vid_hdr: bad magic number at PEB 177: 00000000 instead of 55424921
> UBI error: check_corruption: PEB 177 contains corrupted VID header, and the data does not contain all 0xFF, this may be a non-UBI PEB or a severe VID header corruption which requires manual inspection

Oh oh, this is my new shiny code which is supposed to make UBI more
careful about not wiping corrupted eraseblocks.

Someone reported a problem that his eraseblocks disappear, and I though
this might be because the corrupt partially, e.g., the VID headers
becomes corrupted, and then UBI just wipes them, and leaves no chance
to look at what exactly was corrupted and possibly find the root cause.

So, my new shiny code simply misses the NOR case, where we have this
quirk, where we deliberately corrupt the VID header before erasing.
And if you have a power cut before you have erased but after you have
invalidated the VID header, UBI thinks the PEB is one of those corrupted
ones and it should be preserved.

Take a look at scan.h header comment - I tried to explained the logic.

Anyway, this code is broken for NOR, apparently. This code was merged
only to 2.6.37, so it was not released, and we have chance to fix it.
Or disabled it for NOR.

For quick test, please, hack UBI and make check_corruption() in scan.c
always return 0. Than you effectively disable this new shiny buggy
feature.

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



From mason at postdiluvian.org  Wed Dec  1 23:10:48 2010
From: mason at postdiluvian.org (Mark Mason)
Date: Wed, 1 Dec 2010 23:10:48 -0500
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291261659.14534.13.camel@koala>
References: <20101129195014.19224240@wker>
	<20101129203306.GA22692@postdiluvian.org>
	<1291261659.14534.13.camel@koala>
Message-ID: <20101202041048.GA5998@postdiluvian.org>

Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Mon, 2010-11-29 at 15:33 -0500, Mark Mason wrote:
> > I have seen something similar in the last few months with Samsung
> > K9WAG08U1B-PIB0 chips on a PowerPC 8260.  Sadly I can't be much help
> > since I no longer have access to the hardware and don't have detailed
> > notes anymore, but I did experience UBI/UBIFS corruption that
> > prevented mounting after power cycle tests.  The frequency was
> > approximately what you quote, and there was a high volume of writes to
> > NAND.
> > 
> > Reformatting the NAND was not a big problem for us, so we went with a
> > workaround and never had a chance to track down the actual problem
> > before the product shipped.
> > 
> > Wish I could be more help.
> 
> Well, you could have reported it, I usually try to provide at least
> some help...

Yes, I could have, and I should have, and I intended to, etc.
Unfortunately "market conditions prevailed", the product shipped, and
I wasn't needed anymore.

Plus, I meant to say 8315, not 8260.  Maybe the two bus controllers
are too similar, or maybe I've just inhaled too much flux.


From dedekind1 at gmail.com  Wed Dec  1 23:42:06 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 06:42:06 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101201164447.2215bc58@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker>
Message-ID: <1291264926.14534.32.camel@koala>

On Wed, 2010-12-01 at 16:44 +0100, Anatolij Gustschin wrote:
> On Wed, 1 Dec 2010 13:05:34 +0100
> Anatolij Gustschin <agust at denx.de> wrote:
> ... 
> > My question is:
> > Is it possible that the reset occured while running in
> > nor_erase_prepare() just after clearing the VID header magic,
> > but before clearing the EC header magic?
> 
> yes, it is possible and it seems this is the reason for
> that next issue we've observed. Adding the call to the
> machine restart callback in nor_erase_prepare() just before
> clearing EC header magic to simulate this hypothetical case
> we see:
You are right, Anatoli.

Looking closer to my own code, I see that I treat PEB as
"corrupted and should be preserved" if:

1. EC header is OK.
2. VID header is corrupted.
3. data area is not "all 0xFFs".

And in 'nor_erase_prepare()' we first invalidate the VID header, and
then invalidate the EC header. So there is a small window where you can
end up with all 3 conditions to be true.

The solution is to first invalidate the EC header, and only then the VID
header. Then in case of the race, we just lose the EC header, but VID
header will be all-right, and UBI will handle this - it'll move the data
from this PEB to another one, re-create EC header and use average EC
count. But if you test this scenario, it will be great!!

This patch should help (compile-tested only).




From Artem.Bityutskiy at nokia.com  Wed Dec  1 23:34:01 2010
From: Artem.Bityutskiy at nokia.com (Artem Bityutskiy)
Date: Thu, 2 Dec 2010 06:34:01 +0200
Subject: [PATCH] UBI: fix corrupted PEB detection for NOR flash
Message-ID: <mailman.33.1291265162.1530.linux-mtd@lists.infradead.org>

My new shiny code for corrupted PEB detection has NOR specific bug.
We tread PEB as corrupted and preserve it, if

1. EC header is OK.
2. VID header is corrupted.
3. data area is not "all 0xFFs"

In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
the headers before erasing the PEB. And we invalidate first the VID
header, and then the EC header. So if a power cut happens after we have
invalidated the VID header, but before we have invalidated the EC
header, we end up with a PEB which satisfies the above 3 conditions,
and the scanning code will treat it as corrupted, and will print
scary warnings, wrongly.

This patch fixes the issue by firt invalidating the EC header, then
invalidating the VID header. In case of power cut inbetween, we still
just lose the EC header, and UBI can deal with this situation gracefully.

This patch also adds one irrelevant comment about defining VID header
buffer on stack.

Thanks to Anatolij Gustschin <agust at denx.de> for tracking this down.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
Reported-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/ubi/io.c   |   37 ++++++++++++++++++++++++++++---------
 drivers/mtd/ubi/scan.c |    4 ++++
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index c2960ac..3839253 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -480,12 +480,26 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum)
 	size_t written;
 	loff_t addr;
 	uint32_t data = 0;
+	/*
+	 * Note, we cannot generally define VID header buffers on stack,
+	 * because of the way we deal with these buffers (see the heder
+	 * comment). But we know this is NOR-specific piece of code, so we can
+	 * do this. But yes, this is error-prone and we should (pre-)allocate
+	 * VID header buffer instead.
+	 */
 	struct ubi_vid_hdr vid_hdr;
 
-	addr = (loff_t)pnum * ubi->peb_size + ubi->vid_hdr_aloffset;
+	/*
+	 * Note, it is important to first invalidate the EC header, and then
+	 * VID header. Otherwise a power cut may result in valid EC header and
+	 * invalid VID header, then UBI will treat this PEB as corrupted and
+	 * will try to preserve it, print scary warnings. See scan.c header
+	 * comment for more information.
+	 */
+	addr = (loff_t)pnum * ubi->peb_size;
 	err = ubi->mtd->write(ubi->mtd, addr, 4, &written, (void *)&data);
 	if (!err) {
-		addr -= ubi->vid_hdr_aloffset;
+		addr += ubi->vid_hdr_aloffset;
 		err = ubi->mtd->write(ubi->mtd, addr, 4, &written,
 				      (void *)&data);
 		if (!err)
@@ -499,13 +513,18 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum)
 	 * In this case we probably anyway have garbage in this PEB.
 	 */
 	err1 = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0);
-	if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR)
-		/*
-		 * The VID header is corrupted, so we can safely erase this
-		 * PEB and not afraid that it will be treated as a valid PEB in
-		 * case of an unclean reboot.
-		 */
-		return 0;
+	if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR) {
+		struct ubi_ec_hdr ec_hdr;
+
+		err1 = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0);
+		if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR)
+			/*
+			 * The VID and EC headers are corrupted, so we can
+			 * safely erase this PEB and not afraid that it will be
+			 * treated as a valid PEB in case of an unclean reboot.
+			 */
+			return 0;
+	}
 
 	/*
 	 * The PEB contains a valid VID header, but we cannot invalidate it.
diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c
index 3c63186..d4b1115 100644
--- a/drivers/mtd/ubi/scan.c
+++ b/drivers/mtd/ubi/scan.c
@@ -951,6 +951,10 @@ static int process_eb(struct ubi_device *ubi, struct ubi_scan_info *si,
 			 * impossible to distinguish it from a PEB which just
 			 * contains garbage because of a power cut during erase
 			 * operation. So we just schedule this PEB for erasure.
+			 *
+			 * Besides, in case of NOR flash, we deliberatly
+			 * corrupt both headers because NOR flash erasure is
+			 * slow and can start from the end.
 			 */
 			err = 0;
 		else
-- 
1.7.3.2

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



From dzu at denx.de  Thu Dec  2 04:17:36 2010
From: dzu at denx.de (Detlev Zundel)
Date: Thu, 02 Dec 2010 10:17:36 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101202041048.GA5998@postdiluvian.org> (Mark Mason's message of
	"Wed, 1 Dec 2010 23:10:48 -0500")
References: <20101129195014.19224240@wker>
	<20101129203306.GA22692@postdiluvian.org>
	<1291261659.14534.13.camel@koala>
	<20101202041048.GA5998@postdiluvian.org>
Message-ID: <m2hbew355b.fsf@ohwell.denx.de>

Hi Mark,

[...]

>>From the same project, I do have some improvements to the MPC8315 NAND
> driver that allows higher bus throughput during erase cycles.  There's
> a chance that this is applicable to other NAND controllers, but my
> experience is limited.  I'd be more than happy to share my work with
> someone who has an interest in the 83xx, and I promise that I will do
> a better job at the details than I did with the CPUs in question.

Please do post your changes to the linuxppc-dev[1] mailing list.  There
are a lot of people with interst on the 83xx chips there.

Thanks!
  Detlev

[1] https://lists.ozlabs.org/listinfo/linuxppc-dev

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de


From wolfgang at leila.ping.de  Thu Dec  2 04:17:33 2010
From: wolfgang at leila.ping.de (Wolfgang Wegner)
Date: Thu, 2 Dec 2010 10:17:33 +0100
Subject: UBIFS oops after remount ro
In-Reply-To: <1291260934.14534.6.camel@koala>
References: <20101126135005.GV23237@leila.ping.de>
	<1290785057.2552.14.camel@localhost>
	<20101129131807.GB23237@leila.ping.de>
	<1291040469.2141.10.camel@koala>
	<20101129151729.GE23237@leila.ping.de>
	<1291049157.2141.17.camel@koala>
	<20101129170223.GF23237@leila.ping.de>
	<1291260934.14534.6.camel@koala>
Message-ID: <20101202091733.GM23237@leila.ping.de>

Hi Artem,

On Thu, Dec 02, 2010 at 05:35:34AM +0200, Artem Bityutskiy wrote:
> 
> Mostly vendors change drivers and board files. They usually do not touch
> core functionality. So you can try to merge 2.6.32

there had in fact been some special ARM and/or kirkwood things in this
2.6.32 release, but meanwhile this is all integrated into mainline, as
far as I can see.

> Probably 2.6.35 would be good.

I merged our (very few) local changes into 2.6.36 and am now running
this.

> Anyway, the problem is that I do not really have time to drive you
> through debugging of your issue. I only have time to get "big" results
> from you and provide some help in form of my opinion :-(

Thank you very much for your hints and help so far!

The big result I can give is that I already got this oops once with
2.6.36, too - but could not reproduce it. I also have some other thing
to fix right now, but in case I get back to the problem, I will of
course post results (if any) - thanks to you I now got some pointers
where I can start debugging, this is already great and valuable help.

Regards,
Wolfgang



From matthieu.castet at parrot.com  Thu Dec  2 04:46:49 2010
From: matthieu.castet at parrot.com (Matthieu CASTET)
Date: Thu, 2 Dec 2010 10:46:49 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291264926.14534.32.camel@koala>
References: <20101129195014.19224240@wker>
	<20101201130534.5b95ce83@wker>	<20101201164447.2215bc58@wker>
	<1291264926.14534.32.camel@koala>
Message-ID: <4CF76B09.1020503@parrot.com>

Hi,

Artem Bityutskiy a ?crit :
> On Wed, 2010-12-01 at 16:44 +0100, Anatolij Gustschin wrote:
>> On Wed, 1 Dec 2010 13:05:34 +0100
>> Anatolij Gustschin <agust at denx.de> wrote:
>> ... 
>>> My question is:
>>> Is it possible that the reset occured while running in
>>> nor_erase_prepare() just after clearing the VID header magic,
>>> but before clearing the EC header magic?
>> yes, it is possible and it seems this is the reason for
>> that next issue we've observed. Adding the call to the
>> machine restart callback in nor_erase_prepare() just before
>> clearing EC header magic to simulate this hypothetical case
>> we see:
> You are right, Anatoli.
> 
> Looking closer to my own code, I see that I treat PEB as
> "corrupted and should be preserved" if:
> 
> 1. EC header is OK.
> 2. VID header is corrupted.
> 3. data area is not "all 0xFFs".
> 
> And in 'nor_erase_prepare()' we first invalidate the VID header, and
> then invalidate the EC header. So there is a small window where you can
> end up with all 3 conditions to be true.
> 
> The solution is to first invalidate the EC header, and only then the VID
> header. Then in case of the race, we just lose the EC header, but VID
> header will be all-right, and UBI will handle this - it'll move the data
> from this PEB to another one, re-create EC header and use average EC
> count. But if you test this scenario, it will be great!!
> 
> This patch should help (compile-tested only).
> 
Shouldn't the correct solution will come with handling unstable page 
problem [1] ?

Matthieu

[1]
never trust a page where write/erase was interrupted.


From agust at denx.de  Thu Dec  2 04:57:29 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 2 Dec 2010 10:57:29 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291264926.14534.32.camel@koala>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
Message-ID: <20101202105729.04c25fc1@wker>

Hi,

On Thu, 02 Dec 2010 06:42:06 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:
...
> Looking closer to my own code, I see that I treat PEB as
> "corrupted and should be preserved" if:
> 
> 1. EC header is OK.
> 2. VID header is corrupted.
> 3. data area is not "all 0xFFs".
> 
> And in 'nor_erase_prepare()' we first invalidate the VID header, and
> then invalidate the EC header. So there is a small window where you can
> end up with all 3 conditions to be true.
> 
> The solution is to first invalidate the EC header, and only then the VID
> header. Then in case of the race, we just lose the EC header, but VID
> header will be all-right, and UBI will handle this - it'll move the data
> from this PEB to another one, re-create EC header and use average EC
> count. But if you test this scenario, it will be great!!

I'll test this patch, and already tried to test similar change
but stumbled on another problem, please see more below.

> 
> This patch should help (compile-tested only).
> 
> 
> 
> From 7ddb9cb80ab54d118e2a055ce7a35649070578b1 Mon Sep 17 00:00:00 2001
> From: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> Date: Thu, 2 Dec 2010 06:34:01 +0200
> Subject: [PATCH] UBI: fix corrupted PEB detection for NOR flash
> 
> My new shiny code for corrupted PEB detection has NOR specific bug.
> We tread PEB as corrupted and preserve it, if
> 
> 1. EC header is OK.
> 2. VID header is corrupted.
> 3. data area is not "all 0xFFs"
> 
> In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
> the headers before erasing the PEB. And we invalidate first the VID
> header, and then the EC header. So if a power cut happens after we have
> invalidated the VID header, but before we have invalidated the EC
> header, we end up with a PEB which satisfies the above 3 conditions,
> and the scanning code will treat it as corrupted, and will print
> scary warnings, wrongly.
> 
> This patch fixes the issue by firt invalidating the EC header, then
> invalidating the VID header. In case of power cut inbetween, we still
> just lose the EC header, and UBI can deal with this situation gracefully.
> 
> This patch also adds one irrelevant comment about defining VID header
> buffer on stack.
> 
> Thanks to Anatolij Gustschin <agust at denx.de> for tracking this down.
> 
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> Reported-by: Anatolij Gustschin <agust at denx.de>
> ---
>  drivers/mtd/ubi/io.c   |   37 ++++++++++++++++++++++++++++---------
>  drivers/mtd/ubi/scan.c |    4 ++++
>  2 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index c2960ac..3839253 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -480,12 +480,26 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum)
>  	size_t written;
>  	loff_t addr;
>  	uint32_t data = 0;
> +	/*
> +	 * Note, we cannot generally define VID header buffers on stack,
> +	 * because of the way we deal with these buffers (see the heder
> +	 * comment). But we know this is NOR-specific piece of code, so we can
> +	 * do this. But yes, this is error-prone and we should (pre-)allocate
> +	 * VID header buffer instead.
> +	 */
>  	struct ubi_vid_hdr vid_hdr;
>  
> -	addr = (loff_t)pnum * ubi->peb_size + ubi->vid_hdr_aloffset;
> +	/*
> +	 * Note, it is important to first invalidate the EC header, and then
> +	 * VID header. Otherwise a power cut may result in valid EC header and
> +	 * invalid VID header, then UBI will treat this PEB as corrupted and
> +	 * will try to preserve it, print scary warnings. See scan.c header
> +	 * comment for more information.
> +	 */
> +	addr = (loff_t)pnum * ubi->peb_size;
>  	err = ubi->mtd->write(ubi->mtd, addr, 4, &written, (void *)&data);
>  	if (!err) {
> -		addr -= ubi->vid_hdr_aloffset;
> +		addr += ubi->vid_hdr_aloffset;
>  		err = ubi->mtd->write(ubi->mtd, addr, 4, &written,
>  				      (void *)&data);
>  		if (!err)

yesterday I inverted the sequence of magic number's erasure to
first erase EC header magic and then VID header magic as it was
before commit 5b289b56 and thus in the same way as in the hunk
above. I did it to be able to run further tests of robustness
with 8 byte write buffer. Nightly test was running then, but now
after the test cycle 1011 I see another issue while scanning a
corrupted UBIFS node:

...
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 41:252784 (9232 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 41:256928 (5088 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 41:261072 (944 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: hit empty space
UBIFS DBG (pid 1290): ubifs_end_scan: stop scanning LEB 41 at offset 261072
UBIFS DBG (pid 1290): ubifs_recover_leb: 37:0
UBIFS DBG (pid 1290): ubifs_start_scan: scan LEB 37:0
UBI DBG (pid 1290): ubi_leb_read: read 262016 bytes from LEB 0:37:0
UBI DBG (pid 1290): ubi_eba_read_leb: read 262016 bytes from offset 0 of LEB 0:37, PEB 32
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:0 (262016 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:4144 (257872 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:8288 (253728 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:12432 (249584 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:16576 (245440 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:20720 (241296 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:24864 (237152 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:29008 (233008 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:33152 (228864 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:37296 (224720 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:41440 (220576 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:45584 (216432 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:49728 (212288 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:53872 (208144 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:58016 (204000 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:62160 (199856 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:66304 (195712 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:70448 (191568 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:74592 (187424 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:78736 (183280 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:82880 (179136 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:87024 (174992 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:91168 (170848 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:95312 (166704 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:99456 (162560 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:103600 (158416 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:107744 (154272 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:111888 (150128 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:116032 (145984 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:120176 (141840 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:124320 (137696 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:128464 (133552 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:132608 (129408 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:136752 (125264 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:140896 (121120 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:145040 (116976 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:149184 (112832 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:153328 (108688 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning data node
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:157472 (104544 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning unknown node
UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
UBIFS DBG (pid 1290): ubifs_recover_leb: look at LEB 37:157472 (104544 bytes left)
UBIFS DBG (pid 1290): ubifs_scan_a_node: scanning unknown node
UBIFS error (pid 1290): ubifs_check_node: bad node type 255
UBIFS error (pid 1290): ubifs_check_node: bad node at LEB 37:157472
	magic          0x6101831
	crc            0xc8580727
	node_type      255 (unknown node)
	group_type     255 (unknown)
	sqnum          1389324
	len            4294967295
node type 255 was not recognized
Call Trace:
[c601fb80] [c0007ecc] show_stack+0x4c/0x16c (unreliable)
[c601fbc0] [c013e980] ubifs_check_node+0x17c/0x308
[c601fbe0] [c0147dec] ubifs_scan_a_node+0x15c/0x2d8
[c601fc10] [c015d1c0] ubifs_recover_leb+0x3f0/0x940
[c601fc80] [c01486fc] replay_buds+0xb4/0xb4c
[c601fd20] [c0149894] ubifs_replay_journal+0x700/0xf48
[c601fda0] [c013b060] ubifs_fill_super+0xda0/0x1600
[c601fe00] [c013cbb4] ubifs_get_sb+0x10c/0x344
[c601fe80] [c007b9a4] vfs_kern_mount+0x60/0x150
[c601fea0] [c007bae4] do_kern_mount+0x40/0x100
[c601fec0] [c00926c0] do_mount+0x40c/0x718
[c601ff10] [c0092a5c] sys_mount+0x90/0xd8
[c601ff40] [c0010b44] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe93d18
    LR = 0x1000347c
UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
UBIFS error (pid 1290): ubifs_recover_leb: bad node
UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
*
00001fc0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
00001fe0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
UBIFS error (pid 1290): ubifs_recover_leb: LEB 37 scanning failed
UBIFS DBG (pid 1292): ubifs_bg_thread: background thread "ubifs_bgt0_0" stops
UBI DBG (pid 1290): ubi_close_volume: close device 0, volume 0, mode 2
UBI DBG (pid 1290): ubi_close_volume: close device 0, volume 0, mode 1
mount: Structure needs cleaning

At first glance, it seems, a write was interrupted and we have a
corruption in an UBIFS data node and we can't recover.

Thanks for your help and answers so far!
Anatolij


From dedekind1 at gmail.com  Thu Dec  2 07:18:45 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 14:18:45 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101202105729.04c25fc1@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker>
Message-ID: <1291292325.2526.23.camel@localhost>

On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> UBIFS error (pid 1290): ubifs_recover_leb: bad node
> UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 

But this looks exactly like you have 64-bit write-buffer, but UBIFS
c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
force 8-bytes write-buffer.

Are you sure you did not miss your NOR write-buffer hacks?

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



From dedekind1 at gmail.com  Thu Dec  2 07:18:49 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 14:18:49 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <4CF76B09.1020503@parrot.com>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<4CF76B09.1020503@parrot.com>
Message-ID: <1291292329.2526.24.camel@localhost>

On Thu, 2010-12-02 at 10:46 +0100, Matthieu CASTET wrote:
> Hi,
> 
> Artem Bityutskiy a ?crit :
> > On Wed, 2010-12-01 at 16:44 +0100, Anatolij Gustschin wrote:
> >> On Wed, 1 Dec 2010 13:05:34 +0100
> >> Anatolij Gustschin <agust at denx.de> wrote:
> >> ... 
> >>> My question is:
> >>> Is it possible that the reset occured while running in
> >>> nor_erase_prepare() just after clearing the VID header magic,
> >>> but before clearing the EC header magic?
> >> yes, it is possible and it seems this is the reason for
> >> that next issue we've observed. Adding the call to the
> >> machine restart callback in nor_erase_prepare() just before
> >> clearing EC header magic to simulate this hypothetical case
> >> we see:
> > You are right, Anatoli.
> > 
> > Looking closer to my own code, I see that I treat PEB as
> > "corrupted and should be preserved" if:
> > 
> > 1. EC header is OK.
> > 2. VID header is corrupted.
> > 3. data area is not "all 0xFFs".
> > 
> > And in 'nor_erase_prepare()' we first invalidate the VID header, and
> > then invalidate the EC header. So there is a small window where you can
> > end up with all 3 conditions to be true.
> > 
> > The solution is to first invalidate the EC header, and only then the VID
> > header. Then in case of the race, we just lose the EC header, but VID
> > header will be all-right, and UBI will handle this - it'll move the data
> > from this PEB to another one, re-create EC header and use average EC
> > count. But if you test this scenario, it will be great!!
> > 
> > This patch should help (compile-tested only).
> > 
> Shouldn't the correct solution will come with handling unstable page 
> problem [1] ?

Err, yes, these things are related, but it is long way to go before we
have the unstable bits issues solved. The NOR quirk is the current
solution for slow and peculiar NOR erasure, it works, and should be kept
working, I think.

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



From dedekind1 at gmail.com  Thu Dec  2 07:20:33 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 14:20:33 +0200
Subject: UBIFS oops after remount ro
In-Reply-To: <20101202091733.GM23237@leila.ping.de>
References: <20101126135005.GV23237@leila.ping.de>
	<1290785057.2552.14.camel@localhost>
	<20101129131807.GB23237@leila.ping.de>
	<1291040469.2141.10.camel@koala> <20101129151729.GE23237@leila.ping.de>
	<1291049157.2141.17.camel@koala> <20101129170223.GF23237@leila.ping.de>
	<1291260934.14534.6.camel@koala> <20101202091733.GM23237@leila.ping.de>
Message-ID: <1291292433.2526.26.camel@localhost>

On Thu, 2010-12-02 at 10:17 +0100, Wolfgang Wegner wrote:
> Hi Artem,
> 
> On Thu, Dec 02, 2010 at 05:35:34AM +0200, Artem Bityutskiy wrote:
> > 
> > Mostly vendors change drivers and board files. They usually do not touch
> > core functionality. So you can try to merge 2.6.32
> 
> there had in fact been some special ARM and/or kirkwood things in this
> 2.6.32 release, but meanwhile this is all integrated into mainline, as
> far as I can see.
> 
> > Probably 2.6.35 would be good.
> 
> I merged our (very few) local changes into 2.6.36 and am now running
> this.
> 
> > Anyway, the problem is that I do not really have time to drive you
> > through debugging of your issue. I only have time to get "big" results
> > from you and provide some help in form of my opinion :-(
> 
> Thank you very much for your hints and help so far!
> 
> The big result I can give is that I already got this oops once with
> 2.6.36, too - but could not reproduce it. I also have some other thing
> to fix right now, but in case I get back to the problem, I will of
> course post results (if any) - thanks to you I now got some pointers
> where I can start debugging, this is already great and valuable help.

The same oops? If yes, then this is not 2.6.32-specific issue, then you
should preserve your 2.6.32 setup and dig further, I think. Having a
setup where you can reproduce the bug is very nice thing :-)

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



From agust at denx.de  Thu Dec  2 08:23:51 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 2 Dec 2010 14:23:51 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291292325.2526.23.camel@localhost>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker> <1291292325.2526.23.camel@localhost>
Message-ID: <20101202142351.197abbde@wker>

On Thu, 02 Dec 2010 14:18:45 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> 
> But this looks exactly like you have 64-bit write-buffer, but UBIFS
> c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> force 8-bytes write-buffer.

This looks exactly like I have a 16 byte write buffer. The first
16 bytes of the common header node have been written correctly but
the remaining 8 bytes of the common header and then the 8 bytes of
the data are corrupt.
> 
> Are you sure you did not miss your NOR write-buffer hacks?

I'm sure that the kernel running this test uses the modification in
the CFI code as follows:
diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
index e63e674..9eb47b8 100644
--- a/drivers/mtd/chips/cfi_probe.c
+++ b/drivers/mtd/chips/cfi_probe.c
@@ -213,6 +213,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
        cfi->cfiq->InterfaceDesc = le16_to_cpu(cfi->cfiq->InterfaceDesc);
        cfi->cfiq->MaxBufWriteSize = le16_to_cpu(cfi->cfiq->MaxBufWriteSize);
 
+       /*printk("NOTE: change CFI MaxBufWriteSize from 2^%d to 2^%d\n",*/
+       /*cfi->cfiq->MaxBufWriteSize, 3);*/
+       if (cfi->cfiq->MaxBufWriteSize) {
+               cfi->cfiq->MaxBufWriteSize = 3;
+       }
+

But I'm not sure whether the CFI driver is really using 8 byte
write buffer since the error pattern indicates the usage of a
bigger buffer. I'll check the actual size used in the CFI driver
at runtime.

Thanks,
Anatolij


From roman.tereshonkov at nokia.com  Thu Dec  2 08:28:38 2010
From: roman.tereshonkov at nokia.com (Roman Tereshonkov)
Date: Thu,  2 Dec 2010 15:28:38 +0200
Subject: [PATCH] mtd: onenand: bugfix for 2x mode bad block handling
Message-ID: <1291296518-31566-1-git-send-email-roman.tereshonkov@nokia.com>

This bug becomes visible in 2x mode when chip->writesize
is different from mtd->writesize (= 2 * chip->writesize).
At this case the bad block information is read from
the first and the third physical pages instead of
the first and the second as specification states.

Signed-off-by: Roman Tereshonkov <roman.tereshonkov at nokia.com>
---
 drivers/mtd/onenand/onenand_bbt.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
index 01ab5b3..905209b 100644
--- a/drivers/mtd/onenand/onenand_bbt.c
+++ b/drivers/mtd/onenand/onenand_bbt.c
@@ -91,13 +91,15 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
 		for (j = 0; j < len; j++) {
 			/* No need to read pages fully,
 			 * just read required OOB bytes */
-			ret = onenand_bbt_read_oob(mtd, from + j * mtd->writesize + bd->offs, &ops);
+			ret = onenand_bbt_read_oob(mtd,
+				from + j * this->writesize + bd->offs, &ops);
 
 			/* If it is a initial bad block, just ignore it */
 			if (ret == ONENAND_BBT_READ_FATAL_ERROR)
 				return -EIO;
 
-			if (ret || check_short_pattern(&buf[j * scanlen], scanlen, mtd->writesize, bd)) {
+			if (ret || check_short_pattern(&buf[j * scanlen],
+					       scanlen, this->writesize, bd)) {
 				bbm->bbt[i >> 3] |= 0x03 << (i & 0x6);
 				printk(KERN_WARNING "Bad eraseblock %d at 0x%08x\n",
 					i >> 1, (unsigned int) from);
-- 
1.7.0.4



From dedekind1 at gmail.com  Thu Dec  2 08:35:51 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 15:35:51 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101202142351.197abbde@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker> <1291292325.2526.23.camel@localhost>
	<20101202142351.197abbde@wker>
Message-ID: <1291296951.2526.34.camel@localhost>

On Thu, 2010-12-02 at 14:23 +0100, Anatolij Gustschin wrote:
> On Thu, 02 Dec 2010 14:18:45 +0200
> Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> 
> > On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> > 
> > But this looks exactly like you have 64-bit write-buffer, but UBIFS
> > c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> > force 8-bytes write-buffer.
> 
> This looks exactly like I have a 16 byte write buffer. The first
> 16 bytes of the common header node have been written correctly but
> the remaining 8 bytes of the common header and then the 8 bytes of
> the data are corrupt.
> > 
> > Are you sure you did not miss your NOR write-buffer hacks?
> 
> I'm sure that the kernel running this test uses the modification in
> the CFI code as follows:
> diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
> index e63e674..9eb47b8 100644
> --- a/drivers/mtd/chips/cfi_probe.c
> +++ b/drivers/mtd/chips/cfi_probe.c
> @@ -213,6 +213,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
>         cfi->cfiq->InterfaceDesc = le16_to_cpu(cfi->cfiq->InterfaceDesc);
>         cfi->cfiq->MaxBufWriteSize = le16_to_cpu(cfi->cfiq->MaxBufWriteSize);
>  
> +       /*printk("NOTE: change CFI MaxBufWriteSize from 2^%d to 2^%d\n",*/
> +       /*cfi->cfiq->MaxBufWriteSize, 3);*/
> +       if (cfi->cfiq->MaxBufWriteSize) {
> +               cfi->cfiq->MaxBufWriteSize = 3;
> +       }
> +
> 
> But I'm not sure whether the CFI driver is really using 8 byte
> write buffer since the error pattern indicates the usage of a
> bigger buffer. I'll check the actual size used in the CFI driver
> at runtime.

Can you instead make mtd->writesize to be 64? This is much closer to the
"right thing to do" :-)

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



From agust at denx.de  Thu Dec  2 08:50:27 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 2 Dec 2010 14:50:27 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291296951.2526.34.camel@localhost>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker> <1291292325.2526.23.camel@localhost>
	<20101202142351.197abbde@wker> <1291296951.2526.34.camel@localhost>
Message-ID: <20101202145027.266b30a6@wker>

On Thu, 02 Dec 2010 15:35:51 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Thu, 2010-12-02 at 14:23 +0100, Anatolij Gustschin wrote:
> > On Thu, 02 Dec 2010 14:18:45 +0200
> > Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > 
> > > On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > > > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > > > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > > > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > > > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > > > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> > > 
> > > But this looks exactly like you have 64-bit write-buffer, but UBIFS
> > > c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> > > force 8-bytes write-buffer.
> > 
> > This looks exactly like I have a 16 byte write buffer. The first
> > 16 bytes of the common header node have been written correctly but
> > the remaining 8 bytes of the common header and then the 8 bytes of
> > the data are corrupt.
> > > 
> > > Are you sure you did not miss your NOR write-buffer hacks?
> > 
> > I'm sure that the kernel running this test uses the modification in
> > the CFI code as follows:
> > diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
> > index e63e674..9eb47b8 100644
> > --- a/drivers/mtd/chips/cfi_probe.c
> > +++ b/drivers/mtd/chips/cfi_probe.c
> > @@ -213,6 +213,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
> >         cfi->cfiq->InterfaceDesc = le16_to_cpu(cfi->cfiq->InterfaceDesc);
> >         cfi->cfiq->MaxBufWriteSize = le16_to_cpu(cfi->cfiq->MaxBufWriteSize);
> >  
> > +       /*printk("NOTE: change CFI MaxBufWriteSize from 2^%d to 2^%d\n",*/
> > +       /*cfi->cfiq->MaxBufWriteSize, 3);*/
> > +       if (cfi->cfiq->MaxBufWriteSize) {
> > +               cfi->cfiq->MaxBufWriteSize = 3;
> > +       }
> > +
> > 
> > But I'm not sure whether the CFI driver is really using 8 byte
> > write buffer since the error pattern indicates the usage of a
> > bigger buffer. I'll check the actual size used in the CFI driver
> > at runtime.
> 
> Can you instead make mtd->writesize to be 64? This is much closer to the
> "right thing to do" :-)

Yes. But I also must ensure that the buffer size configured in
cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
is not the case, it seems. If this is true, then I'll still run
into the similar trouble even when using 64 for max_io_size in UBI.

Thanks,
Anatolij


From dedekind1 at gmail.com  Thu Dec  2 08:57:56 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 02 Dec 2010 15:57:56 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101202145027.266b30a6@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker> <1291292325.2526.23.camel@localhost>
	<20101202142351.197abbde@wker> <1291296951.2526.34.camel@localhost>
	<20101202145027.266b30a6@wker>
Message-ID: <1291298276.2526.44.camel@localhost>

On Thu, 2010-12-02 at 14:50 +0100, Anatolij Gustschin wrote:
> > Can you instead make mtd->writesize to be 64? This is much closer to the
> > "right thing to do" :-)
> 
> Yes. But I also must ensure that the buffer size configured in
> cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
> is not the case, it seems. If this is true, then I'll still run
> into the similar trouble even when using 64 for max_io_size in UBI.

Err, no, I think if the UBI/UBIFS min_io_size is greater than the real
write size, it should be fine for UBI/UBIFS. UBIFS should not get upset
if min_io_size is 64, but real write size is 8 or 16 or 32, or even 1
byte, I think.

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



From agust at denx.de  Thu Dec  2 09:18:37 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 2 Dec 2010 15:18:37 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291298276.2526.44.camel@localhost>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101202105729.04c25fc1@wker> <1291292325.2526.23.camel@localhost>
	<20101202142351.197abbde@wker> <1291296951.2526.34.camel@localhost>
	<20101202145027.266b30a6@wker> <1291298276.2526.44.camel@localhost>
Message-ID: <20101202151837.2d0c06c9@wker>

On Thu, 02 Dec 2010 15:57:56 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Thu, 2010-12-02 at 14:50 +0100, Anatolij Gustschin wrote:
> > > Can you instead make mtd->writesize to be 64? This is much closer to the
> > > "right thing to do" :-)
> > 
> > Yes. But I also must ensure that the buffer size configured in
> > cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
> > is not the case, it seems. If this is true, then I'll still run
> > into the similar trouble even when using 64 for max_io_size in UBI.
> 
> Err, no, I think if the UBI/UBIFS min_io_size is greater than the real
> write size, it should be fine for UBI/UBIFS. UBIFS should not get upset
> if min_io_size is 64, but real write size is 8 or 16 or 32, or even 1
> byte, I think.

Yes, this is my understanding, too. But I'll try to explain what I
meant in the previous email:
When I drop the 8 byte buffer hack in the CFI and set mtd->writesize
to 64, but the CFI driver is really using a multiple of the value
configured in cfi->cfiq->MaxBufWriteSize, then I'll run into the
similar trouble since the driver will probably use a n * 64 buffer,
where n > 1.

But I understand what you meant: I should just set mtd->writesize to
64 and continue to test with my hack for 8 Byte in the CFI driver.

Thanks,
Anatolij


From kmpark at infradead.org  Thu Dec  2 18:24:09 2010
From: kmpark at infradead.org (Kyungmin Park)
Date: Fri, 3 Dec 2010 08:24:09 +0900
Subject: [PATCH] mtd: onenand: bugfix for 2x mode bad block handling
In-Reply-To: <1291296518-31566-1-git-send-email-roman.tereshonkov@nokia.com>
References: <1291296518-31566-1-git-send-email-roman.tereshonkov@nokia.com>
Message-ID: <AANLkTinu52rJ_JMhibaxgtqOy=7cg2tVGGKVeZ7imGhO@mail.gmail.com>

Acked-by: Kyungmin Park <kyungmin.park at samsung.com>

On Thu, Dec 2, 2010 at 10:28 PM, Roman Tereshonkov
<roman.tereshonkov at nokia.com> wrote:
> This bug becomes visible in 2x mode when chip->writesize
> is different from mtd->writesize (= 2 * chip->writesize).
> At this case the bad block information is read from
> the first and the third physical pages instead of
> the first and the second as specification states.
>
> Signed-off-by: Roman Tereshonkov <roman.tereshonkov at nokia.com>
> ---
> ?drivers/mtd/onenand/onenand_bbt.c | ? ?6 ++++--
> ?1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
> index 01ab5b3..905209b 100644
> --- a/drivers/mtd/onenand/onenand_bbt.c
> +++ b/drivers/mtd/onenand/onenand_bbt.c
> @@ -91,13 +91,15 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
> ? ? ? ? ? ? ? ?for (j = 0; j < len; j++) {
> ? ? ? ? ? ? ? ? ? ? ? ?/* No need to read pages fully,
> ? ? ? ? ? ? ? ? ? ? ? ? * just read required OOB bytes */
> - ? ? ? ? ? ? ? ? ? ? ? ret = onenand_bbt_read_oob(mtd, from + j * mtd->writesize + bd->offs, &ops);
> + ? ? ? ? ? ? ? ? ? ? ? ret = onenand_bbt_read_oob(mtd,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? from + j * this->writesize + bd->offs, &ops);
>
> ? ? ? ? ? ? ? ? ? ? ? ?/* If it is a initial bad block, just ignore it */
> ? ? ? ? ? ? ? ? ? ? ? ?if (ret == ONENAND_BBT_READ_FATAL_ERROR)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return -EIO;
>
> - ? ? ? ? ? ? ? ? ? ? ? if (ret || check_short_pattern(&buf[j * scanlen], scanlen, mtd->writesize, bd)) {
> + ? ? ? ? ? ? ? ? ? ? ? if (ret || check_short_pattern(&buf[j * scanlen],
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?scanlen, this->writesize, bd)) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bbm->bbt[i >> 3] |= 0x03 << (i & 0x6);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?printk(KERN_WARNING "Bad eraseblock %d at 0x%08x\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?i >> 1, (unsigned int) from);
> --
> 1.7.0.4
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From agust at denx.de  Fri Dec  3 05:07:19 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Fri, 3 Dec 2010 11:07:19 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291264926.14534.32.camel@koala>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
Message-ID: <20101203110719.3a9d14f2@wker>

Hi Artem,

On Thu, 02 Dec 2010 06:42:06 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:
...
> Looking closer to my own code, I see that I treat PEB as
> "corrupted and should be preserved" if:
> 
> 1. EC header is OK.
> 2. VID header is corrupted.
> 3. data area is not "all 0xFFs".
> 
> And in 'nor_erase_prepare()' we first invalidate the VID header, and
> then invalidate the EC header. So there is a small window where you can
> end up with all 3 conditions to be true.
> 
> The solution is to first invalidate the EC header, and only then the VID
> header. Then in case of the race, we just lose the EC header, but VID
> header will be all-right, and UBI will handle this - it'll move the data
> from this PEB to another one, re-create EC header and use average EC
> count. But if you test this scenario, it will be great!!
> 
> This patch should help (compile-tested only).

This reset after clearing EC header and before clearing the VID
seems to be quite rare event. I tested with your patch and with
the mtd->writebuffer set to 64. Since no issues appeared while running
a nightly test (1662 test cycles succeeded), I interrupted the test
and simulated the reset in nor_erase_prepare() by adding a call of the
machine restart callback before clearing the VID header's magic:

nor_erase_prepare: ### RESET while clearing VID magic in peb # 149, off: 0xf6080000

After subsequent booting (reset simulation in nor_erase_prepare() has
been removed again) and mounting the partition I see following
message from wear_leveling_worker():

UBI: scrubbed PEB 149 (LEB 0:19), data moved to PEB 40

My question is: should this PEB really be preserved? I think, no.
It was prepared for erasure and would be entirely erased if no
interruption would occur.

Thanks,
Anatolij


From agust at denx.de  Fri Dec  3 05:23:07 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Fri, 3 Dec 2010 11:23:07 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101203110719.3a9d14f2@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101203110719.3a9d14f2@wker>
Message-ID: <20101203112307.131fa290@mw.dip.t-dialin.net>

On Fri, 3 Dec 2010 11:07:19 +0100
Anatolij Gustschin <agust at denx.de> wrote:
...
> This reset after clearing EC header and before clearing the VID
> seems to be quite rare event. I tested with your patch and with
> the mtd->writebuffer set to 64. Since no issues appeared while running

I meant "mtd->writesize" is set to 64, of course. Sorry.

Anatolij


From dedekind1 at gmail.com  Fri Dec  3 05:28:05 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 12:28:05 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101203110719.3a9d14f2@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101203110719.3a9d14f2@wker>
Message-ID: <1291372085.2365.49.camel@localhost>

On Fri, 2010-12-03 at 11:07 +0100, Anatolij Gustschin wrote:
> UBI: scrubbed PEB 149 (LEB 0:19), data moved to PEB 40
> 
> My question is: should this PEB really be preserved? I think, no.
> It was prepared for erasure and would be entirely erased if no
> interruption would occur.

Well, in general, my thinking is, if only the EC header is corrupted, we
do not know why - may be this was just because of some bit-flips or
radiation, and UBI better preserves it, just in case. I mean, there is a
risk to destroy useful data otherwise.

Then the upper layer SW like UBIFS should know what it was erasing, and
should re-issue the erasure. This is also a requirement made by the
"unstable bits" problem Matthiew found on NAND, and challenged me with.

To put is simple: I think it is saver for UBI to preserve it. Upper
layers will erase it again if it is not needed.

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



From agust at denx.de  Fri Dec  3 05:41:57 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Fri, 3 Dec 2010 11:41:57 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291372085.2365.49.camel@localhost>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101203110719.3a9d14f2@wker> <1291372085.2365.49.camel@localhost>
Message-ID: <20101203114157.5edaf24c@mw.dip.t-dialin.net>

On Fri, 03 Dec 2010 12:28:05 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Fri, 2010-12-03 at 11:07 +0100, Anatolij Gustschin wrote:
> > UBI: scrubbed PEB 149 (LEB 0:19), data moved to PEB 40
> > 
> > My question is: should this PEB really be preserved? I think, no.
> > It was prepared for erasure and would be entirely erased if no
> > interruption would occur.
> 
> Well, in general, my thinking is, if only the EC header is corrupted, we
> do not know why - may be this was just because of some bit-flips or
> radiation, and UBI better preserves it, just in case. I mean, there is a
> risk to destroy useful data otherwise.
> 
> Then the upper layer SW like UBIFS should know what it was erasing, and
> should re-issue the erasure. This is also a requirement made by the
> "unstable bits" problem Matthiew found on NAND, and challenged me with.
> 
> To put is simple: I think it is saver for UBI to preserve it. Upper
> layers will erase it again if it is not needed.

OK, thanks for the clarification!

Anatolij



From dedekind1 at gmail.com  Fri Dec  3 05:49:21 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 12:49:21 +0200
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <20101203110719.3a9d14f2@wker>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
	<20101203110719.3a9d14f2@wker>
Message-ID: <1291373361.2365.52.camel@localhost>

On Fri, 2010-12-03 at 11:07 +0100, Anatolij Gustschin wrote:
> This reset after clearing EC header and before clearing the VID
> seems to be quite rare event. I tested with your patch and with
> the mtd->writebuffer set to 64. Since no issues appeared while running
> a nightly test (1662 test cycles succeeded), I interrupted the test
> and simulated the reset in nor_erase_prepare() by adding a call of the
> machine restart callback before clearing the VID header's magic:

Let's merge it upstream as a bugfix then? Can I have your Tested-by:
Anatolij Gustschin <agust at denx.de> ? Or you want to do more testing for
it?

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



From agust at denx.de  Fri Dec  3 06:15:37 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Fri, 3 Dec 2010 12:15:37 +0100
Subject: UBIFS partition on NOR flash not mountable after power cut test
In-Reply-To: <1291264926.14534.32.camel@koala>
References: <20101129195014.19224240@wker> <20101201130534.5b95ce83@wker>
	<20101201164447.2215bc58@wker> <1291264926.14534.32.camel@koala>
Message-ID: <20101203121537.50b5ff63@mw.dip.t-dialin.net>

On Thu, 02 Dec 2010 06:42:06 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:
...
> From 7ddb9cb80ab54d118e2a055ce7a35649070578b1 Mon Sep 17 00:00:00 2001
> From: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> Date: Thu, 2 Dec 2010 06:34:01 +0200
> Subject: [PATCH] UBI: fix corrupted PEB detection for NOR flash
> 
> My new shiny code for corrupted PEB detection has NOR specific bug.
> We tread PEB as corrupted and preserve it, if
> 
> 1. EC header is OK.
> 2. VID header is corrupted.
> 3. data area is not "all 0xFFs"
> 
> In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
> the headers before erasing the PEB. And we invalidate first the VID
> header, and then the EC header. So if a power cut happens after we have
> invalidated the VID header, but before we have invalidated the EC
> header, we end up with a PEB which satisfies the above 3 conditions,
> and the scanning code will treat it as corrupted, and will print
> scary warnings, wrongly.
> 
> This patch fixes the issue by firt invalidating the EC header, then
> invalidating the VID header. In case of power cut inbetween, we still
> just lose the EC header, and UBI can deal with this situation gracefully.
> 
> This patch also adds one irrelevant comment about defining VID header
> buffer on stack.
> 
> Thanks to Anatolij Gustschin <agust at denx.de> for tracking this down.
> 
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> Reported-by: Anatolij Gustschin <agust at denx.de>

Tested-by: Anatolij Gustschin <agust at denx.de>

> ---
>  drivers/mtd/ubi/io.c   |   37 ++++++++++++++++++++++++++++---------
>  drivers/mtd/ubi/scan.c |    4 ++++
>  2 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index c2960ac..3839253 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -480,12 +480,26 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum)
>  	size_t written;
>  	loff_t addr;
>  	uint32_t data = 0;
> +	/*
> +	 * Note, we cannot generally define VID header buffers on stack,
> +	 * because of the way we deal with these buffers (see the heder
> +	 * comment). But we know this is NOR-specific piece of code, so we can
> +	 * do this. But yes, this is error-prone and we should (pre-)allocate
> +	 * VID header buffer instead.
> +	 */
>  	struct ubi_vid_hdr vid_hdr;
>  
> -	addr = (loff_t)pnum * ubi->peb_size + ubi->vid_hdr_aloffset;
> +	/*
> +	 * Note, it is important to first invalidate the EC header, and then
> +	 * VID header. Otherwise a power cut may result in valid EC header and
> +	 * invalid VID header, then UBI will treat this PEB as corrupted and
> +	 * will try to preserve it, print scary warnings. See scan.c header
> +	 * comment for more information.
> +	 */
> +	addr = (loff_t)pnum * ubi->peb_size;
>  	err = ubi->mtd->write(ubi->mtd, addr, 4, &written, (void *)&data);
>  	if (!err) {
> -		addr -= ubi->vid_hdr_aloffset;
> +		addr += ubi->vid_hdr_aloffset;
>  		err = ubi->mtd->write(ubi->mtd, addr, 4, &written,
>  				      (void *)&data);
>  		if (!err)
> @@ -499,13 +513,18 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum)
>  	 * In this case we probably anyway have garbage in this PEB.
>  	 */
>  	err1 = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0);
> -	if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR)
> -		/*
> -		 * The VID header is corrupted, so we can safely erase this
> -		 * PEB and not afraid that it will be treated as a valid PEB in
> -		 * case of an unclean reboot.
> -		 */
> -		return 0;
> +	if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR) {
> +		struct ubi_ec_hdr ec_hdr;
> +
> +		err1 = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0);
> +		if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR)
> +			/*
> +			 * The VID and EC headers are corrupted, so we can
> +			 * safely erase this PEB and not afraid that it will be
> +			 * treated as a valid PEB in case of an unclean reboot.
> +			 */
> +			return 0;
> +	}
>  
>  	/*
>  	 * The PEB contains a valid VID header, but we cannot invalidate it.
> diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c
> index 3c63186..d4b1115 100644
> --- a/drivers/mtd/ubi/scan.c
> +++ b/drivers/mtd/ubi/scan.c
> @@ -951,6 +951,10 @@ static int process_eb(struct ubi_device *ubi, struct ubi_scan_info *si,
>  			 * impossible to distinguish it from a PEB which just
>  			 * contains garbage because of a power cut during erase
>  			 * operation. So we just schedule this PEB for erasure.
> +			 *
> +			 * Besides, in case of NOR flash, we deliberatly
> +			 * corrupt both headers because NOR flash erasure is
> +			 * slow and can start from the end.
>  			 */
>  			err = 0;
>  		else



From dedekind1 at gmail.com  Fri Dec  3 11:07:57 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 18:07:57 +0200
Subject: bud_replay size question
In-Reply-To: <4CF691F0.9010607@grid-net.com>
References: <4CF691F0.9010607@grid-net.com>
Message-ID: <1291392477.2365.64.camel@localhost>

On Wed, 2010-12-01 at 10:20 -0800, Steve Iribarne wrote:
> What I'm trying to determine is how to figure out how big the replay_bud 
> LEB list can get based on my configuration.  Is there such a thing or am 
> I just dreaming?

Yeah, maximum amount of buds is max_bud_bytes / leb_size rounded up, I
thing. max_bud_bytes is stored in the superblock (see struct
ubifs_sb_node). The smaller it is, the smaller is the UBIFS journal.

You can control max_bud_bytes with the -j option of mkfs.ubifs. Try to
make it smaller.

Frankly, we (UBIFS authors) made this mechanism, but never really played
with journal size and always used the default one. Please, play with
this and report your findings - you can hit bugs if you start making it
too small or too large, but may be not. Dunno. But it has to make UBIFS
keep the journal smaller.

Alternatively, you can try to look at all UBIFS allocations. I will not
be surprized if it allocates some buffers which are not really neaded in
R/O mode, although we did do some work to allocate less resources when
we are in R/O mode. You can experiment in Linux, because it is easier,
and if you find unneeded buffers, fix this, and then port your changes
to u-boot.

HTH.

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



From dedekind1 at gmail.com  Fri Dec  3 11:14:34 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 18:14:34 +0200
Subject: bud_replay size question
In-Reply-To: <1291392477.2365.64.camel@localhost>
References: <4CF691F0.9010607@grid-net.com>
	<1291392477.2365.64.camel@localhost>
Message-ID: <1291392874.2365.67.camel@localhost>

On Fri, 2010-12-03 at 18:07 +0200, Artem Bityutskiy wrote:
> Alternatively, you can try to look at all UBIFS allocations. I will not
> be surprized if it allocates some buffers which are not really neaded in
> R/O mode, although we did do some work to allocate less resources when
> we are in R/O mode. You can experiment in Linux, because it is easier,
> and if you find unneeded buffers, fix this, and then port your changes
> to u-boot.

And you can try to look at UBI - in R/O mode we probably need less than
we allocate, but again dunno for sure, should be checke.

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



From dedekind1 at gmail.com  Fri Dec  3 11:14:36 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 18:14:36 +0200
Subject: [PATCH] mtd: onenand: bugfix for 2x mode bad block handling
In-Reply-To: <1291296518-31566-1-git-send-email-roman.tereshonkov@nokia.com>
References: <1291296518-31566-1-git-send-email-roman.tereshonkov@nokia.com>
Message-ID: <1291392876.2365.68.camel@localhost>

On Thu, 2010-12-02 at 15:28 +0200, Roman Tereshonkov wrote:
> This bug becomes visible in 2x mode when chip->writesize
> is different from mtd->writesize (= 2 * chip->writesize).
> At this case the bad block information is read from
> the first and the third physical pages instead of
> the first and the second as specification states.
> 
> Signed-off-by: Roman Tereshonkov <roman.tereshonkov at nokia.com>

Pushed to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Fri Dec  3 11:14:39 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 18:14:39 +0200
Subject: [PATCH] mtd: OneNAND: Fix 4KiB pagesize OOB handling
In-Reply-To: <20101202002416.GA807@july>
References: <20101202002416.GA807@july>
Message-ID: <1291392879.2365.69.camel@localhost>

On Thu, 2010-12-02 at 09:24 +0900, Kyungmin Park wrote:
> From: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Original 4KiB pagesize chip (SLC) doesn't support OOB operations at Spec.
> And it's also same at Flex-OneNAND.
> 
> Remove the MLC macro if possible and use 4KiB pagesize macro since MLC has 4KiB pagesize.
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Pushed to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Fri Dec  3 11:22:05 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 03 Dec 2010 18:22:05 +0200
Subject: [PATCH V2] omap: nand: remove hardware ECC as default
In-Reply-To: <20101130180542.GP17222@atomide.com>
References: <1290177926-3526-1-git-send-email-s-ghorai@ti.com>
	<20101130180542.GP17222@atomide.com>
Message-ID: <1291393325.2365.72.camel@localhost>

On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> * Sukumar Ghorai <s-ghorai at ti.com> [101119 06:36]:
> > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
> > This flag enables hw ecc by default. Boards like beagle and pandora uses
> > sw ecc for write (e.g. binary flushed from u-boot) and read from kernel.
> > https://patchwork.kernel.org/patch/111036/
> > 
> > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> 
> This should go in as a fix for the -rc via MTD list if possible.
> 
> Acked-by: Tony Lindgren <tony at atomide.com>

Tony, I think this is quite simple patch, and you can merge it yourself,
MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he
quickly jumps in and confirms he takes care of this patch, just go ahead
an merge it. I've put dwmw2 to "To:", just in case.

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



From dwmw2 at infradead.org  Fri Dec  3 11:38:50 2010
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Dec 2010 16:38:50 +0000
Subject: [PATCH V2] omap: nand: remove hardware ECC as default
In-Reply-To: <1291393325.2365.72.camel@localhost>
References: <1290177926-3526-1-git-send-email-s-ghorai@ti.com>
	<20101130180542.GP17222@atomide.com>
	<1291393325.2365.72.camel@localhost>
Message-ID: <1291394352.5992.4.camel@i7.infradead.org>

On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote:
> On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> > * Sukumar Ghorai <s-ghorai at ti.com> [101119 06:36]:
> > > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
> > > This flag enables hw ecc by default. Boards like beagle and pandora uses
> > > sw ecc for write (e.g. binary flushed from u-boot) and read from kernel.
> > > https://patchwork.kernel.org/patch/111036/
> > > 
> > > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> > 
> > This should go in as a fix for the -rc via MTD list if possible.
> > 
> > Acked-by: Tony Lindgren <tony at atomide.com>
> 
> Tony, I think this is quite simple patch, and you can merge it yourself,
> MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he
> quickly jumps in and confirms he takes care of this patch, just go ahead
> an merge it. I've put dwmw2 to "To:", just in case.

Acked-by: David Woodhouse <David.Woodhouse at intel.com>

Unless you'd prefer me to send it on myself, please feel free to submit
it to Linus directly.

-- 
dwmw2



From tony at atomide.com  Fri Dec  3 11:44:31 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 3 Dec 2010 08:44:31 -0800
Subject: [PATCH V2] omap: nand: remove hardware ECC as default
In-Reply-To: <1291394352.5992.4.camel@i7.infradead.org>
References: <1290177926-3526-1-git-send-email-s-ghorai@ti.com>
	<20101130180542.GP17222@atomide.com>
	<1291393325.2365.72.camel@localhost>
	<1291394352.5992.4.camel@i7.infradead.org>
Message-ID: <20101203164430.GE17222@atomide.com>

* David Woodhouse <dwmw2 at infradead.org> [101203 08:29]:
> On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote:
> > On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> > > * Sukumar Ghorai <s-ghorai at ti.com> [101119 06:36]:
> > > > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
> > > > This flag enables hw ecc by default. Boards like beagle and pandora uses
> > > > sw ecc for write (e.g. binary flushed from u-boot) and read from kernel.
> > > > https://patchwork.kernel.org/patch/111036/
> > > > 
> > > > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> > > 
> > > This should go in as a fix for the -rc via MTD list if possible.
> > > 
> > > Acked-by: Tony Lindgren <tony at atomide.com>
> > 
> > Tony, I think this is quite simple patch, and you can merge it yourself,
> > MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he
> > quickly jumps in and confirms he takes care of this patch, just go ahead
> > an merge it. I've put dwmw2 to "To:", just in case.
> 
> Acked-by: David Woodhouse <David.Woodhouse at intel.com>
> 
> Unless you'd prefer me to send it on myself, please feel free to submit
> it to Linus directly.

Thanks, I'll queue it.

Regards,

Tony


From siribarne at grid-net.com  Fri Dec  3 13:20:48 2010
From: siribarne at grid-net.com (Steve Iribarne)
Date: Fri, 03 Dec 2010 10:20:48 -0800
Subject: bud_replay size question
In-Reply-To: <1291392874.2365.67.camel@localhost>
References: <4CF691F0.9010607@grid-net.com>	
	<1291392477.2365.64.camel@localhost>
	<1291392874.2365.67.camel@localhost>
Message-ID: <4CF93500.8050108@grid-net.com>

Artem Bityutskiy wrote:
> On Fri, 2010-12-03 at 18:07 +0200, Artem Bityutskiy wrote:
>> Alternatively, you can try to look at all UBIFS allocations. I will not
>> be surprized if it allocates some buffers which are not really neaded in
>> R/O mode, although we did do some work to allocate less resources when
>> we are in R/O mode. You can experiment in Linux, because it is easier,
>> and if you find unneeded buffers, fix this, and then port your changes
>> to u-boot.
> 
> And you can try to look at UBI - in R/O mode we probably need less than
> we allocate, but again dunno for sure, should be checke.
> 
Once I get this release out the door I will play around with this and 
report back.

-stv

-- 
Steve Iribarne
Sr. Software Engineer
Embedded Devices


From kmpark at infradead.org  Sun Dec  5 19:05:18 2010
From: kmpark at infradead.org (Kyungmin Park)
Date: Mon, 06 Dec 2010 09:05:18 +0900
Subject: [PATCH] mtd: OneNAND: Fix multi block erase support at 4KiB	pagesize
Message-ID: <20101206000518.GA18352@july>

From: Kyungmin Park <kyungmin.park at samsung.com>

Original 4KiB pagesize chip (SLC) doesn't support Multi block erase at Spec.

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 c38bf9c..88f23e3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -2492,7 +2492,8 @@ static int onenand_erase(struct mtd_info *mtd, struct erase_info *instr)
 	/* Grab the lock and see if the device is available */
 	onenand_get_device(mtd, FL_ERASING);
 
-	if (region || instr->len < MB_ERASE_MIN_BLK_COUNT * block_size) {
+	if (ONENAND_IS_4KB_PAGE(this) || region ||
+	    instr->len < MB_ERASE_MIN_BLK_COUNT * block_size) {
 		/* region is set for Flex-OneNAND (no mb erase) */
 		ret = onenand_block_by_block_erase(mtd, instr,
 						   region, block_size);


From agust at denx.de  Mon Dec  6 15:26:57 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Mon,  6 Dec 2010 21:26:57 +0100
Subject: [PATCH] mtd: add NOR flash write buffer size reporting for UBI/UBIFS
Message-ID: <1291667217-13097-1-git-send-email-agust@denx.de>

Add "write_buffer_size" field to struct mtd_info. This field
will be used to set minimal I/O unit size (min_io_size) for UBI
on NOR flash. In case of NOR flash minimal I/O size must be equal
to the maximal size of the write buffer used by embedded flash
programming algorithm.

Flash programming from prepared write buffer performed in one
programming operation could be interrupted by a power cut or
a system reset causing corrupted (partially written) areas in
a flash sector. Knowing the size of potentially corrupted areas
UBIFS scanning and recovery algorithms are able to perform
successful recovery.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/chips/cfi_cmdset_0001.c |    1 +
 drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++++
 drivers/mtd/chips/cfi_cmdset_0020.c |    1 +
 drivers/mtd/mtdconcat.c             |    1 +
 drivers/mtd/mtdpart.c               |    1 +
 drivers/mtd/ubi/build.c             |    5 ++++-
 include/linux/mtd/mtd.h             |   12 ++++++++++++
 7 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 44cbfc0..3705da5 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -455,6 +455,7 @@ struct mtd_info *cfi_cmdset_0001(struct map_info *map, int primary)
 	mtd->flags   = MTD_CAP_NORFLASH;
 	mtd->name    = map->name;
 	mtd->writesize = 1;
+	mtd->write_buffer_size = 1 << cfi->cfiq->MaxBufWriteSize;
 
 	mtd->reboot_notifier.notifier_call = cfi_intelext_reboot;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..33989ce 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -428,6 +428,10 @@ struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
 	mtd->flags   = MTD_CAP_NORFLASH;
 	mtd->name    = map->name;
 	mtd->writesize = 1;
+	mtd->write_buffer_size = 1 << cfi->cfiq->MaxBufWriteSize;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): write buffer size %d\n",
+		__func__, mtd->write_buffer_size);
 
 	mtd->reboot_notifier.notifier_call = cfi_amdstd_reboot;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c b/drivers/mtd/chips/cfi_cmdset_0020.c
index 314af1f..54ad184 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -238,6 +238,7 @@ static struct mtd_info *cfi_staa_setup(struct map_info *map)
 	mtd->resume = cfi_staa_resume;
 	mtd->flags = MTD_CAP_NORFLASH & ~MTD_BIT_WRITEABLE;
 	mtd->writesize = 8; /* FIXME: Should be 0 for STMicro flashes w/out ECC */
+	mtd->write_buffer_size = 1 << cfi->cfiq->MaxBufWriteSize;
 	map->fldrv = &cfi_staa_chipdrv;
 	__module_get(THIS_MODULE);
 	mtd->name = map->name;
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index bf8de09..53a5e94 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -776,6 +776,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 	concat->mtd.size = subdev[0]->size;
 	concat->mtd.erasesize = subdev[0]->erasesize;
 	concat->mtd.writesize = subdev[0]->writesize;
+	concat->mtd.write_buffer_size = subdev[0]->write_buffer_size;
 	concat->mtd.subpage_sft = subdev[0]->subpage_sft;
 	concat->mtd.oobsize = subdev[0]->oobsize;
 	concat->mtd.oobavail = subdev[0]->oobavail;
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 1047ff0..ef37476 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -384,6 +384,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 	slave->mtd.flags = master->flags & ~part->mask_flags;
 	slave->mtd.size = part->size;
 	slave->mtd.writesize = master->writesize;
+	slave->mtd.write_buffer_size = master->write_buffer_size;
 	slave->mtd.oobsize = master->oobsize;
 	slave->mtd.oobavail = master->oobavail;
 	slave->mtd.subpage_sft = master->subpage_sft;
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 5ebe280..9db6fff 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -670,9 +670,12 @@ static int io_init(struct ubi_device *ubi)
 	if (ubi->mtd->type == MTD_NORFLASH) {
 		ubi_assert(ubi->mtd->writesize == 1);
 		ubi->nor_flash = 1;
+		ubi_assert(ubi->mtd->write_buffer_size > 0);
+		ubi->min_io_size = ubi->mtd->write_buffer_size;
+	} else {
+		ubi->min_io_size = ubi->mtd->writesize;
 	}
 
-	ubi->min_io_size = ubi->mtd->writesize;
 	ubi->hdrs_min_io_size = ubi->mtd->writesize >> ubi->mtd->subpage_sft;
 
 	/*
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index fe8d77e..cb902d1 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -144,6 +144,18 @@ struct mtd_info {
 	 */
 	uint32_t writesize;
 
+	/*
+	 * Sets minimal I/O unit size (min_io_size) for UBI on NOR flash.
+	 * In case of NOR flash minimal I/O size must be equal to the size
+	 * of the write buffer used by internal flash programming algorithm.
+	 * This requirement results from the fact that the flash programming
+	 * operation could be interrupted by a power cut or a system reset
+	 * causing corrupted (partially written) areas in a flash sector.
+	 * Knowing the size of potentially corrupted areas UBIFS scanning
+	 * and recovery algorithms are able to perform successful recovery.
+	 */
+	uint32_t write_buffer_size;
+
 	uint32_t oobsize;   // Amount of OOB data per block (e.g. 16)
 	uint32_t oobavail;  // Available OOB bytes per block
 
-- 
1.7.1



From pan at ccpu.com  Mon Dec  6 22:36:58 2010
From: pan at ccpu.com (Deng Pan)
Date: Tue, 7 Dec 2010 11:36:58 +0800
Subject: How to Use the FTL and HAL Sotfware Modules
Message-ID: <67A53E306C9D514FA5CC81FCFF72380114E490FF@szexchange.ccpu.com>

Hi:

Just an old topic about NAND bad block management.

I read from the application notes (http://awww.eetindia.co.in/ARTICLES/2004NOV/A/2004NOV29_MEM_AN07.PDF?SOURCES=DOWNLOAD) that we should use FTL and HAL software module to management the NAND flash bad blocks.

How about the status in linux-mtd? Has it been implemented? If not, is it in the todo list?

Regards

Pan Deng





From pan at ccpu.com  Tue Dec  7 01:01:43 2010
From: pan at ccpu.com (Deng Pan)
Date: Tue, 7 Dec 2010 14:01:43 +0800
Subject: How to Use the FTL and HAL Sotfware Modules
In-Reply-To: <67A53E306C9D514FA5CC81FCFF72380114E490FF@szexchange.ccpu.com>
References: <67A53E306C9D514FA5CC81FCFF72380114E490FF@szexchange.ccpu.com>
Message-ID: <67A53E306C9D514FA5CC81FCFF72380114E49121@szexchange.ccpu.com>

More information about this:

Bad Block Management in NAND Flash Memories
http://www.eetindia.co.in/ARTICLES/2004NOV/A/2004NOV29_MEM_AN06.PDF

How to Use the FTL and HAL Sotfware Modules to Manage Data in Single Level Cell NAND Flash Memories
http://www.eetindia.co.in/ARTICLES/2004NOV/A/2004NOV29_MEM_AN07.PDF


-----Original Message-----
From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Deng Pan
Sent: Tuesday, December 07, 2010 11:37 AM
To: linux-mtd at lists.infradead.org
Subject: How to Use the FTL and HAL Sotfware Modules

Hi:

Just an old topic about NAND bad block management.

I read from the application notes (http://awww.eetindia.co.in/ARTICLES/2004NOV/A/2004NOV29_MEM_AN07.PDF?SOURCES=DOWNLOAD) that we should use FTL and HAL software module to management the NAND flash bad blocks.

How about the status in linux-mtd? Has it been implemented? If not, is it in the todo list?

Regards

Pan Deng




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


From lunz at acm.org  Tue Dec  7 02:29:19 2010
From: lunz at acm.org (Jason Lunz)
Date: Mon, 6 Dec 2010 23:29:19 -0800
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20071228174853.GA4252@uranus.ravnborg.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
Message-ID: <20101207072919.GA8511@falooley.org>


Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
dependencies down closer to the parts of mtd that actually need it.
This allows enough of mtd to build to let jffs2 be used on uml.

Signed-off-by: Jason Lunz <lunz at acm.org>
---
 arch/um/Kconfig.rest        |    4 +---
 drivers/mtd/Kconfig         |    1 -
 drivers/mtd/Makefile        |    3 ++-
 drivers/mtd/chips/Kconfig   |    4 ++++
 drivers/mtd/devices/Kconfig |    8 ++++++++
 drivers/mtd/maps/Kconfig    |    4 ++++
 drivers/mtd/mtdchar.c       |    4 ++++
 drivers/mtd/nand/Kconfig    |    3 +++
 drivers/mtd/onenand/Kconfig |    3 +++
 include/linux/mtd/map.h     |    2 ++
 10 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
index 0ccad0f..e34f399 100644
--- a/arch/um/Kconfig.rest
+++ b/arch/um/Kconfig.rest
@@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
 
 source "drivers/md/Kconfig"
 
-if BROKEN
-	source "drivers/mtd/Kconfig"
-endif
+source "drivers/mtd/Kconfig"
 
 source "drivers/leds/Kconfig"
 
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 1e2cbf5..a0e2a28 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,6 +1,5 @@
 menuconfig MTD
 	tristate "Memory Technology Device (MTD) support"
-	depends on HAS_IOMEM
 	help
 	  Memory Technology Devices are flash, RAM and similar chips, often
 	  used for solid state file systems on embedded devices. This option
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 760abc5..ffa2e15 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS)		+= mtdoops.o
 nftl-objs		:= nftlcore.o nftlmount.o
 inftl-objs		:= inftlcore.o inftlmount.o
 
-obj-y		+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
+obj-y			+= maps/ devices/ nand/ onenand/ tests/
+obj-$(CONFIG_HAS_IOMEM)	+= chips/ lpddr/
 
 obj-$(CONFIG_MTD_UBI)		+= ubi/
diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
index 35c6a23..27382c9 100644
--- a/drivers/mtd/chips/Kconfig
+++ b/drivers/mtd/chips/Kconfig
@@ -1,3 +1,5 @@
+if HAS_IOMEM
+
 menu "RAM/ROM/Flash chip drivers"
 	depends on MTD!=n
 
@@ -240,3 +242,5 @@ config MTD_XIP
 	  then say N.
 
 endmenu
+
+endif # HAS_IOMEM
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 35081ce..8f6d85d 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -112,6 +112,8 @@ config MTD_SST25L
 	  Set up your spi devices with the right board-specific platform data,
 	  if you want to specify device partitioning.
 
+if HAS_IOMEM
+
 config MTD_SLRAM
 	tristate "Uncached system RAM"
 	help
@@ -128,6 +130,8 @@ config MTD_PHRAM
 	  doesn't have access to, memory beyond the mem=xxx limit, nvram,
 	  memory on the video card, etc...
 
+endif # HAS_IOMEM
+
 config MTD_LART
 	tristate "28F160xx flash driver for LART"
 	depends on SA1100_LART
@@ -187,6 +191,8 @@ config MTD_BLOCK2MTD
 	  Testing MTD users (eg JFFS2) on large media and media that might
 	  be removed during a write (using the floppy drive).
 
+if HAS_IOMEM
+
 comment "Disk-On-Chip Device Drivers"
 
 config MTD_DOC2000
@@ -249,6 +255,8 @@ config MTD_DOC2001PLUS
 	  under "NAND Flash Device Drivers" (currently that driver does not
 	  support all Millennium Plus devices).
 
+endif # HAS_IOMEM
+
 config MTD_DOCPROBE
 	tristate
 	select MTD_DOCECC
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index a0dd7bb..e793b29 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -1,3 +1,5 @@
+if HAS_IOMEM
+
 menu "Mapping drivers for chip access"
 	depends on MTD!=n
 
@@ -553,3 +555,5 @@ config MTD_PISMO
 	  When built as a module, it will be called pismo.ko
 
 endmenu
+
+endif # HAS_IOMEM
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 4759d82..a434354 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file,
 /*
  * set up a mapping for shared memory segments
  */
+#ifdef CONFIG_HAS_IOMEM
 static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
 {
 #ifdef CONFIG_MMU
@@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
 	return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS;
 #endif
 }
+#endif
 
 static const struct file_operations mtd_fops = {
 	.owner		= THIS_MODULE,
@@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = {
 #endif
 	.open		= mtd_open,
 	.release	= mtd_close,
+#ifdef CONFIG_HAS_IOMEM
 	.mmap		= mtd_mmap,
+#endif
 #ifndef CONFIG_MMU
 	.get_unmapped_area = mtd_get_unmapped_area,
 #endif
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8229802..8bdd465 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC
 	  The original Linux implementation had byte 0 and 1 swapped.
 
 
+if HAS_IOMEM
+
 menuconfig MTD_NAND
 	tristate "NAND Device Support"
 	depends on MTD
@@ -533,3 +535,4 @@ config MTD_NAND_FSMC
 	  Flexible Static Memory Controller (FSMC)
 
 endif # MTD_NAND
+endif # HAS_IOMEM
diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig
index 4dbd0f5..166aa18 100644
--- a/drivers/mtd/onenand/Kconfig
+++ b/drivers/mtd/onenand/Kconfig
@@ -1,3 +1,5 @@
+if HAS_IOMEM
+
 menuconfig MTD_ONENAND
 	tristate "OneNAND Device Support"
 	depends on MTD
@@ -75,3 +77,4 @@ config MTD_ONENAND_SIM
 	  OneNAND MTD layer.
 
 endif # MTD_ONENAND
+endif # HAS_IOMEM
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index a9e6ba4..c7233ba 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map)
 	return r;
 }
 
+#ifdef CONFIG_HAS_IOMEM
 static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
 {
 	map_word r;
@@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
 {
 	memcpy_toio(map->virt + to, from, len);
 }
+#endif /* CONFIG_HAS_IOMEM */
 
 #ifdef CONFIG_MTD_COMPLEX_MAPPINGS
 #define map_read(map, ofs) (map)->read(map, ofs)
-- 
1.7.2.3



From richard.weinberger at gmail.com  Tue Dec  7 04:39:41 2010
From: richard.weinberger at gmail.com (richard -rw- weinberger)
Date: Tue, 7 Dec 2010 10:39:41 +0100
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101207072919.GA8511@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
Message-ID: <AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>

On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz at acm.org> wrote:
>
> Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
> dependencies down closer to the parts of mtd that actually need it.
> This allows enough of mtd to build to let jffs2 be used on uml.
>
> Signed-off-by: Jason Lunz <lunz at acm.org>
> ---
> ?arch/um/Kconfig.rest ? ? ? ?| ? ?4 +---
> ?drivers/mtd/Kconfig ? ? ? ? | ? ?1 -
> ?drivers/mtd/Makefile ? ? ? ?| ? ?3 ++-
> ?drivers/mtd/chips/Kconfig ? | ? ?4 ++++
> ?drivers/mtd/devices/Kconfig | ? ?8 ++++++++
> ?drivers/mtd/maps/Kconfig ? ?| ? ?4 ++++
> ?drivers/mtd/mtdchar.c ? ? ? | ? ?4 ++++
> ?drivers/mtd/nand/Kconfig ? ?| ? ?3 +++
> ?drivers/mtd/onenand/Kconfig | ? ?3 +++
> ?include/linux/mtd/map.h ? ? | ? ?2 ++
> ?10 files changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
> index 0ccad0f..e34f399 100644
> --- a/arch/um/Kconfig.rest
> +++ b/arch/um/Kconfig.rest
> @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
>
> ?source "drivers/md/Kconfig"
>
> -if BROKEN
> - ? ? ? source "drivers/mtd/Kconfig"
> -endif
> +source "drivers/mtd/Kconfig"

drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2).

Do you exactly know why it was marked and fixes this patch all issues?

> ?source "drivers/leds/Kconfig"
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 1e2cbf5..a0e2a28 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -1,6 +1,5 @@
> ?menuconfig MTD
> ? ? ? ?tristate "Memory Technology Device (MTD) support"
> - ? ? ? depends on HAS_IOMEM
> ? ? ? ?help
> ? ? ? ? ?Memory Technology Devices are flash, RAM and similar chips, often
> ? ? ? ? ?used for solid state file systems on embedded devices. This option
> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
> index 760abc5..ffa2e15 100644
> --- a/drivers/mtd/Makefile
> +++ b/drivers/mtd/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) ? ? ? ? ? ? ? ?+= mtdoops.o
> ?nftl-objs ? ? ? ? ? ? ?:= nftlcore.o nftlmount.o
> ?inftl-objs ? ? ? ? ? ? := inftlcore.o inftlmount.o
>
> -obj-y ? ? ? ? ?+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
> +obj-y ? ? ? ? ? ? ? ? ?+= maps/ devices/ nand/ onenand/ tests/
> +obj-$(CONFIG_HAS_IOMEM) ? ? ? ?+= chips/ lpddr/
>
> ?obj-$(CONFIG_MTD_UBI) ? ? ? ? ?+= ubi/
> diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
> index 35c6a23..27382c9 100644
> --- a/drivers/mtd/chips/Kconfig
> +++ b/drivers/mtd/chips/Kconfig
> @@ -1,3 +1,5 @@
> +if HAS_IOMEM
> +
> ?menu "RAM/ROM/Flash chip drivers"
> ? ? ? ?depends on MTD!=n
>
> @@ -240,3 +242,5 @@ config MTD_XIP
> ? ? ? ? ?then say N.
>
> ?endmenu
> +
> +endif # HAS_IOMEM
> diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
> index 35081ce..8f6d85d 100644
> --- a/drivers/mtd/devices/Kconfig
> +++ b/drivers/mtd/devices/Kconfig
> @@ -112,6 +112,8 @@ config MTD_SST25L
> ? ? ? ? ?Set up your spi devices with the right board-specific platform data,
> ? ? ? ? ?if you want to specify device partitioning.
>
> +if HAS_IOMEM
> +
> ?config MTD_SLRAM
> ? ? ? ?tristate "Uncached system RAM"
> ? ? ? ?help
> @@ -128,6 +130,8 @@ config MTD_PHRAM
> ? ? ? ? ?doesn't have access to, memory beyond the mem=xxx limit, nvram,
> ? ? ? ? ?memory on the video card, etc...
>
> +endif # HAS_IOMEM
> +
> ?config MTD_LART
> ? ? ? ?tristate "28F160xx flash driver for LART"
> ? ? ? ?depends on SA1100_LART
> @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD
> ? ? ? ? ?Testing MTD users (eg JFFS2) on large media and media that might
> ? ? ? ? ?be removed during a write (using the floppy drive).
>
> +if HAS_IOMEM
> +
> ?comment "Disk-On-Chip Device Drivers"
>
> ?config MTD_DOC2000
> @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS
> ? ? ? ? ?under "NAND Flash Device Drivers" (currently that driver does not
> ? ? ? ? ?support all Millennium Plus devices).
>
> +endif # HAS_IOMEM
> +
> ?config MTD_DOCPROBE
> ? ? ? ?tristate
> ? ? ? ?select MTD_DOCECC
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> index a0dd7bb..e793b29 100644
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -1,3 +1,5 @@
> +if HAS_IOMEM
> +
> ?menu "Mapping drivers for chip access"
> ? ? ? ?depends on MTD!=n
>
> @@ -553,3 +555,5 @@ config MTD_PISMO
> ? ? ? ? ?When built as a module, it will be called pismo.ko
>
> ?endmenu
> +
> +endif # HAS_IOMEM
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 4759d82..a434354 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file,
> ?/*
> ?* set up a mapping for shared memory segments
> ?*/
> +#ifdef CONFIG_HAS_IOMEM
> ?static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
> ?{
> ?#ifdef CONFIG_MMU
> @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
> ? ? ? ?return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS;
> ?#endif
> ?}
> +#endif
>
> ?static const struct file_operations mtd_fops = {
> ? ? ? ?.owner ? ? ? ? ?= THIS_MODULE,
> @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = {
> ?#endif
> ? ? ? ?.open ? ? ? ? ? = mtd_open,
> ? ? ? ?.release ? ? ? ?= mtd_close,
> +#ifdef CONFIG_HAS_IOMEM
> ? ? ? ?.mmap ? ? ? ? ? = mtd_mmap,
> +#endif
> ?#ifndef CONFIG_MMU
> ? ? ? ?.get_unmapped_area = mtd_get_unmapped_area,
> ?#endif
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 8229802..8bdd465 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC
> ? ? ? ? ?The original Linux implementation had byte 0 and 1 swapped.
>
>
> +if HAS_IOMEM
> +
> ?menuconfig MTD_NAND
> ? ? ? ?tristate "NAND Device Support"
> ? ? ? ?depends on MTD
> @@ -533,3 +535,4 @@ config MTD_NAND_FSMC
> ? ? ? ? ?Flexible Static Memory Controller (FSMC)
>
> ?endif # MTD_NAND
> +endif # HAS_IOMEM
> diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig
> index 4dbd0f5..166aa18 100644
> --- a/drivers/mtd/onenand/Kconfig
> +++ b/drivers/mtd/onenand/Kconfig
> @@ -1,3 +1,5 @@
> +if HAS_IOMEM
> +
> ?menuconfig MTD_ONENAND
> ? ? ? ?tristate "OneNAND Device Support"
> ? ? ? ?depends on MTD
> @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM
> ? ? ? ? ?OneNAND MTD layer.
>
> ?endif # MTD_ONENAND
> +endif # HAS_IOMEM
> diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
> index a9e6ba4..c7233ba 100644
> --- a/include/linux/mtd/map.h
> +++ b/include/linux/mtd/map.h
> @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map)
> ? ? ? ?return r;
> ?}
>
> +#ifdef CONFIG_HAS_IOMEM
> ?static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
> ?{
> ? ? ? ?map_word r;
> @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
> ?{
> ? ? ? ?memcpy_toio(map->virt + to, from, len);
> ?}
> +#endif /* CONFIG_HAS_IOMEM */
>
> ?#ifdef CONFIG_MTD_COMPLEX_MAPPINGS
> ?#define map_read(map, ofs) (map)->read(map, ofs)
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>



-- 
Thanks,
//richard


From lunz at acm.org  Tue Dec  7 13:20:12 2010
From: lunz at acm.org (Jason Lunz)
Date: Tue, 7 Dec 2010 10:20:12 -0800
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
Message-ID: <20101207182012.GA10546@falooley.org>

On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote:
> On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz at acm.org> wrote:
> >
> > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
> > dependencies down closer to the parts of mtd that actually need it.
> > This allows enough of mtd to build to let jffs2 be used on uml.
> >
> > Signed-off-by: Jason Lunz <lunz at acm.org>
> > ---
> > ?arch/um/Kconfig.rest ? ? ? ?| ? ?4 +---
> > ?drivers/mtd/Kconfig ? ? ? ? | ? ?1 -
> > ?drivers/mtd/Makefile ? ? ? ?| ? ?3 ++-
> > ?drivers/mtd/chips/Kconfig ? | ? ?4 ++++
> > ?drivers/mtd/devices/Kconfig | ? ?8 ++++++++
> > ?drivers/mtd/maps/Kconfig ? ?| ? ?4 ++++
> > ?drivers/mtd/mtdchar.c ? ? ? | ? ?4 ++++
> > ?drivers/mtd/nand/Kconfig ? ?| ? ?3 +++
> > ?drivers/mtd/onenand/Kconfig | ? ?3 +++
> > ?include/linux/mtd/map.h ? ? | ? ?2 ++
> > ?10 files changed, 31 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
> > index 0ccad0f..e34f399 100644
> > --- a/arch/um/Kconfig.rest
> > +++ b/arch/um/Kconfig.rest
> > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
> >
> > ?source "drivers/md/Kconfig"
> >
> > -if BROKEN
> > - ? ? ? source "drivers/mtd/Kconfig"
> > -endif
> > +source "drivers/mtd/Kconfig"
> 
> drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2).
> 
> Do you exactly know why it was marked and fixes this patch all issues?

I don't know exactly why it was originally marked BROKEN. I imagine it
was because most of the low-level mtd drivers need readb/writeb and
friends, which don't exist on uml. But now that mtd has virtual ram- and
blockdev-backed drivers, that's no longer sufficient reason to omit the
whole subsystem.

I can't claim that this fixes all possible issues of course, but I've
privately been using this patch to run block2mtd under uml for years. My
original motivation was to allow the use of jffs2 in a uml-based test
environment and for that it's worked very well.

Jason


From Ritajean.Reed at uphs.upenn.edu  Tue Dec  7 21:53:04 2010
From: Ritajean.Reed at uphs.upenn.edu (Reed, Ritajean)
Date: Tue, 7 Dec 2010 21:53:04 -0500
Subject: Contact me on chris-rodehaver406 @hotmail.com
Message-ID: <8F7E819DAB630B42876CB27A0EF223503DB63C@uphsmbx2.UPHS.PENNHEALTH.PRV>




Hello,
I am Chris Rodehaver, an American diplomat Special Representative and head of the UN mission working under the United nations. I am presently at Bishop International Airport with your consignments trunk boxes which had been cleared from Customs. You are hereby advice to re-confirm your address and telephone number for delivery of your consignments funds and for further details do contact me on my private email ( chris-rodehaver406 at hotmail.com ) and can be reach at (517) 610-7900.

Best Regards,
Chris Rodehaver.
chris-rodehaver406 at hotmail.com
Sent via BlackBerry from T-Mobile


The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.


From glecerf at gmail.com  Wed Dec  8 10:07:15 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 16:07:15 +0100
Subject: [PATCH 2/2] mtd: cfi_cmdset_0002: add support for Samsung K8D3x16UxC
	NOR chips
In-Reply-To: <20101208150710.19706.92098.stgit@dev.siriade.com>
References: <20101208150710.19706.92098.stgit@dev.siriade.com>
Message-ID: <20101208150715.19706.65528.stgit@dev.siriade.com>

These chips report CFI v3.3 [1], so patch them on the fly to the more
correct v1.3.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
[2] https://dev.openwrt.org/ticket/866

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 28e05ad..bf015e7 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -395,7 +395,7 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 	if (cfi->mfr == CFI_MFR_SAMSUNG) {
 		if (extp->MajorVersion == '0') {
 			/*
-			 * Samsung K8P2815UQB and K8D6x16UxM report major=0 / minor=0
+			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
 			 */
 			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.0",
 			       extp->MajorVersion, extp->MinorVersion);
@@ -403,6 +403,19 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 			extp->MajorVersion = '1';
 			extp->MinorVersion = '0';
 		}
+		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
+			/*
+			 * Samsung K8D3x16UxC chips report major=3 / minor=3
+			 */
+			printk(KERN_NOTICE "  Newer Samsung flash detected, "
+			                   "should be compatibile with Amd/Fujitsu.\n");
+
+			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.3",
+			       extp->MajorVersion, extp->MinorVersion);
+
+			extp->MajorVersion = '1'; // set to 1.3
+			extp->MinorVersion = '3';
+		}
 	}
 
 	/*



From glecerf at gmail.com  Wed Dec  8 10:07:10 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 16:07:10 +0100
Subject: [PATCH 1/2] mtd: cfi_cmdset_0002: add support for Samsung K8D6x16UxM
	NOR chips
Message-ID: <20101208150710.19706.92098.stgit@dev.siriade.com>

These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
to patch all Samsung chips with Major == 0 to 1.0.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
[2] https://dev.openwrt.org/ticket/7348

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..28e05ad 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
 static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
-	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
-	    extp->MajorVersion == '0')
-		extp->MajorVersion = '1';
+	if (cfi->mfr == CFI_MFR_SAMSUNG) {
+		if (extp->MajorVersion == '0') {
+			/*
+			 * Samsung K8P2815UQB and K8D6x16UxM report major=0 / minor=0
+			 */
+			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.0",
+			       extp->MajorVersion, extp->MinorVersion);
+
+			extp->MajorVersion = '1';
+			extp->MinorVersion = '0';
+		}
+	}
+
 	/*
 	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
 	 */



From glecerf at gmail.com  Wed Dec  8 10:19:01 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 16:19:01 +0100
Subject: [PATCH v2 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
Message-ID: <20101208151901.20317.30721.stgit@dev.siriade.com>

These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
to patch all Samsung chips with Major == 0 to 1.0.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
[2] https://dev.openwrt.org/ticket/7348

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..bca69d4 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
 static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
-	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
-	    extp->MajorVersion == '0')
-		extp->MajorVersion = '1';
+	if (cfi->mfr == CFI_MFR_SAMSUNG) {
+		if (extp->MajorVersion == '0') {
+			/*
+			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
+			 */
+			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.0",
+			       extp->MajorVersion, extp->MinorVersion);
+
+			extp->MajorVersion = '1';
+			extp->MinorVersion = '0';
+		}
+	}
+
 	/*
 	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
 	 */



From glecerf at gmail.com  Wed Dec  8 10:19:06 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 16:19:06 +0100
Subject: [PATCH v2 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101208151901.20317.30721.stgit@dev.siriade.com>
References: <20101208151901.20317.30721.stgit@dev.siriade.com>
Message-ID: <20101208151906.20317.53000.stgit@dev.siriade.com>

These chips report CFI v3.3 [1], so patch them on the fly to the more
correct v1.3.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
[2] https://dev.openwrt.org/ticket/866

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 28e05ad..bee619e 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -403,6 +403,19 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 			extp->MajorVersion = '1';
 			extp->MinorVersion = '0';
 		}
+		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
+			/*
+			 * Samsung K8D3x16UxC chips report major=3 / minor=3
+			 */
+			printk(KERN_NOTICE "  Newer Samsung flash detected, "
+			                   "should be compatibile with Amd/Fujitsu.\n");
+
+			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.3",
+			       extp->MajorVersion, extp->MinorVersion);
+
+			extp->MajorVersion = '1'; // set to 1.3
+			extp->MinorVersion = '3';
+		}
 	}
 
 	/*



From w.sang at pengutronix.de  Wed Dec  8 10:41:43 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 8 Dec 2010 16:41:43 +0100
Subject: [PATCH v2 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101208151906.20317.53000.stgit@dev.siriade.com>
References: <20101208151901.20317.30721.stgit@dev.siriade.com>
	<20101208151906.20317.53000.stgit@dev.siriade.com>
Message-ID: <20101208154143.GC4641@pengutronix.de>

On Wed, Dec 08, 2010 at 04:19:06PM +0100, Guillaume LECERF wrote:
> These chips report CFI v3.3 [1], so patch them on the fly to the more
> correct v1.3.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
> [2] https://dev.openwrt.org/ticket/866
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 28e05ad..bee619e 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -403,6 +403,19 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
>  			extp->MajorVersion = '1';
>  			extp->MinorVersion = '0';
>  		}
> +		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
> +			/*
> +			 * Samsung K8D3x16UxC chips report major=3 / minor=3
> +			 */
> +			printk(KERN_NOTICE "  Newer Samsung flash detected, "
> +			                   "should be compatibile with Amd/Fujitsu.\n");

compatible

> +

Extra line could be removed, but that's terribly minor :)

> +			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.3",
> +			       extp->MajorVersion, extp->MinorVersion);

loglevel? \n?

> +
> +			extp->MajorVersion = '1'; // set to 1.3

Use C-comments, please. Given the explanation in the printout above, can
also be dropped entirely IMHO.

> +			extp->MinorVersion = '3';
> +		}
>  	}

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101208/58f02167/attachment.sig>

From w.sang at pengutronix.de  Wed Dec  8 10:44:04 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 8 Dec 2010 16:44:04 +0100
Subject: [PATCH v2 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
In-Reply-To: <20101208151901.20317.30721.stgit@dev.siriade.com>
References: <20101208151901.20317.30721.stgit@dev.siriade.com>
Message-ID: <20101208154404.GD4641@pengutronix.de>

On Wed, Dec 08, 2010 at 04:19:01PM +0100, Guillaume LECERF wrote:
> These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
> to patch all Samsung chips with Major == 0 to 1.0.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
> [2] https://dev.openwrt.org/ticket/7348
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
>  1 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 9d68ab9..bca69d4 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
>  static void cfi_fixup_major_minor(struct cfi_private *cfi,
>  				  struct cfi_pri_amdstd *extp)
>  {
> -	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
> -	    extp->MajorVersion == '0')
> -		extp->MajorVersion = '1';
> +	if (cfi->mfr == CFI_MFR_SAMSUNG) {
> +		if (extp->MajorVersion == '0') {
> +			/*
> +			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
> +			 */
> +			printk("  Fixed Samsung's Amd/Fujitsu Extended Query version from %c.%c to 1.0",
> +			       extp->MajorVersion, extp->MinorVersion);

loglevel? \n? This check has just one printout while the other had two.
Should be in sync IMHO. Probably with fewer printout ;)

> +
> +			extp->MajorVersion = '1';
> +			extp->MinorVersion = '0';
> +		}
> +	}
> +

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101208/40e584f3/attachment-0001.sig>

From glecerf at gmail.com  Wed Dec  8 11:00:18 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 17:00:18 +0100
Subject: [PATCH v3 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
Message-ID: <20101208160018.22017.8779.stgit@dev.siriade.com>

These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
to patch all Samsung chips with Major == 0 to 1.0.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
[2] https://dev.openwrt.org/ticket/7348

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..7966f07 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
 static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
-	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
-	    extp->MajorVersion == '0')
-		extp->MajorVersion = '1';
+	if (cfi->mfr == CFI_MFR_SAMSUNG) {
+		if (extp->MajorVersion == '0') {
+			/*
+			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
+			 */
+			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 0.%c to 1.0\n",
+			       extp->MinorVersion);
+
+			extp->MajorVersion = '1';
+			extp->MinorVersion = '0';
+		}
+	}
+
 	/*
 	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
 	 */



From glecerf at gmail.com  Wed Dec  8 11:00:23 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Wed, 08 Dec 2010 17:00:23 +0100
Subject: [PATCH v3 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101208160018.22017.8779.stgit@dev.siriade.com>
References: <20101208160018.22017.8779.stgit@dev.siriade.com>
Message-ID: <20101208160023.22017.21978.stgit@dev.siriade.com>

These chips report CFI v3.3 [1], so patch them on the fly to the more
correct v1.3.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
[2] https://dev.openwrt.org/ticket/866

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 7966f07..8ad6ee9 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -403,6 +403,14 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 			extp->MajorVersion = '1';
 			extp->MinorVersion = '0';
 		}
+		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
+			/*
+			 * Samsung K8D3x16UxC chips report major=3 / minor=3
+			 */
+			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 3.3 to 1.3\n");
+
+			extp->MajorVersion = '1';
+		}
 	}
 
 	/*



From w.sang at pengutronix.de  Wed Dec  8 11:29:03 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 8 Dec 2010 17:29:03 +0100
Subject: [PATCH v3 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101208160023.22017.21978.stgit@dev.siriade.com>
References: <20101208160018.22017.8779.stgit@dev.siriade.com>
	<20101208160023.22017.21978.stgit@dev.siriade.com>
Message-ID: <20101208162903.GF4641@pengutronix.de>

On Wed, Dec 08, 2010 at 05:00:23PM +0100, Guillaume LECERF wrote:
> These chips report CFI v3.3 [1], so patch them on the fly to the more
> correct v1.3.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
> [2] https://dev.openwrt.org/ticket/866
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>

Acked-by: Wolfram Sang <w.sang at pengutronix.de>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101208/c2643d15/attachment.sig>

From w.sang at pengutronix.de  Wed Dec  8 11:32:18 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 8 Dec 2010 17:32:18 +0100
Subject: [PATCH v3 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
In-Reply-To: <20101208160018.22017.8779.stgit@dev.siriade.com>
References: <20101208160018.22017.8779.stgit@dev.siriade.com>
Message-ID: <20101208163218.GG4641@pengutronix.de>

On Wed, Dec 08, 2010 at 05:00:18PM +0100, Guillaume LECERF wrote:
> These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
> to patch all Samsung chips with Major == 0 to 1.0.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
> [2] https://dev.openwrt.org/ticket/7348
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>

One question left:

> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
>  1 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 9d68ab9..7966f07 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
>  static void cfi_fixup_major_minor(struct cfi_private *cfi,
>  				  struct cfi_pri_amdstd *extp)
>  {
> -	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
> -	    extp->MajorVersion == '0')
> -		extp->MajorVersion = '1';
> +	if (cfi->mfr == CFI_MFR_SAMSUNG) {
> +		if (extp->MajorVersion == '0') {
> +			/*
> +			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0

The code below is prepared to show minor != 0, so is the comment above
apropriate? Given that it is okay to fixup major = 0 and minor != 0 to
1.0, you can add my

Acked-by: Wolfram Sang <w.sang at pengutronix.de>

> +			 */
> +			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 0.%c to 1.0\n",
> +			       extp->MinorVersion);
> +
> +			extp->MajorVersion = '1';
> +			extp->MinorVersion = '0';
> +		}
> +	}
> +
>  	/*
>  	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
>  	 */
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101208/17a37164/attachment.sig>

From eparis at redhat.com  Wed Dec  8 14:45:27 2010
From: eparis at redhat.com (Eric Paris)
Date: Wed, 08 Dec 2010 14:45:27 -0500
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on inode
	creation
Message-ID: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>

SELinux would like to implement a new labeling behavior of newly created
inodes.  We currently label new inodes based on the parent and the creating
process.  This new behavior would also take into account the name of the
new object when deciding the new label.  This is not the (supposed) full path,
just the last component of the path.

This is very useful because creating /etc/shadow is different than creating
/etc/passwd but the kernel hooks are unable to differentiate these
operations.  We currently require that userspace realize it is doing some
difficult operation like that and than userspace jumps through SELinux hoops
to get things set up correctly.  This patch does not implement new
behavior, that is obviously contained in a seperate SELinux patch, but it
does pass the needed name down to the correct LSM hook.  If no such name
exists it is fine to pass NULL.

Signed-off-by: Eric Paris <eparis at redhat.com>
---

 fs/btrfs/inode.c               |   13 +++++++------
 fs/btrfs/xattr.c               |    6 ++++--
 fs/btrfs/xattr.h               |    3 ++-
 fs/ext2/ext2.h                 |    2 +-
 fs/ext2/ialloc.c               |    5 +++--
 fs/ext2/namei.c                |    8 ++++----
 fs/ext2/xattr.h                |    6 ++++--
 fs/ext2/xattr_security.c       |    5 +++--
 fs/ext3/ialloc.c               |    5 +++--
 fs/ext3/namei.c                |    8 ++++----
 fs/ext3/xattr.h                |    4 ++--
 fs/ext3/xattr_security.c       |    5 +++--
 fs/ext4/ialloc.c               |    2 +-
 fs/ext4/xattr.h                |    4 ++--
 fs/ext4/xattr_security.c       |    5 +++--
 fs/gfs2/inode.c                |    7 ++++---
 fs/jffs2/dir.c                 |    9 ++++-----
 fs/jffs2/nodelist.h            |    2 +-
 fs/jffs2/security.c            |    5 +++--
 fs/jffs2/write.c               |   18 ++++++++++--------
 fs/jffs2/xattr.h               |    5 +++--
 fs/jfs/jfs_xattr.h             |    5 +++--
 fs/jfs/namei.c                 |    8 ++++----
 fs/jfs/xattr.c                 |    6 ++++--
 fs/ocfs2/namei.c               |    4 ++--
 fs/ocfs2/refcounttree.c        |    3 ++-
 fs/ocfs2/xattr.c               |   10 ++++++----
 fs/ocfs2/xattr.h               |    4 +++-
 fs/reiserfs/namei.c            |    9 +++++----
 fs/reiserfs/xattr_security.c   |    3 ++-
 fs/xfs/linux-2.6/xfs_iops.c    |    9 +++++----
 include/linux/ext3_fs.h        |    3 ++-
 include/linux/reiserfs_xattr.h |    2 ++
 include/linux/security.h       |    9 +++++++--
 mm/shmem.c                     |    9 +++++----
 security/capability.c          |    3 ++-
 security/security.c            |    6 ++++--
 security/selinux/hooks.c       |    5 +++--
 security/smack/smack_lsm.c     |    5 ++++-
 39 files changed, 136 insertions(+), 94 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 8039390..ffc6e15 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -90,13 +90,14 @@ static noinline int cow_file_range(struct inode *inode,
 				   unsigned long *nr_written, int unlock);
 
 static int btrfs_init_inode_security(struct btrfs_trans_handle *trans,
-				     struct inode *inode,  struct inode *dir)
+				     struct inode *inode,  struct inode *dir,
+				     const struct qstr *qstr)
 {
 	int err;
 
 	err = btrfs_init_acl(trans, inode, dir);
 	if (!err)
-		err = btrfs_xattr_security_init(trans, inode, dir);
+		err = btrfs_xattr_security_init(trans, inode, dir, qstr);
 	return err;
 }
 
@@ -4675,7 +4676,7 @@ static int btrfs_mknod(struct inode *dir, struct dentry *dentry,
 	if (IS_ERR(inode))
 		goto out_unlock;
 
-	err = btrfs_init_inode_security(trans, inode, dir);
+	err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name);
 	if (err) {
 		drop_inode = 1;
 		goto out_unlock;
@@ -4736,7 +4737,7 @@ static int btrfs_create(struct inode *dir, struct dentry *dentry,
 	if (IS_ERR(inode))
 		goto out_unlock;
 
-	err = btrfs_init_inode_security(trans, inode, dir);
+	err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name);
 	if (err) {
 		drop_inode = 1;
 		goto out_unlock;
@@ -4864,7 +4865,7 @@ static int btrfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 
 	drop_on_err = 1;
 
-	err = btrfs_init_inode_security(trans, inode, dir);
+	err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name);
 	if (err)
 		goto out_fail;
 
@@ -6940,7 +6941,7 @@ static int btrfs_symlink(struct inode *dir, struct dentry *dentry,
 	if (IS_ERR(inode))
 		goto out_unlock;
 
-	err = btrfs_init_inode_security(trans, inode, dir);
+	err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name);
 	if (err) {
 		drop_inode = 1;
 		goto out_unlock;
diff --git a/fs/btrfs/xattr.c b/fs/btrfs/xattr.c
index 698fdd2..3338a7e 100644
--- a/fs/btrfs/xattr.c
+++ b/fs/btrfs/xattr.c
@@ -352,7 +352,8 @@ int btrfs_removexattr(struct dentry *dentry, const char *name)
 }
 
 int btrfs_xattr_security_init(struct btrfs_trans_handle *trans,
-			      struct inode *inode, struct inode *dir)
+			      struct inode *inode, struct inode *dir,
+			      const struct qstr *qstr)
 {
 	int err;
 	size_t len;
@@ -360,7 +361,8 @@ int btrfs_xattr_security_init(struct btrfs_trans_handle *trans,
 	char *suffix;
 	char *name;
 
-	err = security_inode_init_security(inode, dir, &suffix, &value, &len);
+	err = security_inode_init_security(inode, dir, qstr, &suffix, &value,
+					   &len);
 	if (err) {
 		if (err == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/btrfs/xattr.h b/fs/btrfs/xattr.h
index 7a43fd6..b3cc803 100644
--- a/fs/btrfs/xattr.h
+++ b/fs/btrfs/xattr.h
@@ -37,6 +37,7 @@ extern int btrfs_setxattr(struct dentry *dentry, const char *name,
 extern int btrfs_removexattr(struct dentry *dentry, const char *name);
 
 extern int btrfs_xattr_security_init(struct btrfs_trans_handle *trans,
-				     struct inode *inode, struct inode *dir);
+				     struct inode *inode, struct inode *dir,
+				     const struct qstr *qstr);
 
 #endif /* __XATTR__ */
diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h
index 6346a2a..1b48c33 100644
--- a/fs/ext2/ext2.h
+++ b/fs/ext2/ext2.h
@@ -110,7 +110,7 @@ extern struct ext2_dir_entry_2 * ext2_dotdot (struct inode *, struct page **);
 extern void ext2_set_link(struct inode *, struct ext2_dir_entry_2 *, struct page *, struct inode *, int);
 
 /* ialloc.c */
-extern struct inode * ext2_new_inode (struct inode *, int);
+extern struct inode * ext2_new_inode (struct inode *, int, const struct qstr *);
 extern void ext2_free_inode (struct inode *);
 extern unsigned long ext2_count_free_inodes (struct super_block *);
 extern void ext2_check_inodes_bitmap (struct super_block *);
diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c
index ad70479..ee9ed31 100644
--- a/fs/ext2/ialloc.c
+++ b/fs/ext2/ialloc.c
@@ -429,7 +429,8 @@ found:
 	return group;
 }
 
-struct inode *ext2_new_inode(struct inode *dir, int mode)
+struct inode *ext2_new_inode(struct inode *dir, int mode,
+			     const struct qstr *qstr)
 {
 	struct super_block *sb;
 	struct buffer_head *bitmap_bh = NULL;
@@ -585,7 +586,7 @@ got:
 	if (err)
 		goto fail_free_drop;
 
-	err = ext2_init_security(inode,dir);
+	err = ext2_init_security(inode, dir, qstr);
 	if (err)
 		goto fail_free_drop;
 
diff --git a/fs/ext2/namei.c b/fs/ext2/namei.c
index f8aecd2..368d704 100644
--- a/fs/ext2/namei.c
+++ b/fs/ext2/namei.c
@@ -104,7 +104,7 @@ static int ext2_create (struct inode * dir, struct dentry * dentry, int mode, st
 
 	dquot_initialize(dir);
 
-	inode = ext2_new_inode(dir, mode);
+	inode = ext2_new_inode(dir, mode, &dentry->d_name);
 	if (IS_ERR(inode))
 		return PTR_ERR(inode);
 
@@ -133,7 +133,7 @@ static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, dev_
 
 	dquot_initialize(dir);
 
-	inode = ext2_new_inode (dir, mode);
+	inode = ext2_new_inode (dir, mode, &dentry->d_name);
 	err = PTR_ERR(inode);
 	if (!IS_ERR(inode)) {
 		init_special_inode(inode, inode->i_mode, rdev);
@@ -159,7 +159,7 @@ static int ext2_symlink (struct inode * dir, struct dentry * dentry,
 
 	dquot_initialize(dir);
 
-	inode = ext2_new_inode (dir, S_IFLNK | S_IRWXUGO);
+	inode = ext2_new_inode (dir, S_IFLNK | S_IRWXUGO, &dentry->d_name);
 	err = PTR_ERR(inode);
 	if (IS_ERR(inode))
 		goto out;
@@ -230,7 +230,7 @@ static int ext2_mkdir(struct inode * dir, struct dentry * dentry, int mode)
 
 	inode_inc_link_count(dir);
 
-	inode = ext2_new_inode (dir, S_IFDIR | mode);
+	inode = ext2_new_inode(dir, S_IFDIR | mode, &dentry->d_name);
 	err = PTR_ERR(inode);
 	if (IS_ERR(inode))
 		goto out_dir;
diff --git a/fs/ext2/xattr.h b/fs/ext2/xattr.h
index a1a1c21..5e41ccc 100644
--- a/fs/ext2/xattr.h
+++ b/fs/ext2/xattr.h
@@ -116,9 +116,11 @@ exit_ext2_xattr(void)
 # endif  /* CONFIG_EXT2_FS_XATTR */
 
 #ifdef CONFIG_EXT2_FS_SECURITY
-extern int ext2_init_security(struct inode *inode, struct inode *dir);
+extern int ext2_init_security(struct inode *inode, struct inode *dir,
+			      const struct qstr *qstr);
 #else
-static inline int ext2_init_security(struct inode *inode, struct inode *dir)
+static inline int ext2_init_security(struct inode *inode, struct inode *dir,
+				     const struct qstr *qstr)
 {
 	return 0;
 }
diff --git a/fs/ext2/xattr_security.c b/fs/ext2/xattr_security.c
index 3004e15..5d979b4 100644
--- a/fs/ext2/xattr_security.c
+++ b/fs/ext2/xattr_security.c
@@ -47,14 +47,15 @@ ext2_xattr_security_set(struct dentry *dentry, const char *name,
 }
 
 int
-ext2_init_security(struct inode *inode, struct inode *dir)
+ext2_init_security(struct inode *inode, struct inode *dir,
+		   const struct qstr *qstr)
 {
 	int err;
 	size_t len;
 	void *value;
 	char *name;
 
-	err = security_inode_init_security(inode, dir, &name, &value, &len);
+	err = security_inode_init_security(inode, dir, qstr, &name, &value, &len);
 	if (err) {
 		if (err == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/ext3/ialloc.c b/fs/ext3/ialloc.c
index 9724aef..bfc2dc4 100644
--- a/fs/ext3/ialloc.c
+++ b/fs/ext3/ialloc.c
@@ -404,7 +404,8 @@ static int find_group_other(struct super_block *sb, struct inode *parent)
  * For other inodes, search forward from the parent directory's block
  * group to find a free inode.
  */
-struct inode *ext3_new_inode(handle_t *handle, struct inode * dir, int mode)
+struct inode *ext3_new_inode(handle_t *handle, struct inode * dir,
+			     const struct qstr *qstr, int mode)
 {
 	struct super_block *sb;
 	struct buffer_head *bitmap_bh = NULL;
@@ -589,7 +590,7 @@ got:
 	if (err)
 		goto fail_free_drop;
 
-	err = ext3_init_security(handle,inode, dir);
+	err = ext3_init_security(handle, inode, dir, qstr);
 	if (err)
 		goto fail_free_drop;
 
diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
index bce9dce..a900033 100644
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -1707,7 +1707,7 @@ retry:
 	if (IS_DIRSYNC(dir))
 		handle->h_sync = 1;
 
-	inode = ext3_new_inode (handle, dir, mode);
+	inode = ext3_new_inode (handle, dir, &dentry->d_name, mode);
 	err = PTR_ERR(inode);
 	if (!IS_ERR(inode)) {
 		inode->i_op = &ext3_file_inode_operations;
@@ -1743,7 +1743,7 @@ retry:
 	if (IS_DIRSYNC(dir))
 		handle->h_sync = 1;
 
-	inode = ext3_new_inode (handle, dir, mode);
+	inode = ext3_new_inode (handle, dir, &dentry->d_name, mode);
 	err = PTR_ERR(inode);
 	if (!IS_ERR(inode)) {
 		init_special_inode(inode, inode->i_mode, rdev);
@@ -1781,7 +1781,7 @@ retry:
 	if (IS_DIRSYNC(dir))
 		handle->h_sync = 1;
 
-	inode = ext3_new_inode (handle, dir, S_IFDIR | mode);
+	inode = ext3_new_inode (handle, dir, &dentry->d_name, S_IFDIR | mode);
 	err = PTR_ERR(inode);
 	if (IS_ERR(inode))
 		goto out_stop;
@@ -2195,7 +2195,7 @@ retry:
 	if (IS_DIRSYNC(dir))
 		handle->h_sync = 1;
 
-	inode = ext3_new_inode (handle, dir, S_IFLNK|S_IRWXUGO);
+	inode = ext3_new_inode (handle, dir, &dentry->d_name, S_IFLNK|S_IRWXUGO);
 	err = PTR_ERR(inode);
 	if (IS_ERR(inode))
 		goto out_stop;
diff --git a/fs/ext3/xattr.h b/fs/ext3/xattr.h
index 377fe72..2be4f69 100644
--- a/fs/ext3/xattr.h
+++ b/fs/ext3/xattr.h
@@ -128,10 +128,10 @@ exit_ext3_xattr(void)
 
 #ifdef CONFIG_EXT3_FS_SECURITY
 extern int ext3_init_security(handle_t *handle, struct inode *inode,
-				struct inode *dir);
+			      struct inode *dir, const struct qstr *qstr);
 #else
 static inline int ext3_init_security(handle_t *handle, struct inode *inode,
-				struct inode *dir)
+				     struct inode *dir, const struct qstr *qstr)
 {
 	return 0;
 }
diff --git a/fs/ext3/xattr_security.c b/fs/ext3/xattr_security.c
index 03a99bf..b8d9f83 100644
--- a/fs/ext3/xattr_security.c
+++ b/fs/ext3/xattr_security.c
@@ -49,14 +49,15 @@ ext3_xattr_security_set(struct dentry *dentry, const char *name,
 }
 
 int
-ext3_init_security(handle_t *handle, struct inode *inode, struct inode *dir)
+ext3_init_security(handle_t *handle, struct inode *inode, struct inode *dir,
+		   const struct qstr *qstr)
 {
 	int err;
 	size_t len;
 	void *value;
 	char *name;
 
-	err = security_inode_init_security(inode, dir, &name, &value, &len);
+	err = security_inode_init_security(inode, dir, qstr, &name, &value, &len);
 	if (err) {
 		if (err == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 1ce240a..49b6cfd 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1042,7 +1042,7 @@ got:
 	if (err)
 		goto fail_free_drop;
 
-	err = ext4_init_security(handle, inode, dir);
+	err = ext4_init_security(handle, inode, dir, qstr);
 	if (err)
 		goto fail_free_drop;
 
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 1ef1652..25b7387 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -145,10 +145,10 @@ ext4_expand_extra_isize_ea(struct inode *inode, int new_extra_isize,
 
 #ifdef CONFIG_EXT4_FS_SECURITY
 extern int ext4_init_security(handle_t *handle, struct inode *inode,
-				struct inode *dir);
+			      struct inode *dir, const struct qstr *qstr);
 #else
 static inline int ext4_init_security(handle_t *handle, struct inode *inode,
-				struct inode *dir)
+				     struct inode *dir, const struct qstr *qstr)
 {
 	return 0;
 }
diff --git a/fs/ext4/xattr_security.c b/fs/ext4/xattr_security.c
index 9b21268..007c3bf 100644
--- a/fs/ext4/xattr_security.c
+++ b/fs/ext4/xattr_security.c
@@ -49,14 +49,15 @@ ext4_xattr_security_set(struct dentry *dentry, const char *name,
 }
 
 int
-ext4_init_security(handle_t *handle, struct inode *inode, struct inode *dir)
+ext4_init_security(handle_t *handle, struct inode *inode, struct inode *dir,
+		   const struct qstr *qstr)
 {
 	int err;
 	size_t len;
 	void *value;
 	char *name;
 
-	err = security_inode_init_security(inode, dir, &name, &value, &len);
+	err = security_inode_init_security(inode, dir, qstr, &name, &value, &len);
 	if (err) {
 		if (err == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index e1213f7..52fd31e 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -791,14 +791,15 @@ fail:
 	return error;
 }
 
-static int gfs2_security_init(struct gfs2_inode *dip, struct gfs2_inode *ip)
+static int gfs2_security_init(struct gfs2_inode *dip, struct gfs2_inode *ip,
+			      const struct qstr *qstr)
 {
 	int err;
 	size_t len;
 	void *value;
 	char *name;
 
-	err = security_inode_init_security(&ip->i_inode, &dip->i_inode,
+	err = security_inode_init_security(&ip->i_inode, &dip->i_inode, qstr,
 					   &name, &value, &len);
 
 	if (err) {
@@ -882,7 +883,7 @@ struct inode *gfs2_createi(struct gfs2_holder *ghs, const struct qstr *name,
 	if (error)
 		goto fail_gunlock2;
 
-	error = gfs2_security_init(dip, GFS2_I(inode));
+	error = gfs2_security_init(dip, GFS2_I(inode), name);
 	if (error)
 		goto fail_gunlock2;
 
diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c
index 9297865..82faddd 100644
--- a/fs/jffs2/dir.c
+++ b/fs/jffs2/dir.c
@@ -215,8 +215,7 @@ static int jffs2_create(struct inode *dir_i, struct dentry *dentry, int mode,
 	   no chance of AB-BA deadlock involving its f->sem). */
 	mutex_unlock(&f->sem);
 
-	ret = jffs2_do_create(c, dir_f, f, ri,
-			      dentry->d_name.name, dentry->d_name.len);
+	ret = jffs2_do_create(c, dir_f, f, ri, &dentry->d_name);
 	if (ret)
 		goto fail;
 
@@ -386,7 +385,7 @@ static int jffs2_symlink (struct inode *dir_i, struct dentry *dentry, const char
 
 	jffs2_complete_reservation(c);
 
-	ret = jffs2_init_security(inode, dir_i);
+	ret = jffs2_init_security(inode, dir_i, &dentry->d_name);
 	if (ret)
 		goto fail;
 
@@ -530,7 +529,7 @@ static int jffs2_mkdir (struct inode *dir_i, struct dentry *dentry, int mode)
 
 	jffs2_complete_reservation(c);
 
-	ret = jffs2_init_security(inode, dir_i);
+	ret = jffs2_init_security(inode, dir_i, &dentry->d_name);
 	if (ret)
 		goto fail;
 
@@ -703,7 +702,7 @@ static int jffs2_mknod (struct inode *dir_i, struct dentry *dentry, int mode, de
 
 	jffs2_complete_reservation(c);
 
-	ret = jffs2_init_security(inode, dir_i);
+	ret = jffs2_init_security(inode, dir_i, &dentry->d_name);
 	if (ret)
 		goto fail;
 
diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
index 5a53d9b..e4619b0 100644
--- a/fs/jffs2/nodelist.h
+++ b/fs/jffs2/nodelist.h
@@ -401,7 +401,7 @@ int jffs2_write_inode_range(struct jffs2_sb_info *c, struct jffs2_inode_info *f,
 			    struct jffs2_raw_inode *ri, unsigned char *buf,
 			    uint32_t offset, uint32_t writelen, uint32_t *retlen);
 int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, struct jffs2_inode_info *f,
-		    struct jffs2_raw_inode *ri, const char *name, int namelen);
+		    struct jffs2_raw_inode *ri, const struct qstr *qstr);
 int jffs2_do_unlink(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, const char *name,
 		    int namelen, struct jffs2_inode_info *dead_f, uint32_t time);
 int jffs2_do_link(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, uint32_t ino,
diff --git a/fs/jffs2/security.c b/fs/jffs2/security.c
index 239f512..cfeb716 100644
--- a/fs/jffs2/security.c
+++ b/fs/jffs2/security.c
@@ -23,14 +23,15 @@
 #include "nodelist.h"
 
 /* ---- Initial Security Label Attachment -------------- */
-int jffs2_init_security(struct inode *inode, struct inode *dir)
+int jffs2_init_security(struct inode *inode, struct inode *dir,
+			const struct qstr *qstr)
 {
 	int rc;
 	size_t len;
 	void *value;
 	char *name;
 
-	rc = security_inode_init_security(inode, dir, &name, &value, &len);
+	rc = security_inode_init_security(inode, dir, qstr, &name, &value, &len);
 	if (rc) {
 		if (rc == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/jffs2/write.c b/fs/jffs2/write.c
index c819eb0..30d175b 100644
--- a/fs/jffs2/write.c
+++ b/fs/jffs2/write.c
@@ -424,7 +424,9 @@ int jffs2_write_inode_range(struct jffs2_sb_info *c, struct jffs2_inode_info *f,
 	return ret;
 }
 
-int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, struct jffs2_inode_info *f, struct jffs2_raw_inode *ri, const char *name, int namelen)
+int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f,
+		    struct jffs2_inode_info *f, struct jffs2_raw_inode *ri,
+		    const struct qstr *qstr)
 {
 	struct jffs2_raw_dirent *rd;
 	struct jffs2_full_dnode *fn;
@@ -466,15 +468,15 @@ int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, str
 	mutex_unlock(&f->sem);
 	jffs2_complete_reservation(c);
 
-	ret = jffs2_init_security(&f->vfs_inode, &dir_f->vfs_inode);
+	ret = jffs2_init_security(&f->vfs_inode, &dir_f->vfs_inode, qstr);
 	if (ret)
 		return ret;
 	ret = jffs2_init_acl_post(&f->vfs_inode);
 	if (ret)
 		return ret;
 
-	ret = jffs2_reserve_space(c, sizeof(*rd)+namelen, &alloclen,
-				ALLOC_NORMAL, JFFS2_SUMMARY_DIRENT_SIZE(namelen));
+	ret = jffs2_reserve_space(c, sizeof(*rd)+qstr->len, &alloclen,
+				ALLOC_NORMAL, JFFS2_SUMMARY_DIRENT_SIZE(qstr->len));
 
 	if (ret) {
 		/* Eep. */
@@ -493,19 +495,19 @@ int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, str
 
 	rd->magic = cpu_to_je16(JFFS2_MAGIC_BITMASK);
 	rd->nodetype = cpu_to_je16(JFFS2_NODETYPE_DIRENT);
-	rd->totlen = cpu_to_je32(sizeof(*rd) + namelen);
+	rd->totlen = cpu_to_je32(sizeof(*rd) + qstr->len);
 	rd->hdr_crc = cpu_to_je32(crc32(0, rd, sizeof(struct jffs2_unknown_node)-4));
 
 	rd->pino = cpu_to_je32(dir_f->inocache->ino);
 	rd->version = cpu_to_je32(++dir_f->highest_version);
 	rd->ino = ri->ino;
 	rd->mctime = ri->ctime;
-	rd->nsize = namelen;
+	rd->nsize = qstr->len;
 	rd->type = DT_REG;
 	rd->node_crc = cpu_to_je32(crc32(0, rd, sizeof(*rd)-8));
-	rd->name_crc = cpu_to_je32(crc32(0, name, namelen));
+	rd->name_crc = cpu_to_je32(crc32(0, qstr->name, qstr->len));
 
-	fd = jffs2_write_dirent(c, dir_f, rd, name, namelen, ALLOC_NORMAL);
+	fd = jffs2_write_dirent(c, dir_f, rd, qstr->name, qstr->len, ALLOC_NORMAL);
 
 	jffs2_free_raw_dirent(rd);
 
diff --git a/fs/jffs2/xattr.h b/fs/jffs2/xattr.h
index cf4f575..7be4beb 100644
--- a/fs/jffs2/xattr.h
+++ b/fs/jffs2/xattr.h
@@ -121,10 +121,11 @@ extern ssize_t jffs2_listxattr(struct dentry *, char *, size_t);
 #endif /* CONFIG_JFFS2_FS_XATTR */
 
 #ifdef CONFIG_JFFS2_FS_SECURITY
-extern int jffs2_init_security(struct inode *inode, struct inode *dir);
+extern int jffs2_init_security(struct inode *inode, struct inode *dir,
+			       const struct qstr *qstr);
 extern const struct xattr_handler jffs2_security_xattr_handler;
 #else
-#define jffs2_init_security(inode,dir)	(0)
+#define jffs2_init_security(inode,dir,qstr)	(0)
 #endif /* CONFIG_JFFS2_FS_SECURITY */
 
 #endif /* _JFFS2_FS_XATTR_H_ */
diff --git a/fs/jfs/jfs_xattr.h b/fs/jfs/jfs_xattr.h
index 88b6cc5..e9e100f 100644
--- a/fs/jfs/jfs_xattr.h
+++ b/fs/jfs/jfs_xattr.h
@@ -62,10 +62,11 @@ extern ssize_t jfs_listxattr(struct dentry *, char *, size_t);
 extern int jfs_removexattr(struct dentry *, const char *);
 
 #ifdef CONFIG_JFS_SECURITY
-extern int jfs_init_security(tid_t, struct inode *, struct inode *);
+extern int jfs_init_security(tid_t, struct inode *, struct inode *,
+			     const struct qstr *);
 #else
 static inline int jfs_init_security(tid_t tid, struct inode *inode,
-				    struct inode *dir)
+				    struct inode *dir, const struct qstr *qstr)
 {
 	return 0;
 }
diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
index 231ca4a..ff0fda9 100644
--- a/fs/jfs/namei.c
+++ b/fs/jfs/namei.c
@@ -114,7 +114,7 @@ static int jfs_create(struct inode *dip, struct dentry *dentry, int mode,
 	if (rc)
 		goto out3;
 
-	rc = jfs_init_security(tid, ip, dip);
+	rc = jfs_init_security(tid, ip, dip, &dentry->d_name);
 	if (rc) {
 		txAbort(tid, 0);
 		goto out3;
@@ -252,7 +252,7 @@ static int jfs_mkdir(struct inode *dip, struct dentry *dentry, int mode)
 	if (rc)
 		goto out3;
 
-	rc = jfs_init_security(tid, ip, dip);
+	rc = jfs_init_security(tid, ip, dip, &dentry->d_name);
 	if (rc) {
 		txAbort(tid, 0);
 		goto out3;
@@ -931,7 +931,7 @@ static int jfs_symlink(struct inode *dip, struct dentry *dentry,
 	mutex_lock_nested(&JFS_IP(dip)->commit_mutex, COMMIT_MUTEX_PARENT);
 	mutex_lock_nested(&JFS_IP(ip)->commit_mutex, COMMIT_MUTEX_CHILD);
 
-	rc = jfs_init_security(tid, ip, dip);
+	rc = jfs_init_security(tid, ip, dip, &dentry->d_name);
 	if (rc)
 		goto out3;
 
@@ -1394,7 +1394,7 @@ static int jfs_mknod(struct inode *dir, struct dentry *dentry,
 	if (rc)
 		goto out3;
 
-	rc = jfs_init_security(tid, ip, dir);
+	rc = jfs_init_security(tid, ip, dir, &dentry->d_name);
 	if (rc) {
 		txAbort(tid, 0);
 		goto out3;
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 2d7f165..3fa4c32 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -1091,7 +1091,8 @@ int jfs_removexattr(struct dentry *dentry, const char *name)
 }
 
 #ifdef CONFIG_JFS_SECURITY
-int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir)
+int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir,
+		      const struct qstr *qstr)
 {
 	int rc;
 	size_t len;
@@ -1099,7 +1100,8 @@ int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir)
 	char *suffix;
 	char *name;
 
-	rc = security_inode_init_security(inode, dir, &suffix, &value, &len);
+	rc = security_inode_init_security(inode, dir, qstr, &suffix, &value,
+					  &len);
 	if (rc) {
 		if (rc == -EOPNOTSUPP)
 			return 0;
diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index ff5744e..7740bc0 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -294,7 +294,7 @@ static int ocfs2_mknod(struct inode *dir,
 	}
 
 	/* get security xattr */
-	status = ocfs2_init_security_get(inode, dir, &si);
+	status = ocfs2_init_security_get(inode, dir, &dentry->d_name, &si);
 	if (status) {
 		if (status == -EOPNOTSUPP)
 			si.enable = 0;
@@ -1665,7 +1665,7 @@ static int ocfs2_symlink(struct inode *dir,
 	}
 
 	/* get security xattr */
-	status = ocfs2_init_security_get(inode, dir, &si);
+	status = ocfs2_init_security_get(inode, dir, &dentry->d_name, &si);
 	if (status) {
 		if (status == -EOPNOTSUPP)
 			si.enable = 0;
diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index b5f9160..cd3f5b4 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -4325,7 +4325,8 @@ static int ocfs2_reflink(struct dentry *old_dentry, struct inode *dir,
 
 	/* If the security isn't preserved, we need to re-initialize them. */
 	if (!preserve) {
-		error = ocfs2_init_security_and_acl(dir, new_orphan_inode);
+		error = ocfs2_init_security_and_acl(dir, new_orphan_inode,
+						    &new_dentry->d_name);
 		if (error)
 			mlog_errno(error);
 	}
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 67cd439..6bb6024 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -7185,7 +7185,8 @@ out:
  * must not hold any lock expect i_mutex.
  */
 int ocfs2_init_security_and_acl(struct inode *dir,
-				struct inode *inode)
+				struct inode *inode,
+				const struct qstr *qstr)
 {
 	int ret = 0;
 	struct buffer_head *dir_bh = NULL;
@@ -7193,7 +7194,7 @@ int ocfs2_init_security_and_acl(struct inode *dir,
 		.enable = 1,
 	};
 
-	ret = ocfs2_init_security_get(inode, dir, &si);
+	ret = ocfs2_init_security_get(inode, dir, qstr, &si);
 	if (!ret) {
 		ret = ocfs2_xattr_set(inode, OCFS2_XATTR_INDEX_SECURITY,
 				      si.name, si.value, si.value_len,
@@ -7261,13 +7262,14 @@ static int ocfs2_xattr_security_set(struct dentry *dentry, const char *name,
 
 int ocfs2_init_security_get(struct inode *inode,
 			    struct inode *dir,
+			    const struct qstr *qstr,
 			    struct ocfs2_security_xattr_info *si)
 {
 	/* check whether ocfs2 support feature xattr */
 	if (!ocfs2_supports_xattr(OCFS2_SB(dir->i_sb)))
 		return -EOPNOTSUPP;
-	return security_inode_init_security(inode, dir, &si->name, &si->value,
-					    &si->value_len);
+	return security_inode_init_security(inode, dir, qstr, &si->name,
+					    &si->value, &si->value_len);
 }
 
 int ocfs2_init_security_set(handle_t *handle,
diff --git a/fs/ocfs2/xattr.h b/fs/ocfs2/xattr.h
index aa64bb3..d63cfb7 100644
--- a/fs/ocfs2/xattr.h
+++ b/fs/ocfs2/xattr.h
@@ -57,6 +57,7 @@ int ocfs2_has_inline_xattr_value_outside(struct inode *inode,
 					 struct ocfs2_dinode *di);
 int ocfs2_xattr_remove(struct inode *, struct buffer_head *);
 int ocfs2_init_security_get(struct inode *, struct inode *,
+			    const struct qstr *,
 			    struct ocfs2_security_xattr_info *);
 int ocfs2_init_security_set(handle_t *, struct inode *,
 			    struct buffer_head *,
@@ -94,5 +95,6 @@ int ocfs2_reflink_xattrs(struct inode *old_inode,
 			 struct buffer_head *new_bh,
 			 bool preserve_security);
 int ocfs2_init_security_and_acl(struct inode *dir,
-				struct inode *inode);
+				struct inode *inode,
+				const struct qstr *qstr);
 #endif /* OCFS2_XATTR_H */
diff --git a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
index ba5f51e..d5b22ed 100644
--- a/fs/reiserfs/namei.c
+++ b/fs/reiserfs/namei.c
@@ -593,7 +593,7 @@ static int reiserfs_create(struct inode *dir, struct dentry *dentry, int mode,
 	new_inode_init(inode, dir, mode);
 
 	jbegin_count += reiserfs_cache_default_acl(dir);
-	retval = reiserfs_security_init(dir, inode, &security);
+	retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security);
 	if (retval < 0) {
 		drop_new_inode(inode);
 		return retval;
@@ -667,7 +667,7 @@ static int reiserfs_mknod(struct inode *dir, struct dentry *dentry, int mode,
 	new_inode_init(inode, dir, mode);
 
 	jbegin_count += reiserfs_cache_default_acl(dir);
-	retval = reiserfs_security_init(dir, inode, &security);
+	retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security);
 	if (retval < 0) {
 		drop_new_inode(inode);
 		return retval;
@@ -747,7 +747,7 @@ static int reiserfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 	new_inode_init(inode, dir, mode);
 
 	jbegin_count += reiserfs_cache_default_acl(dir);
-	retval = reiserfs_security_init(dir, inode, &security);
+	retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security);
 	if (retval < 0) {
 		drop_new_inode(inode);
 		return retval;
@@ -1032,7 +1032,8 @@ static int reiserfs_symlink(struct inode *parent_dir,
 	}
 	new_inode_init(inode, parent_dir, mode);
 
-	retval = reiserfs_security_init(parent_dir, inode, &security);
+	retval = reiserfs_security_init(parent_dir, inode, &dentry->d_name,
+					&security);
 	if (retval < 0) {
 		drop_new_inode(inode);
 		return retval;
diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c
index 237c692..ef66c18 100644
--- a/fs/reiserfs/xattr_security.c
+++ b/fs/reiserfs/xattr_security.c
@@ -54,6 +54,7 @@ static size_t security_list(struct dentry *dentry, char *list, size_t list_len,
  * of blocks needed for the transaction. If successful, reiserfs_security
  * must be released using reiserfs_security_free when the caller is done. */
 int reiserfs_security_init(struct inode *dir, struct inode *inode,
+			   const struct qstr *qstr,
 			   struct reiserfs_security_handle *sec)
 {
 	int blocks = 0;
@@ -65,7 +66,7 @@ int reiserfs_security_init(struct inode *dir, struct inode *inode,
 	if (IS_PRIVATE(dir))
 		return 0;
 
-	error = security_inode_init_security(inode, dir, &sec->name,
+	error = security_inode_init_security(inode, dir, qstr, &sec->name,
 					     &sec->value, &sec->length);
 	if (error) {
 		if (error == -EOPNOTSUPP)
diff --git a/fs/xfs/linux-2.6/xfs_iops.c b/fs/xfs/linux-2.6/xfs_iops.c
index 94d5fd6..d9298cf 100644
--- a/fs/xfs/linux-2.6/xfs_iops.c
+++ b/fs/xfs/linux-2.6/xfs_iops.c
@@ -103,7 +103,8 @@ xfs_mark_inode_dirty(
 STATIC int
 xfs_init_security(
 	struct inode	*inode,
-	struct inode	*dir)
+	struct inode	*dir,
+	const struct qstr *qstr)
 {
 	struct xfs_inode *ip = XFS_I(inode);
 	size_t		length;
@@ -111,7 +112,7 @@ xfs_init_security(
 	unsigned char	*name;
 	int		error;
 
-	error = security_inode_init_security(inode, dir, (char **)&name,
+	error = security_inode_init_security(inode, dir, qstr, (char **)&name,
 					     &value, &length);
 	if (error) {
 		if (error == -EOPNOTSUPP)
@@ -195,7 +196,7 @@ xfs_vn_mknod(
 
 	inode = VFS_I(ip);
 
-	error = xfs_init_security(inode, dir);
+	error = xfs_init_security(inode, dir, &dentry->d_name);
 	if (unlikely(error))
 		goto out_cleanup_inode;
 
@@ -368,7 +369,7 @@ xfs_vn_symlink(
 
 	inode = VFS_I(cip);
 
-	error = xfs_init_security(inode, dir);
+	error = xfs_init_security(inode, dir, &dentry->d_name);
 	if (unlikely(error))
 		goto out_cleanup_inode;
 
diff --git a/include/linux/ext3_fs.h b/include/linux/ext3_fs.h
index 6ce1bca..87312a8 100644
--- a/include/linux/ext3_fs.h
+++ b/include/linux/ext3_fs.h
@@ -874,7 +874,8 @@ extern int ext3fs_dirhash(const char *name, int len, struct
 			  dx_hash_info *hinfo);
 
 /* ialloc.c */
-extern struct inode * ext3_new_inode (handle_t *, struct inode *, int);
+extern struct inode * ext3_new_inode (handle_t *, struct inode *,
+				      const struct qstr *, int);
 extern void ext3_free_inode (handle_t *, struct inode *);
 extern struct inode * ext3_orphan_get (struct super_block *, unsigned long);
 extern unsigned long ext3_count_free_inodes (struct super_block *);
diff --git a/include/linux/reiserfs_xattr.h b/include/linux/reiserfs_xattr.h
index b2cf208..c2b7147 100644
--- a/include/linux/reiserfs_xattr.h
+++ b/include/linux/reiserfs_xattr.h
@@ -63,6 +63,7 @@ extern const struct xattr_handler reiserfs_xattr_trusted_handler;
 extern const struct xattr_handler reiserfs_xattr_security_handler;
 #ifdef CONFIG_REISERFS_FS_SECURITY
 int reiserfs_security_init(struct inode *dir, struct inode *inode,
+			   const struct qstr *qstr,
 			   struct reiserfs_security_handle *sec);
 int reiserfs_security_write(struct reiserfs_transaction_handle *th,
 			    struct inode *inode,
@@ -130,6 +131,7 @@ static inline void reiserfs_init_xattr_rwsem(struct inode *inode)
 #ifndef CONFIG_REISERFS_FS_SECURITY
 static inline int reiserfs_security_init(struct inode *dir,
 					 struct inode *inode,
+					 const struct qstr *qstr,
 					 struct reiserfs_security_handle *sec)
 {
 	return 0;
diff --git a/include/linux/security.h b/include/linux/security.h
index 4ab684e..02fcc0e 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -25,6 +25,7 @@
 #include <linux/fs.h>
 #include <linux/fsnotify.h>
 #include <linux/binfmts.h>
+#include <linux/dcache.h>
 #include <linux/signal.h>
 #include <linux/resource.h>
 #include <linux/sem.h>
@@ -315,6 +316,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
  *	then it should return -EOPNOTSUPP to skip this processing.
  *	@inode contains the inode structure of the newly created inode.
  *	@dir contains the inode structure of the parent directory.
+ *	@qstr contains the last path component of the new object
  *	@name will be set to the allocated name suffix (e.g. selinux).
  *	@value will be set to the allocated attribute value.
  *	@len will be set to the length of the value.
@@ -1437,7 +1439,8 @@ struct security_operations {
 	int (*inode_alloc_security) (struct inode *inode);
 	void (*inode_free_security) (struct inode *inode);
 	int (*inode_init_security) (struct inode *inode, struct inode *dir,
-				    char **name, void **value, size_t *len);
+				    const struct qstr *qstr, char **name,
+				    void **value, size_t *len);
 	int (*inode_create) (struct inode *dir,
 			     struct dentry *dentry, int mode);
 	int (*inode_link) (struct dentry *old_dentry,
@@ -1701,7 +1704,8 @@ int security_sb_parse_opts_str(char *options, struct security_mnt_opts *opts);
 int security_inode_alloc(struct inode *inode);
 void security_inode_free(struct inode *inode);
 int security_inode_init_security(struct inode *inode, struct inode *dir,
-				  char **name, void **value, size_t *len);
+				 const struct qstr *qstr, char **name,
+				 void **value, size_t *len);
 int security_inode_create(struct inode *dir, struct dentry *dentry, int mode);
 int security_inode_link(struct dentry *old_dentry, struct inode *dir,
 			 struct dentry *new_dentry);
@@ -2028,6 +2032,7 @@ static inline void security_inode_free(struct inode *inode)
 
 static inline int security_inode_init_security(struct inode *inode,
 						struct inode *dir,
+						const struct qstr *qstr,
 						char **name,
 						void **value,
 						size_t *len)
diff --git a/mm/shmem.c b/mm/shmem.c
index 47fdeeb..86cd21d 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1843,8 +1843,9 @@ shmem_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
 
 	inode = shmem_get_inode(dir->i_sb, dir, mode, dev, VM_NORESERVE);
 	if (inode) {
-		error = security_inode_init_security(inode, dir, NULL, NULL,
-						     NULL);
+		error = security_inode_init_security(inode, dir,
+						     &dentry->d_name, NULL,
+						     NULL, NULL);
 		if (error) {
 			if (error != -EOPNOTSUPP) {
 				iput(inode);
@@ -1983,8 +1984,8 @@ static int shmem_symlink(struct inode *dir, struct dentry *dentry, const char *s
 	if (!inode)
 		return -ENOSPC;
 
-	error = security_inode_init_security(inode, dir, NULL, NULL,
-					     NULL);
+	error = security_inode_init_security(inode, dir, &dentry->d_name, NULL,
+					     NULL, NULL);
 	if (error) {
 		if (error != -EOPNOTSUPP) {
 			iput(inode);
diff --git a/security/capability.c b/security/capability.c
index 92a1bff..c3d796c 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -118,7 +118,8 @@ static void cap_inode_free_security(struct inode *inode)
 }
 
 static int cap_inode_init_security(struct inode *inode, struct inode *dir,
-				   char **name, void **value, size_t *len)
+				   const struct qstr *qstr, char **name,
+				   void **value, size_t *len)
 {
 	return -EOPNOTSUPP;
 }
diff --git a/security/security.c b/security/security.c
index 799239d..7ebeb86 100644
--- a/security/security.c
+++ b/security/security.c
@@ -336,11 +336,13 @@ void security_inode_free(struct inode *inode)
 }
 
 int security_inode_init_security(struct inode *inode, struct inode *dir,
-				  char **name, void **value, size_t *len)
+				 const struct qstr *qstr, char **name,
+				 void **value, size_t *len)
 {
 	if (unlikely(IS_PRIVATE(inode)))
 		return -EOPNOTSUPP;
-	return security_ops->inode_init_security(inode, dir, name, value, len);
+	return security_ops->inode_init_security(inode, dir, qstr, name, value,
+						 len);
 }
 EXPORT_SYMBOL(security_inode_init_security);
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index b8dcd05..7699e23 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -39,6 +39,7 @@
 #include <linux/swap.h>
 #include <linux/spinlock.h>
 #include <linux/syscalls.h>
+#include <linux/dcache.h>
 #include <linux/file.h>
 #include <linux/fdtable.h>
 #include <linux/namei.h>
@@ -2509,8 +2510,8 @@ static void selinux_inode_free_security(struct inode *inode)
 }
 
 static int selinux_inode_init_security(struct inode *inode, struct inode *dir,
-				       char **name, void **value,
-				       size_t *len)
+				       const struct qstr *qstr, char **name,
+				       void **value, size_t *len)
 {
 	const struct task_security_struct *tsec = current_security();
 	struct inode_security_struct *dsec;
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 489a85a..581b65e 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -31,6 +31,7 @@
 #include <net/cipso_ipv4.h>
 #include <linux/audit.h>
 #include <linux/magic.h>
+#include <linux/dcache.h>
 #include "smack.h"
 
 #define task_security(task)	(task_cred_xxx((task), security))
@@ -424,6 +425,7 @@ static void smack_inode_free_security(struct inode *inode)
  * smack_inode_init_security - copy out the smack from an inode
  * @inode: the inode
  * @dir: unused
+ * @qstr: unused
  * @name: where to put the attribute name
  * @value: where to put the attribute value
  * @len: where to put the length of the attribute
@@ -431,7 +433,8 @@ static void smack_inode_free_security(struct inode *inode)
  * Returns 0 if it all works out, -ENOMEM if there's no memory
  */
 static int smack_inode_init_security(struct inode *inode, struct inode *dir,
-				     char **name, void **value, size_t *len)
+				     const struct qstr *qstr, char **name,
+				     void **value, size_t *len)
 {
 	char *isp = smk_of_inode(inode);
 



From glecerf at gmail.com  Thu Dec  9 09:04:11 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Thu, 09 Dec 2010 15:04:11 +0100
Subject: [PATCH v4 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
Message-ID: <20101209140410.26049.51539.stgit@dev.siriade.com>

These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
to patch all Samsung chips from 0.0 to 1.0.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
[2] https://dev.openwrt.org/ticket/7348

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..bf457a4 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -392,9 +392,17 @@ static struct cfi_fixup fixup_table[] = {
 static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
-	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
-	    extp->MajorVersion == '0')
-		extp->MajorVersion = '1';
+	if (cfi->mfr == CFI_MFR_SAMSUNG) {
+		if (extp->MajorVersion == '0' && extp->MinorVersion == '0') {
+			/*
+			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
+			 */
+			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 0.0 to 1.0\n");
+
+			extp->MajorVersion = '1';
+		}
+	}
+
 	/*
 	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
 	 */



From glecerf at gmail.com  Thu Dec  9 09:04:16 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Thu, 09 Dec 2010 15:04:16 +0100
Subject: [PATCH v4 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101209140410.26049.51539.stgit@dev.siriade.com>
References: <20101209140410.26049.51539.stgit@dev.siriade.com>
Message-ID: <20101209140416.26049.54282.stgit@dev.siriade.com>

These chips report CFI v3.3 [1], so patch them on the fly to the more
correct v1.3.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
[2] https://dev.openwrt.org/ticket/866

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
Acked-by: Wolfram Sang <w.sang at pengutronix.de>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index bf457a4..13cee2b 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -401,6 +401,14 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 
 			extp->MajorVersion = '1';
 		}
+		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
+			/*
+			 * Samsung K8D3x16UxC chips report major=3 / minor=3
+			 */
+			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 3.3 to 1.3\n");
+
+			extp->MajorVersion = '1';
+		}
 	}
 
 	/*



From w.sang at pengutronix.de  Thu Dec  9 09:30:25 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Thu, 9 Dec 2010 15:30:25 +0100
Subject: [PATCH v4 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
In-Reply-To: <20101209140410.26049.51539.stgit@dev.siriade.com>
References: <20101209140410.26049.51539.stgit@dev.siriade.com>
Message-ID: <20101209143025.GE3383@pengutronix.de>

On Thu, Dec 09, 2010 at 03:04:11PM +0100, Guillaume LECERF wrote:
> These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
> to patch all Samsung chips from 0.0 to 1.0.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
> [2] https://dev.openwrt.org/ticket/7348
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>

Acked-by: Wolfram Sang <w.sang at pengutronix.de>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101209/7be6812d/attachment.sig>

From john at stoffel.org  Thu Dec  9 10:05:47 2010
From: john at stoffel.org (John Stoffel)
Date: Thu, 9 Dec 2010 10:05:47 -0500
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on inode
	creation
In-Reply-To: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
Message-ID: <19712.61515.201226.938553@quad.stoffel.home>

>>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:

Eric> SELinux would like to implement a new labeling behavior of newly
Eric> created inodes.  We currently label new inodes based on the
Eric> parent and the creating process.  This new behavior would also
Eric> take into account the name of the new object when deciding the
Eric> new label.  This is not the (supposed) full path, just the last
Eric> component of the path.

Eric> This is very useful because creating /etc/shadow is different
Eric> than creating /etc/passwd but the kernel hooks are unable to
Eric> differentiate these operations.  We currently require that
Eric> userspace realize it is doing some difficult operation like that
Eric> and than userspace jumps through SELinux hoops to get things set
Eric> up correctly.  This patch does not implement new behavior, that
Eric> is obviously contained in a seperate SELinux patch, but it does
Eric> pass the needed name down to the correct LSM hook.  If no such
Eric> name exists it is fine to pass NULL.

I've looked this patch over, and maybe I'm missing something, but how
does knowing the name of the file really tell you anything, esp when
you only get the filename, not the path?  What threat are you
addressing with this change?  

So what happens when I create a file /home/john/shadow, does selinux
(or LSM in general) then run extra checks because the filename is
'shadow' in your model?  

I *think* the overhead shouldn't be there if SELINUX is disabled, but
have you confirmed this?  How you run performance tests before/after
this change when doing lots of creations of inodes to see what sort of
performance changes might be there?

Thanks,
John


From eparis at redhat.com  Thu Dec  9 10:52:21 2010
From: eparis at redhat.com (Eric Paris)
Date: Thu, 09 Dec 2010 10:52:21 -0500
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on
	inode creation
In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home>
References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
	<19712.61515.201226.938553@quad.stoffel.home>
Message-ID: <1291909941.3072.70.camel@localhost.localdomain>

On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:

> So what happens when I create a file /home/john/shadow, does selinux
> (or LSM in general) then run extra checks because the filename is
> 'shadow' in your model?  

It's entirely a question of labeling and one that was discussed on the
LSM list in some detail:

http://marc.info/?t=129141308200002&r=1&w=2

The basic synopsis is that when a new inode is created SELinux must
apply some label.  It makes the decision for what label to apply based
on 3 pieces of information.

The label of the parent inode.
The label of the process creating the new inode.
The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc

This patch adds a 4th piece of information, the name of the object being
created.  An obvious situation where this will be useful is devtmpfs
(although you'll find other examples in the above thread).  devtmpfs
when it creates char/block devices is unable to distinguish between kmem
and console and so they are created with a generic label.  hotplug/udev
is then called which does some pathname like matching and relabels them
to something more specific.  We've found that many people are able to
race against this particular updating and get spurious denials in /dev.
With this patch devtmpfs will be able to get the labels correct to begin
with.

I'm certainly willing to discuss the security implications of this
patch, but that would probably be best done with a significantly
shortened cc-list.  You'll see in the above mentioned thread that a
number of 'security' people (even those who are staunchly anti-SELinux)
recognize there is value in this and that it is certainly much better
than we have today.

> I *think* the overhead shouldn't be there if SELINUX is disabled, but
> have you confirmed this?  How you run performance tests before/after
> this change when doing lots of creations of inodes to see what sort of
> performance changes might be there?

I've actually recently done some perf testing on creating large numbers
of inodes using bonnie++, since SELinux was a noticeable overhead in
that operation.  Doing that same test with SELinux disabled (or enabled)
I do not see a noticeable difference when this patch is applied or not.
It's just an extra argument to a function that goes unused.

-Eric



From serge.hallyn at canonical.com  Thu Dec  9 11:05:49 2010
From: serge.hallyn at canonical.com (Serge Hallyn)
Date: Thu, 9 Dec 2010 10:05:49 -0600
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on
	inode creation
In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home>
References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
	<19712.61515.201226.938553@quad.stoffel.home>
Message-ID: <20101209160549.GA2315@peq>

Quoting John Stoffel (john at stoffel.org):
> >>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:
> 
> Eric> SELinux would like to implement a new labeling behavior of newly
> Eric> created inodes.  We currently label new inodes based on the
> Eric> parent and the creating process.  This new behavior would also
> Eric> take into account the name of the new object when deciding the
> Eric> new label.  This is not the (supposed) full path, just the last
> Eric> component of the path.
> 
> Eric> This is very useful because creating /etc/shadow is different
> Eric> than creating /etc/passwd but the kernel hooks are unable to
> Eric> differentiate these operations.  We currently require that
> Eric> userspace realize it is doing some difficult operation like that
> Eric> and than userspace jumps through SELinux hoops to get things set
> Eric> up correctly.  This patch does not implement new behavior, that
> Eric> is obviously contained in a seperate SELinux patch, but it does
> Eric> pass the needed name down to the correct LSM hook.  If no such
> Eric> name exists it is fine to pass NULL.
> 
> I've looked this patch over, and maybe I'm missing something, but how
> does knowing the name of the file really tell you anything, esp when
> you only get the filename, not the path?  What threat are you
> addressing with this change?  

Like you, I keep thinking back to this patch and going back and forth.
But to answer your question:  in some cases, the name of the file
(plus the context of the directory in which it is created) can tell
you what assumptions userspace will make about it.  And userspace most
definately is a part of the TCB, i.e. /bin/passwd and /bin/login.

-serge


From john at stoffel.org  Thu Dec  9 12:48:26 2010
From: john at stoffel.org (John Stoffel)
Date: Thu, 9 Dec 2010 12:48:26 -0500
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on
	inode creation
In-Reply-To: <1291909941.3072.70.camel@localhost.localdomain>
References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
	<19712.61515.201226.938553@quad.stoffel.home>
	<1291909941.3072.70.camel@localhost.localdomain>
Message-ID: <19713.5738.653711.301814@quad.stoffel.home>

>>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:

Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
>> >>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:

>> So what happens when I create a file /home/john/shadow, does selinux
>> (or LSM in general) then run extra checks because the filename is
>> 'shadow' in your model?  

Eric> It's entirely a question of labeling and one that was discussed on the
Eric> LSM list in some detail:

Eric> http://marc.info/?t=129141308200002&r=1&w=2

Thank you for pointing me at this discussion.  I'm working my way
through it, but so far I'm not seeing any consensus that this is
really the proper thing to do.  I personally feel this should be in
userspace if at all possible.

Eric> The basic synopsis is that when a new inode is created SELinux
Eric> must apply some label.  It makes the decision for what label to
Eric> apply based on 3 pieces of information.

Eric> The label of the parent inode.
Eric> The label of the process creating the new inode.
Eric> The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc

These seem to be ok, if you're using label based security.  But since
I freely admit I'm not an expert or even a user, I'm just trying to
understand and push back to make sure we do what's good.  And which
doesn't impact non-SElinux users.  

Eric> This patch adds a 4th piece of information, the name of the
Eric> object being created.  An obvious situation where this will be
Eric> useful is devtmpfs (although you'll find other examples in the
Eric> above thread).  devtmpfs when it creates char/block devices is
Eric> unable to distinguish between kmem and console and so they are
Eric> created with a generic label.  hotplug/udev is then called which
Eric> does some pathname like matching and relabels them to something
Eric> more specific.  We've found that many people are able to race
Eric> against this particular updating and get spurious denials in
Eric> /dev.  With this patch devtmpfs will be able to get the labels
Eric> correct to begin with.

So your Label based access controls are *also* based on pathnames?
Right?  

Eric> I'm certainly willing to discuss the security implications of this
Eric> patch, but that would probably be best done with a significantly
Eric> shortened cc-list.  You'll see in the above mentioned thread that a
Eric> number of 'security' people (even those who are staunchly anti-SELinux)
Eric> recognize there is value in this and that it is certainly much better
Eric> than we have today.

>> I *think* the overhead shouldn't be there if SELINUX is disabled, but
>> have you confirmed this?  How you run performance tests before/after
>> this change when doing lots of creations of inodes to see what sort of
>> performance changes might be there?

Eric> I've actually recently done some perf testing on creating large
Eric> numbers of inodes using bonnie++, since SELinux was a noticeable
Eric> overhead in that operation.  Doing that same test with SELinux
Eric> disabled (or enabled) I do not see a noticeable difference when
Eric> this patch is applied or not.  It's just an extra argument to a
Eric> function that goes unused.

That answers alot of my concerns then.  Not having it impact users in
a non-SELinux context is vitally important to me.

Thanks,
John


From eparis at redhat.com  Thu Dec  9 13:05:21 2010
From: eparis at redhat.com (Eric Paris)
Date: Thu, 09 Dec 2010 13:05:21 -0500
Subject: [PATCH] fs/vfs/security: pass last path component to LSM on
	inode creation
In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home>
References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com>
	<19712.61515.201226.938553@quad.stoffel.home>
	<1291909941.3072.70.camel@localhost.localdomain>
	<19713.5738.653711.301814@quad.stoffel.home>
Message-ID: <1291917921.12683.4.camel@localhost.localdomain>

On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:
> 
> Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
> >> >>>>> "Eric" == Eric Paris <eparis at redhat.com> writes:
> 
> Eric> This patch adds a 4th piece of information, the name of the
> Eric> object being created.  An obvious situation where this will be
> Eric> useful is devtmpfs (although you'll find other examples in the
> Eric> above thread).  devtmpfs when it creates char/block devices is
> Eric> unable to distinguish between kmem and console and so they are
> Eric> created with a generic label.  hotplug/udev is then called which
> Eric> does some pathname like matching and relabels them to something
> Eric> more specific.  We've found that many people are able to race
> Eric> against this particular updating and get spurious denials in
> Eric> /dev.  With this patch devtmpfs will be able to get the labels
> Eric> correct to begin with.
> 
> So your Label based access controls are *also* based on pathnames?
> Right?

Access decisions are still based solely on the label.  This patch can
influence how new objects get their label, which makes the access
decisions indirectly path based.  You'll find a reasonable summary and
commentary on lwn in this weeks security section.



From austin.cheng at martinlinkingbiz.com  Thu Dec  9 20:31:07 2010
From: austin.cheng at martinlinkingbiz.com (Austin Cheng)
Date: Fri, 10 Dec 2010 09:31:07 +0800
Subject: =?gb2312?B?U0NPUiBCZXN0IFByYWN0aWNlcyBmb3IgU3VwcGx5IENoYWluIFByb2Zlc3M=?=
	=?gb2312?B?aW9uYWxzKLmp06bBtNeo0rXIy8q/U0NPUiDX7rzRyrW8+SkqKkxhc3QgUmU=?=
	=?gb2312?B?bWluZGVyIHRvIFJlZ2lzdGVyLSA1IFNlYXRzIExlZnQqKg==?=
Message-ID: <006901cb9813$a297f7a0$e7c7e6e0$@cheng@martinlinkingbiz.com>

This is your last chance to register for SCOR Best Practices for Supply
Chain Professionals. We have only 5 seats left; therefore, do not miss this 

opportunity to register!

SCOR Best Practices for Supply Chain Professionals

6th & 7th January 2011 

Shanghai, China

Hello,

 

How are you? 

 

MARTIN LINKING is convening the SCOR Best Practices for Supply Chain
Professionals on 6th & 7th January 2011 in Shanghai. 

 

It is a two-day workshop to assist supply chain professionals in
implementing the SCOR(r) model best practices to achieve supply chain
excellence and become a best-in-class.

 

Course Description:

By enhancing collaboration and maximizing visibility throughout the
end-to-end supply chain, the SCOR (Supply Chain Operations Reference) model
supports companies in optimizing their supply chain performance.

Although the model has been developed by Supply-Chain Council (SCC) and
widely adopted by Fortune 500 Companies since 1996, it has only recently
reached the China market and local

enterprises in China are just at the learning stage.

With the supply chain affecting many aspects of the business, companies
cannot rely anymore on a 'ad-hoc', unorganized approach to supply chain
operational improvement. SCOR(r) helps manage a common set of business
problems through a standardized language, standardized metrics, benchmarking
and common business practices which accelerate business change and improve
performance.

Organizations which use SCOR enjoy consistent annual bottomline improvements
of 1-3%.

This training course will explore how to become a best-in-class through the
implementation of SCOR best practices.

 

What the Seminar Will Help You Achieve: 

?  How to measure your supply chain performance and compare it with your
competitors

?  How to identify inefficiency gaps and supply chain improvement
opportunities

?  How to map business processes

?  How to implement SCOR best practices

?  How to define a sustainable supply chain strategy

?  How to manage risk in your supply chain network

?  How to manage supply chain competencies, build required capabilities and
recruit skilled staff

?  How to implement the S&OP methodology

o    To forecast accurately your demand

o    To manage your business effectively and achieve competitive advantage
through inventory optimization, cash flow increase, return on working
capital  maximization?

o    To ensure all departments are aligned

o    To ensure your plans are measured accurately to enable continuous
improvement

?  How to make the link between supply chain management and financial
performance

 

Two days training fee is USD 1395.

 

Please find an agenda in both English and Chinese attached with this email
and feel free to contact me for more information.

 

To register the very limited seats, simply fill out the registration form,
attention it to Austin Cheng and fax it to + 86 28 8532 6768.

 

Austin Cheng 

____________________________

Martin Linking Business Consulting Company Limited.

 

T: +86 28 8532 7678

F: +86 28 8532 6768

Mob: +86 15828332755

 <http://www.martinlinking.com/> www.martinlinking.com

 

Upcoming Martin Linking events:

Title      :  Behavior Based Safety Best Practices

Date     :   9th&10th December, 2010

Location:  Shanghai, China

Link       :  http://www.martinlinking.com/documents/ws/bbs2_ws.pdf

 

Title      :   Effective Sales Strategies

Date     :   3rd&4th January 2011

Location:  Shanghai, China
Link      :   http://www.martinlinking.com/documents/ws/esaless_ws.pdf

 

Title      :  SCOR Best Practices for Supply Chain Professionals

Date     :   6th&7th January 2011

Location:  Shanghai, China
Link      :  http://www.martinlinking.com/documents/ws/scor_ws.pdf

 

Title      :  Strategic Purchasing & Supplier Management

Date     :  14th&15th March 2011

Location:  Shanghai, China
Link      :   http://www.martinlinking.com/documents/ws/spsm2011_ws.pdf

 

Title      :   Lean Production workshop

Date     :   21st&22nd March 2011

Location:  Shanghai, China
Link      :   http://www.martinlinking.com/documents/ws/leanp2011_ws.pdf

 

Title      :  Plant Safety Management Best Practices

Date     :  24th&25th March, 2011

Location: Shanghai, China
Link      :  http://www.martinlinking.com/documents/ws/psafetym_ws.pdf

 

Title      :  Equipment Maintenance Management and Production Cost Control

Date     :  25th&26th April, 2011

Location:  Shanghai, China
Link      :  http://www.martinlinking.com/documents/ws/emm2011_ws.pdf

 

Title      :   Operational and Financial Performance Optimization Best
Practices

Date     :   23rd&24th May 2011

Location:  Shanghai, China

Link      :   http://www.martinlinking.com/documents/ws/ofpo_ws.pdf

 

Title      :   Lean Inventory and Warehouse Management

Date     :   26th&27th May 2011

Location:  Shanghai, China

Link      :
http://www.martinlinking.com/documents/ws/leaninventory2011_ws.pdf

 

Title      :  Logistics Management Best Practices

Date     :  16th&17th June 2011

Location:  Shanghai, China
Link      :   http://www.martinlinking.com/documents/ws/logisticsm_ws.pdf

 

If you no longer wish to receive further marketing e-mails, please reply
this email with the email address to be unsubscribed.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101210/0bd1e4fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCOR Best Practices for Supply Chain Professionals.pdf
Type: application/pdf
Size: 354445 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101210/0bd1e4fc/attachment-0001.pdf>

From tarosa.y at gmail.com  Fri Dec 10 12:34:55 2010
From: tarosa.y at gmail.com (Tarosa)
Date: Sat, 11 Dec 2010 02:34:55 +0900
Subject: Please teach UBI
Message-ID: <4D0264BF.6060904@gmail.com>

Hello.

Because I do not usually use English, unknown sentences might be written.

It is a basic question.
UBI is an array of the initial of "Unsorted block images". Please teach the
meaning of this "Unsorted block images".
Was there a filesystem of "Sorted block images" in the past?
What after the filesystem is different as for not sorting block images?
Where of UBI is unsorted block images?
I do not understand. Please tell me.

There are another and a question.
It is defined that CONFIG_MTD_UBI_WL_THRESHOLD is 4096. It is thought this is to
mean WL is done as difference between a maximum  and a minimum  of the value of
erace counter of PEBs are always in the range of 4096*2(=8192).

Why is it 8192 ?
In a value that is bigger than 8192, isn't it good? Or, isn't it good in a
narrower range?
Isn't there what changed by the character of mtd?
Please teach to me.

My best regards.

-- 
tarosa yamamoto
E-Mail: tarosa.y at gmail.com


From gnusercn at gmail.com  Sat Dec 11 08:22:50 2010
From: gnusercn at gmail.com (os user)
Date: Sat, 11 Dec 2010 21:22:50 +0800
Subject: About MTD Testing suite included in the Linux kernel.
Message-ID: <AANLkTi=-L0DuQziSkzzock8LOJEDY2z37t2bLWQQ_YXG@mail.gmail.com>

Hi,

When I work on MTD testing tool (drivers/mtd/tests) included in the
Linux kernel, I found a problem.
For mtd_oobtest, I failed at the testing '4 of 5'. This testing case
will test 'reading past the device'.

Since for my Nandflash controller, no special function is provided for
reading OOB, I looked into the standard implementation 'nand_do_read_oob'.
The logic below seems a little bit confusing for me,

/* Do not allow reads past end of device */
       if (unlikely(from >= mtd->size ||
                    ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
                                       (from >> chip->page_shift)) * len)) {
               DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt read beyond end "
                                       "of device\n", __func__);
               return -EINVAL;
       }


In mtd_oobtest program, the testing code looks like,

/* Attempt to read off end of device */
               ops.mode      = MTD_OOB_AUTO;
               ops.len       = 0;
               ops.retlen    = 0;
               ops.ooblen    = mtd->ecclayout->oobavail + 1;
               ops.oobretlen = 0;
               ops.ooboffs   = 0;
               ops.datbuf    = NULL;
               ops.oobbuf    = readbuf;
               printk(PRINT_PREF "attempting to read past end of device\n");
               printk(PRINT_PREF "an error is expected...\n");
               err = mtd->read_oob(mtd, mtd->size - mtd->writesize, &ops);
               if (err) {
                       printk(PRINT_PREF "error occurred as expected\n");
                       err = 0;
               } else {
                       printk(PRINT_PREF "error: read past end of device\n");
                       errcnt += 1;
               }

It seems, according to the logic in MTD testing suite, MTD should
return an error. But I do not observed any error reported.

Could anyone please have a look at the two code pieces and tell me which
side needs a modification?

Thanks.

BR


From tj at kernel.org  Sat Dec 11 11:51:44 2010
From: tj at kernel.org (Tejun Heo)
Date: Sat, 11 Dec 2010 17:51:44 +0100
Subject: [PATCH 27/30] mtd: don't use flush_scheduled_work()
In-Reply-To: <1292086307-19211-1-git-send-email-tj@kernel.org>
References: <1292086307-19211-1-git-send-email-tj@kernel.org>
Message-ID: <1292086307-19211-28-git-send-email-tj@kernel.org>

flush_scheduled_work() is deprecated and scheduled to be removed.
Directly flush cxt->work_{erase|write} on removal instead.

Signed-off-by: Tejun Heo <tj at kernel.org>
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: linux-mtd at lists.infradead.org
---
This is part of a series to remove flush_scheduled_work() usage to
prepare for deprecation of flush_scheduled_work().  Patches in this
series are self contained and mostly straight-forward.

Please feel free to take it into the appropriate tree, or just ack it.
In the latter case, I'll merge the patch through the workqueue tree
during the next merge window.

If you're seeing this patch for the second time, it's because the
commit hasn't showed up in mainline yet.  Please let me know what
should be done.

Thank you.

 drivers/mtd/mtdoops.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 1ee72f3..8b10273 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
@@ -396,7 +396,8 @@ static void mtdoops_notify_remove(struct mtd_info *mtd)
 		printk(KERN_WARNING "mtdoops: could not unregister kmsg_dumper\n");
 
 	cxt->mtd = NULL;
-	flush_scheduled_work();
+	flush_work_sync(&cxt->work_erase);
+	flush_work_sync(&cxt->work_write);
 }
 
 
-- 
1.7.1



From jkrzyszt at tis.icnet.pl  Sat Dec 11 12:40:02 2010
From: jkrzyszt at tis.icnet.pl (Janusz Krzysztofik)
Date: Sat, 11 Dec 2010 18:40:02 +0100
Subject: [PATCH] MTD: NAND: ams-delta: convert to platform driver
Message-ID: <201012111840.05270.jkrzyszt@tis.icnet.pl>

In its current form, the driver may break unrelated machines if built into the 
kernel, hence is not suitable for inclusion into a kernel built for multiple 
OMAP1 machines. Convert it to a platform driver, that should be free from that 
issue.

While being at it, get rid of depreciated omap_read/write(), use ioremap() 
instead.

Created and tested against linux-2.6.37-rc5 on Amstrad Delta.

Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
---

 arch/arm/mach-omap1/board-ams-delta.c |    6 +
 drivers/mtd/nand/Kconfig              |    1
 drivers/mtd/nand/ams-delta.c          |  107 ++++++++++++++++++++++++++--------
 3 files changed, 90 insertions(+), 24 deletions(-)

--- linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c.orig	2010-12-09 23:08:16.000000000 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c	2010-12-11 17:47:21.000000000 +0100
@@ -4,6 +4,7 @@
  *  Copyright (C) 2006 Jonathan McDowell <noodles at earth.li>
  *
  *  Derived from drivers/mtd/toto.c
+ *  Converted to platform driver by Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
  *
  * 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
@@ -62,9 +63,10 @@ static struct mtd_partition partition_in
 static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
 {
 	struct nand_chip *this = mtd->priv;
+	void __iomem *io_base = this->priv;
 
-	omap_writew(0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
-	omap_writew(byte, this->IO_ADDR_W);
+	writew(0, io_base + OMAP_MPUIO_IO_CNTL);
+	writew(byte, this->IO_ADDR_W);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
 	ndelay(40);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
@@ -75,11 +77,12 @@ static u_char ams_delta_read_byte(struct
 {
 	u_char res;
 	struct nand_chip *this = mtd->priv;
+	void __iomem *io_base = this->priv;
 
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE, 0);
 	ndelay(40);
-	omap_writew(~0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
-	res = omap_readw(this->IO_ADDR_R);
+	writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
+	res = readw(this->IO_ADDR_R);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE,
 			       AMS_DELTA_LATCH2_NAND_NRE);
 
@@ -148,21 +151,27 @@ static int ams_delta_nand_ready(struct m
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
+static struct resource ams_delta_nand_resource __initdata = {
+	.start		= OMAP1_MPUIO_BASE,
+	.end		= OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL,
+};
+
 /*
  * Main initialization routine
  */
-static int __init ams_delta_init(void)
+static int __devinit ams_delta_init(struct platform_device *pdev)
 {
 	struct nand_chip *this;
+	struct resource *res = &ams_delta_nand_resource;
+	void __iomem *io_base;
 	int err = 0;
 
 	/* Allocate memory for MTD device structure and private data */
-	ams_delta_mtd = kmalloc(sizeof(struct mtd_info) +
+	ams_delta_mtd = kzalloc(sizeof(struct mtd_info) +
 				sizeof(struct nand_chip), GFP_KERNEL);
 	if (!ams_delta_mtd) {
-		printk (KERN_WARNING "Unable to allocate E3 NAND MTD device structure.\n");
-		err = -ENOMEM;
-		goto out;
+		dev_err(&pdev->dev, "unable to allocate device structure.\n");
+		return -ENOMEM;
 	}
 
 	ams_delta_mtd->owner = THIS_MODULE;
@@ -170,16 +179,29 @@ static int __init ams_delta_init(void)
 	/* Get pointer to private data */
 	this = (struct nand_chip *) (&ams_delta_mtd[1]);
 
-	/* Initialize structures */
-	memset(ams_delta_mtd, 0, sizeof(struct mtd_info));
-	memset(this, 0, sizeof(struct nand_chip));
-
 	/* Link the private data with the MTD structure */
 	ams_delta_mtd->priv = this;
 
+	if (!request_mem_region(res->start, resource_size(res),
+			dev_name(&pdev->dev))) {
+		dev_err(&pdev->dev, "request_mem_region failed\n");
+		err = -EBUSY;
+		goto out_free;
+	}
+
+	io_base = ioremap(res->start, resource_size(res));
+	if (io_base == NULL) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		err = -EIO;
+		goto out_release_io;
+	}
+
+	this->priv = io_base;
+	ams_delta_mtd->name = dev_name(&pdev->dev);
+
 	/* Set address of NAND IO lines */
-	this->IO_ADDR_R = (OMAP1_MPUIO_BASE + OMAP_MPUIO_INPUT_LATCH);
-	this->IO_ADDR_W = (OMAP1_MPUIO_BASE + OMAP_MPUIO_OUTPUT);
+	this->IO_ADDR_R = io_base + OMAP_MPUIO_INPUT_LATCH;
+	this->IO_ADDR_W = io_base + OMAP_MPUIO_OUTPUT;
 	this->read_byte = ams_delta_read_byte;
 	this->write_buf = ams_delta_write_buf;
 	this->read_buf = ams_delta_read_buf;
@@ -189,7 +211,7 @@ static int __init ams_delta_init(void)
 		this->dev_ready = ams_delta_nand_ready;
 	} else {
 		this->dev_ready = NULL;
-		printk(KERN_NOTICE "Couldn't request gpio for Delta NAND ready.\n");
+		dev_notice(&pdev->dev, "couldn't request NAND ready GPIO.\n");
 	}
 	/* 25 us command delay time */
 	this->chip_delay = 30;
@@ -204,35 +226,72 @@ static int __init ams_delta_init(void)
 	/* Scan to find existance of the device */
 	if (nand_scan(ams_delta_mtd, 1)) {
 		err = -ENXIO;
-		goto out_mtd;
+		goto out;
 	}
 
+#ifdef CONFIG_MTD_PARTITIONS
 	/* Register the partitions */
 	add_mtd_partitions(ams_delta_mtd, partition_info,
 			   ARRAY_SIZE(partition_info));
+#endif
+	err = add_mtd_device(ams_delta_mtd);
 
-	goto out;
+	if (!err)
+		return err;
 
- out_mtd:
+	nand_release(ams_delta_mtd);
+out:
+	ams_delta_latch2_write(NAND_MASK, 0);
+	iounmap(io_base);
+out_release_io:
+	release_mem_region(res->start, resource_size(res));
+out_free:
 	kfree(ams_delta_mtd);
- out:
 	return err;
 }
 
-module_init(ams_delta_init);
-
 /*
  * Clean up routine
  */
-static void __exit ams_delta_cleanup(void)
+static int __devexit ams_delta_cleanup(struct platform_device *pdev)
 {
+	struct nand_chip *chip = ams_delta_mtd->priv;
+	void __iomem *io_base = chip->priv;
+	struct resource *res = &ams_delta_nand_resource;
+
 	/* Release resources, unregister device */
 	nand_release(ams_delta_mtd);
 
+	ams_delta_latch2_write(NAND_MASK, 0);
+	iounmap(io_base);
+	release_mem_region(res->start, resource_size(res));
+
 	/* Free the MTD device structure */
 	kfree(ams_delta_mtd);
+
+	return 0;
+}
+
+static struct platform_driver ams_delta_nand_driver = {
+	.probe		= ams_delta_init,
+	.remove		= __devexit_p(ams_delta_cleanup),
+	.driver		= {
+		.name	= "ams-delta-nand",
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init ams_delta_nand_init(void)
+{
+	return platform_driver_register(&ams_delta_nand_driver);
+}
+module_init(ams_delta_nand_init);
+
+static void __exit ams_delta_nand_exit(void)
+{
+	platform_driver_unregister(&ams_delta_nand_driver);
 }
-module_exit(ams_delta_cleanup);
+module_exit(ams_delta_nand_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Jonathan McDowell <noodles at earth.li>");
--- linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig	2010-12-09 23:13:04.000000000 +0100
+++ linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c	2010-12-11 16:23:51.000000000 +0100
@@ -181,6 +181,11 @@ static struct omap_board_config_kernel a
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
+static struct platform_device ams_delta_nand_device = {
+	.name	= "ams-delta-nand",
+	.id	= -1
+};
+
 static struct resource ams_delta_kp_resources[] = {
 	[0] = {
 		.start	= INT_KEYBOARD,
@@ -273,6 +278,7 @@ void __init amsdelta_reserve(void)
 }
 
 static struct platform_device *ams_delta_devices[] __initdata = {
+	&ams_delta_nand_device,
 	&ams_delta_kp_device,
 	&ams_delta_lcd_device,
 	&ams_delta_led_device,
--- linux-2.6.37-rc5/drivers/mtd/nand/Kconfig.orig	2010-12-09 23:08:16.000000000 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/Kconfig	2010-12-11 15:58:12.000000000 +0100
@@ -96,6 +96,7 @@ config MTD_NAND_SPIA
 config MTD_NAND_AMS_DELTA
 	tristate "NAND Flash device on Amstrad E3"
 	depends on MACH_AMS_DELTA
+	default y
 	help
 	  Support for NAND flash on Amstrad E3 (Delta).
 


From little-nae at sbcglobal.net  Sat Dec 11 16:50:45 2010
From: little-nae at sbcglobal.net (little-nae at sbcglobal.net)
Date: Sat, 11 Dec 2010 13:50:45 -0800 (PST)
Subject: End Of Year winner
Message-ID: <859221.44259.qm@web82108.mail.mud.yahoo.com>


Name:> Occupation:> Tell:> Sex:> Country:


From computersforpeace at gmail.com  Sun Dec 12 03:23:32 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Sun, 12 Dec 2010 00:23:32 -0800
Subject: [PATCH 1/2] mtd: nand: choose correct chip name (ONFI bug)
Message-ID: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>

We have the order of the conditional wrong for choosing the ONFI chip name
vs. the ID table name. Without this fix, we will almost *always* choose a
NULL string to print out instead of the correct one.

This has already been suggested by Matthieu Castet.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 drivers/mtd/nand/nand_base.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 33550c4..38b5eb0 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3164,7 +3164,7 @@ ident_done:
 	printk(KERN_INFO "NAND device: Manufacturer ID:"
 		" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, *dev_id,
 		nand_manuf_ids[maf_idx].name,
-	chip->onfi_version ? type->name : chip->onfi_params.model);
+		chip->onfi_version ? chip->onfi_params.model : type->name);
 
 	return type;
 }
-- 
1.7.0.4




From computersforpeace at gmail.com  Sun Dec 12 03:23:33 2010
From: computersforpeace at gmail.com (Brian Norris)
Date: Sun, 12 Dec 2010 00:23:33 -0800
Subject: [PATCH 2/2] mtd: nand: rearrange ONFI revision checking, add ONFI 2.3
In-Reply-To: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
References: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
Message-ID: <1292142213-645-2-git-send-email-computersforpeace@gmail.com>

In checking for the ONFI revision, the first conditional (for checking
"unsupported" ONFI) seems unnecessary.  All ONFI revisions should be
backwards-compatible; even if this is not the case on some newer ONFI
revision, it should simply fail the second version-checking if-else block
(i.e., the bit-fields for 1.0, 2.0, etc. would not be set to 1). Thus, we
move our "unsupported" condition after having checked each bit field.

Also, it's simple enough to add a condition for ONFI revision 2.3. Note
that this does *NOT* mean we handle all new features of ONFI versions
above 1.0.

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 drivers/mtd/nand/nand_base.c |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 38b5eb0..2237a87 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2872,20 +2872,24 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
 
 	/* check version */
 	val = le16_to_cpu(p->revision);
-	if (val == 1 || val > (1 << 4)) {
-		printk(KERN_INFO "%s: unsupported ONFI version: %d\n",
-								__func__, val);
-		return 0;
-	}
-
-	if (val & (1 << 4))
+	if (val & (1 << 5))
+		chip->onfi_version = 23;
+	else if (val & (1 << 4))
 		chip->onfi_version = 22;
 	else if (val & (1 << 3))
 		chip->onfi_version = 21;
 	else if (val & (1 << 2))
 		chip->onfi_version = 20;
-	else
+	else if (val & (1 << 1))
 		chip->onfi_version = 10;
+	else
+		chip->onfi_version = 0;
+
+	if (!chip->onfi_version) {
+		printk(KERN_INFO "%s: unsupported ONFI version: %d\n",
+								__func__, val);
+		return 0;
+	}
 
 	sanitize_string(p->manufacturer, sizeof(p->manufacturer));
 	sanitize_string(p->model, sizeof(p->model));
-- 
1.7.0.4




From katharine_b at net.hr  Sun Dec 12 19:06:40 2010
From: katharine_b at net.hr (Katharine Bernard)
Date: Mon, 13 Dec 2010 01:06:40 +0100
Subject: GWI SYMPOSIUM INVITATION
Message-ID: <1292198800.215578.3797.nullmailer@mail1011.cent>


Dear Sir/Madam,

It gives me a great pleasure to invite you to the forth coming international seminar which the Global Watch Institution is exited to be hosting in January 24th to 29th 2011 at Webster hall New York City  USA, and from January 31st to February 4th 2011 at Euskalduna Conference Centre and Concert Hall Madrid Spain.

The theme of the forth coming seminar are; Racism and Human Right. Delegates who are interested to make a paper presentation are advice to make a summary presentation on the above subject.

Note: the G.W.I will be providing all delegates with to and fro Air ticket and also visa?s guidance for the seminar purpose. Looking forward for your cooperation and support for the success of the workshop.

Registration is open now! Contact the organizing secretary Mrs. Angela C. Derick for more information.

Email: event_secretary_gwi at globomail.com

Regards

Miss Katharine Bernard

katharine_bernard at globomail.com


From adrian.hunter at nokia.com  Mon Dec 13 07:12:36 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:36 +0200
Subject: [PATCH 6/7] OMAP2/3: OneNAND: add platform data callback for PM
	constraints
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121236.20650.75186.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 05:56:24 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 12:56:24 +0200
Subject: [PATCH 6/7] OMAP2/3: OneNAND: add platform data callback for PM constraints
Message-ID: <mailman.46.1292242375.1530.linux-mtd@lists.infradead.org>

Make it possible for boards to set PM constraints such as maximum wakeup
latency.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/plat-omap/include/plat/onenand.h |    8 ++++++++
 drivers/mtd/onenand/omap2.c               |   16 +++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/onenand.h b/arch/arm/plat-omap/include/plat/onenand.h
index affe87e..1d07119 100644
--- a/arch/arm/plat-omap/include/plat/onenand.h
+++ b/arch/arm/plat-omap/include/plat/onenand.h
@@ -15,12 +15,20 @@
 #define ONENAND_SYNC_READ	(1 << 0)
 #define ONENAND_SYNC_READWRITE	(1 << 1)
 
+enum {
+	ONENAND_PM_CONSTRAINT_OFF,
+	ONENAND_PM_CONSTRAINT_ERASING,
+	ONENAND_PM_CONSTRAINT_OTHER,
+};
+
 struct omap_onenand_platform_data {
 	int			cs;
 	int			gpio_irq;
 	struct mtd_partition	*parts;
 	int			nr_parts;
 	int                     (*onenand_setup)(void __iomem *, int freq);
+	void			(*set_pm_constraints)(struct device *dev,
+						      int on);
 	int			dma_channel;
 	u8			flags;
 	u8			regulator_can_sleep;
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index ac31f46..866b9f9 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -64,6 +64,7 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int freq);
+	void (*set_pm_constraints)(struct device *dev, int on);
 	struct regulator *regulator;
 };
 
@@ -605,13 +606,21 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 
 static int omap2_onenand_enable(struct mtd_info *mtd)
 {
-	int ret;
+	int ret, on;
 	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
 
 	ret = regulator_enable(c->regulator);
 	if (ret != 0)
 		dev_err(&c->pdev->dev, "cant enable regulator\n");
 
+	if (c->set_pm_constraints) {
+		if (c->onenand.state == FL_ERASING)
+			on = ONENAND_PM_CONSTRAINT_ERASING;
+		else
+			on = ONENAND_PM_CONSTRAINT_OTHER;
+		c->set_pm_constraints(&c->pdev->dev, on);
+	}
+
 	return ret;
 }
 
@@ -620,6 +629,9 @@ static int omap2_onenand_disable(struct mtd_info *mtd)
 	int ret;
 	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
 
+	if (c->set_pm_constraints)
+		c->set_pm_constraints(&c->pdev->dev, ONENAND_PM_CONSTRAINT_OFF);
+
 	ret = regulator_disable(c->regulator);
 	if (ret != 0)
 		dev_err(&c->pdev->dev, "cant disable regulator\n");
@@ -682,6 +694,8 @@ static int __devinit omap2_onenand_probe(struct platform_device *pdev)
 		c->setup = pdata->onenand_setup;
 	}
 
+	c->set_pm_constraints = pdata->set_pm_constraints;
+
 	if (c->gpio_irq) {
 		if ((r = gpio_request(c->gpio_irq, "OneNAND irq")) < 0) {
 			dev_err(&pdev->dev,  "Failed to request GPIO%d for "
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:12:17 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:17 +0200
Subject: [PATCH 3/7] mtd: OneNAND: OMAP2/3: prevent regulator sleeping while
	OneNAND is in use
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121217.20650.88237.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:12:30 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:30 +0200
Subject: [PATCH 5/7] OMAP2/3: OneNAND: add 104MHz support
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121230.20650.33730.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 04:22:50 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 11:22:50 +0200
Subject: [PATCH 5/7] OMAP2/3: OneNAND: add 104MHz support
Message-ID: <mailman.48.1292242380.1530.linux-mtd@lists.infradead.org>

Add GPMC timings for 104MHz OneNAND.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c |    9 +++++++++
 drivers/mtd/onenand/omap2.c        |    3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 1db606c..3a7d25f 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -173,6 +173,15 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 	}
 
 	switch (freq) {
+	case 104:
+		min_gpmc_clk_period = 9600; /* 104 MHz */
+		t_ces   = 3;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 3;
+		t_aavdh = 6;
+		t_rdyo  = 9;
+		break;
 	case 83:
 		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 1a07bfc..ac31f46 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -767,6 +767,9 @@ static int __devinit omap2_onenand_probe(struct platform_device *pdev)
 	case 3:
 		c->freq = 83;
 		break;
+	case 4:
+		c->freq = 104;
+		break;
 	}
 
 #ifdef CONFIG_MTD_PARTITIONS
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:12:24 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:24 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead
	of nanoseconds
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121224.20650.11839.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 03:48:27 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 10:48:27 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
Message-ID: <mailman.49.1292242381.1530.linux-mtd@lists.infradead.org>

The calculations done with sync_clk are anyway in picoseconds
and switching to picoseconds allows sync_clk values that are
not a whole number of nanoseconds - which is sometimes the
case.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c     |   10 +++++-----
 arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
 arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
 arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
 5 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 7222096..2bb29c1 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -41,7 +41,7 @@ static int omap2_nand_gpmc_retime(void)
 		return 0;
 
 	memset(&t, 0, sizeof(t));
-	t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
+	t.sync_clk = gpmc_nand_data->gpmc_t->sync_clk;
 	t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_on);
 	t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->adv_on);
 
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 7bb6922..1db606c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -174,7 +174,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 
 	switch (freq) {
 	case 83:
-		min_gpmc_clk_period = 12; /* 83 MHz */
+		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
 		t_avds  = 4;
 		t_avdh  = 2;
@@ -183,7 +183,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 9;
 		break;
 	case 66:
-		min_gpmc_clk_period = 15; /* 66 MHz */
+		min_gpmc_clk_period = 15000; /* 66 MHz */
 		t_ces   = 6;
 		t_avds  = 5;
 		t_avdh  = 2;
@@ -192,7 +192,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 11;
 		break;
 	default:
-		min_gpmc_clk_period = 18; /* 54 MHz */
+		min_gpmc_clk_period = 18500; /* 54 MHz */
 		t_ces   = 7;
 		t_avds  = 7;
 		t_avdh  = 7;
@@ -271,8 +271,8 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t.wr_cycle  = t.rd_cycle;
 		if (cpu_is_omap34xx()) {
 			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ns_to_ticks(min_gpmc_clk_period +
-					t_rdyo));
+					gpmc_ps_to_ticks(min_gpmc_clk_period +
+					t_rdyo * 1000));
 			t.wr_access = t.access;
 		}
 	} else {
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..1b7b3e7 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -168,6 +168,16 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
 	return (time_ns * 1000 + tick_ps - 1) / tick_ps;
 }
 
+unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long tick_ps;
+
+	/* Calculate in picosecs to yield more exact results */
+	tick_ps = gpmc_get_fclk_period();
+
+	return (time_ps + tick_ps - 1) / tick_ps;
+}
+
 unsigned int gpmc_ticks_to_ns(unsigned int ticks)
 {
 	return ticks * gpmc_get_fclk_period() / 1000;
@@ -235,7 +245,7 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
 	int div;
 	u32 l;
 
-	l = sync_clk * 1000 + (gpmc_get_fclk_period() - 1);
+	l = sync_clk + (gpmc_get_fclk_period() - 1);
 	div = l / gpmc_get_fclk_period();
 	if (div > 4)
 		return -1;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 64a0112..1e998ea 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -120,8 +120,8 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
 	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
 
 	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 12 /* 11.1 nsec */;
-	tmp = (t.sync_clk * 1000 + fclk_ps - 1) / fclk_ps;
+	t.sync_clk = 11100 /* 11.1 nsec */;
+	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
 	if (tmp > 4)
 		return -ERANGE;
 	if (tmp <= 0)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..85ded59 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -80,12 +80,12 @@
 #define GPMC_PREFETCH_STATUS_COUNT(val)	(val & 0x00003fff)
 
 /*
- * Note that all values in this struct are in nanoseconds, while
- * the register values are in gpmc_fck cycles.
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
  */
 struct gpmc_timings {
-	/* Minimum clock period for synchronous mode */
-	u16 sync_clk;
+	/* Minimum clock period for synchronous mode (in picoseconds) */
+	u32 sync_clk;
 
 	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
 	u16 cs_on;		/* Assertion time */
@@ -117,6 +117,7 @@ struct gpmc_timings {
 };
 
 extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
+extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
 extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
 extern unsigned long gpmc_get_fclk_period(void);
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:12:00 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:00 +0200
Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command line
	partitioning
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121200.20650.72634.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:12:08 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:08 +0200
Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to onenand_chip
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121208.20650.32767.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:12:44 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:12:44 +0200
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
In-Reply-To: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213121244.20650.78191.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Fri Dec 10 05:04:20 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Fri, 10 Dec 2010 12:04:20 +0200
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
Message-ID: <mailman.52.1292242392.1530.linux-mtd@lists.infradead.org>

Initial bad blocks are normal but the messages look like
errors.  Make the messages less scary, make the main
message an informational message not a warning, make the
message displaying registers a debug message and include
the address there instead of in the informational message.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 drivers/mtd/onenand/onenand_base.c |   22 ++++++++++++----------
 drivers/mtd/onenand/onenand_bbt.c  |    4 ++--
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index bde274f..5065fc7 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1488,8 +1488,7 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
 {
 	struct onenand_chip *this = mtd->priv;
 	unsigned long timeout;
-	unsigned int interrupt;
-	unsigned int ctrl;
+	unsigned int interrupt, ctrl, ecc, addr1, addr8;
 
 	/* The 20 msec is enough */
 	timeout = jiffies + msecs_to_jiffies(20);
@@ -1501,25 +1500,28 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
 	/* To get correct interrupt status in timeout case */
 	interrupt = this->read_word(this->base + ONENAND_REG_INTERRUPT);
 	ctrl = this->read_word(this->base + ONENAND_REG_CTRL_STATUS);
+	addr1 = this->read_word(this->base + ONENAND_REG_START_ADDRESS1);
+	addr8 = this->read_word(this->base + ONENAND_REG_START_ADDRESS8);
 
 	if (interrupt & ONENAND_INT_READ) {
-		int ecc = onenand_read_ecc(this);
+		ecc = onenand_read_ecc(this);
 		if (ecc & ONENAND_ECC_2BIT_ALL) {
-			printk(KERN_WARNING "%s: ecc error = 0x%04x, "
-				"controller error 0x%04x\n",
-				__func__, ecc, ctrl);
+			printk(KERN_DEBUG "%s: ecc 0x%04x ctrl 0x%04x "
+			       "intr 0x%04x addr1 %#x addr8 %#x\n",
+			       __func__, ecc, ctrl, interrupt, addr1, addr8);
 			return ONENAND_BBT_READ_ECC_ERROR;
 		}
 	} else {
-		printk(KERN_ERR "%s: read timeout! ctrl=0x%04x intr=0x%04x\n",
-			__func__, ctrl, interrupt);
+		printk(KERN_ERR "%s: read timeout! ctrl 0x%04x "
+		       "intr 0x%04x addr1 %#x addr8 %#x\n",
+		       __func__, ctrl, interrupt, addr1, addr8);
 		return ONENAND_BBT_READ_FATAL_ERROR;
 	}
 
 	/* Initial bad block case: 0x2400 or 0x0400 */
 	if (ctrl & ONENAND_CTRL_ERROR) {
-		printk(KERN_DEBUG "%s: controller error = 0x%04x\n",
-			__func__, ctrl);
+		printk(KERN_DEBUG "%s: ctrl 0x%04x intr 0x%04x addr1 %#x "
+		       "addr8 %#x\n", __func__, ctrl, interrupt, addr1, addr8);
 		return ONENAND_BBT_READ_ERROR;
 	}
 
diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
index 905209b..fc2c16a 100644
--- a/drivers/mtd/onenand/onenand_bbt.c
+++ b/drivers/mtd/onenand/onenand_bbt.c
@@ -101,8 +101,8 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
 			if (ret || check_short_pattern(&buf[j * scanlen],
 					       scanlen, this->writesize, bd)) {
 				bbm->bbt[i >> 3] |= 0x03 << (i & 0x6);
-				printk(KERN_WARNING "Bad eraseblock %d at 0x%08x\n",
-					i >> 1, (unsigned int) from);
+				printk(KERN_INFO "OneNAND eraseblock %d is an "
+					"initial bad block\n", i >> 1);
 				mtd->ecc_stats.badblocks++;
 				break;
 			}
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:11:44 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:11:44 +0200
Subject: [PATCH 0/7] OneNAND OMAP patches
Message-ID: <20101213121144.20650.27903.sendpatchset@ahunter-work.research.nokia.com>

Hi

Here are some OneNAND and related OMAP patches.

Adrian Hunter (7):
      mtd: OneNAND: OMAP2/3: add support for command line partitioning
      mtd: OneNAND: add enable / disable methods to onenand_chip
      mtd: OneNAND: OMAP2/3: prevent regulator sleeping while OneNAND is in use
      OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
      OMAP2/3: OneNAND: add 104MHz support
      OMAP2/3: OneNAND: add platform data callback for PM constraints
      mtd: OneNAND: lighten scary initial bad block messages

 arch/arm/mach-omap2/gpmc-nand.c           |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c        |   19 +++++--
 arch/arm/mach-omap2/gpmc.c                |   12 ++++-
 arch/arm/mach-omap2/usb-tusb6010.c        |    4 +-
 arch/arm/plat-omap/include/plat/gpmc.h    |    9 ++--
 arch/arm/plat-omap/include/plat/onenand.h |    9 +++
 drivers/mtd/onenand/omap2.c               |   85 +++++++++++++++++++++++------
 drivers/mtd/onenand/onenand_base.c        |   26 ++++++----
 drivers/mtd/onenand/onenand_bbt.c         |    4 +-
 include/linux/mtd/onenand.h               |    2 +
 10 files changed, 131 insertions(+), 41 deletions(-) 
 
Regards
Adrian



From adrian.hunter at nokia.com  Mon Dec 13 07:20:42 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:20:42 +0200
Subject: [PATCH 0/7] OneNAND OMAP patches (resent)
Message-ID: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>

Hi

(resent with corrected email for Artem)

Here are some OneNAND and related OMAP patches.

Adrian Hunter (7):
      mtd: OneNAND: OMAP2/3: add support for command line partitioning
      mtd: OneNAND: add enable / disable methods to onenand_chip
      mtd: OneNAND: OMAP2/3: prevent regulator sleeping while OneNAND is in use
      OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
      OMAP2/3: OneNAND: add 104MHz support
      OMAP2/3: OneNAND: add platform data callback for PM constraints
      mtd: OneNAND: lighten scary initial bad block messages

 arch/arm/mach-omap2/gpmc-nand.c           |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c        |   19 +++++--
 arch/arm/mach-omap2/gpmc.c                |   12 ++++-
 arch/arm/mach-omap2/usb-tusb6010.c        |    4 +-
 arch/arm/plat-omap/include/plat/gpmc.h    |    9 ++--
 arch/arm/plat-omap/include/plat/onenand.h |    9 +++
 drivers/mtd/onenand/omap2.c               |   85 +++++++++++++++++++++++------
 drivers/mtd/onenand/onenand_base.c        |   26 ++++++----
 drivers/mtd/onenand/onenand_bbt.c         |    4 +-
 include/linux/mtd/onenand.h               |    2 +
 10 files changed, 131 insertions(+), 41 deletions(-) 
 
Regards
Adrian



From adrian.hunter at nokia.com  Mon Dec 13 07:21:08 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:21:08 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead
	of nanoseconds
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 03:48:27 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 10:48:27 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
Message-ID: <mailman.53.1292242886.1530.linux-mtd@lists.infradead.org>

The calculations done with sync_clk are anyway in picoseconds
and switching to picoseconds allows sync_clk values that are
not a whole number of nanoseconds - which is sometimes the
case.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c     |   10 +++++-----
 arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
 arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
 arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
 5 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 7222096..2bb29c1 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -41,7 +41,7 @@ static int omap2_nand_gpmc_retime(void)
 		return 0;
 
 	memset(&t, 0, sizeof(t));
-	t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
+	t.sync_clk = gpmc_nand_data->gpmc_t->sync_clk;
 	t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_on);
 	t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->adv_on);
 
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 7bb6922..1db606c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -174,7 +174,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 
 	switch (freq) {
 	case 83:
-		min_gpmc_clk_period = 12; /* 83 MHz */
+		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
 		t_avds  = 4;
 		t_avdh  = 2;
@@ -183,7 +183,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 9;
 		break;
 	case 66:
-		min_gpmc_clk_period = 15; /* 66 MHz */
+		min_gpmc_clk_period = 15000; /* 66 MHz */
 		t_ces   = 6;
 		t_avds  = 5;
 		t_avdh  = 2;
@@ -192,7 +192,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 11;
 		break;
 	default:
-		min_gpmc_clk_period = 18; /* 54 MHz */
+		min_gpmc_clk_period = 18500; /* 54 MHz */
 		t_ces   = 7;
 		t_avds  = 7;
 		t_avdh  = 7;
@@ -271,8 +271,8 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t.wr_cycle  = t.rd_cycle;
 		if (cpu_is_omap34xx()) {
 			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ns_to_ticks(min_gpmc_clk_period +
-					t_rdyo));
+					gpmc_ps_to_ticks(min_gpmc_clk_period +
+					t_rdyo * 1000));
 			t.wr_access = t.access;
 		}
 	} else {
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..1b7b3e7 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -168,6 +168,16 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
 	return (time_ns * 1000 + tick_ps - 1) / tick_ps;
 }
 
+unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long tick_ps;
+
+	/* Calculate in picosecs to yield more exact results */
+	tick_ps = gpmc_get_fclk_period();
+
+	return (time_ps + tick_ps - 1) / tick_ps;
+}
+
 unsigned int gpmc_ticks_to_ns(unsigned int ticks)
 {
 	return ticks * gpmc_get_fclk_period() / 1000;
@@ -235,7 +245,7 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
 	int div;
 	u32 l;
 
-	l = sync_clk * 1000 + (gpmc_get_fclk_period() - 1);
+	l = sync_clk + (gpmc_get_fclk_period() - 1);
 	div = l / gpmc_get_fclk_period();
 	if (div > 4)
 		return -1;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 64a0112..1e998ea 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -120,8 +120,8 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
 	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
 
 	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 12 /* 11.1 nsec */;
-	tmp = (t.sync_clk * 1000 + fclk_ps - 1) / fclk_ps;
+	t.sync_clk = 11100 /* 11.1 nsec */;
+	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
 	if (tmp > 4)
 		return -ERANGE;
 	if (tmp <= 0)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..85ded59 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -80,12 +80,12 @@
 #define GPMC_PREFETCH_STATUS_COUNT(val)	(val & 0x00003fff)
 
 /*
- * Note that all values in this struct are in nanoseconds, while
- * the register values are in gpmc_fck cycles.
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
  */
 struct gpmc_timings {
-	/* Minimum clock period for synchronous mode */
-	u16 sync_clk;
+	/* Minimum clock period for synchronous mode (in picoseconds) */
+	u32 sync_clk;
 
 	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
 	u16 cs_on;		/* Assertion time */
@@ -117,6 +117,7 @@ struct gpmc_timings {
 };
 
 extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
+extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
 extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
 extern unsigned long gpmc_get_fclk_period(void);
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:20:51 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:20:51 +0200
Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command line
	partitioning
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122051.20685.46383.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:21:03 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:21:03 +0200
Subject: [PATCH 3/7] mtd: OneNAND: OMAP2/3: prevent regulator sleeping while
	OneNAND is in use
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122103.20685.4205.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:20:57 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:20:57 +0200
Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to onenand_chip
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122057.20685.68480.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Mon Dec 13 07:21:28 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:21:28 +0200
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122128.20685.9312.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Fri Dec 10 05:04:20 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Fri, 10 Dec 2010 12:04:20 +0200
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
Message-ID: <mailman.57.1292242906.1530.linux-mtd@lists.infradead.org>

Initial bad blocks are normal but the messages look like
errors.  Make the messages less scary, make the main
message an informational message not a warning, make the
message displaying registers a debug message and include
the address there instead of in the informational message.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 drivers/mtd/onenand/onenand_base.c |   22 ++++++++++++----------
 drivers/mtd/onenand/onenand_bbt.c  |    4 ++--
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index bde274f..5065fc7 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1488,8 +1488,7 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
 {
 	struct onenand_chip *this = mtd->priv;
 	unsigned long timeout;
-	unsigned int interrupt;
-	unsigned int ctrl;
+	unsigned int interrupt, ctrl, ecc, addr1, addr8;
 
 	/* The 20 msec is enough */
 	timeout = jiffies + msecs_to_jiffies(20);
@@ -1501,25 +1500,28 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
 	/* To get correct interrupt status in timeout case */
 	interrupt = this->read_word(this->base + ONENAND_REG_INTERRUPT);
 	ctrl = this->read_word(this->base + ONENAND_REG_CTRL_STATUS);
+	addr1 = this->read_word(this->base + ONENAND_REG_START_ADDRESS1);
+	addr8 = this->read_word(this->base + ONENAND_REG_START_ADDRESS8);
 
 	if (interrupt & ONENAND_INT_READ) {
-		int ecc = onenand_read_ecc(this);
+		ecc = onenand_read_ecc(this);
 		if (ecc & ONENAND_ECC_2BIT_ALL) {
-			printk(KERN_WARNING "%s: ecc error = 0x%04x, "
-				"controller error 0x%04x\n",
-				__func__, ecc, ctrl);
+			printk(KERN_DEBUG "%s: ecc 0x%04x ctrl 0x%04x "
+			       "intr 0x%04x addr1 %#x addr8 %#x\n",
+			       __func__, ecc, ctrl, interrupt, addr1, addr8);
 			return ONENAND_BBT_READ_ECC_ERROR;
 		}
 	} else {
-		printk(KERN_ERR "%s: read timeout! ctrl=0x%04x intr=0x%04x\n",
-			__func__, ctrl, interrupt);
+		printk(KERN_ERR "%s: read timeout! ctrl 0x%04x "
+		       "intr 0x%04x addr1 %#x addr8 %#x\n",
+		       __func__, ctrl, interrupt, addr1, addr8);
 		return ONENAND_BBT_READ_FATAL_ERROR;
 	}
 
 	/* Initial bad block case: 0x2400 or 0x0400 */
 	if (ctrl & ONENAND_CTRL_ERROR) {
-		printk(KERN_DEBUG "%s: controller error = 0x%04x\n",
-			__func__, ctrl);
+		printk(KERN_DEBUG "%s: ctrl 0x%04x intr 0x%04x addr1 %#x "
+		       "addr8 %#x\n", __func__, ctrl, interrupt, addr1, addr8);
 		return ONENAND_BBT_READ_ERROR;
 	}
 
diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
index 905209b..fc2c16a 100644
--- a/drivers/mtd/onenand/onenand_bbt.c
+++ b/drivers/mtd/onenand/onenand_bbt.c
@@ -101,8 +101,8 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
 			if (ret || check_short_pattern(&buf[j * scanlen],
 					       scanlen, this->writesize, bd)) {
 				bbm->bbt[i >> 3] |= 0x03 << (i & 0x6);
-				printk(KERN_WARNING "Bad eraseblock %d at 0x%08x\n",
-					i >> 1, (unsigned int) from);
+				printk(KERN_INFO "OneNAND eraseblock %d is an "
+					"initial bad block\n", i >> 1);
 				mtd->ecc_stats.badblocks++;
 				break;
 			}
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:21:14 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:21:14 +0200
Subject: [PATCH 5/7] OMAP2/3: OneNAND: add 104MHz support
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122114.20685.55182.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 04:22:50 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 11:22:50 +0200
Subject: [PATCH 5/7] OMAP2/3: OneNAND: add 104MHz support
Message-ID: <mailman.58.1292242908.1530.linux-mtd@lists.infradead.org>

Add GPMC timings for 104MHz OneNAND.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c |    9 +++++++++
 drivers/mtd/onenand/omap2.c        |    3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 1db606c..3a7d25f 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -173,6 +173,15 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 	}
 
 	switch (freq) {
+	case 104:
+		min_gpmc_clk_period = 9600; /* 104 MHz */
+		t_ces   = 3;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 3;
+		t_aavdh = 6;
+		t_rdyo  = 9;
+		break;
 	case 83:
 		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 1a07bfc..ac31f46 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -767,6 +767,9 @@ static int __devinit omap2_onenand_probe(struct platform_device *pdev)
 	case 3:
 		c->freq = 83;
 		break;
+	case 4:
+		c->freq = 104;
+		break;
 	}
 
 #ifdef CONFIG_MTD_PARTITIONS
-- 
1.7.0.4



From adrian.hunter at nokia.com  Mon Dec 13 07:21:22 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Mon, 13 Dec 2010 14:21:22 +0200
Subject: [PATCH 6/7] OMAP2/3: OneNAND: add platform data callback for PM
	constraints
In-Reply-To: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101213122122.20685.93183.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 05:56:24 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 12:56:24 +0200
Subject: [PATCH 6/7] OMAP2/3: OneNAND: add platform data callback for PM constraints
Message-ID: <mailman.59.1292242916.1530.linux-mtd@lists.infradead.org>

Make it possible for boards to set PM constraints such as maximum wakeup
latency.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/plat-omap/include/plat/onenand.h |    8 ++++++++
 drivers/mtd/onenand/omap2.c               |   16 +++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/onenand.h b/arch/arm/plat-omap/include/plat/onenand.h
index affe87e..1d07119 100644
--- a/arch/arm/plat-omap/include/plat/onenand.h
+++ b/arch/arm/plat-omap/include/plat/onenand.h
@@ -15,12 +15,20 @@
 #define ONENAND_SYNC_READ	(1 << 0)
 #define ONENAND_SYNC_READWRITE	(1 << 1)
 
+enum {
+	ONENAND_PM_CONSTRAINT_OFF,
+	ONENAND_PM_CONSTRAINT_ERASING,
+	ONENAND_PM_CONSTRAINT_OTHER,
+};
+
 struct omap_onenand_platform_data {
 	int			cs;
 	int			gpio_irq;
 	struct mtd_partition	*parts;
 	int			nr_parts;
 	int                     (*onenand_setup)(void __iomem *, int freq);
+	void			(*set_pm_constraints)(struct device *dev,
+						      int on);
 	int			dma_channel;
 	u8			flags;
 	u8			regulator_can_sleep;
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index ac31f46..866b9f9 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -64,6 +64,7 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int freq);
+	void (*set_pm_constraints)(struct device *dev, int on);
 	struct regulator *regulator;
 };
 
@@ -605,13 +606,21 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 
 static int omap2_onenand_enable(struct mtd_info *mtd)
 {
-	int ret;
+	int ret, on;
 	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
 
 	ret = regulator_enable(c->regulator);
 	if (ret != 0)
 		dev_err(&c->pdev->dev, "cant enable regulator\n");
 
+	if (c->set_pm_constraints) {
+		if (c->onenand.state == FL_ERASING)
+			on = ONENAND_PM_CONSTRAINT_ERASING;
+		else
+			on = ONENAND_PM_CONSTRAINT_OTHER;
+		c->set_pm_constraints(&c->pdev->dev, on);
+	}
+
 	return ret;
 }
 
@@ -620,6 +629,9 @@ static int omap2_onenand_disable(struct mtd_info *mtd)
 	int ret;
 	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
 
+	if (c->set_pm_constraints)
+		c->set_pm_constraints(&c->pdev->dev, ONENAND_PM_CONSTRAINT_OFF);
+
 	ret = regulator_disable(c->regulator);
 	if (ret != 0)
 		dev_err(&c->pdev->dev, "cant disable regulator\n");
@@ -682,6 +694,8 @@ static int __devinit omap2_onenand_probe(struct platform_device *pdev)
 		c->setup = pdata->onenand_setup;
 	}
 
+	c->set_pm_constraints = pdata->set_pm_constraints;
+
 	if (c->gpio_irq) {
 		if ((r = gpio_request(c->gpio_irq, "OneNAND irq")) < 0) {
 			dev_err(&pdev->dev,  "Failed to request GPIO%d for "
-- 
1.7.0.4



From ffainelli at freebox.fr  Mon Dec 13 09:35:30 2010
From: ffainelli at freebox.fr (Florian Fainelli)
Date: Mon, 13 Dec 2010 15:35:30 +0100
Subject: [PATCH 1/2] mtd: nand: choose correct chip name (ONFI bug)
In-Reply-To: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
References: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
Message-ID: <201012131535.30336.ffainelli@freebox.fr>

On Sunday 12 December 2010 09:23:32 Brian Norris wrote:
> We have the order of the conditional wrong for choosing the ONFI chip name
> vs. the ID table name. Without this fix, we will almost *always* choose a
> NULL string to print out instead of the correct one.
> 
> This has already been suggested by Matthieu Castet.
> 
> Signed-off-by: Brian Norris <computersforpeace at gmail.com>

Acked-by: Florian Fainelli <ffainelli at freebox.fr>

> ---
>  drivers/mtd/nand/nand_base.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 33550c4..38b5eb0 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3164,7 +3164,7 @@ ident_done:
>  	printk(KERN_INFO "NAND device: Manufacturer ID:"
>  		" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, *dev_id,
>  		nand_manuf_ids[maf_idx].name,
> -	chip->onfi_version ? type->name : chip->onfi_params.model);
> +		chip->onfi_version ? chip->onfi_params.model : type->name);
> 
>  	return type;
>  }


From ffainelli at freebox.fr  Mon Dec 13 09:40:52 2010
From: ffainelli at freebox.fr (Florian Fainelli)
Date: Mon, 13 Dec 2010 15:40:52 +0100
Subject: [PATCH 2/2] mtd: nand: rearrange ONFI revision checking,
	add ONFI 2.3
In-Reply-To: <1292142213-645-2-git-send-email-computersforpeace@gmail.com>
References: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
	<1292142213-645-2-git-send-email-computersforpeace@gmail.com>
Message-ID: <201012131540.52835.ffainelli@freebox.fr>

On Sunday 12 December 2010 09:23:33 Brian Norris wrote:
> In checking for the ONFI revision, the first conditional (for checking
> "unsupported" ONFI) seems unnecessary.  All ONFI revisions should be
> backwards-compatible; even if this is not the case on some newer ONFI
> revision, it should simply fail the second version-checking if-else block
> (i.e., the bit-fields for 1.0, 2.0, etc. would not be set to 1). Thus, we
> move our "unsupported" condition after having checked each bit field.
> 
> Also, it's simple enough to add a condition for ONFI revision 2.3. Note
> that this does *NOT* mean we handle all new features of ONFI versions
> above 1.0.
> 
> Signed-off-by: Brian Norris <computersforpeace at gmail.com>

Acked-by: Florian Fainelli <ffainelli at freebox.fr>

> ---
>  drivers/mtd/nand/nand_base.c |   20 ++++++++++++--------
>  1 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 38b5eb0..2237a87 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2872,20 +2872,24 @@ static int nand_flash_detect_onfi(struct mtd_info
> *mtd, struct nand_chip *chip,
> 
>  	/* check version */
>  	val = le16_to_cpu(p->revision);
> -	if (val == 1 || val > (1 << 4)) {
> -		printk(KERN_INFO "%s: unsupported ONFI version: %d\n",
> -								__func__, val);
> -		return 0;
> -	}
> -
> -	if (val & (1 << 4))
> +	if (val & (1 << 5))
> +		chip->onfi_version = 23;
> +	else if (val & (1 << 4))
>  		chip->onfi_version = 22;
>  	else if (val & (1 << 3))
>  		chip->onfi_version = 21;
>  	else if (val & (1 << 2))
>  		chip->onfi_version = 20;
> -	else
> +	else if (val & (1 << 1))
>  		chip->onfi_version = 10;
> +	else
> +		chip->onfi_version = 0;
> +
> +	if (!chip->onfi_version) {
> +		printk(KERN_INFO "%s: unsupported ONFI version: %d\n",
> +								__func__, val);
> +		return 0;
> +	}
> 
>  	sanitize_string(p->manufacturer, sizeof(p->manufacturer));
>  	sanitize_string(p->model, sizeof(p->model));


From kyungmin.park at samsung.com  Mon Dec 13 19:17:54 2010
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Tue, 14 Dec 2010 09:17:54 +0900
Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to
	onenand_chip
In-Reply-To: <20101213122057.20685.68480.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122057.20685.68480.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <AANLkTi=0W8NuF3SNhWwjwDZtuCzyOM8219_pXG=9pU6O@mail.gmail.com>

Hi,

Now I'm used the clock gating for OneNAND instead of regulator.
so I think the mechanism is similar.

On Mon, Dec 13, 2010 at 9:20 PM, Adrian Hunter <adrian.hunter at nokia.com> wrote:
> From 16b760999cb79f9cf71728c9253f1399717be63a Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Fri, 19 Feb 2010 15:39:52 +0100
> Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to onenand_chip
>
> Add enable / disable methods called from get_device() / release_device().
> These can be used, for example, to allow the driver to prevent the voltage
> regulator from being put to sleep while OneNAND is in use.
>
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
> ---
> ?drivers/mtd/onenand/onenand_base.c | ? ?4 ++++
> ?include/linux/mtd/onenand.h ? ? ? ?| ? ?2 ++
> ?2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
> index c38bf9c..bde274f 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -948,6 +948,8 @@ static int onenand_get_device(struct mtd_info *mtd, int new_state)
> ? ? ? ? ? ? ? ?if (this->state == FL_READY) {
> ? ? ? ? ? ? ? ? ? ? ? ?this->state = new_state;
> ? ? ? ? ? ? ? ? ? ? ? ?spin_unlock(&this->chip_lock);
> + ? ? ? ? ? ? ? ? ? ? ? if (this->enable)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? this->enable(mtd);
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?if (new_state == FL_PM_SUSPENDED) {

I put the code the end of function like:

static int onenand_get_device(struct mtd_info *mtd, int new_state)
{
        struct onenand_chip *this = mtd->priv;
        DECLARE_WAITQUEUE(wait, current);

        /*
         * Grab the lock and see if the device is available
         */
        while (1) {
                spin_lock(&this->chip_lock);
                if (this->state == FL_READY) {
                        this->state = new_state;
                        spin_unlock(&this->chip_lock);
                        break;
                }
                if (new_state == FL_PM_SUSPENDED) {
                        spin_unlock(&this->chip_lock);
                        return (this->state == FL_PM_SUSPENDED) ? 0 : -EAGAIN;
                }
                set_current_state(TASK_UNINTERRUPTIBLE);
                add_wait_queue(&this->wq, &wait);
                spin_unlock(&this->chip_lock);
                schedule();
                remove_wait_queue(&this->wq, &wait);
        }

        if (this->clk)
                clk_enable(this->clk);

        return 0;
}


> @@ -974,6 +976,8 @@ static void onenand_release_device(struct mtd_info *mtd)
> ?{
> ? ? ? ?struct onenand_chip *this = mtd->priv;
>
> + ? ? ? if (this->state != FL_PM_SUSPENDED && this->disable)
> + ? ? ? ? ? ? ? this->disable(mtd);
Need to check the SUSPENDED at here? when enter the suspend get_device
is called.
release device is called when resume. so no need to check
FL_PM_SUSPENDED in my case.

> ? ? ? ?/* Release the chip */
> ? ? ? ?spin_lock(&this->chip_lock);
> ? ? ? ?this->state = FL_READY;

and put the same as like:

static void onenand_release_device(struct mtd_info *mtd)
{
        struct onenand_chip *this = mtd->priv;

        /* Release the chip */
        spin_lock(&this->chip_lock);
        this->state = FL_READY;
        wake_up(&this->wq);
        spin_unlock(&this->chip_lock);

        if (this->clk)
                clk_disable(this->clk);
}

Thank you,
Kyungmin Park

> diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
> index 6da3fe3..ae418e4 100644
> --- a/include/linux/mtd/onenand.h
> +++ b/include/linux/mtd/onenand.h
> @@ -118,6 +118,8 @@ struct onenand_chip {
> ? ? ? ?int (*chip_probe)(struct mtd_info *mtd);
> ? ? ? ?int (*block_markbad)(struct mtd_info *mtd, loff_t ofs);
> ? ? ? ?int (*scan_bbt)(struct mtd_info *mtd);
> + ? ? ? int (*enable)(struct mtd_info *mtd);
> + ? ? ? int (*disable)(struct mtd_info *mtd);
>
> ? ? ? ?struct completion ? ? ? complete;
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? irq;
> --
> 1.7.0.4
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From kmpark at infradead.org  Mon Dec 13 19:21:14 2010
From: kmpark at infradead.org (Kyungmin Park)
Date: Tue, 14 Dec 2010 09:21:14 +0900
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
In-Reply-To: <20101213122128.20685.9312.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122128.20685.9312.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <AANLkTimaoZOPjqh80gnEdz6Qz4YzdkQGTaYqv0mu2GeM@mail.gmail.com>

Acked-by: Kyungmin Park <kyungmin.park at samsung.com>

On Mon, Dec 13, 2010 at 9:21 PM, Adrian Hunter <adrian.hunter at nokia.com> wrote:
> From 5fa7a6377683aabd617f78518cd6cd49eae1679e Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Fri, 10 Dec 2010 12:04:20 +0200
> Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
>
> Initial bad blocks are normal but the messages look like
> errors. ?Make the messages less scary, make the main
> message an informational message not a warning, make the
> message displaying registers a debug message and include
> the address there instead of in the informational message.
>
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
> ---
> ?drivers/mtd/onenand/onenand_base.c | ? 22 ++++++++++++----------
> ?drivers/mtd/onenand/onenand_bbt.c ?| ? ?4 ++--
> ?2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
> index bde274f..5065fc7 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -1488,8 +1488,7 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
> ?{
> ? ? ? ?struct onenand_chip *this = mtd->priv;
> ? ? ? ?unsigned long timeout;
> - ? ? ? unsigned int interrupt;
> - ? ? ? unsigned int ctrl;
> + ? ? ? unsigned int interrupt, ctrl, ecc, addr1, addr8;
>
> ? ? ? ?/* The 20 msec is enough */
> ? ? ? ?timeout = jiffies + msecs_to_jiffies(20);
> @@ -1501,25 +1500,28 @@ static int onenand_bbt_wait(struct mtd_info *mtd, int state)
> ? ? ? ?/* To get correct interrupt status in timeout case */
> ? ? ? ?interrupt = this->read_word(this->base + ONENAND_REG_INTERRUPT);
> ? ? ? ?ctrl = this->read_word(this->base + ONENAND_REG_CTRL_STATUS);
> + ? ? ? addr1 = this->read_word(this->base + ONENAND_REG_START_ADDRESS1);
> + ? ? ? addr8 = this->read_word(this->base + ONENAND_REG_START_ADDRESS8);
>
> ? ? ? ?if (interrupt & ONENAND_INT_READ) {
> - ? ? ? ? ? ? ? int ecc = onenand_read_ecc(this);
> + ? ? ? ? ? ? ? ecc = onenand_read_ecc(this);
> ? ? ? ? ? ? ? ?if (ecc & ONENAND_ECC_2BIT_ALL) {
> - ? ? ? ? ? ? ? ? ? ? ? printk(KERN_WARNING "%s: ecc error = 0x%04x, "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "controller error 0x%04x\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, ecc, ctrl);
> + ? ? ? ? ? ? ? ? ? ? ? printk(KERN_DEBUG "%s: ecc 0x%04x ctrl 0x%04x "
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"intr 0x%04x addr1 %#x addr8 %#x\n",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__, ecc, ctrl, interrupt, addr1, addr8);
> ? ? ? ? ? ? ? ? ? ? ? ?return ONENAND_BBT_READ_ECC_ERROR;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else {
> - ? ? ? ? ? ? ? printk(KERN_ERR "%s: read timeout! ctrl=0x%04x intr=0x%04x\n",
> - ? ? ? ? ? ? ? ? ? ? ? __func__, ctrl, interrupt);
> + ? ? ? ? ? ? ? printk(KERN_ERR "%s: read timeout! ctrl 0x%04x "
> + ? ? ? ? ? ? ? ? ? ? ?"intr 0x%04x addr1 %#x addr8 %#x\n",
> + ? ? ? ? ? ? ? ? ? ? ?__func__, ctrl, interrupt, addr1, addr8);
> ? ? ? ? ? ? ? ?return ONENAND_BBT_READ_FATAL_ERROR;
> ? ? ? ?}
>
> ? ? ? ?/* Initial bad block case: 0x2400 or 0x0400 */
> ? ? ? ?if (ctrl & ONENAND_CTRL_ERROR) {
> - ? ? ? ? ? ? ? printk(KERN_DEBUG "%s: controller error = 0x%04x\n",
> - ? ? ? ? ? ? ? ? ? ? ? __func__, ctrl);
> + ? ? ? ? ? ? ? printk(KERN_DEBUG "%s: ctrl 0x%04x intr 0x%04x addr1 %#x "
> + ? ? ? ? ? ? ? ? ? ? ?"addr8 %#x\n", __func__, ctrl, interrupt, addr1, addr8);
> ? ? ? ? ? ? ? ?return ONENAND_BBT_READ_ERROR;
> ? ? ? ?}
>
> diff --git a/drivers/mtd/onenand/onenand_bbt.c b/drivers/mtd/onenand/onenand_bbt.c
> index 905209b..fc2c16a 100644
> --- a/drivers/mtd/onenand/onenand_bbt.c
> +++ b/drivers/mtd/onenand/onenand_bbt.c
> @@ -101,8 +101,8 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
> ? ? ? ? ? ? ? ? ? ? ? ?if (ret || check_short_pattern(&buf[j * scanlen],
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? scanlen, this->writesize, bd)) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bbm->bbt[i >> 3] |= 0x03 << (i & 0x6);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? printk(KERN_WARNING "Bad eraseblock %d at 0x%08x\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i >> 1, (unsigned int) from);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? printk(KERN_INFO "OneNAND eraseblock %d is an "
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "initial bad block\n", i >> 1);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mtd->ecc_stats.badblocks++;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ? ? ? ? ?}
> --
> 1.7.0.4
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From oyvind.harboe at zylin.com  Tue Dec 14 04:20:03 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 10:20:03 +0100
Subject: Faster flash_eraseall for NOR flash
Message-ID: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>

CFI erase performance can be 10x slower than write
performance on CFI flashes.

I've added an option to skip already erased CFI blocks. This
includes checking if the JFFS2 cleanmarker is written.


--
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer



-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mtd-utils-add-fast-NOR-flash-erase.patch
Type: text/x-patch
Size: 3986 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101214/9031801b/attachment.bin>

From vapier.adi at gmail.com  Tue Dec 14 09:52:53 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 09:52:53 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
Message-ID: <AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>

On Tue, Dec 14, 2010 at 04:20, ?yvind Harboe wrote:
> CFI erase performance can be 10x slower than write
> performance on CFI flashes.
>
> I've added an option to skip already erased CFI blocks. This
> includes checking if the JFFS2 cleanmarker is written.

i dont think -f/--fast is the right name.  how about something a bit
more explicit like --skip-erased ?

why cant this also be used for NAND ?  all the NAND devices i use have
0xff when erased.

other random problems:
 - the coding style of this patch is incorrect.  please review the
style found in the rest of the file.  such as brace placement and
spaces in function calls.
 - your patch is not against the master branch -- there is no
"flash_eraseall.c" file anymore.
 - once you update, your code will look vastly different as there are
helpers to do memory allocation/error output/etc...
 - better to use pread() rather than lseek()/read().
-mike


From oyvind.harboe at zylin.com  Tue Dec 14 10:09:33 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 16:09:33 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
Message-ID: <AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>

Hi Mike,

thanks for the feedback!

>> I've added an option to skip already erased CFI blocks. This
>> includes checking if the JFFS2 cleanmarker is written.
>
> i dont think -f/--fast is the right name. ?how about something a bit
> more explicit like --skip-erased ?

Sounds good to me.

> why cant this also be used for NAND ? ?all the NAND devices i use have
> 0xff when erased.

I don't have any NAND to test with, nor am I terribly familiar with
NAND.

I think it would be good to limit this patch to NOR flash that I
can actually test and know something about. Also NAND flash
doesn't have the horrible erase performance issues, so it
might not be worth it from the point of view that it adds a new
code path.

Will it be acceptable to limit this patch to NOR flash and
pass the buck on NAND flash to someone
more familiar with NAND flash, who can test it and knows
whether or not it makes much sense?

> other random problems:
> ?- the coding style of this patch is incorrect. ?please review the
> style found in the rest of the file. ?such as brace placement and
> spaces in function calls.

I did make an effort to follow the style, so any mismatch with
the existing style is just because I'm white-space blind. Much
like color blindness, it happens when you see enough different
formatting rules. The most annoying is of course code that
doesn't follow any rules, so I'll see about getting this fixed.

> ?- your patch is not against the master branch -- there is no
> "flash_eraseall.c" file anymore.

k.

> ?- once you update, your code will look vastly different as there are
> helpers to do memory allocation/error output/etc...

k.

> ?- better to use pread() rather than lseek()/read().

Didn't know that one. Looks nice though!



-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer


From dedekind1 at gmail.com  Tue Dec 14 10:12:37 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 17:12:37 +0200
Subject: [PATCH 1/1] mtd: nand: add check for out of page read
In-Reply-To: <1290156045-11719-1-git-send-email-r64343@freescale.com>
References: <1290156045-11719-1-git-send-email-r64343@freescale.com>
Message-ID: <1292339557.2538.32.camel@localhost>

On Fri, 2010-11-19 at 16:40 +0800, Jason Liu wrote:
> When run mtd_oobtest case, there will be one error for step(4),
> which turned out it need add one check for out of page read in
> nand_do_read_oob just like mtd_do_write_oob did it already.
> This commit also fix one typo error for comments in mtd_do_write_oob
> 
> Signed-off-by: Jason Liu <r64343 at freescale.com>
> ---
>  drivers/mtd/nand/nand_base.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 1f75a1b..75d199e 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -1782,6 +1782,13 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
>  	else
>  		len = mtd->oobsize;
>  
> +	/* Do not allow read past end of page */
> +	if ((ops->ooboffs + readlen) > len) {
> +		DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt to read "
> +				"past end of page\n", __func__);
> +		return -EINVAL;
> +	}

As you reported to me in a private e-mail (although I prefer to always
have a public ML in CC when dealing with open source stuff) this patch
is wrong. Indeed, it limits the maximum amount of bytes which can be
read at one go to the OOB size, which is incorrect, because
mtd->read_oob() allows reading multiple pages at a time, see comment
near "struct mtd_oob_ops" at include/linux/mtd/mtd.h. So this patch
breaks ABI and hence, has to be reverted.

>  	if (unlikely(ops->ooboffs >= len)) {
>  		DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt to start read "
>  					"outside oob\n", __func__);

Side note: nand_base.c has a bunch of senseless unlikely() hints, would
be nice to clean that up some day.

> -	/* Do not allow reads past end of device */
> +	/* Do not allow write past end of device */

Care to make this a separate clean-up patch meanwhile?

Thank!

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



From vapier.adi at gmail.com  Tue Dec 14 10:18:43 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 10:18:43 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
Message-ID: <AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>

On Tue, Dec 14, 2010 at 10:09, ?yvind Harboe wrote:
>> why cant this also be used for NAND ? ?all the NAND devices i use have
>> 0xff when erased.
>
> I don't have any NAND to test with, nor am I terribly familiar with
> NAND.
>
> I think it would be good to limit this patch to NOR flash that I
> can actually test and know something about. Also NAND flash
> doesn't have the horrible erase performance issues, so it
> might not be worth it from the point of view that it adds a new
> code path.

i think it's fine to let the option operate on NAND devices.  if
someone has a problem with how it operates, then they can post a fix
for their use case.  i wouldnt worry about trying to come up with a
bullet proof solution at the first try.
-mike


From oyvind.harboe at zylin.com  Tue Dec 14 10:26:37 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 16:26:37 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
Message-ID: <AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>

> i think it's fine to let the option operate on NAND devices. ?if
> someone has a problem with how it operates, then they can post a fix
> for their use case. ?i wouldnt worry about trying to come up with a
> bullet proof solution at the first try.

I'd rather pass the buck, because NAND is using a different code
path. Also this is an optimization that makes little difference on
NAND.


-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer


From dedekind1 at gmail.com  Tue Dec 14 10:26:49 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 17:26:49 +0200
Subject: [PATCH 1/1] mtd: nand: add check for out of page read
In-Reply-To: <1290156045-11719-1-git-send-email-r64343@freescale.com>
References: <1290156045-11719-1-git-send-email-r64343@freescale.com>
Message-ID: <1292340409.2538.40.camel@localhost>

On Fri, 2010-11-19 at 16:40 +0800, Jason Liu wrote:
> When run mtd_oobtest case, there will be one error for step(4),
> which turned out it need add one check for out of page read in
> nand_do_read_oob just like mtd_do_write_oob did it already.
> This commit also fix one typo error for comments in mtd_do_write_oob
> 
> Signed-off-by: Jason Liu <r64343 at freescale.com>

I cannot reproduce this with nandsim, can you?

I tried:

1. sudo modprobe nandsim
   sudo modprobe mtd_oobtest dev=0

2. sudo ./load_nandsim.sh 128 128 2048
   sudo modprobe mtd_oobtest dev=0

In both cases the test passes: "mtd_oobtest: finished with 0 errors"

And in 'nand_do_read_oob()' I see the following piece of code:

        /* Do not allow reads past end of device */
        if (unlikely(from >= mtd->size ||
                     ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
                                        (from >> chip->page_shift)) * len)) {
                DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt read beyond end "
                                        "of device\n", __func__);
                return -EINVAL;
        }

which should handle the case AFAICS.

So, although I did think hard about this, it looks like there is no
problem. What is the kernel version you are looking at? I checked it
with my l2-mtd-2.6.git, which is the latest mtd-2.6.git plus a revert
commit of your patch:

http://git.infradead.org/users/dedekind/l2-mtd-2.6.git

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



From vapier.adi at gmail.com  Tue Dec 14 10:33:00 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 10:33:00 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
Message-ID: <AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>

On Tue, Dec 14, 2010 at 10:26, ?yvind Harboe wrote:
>> i think it's fine to let the option operate on NAND devices. ?if
>> someone has a problem with how it operates, then they can post a fix
>> for their use case. ?i wouldnt worry about trying to come up with a
>> bullet proof solution at the first try.
>
> I'd rather pass the buck, because NAND is using a different code
> path. Also this is an optimization that makes little difference on
> NAND.

so pass the buck to me and say i told you to do it that way ;)

the only thing it changes in your original patch is to remove the type
checking ?
-mike


From oyvind.harboe at zylin.com  Tue Dec 14 10:33:59 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 16:33:59 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
Message-ID: <AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>

> the only thing it changes in your original patch is to remove the type
> checking ?

No. There is a different code path for writing the cleanmarkers.


-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer


From vapier.adi at gmail.com  Tue Dec 14 10:38:17 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 10:38:17 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
	<AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
Message-ID: <AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>

On Tue, Dec 14, 2010 at 10:33, ?yvind Harboe wrote:
>> the only thing it changes in your original patch is to remove the type
>> checking ?
>
> No. There is a different code path for writing the cleanmarkers.

OK, i missed that.  just change the code to issue a warning when
someone tries to use this option on a NAND device.  something like
"--skip-erased: sorry, no support (yet) for NAND devices".

in looking at the original patch, i noticed something else ... dont
mix variable decls and code.  i dont think mtd-utils has moved on to
newer C standards/styles yet and support that.  for example, the
"ssize_t i" decl after a bunch of if statements.
-mike


From oyvind.harboe at zylin.com  Tue Dec 14 10:46:01 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 16:46:01 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
	<AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
	<AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>
Message-ID: <AANLkTincaN6in-9F-jUFygCx6-=DGW_9ju=Ve1QbXWSf@mail.gmail.com>

On Tue, Dec 14, 2010 at 4:38 PM, Mike Frysinger <vapier.adi at gmail.com> wrote:
> On Tue, Dec 14, 2010 at 10:33, ?yvind Harboe wrote:
>>> the only thing it changes in your original patch is to remove the type
>>> checking ?
>>
>> No. There is a different code path for writing the cleanmarkers.
>
> OK, i missed that. ?just change the code to issue a warning when
> someone tries to use this option on a NAND device. ?something like
> "--skip-erased: sorry, no support (yet) for NAND devices".
>
> in looking at the original patch, i noticed something else ... dont
> mix variable decls and code. ?i dont think mtd-utils has moved on to
> newer C standards/styles yet and support that. ?for example, the
> "ssize_t i" decl after a bunch of if statements.

I'll see about getting this done. Don't know when though, if
someone beats me to the punch here, no loss :-)


-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer


From vapier.adi at gmail.com  Tue Dec 14 10:47:40 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 10:47:40 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTincaN6in-9F-jUFygCx6-=DGW_9ju=Ve1QbXWSf@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
	<AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
	<AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>
	<AANLkTincaN6in-9F-jUFygCx6-=DGW_9ju=Ve1QbXWSf@mail.gmail.com>
Message-ID: <AANLkTimOmMNeg2Ni92CmaTt2RAk-m=HVSNdNuO8sTJ8q@mail.gmail.com>

On Tue, Dec 14, 2010 at 10:46, ?yvind Harboe wrote:
> I'll see about getting this done. Don't know when though, if
> someone beats me to the punch here, no loss :-)

np; take your time.  thanks for the improvements!
-mike


From dedekind1 at gmail.com  Tue Dec 14 11:01:55 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:01:55 +0200
Subject: [PATCH] mtd: OneNAND: Fix multi block erase support at 4KiB
	pagesize
In-Reply-To: <20101206000518.GA18352@july>
References: <20101206000518.GA18352@july>
Message-ID: <1292342515.2538.66.camel@localhost>

On Mon, 2010-12-06 at 09:05 +0900, Kyungmin Park wrote:
> From: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Original 4KiB pagesize chip (SLC) doesn't support Multi block erase at Spec.
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Pushed to l2-mtd-2.6.git, thank you!

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



From Artem.Bityutskiy at nokia.com  Tue Dec 14 11:01:40 2010
From: Artem.Bityutskiy at nokia.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:01:40 +0200
Subject: [PATCH] mtd: add NOR flash write buffer size reporting for
	UBI/UBIFS
In-Reply-To: <1291667217-13097-1-git-send-email-agust@denx.de>
References: <1291667217-13097-1-git-send-email-agust@denx.de>
Message-ID: <1292342500.2538.65.camel@localhost>

Hi, thank you for the patch, but I have few requests.

On Mon, 2010-12-06 at 21:26 +0100, Anatolij Gustschin wrote:
> Add "write_buffer_size" field to struct mtd_info. This field
> will be used to set minimal I/O unit size (min_io_size) for UBI
> on NOR flash. In case of NOR flash minimal I/O size must be equal
> to the maximal size of the write buffer used by embedded flash
> programming algorithm.
> 
> Flash programming from prepared write buffer performed in one
> programming operation could be interrupted by a power cut or
> a system reset causing corrupted (partially written) areas in
> a flash sector. Knowing the size of potentially corrupted areas
> UBIFS scanning and recovery algorithms are able to perform
> successful recovery.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>
> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c |    1 +
>  drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++++
>  drivers/mtd/chips/cfi_cmdset_0020.c |    1 +
>  drivers/mtd/mtdconcat.c             |    1 +
>  drivers/mtd/mtdpart.c               |    1 +
>  drivers/mtd/ubi/build.c             |    5 ++++-
>  include/linux/mtd/mtd.h             |   12 ++++++++++++
>  7 files changed, 24 insertions(+), 1 deletions(-)

Could you please keep MTD and UBI changes in separate patches?

>  	/*
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index fe8d77e..cb902d1 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -144,6 +144,18 @@ struct mtd_info {
>  	 */
>  	uint32_t writesize;
>  
> +	/*
> +	 * Sets minimal I/O unit size (min_io_size) for UBI on NOR flash.
> +	 * In case of NOR flash minimal I/O size must be equal to the size
> +	 * of the write buffer used by internal flash programming algorithm.
> +	 * This requirement results from the fact that the flash programming
> +	 * operation could be interrupted by a power cut or a system reset
> +	 * causing corrupted (partially written) areas in a flash sector.
> +	 * Knowing the size of potentially corrupted areas UBIFS scanning
> +	 * and recovery algorithms are able to perform successful recovery.
> +	 */
> +	uint32_t write_buffer_size;

Err, no, please, add comment like that to UBI, because it MTD subsystem
is wrong place to discuss UBIFS issues.

But here, instead, explain what is this and how is it different to
writesize.

Also, what write_buffer_size is in case of NAND? I think it should be
equivalent to mtd->writesize.

If we think in terms of general MTD device model:

1. mtd->writesize is the minimal amount of bytes you can write at a
time.

2. but the MTD device can have a "write-buffer", which means it can
write multiple mtd->writesize chunks at a time. And the size of this
buffer has to be "mtd->write_buffer_size" bytes.

So if you write 4 * mtd->writesize bytes, and mtd->write_buffer_size is
2*mtd->writesize, then MTD driver can (but does not have to) do 2
mtd->writesize write operations, not 4.

So I expect a comment like that instead.

To conclude, can you please:

0. Submit an mtd.h patch which just adds the field and nice comment.
1. Submit a NOR-specific patch.
2. Submit a NAND-specific patch - just do mtd->write_buffer_size =
mtd->writesuze in 'nand_scan_tail()'.
3. Submit a OneNAND-specific patch - do the same in 'onenand_scan()'.
4. Submit a patch for mtdpart and mtdconcat.
5. Submit an UBI patch

Yes, it is more job for you, but I hope I'll not scary you off with this
request :-) Thanks!

N.B. And actually, looking at other fields in mtd_info (e.g.,
numeraseregions) makes me think that it is better to name the new field
"writebufsize" instead. This would be more consistent and shorter.

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



From dedekind1 at gmail.com  Tue Dec 14 11:24:38 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:24:38 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101207182012.GA10546@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
Message-ID: <1292343878.2538.80.camel@localhost>

On Tue, 2010-12-07 at 10:20 -0800, Jason Lunz wrote:
> On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote:
> > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz at acm.org> wrote:
> > >
> > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
> > > dependencies down closer to the parts of mtd that actually need it.
> > > This allows enough of mtd to build to let jffs2 be used on uml.
> > >
> > > Signed-off-by: Jason Lunz <lunz at acm.org>
> > > ---
> > >  arch/um/Kconfig.rest        |    4 +---
> > >  drivers/mtd/Kconfig         |    1 -
> > >  drivers/mtd/Makefile        |    3 ++-
> > >  drivers/mtd/chips/Kconfig   |    4 ++++
> > >  drivers/mtd/devices/Kconfig |    8 ++++++++
> > >  drivers/mtd/maps/Kconfig    |    4 ++++
> > >  drivers/mtd/mtdchar.c       |    4 ++++
> > >  drivers/mtd/nand/Kconfig    |    3 +++
> > >  drivers/mtd/onenand/Kconfig |    3 +++
> > >  include/linux/mtd/map.h     |    2 ++
> > >  10 files changed, 31 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
> > > index 0ccad0f..e34f399 100644
> > > --- a/arch/um/Kconfig.rest
> > > +++ b/arch/um/Kconfig.rest
> > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
> > >
> > >  source "drivers/md/Kconfig"
> > >
> > > -if BROKEN
> > > -       source "drivers/mtd/Kconfig"
> > > -endif
> > > +source "drivers/mtd/Kconfig"
> > 
> > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2).
> > 
> > Do you exactly know why it was marked and fixes this patch all issues?
> 
> I don't know exactly why it was originally marked BROKEN. I imagine it
> was because most of the low-level mtd drivers need readb/writeb and
> friends, which don't exist on uml. But now that mtd has virtual ram- and
> blockdev-backed drivers, that's no longer sufficient reason to omit the
> whole subsystem.
> 
> I can't claim that this fixes all possible issues of course, but I've
> privately been using this patch to run block2mtd under uml for years. My
> original motivation was to allow the use of jffs2 in a uml-based test
> environment and for that it's worked very well.

But I think your solution is a bit dirty, because it adds a great deal
of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places.
This is error-prone.

Instead, you should solve this problem in UML code. I do not know how,
but may be you can add readb/writeb there which actually do nothing or
print a scary warning, or do BUG(), and let things which use them just
fail run-time.

Anyway, please, think about a solution which needs few changes in UML
code instead of myriads of small little changes in many places.

Thanks!

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



From dedekind1 at gmail.com  Tue Dec 14 11:30:47 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:30:47 +0200
Subject: [PATCH v4 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
In-Reply-To: <20101209140410.26049.51539.stgit@dev.siriade.com>
References: <20101209140410.26049.51539.stgit@dev.siriade.com>
Message-ID: <1292344247.2538.84.camel@localhost>

On Thu, 2010-12-09 at 15:04 +0100, Guillaume LECERF wrote:
> These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
> to patch all Samsung chips from 0.0 to 1.0.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
> [2] https://dev.openwrt.org/ticket/7348
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c |   14 +++++++++++---
>  1 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 9d68ab9..bf457a4 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -392,9 +392,17 @@ static struct cfi_fixup fixup_table[] = {
>  static void cfi_fixup_major_minor(struct cfi_private *cfi,
>  				  struct cfi_pri_amdstd *extp)
>  {
> -	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
> -	    extp->MajorVersion == '0')
> -		extp->MajorVersion = '1';
> +	if (cfi->mfr == CFI_MFR_SAMSUNG) {
> +		if (extp->MajorVersion == '0' && extp->MinorVersion == '0') {
> +			/*
> +			 * Samsung K8P2815UQB and K8D6x16UxM chips report major=0 / minor=0
> +			 */
> +			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 0.0 to 1.0\n");
> +
> +			extp->MajorVersion = '1';
> +		}

I'm sorry for this nit-pick, but could you please make checkpatch.pl
happy:

WARNING: line over 80 characters
#97: FILE: drivers/mtd/chips/cfi_cmdset_0002.c:398:
+                        * Samsung K8P2815UQB and K8D6x16UxM chips
report major=0 / minor=0

Also, I do not see any reason for a newline between printk() and
extp->MajorVersion = '1' - it only makes code unnecessary sparse.
Newlines ar good between logically independent things, but not between 2
things which are about the same - print about X and then do X.

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



From dedekind1 at gmail.com  Tue Dec 14 11:31:53 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:31:53 +0200
Subject: [PATCH v4 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101209140416.26049.54282.stgit@dev.siriade.com>
References: <20101209140410.26049.51539.stgit@dev.siriade.com>
	<20101209140416.26049.54282.stgit@dev.siriade.com>
Message-ID: <1292344313.2538.86.camel@localhost>

On Thu, 2010-12-09 at 15:04 +0100, Guillaume LECERF wrote:
> These chips report CFI v3.3 [1], so patch them on the fly to the more
> correct v1.3.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
> [2] https://dev.openwrt.org/ticket/866
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
> Acked-by: Wolfram Sang <w.sang at pengutronix.de>
> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index bf457a4..13cee2b 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -401,6 +401,14 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
>  
>  			extp->MajorVersion = '1';
>  		}
> +		if (extp->MajorVersion == '3' && extp->MinorVersion == '3') {
> +			/*
> +			 * Samsung K8D3x16UxC chips report major=3 / minor=3
> +			 */
> +			printk(KERN_NOTICE "  Fixed Samsung's Amd/Fujitsu Extended Query version from 3.3 to 1.3\n");
> +
> +			extp->MajorVersion = '1';
> +		}

Similar, I think this newline is unneeded. Sorry for nit-picking
again :-)

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



From dedekind1 at gmail.com  Tue Dec 14 11:44:36 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:44:36 +0200
Subject: Please teach UBI
In-Reply-To: <4D0264BF.6060904@gmail.com>
References: <4D0264BF.6060904@gmail.com>
Message-ID: <1292345076.2538.95.camel@localhost>

On Sat, 2010-12-11 at 02:34 +0900, Tarosa wrote:
> Hello.
> 
> Because I do not usually use English, unknown sentences might be written.
> 
> It is a basic question.
> UBI is an array of the initial of "Unsorted block images". Please teach the
> meaning of this "Unsorted block images".

Well, you can consider physical erase blocks to be sorted. Then when you
put UBI on top, you have logical eraseblocks (LEBs). Each LEB contains
an "image" (data), and it is mapped to a PEB (block), and and UBI makes
these images to be unsorted in physical level.

So
1. block = physical eraseblock
2. block image - the contents of a physical eraseblocks.

Without UBI, "block images" are sorted.

With UBI, they become "unsorted", in a sense that UBI adds logical layer
with mapping, so on the physical level the "block images" become
unsorted.

Hence the name. It also means "where" in Latin. IBM guys invented it,
not me, so my understanding can be wrong.

> Was there a filesystem of "Sorted block images" in the past?

In physical eraseblocks.

> What after the filesystem is different as for not sorting block images?

UBI is not file-system at all. It is a layer between MTD and
file-system. UBIFS is a file-system which relies on UBI. It name comes
from UBI + FS = UBIFS.

> Where of UBI is unsorted block images?
> I do not understand. Please tell me.
> 
> There are another and a question.
> It is defined that CONFIG_MTD_UBI_WL_THRESHOLD is 4096. It is thought this is to
> mean WL is done as difference between a maximum  and a minimum  of the value of
> erace counter of PEBs are always in the range of 4096*2(=8192).

Not 8192, but 4096.

> Why is it 8192 ?
> In a value that is bigger than 8192, isn't it good? Or, isn't it good in a
> narrower range?

This is just a default. For modern flash you may need lower value, this
is configurable.

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



From dedekind1 at gmail.com  Tue Dec 14 11:50:40 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:50:40 +0200
Subject: About MTD Testing suite included in the Linux kernel.
In-Reply-To: <AANLkTi=-L0DuQziSkzzock8LOJEDY2z37t2bLWQQ_YXG@mail.gmail.com>
References: <AANLkTi=-L0DuQziSkzzock8LOJEDY2z37t2bLWQQ_YXG@mail.gmail.com>
Message-ID: <1292345440.2538.100.camel@localhost>

On Sat, 2010-12-11 at 21:22 +0800, os user wrote:
> Hi,
> 
> When I work on MTD testing tool (drivers/mtd/tests) included in the
> Linux kernel, I found a problem.
> For mtd_oobtest, I failed at the testing '4 of 5'. This testing case
> will test 'reading past the device'.

We are discussing the same here:

http://lists.infradead.org/pipermail/linux-mtd/2010-December/033407.html

Please, take a look there.

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



From dedekind1 at gmail.com  Tue Dec 14 11:53:53 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 18:53:53 +0200
Subject: [PATCH 27/30] mtd: don't use flush_scheduled_work()
In-Reply-To: <1292086307-19211-28-git-send-email-tj@kernel.org>
References: <1292086307-19211-1-git-send-email-tj@kernel.org>
	<1292086307-19211-28-git-send-email-tj@kernel.org>
Message-ID: <1292345633.2538.101.camel@localhost>

On Sat, 2010-12-11 at 17:51 +0100, Tejun Heo wrote:
> flush_scheduled_work() is deprecated and scheduled to be removed.
> Directly flush cxt->work_{erase|write} on removal instead.
> 
> Signed-off-by: Tejun Heo <tj at kernel.org>
> Cc: David Woodhouse <dwmw2 at infradead.org>
> Cc: linux-mtd at lists.infradead.org
> ---
> This is part of a series to remove flush_scheduled_work() usage to
> prepare for deprecation of flush_scheduled_work().  Patches in this
> series are self contained and mostly straight-forward.
> 
> Please feel free to take it into the appropriate tree, or just ack it.
> In the latter case, I'll merge the patch through the workqueue tree
> during the next merge window.
> 
> If you're seeing this patch for the second time, it's because the
> commit hasn't showed up in mainline yet.  Please let me know what
> should be done.

Pushed to l2-mtd-2.6.git, thanks. This means this will be merged to the
mtd tree a bit later and will go upstream.

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



From dedekind1 at gmail.com  Tue Dec 14 12:00:23 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 19:00:23 +0200
Subject: [PATCH] MTD: NAND: ams-delta: convert to platform driver
In-Reply-To: <201012111840.05270.jkrzyszt@tis.icnet.pl>
References: <201012111840.05270.jkrzyszt@tis.icnet.pl>
Message-ID: <1292346023.2538.103.camel@localhost>

On Sat, 2010-12-11 at 18:40 +0100, Janusz Krzysztofik wrote:
> In its current form, the driver may break unrelated machines if built into the 
> kernel, hence is not suitable for inclusion into a kernel built for multiple 
> OMAP1 machines. Convert it to a platform driver, that should be free from that 
> issue.
> 
> While being at it, get rid of depreciated omap_read/write(), use ioremap() 
> instead.
> 
> Created and tested against linux-2.6.37-rc5 on Amstrad Delta.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>

Sorry, but would it please be possible to split this few small patches -
this one is too difficult to review, at least for me.

Thanks!

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



From oyvind.harboe at zylin.com  Tue Dec 14 14:27:18 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Tue, 14 Dec 2010 20:27:18 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTimOmMNeg2Ni92CmaTt2RAk-m=HVSNdNuO8sTJ8q@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
	<AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
	<AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>
	<AANLkTincaN6in-9F-jUFygCx6-=DGW_9ju=Ve1QbXWSf@mail.gmail.com>
	<AANLkTimOmMNeg2Ni92CmaTt2RAk-m=HVSNdNuO8sTJ8q@mail.gmail.com>
Message-ID: <AANLkTim7-ZpO5nQ1Up=rxLJVbCLNJqfbiUGvSnsrONay@mail.gmail.com>

On Tue, Dec 14, 2010 at 4:47 PM, Mike Frysinger <vapier.adi at gmail.com> wrote:
> On Tue, Dec 14, 2010 at 10:46, ?yvind Harboe wrote:
>> I'll see about getting this done. Don't know when though, if
>> someone beats me to the punch here, no loss :-)
>
> np; take your time. ?thanks for the improvements!

This is the server, right?

http://git.infradead.org/mtd-utils.git

I made a stab at trying to get something to build at least.

-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 63 25 00

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-flash_erase-wip-to-add-NOR-skip-erased-block-option.patch
Type: text/x-patch
Size: 3343 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101214/03b295a6/attachment.bin>

From lunz at acm.org  Tue Dec 14 14:51:24 2010
From: lunz at acm.org (Jason Lunz)
Date: Tue, 14 Dec 2010 11:51:24 -0800
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292343878.2538.80.camel@localhost>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
Message-ID: <20101214195124.GA6010@falooley.org>


On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote:
> But I think your solution is a bit dirty, because it adds a great deal
> of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places.
> This is error-prone.

The intent of that patch was to allow as much of the mtd subsystem to
compile as possible. My thinking was to try and rectify the fact that
uml has gone without mtd (and hence jffs2) support for years even though
much of it works just fine. I think the entire subsystem being marked
BROKEN in kconfig kept anyone from experimenting with it.

The patch I sent was actually a reaction to feedback I got from Sam
Ravnborg on my last attempt (um, three years ago :/ ) in which he
suggested pushing down the ifdefs closer to their points of use. But I
agree, the minimal version has a much smaller footprint.

The version below still meets the goal of allowing jffs2-on-block2mtd
usage under uml but is much smaller because only the mtd core is
included. Compile-tested on i386, x86_64, um/i386, and um/x86_64.

> Instead, you should solve this problem in UML code. I do not know how,
> but may be you can add readb/writeb there which actually do nothing or
> print a scary warning, or do BUG(), and let things which use them just
> fail run-time.

Something like this could work, but it would be error-prone for anyone
else who attempts using iomem-requiring drivers on uml. Instead of
getting obvious compile failures we'd have broken drivers that BUG() or
emit scary warnings. That doesn't seem to me like an improvement.

Jason

--

Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
dependencies down closer to the parts of mtd that actually need it.
This allows enough of mtd to build to let jffs2 be used on uml.

Signed-off-by: Jason Lunz <lunz at acm.org>
---
 arch/um/Kconfig.rest    |    4 +---
 drivers/mtd/Kconfig     |    7 +++++--
 drivers/mtd/Makefile    |    3 ++-
 drivers/mtd/mtdchar.c   |    4 ++++
 include/linux/mtd/map.h |   18 +++++++++---------
 5 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
index 0ccad0f..e34f399 100644
--- a/arch/um/Kconfig.rest
+++ b/arch/um/Kconfig.rest
@@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
 
 source "drivers/md/Kconfig"
 
-if BROKEN
-	source "drivers/mtd/Kconfig"
-endif
+source "drivers/mtd/Kconfig"
 
 source "drivers/leds/Kconfig"
 
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 1e2cbf5..7537654 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,6 +1,5 @@
 menuconfig MTD
 	tristate "Memory Technology Device (MTD) support"
-	depends on HAS_IOMEM
 	help
 	  Memory Technology Devices are flash, RAM and similar chips, often
 	  used for solid state file systems on embedded devices. This option
@@ -307,7 +306,7 @@ config SSFDC
 
 config SM_FTL
 	tristate "SmartMedia/xD new translation layer"
-	depends on EXPERIMENTAL && BLOCK
+	depends on EXPERIMENTAL && BLOCK && HAS_IOMEM
 	select MTD_BLKDEVS
 	select MTD_NAND_ECC
 	help
@@ -330,6 +329,8 @@ config MTD_OOPS
 	  To use, add console=ttyMTDx to the kernel command line,
 	  where x is the MTD device number to use.
 
+if HAS_IOMEM
+
 source "drivers/mtd/chips/Kconfig"
 
 source "drivers/mtd/maps/Kconfig"
@@ -342,6 +343,8 @@ source "drivers/mtd/onenand/Kconfig"
 
 source "drivers/mtd/lpddr/Kconfig"
 
+endif # HAS_IOMEM
+
 source "drivers/mtd/ubi/Kconfig"
 
 endif # MTD
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 760abc5..74a03bd 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS)		+= mtdoops.o
 nftl-objs		:= nftlcore.o nftlmount.o
 inftl-objs		:= inftlcore.o inftlmount.o
 
-obj-y		+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
+obj-y			+= tests/
+obj-$(CONFIG_HAS_IOMEM)	+= chips/ lpddr/ maps/ devices/ nand/ onenand/
 
 obj-$(CONFIG_MTD_UBI)		+= ubi/
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 4759d82..a434354 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file,
 /*
  * set up a mapping for shared memory segments
  */
+#ifdef CONFIG_HAS_IOMEM
 static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
 {
 #ifdef CONFIG_MMU
@@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma)
 	return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS;
 #endif
 }
+#endif
 
 static const struct file_operations mtd_fops = {
 	.owner		= THIS_MODULE,
@@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = {
 #endif
 	.open		= mtd_open,
 	.release	= mtd_close,
+#ifdef CONFIG_HAS_IOMEM
 	.mmap		= mtd_mmap,
+#endif
 #ifndef CONFIG_MMU
 	.get_unmapped_area = mtd_get_unmapped_area,
 #endif
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index a9e6ba4..3d9f7e0 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map)
 	return r;
 }
 
+#ifdef CONFIG_MTD_COMPLEX_MAPPINGS
+#define map_read(map, ofs) (map)->read(map, ofs)
+#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len)
+#define map_write(map, datum, ofs) (map)->write(map, datum, ofs)
+#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len)
+
+extern void simple_map_init(struct map_info *);
+#define map_is_linear(map) (map->phys != NO_XIP)
+
 static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
 {
 	map_word r;
@@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
 	memcpy_toio(map->virt + to, from, len);
 }
 
-#ifdef CONFIG_MTD_COMPLEX_MAPPINGS
-#define map_read(map, ofs) (map)->read(map, ofs)
-#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len)
-#define map_write(map, datum, ofs) (map)->write(map, datum, ofs)
-#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len)
-
-extern void simple_map_init(struct map_info *);
-#define map_is_linear(map) (map->phys != NO_XIP)
-
 #else
 #define map_read(map, ofs) inline_map_read(map, ofs)
 #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len)
-- 
1.7.2.3



From dedekind1 at gmail.com  Tue Dec 14 15:01:33 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 14 Dec 2010 22:01:33 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101214195124.GA6010@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org>
Message-ID: <1292356893.29257.1.camel@koala>

On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote:
> On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote:
> > But I think your solution is a bit dirty, because it adds a great deal
> > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places.
> > This is error-prone.
> 
> The intent of that patch was to allow as much of the mtd subsystem to
> compile as possible. My thinking was to try and rectify the fact that
> uml has gone without mtd (and hence jffs2) support for years even though
> much of it works just fine. I think the entire subsystem being marked
> BROKEN in kconfig kept anyone from experimenting with it.
> 
> The patch I sent was actually a reaction to feedback I got from Sam
> Ravnborg on my last attempt (um, three years ago :/ ) in which he
> suggested pushing down the ifdefs closer to their points of use. But I
> agree, the minimal version has a much smaller footprint.
> 
> The version below still meets the goal of allowing jffs2-on-block2mtd
> usage under uml but is much smaller because only the mtd core is
> included. Compile-tested on i386, x86_64, um/i386, and um/x86_64.
> 
> > Instead, you should solve this problem in UML code. I do not know how,
> > but may be you can add readb/writeb there which actually do nothing or
> > print a scary warning, or do BUG(), and let things which use them just
> > fail run-time.
> 
> Something like this could work, but it would be error-prone for anyone
> else who attempts using iomem-requiring drivers on uml. Instead of
> getting obvious compile failures we'd have broken drivers that BUG() or
> emit scary warnings. That doesn't seem to me like an improvement.

This problem does not seem to be mtd-specific, right? So my point was
that it would be nicer to come up with a general solution.

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



From vapier.adi at gmail.com  Tue Dec 14 15:18:11 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 14 Dec 2010 15:18:11 -0500
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTim7-ZpO5nQ1Up=rxLJVbCLNJqfbiUGvSnsrONay@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
	<AANLkTikJ3UTQ-D01FX8fSEGgcuG-fXEhAw6h4z9pwkRX@mail.gmail.com>
	<AANLkTinBpNA9VGB3druyijTKVhK4aDLDc-f=MgKZ4NK6@mail.gmail.com>
	<AANLkTin7OwjwSyMbnOg+RnYEN5gd1Qzspn6RUE1vLzRR@mail.gmail.com>
	<AANLkTimNx5EqicJEAX_wZaz39paKusrDd4CemLcMQ3Qe@mail.gmail.com>
	<AANLkTi=w+zKPxdwWZ+-=8zbaagqjGPJyKRxOcku6kM7Y@mail.gmail.com>
	<AANLkTim-GWLaibEL1O=fcCcuG0qgrO2=qY1k_iKdxJQi@mail.gmail.com>
	<AANLkTikvRdCuPHkxt7=uz7MsVDugaZ4JRO=u_iVJfR4M@mail.gmail.com>
	<AANLkTincaN6in-9F-jUFygCx6-=DGW_9ju=Ve1QbXWSf@mail.gmail.com>
	<AANLkTimOmMNeg2Ni92CmaTt2RAk-m=HVSNdNuO8sTJ8q@mail.gmail.com>
	<AANLkTim7-ZpO5nQ1Up=rxLJVbCLNJqfbiUGvSnsrONay@mail.gmail.com>
Message-ID: <AANLkTikp7oFzYLVhtgh+jS1Y023FAns18rgP3p_TM4iA@mail.gmail.com>

On Tue, Dec 14, 2010 at 14:27, ?yvind Harboe wrote:
> This is the server, right?
>
> http://git.infradead.org/mtd-utils.git

yes
-mike


From jkrzyszt at tis.icnet.pl  Tue Dec 14 15:09:40 2010
From: jkrzyszt at tis.icnet.pl (Janusz Krzysztofik)
Date: Tue, 14 Dec 2010 21:09:40 +0100
Subject: [PATCH v2] MTD: NAND: ams-delta: convert to platform driver
In-Reply-To: <1292346023.2538.103.camel@localhost>
References: <201012111840.05270.jkrzyszt@tis.icnet.pl>
	<1292346023.2538.103.camel@localhost>
Message-ID: <201012142109.42784.jkrzyszt@tis.icnet.pl>

In its current form, the driver may interfere with different hardware on 
different boards if built into the kernel, hence is not suitable for 
inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and 
machine types.

Convert it to a platform driver, that should be free from this issue.

Created and tested against linux-2.6.37-rc5 on Amstrad Delta.

Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
---
Tuesday 14 December 2010 18:00:23 Artem Bityutskiy wrote:
> Sorry, but would it please be possible to split this few small patches -
> this one is too difficult to review, at least for me.

v1 -> v2 changes:
- remove any changes that were not essential for actually converting the 
  driver to a platform driver and modifying its user, ie. the Amstrad Delta 
  board, to register a corresponding platform device on startup,
- re-word the commit message a little bit.

 arch/arm/mach-omap1/board-ams-delta.c |    6 ++++++
 drivers/mtd/nand/ams-delta.c          |   31 ++++++++++++++++++++++++++-----
 2 files changed, 32 insertions(+), 5 deletions(-)

--- linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c.orig	2010-12-14 20:25:58.000000000 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c	2010-12-14 20:26:40.000000000 +0100
@@ -4,6 +4,7 @@
  *  Copyright (C) 2006 Jonathan McDowell <noodles at earth.li>
  *
  *  Derived from drivers/mtd/toto.c
+ *  Converted to platform driver by Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
  *
  * 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
@@ -151,7 +152,7 @@ static int ams_delta_nand_ready(struct m
 /*
  * Main initialization routine
  */
-static int __init ams_delta_init(void)
+static int __devinit ams_delta_init(struct platform_device *pdev)
 {
 	struct nand_chip *this;
 	int err = 0;
@@ -219,20 +222,40 @@ static int __init ams_delta_init(void)
 	return err;
 }
 
-module_init(ams_delta_init);
-
 /*
  * Clean up routine
  */
-static void __exit ams_delta_cleanup(void)
+static int __devexit ams_delta_cleanup(struct platform_device *pdev)
 {
 	/* Release resources, unregister device */
 	nand_release(ams_delta_mtd);
 
 	/* Free the MTD device structure */
 	kfree(ams_delta_mtd);
+
+	return 0;
+}
+
+static struct platform_driver ams_delta_nand_driver = {
+	.probe		= ams_delta_init,
+	.remove		= __devexit_p(ams_delta_cleanup),
+	.driver		= {
+		.name	= "ams-delta-nand",
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init ams_delta_nand_init(void)
+{
+	return platform_driver_register(&ams_delta_nand_driver);
+}
+module_init(ams_delta_nand_init);
+
+static void __exit ams_delta_nand_exit(void)
+{
+	platform_driver_unregister(&ams_delta_nand_driver);
 }
-module_exit(ams_delta_cleanup);
+module_exit(ams_delta_nand_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Jonathan McDowell <noodles at earth.li>");
--- linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig	2010-12-09 23:13:04.000000000 +0100
+++ linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c	2010-12-14 20:26:40.000000000 +0100
@@ -181,6 +181,11 @@ static struct omap_board_config_kernel a
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
+static struct platform_device ams_delta_nand_device = {
+	.name	= "ams-delta-nand",
+	.id	= -1
+};
+
 static struct resource ams_delta_kp_resources[] = {
 	[0] = {
 		.start	= INT_KEYBOARD,
@@ -273,6 +278,7 @@ void __init amsdelta_reserve(void)
 }
 
 static struct platform_device *ams_delta_devices[] __initdata = {
+	&ams_delta_nand_device,
 	&ams_delta_kp_device,
 	&ams_delta_lcd_device,
 	&ams_delta_led_device,



From geert at linux-m68k.org  Tue Dec 14 16:12:28 2010
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 14 Dec 2010 22:12:28 +0100
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292356893.29257.1.camel@koala>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org>
	<1292356893.29257.1.camel@koala>
Message-ID: <AANLkTim2i5e=5uioB8TQhpP9U9ZzSg=zLaH_xscP2Wmg@mail.gmail.com>

On Tue, Dec 14, 2010 at 21:01, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote:
>> On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote:
>> > But I think your solution is a bit dirty, because it adds a great deal
>> > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places.
>> > This is error-prone.
>>
>> The intent of that patch was to allow as much of the mtd subsystem to
>> compile as possible. My thinking was to try and rectify the fact that
>> uml has gone without mtd (and hence jffs2) support for years even though
>> much of it works just fine. I think the entire subsystem being marked
>> BROKEN in kconfig kept anyone from experimenting with it.
>>
>> The patch I sent was actually a reaction to feedback I got from Sam
>> Ravnborg on my last attempt (um, three years ago :/ ) in which he
>> suggested pushing down the ifdefs closer to their points of use. But I
>> agree, the minimal version has a much smaller footprint.
>>
>> The version below still meets the goal of allowing jffs2-on-block2mtd
>> usage under uml but is much smaller because only the mtd core is
>> included. Compile-tested on i386, x86_64, um/i386, and um/x86_64.
>>
>> > Instead, you should solve this problem in UML code. I do not know how,
>> > but may be you can add readb/writeb there which actually do nothing or
>> > print a scary warning, or do BUG(), and let things which use them just
>> > fail run-time.
>>
>> Something like this could work, but it would be error-prone for anyone
>> else who attempts using iomem-requiring drivers on uml. Instead of
>> getting obvious compile failures we'd have broken drivers that BUG() or
>> emit scary warnings. That doesn't seem to me like an improvement.
>
> This problem does not seem to be mtd-specific, right? So my point was
> that it would be nicer to come up with a general solution.

The generic solution for stuff that needs I/O operations is to mark it
"depends on HAS_IOMEM".

I used a similar patch in the past, IIRC to try axfs on UML.

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds


From lunz at acm.org  Tue Dec 14 16:23:49 2010
From: lunz at acm.org (Jason Lunz)
Date: Tue, 14 Dec 2010 13:23:49 -0800
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292356893.29257.1.camel@koala>
References: <20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org>
	<1292356893.29257.1.camel@koala>
Message-ID: <20101214212349.GA6937@falooley.org>


On one hand you've got uml, which simply doesn't have mmio. On the other
there's mtd, which began as a method for accessing hardware devices that
are often accessed using mmio. But then the mtd subsystem developed
emulations of that hardware that are software based and thus don't
require mmio. It's mainly these emulated backends I'm interested in
exposing.

Nothing is going to change so that it makes sense to have any real
mmio-using hardware driver run on uml. The question you raise is, are
there other classes of driver with a software-only subset that can be
exposed on uml? And if so, would adding stub implementations of
readb/writeb and friends actually be enough to make those work? I'm not
aware of any, so at present I don't think the argument for implementing
this in uml arch code is very strong. Or in other words, I don't think a
"general solution" would be very general.

Jason

On Tue, Dec 14, 2010 at 10:01:33PM +0200, Artem Bityutskiy wrote:
> This problem does not seem to be mtd-specific, right? So my point was
> that it would be nicer to come up with a general solution.


From tony at atomide.com  Tue Dec 14 17:28:21 2010
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 14 Dec 2010 14:28:21 -0800
Subject: [PATCH v2] MTD: NAND: ams-delta: convert to platform driver
In-Reply-To: <201012142109.42784.jkrzyszt@tis.icnet.pl>
References: <201012111840.05270.jkrzyszt@tis.icnet.pl>
	<1292346023.2538.103.camel@localhost>
	<201012142109.42784.jkrzyszt@tis.icnet.pl>
Message-ID: <20101214222821.GA14990@atomide.com>

* Janusz Krzysztofik <jkrzyszt at tis.icnet.pl> [101214 12:31]:
> In its current form, the driver may interfere with different hardware on 
> different boards if built into the kernel, hence is not suitable for 
> inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and 
> machine types.
> 
> Convert it to a platform driver, that should be free from this issue.
> 
> Created and tested against linux-2.6.37-rc5 on Amstrad Delta.

Good to see this happen, I assume this is for MTD. If not and you
want me to merge it instead, let me know.

Acked-by: Tony Lindgren <tony at atomide.com>


From rob at landley.net  Tue Dec 14 19:40:25 2010
From: rob at landley.net (Rob Landley)
Date: Tue, 14 Dec 2010 18:40:25 -0600
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101214212349.GA6937@falooley.org>
References: <20071024011712.GA3762@falooley.org>
	<1292356893.29257.1.camel@koala>
	<20101214212349.GA6937@falooley.org>
Message-ID: <201012141840.27529.rob@landley.net>

On Tuesday 14 December 2010 15:23:49 Jason Lunz wrote:
> On one hand you've got uml, which simply doesn't have mmio. On the other
> there's mtd, which began as a method for accessing hardware devices that
> are often accessed using mmio. But then the mtd subsystem developed
> emulations of that hardware that are software based and thus don't
> require mmio. It's mainly these emulated backends I'm interested in
> exposing.
>
> Nothing is going to change so that it makes sense to have any real
> mmio-using hardware driver run on uml. The question you raise is, are
> there other classes of driver with a software-only subset that can be
> exposed on uml? And if so, would adding stub implementations of
> readb/writeb and friends actually be enough to make those work? I'm not
> aware of any, so at present I don't think the argument for implementing
> this in uml arch code is very strong. Or in other words, I don't think a
> "general solution" would be very general.

For what it's worth, QEMU had replaced all my use cases for UML in the past 
few years.  If I wanted to play with loopback mounting jffs2 I'd build a kernel 
to run under QEMU, and have that emulate the flash.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


From rob at landley.net  Tue Dec 14 19:49:02 2010
From: rob at landley.net (Rob Landley)
Date: Tue, 14 Dec 2010 18:49:02 -0600
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292356893.29257.1.camel@koala>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20101214195124.GA6010@falooley.org>
	<1292356893.29257.1.camel@koala>
Message-ID: <201012141849.03926.rob@landley.net>

On Tuesday 14 December 2010 14:01:33 Artem Bityutskiy wrote:
> > > Instead, you should solve this problem in UML code. I do not know how,
> > > but may be you can add readb/writeb there which actually do nothing or
> > > print a scary warning, or do BUG(), and let things which use them just
> > > fail run-time.
> >
> > Something like this could work, but it would be error-prone for anyone
> > else who attempts using iomem-requiring drivers on uml. Instead of
> > getting obvious compile failures we'd have broken drivers that BUG() or
> > emit scary warnings. That doesn't seem to me like an improvement.
>
> This problem does not seem to be mtd-specific, right? So my point was
> that it would be nicer to come up with a general solution.

The problem is that jffs2 is a filesystem, and thus something people would 
really like to be able to loopback mount, but it's hardwired to assume it's 
only ever stored on a certain type of hardware, and thus requies incestuous 
knowledge of the erase granularity of the flash layer in order to function.

It would be really nice to have either the loopback driver or jffs2 be able to 
fake the mtd thing with some kind of "granularity=262144" option to let it 
know "you're not on flash right now, but the flash you'll eventually be on is 
X".  This might require padding the image at the beginning and being mounted 
with an offset if the filesystem doesn't start at the beginning of an erase 
block when copied to the final hardware, but losetup already supports offsets.

What any of this has to do with UML is an open question.  I don't want to 
require UML to loopback mount a jffs2 image, I want to be able to do it from my 
host.  From my perspective, you're solving the wrong problem.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


From lunz at acm.org  Tue Dec 14 20:19:05 2010
From: lunz at acm.org (Jason Lunz)
Date: Tue, 14 Dec 2010 17:19:05 -0800
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <201012141849.03926.rob@landley.net>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20101214195124.GA6010@falooley.org>
	<1292356893.29257.1.camel@koala>
	<201012141849.03926.rob@landley.net>
Message-ID: <20101215011904.GA24292@falooley.org>

On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote:
> The problem is that jffs2 is a filesystem, and thus something people would 
> really like to be able to loopback mount, but it's hardwired to assume it's 
> only ever stored on a certain type of hardware, and thus requies incestuous 
> knowledge of the erase granularity of the flash layer in order to function.

I assume you can turn your jffs2 image file into a block dev using
losetup, then turn the corresponding loop device into an mtd device
using block2mtd, at which point you ought to be able to mount it with
jffs2. I've never tried it.

> What any of this has to do with UML is an open question.  I don't want to 
> require UML to loopback mount a jffs2 image, I want to be able to do it from my 
> host.  From my perspective, you're solving the wrong problem.

There's more than just loopback-mounting jffs2 images. I use this to
make entire uml+jffs2 virtual machines for testing purposes.

Jason


From tony at atomide.com  Tue Dec 14 20:29:15 2010
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 14 Dec 2010 17:29:15 -0800
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds
	instead of nanoseconds
In-Reply-To: <20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101215012914.GE3190@atomide.com>

* Adrian Hunter <adrian.hunter at nokia.com> [101213 04:21]:
> From c52e0cdeedffb7a0f9818ad3d6296d1f51b8669d Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Thu, 9 Dec 2010 10:48:27 +0200
> Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
> 
> The calculations done with sync_clk are anyway in picoseconds
> and switching to picoseconds allows sync_clk values that are
> not a whole number of nanoseconds - which is sometimes the
> case.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
> ---
>  arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
>  arch/arm/mach-omap2/gpmc-onenand.c     |   10 +++++-----
>  arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
>  arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
>  arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
>  5 files changed, 24 insertions(+), 13 deletions(-)

Hmm I think I already replied to this.. But looks like not so here's
a new attempt..

This one you should send to linux-omap and linux-arm-kernel and
Cc Felipe Balbi so we can make sure the timing changes work
with tusb6010. Then we can ack it an it can go via the MTD
list.

Regards,

Tony


From liu.h.jason at gmail.com  Tue Dec 14 20:55:08 2010
From: liu.h.jason at gmail.com (Jason Liu)
Date: Wed, 15 Dec 2010 09:55:08 +0800
Subject: [PATCH 1/1] mtd: nand: add check for out of page read
In-Reply-To: <1292340409.2538.40.camel@localhost>
References: <1290156045-11719-1-git-send-email-r64343@freescale.com>
	<1292340409.2538.40.camel@localhost>
Message-ID: <AANLkTi=zB7UBjkvGYv_wdwZpH1Ghatn6eye1z5616h4X@mail.gmail.com>

Hi, Artem,

2010/12/14 Artem Bityutskiy <dedekind1 at gmail.com>:
> On Fri, 2010-11-19 at 16:40 +0800, Jason Liu wrote:
>> When run mtd_oobtest case, there will be one error for step(4),
>> which turned out it need add one check for out of page read in
>> nand_do_read_oob just like mtd_do_write_oob did it already.
>> This commit also fix one typo error for comments in mtd_do_write_oob
>>
>> Signed-off-by: Jason Liu <r64343 at freescale.com>
>
> I cannot reproduce this with nandsim, can you?
>
> I tried:
>
> 1. sudo modprobe nandsim
> ? sudo modprobe mtd_oobtest dev=0
>
> 2. sudo ./load_nandsim.sh 128 128 2048
> ? sudo modprobe mtd_oobtest dev=0
>
> In both cases the test passes: "mtd_oobtest: finished with 0 errors"
>
> And in 'nand_do_read_oob()' I see the following piece of code:
>
> ? ? ? ?/* Do not allow reads past end of device */
> ? ? ? ?if (unlikely(from >= mtd->size ||
> ? ? ? ? ? ? ? ? ? ? ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(from >> chip->page_shift)) * len)) {
> ? ? ? ? ? ? ? ?DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt read beyond end "
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"of device\n", __func__);
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}

Here the mtd->size in nand_base.c should be the NAND flash chip size,
while in nand_oobtest,

              /* Attempt to read off end of device */
                ops.mode      = MTD_OOB_AUTO;
                ops.len       = 0;
                ops.retlen    = 0;
                ops.ooblen    = mtd->ecclayout->oobavail;
                ops.oobretlen = 0;
                ops.ooboffs   = 1;
                ops.datbuf    = NULL;
                ops.oobbuf    = readbuf;
                printk(PRINT_PREF "attempting to read past end of device\n");
                printk(PRINT_PREF "an error is expected...\n");
                err = mtd->read_oob(mtd, mtd->size - mtd->writesize, &ops);
                if (err) {
                        printk(PRINT_PREF "error occurred as expected\n");
                        err = 0;
                } else {
                        printk(PRINT_PREF "error: read past end of device\n");
                        errcnt += 1;
                }
        }

here, mtd->size is mtd partition size right? when the mtd partition is
not the last MTD partition, the error will happen.

I have tested on real NAND, while not on nandsim.

>
> which should handle the case AFAICS.
>
> So, although I did think hard about this, it looks like there is no
> problem. What is the kernel version you are looking at? I checked it
> with my l2-mtd-2.6.git, which is the latest mtd-2.6.git plus a revert
> commit of your patch:
>
> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git

Yes, as I have written the email to you before in a private email to
tell that this patch has issue and please drop it.

Thanks,

>
> --
> Best Regards,
> Artem Bityutskiy (????? ????????)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>


From rob at landley.net  Wed Dec 15 01:31:18 2010
From: rob at landley.net (Rob Landley)
Date: Wed, 15 Dec 2010 00:31:18 -0600
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101215011904.GA24292@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<201012141849.03926.rob@landley.net>
	<20101215011904.GA24292@falooley.org>
Message-ID: <201012150031.21417.rob@landley.net>

On Tuesday 14 December 2010 19:19:05 Jason Lunz wrote:
> On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote:
> > The problem is that jffs2 is a filesystem, and thus something people
> > would really like to be able to loopback mount, but it's hardwired to
> > assume it's only ever stored on a certain type of hardware, and thus
> > requies incestuous knowledge of the erase granularity of the flash layer
> > in order to function.
>
> I assume you can turn your jffs2 image file into a block dev using
> losetup, then turn the corresponding loop device into an mtd device
> using block2mtd, at which point you ought to be able to mount it with
> jffs2. I've never tried it.

That is awesome and I'm not finding any documentation on it...  Ah:

  http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device

Wow that's awkward.  Let's see, that says...

  mknod /tmp/mtdblock0 b 31 0
  modprobe loop
  losetup /dev/loop0 rootfs.jffs2
  modprobe mtdblock
  modprobe block2mtd
  # Note the ,128KiB is needed (on 2.6.26 at least) to set the
  # eraseblock  size.
  echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd
  modprobe jffs2
  mount -t jffs2 /tmp/mtdblock0 /media/jffs2

So the system isn't automatically loading mtdblock, udev isn't creating any 
/dev nodes for it even thought it is for loop, the associations are created by 
writing strings into a filesystem with a _notoriously_ unstable API (and it 
expects a three letter mixed case suffix to specify units), and despite 
"mtdblock0" I have no idea how that echo syntax would specify more than one 
association at a time.

I'm trying to figure out whether creating a shell script for this or trying to 
modify the busybox mount command would be a better approach to beating some 
sort of usability out of doing this.

Hmmm, mkfs.jffs2 is named as a mkfs but acts a a generator ala genext2fs.  How 
about...

  mkdir empty
  mkfs.jffs2 -r empty -o rootfs.jffs2 -e 128 -l -n

And it created an empty (zero byte) file.  That's nice.  If I touch a file in 
"empty" now 116 bytes.  Adding -p makes it one erase block, but adding "-p 
2048" doesn't specify a multiple of the erase block size, it instead rounded 
rounded it _down_ to that many bytes.  But --pad=$((2048*1024*1024)) was 
apparently ignored...?  How do I specify a _size_ for this thing so it has 
empty space I can write into after the fact?  (The man page says pad with 
0xFF.  Am I going to have to do this by hand?)

  mkdir empty
  touch empty/hello
  mkfs.jffs2 -r empty -o temp.jffs2 -e 128 -l -n -p
  python -c "import sys; sys.stdout.write(131072*63*chr(0xff))" >> temp.jffs2
  losetup /dev/loop0 temp.jffs2
  echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd
  mount -t jffs2 mtdblock0 empty

Yay!  I have a filesystem!  And df claims it's 8 megabytes.

Woot.

> > What any of this has to do with UML is an open question.  I don't want to
> > require UML to loopback mount a jffs2 image, I want to be able to do it
> > from my host.  From my perspective, you're solving the wrong problem.
>
> There's more than just loopback-mounting jffs2 images. I use this to
> make entire uml+jffs2 virtual machines for testing purposes.

As I said, I'm almost exclusively using qemu/kvm these days, but this is 
fun...

> Jason

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


From adrian.hunter at nokia.com  Wed Dec 15 01:54:45 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Wed, 15 Dec 2010 08:54:45 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds
	instead of nanoseconds
In-Reply-To: <20101215012914.GE3190@atomide.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>
	<20101215012914.GE3190@atomide.com>
Message-ID: <4D086635.2010109@nokia.com>

>From c52e0cdeedffb7a0f9818ad3d6296d1f51b8669d Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter at nokia.com>
Date: Thu, 9 Dec 2010 10:48:27 +0200
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds

The calculations done with sync_clk are anyway in picoseconds
and switching to picoseconds allows sync_clk values that are
not a whole number of nanoseconds - which is sometimes the
case.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
  arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
  arch/arm/mach-omap2/gpmc-onenand.c     |   10 +++++-----
  arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
  arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
  arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
  5 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 7222096..2bb29c1 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -41,7 +41,7 @@ static int omap2_nand_gpmc_retime(void)
  		return 0;
  
  	memset(&t, 0, sizeof(t));
-	t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
+	t.sync_clk = gpmc_nand_data->gpmc_t->sync_clk;
  	t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_on);
  	t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->adv_on);
  
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 7bb6922..1db606c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -174,7 +174,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
  
  	switch (freq) {
  	case 83:
-		min_gpmc_clk_period = 12; /* 83 MHz */
+		min_gpmc_clk_period = 12000; /* 83 MHz */
  		t_ces   = 5;
  		t_avds  = 4;
  		t_avdh  = 2;
@@ -183,7 +183,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
  		t_rdyo  = 9;
  		break;
  	case 66:
-		min_gpmc_clk_period = 15; /* 66 MHz */
+		min_gpmc_clk_period = 15000; /* 66 MHz */
  		t_ces   = 6;
  		t_avds  = 5;
  		t_avdh  = 2;
@@ -192,7 +192,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
  		t_rdyo  = 11;
  		break;
  	default:
-		min_gpmc_clk_period = 18; /* 54 MHz */
+		min_gpmc_clk_period = 18500; /* 54 MHz */
  		t_ces   = 7;
  		t_avds  = 7;
  		t_avdh  = 7;
@@ -271,8 +271,8 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
  		t.wr_cycle  = t.rd_cycle;
  		if (cpu_is_omap34xx()) {
  			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ns_to_ticks(min_gpmc_clk_period +
-					t_rdyo));
+					gpmc_ps_to_ticks(min_gpmc_clk_period +
+					t_rdyo * 1000));
  			t.wr_access = t.access;
  		}
  	} else {
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..1b7b3e7 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -168,6 +168,16 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
  	return (time_ns * 1000 + tick_ps - 1) / tick_ps;
  }
  
+unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long tick_ps;
+
+	/* Calculate in picosecs to yield more exact results */
+	tick_ps = gpmc_get_fclk_period();
+
+	return (time_ps + tick_ps - 1) / tick_ps;
+}
+
  unsigned int gpmc_ticks_to_ns(unsigned int ticks)
  {
  	return ticks * gpmc_get_fclk_period() / 1000;
@@ -235,7 +245,7 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
  	int div;
  	u32 l;
  
-	l = sync_clk * 1000 + (gpmc_get_fclk_period() - 1);
+	l = sync_clk + (gpmc_get_fclk_period() - 1);
  	div = l / gpmc_get_fclk_period();
  	if (div > 4)
  		return -1;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 64a0112..1e998ea 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -120,8 +120,8 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
  	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
  
  	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 12 /* 11.1 nsec */;
-	tmp = (t.sync_clk * 1000 + fclk_ps - 1) / fclk_ps;
+	t.sync_clk = 11100 /* 11.1 nsec */;
+	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
  	if (tmp > 4)
  		return -ERANGE;
  	if (tmp <= 0)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..85ded59 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -80,12 +80,12 @@
  #define GPMC_PREFETCH_STATUS_COUNT(val)	(val & 0x00003fff)
  
  /*
- * Note that all values in this struct are in nanoseconds, while
- * the register values are in gpmc_fck cycles.
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
   */
  struct gpmc_timings {
-	/* Minimum clock period for synchronous mode */
-	u16 sync_clk;
+	/* Minimum clock period for synchronous mode (in picoseconds) */
+	u32 sync_clk;
  
  	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
  	u16 cs_on;		/* Assertion time */
@@ -117,6 +117,7 @@ struct gpmc_timings {
  };
  
  extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
+extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
  extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
  extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
  extern unsigned long gpmc_get_fclk_period(void);
-- 1.7.0.4


From adrian.hunter at nokia.com  Wed Dec 15 02:31:20 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Wed, 15 Dec 2010 09:31:20 +0200
Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to
	onenand_chip
In-Reply-To: <AANLkTi=0W8NuF3SNhWwjwDZtuCzyOM8219_pXG=9pU6O@mail.gmail.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>	<20101213122057.20685.68480.sendpatchset@ahunter-work.research.nokia.com>
	<AANLkTi=0W8NuF3SNhWwjwDZtuCzyOM8219_pXG=9pU6O@mail.gmail.com>
Message-ID: <4D086EC8.6030800@nokia.com>

On 14/12/10 02:17, Kyungmin Park wrote:
> Hi,
>
> Now I'm used the clock gating for OneNAND instead of regulator.
> so I think the mechanism is similar.

I am not sure what you are trying to say here.  We need the regulator
enable / disable to stop the regulator going to sleep (because it cannot
supply enough current when it is asleep) and also we need to call down to
the board level to set latency constraints.  These things seem pretty
specific to the OMAP driver hence the new enable() / disable() methods.

We do not need any clock gating.  The OneNAND clock is dealt with by
the OMAP GPMC OneNAND controller and GPMC has auto-idle / smart-idle
facilities that let OMAP gate clocks and power it off when it is not
being used.

>
> On Mon, Dec 13, 2010 at 9:20 PM, Adrian Hunter<adrian.hunter at nokia.com>  wrote:
>>  From 16b760999cb79f9cf71728c9253f1399717be63a Mon Sep 17 00:00:00 2001
>> From: Adrian Hunter<adrian.hunter at nokia.com>
>> Date: Fri, 19 Feb 2010 15:39:52 +0100
>> Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to onenand_chip
>>
>> Add enable / disable methods called from get_device() / release_device().
>> These can be used, for example, to allow the driver to prevent the voltage
>> regulator from being put to sleep while OneNAND is in use.
>>
>> Signed-off-by: Adrian Hunter<adrian.hunter at nokia.com>
>> ---
>>   drivers/mtd/onenand/onenand_base.c |    4 ++++
>>   include/linux/mtd/onenand.h        |    2 ++
>>   2 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
>> index c38bf9c..bde274f 100644
>> --- a/drivers/mtd/onenand/onenand_base.c
>> +++ b/drivers/mtd/onenand/onenand_base.c
>> @@ -948,6 +948,8 @@ static int onenand_get_device(struct mtd_info *mtd, int new_state)
>>                 if (this->state == FL_READY) {
>>                         this->state = new_state;
>>                         spin_unlock(&this->chip_lock);
>> +                       if (this->enable)
>> +                               this->enable(mtd);
>>                         break;
>>                 }
>>                 if (new_state == FL_PM_SUSPENDED) {
>
> I put the code the end of function like:
>
> static int onenand_get_device(struct mtd_info *mtd, int new_state)
> {
>          struct onenand_chip *this = mtd->priv;
>          DECLARE_WAITQUEUE(wait, current);
>
>          /*
>           * Grab the lock and see if the device is available
>           */
>          while (1) {
>                  spin_lock(&this->chip_lock);
>                  if (this->state == FL_READY) {
>                          this->state = new_state;
>                          spin_unlock(&this->chip_lock);
>                          break;
>                  }
>                  if (new_state == FL_PM_SUSPENDED) {
>                          spin_unlock(&this->chip_lock);
>                          return (this->state == FL_PM_SUSPENDED) ? 0 : -EAGAIN;
>                  }
>                  set_current_state(TASK_UNINTERRUPTIBLE);
>                  add_wait_queue(&this->wq,&wait);
>                  spin_unlock(&this->chip_lock);
>                  schedule();
>                  remove_wait_queue(&this->wq,&wait);
>          }
>
>          if (this->clk)
>                  clk_enable(this->clk);
>
>          return 0;
> }
>
>
>> @@ -974,6 +976,8 @@ static void onenand_release_device(struct mtd_info *mtd)
>>   {
>>         struct onenand_chip *this = mtd->priv;
>>
>> +       if (this->state != FL_PM_SUSPENDED&&  this->disable)
>> +               this->disable(mtd);
> Need to check the SUSPENDED at here? when enter the suspend get_device
> is called.
> release device is called when resume. so no need to check
> FL_PM_SUSPENDED in my case.

onenand-get_device should have had:

	if (new_state != FL_PM_SUSPENDED && this->enable)
		this->enable(mtd);

I will resend the patch.


>
>>         /* Release the chip */
>>         spin_lock(&this->chip_lock);
>>         this->state = FL_READY;
>
> and put the same as like:
>
> static void onenand_release_device(struct mtd_info *mtd)
> {
>          struct onenand_chip *this = mtd->priv;
>
>          /* Release the chip */
>          spin_lock(&this->chip_lock);
>          this->state = FL_READY;
>          wake_up(&this->wq);
>          spin_unlock(&this->chip_lock);
>
>          if (this->clk)
>                  clk_disable(this->clk);
> }
>
> Thank you,
> Kyungmin Park
>
>> diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
>> index 6da3fe3..ae418e4 100644
>> --- a/include/linux/mtd/onenand.h
>> +++ b/include/linux/mtd/onenand.h
>> @@ -118,6 +118,8 @@ struct onenand_chip {
>>         int (*chip_probe)(struct mtd_info *mtd);
>>         int (*block_markbad)(struct mtd_info *mtd, loff_t ofs);
>>         int (*scan_bbt)(struct mtd_info *mtd);
>> +       int (*enable)(struct mtd_info *mtd);
>> +       int (*disable)(struct mtd_info *mtd);
>>
>>         struct completion       complete;
>>         int                     irq;
>> --
>> 1.7.0.4
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>



From ricard.wanderlof at axis.com  Wed Dec 15 03:06:56 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Wed, 15 Dec 2010 09:06:56 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
Message-ID: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>


Hi,

I've looked through the documentation on 
http://www.linux-mtd.infradead.org but I can't find the answer to the 
following question(s):

Using 'static' UBI volumes seems to be the preferred way of creating read 
only file systems.

While it seems possible to use ubinize to make a complete ubi image 
containing static volumes and then write it to the flash using ubiformat, 
is it possible to update just a single volume using ubiupdatevol?

I've tried using ubimkvol to create a static volume, then using 
ubiupdatevol to write an ubifs image to it. That works, but when I try to 
mount it subsequently I get things like

[ 6656.114000] UBIFS: static UBI volume - read-only mode
[ 6656.129000] UBIFS error (pid 866): mount_ubifs: can't format empty UBI 
volume: read-only UBI volume
mount: mounting ubi1_0 on /volume1/ failed: Read-only file system

which in a way makes sense to me; if the volume is static = read only then 
it shouldn't be possible to write to it.

The only thing I haven't tried is matching the size of the image I'm 
writing to the size of the partition. With dynamic volumes that doesn't 
seem to be an issue; as long as there is space for the data in the target 
volume. The free space just seems to get truncated to the available free 
space in the flash volume. (On the other hand, writing an image that is 
smaller than the flash volume doesn't seem to 'grow' to fit the available 
space according to df; it remains the same no matter how large the target 
volume is). So I've been rather careless with the size of the image vs. 
the size of the target volume.

A related question: With static volumes, I assume you still get the 
benefit of scrubbing, which in turn means that UBI can move the data 
around if it deems necessary?

Which begs a final question: is it possible to verify the integrity of a 
static UBI volume? Even with JFFS2, if mounted readonly the flash in that 
particular partition is never written to, so it is possible to use a 
simple checksum to verify data integrity. With JFFS2 this can be 
important, as missing JFFS2 nodes don't necessarily result in mount time 
or run time failures, it just results in missing files or parts of files.

/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 geert at linux-m68k.org  Wed Dec 15 03:18:33 2010
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 15 Dec 2010 09:18:33 +0100
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101215011904.GA24292@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20101214195124.GA6010@falooley.org>
	<1292356893.29257.1.camel@koala>
	<201012141849.03926.rob@landley.net>
	<20101215011904.GA24292@falooley.org>
Message-ID: <AANLkTinaXvc=3r9gRNkSnttay-2yD9BDtXo0mOmMff0H@mail.gmail.com>

On Wed, Dec 15, 2010 at 02:19, Jason Lunz <lunz at acm.org> wrote:
> On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote:
>> The problem is that jffs2 is a filesystem, and thus something people would
>> really like to be able to loopback mount, but it's hardwired to assume it's
>> only ever stored on a certain type of hardware, and thus requies incestuous
>> knowledge of the erase granularity of the flash layer in order to function.
>
> I assume you can turn your jffs2 image file into a block dev using
> losetup, then turn the corresponding loop device into an mtd device
> using block2mtd, at which point you ought to be able to mount it with
> jffs2. I've never tried it.

And block2mtd is part of mtd, so you have to get mtd compiled first.

BTW, the patch I used in the past was less intrusive than yours.
I attached it, as I can't send it inline from here.
Note that it was against 2.6.31-rc4.

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uml-mtd.diff
Type: text/x-patch
Size: 3088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101215/123d77c6/attachment.bin>

From dedekind1 at gmail.com  Wed Dec 15 04:24:21 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 11:24:21 +0200
Subject: About NAND Simulator question
In-Reply-To: <AANLkTimDuh_HOpBfSQf9nC5N0wQBh0Zb3aBz49o0Kk26@mail.gmail.com>
References: <AANLkTimDuh_HOpBfSQf9nC5N0wQBh0Zb3aBz49o0Kk26@mail.gmail.com>
Message-ID: <1292405061.2512.26.camel@localhost>

Hi,

please, send all e-mails concerning nandsim to
linux-mtd at lists.infradead.org, you can also CC me, I prefer using "Artem
Bityutskiy <dedekind1 at gmail.com>"

On Tue, 2010-11-30 at 17:57 +0800, ??? wrote:
> When i read your code,I can understand the Simulator has file-base and
> RAM-backed emulation

Yes.

> But I have question is weather the file-base emulation can simulate
> the flash memory's performance.

No, I do not think so. Originally I added some things like delays
emulation, but then never used that, and I do not think that is correct.
I think we better remove that functionality to confuse people less. Or
someone should actually fix that.

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



From dedekind1 at gmail.com  Wed Dec 15 04:37:45 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 11:37:45 +0200
Subject: [PATCH v2] MTD: NAND: ams-delta: convert to platform driver
In-Reply-To: <201012142109.42784.jkrzyszt@tis.icnet.pl>
References: <201012111840.05270.jkrzyszt@tis.icnet.pl>
	<1292346023.2538.103.camel@localhost>
	<201012142109.42784.jkrzyszt@tis.icnet.pl>
Message-ID: <1292405865.2512.28.camel@localhost>

On Tue, 2010-12-14 at 21:09 +0100, Janusz Krzysztofik wrote:
> In its current form, the driver may interfere with different hardware on 
> different boards if built into the kernel, hence is not suitable for 
> inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and 
> machine types.
> 
> Convert it to a platform driver, that should be free from this issue.
> 
> Created and tested against linux-2.6.37-rc5 on Amstrad Delta.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>

Pushed to l2-mtd-2.6.git, thanks!

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



From dedekind1 at gmail.com  Wed Dec 15 04:40:51 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 11:40:51 +0200
Subject: [PATCH 1/2] mtd: nand: choose correct chip name (ONFI bug)
In-Reply-To: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
References: <1292142213-645-1-git-send-email-computersforpeace@gmail.com>
Message-ID: <1292406051.2512.29.camel@localhost>

On Sun, 2010-12-12 at 00:23 -0800, Brian Norris wrote:
> We have the order of the conditional wrong for choosing the ONFI chip name
> vs. the ID table name. Without this fix, we will almost *always* choose a
> NULL string to print out instead of the correct one.
> 
> This has already been suggested by Matthieu Castet.
> 
> Signed-off-by: Brian Norris <computersforpeace at gmail.com>

Pushed both to l2-mtd-2.6.git, thanks!

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



From adrian.hunter at nokia.com  Wed Dec 15 04:33:53 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Wed, 15 Dec 2010 11:33:53 +0200
Subject: [PATCH 2/7] mtd: OneNAND: add enable / disable methods to
	onenand_chip
In-Reply-To: <AANLkTi=0W8NuF3SNhWwjwDZtuCzyOM8219_pXG=9pU6O@mail.gmail.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>	<20101213122057.20685.68480.sendpatchset@ahunter-work.research.nokia.com>
	<AANLkTi=0W8NuF3SNhWwjwDZtuCzyOM8219_pXG=9pU6O@mail.gmail.com>
Message-ID: <4D088B81.2000804@nokia.com>


 From ece28a7fdec36fb40d60d35a5639326871c162f6 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter at nokia.com>
Date: Fri, 19 Feb 2010 15:39:52 +0100
Subject: [PATCH V2 2/7] mtd: OneNAND: add enable / disable methods to onenand_chip

Add enable / disable methods called from get_device() / release_device().
These can be used, for example, to allow the driver to prevent the voltage
regulator from being put to sleep while OneNAND is in use.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
  drivers/mtd/onenand/onenand_base.c |    4 ++++
  include/linux/mtd/onenand.h        |    2 ++
  2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index c38bf9c..5639e43 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -948,6 +948,8 @@ static int onenand_get_device(struct mtd_info *mtd, int new_state)
  		if (this->state == FL_READY) {
  			this->state = new_state;
  			spin_unlock(&this->chip_lock);
+			if (new_state != FL_PM_SUSPENDED && this->enable)
+				this->enable(mtd);
  			break;
  		}
  		if (new_state == FL_PM_SUSPENDED) {
@@ -974,6 +976,8 @@ static void onenand_release_device(struct mtd_info *mtd)
  {
  	struct onenand_chip *this = mtd->priv;
  
+	if (this->state != FL_PM_SUSPENDED && this->disable)
+		this->disable(mtd);
  	/* Release the chip */
  	spin_lock(&this->chip_lock);
  	this->state = FL_READY;
diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
index 6da3fe3..ae418e4 100644
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -118,6 +118,8 @@ struct onenand_chip {
  	int (*chip_probe)(struct mtd_info *mtd);
  	int (*block_markbad)(struct mtd_info *mtd, loff_t ofs);
  	int (*scan_bbt)(struct mtd_info *mtd);
+	int (*enable)(struct mtd_info *mtd);
+	int (*disable)(struct mtd_info *mtd);
  
  	struct completion	complete;
  	int			irq;
-- 
1.7.0.4


From ricard.wanderlof at axis.com  Wed Dec 15 05:43:38 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Wed, 15 Dec 2010 11:43:38 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
Message-ID: <Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>


On Wed, 15 Dec 2010, Ricard Wanderlof wrote:

> I've tried using ubimkvol to create a static volume, then using
> ubiupdatevol to write an ubifs image to it. That works, but when I try to
> mount it subsequently I get things like
>
> [ 6656.114000] UBIFS: static UBI volume - read-only mode
> [ 6656.129000] UBIFS error (pid 866): mount_ubifs: can't format empty UBI
> volume: read-only UBI volume
> mount: mounting ubi1_0 on /volume1/ failed: Read-only file system

I don't know if I screwed up big time when I was trying this out before, 
it seems to work fine now just as well as with dynamic volumes. I don't 
know if I was doing ubiupdatevol to the wrong volume (which would explain 
the above error message) or what.

I'd still like to get some input on the other two questions in my previous 
email though...

> A related question: With static volumes, I assume you still get the
> benefit of scrubbing, which in turn means that UBI can move the data
> around if it deems necessary?
>
> Which begs a final question: is it possible to verify the integrity of a
> static UBI volume? Even with JFFS2, if mounted readonly the flash in that
> particular partition is never written to, so it is possible to use a
> simple checksum to verify data integrity. With JFFS2 this can be
> important, as missing JFFS2 nodes don't necessarily result in mount time
> or run time failures, it just results in missing files or parts of files.

I'm also wondering if anyone has any thoughts on upgrading a 'live' 
system, when the flash is managed by UBI.

With a system based on mtd+jffs2 it is actually possible to reflash the 
partition with the [read only] root file system on it without unmounting, 
as long as no accesses are made to the physical flash during the rewrite 
or afterwards. In other words, immediately after reflashing the system 
must be rebooted.

However, with UBI, given that there are background threads which might be 
doing garbage collection etc I'm suspecting such a solution might not be 
as suitable when the flash is managed by UBI. Or is there a some solution 
that someone has tried with any level of success?

/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 nicolas.ferre at atmel.com  Wed Dec 15 06:59:32 2010
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 15 Dec 2010 12:59:32 +0100
Subject: [PATCH] MTD: m25p80: add debugging trace in sst_write()
Message-ID: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>

Add a DEBUG(MTD_DEBUG_LEVEL2, ..) trace at beginning of sst_write() function as
it is done in m25p80_write() function.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/mtd/devices/m25p80.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index bf5a002..e6b5707 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -482,6 +482,10 @@ static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
 	size_t actual;
 	int cmd_sz, ret;
 
+	DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
+			dev_name(&flash->spi->dev), __func__, "to",
+			(u32)to, len);
+
 	*retlen = 0;
 
 	/* sanity checks */
-- 
1.7.3



From jkrzyszt at tis.icnet.pl  Wed Dec 15 06:58:15 2010
From: jkrzyszt at tis.icnet.pl (Janusz Krzysztofik)
Date: Wed, 15 Dec 2010 12:58:15 +0100
Subject: [PATCH] MTD: NAND: ams-delta: select for built-in by default
Message-ID: <201012151258.16764.jkrzyszt@tis.icnet.pl>

Now that the Amstrad Delta NAND driver is converted to a platform driver, 
which prevents it from interfering with other unrelated hardware in multiple 
OMAP1 cpu and machine configurations, it can be automatically configured for 
being built into the kernel if the Amstrad Delta board is also selected.

Created against linux-2.6.37-rc5.

Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
---

 drivers/mtd/nand/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.37-rc5/drivers/mtd/nand/Kconfig.orig	2010-12-09 23:08:16.000000000 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/Kconfig	2010-12-11 15:58:12.000000000 +0100
@@ -96,6 +96,7 @@ config MTD_NAND_SPIA
 config MTD_NAND_AMS_DELTA
 	tristate "NAND Flash device on Amstrad E3"
 	depends on MACH_AMS_DELTA
+	default y
 	help
 	  Support for NAND flash on Amstrad E3 (Delta).
 


From sshtylyov at mvista.com  Wed Dec 15 08:25:28 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 15 Dec 2010 16:25:28 +0300
Subject: [PATCH] MTD: m25p80: add debugging trace in sst_write()
In-Reply-To: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
References: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <4D08C1C8.3090100@ru.mvista.com>

Hello.

On 15-12-2010 14:59, Nicolas Ferre wrote:

> Add a DEBUG(MTD_DEBUG_LEVEL2, ..) trace at beginning of sst_write() function as
> it is done in m25p80_write() function.

> Signed-off-by: Nicolas Ferre<nicolas.ferre at atmel.com>
[...]

> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index bf5a002..e6b5707 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -482,6 +482,10 @@ static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
>   	size_t actual;
>   	int cmd_sz, ret;
>
> +	DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
> +			dev_name(&flash->spi->dev), __func__, "to",

    What's the point of printing "to" as variable? :-)

> +			(u32)to, len);
> +

WBR, Sergei


From nicolas.ferre at atmel.com  Wed Dec 15 08:43:55 2010
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 15 Dec 2010 14:43:55 +0100
Subject: [PATCH] MTD: m25p80: add debugging trace in sst_write()
In-Reply-To: <4D08C1C8.3090100@ru.mvista.com>
References: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
	<4D08C1C8.3090100@ru.mvista.com>
Message-ID: <4D08C61B.8010006@atmel.com>

Le 15/12/2010 14:25, Sergei Shtylyov :
> Hello.
> 
> On 15-12-2010 14:59, Nicolas Ferre wrote:
> 
>> Add a DEBUG(MTD_DEBUG_LEVEL2, ..) trace at beginning of sst_write()
>> function as
>> it is done in m25p80_write() function.
> 
>> Signed-off-by: Nicolas Ferre<nicolas.ferre at atmel.com>
> [...]
> 
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index bf5a002..e6b5707 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -482,6 +482,10 @@ static int sst_write(struct mtd_info *mtd, loff_t
>> to, size_t len,
>>       size_t actual;
>>       int cmd_sz, ret;
>>
>> +    DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
>> +            dev_name(&flash->spi->dev), __func__, "to",
> 
>    What's the point of printing "to" as variable? :-)

Good question... Maybe a way to have the same shape of messages...

In my patch it is for sure to comply with this driver way of dealing
with DEBUG messages.
It is "to" in this function like its sister m25p80_write(). But it is
also "from" or "at" in others...

>> +            (u32)to, len);
>> +

Cheers,
-- 
Nicolas Ferre


From dedekind1 at gmail.com  Wed Dec 15 08:58:01 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 15:58:01 +0200
Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
In-Reply-To: <20101213122128.20685.9312.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122128.20685.9312.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <1292421481.2512.52.camel@localhost>

On Mon, 2010-12-13 at 14:21 +0200, Adrian Hunter wrote:
> From 5fa7a6377683aabd617f78518cd6cd49eae1679e Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Fri, 10 Dec 2010 12:04:20 +0200
> Subject: [PATCH 7/7] mtd: OneNAND: lighten scary initial bad block messages
> 
> Initial bad blocks are normal but the messages look like
> errors.  Make the messages less scary, make the main
> message an informational message not a warning, make the
> message displaying registers a debug message and include
> the address there instead of in the informational message.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>

Pushed this one to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Wed Dec 15 09:04:29 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 16:04:29 +0200
Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command
	line partitioning
In-Reply-To: <20101213122051.20685.46383.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122051.20685.46383.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <1292421869.2512.56.camel@localhost>

On Mon, 2010-12-13 at 14:20 +0200, Adrian Hunter wrote:
> From d27a88c5f9f18a7c38784c085889c3e1053340cf Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Wed, 30 Dec 2009 07:40:16 +0100
> Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command line partitioning
> 
> Add the ability to parse MTD partition information from the
> kernel command line.
> 
> Note that a pointless BUG_ON is removed, as are redundant
> calls to 'del_mtd_partitions()' and 'del_mtd_device()'
> because they are also done by 'onenand_release()'.
> 
> Finally note that 'add_mtd_device()' returns 1 on failure
> so the error condition was incorrect.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>

I've pushed patches 1 and 7 to l2-mtd-2.6, but patch #2 is not
applicable. I think this is because of changes Kyungmin made recently.
Could you please re-send patches 2 and 3 on top of the l2 tree?

I guess I can apply 2 and 3 now. Patch 4 should wait for comments from
Tony, AFAICS. Patches 5 and 6 are dependent, and hence should wait as
well, AFAICS.

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



From dedekind1 at gmail.com  Wed Dec 15 09:06:46 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 15 Dec 2010 16:06:46 +0200
Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command
	line partitioning
In-Reply-To: <20101213122051.20685.46383.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122051.20685.46383.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <1292422006.2512.57.camel@localhost>

On Mon, 2010-12-13 at 14:20 +0200, Adrian Hunter wrote:
> From d27a88c5f9f18a7c38784c085889c3e1053340cf Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Wed, 30 Dec 2009 07:40:16 +0100
> Subject: [PATCH 1/7] mtd: OneNAND: OMAP2/3: add support for command line partitioning
> 
> Add the ability to parse MTD partition information from the
> kernel command line.
> 
> Note that a pointless BUG_ON is removed, as are redundant
> calls to 'del_mtd_partitions()' and 'del_mtd_device()'
> because they are also done by 'onenand_release()'.
> 
> Finally note that 'add_mtd_device()' returns 1 on failure
> so the error condition was incorrect.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>

Pushed this one to l2-mtd-2.6.git, thank you.

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



From jkrzyszt at tis.icnet.pl  Wed Dec 15 09:43:44 2010
From: jkrzyszt at tis.icnet.pl (Janusz Krzysztofik)
Date: Wed, 15 Dec 2010 15:43:44 +0100
Subject: [PATCH] MTD: NAND: ams-delta: drop omap_read/write, use ioremap
Message-ID: <201012151543.46341.jkrzyszt@tis.icnet.pl>

There is a common requirement for not using OMAP specific omap_readw() / 
omap_writew() function calls in drivers/, but replace them with 
readw() / writew() on ioremap()ped addresses passed from arch/ instead.

The patch implements this idea for the Amstrad Delta NAND driver. To be 
able to use the modified driver, the board file is updated with the 
platform device I/O resource declaration, which is passed from there.

Created and tested against linux-2.6.37-rc5, on top of recent patch 
'MTD: NAND: ams-delta: convert to platform driver'.

Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
---
There is one issue indicated by checkpatch.pl --strict:

  ERROR: space prohibited after that '-' (ctx:WxW)
  #120: FILE: arch/arm/mach-omap1/board-ams-delta.c:188:
  +                               OMAP_MPUIO_IO_CNTL + sizeof(u32) - 1,
                                                                   ^
but this looks like a false positive to me.

 arch/arm/mach-omap1/board-ams-delta.c |   13 ++++++++-
 drivers/mtd/nand/ams-delta.c          |   49 +++++++++++++++++++++++++++++-----
 2 files changed, 55 insertions(+), 7 deletions(-)

--- linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c.orig	2010-12-14 20:58:37.000000000 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c	2010-12-15 15:36:36.000000000 +0100
@@ -5,6 +5,7 @@
  *
  *  Derived from drivers/mtd/toto.c
  *  Converted to platform driver by Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
+ *  Partially stolen from drivers/mtd/nand/plat_nand.c
  *
  * 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
@@ -63,9 +64,10 @@ static struct mtd_partition partition_in
 static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
 {
 	struct nand_chip *this = mtd->priv;
+	void __iomem *io_base = this->priv;
 
-	omap_writew(0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
-	omap_writew(byte, this->IO_ADDR_W);
+	writew(0, io_base + OMAP_MPUIO_IO_CNTL);
+	writew(byte, this->IO_ADDR_W);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
 	ndelay(40);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
@@ -76,11 +78,12 @@ static u_char ams_delta_read_byte(struct
 {
 	u_char res;
 	struct nand_chip *this = mtd->priv;
+	void __iomem *io_base = this->priv;
 
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE, 0);
 	ndelay(40);
-	omap_writew(~0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
-	res = omap_readw(this->IO_ADDR_R);
+	writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
+	res = readw(this->IO_ADDR_R);
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE,
 			       AMS_DELTA_LATCH2_NAND_NRE);
 
@@ -155,8 +158,13 @@ static int ams_delta_nand_ready(struct m
 static int __devinit ams_delta_init(struct platform_device *pdev)
 {
 	struct nand_chip *this;
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	void __iomem *io_base;
 	int err = 0;
 
+	if (!res)
+		return -ENXIO;
+
 	/* Allocate memory for MTD device structure and private data */
 	ams_delta_mtd = kmalloc(sizeof(struct mtd_info) +
 				sizeof(struct nand_chip), GFP_KERNEL);
@@ -178,9 +186,25 @@ static int __devinit ams_delta_init(stru
 	/* Link the private data with the MTD structure */
 	ams_delta_mtd->priv = this;
 
+	if (!request_mem_region(res->start, resource_size(res),
+			dev_name(&pdev->dev))) {
+		dev_err(&pdev->dev, "request_mem_region failed\n");
+		err = -EBUSY;
+		goto out_free;
+	}
+
+	io_base = ioremap(res->start, resource_size(res));
+	if (io_base == NULL) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		err = -EIO;
+		goto out_release_io;
+	}
+
+	this->priv = io_base;
+
 	/* Set address of NAND IO lines */
-	this->IO_ADDR_R = (OMAP1_MPUIO_BASE + OMAP_MPUIO_INPUT_LATCH);
-	this->IO_ADDR_W = (OMAP1_MPUIO_BASE + OMAP_MPUIO_OUTPUT);
+	this->IO_ADDR_R = io_base + OMAP_MPUIO_INPUT_LATCH;
+	this->IO_ADDR_W = io_base + OMAP_MPUIO_OUTPUT;
 	this->read_byte = ams_delta_read_byte;
 	this->write_buf = ams_delta_write_buf;
 	this->read_buf = ams_delta_read_buf;
@@ -196,6 +220,8 @@ static int __devinit ams_delta_init(stru
 	this->chip_delay = 30;
 	this->ecc.mode = NAND_ECC_SOFT;
 
+	platform_set_drvdata(pdev, io_base);
+
 	/* Set chip enabled, but  */
 	ams_delta_latch2_write(NAND_MASK, AMS_DELTA_LATCH2_NAND_NRE |
 					  AMS_DELTA_LATCH2_NAND_NWE |
@@ -215,6 +241,11 @@ static int __devinit ams_delta_init(stru
 	goto out;
 
  out_mtd:
+	platform_set_drvdata(pdev, NULL);
+	iounmap(io_base);
+out_release_io:
+	release_mem_region(res->start, resource_size(res));
+out_free:
 	kfree(ams_delta_mtd);
  out:
 	return err;
@@ -225,9 +256,15 @@ static int __devinit ams_delta_init(stru
  */
 static int __devexit ams_delta_cleanup(struct platform_device *pdev)
 {
+	void __iomem *io_base = platform_get_drvdata(pdev);
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
 	/* Release resources, unregister device */
 	nand_release(ams_delta_mtd);
 
+	iounmap(io_base);
+	release_mem_region(res->start, resource_size(res));
+
 	/* Free the MTD device structure */
 	kfree(ams_delta_mtd);
 
--- linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig	2010-12-14 20:58:37.000000000 +0100
+++ linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c	2010-12-15 15:26:49.000000000 +0100
@@ -181,9 +181,20 @@ static struct omap_board_config_kernel a
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
+static struct resource ams_delta_nand_resources[] = {
+	[0] = {
+		.start	= OMAP1_MPUIO_BASE,
+		.end	= OMAP1_MPUIO_BASE +
+				OMAP_MPUIO_IO_CNTL + sizeof(u32) - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
 static struct platform_device ams_delta_nand_device = {
 	.name	= "ams-delta-nand",
-	.id	= -1
+	.id	= -1,
+	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
+	.resource	= ams_delta_nand_resources,
 };
 
 static struct resource ams_delta_kp_resources[] = {


From linux at arm.linux.org.uk  Wed Dec 15 11:12:13 2010
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 15 Dec 2010 16:12:13 +0000
Subject: [PATCH] MTD: m25p80: add debugging trace in sst_write()
In-Reply-To: <4D08C1C8.3090100@ru.mvista.com>
References: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
	<4D08C1C8.3090100@ru.mvista.com>
Message-ID: <20101215161213.GC9937@n2100.arm.linux.org.uk>

On Wed, Dec 15, 2010 at 04:25:28PM +0300, Sergei Shtylyov wrote:
>> +	DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
>> +			dev_name(&flash->spi->dev), __func__, "to",
>
>    What's the point of printing "to" as variable? :-)

One valid reason to do this is if you have several formatting strings
all the same.  GCC can merge identical strings together.

So, if you have:

 "%s: %s %s 0x%08x, len %zd", dev_name(), __func__, "to"
 "%s: %s %s 0x%08x, len %zd", dev_name(), __func__, "from"
 "%s: %s %s 0x%08x, len %zd", dev_name(), __func__, "foo"

Then you end up with one long string and three short strings instead of

 "%s: %s to 0x%08x, len %zd", dev_name(), __func__
 "%s: %s from 0x%08x, len %zd", dev_name(), __func__
 "%s: %s foo 0x%08x, len %zd", dev_name(), __func__

which'd be three long strings.


From dedekind1 at gmail.com  Thu Dec 16 10:18:31 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 16 Dec 2010 17:18:31 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <201012150031.21417.rob@landley.net>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<201012141849.03926.rob@landley.net>
	<20101215011904.GA24292@falooley.org>
	<201012150031.21417.rob@landley.net>
Message-ID: <1292512711.2364.85.camel@localhost>

On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote:
> That is awesome and I'm not finding any documentation on it...  Ah:
> 
>   http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device
> 
> Wow that's awkward.  Let's see, that says...
> 
>   mknod /tmp/mtdblock0 b 31 0
>   modprobe loop
>   losetup /dev/loop0 rootfs.jffs2
>   modprobe mtdblock
>   modprobe block2mtd
>   # Note the ,128KiB is needed (on 2.6.26 at least) to set the
>   # eraseblock  size.
>   echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd
>   modprobe jffs2
>   mount -t jffs2 /tmp/mtdblock0 /media/jffs2

You should not need mtdblock in modern kernels, it is legacy. You should
be abole to mount jffs2 on top of mtd0 with

mount -t jffs2 mtd0 /media/jffs2

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



From dedekind1 at gmail.com  Thu Dec 16 10:25:06 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 16 Dec 2010 17:25:06 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101214195124.GA6010@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org>
Message-ID: <1292513106.2364.86.camel@localhost>

On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote:
> On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote:
> > But I think your solution is a bit dirty, because it adds a great deal
> > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places.
> > This is error-prone.
> 
> The intent of that patch was to allow as much of the mtd subsystem to
> compile as possible. My thinking was to try and rectify the fact that
> uml has gone without mtd (and hence jffs2) support for years even though
> much of it works just fine. I think the entire subsystem being marked
> BROKEN in kconfig kept anyone from experimenting with it.
> 
> The patch I sent was actually a reaction to feedback I got from Sam
> Ravnborg on my last attempt (um, three years ago :/ ) in which he
> suggested pushing down the ifdefs closer to their points of use. But I
> agree, the minimal version has a much smaller footprint.
> 
> The version below still meets the goal of allowing jffs2-on-block2mtd
> usage under uml but is much smaller because only the mtd core is
> included. Compile-tested on i386, x86_64, um/i386, and um/x86_64.
> 
> > Instead, you should solve this problem in UML code. I do not know how,
> > but may be you can add readb/writeb there which actually do nothing or
> > print a scary warning, or do BUG(), and let things which use them just
> > fail run-time.
> 
> Something like this could work, but it would be error-prone for anyone
> else who attempts using iomem-requiring drivers on uml. Instead of
> getting obvious compile failures we'd have broken drivers that BUG() or
> emit scary warnings. That doesn't seem to me like an improvement.

OK, pushed this patch to l2-mtd-2.6.git.

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



From dedekind1 at gmail.com  Thu Dec 16 11:19:13 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 16 Dec 2010 18:19:13 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
Message-ID: <1292516353.2364.101.camel@localhost>

On Wed, 2010-12-15 at 09:06 +0100, Ricard Wanderlof wrote:
> Hi,
> 
> I've looked through the documentation on 
> http://www.linux-mtd.infradead.org but I can't find the answer to the 
> following question(s):
> 
> Using 'static' UBI volumes seems to be the preferred way of creating read 
> only file systems.

No, I think the _original_ idea behind static volumes was storing some
important r/o blobs there without any FS. So UBI static volumes simplify
this by making the volume size being = the contents size, even if the
contents size is not multiple of LEB size, and static volumes also
protect the data with CRC-32.

But UBIFS has its own CRC32 protection, so does not need UBI static
volume services.

> While it seems possible to use ubinize to make a complete ubi image 
> containing static volumes and then write it to the flash using ubiformat, 
> is it possible to update just a single volume using ubiupdatevol
> 
> I've tried using ubimkvol to create a static volume, then using 
> ubiupdatevol to write an ubifs image to it. That works, but when I try to 
> mount it subsequently I get things like
> 
> [ 6656.114000] UBIFS: static UBI volume - read-only mode
> [ 6656.129000] UBIFS error (pid 866): mount_ubifs: can't format empty UBI 
> volume: read-only UBI volume
> mount: mounting ubi1_0 on /volume1/ failed: Read-only file system
> 
> which in a way makes sense to me; if the volume is static = read only then 
> it shouldn't be possible to write to it.

This should work. You somehow wiped the volume instead of updating it,
may be used the -t option for ubiupdatevol.

> A related question: With static volumes, I assume you still get the 
> benefit of scrubbing, which in turn means that UBI can move the data 
> around if it deems necessary?

Yes, sure.

> Which begs a final question: is it possible to verify the integrity of a 
> static UBI volume?

All eraseblocks are protected with CRC-32. Fist time the static volume
is openend, it is checked. See the 'ubi_check_volume()' function. It is
also checked after it has been updated.

To force checking, you need to detach the whole mtd device, and
re-attach it. Or implement an ioctl for this, which is trivial to do.

>  Even with JFFS2, if mounted readonly the flash in that 
> particular partition is never written to,

The same with UBIFS - we never write when we are mounted R/O. There are
many ubifs_assert()s to check this as well.

>  so it is possible to use a 
> simple checksum to verify data integrity.

You can do this with UBIFS I think, did not try though.

>  With JFFS2 this can be 
> important, as missing JFFS2 nodes don't necessarily result in mount time 
> or run time failures, it just results in missing files or parts of files.

Yeah, I think UBIFS will yell and  switch to R/O mode if one of the
nodes is missing or corrupted.

The difference between JFFS2 and UBIFS is that JFFS2 cannot distinguish
between nodes corrupted because of power cuts, and nodes corrupted
because something bad happened to the flash. UBIFS does better job here
- it recovers only from errors which could possibly be caused by power
cuts, and it switches to R/O mode for other errors.

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



From dedekind1 at gmail.com  Thu Dec 16 11:26:15 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 16 Dec 2010 18:26:15 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
Message-ID: <1292516775.2364.108.camel@localhost>

On Wed, 2010-12-15 at 11:43 +0100, Ricard Wanderlof wrote:
> I'm also wondering if anyone has any thoughts on upgrading a 'live' 
> system, when the flash is managed by UBI.
> 
> With a system based on mtd+jffs2 it is actually possible to reflash the 
> partition with the [read only] root file system on it without unmounting, 
> as long as no accesses are made to the physical flash during the rewrite 
> or afterwards. In other words, immediately after reflashing the system 
> must be rebooted.

Hmm, I presume you can do this with UBIFS, but you need to make sure all
the backgound stuff like moving and eraseing eraseblocs is done before
doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
character device), see the 'vol_cdev_fsync()' function. Ah, and of
course you need to sync UBIFS before this.

Then if you can guarantee that no one is reading writing to it, you can
change the flash.

Another option is to remount R/O, if you can make sure there are no
processes keeping files open in R/W mode.

> However, with UBI, given that there are background threads which might be 
> doing garbage collection etc I'm suspecting such a solution might not be 
> as suitable when the flash is managed by UBI. Or is there a some solution 
> that someone has tried with any level of success?

Just call sync(), then fsync on the UBI volume, and you won't have
background processes if there is not I/O.

Be beware, even reading from UBIFS can cause scrubbing in UBI.

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



From agust at denx.de  Thu Dec 16 17:01:10 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:01:10 +0100
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101214195124.GA6010@falooley.org>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org>
Message-ID: <20101216230110.65156c55@wker>

On Tue, 14 Dec 2010 11:51:24 -0800
Jason Lunz <lunz at acm.org> wrote:
...
> diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
> index a9e6ba4..3d9f7e0 100644
> --- a/include/linux/mtd/map.h
> +++ b/include/linux/mtd/map.h
> @@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map)
>  	return r;
>  }
>  
> +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS
> +#define map_read(map, ofs) (map)->read(map, ofs)
> +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len)
> +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs)
> +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len)
> +
> +extern void simple_map_init(struct map_info *);
> +#define map_is_linear(map) (map->phys != NO_XIP)
> +
>  static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
>  {
>  	map_word r;
> @@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
>  	memcpy_toio(map->virt + to, from, len);
>  }
>  
> -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS
> -#define map_read(map, ofs) (map)->read(map, ofs)
> -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len)
> -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs)
> -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len)
> -
> -extern void simple_map_init(struct map_info *);
> -#define map_is_linear(map) (map->phys != NO_XIP)
> -
>  #else
>  #define map_read(map, ofs) inline_map_read(map, ofs)
>  #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len)

This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not
defined in the kernel configuration. Please fix!

Thanks,
Anatolij



From sshore at iders.ca  Thu Dec 16 17:36:31 2010
From: sshore at iders.ca (Scottie Shore)
Date: Thu, 16 Dec 2010 22:36:31 +0000
Subject: JFFS2 - increase MAX_SUMMARY_SIZE to address warning
Message-ID: <E29897F6386BC843A2912780030A97F31CA0863F@exchange.iders.ca>

Hello,

We frequently see warnings in dmesg similar to the ones below when using JFFS2 on nand flash with 512KiB page size. According to the summary code, this means that the summary size for a page is over MAX_SUMMARY_SIZE of 64KiB, so the summary is discarded.

JFFS2 warning: (549) jffs2_sum_write_data: Not enough space for summary, padsize = -3208
JFFS2 warning: (549) jffs2_sum_write_data: Not enough space for summary, padsize = -3352

The comments with MAX_SUMMARY_SIZE say that 64KiB was chosen so that kmalloc can be used, however other sources say that kmalloc can allocate up to 128KiB. I've updated MAX_SUMMARY_SIZE to 128KiB according to the attached patch and tested on our hardware for about a week with frequent heavy read/write cycles. So far I've encountered no problems, and no further warnings. I'm concerned that a fix this easy may be wrong in a non-obvious way, though.

Are there platforms where this change would not work?
Does this change cause problems that might not be immediately visible?
If there's no concerns about same, could the patch be applied to the mainline code?

Regards,

Scottie Shore
Iders, Inc.
<html>
<body>
Scottie Shore Embedded Software Developer Iders Incorporated 27047 Oakwood Road Oakbank, MB R0E 1J2 Tel (204) 444-5200 ext 282 Fax: (204) 444-5900 [http://www.iders.ca/IDERS_logo.jpg] ________________________________ Iders Incorporated Confidential: ________________________________
 This message is intended solely for the use of the designated recipient(s) and their appointed delegates, and may contain confidential information. Any unauthorized disclosure, copying or distribution of its contents is strictly prohibited. If you have received
 this message in error, please destroy it and advise the sender immediately by phone, Email or facsimile.
</body>
</html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2-summary.patch
Type: text/x-patch
Size: 602 bytes
Desc: jffs2-summary.patch
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101216/7a0e1245/attachment.bin>

From agust at denx.de  Thu Dec 16 17:42:13 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:13 +0100
Subject: [PATCH v2 0/6] Fix UBIFS recovery issues observed on NOR flash
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-1-git-send-email-agust@denx.de>

This v2 patch series is the next attempt to fix UBIFS recovery
issues on NOR flash partitions. Previously only one patch
has been submitted. Now, as requested by Artem, the patch
is split into several patches and additionally the setting
of writebufsize for NAND/OneNAND flash is also done. Comments
from Artem to the previous patch have been addressed, too.

Anatolij Gustschin (6):
  mtd: add writebufsize field to mtd_info struct
  mtd: cfi: add writebufsize initialization
  mtd: nand: add mtd->writebufsize initialization
  mtd: onenand: add mtd->writebufsize initialization
  mtd: initialize writebufsize in the MTD object of a partition
  UBI: use mtd->writebufsize to set minimal I/O unit size

 drivers/mtd/chips/cfi_cmdset_0001.c |    1 +
 drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++++
 drivers/mtd/chips/cfi_cmdset_0020.c |    1 +
 drivers/mtd/mtdconcat.c             |    1 +
 drivers/mtd/mtdpart.c               |    1 +
 drivers/mtd/nand/nand_base.c        |    1 +
 drivers/mtd/onenand/onenand_base.c  |    1 +
 drivers/mtd/ubi/build.c             |   19 ++++++++++++++++++-
 include/linux/mtd/mtd.h             |   13 +++++++++++++
 9 files changed, 41 insertions(+), 1 deletions(-)



From agust at denx.de  Thu Dec 16 17:42:14 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:14 +0100
Subject: [PATCH v2 1/6] mtd: add writebufsize field to mtd_info struct
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-2-git-send-email-agust@denx.de>

This field will be used to indicate the write buffer size
of the MTD device. UBI will set it's minimal I/O unit size
(min_io_size) to the indicated write buffer size. By this
change we intend to fix failed recovery of UBIFS partitions
we currently observe on NOR flash when mounting the partition
after unclean unmount.

Currently the min_io_size is set to mtd->writesize (which is 1
byte for NOR flash). But flash programming is often done from
prepared write buffer containing multiple bytes and is performed
in one programming operation which could be interrupted by a power
cut or a system reset causing corrupted (partially written) areas
in a flash sector. Knowing the size of potentially corrupted areas
UBIFS scanning and recovery algorithms are able to perform
successful recovery.

In case of NOR flash minimal I/O size must be equal to the
maximal size of the write buffer used by embedded flash
programming algorithm. In case of NAND flash mtd->writebufsize
should be equivalent to mtd->writesize.

The subsequent patches will add mtd->writebufsize initialization
where needed.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 include/linux/mtd/mtd.h |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index fe8d77e..3c6db0c 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -144,6 +144,19 @@ struct mtd_info {
 	 */
 	uint32_t writesize;
 
+	/*
+	 * Size of the write buffer used by the MTD.
+	 * MTD devices having a write buffer can write multiple writesize
+	 * chunks at a time. E.g. while writing 4 * writesize bytes to a
+	 * device with 2 * writesize bytes buffer the MTD driver can (but
+	 * doesn't have to) do 2 writesize operations, but not 4.
+	 * In case of NAND flash writebufsize should be equivalent to
+	 * writesize. In case of NOR flash writebufsize is the size of the
+	 * write buffer used by the MTD device to program multiple bytes
+	 * at a time (in one programming operation).
+	 */
+	uint32_t writebufsize;
+
 	uint32_t oobsize;   // Amount of OOB data per block (e.g. 16)
 	uint32_t oobavail;  // Available OOB bytes per block
 
-- 
1.7.1



From agust at denx.de  Thu Dec 16 17:42:15 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:15 +0100
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-3-git-send-email-agust@denx.de>

Initialize mtd->writebufsize to the value obtained
by CFI query command at probe time.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/chips/cfi_cmdset_0001.c |    1 +
 drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++++
 drivers/mtd/chips/cfi_cmdset_0020.c |    1 +
 3 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 44cbfc0..a8c3e1c 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -455,6 +455,7 @@ struct mtd_info *cfi_cmdset_0001(struct map_info *map, int primary)
 	mtd->flags   = MTD_CAP_NORFLASH;
 	mtd->name    = map->name;
 	mtd->writesize = 1;
+	mtd->writebufsize = 1 << cfi->cfiq->MaxBufWriteSize;
 
 	mtd->reboot_notifier.notifier_call = cfi_intelext_reboot;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..54dbd28 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -428,6 +428,10 @@ struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
 	mtd->flags   = MTD_CAP_NORFLASH;
 	mtd->name    = map->name;
 	mtd->writesize = 1;
+	mtd->writebufsize = 1 << cfi->cfiq->MaxBufWriteSize;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): write buffer size %d\n",
+		__func__, mtd->writebufsize);
 
 	mtd->reboot_notifier.notifier_call = cfi_amdstd_reboot;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c b/drivers/mtd/chips/cfi_cmdset_0020.c
index 314af1f..c04b765 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -238,6 +238,7 @@ static struct mtd_info *cfi_staa_setup(struct map_info *map)
 	mtd->resume = cfi_staa_resume;
 	mtd->flags = MTD_CAP_NORFLASH & ~MTD_BIT_WRITEABLE;
 	mtd->writesize = 8; /* FIXME: Should be 0 for STMicro flashes w/out ECC */
+	mtd->writebufsize = 1 << cfi->cfiq->MaxBufWriteSize;
 	map->fldrv = &cfi_staa_chipdrv;
 	__module_get(THIS_MODULE);
 	mtd->name = map->name;
-- 
1.7.1



From agust at denx.de  Thu Dec 16 17:42:16 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:16 +0100
Subject: [PATCH v2 3/6] mtd: nand: add mtd->writebufsize initialization
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-4-git-send-email-agust@denx.de>

Initialize mtd->writebufsize to be equal to mtd->writesize.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/nand/nand_base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5dd7ae4..4915067 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3439,6 +3439,7 @@ int nand_scan_tail(struct mtd_info *mtd)
 	mtd->resume = nand_resume;
 	mtd->block_isbad = nand_block_isbad;
 	mtd->block_markbad = nand_block_markbad;
+	mtd->writebufsize = mtd->writesize;
 
 	/* propagate ecc.layout to mtd_info */
 	mtd->ecclayout = chip->ecc.layout;
-- 
1.7.1



From agust at denx.de  Thu Dec 16 17:42:17 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:17 +0100
Subject: [PATCH v2 4/6] mtd: onenand: add mtd->writebufsize initialization
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-5-git-send-email-agust@denx.de>

Initialize mtd->writebufsize to be equal to mtd->writesize.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/onenand/onenand_base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 2d7c90d..d552821 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -4076,6 +4076,7 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	mtd->block_isbad = onenand_block_isbad;
 	mtd->block_markbad = onenand_block_markbad;
 	mtd->owner = THIS_MODULE;
+	mtd->writebufsize = mtd->writesize;
 
 	/* Unlock whole block */
 	this->unlock_all(mtd);
-- 
1.7.1



From agust at denx.de  Thu Dec 16 17:42:19 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:19 +0100
Subject: [PATCH v2 6/6] UBI: use mtd->writebufsize to set minimal I/O unit size
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-7-git-send-email-agust@denx.de>

Previously we used mtd->writesize field to set UBI's minimal
I/O unit size. This sometimes caused UBIFS recovery issues
when mounting an uncleanly unmounted UBIFS partition on NOR
flash since mtd->writesize is 1 byte for NOR flash. The
MTD CFI driver however often performs writing multiple
bytes in one programming operation using the chip's write
buffer. We have to use the size of this write buffer as
a minimal I/O unit size for UBI on NOR flash to fix the
observed UBIFS recovery issues.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/ubi/build.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 5ebe280..c2d5310 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -672,7 +672,24 @@ static int io_init(struct ubi_device *ubi)
 		ubi->nor_flash = 1;
 	}
 
-	ubi->min_io_size = ubi->mtd->writesize;
+	/*
+	 * Sets minimal I/O unit size (min_io_size) for UBI. On NAND flash
+	 * min_io_size should be equivalent to ubi->mtd->writesize.
+	 * In case of NOR flash minimal I/O size must be equal to the size
+	 * of the write buffer used by internal flash programming algorithm.
+	 * This requirement results from the fact that the flash programming
+	 * operation could be interrupted by a power cut or a system reset
+	 * causing corrupted (partially written) areas in a NOR flash sector.
+	 * Knowing the size of potentially corrupted areas UBIFS scanning
+	 * and recovery algorithms are able to perform successful recovery.
+	 */
+	if (ubi->mtd->type == MTD_NANDFLASH)
+		ubi_assert(ubi->mtd->writebufsize == ubi->mtd->writesize);
+	else if (ubi->mtd->type == MTD_NORFLASH)
+		ubi_assert(ubi->mtd->writebufsize > 0);
+
+	ubi->min_io_size = ubi->mtd->writebufsize;
+
 	ubi->hdrs_min_io_size = ubi->mtd->writesize >> ubi->mtd->subpage_sft;
 
 	/*
-- 
1.7.1



From agust at denx.de  Thu Dec 16 17:42:18 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 16 Dec 2010 23:42:18 +0100
Subject: [PATCH v2 5/6] mtd: initialize writebufsize in the MTD object of a
	partition
In-Reply-To: <292342500.2538.65.camel@localhost>
References: <292342500.2538.65.camel@localhost>
Message-ID: <1292539339-25111-6-git-send-email-agust@denx.de>

Propagate the writebufsize to the partition's MTD object so
that UBI can set correct value for it's minimal I/O size
using the writebufsize field of MTD object of the partition.

By previous patches we added proper writebufsize field
initialization. Next patch can now change UBI to use
this field for setting the minimal I/O size.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/mtd/mtdconcat.c |    1 +
 drivers/mtd/mtdpart.c   |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index bf8de09..5f5777b 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -776,6 +776,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 	concat->mtd.size = subdev[0]->size;
 	concat->mtd.erasesize = subdev[0]->erasesize;
 	concat->mtd.writesize = subdev[0]->writesize;
+	concat->mtd.writebufsize = subdev[0]->writebufsize;
 	concat->mtd.subpage_sft = subdev[0]->subpage_sft;
 	concat->mtd.oobsize = subdev[0]->oobsize;
 	concat->mtd.oobavail = subdev[0]->oobavail;
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 1047ff0..b910a37 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -384,6 +384,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 	slave->mtd.flags = master->flags & ~part->mask_flags;
 	slave->mtd.size = part->size;
 	slave->mtd.writesize = master->writesize;
+	slave->mtd.writebufsize = master->writebufsize;
 	slave->mtd.oobsize = master->oobsize;
 	slave->mtd.oobavail = master->oobavail;
 	slave->mtd.subpage_sft = master->subpage_sft;
-- 
1.7.1



From ricard.wanderlof at axis.com  Fri Dec 17 04:33:12 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Fri, 17 Dec 2010 10:33:12 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <1292516353.2364.101.camel@localhost>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<1292516353.2364.101.camel@localhost>
Message-ID: <Pine.LNX.4.64.1012170946190.7024@lnxricardw.se.axis.com>


On Thu, 16 Dec 2010, Artem Bityutskiy wrote:

> > Using 'static' UBI volumes seems to be the preferred way of creating read 
> > only file systems.
> 
> No, I think the _original_ idea behind static volumes was storing some
> important r/o blobs there without any FS. So UBI static volumes simplify
> this by making the volume size being = the contents size, even if the
> contents size is not multiple of LEB size, and static volumes also
> protect the data with CRC-32.

That's good news, because that's what exactly what I'd need.

> But UBIFS has its own CRC32 protection, so does not need UBI static
> volume services.
> [...] 
> All eraseblocks are protected with CRC-32. Fist time the static volume
> is openend, it is checked. See the 'ubi_check_volume()' function. It is
> also checked after it has been updated.

The thing is, I'd like to be able to checksum, or otherwise verify, a 
couple of read-only partitions on the flash _before_ attempting to boot 
Linux. No point in trying to boot Linux if the kernel or the root file 
system is not intact. So although it is nice that UBI verifies static 
volumes during attach, and UBIFS during mount, it is really too late as I 
need to do this in the boot loader.

Of course, extending the bootloader to be able to verify UBI volumes is 
probably doable. I could then use cramfs, squashfs or similar for the root 
file system, with gluebi, and use the static volume UBI CRC32 for 
verification by the bootloader. Makeing the boot loader understand UBIFS I 
think would be too much work.

>> With a system based on mtd+jffs2 it is actually possible to reflash the
>> partition with the [read only] root file system on it without unmounting,
>> as long as no accesses are made to the physical flash during the rewrite
>> or afterwards. In other words, immediately after reflashing the system
>> must be rebooted.
> The same with UBIFS - we never write when we are mounted R/O. There are
> many ubifs_assert()s to check this as well.

... but UBI might still do writes during the course of scrubbing I guess, 
unless ...

> [ ... ] you need to make sure all the backgound stuff like moving and 
> eraseing eraseblocs is done before doing this by doing fsync() on your 
> /dev/ubiX_Y device (UBI volume character device), see the 
> 'vol_cdev_fsync()' function. Ah, and of course you need to sync UBIFS 
> before this.

That would be no problem, it is basically the same stuff we need to do 
with JFFS2 before reflashing.

> >  so it is possible to use a 
> > simple checksum to verify data integrity.
> 
> You can do this with UBIFS I think, did not try though.

What I meant was 'a simple checksum on the raw mtd partition', which can't 
work with UBIFS as the UBI erase counters etc can change over time as a 
result of scrubbing.

I guess I could read from the /dev/ubix_y device to just get the raw UBIFS 
data which shouldn't change even in the event of scrubbing? Or should I 
use gluebi to get both a raw mtd partition corresponding to the raw UBIFS 
data, as well as using UBIFS (on /dev/ubix_y) for the file system?

> The difference between JFFS2 and UBIFS is that JFFS2 cannot distinguish
> between nodes corrupted because of power cuts, and nodes corrupted
> because something bad happened to the flash. UBIFS does better job here
> - it recovers only from errors which could possibly be caused by power
> cuts, and it switches to R/O mode for other errors.
> [...]
> Just call sync(), then fsync on the UBI volume, and you won't have
> background processes if there is not I/O.
>
> Be beware, even reading from UBIFS can cause scrubbing in UBI.

That's very good. My basic problem though is still that I need to verify 
the integrity before booting, although it is very nice that the file 
system can detect errors during mount. With JFFS2 there's always a 
nagging idea that errors will go undetected and we won't notice until a 
file is missing or contains zeros.

I often get complaints from other developers in our company saying "can't 
we suppress these 'jffs2 crc error' messages if they don't actually 
indicate a failure. My answer is always a) We don't know if they indicate 
a failure or not and b) Since mostly they are harmless, come back when you 
have found that a file has disappeared from the file system or other file 
problem. So far no one has come back with any complaints referring to b).

/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  Fri Dec 17 04:39:18 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Fri, 17 Dec 2010 10:39:18 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <1292516775.2364.108.camel@localhost>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com> 
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
	<1292516775.2364.108.camel@localhost>
Message-ID: <Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>


(Crud, I was trying to concatenate both replies into one message to avoid 
two threads on the same issue but then I thought of something else after 
sending the first one off).

On Thu, 16 Dec 2010, Artem Bityutskiy wrote:

>> With a system based on mtd+jffs2 it is actually possible to reflash the
>> partition with the [read only] root file system on it without unmounting,
>> as long as no accesses are made to the physical flash during the rewrite
>> or afterwards. In other words, immediately after reflashing the system
>> must be rebooted.
>
> Hmm, I presume you can do this with UBIFS, but you need to make sure all
> the backgound stuff like moving and eraseing eraseblocs is done before
> doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
> character device), see the 'vol_cdev_fsync()' function. Ah, and of
> course you need to sync UBIFS before this.
>
> Then if you can guarantee that no one is reading writing to it, you can
> change the flash.

It would be nice to use ubiupdatevol to do this, but it won't let me do 
that if the volume is mounted (naturally). I don't know if this is 
something that is enforced by ubiupdatevol or ubi. I would assume the 
latter but I haven't checked the code.

Of course I could always write my own "ubiupdatevol" to deal with this but 
it's always nice to use existing and supported tools.

/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 glecerf at gmail.com  Fri Dec 17 04:59:41 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Fri, 17 Dec 2010 10:59:41 +0100
Subject: [PATCH v5 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
Message-ID: <20101217095941.8560.75355.stgit@shiryu>

These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
to patch all Samsung chips from 0.0 to 1.0.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
[2] https://dev.openwrt.org/ticket/7348

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
Acked-by: Wolfram Sang <w.sang at pengutronix.de>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9d68ab9..324fee4 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -392,9 +392,19 @@ static struct cfi_fixup fixup_table[] = {
 static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
-	if (cfi->mfr == CFI_MFR_SAMSUNG && cfi->id == 0x257e &&
-	    extp->MajorVersion == '0')
-		extp->MajorVersion = '1';
+	if (cfi->mfr == CFI_MFR_SAMSUNG) {
+		if (extp->MajorVersion == '0' && extp->MinorVersion == '0') {
+			/*
+			 * Samsung K8P2815UQB and K8D6x16UxM chips
+			 * report major=0 / minor=0.
+			 */
+			printk(KERN_NOTICE "  Fixing Samsung's Amd/Fujitsu"
+			       " Extended Query version to 1.%c\n",
+			       extp->MinorVersion);
+			extp->MajorVersion = '1';
+		}
+	}
+
 	/*
 	 * SST 38VF640x chips report major=0xFF / minor=0xFF.
 	 */



From glecerf at gmail.com  Fri Dec 17 04:59:47 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Fri, 17 Dec 2010 10:59:47 +0100
Subject: [PATCH v5 2/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D3x16UxC NOR chips
In-Reply-To: <20101217095941.8560.75355.stgit@shiryu>
References: <20101217095941.8560.75355.stgit@shiryu>
Message-ID: <20101217095947.8560.45288.stgit@shiryu>

These chips report CFI v3.3 [1], so patch them on the fly to the more
correct v1.3.
Discussed and tested by the OpenWRT people [2].

[1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/32Mbit/K8D3216UBC/ds_K8D3x16UxC_rev17.pdf
[2] https://dev.openwrt.org/ticket/866

Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 324fee4..a43ab45 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -393,10 +393,12 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi,
 				  struct cfi_pri_amdstd *extp)
 {
 	if (cfi->mfr == CFI_MFR_SAMSUNG) {
-		if (extp->MajorVersion == '0' && extp->MinorVersion == '0') {
+		if ((extp->MajorVersion == '0' && extp->MinorVersion == '0') ||
+		    (extp->MajorVersion == '3' && extp->MinorVersion == '3')) {
 			/*
 			 * Samsung K8P2815UQB and K8D6x16UxM chips
 			 * report major=0 / minor=0.
+			 * K8D3x16UxC chips report major=3 / minor=3.
 			 */
 			printk(KERN_NOTICE "  Fixing Samsung's Amd/Fujitsu"
 			       " Extended Query version to 1.%c\n",



From viresh.kumar at st.com  Fri Dec 17 05:58:18 2010
From: viresh.kumar at st.com (viresh kumar)
Date: Fri, 17 Dec 2010 16:28:18 +0530
Subject: [PATCH V2 25/69] ST SPEAr: Add smi driver for serial NOR flash
In-Reply-To: <4CCAB4D8.90807@st.com>
References: <cover.1285933331.git.viresh.kumar@st.com>
	<238bd0ff57f8530c597157bc07f6c46dc362e1bc.1285933331.git.viresh.kumar@st.com>
	<4CBD32EB.5050409@st.com> <4CCAB4D8.90807@st.com>
Message-ID: <4D0B424A.2020105@st.com>

On 10/29/2010 05:19 PM, viresh kumar wrote:
> On 10/19/2010 11:25 AM, viresh kumar wrote:
>> On 10/01/2010 05:25 PM, Viresh KUMAR wrote:
>>> From: Shiraz Hashim <shiraz.hashim at st.com>
>>>
>>> SPEAr platforms(spear3xx/spear6xx/spear13xx) provide SMI(Serial Memory
>>> Interface) controller to access serial NOR flash. SMI provides a simple
>>> interface for SPI/serial NOR flashes and has certain inbuilt commands
>>> and features to support these flashes easily. It also makes it possible
>>> to map an address range in order to directly access (read/write) the SNOR
>>> over address bus. This patch intends to provide serial nor driver support
>>> for spear platforms which are accessed through SMI.
>>>
>>> Signed-off-by: Shiraz Hashim <shiraz.hashim at st.com>
>>> Signed-off-by: Viresh Kumar <viresh.kumar at st.com>
>>> ---
>>>  arch/arm/plat-spear/include/plat/smi.h |   68 ++
>>>  drivers/mtd/devices/Kconfig            |    7 +
>>>  drivers/mtd/devices/Makefile           |    1 +
>>>  drivers/mtd/devices/spear_smi.c        | 1122 ++++++++++++++++++++++++++++++++
>>>  4 files changed, 1198 insertions(+), 0 deletions(-)
>>>  create mode 100644 arch/arm/plat-spear/include/plat/smi.h
>>>  create mode 100644 drivers/mtd/devices/spear_smi.c
>>
>> David,
>>
>> Any review comments on this patch??
>>
> 
> David,
> 
> Any review comments??
> 

David,

Is this patch OK? Actually i have sent this patch as part of a big patchset.
And my whole patchset is on hold untill i get this acked.
Please see if you can get some time to review this patch.

--
viresh


From dedekind1 at gmail.com  Fri Dec 17 07:26:57 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 17 Dec 2010 14:26:57 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012170946190.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<1292516353.2364.101.camel@localhost>
	<Pine.LNX.4.64.1012170946190.7024@lnxricardw.se.axis.com>
Message-ID: <1292588817.2412.7.camel@localhost>

On Fri, 2010-12-17 at 10:33 +0100, Ricard Wanderlof wrote:
> > The same with UBIFS - we never write when we are mounted R/O. There are
> > many ubifs_assert()s to check this as well.
> 
> ... but UBI might still do writes during the course of scrubbing I guess, 
> unless ...

Yes, you are right.

> > >  so it is possible to use a 
> > > simple checksum to verify data integrity.
> > 
> > You can do this with UBIFS I think, did not try though.
> 
> What I meant was 'a simple checksum on the raw mtd partition', which can't 
> work with UBIFS as the UBI erase counters etc can change over time as a 
> result of scrubbing.

Ah, yes, you see, you know the things quite well yourself :-)

> I guess I could read from the /dev/ubix_y device to just get the raw UBIFS 
> data which shouldn't change even in the event of scrubbing? Or should I 
> use gluebi to get both a raw mtd partition corresponding to the raw UBIFS 
> data, as well as using UBIFS (on /dev/ubix_y) for the file system?

No, gluebi is not needed, it would just give you an /dev/mtdZ device
with contents equivalent to /dev/ubiX_Y

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



From ricard.wanderlof at axis.com  Fri Dec 17 07:31:32 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Fri, 17 Dec 2010 13:31:32 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <1292588817.2412.7.camel@localhost>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com> 
	<1292516353.2364.101.camel@localhost>
	<Pine.LNX.4.64.1012170946190.7024@lnxricardw.se.axis.com>
	<1292588817.2412.7.camel@localhost>
Message-ID: <Pine.LNX.4.64.1012171328380.7024@lnxricardw.se.axis.com>


On Fri, 17 Dec 2010, Artem Bityutskiy wrote:

> Ah, yes, you see, you know the things quite well yourself :-)

Well, I try to convince myself that I think I know, but there's always the 
very real and likely possibilty that I'm wrong because I've misunderstood 
something.

>> I guess I could read from the /dev/ubix_y device to just get the raw UBIFS
>> data which shouldn't change even in the event of scrubbing? Or should I
>> use gluebi to get both a raw mtd partition corresponding to the raw UBIFS
>> data, as well as using UBIFS (on /dev/ubix_y) for the file system?
>
> No, gluebi is not needed, it would just give you an /dev/mtdZ device
> with contents equivalent to /dev/ubiX_Y

So what does gluebi in fact add, does it just supply all the necessary 
ioctl's to make /dev/ubiX_Y look like a /dev/mtdZ device, in addition to 
the already existing functionality of being able to read and write to the 
volume using read and write? (Yes, I could dig through the code, but even 
though it might give me the answer on what it looks like right now, it 
might not tell what the intention was...).

/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 dedekind1 at gmail.com  Fri Dec 17 07:40:34 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 17 Dec 2010 14:40:34 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012171328380.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<1292516353.2364.101.camel@localhost>
	<Pine.LNX.4.64.1012170946190.7024@lnxricardw.se.axis.com>
	<1292588817.2412.7.camel@localhost>
	<Pine.LNX.4.64.1012171328380.7024@lnxricardw.se.axis.com>
Message-ID: <1292589634.2412.11.camel@localhost>

On Fri, 2010-12-17 at 13:31 +0100, Ricard Wanderlof wrote:
> On Fri, 17 Dec 2010, Artem Bityutskiy wrote:
> 
> > Ah, yes, you see, you know the things quite well yourself :-)
> 
> Well, I try to convince myself that I think I know, but there's always the 
> very real and likely possibilty that I'm wrong because I've misunderstood 
> something.
> 
> >> I guess I could read from the /dev/ubix_y device to just get the raw UBIFS
> >> data which shouldn't change even in the event of scrubbing? Or should I
> >> use gluebi to get both a raw mtd partition corresponding to the raw UBIFS
> >> data, as well as using UBIFS (on /dev/ubix_y) for the file system?
> >
> > No, gluebi is not needed, it would just give you an /dev/mtdZ device
> > with contents equivalent to /dev/ubiX_Y
> 
> So what does gluebi in fact add, does it just supply all the necessary 
> ioctl's to make /dev/ubiX_Y look like a /dev/mtdZ device, in addition to 
> the already existing functionality of being able to read and write to the 
> volume using read and write? (Yes, I could dig through the code, but even 
> though it might give me the answer on what it looks like right now, it 
> might not tell what the intention was...).

Original idea was to put JFFS2 on top of UBI volumes. Gluebi is doing
just that - turns UBI volume into an MTD device, then you have mount it
with JFFS2.

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



From dedekind1 at gmail.com  Fri Dec 17 08:04:29 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 17 Dec 2010 15:04:29 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
	<1292516775.2364.108.camel@localhost>
	<Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>
Message-ID: <1292591069.2412.25.camel@localhost>

On Fri, 2010-12-17 at 10:39 +0100, Ricard Wanderlof wrote:
> (Crud, I was trying to concatenate both replies into one message to avoid 
> two threads on the same issue but then I thought of something else after 
> sending the first one off).
> 
> On Thu, 16 Dec 2010, Artem Bityutskiy wrote:
> 
> >> With a system based on mtd+jffs2 it is actually possible to reflash the
> >> partition with the [read only] root file system on it without unmounting,
> >> as long as no accesses are made to the physical flash during the rewrite
> >> or afterwards. In other words, immediately after reflashing the system
> >> must be rebooted.
> >
> > Hmm, I presume you can do this with UBIFS, but you need to make sure all
> > the backgound stuff like moving and eraseing eraseblocs is done before
> > doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
> > character device), see the 'vol_cdev_fsync()' function. Ah, and of
> > course you need to sync UBIFS before this.
> >
> > Then if you can guarantee that no one is reading writing to it, you can
> > change the flash.
> 
> It would be nice to use ubiupdatevol to do this, but it won't let me do 
> that if the volume is mounted (naturally). I don't know if this is 
> something that is enforced by ubiupdatevol or ubi. I would assume the 
> latter but I haven't checked the code.
> 
> Of course I could always write my own "ubiupdatevol" to deal with this but 
> it's always nice to use existing and supported tools.

This is UBI - it does not allow updating if someone keeps the volume
open. When UBI is mounted, it keeps the volume open. It closes the
volume when unmounted.

It looks error-prone to allow updating while there are users, from UBI
POW, I think.

And I cannot think of a nice way of doing this.

Why can't you just
1. lazily unmount UBIFS
2. find all users of UBIFS and kill them
3. this will make UBIFS finally unmount
4. you safely update the UBI volume

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



From ricard.wanderlof at axis.com  Fri Dec 17 10:02:41 2010
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Fri, 17 Dec 2010 16:02:41 +0100 (CET)
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <1292591069.2412.25.camel@localhost>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com> 
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com> 
	<1292516775.2364.108.camel@localhost>
	<Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>
	<1292591069.2412.25.camel@localhost>
Message-ID: <Pine.LNX.4.64.1012171555320.7024@lnxricardw.se.axis.com>


On Fri, 17 Dec 2010, Artem Bityutskiy wrote:

>>>> With a system based on mtd+jffs2 it is actually possible to reflash the
>>>> partition with the [read only] root file system on it without unmounting,
>>>> as long as no accesses are made to the physical flash during the rewrite
>>>> or afterwards. In other words, immediately after reflashing the system
>>>> must be rebooted.
>>>
>>> Hmm, I presume you can do this with UBIFS, but you need to make sure all
>>> the backgound stuff like moving and eraseing eraseblocs is done before
>>> doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
>>> character device), see the 'vol_cdev_fsync()' function. Ah, and of
>>> course you need to sync UBIFS before this.
>>>
>>> Then if you can guarantee that no one is reading writing to it, you can
>>> change the flash.
>>
>> It would be nice to use ubiupdatevol to do this, but it won't let me do
>> that if the volume is mounted (naturally). I don't know if this is
>> something that is enforced by ubiupdatevol or ubi. I would assume the
>> latter but I haven't checked the code.
>>
>> Of course I could always write my own "ubiupdatevol" to deal with this but
>> it's always nice to use existing and supported tools.
>
> This is UBI - it does not allow updating if someone keeps the volume
> open. When UBI is mounted, it keeps the volume open. It closes the
> volume when unmounted.

Yes, it make definitely makes sense to have it work this way to avoid 
problems.

> It looks error-prone to allow updating while there are users, from UBI
> POW, I think.

I agree. It just happens to be the way our firmware update process works 
currently ... :-)

> And I cannot think of a nice way of doing this.
>
> Why can't you just
> 1. lazily unmount UBIFS
> 2. find all users of UBIFS and kill them
> 3. this will make UBIFS finally unmount
> 4. you safely update the UBI volume

The problem is that in this case it is our root file system which is to be 
reflashed, so we can't just unmount it. I have an idea about using 
pivot_root though, in a similar manner to the way the root file system is 
switched from initrd to disk during an ordinary Linux boot with initrd.

Something like
1. Close down everything.
2. Create a tmpfs and mount it.
3. Copy all necessary binaries and libraries to the tmpfs.
4. Use pivot_root to switch root file systems.
5. Unmount the original (UBIFS) root file system.
6. Rewrite the root file system using ubiupdatevol.
7. Reboot.

Right now I'm stumped at how to restart init in order for it to relase its 
stdin,stdout and stderr, which still refer to the (old) /dev/console, but 
there must be a solution somehow as the same situation must occur with an 
ordinary (initrd) kernel booting.

/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 dedekind1 at gmail.com  Fri Dec 17 12:00:41 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 17 Dec 2010 19:00:41 +0200
Subject: [PATCH V2 25/69] ST SPEAr: Add smi driver for serial NOR flash
In-Reply-To: <4D0B424A.2020105@st.com>
References: <cover.1285933331.git.viresh.kumar@st.com>
	<238bd0ff57f8530c597157bc07f6c46dc362e1bc.1285933331.git.viresh.kumar@st.com>
	<4CBD32EB.5050409@st.com> <4CCAB4D8.90807@st.com>
	<4D0B424A.2020105@st.com>
Message-ID: <1292605241.2412.48.camel@localhost>

On Fri, 2010-12-17 at 16:28 +0530, viresh kumar wrote:
> Is this patch OK? Actually i have sent this patch as part of a big patchset.
> And my whole patchset is on hold untill i get this acked.
> Please see if you can get some time to review this patch.

Would be simpler if you can separate mtd pieces.

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



From dedekind1 at gmail.com  Fri Dec 17 12:05:25 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 17 Dec 2010 19:05:25 +0200
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012171555320.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
	<1292516775.2364.108.camel@localhost>
	<Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>
	<1292591069.2412.25.camel@localhost>
	<Pine.LNX.4.64.1012171555320.7024@lnxricardw.se.axis.com>
Message-ID: <1292605525.2412.52.camel@localhost>

On Fri, 2010-12-17 at 16:02 +0100, Ricard Wanderlof wrote:
> On Fri, 17 Dec 2010, Artem Bityutskiy wrote:
> 
> >>>> With a system based on mtd+jffs2 it is actually possible to reflash the
> >>>> partition with the [read only] root file system on it without unmounting,
> >>>> as long as no accesses are made to the physical flash during the rewrite
> >>>> or afterwards. In other words, immediately after reflashing the system
> >>>> must be rebooted.
> >>>
> >>> Hmm, I presume you can do this with UBIFS, but you need to make sure all
> >>> the backgound stuff like moving and eraseing eraseblocs is done before
> >>> doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
> >>> character device), see the 'vol_cdev_fsync()' function. Ah, and of
> >>> course you need to sync UBIFS before this.
> >>>
> >>> Then if you can guarantee that no one is reading writing to it, you can
> >>> change the flash.
> >>
> >> It would be nice to use ubiupdatevol to do this, but it won't let me do
> >> that if the volume is mounted (naturally). I don't know if this is
> >> something that is enforced by ubiupdatevol or ubi. I would assume the
> >> latter but I haven't checked the code.
> >>
> >> Of course I could always write my own "ubiupdatevol" to deal with this but
> >> it's always nice to use existing and supported tools.
> >
> > This is UBI - it does not allow updating if someone keeps the volume
> > open. When UBI is mounted, it keeps the volume open. It closes the
> > volume when unmounted.
> 
> Yes, it make definitely makes sense to have it work this way to avoid 
> problems.
> 
> > It looks error-prone to allow updating while there are users, from UBI
> > POW, I think.
> 
> I agree. It just happens to be the way our firmware update process works 
> currently ... :-)
> 
> > And I cannot think of a nice way of doing this.
> >
> > Why can't you just
> > 1. lazily unmount UBIFS
> > 2. find all users of UBIFS and kill them
> > 3. this will make UBIFS finally unmount
> > 4. you safely update the UBI volume
> 
> The problem is that in this case it is our root file system which is to be 
> reflashed, so we can't just unmount it. I have an idea about using 
> pivot_root though, in a similar manner to the way the root file system is 
> switched from initrd to disk during an ordinary Linux boot with initrd.
> 
> Something like
> 1. Close down everything.
> 2. Create a tmpfs and mount it.
> 3. Copy all necessary binaries and libraries to the tmpfs.
> 4. Use pivot_root to switch root file systems.
> 5. Unmount the original (UBIFS) root file system.
> 6. Rewrite the root file system using ubiupdatevol.
> 7. Reboot.
> 
> Right now I'm stumped at how to restart init in order for it to relase its 
> stdin,stdout and stderr, which still refer to the (old) /dev/console, but 
> there must be a solution somehow as the same situation must occur with an 
> ordinary (initrd) kernel booting.

Well, I guess it is possible to teach UBI to do roughly something like
this:

1. block all I/O from upper layers (UBIFS)
2. flush the background works queue, i.e., finish all the pending
srubbings, etc.
3. do the volume update, even though there are users, but they are
blocked.

After this there is no way back, so the users are blocked forever. This
should be interruptable blocking, so users should either interrupt, or
you should reboot.

Should not be too difficult to do, but not sure how upstreamable that
would be, but you can try, why not?

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



From tony at atomide.com  Fri Dec 17 19:03:45 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 17 Dec 2010 16:03:45 -0800
Subject: [PATCH 1/7] omap3630: nand: fix device size to work in polled mode
In-Reply-To: <1290785677-16005-2-git-send-email-s-ghorai@ti.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-2-git-send-email-s-ghorai@ti.com>
Message-ID: <20101218000344.GV5941@atomide.com>

* Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> zoom3 and 3630-sdp having the x16 nand device.
> This patch configure gpmc as x16 and select the currect function in driver
> for polled mode (without prefetch enable) transfer.
> 
> Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> ---
>  arch/arm/mach-omap2/board-flash.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c
> index fd38c05..001c605 100644
> --- a/arch/arm/mach-omap2/board-flash.c
> +++ b/arch/arm/mach-omap2/board-flash.c
> @@ -145,6 +145,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs)
>  	board_nand_data.parts		= nand_parts;
>  	board_nand_data.nr_parts		= nr_parts;
>  
> +	if (cpu_is_omap3630())
> +		board_nand_data.devsize = 1;
> +
>  	gpmc_nand_init(&board_nand_data);
>  }
>  #else

I guess this is board specific for the size, not omap specific?

Regards,

Tony


From tony at atomide.com  Fri Dec 17 19:08:46 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 17 Dec 2010 16:08:46 -0800
Subject: [PATCH 2/7] omap3: nand: configurable transfer type per board
In-Reply-To: <1290785677-16005-3-git-send-email-s-ghorai@ti.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-3-git-send-email-s-ghorai@ti.com>
Message-ID: <20101218000845.GW5941@atomide.com>

* Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> nand transfer type (sDMA, Polled, prefetch) can be select from board file,
> enabling all transfer type in driver, by default.
> 
> this helps in multi-omap build and to select different transfer type for
> different board.
> 
> Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> ---
>  arch/arm/plat-omap/include/plat/nand.h |    7 +++
>  drivers/mtd/nand/Kconfig               |   17 ------
>  drivers/mtd/nand/omap2.c               |   92 +++++++++++--------------------
>  3 files changed, 40 insertions(+), 76 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-omap/include/plat/nand.h
> index 6562cd0..78c0bdb 100644
> --- a/arch/arm/plat-omap/include/plat/nand.h
> +++ b/arch/arm/plat-omap/include/plat/nand.h
> @@ -10,6 +10,12 @@
>  
>  #include <linux/mtd/partitions.h>
>  
> +enum nand_io {
> +	NAND_OMAP_PREFETCH_POLLED = 0,	/* prefetch polled mode, default */
> +	NAND_OMAP_POLLED,		/* polled mode, without prefetch */
> +	NAND_OMAP_PREFETCH_DMA		/* prefetch enabled sDMA mode */
> +};
> +
>  struct omap_nand_platform_data {
>  	unsigned int		options;
>  	int			cs;
> @@ -20,6 +26,7 @@ struct omap_nand_platform_data {
>  	int			(*nand_setup)(void);
>  	int			(*dev_ready)(struct omap_nand_platform_data *);
>  	int			dma_channel;
> +	enum nand_io		xfer_type;
>  	unsigned long		phys_base;
>  	int			devsize;
>  };

So maybe the devsize in patch 1/7 should be handled with this too?

Regards,

Tony


From tony at atomide.com  Fri Dec 17 19:09:54 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 17 Dec 2010 16:09:54 -0800
Subject: [PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc
In-Reply-To: <1290785677-16005-4-git-send-email-s-ghorai@ti.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-4-git-send-email-s-ghorai@ti.com>
Message-ID: <20101218000954.GX5941@atomide.com>

* Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> add support the irq mode in GPMC.
> gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
> 
> Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> ---
>  arch/arm/mach-omap2/board-2430sdp.c        |    1 +
>  arch/arm/mach-omap2/board-3430sdp.c        |    1 +
>  arch/arm/mach-omap2/board-3630sdp.c        |    1 +
>  arch/arm/mach-omap2/board-4430sdp.c        |    2 +
>  arch/arm/mach-omap2/board-am3517evm.c      |    2 +
>  arch/arm/mach-omap2/board-apollon.c        |    1 +
>  arch/arm/mach-omap2/board-cm-t35.c         |    1 +
>  arch/arm/mach-omap2/board-devkit8000.c     |    1 +
>  arch/arm/mach-omap2/board-generic.c        |    2 +
>  arch/arm/mach-omap2/board-h4.c             |    1 +
>  arch/arm/mach-omap2/board-igep0020.c       |    1 +
>  arch/arm/mach-omap2/board-ldp.c            |    1 +
>  arch/arm/mach-omap2/board-n8x0.c           |    2 +
>  arch/arm/mach-omap2/board-omap3beagle.c    |    1 +
>  arch/arm/mach-omap2/board-omap3evm.c       |    2 +
>  arch/arm/mach-omap2/board-omap3pandora.c   |    2 +
>  arch/arm/mach-omap2/board-omap3stalker.c   |    1 +
>  arch/arm/mach-omap2/board-omap3touchbook.c |    1 +
>  arch/arm/mach-omap2/board-omap4panda.c     |    2 +
>  arch/arm/mach-omap2/board-overo.c          |    1 +
>  arch/arm/mach-omap2/board-rx51.c           |    1 +
>  arch/arm/mach-omap2/board-zoom2.c          |    2 +
>  arch/arm/mach-omap2/board-zoom3.c          |    2 +
>  arch/arm/mach-omap2/gpmc.c                 |   39 ++++++++++++++++++++++++++-
>  arch/arm/mach-omap2/io.c                   |    2 -
>  arch/arm/plat-omap/include/plat/gpmc.h     |    4 +++
>  arch/arm/plat-omap/include/plat/irqs.h     |    9 +++++-
>  27 files changed, 81 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> index b527f8d..11c89dc 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void)
>  	omap_board_config_size = ARRAY_SIZE(sdp2430_config);
>  	omap2_init_common_hw(NULL, NULL);
>  	omap_init_irq();
> +	gpmc_init();
>  	omap_gpio_init();
>  }
>  
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
> index 4e3742c..a040165 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
>  	omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
>  	omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
>  	omap_init_irq();
> +	gpmc_init();
>  	omap_gpio_init();
>  }
...

The gpmc init should be done with subsys_initcall instead.

Tony


From tony at atomide.com  Fri Dec 17 18:52:19 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 17 Dec 2010 15:52:19 -0800
Subject: [PATCH] MTD: NAND: ams-delta: drop omap_read/write, use ioremap
In-Reply-To: <201012151543.46341.jkrzyszt@tis.icnet.pl>
References: <201012151543.46341.jkrzyszt@tis.icnet.pl>
Message-ID: <20101217235218.GU5941@atomide.com>

* Janusz Krzysztofik <jkrzyszt at tis.icnet.pl> [101215 06:44]:
> There is a common requirement for not using OMAP specific omap_readw() / 
> omap_writew() function calls in drivers/, but replace them with 
> readw() / writew() on ioremap()ped addresses passed from arch/ instead.
> 
> The patch implements this idea for the Amstrad Delta NAND driver. To be 
> able to use the modified driver, the board file is updated with the 
> platform device I/O resource declaration, which is passed from there.
> 
> Created and tested against linux-2.6.37-rc5, on top of recent patch 
> 'MTD: NAND: ams-delta: convert to platform driver'.

Acked-by: Tony Lindgren <tony at atomide.com>


From rob at landley.net  Fri Dec 17 23:08:16 2010
From: rob at landley.net (Rob Landley)
Date: Fri, 17 Dec 2010 22:08:16 -0600
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292512711.2364.85.camel@localhost>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<201012150031.21417.rob@landley.net>
	<1292512711.2364.85.camel@localhost>
Message-ID: <201012172208.17937.rob@landley.net>

On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote:
> On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote:
> > That is awesome and I'm not finding any documentation on it...  Ah:
> >
> >  
> > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_
> >MTD_device
> >
> > Wow that's awkward.  Let's see, that says...
> >
> >   mknod /tmp/mtdblock0 b 31 0
> >   modprobe loop
> >   losetup /dev/loop0 rootfs.jffs2
> >   modprobe mtdblock
> >   modprobe block2mtd
> >   # Note the ,128KiB is needed (on 2.6.26 at least) to set the
> >   # eraseblock  size.
> >   echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd
> >   modprobe jffs2
> >   mount -t jffs2 /tmp/mtdblock0 /media/jffs2
>
> You should not need mtdblock in modern kernels, it is legacy. You should
> be abole to mount jffs2 on top of mtd0 with
>
> mount -t jffs2 mtd0 /media/jffs2

How does one associate the mtd0 with the loopback device?  (I thought mtd0 was 
for actual flash memory.)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


From dedekind1 at gmail.com  Sun Dec 19 11:47:56 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 18:47:56 +0200
Subject: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile
In-Reply-To: <20101217042759.GA3148@falooley.org>
References: <20071024011712.GA3762@falooley.org>
	<1193208689.26096.48.camel@pmac.infradead.org>
	<20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org> <20101216230110.65156c55@wker>
	<20101217042759.GA3148@falooley.org>
Message-ID: <1292777276.2140.1.camel@koala>

On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote:
> On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote:
> > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not
> > defined in the kernel configuration. Please fix!
> 
> Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the
> ability to compile mtd on ARCH=um, with the exception mtdchar.

Merged with the previous patch, thanks.

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



From dedekind1 at gmail.com  Sun Dec 19 11:54:05 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 18:54:05 +0200
Subject: [PATCH 1/1] mtd: nand: add check for out of page read
In-Reply-To: <AANLkTi=zB7UBjkvGYv_wdwZpH1Ghatn6eye1z5616h4X@mail.gmail.com>
References: <1290156045-11719-1-git-send-email-r64343@freescale.com>
	<1292340409.2538.40.camel@localhost>
	<AANLkTi=zB7UBjkvGYv_wdwZpH1Ghatn6eye1z5616h4X@mail.gmail.com>
Message-ID: <1292777645.13362.3.camel@koala>

On Wed, 2010-12-15 at 09:55 +0800, Jason Liu wrote:
> >        /* Do not allow reads past end of device */
> >        if (unlikely(from >= mtd->size ||
> >                     ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
> >                                        (from >> chip->page_shift)) * len)) {
> >                DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt read beyond end "
> >                                        "of device\n", __func__);
> >                return -EINVAL;
> >        }
> 
> Here the mtd->size in nand_base.c should be the NAND flash chip size,

I think this is partition size as well.

> while in nand_oobtest,
> 
>               /* Attempt to read off end of device */
>                 ops.mode      = MTD_OOB_AUTO;
>                 ops.len       = 0;
>                 ops.retlen    = 0;
>                 ops.ooblen    = mtd->ecclayout->oobavail;
>                 ops.oobretlen = 0;
>                 ops.ooboffs   = 1;
>                 ops.datbuf    = NULL;
>                 ops.oobbuf    = readbuf;
>                 printk(PRINT_PREF "attempting to read past end of device\n");
>                 printk(PRINT_PREF "an error is expected...\n");
>                 err = mtd->read_oob(mtd, mtd->size - mtd->writesize, &ops);
>                 if (err) {
>                         printk(PRINT_PREF "error occurred as expected\n");
>                         err = 0;
>                 } else {
>                         printk(PRINT_PREF "error: read past end of device\n");
>                         errcnt += 1;
>                 }
>         }
> 
> here, mtd->size is mtd partition size right? when the mtd partition is
> not the last MTD partition, the error will happen.

I think this is the same in both. Try to debug this with printks().

> 
> I have tested on real NAND, while not on nandsim.

Please, try to reproduce this with nandsim as well, and if it works, try
to find out why (using printk debugging)

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



From dedekind1 at gmail.com  Sun Dec 19 12:00:53 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:00:53 +0200
Subject: [PATCH] MTD: NAND: ams-delta: select for built-in by default
In-Reply-To: <201012151258.16764.jkrzyszt@tis.icnet.pl>
References: <201012151258.16764.jkrzyszt@tis.icnet.pl>
Message-ID: <1292778053.13362.7.camel@koala>

On Wed, 2010-12-15 at 12:58 +0100, Janusz Krzysztofik wrote:
> Now that the Amstrad Delta NAND driver is converted to a platform driver, 
> which prevents it from interfering with other unrelated hardware in multiple 
> OMAP1 cpu and machine configurations, it can be automatically configured for 
> being built into the kernel if the Amstrad Delta board is also selected.
> 
> Created against linux-2.6.37-rc5.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>

Pushed to l2-mtd-2.6.git, thanks.

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



From dedekind1 at gmail.com  Sun Dec 19 12:00:55 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:00:55 +0200
Subject: [PATCH] MTD: m25p80: add debugging trace in sst_write()
In-Reply-To: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
References: <1292414372-17085-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <1292778055.13362.8.camel@koala>

On Wed, 2010-12-15 at 12:59 +0100, Nicolas Ferre wrote:
> Add a DEBUG(MTD_DEBUG_LEVEL2, ..) trace at beginning of sst_write() function as
> it is done in m25p80_write() function.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>

So do you do this only becaus it is done in m25p80_write()? This is what
the commit message suggests... Have you found these DEBUG macros useful
for you? (I never found them any useful).

Anyway, I've put this to my l2-mtd-2.6.git tree, thanks.

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



From dedekind1 at gmail.com  Sun Dec 19 12:03:33 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:03:33 +0200
Subject: [PATCH] MTD: NAND: ams-delta: drop omap_read/write, use ioremap
In-Reply-To: <201012151543.46341.jkrzyszt@tis.icnet.pl>
References: <201012151543.46341.jkrzyszt@tis.icnet.pl>
Message-ID: <1292778213.13362.9.camel@koala>

On Wed, 2010-12-15 at 15:43 +0100, Janusz Krzysztofik wrote:
> There is a common requirement for not using OMAP specific omap_readw() / 
> omap_writew() function calls in drivers/, but replace them with 
> readw() / writew() on ioremap()ped addresses passed from arch/ instead.
> 
> The patch implements this idea for the Amstrad Delta NAND driver. To be 
> able to use the modified driver, the board file is updated with the 
> platform device I/O resource declaration, which is passed from there.
> 
> Created and tested against linux-2.6.37-rc5, on top of recent patch 
> 'MTD: NAND: ams-delta: convert to platform driver'.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>

Pushed to l2-mtd-2.6.git, thanks!

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



From dedekind1 at gmail.com  Sun Dec 19 12:05:42 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:05:42 +0200
Subject: [PATCH v5 1/2] mtd: cfi_cmdset_0002: add support for Samsung
	K8D6x16UxM NOR chips
In-Reply-To: <20101217095941.8560.75355.stgit@shiryu>
References: <20101217095941.8560.75355.stgit@shiryu>
Message-ID: <1292778342.13362.10.camel@koala>

On Fri, 2010-12-17 at 10:59 +0100, Guillaume LECERF wrote:
> These chips report CFI v0.0 [1], so extend cfi_fixup_major_minor()
> to patch all Samsung chips from 0.0 to 1.0.
> Discussed and tested by the OpenWRT people [2].
> 
> [1] http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NORFlash/64Mbit/K8D6316UTM/ds_K8D6x16UxM_rev16.pdf
> [2] https://dev.openwrt.org/ticket/7348
> 
> Signed-off-by: Guillaume LECERF <glecerf at gmail.com>
> Acked-by: Wolfram Sang <w.sang at pengutronix.de>

Pushed both patches to l2-mtd-2.6.git, thank you!

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



From dedekind1 at gmail.com  Sun Dec 19 12:08:22 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:08:22 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <201012172208.17937.rob@landley.net>
References: <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
	<201012150031.21417.rob@landley.net>
	<1292512711.2364.85.camel@localhost>
	<201012172208.17937.rob@landley.net>
Message-ID: <1292778502.13362.13.camel@koala>

On Fri, 2010-12-17 at 22:08 -0600, Rob Landley wrote:
> On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote:
> > On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote:
> > > That is awesome and I'm not finding any documentation on it...  Ah:
> > >
> > >  
> > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_
> > >MTD_device
> > >
> > > Wow that's awkward.  Let's see, that says...
> > >
> > >   mknod /tmp/mtdblock0 b 31 0
> > >   modprobe loop
> > >   losetup /dev/loop0 rootfs.jffs2
> > >   modprobe mtdblock
> > >   modprobe block2mtd
> > >   # Note the ,128KiB is needed (on 2.6.26 at least) to set the
> > >   # eraseblock  size.
> > >   echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd
> > >   modprobe jffs2
> > >   mount -t jffs2 /tmp/mtdblock0 /media/jffs2
> >
> > You should not need mtdblock in modern kernels, it is legacy. You should
> > be abole to mount jffs2 on top of mtd0 with
> >
> > mount -t jffs2 mtd0 /media/jffs2
> 
> How does one associate the mtd0 with the loopback device?  (I thought mtd0 was 
> for actual flash memory.)

You do not need loopback devices, just flash your rootfs.jffs2 directly
to /dev/mtd0, e.g., with nandwrite. You can emulate nand with nandsim.

But your method should also work, I just wanted to point that JFFS2 does
not depend on mtdblock in any way.

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



From dedekind1 at gmail.com  Sun Dec 19 12:45:31 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:45:31 +0200
Subject: [PATCH v2 1/6] mtd: add writebufsize field to mtd_info struct
In-Reply-To: <1292539339-25111-2-git-send-email-agust@denx.de>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-2-git-send-email-agust@denx.de>
Message-ID: <1292780731.13362.16.camel@koala>

On Thu, 2010-12-16 at 23:42 +0100, Anatolij Gustschin wrote:
> This field will be used to indicate the write buffer size
> of the MTD device. UBI will set it's minimal I/O unit size
> (min_io_size) to the indicated write buffer size. By this
> change we intend to fix failed recovery of UBIFS partitions
> we currently observe on NOR flash when mounting the partition
> after unclean unmount.
> 
> Currently the min_io_size is set to mtd->writesize (which is 1
> byte for NOR flash). But flash programming is often done from
> prepared write buffer containing multiple bytes and is performed
> in one programming operation which could be interrupted by a power
> cut or a system reset causing corrupted (partially written) areas
> in a flash sector. Knowing the size of potentially corrupted areas
> UBIFS scanning and recovery algorithms are able to perform
> successful recovery.
> 
> In case of NOR flash minimal I/O size must be equal to the
> maximal size of the write buffer used by embedded flash
> programming algorithm. In case of NAND flash mtd->writebufsize
> should be equivalent to mtd->writesize.
> 
> The subsequent patches will add mtd->writebufsize initialization
> where needed.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>

I've tweaked your commentary a bit and pushed to l2-mtd-2.6.git, please,
check.

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



From dedekind1 at gmail.com  Sun Dec 19 12:45:57 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:45:57 +0200
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <1292539339-25111-3-git-send-email-agust@denx.de>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-3-git-send-email-agust@denx.de>
Message-ID: <1292780757.13362.17.camel@koala>

On Thu, 2010-12-16 at 23:42 +0100, Anatolij Gustschin wrote:
> Initialize mtd->writebufsize to the value obtained
> by CFI query command at probe time.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>

Pushed patches 2-5 as is.

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



From dedekind1 at gmail.com  Sun Dec 19 12:46:19 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 19 Dec 2010 19:46:19 +0200
Subject: [PATCH v2 6/6] UBI: use mtd->writebufsize to set minimal I/O
	unit size
In-Reply-To: <1292539339-25111-7-git-send-email-agust@denx.de>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-7-git-send-email-agust@denx.de>
Message-ID: <1292780779.13362.18.camel@koala>

On Thu, 2010-12-16 at 23:42 +0100, Anatolij Gustschin wrote:
> Previously we used mtd->writesize field to set UBI's minimal
> I/O unit size. This sometimes caused UBIFS recovery issues
> when mounting an uncleanly unmounted UBIFS partition on NOR
> flash since mtd->writesize is 1 byte for NOR flash. The
> MTD CFI driver however often performs writing multiple
> bytes in one programming operation using the chip's write
> buffer. We have to use the size of this write buffer as
> a minimal I/O unit size for UBI on NOR flash to fix the
> observed UBIFS recovery issues.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>

I've re-wrote the commentary and pushed, please, check.

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



From lunz at acm.org  Sun Dec 19 14:07:20 2010
From: lunz at acm.org (Jason Lunz)
Date: Sun, 19 Dec 2010 14:07:20 -0500
Subject: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile
In-Reply-To: <1292777276.2140.1.camel@koala>
References: <20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org> <20101216230110.65156c55@wker>
	<20101217042759.GA3148@falooley.org>
	<1292777276.2140.1.camel@koala>
Message-ID: <20101219190720.GA16710@falooley.org>


You should also drop the changes that
7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c -
there's no point changing that when mtdchar is disabled on ARCH=um.

Jason

On Sun, Dec 19, 2010 at 06:47:56PM +0200, Artem Bityutskiy wrote:
> On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote:
> > On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote:
> > > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not
> > > defined in the kernel configuration. Please fix!
> > 
> > Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the
> > ability to compile mtd on ARCH=um, with the exception mtdchar.
> 
> Merged with the previous patch, thanks.
> 
> -- 
> Best Regards,
> Artem Bityutskiy (???????? ?????)
> 
> 


From manningc2 at actrix.gen.nz  Sun Dec 19 16:45:53 2010
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Mon, 20 Dec 2010 10:45:53 +1300
Subject: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage
In-Reply-To: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
Message-ID: <201012201045.53688.manningc2@actrix.gen.nz>

On Saturday 27 November 2010 04:34:30 Sukumar Ghorai wrote:
> The following set of patches applies on linux-2.6.
>
> The main motivations behind this patch series are -
>         1. support NAND I/O in irq mode.
>         2. support of different ECC schema.
>         3. also to make ecc layout as like in romcode ecc layout

Why change the ECC layout?

Be very careful when you change ECC layouts. This can break production 
systems.

For example if people are running something earlier and then want to deliver a 
new kernel with 2.6.37 then their existing NAND file systems will no longer 
be readable.

Changes to ECC should only be done for very good reasons and should be 
controlled with a Kconfig with the default being the existing ECC layout.

-- Charles



From manningc2 at actrix.gen.nz  Sun Dec 19 16:50:10 2010
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Mon, 20 Dec 2010 10:50:10 +1300
Subject: [PATCH v6 2/3] omap3 nand: cleanup virtual address usages
In-Reply-To: <1278660308-8689-3-git-send-email-s-ghorai@ti.com>
References: <1278660308-8689-1-git-send-email-s-ghorai@ti.com>
	<1278660308-8689-2-git-send-email-s-ghorai@ti.com>
	<1278660308-8689-3-git-send-email-s-ghorai@ti.com>
Message-ID: <201012201050.10726.manningc2@actrix.gen.nz>

On Friday 09 July 2010 19:25:07 Sukumar Ghorai wrote:

> +++ b/arch/arm/plat-omap/include/plat/nand.h
> @@ -21,13 +21,11 @@ struct omap_nand_platform_data {
>  	int			(*dev_ready)(struct omap_nand_platform_data *);
>  	int			dma_channel;
>  	unsigned long		phys_base;
> -	void __iomem		*gpmc_cs_baseaddr;
> -	void __iomem		*gpmc_baseaddr;
>  	int			devsize;
>  };
>
> -/* size (4 KiB) for IO mapping */
> -#define	NAND_IO_SIZE	SZ_4K
> +/* minimum size for IO mapping */
> +#define	NAND_IO_SIZE	4

Is this really only for a 4-byte region? I would have expected that this 
controls access to a multi-register NAND controller and should really be 
larger. 

-- Charles



From manningc2 at actrix.gen.nz  Sun Dec 19 17:18:01 2010
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Mon, 20 Dec 2010 11:18:01 +1300
Subject: UBIFS not mounting on linux-omap 2.6.36
Message-ID: <201012201118.01766.manningc2@actrix.gen.nz>

Hi All

I am trying to nail down an omap3 ubifs  performance regression, but cannot 
get Steve Sakoman's 2.6.35 or 2.6.36 kernels
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git
 to mount ubifs although the same procedure works with older kernels and works 
with the linux-omap 2.6.37 master.

Any hints?

Thanks

Charles


The NAND had been initilised with:

ubiformat /dev/mtd4 -s 512

ubimkvol /dev/ubi0 -m -N foo

Herewith log

root at omap3-multi:~# ubiattach /dev/ubi_ctrl -m4 -d4
UBI: attaching mtd4 to ubi4
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: max. sequence number:       2
UBI: attached mtd4 to ubi4
UBI: MTD device name:            "rootfs"
UBI: MTD device size:            249 MiB
UBI: number of good PEBs:        1996
UBI: number of bad PEBs:         0
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:             0
UBI: total number of reserved PEBs: 1996
UBI: number of PEBs reserved for bad PEB handling: 19
UBI: max/mean erase counter: 8195/11
UBI: image sequence number:  1842873171
UBI: background thread "ubi_bgt4d" started, PID 407
UBI device number 4, total 1996 LEBs (257531904 bytes, 245.6 MiB), available 0 
LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
root at omap3-multi:~# dmesg
...
UBI: attaching mtd4 to ubi4
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: max. sequence number:       2
UBI: attached mtd4 to ubi4
UBI: MTD device name:            "rootfs"
UBI: MTD device size:            249 MiB
UBI: number of good PEBs:        1996
UBI: number of bad PEBs:         0
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:             0
UBI: total number of reserved PEBs: 1996
UBI: number of PEBs reserved for bad PEB handling: 19
UBI: max/mean erase counter: 8195/11
UBI: image sequence number:  1842873171
UBI: background thread "ubi_bgt4d" started, PID 407

root at omap3-multi:~# ubinfo -a              
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:62
Present UBI devices:            ubi4

ubi4
Volumes count:                           1
Logical eraseblock size:                 129024 bytes, 126.0 KiB
Total amount of logical eraseblocks:     1996 (257531904 bytes, 245.6 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  19
Current maximum erase counter value:     8195
Minimum input/output unit size:          2048 bytes
Character device major/minor:            250:0
Present volumes:                         0

Volume ID:   0 (on ubi4)
Type:        dynamic
Alignment:   1
Size:        1973 LEBs (254564352 bytes, 242.8 MiB)
State:       OK
Name:        foo
Character device major/minor: 250:1
root at omap3-multi:~# mount -t ubifs ubi4:foo ss/
mount: ubi4:foo already mounted or ss/ busy
root at omap3-multi:~# dmesg
...
UBIFS DBG (pid 429): ubifs_get_sb: name ubi4:foo, flags 0x0
UBIFS DBG (pid 429): ubifs_get_sb: opened ubi4_0
...



From agust at denx.de  Mon Dec 20 04:15:39 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Mon, 20 Dec 2010 10:15:39 +0100
Subject: [PATCH v2 1/6] mtd: add writebufsize field to mtd_info struct
In-Reply-To: <1292780731.13362.16.camel@koala>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-2-git-send-email-agust@denx.de>
	<1292780731.13362.16.camel@koala>
Message-ID: <20101220101539.62f05a61@wker>

On Sun, 19 Dec 2010 19:45:31 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> I've tweaked your commentary a bit and pushed to l2-mtd-2.6.git, please,
> check.

It is ok. Thanks!

Anatolij


From agust at denx.de  Mon Dec 20 04:18:51 2010
From: agust at denx.de (Anatolij Gustschin)
Date: Mon, 20 Dec 2010 10:18:51 +0100
Subject: [PATCH v2 6/6] UBI: use mtd->writebufsize to set minimal I/O
	unit size
In-Reply-To: <1292780779.13362.18.camel@koala>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-7-git-send-email-agust@denx.de>
	<1292780779.13362.18.camel@koala>
Message-ID: <20101220101851.4d4f8583@wker>

On Sun, 19 Dec 2010 19:46:19 +0200
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Thu, 2010-12-16 at 23:42 +0100, Anatolij Gustschin wrote:
> > Previously we used mtd->writesize field to set UBI's minimal
> > I/O unit size. This sometimes caused UBIFS recovery issues
> > when mounting an uncleanly unmounted UBIFS partition on NOR
> > flash since mtd->writesize is 1 byte for NOR flash. The
> > MTD CFI driver however often performs writing multiple
> > bytes in one programming operation using the chip's write
> > buffer. We have to use the size of this write buffer as
> > a minimal I/O unit size for UBI on NOR flash to fix the
> > observed UBIFS recovery issues.
> > 
> > Signed-off-by: Anatolij Gustschin <agust at denx.de>
> 
> I've re-wrote the commentary and pushed, please, check.

Checked, it is ok. Thanks!

Anatolij


From viresh.kumar at st.com  Mon Dec 20 04:19:30 2010
From: viresh.kumar at st.com (Viresh Kumar)
Date: Mon, 20 Dec 2010 14:49:30 +0530
Subject: [PATCH V3 25/63 resend] Newly erased page read workaround
In-Reply-To: <cover.1292833228.git.viresh.kumar@st.com>
References: <cover.1292833228.git.viresh.kumar@st.com>
Message-ID: <6187de0568d1ea8a6aeb6c3ca54ac6684bee9973.1292833228.git.viresh.kumar@st.com>

From: Vipin Kumar <vipin.kumar at st.com>

A newly erased page contains ff in data as well as spare area. While reading an
erased page, the read out ecc from spare area does not match the ecc generated
by fsmc ecc hardware accelarator. This is because ecc of data ff ff is not ff
ff. This leads to errors when jffs2 fs erases and reads back the pages to
ensure consistency.

This patch adds a software workaround to ensure that the ecc check is not
performed for erased pages. An erased page is checked by checking data as ff ff.

Signed-off-by: Vipin Kumar <vipin.kumar at st.com>
Signed-off-by: Viresh Kumar <viresh.kumar at st.com>
---
 drivers/mtd/nand/fsmc_nand.c |   28 ++++++++++++++++++++++------
 1 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 02edfba..d3f0d8d 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -385,7 +385,7 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 	struct fsmc_nand_data *host = container_of(mtd,
 					struct fsmc_nand_data, mtd);
 	struct fsmc_eccplace *ecc_place = host->ecc_place;
-	int i, j, s, stat, eccsize = chip->ecc.size;
+	int i, j, k, s, stat, eccsize = chip->ecc.size;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
@@ -425,11 +425,27 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 		memcpy(&ecc_code[i], oob, 13);
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
-		stat = chip->ecc.correct(mtd, p, &ecc_code[i], &ecc_calc[i]);
-		if (stat < 0)
-			mtd->ecc_stats.failed++;
-		else
-			mtd->ecc_stats.corrected += stat;
+		/*
+		 * This is a temporary erase check. A newly erased page read
+		 * would result in an ecc error because the oob data is also
+		 * erased to FF and the calculated ecc for an FF data is not
+		 * FF..FF.
+		 * This is a workaround to skip performing correction in case
+		 * data is FF..FF
+		 */
+		for (k = 0; k < eccsize; k++) {
+			if (*(p + k) != 0xff)
+				break;
+		}
+
+		if (k < eccsize) {
+			stat = chip->ecc.correct(mtd, p, &ecc_code[i],
+					&ecc_calc[i]);
+			if (stat < 0)
+				mtd->ecc_stats.failed++;
+			else
+				mtd->ecc_stats.corrected += stat;
+		}
 	}
 
 	return 0;
-- 
1.7.2.2



From dedekind1 at gmail.com  Mon Dec 20 06:23:36 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Mon, 20 Dec 2010 13:23:36 +0200
Subject: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile
In-Reply-To: <20101219190720.GA16710@falooley.org>
References: <20071227181524.GA19051@falooley.org>
	<20071228174853.GA4252@uranus.ravnborg.org>
	<20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org> <20101216230110.65156c55@wker>
	<20101217042759.GA3148@falooley.org> <1292777276.2140.1.camel@koala>
	<20101219190720.GA16710@falooley.org>
Message-ID: <1292844216.13362.19.camel@koala>

On Sun, 2010-12-19 at 14:07 -0500, Jason Lunz wrote:
> You should also drop the changes that
> 7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c -
> there's no point changing that when mtdchar is disabled on ARCH=um.

Ok, could you please re-sent the final patch with the commit message
etc?

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



From lunz at acm.org  Mon Dec 20 09:04:54 2010
From: lunz at acm.org (Jason Lunz)
Date: Mon, 20 Dec 2010 09:04:54 -0500
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <1292844216.13362.19.camel@koala>
References: <20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org> <20101216230110.65156c55@wker>
	<20101217042759.GA3148@falooley.org>
	<1292777276.2140.1.camel@koala>
	<20101219190720.GA16710@falooley.org>
	<1292844216.13362.19.camel@koala>
Message-ID: <20101220140454.GA26229@falooley.org>

On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote:
> Ok, could you please re-sent the final patch with the commit message
> etc?

Sure, here's everything as a single patch.

------------------------------------->8
Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
dependencies down closer to the parts of mtd that actually need it.
This allows enough of mtd to build to let jffs2 be used on uml.

Signed-off-by: Jason Lunz <lunz at acm.org>
---
 arch/um/Kconfig.rest |    4 +---
 drivers/mtd/Kconfig  |    8 ++++++--
 drivers/mtd/Makefile |    3 ++-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest
index 0ccad0f..e34f399 100644
--- a/arch/um/Kconfig.rest
+++ b/arch/um/Kconfig.rest
@@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig"
 
 source "drivers/md/Kconfig"
 
-if BROKEN
-	source "drivers/mtd/Kconfig"
-endif
+source "drivers/mtd/Kconfig"
 
 source "drivers/leds/Kconfig"
 
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 7741470..603e447 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,6 +1,5 @@
 menuconfig MTD
 	tristate "Memory Technology Device (MTD) support"
-	depends on HAS_IOMEM
 	help
 	  Memory Technology Devices are flash, RAM and similar chips, often
 	  used for solid state file systems on embedded devices. This option
@@ -178,6 +177,7 @@ comment "User Modules And Translation Layers"
 
 config MTD_CHAR
 	tristate "Direct char device access to MTD devices"
+	depends on HAS_IOMEM
 	help
 	  This provides a character device for each MTD device present in
 	  the system, allowing the user to read and write directly to the
@@ -310,7 +310,7 @@ config SSFDC
 
 config SM_FTL
 	tristate "SmartMedia/xD new translation layer"
-	depends on EXPERIMENTAL && BLOCK
+	depends on EXPERIMENTAL && BLOCK && HAS_IOMEM
 	select MTD_BLKDEVS
 	select MTD_NAND_ECC
 	help
@@ -333,6 +333,8 @@ config MTD_OOPS
 	  To use, add console=ttyMTDx to the kernel command line,
 	  where x is the MTD device number to use.
 
+if HAS_IOMEM
+
 source "drivers/mtd/chips/Kconfig"
 
 source "drivers/mtd/maps/Kconfig"
@@ -345,6 +347,8 @@ source "drivers/mtd/onenand/Kconfig"
 
 source "drivers/mtd/lpddr/Kconfig"
 
+endif # HAS_IOMEM
+
 source "drivers/mtd/ubi/Kconfig"
 
 endif # MTD
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index d4e7f25..c83eee4 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS)		+= mtdoops.o
 nftl-objs		:= nftlcore.o nftlmount.o
 inftl-objs		:= inftlcore.o inftlmount.o
 
-obj-y		+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
+obj-y			+= tests/
+obj-$(CONFIG_HAS_IOMEM)	+= chips/ lpddr/ maps/ devices/ nand/ onenand/
 
 obj-$(CONFIG_MTD_UBI)		+= ubi/
-- 
1.7.2.3



From glecerf at gmail.com  Mon Dec 20 11:36:57 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Mon, 20 Dec 2010 17:36:57 +0100
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <1292539339-25111-3-git-send-email-agust@denx.de>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-3-git-send-email-agust@denx.de>
Message-ID: <AANLkTi=DHrBiBd8j3fFR5zmuX2cXC05sEFFRdF_btK3Y@mail.gmail.com>

Hello.

2010/12/16 Anatolij Gustschin <agust at denx.de>:
> Initialize mtd->writebufsize to the value obtained
> by CFI query command at probe time.
>
> Signed-off-by: Anatolij Gustschin <agust at denx.de>
> ---
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -428,6 +428,10 @@ struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
> ? ? ? ?mtd->flags ? = MTD_CAP_NORFLASH;
> ? ? ? ?mtd->name ? ?= map->name;
> ? ? ? ?mtd->writesize = 1;
> + ? ? ? mtd->writebufsize = 1 << cfi->cfiq->MaxBufWriteSize;

What about wbufsize initialized in cfi_amdstd_write_buffers() to
"cfi_interleave(cfi) << cfi->cfiq->MaxBufWriteSize" ?
I don't know this piece of code, but I just wanted to point it to you.

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org


From manningc2 at actrix.gen.nz  Mon Dec 20 17:36:22 2010
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Tue, 21 Dec 2010 11:36:22 +1300
Subject: Huge ubi or ubifs sync slowdown since 2.6.32
Message-ID: <201012211136.22254.manningc2@actrix.gen.nz>


Hi All

I've been looking into a ubifs performance regression on linux-omap 2.6.37.

My test is pretty simple, copy a 2Mbyte file and sync.

# sync; date; cp 2Mbyte-file foo; sync; date

On 2.6.32 and earler, the time between the two dates was around 3 seconds.
On linux-omap master it is around 14 seconds. Ouch!

At first I thought the problem was due to changes in the OMAP nand drivers, 
but raw randwrite speed is actually a bit faster. This suggest the finger 
should be pointed at ubi or ubifs.

I then thought that perhaps the layout of my ubinized image might be a 
contributing factor so I erased the partition, ubiformatted and ubimkvoled. 
The problem persisted,

Any suggestions as to what might be broken or how to debug this deeper?

Thanks

Charles





From tony at atomide.com  Mon Dec 20 20:23:52 2010
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 20 Dec 2010 17:23:52 -0800
Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds
	instead of nanoseconds
In-Reply-To: <20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>
References: <20101213122042.20685.52929.sendpatchset@ahunter-work.research.nokia.com>
	<20101213122108.20685.1920.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101221012352.GI5941@atomide.com>

* Adrian Hunter <adrian.hunter at nokia.com> [101213 04:21]:
> From c52e0cdeedffb7a0f9818ad3d6296d1f51b8669d Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter at nokia.com>
> Date: Thu, 9 Dec 2010 10:48:27 +0200
> Subject: [PATCH 4/7] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
> 
> The calculations done with sync_clk are anyway in picoseconds
> and switching to picoseconds allows sync_clk values that are
> not a whole number of nanoseconds - which is sometimes the

Can you please post patches 4 - 5 of this series as separate
patches and Cc linux-omap and linux-arm-kernel mailing lists?

This is assuming patches 4 - 5 do not have dependencies to
the other patches in the series..

Thanks,

Tony


From dedekind1 at gmail.com  Tue Dec 21 09:45:24 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 21 Dec 2010 16:45:24 +0200
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <AANLkTi=DHrBiBd8j3fFR5zmuX2cXC05sEFFRdF_btK3Y@mail.gmail.com>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-3-git-send-email-agust@denx.de>
	<AANLkTi=DHrBiBd8j3fFR5zmuX2cXC05sEFFRdF_btK3Y@mail.gmail.com>
Message-ID: <1292942724.2286.57.camel@localhost>

On Mon, 2010-12-20 at 17:36 +0100, ext Guillaume LECERF wrote:
> Hello.
> 
> 2010/12/16 Anatolij Gustschin <agust at denx.de>:
> > Initialize mtd->writebufsize to the value obtained
> > by CFI query command at probe time.
> >
> > Signed-off-by: Anatolij Gustschin <agust at denx.de>
> > ---
> > --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> > @@ -428,6 +428,10 @@ struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
> >        mtd->flags   = MTD_CAP_NORFLASH;
> >        mtd->name    = map->name;
> >        mtd->writesize = 1;
> > +       mtd->writebufsize = 1 << cfi->cfiq->MaxBufWriteSize;
> 
> What about wbufsize initialized in cfi_amdstd_write_buffers() to
> "cfi_interleave(cfi) << cfi->cfiq->MaxBufWriteSize" ?
> I don't know this piece of code, but I just wanted to point it to you.

Yes, fair question, Anatolij?

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



From dedekind1 at gmail.com  Tue Dec 21 12:36:22 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 21 Dec 2010 19:36:22 +0200
Subject: UBIFS not mounting on linux-omap 2.6.36
In-Reply-To: <201012201118.01766.manningc2@actrix.gen.nz>
References: <201012201118.01766.manningc2@actrix.gen.nz>
Message-ID: <1292952982.13362.21.camel@koala>

On Mon, 2010-12-20 at 11:18 +1300, Charles Manning wrote:
> Hi All
> 
> I am trying to nail down an omap3 ubifs  performance regression, but cannot 
> get Steve Sakoman's 2.6.35 or 2.6.36 kernels
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git
>  to mount ubifs although the same procedure works with older kernels and works 
> with the linux-omap 2.6.37 master.

Well, the only hint I can give is some kind of bisecting, but probably
you do not need such hint :-)

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



From adrian.hunter at nokia.com  Tue Dec 21 14:44:33 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Tue, 21 Dec 2010 21:44:33 +0200
Subject: [PATCH 0/2] Add 104MHz support for OMAP OneNAND
Message-ID: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>

Hi

Here is OMAP2/3: OneNAND: add 104MHz support.

Adrian Hunter (2):
      OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
      OMAP2/3: OneNAND: add 104MHz support

 arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c     |   19 ++++++++++++++-----
 arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
 arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
 arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
 drivers/mtd/onenand/omap2.c            |    3 +++
 6 files changed, 36 insertions(+), 13 deletions(-)
 
Regards
Adrian



From adrian.hunter at nokia.com  Tue Dec 21 14:44:41 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Tue, 21 Dec 2010 21:44:41 +0200
Subject: [PATCH 1/2] OMAP2/3: GPMC: put sync_clk value in picoseconds instead
	of nanoseconds
In-Reply-To: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
References: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101221194441.3127.9777.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 03:48:27 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 10:48:27 +0200
Subject: [PATCH 1/2] OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
Message-ID: <mailman.68.1292960705.1530.linux-mtd@lists.infradead.org>

The calculations done with sync_clk are anyway in picoseconds
and switching to picoseconds allows sync_clk values that are
not a whole number of nanoseconds - which is sometimes the
case.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-nand.c        |    2 +-
 arch/arm/mach-omap2/gpmc-onenand.c     |   10 +++++-----
 arch/arm/mach-omap2/gpmc.c             |   12 +++++++++++-
 arch/arm/mach-omap2/usb-tusb6010.c     |    4 ++--
 arch/arm/plat-omap/include/plat/gpmc.h |    9 +++++----
 5 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 7222096..2bb29c1 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -41,7 +41,7 @@ static int omap2_nand_gpmc_retime(void)
 		return 0;
 
 	memset(&t, 0, sizeof(t));
-	t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk);
+	t.sync_clk = gpmc_nand_data->gpmc_t->sync_clk;
 	t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_on);
 	t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->adv_on);
 
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 7bb6922..1db606c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -174,7 +174,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 
 	switch (freq) {
 	case 83:
-		min_gpmc_clk_period = 12; /* 83 MHz */
+		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
 		t_avds  = 4;
 		t_avdh  = 2;
@@ -183,7 +183,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 9;
 		break;
 	case 66:
-		min_gpmc_clk_period = 15; /* 66 MHz */
+		min_gpmc_clk_period = 15000; /* 66 MHz */
 		t_ces   = 6;
 		t_avds  = 5;
 		t_avdh  = 2;
@@ -192,7 +192,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t_rdyo  = 11;
 		break;
 	default:
-		min_gpmc_clk_period = 18; /* 54 MHz */
+		min_gpmc_clk_period = 18500; /* 54 MHz */
 		t_ces   = 7;
 		t_avds  = 7;
 		t_avdh  = 7;
@@ -271,8 +271,8 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 		t.wr_cycle  = t.rd_cycle;
 		if (cpu_is_omap34xx()) {
 			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ns_to_ticks(min_gpmc_clk_period +
-					t_rdyo));
+					gpmc_ps_to_ticks(min_gpmc_clk_period +
+					t_rdyo * 1000));
 			t.wr_access = t.access;
 		}
 	} else {
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..1b7b3e7 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -168,6 +168,16 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
 	return (time_ns * 1000 + tick_ps - 1) / tick_ps;
 }
 
+unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long tick_ps;
+
+	/* Calculate in picosecs to yield more exact results */
+	tick_ps = gpmc_get_fclk_period();
+
+	return (time_ps + tick_ps - 1) / tick_ps;
+}
+
 unsigned int gpmc_ticks_to_ns(unsigned int ticks)
 {
 	return ticks * gpmc_get_fclk_period() / 1000;
@@ -235,7 +245,7 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
 	int div;
 	u32 l;
 
-	l = sync_clk * 1000 + (gpmc_get_fclk_period() - 1);
+	l = sync_clk + (gpmc_get_fclk_period() - 1);
 	div = l / gpmc_get_fclk_period();
 	if (div > 4)
 		return -1;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 7cb3c18..30934b9 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -120,8 +120,8 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
 	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
 
 	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 12 /* 11.1 nsec */;
-	tmp = (t.sync_clk * 1000 + fclk_ps - 1) / fclk_ps;
+	t.sync_clk = 11100 /* 11.1 nsec */;
+	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
 	if (tmp > 4)
 		return -ERANGE;
 	if (tmp <= 0)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..85ded59 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -80,12 +80,12 @@
 #define GPMC_PREFETCH_STATUS_COUNT(val)	(val & 0x00003fff)
 
 /*
- * Note that all values in this struct are in nanoseconds, while
- * the register values are in gpmc_fck cycles.
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
  */
 struct gpmc_timings {
-	/* Minimum clock period for synchronous mode */
-	u16 sync_clk;
+	/* Minimum clock period for synchronous mode (in picoseconds) */
+	u32 sync_clk;
 
 	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
 	u16 cs_on;		/* Assertion time */
@@ -117,6 +117,7 @@ struct gpmc_timings {
 };
 
 extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
+extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
 extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
 extern unsigned long gpmc_get_fclk_period(void);
-- 
1.7.0.4



From adrian.hunter at nokia.com  Tue Dec 21 14:44:48 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Tue, 21 Dec 2010 21:44:48 +0200
Subject: [PATCH 2/2] OMAP2/3: OneNAND: add 104MHz support
In-Reply-To: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
References: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101221194448.3127.32165.sendpatchset@ahunter-work.research.nokia.com>


From adrian.hunter at nokia.com  Thu Dec  9 04:22:50 2010
From: adrian.hunter at nokia.com (Adrian Hunter)
Date: Thu, 9 Dec 2010 11:22:50 +0200
Subject: [PATCH 2/2] OMAP2/3: OneNAND: add 104MHz support
Message-ID: <mailman.70.1292960729.1530.linux-mtd@lists.infradead.org>

Add GPMC timings for 104MHz OneNAND.

Signed-off-by: Adrian Hunter <adrian.hunter at nokia.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c |    9 +++++++++
 drivers/mtd/onenand/omap2.c        |    3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 1db606c..3a7d25f 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -173,6 +173,15 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
 	}
 
 	switch (freq) {
+	case 104:
+		min_gpmc_clk_period = 9600; /* 104 MHz */
+		t_ces   = 3;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 3;
+		t_aavdh = 6;
+		t_rdyo  = 9;
+		break;
 	case 83:
 		min_gpmc_clk_period = 12000; /* 83 MHz */
 		t_ces   = 5;
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 9f322f1..d0894ca 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -721,6 +721,9 @@ static int __devinit omap2_onenand_probe(struct platform_device *pdev)
 	case 3:
 		c->freq = 83;
 		break;
+	case 4:
+		c->freq = 104;
+		break;
 	}
 
 #ifdef CONFIG_MTD_PARTITIONS
-- 
1.7.0.4



From tony at atomide.com  Tue Dec 21 15:18:31 2010
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 21 Dec 2010 12:18:31 -0800
Subject: [PATCH 0/2] Add 104MHz support for OMAP OneNAND
In-Reply-To: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
References: <20101221194433.3127.74744.sendpatchset@ahunter-work.research.nokia.com>
Message-ID: <20101221201831.GI5829@atomide.com>

* Adrian Hunter <adrian.hunter at nokia.com> [101221 11:44]:
> Hi
> 
> Here is OMAP2/3: OneNAND: add 104MHz support.
> 
> Adrian Hunter (2):
>       OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
>       OMAP2/3: OneNAND: add 104MHz support

Gave these a quick try and the GPMC changes work fine for smc91x
on 2430sdp and tusb6010 g_ether for n810.  So I'll queue these,
thanks.

Tony


From prakity at marvell.com  Wed Dec 22 02:07:46 2010
From: prakity at marvell.com (Philip Rakity)
Date: Tue, 21 Dec 2010 23:07:46 -0800
Subject: [PATCH 3/23]  Alternative mmc structure to support pxa168, pxa910,
	mmp2 family SD
Message-ID: <B8EC55D2-F154-492D-AF7C-39A779B4E740@marvell.com>


From prakity at marvell.com  Sun Dec 19 22:08:31 2010
From: prakity at marvell.com (Philip Rakity)
Date: Sun, 19 Dec 2010 19:08:31 -0800
Subject: [PATCH] sdhci: delete clk gating code since not correct
Message-ID: <mailman.75.1293001975.1530.linux-mtd@lists.infradead.org>

clock gating is using wrong registers for mmp2.
remove code -- future patch will add back support

Signed-off-by: Philip Rakity <prakity at marvell.com>
Signed-off-by: Mark F. Brown <markb at marvell.com>
---
 arch/arm/plat-pxa/include/plat/sdhci.h |    1 -
 drivers/mmc/host/sdhci-pxa.c           |    9 ---------
 2 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-pxa/include/plat/sdhci.h b/arch/arm/plat-pxa/inc=
lude/plat/sdhci.h
index 1ab332e..270fb2b 100644
--- a/arch/arm/plat-pxa/include/plat/sdhci.h
+++ b/arch/arm/plat-pxa/include/plat/sdhci.h
@@ -15,7 +15,6 @@
=20
 /* pxa specific flag */
 /* Require clock free running */
-#define PXA_FLAG_DISABLE_CLOCK_GATING (1<<0)
=20
 /* Board design supports 8-bit data on SD/SDIO BUS */
 #define PXA_FLAG_SD_8_BIT_CAPABLE_SLOT (1<<2)
diff --git a/drivers/mmc/host/sdhci-pxa.c b/drivers/mmc/host/sdhci-pxa.c
index 5a61208..4713238 100644
--- a/drivers/mmc/host/sdhci-pxa.c
+++ b/drivers/mmc/host/sdhci-pxa.c
@@ -29,9 +29,6 @@
=20
 #define DRIVER_NAME	"sdhci-pxa"
=20
-#define SD_FIFO_PARAM		0x104
-#define DIS_PAD_SD_CLK_GATE	0x400
-
 struct sdhci_pxa {
 	struct sdhci_host		*host;
 	struct sdhci_pxa_platdata	*pdata;
@@ -49,7 +46,6 @@ struct sdhci_pxa {
 static void set_clock(struct sdhci_host *host, unsigned int clock)
 {
 	struct sdhci_pxa *pxa =3D sdhci_priv(host);
-	u32 tmp =3D 0;
=20
 	if (clock =3D=3D 0) {
 		if (pxa->clk_enable) {
@@ -58,11 +54,6 @@ static void set_clock(struct sdhci_host *host, unsigned =
int clock)
 		}
 	} else {
 		if (0 =3D=3D pxa->clk_enable) {
-			if (pxa->pdata->flags & PXA_FLAG_DISABLE_CLOCK_GATING) {
-				tmp =3D readl(host->ioaddr + SD_FIFO_PARAM);
-				tmp |=3D DIS_PAD_SD_CLK_GATE;
-				writel(tmp, host->ioaddr + SD_FIFO_PARAM);
-			}
 			clk_enable(pxa->clk);
 			pxa->clk_enable =3D 1;
 		}
--=20
1.6.0.4



--_002_B8EC55D2F154492DAF7C39A779B4E740marvellcom_
Content-Type: application/octet-stream;
	name="0003-sdhci-delete-clk-gating-code-since-not-correct.patch"
Content-Description: 0003-sdhci-delete-clk-gating-code-since-not-correct.patch
Content-Disposition: attachment;
	filename="0003-sdhci-delete-clk-gating-code-since-not-correct.patch";
	size=2012; creation-date="Tue, 21 Dec 2010 23:07:47 GMT";
	modification-date="Tue, 21 Dec 2010 23:07:47 GMT"
Content-Transfer-Encoding: base64


CQl9Ci0tIAoxLjYuMC40Cgo=

--_002_B8EC55D2F154492DAF7C39A779B4E740marvellcom_--


From s-ghorai at ti.com  Wed Dec 22 02:43:13 2010
From: s-ghorai at ti.com (Ghorai, Sukumar)
Date: Wed, 22 Dec 2010 13:13:13 +0530
Subject: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage
In-Reply-To: <201012201045.53688.manningc2@actrix.gen.nz>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<201012201045.53688.manningc2@actrix.gen.nz>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B036A3B0397@dbde02.ent.ti.com>



> -----Original Message-----
> From: Charles Manning [mailto:manningc2 at actrix.gen.nz]
> Sent: Monday, December 20, 2010 3:16 AM
> To: linux-mtd at lists.infradead.org
> Cc: Ghorai, Sukumar; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v6 0/7] nand prefetch-irq support and ecc layout
> chanage
> 
> On Saturday 27 November 2010 04:34:30 Sukumar Ghorai wrote:
> > The following set of patches applies on linux-2.6.
> >
> > The main motivations behind this patch series are -
> >         1. support NAND I/O in irq mode.
> >         2. support of different ECC schema.
> >         3. also to make ecc layout as like in romcode ecc layout
> 
> Why change the ECC layout?
> 
> Be very careful when you change ECC layouts. This can break production
> systems.
> 
> For example if people are running something earlier and then want to
> deliver a
> new kernel with 2.6.37 then their existing NAND file systems will no
> longer
> be readable.
> 
> Changes to ECC should only be done for very good reasons and should be
> controlled with a Kconfig with the default being the existing ECC layout.
> 
[Ghorai] we are just adding few ecc-layout(s) and based on the request from different customer. The default ecc-layout is the old one for backward compatibility and selection of ecc-layput is exposed form board file.  



From s-ghorai at ti.com  Wed Dec 22 02:52:12 2010
From: s-ghorai at ti.com (Ghorai, Sukumar)
Date: Wed, 22 Dec 2010 13:22:12 +0530
Subject: [PATCH 2/7] omap3: nand: configurable transfer type per board
In-Reply-To: <20101218000845.GW5941@atomide.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-3-git-send-email-s-ghorai@ti.com>
	<20101218000845.GW5941@atomide.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B036A3B03A5@dbde02.ent.ti.com>



> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Saturday, December 18, 2010 5:39 AM
> To: Ghorai, Sukumar
> Cc: linux-omap at vger.kernel.org; linux-mtd at lists.infradead.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 2/7] omap3: nand: configurable transfer type per board
> 
> * Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> > nand transfer type (sDMA, Polled, prefetch) can be select from board
> file,
> > enabling all transfer type in driver, by default.
> >
> > this helps in multi-omap build and to select different transfer type for
> > different board.
> >
> > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> > ---
> >  arch/arm/plat-omap/include/plat/nand.h |    7 +++
> >  drivers/mtd/nand/Kconfig               |   17 ------
> >  drivers/mtd/nand/omap2.c               |   92 +++++++++++--------------
> ------
> >  3 files changed, 40 insertions(+), 76 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-
> omap/include/plat/nand.h
> > index 6562cd0..78c0bdb 100644
> > --- a/arch/arm/plat-omap/include/plat/nand.h
> > +++ b/arch/arm/plat-omap/include/plat/nand.h
> > @@ -10,6 +10,12 @@
> >
> >  #include <linux/mtd/partitions.h>
> >
> > +enum nand_io {
> > +	NAND_OMAP_PREFETCH_POLLED = 0,	/* prefetch polled mode, default
> */
> > +	NAND_OMAP_POLLED,		/* polled mode, without prefetch */
> > +	NAND_OMAP_PREFETCH_DMA		/* prefetch enabled sDMA mode */
> > +};
> > +
> >  struct omap_nand_platform_data {
> >  	unsigned int		options;
> >  	int			cs;
> > @@ -20,6 +26,7 @@ struct omap_nand_platform_data {
> >  	int			(*nand_setup)(void);
> >  	int			(*dev_ready)(struct omap_nand_platform_data *);
> >  	int			dma_channel;
> > +	enum nand_io		xfer_type;
> >  	unsigned long		phys_base;
> >  	int			devsize;
> >  };
> 
> So maybe the devsize in patch 1/7 should be handled with this too?

[Ghorai] patch 1/7 [1] is to select the NAND type i.e. x8 or x16 NAND; 
So I am keeping as separate patch. And let me know if I am missing anything.
 
[1] https://patchwork.kernel.org/patch/359092/



From s-ghorai at ti.com  Wed Dec 22 03:00:43 2010
From: s-ghorai at ti.com (Ghorai, Sukumar)
Date: Wed, 22 Dec 2010 13:30:43 +0530
Subject: [PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc
In-Reply-To: <20101218000954.GX5941@atomide.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-4-git-send-email-s-ghorai@ti.com>
	<20101218000954.GX5941@atomide.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B036A3B03AF@dbde02.ent.ti.com>



> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Saturday, December 18, 2010 5:40 AM
> To: Ghorai, Sukumar
> Cc: linux-omap at vger.kernel.org; linux-mtd at lists.infradead.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc
> 
> * Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> > add support the irq mode in GPMC.
> > gpmc_init() function move after omap_init_irq() as it has dependecy on
> irq.
> >
> > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> > ---
> >  arch/arm/mach-omap2/board-2430sdp.c        |    1 +
> >  arch/arm/mach-omap2/board-3430sdp.c        |    1 +
> >  arch/arm/mach-omap2/board-3630sdp.c        |    1 +
> >  arch/arm/mach-omap2/board-4430sdp.c        |    2 +
> >  arch/arm/mach-omap2/board-am3517evm.c      |    2 +
> >  arch/arm/mach-omap2/board-apollon.c        |    1 +
> >  arch/arm/mach-omap2/board-cm-t35.c         |    1 +
> >  arch/arm/mach-omap2/board-devkit8000.c     |    1 +
> >  arch/arm/mach-omap2/board-generic.c        |    2 +
> >  arch/arm/mach-omap2/board-h4.c             |    1 +
> >  arch/arm/mach-omap2/board-igep0020.c       |    1 +
> >  arch/arm/mach-omap2/board-ldp.c            |    1 +
> >  arch/arm/mach-omap2/board-n8x0.c           |    2 +
> >  arch/arm/mach-omap2/board-omap3beagle.c    |    1 +
> >  arch/arm/mach-omap2/board-omap3evm.c       |    2 +
> >  arch/arm/mach-omap2/board-omap3pandora.c   |    2 +
> >  arch/arm/mach-omap2/board-omap3stalker.c   |    1 +
> >  arch/arm/mach-omap2/board-omap3touchbook.c |    1 +
> >  arch/arm/mach-omap2/board-omap4panda.c     |    2 +
> >  arch/arm/mach-omap2/board-overo.c          |    1 +
> >  arch/arm/mach-omap2/board-rx51.c           |    1 +
> >  arch/arm/mach-omap2/board-zoom2.c          |    2 +
> >  arch/arm/mach-omap2/board-zoom3.c          |    2 +
> >  arch/arm/mach-omap2/gpmc.c                 |   39
> ++++++++++++++++++++++++++-
> >  arch/arm/mach-omap2/io.c                   |    2 -
> >  arch/arm/plat-omap/include/plat/gpmc.h     |    4 +++
> >  arch/arm/plat-omap/include/plat/irqs.h     |    9 +++++-
> >  27 files changed, 81 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
> omap2/board-2430sdp.c
> > index b527f8d..11c89dc 100644
> > --- a/arch/arm/mach-omap2/board-2430sdp.c
> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
> > @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void)
> >  	omap_board_config_size = ARRAY_SIZE(sdp2430_config);
> >  	omap2_init_common_hw(NULL, NULL);
> >  	omap_init_irq();
> > +	gpmc_init();
> >  	omap_gpio_init();
> >  }
> >
> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
> omap2/board-3430sdp.c
> > index 4e3742c..a040165 100644
> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
> >  	omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
> >  	omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
> >  	omap_init_irq();
> > +	gpmc_init();
> >  	omap_gpio_init();
> >  }
> ...
> 
> The gpmc init should be done with subsys_initcall instead.

[Ghorai] You suggested the same in previous v5; and I mentioned 
the issues [1] that - nand_init()called before subsys_initcall(gpmc_init);
Let me know if I am missing anything again.
 
[1] https://patchwork.kernel.org/patch/212452/



From s-ghorai at ti.com  Wed Dec 22 04:24:07 2010
From: s-ghorai at ti.com (Ghorai, Sukumar)
Date: Wed, 22 Dec 2010 14:54:07 +0530
Subject: [PATCH 1/7] omap3630: nand: fix device size to work in polled mode
In-Reply-To: <20101218000344.GV5941@atomide.com>
References: <1290785677-16005-1-git-send-email-s-ghorai@ti.com>
	<1290785677-16005-2-git-send-email-s-ghorai@ti.com>
	<20101218000344.GV5941@atomide.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B036A3B0463@dbde02.ent.ti.com>



> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Saturday, December 18, 2010 5:34 AM
> To: Ghorai, Sukumar
> Cc: linux-omap at vger.kernel.org; linux-mtd at lists.infradead.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/7] omap3630: nand: fix device size to work in polled
> mode
> 
> * Sukumar Ghorai <s-ghorai at ti.com> [101126 07:25]:
> > zoom3 and 3630-sdp having the x16 nand device.
> > This patch configure gpmc as x16 and select the currect function in
> driver
> > for polled mode (without prefetch enable) transfer.
> >
> > Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
> > ---
> >  arch/arm/mach-omap2/board-flash.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-
> omap2/board-flash.c
> > index fd38c05..001c605 100644
> > --- a/arch/arm/mach-omap2/board-flash.c
> > +++ b/arch/arm/mach-omap2/board-flash.c
> > @@ -145,6 +145,9 @@ __init board_nand_init(struct mtd_partition
> *nand_parts, u8 nr_parts, u8 cs)
> >  	board_nand_data.parts		= nand_parts;
> >  	board_nand_data.nr_parts		= nr_parts;
> >
> > +	if (cpu_is_omap3630())
> > +		board_nand_data.devsize = 1;
> > +
> >  	gpmc_nand_init(&board_nand_data);
> >  }
> >  #else
> 
> I guess this is board specific for the size, not omap specific?
[Ghorai] Agree, the NAND type (i.e. x8 NAND or x16 NAND) is a board specific,
So I will change the definition of board_nand_init() to pass the devsize form board file.
And I will submit the patch-series again.


From boaz.bd at wellsense-tech.com  Wed Dec 22 09:36:03 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Wed, 22 Dec 2010 16:36:03 +0200
Subject: UBIFS reboots issue
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>

Hi all,

We have an embedded system using a Samsung 2GB MLC NAND and are using
UBIFS as the file system on it.
I have a question regarding UBIFS and hard reboots.
After some work with the flash (doing reads and writes to it), some
times one of our partitions would fail to mount.
I suspected this has something to do with a reboot which happens during
a write to the flash.
In order to test this I created a simple script which copies a file from
to the partition, syncs, then deletes it and does this repeatedly until 
a hard reboot occurs (using the watch dog to cause the boot).
This process repeats itself until the partition fails to mount.
When I performed the test mentioned above, after about 3-4 times the
partition would fail.
I am not sure if this behaviour is normal or not.
Did someone encounter similiar behaviour?

Thanks,

Boaz. 

From dedekind1 at gmail.com  Wed Dec 22 09:40:42 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 22 Dec 2010 16:40:42 +0200
Subject: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
In-Reply-To: <20101220140454.GA26229@falooley.org>
References: <20101207072919.GA8511@falooley.org>
	<AANLkTineLxHdcDKZEUGiqVNAauSX_xyQrs49kKaqhiWo@mail.gmail.com>
	<20101207182012.GA10546@falooley.org>
	<1292343878.2538.80.camel@localhost>
	<20101214195124.GA6010@falooley.org> <20101216230110.65156c55@wker>
	<20101217042759.GA3148@falooley.org> <1292777276.2140.1.camel@koala>
	<20101219190720.GA16710@falooley.org> <1292844216.13362.19.camel@koala>
	<20101220140454.GA26229@falooley.org>
Message-ID: <1293028842.12773.15.camel@localhost>

On Mon, 2010-12-20 at 09:04 -0500, Jason Lunz wrote:
> On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote:
> > Ok, could you please re-sent the final patch with the commit message
> > etc?
> 
> Sure, here's everything as a single patch.
> 
> ------------------------------------->8
> Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM
> dependencies down closer to the parts of mtd that actually need it.
> This allows enough of mtd to build to let jffs2 be used on uml.
> 
> Signed-off-by: Jason Lunz <lunz at acm.org>

OK, taken this one, thanks.

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



From dedekind1 at gmail.com  Wed Dec 22 09:43:12 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 22 Dec 2010 16:43:12 +0200
Subject: Huge ubi or ubifs sync slowdown since 2.6.32
In-Reply-To: <201012211136.22254.manningc2@actrix.gen.nz>
References: <201012211136.22254.manningc2@actrix.gen.nz>
Message-ID: <1293028992.12773.18.camel@localhost>

On Tue, 2010-12-21 at 11:36 +1300, Charles Manning wrote:
> Hi All
> 
> I've been looking into a ubifs performance regression on linux-omap 2.6.37.
> 
> My test is pretty simple, copy a 2Mbyte file and sync.
> 
> # sync; date; cp 2Mbyte-file foo; sync; date
> 
> On 2.6.32 and earler, the time between the two dates was around 3 seconds.
> On linux-omap master it is around 14 seconds. Ouch!
> 
> At first I thought the problem was due to changes in the OMAP nand drivers, 
> but raw randwrite speed is actually a bit faster. This suggest the finger 
> should be pointed at ubi or ubifs.
> 
> I then thought that perhaps the layout of my ubinized image might be a 
> contributing factor so I erased the partition, ubiformatted and ubimkvoled. 
> The problem persisted,
> 
> Any suggestions as to what might be broken or how to debug this deeper?

Can you try this on nandsim and see if there are still differences? You
can make nandsim slower by injecting an udelay somewhere. Try this on
your x86 host - this way you'll narrow this down to an OMAP-specific or
platform-independent problem.

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



From siribarne at grid-net.com  Wed Dec 22 11:37:19 2010
From: siribarne at grid-net.com (Steve Iribarne)
Date: Wed, 22 Dec 2010 08:37:19 -0800
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
Message-ID: <4D12293F.3090008@grid-net.com>

On 12/22/2010 06:36 AM, Boaz Ben-David wrote:
> Hi all,
>
> We have an embedded system using a Samsung 2GB MLC NAND and are using
> UBIFS as the file system on it.
> I have a question regarding UBIFS and hard reboots.
> After some work with the flash (doing reads and writes to it), some
> times one of our partitions would fail to mount.
> I suspected this has something to do with a reboot which happens during
> a write to the flash.
> In order to test this I created a simple script which copies a file from
> to the partition, syncs, then deletes it and does this repeatedly until
> a hard reboot occurs (using the watch dog to cause the boot).
> This process repeats itself until the partition fails to mount.
> When I performed the test mentioned above, after about 3-4 times the
> partition would fail.
> I am not sure if this behaviour is normal or not.
> Did someone encounter similiar behaviour?

What is the error when it tries to remount?


From fggs at terra.com.br  Wed Dec 22 11:43:50 2010
From: fggs at terra.com.br (=?iso-8859-1?Q?Fl=E1vio_Silveira?=)
Date: Wed, 22 Dec 2010 14:43:50 -0200
Subject: Trying to patch dd-wrt kernel to support SST39VF6401B
Message-ID: <4AF29211F3A744AF96CFEAB3B5A7339F@THOR>

Hi, I'm trying to patch this kernel (2.6.26) with the patch provided by 
Guillaume Lecerf for current kernel.

I'm stuck with patching cfi_util.c file, as it's very different. Can 
somebody help?

Patch and cfi_util.c attached! 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfi_util.c
Type: application/octet-stream
Size: 4254 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101222/d5a70c23/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfi_util-add-support-for-switc.patch
Type: application/octet-stream
Size: 1046 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101222/d5a70c23/attachment-0001.obj>

From boaz.bd at wellsense-tech.com  Wed Dec 22 12:32:20 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Wed, 22 Dec 2010 19:32:20 +0200
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF776745@SBS2008.wellsense.local>

I can't seem to post back...

On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> Hi all,
> 
> We have an embedded system using a Samsung 2GB MLC NAND and are using
> UBIFS as the file system on it.
> I have a question regarding UBIFS and hard reboots.
> After some work with the flash (doing reads and writes to it), some
> times one of our partitions would fail to mount.
> I suspected this has something to do with a reboot which happens during
> a write to the flash.
> In order to test this I created a simple script which copies a file from
> to the partition, syncs, then deletes it and does this repeatedly until 
> a hard reboot occurs (using the watch dog to cause the boot).
> This process repeats itself until the partition fails to mount.
> When I performed the test mentioned above, after about 3-4 times the
> partition would fail.
> I am not sure if this behaviour is normal or not.
> Did someone encounter similiar behaviour?
> 
> Thanks,
> 
> Boaz. 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From boaz.bd at wellsense-tech.com  Wed Dec 22 12:35:32 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Wed, 22 Dec 2010 19:35:32 +0200
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF776745@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
	<39A4B204C321D34DA3490E3B119D5A6C68BF776745@SBS2008.wellsense.local>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF776746@SBS2008.wellsense.local>

Ok, got it.

Here is the ubiattach and mount outputs:

attaching mtd7 to ubi2
UBI: physical eraseblock size:   524288 bytes (512 KiB)
UBI: logical eraseblock size:    516096 bytes
UBI: smallest flash I/O unit:    4096
UBI: VID header offset:          4096 (aligned 4096)
UBI: data offset:                8192
UBI: attached mtd7 to ubi2
UBI: MTD device name:            "nand.db"
UBI: MTD device size:            1648 MiB
UBI: number of good PEBs:        3291
UBI: number of bad PEBs:         5
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:             0
UBI: total number of reserved PEBs: 3291
UBI: number of PEBs reserved for bad PEB handling: 32
UBI: max/mean erase counter: 237/11
UBI: image sequence number: 0
UBI: background thread "ubi_bgt2d" started, PID 1326
UBI device number 2, total 3291 LEBs (1698471936 bytes, 1.6 GiB),
available 0 LEBs (0 bytes), LEB size 516096 bytes (504.0 KiB)
UBIFS: recovery needed
UnCorrectable RS-ECC Error
UBI error: ubi_io_read: error -74 while reading 516096 bytes from PEB
2237:8192, read 516096 bytes
UBIFS error (pid 1328): ubifs_check_node: bad node length 9
UBIFS error (pid 1328): ubifs_check_node: bad node at LEB 244:360448
Unable to handle kernel paging request at virtual address c93d5000
pgd = c56a8000
[c93d5000] *pgd=85618011, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.31-207-g7286c01-hg639121a71164-dirty #49)
PC is at hex_dump_to_buffer+0x164/0x270
LR is at hex_dump_to_buffer+0x48/0x270
pc : [<c03bb9a4>]    lr : [<c03bb888>]    psr: 80000013
sp : c56c9a80  ip : 0000000f  fp : 00000000
r10: 000000c8  r9 : 00000001  r8 : c56c9ac8
r7 : 00000020  r6 : c93d4ff0  r5 : 00000020  r4 : 00000030
r3 : 00000010  r2 : 00000033  r1 : c56c9afb  r0 : 00000020
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 856a8008  DAC: 00000015
Process mount (pid: 1328, stack limit = 0xc56c8268)
Stack: (0xc56c9a80 to 0xc56ca000)
9a80: c93d4ff0 fffda019 00000020 00000020 00025fc0 c93d4ff0 c56c9ac8
c0627fe8 
9aa0: fffda019 c06450d3 00000002 c03bbb20 c56c9ac8 000000c8 00000000
c062e3f8 
9ac0: ffffffd8 00000000 66206666 66662066 20666620 66206666 66662066
20666620 
9ae0: 66206666 66662066 20666620 66206666 66662066 20666620 66206666
66662066 
9b00: 20666620 66206666 66662066 20666620 66206666 66662066 20666620
66206666 
9b20: 66662066 00666620 c56c9b30 c025630c ffffffff 60000013 ffffffff
ffffffff 
9b40: 00000000 00000000 ffffffff 0000000a ffffffff ffffffff 00000000
c56c9bf0 
9b60: 0000a78f c06f81dc 00058000 000000f4 c56ad3e0 c93af030 ffffffd9
c5312000 
9b80: 00058000 000000f4 c56ad3e0 00000000 00000009 c93af030 ffffffd9
c5312000 
9ba0: 00058000 000000f4 c56ad3e0 00000000 00000009 c03903ac 00000001
c93af030 
9bc0: ffffffd9 00000000 00000050 000000f4 c0694378 c93af000 ffffffea
c5312000 
9be0: 00058000 000000f4 c56ad3e0 00000000 0000004b 2000a78f c93af000
ffffffea 
9c00: c5312000 00058000 000000f4 c56ad3e0 00000000 c0366dc8 00058000
c93af000 
9c20: 06101831 c93af000 00058000 c5312000 000000f4 c036edf0 00000000
00000001 
9c40: c5312000 c93af000 c56c8000 000000f4 fffffffd c56ad3e0 00058000
c03865b0 
9c60: 00058000 00000000 00000000 00000000 c9357000 00026000 00000001
00058000 
9c80: c93af000 00026000 c0694378 c56c8000 00000000 c5312000 00000000
c59615a4 
9ca0: 00000002 000000f4 c56ad520 c036f7b8 00000001 c069f3b8 004f4dfa
00000000 
9cc0: 00000000 c56c9d44 00000000 00000000 0a78dace 00000000 00000020
c04348f4 
9ce0: 00000001 c596159c 00000040 00000000 004f4cbf 00000000 c5312844
00000000 
9d00: c56ad3e8 c5312850 00000002 c5960c9c 004f4daf 00000000 00000005
0000004b 
9d20: 0005a000 00000040 00078380 00000000 00000000 00000000 c56c8000
c036f21c 
9d40: 00000000 00000000 00000000 c5312000 c56c8000 c56ad3e8 c56ad3e0
00000005 
9d60: c56ad540 00000001 c5312850 c0370c5c 00000032 00000000 c56c9dec
c57c1400 
9d80: 00000400 c02b8898 c56c9da4 c02b8900 c56ad3a0 c02b8a04 00000400
00000000 
9da0: c56ad3e0 c57c15f8 c531276c c56ad3e8 c94e0000 00000001 00079000
00000002 
9dc0: c56c9de8 c02b8be8 00000020 c5312850 00000165 00000000 004f4dfc
00000000 
9de0: 00000000 00000001 c945a00c 00000000 00001000 c53126e0 c5312000
00000000 
9e00: c5320800 00000000 00000001 00000000 c531271c c0362f88 00000000
00000005 
9e20: c5320964 c0626c44 c06ed480 c5320964 00000005 c03b8bd8 c56c9e50
c56c8000 
9e40: 00000000 c06a80b0 c5320800 c02c77d0 c5216800 00000002 00000007
c5312724 
9e60: 00000003 c5312008 c5216800 c56ad1c0 c5320800 00008000 c06a80b0
c56c9edc 
9e80: c56b0000 c06a97f4 c56c9f48 c036448c c56c8000 c03b426c 00000002
00000000 
9ea0: 00000cb7 c02dca68 64212000 00000000 c569e000 00000003 00000000
00000000 
9ec0: 00000001 0007e000 00000004 c5320524 0f600001 c06eda30 c569e000
c569e005 
9ee0: c7f6c900 c569e000 c56b0000 00008000 c06a80b0 c7f06000 00008000
c02c6a30 
9f00: c7f6c900 00008000 c06a80b0 c7f06000 c56b0000 c569e000 00008000
c02c6ac0 
9f20: 00000000 00000020 c569e000 00008000 c56b0000 c02ddc40 c56c9f8c
c56c8000 
9f40: 00000003 00000000 c7e20000 c627c080 c029e408 c5317000 bef7ce39
00008000 
9f60: 00000000 c0232f44 c56c8000 00000003 00000000 c02ddd38 c56b0000
000a1000 
9f80: 000c2000 c569e000 c7f06000 c56b0000 bef7cb18 000a1018 bef7cb18
400214d0 
9fa0: 00000015 c0232dc0 000a1018 bef7cb18 bef7ce39 bef7ce43 bef7ce33
00008000 
9fc0: 000a1018 bef7cb18 400214d0 00000015 00000000 00000000 00000003
00000000 
9fe0: 000a1018 bef7ca34 0004076c 40101634 60000010 bef7ce39 00000000
00000000 
[<c03bb9a4>] (hex_dump_to_buffer+0x164/0x270) from [<c03bbb20>]
(print_hex_dump+0x70/0xf8)
[<c03bbb20>] (print_hex_dump+0x70/0xf8) from [<c03903ac>] (dbg_dump_node
+0xf50/0x13cc)
[<c03903ac>] (dbg_dump_node+0xf50/0x13cc) from [<c0366dc8>]
(ubifs_check_node+0x290/0x2e8)
[<c0366dc8>] (ubifs_check_node+0x290/0x2e8) from [<c036edf0>]
(ubifs_scan_a_node+0x21c/0x3d4)
[<c036edf0>] (ubifs_scan_a_node+0x21c/0x3d4) from [<c03865b0>]
(ubifs_recover_leb+0x16c/0xacc)
[<c03865b0>] (ubifs_recover_leb+0x16c/0xacc) from [<c036f7b8>]
(replay_buds+0xdc/0xb50)
[<c036f7b8>] (replay_buds+0xdc/0xb50) from [<c0370c5c>]
(ubifs_replay_journal+0xa30/0x127c)
[<c0370c5c>] (ubifs_replay_journal+0xa30/0x127c) from [<c0362f88>]
(ubifs_fill_super+0xc50/0x1e70)
[<c0362f88>] (ubifs_fill_super+0xc50/0x1e70) from [<c036448c>]
(ubifs_get_sb+0x2e4/0x358)
[<c036448c>] (ubifs_get_sb+0x2e4/0x358) from [<c02c6a30>]
(vfs_kern_mount+0x4c/0x98)
[<c02c6a30>] (vfs_kern_mount+0x4c/0x98) from [<c02c6ac0>] (do_kern_mount
+0x34/0xd8)
[<c02c6ac0>] (do_kern_mount+0x34/0xd8) from [<c02ddc40>] (do_mount
+0x710/0x784)
[<c02ddc40>] (do_mount+0x710/0x784) from [<c02ddd38>] (sys_mount
+0x84/0xcc)
[<c02ddd38>] (sys_mount+0x84/0xcc) from [<c0232dc0>] (ret_fast_syscall
+0x0/0x2c)
Code: e1570009 bafffff0 e3a07005 ea000013 (e7d6c003) 
---[ end trace 977c7948905d1436 ]---
note: mount[1328] exited with preempt_count 2
BUG: scheduling while atomic: mount/1328/0x40000002
Modules linked in:
[<c02375f8>] (unwind_backtrace+0x0/0xd0) from [<c0563f80>] (schedule
+0x78/0x3e4)
[<c0563f80>] (schedule+0x78/0x3e4) from [<c024f4d8>] (__cond_resched
+0x24/0x40)
[<c024f4d8>] (__cond_resched+0x24/0x40) from [<c05643b8>] (_cond_resched
+0x30/0x40)
[<c05643b8>] (_cond_resched+0x30/0x40) from [<c02b0238>] (unmap_vmas
+0x528/0x5d8)
[<c02b0238>] (unmap_vmas+0x528/0x5d8) from [<c02b2ce8>] (exit_mmap
+0xac/0x198)
[<c02b2ce8>] (exit_mmap+0xac/0x198) from [<c0252ff4>] (mmput+0x38/0xf8)
[<c0252ff4>] (mmput+0x38/0xf8) from [<c0256bb4>] (exit_mm+0x140/0x144)
[<c0256bb4>] (exit_mm+0x140/0x144) from [<c0258260>] (do_exit
+0x15c/0x6bc)
[<c0258260>] (do_exit+0x15c/0x6bc) from [<c0236500>] (die+0x168/0x188)
[<c0236500>] (die+0x168/0x188) from [<c02385c4>] (__do_kernel_fault
+0x64/0x74)
[<c02385c4>] (__do_kernel_fault+0x64/0x74) from [<c02387e8>]
(do_page_fault+0x214/0x230)
[<c02387e8>] (do_page_fault+0x214/0x230) from [<c023225c>] (do_DataAbort
+0x30/0x94)
[<c023225c>] (do_DataAbort+0x30/0x94) from [<c02329ec>] (__dabt_svc
+0x4c/0x60)
Exception stack(0xc56c9a38 to 0xc56c9a80)
9a20:                                                       00000020
c56c9afb 
9a40: 00000033 00000010 00000030 00000020 c93d4ff0 00000020 c56c9ac8
00000001 
9a60: 000000c8 00000000 0000000f c56c9a80 c03bb888 c03bb9a4 80000013
ffffffff 
[<c02329ec>] (__dabt_svc+0x4c/0x60) from [<c03bb9a4>]
(hex_dump_to_buffer+0x164/0x270)
[<c03bb9a4>] (hex_dump_to_buffer+0x164/0x270) from [<c03bbb20>]
(print_hex_dump+0x70/0xf8)
[<c03bbb20>] (print_hex_dump+0x70/0xf8) from [<c03903ac>] (dbg_dump_node
+0xf50/0x13cc)
[<c03903ac>] (dbg_dump_node+0xf50/0x13cc) from [<c0366dc8>]
(ubifs_check_node+0x290/0x2e8)
[<c0366dc8>] (ubifs_check_node+0x290/0x2e8) from [<c036edf0>]
(ubifs_scan_a_node+0x21c/0x3d4)
[<c036edf0>] (ubifs_scan_a_node+0x21c/0x3d4) from [<c03865b0>]
(ubifs_recover_leb+0x16c/0xacc)
[<c03865b0>] (ubifs_recover_leb+0x16c/0xacc) from [<c036f7b8>]
(replay_buds+0xdc/0xb50)
[<c036f7b8>] (replay_buds+0xdc/0xb50) from [<c0370c5c>]
(ubifs_replay_journal+0xa30/0x127c)
[<c0370c5c>] (ubifs_replay_journal+0xa30/0x127c) from [<c0362f88>]
(ubifs_fill_super+0xc50/0x1e70)
[<c0362f88>] (ubifs_fill_super+0xc50/0x1e70) from [<c036448c>]
(ubifs_get_sb+0x2e4/0x358)
[<c036448c>] (ubifs_get_sb+0x2e4/0x358) from [<c02c6a30>]
(vfs_kern_mount+0x4c/0x98)
[<c02c6a30>] (vfs_kern_mount+0x4c/0x98) from [<c02c6ac0>] (do_kern_mount
+0x34/0xd8)
[<c02c6ac0>] (do_kern_mount+0x34/0xd8) from [<c02ddc40>] (do_mount
+0x710/0x784)
[<c02ddc40>] (do_mount+0x710/0x784) from [<c02ddd38>] (sys_mount
+0x84/0xcc)
[<c02ddd38>] (sys_mount+0x84/0xcc) from [<c0232dc0>] (ret_fast_syscall
+0x0/0x2c)

Thanks!



On Wed, 2010-12-22 at 19:32 +0200, Boaz Ben-David wrote:
> I can't seem to post back...
> 
> On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> > Hi all,
> > 
> > We have an embedded system using a Samsung 2GB MLC NAND and are using
> > UBIFS as the file system on it.
> > I have a question regarding UBIFS and hard reboots.
> > After some work with the flash (doing reads and writes to it), some
> > times one of our partitions would fail to mount.
> > I suspected this has something to do with a reboot which happens during
> > a write to the flash.
> > In order to test this I created a simple script which copies a file from
> > to the partition, syncs, then deletes it and does this repeatedly until 
> > a hard reboot occurs (using the watch dog to cause the boot).
> > This process repeats itself until the partition fails to mount.
> > When I performed the test mentioned above, after about 3-4 times the
> > partition would fail.
> > I am not sure if this behaviour is normal or not.
> > Did someone encounter similiar behaviour?
> > 
> > Thanks,
> > 
> > Boaz. 
> > ______________________________________________________
> > 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 siribarne at grid-net.com  Wed Dec 22 13:09:25 2010
From: siribarne at grid-net.com (Steve Iribarne)
Date: Wed, 22 Dec 2010 10:09:25 -0800
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF776746@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>	<39A4B204C321D34DA3490E3B119D5A6C68BF776745@SBS2008.wellsense.local>
	<39A4B204C321D34DA3490E3B119D5A6C68BF776746@SBS2008.wellsense.local>
Message-ID: <4D123ED5.3080103@grid-net.com>

> Ok, got it.
>
> Here is the ubiattach and mount outputs:
>

I know we've seen this error... I'm asking someone else here what caused 
it...

UnCorrectable RS-ECC Error
UBI error: ubi_io_read: error -74 while reading 516096 bytes from PEB



I thought it was a bad flash part but not sure... I'll get back to you 
as soon as he answers.  He works remote today.

-stv


From boaz.bd at wellsense-tech.com  Wed Dec 22 13:53:27 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Wed, 22 Dec 2010 20:53:27 +0200
Subject: UBIFS reboots issue
In-Reply-To: <4D123ED5.3080103@grid-net.com>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
	<39A4B204C321D34DA3490E3B119D5A6C68BF776745@SBS2008.wellsense.local>
	<39A4B204C321D34DA3490E3B119D5A6C68BF776746@SBS2008.wellsense.local>,
	<4D123ED5.3080103@grid-net.com>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF77573C@SBS2008.wellsense.local>

Thanks for the quick reply.

About the bad flash part, I am not too sure this is the case.
We can reproduce this on every one of our devices, and also on the development board we used which has another (different part number) 
Samsung chip, also MLC.

Boaz.

________________________________________
From: linux-mtd-bounces at lists.infradead.org [linux-mtd-bounces at lists.infradead.org] On Behalf Of Steve Iribarne [siribarne at grid-net.com]
Sent: Wednesday, December 22, 2010 8:09 PM
To: linux-mtd at lists.infradead.org
Subject: Re: UBIFS reboots issue

> Ok, got it.
>
> Here is the ubiattach and mount outputs:
>

I know we've seen this error... I'm asking someone else here what caused
it...

UnCorrectable RS-ECC Error
UBI error: ubi_io_read: error -74 while reading 516096 bytes from PEB



I thought it was a bad flash part but not sure... I'll get back to you
as soon as he answers.  He works remote today.

-stv

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


From dedekind1 at gmail.com  Wed Dec 22 15:20:45 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Wed, 22 Dec 2010 22:20:45 +0200
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
Message-ID: <1293049245.2051.4.camel@koala>

On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> Hi all,
> 
> We have an embedded system using a Samsung 2GB MLC NAND and are using
> UBIFS as the file system on it.
> I have a question regarding UBIFS and hard reboots.
> After some work with the flash (doing reads and writes to it), some
> times one of our partitions would fail to mount.
> I suspected this has something to do with a reboot which happens during
> a write to the flash.
> In order to test this I created a simple script which copies a file from
> to the partition, syncs, then deletes it and does this repeatedly until 
> a hard reboot occurs (using the watch dog to cause the boot).
> This process repeats itself until the partition fails to mount.
> When I performed the test mentioned above, after about 3-4 times the
> partition would fail.
> I am not sure if this behaviour is normal or not.
> Did someone encounter similiar behaviour?

Just curious, did you see this:

http://linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc

I do not think you can just use UBI/UBIFS on MLC as is, you'd need to
make sure MLC-specific behavior is handled properly.

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



From liu.h.jason at gmail.com  Thu Dec 23 01:06:33 2010
From: liu.h.jason at gmail.com (Jason Liu)
Date: Thu, 23 Dec 2010 14:06:33 +0800
Subject: [PATCH 1/1] mtd: nand: add check for out of page read
In-Reply-To: <1292777645.13362.3.camel@koala>
References: <1290156045-11719-1-git-send-email-r64343@freescale.com>
	<1292340409.2538.40.camel@localhost>
	<AANLkTi=zB7UBjkvGYv_wdwZpH1Ghatn6eye1z5616h4X@mail.gmail.com>
	<1292777645.13362.3.camel@koala>
Message-ID: <AANLkTikSVLNaFOT55piRosOCyJ9uXQ85QD0u3w75UimU@mail.gmail.com>

Hi, Artem,

2010/12/20 Artem Bityutskiy <dedekind1 at gmail.com>:
> On Wed, 2010-12-15 at 09:55 +0800, Jason Liu wrote:
>> > ? ? ? ?/* Do not allow reads past end of device */
>> > ? ? ? ?if (unlikely(from >= mtd->size ||
>> > ? ? ? ? ? ? ? ? ? ? ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(from >> chip->page_shift)) * len)) {
>> > ? ? ? ? ? ? ? ?DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt read beyond end "
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"of device\n", __func__);
>> > ? ? ? ? ? ? ? ?return -EINVAL;
>> > ? ? ? ?}
>>
>> Here the mtd->size in nand_base.c should be the NAND flash chip size,
>
> I think this is partition size as well.

I think you are wrong. This should be the NAND flash chip size not the
partition size.

>
>> while in nand_oobtest,
>>
>> ? ? ? ? ? ? ? /* Attempt to read off end of device */
>> ? ? ? ? ? ? ? ? ops.mode ? ? ?= MTD_OOB_AUTO;
>> ? ? ? ? ? ? ? ? ops.len ? ? ? = 0;
>> ? ? ? ? ? ? ? ? ops.retlen ? ?= 0;
>> ? ? ? ? ? ? ? ? ops.ooblen ? ?= mtd->ecclayout->oobavail;
>> ? ? ? ? ? ? ? ? ops.oobretlen = 0;
>> ? ? ? ? ? ? ? ? ops.ooboffs ? = 1;
>> ? ? ? ? ? ? ? ? ops.datbuf ? ?= NULL;
>> ? ? ? ? ? ? ? ? ops.oobbuf ? ?= readbuf;
>> ? ? ? ? ? ? ? ? printk(PRINT_PREF "attempting to read past end of device\n");
>> ? ? ? ? ? ? ? ? printk(PRINT_PREF "an error is expected...\n");
>> ? ? ? ? ? ? ? ? err = mtd->read_oob(mtd, mtd->size - mtd->writesize, &ops);
>> ? ? ? ? ? ? ? ? if (err) {
>> ? ? ? ? ? ? ? ? ? ? ? ? printk(PRINT_PREF "error occurred as expected\n");
>> ? ? ? ? ? ? ? ? ? ? ? ? err = 0;
>> ? ? ? ? ? ? ? ? } else {
>> ? ? ? ? ? ? ? ? ? ? ? ? printk(PRINT_PREF "error: read past end of device\n");
>> ? ? ? ? ? ? ? ? ? ? ? ? errcnt += 1;
>> ? ? ? ? ? ? ? ? }
>> ? ? ? ? }
>>
>> here, mtd->size is mtd partition size right? when the mtd partition is
>> not the last MTD partition, the error will happen.
>
> I think this is the same in both. Try to debug this with printks().
>
>>
>> I have tested on real NAND, while not on nandsim.
>
> Please, try to reproduce this with nandsim as well, and if it works, try
> to find out why (using printk debugging)

Yes, I have reproduce this issue with nandsim, please check the following log,

root at freescale ~$ insmod nandsim.ko first_id_byte=0x20
second_id_byte=0xaa third_id_byte=0x00 fourth_id_byte=0x15
parts=0x400,0x400
[nandsim] warning: read_byte: unexpected data output cycle, state is
STATE_READY return 0x0
[nandsim] warning: read_byte: unexpected data output cycle, state is
STATE_READY return 0x0
[nandsim] warning: read_byte: unexpected data output cycle, state is
STATE_READY return 0x0
[nandsim] warning: read_byte: unexpected data output cycle, state is
STATE_READY return 0x0
NAND device: Manufacturer ID: 0x20, Chip ID: 0xaa (ST Micro NAND
256MiB 1,8V 8-bit)
flash size: 256 MiB
page size: 2048 bytes
OOB area size: 64 bytes
sector size: 128 KiB
pages number: 131072
pages per sector: 64
bus width: 8
bits in sector size: 17
bits in page size: 11
bits in OOB size: 6
flash size with OOB: 270336 KiB
page address bytes: 5
sector address bytes: 3
options: 0x8
Scanning device for bad blocks
Creating 2 MTD partitions on "NAND 256MiB 1,8V 8-bit":
0x000000000000-0x000008000000 : "NAND simulator partition 0"
0x000008000000-0x000010000000 : "NAND simulator partition 1"
root at freescale ~$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00300000 00080000 "bootloader"
mtd1: 00500000 00080000 "nand.kernel"
mtd2: 10000000 00080000 "nand.rootfs"
mtd3: 10000000 00080000 "nand.userfs1"
mtd4: df800000 00080000 "nand.userfs2"
mtd5: 08000000 00020000 "NAND simulator partition 0"
mtd6: 08000000 00020000 "NAND simulator partition 1"
root at freescale ~$ insmod mtd_oobtest.ko dev=5
=================================================
mtd_oobtest: MTD device: 5
mtd_oobtest: MTD device size 134217728, eraseblock size 131072, page
size 2048, count of eraseblocks 1024, pages per eraseblock
64, OOB size 64
mtd_oobtest: scanning for bad eraseblocks
mtd_oobtest: scanned 1024 eraseblocks, 0 are bad
mtd_oobtest: test 1 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 1024 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written 1024 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified 1024 eraseblocks
mtd_oobtest: test 2 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 1024 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written 1024 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified 1024 eraseblocks
mtd_oobtest: test 3 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 1024 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written 1024 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified 1024 eraseblocks
mtd_oobtest: test 4 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 1024 eraseblocks
mtd_oobtest: attempting to start write past end of OOB
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to start read past end of OOB
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to write past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to read past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error: read past end of device
mtd_oobtest: attempting to write past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to read past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error: read past end of device
mtd_oobtest: test 5 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 1024 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written 1023 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified 1023 eraseblocks
mtd_oobtest: finished with 2 errors
=================================================

>
> --
> Best Regards,
> Artem Bityutskiy (???????? ?????)
>
>


From tom.leiming at gmail.com  Thu Dec 23 03:24:35 2010
From: tom.leiming at gmail.com (Ming Lei)
Date: Thu, 23 Dec 2010 16:24:35 +0800
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
References: <ActfCy0cZc3bW9yIT5u5fx8oZO9GQw==>
	<2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
Message-ID: <AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>

Hi,

2010/9/28 Ghorai, Sukumar <s-ghorai at ti.com>:
> Hi,
> I was using the following ecc layout which is not working to mount the jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is not working with latest 2.6 kernel.
>
> Observation is that - no read request issued to the driver (say omap2.c).
>
> # mount -t jffs2 /dev/mtdblock4 /mnt/nand
> [?? 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes, read 0 bytes, error -22
> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error

I meet the issue too, kernel is  2.6.37-rc6-next-20101217+, and board is
beagle B5.

Is there any way to fix or workaround the issue?


thanks,
-- 
Lei Ming


From boaz.bd at wellsense-tech.com  Thu Dec 23 07:51:53 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Thu, 23 Dec 2010 14:51:53 +0200
Subject: UBIFS reboots issue
In-Reply-To: <1293049245.2051.4.camel@koala>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
	<1293049245.2051.4.camel@koala>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF77674A@SBS2008.wellsense.local>

I am using kernel 2.6.31 for iMX35 and I'm not sure what version of
UBIFS is patched in there.
What do I need to do in order to patch to the latest version? 
Is is enough to clone UBIFS 2.6.31 and copy over the fs/ubifs and
mtd/ubi directories or are there any other directories I need to take
into account?

Thanks,

Boaz.

On Wed, 2010-12-22 at 22:20 +0200, Artem Bityutskiy wrote:
> On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> > Hi all,
> > 
> > We have an embedded system using a Samsung 2GB MLC NAND and are using
> > UBIFS as the file system on it.
> > I have a question regarding UBIFS and hard reboots.
> > After some work with the flash (doing reads and writes to it), some
> > times one of our partitions would fail to mount.
> > I suspected this has something to do with a reboot which happens during
> > a write to the flash.
> > In order to test this I created a simple script which copies a file from
> > to the partition, syncs, then deletes it and does this repeatedly until 
> > a hard reboot occurs (using the watch dog to cause the boot).
> > This process repeats itself until the partition fails to mount.
> > When I performed the test mentioned above, after about 3-4 times the
> > partition would fail.
> > I am not sure if this behaviour is normal or not.
> > Did someone encounter similiar behaviour?
> 
> Just curious, did you see this:
> 
> http://linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc
> 
> I do not think you can just use UBI/UBIFS on MLC as is, you'd need to
> make sure MLC-specific behavior is handled properly.
> 
> -- 
> Best Regards,
> Artem Bityutskiy (???????? ?????)
> 


From manningc2 at actrix.gen.nz  Thu Dec 23 22:02:36 2010
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Fri, 24 Dec 2010 16:02:36 +1300
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
References: <ActfCy0cZc3bW9yIT5u5fx8oZO9GQw==>
	<2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
Message-ID: <201012241602.36582.manningc2@actrix.gen.nz>

On Thursday 23 December 2010 21:24:35 Ming Lei wrote:
> Hi,
>
> 2010/9/28 Ghorai, Sukumar <s-ghorai at ti.com>:
> > Hi,
> > I was using the following ecc layout which is not working to mount the
> > jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is
> > not working with latest 2.6 kernel.
> >
> > Observation is that - no read request issued to the driver (say omap2.c).
> >
> > # mount -t jffs2 /dev/mtdblock4 /mnt/nand
> > [?? 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
> > read 0 bytes, error -22 mount: Mounting /dev/mtdblock4 on /mnt/nand
> > failed: Input/output error
>
> I meet the issue too, kernel is  2.6.37-rc6-next-20101217+, and board is
> beagle B5.
>
> Is there any way to fix or workaround the issue?
>
>
> thanks,

THis might be due to the way the omap2.c driver is now screwed up so that it 
does not read when not u32 aligned.

Try this:
http://www.spinics.net/linux/lists/linux-omap/msg42422.html

Please report back if that fixes the problem for you.

-- Charles





From Zhongjun.Zhou at alcatel-sbell.com.cn  Thu Dec 23 22:23:20 2010
From: Zhongjun.Zhou at alcatel-sbell.com.cn (ZHOU Zhongjun)
Date: Fri, 24 Dec 2010 11:23:20 +0800
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF77674A@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local><1293049245.2051.4.camel@koala>
	<39A4B204C321D34DA3490E3B119D5A6C68BF77674A@SBS2008.wellsense.local>
Message-ID: <EF949E0CEB6551499A3643069FE41ACB034B6DFC@CNSHGSMBS01.ad4.ad.alcatel.com>

Why do you not to use YAFFS2 for NAND flash?  It seems that Yaffs2 is more popularity.


-----Original Message-----
From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Boaz Ben-David
Sent: Thursday, December 23, 2010 8:52 PM
To: linux-mtd at lists.infradead.org
Subject: Re: UBIFS reboots issue

I am using kernel 2.6.31 for iMX35 and I'm not sure what version of UBIFS is patched in there.
What do I need to do in order to patch to the latest version? 
Is is enough to clone UBIFS 2.6.31 and copy over the fs/ubifs and mtd/ubi directories or are there any other directories I need to take into account?

Thanks,

Boaz.

On Wed, 2010-12-22 at 22:20 +0200, Artem Bityutskiy wrote:
> On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> > Hi all,
> > 
> > We have an embedded system using a Samsung 2GB MLC NAND and are 
> > using UBIFS as the file system on it.
> > I have a question regarding UBIFS and hard reboots.
> > After some work with the flash (doing reads and writes to it), some 
> > times one of our partitions would fail to mount.
> > I suspected this has something to do with a reboot which happens 
> > during a write to the flash.
> > In order to test this I created a simple script which copies a file 
> > from to the partition, syncs, then deletes it and does this 
> > repeatedly until a hard reboot occurs (using the watch dog to cause the boot).
> > This process repeats itself until the partition fails to mount.
> > When I performed the test mentioned above, after about 3-4 times the 
> > partition would fail.
> > I am not sure if this behaviour is normal or not.
> > Did someone encounter similiar behaviour?
> 
> Just curious, did you see this:
> 
> http://linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc
> 
> I do not think you can just use UBI/UBIFS on MLC as is, you'd need to 
> make sure MLC-specific behavior is handled properly.
> 
> --
> Best Regards,
> Artem Bityutskiy (???????? ?????)
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


From boaz.bd at wellsense-tech.com  Fri Dec 24 05:40:35 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Fri, 24 Dec 2010 12:40:35 +0200
Subject: UBIFS reboots issue
In-Reply-To: <EF949E0CEB6551499A3643069FE41ACB034B6DFC@CNSHGSMBS01.ad4.ad.alcatel.com>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local><1293049245.2051.4.camel@koala>
	<39A4B204C321D34DA3490E3B119D5A6C68BF77674A@SBS2008.wellsense.local>,
	<EF949E0CEB6551499A3643069FE41ACB034B6DFC@CNSHGSMBS01.ad4.ad.alcatel.com>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF77573E@SBS2008.wellsense.local>

I would very much want to try yaffs2. I cloned the git repo and patched my kernel using the script provided
with the yaffs code. The kernel compiled with no errors but after I mounted a yaffs partition I could not create any new files on it.
Each time I try to create a file on the partition I get "cannot allocate memory",,,
I haven't had much time to investigate this so if anyone has any idea why this is happening, this is also a very good direction for me to go with (using yaffs).
________________________________________
From: ZHOU Zhongjun [Zhongjun.Zhou at alcatel-sbell.com.cn]
Sent: Friday, December 24, 2010 5:23 AM
To: Boaz Ben-David; linux-mtd at lists.infradead.org
Subject: RE: UBIFS reboots issue

Why do you not to use YAFFS2 for NAND flash?  It seems that Yaffs2 is more popularity.


-----Original Message-----
From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Boaz Ben-David
Sent: Thursday, December 23, 2010 8:52 PM
To: linux-mtd at lists.infradead.org
Subject: Re: UBIFS reboots issue

I am using kernel 2.6.31 for iMX35 and I'm not sure what version of UBIFS is patched in there.
What do I need to do in order to patch to the latest version?
Is is enough to clone UBIFS 2.6.31 and copy over the fs/ubifs and mtd/ubi directories or are there any other directories I need to take into account?

Thanks,

Boaz.

On Wed, 2010-12-22 at 22:20 +0200, Artem Bityutskiy wrote:
> On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> > Hi all,
> >
> > We have an embedded system using a Samsung 2GB MLC NAND and are
> > using UBIFS as the file system on it.
> > I have a question regarding UBIFS and hard reboots.
> > After some work with the flash (doing reads and writes to it), some
> > times one of our partitions would fail to mount.
> > I suspected this has something to do with a reboot which happens
> > during a write to the flash.
> > In order to test this I created a simple script which copies a file
> > from to the partition, syncs, then deletes it and does this
> > repeatedly until a hard reboot occurs (using the watch dog to cause the boot).
> > This process repeats itself until the partition fails to mount.
> > When I performed the test mentioned above, after about 3-4 times the
> > partition would fail.
> > I am not sure if this behaviour is normal or not.
> > Did someone encounter similiar behaviour?
>
> Just curious, did you see this:
>
> http://linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc
>
> I do not think you can just use UBI/UBIFS on MLC as is, you'd need to
> make sure MLC-specific behavior is handled properly.
>
> --
> Best Regards,
> Artem Bityutskiy (???????? ?????)
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


From tom.leiming at gmail.com  Fri Dec 24 08:51:22 2010
From: tom.leiming at gmail.com (Ming Lei)
Date: Fri, 24 Dec 2010 21:51:22 +0800
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <201012241602.36582.manningc2@actrix.gen.nz>
References: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
	<201012241602.36582.manningc2@actrix.gen.nz>
Message-ID: <AANLkTi=DfzP5mkwJ3zWePSp+gthWV-OT1_kBVFtkpNWU@mail.gmail.com>

Hi,

2010/12/24 Charles Manning <manningc2 at actrix.gen.nz>:

> THis might be due to the way the omap2.c driver is now screwed up so that it
> does not read when not u32 aligned.
>
> Try this:
> http://www.spinics.net/linux/lists/linux-omap/msg42422.html
>
> Please report back if that fixes the problem for you.

No, the patch doesn't fix the issue.

thanks,
-- 
Lei Ming


From tom.leiming at gmail.com  Fri Dec 24 08:56:34 2010
From: tom.leiming at gmail.com (Ming Lei)
Date: Fri, 24 Dec 2010 21:56:34 +0800
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <AANLkTi=DfzP5mkwJ3zWePSp+gthWV-OT1_kBVFtkpNWU@mail.gmail.com>
References: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
	<201012241602.36582.manningc2@actrix.gen.nz>
	<AANLkTi=DfzP5mkwJ3zWePSp+gthWV-OT1_kBVFtkpNWU@mail.gmail.com>
Message-ID: <AANLkTi=YM2ONPfA9g4tFDQcJwfstGi_FLsrXTEcyby7b@mail.gmail.com>

2010/12/24 Ming Lei <tom.leiming at gmail.com>:
> Hi,
>
> 2010/12/24 Charles Manning <manningc2 at actrix.gen.nz>:
>
>> THis might be due to the way the omap2.c driver is now screwed up so that it
>> does not read when not u32 aligned.
>>
>> Try this:
>> http://www.spinics.net/linux/lists/linux-omap/msg42422.html
>>
>> Please report back if that fixes the problem for you.
>
> No, the patch doesn't fix the issue.

#mount -t jffs2 /dev/mtdblock4 /mnt/cf

mount: /dev/mtdblock4: can't read superblock

[   41.216796] nand_do_read_oob: Attempt to read past end of page
[   41.216827] cannot read OOB for EB at 00000000, requested 152
bytes, read 0 bytes, error -22


thanks,
-- 
Lei Ming


From tom.leiming at gmail.com  Fri Dec 24 09:10:33 2010
From: tom.leiming at gmail.com (Ming Lei)
Date: Fri, 24 Dec 2010 22:10:33 +0800
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <AANLkTi=YM2ONPfA9g4tFDQcJwfstGi_FLsrXTEcyby7b@mail.gmail.com>
References: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
	<201012241602.36582.manningc2@actrix.gen.nz>
	<AANLkTi=DfzP5mkwJ3zWePSp+gthWV-OT1_kBVFtkpNWU@mail.gmail.com>
	<AANLkTi=YM2ONPfA9g4tFDQcJwfstGi_FLsrXTEcyby7b@mail.gmail.com>
Message-ID: <AANLkTikNP4HU3cHHQXjSBCXqxz0ES1AhCZpt3ZqKu9KT@mail.gmail.com>

Hi Jason,

2010/12/24 Ming Lei <tom.leiming at gmail.com>:
> 2010/12/24 Ming Lei <tom.leiming at gmail.com>:
>> Hi,
>>
>> 2010/12/24 Charles Manning <manningc2 at actrix.gen.nz>:
>>
>>> THis might be due to the way the omap2.c driver is now screwed up so that it
>>> does not read when not u32 aligned.
>>>
>>> Try this:
>>> http://www.spinics.net/linux/lists/linux-omap/msg42422.html
>>>
>>> Please report back if that fixes the problem for you.
>>
>> No, the patch doesn't fix the issue.
>
> #mount -t jffs2 /dev/mtdblock4 /mnt/cf
>
> mount: /dev/mtdblock4: can't read superblock
>
> [ ? 41.216796] nand_do_read_oob: Attempt to read past end of page
> [ ? 41.216827] cannot read OOB for EB at 00000000, requested 152
> bytes, read 0 bytes, error -22

When I revert the patch below from Jason,

       http://marc.info/?l=linux-kernel&m=129015697513966&w=2

mount will be OK but with some info printed, see below:

root at beagleboard:~# mount -t jffs2 /dev/mtdblock4 /mnt/cf
[   39.662963] JFFS2 notice: (1324) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 0
of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.

#mount
......
/dev/mtdblock4 on /media/cf type jffs2 (rw,relatime)

So seems the patch from Jason does cause the issue, maybe should be
dropped or fixed further.

thanks,
-- 
Lei Ming


From tom.leiming at gmail.com  Fri Dec 24 09:40:40 2010
From: tom.leiming at gmail.com (Ming Lei)
Date: Fri, 24 Dec 2010 22:40:40 +0800
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <201012241602.36582.manningc2@actrix.gen.nz>
References: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
	<201012241602.36582.manningc2@actrix.gen.nz>
Message-ID: <AANLkTiky0G_H9vGDRNj-y=JTcfCcvRgfXraa0SbAZM4t@mail.gmail.com>

Hi,

2010/12/24 Charles Manning <manningc2 at actrix.gen.nz>:

> THis might be due to the way the omap2.c driver is now screwed up so that it
> does not read when not u32 aligned.
>
> Try this:
> http://www.spinics.net/linux/lists/linux-omap/msg42422.html
>
> Please report back if that fixes the problem for you.

The patch is still a good catch, with it, the following error
message does disappear:

[  299.433197] uncorrectable error :
[  299.436737] uncorrectable error :
[  299.440338] mtd->read(0x530 bytes from 0xf9202d0) returned ECC error
[  299.447875] uncorrectable error :
[  299.451263] uncorrectable error :
[  299.454833] mtd->read(0x44 bytes from 0xf927efc) returned ECC error
[  299.461822] uncorrectable error :
[  299.465240] uncorrectable error :
[  299.468780] uncorrectable error :
[  299.472534] mtd->read(0x5a4 bytes from 0xf940d84) returned ECC error

If not applying this patch, even Jason's patch is reverted, the error message
above will be printed out very frequently during 'mount'.

thanks,
-- 
Lei Ming


From david-b at pacbell.net  Fri Dec 24 13:37:57 2010
From: david-b at pacbell.net (David Brownell)
Date: Fri, 24 Dec 2010 10:37:57 -0800 (PST)
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <AANLkTiky0G_H9vGDRNj-y=JTcfCcvRgfXraa0SbAZM4t@mail.gmail.com>
Message-ID: <89885.88076.qm@web180308.mail.gq1.yahoo.com>

ISTR that while JFFS2 worked with NAND, it had
to reserve a few bytes of OOB data that might more
naturally be used for ECC data.  I've not looked
at your layout ... does it reserve those bytes
for use by JFFS, or is it using them for ECC?

Also, ISTR that Some People felt that using JFFS2
with NAND was sub-optimal.  Which is why we have other NAND filesystem choices, like UBI/UBIFS,
and  (currently out-of-tree) YAFFS2.

- Dave



From adrian.wenl at gmail.com  Fri Dec 24 23:31:07 2010
From: adrian.wenl at gmail.com (Lei Wen)
Date: Sat, 25 Dec 2010 12:31:07 +0800
Subject: [PATCH V3 0/6] pxa3xx_nand update series set
In-Reply-To: <AANLkTin2O-mQi9jxnJsgBr82T1FRrRavMA5MMnvzueJ7@mail.gmail.com>
References: <1287742484-4276-1-git-send-email-leiwen@marvell.com>
	<AANLkTikVAU5KAN072O7xp=A3meFTw5AadUSoqbzEGofO@mail.gmail.com>
	<AANLkTin2O-mQi9jxnJsgBr82T1FRrRavMA5MMnvzueJ7@mail.gmail.com>
Message-ID: <AANLkTinj0_+iHQCLiSt4aRZKeoK-VODnW+rcO3VOESv8@mail.gmail.com>

Ping...

Should we restart this review?...

Best regards,
Lei

On Fri, Nov 19, 2010 at 12:42 PM, Lei Wen <adrian.wenl at gmail.com> wrote:
> Hi David,
>
> Would you mind check whether those patches need any fix, or could be merged now?
>
> Thanks,
> Lei
>
> On Fri, Oct 22, 2010 at 6:15 PM, Haojian Zhuang
> <haojian.zhuang at gmail.com> wrote:
>> On Fri, Oct 22, 2010 at 6:14 PM, Lei Wen <leiwen at marvell.com> wrote:
>>> [PATCH V3 1/6] pxa3xx_nand: make scan procedure more clear
>>> [PATCH V3 2/6] pxa3xx_nand: rework irq logic
>>> [PATCH V3 3/6] pxa3xx_nand: discard wait_for_event,write_cmd,__readid function
>>> [PATCH V3 4/6] pxa3xx_nand: unify prepare command
>>> [PATCH V3 5/6] pxa3xx_nand: mtd scan id process could be defined by driver itself
>>> [PATCH V3 6/6] pxa3xx_nand: clean the keep configure code
>>>
>>
>> Hi Eric and all,
>>
>> Patches are refreshed. Please help to review.
>>
>> Best Regards
>> Haojian
>>
>


From linus.ml.walleij at gmail.com  Sun Dec 26 10:38:31 2010
From: linus.ml.walleij at gmail.com (Linus Walleij)
Date: Sun, 26 Dec 2010 16:38:31 +0100
Subject: [PATCH V3 36/63] ST SPEAr : FSMC (Flexible Static Memory
	Controller) NOR interface driver
In-Reply-To: <187ed7b3996c7f37ce782d847d3ecc761c3e52b8.1292833228.git.viresh.kumar@st.com>
References: <cover.1292833228.git.viresh.kumar@st.com>
	<187ed7b3996c7f37ce782d847d3ecc761c3e52b8.1292833228.git.viresh.kumar@st.com>
Message-ID: <AANLkTik_NXigwhRH3KMjV3qmu-GB7m+6hzzdGY8RjBof@mail.gmail.com>

2010/12/20 Viresh Kumar <viresh.kumar at st.com>:

> SPEAr1300 SoC supports FSMC to interface with various memories
> (NOR/NAND/SRAM). This patch adds the support for FSMC over NOR interface.
>
> The driver being used is driver/mtd/maps/physmap.c

OK..

(...)
> diff --git a/arch/arm/mach-spear13xx/fsmc-nor.c b/arch/arm/mach-spear13xx/fsmc-nor.c
> new file mode 100644
> index 0000000..03234b6
> --- /dev/null
> +++ b/arch/arm/mach-spear13xx/fsmc-nor.c

What is this file doing in mach-spear13xx? Several other platforms
like U300 and Nomadik use the same NOR controller.

This should be in drivers/mtd/* somewhere I believe?

> @@ -0,0 +1,85 @@
> +/*
> + * arch/arm/mach-spear13xx/fsmc-nor.c
> + *
> + * FSMC (Flexible Static Memory Controller) interface for NOR
> + *
> + * Copyright (C) 2010 ST Microelectronics
> + * Vipin Kumar<vipin.kumar at st.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <plat/fsmc.h>

Use <linux/mtd/fsmc.h> as include file, get rid of plat/fsmc.h.
Extend that .h file with the stuff you need.

We need to keep definitions for MTD NOR, NAND and OneNAND using FSMC
in this file so as to keep things simple. One header file is enough, and it's
very generic too, FSMC is not for plat-spear/* but also U300, Nomadik and
Ux500.

Yours,
Linus Walleij


From r64343 at freescale.com  Sun Dec 26 21:12:10 2010
From: r64343 at freescale.com (Liu Hui-R64343)
Date: Mon, 27 Dec 2010 02:12:10 +0000
Subject: Issue : jffs2 and ecc layout
In-Reply-To: <AANLkTikNP4HU3cHHQXjSBCXqxz0ES1AhCZpt3ZqKu9KT@mail.gmail.com>
References: <2A3DCF3DA181AD40BDE86A3150B27B6B03560990E3@dbde02.ent.ti.com>
	<AANLkTimJFsjLT15FA+TqDKzjvPXgxUAvovWpWKP3NCK4@mail.gmail.com>
	<201012241602.36582.manningc2@actrix.gen.nz>
	<AANLkTi=DfzP5mkwJ3zWePSp+gthWV-OT1_kBVFtkpNWU@mail.gmail.com>
	<AANLkTi=YM2ONPfA9g4tFDQcJwfstGi_FLsrXTEcyby7b@mail.gmail.com>
	<AANLkTikNP4HU3cHHQXjSBCXqxz0ES1AhCZpt3ZqKu9KT@mail.gmail.com>
Message-ID: <2CF7613B9822A943BEF13EF7ACEC5BD106D221@039-SN1MPN1-001.039d.mgd.msft.net>

Hi, Ming, 
Yes, this patch has some issues and Artem has reverted it.
This patch is intent to fix the mtd_oobtest, step 4 issue, but it's wrong.
Please revert it. Sorry for that.


Best Regards,
Jason Liu


>-----Original Message-----
>From: Ming Lei [mailto:tom.leiming at gmail.com]
>Sent: Friday, December 24, 2010 10:11 PM
>To: Liu Hui-R64343; David.Woodhouse at intel.com
>Cc: Ghorai, Sukumar; linux-mtd at lists.infradead.org; linux-
>omap at vger.kernel.org; Charles Manning
>Subject: Re: Issue : jffs2 and ecc layout
>
>Hi Jason,
>
>2010/12/24 Ming Lei <tom.leiming at gmail.com>:
>> 2010/12/24 Ming Lei <tom.leiming at gmail.com>:
>>> Hi,
>>>
>>> 2010/12/24 Charles Manning <manningc2 at actrix.gen.nz>:
>>>
>>>> THis might be due to the way the omap2.c driver is now screwed up so
>>>> that it does not read when not u32 aligned.
>>>>
>>>> Try this:
>>>> http://www.spinics.net/linux/lists/linux-omap/msg42422.html
>>>>
>>>> Please report back if that fixes the problem for you.
>>>
>>> No, the patch doesn't fix the issue.
>>
>> #mount -t jffs2 /dev/mtdblock4 /mnt/cf
>>
>> mount: /dev/mtdblock4: can't read superblock
>>
>> [ ? 41.216796] nand_do_read_oob: Attempt to read past end of page [
>> 41.216827] cannot read OOB for EB at 00000000, requested 152 bytes,
>> read 0 bytes, error -22
>
>When I revert the patch below from Jason,
>
>       http://marc.info/?l=linux-kernel&m=129015697513966&w=2
>
>mount will be OK but with some info printed, see below:
>
>root at beagleboard:~# mount -t jffs2 /dev/mtdblock4 /mnt/cf
>[   39.662963] JFFS2 notice: (1324) jffs2_build_xattr_subsystem:
>complete building xattr subsystem, 0
>of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
>
>#mount
>......
>/dev/mtdblock4 on /media/cf type jffs2 (rw,relatime)
>
>So seems the patch from Jason does cause the issue, maybe should be
>dropped or fixed further.
>
>thanks,
>--
>Lei Ming




From boaz.bd at wellsense-tech.com  Tue Dec 28 10:47:49 2010
From: boaz.bd at wellsense-tech.com (Boaz Ben-David)
Date: Tue, 28 Dec 2010 17:47:49 +0200
Subject: UBIFS reboots issue
In-Reply-To: <39A4B204C321D34DA3490E3B119D5A6C68BF77573E@SBS2008.wellsense.local>
References: <39A4B204C321D34DA3490E3B119D5A6C68BF77673F@SBS2008.wellsense.local>
	<1293049245.2051.4.camel@koala>
	<39A4B204C321D34DA3490E3B119D5A6C68BF77674A@SBS2008.wellsense.local> , 
	<EF949E0CEB6551499A3643069FE41ACB034B6DFC@CNSHGSMBS01.ad4.ad.alcatel.com>
	<39A4B204C321D34DA3490E3B119D5A6C68BF77573E@SBS2008.wellsense.local>
Message-ID: <39A4B204C321D34DA3490E3B119D5A6C68BF776758@SBS2008.wellsense.local>

I'm sorry for changing the thread subject in the previous mail..

I guess it sums up to one main question (and I would be very greatful if
someone could answer):

	Overall, for use on MLC NAND, is UBIFS or JFFS2 more suitable?
	From what I understand, JFFS2 doesn't do wear-leveling very
	good which will shorten the flash lifetime, but on the other
	hand, as Artem said and is written in the UBIFS web-site, UBIFS
	needs some work to be used on MLC. 

On another note, I would like to also try yaffs2 but I can't get it to
work (can't seem to create any files). Does anyone has any experience
using it on the Freescale iMX35 PDK?

Thanks.



On Fri, 2010-12-24 at 12:40 +0200, Boaz Ben-David wrote:
> I would very much want to try yaffs2. I cloned the git repo and patched my kernel using the script provided
> with the yaffs code. The kernel compiled with no errors but after I mounted a yaffs partition I could not create any new files on it.
> Each time I try to create a file on the partition I get "cannot allocate memory",,,
> I haven't had much time to investigate this so if anyone has any idea why this is happening, this is also a very good direction for me to go with (using yaffs).
> ________________________________________
> From: ZHOU Zhongjun [Zhongjun.Zhou at alcatel-sbell.com.cn]
> Sent: Friday, December 24, 2010 5:23 AM
> To: Boaz Ben-David; linux-mtd at lists.infradead.org
> Subject: RE: UBIFS reboots issue
> 
> Why do you not to use YAFFS2 for NAND flash?  It seems that Yaffs2 is more popularity.
> 
> 
> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Boaz Ben-David
> Sent: Thursday, December 23, 2010 8:52 PM
> To: linux-mtd at lists.infradead.org
> Subject: Re: UBIFS reboots issue
> 
> I am using kernel 2.6.31 for iMX35 and I'm not sure what version of UBIFS is patched in there.
> What do I need to do in order to patch to the latest version?
> Is is enough to clone UBIFS 2.6.31 and copy over the fs/ubifs and mtd/ubi directories or are there any other directories I need to take into account?
> 
> Thanks,
> 
> Boaz.
> 
> On Wed, 2010-12-22 at 22:20 +0200, Artem Bityutskiy wrote:
> > On Wed, 2010-12-22 at 16:36 +0200, Boaz Ben-David wrote:
> > > Hi all,
> > >
> > > We have an embedded system using a Samsung 2GB MLC NAND and are
> > > using UBIFS as the file system on it.
> > > I have a question regarding UBIFS and hard reboots.
> > > After some work with the flash (doing reads and writes to it), some
> > > times one of our partitions would fail to mount.
> > > I suspected this has something to do with a reboot which happens
> > > during a write to the flash.
> > > In order to test this I created a simple script which copies a file
> > > from to the partition, syncs, then deletes it and does this
> > > repeatedly until a hard reboot occurs (using the watch dog to cause the boot).
> > > This process repeats itself until the partition fails to mount.
> > > When I performed the test mentioned above, after about 3-4 times the
> > > partition would fail.
> > > I am not sure if this behaviour is normal or not.
> > > Did someone encounter similiar behaviour?
> >
> > Just curious, did you see this:
> >
> > http://linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc
> >
> > I do not think you can just use UBI/UBIFS on MLC as is, you'd need to
> > make sure MLC-specific behavior is handled properly.
> >
> > --
> > Best Regards,
> > Artem Bityutskiy (???????? ?????)
> >
> 
> ______________________________________________________
> 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 oyvind.harboe at zylin.com  Wed Dec 29 03:25:19 2010
From: oyvind.harboe at zylin.com (=?UTF-8?Q?=C3=98yvind_Harboe?=)
Date: Wed, 29 Dec 2010 09:25:19 +0100
Subject: Faster flash_eraseall for NOR flash
In-Reply-To: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
References: <AANLkTi=DmECiCVyZ61Cc0=66VANyrQV9xwzYjDceA8=M@mail.gmail.com>
Message-ID: <AANLkTimivRigmfgNK8mm+WTXeYALnp+1vwWDc4LuJM6n@mail.gmail.com>

I don't think this feature is going to work very well as-is.

To make this effective in real life, I think I'll have to add in an
option to read in a binary file, which is written to flash after
erase.

Only those erase blocks which changed should be
erased + written.

The cleanmarkers would be written for erase blocks after
the end of the binary file.

This fixes two things: even faster for blocks that don't change,
if the cleanmarker is not supposed to be there for certain
blocks, then it will currently fail.

-- 
?yvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer


From s-ghorai at ti.com  Wed Dec 29 08:32:19 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:19 +0530
Subject: [PATCH v7 0/7] nand prefetch-irq support and ecc layout chanage
Message-ID: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>

The following set of patches applies on linux-2.6.

The main motivations behind this patch series are -
        1. support NAND I/O in irq mode.
        2. support of different ECC schema.
        3. also add support ecc layout as like in romcode ecc layout, but not enabled

v7: NAND type (x16 or x8) is board specific and not omap specific; this passed form board file.
    
v6: configurable transfer type from board file; 
    #define irq number used for nand-irq
    http://www.mail-archive.com/linux-omap at vger.kernel.org/msg39397.html
    
v5: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg35860.html
This address the input as to support the irq_chained in GPMC.
And resend of
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg35848.html

v4: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg34882.html
and resend of
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg32689.html

v3: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg32071.html
Rebase on latest codebase and previous patch(posted).
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg31963.html

v2: Rebase on latest codebase and previous patch(posted).
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg31471.html

v1: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg26666.html

Sukumar Ghorai (7):
  omap3630: nand: fix device size to work in polled mode
  omap3: nand: configurable transfer type per board
  omap: gpmc: enable irq mode in gpmc
  omap3: nand: prefetch in irq mode support
  omap3: nand: configurable fifo threshold to gain the throughput
  omap3: nand: ecc layout select from board file
  omap3: nand: making ecc layout as compatible with romcode ecc

 arch/arm/mach-omap2/board-2430sdp.c        |    1 +
 arch/arm/mach-omap2/board-3430sdp.c        |    3 +-
 arch/arm/mach-omap2/board-3630sdp.c        |    4 +-
 arch/arm/mach-omap2/board-4430sdp.c        |    2 +
 arch/arm/mach-omap2/board-am3517evm.c      |    2 +
 arch/arm/mach-omap2/board-apollon.c        |    1 +
 arch/arm/mach-omap2/board-cm-t35.c         |    1 +
 arch/arm/mach-omap2/board-devkit8000.c     |    1 +
 arch/arm/mach-omap2/board-flash.c          |   13 +-
 arch/arm/mach-omap2/board-flash.h          |    4 +-
 arch/arm/mach-omap2/board-generic.c        |    2 +
 arch/arm/mach-omap2/board-h4.c             |    1 +
 arch/arm/mach-omap2/board-igep0020.c       |    1 +
 arch/arm/mach-omap2/board-ldp.c            |    3 +-
 arch/arm/mach-omap2/board-n8x0.c           |    2 +
 arch/arm/mach-omap2/board-omap3beagle.c    |    1 +
 arch/arm/mach-omap2/board-omap3evm.c       |    2 +
 arch/arm/mach-omap2/board-omap3pandora.c   |    2 +
 arch/arm/mach-omap2/board-omap3stalker.c   |    1 +
 arch/arm/mach-omap2/board-omap3touchbook.c |    1 +
 arch/arm/mach-omap2/board-omap4panda.c     |    2 +
 arch/arm/mach-omap2/board-overo.c          |    1 +
 arch/arm/mach-omap2/board-rx51.c           |    1 +
 arch/arm/mach-omap2/board-zoom2.c          |    7 +-
 arch/arm/mach-omap2/board-zoom3.c          |    7 +-
 arch/arm/mach-omap2/gpmc-nand.c            |    7 +-
 arch/arm/mach-omap2/gpmc.c                 |   50 ++++-
 arch/arm/mach-omap2/io.c                   |    2 -
 arch/arm/plat-omap/include/plat/gpmc.h     |   17 ++-
 arch/arm/plat-omap/include/plat/irqs.h     |    9 +-
 arch/arm/plat-omap/include/plat/nand.h     |   11 +
 drivers/mtd/nand/Kconfig                   |   17 --
 drivers/mtd/nand/omap2.c                   |  336 +++++++++++++++++++++-------
 33 files changed, 396 insertions(+), 119 deletions(-)



From s-ghorai at ti.com  Wed Dec 29 08:32:20 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:20 +0530
Subject: [PATCH v7 1/7] omap3630: nand: fix device size to work in polled mode
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-2-git-send-email-s-ghorai@ti.com>

zoom3 and 3630-sdp having the x16 nand device.
This patch configure gpmc as x16 and select the currect function in driver
for polled mode (without prefetch enable) transfer.

Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/mach-omap2/board-3430sdp.c |    2 +-
 arch/arm/mach-omap2/board-3630sdp.c |    3 ++-
 arch/arm/mach-omap2/board-flash.c   |   10 ++++++----
 arch/arm/mach-omap2/board-flash.h   |    4 ++--
 arch/arm/mach-omap2/board-ldp.c     |    2 +-
 arch/arm/mach-omap2/board-zoom2.c   |    5 +++--
 arch/arm/mach-omap2/board-zoom3.c   |    5 +++--
 arch/arm/mach-omap2/gpmc-nand.c     |    7 +++++--
 drivers/mtd/nand/omap2.c            |    2 +-
 9 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..470872e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -809,7 +809,7 @@ static void __init omap_3430sdp_init(void)
 	omap_serial_init();
 	usb_musb_init(&musb_board_data);
 	board_smc91x_init();
-	board_flash_init(sdp_flash_partitions, chip_sel_3430);
+	board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
 	sdp3430_display_init();
 	enable_board_wakeup_source();
 	usb_ehci_init(&ehci_pdata);
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..0a74141 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -11,6 +11,7 @@
 #include <linux/platform_device.h>
 #include <linux/input.h>
 #include <linux/gpio.h>
+#include <linux/mtd/nand.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -210,7 +211,7 @@ static void __init omap_sdp_init(void)
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 	zoom_peripherals_init();
 	board_smc91x_init();
-	board_flash_init(sdp_flash_partitions, chip_sel_sdp);
+	board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
 	enable_board_wakeup_source();
 	usb_ehci_init(&ehci_pdata);
 }
diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c
index fd38c05..f6b7253 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -139,11 +139,13 @@ static struct omap_nand_platform_data board_nand_data = {
 };
 
 void
-__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs)
+__init board_nand_init(struct mtd_partition *nand_parts,
+			u8 nr_parts, u8 cs, int nand_type)
 {
 	board_nand_data.cs		= cs;
 	board_nand_data.parts		= nand_parts;
-	board_nand_data.nr_parts		= nr_parts;
+	board_nand_data.nr_parts	= nr_parts;
+	board_nand_data.devsize		= nand_type;
 
 	gpmc_nand_init(&board_nand_data);
 }
@@ -194,7 +196,7 @@ unmap:
  * @return - void.
  */
 void board_flash_init(struct flash_partitions partition_info[],
-					char chip_sel_board[][GPMC_CS_NUM])
+			char chip_sel_board[][GPMC_CS_NUM], int nand_type)
 {
 	u8		cs = 0;
 	u8		norcs = GPMC_CS_NUM + 1;
@@ -250,5 +252,5 @@ void board_flash_init(struct flash_partitions partition_info[],
 				"in GPMC\n");
 	else
 		board_nand_init(partition_info[2].parts,
-				partition_info[2].nr_parts, nandcs);
+			partition_info[2].nr_parts, nandcs, nand_type);
 }
diff --git a/arch/arm/mach-omap2/board-flash.h b/arch/arm/mach-omap2/board-flash.h
index 69befe0..c240a3f 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -25,6 +25,6 @@ struct flash_partitions {
 };
 
 extern void board_flash_init(struct flash_partitions [],
-				char chip_sel[][GPMC_CS_NUM]);
+				char chip_sel[][GPMC_CS_NUM], int nand_type);
 extern void board_nand_init(struct mtd_partition *nand_parts,
-					u8 nr_parts, u8 cs);
+					u8 nr_parts, u8 cs, int nand_type);
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 001fd97..b088b1d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -436,7 +436,7 @@ static void __init omap_ldp_init(void)
 	omap_serial_init();
 	usb_musb_init(&musb_board_data);
 	board_nand_init(ldp_nand_partitions,
-		ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS);
+		ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS, 0);
 
 	omap2_hsmmc_init(mmc);
 	/* link regulators to MMC adapters */
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c
index 2992a9f..994d286 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -15,6 +15,7 @@
 #include <linux/input.h>
 #include <linux/gpio.h>
 #include <linux/i2c/twl.h>
+#include <linux/mtd/nand.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -102,8 +103,8 @@ static void __init omap_zoom2_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	zoom_peripherals_init();
-	board_nand_init(zoom_nand_partitions,
-			ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
+	board_nand_init(zoom_nand_partitions, ARRAY_SIZE(zoom_nand_partitions),
+						ZOOM_NAND_CS, NAND_BUSWIDTH_16);
 	zoom_debugboard_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-zoom3.c b/arch/arm/mach-omap2/board-zoom3.c
index 5adde12..0c9c15e 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -12,6 +12,7 @@
 #include <linux/platform_device.h>
 #include <linux/input.h>
 #include <linux/gpio.h>
+#include <linux/mtd/nand.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -115,8 +116,8 @@ static void __init omap_zoom_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 	zoom_peripherals_init();
-	board_nand_init(zoom_nand_partitions,
-			 ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
+	board_nand_init(zoom_nand_partitions, ARRAY_SIZE(zoom_nand_partitions),
+						ZOOM_NAND_CS, NAND_BUSWIDTH_16);
 	zoom_debugboard_init();
 
 	omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 7222096..5d58f57 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -12,6 +12,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
+#include <linux/mtd/nand.h>
 
 #include <asm/mach/flash.h>
 
@@ -69,8 +70,10 @@ static int omap2_nand_gpmc_retime(void)
 	t.wr_cycle  = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->wr_cycle);
 
 	/* Configure GPMC */
-	gpmc_cs_configure(gpmc_nand_data->cs,
-				GPMC_CONFIG_DEV_SIZE, gpmc_nand_data->devsize);
+	if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
+		gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 1);
+	else
+		gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 0);
 	gpmc_cs_configure(gpmc_nand_data->cs,
 			GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
 	err = gpmc_cs_set_timings(gpmc_nand_data->cs, &t);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 15682ec..7c04cd6 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -804,7 +804,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 	info->mtd.name		= dev_name(&pdev->dev);
 	info->mtd.owner		= THIS_MODULE;
 
-	info->nand.options	|= pdata->devsize ? NAND_BUSWIDTH_16 : 0;
+	info->nand.options	= pdata->devsize;
 	info->nand.options	|= NAND_SKIP_BBTSCAN;
 
 	/* NAND write protect off */
-- 
1.7.0.4



From s-ghorai at ti.com  Wed Dec 29 08:32:24 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:24 +0530
Subject: [PATCH v7 5/7] omap3: nand: configurable fifo threshold to gain the
	throughput
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-6-git-send-email-s-ghorai@ti.com>

Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.

Signed-off-by: Vimal Singh <vimalsingh at ti.com>
Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/mach-omap2/gpmc.c             |   11 +++++++----
 arch/arm/plat-omap/include/plat/gpmc.h |    5 ++++-
 drivers/mtd/nand/omap2.c               |   22 ++++++++++++++--------
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index cfaf357..b26b1a5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
 #define GPMC_CHUNK_SHIFT	24		/* 16 MB */
 #define GPMC_SECTION_SHIFT	28		/* 128 MB */
 
-#define PREFETCH_FIFOTHRESHOLD	(0x40 << 8)
 #define CS_NUM_SHIFT		24
 #define ENABLE_PREFETCH		(0x1 << 7)
 #define DMA_MPU_MODE		2
@@ -595,15 +594,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
 /**
  * gpmc_prefetch_enable - configures and starts prefetch transfer
  * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
  * @dma_mode: dma mode enable (1) or disable (0)
  * @u32_count: number of bytes to be transferred
  * @is_write: prefetch read(0) or write post(1) mode
  */
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
 				unsigned int u32_count, int is_write)
 {
 
-	if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+	if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX) {
+		printk(KERN_ERR "PREFETCH Fifo Threshold is not supported\n");
+		return -1;
+	} else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
 		/* Set the amount of bytes to be prefetched */
 		gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
 
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
 		 * enable the engine. Set which cs is has requested for.
 		 */
 		gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs << CS_NUM_SHIFT) |
-					PREFETCH_FIFOTHRESHOLD |
+					PREFETCH_FIFOTHRESHOLD(fifo_th) |
 					ENABLE_PREFETCH |
 					(dma_mode << DMA_MPU_MODE) |
 					(0x1 & is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
 #define GPMC_IRQ_FIFOEVENTENABLE	0x01
 #define GPMC_IRQ_COUNT_EVENT		0x02
 
+#define PREFETCH_FIFOTHRESHOLD_MAX	0x40
+#define PREFETCH_FIFOTHRESHOLD(val)	(val << 8)
+
 /*
  * Note that all values in this struct are in nanoseconds, while
  * the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
 extern void gpmc_cs_free(int cs);
 extern int gpmc_cs_set_reserved(int cs, int reserved);
 extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
 					unsigned int u32_count, int is_write);
 extern int gpmc_prefetch_reset(int cs);
 extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 007862e..384d89b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -243,7 +243,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char *buf, int len)
 	}
 
 	/* configure and start prefetch transfer */
-	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
+	ret = gpmc_prefetch_enable(info->gpmc_cs,
+			PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
 	if (ret) {
 		/* PFPW engine is busy, use cpu copy method */
 		if (info->nand.options & NAND_BUSWIDTH_16)
@@ -287,7 +288,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
 	}
 
 	/*  configure and start prefetch transfer */
-	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x1);
+	ret = gpmc_prefetch_enable(info->gpmc_cs,
+			PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
 	if (ret) {
 		/* PFPW engine is busy, use cpu copy method */
 		if (info->nand.options & NAND_BUSWIDTH_16)
@@ -340,8 +342,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
 	dma_addr_t dma_addr;
 	int ret;
 
-	/* The fifo depth is 64 bytes. We have a sync at each frame and frame
-	 * length is 64 bytes.
+	/* The fifo depth is 64 bytes max.
+	 * But configure the FIFO-threahold to 32 to get a sync at each frame
+	 * and frame length is 32 bytes.
 	 */
 	int buf_len = len >> 6;
 
@@ -382,7 +385,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
 					OMAP24XX_DMA_GPMC, OMAP_DMA_SRC_SYNC);
 	}
 	/*  configure and start prefetch transfer */
-	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x1, len, is_write);
+	ret = gpmc_prefetch_enable(info->gpmc_cs,
+			PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write);
 	if (ret)
 		/* PFPW engine is busy, use cpu copy methode */
 		goto out_copy;
@@ -518,7 +522,8 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd, u_char *buf, int len)
 	init_completion(&info->comp);
 
 	/*  configure and start prefetch transfer */
-	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
+	ret = gpmc_prefetch_enable(info->gpmc_cs,
+			PREFETCH_FIFOTHRESHOLD_MAX/2, 0x0, len, 0x0);
 	if (ret)
 		/* PFPW engine is busy, use cpu copy methode */
 		goto out_copy;
@@ -563,8 +568,9 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
 	info->buf = (u_char *) buf;
 	init_completion(&info->comp);
 
-	/*  configure and start prefetch transfer */
-	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x1);
+	/* configure and start prefetch transfer : size=24 */
+	ret = gpmc_prefetch_enable(info->gpmc_cs,
+			(PREFETCH_FIFOTHRESHOLD_MAX*3)/8, 0x0, len, 0x1);
 	if (ret)
 		/* PFPW engine is busy, use cpu copy methode */
 		goto out_copy;
-- 
1.7.0.4



From s-ghorai at ti.com  Wed Dec 29 08:32:26 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:26 +0530
Subject: [PATCH v7 7/7] omap3: nand: making ecc layout as compatible with
	romcode ecc
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-8-git-send-email-s-ghorai@ti.com>

This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.

This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.

This patch does not enables this feature by default and need to pass from
board file to enable for any board.

Signed-off-by: Vimal Singh <vimalsingh at ti.com>
Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/plat-omap/include/plat/gpmc.h |    2 +
 drivers/mtd/nand/omap2.c               |   37 +++++++++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 28a5607..fcc0530 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -90,6 +90,8 @@ enum omap_ecc {
 		/* 1-bit ecc: stored at end of spare area */
 	OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
 	OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+		/* 1-bit ecc: stored at begining of spare area as romcode */
+	OMAP_ECC_HAMMING_CODE_HW_ROMCODE, /* gpmc method & romcode layout */
 };
 
 /*
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c6f3ea9..72af2d9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -97,6 +97,20 @@
 static const char *part_probes[] = { "cmdlinepart", NULL };
 #endif
 
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+	.options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+	.offs = 0,
+	.len = 1,
+	.pattern = scan_ff_pattern,
+};
+
+
 struct omap_nand_info {
 	struct nand_hw_control		controller;
 	struct omap_nand_platform_data	*pdata;
@@ -906,6 +920,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 	struct omap_nand_info		*info;
 	struct omap_nand_platform_data	*pdata;
 	int				err;
+	int				i, offset;
 
 	pdata = pdev->dev.platform_data;
 	if (pdata == NULL) {
@@ -1029,7 +1044,8 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 	/* selsect the ecc type */
 	if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
 		info->nand.ecc.mode = NAND_ECC_SOFT;
-	else if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+	else if ((pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
+		(pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
 		info->nand.ecc.bytes            = 3;
 		info->nand.ecc.size             = 512;
 		info->nand.ecc.calculate        = omap_calculate_ecc;
@@ -1049,6 +1065,25 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 		}
 	}
 
+	/* rom code layout */
+	if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+
+		if (info->nand.options & NAND_BUSWIDTH_16)
+			offset = 2;
+		else {
+			offset = 1;
+			info->nand.badblock_pattern = &bb_descrip_flashbased;
+		}
+		omap_oobinfo.eccbytes = 3 * (info->mtd.oobsize/16);
+		for (i = 0; i < omap_oobinfo.eccbytes; i++)
+			omap_oobinfo.eccpos[i] = i+offset;
+
+		omap_oobinfo.oobfree->offset = offset + omap_oobinfo.eccbytes;
+		omap_oobinfo.oobfree->length = info->mtd.oobsize -
+					(offset + omap_oobinfo.eccbytes);
+
+		info->nand.ecc.layout = &omap_oobinfo;
+	}
 
 #ifdef CONFIG_MTD_PARTITIONS
 	err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);


From s-ghorai at ti.com  Wed Dec 29 08:32:23 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:23 +0530
Subject: [PATCH v7 4/7] omap3: nand: prefetch in irq mode support
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-5-git-send-email-s-ghorai@ti.com>

This patch enable prefetch-irq mode for nand transfer(read, write)

Signed-off-by: Vimal Singh <vimalsingh at ti.com>
Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/mach-omap2/board-flash.c      |    2 +
 arch/arm/plat-omap/include/plat/nand.h |    4 +-
 drivers/mtd/nand/omap2.c               |  169 ++++++++++++++++++++++++++++++++
 3 files changed, 174 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c
index f6b7253..1964509 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,6 +16,7 @@
 #include <linux/platform_device.h>
 #include <linux/mtd/physmap.h>
 #include <linux/io.h>
+#include <plat/irqs.h>
 
 #include <plat/gpmc.h>
 #include <plat/nand.h>
@@ -147,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
 	board_nand_data.nr_parts	= nr_parts;
 	board_nand_data.devsize		= nand_type;
 
+	board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
 	gpmc_nand_init(&board_nand_data);
 }
 #else
diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-omap/include/plat/nand.h
index 78c0bdb..ae5e053 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -13,7 +13,8 @@
 enum nand_io {
 	NAND_OMAP_PREFETCH_POLLED = 0,	/* prefetch polled mode, default */
 	NAND_OMAP_POLLED,		/* polled mode, without prefetch */
-	NAND_OMAP_PREFETCH_DMA		/* prefetch enabled sDMA mode */
+	NAND_OMAP_PREFETCH_DMA,		/* prefetch enabled sDMA mode */
+	NAND_OMAP_PREFETCH_IRQ		/* prefetch enabled irq mode */
 };
 
 struct omap_nand_platform_data {
@@ -26,6 +27,7 @@ struct omap_nand_platform_data {
 	int			(*nand_setup)(void);
 	int			(*dev_ready)(struct omap_nand_platform_data *);
 	int			dma_channel;
+	int			gpmc_irq;
 	enum nand_io		xfer_type;
 	unsigned long		phys_base;
 	int			devsize;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 66b7428..007862e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -11,6 +11,7 @@
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/delay.h>
+#include <linux/interrupt.h>
 #include <linux/jiffies.h>
 #include <linux/sched.h>
 #include <linux/mtd/mtd.h>
@@ -108,6 +109,13 @@ struct omap_nand_info {
 	unsigned long			phys_base;
 	struct completion		comp;
 	int				dma_ch;
+	int				gpmc_irq;
+	enum {
+		OMAP_NAND_IO_READ = 0,	/* read */
+		OMAP_NAND_IO_WRITE,	/* write */
+	} iomode;
+	u_char				*buf;
+	int					buf_len;
 };
 
 /**
@@ -436,6 +444,153 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
 		omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
 }
 
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+	struct omap_nand_info *info = (struct omap_nand_info *) dev;
+	u32 bytes;
+	u32 irq_stat;
+
+	irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+	bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+	bytes = bytes  & 0xFFFC; /* io in multiple of 4 bytes */
+	if (info->iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
+		if (irq_stat & 0x2)
+			goto done;
+
+		if (info->buf_len & (info->buf_len < bytes))
+			bytes = info->buf_len;
+		else if (!info->buf_len)
+			bytes = 0;
+		iowrite32_rep(info->nand.IO_ADDR_W,
+						(u32 *)info->buf, bytes >> 2);
+		info->buf = info->buf + bytes;
+		info->buf_len -= bytes;
+
+	} else {
+		ioread32_rep(info->nand.IO_ADDR_R,
+						(u32 *)info->buf, bytes >> 2);
+		info->buf = info->buf + bytes;
+
+		if (irq_stat & 0x2)
+			goto done;
+	}
+	gpmc_cs_configure(info->gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+	irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+	return IRQ_HANDLED;
+
+done:
+	complete(&info->comp);
+	/* disable irq */
+	gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+	/* clear status */
+	gpmc_cs_configure(info->gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+	irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * omap_read_buf_irq_pref - read data from NAND controller into buffer
+ * @mtd: MTD device structure
+ * @buf: buffer to store date
+ * @len: number of bytes to read
+ */
+static void omap_read_buf_irq_pref(struct mtd_info *mtd, u_char *buf, int len)
+{
+	struct omap_nand_info *info = container_of(mtd,
+						struct omap_nand_info, mtd);
+	int ret = 0;
+
+	if (len <= mtd->oobsize) {
+		omap_read_buf_pref(mtd, buf, len);
+		return;
+	}
+
+	info->iomode = OMAP_NAND_IO_READ;
+	info->buf = buf;
+	init_completion(&info->comp);
+
+	/*  configure and start prefetch transfer */
+	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
+	if (ret)
+		/* PFPW engine is busy, use cpu copy methode */
+		goto out_copy;
+
+	info->buf_len = len;
+	/* enable irq */
+	gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ,
+		(GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+	/* waiting for read to complete */
+	wait_for_completion(&info->comp);
+
+	/* disable and stop the PFPW engine */
+	gpmc_prefetch_reset(info->gpmc_cs);
+	return;
+
+out_copy:
+	if (info->nand.options & NAND_BUSWIDTH_16)
+		omap_read_buf16(mtd, buf, len);
+	else
+		omap_read_buf8(mtd, buf, len);
+}
+
+/*
+ * omap_write_buf_irq_pref - write buffer to NAND controller
+ * @mtd: MTD device structure
+ * @buf: data buffer
+ * @len: number of bytes to write
+ */
+static void omap_write_buf_irq_pref(struct mtd_info *mtd,
+					const u_char *buf, int len)
+{
+	struct omap_nand_info *info = container_of(mtd,
+						struct omap_nand_info, mtd);
+	int ret = 0;
+	if (len <= mtd->oobsize) {
+		omap_write_buf_pref(mtd, buf, len);
+		return;
+	}
+
+	info->iomode = OMAP_NAND_IO_WRITE;
+	info->buf = (u_char *) buf;
+	init_completion(&info->comp);
+
+	/*  configure and start prefetch transfer */
+	ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x1);
+	if (ret)
+		/* PFPW engine is busy, use cpu copy methode */
+		goto out_copy;
+
+	info->buf_len = len;
+	/* enable irq */
+	gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ,
+			(GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+	/* waiting for write to complete */
+	wait_for_completion(&info->comp);
+	/* wait for data to flushed-out before reset the prefetch */
+	do {
+		ret = gpmc_read_status(GPMC_PREFETCH_COUNT);
+	} while (ret);
+	/* disable and stop the PFPW engine */
+	gpmc_prefetch_reset(info->gpmc_cs);
+	return;
+
+out_copy:
+	if (info->nand.options & NAND_BUSWIDTH_16)
+		omap_write_buf16(mtd, buf, len);
+	else
+		omap_write_buf8(mtd, buf, len);
+}
+
 /**
  * omap_verify_buf - Verify chip data against buffer
  * @mtd: MTD device structure
@@ -769,6 +924,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 
 	info->gpmc_cs		= pdata->cs;
 	info->phys_base		= pdata->phys_base;
+	info->gpmc_irq		= pdata->gpmc_irq;
 
 	info->mtd.priv		= &info->nand;
 	info->mtd.name		= dev_name(&pdev->dev);
@@ -846,6 +1002,19 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 		}
 		break;
 
+	case NAND_OMAP_PREFETCH_IRQ:
+		err = request_irq(info->gpmc_irq,
+				omap_nand_irq, IRQF_SHARED, "gpmc-nand", info);
+		if (err) {
+			dev_err(&pdev->dev, "requesting irq(%d) error:%d",
+							info->gpmc_irq, err);
+			goto out_release_mem_region;
+		} else {
+			info->nand.read_buf   = omap_read_buf_irq_pref;
+			info->nand.write_buf  = omap_write_buf_irq_pref;
+		}
+		break;
+
 	default:
 		dev_err(&pdev->dev,
 			"xfer_type(%d) not supported!\n", pdata->xfer_type);
-- 
1.7.0.4



From s-ghorai at ti.com  Wed Dec 29 08:32:25 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:25 +0530
Subject: [PATCH v7 6/7] omap3: nand: ecc layout select from board file
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-7-git-send-email-s-ghorai@ti.com>

This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver.  And hw ecc layout selected for
sdp and zoom boards, by default.

Signed-off-by: Vimal Singh <vimalsingh at ti.com>
Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/mach-omap2/board-flash.c      |    1 +
 arch/arm/plat-omap/include/plat/gpmc.h |    6 ++++++
 arch/arm/plat-omap/include/plat/nand.h |    2 ++
 drivers/mtd/nand/omap2.c               |   26 +++++++++++---------------
 4 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c
index 1964509..a768198 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -148,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
 	board_nand_data.nr_parts	= nr_parts;
 	board_nand_data.devsize		= nand_type;
 
+	board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
 	board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
 	gpmc_nand_init(&board_nand_data);
 }
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index fb82335..28a5607 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,12 @@
 #define PREFETCH_FIFOTHRESHOLD_MAX	0x40
 #define PREFETCH_FIFOTHRESHOLD(val)	(val << 8)
 
+enum omap_ecc {
+		/* 1-bit ecc: stored at end of spare area */
+	OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
+	OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+};
+
 /*
  * Note that all values in this struct are in nanoseconds, while
  * the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-omap/include/plat/nand.h
index ae5e053..d86d1ec 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <plat/gpmc.h>
 #include <linux/mtd/partitions.h>
 
 enum nand_io {
@@ -31,6 +32,7 @@ struct omap_nand_platform_data {
 	enum nand_io		xfer_type;
 	unsigned long		phys_base;
 	int			devsize;
+	enum omap_ecc           ecc_opt;
 };
 
 /* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 384d89b..c6f3ea9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -618,8 +618,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const u_char * buf, int len)
 	return 0;
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
 /**
  * gen_true_ecc - This function will generate true ECC value
  * @ecc_buf: buffer to store ecc code
@@ -839,8 +837,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int mode)
 	gpmc_enable_hwecc(info->gpmc_cs, mode, dev_width, info->nand.ecc.size);
 }
 
-#endif
-
 /**
  * omap_wait - wait until the command is done
  * @mtd: MTD device structure
@@ -1030,17 +1026,17 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 
 	info->nand.verify_buf = omap_verify_buf;
 
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-	info->nand.ecc.bytes		= 3;
-	info->nand.ecc.size		= 512;
-	info->nand.ecc.calculate	= omap_calculate_ecc;
-	info->nand.ecc.hwctl		= omap_enable_hwecc;
-	info->nand.ecc.correct		= omap_correct_data;
-	info->nand.ecc.mode		= NAND_ECC_HW;
-
-#else
-	info->nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+	/* selsect the ecc type */
+	if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
+		info->nand.ecc.mode = NAND_ECC_SOFT;
+	else if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+		info->nand.ecc.bytes            = 3;
+		info->nand.ecc.size             = 512;
+		info->nand.ecc.calculate        = omap_calculate_ecc;
+		info->nand.ecc.hwctl            = omap_enable_hwecc;
+		info->nand.ecc.correct          = omap_correct_data;
+		info->nand.ecc.mode             = NAND_ECC_HW;
+	}
 
 	/* DIP switches on some boards change between 8 and 16 bit
 	 * bus widths for flash.  Try the other width if the first try fails.
-- 
1.7.0.4



From s-ghorai at ti.com  Wed Dec 29 08:32:21 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:21 +0530
Subject: [PATCH v7 2/7] omap3: nand: configurable transfer type per board
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-3-git-send-email-s-ghorai@ti.com>

nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.

this helps in multi-omap build and to select different transfer type for
different board.

Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/plat-omap/include/plat/nand.h |    7 +++
 drivers/mtd/nand/Kconfig               |   17 ------
 drivers/mtd/nand/omap2.c               |   92 +++++++++++--------------------
 3 files changed, 40 insertions(+), 76 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
 
 #include <linux/mtd/partitions.h>
 
+enum nand_io {
+	NAND_OMAP_PREFETCH_POLLED = 0,	/* prefetch polled mode, default */
+	NAND_OMAP_POLLED,		/* polled mode, without prefetch */
+	NAND_OMAP_PREFETCH_DMA		/* prefetch enabled sDMA mode */
+};
+
 struct omap_nand_platform_data {
 	unsigned int		options;
 	int			cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
 	int			(*nand_setup)(void);
 	int			(*dev_ready)(struct omap_nand_platform_data *);
 	int			dma_channel;
+	enum nand_io		xfer_type;
 	unsigned long		phys_base;
 	int			devsize;
 };
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8229802..89bb297 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -105,23 +105,6 @@ config MTD_NAND_OMAP2
 	help
           Support for NAND flash on Texas Instruments OMAP2 and OMAP3 platforms.
 
-config MTD_NAND_OMAP_PREFETCH
-	bool "GPMC prefetch support for NAND Flash device"
-	depends on MTD_NAND_OMAP2
-	default y
-	help
-	 The NAND device can be accessed for Read/Write using GPMC PREFETCH engine
-	 to improve the performance.
-
-config MTD_NAND_OMAP_PREFETCH_DMA
-	depends on MTD_NAND_OMAP_PREFETCH
-	bool "DMA mode"
-	default n
-	help
-	 The GPMC PREFETCH engine can be configured eigther in MPU interrupt mode
-	 or in DMA interrupt mode.
-	 Say y for DMA mode or MPU mode will be used
-
 config MTD_NAND_IDS
 	tristate
 
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7c04cd6..66b7428 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -96,27 +96,6 @@
 static const char *part_probes[] = { "cmdlinepart", NULL };
 #endif
 
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
-static int use_prefetch = 1;
-
-/* "modprobe ... use_prefetch=0" etc */
-module_param(use_prefetch, bool, 0);
-MODULE_PARM_DESC(use_prefetch, "enable/disable use of PREFETCH");
-
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
-static int use_dma = 1;
-
-/* "modprobe ... use_dma=0" etc */
-module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
-#else
-static const int use_dma;
-#endif
-#else
-const int use_prefetch;
-static const int use_dma;
-#endif
-
 struct omap_nand_info {
 	struct nand_hw_control		controller;
 	struct omap_nand_platform_data	*pdata;
@@ -324,7 +303,6 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
 	}
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
 /*
  * omap_nand_dma_cb: callback on the completion of dma transfer
  * @lch: logical channel
@@ -426,14 +404,6 @@ out_copy:
 			: omap_write_buf8(mtd, (u_char *) addr, len);
 	return 0;
 }
-#else
-static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
-static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
-					unsigned int len, int is_write)
-{
-	return 0;
-}
-#endif
 
 /**
  * omap_read_buf_dma_pref - read data from NAND controller into buffer
@@ -842,28 +812,13 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 		info->nand.chip_delay = 50;
 	}
 
-	if (use_prefetch) {
-
+	switch (pdata->xfer_type) {
+	case NAND_OMAP_PREFETCH_POLLED:
 		info->nand.read_buf   = omap_read_buf_pref;
 		info->nand.write_buf  = omap_write_buf_pref;
-		if (use_dma) {
-			err = omap_request_dma(OMAP24XX_DMA_GPMC, "NAND",
-				omap_nand_dma_cb, &info->comp, &info->dma_ch);
-			if (err < 0) {
-				info->dma_ch = -1;
-				printk(KERN_WARNING "DMA request failed."
-					" Non-dma data transfer mode\n");
-			} else {
-				omap_set_dma_dest_burst_mode(info->dma_ch,
-						OMAP_DMA_DATA_BURST_16);
-				omap_set_dma_src_burst_mode(info->dma_ch,
-						OMAP_DMA_DATA_BURST_16);
-
-				info->nand.read_buf   = omap_read_buf_dma_pref;
-				info->nand.write_buf  = omap_write_buf_dma_pref;
-			}
-		}
-	} else {
+		break;
+
+	case NAND_OMAP_POLLED:
 		if (info->nand.options & NAND_BUSWIDTH_16) {
 			info->nand.read_buf   = omap_read_buf16;
 			info->nand.write_buf  = omap_write_buf16;
@@ -871,7 +826,33 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 			info->nand.read_buf   = omap_read_buf8;
 			info->nand.write_buf  = omap_write_buf8;
 		}
+		break;
+
+	case NAND_OMAP_PREFETCH_DMA:
+		err = omap_request_dma(OMAP24XX_DMA_GPMC, "NAND",
+				omap_nand_dma_cb, &info->comp, &info->dma_ch);
+		if (err < 0) {
+			info->dma_ch = -1;
+			dev_err(&pdev->dev, "DMA request failed!\n");
+			goto out_release_mem_region;
+		} else {
+			omap_set_dma_dest_burst_mode(info->dma_ch,
+					OMAP_DMA_DATA_BURST_16);
+			omap_set_dma_src_burst_mode(info->dma_ch,
+					OMAP_DMA_DATA_BURST_16);
+
+			info->nand.read_buf   = omap_read_buf_dma_pref;
+			info->nand.write_buf  = omap_write_buf_dma_pref;
+		}
+		break;
+
+	default:
+		dev_err(&pdev->dev,
+			"xfer_type(%d) not supported!\n", pdata->xfer_type);
+		err = -EINVAL;
+		goto out_release_mem_region;
 	}
+
 	info->nand.verify_buf = omap_verify_buf;
 
 #ifdef CONFIG_MTD_NAND_OMAP_HWECC
@@ -897,6 +878,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
 		}
 	}
 
+
 #ifdef CONFIG_MTD_PARTITIONS
 	err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
 	if (err > 0)
@@ -926,7 +908,7 @@ static int omap_nand_remove(struct platform_device *pdev)
 							mtd);
 
 	platform_set_drvdata(pdev, NULL);
-	if (use_dma)
+	if (info->dma_ch != -1)
 		omap_free_dma(info->dma_ch);
 
 	/* Release NAND device, its internal structures and partitions */
@@ -949,14 +931,6 @@ static int __init omap_nand_init(void)
 {
 	printk(KERN_INFO "%s driver initializing\n", DRIVER_NAME);
 
-	/* This check is required if driver is being
-	 * loaded run time as a module
-	 */
-	if ((1 == use_dma) && (0 == use_prefetch)) {
-		printk(KERN_INFO"Wrong parameters: 'use_dma' can not be 1 "
-				"without use_prefetch'. Prefetch will not be"
-				" used in either mode (mpu or dma)\n");
-	}
 	return platform_driver_register(&omap_nand_driver);
 }
 
-- 
1.7.0.4



From s-ghorai at ti.com  Wed Dec 29 08:32:22 2010
From: s-ghorai at ti.com (Sukumar Ghorai)
Date: Wed, 29 Dec 2010 19:02:22 +0530
Subject: [PATCH v7 3/7] omap: gpmc: enable irq mode in gpmc
In-Reply-To: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
References: <1293629546-18831-1-git-send-email-s-ghorai@ti.com>
Message-ID: <1293629546-18831-4-git-send-email-s-ghorai@ti.com>

add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on irq.

Signed-off-by: Sukumar Ghorai <s-ghorai at ti.com>
---
 arch/arm/mach-omap2/board-2430sdp.c        |    1 +
 arch/arm/mach-omap2/board-3430sdp.c        |    1 +
 arch/arm/mach-omap2/board-3630sdp.c        |    1 +
 arch/arm/mach-omap2/board-4430sdp.c        |    2 +
 arch/arm/mach-omap2/board-am3517evm.c      |    2 +
 arch/arm/mach-omap2/board-apollon.c        |    1 +
 arch/arm/mach-omap2/board-cm-t35.c         |    1 +
 arch/arm/mach-omap2/board-devkit8000.c     |    1 +
 arch/arm/mach-omap2/board-generic.c        |    2 +
 arch/arm/mach-omap2/board-h4.c             |    1 +
 arch/arm/mach-omap2/board-igep0020.c       |    1 +
 arch/arm/mach-omap2/board-ldp.c            |    1 +
 arch/arm/mach-omap2/board-n8x0.c           |    2 +
 arch/arm/mach-omap2/board-omap3beagle.c    |    1 +
 arch/arm/mach-omap2/board-omap3evm.c       |    2 +
 arch/arm/mach-omap2/board-omap3pandora.c   |    2 +
 arch/arm/mach-omap2/board-omap3stalker.c   |    1 +
 arch/arm/mach-omap2/board-omap3touchbook.c |    1 +
 arch/arm/mach-omap2/board-omap4panda.c     |    2 +
 arch/arm/mach-omap2/board-overo.c          |    1 +
 arch/arm/mach-omap2/board-rx51.c           |    1 +
 arch/arm/mach-omap2/board-zoom2.c          |    2 +
 arch/arm/mach-omap2/board-zoom3.c          |    2 +
 arch/arm/mach-omap2/gpmc.c                 |   39 ++++++++++++++++++++++++++-
 arch/arm/mach-omap2/io.c                   |    2 -
 arch/arm/plat-omap/include/plat/gpmc.h     |    4 +++
 arch/arm/plat-omap/include/plat/irqs.h     |    9 +++++-
 27 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index b527f8d..11c89dc 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(sdp2430_config);
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 470872e..690fecd 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
 	omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
 	omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c
index 0a74141..46c1755 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -77,6 +77,7 @@ static void __init omap_sdp_init_irq(void)
 	omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
 			h8mbx00u0mer0em_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..8d15604 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -34,6 +34,7 @@
 #include <plat/common.h>
 #include <plat/usb.h>
 #include <plat/mmc.h>
+#include <plat/gpmc.h>
 
 #include "hsmmc.h"
 #include "timer-gp.h"
@@ -222,6 +223,7 @@ static void __init omap_4430sdp_init_irq(void)
 	omap2_gp_clockevent_set_gptimer(1);
 #endif
 	gic_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..460e3d1 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
 #include <plat/common.h>
 #include <plat/usb.h>
 #include <plat/display.h>
+#include <plat/gpmc.h>
 
 #include "mux.h"
 #include "control.h"
@@ -392,6 +393,7 @@ static void __init am3517_evm_init_irq(void)
 
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index 2c6db1a..8264e7a 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(apollon_config);
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 	apollon_init_smc91x();
 }
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..7c9a834 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -686,6 +686,7 @@ static void __init cm_t35_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 53ac762..f82d3b7 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -447,6 +447,7 @@ static void __init devkit8000_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 #ifdef CONFIG_OMAP_32K_TIMER
 	omap2_gp_clockevent_set_gptimer(12);
 #endif
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index b1c2c9a..0b0d2cb 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -29,6 +29,7 @@
 #include <plat/usb.h>
 #include <plat/board.h>
 #include <plat/common.h>
+#include <plat/gpmc.h>
 
 static struct omap_board_config_kernel generic_config[] = {
 };
@@ -39,6 +40,7 @@ static void __init omap_generic_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(generic_config);
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 }
 
 static void __init omap_generic_init(void)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 929993b..41b04c4 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -293,6 +293,7 @@ static void __init omap_h4_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(h4_config);
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 	h4_init_flash();
 }
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..c4de273 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -497,6 +497,7 @@ static void __init igep2_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(igep2_config);
 	omap2_init_common_hw(m65kxxxxam_sdrc_params, m65kxxxxam_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index b088b1d..489f40d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -294,6 +294,7 @@ static void __init omap_ldp_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(ldp_config);
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 	ldp_init_smsc911x();
 }
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index e823c70..4f7c714 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -33,6 +33,7 @@
 #include <plat/onenand.h>
 #include <plat/mmc.h>
 #include <plat/serial.h>
+#include <plat/gpmc.h>
 
 #include "mux.h"
 
@@ -641,6 +642,7 @@ static void __init n8x0_init_irq(void)
 {
 	omap2_init_common_hw(NULL, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 14f4224..a83c3f3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -487,6 +487,7 @@ static void __init omap3_beagle_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 #ifdef CONFIG_OMAP_32K_TIMER
 	omap2_gp_clockevent_set_gptimer(12);
 #endif
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index b04365c..21cc9e5 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -43,6 +43,7 @@
 #include <plat/common.h>
 #include <plat/mcspi.h>
 #include <plat/display.h>
+#include <plat/gpmc.h>
 
 #include "mux.h"
 #include "sdram-micron-mt46h32m32lf-6.h"
@@ -625,6 +626,7 @@ static void __init omap3_evm_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 89ed1be..e095f1d 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -47,6 +47,7 @@
 #include <plat/mcspi.h>
 #include <plat/usb.h>
 #include <plat/display.h>
+#include <plat/gpmc.h>
 #include <plat/nand.h>
 
 #include "mux.h"
@@ -639,6 +640,7 @@ static void __init omap3pandora_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index f252721..c07ba77 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -586,6 +586,7 @@ static void __init omap3_stalker_init_irq(void)
 	omap_board_config_size = ARRAY_SIZE(omap3_stalker_config);
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL);
 	omap_init_irq();
+	gpmc_init();
 #ifdef CONFIG_OMAP_32K_TIMER
 	omap2_gp_clockevent_set_gptimer(12);
 #endif
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 41104bb..d549763 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -425,6 +425,7 @@ static void __init omap3_touchbook_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 #ifdef CONFIG_OMAP_32K_TIMER
 	omap2_gp_clockevent_set_gptimer(12);
 #endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 1ecd0a6..a03a021 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -36,6 +36,7 @@
 #include <plat/common.h>
 #include <plat/usb.h>
 #include <plat/mmc.h>
+#include <plat/gpmc.h>
 #include "timer-gp.h"
 
 #include "hsmmc.h"
@@ -78,6 +79,7 @@ static void __init omap4_panda_init_irq(void)
 {
 	omap2_init_common_hw(NULL, NULL);
 	gic_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 7053bc0..c5fe2b0 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -416,6 +416,7 @@ static void __init overo_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 			     mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 36f2cf4..3be8729 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -107,6 +107,7 @@ static void __init rx51_init_irq(void)
 	omap3_pm_init_cpuidle(rx51_cpuidle_params);
 	sdrc_params = rx51_get_sdram_timings();
 	omap2_init_common_hw(sdrc_params, sdrc_params);
+	gpmc_init();
 	omap_init_irq();
 	omap_gpio_init();
 }
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c
index 994d286..b77802b 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -22,6 +22,7 @@
 
 #include <plat/common.h>
 #include <plat/board.h>
+#include <plat/gpmc.h>
 
 #include <mach/board-zoom.h>
 
@@ -34,6 +35,7 @@ static void __init omap_zoom2_init_irq(void)
 	omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
 				 mt46h32m32lf6_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-zoom3.c b/arch/arm/mach-omap2/board-zoom3.c
index 0c9c15e..d56024f 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -22,6 +22,7 @@
 #include <plat/common.h>
 #include <plat/board.h>
 #include <plat/usb.h>
+#include <plat/gpmc.h>
 
 #include "board-flash.h"
 #include "mux.h"
@@ -78,6 +79,7 @@ static void __init omap_zoom_init_irq(void)
 	omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
 			h8mbx00u0mer0em_sdrc_params);
 	omap_init_irq();
+	gpmc_init();
 	omap_gpio_init();
 }
 
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..cfaf357 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
  */
 #undef DEBUG
 
+#include <linux/irq.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/err.h>
@@ -22,12 +23,12 @@
 #include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/module.h>
+#include <linux/interrupt.h>
 
 #include <asm/mach-types.h>
 #include <plat/gpmc.h>
 
 #include <plat/sdrc.h>
-
 /* GPMC register offsets */
 #define GPMC_REVISION		0x00
 #define GPMC_SYSCONFIG		0x10
@@ -100,6 +101,8 @@ static void __iomem *gpmc_base;
 
 static struct clk *gpmc_l3_clk;
 
+static irqreturn_t gpmc_handle_irq(int irq, void *dev);
+
 static void gpmc_write_reg(int idx, u32 val)
 {
 	__raw_writel(val, gpmc_base + idx);
@@ -487,6 +490,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
 	u32 regval = 0;
 
 	switch (cmd) {
+	case GPMC_ENABLE_IRQ:
+		gpmc_write_reg(GPMC_IRQENABLE, wval);
+		break;
+
 	case GPMC_SET_IRQ_STATUS:
 		gpmc_write_reg(GPMC_IRQSTATUS, wval);
 		break;
@@ -670,7 +677,8 @@ static void __init gpmc_mem_init(void)
 
 void __init gpmc_init(void)
 {
-	u32 l;
+	u32 l, irq;
+	int cs;
 	char *ck = NULL;
 
 	if (cpu_is_omap24xx()) {
@@ -713,6 +721,33 @@ void __init gpmc_init(void)
 	l |= (0x02 << 3) | (1 << 0);
 	gpmc_write_reg(GPMC_SYSCONFIG, l);
 	gpmc_mem_init();
+
+	/* initalize the irq_chained */
+	irq = OMAP_GPMC_IRQ_BASE;
+	for (cs = 0; cs < GPMC_CS_NUM; cs++) {
+		set_irq_handler(irq, handle_simple_irq);
+		set_irq_flags(irq, IRQF_VALID);
+		irq++;
+	}
+
+	if (request_irq(INT_34XX_GPMC_IRQ,
+			gpmc_handle_irq, IRQF_SHARED, "gpmc", gpmc_base))
+		printk(KERN_ERR "gpmc: irq-%d could not claim: err %d\n",
+						INT_34XX_GPMC_IRQ, irq);
+}
+
+static irqreturn_t gpmc_handle_irq(int irq, void *dev)
+{
+	u8 cs;
+
+	if (irq != INT_34XX_GPMC_IRQ)
+		return IRQ_HANDLED;
+	/* check cs to invoke the irq */
+	cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1)) >> CS_NUM_SHIFT) & 0x7;
+	if (OMAP_GPMC_IRQ_BASE+cs <= OMAP_GPMC_IRQ_END)
+		generic_handle_irq(OMAP_GPMC_IRQ_BASE+cs);
+
+	return IRQ_HANDLED;
 }
 
 #ifdef CONFIG_ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index a1939b1..3e67a67 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -30,7 +30,6 @@
 
 #include <plat/sram.h>
 #include <plat/sdrc.h>
-#include <plat/gpmc.h>
 #include <plat/serial.h>
 
 #include "clock2xxx.h"
@@ -351,5 +350,4 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 		omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
 		_omap2_init_reprogram_sdrc();
 	}
-	gpmc_init();
 }
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..054e704 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -41,6 +41,8 @@
 #define GPMC_NAND_ADDRESS	0x0000000b
 #define GPMC_NAND_DATA		0x0000000c
 
+#define GPMC_ENABLE_IRQ		0x0000000d
+
 /* ECC commands */
 #define GPMC_ECC_READ		0 /* Reset Hardware ECC for read */
 #define GPMC_ECC_WRITE		1 /* Reset Hardware ECC for write */
@@ -78,6 +80,8 @@
 #define WR_RD_PIN_MONITORING		0x00600000
 #define GPMC_PREFETCH_STATUS_FIFO_CNT(val)	((val >> 24) & 0x7F)
 #define GPMC_PREFETCH_STATUS_COUNT(val)	(val & 0x00003fff)
+#define GPMC_IRQ_FIFOEVENTENABLE	0x01
+#define GPMC_IRQ_COUNT_EVENT		0x02
 
 /*
  * Note that all values in this struct are in nanoseconds, while
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..b90b9ef 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -318,6 +318,7 @@
 #define INT_34XX_PRCM_MPU_IRQ	11
 #define INT_34XX_MCBSP1_IRQ	16
 #define INT_34XX_MCBSP2_IRQ	17
+#define INT_34XX_GPMC_IRQ	20
 #define INT_34XX_MCBSP3_IRQ	22
 #define INT_34XX_MCBSP4_IRQ	23
 #define INT_34XX_CAM_IRQ	24
@@ -411,7 +412,13 @@
 #define TWL_IRQ_END		TWL6030_IRQ_END
 #endif
 
-#define NR_IRQS			TWL_IRQ_END
+/* GPMC related */
+#define OMAP_GPMC_IRQ_BASE	(TWL_IRQ_END)
+#define OMAP_GPMC_NR_IRQS	7
+#define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
+
+
+#define NR_IRQS			OMAP_GPMC_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)	(1 << ((irq) % 32))
 
-- 
1.7.0.4



From russ.dill at gmail.com  Wed Dec 29 15:26:58 2010
From: russ.dill at gmail.com (Russ Dill)
Date: Wed, 29 Dec 2010 13:26:58 -0700
Subject: Static UBI volumes and ubiupdatevol ?
In-Reply-To: <Pine.LNX.4.64.1012171555320.7024@lnxricardw.se.axis.com>
References: <Pine.LNX.4.64.1012150855090.6187@lnxricardw.se.axis.com>
	<Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>
	<1292516775.2364.108.camel@localhost>
	<Pine.LNX.4.64.1012171036510.7024@lnxricardw.se.axis.com>
	<1292591069.2412.25.camel@localhost>
	<Pine.LNX.4.64.1012171555320.7024@lnxricardw.se.axis.com>
Message-ID: <AANLkTi=_FUG2_SO5yKn1Sj9ksi6DzTw7W=zS9jujNjtV@mail.gmail.com>

On Fri, Dec 17, 2010 at 8:02 AM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
>
> On Fri, 17 Dec 2010, Artem Bityutskiy wrote:
>
>>>>> With a system based on mtd+jffs2 it is actually possible to reflash the
>>>>> partition with the [read only] root file system on it without
>>>>> unmounting,
>>>>> as long as no accesses are made to the physical flash during the
>>>>> rewrite
>>>>> or afterwards. In other words, immediately after reflashing the system
>>>>> must be rebooted.
>>>>
>>>> Hmm, I presume you can do this with UBIFS, but you need to make sure all
>>>> the backgound stuff like moving and eraseing eraseblocs is done before
>>>> doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
>>>> character device), see the 'vol_cdev_fsync()' function. Ah, and of
>>>> course you need to sync UBIFS before this.
>>>>
>>>> Then if you can guarantee that no one is reading writing to it, you can
>>>> change the flash.
>>>
>>> It would be nice to use ubiupdatevol to do this, but it won't let me do
>>> that if the volume is mounted (naturally). I don't know if this is
>>> something that is enforced by ubiupdatevol or ubi. I would assume the
>>> latter but I haven't checked the code.
>>>
>>> Of course I could always write my own "ubiupdatevol" to deal with this
>>> but
>>> it's always nice to use existing and supported tools.
>>
>> This is UBI - it does not allow updating if someone keeps the volume
>> open. When UBI is mounted, it keeps the volume open. It closes the
>> volume when unmounted.
>
> Yes, it make definitely makes sense to have it work this way to avoid
> problems.
>
>> It looks error-prone to allow updating while there are users, from UBI
>> POW, I think.
>
> I agree. It just happens to be the way our firmware update process works
> currently ... :-)
>
>> And I cannot think of a nice way of doing this.
>>
>> Why can't you just
>> 1. lazily unmount UBIFS
>> 2. find all users of UBIFS and kill them
>> 3. this will make UBIFS finally unmount
>> 4. you safely update the UBI volume
>
> The problem is that in this case it is our root file system which is to be
> reflashed, so we can't just unmount it. I have an idea about using
> pivot_root though, in a similar manner to the way the root file system is
> switched from initrd to disk during an ordinary Linux boot with initrd.
>
> Something like
> 1. Close down everything.
> 2. Create a tmpfs and mount it.
> 3. Copy all necessary binaries and libraries to the tmpfs.
> 4. Use pivot_root to switch root file systems.
> 5. Unmount the original (UBIFS) root file system.
> 6. Rewrite the root file system using ubiupdatevol.
> 7. Reboot.
>
> Right now I'm stumped at how to restart init in order for it to relase its
> stdin,stdout and stderr, which still refer to the (old) /dev/console, but
> there must be a solution somehow as the same situation must occur with an
> ordinary (initrd) kernel booting.
>

Busybox init knows how to do this operation. If not, a straightforward
alternative is to kexec your kernel with a small initrd that can do
the work.


From thomas at wytron.com.tw  Thu Dec 30 02:31:49 2010
From: thomas at wytron.com.tw (Thomas Chou)
Date: Thu, 30 Dec 2010 15:31:49 +0800
Subject: mkfs.jffs2 failed to create repeated dev nodes from device_table.txt
Message-ID: <4D1C3565.1030800@wytron.com.tw>

Hi experts,

I found an issue with the latest git head. The mkfs.jffs2 failed to 
create repeated dev nodes from the device_table.txt in the git tree, 
such as hda1-15, tty0-5.

It happened with this pattern,

/dev/tty	c	666	0	0	5	0	0	0	-
/dev/tty	c	666	0	0	4	0	0	1	6

# IDE Devices
/dev/hda	b	640	0	0	3	0	0	0	-
/dev/hda	b	640	0	0	3	1	1	1	15
/dev/hdb	b	640	0	0	3	64	0	0	-
/dev/hdb	b	640	0	0	3	65	1	1	15


Using jffs2dump -c, I could see only hda,

          Dirent     node at 0x004d3970, totlen 0x0000002b, #pino    14, 
version   274, #ino       276, nsize        3, name hda
          Inode      node at 0x004d399c, totlen 0x00000046, #ino    276, 
version     1, isize        0, csize        2, dsize        2, offset 
      0

Best regards,
Thomas


From ralf.roesch at rw-gmbh.de  Thu Dec 30 03:30:48 2010
From: ralf.roesch at rw-gmbh.de (=?UTF-8?B?UmFsZiBSw7ZzY2g=?=)
Date: Thu, 30 Dec 2010 09:30:48 +0100
Subject: [PATCH] mtd: nand: fix for printing NAND model
Message-ID: <4D1C4338.2030003@rw-gmbh.de>

Signed-off-by: Ralf Roesch <ralf.roesch at rw-gmbh.de>
---
 drivers/mtd/nand/nand_base.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1f75a1b..f29183a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3157,7 +3157,7 @@ ident_done:
 	printk(KERN_INFO "NAND device: Manufacturer ID:"
 		" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, *dev_id,
 		nand_manuf_ids[maf_idx].name,
-	chip->onfi_version ? type->name : chip->onfi_params.model);
+	chip->onfi_version ? chip->onfi_params.model : type->name);
  	return type;
 }
-- 
1.7.2.3



From ffainelli at freebox.fr  Thu Dec 30 03:52:30 2010
From: ffainelli at freebox.fr (Florian Fainelli)
Date: Thu, 30 Dec 2010 09:52:30 +0100
Subject: [PATCH] mtd: nand: fix for printing NAND model
In-Reply-To: <4D1C4338.2030003@rw-gmbh.de>
References: <4D1C4338.2030003@rw-gmbh.de>
Message-ID: <201012300952.30921.ffainelli@freebox.fr>

Hello,

On Thursday 30 December 2010 09:30:48 Ralf R?sch wrote:
> Signed-off-by: Ralf Roesch <ralf.roesch at rw-gmbh.de>
> ---
>  drivers/mtd/nand/nand_base.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 1f75a1b..f29183a 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3157,7 +3157,7 @@ ident_done:
>  	printk(KERN_INFO "NAND device: Manufacturer ID:"
>  		" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, *dev_id,
>  		nand_manuf_ids[maf_idx].name,
> -	chip->onfi_version ? type->name : chip->onfi_params.model);
> +	chip->onfi_version ? chip->onfi_params.model : type->name);
>   	return type;
>  }

The same fix has already been submitted and applied a couple of days ago: 
http://patchwork.ozlabs.org/patch/75222/
--
Florian


From ralf.roesch at rw-gmbh.de  Thu Dec 30 04:30:11 2010
From: ralf.roesch at rw-gmbh.de (=?UTF-8?B?UmFsZiBSw7ZzY2g=?=)
Date: Thu, 30 Dec 2010 10:30:11 +0100
Subject: [PATCH] txx9ndfmc: limit transfer bytes to 512 (ECC provides 6 bytes
	max)
Message-ID: <4D1C5123.4050804@rw-gmbh.de>

See commit: c0cbfd0e81d879a950ba6f0df3f75ea30c5ab16e
Using __nand_correct_data() helper function, this driver can read 512
byte (with 6 byte ECC) at a time.

This is correct, but not more:
With NAND chips providing page sizes > 512 Bytes
chip->ecc.bytes are calculated > 6 in txx9ndfmc_nand_scan.
According the data sheet there are (only) 6 bytes ECC available.

After applying the patch a Hynix 512M*8 with 2k page size could be
successfully formatted and used with an ubifs file system.

Signed-off-by: Ralf Roesch <ralf.roesch at rw-gmbh.de>
---
 drivers/mtd/nand/txx9ndfmc.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/txx9ndfmc.c b/drivers/mtd/nand/txx9ndfmc.c
index 054a41c..ca270a4 100644
--- a/drivers/mtd/nand/txx9ndfmc.c
+++ b/drivers/mtd/nand/txx9ndfmc.c
@@ -277,8 +277,9 @@ static int txx9ndfmc_nand_scan(struct mtd_info *mtd)
 	ret = nand_scan_ident(mtd, 1, NULL);
 	if (!ret) {
 		if (mtd->writesize >= 512) {
-			chip->ecc.size = mtd->writesize;
-			chip->ecc.bytes = 3 * (mtd->writesize / 256);
+			/* Hardware ECC 6 byte ECC per 512 Byte data */
+			chip->ecc.size = 512;
+			chip->ecc.bytes = 6;
 		}
 		ret = nand_scan_tail(mtd);
 	}
-- 
1.7.2.3



From glecerf at gmail.com  Thu Dec 30 05:32:11 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Thu, 30 Dec 2010 11:32:11 +0100
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <1292942724.2286.57.camel@localhost>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-3-git-send-email-agust@denx.de>
	<AANLkTi=DHrBiBd8j3fFR5zmuX2cXC05sEFFRdF_btK3Y@mail.gmail.com>
	<1292942724.2286.57.camel@localhost>
Message-ID: <AANLkTikmbbECMLNZ-3d=Z32RcFvsiv=eDyAwJ2=n1sHi@mail.gmail.com>

2010/12/21 Artem Bityutskiy <dedekind1 at gmail.com>:
> Yes, fair question, Anatolij?

Hi all.

Anatolij, what about such patches ?
Note : this is totally untested ;)

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 04-v2-2-6-mtd-cfi-add-writebufsiz.patch
Type: application/octet-stream
Size: 2209 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101230/bac93399/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 08-patch.patch
Type: application/octet-stream
Size: 5235 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20101230/bac93399/attachment-0003.obj>

From glecerf at gmail.com  Thu Dec 30 06:49:18 2010
From: glecerf at gmail.com (Guillaume LECERF)
Date: Thu, 30 Dec 2010 12:49:18 +0100
Subject: [PATCH v2 2/6] mtd: cfi: add writebufsize initialization
In-Reply-To: <AANLkTikmbbECMLNZ-3d=Z32RcFvsiv=eDyAwJ2=n1sHi@mail.gmail.com>
References: <292342500.2538.65.camel@localhost>
	<1292539339-25111-3-git-send-email-agust@denx.de>
	<AANLkTi=DHrBiBd8j3fFR5zmuX2cXC05sEFFRdF_btK3Y@mail.gmail.com>
	<1292942724.2286.57.camel@localhost>
	<AANLkTikmbbECMLNZ-3d=Z32RcFvsiv=eDyAwJ2=n1sHi@mail.gmail.com>
Message-ID: <AANLkTinWtEmu9nwcww4JKang+cNoHsrETT_Mojz7FF0L@mail.gmail.com>

2010/12/30 Guillaume LECERF <glecerf at gmail.com>:
> Anatolij, what about such patches ?
> Note : this is totally untested ;)

Please disregard 08-patch.patch, I think it does not even compile :(


-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org


From thomas at wytron.com.tw  Thu Dec 30 20:45:19 2010
From: thomas at wytron.com.tw (Thomas Chou)
Date: Fri, 31 Dec 2010 09:45:19 +0800
Subject: [PATCH] mkfs.jffs2: fix repeated dev nodes
In-Reply-To: <4D1C3565.1030800@wytron.com.tw>
References: <4D1C3565.1030800@wytron.com.tw>
Message-ID: <1293759919-3297-1-git-send-email-thomas@wytron.com.tw>

Fix the repeated nodes with the same primary name in device_table.txt.
They were not generated correctly.

/dev/tty    c    666    0    0    5    0    0    0    -
/dev/tty    c    666    0    0    4    0    0    1    6

# IDE Devices
/dev/hda    b    640    0    0    3    0    0    0    -
/dev/hda    b    640    0    0    3    1    1    1    15
/dev/hdb    b    640    0    0    3    64    0    0    -
/dev/hdb    b    640    0    0    3    65    1    1    15

Only created,
/dev/tty
/dev/hda
/dev/hdb

Signed-off-by: Thomas Chou <thomas at wytron.com.tw>
---
 mkfs.jffs2.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mkfs.jffs2.c b/mkfs.jffs2.c
index 256eec4..717e1cc 100644
--- a/mkfs.jffs2.c
+++ b/mkfs.jffs2.c
@@ -457,7 +457,7 @@ static int interpret_table_entry(struct filesystem_entry *root, char *line)
 			errmsg_die("Unsupported file type '%c'", type);
 	}
 	entry = find_filesystem_entry(root, name, mode);
-	if (entry) {
+	if (entry && !(count > 0 && (type == 'c' || type == 'b'))) {
 		/* Ok, we just need to fixup the existing entry
 		 * and we will be all done... */
 		entry->sb.st_uid = uid;
-- 
1.7.3.4



From thomas at wytron.com.tw  Thu Dec 30 22:16:06 2010
From: thomas at wytron.com.tw (Thomas Chou)
Date: Fri, 31 Dec 2010 11:16:06 +0800
Subject: [PATCH] mkfs.jffs2: fix devtable count as mkfs.ubifs does
In-Reply-To: <4D1C3565.1030800@wytron.com.tw>
References: <4D1C3565.1030800@wytron.com.tw>
Message-ID: <1293765366-27147-1-git-send-email-thomas@wytron.com.tw>

The counting was incorrect. Follow that of mkfs.ubifs.

Signed-off-by: Thomas Chou <thomas at wytron.com.tw>
---
 mkfs.jffs2.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mkfs.jffs2.c b/mkfs.jffs2.c
index 717e1cc..3aab533 100644
--- a/mkfs.jffs2.c
+++ b/mkfs.jffs2.c
@@ -497,10 +497,10 @@ static int interpret_table_entry(struct filesystem_entry *root, char *line)
 					unsigned long i;
 					char *dname, *hpath;
 
-					for (i = start; i < count; i++) {
+					for (i = start; i < (start + count); i++) {
 						xasprintf(&dname, "%s%lu", name, i);
 						xasprintf(&hpath, "%s/%s%lu", rootdir, name, i);
-						rdev = makedev(major, minor + (i * increment - start));
+						rdev = makedev(major, minor + (i - start) * increment);
 						add_host_filesystem_entry(dname, hpath, uid, gid,
 								mode, rdev, parent);
 						free(dname);
-- 
1.7.3.4



From vapier at gentoo.org  Fri Dec 31 00:08:44 2010
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 31 Dec 2010 00:08:44 -0500
Subject: [PATCH] mkfs.jffs2: fix devtable count as mkfs.ubifs does
In-Reply-To: <1293765366-27147-1-git-send-email-thomas@wytron.com.tw>
References: <4D1C3565.1030800@wytron.com.tw>
	<1293765366-27147-1-git-send-email-thomas@wytron.com.tw>
Message-ID: <AANLkTinuOGP7=97UOq5eRe+FxNq3zwKnQQUdCaLT_OqC@mail.gmail.com>

On Thu, Dec 30, 2010 at 22:16, Thomas Chou wrote:
> The counting was incorrect. Follow that of mkfs.ubifs.

hmm, sounds like we should rip the stuff out of both and put into
lib/devtable.c.  feel up to the challenge ?
-mike


From thomas at wytron.com.tw  Fri Dec 31 00:54:47 2010
From: thomas at wytron.com.tw (Thomas Chou)
Date: Fri, 31 Dec 2010 13:54:47 +0800
Subject: [PATCH] mkfs.jffs2: fix devtable count as mkfs.ubifs does
In-Reply-To: <AANLkTinuOGP7=97UOq5eRe+FxNq3zwKnQQUdCaLT_OqC@mail.gmail.com>
References: <4D1C3565.1030800@wytron.com.tw>
	<1293765366-27147-1-git-send-email-thomas@wytron.com.tw>
	<AANLkTinuOGP7=97UOq5eRe+FxNq3zwKnQQUdCaLT_OqC@mail.gmail.com>
Message-ID: <4D1D7027.3070503@wytron.com.tw>

On 12/31/2010 01:08 PM, Mike Frysinger wrote:
> On Thu, Dec 30, 2010 at 22:16, Thomas Chou wrote:
>> The counting was incorrect. Follow that of mkfs.ubifs.
>
> hmm, sounds like we should rip the stuff out of both and put into
> lib/devtable.c.  feel up to the challenge ?
> -mike
>
Sound great. But I am lost in the maze of kernel v2.6.37-rc and not 
ready to come up with this right now.

- Thomas


From mnalajal at codeaurora.org  Fri Dec 31 03:54:40 2010
From: mnalajal at codeaurora.org (Murali Nalajala)
Date: Fri, 31 Dec 2010 14:24:40 +0530
Subject: [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
Message-ID: <1293785680-19850-1-git-send-email-mnalajal@codeaurora.org>

From: Arve Hj?nnev?g <arve at android.com>

Add initial msm nand driver support for Qualcomm MSM and QSD platforms.
This driver is currently capable of handling 2K page nand devices.

This driver is originally
developed by Google and its source is available at
http://android.git.kernel.org/?p=kernel/experimental.git

CC: Brian Swetland <swetland at google.com>
Signed-off-by: Arve Hj?nnev?g <arve at android.com>
Signed-off-by: Murali Nalajala <mnalajal at codeaurora.org>
---
 drivers/mtd/devices/Kconfig    |   10 +
 drivers/mtd/devices/Makefile   |    1 +
 drivers/mtd/devices/msm_nand.c | 1281 ++++++++++++++++++++++++++++++++++++++++
 drivers/mtd/devices/msm_nand.h |   75 +++
 4 files changed, 1367 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/devices/msm_nand.c
 create mode 100644 drivers/mtd/devices/msm_nand.h

diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 35081ce..bcf851f 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -49,6 +49,16 @@ config MTD_MS02NV
 	  say M here and read <file:Documentation/kbuild/modules.txt>.
 	  The module will be called ms02-nv.
 
+config MTD_MSM_NAND
+	tristate "MSM on-chip NAND Flash Controller driver"
+	depends on MTD && ARCH_MSM
+	help
+	  This enables the on-chip NAND flash controller driver on Qualcomm's
+	  MSM and QSD platforms.
+
+	  MSM NAND controller is capable of interface to all leading nand
+	  flash vendor devices ie Samsung, Micron, Hynix etc.
+
 config MTD_DATAFLASH
 	tristate "Support for AT45xxx DataFlash"
 	depends on SPI_MASTER && EXPERIMENTAL
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index f3226b1..fe959e8 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MTD_SLRAM)		+= slram.o
 obj-$(CONFIG_MTD_PHRAM)		+= phram.o
 obj-$(CONFIG_MTD_PMC551)	+= pmc551.o
 obj-$(CONFIG_MTD_MS02NV)	+= ms02-nv.o
+obj-$(CONFIG_MTD_MSM_NAND)	+= msm_nand.o
 obj-$(CONFIG_MTD_MTDRAM)	+= mtdram.o
 obj-$(CONFIG_MTD_LART)		+= lart.o
 obj-$(CONFIG_MTD_BLOCK2MTD)	+= block2mtd.o
diff --git a/drivers/mtd/devices/msm_nand.c b/drivers/mtd/devices/msm_nand.c
new file mode 100644
index 0000000..89b7e03
--- /dev/null
+++ b/drivers/mtd/devices/msm_nand.c
@@ -0,0 +1,1281 @@
+/*
+ * Copyright (C) 2007 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#define pr_fmt(fmt) "%s:" fmt, __func__
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/dma-mapping.h>
+#include <asm/mach/flash.h>
+#include <mach/dma.h>
+
+#include "msm_nand.h"
+
+unsigned long msm_nand_phys;
+
+#define CFG1_WIDE_FLASH (1U << 1)
+#define MSM_NAND_DMA_BUFFER_SIZE SZ_4K
+#define MSM_NAND_DMA_BUFFER_SLOTS \
+	(MSM_NAND_DMA_BUFFER_SIZE / (sizeof(((atomic_t *)0)->counter) * 8))
+
+#define SRC_CRCI_NAND_CMD  CMD_SRC_CRCI(DMOV_NAND_CRCI_CMD)
+#define DST_CRCI_NAND_CMD  CMD_DST_CRCI(DMOV_NAND_CRCI_CMD)
+#define SRC_CRCI_NAND_DATA CMD_SRC_CRCI(DMOV_NAND_CRCI_DATA)
+#define DST_CRCI_NAND_DATA CMD_DST_CRCI(DMOV_NAND_CRCI_DATA)
+
+#define msm_virt_to_dma(chip, vaddr) \
+		 ((chip)->dma_addr + \
+		 ((uint8_t *)(vaddr) - (chip)->dma_buffer))
+
+/**
+ * struct msm_nand_chip - Describe the msm nand chip and dma properties
+ * @dev:                Holds the device structure pointer
+ * @wait_queue:         Wait queue for handling DMA buffer requests
+ * @dma_buffer_busy:    Check DMA buffer status
+ * @dma_channel:        DMA channel number
+ * @dma_buffer:         Allocated dma buffer address
+ * @dma_addr:           Bus-specific DMA address
+ * @cfg0:               Nand controller configuration0 register value
+ * @cfg1:               Nand controller configuration1 register value
+ * @ecc_buf_cfg:        Stores ECC buffer configuration
+ *
+ * This structure is used to store the DMA and nand controller information
+ */
+struct msm_nand_chip {
+	struct device *dev;
+	wait_queue_head_t wait_queue;
+	atomic_t dma_buffer_busy;
+	unsigned dma_channel;
+	uint8_t *dma_buffer;
+	dma_addr_t dma_addr;
+	unsigned cfg0, cfg1;
+	uint32_t ecc_buf_cfg;
+};
+
+/**
+ * struct msm_nand_info - Stores the mtd and nand device information
+ * @mtd:         MTD device structure
+ * @parts:       Pointer to the MTD partitions
+ * @msm_nand:    Holds the nand device information
+ *
+ * It stores the mtd properties associted to the nand device and also
+ * mtd partition details.
+ */
+struct msm_nand_info {
+	struct mtd_info         mtd;
+	struct mtd_partition    *parts;
+	struct msm_nand_chip    msm_nand;
+};
+
+/**
+ * msm_nand_oob_64 - oob info for large (2KB) page
+ */
+static struct nand_ecclayout msm_nand_oob_64 = {
+	.eccbytes	= 40,
+	.eccpos		= {
+		0,  1,  2,  3,  4,  5,  6,  7,  8,  9,
+		10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
+		20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
+		46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
+		},
+	.oobavail	= 16,
+	.oobfree	= {
+		{30, 16},
+	}
+};
+
+static void *msm_nand_get_dma_buffer(struct msm_nand_chip *chip, size_t size)
+{
+	unsigned int bitmask, free_bitmask, old_bitmask;
+	unsigned int need_mask, current_need_mask;
+	int free_index;
+
+	need_mask = (1UL << DIV_ROUND_UP(size, MSM_NAND_DMA_BUFFER_SLOTS)) - 1;
+	bitmask = atomic_read(&chip->dma_buffer_busy);
+	free_bitmask = ~bitmask;
+	do {
+		free_index = __ffs(free_bitmask);
+		current_need_mask = need_mask << free_index;
+		if ((bitmask & current_need_mask) == 0) {
+			old_bitmask =
+				atomic_cmpxchg(&chip->dma_buffer_busy,
+					       bitmask,
+					       bitmask | current_need_mask);
+			if (old_bitmask == bitmask)
+				return chip->dma_buffer +
+					free_index * MSM_NAND_DMA_BUFFER_SLOTS;
+			free_bitmask = 0; /* force return */
+		}
+		/* current free range was too small, clear all free bits */
+		/* below the top busy bit within current_need_mask */
+		free_bitmask &=
+			~(~0U >> (32 - fls(bitmask & current_need_mask)));
+	} while (free_bitmask);
+
+	return NULL;
+}
+
+static void msm_nand_release_dma_buffer(struct msm_nand_chip *chip,
+					void *buffer, size_t size)
+{
+	int index;
+	unsigned int used_mask;
+
+	used_mask = (1UL << DIV_ROUND_UP(size, MSM_NAND_DMA_BUFFER_SLOTS)) - 1;
+	index = ((uint8_t *)buffer - chip->dma_buffer) /
+		MSM_NAND_DMA_BUFFER_SLOTS;
+	atomic_sub(used_mask << index, &chip->dma_buffer_busy);
+
+	wake_up(&chip->wait_queue);
+}
+
+static uint32_t flash_read_id(struct msm_nand_chip *chip)
+{
+	struct {
+		dmov_s cmd[5];
+		unsigned cmdptr;
+		unsigned data[5];
+	} *dma_buffer;
+	uint32_t rv;
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+
+	dma_buffer->data[0] = NAND_DEV_SEL_CS0 | DM_ENABLE;
+	dma_buffer->data[1] = NAND_CMD_FETCH_ID;
+	dma_buffer->data[2] = 1;
+	dma_buffer->data[3] = MSM_NAND_STATS_INIT;
+	dma_buffer->data[4] = MSM_NAND_STATS_INIT;
+	/* verify the array size statically to avoid array overflow access */
+	BUILD_BUG_ON(4 != ARRAY_SIZE(dma_buffer->data) - 1);
+
+	dma_buffer->cmd[0].cmd = 0 | CMD_OCB;
+	dma_buffer->cmd[0].src = msm_virt_to_dma(chip, &dma_buffer->data[0]);
+	dma_buffer->cmd[0].dst = NAND_FLASH_CHIP_SELECT;
+	dma_buffer->cmd[0].len = 4;
+
+	dma_buffer->cmd[1].cmd = DST_CRCI_NAND_CMD;
+	dma_buffer->cmd[1].src = msm_virt_to_dma(chip, &dma_buffer->data[1]);
+	dma_buffer->cmd[1].dst = NAND_FLASH_CMD;
+	dma_buffer->cmd[1].len = 4;
+
+	dma_buffer->cmd[2].cmd = 0;
+	dma_buffer->cmd[2].src = msm_virt_to_dma(chip, &dma_buffer->data[2]);
+	dma_buffer->cmd[2].dst = NAND_EXEC_CMD;
+	dma_buffer->cmd[2].len = 4;
+
+	dma_buffer->cmd[3].cmd = SRC_CRCI_NAND_DATA;
+	dma_buffer->cmd[3].src = NAND_FLASH_STATUS;
+	dma_buffer->cmd[3].dst = msm_virt_to_dma(chip, &dma_buffer->data[3]);
+	dma_buffer->cmd[3].len = 4;
+
+	dma_buffer->cmd[4].cmd = CMD_OCU | CMD_LC;
+	dma_buffer->cmd[4].src = NAND_READ_ID;
+	dma_buffer->cmd[4].dst = msm_virt_to_dma(chip, &dma_buffer->data[4]);
+	dma_buffer->cmd[4].len = 4;
+	/* verify the array size statically to avoid array overflow access */
+	BUILD_BUG_ON(4 != ARRAY_SIZE(dma_buffer->cmd) - 1);
+
+	dma_buffer->cmdptr =
+		(msm_virt_to_dma(chip, dma_buffer->cmd) >> 3) | CMD_PTR_LP;
+
+	msm_dmov_exec_cmd(
+		chip->dma_channel, DMOV_CMD_PTR_LIST |
+		DMOV_CMD_ADDR(msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+	pr_debug("status: %x\n", dma_buffer->data[3]);
+	pr_debug("nandid: %x maker %02x device %02x\n",
+		dma_buffer->data[4], dma_buffer->data[4] & 0xff,
+		(dma_buffer->data[4] >> 8) & 0xff);
+	rv = dma_buffer->data[4];
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+	return rv;
+}
+
+static int flash_read_config(struct msm_nand_chip *chip)
+{
+	struct {
+		dmov_s cmd[2];
+		unsigned cmdptr;
+		unsigned cfg0;
+		unsigned cfg1;
+	} *dma_buffer;
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+	dma_buffer->cfg0 = 0;
+	dma_buffer->cfg1 = 0;
+
+	dma_buffer->cmd[0].cmd = CMD_OCB;
+	dma_buffer->cmd[0].src = NAND_DEV0_CFG0;
+	dma_buffer->cmd[0].dst = msm_virt_to_dma(chip, &dma_buffer->cfg0);
+	dma_buffer->cmd[0].len = 4;
+
+	dma_buffer->cmd[1].cmd = CMD_OCU | CMD_LC;
+	dma_buffer->cmd[1].src = NAND_DEV0_CFG1;
+	dma_buffer->cmd[1].dst = msm_virt_to_dma(chip, &dma_buffer->cfg1);
+	dma_buffer->cmd[1].len = 4;
+	/* verify the array size statically to avoid array overflow access */
+	BUILD_BUG_ON(1 != ARRAY_SIZE(dma_buffer->cmd) - 1);
+
+	dma_buffer->cmdptr =
+		(msm_virt_to_dma(chip, dma_buffer->cmd) >> 3) | CMD_PTR_LP;
+
+	msm_dmov_exec_cmd(
+		chip->dma_channel, DMOV_CMD_PTR_LIST |
+		DMOV_CMD_ADDR(msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+	chip->cfg0 = dma_buffer->cfg0;
+	chip->cfg1 = dma_buffer->cfg1;
+
+	pr_info("read cfg0 = %x, cfg1 = %x\n", chip->cfg0, chip->cfg1);
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+
+	if ((chip->cfg0 == 0) || (chip->cfg1 == 0))
+		return -ENODEV;
+
+	chip->cfg0 = (3 <<  6)  /* 4 codeword per page for 2k nand */
+		|  (516 <<  9)  /* 516 user data bytes */
+		|   (10 << 19)  /* 10 parity bytes */
+		|    (5 << 27)  /* 5 address cycles */
+		|    (1 << 30)  /* Read status before data */
+		|    (1 << 31)  /* Send read cmd */
+		/* 0 spare bytes for 16 bit nand or 1 spare bytes for 8 bit */
+		| ((chip->cfg1 & CFG1_WIDE_FLASH) ? (0 << 23) : (1 << 23));
+	chip->cfg1 = (0 <<  0)  /* Enable ecc */
+		|    (7 <<  2)  /* 8 recovery cycles */
+		|    (0 <<  5)  /* Allow CS deassertion */
+		|  (465 <<  6)  /* Bad block marker location */
+		|    (0 << 16)  /* Bad block in user data area */
+		|    (2 << 17)  /* 6 cycle tWB/tRB */
+		| (chip->cfg1 & CFG1_WIDE_FLASH); /* preserve wide flag */
+
+	return 0;
+}
+
+static unsigned flash_rd_reg(struct msm_nand_chip *chip, unsigned addr)
+{
+	struct {
+		dmov_s cmd;
+		unsigned cmdptr;
+		unsigned data;
+	} *dma_buffer;
+	unsigned rv;
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+
+	dma_buffer->cmd.cmd = CMD_LC;
+	dma_buffer->cmd.src = addr;
+	dma_buffer->cmd.dst = msm_virt_to_dma(chip, &dma_buffer->data);
+	dma_buffer->cmd.len = 4;
+
+	dma_buffer->cmdptr =
+		(msm_virt_to_dma(chip, &dma_buffer->cmd) >> 3) | CMD_PTR_LP;
+	dma_buffer->data = MSM_NAND_STATS_INIT;
+
+	msm_dmov_exec_cmd(
+		chip->dma_channel, DMOV_CMD_PTR_LIST |
+		DMOV_CMD_ADDR(msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+	rv = dma_buffer->data;
+
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+
+	return rv;
+}
+
+static void flash_wr_reg(struct msm_nand_chip *chip, unsigned addr,
+			 unsigned val)
+{
+	struct {
+		dmov_s cmd;
+		unsigned cmdptr;
+		unsigned data;
+	} *dma_buffer;
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+
+	dma_buffer->cmd.cmd = CMD_LC;
+	dma_buffer->cmd.src = msm_virt_to_dma(chip, &dma_buffer->data);
+	dma_buffer->cmd.dst = addr;
+	dma_buffer->cmd.len = 4;
+
+	dma_buffer->cmdptr =
+		(msm_virt_to_dma(chip, &dma_buffer->cmd) >> 3) | CMD_PTR_LP;
+	dma_buffer->data = val;
+
+	msm_dmov_exec_cmd(
+		chip->dma_channel, DMOV_CMD_PTR_LIST |
+		DMOV_CMD_ADDR(msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+}
+
+static int msm_nand_read_oob(struct mtd_info *mtd, loff_t from,
+			     struct mtd_oob_ops *ops)
+{
+	struct msm_nand_chip *chip = mtd->priv;
+
+	struct {
+		dmov_s cmd[4 * 5 + 3];
+		unsigned cmdptr;
+		struct {
+			uint32_t cmd;
+			uint32_t addr0;
+			uint32_t addr1;
+			uint32_t chipsel;
+			uint32_t cfg0;
+			uint32_t cfg1;
+			uint32_t exec;
+			uint32_t ecccfg;
+			struct {
+				uint32_t flash_status;
+				uint32_t buffer_status;
+			} result[4];
+		} data;
+	} *dma_buffer;
+	dmov_s *cmd;
+	unsigned n;
+	unsigned page = from / NAND_PAGE_SIZE;
+	uint32_t oob_len = ops->ooblen;
+	uint32_t sectordatasize;
+	uint32_t sectoroobsize;
+	int err, pageerr, rawerr;
+	dma_addr_t data_dma_addr = 0;
+	dma_addr_t oob_dma_addr = 0;
+	dma_addr_t data_dma_addr_curr = 0;
+	dma_addr_t oob_dma_addr_curr = 0;
+	uint32_t oob_col = 0;
+	unsigned page_count;
+	unsigned pages_read = 0;
+	unsigned start_sector = 0;
+	uint32_t ecc_errors;
+	uint32_t total_ecc_errors = 0;
+
+	if (from & (mtd->writesize - 1)) {
+		pr_err("unsupported from, 0x%llx\n", from);
+		return -EINVAL;
+	}
+	if (ops->datbuf != NULL && (ops->len % mtd->writesize) != 0) {
+		/* when ops->datbuf is NULL, ops->len may refer to ooblen */
+		pr_err("unsupported ops->len, %d\n", ops->len);
+		return -EINVAL;
+	}
+	if (ops->ooblen != 0 && ops->ooboffs != 0) {
+		pr_err("unsupported ops->ooboffs, %d\n", ops->ooboffs);
+		return -EINVAL;
+	}
+
+	if (ops->oobbuf && !ops->datbuf && ops->mode == MTD_OOB_AUTO)
+		start_sector = 3;
+
+	if (ops->oobbuf && !ops->datbuf)
+		page_count = ops->ooblen / ((ops->mode == MTD_OOB_AUTO) ?
+			mtd->oobavail : mtd->oobsize);
+	else
+		page_count = ops->len / mtd->writesize;
+
+	pr_debug("%llx %p %x %p %x\n",
+		from, ops->datbuf, ops->len, ops->oobbuf, ops->ooblen);
+
+	if (ops->datbuf) {
+		data_dma_addr_curr = data_dma_addr =
+			dma_map_single(chip->dev, ops->datbuf, ops->len,
+				       DMA_FROM_DEVICE);
+		if (dma_mapping_error(chip->dev, data_dma_addr)) {
+			pr_err("msm_nand_read_oob: failed to get dma addr "
+			       "for %p\n", ops->datbuf);
+			return -EIO;
+		}
+	}
+	if (ops->oobbuf) {
+		memset(ops->oobbuf, 0xff, ops->ooblen);
+		oob_dma_addr_curr = oob_dma_addr =
+			dma_map_single(chip->dev, ops->oobbuf,
+				       ops->ooblen, DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(chip->dev, oob_dma_addr)) {
+			pr_err("msm_nand_read_oob: failed to get dma addr "
+			       "for %p\n", ops->oobbuf);
+			err = -EIO;
+			goto err_dma_map_oobbuf_failed;
+		}
+	}
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+
+	oob_col = start_sector * 0x210;
+	if (chip->cfg1 & CFG1_WIDE_FLASH)
+		oob_col >>= 1;
+
+	err = 0;
+	while (page_count-- > 0) {
+		cmd = dma_buffer->cmd;
+
+		/* CMD / ADDR0 / ADDR1 / CHIPSEL program values */
+		dma_buffer->data.cmd = NAND_CMD_PAGE_READ_ECC;
+		dma_buffer->data.addr0 = (page << 16) | oob_col;
+		dma_buffer->data.addr1 = (page >> 16) & 0xff;
+		/* flash0 + undoc bit */
+		dma_buffer->data.chipsel = NAND_DEV_SEL_CS0 | DM_ENABLE;
+
+
+		dma_buffer->data.cfg0 =
+			(chip->cfg0 & ~(7U << 6)) | ((3U - start_sector) << 6);
+		dma_buffer->data.cfg1 = chip->cfg1;
+
+		/* GO bit for the EXEC register */
+		dma_buffer->data.exec = 1;
+
+		/* verify the array size statically to avoid array
+		 * overflow access
+		 */
+		BUILD_BUG_ON(4 != ARRAY_SIZE(dma_buffer->data.result));
+
+		for (n = start_sector; n < 4; n++) {
+			/* flash + buffer status return words */
+			dma_buffer->data.result[n].flash_status =
+							 MSM_NAND_STATS_INIT;
+			dma_buffer->data.result[n].buffer_status =
+							 MSM_NAND_STATS_INIT;
+
+			/* block on cmd ready, then
+			 * write CMD / ADDR0 / ADDR1 / CHIPSEL
+			 * regs in a burst
+			 */
+			cmd->cmd = DST_CRCI_NAND_CMD;
+			cmd->src = msm_virt_to_dma(chip, &dma_buffer->data.cmd);
+			cmd->dst = NAND_FLASH_CMD;
+			if (n == start_sector)
+				cmd->len = 16;
+			else
+				cmd->len = 4;
+			cmd++;
+
+			if (n == start_sector) {
+				cmd->cmd = 0;
+				cmd->src = msm_virt_to_dma(chip,
+							&dma_buffer->data.cfg0);
+				cmd->dst = NAND_DEV0_CFG0;
+				cmd->len = 8;
+				cmd++;
+			}
+
+			/* kick the execute register */
+			cmd->cmd = 0;
+			cmd->src =
+				msm_virt_to_dma(chip, &dma_buffer->data.exec);
+			cmd->dst = NAND_EXEC_CMD;
+			cmd->len = 4;
+			cmd++;
+
+			/* block on data ready, then
+			 * read the status register
+			 */
+			cmd->cmd = SRC_CRCI_NAND_DATA;
+			cmd->src = NAND_FLASH_STATUS;
+			cmd->dst = msm_virt_to_dma(chip,
+						   &dma_buffer->data.result[n]);
+			/* NAND_FLASH_STATUS + NAND_BUFFER_STATUS */
+			cmd->len = 8;
+			cmd++;
+
+			/* read data block
+			 * (only valid if status says success)
+			 */
+			if (ops->datbuf) {
+				sectordatasize = (n < 3) ? 516 : 500;
+				cmd->cmd = 0;
+				cmd->src = NAND_FLASH_BUFFER;
+				cmd->dst = data_dma_addr_curr;
+				data_dma_addr_curr += sectordatasize;
+				cmd->len = sectordatasize;
+				cmd++;
+			}
+
+			if (ops->oobbuf &&
+			    (n == 3 || ops->mode != MTD_OOB_AUTO)) {
+				cmd->cmd = 0;
+				if (n == 3) {
+					cmd->src = NAND_FLASH_BUFFER + 500;
+					sectoroobsize = 16;
+					if (ops->mode != MTD_OOB_AUTO)
+						sectoroobsize += 10;
+				} else {
+					cmd->src = NAND_FLASH_BUFFER + 516;
+					sectoroobsize = 10;
+				}
+
+				cmd->dst = oob_dma_addr_curr;
+				if (sectoroobsize < oob_len)
+					cmd->len = sectoroobsize;
+				else
+					cmd->len = oob_len;
+				oob_dma_addr_curr += cmd->len;
+				oob_len -= cmd->len;
+				if (cmd->len > 0)
+					cmd++;
+			}
+		}
+
+		/* verify the array size statically to avoid array
+		 * overflow access
+		 */
+		BUILD_BUG_ON(4 * 5 + 3 != ARRAY_SIZE(dma_buffer->cmd));
+		BUG_ON(cmd - dma_buffer->cmd > ARRAY_SIZE(dma_buffer->cmd));
+		dma_buffer->cmd[0].cmd |= CMD_OCB;
+		cmd[-1].cmd |= CMD_OCU | CMD_LC;
+
+		dma_buffer->cmdptr =
+			(msm_virt_to_dma(chip, dma_buffer->cmd) >> 3)
+			| CMD_PTR_LP;
+
+		msm_dmov_exec_cmd(
+			chip->dma_channel, DMOV_CMD_PTR_LIST | DMOV_CMD_ADDR(
+				msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+		/* if any of the writes failed (0x10), or there
+		 * was a protection violation (0x100), we lose
+		 */
+		pageerr = rawerr = 0;
+		for (n = start_sector; n < 4; n++) {
+			if (dma_buffer->data.result[n].flash_status & 0x110) {
+				rawerr = -EIO;
+				break;
+			}
+		}
+		if (rawerr) {
+			if (ops->datbuf) {
+				uint8_t *datbuf =
+				ops->datbuf + pages_read * mtd->writesize;
+				for (n = 0; n < mtd->writesize; n++) {
+					/* empty blocks read 0x54 at
+					 * these offsets
+					 */
+					if (n % 516 == 3 && datbuf[n] == 0x54)
+						datbuf[n] = 0xff;
+					if (datbuf[n] != 0xff) {
+						pageerr = rawerr;
+						break;
+					}
+				}
+			}
+			if (ops->oobbuf) {
+				for (n = 0; n < ops->ooblen; n++) {
+					if (ops->oobbuf[n] != 0xff) {
+						pageerr = rawerr;
+						break;
+					}
+				}
+			}
+		}
+		if (pageerr) {
+			for (n = start_sector; n < 4; n++) {
+				if (dma_buffer->data.result[n].buffer_status
+						& 0x8) {
+					/* not thread safe */
+					mtd->ecc_stats.failed++;
+					pageerr = -EBADMSG;
+					break;
+				}
+			}
+		}
+		if (!rawerr) { /* check for corretable errors */
+			for (n = start_sector; n < 4; n++) {
+				ecc_errors = dma_buffer->data.
+					result[n].buffer_status & 0x7;
+				if (ecc_errors) {
+					total_ecc_errors += ecc_errors;
+					/* not thread safe */
+					mtd->ecc_stats.corrected += ecc_errors;
+					if (ecc_errors > 1)
+						pageerr = -EUCLEAN;
+				}
+			}
+		}
+		if (pageerr && (pageerr != -EUCLEAN || err == 0))
+			err = pageerr;
+
+		if (rawerr && !pageerr) {
+			pr_err("msm_nand_read_oob %llx %x %x empty page\n",
+			       (loff_t)page * mtd->writesize, ops->len,
+			       ops->ooblen);
+		} else {
+			pr_debug("status: %x %x %x %x %x %x %x %x\n",
+				dma_buffer->data.result[0].flash_status,
+				dma_buffer->data.result[0].buffer_status,
+				dma_buffer->data.result[1].flash_status,
+				dma_buffer->data.result[1].buffer_status,
+				dma_buffer->data.result[2].flash_status,
+				dma_buffer->data.result[2].buffer_status,
+				dma_buffer->data.result[3].flash_status,
+				dma_buffer->data.result[3].buffer_status);
+		}
+
+		if (err && err != -EUCLEAN && err != -EBADMSG)
+			break;
+		pages_read++;
+		page++;
+	}
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+
+	if (ops->oobbuf) {
+		dma_unmap_single(chip->dev, oob_dma_addr,
+				 ops->ooblen, DMA_FROM_DEVICE);
+	}
+err_dma_map_oobbuf_failed:
+	if (ops->datbuf) {
+		dma_unmap_single(chip->dev, data_dma_addr,
+				 ops->len, DMA_FROM_DEVICE);
+	}
+
+	ops->retlen = mtd->writesize * pages_read;
+	ops->oobretlen = ops->ooblen - oob_len;
+	if (err)
+		pr_err("msm_nand_read_oob %llx %x %x failed %d, corrected %d\n",
+		       from, ops->datbuf ? ops->len : 0, ops->ooblen, err,
+		       total_ecc_errors);
+	return err;
+}
+
+static int
+msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len,
+	      size_t *retlen, u_char *buf)
+{
+	int ret;
+	struct mtd_oob_ops ops;
+
+
+	ops.mode = MTD_OOB_PLACE;
+	ops.len = len;
+	ops.retlen = 0;
+	ops.ooblen = 0;
+	ops.datbuf = buf;
+	ops.oobbuf = NULL;
+	ret =  msm_nand_read_oob(mtd, from, &ops);
+	*retlen = ops.retlen;
+	return ret;
+}
+
+static int
+msm_nand_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops)
+{
+	struct msm_nand_chip *chip = mtd->priv;
+	struct {
+		dmov_s cmd[4 * 5 + 3];
+		unsigned cmdptr;
+		struct {
+			uint32_t cmd;
+			uint32_t addr0;
+			uint32_t addr1;
+			uint32_t chipsel;
+			uint32_t cfg0;
+			uint32_t cfg1;
+			uint32_t exec;
+			uint32_t ecccfg;
+			uint32_t flash_status[4];
+		} data;
+	} *dma_buffer;
+	dmov_s *cmd;
+	unsigned n;
+	unsigned page = to / NAND_PAGE_SIZE;
+	uint32_t oob_len = ops->ooblen;
+	uint32_t sectordatawritesize;
+	int err;
+	dma_addr_t data_dma_addr = 0;
+	dma_addr_t oob_dma_addr = 0;
+	dma_addr_t data_dma_addr_curr = 0;
+	dma_addr_t oob_dma_addr_curr = 0;
+	unsigned page_count;
+	unsigned pages_written = 0;
+
+	if (to & (mtd->writesize - 1)) {
+		pr_err("unsupported to, 0x%llx\n", to);
+		return -EINVAL;
+	}
+	if (ops->ooblen != 0 && ops->mode != MTD_OOB_AUTO) {
+		pr_err("unsupported ops->mode, %d\n", ops->mode);
+		return -EINVAL;
+	}
+
+	if (ops->datbuf == NULL) {
+		pr_err("unsupported ops->datbuf == NULL\n");
+		return -EINVAL;
+	}
+	if ((ops->len % mtd->writesize) != 0) {
+		pr_err("unsupported ops->len, %d\n", ops->len);
+		return -EINVAL;
+	}
+
+	if (ops->ooblen != 0 && ops->ooboffs != 0) {
+		pr_err("unsupported ops->ooboffs, %d\n", ops->ooboffs);
+		return -EINVAL;
+	}
+
+	if (ops->datbuf) {
+		data_dma_addr_curr = data_dma_addr =
+			dma_map_single(chip->dev, ops->datbuf,
+				       ops->len, DMA_TO_DEVICE);
+		if (dma_mapping_error(chip->dev, data_dma_addr)) {
+			pr_err("msm_nand_write_oob: failed to get dma addr "
+			       "for %p\n", ops->datbuf);
+			return -EIO;
+		}
+	}
+	if (ops->oobbuf) {
+		oob_dma_addr_curr = oob_dma_addr =
+			dma_map_single(chip->dev, ops->oobbuf,
+				       ops->ooblen, DMA_TO_DEVICE);
+		if (dma_mapping_error(chip->dev, oob_dma_addr)) {
+			pr_err("msm_nand_write_oob: failed to get dma addr "
+			       "for %p\n", ops->oobbuf);
+			err = -EIO;
+			goto err_dma_map_oobbuf_failed;
+		}
+	}
+
+	page_count = ops->len / mtd->writesize;
+
+	wait_event(chip->wait_queue, (dma_buffer =
+			msm_nand_get_dma_buffer(chip, sizeof(*dma_buffer))));
+
+	while (page_count-- > 0) {
+		cmd = dma_buffer->cmd;
+
+		/* CMD / ADDR0 / ADDR1 / CHIPSEL program values */
+		dma_buffer->data.cmd = NAND_CMD_PRG_PAGE;
+		dma_buffer->data.addr0 = page << 16;
+		dma_buffer->data.addr1 = (page >> 16) & 0xff;
+		dma_buffer->data.chipsel = NAND_DEV_SEL_CS0 | DM_ENABLE;
+
+		dma_buffer->data.cfg0 = chip->cfg0;
+		dma_buffer->data.cfg1 = chip->cfg1;
+
+		/* GO bit for the EXEC register */
+		dma_buffer->data.exec = 1;
+
+		/* verify the array size statically to avoid array
+		 * overflow access
+		 */
+		BUILD_BUG_ON(4 != ARRAY_SIZE(dma_buffer->data.flash_status));
+
+		for (n = 0; n < 4; n++) {
+			/* status return words */
+			dma_buffer->data.flash_status[n] = MSM_NAND_STATS_INIT;
+			/* block on cmd ready, then
+			 * write CMD / ADDR0 / ADDR1 / CHIPSEL regs in a burst
+			 */
+			cmd->cmd = DST_CRCI_NAND_CMD;
+			cmd->src =
+				msm_virt_to_dma(chip, &dma_buffer->data.cmd);
+			cmd->dst = NAND_FLASH_CMD;
+			if (n == 0)
+				cmd->len = 16;
+			else
+				cmd->len = 4;
+			cmd++;
+
+			if (n == 0) {
+				cmd->cmd = 0;
+				cmd->src = msm_virt_to_dma(chip,
+							&dma_buffer->data.cfg0);
+				cmd->dst = NAND_DEV0_CFG0;
+				cmd->len = 8;
+				cmd++;
+			}
+
+				/* write data block */
+			sectordatawritesize = (n < 3) ? 516 : 500;
+			cmd->cmd = 0;
+			cmd->src = data_dma_addr_curr;
+			data_dma_addr_curr += sectordatawritesize;
+			cmd->dst = NAND_FLASH_BUFFER;
+			cmd->len = sectordatawritesize;
+			cmd++;
+
+			if (ops->oobbuf) {
+				if (n == 3) {
+					cmd->cmd = 0;
+					cmd->src = oob_dma_addr_curr;
+					cmd->dst = NAND_FLASH_BUFFER + 500;
+					if (16 < oob_len)
+						cmd->len = 16;
+					else
+						cmd->len = oob_len;
+					oob_dma_addr_curr += cmd->len;
+					oob_len -= cmd->len;
+					if (cmd->len > 0)
+						cmd++;
+				}
+				if (ops->mode != MTD_OOB_AUTO) {
+					/* skip ecc bytes in oobbuf */
+					if (oob_len < 10) {
+						oob_dma_addr_curr += 10;
+						oob_len -= 10;
+					} else {
+						oob_dma_addr_curr += oob_len;
+						oob_len = 0;
+					}
+				}
+			}
+
+			/* kick the execute register */
+			cmd->cmd = 0;
+			cmd->src =
+				msm_virt_to_dma(chip, &dma_buffer->data.exec);
+			cmd->dst = NAND_EXEC_CMD;
+			cmd->len = 4;
+			cmd++;
+
+			/* block on data ready, then
+			 * read the status register
+			 */
+			cmd->cmd = SRC_CRCI_NAND_DATA;
+			cmd->src = NAND_FLASH_STATUS;
+			cmd->dst = msm_virt_to_dma(chip,
+					     &dma_buffer->data.flash_status[n]);
+			cmd->len = 4;
+			cmd++;
+		}
+
+		dma_buffer->cmd[0].cmd |= CMD_OCB;
+		cmd[-1].cmd |= CMD_OCU | CMD_LC;
+		/* verify the array size statically to avoid array
+		 * overflow access
+		 */
+		BUILD_BUG_ON(4 * 5 + 3 != ARRAY_SIZE(dma_buffer->cmd));
+		BUG_ON(cmd - dma_buffer->cmd > ARRAY_SIZE(dma_buffer->cmd));
+		dma_buffer->cmdptr =
+			(msm_virt_to_dma(chip, dma_buffer->cmd) >> 3) |
+			CMD_PTR_LP;
+
+		msm_dmov_exec_cmd(chip->dma_channel,
+			DMOV_CMD_PTR_LIST | DMOV_CMD_ADDR(
+				msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+		/* if any of the writes failed (0x10), or there was a
+		 * protection violation (0x100), or the program success
+		 * bit (0x80) is unset, we lose
+		 */
+		err = 0;
+		for (n = 0; n < 4; n++) {
+			if (dma_buffer->data.flash_status[n] & 0x110) {
+				err = -EIO;
+				break;
+			}
+			if (!(dma_buffer->data.flash_status[n] & 0x80)) {
+				err = -EIO;
+				break;
+			}
+		}
+
+		pr_debug("write page %d: status: %x %x %x %x\n", page,
+			dma_buffer->data.flash_status[0],
+			dma_buffer->data.flash_status[1],
+			dma_buffer->data.flash_status[2],
+			dma_buffer->data.flash_status[3]);
+
+		if (err)
+			break;
+		pages_written++;
+		page++;
+	}
+	ops->retlen = mtd->writesize * pages_written;
+	ops->oobretlen = ops->ooblen - oob_len;
+
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+
+	if (ops->oobbuf)
+		dma_unmap_single(chip->dev, oob_dma_addr,
+				 ops->ooblen, DMA_TO_DEVICE);
+err_dma_map_oobbuf_failed:
+	if (ops->datbuf)
+		dma_unmap_single(chip->dev, data_dma_addr,
+				 mtd->writesize, DMA_TO_DEVICE);
+	if (err)
+		pr_err("msm_nand_write_oob %llx %x %x failed %d\n",
+		       to, ops->len, ops->ooblen, err);
+	return err;
+}
+
+static int msm_nand_write(struct mtd_info *mtd, loff_t to, size_t len,
+			  size_t *retlen, const u_char *buf)
+{
+	int ret;
+	struct mtd_oob_ops ops;
+
+	ops.mode = MTD_OOB_PLACE;
+	ops.len = len;
+	ops.retlen = 0;
+	ops.ooblen = 0;
+	ops.datbuf = (uint8_t *)buf;
+	ops.oobbuf = NULL;
+	ret =  msm_nand_write_oob(mtd, to, &ops);
+	*retlen = ops.retlen;
+	return ret;
+}
+
+static int
+msm_nand_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+	int err;
+	struct msm_nand_chip *chip = mtd->priv;
+	struct {
+		dmov_s cmd[4];
+		unsigned cmdptr;
+		unsigned data[8];
+	} *dma_buffer;
+	unsigned page = instr->addr / NAND_PAGE_SIZE;
+
+	if (instr->addr & (mtd->erasesize - 1)) {
+		pr_err("unsupported erase address, 0x%llx\n",
+		       instr->addr);
+		return -EINVAL;
+	}
+	if (instr->len != mtd->erasesize) {
+		pr_err("unsupported erase len, %lld\n",
+		       instr->len);
+		return -EINVAL;
+	}
+
+	wait_event(chip->wait_queue,
+		   (dma_buffer = msm_nand_get_dma_buffer(
+			    chip, sizeof(*dma_buffer))));
+
+	dma_buffer->data[0] = NAND_CMD_BLOCK_ERASE;
+	dma_buffer->data[1] = page;
+	dma_buffer->data[2] = 0;
+	dma_buffer->data[3] = NAND_DEV_SEL_CS0 | DM_ENABLE;
+	dma_buffer->data[4] = 1;
+	dma_buffer->data[5] = MSM_NAND_STATS_INIT;
+	dma_buffer->data[6] = chip->cfg0 & (~(7 << 6));  /* CW_PER_PAGE = 0 */
+	dma_buffer->data[7] = chip->cfg1;
+	/* verify the array size statically to avoid array overflow access */
+	BUILD_BUG_ON(7 != ARRAY_SIZE(dma_buffer->data) - 1);
+
+	dma_buffer->cmd[0].cmd = DST_CRCI_NAND_CMD | CMD_OCB;
+	dma_buffer->cmd[0].src = msm_virt_to_dma(chip, &dma_buffer->data[0]);
+	dma_buffer->cmd[0].dst = NAND_FLASH_CMD;
+	dma_buffer->cmd[0].len = 16;
+
+	dma_buffer->cmd[1].cmd = 0;
+	dma_buffer->cmd[1].src = msm_virt_to_dma(chip, &dma_buffer->data[6]);
+	dma_buffer->cmd[1].dst = NAND_DEV0_CFG0;
+	dma_buffer->cmd[1].len = 8;
+
+	dma_buffer->cmd[2].cmd = 0;
+	dma_buffer->cmd[2].src = msm_virt_to_dma(chip, &dma_buffer->data[4]);
+	dma_buffer->cmd[2].dst = NAND_EXEC_CMD;
+	dma_buffer->cmd[2].len = 4;
+
+	dma_buffer->cmd[3].cmd = SRC_CRCI_NAND_DATA | CMD_OCU | CMD_LC;;
+	dma_buffer->cmd[3].src = NAND_FLASH_STATUS;
+	dma_buffer->cmd[3].dst = msm_virt_to_dma(chip, &dma_buffer->data[5]);
+	dma_buffer->cmd[3].len = 4;
+
+	/* verify the array size statically to avoid array overflow access */
+	BUILD_BUG_ON(3 != ARRAY_SIZE(dma_buffer->cmd) - 1);
+
+	dma_buffer->cmdptr =
+		(msm_virt_to_dma(chip, dma_buffer->cmd) >> 3) | CMD_PTR_LP;
+
+	msm_dmov_exec_cmd(
+		chip->dma_channel, DMOV_CMD_PTR_LIST |
+		DMOV_CMD_ADDR(msm_virt_to_dma(chip, &dma_buffer->cmdptr)));
+
+	/* we fail if there was an operation error, a mpu error, or the
+	 * erase success bit was not set.
+	 */
+
+	if (dma_buffer->data[5] & 0x110 || !(dma_buffer->data[5] & 0x80))
+		err = -EIO;
+	else
+		err = 0;
+
+	msm_nand_release_dma_buffer(chip, dma_buffer, sizeof(*dma_buffer));
+	if (err) {
+		pr_err("erase failed, 0x%llx\n", instr->addr);
+		instr->fail_addr = instr->addr;
+		instr->state = MTD_ERASE_FAILED;
+	} else {
+		instr->state = MTD_ERASE_DONE;
+		instr->fail_addr = 0xffffffff;
+		mtd_erase_callback(instr);
+	}
+	return err;
+}
+
+static int
+msm_nand_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
+	/* Check for invalid offset */
+	if (ofs > mtd->size)
+		return -EINVAL;
+
+	return 0;
+}
+
+
+static int
+msm_nand_block_markbad(struct mtd_info *mtd, loff_t ofs)
+{
+	int ret;
+
+	ret = msm_nand_block_isbad(mtd, ofs);
+	if (ret) {
+		/* If it was bad already, return success and do nothing */
+		if (ret > 0)
+			return 0;
+		return ret;
+	}
+
+	return -EIO;
+}
+
+/**
+ * msm_nand_scan - [msm_nand Interface] Scan for the msm_nand device
+ * @mtd:        MTD device structure
+ * @maxchips:   Number of chips to scan for
+ *
+ * This fills out all the not initialized function pointers
+ * with the defaults.
+ * The flash ID is read and the mtd/chip structures are
+ * filled with the appropriate values.
+ */
+static int msm_nand_scan(struct mtd_info *mtd, int maxchips)
+{
+	unsigned n;
+	struct msm_nand_chip *chip = mtd->priv;
+	uint32_t flash_id;
+
+
+	if (flash_read_config(chip)) {
+		pr_err("ERROR: could not save cfg0 & cfg1 state\n");
+		return -ENODEV;
+	}
+	pr_info("cfg0 = %x, cfg1 = %x\n", chip->cfg0, chip->cfg1);
+	pr_info("cfg0: cw/page=%d ud_sz=%d ecc_sz=%d spare_sz=%d "
+		"num_addr_cycles=%d\n", (chip->cfg0 >> 6) & 7,
+		(chip->cfg0 >> 9) & 0x3ff, (chip->cfg0 >> 19) & 15,
+		(chip->cfg0 >> 23) & 15, (chip->cfg0 >> 27) & 7);
+
+	pr_info("NAND_READ_ID = %x\n", flash_rd_reg(chip, NAND_READ_ID));
+	flash_wr_reg(chip, NAND_READ_ID, 0x12345678);
+
+	flash_id = flash_read_id(chip);
+
+	n = flash_rd_reg(chip, NAND_DEV0_CFG0);
+	pr_info("cfg0: cw/page=%d ud_sz=%d ecc_sz=%d spare_sz=%d\n",
+		(n >> 6) & 7, (n >> 9) & 0x3ff, (n >> 19) & 15,
+		(n >> 23) & 15);
+
+	n = flash_rd_reg(chip, NAND_DEV_CMD1);
+	pr_info("DEV_CMD1: %x\n", n);
+
+	n = flash_rd_reg(chip, NAND_EBI2_ECC_BUF_CFG);
+	pr_info("NAND_EBI2_ECC_BUF_CFG: %x\n", n);
+
+	chip->ecc_buf_cfg = 0x203;
+
+	if ((flash_id & 0xffff) == 0xaaec) /* 2Gbit Samsung chip */
+		mtd->size = 256 << 20; /* * num_chips */
+	else if (flash_id == 0x5580baad) /* 2Gbit Hynix chip */
+		mtd->size = 256 << 20; /* * num_chips */
+	else if (flash_id == 0x5510baad) /* 2Gbit Hynix chip */
+		mtd->size = 256 << 20; /* * num_chips */
+	pr_info("flash_id: %x size %llx\n", flash_id, mtd->size);
+
+	mtd->writesize = 2048;
+	mtd->oobsize = msm_nand_oob_64.eccbytes + msm_nand_oob_64.oobavail;
+	mtd->oobavail = msm_nand_oob_64.oobavail;
+	mtd->erasesize = mtd->writesize << 6;
+	mtd->ecclayout = &msm_nand_oob_64;
+
+	/* Fill in remaining MTD driver data */
+	mtd->type = MTD_NANDFLASH;
+	mtd->flags = MTD_CAP_NANDFLASH;
+	mtd->erase = msm_nand_erase;
+	mtd->point = NULL;
+	mtd->unpoint = NULL;
+	mtd->read = msm_nand_read;
+	mtd->write = msm_nand_write;
+	mtd->read_oob = msm_nand_read_oob;
+	mtd->write_oob = msm_nand_write_oob;
+	mtd->lock = NULL;
+	mtd->suspend = NULL;
+	mtd->resume = NULL;
+	mtd->block_isbad = msm_nand_block_isbad;
+	mtd->block_markbad = msm_nand_block_markbad;
+	mtd->owner = THIS_MODULE;
+
+	return 0;
+}
+
+/**
+ * msm_nand_release - [msm_nand Interface] Free resources held by the msm_nand device
+ * @mtd:    MTD device structure
+ */
+static void msm_nand_release(struct mtd_info *mtd)
+{
+
+#ifdef CONFIG_MTD_PARTITIONS
+	/* Deregister partitions */
+	del_mtd_partitions(mtd);
+#endif
+	/* Deregister the device */
+	del_mtd_device(mtd);
+}
+
+#ifdef CONFIG_MTD_PARTITIONS
+static const char const *part_probes[] = { "cmdlinepart", NULL,  };
+#endif
+
+static int __devinit msm_nand_probe(struct platform_device *pdev)
+{
+	struct msm_nand_info *info;
+	struct resource *res;
+	struct flash_platform_data const *pdata = pdev->dev.platform_data;
+	int err;
+
+	res = platform_get_resource_byname(pdev,
+					IORESOURCE_MEM, "msm_nand_phys");
+	if (!res || !res->start) {
+		pr_err("msm_nand_phys resource invalid/absent\n");
+		return -EINVAL;
+	}
+	msm_nand_phys = res->start;
+	pr_debug("phys addr 0x%lx\n", msm_nand_phys);
+
+	res = platform_get_resource_byname(pdev,
+					IORESOURCE_DMA, "msm_nand_dmac");
+	if (!res || !res->start) {
+		pr_err("Invalid msm_nand_dmac resource\n");
+		return -EINVAL;
+	}
+
+	info = kzalloc(sizeof(struct msm_nand_info), GFP_KERNEL);
+	if (!info) {
+		pr_err("No memory for msm_nand_info\n");
+		return -ENOMEM;
+	}
+
+	info->msm_nand.dev = &pdev->dev;
+
+	init_waitqueue_head(&info->msm_nand.wait_queue);
+
+	info->msm_nand.dma_channel = res->start;
+	pr_debug("dma channel 0x%x\n", info->msm_nand.dma_channel);
+	info->msm_nand.dma_buffer =
+		dma_alloc_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
+				   &info->msm_nand.dma_addr, GFP_KERNEL);
+	if (info->msm_nand.dma_buffer == NULL) {
+		err = -ENOMEM;
+		goto out_free_info;
+	}
+
+	pr_debug("allocated dma buffer at %p, dma_addr %x\n",
+		info->msm_nand.dma_buffer, info->msm_nand.dma_addr);
+
+	info->mtd.name = dev_name(&pdev->dev);
+	info->mtd.priv = &info->msm_nand;
+	info->mtd.owner = THIS_MODULE;
+
+	if (msm_nand_scan(&info->mtd, 1)) {
+		err = -ENXIO;
+		goto out_free_dma_buffer;
+	}
+
+#ifdef CONFIG_MTD_PARTITIONS
+	err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
+	if (err > 0)
+		err = add_mtd_partitions(&info->mtd, info->parts, err);
+	else if (err <= 0 && pdata && pdata->parts)
+		err = add_mtd_partitions(&info->mtd, pdata->parts,
+					 pdata->nr_parts);
+	else
+#endif
+		err = add_mtd_device(&info->mtd);
+
+	if (err != 0)
+		goto out_free_dma_buffer;
+
+	platform_set_drvdata(pdev, info);
+
+	return 0;
+
+out_free_dma_buffer:
+	dma_free_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
+			  info->msm_nand.dma_buffer, info->msm_nand.dma_addr);
+out_free_info:
+	kfree(info);
+
+	return err;
+}
+
+static int __devexit msm_nand_remove(struct platform_device *pdev)
+{
+	struct msm_nand_info *info = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+
+#ifdef CONFIG_MTD_PARTITIONS
+	if (info->parts)
+		del_mtd_partitions(&info->mtd);
+	else
+#endif
+		del_mtd_device(&info->mtd);
+
+	msm_nand_release(&info->mtd);
+	dma_free_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
+			  info->msm_nand.dma_buffer, info->msm_nand.dma_addr);
+	kfree(info);
+
+	return 0;
+}
+
+static struct platform_driver msm_nand_driver = {
+	.probe		= msm_nand_probe,
+	.remove		= __devexit_p(msm_nand_remove),
+	.driver = {
+		.name	= "msm_nand",
+		.owner	= THIS_MODULE,
+	}
+};
+
+static int __init msm_nand_init(void)
+{
+	return platform_driver_register(&msm_nand_driver);
+}
+module_init(msm_nand_init);
+
+static void __exit msm_nand_exit(void)
+{
+	platform_driver_unregister(&msm_nand_driver);
+}
+module_exit(msm_nand_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("msm_nand flash driver code");
+MODULE_ALIAS("platform:msm_nand");
diff --git a/drivers/mtd/devices/msm_nand.h b/drivers/mtd/devices/msm_nand.h
new file mode 100644
index 0000000..c57d297
--- /dev/null
+++ b/drivers/mtd/devices/msm_nand.h
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2007 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DRIVERS_MTD_DEVICES_MSM_NAND_H
+#define __DRIVERS_MTD_DEVICES_MSM_NAND_H
+
+extern unsigned long msm_nand_phys;
+#define NAND_REG(off) (msm_nand_phys + (off))
+
+#define NAND_FLASH_CMD            NAND_REG(0x0000)
+#define NAND_ADDR0                NAND_REG(0x0004)
+#define NAND_ADDR1                NAND_REG(0x0008)
+#define NAND_FLASH_CHIP_SELECT    NAND_REG(0x000C)
+#define NAND_EXEC_CMD             NAND_REG(0x0010)
+#define NAND_FLASH_STATUS         NAND_REG(0x0014)
+#define NAND_BUFFER_STATUS        NAND_REG(0x0018)
+#define NAND_DEV0_CFG0            NAND_REG(0x0020)
+#define NAND_DEV0_CFG1            NAND_REG(0x0024)
+#define NAND_DEV1_CFG0            NAND_REG(0x0030)
+#define NAND_DEV1_CFG1            NAND_REG(0x0034)
+#define NAND_READ_ID              NAND_REG(0x0040)
+#define NAND_READ_STATUS          NAND_REG(0x0044)
+#define NAND_CONFIG_DATA          NAND_REG(0x0050)
+#define NAND_CONFIG               NAND_REG(0x0054)
+#define NAND_CONFIG_MODE          NAND_REG(0x0058)
+#define NAND_CONFIG_STATUS        NAND_REG(0x0060)
+#define NAND_MACRO1_REG           NAND_REG(0x0064)
+#define NAND_XFR_STEP1            NAND_REG(0x0070)
+#define NAND_XFR_STEP2            NAND_REG(0x0074)
+#define NAND_XFR_STEP3            NAND_REG(0x0078)
+#define NAND_XFR_STEP4            NAND_REG(0x007C)
+#define NAND_XFR_STEP5            NAND_REG(0x0080)
+#define NAND_XFR_STEP6            NAND_REG(0x0084)
+#define NAND_XFR_STEP7            NAND_REG(0x0088)
+#define NAND_DEV_CMD0             NAND_REG(0x00A0)
+#define NAND_DEV_CMD1             NAND_REG(0x00A4)
+#define NAND_DEV_CMD2             NAND_REG(0x00A8)
+#define NAND_DEV_CMD_VLD          NAND_REG(0x00AC)
+#define NAND_EBI2_MISR_SIG_REG    NAND_REG(0x00B0)
+#define NAND_EBI2_ECC_BUF_CFG     NAND_REG(0x00F0)
+#define NAND_FLASH_BUFFER         NAND_REG(0x0100)
+
+/* device commands */
+
+#define NAND_CMD_SOFT_RESET         0x01
+#define NAND_CMD_PAGE_READ          0x32
+#define NAND_CMD_PAGE_READ_ECC      0x33
+#define NAND_CMD_PAGE_READ_ALL      0x34
+#define NAND_CMD_SEQ_PAGE_READ      0x15
+#define NAND_CMD_PRG_PAGE           0x36
+#define NAND_CMD_PRG_PAGE_ECC       0x37
+#define NAND_CMD_PRG_PAGE_ALL       0x39
+#define NAND_CMD_BLOCK_ERASE        0x3A
+#define NAND_CMD_FETCH_ID           0x0B
+#define NAND_CMD_STATUS             0x0C
+#define NAND_CMD_RESET              0x0D
+
+#define MSM_NAND_STATS_INIT	    0xeeeeeeee
+#define DM_ENABLE		    (1 << 2)
+#define NAND_DEV_SEL_CS0	    (0 << 0)
+
+#define NAND_PAGE_SIZE		    2048
+
+#endif
--
1.7.3.4

--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


From stefani at seibold.net  Fri Dec 31 05:08:48 2010
From: stefani at seibold.net (stefani at seibold.net)
Date: Fri, 31 Dec 2010 11:08:48 +0100
Subject: [PATCH] New ubitunefs command to adjust tunable filesystem parameters
	on ubifs
Message-ID: <1293790128-4986-1-git-send-email-stefani@seibold.net>

From: Stefani Seibold <stefani at seibold.net>

ubitunefs allows the system administrator to adjust various tunable
filesystem  parameters on Linux ubifs filesystems. The current values of these
parameters can be displayed by using the -v or calling without any option.

Currently the ubitunefs supports the following parameters:

-x, --compr=<none|lzo|zlib>    compression type
-R, --reserved=SIZE            how much space should be reserved for super-user

Maybe it will be nice to adjust also the uid and gid of the reserved owner,
or the increase the max. size of the ubi filesystem. This will be very simple
to implement.

Signed-off-by: Stefani Seibold <stefani at seibold.net>
---
 ubi-utils/Makefile        |    5 +-
 ubi-utils/src/ubitunefs.c |  494 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 498 insertions(+), 1 deletions(-)
 create mode 100644 ubi-utils/src/ubitunefs.c

diff --git a/ubi-utils/Makefile b/ubi-utils/Makefile
index df81cd9..35260be 100644
--- a/ubi-utils/Makefile
+++ b/ubi-utils/Makefile
@@ -8,7 +8,7 @@ KERNELHDR := ../include
 CPPFLAGS += -Iinclude -Isrc -I$(KERNELHDR)
 
 LIBS = libubi libubigen libiniparser libscan
-TARGETS = ubiupdatevol ubimkvol ubirmvol ubicrc32 ubinfo ubiattach \
+TARGETS = ubitunefs ubiupdatevol ubimkvol ubirmvol ubicrc32 ubinfo ubiattach \
           ubidetach ubinize ubiformat ubirename mtdinfo ubirsvol
 
 VPATH = src
@@ -37,6 +37,9 @@ $(BUILDDIR)/ubiformat: $(addprefix $(BUILDDIR)/,\
 	ubiformat.o ubiutils-common.o libscan.a libubi.a libubigen.a)
 #	$(CC) $(CFLAGS) $(filter %.o, $^) -L. -lmtd -lscan -lubi -lubigen -o $@
 
+$(BUILDDIR)/ubitunefs: $(addprefix $(BUILDDIR)/,\
+	ubitunefs.o ubiutils-common.o libscan.a libubi.a libubigen.a)
+
 $(BUILDDIR)/libubi.a: $(BUILDDIR)/libubi.o
 
 $(BUILDDIR)/libubigen.a: $(BUILDDIR)/libubigen.o
diff --git a/ubi-utils/src/ubitunefs.c b/ubi-utils/src/ubitunefs.c
new file mode 100644
index 0000000..f8b6161
--- /dev/null
+++ b/ubi-utils/src/ubitunefs.c
@@ -0,0 +1,494 @@
+/*
+ * Copyright (C) 2007, 2008, 2010 Nokia Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ * An utility to tune a UBI filesystem.
+ *
+ * Author: Stefani Seibold <stefani at seibold.net>
+ *         in order of NSN Nokia Siemens Networks Ulm/Germany
+ * 	   based on work by Artem Bityutskiy
+ *
+ */
+
+#define PROGRAM_VERSION "0.3"
+#define PROGRAM_NAME    "ubitunefs"
+
+#define _GNU_SOURCE
+#define _LARGEFILE64_SOURCE
+#include <getopt.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <limits.h>
+#include <string.h>
+#include <stdint.h>
+#include <endian.h>
+#include <byteswap.h>
+#include <linux/types.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+
+#include <libubi.h>
+#include <crc32.h>
+#include "common.h"
+#include "ubiutils-common.h"
+#include "../mkfs.ubifs/ubifs-media.h"
+#include "../mkfs.ubifs/defs.h"
+
+static void *super_buf;
+struct ubi_dev_info dev_info;
+
+/* The variables below are set by command line arguments */
+struct args {
+	int devn;
+	int vol_id;
+	const char *node;
+	const char *vol_name;
+	int compr;
+	long long reserved;
+	int verbose;
+};
+
+static struct args args = {
+	.vol_id = -1,
+	.devn = -1,
+	.node = NULL,
+	.vol_name = NULL,
+	.compr = -1,
+	.reserved = -1,
+	.verbose = 0,
+};
+
+static const char doc[] = PROGRAM_NAME " version " PROGRAM_VERSION
+			 " - a tool for UBI filesystem tuning.";
+
+static const char optionsstr[] =
+"-d, --devn=<UBI device number>  UBI device number to get information about\n"
+"-n, --vol_id=<volume ID>        ID of UBI volume to print information about\n"
+"-N, --name=<volume name>        name of UBI volume to print information about\n"
+"-x, --compr=<none|lzo|zlib>     compression type\n"
+"-R, --reserved=SIZE             how much space should be reserved for super-user\n"
+"-v, --verbose                   verbose output\n"
+"-h, --help                      print help message\n"
+"-V, --version                   print program version";
+
+static const char usage[] =
+"Usage 1: " PROGRAM_NAME " [-d <UBI device number>] [-n <volume ID> | -N <volume name>]\n"
+"\t\t[-h] [-V] [--vol_id=<volume ID> | --name <volume name>]\n"
+"\t\t[--devn <UBI device number>] [--help] [--version]\n"
+"Usage 2: " PROGRAM_NAME " <UBI volume node file name> [-h] [-V] [--help] [--version]\n\n";
+
+static const struct option long_options[] = {
+	{ .name = "devn",      .has_arg = 1, .flag = NULL, .val = 'd' },
+	{ .name = "vol_id",    .has_arg = 1, .flag = NULL, .val = 'n' },
+	{ .name = "name",      .has_arg = 1, .flag = NULL, .val = 'N' },
+	{ .name = "help",      .has_arg = 0, .flag = NULL, .val = 'h' },
+	{ .name = "version",   .has_arg = 0, .flag = NULL, .val = 'V' },
+	{ .name = "compr",     .has_arg = 1, .flag = NULL, .val = 'c' },
+	{ .name = "reserved",  .has_arg = 1, .flag = NULL, .val = 'r' },
+	{ .name = "verbose",   .has_arg = 0, .flag = NULL, .val = 'v' },
+	{ NULL, 0, NULL, 0},
+};
+
+/**
+ * get_multiplier - convert size specifier to an integer multiplier.
+ * @str: the size specifier string
+ *
+ * This function parses the @str size specifier, which may be one of
+ * 'KiB', 'MiB', or 'GiB' into an integer multiplier. Returns positive
+ * size multiplier in case of success and %-1 in case of failure.
+ */
+static int get_multiplier(const char *str)
+{
+	if (!str)
+		return 1;
+
+	/* Remove spaces before the specifier */
+	while (*str == ' ' || *str == '\t')
+		str++;
+
+	if (!strcasecmp(str, "KB"))
+		return 1000;
+	if (!strcasecmp(str, "MB"))
+		return 1000 * 1000;
+	if (!strcasecmp(str, "GB"))
+		return 1000 * 1000 * 1000;
+	if (!strcasecmp(str, "KiB"))
+		return 1024;
+	if (!strcasecmp(str, "MiB"))
+		return 1024 * 1024;
+	if (!strcasecmp(str, "GiB"))
+		return 1024 * 1024 * 1024;
+
+	return -1;
+}
+
+/**
+ * get_bytes - convert a string containing amount of bytes into an
+ *             integer.
+ * @str: string to convert
+ *
+ * This function parses @str which may have one of 'KiB', 'MiB', or 'GiB' size
+ * specifiers. Returns positive amount of bytes in case of success and %-1 in
+ * case of failure.
+ */
+static long long get_bytes(const char *str)
+{
+	char *endp;
+	long long bytes = strtoull(str, &endp, 0);
+
+	if (endp == str || bytes < 0)
+		return errmsg("incorrect amount of bytes: \"%s\"", str);
+
+	if (*endp != '\0') {
+		int mult = get_multiplier(endp);
+
+		if (mult == -1)
+			return errmsg("bad size specifier: \"%s\" - "
+				       "should be 'KiB', 'MiB' or 'GiB'", endp);
+		bytes *= mult;
+	}
+
+	return bytes;
+}
+
+static int parse_opt(int argc, char * const argv[])
+{
+	while (1) {
+		int key;
+		char *endp;
+
+		key = getopt_long(argc, argv, "an:N:d:hVx:R:v", long_options, NULL);
+		if (key == -1)
+			break;
+
+		switch (key) {
+		case 'n':
+			args.vol_id = strtoul(optarg, &endp, 0);
+			if (*endp != '\0' || endp == optarg || args.vol_id < 0)
+				return errmsg("bad volume ID: " "\"%s\"", optarg);
+			break;
+
+		case 'N':
+			args.vol_name = optarg;
+			break;
+
+		case 'd':
+			args.devn = strtoul(optarg, &endp, 0);
+			if (*endp != '\0' || endp == optarg || args.devn < 0)
+				return errmsg("bad UBI device number: \"%s\"", optarg);
+
+			break;
+
+		case 'h':
+			fprintf(stderr, "%s\n\n", doc);
+			fprintf(stderr, "%s\n\n", usage);
+			fprintf(stderr, "%s\n", optionsstr);
+			exit(EXIT_SUCCESS);
+
+		case 'V':
+			fprintf(stderr, "%s\n", PROGRAM_VERSION);
+			exit(EXIT_SUCCESS);
+
+		case 'x':
+			if (!strcmp(optarg, "none"))
+				args.compr = UBIFS_COMPR_NONE;
+			else
+			if (!strcmp(optarg, "lzo"))
+				args.compr = UBIFS_COMPR_LZO;
+			else
+			if (!strcmp(optarg, "zlib"))
+				args.compr = UBIFS_COMPR_ZLIB;
+			else
+				return errmsg("bad compr type: \"%s\"", optarg);
+
+			break;
+
+		case 'R':
+			args.reserved = get_bytes(optarg);
+			break;
+
+		case 'v':
+			args.verbose = 1;
+			break;
+
+		case ':':
+			return errmsg("parameter is missing");
+
+		default:
+			fprintf(stderr, "Use -h for help\n");
+			return -1;
+		}
+	}
+
+	if (optind == argc - 1)
+		args.node = argv[optind];
+	else if (optind < argc)
+		return errmsg("more then one UBI device specified (use -h for help)");
+
+	return 0;
+}
+
+static int translate_dev(libubi_t libubi, const char *node)
+{
+	int err;
+
+	err = ubi_probe_node(libubi, node);
+	if (err == -1) {
+		if (errno != ENODEV)
+			return sys_errmsg("error while probing \"%s\"", node);
+		return errmsg("\"%s\" does not correspond to any UBI device or volume", node);
+	}
+
+	if (err == 1) {
+		struct ubi_dev_info dev_info;
+
+		err = ubi_get_dev_info(libubi, node, &dev_info);
+		if (err)
+			return sys_errmsg("cannot get information about UBI device \"%s\"", node);
+
+		args.devn = dev_info.dev_num;
+	} else {
+		struct ubi_vol_info vol_info;
+
+		err = ubi_get_vol_info(libubi, node, &vol_info);
+		if (err)
+			return sys_errmsg("cannot get information about UBI volume \"%s\"", node);
+
+		if (args.vol_id != -1)
+			return errmsg("both volume character device node (\"%s\") and "
+				      "volume ID (%d) are specify, use only one of them"
+				      "(use -h for help)", node, args.vol_id);
+
+		args.devn = vol_info.dev_num;
+		args.vol_id = vol_info.vol_id;
+	}
+
+	return 0;
+}
+
+static int get_vol_id_by_name(libubi_t libubi, int dev_num, const char *name)
+{
+	int err;
+	struct ubi_vol_info vol_info;
+
+	err = ubi_get_vol_info1_nm(libubi, dev_num, name, &vol_info);
+	if (err)
+		return sys_errmsg("cannot get information about volume \"%s\" on ubi%d\n", name, dev_num);
+
+	args.vol_id = vol_info.vol_id;
+
+	return 0;
+}
+
+/**
+ * read_super - read the ubifs super block
+ * @fd: device node file handle
+ * @buf: buffer (must be at least leb_size bytes)
+ */
+static int read_super(int fd, void *buf)
+{
+	struct ubifs_sb_node *sup = buf;
+	off64_t pos = UBIFS_SB_LNUM * dev_info.leb_size;
+
+	if (lseek64(fd, pos, SEEK_SET) != pos)
+		return sys_errmsg("failed seeking super block");
+
+	if (read(fd, buf, UBIFS_SB_NODE_SZ) != UBIFS_SB_NODE_SZ)
+		return sys_errmsg("read super block failed");
+
+	if (le32_to_cpu(sup->ch.magic) != UBIFS_NODE_MAGIC)
+		return sys_errmsg("invalid super block magic");
+
+	if (le32_to_cpu(sup->ch.crc) !=  mtd_crc32(UBIFS_CRC32_INIT, buf + 8, le32_to_cpu(sup->ch.len) - 8))
+		return sys_errmsg("invalid super block crc");
+
+	if (le32_to_cpu(sup->leb_size) != dev_info.leb_size)
+		return sys_errmsg("invalid super block leb_size");
+
+	return 0;
+}
+
+/**
+ * update_super - write the super block.
+ * @ubi: ubi descriptor
+ * @fd: device node file handle
+ * @buf: buffer (must be at least leb_size bytes)
+ */
+static int update_super(libubi_t ubi, int fd, void *buf)
+{
+	int len;
+	struct ubifs_sb_node *sup = buf;
+	off64_t pos = (off64_t)UBIFS_SB_LNUM * dev_info.leb_size;
+	int update = 0;
+
+	if (args.compr != -1) {
+		if (args.compr != le16_to_cpu(sup->default_compr)) {
+			sup->default_compr = cpu_to_le16(args.compr);
+			update = 1;
+		}
+	}
+
+	if (args.reserved != -1) {
+		if (args.reserved != le64_to_cpu(sup->rp_size)) {
+			sup->rp_size = cpu_to_le64(args.reserved);
+			update = 1;
+		}
+	}
+
+	if (!update) {
+		puts("Nothing changed, hence super block NOT written to flash!");
+		return 1;
+	}
+
+	len = ALIGN(ALIGN(UBIFS_SB_NODE_SZ, 8), dev_info.min_io_size);
+	memset(buf + len, 0xff, dev_info.leb_size - len);
+
+	sup->ch.crc = cpu_to_le32(mtd_crc32(UBIFS_CRC32_INIT, buf + 8, le32_to_cpu(sup->ch.len) - 8));
+
+	if (ubi_leb_change_start(ubi, fd, UBIFS_SB_LNUM, dev_info.leb_size, UBI_LONGTERM))
+		return sys_errmsg("ubi_leb_change_start failed");
+
+	if (lseek64(fd, pos, SEEK_SET) != pos)
+		return sys_errmsg("failed seeking super block");
+
+	if (write(fd, buf, dev_info.leb_size) != dev_info.leb_size)
+		return sys_errmsg("write super block failed");
+
+	return 0;
+}
+
+/**
+ * show_super - show the super block.
+ */
+static void show_super(void *buf)
+{
+	struct ubifs_sb_node *sup = buf;
+	const char *p;
+
+	switch(le16_to_cpu(sup->default_compr)) {
+	case UBIFS_COMPR_NONE:
+		p = "none";
+		break;
+	case UBIFS_COMPR_LZO:
+		p = "lzo";
+		break;
+	case UBIFS_COMPR_ZLIB:
+		p = "zlib";
+		break;
+	default:
+		p = "unknown";
+		break;
+	}
+
+	printf("UBIFS:\n");
+	printf(" default compressor: %s\n", p);
+	printf(" reserved for root: %llu bytes\n", le64_to_cpu(sup->rp_size));
+}
+
+int main(int argc, char * const argv[])
+{
+	int err;
+	libubi_t libubi;
+	char devname[128];
+	int fd;
+
+	err = parse_opt(argc, argv);
+	if (err)
+		return -1;
+
+	libubi = libubi_open();
+	if (!libubi) {
+		if (errno == 0)
+			return errmsg("UBI is not present in the system");
+		return sys_errmsg("cannot open libubi");
+	}
+
+	if (args.node) {
+		/*
+		 * A character device was specified, translate this into UBI
+		 * device number and volume ID.
+		 */
+		err = translate_dev(libubi, args.node);
+		if (err)
+			goto out_libubi;
+	}
+
+	if (args.devn == -1) {
+		errmsg("device number is missing "
+		       "(use -h for help)\n");
+		goto out_libubi;
+	}
+
+	err = ubi_get_dev_info1(libubi, args.devn, &dev_info);
+	if (err) {
+		errmsg("cannot get information about UBI device %d", args.devn);
+		goto out_libubi;
+	}
+
+	if (args.vol_name) {
+		err = get_vol_id_by_name(libubi, args.devn, args.vol_name);
+		if (err)
+			goto out_libubi;
+	}
+
+	if (args.vol_id == -1) {
+		errmsg("volume ID is missing "
+		       "(use -h for help)\n");
+		goto out_libubi;
+	}
+
+	if (!args.node) {
+		sprintf(devname, "/dev/ubi%d_%d", args.devn, args.vol_id);
+		args.node = devname;
+	}
+
+	super_buf = malloc(dev_info.leb_size);
+	if (!super_buf) {
+		errmsg("out of memory");
+		goto out_libubi;
+	}
+
+	fd = open(args.node, O_RDWR|O_EXCL);
+	if (fd == -1) {
+		errmsg("cannot open the UBI volume '%s'", args.node);
+		goto out_libubi;
+	}
+
+	err = read_super(fd, super_buf);
+	if (err)
+		goto out_libubi;
+
+	if (args.compr != -1 || args.reserved != -1)
+		update_super(libubi, fd, super_buf);
+	else
+		args.verbose = 1;
+
+	if (args.verbose)
+		show_super(super_buf);
+
+	if (err)
+		goto out_libubi;
+
+	libubi_close(libubi);
+	return 0;
+
+out_libubi:
+	libubi_close(libubi);
+	return -1;
+}
-- 
1.7.3.4



