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

[Bin Meng]

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.

>
> 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?

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?

Regards,
Bin