[U-Boot-Users] [PATCH, resend] Support dynamic/patched NAND ENV offset

[Harald Welte]

On Mon, Jul 07, 2008 at 01:47:24PM -0500, Scott Wood wrote:
> On Mon, Jul 07, 2008 at 12:28:12AM +0800, Harald Welte wrote:
> > I've first sent this on Feb 17, 2007.  Unfortunately no reply was
> > received.  I think this is a quite useful feature, since a compile time
> > offset into the NAND flash for the environment just doesn't work well
> > with bad blocks ;)
> 
> It works if you allow room for bad blocks within each partition, and treat
> the environment as its own partition.  Current u-boot supports skipping bad
> blocks within a desginated environment region.

which wastes a lot of space, if you have something like a 128kByte
erase-block-size (like most 2kByte page size NAND's today)... so if you
want to have redundancy and use some spare blocks you will end up with
something on the order of 512kByte of wasted flash space to store a
couple of hundreds of bytes environment.  Not very elegant.

Furthermore, if you want to make sure it always works with any of your
components that are within the spec of the manufacturer, then you will
waste even more.  The problem is that a new virgin component e.g. a
64MByte flash from Samsung  can have already as many as 1.3MBytes of bad
blocks.  There is no guarantee that they are all within one of your
partitions.  So to only cope with factory bad blocks, you would have to
have 1.3MBytes of spare space in each of your partitions!  Don't you
think that's a bit too much waste of space?  (you can read the full
rationale at http://wiki.openmoko.org/wiki/NAND_bad_blocks)

So I'd say that having the address of the environment block stored in
the out-of-band area of the first block (which is always guaranteed to
be good by the manufacturer) sounds like a much more elegant solution.

Therefore, I still believe that such a feature is useful and should be
merged into u-boot.  If there are problems with my particular
implementation, I'm happy to address them.

I also have another patchset for what I call 'dynpart' support, i.e. the
dynamic calculation of a unit-specific partition table that ensures the
net size of partitions are as per spec, no matter how many of the
factory default blocks are located where.  So it would even support
NAND devices with a worse spec than the ones that we were using.

Cheers,
-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone