it says PowerPC G3 because thats the early OS X's default name for an Unknown CPU (its running in PPC generic mode) I do wonder if I can futz with the PowerLogix OS X 7448 NVRAMRC script to get it to make the CPU pretend to be a 7445 rather then a 7447A as it normally does, but i need to figure out how said script works/what it does exactly first!
(no public OS X version supports the 7448 natively, while earlier OS X versions up to 10.2.8 will boot on an unknown CPU later versions wont, so PowerLogix needed an NVRAM script to get those later OS X versions booting)
here it is for those wondering (note its diffrent to simple just changing the cpu-version property in Open Firmware, as OS X actually checks the PVR it seems rather then just looking at the OF device tree like the Mac OS 8.6/9.x ROM does)
Code:
" "(F1084C2A00000103120A6465766963652D656E64CDA5CA065F2E6C2E72310800B8A5CA065F2E6C2E72320801B812192F6F70656E70726F6D2F636C69656E742D7365727669636573120B66696E642D646576696365CD120B5B275D2071756965736365CDC30800CA07717569657363650802B708001D08011DC2120A6465766963652D656E64CDCA055F2E6C2E720803B7120C00000024FFFF0000800300001000004000B14A4AA74EA74EA74E7AA53C1400205210000000041E4710FFF80000497310800000004910000000041E7333B24A10000000041E471003FFFFF83C14FFC54652C2120470767240CD10FFFF00002310800400003C140009110803C30801B200)" dup -rot alloc-mem dup 2swap -rot move 1 byte-load \
it is interestingly partly some sort of hex string
It's fcode. The
nvramrc script moves the bytes to a buffer in memory and executes it with
byte-load. I'm not sure why they execute as fcode instead of as forth text since the forth text that compiles the fcode appears to be shorter than their nvram script.
I'm not sure what the fcode does. It seems to want to execute the code in
_.l.r after the
quiesce word in
/openprom/client-services is executed but only if the pvr's upper 16 bits are set to 0x8004 which identifies the CPU as 7448, Apollo 8. If it's not an Apollo 8 then the script probably throws an error after
quiesce since they didn't set
_.l.r2 in the non-Apollo 8 case.
Not sure what
quiesce is. Maybe it's what gets executed before transferring to the boot rom file? I am totally guessing.
_.l.r appears to be looking for a string of bytes at 4000 (where the boot rom file is loaded? totally guessing). The string of bytes it's looking for is
0000 0024 FFFF 0000 8003 0000. I think it's changing the last eight bytes to
FFF8 0000 8000 0000. Maybe the first 4 bytes is a mask of bits to modify and the last 4 bytes is the new value for the masked bits.
Totally guessing. I did not google
quiesce, or look at the rom file or examine the fcode very closely.
on the NVRAM script
@DearthnVader took it apart a bit, but I still dont know exactly what its doing
other then obviously we know its tricking OS X into thinking its booting on a 7447A but how exactly it does that I dont know sadly,
Awesome, nice skills. This is what I call hacking. Anyway, I wanted to know what the PowerLogix NVRam patch really does, beyond the binary blob: \ Welcome to detok - FCode detokenizer v1.0.3 \ (C) Copyright 2001-2010 Stefan Reinauer \ (C) Copyright 2006 coresystems GmbH \ (C) Copyright...
forums.macrumors.com
Reading that thread, I see
@DearthnVader did detok the fcode and
@dosdude1 did convert the detok result to fcode. My DumpPCIRom.sh script does it automatically in one step.
@dosdude1's final solution to the nvramrc script was to split the 259 byte string literal into 131 bytes and 128 bytes. Probably a good idea since the string literal buffers are probably limited to 256 bytes and 259 bytes would overflow a buffer possibly causing a hang (3 bytes would overwrite whatever was after the second buffer but only if the string was being placed in the second buffer - the nvramrc script would not have a problem if the string were being placed in the first buffer as it is immediately followed by the second buffer).
I only checked the buffers in Open Firmware 2.4 - I did not try later Open Firmware versions. The way to check this is to create two strings, and dump the stack to see where they were stored.
Code:
" hello"
" there"
" !!!!!!"
.s
We try to occupy 3 buffers. In Open Firmware 2.4, there's only two buffers, so the last string would overwrite the first string. The stack result should show that the first and third string are in the same buffer and that the buffers are 256 bytes apart.
Instead of using alloc-mem, the byte stings could maybe be placed in the dictionary and executed from there?
Code:
" "(1234)" encode-bytes " "(1234)" encode-bytes encode+ drop 1 byte-load
@joevt said something about extra configuration space for PCI-E vs PCI, so the garbled video output is not an unexpected outcome of this testing.
Perhaps he can clarify and elaborate?
What I would be interested in is NVME testing, if we could get a basic NVME driver for Tiger or Leopard we could use the "Helper Drive" to boot OS X.
I don't think extended config space is a problem if it's not used. You can try the lspci for Open Firmware command.
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-31364424
A PCI Express card will have an Express Capability Structure. This has a bunch of PCI express info (lanes, link rate, etc) but I don't think it indicates if a PCIe card uses extended configuration space.
I don't know if it's possible for a PCI host to read from extended configuration space. Maybe there's something in the PCI to PCIe bridge.
I haven't looked at trying to read from extended configuration space on my Quad G5 while in Open Firmware.
I would like to have a version of pciutils that works on PowerPC Macs. It would require a DirectHW.kext port.
when I do have updates to post dont worry ill post em 
