[U-Boot] [ANN] U-Boot v2020.01-rc4 released

[U-Boot] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

Hey all,

It's release day and here is v2020.01-rc4.  Yes, I'm still working on
fixing all of the issues that pop up as I get the MTD clean-up series
ready to go.  In fact, what I need to do at this point is grab the
handful of size reduction patches that this has shown are worthwhile,
then I can do the MTD series.  Then we're down to just fixing up
misconversions where things got turned off.

Once again, for a changelog, 
git log --merges v2020.01-rc3..v2020.01-rc4
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

I'm planning on doing -rc5 on December 23rd with the release scheduled
on January 6th.  Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191202/e1321951/attachment.sig>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Eugen.Hristev at microchip.com]

Resending because of mailing list server issues.

On 03.12.2019 13:30, Eugen Hristev wrote:
> 
> 
> On 03.12.2019 05:10, Tom Rini wrote:
> 
>> Hey all,
>>
>> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
>> fixing all of the issues that pop up as I get the MTD clean-up series
>> ready to go.  In fact, what I need to do at this point is grab the
>> handful of size reduction patches that this has shown are worthwhile,
>> then I can do the MTD series.  Then we're down to just fixing up
>> misconversions where things got turned off.
>>
>> Once again, for a changelog,
>> git log --merges v2020.01-rc3..v2020.01-rc4
>> and as always, I ask for more details in the PRs people send me so I can
>> put them in the merge commit.
>>
>> I'm planning on doing -rc5 on December 23rd with the release scheduled
>> on January 6th.  Thanks all!
> 
> Hi Tom,
> 
> Isn't Jan 6th a bit tight considering the new year vacations ?
> Not like I would expect last minute bugs, but, just to make sure.
> 
> Eugen
> 
>>
>> -- 
>> Tom
>>
>>
>> _______________________________________________
>> U-Boot-Custodians mailing list
>> U-Boot-Custodians at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot-custodians
>>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

On Tue, Dec 03, 2019 at 11:30:28AM +0000, Eugen.Hristev at microchip.com wrote:
> 
> 
> On 03.12.2019 05:10, Tom Rini wrote:
> 
> > Hey all,
> > 
> > It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > fixing all of the issues that pop up as I get the MTD clean-up series
> > ready to go.  In fact, what I need to do at this point is grab the
> > handful of size reduction patches that this has shown are worthwhile,
> > then I can do the MTD series.  Then we're down to just fixing up
> > misconversions where things got turned off.
> > 
> > Once again, for a changelog,
> > git log --merges v2020.01-rc3..v2020.01-rc4
> > and as always, I ask for more details in the PRs people send me so I can
> > put them in the merge commit.
> > 
> > I'm planning on doing -rc5 on December 23rd with the release scheduled
> > on January 6th.  Thanks all!
> 
> Hi Tom,
> 
> Isn't Jan 6th a bit tight considering the new year vacations ?
> Not like I would expect last minute bugs, but, just to make sure.

I expect things to get very quiet after this week, so I think things
will be safe.  I'm grabbing some assorted fixes now, and then the MTD
cleanups, and then that's about it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/4dda45d8/attachment.sig>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Joe Hershberger]

Hi Tom,

On Mon, Dec 2, 2019 at 9:11 PM Tom Rini <trini@konsulko.com> wrote:
>
> Hey all,
>
> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> fixing all of the issues that pop up as I get the MTD clean-up series
> ready to go.  In fact, what I need to do at this point is grab the
> handful of size reduction patches that this has shown are worthwhile,
> then I can do the MTD series.  Then we're down to just fixing up
> misconversions where things got turned off.
>
> Once again, for a changelog,
> git log --merges v2020.01-rc3..v2020.01-rc4
> and as always, I ask for more details in the PRs people send me so I can
> put them in the merge commit.
>
> I'm planning on doing -rc5 on December 23rd with the release scheduled
> on January 6th.  Thanks all!

I have a -net PR just about ready, but there are a few boards failing
for size. When can I expect the size reduction to drop?

Thanks,
-Joe

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Simon Glass]

Hi Tom,

