[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Woodruff, Richard]

Hello,

The following path fixes a few bugs in cmd_nand.c :
  - Fixed null dereference which could result in incorrect ECC values.
  - Added support for devices with no Ready/Busy signal connected.
  - Added OMAP1510 read/write protect handling.
  - Fixed nand.h's ECCPOS. A conflict existed with POS5 and badblock for
non-JFFS2.
  - Switched default ECC to be JFFS2.
  - Added spinning wheel.
--------------------
Prior to this only ECC for JFFS2 would have worked, and that only if you had
memory at zero which you didn't mind being corrupted. The other method would
result in a corrupted bad block byte in the oob data.

Regards,

Richard W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand_fix.diff
Type: application/octet-stream
Size: 10814 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030724/5d70094f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand_fix.changelog
Type: application/octet-stream
Size: 396 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030724/5d70094f/attachment-0001.obj 

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Wolfgang Denk]

Dear Richard,

in message <FD2AC9A020DDD51194710008C7089B200BEE2218@dlee17.itg.ti.com> you wrote:
> 
> The following path fixes a few bugs in cmd_nand.c :
>   - Fixed null dereference which could result in incorrect ECC values.
>   - Added support for devices with no Ready/Busy signal connected.
>   - Added OMAP1510 read/write protect handling.
>   - Fixed nand.h's ECCPOS. A conflict existed with POS5 and badblock for
> non-JFFS2.
>   - Switched default ECC to be JFFS2.

Added so far.

Will push to CVS soon.

>   - Added spinning wheel.

Skipped / rejected.


May I please ask you to adhere to the guidlines for coding style?

Please do not add trailing white space, especially  not  to  existing
code.
Please stick with 8 char indentation.


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
The man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Wolfgang Denk]

In message <20030727175341.GI28983@pengutronix.de> you wrote:
>
> > My $ 0.02: forget about it. It's not worth any effort.
> 
> Shouldn't unix design philosophy be "if there is a user who needs it
> don't forbid it per design but make it configurable per policy"...? 

Sure. You understand the meaning of "my $ 0.02" ?


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
While most peoples' opinions change, the conviction of their correct-
ness never does.

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Robert Schwebel]

On Sun, Jul 27, 2003 at 07:37:28PM +0200, Wolfgang Denk wrote:
> In message <FD2AC9A020DDD51194710008C7089B200BEE2226@dlee17.itg.ti.com> you wrote:
> > Yes placement could be improved.  However, it is done on a per block basis,
> > not byte, so the overhead isn't that noticeable.  Spinning a wheel every 16k
> > should not be that bad. (Its currently spinning at the page size instead of
> > the block, but that could be easily changed).
> 
> My $ 0.02: forget about it. It's not worth any effort.

Shouldn't unix design philosophy be "if there is a user who needs it
don't forbid it per design but make it configurable per policy"...? 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Wolfgang Denk]

In message <FD2AC9A020DDD51194710008C7089B200BEE2226@dlee17.itg.ti.com> you wrote:
> Yes placement could be improved.  However, it is done on a per block basis,
> not byte, so the overhead isn't that noticeable.  Spinning a wheel every 16k
> should not be that bad. (Its currently spinning at the page size instead of
> the block, but that could be easily changed).

My $ 0.02: forget about it. It's not worth any effort.


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
If I had to live my life again,  I'd  make  the  same  mistakes, only
sooner.                                          -- Tallulah Bankhead

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Woodruff, Richard]

Yes placement could be improved.  However, it is done on a per block basis,
not byte, so the overhead isn't that noticeable.  Spinning a wheel every 16k
should not be that bad. (Its currently spinning at the page size instead of
the block, but that could be easily changed).

Regards,

Richard W.

-----Original Message-----
From: Wolfgang Denk [mailto:wd at denx.de] 
Sent: Sunday, July 27, 2003 8:39 AM
To: Woodruff, Richard
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] PATCH : Fixes and enhancements for NAND flash. 

Dear Richard,

in message <FD2AC9A020DDD51194710008C7089B200BEE2224@dlee17.itg.ti.com> you
wrote:
> 
> I do like the spinning wheel.  Is there any standard way to add a progress
> indicator into this or any code with significant delay?  Any of the users
of

Use common sense. The only thing it does is making a part of the code
which takes more time than you like eveln  slower:  I'm  not  talking
about  the few CPU cycles for the printf (putc() would have been much
simpler), but especially about trashing the cache for "pretty" things
that don't add value, and the time it takes to output this stuff on a
slow serial line.

