Come già menzionato in precedenza, sui sistemi ARM non esiste un firmware standard, persino il comportamento di sistemi che nominalmente usano lo stesso firmware può essere abbastanza differente. Ciò dipende dal fatto che gran parte dei dispositivi che utilizzano l'architettura ARM sono sistemi embedded per i quali il produttori realizzano versioni del firmware pesantemente personalizzate con patch specifiche per il dispositivo. Purtroppo è molto raro che i produttori inviino le proprie modifiche a chi sviluppa il firmware originale e quindi le modifiche fatte dai produttori non sono integrate nelle nuove versioni ufficiali del firmware.

Di conseguenza persino i sistemi appena usciti sul mercato utilizzano del firmware basato su una versione vecchia e personalizzata dal produttore del firmware originale che nel frattempo è stato migliorato dagli sviluppatori: aggiungendo funzionalità o cambiandone alcuni aspetti. Inoltre, anche il nome dei dispositivi montati non è consistente tra le versioni modificate dai produttori dello stesso firmware e quindi per i sistemi ARM è impossibile fornire istruzioni d'uso indipendenti dal prodotto.

Debian distribuisce da .../images/u-boot/ delle immagini di U-Boot per i vari sistemi armhf in grado di caricare U-Boot da una scheda SD. Le immagini di U-Boot sono create in due formati: con i componenti in formato grezzo oppure in formato pronto per le schede, più facile da scrivere su schede SD. I componenti di U-Boot grezzi sono forniti per gli utenti più evoluti; in generale il metodo consigliato è usare una delle immagini pronte per le schede SD. Il nome delle immagini è <tipo-sistema>.sdcard.img.gz ed è possibile scriverle su una scheda con questo comando:

zcat <tipo-sistema>.sdcard.img.gz > /dev/DEVICE_SCHEDA_SD

Come per tutte le immagini, la scrittura dell'immagine sulla scheda SD sovrascrive completamente il contenuto della scheda!

Se è disponibile una immagine U-Boot per il proprio sistema, si raccomanda di usare quell'immagine al posto di U-Boot fornito dal produttore perché solitamente la versione Debian è più recente ed ha più funzionalità.

L'indirizzo MAC di ogni dispositivo Ethernet normalmente dovrebbe essere unico a livello mondiale e tecnicamente deve essere unico all'interno del dominio di broadcast ethernet. Per ottere questo risultato chi produce i dispositivi si fa assegnare un blocco di indirizzi MAC (e per questo paga una tassa) e assegna uno di questi indirizzi a ogni dispositivo.

Nel caso delle schede di sviluppo, alcuni produttori vogliono non pagare questa tassa e quindi forniscono dispositivi che non hanno un indirizzo MAC univoco. In questo caso devono essere gli utenti a definire gli indirizzi MAC dei propri sistemi. Quando non è definito un indirizzo MAC, alcuni driver di rete ne generano uno casuale che cambia a ogni riavvio, in questo caso l'accesso alla rete funziona anche senza che l'utente abbia impostato un indirizzo MAC ma, per esempio, l'assegnazione semi-statica di indirizzi IP su DHCP in base all'indirizzo MAC del client che fa la richiesta non funziona in modo affidabile.

Per evitare conflitti con gli indirizzi MAC assegnati ufficialmente, c'è un insieme di indirizzi che è riservato agli indirizzi «locally administered» (amministrati localmente). È definito dal valore di due bit del primo byte dell'indirizzo (l'articolo in lungua inglese «MAC Address» su Wikipedia dà una buona spiegazione). In pratica vuol dire che, per esempio, tutti gli indirizzi che iniziano con il valore esadecimale ca (come ca:ff:ee:12:34:56) può essere usato come un indirizzo amministrato localmente.

Per i sistemi che utilizzano U-Boot come firmware di sistema, l'indirizzo MAC ethernet è salvato nella variabile d'ambiente «ethaddr»; è possibile controllarne il valore dal prompt di U-Boot con il comando «printenv ethaddr» e può essere cambiato con il comando «setenv ethaddr ca:ff:ee:12:34:56». Dopo aver impostato il nuovo valore, usare il comando «saveenv» per rendere permanente la modifica.

È possibile che su alcuni sistemi con vecchie versioni di U-Boot si verifichino durante il processo d'avvio dei problemi con la rilocazione in memoria del kernel Linux, del ramdisk iniziale e del device-tree blob. In questo caso, U-Boot mostra il messaggio «Starting kernel ...» e poi il sistema si blocca senza altri messaggi. Questi problemi sono stati risolti nelle versioni di U-Boot successive alla v2014.07.

Questo problema potrebbe comunque verificarsi anche se il sistema era originariamente equipaggiato con una versione di U-Boot precedente alla v2014.07 e, in seguito, è stato aggiornato a una versione più recente. Infatti l'aggiornamento di U-Boot solitamente non modifica le variabili d'ambiente esistenti ma la correzione richiede l'impostazione della nuova variabile d'ambiente (bootm_size) che viene creata automaticamente solo sulle nuove installazioni quindi senza variabili d'ambiente esistenti. È possibile impostare manualmente bootm_size al suo valore predefinito eseguendo il comando «env default bootm_size; saveenv» dal promnpt di U-Boot.

Un'altra possibilità per prevenire problemi legati alla rilocazione è eseguire il comando «setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv» dal prompt di U-Boot per disattivare completamente la rilocazione del ramdisk iniziale e del device-tree blob.