subject:"\[U\-Boot\] \[PATCH 11\/13\] x86\: baytrail\: Issue full system reset in reset

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

2015-11-06 Thread Simon Glass

Hi Bin,

On 18 October 2015 at 20:31, Bin Meng  wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 18 October 2015 at 20:01, Bin Meng  wrote:
>>> Hi Simon,
>>>
>>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass  wrote:
 Hi Bin,

 On 11 October 2015 at 22:37, Bin Meng  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 
> ---
>
>  arch/x86/cpu/baytrail/valleyview.c | 6 ++
>  1 file changed, 6 insertions(+)

 Acked-by: Simon Glass 

>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-18 Thread Bin Meng

Hi Simon,

On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 October 2015 at 22:37, Bin Meng  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 
>> ---
>>
>>  arch/x86/cpu/baytrail/valleyview.c | 6 ++
>>  1 file changed, 6 insertions(+)
>
> Acked-by: Simon Glass 
>
>>
>> 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?

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

>
> Regards,
> Simon

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-18 Thread Simon Glass

Hi Bin,

On 11 October 2015 at 22:37, Bin Meng  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 
> ---
>
>  arch/x86/cpu/baytrail/valleyview.c | 6 ++
>  1 file changed, 6 insertions(+)

Acked-by: Simon Glass 

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

Also I don't see any speed-up from using the cache on Minnowmax.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-18 Thread Bin Meng

Hi Simon,

On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 18 October 2015 at 20:01, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass  wrote:
>>> Hi Bin,
>>>
>>> On 11 October 2015 at 22:37, Bin Meng  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 
 ---

  arch/x86/cpu/baytrail/valleyview.c | 6 ++
  1 file changed, 6 insertions(+)
>>>
>>> Acked-by: Simon Glass 
>>>

 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-18 Thread Simon Glass

Hi Bin,

On 18 October 2015 at 20:01, Bin Meng  wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 11 October 2015 at 22:37, Bin Meng  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 
>>> ---
>>>
>>>  arch/x86/cpu/baytrail/valleyview.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>
>> Acked-by: Simon Glass 
>>
>>>
>>> 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.

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?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-18 Thread Simon Glass

On 18 October 2015 at 14:27, Simon Glass  wrote:
> Hi Bin,
>
> On 11 October 2015 at 22:37, Bin Meng  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 
>> ---
>>
>>  arch/x86/cpu/baytrail/valleyview.c | 6 ++
>>  1 file changed, 6 insertions(+)
>
> Acked-by: Simon Glass 

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-10-11 Thread Bin Meng

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

 arch/x86/cpu/baytrail/valleyview.c | 6 ++
 1 file changed, 6 insertions(+)

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

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

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

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

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

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

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

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

7 matches

Site Navigation

Mail list logo

Footer information