Radeon HD cards on PowerPC Leopard using osx86-driver-radeonhd framebuffer driver?

[pc297]

Hi everyone,

Since reading up on some open source framebuffer drivers / injectors for hackintoshes (e.g. Callisto, ATY_init), I've been wondering about the possibility of porting those to PowerPC. While I haven't been able to find the source code for Callisto or ATY_init (@netkas might have the latter), I've come across Dong Luo's excellent work on a framebuffer driver for Radeon HD 2xxx-4xxx cards ported from the linux RadeonHD driver, with source code available (osx86-driver-radeonhd):

ATI HD framebuffer driver (10.5/10.6) with source code

Put it into /S/L/E/ and rebuild the cache to test. It will not affect vanilla driver. Any injector will prevent this driver from loading since it works the same way as IONDRVSupport. [FAQ:] 1. get a blank or dark screen after boot, or the screen keep flashing In RadeonHD.kext/Contents/Info.plist,...

www.insanelymac.com

Google Code Archive - Long-term storage for Google Code Project Hosting.

code.google.com

After simply editing OS_Version.h to use the 10.5 IOKit and setting the target architectures properly in the project properties (so far I've only had luck with ppc and i386), I have had some success compiling to powerpc in Xcode 3.1.4 under 10.5.8 (on a G5 Quad), however only using llvm-gcc. I am getting some missing symbols using gcc, I am probably missing some things in OSBundleLibraries for the latter.

Somehow, after compiling with llvm-gcc, at first the kext won't load even after removing S/L/Extensions.mkext, S/L/Extensions/Caches S/L/Caches and rebooting multiple times (kextload -t shows overflow errors). However, after rebooting into another OS (10.6 ppc in my case) and subsequently rebooting into 10.5.8, the RadeonHD extension then loads properly, and RadeonHD cards are correctly detected, but I have yet to get them to display anything.

Both my stock PCIe Radeon HD 4650 and 4870 (PC versions) cards do get recognised under 10.5.8 ppc, with display nubs created, however so far only with a black screen. Their fans, which normally rev up slightly as linux loads (under which they work flawlessly) as activity increases, do not rev up at all. Adding EDIDs to Info.plist (either as base64 or hex) does seem to go slightly further in that displays are shown as connected to the cards, but only in debug mode. The amount of VRAM seems wrong though both using the 4650 (512Mb) or 4870 (1Gb). Both cards are supported as per knownCardList.txt and rhd_id.c. The second last System Profiler screenshot with the 4800 series (actually HD4870) shows what happens when debugMode is set to false. Same result with the HD4650. The display nubs are there, but with nothing seemingly attached to them. The very last System Profiler screenshot is using my HD5770, which, although being detected as display, clearly doesn't seem supported.

I've tried fiddling around with various options, e.g. setting BackLightLevel to 0, enableBacklight to false, @0,UseFixedModes, to true or specifiying @0,TYPE to DACA but no avail. I haven't tried changing forceSwitchCrtc to true yet though, will give it a try. I don't know if getting it to work is just a matter of options in the plist or if deeper issues need to be resolved in Xcode.

Building as debug or release seems to have the exact same effects.

I also haven't compiled RadeonDump to ppc yet to get some proper troubleshooting / logging, but will do as soon as I get a chance. dmesg / verbose boot do show "RadeonHD: creating nubs".

There are several files in the project trunk that are not in the Xcode project that might be needed for hardware support on ppc, notably xf86/Pci.c xf86/Pci.h that seem to have dedicated ppc methods, maybe this is what is missing (notably how the ROM is accessed, as it will be little-endian) ? However trying to include those creates a massive dependency problem, requiring most of the X11/XF86 source code for mac which I don't have (several X11 include files are present in the Developer folder but several other required e.g. Compiler.h are missing).

On the other hand, on the insanelymac forum on the kext, it seems that someone may have made a universal version (however not tested on powerpc) but all versions posted on the forum are intel, would by any chance anyone have this?

ATI HD framebuffer driver (10.5/10.6) with source code

www.insanelymac.com

Or if anyone knows what I might be missing, even though I found these baby steps already encouraging? Or reckons that this has any chance of ever working (or not due to endianness issues that would entail significant rewriting)?

Cheers,

PS: I will post the ppc kext later on today if anyone wants to try it


EDIT: from what I understand, osx86-driver-radeonhd works independently of ATIX2000.kext (anyway not available for ppc, if only <sigh>) and will still result in a useable framebuffer driver in its absence

EDIT2: from what I also understand, under ppc linux, the modern radeon driver will soft-load ROM code with endianness taken into account for correct operation. I don't know if the present driver implements any of this

EDIT3: further to point 2 I have only tried the AtomBIOS version of the driver

 

[pc297]

Here is the 10.5 ppc RadeonHD kext that I could compile with Xcode 3.1.4 using LLVM GCC 4.2 under 10.5.8 ppc. In case anyone wants to give it a try and play around with the options in Contents/Info.plist.

So what "works" for me is the following (without having any display from the Radeon HD card though, but the kext gets it detected):

1: copy RadeonHD.kext to S/L/E
2: change permissions:

sudo chmod -R 755 /System/Library/Extensions/RadeonHD.kext
sudo chown -R root:wheel /System/Library/Extensions/RadeonHD.kext

3: delete kext cache:

sudo rm -Rfd /System/Library/Extensions.mkext
sudo rm -Rfd /System/Library/Extensions/Caches/
sudo rm -Rfd /System/Library/Caches/

4: reboot into 10.5.8

5: (optional, haven't worked out if this is really required) try to load the kext:

sudo kextload -t /System/Library/Extensions/RadeonHD.kext

this should give you an overflow error message

6: reboot under another OS (for me 10.6 10A190)

7: (optional, haven't worked out if this is really required) try to load the kext under 10.6:

sudo kextload -t /Volumes/Macintosh\ HD/System/Library/Extensions/RadeonHD.kext

8: reboot into 10.5.8, you should have the kext loaded and if you have a Radeon HD 2XXX-4XXX card, it should be detected but not displaying anything

I am attaching the universal 10.5 version as well, I haven't tested it under i386 yet, this could help determine whether the build process actually worked or not and whatever kext options need to be set. I guess this might entail getting rid of ATIRadeonX2000.kext & co to make sure it works.

Obviously if anyone has a universal version of it from Dong's insanelymac post, it would be great, let me know!

A 10.6 version should follow using Xcode 3.2, hopefully including ppc, if Xcode works as it should under 10A190 ppc.

Cheers,

EDIT: after further inspecting Contents/Info.plist, it could be that the kext is just missing RadeonDump and RadeonDumpClient, I will try to build those

EDIT2: I can confirm that steps 5 and 7 are not needed

 

[pc297]

So setting forceSwitchCrtc to true doesn't seem to be doing anything. Re RadeonDump and RadeonDumpClient, they do get compiled as objects in XCode but not as executables, does anyone know how to do this in XCode? Using e.g. gcc RadeonDump.o -o RadeonDump gives a missing symbols error message, I guess I need to add -I<include_dir(s)>. RadeonDump.c does not compile though, I am missing several X11/xf86 includes, will look those up.

 

[im_to_hyper]

Awesome work, keep it up! Wish I knew which Discord server could help ya out more!

 

[pc297]

Awesome work, keep it up! Wish I knew which Discord server could help ya out more!

Thanks, I just added the pieces "OSX open source Radeon HD framebuffer driver" and "PC Radeon HD cards work in PowerMacs running linux" together I am trying to figure out whether the extension actually does something or if it's just a matter of it only being a portmanteau merely recognising RadeonHD cards, e.g. when you plug in a powerbank into a USB slot, in which case it just gets detected as an HID but will obviously do nothing more than aesthetically telling you something is plugged in

 

[B S Magnet]

So setting forceSwitchCrtc to true doesn't seem to be doing anything. Re RadeonDump and RadeonDumpClient, they do get compiled as objects in XCode but not as executables, does anyone know how to do this in XCode? Using e.g. gcc RadeonDump.o -o RadeonDump gives a missing symbols error message, I guess I need to add -I<include_dir(s)>. RadeonDump.c does not compile though, I am missing several X11/xf86 includes, will look those up.

This is way above my knowledge level, technically speaking. It is really impressive what you’re doing, and I look forward to reading future updates on your efforts.

One thing to come to mind might be related in some part to what the Radeon HD card’s firmware/ROM is expecting from the driver, versus what the driver you’ve cobbled together is supplying. Providing the basics, such as hardware metadata from the card itself, is probably straightforward, which is why the driver you compiled is successful in showing the card being connected to the PCIe bus. But this driver may not have all the code it needs to pass to the card, for the card to process/parse a signal from/to a display.

My thinking/hypothesis is the Radeon HD card is expecting OpenCL-compliant commands from the CPU, via the driver interface, but instead is receiving Brook-compliant commands it is unable to resolve/parse. In short, this is the problem I wrote about last year on the SL-PPC project. This seemed to be the hard-and-fast divider between the Radeon cards which are hardware-supported in a PowerPC PCIe environment (i.e., running on BrookGPU-compliant code), and those which aren’t (i.e., Intel-only running on OpenCL-compliant code). I don’t know if AMD wrote any hybrid drivers for those cards intended only for OpenCL, but allowed for some functionality in non-OpenCL circumstances (the way Intel did with its integrated GPUs on the early MacBooks).

Perhaps there’s some way to include a translation layer between BrookGPU code and OpenCL code, to include in a home-built driver, but this is also far beyond my technical competence. I don’t know whether reverse-engineering/de-compiling OEM drivers here would hint at anything useful or not.

 

[DearthnVader]

Hi everyone,

Since reading up on some open source framebuffer drivers / injectors for hackintoshes (e.g. Callisto, ATY_init), I've been wondering about the possibility of porting those to PowerPC. While I haven't been able to find the source code for Callisto or ATY_init (@netkas might have the latter), I've come across Dong Luo's excellent work on a framebuffer driver for Radeon HD 2xxx-4xxx cards ported from the linux RadeonHD driver, with source code available (osx86-driver-radeonhd):

ATI HD framebuffer driver (10.5/10.6) with source code

Put it into /S/L/E/ and rebuild the cache to test. It will not affect vanilla driver. Any injector will prevent this driver from loading since it works the same way as IONDRVSupport. [FAQ:] 1. get a blank or dark screen after boot, or the screen keep flashing In RadeonHD.kext/Contents/Info.plist,...

www.insanelymac.com

Google Code Archive - Long-term storage for Google Code Project Hosting.

code.google.com

After simply editing OS_Version.h to use the 10.5 IOKit and setting the target architectures properly in the project properties (so far I've only had luck with ppc and i386), I have had some success compiling to powerpc in Xcode 3.1.4 under 10.5.8 (on a G5 Quad), however only using llvm-gcc. I am getting some missing symbols using gcc, I am probably missing some things in OSBundleLibraries for the latter.

Somehow, after compiling with llvm-gcc, at first the kext won't load even after removing S/L/Extensions.mkext, S/L/Extensions/Caches S/L/Caches and rebooting multiple times (kextload -t shows overflow errors). However, after rebooting into another OS (10.6 ppc in my case) and subsequently rebooting into 10.5.8, the RadeonHD extension then loads properly, and RadeonHD cards are correctly detected, but I have yet to get them to display anything.

Both my stock PCIe Radeon HD 4650 and 4870 (PC versions) cards do get recognised under 10.5.8 ppc, with display nubs created, however so far only with a black screen. Their fans, which normally rev up slightly as linux loads (under which they work flawlessly) as activity increases, do not rev up at all. Adding EDIDs to Info.plist (either as base64 or hex) does seem to go slightly further in that displays are shown as connected to the cards, but only in debug mode. The amount of VRAM seems wrong though both using the 4650 (512Mb) or 4870 (1Gb). Both cards are supported as per knownCardList.txt and rhd_id.c. The second last System Profiler screenshot with the 4800 series (actually HD4870) shows what happens when debugMode is set to false. Same result with the HD4650. The display nubs are there, but with nothing seemingly attached to them. The very last System Profiler screenshot is using my HD5770, which, although being detected as display, clearly doesn't seem supported.

I've tried fiddling around with various options, e.g. setting BackLightLevel to 0, enableBacklight to false, @0,UseFixedModes, to true or specifiying @0,TYPE to DACA but no avail. I haven't tried changing forceSwitchCrtc to true yet though, will give it a try. I don't know if getting it to work is just a matter of options in the plist or if deeper issues need to be resolved in Xcode.

Building as debug or release seems to have the exact same effects.

I also haven't compiled RadeonDump to ppc yet to get some proper troubleshooting / logging, but will do as soon as I get a chance. dmesg / verbose boot do show "RadeonHD: creating nubs".

There are several files in the project trunk that are not in the Xcode project that might be needed for hardware support on ppc, notably xf86/Pci.c xf86/Pci.h that seem to have dedicated ppc methods, maybe this is what is missing (notably how the ROM is accessed, as it will be little-endian) ? However trying to include those creates a massive dependency problem, requiring most of the X11/XF86 source code for mac which I don't have (several X11 include files are present in the Developer folder but several other required e.g. Compiler.h are missing).

On the other hand, on the insanelymac forum on the kext, it seems that someone may have made a universal version (however not tested on powerpc) but all versions posted on the forum are intel, would by any chance anyone have this?

ATI HD framebuffer driver (10.5/10.6) with source code

www.insanelymac.com

Or if anyone knows what I might be missing, even though I found these baby steps already encouraging? Or reckons that this has any chance of ever working (or not due to endianness issues that would entail significant rewriting)?

Cheers,

PS: I will post the ppc kext later on today if anyone wants to try it


EDIT: from what I understand, osx86-driver-radeonhd works independently of ATIX2000.kext (anyway not available for ppc, if only <sigh>) and will still result in a useable framebuffer driver in its absence

EDIT2: from what I also understand, under ppc linux, the modern radeon driver will soft-load ROM code with endianness taken into account for correct operation. I don't know if the present driver implements any of this

EDIT3: further to point 2 I have only tried the AtomBIOS version of the driver

View attachment 2005976


View attachment 2005978


View attachment 2005979


View attachment 2005977


View attachment 2005980


View attachment 2005981

These drivers expect a VGA Bios( GOP or EFI ) to initialize the card and the frame buffer driver to take over from that, if I'm not mistaken.

You'd be better off writing an FCODE ROM for the card, assuming it's one of the cards AMD released the hardware info for, then writing an OS X complaint 'ndrv'. The trouble is all you would have is a basic driver with no 2D/3D hardware acceleration because the drivers don't exist in the PPC branch of OS X and Apple never released an open API for writing them.

 

[pc297]

This is way above my knowledge level, technically speaking. It is really impressive what you’re doing, and I look forward to reading future updates on your efforts.

One thing to come to mind might be related in some part to what the Radeon HD card’s firmware/ROM is expecting from the driver, versus what the driver you’ve cobbled together is supplying. Providing the basics, such as hardware metadata from the card itself, is probably straightforward, which is why the driver you compiled is successful in showing the card being connected to the PCIe bus. But this driver may not have all the code it needs to pass to the card, for the card to process/parse a signal from/to a display.

My thinking/hypothesis is the Radeon HD card is expecting OpenCL-compliant commands from the CPU, via the driver interface, but instead is receiving Brook-compliant commands it is unable to resolve/parse. In short, this is the problem I wrote about last year on the SL-PPC project. This seemed to be the hard-and-fast divider between the Radeon cards which are hardware-supported in a PowerPC PCIe environment (i.e., running on BrookGPU-compliant code), and those which aren’t (i.e., Intel-only running on OpenCL-compliant code). I don’t know if AMD wrote any hybrid drivers for those cards intended only for OpenCL, but allowed for some functionality in non-OpenCL circumstances (the way Intel did with its integrated GPUs on the early MacBooks).

Perhaps there’s some way to include a translation layer between BrookGPU code and OpenCL code, to include in a home-built driver, but this is also far beyond my technical competence. I don’t know whether reverse-engineering/de-compiling OEM drivers here would hint at anything useful or not.

It's not so technical at all, merely compiling A lot easier with emerge under Gentoo for the modern radeon driver though I would go through the code to see if there is any hint of OpenCL-compliant commands. I would have to double-check the current radeon driver as well (which works with stock PC Radeon 2XXX HD cards and above under at least the current PPC versions of Debian, OpenSUSE and Gentoo, and previously Ubuntu until it dropped PPC support after 16.10). It works without OpenCL under Linux, but does support it once installed (at least in my hands in PPC Debian, OpenSUSE and Gentoo with RadeonHD 4XXX and 5XXX cards, I think Luigi Burdo tested it up to 7XXX).

The version that Dong made is essentially a port derived from elements of the same fork (the framebuffer part of the radeon linux driver, not fglrx for which the source is not available anyway) but 13 years ago. But I see what you mean and yes I recall precisely this discussion on the SL PPC forum. Might be worth a try with 10.6 10A96 or 10A190, both ppc and intel. I recall that my Radeon HD 5870 was working fine when I put my hard drive with 10A190 into my MP2,1 and booted from it, and I recall from this discussion that likely OpenCL wasn't yet really implemented in those early SL versions. It could also be that it was on the intel side but not ppc, we will never know as no one has the source for these kexts. Re BrookGPU it would be interesting to try with a Radeon HD 2XXX or 3XXX as those will only support it and not OpenCL, but those cards are supported under both Leopard and SL.

 

[barracuda156]

After simply editing OS_Version.h to use the 10.5 IOKit and setting the target architectures properly in the project properties (so far I've only had luck with ppc and i386), I have had some success compiling to powerpc in Xcode 3.1.4 under 10.5.8 (on a G5 Quad), however only using llvm-gcc. I am getting some missing symbols using gcc, I am probably missing some things in OSBundleLibraries for the latter.

Awesome work!

I am not sure it will solve compilation issues, but you can get gcc11 onto PowerPC (both 10.5.8 and 10A190). I have an outline of the procedure in Macports-related thread here, but feel free to ask anything, I have it working now on the Quad and on Intel MacMini in Rosetta.

P. S. For 10A190 the only way to go, as of now, is Macports, but on 10.5.8 and 10.6.8 Rosetta you can build gcc10 and then gcc11 directly.

 

[pc297]

These drivers expect a VGA Bios( GOP or EFI ) to initialize the card and the frame buffer driver to take over from that, if I'm not mistaken.

Precisely. This is the AtomBIOS part of the driver. So does the ppc radeon linux driver which works flawlessly in ppc macs running modern versions of Debian (sid), OpenSUSE (Tumbleweed) and Gentoo. I tested it using both stock VGA and EFI ROMs. The one thing that one needs to install in Debian and Gentoo (or, rather, emerge for the latter) to have Radeon HD cards work on ppc macs is firmware-linux-nonfree on top of the built-in radeon driver (installed by default under OpenSUSE). The point is, ROMs from HD 2XXX+ cards are soft-loaded, decoded and interpreted under linux, which makes it possible to use these cards under ppc linux.

https://forums.macrumors.com/threads/arch-linux-on-ppc-of-all-things.2302272/post-30789337

The three main questions are therefore:

1) was this implemented before or after Dong's excellent port?

2) does the radeon linux driver perform byte-flipping for ppc machines from decoded Radeon HD ROMs?

3) if so was this already implemented when Dong ported the driver, i.e. was there any implementation that specifically accommodates the ppc architecture?

Re 1) I would tend to say before, which is the AtomBIOS part of the driver.

Re 2) one way to find out would be to look into the source of the linux radeon driver, as far as I know under e.g. gentoo the exact same source is used for x86 and ppc when emerging this driver, so I would imagine yes, but would need to go through the code. If this is the case, isolating the endianness-switching (byte-flipping) methods would be important if 3) turns out to be negative

