[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rtVAX300 .. need help..
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
...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
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
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. :-)
Main Index |
Thread Index |