detecting RAM size in stage2

[extremecoder]

I am developing a stage2 loader in asm .. i want to calculate the total available RAM in the system ...

I have read the article from http://wiki.osdev.org/How_Do_I_Determin ... unt_Of_RAM ...

using Int 0x15, with AX=E820h is the only way to reliably and safely calculate the RAM size ?

have someone tried / found any other technique ...

[Blue]

Hi,

I do not know if you already read this excellent post by Brendan about detecting memory, if you did, then just ignore this post
Brendan's Guide To Detecting Memory

Edit: Now I look over the topic again, it seems it has already been merged into the wiki, so just ignore my post.

Blue

[AJ]

Hi,

Yes, that is the way to determine the amount of RAM. If not supported, you should either use one of the other interrupts listed or display an error message and abort.

Cheers,
Adam

[egos]

...is the only way to reliably and safely calculate the RAM size ?

It is the better way

[egos]

If not supported, you should either use one of the other interrupts listed or display an error message and abort.

It is true. See the example in the ACPI specification for details.

[extremecoder]

how many times you would keep on calling int 0x15 ?

as per the logic, you would allocate a area of 24 bytes and pass it on as DI. once the int 0x15 is called, the 24 bytes of info will contain information of RAM regions.

I don't understand, how exactly you would the size of RAM?

If my understanding is correct, then you will keep on running this is in a loop, which will return 24 bytes of information everytime, and based on that you keep on collect information of certain RAM regions and will finally calculate the size based on Type 1?

If that is the case, how many 24 byte entry list you will allocate initially ? or let's say for a n amount of RAM, how many times the loop will get executed ?

[Hyperdrive]

If my understanding is correct, then you will keep on running this is in a loop, which will return 24 bytes of information everytime, and based on that you keep on collect information of certain RAM regions and will finally calculate the size based on Type 1?

If that is the case, how many 24 byte entry list you will allocate initially ? or let's say for a n amount of RAM, how many times the loop will get executed ?

For the BIOS call one 20/24 byte area is sufficient, as you can simply reuse it. What you do with the returned information is another thing. Build your own list of regions, or just sum the amount of available RAM, or ... whatever you want. Depending on what you do you have to allocate some memory. You can do that the way you like. (For example, allocate 128 bytes for your own list and extend it, if you run out of space. (How you extend the space is another story...))

You'll don't know how many times you have to call E820 to get the full list. But you'll eventually get an indication that there are no more entries.

From the RBIL:

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)

If you really need to know the exact amount of returned entries, the only thing of which I can think at the moment is:

• 1. allocate one dummy entry and use this one throughout step 2
  2. call repeatedly E820 until there are no more entries and count the invocations of E820
  3. allocate enough memory for the amount of entries you've obtained in step 2
  4. start again calling E820 repeatedly until there are no more entries and point every time to another pre-allocated entry of step 3

But that's not that nice. You'll probably want to consider the above mentioned scheme with "extending" a memory allocation (i.e. a heap-style version).

--TS