From owner-freebsd-hardware Tue Jun 18 16:13:01 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA07790 for hardware-outgoing; Tue, 18 Jun 1996 16:13:01 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA07776; Tue, 18 Jun 1996 16:12:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA11403; Tue, 18 Jun 1996 16:10:19 -0700 From: Terry Lambert Message-Id: <199606182310.QAA11403@phaeton.artisoft.com> Subject: Re: FreeBSD works with Cy486DLC processors? To: michaelv@HeadCandy.com (Michael L. VanLoon -- HeadCandy.com) Date: Tue, 18 Jun 1996 16:10:19 -0700 (MST) Cc: sos@FreeBSD.ORG, alex@fa.tdktca.com, bmk@fta.com, Eloy.Paris@ven.ra.rockwell.com, questions@FreeBSD.ORG, hardware@FreeBSD.ORG, hal@wwa.com In-Reply-To: <199606181541.IAA16069@MindBender.HeadCandy.com> from "Michael L. VanLoon -- HeadCandy.com" at Jun 18, 96 08:41:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Basically the root problem is twofold: 1) the kernel has _no_ way to > know what the right thing to do is, because it can't know how your > motherboard is designed, so it needs help by you setting the right > option, and 2) the 486DLC is sometimes expected to do an impossible > task: running in a 386 motherboard that has absolutely no support for > cache coherency. Actually, #1 is possible. 1) You know you have a DMA device 2) You have enough memory to read to cause the cache to flush (or if the processor supports BINVD, use that, or you can two stage it, by turning the caching off on some chips) 3) You DMA from two areas on the disk, verifying that the areas differ by flushing the target memory from the cache, with a memory roll-through or BINVD 4) You two's complement the data after setting up duplicate transactions but not initiating them (to avoid accidently flushing the target memory after the two's complement by way of executing too much driver code) 5) You trigger the test DMA's 6) You see if the memory are contains the complemented or the actual data This can be a pain, since minimizing the code path for trigger after setup can require significant driver changes. Alternately, you could build a DMA test card that wrote data to real memory locations which you can preset via outb. This would be good, but it not a general soloution. Rod could use a card like this, or he chould write code to make an Adaptec controller and a small pattern-containing SCSI disk act the same way -- but he's an OEM, and can afford the overhead for the benefit. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.