dingux外伝 終わり

あめりあです。
シリアル受信成功しました。
原因はRTS/CTS配線でした。何故ならば、その2配線をコネクタから外したところ動作したので。そもそも制御線なんて不要なはずなのに何故に配線されているの？という疑問から、あーこのレベルコンバータてスイッチングしてTTL変換しているのか！と学習(QC-IDてやたらコイルがあるんでトランス的(アナログ回路かい！)な意味合いで考えていた)し、そこから手当たり次第にキーワード検索し、もはや絶滅寸前のQV-10自作リンクケーブルページを掘り当て、そこの回路図を読む限りDTRだけで事が足りると分かり、それでもカシオ回路とは違う訳で、うーん、カシオ回路の意図を汲まないとなぁ。。と本気でRS-232C仕様と回路を追い始めたのですが、ダメ！こゆのヲタがするもの！と訳の分からない面倒臭がりカミュが出現し、へいゆー、RTS/CTS外しちゃいなよと囁かれぶっこ抜いたところ動作。もう動いたら原理とかどうでもいいや(多分RTSは関係なくてCTSが送信不可状態とみなされて動作していなかったぽいような。。ちゅかシリアルコントローラを制御しておくのが前提なんだろうなカシオ回路)。うへへ。
結局のところ、CMOS/RS232CのTTLコンバータて4つの端子(RxD,TxD,DTR,GND)だけで実現出来るのに、max系チップとか別電源確保しなくちゃならず、どうしてこゆの使うんだろ？という疑問も湧いたんだけど(スペースの問題とか通信速度の問題とかかな)、もういいや。

オリジナルファームのデバッグログ

NAND Booting...ECD755B6..
loader size = 0x00051670
000000E4:1...
OK
NAND Loading...
get ccpmp_config ok!!!
ccpmp_config.firmware_name = A320.HXF. ccpmp_config.update_key = 123, ccpmp_config.lcm.width = 320, ccpmp_config.lcm.height = 240.
loader normal mode...
Creating ftl device...
id:EC D7 55 B6 78
id:00 00 00 00 00
id:00 00 00 00 00
id:00 00 00 00 00
OK.
usb_connect = 0
into lcd_init.
loader -- into lcd_init.
into init_lcd_gpio.
out init_lcd_gpio.
loader -- init_lcd_gpio ok.
into Init_LCM_FAIR_ILI9331_320_240!!!
out Init_LCM_FAIR_ILI9331_320_240!!!
loader -- init_lcd_register ok.
loader -- out lcd_init.
Start decode...
OK 153602.
out lcd_init.
get_lcd_brightness -- value = 1.
00002C25:1.00002C29:1.00002C35:1.00002C44:1.00002C4D:1.00002C68:1.00000514:1.00000530:1.00000568:1.000005F5:1.00000640:1.len is 0x 500000
os_len = 0x 23af68. checksum = 0x0a2d458f.
1 - ret = 0
2 - ret = 1
Run image...

c_main enter------!!
kseg init OK!
new loader, system config ok!
intc init OK!
intc lib OK!

the os is start

stage1のデバッグログも無事受信。既存はパラメタ出力だけでしたので適当に仕込みました。

stage2はデバッグログ受信が出来ないちゅうより、走ってないぽい。c_mainエンタ直後にデバッグログ仕込んだけど音沙汰がないちゅうことは、そもそもc_mainにジャンプしていないという結論。スタートアップルーチンを読む限りは正しくジャンプしているし、ロード先アドレスからstage2のサイズ分バルクリードしてベリファイも実施しているので、怪しむべきはSTAGE2_PROG_STARTのベンダリクエスト。マップファイル見てもロードアドレスから_startがマップされているし。BOOT ROMがRAM展開しているのならば(よく考えてみるとstage1でramを初期化するのでBOOT ROMはRAM展開するはずもないし、RAMだって必須デバイスではないので展開するはずがないですね)、もしやstage2ロードしたことで上書きしてる？と心配したが、ベリファイ時のバルク操作も効いてるしSTAGE2_PROG_STARTのリクエストも正常復帰しているため、デバイス側でハンドリングされているのは確実な模様。そもそも、STAGE1_PROG_STARTとSTAGE2_PROG_STARTで二つのベンダリクエストを用意していること自体がきもい。何かしらトリックがあるはず。stage2のリクエストハンドラと既存のハンドラと実装が同じならば解析する意味もあるんだけどな。。STAGE2_PROG_START前のキャッシュフラッシュもなんちゅうか臭う。そもそも、stage1と2を分ける必要性さえ理解不能であるため、かなり詰み気味。

あ、そうそう、usb boot時のデバッグログが受信出来なかった理由ですが、use_uart=1にしていたのが原因です。てっきり使用する(1)使用しない(0)と思い込んでましたが、実際はUARTポートがjz4740は0と1の2ポート存在し、そのどちらを使うかの指定でした。一昨日半田したのはポート0なので、ここはuse_uart=0にすべきでした。

んー。
完全に詰んだ。
初心に戻って文献でも読みます。
デバッグログ受信は完了しましたので外伝はこれにて終了っす！