Location of exception vectors in PPC BSPs
FrankG
Specifically I am trying to understand the wrSbc8260 BSP, but the
question applies to all PPC BSPs.
I think I understand the PPC exception vector scheme. The base is set
according to 0xFFF00000 or 0x00000000. This depends on the IP bit in
the MSR which originates at reset in the CIP bit in the HRCW. Whatever
the base is you then
have the following offsets: Quoting from 6-4 of MPCFPE32B.pdf.
System Reset 0x0100
Machine Check 0x0200
DSI 0x0300
ISI 0x0400
External Interrupt 0x0500
Alignment 0x0600
Program 0x0700
FP unavailable 0x0900
...
Reserved 0x1000 - 0x2FFF
There are several things I am confused about. It seems as though the
romImage starts at address 0xFFF00100. I guess this causes the
assembler routine romInit in romInit.s to execute on reset by virtue
of the fact that it is linked first.
It seems like there is no allowance for any other exception except the
External Interrupt which is then connected from m8260IntrInit() via
this API call.
excIntConnect ((VOIDFUNCPTR *) _EXC_OFF_INTR, m8260IntrDeMux);
I geuss this just overwrites whatever happens to be at address
0xFFF00500.
Which is a predefined physical address location in the MMU? I geuss
the writing of the TLBs in romInit.s set this up to whatever physical
memory location.
Clearly I have more questions than answers I am slowly integrating all
this PPC/BSP knowledge. However I was hoping someone who had already
figured this stuff out could give me a hint, or at least point me to
some good documentation.
Dan Gold
>How does vxWorks locate the PPC exception vectors?
It doesn't. They are set by the Green Book, which you've quoted below.
They are either at 0x100 or 0xfff00100, as you correctly noted by MSR[IP].
>I think I understand the PPC exception vector scheme. The base is set
>according to 0xFFF00000 or 0x00000000. This depends on the IP bit in
>the MSR which originates at reset in the CIP bit in the HRCW. Whatever
>the base is you then
>have the following offsets: Quoting from 6-4 of MPCFPE32B.pdf.
>System Reset 0x0100
>Machine Check 0x0200
>DSI 0x0300
>ISI 0x0400
>External Interrupt 0x0500
>Alignment 0x0600
>Program 0x0700
>FP unavailable 0x0900
>...
>Reserved 0x1000 - 0x2FFF
Correct. The reserved area actually contains vectors, some are only present
on a 750, some only on a 74xx, etc... You need to see your processor
specific HW manual. For the 8260, the 603e manual does just fine.
>There are several things I am confused about. It seems as though the
>romImage starts at address 0xFFF00100. I guess this causes the
>assembler routine romInit in romInit.s to execute on reset by virtue
>of the fact that it is linked first.
Correct, and vxWorks links it at 0xfff00100.
>It seems like there is no allowance for any other exception except the
>External Interrupt which is then connected from m8260IntrInit() via
>this API call.
>
> excIntConnect ((VOIDFUNCPTR *) _EXC_OFF_INTR, m8260IntrDeMux);
>
>I geuss this just overwrites whatever happens to be at address
>0xFFF00500.
There are other exceptions that are generated to the PPC, such as SMI and
NMI. And in the case of the 8260 IRQ0-7. And also for the 8260 (and 860)
you can have general purpose input lines generating interrupts. You are
correct that there is no allowance for multiple general purpose interrupts
to be hardwired to the external interrupt pin. Usually all external
interrupts come through some sort of interrupt controller.
The 8260 and 860 are special cases of the external interrupts. Look in
tornado/target/src/intrCtl/xxx8260.c, I can't remember the exact name of the
file. Basically vxWorks does the excIntConnect, because it needs a few
things are the beginning of the exception handler (prologue and epilogue for
the ISR at 0x500). So when you call intConnect(), vxWorks maintains a table
of exception vectors. When the 8260 generates an interrupt, the code looks
at the SIVEC register to get the particular vector, uses that as an index
into it's table, and jumps to the function you've registered with
intConnect(). That way you don't have to worry about the code at 0x500.
>Which is a predefined physical address location in the MMU? I geuss
>the writing of the TLBs in romInit.s set this up to whatever physical
>memory location.
Huh ? In romInit.s I think it only invalidates the TLBs.
>Clearly I have more questions than answers I am slowly integrating all
>this PPC/BSP knowledge. However I was hoping someone who had already
>figured this stuff out could give me a hint, or at least point me to
>some good documentation.
The BSP code is the best documentation for some of this stuff. Of course
the HW manuals too, and you can always call your WRS FAE and ask for source
if you don't find what you're looking for.
hth,
Dan Gold go...@ensemble.com
Varndell Engineering
>
> How does vxWorks locate the PPC exception vectors?
> Specifically I am trying to understand the wrSbc8260 BSP, but the
> question applies to all PPC BSPs.
>
> I think I understand the PPC exception vector scheme. The base is set
> according to 0xFFF00000 or 0x00000000. This depends on the IP bit in
> the MSR which originates at reset in the CIP bit in the HRCW. Whatever
> the base is you then
> have the following offsets: Quoting from 6-4 of MPCFPE32B.pdf.
> System Reset 0x0100
> Machine Check 0x0200
> DSI 0x0300
> ISI 0x0400
> External Interrupt 0x0500
> Alignment 0x0600
> Program 0x0700
> FP unavailable 0x0900
> ...
> Reserved 0x1000 - 0x2FFF
>
> There are several things I am confused about. It seems as though the
> romImage starts at address 0xFFF00100. I guess this causes the
> assembler routine romInit in romInit.s to execute on reset by virtue
> of the fact that it is linked first.
Sort of, but not all PPC systems boot from that address.
> It seems like there is no allowance for any other exception except the
> External Interrupt which is then connected from m8260IntrInit() via
> this API call.
>
> excIntConnect ((VOIDFUNCPTR *) _EXC_OFF_INTR, m8260IntrDeMux);
>
> I geuss this just overwrites whatever happens to be at address
> 0xFFF00500.
By the time vx calls excIntConnect, the vectors are in RAM.
> Which is a predefined physical address location in the MMU? I geuss
> the writing of the TLBs in romInit.s set this up to whatever physical
> memory location.
No, rominit.s just invalidates the TLBs. They are initialized later.
>
> Clearly I have more questions than answers I am slowly integrating all
> this PPC/BSP knowledge. However I was hoping someone who had already
> figured this stuff out could give me a hint, or at least point me to
> some good documentation.
The following link is for vx 5.5, but answers questions like these.
http://web2.windriver.com/windsurf/techpubs/ide/tornado/t22/pdf/vxworks/Guide1.pdf
--
Varndell Engineering, LLC Embedded Systems Expertise
Need an END driver DP8382x GigE devices? Contact us.
http://www.varndellengineering.com
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Varndell Engineering
>
> How does vxWorks locate the PPC exception vectors?
> Specifically I am trying to understand the wrSbc8260 BSP, but the
> question applies to all PPC BSPs.
>
> I think I understand the PPC exception vector scheme. The base is set
> according to 0xFFF00000 or 0x00000000. This depends on the IP bit in
> the MSR which originates at reset in the CIP bit in the HRCW. Whatever
> the base is you then
> have the following offsets: Quoting from 6-4 of MPCFPE32B.pdf.
> System Reset 0x0100
> Machine Check 0x0200
> DSI 0x0300
> ISI 0x0400
> External Interrupt 0x0500
> Alignment 0x0600
> Program 0x0700
> FP unavailable 0x0900
> ...
> Reserved 0x1000 - 0x2FFF
>
> There are several things I am confused about. It seems as though the
> romImage starts at address 0xFFF00100. I guess this causes the
> assembler routine romInit in romInit.s to execute on reset by virtue
> of the fact that it is linked first.
Sort of, but not all PPC systems boot from that address.
> It seems like there is no allowance for any other exception except the
> External Interrupt which is then connected from m8260IntrInit() via
> this API call.
>
> excIntConnect ((VOIDFUNCPTR *) _EXC_OFF_INTR, m8260IntrDeMux);
>
> I geuss this just overwrites whatever happens to be at address
> 0xFFF00500.
By the time vx calls excIntConnect, the vectors are in RAM.
> Which is a predefined physical address location in the MMU? I geuss
> the writing of the TLBs in romInit.s set this up to whatever physical
> memory location.
No, rominit.s just invalidates the TLBs. They are initialized later.
>
> Clearly I have more questions than answers I am slowly integrating all
> this PPC/BSP knowledge. However I was hoping someone who had already
> figured this stuff out could give me a hint, or at least point me to
> some good documentation.
The following link is for vx 5.5, but answers questions like these.
Richard Nardone
> How does vxWorks locate the PPC exception vectors?
> Specifically I am trying to understand the wrSbc8260 BSP, but the
> question applies to all PPC BSPs.
>
> I think I understand the PPC exception vector scheme. The base is set
> according to 0xFFF00000 or 0x00000000. This depends on the IP bit in
> the MSR which originates at reset in the CIP bit in the HRCW. Whatever
> the base is you then
> have the following offsets: Quoting from 6-4 of MPCFPE32B.pdf.
> System Reset 0x0100
> Machine Check 0x0200
> DSI 0x0300
> ISI 0x0400
> External Interrupt 0x0500
> Alignment 0x0600
> Program 0x0700
> FP unavailable 0x0900
> ...
> Reserved 0x1000 - 0x2FFF
This is true, except the Decrementer exception is connected at
offset 0x0900.
>
> There are several things I am confused about. It seems as though the
> romImage starts at address 0xFFF00100. I guess this causes the
> assembler routine romInit in romInit.s to execute on reset by virtue
> of the fact that it is linked first.
After the HRCW is read, the first instruction fetch is from the
system reset exception vector located at offset 0x0100 from the
exception base.
> It seems like there is no allowance for any other exception except the
> External Interrupt which is then connected from m8260IntrInit() via
> this API call.
>
> excIntConnect ((VOIDFUNCPTR *) _EXC_OFF_INTR, m8260IntrDeMux);
>
> I geuss this just overwrites whatever happens to be at address
> 0xFFF00500.
The PPC architecture has one main external interrupt. The ISR
placed at this location has lots of work to do to figure out which
interrupt(s) is present and then dispatch the appropriate processing
(another ISR).
The Decrementer exception is also used as the system cadence for many
BSPS.
This determines when the kernel is activated, the VxWork Tick, which
is usually set to 60Hz or 100Hz.
> Which is a predefined physical address location in the MMU? I geuss
> the writing of the TLBs in romInit.s set this up to whatever physical
> memory location.
The BSP I worked with on the 8260 did a one to one mapping using the
four IBATS and four DBATS. Look at the PowerPC Programming
Environments for 32-Bit Microprocessors manual, chapter 7 MMU.
kiran Mandava
I am trying to port vxworks onto one of our board. this board has
dual processors 750Cxe, CPC710 is the bridging device. they are using
the same SDRAM
i have problems while registering the interrupt handlers. First CPU is
using the first half of the SDRAM and the second CPU the other half.
Since i can't relocate the Interrupt Vector base how can i handle
the interrupts on both the CPUs. if any of the processor gets the
external interrupt it will jump to 0x500 and vxworks tries to save the
interrupt context to the interrupt stack location and then call the
ISR. In the ISR i could jump to a different location depending on the
CPU on which the interrupt occured, but the interrupt context is
always stored on the first CPU SDRAM and how to handle the case if the
first CPU gets the interrupt at the same time as when the second one
is in the middle of the ISR.
thanks
kiran
ri...@cyclone.com (Richard Nardone) wrote in message news:<29b153d9.02091...@posting.google.com>...