[U-Boot-Users] ECC code used in cmd_nand.c

[U-Boot-Users] ECC code used in cmd_nand.c

[Woodruff, Richard]

.. Shouldn't the noecc check be doing a if(start != round_down(start,0x200))
and a check for less than size 0x200? This should ensure that the address is
at the proper boundary....does your board have sram/dram at 0.

rkw

> -----Original Message-----
> From: Woodruff, Richard 
> Sent: Wednesday, July 23, 2003 5:59 PM
> To: 'dge at sixnetio.com'
> Cc: u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] ECC code used in cmd_nand.c
> 
> 
> I'm thinking part of the problem I was having was my command 
> is bring up a
> bug:
> 	nand write 10008000 0 200
> 
> 	This will result in nand_rw calling nand_write_ecc with 
> an eccbuf = NULL, as the size and alignment check does not 
> work for the first block (noecc = (start!=start... ).  
> Nand_rw passes this to nand_write_ecc which passes it onto 
> nand_write page. Which then acts like its valid and starts 
> trying to read and write to address 0.  As I have ROM there 
> what ends up going into the oob is my rom's first instruction.
> 
> I've feeling a bit slow at the moment, and am wondering if 
> the rounding to see if we are starting on an aligned address 
> is even correct.
> 
> As far as R/B goes, I have two types of systems, one has it 
> and the other doesn't.  I've inserted code which seems to 
> allow things to work without a R/B connected...mainly using 
> the status read to wait till not busy followed by a read to 
> check for success or failure.  The only real pain with out 
> having a RB and doing this all with GPIOs is my ARM does not 
> have anything which allows the equivalent of a ppc "sync" 
> instruction, so dependencies on the memory controller's 
> scheduling creep up.
> 
> Regards/Thanks,
> 
> Richard W.
> 
> 
> 
> > -----Original Message-----
> > From: Dave Ellis [mailto:dge at sixnetio.com]
> > Sent: Wednesday, July 23, 2003 1:38 PM
> > To: Woodruff, Richard
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: RE: [U-Boot-Users] ECC code used in cmd_nand.c
> > 
> > 
> > Richard Woodruff wrote:
> > > Can anyone verify that the write using "nand write aaaa 
> offf ssss" 
> > > should work with ECC enabled?  I'm finding that if I 
> disable the ECC 
> > > generation I can write uImages and compare them and get what I 
> > > expect and boot from them.
> > 
> > It has been working fine for me using the SXNI855T
> > configuration. I built this morning's CVS version and it also 
> > seems OK.
> > 
> > > If I enable ECC generation, on read it complains that 
> they are all 
> > > wrong (but there is no errors on the write which I think 
> it should 
> > > give if the written ecc does not match the calculated one).  If I 
> > > disregard the ecc warnings and then "cmp" the data starting which 
> > > was loaded, the first 16k are indeed the same (16k is my block 
> > > size), however, there is some differences at the end of the first 
> > > block.  Again, if I disable ECC no such problem.
> > 
> > If you write if with ECC, but read it back without ECC is the
> > data still corrupted? The data may be OK until the bad ECC 
> > data is used to 'correct' it.
> > 
> > > ...If I do a read.oob of the first block, it appears that the 
> > > data_buf[0] is written to the first position of the oob, 
> instead of 
> > > the expected data.
> > 
> > Are you sure NanD_WaitReady() is working? If it isn't, you
> > could start to read the oob data before it is ready, and 
> > would see some old data from the start of the buffer.
> > 
> > Dave
> > 
> > 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 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > 
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
> including Data Reports, E-commerce, Portals, and Forums are 
> available now. Download today and enter to win an XBOX or 
> Visual Studio .NET. 
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
_072303_01/01
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] ECC code used in cmd_nand.c

[Dave Ellis]

> Richard Woodruff wrote: 
> .. Shouldn't the noecc check be doing a if(start !=
round_down(start,0x200))
> and a check for less than size 0x200? This should ensure that the
address is
> at the proper boundary....does your board have sram/dram at 0.

I think the noecc check is both unnecessary and broken (as originally
written it is _always_ true), so it should be removed. For a small read
the lower level routines read in and check the entire block, so noecc
is unnecessary. When writing, the decision is managed correctly by the
lower level routines, so again noecc is not needed.

