Page 1 of 1
Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 1:48 am
by user11924
Is there any way to access the physical memory corresponding to the addresses that are 'holes' according to the BIOS (perhaps because there are devices mapped there or whatever)?
Or is that memory always empty, from when the computer is turned on to when it is turned off?
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 3:10 am
by bluemoon
There is no usable memory in the hole. It can be faulty ram that is disabled, or for any reason the BIOS don't feel like you using it.
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 3:23 am
by wikiwolf
Devices can be remapped but BIOS areas are reserved, don't mess with them.
Memory-mapped I/O is the common method to access devices on the x86 architecture so it's unlikely you can get rid of memory gaps...
...or maybe I'm missing something. I'm not very expert, sorry.
Some useful info in the wiki:
http://wiki.osdev.org/Memory_Map_%28x86%29
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 4:02 am
by Brendan
Hi,
There is one case - for most modern chipsets/motherboards, the area reserved for legacy ROMs (e.g. from 0x000C0000 to 0x000EFFFF) is actually RAM. The BIOS copies "ROM images" from PCI devices into this area and then tells the memory controller to treat this area as "read only". With some special (chipset/motherboard specific) ninja hacks (and some MTRR changes), you can reclaim this RAM and gain an extra 192 KiB of RAM to play with.
Cheers,
Brendan
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 5:17 am
by Nable
> extra 192 KiB of RAM
MMIO uses much more space than 192k. For example, you have 4G of RAM and framebuffer is mapped somewhere in these 4G.
6.25 or 12.5% (for rather typical 256/512M framebuffers) of memory will be lost.
Afair, one can program MTRRs to specify whether bus access will go to MMIO or RAM, am I right?
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 5:24 am
by Griwes
Nable wrote:> extra 192 KiB of RAM
MMIO uses much more space than 192k. For example, you have 4G of RAM and framebuffer is mapped somewhere in these 4G.
6.25 or 12.5% (for rather typical 256/512M framebuffers) of memory will be lost.
Afair, one can program MTRRs to specify whether bus access will go to MMIO or RAM, am I right?
Nowadays, you have 256TiB of virtual address space, so 256/512MiB is 9.5 * 10^-5% or 19 * 10^-5% - it doesn't really matter (I don't count physical RAM here, which is normally about 6GiB and more nowadays).
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 5:31 am
by xenos
My laptop has 4GB RAM installed and it has a memory hole from 0xC0000000 to 0xFFFFFFFF. However, that does not mean that 1GB of my physical RAM is inaccessible - it is simply mapped to 0x100000000 to 0x13FFFFFFF. So there really is no physical memory hidden behind that hole.
The situation may be differrent for legacy memory holes in the area 0xA0000 to 0xFFFFF.
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 6:39 am
by bluemoon
I'm more curious on 15m-16m memory hole on legacy machine, do that memory get remapped or just get wasted?
Re: Accessing physical memory behind the 'holes'?
Posted: Thu May 17, 2012 7:21 am
by Brendan
Hi,
bluemoon wrote:I'm more curious on 15m-16m memory hole on legacy machine, do that memory get remapped or just get wasted?
I'd assume there's old motherboards (e.g. intended for 8 MiB of RAM or less) that don't remap anything in that hole when more memory is present. I'd assume there's slightly newer motherboards (e.g. intended for 16 MiB or more RAM) where RAM in that area is remapped elsewhere and others that don't. I'd also assume there's even newer motherboards (probably everything made in the last 15 years) where 1 MiB of RAM wasn't considered worth worrying about anymore. I'd also assume there's recent motherboards that don't even support the hole (as it's not used unless there's ISA devices, and ISA is "obsolete enough" now).
Unless you know the details for a specific motherboard/chipset you can't really know if the RAM gets remapped or not; and if the RAM isn't remapped you'd need a lot more details to determine if anything can be done about it anyway. For example, if a computer does have this hole, and if you had enough information to write chipset specific code to disable the hole, you'd still have to determine if there are any ISA devices using the hole before you could safely disable it. Of course ISA sucks - you'd have to manually probe for every ISA card ever created that could be using the hole just to determine if any are present.
Cheers,
Brendan
Re: Accessing physical memory behind the 'holes'?
Posted: Mon Jun 11, 2012 8:51 pm
by user11924
bluemoon wrote:There is no usable memory in the hole. It can be faulty ram that is disabled, or for any reason the BIOS don't feel like you using it.
Hmmm... but e.g. System Management Mode can definitely use RAM behind the Video RAM address range (
http://fawlty.cs.usfca.edu/~cruse/cs630f06/duflot.pdf), so that's what made me wonder if you could somehow hack around for other addresses as well.
Re: Accessing physical memory behind the 'holes'?
Posted: Mon Jun 11, 2012 8:52 pm
by user11924
Brendan wrote:bluemoon wrote:I'm more curious on 15m-16m memory hole on legacy machine, do that memory get remapped or just get wasted?
Unless you know the details for a specific motherboard/chipset you can't really know if the RAM gets remapped or not; and if the RAM isn't remapped you'd need a lot more details to determine if anything can be done about it anyway. For example, if a computer does have this hole, and if you had enough information to write chipset specific code to disable the hole, you'd still have to determine if there are any ISA devices using the hole before you could safely disable it. Of course ISA sucks - you'd have to manually probe for every ISA card ever created that could be using the hole just to determine if any are present.
That's interesting, cool!