Jump to content

Editing custom personalities for ATI Radeon HD[45]xx

bcc9

By bcc9,
in ATi

 Share
775 posts in this topic

Recommended Posts

bcc9
bcc9
Posted
Posted (edited)

The problem:
Under OSX the ATI driver uses a hard-coded set of personalities to define some of the video card's capabilities, most notably the connector layout. This is sufficient to support the limited number of configurations that Apple ships, but leads to non-working monitors (black displays) in many hackintosh configurations. Users have limited success & limited functionality by simply guessing which hard-coded personality best matches their video card.

Some prerequisites:

There are currently 26 ATI framebuffer personalities defined in ATIFramebuffer's Info.plist.
Each of these personalities defines a set of hard-coded information about the video card hardware. One of the key pieces that gets defined is the connector information, known as ConnectorInfo within the ATI driver.
There is one ConnectorInfo structure for every potential connector that may be plugged into a video card. (Dual link DVI ports still count as a single ConnectorInfo). Each personality defines a table of these ConnectorInfo structures.

The ConnectorInfo structure can be represented as the following 16 byte structure, in C code:
 

typedef struct {
int ConnectorType; /* known values below */
#define CONNECTORTYPE_LVDS 0x00000002 /* Ie internal Low Voltage display,
such as laptop */
#define CONNECTORTYPE_DVI_DUAL 0x00000004 /* Dual link(?) DVI */
#define CONNECTORTYPE_VGA 0x00000010 /* Per mucha */
#define CONNECTORTYPE_SVIDEO 0x00000080 /* Per mucha */
#define CONNECTORTYPE_DVI 0x00000200 /* Single link DVI(?), Per azimutz */
#define CONNECTORTYPE_DP 0x00000400 /* Displayport */
#define CONNECTORTYPE_HDMI 0x00000800

int controlflags;
int features;
byte link_i2cid; /* Bits 0-3: i2cid
Bits 4-7: link transmitter link */
byte dac_digidx; /* Bits 0-3: link encoder number
Bits 4-7: link dac number */
byte hotplugid;
byte senseid; /* Sense line is bits 0-3
Use hw i2c flag is bit 4 */
/* i2cid = (senseid & 0xf-1)+0x90 */
/* senseid = (i2cid & 0xf) +1*/
} ConnectorInfo;

where integers are represented in intel little-endian byte order, and bit 0 is the LSB.

Lets take a look at the driver's 32-bit code for seting up the ConnectorInfo.
otool -arch i386 -vt ATIFramebuffer | c++filt | grep createInfo
gives you the list of the 26 initialization routines.
For all personalities, the initialization routine sets the connector count and a pointer to a static array of ConnectorInfo.

I've written a script which will parse the personality initialization routines for you and calculate the effective address of the ConnectorInfo table, as well as the number of table entries. The script currently outputs information for all personalities found in the ATI Framebuffer kext.
Usage:
perl ati-personality.pl -386
to output 32-bit kext information, or
perl ati-personality.pl
to output 64-bit kext information
As of osx 10.7, the connectorinfo has been separated out across several ATI controller kexts, instead of ATIFramebuffer.
The script detects this automatically for 10.7 or 10.8 and prints information for all the controller kexts. However the 10.6.7 2011 MBP kexts also share this new layout and the script doesn't auto-detect this. For this case only, you should use the -a switch to tell the script to look in the new locations:
perl ati-personality.pl -a
to get the connectorinfo from their new locations with the 10.6.7 2011 MBP kexts.

See finding-patch-address.txt in the attached zip file for instructions if you wish to calculate the effective address & disk address yourself by hand.

Note: ati-personality.pl supports OSX 10.6.x where x >= 4, as well as 10.7 and 10.8. In older versions of OSX the ConnectorInfo structure was a different length (used to be 20 bytes instead of the current 16).

For example purposes lets focus on the 10.6.6 32-bit portion of the kext, and the uakari ConnectorInfo. From ati-personality.pl we learn:

Personality: Uakari
ConnectorInfo count in decimal: 4
Disk offset in decimal 226552
0000000 00 04 00 00 00 04 00 00 00 01 00 00 12 04 04 01
0000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 03
0000020 00 02 00 00 14 00 00 00 00 01 00 00 00 00 06 05
0000030 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 04
0000040