On Mon, 2 Dec 2019 at 20:11, Tom Rini <trini@konsulko.com> wrote:
>
> Hey all,
>
> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> fixing all of the issues that pop up as I get the MTD clean-up series
> ready to go.  In fact, what I need to do at this point is grab the
> handful of size reduction patches that this has shown are worthwhile,
> then I can do the MTD series.  Then we're down to just fixing up
> misconversions where things got turned off.
>
> Once again, for a changelog,
> git log --merges v2020.01-rc3..v2020.01-rc4
> and as always, I ask for more details in the PRs people send me so I can
> put them in the merge commit.
>
> I'm planning on doing -rc5 on December 23rd with the release scheduled
> on January 6th.  Thanks all!

Speaking of next year, what is the plan for the release. Is there any
chance we might move back to a release every two months? The
three-month process is very slow...

Regards,
Simon

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Marek Vasut]

On 12/3/19 5:52 PM, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 2 Dec 2019 at 20:11, Tom Rini <trini@konsulko.com> wrote:
>>
>> Hey all,
>>
>> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
>> fixing all of the issues that pop up as I get the MTD clean-up series
>> ready to go.  In fact, what I need to do at this point is grab the
>> handful of size reduction patches that this has shown are worthwhile,
>> then I can do the MTD series.  Then we're down to just fixing up
>> misconversions where things got turned off.
>>
>> Once again, for a changelog,
>> git log --merges v2020.01-rc3..v2020.01-rc4
>> and as always, I ask for more details in the PRs people send me so I can
>> put them in the merge commit.
>>
>> I'm planning on doing -rc5 on December 23rd with the release scheduled
>> on January 6th.  Thanks all!
> 
> Speaking of next year, what is the plan for the release. Is there any
> chance we might move back to a release every two months? The
> three-month process is very slow...

I am very happy with this 3-month release cycle, it's less stressful and
I think the quality of the releases is higher too.

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> On Mon, Dec 2, 2019 at 9:11 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > Hey all,
> >
> > It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > fixing all of the issues that pop up as I get the MTD clean-up series
> > ready to go.  In fact, what I need to do at this point is grab the
> > handful of size reduction patches that this has shown are worthwhile,
> > then I can do the MTD series.  Then we're down to just fixing up
> > misconversions where things got turned off.
> >
> > Once again, for a changelog,
> > git log --merges v2020.01-rc3..v2020.01-rc4
> > and as always, I ask for more details in the PRs people send me so I can
> > put them in the merge commit.
> >
> > I'm planning on doing -rc5 on December 23rd with the release scheduled
> > on January 6th.  Thanks all!
> 
> I have a -net PR just about ready, but there are a few boards failing
> for size. When can I expect the size reduction to drop?

How much are they failing?  You can rebase on top of
WIP/2019-12-03-master-imports and see if that's enough.  But also if
it's for packed member things, I'm not sure if that's the right approach
vs disabling the warning like the Linux kernel does (and we do today,
for clang).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/59ec76a5/attachment.sig>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote:
> On 12/3/19 5:52 PM, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Mon, 2 Dec 2019 at 20:11, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> Hey all,
> >>
> >> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> >> fixing all of the issues that pop up as I get the MTD clean-up series
> >> ready to go.  In fact, what I need to do at this point is grab the
> >> handful of size reduction patches that this has shown are worthwhile,
> >> then I can do the MTD series.  Then we're down to just fixing up
> >> misconversions where things got turned off.
> >>
> >> Once again, for a changelog,
> >> git log --merges v2020.01-rc3..v2020.01-rc4
> >> and as always, I ask for more details in the PRs people send me so I can
> >> put them in the merge commit.
> >>
> >> I'm planning on doing -rc5 on December 23rd with the release scheduled
> >> on January 6th.  Thanks all!
> > 
> > Speaking of next year, what is the plan for the release. Is there any
> > chance we might move back to a release every two months? The
> > three-month process is very slow...
> 
> I am very happy with this 3-month release cycle, it's less stressful and
> I think the quality of the releases is higher too.

I thought I said this a release or so ago, sorry.  I believe we'll be
sticking with the 3-month cycle and I hope to find time to more actively
use a -next branch myself to help with some of the delay, or at least
slower feedback cycle.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/23f6c1bd/attachment.sig>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Simon Glass]

