世界を動かす技術を、日本語で。

プレブート環境におけるPoE+電力の交渉

概要

  • 2015年、PoE給電対応のx86組込PCとデジタルサイネージシステム開発プロジェクト
  • 標準PoE(802.3af)の電力上限を超える要件に直面
  • OS起動前にLLDPパケット送信でPoE+交渉を実現する必要性
  • UEFIアプリケーションによる独自解決策「PoePwrNegotiator」を開発
  • オープンソース公開とプロジェクトの意義共有

PoE給電x86組込PC開発の課題と背景

  • Windows 10 Professional 搭載の Intel Atom 組込PC・デジタルサイネージ機器の開発
  • PoE(Power over Ethernet)で AC電源工事不要化 を目指す設計思想
  • 一般的なIoT機器より 高い消費電力 (23W)要件
  • 標準PoE(802.3af)は 最大15.4W、PoE+(802.3at)は 最大30W
  • 一部クライアント環境では PoE+非対応スイッチ が障壁

PoE規格と電力要件の整理

  • IEEE 802.3af(PoE) :最大15.4W(PSE)、12.95W(PD)、2ペア、2003年制定
  • IEEE 802.3at(PoE+) :最大30W(PSE)、25.5W(PD)、2ペア、2009年制定
  • 当該機器は 最小18W 必要、PoE+必須

LLDPによる電力交渉問題

  • 組込システムは 物理層クラス分け のみ対応、LLDP(データリンク層)未対応
  • PoE+電力供給には LLDPパケット 送信が必要なスイッチも存在
  • OS起動前に 十分な電力供給が受けられず、Windows起動途中でシャットダウン
  • OSが起動しないとLLDP送信できない ジレンマ

UEFIアプリケーションによる解決アプローチ

  • UEFIファームウェア はOS不要で TCP/IP通信 可能
  • UEFIアプリケーション でLLDPパケット送信を試みる方針
  • BIOS/UEFIカスタム開発は ベンダー協力得られず 断念
  • UEFIアプリ はEFI System Partition(ESP)に格納し、OS前に起動可能
  • ネットワーク・ファイルシステム・I/Oデバイスへの 低レベルアクセス が可能

実装と技術的工夫

  • Piotr Król (元Intel BIOSエンジニア)に開発依頼
  • リモート開発環境 (シリアル/IP-KVM)で作業
  • 標準UEFIツール(bcfg)が使えず、 startup.nshスクリプト による自動実行を採用
  • 4ヶ月で PoePwrNegotiator (C言語製UEFIアプリ)完成
  • LLDP-MEDパケット 送信でPoE+電力交渉をOS不要で実現
  • 全PoEデバイスへ展開し 安定稼働 を確認

オープンソース公開と意義

  • PoePwrNegotiatorMITライセンス でGitHub公開
    • リポジトリ: https://github.com/orbitrod/PoePwrNegotiator
  • PoE給電x86システム開発者への 情報共有・再利用促進
  • UEFIアプリケーション によるネットワーク制御事例のドキュメント化
  • 商用・個人問わず 無償利用・改変・統合 が可能

特別謝辞とプロジェクトの教訓

  • Carlos :テスト・展開の右腕として多大な貢献
  • Piotr Król :ファームウェア分野の深い専門知識と実装力に感謝
  • 本プロジェクトは「 制約を乗り越える創意工夫」の重要性を再認識
  • PoePwrNegotiatorの経験やアプローチが PoEシステム設計の参考 となることを期待

Hackerたちの意見

PoEスタンダードの概要(IEEE 802.3)ちなみに、802.3btは2022年にリリースされたよ。 * https://en.wikipedia.org/wiki/Power_over_Ethernet 接続の遠端で最大71Wまで供給できるんだ。

UARTスタンダードはビットレートを指定してなかったから、1960年代の300bpsから90年代の10Mbps以上までスケールできたんだ。なんでPoEスタンダードも同じことができないの?単に標準で電圧や電流の制限を設けず、エンドポイントデバイスに自分たちの能力をアピールさせればいいんだよ。

2018年に最終決定され、2020年には主要ベンダーから商業提供がありました。私たちが2018年に802.3bt製品を開発したので、これを知っています。

面白いね。俺だったら、CPUのクロックを下げてOSをブートしてみるかな。そうすれば、なんとかなるかもしれない。著者のアプローチよりは理想的じゃないけど。

