linux-mips-fnet
[Top] [All Lists]

Re: TLB Management , C library

To: linux@mailhost.uni-koblenz.de
Subject: Re: TLB Management , C library
From: Didier Frick <dfrick@dial.eunet.ch>
Date: Thu, 6 Jun 1996 02:29:42 +0200
Cc: linux-mips@fnet.fr
Cc: Robin.Farine@info.unine.ch
In-reply-to: <199606051220.OAA24235@informatik.uni-koblenz.de> (message from Systemkennung Linux on Wed, 5 Jun 1996 14:03:20 +0200 (MET DST))
>>>>> "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

<Prev in Thread] Current Thread [Next in Thread>