|
September 11, 2003
|
The driver has now moved pretty close to actually just lack the card-specific parts:
- It registers itself to handle a char-device (60, 0)
- It registers an entry in /proc/driver to present device information and, in the future, information about the work it's doing
- It registers an interrupt handler with a tophalf and accompanying wait queues for the tasklets to be
- It handles ioctl calls
- Some of the abstraction to handle the communication with user space has been defined
- The file operations are in place just waiting to be modified to reflect the way the hardware wants to be fed data
I've also returned to IDAPro (with a newly compiled wine) to try to understand what structures are involved, how the (Win98/WinNT as it turns out) driver communicates with the card and in what shape it returns the unpacked data. This is tedious work but I get to know quite a few things about the inside of the Win98/WinNT environment and I hope it won't harm me too much. ;P
It's worth noting that several parts look pretty much the same as in Linux with tables of function pointers, spin locks and operations waiting in queues to be handled.
Right now I'd give pretty much to get IDAPro's anonymous markers, like "sub_xxxxx", translated into things like "initCard" and the such but I guess things will get clearer as I spend more time with this precompiled beast.
|
|
September 6, 2003
|
I've actually gotten an e-mail from someone that would like to see the driver come into existence. All hail Google! ;P~
Suddenly I feel the urge to dig into things even more.
|
|
March 12, 2003
|
After almost a year I have picked up the scent of something interesting again. I got word of an implementation of a Linux device driver for the Creative DXR2 card that (hopefully) uses the same ZiVA decoding chip as the card in my laptop.
The device driver is written for the 2.2.x kernel and it's littered with question marks which leaves me with some problems:
- Will I be able to use the code "as is" or has anything major happened in the kernel?
- Will I be able to even detect the ZiVA chip on my card?
- When, and I do say "when", something doesn't work, will I be able to decode the "documentation" in the code?
- Will code for the ZiVA on a DXR2 work with the ZiVA on my card?
At the moment I'm investigating the code and making plans to hook it into the existing detection of the PCI card that is compliant with version 2.4.x of the Linux kernel. Trouble along the way include bus mastering, DMA and interrupt handling but as the lunatic that I am, I try to view it as a chance to learn something useful. I will probably spend a few days giggling at "jiffies"...
I have also learnt that the CineMaster card has a new name and that another company, CIFELLI Corporation, sells the card. The card is now known as cifePEG C3.0. I sent a request to their support and I'm waiting for a reply.
|
|
April 10, 2002
|
Now the module loads and unloads:
Apr 10 21:13:00 h231 kernel: cin_dvd_dec: driver version 0.0.1 loaded
Apr 10 21:13:00 h231 kernel: cin_dvd_dec: Cinemaster DVD Decoder Card found
Apr 10 21:13:00 h231 kernel: cin_dvd_dec: Enabling device
Apr 10 21:13:00 h231 kernel: PCI: Found IRQ 11 for device 00:0d.0
Apr 10 21:13:00 h231 kernel: PCI: Sharing IRQ 11 with 00:05.2
Apr 10 21:13:00 h231 kernel: PCI: Sharing IRQ 11 with 00:0c.0
Apr 10 21:13:00 h231 kernel: cin_dvd_dec: Requesting memory region
Apr 10 21:13:00 h231 kernel: cin_dvd_dec: Cinemaster DVD Decoder Card (rev 2) at 00:0d.0, irq: 11, latency: 64, memory: 0xed00
Apr 10 21:13:21 h231 kernel: cin_dvd_dec: driver unloaded
Also, the module can probe for some basic information. As far as I can see this is all that can be done without stumbling into card specific features. The next step is to figure out how IRQ is enabled in the Win32 driver and what initial setup is done when the Win32 driver is loaded.
|
|
April 9, 2002
|
The amount of information is getting somewhat more dense. A friend of mine has supplied me with an extracted version of the Win98 DDK in handy HTML format. He has also been kind enough to let me warp my already twisted mind oogling "WINDOWS NT, Device Driver Development" and "Writing Windows VxDs and Device Drivers".
The amount of information pertaining Win32 that I might have to digest is a bit overwhelming.
|
|
April 7, 2002
|
Things have happened. There's been something called Easter which in turn resulted in me having that cavity behind the nose, whatever it's called in English, filled with that slimy thing commoners refer to as snot.
On a brighter note I've been supplied with a copy of IDA Pro 4.15 and I've begun inspecting the Win32 code using this really neat tool. I've also written some code using the PCI support in the Linux kernel and at the moment the module can be loaded, unloaded and detect the correct card.
|
|
March 29, 2002
|
|
The source for the bttv-driver has been inspected and as far as I could see everything I need up to actually sending card specific data is in there. The mighty cut'n'paste operation is on it's way tightly followed by more inspection of the Win32 driver.
|
|
March 28, 2002
|
|
The laptop has been uppgraded to a 2.4.18 kernel and everything seems to work fine. I'll probably have to poke at the soundcard and the correct module to get sound out of it again but that's only to expect when you compile the wrong module and won't take the time to fix it at once.
|
|
March 27, 2002
|
|
After a few lazy days with minimal exposure to the problem to let my subconsious do it's thing I was back in the saddle. Linux for Toshiba PCs had sent me an email requesting some extra information that I sent, including a link to this page.
|
|
March 23, 2002
|
Reading about the inner workings of the PentiumIII processor turned out to be more than just somewhat interesting. Protected mode memory handling and protection have been assimilated and interrupts is on the menu for dessert.
To add to the experience I glanced at the PCI documentation for the Linux kernel and it turned out to be easily digested. Soon I will write the part of the module that identifies the card, sucks out the I/O-information and allocates the necessary resources.
At the time of writing real hunger tormented my innards making way for a pleasent dinner and lots of alcoholic beverages. ;P~
|
|
March 22, 2002
|
What joy, what happiness! The fact that I installed wine earlier made way for something like a cheerful moment around noon. I installed the demo version of w32dasm 8.7 and it worked almost like in a native win32-environment. After some time searching the net, I (just to try it out) installed a patch and all of a sudden my w32dasm 8.7 was a w32dasm 8.9 without limitations. ;P~
It would be really good to have something like IDA Pro 4.20 but as long as I can inspect the code I'm almost satisfied. This called for a celebratory cigarette and some hacker wasser (BATTERY). The tedious task of identifying how, when and where the driver interacts with the card could commence.
The evening was spent inspecting Win32-assembler, writing stubs and reading Intel's PentiumIII manual to understand how segmented memory handling works.
|
|
March 21, 2002
|
|
The day started early and I compiled an objdump that understands pei-i386 which enabled me to inspect the DLLs with all the OP-codes transformed into neat x86 assembler. This gave me the possibility to actually see some of the inner workings and together with the information about the symbols that the DLL exports I'll be able to connect the two. This will be done with a perl hack that I started on.
|
|
March 20, 2002
|
The support at Ravisent responded, once again, and this time the rules were clear: "... the information that you are requesting is company proprietary. It is company policy to not distribute this information.". This left only Toshiba as a possible source of information and judging by the dates of the requests on their site, that could take a while.
The harassment had payed off. I was directed to a small hack that could parse the information in a Win32-DLL and display it. I played around with it for a while only to discover that it didn't know all the OP-codes for a Pentium processor.
|
|
March 19, 2002
|
|
The support at LSILogic responded to my request with "We support 'pci scsi host adapters'. Please contact your nearest field sales office.". Is this a dead end? Time will tell.
|
|
March 18, 2002
|
|
I got some sort of response from Ravisent's support where I was let in on the secret that they use DirectShowAPIs and that would be all that I would need to develop my own application. I answered with a schema that roughly described the structure in a Win32 environment and in a Linux environment and pointed out that this is done for and with Linux. I also made perfectly clear which part I was interested in.
|
|
Middle of March, 2002
|
I had now sent requests to LSILogic, former C-Cube and manufacturer of the chip, and to Ravisent, the former manufacturer of the card. I had also downloaded a Win98 driver to dissect and started to look for tools that could help me with that. In this quest for the Mighty Tool I harassed almost everyone in sight as to if they knew something toolish.
I spent some time reading at MSDN about DLLs, their structure and how they function. I also installed wine (WineHQ) to be able to poke at the DLLs in an environment that in some way resembled their normal habitat. The wine-experience was somewhat rewarding as soon as I figured out how to control the debug messages and parse these messages but it didn't result in any Herueka-like moment.
|
|
Early March, 2002
|
|
The idea was spawned. The gnomes in my head told me that I could, and should, do this. I started to search the Mighty Net for information. This resulted in some of the links below and a request for the specifications for the card at Linux for Toshiba PCs.
|
|