ELECOM WRC-1167GHBK2-S

PRを投げたタイミングがOpenWrt 18.06のリリース準備作業真っ只中で、しばらく中の人からのコメント等動きが無かったのでWN-GX300GR同様リリース後になるかなーと思っていましたが、今日マージされました。

仕様

これもお馴染みのMT7621です。こちらはWN-GX300GRのMT7621Sに対し、デュアルコアの “MT7621A” が搭載されています。
無線については2.4/5GHz両方を1チップのMT7615Dでカバーしています。ただし、現状OpenWrt (MT76)でのサポートは無いため、使用することはできません。(まあどのみち電波法の問題がありますが)

  • SoC: MediaTek MT7621A (880MHz, 2C4T)
  • RAM: DDR3 SDRAM 128MB
  • Flash: SPI Flash 16MB
  • WAN/LAN: 1000Mbps x1 / 1000Mbps x4
  • UART: 57600bps(RJ45側からVcc, GND, TX, RX)

その他ハードウェアやKernel等細かい点の詳細については、雑記ブログにメモしてあるのでそちらを参照。

OpenWrt化

メーカーファームがOpenWrtベースであったこと、”firmware” パーティションにKernelとRootfsを持つ構造であったことから、factoryファームを生成させることができました。このため、簡単にOpenWrtを導入することができます。

  • WRC-1167GHBK2-Sを起動
    WRC-1167GHBK2-Sに電源ケーブルを繋ぎ、普通に起動。
  • WebUIにアクセス
    PCとWRC-1167GHBK2-SをLANケーブルで繋いで http://192.168.2.1/details.htmlにアクセス
  • ファームウェア更新ページへアクセス
    管理用アカウントの設定を要求された場合は適当に設定し、ファームウェアの手動更新ページへアクセス
  • ファーム更新
    WRC-1167GHBK2-Sのfactoryファームを wrc-1167ghbk2-s_v0.00.bin へリネームしたうえで選択し、アップデートを実行
  • 完了
    Flashの書き込みが完了後再起動され、OpenWrtで起動してくる

備考

  • WRC-1167GHBK2-Sはメーカーファームが前述のとおりOpenWrtベースでであり、構造としてはKernel + RootfsをfirmwareとしてまとめているOpenWrtでよく用いられる手法
    • ただしRootfsはramfsであり、設定保存用のrootfs_dataパーティションがfirmwareパーティションの後ろに存在
    • rootfs_dataの領域をOpenWrtで使用する場合、factoryファームでOpenWrt化した際に設定を引き継いでしまう可能性があることと、メーカーファームでのアップデートの仕組み上factoryからもう一度書き換える必要が出てくるなど面倒になるので、使用せずread-onlyでそのまま。
  • アップデート用ファームはヘッダが “ELECOM 機種名 バージョン” 、ファーム末尾にヘッダを除いた部分のmd5チェックサムが付くのみの構造。
    ヘッダ例:
    ELECOM WRC-1167GHBK2-S v1.03
  • メーカーファームでアップデートする際、ファームウェアのファイル名も見ているらしくOpenWrtのファイル名のままではエラーになる。
  • メーカーファームへの書き戻しは、バックアップ済みのfirmwareパーティションをOpenWrtでのfirmwareパーティションにmtd writeするか、もしくは未検証ながらアップデートファームからヘッダと末尾のmd5チェックサムを除去したものでfirmwareパーティションにmtd writeすることで恐らく可能。
  • Power LEDにRGBの三色が搭載されている。デフォルトではメーカーファームと同じくgreenを電源やステータスランプとして使用。
  • MT7621ではHW NATが実装されているため、WN-GX300GR同様にNATのCPU負荷をかなり抑えることが可能。

色々

今回PRを出してからWN-GX300GRほど時間は掛からなかったものの、メンテナの方からmtdパーティションのlabelについて指摘があったためそれだけ修正。
無線について何か言われるかなとも思ったものの、そちらはdtsにコメントを置いたのとcommitメッセージ内のspecificationにMT7615Dであることを書いたためか、特に何もなかった。

