Hi,
dmac0505 wrote:
Yeah sorry about saying 'nothing' in RAM - poor word choice on my part. Basically I am just wondering where the physical address of 0 is located physically on a stick of RAM? I assume it has something to do with the circuitry that causes an area of the RAM to be used first?
The CPU doesn't know. The CPU sends any reads/writes that can't be done in cache to the memory controller and never knows or cares if it's RAM or not.
Note: Everything below here is mostly for 80x86. For other systems/CPUs things might be similar in a different way.When you first turn a computer on there is no RAM and the MTRRs are set to "everything uncached". The CPU starts executing ROM (firmware). The memory controller and chipset's default state at power on must forward reads/writes intended for firmware to the ROM.
Firmware (without using any RAM, but possibly by using a "cache as RAM" hack) asks the memory controller to ask the memory modules what they are and then uses this information to configure the memory controller; including setting the speed and physical address of the memory modules correctly.
After that, firmware may test the RAM (but this is typically a "fast and mostly useless" test - enough to determine if the memory module isn't quite plugged in properly and not a lot else).
Next, the firmware figures out the CPU's MTRRs, starts the AP CPUs, determines which CPUs are "good" and which are faulty (from the CPU's built in self test), disables any faulty CPUs, then configures the MTRRs on all working CPUs the same to suit the memory it detected/configured. After this the CPUs can start using their caches. Firwmare would also configure a few other things in the CPUs while they're running (e.g. the SMM area's address for each CPU). Then the firmware sends the AP CPUs back to their "wait for INIT" state (where they do nothing until the OS starts them again).
After all of this; the CPU still just sends any reads/writes that can't be done in cache to the memory controller and never knows or cares if it's RAM or not.
Note 1: For systems with either quick-path or hyper-transport, where you've got 2 or more memory controllers; the firmware would also have to setup the quick-path or hyper-transport links, so that a read/write to a different NUMA domain gets forwarded (via. the link) to the correct memory controller.Note 2: It really is best to think of it as sending/receiving little packets or messages. For example, software reads from physical address 0x12345678, so the CPU sends a "get me the data at 0x12345678" message to the memory controller, the memory controller receives the message and decides whether it should be forwarded to RAM chip/s or a quick-path link or to PCI, and whereever it ends up something sends back a reply message (like "the data at 0x12345678 as 0x99"). When the CPU receives the reply it can finish the instruction that caused the read.Note 3: For simplicity, I've ignored cache coherency in all of the above (e.g. the MESI protocol). Think of this as more messages (like "I want to modify the data at address 0x12345678; so if any of you other CPUs have it cached give me a copy and then forget you ever saw it!").Cheers,
Brendan