link もっと前
   2019年 4月 19日 -
      2019年 4月 10日  
link もっと後

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

日々

link permalink

RISC-V の SoC を見ていた

Linux が動くくらいの RISC-V の SoC 搭載ボードを探していたのですが、どうやらまだ市販されてなさそうでした……。

代わり(?)に SiFive の高性能 RISC-V SoC である HiFive Unleashed(リンク)のマニュアルを眺めていました。

HiFive Unleashed は高性能と紹介されていることが多いですが、現状 RISC-V は Arduino くらいの小規模 SoC がほとんどで、それらと比較して高性能、と言っているのだと思われます。

特に珍しい機能もないですし、最近のテレビやタブレット向けの巨大な ARM 系 SoC と比べると、どうしてもショボく見えてしまうのは仕方ないでしょう。

ああ、でも Errata の章があるのは珍しいかもしれません。

ROCK-2: High 24 address bits are ignored
Workaround
Do not access out-of-bound addresses in software.
I2C-1: I2C interrupt can not be cleared
Workaround
Poll the I2C controller state to wait for TIP (transaction in progress) to go low.

などの豪快なバグがある様子が伺えます。特に ROCK-2 の Workaround は全然 Workaround になっておらずのが面白いです。アクセス違反をするな、と言ってアクセス違反がなくなるなら OS の苦労はないでしょ。かなり悲惨なバグです。

ボードには修正した SoC を載せるのか、バグった SoC を強引に搭載するのか、どちらなんでしょうね……。

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

[編集者: すずき]
[更新: 2019年 4月 20日 00:42]
link 編集する

コメント一覧

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



link permalink

Linux の DMA

昨今のキャッシュを持った CPU では、DMA を行う際に CPU のキャッシュのフラッシュ(ダーティデータをメインメモリに書きだす、パージともいう)やインバリデート(キャッシュから消しさる、クリーンともいう)が必須です。

しかしアーキテクチャや CPU の実装によってキャッシュの操作方法は異なるため、Linux では DMA API というレイヤでアーキテクチャの差分を隠蔽しています。

Linux で DMA を行うドライバを書くときの一番単純な作法(=単一の領域に DMA を行う、スキャッターギャザーなどはしない)は、

dma_alloc
バッファ確保
dma_map_single
バッファを CPU のメモリ空間にマップし、CPU から見えるようにする
dma_sync_single_for_cpu
CPU からバッファをアクセスする準備
CPU からバッファにデータを書き込む
dma_sync_single_for_device
デバイスからバッファをアクセスする準備
デバイスから DMA を行いデータを読み込む
dma_unmap_single
バッファのマップをやめる
dma_free
バッファ解放

ざっくりいってこのような感じです。先ほど述べた通り、Linux の DMA API にキャッシュのフラッシュやインバリデート関数はありません。ハード依存の操作をなるべく減らし、多数のアーキテクチャに対応しやすくなっているんですね。

実際はいつフラッシュしているのか?

そうはいっても、実際にどこでキャッシュフラッシュしているか、気になると思います。昔、Linux 4.4 を調べた情報を引っ張り出してきました。アーキテクチャは AArch64 つまり 64bit の ARM コアです。

AArch64 の場合、キャッシュ操作をしているのは dma_sync_single_for_cpu() と dma_sync_single_for_device() です。前者がインバリデート、後者がフラッシュ+インバリデートを行っています。

前者の dma_sync_single_for_cpu() を追いかけてみると、

dma_sync_single_for_cpu()
関数ポインタ経由で ops->sync_single_for_cpu() を呼びます。AArch64 の場合 ops には通常 swiotlb の DMA 操作関数が入っています。ですので __swiotlb_sync_single_for_cpu() が呼ばれます
__swiotlb_sync_single_for_cpu()
コヒーレントバッファでない(キャッシュフラッシュがいる)場合 __dma_unmap_area() を呼びます
__dma_unmap_area()
__dma_inv_range() を呼びます
__dma_inv_range()
キャッシュをインバリデートします

こんな感じですね。しつこいですが AArch64 の実装を見ただけですので、将来的に変わるかもしれないし、他のアーキテクチャでは仕組みが違います。

直接フラッシュしたがるおじさん

昔の Linux ではキャッシュ操作関数をドライバから使うことができました。その記憶からなのか、たまにフラッシュやインバリデートのようなアーキテクチャ依存の操作を直接呼びたがる人がいます。

