[U-Boot] [PATCH 11/13] x86: baytrail: Issue full system reset in reset_cpu()

[Simon Glass]

Hi Bin,

On 18 October 2015 at 20:31, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 18 October 2015 at 20:01, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 11 October 2015 at 22:37, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> With MRC cache enabled, when typing 'reset' in the U-Boot shell,
>>>>> BayTrail FSP initialization hangs at "Configuring Memory Start":
>>>>>
>>>>>   Setting BootMode to 0
>>>>>   Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
>>>>>   Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
>>>>>   About to call MrcInit();
>>>>>   BayleyBay Platform Type
>>>>>   CurrentMrcData.BootMode = 4
>>>>>   Taking Fastboot path!
>>>>>   Configuring Memory Start...
>>>>>
>>>>> Changing reset_cpu() to do a full system reset fixes this issue.
>>>>>
>>>>> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
>>>>> ---
>>>>>
>>>>>  arch/x86/cpu/baytrail/valleyview.c | 6 ++++++
>>>>>  1 file changed, 6 insertions(+)
>>>>
>>>> Acked-by: Simon Glass <sjg at chromium.org>
>>>>
>>>>>
>>>>> diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c
>>>>> index 215e0d0..a009c14 100644
>>>>> --- a/arch/x86/cpu/baytrail/valleyview.c
>>>>> +++ b/arch/x86/cpu/baytrail/valleyview.c
>>>>> @@ -65,3 +65,9 @@ int reserve_arch(void)
>>>>>  #endif
>>>>>  }
>>>>>  #endif
>>>>> +
>>>>> +void reset_cpu(ulong addr)
>>>>> +{
>>>>> +       /* cold reset */
>>>>> +       x86_full_reset();
>>>>> +}
>>>>> --
>>>>> 1.8.2.1
>>>>>
>>>>
>>>> Actually on Minnowmax this doesn't fix the hang.
>>>
>>> That's strange. As full reset indicates a complete power cycle. Does
>>> MinnowMax boot with MRC cache enabled?
>>
>> It's hard to tell because the UART does not work that early. I wish we
>> could fix that. I thought I did have it running at one point, but I
>> may have imagined it.
>
> We need figure out where the hang happens. Is it in FSP, or in U-Boot?
> You can use a debug version of FSP (the gold4 release includes a debug
> version FSP) to see where the FSP hangs if it is the FSP hang case.

Ah yes, that's a good idea.

>
>>
>> Re the hang, I'm not sure - it seems to have stopped happening, so
>> let's not worry about it for now.
>>
>>
>>>>
>>>> Also I don't see any speed-up from using the cache on Minnowmax.
>>>
>>> On Galileo, I did not see any speed-up either. I think it is because
>>> on MinnowMax and Galileo they both uses memory-down configuration. The
>>> speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
>>
>> So what is the point of enabling the MRC cache?
>>
>
> On Bayley Bay it indeed improves the boot time. So, maybe we can just
> leave this option unselected by the defconfig files for Chromebook and
> Galileo?

OK. It does speed up link.

>
> One thing I noticed that on Chromebook the memory SPD is passed by
> device tree. Is there any DIMM on the Chromebook and the SPD in device
> tree is just a short-cut for the MRC? If we let MRC reads the SPD,
> does MRC cache help?

Yes there are DIMMs but we know exactly what they are. The MRC cache
does seem to help on this platform.

Regards,
Simon