Re: rtVAX300 .. need help..

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

Holm Tiffe wrote:

> 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

....


The Interrupt System:

3.1.10  Interrupt Control

The IRQ<3:0> L, HLT L, and PWRFL L inputs to the processor ant three
registers ( ...hrrmmm.. wich ones?) control the hardware interupt system.
Asserting any of the input pins generates an interrupt at the hardware
level given in Table 2-4. The three registers are used to control the
software interrupt system.

3.1.11 Internal Hardware Interrupts

The rtVAX 300 10ms interval timer interrupts at IPL16 and the Ethernet
coprocessor can interrupt the rtVAX 300 at IPL15. These interrupts have
higher priority that IRQ<2> L and IRQ<1> L wich also interrupt at IPL16 and
IPL15.

3.1.12 Dispatching Interrupts: Vectors

The system control block is a page-aligned table containing the vectors
used to dispatch exeptions and interrrupts to the appropriate service
routines.
Only device vectors in the range of 100 to 7ffc should be used, except by
devices emulating console storage and terminal hardware. The console
reserves vectors 0xc0 to 03cc and interrrupts at IPL14 by means of IRQ<0>
L.
The rtVAX 300 internal Ethernet coprocessor can interrupt at IPL15. This
interrupt is daisy-chained to the external interrrupt request IRQ<1> L and
is serviced before IRQ<1> L. The vector is set by writing to the Ethernet
coprocessor CSR0 register at location 20180000.

3.1.12.1 Interrupt Action
Interrupts can be devided into two classes: nonmaskable, and maskable.

Ninmaskable interrupts cause a halt trough the hardware halt procedure
which saves the PC, PSL, MAKEN<0>, and halt code in IPRs, raises the
processor IPL to 1F, and then passes the control to the resident firmware.

...

Is it possible that the ominous 0x2008000 mapping is simple the System
Control Block with the vectors?

Here is Table 3-4

Priority Level  Interrrupt Condition            SCB Offset
Nonmaskable     Reset asserted                  Note a)
                HLT asserted                    Note b)
1F              unused
1E              PWRFL L asserted                0c
1D-18           unused
17              IRQ<3> L asserted               Device Vector on DAL<15:02> H
16              Interval Timer interrrupt       c0
                IRQ<2> L asserted               Device Vector on DAL<15:02> H
15              Ethernet coprocessor int        Vector placed in SGEC CSR0
                IRQ<1> L asserted               Device Vector on DAL<15:02> H
14              Console Terminal                02c0
                IRQ<0> L asserted               Device Vector on DAL<15:02> H
13-10           unused
0f-01           Software interrupt req.         84-BC

Note a) This condition forces execution to the resident firmware's dispatcher
with a halt code of 3 (hardware reset)

Note b)This condition forces execution to the resident firmware's dispatcher 
with a halt code of 2 (external halt)

Three IPRs control the interrupt system: IPR18, the interrupt priority
level register (IPL), IPR20, the software interrupt request register
(SIRR), and IPR21, the software interupt summary register (SISR). The IPL
is used for loading the processor priority. The SIRR is used for generating
software interrupt requests. The SISR records pending software interrupt
requests at levels 1 trough 15.

....

3.1.12.5 System Control Block

..IPR17 .. the system control block base register (SCBB) points to the SCB.

...


In the code above we see 

  sc->sc_intreq = (char *)sc->sc_vsregs + 12;
  sc->sc_intclr = (char *)sc->sc_vsregs + 12;
  sc->sc_intmsk = (char *)sc->sc_vsregs + 8;

so this seems to me like an system interrupt controller that just not exist
in my acrtual hardware....?

What do you think?

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