Thanks for the details Jon. Based on this, I might change the partitions sizes a little. I do use UBI for the major partition, but the other partitions are read by u-boot (Kernel or R/O root filesystem in JFFS2). These smaller partitions have to have a set size with an explicit offset, but the question is what size is enough to account for bad blocks. From your comments, I might have to go to 4 bad blocks in 4M. The downside is that uboot, as provided from Marvell, is relatively particular at the use and management of the first 1M partition. I believe that it can not survive more than one bad block in that partition.
Robert P.S. Thanks for the source that can test distributions. On 1/25/11 12:43 AM, "Jon Povey" <[email protected]> wrote: > [email protected] 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. > -- Cisco 2200 E. Pres. George Bush Turnpike Richardson, TX 75082 [email protected] 972-813-1544 "Any sufficiently advanced technology is indistinguishable from magic" Arthur C. Clarke _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
