From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Thu, 11 Apr 2013 00:50:01 +0200
Subject: [U-Boot] [PATCH v2 4/4] ARM: fix CONFIG_SPL_MAX_SIZE semantics
In-Reply-To: <5165E602.5040700@wwwdotorg.org>
References: <1365451109-22030-1-git-send-email-albert.u.boot@aribaud.net>
	<1365549295-9388-1-git-send-email-albert.u.boot@aribaud.net>
	<1365549295-9388-2-git-send-email-albert.u.boot@aribaud.net>
	<1365549295-9388-3-git-send-email-albert.u.boot@aribaud.net>
	<1365549295-9388-4-git-send-email-albert.u.boot@aribaud.net>
	<1365549295-9388-5-git-send-email-albert.u.boot@aribaud.net>
	<5165E602.5040700@wwwdotorg.org>
Message-ID: <20130411005001.56efc6a3@lilith>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Stephen,

On Wed, 10 Apr 2013 16:21:54 -0600, Stephen Warren
<swarren@wwwdotorg.org> wrote:

> On 04/09/2013 05:14 PM, Albert ARIBAUD wrote:
> > Remove SPL-related ASSERT() in arch/arm/cpu/u-boot.lds
> > as this file is never used for SPL builds.
> > 
> > Rewrite the ASSERT() in arch/arm/cpu/u-boot-spl.lds
> > to separately test image (text,data,rodata...) size
> > and BSS size each against its own max.
> > 
> > Also, output section mmutable is not used in SPL builds.
> > Remove it.
> > 
> > Finally, update README regarding the (now homogeneous)
> > semantics of the CONFIG_SPL_MAX_SIZE and
> > CONFIG_SPL_BSS_MAX_SIZE macros.
> 
> This still seems to have separate defines for SPL text/data/rodata size
> and BSS size. If I want instead to limit the total text/data/rodata/bss
> size, but place no specific limit on the bss size individually, can I
> not do that?

This would defeat the purpose of giving CONFIG_SPL_MAX_SIZE a constant
meaning -- one of the issues which prompted this patch series is that
in ARM sometime CONFIG_SPL_MAX_SIZE meant BSS included, and sometime
excluded, and this inconsistency had to be resolved. As in the rest of
U-boot, CONFIG_SPL_MAX_SIZE was meant BSS excluded, this is the
semantics that was decided.

What we could do, though, is subdivide testing based on the existence or
non-existence of CONFIG_SPL_BSS_START_ADDR:

- if CONFIG_SPL_BSS_START_ADDR exists, then we assume SPL image and
  BSS are disjoint and we test each one against its max size, as this
  patch series does;

- if CONFIG_SPL_BSS_START_ADDR does not exist, then we assume SPL image
  and BSS are contiguous and we test the whole of SPL against the sum
  of CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE.

I guess this will be considered useless complication -- after all,
once you have artificially partitioned your SPL space into image+BSS --
and you know from the build command how much should be allotted to each
of them -- the worst that can happen is that a later build fails with
an explicit error message forcing you to look at current image and BSS
size and adjust one or both of the max values accordingly.

Amicalement,
-- 
Albert.