[U-Boot-Users] [RFC] NAND Flash

[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

Hello there.

As you remember earlier I have sent a small patch for the NAND
portion of u-boot.

This forced me to really take a hard look at the code and really
evaluate it.

The big problem with the code as it is its its tendancy not to
account properly for errors which are not only probable but
certain during the life of the device.

For example the current code cannot boot reliably from NAND
and the read and write routines are also unreliable.

It's basic assumption made that you can read/write from the NAND
at any position is false. This is impossible because of
the bad blocks that may force you to skip a bad sector.

I'm currently in the process of rewritting to actually make it
work reliably.

I can keep backwards compatibility with the old code but
you can only use it at your own risk.

I'm asking for any people currently working with NAND to comment
on the following points:

1. Do you read and write the NAND at arbitrary offsets?
   That means not in page boundaries.

2. Do you use the NAND boot command? It can be replaced by a copy and
   bootm sequence.

3. Do you use it as a raw device without employing ECC? Do you
   understand the implications?

4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
   placement of ECC and status bits?

5. What kind of bad block management options would you like? I'm thinking
   of implementing a bad block detection mechanism which would erase and
   test the whole chip for any bad blocks.
   Another command could also utilise ECC to detect borderline working
   pages and relocate them to avoid a permanent failure.

Awaiting your input...

Regards

Pantelis

[U-Boot-Users] [RFC] NAND Flash

[Peter Billek]

We are in the progress of starting to implement u-boot and will need NAND support as well.

As it looks at the moment we will access the NAND flash not in page boundaries, but rather with arbitrary offsets. 
At the moment we are using something similar to the boot command with is still a adaptation from former armboot.
We don't use ECC and also no FS, rather fixed addresses. However this has to change in the future, but for the moment we are just prototyping.
AS or the bad block cheeking, I would rather go for the relocation implementation rather than the erasing the complete chip.

I am looking forward to see how your work progresses and might commit to it in the future as well if I can.

greetings
Peter Billek
Board Level Design, Realtime SW
Local Design Center VIE
Ericsson Enterprise GmbH
mailto:peter.billek at ericsson.com

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Pantelis
Antoniou
Sent: Dienstag, 27. April 2004 09:08
To: Wolfgang Denk; U-Boot Users
Subject: [U-Boot-Users] [RFC] NAND Flash


Hello there.

As you remember earlier I have sent a small patch for the NAND
portion of u-boot.

This forced me to really take a hard look at the code and really
evaluate it.

The big problem with the code as it is its its tendancy not to
account properly for errors which are not only probable but
certain during the life of the device.

For example the current code cannot boot reliably from NAND
and the read and write routines are also unreliable.

It's basic assumption made that you can read/write from the NAND
at any position is false. This is impossible because of
the bad blocks that may force you to skip a bad sector.

I'm currently in the process of rewritting to actually make it
work reliably.

I can keep backwards compatibility with the old code but
you can only use it at your own risk.

I'm asking for any people currently working with NAND to comment
on the following points:

1. Do you read and write the NAND at arbitrary offsets?
   That means not in page boundaries.

2. Do you use the NAND boot command? It can be replaced by a copy and
   bootm sequence.

3. Do you use it as a raw device without employing ECC? Do you
   understand the implications?

4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
   placement of ECC and status bits?

5. What kind of bad block management options would you like? I'm thinking
   of implementing a bad block detection mechanism which would erase and
   test the whole chip for any bad blocks.
   Another command could also utilise ECC to detect borderline working
   pages and relocate them to avoid a permanent failure.

Awaiting your input...

Regards

Pantelis




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

Peter Billek (VI/SEA) wrote:

>We are in the progress of starting to implement u-boot and will need NAND support as well.
>
>As it looks at the moment we will access the NAND flash not in page boundaries, but rather with arbitrary offsets. 
>At the moment we are using something similar to the boot command with is still a adaptation from former armboot.
>We don't use ECC and also no FS, rather fixed addresses. However this has to change in the future, but for the moment we are just prototyping.
>
I hope you don't solder your chips on the board, cause bad blocks can be 
present in pristine chips fresh from the factory.
This will NOT work, since a bad block anywhere in the range that you use 
means that you must replace the chip.

>AS or the bad block cheeking, I would rather go for the relocation implementation rather than the erasing the complete chip.
>
>
Me too, but it's kinda tricky...

>I am looking forward to see how your work progresses and might commit to it in the future as well if I can.
>
>
Looking forward to it too.

>greetings
>Peter Billek
>Board Level Design, Realtime SW
>Local Design Center VIE
>Ericsson Enterprise GmbH
>mailto:peter.billek at ericsson.com
>
>
Regards

Pantelis

[U-Boot-Users] [RFC] NAND Flash

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Pantelis
> Antoniou
> Sent: Tuesday, April 27, 2004 3:45 AM
> To: Peter Billek (VI/SEA)
> Cc: U-Boot Users
> Subject: Re: [U-Boot-Users] [RFC] NAND Flash
>
>
> Peter Billek (VI/SEA) wrote:
>
> >We are in the progress of starting to implement u-boot and
> will need NAND support as well.

[snip]

> >AS or the bad block cheeking, I would rather go for the
> relocation implementation rather than the erasing the complete chip.
> >
> >
> Me too, but it's kinda tricky...

The Toshiba NAND flash we use comes from the factory with the bad blocks already marked (they may grow more bad blocks, but the initial ones are identified during manufacturing testing).  If you erase the chip without saving the information first, you lose that valuable information.  You should check with your supplier to see how they handle it.

gvb




******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] [RFC] NAND Flash