写真

2.4/5GHz両帯域を1チップでカバーしているためか、基板上の実装面積が小さいうえに基板自体も小さめ。

  • 筐体を開けたところ
    IMG_20180612_194509
  • 基板表側全体
    IMG_20180612_195359
  • SoCとRAM
    IMG_20180612_195534
  • MT7615D
    IMG_20180612_195911
広告

I-O DATA WN-GX300GR

PRを投げたタイミングが丁度OpenWrt 18.06の作業が開始された時期であり、しばらく中の人からのコメント等動きが無かったのでリリース後になるかなーと思っていましたが、今日マージされました。
Tama W06に続き、この機種についてもまとめておきます。

仕様

WSR-1166DHP/DHP2やVR500等でお馴染みのMT7621です。ただし、WN-GX300GRでは上位モデルのWN-AX1167GRに対して下位モデルという位置づけからか、シングルコアの “MT7621S” が搭載されています。

  • SoC: MediaTek MT7621S (880MHz, 1C2T)
  • RAM: DDR2 SDRAM 64MB
  • Flash: SPI Flash 8MB
  • WAN/LAN: 1000Mbps x1 / 1000Mbps x4
  • UART: 115200bps(RJ45側からVcc, GND, TX, RX)

その他ハードウェアやKernel等細かい点の詳細については、雑記ブログにメモしてあるのでそちらを参照。

OpenWrt化

前回sysupgradeファームのみでOpenWrtを導入できたTama W06に対し、こちらはFlashこそ8MBあるものの、メーカーファームでは各OS領域4MB弱でデュアルイメージを構成しています。そのため、OpenWrtではそれぞれの領域に入りきらないのでfactoryファームは断念しました。
これにより、OpenWrtの導入にはシリアルコンソールの接続が必要になります。

  • TFTPサーバを用意
    PC側のIPアドレスを192.168.99.8に設定してWN-GX300GRと接続、WN-GX300GRのinitramfsファームを uImageWN-GX300GR にリネームしたうえでTFTPディレクトリに置き、TFTPサーバを起動。
  • U-Bootからinitramfsでブートさせる
    WN-GX300GRに電源ケーブルを繋いで起動し、U-Bootの起動方法選択で “1” を選択しTFTPからイメージを取得してRAM上に展開しブートするモードへ。デバイスとサーバのIPアドレス、ファイル名は変更せずEnterキー3回押下でinitramfsイメージをTFTPサーバからダウンロードし、それを使用して自動的にブートが実行される。
  • sysupgradeファームを投入
    initramfsファームでのブートが完了したら、mtd erase firmware を実行してメーカーファームを削除したうえでsysupgradeによりsysupgradeファームを焼き込む。
  • 完了
    2分前後掛かるものの、Flashへの書き込みが完了して再起動する。

備考

  • OpenWrtでのシリアルコンソールのBaudrateは115200bpsに設定。ramipsでよくある57600bpsかと思っていたら、メーカーファームではU-BootもKernelも115200bpsだった。このため、OpenWrt化しても57600bpsではU-BootとOpenWrtで異なってしまうので、115200bpsを採用。
  • OpenWrtでは2つあるOSイメージ用パーティションを結合して1つとして扱うようにしたため、initramfs上でバックアップしたメーカーファームの2つのOS領域 (“Kernel” + “app”) を結合して firmware.bin などとし、
    mtd write firmware.bin firmware
    

    とすることでメーカーファームに書き戻すことが可能。
    メーカー公式サイトで公開されているアップデート用ファームでもできそうだけど未検証。

  • MT7621ではHW NATが実装されているため、WN-GX300GRでもNATのCPU負荷をかなり抑えることが可能。

雑感

