コグノスケ


link 未来から過去へ表示  link 過去から未来へ表示(*)

link もっと前
2018年12月6日 >>> 2018年12月15日
link もっと後

2018年12月6日

PCの進歩

Ryzen 7は8コア16スレッドCPUですが、5万円もしません。10万円あれば、Ryzen 7 2700, 32GB DDR4, NVMe SSD, マザーボードを買ってもお釣りが来てしまいます。

これほどお安く16並列ビルド(make -j16)に耐えうるCPU, I/O, メモリが購入できる時代が来るとは思いませんでした。一昔前なら、サーバー用の異常に高価なシステムでしか実現できなかったことです。

技術の進歩って素晴らしいですね。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2018/12/16 00:00)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2018年12月9日

最初に触ったPC

私は、比較的PCと出会った時期は遅い(※)ので、パソコン原始時代をほとんど知らないですが、それでも当時のマシンと、今使っているRyzen 7マシンを比べると隔世の感があります。

(※)初めて触ったのは中学校にあったPC9821-Cb2、買ったのはPC9821-V7でCPUはPentium/75MHzだった、はず。

中学生で思い出しましたが、Aboutページの写真(Facebookのアイコンでもある)は中学2年生の時の顔です。現像した写真のスキャンではなく、当時珍しかった「デジカメ」で撮った写真です。機種は覚えていませんが、フロッピーに記録するタイプでした。

当時とそんなに顔は変わっていませんが、髪はかなり白くなりました。何でだろ、体質なのかな……?

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2018/12/12 02:09)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2018年12月11日

Tinker Boardとlinux-next

先日購入(2018年12月5日の日記参照)したTinker Boardでlinux-nextを動かしてみたら、特に何も引っかかることなく起動しました。素敵。しかし調子に乗ってコンフィグをガチャガチャ弄ってたら起動しなくなってしまいました。

ちょっと焦りましたが、同時にROCK64も起動しなくなっていたので、原因はコンフィグじゃなくて、linux-nextの12月11日版を引っ張ってきたことのようです。先週もなってたなあ。またか〜。

やたらデカいvmlinux

AArch32とAArch64のビルドを往復でやっていて、vmlinuxのリンク速度が全然違うことに気づきました。AArch64の方が桁違いに遅いです。

AArch32だとvmlinuxのサイズは20MBくらいですが、AArch64向けにビルドするとなぜかvmlinuxが300MBとかになります。なぜこんなにデカいんでしょう。リンクが遅くて辛いです。

U-Bootもおかしい

Tinker BoardはU-bootでsaveenvすると二度と起動しなくなります。linux-nextを起動するコマンドをsaveしたかったのですが、できません。ちょっと不便です。

この症状ROCK64も同じでした。RockchipのU-bootは何かおかしいんだろうか……?

メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆。

編集者:すずき(2018/12/16 00:12)

