Provided by: manpages-pt_20040726-2_all bug

NOME

       bootparam  -  introdução  aos  parâmetros de inicialização do kernel do
       Linux

DESCRIÇÃO

       O kernel do Linux aceita  certas  ‘opções  de  linha  de  comandos’  ou
       ‘parâmetros  de  inicialização’ no momento em que é iniciado. Em geral,
       isso é usado para suprir o kernel com informação a respeito do hardware
       que  o  mesmo  pode  não  estar apto para determinar por si só, ou para
       prevenir/ignorar os valores que o kernel possa ter detectado  de  outra
       maneira.

       Quando  o kernel é carregado diretamente pelo BIOS (digamos, através de
       um disquete para o qual você tenha copiado um kernel usando "cp  zImage
       /dev/fd0"),  você não tem oportunidade de especificar nenhum parâmetro.
       Então, para tirar  proveito  dessa  possibilidade,  você  tem  de  usar
       software que seja capaz de aceitar os parâmetros, como LILO ou loadlin.
       Para alguns parâmetros pode-se também modificar a imagem do  kernel  em
       si, usando rdev, veja rdev(8) para mais detalhes.

       O programa LILO (LInux LOader), escrito por Werner Almesberger é o mais
       comumente usado. Ele é capaz de carregar diversos kernels e armazenar a
       informação de configuração em um arquivo de texto puro. (Veja lilo(8) e
       lilo.conf(5).)  LILO pode carregar DOS, OS/2, Linux, FreeBSD, UnixWare,
       etc., e é bastante flexível.

       O  outro  carregador  de  Linux comumente usado é o "Loadlin", que é um
       programa do DOS que tem a capacidade de carregar  um  kernel  de  Linux
       através  do  prompt do DOS (com argumentos de inicialização), assumindo
       que certos recursos estão disponíveis.  Isto é  bom  para  pessoas  que
       querem iniciar o Linux através do DOS.

       É  também  bastante  útil  se você possui algum hardware que depende do
       driver  de  DOS  fornecido  para  colocar  o  hardware  em  um   estado
       reconhecido.  Um  exemplo  comum  são as placas de som "compatíveis com
       SoundBlaster", que requerem o driver de DOS para mexer alguns registros
       místicos  para  colocar a placa em modo compatível com SB. Carregando o
       DOS com o driver fornecido e então carregando o Linux  pelo  prompt  do
       DOS evita o reset da placa, que ocorre quando se reinicia a máquina.

LISTA DE ARGUMENTOS

       A  linha  de  comando  do  kernel  é  analisada em uma lista de strings
       (argumentos de inicialização) separada por espaços.  Muitos  argumentos
       usam a forma:

              nome[=value_1][,value_2]...[,value_10]

       onde "nome" é uma palavra-chave única que é usada para identificar para
       qual parte do kernel os valores associados (se houver algum) devem  ser
       enviados.   Note  que  o  limite  de  10  é  real, uma vez que o código
       presente só é capaz de manipular 10 parâmetros  separados  por  vírgula
       por  palavra-chave.  (De  qualquer  forma, você pode reutilizar a mesma
       palavra-chave, com mais 10 parâmetros adicionais, em situações unusuais
       e complicadas, assumindo que a função do setup suporta isso.)

       A  maioria  das  opções  está  em linux/init/main.c. Primeiro, o kernel
       checa se o argumento é  um  dos  argumentos  especiais,  como  ‘root=’,
       ‘nfsroot=’,  ‘fsaddrs=’,  ‘ro’,  ‘rw’, ‘debug’ ou ‘init’. O significado
       desses argumentos está descrito abaixo.

       Então ele caminha por uma lista de funções de configuração (contidas no
       array  de  setup  de  inicialização)  para  verificar  se  a  string de
       argumento especificada (como ‘foo’) está associada com uma  uma  função
       de  setup (‘foo_setup()’) para um dispositivo em particular ou parte do
       kernel. Se você passou ao kernel a linha foo=3,4,5,6,  então  o  kernel
       procurará  na  array  de  setup de boot, para verificar se ‘foo’ estava
       registrado. Se estiver, então ele chamará a função  associada  a  ‘foo’
       (foo_setup())  e  manipulará os argumentos 3, 4, 5 e 6 como passados na
       linha comandos do kernel.

       Qualquer coisa da forma ’foo=bar’ que não for  aceita  como  função  de
       setup  como  descrito  acima, é então interpretado como uma variável de
       ambiente  a  ser  configurada.  Um   exemplo   (inútil?)   seria   usar
       ‘TERM=vt100’ como argumento de inicialização.

       Os  argumentos  restantes  que  não  são  usados  pelo  kernel  nem são
       interpretados  como  variáveis  de  ambiente,  são  então  passados  ao
       processo,  o qual usualmente é o programa init. O argumento mais comum,
       que é passado ao processo do init é a palavra ’single’, a qual  instrui
       init  a iniciar o computador em modo de usuário singular e não iniciará
       nunhum dos daemons usuais. Procure na man  page  pela  versão  do  init
       instalada em seu sistema para ver que argumentos ele aceita.

ARGUMENTOS GERAIS DE INICIALIZAÇÃO, DISPOSITIVOS NÃO ESPECÍFICOS

init=...’
       Configura o comando inicial a ser executado pelo kernel. Se não estiver
       presente, ou não puser ser  encontrado,  o  kernel  tentará  /etc/init,
       então  /bin/init, então /sbin/init, então /bin/sh e entrar em pânico se
       tudo isso falhar.

   ‘nfsaddrs=...’
       Configura o endereço  nfs  de  inicialização  para  string  dada.  Esse
       endereço de inicialização é usado no caso de inicialização por rede.

   ‘nfsroot=...’
       Configura  o nome de root do nfs para a string dada. Se esta string não
       começa  com  ‘/’  ou  ‘,’  ou  um  dígito,  então  será  prefixada  por
       ‘tftpboot/’.  Este  nome  de  root é usado em caso de inicialização por
       rede.

   ‘no387’
       (somente  quando  CONFIG_BUGi386  está  definido.)  Alguns   chips   de
       coprocessamento  do i387 apresentam bugs, que aparecem quando usados em
       modo protegido de 32 bits. Por  exemplo,  alguns  dos  primeiros  chips
       ULSI-387  causavam  travamentos  quando estavam lidando com cálculos de
       ponto flutuante. Usar o argumento ‘no387’ faz com que o Linux ignore  o
       co-processador  matemático  mesmo  que você possua um. É claro que você
       deve  então  ter  seu  kernel  compilado  com  suporte  a  emulação  de
       coprocessador!

   ‘no-hlt’
       (somente  quando  CONFIG_BUGi386  está definido.)  Alguns dos primeiros
       chips  i486DX-100  têm  problemas  com  a  instrução  ‘hlt’,  pois  não
       conseguem voltar com segurança para o modo operacional após o uso dessa
       instrução. Usar a instrução ‘no-hlt’ diz ao Linux para apenas rodar  um
       loop  infinito  quando  não  houver nada a ser feito e não parar a CPU.
       Isso permite às pessoas que têm esses chips defeituosos usarem Linux.

   ‘root=...’
       Este argumento diz  ao  kernel  que  dispositivo  será  utilizado  como
       sistema de arquivos raiz durante a carga. O padrão dessa configuração é
       determinado no  momento  da  compilação  e  usualmente  é  o  valor  do
       dispositivo  raiz onde o kernel foi construído. Para ignorar esse valor
       e selecionar o segundo drive de disquete como dispositivo raiz, pode-se
       usar ‘root=/dev/fd1’.(O dispositivo de root também pode ser configurado
       usando-se rdev(8).)

       O  dispositivo   raiz   pode   ser   especificado   simbolicamente   ou
       numericamente.  Uma especificação simbólica tem a forma /dev/XXYN, onde
       XX designa o tipo de dispositivo (‘hd’ para discos rígidos  compatíveis
       com ST-506, com Y entre ‘a’-‘d’; ‘sd’ para discos compatíveis com SCSI,
       com Y entre ‘a’-‘e’, ‘ad’ para discos ACSI atari com Y  entre  ‘a’-‘e’,
       ‘ez’  para drive paralelo removível Syquest EZ135, com Y=‘a’, ‘xd’ para
       discos compatíveis com XT, com Y sendo ‘a’ ou ‘b’; ‘fd’ para drives  de
       disquete,  onde  Y  é o número do drive de disquete - fd0 seria o drive
       ‘A:’ do DOS e fd1 seria o drive ‘B:’ do DOS, Y é a letra  do  drive  ou
       número  e  ‘N’  é  o  número  (em  decimal)  da partição do dispositivo
       (ausente no caso de  disquetes).  Os  kerneis  mais  recentes  permitem
       muitos  outros  tipos,  a  maioria  CDROMs: nfs, ram, scd, mcd, cdu535,
       aztcd, cm206cd, gscd, sbpcd, sonycd, bpcd.  (O tipo  nfs  especifica  o
       boot de rede; ram se refere a um ram disk.)

       Note que isto nada tem a ver com a designação desses dispositvos em seu
       sistema de arquivos. A parte ‘/dev’ é puramente convencional.

       A  especificação  numérica  mais  incômoda   e   menos   portável   dos
       dispositivos  de  root  possíveis acima em maior/menor formato também é
       aceita. (E.g., /dev/sda3 é maior 8 e menor  3,  então  você  pode  usar
       ‘root=0x803’ como uma alternativa.)

   ‘roerw’
       A  opção ‘ro’ diz ao kernel para montar o sistema de arquivos raiz como
       ‘somente  leitura’  (readonly),  para  que  programas  de  checagem  de
       consistência  de  sistemas de arquivos (fsck) possam fazer seu trabalho
       em um sistema de arquivos imóvel.  Nenhum processo  pode  escrever  nos
       arquivos  do  sistema  em questão, até que o mesmo seja ‘remontado’ com
       capacidade de ‘leitura/escrita (read/write), e.g., por ‘mount -w -n  -o
       remount /’. (veja também mount(8).)

       A   opção   ‘rw’  diz  ao  kernel  para  montar  o  sistema  raiz  como
       ‘escrita/leitura’.  Este é o padrão.

       A escolha  entre  somente-leitura  e  leitura/escrita  pode  ser  feita
       usando-se rdev(8).

   ‘reserve=...’
       Esta  é usada para proteger regiões de portas I/O de sondagens. A forma
       do comando é:

              reserve=iobase,extent[,iobase,extent]...

       Em algumas máquinas, pode ser  necessário  evitar  que  os  drivers  de
       dispositivo  procurem  os mesmos em regiões específicas (auto-probing).
       Isto pode ocorrer por causa de hardware que reage mal  à  detecção,  ou
       hardware que é erroneamente identificado ou meramente hardware que você
       não quer que o kernel inicialize.

       O argumento de linha de boot reserve especifica uma  região  de  portas
       E/S que não devem ser sondadas. Um driver de dispositivo não irá sondar
       uma  região  reservada,  a  não  ser  que  outro  argumento   de   boot
       explicitamente espefique para fazê-lo.

       Por exemplo, a linha de inicialização

              reserve=0x300,32 blah=0x300

       previne  todos  os  drivers  de  dispositivo, exceto o driver ‘blah’ da
       sondagem de 0x300-0x31f.

   ‘mem=...’
       A chamada do BIOS definida nas especificações  do  PC,  que  retorna  a
       quantidade  de  memória, foi desenhada para ser capaz de reportar até o
       máximo de 64MB. O Linux usa essa chamada da BIOS durante  o  boot  para
       determinar  quanta  memória está instalada. Se você tem mais de 64MB de
       RAM instalados, pode usar esse argumento de boot para  dizer  ao  Linux
       quanta  memória tem. O valor é decimal ou hexadecimal (prefixo 0x), e o
       sufixo ‘k’ (vezes 1024) ou ‘M’ (vezes 1048576) podem ser  usado.   Aqui
       está  uma  citação de Linus (Torvalds, criador do Linux), a respeito do
       uso do parâmetro ‘mem=’.

       ‘‘O kernel aceitará qualquer parâmetro ‘mem=xx’ que você lhe der  e  se
       acontecer  de  você mentir para ele, ele irá travar horrivelmente, cedo
       ou tarde.  O parâmetro indica o endereço de  RAM  alocável  mais  alto,
       então  ‘mem=0x1000000’  significa  que  você  tem  16MB de memória, por
       exemplo. Para uma máquina com 96MB ele será ‘mem=6000000’.

       NOTA NOTA NOTA: algumas máquinas podem usar o topo da memória para BIOS
       cacheing  ou  algo  assim,  então  você  pode  não  ter o total de 96MB
       endereçável. A recíproca  é  verdadeira:  alguns  chipsets  mapearão  a
       memória física que está coberta pela área do BIOS na área logo acima do
       topo da memória, então, o topo da memória pode  ser  realmente  96MB  +
       384kB,  por exemplo. Se você disser ao Linux que possui mais memória do
       que realmente tem, coisas ruins acontecerão: talvez não  imediatamente,
       mas certamente em algum momento.’’

   ‘panic=N’
       Por  padrão, o kernel não recarregará (reboot) após um pânico, mas esta
       opção causará o reboot do kernel, após N segundos (se N  >  0).   Estee
       timeout    de   pânico   pode   ser   configurado   por   "echo   N   >
       /proc/sys/kernel/panic"

   ‘reboot=[warm|cold][,[bios|hard]]’
       (somente quando CONFIG_BUGi386 estiver definido.)   Desde  o  2.0.22  o
       reboot  é  por  padrão  uma reinicialização fria (cold reboot).  Alguém
       pergunta pelo antigo padrão ‘reboot=warm’.  (Um ‘cold reboot’ pode  ser
       necessário  para  resetar  certos hardwares, mas pode destruir qualquer
       dado em cache de disco que não tenha sido escrito.  Uma reinicialização
       quente   (warm   boot)   pode   ser  mais  rápida).   Por  padrão,  uma
       reinicialização é difícil, requisitando-se que o controlador do teclado
       para pulsar o fluxo da linha de reset baixa, mas há ao menos um tipo de
       placa-mãe que não funcionará.  A  opção  ‘reboot=bios’,  ao  contrário,
       passará através do BIOS.

   ‘nosmpemaxcpus=N’
       (somente  quando  __SMP__  estiver  definido.)   Uma  opção de linha de
       comando de ‘nosmp’  ou  ‘maxcpus=0’  irá  desabilitar  completamente  a
       ativação  do  SMP  (simetrical  multi  processing - multi processamento
       simétrico); a opção ‘maxcpus=N’ limita o número máximo de CPUs ativadas
       no modo SMP em N.

ARGUMENTOS PARA USO DE DESENVOLVEDORES DE KERNEL

debug’
       As mensagens do kernel são enviadas ao demônio de log do kernel, klogd,
       então elas devem estar armazenadas em disco. Mensagens com a prioridade
       acima:  console_loglevel  são  também impressas no console. (Para estes
       níveis,  veja  <linux/kernel.h>.)   Por  padrão,  esta  variável   está
       configurada para catalogar qualquer coisa mais importante que mensagens
       de debug. Este argumento de inicialização diz ao kernel  para  imprimir
       também as mensagens de nível DEBUG.  O nível de log de console (console
       loglevel) configurado durante a  execução,  através  de  uma  opção  no
       klogd. Veja klogd(8).

   ‘profile=N’
       É  possível  habilitar  uma  função  de  profiling no kernel, se alguém
       desejar ver onde  o  kernel  está  gastando  seus  ciclos  de  CPU.   O
       profiling  pode  ser habilitado configurando a variável prof_shift para
       um valor que não zero.  Isto  pode  ser  feito  tanto  especificando-se
       CONFIG_PROFILE  durante  a  compilação, ou dando-se a opção ‘profile=’.
       Agora   o   valor   de   prof_shift   será   N,   quando    dado,    ou
       CONFIG_PROFILE_SHIFT,   quando   este   é  dado,  ou  2,  o  padrão.  A
       significância dessa varaiável é que  a  mesma  dá  a  granularidade  do
       profiling:  a  cada  pulso do clock, se o sistema estiever executando o
       kernel, um contador é incrementado:

              profile[address >> prof_shift]++;

       A informação  bruta  de  profiling  pode  ser  lida  em  /proc/profile.
       Provavelmente,  você  irá deseja usar uma ferramenta como readprofile.c
       para ordená-la.  Escrever em /proc/profiles limpará os contadores.

   ‘swap=N1,N2,N3,N4,N5,N6,N7,N8’
       Configura os oito parâmetros, max_page_age, page_advance, page_decline,
       page_initial_age,  age_cluster_fract,  age_cluster_min, pageout_weight,
       bufferout_weight, que  controlam  os  algoritmos  de  swap  do  kernel.
       Apenas para afinadores de kernel.

   ‘buff=N1,N2,N3,N4,N5,N6’
       Configura  os seis parâmetros max_buff_age, buff_advance, buff_decline,
       buff_initial_age, bufferout_weight,  buffermem_grace  que  controlam  o
       gerenciamento  de  buffers de memória do kernel. Apenas para afinadores
       de kernel.

ARGUMENTOS DE INICIALIZAÇÃO PARA USO DE DISCO DE RAM (RAMDISK)

       (apenas se o kernel foi compilado com CONFIG_BLK_DEV_RAM.)  Em geral  é
       uma  má idéia usar um disco de RAM (ramdisk) no Linux - o sistema usará
       a memória disponível de forma mais eficiente sozinho.   Mas  durante  a
       inicialização  (ou  criação de disquetes de boot) é frequentemente útil
       carregar o conteúdo do disquete em um disco de RAM. Alguém pode ter  um
       sistema  no  qual  seja  necessário que alguns módulos sejam carregados
       (para sistemas de arquivos ou hardware) antes  que  o  disco  principal
       possa ser acessado.

       No  Linux  1.3.48,  o  gerenciamento  de  ramdisk  mudou drasticamente.
       Anteriormente, a memória era alocada estaticamente e havia um parâmetro
       ‘ramdisk=N’  para  dizer seu tamanho. (isso pode também ser configurado
       na imagem do kernel durante a compilação ou pelo uso de  rdev(8).)   Os
       discos  de  RAM atuais usam o cache de buffer e aumentam dinamicamente.
       Para maior informação (e.g., como usar rdev(8) em combinação com o novo
       setup de ramdisk), veja /usr/src/linux/Documentation/ramdisk.txt.

       Existem quatro parâmetros, dois booleanos e dois inteiros.

   ‘load_ramdisk=N’
       Se  N=1,  carrega  um ramdisk. Se N=0, Não carrega um ramdisk (Este é o
       padrão.)

   ‘prompt_ramdisk=N’
       Se N=1, pede a inserção do disquete (Este é o padrão.).   Se  N=0,  não
       pede a inserção do disquete (assim, esse parâmetro nunca é necessário).

   ‘ramdisk_size=Nou (obsoleto)ramdisk=N’
       Configura o tamanho máximo do(s) ramdisk(s) para N kB. O padrão é  4096
       (4 MB).

   ‘ramdisk_start=N’
       Configura  o  número  do  bloco  inicial (a simetria no disquete onde o
       ramdisk começa) para N.  Isso é necessário no caso de o ramdisk  seguir
       uma imagem do kernel.

   ‘noinitrd’
       (somente   se   o   kernel   foi  compilado  com  CONFIG_BLK_DEV_RAM  e
       CONFIG_BLK_DEV_INITRD.)  Atualmente é possível compilar o  kernel  para
       usar initrd.  Quando esta característica está habilitada, o processo de
       inicialização carregará o kernel e um ramdisk inicial; então, o  kernel
       converte  initrd em um ramdisk "normal que é montado em leitura/escrita
       como dispositivo raiz; então, /linuxrc é executado; depois,  o  sistema
       de  arquivos  raiz  "real"  é  montado e o sistema de arquivos initrd é
       movido para /initrd; finalmente, a sequência de inicialização  usual  é
       executada (e.g. chamada de /sbin/init.

       Para  uma  descrição  detalhada  das  caracteríticas  de  initrd,  veja
       /usr/src/linux/Documentation/initrd.txt

       A opção ‘noinitrd’ diz ao kernel, que embora tenha sido compilado  para
       operar  com initrd, que não deve executar os passos acima, e sim deixar
       os dados do initrd em /etc/initrd.  (esse dispositivo  pode  ser  usado
       apenas uma vez -- os dados são liberados tão logo o último processo que
       o utilizou houver fechado /etc/initrd.)

ARGUMENTOS DE BOOT PARA DISPOSITIVOS SCSI

       Notação geral para esta seção:

       iobase -- a primeira porta I/O  que  a  controladora  SCSI  ocupa.  São
       especificados  em notação hexadecimal e usualmente encontram-se na área
       de 0x200 a 0x3ff.

       irq -- a interrupção de hardware em que a placa está  configurada  para
       usar.   Valores  válidos  dependerão  da  placa  em  questão, mas serão
       usualmente 5, 7, 9, 10, 11, 12 e 15. Os outros valores são  normalmente
       utilizados  por  periféricos comuns, como discos rígidos IDE, drives de
       disquete, portas seriais, etc.

       scsi-id -- a identidade que a adaptadora usa para se autoidentificar no
       bus  SCSI.  Algumas poucas adaptadoras permitem que você modifique este
       valor, mas a  maioria  tem-no  permanentemente  especificado  de  forma
       interna.  O  padrão  usual  é 7, mas as placas Seagate e Domain TMC-950
       usam 6.

       parity  --  se  a  controladora  SCSI  deve  esperar  os   dispositivos
       conectados  para  fornecer  um  valor  de  paridade  com  toda troca de
       informação. Especificando um "um", indica que a  checagem  de  paridade
       está  habilitada  e  um  "zero"  desabilita  a  checagem  de  paridade.
       Novamente, nem todas as adaptadoras suportam a seleção de paridade como
       um argumento de inicialização.

   ‘max_scsi_luns=...’
       Um  dispositivo  SCSI  deve  possuir  um  número  de  ‘subdispositivos’
       contidos em si. O exemplo mais comum é um desses novos CD-ROMS SCSI que
       podem  manipular mais de um disco por vez. Cada CD está endereçado como
       um ‘Número de Unidade Lógica’ (Logical  Unit  Number  --  LUN)  daquele
       dispositivo  em particular. Mas a maioria dos dispositivos, como discos
       rígidos, drives de fita e outros são  apenas  um  dispositivo  e  serão
       designado por LUN zero.

       Alguns   dispositivos  SCSI  pobremente  projetados  não  suportam  ser
       testados para LUNs não iguais a zero. Por isso, se a flag de compilação
       CONFIG_SCSI_MULTI_LUN  não  estiver configurada, os novos kernels irão,
       por padrão, testar apenas LUN zero.

       Para especificar o número de LUNs  provados  durante  a  inicialização,
       pode-se  entrar ‘max_scsi_luns=n’ como um argumento de boot, onde ‘n’ é
       um número entre um e oito. Para evitar os  problemas  descritos  acima,
       pode-se   usar  n=1  para  evitar  transtornos  bem  como  dispositivos
       quebrados.

   Configuração de Drives de Fita SCSI
       Algumas configurações de inicialização do driver de fita SCSI pode  ser
       alcançadas usando-se o seguinte:

              st=buf_size[,write_treshold[,max_bufs]]

       Os  dois  primeiros  números  são  especificados  em  unidades de kB. O
       buf_size padrão é 32kB e o tamanho máximo que pode ser especificado são
       ridículos 16384kB. O write_treshold
        é o valor no qual o buffer é enviado à fita, com valor padrão de 30kB.
       O número máximo de buffers varia com o número de drivers  detectados  e
       possui o padrão de dois.  Um exemplo de uso seria:

       Maiores detalhes podem ser encontrados no arquivo README.st que fica no
       diretório SCSI da árvore de fontes do kernel.

   Configuração de Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI
       Os números ’aha’ referem-se a placas e os números ’aic’  referem-se  ao
       chip  SCSI real nesse tipo de placas, incluindo a Soundblaster-16 SCSI.

       O código de prova para estas controladoras SCSI procuram por  uma  BIOS
       instalada  e,  se nenhum estiver presente, a verificação não encontrará
       sua placa. Então, você terá de usar um argumento de boot na forma:

              aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]]

       Se o driver foi compilado com debugging habilitado, um sexto valor pode
       ser adicionado para especificar o nível de debug.

       Todos  os parâmetros são como descritos no início desta seção e o valor
       reconnect permitirá ao dispositivo desconectar/conectar se um um  valor
       não-zero for usado. Um exemplo de uso:

              aha152x=0x340,11,7,1

       Note  que  os parâmetros devem ser especificados na ordem, significando
       que se você quiser especificar um valor  de  paridade,  então  terá  de
       especificar os valores de io-base, irq, scsi-id e reconnect também.

   Configuração de Adaptec aha154x
       As  placas  da  série  aha1542 têm um controlador de drive de disquetes
       i82077 onboard, enquanto as da série aha1540 não têm. Essas são  placas
       de  busmastering,  e  possuem parâmetros para configurar a ‘‘lealdade’’
       que será usada para compartilhar o barramento com outros  dispositivos.
       O argumento de inicialização parece-se com o seguinte:

              aha1542=iobase[,buson,busoff[,dmaspeed]]

       Valores  válidos  de  iobase  são  usualmente  um dos seguintes: 0x130,
       0x134, 0x230, 0x234, 0x330, 0x334. Placas clones podem permitir valores
       diferentes.

       Os  valores  buson, busoff referem-se ao número de microssegundos que a
       placa dominará o barramento ISA. Os padrões são  11us  on  e  4us  off,
       então as outras placas (tal como uma placa de rede ISA LANCE) terão uma
       chance de acessar o barramento ISA.

       O valor  dmaspeed  refere-se  à  taxa  (em  MB/s)  em  que  ocorre  a
       transferência de DMA (Acesso Direto à Memória -- Direct Memory Access).
       O padrão é 5MB/s.  Placas de  revisão  mais  recente  permitem  a  você
       escolher  selecionar  esse  valor  como  parte  de uma configuração via
       software. As mais antigas usam jumpers. Você pode  usar  esses  valores
       até  10MB/s,  assumindo  que sua placa-mãe seja capaz de manipular essa
       taxa.  Experimente, com cuidado, usar valores acima de 5MB/s.

   Configuração de Adaptec aha274x, aha284x, aic7xxx
       Essas placas aceitam argumentos na forma:

              aic7xxx=extended,no_reset

       O valor extended , se não-zero, indica que a  tradução  estendida  para
       discos  grandes está habilitada. O valor no_reset , se não-zero, diz ao
       driver para  não  ressetar  o  barramento  SCSI  enquanto  configura  a
       adaptadora durante a inicialização.

   Configuração de controladoras SCSI AdvanSys (advansys=)
       O  driver AdvanSys aceita até 4 endereços de i/o que serão checados por
       uma placa SCSI AdvanSys. Note que esses valores (se usados) não  afetam
       verificação  em  EISA  ou  PCI.  São  apenas usados para verificação de
       placas ISA e VLB. A mais, se  o  driver  foi  compilado  com  debugging
       habilitado,  a  saída  do  nível  de  debugging  pode  ser  configurado
       adicionando-se um parâmetro 0xdeb[0-f]. O ’0-f’ permite a  configuração
       do  nível  de  mensagens de debugging para qualquer um dos 16 níveis de
       verbosidade.

   AM53C974
              AM53C974=host-scsi-id,target-scsi-id,max-rate,max-offset

   Configuração de adaptadoras SCSI BusLogic (BusLogic=)
              BusLogic=N1,N2,N3,N4,N5,S1,S2,...

       Para uma discussão mais ampla dos parâmetros de linha  de  comandos  da
       BusLogic, veja /usr/src/linux/drivers/scsi/BusLogic.c (linhas 3149-3270
       na versão do kernel que estou examinando). O texto abaixo é um  extrato
       muito resumido.

       Os  parâmetros  N1-N5  são completos. Os parâmetros S1,... são strings.
       N1 é o endereço de E/S no qual a adaptadora SCSI está localizada.  N2 é
       o  Tagged  Queue  Depth  (profundidade  da fila entre tags) para uso em
       dispositivos alvo que suportem Tagged Queuing.  N3 é o Bus Settle  Time
       (tempo  de  acomodação do barramaento) em segundos. Esta é a quantidade
       de tempo a ser aguardado entre um reset da controladora  que  inicia  o
       reset  do  barramento  SCSI e a emissão de comandos SCSI.  N4 é o Local
       Options (opções locais)  (para  uma  controladora.).   N5  é  o  Global
       Options (opções globais) (para todas as controladoras.).

       As  opções de strings são usadas para dar controle sobre Tagged Queuing
       (TQ:Default, TQ:Enable, TQ:Disable, TQ:<Per-Target-Spec>), sobre  Error
       Recovery    (recuperação    de    erro    (ER:Default,    ER:HardReset,
       ER:BusDeviceReset, ER:None, ER:<Per-Target-Spec>) e sobre Host  Adapter
       Probing  (verficação de controladora) (NoProbe, NoProbeISA, NoSortPCI).

   Configuração de EATA/DMA
       A lista padrão de portas i/o a serem verificadaspodem  ser  modificadas
       por:

              eata=iobase,iobase,....

   Configuração de Future Domain TMC-16x0
              fdomain=iobase,irq[,adapter_id]

   Configuração de controladora SCSI Great Valley Products (GPV)
              gvp11=dma_transfer_bitmask

   Configuração de Future Domain TMC-8xx, TMC-950
              tmc8xx=mem_base,irq

       O  valor  mem_base  é  o valor da região I/O mapeada pela memória que a
       placa usa.  Ele  será  um  dos  seguintes  valores:  0xc8000,  0xca000,
       0xcc000, 0xce000, 0xdc000, 0xde000.

   Configuração de IN2000
              in2000=S

       Onde S é uma string separada de itens ’palavra-chave[:valor]’ separados
       por vírgula. Palavras chaves  reconhecidas  (possivelmente  com  valor)
       são:  ioport:addr, noreset, nosync:x, period:ns, disconnect:x, debug:x,
       proc:x.     Para     as     funções     desses     parâmetros,     veja
       /usr/src/linux/drivers/scsi/in2000.c.

   Configuração de NCR5380 e NCR53C400
       A forma do argumento de inicialização é:

              ncr5380=iobase,irq,dma

       ou

              ncr53c400=iobase,irq

       Se  a  placa  não  usa  interrupções,  um  valor  de  IRQ de 255 (0xff)
       desabilitará interrupções. Um IRQ 254 significa  autoverificação.  Mais
       detalhes           podem           ser          encontrados          em
       /usr/src/linux/drivers/scsi/README.g_NCR5380.

       "Configuração de NCR53C8xx"

              ncr53c8xx=S

       onde S é  uma  string  de  itens  ’palavra-chave:valor’  separados  por
       vírgula.   Palavras-chaves  reconhecidas:  mpar  (master_parity),  spar
       (scsi_parity), disc (disconnection),  specf  (special_features),  ultra
       (ultra_scsi),   fsn   (force_sync_nego),   tags   (default_tags),  sync
       (default_sync), verb  (vberbose),  debug  (debug),  burst  (burst_max).
       Para      a      função      dos      valores     assinalados,     veja
       /usr/src/linux/drivers/scsi/ncr53c8xx.c.

   Configuração de NCR53c406c
              ncr53c406a=iobas[,irq[,fastpio]]

       Especifique irq = 0 para modo de drivers  sem  interrupção.   Configure
       fastpio = 1 para modo pio rápido, 0 para modo lento.

   Configuração de IOMEGA PPA3
              ppa=iobase[,speed_high[,speed_low[,nybble]]]

       Aqui ’iobase’ é o endereço da porta paralela (padrão 0x378), (padrão 6)
       e ’nybble’  é  uma  booleana   ‘force  nybble  (4-bit)  mode)’  (padrão
       0=false).  Veja também /usr/src/linux/driversscsi/README.ppa.

   Configuração de Pro Audio Spectrum
       O  PAS-16  usa  um  chip  SCSI  NC5380 e modelos mais recentes suportam
       configuração sem jumpers. A forma do argumento de inicialização é:

              pas16=iobase,irq

       A única diferença é que se você puder especificar um valor de IRQ  255,
       que  dirá  ao driver para trabalhar no modo sem interrupção, embora com
       perda de performance. A iobase padrão é usualmente 0x388.

   Configuração de Seagate ST-0x
       Se sua placa não for detectada na  inicialização,  você  terá  de  usar
       argumentos de boot, na forma:

              st0x=mem_base,irq

       O  valor  mem_base  é o valor da região I/O mapeada pela memória, que a
       placa usa. Ele será  usualmente  um  dos  valores  seguintes:  0xc8000,
       0xxca000, 0xcc000, 0xce000, 0xcd000, 0xde000.

   Configuração de Trantor T128
       Estas  placas são também baseadas no chip NCR5380 e aceita as seguintes
       opções:

              t128=mem_base,irq

       Os valoes válidos para mem_base são  os  seguintes:  0xcc000,  0xc8000,
       0xdc000, 0xd8000.

   Configuração de UltraStor 14F/34F
       A  lista padrão de portas i/o a serem verificadas podem ser modificadas
       por:

              eata=iobase,iobase,....

   Configuração de WD7000
              wd7000=irq,dma,iobase

   Configuração de controladora SCSI Commodore Amiga A2091/509
              wd33c93=S

       Onde  S  é  uma  string  de  opções  separadas  por   vírgula.   Opções
       reconhecidas  são:  nosync:bitmask,  nodma:x,  period:ns, disconnect:x,
       debug:x,      clock:x,      next.       Para       detalhes,       veja
       /usr/src/linux/drivers/scsi/wd33c93.c

DISCOS RÍGIDOS

   Parâmetros do driver de disco/CDROM IDE
       O  driver IDE aceita vários parâmetros, que variam de especificações da
       geometria do disco para suporte de chips  de  controladoras  quebrados.
       Opções  específicas  do drive são especificadas usando-se ‘hdX’ com ‘X’
       entre ‘a’-‘h’.

       Outras opções não específicas de drive, são especificadas com o prefixo
       ‘hd=’.  Note  que  usando um prefixo específico de drive para uma opção
       não específica de drive continuará funcionando e a opção será  aplicada
       como esperado.

       Note  também  que ‘hd=’ pode ser usado para referir-se ao próximo drive
       não  especificado  na  sequência  (a,  ...,  h).  Para  as   discussões
       seguintes,  a  opção  ‘hd=’  será  citada  brevemente.  Veja  o arquivo
       README.ide em linux/drivers/block para maiores detalhes.

   As opçõeshd=cyls,heads,sects[,wpcom[,irq]]’
       Essas opções são usadas para especificar a geometria física  do  disco.
       Apenas  os  três  primeiros  valores  são  requeridos.  Os  valores  de
       cilindros/cabeças/setores serão aqueles utilizados pelo fdisk. O  valor
       de pre-compensação de escrita é ignorado nos discos IDE. O valor do IRQ
       especificado será o IRQ utilizado pela interface na qual o drive reside
       e não um parâmetro específico de drive.

   A opçãohd=serialize’
       O chip de interface dual IDE CMD-640 é quebrado em seu próprio projeto,
       pois quando os drives da interface secundária são usados ao mesmo tempo
       que os drives da interface primária, isto corromperá seus dados. Usando
       esta opção, diz-se ao driver para assegurar-se que as interfaces  nunca
       serão usadas ao mesmo tempo.

   A opçãohd=dtc2278’
       Esta opção diz ao driver que você possui uma interface IDE DTC-2278D. O
       driver então tenta executar operações DTC específicas para habilitar  a
       segunda interface e habilitar modos de transferência mais velozes.

   A opçãohd=noprobe’
       Não há verificação do drive especificado. Por exemplo:

              hdb=noprobe hdb=1166,7,17

       desabilitará a verificação, mas continuará especificando a geometria do
       drive, para que possa ser  registrado  como  um  bloco  de  dispositivo
       válido e, conseqüentemente, utilizável.

   A opçãohd=nowerr’
       Alguns  drives  aparentemente  tem  o  WRERR_STAT um tanto imobilizado.
       Essa opção habilita um paliativo para esses dispositivos quebrados.

   A opçãohd=cdrom’
       Isso diz ao driver IDE que há um CD-ROM compatível com ATAPI  conectado
       no  lugar  de  um  disco rígido IDE normal. Em muitos casos, o CD-ROM é
       identificado automaticamente, mas se não for, esta opção pode ajudar.

   Opções do driver de disco standard ST-506 (hd=)
       O driver de disco standard aceita argumentos  de  geometria  de  discos
       similares  ao driver IDE. Note, contudo, que ele só espera três valores
       (C/H/S) -- algum  mais  ou  algum  menos  e  o  driver  irá  ignorar-te
       silenciosamente.  Além  disso,  só  aceita  ‘hd=’  como argumento, i.e.
       ‘hda=’ e outros não são válidos aqui. O formato é o seguinte:

              hd=cyls,heads,sects

       Se houver dois discos instalados, o acima é repetido com os  parâmetros
       da geometria do segundo disco.

   Opções do driver de disco XT (xd=)
       Se  você  for  desafortunado  o suficiente para estar usando uma dessas
       velhas placas de 8 bits que movem dados a gritantes 125kB/s, então aqui
       está  a  solução.  Se a placa não for reconhecida, você terá de usar um
       argumento de boot, na forma:

              xd=type,irq,iobase,dma_chan

       O valor ’type’ especifica o fabricante da placa em particular, conforme
       segue: 0=genérica; 1=DTC; 2,3,4=Western Digital, 5,6,7=Seagate; 8=OMTI.
       A única diferença entre múltiplos tipos de  um  mesmo  fabricante  é  a
       string  do   BIOS usados na detecção, que não são utilizados se o valor
       ’type’ estiver especificado.

       A função ’xd_setup()’ não checa os valores e assume que você inseriu os
       quatro  valores.  Não a desaponte. Aqui está um exemplo de uso para uma
       controladora WD1002  com  o  BIOS  removido/desabilitado,  usando-se  o
       parâmetro ‘padrão’ da controladora XT:

              xd=2,5,0x320,3

   Discos removíveis Syquest EZ*
              ez=iobase[,irq[,rep[,nybble]]]

   DISPOSITIVOS IBM DE BARRAMENTO MCA
       Veja também /usr/src/linux/Documentation/mca.txt.

   Discos rígidos PS/2 ESDI
       É   possível   especificar   a   geometria   desejada   no  momento  da
       inicialização:

              ed=cyls,heads,sectors

       Para um Thinkpad-720, adicione a opção:

              tp720=1

   Configuração de subsistema SCSI Microchannel IBM
              ibmmcascsi=N

       onde ’N’ é o pun (SCSI ID) do subsistema.

CD-ROMS (não-SCSI/ATAPI/IDE)

   Interface Aztech
       A sintaxe para esse tipo de placa é:

              aztcd= iobase,[,magic_number]

       Se você configurar o ’magic_number’ para 0x79, então o driver tentará e
       rodará  de  qualquer  forma,  no  caso  de  uma  versão desconhecida de
       ’firmware’. Os outros valores são ignorados.

   CD-ROM MicroSolutionsbackpack’
       Sintaxe:

              bpcd=iobase

   Interface Sony CDU-31A e CDU-33A
       Esta interface de CD-ROM é encontrada em  algumas  placas  de  som  Pro
       Audio  Spectrum  e  outras  placas  fornecidas pela Sony. A sintaxe é a
       seguinte:

              cdu31a=iobase,[,irq[,is_pas_card]]

       Especificando um valor de IRQ 0, diz-se ao driver que  interrupções  de
       hardware  não são suportadas (como em algumas placas PAS). Se sua placa
       suporta interrupções, você deve  usá-las,  pois  as  mesmas  reduzem  a
       utilização de CPU pelo driver.

       O  parâmetro  is_pas_card  deve  ser inserido como ’PAS’, se se estiver
       usando uma placa Pro Audio Spectrum  e,  em  outra  circunstância,  não
       deverá ser especificado.

   Interface Sony CDU-535
       A sintaxe para essa interface de CD-ROM é:

              sonycd535=iobase[,irq]

       Um  ’zero’ pode ser utilizado como valor de base I/O como um ‘possuidor
       de lugar’ se alguém desejar especificar um valor de IRQ.

   Interface GoldStar
       A sintaxe para essa interface de CD-ROM é:

              gscd=iobase

   Interface de CD-ROM ISP-16
       Sintaxe:

              isp16=[iobase[,irq[,dma[,type]]]]

       (três inteiros e uma string). Se ’type’  for  dado  como  ‘noisp16’,  a
       interface não será configurada. Outros tipos reconhecidos são: ‘Sanyo’,
       ‘Sony’, ‘Panasonic’ e ‘Mitsumi’.

   A interface padrão Mitsumi
       A sintaxe para essa interface de CD-ROM é:

              mcd=iobase,[,irq[,wait_value]]

       O valor wait_value é utilizado como um valor de timeout  interno,  para
       quem  esteja  tendo  problemas  com  seus  drive  e  pode  ou  não  ser
       implementado, dependendo de um  ’#define’  da  compilação.   O  Mitsumi
       FX400 é um leitor de CD-ROM IDE/ATAPI e não usa o driver ’mcd’.

   Interface Mitsumi XA/Multisession
       Isto é para o mesmo hardware acima, mas o driver possui características
       adicionais.  Sintaxe:

              mcdx=iobase[,irq]

   Interface Optics Storage
       A sintaxe para esse tipo de placa é:

              optcd=iobase

   Interface Phillips CM206
       A sintaxe para esse tipo de placa é:

              cm206=[iobase][,irq]

       O driver assume que números entre 3 e  11  são  valores  de  IRQ  e  os
       números  entre 0x300 e 0x370 são portas I/O, então você pode especiicar
       um ou ambos os números, em qualquer ordem.  Também  é  aceita  a  forma
       ‘cm206=auto’, para habilitar autoverificação.

   Interface Sanyo
       A sintaxe para esse tipo de placa é:

              sjcd=iobase[,irq[,dma_channel]]

   Interface SoundBlaster Pro
       A sintaxe para esse tipo de placa é:

              sbpcd=iobase,type

       onde   ’type’   é   um   das   seguintes  strings  (sensível  a  caixa)
       ‘SoundBlaster’, ‘LaserMate’ ou ‘SPEA’. A base I/O é aquela da interface
       do CD-ROM, não a da parte de som da placa.

DISPOSITIVOS ETHERNET

       Drivers diversos usam argumentos diversos, mas todos eles, ao menos, se
       parecem, usando um IRQ, um valor base de porta I/O e um  nome.  Em  sua
       forma mais genérica, se parece com o que segue:

              ether=irq,iobase[,param_1[,...param_8]],name

       O  primeiro  argumento não numérico é entendido como o nome. Os valores
       de tipo de placa/driver. Valores  ’param_n’  típicos  são  usados  para
       especificar  coisas  como endereço de memória compartilhada, seleção de
       interface, canal de DMA e coisas assim.

       O uso mais comum desse parâmetro é forçar a verificação  da  existência
       de  uma  segunda  placa de rede, pois o padrão é ’procurar’ apenas uma.
       Isso pode ser executado com um simples:

              ether=0,0,eth1

       Note que os valores de zero para os  valores  de  IRQ  e  base  I/O  no
       exemplo acima, diz ao driver para executar autoverificação.

       O   ’Ethernet-HOWTO’  possui  extensa  documentação  sopbre  como  usar
       múltiplas placas e sobre a implementação  específica  de  ’param_n’  de
       placas/drivers,    onde   utilizados.   Leitores   interessados   devem
       encaminhar-se a seção daquele  documento  referente  especificamente  à
       suas placas.

DRIVER DE LEITOR DE DISQUETE

       Há  muitas  opções  de  drivers  de  leitores de disquete e estão todos
       listados em README.fd,  em  linux/drivers/block.  Esta  informação  foi
       tirada diretamente de tal arquivo.

   floppy=mask,allowed_drive_mask
       Configura o ’bitmask’ de drives permitidos para ’drives permitidos para
       mask’. Por padrão, apenas as unidades 0 e 1  de  cada  controladora  de
       disquetes  são  permitidos.  Isso  ocorre  porque  certos hardwares não
       padrão (placas-mães ASUS PCI) ’bagunçam’ o teclado  quando  acessam  as
       unidades  2 ou 3. Essa opção está um tanto defasada pela opção de cmos.

   floppy=all_drives
       Configura o ’bitmask’ de drives permitidos para ’todos os drives’.  Use
       se você possuir mais de dois drives conectados a uma controladora.

   floppy=asus_pci
       Configura  o ’bitmask’ para permitir apenas as unidades 0 e 1 (padrão).

   floppy=daring
       Diz ao driver de disquete que você possui uma controladora de disquetes
       bem  comportada.  Permite  operação mais eficiente e uniforme, mas pode
       falhar em certas controladoras. Pode também aumentar  a  velocidade  de
       certas operações.

   floppy=0,daring
       Diz ao driver que sua controladora deve ser usada com cuidado.

   floppy=one_fdc
       Diz  ao  driver  que  você  possui  apenas uma controladora de disquete
       (padrão).

   floppy=two_fdc ou floppy=address,two_fdc
       Diz ao driver de disquete  que  tem  duas  controladoras  de  disquete.
       Assume-se  que  a  segunda  controladora  está  endereçada.  Se  nenhum
       endereço for inserido, 0x370 será adotado.

   floppy=thinkpad
       Diz ao driver de disquete que você possui um ’Thinkpad’. Os ’Thinkpads’
       usam uma convensão inversa para a linha de troca de discos.

   floppy=o,thinkpad
       Diz ao driver de disquete que você não possui um ’Thinkpad’.

   floppy=drive,type,cmos
       Configura  o  tipo  de  drive do CMOS para ’type’. Adicionalmente, esse
       drive é permitido no ’bitmask’. Isso é útil se você tem  mais  de  dois
       drives  de  disquetes  (apenas dois podem ser descritos no CMOS físico)
       ou, se seu BIOS usa tipos de CMOS não padrão. Configurando o CMOS  para
       ’0’  para  os  dois  primeiros drives (padrão), faz com que o driver de
       disquete leia o CMOS físico para esses drives.

   floppy=unexpected_interrupts
       Exibe uma  mensagem  de  aviso  quando  uma  interrupção  inesperada  é
       recebida (funcionamento padrão).

   floppy=no_unexpected_interrupts ou floppy=L40SX
       Não  exibe  mensagens  de  aviso  quando  uma  interrupção inesperada é
       recebida. Isso é necessário em laptops IBM L40SX  em  certos  modos  de
       vídeo.  (Parece que há uma relação entre o vídeo e o drive de disquete.
       As interrupções inesperadas afetam apenas  o  desempenho  e  podem  ser
       seguramente ignoradas.)

DRIVER DE SOM

       O  driver  de  som pode também aceitar argumentos de inicialização para
       ignorar os valores compilados internamente.  Isso  não  é  recomendado,
       pois  é  um pouco complexo. Isto é descrito no arquivo Readme.Linux, em
       linux/drivers/sound. Aceita um argumento de inicialização na forma:

              sound=device1[,device2[,device3...[,device10]]]

       onde cada valor ’deviceN’ é um dos seguintes, no formato ’0xTaaaId’,  e
       usados como segue:

       T  -  tipo  de dispositivo: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
       7=SB16-MPU401

       aaa - endereço I/O em hexa.

       I - linha de interrupção em hexa (i.e. 10=a, 11=b, ...).

       d - canal de DMA.

       Como você pode ver, tudo fica bastante complicado, e é melhor  compilar
       seus   próprios  valores  como  recomendado.  Usando  um  argumento  de
       inicialização ‘sound=0’ desabilitará o driver de som inteiramente.

DRIVERS DE ISDN

   Driver de ISDN ICN
       Sintaxe:

              icn=iobase,membase,icn_id1,icn_id2

       onde ’icn_id1,icn_id2’ são duas strings utilizadas para  identificar  a
       placa nas mensagens do kernel.

   Driver ISDN PCBIT
       Sintaxe:

              pcbit=membase1,irq1[,membase2,irq2]

       onde  ’membaseN’ é a base de memória compartilhada da enésima placa e e
       membase 0xD0000.

   Driver ISDN Teles
       Sintaxe:

              teles=iobase,irq,membase,protocol,teles_id

       onde ’iobase’ é o endereço  da  porta  i/o  da  placa,  ’membase’  é  o
       endereço  da  memória  compartilhada  da  placa,  ’irq’  é  o  canal da
       interrupção que a placa usa e ’teles_id’ é uma string de  identificação
       ASCII única.

DRIVERS DE PORTAS SERIAIS

   Driver serial multiportas RISCom/8
       Sintaxe:

              riscom=iobase1[,iobase2[,iobase3[,iobase4]]]]

       Mais        detalhes        podem        ser       encontrados       em
       /usr/src/linux/Documentation/riscom8.txt.

   Driver DigiBoard (digi=)
       Se esta opção for usada, deverá  possuir  exatamente  seis  parâmetros.
       Sintaxe:

              digi=status,type,altpin,numports,iobase,membase

       Os  parâmetros  devem  ser  inseridos como inteiros ou como strings. Se
       forem usadas strings, então ’iobase’ e ’membase’  devem  ser  inseridos
       como hexadecimal.  Os argumentos inteiros (poucos, mas devem ser dados)
       são, em ordem: status (Habilitar(1) ou Deabilitar(0) esta placa),  type
       (PC/Xi(0),  PC/Xe(1),  PC/Xeve(2),  PC/Xem(3)), altpin (Habilitar(1) ou
       Desabilitar(0) alternação da disposição da pinagem),  numports  (número
       de  portas  na  placa), iobase (porta I/O onde a placa está configurada
       (em HEXA)), membase (base da janela de memória (em HEXA)).   Assim,  os
       seguintes argumentos do prompt de inicialização são equivalentes:

              digi=E,PC/Xi,D,16,200,D0000
              digi=1,0,0,16,0x200,851968

       Mais        detalhes        podem        ser       encontrados       em
       /usr/src/linux/Documentation/digiboard.txt.

   Radio modem serial/paralelo Baycom
       Sintaxe:

              baycom=iobase,irq,modem

       Aqui estão exatamente três  parâmetros:  para  algumas  placas,  insira
       alguns  comandos  ‘baycom=’.  O parâmetro ’modem’ é uma string que pode
       ter um dos valores ’ser12’, ’ser12*’, ’par96’, ’par96*’.  Aqui,  o  ’*’
       denota  que  o  DCD  de  software deve ser usado, e Para mais detalhes,
       veja: /usr/src/linux/drivers/net/README.baycom.

   Driver de placa de som/radio modem
       Sintaxe:

              soundmodem=iobase,irq,dma[,dma2[,serio[,pario]]],0,mode

       Todos os parâmetros, exceto o  último,  são  inteiros;  o  tolo  ’0’  é
       necessário  por conta de um bug no código de configuração.  O parâmetro
       ’mode’ é uma string com sintaxe ’hw:modem’, onde ’hw’é um entre  ’sbc’,
       ’wss’, ’wssfdx’ e ’modem’ é um entre

