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

Re: Deskstation rPC44 update

To: linux-mips@fnet.fr
Subject: Re: Deskstation rPC44 update
From: Systemkennung Linux <linux@mailhost.uni-koblenz.de>
Date: Sun, 21 Jan 1996 18:59:39 +0100 (MET)
In-reply-to: <199601210642.XAA25317@rover.village.org> from "Warner Losh" at Jan 20, 96 11:42:17 pm
Hi,

> [ Don't know if this belongs in the list, please let me know if this
> is a problem ]

This is exactly what this list is about - porting Linux to MIPS!

> : vdma_alloc similar to the one in include/asm-i386/floppy.h.
> 
> OK.  I'll take a look there.  I kinda figured that the Deskstation
> rPC44 will mostly a PC port in a lot of ways...  Thanks for the
> pointer.  I'll have to remember to greb the i386 tree when I have
> problems :-).

Not needed - the stuff for other architectures is included in the MIPS
source tree.

> : I suspect the Tyne stuff is pretty buggy and outdated now that I've
> : changed to the Pica box for over a year.  As far as I know from the Tyne
> : the machine has ordinary PC DMA logic.  So in your case the stuff in
> : <include/asm-i386/floppy.h> should fit the rPC.  (Btw: Is the floppy
> : controller on your machine an (E)ISA card?)
> 
> ISA card in a EISA bus.

OK, this means that the PC stuff is really what you need.

> : The DMA in the Tyne is a bit special.  The motherboard contains additional
> : 32 bit wide 512kb SRAM.  This RAM is called "DMA cache".  This RAM is
> : the only place where the onboard PC chipset can do DMA.  So the processor
> : has to copy all data to the DMA cache and then to enable the DMA.  This
> : should be quite easy to hack in the DMA drivers, especially since Tynes
> : never have problems with DMA making primary/secondary cache state
> : inconsistent with memory.
> 
> I'll have to see if the rPC44 is the same or not.  Is there anyway in
> code to tell this, or do I need to ask the folks at Deskstation?  I
> don't recall seeing anything about a special SRAM DMA cache, which
> sounds expensive enough to warrant marketing folk to add it to the
> docs...

:-)  Well, I think it the DMA cache was mentioned in the boards manual.
If you know about SRAM types - on the Tyne the SRAM is easy to find.  If I
remember right the chip was located near the slots.  I however think that
it is more probably that your board doesn't have a DMA cache.

> : I suspect the Tyne stuff is pretty buggy and outdated now that I've
> : changed to the Pica box for over a year.  I found how buggy that stuff
> : is when I tried to reuse it for the Acer ...  Well, at least I did
> : my best to fix it.
> 
> Would it be better to start with the Jazz and/or Pica stuff?  The
> pica.S file seems to be derived from the tyne.S file, but has had lots
> of additional hacks done to it.

Well, originally both files were part of entry.S.  Since the Jazz machines
need lots of additional chipset specific stuff I created two files based
on the entry.S stuff.  The difference that is important for you is that
the interrupt handling is a bit different.  On both machines all interrupts
from PC style hardware are mapped to one single processor interrupt.  Think
it was interrupt #2 on the Tyne.  On a Tyne the processor needs to do the
complete interrupt acknowledge cycle that a i386 does in hardware in
software.  The Jazz machines are different in that respect.  The Tyne code
would work for them, too but the chipset offers an register from which
a single read does the complete interrupt acknowledge stuff as the i386
hardware would do.  The rest of handling for interrupts from PC style
hardware is the same.

The Jazz chipset features additional hardware onboard.  This hardware is
the reason for the rest of differences between tyne.S and pica.S

> 2.5.2.  The problem is that it doesn't like the output of cpp in the
> case that I found.  It smells like a buffer overflow bug in as, since
> if I remove 5 of the # lines from the output of cpp, the problem goes
> away.

Hm ...  I'll try that at home.  Never had that problem before.  There are
still some bugs in GAS but usually only invalid assembler code makes GAS
dump core.

> OK.  I'm going to try to keep them one source base for the moment.  If
> that turns out to be a big pain in the hind quarters, I'll spearate
> them out again.  I'm not even sure how popular the Tyne port will be
> (if at all).  I think that the DECstation port will be the most
> popular of all the ports and we will never get a question about Tynes
> on the list.  BTW, what is the status of the TYNE?  Does Waldorf still
> have it?  Are they looking for a home for it :-)?  Has it been
> repaired?  Is the machine bootable at this point (modulo bugs in the
> Linux port)?

Think I pass the question on to Andy who should know more about the
fate of the board.

   Ralf

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