rj0q@eleazar.dartmouth.edu (Rodney D. Jacobson) (04/09/91)
We at Aesculys Research Corp are trying to install a TrueVision Targa+ card in
a rs/6000 model 320. Actually, the install is simple once you figure out that
the key needs to be in the service position to open the case. What we are
having trouble with is using the card without writing an official device
driver.
What we want to do for now is port a task we have running on a MIPS 3000 with
an ISA bus targa card. On the MIPS, we open /dev/mem, allocate some memory
and use mmap() to map card registers and memory into an address in
(privileged) user space.
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.
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.
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.
The track that Satya has sent us along is to use /dev/bus0 and ioctl()
calls. We have verified that the following ioctl() functions are useful:
1. IOCINFO - get device info
2. MIOCCGET - get/read pos register contents
3. MIOCCPUT - set pos register contents
4. MIOBUSGET - read from a register
5. MIOBUSPUT - write to a mca register
so for example to write a byte stored in uchar newVal into the register 0x200
we do the following:
int fd = open("/dev/bus0",O_RDWR);
static MACH_DD_IO mdd = {0, sizeof(newVal), MV_BYTE, &newVal};
mdd.md_addr = addr; // ie 0x200
ioctl(fd, MIOBUSPUT, &mdd);
Satya's notes did not show how to access board memory and we are at a loss on
how to proceed. It is not clear that /dev/bus0 will help us on this one.
The big question is can we access memory on an mca card from a user - vs
device driver - process and how do we do it?
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. On a
ps/2, there is apparently a configuration program which reads a @*.adf file.
Is there any equivalent way to do that on the rs/6000? The stuff in
/usr/lpp/bos/samples apparently shows how one might do this in a device
driver, but it is not clear if it helps me in this case.
Sincerely,
David L. Hawley
Aesculys Research Corp
(603)488-4900
(603)488-0104 (fax)
dartvax!axsys!dave (e-mail)lso@softpro.stgt.sub.org (Lars Soltau) (04/12/91)
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=<name of card>. 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 <stddiscl.h>
larry@morpho.UUCP (Larry Morris) (04/18/91)
lso@softpro.stgt.sub.org (Lars Soltau) writes: >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)". Well, I can't say why its not in the manuals, but it is in the course notes for IBM's "Writing AIX Device Drivers" class. The description follows. busresolve( logic_name, flags, conflict_list, not_resolved, bus_name ) - Assigns bus resources to the adapter and ensures that bus - resources for the adapter do not conflict with other - adapters in the system. -EXAMPLE char * logic_name; char conflist[1024]; char not_resolved[1024]; struct CuDv CuDv; ....... busresolve(logic_name, (int)0, conflist, not_resolved, CuDv.parent); setleds( led_val ) - Sets the LEDs at boot time - EXAMPLE if( ipl_phase != RUNTIME_CFG ) setleds( preobj.led ); As far as I know, this is the best (only?) place to find a lot of this information. For example, I still can't find a description of the kernel printf routine used for debugging. It does differ from the regular printf. And the list of kernel subroutines under info seems incomplete. The class was very worthwhile, and you get a lot of documentation and sample code. Talk to your SE. I think they are offering the class. The session I attended was just to test out the course outline and get some feedback before they started offering it on a regular basis. Disclaimer: I write device drivers, not company policy. The above opinions are mine, all mine. ____________________________________________________________________________ amc-gw!morpho!larry -- Disclaimer: I write device drivers, not company policy. The above opinions are mine, all mine. ____________________________________________________________________________ amc-gw!morpho!larry