On Wed, 2011-05-25 at 12:06 -0700, Kukjin Kim wrote:
> On 05/25/11 11:04, Marc Zyngier wrote:
> > On Wed, 2011-05-25 at 10:28 -0700, Kukjin Kim wrote:
> >> On 05/20/11 06:46, Marc Zyngier wrote:
>
> (snip)
>
> > So that address has changed between two SoC revisions? That's
> > unfortunate, to say the least. I'm most probably using an early revision
> > of the hardware (EVT0?), as it doesn't even support MCT.
> >
> I'm afraid :( and I agree secondary CPU should work on all of
> Exynos4210. But I'm still think about the method...
>
> > What about the following patch?
> >
> Uhm...this is really hack but I'd like to use another normal way...?
Oh, no question about the hack status. The trouble is, unless there is a
sure way to tell which SoC revision we're running on, there's little
else we can do than poke both locations and pray.
Is there such a way to identify the SoC revision?
> >> From c27e75b86e1ee181987a9364286a888421e76205 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier<marc.zyngier@xxxxxxx>
> > Date: Fri, 20 May 2011 14:38:25 +0100
> > Subject: [PATCH] ARM: exynos4: fix secondary CPU boot on early SoC revisions
> >
> > It appears that the system-wide flags register that used to be at
> > 0x02025000 on the first revision of Exynos4 has moved to 0x02020000.
> >
> > The kernel has been updated accordingly, but this unfortunately leaves
> > early boards without SMP support (the secondary CPU spins endlessly
> > in BL0 waiting for an address to be written at that memory location).
> >
> > Try to solve the problem by poking both locations. This should be
> > safe as this is done early enough in the kernel boot process, and nobody
> > should be using the SRAM yet.
> >
> > Tested on a vintage SMDK-v310.
>
> vintage ;)
Well, I thought I was the uber-cool guy in the office because of that
shiny blue board on my desk, only to discover that it's sooo last
year... ;-)
> >
> > Cc: Kukjin Kim<kgene.kim@xxxxxxxxxxx>
> > Signed-off-by: Marc Zyngier<marc.zyngier@xxxxxxx>
> > ---
> > arch/arm/mach-exynos4/include/mach/map.h | 1 +
> > arch/arm/mach-exynos4/platsmp.c | 14 ++++++++++++++
> > 2 files changed, 15 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos4/include/mach/map.h b/arch/arm/mach-exynos4/include/mach/map.h
> > index 0009e77..781e149 100644
> > --- a/arch/arm/mach-exynos4/include/mach/map.h
> > +++ b/arch/arm/mach-exynos4/include/mach/map.h
> > @@ -24,6 +24,7 @@
> > #include<plat/map-s5p.h>
> >
> > #define EXYNOS4_PA_SYSRAM 0x02020000
> > +#define EXYNOS4_PA_SYSRAM_EVT0 0x02025000
> >
> > #define EXYNOS4_PA_FIMC0 0x11800000
> > #define EXYNOS4_PA_FIMC1 0x11810000
> > diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
> > index c5e65a0..f261c34 100644
> > --- a/arch/arm/mach-exynos4/platsmp.c
> > +++ b/arch/arm/mach-exynos4/platsmp.c
> > @@ -155,6 +155,7 @@ void __init smp_init_cpus(void)
> > void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> > {
> > int i;
> > + void __iomem *sysram_evt0;
> >
> > /*
> > * Initialise the present map, which describes the set of CPUs
> > @@ -172,4 +173,17 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> > * secondary CPU branches to this address.
> > */
> > __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), S5P_VA_SYSRAM);
> > +
> > + /*
> > + * EVT0 has the system-wide flags register at a different address.
> > + * Poke it as well, in case we're running on an old SoC revision.
> > + */
> > + sysram_evt0 = ioremap(EXYNOS4_PA_SYSRAM_EVT0, SZ_4K);
>
> Hmm...first of all, need to check whether can ioremap the area on newer
> one but I'm out off office now so will check it after backing.
The only documentation I have access to refers to the iRAM (SRAM) being
mapped between 0x02020000 and 0x02040000. Unless the HW guys have gone
completely wild and changed this range as well, I think we're pretty
safe.
> > + if (!sysram_evt0) {
> > + pr_err("Unable to remap EXYNOS4_PA_SYSRAM_EVT0\n");
>
> Do we really need 'pr_err' here?...
No. Anything will do. Though not being able to ioremap() that region may
indicate further trouble down the road.
> > + return;
> > + }
> > +
> > + __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), sysram_evt0);
> > + iounmap(sysram_evt0);
> > }
>
Cheers,
M.
--
Reality is an implementation detail.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
