1 files changed, 172 insertions, 0 deletions
diff --git a/eu/preparing/pre-install-bios-setup.xml b/eu/preparing/pre-install-bios-setup.xml
new file mode 100644
index 000000000..c4cdd6b7f
--- /dev/null
+++ b/eu/preparing/pre-install-bios-setup.xml
@@ -0,0 +1,172 @@
+<!-- retain these comments for translator revision tracking -->
+<!-- original version: 11648 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 ``firmware'' 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 ``mapped memory'', 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 keyboards</title>
+<para>
+
+If you have no AT-style keyboard and only a USB model, you will need
+to enable legacy AT keyboard emulation in your BIOS setup. Consult
+your main board manual and look in the BIOS for "Legacy keyboard
+emulation" or "USB keyboard support" options. It must be enabled in
+order to boot the installation system.  If you enabled this option and
+it is working for you, you are fine and can go ahead.
+
+</para><para>
+
+If you cannot find this option, it might be that it is always enabled
+and you can continue. It also might mean that the BIOS does not
+provide any emulation support (bad luck here).
+
+</para><para>
+
+If you find the option and enable it, but the emulation stops working
+soon after the kernel started, then you have bad luck too. You could
+try the "bf2.4" flavor where the root floppy brings USB modules. If
+you are installing with floppy disks, you would need the keyboard once
+before the USB modules can be loaded. Specifying the "keytimer" option
+at boot prompt may help in this case.
+
+</para><para>
+
+Sometimes, the emulation hangs but it wakes up after few minutes, so
+you could wait some time and try to continue. To fix this behavior,
+you could load Linux' own drivers for USB keyboards. For this, use
+"modconf" (Step "Configure Device Driver Modules") and load usb-uhci
+or usb-ohci modules.
+
+</para>
+   </sect3>
+
+   <sect3><title>More than 64 MB RAM</title>
+<para>
+
+The Linux Kernel can not always detect what amount of RAM you have.  If
+this is the case please look at <xref linkend="boot-parms"/>.
+
+</para>
+   </sect3>
+  </sect2>
+ </sect1>