That one works a lot better than the older version I found.
Let me know if the attached is what you were asking for above.
Let me know if the attached is what you were asking for above.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
A Quick Start Guide to G5 RAM Shenanigans: To 18GB... And Beyond!
- Thread starter Nullcaller
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Perfect.
You typed:
load-base load-size evaluate lspciwhich responded with:
select a pci devicebecause the
lspci command that you added at the end of that command line expects to be executed after the active package is set to a PCI host controller.The correct command sequence is:
load-base load-size evaluatedev agplspcidev pci1lspcidev pci2lspciI attached the lspci parsed info for your dump.
It has one mistake for the
00:14.0 CardBus bridge PCI device (/pci@f2000000/cardbus@14 in the Open Firmware device tree).My "lspci for Open Firmware" is missing code to distinguish between a normal PCI bridge and a CardBus bridge so it assumes the bridge has PCI bridge BARs at register 0x10 and 0x14 instead of the single CardBus bridge BAR at 0x10.
The
reg property in your dump-device-tree output says there's a BAR like register at 0x44 and 0x98? I need to look at the PC Card Standard..10h is "CardBus socket/ExCA base address". The reg property says this is relocatable, non-prefetchable, memory. It is always 4K.
44h is "16-bit PC Card legacy mode base address". The reg property says this is relocatable, non-prefetchable, I/O. It is always 4 bytes. It only exists when the function number is 0.
The "PCI1510 GGU/GVF/PGE/ZGU/ZVF PC Card Controllers" Data Manual says 94h-9Ch is reserved.
https://www.ti.com/lit/ds/symlink/pci1510.pdf?ts=1780369429792
The "PCI1510 Implementation Guide" document says 94h and 98h were related to centralized or distributed DMA which is no longer supported in the latest versions of the PC Card Standard (beginning with 7.2 in November 2000).
https://www.ti.com/lit/an/scpa035/scpa035.pdf?ts=1780440970936
I can't find the PC Card Standard 7.1 or earlier.
The "PCI4410A GHK/PDV PC Card and OHCI Controller" Data Manual documents the DDMA registers 94h and 98h
https://resources.ampheo.com/static/datasheets/texas-instruments/pci4410aghk.pdf
98h is "Socket DMA register 1". The reg property says this is relocatable, non-prefetchable, below 64KB, I/O. It is always 16 bytes.
I’m glad to have finally succeeded in generating the requested info!
Does this get us any closer to determining if this machine is capable of addressing more than 2GB of RAM?
Does this get us any closer to determining if this machine is capable of addressing more than 2GB of RAM?
No. The point of getting this PCI info was to see if there was anything in the PowerBook5,9 that looked like the CPC945 of the Quad G5.
It's mostly Apple proprietary chips doing the memory controlling, so I'll probably have to stick with https://forums.macrumors.com/thread...gans-to-18gb-and-beyond.2482947/post-34609975 as my best analysis for your situation. It is very unlikely that any 32-bit Power Mac had a memory controller that allowed assigning addresses beyond the 2 GiB limit.
I've attached a new version of "lspci for Open Firmware" that should produce better results for CardBus bridges. Please give it a try.
Updated, see https://forums.macrumors.com/thread...gans-to-18gb-and-beyond.2482947/post-34613425.
Last edited:
Well, that's disappointing but I'm no worse off than I was before.
I've attached the output you asked for above.
I've attached the output you asked for above.
Thanks. The output looks correct now for the two CardBus bridge registers 44h and 98h.
I updated the ParselspciFromOpenFirmware.sh script to handle those two registers and attached the results for your PowerBook5,9.
Update: Find a link to lspci for Open Firmware at https://tinkerdifferent.com/threads/erics-apple-network-server-700-tinker-log.3987/post-41227
Last edited:
This was a week ago now, and now, which is a week later from a week ago, I have these eight beauties:
Now, nothing really changed between now and when people tested PC2-4200P RAM in a PMG5 years ago, so yes, it doesn't actually work:
- 2 5300P sticks in symmetrical slots on their own -> three telephone beeps
- 2 5300P sticks in symmetrical slots with 2 4200U sticks also in symmetrical slots -> three telephone beeps
- 1 5300P stick with 2 4200U sticks in symmetrical slots -> startup bong, but the stick doesn't get mapped
It's probably just Apple being Apple and arbitrarily deciding you don't want ECC RAM there, especially since at that point they would've probably known that there will eventually be a Mac Pro, and it would've been beneficial for them to go 'oh, look, the Mac Pro even has ECC, what an innovative new feature'.
But anyway, that might not really matter. @joevt, am I correct in assuming that OpenFirmware doesn't have anything to do with initializing the DDR controller? My understanding from reading the "PowerPC 970MP RISC Microprocessor and CPC945 Bridge and Memory Controller Design Guide" is that this is done by the service processor, a.k.a the SPU.
If that is indeed the case, then dumping SPU firmware would potentially allow a rewrite of the part of the firmware that intializes the DDR controller, with proper ECC detection and configuration. It also just so happens that I am currently in possession of two pretty much dead PMG5 boards, so, you know, zero problems with figuring out where to get the firmware from.
The only two questions would then be:
- Whether or not the SPU firmware is protected from reading/writing (probably yes)
- If it is, whether or not the timing attack on flash protection (suggested by @Andrew-R) for M16C/6N5 works on M16C/28 (probably also yes)
(And yeah, no, it's not that anybody needs it, not even me. It's just fun. And also, I've reasons to dump SPU furmware anyway. Which, in large part, is that it's just fun)
Last edited:
Open Firmware is compressed in ROM and runs in RAM, so RAM must be setup before then.
I don't know what an SPU is. Open Firmware has a couple mentions of it. "Pulsar" (SPU) Open Firmware fcode image begins at offset 923e8 in my dump. Search for "detokenizing start at offset 0923F8" in Part2.of.
I posted a disassembly of the HwInit code from the firmware of the Quad G5 and all of the Open Firmware code at
https://forums.macrumors.com/thread...gans-to-18gb-and-beyond.2482947/post-34604974
and pointed out how to find where it accesses the memory controller registers.
Somewhere in that code must be a method to read the SPD from i2c, and then more code to check some offsets in the SPD to calculate the sizes.
There's a disassembly of the Beige G3's code that reads SPD from i2c. I imagine the Quad G5 code does something similar, though the version/contents of SPD is different and the i2c controller is different.
https://github.com/dingusdev/dingusppc/issues/170#issuecomment-4149686924
In Open Firmware the SPD for the DIMMs can be read using this:
Code:
" /u4@0,f8000000/i2c@f8001000" select-dev
h# 100 buffer: buf
cr 80 0 do buf 80 i 2* 0 read-i2c-at ?dup if i 2* 2 u.r buf swap dump cr then loopThe SPD for the 8 DIMMs is at addresses 0xa0, 0xa2, 0xa4, 0xa6, 0xa8, 0xaa, 0xac, 0xae. 128 bytes each.
The i2c Controller is keywest-i2c and compatible with uni-n-i2c. I guess the i2c relates registers are between 0f8001000 and 0f8001fff.
The Open Firmware code explains how the i2c works. 0f8001003 is i2c-base. I guess you can find a PPC assembly version in HwInit.
Thank you!
SPU (or SMU in earlier PMG5 revisions), also called service processor by IBM, is a microcontroller, which does the very early initialization of the system. It also probably controls the fans (at least, in iMac G5 the SPU does, we don't have a schematic for PMG5, so that's the closest thing to it). It has some 100KB of flash memory for program (96K) and data (4K) storage and 8KB of RAM, as well as an M16C/60 series core.
My current understanding of the system initialization sequence is as follows:
- The SPU gets power to it and starts up the moment you plug the power cable into the back of the PMG5.
- There is a power button signal which is normally pulled to high (like 3.3V) logic level by a 1~100 kOhm resistor. When you press the power button, this signal gets shorted to ground. This signal is connected to the SPU, so pressing the power button results in the power button signal going from high to low.
- The SPU is set up to monitor this transition, so it generates an interrupt in the SPU.
- The interrupt handler function calls some initial setup functions.
- Judging by the click that happens every time you turn on a PMG5, the SPU tells the PSU to switch on a one or more voltages.
- The SPU deasserts RESET signals from the North Bridge (U4), the Mid Bridge (Shasta) and the South Bridge (Vesta).
- The SPU configures HyperTransport links between the North Bridge, the Mid Bridge and the South Bridge, if configuration is required there (with those high-speed interfaces, it usually is). After HyperTransport links are established, OpenFirmware flash (also known as BootROM) is accessible from the North Bridge, and will be accessible to CPUs once those are initialized.
- The SPU reads the DIMM SPD using the North Bridge and initializes the North Bridge memory controller according to the DIMM layout.
- The SPU gathers information about the processors from the processor boards. I am as of yet unsure whether the processor board just has an EEPROM with what I presume is information about the processor like in early PMG5s or it has something more complex, like a whole microcontroller that stores that information, as well as doing some other things. (The problem is, pretty much no chips on the processor board have publicly available datasheets)
- The SPU configures the Processor Interface bus on one or two processor dies, as well as the North Bridge.
- The SPU then presumably loads into RAM some sort of shim (the point of which is to decompress and load OpenFirmware into RAM) at some sort of default reset vector address.
- Once everything is ready, core clock is started and shim execution begins.
Pulsar is actually an entirely different thing. My understanding of it is that it's just an Apple-specific ASIC which generates the clock signals for the whole system and is controlled by the SPU. The Late 2005 PMG5 actually uses the second revision, 'Pulsar 2', whereas the earlier ones use plain old 'Pulsar'. So whenever you see anything pulsar, it's probably fair to assume it has something to do with clocks.
Thank you! I took a quick look, didn't understand much, to be perfectly honest, but it seems like there's a lot of stuff in OpenFirmware that can maybe help experiment with the SPU. At the very least, it can maybe help poke it a bit to understand its behavior.
I'm also attaching the Power-On Reset application note and the design guide here if you ever feel like you want to take a look
The Open Firmware code mentions an fcode driver image named "SPU" but it is not included in the firmware for the Quad G5. Apple made their later firmwares universal, but since 4.5.5d5 (for 32-bit) or 514f0 (for 64-bit), the firmware includes only fcode images required by the Mac model that the firmware is being installed to.
Apple Developer Notes at:
https://leopard-adc.pepas.com/documentation/Hardware/hardware2.html
But it doesn't mention the G5 with PCIe slots. For that you have to go here:
https://leopard-adc.pepas.com/referencelibrary/HardwareDrivers/idxAppleHardware-date0.html#doclist
Which shows there's only an HTML version for the Quad G5
https://leopard-adc.pepas.com/docum...G5_05Oct/Introduction/PwrMacG5-0510_pref.html
It's very short and makes many references to other documents.
It has SMU but no mention of SPU.
I don't have a firmware updater for the Quad G5. Earlier firmware updates include an fcode image in the installer with one of these names:
SPU.1.1.1f0
SPU.1.1.1f1
SPU.1.1.4f1
SPU.1.1.6f1
I've attached a dump for SPU.1.1.6f1 from ROM 5.1.8f7 Power Mac G5 (June 2004) Firmware Update.
This fcode image is run by the installer and is not included in the installed firmware.
Another fcode image that is run by the installer and is not included in the installed firmware is "mpu-i2c".
The Dual/Quad G5 ROMs 5.2.7f1 have drivers named "SMU". One main SMU driver and many drivers for sub-devices of the SMU.
Older firmwares (starting from 4.8.5f0) have SMU related code but they are in drivers that don't include the name "SMU". In this case SMU is a variant of PMU. The model specific firmware drivers will set a PMU instance handle if they have a PMU driver or an SMU instance handle if they have a SMU driver.
The only dumps I have that set the SMU handle are these:
ROM 5.1.7f1 Xserve G5 Firmware Update
ROM 5.1.8f7 Power Mac G5 (June 2004) Firmware Update
ROM 5.2.7f1 0x22c2.02 G5 Quad (includes Dual Core).
has-smu? is a bit in the config block, byte offset 0xC bit 7 (the MSB of the byte). I've included config blocks from all the firmware updates that I can parse (not the latest ones). Every firmware dump has a config block from the machine the firmware dump came from. The config block structure is documented in a pdf but compare with code from Open Firmware to be sure the documuent matches the contents.https://68kmla.org/bb/threads/imac-g3-dv-cpu-swap-just-a-few-steps-away.51982/post-586676
https://68kmla.org/bb/threads/imac-g3-rev-a-c-g4-cpu-upgrade.5043/post-563600
Byte 0xc of config block according to Open Firmware 5.2.7f1:
Code:
0 64bit-mem-mode?
1 reg-cke?
2 reg-cs?
3 reg-dimm?
4 on-board-processor?
5 needs-cke-timing-adjust?
6 needs-cs-timing-adjust?
7 has-smu?Update lspci for Open Firmware (see link at https://tinkerdifferent.com/threads/erics-apple-network-server-700-tinker-log.3987/post-41227 ).
Fixed a couple bugs.
Added an
For Power Mac G5 with PCIe, added
Fixed a couple bugs.
Added an
lspci-all command to get pci info from all pci hosts automatically so you don't need to use dev pci or " pci" select-dev for each host.For Power Mac G5 with PCIe, added
lspcie-all command. This gets extended config space registers (all 4096 bytes) for all PCI devices. On the Quad G5, this is only valid for the PCIe graphics slot. The other 3 PCIe slots don't have a method to get PCIe registers (uses "HyperTransport™ I/O Link Specification" Revision 1.04 instead of "HyperTransport™ I/O Link Specification" Revision 1.05?) so the first 256 bytes is just repeated 16 times.