Date: Sat, 2 Aug 1997 00:06:35 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Dave Huang <khym@bga.com> Cc: freebsd-scsi@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: Disk activity light on Asus SC875 doesn't work Message-ID: <19970802000635.04080@mi.uni-koeln.de> In-Reply-To: <Pine.NEB.3.96.970731004239.240A-100000@dahan.metonymy.com>; from Dave Huang on Thu, Jul 31, 1997 at 12:47:39AM -0500 References: <19970721222749.48037@mi.uni-koeln.de> <Pine.NEB.3.96.970731004239.240A-100000@dahan.metonymy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 31, Dave Huang <khym@bga.com> wrote: > On Mon, 21 Jul 1997, Stefan Esser wrote: > > So, if you wait for a few more days, you may find that > > your status LED will suddenly start to blink :) > > Well, I ported the changes in version 1.100 of ncr.c into the NetBSD > driver, enabled SCSI_NCR_SYMBIOS_COMPAT, and my LED is working now! > Thanks! :) Now I guess I need to work on the patch from 100 to 101... wow, > that's a pretty big diff :) Well, it *looks* big, but I think it should apply with very little problems, since most lines that change are in the SCRIPTS code and the loader, which should not be any different in NetBSD. (BTW: I want to have the NCR driver found in the FreeBSD-current sources compatible to NetBSD as well, but don't have any NetBSD system to test it on. I'd really qppreciate, if you could send back the changes you had to apply. Else the code in NetBSD will diverge it will become ever harder to apply changes made to the FreeBSD code ...) > What's the benefit of loading the microcode into the on-chip RAM, anyways? The NCR chips traditionally fetched instructions from system DRAM. The 53c810 only supported single cycle accesses (which required two to three single DWORD PCI bus transfers per instruction), later chips offered burst op-code fetch and read-ahead for better PCI bus efficiency and higher execution rates. The 4KB SRAM found in 53c825A and 53c875 chips is big enough to hold most of the code required for normal SCSI command execution. Only the scatter/gather tables and some exception handling code doesn't fit in, but since this is only a small fraction of all accesses, the PCI bus load can be significantly reduced. Since the CPU in the NCR chip will stall if it can fetch instructions fast enough, use of the SRAM can reduce SCSI command overhead and the associated latencies, which will be most obvious in a system with many disk drives and possibly several NCR SCSI controllers. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970802000635.04080>