Jump to content
696 posts in this topic

Recommended Posts

Ok...so...this is wierd, can some body tell me if the ati sound cards are the same in the x200 chipsets how come some people have a realtek and some people have conexant does it have to do with like desktop or laptop or...is the problem how the southbridge adresses the sound card I am a little confused as to how a fix for realtek cards is gonna help those with conexant cards or vice versa...or am i just like a complete retard and totally off base...sorry if this sounds noobish...

actually brandon, ur right on, and that seems to be the problem i just ran into. It appears the desktop chips use and realtek ALC655 codec, and the notebooks use something else, but both have vendor id as 1002 4370, which is from ATI. It would also seem that at least some of the Intel ICH series use the same codec chip.

 

This leads to an interesting problem about developing the driver, the key is to figure out exactly what system is similar to the SB400 chip, and see how that driver developed in other OS's like linux or *bsd and then develop in the same way for MAC OS.

 

That's the research that has been occupying me for the last couple hours. I have some def specs and pdf's to leaf through to see if there are similarities that can be exploited, otherwise this driver is going to have to come from total scratch.

 

Since I am on a laptop there's only certain things I can test, so when the time comes, we're gonna need some people with the desktop versions to test the driver, and yeah, that's what Im to up to right now.

 

Its possible code started by scousi may be able to be finished by me, but I still need to get his source code that he started to finish it. Hopefully this can be a nice collaborative effort.

fireshark, can u figure out if its an actual conexant codec chip, or a realtek chip being loaded by the Conexant AMC Audio driver.

 

also i've noticed the x64 windows driver is supplied by ATI.

 

Does anyone know a way of determining exactly what codec chip the computer uses, possibly from windows or linux?

fireshark, can u figure out if its an actual conexant codec chip, or a realtek chip being loaded by the Conexant AMC Audio driver.

 

also i've noticed the x64 windows driver is supplied by ATI.

 

Does anyone know a way of determining exactly what codec chip the computer uses, possibly from windows or linux?

 

Mine is the Realtek 255.

 

EdFlyer, I'm still looking for the code I had. I has lost my HD but i know that the I have a backup. The question is where did I put the backup!

 

Duhh!

 

:D

 

BTW, did you ever manage to get the Interrupts captured?

 

Are you using IO mapping or Memory mapping? I only have BAR0 availiable on my device. Do you have any other BARS on yours?

Hi Ed, I don´t know i´ve it would help you, but when I load the konoppix 4.0.2 my sound works well. But i´m not so into linux to post you the log you need.

I´ve u would give me a little bit advice I would look it up for you. Or you just DL the Knoppix by your self.

 

Hope it helped.

i'm not 100% sure what's going with my driver.....i think my problem may be in the interrupts, but i don't know. I'd like to get a working log of the linux driver to see what's done in what order and compare that. Unfortunately college classes are getting in the way of the driver development, but I'll have free time later.

the boot log from when the driver loads in linux is what i'm looking for. I would like to trace what happens, and in what order, so that I can make sure the driver's loading the right stuff in the correct order.

 

oh scousi, im not sure what you meant with the interrupts, but it seems to attach correctly to irq 17 with an io of 3400, but I'm not sure entirely the meaning of the io number.

 

alright, im off to more debugging and coding.

the boot log from when the driver loads in linux is what i'm looking for. I would like to trace what happens, and in what order, so that I can make sure the driver's loading the right stuff in the correct order.

 

oh scousi, im not sure what you meant with the interrupts, but it seems to attach correctly to irq 17 with an io of 3400, but I'm not sure entirely the meaning of the io number.

 

alright, im off to more debugging and coding.

 

Your best bet is to look at the linux atiixp source code (attached) and the ALSA documentation. There is a lot of similarities between Linux and Macs initialize PCI card drivers.

 

With the IXP, you need the interrupt to detect the 3 codec devices. You will have to learn on how the read and write to the ATI registers. The atiixp.c module has all the register offsets defined. You will need these since there is no public ATI documentation. The driver will never work unless you set up the proper framework to read and write to the proper registers. You have to service the interrups that the card generates. The trick is to set up your DMA or IO access correctly. You absolutely need the proper offsets and status bits. That's why you will find the values defined in the atiixp module quite usefull.

 

Also get this:

 

ftp://ftp.apple.com/developer/Tool_Chest/.../CHUD_4.3.2.dmg

 

CHUD tools. There is a utility in there called Regie SE that allows you to view all the low level stuff. You can read and write the registers if you know the proper offsets.

 

Good luck.

 

the atiixp.txt is actually atiixp.c but they won't let me upload a .c file for some reason.

atiixp.txt

yeah, i've been working off that for a while, my problem is there is an access timeout that occurs when the code checks to see if the ac-link is not busy. i was hoping for a boot log from linux to see if I had loaded something the wrong or at the wrong time or in the wrong order.

 

i shall continue testing this evening.

Here's the part of the dmesg which seams to correspond to sound initialization:

 

Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 209
ACPI: PCI Interrupt 0000:00:14.6[B] -> GSI 17 (level, low) -> IRQ 209
MC'97 0 converters and GPIO not ready (0x1)
ALSA device list:
 #0: ATI IXP rev 1 with unknown codec at 0xb0003400, irq 209
 #1: ATI IXP Modem rev 1 at 0xb0003800, irq 209

 

I'm not sure if there's more to it, so I'm including the full dmesg in case there's something else. I installed this kernel late last week, and sound is working on it.

dmesg.txt

hey guys I'm not as smart as you guys as far as the coding and debugging for the driver goes, but if you can think of any way I could help you out, let me know. It doesnt feel right to just sit here and wait for you guys to finish and then just reap the rewards for doing nothing :)

Any news in this projekt?

 

Is the homepage up soon, or!?

 

I'm just curious.. :)

 

I've been working on it lately. I found my backup of the source code.

 

The problem I'm having so far is getting the device to fire interrupts and mapping the DMA buffers to the device.

I've been working on it lately. I found my backup of the source code.

 

The problem I'm having so far is getting the device to fire interrupts and mapping the DMA buffers to the device.

 

 

Here's the source code if anyone want to take a look. It doesn't work however.

ati.tar.gz

well, i've been working off scousi's and mine source code and checking against the linux code. I've run into an interesting problem where there's an infinite loop occuring, but its not occuring in the code that we developed, but in the code that came from Apple. So, hopefully is a matter of figuring out where the loop is originally called from, and then tracing the steps that cause that.

 

The good news is that the river is loading more or less and that we can control volume, but anytime it attmpets to play a sound it hits the inifite loop, so that's the current status for the curious.

thanks! I love updates-- I think I check this thread about once an hour. it sounds like you're close. once I get garageband installed, i'm naming my mac drive 'scousi' and my windows drive 'edflyer' so they'll be right there on the desktop all the time and i'll never forget the blood sweat and tears sacrificed for my hackintosh....

well, i've been working off scousi's and mine source code and checking against the linux code. I've run into an interesting problem where there's an infinite loop occuring, but its not occuring in the code that we developed, but in the code that came from Apple. So, hopefully is a matter of figuring out where the loop is originally called from, and then tracing the steps that cause that.

 

The good news is that the river is loading more or less and that we can control volume, but anytime it attmpets to play a sound it hits the inifite loop, so that's the current status for the curious.

 

Can you send me what you are talking about? (PM). I've cleaned up my code a liitle by actually using the Linux functions. (Sorry about the mess but this is a hack, no QA on my back). I don't have the master volume working either. The driver isn't actually crashing. Another weirdness is that DebugLog only logs when it's called from code within AppleAC97AudioATIIXP.cpp module.

 

THe DMA mappings just don't seem to happen. We must find a way to kick-start the whole thing. I'm also a little suspicious about the source since it didn't compile without any tweaks.

 

I have enclosed an update to the code.

 

The problem I'm having is this:

 

Mar 29 21:26:02 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1]

Mar 29 21:26:02 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1] IS ALREADY RUNNING

Mar 29 21:26:02 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:02 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:02 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:02 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:02 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:02 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:02 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:02 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:02 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:02 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:02 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:02 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:02 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1]

Mar 29 21:26:02 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1] IS ALREADY RUNNING

Mar 29 21:26:02 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:02 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:02 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:02 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:02 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:02 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:02 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:02 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:02 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:02 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:02 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:02 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1]

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1] IS ALREADY RUNNING

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1]

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1] IS ALREADY RUNNING

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1]

Mar 29 21:26:03 MACPortable kernel[0]: AppleAC97AudioATIIXP::startDMAEngine[1] IS ALREADY RUNNING

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

Mar 29 21:26:03 MACPortable kernel[0]: HW Position = 0x102d50b4 engine ID = 0x1,REG=0xc

Mar 29 21:26:03 MACPortable kernel[0]: LINKPTR = 0x106a1001

Mar 29 21:26:03 MACPortable kernel[0]: START = 0x102d5000

Mar 29 21:26:03 MACPortable kernel[0]: NEXT = 0x21b6800c

Mar 29 21:26:03 MACPortable kernel[0]: CUR = 0x102d50b4

Mar 29 21:26:03 MACPortable kernel[0]: SZ = 0x8000400

ati_snd.tar.gz

that engine running problem is the one i've run into, once I get back on my laptop tomorrow, I'll upload the .cpp file that's relevent. Yeah, We need to figure out how to have the dma shutdown properly after the codecs are initialized, so that when the OS calls it, it isn't already running, because it shuoldn't. Hopefully we can get this solved. Too bad the other driver projects aren't getting this amount of collaboration.

 

that's all for now

-ed

Guest
This topic is now closed to further replies.
×
×
  • Create New...