Re: [Etherboot-discuss] DEBUG=relocate output

[Michael B. <mb...@fe...>]

On Thu, 31 Aug 2006, Michael Brown wrote:
>> I also tried making the memory start at 0x80000000, and the same thing
>> occurs. When the region is zero bytes long it just dies.
>
> <snip>
>
> Will do.  I suspect that the problem might be the code that's designed 
> to strip out empty e820 regions created as a result of our map mangling. 
> I found that Windows expects only a single region in base memory; if you 
> return two regions (one being empty) either side of Etherboot then it 
> gets really confused.  I therefore added code specifically to skip any 
> empty regions created by us, but it's possible that it's getting 
> confused by the "real" empty region and screwing up some internal state.

I think I've found it.  The "strip empty region" logic works as follows:

   do {
      generate unstripped e820 map entry
   } while ( ! ( generated entry is empty ) )

i.e. if we see a zero-length entry, we iterate to the next entry in the 
map.  This fails utterly when the zero-length entry is at the end of the 
map, since it will then iterate back round to the beginning, resulting in 
a map containing duplicate entries (and limited in number of entries only 
by the caller's patience).

I've checked in a small patch which I think fixes this issue.  I've tested 
that it correctly returns a finite modified e820 map when using your 
modified BIOS with a zero-length entry at 0x8000000.

Can you update arch/i386/firmware/pcbios/e820mangler.S and re-test?

Thanks,

Michael