Som redan nämnts tidigare finns det tyvärr ingen standard för fastprogramvara för system på ARM-system. Även beteendet hos olika system som använder nominellt samma fasta programvara kan vara ganska olika. Detta beror på att en stor del av enheterna som använder ARM-arkitekturen är inbyggda system, för vilka tillverkarna vanligtvis bygger kraftigt anpassade versioner av fastprogramvara för och inkluderar enhetsspecifika patchar. Tyvärr skickar tillverkarna ofta inte tillbaka sina ändringar och tillägg till de huvudsakliga utvecklarna av fastprogramvara, så deras ändringar är inte integrerade i nyare versioner av den ursprungliga fasta programvaran.

Som ett resultat använder även nysålda system ofta en fast programvara som är baserad på en år gammal tillverkarmodifierad version av en fast programvara vars mainlinekodbas har utvecklats mycket längre under tiden och erbjuder ytterligare funktioner eller visar olika beteende i vissa aspekter. Utöver det är namngivningen av inbyggda enheter inte konsekvent mellan olika tillverkarmodifierade versioner av samma fasta programvara, därför är det nästan omöjligt att tillhandahålla användbara produktoberoende instruktioner för ARM-baserade system.

Debian tillhandahåller U-Boot-avbilder för olika armhf-system som kan ladda sin U-Boot från ett SD-kort på .../images/u-boot/ . U-Boot-byggen erbjuds i två format: råa U-Boot-komponenter och en färdig kortavbild som enkelt kan skrivas in på ett SD-kort. De råa U-Boot-komponenterna tillhandahålls för avancerade användare; det allmänt rekommenderade sättet är att använda en av de färdiga SD-kortsavbilderna. De heter <system-type>.sdcard.img.gz och kan skrivas till ett SD-kort t.ex. med

zcat <system-type>.sdcard.img.gz > /dev/SD_CARD_DEVICE

Som med alla avbilder, tänk på att när du skriver avbilden till ett SD-kort raderas allt tidigare innehåll på kortet!

Om Debian tillhandahåller en U-Boot-avbildning för ditt system, rekommenderas att du använder den här avbilden istället för den leverantörslevererade U-Boot, eftersom versionen i Debian vanligtvis är nyare och har fler funktioner.

MAC-adressen för varje Ethernet-gränssnitt bör normalt vara globalt unik, och den måste tekniskt sett vara unik inom sin Ethernet-sändningsdomän. För att uppnå detta tilldelar tillverkaren vanligtvis ett block av MAC-adresser från en centralt administrerad pool (för vilken en avgift måste betalas) och förkonfigurerar en av dessa adresser på varje såld enhet.

När det gäller utvecklingskort vill tillverkaren ibland undvika att betala dessa avgifter och tillhandahåller därför inga globalt unika adresser. I dessa fall måste användarna själva definiera MAC-adresser för sina system. När ingen MAC-adress är definierad för ett Ethernet-gränssnitt genererar vissa nätverksdrivrutiner en slumpmässig MAC-adress som kan ändras vid varje uppstart, och om detta händer skulle nätverksåtkomst vara möjlig även när användaren inte har ställt in en adress manuellt, men t.ex. att tilldela semi-statiska IP-adresser med DHCP baserat på MAC-adressen för den begärande klienten skulle uppenbarligen inte fungera tillförlitligt.

För att undvika konflikter med befintliga officiellt tilldelade MAC-adresser finns det en adresspool som är reserverad för så kallade ”lokalt administrerade”-adresser. Den definieras av värdet av två specifika bitar i adressens första byte (artikeln ”MAC-adress” på engelska Wikipedia ger en bra förklaring). I praktiken innebär detta att t.ex. alla adresser som börjar med hexadecimal ca (som ca:ff:ee:12:34:56) kan användas som en lokalt administrerad adress.

På system som använder U-Boot som systemets fastaprogramvara, placeras Ethernet MAC-adressen i miljövariabeln ”ethaddr”. Det kan kontrolleras vid U-Boot kommandotolken med kommandot ”printenv ethaddr” och kan ställas in med kommandot ”setenv ethaddr ca:ff:ee:12:34:56” . Efter att ha ställt in värdet gör kommandot ”saveenv” tilldelningen permanent.

På vissa system med äldre U-Boot-versioner kan det uppstå problem med att korrekt flytta Linux-kärnan, den initiala ramdisken och enhetsträdet i minnet under uppstartsprocessen. I det här fallet visar U-Boot meddelandet ”Startar kärnan ...”, men systemet fryser efteråt utan ytterligare utmatning. Dessa problem har lösts med nyare U-Boot-versioner från v2014.07 och framåt.

Om systemet ursprungligen har använt en U-Boot-version äldre än v2014.07 och har uppgraderats till en nyare version senare, kan problemet fortfarande uppstå även efter att U-Boot har uppgraderats. Uppgradering av U-Boot ändrar vanligtvis inte de befintliga U-Boot-miljövariablerna och korrigeringen kräver att ytterligare en miljövariabel (bootm_size) ställs in, vilket U-Boot gör automatiskt endast på nya installationer utan befintlig miljödata. Det är möjligt att manuellt ställa in bootm_size till den nya U-Bootens standardvärde genom att köra kommandot ”env default bootm_size; saveenv” vid U-Boot-prompten.

En annan möjlighet att kringgå omlokaliseringsrelaterade problem är att köra kommandot ”setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” vid U-Boot-prompten för att helt inaktivera omlokaliseringen av den initiala ramdisken och enhetsträdet.