I think the original programmer was trying to detect when the write
crossed the end of sector, so the ECC would be written when the
sector was complete, but it is so broken it is hard to tell.

Yes, I have ram at 0, which is why my system works, since the ecc_code
buffer ends up at 0x00000000 instead of eccbuf. I have now fixed it by
removing noecc completely.

> > -----Original Message-----
> > From: Woodruff, Richard 
> > Sent: Wednesday, July 23, 2003 5:59 PM
> > To: 'dge at sixnetio.com'
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: RE: [U-Boot-Users] ECC code used in cmd_nand.c
> > 
> > 
> > I'm thinking part of the problem I was having was my command 
> > is bring up a
> > bug:
> > 	nand write 10008000 0 200
> > 
> > 	This will result in nand_rw calling nand_write_ecc with 
> > an eccbuf = NULL, as the size and alignment check does not 
> > work for the first block (noecc = (start!=start... ).  
> > Nand_rw passes this to nand_write_ecc which passes it onto 
> > nand_write page. Which then acts like its valid and starts 
> > trying to read and write to address 0.  As I have ROM there 
> > what ends up going into the oob is my rom's first instruction.
> > 
> > I've feeling a bit slow at the moment, and am wondering if 
> > the rounding to see if we are starting on an aligned address 
> > is even correct.
> > 
> > As far as R/B goes, I have two types of systems, one has it 
> > and the other doesn't.  I've inserted code which seems to 
> > allow things to work without a R/B connected...mainly using 
> > the status read to wait till not busy followed by a read to 
> > check for success or failure.  The only real pain with out 
> > having a RB and doing this all with GPIOs is my ARM does not 
> > have anything which allows the equivalent of a ppc "sync" 
> > instruction, so dependencies on the memory controller's 
> > scheduling creep up.
> > 
> > Regards/Thanks,
> > 
> > Richard W.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Dave Ellis [mailto:dge at sixnetio.com]
> > > Sent: Wednesday, July 23, 2003 1:38 PM
> > > To: Woodruff, Richard
> > > Cc: u-boot-users at lists.sourceforge.net
> > > Subject: RE: [U-Boot-Users] ECC code used in cmd_nand.c
> > > 
> > > 
> > > Richard Woodruff wrote:
> > > > Can anyone verify that the write using "nand write aaaa offf
ssss" 
> > > > should work with ECC enabled?  I'm finding that if I disable the
ECC 
> > > > generation I can write uImages and compare them and get what I 
> > > > expect and boot from them.
> > > 
> > > It has been working fine for me using the SXNI855T
> > > configuration. I built this morning's CVS version and it also 
> > > seems OK.
> > > 
> > > > If I enable ECC generation, on read it complains that they are
all 
> > > > wrong (but there is no errors on the write which I think it
should 
> > > > give if the written ecc does not match the calculated one).  If
I 
> > > > disregard the ecc warnings and then "cmp" the data starting
which 
> > > > was loaded, the first 16k are indeed the same (16k is my block 
> > > > size), however, there is some differences at the end of the
first 
> > > > block.  Again, if I disable ECC no such problem.
> > > 
> > > If you write if with ECC, but read it back without ECC is the
> > > data still corrupted? The data may be OK until the bad ECC 
> > > data is used to 'correct' it.
> > > 
> > > > ...If I do a read.oob of the first block, it appears that the 
> > > > data_buf[0] is written to the first position of the oob, instead
of 
> > > > the expected data.
> > > 
> > > Are you sure NanD_WaitReady() is working? If it isn't, you
> > > could start to read the oob data before it is ready, and 
> > > would see some old data from the start of the buffer.

[U-Boot-Users] ECC code used in cmd_nand.c

[Woodruff, Richard]

I'm thinking part of the problem I was having was my command is bring up a
bug:
	nand write 10008000 0 200

	This will result in nand_rw calling nand_write_ecc with an eccbuf =
NULL, as the size and alignment check does not work for the first block
(noecc = (start!=start... ).  Nand_rw passes this to nand_write_ecc which
passes it onto nand_write page. Which then acts like its valid and starts
trying to read and write to address 0.  As I have ROM there what ends up
going into the oob is my rom's first instruction.

I've feeling a bit slow at the moment, and am wondering if the rounding to
see if we are starting on an aligned address is even correct.

As far as R/B goes, I have two types of systems, one has it and the other
doesn't.  I've inserted code which seems to allow things to work without a
R/B connected...mainly using the status read to wait till not busy followed
by a read to check for success or failure.  The only real pain with out
having a RB and doing this all with GPIOs is my ARM does not have anything
which allows the equivalent of a ppc "sync" instruction, so dependencies on
the memory controller's scheduling creep up.

Regards/Thanks,

Richard W.



> -----Original Message-----
> From: Dave Ellis [mailto:dge at sixnetio.com] 
> Sent: Wednesday, July 23, 2003 1:38 PM
> To: Woodruff, Richard
> Cc: u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] ECC code used in cmd_nand.c
> 
> 
> Richard Woodruff wrote:
> > Can anyone verify that the write using "nand write aaaa offf
> > ssss" should work with ECC enabled?  I'm finding that if I 
> > disable the ECC generation I can write uImages and compare 
> > them and get what I expect and boot from them.  
> 
> It has been working fine for me using the SXNI855T 
> configuration. I built this morning's CVS version and it also 
> seems OK.
> 
> > If I enable ECC generation, on read it complains that they
> > are all wrong (but there is no errors on the write which I 
> > think it should give if the written ecc does not match the 
> > calculated one).  If I disregard the ecc warnings and then 
> > "cmp" the data starting which was loaded, the first 16k are 
> > indeed the same (16k is my block size), however, there is 
> > some differences at the end of the first block.  Again, if I 
> > disable ECC no such problem.
> 
> If you write if with ECC, but read it back without ECC is the 
> data still corrupted? The data may be OK until the bad ECC 
> data is used to 'correct' it.
> 
> > ...If I do a read.oob of the first block, it appears that the
> > data_buf[0] is written to the first position of the oob, 
> > instead of the expected data.
> 
> Are you sure NanD_WaitReady() is working? If it isn't, you 
> could start to read the oob data before it is ready, and 
> would see some old data from the start of the buffer.
> 
> Dave
> 
> 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] ECC code used in cmd_nand.c

