既に触れたように、残念ながら ARM システムのシステムファームウェアには標準となるものがありません。名義上同一のファームウェアを利用していても、システムが異なれば挙動はかなり異なることがあります。これは ARM アーキテクチャを採用している機器の大半が組み込みシステムであり、製造者は通常独自の変更を相当に加えたバージョンのファームウェアをビルドし、機器特有のパッチを収録しているという事実に起因します。残念ながら製造者が変更や拡張を主流側のファームウェア開発者に送らないことが多く、そのため製造者による変更が元のファームウェアの新しいバージョンにはなかなか取り入れられません。

結果として新しく販売されているシステムであっても、製造者により改変された1年以上古いバージョンのファームウェアを基にしたファームウェアを使っていることが多く、一方で主流側のコードはその間に大きく進化して追加の機能を提供していたり、ある面で異なる挙動を取るということがあります。それに加え、オンボードデバイスの命名方法は異なる製造者が改変したバージョン間では同一のファームウェアであっても一貫性がなく、そのためARMベースのシステムで製品に依存せずに利用できる命令を提供するのはほぼ不可能です。

Debian は .../images/u-boot/ で SDカードから U-Boot を読み込める 様々な armhf システム向けの U-Boot イメージを提供しています。U-Boot ビルドは2つの形式を提供しています: U-Boot の構成要素をそのまま収録したものと簡単にSDカードに書き込める既製のカードイメージです。U-Boot の構成要素をそのまま提供しているのは上級ユーザ向けです。通常は既製のSDカードイメージのどれかの利用を勧めています。これは <システム種類>.sdcard.img.gz といった名前で、例えば

zcat <システム種類>.sdcard.img.gz > /dev/SDカードのデバイス

のようにしてカードに書き込めます。どのイメージでも同じですが、イメージをSDカードに書き込むとそのカードにあった内容は消えてしまうことに留意してください!

当該システム用の U-Boot イメージが Debian から提供されている場合はベンダーから提供された U-Boot よりもそのイメージの使用を勧めます。通常 Debian 版の方が新しく多機能なためです。

通常、全イーサネットインターフェイスのMACアドレスが全体で一意であるべきで、技術的にはイーサネットブロードキャストドメイン内で一意でないといけません。それを実現するために製造者は通常、中央管理されている (対価を払う必要のある) MAC アドレスブロックを割り当てられ、そのアドレスの中から1つを、販売する各製品に事前設定します。

開発用ボードの場合、製造者が対価の支払いを避けたいために全体で一意なアドレスが提供されないこともあります。その場合はユーザ自身でシステムの MAC アドレスを決めないといけません。イーサネットインターフェイスの MAC アドレスが決められていない場合、ネットワークドライバによっては MAC アドレスを無作為に生成します。そうして生成された MAC アドレスはブートのたびに変わる可能性があり、変更が発生した場合、ユーザが手作業によりアドレスをセットしなくてもネットワークアクセスは可能でしょうが、例えばリクエストしたクライアントの MAC アドレスを基にして DHCP により半固定の IP アドレスを割り当てるような場合の動作に信頼性が失われるのは明らかです。

公式に割り当てられている既存の MAC アドレスとの競合を回避するため、いわゆる「ローカル管理用」アドレスとして予約されているアドレス領域があります。アドレスの第1バイトの特定の2ビットの値が決められています (英語版 Wikipedia の記事「MAC_address」に良い説明があります)。事実上これは例えば 16 進数 ca から始まる任意のアドレス (ca:ff:ee:12:34:56 等) をローカル管理用アドレスとして利用できるということになります。

システムのファームウェアとして U-Boot を使っているシステムでは、イーサネット MAC アドレスは「ethaddr」環境変数にセットされています。U-Boot のコマンドプロンプトでコマンド「printenv ethaddr」により確認、コマンド「setenv ethaddr ca:ff:ee:12:34:56」によりセットできます。値の設定後にコマンド「saveenv」を実行するとその割り当てが恒久的になります。

以前のバージョンの U-Boot を利用しているシステムの一部ではブートの過程で Linux カーネルや初期 RAM ディスク、デバイスツリー blob のメモリへの再配置に不具合がある可能性があります。その場合 U-Boot は「Starting kernel ...」というメッセージを表示しますがシステムはそれ以上出力することなくフリーズします。この問題は v2014.07 以降の新しいバージョンの U-Boot では解決されています。

システムが元々 v2014.07 よりも古いバージョンの U-Boot を利用していたもので後から新しいバージョンにアップグレードした場合、U-Boot のアップグレード後でも問題が引き続き発生するかもしれません。U-Boot のアップグレードでは通常既存の U-Boot 環境変数を変更せず、この問題の修正には追加の環境変数 (bootm_size) をセットする必要があり、既存の環境データの存在しない新規インストール処理でのみ U-Boot は自動的にそれをセットします。コマンド「env default bootm_size; saveenv」を U-Boot のプロンプトで手作業により実行することで U-Boot の新しいデフォルト値に bootm_size をセットできます。

再配置関連の問題を回避する別の策として、コマンド「setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv」を U-Boot プロンプトで実行して初期 RAM ディスク、デバイスツリー blob の再配置を完全に無効化する方法があります。