• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Why is the G4 limited to 2GB Ram? Boot rom? Firmware? Memory Controller? Could that be patched?

Question is basically explained in the title.

I know that 2GB is plenty for the old Software running on my MDD. But just like overclocking the CPUs to 1.6GHz from 1.4.... Like it's fun to tinker, and i guess we can all agree with that.

I currently have two 1GB DDR 400 crucial gamingX sticks (with a baby blue metallic headspreader haha. Got them NOS for 8€) in my MDD. Runs fine, but i got more ram here that the System wont address.

Is this a physical limitation, like the memory Controller, or "just" Software, Firmware/boot Rom etc?
Could that theoretically be patched or modded? Just for fun?
 
It’s almost certainly because the G4 is just a 32-bit CPU. Although the physical address bus is >32-bits, it’s quite possible Mac OS X to 10.4 doesn’t use it, hence 4GB is the practical limit and the top 2GB is reserved for IO.

The Intel 32-bit Core Duo Macs have the same limitation despite coming out after the G5 Macs.


This means the iMac G5 2.1GHz released in 2005 had a limit of 4.5GB, but the iMac Core Duo in 2006 was also limited to 2GB.


The Quad Core power Mac G5 (2005) could handle 16GB.

 
It’s almost certainly because the G4 is just a 32-bit CPU. Although the physical address bus is >32-bits, it’s quite possible Mac OS X to 10.4 doesn’t use it, hence 4GB is the practical limit and the top 2GB is reserved for IO.

The Intel 32-bit Core Duo Macs have the same limitation despite coming out after the G5 Macs.


This means the iMac G5 2.1GHz released in 2005 had a limit of 4.5GB, but the iMac Core Duo in 2006 was also limited to 2GB.


The Quad Core power Mac G5 (2005) could handle 16GB.

I completely get the 32 bit limitation. But why is the G4 then limited to 2 instead of 4GB?

A Pentium 4 System could also use 4GB RAM. So could 32 bit Arm
 
Last edited:
You can install 4GB of RAM on a P4 system, but the system overhead takes up space and each GPU sucks up 128 or 256MB windows so usable memory is lower.
 
I completely get the 32 bit limitation. But why is the G4 then limited to 2 instead of 4GB? A Pentium 4 System could also use 4GB RAM. So could 32 bit Arm
It's dependent on the OS design.

For example, some versions of Windows e.g. XP don't use Physical Address Extensions, so they're limited to 4GB of RAM - IO space, which typically means just 3.5GB RAM max.

ARM32 up to v7 only supports up to 4GB of RAM, but v7A supports a similar Physical Address Extension in a similar way to Intel:


But all of this is just a hack. Even if a 32-bit CPU has some kind of PAE, it can't easily address that memory, because it only has 32-bit pointers. Instead the way it ends up working is that physical RAM beyond 4GB must be managed so that for any process ProcessRAM+AddressSpaceSharedWIthOtherProcesses(e.g. DLLs)+SystemAddressSpace+AnyIOAddressSpace <= 4GB.

Otherwise, you can't distinguish all the memory locations with a 32-bit pointer. To fit it all in, e.g. processes get sandboxed; shared DLL space gets limited; IO is abstracted (so you can't access it at all) + SystemAddress space is all kernel side.

In Mac OS X for PPC it's just simplified to only supporting 2GB with the upper 2GB for IO and ROM. There's no 3GB RAM + 1GB IO option; nor even 3.5GB RAM + 0.5GB IO either.

It's a common problem/solution. The pdp-11 only supported 16-bit virtual addresses even though it could support 22-bit physical addresses. IO was confined to the top 8kB, but typically a user program had no access to it (but that did mean it could address 64kB of data + 64kB of code space). ARM26 supported 26-bit virtual addressing, but only 4MB of physical addressing per MMU. The 8086 supported 1MB of 'real' address space, but the IBM PC limited that to just 640kB (leaving 384kB for IO space). Later "Expanded" memory used a banked memory technique to fit several MB into a 64kB window in that 384kB slot. The 80286 supported 1GB of virtual memory, but only 16MB of physical memory, but I understand the IO system was still crammed into that 384kB slot on a PC.
 
Most of the addresses should appear in the Open Firmware device tree.
dump-device-tree

2 GiB is 0x80000000
2.5 GiB is 0xA0000000
3 GiB is 0xC0000000
3.5 GiB is 0xE0000000

Are there any I/O addresses in the range you want to use for RAM? Can those I/O addresses be changed?
PCI addresses can be changed but can all of them be changed?
Are there addresses that are not PCI that need to be changed? Maybe there's a different way to change them.
ROM is usually the last MiB of the address space so that doesn't need to be changed but PCI addresses cannot overlap.

Does the memory controller support more than 2 GiB of RAM?
Does the firmware?
Does the OS?

An emulator like DingusPPC is a good way to try patches for firmware and OS but the only machine it emulates that supports more than 1 GiB of RAM are the TNT machines (Power Mac 7500-9600 - 1.625 GiB). It only supports New World Macs iMac G3 and B&W G3 (1 GiB of RAM) but it might be possible for them (and Beige G3) to use 2GiB of RAM using a ROM patch and changing the MPC106 memory controller to support more address bits per RAM bank (by using unused bits). If you can get 2 GiB working, then maybe you can get 3 GiB. I suppose if you have 3 GiB of RAM you can probably use a subset of that (say 2.5 GiB) if you need to use more for PCI or other I/O.
 
If you're comfortable with QEMU, you could also try hacking at the pmg4 virtual hardware to try different configurations; the results wouldn't be guaranteed to match any real hardware, but it's a good first step to see where things break before committing to tweaking actual hardware and OF configurations.
 
In Mac OS X for PPC it's just simplified to only supporting 2GB with the upper 2GB for IO and ROM. There's no 3GB RAM + 1GB IO option; nor even 3.5GB RAM + 0.5GB IO either.

This isn't _completely_ accurate, in that Power Mac G5s (as of the final iteration) could physically support up to 16 GiB when 64-bit addressing is active (i.e., for command-line software under Tiger, or in general under Leopard). I don't know whether there were any software limitations associated therewith.

Does anyone know whether 32-bit software on a G5 could use more of the 4GiB window than the otherwise-hard 2G limit?
 
The MacRISC architecture as defined by Gary Davidian pretty much sets the 2GB limit. Initially because NuBus takes almost 2GB of space for a 6-slot machine, and then they just didn't change that when PCI happened.
 
This isn't _completely_ accurate, in that Power Mac G5s (as of the final iteration) could physically support up to 16 GiB
I should have clarified I was only talking about 32-bit PPC. I had done a previous search on EveryMac for Mac OS X RAM limits on the 32-bit PPC and Intel CPUs, it's always 2GB.

The MacRISC architecture as defined by Gary Davidian pretty much sets the 2GB limit. Initially because NuBus takes almost 2GB of space for a 6-slot machine, and then they just didn't change that when PCI happened.
OK, thanks. Do you have a link to the actual 68K emulator source code? I found a link to the project (I forget the name) that has quite a lot of the Davidian ROM nano-kernel. Is that what you're referring to? Also, I know PCI has a tree structure, but do PCI cards just take up the IO space they need then? (given that RAM can reach 3.5GB on 32-bit Windows on a PCI PC).
 
Do you have a link to the actual 68K emulator source code?
The 68K emulator is at 0x68000000 (1.5 GiB + 128 MiB) but I don't think it matters for Mac OS X.

Also, I know PCI has a tree structure, but do PCI cards just take up the IO space they need then? (given that RAM can reach 3.5GB on 32-bit Windows on a PCI PC).
PCI devices have BARs (base address registers) that indicate the address and size of the memory region. The size determines the possible addresses. A 1 GiB BAR needs to be on a 1 GiB boundary. That leaves only 4 possible addresses it can use in a 32-bit system: 0x00000000, 0x40000000, 0x80000000, 0xC0000000. That's why BARs are usually 512 MiB or less. The first PCI Macs have firmware that has BARs limited to 128 MiB. Mac OS adds a nvramrc patch to support 256 MiB. Later Power PC Macs support 512 MiB max. I created a patch for earlier Macs to support 512 MiB. I suppose a patch to support 1 GiB might be possible but probably only one of those could be supported using address 0x80000000 unless 0x4000000 is usable? 0x00000000 would cover exception vectors and RAM and 0xC0000000 would cover macio and ROM.

The tree structure of PCI refers to when you have PCI-PCI bridges.

First of all there are PCI Host bridges which connect to the CPU/memory bus on the host side and PCI devices on the downstream side. The PCI Host Bridge might have limits to its supported address range. In DingusPPC, the PCI Hosts are Bandit/Chaos/AspenPci and MPC106/Grackle.

Any BAR of a PCI device connected to a PCI Host bridge can have an address anywhere the BAR and the PCI Host bridge supports.

Next you have PCI-PCI bridges which can connect multiple downstream PCI devices to a single slot of an upstream PCI Host bridge or an upstream PCI-PCI bridge. The address ranges supported by a PCI-PCI bridge are stored in the I/O, Memory, and Prefetchable memory behind bridge address range registers. Downstream memory ranges have to fit in the upstream memory ranges. For this discussion, you can ignore I/O memory ranges since those don't use CPU memory addressing.

