Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Mon, Oct 14, 2019 at 01:04:00PM +0200, Daniel Schwierzeck wrote: > Hi Tom, > > On Tue, Oct 8, 2019 at 2:53 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > > Hey all, > > > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > > regression fixes, I feel things are as stable as they are likely > > > > > > > to get > > > > > > > so I've tagged and released v2019.07 and I would like to thank > > > > > > > all of > > > > > > > our contributor for their efforts. > > > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > > > To repeat something I posted about in the previous -rc release, > > > > > > > I've > > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > > page > > > > > > > that the "next" branch is expected to be rebased. Why? While > > > > > > > I'm not > > > > > > > sure if I want to apply things directly to the next branch and > > > > > > > then give > > > > > > > them some sort of automated testing, I do want to try and give > > > > > > > changes > > > > > > > some sort of build testing and similar sooner than I have, and > > > > > > > that was > > > > > > > at least a related problem. > > > > > > > > > > > > > > In terms of a changelog, > > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > > or > > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > > > For this next release, one big concern I have but that I am > > > > > > > hopeful we > > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > > support. > > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > > been a > > > > > > > number of patches posted that get us a good part of the way there > > > > > > > and I > > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > > October > > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > > 2020. > > > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > > sheevaplug board. > > > > > > > > > > > > 01: Prepare v2019.10 > > > > > >arm: + sheevaplug > > > > > > +u-boot.kwb exceeds file size limit: > > > > > > + limit: 524288 bytes > > > > > > + actual: 524632 bytes > > > > > > + excess: 344 bytes > > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > > days, but I thought that was due to patches in my queue. However I > > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > > elsewhere that this happens, and also that the EFI PR will address > > > > > this, > > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > > that was due to I dropped some SPL patches that were previously in the > > > > queue. > > > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > > address. Thanks! > > > > > > I see a few full path to source files in the resulting binary: > > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > > support it (and these come from BUG/BUG_ON) and I still don't know of > > anyplace that provides a full set of new enough toolchains for use on > > all of the architectures we care about. > > this could also be fixed by replacing all usages of __FILE__ with > KBUILD_BASENAME which would work with all toolchain versions ;) Yes, but I also loathe getting these files further out of sync with Linux. There's already a pre
Re: [U-Boot] [ANN] U-Boot v2019.10 released
Hi Tom, On Tue, Oct 8, 2019 at 2:53 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > Hey all, > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > regression fixes, I feel things are as stable as they are likely to > > > > > > get > > > > > > so I've tagged and released v2019.07 and I would like to thank all > > > > > > of > > > > > > our contributor for their efforts. > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > page > > > > > > that the "next" branch is expected to be rebased. Why? While I'm > > > > > > not > > > > > > sure if I want to apply things directly to the next branch and then > > > > > > give > > > > > > them some sort of automated testing, I do want to try and give > > > > > > changes > > > > > > some sort of build testing and similar sooner than I have, and that > > > > > > was > > > > > > at least a related problem. > > > > > > > > > > > > In terms of a changelog, > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > or > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > For this next release, one big concern I have but that I am hopeful > > > > > > we > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > support. > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > been a > > > > > > number of patches posted that get us a good part of the way there > > > > > > and I > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > October > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > 2020. > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > sheevaplug board. > > > > > > > > > > 01: Prepare v2019.10 > > > > >arm: + sheevaplug > > > > > +u-boot.kwb exceeds file size limit: > > > > > + limit: 524288 bytes > > > > > + actual: 524632 bytes > > > > > + excess: 344 bytes > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > days, but I thought that was due to patches in my queue. However I > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > elsewhere that this happens, and also that the EFI PR will address this, > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > that was due to I dropped some SPL patches that were previously in the > > > queue. > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > address. Thanks! > > > > I see a few full path to source files in the resulting binary: > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > support it (and these come from BUG/BUG_ON) and I still don't know of > anyplace that provides a full set of new enough toolchains for use on > all of the architectures we care about. > this could also be fixed by replacing all usages of __FILE__ with KBUILD_BASENAME which would work with all toolchain versions ;) -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
Dear Tom, In message <20191007211543.GQ6716@bill-the-cat> you wrote: > > It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. Thanks. The release statistics is available as usual at [1]. [1] https://www.denx.de/wiki/U-Boot/UbootStat_2019_10 Here is the short summary: Changes since v2019.07: * Processed 2007 csets from 190 developers * 31 employers found * A total of 111008 lines added, 38325 removed (delta 72683) Developers with the most changesets Simon Glass252 (12.6%) Kever Yang 142 (7.1%) Heinrich Schuchardt115 (5.7%) Patrick Delaunay 112 (5.6%) Jagan Teki 89 (4.4%) Bin Meng70 (3.5%) Hou Zhiqiang66 (3.3%) Adam Ford 55 (2.7%) Lukasz Majewski 46 (2.3%) Peng Fan45 (2.2%) ... Developers with the most changed lines Simon Glass 15674 (12.4%) Jagan Teki7394 (5.8%) Kever Yang7177 (5.7%) Marek Vasut 6504 (5.1%) Bin Meng 5608 (4.4%) Heinrich Schuchardt 5109 (4.0%) Lukasz Majewski 4813 (3.8%) Patrick Delaunay 3764 (3.0%) Manivannan Sadhasivam 3703 (2.9%) Neil Armstrong3599 (2.8%) ... Developers with the most lines removed Uwe Kleine-König 2338 (6.1%) Heinrich Schuchardt 1027 (2.7%) Horatiu Vultur 455 (1.2%) Holger Brunck 431 (1.1%) Tom Rini 418 (1.1%) Patrice Chotard211 (0.6%) Bartosz Golaszewski193 (0.5%) Ilko Iliev 192 (0.5%) Bernhard Messerklinger 77 (0.2%) Ryan Harkin 67 (0.2%) ... Developers with the most signoffs (total 335) YouMin Chen 55 (16.4%) Stefan Roese36 (10.7%) Patrice Chotard 23 (6.9%) Michal Simek20 (6.0%) Tom Warren 16 (4.8%) Tom Rini14 (4.2%) Holger Brunck 13 (3.9%) Igor Opaniuk12 (3.6%) Matthias Brugger10 (3.0%) Bin Meng 8 (2.4%) ... Developers with the most reviews (total 897) Bin Meng 185 (20.6%) Kever Yang 119 (13.3%) Prabhakar Kushwaha 108 (12.0%) Simon Glass 53 (5.9%) Peng Fan40 (4.5%) Jagan Teki 35 (3.9%) Lokesh Vutla32 (3.6%) Oleksandr Suvorov 31 (3.5%) Stefan Roese26 (2.9%) Anup Patel 21 (2.3%) ... Developers with the most test credits (total 121) Bin Meng43 (35.5%) Anup Patel 7 (5.8%) Heiko Schocher 6 (5.0%) Jernej Skrabec 5 (4.1%) Corentin Labbe 5 (4.1%) Steffen Dirkwinkel 5 (4.1%) Adam Ford5 (4.1%) Mark Kettenis4 (3.3%) Heinrich Schuchardt 3 (2.5%) Joris Offouga3 (2.5%) ... Developers who gave the most tested-by credits (total 121) Park, Aiden 12 (9.9%) Lukas Auer 11 (9.1%) Andre Przywara 10 (8.3%) Simon Glass 8 (6.6%) Ramon Fried 7 (5.8%) Pierre-Jean Texier 6 (5.0%) Yangbo Lu5 (4.1%) Anup Patel 4 (3.3%) Marek Vasut 4 (3.3%) Neil Armstrong 4 (3.3%) ... Developers with the most report credits (total 28) Fermín Serna5 (17.9%) Ramon Fried 4 (14.3%) Simon Glass 2 (7.1%) Heinrich Schuchardt 2 (7.1%) Jagan Teki 2 (7.1%) Sam Protsenko2 (7.1%) Fabio Estevam2 (7.1%) Marek Vasut 1 (3.6%) Kever Yang 1 (3.6%) Michal Simek 1 (3.6%) ... Developers who gave the most report credits (total 28) Heinrich Schuchardt 7 (25.0%) liucheng (G) 5 (17.9%) Jagan Teki 3 (10.7%) Eugeniu Rosca3 (10.7%) Anatolij Gustschin 2 (7.1%) Bin Meng 2 (7.1%) Tom Rini 1 (3.6%) Simon Goldschmidt1 (3.6%) Suniel Mahesh1 (3.6%) Thierry Reding 1 (3.6%) ... Top changeset contributors by employer (Unknown) 617 (30.7%) Google, Inc. 253 (12.6%) NXP216 (10.8%) Rockchip 144 (7.2%) ST Microelectronics140 (7.0%) Texas Instruments 133 (6.6%) DENX Software Engineering 98 (4.9%) Amarula Solutions 96 (4.8%) Linaro 53 (2.6%) BayLibre SAS37 (1.8%) ... Top lines changed by employer (Unknown)
Re: [U-Boot] [ANN] U-Boot v2019.10 released
Hello Michal, Am 08.10.2019 um 14:38 schrieb Michal Simek: On 08. 10. 19 14:35, Tom Rini wrote: On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: On 07. 10. 19 23:15, Tom Rini wrote: Hey all, It's release day and while we've once again had some last minute regression fixes, I feel things are as stable as they are likely to get so I've tagged and released v2019.07 and I would like to thank all of our contributor for their efforts. I expect v2019.10 :-) Oops. I did get the tag right this time at least. To repeat something I posted about in the previous -rc release, I've clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page that the "next" branch is expected to be rebased. Why? While I'm not sure if I want to apply things directly to the next branch and then give them some sort of automated testing, I do want to try and give changes some sort of build testing and similar sooner than I have, and that was at least a related problem. In terms of a changelog, git log --merges v2019.10-rc4..v2019.10 or git log --merges v2019.07..v2019.10 For this next release, one big concern I have but that I am hopeful we will be able to overcome is that we need to remove Python 2.7 support. Python 2.7 itself is end of lifed on January 1st, 2020. There's been a number of patches posted that get us a good part of the way there and I believe we can get the rest done before the deadline. The merge window is once again open and I plan to tag -rc1 on October 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. I am preparing pull request and I see that release has issue with sheevaplug board. 01: Prepare v2019.10 arm: + sheevaplug +u-boot.kwb exceeds file size limit: + limit: 524288 bytes + actual: 524632 bytes + excess: 344 bytes +make[1]: *** [u-boot.kwb] Error 1 +make[1]: *** Deleting file 'u-boot.kwb' +make: *** [sub-make] Error 2 There are also warnings about conversions to DM. Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me there's some /full/path string(s) somewhere that we should find and address. Thanks! It was catched by Travis on my branch. https://travis-ci.org/michalsimek/u-boot/jobs/594990410 But I was retesting it on my PC on tag too(log above). Sorry missed this thread yesterday ... Yes I detected this issue also here, as I wanted to send a pull request for ubi: https://lists.denx.de/pipermail/u-boot/2019-October/385848.html I asked Prafulla (listed as Board Maintainer) if there are plans to convert this board to DM or if it can be removed. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 04:36:08PM +0100, Peter Robinson wrote: > > It's release day and while we've once again had some last minute > > regression fixes, I feel things are as stable as they are likely to get > > so I've tagged and released v2019.07 and I would like to thank all of > > our contributor for their efforts. > > > > To repeat something I posted about in the previous -rc release, I've > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > that the "next" branch is expected to be rebased. Why? While I'm not > > sure if I want to apply things directly to the next branch and then give > > them some sort of automated testing, I do want to try and give changes > > some sort of build testing and similar sooner than I have, and that was > > at least a related problem. > > > > In terms of a changelog, > > git log --merges v2019.10-rc4..v2019.10 > > or > > git log --merges v2019.07..v2019.10 > > > > For this next release, one big concern I have but that I am hopeful we > > will be able to overcome is that we need to remove Python 2.7 support. > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > number of patches posted that get us a good part of the way there and I > > believe we can get the rest done before the deadline. > > I think the big missing piece was to rebase libfdt to the upstream > 1.5.x series that now supports python3, the issue there from memory > was that it bloats some things, Simon was investigating and going to > post a patch set for upstream dtc/libfdt to resolve some of the issues > but I'm not sure if he'd reported back on the latest status of that > work. The libfdt part, by itself, turns out to be easy (just the normal convert to python3 setup.py or whatever). But binman/buildman/test.py all need updating and are real work. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
> It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. > > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > that the "next" branch is expected to be rebased. Why? While I'm not > sure if I want to apply things directly to the next branch and then give > them some sort of automated testing, I do want to try and give changes > some sort of build testing and similar sooner than I have, and that was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful we > will be able to overcome is that we need to remove Python 2.7 support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > number of patches posted that get us a good part of the way there and I > believe we can get the rest done before the deadline. I think the big missing piece was to rebase libfdt to the upstream 1.5.x series that now supports python3, the issue there from memory was that it bloats some things, Simon was investigating and going to post a patch set for upstream dtc/libfdt to resolve some of the issues but I'm not sure if he'd reported back on the latest status of that work. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 04:17:08PM +0200, Michal Simek wrote: > On 08. 10. 19 16:02, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: > >> On 08. 10. 19 15:25, Tom Rini wrote: > >>> On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > >> On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > >>> On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > On 07. 10. 19 23:15, Tom Rini wrote: > >> Hey all, > >> > >> It's release day and while we've once again had some last minute > >> regression fixes, I feel things are as stable as they are likely > >> to get > >> so I've tagged and released v2019.07 and I would like to thank all > >> of > >> our contributor for their efforts. > > > > I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > > >> To repeat something I posted about in the previous -rc release, > >> I've > >> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > >> page > >> that the "next" branch is expected to be rebased. Why? While I'm > >> not > >> sure if I want to apply things directly to the next branch and > >> then give > >> them some sort of automated testing, I do want to try and give > >> changes > >> some sort of build testing and similar sooner than I have, and > >> that was > >> at least a related problem. > >> > >> In terms of a changelog, > >> git log --merges v2019.10-rc4..v2019.10 > >> or > >> git log --merges v2019.07..v2019.10 > >> > >> For this next release, one big concern I have but that I am > >> hopeful we > >> will be able to overcome is that we need to remove Python 2.7 > >> support. > >> Python 2.7 itself is end of lifed on January 1st, 2020. There's > >> been a > >> number of patches posted that get us a good part of the way there > >> and I > >> believe we can get the rest done before the deadline. > >> > >> The merge window is once again open and I plan to tag -rc1 on > >> October > >> 28th, bi-weekly -rcs thereafter and final release on January 6th, > >> 2020. > > > > I am preparing pull request and I see that release has issue with > > sheevaplug board. > > > > 01: Prepare v2019.10 > >arm: + sheevaplug > > +u-boot.kwb exceeds file size limit: > > + limit: 524288 bytes > > + actual: 524632 bytes > > + excess: 344 bytes > > +make[1]: *** [u-boot.kwb] Error 1 > > +make[1]: *** Deleting file 'u-boot.kwb' > > +make: *** [sub-make] Error 2 > > > >>> > >>> I saw this occasionally when I prepared the u-boot-x86 PR during past > >>> days, but I thought that was due to patches in my queue. However I > >>> remember I only saw excess 8 bytes or something, not 344 bytes ... > >>> > > There are also warnings about conversions to DM. > > > > Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address > this, > but my travis and gitlab pipelines passed. So that implies to me > >>> > >>> My latest run of gitlab-ci passed as well. Again I was not sure if > >>> that was due to I dropped some SPL patches that were previously in the > >>> queue. > >>> > there's some /full/path string(s) somewhere that we should find and > address. Thanks! > >> > >> I see a few full path to source files in the resulting binary: > >> $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > >> /home/trini/work/u-boot/u-boot/net/eth_legacy.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > > support it (and these come from BUG/BUG_ON) and I still don't know of > > anyplace that provides a full set of new enough toolchains for use on > > all of the arch
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 16:02, Tom Rini wrote: > On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: >> On 08. 10. 19 15:25, Tom Rini wrote: >>> On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: >> On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: >>> On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > On 07. 10. 19 23:15, Tom Rini wrote: >> Hey all, >> >> It's release day and while we've once again had some last minute >> regression fixes, I feel things are as stable as they are likely to >> get >> so I've tagged and released v2019.07 and I would like to thank all of >> our contributor for their efforts. > > I expect v2019.10 :-) Oops. I did get the tag right this time at least. >> To repeat something I posted about in the previous -rc release, I've >> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees >> page >> that the "next" branch is expected to be rebased. Why? While I'm >> not >> sure if I want to apply things directly to the next branch and then >> give >> them some sort of automated testing, I do want to try and give >> changes >> some sort of build testing and similar sooner than I have, and that >> was >> at least a related problem. >> >> In terms of a changelog, >> git log --merges v2019.10-rc4..v2019.10 >> or >> git log --merges v2019.07..v2019.10 >> >> For this next release, one big concern I have but that I am hopeful >> we >> will be able to overcome is that we need to remove Python 2.7 >> support. >> Python 2.7 itself is end of lifed on January 1st, 2020. There's >> been a >> number of patches posted that get us a good part of the way there >> and I >> believe we can get the rest done before the deadline. >> >> The merge window is once again open and I plan to tag -rc1 on October >> 28th, bi-weekly -rcs thereafter and final release on January 6th, >> 2020. > > I am preparing pull request and I see that release has issue with > sheevaplug board. > > 01: Prepare v2019.10 >arm: + sheevaplug > +u-boot.kwb exceeds file size limit: > + limit: 524288 bytes > + actual: 524632 bytes > + excess: 344 bytes > +make[1]: *** [u-boot.kwb] Error 1 > +make[1]: *** Deleting file 'u-boot.kwb' > +make: *** [sub-make] Error 2 > >>> >>> I saw this occasionally when I prepared the u-boot-x86 PR during past >>> days, but I thought that was due to patches in my queue. However I >>> remember I only saw excess 8 bytes or something, not 344 bytes ... >>> > There are also warnings about conversions to DM. > > Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me >>> >>> My latest run of gitlab-ci passed as well. Again I was not sure if >>> that was due to I dropped some SPL patches that were previously in the >>> queue. >>> there's some /full/path string(s) somewhere that we should find and address. Thanks! >> >> I see a few full path to source files in the resulting binary: >> $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c >> /home/trini/work/u-boot/u-boot/net/eth_legacy.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > support it (and these come from BUG/BUG_ON) and I still don't know of > anyplace that provides a full set of new enough toolchains for use on > all of the architectures we care about. For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? >>> >>> Note that for Sheevaplug it's the full U-Boot that's blowing up and not >>> SPL/TPL. >> >> Anyway back to the problem. If path matters for all these cases. >> Path depends on your gith
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: > On 08. 10. 19 15:25, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > >> On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > >>> > >>> On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > >> > >> On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > >>> On 07. 10. 19 23:15, Tom Rini wrote: > Hey all, > > It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to > get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. > >>> > >>> I expect v2019.10 :-) > >> > >> Oops. I did get the tag right this time at least. > >> > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > page > that the "next" branch is expected to be rebased. Why? While I'm > not > sure if I want to apply things directly to the next branch and then > give > them some sort of automated testing, I do want to try and give > changes > some sort of build testing and similar sooner than I have, and that > was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful > we > will be able to overcome is that we need to remove Python 2.7 > support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's > been a > number of patches posted that get us a good part of the way there > and I > believe we can get the rest done before the deadline. > > The merge window is once again open and I plan to tag -rc1 on October > 28th, bi-weekly -rcs thereafter and final release on January 6th, > 2020. > >>> > >>> I am preparing pull request and I see that release has issue with > >>> sheevaplug board. > >>> > >>> 01: Prepare v2019.10 > >>>arm: + sheevaplug > >>> +u-boot.kwb exceeds file size limit: > >>> + limit: 524288 bytes > >>> + actual: 524632 bytes > >>> + excess: 344 bytes > >>> +make[1]: *** [u-boot.kwb] Error 1 > >>> +make[1]: *** Deleting file 'u-boot.kwb' > >>> +make: *** [sub-make] Error 2 > >>> > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > days, but I thought that was due to patches in my queue. However I > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > >>> There are also warnings about conversions to DM. > >>> > >>> Is it OK to ignore these boards which should be likely removed? > >> > >> So, how / where are you making this fail? I know it's been noted > >> elsewhere that this happens, and also that the EFI PR will address > >> this, > >> but my travis and gitlab pipelines passed. So that implies to me > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > that was due to I dropped some SPL patches that were previously in the > > queue. > > > >> there's some /full/path string(s) somewhere that we should find and > >> address. Thanks! > > I see a few full path to source files in the resulting binary: > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > >>> > >>> And we have -fmacro-prefix-map patches but our default toolchain doesn't > >>> support it (and these come from BUG/BUG_ON) and I still don't know of > >>> anyplace that provides a full set of new enough toolchains for use on > >>> all of the architectures we care about. > >> > >> For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough > >> info? > > > > Note that for Sheevaplug it's the full U-Boot that's blowing up and not > > SPL/TPL. > > Anyway back to the problem. If path matters for all these cases. > Path depends on your github username because clone is done like th
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 15:25, Tom Rini wrote: > On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: >> On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: >>> >>> On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: >> >> On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: >>> On 07. 10. 19 23:15, Tom Rini wrote: Hey all, It's release day and while we've once again had some last minute regression fixes, I feel things are as stable as they are likely to get so I've tagged and released v2019.07 and I would like to thank all of our contributor for their efforts. >>> >>> I expect v2019.10 :-) >> >> Oops. I did get the tag right this time at least. >> To repeat something I posted about in the previous -rc release, I've clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page that the "next" branch is expected to be rebased. Why? While I'm not sure if I want to apply things directly to the next branch and then give them some sort of automated testing, I do want to try and give changes some sort of build testing and similar sooner than I have, and that was at least a related problem. In terms of a changelog, git log --merges v2019.10-rc4..v2019.10 or git log --merges v2019.07..v2019.10 For this next release, one big concern I have but that I am hopeful we will be able to overcome is that we need to remove Python 2.7 support. Python 2.7 itself is end of lifed on January 1st, 2020. There's been a number of patches posted that get us a good part of the way there and I believe we can get the rest done before the deadline. The merge window is once again open and I plan to tag -rc1 on October 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. >>> >>> I am preparing pull request and I see that release has issue with >>> sheevaplug board. >>> >>> 01: Prepare v2019.10 >>>arm: + sheevaplug >>> +u-boot.kwb exceeds file size limit: >>> + limit: 524288 bytes >>> + actual: 524632 bytes >>> + excess: 344 bytes >>> +make[1]: *** [u-boot.kwb] Error 1 >>> +make[1]: *** Deleting file 'u-boot.kwb' >>> +make: *** [sub-make] Error 2 >>> > > I saw this occasionally when I prepared the u-boot-x86 PR during past > days, but I thought that was due to patches in my queue. However I > remember I only saw excess 8 bytes or something, not 344 bytes ... > >>> There are also warnings about conversions to DM. >>> >>> Is it OK to ignore these boards which should be likely removed? >> >> So, how / where are you making this fail? I know it's been noted >> elsewhere that this happens, and also that the EFI PR will address this, >> but my travis and gitlab pipelines passed. So that implies to me > > My latest run of gitlab-ci passed as well. Again I was not sure if > that was due to I dropped some SPL patches that were previously in the > queue. > >> there's some /full/path string(s) somewhere that we should find and >> address. Thanks! I see a few full path to source files in the resulting binary: $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c /home/trini/work/u-boot/u-boot/net/eth_legacy.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c >>> >>> And we have -fmacro-prefix-map patches but our default toolchain doesn't >>> support it (and these come from BUG/BUG_ON) and I still don't know of >>> anyplace that provides a full set of new enough toolchains for use on >>> all of the architectures we care about. >> >> For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough >> info? > > Note that for Sheevaplug it's the full U-Boot that's blowing up and not > SPL/TPL. Anyway back to the problem. If path matters for all these cases. Path depends on your github username because clone is done like that. git clone --depth=50 --branch=mainline-v20191008 https://github.com/michalsimek/u-boot.git michalsimek/u-boot And buildman is running without -o property. Shouldn't we setup -o property that it will behave the same for everybody? -o /tmp/ ? Then all pathes should be the same for everybody without any dependency on github user name. Thanks, Michal -- Michal Simek, Ing. (M.Eng), Op
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > > Hey all, > > > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > > regression fixes, I feel things are as stable as they are likely > > > > > > > to get > > > > > > > so I've tagged and released v2019.07 and I would like to thank > > > > > > > all of > > > > > > > our contributor for their efforts. > > > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > > > To repeat something I posted about in the previous -rc release, > > > > > > > I've > > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > > page > > > > > > > that the "next" branch is expected to be rebased. Why? While > > > > > > > I'm not > > > > > > > sure if I want to apply things directly to the next branch and > > > > > > > then give > > > > > > > them some sort of automated testing, I do want to try and give > > > > > > > changes > > > > > > > some sort of build testing and similar sooner than I have, and > > > > > > > that was > > > > > > > at least a related problem. > > > > > > > > > > > > > > In terms of a changelog, > > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > > or > > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > > > For this next release, one big concern I have but that I am > > > > > > > hopeful we > > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > > support. > > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > > been a > > > > > > > number of patches posted that get us a good part of the way there > > > > > > > and I > > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > > October > > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > > 2020. > > > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > > sheevaplug board. > > > > > > > > > > > > 01: Prepare v2019.10 > > > > > >arm: + sheevaplug > > > > > > +u-boot.kwb exceeds file size limit: > > > > > > + limit: 524288 bytes > > > > > > + actual: 524632 bytes > > > > > > + excess: 344 bytes > > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > > days, but I thought that was due to patches in my queue. However I > > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > > elsewhere that this happens, and also that the EFI PR will address > > > > > this, > > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > > that was due to I dropped some SPL patches that were previously in the > > > > queue. > > > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > > address. Thanks! > > > > > > I see a few full path to source files in the resulting binary: > > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > > support it (and these come from BUG/BUG_ON) and I still don't know of > > anyplace that provides a full set of new enough toolchains for use on > > all of the architectures we care about. > > For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? Note that for Sheevaplug it's the full U-Boot that's blowing up and not SPL/TPL. -- Tom signature.asc Description: PGP signature ___
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > Hey all, > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > regression fixes, I feel things are as stable as they are likely to > > > > > > get > > > > > > so I've tagged and released v2019.07 and I would like to thank all > > > > > > of > > > > > > our contributor for their efforts. > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > page > > > > > > that the "next" branch is expected to be rebased. Why? While I'm > > > > > > not > > > > > > sure if I want to apply things directly to the next branch and then > > > > > > give > > > > > > them some sort of automated testing, I do want to try and give > > > > > > changes > > > > > > some sort of build testing and similar sooner than I have, and that > > > > > > was > > > > > > at least a related problem. > > > > > > > > > > > > In terms of a changelog, > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > or > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > For this next release, one big concern I have but that I am hopeful > > > > > > we > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > support. > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > been a > > > > > > number of patches posted that get us a good part of the way there > > > > > > and I > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > October > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > 2020. > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > sheevaplug board. > > > > > > > > > > 01: Prepare v2019.10 > > > > >arm: + sheevaplug > > > > > +u-boot.kwb exceeds file size limit: > > > > > + limit: 524288 bytes > > > > > + actual: 524632 bytes > > > > > + excess: 344 bytes > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > days, but I thought that was due to patches in my queue. However I > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > elsewhere that this happens, and also that the EFI PR will address this, > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > that was due to I dropped some SPL patches that were previously in the > > > queue. > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > address. Thanks! > > > > I see a few full path to source files in the resulting binary: > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > support it (and these come from BUG/BUG_ON) and I still don't know of > anyplace that provides a full set of new enough toolchains for use on > all of the architectures we care about. For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > Hey all, > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > regression fixes, I feel things are as stable as they are likely to > > > > > get > > > > > so I've tagged and released v2019.07 and I would like to thank all of > > > > > our contributor for their efforts. > > > > > > > > I expect v2019.10 :-) > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > > > sure if I want to apply things directly to the next branch and then > > > > > give > > > > > them some sort of automated testing, I do want to try and give changes > > > > > some sort of build testing and similar sooner than I have, and that > > > > > was > > > > > at least a related problem. > > > > > > > > > > In terms of a changelog, > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > or > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > For this next release, one big concern I have but that I am hopeful we > > > > > will be able to overcome is that we need to remove Python 2.7 support. > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been > > > > > a > > > > > number of patches posted that get us a good part of the way there and > > > > > I > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > 2020. > > > > > > > > I am preparing pull request and I see that release has issue with > > > > sheevaplug board. > > > > > > > > 01: Prepare v2019.10 > > > >arm: + sheevaplug > > > > +u-boot.kwb exceeds file size limit: > > > > + limit: 524288 bytes > > > > + actual: 524632 bytes > > > > + excess: 344 bytes > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > +make: *** [sub-make] Error 2 > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > days, but I thought that was due to patches in my queue. However I > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > There are also warnings about conversions to DM. > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > So, how / where are you making this fail? I know it's been noted > > > elsewhere that this happens, and also that the EFI PR will address this, > > > but my travis and gitlab pipelines passed. So that implies to me > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > that was due to I dropped some SPL patches that were previously in the > > queue. > > > > > there's some /full/path string(s) somewhere that we should find and > > > address. Thanks! > > I see a few full path to source files in the resulting binary: > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c And we have -fmacro-prefix-map patches but our default toolchain doesn't support it (and these come from BUG/BUG_ON) and I still don't know of anyplace that provides a full set of new enough toolchains for use on all of the architectures we care about. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > Hey all, > > > > > > > > It's release day and while we've once again had some last minute > > > > regression fixes, I feel things are as stable as they are likely to get > > > > so I've tagged and released v2019.07 and I would like to thank all of > > > > our contributor for their efforts. > > > > > > I expect v2019.10 :-) > > > > Oops. I did get the tag right this time at least. > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > > sure if I want to apply things directly to the next branch and then give > > > > them some sort of automated testing, I do want to try and give changes > > > > some sort of build testing and similar sooner than I have, and that was > > > > at least a related problem. > > > > > > > > In terms of a changelog, > > > > git log --merges v2019.10-rc4..v2019.10 > > > > or > > > > git log --merges v2019.07..v2019.10 > > > > > > > > For this next release, one big concern I have but that I am hopeful we > > > > will be able to overcome is that we need to remove Python 2.7 support. > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > > > number of patches posted that get us a good part of the way there and I > > > > believe we can get the rest done before the deadline. > > > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > > > > > I am preparing pull request and I see that release has issue with > > > sheevaplug board. > > > > > > 01: Prepare v2019.10 > > >arm: + sheevaplug > > > +u-boot.kwb exceeds file size limit: > > > + limit: 524288 bytes > > > + actual: 524632 bytes > > > + excess: 344 bytes > > > +make[1]: *** [u-boot.kwb] Error 1 > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > +make: *** [sub-make] Error 2 > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > days, but I thought that was due to patches in my queue. However I > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > There are also warnings about conversions to DM. > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > So, how / where are you making this fail? I know it's been noted > > elsewhere that this happens, and also that the EFI PR will address this, > > but my travis and gitlab pipelines passed. So that implies to me > > My latest run of gitlab-ci passed as well. Again I was not sure if > that was due to I dropped some SPL patches that were previously in the > queue. > > > there's some /full/path string(s) somewhere that we should find and > > address. Thanks! I see a few full path to source files in the resulting binary: $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c /home/trini/work/u-boot/u-boot/net/eth_legacy.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > On 07. 10. 19 23:15, Tom Rini wrote: > > > Hey all, > > > > > > It's release day and while we've once again had some last minute > > > regression fixes, I feel things are as stable as they are likely to get > > > so I've tagged and released v2019.07 and I would like to thank all of > > > our contributor for their efforts. > > > > I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > > > > To repeat something I posted about in the previous -rc release, I've > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > sure if I want to apply things directly to the next branch and then give > > > them some sort of automated testing, I do want to try and give changes > > > some sort of build testing and similar sooner than I have, and that was > > > at least a related problem. > > > > > > In terms of a changelog, > > > git log --merges v2019.10-rc4..v2019.10 > > > or > > > git log --merges v2019.07..v2019.10 > > > > > > For this next release, one big concern I have but that I am hopeful we > > > will be able to overcome is that we need to remove Python 2.7 support. > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > > number of patches posted that get us a good part of the way there and I > > > believe we can get the rest done before the deadline. > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > > > I am preparing pull request and I see that release has issue with > > sheevaplug board. > > > > 01: Prepare v2019.10 > >arm: + sheevaplug > > +u-boot.kwb exceeds file size limit: > > + limit: 524288 bytes > > + actual: 524632 bytes > > + excess: 344 bytes > > +make[1]: *** [u-boot.kwb] Error 1 > > +make[1]: *** Deleting file 'u-boot.kwb' > > +make: *** [sub-make] Error 2 > > I saw this occasionally when I prepared the u-boot-x86 PR during past days, but I thought that was due to patches in my queue. However I remember I only saw excess 8 bytes or something, not 344 bytes ... > > There are also warnings about conversions to DM. > > > > Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address this, > but my travis and gitlab pipelines passed. So that implies to me My latest run of gitlab-ci passed as well. Again I was not sure if that was due to I dropped some SPL patches that were previously in the queue. > there's some /full/path string(s) somewhere that we should find and > address. Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 14:35, Tom Rini wrote: > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: >> On 07. 10. 19 23:15, Tom Rini wrote: >>> Hey all, >>> >>> It's release day and while we've once again had some last minute >>> regression fixes, I feel things are as stable as they are likely to get >>> so I've tagged and released v2019.07 and I would like to thank all of >>> our contributor for their efforts. >> >> I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > >>> To repeat something I posted about in the previous -rc release, I've >>> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page >>> that the "next" branch is expected to be rebased. Why? While I'm not >>> sure if I want to apply things directly to the next branch and then give >>> them some sort of automated testing, I do want to try and give changes >>> some sort of build testing and similar sooner than I have, and that was >>> at least a related problem. >>> >>> In terms of a changelog, >>> git log --merges v2019.10-rc4..v2019.10 >>> or >>> git log --merges v2019.07..v2019.10 >>> >>> For this next release, one big concern I have but that I am hopeful we >>> will be able to overcome is that we need to remove Python 2.7 support. >>> Python 2.7 itself is end of lifed on January 1st, 2020. There's been a >>> number of patches posted that get us a good part of the way there and I >>> believe we can get the rest done before the deadline. >>> >>> The merge window is once again open and I plan to tag -rc1 on October >>> 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. >> >> I am preparing pull request and I see that release has issue with >> sheevaplug board. >> >> 01: Prepare v2019.10 >>arm: + sheevaplug >> +u-boot.kwb exceeds file size limit: >> + limit: 524288 bytes >> + actual: 524632 bytes >> + excess: 344 bytes >> +make[1]: *** [u-boot.kwb] Error 1 >> +make[1]: *** Deleting file 'u-boot.kwb' >> +make: *** [sub-make] Error 2 >> >> There are also warnings about conversions to DM. >> >> Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address this, > but my travis and gitlab pipelines passed. So that implies to me > there's some /full/path string(s) somewhere that we should find and > address. Thanks! It was catched by Travis on my branch. https://travis-ci.org/michalsimek/u-boot/jobs/594990410 But I was retesting it on my PC on tag too(log above). Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > On 07. 10. 19 23:15, Tom Rini wrote: > > Hey all, > > > > It's release day and while we've once again had some last minute > > regression fixes, I feel things are as stable as they are likely to get > > so I've tagged and released v2019.07 and I would like to thank all of > > our contributor for their efforts. > > I expect v2019.10 :-) Oops. I did get the tag right this time at least. > > To repeat something I posted about in the previous -rc release, I've > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > that the "next" branch is expected to be rebased. Why? While I'm not > > sure if I want to apply things directly to the next branch and then give > > them some sort of automated testing, I do want to try and give changes > > some sort of build testing and similar sooner than I have, and that was > > at least a related problem. > > > > In terms of a changelog, > > git log --merges v2019.10-rc4..v2019.10 > > or > > git log --merges v2019.07..v2019.10 > > > > For this next release, one big concern I have but that I am hopeful we > > will be able to overcome is that we need to remove Python 2.7 support. > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > number of patches posted that get us a good part of the way there and I > > believe we can get the rest done before the deadline. > > > > The merge window is once again open and I plan to tag -rc1 on October > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > I am preparing pull request and I see that release has issue with > sheevaplug board. > > 01: Prepare v2019.10 >arm: + sheevaplug > +u-boot.kwb exceeds file size limit: > + limit: 524288 bytes > + actual: 524632 bytes > + excess: 344 bytes > +make[1]: *** [u-boot.kwb] Error 1 > +make[1]: *** Deleting file 'u-boot.kwb' > +make: *** [sub-make] Error 2 > > There are also warnings about conversions to DM. > > Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me there's some /full/path string(s) somewhere that we should find and address. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 07. 10. 19 23:15, Tom Rini wrote: > Hey all, > > It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. I expect v2019.10 :-) > > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > that the "next" branch is expected to be rebased. Why? While I'm not > sure if I want to apply things directly to the next branch and then give > them some sort of automated testing, I do want to try and give changes > some sort of build testing and similar sooner than I have, and that was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful we > will be able to overcome is that we need to remove Python 2.7 support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > number of patches posted that get us a good part of the way there and I > believe we can get the rest done before the deadline. > > The merge window is once again open and I plan to tag -rc1 on October > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. I am preparing pull request and I see that release has issue with sheevaplug board. 01: Prepare v2019.10 arm: + sheevaplug +u-boot.kwb exceeds file size limit: + limit: 524288 bytes + actual: 524632 bytes + excess: 344 bytes +make[1]: *** [u-boot.kwb] Error 1 +make[1]: *** Deleting file 'u-boot.kwb' +make: *** [sub-make] Error 2 There are also warnings about conversions to DM. Is it OK to ignore these boards which should be likely removed? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2019.10 released
Hey all, It's release day and while we've once again had some last minute regression fixes, I feel things are as stable as they are likely to get so I've tagged and released v2019.07 and I would like to thank all of our contributor for their efforts. To repeat something I posted about in the previous -rc release, I've clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page that the "next" branch is expected to be rebased. Why? While I'm not sure if I want to apply things directly to the next branch and then give them some sort of automated testing, I do want to try and give changes some sort of build testing and similar sooner than I have, and that was at least a related problem. In terms of a changelog, git log --merges v2019.10-rc4..v2019.10 or git log --merges v2019.07..v2019.10 For this next release, one big concern I have but that I am hopeful we will be able to overcome is that we need to remove Python 2.7 support. Python 2.7 itself is end of lifed on January 1st, 2020. There's been a number of patches posted that get us a good part of the way there and I believe we can get the rest done before the deadline. The merge window is once again open and I plan to tag -rc1 on October 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
