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: awater...@dawning.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