You can see above that the perl script found the location of the Uakari connector info and has dumped out the contents in hex.
You can also dump the ConnectorInfo yourself, see the xxd example below.

Next we take a look at the ConnectorInfo for this personality:

connector-type 0x00000400=displayport at port 0
connector-type 0x00000004=DVI at port 1
connector-type 0x00000200=single link DVI(probably) at port 2
connector-type 0x00000800=HDMI at port 3

Booting kabyl's chameleon branch on my Sapphire Radeon 5670 with this personality results in working DVI and working HDMI (with no audio). Note that due to a bug in that code, overriding the personality from Baboon (the default with 3 connectors total) to Uakari results in 3 injection strings not 4. So the 5670 hardware's ports are matched against only the first 3 entries in the uakari table.

Looking at the ioregistry, one can see that port-number 1&2 matched and port 0 did not. (ATY_ActiveFlags != 1 when the port is matched).
So my HDMI port was matched but with the wrong connector type (0x0002). This causes HDMI audio to fail.
To fix this I overwrote bytes 0 thru 15 of port 2's table entry with port 3's.
You can do this using your favorite hex editor.
xxd, followed by ascii editing, followed by xxd -r is probably the simplest choice. For example:

% cd /System/Library/Extensions/ATIFramebuffer.kext/Contents/MacOS/
% ls -l ATIFramebuffer
-rw-r--r-- 1 root wheel 304556 Mar 2 16:57 ATIFramebuffer
% dd if=ATIFramebuffer of=/tmp/uakari bs=1 skip=226552 count=64
% cd /tmp
% xxd < uakari > hex
% cat hex
0000000: 0004 0000 0004 0000 0001 0000 1204 0401 ................
0000010: 0400 0000 1400 0000 0001 0000 0112 0103 ................
0000020: 0002 0000 1400 0000 0001 0000 0000 0605 ................
0000030: 0008 0000 0002 0000 0001 0000 2205 0504 ............"...
%

Since there are 4 connectors for this personality, we dump 4*16=64 bytes in the dd command shown above.
Now you edit the ConnectoIinfo table with your favorite text editor and dd the result back in place:

% xxd -r < hex > uakari.new
% dd if=uakari.new of=/System/Library/Extensions/ATIFramebuffer.kext/Contents/MacOS/ATIFramebuffer bs=1 count=64 seek=226552 conv=notrunc

The resulting table with the 3rd row changed:

% cat hex
0000000: 0004 0000 0004 0000 0001 0000 1204 0401 ................
0000010: 0400 0000 1400 0000 0001 0000 0112 0103 ................
0000020: 0008 0000 0002 0000 0001 0000 2205 0505 ............"...
0000030: 0008 0000 0002 0000 0001 0000 2205 0504 ............"...

Note that since the 32bit & 64bit connectorinfo tables are the same, you can simply repeat the last dd step above with the proper disk offset for the 64 bit table, in order to update that table as well.

With the above edit, my HDMI audio port is recognized as type 0x0800, with the usual HDMI flags, but with the expected sense line (0x05). And viola, HDMI audio now works!

Next, my Sapphire radeon 5670 actually has 3 ports - HDMI, DVI and displayport, and, alas, this personality is only working with 2 of them, even though the personality does include a displayport connector. Luckily I was able to find a different personality with which this card's displayport did work, the Vervet personality.

Again from ati-personality.pl, we find Vervet's ConnectorInfo:

Personality: Vervet
ConnectorInfo count in decimal: 4
Disk offset in decimal 226616
0000000 00 04 00 00 00 04 00 00 00 01 00 00 12 04 04 02
0000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 04
0000020 00 02 00 00 14 00 00 00 00 01 00 00 00 00 06 03
0000030 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 01
0000040

My card does in fact match port-number 0 for the DP port, as seen in the ioregistry.
So I copy the working senseid field from the vervet personality into the Uakari personality (replace the 0x01 at byte 15 of the first line with 0x02).
Viola, all 3 ports are now working with my card...

Hope this helps others with non-working ports or with HDMI audio problems.
Questions/comments?

