Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

On Thu, 29 Aug 2002, Michael Brown wrote:
> > > I think I'm seeing the same problem.  I'm getting total garbage in the
> > > E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> > > "fake" memory map used when the e820 calls fail, which gets it to the
> > > point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> > > locks up and requires a hard reset.
> > The symptoms are certainly the same.
> > > Ideas, toolchain test, etc. welcome.
> > Could you see if the E820 issue is new?
> > That is could you take a 5.0 series etherboot and dump the e820 map
> > you get.
> Done.  Result with current 5.0.x CVS is sensible:
> [0000000000000000, 000000000009FC00) type 1
> [000000000009FC00, 00000000000A0000) type 2
> [00000000000F0000, 0000000000100000) type 2
> [00000000FFFF0000, 0000000100000000) type 2
> [0000000000100000, 00000000037F0000) type 1
> [00000000037F3000, 0000000003800000) type 3
> [00000000037F0000, 00000000037F3000) type 4
> Result from 5.1.x is genuine garbage, looking almost like random data.
> Short extract:
> ...
> [0F52506100000000, 1B5D5D6319190619) type 0
> [4000400010000800, 9050672860302028) type 690825260
> [C0325250291E2E2A, 61193E3649CF1F10) type 552004582
> ...

Fixed it!

Problem was that %ebx was not zeroed before the first Int15:e820 call.
Presumably, some BIOSes can cope with this and will correct for it, but
others will just blindly use it as an offset into some table.

I now get the correct E820 map returned in 5.1.x.  Fix is committed to
pcbios.S.  It's a one-liner:
  xorl %ebx, %ebx
that somehow got lost between 5.0.x and 5.1.x.

Michael Brown
http://www.fensystems.co.uk