| Message ID | 1444624667-8818-12-git-send-email-bmeng.cn@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Bin, On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> > --- > > arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ > 1 file changed, 6 insertions(+) Acked-by: Simon Glass <sjg@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. Also I don't see any speed-up from using the cache on Minnowmax. Regards, Simon
On 18 October 2015 at 14:27, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> >> --- >> >> arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ >> 1 file changed, 6 insertions(+) > > Acked-by: Simon Glass <sjg@chromium.org> Applied to u-boot-x86, thanks!
Hi Simon, On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> >> --- >> >> arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ >> 1 file changed, 6 insertions(+) > > Acked-by: Simon Glass <sjg@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? > > 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
Hi Bin, On 18 October 2015 at 20:01, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> >>> --- >>> >>> arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >> >> Acked-by: Simon Glass <sjg@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. 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
Hi Simon, On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 18 October 2015 at 20:01, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> >>>> --- >>>> >>>> arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>> >>> Acked-by: Simon Glass <sjg@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
Hi Bin, On 18 October 2015 at 20:31, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 18 October 2015 at 20:01, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi Simon, >>> >>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass <sjg@chromium.org> wrote: >>>> Hi Bin, >>>> >>>> On 11 October 2015 at 22:37, Bin Meng <bmeng.cn@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@gmail.com> >>>>> --- >>>>> >>>>> arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ >>>>> 1 file changed, 6 insertions(+) >>>> >>>> Acked-by: Simon Glass <sjg@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
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(); +}
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@gmail.com> --- arch/x86/cpu/baytrail/valleyview.c | 6 ++++++ 1 file changed, 6 insertions(+)