Re 3) Ubuntu 13.X, and I think 12.X supported radeon HD cards under ppc to some extent, e.g. I am able to get some basic framebuffer display in 13.X ppc for my Radeon HD cards. For 10.X this is where this gets interesting, as Dong's port was written around that time. Radeon HD cards do seem to get somehow initialised under Ubuntu 10.04 ppc as the display kicks in and they start to rev up, but the display is garbled. So it could be that Dong's code, which is derived from the linux radeon driver from around that time, does implement some sort of support for ppc that was carried over - so this would argue for 1) but is obviously dependent on the extent of elements that were ported. Whether it is functional or not is a whole different ball game. There are clearly ppc-specific methods in Pci.c and Pci.h but these are not used in the XCode project, I need further includes that are not in the X11 part of the 10.5 SDK and will look those up. It could be that these are needed to get the cards working on ppc macs.

You'd be better off writing an FCODE ROM for the card, assuming it's one of the cards AMD released the hardware info for, then writing an OS X complaint 'ndrv'.

This would obviously be a massive and very daunting undertaking and another approach that I am in no way qualified to carry out and probably not too many people, except for the guys that obviously wrote OF ROMs or the ones who wrote various ppc ROM makers (e.g. the GF 6200 ppc rom maker which works from VGA roms as input, very neat by the way, did the trick for me to get a GF6200 on the G3 B&W), as well as people such as yourself who are very knowledgeable about VGA/EFI/OF rom code writing, or perhaps @netkas himself. I could somehow imagine a starting point could be deriving ppc HD 2XXX roms by comparing the VGA and OF Radeon X19XX roms, working out the differences and applying to parts of the VGA/EFI Radeon X19XX cards, taking into account the (very massive) differences between the X19XX and HD2XXX cards. Way above me in any case. The NDRV part would indeed then come in BUT a lot of the code necessary for initialisation etc is already included in OF/OF GPU roms as you point it out yourself

