Problems booting exynos5420 with >1 CPU

[Abhilash Kesavan]

Hi Doug,

On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson <dianders at google.com> wrote:
> Abhilash,
>
> On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
> <kesavan.abhilash at gmail.com> wrote:
>> Hi Doug,
>>
>> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson <dianders at google.com> wrote:
>>> Abhilash,
>>>
>>>
>>>
>>> On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
>>> <kesavan.abhilash at gmail.com> wrote:
>>>> Hi Doug,
>>>>
>>>> On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson <dianders at google.com> wrote:
>>>>> Abhilash,
>>>>>
>>>>> On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan
>>>>> <kesavan.abhilash at gmail.com> wrote:
>>>>>> Hi Doug,
>>>>>>
>>>>>> The first change in the kernel (clearing an iRAM location) is needed
>>>>>> because of an unnecessary change that we are carrying in the Chrome
>>>>>> U-boot. There is no reason for us to have the workaround in the
>>>>>> mainline kernel. Rather, we should remove the check from our u-boot.
>>>>>> However AFAIR a clean-up patch that I had posted internally was not
>>>>>> accepted as we had frozen the SPL at the time.
>>>>>
>>>>> Ah, is that this one, or a different one?
>>>>>
>>>>> https://chromium-review.googlesource.com/#/c/66049/
>>>> Yes, this along with a kernel side change.
>>>
>>> Can we safely take this one without the kernel-side one?
>> Yes, just the u-boot change should suffice.
>>>
>>>
>>>>> If we land that patch now it won't help since nobody is going to be
>>>>> updating their read-only firmware.  We'll need to put code somewhere
>>>>> that fixes it.
>>>> We just carry the workaround fix locally until we migrate to mainline
>>>> u-boot for 5420 where the unnecessay check will not be present.
>>>
>>> I think there are people out there who want to run a mainline kernel
>>> on existing Chromebook 2 hardware and don't want to rewrite their RO
>>> firmware.  We need a solution for those people.
>> Yes, I see your point. But, do you think someone who has changed the
>> existing fused kernel on the device to a mainline one would be averse
>> to applying a couple of small work-around changes as well ? Their
>> finding this thread and the proposed "magic" fixes may be difficult
>> but not the actual application I think.
>>
>> How about having a page similar to
>> "http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/using-an-upstream-kernel-on-snow"
>> for Peach ? We could have the work-arounds listed there.
>
> We can (though the fewer weird things we have the better), but we
> definitely need to provide workarounds that don't require people to
> change their RO firmware.
I do not quite agree with this. They do not need to change their RO
firmware, just modify their boot commands.
>
> Thinking all that through, I think the answer is that we want to
> abandon the U-Boot change above
> <https://chromium-review.googlesource.com/#/c/66049/>.  At this point
> we're never going to take it at this point and there's no possible way
> to do it in an RW firmware update (right?) since any workaround would
> be overwritten by the SPL at resume time.
Sure, will abandon.
>
> So the proper "fix" for the "mw.l 02073028 0" is a kernel fix.  ...and
I believe there is no "proper" fix for incorrect existing code in
non-mainline u-boot.

> if upstream doesn't want land it because it's impure then we'll just
> have to list it on our "apply these hacks to your kernel".  You sent
> me this as a kernel fix before and now I think I understand why (to
> handle the s2r case).  Can you please post this up to the mailing
> list?  Please make sure it will handle the suspend/resume case
> whenever suspend/resume starts working (I haven't tested but I
> remember hearing that it doesn't work).

Are you talking about the re-writing the mcpm entry point address post-resume ?
>
> Note: I think there are actually two possible kernel fixes (right?):
> 1. Have the kernel itself (re)write the code at 0x02073000 at bootup /
> resume time.  I don't know of any reason why this should need to be in
> U-Boot.  Maybe upstream would take this?

>
> 2. Have the kernel clear this flag to work with existing Chromebook 2 firmware.
>
> --
>
> The proper "fix" for the "mw.l 10d25000 3" is a U-Boot fix.  Let me
> see if I can put together something that will handle this in RW
> U-Boot.  Even if we don't officially ship this RW U-Boot we can always
> point people at the binaries.
>
>
> Does that make sense?
>
> -Doug