[Dave Ellis]

Richard Woodruff wrote:
> Can anyone verify that the write using "nand write aaaa offf 
> ssss" should work with ECC enabled?  I'm finding that if I 
> disable the ECC generation I can write uImages and compare 
> them and get what I expect and boot from them.  

It has been working fine for me using the SXNI855T configuration.
I built this morning's CVS version and it also seems OK.

> If I enable ECC generation, on read it complains that they 
> are all wrong (but there is no errors on the write which I 
> think it should give if the written ecc does not match the 
> calculated one).  If I disregard the ecc warnings and then 
> "cmp" the data starting which was loaded, the first 16k are 
> indeed the same (16k is my block size), however, there is 
> some differences at the end of the first block.  Again, if I 
> disable ECC no such problem.

If you write if with ECC, but read it back without ECC is the
data still corrupted? The data may be OK until the bad ECC
data is used to 'correct' it.

> ...If I do a read.oob of the first block, it appears that the 
> data_buf[0] is written to the first position of the oob, 
> instead of the expected data.

Are you sure NanD_WaitReady() is working? If it isn't, you could
start to read the oob data before it is ready, and would see
some old data from the start of the buffer.

Dave

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] ECC code used in cmd_nand.c

[Woodruff, Richard]

Hello,
 
Can anyone verify that the write using "nand write aaaa offf ssss" should
work with ECC enabled?  I'm finding that if I disable the ECC generation I
can write uImages and compare them and get what I expect and boot from them.

 
If I enable ECC generation, on read it complains that they are all wrong
(but there is no errors on the write which I think it should give if the
written ecc does not match the calculated one).  If I disregard the ecc
warnings and then "cmp" the data starting which was loaded, the first 16k
are indeed the same (16k is my block size), however, there is some
differences at the end of the first block.  Again, if I disable ECC no such
problem.
 
...If I do a read.oob of the first block, it appears that the data_buf[0] is
written to the first position of the oob, instead of the expected data.
 
Regards/Thanks for any info,
 
Richard W.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20030722/7882c023/attachment.htm