今回はPRを出してからマージされるまで時間は掛かったものの(前述のとおりリリース準備のため)、議論を行うことは無くすんなりマージされたので一安心。
上位機種のWN-AX1167GRも某氏からパッチ案等頂いたのである程度組み上げてあるものの、実機が無く検証できないのでどうしたものやら。

WG2600HP(経過報告)

さて再びやり始めた新機種のサポートですが、今回は最後の1つがコケておりPRにたどり着かない状況です。

  • きっかけ

    雑記にも書きましたが、3月24日の東海道らぐ横浜当日に「何か面白そうな機種無いかな」と秋葉原に寄ってフラフラ徘徊した際、駅近くのソフマップでWG2600HPを一部部品欠損で¥6,500弱で見つけ(パネルが無いとされていたが全部揃っていた)、ipq806x機と予想されることから購入しました。

  • サポート作業

    • 流れ

      • 筐体を開ける
        ここがしんどい。WPSボタンのある側がまず黒いカバーを外すことができ、その下にさらに金属板が取り付けられたベージュとグレーの中間程度の色をしたカバーが取り付けられている。この2つ目のカバーの取り外しに手間取った。フロント側(USB, RJ-45等と反対側)のツメが銀色の帯と反対側にあり、奥まった位置にあるため上手く引っ掛けてツメを外すことができない。
        最終的に強く力を掛けた際にツメが1つ破損し、その結果大きく開くようになったのでなんとか残りのツメを外して開けた。
      • シリアルを繋ぐ
        基板上にスルーホールで出ており、ハンダ埋めも無いのであまり難しい点は無し。USBやRJ-45側から RX, TX, NC, GND, Vcc。ケーブルは TX, RX, (接続無し), GND, (接続無し)とする。
      • コンソールで色々確認する(失敗)
        WG2600HPではコンソールにパスワードが掛けられており、アクセス不可。OpenWrtベースのQSDKが使用されておりfailsafeへ落ちることはできるものの、ある程度時間が経過すると “watchdog barked!” と出て再起動されてしまい、行動が著しく制限される。そこでrootのパスワードハッシュを見つけはしたものの、パスワードまでは現状特定できずログインもできていない。
        また、U-Bootもブートを中断してコンソールに入ることなどができない上に、何らかのボタンを押しながらブートすることでinitramfsイメージを受け付けるといった機能が無いようで、ビルドしたファームを流し込むことができない。
      • とりあえずファームをビルド
        流し込む手段が見つけられていないものの、とりあえずファームをベース部分だけ組んでビルド。OpenWrtのipq806xでサポート済みの機種のうち “Qualcomm IPQ8064/AP148 (dts: qcom-ipq8064-ap148.dts)” がリファレンスボードらしくWXR-2533DHPでもこれを流用できたので、このdts等をコピーしてWG2600HP用の機種サポートを暫定的に追加する。
        mtdパーティションについてはfailsafeやbootlogから確認できていたので、それを基に定義を追加。
      • U-Bootの環境変数を弄れた
        failsafeで利用できるコマンドを見て回っていたところ、U-Bootの環境変数を表示するfw_printenv、その変更を行うfw_setenvを発見。そのまま叩いてもuciに設定が入っておらず、/etc/fw_env.config も無いのでエラーになるが、/etc/fw_env.config をAPPSBLENVパーティションで記述したところ環境変数の取得と設定を行うことができた。
      • initramfsイメージを投げ込む
        fw_setenvが利用できたので、bootcmdを書き換えてinitramfsイメージをTFTPで取らせてブートする様に変更する。
        コマンドが少々長いので、”ramboot” として分離した。rambootはWXR-2533DHPのものを参考にした。

        fw_setenv autostart yes
        fw_setenv ipaddr 192.168.10.1
        fw_setenv serverip 192.168.10.2
        fw_setenv ramboot "rootfstype=ramfs; tftpboot 0x44000000 wg2600hp.bin"
        fw_setenv bootcmd "run ramboot"
        

        ipaddrでルータ側のIPアドレスを、serveripでTFTP側のIPアドレスを設定する。
        rambootでは、rootfstypeをramfsとして指定、TFTPを利用してサーバから wg2600hp.bin を取得してメモリ上 0x44000000 にロードしてブートする。ただしこれだけではロードしただけで止まってしまうため、自動でブートも行うよう “autostart=yes” を設定する。
        bootcmdでは、rambootに設定したコマンドを実行 (run) する。

      • mtdをバックアップ
        initramfsイメージでブートできたら、弄る前に各mtdパーティションをバックアップしておく。ddしてscpでダウンロードした。
        また、WG2600HPでは バックアップしたうちの “ART” ではなく “PRODUCTDATA” パーティションにMACアドレスが格納されているため、メーカーファーム上で確認しておいた各インターフェースに割り当てられているMACアドレスと比較して始点アドレスを確認する。
      • 各種情報を確認する
        initramfsイメージでブートし、各種情報(主にGPIO周辺)を確認する。
        NECが公開しているWG2600HPのソースコードでは “CONFIG_BOARD_AKRO” として #ifdef にWG2600HPの情報が記述されており、これと合致しているかを確認する。
        WG2600HPのRJ-45ポートにPCなどとケーブルを接続し、リンク状態も確認する。すると、OpenWrtで既にサポートされている他機種とはポート構成が異なっており、ほんとか?という気持ちになった(そうリンクするんだからそれしか無いのだが)。
      • コードを修正してテスト
        確認した情報を基にコードを修正し、再度投入して正常に機能するかテスト。問題が見つかれば再度修正してトライ。
        USBポートやPCIe、各インターフェースのMACアドレス辺りを何度か修正を重ねた。
      • Flashに焼き込み
        initramfsイメージでできる作業がおおよそ完了したら、最後にFlash周りの確認のため焼き込む。
        mtdパーティション等の構成からipq806x内のTP-LINK VR2600vと同じ書き込み方法が使えると判断し、その通りに platform.sh を記述。
        initramfsイメージからsysupgradeで焼き込む前に、FlashからブートできるようにU-Bootのbootcmdを変更する。この際、bootipqを設定するだけだと、kernel自体が破損しているのであればU-Bootのコンソールに自動で落ちるものの、そうではない問題があった場合にブートが止まってしまったり、再起動を繰り返すのみで復旧不能に陥るため、rambootも残すようにする。

        fw_setenv bootcmd "run ramboot || bootipq"
        


        上記でまずrambootを受け付け、それが失敗すればbootipqを実行する。
        bootcmdを設定したらsysupgradeを実行してFlashに焼き込む。ここまでは問題無く成功。

  • 問題

    • sysupgradeで設定を引き継げない

      sysupgradeの際、本来であれば “kernel”, “rootfs” パーティションに新しいファームウェアが書き込まれると同時にバックアップされていたconfig類が書き戻されるはずが、コンソール上にメッセージは出るものの再起動すると初期状態になってしまっている。
      SPI Flash環境でのsysupgradeに通常使用される “default_do_upgrade” を実行した後に “jffs2_copy_config” を実行すればconfig類が引き継がれたものの、コードを確認しても本来であれば “default_do_upgrade” だけでできるはずであり、他に “jffs2_copy_config” を実行している機種は無い。この問題が解決できずしばらくここで作業がストップしてしまっている。
      config類がどこか別のパーティションに書き込まれてしまっているのかと確認したものの、WinMerge等でバイナリのdiffを取ってもkernelとrootfs以外に変更されたパーティションは無かった。
      もう少し追加で詳しく調べてみる予定。

  • 所感とか

    作業中、ミスによってkernelがコンソールに何も吐かない状態にしてしまい、故意にメーカーファームのkernelを破損させる羽目になるなどかなり綱渡りの作業になった(それも、kernelを破損させられずにrootfsをやってしまったらたぶんアウト)。しんどいけど楽しい。
    気になる個所はいくつかあるものの、現状問題らしい問題は上記のsysupgradeの問題1つのみ。さすがにこの状態でPR投げるわけにもいかないため、解決できずストップしてしまっている。
    それまでは(initramfsイメージを投げ込めてからは)サクサクと進んでいたため、まさかそこでコケるとは思わず早いうちにPR投げるまで行けそうと思っていた。
    今のところ解決策が全く思いつかないため、今後Forumで質問してみようかなと思う。場合によってはjffs2_copy_configでPR投げてしまおうかとも考えたものの、メンテナ氏に迷惑かけてしまうのもどうかというところがある。

