ylo@ngs.fi (Tatu Yl|nen) (12/28/90)
I want to be able to reboot the pc532 in software (so that with a
future rom revision it could automatically reload the kernel after a
panic).
Is there any way to do this without hardware modifications? (I guess
I could connect a wire from g1/ir2 to the reset pin (perhaps through a
buffer), or use an optoisolator driven from a serial port?)
I would settle with a "soft reset" causing reloading of the kernel.
However, if the code must run in real mode, it should be short, as
writing code to run at "wrong" addresses is painful (the kernel is
mapped at 0x18000000).
Second question: Have I understood correctly that it is difficult to
generate good code for the ns532 that would be loaded above
0x20000000? (gcc for one cannot easily do this). The problem is that
absolute memory references (and displacements) are only 30 bits,
effectively limiting the usable virtual address space to 512 megabytes
(which is not much but probably still sufficient for this board).
Third, I am sometimes getting spurious interrupts on irq1, irq3 and
irq15. Especially those on irq15 seem to correlate with activity on
the serial lines (com0). Does anyone have any ideas how this is
possible? As far as I know, all those irq lines are unused (I can't
find any pullups/downs in the schematic, is this true? If so,
interference from other signals might explain the spurious
interrupts).
Fourth, I would like to be able to order interrupt priorities so that
the timer has the highest priority (I currently have it directed to
irq0), com lines come next, and scsi devices have the lowest priority.
(I might want to switch the order of the timer and comintr if the
uarts lose characters).
If I have understood correctly, the icu does not directly support
arbitrary priorities. I can "simulate" this my masking off lower
priority interrupts (in set_spl (related to spl1, splx etc)) and
setting IF in psr, but then I need to make ICU allow the interrupts it
thinks are lower-priority. I can do this by reading HVCT (I think).
However, to prevent same level interrupts I now have to keep
interrupts disabled from later set_spl to rett to prevent same level
interrupts from overflowing the kernel stack (which requires a
specialized version of set_spl). Could someone verify if my thinking
about HVCT is valid?
Below is the interrupt handler I am using (HVCT kludge code commented
out). (I am using direct non-vectored mode, r3-r7 callee-saved, gcc
assumes sb contains 0).
ENTRY(t_nvi_interrupt)
enter [r0,r1,r2],0
sprd sb,tos
lprd sb,0 /* some C code may expect this */
movd @EX(pic_addr),r0 /* get icu addr */
movb ICU_SVCT(r0),r1 /* get interrupt vector number */
/* movb ICU_HVCT(r0),r0 /* acknowledge interrupt to icu */
andd 0xf,r1
movzbd @EX(intpri)[r1:b],r0 /* get interrupt priority */
movd r1,tos /* save vector */
bsr EX(set_spl) /* set spl */
movd tos,r1 /* get vector */
movd 8(fp),tos /* psr at interrupt (see hardclock.c) */
movd r0,tos /* save old spl level (arg 2) */
movd r1,tos /* save vector (arg 1) */
movd @EX(ivect)[r1:d],r2 /* get handler address */
jsr 0(r2) /* call interrupt handler */
adjspb -4 /* remove vector from stack */
movd tos,r0 /* old ipl */
bsr EX(set_spl) /* reset ipl to old value */
adjspb -4 /* remove psr from stack */
lprd sb,tos
exit [r0,r1,r2]
reti
/* rett 0 /* sic! We have already acknowledged */
/* the interrupt and thus cannot use */
/* reti */
Tatu Ylonen <ylo@cs.hut.fi>