Re: rtVAX300 .. need help..

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

Johnny Billquist wrote:

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

... and that was the cause form me to ask here (nicely?) after reading that
comment in the header file ..if this is normal...

:-)

Now we have closed the circle.

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

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

Yes. I wouldn't build an generic kernel for now, leaving vsbus, BI and
other things out of the config file. I know of findcpu.c and modified it
already to make the standalone boot work, I'm aware auf autoconf.c and
friends.
> 
> >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.

The generic kernel just halts (as expected) since the CPU isn't supported
(findcpu has no match for it) and there is no console to say anything.

Aaach Johnny, the rtVAX Board has an SCN2681 as console UART that no other
VAX expect the VXT2000 in OpenBSD has, and the VXT2000 has an descendand of
the SCN2681 wich makes some things clear:

1. I don't have any working console code in the NetBSD Generic kernel, nor
on the entire arch/vax system.

2. There is a SCN2681 (or similar) driver somewhere in the NetBSD AMIGA [note]
arch, that should also usable in general but the OpenBSD Driver looked somewhat
cleaner at first. Maybe it turns out that this isn't really the case, since
OpenBSD has a different and also unknown to me device driver interface.

3. at first I need to make the kernel print out something.

4. on an unknown OS with no docs for the HW this is impossible.


The modified standalone boot I made used for the console in- and output
some ROM routines that Mouse found while disassembling the ROM code I
read out of that rtVAX brick.
Before you ask, there are 4 pieces of I28F512 in the CPU itself and
4 DIP28 EPROMs (forgot the Type for now but read them out) additionally on
that board, that are containing the manufactures VAXELN OS, the RTVAX is
able to boot out of that ROMs and from eza0.

The Memory address of those 4 Eproms is documented exactly at 0x20080000
!!! (and you wondered why I had stupid questions)

[note] the string 2681 for the DUART appears also in
mips/sibyte/dev/sbobiovar.h
mips/sibyte/dev/sbscn.c
sgimips/conf/GENERIC32_IP12
sgimips/dev/scn.c
sgimips/dev/scnreg.h
sgimips/dev/scnvar.h
... and I can't find currently the amiga device where this chips is used.

(You find all that information above in this thread)

... is one of the experienced NetBSD kernel hackers here able to port
the sgi scn driver at least in a raw form to the vax mainbus or vsbus or
*smile* rtbus? ..or able to help me with some driver hacking..?

Maybe the sgimips driver is a better starting point since the kernel
interface should already in a usable state.. Interrupts and addressing must
be modified..

I think I can provide the neccessary infos, address and interrupt
structure.. There is no handshaking on the used chip, it is the smallest
variant w/o status lines.
> 
> >>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

Yes and I think that was the primary cause of getting no answers at all.
But at all now the architecture stuff isn't looking that basic anymore
and this ugly comment in the header file raised questions. Please
understand me, I've used the kernel source code from an working Operating
system in his sixt release to gather some information....and this was
wrong...


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