Jump to content

New ATI Framebuffer Xcode project to start from


  • Please log in to reply
122 replies to this topic

#41
LeoMark

LeoMark

    InsanelyMac Protégé

  • Members
  • Pip
  • 10 posts
Hey guys ... do you think the project will not have a solution? the project will continue or is this the end of the ATI Mobility ... ;)

#42
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

latest still panics for me O.o


I don't have a later ATI card to test the code. The _RHDReadMC and _RHDWriteMC are different for my x1400 compared to later cards, maybe panic here?

#43
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

I don't have a later ATI card to test the code. The _RHDReadMC and _RHDWriteMC are different for my x1400 compared to later cards, maybe panic here?


Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to.

Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks.
Specifically, kernel panicks in rhd_init.c, function:

void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) {
	 *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value;
}

CARD16 offset was 544c, CARD32 value was 8

_RHDRegRead previously returned 0 for the offset 544c

Hope it helps

#44
super_engine

super_engine

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 191 posts
Hi
I am one of hundrends laptop users with an ATI Mobility card (X1350)
Please can attach a compiled file in this thread. So we, no developers, can test it ???

thank you in advance.

#45
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to.

Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks.
Specifically, kernel panicks in rhd_init.c, function:

void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) {
	  *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value;
 }

CARD16 offset was 544c, CARD32 value was 8

_RHDRegRead previously returned 0 for the offset 544c

Hope it helps

Thanks for your interest and effort.
A roughly search of 0x544C did not give any results from radeonHD or ati open source. I then looked at the binary code of ATY_MegaLodon. It turns out the register address is visited in the procedures of PCIE_Gen1_Enable and PCIE_Gen2_Enable. Below is the disemblyed code of PCIE_Gen2_Enable:
OSStatus PCIE_Gen2_Enable(DriverGlobal *aDriverRecPtr) {
	UInt32 value, value1;
	pciepw32(aDriverRecPtr, 0xA2, pciepr32(aDriverRecPtr, 0xA2) & ~(1 << 13));
	value = pciepr32(aDriverRecPtr, 0xA2);
	if (value & (1 << 9))
		pciepw32(aDriverRecPtr, 0xA2, ((((value | (1 << 10)) & ~7) | ((value & 0x70) >> 4)) | (1 << 8)) & ~(1 << 7));
	else
		pciepw32(aDriverRecPtr, 0xA2, value | (1 << 13));
	value = pciepr32(aDriverRecPtr, 0xA4);
	if ((value & (1 << 23)) && (value & (1 << 24))) {
		regw32(aDriverRecPtr, 0x5488, regr32(aDriverRecPtr, 5488) & ~(1 << 25));
		regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~(1 << 28));
		regw32(aDriverRecPtr, 0x5404, regr32(aDriverRecPtr, 5404) | (1 << 25));
		regw32(aDriverRecPtr, 0x5484, regr32(aDriverRecPtr, 5484) & ~0xF;
		regw32(aDriverRecPtr, 0x5410, regr32(aDriverRecPtr, 5410) | (1 << 23));
		regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~0x1E);
		value = (value | 1) & ~2;
		value1 = pciepr32(aDriverRecPtr, 0xA1);
		if (value1 & (1 << 6)) pciepw32(aDriverRecPtr, 0xA1, value1 & ~0x40);
		pciepw32(aDriverRecPtr, 0xA4, ((((value & ~0x300) | 0x300) & ~0x3C000) & ~0x40) | 0x20);
		regw32(aDriverRecPtr, 0x541C, regr32(aDriverRecPtr, 541C) | (1 << 3));
		regw32(aDriverRecPtr, 0x544C, 8);
		regw32(aDriverRecPtr, 0x4088, (regr32(aDriverRecPtr, 4088) & ~0xF) | 2);
		regw32(aDriverRecPtr, 0x544C, 0);
	}
	return noErr;
}
However, I could not find out why it could cause a kernel panic. Hope someone else could give an answer.

#46
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

Thanks for your interest and effort.
A roughly search of 0x544C did not give any results from radeonHD or ati open source. I then looked at the binary code of ATY_MegaLodon. It turns out the register address is visited in the procedures of PCIE_Gen1_Enable and PCIE_Gen2_Enable. Below is the disemblyed code of PCIE_Gen2_Enable:

OSStatus PCIE_Gen2_Enable(DriverGlobal *aDriverRecPtr) {
	 UInt32 value, value1;
	 pciepw32(aDriverRecPtr, 0xA2, pciepr32(aDriverRecPtr, 0xA2) & ~(1 << 13));
	 value = pciepr32(aDriverRecPtr, 0xA2);
	 if (value & (1 << 9))
		 pciepw32(aDriverRecPtr, 0xA2, ((((value | (1 << 10)) & ~7) | ((value & 0x70) >> 4)) | (1 << 8)) & ~(1 << 7));
	 else
		 pciepw32(aDriverRecPtr, 0xA2, value | (1 << 13));
	 value = pciepr32(aDriverRecPtr, 0xA4);
	 if ((value & (1 << 23)) && (value & (1 << 24))) {
		 regw32(aDriverRecPtr, 0x5488, regr32(aDriverRecPtr, 5488) & ~(1 << 25));
		 regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~(1 << 28));
		 regw32(aDriverRecPtr, 0x5404, regr32(aDriverRecPtr, 5404) | (1 << 25));
		 regw32(aDriverRecPtr, 0x5484, regr32(aDriverRecPtr, 5484) & ~0xF;
		 regw32(aDriverRecPtr, 0x5410, regr32(aDriverRecPtr, 5410) | (1 << 23));
		 regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~0x1E);
		 value = (value | 1) & ~2;
		 value1 = pciepr32(aDriverRecPtr, 0xA1);
		 if (value1 & (1 << 6)) pciepw32(aDriverRecPtr, 0xA1, value1 & ~0x40);
		 pciepw32(aDriverRecPtr, 0xA4, ((((value & ~0x300) | 0x300) & ~0x3C000) & ~0x40) | 0x20);
		 regw32(aDriverRecPtr, 0x541C, regr32(aDriverRecPtr, 541C) | (1 << 3));
		 regw32(aDriverRecPtr, 0x544C, 8);
		 regw32(aDriverRecPtr, 0x4088, (regr32(aDriverRecPtr, 4088) & ~0xF) | 2);
		 regw32(aDriverRecPtr, 0x544C, 0);
	 }
	 return noErr;
 }
However, I could not find out why it could cause a kernel panic. Hope someone else could give an answer.


Well I do have another hackbook that I can use to debug the kext with the kernel debug kit. I'll give it a try and tell you what happens.

Another interesting (maybe?) thing is that I skipped the 544c offset and now it panics at the exact same address that is next in the Megalodon fb, 0x4088.

#47
ridgeline

ridgeline

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 532 posts
  • Gender:Male
  • Location:Cape Coral, FL
oh for the love of OSX thank you guys for not giving up on this project

#48
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,019 posts
  • Gender:Male
  • Location:Moscow

Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to.

Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks.
Specifically, kernel panicks in rhd_init.c, function:

void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) {
	 *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value;
}

CARD16 offset was 544c, CARD32 value was 8

_RHDRegRead previously returned 0 for the offset 544c

Hope it helps

Bad offset can't cause kernel panic!
Kernel panic can be caused by bad rhdPtr. Check!

#49
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

Bad offset can't cause kernel panic!
Kernel panic can be caused by bad rhdPtr. Check!


If it was the case, somehow IOmap was read wrong for those cards. People can try change two lines in ATY_Init.cpp from
IOmap = device->mapDeviceMemoryWithIndex(RHD_MMIO_BAR);
to
IOmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress2);
and from
FBmap = device->mapDeviceMemoryWithIndex(RHD_FB_BAR);
to
FBmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0);
"mapDeviceMemoryWithRegister" is used by native drivers and I think it should found the correct map.

#50
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

If it was the case, somehow IOmap was read wrong for those cards. People can try change two lines in ATY_Init.cpp from

IOmap = device->mapDeviceMemoryWithIndex(RHD_MMIO_BAR);
to
IOmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress2);
and from
FBmap = device->mapDeviceMemoryWithIndex(RHD_FB_BAR);
to
FBmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0);
"mapDeviceMemoryWithRegister" is used by native drivers and I think it should found the correct map.


I'll check that and report back ASAP

#51
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

I'll check that and report back ASAP


Hehheh! Yeap, it worked! No kernel panic, and i got a nice weird display state :whistle:
I never imagined that seeing this would make me happy :whistle:

Considering this a success? I'll post the fixed source here later so everyone can try it with cards other than Mobility HD3650

Here's the Sourcecode.
For the record my log shows ASIC_Init Success as in your log dong. If you want the full log I can post it.

Attached Files



#52
LeoMark

LeoMark

    InsanelyMac Protégé

  • Members
  • Pip
  • 10 posts
I'm not believing! It is the best news of recent years! dong, thanoulas, slice, netkas, was everything that users ati mobility hd dreamed!
:) :D :D


I test on my hd2400 mobility, how do I proceed?
Please thanoulas, show the miracle!!!

#53
ridgeline

ridgeline

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 532 posts
  • Gender:Male
  • Location:Cape Coral, FL
You guys are far smarter than I could ever figure out. can you tell me what I would need to replace for my 3450HD Mobilty? and how does this need to be installed I want to test this myself.
Thanks, Mark

#54
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

You guys are far smarter than I could ever figure out. can you tell me what I would need to replace for my 3450HD Mobilty? and how does this need to be installed I want to test this myself.
Thanks, Mark


Guys, this is not even close to a driver yet. All it does is that it initialises the ATi cards by reading values from the BIOS. But it's a progress. And keep in mind I did not have anything to do with this, this is all dong's work.

