> probably the only problem you have is that Paul did forget to copy the
> execption handle to the correct location. There were some Mail's around
> just after ther e release of Paul's "linux-18.104.22.168.dec" concerning that
> topic. I do not have the source here but it was something like
> memcopy(KSEG0+0x80, execpt_vec0, 0x80);
> just in the beginning of get_pmax_memorysize of arch/mips/dec/decstation.c.
> May be you can find the original mail of Paul, or I will post the correct
> statment tomorrow.
OK. (Got your other message with the real statement.) Well, I'm
reinstalling the OS on my NFS server tonight, so unfortunately I can do any
recompiling right now :-( But I _did_ make much progress last night!
I ended up just hard-coding the memory size for my box (a whopping 8 meg!)
and then I pressed on. Couple other things I found:
1) In linux/arch/mips/dec/decstation.c, there is a call to prom_getenv to
get the console type. As is implied by the comment directly above, the
environment variable is different on the 5100 (and 2100/3100 too, I assume) -
it is "console" not "osconsole". This returns "0" on my box, so I modified
the if/then/else below to set serial console for this value.
2) Hmm. I guess this should have been 1, since it appears first - but I
think I found it second! Anyways, there is a call to register_console which
passed "rex_printf". This lead to an immediate core dump the first time
printk was called (at the end of boot.S). Once I changed this to prom_printf
I was rewarded with a bunch more of the boot sequence! Now I get to the
loop delay calibration, where the machine hangs.
Can anyone give me a quick explanation of how this routine works, and why
it _isn't_ working? I notice that just above there is a note requesting
that someone "write the time init code for the DECstation" -- is this why
it isn't working (because the clock interrupt isn't being serviced?)
This is fun!
Stu Allen Phone: (716) 231-0073
EDS / GNS Internet: email@example.com