RE: [PATCH] OneNAND: Update OMAP OneNAND mapping using device driver model

Hi

In previous way. we have to modify omap-onenand.c file itself. and it is
difficult to adapt another omap platform.

But each platform has some different partition configurations and
chip-select.

e.g., OSK use CS2 as OneNAND, But my custom board use CS3. 

So I move the partition information to each platform as NOR does

e.g., linux/arm/arch/mach-omap1/board-*.c

Now we only modify each platform configuation file.

Regrads,

Kyungmin Park

> -----Original Message-----
> From: Bernhard Priewasser [mailto:priewasser <at> gmail.com] 
> Sent: Wednesday, August 31, 2005 11:22 PM
> To: kyungmin.park <at> samsung.com
> Cc: linux-mtd <at> lists.infradead.org
> Subject: Re: [PATCH] OneNAND: Update OMAP OneNAND mapping 
> using device driver model
> 
> Hi Kyungmin,
> 

[PATCH] More removing virtual blocks

Here is a follow-on patch for Ferenc's patch that removes virtual block
support from jffs2. Just a couple loose ends.

Pete

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

Re: Latest jffs2 broken?

> Did you try which earlier snapshot works correctly? It can be a good
> starting point where the problem is. 2005-07-30? 2005-08-01? 2005-08-05?

This problem does not occur with 2005-08-01, but does with 2005-08-02.
There were some significant changes to the frag tree code that went in
between these two snapshots.

It appears that the offending code is in readinode.c. There is code in
jffs2_get_inode_nodes(), read_dnode(), and read_more() that attempts to
optimize the NAND (writebuffered) cases to avoid redundant reads of
flash. When I removed these optimizations, the problem goes away and
everything is quite happy. It was not obvious to me what is wrong with
this code, but honestly, I'm too tired to figure it out now.

Regardless, I have attached the patch that makes latest mtd cvs work for
me. I do not have high hopes that the powers that be will want to apply
this patch, but I wanted to put it out there in case someone else is
having the same trouble. Maybe someone more familiar with this code
could take another look too.

Pete

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

Re: [PATCH] More removing virtual blocks

Peter Grayson wrote:

>Here is a follow-on patch for Ferenc's patch that removes virtual block
>support from jffs2. Just a couple loose ends.
>  
>
Thanks Pete, commited.

Ferenc

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

Re: [PATCH] OneNAND: Update OMAP OneNAND mapping using device driver model

Alright, thank you.
For my purposes it might be easier to leave it all in
driveres/mtd/onenand/[omap]-onenand.c or drivers/mtd/maps/, because I'm 
glad if I am as far away as possible from arch/ 

Regards,
Bernhard

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

NAND JFFS2 mount umount problems

HI ALL,

I used the linux-2.6.11 kernel from MIPS-LINUX.ORG. I am not sure which 
snapshot does it merged from. The drivers/mtd/mtdchar.c is:
    $Id: mtdchar.c,v 1.66 2005/01/05 18:05:11 dwmw2 Exp $

I tried to test my NAND flash driver following the steps below:

(1) Format the NAND partition to JFFS2, mount it and read/write for
100 times. There are no error at all.
    $ eraseall -j /dev/mtd/0
    $ mount -t jffs2 /dev/mtdblock/0 /mnt  

Then repeat the following step 100 times:
    $ rm -f /mnt/test.rpm
    $ cp -f /test/nand/test.rpm /mnt
    $ cp -f /mnt/test.rpm /test/nand/dump${i}.rpm
    where ${i} are [1..100]

After 100 read/write, then umount the NAND partition.

(2) If at each time, first mount /dev/mtdblock/0, copy the test.rpm file out,
then umount /dev/mtdblock/0, about 8 copied files will be corrupted.
    $ eraseall -j /dev/mtd/0
    $ mount -t jffs2 /dev/mtdblock/0 /mnt 
    $ cp -f /test/nand/test.rpm /mnt
    $ umount /mnt

Then repeat the following step 100 times:
    $ mount -t jffs2 /dev/mtdblock/0 /mnt

Re: [PATCH] OneNAND: Simple Bad Block handling support

Hi Kyungmin,

please let me bother you with another question.
It's about scanning for bad blocks during reading/writing flash (/* TODO 
handling oob */...)
What's the possibility of having a bad block at r/w? OneNAND spec isn't 
very extensive regarding handling bad blocks beside the initial scan. 
Which things must/should be done by the flash driver, which ones by the 
file system in this case?
I would be very grateful if you could give me a brief outline, I'm 
afraid BBM is a bit "too new" for us because we are used to operate on 
plain NOR... 

Thanks,
Bernhard

PS: Kyungmin, sorry for double mail

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

RE: [PATCH] OneNAND: Simple Bad Block handling support

Hi

> 
> please let me bother you with another question.
> It's about scanning for bad blocks during reading/writing 
> flash (/* TODO 
> handling oob */...)

'TODO handling oob' is for YAFFS filesystem
In JFFS2, they only use erase mark at oob area
But YAFFS use some many files, 
We needs to test YAFFS. currently not yet run and tested.

> What's the possibility of having a bad block at r/w?
 OneNAND spec isn't 
> very extensive regarding handling bad blocks beside the initial scan. 

> Which things must/should be done by the flash driver, which 
> ones by the 
> file system in this case?

I don't know the exactly but I heard that JFFS2 handles runtime badblock
internally. 
So OneNAND MTD don't care badblock handling in read/write function. 
MTD only care the initial bad block at erase operation.

> I would be very grateful if you could give me a brief outline, I'm 
> afraid BBM is a bit "too new" for us because we are used to 
> operate on 
> plain NOR... 

Re: PATCH: allow JFFS2 to write to really small disks

On Wed, 31 August 2005 11:28:12 +0200, Øyvind Harboe wrote:
> 
> The attached patch allows JFFS2 to write to really small JFFS2 disks.
> 
> This is e.g. useful when using JFFS2 for in-system one time programming
> of embedded device parameters: serial number, MAC, etc.
> 
> Comments?

> Index: build.c
> ===================================================================
> RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
> retrieving revision 1.76
> diff -u -r1.76 build.c
> --- build.c    30 Jul 2005 15:29:27 -0000	1.76
> +++ build.c    31 Aug 2005 09:01:34 -0000
>  <at>  <at>  -279,6 +279,14  <at>  <at> 
>  
> 	c->resv_blocks_write = c->resv_blocks_deletion + (size / c->sector_size);
>  
> +	/* If the flash disk is smaller than resv_blocks_write, then we 
> +	   allow writing to the disk anyway. The flash disk is then most likely
> +	      being used as write once - read many medimum, e.g. in-system configuration of 
> +	         static parameters(e.g. MAC address of device in stored in "ROM"). */
> +		 if (c->resv_blocks_write * c->sector_size > c->flash_size) {
> +		   c->resv_blocks_write = 0; 
> +		   }
> +
> 	/* When do we let the GC thread run in the background */
>  

Re: [PATCH] OneNAND: Simple Bad Block handling support

 > I don't know the exactly but I heard that JFFS2 handles runtime
 > badblock internally.
 > So OneNAND MTD don't care badblock handling in read/write function.
 > MTD only care the initial bad block at erase operation.

Isn't this rather important?  As I said, I'm rather new to the bad 
block stuff, so I'm ashamed of don't knowing it at all. Can JFFS2 
recognize a bad block without OneNAND driver explicitely reporting one?? 
I'm very interested in this thing; presumably it may be easy to find out 
having a look on the list's NAND BBT threads...

 > In our commercial software, we use another bad block handling, known
 > as Bad Block Management (BBM) based on replace instead of skip as BBT
 > So we don't care the intial bad and runtime bad.
 > Now we are trying to implement our scheme and will be released at open
 > source. But not yet available in this time.

You are speaking about RFS? I'm wondering for quite a time about the 
technical and commercial parallels/differences of MTD/JFFS2 and RFS...

Do you have any (public) comment on the occurence of (runtime) bad 
blocks? When, why, ...?

 > If do you have any question. please let me know :)

Too many to write down, but I'll try 

Regards,
Bernhard