[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: About support for rtVAX300
On 2013-01-11 22:05, 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
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 :-))
This is just getting some mappings to physical memory setup. Notice the
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
On the very last instruction in pmap_bootstrap()
rpb.sbr = mfpr(PR_SBR);
rpb.slr = mfpr(PR_SLR);
rpb.wait = 0; /* DDB signal */
*(int *)(0x201ffffe)=0xf-3; /* Holm */
*(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?
I assume you do see the '3'?
This is potentially dangerous or bad, since you are writing a 32-bit
value to an address that is just two bytes from the end of a page. You
might very well get a page fault when doing this with virtual memory
Try changing "int" to "short"?
Also, turn on the debugging. That should give you a bunch of information
as soon as simple printing works. And, as ragge pointed out, the most
primitive printing done by the kernel is just polled, so just using the
rom routines for that is perfectly fine.
..whats happening here?
That sure what "here" referred to...
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |