headers
coffee_4 | 1 Aug 2009 04:54
Picon
Favicon

partial write of NOR

Are there any command for partial write of NOR flash memories?
How can i write one part of NOR flash memories?

For NAND flash memories, i can use nandwrite like this.
$ nandwrite /dev/mtd1 data --start=0x2000

Best regards,
Nobu

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 1 Aug 2009 09:21
Picon
Picon
Favicon

Re: partial write of NOR

Dear coffee_4 <at> infoseek.jp,

In message <20090801115434.coffee_4 <at> infoseek.jp> you wrote:
> Are there any command for partial write of NOR flash memories?
> How can i write one part of NOR flash memories?

dd if=... of=/dev/mtd... seek=...

Best regards,

Wolfgang Denk

--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
COBOL is for morons.                                 -- E.W. Dijkstra

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Subodh Nijsure | 1 Aug 2009 17:49
Picon

Re: Trouble getting MTD to run -- permission denied messages

I enabled some of the debug macros and attached output below,
concerned about "Chip erase not supported" debug output. Is that
reason I am not able to write to NOR flash? But I also see " Program
after Erase Suspend: supported"

Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
Primary Algorithm Table at 010A
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum:  1.7 V
Vcc Maximum:  2.0 V
Vpp Minimum:  8.5 V
Vpp Maximum:  9.5 V
Typical byte/word write timeout: 256 .s
Maximum byte/word write timeout: 512 .s
Typical full buffer write timeout: 512 .s
Maximum full buffer write timeout: 1024 .s
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 4096 ms
Chip erase not supported
Device size: 0x2000000 bytes (32 MiB)
Flash Device Interface description: 0x0001
  - x16-only asynchronous interface
Max. bytes in buffer write: 0x40
Number of Erase Block Regions: 2
  Erase Region #0: BlockSize 0x8000 bytes, 4 blocks
  Erase Region #1: BlockSize 0x20000 bytes, 255 blocks

 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roel Kluin | 2 Aug 2009 10:23
Picon
Gravatar

Re: pmcmsp-flash.c: correct clean up?