radeon_bios_decode.0.2.zip

ati-personality.pl.0.15.zip

ati-personality-0.15-sierra.zip

Edited by fantomas1
added macOS Sierra version: http://www.insanelymac.com/forum/topic/303186-how-to-modification-of-amd-fb-clover-injection/page-14#entry2244234
  • Like 6
Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
The ConnectorInfo structure can be represented as the following 16 byte structure, in C code:

 

 typedef struct {
   int ConnectorType;	/* known values below */
  #define CONNECTORTYPE_DVI  0x0004
  #define CONNECTORTYPE_DP   0x0400	/* Displayport */
  #define CONNECTORTYPE_HDMI 0x0800
   int flags;
   int features;
   byte link_i2cid;	/* Bits 0-3: i2cid
			  Bits 4-7: link transmitter link */
   byte dac_digidx;	/* Bits 0-3: link encoder number
			  Bits 4-7: link dac number */
   byte hotplugid;
   byte senseid;	/* Sense line is bits 0-3
			 Use hw i2c flag is bit 4 */
  } ConnectorInfo;

Thank you bcc9! I was wondering what the other fields are used for.

 

Booting kabyl's chameleon branch on my Sapphire Radeon 5670 with this personality results in working DVI and working HDMI (with no audio). Note that due to a bug in that code, overriding the personality from Baboon (the default with 3 connectors total) to Uakari results in 3 injection strings not 4. So the 5670 hardware's ports are matched against only the first 3 entries in the uakari table.

I'll have to fix that, thanks.

 

Hope this helps others with non-working ports or with HDMI audio problems.

Questions/comments?

We need more people like you ;)

  • Like 2
Link to comment
Share on other sites
Boombeng
Boombeng
Posted
Posted

I had a look to enable hdmi audio on my HD4850 (2xdvi + s-video)

Here is the atombios connector dump :

Audio chip info: 0

Connector at index 0 type: DVI-I (2)

Connector at index 1 type: DVI-I (2)

Connector at index 2 type: 9 pin DIN (9)

Connector at index 4 type: DVI-I (2)

Connector at index 5 type: DVI-I (2)

Under Windows it is possible to have audio output using a dvi>hdmi dongle

Using Motmot personnality of Atiframebuffer both dvi ports work well but ther is no audio

 

Following your instructions i found this for motmot :

 

addl $0x00010d60 (68960)

movb $0x02

 

offset_for_segment = 61624

start_address_for_segment = 0000ed80 (60800)

 

total = 225432

 

at 225432 dec address in bin :

 

00 04 00 00 04 01 00 00 00 01 00 00 10 00 02 03

04 00 00 00 14 02 00 00 00 01 00 00 01 11 01 04

 

looking ioregistry i can see port 0 and 1 are matched when i plug 2 displays in dvi

 

Would that be possible to enable audio or the lack of hdmi connector in atombios is a problem ?

 

Thanks again

  • Like 1
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Thank you bcc9! I was wondering what the other fields are used for.
Thanks. I think I also have a bunch of the feature flag bits mapped but I haven't been able to verify them.

 

With some more understanding, we might be able to auto-patch these tables for 3rd party cards.

I'll have to fix that, thanks.

 

 

We need more people like you -_-

Glad you can pick that up without a real bug report :D

Yes, actual developers are pretty rare around here. It's too bad there isn't a good, active hackintosh developer forum.

 

How did you connect Displayport from your monitor? Or, do do you have Displayport monitor?

My dell u3011 has displayport. Works for me at 2560x1600.

Maybe I should pick up a DP->HDMI adapter so I can try HDMI audio over DP.

 

Would that be possible to enable audio or the lack of hdmi connector in atombios is a problem ?

That would depend upon the capabilities of your video card. Your card's DVI ports may carry HDMI audio (but probably not). To know for sure, check your lspci output.

Borrowing from Kabyl's post:

lspci -nnvd 0x1002: | grep -B2 Subsystem

