Handbook:MIPS/Blocks/Bootloader/pt-br

arcload para máquinas Silicon Graphics
O arcload foi criado para máquinas que requerem kernel de 64 bits e desse modo não podem usar o arcboot (que não pode ser facilmente compilado como um binário de 64 bits). Ele também contorna peculiaridades que aparecem ao se carregar o kernel diretamente do cabeçalho de volume. Vamos proceder com a instalação:

Depois de terminado, encontre o binário arcload em. Dois arquivos existem lá:
 * : O binário de 32 bits para sistemas Indy, Indigo2 (R4k), Challenge S e O2 systems
 * : O binário de 64 bits para sistemas Octane/Octane2, Origin 200/2000 e Indigo2 Impact

Use o  para instalar o binário apropriado para o sistema no volume de cabeçalho:

Para usuários Indy/Indigo2/Challenge S/O2:

Para usuários Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000:

Agora use o  para checar que estão no cabeçalho de volume:

O arquivo tem uma sintaxe parecida com C. Para detalhes completos sobre como o configurar, veja a página do arcload no wiki Linux/MIPS. Resumindo, defina algumas opções, que são habilitadas ou desabilitadas durante o boot usando a variável OSLoadFilename.

A partir do arcload-0.5, o arc.cf e os kernel podem residir ou no cabeçalho de volume ou em uma partição. Para utilizar esse novo recurso, coloque os arquivos na partição (ou  se a partição de boot não for separada). O arcload usa o código do driver do sistema de arquivos do popular gerenciador de boot grub e por isso suporta o mesmo conjunto de sistemas de arquivos.

Instalando o CoLo
Servidores Cobalt possuem um firmware muito mais limitado instalado no chip. A BOOTROM do Cobalt é primitiva em comparação com a PROM SGI e tem um número de sérias limitações.
 * Há um limite de 675kB (aproximadamente) para o kernel. O tamanho atual do Linux 2.4 torna quase impossível criar um kernel desse tamanho. O Linux 2.6 e 3.x estão totalmente fora de questão.
 * Kernel de 64 bits não são suportados pelo firmware de fábrica (são altamente experimentais em máquinas Cobalt atualmente)
 * O shell é no máximo bem básico

Para superar essas limitações, um firmware alternativo, chamado CoLo (Cobalt Loader) foi desenvolvido. Essa é uma imagem de BOOTROM que pode tanto ser gravada no chip dentro do servidor Cobalt, ou carregada a partir de um firmware existente.

Vamos agora instalar o CoLo. Primeiro, faça emerge do pacote.

Com isso instalado, dê uma olhada no diretório para encontrar dois arquivos:
 * (o "kernel" para o firmware de fábrica carregar) e
 * (uma imagem de ROM para ser gravada na BOOTPROM)

Começamos montando e colocando uma cópia compactada de  em, onde o sistema espera encontrá-la.

Configurando o CoLo
Quando o sistema der boot, ele irá carregar o CoLo que mostrará um menu no display LCD traseiro. A primeira opção (e default, que é assumida após cerca de 5 segundos) é dar boot no disco rígido. O sistema então tenta montar a primeira partição Linux que encontrar e executar o script default.colo. A sintaxe é documentada na documentação do CoLo (veja, onde X.YY é a versão instalada) e é muito simples.

Também é possível perguntar, por exemplo, qual kernel e configuração dar boot, com um limite de tempo default. A configuração abaixo faz exatamente isso, pergunta ao usuário qual kernel deseja dar boot e executa a imagem selecionada. vmlinux.gz.new e vmlinux.gz.working podem ser as imagens reais do kernel, ou apenas links simbólicos para imagens do kernel no disco. O argumento "50" especifica que ele deve prosseguir com a primeira opção ("working") após 5 segundos (50 décimos de segundo).

Veja a documentação em para maiores detalhes.

Configuração para console serial
OK, a instalação do Linux como está agora daria boot normalmente, mas assume que o usuário estará logado em um terminal físico. Em máquinas Cobalt isso é particularmente ruim - não existem terminais físicos.

Primeiro, usando um editor e abra o arquivo. Abaixo no arquivo, verifique o seguinte:

Primeiro, retire o sinal de comentário da linha c0. Por default, ela é configurada para usar uma taxa de bauds de terminal de 9600 bps. Nos servidores Cobalt ela pode ser trocada para 115200 para casar a taxa de bauds da BOOT PROM. Abaixo está como essa seção ficará. Em uma máquina sem monitor (servidores Cobalt, por ex.) recomendamos também por em comentário as linhas de terminais locais (c1 até c6) uma vez que elas têm o hábito de não se comportarem bem quando não podem abrir o.

Agora, por fim... temos que dizer ao sistema que a porta serial local pode ser confiada como um terminal seguro. O arquivo que precisamos alterar é o. Ele contém uma lista de terminais nos quais o sistema confia. Simplesmente acrescentamos duas linhas, permitindo que a linha serial seja usada para login do root.

Em outro momento, o Linux também chama a linha de /dev/tts/0 -- então a adicionamos também:

Setting generic PROM settings
With the bootloader installed, after rebooting (which we will come to in a second), go to the System Maintenance Menu and select Command Monitor (5) like did initially when netbooting the system.

Menu after boot

Provide the location of the Volume Header:

Automatically boot Gentoo:

Set the timezone:

Use the serial console - graphic adapter users should have "g" instead of "d1" (one):

Set the serial console baud rate. This is optional, 9600 is the default setting, although one may use rates up to 38400 if that is desired:

Now, the next settings depend on how the system is booted.

Settings for direct volume-header booting
Set the root device to Gentoo's root partition, such as :

To list the available kernels, type "ls".

Declare the kernel parameters to pass:

To try a kernel without messing with kernel parameters, use the boot -f PROM command:

Settings for arcload
arcload uses the OSLoadFilename option to specify which options to set from. The configuration file is essentially a script, with the top-level blocks defining boot images for different systems, and inside that, optional settings. Thus, setting OSLoadFilename=mysys(serial) pulls in the settings for the mysys block, then sets further options overridden in serial.

In the example file above, we have one system block defined, ip28 with working, new and debug options available. We define our PROM variables as so:

Select arcload as the bootloader:- sash64 or sashARCS:

Use the "working" kernel image, defined in "ip28" section of arc.cf:

Starting with arcload-0.5, files no longer need to be placed in the volume header -- they may be placed in a partition instead. To tell arcload where to look for its configuration file and kernels, one must set the OSLoadPartition PROM variable. The exact value here will depend on where the disk resides on the SCSI bus. Use the SystemPartition PROM variable as a guide -- only the partition number should need to change.

To load from the volume header -- use partition 8:

Otherwise, specify the partition and filesystem type: