Bootloader

[Felipe Balbi]

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
me at felipebalbi.com
http://blog.felipebalbi.com