コメント一覧

  • T4さん(2018/12/18 13:31)
    > Rockchip の U-boot は何かおかしいんだろうか……?

    おかしかったんですよ
    "saveenv を実行すると自身のコード領域に書き込んでしまう"
    ってのが有りました。

    但し、これもう一年以上前の話で、既に直ってたハズなんですけど…
    具体的にどのツリーを使ったか明示してもらえれば、ココだと提示できますけど
    使ったツリーが不明なんで、提供できるのはこの程度の情報だけです。


    > vmlinux が 300MB とかになります。
    おそらくですが、それデバッグ・シンボルが引っ付いてますね。
    だた、next はもう用が済んでるんで 最新のもので実際に確認したわけではありません
    少なくても、ちょい前にaarch64で弄ってた時は(ver 4.19.0)、20MB程度でした。
  • すずきさん(2018/12/19 11:54)
    > 但し、これもう一年以上前の話で、既に直ってたハズなんですけど…
    > 具体的にどのツリーを使ったか明示してもらえれば、ココだと提示できますけど
    > 使ったツリーが不明なんで、提供できるのはこの程度の情報だけです。

    ASUS のサイトからダウンロードできる下記のイメージをそのまま使っています。日付を見るとほぼ 1年前ですね。

    http://dlcdnet.asus.com/pub/ASUS/mb/Linux/Tinker_Board_2GB/20170417-tinker-board-linaro-stretch-alip-v1.8.zip


    > おそらくですが、それデバッグ・シンボルが引っ付いてますね。
    > だた、next はもう用が済んでるんで 最新のもので実際に確認したわけではありません
    > 少なくても、ちょい前にaarch64で弄ってた時は(ver 4.19.0)、20MB程度でした。

    ご指摘の通りで、arm64 の場合、make defconfig で CONFIG_DEBUG_INFO=y
    になってしまうらしく(なんでこんな設定になってるんだろ…)、
    デバッグシンボルが全力で付いていました。

    CONFIG_DEBUG_INFO を外せば 30MB 程度になります。
  • T4さん(2018/12/21 10:14)
    私は、Tinker Board を持ってないんで、これに付いては何も語れません

    気になったのは↓方です。
    > この症状 ROCK64 も同じでした。
  • すずきさん(2018/12/22 02:10)
    失礼しました。Rock64 の方は、

    U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b

    でした。これも 1年位前のままですね…。

    saveenv で U-Boot が潰れるかどうかは再確認していません。もし起動しなくなると、戻すのが大変面倒なので…。
  • T4さん(2018/12/25 12:45)
    再現しませんね

    確かに、過去にそう言うバージョンはありました。
    しかし、提示のバージョンに関しては、コードを見ても既に直してありますし
    また、実際に "MicroSD / SPI-FLASH" の双方で試してみても問題は発生しませんでした。

    申し訳ないが、指摘の事項は正しいと思えない。
    (*再確認していません。と書いてあるしね)

    でも、敢て確認する必要は有りません
    万が一環境を壊して戻せなくなったら、目も当てられない

    過去に有った問題の該当箇所は、↓に関連した部分です
    https://github.com/ayufan-rock64/linux-u-boot/commit/60cc9f538b03e5c1dc1163192d338a8f78e44141#diff-efde2e212b5355a080e3baf561e01218

    ----
    <最初のブート>
    DDR version 1.13 20180428
    ....
    U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b (Jul 26 2018 - 08:18:38 +0000)

    Model: Pine64 Rock64
    DRAM: 4 GiB
    MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
    SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    *** Warning - bad CRC, using default environment
    ...

    Hit any key to stop autoboot: 0
    => setenv devnum 3
    => saveenv
    Saving Environment to SPI Flash...
    SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    Erasing SPI flash...Writing to SPI flash...done

    ----
    => reset
    <2回目のブート>
    DDR version 1.13 20180428
    ....

    Hit any key to stop autoboot: 0
    => printenv devnum
    devnum=3
  • すずきさん(2018/12/27 00:22)
    確認いただいてありがとうございます。直っているなら良かったです。

    今は、あえて試そうとは思わないですが、U-Boot に興味が沸いたら見てみます。
open/close この記事にコメントする



2018年12月14日

Tinker Boardでは不具合再現せず

目次: ROCK64/ROCKPro64

Tinker Boardでサウンド周りを有効にしてlinux-nextを動かしてみたものの、指摘された不具合(2018年12月5日の日記参照)が出ません。

メールではDMAドライバのどこかでクラッシュした、と言われました。サウンド周りのハードウェアはI2Sとコーデックが居ますが、DMAを使うのはI2Sだけです。コーデックmax98090はSoC外部に居ますから、SoC内部のDMAを使う術がありません。

I2Sが原因ならば、SoC内部のハードウェア起因ですから、Tinker BoardだろうがChromebook C201だろうが、ボードに関わらず現象が再現しても良さそうなのに。

Chromebookで使われているグルードライバrockchip-snd-max98090の影響も疑って、Chromebook C201のデバイスツリー(rk3288-veyron-speedy.dts)からデバイスノードの設定をパクってきて、max98090をspdif-transimtterに差し替えて(Tinker Boardにmax98090は搭載されていない)、無理やり動かしてみましたが、特に何事も無く動いてしまいました。

どうやってもChromebook C201じゃないと再現しないのかな?良くわからないバグだ……。

Tinker Boardのアナログオーディオ出力

ROCK64のときはアナログオーディオ出力でもHDMI出力でも、SoC内蔵のI2Sハードが動作しましたが、Tinker Boardはちょっと事情が違います。

