Memory maps

[Federico Tomassetti]

I know there're some areas reserved by the BIOS for specific use (es. B8000+ for text mode video memory, some area for ROM data and so on) where I can find a memory map specifyng what memory portions I can use to load my second stage and set my stack? After that I'll need memory to load the rest of my kernel, I can use the service e820 from the int 15? There're better ways? Some comments about this service?

Thanks in advance for all replies,
Federico

[Pype.Clicker]

i found http://www.doc.ic.ac.uk/~rah03/dxos/scrshots.php yesterday which has a snapshot of int15 map displayed. Note that the map tells nothing about what's below 1MB, as this is IBM standard. See perica's tutorial for a map of what's there.

[Gnome]

Yes, you can use that, provided you're in real mode (obviously). It will give you a memory map that is guaranteed to have all the available regions of memory.

This is what I use, indirectly. GRUB supplies the memory map, but it gets it from e820.

[Federico Tomassetti]

When I'm in protected mode I can't use BIOS anymore, right? So there're other ways to obtain the memory map? The unique way is to return in real mode? In this case can you give me some snippet & explanation about do it?

Thanks

[Brendan]

Hi,

When I'm in protected mode I can't use BIOS anymore, right? So there're other ways to obtain the memory map? The unique way is to return in real mode? In this case can you give me some snippet & explanation about do it?

Most (all?) OS's gather this information before enabling protected mode.

One possible example:
- use bios to get memory information
- store memory information somewhere
- enable protected mode
- use stored memory information to initialize physical memory manager/s
- use physical memory manager/s to initialize paging
- enable paging and jmp to kernel

Cheers,

Brendan

[Federico Tomassetti]

To ask memory from the BIOS I can use E820 or E801. Bochs seems to not support E820 so i've to use E801 (for now). I read Ralph Brown's list but I'm confused about "configured memory".

Return: CF clear if successful
    AX = extended memory between 1M and 16M, in K (max 3C00h = 15MB)
    BX = extended memory above 16M, in 64K blocks
    CX = configured memory 1M to 16M, in K
    DX = configured memory above 16M, in 64K blocks
   CF set on error

configured memory indicated an area occuped by I/O mapping, BIOS and other similar stuff? If not how can I know what areas have not to be touched?

Federico

[Perica]

..

[Pype.Clicker]

okay, committed that to the WikiFAQ

[Curufir]

...Bochs seems to not support E820...

Then your code is wrong. Bochs has supported this for as long as I can remember.

configured memory indicated an area occuped by I/O mapping, BIOS and other similar stuff?

No, that's not what configured memory means in this instance. To the best of my knowledge extended memory indicates that the memory was detected automatically (ie From the RAM chips) whilst configured memory indicates the memory was detected via jumper/pin settings on the motherboard (If you have one of these boards then you need to send it to a museum).

Use the set of values that isn't zero. On buggy BIOS both sets will have the same value. On most modern BIOS you'll want the extended memory values.

If not how can I know what areas have not to be touched?

Once above 1Mb no device should get memory mapped into space already used by physical RAM, so you can happily assume anything reported by e801/88 is there to be used by your OS.

Memory mapped devices usually have a mechanism to report back where they are mapped (Eg a graphics card framebuffer). Use those mechanisms to find out which part of the address space they use.

[Federico Tomassetti]

ME>...Bochs seems to not support E820...

CURUFIR>Then your code is wrong. Bochs has supported this for as long >as I can remember.


Ralph Brown's interrupt list:

INT 15 - newer BIOSes - GET SYSTEM MEMORY MAP
   AX = E820h
   EAX = 0000E820h
   EDX = 534D4150h ('SMAP')
   EBX = continuation value or 00000000h to start at beginning of map
   ECX = size of buffer for result, in bytes (should be >= 20 bytes)
   ES:DI -> buffer for result (see #00581)
Return: CF clear if successful
    EAX = 534D4150h ('SMAP')
    ES:DI buffer filled
    EBX = next offset from which to copy or 00000000h if all done
    ECX = actual length returned in bytes
   CF set on error
    AH = error code (86h) (see #00496 at INT 15/AH=80h)

My code:

   xor ax, ax
   mov es, ax
   mov di, MEMMAP_DATA_LINEAR_ADDR
   xor ebx, ebx
   mov eax, 0x0000e820
   mov edx, 0x534d4150
   mov ecx, 20
.loop
   int 15
   cmp eax, 'SMAP'
   jne E820_error / jc E820_error (The same with one line or the other)

This simple code seems to not work under bochs (not tried on a real machine), so I supposed was a bochs' problem, someone can tell me where I'm wrong?

THX

[Brendan]

Hi,

Ralph Brown's interrupt list:

INT 15 - newer BIOSes - GET SYSTEM MEMORY MAP

My code:
???int 15

Ralf Brown isn't all that specific when it comes to determining which values are hex and which are decimal. You're actually trying to use IRQ 7 - try "int 0x15" or "int 21" .

Cheers,

Brendan

[Pype.Clicker]

well, *all* interrupts numbers have *always* be written in hex in every DOC i ever read ... plus the fact you have int 1A etc in the same list should give a hint, no ?

[Federico Tomassetti]

I read in "Linux kernel internals" that some firmware is contained
in the first 64 Kb of memory at startup. It's true? So I've to not use
memory below 0x10000?

[Candy]

I read in "Linux kernel internals" that some firmware is contained
in the first 64 Kb of memory at startup. It's true? So I've to not use
memory below 0x10000?

I have serious doubts about that. Microsoft (what every nitwit "computer component designer" uses to 'test' their hardware) places its own code there. Your boot sector is there. Unless 0E820 says no you should always be able to use all that memory without repercussions.

[Dreamsmith]

Unless 0E820 says no you should always be able to use all that memory without repercussions.

Well, you can't use it all with no repercussions, but depending on your OS, the repercussions may be irrelevent. Specifically, if you clobber the BIOS data below 0x500, you won't be able to use the BIOS anymore. But if you weren't using it anyhow, you probably don't care.