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:

> On 01/11/2013 10:05 PM, Holm Tiffe wrote:
> >Anders Magnusson wrote:
> >
[..]
> 
> >         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...

... but: *(int *)vax_map_physmem(0x201ffffc,1)=(int)(0xf-4)<<16;

should work. But it doesn't, why?

> 
> >root addr=192.168.50.50 path=/data/home/exports/rtvax
> >2066012+92196=0x20f240
> >
> >?06 HLT INST
> >     PC = 800003F7
> >  85 RESTART SYS
> >  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.

Yes. I should, but I can't. Maybe sometimes I check all the 256
possibilities of that dipswitch register that is on that board, ot maybe I
get a Hardwaremanual for that thing...
> 
> 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
> 

Ok, I'm doing that for now.
[..]
> >
> >
> >>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
> >>
> >>
> >[..]

I looked a little at ka650.c:

struct  ka650_merr *ka650merr_ptr;
struct  ka650_cbd *ka650cbd_ptr;
struct  ka650_ssc *ka650ssc_ptr;
struct  ka650_ipcr *ka650ipcr_ptr;
int     *KA650_CACHE_ptr;
[..]
ka650_conf(void)
{

        /*
         * MicroVAX III: We map in memory error registers,
         * cache control registers, SSC registers,
         * interprocessor registers and cache diag space.
         */
        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,
            (KA650_CACHESIZE/VAX_NBPG));

        ka650setcache(CACHEON);
        if (ctob(physmem) > ka650merr_ptr->merr_qbmbr) {
                printf("physmem(0x%x) > qbmbr(0x%x)\n",
                    ctob(physmem), (int)ka650merr_ptr->merr_qbmbr);
                panic("qbus map unprotected");
        }
        if (mfpr(PR_TODR) == 0)
                mtpr(1, PR_TODR);

*(int *)vax_map_physmem(0x201ffffc,1)=(int)(0xf-7)<<16; /* Holm */
}
....

/*
 * memory error & configuration registers
 */
struct ka650_merr {
        u_long  merr_scr;       /* System Config Register */
        u_long  merr_dser;      /* DMA System Error Register */
        u_long  merr_qbear;     /* QBus Error Address Register */
        u_long  merr_dear;      /* DMA Error Address Register */
        u_long  merr_qbmbr;     /* Q Bus Map Base address Register */
        u_long  pad[59];
        u_long  merr_csr[16];   /* Main Memory Config Regs (16 banks) */
        u_long  merr_errstat;   /* Main Memory Error Status */
        u_long  merr_cont;      /* Main Memory Control */
};
#define KA650_MERR      0x20080000

Woahh!
There is my special friend 0x20080000 again...
This is the same thing as the VS_REGS on the Vaxstation.

Has the not working write to the display something todo with not defined
or disbaled memory regions or so? I mean not defined for a KA650 or a
KA410?

What happens if I map that address 2 or more times? (not saving the pointer to 
the
display somewhere b'cause of laziness?) Have I to unmap them before?

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



Home | Main Index | Thread Index | Old Index