Linux Manpages Online - man.cx manual pages

NOME

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

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.)

’ro’ e ’rw’
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.

’nosmp’ e ’maxcpus=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=N’ ou (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

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ções ’hd=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ção ’hd=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ção ’hd=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ção ’hd=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ção ’hd=nowerr’
Alguns drives aparentemente tem o WRERR_STAT um tanto imobilizado. Essa opção habilita um paliativo para esses dispositivos quebrados.

A opção ’hd=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 MicroSolutions ’backpack’
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’.

Manpages