DRIVER DE LINHA DE IMPRESSORA

lp=’
       Em  kernels  mais  recentes  que  1.3.75,  você pode dizer ao driver da
       impressora que portas usar e quais portas não usar. O  mais  recente  é
       mais  prático,  se  você  não  quer que o driver de impressora exigindo
       todas as portas paralelas disponíveis, pois assim outros drivers  (e.g.
       PLIP, PPA) podem usá-las.

       O  formato do argumento é multiple i/o, IRQ pairs. Por exemplo, usará o
       IRQ 7 para a porta 0x378. A porta em ’0x278’ (se houver uma)  não  será
       verificada,  uma  vez que a autoverificação só ocorre na ausência de um
       argumento ‘lp=’. Para desabilitar o driver de impressora completamente,
       pode-se usar ‘lp=0’.

   Driver de WDT500/501
       Sintaxe:

              wdt=io,irq

DRIVERS DE MOUSE

       O  driver  do  busmouse aceita apenas um parâmetro, que será o valor do
       IRQ a ser usado pelo hardware.

   ‘msmouse=irq’
       E exatamente o mesmo para o driver do msmouse.

   Configuração do mouse ATARI
       atamouse=threshold,[,y-threshold]

              Se apenas um argumento for dado, ele será usado tanto  para  ’x-
              threshold’   quanto  para  ’y-threshold’.  Se  não,  o  primeiro
              argumento é ’x-threshold’  e  o  segundo  ’y-threshold’.   Estes
              valores devem estar entre 1 e 20 (inclusive); o padrão é ’2’.

HARDWARE DE VÍDEO

no-scroll’
       Esta  opção  diz  ao  driver  do console para não utilizar a rolagem de
       hardware (onde uma rolagem é efetuada movendo-se a origem  da  tela  da
       memória  de  vídeo,  ao  invés de mover os dados). Isso é necessário em
       algumas máquinas Braille.

AUTORES

       Linus Torvalds (e outros)

VEJA TAMBÉM

       klogd(8), lilo.conf(5), lilo(8), mount(8), rdev(8).

       Grande parte dessa página de  manual  é  derivada  do  "Boot  Parameter
       HOWTO" (versão 1.0.1), escrito por Paul Gortmaker.  Algumas informações
       adicionais podem ser encontradas nesse (ou em uma versão mais  recente)
       HOWTO.

TRADUZIDO POR LDP-BR EM 03/08/2000.

       Valter ’Geddy’ Ferraz S. <geddy@lawyer.com> (tradução) André L. Fassone
       Canova <lonelywolf@blv.com.br> (revisão)