garyj@sucker.pcs.com (Gary Jennejohn) (05/24/91)
This is actually intended for Des Young, but the mailer at NSC keeps bouncing it back to me. I'm sorta forced to send it to the group. Hi Des; I'm currently working on a driver for the AIC6250 chip and have run into problems with pseudo-DMA. I sent George the message below and he thought that you might be working on a driver too and recommended that I contact you. >> I'm trying to write a driver for the 6250 SCSI chip (as you've probably >> noticed from other mail). Everything works fine (read/write) when I use >> polled mode. However, when I try to use the pseudo-DMA the chip thinks that >> fewer bytes have been transferred than my software does, i.e., there's usually >> a residue in the DMA count registers after I come out of the transfer loop. >> Note that this loop uses byte accesses rather than movsd. >> >> I'm pretty sure that I'm programming the chip correctly because, if I loop >> until the chip thinks there are no more bytes, the disk is happy and the >> chip is happy. Unfortunately, the data actually transferred to/from the >> disk is wrong. >> >> I'm just a poor software guy but one of the hardware people here looked at >> various signals with a logic analyzer. We examined the behavior with both the >> 8490 and the 6250 for comparison. >> >> We looked at the following signals: >> drqs0/1 into the scsi pal >> /rd from the wait pal >> A27 from the decoder pal\__ we triggered on these two >> /scsi into the scsi pal / >> /dack from the wait pal >> /nrdy from the wait pal >> /dack0/1 from the scsi pal >> >> For the 8490 (which works) we noticed that drqs1 was asserted about every >> 800ns with /dack1 coming shortly after. For the 6250 we noticed that drqs0 >> was asserted 4 times in a row (about 760ns all told for 4 drqs0's). /dack0 >> appeared on the heels of drqs0. /scsi remained asserted the whole time. After >> this "burst" there was a delay of about 2600ns until the next "burst". >> I assume that drqs0 comes so quickly in bursts because of the on-chip FIFO >> and that the 2600ns delay corresponds to the time needed to read 4 more >> bytes into the FIFO. >> >> It looked sort of like this for the 6250: (for a read) >> >> __________________________ __ __ __ >> A27: ___| |_| |_| |_| |________ >> >> ___ _ _ _ ________ >> /scsi: |_________________________| |_| |_| |_| >> >> ________ ___ ___ ___ __________________________ >> drqs0: |__| |__| |__| |___| >> >> ______ ___ __ __ __________________________ >> /dack0: |__| |__| |__| |___| >> >> I don't think that the CPU transferred a byte each time drqs0 was asserted. >> I suspect that the cycle was extended by the logic in the pals and that only >> one byte was really transferred. However, I don't know which signals to look >> at to verify this. > >No, the /dack0 signal is asserted by the wait/scsi pal combination. The /dack >signal from the wait pal is generated only for a iord or iowr to/from the >scsi pseudo dma address. Therefore, since you show a /dack for each drqs this >can only occur if the cpu performs a read or write. So, I don't know why >you appear to be losing data - but the waveforms that you show are correct. > >> I'm wondering if the bursty way that drqs0 comes isn't leading to a problem. >> Did you and Dave ever test out the 6250 with pseudo-DMA? Do you think that >> there could be a problem with the scsi and/or wait pals? > >It shouldn't be a problem, since the aic6250 can only de-assert drq when it >receives a /dack and that can only happen when the cpu does a read or write >as explained above. > >We haven't really looked at the aci6250 since we only had the old DL rev >which was very broken (which rev do you have - we shipped EL's to everyone >but I think that some of the kits from Steve Ligget had some DL's). When we >got the EL rev we checked transfers very quickly and then went on with the >8490 which we had drivers for and which Bruce supported in Minix. I think >that Des Young has been working with the aic6250, maybe you should check >with him and see if he has had problems. > >> Can you suggest any other signals to look at to confirm whether the CPU is >> transferring a byte every time drqs0 is asserted? > >As I've said - the cpu must be transferring data - else /dack wouldn't >transition. > >> Any leads you can give me will be greatly appreciated. > >Good luck, keep me posted, > >best regards, > >-- >George Scolaro >george@wombat.bungi.com [37 20 51 N / 122 03 07 W] > ARE you working on a driver and, if so, have you seen anything like this? Am I doing something wrong/stupid here? As I wrote to George, any leads you can give me will be greatly appreciated. Gary
des@musashi.wpd.sgi.COM (Des Young) (06/04/91)
Hi, at last a repost/followup/alternative. The O/S on my machine was upgraded last week, simultaneously with the main file server's O/S. The combination rendered me inactive for longer than could be believed (the two machines are also from different vendors, different X implementations etc.). Anyway, I lost the mail with the timing diagrams about the 6250 problems. Could the author resend them please? I am not an NS, my email address is des@pei.com I have been working on a 6250 driver, but I do not have it going yet. What I did not understand from what I remember about the timing diagrams is how come the transfers are in bursts of 4 ? If you are programming the FIFO offset to be zero (required for async SCSI transfers), they should be one at a time, unless the code fetch/execute time is longer than the SCSI transfer time (surely not ?). I will look over the code Jordan posted on your behalf. What is your email address ? Cheers, Des.