Som allerede nævnt før, så er der uheldigvis ikke en standard for systemfirmware på ARM-systemer. Selv opførelsen på forskellige systemer, der normalt bruger den samme firmware kan være ret så forskellig. Dette kommer af, at en stor del af enhederne, der bruger ARM-arkitekturen er indlejrede systemer, hvortil producenten normalt bygget meget tilpasset firmwareversioner og inkluderer enhedsspecifikke rettelser. Desværre sender producenterne ikke deres ændringer og udvidelser tilbage til firmwareudviklerne, så deres ændirnger integreres ikke i nyere versioner af den oprindelige firmware.

Det medfører, at selv nye systemer ofte bruger en firmware, der er baseret på en gammel producentændret version af en firmware, hvis kodegrundlag har udviklet sig langt mere i mellemtiden og tilbyder yderligere funktioner eller har en anden opførsel under bestemte betingelser. Derudover er navngivningen af onboard-enheder ikke konsistent mellem forskellige producentændrede versioner af den samme firmware, så det er næsten umuligt at tilbyde brugbare produktuafhængige instruktioner for ARM-baserede systemer.

Debian tilbyder U-Boot-aftryk for diverse armhf-systemer, der kan indlæse deres U-Boot fra et SD-kort på .../images/u-boot/ . U-Boot-bygningerne tilbydes i to formater: rå U-Boot-komponenter og et på forhånd udarbejdet kortaftryk, der nemt kan skrives til et SD-kort. De rå U-Boot-komponenter tilbydes til de avancerede brugere; den generelt anbefalede måde er at bruge en af de på forhånd udarbejdede SD-kortaftryk. De er navngivet <system-type>.sdcard.img.gz og kan skrives til et kort f.eks. med

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

Som med alle aftryk, så vær opmærksom på at når du skriver aftrykket til et SD-kort, så fjernes alt indhold på kortet!

Hvis Debian tilbyder et U-Boot-aftryk til dit system, så anbefales det, at du bruger dette aftryk i stedet for den leverandørtilbudte U-Boot, da versionen i Debian normalt er nyere og har flere funktioner.

MAC-adressen for hver ethernetgrænseflade skal normalt være global unik, og den skal teknisk være unik indenfor sit ethernet broadcast-domæne. For at opnå dette, allokerer leverandøren normalt en blok af MAC-adresser fra en centralt administreret pulje (hvilket der skal betales et vederlag for) og forhåndskonfigurerer en af disse adresser på hvert solgt enhed.

I tilfældet med udviklingsbundkort ønsker producenten nogle gange at undgå betaling af disse gebyrer og tilbyder derfor ingen globale unikke adresser. I disse tilfælde skal brugeren selv definere MAC-adresser for deres systemer. Når ingen MAC-adresse er defineret for en ethernet-grænseflade, opretter nogle netværksdrivere en vilkårlig MAC-adresse, der kan ændre sig ved hver opstart, og hvis dette sker, vil netværksadgang være mulig, selv når brugere ikke manuelt har angivet en adresse, men f.eks. tildeling af semi-statiske IP-adresser fra DHCP baseret på MAC-adressen for den anmodende klient vil indlysende nok ikke fungere stabilt.

For at undgå konflikter med eksisterende officielt tildelte MAC-adresser, er der en adressepulje, der er reserveret for såkaldt “lokalt administrerede” adresser. Det er defineret af værdien for to specifikke bit i den første byte af adressen (artiklen “MAC address” i den engelske Wikipedia har en god forklaring). I praktisk betyder dette at f.eks. enhver adresse startende med hexadecimal ca (såsom ca:ff:ee:12:34:56) kan bruges som en lokalt administreret adresse.

På systemer der bruger U-Boot som systemfirmware, er ethernet MAC-adressen placeret i miljøvariablen “ethaddr”. Det kan kontrolleres via U-Boot-kommandoprompten med kommandoen “printenv ethaddr” og kan indstilles med kommandoen “setenv ethaddr ca:ff:ee:12:34:56”. Efter angivelse af værdien, gør kommandoen “saveenv” tildelingen permanent.

På nogle systemer med ældre U-Boot-versioner kan der være problemer med korrekt reallokering af Linuxkernen, den oprindelige ramdisk og enhedstræets blob i hukommelsen under opstartsprocessen. I dette tiflælde viser U-Boot beskeden “Starting kernel ...”, men systemet fryser efterfølgende uden yderligere resultat. Disse problemstillinger er blevet løst med nyere U-Boot-versioner fra version 2014.07 og fremad.

Hvis systemet oprindelig har brugt en U-Boot-version ældre end v2014.07 og aldrig er blevet opgraderet til en nyere version senere, så kan problemet fortsat være der efter opgradering af U-Boot. Opgradering af U-Boot ændrer normalt ikke det eksisterende U-Boot-miljøs variabler og rettelsen kræver at en yderligere miljøvariabel (bootm_size) indstilles, hvilket U-Boot kun gør automatisk på friske installationer uden eksisterende miljødata. Det er muligt manuelt at indstille bootm_size til den nye U-Boots standardværdi ved at afvikle kommandoen “env default bootm_size; saveenv” ved U-Boot-prompten.

En anden måde at omgå relokeringsproblemer er at køre kommandoen “setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” på U-Boot-prompten for helt at deaktivere relokeringen af den oprindelige ramdisk og enhedstræets blob.