How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
Wouldn't that result in more cache flushing than the original
solution?
For example, my kernel is 3.5MB. Assuming a 32 byte cache line
size,
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:
How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
Wouldn't that result in more cache flushing than the original solution?
For example, my
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:
Oops ! You are right. We could go back to the clean_dcache_all() or the
initial approach that you suggested. (dcbst).
I am not sure how do we flush the entire dcache(only). Could you post a
patch which does the same ?
Another
On 11/09/11 12:03, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeufjpoim...@linux.vnet.ibm.com wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do it like:
for e.g, on 440x, (in
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf jpoim...@linux.vnet.ibm.com wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do it like:
On 11/09/11 20:23, Josh Poimboeuf wrote:
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeufjpoim...@linux.vnet.ibm.com wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in relocate(), lets
do it
like:
for e.g, on 440x, (in head_44x.S :)
#ifdef CONFIG_RELOCATABLE
...
bl relocate
#Flush the d-cache and invalidate the
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf jpoim...@linux.vnet.ibm.com wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do it like:
for e.g, on 440x, (in head_44x.S :)
#ifdef
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add r0, r0, r3 /* final addend */
stwx
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add r0, r0, r3 /* final
On 11/07/11 20:43, Josh Poimboeuf wrote:
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Hi Suzuki,
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Hi Suzuki,
Thanks for the patches. I've been testing them
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Currently the following relocation types are handled :
R_PPC_RELATIVE
R_PPC_ADDR16_LO
14 matches
Mail list logo
