本人から今日は帰りませんと電話がありました。
まぁ、昼まで使い物にならず。昼からもだけど。まぁ、ビールだけだったのでかなりマシですね。ホッピーで泥酔すると一日復活できないからなー。
tsarmベースのkernelをさっそく書き込んでみる。
なんか書き込みソフトがpanicとかダイアログ出しましたよ。
サイズが大きすぎるのかなぁ、と思ってnetbsd.binをgzipして書き込んでみると成功。
ブートさせてみるとちゃんとUncompressしてくれるみたい。
しかし、うんともすんともいわない。
とりあえず、armadillo9_start.Sをすぎて、armadillo9_machdep.cのinitarm()に入っていたら、すぐにconsinit()が呼ばれてシリアルが初期化されるので、何らかのメッセージが表示されるはずである。
ということで、armadillo9_start.Sの中で死んでいるか、それすらもできていないということになるだろう。
シリアルが使えないとしたらLEDデバッグやbeepデバッグをすることになるのかなぁ。
ってことで、ハードウェアマニュアルを読んでみると29ページにLED (D1)というのがあって、GPIO Port Eに接続されたLEDがあるらしい。
こいつはhermitというモニタプログラムが起動しているときには点灯しているが、kernelとuserlandを展開後して、kernelへ制御をうつす時に消灯している。
なので、このLEDを点灯させることができれば、どこまで実行されているかを知ることができるんじゃないかと思ってGPIO Port Eのアドレスを直接叩く方法を考える。
OBS266でLEDを直接叩いたときは、特定のアドレスに値を代入するという方法を教えてもらったので、それに挑戦。
たしか、こんな感じで書くのだった。
*(volatile int *)0xef600700 = ~0;
GPIO Port EてことはEP93XX_GPIO_PEDRに何か書いてやれば点灯するのかな。
EP93XX_GPIO_PEDRは次の三つのアドレスの和になるはず。
ということで、0x80840020に0xffあたりを書いてあげればLEDが点灯しそうな気がする。
で、アセンブラがよくわからんのよ。こんなんでいいの?
mov r3, #-2147483616
add r3, r3, #8650752
mov r2, #255
str r2, [r3, #0]
ということで、このコードを次のアセンブラの前に埋めてみた (Heave-ho! って「どっこいしょ」という意味らしい)。
mov pc, r8 /* Heave-ho! */
すると、緑のLEDと赤のLEDが点灯する。Armadillo-9の基盤上だと緑のLEDがD1で赤のLEDがD2。っていうか、赤のLEDってなに?
しかも、モニタプログラムのプロンプトに戻ってくる。
きっとGPIO PortE Pin 0が緑のLEDでPin 1が赤のLEDじゃないかなー、ということで、GPIO Port Eに255を書き込むのではなく、1と2を試してみる。
どうやら、1を書くと緑のLEDが点灯し2を書くと赤のLEDが点灯するようだ。当然ながら、3を書くと両方点灯する。
で、赤のLEDが点灯したときだけモニタプログラムのプロンプトに戻ってくるみたい。なので、1を書いたときはそのまま停止 (ダンマリ)。
さらに、今気づいたんだけどGPIOのPortって入力か出力かを設定してあげなきゃいけないんだろうか。だったらGPIO_PEDDRも設定しないといけないのかも。
まぁ、いずれにせよ緑のLEDを使って場所を特定していくことになるのかな。
ということで、ほんの少しだけずらしてみる。
mov pc, r8 /* Heave-ho! */
Lunmapped:
/*
* We want to construct a memory map that maps us
* VA==PA (SDRAM at 0x00000000). We create these
* mappings uncached and unbuffered to be safe.
*/
/* GPIO Port E */
mov r3, #-2147483616
add r3, r3, #8650752
mov r2, #1
str r2, [r3, #0]
/*
* Step 1: Map the entire address space VA==PA.
*/
adr r4, Ltable
ldr r0, [r4] /* r0 = &l1table */
うーん。LEDは点灯しません。えー、実質何もしていない気がするんですけど。
mov pc, r8 /* Heave-ho! */
これってpcにr8の内容を代入しているんですよね。
で、r8の内容はその前に
adr r8, Lunmapped
bic r8, r8, #0xff000000 /* clear upper 8 bits */
ってなっているのです。ですから、LunmappedなラベルのアドレスをPCに入れたということになって、Lunmappedなアドレスから命令が実行されるのかなと。
であれば、真っ先にLEDが光らないといけないような気がするんですが...
clear upper 8 bitsというのは気になります。なんでこんなことしてるんだろ。
さて、とりあえず mov pc, r8で死んでいるとして、それをやめたらどうなるの? ということで、すこしづつ進めてみる。
どうやらMMUを有効にするところで死ぬようだ。
/* OK, let's enable the MMU. */
mrc p15, 0, r2, c1, c0, 0
orr r2, r2, #CPU_CONTROL_MMU_ENABLE
mcr p15, 0, r2, c1, c0, 0
ということで、きょうはここまで。
鼻血がでた。結構大量に。
風呂に錠剤を入れて追い炊きするタイプの洗浄剤をつかってみた。
たしかに汚れが浮いてきているような気がする。が、これは風呂釜のなかの汚れかどうかは判断できないな。やっぱり浴槽をきれいに洗ってからやってみればよかったな。
Armadillo-9のソフトウェアマニュアルP30の表8-2にメモリマップ(RAM)について書かれている。
それによるとFlashメモリから展開・コピーされるkernelのアドレスは0xc0018000と書いてある。
evbarm/conf/std.armadillo9にはLOADADDRESSというmakeoptionsが書かれていて0xc020000になっている。mk.armadillo9も同様のアドレスが書かれている。
ここも直すのかな。0xc0200000と0xc0018000だと結構違いがあるなぁ。mk.armadillo9はPHYなアドレスも同じようにしないといけないことに。
いずれにせよarmadillo9_start.SのStep 1からStep 6までを理解しないといけないということなのか。
/*
* Step 1: Map the entire address space VA==PA.
*/
adr r4, Ltable
ldr r0, [r4] /* r0 = &l1table */
mov r1, #(L1_TABLE_SIZE / 4) /* 4096 entry */
mov r2, #(L1_S_SIZE) /* 1MB / section */
mov r3, #(L1_S_AP(AP_KRW)) /* kernel read/write */
orr r3, r3, #(L1_TYPE_S) /* L1 entry is section */
1:
str r3, [r0], #0x04
add r3, r3, r2
subs r1, r1, #1
bgt 1b
L1_TABLE_SIZEなどL1_***な定義はarm/include/arm32/pte.hにある。Ltableは.word 0x4000となっている。
1MBを4096回繰り返せば4GBだからMap the entire address space VA==PAというのもなんとなく理解できる。で、mapするためのテーブルが0x4000番地から4kつかわれるということか?
以降のStep 2からStep 6はStep 1で初期化したVA==PAなテーブルに変更をかけていくということになるんですかねぇ?
めずらしく早く起きましたよ。
とりあえず、ハードウェアマニュアルのメモリマップを参考にVAとPAのマッピングを見よう見まねで作成してみた。
残念ですが、動きません。
書いたアセンブラも怪しいが、そもそもの考え方が間違っている可能性が高い。
そもそも、mov pc, r8で止まる理由とか解決していないし。
おれ自身が眠いっす。
夜に鼻血が出た。なんか、暑くなってきたからのぼせぎみなのかな。
ちっとも動かないので気分転換にLinuxのコードを再び読む。
いまメモリマップでハマっているつもりなんだけど、実際のところはざっくりとマッピングすれば良い気がしてきた。
というのも、物理メモリと仮想メモリのマッピングはarch/arm/mach-ep93xx/mm.cの次の構造体ぐらいしか情報がなさそうに見える。mmがMemory Mapの略だというのに今日気づいたのがなかなかニブい自分をさらけ出す。
static struct map_desc ep93xx_io_desc[] __initdata =
{
//
// Virtual Address Physical Addresss Size in Bytes Domain R W C B Last
{ IO_BASE_VIRT, IO_BASE_PHYS, IO_SIZE, DOMAIN_IO, 0, 1, 0, 0 },
{ PCMCIA_BASE_VIRT, PCMCIA_BASE_PHYS, PCMCIA_SIZE, DOMAIN_IO, 0, 1, 0, 0 },
#ifdef CONFIG_ARCH_ARMADILLO9
{ MISC8_BASE_VIRT, MISC8_BASE_PHYS, MISC8_SIZE, DOMAIN_IO, 0, 1, 0, 0 },
{ MISC16_BASE_VIRT, MISC16_BASE_PHYS, MISC16_SIZE, DOMAIN_IO, 0, 1, 0, 0 },
#endif
LAST_DESC
};
また、IO_BASE_PHYSなどの定数類はinclude/asm-arm/arch-ep93xx/regmap.hで定義されているのでこれらを拾ってくれば良いということになる。
極端な話、VA==PA, IO_BASE, PCMCIA_BASEの三つを初期化すりゃ、動いてくれるんじゃないかなぁ。
そうはいっても、手がかりが全然つかめないのでevbarmの下をじろじろと眺める。
で、Armadillo-9のメモリマップではPAの0xc000000はVAの0xc000000にマッピングされるのがTS-7200との違い (TS-7200はVAが0x00000000) だなぁ、と思いつつevbarm/*/*_start.Sを眺める。
すると、tsarm (TS-7200) ではSDRAM at 0x00000000と書かれているのがadi_brhでSDRAM at 0xc000000と書かれている。これは、Armadillo-9と同じじゃないかなぁ。
evbarm/adi_brh/brh_start.Sを読むと色々なことがわかった。
tsarmのtsarm_start.Sで
add r8, pc, #Lunmapped
bic r8, r8, #0xff000000 /* clear upper 8 bits */
って、どういう意味じゃい。とか、
mov pc, r8 /* Heave-ho! */
でハングアップするのはなんでだろ。とか思っていた。
brh_start.Sでは、
add r8, pc, #(.Lunmapped - . - 8)
bic r8, r8, #0xff000000 /* clear upper 8 bits */
orr r8, r8, #0xc0000000 /* OR in physical base address */
というように物理アドレスへのORをとっていて
mov pc, r8 /* Heave-ho! */
てな感じで.Lunmappedなアドレスにジャンプするということがわかる。
conf/mk.adi_brhやconf/mk.tsarmをみるとkernelがロードされる物理アドレスと仮想アドレスが示されているけれど、これらも勘案すると0xc0000000な Armadillo-9はtsarmを参考にするよりもむしろadi_brhを参考にした方が良いのでは?
と思い、brh_start.Sを参考に、とりあえずIO_BASEは置いといてVA==PAなマップを作るだけのarmadillo9_start.Sを書いて、mk.armadillo9, std.armadillo9のアドレス指定も0xc0200000に直してkernelを作ってみた。
すると、これまで動かなかったmov pc, r8を通過し、armadill9_start.Sの最後の方のMMUをenableするところまで動いた (LEDが光った)。
ということで、adi_brhを参考にする作戦は良かったみたい。
もしかしたら、IO_BASEとかちゃんと書けば、もっと先に進むかも。
とか思っていたのだけど、ARMのアセンブラに阻まれる。
たとえば、こんなの。
add r0, pc, #(Ltable - . - 8)
(中略)
Ltable:
.word 0xc0004000
この#(Lhoge - . - 8)という表現がわからん。r0 = pc + 0xc000400だと意味不明だし。
そのあとに
ldr r0, [r0] /* r0 = &l1table */
って書いてある。ようは、「r0に0xc0004000番地の内容をロードした」ということなんだろうか。結論はそうだとしても、mov r0 #Ltableじゃダメなのかなぁ、ダメなんだろうからこう書いているんだろうなぁ。
このアセンブラの表記はARMって言う話じゃなくてGNU asの表記方法なのだろうか。よくわからんよ。しかも、adi_brhしかこういう表記していないっぽい。
とにかく、もっとじっくり考えないとダメかな。
今日も、おれ自身が眠いっす。
朝にも鼻血が出た。鼻の粘膜が過敏になっているのかもしれない。
さすがに睡眠不足なので、何もせずに寝る。
さすがによく寝たので朝から調子が良い。
雨はいやだなぁ。今日は小雨だけれども。
掲示板や日記でアセンブラの指南をいただく。ありがたいことです。
#(Lhoge - . - 8)の表記についての謎が解けました。
adrはGNU asの疑似命令というのもなるほどという感じ。
ということで、adi_brhは「(一見まわりくどいが)ARMらしいコーディング」ということになるのでしょうか。
その他のadrを使っているevbarmは「GNU asの疑似命令を使って可読性を重視したコーディング」という感じなのかな。
個人的にはadrを使ってわかりやすい方が今のところ理解をしやすそうなので、そっちを使っていこうかな。
などと思いつつ、なんの作業もしないのでありました。
こういうとき元気を付ける読み物と言えばNetBSD/news68kへの道 (http://www.ceres.dti.ne.jp/~tsutsui/netbsd/port-news68k.html)でしょう。
読むだけで元気が出るのです。
news68kに比れば、文献やLinuxのソースがある私などは動かないほうがおかしい、という感じかもしれない。
printfが動くのはいつになるだろうか。
今週末のNBUG例会であっさりと動作報告とかありそうな気もするけれど。
ビール二杯、ホッピー二杯、ウーロン茶一杯。
サプライズが二つほど。
ついに買うものがなくなりましたかという話とついにそれに手を出しましたかという話。
なにごとも経験というのは大切ですね。
あさもよるも。
ふとarch/arm/ep93xx/ep93xxreg.hにも定義があったなと思い出した。
関係しそうな三つは次のように変更した。
#define EP93XX_IO_VBASE 0xff000000UL #define EP93XX_AHB_VBASE 0xff000000UL #define EP93XX_APB_VBASE 0xff300000UL
で、ダンマリで先に進まず、やっぱり何も変わらないので原因を調査するべくobjdump -S netbsdと逆アセンブルしてみる。逆アセンブルなんて初めてやってみたな。
逆アセンブルの結果、一番始めには、まさに今さわっているarmadillo9_start.Sがあるようだ。見慣れたLunmappedなどというラベルも見える。
/export/o/20050529/evbarm/sys/arch/evbarm/compile/ARMADILLO9/netbsd: file format elf32-littlearm
Disassembly of section .start:
00200000 <armadillo9_start>:
200000: e28f8020 add r8, pc, #32 ; 0x20
200004: e3c884ff bic r8, r8, #-16777216 ; 0xff000000
200008: e3888103 orr r8, r8, #-1073741824 ; 0xc0000000
20000c: ee112f10 mrc 15, 0, r2, cr1, cr0, {0}
200010: e3c22001 bic r2, r2, #1 ; 0x1
200014: ee012f10 mcr 15, 0, r2, cr1, cr0, {0}
200018: e1a00000 nop (mov r0,r0)
20001c: e1a00000 nop (mov r0,r0)
200020: e1a00000 nop (mov r0,r0)
200024: e1a0f008 mov pc, r8
00200028 <Lunmapped>:
200028: e28f40b4 add r4, pc, #180 ; 0xb4
20002c: e5940000 ldr r0, [r4]
200030: e3a01a01 mov r1, #4096 ; 0x1000
200034: e3a02601 mov r2, #1048576 ; 0x100000
200038: e3a03b01 mov r3, #1024 ; 0x400
20003c: e3833002 orr r3, r3, #2 ; 0x2
200040: e4803004 str r3, [r0], #4
200044: e0833002 add r3, r3, r2
200048: e2511001 subs r1, r1, #1 ; 0x1
20004c: cafffffb bgt 200040 <Lunmapped+0x18>
200050: e5940000 ldr r0, [r4]
200054: e2800dff add r0, r0, #16320 ; 0x3fc0
200058: e3a03102 mov r3, #-2147483648 ; 0x80000000
20005c: e3833b01 orr r3, r3, #1024 ; 0x400
200060: e3833002 orr r3, r3, #2 ; 0x2
200064: e4803004 str r3, [r0], #4
200068: e5940000 ldr r0, [r4]
20006c: e2800dff add r0, r0, #16320 ; 0x3fc0
200070: e2800020 add r0, r0, #32 ; 0x20
200074: e3a03102 mov r3, #-2147483648 ; 0x80000000
200078: e2833502 add r3, r3, #8388608 ; 0x800000
20007c: e3833b01 orr r3, r3, #1024 ; 0x400
200080: e3833002 orr r3, r3, #2 ; 0x2
200084: e4803004 str r3, [r0], #4
200088: e0833002 add r3, r3, r2
20008c: e4803004 str r3, [r0], #4
200090: e28f004c add r0, pc, #76 ; 0x4c
200094: e5900000 ldr r0, [r0]
200098: ee020f10 mcr 15, 0, r0, cr2, cr0, {0}
20009c: ee080f17 mcr 15, 0, r0, cr8, cr7, {0}
2000a0: e3a00001 mov r0, #1 ; 0x1
2000a4: ee030f10 mcr 15, 0, r0, cr3, cr0, {0}
2000a8: e59f1038 ldr r1, [pc, #56] ; 2000e8 <Lstart>
2000ac: e1a01001 mov r1, r1
2000b0: ee112f10 mrc 15, 0, r2, cr1, cr0, {0}
2000b4: e3822001 orr r2, r2, #1 ; 0x1
2000b8: ee012f10 mcr 15, 0, r2, cr1, cr0, {0}
2000bc: e1a00000 nop (mov r0,r0)
2000c0: e1a00000 nop (mov r0,r0)
2000c4: e1a00000 nop (mov r0,r0)
2000c8: ee122f10 mrc 15, 0, r2, cr2, cr0, {0}
2000cc: e1a02002 mov r2, r2
2000d0: e3a03182 mov r3, #-2147483616 ; 0x80000020
2000d4: e2833721 add r3, r3, #8650752 ; 0x840000
2000d8: e3a02001 mov r2, #1 ; 0x1
2000dc: e5832000 str r2, [r3]
2000e0: e1a0f001 mov pc, r1
002000e4 <Ltable>:
2000e4: c01fc000 andgts ip, pc, r0
002000e8 <Lstart>:
2000e8: c02000ec eorgt r0, r0, ip, ror #1
Disassembly of section .text:
c02000ec <kernel_text>:
c02000ec: e28f103c add r1, pc, #60 ; 0x3c
c02000f0: e8912006 ldmia r1, {r1, r2, sp}
c02000f4: e0422001 sub r2, r2, r1
c02000f8: e3a03000 mov r3, #0 ; 0x0
c02000fc: e4813004 str r3, [r1], #4
c0200100: e2522004 subs r2, r2, #4 ; 0x4
c0200104: cafffffc bgt c02000fc <kernel_text+0x10>
c0200108: e3a0b000 mov fp, #0 ; 0x0
c020010c: eb02ed99 bl c02bb778 <initarm>
c0200110: e1a0d000 mov sp, r0
c0200114: e3a0b000 mov fp, #0 ; 0x0
c0200118: e1a0c00d mov ip, sp
c020011c: e92dd800 stmdb sp!, {fp, ip, lr, pc}
c0200120: e24cb004 sub fp, ip, #4 ; 0x4
c0200124: eb00adcb bl c022b858 <main>
c0200128: e28f000c add r0, pc, #12 ; 0xc
c020012c: ea016064 b c02582c4 <panic>
c0200130: c0349e84 eorgts r9, r4, r4, lsl #29
c0200134: c0356570 eorgts r6, r5, r0, ror r5
c0200138: c034a684 eorgts sl, r4, r4, lsl #13
c020013c: 6e69616d powvsez f6, f1, #5.0
c0200140: 72202928 eorvc r2, r0, #655360 ; 0xa0000
c0200144: 72757465 rsbvcs r7, r5, #1694498816 ; 0x65000000
c0200148: 0064656e rsbeq r6, r4, lr, ror #10
c020014c: c0354170 eorgts r4, r5, r0, ror r1
で、<Lstart>のあとの<kernel_text>というのがarmadillo9_start.Sのあとに実行されるのだろう。2000a8:で<Lstart>の値、つまりc02000ec、つまりc02000ec番地の<kernel_text>っていうことだからなぁ。
んで、<kernel_text>をしばし実行するとc020010cに<initarm>に飛ぶような命令になっている。おぉ、結構すぐにinitarm()に入るのだなと思い、<initarm>のアドレスであるc02bb778を見ると次のようになっている。
c02bb778 <initarm>:
c02bb778: e1a0c00d mov ip, sp
c02bb77c: e92ddff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
c02bb780: e3a03182 mov r3, #-2147483616 ; 0x80000020
c02bb784: e24cb004 sub fp, ip, #4 ; 0x4
c02bb788: e2833721 add r3, r3, #8650752 ; 0x840000
c02bb78c: e3a02002 mov r2, #2 ; 0x2
c02bb790: e24dd014 sub sp, sp, #20 ; 0x14
c02bb794: e5832000 str r2, [r3]
c02bb798: eb000252 bl c02bc0e8 <consinit>
c02bb79c: e59f0864 ldr r0, [pc, #2148] ; c02bc008 <.text+0xbbf1c>
c02bb7a0: ebfe7522 bl c0258c30 <printf>
<initarm>に入るとすぐにLEDを光らせるコードが入っている (c02bb780:からc0bb78c:)。
それでもLEDが光らないってことは、armadillo9_start.Sをでてからinitarm()に入るまでの、ほんの数個の命令のところで死んでいるっていうことなんだろうか。
うーん、いよいよわかんなくなってきたぞ。
関係ないけど、逆アセンブルっておもしろいね。
armadillo_start.Sのソースはこんな感じ。ライセンスは元ファイル (evbarm/tsarm/tsarm_start.S) と同様。
#include <machine/asm.h>
#include <arm/armreg.h>
#include <arm/arm32/pte.h>
#include <arm/ep93xx/ep93xxreg.h>
.section .start,"ax",%progbits
.global _C_LABEL(armadillo9_start)
_C_LABEL(armadillo9_start):
/*
* We will go ahead and disable the MMU here so that we don't
* have to worry about flushing caches, etc.
*
* Note that we may not currently be running VA==PA, which means
* we'll need to leap to the next insn after disabing the MMU.
*/
adr r8, Lunmapped
bic r8, r8, #0xff000000 /* clear upper 8 bits */
orr r8, r8, #0xc0000000 /* OR in physical base address */
/*
* Setup coprocessor 15.
*/
mrc p15, 0, r2, c1, c0, 0
bic r2, r2, #CPU_CONTROL_MMU_ENABLE
mcr p15, 0, r2, c1, c0, 0
nop
nop
nop
mov pc, r8 /* Heave-ho! */
Lunmapped:
/*
* We want to construct a memory map that maps us
* VA==PA (SDRAM at 0xc0000000). We create these
* mappings uncached and unbuffered to be safe.
*/
/*
* Step 1: Map the entire address space VA==PA.
*/
adr r4, Ltable
ldr r0, [r4] /* r0 = &l1table */
mov r1, #(L1_TABLE_SIZE / 4) /* 4096 entry */
mov r2, #(L1_S_SIZE) /* 1MB / section */
mov r3, #(L1_S_AP(AP_KRW)) /* kernel read/write */
orr r3, r3, #(L1_TYPE_S) /* L1 entry is section */
1:
str r3, [r0], #0x04
add r3, r3, r2
subs r1, r1, #1
bgt 1b
/*
* Step 2: Map VA 0xff000000->0xff100000 to PA 0x80000000->0x80100000.
*/
ldr r0, [r4]
add r0, r0, #(0xff0 * 4) /* offset to 0xff000000 */
mov r3, #0x80000000
orr r3, r3, #(L1_S_AP(AP_KRW))
orr r3, r3, #(L1_TYPE_S)
str r3, [r0], #4
/*
* Step 3: Map VA 0xff800000->0xffa00000 to PA 0x80800000->0x80a00000.
*/
ldr r0, [r4]
add r0, r0, #(0xff0 * 4) /* offset to 0xff000000 */
add r0, r0, #(0x8 * 4) /* offset to 0xff800000 */
mov r3, #0x80000000
add r3, r3, #0x00800000
orr r3, r3, #(L1_S_AP(AP_KRW))
orr r3, r3, #(L1_TYPE_S)
str r3, [r0], #0x4
add r3, r3, r2
str r3, [r0], #0x4
/* OK! Page table is set up. Give it to the CPU. */
adr r0, Ltable
ldr r0, [r0]
mcr p15, 0, r0, c2, c0, 0
/* Flush the old TLBs, just in case. */
mcr p15, 0, r0, c8, c7, 0
/* Set the Domain Access register. Very important! */
mov r0, #1
mcr p15, 0, r0, c3, c0, 0
/* Get ready to jump to the "real" kernel entry point... */
ldr r1, Lstart
mov r1, r1 /* Make sure the load completes! */
/* OK, let's enable the MMU. */
mrc p15, 0, r2, c1, c0, 0
orr r2, r2, #CPU_CONTROL_MMU_ENABLE
mcr p15, 0, r2, c1, c0, 0
nop
nop
nop
/* CPWAIT sequence to make sure the MMU is on... */
mrc p15, 0, r2, c2, c0, 0 /* arbitrary read of CP15 */
mov r2, r2 /* force it to complete */
/* GPIO Port E (LED D1)*/
mov r3, #0x80000020
add r3, r3, #0x840000
mov r2, #1
str r2, [r3, #0]
mov pc, r1 /* leap to kernel entry point! */
Ltable:
.word 0xc0200000 - 0x00004000
Lstart:
.word start
休みにしてはけっこう朝早く起きて、午前中から午後にかけてゴロゴロ。
午後からアキバにいきました。
あんまりウロウロできず、マウスを一個買いました。
光学式マウス, CB-MOU4-WH, クレバリー, 1,333円, クレバリーインターネット館, USB接続
あと、アソビットシティ2号館で両替目的に単4の電池を買ったり、ガシャポン二回とプラレールのレール (二倍直線、二倍曲線) を買ったり。
アソビットシティ2号館の上の方の鉄道模型の階は好きな人にはたまらないだろうなぁ。
最後に書泉でTECH-I Vol.18 ARMプロセッサ入門を買ってきた。
何もやってませんがARMプロセッサ入門を買ってきたので勘弁してください。
近くの公園へ。
マジマジ言いすぎにつき、しばらくマジ断ち。
Linux環境を整えるべくLinuxをインストールする、というのはできないので、coLinuxというのに手を出してみる。Windowsでも簡単にLinux環境が構築できる。
これは便利だ。
などと言っているが、NetBSDは全く進展がない。
kernelの開始アドレスが0xc0018000じゃなくて0xc0200000から始まっているのをIRCで指摘されて、そういえばそうだったぞ、と思い出す。
0xc0200000にしたのは、SDRAMが0xc0000000の他のevbarmな計算機が0xc0200000とmk.XXXXに指定していたから真似しました、という弱い理由だったりするので、やっぱり0xc001800が正しいのかもしれない。
Let's NoteにNetBSDとXを入れてしばらく使っていると、非常に具合がいい。
これは、単純に昔から使い慣れたキーバインドとかそういうものによるところが大きいと思うけど。
Mac OS Xが不便なわけじゃない。不便どころか、とても良くできたOSで、本当に便利で役に立ってくれている。日々のメールやWeb閲覧など日常生活で使ってきたし、Windowsよりも快適なんじゃないかと思えるところがたくさんあった。追加なしにshellやsshが使えるのも良かった。
さらに深入りすれば、もっともっと快適になるだろうな、という感触だけど、思うところがあってNetBSDを入れたくなった。
というわけで、Mac miniにNetBSDを入れる決心をつけたのが数週間前。
今日からついにHDDの整理を始めた。といっても、ほんの少しのファイルとiTunesの音楽ファイルくらいを吸い上げれば良いみたい。
これらも、CDからリッピングし直したり、ダウンロードしたりすれば復元できるので、本当に残さなければならないファイルはないのかもしれない。
HDDは40Gbytesなんだけど、やっぱりMac OS XとNetBSDとのDual bootかなぁ。Debian GNU/Linuxを入れたよ、という話も聞くけど三つもOS入れられるんだろうか。
なんか、ここまで書いてきて、新しいことを受け入れることができなくなった単なる年寄りのような気がしてきた。
そうじゃない、それは認めたくない、ちゃんと理由があるんだと理由を探す自分にさらに年寄りを感じるのであった。
急きょ、多摩方面から応援をお願いする。
ついにMac mini再インストール。
パーティションを半分にして、Mac OS Xをクリーンインストール。
Appleにユーザ登録させられるのが面倒臭いと思った。
とりあえず、NetBSD/macppcのISOイメージをftp://ftp.ki.nu/NetBSD/snapshot/20050416ts/からダウンロードした。
が、Mac OS Xを使ってCD-RにISOイメージを書き込む方法がわからず、今日はここまで。
家の環境がほとんど使えなかったのを理由に何もできず。
メールはこちらへ...[BSD小僧 (tokuda @(at) tokuda .(dot) net)]
この日記は、GNSを使用して作成されています。