SDHC2連続アクセスでリブート

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でのリトライが多発して試験になりませんでした。

--
なかむら

コメントを投稿するにはログインまたは登録をしてください

at_yashi

2014年6月2日 14時23分

中村さん、

> linux-2.6.26-at19を使ってSDHC2へ連続書き込みをすると
> ハードウェアWDOGでリブートすることがあります。
> 連続リードは試してません。

情報ありがとうございます。
とりあえず、こちらでも再現するか確認してみます。

SDHC2の方が、CRCエラーがよく出やすい状態という認識で良いでしょうか？
CRCが起因の場合は、コンソールにメッセージがでるとおもうのですが、
なにか出てますか？

SDHC2が拡張ボードの方にあり、信号品質が起因していた場合、再現させるのが
難しいかもしれません。その時は、質問させてください。

コメントを投稿するにはログインまたは登録をしてください

nakayama.junichi

2014年6月2日 16時43分

中村様

ONICOSの中山です。

中村さんの環境で起きている現象と関係ないかもしれませんが、
以下のページは参考にならないでしょうか？
http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer

私の関わっているプロジェクト（Armadillo-440を使用）では、
SDカードがまれに、リードオンリー状態になってしまうという現象が発生したため、
上記ページにあるような対処を行いました。
リードオンリー状態になるだけで、リブートはなかったですが。。。

コメントを投稿するにはログインまたは登録をしてください

y.nakamura

2014年6月2日 18時58分

中村です。

> 中村さんの環境で起きている現象と関係ないかもしれませんが、
> 以下のページは参考にならないでしょうか？
> http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer

中山さん、
情報、ありがとうございます。
これも試してみることにします。

コメントを投稿するにはログインまたは登録をしてください

y.nakamura

2014年6月3日 1時38分

中村です。

> > 中村さんの環境で起きている現象と関係ないかもしれませんが、
> > 以下のページは参考にならないでしょうか？
> > http://armadillo.atmark-techno.com/sdhc-enforce-single-block-transfer
>
> 中山さん、
> 情報、ありがとうございます。
> これも試してみることにします。

シングルブロック転送にしてやってみました。
かなり遅いですね。
遅いので繰り返し回数はあまり消化できませんでしたが、
数時間動かしたところでは、症状は出ませんでした。

--
なかむら

コメントを投稿するにはログインまたは登録をしてください

y.nakamura

2014年6月2日 18時41分

中村です。

> 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

2014年6月3日 1時34分

中村です。

> たぶん今夜できると思うのですけど、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

2014年6月3日 17時25分

笹山です。

> linux-2.6.26-at19.tar.gz
> atmark-dist-20140415.tar.gz
> この２つを使い、まっさらな状態からビルドして試したところ、
> やはりリブートが発生しました。
>
> ハードウェアは前に書いたのと同じA440＋サンハヤトSD基板、
> と、A410＋オリジナル基板。
> 最初のmake configでのプロダクトの選択は、Armadillo-420です。

検証結果のご展開、誠にありがとうございます。
弊社でも現象が再現しました。

現在、解析を実施中です。
進展があり次第、報告させていただきます。

コメントを投稿するにはログインまたは登録をしてください

y.nakamura

2014年6月4日 3時00分

中村です。

> 笹山です。
...
> 弊社でも現象が再現しました。
>
> 現在、解析を実施中です。
> 進展があり次第、報告させていただきます。

迅速な対応(調査開始)、ありがとうございます。
よろしくお願いします。

コメントを投稿するにはログインまたは登録をしてください

at_takashi.sasayama

2014年6月4日 10時59分

笹山です。

現在までに確認できている点について
報告をさせていただきます。

==============================
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

2014年6月4日 15時42分

中村です。

笹山さん、
詳しい途中経過のご報告、ありがとうございます。

> > ちなみに、printk()などでたくさんの情報をコンソールに出すと、
> > 同じテストスクリプトでも現象が発生しなくなってしまいます。

このprintkデバッグは、目星をつけたいくつかの関数の入り口と出口や、
spin_lock_irq(),spin_unlock_irq()などの近くに手作業で
printk(KERN_INFO "hoge");
などを入れた場合です。

カーネルコンフィグでのMMCデバッグ有効化は試していませんでしたので、
やってみました。
私のところでも数回のループで現象が発生しました。

--
なかむら

コメントを投稿するにはログインまたは登録をしてください

y.nakamura

2014年6月9日 3時20分

中村です。

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

2014年6月9日 10時24分

笹山です。

> 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

2014年6月9日 14時50分

中村です。

> 上記、弊社でも同様の結果が確認できました。
> 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

2014年6月9日 18時35分

笹山です。

> 今までの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

2014年6月9日 19時06分

笹山さん、
中村です。

> 「128に設定すると問題がある」旨の回答をいただいています。
・・・

説明ありがとうございます。

> 引き続き、進展がありましたらご連絡いたします。
> どうぞよろしくお願いいたします。

こちらこそ、よろしくお願いいたします。

コメントを投稿するにはログインまたは登録をしてください

at_takashi.sasayama

2014年6月12日 19時17分

笹山です。

問題の原因はまだ判明していませんが、
こちらで試験した結果を連絡します。

=========================================
リセット現象と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

2014年6月12日 20時50分

中村です。

笹山さん、
調査レポート(の途中経過)、ありがとうございます。

> またデータシートでは設定禁止である 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

2014年6月13日 9時37分

笹山です。

> > 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

2014年6月13日 12時49分

中村です。

> 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

--
なかむら

コメントを投稿するにはログインまたは登録をしてください

Armadilloフォーラム

SDHC2連続アクセスでリブート

製品

コメント