Port-vax archive

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

Re: rtVAX300 .. need help..



Kenn Humborg wrote:

> > 
> > /*      $NetBSD: vsbus.h,v 1.18 2008/03/11 05:34:02 matt Exp $ */
> > [..]
> > /*
> >  * Some chip addresses and constants, same on all VAXstations.
> >  */
> > #define VS_CFGTST       0x20020000      /* config register */
> > #define VS_REGS         0x20080000      /* Misc CPU internal regs */
> > #define NI_ADDR         0x20090000      /* Ethernet address */
> > #define DZ_CSR          0x200a0000      /* DZ11-compatible chip csr */
> > #define VS_CLOCK        0x200b0000      /* clock chip address */
> > #define SCA_REGS        0x200c0000      /* disk device addresses */
> > #define NI_BASE         0x200e0000      /* LANCE CSRs */
> > #define NI_IOSIZE       (128 * VAX_NBPG)    /* IO address size */
> > 
> > #define KA49_SCSIMAP    0x27000000      /* KA49 SCSI SGMAP */
> > /*
> > 
> > 
> > "Misc CPU internal regs" mapped at 0x20080000 in the address space.
> > I've asked about three times how this could be meant since I found nowhere
> > that CPU Registers are got mapped to memory addresses.
> > The rest of the definitions are straight forward, no question about that.
> 
> Back when I was hacking on Linux for VAX, I learned the following
> (which may or may not be 100% true!):
> 
> VAXstation-class machines (KA4x-serial CPUs, not the
> QBus-based MicroVAX-2/3 machines with KA630 and KA650) have 
> nearly everything on one motherboard.  There isn't a proper
> VAX-style bas adapter that interconnects from the CPU's bus
> to a peripheral bus (such as the CQBIC on a KA650, which
> performs hardware mappings between address and interrupts
> on the CPU side and the QBus side).  However, there is a 
> smaller amount of simpler logic that sits between the 
> interrupt output lines from the peripherals (such as 
> UART, SCSI controller, Ethernet controller) and the interrupt
> input lines on the CPU.
> 
> The registers mapped at 0x20080000 control this interface 
> logic. 
> They have nothing to do with "CPU internal registers".
> In the VAX world, CPU internal registers means the bits you
> access via the MTPR and MFPR instructions.  I think the
> comment in the NetBSD source is misleading here.

That is the information I wanted. THX.
So as I already wrote I can delete the code related to this.

> 
> See comments here for more details:
> 
> http://linux-vax.cvs.sourceforge.net/viewvc/linux-vax/kernel-2.5/drivers/vax
> /bus/vsbus.c?view=markup
> 
> Your CPU is a KA620, so I would not expect the surrounding 
> hardware to be similar to a KA4x.  It's possible, but I 
> wouldn't use it as a starting assumption.

No, it isn't a KA620, it is a little VAX brick with an CVAX in it,
that was sold as module to used in embedded computers.

Here again  lins to some pictures:

http://www.tiffe.de/robotron/VAX/rtVAX300-internal-1.jpg
http://www.tiffe.de/robotron/VAX/rtVAX300-internal-2.jpg
http://www.tiffe.de/robotron/VAX/rtVAX300-internal-3.jpg
http://www.tiffe.de/images/11122012114.jpg

> 
> Does the manual you have mention address 0x20080000 at all?

..hmm, yes, but with a total different context.
This address is the base address of user ROM Space, the place where the OEM
can add the VAXELN OS and his own code. Since the Address interfered with
that  "register" above, I wanted to know what exactly is going on here.
> 
> Later,
> Kenn
> 

Thank you,

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



Home | Main Index | Thread Index | Old Index