[Woodruff, Richard]

Hello Pantelis,

I recently used that code a quite a bit...I probably have a few changes
which I probably should have sent back in...there were some problems
with some operations to the oob, and one bit about bad blocks which we
enhanced.  I'll send you version of the code for you to compare against
later.

> I'm asking for any people currently working with NAND to comment
> on the following points:
> 
> 1. Do you read and write the NAND at arbitrary offsets?
>    That means not in page boundaries.

No not usually.  We generally only used it for catastrophic recovery. In
that case we would write a file system image out.  Because it is fairly
slow, I usually had a separate kernel partition.  The board I used to
use had a NOR u-boot.  At reset with would jffs2 scan the first
partition and recover the kernel (which had mtd+nand) built in.  It
would load and start this kernel.  This kernel mounted a read only root
system partition in NAND, and a r/w user partition.  Updates were
expected to happen at the kernel level...if they failed badly, you could
send an Image to u-boot which could then re-burn the entire partitions.

In newer processors which TI is doing, we actually can drop the NOR all
together.  The processor's have hardware acceleration and enough
microcode in mask rom to boot from a single external NAND.  U-boot will
be supported in these systems.

> 2. Do you use the NAND boot command? It can be replaced by a copy and
>    bootm sequence.

Only for development.  It's a bit more quick to burn in a raw image, but
also not very safe.   I think some manufactures may guarantee that some
number of the first blocks are good.  If you don't write them very much
you are probably pretty safe.
 
> 3. Do you use it as a raw device without employing ECC? Do you
>    understand the implications?
Raw only for development.

> 
> 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
>    placement of ECC and status bits?
We used JFFS2 and NAND.  Actually, we paid Woodhouse to get JFFS2+NAND
support up to par.  Current snapshots on his CVS seem pretty safe.
 
> 5. What kind of bad block management options would you like? I'm
thinking
>    of implementing a bad block detection mechanism which would erase
and
>    test the whole chip for any bad blocks.
>    Another command could also utilise ECC to detect borderline working
>    pages and relocate them to avoid a permanent failure.
> 
> Awaiting your input...
> 
> Regards
> 
> Pantelis
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

Woodruff, Richard wrote:

>Hello Pantelis,
>
>I recently used that code a quite a bit...I probably have a few changes
>which I probably should have sent back in...there were some problems
>with some operations to the oob, and one bit about bad blocks which we
>enhanced.  I'll send you version of the code for you to compare against
>later.
>
>
TIA.