Tinker Boardにもアナログオーディオ端子は付いていますが、接続先はRK3288ではなくオンボードのUSB Audio(Realtek ALC4040)です。アナログオーディオのためにわざわざ専用USBデバイスを載せるとは、豪華なボードだなあ〜。

というわけで、Tinker BoardでSoC内蔵のI2Sが動くかどうか試すには、アナログオーディオ端子ではダメで、HDMI出力じゃないと本当に動作しているかどうかわからないです。我が家にはデジタルテレビならありますが、ボードからケーブルが届かないですね。

できればHDMIが映せて、音も出せて、ボードの隣に置いても邪魔にならないくらい小さいモニタがあるとベストですが、我が家にそんなもんは無い……。

メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆した。

編集者:すずき(2023/05/15 04:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2018年12月15日

ARMワンボードPCのネットワーク

Raspberry Pi対抗ボードの多くはRaspberry Pi 3のEthernetが遅いこと(USB接続らしい)を引き合いに出し、ネットワークが速いことを宣伝文句にしています。

宣伝文句自体は疑っていませんが、どの程度の差があるかは知らないので、測定してみました。ちょうどTinker Boardも購入しましたし、Rockchip同士の比較もしてみたいと思います。

測定方法

測定は簡単です。受信側のPCで下記を実行します。

$ iperf3 -s -p 11111

送信側の各種ボードで下記を実行します。

$ iperf3 -c (PCのIPアドレス) -p 11111

受信側のPCのCPUはRyzen 7 2700で、マザーボードはASUS B450-F GAMINGです。OSはDebian GNU/Linux amd64のTesting版です。測定時点でのカーネルは4.18.0-2-amd64というバージョンになっていました。

測定結果

結果だけ先に言うとTinker Board(RK3288)の方が速いです。ROCK64(RK3328)の方が後発のSoCなのですが、Ethernetは遅いみたいですね。

ちなみにRaspberry Pi 3は94Mbpsでした。そもそもGigabit Etherじゃないので、比べ物になりません。

  • Tinker Board: 942Mbits/sec
  • ROCK64: 805Mbits/sec
  • Raspberry Pi 3 Model B: 94Mbits/sec

念のため各ボードのEthernetケーブルを入れ替えてみましたが、結果は変わりませんでした。

参考までにファイルサーバとして使っているPentium Jのマシンから、同様の計測を行ったところ942Mbits/sec でした。

測定のログ

結果はこんな感じでした。

Tinker Board (RK3288) でのiperf3実行結果
katsuhiro@linaro-alip:~$ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.16 port 58608 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   113 MBytes   950 Mbits/sec    0    358 KBytes
[  4]   1.00-2.00   sec   112 MBytes   942 Mbits/sec    0    358 KBytes
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   5.00-6.00   sec   112 MBytes   943 Mbits/sec    0    406 KBytes
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec    0    406 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec                  receiver

iperf Done.
ROCK64 (RK3328) でのiperf3実行結果
katsuhiro@rock64:~$ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.102 port 54768 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  97.6 MBytes   819 Mbits/sec    0    356 KBytes
[  4]   1.00-2.00   sec  96.4 MBytes   808 Mbits/sec    0    395 KBytes
[  4]   2.00-3.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   3.00-4.00   sec  95.7 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   4.00-5.00   sec  95.8 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   5.00-6.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   6.00-7.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   7.00-8.00   sec  95.7 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   8.00-9.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   9.00-10.00  sec  95.8 MBytes   803 Mbits/sec    0    395 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   960 MBytes   805 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   958 MBytes   804 Mbits/sec                  receiver

iperf Done.
Raspberry Pi 3 Model Bでのiperf3実行結果
katsuhiro@raspberrypi:~ $ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.105 port 46476 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  11.3 MBytes  94.6 Mbits/sec    0   29.7 KBytes
[  4]   1.00-2.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   2.00-3.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   3.00-4.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   4.00-5.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   5.00-6.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   6.00-7.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   7.00-8.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   8.00-9.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   9.00-10.00  sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  94.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  94.2 Mbits/sec                  receiver

iperf Done.
編集者:すずき(2018/12/16 01:11)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2018年12月6日 >>> 2018年12月15日
link もっと後

管理用メニュー

link 記事を新規作成

<2018>
<<<12>>>
------1
2345678
9101112131415
16171819202122
23242526272829
3031-----

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20