https://forums.macrumors.com/threads/testing-fcode-roms-before-you-flash.2123070/

But yes an NDRV would have to be written, however this is part of the ASOP so it might be possible to port the intel one and if it's not available it probably wouldn't be completely impossible to derive one from that of X6XX, X8XX, X12XX, X16XX and X19XX cards if available.

The trouble is all you would have is a basic driver with no 2D/3D hardware acceleration because the drivers don't exist in the PPC branch of OS X and Apple never released an open API for writing them.

This is what this framebuffer driver basically provides and I would already be happy with that . Obviously QE/CI would need ATIX2000.kext which is not available for ppc and even if the source was available it would undoubtedly require a lot of work to get it working on ppc, be it only for the endianness issues. But since Dong's port was written with Hackintoshes in mind, in several cases people had to get rid of ATIX2000.kext altogether to get PC Radeon HD cards working, albeit with a software framebuffer only, but were still happy to get any display! The real question is, which NDRV gets used in this case, for unsupported cards. Since there is a Leopard version of Dong's kext that can perhaps be used on stock Leopard, that is WITHOUT any NDRV specifically written for RadeonHD cards. From what I can see, IONDRVFramebuffer gets called as the legacy framebuffer since a lot of the ROM code from RadeonHD cards is used to initialise them in OSX:

