Cache-inhibited region for certain exception handler(e500 chips, 2.4 kernel)?

Is there a way to put certain exception handler(e.g. machine check) on e500
to a cache-inhibited region? 
 
1. The e500 kernel puts exception handlers at the starting of the physical
memory.
2. All the physical memory are covered by a few TLB1s to do
0xc0000000-0x00000000 translation.
3. We can not add a new TLB1 to map a small piece of memory, because it has
boundary limitation(4K...256M). We can not use two TLB1 to overlap since it
will cause program error.
4. When we tried to move a handler(e.g. machine check) to a different
location, the kernel won't boot.
5. We don't want to map all the exceptional handlers to be cache inhibited,
say, the first 1MB, the performance will be horrible if we do so.
 
Is there a way at all to tweak things like this, i.e., put an exception
handler into a piece of memory that is cache-inhibited?
 
I also thought about use mlock/mmap on /dev/mem, move the specific exception
handler to a high address then use a separate TLB1 to cover it(need change
link script?),etc. 
 
Any suggestion is greatly appreciated.
 
xianghua
 

On Wed, 15 Feb 2006, Xianghua Xiao wrote:

Is there a way to put certain exception handler(e.g. machine check) on e500
to a cache-inhibited region? 
 
1. The e500 kernel puts exception handlers at the starting of the physical
memory.
2. All the physical memory are covered by a few TLB1s to do
0xc0000000-0x00000000 translation.
3. We can not add a new TLB1 to map a small piece of memory, because it has
boundary limitation(4K...256M). We can not use two TLB1 to overlap since it
will cause program error.
4. When we tried to move a handler(e.g. machine check) to a different
location, the kernel won't boot.
5. We don't want to map all the exceptional handlers to be cache inhibited,
say, the first 1MB, the performance will be horrible if we do so.
 
Is there a way at all to tweak things like this, i.e., put an exception
handler into a piece of memory that is cache-inhibited?
 
I also thought about use mlock/mmap on /dev/mem, move the specific exception
handler to a high address then use a separate TLB1 to cover it(need change
link script?),etc. 
 

Why exactly do you the mcheck handler to be cache inhibited?  One simple 
way would be to setup a temp mapping in kernel virtual address space 
somewhere and have the first thing the current handler does is jump to 
that location.

- kumar

Hi Kumar,

I saw your email earlier, so figured you were listening in
on the PPC group at the moment.

In the recent 2.6 kernel source, you authored the file:

arch/ppc/platforms/83xx/mpc834x_sys.h and .c

are these files for the MPC8349E-MDS board?

In the Denx source, there is modified versions for the
TQM board, but I wasn't sure what platform the original
files were targeted for.

Thanks,
Dave Hawkins,
Caltech.

On Wed, 15 Feb 2006, David Hawkins wrote:

Hi Kumar,

I saw your email earlier, so figured you were listening in
on the PPC group at the moment.

In the recent 2.6 kernel source, you authored the file:

arch/ppc/platforms/83xx/mpc834x_sys.h and .c

are these files for the MPC8349E-MDS board?

Yes, Freescale names the board four different things durings its 
development (ADS, SYS, MDS, ok maybe only three :)

In the Denx source, there is modified versions for the
TQM board, but I wasn't sure what platform the original
files were targeted for.

Not sure, I follow.  The MPC834x MDS was the first 834x system supported.

However, if you are looking at 834x, I recommend you grab my u-boot tree 
from kernel.org since it has support for booting the kernel with a flat 
device tree.  From 2.6.16, all future 83xx work will be done in 
arch/powerpc which requires a flat dev tree to boot.

- kumar

quoted

... for the MPC8349E-MDS board?

Yes, Freescale names the board four different things durings its 
development (ADS, SYS, MDS, ok maybe only three :)

Ok, great.

quoted

In the Denx source, there is modified versions for the
TQM board, but I wasn't sure what platform the original
files were targeted for. 

Not sure, I follow.  The MPC834x MDS was the first 834x system supported.

Sorry, my fault, I wasn't clear.

I was just referring to the fact that in addition to your
source, the Denx tree also has the work they are doing on
the TQM board that contains an 8349E.

However, if you are looking at 834x, I recommend you grab my u-boot tree 
from kernel.org since it has support for booting the kernel with a flat 
device tree.  From 2.6.16, all future 83xx work will be done in 
arch/powerpc which requires a flat dev tree to boot.

Ok.

The reason I was asking, was that I want to benchmark an 8349E
based system. Wolfgang Denx mentioned the TQM system, so I took
a look in the Denx tree, and saw that their work was based
on yours. I assumed your work was for a Freescale reference board,
but didn't know which.

Thanks for the clarification.

Dave