Em sistemas baseados em ARM na maioria dos casos é utilizado um de dois formatos de imagens de arranque: a) kernels Linux standard de formato zImage (“vmlinuz”) em conjunto com os ramdisk iniciais standard de Linux (“initrd.gz”) ou b) kernels de formato uImage (“uImage”) em conjunto com os correspondentes ramdisks iniciais (“uInitrd”).
uImage/uInitrd são formatos de imagens desenhados para o firmware u-boot que é utilizado em muitos sistemas ARM. As versões mais antigas de u-boot apenas podem arrancar com o formato uImage/uInitrd, por isso estes são vulgarmente utilizados em sistemas armel antigos. As novas versões u-boot podem - além de arrancar uImages/uInitrds - também arrancar kernels Linux standard e imagens ramdisk, mas a sintaxe de comando para o fazer é ligeiramente diferente da para arrancar a partir de uImages.
Para sistemas que utilizem um kernel multi-plataforma, além do kernel e um ramdisk inicial, é necessário um chamado ficheiro device-tree, “dtb”. É especifico de cada sistema suportado e contém uma descrição do hardware próprio.
Arrancar pela rede requer que tenha uma ligação de rede e um servidor TFTP de arranque por rede (e provavelmente também um servidor de DHCP, RARP ou BOOTP para a configuração automática de rede).
A configuração do servidor para suportar arranque pela rede é descrita em Secção 4.3, “Preparar Ficheiros para Arrancar Através da Rede por TFTP”.
O arranque pela rede em sistemas que utilizam o firmware u-boot consiste em três passos: a) configurar a rede, b) carregar as imagens (kernel/ramdisk inicial/dtb) para a memória e c) efectivamente executar o código carregado.
Primeiro tem de configurar a rede, quer automaticamente por DHCP ou correndo
setenv autoload no dhcp
ou manualmente definindo várias variáveis de ambiente
setenv ipaddr <endereço ip do cliente> setenv netmask <máscara de rede> setenv serverip <endereço ip do servidor de tftp> setenv dnsip <endereço ip do servidor de nomes (dns)> setenv gatewayip <endereço ip da gateway predefinida>
saveenv
Depois tem de carregar as imagens (kernel/ramdisk inicial) para a memória. Isto é feito com o comando tftpboot, ao qual tem de ser passado o endereço a partir de onde é guardada na memória a imagem. Infelizmente o mapa de memória pode variar entre sistemas, por isso não há uma regra genérica com os endereços que possam ser utilizados para isto.
Em alguns sistemas, u-boot pré-define um conjunto de variáveis de ambiente com endereços de carregamento apropriados: kernel_addr_r, ramdisk_addr_r e fdt_addr_r. Pode verificar se estão definidos ao correr
printenv kernel_addr_r ramdisk_addr_r fdt_addr_r
Se não estiverem definidos, tem que verificar a documentação do seu sistema por valores apropriados e defini-los manualmente. Para sistemas baseados em Allwinner SunXi SOCs (e.g. o Allwinner A10, nome de arquitectura “sun4i” ou o Allwinner A20, nome de arquitectura “sun7i”), pode por exemplo utilizar os seguintes valores:
setenv kernel_addr_r 0x46000000 setenv fdt_addr_r 0x47000000 setenv ramdisk_addr_r 0x48000000
Quando estiverem definidos os endereços de carregamento, pode assim carregar as imagens para a memória a partir do servidor tftp anteriormente definido:
tftpboot ${kernel_addr_r} <nome de ficheiro da imagem do kernel> tftpboot ${fdt_addr_r} <nome de ficheiro de dtb> tftpboot ${ramdisk_addr_r} <nome de ficheiro da imagem inicial de ramdisk>
A terceira parte é definir a linha de comandos do kernel e executar o código carregado. U-boot passa o conteúdo da variável de ambiente “bootargs” como linha de comandos do kernel, por isso quaisquer parâmetros para o kernel e instalador - tais como dispositivo de consola (veja Secção 5.3.1, “Consola de arranque”) ou opções de preseeding (seja Secção 5.3.2, “Parâmetros de instalação Debian” e Apêndice B, Automatizar a instalação utilizando 'preseeding') - pode ser definido com um comando como
setenv bootargs console=ttyS0,115200 rootwait panic=10
O comando exato a executar o código carregado anteriormente depende do formato de imagem utilizado. Com uImage/uInitrd o comando é
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
e com imagens nativas de Linux é
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
Nota: Quando arrancar imagens standard de linux, é importante carregar a imagem ramdisk inicial após o kernel e o dtb já que u-boot define a variável de tamanho de ficheiro ao tamanho do último ficheiro carregado e o comando bootz necessita o tamanho da imagem ramdisk para funcionar correctamente. Em caso de arrancar um kernel específico da plataforma, i.e. um kernel sem device-tree, simplesmente omita o parâmetro ${fdt_addr_r}.
Many modern u-boot versions have USB support and allow booting from USB mass storage devices such as USB sticks. Unfortunately the exact steps required to do that can vary quite a bit from device to device.
U-Boot v2014.10 has introduced a common commandline handling and autoboot framework. This allows building generic boot images that work on any system implementing this framework. The debian-installer
supports installation from a USB stick on such systems, but unfortunately not all platforms have adopted this new framework yet.
To build a bootable USB stick for installing Debian, unpack the hd-media tarball (see Secção 4.2.1, “Onde Encontrar Imagens de Instalação”) onto a USB stick formatted with a filesystem supported by the u-boot version on your device. For modern u-boot versions, any of FAT16 / FAT32 / ext2 / ext3 / ext4 usually works. Then copy the ISO image file of the first Debian installation CD or DVD onto the stick.
The autoboot framework in modern u-boot versions works similar to the boot ordering options in a PC BIOS, i.e. it checks a list of possible boot devices for a valid boot image and starts the first one it finds. If there is no operating system installed, plugging in the USB stick and powering up the system should result in starting the installer. You can also initiate the USB-boot process any time from the u-boot prompt by entering the “run usb_boot” command.
One problem that can come up when booting from a USB stick while using a serial console can be a console baudrate mismatch. If a console variable is defined in u-boot, the debian-installer
boot script automatically passes it to the kernel to set the primary console device and, if applicable, the console baudrate. Unfortunately the handling of the console variable varies from platform to platform - on some platforms, the console variable includes the baudrate (as in “console=ttyS0,115200”), while on other platforms the console variable contains only the device (as in “console=ttyS0”). The latter case leads to a garbled console output when the default baudrate differs between u-boot and the kernel. Modern u-boot versions often use 115200 baud while the kernel still defaults to the traditional 9600 baud. If this happens, you should manually set the console variable to contain the correct baudrate for your system and then start the installer with the “run usb_boot” command.