Provided by:
manpages-pt_20040726-2_all 
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.)
‘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
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çõ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’.
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)