Grub Memory Map Problem

[mordak]

hi
i use virtual pc and grub to load kernel and get memory map and i see lot of code about Grub Mem Map but its return last mem map values negaive?
total memory map is 64mb
before red Rectangle we have 0x03FFF000+0x01000=4000000 or 4000000/(100000)=40 Hex=
64mb and it seem to red rectangle is Extra but mmp_lenght is A8 ro 168
and when we multiply 7*0x14(size)=168 we now understand we must have 7 entry exact and red rectangle is not extra but its false
i confused please help me

[turdus]

Don't use signed int for addresses, use "unsigned int" instead, and you'll be fine. That last block records firmware area at the top of 4G, which makes the most significant bit set in the address. That bit is interpreted as a sign bit for signed int, which is not what you want.

[Brendan]

Hi,

i use virtual pc and grub to load kernel and get memory map and i see lot of code about Grub Mem Map but its return last mem map values negaive?

All of the values in the memory map (base, length, type, etc) are unsigned integers, which means that if you get a negative number displayed then you're printing them as signed integers and not unsigned integers. This is your first mistake; for example, if you print the unsigned 32-bit integer 0xFFFC0000 as a signed 32-bit integer, you'd get the (negative) value -0x00040000.

Half of the values in the memory map (base and length) are 64-bit unsigned integers. For example, the value 0x00000000FFFC0000 is an unsigned 64-bit value. If you (incorrectly) print it as a signed 64-bit value then it'd still be displayed correctly (and won't be negative). Basically, this is the second mistake (printing a 64-bit integer as a 32-bit integer).

Also note that (because hex is normally only used for things like addresses, bit fields, masks, etc), when a hex number is displayed the leading zeros should probably be kept to indicate size. For example, "0x0002" is a 16-bit integer, which is very different to "0x02" (a byte) or "0x2" (half a byte).

This means that the last entry of the memory map *should* look like this:

Code: Select all

size = 0x14, base_addr = 0x00000000FFFC0000, length = 0x0000000000040000, type = 0x02

Of course this is perfectly normal - it describes a 256 KiB ROM exactly where it should be.


Cheers,

Brendan

[mordak]

thank lot of
i assume that value are unsigned int but i print them as signed

Also note that (because hex is normally only used for things like addresses, bit fields, masks, etc), when a hex number is displayed the leading zeros should probably be kept to indicate size. For example, "0x0002" is a 16-bit integer, which is very different to "0x02" (a byte) or "0x2" (half a byte).

thank for your comment
yes its right but not necessary for printing

can explain me about last record mem area what is it?(its above 4GB)

[Brendan]

Hi,

can explain me about last record mem area what is it?(its above 4GB)

That last area (which is just below 4 GiB), is the system's ROM. It contains lots of stuff, including the first instruction that a CPU will execute when it's first turned on, and the "power on self test" code.

Another part of the real ROM (just below 4 GiB) is copied to the "legacy ROM" area (which is actually RAM that is set to "write only" afterwards) during boot. This is the part that runs in real mode and implements the BIOS functions.

The area described by the third entry in your memory map (from 0x000E0000 to 0x000FFFFF) is this "legacy ROM" area.

Mostly they do it like this because the legacy ROM area is too small for modern systems - the entire 256 KiB ROM won't fit in the 64 KiB legacy ROM area; but that legacy ROM area must contain some code that is used by boot loaders (and old OSs like DOS) for backward compatibility.


Cheers,

Brendan