インテルのAtomプロセッサを使ってるけど[...]これらはフル機能のx86コンピュータで、標準のPoE(802.3af)が供給できる以上の電力が必要だったんだ。多分、サーバー用のAtomか、実際にはそれほど低消費電力じゃない後期モデルだね。俺が知ってるやつは10W以下だし。

10WのTDP CPUを持ってるかもしれないけど、システム全体も電力が必要だからね。

OSがブートする前にPoE+の電力交渉を解決するのは次のレベルだね。これはいいアイデアだし、賢い回避策だ。

逆だと思っていました。ネットワークハードウェアでPoE+交渉を行うのが第一段階で、OSに委任するのが次のレベルだと思います。

周辺機器を調べて、追加の電力が必要かどうかを判断して、UEFI内でリクエストするのって面白くない?

需要が変動する場合はどうなるの?

これはすごいね。俺だったら、みんなが使ってるデファクトスタンダードのパッシブPoEを使ってたと思う。誰かが問題に真正面から取り組んでるのを見るのはいいね。

関連する問題は、USB-PDで電源を供給するシングルボードコンピュータです。USB-PDのソースは、シンクが5秒以内に電力供給交渉を行わないと、電源を切ったり、変なことをしたりします。USB-PDの交渉はLinuxで処理されるので、Linuxがブートする頃には手遅れになっていて、電源供給が切れてしまい、ブートループに陥ります。解決策として、U-bootブートローダーの段階でUSB-PDの交渉を行うという方法が、この記事と非常に似ています。

面白いですね、シェアしてくれてありがとう。「薄型」USB-CコントローラがPDハンドシェイクを別のところに委任する進化を見逃していました。OSのドライバがその役割を担って、電源供給にどれだけの電力を供給するかを伝えるというのがどう感じるか、まだ分かりません。必ずしも新しいセキュリティの懸念ではないですが、一般のB2Cカスタマーサービスの観点からは悪夢のような話です(例えば、ブート中にシステムがシャットダウンしてマザーボードが壊れるなど)。

スレッドを読んでいると、動作は電源供給に依存しているようです。私はPinePower PSUを使ってUSB-C経由でPinebook Proに電源を供給しましたが、その時はOSにFUSB302ドライバすら入れていませんでした(今は追加中です)。他のボードはUSB-PDを全く使わず、5Vにデフォルト設定されたUSB-Cコネクタを持つPSUを使うことに頼っています。例えば、RPiやOrange Pi 5(RK3588)などです。

Appleは、すべてのPD交渉をハードウェアで行うことで解決しています。

イーサネットやUSBのPHYが、これを小さなNVRAMに保存して交渉を処理していないのが信じられない。もしラップトップのように、デバイスがオフの間に充電するバッテリーがあったらどうなるの?Androidは、起動していないときにこれをどう処理してるんだろう?BIOSがこの辺を扱ってるのかな?

もっと掘り下げて、UEFIアプリケーションの概念に出会いました。今日学びました。

スイッチは、15.4W以上を必要とするデバイスのために、データリンク層の分類にLLDPを要求するように設定されている。 これは本当にスイッチの設定の問題に感じる。準拠したPoE PD回路は、その電力クラスを示すべきで、電力供給をブートストラップする必要はないはず。もしPDが準拠していて、部品が正しく選ばれているなら、PSEは準拠していないか、設定が間違っているってことだね。

2015年に、PoEで動く組み込みx86コンピュータやデジタルサイネージシステムを作るプロジェクトに取り組んでた。 >私たちのデバイスは、フル稼働時に約23Wを必要とし、802.3at(PoE+)の領域に入った。著者が解決した問題はかなり興味深いけど、ただの広告を表示するためにフルコピーのWindowsを立ち上げるのは無駄だと思う。フルコピーのWindows 10の攻撃面は、攻撃者にとっては夢のようなものだよね。これらのインストールのほとんどが使われなくなって、超低消費電力のソリューションに置き換えられることを願ってる。

環境次第だね。もしビル内のすべてのPCでWindowsが動いているなら、これらのサインもWindowsで動かす方が理にかなってるかも。すでに支払っているセキュリティソフトのコピーを入れて、承認されたADユーザーがサインを管理できるようにすればいいし。Windowsは攻撃ベクターとしては優れてるけど、自分で管理してるなら、簡単に監査できないベンダーのソリューションよりリスクは少ないと思う。悪意のあるウェブサイトにアクセスしたり、マルウェアのUSBを差し込むユーザーがいないってことも、リスクを減らす要因かもね。もし企業ネットワークに1000台のWindowsマシンがあるなら、あと数台増えるくらい大したことないでしょ?