Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1686 comp.os.linux.development:4589
Newsgroups: comp.os.386bsd.development,comp.os.linux.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!sgiblab!sgigate.sgi.com!olivea!hal.com!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: The ###^%$ DMA problem from the EISA side.
Message-ID: <jmonroyCJo4rD.Gs1@netcom.com>
Followup-To: comp.os.386bsd.development
Keywords: DMA EISA ISA overrun FDC QIC-40/80
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Sat, 15 Jan 1994 11:18:48 GMT
Lines: 61
PLEASE NOTE the followup line before you fire off
another... you moron message.
===================================================================
DRAM Refresh from the EISA side.
This message was sent to me on the current DMA discussion.
Your input is most welcome.
======================================================================
Newsgroups: comp.os.386bsd.development
Date: Wed, 12 Jan 94 18:34:33 -0800
I've completely lost the point of what this thread is about. What is the
real problem that needs to be solved that is causing the debate about how
DRAM refresh is handled on an ISA PC and DMA channel 0?
There is a set of "problems" having to do with ISA bus masters and ISA
compatible DMA devices that can cause problems with DRAM refresh. Is that
the orriginal point of this thread? EISA systems (at least those using the
TI TACT 84544 EISA Peripheral Control Unit) have "solved" a set of problems
in this area.
In ISA systems, the system needs to have refresh cycles generated about every
15 microseconds. This is a shared responcibility between the system's
Interval Timer 1, Counter 1 and and 16 bit ISA bus mastering devices.
Any 16 bit bus mastering device is responcible for generating the REFRESH*
signal every 15 microseconds if they are in control of the bus for longer
than 15 usec. Sadly, not all such devices followed the ISA spec. in this
regards.
EISA improves upon this in a couple of manners:
1) The maximum refresh cycle hold off interval is now 75 usec. maximum.
2) EISA bus master (not to be confused with EISA's support of a compatibility
mode ISA bus master & DMA modes) devices can be pre-empted by the DRAM
refresh cycles, no matter how long they hold the bus.
3) If an ISA compatibility bus mastering device doesn't allow a refresh
every 15 usec.,
upto four occurances are "remembered" by the EPCU. When the bus is finally
released, it will "burst" a series of DRAM refresh cycles equal to the
number missed (upto 4) while the ISA bus master failed to generate them.
Again, speculating on what the root cause of these thread's debate is, it
sounds as if a data corruption problem caused by DRAM refresh failure may
be occuring due to an improperly implemented ISA board not generating the
REFRESH* signal. I would speculate that perhaps this wasn't noticed on DOS
because DMA was not used to communicate with the board, programmed I/O was.
So many of these improperly implemented ISA boards exist that the authors of
the EISA specifications worked hard to "work around" this problem so that such
boards would be more likely to work in an EISA system they they did in an ISA
system.
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________