C4's Cyrix 486 patches for Linux-  Version 0.30
-----------------------------------------------

DISCLAIMER
----------
First, the legal stuff..  I don't want Joe User slapping me with a suit
because he thinks I destroyed his machine or his data or whatever.

I take no responsibility whatsoever for any damages caused directly or as
consequence of the use or non-use of the following instructions and patches.
They have worked for me but they may or may not work for you.  These
instructions and patches are provided for purely informational purposes.
Although I have checked it over, I am also not responsible for any mistakes
in this text nor any direct or consequential damage caused because of them.
There is no guarantee stated or implied.  USE AT YOUR OWN RISK.

IMPORTANT NOTE
--------------
These patches are for the *Cyrix* line of 486 processors *ONLY*.  They
have not been tested on such chips as the IBM 486SLC or IBM 486DLC, and
when used on non-Cyrix parts may have no effect or may cause untold havoc.
As stated above, use at your own risk.  I can offer no help at all on the
subject of non-Cyrix chips, so please don't email asking for help unless
you have a genuine Cyrix part.

*VERY IMPORTANT NOTE*
---------------------
While I'm glad to answer questions and attempt to help you solve any
problems you have with this patch over email, it is *very* important
that you email to the correct address.  I have several email addresses,
and at least one of them is reserved for research-related mail ONLY.
This link is paid for, and I don't appreciate getting people's problem
reports at that address.  The correct address to send problem reports
and other queries to is: clau@acs.ucalgary.ca.  I may post articles from
a variety of machines, but the above address is the *ONLY* address at
which I will reply to questions about this and other packages.  Mail to
any other address MAY get a reply if I'm feeling good, otherwise it will
be ignored.  Repeated messages to the wrong address will result in a note
to your system admin.

Also, I've taken the time to write the README files in this package, and
they answer a variety of questions that you might have, so please take
the time to read them CAREFULLY before you email. 


Part A- Frequently Asked Questions
----------------------------------

1- What's a Cyrix 486?

A Cyrix 486 is one of several clones of the Intel 80486 CPU.  The Cyrix
486 is made by Cyrix Corporation and comes in the following varieties:

   Part No.     Description
   ---------    -------------------------------------------------------
   Cx486DLC     An i486 with 1K cache in an i386 pin-compatible package.
                Uses standard 387 part for math coprocessor.
                Designed for DLC-capable motherboards, no cache coherency
                logic.
   Cx486SLC     As above, but 16 bit external bus (a la i386SX)
   Cx486DRu2    A daughterboard with a clock doubler, cache coherency logic
                and a 486DLC processor.  Plugs in place of i386 processor.
                Uses standard 387 part for math coprocessor.
   Cx486DRx2    The single-chip integrated version of the DRu2.
   Cx486SRx2    As above but for i386SX.
  *Cx486D	i486DX pin-compatible part with 2K cache.
  *Cx486S	i486SX pin-compatible part with 2K cache.
  *Cx486DX	i486DX pin-compatible part with 8K cache.
  *Cx486SX	i486SX pin-compatible part with 8K cache.

* These are "real" 486 parts and don't require this patch.

2- How do the Cyrix processors compare to their Intel counterparts

Assuming both systems have no external cache, a 40 MHz DLC part gets about
the same performance as a 33 MHz Intel part.  (At 40 MHz the DLC benchmarks
faster, but for real work, the bigger cache on the Intel part plays an
important role).  If both machines have an external cache, the 40 MHz DLC
part will get better performance.

Floating point performance with an Intel 387 coprocessor is slightly better
than with the 386, but still significantly below that of the built-in 487
FPU.  Performance with the recommended Cyrix 83D87 coprocessor is reported
to be *better* than that of the 487, but I can't confirm this.  There
have also been reports of incompatibilities with early revisions of both
the original pre-mask change Intel and IIT 387 coprocessors.  If you have
one of these coprocessors and are having problems, try pulling the
coprocessor before emailing for help.

3- I'd like a Cyrix processor.  Which one should I get?

Because of the problems with cache-coherency, unless you have a motherboard
that is DLC-capable (cache coherency logic on motherboard and cache enable
in BIOS) the obvious choices would be the DRu2, DRx2 and the SRx2.  However
the DLC and SLC parts can be found for as little as $80, whereas the DRx2
part sells for $349 (if you buy from Cyrix, possibly much less elsewhere).
The cache coherency problem on the DLC and SLC parts can be worked around,
but your speed will suffer badly.  Depending on your application, the savings
from getting the DLC part instead of the DRx2 part may be worth the performance
loss.

4- What do these patches do?

