From patchwork Wed Jun 15 09:53:31 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 881502 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5F9sGsp031104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2011 09:54:37 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QWmnV-0000xz-Be; Wed, 15 Jun 2011 09:54:05 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QWmnU-0006LV-Vc; Wed, 15 Jun 2011 09:54:04 +0000 Received: from casper.infradead.org ([2001:770:15f::2]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QWmnS-0006LP-DF for linux-arm-kernel@canuck.infradead.org; Wed, 15 Jun 2011 09:54:02 +0000 Received: from service87.mimecast.com ([94.185.240.25]) by casper.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1QWmnQ-0006Q0-1X for linux-arm-kernel@lists.infradead.org; Wed, 15 Jun 2011 09:54:00 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 15 Jun 2011 10:53:30 +0100 Received: from [10.1.66.40] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jun 2011 10:54:07 +0100 Message-ID: <4DF8811B.9090506@arm.com> Date: Wed, 15 Jun 2011 10:53:31 +0100 From: Marc Zyngier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kyungmin Park Subject: Re: [PATCH] ARM: exynos4: fix secondary CPU boot References: <1305899190-16732-1-git-send-email-marc.zyngier@arm.com> <4DDD3C57.6020705@samsung.com> <1306346645.27474.182.camel@e102391-lin.cambridge.arm.com> <4DDD531A.50604@samsung.com> <1306422710.27474.237.camel@e102391-lin.cambridge.arm.com> <1307003689.31098.6.camel@e102391-lin.cambridge.arm.com> <1307004853.31098.12.camel@e102391-lin.cambridge.arm.com> In-Reply-To: X-Enigmail-Version: 1.1.2 X-OriginalArrivalTime: 15 Jun 2011 09:54:07.0356 (UTC) FILETIME=[2AD85BC0:01CC2B42] X-MC-Unique: 111061510533100201 X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110615_105400_154978_4EC5F0FB X-CRM114-Status: GOOD ( 41.77 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2-r929478 on casper.infradead.org summary: Content analysis details: (-2.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [94.185.240.25 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Kukjin Kim , "linux-samsung-soc@vger.kernel.org" , Angus Ainslie , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Wed, 15 Jun 2011 09:54:37 +0000 (UTC) On 15/06/11 01:52, Kyungmin Park wrote: > On Wed, Jun 15, 2011 at 7:26 AM, Angus Ainslie wrote: >> On Thu, Jun 2, 2011 at 2:54 AM, Marc Zyngier wrote: >>> On Thu, 2011-06-02 at 17:39 +0900, Kyungmin Park wrote: >>>> On Thu, Jun 2, 2011 at 5:34 PM, Marc Zyngier wrote: >>>>> On Thu, 2011-06-02 at 16:01 +0900, Kyungmin Park wrote: >>>>>> On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier wrote: >>>>>>> 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? >>>>>> >>>>>> It's also required for OneNAND. as you know C210 EVT0 OneNAND DMA has >>>>>> bug and need to workaround. >>>>>> >>>>>> platform codes should provide the these function. please see the OMAP >>>>>> codes. how to handle it. >>>>> >>>>> So we know there's a need beyond the wish to see the second core up and >>>>> running on my board. >>>>> >>>>> Now what is the proper method to detect the revision of the SOC? >>>>> Handling it is no problem, once we have the information. Unfortunately >>>>> the documentation I have is less than helpful on that subject. >>>> >>>> It can be distinguished by chip id. but there's no code to handle this one. >>>> >>>> 0x4320 0200 EVT0 >>>> 0x4321 0210 EVT1 >>>> 0x4321 0211 EVT2 >>> >>> Apparently, the low 8 bits can be overloaded by the efuse. Which makes >>> telling EVT1 from EVT2 unreliable. >>> >>> But at least this is a start. I'll see if I can come up with something >>> minimal enough to be merged as a fix. >>> >>> Thanks, >>> >>> 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@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> Would something like this work instead ? It seems to work on EVT0 but >> I haven't had a chance to test on EVT1. >> >> >> From a4c1b643596599df9d79776c9b94f2536661a4c9 Mon Sep 17 00:00:00 2001 >> From: Angus Ainslie >> Date: Tue, 14 Jun 2011 16:13:35 -0600 >> 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). >> >> Use the CPU id to decide whether we are running on EVT0 and use the >> old location in that case. > > Hi Angus, > > Now this information is also required for other device drivers such as OneNAND. > So can you make a generic function at common place such as plat-s5p? > I mean we need a generic helper function for handling the EVT version > at samsung platform. Here's what I have in my current tree. I just added a s3c_get_chip_id() helper, and used that in the secondary boot path. The same function could be used for OneNAND and MCT. Cheers, M. Acked-by: Kyungmin Park diff --git a/arch/arm/mach-exynos4/include/mach/map.h b/arch/arm/mach-exynos4/include/mach/map.h index 57d8074..da08f5c 100644 --- a/arch/arm/mach-exynos4/include/mach/map.h +++ b/arch/arm/mach-exynos4/include/mach/map.h @@ -24,6 +24,7 @@ #include #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..086d1e3 100644 --- a/arch/arm/mach-exynos4/platsmp.c +++ b/arch/arm/mach-exynos4/platsmp.c @@ -26,6 +26,8 @@ #include #include +#include + #include #include @@ -170,6 +172,24 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus) * system-wide flags register. The boot monitor waits * until it receives a soft interrupt, and then the * secondary CPU branches to this address. + * + * EVT0 has the system-wide flags register at a different + * address, hence the following hackery... */ - __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), S5P_VA_SYSRAM); + if (s3c_get_chip_id() & 0xF0000UL) + __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), + S5P_VA_SYSRAM); + else { + void __iomem *sysram_evt0; + + sysram_evt0 = ioremap(EXYNOS4_PA_SYSRAM_EVT0, SZ_4K); + if (!sysram_evt0) { + pr_err("Unable to remap EXYNOS4_PA_SYSRAM_EVT0\n"); + return; + } + __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), + sysram_evt0); + iounmap(sysram_evt0); + } + } diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h index c0a5741..41573cc 100644 --- a/arch/arm/plat-samsung/include/plat/cpu.h +++ b/arch/arm/plat-samsung/include/plat/cpu.h @@ -44,6 +44,8 @@ struct cpu_table { extern void s3c_init_cpu(unsigned long idcode, struct cpu_table *cpus, unsigned int cputab_size); +extern unsigned long s3c_get_chip_id(void); + /* core initialisation functions */ extern void s3c24xx_init_irq(void); diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c index 79d10fc..320b88f 100644 --- a/arch/arm/plat-samsung/init.c +++ b/arch/arm/plat-samsung/init.c @@ -30,6 +30,7 @@ #include static struct cpu_table *cpu; +static unsigned long s3c_chip_id; static struct cpu_table * __init s3c_lookup_cpu(unsigned long idcode, struct cpu_table *tab, @@ -60,6 +61,8 @@ void __init s3c_init_cpu(unsigned long idcode, panic("Unsupported Samsung CPU"); } + s3c_chip_id = idcode; + cpu->map_io(); } @@ -140,6 +143,11 @@ void __init s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no) (cpu->init_uarts)(cfg, no); } +unsigned long s3c_get_chip_id(void) +{ + return s3c_chip_id; +} + static int __init s3c_arch_init(void) { int ret;