[Top] [All Lists]

Re: Deskstation rPC44 update

Subject: Re: Deskstation rPC44 update
From: Systemkennung Linux <>
Date: Sat, 20 Jan 1996 23:12:23 +0100 (MET)
In-reply-to: <> from "Warner Losh" at Jan 19, 96 11:54:59 pm

> I have enabled the floppy build, and get an undefined reference to
> vdma_alloc from floppy.o.  I do find it defind in jazzdma.h and used
> in a macro in floppy.h.  It will only be called, it seems, if the
> machine is the Pica 61, the Magnum 4000 or the Olivetti M700...
> Sounds like I need a dummy version in the Deskstation stuff.  Is that
> the case?  The Jazz version certainly isn't "dummy" by any streatch of
> the imaginiation.  Looks like I'll have to find out about DMA stuff on
> the Deskstation :-(.  For the moment, I've dummied up something to get
> the kernel to compile.

For the Jazz family of machines vdma_alloc() allocates virtual address
space for the onboard DMA engine on the motherboard.  Since your machine
doesn't have that feature it is sufficient to install a dummy version of
vdma_alloc similar to the one in include/asm-i386/floppy.h.

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?)

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.

> How close are the tyne files to being up to date?  There are a few
> typos in these files, and I was wondering up to date the tyne stuff
> is.  I know that it is hard w/o a working machine, so I don't fault
> any out of datedness in them.  It would be nice to know how much
> debugging I'll have to do with them.  The comment at the top of tyne.S
> isn't giving me much hope for that file, but maybe tyne-c.c is in
> better shape...

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.

> I've also rigged it up so that tyne-c.c and rpc44-c.c use the exact
> same code, modulo one #define that changes the names of the functions.
> I'd do the same for tyne.S and rpc44.S, but the assembler that I have
> here is broken when I try to do that.  Over time they may diverge, but
> I thought this would be the best way to keep the files in sync with
> the moving kernel interface changes.

Broken Assembler?  Maybe it fails to assemble %HI, %hi and %lo operators?
In that case upgrade to my 2.6 patch.  Older versions of my assembler
also have fixed this operators but all FSF/Cygnus versions are broken in
that respect.

That there are two copies of an almost identical file has just the simple
reason that I wanted to give you a place where you can put your stuff
in.  In case the rPC44 and Tyne proof to be very similar or even
identical we also could merge them again.

> Maybe Ralf's new 1.3.58 will help this situation...  I'll give them a
> try as soon as Luc moves them (or is that Stoned?).  In any event, can
> mere mortals grab these before they are moved, or is the incoming
> directory write only?

I can't do direct upload to  So I make then into another
machine and if I remember right my uploads are automatically being
mirrored from there into private/Incoming/ every 20 minutes.  Feel free
to grep my uploads from there before someone else moves them online.
Horrible way to work around Fnet's policy, but at least we have a
FTP site with acceptable bandwidth and nice maintainers :-)

> Thanks for any help and suggestions that you might have.  As always, a
> lead on a good technical doc set for the rPC44 would be nice :-).


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