[U-Boot] [PATCH] distro: Disable iso partition format for SPL

[Tom Rini]

On Mon, Apr 25, 2016 at 05:18:38PM +0200, Heiko Schocher wrote:
> Hello Alexander,
> 
> Am 25.04.2016 um 17:04 schrieb Alexander Graf:
> >On 04/25/2016 05:03 PM, Heiko Schocher wrote:
> >>Hello Alexander,
> >>
> >>Am 25.04.2016 um 14:55 schrieb Alexander Graf:
> >>>When building an SPL binary, chances are quite slim that we need an
> >>>iso partition label. However, there were reports of us exceeding our
> >>>SPL memory limit with iso enabled.
> >>>
> >>>So for now, let's disable the ISO partition format code when in the
> >>>SPL build.
> >>>
> >>>Reported-by: Heiko Schocher <hs at denx.de>
> >>>Signed-off-by: Alexander Graf <agraf at suse.de>
> >>>---
> >>>  include/config_distro_defaults.h | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >>Thanks for the fix!
> >>
> >>Acked-by: Heiko Schocher <hs at denx.de>
> >
> >Did you test and verify that this fixes the issue for you? My local compile was still too big, but I
> >guess that's a toolchain difference thing :)
> 
> I tested this patch for an am335x port, I soon post to mainline. With
> this patch, it compiled again clean for me.
> 
> Just tried the "igep0030_nand_defconfig" ... yes, it fails also with
> this patch:
> 
> without your patch:
> arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 1176 bytes
> 
> with it:
> arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 272 bytes
> 
> So, your patch saves some bytes, but this fix seems valid for me, so I
> acked it ... But it seems, there are more issues with this board ...
> 
> Ah, Tom already posted another fix, see:
> http://patchwork.ozlabs.org/patch/614516/

The root problem is that we have a few boards that are once again close
to the size limit, depending on toolchain.  I'm slightly surprised that
you aren't also telling me duovero is broken (that overflows for me
depending on toolchaind and I've already asked the maintainer to look
into trimming things).  We may, in the end, have to take some not-nice
patches for this release and see about maybe saying that OMAP3 also
needs to use DDR for SPL stack, once set (and saying that ~4KiB space
should be enough for stack space prior to DDR init).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160425/b5642fb3/attachment.sig>