From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp09.in.ibm.com (e28smtp09.in.ibm.com [122.248.162.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e28smtp09.in.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 3346CB6F71 for ; Wed, 9 Nov 2011 17:33:25 +1100 (EST) Received: from /spool/local by e28smtp09.in.ibm.com with XMail ESMTP for from ; Wed, 9 Nov 2011 12:03:14 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pA96X7Il2543818 for ; Wed, 9 Nov 2011 12:03:08 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pA96X6bY008978 for ; Wed, 9 Nov 2011 17:33:07 +1100 Date: Wed, 9 Nov 2011 12:03:03 +0530 From: Suzuki Poulose To: Josh Poimboeuf Subject: Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel Message-ID: <20111109120303.51ac3b1b@suzukikp.in.ibm.com> In-Reply-To: <1320769145.5273.26.camel@treble> References: <20111025114829.8183.1725.stgit@suzukikp.in.ibm.com> <20111025115354.8183.48237.stgit@suzukikp.in.ibm.com> <1320276969.3309.3.camel@treble> <4EB3A40C.1070802@in.ibm.com> <1320678819.2750.15.camel@treble> <4EB8D628.2090304@in.ibm.com> <1320769145.5273.26.camel@treble> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Nathan Miller , Josh Poimboeuf , Dave Hansen , Alan Modra , Scott Wood , Paul Mackerras , linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > > ... > > bl relocate > > > > #Flush the d-cache and invalidate the i-cache here > > #endif > > > > > > This would let the different platforms do the the cache > > invalidation in their own way. > > > > Btw, I didn't find an instruction to flush the entire d-cache in > > PPC440 manual. We have instructions to flush only a block > > corresponding to an address. > > > > However, we have 'iccci' which would invalidate the entire i-cache > > which, which I think is better than 80,000 i-cache invalidates. > > In misc_32.S there are already some platform-independent cache > management functions. If we use those, then relocate() could simply > call them. Then the different platforms calling relocate() wouldn't > have to worry about flushing/invalidating caches. > > For example, there's a clean_dcache_range() function. Given any range > twice the size of the d-cache, it should flush the entire d-cache. > But the only drawback is that it would require the caller to know the > size of the d-cache. > > Instead, I think it would be preferable to create a new clean_dcache() > (or clean_dcache_all()?) function in misc_32.S, which could call > clean_dcache_range() with the appropriate args for flushing the entire > d-cache. relocate() could then call the platform-independent > clean_dcache(). > How about using clean_dcache_range() to flush the range runtime address range [ _stext, _end ] ? That would flush the entire instructions. > 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 ? > > Suzuki, if you agree with this direction, I could work up a new patch > if needed. > I have the following (untested) patch which uses clean_dcache_range() and flush_instruction_cache(): I will send the next version soon with those changes and the DYNAMIC_MEMSTART config for oldstyle relocatoin, if every one agrees to this. diff --git a/arch/powerpc/kernel/reloc_32.S b/arch/powerpc/kernel/reloc_32.S index 045d61e..cce0510 100644 --- a/arch/powerpc/kernel/reloc_32.S +++ b/arch/powerpc/kernel/reloc_32.S @@ -33,10 +33,9 @@ R_PPC_RELATIVE = 22 _GLOBAL(relocate) - mflr r0 + mflr r14 /* Save our LR */ bl 0f /* Find our current runtime address */ 0: mflr r12 /* Make it accessible */ - mtlr r0 lwz r11, (p_dyn - 0b)(r12) add r11, r11, r12 /* runtime address of .dynamic section */ @@ -87,18 +86,19 @@ eodyn: /* End of Dyn Table scan */ * Work out the current offset from the link time address of .rela * section. * cur_offset[r7] = rela.run[r9] - rela.link [r7] - * _stext.link[r10] = _stext.run[r10] - cur_offset[r7] - * final_offset[r3] = _stext.final[r3] - _stext.link[r10] + * _stext.link[r12] = _stext.run[r10] - cur_offset[r7] + * final_offset[r3] = _stext.final[r3] - _stext.link[r12] */ subf r7, r7, r9 /* cur_offset */ - subf r10, r7, r10 - subf r3, r10, r3 /* final_offset */ + subf r12, r7, r10 + subf r3, r12, r3 /* final_offset */ subf r8, r6, r8 /* relaz -= relaent */ /* * Scan through the .rela table and process each entry * r9 - points to the current .rela table entry * r13 - points to the symbol table + * r10 - holds the runtime address of _stext */ /* @@ -180,12 +180,23 @@ store_half: nxtrela: cmpwi r8, 0 /* relasz = 0 ? */ - ble done + ble flush add r9, r9, r6 /* move to next entry in the .rela table */ subf r8, r6, r8 /* relasz -= relaent */ b applyrela -done: blr + /* Flush the d-cache'd instructions */ +flush: + mr r3, r10 + lis r4, (_end - _stext)@h + ori r4, r4, (_end - _stext)@l + add r4, r3, r4 + bl clean_dcache_range + /* Invalidate the i-cache */ + bl flush_instruction_cache +done: + mtlr r14 + blr p_dyn: .long __dynamic_start - 0b Thanks Suzuki