* [U-Boot] [ANN] U-Boot v2020.01-rc4 released
@ 2019-12-03 3:10 Tom Rini
[not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com>
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Tom Rini @ 2019-12-03 3:10 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com>]
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released [not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com> @ 2019-12-03 11:55 ` Eugen.Hristev at microchip.com 2019-12-03 14:30 ` Tom Rini 1 sibling, 0 replies; 12+ messages in thread From: Eugen.Hristev at microchip.com @ 2019-12-03 11:55 UTC (permalink / raw) To: u-boot 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 >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released [not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com> 2019-12-03 11:55 ` [U-Boot-Custodians] " Eugen.Hristev at microchip.com @ 2019-12-03 14:30 ` Tom Rini 1 sibling, 0 replies; 12+ messages in thread From: Tom Rini @ 2019-12-03 14:30 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 3:10 [U-Boot] [ANN] U-Boot v2020.01-rc4 released Tom Rini [not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com> @ 2019-12-03 16:45 ` Joe Hershberger 2019-12-03 17:05 ` Tom Rini 2019-12-03 16:52 ` Simon Glass 2 siblings, 1 reply; 12+ messages in thread From: Joe Hershberger @ 2019-12-03 16:45 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 16:45 ` Joe Hershberger @ 2019-12-03 17:05 ` Tom Rini 2019-12-03 20:56 ` Joe Hershberger 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2019-12-03 17:05 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 17:05 ` Tom Rini @ 2019-12-03 20:56 ` Joe Hershberger 2019-12-03 21:03 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Joe Hershberger @ 2019-12-03 20:56 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 20:56 ` Joe Hershberger @ 2019-12-03 21:03 ` Tom Rini 0 siblings, 0 replies; 12+ messages in thread From: Tom Rini @ 2019-12-03 21:03 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 3:10 [U-Boot] [ANN] U-Boot v2020.01-rc4 released Tom Rini [not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com> 2019-12-03 16:45 ` Joe Hershberger @ 2019-12-03 16:52 ` Simon Glass 2019-12-03 17:00 ` Marek Vasut 2 siblings, 1 reply; 12+ messages in thread From: Simon Glass @ 2019-12-03 16:52 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 16:52 ` Simon Glass @ 2019-12-03 17:00 ` Marek Vasut 2019-12-03 17:07 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Marek Vasut @ 2019-12-03 17:00 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 17:00 ` Marek Vasut @ 2019-12-03 17:07 ` Tom Rini 2019-12-03 17:20 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2019-12-03 17:07 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 17:07 ` Tom Rini @ 2019-12-03 17:20 ` Simon Glass 2019-12-03 17:41 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Simon Glass @ 2019-12-03 17:20 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released 2019-12-03 17:20 ` Simon Glass @ 2019-12-03 17:41 ` Tom Rini 0 siblings, 0 replies; 12+ messages in thread From: Tom Rini @ 2019-12-03 17:41 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-12-03 21:03 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-03 3:10 [U-Boot] [ANN] U-Boot v2020.01-rc4 released Tom Rini
[not found] ` <73b453a4-ed9c-3177-6623-0ce716cc31a8@microchip.com>
2019-12-03 11:55 ` [U-Boot-Custodians] " Eugen.Hristev at microchip.com
2019-12-03 14:30 ` Tom Rini
2019-12-03 16:45 ` Joe Hershberger
2019-12-03 17:05 ` Tom Rini
2019-12-03 20:56 ` Joe Hershberger
2019-12-03 21:03 ` Tom Rini
2019-12-03 16:52 ` Simon Glass
2019-12-03 17:00 ` Marek Vasut
2019-12-03 17:07 ` Tom Rini
2019-12-03 17:20 ` Simon Glass
2019-12-03 17:41 ` Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.