Re: rtVAX300 .. need help..

[Holm Tiffe <holm%freibergnet.de@localhost>]

Roger Ivie wrote:

> On Tue, 8 Jan 2013, Holm Tiffe wrote:
> >I know you are all here looking what happens but "without a little help
> >from my friends.."
> 
> Well, speaking only for myself, I'm pretty much a NetBSD dilettante.
> I've been using it for *ages*, but I've never really done any kernel
> hacking on it.
> 
> I've done plenty of work with raw VAX hardware and with VMS, but all my
> VAX related work was done a long, long time ago. The memory fades.
> 
> >Are there further hints what I should do with this VS_REGS mapping?
> >Is it normal for an VAX CPU or for the CVAX to have memory mapped
> >registers? Why are VAX49 and VAX53 are using an different address?
> 
> Addresses are typically whatever happened to be convenient for the
> system designer. For busless systems, there weren't a lot of conventions
> followed.
> 
> I stumbled onto an example of these differences between the VAXstation
> 4000/60 (I suppose that'd be a KA46) and the /90 when I was working up
> some code to bit-bang a serial console intended for a little NVAX
> processor module designed to fit into the CPU socket of an AlphaStation
> 250mumble. I prototyped the thing on the /60 using the modem control
> lines of the communications port. When I tried it on the /90, I
> discovered A) that the flash on the /90 occupied the space taken by the
> console on the /60 and that B) fiddling with the modem control signals
> at the /60 address erased the flash on a /90.
> 
> Of course, what really got me in trouble was fixing it. Since the flash
> was really close to the power connector on the /90s, we installed
> sockets. Turned out the machine was on a maintenance contract and Field
> Circus was Not Amused.
> 
> >#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
> 
> I don't have any documentation on the /90, but one thing I discovered
> when I designed the TURBOchannel adapter for the /60 (which was also
> used in the /90) was that the /90 uses edge-triggered interrupts instead
> of level-triggered. I worked around that in my own VMS device drivers by
> fiddling with an interrupt enable bit in the TURBOchannel adapter (after
> servicing an interrupt, I would clear and set the interrupt enable so
> that a new edge would be created on a /90 if the interrupt was still
> asserted).
> 
> These registers are presumably used for that sort of interrupt
> management on those platforms.
> 
> These registers would wind up in whatever FPGA they designed to support
> the system. These would be system-specific, so they would very from
> system to system.
> -- 
> roger ivie
> rivie%ridgenet.net@localhost

Yea, I've read something from the 4000/90, NetBSD and empty Flash in the
past, ...seems the same as you described here and someone has changed the
Mapping of that VS_REGS from 0x2008000 to 0x25c00000 because of exactly
this issue.. Who was this?

So I'm right with the assumption that those internal regs of the CPU are not
internal regs, that are registers for interrupt control ans something in a
system support device that's mapped somewhere in the memory?

There is a "Memory System CSR" at 20110000 .. 20110004 in the docs,
and I should search for an Interrrupt Status/Control register set and
something related to DMA?

Regards,

Holm
-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741