Re: About support for rtVAX300

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

Jochen Kunz wrote:

> On Sat, 12 Jan 2013 07:59:54 +0100
> Holm Tiffe <holm%freibergnet.de@localhost> wrote:
> 
> > there is no ka42A or B in that code (are they supported at all?)
> The VAXstation 3100m30 (KA42-A) is supported for well over a decade.
> The VAXserver 3100 (KA41-B) is basicly the same machine without
> graphics. KA41-E is a VAXserver 3100 with CVAX+. The KA42-B variants
> are nearly identical, but feature a faster CVAX+ CPU. (90 ns versus
> 60 ns cycle time.) That is why NetBSD treats them all as VAX_BTYP_420.

That's proably the cause I got confused.

> 
> The next generation is the Rigel CPU as used in KA43-A (VAXstation
> 3100m76), KA670 (VAX4000m300) and KA64A (VAX6400).
> 
> VAX hardware reference:
> http://www.netbsd.org/docs/Hardware/Machines/DEC/vax/
> 
> To maximize confusion: KA42 variatnts have similarity to the KA410 of
> the previous generation (UVII / VAXstation 2000). Thats why you can
> find CVAX stuff in vax/ka410.c...
> 
> Sorry, I lost where you are and where you have been. Too many mails
> overflowing my brain. ;-)

This doesn't even look better from my side of view :-)

> There are some global variables, have a look at the end of
> src/sys/arch/vax/include/sid.h


Yes:

#define VAX_BTYP_650    0x0A000001      /* MicroVAX 3500, 3600 */
     /* VAX_BTYP_65D    0x0A000001         VAXstation 3200, 3500 XXX */
     /* VAX_BTYP_640    0x0A000001         MicroVAX 3300, 3400 XXX */
     /* VAX_BTYP_655    0x0A000001         MicroVAX 3800, 3900 XXX */
#define VAX_BTYP_9CC    0x0A000002      /* VAX 6000 model 210/310 */
#define VAX_BTYP_60     0x0A000003      /* VAXstation 3520, 3540 */
#define VAX_BTYP_420    0x0A000004      /* VAXstation 3100 models 10 - 48
*/
#define VAX_BTYP_IS1    0x0A000006      /* Infoserver 1000 */
#define VAX_BTYP_510    0x0A000007      /* VAXft model 110 */
     /* VAX_BTYP_520    0x0A000007         VAXft model 310 */
#define VAX_BTYP_RT300  0x0A000009      /* rtVAX 300 */
/*

The SID Extension Register contains 

>>> e/l 20040004

  P 20040004  09110002


> They are used to encode various aspects of the hardware. Thay are setup
> in vax/findcpu.c 

case VAX_TYP_UV2:
        case VAX_TYP_CVAX:
        case VAX_TYP_RIGEL:
        case VAX_TYP_MARIAH:
        case VAX_TYP_NVAX:
        case VAX_TYP_SOC:
                vax_siedata = *(int *)(0x20040004);     /* SIE address */
                vax_boardtype |= vax_siedata >> 24;

                switch (vax_boardtype) {
                case VAX_BTYP_420: /* They are very similar */
                case VAX_BTYP_410:
                case VAX_BTYP_43:
                case VAX_BTYP_46:
                case VAX_BTYP_48:
                case VAX_BTYP_IS1:
                        vax_confdata = *(int *)(0x20020000);
                        vax_bustype = VAX_VSBUS;
                        break;
                case VAX_BTYP_49:
                        vax_confdata = *(int *)(0x25800000);
                        vax_bustype = VAX_VSBUS;
                        break;

                case VAX_BTYP_9CC:
                case VAX_BTYP_9RR:
                case VAX_BTYP_1202:
                case VAX_BTYP_1302:
                        vax_bustype = VAX_XMIBUS;
                        break;

                case VAX_BTYP_670:
                case VAX_BTYP_660:
                case VAX_BTYP_60:
                case VAX_BTYP_680:
                case VAX_BTYP_681:
                case VAX_BTYP_630:
                case VAX_BTYP_650:
                case VAX_BTYP_53:
                        vax_bustype = VAX_IBUS;
                        break;
                case VAX_BTYP_RT300:
                        vax_bustype = VAX_RTVBUS;
                        break;

> and influence things like autoconf(9)... In many

Yes, hacked the autoconf from the standalone loader already to get it
booting over the net. But I don't know where that autoconf routines 
for the kernel are getting called and that's what I try to trace what
is happening in that code at all.
As far as I know the first thing is locore.c where that pmap thing is
called. locore.c is calling main() at his end wich is in init_main.c
where some of the first things is to initialize the console..
autoconf.c is full of printf's and aprint_normal so this should be come
later.

Ragge wrote that I sould place some asm"halt"s in the code to trace that,
ok I'll try this, but it where really nice If I could find a way to display
something on that TIL311 after the VM System is started. Nobody knows how?

> places information from these variables is taken for hardware
> configuration, not only CPU chip or boardtype. But most likely you have
> been there already.
> -- 
> 
> 
> \end{Jochen}
> 
> \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Hmm, If I wheren't, I couldn't load something over the net,
but this all was in physical memory.

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