From: Thomas Gleixner <gleixner@autronix.de>
To: linux-mtd@lists.infradead.org
Cc: <jffs-dev@axis.com>
Subject: Re: NAND flash and JFFS(2)
Date: Mon, 11 Feb 2002 16:32:01 +0100 [thread overview]
Message-ID: <02021116320106.00764@thomas> (raw)
On Monday, 11. February 2002 14:53, David Woodhouse wrote:
> Where's the ECC when we're using the SmartMedia format on them?
The layout for SmartMedia DOS for 256 byte pagesize:
Even page:
Byte 0-3 reserved area
Byte 4 data status flag
Byte 5 block status flag (bad block marker)
Byte 6-7 block adress 1
Odd page:
Byte 0-2 ECC Area-2 (odd page)
Byte 3-4 Block Address 2
Byte 5-7 ECC Area-1 (even page)
The layout for SmartMedia DOS for 512 byte pagesize:
Byte 0-3 Reserved Area
Byte 4 Data Status Flag
Byte 5 block status flag (bad block marker)
Byte 6-7 Block Address-1
Byte 8-10 ECC Area-2 (byte 256-511)
Byte 11-12 Block Address 2
Byte 13-15 ECC Area-1 (byte 0-255)
They build a virtual blocksize of 512 byte on the small devices. I thought
about doing the same, but IMHO it's not a good idea.
> Either way, you mustn't ever erase a block which is marked bad, right?
The datasheet says it's not allowed to do this, due to the fact, that you
loose bad block information and maybe you can't write the bad block info
again. So you would run always into this bad block after restart.
Sorry, as you see above, i had some trouble to count. The bad block status on
SmartMedia is not at Byte 6 it's at Byte 5. We want to keep it there, so we
have to split the ECC data on 512 byte devices.
SmartMedia and raw NAND 512 byte pagesize
Byte 0-3 ECC part 1
Byte 4 page data valid flag
Byte 5 bad block status
Byte 6-7 ECC part 2
Byte 8-15 cleanmarker
SmartMedia and raw NAND 256 Byte pagesize
Byte 0-2 ECC
Byte 3-4 cleanmarker
Byte 5 bad block status
Byte 6 page data valid flag
Byte 7 spare
Please let me know, if we can fix this layout. Then i would implement and
test it.
> Cool. Does this leave some files on the fs and make lots of GC happen, and
> check the contents of all files on restart? Vipin's tests did this quite
> well, IIRC.
I have some files untouched on the fs. I check them with diff after reboot.
There was no failure.
> Now I suppose we need to look at using write_super and sb->s_dirt the way
> that God intended, for flushing pending writes in the wbuf rather than
> just triggering erases.
What do you mean exactly and what about the cleanup, when we fail during
flush_wbuf ?
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: gleixner@autronix.de, http://www.autronix.de
next reply other threads:[~2002-02-11 15:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-11 15:32 Thomas Gleixner [this message]
2002-02-11 15:48 ` NAND flash and JFFS(2) Thomas Gleixner
2002-02-11 19:28 ` Thomas Gleixner
-- strict thread matches above, loose matches on Subject: below --
2002-02-13 20:03 Lance Nakamura
2002-02-13 20:19 ` Thomas Gleixner
2002-02-11 23:42 Steve_Chen
2002-02-12 0:10 ` Thomas Gleixner
[not found] <02020523405103.11497@thomas>
2002-02-06 4:54 ` David Woodhouse
2002-02-06 22:47 ` Thomas Gleixner
2002-02-06 22:55 ` David Woodhouse
2002-02-07 6:51 ` Thomas Gleixner
2002-02-07 7:04 ` David Woodhouse
2002-02-11 13:42 ` Thomas Gleixner
2002-02-11 13:53 ` David Woodhouse
[not found] ` <0202121847440K.00764@thomas>
2002-02-13 11:40 ` Thomas Gleixner
2002-02-05 14:41 Veli-Pekka Ylönen
2002-02-05 15:30 ` David Woodhouse
2002-02-05 17:28 ` Thomas Gleixner
2002-02-05 21:18 ` David Woodhouse
2002-02-05 17:35 ` Veli-Pekka Ylönen
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=02021116320106.00764@thomas \
--to=gleixner@autronix.de \
--cc=jffs-dev@axis.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