>>>>> "linux-mips" == Systemkennung Linux <linux@informatik.uni-koblenz.de>
>>>>> writes:
Hello,
[...]
linux-mips> The double tlbl exception is part of the concept.
linux-mips> Handling the tlb faults this way takes out complexity
linux-mips> from the first handler (which has 14 instructions for
linux-mips> R4x00 and only 12 for R4600).
Yep, it seems to work now. My problem was that the format
of the R3000 context register is different from the R4000.
In addition, it drops bit 31 of the faulting address, which
makes it difficult to use it for kernel page mapping.
My current solution is expensive, but it seems to work:
I don't use the context register at all, I emulate it using
BadVAddr to get R4000-like page table offsets.
This solution has at least one advantage:
It works regardless of the format of the context register, so
maybe it will be useful for other currently unsupported
MIPS processors.
I'll get back to optimize it later (I know, they all say that :-))
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 ?
linux-mips> Which libc have you been using for your compilation
linux-mips> attempts?
I don't have it here, but if I remember well it was something
like 4.6.28, with two patches. We took the complete state
on the fnet server on May 26.
>> - There was a bug in the 1.3.98 ld.script: the _end symbol is
>> before the .sbss data, which will cause variables to be
>> overwritten at initialization.
linux-mips> The .sbss section should be empty so this is no real
linux-mips> problem. This script is used anyway only used when
linux-mips> converting an ELF kernel into an a.out kernel for
linux-mips> bootstrap purposes. Given some other problems with
linux-mips> binutils that I'm just debugging this option doesn't
linux-mips> work anyway.
In our case, we use the script a lot: our target boots from
a Flash ROM (currently the minimal compressed kernel takes around
170 Kb, with Minix, serial driver, plus a minimal set of features.
In the current state (kernel thread creation hangs when launching
init), it takes around 450Kb code and 205Kb data).
To do this, we need some linker customization which is best done
in a linker script.
I'm not sure they were in the .sbss section, but there were
definitely some kernel variables overwritten during kernel_startup
until we moved the definition of _end.
If your problem with the binutils has anything to do with binary
format, we have a patch for the bfd lib to handle output addresses
correctly when creating a binary file. I think this patch has
already been made available by Robin Farine, but if anyone wants
it please ask.
>> - The R3000 cli/sti functions need nops to prevent coprocessor
>> hazards.
linux-mips> I (and Paul Antoine who did most of the R3000 bits
linux-mips> that exist) know about this problem. The problem is
linux-mips> that the R3000 documentation (Kane) doesn't specify
linux-mips> how many nops are exactly required; we intended to
linux-mips> inquire how many are required before we add five (==
linux-mips> pipeline lenght) as brute force solution.
I touched the code in r3000.S and head.S . I guess this is where
the coprocessor 0 hazards are the most likely. I have added some
nops in there just to be sure. I'm not yet certain it works, though.
About the state of our work:
We have planned to release a set of clean patches when the
system runs.
Until now, we're working in a real hurry and we absolutely
don't have time to spend on anything else than getting the
system to boot and be usable.
If anybody can be content with our raw work files, with:
- Virtually uncommented changes
- Untested modifications
- Absolutely no file headers or legalese of any sort
- Scrambled indentation because we use the default mode
of emacs (no time to add emacs tags to source :-)).
- But if you know diff (or better, ediff), you should
be able to cope, maybe find some ideas or most likely
undig some bugs.
If you're interested, drop me an email.
See you,
Didier
--
///////////////////////////////////////////////////////////////////////////////
// Didier Frick, software engineer / Fbg. du Lac 6 /dfrick@dial.eunet.ch//
// Software development & consulting / CH-2000 Neuchatel / +41 (38) 211508 //
///////////////////////////////////////////////////////////////////////////////
http://ourworld.compuserve.com/homepages/Didier_Frick
|