y.nakamura
2014年6月2日 9時52分
中村です。
linux-2.6.26-at19を使ってSDHC2へ連続書き込みをすると
ハードウェアWDOGでリブートすることがあります。
連続リードは試してません。
at19で修正されたmmcドライバをat18に戻すと、現象は発生しなくなります。
絶対に！とは言い切れませんが、下に書くテストスクリプトで、
at19ではリブート頻発、at18では一晩動かしても発生しませんでした。
このあとも自分でもさらに調べる予定ですが、今のところ
根本原因がわかりません。
at19ではSDカードのエラーリトライが強化されたとのことなので、
できればat19を使いたい(at18ではノイズ等でエラーが発生したとき
カーネルパニックになったこともあるので)と思ってます。
少し長くなりますが、できるだけ正確な情報を書いていきます。
どなたかお助け下さい。
at19の中のat18相当に戻したのは次の２つのファイルです。
- drivers/mmc/card/Makefile
- drivers/mmc/host/mx_sdhci.c
下に書くようにGPT割り込みが止まってしまうようなので、
at19で追加された(置き換えられた)drivers/mmc/card/block_mx25.c の
spin_lock_irq()などを重点的に追ってみましたが、原因はつかめずです。
ちなみに、printk()などでたくさんの情報をコンソールに出すと、
同じテストスクリプトでも現象が発生しなくなってしまいます。
●試験ハードウェア
その１：
Armadillo-440 + サンハヤトのSDカードスロット基板CK-35
https://www.sunhayato.co.jp/products/details.php?u=1376&id=07013
CON9から10pinソケットと小さなユニバーサル基板を経由してUEW線で接続。
追加部品は、DAT0～DAT3とCMDを100kプルアップ、CLKを100kプルダウン。
それと電源のパスコンのみ。
その２：
Armadillo-410 + 独自基板
A410とSDカードスロットの間には47kのプルアップ・プルダウンの他に、
保護素子(ESD保護用ダイオードや直列の小さな抵抗など)が入ってます。
配線は長めです。
●ハードウェアWDOGリブートであることの確認方法
ML時代の[Armadillo:09183]での原田さんの説明
http://lists.atmark-techno.com/pipermail/armadillo/2013-September/00918…
を参考に、arch/arm/plat-mxc/wdog.cを次のように修正し、
WDOGタイマによるリセットまでの時間を100秒にしてみたところ、
動作停止から再起動まで100秒になりましたので、
ハードウェアWDOGによるリブートと判断しました。
この修正をしないときは、10秒でリブートしました。
arch/arm/plat-mxc/wdog.c修正箇所
/* Watchdog timers are not enabled by default */ #undef WDOG1_ENABLE /* not defined by default */ #undef WDOG2_ENABLE /* not defined by default */ #define WDOG1_ENABLE //★追加 //#define WDOG1_TIMEOUT 4000 /* WDOG1 timeout in ms */ #define WDOG1_TIMEOUT 100000 /* WDOG1 timeout in ms */ //★変更 #define WDOG2_TIMEOUT (WDOG1_TIMEOUT / 2) /* WDOG2 timeout in ms */ //#define WDOG_SERVICE_PERIOD (WDOG2_TIMEOUT / 2) /* time interval in ms to service WDOGs */ #define WDOG_SERVICE_PERIOD 1000 /* time interval in ms to service WDOGs */ //★変更
動作停止は、LEDをheartbeatにして確認してます。
ハードウェアWDOGが働く＝GPT割り込みが発生しない＝LED点滅が止まる、です。
●試験スクリプト
for i in `seq 1 1000`; do
echo $i `date`
mke2fs -j /dev/mmcblk0p1
mount /dev/mmcblk0p1 /mnt
dd if=/dev/zero of=/mnt/a bs=1M count=1000
umount /mnt
done
●本体のmicroSD(SDHC1)
あまり長い時間は試してませんが、リブートは発生しないようです。
SDHC1とSDHC2の違いよるものか、ノイズ等によるものかは不明です。
●その他
試験ソフトは違うのですが、試験ハードウェア「その２」（を含む装置全体）を
インパルスノイズ試験にかけたとき、リブートの発生頻度が上がりました。
メディア(SDカードのメーカやサイズ)は関係なさそうです。
よろしくお願いします。
P.S.
Armadillo-400シリーズ全体のことと思うですが、投稿画面の製品選択は、
試した440と410のみにしました。
時間があったら、460＋サンハヤトでもやってみます。
A410＋純正拡張ボード＋サンハヤトは、A440のサンハヤト基板をそのままで
試したのですが、at19でのリトライが多発して試験になりませんでした。
--
なかむら
コメント
nakayama.junichi
中村様
ONICOSの中山です。
中村さんの環境で起きている現象と関係ないかもしれませんが、
以下のページは参考にならないでしょうか？
http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer
私の関わっているプロジェクト（Armadillo-440を使用）では、
SDカードがまれに、リードオンリー状態になってしまうという現象が発生したため、
上記ページにあるような対処を行いました。
リードオンリー状態になるだけで、リブートはなかったですが。。。
y.nakamura
中村です。
> 中村さんの環境で起きている現象と関係ないかもしれませんが、
> 以下のページは参考にならないでしょうか？
> http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer
中山さん、
情報、ありがとうございます。
これも試してみることにします。
y.nakamura
中村です。
> > 中村さんの環境で起きている現象と関係ないかもしれませんが、
> > 以下のページは参考にならないでしょうか？
> > http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer
>
> 中山さん、
> 情報、ありがとうございます。
> これも試してみることにします。
シングルブロック転送にしてやってみました。
かなり遅いですね。
遅いので繰り返し回数はあまり消化できませんでしたが、
数時間動かしたところでは、症状は出ませんでした。
--
なかむら
y.nakamura
中村です。
> SDHC2の方が、CRCエラーがよく出やすい状態という認識で良いでしょうか？
はい。
試験に使った機材の"その１"、Armadillo-440 + サンハヤトCK-35の写真を添付します。
（UEW線の処理が雑なので恥ずかしいところなのですが）
写真にはLEDがついてますが、そのLEDと横の抵抗はどこにもつながってません。
それから、写真に写ってませんが、裏側に0.1μFの積層セラミックをつけています。
ケミコンは100μF/16Vです。
Armadillo-440液晶開発キットの液晶(CON11)を外して使っています。
"その２"の独自基板の写真は公開できないのですけど、
どちらもノイズが乗りやすいのは確かです。
> CRCが起因の場合は、コンソールにメッセージがでるとおもうのですが、
> なにか出てますか？
何も出ていません。いきなりHermitの起動メッセージです。
テストのスクリプトでは、mountした後すぐにddを開始してます。
ddは実行中に何もメッセージを出さないので、次のようになります。
(mountから後の部分のみ)
正常時
kjournald starting. Commit interval 5 seconds
EXT3 FS on mmcblk0p1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
1000+0 records in
1000+0 records out
WDT動作時
kjournald starting. Commit interval 5 seconds
EXT3 FS on mmcblk0p1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Hermit-At v2.1.4 (armadillo4x0) compiled at ・・・・・
Uncompressing kernel.....・・・・・....done.
Uncompressing ramdisk......・・・・・........done.
コンソールにでるだろうエラーメッセージというのは、
https://armadillo.atmark-techno.com/forum/armadillo/643#comment-329
で書いた
mmcblk0: data error detected. retrying block read. Retry 1
のようなのですよね。
以前、稀にこれが出ることがありました（A410＋純正拡張ボード＋
サンハヤトでは出まくり）。また、インパルスノイズ試験のときには、
A410＋独自基板でこれが何度か出ましたが、この数日の再現試験では、
"その１"の機材も"その２"の機材も、このメッセージは出ていません。
> SDHC2が拡張ボードの方にあり、信号品質が起因していた場合、再現させるのが
> 難しいかもしれません。その時は、質問させてください。
こちらで作成した基板の場合、御社での再現試験は難しいと思いましたので、
Armadillo-440＋市販のサンハヤトのSDカード基板でも同じ症状になること
（頻度は少し違うようですが）を確認して投稿しました。
現在使用しているカーネルやユーザランドはA410用に作った独自基板に合わせて、
configをあちこち変更し、また、ドライバ類もいくつか修正をしています。
たぶん今夜できると思うのですけど、SDHC2以外の部分には手を入れないものを
使ってのテストもやってみるつもりです。
（本当はこれをやってから投稿すべきだったのですが・・・）
よろしくお願いいたします。
--
なかむら
| ファイル | ファイルの説明 |
|---|---|
| P1060708 (640x427).jpg | Armadillo-440 + サンハヤトCK-35 |
y.nakamura
中村です。
> たぶん今夜できると思うのですけど、SDHC2以外の部分には手を入れないものを
> 使ってのテストもやってみるつもりです。
linux-2.6.26-at19.tar.gz
atmark-dist-20140415.tar.gz
この２つを使い、まっさらな状態からビルドして試したところ、
やはりリブートが発生しました。
ハードウェアは前に書いたのと同じA440＋サンハヤトSD基板、
と、A410＋オリジナル基板。
最初のmake configでのプロダクトの選択は、Armadillo-420です。
カーネルコンフィグレーションの変更は、SDHC2と
CON9_1によるSDHC2のPWREN、それと、
REGULATOR_FIXED_VOLTAGEのみ。
A440＋サンハヤトSD基板ではパワーコントロールをしていないのですが、
A410＋オリジナル基板の方ではCON9_1による制御をしているので、
どちらもCON9_1のPWRENして、同じ設定で動かしました。
起動直後、シリアルコンソールからloginして、コピペで次のように実行。
# echo heartbeat > /sys/class/leds/red/trigger # for i in `seq 1 1000`; do > echo $i `date` > mke2fs -j /dev/mmcblk0p1 > mount /dev/mmcblk0p1 /mnt > dd if=/dev/zero of=/mnt/a bs=1M count=1000 > umount /mnt > done
早いときはループの１～２周目で、遅いときで数周～10数周くらいで、
ハードウェアWDTによるリセットがかかるようです。
--
なかむら
at_takashi.sasayama
笹山です。
> linux-2.6.26-at19.tar.gz
> atmark-dist-20140415.tar.gz
> この２つを使い、まっさらな状態からビルドして試したところ、
> やはりリブートが発生しました。
>
> ハードウェアは前に書いたのと同じA440＋サンハヤトSD基板、
> と、A410＋オリジナル基板。
> 最初のmake configでのプロダクトの選択は、Armadillo-420です。
検証結果のご展開、誠にありがとうございます。
弊社でも現象が再現しました。
現在、解析を実施中です。
進展があり次第、報告させていただきます。
y.nakamura
at_takashi.sasayama
笹山です。
現在までに確認できている点について
報告をさせていただきます。
==============================
1. 現象が再現する環境について
==============================
----------
再現環境
----------
Armadillo-440
linux-2.6.26-at18 or 19
Atmark Dist v20140415
CON9(SDHC2)接続用のmicroSD冶具
- マイクロSDカードスロットDIP化キット
http://akizukidenshi.com/catalog/g/gK-05488
- DAT0-DAT3,CMD 47k プルアップ, 47ダンピング抵抗
- CLK 47k プルダウン
- 電源-GND間に10uFのパスコン
CRCエラーが発生しないことを、
コンソールに出力されるログで確認しています。
試験スクリプトは掲示いただきました下記を用いています。
# for i in `seq 1 1000`; do echo $i `date` mke2fs -j /dev/mmcblk0p1 mount /dev/mmcblk0p1 /mnt dd if=/dev/zero of=/mnt/a bs=1M count=1000 umount /mnt done
試験結果は下記となります。
中村さんの検証結果と同様となりました。
■パターン1 : Linuxカーネルバージョン : linux-2.6.26-at19
SDHC1 : 試験開始後24時間経過するが現象は発生しない
SDHC2 : 現象の発生を確認 (発生時間に関しては後述)
■パターン2 : Linuxカーネルバージョン : linux-2.6.26-at18
SDHC1 : 試験開始後24時間経過するが現象は発生しない
SDHC2 : 試験開始後24時間経過するが現象は発生しない
===================================
2. 現象が発生するまでの時間について
===================================
> ちなみに、printk()などでたくさんの情報をコンソールに出すと、
> 同じテストスクリプトでも現象が発生しなくなってしまいます。
> 早いときはループの１～２周目で、遅いときで数周～10数周くらいで、
> ハードウェアWDTによるリセットがかかるようです。
カーネルコンフィグでMMCデバッグログの有効無効を切り替えた際に、
現象発生までの時間に違いがあることを確認しました。
MMCデバッグログを有効にすると発生までの時間が短くなります。
こちらは、中村さんの結果と逆になりました。
Linux Kernel v2.6.26-at19 Configuration
Device Drivers --->
<*> MMC/SD/SDIO card support --->
[*] MMC debugging■パターン1 MMCデバッグログ 無効
現象発生までの時間 ：1時間～2時間 (試験スクリプトのループ回数 約20～40回)
■パターン2 MMCデバッグログ 有効
現象発生までの時間 ：1分～10分 (試験スクリプトのループ回数 約0～2回)
===================================
3. 現在の解析状況
===================================
下記の観点で解析を進めていますが、
まだ原因解明までには到っていません。
・SDHC1,SDHC2の違い
・排他制御(デッドロックなど)
引き続き、進展がありましたら
ご報告をさせていただきます。
どうぞよろしくお願いいたします。
y.nakamura
中村です。
笹山さん、
詳しい途中経過のご報告、ありがとうございます。
> > ちなみに、printk()などでたくさんの情報をコンソールに出すと、
> > 同じテストスクリプトでも現象が発生しなくなってしまいます。
このprintkデバッグは、目星をつけたいくつかの関数の入り口と出口や、
spin_lock_irq(),spin_unlock_irq()などの近くに手作業で
printk(KERN_INFO "hoge");
などを入れた場合です。
カーネルコンフィグでのMMCデバッグ有効化は試していませんでしたので、
やってみました。
私のところでも数回のループで現象が発生しました。
--
なかむら
y.nakamura
中村です。
printkデバッグではさっぱりわからず、最後の手段（？）、
at18からat19で変更になったところを部分的にat18に戻してみました。
mmc/card/block_mx25.cだけをat18のblock.cに戻しても効果なし。
次に試したmmc/host/mx_sdhci.cの次の部分では効果があり、
例のテストスクリプトのforループを２回にわけて数100回まわしましたが
リブートは発生しませんでした。
//#ifdef CONFIG_ARCH_MX25 //static unsigned int mxc_wml_value = 64; //#else static unsigned int mxc_wml_value = 512; //#endif
INTERNAL DMA だとすると、この違いが影響する部分は、
sdhci_reset()とsdhci_init()の中の
if (mxc_wml_value == 512)
writel(SDHCI_WML_128_WORDS, host->ioaddr + SDHCI_WML);
else
writel(SDHCI_WML_16_WORDS, host->ioaddr + SDHCI_WML);という部分のみだと思います。
i.MX25のリファレンスマニュアルのWMLレジスタに関する部分を眺めてみましたが、
これが今回の問題にどう影響しているのはわかりませんでした。
at18からat19で、この部分が修正された理由はわかりませんが、
笹山さんの調査の手がかりにはなりませんか？
--
なかむら
at_takashi.sasayama
笹山です。
> printkデバッグではさっぱりわからず、最後の手段（？）、
> at18からat19で変更になったところを部分的にat18に戻してみました。
>
> mmc/card/block_mx25.cだけをat18のblock.cに戻しても効果なし。
> 次に試したmmc/host/mx_sdhci.cの次の部分では効果があり、
> 例のテストスクリプトのforループを２回にわけて数100回まわしましたが
> リブートは発生しませんでした。
>
>
> //#ifdef CONFIG_ARCH_MX25 > //static unsigned int mxc_wml_value = 64; > //#else > static unsigned int mxc_wml_value = 512; > //#endif >
上記、弊社でも同様の結果が確認できました。
at19から上記の修正のみをat18に戻したものを用いて、
5台同時にランニング試験を実施したところ、
約60時間が経過してもいずれもリブートが発生しないことを確認しています。
> INTERNAL DMA だとすると、この違いが影響する部分は、
> sdhci_reset()とsdhci_init()の中の
>
> if (mxc_wml_value == 512) > writel(SDHCI_WML_128_WORDS, host->ioaddr + SDHCI_WML); > else > writel(SDHCI_WML_16_WORDS, host->ioaddr + SDHCI_WML); >
> という部分のみだと思います。
>
> i.MX25のリファレンスマニュアルのWMLレジスタに関する部分を眺めてみましたが、
> これが今回の問題にどう影響しているのはわかりませんでした。
>
> at18からat19で、この部分が修正された理由はわかりませんが、
> 笹山さんの調査の手がかりにはなりませんか？
この部分を修正した理由は、i.MX25のエラッタENGcm07452に対する
ワークアラウンドの適用です。
現在、本修正を行うことで何故SDHC2のみ問題が発生するのかを
調査・解析を実施しています。
引き続き、進展があり次第、報告をさせていただきます。
y.nakamura
中村です。
> 上記、弊社でも同様の結果が確認できました。
> at19から上記の修正のみをat18に戻したものを用いて、
> 5台同時にランニング試験を実施したところ、
> 約60時間が経過してもいずれもリブートが発生しないことを確認しています。
60時間ということは、私がここに書く前から笹山さんの方でも
この部分を試験されていた、ということですね。
> この部分を修正した理由は、i.MX25のエラッタENGcm07452に対する
> ワークアラウンドの適用です。
eSDHC: eSDHC last transfer data fails when the WML register RD_WML field is set to DMA mode and is 1 byte or 127 bytes
というやつですね。
昨晩、そこを見てました。
この127という値が気になります。
というのは、リファレンスマニュアルのRD_WMLとWR_WMLの説明で、
table 23-26に
"The maximum legal value for the write watermark level is 127."
と書いてありますが、その前のページの
"23.3.3.15 Watermark Level Register (WML)"の直後には、
"Watermark levels can range from 1–128 words"
と書いてあります。
何で128ではなくて127なの？と探してみたところ、
こういうページを見つけました。
https://community.freescale.com/docs/DOC-98338
から引用
Yuri Muhin 2013/12/13 0:08 It should be "The maximum legal value for the write watermark level is 128" in Table 23-26 instead "The maximum legal value for the write watermark level is 127".
今までの128は問題ない、という話はないでしょうか？
> 現在、本修正を行うことで何故SDHC2のみ問題が発生するのかを
> 調査・解析を実施しています。
よろしくお願いいたします。
--
なかむら
at_takashi.sasayama
笹山です。
> 今までの128は問題ない、という話はないでしょうか？
linux-2.6.26-at19 開発の際に Freescale社 へ同内容を問い合わせたところ、
「128に設定すると問題がある」旨の回答をいただいています。
そのため、 ENGcm07452 のワークアラウンドに従い、
2 - 126 の範囲である 16 を WML の値として選択しました。
16 という値は、
a) i.MX25 WMLレジスタのリセット値であること
b) Linux の mainline で使用している値であること
を理由に選択しています。
SDHC1では問題が出ていなかったので、そのまま 16 を採用しましたが、
SDHC2では確認が不足していました。
大変申し訳ございません。
引き続き、進展がありましたらご連絡いたします。
どうぞよろしくお願いいたします。
y.nakamura
at_takashi.sasayama
笹山です。
問題の原因はまだ判明していませんが、
こちらで試験した結果を連絡します。
=========================================
リセット現象とWML値の関連について
=========================================
WR_WML値がリセット現象の発生に関係していることがわかりました。
またデータシートでは設定禁止である WR_WML 128 のみ、
正常動作を確認しました。
--------
試験環境
--------
Armadillo-440
linux-2.6.26-at19
Atmark Dist v20140415
CON9(SDHC2)接続用のmicroSD冶具
--------
試験手順
--------
1. WR_WML、RD_WML値を変更したカーネルイメージを作成
(WR_BRST_LEN、RD_BRST_LEN値 は 4 に固定)
2. 1のカーネルイメージでArmadilloを起動
3. 試験スクリプトを実行
試験開始後、遅くても3時間以内にはリセット現象が発生していることから、
24時間以上経過した場合は、リセット現象が発生しないと判断しています。
■試験結果1: WR_WML、RD_WML値が同じ値の場合
WR_WML値 RD_WML値 リセット現象の発生
--------------------------------------
128 128 発生しない
126 126 発生する
64 64 発生する
32 32 発生する
16 16 発生する
8 8 発生する
4 4 発生しない ※データの不整合が発生 試験結果3を参照
2 2 発生しない ※データの不整合が発生 試験結果3を参照
--------------------------------------■試験結果2: WR_WML値 128固定時の試験結果
WR_WML値 RD_WML値 リセット現象の発生 -------------------------------------- 128 128 発生しない 128 64 発生しない 128 32 発生しない 128 16 発生しない 128 2 発生しない --------------------------------------
設定すると問題がある WR_WML 128、RD_WML 128では、
問題が発生しない結果となっています。
=========================================
リセット現象が発生しないWML値での通信確認
=========================================
リセット現象が発生しないWML値で、
正常にSD通信が行えているかを確認しました。
■試験結果3: リセット現象が発生しないWML値の組み合わせで通信確認
WR_WML値 RD_WML値 試験結果 備考
--------------------------------------------------------------
128 128 正常 52時間が経過、引き続き試験中
4 4 異常を確認 ※1
2 2 異常を確認 ※1
--------------------------------------------------------------※1:データの不整合が発生することを確認しています。
具体的にはテストデータを書き込み後、読み出し、比較すると一致しないことがあります。
WR_BRST_LEN < WR_WML に設定せよと、i.MX25データシートに記載されていることから、
WML値が 2、4 の時は、WR_BRST_LEN 4 の時は問題が発生していると推測しています。
i.MX25 Multimedia Applications Processor Reference Manual IMX25RM Rev. 2 01/2011
Table 23-26. Watermark Level Register Field Descriptions より引用
The write burst length must not exceed the write watermark level, and all bursts within a watermark level transfer are in back-to-back mode.
=========================================
今後の解析について
=========================================
残念ながら、WR_WMLの設定によって、SDHC2で問題が発生するのかを、
まだ突き止めることができていません。
またFreescaleへ本件の問い合わせを行っていますので、
引き続き、進展がありましたら連絡させていただきます。
どうぞよろしくお願いいたします。
y.nakamura
中村です。
笹山さん、
調査レポート(の途中経過)、ありがとうございます。
> またデータシートでは設定禁止である WR_WML 128 のみ、
> 正常動作を確認しました。
データシート（リファレンスマニュアル）には
"Watermark levels can range from 1–128 words"
と記述されている部分もあります。
ほんとに128が設定禁止なのかどうか、（マニュアル記載のミスと
いうこともあるのでは？）そこらへんの確認も必要かな？と思います。
Freescaleから
>> 「128に設定すると問題がある」旨の回答をいただいています。
とのことでしたが・・・
例のエラッタで言っているのはRDのときだけのようですので、
Freescaleの回答の「128に設定すると問題がある」というのは、
RDだけの話なのかも？（勝手な推測ですが）
マニュアル誤記ですけど・・・（見ればすぐに判断できる部分ですが）
BURSTのところもリファレンスマニュアルでおかしいところがありますね。
ビット定義の図では５ビットあるに[3:0]と書いてあったり。
（[4:0]と書いてあるところもあります）
他の同じような（だけどちょっと違う）プロセッサのマニュアルからの
コピペミスが、あちこちにあるんじゃないかなぁ～なんて思ってます。
> 1. WR_WML、RD_WML値を変更したカーネルイメージを作成
> (WR_BRST_LEN、RD_BRST_LEN値 は 4 に固定)
元のソースのmx_sdhci.hでは、
#define SDHCI_WML_4_WORDS 0x00040004 #define SDHCI_WML_16_WORDS 0x00100010 #define SDHCI_WML_64_WORDS 0x00400040 #define SDHCI_WML_128_WORDS 0x00800080
となっていて、BRST_LENはRDもWRも0です。
（ソースやヘッダファイルでgrepかけてみましたが、単独で
BRSTを設定しているところはなさそうです）
テストで４にした理由は何でしょうか？
> またFreescaleへ本件の問い合わせを行っていますので、
> 引き続き、進展がありましたら連絡させていただきます。
よろしくお願いいたします。
--
なかむら
at_takashi.sasayama
笹山です。
> > 1. WR_WML、RD_WML値を変更したカーネルイメージを作成
> > (WR_BRST_LEN、RD_BRST_LEN値 は 4 に固定)
>
> 元のソースのmx_sdhci.hでは、
>
> #define SDHCI_WML_4_WORDS 0x00040004 > #define SDHCI_WML_16_WORDS 0x00100010 > #define SDHCI_WML_64_WORDS 0x00400040 > #define SDHCI_WML_128_WORDS 0x00800080 >
> となっていて、BRST_LENはRDもWRも0です。
> （ソースやヘッダファイルでgrepかけてみましたが、単独で
> BRSTを設定しているところはなさそうです）
>
> テストで４にした理由は何でしょうか？
誤解を招く表現、失礼しました。
正しくは、
WR_BRST_LEN 、RD_BRST_LEN 値 は リセット値である 4 から変更せずに試験
ですね。
WR_BRST_LEN に 0 を書き込むとリセット値が設定されます。
i.MX25 Multimedia Applications Processor Reference Manual
Table 23-26. Watermark Level Register Field Descriptions
28–24 WR_BRST_LEN[4:0]より引用
The field cannot be cleared: writing 0 to this field results in the reset value 01000.
ただ、ここで記載されている リセット値の 01000 (8) は誤記であり、正しいリセット値は 00100 (4) です。
https://community.freescale.com/docs/DOC-98338
より引用
The default / reset value 0b00100 for the burst length fields (WR_BRST_LEN and RD_BRST_LEN) is correct (instead of 0b01000)
中村さんが既に確認されていますように、
WR_BRST_LEN、RD_BRST_LEN には 0 しか書き込まない為、
リセット値である 4 に設定されています。
y.nakamura
中村です。
> WR_BRST_LEN に 0 を書き込むとリセット値が設定されます。
>
> i.MX25 Multimedia Applications Processor Reference Manual
> Table 23-26. Watermark Level Register Field Descriptions
> 28–24 WR_BRST_LEN[4:0]より引用
>
> The field cannot be cleared: writing 0 to this field results in the reset value > 01000. >
あ、すみません。そこ、読み落としてました。
> ただ、ここで記載されている リセット値の 01000 (8) は誤記であり、正しいリセット値は 00100 (4) です。
>
> https://community.freescale.com/docs/DOC-98338
これ、WMLの最大値が127じゃなくて128だよ、って書いていた記事の後半ですね。
この後半もちゃんと読んでませんでした。m(_ _)m
--
なかむら
at_yashi
2014年6月2日 14時23分
中村さん、
> linux-2.6.26-at19を使ってSDHC2へ連続書き込みをすると
> ハードウェアWDOGでリブートすることがあります。
> 連続リードは試してません。
情報ありがとうございます。
とりあえず、こちらでも再現するか確認してみます。
SDHC2の方が、CRCエラーがよく出やすい状態という認識で良いでしょうか？
CRCが起因の場合は、コンソールにメッセージがでるとおもうのですが、
なにか出てますか？
SDHC2が拡張ボードの方にあり、信号品質が起因していた場合、再現させるのが
難しいかもしれません。その時は、質問させてください。