Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: About support for rtVAX300
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
Home |
Main Index |
Thread Index |
Old Index