I have a quick question? Does GRUB "steal" 513KB (449KB - other emulator) of memory?
Emulator memory: 2048MB (2097152KB). Lower Memory: 639KB. Upper Memory: 2096000KB. Total Memory: 2096639KB ==> 2047MB.
Where did the last megabyte go? Can I safely tell my memory manager that 2048MB are available?
[Answered] GRUB Memory Map Stealing 513KB
[Answered] GRUB Memory Map Stealing 513KB
Last edited by Octacone on Sat Apr 15, 2017 6:52 am, edited 1 time in total.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Re: GRUB Memory Map Stealing 513KB
you cannot safely tell your memory manager any amount of memory, actual RAM memory (especially on real hardware, though somewhat less common on emulators) is almost never contiguous -- always use the memory map, and instead of telling your memory manager how much memory exists, give your memory manager a list of available addressesoctacone wrote:I have a quick question? Does GRUB "steal" 513KB (449KB - other emulator) of memory?
Emulator memory: 2048MB (2097152KB). Lower Memory: 639KB. Upper Memory: 2096000KB. Total Memory: 2096639KB ==> 2047MB.
Where did the last megabyte go? Can I safely tell my memory manager that 2048MB are available?
note: some of this missing memory might be in the area between the lower 639k and the upper 2096000k... the lower number is obviously already deducting some memory for firmware use (otherwise the number should be 640k rather than 639k) -- and if all the memory is laid out sequentially from address 0 (common on modern systems, though some older systems try to "remap" it to higher addresses) then about 384k of memory is hidden underneath the ROM region reserved for system and option ROMs between the lower and upper memory areas -- also the memory between 15MB and 16MB may not be usable (even if actual ram is located there, you will loose and be unable to use that memory on some systems which reserve that memory region for hardware use)
also note, some of that memory is used by the firmware for special tables and things that the OS cannot touch without destroying the computer (even after you take control of the system, the firmware continues to operate without your knowledge or intervention, and it might need some of that memory)
let me reiterate: if you are retrieving a total amount of memory instead of properly parsing the memory map, you can destroy the computer, this should never be done, it is dangerous to do, always always use the memory map
Re: GRUB Memory Map Stealing 513KB
JAAman wrote:you cannot safely tell your memory manager any amount of memory, actual RAM memory (especially on real hardware, though somewhat less common on emulators) is almost never contiguous -- always use the memory map, and instead of telling your memory manager how much memory exists, give your memory manager a list of available addressesoctacone wrote:I have a quick question? Does GRUB "steal" 513KB (449KB - other emulator) of memory?
Emulator memory: 2048MB (2097152KB). Lower Memory: 639KB. Upper Memory: 2096000KB. Total Memory: 2096639KB ==> 2047MB.
Where did the last megabyte go? Can I safely tell my memory manager that 2048MB are available?
note: some of this missing memory might be in the area between the lower 639k and the upper 2096000k... the lower number is obviously already deducting some memory for firmware use (otherwise the number should be 640k rather than 639k) -- and if all the memory is laid out sequentially from address 0 (common on modern systems, though some older systems try to "remap" it to higher addresses) then about 384k of memory is hidden underneath the ROM region reserved for system and option ROMs between the lower and upper memory areas -- also the memory between 15MB and 16MB may not be usable (even if actual ram is located there, you will loose and be unable to use that memory on some systems which reserve that memory region for hardware use)
also note, some of that memory is used by the firmware for special tables and things that the OS cannot touch without destroying the computer (even after you take control of the system, the firmware continues to operate without your knowledge or intervention, and it might need some of that memory)
let me reiterate: if you are retrieving a total amount of memory instead of properly parsing the memory map, you can destroy the computer, this should never be done, it is dangerous to do, always always use the memory map
Thanks for clarification. Actually I am trying to parse a memory map right now. C++ is making this hard for me (awful casting). I actually needed this information for display purposes. Then I guess I can tell the user he has 2048MB of RAM and tell the memory manager it can use 2047MB (memory map data of course).
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Re: GRUB Memory Map Stealing 513KB
Not too much, some casting may be necessary of course.octacone wrote:Actually I am trying to parse a memory map right now. C++ is making this hard for me (awful casting).
the actual parser has a few casts
Learn to read.
Re: GRUB Memory Map Stealing 513KB
Oh, I managed to get around it. That is not longer an issue. Thanks anyways.dozniak wrote:Not too much, some casting may be necessary of course.octacone wrote:Actually I am trying to parse a memory map right now. C++ is making this hard for me (awful casting).
the actual parser has a few casts
Does this memory map look okay?
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
[Answered] GRUB Memory Map Stealing 513KB
0xF(x8)1 = 0xFFFFFFFF + 1 = 0x100000000dozniak wrote:What's 0xF(x8)1 ?? Other than that looks ok.
Answered.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader