[PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem

[Kumar Gala]

On Dec 18, 2009, at 4:50 PM, Peter Tyser wrote:

> Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
> the "cpu-release-addr" device tree property to contain the physical RAM
> location that secondary cores were spinning at.  Previously, the
> "cpu-release-addr" property contained a value referencing the boot page
> translation address range of 0xfffffxxx, which then indirectly accessed
> RAM.
> 
> The "cpu-release-addr" is currently ioremapped and the secondary cores
> kicked.  However, due to the recent change in "cpu-release-addr", it
> sometimes points to a memory location in low memory that cannot be
> ioremapped.  For example on a P2020-based board with 512MB of RAM the
> following error occurs on bootup:
> 
>  <...>
>  mpic: requesting IPIs ...
>  __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
>  Unable to handle kernel paging request for data at address 0x00000014
>  Faulting instruction address: 0xc05df9b0
>  Oops: Kernel access of bad area, sig: 11 [#1]
>  SMP NR_CPUS=2 P2020 RDB
>  Modules linked in:
>  <... eventual kernel panic>
> 
> Adding logic to conditionally ioremap or access memory directly resolves
> the issue.
> 
> Signed-off-by: Peter Tyser <ptyser at xes-inc.com>
> Signed-off-by: Nate Case <ncase at xes-inc.com>
> Reported-by: Dipen Dudhat <B09055 at freescale.com>
> Tested-by: Dipen Dudhat <B09055 at freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c |   21 +++++++++++++++++++--
> 1 files changed, 19 insertions(+), 2 deletions(-)

applied to merge for 2.6.33

- k