forked from luck/tmp_suning_uos_patched
d1d47ec6e6
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@xes-inc.com> Signed-off-by: Nate Case <ncase@xes-inc.com> Reported-by: Dipen Dudhat <B09055@freescale.com> Tested-by: Dipen Dudhat <B09055@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> |
||
|---|---|---|
| .. | ||
| boot | ||
| configs | ||
| include/asm | ||
| kernel | ||
| kvm | ||
| lib | ||
| math-emu | ||
| mm | ||
| oprofile | ||
| platforms | ||
| sysdev | ||
| xmon | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||
| relocs_check.pl | ||