Re: About support for rtVAX300

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

Mouse wrote:

> >> As of 5.1 (the most recent source tree I have at hand), if init
> >> finds /dev/console missing, it forks a process to run
> >> ./sh ./MAKEDEV -MM init (in /dev/), or if ./MAKEDEV isn't executable
> >> then /etc/MAKEDEV.  Exit code 11 means that even after running that,
> >> /dev/console still doesn't exist.
> 
> Oops.  The leading "./sh" should be just "sh":
> 
>                         (void)execl(INIT_BSHELL, "sh",
>                             access("./MAKEDEV", X_OK) == 0
>                                 ? "./MAKEDEV" : "/etc/MAKEDEV",
>                             "-MM", "init", NULL);
> 
> (Not that this makes a big difference.  I just don't like to let a
> mistake stand - though I was going to ignore it when I had no other
> reason to post.)

No Problem at all, I know MAKEDEV and that in /dev is no shell at all.

> 
> > At least I could made some devices with mknod, don't know if this is
> > the right way, since if my memory is correct they have to be created
> > with the tools from the target OS.
> 
> Yes and no.  When they're on local disk, it's important that the
> mapping between major/minor numbers and the on-disk data match what the
> target OS uses.  But you're over NFS.  I can't recall whether NFS
> carries major/minor numbers or a single dev_t value, but for devices
> with small major and minor numbers (which includes everything critical
> for single-user use) you probably can get away with using the server's
> mknod (and/or running MAKEDEV there).
> 
> > Init doesn't complain about a missing /dev/console anymore.
> 
> Yesssss...but if the major/minor numbers are wrong, output may not be
> going anywhere useful.  It sounds to me as though your system is
> crashing before you're to the point where userland would normally write
> anything, so it's hard to tell, yet, whether it's right.
> 
> /~\ The ASCII                           Mouse
> \ / Ribbon Campaign
>  X  Against HTML              mouse%rodents-montreal.org@localhost
> / \ Email!         7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

...hmm no.
I know that the problem is in the scn driver. At least init should be
running at this time as it's own process.
Something is calling scnwrite() but only scncputc()and scncgetc() are usable
to this time. Even the scn_match() wasn't successful at this time since it
couldn't :-)

scn_match(device_t parent, struct cfdata *cf, void *aux)
{
        struct mainbus_attach_args *ma = aux;
        if ((mach_type == MACH_SGI_IP6 || mach_type == MACH_SGI_IP10) &&
                 ma->ma_addr == 0x1fb80004)
                return (1);
               
        return (0);
}
#else
int
scn_match(device_t parent, cfdata_t cf, void *aux)
{
        struct mainbus_attach_args *ma = aux;
        if ((vax_boardtype== VAX_BTYP_RT300) &&
                ma->ma_addr == 0x20100000) { /* ???  Holm */
                aprint_normal("scn_match successful\n");
                return (1);
        }

        return (0);
}

The first came from sgimips (as easy to see), the later where my try to
port that to the vax, but things are entirely different here now, since
I deleted the rtvbus stuff now and the mainbus has only entries to a
devreg[] tab where the devices at the mainbus that are listed in ka650.c
(for example)sare avialable and no csr's.

The dz_vsbus driver is working with the polled version until mfpr(PR_MAPEN) 
isn't
returning 0 anymore and is then attaching the driver from
sys/dev/dec/dz.c automaically (if I got this correctly).
Ohh man, what a hassle, and this for an "experienced" driver writer like me...

The light at the end of the tunnel is still very small and dark to this
time..

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