Would show you two PCI devices if your video card supports audio. The second PCI device with audio class (0403) would be the audio device. Example:

 lspci -nnvd 0x1002: | grep -B2 Subsystem
 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Redwood [Radeon HD 5670] [1002:68d8] (prog-if 00 [VGA controller])
	  Subsystem: PC Partner Limited Device [174b:e151]
 --

 01:00.1 Audio device [0403]: ATI Technologies Inc Redwood HDMI Audio [Radeon HD 5600 Series] [1002:aa60]
	  Subsystem: PC Partner Limited Device [174b:aa60]

Link to comment
Share on other sites
VCH888
VCH888
Posted
Posted
My dell u3011 has displayport. Works for me at 2560x1600.

Maybe I should pick up a DP->HDMI adapter so I can try HDMI audio over DP.

Can you get sound out thru 3 audio jacks if connecting to HDMI or DisplayPort?

 

I tried DP -> HDMI on my Sapphire HD7550 and got duplicate, not mirror. Connecting DVI to LCD monitor and DP -> HDMI to LCD TV. Display in System Profiler showed me only LCD monitor. So, I think I could get DP port working properly if I had a monitor with display port or used either DP2VGA or active DP2DVI.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Can you get sound out thru 3 audio jacks if connecting to HDMI or DisplayPort?

 

I tried DP -> HDMI on my Sapphire HD7550 and got duplicate, not mirror. Connecting DVI to LCD monitor and DP -> HDMI to LCD TV. Display in System Profiler showed me only LCD monitor. So, I think I could get DP port working properly if I had a monitor with display port or used either DP2VGA or active DP2DVI.

What do you mean by 3 audio jacks?

 

Under system profiler, or via "system_profiler SPDisplaysDataType" from the shell, I can see all 3 of my card's ports show up as separate addressable displays.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Very interesting.

 

Do you see any possibility of enabling LVDS output (as in older FB such as Wormy) in the newer FB (such as Peregrine) so those of us with Mobility Radeons can use laptop display?

 

http://www.projectosx.com/forum/index.php?showtopic=9

And that's an interesting connector table. Assuming it's right about the LVDS ports, that would make:

 

#define CONNECTORTYPE_LVDS 0x0002

as an addition to post #1, which is actually what I thought but was uncertain.

Since there are apple products shipping with mobile radeons, yes I see no reason why you shouldn't be able to make 3rd party mobile radeons work, at least for gpus sufficiently similar to the genuine apple models.

Link to comment
Share on other sites
jsl
jsl
Posted
Posted
Some prerequisites:
  • Installation of OSX Developer tools (for examining personalities with otools)
    Somewhat working install of ATI radeon HD[45]xx card with Kabyl's chameleon branch:
http://www.insanelymac.com/forum/index.php?showtopic=231768
Understanding of hex editing
Ability to troubleshoot by looking at ioregistry, understanding how to test ATI personalities using ATIConfig

 

This is a first draft

 

There are currently 26 ATI framebuffer personalities defined in ATIFramebuffer's Info.plist.

Each of these personalities defines a set of hard-coded information about the video card hardware. One of the key pieces that gets defined is the connector information, known as ConnectorInfo within the ATI driver.

There is one ConnectorInfo structure for every potential connector that may be plugged into a video card. (Dual link DVI ports still count as a single ConnectorInfo). Each personality defines a table of these ConnectorInfo structures.

 

The ConnectorInfo structure can be represented as the following 16 byte structure, in C code:

 

 typedef struct {
   int ConnectorType;	/* known values below */
  #define CONNECTORTYPE_DVI  0x0004
  #define CONNECTORTYPE_DP   0x0400	/* Displayport */
  #define CONNECTORTYPE_HDMI 0x0800
   int flags;
   int features;
   byte link_i2cid;	/* Bits 0-3: i2cid
			  Bits 4-7: link transmitter link */
   byte dac_digidx;	/* Bits 0-3: link encoder number
			  Bits 4-7: link dac number */
   byte hotplugid;
   byte senseid;	/* Sense line is bits 0-3
			 Use hw i2c flag is bit 4 */
  } ConnectorInfo;

 

where integers are represented in intel little-endian byte order, and bit 0 is the LSB.

 

Lets take a look at the driver's 32-bit code for seting up the ConnectorInfo.

otool -arch i386 -vt ATIFramebuffer | c++filt | grep createInfo