The Cyrix 486 chips have an interesting design "feature"- upon power-up or
reset, their chip caches are enabled, but they are set up such that the
none of your memory is marked as cacheable.  This is equivalent to disabling
the cache outright.  Without the cache, performance gain of the system vs.
the original 386 processor is minimal.  Enabling the cache improves system
performance by 100% or more!  These patches simply enable the cache on the
chip so you get the best performance possible.  The patches also allow the
use of a DLC part on motherboards that do not directly support this chip. 

5- I've got a 486DLC-capable motherboard, do I need the patch?

As expressed above, a good DLC-capable motherboard's BIOS will automatically
enable the chip cache, so no, you don't need this patch. 

How do you tell if you've got a DLC-capable motherboard?  Well, the first clue
is if you bought the system with a DLC chip on the board.  Other clues include
the presence of BIOS setup options for the DLC, the fact that you don't need
any software drivers, etc to enable the cache when you boot DOS.  An already
high BogoMips (tm) (13 or better for a 40 MHz part) value when you boot Linux
also indicates that you have a DLC-capable motherboard.

Some motherboards and BIOSes claiming to be DLC aware only do their job
if running an OS which uses BIOS (OS/2, DOS).  These BIOSes don't enable
the cache when an OS doesn't require BIOS services (like Linux or any Unix).
If you have a motherboard which does this, then yes, you should install the
patch.

One particular motherboard which claims to be DLC aware, but isn't for
Unix is the OPTi495SLC+AMI BIOS.  I'd appreciate reports of any other
motherboard and BIOS configurations which claim DLC awareness, but
really aren't.


6- How do I install the patch?

The patch comes in two parts, the first to add the Cyrix options to the kernel
configuration script, and the second to add the cache-enable code to the
bootstrap routine.  To install, copy the patch file to your linux source
directory (/usr/src/linux on most machines), and type 'dopatch'.  If
everything works, type 'make config' and answer the questions, then type
'make' once more to recompile the kernel.


Part B- The Technical Stuff
---------------------------

The some of the following information is from Derek Fawcus (G7FVS)
(df@eyrie.demon.co.uk), the remaining information is from the Cyrix
documentation:

The on-chip cache of the Cyrix 486 is controlled by a set of configuration
registers referred to as: CCR0, CCR1, NCR1, NCR2, NCR3 and NCR4.  These
registers are accessed through two I/O ports (0x22 and 0x23).  The first
port, 0x22 is the address index register and the second port, 0x23 is the
data register.

The cache control registers are at address indices in the range 0xc0 to 0xcf,
to use them write the index into 0x22 and read/write the value from/to
0x23.

Register Name			Index			Size (bytes)
-------------			-----			------------

CCR0				0xc0			1
Configuration Control 0

CCR1				0xc1			1
Configuration Control 1

NCR1				0xc4 - 0xc6		3
Non-Cachable Region 1

NCR2				0xc7 - 0xc9		3
Non-Cachable Region 2

NCR3				0xca - 0xcc		3
Non-Cachable Region 3

NCR4				0xcd - 0xcf		3
Non-Cachable Region 4

The non-cachable regions are specified by a block size and a starting
address.  The sizes range from 4kbytes to 4Gbytes, the starting address
must be on a multiple of the the block size.  A size of 0 disables that
non-cachable region, and a size of 4G marks all of memory as non-cachable.

Taking NCR1 as an example, the break down is as follows:

	ADDR	BITS
	0xc4	7 - 0		Address bits 31-24 of starting address
	0xc5	7 - 0			     23-16
	0xc6	7 - 4			     15-12
		3 - 0		Block size, call this value sz

Registers NCR2 - NCR4 are as above but with different starting regions.

Block sizes are given by size = 2048bytes * (2 ^ sz) except for values
of sz of 0 and 15 which are disable region and 4G non-cachable respectivly.

CCR0 is a set of bits as follows:

	BIT	Setting	NAME

	0	1	NC0	If 1 sets the first 64k of each 1M boundary as
				non-cachable.

	1	1	NC1	If 1 sets 640k to 1M as non-cachable

	2	0	A20M	If 1 enables A20M# input

	3	0	KEN	If 1 enables KEN# input 

	4	1	FLUSH	If 1 enables FLUSH# input

	5	0	BARB	If 1 enables flushing of the internal cache
				when hold state is entered (during DMA and
				DRAM refresh)

	6	0	CO	Selects cache organisation. 0 = 2 way set
								associative
						    	    1 = direct-mapped

	7	0	SUSPEND	If 1 enables SUSP# input and SUSPA# output


