| Message ID | 1402096465-13218-1-git-send-email-dianders@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 6 Jun 2014, Doug Anderson wrote: > 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: Nicolas Pitre <nico@linaro.org> > --- > Changes in v2: > - Removed #define > > arch/arm/mach-exynos/mcpm-exynos.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c > index 0498d0b..ace0ed6 100644 > --- a/arch/arm/mach-exynos/mcpm-exynos.c > +++ b/arch/arm/mach-exynos/mcpm-exynos.c > @@ -25,7 +25,6 @@ > > #define EXYNOS5420_CPUS_PER_CLUSTER 4 > #define EXYNOS5420_NR_CLUSTERS 2 > -#define MCPM_BOOT_ADDR_OFFSET 0x1c > > /* > * The common v7_exit_coherency_flush API could not be used because of the > @@ -343,11 +342,13 @@ static int __init exynos_mcpm_init(void) > pr_info("Exynos MCPM support installed\n"); > > /* > - * Future entries into the kernel can now go > - * through the cluster entry vectors. > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr > + * as part of secondary_cpu_start(). Let's redirect it to the > + * mcpm_entry_point(). > */ > - __raw_writel(virt_to_phys(mcpm_entry_point), > - ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET); > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */ > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */ > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8); > > iounmap(ns_sram_base_addr); > > -- > 2.0.0.526.g5318336 >
Doug Anderson <dianders@chromium.org> writes: > 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> I confirm that this patch (plus the enable CCI hack[1]) allows me to see all 8 cores when booting linux-next on my Chromebook2. Kevin [1] While waiting for the forth-coming patch from Andrew to enable the CCI port for the boot cluster), I do this from u-boot before starting the kernel (based on earlier email from Doug): mw.l 10d25000 3 # Enable CCI from U-Boot
> [1] While waiting for the forth-coming patch from Andrew to enable the > CCI port for the boot cluster), I do this from u-boot before starting > the kernel (based on earlier email from Doug): > > mw.l 10d25000 3 # Enable CCI from U-Boot From the other thread, it sounds like Nicolas wants enabling of the boot cluster's CCI port to be done unconditionally for all MCPM platforms. Nicolas, are you preparing a patch for this or should I? The only issue I see with making the MCPM loopback generic is that although all current mainline MCPM platforms have the same cache flush procedure, a future platform could be different. Thanks, Andrew
On Mon, 9 Jun 2014, Andrew Bresticker wrote: > > [1] While waiting for the forth-coming patch from Andrew to enable the > > CCI port for the boot cluster), I do this from u-boot before starting > > the kernel (based on earlier email from Doug): > > > > mw.l 10d25000 3 # Enable CCI from U-Boot > > From the other thread, it sounds like Nicolas wants enabling of the > boot cluster's CCI port to be done unconditionally for all MCPM > platforms. Nicolas, are you preparing a patch for this or should I? I would like confirmation this indeed solves your problem first before I go ahead with it. > The only issue I see with making the MCPM loopback generic is that > although all current mainline MCPM platforms have the same cache flush > procedure, a future platform could be different. If you look at my patch the cache flush is factored out. Nicolas
On Mon, Jun 9, 2014 at 1:22 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Mon, 9 Jun 2014, Andrew Bresticker wrote: > >> > [1] While waiting for the forth-coming patch from Andrew to enable the >> > CCI port for the boot cluster), I do this from u-boot before starting >> > the kernel (based on earlier email from Doug): >> > >> > mw.l 10d25000 3 # Enable CCI from U-Boot >> >> From the other thread, it sounds like Nicolas wants enabling of the >> boot cluster's CCI port to be done unconditionally for all MCPM >> platforms. Nicolas, are you preparing a patch for this or should I? > > I would like confirmation this indeed solves your problem first before I > go ahead with it. FYI... I confirmed on the other thread. It works on the Chromebook2. Kevin
On Mon, 9 Jun 2014, Kevin Hilman wrote: > On Mon, Jun 9, 2014 at 1:22 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > > On Mon, 9 Jun 2014, Andrew Bresticker wrote: > > > >> > [1] While waiting for the forth-coming patch from Andrew to enable the > >> > CCI port for the boot cluster), I do this from u-boot before starting > >> > the kernel (based on earlier email from Doug): > >> > > >> > mw.l 10d25000 3 # Enable CCI from U-Boot > >> > >> From the other thread, it sounds like Nicolas wants enabling of the > >> boot cluster's CCI port to be done unconditionally for all MCPM > >> platforms. Nicolas, are you preparing a patch for this or should I? > > > > I would like confirmation this indeed solves your problem first before I > > go ahead with it. > > FYI... I confirmed on the other thread. It works on the Chromebook2. OK I'll clean it up for mainline. Nicolas
Nicolas, On Mon, Jun 9, 2014 at 1:55 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Mon, 9 Jun 2014, Kevin Hilman wrote: > >> On Mon, Jun 9, 2014 at 1:22 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: >> > On Mon, 9 Jun 2014, Andrew Bresticker wrote: >> > >> >> > [1] While waiting for the forth-coming patch from Andrew to enable the >> >> > CCI port for the boot cluster), I do this from u-boot before starting >> >> > the kernel (based on earlier email from Doug): >> >> > >> >> > mw.l 10d25000 3 # Enable CCI from U-Boot >> >> >> >> From the other thread, it sounds like Nicolas wants enabling of the >> >> boot cluster's CCI port to be done unconditionally for all MCPM >> >> platforms. Nicolas, are you preparing a patch for this or should I? >> > >> > I would like confirmation this indeed solves your problem first before I >> > go ahead with it. >> >> FYI... I confirmed on the other thread. It works on the Chromebook2. > > OK I'll clean it up for mainline. I just wanted to double-check that this is still on your list of things to do. If not then please let us know! :) -Doug
On Mon, 16 Jun 2014, Doug Anderson wrote: > Nicolas, > > On Mon, Jun 9, 2014 at 1:55 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > > On Mon, 9 Jun 2014, Kevin Hilman wrote: > > > >> On Mon, Jun 9, 2014 at 1:22 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > >> > On Mon, 9 Jun 2014, Andrew Bresticker wrote: > >> > > >> >> > [1] While waiting for the forth-coming patch from Andrew to enable the > >> >> > CCI port for the boot cluster), I do this from u-boot before starting > >> >> > the kernel (based on earlier email from Doug): > >> >> > > >> >> > mw.l 10d25000 3 # Enable CCI from U-Boot > >> >> > >> >> From the other thread, it sounds like Nicolas wants enabling of the > >> >> boot cluster's CCI port to be done unconditionally for all MCPM > >> >> platforms. Nicolas, are you preparing a patch for this or should I? > >> > > >> > I would like confirmation this indeed solves your problem first before I > >> > go ahead with it. > >> > >> FYI... I confirmed on the other thread. It works on the Chromebook2. > > > > OK I'll clean it up for mainline. > > I just wanted to double-check that this is still on your list of > things to do. If not then please let us know! :) It is. Nicolas
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c index 0498d0b..ace0ed6 100644 --- a/arch/arm/mach-exynos/mcpm-exynos.c +++ b/arch/arm/mach-exynos/mcpm-exynos.c @@ -25,7 +25,6 @@ #define EXYNOS5420_CPUS_PER_CLUSTER 4 #define EXYNOS5420_NR_CLUSTERS 2 -#define MCPM_BOOT_ADDR_OFFSET 0x1c /* * The common v7_exit_coherency_flush API could not be used because of the @@ -343,11 +342,13 @@ static int __init exynos_mcpm_init(void) pr_info("Exynos MCPM support installed\n"); /* - * Future entries into the kernel can now go - * through the cluster entry vectors. + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr + * as part of secondary_cpu_start(). Let's redirect it to the + * mcpm_entry_point(). */ - __raw_writel(virt_to_phys(mcpm_entry_point), - ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET); + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */ + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */ + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8); iounmap(ns_sram_base_addr);
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> --- Changes in v2: - Removed #define arch/arm/mach-exynos/mcpm-exynos.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)