gives you the list of the 26 initialization routines.

For all personalities, the initialization routine sets the connector count and a pointer to a static array of ConnectorInfo.

 

The address of the ConnectorInfo table can be found by looking at the assembly code for the personality's createInfo routine. Specifically the address can be found in the last addl instruction in the routine. The exception is the case where the table has only one connector. In that case there is no addl instruction, instead look for the movl instruction with 0x0c(%eax) as second operand.

In both cases, the address of the ConnectorInfo structure is the hex address reported in the first operand of the instruction.

 

The number of connectors can generally be found by looking at the movb instruction whose second operand is 0x03(%ecx). (The Wormy personality is the exception, I'm not sure why).

 

Now lets take a specific example, the Uakari personality. In UakariInfo::createInfo we see 1 addl instruction, it reads (I'm looking using 10.6.6 driver code as an example from here on):

0000d472 addl $0x000111c0,%eax

and for the number of connectors,

0000d467 movb $0x04,0x03(%ecx)

 

So 0x111c0 is the address of the ConnectorInfo, and there are 4 of them.

 

Next we will want to convert this virtual memory address to an offset in the file for our viewing and editing convenience.

 

  1. lipo -detailed_info ATIFramebuffer
    reports file offsets for the FAT binary. In the offset field under i386 architecture, we see 155648 (decimal)
  2. otool -arch i386 -l ATIFramebuffer
    Find the section whose address+size includes the above virtual address within its range (111c0). In this case the we have a data segment that starts at 111c0 exactly. otool reports a file offset of 70904 (decimal) for that segment.
  3. So the address on disk for this virtual address is:
    offset_in_file = start_offset_for_architecture + offset_for_segment + virtual_address - start_address_for_segment
     
    where start_offset_for_architecture as reported by lipo above
    start_address_for_segment, offset_for_segment as reported by otool above
    virtual_address is the address obtained from the addl instruction.
     
    Numerically, the address on disk is:
     
    155648+70904+0x111c0-0x111c0=226552

Now we take a look at the ConnectorInfo therein. Since there are 4 connectors for this personality, we want to look at 64 bytes:

 dd if=ATIFramebuffer of=/tmp/uakari bs=1 skip=226552 count=64
  od -Ax -tx1 /tmp/uakari
  000000 00 04 00 00 00 04 00 00 00 01 00 00 12 04 04 01
  000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 03
  000020 00 02 00 00 14 00 00 00 00 01 00 00 00 00 06 05
  000030 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 04
  000040

So we have for this personality

connector-type 0x0400=displayport at port 0

connector-type 0x0004=DVI at port 1

connector-type 0x0002=?? at port 2

connector-type 0x0800=HDMI at port 3

 

Booting kabyl's chameleon branch on my Sapphire Radeon 5670 with this personality results in working DVI and working HDMI (with no audio). Note that due to a bug in that code, overriding the personality from Baboon (the default with 3 connectors total) to Uakari results in 3 injection strings not 4. So the 5670 hardware's ports are matched against only the first 3 entries in the uakari table.

 

Looking at the ioregistry, one can see that port-number 1&2 matched and port 0 did not. (ATY_ActiveFlags != 1 when the port is matched).

So my HDMI port was matched but with the wrong connector type (0x0002). This causes HDMI audio to fail.

To fix this I overwrote bytes 0 thru 15 of port 2's table entry with port 3's.

You can do this using your favorite hex editor. I used emacs :)

xxd, followed by ascii editing, followed by xxd -r is probably a less awkard choice.

 

The resulting table with the 3rd row changed:

 od -Ax -tx1 /tmp/uakari
  000000 00 04 00 00 00 04 00 00 00 01 00 00 12 04 04 01
  000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 03
  000020 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 05
  000030 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 04
  000040

Now my HDMI audio port is recognized as type 0x0800, with the usual HDMI flags, but with the expected sense line (0x05). And viola, HDMI audio now works!

 

Next, my Sapphire radeon 5670 actually has 3 ports - HDMI, DVI and displayport, and, alas, this personality is only working with 2 of them, even though the personality does include a displayport connector. Luckily I was able to find a different personality with which this card's displayport did work, the Vervet personality.

 

Using the above procedure, I find Vervet's ConnectorInfo at

0x11200, with 4 connectors. On disk:

155648+70904+0x11200-0x111c0=226616

 

 dd if=ATIFramebuffer of=/tmp/vervet bs=1 skip=226616 count=64
  od -Ax -tx1 /tmp/vervet
  000000 00 04 00 00 00 04 00 00 00 01 00 00 12 04 04 02
  000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 04
  000020 00 02 00 00 14 00 00 00 00 01 00 00 00 00 06 03
  000030 00 08 00 00 00 02 00 00 00 01 00 00 22 05 05 01
  000040

My card does in fact match port-number 0 for the DP port, as seen in the ioregistry.

So I copy the working senseid field from the vervet personality into the Uakari personality (replace the 0x01 at byte 15 of the first line with 0x02).

Viola, all 3 ports are now working with my card...

 

Hope this helps others with non-working ports or with HDMI audio problems.

Questions/comments?

Thanks for your detailed guide for us.

My EAH5850 has this personality of Uakari FB found by IORegistryExplorer:

connector-type 0x0400=DP at port 0

connector-type 0x0004=DVI at port 1

connector-type 0x0200=DVI at port 2

connector-type 0x0800=HDMI at port 3

Currently only DVI at port 1 and port 2 are working for me by any two of the three (DVI->DVI, DVI->VGA, DVI->HDMI ).

But I can detect two PCI address for my EAH5850: one for VGA and the other for audio device by lspci.

According to your theory what is the best way to change it to get my HDMI audio working with Uakari FB ?

Link to comment
Share on other sites
VCH888
VCH888
Posted
Posted
What do you mean by 3 audio jacks?

 

Under system profiler, or via "system_profiler SPDisplaysDataType" from the shell, I can see all 3 of my card's ports show up as separate addressable displays.

I looked at your Dell u3011 specification from this web site, it told me that U3011 has Audio output. So, I asked you whether or you can audio out from the monitor.

 

Thanks.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
I looked at your Dell u3011 specification from this web site, it told me that U3011 has Audio output. So, I asked you whether or you can audio out from the monitor.

Thanks for reminding me, I had actually forgotten I had those ports on my 3011!!

So yes, I just tested it and I do in fact get working audio out those discrete 5.1 ports when I have hdmi or displayport attached. With displayport attached, the audio device is displayed as "DisplayPort", when the hdmi port is attached, the audio device is displayed as "HDMI", when both are attached, still just "DisplayPort".

 

attach_add.png

post-382001-1298954923_thumb.jpg

Link to comment
Share on other sites
VCH888
VCH888
Posted
Posted
Thanks for reminding me, I had actually forgotten I had those ports on my 3011!!

So yes, I just tested it and I do in fact get working audio out those discrete 5.1 ports when I have hdmi or displayport attached. With displayport attached, the audio device is displayed as "DisplayPort", when the hdmi port is attached, the audio device is displayed as "HDMI", when both are attached, still just "DisplayPort".

 

attach_add.png

 

Thanks. This monitor is useful.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Thanks for your detailed guide for us.

If my EAH5850 has this personality of Uakari FB:

connector-type 0x0004=DVI at port 0

connector-type 0x0200=DVI at port 1

connector-type 0x0400=DP at port 2

connector-type 0x0800=HDMI at port 3

And currently only DVI at port 0 and port 1 are working for me.

But I can detect two PCI address for my EAH5850: one for VGA and the other for audio device by lspci.

According to your theory what is the best way to change it to get my HDMI audio working with Uakari FB ?

I'm not sure where you get that layout for Uakari, I did decode it in post #1, showing a different layout. When I wrote "ports" in that post I meant as enumerated in the ConnectorInfo array. These are reported as "port-number" = x in the IORegistry where x is numbered starting at 0. For example:

	 | |   |	 +-o ATY,Uakari@0  <class IOFBStub, id 0x1000002a2, registered, matched, active, busy 0 (223 ms), retain 7>
 | |   |	 | | {
 | |   |	 | |   "port-number" = 1
 | |   |	 | |   "display-type" = "LCD"
 | |   |	 | |   "connector-type" = 4
 | |   |	 | |   "ATY,ActiveFlags" = 4
 | |   |	 | |   "IOFBDependentIndex" = 0
 | |   |	 | |   "IOFBDependentID" = 117281408
 | |   |	 | |   "ATY,ControlFlags" = 20
 | |   |	 | |   "AAPL,gray-page" = <01000000>
 | |   |	 | |   "av-signal-type" = 2
 | |   |	 | |   "AAPL,gray-value" = <c38c6400>
 | |   |	 | |   "display-connect-flags" = <00000000>
 | |   |	 | |   "name" = <"ATY,Uakari">
 | |   |	 | |   "AAPL,boot-display" = <01000000>
 | |   |	 | | }

shows the second Uakari table entry, port number 1:

 000010 04 00 00 00 14 00 00 00 00 01 00 00 01 12 01 03

matching as display #0 for my video card. I can see that it successfully matched because ATY,ActiveFlags != 1. Notice also the connector-type = 4 value corresponding to the 04 00 00 00 in the table.

 

So given that, I assume your video card is the Asus model with displayport and hdmi ports, and they aren't matching the ports in the uakari table due to the senseid.

 

So in post #1 I recommended that you could find some other personalities where those ports do work to "discover" the working value for the senseid. Another choice would be to guess what that value should be. Or help figure out how to determine the value automatically from the atom bios or directly from the card :)

 

Thanks. This monitor is useful.

Yes, thanks, now we know displayport audio does work with my example config, no DP->HDMI dongle required to test. Not so useful in practice to have 3 ports all going between the same card and display :)

