[U-Boot-Users] Problem porting the POST instruction cache test to the MPC5200.

[U-Boot-Users] Problem porting the POST instruction cache test to the MPC5200.

[Txema Lopez]

Hi all,

I'm trying to port the POST cache test to the MPC5200 and I've found 
some problems porting the cache_post_test5 function. I think the 
philosophy of the function (I think the comments are not updated) is  to 
lock an instruction in the  cache, modify the instruction position in 
memory with another instruction and verify that the instruction locked 
in the cache has been executed when we jump to the instruction . The 
locked instruction load the r3 register with a 0 value and the "new" 
instruction with a -1. When I debug the function with the gdb and the 
BDI2000 with the ddd front end I see in the Machine Code Window the 
intruction locked ( li r3, 0) but if I stepi the instruction the value 
in r3 will be -1. I can't understand what is happening. Who is telling 
the truth?.  I think the problem seems to be  with the lock proccess 
and  I have a doubt: Must I activate the intruction MMU to lock the 
cache in a MPC5200? I have read the MPC5200 core manual and this aspect 
is not clear to me. How can I see the instruction cache with the gdb (or 
BDI2000) without write a specific function ?.

Any clue will be welcomed.

Attached my test cache file for the MPC5200  based on  the cache_8xx.S file.

Thanks in advance.

Jose Maria Lopez.
 


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cache_5xxx.S
Url: http://lists.denx.de/pipermail/u-boot/attachments/20051114/6952858f/attachment.txt 

[U-Boot-Users] Problem porting the POST instruction cache test to the MPC5200.

[Stefan Mätje]

Hi Mr. Lopez,

I've already implemented a POST cache test for the MPC5200. This was  
done while porting U-Boot to one of our new boards pf5200_st.  
Unfortunately I forked from the U-Boot tree several month ago. To catch  
up to the current U-Boot tree I will need about one or two weeks. Then  
I will be able to post a patch against the current version.

If you want you may get my source files in advance. Please contact me  
directly.

To answer some of your questions from my experience:

Am 14.11.2005 17:07:23 schrieb(en) Txema Lopez:
> Hi all,
> 
> I'm trying to port the POST cache test to the MPC5200 and I've found  
> some problems porting the cache_post_test5 function. I think the  
> philosophy of the function (I think the comments are not updated) is   
> to lock an instruction in the  cache, modify the instruction position  
> in memory with another instruction and verify that the instruction  
> locked in the cache has been executed when we jump to the instruction .

This was also my idea about this function.

> The locked instruction load the r3 register with a 0 value and the  
> "new" instruction with a -1. When I debug the function with the gdb  
> and the BDI2000 with the ddd front end I see in the Machine Code  
> Window the intruction locked ( li r3, 0) but if I stepi the  
> instruction the value in r3 will be -1. I can't understand what is  
> happening. Who is telling the truth?.

I don't really know, but I think a least from PPC instruction level  
there is no way to read the contents of the instruction cache on the G2  
core (nearly a 603e).

> I think the problem seems to
> be  with the lock proccess and  I have a doubt: Must I activate the  
> intruction MMU to lock the cache in a MPC5200? I have read the
> MPC5200 core manual and this aspect is not clear to me.

For locking only you don't need the MMU. But some parts of the POST  
cache test (especially the data write through stuff) are only working  
with MMU enabled.

> How can I see
> the instruction cache with the gdb (or BDI2000) without write a  
> specific function ?.

I really don't know.

I believe the problem is not the locking of the instruction cache. The  
difficult thing is to get the right instructions into the cache before  
the locking is done.

The solution that works for me was to call the test instruction once  
then lock the cache and after that replace the instruction in memory.  
The second call then has to deliver the value set up by the locked  
instruction.

The reason for this is the completely different cache handling on 8xx  
cores and on the G2/603e core. The 603e core misses any instruction to  
load and lock explicitely a cache line.

Also the code to load and lock instructions in the cache which is  
depicted in the G2 Core Reference manual will not work because one of  
its preconditions is that the loading code is executed from an area  
from which the core can read two instructions in one beat (64 bit data  
path). There is no memory area on the MPC5200 that would fulfill this  
precondition. Maybe except the SRAM, but I didn't test that after  
having a working solution.

> Thanks in advance.
> 
> Jose Maria Lopez.