public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Christian Gan <cgan@iders.ca>,
	manningc2@actrix.gen.nz, Nick Bane <nick@cecomputing.co.uk>,
	Marc Singer <elf@buici.com>
Cc: linux-mtd@lists.infradead.org, yaffs@toby-churchill.org
Subject: Re: Interest in DOC and YAFFS?
Date: Wed, 25 Sep 2002 09:33:46 +0200	[thread overview]
Message-ID: <200209250933.47027.tglx@linutronix.de> (raw)
In-Reply-To: <NFBBLPGPLKFIKCCPLALEEECPCEAA.cgan@iders.ca>

On Wednesday 25 September 2002 00:46, Christian Gan wrote:
> MTD Changes:
> ============
> - Finally, the current MTD uses the OOB to write the ECCs and also a "valid
> ECC" byte.  YAFFS tags has no room for the valid ECC byte in the OOB so I
> had to ignore it, which is not exactly ideal.  The byte location that the
> MTD writes to the OOB for ECC also must be changed (by defining the ecc_pos
> in the oob config).
The current nand.c in MTD CVS supports not longer a ECC-valid byte.

Further changes:
Use buffered read/write only for non pagealigned access, speed up the
aligned path by using the filesystem-buffer.

Reset chip removed from nand_select(), implicit done only, when erase is
interrupted 

waitfuntion use yield, instead of schedule_timeout

support for 6byte/512byte hardware ECC

read_ecc, write_ecc extended for different oob-layout selections: 
Implemented NAND_NONE_OOB, NAND_JFFS2_OOB, NAND_YAFFS_OOB. 
fs-driver gives one of these constants to select the oob-layout fitting
the filesystem.I have added int oobsel as parameter to each function.
oobdata can be read together with the raw data, when the fs-driver
supplies a big enough buffer. 
size = 12 * number of pages to read (256B pagesize) 
       24 * number of pages to read (512B pagesize)
The buffer contains 8/16 byte oobdata and 4/8 byte returncode from
correct_ecc
oobbuf [0-15] oob-data 1st read page 
oobbuf [16-19] return code from correct_ecc byte 0-255
oobbuf [20-23] return code from correct_ecc byte 256-511
oobbuf [24-39] oob-data 2nd read page
oobbuf [40-31] return code from correct_ecc byte 0-255
.....
The returnvalue of read_ecc is -EIO, if any correct_ecc returned -1. But
retlen is equal to the requested length, so fs-driver can decide what to
do.

oobdata can be given from filesystem to program them in one go together
with the raw data. ECC codes are filled in at the place selected by
oobsel.
This supports multipage programming. 
oobbuf[0-15] 1st page to write
oobbuf[16-31] 2nd page to write
ECC is filled in at the selected place.

I hope these changes are a good compromise for YAFFS folks. In this way
we enable YAFFS support and do not break anything. And you have HW-ECC
support out of the box. Maybe the multipage write/read is useful for you
too.

It's not the maximum speedup, which could be done with a YAFFS-specific
layer, but it enables people to use YAFFS and JFFS2 on the same machine,
even on the same flash chip. 

I started already to write a DOC hardware driver, but at the moment it's 
stucked, because I have to do some paid work :). It's not a really big 
problem to write a DOC driver  for nand.c now.

-- 
Thomas
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

      reply	other threads:[~2002-09-25  7:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-23  9:20 jffs2 and Doc 2000 eylon eyal
2002-09-24  0:03 ` Interest in DOC and YAFFS? Charles Manning
2002-09-24  3:44   ` Marc Singer
2002-09-24  3:58     ` Interest in DOC and YAFFS? --> YAFFS bootloading Charles Manning
2002-09-24  4:44       ` Marc Singer
2002-09-24  7:53         ` Russ Dill
2002-09-24 16:53           ` Marc Singer
2002-09-24 16:59             ` Russ Dill
2002-09-24 17:14               ` Marc Singer
2002-09-24 17:21                 ` Brian J. Fox
2002-09-24 17:30                 ` Russ Dill
2002-09-24 18:33                   ` Marc Singer
2002-09-24 17:44                 ` Kenneth Johansson
2002-09-24 18:37                   ` Marc Singer
2002-09-24 18:47                     ` Russ Dill
2002-09-24 20:22                       ` Marc Singer
2002-09-24 20:41                         ` Russ Dill
2002-09-24  7:23       ` Nick Bane
2002-09-24 16:55         ` Marc Singer
2002-09-24 18:23           ` Nick Bane
2002-09-24 20:53             ` Interest in DOC and YAFFS? Charles Manning
2002-09-24 22:46               ` Christian Gan
2002-09-25  7:33                 ` Thomas Gleixner [this message]

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=200209250933.47027.tglx@linutronix.de \
    --to=tglx@linutronix.de \
    --cc=cgan@iders.ca \
    --cc=elf@buici.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manningc2@actrix.gen.nz \
    --cc=nick@cecomputing.co.uk \
    --cc=yaffs@toby-churchill.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