[U-Boot] [PATCH] OpenRD: relocate environment to 640kB

[Tom Rini <trini@ti.com>]

On Thu, Jul 11, 2013 at 07:40:28PM +0200, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini <trini@ti.com> wrote:
> 
> > On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
> > > Hi Sascha,
> > > 
> > > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe
> > > <t-uboot@infra-silbe.de> wrote:
> > > 
> > > > Hello Albert, hello Tom,
> > > > 
> > > > Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
> > > > 
> > > > [Move environment to account for increase in U-Boot size]
> > > > > This patch is for 2013.10, not 2013.07, but I prefer raising the issue
> > > > > as early as possible.
> > > > >
> > > > > If there is no way to make things smoother, then I think the 2013.10
> > > > > release notes should contain a red, blinking, paragraph about this. I
> > > > > would *hate* it if people were not warned and given a method to port
> > > > > their current environment setting over.
> > > > >
> > > > > Possibly even, the 2013.07 could have a warning about the change to
> > > > > come, so that people have a better chance yet to prepare for the
> > > > > change.
> > > > 
> > > > The situation has gotten better recently and U-Boot fits into the
> > > > previous partition size of 384KiB again. So it isn't broken on OpenRD
> > > > anymore and the above would seem like a good approach.
> > > 
> > > How well does it fit again, and do you have any idea what caused the
> > > increase in size, and what caused the decrease?
> > 
> > I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections
> > is what brought the size back down again.  We've been adding a lot of
> > kinda optional code, and to avoid having to ifdef the hell out of
> > everything, we've been relying on growth not being a big problem or just
> > ignoring it.
> 
> ... Which in the end can bite back, see anonymous string issue. Are we
> heading back to carefully selecting which files we build rather than
> building then dropping?

It depends on what we can get from the tools we have, cleanly.  I've
seen, for example, patches to kill all output from SPL, as that was
required to get the required big features into a size constrained SPL.
But I don't think it was clean enough for mainline.  On the other hand,
we've got some large files, and if splitting them up for logical uses
also gets us working around string issues, good for us.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/05057f8d/attachment.pgp>