[U-Boot] Regression in U-boot v2019-07-rcX
Hi!
I have noticed today the regression in newer U-Boot. For now I'm not sure which version is affected first. At least v2019.07-rc4 behaves badly.
Under badly I mean the following. Consider the output at the boot time:
U-Boot 2019.07-rc4-00012-gcea7942d57 (Jun 12 2019 - 16:08:09 +0300)
CPU: Intel(R) Atom(TM) CPU U1000 @ 500MHz DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0
Note lines started with DRAM: and MMC:. Now the 4 seconds (!) time is passed between them.
On top of that DFU seems twice slower (on the glance, I haven't measure with `time` yet).
Any ideas, while I'll try to allocate some time to investigate myself?
P.S. The board I'm testing with is Intel Edison. I think no need to tell that nothing has been changed except the base (I'm rebased my stuff on top of latest and greatest U-Boot releases).
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
Hi!
I have noticed today the regression in newer U-Boot. For now I'm not sure which version is affected first. At least v2019.07-rc4 behaves badly.
Under badly I mean the following. Consider the output at the boot time:
U-Boot 2019.07-rc4-00012-gcea7942d57 (Jun 12 2019 - 16:08:09 +0300)
CPU: Intel(R) Atom(TM) CPU U1000 @ 500MHz DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0
Note lines started with DRAM: and MMC:. Now the 4 seconds (!) time is passed between them.
On top of that DFU seems twice slower (on the glance, I haven't measure with `time` yet).
Any ideas, while I'll try to allocate some time to investigate myself?
P.S. The board I'm testing with is Intel Edison. I think no need to tell that nothing has been changed except the base (I'm rebased my stuff on top of latest and greatest U-Boot releases).
v2019.07-rc1 is NOT affected!
The time difference with DFU: -rc1: real 0m1.114s -rc4: real 0m2.691s
Hi Andy,
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
Hi!
I have noticed today the regression in newer U-Boot. For now I'm not sure which version is affected first. At least v2019.07-rc4 behaves badly.
Under badly I mean the following. Consider the output at the boot time:
U-Boot 2019.07-rc4-00012-gcea7942d57 (Jun 12 2019 - 16:08:09 +0300)
CPU: Intel(R) Atom(TM) CPU U1000 @ 500MHz DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0
Note lines started with DRAM: and MMC:. Now the 4 seconds (!) time is passed between them.
On top of that DFU seems twice slower (on the glance, I haven't measure with `time` yet).
Any ideas, while I'll try to allocate some time to investigate myself?
P.S. The board I'm testing with is Intel Edison. I think no need to tell that nothing has been changed except the base (I'm rebased my stuff on top of latest and greatest U-Boot releases).
v2019.07-rc1 is NOT affected!
The time difference with DFU: -rc1: real 0m1.114s -rc4: real 0m2.691s
Could you bisect between -rc1 and -rc4 ?
Thanks in advance,
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Wed, Jun 12, 2019 at 03:37:54PM +0200, Lukasz Majewski wrote:
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
v2019.07-rc1 is NOT affected!
The time difference with DFU: -rc1: real 0m1.114s -rc4: real 0m2.691s
Could you bisect between -rc1 and -rc4 ?
Thanks in advance,
Just did, see my previous message.
On Wed, Jun 12, 2019 at 04:23:37PM +0300, Andy Shevchenko wrote:
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
Hi!
I have noticed today the regression in newer U-Boot. For now I'm not sure which version is affected first. At least v2019.07-rc4 behaves badly.
Under badly I mean the following. Consider the output at the boot time:
U-Boot 2019.07-rc4-00012-gcea7942d57 (Jun 12 2019 - 16:08:09 +0300)
CPU: Intel(R) Atom(TM) CPU U1000 @ 500MHz DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0
Note lines started with DRAM: and MMC:. Now the 4 seconds (!) time is passed between them.
On top of that DFU seems twice slower (on the glance, I haven't measure with `time` yet).
Any ideas, while I'll try to allocate some time to investigate myself?
P.S. The board I'm testing with is Intel Edison. I think no need to tell that nothing has been changed except the base (I'm rebased my stuff on top of latest and greatest U-Boot releases).
v2019.07-rc1 is NOT affected!
The time difference with DFU: -rc1: real 0m1.114s -rc4: real 0m2.691s
The culprit commit is:
commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a Author: Simon Glass sjg@chromium.org Date: Thu Apr 25 21:59:06 2019 -0600
x86: Don't set up MTRRs in SPL
Please revert ASAP before release, thanks!
On Wed, Jun 12, 2019 at 9:49 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Wed, Jun 12, 2019 at 04:23:37PM +0300, Andy Shevchenko wrote:
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
Hi!
I have noticed today the regression in newer U-Boot. For now I'm not sure which version is affected first. At least v2019.07-rc4 behaves badly.
Under badly I mean the following. Consider the output at the boot time:
U-Boot 2019.07-rc4-00012-gcea7942d57 (Jun 12 2019 - 16:08:09 +0300)
CPU: Intel(R) Atom(TM) CPU U1000 @ 500MHz DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0
Note lines started with DRAM: and MMC:. Now the 4 seconds (!) time is passed between them.
On top of that DFU seems twice slower (on the glance, I haven't measure with `time` yet).
Any ideas, while I'll try to allocate some time to investigate myself?
P.S. The board I'm testing with is Intel Edison. I think no need to tell that nothing has been changed except the base (I'm rebased my stuff on top of latest and greatest U-Boot releases).
v2019.07-rc1 is NOT affected!
The time difference with DFU: -rc1: real 0m1.114s -rc4: real 0m2.691s
The culprit commit is:
commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a Author: Simon Glass sjg@chromium.org Date: Thu Apr 25 21:59:06 2019 -0600
x86: Don't set up MTRRs in SPLPlease revert ASAP before release, thanks!
So it looks that MTRRs are not programmed for Intel Edison to enable cache?
Simon, would you please take a look? I suspect simply revert this will break the Chromebook SPL build?
Regards, Bin
On Wed, Jun 12, 2019 at 10:07:11PM +0800, Bin Meng wrote:
On Wed, Jun 12, 2019 at 9:49 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Wed, Jun 12, 2019 at 04:23:37PM +0300, Andy Shevchenko wrote:
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a Author: Simon Glass sjg@chromium.org Date: Thu Apr 25 21:59:06 2019 -0600
x86: Don't set up MTRRs in SPLPlease revert ASAP before release, thanks!
So it looks that MTRRs are not programmed for Intel Edison to enable cache?
Simon, would you please take a look? I suspect simply revert this will break the Chromebook SPL build?
Since there is no activity on this and release is coming, I would propose to revert for now.
Hi Bin, Andy,
On Mon, 17 Jun 2019 at 08:49, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Wed, Jun 12, 2019 at 10:07:11PM +0800, Bin Meng wrote:
On Wed, Jun 12, 2019 at 9:49 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Wed, Jun 12, 2019 at 04:23:37PM +0300, Andy Shevchenko wrote:
On Wed, Jun 12, 2019 at 04:18:25PM +0300, Andy Shevchenko wrote:
commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a Author: Simon Glass sjg@chromium.org Date: Thu Apr 25 21:59:06 2019 -0600
x86: Don't set up MTRRs in SPLPlease revert ASAP before release, thanks!
So it looks that MTRRs are not programmed for Intel Edison to enable cache?
Simon, would you please take a look? I suspect simply revert this will break the Chromebook SPL build?
Since there is no activity on this and release is coming, I would propose to revert for now.
I am OK with a revert for now if we don't have another solution.
The problem here is that we want to select when the mtrrs are programmed.
With my patch, this code is enabled on edison. I think the solution might be to set the mtrrs earlier on link. But I'll need to take a look and it won't be for about two weeks.
Regards, Simon
participants (4)
-
Andy Shevchenko -
Bin Meng -
Lukasz Majewski -
Simon Glass