summaryrefslogtreecommitdiffstats
path: root/arch/arm/boot
diff options
context:
space:
mode:
authorDoug Anderson <dianders@chromium.org>2014-06-21 19:30:53 +0900
committerKukjin Kim <kgene.kim@samsung.com>2014-06-21 19:30:53 +0900
commit7cbcb9d46f9194eb1f88c253a08c0292b2883acc (patch)
tree3d186806ead0b836c0b3d45b23f964b47e012004 /arch/arm/boot
parentc0c3c3590d0d178cd461f0c29aca0e83294c4bc4 (diff)
ARM: EXYNOS: Don't rely on firmware's secondary_cpu_start for mcpm
On exynos mcpm systems the firmware is hardcoded to jump to an address in SRAM (0x02073000) when secondary CPUs come up. By default the firmware puts a bunch of code at that location. That code expects the kernel to fill in a few slots with addresses that it uses to jump back to the kernel's entry point for secondary CPUs. Originally (on prerelease hardware) this firmware code contained a bunch of workarounds to deal with boot ROM bugs. However on all shipped hardware we simply use this code to redirect to a kernel function for bringing up the CPUs. Let's stop relying on the code provided by the bootloader and just plumb in our own (simple) code jump to the kernel. This has the nice benefit of fixing problems due to the fact that older bootloaders (like the one shipped on the Samsung Chromebook 2) might have put slightly different code into this location. Once suspend/resume is implemented for systems using exynos-mcpm we'll need to make sure we reinstall our fixed up code after resume. ...but that's not anything new since IRAM (and thus the address of the mcpm_entry_point) is lost across suspend/resume anyway. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Diffstat (limited to 'arch/arm/boot')
0 files changed, 0 insertions, 0 deletions