[vmips] Linux almost works...

[Brian R. Gaeke]

Sorry it's taken me a while to respond to your email.

And then spake Cable Guy, as follows:
> Note that I modified the kernel loader to have the "rk" command.  It
> just copies the kernel to RAM and clears the .bss.  I also came up
> with a ld.script that loads both the kernel and the ROM monitor (based
> on xmboot) into the same address space so gdb and insight coud "see"
> both the monitor and the kernel.  Spent several days on that part.

Sounds nifty! Let me know if you think it's something you'd like to clean up
and contribute.

> Anyway, of note is the kernel command line:
> 
> "Kernel command line: single root=/dev/ram0 rw load_ramdisk=1
> init=/bin/ash console=ttyS3,9600n8"
> 
> I obtained the KN02 document and see that the DZ serial lines are
> weird.  Line 0 is used for the keyboard and line 3 is used for
> "printer" output.  Linux, however, normally sees a serial console as
> kbd-in/tty-out on the same serial line.

I think that's fine, because the serial lines are capable of full-duplex
operation.

> nothing wil shake it loose from hanging at the same spot.

My guess is that something might have changed either in the Linux kernel or
in VMIPS, because my latest build of Linux is showing the same symptoms.

> Is it possible to jack in a "serial port emulator" into VMIPS? 

I'm not entirely sure what you mean here.

> Perhaps going the SPIM Console route would help.

It might be interesting to try writing a driver for the SPIM console
for Linux. It uses a lot of interrupt lines, though, so it might
be annoying to integrate into a DECstation kernel - you might want
to give it its own "board".

> I don't know.  At this point gdb doesn't seem to be
> too useful because it sees every signal and exception and there are a
> LOT of those going on all the time when Linux is running on MIPS.

That's been my experience too, unfortunately. What I usually try
to do in these cases is to use the "-o tracing" option to get a
dynamic instruction trace, and then trace through it by hand to see
where the machine has gotten lost in the weeds.  Right now, you can
do this manually by specifying a PC value at which to start tracing
(-o tracestartpc), and then halting VMIPS after you think you've
captured the fault, using the "quit" character, which is normally
^\.

The next thing that I want to do is make it easier to trace these
kinds of bugs, by adding a user-interaction mode that you can access
with a special keypress (similar to telnet's ^] keystroke, for
example, or the Stop-A key combo on Sun consoles).   My reasoning
is that it would be easier to hit a button and type "trace on", run
for a while, and say "trace off", than it is now, where you have
to know the exact PC you want to start tracing at.

-Brian

--
Brian R. Gaeke, brg at dgate.org -- GnuPG encrypted mail gleefully accepted