Formati delle immagini d'avvio
Sulla maggior parte dei sistemi ARM è utilizzato uno tra questi due
formati per le immagini di avvio: a) kernel Linux standard
(vmlinuz
) insieme ai tradizionali ramdisk iniziali di
Linux (initrd.gz
) oppure b) kernel in formato uImage
insieme al suo ramdisk iniziale (uInitrd
).
uImage/uInitrd sono formati pensati per il firmware U-Boot, presente
su molti sistemi ARM. Le versioni di U-Boot più vecchie possono avviare
solo file nel formato uImage/uInitrd, quindi spesso sono usate sui
sistemi armel più vecchi. Le versioni di U-Boot più recenti sono in
grado di avviare ovviamente le immagini uImages/uInitrds ma riescono ad
avviare anche i kernel e i ramdisk in formato Linux, la sintassi del
comando per avviare le immagini in formato Linux è leggermente diversa
da quella del comando per avviare le immagini uImage.
Per i sistemi che usano un kernel multipiattaforma, oltre al kernel e
al ramdisk, è necessario anche un cosiddetto file con l'albero dei
dispositivi (device-tree oppure device-tree blob, dtb
).
Tale file è specifico per ciscun sistema e contiene la descrizione
dell'hardware.
Avvio con TFTP
&boot-installer-intro-net.xml;
Avvio da TFTP con U-Boot
L'avvio da rete per i sistemi che usano il firmware U-Boot consiste di
tre passi: a) configurazione della rete b) caricamento delle immagini
(kernel, ramdisk e dtb) in memoria c) l'esecuzione del codice appena
caricato.
Il primo passo è configurare la rete, automaticamente tramite DHCP con
setenv autoload no
dhcp
oppure manualmente impostando alcune variabili d'ambiente
setenv ipaddr <indirizzo ip del client>
setenv netmask <maschera di rete>
setenv serverip <indirizzo ip del server tftp>
setenv dnsip <indirizzo ip del nameserver>
setenv gatewayip <indirizzo ip del gateway predefinito>
È possibile salvare in modo permanente queste impostazioni eseguendo
saveenv
Dopodiche è necessario caricare le immagini (kernel, ramdisk iniziale
e dtb) in memoria. Per questa operazione occorre usare il comando
tftpboot passando l'indirizzo di memoria al quale deve deve caricata
l'immagine. Sfortunatamente la mappa di memoria varia da sistema a
sistema e non esiste una regola generale su quale indirizzo utilizzare.
Su alcuni sistemi, U-Boot predefinisce una serie di varibili d'ambiente
con gli indirizzi da usare: kernel_addr_r, ramdisk_addr_r e fdt_addr_r.
È possibile verificare se tali variabili sono state definite con
printenv kernel_addr_r ramdisk_addr_r fdt_addr_r
Se non sono state definite, è necessario trovare nella documentazione
i valori adatti al proprio sistema e impostarli manualmente. Per i
sistemi basati sui SOC Allwinner SunXi (per esempio per Allwinner A10
nome dell'architettura sun4i
, o Allwinner A20, nome
dell'architettura sun7i
) è possibile usare i seguenti
valori:
setenv kernel_addr_r 0x46000000
setenv fdt_addr_r 0x47000000
setenv ramdisk_addr_r 0x48000000
Dopo aver impostato gli indirizzi, è possibile caricare le immagini
in memoria dal server tftp definito in precedenza con
tftpboot ${kernel_addr_r} <nome file dell'immagine del kernel>
tftpboot ${fdt_addr_r} <nome file del dtb>
tftpboot ${ramdisk_addr_r} <nome file del ramdisk iniziale>
Il terzo passo è impostare la riga di comando per il kernel e avviare
l'esecuzione del codice appena caricato. U-boot passa il contenuto
della variabile d'ambiente bootargs
come riga di comando
al kernel, quindi tutti parametri per il kernel e per l'installatore,
come il device della console (vedere )
oppure le opzioni di preconfigurazione (vedere e ), possono
essere impostati con un comando simile a
setenv bootargs console=ttyS0,115200 rootwait panic=10
Il comando per eseguire il codice caricato in precedenza dipende dal
formato delle immagini usato. Con uImage/uInitrd, usare il comando
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
e con le immagini native Linux usare
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
Nota: quando si avviano immagini linux è importante caricare l'immagine
del ramdisk iniziale dopo il kernel e il dtb poiché U-Boot imposta il
valore della variabile filesize pari alla dimensione dell'ultimo file
caricato e il comando bootz ha bisogno di conoscere la dimensione
dell'immagine del ramdisk per funzionare correttamente. Per avviare un
kernel specifico per una piattaforma, vale a dire un kernel senza il
device-tree, è sufficiente omettere il parametro ${fdt_addr_r}.
Avvio da chiavetta USB in U-Boot
Molte delle versioni moderne di U-Boot hanno il supporto per USB e
permettono di fare l'avvio da dispositivi di memorizzazione di massa
USB come le chiavette USB. Sfortunatamente i passi esatti per fare
l'avvio variano leggermente da dispositivo a dispositivo.
In U-Boot v2014.10 sono stati introdotti una gestione comune della riga
di comando e l'infrastruttura autoboot. Ciò permette di creare immagini
d'avvio generiche che funzionano su qualsiasi sistema con tale framework.
Il &d-i; può fare l'installazione a partire da una chiavetta USB su tali
sistemi, purtroppo non tutte le piattaforme hanno già adottato questa
nuova infrastruttura.
Per creare una chiavetta USB con la quale installare &debian; occorre
prima scompattare l'archivio tar hd-media (consultare ) su una chiavetta USB formattata con uno dei
filesystem supportati dalla versione di U-Boot del proprio dispositivo
(le versioni più recenti di U-Boot suportano FAT16 / FAT32 / ext2 /
ext3 / ext4), poi copiare il file dell'immagine ISO del primo CD o DVD
d'installazione &debian; sulla chiavetta.
L'infrastruttura autoboot delle recenti versioni di U-Boot funziona in
modo similare alla opzione sull'ordine di avvio del BIOS dei PC, cioè
ricerca nell'elenco dei dispositivi da cui è possibile fare l'avvio il
primo che contiene un'immagine avviabile e la fa partire. Se non è
installato alcun sistema operativo, inserendo una chiavetta USB e
l'accensione del sistema dovrebbe comportare l'avvio dell'installatore.
È anche possibile iniziare il processo d'avvio da USB in qualsiasi
momento inserendo dal prompt di U-Boot il comando
run bootcmd_usb0
.
Un problema che può verificarsi durante l'avvio da una chiavetta USB
quando è collegata una console seriale è un disallineamento della
velocità di comunicazione. Se in U-Boot è definita la varibile console,
lo script di avvio del &d-i; ne passa automaticamente il valore al
kernel in modo da impostare il device della console primaria e, se
possibile, la velocità di trasmissione. Sfortunatamente la gestione
della variabile console varia da piattaforma a piattaforma: su alcune
la varibile contiene anche la velocità (come in
console=ttyS0,115200
), invece su altre la varibile
contiene solo il device (come in console=ttyS0
). In
quest'ultimo caso è possibile avere dell'output confuso sulla console
qual ora la velocità predefinita di U-Boot sia diversa da quella del
kernel. Le versioni recenti di U-Boot spesso utilizzano 115200 baud
mentre il kernel tutt'ora utilizza i tradizionali 9600 baud. In questo
caso è necessario impostare manualmente la varibile console in modo che
contenga anche la velocità di trasmissione adatta al sistema e avviare
l'installatore con il comando run bootcmd_usb0
.