Hello, I didn't implemented the flush for this access. I keep it working as it was previously in order to reduce disturbance. But on the u8500 example, it is an interesting approach, through this access on dap 0, peripheral register can be Read without spending time flushing full cache.
Best Regards From: Karl Kurbjun [mailto:kkurb...@gmail.com] Sent: Thursday, October 06, 2011 5:30 AM To: Michel JAOUEN Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Cache L1, L2 on armv7a. On 10/05/2011 05:32 AM, Michel JAOUEN wrote: Hello, Below , you find the answer to your question : * Is the address supposed to point to the base PL310 address? Yes , you have to provide the physical address of PL310. * Why do you call this operation if the target status is unknown? After target creation and smp initialization, this operation need to be done only once. By doing it with target in unknow state, It is not performed several time, if operation is done several time, only 1st call is taken into account. * What does this operation do when called? This operation is initializing the l2 cache handler with external cache PL310. (without this initialization cache l2 is not supported) The number of way is provided as parameter, auto detection is not implemented yet. The effect of this call is seen later on : -1- while reading phys memory through dap apsel 1: a flush of the cache L1 from the cortex A9s and then a flush of unified cache L2 will be done. This will allow to read a consistent physical memory. -2- cortex_a8 cache_info : shows the cache L1 and L2 info Best Regards Michel JAOUEN Michel, Thanks for the explanation, that helped a bunch. With this work then using apsel 1 will guarantee consistent memory. If I write through apsel 0 will the L2 and L1 cache lines also be invalidated? Thanks again, Karl
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
