Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: About support for rtVAX300



Anders Magnusson wrote:

> Hi Holm et al,
> 
> I've been quite busy last days but I'll try to explain some basics that 
> might help you.
> Maybe others have already written it (lots of mail and I haven't read 
> everything :-)
> 
> Anyway, as I see it the fastest way to get started is something like:
> 
> 1) Fix a define VAX_BTYP_rt300 or so and add it in findcpu.c directly 
> after VAX_BTYP_650 in the switch statement.
> This get the correct defaults (for machine checks etc).  You may have 
> done this already due to the discussions.

Du you really think that the KA650 is the best decision here?
I'm hacking around for some time with the ka410 as basis wich is also an
CVAX but w/o Lance and QBUS but with something calles vsbus and a SGEC..

..and then the KA650 is again doing stuff like this:

       */
        ka650merr_ptr = (void *)vax_map_physmem(KA650_MERR, 1);
        ka650cbd_ptr = (void *)vax_map_physmem(KA650_CBD, 1);
        ka650ssc_ptr = (void *)vax_map_physmem(KA650_SSC, 3);
        ka650ipcr_ptr = (void *)vax_map_physmem(KA650_IPCR, 1);
        KA650_CACHE_ptr = (void *)vax_map_physmem(KA650_CACHE,

..so there are some "misc CPU internal Registers" again :-))

On the rtvax is a register for the TIL311 Display, I can write an
~0xa to 0x201ffffe and see an 'A', with that I've tried to trace
the startup code a little, but I get lost in pmap_bootstrap() called from
locore.c.
On the very last instruction in pmap_bootstrap()

            VM_FREELIST_DEFAULT);
        mtpr(sysptsize, PR_SLR);
        rpb.sbr = mfpr(PR_SBR);
        rpb.slr = mfpr(PR_SLR);
        rpb.wait = 0;   /* DDB signal */

         *(int *)(0x201ffffe)=0xf-3; /* Holm */

        mtpr(1, PR_MAPEN);

         *(int *)vax_map_physmem(0x201ffffe,1)=0xf-4; /* Holm */
}

Nothing happens anymore and I get a trap or something like this..
I never see that '4', regardless if I try vax_map_physmem or not.
Is vax_map_physmem() the right thing to this time?

root addr=192.168.50.50 path=/data/home/exports/rtvax
2066012+92196=0x20f240

?06 HLT INST
    PC = 800003F7
 85 RESTART SYS
 84 FAIL
>>> 

>>>e/l/g/n:f r0

  G 00000000  00000000
  G 00000001  00000000
  G 00000002  000001F7
  G 00000003  00000020
  G 00000004  000001F7
  G 00000005  00000000
  G 00000006  00000000
  G 00000007  801F2620
  G 00000008  80000580
  G 00000009  00000004
  G 0000000A  801F2824
  G 0000000B  00000000
  G 0000000C  80000578
  G 0000000D  8000054C
  G 0000000E  800004B0
  G 0000000F  800003F7

----------------------------------------------------------------

 *(.text .stub .text.* .gnu.linkonce.t.*)
 .text          0x80000000      0x55d intvec.o
                0x80000000                kernbase
                0x80000000                rpb
                0x80000200                Xmcheck
                0x80000284                Xinvkstk
                0x8000028c                Xprivinflt
                0x8000029c                Xxfcflt
                0x800002a4                Xresopflt
                0x800002ac                Xresadflt
                0x800002b4                Xchmx
                0x800002bc                Xtransl_v
                0x800002dc                Xaccess_v
                0x8000030c                Xtracep
                0x80000314                Xbreakp
                0x8000031c                Xarithflt
                0x80000324                Xsyscall
                0x8000036c                Xcmrerr
                0x8000037c                Xsbiflt
                0x80000388                Xastintr
                0x80000390                Xddbtrap
                0x80000398                Xhardclock
                0x800003f5                sret
                0x80000413                emtable
                0x80000524                Xemulate
 *fill*         0x8000055d        0x3 0101
 .text          0x80000560      0x3cd subr.o
----------------------------------------------------------------
intvec.S
/*
 * Main routine for traps; all go through this.
 * Note that we put USP on the frame here, which sometimes should
 * be KSP to be correct, but because we only alters it when we are 
 * called from user space it doesn't care.
 * _sret is used in cpu_set_kpc to jump out to user space first time.
 */
        .globl  _C_LABEL(sret)
Xtrap:  pushr   $0xfff
        mfpr    $PR_USP, -(%sp)
        pushl   %ap
        pushl   %fp
        pushl   %sp
        calls   $1, _C_LABEL(trap)
_C_LABEL(sret):
        movl    (%sp)+, %fp
        movl    (%sp)+, %ap
        mtpr    (%sp)+, $PR_USP
        popr    $0xfff
        addl2   $8, %sp
        mtpr    $IPL_HIGH, $PR_IPL      # Be sure we can REI
        rei

sbifltmsg:
        .asciz  "SBI fault"

----------------------------------------------------------------


..whats happening here?

Regards,

Holm


> 
> 2) Add checks in ka650.c:ka650setcache() to not init the L2 cache (as 
> for KA640).  The rt300 do not seem to have any L2cache.
> 
> 3) Add a entry for the console chip in conf.c, in the same way as dz.
> 
> 4) Write a small driver for sending characters to the console subsystem 
> in kernel mode.  Look at vsa/dz_vsbus.c:dzcnputc(), this routine is the 
> one that writes data to the console in kernel mode.  This is done by 
> just busy-waiting so it is quite simple.
> 
> ...then you should get some output :-)
> 
> That's the hints I can give right now.  I'm quite busy right now :-/
> 
> -- Ragge
> 
> 
[..]
-- 
      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



Home | Main Index | Thread Index | Old Index