You can use sudo lspci -nnvvv (from my pciutils fork for Mac OS X) to get a list of all devices and the starting address of BARs and the address ranges of bridges.

To get the size of BARs, you can use my lspci for Open Firmware script which gathers the info which can be parsed by a shell script that uses lspci.

For example, a Radeon 7000 has these BARs reported by lspci:
Code:
	Region 0: Memory at 88000000 (32-bit, prefetchable) [disabled]
	Region 1: I/O ports at 0400 [disabled]
	Region 2: Memory at 80a00000 (32-bit, non-prefetchable) [disabled]
	Expansion ROM at 80a20000 [disabled]

My lspci for Open Firmware script will add this info for each BAR:
Code:
	00006810:88000008.f8000008 Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
	00006814:00000401.ffffff01 Region 1: I/O ports at 0400 [size=256]
	00006818:80a00000.ffff0000 Region 2: Memory at 80a00000 (32-bit, non-prefetchable) [size=64K]
	00006830:80a20000.fffe0001 Expansion ROM at 80a20000 [disabled] [size=128K]

A PCI-PCI bridge will have these regions:
Code:
00:0e.0 PCI bridge [0604]: Actiontec Electronics Inc Mini-PCI bridge [1668:0100] (rev 11) (prog-if 00 [Normal decode])
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 1000-1fff [size=4K] [16-bit]
	Memory behind bridge: 80800000-808fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: 80800000-807fffff [disabled] [32-bit]

A PCI device connected to that bridge must have it's BARs inside that bridge's behind ranges:
Code:
01:00.0 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 41) (prog-if 10 [OHCI])
	Region 0: Memory at 80803000 (32-bit, non-prefetchable) [disabled]
	00010010:80803000.fffff000 Region 0: Memory at 80803000 (32-bit, non-prefetchable) [size=4K]

The [disabled] qualifier comes from the memory and I/O enable bits of the control register.
Code:
	Control: I/O- Mem-
 
The 68K emulator is at 0x68000000 (1.5 GiB + 128 MiB) but I don't think it matters for Mac OS X.
Thanks, I was just curious.
PCI devices have BARs (base address registers) that indicate the address and size of the memory region.
OK, cool, thanks.
<snkp> you can ignore I/O memory ranges since those don't use CPU memory addressing.
I was assuming all PCI I/O was memory-mapped anyway, since most architectures (apart from x86/x64) don't have a specific I/O address space and it'd have to be mapped to memory too. Also the 80386 still only had a 16-bit I/O address space.

Oh, BTW: thanks for all the effort and explanation, my knowledge of PCI is pretty much next to nothing.
 
I was assuming all PCI I/O was memory-mapped anyway, since most architectures (apart from x86/x64) don't have a specific I/O address space and it'd have to be mapped to memory too. Also the 80386 still only had a 16-bit I/O address space.
The Bandit PCI host has a memory mapped range for I/O addresses. It's 8 MiB (23 bits) instead of 16 bits.

Macs that use Grackle PCI host (MPC106) use Address Map B. Address Map B has a memory mapped range for I/O addresses that is 12 MiB but is split into a 64 KiB part at offset 0 and a 4 MiB part at offset 8MiB. DingusPPC allows only 16 bits currently.
 
The Bandit PCI host has a memory mapped range for I/O addresses. It's 8 MiB (23 bits) instead of 16 bits.

Macs that use Grackle PCI host (MPC106) use Address Map B. Address Map B has a memory mapped range for I/O addresses that is 12 MiB but is split into a 64 KiB part at offset 0 and a 4 MiB part at offset 8MiB. DingusPPC allows only 16 bits currently.
Gosh. NuBus was a lot simpler! If only they (i.e. Intel/Microsoft) had chosen that, and upgraded it to PCI performance! Anyway, thanks for the DingusPPC ref too!
 
Seems to not matter anyways, tried booting my MDD and the 1,42 GHz dual CPU (overclocked to 1,58) appears to be dead. Completely, from one wday to the other.
My dual 1,08 (originally 867mhz) works....
 
I should have clarified I was only talking about 32-bit PPC. I had done a previous search on EveryMac for Mac OS X RAM limits on the 32-bit PPC and Intel CPUs, it's always 2GB.

I remember the 32-bit Core Duo machines were limited to 2GB RAM but had always assumed it was artificial, because the Core 2 Duos that followed could address up to 3GB. I think they were 64-bit CPUs but some parts of the architecture weren’t 64-bit clean, as it were, so were still subject to the 32-bit, 4GB limit (with 1GB lost to overheads).

