Anonymous user
Detecting Memory (x86): Difference between revisions
Jump to navigation
Jump to search
→Manual Probing: Added a Theoretical introduction section
| [unchecked revision] | [unchecked revision] |
(→Manual Probing: Adding additional information about why not to probe memory directly. Previous information might induce the newbie in error.) |
(→Manual Probing: Added a Theoretical introduction section) |
||
Line 252:
There are a few other BIOS functions that claim to give you memory information. However, they are so widely unsupported that it is impossible to even find machines to test the code on. <b>All</b> current machines support E820 (above). If some user should happen to dig up such a dinosaur of a machine that its BIOS does not support any standard memory detection function -- they will not complain that your modern OS fails to support that machine. Just give an error message.
==== Manual Probing ====
{{Warning|This could possibly damage your computer}}
Use BIOS to get a memory map, or use [[GRUB]] (which calls BIOS for you).
==== Theoretical introduction ====
Direct memory probing is only useful for very old systems with buggy and/or non-updateable BIOSes, or maybe a system with modified hardware that does not much the firmware anymore. So if you don't intend to support this sort of computers, you don't need memory probing. Period.
support. However, the algorithm will always need to take into account potential holes in system memory or previously detected memory mapped devices, such as frame buffering SVGA cards, etc. Maybe you will want to probe just a specific range of memory that is known to be otherwise undetectable on a specific computer model.▼
Anyway, don't think that this will save you from the effort of understanding how to call the complicated BIOS APIs. Before launching a probe, you will always need to detect '''if''' the computer where your OS is running really needs it, and '''which''' memory areas really need to be probed (because for other areas you should always consider the information provided by the BIOS). You also need to take into account the appropriate memory holes and/or memory mapped devices, which may vary from system to system.
However, the BIOS is part of the computer, and may know things you ignore about your memory, motherboard and PCI devices. Probing memory-mapped PCI devices may have ''unpredictable results''{{what}} and may theoretically '''damage your system'''{{how}}.▼
▲When perfectly implemented, directly probing memory may allow you to detect extended memory on systems where the BIOS fails to provide the appropriate support. However, the algorithm will always need to take into account potential holes in system memory or previously detected memory mapped devices, such as frame buffering SVGA cards, etc. Maybe you will want to probe just a specific range of memory that is known to be otherwise undetectable on a specific computer model.
▲However, the BIOS is part of the computer, and may know things (see [[#Practical obstacles to memory probing]]) you ignore about your memory, motherboard and PCI devices. Probing memory-mapped PCI devices may have '''unpredictable results''
Note: You will never get an error from trying to read/write memory that does not exist -- this is important to understand: you will not get valid results, but you won't get an error, either.
===== Practical obstacles to memory probing =====
There follows a list of technical difficulties involved in memory probing that may help to implement such an algorithm if you end up having to do it:
* There can be important data structures left in RAM by the BIOS (e.g. the ACPI tables) that you'd trash. Those structures may be anywhere and the only way to know their addresses is to "ask" the BIOS.▼
* There can be a memory mapped device from 15 MB to 16 MB (typically "VESA local bus" video cards, or older ISA cards that aren't limited to just video).
* There can also be a(n) (extremely rare) "memory hole" at 0x00080000 for some sort of compatibility with ancient cards.
Line 274 ⟶ 278:
* There are also (typically older) motherboards where you can write a value to "nothing" and read the same value back due to bus capacitance; there are motherboards where you write a value to cache and read the same value back from cache even though no RAM is at that address.
* There are (older, mostly 80386) motherboards that remap the RAM underneath the option ROMs and BIOS to the end of RAM. (e.g. with 4 MB of RAM installed you get RAM from 0x00000000 to 0x000A0000 and more RAM from 0x00100000 to 0x00460000, which causes problems if you test each MB of RAM because you get the wrong answer -- either under-counting RAM up to 0x00400000, or over-counting RAM up to 0x00500000).
▲* There can be important data structures left in RAM by the BIOS (e.g. the ACPI tables) that you'd trash.
* If you write the code properly (ie. to avoid as many of the problems as you can), then it is <i>insanely</i> slow.
* Lastly, testing for RAM (if it actually works) will only tell you where RAM is - it doesn't give you a complete map of the physical address space. You won't know where you can safely put memory mapped PCI devices because you won't know which areas are reserved for chipset things (e.g. SMM, ROMs), etc.
| |||