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.