[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PowerPC exceptions: various comments
- Date: Tue, 11 Mar 2008 17:48:37 +0100
- From: Thomas.Doerfler at embedded-brains.de (Thomas Doerfler)
- Subject: PowerPC exceptions: various comments
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
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
- 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
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
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
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.