[vmips] Linux almost works...

[Cable Guy]

On Sun, 19 Dec 2004 00:50:45 -0600, Brian R. Gaeke <brg at dgate.org> wrote:
> Sorry it's taken me a while to respond to your email.

That's OK.  I remember finals :)  Hope you did well.

> > 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.

Yes, I could do that.  It does need a little cleaning up.  Basically I
symlinked the Linux build root to the xmboot directory and modified
the standard Linux ld.script to also bring in the xmboot files.  I had
to rename all the functions in lib.c so they wouldn't conflict with
the Linux names at link time.  Not too hard, I just prefixed
everything with an undersccore.  LD has a boatload of shortcomings I
learned about the hard way.  You know you're in for a rough ride when
you search for something on Google and you only get aout 35 hits back.

> > "Kernel command line: single root=/dev/ram0 rw load_ramdisk=1
> > init=/bin/ash console=ttyS3,9600n8"
> 
> I think that's fine, because the serial lines are capable of full-duplex
> operation.

Could interrupts have anything to do with it, or does Linux use
polling?  I know you mentioned something about that in the vmips docs.
 I would rather stay with the DZ serial stuff since even though it's
weird, it's brutally simple.  An interrupt on each charatcter.  Using
the "silo" will get you 64 chars before an interrupt.  I was shocked. 
It seems very primitive, even for the 70s when this stuff came out.

> > 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.

I've gotten it to spit out one more line after the "DZ11 write LPR as
1e1b".  It's:
"Algorithmics/MIPS FPU Emulator v1.5"

That's cool, though, because I built my toolchain without FPU support.

> > Is it possible to jack in a "serial port emulator" into VMIPS?
> 
> I'm not entirely sure what you mean here.

In the bootup messages I notce that ttys00 through ttyS03 are
registered.  I was wondering if there was some way to hook into a
/dev/tty-something with a terminal emulator program and undertake
communications with a virtual tty of Linux as exposed by VMIPS. 
Probably not too easy.  My background includes a lot of work with
IBM's Virtual Machine mainframe OS where every real device can be
simulated and "attached" to a virtual machine.  Linux is a different
beast, I know.

> > 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 was thinking about defining a "board" for VMIPS.  Need more time for
that :)  As I said earlier, I think it would be easier to stick with
the DZ-11.

> 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
> ^\.

I hacked around some in the debug.cc code and changed some of the
assignments in Debug::exccode_to_signal() and then in
Debug::target_continue() added some tests so it wouldn't break on the
exceptions for Sys, TLBL, TLBS, Mod or CpU.  It lets gdb run much
smoother, although I'm no closer to finding the problem.  There are no
exceptions other than the ones I masked off after it "hangs".   BTW I
had some problems with the way MIPS signals are defined compared to
what gdb thinks they are.  I tried changing one to SIGUSR1 in the
VMIPS code and then tried to ignore it in the .gdbrc file (nostop). 
gdb thought it was something else besides SIGUSR1 and didn't mask it
at all.

> 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.

I think I did something like that too :)  I set a global flag so
nothing would break at all until it reached the code where the
"Algorithmics/MIPS" message is printed to the console.  Then
everything reverted to "normal" and that's when I found that there's
nothing drastic that seems to be wrong.  Luckily I dumped all the
pristine VMIPS code into my own revision control system before I
started hacking away at it so at least I'm not drowning in my own
changes and forgetting what I've done.

Linux isn't crashing.  I think the problem is when Linux tries to run
userspace code for the first time.  In my case it's BusyBox's
implementation of the ash shell.  At this point I have serious
problems re-building my toolchain.  When I try to rebuild uClibc with
it it complains that it can't find certain floating point symbols.  Oh
no, not again....   But that's not a VMIPS issue.

I want to stick as closely as possible to what's embedded in the
router.  Finding a pre-built toolchain that matches all the versions
of everything on there is impossible because from uClibc to BusyBox to
gcc to the GoAhead web server, everything on it is about 2 years old. 
I found a toolchain many people have had good luck with at
http://rtl8181.sourceforge.net/ but the Realtek RTL8181 device is
big-endian while my router based on the ADM5120 is a little-endian
device.  It's maddening because what I have found on my router is
almost certainly built with the same codebase as the RTL8181 devices. 
Even the firmware image files are in the same format (with the
exception that they're big-endian).  And, of course, the router
manufacturer blatantly disregards the GPL and refuses to supply the
source code for their firmware.  So I have no choice but to struggle
with it until I get it all figured out.  I'll keep you posted.  Thanks
again, Brian.