2010年07月16日

kozos: lpc2388版を試した時のメモ

kozos: lpc2388版を試した時のメモ
2010年7月のてきとーな日記 
http://www.bi.a.u-tokyo.ac.jp/~uaa/gomitext/2010/201007.html

上の方(かた)がkozosをLPC2388に移植していて、
公開されていた
kozos-lpc2388-20100701.tar.gz
というソース群をいただいた。
自分が移植しようとすると「4重苦」くらいで
挫折しそうな気もします。(^^;

「kozos本」買おうかなぁ。

で、
IF誌付録のLPC2388基板も死蔵ぎみなので試してみた。

コンパイルして焼くだけなので簡単かと思ったが意外にハマッたので
メモしておく。
ただし上記ファイル群がどうのということではなく
自分の知識や環境群のせいだったのだ。

1, cygwinコンソール上でコンパイル。←OK
  「Makefile」中のarm-elf-gccへのパスを変更するだけだった。
   PREFIX変数を指定すれば「Makefile」の変更は必要ない。
$ make -e PREFIX=/usr/local/arm-tools
例えば上のようにarm-elf-gccのありかの一つ上のフォルダを    指定すればよい。 (以下、arm-elf-gcc等を「gcc」と書いたりする) 次、 2, cygwinはあまり好きじゃないので (オイ  MS-DOSコマンドラインでコンパイル。 ここからいきなりハマる。 *「startup.S」と「startup.s」 ? * これの違いを知らなかったのがそもそも解決を遅らせたのだった。 両方とも「アセンブラ」ファイルだけど、「*.S」(ラージエス) の方は 「C言語のディレクティブ群」が使えることを意味する。 例えばアセンブラファイル中で #include "anothor.h" /* comment */ #define FOOBAR 5 // comment 等の命令群が使えたりするのだった。 で、この「C言語のディレクティブ群」を含んだ「*.S」ファイルは 必ず「gccに喰わせる」のだ。 1)○: gcc -c startup.S -o startup.o   これは正しい。 2)△: gcc -c startup.s -o startup.o   これも正しいけど、「C言語のディレクティブ」を含んではいけない。 3)×: as startup.S -o startup.o   「C言語のディレクティブ」を含まないなら○   まぎらわしい 4)○: as startup.s -o startup.o   これは普通。 で、状況を見る限り gccは拡張子が「*.S」なら事前に「C言語のプリプロセッサ」相当のものを通す。 「*.s」ならそのままアセンブルするようだ。 要は、gccは「拡張子の大文字、小文字の違いだけ」を見て 「プリプロセス」するかどうかを決め打ちしているようだ。 というか、そういう仕様の様だ(^^; *gnu make にやられた* DOS窓で使うgnu make(ぐニュー・メイク)「make.exe」は 「WinAVR」付属の物を使用している。 (以下、winavr-makeと略記) 1年以上使用したのでそれなりに「信頼」をおいていた。 が、ここに来て「裏切られた」。 以上。 (オイ ある意味、よく頑張ったのかもしれない。 問題点: winavr-makeは 拡張子の「大文字、小文字の区別に失敗する」ようだ。 メイクルール(サフィックス・ルールとか暗黙のルール等)に従って 最終的に「期待」される正しいコマンドが
gcc -c startup.S -o startup.o
とすると、winavr-makeは「誤って」
gcc -c startup.s -o startup.o
を実行してしまうのだった。 上述の内容からこれはアセンブルエラーになるのだ。 「startup.s」というファイルは存在しないが結果的には プリプロセスしないまま「startup.S」をアセンブルしてしまうのだ。 「make.exeが原因」であるのに気づくのに時間がかかった。 orz 暗黙系のルールに頼らず直接「startup.S」を記述するようなメイク行に 変更すれば問題なくアセンブルできるが、なにやら大文字、小文字についての 「Warning」が出ていた。 *より良い「gnu make」探し (cygwin以外で)* cygwinはなるべく避ける方向なので「mingw系」の物に限る。 といっても、高い信頼性を獲得するにはある程度長期間使ってみないと 分からないわけで。。。 そういうわけで、ひとまず上記の「問題」が最低限起きない「make.exe」を探す。 問題が起きない候補: 1,「CodeSourcery g++ Lite for ARM」付属の「cs-make.exe」を    「make.exe」にリネームして使う。 2,「MSYS-1.0.xx系」のbinフォルダにパスを通して「make.exe」と    「Unixツールズ」も含めて使う。 で、「MSYS」を使ってみることにした。 今まではWinAVRの「utils\bin」フォルダにパスを通して 「make + Unixツールズ」として使っていたがそれをやめて 「msys\1.0\bin」にパスを通してMS-DOSコマンドラインから使ってみること にした。 「MSYS:Unixツールズ」についてはまた別ページで調査隊を送ることにした。 ちなみに、 「LPCxpresso」をインストールすると「Unixツールズ」として「MSYS」が インストールされるが パスは通さないので他に影響を与えないようになっている。 「MSYS」は、 http://sourceforge.net/projects/mingw/files/MSYS/ 上のページの 「All Files」-「MSYS」-「BaseSystem」-「msys-1.0.11」-「MSYS-1.0.11.exe」 がインストーラ。 うちは ちょい古めの「MSYS-1.0.10.exe」を使っている。 (特に意味はない) で、 kozosはコンパイルできたのだ。Windows版の Sourcery G++ Lite 2010q1-188 をMS-DOSコマンドラインで実行した。 arm-none-eabi-gccのWindows版は http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite EABIのところから取得できる。 * TeraTermのXmodemにハマる * kozosの実行ファイルをブートローダ経由でXmodemを使ってARMのSRAMに転送するんだが、 TeraTermのXmodemが無言になって動かないのだった。 orz TeraTermはバージョン「4.xx」だったのを最新の「4.66」にしてみたがダメだった。 orz orz Windows付属の「ハイパーターミナル」にしてみるとあっさり転送できた。 ググると同様なことを書いている人がいたのでひとまず 「こーゆーもん」とあきらめる。 TeraTermでなぜだめかはそのうちかな。 (オ〜〜イ *WinAVRのutils/binもMSYSツールズだった (^^;* なんか大きく見落としていたが WinAVRのutils/binフォルダをよく見るとこれらも「MSYSツールズ」だった。 ということでやはり 「MSYSとは?」 「Unixツールズとは?」 「MSYSツールズとは?」 などをもう少し調査するしかないな。 自分がほしいのは、cygwinと無関係な、 でもなるべく必要最小限のUnixツールズをUnix風に使える、 高信頼のMS-DOS版の make.exeと必要最小限のUnixツールズ がほしいのだった。 別ブログに続くかも。
posted by Copyright (C) avrin All Rights Reserved. at 23:02| Comment(10) | TrackBack(0) | ARM系 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
audinさん、こんにちは。
kozosって何ですか何でそんな面白いものをご存知なんですか?
μCLinuxよりももっと小さいOSなんですよね?
LPC2388とかのFlash(128kとか)でも動くんですか?

すみません質問攻撃ばっかりで。
Posted by iruka at 2010年07月20日 14:50
こんばんわ
kozos自体をまだほとんど知らないので詳細は
作者のページを参照したほうが良いと思います。
kozosはOSそのものを作る学習目的の色合いが
強い感じです。

lpc2388版をコンパイルしたらARMコードで6.5Kバイトくらいでした。どんな機能が使えるかの詳細は未確認です。
タイマーベースの周期タスクサービスは未実装
でした。(kozos作者のページには実装例があります)
現状ではlpc2336のRAMに転送して実行するようになっています。

uCLinuxはググってみると10年前のソースしか
ないような感じでした。
linuxなら結構巨大なんじゃないでしょうか。
(予想です)
Posted by audin at 2010年07月21日 20:54
uCLinuxは仮想記憶を持たないCPU用の組み込みLinuxです。
H8とかARM-v7以下とかCortex-Rとか用です。
(結局H8専用なのか・・・)

カーネルサイズはでかいです。(普通のLinuxとさほど変わらない)

kozos小さすぎ。(STM32のブートローダー:12kより小さい)
Posted by iruka at 2010年07月21日 22:50
…(あまりにも嬉しくて声が出ない)。
楽しんで頂ければ、幸いです。
Posted by ささのたかよし at 2010年08月24日 22:34
>ささのさん

はじめましてirukaです。

最近ARM(Cortex-M3)に嵌ってます。
LPC2388じゃなくて、STM32かLPC1343版って
作れませんかねぇ・。

ARMって、日本じゃ流行らないんでしょうか。

ttp://hp.vector.co.jp/authors/VA000177/html/ARM.html

とりあえず自分の中では(PICやAVRより)流行ってます。
Posted by iruka at 2010年08月24日 23:07
お邪魔します。

手元にLPC1114(Cortex-M0)を載せたLPCExpressoがありますが、
全部Windows上でやるのかあということで放り投げたままの
状態だったりします。

#Eclipseよく分からないんです

やっぱりCortex-M0よりM3の方が良いでしょうか?
Posted by ささのたかよし at 2010年08月24日 23:34
>全部Windows上でやるのかあ

一応ビルドはどっちのマシンでも出来ますけれど
USBデバイスを繋ぐ端末はたいていWindowsなんです
(だってLinuxの場合ドライバーとかlibhidとか面倒なんで)

ソース編集はLinuxとWin半々でやってます。
LPC1114と1343ではFlashとSRAMサイズは同じ
ですがUSBの有無が違うようです。
Posted by iruka at 2010年08月25日 11:22
こんばんわ audinです。
LPCXpressoは9月末ごろにLinux対応に
なるそうです。
ttp://knowledgebase.nxp.com/showthread.php?t=623

Cortex-M0はARMによればアセンブラ指向の8ビット
技術者向けに命令数を激減させたそうです。
真の8ビットキラーはCortex-M0という点で興味深いです。
そのうちCortex-M0も買ってみます。
Posted by audin at 2010年08月26日 22:28
audinさん、こんにちは。
>Cortex-M0はARMによればアセンブラ指向の8ビット
>技術者向けに命令数を激減させたそうです。

一応Cortex-MシリーズはThumb2命令セットのみ
が実装されていて、M0とM3の差異はほんの
わずかです。(M3は単なる後継品種?)
命令数を激減というのは、おそらくARMの32bit命令
を全部ばっさり切り捨ててthumbだけにした、
という意味だと思います。

(M3にはmovtが追加された程度らしい)
M1はFPGA向けマクロだそうです。
Posted by iruka at 2010年08月27日 09:30
手持ちのLPCExpresso(LPC1114)を二つに割って、
こんな風にUSBシリアルを付けてみようかと考えております。

ttp://ecrafts.g.hatena.ne.jp/Lynx-EyED/20100810

KOZOS側でもシリアルを使っているため、
LPC-Linkだけではちょっと厳しいのかなというのが理由です
(LPCExpressoの流儀を知らないだけかもしれませんが…)。

#lpc21ispはhackする方向で。

Cortex-M0の仕様書は、仕事場の行き帰りの中の電車の中で
簡単に目を通しています。
…8bitキラーの素質ありますね、これ。
Posted by ささのたかよし at 2010年08月28日 12:07
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック