122 replies to this topic

[LeoMark]

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 ...  

[dong]

netkas, on Mar 28 2009, 05:51 AM, said:

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?

[thanoulas]

dong, on Mar 31 2009, 09:18 PM, said:

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

[super_engine]

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.

[dong]

thanoulas, on Apr 5 2009, 10:24 AM, said:

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.

[thanoulas]

dong, on Apr 6 2009, 01:24 AM, said:

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.

[ridgeline]

oh for the love of OSX thank you guys for not giving up on this project

[Slice]

thanoulas, on Apr 5 2009, 06:24 PM, said:

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!

[dong]

Slice, on Apr 16 2009, 01:25 AM, said:

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.

[thanoulas]

dong, on Apr 16 2009, 04:41 PM, said:

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

[thanoulas]

thanoulas, on Apr 16 2009, 07:07 PM, said:

I'll check that and report back ASAP

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

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

•  ATY_Init.zip   667.53K   61 downloads

[LeoMark]

I'm not believing! It is the best news of recent years! dong, thanoulas, slice, netkas, was everything that users ati mobility hd dreamed!
  


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

[ridgeline]

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

[thanoulas]

ridgeline, on Apr 16 2009, 11:30 PM, said:

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.

[LeoMark]

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!

[thanoulas]

LeoMark, on Apr 17 2009, 12:51 AM, said:

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.

[netkas]

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

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)

[thanoulas]

netkas, on Apr 17 2009, 06:53 PM, said:

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..

netkas, on Apr 17 2009, 06:53 PM, said:

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

•  ATY_Init.zip   747.69K   35 downloads

[netkas]

thanoulas, on Apr 18 2009, 04:18 AM, said:

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

[netkas]

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