RAM Mapping Script

[Ben Scott]

On Sun, Mar 2, 2008 at 10:40 AM, Jim Kuzdrall <gnhlug at intrel.com> wrote:
>  There is only one level of self-check in this BIOS and that is
>  enabled.

  And BIOS memory tests are notoriously unreliable (i.e., routinely
miss problems).

>  What do you think of this theory?  The BIOS unpacks its startup code
>  into low RAM, but then allows that to be overwritten.

  The BIOS program code is ROM, presented somewhere in the processor's
physical address space below 1 MiB.  Where exactly, I forget, but I
remember it isn't address 0.  The address space used by the ROM is
never available for anything else; it "blocks" the RAM at that
location.  (In real mode.  In protected mode, with virtual memory, I'm
not sure how things work.)

  The processor begins executing the BIOS code immediately on
power-on.  One of the first things that code does is initialize memory
hardware, and then set-up the IVT and stack.  From that point on, the
BIOS code acts just like any other real-mode software (such as GRUB or
MS-DOS).

  The IVT is stored in regular RAM, at addresses 0 though 0x1000.
That isn't program code, stack, or heap; it's a special region of
memory reserved for use by the 8086 aritecture.  MS-DOS used it
extensively.  I don't think GRUB modifies it much, but it still
depends on it to invoke BIOS routines for things like disk services.

  What I don't know about is if or how the protected mode kernel uses
and/or preserves the real-mode IVT at 0x000 though 0x1000.  As others
have noted, the kernel does care about a few real-mode BIOS routines,
for things like rebooting and console video initialization.  I suppose
it's possible the kernel grabs whatever it needs from the real-mode
IVT and then reclaims that kibibyte for other uses.  But it may just
be reserved and untouched.

  It could also be that the memory error being reported is really just
a symptom of some larger problem, such as an ailing processor or
memory controller, or more wide-spread memory faults.

-- Ben