[U-Boot] Regression in U-boot v2019-07-rcX

[U-Boot] Regression in U-boot v2019-07-rcX

[Andy Shevchenko]

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 at ff3fc000: 0, mmc at 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).

-- 
With Best Regards,
Andy Shevchenko

[U-Boot] Regression in U-boot v2019-07-rcX

[Andy Shevchenko]

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 at ff3fc000: 0, mmc at 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

-- 
With Best Regards,
Andy Shevchenko

[U-Boot] Regression in U-boot v2019-07-rcX

[Lukasz Majewski]

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 at ff3fc000: 0, mmc at 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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190612/7fd25915/attachment.sig>

[U-Boot] Regression in U-boot v2019-07-rcX

[Andy Shevchenko]

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.


-- 
With Best Regards,
Andy Shevchenko

[U-Boot] Regression in U-boot v2019-07-rcX

[Andy Shevchenko]

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 at ff3fc000: 0, mmc at 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!

-- 
With Best Regards,
Andy Shevchenko

[U-Boot] Regression in U-boot v2019-07-rcX

[Bin Meng]

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 at ff3fc000: 0, mmc at 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!

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

[U-Boot] Regression in U-boot v2019-07-rcX

[Andy Shevchenko]

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

-- 
With Best Regards,
Andy Shevchenko

[U-Boot] Regression in U-boot v2019-07-rcX

[Simon Glass]

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