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 them working, @sasho648 came up with a few lines of Forth code which, upon pasting them into OpenFirmware, will properly initialize the sticks.
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 defines how the physical address space of each individual RAM stick is mapped onto the physical address space of the whole system. Or, at least, that's my understanding of it, which seems to make sense.
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:
Making sense of the memory mapping configuration
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 at which the address space of the RAM stick will be mapped into the physical memory address space of the machine, and a 32-bit integer which indicates the size of the RAM stick address space which is going to be mapped. Now, this is not the actual size of the RAM stick. It's simply how much of it we want to map into the machine address space.
One additional thing to note is that OpenFirmware spits out and interprets these values in hexadecimal notation, which is why
But we also see that the 4GB sticks aren't being mapped. My best guess as to why is that the size which they want to map into the machine address space exceeds the limit of the 32-bit integer. They want to map
We're going to fix this by overwriting the reg property and manually mapping a little bit less than the full 4GB onto the address space.
Coming up with corrected memory mapping configuration
There seem to be some rules as to how you're supposed to do this. For example, OpenFirmware automatically maps my two 1GB sticks into the first two gigabytes of the physical address space, but then it skips two gigabytes and maps the two 2GB sticks into the second four gigabyte region of the address space. If you then try to manually 'fix' that, the system will crash at some point when booting the OS.
My best guess is that it can't map more than two sticks to any contiguous four gigabyte region. But to be safe, it's easier to just put your smallest RAM sticks into the first slots, like I did, and use the values which OpenFirmware automatically generates for you instead of experimenting. Do feel free to experiment, though.
But anyways, for me the proper 'reg' property looks something like this:
Now, to make reading hex math easier on your eyes, from this point on, I'm going to be putting random spaces inside numbers, like this:
You can see from my configuration that I've mapped the first 4GB stick right after where the last 2GB stick ends (
I find that it is easiest to count in terms of gigabytes. As we've already established,
Also,
Now, I've recently been testing a slightly different configuration:
Here, more of the RAM stick is utilized. I don't know whether it will work with Mac OS, but it works with my Gentoo install. No memtester errors, no crashes, everything as stable as can be. With this configuration, the system should be able to utilize everything but the last 16MB of each of the 4GB sticks, which to me seems both fine and more reasonable than 'the last 256MB' (as is the case in the previous configuration).
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 pretty much the full 18GB I have in the system working with Gentoo Linux I've been experimenting with as of late. 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 defines how the physical address space of each individual RAM stick is mapped onto the physical address space of the whole system. Or, at least, that's my understanding of it, which seems to make sense.
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 00000000Making sense of the memory mapping configuration
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 at which the address space of the RAM stick will be mapped into the physical memory address space of the machine, and a 32-bit integer which indicates the size of the RAM stick address space which is going to be mapped. Now, this is not the actual size of the RAM stick. It's simply how much of it we want to map into the machine address space.
One additional thing to note is that OpenFirmware spits out and interprets these 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).But we also see that the 4GB sticks aren't being mapped. My best guess as to why is that the size which they want to map into the machine address space exceeds the limit of the 32-bit integer. They want to map
00000001 00000000 bytes, at which point probably OpenFirmware 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 mapping a little bit less than the full 4GB onto the address space.
Coming up with corrected memory mapping configuration
There seem to be some rules as to how you're supposed to do this. For example, OpenFirmware automatically maps my two 1GB sticks into the first two gigabytes of the physical address space, but then it skips two gigabytes and maps the two 2GB sticks into the second four gigabyte region of the address space. If you then try to manually 'fix' that, the system will crash at some point when booting the OS.
My best guess is that it can't map more than two sticks to any contiguous four gigabyte region. But to be safe, it's easier to just put your smallest RAM sticks into the first slots, like I did, and use the values which OpenFirmware automatically generates for you instead of experimenting. Do feel free to experiment, though.
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 F0000000
00000004 00000000 F0000000Now, to make reading hex math easier on your eyes, from this point on, I'm going to be putting random spaces inside numbers, like this:
4000 0000. This is meant to read 40000000. Keep this in mind.You 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), I've limited the size of the stick to 3.75GB (F000 0000 as opposed to full 1 0000 0000), and I've skipped 1000 0000 bytes in between the 4GB sticks. This makes for nice alignment and less bugs. This is pretty much the configuration @sasho648 got working back in the day.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, 1 0000 0000 bytes (hex) is 4 GB and F000 0000 bytes (hex) is 3.75 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.Now, I've recently been testing a slightly different configuration:
Code:
00000000 00000000 40000000
00000000 40000000 40000000
00000001 00000000 80000000
00000001 80000000 80000000
00000002 00000000 80000000
00000002 80000000 80000000
00000003 00000000 FF000000
00000004 00000000 FF000000Here, more of the RAM stick is utilized. I don't know whether it will work with Mac OS, but it works with my Gentoo install. No memtester errors, no crashes, everything as stable as can be. With this configuration, the system should be able to utilize everything but the last 16MB of each of the 4GB sticks, which to me seems both fine and more reasonable than 'the last 256MB' (as is the case in the previous configuration).
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
00000000 80000000 80000000 //2GB (slot 1B) -- required to boot into OpenFirmware
00000001 00000000 FF000000 //4GB (slot 2A)
00000002 00000000 FF000000 //4GB (slot 2B)
00000003 00000000 FF000000 //4GB (slot 3A)
00000004 00000000 FF000000 //4GB (slot 3B)
00000005 00000000 FF000000 //4GB (slot 4A)
00000006 00000000 FF000000 //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:
0000000000000000400000000000000040000000400000000000000100000000800000000000000180000000800000000000000200000000800000000000000280000000800000000000000300000000FF0000000000000400000000FF000000We 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 pretty much the full 18GB I have in the system working with Gentoo Linux I've been experimenting with as of late. Not that I need it, per se, but it is both fun and absolutely ridiculous.
Good luck!
Last edited:
