Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!unidui!unido!ira.uka.de!smurf!nadia!softpro!lso From: lso@softpro.stgt.sub.org (Lars Soltau) Newsgroups: comp.unix.aix Subject: Re: RS/6000 device driver Message-ID: <104@linus.stgt.sub.org> Date: 11 Apr 91 17:44:46 GMT References: <1991Apr9.131843.4409@dartvax.dartmouth.edu> Reply-To: lso@linus.stgt.sub.org (Lars Soltau) Organization: SOFTPRO, Software Professional GmbH, Boeblingen, Germany Lines: 72 In article <1991Apr9.131843.4409@dartvax.dartmouth.edu> rj0q@eleazar.dartmouth.edu (Rodney D. Jacobson) writes: [...] >We have made a little progress on getting the Targa+ card to work in the >rs/6000, but some issues remain. Satya Rao of IBM Austin sent us some code >which shows how a user process can read and write to the mca POS registers and >to registers on the board. This works and we can verify that the Targa board >has the id it's supposed to and that we can read and write i/o registers on >the board. > > >The remaining problems are: > >1. how to read and write to Targa memory. > I can't help you there. I suppose this is only possible in the kernel environment. >2. how to insure that we do not set Targa i/o and memory locations on >top of those used by other boards on the system. Look up "Writing a [Define|Configuration] Method" in the Kernel Extensions Programming Concepts. It made things a lot clearer for me. As far as I have been able to deduce from the manual, for each possible MCA card there exists an object in the PdDv class, with class="adapter", subclass="mca" and type=. So first you have to create this entry in the PdDv class for your card. The define method, /etc/methods/define, is able to handle every mca card, so you only have to enter this method into the object as define method. At boot time, the system checks all mca slots and reads the POS id. Then it searches for an entry in PdDv with this device ID and calls the define method of that object, if one is found. This method creates an object in CuDv with the actual location of the card (the slot number). >Issue 1 is the biggest mystery to us at this point. We can probably solve >issues 2 by playing dungeons and dragons with info and odme, but some >outside help would make things much easier. You can leave the "dungeons and dragons" to the system. Another odm class, PdAt, contains all possible attributes for all devices, among which are the i/o address and interrupt level for the mca boards. In the manual it says that you are to call a routine named "busresolve()", but no further documentation about this routine is given. I assume that it checks all devices and then chooses the right parameters. I don't know who actually sets these parameters and who is supposed to enter them into the CuAt class. If anyone has found further documentation about "busresolve()", please tell me about it. By the way, the manual says that the configure method is supposed to call "setleds()", but this routine is also not documented anywhere. I found out by trial and error that it's "void setleds(int)". >The track that Satya has sent us along is to use /dev/bus0 and ioctl() >calls. I am very much interested in all information you have got. Please mail me the code fragment. >As far as avoiding conflicts with other mca boards goes, it looks like we need >to search through odme and figure out what devices use what addresses. > However I have not figured out an efficient way of telling what addresses are >currently used. I also have not figured out how to tell the system what >addresses the Targa board will use with a given pos register setting. You have to create one object in the PdAt class for each attribute of your card, like i/o address or int level. Look at the entries for the hscsi or the ethernet adapter, then it will become clear. As I said above, avoiding conflicts is done by "busresolve()", but don't ask me how exactly this thing works. Is it a bug that it's not in the manuals? -- Lars Soltau lso@softpro.stgt.sub.org #include