Thoughts about U-boot binary size increase

[Lukasz Majewski]

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: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240328/35f6f5bb/attachment.sig>