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
R_PPC_ADDR16_
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 th
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,
Thanks
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 */
> >
> 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
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 r0,
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 invalidat
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf 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 CONFIG_RELOCATABLE
> >
On 11/09/11 12:03, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf 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 CONFI
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf 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
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 Poimboeuf 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 i
> >> 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 ca
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?
> >
> >
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
14 matches
Mail list logo
