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