Link to comment
Share on other sites
wmarsh
wmarsh
Posted
Posted
And that's an interesting connector table. Assuming it's right about the LVDS ports, that would make:

 

#define CONNECTORTYPE_LVDS 0x0002

as an addition to post #1, which is actually what I thought but was uncertain.

Since there are apple products shipping with mobile radeons, yes I see no reason why you shouldn't be able to make 3rd party mobile radeons work, at least for gpus sufficiently similar to the genuine apple models.

bcc9, if you otool -arch i386 -vt ATIFramebuffer I can see the addl for each framebuffer, and find the address as you say.

 

However, otool -arch x86_64 -vt ATIFramebuffer does not show an addl in the CreateInfo section

 

Are you booting -arch i386 after this mod? Or does making the 1 change in the table still work for you booting into the normal 64 bit mode?

 

I am not sure you are correct about the LVDS Connector type.

Wormy looks to me like its 1st port is 0x8000 [edit -- error in address]

Iago, and the new Nomascus look like its 0x0200

 

I will try both and see if either works

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
bcc9, if you otool -arch i386 -vt ATIFramebuffer I can see the addl for each framebuffer, and find the address as you say.

 

However, otool -arch x86_64 -vt ATIFramebuffer does not show an addl in the CreateInfo section

I normally only boot my hackintosh systems in 32 bit mode as that is how genuine macs run under 10.6. (If Apple is treating 64 bit mode as bleeding edge, why venture into the uncharted territory with no noticible performance difference?)

 