I upgraded a Core Duo Mac Mini with a Core2Duo CPU and installed newer firmware which raised the RAM limit from 2GB to 3GB - so it clearly was never a chipset limitation.
 
<snip> 32-bit Core Duo <snip> 2GB RAM <snip> Core 2 Duos <snip> 3GB. <snip> some parts of the architecture weren’t 64-bit clean <snip>
From the link below, I think it says the chipset had a 4GB RAM limit.
I upgraded a Core Duo Mac Mini with a Core2Duo CPU and installed newer firmware which raised the RAM limit from 2GB to 3GB - so it clearly was never a chipset limitation.
A brilliant experiment! Was it easy to upgrade? I found this link:


I used to have a MacBook Core Duo with 2GB of RAM until it died in January 2014; so I can't test any of that. My earliest Intel Mac is currently a 2.4GHz MacBook C2D/2.4GHz (dual boot Mac OS X 10.7/Linux).

Trying to put it together as best as I can as yet.
  • @joevt said the reason a G4 can't address more than 2GB is that the Davidian 68K emulator would clash; even though it's not needed in Mac OS X (and I guess even with Classic, it's running from the ROM on HD). So, the 2GB limit could be inherited from 32-bit Mac OS X.
  • The earliest Intel Mac OS X was Tiger which already had some 64-bit addressing support, because G5s were 64-bit and could address up to 16GB.
  • The earliest Intel Mac chipset had a 4GB limit.
So I don't think we have a definitive reason for why the Core Duo Intel Macs were limited to 2GB RAM.
 
  • @joevt said the reason a G4 can't address more than 2GB is that the Davidian 68K emulator would clash; even though it's not needed in Mac OS X (and I guess even with Classic, it's running from the ROM on HD). So, the 2GB limit could be inherited from 32-bit Mac OS X.
I think I said (or implied) that Mac OS X is probably not affected by the 68K emulator because it doesn't use it.

There are roadblocks. The question is, what are they and can they be bypassed (either with firmware or software or hardware changes). An emulator makes it easier because it's all software. e.g. The hardware MPC106 is limited to 1GiB but you can change it in emulation to use more bits. This requires changes to the firmware (which is just a file in an emulator) or the software (just a file in the OS which can be patched or recompiled).
 
Gosh. NuBus was a lot simpler! If only they (i.e. Intel/Microsoft) had chosen that, and upgraded it to PCI performance! Anyway, thanks for the DingusPPC ref too!

I have a fondness for geographically addressed slots like the Apple II and NuBus, but those systems suffer from fixed-size memory partitions per card. The Apple II's were way too small so that all of the later interesting cards circa 1986 were heavily bankswitched. NuBus's partitions were too large. Every card gets 272 MB and I haven't seen a real-world NuBus card use more than 8 MB of that space. (The "image card" in MAME that Rob Braun designed does use 256 MB, but that's not a card that physically exists). The smallest possible PCI BAR is 16 bytes (amusingly the same as the Apple II /DEVSEL space) so cards can be very efficient.
 
I have a fondness for geographically addressed slots like the Apple II and NuBus, but those systems suffer from fixed-size memory partitions per card. The Apple II's were way too small so that all of the later interesting cards circa 1986 were heavily bankswitched. NuBus's partitions were too large. Every card gets 272 MB and I haven't seen a real-world NuBus card use more than 8 MB of that space. (The "image card" in MAME that Rob Braun designed does use 256 MB, but that's not a card that physically exists). The smallest possible PCI BAR is 16 bytes (amusingly the same as the Apple II /DEVSEL space) so cards can be very efficient.
When I picked up my Apple ][europlus in 1989 (or maybe 1991), I also picked up a bunch of technical manuals, including the hardware architecture describing the slot mechanism.

Which to summarise: there’s a unique memory-mapped IO range for each slot (v tiny); and a shared ROM area (2kB?) which is activated when you jump to an entry point, which itself is slot dependent.

But the upshot was that it was possible to design plug-n-play hardware on the Apple ][, //e and IIgs. And then the PC screwed that up entirely for the best part of 15 years!!!!!

I agree that slots shouldn’t have fixed address ranges though, but all that takes is a means of daisy-chaining initialisations and defining an IO base address. So, eg you could allocate the top 256MiB in 32-bit space to IO and then an 8-bit latch per card would allow cards on a 1MB boundary. And you’d still be left with 3.75GiB free.

That’s no good of course for 64-bit addressed cards, but I guess then you just extend the allocation protocol and provide any missing latch addresses on the host side?
 
Back
Top