On Wed, Mar 19, 2008 at 09:33:22PM +0000, Andy Green wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > > 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. > > Well that will be simpler. > > > For basic sequential read/write operations, we can skip over bad > > blocks easily enough. > > OK. > > > 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) > > Hum. Since we can't parse ext2 at the moment we will need at least > these partitions if I understood the intention for NAND > > - bootloader > - kernel commandline string > - backup kernel > - backup rootfs > > and additionally if we accept to use NAND for the main rootfs > > - main kernel > - main rootfs (biggest) > > Burning a few MB of 256MB in padding sounds OK. > > >> - 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. (*) > > I agree that if we define the bootloader as just a kernel loader, then > the only legitimate settings in there would be directly to do with how > to run the kernel. But isn't it a serious problem that we need a > different kernel image to run from SD (root=mmcblk<n>p<m>...) in that > case than from NAND? And then the kernels will only function when > coming from a specific partition index on their specific media?
In the worse case, we keep u-boot for development purposes, but devices will ship with a minimal bootloader. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com