Anyways, yes, for examining&patching the 64-bit code, the instructions are necessarily a bit different, as the addressing modes are different.

 

For the 64-bit address of the ConnetorInfo table, look at the last leaq instruction. Compute the effective address by adding the operand's constant to the address of the next instruction. So in the Uakari case:

 000000000000db7e	leaq	0x00004cbb(%rip),%rdi
 000000000000db85	movslq	%ecx,%rax

The effective address for the lea instruction is 0x4cbb+0xdb85=0x12840

And for routines whose table has only one connector, look for the leaq instruction that immediately proceeds the movq with 0x10(%rsi) as the second operand. Compute the effective address as above.

 

Once you have this effective address, you should be able to convert from virtual address to disk offset as described in post #1.

Are you booting -arch i386 after this mod? Or does making the 1 change in the table still work for you booting into the normal 64 bit mode?
I don't think it's even possible to share data between architectures in a fat binary (unless it's done thru a file). So yes, there are duplicate copies of all the ConnectorInfo tables for both architectures.

 

I am not sure you are correct about the LVDS Connector type.

Wormy looks to me like its 1st port is 0x8000

Huh? Where do you get that from? For wormy:

 

dd if=ATIFramebuffer of=/tmp/wormy bs=1 skip=221720 count=32

od -Ax -tx1 /tmp/wormy

000000 02 00 00 00 40 00 00 00 29 00 00 00 00 01 01 03

000010 04 00 00 00 16 00 00 00 00 00 00 00 00 10 02 01

 

So

port-number 0, connector-type 0x00000002 = LVDS

port-number 1, connector-type 0x00000004 = DVI

 

In my #defines, the integers are in native/host byte order (little endian).

Link to comment
Share on other sites
wmarsh
wmarsh
Posted
Posted
Huh? Where do you get that from? For wormy:

 

dd if=ATIFramebuffer of=/tmp/wormy bs=1 skip=221720 count=32

od -Ax -tx1 /tmp/wormy

000000 02 00 00 00 40 00 00 00 29 00 00 00 00 01 01 03

000010 04 00 00 00 16 00 00 00 00 00 00 00 00 10 02 01

 

So

port-number 0, connector-type 0x00000002 = LVDS

port-number 1, connector-type 0x00000004 = DVI

 

In my #defines, the integers are in native/host byte order (little endian).

I'll recheck my math; I got skip 221144 (hex 35fd8) for Wormy. Wondered why it looked so weird.

 

[EDIT]

Found the problem. Wormy has 3 addl

for wormy, 32 bit

start for arch + offset + virtual add - start for seg

155648 + 61624 + fee0 - ed80 = 221720

 

You are correct, but I learn by example

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Found the problem. Wormy has 3 addl

Yes, and the instructions for 32-bit were to look at the last addl of the routine, which does direct you to the right one in this case (and the other cases from what I can see).

 

I did also provide an example, with the math, in post #1.

 

Seems like a perl script may be in order here...

Link to comment
Share on other sites
wmarsh
wmarsh
Posted
Posted
Yes, and the instructions for 32-bit were to look at the last addl of the routine, which does direct you to the right one in this case (and the other cases from what I can see).

 

I did also provide an example, with the math, in post #1.

 

Seems like a perl script may be in order here...

No your instructions were good, I just was working too fast.

And the last time I read decompiled binaries I was using a Z-80 cpu, so I am out of practice.

 

The first test for LVDS did not work. I tried MotMot and GraphicsEnabler=y, but I think Graphics Enabler injects at the right place for desktop cards, and my study of my DSDT (esp considering Nvidia laptops vs desktop hacks) suggests this is not correct for mobility cards. So I am going to try again with DSDT hack instead.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
So in post #1 I recommended that you could find some other personalities where those ports do work to "discover" the working value for the senseid. Another choice would be to guess what that value should be. Or help figure out how to determine the value automatically from the atom bios or directly from the card :)

Ok, I believe I've mapped the senseid field to the atom bios!

i2cid = (senseid & 0xf-1)+0x90;

or the inverse:

senseid = (i2cid & 0xf) +1;

Now here's a version of my radeondump that will print the i2cids for the connectors.

Edit: See radeon_bios_decode in post #1 for newer version that computes the senseid value for you, and also prints encoder information.

 

For example, for my sapphire card:

./radeondump < rom
  ATOM BIOS Rom: 
		  SubsystemVendorID: 0x174b SubsystemID: 0xe151
		  IOBaseAddress: 0x0000
		  Filename: 3E151DAF.HY1
		  BIOS Bootup Message: 
  REDWOOD XT C02002 GDDR5 64Mx16 1G UCODEv:126							   

  Connector at index 0 type: DisplayPort (10)
  Connector's i2cid: 91
  Connector at index 1 type: HDMI-A (11)
  Connector's i2cid: 94
  Connector at index 2 type: DVI-I (2)
  Connector's i2cid: 92
  Connector at index 3 type: DVI-I (2)
  Connector's i2cid: 92

(In the above the i2cid is printed base 16).

 

So the senseid values are:

DP: (91&0xf)+1 = 2

HDMI: (94&0xf)+1=5

DVI: (92&0xf)+1=3

 

These exactly match the senseid that I found in post #1 by experimentation.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...