Zoals reeds eerder aangegeven, bestaat er jammer genoeg geen standaard voor systeemfirmware op ARM-systemen. Zelfs verschillende systemen die nominaal dezelfde firmware gebruiken, kunnen zich heel verschillend gedragen. Dit komt door het feit dat een groot deel van de apparaten die van de ARM-architectuur gebruik maken, ingebedde systemen zijn waarvoor de fabrikanten sterk aangepaste firmwareversies maken met toevoeging van apparaatspecifieke aanpassingen. Jammer genoeg koppelen de fabrikanten deze aanpassingen en uitbreidingen niet terug naar de ontwikkelaars van de standaardfirmware, waardoor hun wijzigingen niet opgenomen geraken in de recentere versies van de originele firmware.

Het gevolg daarvan is dat zelfs nieuw verkochte systemen vaak gebruik maken van firmware die gebaseerd is op een jaren oude door de fabrikant gewijzigde versie van firmware waarvan de standaardcode intussen erg geëvolueerd is en bijkomende functionaliteit biedt en voor bepaalde aspecten een ander gedrag vertoont. Daarbij komt nog dat er tussen verschillende door de fabrikant gewijzigde versies van dezelfde firmware geen consistentie is in de naamgeving van boordapparatuur en daarom is het schier onmogelijk om bruikbare product-onafhankelijke instructies te geven voor op ARM gebaseerde systemen.

Debian levert U-Boot-images voor verschillende armhf-systemen die hun U-Boot kunnen laden vanaf een SD-kaart op .../images/u-boot/ . De U-Boot-compilaties worden in twee formaten aangeboden: rauwe U-Boot-componenten en een kant-en-klaar kaart-image dat gemakkelijk naar een SD-kaart geschreven kan worden. De rauwe U-Boot-componenten worden voor geoefende gebruikers ter beschikking gesteld. De algemeen aanbevolen werkwijze is om gebruik te maken van een van de kant-en-klare SD-kaart-images. Ze heten <systeem-type>.sdcard.img.gz en kunnen naar een kaart geschreven worden, bijvoorbeeld met de opdracht

zcat <systeem-type>.sdcard.img.gz > /dev/SD_KAART_APPARAAT

Denk eraan dat een image naar een SD-kaart schrijven alle eerdere inhoud van die kaart wist, zoals dat het geval is voor alle images.

Indien Debian voor uw systeem een U-Boot-image ter beschikking stelt, is het aangeraden om dit image te gebruiken in plaats van het door de leverancier geleverde U-Boot, vermits de versie in Debian meestal recenter is en meer functionaliteit biedt.

Normaal zou het MAC-adres van elke ethernet-interface wereldwijd uniek moeten zijn en het moet vanuit technisch oogpunt uniek zijn binnen zijn ethernet broadcast-domein. Om dit te bereiken reserveert de fabrikant gewoonlijk een blok MAC-adressen uit een centraal beheerde pool (waarvoor een prijs betaald moet worden) en stelt een van deze adressen vooraf in op elk verkocht exemplaar.

In het geval van ontwikkelingsborden wil de fabrikant deze kosten soms vermijden en geeft hij geen globaal uniek adres. In deze gevallen moet de gebruiker zelf een uniek MAC-adres definiëren voor zijn systeem. Als geen MAC-adres gedefinieerd werd voor een ethernet-interface, genereren sommige netwerkstuurprogramma's een willekeurig MAC-adres dat bij elke herstart anders kan zijn. In een dergelijk scenario is toegang tot het netwerk mogelijk, zelfs als de gebruiker niet handmatig een adres ingesteld heeft, maar bijvoorbeeld het toekennen van een semi-statisch IP-adres door DHCP op basis van het MAC-adres van de cliënt die daarom vraagt, zal om evidente redenen niet betrouwbaar kunnen gebeuren.

Om conflicten met officieel toegewezen MAC-adressen te vermijden, bestaat er een pool met adressen die voorbehouden is voor zogenaamde “lokaal beheerde” adressen. Die pool wordt gedefinieerd door de waarde van twee specifieke bits in de eerste byte van het adres (het artikel “MAC address” in de Engelstalige Wikipedia geeft een goede uitleg). In de praktijk betekent dit dat bijvoorbeeld elk adres dat met het hexadecimaal getal ca begint (zoals ca:ff:ee:12:34:56) gebruikt kan worden voor een lokaal beheerd adres.

Op systemen die U-Boot als systeemfirmware gebruiken, wordt het ethernet MAC-adres geplaatst in de omgevingsvariabele “ethaddr”. Het kan nagekeken worden aan de commandoregelprompt van U-Boot met het commando “printenv ethaddr” en het kan ingesteld worden met het commando “setenv ethaddr ca:ff:ee:12:34:56”. Nadat de waarde ingesteld werd, maakt het commando “saveenv” de toewijzing permanent.

Op sommige systemen met een oudere U-Boot-versie kunnen er zich tijdens het opstartproces problemen stellen met een juiste relocatie in het geheugen van de Linuxkernel, de initiële ramdisk en de blob met de apparatenboom. In een dergelijk geval toont U-Boot de melding “Starting kernel ...”, maar loopt het systeem nadien vast zonder verdere uitvoer te genereren. In recentere versies van U-Boot, te beginnen met v2014.07, zijn deze problemen opgelost.

Indien het systeem oorspronkelijk een versie van U-Boot gebruikte die ouder was dan v2014.07 en nadien opgewaardeerd werd naar een recentere versie, kan het probleem zich na de opwaardering van U-Boot nog steeds manifesteren. Het opwaarderen van U-Boot wijzigt over het algemeen niet de bestaande omgevingsvariabelen van U-boot en de reparatie vereist dat een bijkomende omgevingsvariabele (bootm_size) ingesteld wordt, hetgeen U-Boot enkel automatisch doet bij nieuwe installaties waar nog geen omgevingsdata bestaan. Men kan de variabele bootm_size handmatig instellen op de nieuwe standaard van U-Boot door het commando “env default bootm_size; saveenv” uit te voeren aan de prompt van U-Boot.

Een andere mogelijkheid om de relocatiegerelateerde problemen te omzeilen is om de relocatie van de initiële ramdisk en de blob met de apparatenboom volledig uit te schakelen door aan de prompt van U-Boot het commando “setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” in te geven.