[PATCH 00/13] powerpc: Backport 8xx TLB to 2.4

Scott Wood scottwood at freescale.com
Fri Jan 14 07:44:00 EST 2011


On Tue, 11 Jan 2011 11:56:32 +0100
Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:

> Joakim Tjernlund/Transmode wrote on 2011/01/11 09:12:44:
> >
> > Willy Tarreau <w at 1wt.eu> wrote on 2011/01/11 07:09:26:
> > >
> > > Hi Joakim,
> > >
> > > On Mon, Jan 10, 2011 at 10:37:46PM +0100, Joakim Tjernlund wrote:
> > > > This is a backport from 2.6 which I did to overcome 8xx CPU
> > > > bugs. 8xx does not update the DAR register when taking a TLB
> > > > error caused by dcbX and icbi insns which makes it very
> > > > tricky to use these insns. Also the dcbst wrongly sets the
> > > > the store bit when faulting into DTLB error.
> > > > A few more bugs very found during development.
> > > >
> > > > I know 2.4 is in strict maintenance mode and 8xx is obsolete
> > > > but as it is still in use I wanted 8xx to age with grace.
> > >
> > > Thank you very much for taking care of this, that's very much appreciated.
> > > I'll look at this ASAP. Just a quick question in order to be certain, did
> > > you have the opportunity to test all of these changes on real hardware ?
> 
> > I tested these on real 8xx HW but I used an older 2.4 linux as we haven't
> > moved forward on 2.4 for quite some time.
> > The affected files were almost identical though. Would be great if
> > Scott could give them a spin on 8xx with current 2.4.

Is ep88xc (the board I have easily available to test) supported in
mainline 2.4?  I don't see a platform file, defconfig, or bootwrapper
code that obviously covers it.

Is there anyone out there actually using 8xx on top-of-tree mainline
2.4 who can test it?

> BTW, it occurred to me that the following 8xx quirk is best
> done in 8xx code:
> 
> From c1985a3b8b16d96ddce5ef90d5a15e70fb8a2aec Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> Date: Tue, 11 Jan 2011 11:24:22 +0100
> Subject: [PATCH] 8xx: Move invalidation of non present TLBs
> 
> 8xx does not invalidate ~PRESENT TLBs, move the workaround
> in mm/fault.c here to keep 8xx quirks localized.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> ---
>  arch/ppc/kernel/head_8xx.S |   12 ++++++++++--
>  arch/ppc/mm/fault.c        |    7 -------
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
> index 75acaa0..24b206c 100644
> --- a/arch/ppc/kernel/head_8xx.S
> +++ b/arch/ppc/kernel/head_8xx.S
> @@ -221,7 +221,11 @@ DataAccess:
>  	mr	r5,r20
>  	mfspr	r4,DAR
>  	stw	r4,_DAR(r21)
> -	li	r20,0x00f0
> +	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
> +	andis.	r20,r5,0x4000
> +	beq+	1f
> +	tlbie	r4
> +1:	li	r20,0x00f
>  	mtspr	DAR,r20	/* Tag DAR */
>  	addi	r3,r1,STACK_FRAME_OVERHEAD
>  	li	r20,MSR_KERNEL
> @@ -238,7 +242,11 @@ InstructionAccess:
>  	addi	r3,r1,STACK_FRAME_OVERHEAD
>  	mr	r4,r22
>  	mr	r5,r23
> -	li	r20,MSR_KERNEL
> +	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
> +	andis.	r20,r5,0x4000
> +	beq+	1f
> +	tlbie	r4
> +1:	li	r20,MSR_KERNEL
>  	rlwimi	r20,r23,0,16,16		/* copy EE bit from saved MSR */
>  	FINISH_EXCEPTION(do_page_fault)
> 
> diff --git a/arch/ppc/mm/fault.c b/arch/ppc/mm/fault.c
> index 874005a..8819fb1 100644
> --- a/arch/ppc/mm/fault.c
> +++ b/arch/ppc/mm/fault.c
> @@ -116,13 +116,6 @@ void do_page_fault(struct pt_regs *regs, unsigned long address,
>  	else
>  		is_write = error_code & 0x02000000;
>  #endif /* CONFIG_4xx || CONFIG_BOOKE */
> -#if defined(CONFIG_8xx)
> -	/* 8xx does no invalidate TLBs that are ~PRESENT,
> -	 * do it here.
> -	 */
> -	if (error_code & 0x40000000)
> -		_tlbie(address);
> -#endif
>  #if defined(CONFIG_XMON) || defined(CONFIG_KGDB)
>  	if (debugger_fault_handler && regs->trap == 0x300) {
>  		debugger_fault_handler(regs);
> --
> 1.7.3.4
> 
> Scott, what do you think of this? Is it safe to call tlbie in this context?

I'd guess so (I assume the concern is MMU translation being off?), but I
don't have any particular knowledge about this.  I'd be checking the
same manual that you have. :-)

-Scott



More information about the Linuxppc-dev mailing list