Re: [Openocd-development] Cache L1, L2 on armv7a.
Merged. Thanks! -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cache L1, L2 on armv7a.
On 09/29/2011 09:40 AM, Michel JAOUEN wrote: Hello, I implemented the flush of L1 and L2 cache for cortex_a. I added the support of phys memory access through dap apsel 1, (for this access, a flush is performed, and mmu is disabled) I also implement va_to_pa mechanism for virt_to_phys. For that purpose, I have modified the architecture : Instead of increasing cortex_a.c file, I moved this new support feature to armv7a.c . The reason of this change is to prepare later cortex_a evolution.(A15, A7), that could be implemented in Another file than cortex_a.c relying on a set of function from amv7a file. Best Regards. Michel JAOUEN ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Michel, I am trying to understand what the "cache_config" command does so that I can add this functionality to the Pandaboard. I apologize for the list of questions, but the operation is not clear and I didn't see any documentation for this feature: * Is the address supposed to point to the base PL310 address? * Why do you call this operation if the target status is unknown? * What does this operation do when called? I appreciate any insight you can provide. Thanks, Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cache L1, L2 on armv7a.
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 1^st 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
Re: [Openocd-development] Cache L1, L2 on armv7a.
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
