FC1307A搭載SD-IDE変換基板のおかしな挙動を直す
はじめに
数年前には登場していたと思われる、FC1307Aを搭載したSD-CFアダプタとSD-IDE変換基板に関するお話です。
機能は形状のまま見ての通り、SDカードやMicroSDカードをIDEハードディスクの代わりに使うためのデバイスで、40ピンタイプはSD35VC0、TF35VA0といった型番が印字されており、44ピンタイプは型番の印字は無いものの、こちらもSDタイプ、TFタイプが存在します。
論理的にはSD-CFアダプタ+CF-IDEアダプタとほぼ等価なのですが、SD-CFアダプタでは省略されている電源回路や受動部品が搭載されていたり、プッシュプル式のカードスロットが搭載されており、CF-IDE変換してSD-CFアダプタを組み込むより電気的にも安定していそうで、カードの出し入れもしやすい構造です。
…なのですが、一つ致命的な問題があったのでした。
何が問題か?
状況によって電源投入時に先頭セクタの読み出し内容が化けてしまい、正常に動作しないという挙動が発生してしまうのです。実際にSDカード上のデータが破壊されるわけではないのですが、ホストから見れば書き込んだ通りのデータが読みだせないので、データが破壊されているように見えます。
Linuxベースの機器や、独自フォーマット利用する方式の楽器、パーティションテーブルの形式がPC/ATと異なるコンピューターに組み込む場合は、このバグを踏んでしまうことになり、正常に起動しないなどの問題が発生します。
さて、この問題を回避するためにいくつかの方法が編み出されました。
- カードを挿さずに電源投入し、カードを挿してからリセットする
- PC/ATのパーティションテーブルを模倣したものを作成する
…など。
でも、できることなら環境に依存せず、特別な手続きなしに任意の内容のカードを挿入した状態で電源投入時から正しく動いてほしいですよね。
調査
SD-IDE、SD-CFを含めFC1307Aのファームウェアにはいくつかのバージョンが存在することも知られており、バージョンによって細かな挙動に違いがありました。
分解してSPI Flashを取り外し、内容をダンプしてみます。
SPI Flashを読み書きする方法は、「SPI Flash RaspberryPi」で検索すると簡単な方法がありますので参考にしてみて下さい。また、SOP8用ICクリップを用いて基板から取り外さずに読み書きすることが可能でした。
確認できているFC1307Aのファームウェアの一覧
ATAデバイス名 | リビジョン | ファームウェア内文字列 | Flash型番 容量 | 確認されている搭載製品 |
---|---|---|---|---|
SINTECHI HighSpeed SD to CF Adapter V1.0 | Rev 1.2 | FC-1307 2012_07_19-BANK CF_V1.5B15 | Pm25LD512 512kbit | SD35VC0(黄色シルク印刷)、変換名人のSD-IDE 44ピンタイプ |
FC-1307 SD to CF Adapter V1.3 | Rev 1.3 | FC-1307 2012_10_29-BANK CF_V1.5B17 | FH25VQ40 4Mbit | TF-CFアダプタ(赤) |
FC-1307 SD to CF Adapter V1.4 | Rev 1.4 | FC-1307 2012_12_20-BANK CF_V1.5B18 | BY25D40A 4Mbit | SD-IDEアダプタ (TD-Linuxさんによる報告)、SD35VC0(白色シルク印刷)、最近購入した44ピンタイプ |
FC-1307 SD to CF Adapter V1.5 | Rev 1.5 | FC-1307 2015_10_16-BANK CF_V1.5B17 | FH25VQ40 4Mbit | SD-CFアダプタ(黒)、サンワサプライADR-SDCF1 |
(6/24 Flash容量、確認されている搭載製品を修正しました。)
(7/23 搭載製品を追加しました。)
512kbit、4MbitのFlashともに、先頭48KB(384kbit)しか使用していないようです。
ほかにも、FC1307Aを搭載しながらリムーバブルで使うことを想定したMisty Ghostというものが存在しますが、用途的にリムーバブルフラグがあると都合が悪いため今回は考慮しません。
手元のいくつかの環境で検証した結果、Rev1.5のものは前述の問題が発生しないことを確認できました。というわけで、問題のあるファームウェアを都合のいいものに置き換えてしまうという蛮行を思いついたのでした。
(6/24追記)ファームウェアをダンプできていない搭載製品はほかに下記のものがあります。
- iFlash (SD-CF、SD-ZIF、2SD-ZIF、4TF-ZIFタイプ)
FC1307Aを搭載しており、ATAデバイス名は独自のものになっているようです。チップ周りが樹脂で固められており、ファームウェアを読みだすには破壊的な方法で分解する必要がありそうです。
・SD-CFタイプの登場が2012/12/26
・Dualタイプの登場が2015/09/18
とのことで、これらは少なからずFC1307A Rev1.5の日付である2015/10/16より前から存在するので、時空をさかのぼっていなければ、iFlashはRev1.5のものより古いFC1307Aファームウェアをベースにしていると考えられます。 - imCort Design(2TF-ZIFタイプ)
iFlashと同様の目的で設計されたと思われるアダプタです。
発売日は不明ですが、Rockboxのチャットログによると、「根本的にはiFlashと同じで、broken everything」なのだそうで、こちらも新しいファームウェアが載っている望みは薄そうです。 - Arqamさんの情報によると、「複数のSDカードをJBOD構成で動作するのはRev 1.3のみ」とのことなので、複数SDカードに対応するアダプタはRev 1.3をベースにしている可能性があります。
シングルカードのアダプタしか所持していないため、この視点は抜けていました。(7/16追記)
小手調べ
手始めにRev 1.3のTF-CFアダプタ(赤)にRev 1.5のファームウェアを載せてみます。これは問題なく動きました。
実践
当初はSD-IDEにもRev 1.5のファームウェアを書き込んで、一件落着、という目論見であったのですが、SD-IDEにこのファームウェアを書き込んでも動かないのです。電源を入れてもだんまりで、ホストから見ても応答しません。
同じチップを使っているのになぜだ…そんなはずはない…ならばだ、回路を追いかけてSD-CFと同じ状態にしてやるまでだ。
というわけで調査した結果、下記の変更を基板に加えることにします。
- 基板上のSPI FlashにRev 1.5のファームウェアを書き込む
- 下記のピンがGNDに落ちているので、パターンカットする
- FC1307A 9pin (IOP0)
- FC1307A 13pin (IOP1)
U3 (STCA1) を取り外し、その6pinのランド =FC1307A 14pin (IOP2) をGNDに落とす
実は、この作業を2022年初頭に途中までやりかけた後、まる2年放置していたんですが、ピン配置の情報が入手できたため2年ぶりの雪辱が晴らすことができました。
電源ピンなのかIOピンなのかが判別できるだけでも、格段に解析難易度が変わりますね。
さて、パターンカットした箇所をルーペでよ~く確認して…OK、電源投入。
Accessが一瞬光った!動いた!!
SD-IDE(SD35VC0)の基板で、SD-CF Rev1.5のファームウェアが動作いたしました。
これで異常な挙動に悩まされることはなくなりそうです。
FAQ
- Rev 1.5のファームウェアはどこにありますか?
- まず、この記事を最後まで読んでみることをおすすめします
- 探しても見つからなければ、確認されている搭載製品の欄を参考に購入し、分解してROMを取り出すことで入手できます
- もし、一覧にないバージョン、搭載製品を見つけたらコメントいただけると嬉しいです
- 機器のアクセスランプが薄く点灯する、常に点灯するのですが?
- ホスト側のアクセスランプが5Vでプルアップされている場合、SD-IDEアダプタ内で39ピンが3.3Vでプルアップされているため、その差の1.7VでLEDが点灯してしまう場合があります
- アクセスランプの+側を3.3Vから取る
- アクセスランプをVfの大きいLED(白・青・紫)に替える
- SD-IDE基板上で39ピンに直列にLEDかダイオードを入れる
-
SD-IDE基板上で39ピンを5Vでプルアップする- 微点灯が収まらないからと過小な抵抗を挿入すると、ICに過大な電流が流れて破損するため、この方法は非推奨です。(7/8追記)
- 等で解消できると考えられます。ホスト側の回路との関係を見て適切に対応してください
- ホスト側のアクセスランプが5Vでプルアップされている場合、SD-IDEアダプタ内で39ピンが3.3Vでプルアップされているため、その差の1.7VでLEDが点灯してしまう場合があります
- 認識しているようですが、データが化けています…
- UDMA66以前のホストは基準電圧が5Vとなっていますが、FC1307Aは3.3Vで駆動されるため、チップセットによってはビットが落ちてしまうケースを確認しています
- 対処療法的ですが、SD-IDE基板上のレギュレータを3.5V程度のものに換える、レギュレータのGND端子に直列にダイオードを挟む等して、電圧を少し盛ってあげることで解決する場合があります
- Libretto SS1000において問題解消を確認しています
お土産
本日はお越しいただきありがとうございました。
お土産にFC1307A KiCAD用ライブラリをどうぞ。
FC-1307A.lib
番外編 改造ファームウェアをつくる
さて、汎用的に都合がよい状態を得ることができ、ひと段落ついたところですが、動作に癖のある特定の機種用に利用することを目的としている方もいらっしゃると思います。
Internet ArchiveにファームウェアをコレクションしていたAdam K氏より、特定のいくつかのモデルのHDDしか認識しない東芝T5200に対して、SD-IDEのファームウェアのモデル名を変更して対応したという事例を教えていただきました。
これに着想を得て、PC-98シリーズの内蔵IDEディスクの容量上限が543MBおよび4,351MBの機種で発生するシリンダ数計算のオーバーフローおよび、それに起因するハングアップを回避するファームウェアを作ることができないか試みるという、さらなる蛮行を重ねました。
結果、ネイティブHead/Sectorの値を、これらの機種が決め打ち設定する値である8/17とすることで、挿入したSDカードの容量に関わらず起動時のオーバーフローが回避できることがわかりました。
パッチ対象のファームウェアイメージ
FC-1307 2015_10_16-BANK CF_V1.5B17.bin 65,536byte CRC32=2F99F86C
該当の機種向けのパッチ。git apply
コマンドを使用して上記のファームウェアに適用します。
diff --git a/FC1307A_1.5.bin b/FC1307A_1.5.bin
index 7e3b8536b7735757a52cbd40ec9b17df5cae8fb2..9d9c20ef5900d0cfb801225aafda2787e6e616b0 100755
GIT binary patch
delta 84
zcmZo@U}<Pz+0dZP$HBnB;J_pZBtc;EMs1PFi?r()88$2G2nq}MI+vtoD+D;}T3Q$w
lC<MDqcCz2Y6r{JwVUjQ_M@4O!;O6PU={ihI&lfc`002?}7R~?w
delta 71
zcmZo@U}<Pz+0dZPC&0kK;J{=LBtc;EMs1PFi?r()SvD)`2ntVbv6r0eZNHhRN@bJ7
YBw<#8irO;!&C`R^b(qdPTh!110Eb=`NB{r;
(6/18更新:シリンダ値の割り算に使うH/S値の格納場所がわかったので、正しいシリンダ値が計算されるようにパッチを修正しました。これにより、4GB以下のカードを挿入したときに正しい容量で認識するようになります。)
32GBのMicroSDカードを使用した例
資料 および 参考文献
お困りの声
ソフトウェア的な対策
当記事を紹介して頂きました。ありがとうございます。
ファームウェア、回路図、資料
当記事を紹介して頂きました。ありがとうございます。
FC1307Aのカタログ(PDF)がダウンロードできます。
Discussion
コメント失礼致します。
git applyでpatchを当てようとすると
error: corrupt binary patch at line 11:
error: unrecognized input
最後の何も無い行が壊れていると表示されます(その行を削除すると10行目が壊れていると表示されます)
原因が皆目見当も付かないのですが、どうしたら良いでしょうか?
/opt/FC-1307/
の中に
FC-1307 2015_10_16-BANK CF_V1.5B17.bin FARM.PATCHが入っています。
改行コードもLFに指定して保存する等もしたのですが改善せず....
コメントありがとうございます。
git applyでパッチを適用する際の注意点ですが、
a/~
b/~
で指定するファイル名とパッチ対象のファイル名がすべて一致している必要があります以上の点を試してみてください。
ご返信ありがとうございます。
2週間程空いてしまいましたが進展致しましたのでコメント送らせていただきます。
patchファイル末尾に空白行を2行入れた所パッチに成功致しました。
その上でPC-9801USにてLBA_IDEを用いて128GBのSDカードを組み込んだのですが、
IPLwareを読み込み固定ディスク起動メニュー迄は行くのですがその先に進みません。
別のディスク(FD)よりアクセスしてみるとファイル表示等は正常にされるものの、
アプリケーションを起動するとハングしたりAbnormal Program terminationと表示されたりと
明らかに異常です。
FAQにある様にこれは電圧不足による化けなのでしょうか...?
パッチ適用、書き込みに成功したようで幸いです。
IPLwareが正常に実行され起動メニューが表示されているなら、データ化けは発生していないと考えられます。
もしデータ化けが発生していたら、IPLの起動中に異常が発生するか、IPLwareのロード中にチェックサムエラーが発生するはずです。
しかし、PC-9801USに128GBのストレージを搭載した方は今まであまりいないでしょうから、問題の切り分けが難しそうですね。
まずは先頭500MB程度が問題なく使えるかどうか確認してみてはいかがでしょうか。
現状報告です。
PC-9801USはLBA_IDE抜きですと問題なく動作致しました。
(FreeDOS(98)の場合はLBA_IDE入りでも正常に動作しました。
詳しくはりうさんのツイートをご参照お願いいたします。)
PC-9821Na7でもLBA_IDE付きで動作致しました。
今後これを超える様な内蔵固定ディスクインターフェース用のストレージは現れないと思います。
えむしてさんにはとても感謝してもしきれません、ありがとうございます。
質問等でなくてすみません。
かなり感動してます。
素晴らしい改造をされたことと、
情報を公開してくださったことに感謝です。
FC1307Aのアダプタは、諦めていました。
手持ちのものがいくつかあるので
公開して頂いた内容をもとに
色々やってみます。
かなり前に、
某chでFC1307使った際のリセット回避について
議論されてた方でしょうか?
海外の方の情報だと、レトロな固定CHS対応機種にも
ファーム改造でいけそうで、嬉しい。
このためにアカウント作りましたが、
また質問等させていただければと思います。
ありがとうございます。
2022年ごろまでの経緯はTwitter等に投稿しておりました。遡ってみたところ、2019年秋ごろにFC1307A搭載SD-CFアダプタとSD-IDE基板を購入したのがきっかけで、2022年1月にファームウェアの載せ替えを試み、SD-CFアダプタは解決し、SD-IDE基板はお蔵入りとなっていたものを、今回再びチャレンジしてみた次第です。
せっかくの機会なので、ぜひZennに記事を作成してみてください。気軽に書けるスクラップという投稿スタイルもあるので、小さなことから技術的交流が図れるのではないかと考えています。よろしくお願いします。
そうなのですね。。(^^;
多分、Xの検索もしてましたので
みてたと思うのですが。。😅
ファームのスワップとか、やはり
視点がw
海外の方で、ファーム解析を
してたのはみてましたが、
如何せんチップの情報が探せなくて、
吸出し機器も持っておらず
まぁ、自分のレベルでは
手詰まりでした。で二年放置。。(^^;
とにかく、今から再始動して見ます😁