Subject: Re: Adaptec 1742
To: None <"Michael L. VanLoon -- Iowa State University">
From: Michael L. VanLoon -- Iowa State University <>
List: current-users
Date: 08/03/1994 20:59:55
Incidentally, I contributed most of the Cyrix-specific logic in
locore.s and machdep.c, that Theo retuned and put into the tree.  So,
I'll comment on my viewpoint.

>So, I've implemented the following compromise:
>1) The bit which disables caching of the ISA `hole' area is always

This is probably good for all machines.  However, for non DLC-specific
motherboards, we should probably be using the mode where it flushes
the cache on each bus hold.  We should be moving #0x22 into CCR0
instead of the #0x02 that is default.  (Look where it's commented out
in locore.s).

For people who have DLC-specific motherboards that actually have
hardware cache support, it would be nice if there were a kernel option
that would simply tell the Cyrix setup code to not touch the caching
stuff (just DLC detection), so what they do in their BIOS will stick
as NetBSD boots.

I don't see why nobody wants to make this a config-time option.  There
is absolutely no way to detect whether a motherboard is DLC hardware
specific -- it must be supplied by the user.  I envision something
like #DLC_BIOS or #DLC_PARANOID to enable either a) don't touch the
cache settings, or b) enable the cache in paranoid mode where it
flushes on every bus hold and locks out the 640K-1M region (for use on
386 motherboards without DLC hardware caching support).

>2) If caching doesn't work correctly on your machine, you can turn it
>off using the BIOS setup utility that came with your machine.  I'm not
>going to try to intuit what the right thing is from the limited view I
>have from the inside of your CPU.

You can't if we set it a certain way inside locore.s on every boot.
That's why I'm in favor of a config option.  (Although, at present, if
you don't #define notyet_cyrix, you don't get any DLC caching at all.)

>3) Eventually the explicit cache invalidations should be added anyway,
>but I'm not going to do it today.  (Feel free to volunteer!)

I started to do it, and had dma.c and bt742a.c cache-safe (since
that's the only DMA hardware I have).  I'm not so sure it's such a
good idea, unless you can be sure *everyone* who writes a DMA driver
knows to put cache invalidations in the right places.

I'd volunteer to finish the work if I wasn't working 60 hours a week.


 Michael L. VanLoon                 Iowa State University Computation Center                    Project Vincent Systems Staff
  Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc.