3.6. インストール前に行うハードウェア・OS の設定

この節では、Debian のインストールに先立って必要となるハードウェアの設定について見ていきます。通常この作業では、システムの BIOS/システム用ファームウェアの設定をチェックし、場合によってはその設定を変更することになります。BIOSシステムファームウェアは、ハードウェアが利用する中核的なソフトウェアで、電源投入後のブートプロセスの間に起動される、最も重要なものです。

3.6.1. ARM ファームウェア

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

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

3.6.2. U-Boot でのイーサネット MAC アドレスの設定

通常、全イーサネットインターフェイスの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を実行するとその割り当てが恒久的になります。

3.6.3. U-Boot でのカーネル/initrd/デバイスツリーの再配置問題

以前のバージョンの 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 の再配置を完全に無効化する方法があります。