[U-Boot] RFC: porting u-boot to sequoia based nand booting board

[Alex Waterman <awaterman@dawning.com>]

Scott,

> Nothing in nand_base.c is used by SPL.  SPL has its own code for this,
> which currently just does a readb() (broken on 16-bit?).

Oh you were talking about the bad block function in nand_base.c... That 
makes more sense now :). And yeah, I suppose the spl bad block check is
broken. If it does not check the full 16 bits of data then some bad blocks
may be incorrectly read as good.

> It's not really our choice, it's what the manufacturer uses (unless you
> want to get into rewriting the markers before first use...).  The one
> chip datasheet I looked at claimed the bad block marker was any value other
> than 0xffff on 16-bit, so checking just one of the bytes would be wrong.

My NAND data sheet says that the bad block mark is 0x000 for x16. However
it says a little before that one should check for any non 0xffff value in the
bad block marker. So it would seem that 16 bit devices should do a 16 bit
check but under normal conditions an 8bit check would probably work... 

I looked at the nand_block_bad() function in nand_base.c and it does the
same cpu_to_le16() stuff that nand_read_byte16() does. I wonder if there is
something to that? It seems to me that if its doing an 8 bit check for
0x0000 or 0xffff then it doesn't matter the endianness at all. Maybe that
code is trying to make up for other code incorrectly writing only a single
byte for the bad block marker?

Regards,
Alex

-- 
Alex Waterman
Computer Engineer
Phone: 215-896-4920
Email: awaterman at dawning.com