多摩電子工業 Axing W06

OpenWrt masterに、多摩電子工業 Axingシリーズの小型無線LANルータ “W06 (AW06 / TW06W)” のサポートが追加されました。
upstreamに投げたものとしては、今回が初めてのデバイスサポート。

仕様

個人的に初のMT7688AN。購入時は正直無線の速度などからNexx WT1520に近い(RT5350, RAM 32MB, Flash 4MB)構成かと思っていたものの、実際に開けてみたら余裕を持った構成だった。
小型機としては大容量の16MB Flashでびっくり。通常サイズのルータで8MBしか無い機種を煽れる

  • SoC: MediaTek MT7688AN (575MHz, 1C1T)
  • RAM: DDR2 SDRAM 64MB
  • Flash: SPI Flash 16MB
  • WAN/LAN: 100Mbps x1
  • USB: USB 2.0 Type-A x1
  • UART: x1(RJ45側からGND, RX, TX, Vcc)

その他ハードウェアの詳細については、雑記ブログにメモしてあるのでそちらを参照。

OpenWrt化

メーカーファームがOpenWrtベースであり、またメーカーのアップデート用イメージも独自ヘッダや暗号化が一切無く単純なKernel + Rootfsの構成。そのため、factoryイメージを用意する必要が無かった。

  • W06を起動
    電源供給用のMicroUSBポートにケーブルを接続し、W06を起動
  • W06の無線LANに接続
    W06が起動したら、それが発しているSSIDに接続。LANポート側はデフォルトでWANとして設定されており、ルータのWebUIに接続できない。無線LANはデフォルトでLAN側。
    接続に必要なパスワードはルータ裏側のラベルに記載あり。
  • sysupgradeファームを投入
    WebUIにログインし(デフォルトでは admin/(空))、ファームウェア更新ページへアクセス。通常のアップデート手順でOpenWrtのW06用sysupgradeイメージを選択し、OKを押下するとFlashへの書き込みが開始される。
    この際特にファームウェアのチェックは厳密には行われないようで、すんなりいける(はず)。
  • 完了
    2分前後掛かるものの、Flashへの書き込みが完了して再起動する。
    再起動後、メーカーファームとは異なりLANポートをデフォルトでLAN側に設定してあるため、192.168.1.1でアクセス可。