Hi Tom,

On Tue, 3 Dec 2019 at 10:07, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote:
> > On 12/3/19 5:52 PM, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 2 Dec 2019 at 20:11, Tom Rini <trini@konsulko.com> wrote:
> > >>
> > >> Hey all,
> > >>
> > >> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > >> fixing all of the issues that pop up as I get the MTD clean-up series
> > >> ready to go.  In fact, what I need to do at this point is grab the
> > >> handful of size reduction patches that this has shown are worthwhile,
> > >> then I can do the MTD series.  Then we're down to just fixing up
> > >> misconversions where things got turned off.
> > >>
> > >> Once again, for a changelog,
> > >> git log --merges v2020.01-rc3..v2020.01-rc4
> > >> and as always, I ask for more details in the PRs people send me so I can
> > >> put them in the merge commit.
> > >>
> > >> I'm planning on doing -rc5 on December 23rd with the release scheduled
> > >> on January 6th.  Thanks all!
> > >
> > > Speaking of next year, what is the plan for the release. Is there any
> > > chance we might move back to a release every two months? The
> > > three-month process is very slow...
> >
> > I am very happy with this 3-month release cycle, it's less stressful and
> > I think the quality of the releases is higher too.
>
> I thought I said this a release or so ago, sorry.  I believe we'll be
> sticking with the 3-month cycle and I hope to find time to more actively
> use a -next branch myself to help with some of the delay, or at least
> slower feedback cycle.

That would certainly help, but it hasn't proved possible so far. Let's
see how it goes with the next release.

Do you think if we can improve the testing (e.g. with more mini-labs
attached to gitlab) we might resolve these stability problems?

Regards,
Simon

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

On Tue, Dec 03, 2019 at 10:20:51AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 3 Dec 2019 at 10:07, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote:
> > > On 12/3/19 5:52 PM, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 2 Dec 2019 at 20:11, Tom Rini <trini@konsulko.com> wrote:
> > > >>
> > > >> Hey all,
> > > >>
> > > >> It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > > >> fixing all of the issues that pop up as I get the MTD clean-up series
> > > >> ready to go.  In fact, what I need to do at this point is grab the
> > > >> handful of size reduction patches that this has shown are worthwhile,
> > > >> then I can do the MTD series.  Then we're down to just fixing up
> > > >> misconversions where things got turned off.
> > > >>
> > > >> Once again, for a changelog,
> > > >> git log --merges v2020.01-rc3..v2020.01-rc4
> > > >> and as always, I ask for more details in the PRs people send me so I can
> > > >> put them in the merge commit.
> > > >>
> > > >> I'm planning on doing -rc5 on December 23rd with the release scheduled
> > > >> on January 6th.  Thanks all!
> > > >
> > > > Speaking of next year, what is the plan for the release. Is there any
> > > > chance we might move back to a release every two months? The
> > > > three-month process is very slow...
> > >
> > > I am very happy with this 3-month release cycle, it's less stressful and
> > > I think the quality of the releases is higher too.
> >
> > I thought I said this a release or so ago, sorry.  I believe we'll be
> > sticking with the 3-month cycle and I hope to find time to more actively
> > use a -next branch myself to help with some of the delay, or at least
> > slower feedback cycle.
> 
> That would certainly help, but it hasn't proved possible so far. Let's
> see how it goes with the next release.

Well, it's also about custodian stress and time levels.  The longer
cycle seems to be better for that.

> Do you think if we can improve the testing (e.g. with more mini-labs
> attached to gitlab) we might resolve these stability problems?

Ah right, I needed to reply to that thread, sorry.  I get the feeling
that the answer overall is that folks that have spent time with LAVA
need to chime in, or barring that, I need to play with LAVA as that's
how a lot of the "how do you reserve boards" and so forth problems are
handled, and would also make an easier case for vendors to get more
U-Boot testing done (as that gets you to kernelci too, or if you already
have kernelci going, you can add U-Boot with just a few more steps).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/95f9f4ff/attachment.sig>

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Joe Hershberger]

Hey Tom,

