Page 1 of 1
Bug on memory map wiki page
Posted: Tue Nov 11, 2008 3:09 pm
by captainwiggles
Hey guys, I just signed up so I could edit a bug on the wik, but seems I have to wait to be added to the group first.
I decided to make this post, so that if I forget to make the change, somebody else will see it.
OK. On the page:
http://wiki.osdev.org/Memory_Map_(x86) In the ""Upper" Memory (> 1 MiB)" section, the seccond entry of the table, should have size B00000 not 900000.
Thanks for an awesome site.
Andy
Re: Bug on memory map wiki page
Posted: Tue Nov 11, 2008 6:27 pm
by Love4Boobies
It's not the wiki you should look after. I thought that as first also, but try using the forum for a while. You'll be really surprised.
Re: Bug on memory map wiki page
Posted: Tue Nov 11, 2008 10:43 pm
by bewing
captainwiggles, as the author of that article, I thank you. And Combuster too, for the actual edit. I disagree with Love4Boobies to some extent -- we should gather as much accurate info into the wiki as we can, to reduce the number of repeated questions. Making factual edits and additions to the wiki is a very important and useful thing.
Re: Bug on memory map wiki page
Posted: Thu Nov 13, 2008 8:43 pm
by ~
What about the range from 0xE0000000, etc., to 0xFFFFFFFF or maybe beyond?
Also, are you certain of the range from 0x0C000000 to 0x0FFFFFFF?
Maybe it was a computer with 256Mb sharing some 64Mb of memory for something like video?
Maybe any arbitrary RAM could be used and the BIOS should be queried whenever possible?
Here I include two attachments of the PCI memory usage for my newer PC, seen under Windows and under DOS. It has 512Mb of RAM. It appears by the BIOS as having 448Mb of RAM since it is sharing 64Mb for the integrated video.
Re: Bug on memory map wiki page
Posted: Fri Nov 14, 2008 6:54 am
by Brendan
Hi,
The entire physical memory map depends on the hardware (chipset, BIOS, PCI devices present, RAM present, etc).
There are some thing an OS can assume, including what's in the first 1 MiB of the physical address space (because of backward compatibility), the address of the first I/O APIC (if present), the address of the local APIC/s (if present) and the true address of the BIOS ROM (or at least the address that the BIOS ROM ends - you don't know how large the BIOS ROM is so you don't know where it starts).
However, you should never assume anything unless you absolutely have to. There are situations where you need to assume something about the physical address space, but each time you assume something you increase the chance of compatibility problems. This means you can mostly forget about everything you assumed about the physical address space - you should ask the BIOS for a physical address space map (e.g. from Int 0x15 , eax = 0xE820); and you should ask ACPI tables and/or MP specification tables where the I/O APICs are and where the local APICs are; and you should get the addresses of any memory mapped PCI devices from the device's BARs (in PCI configuration space).
Typically, the area from 0xFE000000 to 0xFFFFFFFF is used by the BIOS ROM and specific devices (I/O APICs, local APICs, and HPET if I remember right). Also, typically the area below this is used for memory mapped PCI devices (including 64-bit PCI devices, because a 32-bit OS may not be able to use 64-bit addressing, so a 64-bit PCI device still needs to be mapped below 4 GiB for backward compatibility). This "PCI device" area is typically from 0xC0000000 to 0xFDFFFFFF, or from 0xE0000000 to 0xFDFFFFFF, or maybe from 0x80000000 to 0xFDFFFFFF. Still, these are all just assumptions - nothing guarantees these assumptions are correct, and nothing prevents a BIOS/motherboard manufacturer from doing things completely differently.
Cheers,
Brendan