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

[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?

Take a look at the description here: https://github.com/jhnbwrs/macportsGCCfixup
It deals with a matter of Xcode plugins (not tested with XCode 3.x, but may work in a similar way).

 

[sasho648]

That's amazing - I'm going to try my osx86 (I used to run OS X Snow Leopard on an intel box) hd5450 on my PowerMac G5 QUAD.

Btw I would like to help if you create like a github (fork?) or something.

And there is Gentoo Prefix which seems to be installing quite successfully on my side for now - about 4th hour in (it installs on os x home folder).

Following up I'm wondering why 2d/3d won't be possible to do: why is ATIX2000.kext not supported? Ok I answered that myself.

 

[barracuda156]

May be of interest re ATI cards: https://www.insanelymac.com/forum/topic/17767-borisbadenov-ati-x1000-series-solution/

 

[Wizzlemane96]

This would be awesome to achieve. I have a HD 3870 mac edition new in box would be awesome to use it in my G5 quad. The FX 4500 is a great card but it could really use an upgrade. According to Userbenchmark the 3870 is about 400% faster than the fx4500. 3870 VS FX4500

 

[ITzTravelInTime]

@pc297 About the card rom issue, i think on powerpc you have to look for the memory address of the rom using the pci config space, more info on it using this very useful book: https://raw.githubusercontent.com/sun6boys/Books/master/Os X And iOS Kernel Programming.pdf (i think at page 175)

BTW since the roms on those cards are meant for little endian systems i think you should definetly do some byteswapping.

 

[pc297]

@pc297 About the card rom issue, i think on powerpc you have to look for the memory address of the rom using the pci config space, more info on it using this very useful book: https://raw.githubusercontent.com/sun6boys/Books/master/Os X And iOS Kernel Programming.pdf (i think at page 175)

BTW since the roms on those cards are meant for little endian systems i think you should definetly do some byteswapping.

Thanks a lot, I did add some code to read the rom from file but I have yet to figure out how to cast the buffer to rhdPtr->BIOSCopy, I was also thinking of trying to locate the rom address in openfirmware (in intel machines it is read from 0xC0000 I think from how "legacyBIOSLocation" is set) but this link will make it a lot easier, thanks!

Re byteswapping I think - but I need to go through the ppc-specific methods (there are some) to confirm it - that the linux module this extension is derived from already does byteswapping for BE systems, i.e. along the same lines as the current linux radeon driver does for LE RadeonHD cards under BE ppc linux; I think Dong forked it after this was implemented in linux

 

[ITzTravelInTime]

Thanks a lot, I did add some code to read the rom from file but I have yet to figure out how to cast the buffer to rhdPtr->BIOSCopy, I was also thinking of trying to locate the rom address in openfirmware (in intel machines it is read from 0xC0000 I think from how "legacyBIOSLocation" is set) but this link will make it a lot easier, thanks!

Re byteswapping I think - but I need to go through the ppc-specific methods (there are some) to confirm it - that the linux module this extension is derived from already does byteswapping for BE systems, i.e. along the same lines as the current linux radeon driver does for LE RadeonHD cards under BE ppc linux; I think Dong forked it after this was implemented in linux

about the legacy bios rom: i don't think that os x will agree if you want to use the legacy bios address, especially on a risc system, because it's designed for the drivers to just use standard pci calls, therefor the best way to get the rom address is to read it off the pci config space, then shove it into a pointer, and just perform your memory operations with it using that pointer. hardcoded memory addresses are considered very bad practice in modern systems, and they are mostly used in the world of microcontrollers mowadays or bootloaders/kernels.

Also it's not a bad idea to go take a look at pci standards, for things like expansion roms standards and so on ..., it will surely help.

btw also when you are able to access the rom from the config space, try to get a dump of the rom memory buffer first, and check it against a dump of the rom. this should tell you if you actually need byte swapping or any other thing.

 

[pc297]

about the legacy bios rom: i don't think that os x will agree if you want to use the legacy bios address, especially on a risc system, because it's designed for the drivers to just use standard pci calls

Nono, I confirm that this definitely does not work especially with the given x86-specific address, but strangely this seems to be the default behaviour of osx86-driver-radeonhd. It does however try to read the BIOS from PCI config space as a last resort:

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

but RHDReadPCIBios does not seem to function properly with openfirmware or BE as this systematically results in ATOM_FAILED being returned. Let's see if this can be solved, otherwise I will just stick to reading the rom from file; where I am right now is trying to figure out a way to cast the file ptr (I do use fopen in binary mode for the rom file ) to a type handled by ptr = rhdPtr->BIOSCopy

Cheers,

 

[ITzTravelInTime]

Nono, I confirm that this definitely does not work especially with the given x86-specific address, but strangely this seems to be the default behaviour of osx86-driver-radeonhd. It does however try to read the BIOS from PCI config space as a last resort:

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

but RHDReadPCIBios does not seem to function properly with openfirmware or BE as this systematically results in ATOM_FAILED being returned. Let's see if this can be solved, otherwise I will just stick to reading the rom from file; where I am right now is trying to figure out a way to cast the file ptr (I do use fopen in binary mode for the rom file ) to a type handled by ptr = rhdPtr->BIOSCopy

Cheers,

About the legacy bios, i think that's just an hackintosh thing, because perhaps the bootlaoder keeps the bios loaded. While on real macs nothing it's really done with the legacy video bios, so it's just treated as any other expansion card's rom, this hsould be true even on intel macs.

 

[pc297]

About the legacy bios, i think that's just an hackintosh thing, because perhaps the bootlaoder keeps the bios loaded. While on real macs nothing it's really done with the video bios, so it's just treated as any other expansion card's rom, this hsould be true even on intel macs.

Yes it was clearly forked from the linux radeon driver with Hackintoshes in mind, that said I need to check whether it loads on real intel macs

 

[ITzTravelInTime]

Yes it was clearly forked from the linux radeon driver with Hackintoshes in mind, that said I need to check whether it loads on real intel macs

It is actually a good idea, because some behaviors which are standard for all macs it's not guaranteed on hackintoshes. Also because on intel macs apple has it's own wired ways of handling things like windows compatibility and legacy booting compatibility, so when it comes to boot os x, the system could avoid using all or some the pc compatibility stuff.

 

[ITzTravelInTime]

Nono, I confirm that this definitely does not work especially with the given x86-specific address, but strangely this seems to be the default behaviour of osx86-driver-radeonhd. It does however try to read the BIOS from PCI config space as a last resort:

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

but RHDReadPCIBios does not seem to function properly with openfirmware or BE as this systematically results in ATOM_FAILED being returned. Let's see if this can be solved, otherwise I will just stick to reading the rom from file; where I am right now is trying to figure out a way to cast the file ptr (I do use fopen in binary mode for the rom file ) to a type handled by ptr = rhdPtr->BIOSCopy

Cheers,

About this code i was looking at it in the source and, are we sure it's actually using the right address? because if so it should be using a call to device->configRead32(kIOPCIConfigExpansionROMBase) in device's start method, which i don't see anywhere in the code, i hope it doesn't use the pci config space as a buffer directly, because i's a bad idea to do that, because from a pci driver on os x, you are not supposed to do it really (even if nothing prevents you from doing it), you should call the config read methods and passing them the constants matching what you are trying to read.

Especially because this driver is being ported to a big endian machine, and various kinds of buffer operations are known to break with endianess changes, in fact apple made those config read kpis just to make life easier to driver developers looking into making multi-platform drivers.