注意事項など

  • メーカーファームへの書き戻しは、OpenWrt上でバックアップ済みのメーカーファームにおける “firmware” パーティションを使用して
    sysupgrade -F -n firmware.bin
    

    とすることで可。

  • メーカーファームではシリアルコンソールにログインが必要であり、rootにパスワードが設定されている。メーカーファームがそもそもOpenWrtベースであるため、WebUIからOpenWrt化した場合ログインとパスワードも継承されてしまい、OpenWrt化後もLuCIへのログインやSSH、シリアルコンソールでのアクセス時にそのパスワードが要求されてしまう。
    このパスワードについては雑記ブログを云々。
    このログインとパスワードをOpenWrt化後に削除したい場合、WPSボタンを長押しすることでfactory resetが掛かり、OpenWrtの初期状態へリセットされるため削除できる。
  • メーカーファームでは筐体側面のWPSボタンがリセットと共用になっているものの、OpenWrtではリセットボタンのみに設定。

雑感

今回も以前WT1520のリセットボタンを追加した時と同様mkresin氏に助言して頂いたおかげで、なんとかサポート追加をすることができた。感謝。こちらの勘違いなどでだいぶ氏の手を煩わせてしまったけれども、それでもしっかり最後まで対応して頂いたのが非常にありがたい。
また、メンテナ氏の手を煩わせてしまうことになってしまうけれども、やはり自分の中だけで作業するのとPRを投げてやり取りしながら問題を解決して進めるのとでは、得られる知識量が段違い。今回得られた知識を活用しつつ、今後も色々取り組んでいければと思う。

