PowerPC exceptions: various comments

[Till Straumann]

Hi Thomas.

I really appreciate your comments - special thanks for clarifying issue 
#1 with
FreeScale!

Thomas Doerfler wrote:
> 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.
correct
> For this purpose, you write the content of r1 to the "lock_bits" flag 
> as the first opcode in the non-critical interrupt prolog.
yes
>
> 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.
bad news.
> 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.
yes, I agree.
>
> 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?
no hard reqs. but it might be confusing to the user and limit 
functionality of
critical interrupts.

There is one more kludge: the critical code could check CSSR0 and catch
the case where it would return to prologue code.
>
> 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?
yes.
>
> 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.
I'm sorry - not sure I completely understand your idea. Could you please 
elaborate a bit more?

The main goal is not having to copy prologue snippets since that 
wouldn't work in ROM, right?

So you would propose writing/generating a CPU-specific, static 
prologue-snippet table
that would be linked with the application?

Thanks
-- Till

>
> 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.
>
>
>
>