> > Now the system boots a good deal further, unfortunately it
> > hangs on the kernel_thread call which is supposed to launch
> > init. Do you have any suggestions on what I should look for
> > to catch this one ?
> If the system loops: check that the executable you're using is really
> a MIPS ELF executable with the x bits set. I've uploaded an simple
> hello, world program written in assembler a long time ago. Try to install
> the program as /bin/sh (remove your init proram before trying this) and to
> boot your system. You should get "hello, world!\n" messages.
Well, in the version I'm working on (1.3.98), init is not an executable,
but a procedure within init/main.c, which is forked via a kernel_thread
call. I have traced the behavior as follows:
When the syscall instruction is executed (by kernel_thread),
the syscall handler tries to
do a SAVE_ALL, but hangs: I get a tlbs exception when trying to store the
first register. I suppose this call should be handled on the kernel stack,
however. I still have some trouble understanding how the CU0 bit is used
to select between kernel and user stacks.
> Please use the supplied binaries of GNU libc snapshot 960501. These
> are compiled for plain R3000 and contain no optimizations for the R4000
> so they should work for you. You might also try the binaries from
> root-0.01.tar.gz or one of the other binary archives.
> Is your system little or big endian?
It is big endian, so if we have to deal with binaries they'll have to be
compiled big-endian. We have just checked the fnet server but weren't able
to find the snapshot. Do you have an URL for it ? And also for root-0.01 ?
By the way, memory space is at an absolute premium for us, so we really need
a way to strip the library from unneeded components.
> If you need a special linker script you can put it into an new directory
> in arch/mips/<target>/ld.script and add the required options for ld in
Yep, that's what we did. However, we copied the arch/mips/ld.script into
our custom script as a starting point, so we got this problem.
> I'm interested in taking a look at this patches.
OK, I'll see that you get it.
> I'd like to get the R3000 diffs from you into my sources as soon as
> possible so that I can help the DECstation people this way.
For the moment, our code is far from stable, and we are under tremendous time
so please allow us some more time before giving it out.
Shouldn't last too long.
> I've written a short text that describes the handling of the pages tables
> a bit closer. I hope this help you people out these to understand this
> part of the kernel better because it's by far more complex than eg. on
> Intel or m68k. I'll also put this text into arch/mips/doc/ in the
> kernel sources.