>>I'm asking for any people currently working with NAND to comment
>>on the following points:
>>
>>1. Do you read and write the NAND at arbitrary offsets?
>>   That means not in page boundaries.
>>
>
>No not usually.  We generally only used it for catastrophic recovery. In
>that case we would write a file system image out.  Because it is fairly
>slow, I usually had a separate kernel partition.  The board I used to
>use had a NOR u-boot.  At reset with would jffs2 scan the first
>partition and recover the kernel (which had mtd+nand) built in.  It
>would load and start this kernel.  This kernel mounted a read only root
>system partition in NAND, and a r/w user partition.  Updates were
>expected to happen at the kernel level...if they failed badly, you could
>send an Image to u-boot which could then re-burn the entire partitions.
>
>
That sounds reasonably safe.

>In newer processors which TI is doing, we actually can drop the NOR all
>together.  The processor's have hardware acceleration and enough
>microcode in mask rom to boot from a single external NAND.  U-boot will
>be supported in these systems.
>
>
>>2. Do you use the NAND boot command? It can be replaced by a copy and
>>   bootm sequence.
>>
>
>Only for development.  It's a bit more quick to burn in a raw image, but
>also not very safe.   I think some manufactures may guarantee that some
>number of the first blocks are good.  If you don't write them very much
>you are probably pretty safe.
> 
>
>>3. Do you use it as a raw device without employing ECC? Do you
>>   understand the implications?
>>
>Raw only for development.
>
>
>>4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
>>   placement of ECC and status bits?
>>
>We used JFFS2 and NAND.  Actually, we paid Woodhouse to get JFFS2+NAND
>support up to par.  Current snapshots on his CVS seem pretty safe.
>
That was my main impetus. I updated from a recent CVS snapshot
and noticed the disrepancies. I'm thinking in putting the oob placement
in a environment variable, just to be able to follow the Linux MTD.

> 
>
>>5. What kind of bad block management options would you like? I'm
>>
>thinking
>
>>   of implementing a bad block detection mechanism which would erase
>>
>and
>
>>   test the whole chip for any bad blocks.
>>   Another command could also utilise ECC to detect borderline working
>>   pages and relocate them to avoid a permanent failure.
>>
>>Awaiting your input...
>>
>>Regards
>>
>>Pantelis
>>
>>
>>
>>
Regards

Pantelis

