2011-03-09 14:06:28     bf524, NAND boot, and bad blocks

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2011-03-09 14:06:28     bf524, NAND boot, and bad blocks

Reggy Perrin (UNITED STATES)

Message: 98778   

 

Hi folks,

 

We would appreciate some feedback about the best practices for handling NAND bad blocks in a NAND-only solution.  However, the wiki doesn't really detail how to manage bad blocks at the non-file system level (u-boot, kernel, etc).  We'd appreciate some feedback about specific items that should be implemented for a robust, NAND-only environment.

 

Here's our environment:

 

    BF524

    128MB NAND flash (SLC)

    kernel and root file system are separate

    We update the kernel remotely, so we have a 2nd kernel/root file system partition.  The update writes to that 2nd partition and changes the u-boot parameters to reflect the new upgrade

 

Here's out specific questions:

 

    Can the BF52x family support future 4-bit ECC chips that are starting to be released?  From googling, there appears to be some support brewing in u-boot and mtd drivers, but not sure that is baked yet.

    What overage would you recommend for areas to allow for future bad blocks?  For instance, we need 2 u-boot environment areas, and main environment and a redundant environment.  If that environment size is 1 block, then that block going bad would stop future kernel remote updates.  Right now, we have each environment range set to 4 blocks, to allow for 3 blocks to go bad in the future.  Additionally, we need to determine how many spare blocks to provide for the kernel, to allow for future bad blocks to develop there as well.  Are there any recommendations?

    We are using the nandwrite/nanddump/flash_eraseall commands in the root file system to program the new files that have been transmitted.  It appears that nandwrite handles bad blocks correctly.  Any items we need to consider beyond using nandwrite?

 

Thanks!

 

RP

QuoteReplyEditDelete

 

 

2011-03-09 14:39:04     Re: bf524, NAND boot, and bad blocks

Mike Frysinger (UNITED STATES)

Message: 98783   

 

there isnt much documentation on handling bad blocks yourself because you generally shouldnt be.  if you dont want to run a full fs like jffs2 or yaffs, then that's fine.  but you can still use UBI which provides bad block handling as well as wear leveling for you.

  www.linux-mtd.infradead.org/doc/ubi.html

 

the Blackfin NFC hardware does not care about ECC that the chip provides.  it takes care of calculating the ECC itself in hardware.  but obviously we cant something will or wont work since we've never tested it.

QuoteReplyEditDelete

 

 

2011-03-09 15:17:40     Re: bf524, NAND boot, and bad blocks

Reggy Perrin (UNITED STATES)

Message: 98792   

 

Thanks, Mike

 

I realize the root file system is already handled, and I'm letting JFFS deal with it.

 

My bigger question is regarding u-boot and the kernel.  I believe I just need to give 2+ blocks to u-boot for each environment for safety, and increase our kernel partition size to allow for future bad blocks.  Would you agree this is the right method?

 

Regarding the newer NAND chips, they appear to have a more complex ECC system (4-bits vs. 1-bit currently).  My question is about the BF52x hardware:  Is the NAND interface compatible with newer NAND chips coming on the market, or is there an upcoming issue with future chips?  I've found some u-boot traffic of people starting to ask these questions, and you can see that it is very new (January of this year).  Linux mtd subsystem emails such as this one from this year also apply.  Any development ongoing with this?

 

Thanks

 

RP

QuoteReplyEditDelete

 

 

2011-03-09 15:23:08     Re: bf524, NAND boot, and bad blocks

Mike Frysinger (UNITED STATES)

Message: 98793   

 

for u-boot, people tend to use the redundant environment.  as for bad blocks, i dont really know how that is handled ... i'd have to read the documentation and/or source.

 

for the kernel, since you would be using the read/write funcs that take care of bad blocks, the smart move would be to reserve some space for it.  then again, this seems like this is what UBI is for and UBI support is in u-boot already ...

 

wrt hardware questions, those are better posted at ez.analog.com

 

wrt software development, no one on our side is looking or even thinking about these.  the vast work on common mtd code happens in upstream projects and not with SoC providers like ADI.

QuoteReplyEditDelete

 

 

2011-03-09 15:49:48     Re: bf524, NAND boot, and bad blocks

Reggy Perrin (UNITED STATES)

Message: 98794   

 

Perfect, thanks Mike

QuoteReplyEditDelete

Attachments

    Outcomes