Port-vax archive

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

Re: About support for rtVAX300

On 01/11/2013 10:05 PM, Holm Tiffe wrote:
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..
Yes, I'm 110% sure that you must use KA650, since you have a KA650 :-)
KA410 is something completely different, ignore that.

Do not care about the devices, and vsbus is another thing that you do not need either. The purpose of the vsbus is to keep properties like csr and dma resource maps, which is of no interest for the rt300.

The autoconf system just ignores devices that cannot be found. Nothing bad should happen, the first thing that the probe routines do is to try to access the specific memory space addressed, and if nothing there it gets a machine check and just continue.

..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 :-))
Yep, but that do not matter for you. These are there because it was convenient when someone wrote this code ~25 years ago. They do not hurt. It's for the L2cache (which is external to the CPU) and the SSC (system Support Chip) that you do not have either.

         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?
As others already has pointed out you are trying to write to an invalid address here...

root addr= path=/data/home/exports/rtvax

     PC = 800003F7
  84 FAIL
You should set the machine not to restart after hlt but just halt. Makes debugging easier :-) Here it tries to reboot but fails in the reboot process so all your registers after the halt is clobbered.

Debugging hints here:

Sprinkle with asm("halt"); to trace where it fails. This is useful as long as you do not have a working console.
Then you just type C a the prompt to continue.

You may also add a asm("halt"); in the machine check routine, since the printf routines there won't work.

-- Ragge

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
  * 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)
         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

         .asciz  "SBI fault"


..whats happening here?



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


Home | Main Index | Thread Index | Old Index