1 files changed, 151 insertions, 0 deletions
diff --git a/ca/preparing/pre-install-bios-setup.xml b/ca/preparing/pre-install-bios-setup.xml
new file mode 100644
index 000000000..74d57db2d
--- /dev/null
+++ b/ca/preparing/pre-install-bios-setup.xml
@@ -0,0 +1,151 @@
+<!-- retain these comments for translator revision tracking -->
+<!-- original version: 28997 untranslated -->
+
+ <sect1 id="pre-install-bios-setup">
+ <title>Pre-Installation Hardware and Operating System Setup</title>
+<para>
+
+This section will walk you through pre-installation hardware setup, if
+any, that you will need to do prior to installing Debian.  Generally,
+this involves checking and possibly changing firmware settings for
+your system.  The <quote>firmware</quote> is the core software used by the
+hardware; it is most critically invoked during the bootstrap process
+(after power-up). Known hardware issues affecting the reliability of
+&debian; on your system are also highlighted.
+
+</para>
+
+&bios-setup-i386.xml;
+&bios-setup-m68k.xml;
+&bios-setup-powerpc.xml;
+&bios-setup-sparc.xml;
+&bios-setup-s390.xml;
+
+  <sect2><title>Hardware Issues to Watch Out For</title>
+<para arch="not-s390">
+
+Many people have tried operating their 90 MHz CPU at 100 MHz, etc.  It
+sometimes works, but is sensitive to temperature and other factors and
+can actually damage your system. One of the authors of this document
+over-clocked his own system for a year, and then the system started
+aborting the <command>gcc</command> program with an unexpected signal
+while it was compiling the operating system kernel. Turning the CPU
+speed back down to its rated value solved the problem.
+
+</para><para arch="not-s390">
+
+The <command>gcc</command> compiler is often the first thing to die
+from bad memory modules (or other hardware problems that change data
+unpredictably) because it builds huge data structures that it
+traverses repeatedly.  An error in these data structures will cause it
+to execute an illegal instruction or access a non-existent
+address. The symptom of this will be <command>gcc</command> dying from
+an unexpected signal.
+
+</para><para arch="m68k">
+
+Atari TT RAM boards are notorious for RAM problems under Linux; if you
+encounter any strange problems, try running at least the kernel in
+ST-RAM.  Amiga users may need to exclude RAM using a booter memfile.
+
+<phrase condition="FIXME"><emphasis>
+
+FIXME: more description of this needed.
+
+</emphasis></phrase>
+
+</para><para arch="i386">
+
+The very best motherboards support parity RAM and will actually tell
+you if your system has a single-bit error in RAM. Unfortunately, they
+don't have a way to fix the error, thus they generally crash
+immediately after they tell you about the bad RAM. Still, it's better
+to be told you have bad memory than to have it silently insert errors
+in your data. Thus, the best systems have motherboards that support
+parity and true-parity memory modules; see
+<xref linkend="Parity-RAM"/>.
+
+</para><para arch="i386">
+
+If you do have true-parity RAM and your motherboard can handle it, be
+sure to enable any BIOS settings that cause the motherboard to
+interrupt on memory parity errors.
+
+</para>
+
+   <sect3 arch="i386"><title>The Turbo Switch</title>
+<para>
+
+Many systems have a <emphasis>turbo</emphasis> switch that controls
+the speed of the CPU.  Select the high-speed setting. If your BIOS
+allows you to disable software control of the turbo switch (or
+software control of CPU speed), do so and lock the system in
+high-speed mode. We have one report that on a particular system, while
+Linux is auto-probing (looking for hardware devices) it can
+accidentally touch the software control for the turbo switch.
+
+</para>
+   </sect3>
+
+   <sect3 arch="i386"><title>Cyrix CPUs and Floppy Disk Errors</title>
+<para>
+
+Many users of Cyrix CPUs have had to disable the cache in their
+systems during installation, because the floppy disk has errors if
+they do not.  If you have to do this, be sure to re-enable your cache
+when you are finished with installation, as the system runs
+<emphasis>much</emphasis> slower with the cache disabled.
+
+</para><para>
+
+We don't think this is necessarily the fault of the Cyrix CPU. It may
+be something that Linux can work around. We'll continue to look into
+the problem.  For the technically curious, we suspect a problem with
+the cache being invalid after a switch from 16-bit to 32-bit code.
+
+</para>
+   </sect3>
+
+   <sect3 arch="i386"><title>Peripheral Hardware Settings</title>
+<para>
+
+You may have to change some settings or jumpers on your computer's
+peripheral cards.  Some cards have setup menus, while others rely on
+jumpers.  This document cannot hope to provide complete information on
+every hardware device; what it hopes to provide is useful tips.
+
+</para><para>
+
+If any cards provide <quote>mapped memory</quote>, the memory should be
+mapped somewhere between 0xA0000 and 0xFFFFF (from 640K to just below 1
+megabyte) or at an address at least 1 megabyte greater than the total
+amount of RAM in your system.
+
+</para>
+   </sect3>
+
+   <sect3 arch="i386" id="usb-keyboard-config">
+   <title>USB BIOS support and keyboards</title>
+<para>
+
+If you have no AT-style keyboard and only a USB model, you may need
+to enable legacy AT keyboard emulation in your BIOS setup. Only do this if
+the installation system fails to use your keyboard in USB mode. Conversely,
+for some systems (especially laptops) you may need to disable legacy USB
+support if your keyboard does not respond.
+Consult your main board manual and look in the BIOS for <quote>Legacy
+keyboard emulation</quote> or <quote>USB keyboard support</quote> options.
+
+</para>
+   </sect3>
+
+   <sect3><title>More than 64 MB RAM</title>
+<para>
+
+The Linux Kernel cannot always detect what amount of RAM you have.  If
+this is the case please look at <xref linkend="boot-parms"/>.
+
+</para>
+   </sect3>
+  </sect2>
+ </sect1>