Initial revision

4 files changed, 449 insertions, 17 deletions

diff --git a/Documentation/m68k/00-INDEX b/Documentation/m68k/00-INDEX
new file mode 100644
index 000000000..ae5b93488
--- /dev/null
+++ b/Documentation/m68k/00-INDEX
@@ -0,0 +1,9 @@
+00-INDEX
+	- this file
+amiboot.txt
+	- info and options for the Linux/m68k Amiga bootstrap (Amiboot)
+framebuffer.txt
+	- info about the Linux/m68k frame buffer device
+kernel-options.txt
+	- command line options for Linux/m68k
+
diff --git a/Documentation/m68k/amiboot.README b/Documentation/m68k/amiboot.txt
index 1e25e1d37..c119c6357 100644
--- a/Documentation/m68k/amiboot.README
+++ b/Documentation/m68k/amiboot.txt
@@ -1,7 +1,10 @@
 
-		Linux/m68k Amiga Bootstrap version 5.1
+		Linux/m68k Amiga Bootstrap version 5.5
 		--------------------------------------
 
+Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
+Last revised: March 27, 1997
+
 
 0. Introduction
 ---------------
@@ -10,7 +13,7 @@ Amiboot is used to boot Linux/m68k on Amiga from the CLI/Shell.
 
 Before you try to boot Linux/m68k for the first time, please read the FAQ
 
-    http://www-agrw.informatik.uni-kl.de/~jmayer/linux68k/linux68k-faq
+    http://www.clark.net/pub/lawrencc/linux/faq/faq.html
 
 and the Installation Guide
 
@@ -19,7 +22,7 @@ and the Installation Guide
 first. Although the Installation Guide is getting a bit outdated, it's still a
 good starting point.
 
-Amiboot 5.1 is meant for Linux/m68k 2.0.x, 2.1.x or higher (kernel bootinfo
+Amiboot 5.5 is meant for Linux/m68k 2.0.x, 2.1.x or higher (kernel bootinfo
 interface versions 1.x and 2.x). Please use an older version for older kernels.
 
 
@@ -30,23 +33,27 @@ The Amiboot invocation syntax looks like
 
     amiboot [options] [kernel command line]
 
-Valid options are:
+Basic options:
 
     --help           Display the usage information
 
     --kernel file    Use kernel image `file' (default is `vmlinux')
 
-    --ramdisk file   Use ramdisk image `file'.
+    --ramdisk file   Use ramdisk image `file'
+
+Advanced options:
 
     --debug          Enable debug mode
 
-    --baud           Set the serial port speed (default is 9600)
+    --baud speed     Set the serial port speed (default is 9600 bps)
 
     --memfile file   Use memory file `file'
 
     --keep-video     Don't reset the video mode
 
-    --model id       Set the Amiga model to `id'.
+    --model id       Set the Amiga model to `id'
+
+    --processor cfm  Set the processor type to `cfm'
 
 The kernel command line contains the options you want to pass to the kernel and
 to init, the process that's started first by Linux. Please read
@@ -57,6 +64,10 @@ Linux/m68k kernel image, and --ramdisk if you want to boot from a ramdisk file,
 i.e. a file containing a complete file system, instead of from a hard disk
 partition.
 
+Note that both the kernel image and the ramdisk image can be compressed with
+gzip. Amiboot knows how to deal with gzipped kernel images, and the kernel
+recognizes gzipped ramdisk images.
+
 Example:
 
     amiboot -k vmlinux-2.1.13 root=/dev/hda3 video=font:PEARL8x8
@@ -65,8 +76,8 @@ Amiboot will boot the kernel image `vmlinux-2.1.13' and will pass
 `root=/dev/hda3 video=font:PEARL8x8' to the kernel.
 
 
-The other options are more specialized. Don't use them unless you really have
-to and you know what you're doing.
+The other options are more advanced. Don't use them unless you really have to
+and you know what you're doing.
 
 The --baud option allows you to specify the serial port speed for initial boot
 information and initial kernel messages. Note: this option does not work with
@@ -79,8 +90,9 @@ The --keep-video option is necessary if you want to retain the current graphics
 mode (on a graphics board) under Linux. Currently this is only useful if you
 have a CyberVision 64 graphics board.
 
-Finally, --model allows you to specify your Amiga model, and --debug is for
-debugging purposes.
+Finally, --model and --processor allow you to specify your Amiga model and
+processor type if they are detected incorrectly, and --debug dumps some
+information which simplifies debugging.
 
 
 2. The memory file
@@ -98,7 +110,7 @@ format for the file is:
     ...
 
 For example, if you don't want Linux to use your 2nd meg of chipram, you would
-create a file that looks contains only:
+create a file that contains only:
 
     1048576
 
@@ -149,7 +161,33 @@ Please send me the output of amiboot used with the --debug option if your Amiga
 model is detected incorrectly.
 
 
-4. Abbreviations
+4. Processor types
+------------------
+
+If your processor is detected incorrectly, you can override this using the
+`--processor cfm' option. `cfm' must be a three-digit number with
+
+  - `c' the CPU (Central Processing Unit) type,
+  - 'f' the FPU (Floating Point Unit) type,
+  - 'm' the MMU (Memory Management Unit) type,
+
+from the table below:
+
+     value |  CPU  |  FPU  |  MMU
+    -------+-------+-------+-------
+       0   |   -   |   -   |   -
+       1   | 68020 | 68881 | 68851
+       2   | 68030 | 68882 | 68030
+       3   | 68040 | 68040 | 68040
+       4   | 68060 | 68060 | 68060
+
+e.g. `444' if you have a 68060 and `303' if you have a 68LC040.
+
+Note that normally you don't have to use this option. It's only needed for some
+combinations of an old Kickstart ROM and a new processor (e.g. a 68060).
+
+
+5. Abbreviations
 ----------------
 
 All options also have a shorthand:
@@ -162,9 +200,10 @@ All options also have a shorthand:
     --memfile	    -m
     --keep-video    -v
     --model	    -t
+    --processor	    -p
 
 
-5. Miscellaneous
+6. Miscellaneous
 ----------------
 
 Some expansion boards keep on generating interrupts once they were initialized
@@ -186,7 +225,7 @@ routine for them yet:
 If you write a routine to disable an expansion board, please let me know.
 
 
-6. Troubleshooting
+7. Troubleshooting
 ------------------
 
   - Amiboot says
@@ -222,11 +261,13 @@ If you write a routine to disable an expansion board, please let me know.
 
       o If that doesn't work, remove any expansion devices and retry.
 
+      o Check the detected Amiga model and processor type.
+
       o Look at the characters that are dumped to the serial port during
 	booting.
 
 
-7. Amiga-Lilo
+8. Amiga-Lilo
 -------------
 
 Once you have a stable Linux/m68k installation, you may want to try Amiga-Lilo.
@@ -234,7 +275,7 @@ Amiga-Lilo allows you to boot Linux/m68k without the overhead of booting
 AmigaOS first, and it provides you with a boot menu.
 
 
-8. Credits
+9. Credits
 ----------
 
 This readme was written by Geert Uytterhoeven. A lot of information was taken
diff --git a/Documentation/m68k/framebuffer.txt b/Documentation/m68k/framebuffer.txt
new file mode 100644
index 000000000..490a33793
--- /dev/null
+++ b/Documentation/m68k/framebuffer.txt
@@ -0,0 +1,370 @@
+
+		The Linux/m68k Frame Buffer Device
+		----------------------------------
+
+Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
+Last revised: March 23, 1997
+
+
+0. Introduction
+---------------
+
+The frame buffer device provides an abstraction for the graphics hardware. It
+represents the frame buffer of some video hardware and allows application
+software to access the graphics hardware through a well-defined interface, so
+the software doesn't need to know anything about the low-level (hardware
+register) stuff.
+
+The device is accessed through special device nodes, usually located in the
+/dev directory, i.e. /dev/fb*.
+
+
+1. User's View of /dev/fb*
+--------------------------
+
+From the user's point of view, the frame buffer device looks just like any
+other device in /dev. It's a character device using major 29, the minor is
+divided into a frame buffer number in the upper 3 bits (allowing max. 8 frame
+buffers simultaneously) and a resolution code in the lower 5 bits of the minor.
+
+By convention, the following device nodes are used (numbers indicate the device
+minor numbers):
+
+    First frame buffer
+	 0 = /dev/fb0current		Current resolution
+	 1 = /dev/fb0autodetect		Default resolution
+	 2 = /dev/fb0predefined0	Predefined resolutions (22)
+	     ...
+	23 = /dev/fb0predefined21
+	24 = /dev/fb0user0		User defined resolutions (8)
+	     ...
+	31 = /dev/fb0user7                              
+
+    Second frame buffer
+	32 = /dev/fb1current		Current resolution
+	33 = /dev/fb1autodetect		Default resolution
+	34 = /dev/fb1predefined0	Predefined resolutions (22)
+	     ...
+	55 = /dev/fb1predefined21
+	56 = /dev/fb1user0		User defined resolutions (8)
+	     ...                                          
+	63 = /dev/fb1user7                                 
+
+and so on...
+
+The device with (minor & 31) == 0 (/dev/fb?current) stands for the frame buffer
+together with the currently set video parameters; (minor & 31) == 1
+(/dev/fb?autodetect) is the video mode detected at boot time. Any other minor
+stands for some predefined or user defined video mode.
+
+The predefined entries (/dev/fb?predefined*) usually have a device dependent
+name, e.g. for major 29, minor 5, we have /dev/fb0multiscan on Amiga and
+/dev/fb0ttmid on Atari. These are meant to contain hardware dependent
+resolutions.
+
+The user defined resolutions (/dev/fb?user?) are meant to be filled in by the
+user. This way the user can store his favorite 8 resolutions during boot up.
+
+Note: if you need more than 8 user defined resolutions, you can always override
+the predefined resolutions by storing them in one of the predefined entries.
+But this is not recommended. Similarly, if there are more than 22 predefined
+resolutions, the device writer can decide to store them in the user defined
+entries.
+
+If the device is opened (for writing), the frame buffer driver switches to the
+selected video mode. Thus, you can switch video modes by writing to a frame
+buffer device, e.g.
+
+    > /dev/fb0ttlow
+
+will switch your video to TT low mode. Note: if you specify a resolution which
+contains a value that's not possible on your hardware, the frame buffer device
+will round it up (if possible) or return an error condition.
+
+The frame buffer devices are also `normal' memory devices, this means, you can
+read and write their contents. You can, for example, make a screen snapshot by
+
+  cp /dev/fb0current myfile
+
+There also can be more than one frame buffer at a time, e.g. if you have a
+graphics card in addition to the built-in hardware. The corresponding frame
+buffer devices (/dev/fb0* and /dev/fb1* etc.) work independently.
+
+Application software that uses the frame buffer device (e.g. the X server) will
+use /dev/fb0current by default. You can specify an alternative resolution by
+setting the environment variable $FRAMEBUFFER to the path name of a frame
+buffer device, e.g. (for sh/bash users):
+
+    export FRAMEBUFFER=/dev/fb0multiscan
+
+or (for csh users):
+
+    setenv FRAMEBUFFER /dev/fb0multiscan
+
+After this the X server will use the multiscan video mode.
+
+
+2. Programmer's View of /dev/fb*
+--------------------------------
+
+As you already know, a frame buffer device is a memory device like /dev/mem and
+it has the same features. You can read it, write it, seek to some location in
+it and mmap() it (the main usage). The difference is just that the memory that
+appears in the special file is not the whole memory, but the frame buffer of
+some video hardware.
+
+/dev/fb* also allows several ioctls on it, by which lots of information about
+the hardware can be queried and set. The color map handling works via ioctls,
+too. Look into <linux/fb.h> for more information on what ioctls exist and on
+which data structures they work. Here's just a brief overview:
+
+  - You can request unchangeable information about the hardware, like name,
+    organization of the screen memory (planes, packed pixels, ...) and address
+    and length of the screen memory.
+
+  - You can request and change variable information about the hardware, like
+    visible and virtual geometry, depth, color map format, timing, and so on.
+    If you try to change that informations, the driver maybe will round up some
+    values to meet the hardware's capabilities (or return EINVAL if that isn't
+    possible).
+
+  - You can get and set parts of the color map. Communication is done with 16
+    bit per color part (red, green, blue, transparency) to support all existing
+    hardware. The driver does all the computations needed to bring it into the
+    hardware (round it down to less bits, maybe throw away transparency).
+
+All this hardware abstraction makes the implementation of application programs
+easier and more portable. E.g. the X server works completely on /dev/fb* and
+thus doesn't need to know, for example, how the color registers of the concrete
+hardware are organized. XF68_FBDev is a general X server for bitmapped,
+unaccelerated video hardware. The only thing that has to be built into
+application programs is the screen organization (bitplanes or chunky pixels
+etc.), because it works on the frame buffer image data directly.
+
+For the future it is planned that frame buffer drivers for graphics cards and
+the like can be implemented as kernel modules that are loaded at runtime. Such
+a driver just has to call register_framebuffer() and supply some functions.
+Writing and distributing such drivers independently from the kernel will save
+much trouble...
+
+
+3. Frame Buffer Resolution Maintenance
+--------------------------------------
+
+Frame buffer resolutions are maintained using the utility `fbset'. It allows to
+change the video mode properties of the current or a user defined resolution.
+It's main usage is to tune video modes and to store custom resolutions into one
+of the /dev/fb?user?  entries, e.g. during boot up in one of your /etc/rc.* or
+/etc/init.d/* files, after which those resolutions can be used by applications.
+
+Fbset uses a video mode database stored in a configuration file, so you can
+easily add your own modes and refer to them with a simple identifier. The fbset
+install script also creates the special device nodes for the device dependent
+predefined resolutions.
+
+
+4. The X Server
+---------------
+
+The X server (XF68_FBDev) is the most notable application program for the frame
+buffer device. The current X server is part of the XFree86/XFree68 release 3.2
+package and has 2 modes:
+
+  - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
+    file contains a
+
+	Modes "default"
+
+    line, the X server will use the scheme discussed above, i.e. it will start
+    up in the resolution determined by /dev/fb0current (or $FRAMEBUFFER, if
+    set). This is the default for the configuration file supplied with XFree68
+    3.2. It's the most simple configuration (and the only possible one if you
+    want to have a broadcast compatible display, e.g. PAL or NTSC), but it has
+    some limitations.
+
+  - Therefore it's also possible to specify resolutions in the /etc/XF86Config
+    file. This allows for on-the-fly resolution switching while retaining the
+    same virtual desktop size. The frame buffer device that's used is still
+    /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
+    defined by /etc/XF86Config now. The disadvantage is that you have to
+    specify the timings in a different format (but `fbset -x' may help) and
+    that you can't have a broadcast compatible display (e.g. no PAL or NTSC).
+
+To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
+work 100% with XF68_FBDev: the reported clock values are always incorrect.
+
+There exists also an accelerated X server for the Cybervision 64 graphics
+board, but that's not discussed here.
+
+
+5. Video Mode Timings
+---------------------
+
+A monitor draws an image on the screen by using an electron beam (3 electron
+beams for most color models, 1 electron beam for Trinitron color monitors and
+monochrone monitors). The front of the screen is covered by a pattern of
+colored phospors (pixels). If a phospor is hit by an electron, it emits a
+photon and thus becomes visible.
+
+The electron beam draws horizontal lines (scanlines) from left to right, and
+from the top to the bottom of the screen. By modifying the intensity of the
+electron beam, pixels with various colors and intensities can be shown.
+
+After each scanline the electron beam has to move back to the left side of the
+screen and to the next line: this is called the horizontal retrace. After the
+whole screen (frame) was painted, the beam moves back to the upper left corner:
+this is called the vertical retrace. During both the horizontal and vertical
+retrace, the electron beam is turned off (blanked).
+
+The speed at which the electron beam paints the pixels is determined by the
+dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
+of cycles per second), each pixel is 35242 ps (picoseconds) long:
+
+    1/(28.37516E6 Hz) = 35.242E-9 s
+
+If the screen resolution is 640x480, it will take
+
+    640*35.242E-9 s = 22.555E-6 s
+
+to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
+also takes time (e.g. 272 `pixels'), so a full scanline takes
+
+    (640+272)*35.242E-9 s = 32.141E-6 s
+
+We'll say that the horizontal scanrate is about 31 kHz:
+
+    1/(32.141E-6 s) = 31.113E3 Hz
+
+A full screen counts 480 (yres) lines, but we have to consider the vertical
+retrace too (e.g. 49 `pixels'). So a full screen will take
+
+    (480+49)*32.141E-6 s = 17.002E-3 s
+
+The vertical scanrate is about 59 Hz:
+
+    1/(17.002E-3 s) = 58.815 Hz
+
+This means the screen data is refreshed about 59 times per second. To have a
+stable picture without visible flicker, VESA recommends a vertical scanrate of
+at least 72 Hz. But the perceived flicker is very human dependent: some people
+can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
+
+Since the monitor doesn't know when a new scanline starts, the graphics board
+will supply a synchronization pulse (horizontal sync or hsync) for each
+scanline.  Similarly it supplies a synchronization pulse (vertical sync or
+vsync) for each new frame. The position of the image on the screen is
+influenced by the moments at which the synchronization pulses occur.
+
+The following picture summarizes all timings. The horizontal retrace time is
+the sum of the left margin, the right margin and the hsync length, while the
+vertical retrace time is the sum of the upper margin, the lower margin and the
+vsync length.
+
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |upper_margin                |          |       |
+  |          |                ¥                            |          |       |
+  +----------###############################################----------+-------+
+  |          #                ^                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |   left   #                |                            #  right   | hsync |
+  |  margin  #                |       xres                 #  margin  |  len  |
+  |<-------->#<---------------+--------------------------->#<-------->|<----->|
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |yres                        #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                ¥                            #          |       |
+  +----------###############################################----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |lower_margin                |          |       |
+  |          |                ¥                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |vsync_len                   |          |       |
+  |          |                ¥                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+
+The frame buffer device expects all horizontal timings in number of dotclocks
+(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
+
+
+6. Converting XFree86 timing values info frame buffer device timings
+--------------------------------------------------------------------
+
+An XFree86 mode line consists of the following fields:
+ "800x600"     50      800  856  976 1040    600  637  643  666
+ < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL
+
+The frame buffer device uses the following fields:
+
+  - pixclock: pixel clock in ps (pico seconds)
+  - left_margin: time from sync to picture
+  - right_margin: time from picture to sync
+  - upper_margin: time from sync to picture
+  - lower_margin: time from picture to sync
+  - hsync_len: length of horizontal sync
+  - vsync_len: length of vertical sync
+
+1) Pixelclock:
+   xfree: in MHz
+   fb: In Picoseconds (ps)
+
+   pixclock = 1000000 / DCF
+
+2) horizontal timings:
+   left_margin = HFL - SH2
+   right_margin = SH1 - HR
+   hsync_len = SH2 - SH1
+
+3) vertical timings:
+   upper_margin = VFL - SV2
+   lower_margin = SV1 - VR
+   vsync_len = SV2 - SV1
+
+Good examples for VESA timings can be found in the XFree86 source tree,
+under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
+
+
+7. References
+-------------
+
+For more specific information about the frame buffer device and its
+applications, please refer to the following documentation:
+
+  - The manual pages for fbset: fbset(8), fb.modes(5)
+  - The manual pages for XFree68: XF68_FBDev(1), XF86Config(4/5)
+  - The mighty kernel sources:
+      o linux/include/linux/fb.h
+      o linux/drivers/char/fbmem.c
+      o linux/arch/m68k/*/*fb.c
+
+
+8. Downloading
+--------------
+
+All necessary files can be found at
+
+    ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
+
+and on its mirrors.
+
+  
+9. Credits                                                       
+----------                                                       
+                
+This readme was written by Geert Uytterhoeven, partly based on the original
+`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
+provided by Frank Neumann.
+
+The frame buffer device abstraction was designed by Martin Schaller.
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index b5878662d..ed0c203d0 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -800,6 +800,18 @@ hostadapters.
   No argument. Used to separate blocks of keywords when there's more
 than one host adapter in the system.
 
+5.3.7) nodma
+------------
+
+Syntax: nodma:x
+
+  If x is 1 (or if the option is just written as "nodma"), the WD33c93
+controller will not use DMA (= direct memory access) to access the
+Amiga's memory.  This is useful for some systems (like A3000's and
+A4000's with the A3640 accelerator, revision 3.0) that have problems
+using DMA to chip memory.  The default is 0, i.e. to use DMA if
+possible.
+
 
 5.4) gvp11=
 -----------