Great! Thank you! :)
From: Kruno Peric [mailto:K.Peric@astronautics.com]
Sent: Thursday, April 25, 2019 8:31
To: Ma, Maurice <maurice.ma(a)intel.com>; sbl-devel(a)lists.01.org
Subject: RE: MRC data retraining
I've created the issue:
https://github.com/slimbootloader/slimbootloader/issues/146
From: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>
Sent: Thursday, April 25, 2019 10:25 AM
To: Kruno Peric <K.Peric@astronautics.com<mailto:K.Peric@astronautics.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
#145 is not an issue, but a pull request. In the commit message, I put "It fixed
#TBD.", and the #TBD is supposed to be an open issue.
All issues will be listed under:
https://github.com/slimbootloader/slimbootloader/issues
All pull requests will be listed under:
https://github.com/slimbootloader/slimbootloader/pulls
Thanks
Maurice
From: Kruno Peric [mailto:K.Peric@astronautics.com]
Sent: Thursday, April 25, 2019 8:19
To: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
I don't believe another issue needs to be opened. Issue #145 covers the bug and the
PR associated fixes it.
From: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>
Sent: Thursday, April 25, 2019 10:16 AM
To: Kruno Peric <K.Peric@astronautics.com<mailto:K.Peric@astronautics.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
Thanks you for the testing. Glad to know the fix worked for you.
Yes, it will roll back every 119 boot cycles.
Are you going to open an issue for it ? Then I can associate the PR with the issue.
https://github.com/slimbootloader/slimbootloader/issues
Thanks
Maurice
From: Kruno Peric [mailto:K.Peric@astronautics.com]
Sent: Thursday, April 25, 2019 7:14
To: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
We did a test, and confirmed that the slots rolled back around at 119. It did not do the
memory retraining, so it appears to be working. We confirmed that it rolled back around
twice.
From: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>
Sent: Thursday, April 25, 2019 12:15 AM
To: Kruno Peric <K.Peric@astronautics.com<mailto:K.Peric@astronautics.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
Hi,
A pull request has been submitted to address this issue.
https://github.com/slimbootloader/slimbootloader/pull/145
Could you please do a test to see if your issue can be fixed with this PR ?
Thanks
Maurice
From: Sbl-devel [mailto:sbl-devel-bounces@lists.01.org] On Behalf Of Rangarajan, Ravi P
Sent: Wednesday, April 24, 2019 21:28
To: Kruno Peric <K.Peric@astronautics.com<mailto:K.Peric@astronautics.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: Re: [Sbl-devel] MRC data retraining
Hi
We are able to reproduce the issue on our side. Would you mind creating an issue in
github. We will provide a fix soon.
Thanks
Ravi
From: Rangarajan, Ravi P
Sent: Wednesday, April 24, 2019 3:27 PM
To: 'Kruno Peric'
<K.Peric@astronautics.com<mailto:K.Peric@astronautics.com>>;
sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: RE: MRC data retraining
Hi
We need to understand what is causing the MRC to do a retraining. Would it be possible for
you to collect the boot logs and provide them - maybe the last 2-3 boots including the
boot where it does retraining? We need to check if SBL is initializing the UPD fields for
FspMemoryInit API correctly.
We will also try to setup a system to see if we can reproduce the issue.
Thanks
Ravi
From: Sbl-devel [mailto:sbl-devel-bounces@lists.01.org] On Behalf Of Kruno Peric
Sent: Wednesday, April 24, 2019 8:33 AM
To: sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org>
Subject: [Sbl-devel] MRC data retraining
In regards to memory training and fast boot, our expectation was that the training would
occur once during the first boot, then the NV saved training data would be used for
subsequent boots so that training could be skipped. However, after 119 boots, the memory
training process repeats. This causes an unacceptably long boot time. Do you have a
recommendation for how to stop the MRC parameter retraining from occurring?