[U-Boot-Users] cmd_nand.c :: check_block, wrong bad block pos ?

[Woodruff, Richard]

Hello,

Well I just got nand and ECC to work on my little endian ARM board.  By
using the following corrected round nand_rw zero deferences were stopped:
	noecc = (start != ROUND_DOWN(start, 0x200)) || (len < 0x200) ;

And, I'm not quite sure what why, perhaps endianess, the read_oob in check
block was returning byte 6 from the oob instead of 5.  By changing it to ask
for (badpos + 1) it started returning the correct byte.  I'll need to check
into this one a bit more.  Does anyone know why badpos by itself is not
enough?

After I test a little I can post a patch back for others to test against.

Regards,

Richard W.




-----Original Message-----
From: Woodruff, Richard 
Sent: Wednesday, July 23, 2003 6:23 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

.. 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


-------------------------------------------------------
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