diff options
Diffstat (limited to 'ca/preparing/pre-install-bios-setup.xml')
-rw-r--r-- | ca/preparing/pre-install-bios-setup.xml | 151 |
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> |