Hi,
Our board is based on the PPC405GP CPU. The 0-31 Interrupts are reserved for
mainboard and PCI purpose.
How can I map ISA irqs 0-15 to system 32-47?
The ISA irqs are handled by Intel Southbridge PIIX4.
Regards,
Jacek
Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
Hi,
Our board is based on the PPC405GP CPU. The 0-31 Interrupts are reserved for
mainboard and PCI purpose.How can I map ISA irqs 0-15 to system 32-47?
The ISA irqs are handled by Intel Southbridge PIIX4.
These mappings are done in the init_intrinfo() routine of the startup code.
The “Building Embedded Systems” documentation has further details.
Regards,
Jacek
–
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
These mappings are done in the init_intrinfo() routine of the startup
code.
The “Building Embedded Systems” documentation has further details.
I have never configured such mappings before.
Here is our irqs mappings:
PPC405 Interrupt number | Usage
0-24 | PPC405 internal devices
25 | interrupt from PIIX4
(Master PIC)
26 | interrupt from DUART
27 | external IRQ2
28-31 | PCI INTA, INTB, INTC, INTD
this part works fine.
We want to add external:
32-47 | ISA interrupts
So, I have a couple of questions:
-
Do I need to write own set of callouts for external 32-47 isa intrs?
I mean &interrupt_id/eoi/mask/unmask_ext_isa routines. -
Can anybody explain how to properly set cascade vector?
Jacek
Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
These mappings are done in the init_intrinfo() routine of the startup
code.
The “Building Embedded Systems” documentation has further details.I have never configured such mappings before.
Here is our irqs mappings:
PPC405 Interrupt number | Usage
0-24 | PPC405 internal devices
25 | interrupt from PIIX4
(Master PIC)
26 | interrupt from DUART
27 | external IRQ2
28-31 | PCI INTA, INTB, INTC, INTDthis part works fine.
We want to add external:
32-47 | ISA interruptsSo, I have a couple of questions:
- Do I need to write own set of callouts for external 32-47 isa intrs?
I mean &interrupt_id/eoi/mask/unmask_ext_isa routines.
You shouldn’t need to write the interrupt callouts from scratch, since there
have been other BSPs that use this style of interrupt setup.
For an example of a PPC BSP that implements an 8259 style interrupt controller,
I’d suggest that you download the Sandpoint BSP.
- Can anybody explain how to properly set cascade vector?
The cascade vector is set in the init_intrinfo() routine. It is the third parameter
in the intrinfo structure, for the interrupt controller you are describing. For example,
if your PIIX4 interrupt controller output goes to PPC405 interrupt 25, then the third
parameter of the intrinfo entry for your PIIX4 interrupt controller would be 25. For the
top level interrupt controller (the one which connects to the CPU), the cascade vector
is _NTO_INTR_SPARE. The first two parameters of the intrinfo entry describe the start
vector, and the number of vectors on that controller, respectively. So, for the PPC405
interrupt controller, the first three parameters would be:
_NTO_INTR_CLASS_EXTERNAL,32,_NTO_INTR_SPARE
_NTO_INTR_CLASS_EXTERNAL is defined as 0 (in /usr/include/sys/neutrino.h)
for the PIIX4 controller, the first three parameters would be:
32,16,25
Note that it is not necessary for the interrupt numbers to run contiguously between
two different controllers; with ISA style interrupts, we will often start them at
100, so that the interrupt numbers look like “normal” x86 numbers, just offset by
100. So, for example, the UART interrupts would be 104 and 103, instead of 4 and 3.
In this case, the intrinfo parameters describing the PIIX4 would be:
100,16,25
Jacek
–
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
Hi Dave,
Now I’m looking at the Sandpoint BSP source.
Why the SANDPOINT_PIB_BASE is defined in two different ways:
- SANDPOINT_PIB_BASE 0xfe000000 (init_intrinfo.c),
- SANDPOINT_PIB_BASE 0x36000000 (callout_interrupt_sandpoint.s)
?
What is an application of the SANDPOINT_PCI_INTACK 0x36ff0030 value?
What is hidding behind it?
Is there any method for interrupt callouts code debugging?
Regards,
Jacek
U¿ytkownik “Dave Green” <dgreen@qnx.com> napisa³ w wiadomo¶ci
news:df74jh$s6j$1@inn.qnx.com…
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
These mappings are done in the init_intrinfo() routine of the startup
code.
The “Building Embedded Systems” documentation has further details.I have never configured such mappings before.
Here is our irqs mappings:
PPC405 Interrupt number | Usage
0-24 | PPC405 internal devices
25 | interrupt from PIIX4
(Master PIC)
26 | interrupt from DUART
27 | external IRQ2
28-31 | PCI INTA, INTB, INTC,
INTDthis part works fine.
We want to add external:
32-47 | ISA interruptsSo, I have a couple of questions:
- Do I need to write own set of callouts for external 32-47 isa intrs?
I mean &interrupt_id/eoi/mask/unmask_ext_isa routines.You shouldn’t need to write the interrupt callouts from scratch, since
there
have been other BSPs that use this style of interrupt setup.
For an example of a PPC BSP that implements an 8259 style interrupt
controller,
I’d suggest that you download the Sandpoint BSP.
2) Can anybody explain how to properly set cascade vector?The cascade vector is set in the init_intrinfo() routine. It is the third
parameter
in the intrinfo structure, for the interrupt controller you are
describing. For example,
if your PIIX4 interrupt controller output goes to PPC405 interrupt 25,
then the third
parameter of the intrinfo entry for your PIIX4 interrupt controller would
be 25. For the
top level interrupt controller (the one which connects to the CPU), the
cascade vector
is _NTO_INTR_SPARE. The first two parameters of the intrinfo entry
describe the start
vector, and the number of vectors on that controller, respectively. So,
for the PPC405
interrupt controller, the first three parameters would be:_NTO_INTR_CLASS_EXTERNAL,32,_NTO_INTR_SPARE
_NTO_INTR_CLASS_EXTERNAL is defined as 0 (in /usr/include/sys/neutrino.h)
for the PIIX4 controller, the first three parameters would be:
32,16,25
Note that it is not necessary for the interrupt numbers to run
contiguously between
two different controllers; with ISA style interrupts, we will often start
them at
100, so that the interrupt numbers look like “normal” x86 numbers, just
offset by
100. So, for example, the UART interrupts would be 104 and 103, instead of
4 and 3.
In this case, the intrinfo parameters describing the PIIX4 would be:100,16,25
Jacek
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
Hi Dave,
Now I’m looking at the Sandpoint BSP source.
Why the SANDPOINT_PIB_BASE is defined in two different ways:
- SANDPOINT_PIB_BASE 0xfe000000 (init_intrinfo.c),
- SANDPOINT_PIB_BASE 0x36000000 (callout_interrupt_sandpoint.s)
It appears that you’ve downloaded a 6.21 version of the BSP, where the
interrupts callouts used a different method of mapping physical to virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using the
6.3.0 sandpoint BSP.
What is an application of the SANDPOINT_PCI_INTACK 0x36ff0030 value?
What is hidding behind it?
Again, in the 6.3.0 BSP, that’s at a different address. Regardless,
it is a register that is read once to acknowledge an interrupt coming
from the 8259, and then read a second time to determine the actual
interrupt vector.
Is there any method for interrupt callouts code debugging?
Not via hardware debuggers, etc. You can put code in to display
single characters on screen, or to turn on LEDs, or perhaps to
halt the processor if a certain code path is executed, but in
general, debugging interrupt callouts is fairly painful.
Regards,
Jacek
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
These mappings are done in the init_intrinfo() routine of the startup
code.
The “Building Embedded Systems” documentation has further details.I have never configured such mappings before.
Here is our irqs mappings:
PPC405 Interrupt number | Usage
0-24 | PPC405 internal devices
25 | interrupt from PIIX4
(Master PIC)
26 | interrupt from DUART
27 | external IRQ2
28-31 | PCI INTA, INTB, INTC,
INTDthis part works fine.
We want to add external:
32-47 | ISA interruptsSo, I have a couple of questions:
- Do I need to write own set of callouts for external 32-47 isa intrs?
I mean &interrupt_id/eoi/mask/unmask_ext_isa routines.You shouldn’t need to write the interrupt callouts from scratch, since
there
have been other BSPs that use this style of interrupt setup.
For an example of a PPC BSP that implements an 8259 style interrupt
controller,
I’d suggest that you download the Sandpoint BSP.
2) Can anybody explain how to properly set cascade vector?The cascade vector is set in the init_intrinfo() routine. It is the third
parameter
in the intrinfo structure, for the interrupt controller you are
describing. For example,
if your PIIX4 interrupt controller output goes to PPC405 interrupt 25,
then the third
parameter of the intrinfo entry for your PIIX4 interrupt controller would
be 25. For the
top level interrupt controller (the one which connects to the CPU), the
cascade vector
is _NTO_INTR_SPARE. The first two parameters of the intrinfo entry
describe the start
vector, and the number of vectors on that controller, respectively. So,
for the PPC405
interrupt controller, the first three parameters would be:_NTO_INTR_CLASS_EXTERNAL,32,_NTO_INTR_SPARE
_NTO_INTR_CLASS_EXTERNAL is defined as 0 (in /usr/include/sys/neutrino.h)
for the PIIX4 controller, the first three parameters would be:
32,16,25
Note that it is not necessary for the interrupt numbers to run
contiguously between
two different controllers; with ISA style interrupts, we will often start
them at
100, so that the interrupt numbers look like “normal” x86 numbers, just
offset by
100. So, for example, the UART interrupts would be 104 and 103, instead of
4 and 3.
In this case, the intrinfo parameters describing the PIIX4 would be:100,16,25
Jacek
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
–
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
It appears that you’ve downloaded a 6.21 version of the BSP, where the
interrupts callouts used a different method of mapping physical to virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using the
6.3.0 sandpoint BSP.
Are these both definition of SANDPOINT_PIB_BASE exactly the same under
6.3.0?
Unfortunately I don’t have access to the 6.3.0 Sandpoint BSP.
Jacek
Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
It appears that you’ve downloaded a 6.21 version of the BSP, where the
interrupts callouts used a different method of mapping physical to virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using the
6.3.0 sandpoint BSP.Are these both definition of SANDPOINT_PIB_BASE exactly the same under
6.3.0?
Unfortunately I don’t have access to the 6.3.0 Sandpoint BSP.
SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in init_asinfo.c)
which allows the kernel callouts to gain access to the interrupt controller
registers.
In init_asinfo() of the 6.2.1 startup, you’ll see the following mapping:
as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts (0xfe000000),
maps to 0x36000000. This address can then be used directly in the interrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0 callouts for
examples.
\
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
Dave,
At the moment I’m working on the set of interrupt
callout routines and I have one problem.
Here is a part of my unmask callout:
CALLOUT_START interrupt_unmask_piix4_isa, 0, patcher
DEVBASE %r12, 0x12345678
…
la %r5,PIB_INTR1_OCW1(%r12) # put in r5 0xe8000021 address
lbz %r0,0(%r5) # load current intr mask
from OCW1 (IMR)
…
CALLOUT_END interrupt_unmas_piix4_isa
The "lbz %r0,0(%r5) " line crashes OS as follows:
devc-ser8250 -e -u5 -b115200 0xe8000200,105 &
28686 running devc-ser8250
Shutdown[0,0] S/C/F=11/1/11 C/D=00046fa0/0009a824 state(c0)= now lock
[0]PID-TID=28686-1? P/T FL=00001000/80000000 “bin/devc-ser8250”
ppcbe context[07ff1ee0]:
0000: 0000c9d8 07ff1f90 0009f468 0000c000 00000005 e8000021 00000020
00000000
0020: 00000080 0000c5f0 07be67d0 00000028 e8000000 000a151c 00000000
00000000
0040: 4804a978 48050000 48050000 00000000 48050000 4803fec4 00000005
4805d2f0
0060: 48041b1c 00000000 00000028 00000000 07be6370 07fef2b0 00000009
07fef2b0
0080: 000780a0 0006a558 00000030 0000ca00 84000004 00000000 0009a32c
0009a32c
00a0: 07ff1fa0
instruction[0000ca00]:
88 05 00 00 7c 00 06 ac 7c 00 30 78 98 05 00 00 7c 00 04 ac 38 60 00 00 4e
80
stack[07ff1f90]:
0000: 07ff1fa0 07fef2b0 07fef2b0 07be67d0 07ff1fd0 0006a180 00000000
0009a5f0
0020: 00029000 48050000 00000000 4805c1d4 00000028 07be6370 00000000
07be6448
0040: 07ff1ff0 000781dc 00000000 00098468 00000000 00000000 07be643c
07be6370
0060: 00000000 0009492c 00000000 00000000 07ff98a0 07ff9730 07ff95c0
07ff9450
As we see patcher puts the correct PIB address base 0xe8000000 to ‘r12’
register.
In ‘r5’ we have 0xe8000021 and in ‘r4’ interrupt nr 5 which is correct since
ISA interrupts
are mapped to the 100 - 115 range:
paddr_t intr_base = 0xE8000000;
{ _NTO_INTR_CLASS_EXTERNAL + 100, 16, 25,
PPC_EXC_EXTERNAL_INTR, 0, 0,
{0, 0, &interrupt_id_piix4_isa},
{INTR_GENFLAG_LOAD_INTRMASK, 0, &interrupt_eoi_piix4_isa},
&interrupt_mask_piix4_isa, &interrupt_unmask_piix4_isa, 0,
&intr_base,
},
Why does my unmask_callout routine crash?
Is it possible to read/write values inside callout
directly from/to the physical address (i.e. 0xe8000000 + offset)?
Did I miss something in init_intrinfo or init_asinfo function?
Jacek
U¿ytkownik “Dave Green” <dgreen@qnx.com> napisa³ w wiadomo¶ci
news:dfa35u$65r$1@inn.qnx.com…
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
It appears that you’ve downloaded a 6.21 version of the BSP, where the
interrupts callouts used a different method of mapping physical to
virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using
the
6.3.0 sandpoint BSP.Are these both definition of SANDPOINT_PIB_BASE exactly the same under
6.3.0?
Unfortunately I don’t have access to the 6.3.0 Sandpoint BSP.SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in init_asinfo.c)
which allows the kernel callouts to gain access to the interrupt
controller
registers.In init_asinfo() of the 6.2.1 startup, you’ll see the following mapping:
as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts (0xfe000000),
maps to 0x36000000. This address can then be used directly in the
interrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0 callouts
for
examples.
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in init_asinfo.c)
which allows the kernel callouts to gain access to the interrupt
controller
registers.In init_asinfo() of the 6.2.1 startup, you’ll see the following mapping:
as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts (0xfe000000),
maps to 0x36000000. This address can then be used directly in the
interrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0 callouts
for
examples.
How does the BAT mapping work?
Is it decribed somewhere?
I would like to know how it will work on our PPC405 target
(procnto-400) and PIB base address e8000000.
Jacek
–
David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
For 400 CPU callouts(6.3.0), you have to disable MMU and then
access the physical address directly. Remember to re-enable
the MMU after you’ve done your work.
Wensheng Zheng
Jacek Rudnicki wrote:
SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in init_asinfo.c)
which allows the kernel callouts to gain access to the interruptcontroller
registers.
In init_asinfo() of the 6.2.1 startup, you’ll see the following mapping:
as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts (0xfe000000),
maps to 0x36000000. This address can then be used directly in theinterrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0 calloutsfor
examples.
How does the BAT mapping work?
Is it decribed somewhere?I would like to know how it will work on our PPC405 target
(procnto-400) and PIB base address e8000000.Jacek
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
\
Jacek,
It turns out there is a problem with the callout_io_map routine
that is used by the patcher code, when used on PPC400 series
CPUs. The work-around is to turn off data translation in each
callout, and use the physical addresses directly. I’ve e-mailed
you some callout code for a PPC400 based system which also has
an 8259 interrupt controller, and which demonstrates how to
implement turning off data translation.
Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:
Dave,
At the moment I’m working on the set of interrupt
callout routines and I have one problem.Here is a part of my unmask callout:
CALLOUT_START interrupt_unmask_piix4_isa, 0, patcher
DEVBASE %r12, 0x12345678
…
la %r5,PIB_INTR1_OCW1(%r12) # put in r5 0xe8000021 address
lbz %r0,0(%r5) # load current intr mask
from OCW1 (IMR)
…
CALLOUT_END interrupt_unmas_piix4_isa
The "lbz %r0,0(%r5) " line crashes OS as follows:devc-ser8250 -e -u5 -b115200 0xe8000200,105 &
28686 running devc-ser8250
Shutdown[0,0] S/C/F=11/1/11 C/D=00046fa0/0009a824 state(c0)= now lock
[0]PID-TID=28686-1? P/T FL=00001000/80000000 “bin/devc-ser8250”
ppcbe context[07ff1ee0]:
0000: 0000c9d8 07ff1f90 0009f468 0000c000 00000005 e8000021 00000020
00000000
0020: 00000080 0000c5f0 07be67d0 00000028 e8000000 000a151c 00000000
00000000
0040: 4804a978 48050000 48050000 00000000 48050000 4803fec4 00000005
4805d2f0
0060: 48041b1c 00000000 00000028 00000000 07be6370 07fef2b0 00000009
07fef2b0
0080: 000780a0 0006a558 00000030 0000ca00 84000004 00000000 0009a32c
0009a32c
00a0: 07ff1fa0
instruction[0000ca00]:
88 05 00 00 7c 00 06 ac 7c 00 30 78 98 05 00 00 7c 00 04 ac 38 60 00 00 4e
80
stack[07ff1f90]:
0000: 07ff1fa0 07fef2b0 07fef2b0 07be67d0 07ff1fd0 0006a180 00000000
0009a5f0
0020: 00029000 48050000 00000000 4805c1d4 00000028 07be6370 00000000
07be6448
0040: 07ff1ff0 000781dc 00000000 00098468 00000000 00000000 07be643c
07be6370
0060: 00000000 0009492c 00000000 00000000 07ff98a0 07ff9730 07ff95c0
07ff9450As we see patcher puts the correct PIB address base 0xe8000000 to ‘r12’
register.
In ‘r5’ we have 0xe8000021 and in ‘r4’ interrupt nr 5 which is correct since
ISA interrupts
are mapped to the 100 - 115 range:paddr_t intr_base = 0xE8000000;
{ _NTO_INTR_CLASS_EXTERNAL + 100, 16, 25,
PPC_EXC_EXTERNAL_INTR, 0, 0,
{0, 0, &interrupt_id_piix4_isa},
{INTR_GENFLAG_LOAD_INTRMASK, 0, &interrupt_eoi_piix4_isa},
&interrupt_mask_piix4_isa, &interrupt_unmask_piix4_isa, 0,
&intr_base,
},Why does my unmask_callout routine crash?
Is it possible to read/write values inside callout
directly from/to the physical address (i.e. 0xe8000000 + offset)?Did I miss something in init_intrinfo or init_asinfo function?
Jacek
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
It appears that you’ve downloaded a 6.21 version of the BSP, where the
interrupts callouts used a different method of mapping physical to
virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using
the
6.3.0 sandpoint BSP.Are these both definition of SANDPOINT_PIB_BASE exactly the same under
6.3.0?
Unfortunately I don’t have access to the 6.3.0 Sandpoint BSP.SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in init_asinfo.c)
which allows the kernel callouts to gain access to the interrupt
controller
registers.In init_asinfo() of the 6.2.1 startup, you’ll see the following mapping:
as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts (0xfe000000),
maps to 0x36000000. This address can then be used directly in the
interrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0 callouts
for
examples.
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
–
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
Big thanks to both of you!!
Jacek
U¿ytkownik “Dave Green” <dgreen@qnx.com> napisa³ w wiadomo¶ci
news:dfphog$hvf$1@inn.qnx.com…
Jacek,
It turns out there is a problem with the callout_io_map routine
that is used by the patcher code, when used on PPC400 series
CPUs. The work-around is to turn off data translation in each
callout, and use the physical addresses directly. I’ve e-mailed
you some callout code for a PPC400 based system which also has
an 8259 interrupt controller, and which demonstrates how to
implement turning off data translation.
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
Dave,At the moment I’m working on the set of interrupt
callout routines and I have one problem.Here is a part of my unmask callout:
CALLOUT_START interrupt_unmask_piix4_isa, 0, patcher
DEVBASE %r12, 0x12345678
…
la %r5,PIB_INTR1_OCW1(%r12) # put in r5 0xe8000021 address
lbz %r0,0(%r5) # load current intr
mask
from OCW1 (IMR)
…
CALLOUT_END interrupt_unmas_piix4_isa
The "lbz %r0,0(%r5) " line crashes OS as follows:devc-ser8250 -e -u5 -b115200 0xe8000200,105 &
28686 running devc-ser8250
Shutdown[0,0] S/C/F=11/1/11 C/D=00046fa0/0009a824 state(c0)= now lock
[0]PID-TID=28686-1? P/T FL=00001000/80000000 “bin/devc-ser8250”
ppcbe context[07ff1ee0]:
0000: 0000c9d8 07ff1f90 0009f468 0000c000 00000005 e8000021 00000020
00000000
0020: 00000080 0000c5f0 07be67d0 00000028 e8000000 000a151c 00000000
00000000
0040: 4804a978 48050000 48050000 00000000 48050000 4803fec4 00000005
4805d2f0
0060: 48041b1c 00000000 00000028 00000000 07be6370 07fef2b0 00000009
07fef2b0
0080: 000780a0 0006a558 00000030 0000ca00 84000004 00000000 0009a32c
0009a32c
00a0: 07ff1fa0
instruction[0000ca00]:
88 05 00 00 7c 00 06 ac 7c 00 30 78 98 05 00 00 7c 00 04 ac 38 60 00 00
4e
80
stack[07ff1f90]:
0000: 07ff1fa0 07fef2b0 07fef2b0 07be67d0 07ff1fd0 0006a180 00000000
0009a5f0
0020: 00029000 48050000 00000000 4805c1d4 00000028 07be6370 00000000
07be6448
0040: 07ff1ff0 000781dc 00000000 00098468 00000000 00000000 07be643c
07be6370
0060: 00000000 0009492c 00000000 00000000 07ff98a0 07ff9730 07ff95c0
07ff9450As we see patcher puts the correct PIB address base 0xe8000000 to ‘r12’
register.
In ‘r5’ we have 0xe8000021 and in ‘r4’ interrupt nr 5 which is correct
since
ISA interrupts
are mapped to the 100 - 115 range:paddr_t intr_base = 0xE8000000;
{ _NTO_INTR_CLASS_EXTERNAL + 100, 16, 25,
PPC_EXC_EXTERNAL_INTR, 0, 0,
{0, 0, &interrupt_id_piix4_isa},
{INTR_GENFLAG_LOAD_INTRMASK, 0, &interrupt_eoi_piix4_isa},
&interrupt_mask_piix4_isa, &interrupt_unmask_piix4_isa, 0,
&intr_base,
},Why does my unmask_callout routine crash?
Is it possible to read/write values inside callout
directly from/to the physical address (i.e. 0xe8000000 + offset)?Did I miss something in init_intrinfo or init_asinfo function?
Jacek
Jacek Rudnicki <> jacek.rudnicki@quantum.com.pl> > wrote:
It appears that you’ve downloaded a 6.21 version of the BSP, where
the
interrupts callouts used a different method of mapping physical to
virtual
addresses. If you’re working on a BSP for 6.3.0, you should be using
the
6.3.0 sandpoint BSP.Are these both definition of SANDPOINT_PIB_BASE exactly the same
under
6.3.0?
Unfortunately I don’t have access to the 6.3.0 Sandpoint BSP.SANDPOINT_PIB_BASE is only defined once in the 6.3.0 BSP, to the
physical address of the PIB base. The other definition that you
see in the 6.21 BSP is a result of a BAT mapping (set up in
init_asinfo.c)
which allows the kernel callouts to gain access to the interrupt
controller
registers.In init_asinfo() of the 6.2.1 startup, you’ll see the following
mapping:as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, “kernel_device”, mem);
So, physical addresses in the range of 0xf8000000 - 0xffffffff are
mapped to virtual addresses 0x30000000 - 0x37ffffff.
As a result, the physical base address of the PIB interrupts
(0xfe000000),
maps to 0x36000000. This address can then be used directly in the
interrupt
callouts. But, as I said earlier, this has all changed under 6.3.0, so
if
you’re developing a 6.3.0 BSP, it’s best to look at other 6.3.0
callouts
for
examples.
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
\David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com