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

Re: Linux 2.1.100 on MIPS R3000 VME box

To: linux-mips@fnet.fr
Subject: Re: Linux 2.1.100 on MIPS R3000 VME box
From: Harald Koerfgen <harald.koerfgen@netcologne.de>
Date: Fri, 14 Aug 1998 18:00:28 +0200 (MEST)
In-reply-to: <Pine.SV4.3.91.980814182836.1948B-100000@mech>
Organization: none
Reply-to: "Harald Koerfgen" <harald.koerfgen@netcologne.de>
Sender: harry@franz.no.dom
Hi,

On 14-Aug-98 Gleb O. Rajko wrote:
> 
> 
> On Fri, 14 Aug 1998, Alex deVries wrote:
>  
>> Hmmm.  How different are R3ks in comparison to R4ks?  I was under the
>> impression they were binary compatible.
> backward only. For example, gcc likes to optimize access and uses double 
> word load/store instructions until you specify -mips1. I don't know how many
> binaries have it inside. I am afraid, almost all.

Well, I haven't had the chance yet to prove if this is true, but I think you
may be interested in what Ralf told me about this:

On 05-Mar-98 ralf@uni-koblenz.de wrote:
> Thought this might as well be interesting to other as well, so I copy this
> to the usual lists.
> 
> On Thu, Mar 05, 1998 at 08:29:51PM +0100, Harald Koerfgen wrote:
> 
>> BTW Eine Sache, die ich schon immer wissen wollte, aber nie zu fragen wagte:
>> 
>> Wie sieht das eigentlich mit der CPU-Abhaengigkeit der glibc aus?
>> 
>> Ich habe gerade damit anfgefangen, mich mit dem Ramdisk-Support fuer
>> linux/MIPS zu
>> beschaeftigen und moechte spaeter einmal ein Ramdisk-Image zum Kernel-Image
>> dazulinken, welches als root gemountet werden soll. Auf diesem moechte ich
>> eine
>> statisch gelinkte bash unterbringen. Meine eigentliche Frage ist nun, wuerde
>> das mit
>> der existierenden glibc funktionieren, oder muesste ich eine
>> R3000-spezifische glibc
>> bauen?
> 
> All the published userland binaries have been compiled using MIPS ISA 1.  The
> sole exception is glibc.  As it is usual for Linux, the MIPS binaries of
> glibc have been built using the three add-ons crypt, localedata and
> linuxthreads.  In order to be threadsafe LinuxThreads has to use some kind of
> semaphores etc..  Since it is the natural way of doing things for R6000 and
> better, I choose to implement this using the ll and sc instructions.
> 
> For the members of the MIPS CPU family which are lacking these two
> instructions I suggest to simulate them in the reserved instruction handler.
> This will work for all uniprocessor systems and using the special hardware
> which is part of old R2000/R3000 systems it would even be SMP proof - if
> we ever do R3000 SMP ...  It wouldn't be interrupt safe as well.
> 
> The implementation could roughly look like:
> 
> unsigned long ll_bit, lladdr;
> 
> void simulate_ll(struct pt_regs *regs)
> {
>       unsigned long addr;
> 
>       /*
>        * analyse the ll instruction that just caused a ri exception
>        * and put the referenced address to addr.
>        */
>       [...]
>       
>       lladdr = addr;
>       ll_bit = 1;
>       regs[reg_to_be_loaded] = *addr;
> }
> 
> void simulate_sc(struct pt_regs *regs)
> {
>       /*
>        * analyse the ll instruction that just caused a ri exception
>        * and put the referenced address to addr.
>        */
>       [...]
> 
>       lladdr = addr;
> 
>       if (ll_bit = 0) {
>               regs[reg_to_be_stored] = 0;
>               return;
>       }
> 
>       *addr = regs[reg_to_be_loaded];
>       regs[reg_to_be_loaded] = 1;
> }
> 
> The scheduler would have to clear ll_bit on every context switch in order
> to take care of shared memory and threads sharing their mm_struct.
> 
> There are for shure better ways of doing this, but this implementation would
> keep the 100% binary compatibility.  The way not to do it is to use
> sysmips(MIPS_ATOMIC_SET, ...) syscall which would result in the full
> syscall overhead.  Even though Linux's is way less than RISC/OS's ...
> 
>   Ralf
[end of Ralfs mail]

> I don't thing somebody interested in entire port, because it's a quite 
> specific machine which developed and produced in Russia. It has VME bus 
> that is controlled by VIC068/VAC068 chips. Only thing that comes 
> in mind is it's might help to port Linux to VME-based boards with a MIPS CPU.
> There should be a lot such machines in the world... Anyway, I prefer to 
> polish our code before posting a patch if nobody is interested to look at 
> code soon. 

Well, I am :-).

> Great, thanks.
> 
> Gleb.

---
Regards,
Harald

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