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.