By this point, most of you probably already know that the Late 2005 PowerMac G5 (along with the Quad) actually supports far more memory than the measly 16GB which is purportedly the limit for it. Now, apparently, some 4GB DDR2 sticks might work in it without performing any OpenFirmware magic whatsoever, but not all of them. And to get the latter working, @sasho648 came up with a bit Forth code for OpenFirmware back in the day. This guide, however, describes an improved (yet very similar) process suggested by @joevt.
Now, I always knew that running more than 16GB of memory in a PowerMac G5 was technically possible. But what I personally didn't know is just how easy it actually is. It appears that you don't need any special 'mac-friendly' RAM or even that much technical knowledge, just a few magic numbers and some free time to enter them into OpenFirmware.
What OpenFirmware actually is, in large part, is a neat way to modify hardware description passed to the operating system kernel on boot. This hardware description is a tree-like structure called OpenFirmware Device Tree. The funny thing is, this is quite an open standard, and one still in very wide use today. If you have an Android phone, chances are, it uses the same old Device Tree specification to pass hardware description to the Linux kernel, which works under the hood of Android. Time is a flat circle.
But enough with the history lessons. What we're going to do is modify the 'memory' node of the device tree, which describes the memory layout of the system. More specifically, the 'reg' property of the 'memory' node, which is passed to the operating system and lets the operating system kernel know how much memory there is in the machine, or, in fancier terms, which portions of the physical address space it can safely address without going out of bounds of actual memory capacity.
Getting your current memory mapping configuration
First of all, boot into OpenFirmware and enter the following commands:
This will display all the properties of the 'memory' node, which is directly under the root node, '/'. One of the properties will be called 'reg' and it will look a bit like this:
Initial memory mapling configuration & plan of action
Now, if you were to take the door off of my G5, remove the front fan assembly, and look at how the RAM sticks are physically situated in the machine, my RAM configuration would look a bit like this:
OpenFirmware, however, does not count RAM slots from top to bottom, it counts them from the center outwards, as numbered in the braces. So, to OpenFirmware, my RAM configuration looks a little bit like this:
And that is what we see in the 'reg' property, if we squint and look hard enough:
Each line of the 'reg' property contains: two 32-bit integers which are combined into one 64-bit integer to get the offset of a usable address space segment in the physical memory address space of the machine, and a 32-bit integer which indicates the size of that segment.
Here, you should understand one important point. By the time OpenFirmware boots, the 4GB sticks are already properly initialized and available to the system should it decide to use them. It simply does not do that, because it has not been passed the correct 'reg' property.
Now, OpenFirmware tries to configure the 'reg' property by simply estimating where each of the DIMMs should end up in the physical address space after initialization (failing the process for the 4GB DIMMs). But, crucially, the size of a segment in the 'reg' property does not have to be an actual size of any actual RAM stick. You can split one RAM sticks into two segments. You can group many RAM sticks together into one segment. As long as you cover the desired amount of usable address space with the segments, and as long as they don't intersect, you're fine.
One additional thing to note is that OpenFirmware spits out and interprets the size and offset values in hexadecimal notation, which is why
We see in our 'reg' property configuration that the address slace of the 4GB sticks isn't being properly represented by OpenFirmware. My best guess as to why is that the size which OpenFirmware wants to map into the machine address space exceeds the limit of the 32-bit integer. It wants to map
We're going to fix this by overwriting the 'reg' property and manually inserting the physical address space segments which will represent our 4GB DIMMs.
Coming up with corrected memory mapping configuration
To make reading hex math easier on your eyes, from this point on, I'm going to be putting spaces inside numbers in strategic places, like this:
Before we start, there is one cardinal rule for coming up with your own configuration, which is that there should be a two-gigabyte-sized hole in your configuration starting at the two-gigabyte offset, meaning you should never use addresses from
This is the so-called "I/O hole". The processor actually communicates with peripherals by reading from and writing to addresses from that range. If you put addresses from this I/O hole range into the 'reg' propety, you're essentially telling the operating system kernel to treat peripherals as RAM. In practice, this just means that the system will crash at some point when booting the OS, as when you write sensetive kernel code to your mouse, it doesn't tend to stick around.
The easiest way out of this problem is to just put your smallest RAM sticks into the first slots, like I did, and use the values which OpenFirmware automatically generates for you until you reach the first unrecognized stick, which at this point you will be wanting to map to an offset higher than
But anyways, for me the proper 'reg' property looks something like this:
You can see from my configuration that I've mapped the first 4GB stick right after where the last 2GB stick ends (
When coming up with your own configuration, I find that it is easiest to count in terms of gigabytes. As we've already established,
Also,
My assumption is that the current theoretical memory maximum for the G5 (28 GB) can be reached with the following configuration (this configuration is untested, as I currently do not have the RAM to test it):
And if you can find a pair of 4GB memory sticks which get recognized by the PowerMac G5 without OpenFirmware trickery, the theoretical maximum goes up to 32 GB.
Now the question is, how do you actually overwrite the reg property?
Applying new memory mapping configuration
First, remove spaces and newlines from your desired configuration, so that it looks like one continuous string:
We will refer to this string of as
Now, simply enter the following code into OpenFirmware, taking care to replace
You can then verify that you've entered the configuration correctly by re-entering the code from the begginning:
If you see that you've made a mistake, you can use up/down arrow keys to go back to the command with the mistake and edit it. Verify again, and, when you're ready, simply type in
Final words
As for me, after going through these steps, I've been able to get the full 18GB I have in the system working with both Gentoo Linux I've been experimenting with as of late and Sorbet Leopard. Not that I need it, per se, but it is both fun and absolutely ridiculous.
Good luck!
Now, I always knew that running more than 16GB of memory in a PowerMac G5 was technically possible. But what I personally didn't know is just how easy it actually is. It appears that you don't need any special 'mac-friendly' RAM or even that much technical knowledge, just a few magic numbers and some free time to enter them into OpenFirmware.
What OpenFirmware actually is, in large part, is a neat way to modify hardware description passed to the operating system kernel on boot. This hardware description is a tree-like structure called OpenFirmware Device Tree. The funny thing is, this is quite an open standard, and one still in very wide use today. If you have an Android phone, chances are, it uses the same old Device Tree specification to pass hardware description to the Linux kernel, which works under the hood of Android. Time is a flat circle.
But enough with the history lessons. What we're going to do is modify the 'memory' node of the device tree, which describes the memory layout of the system. More specifically, the 'reg' property of the 'memory' node, which is passed to the operating system and lets the operating system kernel know how much memory there is in the machine, or, in fancier terms, which portions of the physical address space it can safely address without going out of bounds of actual memory capacity.
Getting your current memory mapping configuration
First of all, boot into OpenFirmware and enter the following commands:
Code:
dev /memory
.propertiesThis will display all the properties of the 'memory' node, which is directly under the root node, '/'. One of the properties will be called 'reg' and it will look a bit like this:
Code:
00000000 00000000 40000000
00000000 40000000 40000000
00000001 00000000 80000000
00000001 80000000 80000000
00000002 00000000 80000000
00000002 80000000 80000000
00000000 00000000 00000000
00000000 00000000 00000000Initial memory mapling configuration & plan of action
Now, if you were to take the door off of my G5, remove the front fan assembly, and look at how the RAM sticks are physically situated in the machine, my RAM configuration would look a bit like this:
Code:
4GB (slot 4A)
2GB (slot 3A)
2GB (slot 2A)
1GB (slot 1A)
----
1GB (slot 1B)
2GB (slot 2B)
2GB (slot 3B)
4GB (slot 4B)OpenFirmware, however, does not count RAM slots from top to bottom, it counts them from the center outwards, as numbered in the braces. So, to OpenFirmware, my RAM configuration looks a little bit like this:
Code:
1GB (slot 1A)
1GB (slot 1B)
2GB (slot 2A)
2GB (slot 2B)
2GB (slot 3A)
2GB (slot 3B)
4GB (slot 4A)
4GB (slot 4B)And that is what we see in the 'reg' property, if we squint and look hard enough:
Code:
00000000 00000000 40000000 //1GB (slot 1A)
00000000 40000000 40000000 //1GB (slot 1B)
00000001 00000000 80000000 //2GB (slot 2A)
00000001 80000000 80000000 //2GB (slot 2B)
00000002 00000000 80000000 //2GB (slot 3A)
00000002 80000000 80000000 //2GB (slot 3B)
00000000 00000000 00000000 //4GB (slot 4A)
00000000 00000000 00000000 //4GB (slot 4B)Each line of the 'reg' property contains: two 32-bit integers which are combined into one 64-bit integer to get the offset of a usable address space segment in the physical memory address space of the machine, and a 32-bit integer which indicates the size of that segment.
Here, you should understand one important point. By the time OpenFirmware boots, the 4GB sticks are already properly initialized and available to the system should it decide to use them. It simply does not do that, because it has not been passed the correct 'reg' property.
Now, OpenFirmware tries to configure the 'reg' property by simply estimating where each of the DIMMs should end up in the physical address space after initialization (failing the process for the 4GB DIMMs). But, crucially, the size of a segment in the 'reg' property does not have to be an actual size of any actual RAM stick. You can split one RAM sticks into two segments. You can group many RAM sticks together into one segment. As long as you cover the desired amount of usable address space with the segments, and as long as they don't intersect, you're fine.
One additional thing to note is that OpenFirmware spits out and interprets the size and offset values in hexadecimal notation, which is why
1 GB is 40000000 bytes: 40000000 bytes (hex) = 4 * 16 ^ 7 bytes (decimal) = 1,073,741,824 bytes (decimal) = 1*1024*1024*1024 bytes (decimal).We see in our 'reg' property configuration that the address slace of the 4GB sticks isn't being properly represented by OpenFirmware. My best guess as to why is that the size which OpenFirmware wants to map into the machine address space exceeds the limit of the 32-bit integer. It wants to map
00000001 00000000 bytes, at which point it probably freaks out in one way or another and the result is zero mapped bytes.We're going to fix this by overwriting the 'reg' property and manually inserting the physical address space segments which will represent our 4GB DIMMs.
Coming up with corrected memory mapping configuration
To make reading hex math easier on your eyes, from this point on, I'm going to be putting spaces inside numbers in strategic places, like this:
4000 0000. This is meant to read 40000000. Keep this in mind.Before we start, there is one cardinal rule for coming up with your own configuration, which is that there should be a two-gigabyte-sized hole in your configuration starting at the two-gigabyte offset, meaning you should never use addresses from
8000 0000 to 1 0000 0000.This is the so-called "I/O hole". The processor actually communicates with peripherals by reading from and writing to addresses from that range. If you put addresses from this I/O hole range into the 'reg' propety, you're essentially telling the operating system kernel to treat peripherals as RAM. In practice, this just means that the system will crash at some point when booting the OS, as when you write sensetive kernel code to your mouse, it doesn't tend to stick around.
The easiest way out of this problem is to just put your smallest RAM sticks into the first slots, like I did, and use the values which OpenFirmware automatically generates for you until you reach the first unrecognized stick, which at this point you will be wanting to map to an offset higher than
1 0000 0000, since the address space lower than it or slightly higher than it will have already been taken up by lower-capacity DIMMs.But anyways, for me the proper 'reg' property looks something like this:
Code:
00000000 00000000 40000000
00000000 40000000 40000000
00000001 00000000 80000000
00000001 80000000 80000000
00000002 00000000 80000000
00000002 80000000 80000000
00000003 00000000 80000000
00000003 80000000 80000000
00000004 00000000 80000000
00000004 80000000 00000000You can see from my configuration that I've mapped the first 4GB stick right after where the last 2GB stick ends (
2 8000 0000 + 8000 0000 = 3 0000 0000 in hex), and I've split it in two segments of length 8000 0000 which combined span from 3 0000 0000 to 4 0000 0000. I then did the same for the second 4GB stick, splitting it into two segments which combined span from 4 0000 0000 to 5 0000 0000. This configuration was suggested to me by @joevt, and @joevt is also the one who clarified the actual meaning of the 'reg' property, which is now incorporated into this guide.When coming up with your own configuration, I find that it is easiest to count in terms of gigabytes. As we've already established,
4000 0000 bytes (hexadecimal notation) is 1 GB. This means that 8000 0000 bytes (hex) is 2 GB and 1 0000 0000 bytes (hex) is 4 GB.Also,
2000 0000 bytes (hex) is 512 MB, 1000 0000 bytes (hex) is 256 MB, 800 0000 bytes (hex) is 128 MB, and so on.My assumption is that the current theoretical memory maximum for the G5 (28 GB) can be reached with the following configuration (this configuration is untested, as I currently do not have the RAM to test it):
Code:
00000000 00000000 80000000 //2GB (slot 1A) -- required to boot into OpenFirmware
00000001 00000000 80000000 //2GB (slot 1B) -- required to boot into OpenFirmware
00000001 80000000 80000000
00000002 00000000 80000000 //4GB (slot 2A)
00000002 80000000 80000000
00000003 00000000 80000000 //4GB (slot 2B)
00000003 80000000 80000000
00000004 00000000 80000000 //4GB (slot 3A)
00000004 80000000 80000000
00000005 00000000 80000000 //4GB (slot 3B)
00000005 80000000 80000000
00000006 00000000 80000000 //4GB (slot 4A)
00000006 80000000 80000000
00000007 00000000 80000000 //4GB (slot 4B)And if you can find a pair of 4GB memory sticks which get recognized by the PowerMac G5 without OpenFirmware trickery, the theoretical maximum goes up to 32 GB.
Now the question is, how do you actually overwrite the reg property?
Applying new memory mapping configuration
First, remove spaces and newlines from your desired configuration, so that it looks like one continuous string:
Code:
000000000000000040000000000000004000000040000000000000010000000080000000000000018000000080000000000000020000000080000000000000028000000080000000000000030000000080000000000000000000003800000008000000040000000080000000000000048000000080000000We will refer to this string of as
<configuration>.Now, simply enter the following code into OpenFirmware, taking care to replace
<configuration> with your configuration string:
Code:
dev /memory
" "(<configuration>)" encode-bytes " reg" propertyYou can then verify that you've entered the configuration correctly by re-entering the code from the begginning:
Code:
dev /memory
.propertiesIf you see that you've made a mistake, you can use up/down arrow keys to go back to the command with the mistake and edit it. Verify again, and, when you're ready, simply type in
mac-boot to continue normal boot. If you prefer to select the OS before booting, enter multi-boot instead.Final words
As for me, after going through these steps, I've been able to get the full 18GB I have in the system working with both Gentoo Linux I've been experimenting with as of late and Sorbet Leopard. Not that I need it, per se, but it is both fun and absolutely ridiculous.
Good luck!
Last edited:
