Wie bereits vorher erwähnt, gibt es unglücklicherweise keinen Standard für System-Firmware auf ARM-Systemen. Sogar das Verhalten verschiedener Systeme, die nominal die gleiche Firmware verwenden, kann ziemlich unterschiedlich sein. Dies liegt an der Tatsache, dass ein großer Teil der Geräte, die die ARM-Architektur nutzen, eingebettete (embedded) Systeme sind, für die die Hersteller üblicherweise stark angepasste Firmware-Versionen erstellen und gerätespezifische Patches integrieren. Unglücklicherweise melden die Hersteller oft ihre Änderungen nicht zurück an die ursprünglichen Firmware-Entwickler, so dass die Änderungen nicht in neuere Versionen der Original-Firmware einfließen.

Als Ergebnis daraus verwenden sogar neu verkaufte Systeme oft eine Firmware, die auf einer mehrere Jahre alten, durch den Hersteller angepassten Version einer Firmware basiert, deren Original-Codebasis sich in der Zwischenzeit erheblich weiterentwickelt hat und zusätzliche Funktionalitäten enthält oder bei bestimmten Aspekten ein verändertes Verhalten zeigt. Zusätzlich dazu ist die Benamung von Onboard-Geräten nicht konsistent zwischen hersteller-modifizierten Versionen der gleichen Firmware, daher ist es nahezu unmöglich, nützliche geräteunabhängige Dokumentation für ARM-basierte Systeme bereitzustellen.

Die MAC-Adresse jeder Ethernet-Schnittstelle sollte eigentlich global eindeutig sein, und technisch muss sie innerhalb ihrer Ethernet-Broadcast-Domain eindeutig sein. Um dies zu erreichen, reserviert der Hersteller normalerweise einen Block von MAC-Adressen aus einem zentral administrierten Pool (für den eine Gebühr gezahlt werden muss) und vergibt dann eine dieser Adressen an jedes verkaufte Gerät.

Im Falle von Development-Boards wollen Hersteller manchmal die Zahlung der Gebühr vermeiden und stellen daher keine global eindeutigen Adressen bereit. In diesen Fällen muss der Benutzer selbst MAC-Adressen für seine Systeme vergeben. Wenn für eine Ethernet-Schnittstelle keine MAC-Adresse festgelegt ist, generieren einige Netzwerktreiber eine zufällige MAC-Adresse, die sich dann bei jedem Neustart ändern kann, und dabei wäre ein Netzwerkzugriff möglich, ohne dass der Benutzer händisch eine Adresse festgelegt hat; wenn jedoch z.B. die IP-Adressen über DHCP aus der MAC-Adresse des anfordernden Clients abgeleitet werden, würde dies natürlich nicht zuverlässig funktionieren.

Um Konflikte mit vorhandenen offiziell vergebenen MAC-Adressen zu vermeiden, gibt es einen Adress-Pool, der für sogenannte „lokal administrierte“ Adressen reserviert ist. Er wird über den Wert von zwei speziellen Bits im ersten Byte der Adresse definiert (der Artikel „MAC address“ in der englisch-sprachigen Wikipedia enthält hierzu eine gute Beschreibung). In der Praxis bedeutet dies, dass z.B. jede Adresse, die mit dem hexadezimalen Wert ca beginnt (wie ca:ff:ee:12:34:56), als lokal administrierte Adresse verwendet werden kann.

Auf Systemen, die U-Boot als System-Firmware nutzen, ist die Ethernet-MAC-Adresse in der Umgebungsvariablen „ethaddr“ abgelegt. Sie kann über den U-Boot-Befehlsprompt mit dem Befehl „printenv ethaddr“ überprüft und mit „setenv ethaddr ca:ff:ee:12:34:56“ gesetzt werden. Nach dem Ändern des Wertes wird mit dem Befehl „saveenv“ diese Einstellung fest abgespeichert.

Auf einigen Systemen mit älteren U-Boot-Versionen können Probleme bei der korrekten Speicherzuweisung für Linux-Kernel, Initial-Ramdisk und Gerätebaum-Abbild während des Boot-Prozesses auftreten. In diesem Fall zeigt U-Boot die Meldung „Starting kernel ...“ an, aber das System friert danach ohne weitere Ausgabe ein. Diese Probleme wurden in neueren U-Boot-Versionen ab v2014.07 aufwärts behoben.

Falls das System im Originalzustand eine U-Boot-Version älter als v2014.07 genutzt hat und dann auf eine neuere Version aktualisiert wurde, könnte das Problem auch nach dem Upgrade von U-Boot noch auftreten. Das Aktualisieren von U-Boot modifiziert üblicherweise nicht die vorhandenen Umgebungsvariablen und der Fix zur Fehlerbehebung erfordert das Setzen einer zusätzlichen Umgebungsvariable (bootm_size), was jedoch nur bei frischen Neuinstallationen ohne vorhandene Umgebungsdaten von U-Boot automatisch erledigt wird. Es ist möglich, bootm_size händisch auf den neuen U-Boot-Standardwert zu setzen, indem „env default bootm_size; saveenv“ am U-Boot-Prompt ausgeführt wird.

Eine andere Möglichkeit, solche Probleme bei Speicherzuweisungen zu verhindern, wäre die Ausführung von „setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv“ am U-Boot-Prompt; damit wird die dynamische Speicherzuweisung für Initial-Ramdisk und Gerätebaum-Abbild vollständig deaktiviert.