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

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

2025年5月28日原文(roderickkhan.com)

概要

  • 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の交渉を行うという方法が、この記事と非常に似ています。

Hacker Newsで議論の続きを見る