[U-Boot] [ANN] U-Boot v2020.01-rc4 released
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,
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
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).
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
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_vboot922+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!
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
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.
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.
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
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).
participants (4)
-
Joe Hershberger -
Marek Vasut -
Simon Glass -
Tom Rini