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

[Kumar Gala]

On Jan 21, 2010, at 4:28 PM, Peter Tyser wrote:

> On Fri, 2009-12-18 at 16:50 -0600, 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>
> 
> Any chance this going to be picked up for 2.6.33?  The issue is
> currently going to bite anyone using an MP-capable 85xx system that
> doesn't use highmem.

This just got lost in my queue.  Will apply and send up for .33

- k