[U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

On Fri, 2018-11-09 at 10:41 +0100, Alexander Graf wrote:
> On 11/09/2018 10:18 AM, Marcel Ziswiler wrote:
> > Hi Stefano
> > 
> > On Thu, 2018-11-08 at 15:07 +0100, Stefano Babic wrote:
> > > Hi Marcel,
> > > 
> > > On 08/11/18 02:55, Fabio Estevam wrote:
> > > > [Adding Stefano]
> > > > 
> > > > On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler <marcel@ziswiler
> > > > .com
> > > > > wrote:
> > > > > 
> > > > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > 
> > > > > The make macro to check if the binary exceeds the board size
> > > > > limit is
> > > > > taken straight from the root Makefile.
> > > > > 
> > > > > Without this and e.g. enabled EFI Vybrid fails booting as the
> > > > > regular
> > > > > size limit check does not take the final u-boot.imx binary
> > > > > size
> > > > > into
> > > > > account which is bigger due to alignment as well as IMX
> > > > > header
> > > > > stuff.
> > > > > 
> > > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > 
> > > > Reviewed-by: Fabio Estevam <festevam@gmail.com>
> > > > 
> > > > Hi Stefano, maybe this could be material for 2018.11?
> > > > 
> > > 
> > > Added both patches to u-boot-imx, check is effective, now size is
> > > too
> > > much and build fails:
> > > 
> > > 
> > > Building current source for 1 boards (1 thread, 8 jobs per
> > > thread)
> > >         arm:  +   colibri_vf
> > > +u-boot.imx exceeds file size limit:
> > > +  limit:  520192 bytes
> > > +  actual: 526104 bytes
> > > +  excess: 5912 bytes
> > > +make[2]: *** [u-boot.imx] Error 1
> > > +make[1]: *** [u-boot.imx] Error 2
> > > +make: *** [sub-make] Error 2
> > >      0    0    1 /1      colibri_vf
> > > 
> > > Can you take a look ?
> > 
> > Sure, what kind of a tool chain are you using? Might just be that
> > the
> > GCC 8.2 I was using does a better job in optimising stuff. Yep,
> > with
> > GCC 7.3.1 it also fails at my end! I guess then we have to drop EFI
> > entirely but I doubt Mr. Graf will be happy...
> 
> I definitely wouldn't be happy, but I've seen us run into tight 
> situations with Vybrid before. So yes, if your platform really a) 
> doesn't want to ever support EBBR and b) really has very tight size 
> constraints, disabling EFI_LOADER is perfectly fine with me.

Yes, I'm fully aware of EBBR having attended Grant's talk in Edinburgh
but especially those older raw NAND platforms are probably not the best
candidates for any of this. Unless, of course, we would put some more
effort transitioning them all to SPL and what not to overcome e.g. such
SRAM limitations. I will send a v2 which disables EFI for now.

> Alex

Cheers

Marcel