[PATCH] ARM: exynos4: fix secondary CPU boot
From: Angus Ainslie <hidden>
Date: 2011-06-14 22:26:34
Also in:
linux-samsung-soc
On Thu, Jun 2, 2011 at 2:54 AM, Marc Zyngier [off-list ref] wrote:
On Thu, 2011-06-02 at 17:39 +0900, Kyungmin Park wrote:quoted
On Thu, Jun 2, 2011 at 5:34 PM, Marc Zyngier [off-list ref] wrote:quoted
On Thu, 2011-06-02 at 16:01 +0900, Kyungmin Park wrote:quoted
On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier [off-list ref] wrote:quoted
On Wed, 2011-05-25 at 12:06 -0700, Kukjin Kim wrote:quoted
On 05/25/11 11:04, Marc Zyngier wrote:quoted
On Wed, 2011-05-25 at 10:28 -0700, Kukjin Kim wrote:quoted
On 05/20/11 06:46, Marc Zyngier wrote:(snip)quoted
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...quoted
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 EVT2Apparently, 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 at 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.