Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

About support for rtVAX300



Hi Holm et al,

I've been quite busy last days but I'll try to explain some basics that might help you. Maybe others have already written it (lots of mail and I haven't read everything :-)

Anyway, as I see it the fastest way to get started is something like:

1) Fix a define VAX_BTYP_rt300 or so and add it in findcpu.c directly after VAX_BTYP_650 in the switch statement. This get the correct defaults (for machine checks etc). You may have done this already due to the discussions.

2) Add checks in ka650.c:ka650setcache() to not init the L2 cache (as for KA640). The rt300 do not seem to have any L2cache.

3) Add a entry for the console chip in conf.c, in the same way as dz.

4) Write a small driver for sending characters to the console subsystem in kernel mode. Look at vsa/dz_vsbus.c:dzcnputc(), this routine is the one that writes data to the console in kernel mode. This is done by just busy-waiting so it is quite simple.

...then you should get some output :-)

That's the hints I can give right now.  I'm quite busy right now :-/

-- Ragge


On 01/07/2013 06:46 PM, Holm Tiffe wrote:
Anders Magnusson wrote:

On 01/06/2013 09:27 PM, Holm Tiffe wrote:
I have now created a subdirectory below arch/vax named rtv and try to put
the needed stuff in there.
I've copied the qsc files from OpenBSD, removed some stuff that's not
needed (4 Lines in a chip) and will try to integrate that.
Before I can do that I have to make an modified vsbus (since there are some
other adresses on the rtVAX, uncommon to the rest).
I think that if the serial chip on rtVAX are similar enough to the chip
on the VXT2000 then it would be good to have support for both of them in
the same driver.
So far as I've read has the VXT2000 only one interrrupt that is controlled
within the 26C94 Chip with his registers. I don't have those registers
so I have this todo with other things.
Don't forget, it is the console serial line that I'm trying to get to run,
with an architecture I'm not familar with. I have almost no possibilities
to debug this w/o to print something on my screen.

I'm lucky if I can get the 2681 Part running at first, reintegrate the
other things will be step 2. I'm lucky if I see only one char.
There are many other things to port, the device driver calling conventions
for example. Never done this before and never with NetBSD. W/o your all
help this will still be not possible for me...
Also, I think it is no reason to invent a new bus since there will be no
need for it.
The sgec is already in there (at mainbus as ze0)  and adding the serial
driver could be done in the same way.
May be.. but with en extra bus I have things better under control.
I can patch the vsbus thing, but this:


/*
  * Generic definitions for the (virtual) vsbus. contains common info
  * used by all VAXstations.
  */

#ifndef _VAX_VSBUS_H_
#define _VAX_VSBUS_H_

...wouldn't be true  anymore. This is the cause why I'm trying my own bus..
The rtVAX is no VAXstation at all and it's Hardware isn't common with
VAXstations.
The CPU is a CVAX so the same CPU definitions should be possible to use
IMHO.
For this VS_REGS are more than one definition already existing:


         switch (vax_boardtype) {
#if VAX49 || VAX53
         case VAX_BTYP_53:
         case VAX_BTYP_49:
                 sc->sc_vsregs = vax_map_physmem(0x25c00000, 1);
                 sc->sc_intreq = (char *)sc->sc_vsregs + 12;
                 sc->sc_intclr = (char *)sc->sc_vsregs + 12;
                 sc->sc_intmsk = (char *)sc->sc_vsregs + 8;
                 vsbus_dma_init(sc, 8192);
                 break;
#endif

#if VAX46 || VAX48
         case VAX_BTYP_48:
         case VAX_BTYP_46:
                 sc->sc_vsregs = vax_map_physmem(VS_REGS, 1);
                 sc->sc_intreq = (char *)sc->sc_vsregs + 15;
                 sc->sc_intclr = (char *)sc->sc_vsregs + 15;
                 sc->sc_intmsk = (char *)sc->sc_vsregs + 12;
                 vsbus_dma_init(sc, 32768);
#endif

         default:
                 sc->sc_vsregs = vax_map_physmem(VS_REGS, 1);
                 sc->sc_intreq = (char *)sc->sc_vsregs + 15;
                 sc->sc_intclr = (char *)sc->sc_vsregs + 15;
                 sc->sc_intmsk = (char *)sc->sc_vsregs + 12;
                 if (vax_boardtype == VAX_BTYP_410) {
                         dbase = KA410_DMA_BASE;
                         dsize = KA410_DMA_SIZE;
                 } else {
                         dbase = KA420_DMA_BASE;
                         dsize = KA420_DMA_SIZE;
                         *(char *)(sc->sc_vsregs + 0xe0) = 1; /* Big DMA */
                 }

Since the definition of 0x2008000 from vsbus.h is overwritten here
for VAX_BTYP_49 and VAX_BTYP_53 and there is ROM physically on the rtVAX
what should I do? What the heck is thisr:

  #define KA49_SCSIMAP    0x27000000 /* KA49 SCSI SGMAP */

..that's needed by the vsbus_dma things..?

But the best thing is to get running now, then later things can be
cleaned up :-)

-- Ragge
Yes, but it should compile at first, shouldn't it?
There are many things about VAX internals I'm not aware of or
I just not know about them. What is with this internal register mapping?
Is it normal for a VAX that CPU Registers are memory mapped?

Regards,

Holm




Home | Main Index | Thread Index | Old Index