On Wed, Mar 19, 2008 at 05:17:53PM -0300, Werner Almesberger wrote: > Andy Green wrote: > > - If we have NAND back again, how are we going to manage the bad block > > stuff with this minimal bootloader? > > There are two things we need bad block information for: > > 1) Avoid storing data in bad blocks. > > 2) Make sure the partitions have enough good blocks. > > I think JFFS2 is fine with just the bad block information already > stored in NAND, i.e., it doesn't actually need the bad block table. > This needs verifying, also from a performance aspect. > > For basic sequential read/write operations, we can skip over bad > blocks easily enough. > > So issue 1) should be okay. > > For issue 2), I'd attack from two angles: a) reduce the number of > partitions and make them larger. b) don't try to have "exact" sizes > but just add some spare blocks (and use statistical assurances, see > below) > > b) consumes a certain number of blocks per partition, depending on > the number of bad blocks the NAND is supposed to have, the partition > size, distribution of bad blocks, and with which probability we want > to be able to fit our partitions onto a given NAND. > > If the number of partitions is very small (two sounds like a good > number to me, one for booting and one for the file system), then we > could just allocate the worst-case number of bad blocks per partition > and take no risk at all. > > Note that this is actually safer than the current supposedly exact > approach, since we can lose good blocks also during use, after > which our precisely fitted partition might be too small. > > There are other tricks one could use if partition boundaries can be > roughly predicted, such as marking partitions in OOB data, but I'd > rather stay away from becoming overly dependent on NAND-specific > features.
I'd put the kernel in some special blocks, but still only one partition and then you tell the bootloader to read those special blocks where we DO know the kernel resides. > > - What about an environment? > > Radical approach: hard-code anything that's environment (which would > be basically the boot parameter line - everything else is just the > partition table, internal u-boot housekeeping, or boot menu). Users > pick the kboot kernel if they want to pass their own parameters. (*) > > Slightly less radical approach: have a well-known location with a > block that's used as the boot parameter line. > > (*) Did we mention the "fastpath" yet ? The idea would be that the > boot loader can boot either the "real" kernel directly, which > would be the default, or the intermediate kernel which implements > the boot loader user interface and any more advanced features. > > > U-Boot env seems to be a place where bugs > > can come from in terms of the same devices acting different. > > Yeah, and that's mainly because the partition table lives there. > > What's nice is that, once you start to unravel the very complex > design we have now, it all falls into place in a much simpler way. > > - Werner > -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com
