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