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 <pty...@xes-inc.com> > Signed-off-by: Nate Case <nc...@xes-inc.com> > Reported-by: Dipen Dudhat <b09...@freescale.com> > Tested-by: Dipen Dudhat <b09...@freescale.com> > --- > arch/powerpc/platforms/85xx/smp.c | 21 +++++++++++++++++++-- > 1 files changed, 19 insertions(+), 2 deletions(-)
applied to merge for 2.6.33 - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
