[LV-kern-commit] CVS: kernel-2.4/Documentation/vax cpu.txt,NONE,1.1

[Kenn H. <ke...@us...>]

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.