ATI HD framebuffer driver (10.5/10.6) with source code

www.insanelymac.com

The question is, whether this is possible under ppc Leopard. It certainly works that way for the Linux driver on ppc.

It could however be that a new NDRV is required to get Radeon HD cards displaying anything at all for ppc. Strangely enough though even though I still get no display, ASP reports that CI is enabled on the Radeon HD (but not QE) 🙃

 

[ITzTravelInTime]

Awesome work, just want to ask: Does it work with AGP cards? I have a Radeon HD 4670 agp and I can combine it with a pci card card for the open firmware display output, it could be nice to see it work in my agp g5.

BTW I have also ported some Sound card hackintosh drivers to PowerPC macs, so I have CMI8738, Via VT1724HT card and 10kx based sound blasters and e-mu Edsp cards working in my powerpc macs.

Projects links:

- https://forums.macrumors.com/thread...ries-driver-os-x-ppc-porting-project.2287424/
- https://forums.macrumors.com/threads/driver-cheap-pci-sound-cards-on-ppc-macs-cmi8738.2283325/
- https://github.com/ITzTravelInTime/Envy24HT/releases/tag/1.0


For my driver ports one of the things I had to do to ensure proper functioning of all the servers is correct the endianess in the small buffers, did you do that too? Also one thing to check is for I/O operations to be properly performed via memory mapped I/O ports on PowerPC, have you adjusted for those that?