On Tue, Dec 3, 2019 at 11:05 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote:
> > Hi Tom,
> >
> > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > Hey all,
> > >
> > > It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > > fixing all of the issues that pop up as I get the MTD clean-up series
> > > ready to go.  In fact, what I need to do at this point is grab the
> > > handful of size reduction patches that this has shown are worthwhile,
> > > then I can do the MTD series.  Then we're down to just fixing up
> > > misconversions where things got turned off.
> > >
> > > Once again, for a changelog,
> > > git log --merges v2020.01-rc3..v2020.01-rc4
> > > and as always, I ask for more details in the PRs people send me so I can
> > > put them in the merge commit.
> > >
> > > I'm planning on doing -rc5 on December 23rd with the release scheduled
> > > on January 6th.  Thanks all!
> >
> > I have a -net PR just about ready, but there are a few boards failing
> > for size. When can I expect the size reduction to drop?
>
> How much are they failing?  You can rebase on top of
> WIP/2019-12-03-master-imports and see if that's enough.  But also if

arm: + tbs2910
+u-boot.imx exceeds file size limit:
1356+  limit:  0x5fc00 bytes
1357+  actual: 0x60c00 bytes
1358+  excess: 0x1000 bytes

       arm:  +   am335x_boneblack_vboot
922+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will
not fit in region `.sram'
923+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 392 bytes
924+make[2]: *** [spl/u-boot-spl] Error 1
925+make[1]: *** [spl/u-boot-spl] Error 2
926+make: *** [sub-make] Error 2
927       arm:  +   am335x_evm
928+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will
not fit in region `.sram'
929+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 664 bytes
930+make[2]: *** [spl/u-boot-spl] Error 1
931+make[1]: *** [spl/u-boot-spl] Error 2
932+make: *** [sub-make] Error 2


> it's for packed member things, I'm not sure if that's the right approach
> vs disabling the warning like the Linux kernel does (and we do today,
> for clang).
>
> --
> Tom

[U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

On Tue, Dec 03, 2019 at 02:56:38PM -0600, Joe Hershberger wrote:
> Hey Tom,
> 
> On Tue, Dec 3, 2019 at 11:05 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote:
> > > Hi Tom,
> > >
> > > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > Hey all,
> > > >
> > > > It's release day and here is v2020.01-rc4.  Yes, I'm still working on
> > > > fixing all of the issues that pop up as I get the MTD clean-up series
> > > > ready to go.  In fact, what I need to do at this point is grab the
> > > > handful of size reduction patches that this has shown are worthwhile,
> > > > then I can do the MTD series.  Then we're down to just fixing up
> > > > misconversions where things got turned off.
> > > >
> > > > Once again, for a changelog,
> > > > git log --merges v2020.01-rc3..v2020.01-rc4
> > > > and as always, I ask for more details in the PRs people send me so I can
> > > > put them in the merge commit.
> > > >
> > > > I'm planning on doing -rc5 on December 23rd with the release scheduled
> > > > on January 6th.  Thanks all!
> > >
> > > I have a -net PR just about ready, but there are a few boards failing
> > > for size. When can I expect the size reduction to drop?
> >
> > How much are they failing?  You can rebase on top of
> > WIP/2019-12-03-master-imports and see if that's enough.  But also if
> 
> arm: + tbs2910
> +u-boot.imx exceeds file size limit:
> 1356+  limit:  0x5fc00 bytes
> 1357+  actual: 0x60c00 bytes
> 1358+  excess: 0x1000 bytes

Might be fine now, we're clearing out a few bytes.

>        arm:  +   am335x_boneblack_vboot
> 922+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will
> not fit in region `.sram'
> 923+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 392 bytes
> 924+make[2]: *** [spl/u-boot-spl] Error 1
> 925+make[1]: *** [spl/u-boot-spl] Error 2
> 926+make: *** [sub-make] Error 2
> 927       arm:  +   am335x_evm
> 928+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will
> not fit in region `.sram'
> 929+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 664 bytes
> 930+make[2]: *** [spl/u-boot-spl] Error 1
> 931+make[1]: *** [spl/u-boot-spl] Error 2
> 932+make: *** [sub-make] Error 2

SPL is unchanged in all cases.  What's causing this growth anyhow?
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/265be8f1/attachment.sig>