[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

Woodruff, Richard wrote:

>>I hope you don't solder your chips on the board, cause bad blocks can
>>
>be
>
>>present in pristine chips fresh from the factory.
>>This will NOT work, since a bad block anywhere in the range that you
>>
>use
>
>>means that you must replace the chip.
>>
>>
>
>Bad blocks can in practice be a bit harder to get then one might think.
>In say ... 500 different samples which passed my desk in the last three
>years none of them actually had bad blocks.  They could have of coarse.
>We simulated bad blocks.  It is a real problem.
>
I thought it was rare too until I got one chip with a bad block just the 
other
day.

It seems to vary with the lot.

>
>Regards,
>
>Richard W.
>
>
>
>
Regards

Pantelis

[U-Boot-Users] [RFC] NAND Flash

[Woodruff, Richard]

> I hope you don't solder your chips on the board, cause bad blocks can
be
> present in pristine chips fresh from the factory.
> This will NOT work, since a bad block anywhere in the range that you
use
> means that you must replace the chip.
> 

Bad blocks can in practice be a bit harder to get then one might think.
In say ... 500 different samples which passed my desk in the last three
years none of them actually had bad blocks.  They could have of coarse.
We simulated bad blocks.  It is a real problem.

Regards,

Richard W.

[U-Boot-Users] [RFC] NAND Flash

[Dave Ellis]

Pantelis Antoniou wrote:

> The big problem with the code as it is its its tendancy not to
> account properly for errors which are not only probable but
> certain during the life of the device.
> 
> For example the current code cannot boot reliably from NAND
> and the read and write routines are also unreliable.
>
> It's basic assumption made that you can read/write from the NAND
> at any position is false. This is impossible because of
> the bad blocks that may force you to skip a bad sector.

The nand boot looks broken to me. The .jffs2 commands work well
for me for booting from a jffs2 partition.
 
> I'm currently in the process of rewritting to actually make it
> work reliably.
> 
> I can keep backwards compatibility with the old code but
> you can only use it at your own risk.

It definitely could use a rewrite. It looks like it was ported from
a very old version of mtd. Please let's keep the .jffs2
options for jffs2, so we can add optimizations such as skipping
to the end of an empty erase block without breaking other uses.
 
> I'm asking for any people currently working with NAND to comment
> on the following points:
> 
> 1. Do you read and write the NAND at arbitrary offsets?
>    That means not in page boundaries.

No. I read an entire JFFS2 partition, or write a JFFS2 image, but
only on page boundaries.
 
> 2. Do you use the NAND boot command? It can be replaced by a copy and
>    bootm sequence.

No.

> 3. Do you use it as a raw device without employing ECC? Do you
>    understand the implications?

No, use ECC and JFFS2.

> 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
>    placement of ECC and status bits?

JFFS2

> 5. What kind of bad block management options would you like? I'm
thinking
>    of implementing a bad block detection mechanism which would erase
and
>    test the whole chip for any bad blocks.
>    Another command could also utilise ECC to detect borderline working
>    pages and relocate them to avoid a permanent failure.

If the factory or linux/jffs2/mtd have marked a block bad it shouldn't
be
erased. There is no reliable way to find them again without factory
tests,
and I think the manufacturers say that erasing a factory marked bad
block
can make the good blocks unreliable. I want jffs2 to handle any new bad
blocks.

Dave Ellis

~~~~~~~~~~~~~~~~~~~~~~~~~~
SIXNET - "Leading the Industrial Ethernet Revolution"
331 Ushers Road,   P.O. Box 767, Clifton Park, NY 12065 USA
Tel +1 (518) 877-5173   Fax +1 (518) 877-8346
Email me at: dge at sixnetio.com 
Detailed product info: www.sixnetio.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~

[U-Boot-Users] [RFC] NAND Flash

[Wolfgang Denk]

In message <408E554E.7080004@intracom.gr> you wrote:
> 
> That was my main impetus. I updated from a recent CVS snapshot
> and noticed the disrepancies. I'm thinking in putting the oob placement
> in a environment variable, just to be able to follow the Linux MTD.

Please remember what environment variables  are  intended  for.  This
seems not to be the case here. YMMV.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I thought my people would grow tired of killing. But you were  right,
they  see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
	-- Apella, "A Private Little War", stardate 4211.8

[U-Boot-Users] [RFC] NAND Flash

[Wolfgang Denk]

Dear Pantelis,

in message <408E06E4.2090308@intracom.gr> you wrote:
> 
> I'm currently in the process of rewritting to actually make it
> work reliably.
> 
> I can keep backwards compatibility with the old code but
> you can only use it at your own risk.
> 
> I'm asking for any people currently working with NAND to comment
> on the following points:
...

The last message about this topis is more than 6 weeks old. Was there
any agreement how to proceed?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten

[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

Wolfgang Denk wrote:

>Dear Pantelis,
>
>in message <408E06E4.2090308@intracom.gr> you wrote:
>
>>I'm currently in the process of rewritting to actually make it
>>work reliably.
>>
>>I can keep backwards compatibility with the old code but
>>you can only use it at your own risk.
>>
>>I'm asking for any people currently working with NAND to comment
>>on the following points:
>>
>...
>
>The last message about this topis is more than 6 weeks old. Was there
>any agreement how to proceed?
>
>Best regards,
>
>Wolfgang Denk
>
>
Hi Wolfgang.

Discussing with the MTD people they appear to be OK with this,
and only have some minor things they needed to be addressed.

Unfortunately the patch I last sent is kinda of bit-rotted and
have actually re-worked to properly work (and compile for
other boards :).

Will post updated patch based on latest cvs tree within the day.

Regards

Pantelis