Also check all the dma buffer allocation to make sure they are performed in a region of the physical memory accessible by the cards, because some cards might be able to address less than 32 bits of address space (like with some older sound cards) but the os should provide you with KPI for that.

Also those kexts might use vector instructions so PowerPC alternatives must be provided were they are needed.

Also some KPI available on leopard are also available on tiger server edition but not in consumer tiger, so there is the possibility of having the drivers working on tiger too.

 

[pc297]

Awesome work, just want to ask: Does it work with AGP cards? I have a Radeon HD 4670 agp and I can combine it with a pci card card for the open firmware display output, it could be nice to see it work in my agp g5.

BTW I have also ported some Sound card hackintosh drivers to PowerPC macs, so I have CMI8738, Via VT1724HT card and 10kx based sound blasters and e-mu Edsp cards working in my powerpc macs.

Projects links:

- https://forums.macrumors.com/thread...ries-driver-os-x-ppc-porting-project.2287424/
- https://forums.macrumors.com/threads/driver-cheap-pci-sound-cards-on-ppc-macs-cmi8738.2283325/
- https://github.com/ITzTravelInTime/Envy24HT/releases/tag/1.0


For my driver ports one of the things I had to do to ensure proper functioning of all the servers is correct the endianess in the small buffers, did you do that too? Also one thing to check is for I/O operations to be properly performed via memory mapped I/O ports on PowerPC, have you adjusted for those that?

Also check all the dma buffer allocation to make sure they are performed in a region of the physical memory accessible by the cards, because some cards might be able to address less than 32 bits of address space (like with some older sound cards) but the os should provide you with KPI for that.

Also those kexts might use vector instructions so PowerPC alternatives must be provided were they are needed.

Also some KPI available on leopard are also available on tiger server edition but not in consumer tiger, so there is the possibility of having the drivers working on tiger too.

Thanks! Re AGP Radeon HD cards I don't see why not, these work flawlessly under ppc linux, see these replies in this thread:

https://forums.macrumors.com/threads/the-powerpc-debian-wiki.2178457/post-30971999

https://forums.macrumors.com/threads/the-powerpc-debian-wiki.2178457/post-30972410

However as for the driver really "working", I would just like to clarify that although the cards do recognised with this kext under ppc Leopard (and likely 10.6 10A96 and 10A190 in the near future), there is, as of yet, no actual display coming out. Maybe I should add a question mark to the thread title or rename it to "Getting Radeon HD cards to work on PowerPC Leopard using osx86-driver-radeonhd framebuffer driver"

 

[pc297]

I am not sure it will solve compilation issues, but you can get gcc11 onto PowerPC (both 10.5.8 and 10A190). I have an outline of the procedure in Macports-related thread here, but feel free to ask anything, I have it working now on the Quad and on Intel MacMini in Rosetta.

P. S. For 10A190 the only way to go, as of now, is Macports, but on 10.5.8 and 10.6.8 Rosetta you can build gcc10 and then gcc11 directly.

Thanks a lot for that, yes I saw it in the SL PPC thread, is there any way to use gcc11 with XCode 3.1.4 or 3.2? Re 10A190 I was able to compile the 10.5 kext (but not 10.6 yet, could be that the 10.6 ppc SDK is broken in XCode 3.2 ppc) in XCode 3.2 (I installed the one from 10A96).

 

[ITzTravelInTime]

Thanks a lot for that, yes I saw it in the SL PPC thread, is there any way to use gcc11 with XCode 3.1.4 or 3.2? Re 10A190 I was able to compile the 10.5 kext (but not 10.6 yet, could be that the 10.6 ppc SDK is broken in XCode 3.2 ppc) in XCode 3.2 (I installed the one from 10A96).

The problem with OS X is that agp devices have a different class match compared to pci and pcie ones, so the driver could not load for those.

About the other things I said about porting drivers to PowerPC (as I did) what have you done to the source code? Did you do any of the things I recommend?

My experience porting the sound cards drivers could help I think, I might take a look at the source and maybe produce a few builds for you to test out. It might just be a matter of fixing those things I mentioned in the source code to get display working.

 

[pc297]

I managed to compile RadeonDump however with the .c version I get an error: IORegistryEntryGetPath returned 0x10000003 error, and with the .cpp version I get no output. I have come across the RadeonPCI extension for hackintoshes which I have compiled to see if it helps RadeonDump:

DarwinDumper

www.insanelymac.com

The kext Info.plist looks for *ATY* matches, will change it to ATI (ioreg -l registers the RadeonHD card as ATI when RadeonHD.kext is loaded) and let you know

 

[pc297]

This is my dmesg with RadeonHD.kext, the point is that I should probably try with either a card listed in the kext database (more precisely, the AtomBIOS data table), or to compile the version without AtomBIOS:

[RadeonHD]: initialize NDRVHD for nub 0
[RadeonHD]: initialize hardware with nub 0
[RadeonHD]: Card not in database: 0x9498:0x174B:0xE930; using generic modesetting.
[RadeonHD]: If - and only if - your card does not work or does not work optimally
[RadeonHD]: Detected an RV730 on an unidentified card
[RadeonHD]: PCIE Card Detected
[RadeonHD]: RHDAtomBiosFunc
[RadeonHD]: rhdAtomInit
[RadeonHD]: Getting BIOS copy from legacy address
[RadeonHD]: rhdAtomGetTables
[RadeonHD]: rhdAtomGetTables: No AtomBios signature found
[RadeonHD]: Query for AtomBIOS Init: failed
[RadeonHD]: Using AtomBIOS for All
[RadeonHD]: No AtomBIOS image found but required for AtomBIOS based mode setting
[RadeonHD]: RHDMCDestroy
[RadeonHD]: RHDVGADestroy
[RadeonHD]: RHDPLLsDestroy
[RadeonHD]: RHDLUTsDestroy
[RadeonHD]: RHDOutputsDestroy
[RadeonHD]: RHDConnectorsDestroy
[RadeonHD]: RHDCursorsDestroy
[RadeonHD]: RHDCrtcsDestroy
[RadeonHD]: RHDI2CFunc
[RadeonHD]: RHDAtomBiosFunc
[RadeonHD]: Query for AtomBIOS Teardown: failed
[RadeonHD]: nub 0 can't initialize from hardware
[RadeonHD]: cscProbeConnection
[RadeonHD]: cscGetScalerInfo
[RadeonHD]: cscSetGray
[RadeonHD]: cscSavePreferredConfiguration
[RadeonHD]: cscGetFeatureConfiguration
[RadeonHD]: cscGetMultiConnect...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetMultiConnect...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetConnection...
[RadeonHD]: initialize NDRVHD for nub 1
[RadeonHD]: initialize hardware with nub 1
[RadeonHD]: Card not in database: 0x9498:0x174B:0xE930; using generic modesetting.
[RadeonHD]: If - and only if - your card does not work or does not work optimally
[RadeonHD]: Detected an RV730 on an unidentified card
[RadeonHD]: PCIE Card Detected
[RadeonHD]: RHDAtomBiosFunc
[RadeonHD]: rhdAtomInit
[RadeonHD]: rhdAtomGetTables
[RadeonHD]: rhdAtomGetTables: No AtomBios signature found
[RadeonHD]: Query for AtomBIOS Init: failed
[RadeonHD]: Using AtomBIOS for All
[RadeonHD]: No AtomBIOS image found but required for AtomBIOS based mode setting
[RadeonHD]: RHDMCDestroy
[RadeonHD]: RHDVGADestroy
[RadeonHD]: RHDPLLsDestroy
[RadeonHD]: RHDLUTsDestroy
[RadeonHD]: RHDOutputsDestroy
[RadeonHD]: RHDConnectorsDestroy
[RadeonHD]: RHDCursorsDestroy
[RadeonHD]: RHDCrtcsDestroy
[RadeonHD]: RHDI2CFunc
[RadeonHD]: RHDAtomBiosFunc
[RadeonHD]: Query for AtomBIOS Teardown: failed
[RadeonHD]: nub 1 can't initialize from hardware
[RadeonHD]: cscProbeConnection
[RadeonHD]: cscGetScalerInfo
[RadeonHD]: cscSetGray
[RadeonHD]: cscSavePreferredConfiguration
[RadeonHD]: cscGetFeatureConfiguration
[RadeonHD]: cscGetMultiConnect...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetMultiConnect...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetConnection...
[RadeonHD]: cscGetFeatureConfiguration
[RadeonHD]: cscGetFeatureConfiguration
[RadeonHD]: cscGetFeatureConfiguration
[RadeonHD]: cscGetFeatureConfiguration

 

[DearthnVader]

Getting BIOS copy from legacy address

There is an address in shadow memory on x86 BIOS systems where the Video BIOS is loaded, your kext is likely trying to probe that address( I forget what it is ). That's not going to work on Open Firmware PPC, you'll have to find a way to upload the VBIOS to your driver via a file.

 

[pc297]

The problem with OS X is that agp devices have a different class match compared to pci and pcie ones, so the driver could not load for those.

About the other things I said about porting drivers to PowerPC (as I did) what have you done to the source code? Did you do any of the things I recommend?

My experience porting the sound cards drivers could help I think, I might take a look at the source and maybe produce a few builds for you to test out. It might just be a matter of fixing those things I mentioned in the source code to get display working.

Am going through them, looks promising! Thanks for the links above

Cheers,

 

[pc297]

There is an address in shadow memory on x86 BIOS systems where the Video BIOS is loaded, your kext is likely trying to probe that address( I forget what it is ). That's not going to work on Open Firmware PPC, you'll have to find a way to upload the VBIOS to your driver via a file.

That's exactly what I was thinking too, especially if AtomBIOS is looking for it and can't find it at this address. Solutions: either hard-linking to a file in the code (ugly though and it will require a lot of roms), implement linking in the kext settings, port linux-firmware-nonfree/come up with an equivalent, identify the address where the VGA BIOS gets loaded if at all and modify accordingly in the code, or directly via OF using the method you previously suggested:

https://forums.macrumors.com/threads/testing-fcode-roms-before-you-flash.2123070/

That said, from what I read RadeonHD.kext should also work with actual intel macs so EFI there and not just x86 BIOS? Unless the address is the same in both? I also wonder how exactly the radeon driver successfully does precisely this under Linux ppc? I will have a look in the code there for anything OpenFirmware-specific, e.g. the address where the VGA BIOS gets loaded when decoded/byte-flipped

 

[pc297]

There is an address in shadow memory on x86 BIOS systems where the Video BIOS is loaded, your kext is likely trying to probe that address( I forget what it is ). That's not going to work on Open Firmware PPC, you'll have to find a way to upload the VBIOS to your driver via a file.

Ah wait, you mean to say that in OpenFirmware PPC this VGA BIOS will never get loaded in memory, right? Then indeed loading it from disk is likely the answer, like from firmware-linux-nonfree. I guess that Ubuntu 10.04 has it too (the first Ubuntu release that has it is from 2009), will check from the 10.04 ppc live cd if it is installed by default which would explain why I get radeon hd graphics initialised booting from it.

 

[barracuda156]

Thanks a lot for that, yes I saw it in the SL PPC thread, is there any way to use gcc11 with XCode 3.1.4 or 3.2? Re 10A190 I was able to compile the 10.5 kext (but not 10.6 yet, could be that the 10.6 ppc SDK is broken in XCode 3.2 ppc) in XCode 3.2 (I installed the one from 10A96).

1. In theory you can make a plugin for Xcode in order to use the new gcc, however I did not try that. I think those are plain-text files. I use gcc11 in Macports, without Xcode. (If you succeed, please let me know btw.)

2. I advise to stay away from 10A96, it is broken. Use 10A190 and Xcode from 10A190.

 

[pc297]

There is an address in shadow memory on x86 BIOS systems where the Video BIOS is loaded, your kext is likely trying to probe that address( I forget what it is ). That's not going to work on Open Firmware PPC, you'll have to find a way to upload the VBIOS to your driver via a file.

I have tried to bypass the code that reads the legacy address pointer in rhd_atombios.c:

        LOG("Getting BIOS copy from legacy address\n");
        ptr = rhdPtr->BIOSCopy;
 
        BIOSImageSize = ptr[2] * 512;
        if (BIOSImageSize > legacyBIOSMax) {
            LOG("Invalid BIOS length field\n");
            return ATOM_FAILED;
        }
        BIOSImageSize = rhdPtr->BIOSSize;
        rhdPtr->BIOSCopy = NULL;
        rhdPtr->BIOSSize = 0;

to just read the VGA BIOS from PCI config space:

        /* as last resort always try to read BIOS from PCI config space */
        LOG("Getting BIOS copy from PCI config space\n");
        if (BIOSImageSize == 0) {
        if (!(BIOSImageSize = RHDReadPCIBios(rhdPtr, &ptr)))
            return ATOM_FAILED;
            unposted = TRUE;
        }

just commenting out if and else statements for the first and second portions of code, and commenting out the first part, but to no avail. Same dmesg apart from the log message I inserted. I will check whether ATOM_FAILED is returned or not, as it should fail before I get the "No AtomBios signature found" error if so. It could be that the RHDReadPCIBios method is written for x86.

If it is or if ATOM_FAILED is returned, I am indeed going to read the rom from file. The question is if it can be used as such or if it will need some endianness switching if the latter is not implemented in the code at all (could also be the source of the error, that ATOM_FAILED is not returned but that the rom doesn't get decoded properly). The other option is to use the driver without AtomBIOS as in its first versions.

 

[pc297]

Some progress, so unposted gets set to true with the only code above but ATOM_FAILED does not get returned, I will try to see what happens with the code that I commented out (it looks like it is needed to set BIOSImageSize, and it is likely the reason why ATOM_FAILED does not get returned as the result of RHDReadPCIBios(rhdPtr, &ptr) is 0 when not set and equals BIOSImageSize when not set above). In the meantime I will dump the VGA BIOS and try to read it into ptr. I would do this on a PC, unless someone knows a way to dump it with Zeus? AFAIK the ppc version can only dump nvidia roms, unless there is another tool (with source available which would be great so that the code to read the BIOS could be used in the radeonhd driver)?

Cheers,

 

[ITzTravelInTime]

Some progress, so unposted gets set to true with the only code above but ATOM_FAILED does not get returned, I will try to see what happens with the code that I commented out (it looks like it is needed to set BIOSImageSize, and it is likely the reason why ATOM_FAILED does not get returned as the result of RHDReadPCIBios(rhdPtr, &ptr) is 0 when not set and equals BIOSImageSize when not set above). In the meantime I will dump the VGA BIOS and try to read it into ptr. I would do this on a PC, unless someone knows a way to dump it with Zeus? AFAIK the ppc version can only dump nvidia roms, unless there is another tool (with source available which would be great so that the code to read the BIOS could be used in the radeonhd driver)?

Cheers,

It might be likely, I should really take a look at the code because first of all you need to convert all pci config space calls into memory address reads (using also a system instruction that performs endianess swap while reading the value into the cpu registers) then you need to make sure that dma buffers are written to in a little endian way, usually you have to use the same instruction I mentioned before. Then the code should be checked for any code that violates the endianess and so might break with a big endianess system, for example reading a shorter (in terms of bit lenght) value from a pointer pointing to a longer value, those should be endianess swapped too to be successfully ported.

So all the problems with endianess compatibility must be fixed, and it’s a good idea to deploy some kpi functions to do that, and any x86 specific stuff must be re-implemented with PowerPC equivalents.

 

[pc297]

It might be likely, I should really take a look at the code because first of all you need to convert all pci config space calls into memory address reads (using also a system instruction that performs endianess swap while reading the value into the cpu registers) then you need to make sure that dma buffers are written to in a little endian way, usually you have to use the same instruction I mentioned before. Then the code should be checked for any code that violates the endianess and so might break with a big endianess system, for example reading a shorter (in terms of bit lenght) value from a pointer pointing to a longer value, those should be endianess swapped too to be successfully ported.

So all the problems with endianess compatibility must be fixed, and it’s a good idea to deploy some kpi functions to do that, and any x86 specific stuff must be re-implemented with PowerPC equivalents.

Thanks for the suggestion, I also think this might be an issue when I get to the rom decoding part - regardless of whether it is read from the card or from file - and also possibly pci addressing when attempting to read the rom. I have been going through the code for a few days and I have yet to find any evidence of byte-swapping for ppc which we all know happens in the modern radeon driver, but it is indeed unclear as to whether this was already implemented when Dong ported the driver from Linux in 2009. There are some ppc-specific methods in Pci.c but the latter doesn't get used by default in the XCode project, and including it creates a massive dependency problem, notably of includes that are not in the XCode X11 SDK. I have already found most of them but not all yet.