> the code I've talked with like such a feature.  It seems that same bit of
> code has been replicated in a few places. Surly having a library call and
> some ifdef's would be acceptable.

No, not at this place. It's a different story when -  for  example  -
waiting  for a flash sector be return to ready state when erasing it.
Here you have to wait anyway, so feel free  to  implement  this  busy
wait as you like it.

> As far a code formatting, I'll see if I can't fix it up.  I find myself
> using several editors depending on the context of what I'm doing.  I've
not
> mastered any of them... When I do the diff -purN for the patch, I
generally
> don't notice differences except in the areas I have changed something.
What
> code reformatter/filter do you use?  Some of the more recent u-boot
releases
> have had a lot of style changes to the point I would suspect you ran
> something over the code.

vi and indent (indent -kr -i8 -bad -bap -nbc -br -c33 -cd33 -ncdb -ce
-ci8 -cli0 -cp33 -d0 -di1 -nfc1 -nfca -i4 -ip0 -l75  -lp  -pcs  -npsl
-nsc -nsob -nss -ts4, to be precise).


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
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Wolfgang Denk]

Dear Richard,

in message <FD2AC9A020DDD51194710008C7089B200BEE2224@dlee17.itg.ti.com> you wrote:
> 
> I do like the spinning wheel.  Is there any standard way to add a progress
> indicator into this or any code with significant delay?  Any of the users of

Use common sense. The only thing it does is making a part of the code
which takes more time than you like eveln  slower:  I'm  not  talking
about  the few CPU cycles for the printf (putc() would have been much
simpler), but especially about trashing the cache for "pretty" things
that don't add value, and the time it takes to output this stuff on a
slow serial line.

> the code I've talked with like such a feature.  It seems that same bit of
> code has been replicated in a few places. Surly having a library call and
> some ifdef's would be acceptable.

No, not at this place. It's a different story when -  for  example  -
waiting  for a flash sector be return to ready state when erasing it.
Here you have to wait anyway, so feel free  to  implement  this  busy
wait as you like it.

> As far a code formatting, I'll see if I can't fix it up.  I find myself
> using several editors depending on the context of what I'm doing.  I've not
> mastered any of them... When I do the diff -purN for the patch, I generally
> don't notice differences except in the areas I have changed something.  What
> code reformatter/filter do you use?  Some of the more recent u-boot releases
> have had a lot of style changes to the point I would suspect you ran
> something over the code.

vi and indent (indent -kr -i8 -bad -bap -nbc -br -c33 -cd33 -ncdb -ce
-ci8 -cli0 -cp33 -d0 -di1 -nfc1 -nfca -i4 -ip0 -l75  -lp  -pcs  -npsl
-nsc -nsob -nss -ts4, to be precise).


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
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

[U-Boot-Users] PATCH : Fixes and enhancements for NAND flash.

[Woodruff, Richard]

Wolfgang,

I do like the spinning wheel.  Is there any standard way to add a progress
indicator into this or any code with significant delay?  Any of the users of
the code I've talked with like such a feature.  It seems that same bit of
code has been replicated in a few places. Surly having a library call and
some ifdef's would be acceptable.

As far a code formatting, I'll see if I can't fix it up.  I find myself
using several editors depending on the context of what I'm doing.  I've not
mastered any of them... When I do the diff -purN for the patch, I generally
don't notice differences except in the areas I have changed something.  What
code reformatter/filter do you use?  Some of the more recent u-boot releases
have had a lot of style changes to the point I would suspect you ran
something over the code.

Regards,

Richard W.


in message <FD2AC9A020DDD51194710008C7089B200BEE2218@dlee17.itg.ti.com> you
wrote:
> 
> The following path fixes a few bugs in cmd_nand.c :
>   - Fixed null dereference which could result in incorrect ECC values.
>   - Added support for devices with no Ready/Busy signal connected.
>   - Added OMAP1510 read/write protect handling.
>   - Fixed nand.h's ECCPOS. A conflict existed with POS5 and badblock for
> non-JFFS2.
>   - Switched default ECC to be JFFS2.

Added so far.

Will push to CVS soon.

>   - Added spinning wheel.

Skipped / rejected.


May I please ask you to adhere to the guidlines for coding style?

Please do not add trailing white space, especially  not  to  existing
code.
Please stick with 8 char indentation.


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
The man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.