If anyone still wants to try this out, build it with xcode, add your deviceID to the plist and load the kext in single user mode. See if it panics for you and report here your card and a log if possible. If all goes well you should see a weird display state. Yeah, that's good. And yeah, that's all it does for now.

#55
LeoMark

LeoMark

    InsanelyMac Protégé

  • Members
  • Pip
  • 10 posts
a doubt thanoulas and dong ... the values of the BIOS can help this? http://www.insanelym...howtopic=154469 or has nothing to do?
Still lack much for something permanent? What percentage of the project ready?
Sorry for many questions from noob ... Congratulations for the progress!
:thumbsdown_anim:

#56
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

a doubt thanoulas and dong ... the values of the BIOS can help this? http://www.insanelym...howtopic=154469 or has nothing to do?
Still lack much for something permanent? What percentage of the project ready?
Sorry for many questions from noob ... Congratulations for the progress!
:(


ATY_Init was actually created after netkas's request in order to help initialize secondary ati video cards (like on crossfire) because the secondary cards do not POST. I guess it could help to read the connections and the DDC from the bios, but this is based on linux code and the necessary functions are missing. One would have to implement these functions in order to test anything.

As far as the project is concerned (which is different from ATY_Init) no news yet. When and IF we have any success, be sure that we'll post about it.

#57
netkas

netkas

    InsanelyMac Legend

  • Developers
  • 616 posts
  • Gender:Male
anyone tried it with unposted card ?

Dong, can your driver set resolution (without interracting with os(IONDRV and friends)), just to complete card's initializing ?

hm, aty_init is subclass of iondrvframebuffer, and its not good for this case, it need to be subclass of iopcidevice

// made changes for aty_init to be child of IOPCIFamily, it all fine except panic in IOPCIFamily after ATIInit detached :rolleyes:

I have an idea how to identify posted card(and bypass asic_init for it)

Take a look at this pdf - http://www.phoenix.c...specsbbs101.pdf

page 33

so, need to dump binimage from memory(so from posted card), map it into Option Rom header struct, then get offset to PCI Data Structure (at 018h), then map PCI data structure from binimage and get device-id (offset 06h) and compare it to device-id provided by osx, if they match - the card was posted, if dont - it wasnt.

in this case combo of two same card might not work(but in this case there can be an option in plist to disable this logic)

#58
thanoulas

thanoulas

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts

hm, aty_init is subclass of iondrvframebuffer, and its not good for this case, it need to be subclass of iopcidevice

// made changes for aty_init to be child of IOPCIFamily, it all fine except panic in IOPCIFamily after ATIInit detached :)


I changed my code to convert the kext to IOPCIFamily child but i didn't get a kernel panic. The screen changed to the weird state, and after a couple of seconds it restarted on its own.. (I don't really know what happens when IOPCIFamily panics, was this it?)

So I added a couple of lines right before the return NULL at the end of the function:
device->terminate();
   
	this->terminate();

and tried again. Initializes fine, no kp, and no restart.

Ignore this, it does panic. No clue why though..

I have an idea how to identify posted card(and bypass asic_init for it)

Take a look at this pdf - http://www.phoenix.c...specsbbs101.pdf

page 33

so, need to dump binimage from memory(so from posted card), map it into Option Rom header struct, then get offset to PCI Data Structure (at 018h), then map PCI data structure from binimage and get device-id (offset 06h) and compare it to device-id provided by osx, if they match - the card was posted, if dont - it wasnt.

in this case combo of two same card might not work(but in this case there can be an option in plist to disable this logic)


Why read the option rom header, when we can read the device-id, vendor etc from the actual option rom (ATOMBIOS) that is already loaded in ATY_Init? We can get all the ATi devices through OSx and then compare them against the device-id we read from the atombios. If they don't match, then the card wasn't posted!

There you go, this should skip the asicinit function if the deviceID that was read from osx was the same as the one that was read from the bios

Attached Files



#59
netkas

netkas

    InsanelyMac Legend

  • Developers
  • 616 posts
  • Gender:Male

Why read the option rom header, when we can read the device-id, vendor etc from the actual option rom (ATOMBIOS) that is already loaded in ATY_Init? We can get all the ATi devices through OSx and then compare them against the device-id we read from the atombios. If they don't match, then the card wasn't posted!

There you go, this should skip the asicinit function if the deviceID that was read from osx was the same as the one that was read from the bios


bin_image from ioreg will match to card always(if natit was set up properly) need to read posted bios from ram, for devid comparision.

I had to implement basic power management, now it semy works, i got blue screen on unposted card :)

#60
netkas

netkas

    InsanelyMac Legend

  • Developers
  • 616 posts
  • Gender:Male
panic comes from

IOReturn IOPCIDevice::setPowerState( unsigned long powerState,
IOService * whatDevice )

this line

parent->setDevicePowerState( this, 1 );

when it tries to get call address for class function





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy