From: tglx@linutronix.de (Thomas Gleixner)
To: David Daney <ddaney@avtrex.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: mtd, mtdblock and nand ecc.
Date: Wed, 14 Apr 2004 19:36:32 +0200 [thread overview]
Message-ID: <200404141936.32655.tglx@linutronix.de> (raw)
In-Reply-To: <407D6BB6.6090504@avtrex.com>
On Wednesday 14 April 2004 18:49, David Daney wrote:
> >
> >He ? 1 minute ? Where is the time spent ?
> How should I know?
Profiling :)
> >Thats totaly out of the usual time. My boot time with JFFS2 is well below
> > 30s on an ARM7. I have no YAFFS root fs handy, but it is much faster.
> >
> >The solution is checking where the time is lost and fixing it.
>
> I have a custom nand driver (based on nand.c, but adapted to a non
> standard nand physical interface) that uses software ECC. On a 300 MHz
> mips32 cpu.
Why did you modify nand.c ?
Almost everything in nand.c can be overridden by the board driver. Therefor we
call all the functions through chip->xxx().
> When ever jffs2 or yaffs are mounted, they both seem to read many
> pages. Perhaps the ECC overhead of reading all that data.
> I suppose I could turn off ECC and see how fast it is...
Sure, that would give an estimation.
> >>That is why I am thinking about using a non NAND aware file system for
> >>things that can be read-only.
> >
> >But this does not answer my question how you want to deal with bad blocks
> > ?
>
> I want a file system very much like cramfs, but that can have holes in
> it so that it works on NAND.
> When mounted it would start scanning blocks starting from the beginning
> of the NAND partition until it found a valid superblock (or what ever
> you would call it). Then it would be done because all of the indexes
> would be built to work around the bad blocks. Since this filesystem
> would be read-only with a static structure, you would never have to read
> more than necessary.
OK, so you are going to write a fs driver, which is NAND aware and behaves
similar to cramfs.
Whatfor then the discussion about making mtdblock nand aware ?
If you write a nand aware fs then you just call the appropriate functions.
This fs will be specific for nand or selectable for nand, so what ?
No need to touch anything in mtdblock.c
--
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
next prev parent reply other threads:[~2004-04-14 17:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-14 4:37 mtd, mtdblock and nand ecc David Daney
2004-04-14 12:43 ` Thomas Gleixner
2004-04-14 14:11 ` David Daney
2004-04-14 14:48 ` Thomas Gleixner
2004-04-14 15:13 ` David Daney
2004-04-14 16:15 ` Thomas Gleixner
2004-04-14 16:49 ` David Daney
2004-04-14 17:36 ` Thomas Gleixner [this message]
2004-04-14 18:39 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200404141936.32655.tglx@linutronix.de \
--to=tglx@linutronix.de \
--cc=ddaney@avtrex.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox