[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rtVAX300 .. need help..
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:
> >>Just a few short comments. The VAX internal registers are not memory
> >>mapped, ever. That would be against the architecture specification.
> >>There are special instructions you use to access the processor internal
> >That's what I understood reading the available docs, but since I'm doing a
> >lot of UTSL while trying to find out how other people done with other
> >VAXes, there are questions come up when I read code like this:
> >/* $NetBSD: vsbus.h,v 1.18 2008/03/11 05:34:02 matt Exp $ */
> > * Some chip addresses and constants, same on all VAXstations.
> > */
> >#define VS_CFGTST 0x20020000 /* config register */
> >#define VS_REGS 0x20080000 /* Misc CPU internal regs */
> >#define NI_ADDR 0x20090000 /* Ethernet address */
> >#define DZ_CSR 0x200a0000 /* DZ11-compatible chip csr */
> >#define VS_CLOCK 0x200b0000 /* clock chip address */
> >#define SCA_REGS 0x200c0000 /* disk device addresses */
> >#define NI_BASE 0x200e0000 /* LANCE CSRs */
> >#define NI_IOSIZE (128 * VAX_NBPG) /* IO address size */
> >#define KA49_SCSIMAP 0x27000000 /* KA49 SCSI SGMAP */
> >"Misc CPU internal regs" mapped at 0x20080000 in the address space.
> >I've asked about three times how this could be meant since I found nowhere
> >that CPU Registers are got mapped to memory addresses.
> >The rest of the definitions are straight forward, no question about that.
> 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..
(is it normal for an VAX CPU to have some internal Registers mapped in the
address space? .. or some such)
> >>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
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.
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.
> What you need is a way to recognize your specific CPU, have a unique
> identifier for it, then specify what bus structure you have, and write
> code that probes for things on that bus for which there isn't already
> code, and then your cpu-specific code to do operations on your CPU. That
> can probably be copied in parts from other similar CPUs.
> >>Sorry that I can't be of more help. The questions you ask are just going
> >>to take too much time to work through. You can sit down with an existing
> >>CPU implementation and start by understanding that one (the uVAX II for
> >>example), and then, once you understand the details of that one, you
> >>should have a pretty straight forward time of getting your board up and
> >>running. If you don't have the time for those studies, I doubt you'll
> >>pull this off.
> >> Johnny
> >Johnny I could sit down reading manuals, searching for more manuals,
> >trying to learn all about the internal structures of stone age computers
> >until I'm old and gray (...I'm already got some grey hair, I'm 49,
> >getting 50 in march this year) or I can try just to ask exactly here,
> >where I could meet people that are knowing about this stuff, are fans of
> >that stuffi, with long known to me names are and hoping for some help from
> >We all here, inclusive me know that what I wan't todo is good for nothing
> >at all, It wouldn't save the planet or our children, I't wouldn't kick the
> >US people to shredder their weapons, it woudn't influence Kim Jong Un or
> >Ahmadinejad's opinions, nor it will generate soe cash.
> >It is only fun and it pushes people from all over the world to talk
> >How would you decide?
> 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.
> Quite honestly, I wouldn't care much about those registers you see in
> other implementations. Check what registers and stuff you have on your
> CPU, and start with the basic stuff from there.
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
Main Index |
Thread Index |