summaryrefslogtreecommitdiffstats
path: root/Documentation/cyrix.txt
blob: 203bc8b8f132603b1ed966c03221100dc3c8e7ce (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
                        Cyrix Processor Support
                        -----------------------

Processor Recognition
---------------------

Cyrix processors prior to the 6x86MX power up in a default mode
designed to avoid compatibility problems with software that
makes assumptions about processor capabilities based solely on
the apparent family of processor. Unless special handling is
provided Cyrix chips will be identified as some unknown model
of 486.

  The Cyrix processor recognition kernel build option compiles
in code that enables the CPUID instruction on Cyrix processors
and that uses the Cyrix specific DEVID feature to identify the
particular type of Cyrix chip present.

  The 6x86MX and later processors have CPUID enabled by default
however special handling is still required to read the specific
processor type using DEVID since the CPUID information gives
family 6, model 0 - i.e. an A step PPro.

  The combination of CPUID and DEVID allows all current Cyrix
processors to be recognised and listed correctly in /proc/cpuinfo.
This includes Cx486, 5x86, 6x86, Gx86 (aka MediaGx) and 6x86MX.

  Processor recognition is required for all other Cyrix specific
options.


Suspend on Halt Power Saving
----------------------------

The suspend on halt power saving feature allows the processor to
enter a low power mode when the "hlt" instruction is executed. This
results in dramatically reduced operating temperatures if you do
not spend long periods of time running processor intensive tasks.
Cyrix processors allow this feature to be enabled an disabled
through their configuration registers. The default state on reset
is disabled and many (most?) BIOSs leave it disabled hence a
kernel configuration option is provided that adds code to explicitly
enabled suspend on halt when Linux boots.

  However there appear to be a few rare cases in which the
combination of suspend on halt and some bus master DMA cards can
cause the system to lock up. If this appears to happen you may
need to leave suspend on halt in its default state. (Note that
an option to _disable_ suspend on halt is not provided. If your
BIOS enables it you have to live with it)


5x86 Performance Features
-------------------------

The 5x86 contains a performance control register that allows
several performance enhancing features to be turned on. Unfortunately
many of these features do not appear to work correctly. The 5x86
performance features kernel build option will attempt to set
the performance control register appropriately but it is
impossible to guarantee that even these conservative settings
will work on all chips.

  WARNING: If this is enabled you may find that the only way to
reboot is to power cycle the machine. Even a hard reboot seems
to fail on some systems.


6x86 Performance Features
-------------------------

Like the 5x86 the 6x86 has several Cyrix specific performance
features. Normally a 6x86 aware BIOS will set these to reasonable,
if not fully optimal, settings. The 6x86 performance features
kernel build option mostly just fine tunes them.


6x86 Branch Prediction
----------------------

The 6x86 uses speculative execution coupled with several levels
of branch prediction to maximise processing speed. While the
default power up state is reasonable the branch prediction logic
is configurable and there may be some benefit in fine tuning it.

  Unfortunately Cyrix offer no documentation on how to configure
branch prediction and IBM have only partial documentation available.
Further detail and speculation is available from the 6x86opt package
by Mikael Johansson <Mikael.Johansson@helsinki.fi>.

  The initial power up state of the 6x86 configures the branch
prediction logic to handle short branches. The 6x86 branch target
buffer features kernel build option enables code that enables
handling of long branches as well. It is not clear if this will
benefit in your particular case or not.


6x86 Variable Sized Paging Mechanism
------------------------------------

The variable sized paging mechanism (VSPM) is a feature of the Cyrix
6x86 family of processors that allows large regions of memory
to be mapped using a single MMU entry rather than many individual
page sized entries. This significantly reduces the overhead in
accessing such regions. It is also ideally suited to use for the
linear mapping of physical memory to kernel memory used by Linux.

  The Cyrix documenation offers only a brief paragraph of explanation.
Unfortunately the observed behaviour of VSPM suggests that even
this little information is not entirely correct. Worse still, no one
at Cyrix is able to answer questions concerning VSPM. Given that
every revision of 6x86 has *different* VSPM bugs this is not entirely
surprising! Work arounds are in place for the known bugs in step 1,
revisions 4, 5 and 6 chips. Revision 7 is also believed to work.

  WARNING: There appears to be no way to disable a VSPM entry once
it has been created short of a hard reset (which may mean a power
cycle). Failure to clear the VSPM entries means that programs that
use virtual memory layouts different from Linux will crash unexpectedly
after Linux has been running. This includes Windows NT/95, programs
that use DOS extenders etc.

  By experiment:

  * VSPM pages must be power of two sizes. A single 24MB page fails.
    This is not entirely surprising but the documentation could give
    the impression that VSPM supports arbitrary sizes.

  * Documentation suggests there are 8 VSPM slots (3 bit index) but
    tests show the upper four slots mirror the lower four.

  * VSPM entries appear to override traditional page table entries
    so we must not overlap the start of the vmalloc region.

  The following only apply to 1 rev 6 and lower chips. 1 rev 7 and
  above do not appear to have these problems.

  * With a 16MB page followed by an 8MB page I always get a write
    fault on the last 4k of the 8MB page. With 8MB plus 4MB I can't
    even boot.
      If we have such a memory size we map the first power of two
    with a VSPM entry and use traditional paging for the rest.

  * Do not try and create a mapping with dirty and accessed flags
    clear - a step 1 rev 5 chip will crash.

  * The valid bit in a VSPM entry is non-functional. There is no way
    to invalidate a VSPM entry once it has been written.

  * Attempting to replace a VSPM entry with one that maps a zero
    sized region from 0 to 0 crashes the CPU.


What more could be done
-----------------------

  Disabling write allocate while we do page copies/clears will
avoid unnecessary cache trashing. However it will also reduce
the apparent memory bandwidth for the operation so it runs
slower (with write allocate the write to memory becomes delayed
and happens asynchronously). Rumour has it that disabling
write allocate for such operations is generally good on an
Intel chip. Disabling and re-enabling write allocate on a
Cyrix would take and extra 60-65 clock cycles each.

  The 6x86 allows Address regions to be set up and en/disabling 
certain features for these regions. In order to optimize, we could 
analyse the setup done (or not done) by the BIOS and optimize it.
However, it is worth noting that the BIOS probably has more
hardware specific details coded in it than we could ever determine
by any form of probing so if it sets something up in a particular
way the motherboard designers may have had very good reasons for
doing it. Trying to play fast and loose may not be such a good
idea for the general case.

  * Setting up regions fo the main memory: RCE, WWO, WL(?), WG

  * Setting up VGA text (0x000a0000) and graphics memory (PCI:
    e.g. 0xe0000000) to RCD, WG

  * Setting up BIOS regions to RCD or RCE, WT

  * Not touching SMM space (ARR3)

  * Disabling WG for Memory Mapped IO

(RCE/D = Region cache enable/disable, WWO = Weak Write Ordering,
WL = Weak Locking, WG = Write Gathering, WT = Write Through.)


Where to get information
------------------------

  There is a databook in PDF format (6X-DBOOK.PDF), which can be down-
loaded from Cyrix' WWW server, which contains a description of the 
Configuration Registers CCR0 - CCR5, the Device Identification Registers 
DIR0 + DIR1 and the Address Region ARRx and Region Control
RCRx registers and an incomplete description of the VSPM mechanism.
More about CPU detection, VSPM and more undocumented features can be
found on the Pentium Compiler Group homepage (http://www.goof.com/pcg)
and by following the links found in the docs.