PowerPC exceptions: various comments

[Thomas Doerfler]

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.




-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.