Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel

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 option is to, change the current mapping to 'Write Through' before
calling the relocate() and revert back to the original setting after relocate().

Why not just keep the dcbst's & icbi's in relocate for now ? (original
patch) Is it noticably slower to boot ? If not I'd say keep it that way,
it will work on all implementations.

Cheers,
Ben.

quoted

quoted

quoted

For i-cache invalidation there's already the (incorrectly named?)
flush_instruction_cache().  It uses the appropriate platform-specific
methods (e.g. iccci for 44x) to invalidate the entire i-cache.

Agreed. The only thing that worries me is the use of KERNELBASE in the
flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
implementations ignore the arguments passed to iccci ?

Good question.  I don't know the answer. :-)

That also may suggest a bigger can of worms.  A grep of the powerpc code
shows many uses of KERNELBASE.  For a relocatable kernel, nobody should
be relying on KERNELBASE except for the early relocation code.  Are we
sure that all the other usages of KERNELBASE are "safe"?

I think we could simply replace the occurrences of KERNELBASE (after the relocate())
  with '_stext' which would give the virtual start address of the kernel.

Thanks
Suzuki

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev