From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Waterman Date: Wed, 18 May 2011 08:49:17 -0400 Subject: [U-Boot] RFC: porting u-boot to sequoia based nand booting board In-Reply-To: <20110517163207.08cc2ea6@schlenkerla.am.freescale.net> References: <4DD2717D.800@dawning.com> <201105171541.01662.sr@denx.de> <4DD28202.4050305@dawning.com> <20110517120523.23109215@schlenkerla.am.freescale.net> <4DD2B538.9040604@dawning.com> <20110517142052.7ed835f4@schlenkerla.am.freescale.net> <4DD2E586.5050708@dawning.com> <20110517163207.08cc2ea6@schlenkerla.am.freescale.net> Message-ID: <4DD3C04D.9070001@dawning.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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