Re: About support for rtVAX300

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

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...

> > 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.

> > 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.

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/}