how much ram can 32 bits really address?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

how much ram can 32 bits really address?

Post by sancho1980 »

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???
User avatar
01000101
Member
Member
Posts: 1599
Joined: Fri Jun 22, 2007 12:47 pm
Contact:

Post by 01000101 »

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.
Pavia
Posts: 23
Joined: Mon Jun 25, 2007 2:54 pm
Location: Russia

Post by Pavia »

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.
when i write to b8000, am i writing the memory of my video adapter or my system memory?
When you write to(read from) A0000h-BFFFFh you write to(read from) video 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. =)
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re: how much ram can 32 bits really address?

Post by Candy »

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???
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.

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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: how much ram can 32 bits really address?

Post by Brendan »

Hi,
sancho1980 wrote:32 bits can address 2^32 bytes, 4 gigs if you will
but wait...
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.

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).
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???
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).

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.
Pavia
Posts: 23
Joined: Mon Jun 25, 2007 2:54 pm
Location: Russia

Post by Pavia »

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.
CPU have, but mother board (chpset) can have 32 lines or 36.
Sorry, my bed english. =)
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

Post by sancho1980 »

damn this sounds complicated
how am i actually going to write an operating system if i cant rely on anything...
SpooK
Member
Member
Posts: 260
Joined: Sun Jun 18, 2006 7:21 pm

Post by SpooK »

sancho1980 wrote:damn this sounds complicated
how am i actually going to write an operating system if i cant rely on anything...
You can. You have a few things to work with though...

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.
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

Post by sancho1980 »

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):
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)
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?
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]
Pavia
Posts: 23
Joined: Mon Jun 25, 2007 2:54 pm
Location: Russia

Post by Pavia »

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
Sorry, my bed english. =)
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

Post by sancho1980 »

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
:oops:
Post Reply