[U-Boot] [PATCH 4/4] ARM: tegra: increase CONFIG_SYS_TEXT_BASE

[Tom Rini <trini@ti.com>]

On Wed, Oct 17, 2012 at 09:20:31PM -0600, Stephen Warren wrote:
> On 10/17/2012 06:05 PM, Simon Glass wrote:
> > Hi Stephen.
> > 
> > On Tue, Oct 16, 2012 at 3:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> On 10/16/2012 04:09 PM, Lucas Stach wrote:
> >>> Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
> >>>> From: Stephen Warren <swarren@nvidia.com>
> >>>>
> >>>> The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not
> >>>> overlap the main U-Boot.
> >>>
> >>> Is there any specific reason why the SPL is now bigger than before? Or
> >>> is this just because of the general U-Boot rework (like serial multi
> >>> anywhere)? And by how much has it grown? This is really more out of
> >>> curiosity rather than any real objection.
> >>
> >> Looking at this more, I built commit cca6076 "tegra20: Remove armv4t
> >> build flags" which was the last patch in the series that enabled SPL on
> >> Tegra, and it overflows even there:
> >>
> >> Configuring for ventana board...
> >>    text    data     bss     dec     hex filename
> >>  226085    4384  274228  504697   7b379 ./u-boot
> >>   13857     153    4516   18526    485e ./spl/u-boot-spl
> >>
> >> u-boot/master currently has:
> >>
> >> Configuring for ventana board...
> >>    text    data     bss     dec     hex filename
> >>  233579    4432  274368  512379   7d17b ./u-boot
> >>   14382     201    4520   19103    4a9f ./spl/u-boot-spl
> >>
> >> So, there is slight growth, but mainly I think we've just been getting
> >> lucky.
> >>
> >> Also, the overflow might possibly only have been exposed by the recent
> >> serial rework; when I found the problem the serial rework caused on
> >> Tegra, Allen mentioned that the missing BSS clearing hadn't been a
> >> problem before since no global variables were used, but the serial
> >> rework caused some to be.
> > 
> > To ask the opposite question, is it worth increasing by a whole 16KB
> > so that the base address of U-Boot is a more aligned number?
> 
> That would bloat the binary by about 12KB more than it needs to be. I
> don't believe there's any particular need for the main U-Boot to be
> built for any particular address, and we can just continue to bump up
> this value as/when the SPL grows.

Well, lets stop and think for a minute more.  Are we likely to add new
features to SPL on Tegra (direct OS booting, support in one binary for
both SPL-from-flash and SPL-from-something-else) ?  If so, lets increase
this to a reasonable maximum now rather than keep bumping and breaking.
On TI parts for example, we are limited by our SRAM size and set that
(minus a bit for stack) as how big we allow SPL to be so that we don't
have to tweak this value based on toolchain or feature changes (ELDK 4.2
vs current Linaro for example, can be a noticable size difference).

-- 
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/20121018/5af1233a/attachment.pgp>