dynamically generate strides in fmap_find() to cover all of ROM

dynamically generate strides in fmap_find() to cover all of ROM

This changes the hard coded array of strides to cover with an algorithm that
will result in every bit of the ROM being checked.  Now the algorithm starts
at 1/2 the ROM's total size and divides its stride by 2 on each iteration.

BUG=
TEST=Tested on Alex with an FMAP structure at various alignments (2M, 1M, 64K, 4K, 16, 5, 1).

[Stefan Reinauer, 2011-03-09 23:21:38]

LGTM

[Louis, 2011-03-11 05:43:32]

Can we remove brute force loop?  This loop increases 6 secs when reading EC
flash.

[Stefan Reinauer, 2011-03-11 06:26:45]

On 2011/03/11 05:43:32, Louis wrote:
> Can we remove brute force loop?  This loop increases 6 secs when reading EC
> flash.

Only when there is no fmap. Will this be the case for us?

[david.hendricks, 2011-03-11 08:00:49]

On 2011/03/11 06:26:45, Stefan Reinauer wrote:
> On 2011/03/11 05:43:32, Louis wrote:
> > Can we remove brute force loop?  This loop increases 6 secs when reading EC
> > flash.
> 
> Only when there is no fmap. Will this be the case for us?

[dhendrix, 2011-03-11 08:03:40]

On 2011/03/11 08:00:49, david.hendricks wrote:
> On 2011/03/11 06:26:45, Stefan Reinauer wrote:
> > On 2011/03/11 05:43:32, Louis wrote:
> > > Can we remove brute force loop?  This loop increases 6 secs when reading
EC
> > > flash.
> > 
> > Only when there is no fmap. Will this be the case for us?

I don't think Louis' reply went thru... the answer is "yes" for older firmwares.

I'll try to fix the issue tomorrow and have it so the brute force method works
to fill the "oldcontents" buffer in doit(). That will eliminate the penalty and
give us the benefit.