[PATCH] ARM: exynos4: fix secondary CPU boot

[Angus Ainslie]

On Thu, Jun 2, 2011 at 2:54 AM, Marc Zyngier <Marc.Zyngier at arm.com> wrote:
> On Thu, 2011-06-02 at 17:39 +0900, Kyungmin Park wrote:
>> On Thu, Jun 2, 2011 at 5:34 PM, Marc Zyngier <Marc.Zyngier at arm.com> wrote:
>> > On Thu, 2011-06-02 at 16:01 +0900, Kyungmin Park wrote:
>> >> On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier <Marc.Zyngier at arm.com> 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 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.