From d8d9b8f76f22b7a16a83e261e64f89ee611f49df Mon Sep 17 00:00:00 2001 From: Ralf Baechle Date: Sun, 1 Jun 1997 03:16:17 +0000 Subject: Initial revision --- Documentation/m68k/00-INDEX | 9 + Documentation/m68k/amiboot.README | 241 ---------------------- Documentation/m68k/amiboot.txt | 282 ++++++++++++++++++++++++++ Documentation/m68k/framebuffer.txt | 370 ++++++++++++++++++++++++++++++++++ Documentation/m68k/kernel-options.txt | 12 ++ 5 files changed, 673 insertions(+), 241 deletions(-) create mode 100644 Documentation/m68k/00-INDEX delete mode 100644 Documentation/m68k/amiboot.README create mode 100644 Documentation/m68k/amiboot.txt create mode 100644 Documentation/m68k/framebuffer.txt (limited to 'Documentation/m68k') 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.README deleted file mode 100644 index 1e25e1d37..000000000 --- a/Documentation/m68k/amiboot.README +++ /dev/null @@ -1,241 +0,0 @@ - - Linux/m68k Amiga Bootstrap version 5.1 - -------------------------------------- - - -0. Introduction ---------------- - -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 - -and the Installation Guide - - http://www.informatik.uni-oldenburg.de/~amigo/inst.html - -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 -interface versions 1.x and 2.x). Please use an older version for older kernels. - - -1. Running Amiboot ------------------- - -The Amiboot invocation syntax looks like - - amiboot [options] [kernel command line] - -Valid options are: - - --help Display the usage information - - --kernel file Use kernel image `file' (default is `vmlinux') - - --ramdisk file Use ramdisk image `file'. - - --debug Enable debug mode - - --baud Set the serial port speed (default is 9600) - - --memfile file Use memory file `file' - - --keep-video Don't reset the video mode - - --model id Set the Amiga model to `id'. - -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 -linux/Documentation/m68k/kernel-options.txt for more information. - -Normally you only use the --kernel option to specify the file that contains the -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. - -Example: - - amiboot -k vmlinux-2.1.13 root=/dev/hda3 video=font:PEARL8x8 - -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 --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 -kernels with bootinfo interface versions prior to 2.0. - -The --memfile option is used to specify the blocks of memory that will be used -by Linux. - -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. - - -2. The memory file ------------------- - -If you have some non-AutoConfig memory you want to use under Linux, or if you -want to disable some parts of your memory (e.g. Zorro II RAM on '040 based -systems), you have to use a memory file and the --memfile option. This file -contains information about the memory chunks you want to use under Linux. The -format for the file is: - - chipramsize - [0xfastchunkaddr fastchunksize] - [0xfastchunkaddr fastchunksize] - ... - -For example, if you don't want Linux to use your 2nd meg of chipram, you would -create a file that looks contains only: - - 1048576 - -If you had 1M of chip ram, 2M of 16 bit FAST ram at address 0x200000 and 16M of -32 bit FAST ram at address 0x80000000, and you didn't want Linux to use the -slow 16 bit FAST ram, you'd create a file that looks like: - - 1048576 - 0x80000000 16777216 - -The memory file can also be used to specify in which block of memory the kernel -will be put. Normally Amiboot will put the kernel in the first block of Fast -RAM it will find. If you use a memory file, it will put the kernel in the first -block of fast RAM you specify. - - -3. Amiga models ---------------- - -If Amiboot incorrectly detects the model of your Amiga, you can force it to -detect any model you want using the --model option. `id' must be one of the -numbers as defined in linux/include/asm-m68k/amigahw.h (AMI_*). Currently the -following models are known: - - Model ID - ----- -- - Amiga 500 1 - Amiga 500+ 2 - Amiga 600 3 - Amiga 1000 4 - Amiga 1200 5 - Amiga 2000 6 - Amiga 2500 7 - Amiga 3000 8 - Amiga 3000T 9 - Amiga 3000+ 10 - Amiga 4000 11 - Amiga 4000T 12 - CDTV 13 - CD32 14 - Draco 15 - -Note that Amiboot can't distinguish among Amiga models that are very similar to -each other (e.g. A500/A1000/A2000/A2500 and A3000/A3000T). Of course this is -harmless and there's no real need to use --model in that case. - -Please send me the output of amiboot used with the --debug option if your Amiga -model is detected incorrectly. - - -4. Abbreviations ----------------- - -All options also have a shorthand: - - --help -h - --kernel -k - --ramdisk -r - --debug -d - --baud -b - --memfile -m - --keep-video -v - --model -t - - -5. Miscellaneous ----------------- - -Some expansion boards keep on generating interrupts once they were initialized -under AmigaOS. This can cause an interrupt deadlock while booting Linux. The -following boards are recognized and disabled: - - o Helfrich Rainbow 3 Graphics Board - o Helfrich Piccolo Graphics Board - o Helfrich SD64 Graphics Board - o Village Tronic Ariadne Ethernet Board - o Hydra Systems Amiganet Ethernet Board - -The following boards are known to cause problems but we don't have a disable -routine for them yet: - - o Commodore A2060 Arcnet Card - o Ameristar A560 Arcnet Card - -If you write a routine to disable an expansion board, please let me know. - - -6. Troubleshooting ------------------- - - - Amiboot says - - This bootstrap is too old/new for this kernel - - This means that you're using a version of Amiboot that's not compatible - with the kernel you want to boot. - - Solution: use the correct Amiboot, or use another kernel. - - - Amiboot says - - Warning: too many AutoConfig devices. Ignoring device at 0x???????? - - or - - Warning: too many memory blocks. Ignoring block of ???K at 0x???????? - - This means that you have more AutoConfig devices or memory chunks than - Amiboot supports. Note that you can still boot Linux/m68k, but that the - additional devices or memory blocks can't be used. - - Solution: increase the ZORRO_NUM_AUTO (for AutoConfig devices) or - NUM_MEMINFO (for memory chunks) values in the kernel sources - (linux/include/asm-m68k/zorro.h and linux/include/asm-m68k/setup.h) and - recompile both Amiboot and the kernel. - - - If all you get is a grey screen, or if Linux/m68k suddenly locks up during - booting, try the following things: - - o Boot with the Startup-Sequence disabled, run SetPatch and try again. - - o If that doesn't work, remove any expansion devices and retry. - - o Look at the characters that are dumped to the serial port during - booting. - - -7. Amiga-Lilo -------------- - -Once you have a stable Linux/m68k installation, you may want to try Amiga-Lilo. -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 ----------- - -This readme was written by Geert Uytterhoeven. A lot of information was taken -from the ANNOUNCE-* files by Hamish Macdonald. diff --git a/Documentation/m68k/amiboot.txt b/Documentation/m68k/amiboot.txt new file mode 100644 index 000000000..c119c6357 --- /dev/null +++ b/Documentation/m68k/amiboot.txt @@ -0,0 +1,282 @@ + + Linux/m68k Amiga Bootstrap version 5.5 + -------------------------------------- + +Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be) +Last revised: March 27, 1997 + + +0. Introduction +--------------- + +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.clark.net/pub/lawrencc/linux/faq/faq.html + +and the Installation Guide + + http://www.informatik.uni-oldenburg.de/~amigo/inst.html + +first. Although the Installation Guide is getting a bit outdated, it's still a +good starting point. + +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. + + +1. Running Amiboot +------------------ + +The Amiboot invocation syntax looks like + + amiboot [options] [kernel command line] + +Basic options: + + --help Display the usage information + + --kernel file Use kernel image `file' (default is `vmlinux') + + --ramdisk file Use ramdisk image `file' + +Advanced options: + + --debug Enable debug mode + + --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' + + --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 +linux/Documentation/m68k/kernel-options.txt for more information. + +Normally you only use the --kernel option to specify the file that contains the +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 + +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 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 +kernels with bootinfo interface versions prior to 2.0. + +The --memfile option is used to specify the blocks of memory that will be used +by Linux. + +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 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 +------------------ + +If you have some non-AutoConfig memory you want to use under Linux, or if you +want to disable some parts of your memory (e.g. Zorro II RAM on '040 based +systems), you have to use a memory file and the --memfile option. This file +contains information about the memory chunks you want to use under Linux. The +format for the file is: + + chipramsize + [0xfastchunkaddr fastchunksize] + [0xfastchunkaddr fastchunksize] + ... + +For example, if you don't want Linux to use your 2nd meg of chipram, you would +create a file that contains only: + + 1048576 + +If you had 1M of chip ram, 2M of 16 bit FAST ram at address 0x200000 and 16M of +32 bit FAST ram at address 0x80000000, and you didn't want Linux to use the +slow 16 bit FAST ram, you'd create a file that looks like: + + 1048576 + 0x80000000 16777216 + +The memory file can also be used to specify in which block of memory the kernel +will be put. Normally Amiboot will put the kernel in the first block of Fast +RAM it will find. If you use a memory file, it will put the kernel in the first +block of fast RAM you specify. + + +3. Amiga models +--------------- + +If Amiboot incorrectly detects the model of your Amiga, you can force it to +detect any model you want using the --model option. `id' must be one of the +numbers as defined in linux/include/asm-m68k/amigahw.h (AMI_*). Currently the +following models are known: + + Model ID + ----- -- + Amiga 500 1 + Amiga 500+ 2 + Amiga 600 3 + Amiga 1000 4 + Amiga 1200 5 + Amiga 2000 6 + Amiga 2500 7 + Amiga 3000 8 + Amiga 3000T 9 + Amiga 3000+ 10 + Amiga 4000 11 + Amiga 4000T 12 + CDTV 13 + CD32 14 + Draco 15 + +Note that Amiboot can't distinguish among Amiga models that are very similar to +each other (e.g. A500/A1000/A2000/A2500 and A3000/A3000T). Of course this is +harmless and there's no real need to use --model in that case. + +Please send me the output of amiboot used with the --debug option if your Amiga +model is detected incorrectly. + + +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: + + --help -h + --kernel -k + --ramdisk -r + --debug -d + --baud -b + --memfile -m + --keep-video -v + --model -t + --processor -p + + +6. Miscellaneous +---------------- + +Some expansion boards keep on generating interrupts once they were initialized +under AmigaOS. This can cause an interrupt deadlock while booting Linux. The +following boards are recognized and disabled: + + o Helfrich Rainbow 3 Graphics Board + o Helfrich Piccolo Graphics Board + o Helfrich SD64 Graphics Board + o Village Tronic Ariadne Ethernet Board + o Hydra Systems Amiganet Ethernet Board + +The following boards are known to cause problems but we don't have a disable +routine for them yet: + + o Commodore A2060 Arcnet Card + o Ameristar A560 Arcnet Card + +If you write a routine to disable an expansion board, please let me know. + + +7. Troubleshooting +------------------ + + - Amiboot says + + This bootstrap is too old/new for this kernel + + This means that you're using a version of Amiboot that's not compatible + with the kernel you want to boot. + + Solution: use the correct Amiboot, or use another kernel. + + - Amiboot says + + Warning: too many AutoConfig devices. Ignoring device at 0x???????? + + or + + Warning: too many memory blocks. Ignoring block of ???K at 0x???????? + + This means that you have more AutoConfig devices or memory chunks than + Amiboot supports. Note that you can still boot Linux/m68k, but that the + additional devices or memory blocks can't be used. + + Solution: increase the ZORRO_NUM_AUTO (for AutoConfig devices) or + NUM_MEMINFO (for memory chunks) values in the kernel sources + (linux/include/asm-m68k/zorro.h and linux/include/asm-m68k/setup.h) and + recompile both Amiboot and the kernel. + + - If all you get is a grey screen, or if Linux/m68k suddenly locks up during + booting, try the following things: + + o Boot with the Startup-Sequence disabled, run SetPatch and try again. + + 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. + + +8. Amiga-Lilo +------------- + +Once you have a stable Linux/m68k installation, you may want to try Amiga-Lilo. +Amiga-Lilo allows you to boot Linux/m68k without the overhead of booting +AmigaOS first, and it provides you with a boot menu. + + +9. Credits +---------- + +This readme was written by Geert Uytterhoeven. A lot of information was taken +from the ANNOUNCE-* files by Hamish Macdonald. 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 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= ----------- -- cgit v1.2.3