Re: About support for rtVAX300

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

Jochen Kunz wrote:

> On Sat, 12 Jan 2013 11:16:15 +0100
> Holm Tiffe <holm%freibergnet.de@localhost> wrote:
> 
> > That is why NetBSD treats them all as VAX_BTYP_420.
> > That's proably the cause I got confused.
> Additional note: As Ragge pointed out you have to treat your toy as a
> KA650. Thats because the KA650 has a CVAX CPU chip and may in turn be
> used as a placeholder for all machines with this CPU chip... At least
> in some parts of the code...

I've done that in the meantime. But here are still some things to clean up,
eg something like this:

static const char * const ka650_devs[] = { "cpu", "lance", "uba", NULL };
static const char * const ka650RT_devs[] = { "cpu", "rtvbus", NULL };

There is no lance and no uba at the rtvax. so the modified ka650.c will
not work on an ka650 as it is.

> 
> > > 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 :-)
> Well. Thats the way it goes. I didn't hack port-vax in this depth, but
> port-ofppc, port-hp700 and now I am at port-evbarm. The level of
> confusion there is the same. I can understand your frustration. But I
> can't help you. Everyone who starts with this stuff goes through the
> same unpleasant experience.

Hmm...
> 
> > > and influence things like autoconf(9)... In many
> > Yes, hacked the autoconf from the standalone loader already to get it
> > booting over the net.
> Thats not really the kernel autoconf(9).
> 
> > 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.
> autoconf(9) is started later from some machine independent, central
> kernel infrastructure. (IIRC main().) For now this is not yet relevant.
> You need to get a polled console "driver" going first. Later, when
> autoconf(9) is run and finds the real driver for the console, this real
> driver will take over the conmsole IO. Thats future.

I found out that in the meantime for myself. And I'm on that point where I
should write the polled driver for the console.
The Problem is, that I don't understand how the VM-stuff is working, for
every machine in the arch/vax tree this is looking different and I wasn't
able to display something on the TIL311 since vm ist started nor to write
anything to an UART Register.
Why? Don't know. Got no answer here, tried all the things that where
suggested. (I think). I got wheter the vax_map_physmem stuff not the
ioaccess thing to work.

> 
> Try to get some characters out of the console. Or even some output from
> the TIL311. But I can't help you to accomplish this as I have no in
> depth knowledge if VAXen. :-(
> -- 
> 
> 
> \end{Jochen}
> 
> \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

I'll keep reading trough the files for other drivers and other
architectures. I have stolen the driver from sgimis/scn, but there the vm
thing seems to just working.

(Es muß doch möglich sein ein beschissenes Byte an die Peripherie
auszugeben, ich haue den Dreck gleich in die Ecke!)

BTW: The Vax card sits currently in a "BastelPC" that's normaly used to
write 8inch floppies..

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