It's first step to handle the EVT.
Acked-by: Kyungmin Park
> Jazz is not dead. It just smells funny...
> From a24392183d396fab790557b0efb35e840c9e8a81 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Fri, 20 May 2011 14:38:25 +0100
> Subject: [PATCH] ARM: exynos4: fi
1. After wake-up, the system-wide flags register loses its value.
Hence, write the address of secondary startup function to
successfully boot the secondary CPU.
2. Changes SGI1 to SGI0 for secondary CPU boot up
Signed-off-by: Inderpal Singh
---
1. The below patch is mandatory to boot secon
t; 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. Whic
>>> 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
>> mi
t;>
>> 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
> minim
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 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
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
. 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.
Thank you,
Kyungmin Park
>
>> >> From c27e75b86e1ee181987a9364286a888421e76205 Mon Sep 17 00:00:00 2001
>> > From:
On 5/31/2011 3:24 AM, Russell King - ARM Linux wrote:
On Mon, May 30, 2011 at 03:08:17PM +0530, Santosh Shilimkar wrote:
When do you plan to fix the SGI usage as discussed
in above thread. I thought SGI1 usage was ok for OMAP,
realview/versatile and MSM.
I'd like the use of the arbitary SGI1 t
On Mon, May 30, 2011 at 03:08:17PM +0530, Santosh Shilimkar wrote:
> When do you plan to fix the SGI usage as discussed
> in above thread. I thought SGI1 usage was ok for OMAP,
> realview/versatile and MSM.
I'd like the use of the arbitary SGI1 to fade away, to be replaced with
something a little
On 5/30/2011 2:43 PM, Inderpal Singh wrote:
[...]
2. Fix to remove the "Unknown IPI message 0x1" message when
secondary CPU boots.
For this one you are avoiding a wakeup IPI and rather
relying on schedule IPI. That just avoiding the issue.
This doesn't seems to be right. Refer below threa
1. After wake-up, the system-wide flags register loses its value.
Hence, write the address of secondary startup function to
successfully boot the secondary CPU.
2. Fix to remove the "Unknown IPI message 0x1" message when
secondary CPU boots.
Signed-off-by: Inderpal Singh
---
arch/arm/m
e'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
> > Date: Fri, 20 May 2011 14:38:25 +0100
> > Subject:
al way...?
M.
From c27e75b86e1ee181987a9364286a888421e76205 Mon Sep 17 00:00:00 2001
From: Marc Zyngier
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
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.
What about the following patch?
M.
>From c27e75b86e1ee181987a9364286a888421e76205
On 05/20/11 06:46, Marc Zyngier wrote:
Patch 7d30e8b38 (ARM: EXYNOS4: Add EXYNOS4 CPU initialization support)
renamed the s5pv310 to exynos4, and also changed the value of
EXYNOS4_PA_SYSRAM, which is used to release the secondary CPU from
spinning in BL0. As a result, CPU1 can't be brought up any
Patch 7d30e8b38 (ARM: EXYNOS4: Add EXYNOS4 CPU initialization support)
renamed the s5pv310 to exynos4, and also changed the value of
EXYNOS4_PA_SYSRAM, which is used to release the secondary CPU from
spinning in BL0. As a result, CPU1 can't be brought up anymore.
This patch simply reverts EXYNOS4_
18 matches
Mail list logo
