What information does BIOS load into RAM?

Question

I know that, on booting, BIOS loads the first sector (512 bytes) of a pre-defined device drive on memory 0x7c00 and then jump to that address.

So, memory from 0x7c00 to 0x7dff is occupied. Is there any other section of RAM that is occupied?

If I'm programming an Operating System, could I use all the RAM except 0x7c00 to ox7dff for my own purposes?, or, is there any other section filled with "precious" information at boot time that I must not overwrite?

I know that at a given moment, I can overwrite MBR loaded on memory (chainloading), my question is focused on... what part of the memory is available for an Operating System?

Sorry for my bad english. Thanks for your answers!!

Holinshed

Answer 1

The x86 Real Mode Memory Map is as follows:

 - 0x00000000 - 0x000003FF - Real Mode Interrupt Vector Table
 - 0x00000400 - 0x000004FF - BIOS Data Area
 - 0x00000500 - 0x00007BFF - Unused
 - 0x00007C00 - 0x00007DFF - Our Bootloader
 - 0x00007E00 - 0x0009FFFF - Unused
 - 0x000A0000 - 0x000BFFFF - Video RAM (VRAM) Memory
 - 0x000B0000 - 0x000B7777 - Monochrome Video Memory
 - 0x000B8000 - 0x000BFFFF - Color Video Memory
 - 0x000C0000 - 0x000C7FFF - Video ROM BIOS
 - 0x000C8000 - 0x000EFFFF - BIOS Shadow Area
 - 0x000F0000 - 0x000FFFFF - System BIOS

In my real mode programming I usually stick from 0x00007E00 - 0x0009FFFF (Not all of it).. I use segment:offset addressing to use the memory.. To go from a 1 Stage bootloader to a Kernel or a Bootloader 2nd Stage, I use:

; bootloader.s

BITS  16
ORG   0x7C00

  CLI
  JMP 0xE000      ; Can also be JMP 0x7C00:200
  HLT

TIMES 510 - ($-$$) DB 0
DW 0xAA55

--

; Something.s

BITS  16
ORG   0x7E00      ; Can also be ORG   0x7C00:200

; Code goes here for your purposes.. whether it be a 2nd stage
; bootloader or your 16bit kernel..

CLI
HLT

If you are going into Protected mode, you will still need a stub as shown above.. In Something.s you can program in your protected mode routines (GDT, A20, Set video mode, etc..)

To explain about the memory location at 0x7C00 (Bootloader Entry Point), 0x7C00 - 0x7DFF is where you place your bootloader (the bootloader.s above). You place it there because the BIOS jumps to that location after doing its routines. The bootloader must be exactly 512 bytes in size (notice the TIMES directive). From there, your code can be any size (as long as it fits in the memory map), and you will be able to work on the OS fully.

If you DO go into 32Bit Protected Mode, you will be able to use ANYTHING about the 1MiB mark.

Gupton

I didn't notice the date until after I posted.. Sorry for bringing this back up. – Gupton

"- 0x00007E00 - 0x0009FFFF - Unused" - This is not entirely true. The range that is guaranteed to be free is 0x00007E00 - 0x0007FFFF. Above that range you will have the EBDA (usually at 0x0009FC00 - 0x0009FFFF, but I've seen it at 0x00096C00 and other locations as well) and potentially some BIOS code. Some BIOSes have PXE boot code in this range. A conservative approach is to avoid everything above 0x00080000. – Mcnabb

Answer 2

With any remotely recent BIOS, you can obtain memory map information by using the BIOS Int 15/AX=E820h call. This will tell you what memory you can use for your OS.

A more detailed explanation on how to detect available memory, and the contents of the BIOS memory map can be found at OSDev.

Perfect

Answer 3

If you write an OS, as soon as you go into protected mode, you get forget the BIOS (unless you are working with some bad device) and use all you have.

Or are you writing a bootloader?

Mel

You can't forget the BIOS. It may need some regions of memory protected for MMIO regions, or for use by SMM code. – Perfect

There are a lot of physical memory regions that aren't usable specifically with memory mapped hardware. – Hurdle