今の Linux ではキャッシュ操作関数は当然ありますが、ドライバからは呼べない、つまり呼ぶことを推奨していません。もちろんオープンソースなので改造すれば何でもできますけど、メンテナンス性や再利用性、移植性を下げるだけで、損しかないでしょう。

[編集者: すずき]
[更新: 2019年 4月 20日 00:29]
link 編集する

コメント一覧

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



link permalink

レジスタダンプ、書き換えツール memaccess - ちょっと修正

先日(2019年 3月 24日の日記参照)作った memaccess(GitHub へのリンク)細かい部分が色々バグっていたので直しました。

  • 32bit 環境でビルドできない
  • ビルド時に libtool を要求する(本来は要らない)
  • 0x80000000_00000000 以上のアドレスを指定すると 0x7fffffff_ffffffff になってしまう
  • 32bit を超える値を書き込めない

アドレスの指定は文句なしで 64bit 符号なし整数にしましたが、書き込む値については 64bit の符号つき整数(今はこっち)と 64bit の符号なし整数の、どっちが良いんでしょうね。贅沢を言えば、どちらも使いたいですけど。

[編集者: すずき]
[更新: 2019年 4月 19日 23:35]
link 編集する

コメント一覧

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



link permalink

ぼやける Windows

以前の日記(2019年 3月 17日の日記参照)で、Windows Update のあとにウインドウのタイトルがズレてしまう話を書きました。

その際に同時に発生する画面がぼやけてしまう現象についてもスクリーンショットを取ったので載せておきます。


ボヤけている状態

このようにフォントがボヤけてしまいます。タスクマネージャの場合はあまり目立ちませんが、アプリケーションによってはさらに顕著です。


サインアウト、サインインしなおした状態

前回は「再起動で直る」と書きましたが、サインインしなおすだけでも直るようです。

ボヤける理由の予想

ざっくりいうと、Windows Update がテキストサイズの拡大縮小設定を元に戻した後に、サインインしなおさないからじゃないか?と思っています。

Windows 10 にはアプリケーションのテキストサイズを調整する機能があります。[Windows の設定] -> [システム] -> [ディスプレイ] から設定できます。


拡大縮小設定を変更したときの警告文

設定変更すると一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません、という警告文が表示されます。

購入当初は 125% の設定になっていました。初期値はディスプレイの物理的なサイズと解像度によって決まっているそうです。あと、私は拡大縮小の設定を「100%」に変更して使用しています。

以上から導いた私の予想ですが、

  • Windows Updateによって、テキストサイズの設定が初期値(125%)に戻る
  • Windows Update が PC を再起動する
  • アプリケーションがテキストサイズ 125% で表示する
  • Windows Update がユーザーが使っていたテキストサイズ設定(私の場合 100%)に設定しなおす
  • サインアウトは行わないため、アプリケーションがついてこられずボヤけてしまう

こんな状態になっているのではないかと思っています。

[編集者: すずき]
[更新: 2019年 4月 13日 17:06]
link 編集する

コメント一覧

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



link もっと前
   2019年 4月 19日 -
      2019年 4月 10日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www2.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 7/16 02:26

カレンダー

<2019>
<<<04>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント 5件

  • link 19年05月17日
    すずき 「試してみたら、同じみたいです。\nわざわ...」
    (更新:05/25 10:35)
  • link 19年05月17日
    hdk 「実際に試したわけではないので素朴な疑問な...」
    (更新:05/23 21:07)
  • link 19年04月01日
    すずき 「どの CPU というかシステムでも同じ傾...」
    (更新:04/05 11:03)
  • link 19年04月01日
    hdk 「去年Ryzen 7 1700で測りました...」
    (更新:04/02 22:48)
  • link 19年03月05日
    すずき 「> オシロの波形見てて気がつかなか...」
    (更新:03/21 17:45)

最近の記事 3件

link もっとみる
  • link 19年07月12日
    すずき 「[OpenVX on OpenCL] 会社の人に OpenVX の...」
    (更新:07/16 02:26)
  • link 19年07月04日
    すずき 「[Unleashed の動作周波数] SiFive FU540 の...」
    (更新:07/06 01:16)
  • link 19年05月27日
    すずき 「[がんばれ HiFive Unleashed] HiFive Un...」
    (更新:07/06 00:47)

こんてんつ

open/close wiki
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 過去日記について

その他の情報

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