[PATCH] powerpc: Better setup of boot page TLB entry

Kumar Gala kumar.gala at freescale.com
Thu Nov 20 07:51:10 EST 2008


On Nov 19, 2008, at 1:14 PM, Trent Piepho wrote:

> The initial TLB mapping for the kernel boot didn't set the memory  
> coherent
> attribute, MAS2[M], in SMP mode.
>
> If this code supported booting a secondary processor, which it  
> doesn't yet,
> but suppose it did, then when a secondary processor boots, it would  
> have
> probably signaled the primary processor by setting a variable called
> something like __secondary_hold_acknowledge.  However, due to the  
> lack of
> the M bit, the primary processor would not have snooped the  
> transaction
> (even if a transaction were broadcast).  If primary CPU's L1 D-cache  
> had a
> copy, it would not have been flushed and the CPU would have never  
> seen the
> ack.  Which would have resulted in the primary CPU spinning for a long
> time, perhaps a full second before it would have given up, while it  
> would
> have waited for the ack from the secondary CPU that it wouldn't have  
> been
> able to see because of the stale cache.
>
> The value of MAS2 for the boot page TLB1 entry is a compile time  
> constant,
> so there is no need to calculate it in powerpc assembly language.
>
> Also, from the MPC8572 manual section 6.12.5.3, "Bits that represent
> offsets within a page are ignored and should be cleared." Existing  
> code
> didn't clear them, this code does.
>
> The same when the page of KERNELBASE is found; we don't need to use  
> asm to
> mask the lower 12 bits off.
>
> In the code that computes the address to rfi from, don't hard code the
> offset to 24 bytes, but have the assembler figure that out for us.
>
> Signed-off-by: Trent Piepho <tpiepho at freescale.com>
> Acked-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> arch/powerpc/include/asm/mmu-fsl-booke.h |    2 ++
> arch/powerpc/kernel/head_fsl_booke.S     |   22 +++++++++++++---------
> 2 files changed, 15 insertions(+), 9 deletions(-)

applied to next.

- k



More information about the Linuxppc-dev mailing list