Hi Tom, > On Thu, Mar 28, 2024 at 01:55:22PM +0100, Lukasz Majewski wrote: > > Hi Tom, > > > > > On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote: > > > > Dear Community, > > > > > > > > I'd like to share with you some thoughts about growth of > > > > u-boot's binary size for SPL and u-boot proper. > > > > > > > > Board: XEA > > > > SoC : imx287 (still in active production) > > > > Problem: SPL size constrained to ~55 KiB (This cannot be > > > > exceeded). Board design constraints u-boot proper size to less > > > > than ~448 KiB > > > > > > > > > > > > When XEA was added (2019.07): > > > > - u-boot.sb (SPL): 37 KiB > > > > - u-boot.img : 401 KiB > > > > > > > > Now (2024.04): > > > > - u-boot.sb (SPL): 40 KiB > > > > - u-boot.img : 427 KiB > > > > > > > > (With a _lot_ of effort put to reduce the size) > > > > > > > > Hence, the question - would it be possible to take more concern > > > > about the binary size growth? > > > > > > > > Maybe CI could catch patches, which enable by default some > > > > features and the size is unintentionally increased? > > > > > > > > I'm open for any feedback and thoughts on "stopping" the binary > > > > size increase. > > > > > > I think that's pretty amazingly small growth for nearly 5 years > > > of bug fixes and feature enhancements that it's likely minor to > > > make granular. > > > > Those results are after using OF_PLATDATA in SPL and other tricks - > > like compression of DTB in u-boot proper, so this caused some extra > > effort to keep small. > > Yes, and I'm still pretty happy with that.
Ok :-) > I would encourage you to do > what I suggested, before turning on LTO (as that makes it hard to see > symbol size changes due to the nature of LTO) as what you asked for in > your original email is what I do, and have done for a very long time > now, with 99% of every pull request / branch merge. I'm not saying I > didn't miss anything, but I am saying it's a matter of specific > changes and not a general problem. Ok. I will check binman's output for symbol sizes changes. > And if you hadn't previously set > the options to enforce failure to build if hard size constraints are > missed, please do so. > I will. Thanks for input and help. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpWXlCv80mUZ.pgp
Description: OpenPGP digital signature
