PowerPC exceptions: various comments

[Kate Feng]

Thomas Doerfler wrote:

> Before we got further into the details of these plans, I would like to 
> get your opinion on the whole direction. Be assured, that we would NOT 
> add conditional assembly and we would NOT copy/paste/modify relevant 
> code :-)

It is #1 and intelligent to have a unified standard throughout the RTEMS 
code.

Kate

>Hello Till,
>
>we are currently adapting RTEMS to a MPC55xx microcontroller with a 
>e200z6 CPU core. We are pleased to see, that you have significantly 
>cleaned up the PPC exception code and you also already have done lots of 
>stuff to support the e500 core, which is very similar to the e200.
>
>All in all I agree, that your modifications simplify the use of the PPC 
>vectoring scheme.
>
>But we have some topics that should be discussed.
>
>1. Critical Interrupts
>=======================
>My colleague Sebastian has tripped over the synchronization you try to 
>achieve between non-critical and critical interrupts. As far as I 
>understand, you try to detect the situation, that a critical interrupt 
>interrupts the prolog code of a non-critical interrupt. For this 
>purpose, you write the content of r1 to the "lock_bits" flag as the 
>first opcode in the non-critical interrupt prolog.
>
>Unfortunately this will not work reliable. I have discussed the issue 
>with one of my Freescale contact persons, and he told me that entering 
>the non-critical interrupt and executing the first opcode is NOT atomic. 
>So there is still a chance, that
>
>- the CPU has saved PC/MSR into SRR0/1
>
>- the CPU has modified PC/MSR to execute the non-critical interrupt prolog
>
>- A critical interrupt is raised
>
>- the CPU saves PC/MSR into CSRR0/1 and enters the critical interrupt 
>handler
>
>- the critical interrupt handler may issue a thread dispatch when 
>leaving, and therefore delay the previously raised non-critical interrupt.
>
>As far as I can see, we should postulate, that critical interrupts are 
>NOT allowed to dispatch tasks. Do you see hard requirements that stand 
>against this?
>
>2. Interrupt Prolog Placement in ROM
>====================================
>
>Our target will have 128KByte(!) of internal RAM. In some applications, 
>this will be the only RAM available, and therefore I am looking for ways 
>to place the exception prologue code in ROM/Flash (that's where the rest 
>of the code is located anyway).
>
>What I have seen in the current code gives me the impression that the 
>prologue code is more or less statically initialized. When the current 
>CPU type has been detected, the corresponding prologue snippets are 
>copied to the proper vector locations and it is not intended that the 
>prologue code is replaced when e.g. a debugger agent is attached. 
>Instead, the agent would connect to the high level handler. Did I get 
>this right?
>
>So my idea would be to alternatively make the macro assembler duplicate 
>the prologues in proper flavour, quite similar to the 
>"xxx_vector_categories" tables in raw_exception.c. Many other changes 
>would be required then (e.g. the relationship between the prologue 
>address and the vector number will become different again), but it is at 
>least worth the effort for the MPC55xx, and maybe it would even make 
>sense for the "big" PPCs, because copying the code to the vector range 
>is not really necessary in all situations.
>
>Before we got further into the details of these plans, I would like to 
>get your opinion on the whole direction. Be assured, that we would NOT 
>add conditional assembly and we would NOT copy/paste/modify relevant 
>code :-)
>
>wkr,
>Thomas.
>
>
>
>
>  
>