Hey Tom, On Tue, Dec 3, 2019 at 11:05 AM Tom Rini <tr...@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 <tr...@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