how much ram can 32 bits really address?
-
- Member
- Posts: 199
- Joined: Fri Jul 13, 2007 6:37 am
- Location: Stuttgart/Germany
- Contact:
how much ram can 32 bits really address?
32 bits can address 2^32 bytes, 4 gigs if you will
but wait...
0c0000-0c7fff: are used for the video bios (32k)
;0c0000-oeffff: BIOS shadow area (whatever that is, it takes
192k)
;0f0000-0fffff: System bios (ROM) (64k)
that makes 288 k of your address space which obviously you cannot addres (in case you really have 4 gigs of ram)
and what happens with the video ram? where is it mapped? when i write to b8000, am i writing the memory of my video adapter or my system memory? what if my video adapter has 256 or more megs of ram? do i have to take that from the addressable ram too???
how does this all work???
but wait...
0c0000-0c7fff: are used for the video bios (32k)
;0c0000-oeffff: BIOS shadow area (whatever that is, it takes
192k)
;0f0000-0fffff: System bios (ROM) (64k)
that makes 288 k of your address space which obviously you cannot addres (in case you really have 4 gigs of ram)
and what happens with the video ram? where is it mapped? when i write to b8000, am i writing the memory of my video adapter or my system memory? what if my video adapter has 256 or more megs of ram? do i have to take that from the addressable ram too???
how does this all work???
im not the most experienced one here, but isnt the onboard ram on the video card a directly addressable space?
instead of addressing physical memory in that situation you are addressing the physical memory on the video card, therefore it does NOT cut into your 4gigs of physical ram.
instead of addressing physical memory in that situation you are addressing the physical memory on the video card, therefore it does NOT cut into your 4gigs of physical ram.
Website: https://joscor.com
To detct memory use BIOS int 15h eax,e820h
Read http://www.osdev.org/wiki/How_Do_I_Dete ... unt_Of_RAM
If you video adapter have 256 or more megs of ram. The video mem mapped to space at hight address (hereabouts С0000000h-FFFFFFFFh). If you read about LFB you know abaut it.
All device can use top of mem address to mapped theirs memory, Memory Mapped I/O.
Any chipset, blocking main memory, at the hight Top of Used DRAM ( Top of Low Usabled DRAM).
Other remap part main ram to height 4GB. System support 36 bit physical address.
Some system also dooble write to main memory, and read from there. It faste then read from video memory.
0C0000h-0FFFF0-shadow area of RAM. You can unlock it to write.
Read http://www.osdev.org/wiki/How_Do_I_Dete ... unt_Of_RAM
If you video adapter have 256 or more megs of ram. The video mem mapped to space at hight address (hereabouts С0000000h-FFFFFFFFh). If you read about LFB you know abaut it.
All device can use top of mem address to mapped theirs memory, Memory Mapped I/O.
Any chipset, blocking main memory, at the hight Top of Used DRAM ( Top of Low Usabled DRAM).
Other remap part main ram to height 4GB. System support 36 bit physical address.
When you write to(read from) A0000h-BFFFFh you write to(read from) video memory.when i write to b8000, am i writing the memory of my video adapter or my system memory?
Some system also dooble write to main memory, and read from there. It faste then read from video memory.
0C0000h-0FFFF0-shadow area of RAM. You can unlock it to write.
Sorry, my bed english. =)
Re: how much ram can 32 bits really address?
You have an address space on your CPU that depends on the number of address lines on the CPU (the number of physical lines). Up to the PPro you had 32 lines (or less), the PPro until the P4 / P-M had 36 lines, the newer Intel and AMD cpu's have 40. That means you can physically address up to a terabyte.sancho1980 wrote:32 bits can address 2^32 bytes, 4 gigs if you will
but wait...
0c0000-0c7fff: are used for the video bios (32k)
;0c0000-oeffff: BIOS shadow area (whatever that is, it takes
192k)
;0f0000-0fffff: System bios (ROM) (64k)
that makes 288 k of your address space which obviously you cannot addres (in case you really have 4 gigs of ram)
and what happens with the video ram? where is it mapped? when i write to b8000, am i writing the memory of my video adapter or my system memory? what if my video adapter has 256 or more megs of ram? do i have to take that from the addressable ram too???
how does this all work???
Logically you can still only address 2^32 bytes in pmode, or 2^48 in lmode. You're interested in physical however.
Yes, all of these things take a chunk out of the space. The memory usually starts at 0 and runs to its own end of memory, after that there's literally nothing. The space after it is used by devices and they're told using the PCI configuration space mechanism where they are supposed to be. This includes the full memory of your video card.
Your video card probably also knows a neat trick - it can take a byte out of your normal memory for its use. Some video cards use solely normal memory for this purpose. I expect them to list it in the E820 memory map but you'd have to find somebody who's tried this on one of those devices.
Hope this helps. If you have more specific questions, don't be afraid to ask.
Re: how much ram can 32 bits really address?
Hi,
For a computer with 4 GB of RAM, you might only be able to access half of RAM with 32-bit addressing. Depending on your chipset/BIOS the extra RAM may be accessable above 4 GB.
I should point out that most CPUs (Pentium II and later?) support PAE and PSE-36. Both of these are different ways of doing paging that allow the OS to use 36-bit physical addresses (up to 64 GB of physical address space).
For PCI, when the CPU tries to access something in the physical address space the memory controller checks to see if it's RAM or not. If it's not RAM it sends the access to the PCI bus, where PCI bridges route the access to a certain bus segment and devices on that bus segment may respond to it.
Usually, for a video card the PCI bridges route accesses to the area between 0x000A0000 to 0x000BFFFF to the bus segment that the video card is on. Usually the entire video display memory is also mapped into the "PCI device hole" below 4 GB, and accesses to this area are also routed by bridges to the bus segment that the video card is on.
How the video card interprets these accesses depends entirely on the device. For example, when you write to 0x000A0000 to video card might AND it with something, then split it into bits and send each bit to a different 64 KB bank of display memory, so that an 8-bit write effects 8 different areas of display memory. Of course this also depends on how the video card is configured (which usually depends on which video mode it's in - the "8-bits split into 8 different areas" example is common for 16 colour modes). For something like bank switched video modes, it's common for 64 KB of display memory to be mapped at 0x000A0000 and another 64 KB of display memory to be mapped at 0x000B0000, so that when you write to 0x000A0000 the video card does "my_address = your_address - 0x000A0000 + bank_start_address" to figure out which address in it's RAM to use.
If video display memory is (also) mapped into the "PCI device hole" below 4 GB, then usually the video display memory is mapped "as is" with no strange addressing translations (but again, this is entirely up to the video card).
It's also common for the video card's registers to (optionally) be mapped into the physical address space, so that it's device driver can use memory accesses instead of I/O ports.
Then there's the IOMMU, which is a new thing that's built into the memory controller. It's capable of translating and restricting different accesses, so that (for e.g.) when the CPU asks for one address it's translated to a completely different address on the PCI bus.
Basically, when software asks to read or write to any address, the CPU can mangle the address or do other things with it (via. the segmentation and paging mechanisms), then the memory controller can mangle the address or do other things with it, then the PCI bridges route it somewhere, then the PCI device can ignore it or accept it (and mangle it or do other things with it).
Cheers,
Brendan
With 32-bits you can access 4 GB of physical address space. However "physical address space != RAM" - usually there's about 380 KB of legacy stuff below 1 MB and a hole for memory mapped PCI devices, APICs, the BIOS ROM itself, etc just below 4 GB. The size of this second area can be anything (depending on your chipset, BIOS and devices) - 512 MB and 1 GB are common.sancho1980 wrote:32 bits can address 2^32 bytes, 4 gigs if you will
but wait...
For a computer with 4 GB of RAM, you might only be able to access half of RAM with 32-bit addressing. Depending on your chipset/BIOS the extra RAM may be accessable above 4 GB.
I should point out that most CPUs (Pentium II and later?) support PAE and PSE-36. Both of these are different ways of doing paging that allow the OS to use 36-bit physical addresses (up to 64 GB of physical address space).
First, you could have a (purely theoretical) device with 512 MB of RAM in it, where the device's RAM can only be accessed via. I/O ports and can't be mapped into the physical address space at all. Alternatively, you might not be able to access the device's RAM at all (for e.g. a large cache in a hard disk controller).sancho1980 wrote:and what happens with the video ram? where is it mapped? when i write to b8000, am i writing the memory of my video adapter or my system memory? what if my video adapter has 256 or more megs of ram? do i have to take that from the addressable ram too???
For PCI, when the CPU tries to access something in the physical address space the memory controller checks to see if it's RAM or not. If it's not RAM it sends the access to the PCI bus, where PCI bridges route the access to a certain bus segment and devices on that bus segment may respond to it.
Usually, for a video card the PCI bridges route accesses to the area between 0x000A0000 to 0x000BFFFF to the bus segment that the video card is on. Usually the entire video display memory is also mapped into the "PCI device hole" below 4 GB, and accesses to this area are also routed by bridges to the bus segment that the video card is on.
How the video card interprets these accesses depends entirely on the device. For example, when you write to 0x000A0000 to video card might AND it with something, then split it into bits and send each bit to a different 64 KB bank of display memory, so that an 8-bit write effects 8 different areas of display memory. Of course this also depends on how the video card is configured (which usually depends on which video mode it's in - the "8-bits split into 8 different areas" example is common for 16 colour modes). For something like bank switched video modes, it's common for 64 KB of display memory to be mapped at 0x000A0000 and another 64 KB of display memory to be mapped at 0x000B0000, so that when you write to 0x000A0000 the video card does "my_address = your_address - 0x000A0000 + bank_start_address" to figure out which address in it's RAM to use.
If video display memory is (also) mapped into the "PCI device hole" below 4 GB, then usually the video display memory is mapped "as is" with no strange addressing translations (but again, this is entirely up to the video card).
It's also common for the video card's registers to (optionally) be mapped into the physical address space, so that it's device driver can use memory accesses instead of I/O ports.
Then there's the IOMMU, which is a new thing that's built into the memory controller. It's capable of translating and restricting different accesses, so that (for e.g.) when the CPU asks for one address it's translated to a completely different address on the PCI bus.
Basically, when software asks to read or write to any address, the CPU can mangle the address or do other things with it (via. the segmentation and paging mechanisms), then the memory controller can mangle the address or do other things with it, then the PCI bridges route it somewhere, then the PCI device can ignore it or accept it (and mangle it or do other things with it).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
CPU have, but mother board (chpset) can have 32 lines or 36.You have an address space on your CPU that depends on the number of address lines on the CPU (the number of physical lines). Up to the PPro you had 32 lines (or less), the PPro until the P4 / P-M had 36 lines, the newer Intel and AMD cpu's have 40. That means you can physically address up to a terabyte.
Sorry, my bed english. =)
-
- Member
- Posts: 199
- Joined: Fri Jul 13, 2007 6:37 am
- Location: Stuttgart/Germany
- Contact:
You can. You have a few things to work with though...sancho1980 wrote:damn this sounds complicated
how am i actually going to write an operating system if i cant rely on anything...
1) The upper 384KB of the first MB of memory (0x000A0000 - 0x000FFFFF) is all memory-mapped from devices in one way or another, a legacy kick-back you have to deal with so just treat it as a "no RAM" area.
2) Not every system has 640KB of conventional memory (the lower 640KB of the first MB), but you can be virtually assured that there is at least 256KB. The CMOS should return the correct amount of conventional memory installed.
3) Any system with such mappings as Brenden and Candy describe (e.g. ACPI) are easily dealt with by using the Real-Mode BIOS Interrupt 0x15, Function 0xE820 to return a detailed map of memory regions. Using that map, you know where usable RAM is and is not.
If you are not comfortable at first, you can always rely on GRUB for such assured memory detection.
-
- Member
- Posts: 199
- Joined: Fri Jul 13, 2007 6:37 am
- Location: Stuttgart/Germany
- Contact:
Im trying to make sense of int 15, AX = E820h
the wiki says: "a maximum of 20 bytes will be transferred at one time" for the address range descriptor...
a little bit of googling gives me (http://www.osdev.org/osfaq2/index.php/H ... f%20RAM%3F):
also, specifying in ecx how many bytes i want returnt doesnt make sense: if im asking for a descriptor, i sure am asking for the whole descriptor..what use is a partial descriptor?
please let there be light. nothing really explains it
[/url]
the wiki says: "a maximum of 20 bytes will be transferred at one time" for the address range descriptor...
a little bit of googling gives me (http://www.osdev.org/osfaq2/index.php/H ... f%20RAM%3F):
So the address range descriptor is 16 + 16 + 8 bytes = 40 bytes long. this doesnt add up! if i call this interrupt twice in a row with the same input, do i get the other 20 bits on the second run?Format of Phoenix BIOS system memory map address range descriptor:
Offset Size Description (Table 00559)
00h QWORD base address
08h QWORD length in bytes
10h DWORD type of address range (see #00560)
also, specifying in ecx how many bytes i want returnt doesnt make sense: if im asking for a descriptor, i sure am asking for the whole descriptor..what use is a partial descriptor?
please let there be light. nothing really explains it
![Sad :-(](./images/smilies/icon_sad.gif)
You not right calc.
QWord 8 Bytes
DWord 4 Bytes
Word 2 Bytes
Byte 1 Byte
8+8+4=20 bytes long
Format of Phoenix BIOS system memory map address range descriptor:
Offset Size Description (Table 00559)
00h QWORD base address
08h QWORD length in bytes
10h DWORD type of address range (see #00560)
QWord 8 Bytes
DWord 4 Bytes
Word 2 Bytes
Byte 1 Byte
8+8+4=20 bytes long
Sorry, my bed english. =)
-
- Member
- Posts: 199
- Joined: Fri Jul 13, 2007 6:37 am
- Location: Stuttgart/Germany
- Contact:
Pavia wrote:You not right calc.Format of Phoenix BIOS system memory map address range descriptor:
Offset Size Description (Table 00559)
00h QWORD base address
08h QWORD length in bytes
10h DWORD type of address range (see #00560)
QWord 8 Bytes
DWord 4 Bytes
Word 2 Bytes
Byte 1 Byte
8+8+4=20 bytes long
![Embarassed :oops:](./images/smilies/icon_redface.gif)