[root@ns2 root]# tcpdump -i br0 igmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 20:18:27.106738 IP 192.168.25.108 > 224.0.0.251: igmp v2 report 224.0.0.251 20:35:58.102648 IP 192.168.25.108 > ALL-ROUTERS.MCAST.NET: igmp leave 224.0.0.251 20:36:12.592447 IP 192.168.25.108 > 224.0.0.251: igmp v2 report 224.0.0.251朝から眺めててこの1件だけだったりするし、uClinux/H8でigmpは要らないだろ~ということで、kernelのソースからの削除作業にいつか挑戦したいところ。少なくとも20kbくらいは小さくなりそうだし(´ー`)。しかし結構 IPv4のkernel中に根深く(ip_mc_* な関数として)埋まっているので単純にリンクしないようにするだけでは外せないのが辛いところ。
ls -lR |grep '.o$'|sort -n --key=5等で適当に *.oのサイズと名前を眺めつつ、これなくても大丈夫じゃないの?というのを削り落とし。で procfsステ(;´Д`)。procfsとかオイラが小学校入った頃には無かったと思うし、今の小学生は過保護で遺憾…というわけでもないんですが、ioctl叩いたり kernel直覗きで拾えるならイランだろ~どうせ psも netstatも入れないんだし(予定)…とか。
-rwxr-xr-x 1 root root 1073382 Mar 2 22:53 linux -rwxr-xr-x 1 root root 679440 Mar 2 22:53 linux.binさっきより30KB程度小さくなったかなヽ(´ー`)ノ他にも igmp.oとか要らなさそうなのが在るのでコレも追い出し予定。贅沢は敵(´ー`)なのです。
・・・略 rm -f crypto.o h8300-linux-elf-ar rcs crypto.o make[2]: Leaving directory `/usr/local/src/linux-2.4.32/crypto' make[1]: Leaving directory `/usr/local/src/linux-2.4.32/crypto' h8300-linux-elf-ld -T arch/h8300/platform/h8300h/aki3068net/ram.ld arch/h8300/platform/h8300h/aki3068net/crt0_ram.o init/main.o init/version.o init/do_mounts.o \ --start-group \ arch/h8300/kernel/kernel.o arch/h8300/mm/mm.o arch/h8300/platform/h8300h/platform.o arch/h8300/platform/h8300h/aki3068net/aki3068net.o kernel/kernel.o mmnommu/mmnommu.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/serial/serial.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o \ net/network.o \ /usr/local/src/linux-2.4.32/lib/lib.a arch/h8300/lib/lib.a /usr/local/lib/gcc/h8300-linux-elf/4.0.2/h8300h/int32/libgcc.a \ --end-group \ -o linux h8300-linux-elf-nm linux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map h8300-linux-elf-objcopy -O binary linux linux.bin [root@FS1 linux-2.4.32]$ gzip -9 < linux.bin > linux.bin.gz [root@FS1 linux-2.4.32]$ ls -l linux.bin* -rwxr-xr-x 1 root root 771340 Feb 27 10:19 linux.bin -rw-r--r-- 1 root root 327285 Feb 27 10:19 linux.bin.gz [root@FS1 linux-2.4.32]$ということで一応バイナリっぽいのが出来るところまで。なぜ gcc4系でコンパイルしてみたかというと、やはりサイズの問題が大きいわけです。また512KBの中に押し込もうという考えですから、小さければ小さいほど宜しいのです(´ー`)
openwinceのJTAG toolからjtag-0.5.1をDLしてコンパイル。
include-0.3.1なども必要なので同じくDLして./configureして make、make installしたり。
で、motorolaからMPC8241やMPC8245用のBSDLファイルがDL可能なので、コレを併用して遊べないかな?と考えたわけで…。bsdl2jtagってコマンド使えばJTAG tool用のファイル吐いてくれそうだし…ヽ(´ー`)ノ
…
…
…
で、結果的には敗北(;´Д`)。bsdl2jtagに通しても何も吐きませんでした…まあbsdl2jtagのソース読んで目が点になるっつか、コレ書き直すだけで一仕事だなっつか、今時それはナイダロっつか…パーサとしてどうか?と思う作りだったので、しばらく静観する予定。
MPC8241搭載の玄箱用にWigglerで戦ってみていたわけですが、あまり芳しい結果は得られず…回路がわるいんじゃないの?という話で吊ってみたり下げてみたりと色々試しましたが敗北(;´Д`)
で、前々からWigglerだとMPC8245でもPPC405でも時々コマンドがすっぽ抜けるので、もう少しまともなJTAG買った方が…(って、Wigglerなんてオモチャに近いわけですが…)という思いもあってAmontec low cost ARM Debug and JTAG interfaceから Chameleon POD購入ヽ(´ー`)ノ送料込みで225EURO。また会計士さんから烈火のごとく怒られますね。
Chameleon PODと謎基板
Wigglerがオモチャか?という点では、Chameleon PODもあまり変わらないわけですし、「他社製品に化ける」という点ではフクヨカに黒く灰色の臭いもするわけですが…しかもARM用としてうたってませんしね。ARM用のWiggler互換JTAGならアチコチで回路図が公開されてたり販売されてたりするわけで…もしかして黙認してますか?まあ、ちゃんとした開発部署で、ちゃんとした開発するならこんなコンパチケーブル使って…というのは信頼性を考えるとアレなのですが。
で、6/29に実は注文済みで、スイスからTNTつかって空輸で成田、そっから西部運輸(トラッキング問合せができない)で1weekほどかけて到着いたしました。物凄くデカイ箱できた割には中身はホームページを印刷した紙2枚ほどと、ケーブル本体をプチプチで包んだ程度でした。回路は、手半田ぽいですね(;´Д`)
で、ヤハリARM用なのですがMPC8245で動作するか?というとヤハリ色々仕掛けがありまして、紆余曲折とかAmontecの某氏とかとやり取りしながらChameleon POD用のファーム貰ったりしつつ回路弄ってたら動作しましたヽ(´ー`)ノワライ
ARM用のファームでもRESET以外は何とか動作してたんですが、おそらく一部が論理が逆になってる?とかアノpinはコノpinとは接続しないの?とかあって数時間ほど弄ってたわけです。で、MPC8241ではどうか?というと動作しませんでした。Wigglerの時と同じくRESET、HALT、GO(と一部STEPも)だけ。REGとCPUが使えないので、命令単位で追えませんし、各種メモリ参照用のコマンドも全滅…これはあきませんね(;´Д`)
MPC8245については勝算はあったんですけどね。ウチにはARM用も8245用も403用もあるので…MPC8241について OCD Commanderでは本当に対応していないのか?というのを検証する為に MetroWerksのPPC関連開発環境の評価版入手して試し予定。
# 回路図とか詳細はとりあえず伏せときます(;´Д`)
開発環境他、現状でのベストチョイスは…
・binutils-2.13.2
・gcc-3.3.2+patch
・elf2flt
・genromfs
・uClibc-0.9.24+patch(scanf他)
・busybox-1.00-pre5+patch(h8-uClinux対応)
ではないかねえ。
また、kernelは
linux-2.4.22+uclinux-2.4.22-uc0.diff と思われます(と、書き残し)
NFS無しでこの位は動作するようになりました(しかし辿り付くまでに地獄のような苦しみが…)
eth0: NE1000 found at 0x200000, using IRQ 17. Blkmem copyright 1998,1999 D. Jeff Dionne Blkmem copyright 1998 Kenneth Albanowski Blkmem 1 disk images: 0: 4CF984-504983 [VIRTUAL 4CF984-504983] (RO) NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 512 bind 1024) VFS: Mounted root (romfs filesystem) readonly. Freeing unused kernel memory: 24k freed (0x4ac000 - 0x4b1000) 誓# hostname aaaa # sbin/ifconfig eth0 10.0.0.110 # ls|./smtpclient -S 10.0.0.1 -f mine@lancard.com mine@lancard.com SMTPclient: aaaa: unknown host # cat /etc/hosts 10.0.0.110 H83069F # hostname H83069F # ls|./smtpclient -S 10.0.0.1 -f mine@lancard.com mine@lancard.com #
ちなみに busyboxでサポートさせたコマンドは
# ./busybox BusyBox v1.00-pre5 (2003.12.31-08:19+0000) multi-call binary Usage: busybox [function] [arguments]... or: [function] [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use, and BusyBox will act like whatever it was invoked as. Currently defined functions: busybox, cat, echo, hostname, ifconfig, ls, mount, mv, route #
これだけです。initとshもありませんがshはH8MAXのから借用しております。busybox自体のサイズがでかくなると、コマンドごとにその分のメモリ容量を取るわけですから、常駐するものは小さく個別に作成するのが良いようです。すでに数十KBのメモリを争う戦いになっております(わらい)
先日から大はまりの事柄があって、これが解決しないとある仕事が頓挫して多方面に大迷惑…(すでにかなり迷惑かけてるんですが)だったのですが、なんとか先ほど解決… gcc-3.2.3で手元にあるh8-uClinuxのkernel作ると /proc FS周りにかなり異常な動作が見られたのですが、gcc-3.3.2とbinutils-2.13.2の組み合わせにて現象再現しなくなり…
# cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packe ts errs drop fifo colls carrier compressed lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
とかの出力が延々ループして終わらず…つまり ifconfigとか使えなくてアドレス設定が出来ないという珍現象に悩まされておりました。アドレス設定が出来ませんから、smtpclientとかでアレするのも出来ず…。 ということで、次の作業をバリバリ進めたり
binutils(2.12.1, 2.13, 2.13.1, 2.13.2, 2.14)と gcc-3.3.2の組み合わせで h8300-elf- なクロス環境作成調査。というのも手元でSegmentation Fault吐く elf2fltが作成されることがあって、嵌りまくって気持ち悪かったので…やはりツブしておきたいという流れ。
結論:binutils 2.12.1 ○ 2.13 ○ 2.13.1 ○ 2.13.2 ○ 2.14 ×
2.14との組み合わせの場合のみ Segmentation Faultとなり、それ以外の場合はelf形式から同一サイズの bFLTバイナリへ変換成功。2.14ではなぜそのようになるか? は未調査。 こういうバルクなテストやるときは処理が高速なマシンが欲しくなりますな。
#!/bin/sh rm -rf binutils-2.14 tar xzvf binutils-2.14.tar.bz2 cd binutils-2.14 ./configure --target=h8300-elf make make install cp bfd/libbfd.a /usr/local/lib/ cd .. rm -rf gcc-3.3.2 tar xzvf gcc-3.3.2.tar.gz && cd gcc-3.3.2 && patch -p1 < ../gcc.diff ./configure --target=h8300-elf --enable-languages='c,c++' make make install cd .. h8300-elf-gcc -v rm -rf elf2flt tar xzvf elf2flt.20031229.tgz cd elf2flt zcat ../elf2flt.h8300helf.20031229.diff.gz | patch -p0 ./configure --target=h8300-elf \ --with-libbfd=/usr/local/lib/libbfd.a \ --with-libiberty=/usr/local/lib/libiberty.a \ --with-bfd-include-dir=/usr/local/include \ --with-binutils-include-dir=../binutils-2.14/include make make install
やっとやっとやっとマトモに動作する環境までたどり着きましたよ。
苦節数ヶ月っつか、何にハマってたんだろうヽ(´ー`)ノ謎スギ。
uClinux-h8な ML辺りとか プロジェクト: uClinux-H8方面あたりに
少しずつ成果は流さないと…というかイヤでもここ数日で各種ドキュメントを
ギッチリガッチリ書かないといけないわけで…あああああ。
とりあえず busyboxまでは かなり素直に走れます。はい
先日から動作するシナイと騒いでいたWIGGLERの件一旦決着。e-mail書き書きしてやり取りいたしました>Macraigor Systemsの人と
現在所有のWIGGLER
・IBM PPC 4xx (WPPC4xx)
・Motorola MPC 603e,7xx,82xx (WNPJ-COP)
・Intel XScale (WNPJ-ARM-20)
で、実は WPPC4xxは 403は対応するけど405は対応しない。Raven は対応している?という回答。またMPC72xxについては対応する製品を現在は出していないなど回答ありました。どう見ても 4xxだと 405も含まれそうに思われますので「けどね、言わせて貰うと ドレがドレに対応してるかもっと明確にさせた方がいいと思うんだよねー」(But, I have a bone to pick, you must show more clearly that ~)とヒトコト入れたり。
安いので、405用送り返すか?」に対しては「403板も買うからいいよ」と回答。勉強にもなったし。
ちなみに、MPC8245と 405GPだと 11番と13番ピンが入れ替わってるので「動作しないはずなんだけど、動作したということならソレは良かったね」と言われたり。まあ、FlashROMいじれない以外はそう強く問題はありませんでしたとさ。ワライ
とりあえず、ARM入りのBRL-04AをJUNK箱からみつけたので、分解~SAMSUNG S3C4510B搭載ですね。わざわざARMと書いてあります。
JTAGのpinoutらしきパターンが見えたので、スルーホールのハンダを吸い取ってからピンヘッダをつけました。もちろんCPUのpinとパターンの結果、ARM系の14pinのJTAG端子というのはわかっております。
XScale?ぬぬ
で、まあ ゴニョゴニョとバラシテ、14pinの端子くくりつけて接続~WIGGLER発進~撃沈。どうも上手く動作しないようですね。原因は不明。TVCCに5V近く出てるのも確認してますし、他のWIGGLERでも状況変わらず(というか、~用のWIGGLERと~用のWIGGLERって中身ほとんど同じだな)。
疲れたので0400頃撤収
JTAGでGPIO周辺叩いてLED眺めたので防備録
LONG $ef600700 = $00000000 ・・・ 全点灯
LONG $ef600700 = $00080000 ・・・ 1消灯
LONG $ef600700 = $00040000 ・・・ 2消灯
LONG $ef600700 = $00020000 ・・・ 4消灯
./build.sh -m evbppc tools2003/09/01時点、cvsで取ってきたNetBSD-currentはLinux環境上では stat.cの構築でエラーが出ますので、とりあえず場当たり的対応
[admin@DURON-PC src]$ cvs diff -u tools/stat/../../usr.bin/stat/stat.c Index: tools/stat/../../usr.bin/stat/stat.c =================================================================== RCS file: /cvsroot/src/usr.bin/stat/stat.c,v retrieving revision 1.13 diff -u -r1.13 stat.c --- tools/stat/../../usr.bin/stat/stat.c 2003/07/25 03:21:17 1.13 +++ tools/stat/../../usr.bin/stat/stat.c 2003/09/03 21:50:52 @@ -89,6 +89,10 @@ #define st_atimespec st_atim #define st_ctimespec st_ctim #define st_mtimespec st_mtim +#else +#define st_atimespec st_atime +#define st_ctimespec st_ctime +#define st_mtimespec st_mtime #endif /* HAVE_STRUCT_STAT_ST_ATIM */ #define DEF_FORMAT \さらに
./build.sh -m evbppc kernel=WALNUT ; ./imagemake素直に動作するわけもありませんので、GPIO経由で LEDを光らせるコード等追加しつつ停止位置を推測していきます…どうもinitppcまでたどり着いていない感じなので、いろいろ見回して walnut_start.Sの途中でどこか知らないところに飛んでいるのを検出。openbiosを操作しているコードが怪しそうなので#if 0 ~ #endifで囲んだりしながら initppcの先頭に仕掛けた LED点灯コードの動作を確認~。
先日から何度もハマリ負けが続いてたWIGGLERですが、405GP用ではなくMotorora MPC8245用も注文しておりました。で、本日ソレが届いたので早速開封~
輸入品~ 中身はシンプルな14pin
念のためPINoutは確認しましたが問題ない様子。某社のMPC8245ボードに接続し、早速動作試してみました。
RESET!GO!HALT! STATUS!CPU!REGS! 自由自在ですよ。CPUが停止します動作しますレジスタ見れますメモリも、値も弄ってI/Oも直に叩けます。こりゃ良いです快適(ワライ)
ところで、PINout的には同一の設計の某社のIBM PPC405GPボードに接続を試してみました。
405GP停止中~☆
バッチリです。停まる、走る、全く問題ありません。ためしに一旦HALTして GPIOのアドレスに
LONG $EF600700=0
LONG $EF600700=$ffffffff
してみましたが、LEDが消灯/点灯してます。バッチリです。
コレで自宅に JTAGデバッガが2個になりました。もう少し落ち着いたら gdbからの使用方法など入れていきます~♪
先日から弄ってる WIGGLERについて HW_Supportとやり取りをしてチェック方法など伺ったので調査…しかしまたも敗北したわけです。
起動と設定 起動後にRESETボタン押下
さっぱり target板を検出できていない感じです。パラレルポートを EPPからBi-directional(Standard)に変更しても変わらず… HW_supportの方から RAVEN用のcheckerを使ってみることを薦められたので、実行してみると
RAVEN TESTER
WIGGLER自体は検出されている感じです。…謎
結局 Flash programmerも上手く動作していないため、この件についてはまたHW_supportの方へオアズケ… PPC4xx、MPC8245他の開発環境構築の苦難は続く…
ただ、WIGGLER接続時と非接続時でボードの動作が異なる(haltがかかったりかからなかったり)なので、何らかのミスコンフィグされたハードウェアが届いたのではないかとか…予想
Macraigor Systems LLCの WIGGLER (IBM PowerPC 4xx用)を Windows 2000から試用しているがイマイチ動作が異常。ということでHW_Supportへ問合せを行ってはみたが、cable disconnect等の targetがおかしい?とも思えるエラー続出で切り分け出来ず。Windows95・98で再挑戦予定。
謎な中身
GALが1本にbus bufferが1本と非常にシンプルな構成な上に、target板の回路図とも見比べて別にレベル的な問題もなさそうなので、やはりOSの問題かなWindows2000 とか。
少なくとも OCD commanderと FlashWriterが使えるだけでも 非常に有用なんだけど。