[ Don't know if this belongs in the list, please let me know if this
is a problem ]
: 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 :-).
: 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.
: 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...
: 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.
: 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.
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.
: 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.
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)?
: I can't do direct upload to ftp.fnet.fr. 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 :-)
I'll give that a try. While it would be nice to be able to grab the
stuff as soon as you upload it, I have not had a problem with the
response time of Stoned and/or Luc in moving them into the right
places. I'll take a quick peek into that area when I get a chance.
Right now it is time to wonder off to bed. Too much Sushi and Saki
tonight for my own good (which is why I will *NOT* be hacking on the
port tonight :-).
Warner
|