openocd-development-boun...@lists.berlios.de wrote: > I was asking the ODM to > ensure that no more than 2 bad blocks occur in any 4M range > of the flash as a requirement.
You have a pretty good chance of hitting that ime. > Anyone have any place to get something official about bad > block density? I suspect that in practice, 2 BB in 4M is > reasonable and unlikely to cause issues, but without > empirical documentation, I can't make a requirement. with 2KB page 512MB NAND flash if I remember rightly quite a few of the chips we buy in would fail your 4M requirement. More than 1-2% I think. My statistics are not hot enough to give you the formula, but 512M into 4M buckets is 128 buckets, assuming 128KB blocks is 4096 blocks, let's say 1% are bad is around 41, ideally randomly distributed - this gives a very high probability that two will be in the same bucket. Not sure the probability for 3, but I think it is also high. Also I think (fuzzy memory, sorry) that bad blocks tend to appear close together more often than even random distribution would suggest. > In a > 512M NAND flash, setting aside +40M in sloppy partitioning seems very > wasteful. > > Thoughts/Comments? That is what UBI is for if I understand it correctly. It manages internal virtual partitions where the actual wear levelling and bad block tolerance takes place across the whole physical NAND shared by the UBI partitions. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