CCR1 is not really of interest as it controls the use of the RPLSET and
RPLVAL# output lines, these require extra hardware and on a board designed
for the Cyrix chip should probably not be touched.  If bit 0 is set then
these lines are enabled.

On power up all bits are 0 except 0xc6 which is set to 0x0f thereby
effectively disabling all caching.

The state of the cache (ON/OFF) is controlled by the CD (cache disable) bit
in the 386/486 CR0 register.  If this bit is enabled, the internal cache is
disabled, regardless of the settings of the CCR and NCR registers.  Most
BIOS' happen to disable this bit so that the cache is enabled.  In this case,
only the CCR and NCR registers need to be changed to gain full performance
from the chip.  If your BIOS does not enable the cache, then you'll need
an additional patch to fix this condition.

Now to the specifics:

To maintain cache-coherency, the FLUSH input should be enabled- on the
DRu2, DRx2 and SRx2 parts, the internal cache coherency logic toggle this
input during DMA.  However, on a DLC part on a non-DLC motherboard, this
pin is normally not connected, so how do we maintain cache coherency?

We can force cache flushing on DMA by enabling the BARB input since DMA
normally causes the CPU to enter the HOLD state.  Unfortunately, the BARB
input is also asserted at DRAM refreshes, which means that the cache is
flushed almost continuously, giving poor performance (about 8 BogoMips (tm)
for a non-DLC system vs. 13 for a DLC-supporting system with a 40 MHz part).
The bogoboost patch posted recently to c.o.l.d might be of some use in this
case.  I don't know about you, but I'd prefer to pay the extra $$ for the
DRu2 or DRx2 part and not have to worry about cache-coherency and also get
better performance.  On a machine with external cache, the continual cache
flushing problem isn't as serious and your performance doesn't suffer as much.
(11-12 BogoMips reported on a DLC 40 MHz part with 256k ext. cache)

The kernel patch sets CCR0 to 0x13 (NC0, NC1 and FLUSH) for DRx2 and DRu2
processors and to 0x23 (NC0, NC1 and BARB) for DLC processors.  CCR1 is 
set to zero (all low power mode features disabled), and the NCR registers
are set to zero (allow caching of entire PC memory..  If you have a ram
disk or some peripheral card that puts its memory somewhere other than
640k-1M, you can change these registers to disable caching in the desired
memory range)

Part C- Bugs ("Features") and Changes
-------------------------------------

Bugs?  What bugs?

Actually, the fact that no attempt to verify that a Cyrix processor is
actually installed before trying to enable the cache might be considered
a bug.  I don't believe that setting ports 0x22 and 0x23 on a non-Cyrix
processor has any effect, but you might not want to take that chance-
don't run a Cyrix enabled kernel on a non-Cyrix machine.

Also, no attempt to verify cache-coherency after DMA on a Cyrix processor
is made.  The BARB input should suffice for most machines, but if it doesn't
for yours, too bad, get a DRx2 instead.  (Actually, you *could* hack the
DMA parts of the kernel to send a cache-invalidate signal to the CPU when
DMA occurs- this is left as an exercise for the reader).

Changes between version 0.1 and 0.15:
a) Fixed 'dopatch' to reflect file locations in the .tar
b) Removed the duplicated patch code in setup.S.diff
c) Provided setup.S.diff.alt for cases where the compiled setup.o is too big
d) Provided README.ARGGH which attempts to provide solutions to some
   possible problems

Changes between version 0.15 and version 0.20:
a) Additional CD bit patch for motherboards whose BIOS do not disable this
   bit.
b) pl11+ format config.in patch is now provided.
   pl11 patch is courtesy of Henrique Martins (martins@hplhasm.hpl.hp.com)
c) Miscellaneous corrections and additions to the README files.

Changes between version 0.20 and version 0.25:
a) Modified Cyrix register settings for slight performance boost under Linux.
b) Fixed the CD bit patch.
c) Miscellaneous corrections and additions to the README files.

Changes between version 0.25 and version 0.25a:
a) The change for the boost above should not have been propagated to the
   DLC part.  

Changes between version 0.25a and version 0.30:
a) Now Linux 1.0 compatible
b) BogoBoost patch made an integral (but optional) part of CxPatch.
c) Several different alt patches added.  Choose the one that works for
   you.

Part D- TODO
------------

- Nothing.  Autodetecting a Cyrix part adds to much code to the bootup code,
  you'd have to strip a few more video detection routines to make it fit,
  but then people will just complain bitterly..

Please mail any corrections/comments/enhancments/money to clau@acs.ucalgary.ca
Direct all flames/threats/rotten veggies to /dev/null

