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. > > > >> > >> > >>> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
