Update of /cvsroot/linux-vax/kernel-2.4/Documentation/vax
In directory usw-pr-cvs1:/tmp/cvs-serv14866/Documentation/vax
Added Files:
cpu.txt
Log Message:
Start documenting CPU details
--- NEW FILE ---
$Id: cpu.txt,v 1.1 2001/03/04 23:41:37 kenn Exp $
INTRODUCTION
============
This file attempts to collate all the CPUs that we know about, how they
are identified and any quirks or bugs that we need to watch for.
VAX CPUs are identified with model numbers beginning with KA followed
by 2 or 3 digits. Multiple DEC systems may use the same CPUs, with
different surrounding hardware (and slightly different firmware in some
cases), but the basic operation should be much the same.
These CPUs fall into families that seem to have various codenames
(such as RIGEL and MARIAH). Where possible, we will try to use the KAxx
designations, rather than the codenames.
A VAX CPU is identified during boot by first examining internal processor
register 0x3E (PR$_SID). The high byte of this register seems to denote
the processor family. The meaning of the low 3 bytes depends on the family.
SUPPORTED CPUS
==============
KA42
KA43
KA46
KA410
KA630
KA650
UNSUPPORTED CPUS
================
KA41
KA52
KA55
KA60
KA620
KA640
KA655
KA660
KA730
KA750
KA780
KA785
KA790
*******************************************************************************
*******************************************************************************
KA650
=====
Description:
Q-22 bus single-board CPU. M-number is M7620. Based on the CVAX
implementation of VAX. Sometimes called a MicroVAX III.
The only I/O on the CPU itself is the console serial port.
Shipped in:
VAXstation 3500
Identification:
PR$_SID:
The high byte is 0x0A. This indicates a CVAX-based CPU. The low
byte holds the microcode revision.
SIDEX at 20040004:
The high byte is 0x01. This seems to indicate a Qbus CPU.
Bits 16 to 23 hold the firmware revision.
Bits 8 to 15 contain 0x01. This means KA650.
The meaning of bits 0 to 7 is unknown.
Notes:
The KA650's firmware is held in a pair of 27512 EPROMs. Some units
shipped with firmware versions that didn't even have a HELP
command.
Looking at the KA650 firmware, it looks like the same firmware is
used in the KA640 and KA655 as well. There are a lot of CASEx
instructions that dispatch on bits 8 to 15 of SIDEX.
*******************************************************************************
*******************************************************************************
KA43
====
Description:
Integrated CPU and mainboard based on the RIGEL implementation of VAX.
The board also contains two NCR5380 SCSI controllers, an AMD LANCE
ethernet controller and a DZ11-compatible serial controller.
Maximum memory is 32MB.
Online copy of the VAXstation 3100 Model 76 Owner's Guide (EK-VX31M-UG)
available at http://www.whiteice.com/~williamwebb/intro/DOC-i.html.
Shipped in:
VAXstation 3100 Model 76
Identification:
PR$_SID:
The high byte is 0x0B. This seems to indicate a RIGEL-based CPU.
The meaning of the low 3 bytes is unknown.
SIDEX at 20040004:
The meaning of the SIDEX is unknown.
Notes:
Sharing memory with the LANCE chip requires a bit of hackery. Physical
memory is accessible from 0x00000000 to 0x01ffffff (as normal), but is
also accessible via the "DIAGMEM" region of I/O space from 0x28000000
to 0x29ffffff. To prevent strange behaviour (such as memory read
parity error machine checks), you _must_ read and write the memory
shared with the LANCE via the DIAGMEM region.
One way to do this is to kmalloc() a region for the LANCE structures
and buffers and modify the PTEs for this region to OR in bits
0x00140000 in the PFN field (to make them point to the DIAGMEM region).
Actually, using get_free_pages() might be a better idea, since there
might be other data structures sharing pages with this region, because
kmalloc() doesn't page-align.
Another way is to calculate the physical addresses behind the kmalloc()ed
region and ioremap() them. This has the disadvantage of using twice as
many PTEs.
It looks like this might be needed for DMA to the SCSI controllers as
well.
|