WXR-2533DHP(経過報告2)

前回の経過報告から10日くらい経過し、いくらか進んだのでここで再び経過報告です。

状況

  • U-Bootのbankチェックをパスできるようになった
    • rootfs checksumがどんな値かも判明。xeditで以下の様に出すことができ、
      wxr-2533dhp_133.PNG
      Linuxでの算出方法は某氏より以下を教えて頂いた。

      od -A n -t u1 | tr -s ' ' '\n' | awk '{s+=$0}END{printf "%x", 255-s%256}'
      
    • 上記により、ブート時にU-Bootのコンソールからbootipqを叩いてチェックをスキップさせる必要が無くなった(→ 何もせずブートできる)
  • KernelのRootfsとU-BootのRootfsチェック用にrootfsボリュームを2つ作る必要が生じた
    • U-Bootは “ubi_rootfs” ボリュームのみを、OpenWrtのKernelは “rootfs” ボリュームのみをそれぞれ固定で参照しようとするため。
      • 当初U-Boot側に合わせてOpenWrt側rootfsのボリューム名をubinizeで “ubi_rootfs” に変更したが、何度試してもrootfsの認識に失敗した。結局、OpenWrt側が target/linux/generic/pending-4.9/491-ubi-auto-create-ubiblock-device-for-rootfs.patch でrootfsとして使えるボリュームを “rootfs” のみに固定していることが判明、やむなく別個で作ることにした。
      • OpenWrtビルド時に生成されるrootfsを “ubi_rootfs” にもそのまま使用するとNAND Flash上のスペースを無駄に占有する(OpenWrt側では使用されない)ため、空のフォルダ1個をsquashfs化して、そこにU-Bootのチェックをパスするのに必要なchecksumを付加するようにした。
  • U-Bootの挙動に絡み、KernelはBank1を、RootfsはBank2のモノを使用することにした
    • U-Bootが、Bank2を “破損している” と判定しない限りBank2⇒Bank1の向きで書き戻しを行い、またその際 “kernel” と “ubi_rootfs” のみの書き戻ししか行わないため。
      • WXR-2533DHPでは、メーカーファームでは当然ながらBank1の “kernel”, “ubi_rootfs”, “ubi_rootfs_data” がブートに使用される。
      • その状態でアップデートを行った場合、更新先のファームはBank1ではなくBank2に書き込み、リブートしてU-Bootのbankチェックが実行された際、イメージが異なるとしてBank2からBank1へイメージが書き込まれ、アップデートが完了する仕組みになっている。
      • OpenWrtの場合、KernelはメーカーファームでもOpenWrtでも “kernel” なのでU-Bootにより問題なくBank2⇒Bank1へ書き込まれるが、RootfsはU-Boot用の “ubi_rootfs” がU-Bootに認識され書き戻されるのみで、Bank2にあるOpenWrt用の “rootfs” は何もされない(= Bank1のrootfsが更新されない)。
      • もしOpenWrtでKernelとRootfsを両方ともBank1から起動できるようにする場合、”kernel” と “ubi_rootfs” はBank2に、”rootfs” とデータ領域の “rootfs_data” はBank1にと2か所に書き込まなければならず、手順が面倒になる。
        また、sysupgrade時も両方への書き込みが必要になり、複雑化してしまう。
      • 対して、kernelはBank1、RootfsはBank2としてしまえば、Bank2に書き込まれたOpenWrtの “kernel” とU-Boot用の “ubi_rootfs” は自動でBank1に書き込まれU-Bootはそれをブートするほか、RootfsはBank2に書き込み済みの “rootfs” を読み込ませれば良いのでだいぶ簡単になる。
      • メーカーファームと現時点でのOpenWrtファームにおけるUBIボリュームの使用状況については、雑記にまとめた。
      • ただし、ぶっちゃけ上記の雑記で改めて表にしてみると「ひどいなこれ」という感想しか出てこない。
      • というのを書きながら、’Bank1にイメージ書き込んだ後Bank2から意図的に “kernel” だけボリューム削除して破損扱いにさせれば、通常とは逆向きのBank1⇒Bank2の書き戻しが発生するから、使用するボリュームをBank1にまとめることもできるかな?’ というのが思い浮かんだ。後で試す。
  • sysupgradeまで機能するようにできた
    • WXR-2533DHPでは上の項目で長々と書いた通り “ubi_rootfs” を上手く扱わなくてはならず、その関係上OpenWrtに存在しているsysupgradeスクリプト(というかNAND向けスクリプトのnand.sh)では対応できない。そのため、いくらか引用したうえでbuffalo.shを作成し、 “ubi_rootfs” をバックアップ/書き戻しすることでsysupgradeを行えるようにした。
    • ただし、テスト回数とテスト条件はあまり多く試せていないため、確実性は不安。
    • また、上のBankの取り扱いで最後に書いた思いついたことを試す場合、再度sysupgrade用スクリプトの改変が必要になるため、どうなることやら。
  • PCI周りがエラーらしきものを吐く
    • ブート時にPCI周辺で “無線のFirmwareが読めない” というようなエラーが吐かれる。
      ただしブート完了後無線は正常に機能しているように見え、また少し検索してみても “問題ない” というような記述が見られる。

      ログ

      [   19.985388] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
      [   19.985940] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
      [   20.172091] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/firmware-6.bin failed with error -2
      [   20.172147] ath10k_pci 0000:01:00.0: Falling back to user helper
      [   36.077329] firmware ath10k!QCA99X0!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
      [   36.492146] ath10k_pci 0000:01:00.0: qca99x0 hw2.0 target 0x01000000 chip_id 0x003b01ff sub 168c:0002
      [   36.492179] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
      [   36.502471] ath10k_pci 0000:01:00.0: firmware ver 10.4.1.00030-1 api 5 features no-p2p crc32 d2901e01
      [   36.600352] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 1:1 crc32 08fa09f2
      [   37.865657] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
      [   37.953404] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
      [   37.953970] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
      [   38.156469] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/firmware-6.bin failed with error -2
      [   38.156515] ath10k_pci 0001:01:00.0: Falling back to user helper
      [   38.307675] firmware ath10k!QCA99X0!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
      [   38.307815] ath10k_pci 0001:01:00.0: qca99x0 hw2.0 target 0x01000000 chip_id 0x003b01ff sub 168c:0002
      [   38.315640] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
      [   38.327131] ath10k_pci 0001:01:00.0: firmware ver 10.4.1.00030-1 api 5 features no-p2p crc32 d2901e01
      [   38.389439] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 1:2 crc32 08fa09f2
      [   39.664713] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
      

今後

  • できればfactoryイメージを作りたいものの、単にKernelとRootfsを投入しただけではリブート後OpenWrtのKernelがRootfsを見つけられなくなるので、どうしたものか

雑感とか

  • SoC(IPQ8064)は負荷に応じてコアごとにクロックが変動していた(384MHz – 1,400MHz)
  • LuCIのページ遷移が体感的に速い
  • どこかで有線のiperf計測したい

お知らせっぽいもの

  • 今のところ今年2月のOSC 2018 Tokyo/Springにて、東海道らぐブースの場所をお借りしてWXR-2533DHPを動態展示させていただく予定です。
    色々詳しい方にご意見等頂ければと思います。