lkml.org 
[lkml]   [2014]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
From
Hi Doug,

On 13 June 2014 20:40, Doug Anderson <dianders@chromium.org> wrote:
> Chander,
>
> On Fri, Jun 13, 2014 at 4:54 AM, Chander Kashyap <k.chander@samsung.com> wrote:
>> This patch is effectively changing the mcpm_entry_point address from
>> nsbase + 0x1c to nsbase + 0x8
>>
>> Hence while integrating with mainline u-boot we need to take care for
>> new mcpm_entry_point address.
>>
>> With Chromebook it works straightforward.
>
> Can you explain more and point to the code that is using the nsbase +
> 0x1c? Specifically the only code I see that uses the nsbase + 0x1c is
> the code that is located at nsbase, which is the code we're
> overwriting here. I'd imagine you're using U-Boot code that looks
> something like the bits that start at code_base here:
>
> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/ce358daf5069f1dc145b0f9d403cfbb028271807/arch/arm/cpu/armv7/exynos/lowlevel.S
>
> With my kernel change you can completely eliminate U-Boot's
> installation of this code (or keep it, it makes no difference).

Yes i agree with your point.
What i am saying is when there is full support for Exynos5420 in
mainline u-boot we need to take care for the mcpm_entry_point address.

>
> -Doug



--
with warm regards,
Chander Kashyap


\
 
 \ /
  Last update: 2014-06-16 10:21    [W:0.065 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site