Re: rtVAX300 .. need help..

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2013-01-10 14:38, Holm Tiffe wrote:
> Johnny Billquist wrote:
>
> > Hi, Holm. I was perhaps a bit harsh in my previous mail. Sorry for that.
> >
> > On 2013-01-10 12:18, Holm Tiffe wrote:
> > > Johnny Billquist wrote:
> > >
> > > [..]
> > The absolute best is to find a technical manual for any uVAX, and look
> > at the register at that address and understand what it contains.
> > Without checking (which means I might be totally wrong here), the
> > comment is somewhat misleading, as I don't think CPU internal means
> > exactly that, but registers that are for control and management on the
> > cpu board.
>
> ...you got it, that's why I asked at all..

Looking at the specific machine the code is for, in combination with 
looking at the code, helps understand why some things exist, and why 
some things are done in a specific way.
Without that information, looking at the code can be pretty hard, and of 
questionable use. We're talking board-specific registers here.

> (is it normal for an VAX CPU to have some internal Registers mapped in the
> address space? .. or some such)

If we talk about CPU internal registers, they are never memory mapped.
That's why the MTPR/MFPR instructions exist.

> > > > However, there are various bus adapters, which maps addresses back and
> > > > forth, which can be relevant, and which you might need to understand
> > > > more about.
> > > > The same goes for the MMU in general, and how buses work.
> > >
> > > At first I'm trying to find out if I need to support some of this stuff at
> > > all. As I wrote above I've created my own bus "rtbus" in that kernel
> > > hierarchy since I don't want to shoot in foots that are not mine.
> >
> > It might be easier to just hook into the existing vsbus code. It's
> > pretty much a "fake" bus as it is, since different VAXstations are
> > pretty dissimilar. NetBSD does various probings and stuff at boot, which
> > is for most parts also taking into consideration what CPU type you have,
> > so unless things are written very bad, you should not be able to wreck
> > anything existing by adding something new.
>
> My rtbus is an vsbus and I'm in the process to delete what I don't need.
> I've created just an directory rtbus and copied the vsbus files in, added
> the OpenBSD qsc driver files and hack around to get this working thogether.
> Wehn I know what I need, I can decide how to integrate this rtbus back in
> the vsbus "architecture". As for the probing, this comes later.
> For now I have to change the OpenBSD device driver interface to fit to
> NetBSD, think about generating interrupts from the UART and attach the
> driver to the console. Later I'm trying to get the ethernet working which I
> think is not that much of work. The very last thing I do is thinking about
> autoprobing.

It's a part of the configuration run as a part of starting NetBSD. You 
cannot ignore it, however you might stub much of it...

But basically, you'd just throw some calls into the attach function of 
the bus, based on machine type, and off you go. That is why it should be 
a piece of cake to graft into the existing vsbus. If you create your own 
bus, you'll need not only to copy the code, you also need to hack into 
the autoconfig system used a boot time.

> As I wrote days before, that thing as an board ID of:
>
> #define VAX_BTYP_RT300  0x0A000009      /* rtVAX 300 */
>
> This identifies the processor brick (CPU Id and SID Extension register
> contents merged in the usual way) but this alone says NOTHING about the
> entire system, since the brick is made to add something external.

But that should uniquely identify the CPU board, which is enough for 
your basic needs. After that, it becomes a question of figuring out what 
peripherals are physically attached.

> That thing is already booting NetBSD netboot code with mop and loading the
> kernel over nfs. Now I want to build a kernel that talks to me over the
> SCN2681 UART chip.

But do you get any further, such as into single-user mode? Or atleast 
getting it to print out a banner, or anything?
Just loading the kernel is not actually telling that much, since the 
boot loader is a standalone application running.

> > Oh, I don't mind you working on getting this done. It's just that it's a
> > big hill from where you are standing, I think. However, given some time
> > and focus, this is definitely doable.
>
> I hope so. And I hope I can count an you here at all.
> I want to hear anything, If I'm wrong, If you don't know oder If you know
> something about something. :-)
> I know that I don't know the most things, but I'll continue to ask.

The usual restriction/problem for most people is time. Asking too many 
big questions about basic architecture stuff takes lots of time to 
answer, as well as being, well, fundamental knowledge one should perhaps 
have before attacking this problem. :-)

        Johnny