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=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.
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
----------------------------------------------------------------
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
[..]
Home |
Main Index |
Thread Index |
Old Index