Op 29-07-09 20:52, Roel Kluin schreef:
> Hi,
> 
> I noted that cleanup_msp_flash() attempted to determine the size of
> msp_flash with `sizeof(msp_flash) / sizeof(struct mtd_info **)'
> this will not work since msp_flash is not an array.
> 
> Also I made some changes to since init_msp_flash() to clean up
> after errors. Do you have problems with this?

My former patch had whitespace issues.

Roel

diff --git a/drivers/mtd/maps/pmcmsp-flash.c b/drivers/mtd/maps/pmcmsp-flash.c
index 4768bd5..52812a9 100644
--- a/drivers/mtd/maps/pmcmsp-flash.c
+++ b/drivers/mtd/maps/pmcmsp-flash.c
 <at>  <at>  -50,7 +50,7  <at>  <at>  static int fcnt;

 static int __init init_msp_flash(void)
 {
-	int i, j;
+	int i, j, ret = -ENOMEM;
 	int offset, coff;
 	char *env;
 	int pcnt;
 <at>  <at>  -75,14 +75,16  <at>  <at>  static int __init init_msp_flash(void)
 	printk(KERN_NOTICE "Found %d PMC flash devices\n", fcnt);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Neukomm | 2 Aug 2009 16:04
Picon

patch for mkfs.ubifs devtable.c increment in dev_table is wrongly interpreted

patch for mkfs.ubifs devtable.c increment in dev_table is wrongly 
interpreted

with the device table one can add /dev entries to the root file system 
image.
The device table file contains among others the fields minor, start, 
increment and count.
If there is an entry with minor=0 start=0 increment =32 and count=4 the 
mkfs.ubifs makes
128 device entries, with minor numbers from 0 to 127
The correct version makes 4 entries with minor number 0,32,64,96.

/dev/mtd c 640 0 0 90 0 0  2 7
This gives 14 devices /dev/mtdXX instead of  7 devices.
Due to this error mtd_debug info /dev/mtd3 delivers the information of 
/dev/mtd1 instead of. 

diff --git a/mkfs.ubifs/devtable.c b/mkfs.ubifs/devtable.c
index 236a6e7..e2d96dc 100644
--- a/mkfs.ubifs/devtable.c
+++ b/mkfs.ubifs/devtable.c
 <at>  <at>  -248,7 +248,7  <at>  <at>  static int interpret_table_entry(const char *line)
                        goto out_free;
                }
        } else {
-               int i, num = start + increment * count, len = 
strlen(name) + 20;
+               int i, num = start + count, len = strlen(name) + 20;
                char *nm;
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rupesh Kumar | 3 Aug 2009 05:21
Favicon

OOB data difference

Hi all,

I booted with ramdisk rfs image and erased one of the flash partition with 
flash_eraseall (with -j option) utility. The OOB data written in the 
partition was as shown as below.

OOB:
        ff ff ff ff ff ff 9a a5
        a6 ff ff ff ff ff ff ff
        ff ff ff ff ff ff 03 33
        0c ff ff ff ff ff ff ff
        ff ff ff ff ff ff 03 c0
        3f ff ff ff ff ff ff ff
        ff ff ff ff ff ff a5 65
        a6 ff ff ff ff ff ff ff

Then, booted with jffs2 rfs image and repeated same operation, the OOB 
data written was

OOB:
        ff ff ff ff ff ff 0c 33
        0c ff ff ff ff ff ff ff
        ff ff ff ff ff ff 30 ff
        0c ff ff ff ff ff ff ff
        ff ff ff ff ff ff f3 cf
        3c ff ff ff ff ff ff ff
        ff ff ff ff ff ff ff c0
        0c ff ff ff ff ff ff ff

command used for erasing flash partition in both cases was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 3 Aug 2009 05:48
Picon

Re: patch for mkfs.ubifs devtable.c increment in dev_table is wrongly interpreted

On Sun, Aug 2, 2009 at 10:04, Daniel Neukomm wrote:
> patch for mkfs.ubifs devtable.c increment in dev_table is wrongly
> interpreted
>
> with the device table one can add /dev entries to the root file system
> image.
> The device table file contains among others the fields minor, start,
> increment and count.
> If there is an entry with minor=0 start=0 increment =32 and count=4 the
> mkfs.ubifs makes
> 128 device entries, with minor numbers from 0 to 127
> The correct version makes 4 entries with minor number 0,32,64,96.
>
> /dev/mtd c 640 0 0 90 0 0  2 7
> This gives 14 devices /dev/mtdXX instead of  7 devices.
> Due to this error mtd_debug info /dev/mtd3 delivers the information of
> /dev/mtd1 instead of.
> diff --git a/mkfs.ubifs/devtable.c b/mkfs.ubifs/devtable.c
> index 236a6e7..e2d96dc 100644

all patches should include signed-off-by tags.  please read the
Documentation/SubmittingPatches file in the linux kernel source code
for some guidelines.
-mike

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Kyungmin Park | 3 Aug 2009 07:35
Favicon

UBIFS abnormal unaligned access at OneNAND 4KiB page

Hi Adrian,

Now I'm working with 4KiB pagesize OneNAND, I got problem with
unaligned byte align again.

<7>UBIFS DBG (pid 1): read_znode: LEB 78:205824, level 0, 8 branch
<7>UBIFS DBG (pid 1): ubifs_read_node: LEB 78:206016, indexing node, length 48
onenand_mlc_read_ops_nolock[1108] buf c41bda80 1216 48
<7>UBIFS DBG (pid 1): read_znode: LEB 78:206016, level 0, 1 branch
onenand_mlc_read_ops_nolock[1108] buf c40a68c0 441 13
onenand_read_bufferram[674] area 0x400, buffer c40a68c0, offset 441, count 13
<1>Unhandled fault: external abort on non-linefetch (0x1008) at 0xc58805ba

In the previous time, we got the similar case. but the problem gone
with some patch. but it happens again.

Do you have any idea?

Of course, 2KiB pagesize is working well with same kernel

My kernel is the latest arm git tree. (2.6.31-rc4-gb0c7edf-dirty #624)

Thank you,
Kyungmin Park

onenand_mlc_read_ops_nolock[1108] buf c41bda80 1264 188
<7>UBIFS DBG (pid 1): read_znode: LEB 78:230640, level 1, 8 branch
<7>UBIFS DBG (pid 1): ubifs_read_node: LEB 78:196608, indexing node, length 188
onenand_mlc_read_ops_nolock[1108] buf c41bda80 0 188
<7>UBIFS DBG (pid 1): read_znode: LEB 78:196608, level 0, 8 branch
(Continue reading)

Permalink | Reply | 7 comments |
headers
Kyungmin Park | 3 Aug 2009 08:34
Favicon

Re: UBIFS abnormal unaligned access at OneNAND 4KiB page

On Mon, Aug 3, 2009 at 3:29 PM, Adrian Hunter<adrian.hunter <at> nokia.com> wrote:
> Kyungmin Park wrote:
>>
>> Hi Adrian,
>>
>> Now I'm working with 4KiB pagesize OneNAND, I got problem with
>> unaligned byte align again.
>>
>> <7>UBIFS DBG (pid 1): read_znode: LEB 78:205824, level 0, 8 branch
>> <7>UBIFS DBG (pid 1): ubifs_read_node: LEB 78:206016, indexing node,
>> length 48
>> onenand_mlc_read_ops_nolock[1108] buf c41bda80 1216 48
>> <7>UBIFS DBG (pid 1): read_znode: LEB 78:206016, level 0, 1 branch
>> onenand_mlc_read_ops_nolock[1108] buf c40a68c0 441 13
>> onenand_read_bufferram[674] area 0x400, buffer c40a68c0, offset 441, count
>> 13
>> <1>Unhandled fault: external abort on non-linefetch (0x1008) at 0xc58805ba
>>
>> In the previous time, we got the similar case. but the problem gone
>> with some patch. but it happens again.
>>
>> Do you have any idea?
>
> It is up to your driver to meet your bus requirements.  If the bus requires
> word (2 bytes) aligned accesses then you must check the alignment in the
> driver and read the ends words separately.

It's onenand_base.c. Only change is page size is 4KiB. others are same.

>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Adrian Hunter | 3 Aug 2009 08:40
Picon

Re: UBIFS abnormal unaligned access at OneNAND 4KiB page

Kyungmin Park wrote:
> On Mon, Aug 3, 2009 at 3:29 PM, Adrian Hunter<adrian.hunter <at> nokia.com> wrote:
>> Kyungmin Park wrote:
>>> Now I'm working with 4KiB pagesize OneNAND, I got problem with
>>> unaligned byte align again.
>>>
>>> <7>UBIFS DBG (pid 1): read_znode: LEB 78:205824, level 0, 8 branch
>>> <7>UBIFS DBG (pid 1): ubifs_read_node: LEB 78:206016, indexing node,
>>> length 48
>>> onenand_mlc_read_ops_nolock[1108] buf c41bda80 1216 48
>>> <7>UBIFS DBG (pid 1): read_znode: LEB 78:206016, level 0, 1 branch
>>> onenand_mlc_read_ops_nolock[1108] buf c40a68c0 441 13
>>> onenand_read_bufferram[674] area 0x400, buffer c40a68c0, offset 441, count
>>> 13
>>> <1>Unhandled fault: external abort on non-linefetch (0x1008) at 0xc58805ba
>>>
>>> In the previous time, we got the similar case. but the problem gone
>>> with some patch. but it happens again.
>>>
>>> Do you have any idea?
>> It is up to your driver to meet your bus requirements.  If the bus requires
>> word (2 bytes) aligned accesses then you must check the alignment in the
>> driver and read the ends words separately.
> 
> It's onenand_base.c. Only change is page size is 4KiB. others are same.
> 
>> UBIFS does make unaligned reads to the LPT e.g. reading 13 bytes at offset
>> 441
> 
> I think so. but now I got the these unaligned reads.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane