mount costs too long

mount costs too long

[Aubrey]

Hi all,

I wrote a mtd-nand driver and enabled it with YAFFS on 2.6.18.
When I mount the mtd partition of a large page nand chip, everything works fine.
But When I replace the large page nand chip with a small page nand
chip,everything works ok except mount costs about 8 seconds. It's too
long, I think.

The same kernel and driver, the same hardware except the nand part
number( NAND01G and NAND128W), any clue?

Did anyone encounter this issue? Welcome any suggestions!

Thanks,
-Aubrey

Re: mount costs too long

[Josh Boyer]

On Fri, 2006-11-10 at 15:05 +0800, Aubrey wrote:
> Hi all,
> 
> I wrote a mtd-nand driver and enabled it with YAFFS on 2.6.18.
> When I mount the mtd partition of a large page nand chip, everything works fine.
> But When I replace the large page nand chip with a small page nand
> chip,everything works ok except mount costs about 8 seconds. It's too
> long, I think.

You might try asking on the YAFFS mailing list.  I'm not sure why
changing to a smaller chip would vary the mount time.

josh

Re: mount costs too long

[Aubrey]

On 11/10/06, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 2006-11-10 at 15:05 +0800, Aubrey wrote:
> > Hi all,
> >
> > I wrote a mtd-nand driver and enabled it with YAFFS on 2.6.18.
> > When I mount the mtd partition of a large page nand chip, everything works fine.
> > But When I replace the large page nand chip with a small page nand
> > chip,everything works ok except mount costs about 8 seconds. It's too
> > long, I think.
>
> You might try asking on the YAFFS mailing list.  I'm not sure why
> changing to a smaller chip would vary the mount time.
>
I got a clue from YAFFS mailing list, this is a known issue on 2.6.18 kernels.
It is caused by the MTD layer rework and corresponding yaffs-mtd layer
modifications. Namely, an additional translation had to be implemented
for OOB area for 512b page chips.

But I'm not sure what should be changed to fix this issue. Now I'm
using the newest yaffs, should I upgrade mtd in the kernel to the
newest version? ( The kernel I'm using is 2.6.18).

Thanks,
-Aubrey

Re: mount costs too long

[Artem Bityutskiy]

On Fri, 2006-11-10 at 22:48 +0800, Aubrey wrote:
> I got a clue from YAFFS mailing list, this is a known issue on 2.6.18 kernels.
> It is caused by the MTD layer rework and corresponding yaffs-mtd layer
> modifications. Namely, an additional translation had to be implemented
> for OOB area for 512b page chips.

Is it possible to describe this in more details? And why YAFFS people do
not fix this?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mount costs too long

[Vitaly Wool]

Artem Bityutskiy wrote:

>On Fri, 2006-11-10 at 22:48 +0800, Aubrey wrote:
>  
>
>>I got a clue from YAFFS mailing list, this is a known issue on 2.6.18 kernels.
>>It is caused by the MTD layer rework and corresponding yaffs-mtd layer
>>modifications. Namely, an additional translation had to be implemented
>>for OOB area for 512b page chips.
>>    
>>
>
>Is it possible to describe this in more details? And why YAFFS people do
>not fix this?
>
>  
>
This is more a yaffs1 problem rather than MTD's. The thing is that
yaffs1 blindly presumes SmartMedia OOB layout which is untrue for most
flashes, so an additional translation was implemented within yaffs1.

Vitaly

Re: mount costs too long

[Artem Bityutskiy]

On Fri, 2006-11-10 at 19:15 +0300, Vitaly Wool wrote:
> This is more a yaffs1 problem rather than MTD's. The thing is that
> yaffs1 blindly presumes SmartMedia OOB layout which is untrue for most
> flashes, so an additional translation was implemented within yaffs1.
> 
But Aubrey said it is 2.6.18-only, why?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mount costs too long

[Vitaly Wool]

Artem Bityutskiy wrote:

>On Fri, 2006-11-10 at 19:15 +0300, Vitaly Wool wrote:
>  
>
>>This is more a yaffs1 problem rather than MTD's. The thing is that
>>yaffs1 blindly presumes SmartMedia OOB layout which is untrue for most
>>flashes, so an additional translation was implemented within yaffs1.
>>
>>    
>>
>But Aubrey said it is 2.6.18-only, why?
>
>  
>
B/c due to the MTD layer rework, there's no way now to use custom
oobinfo in yaffs.
Therefore, as yaffs1 presumes the SmartMedia OOB layout one can either
read/write raw OOB but that will most probably break the bad block
handling, or implement a small shim layer putting spare OOB area into
SmartMedia OOB layout or back. Any other way will result in
incompatibility with the older version of yaffs1.

Vitaly

Re: mount costs too long

[Claudio Lanconelli]

Vitaly Wool wrote:
> B/c due to the MTD layer rework, there's no way now to use custom
> oobinfo in yaffs.
> Therefore, as yaffs1 presumes the SmartMedia OOB layout one can either
> read/write raw OOB but that will most probably break the bad block
> handling, or implement a small shim layer putting spare OOB area into
> SmartMedia OOB layout or back. Any other way will result in
> incompatibility with the older version of yaffs1.
>   
Is there a way to specify SmartMedia OOB layout in the board
driver?
Also ssfdc.c needs SmartMedia OOB layout to work.

Cheers,
Claudio Lanconelli

Re: mount costs too long

[Vitaly Wool]

Claudio Lanconelli wrote:

>Is there a way to specify SmartMedia OOB layout in the board
>driver?
>  
>
Yes. Still I'm not sure if you need to hack nand_base or not.

>Also ssfdc.c needs SmartMedia OOB layout to work.
>
>  
>
It's a separate case AFAIK.

Vitaly

Re: mount costs too long

[Artem Bityutskiy]

On Fri, 2006-11-10 at 19:34 +0300, Vitaly Wool wrote:
> B/c due to the MTD layer rework, there's no way now to use custom
> oobinfo in yaffs.
> Therefore, as yaffs1 presumes the SmartMedia OOB layout one can either
> read/write raw OOB but that will most probably break the bad block
> handling, or implement a small shim layer putting spare OOB area into
> SmartMedia OOB layout or back. Any other way will result in
> incompatibility with the older version of yaffs1.

OK, as it was said that YAFFS1 becomes much slower, this means that it
reads more data from OOB then if it were working with older kernel.
Right? Why it reads more data?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mount costs too long

[Aubrey]

On 11/11/06, Artem Bityutskiy <dedekind@infradead.org> wrote:
> On Fri, 2006-11-10 at 19:34 +0300, Vitaly Wool wrote:
> > B/c due to the MTD layer rework, there's no way now to use custom
> > oobinfo in yaffs.
> > Therefore, as yaffs1 presumes the SmartMedia OOB layout one can either
> > read/write raw OOB but that will most probably break the bad block
> > handling, or implement a small shim layer putting spare OOB area into
> > SmartMedia OOB layout or back. Any other way will result in
> > incompatibility with the older version of yaffs1.
>
> OK, as it was said that YAFFS1 becomes much slower, this means that it
> reads more data from OOB then if it were working with older kernel.
> Right? Why it reads more data?
>

Well, If I understand correctly, this should be a YAFFS issue. I got
the following explaination from YAFFS mailing list:
------------------
 Charles Manning to yaffs, me

On Saturday 11 November 2006 03:53, Vitaly Wool wrote:
> You'll have to do some code hacking to speed things up. I.e. you'll
> need to set up your OOB layout according to SmartMedia spec and then
> you'll be able to remove the translation shim in yaffs code.

It is important to understand this:

The mtd NAND driver is generic code that is parameterised by configuration
tables to make it flexible. This gives an (almost/often) out of the box
experience, and IMHO, is pretty slick code, but there's a cost associated
with the flexibility.

A custom driver can be a lot faster, but then it won't be generic any more.

Most people who want fast NAND speed end up writing their own custom drivers
to maximise ransfer with their hardware.
---------------------

I think I need more time to read source code to understand this. Did
anyone enable yaffs on small page NAND chip on the kernel >= 2.6.18?

-Aubrey