From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Fri, 06 Dec 2013 16:05:17 -0700
Subject: [U-Boot] [RFC] ARM: Start using fdt_high for relocation
In-Reply-To: <20131206210435.GC420@bill-the-cat>
References: <20131206154850.GW420@bill-the-cat>
	<20131206175937.5e2ad421@lilith>
	<20131206171813.GA420@bill-the-cat>
	<20131206202804.5cf6fbe4@lilith>
	<20131206203116.GB420@bill-the-cat>
	<52A23726.5030903@wwwdotorg.org>
	<20131206210435.GC420@bill-the-cat>
Message-ID: <52A2582D.6030507@wwwdotorg.org>
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

On 12/06/2013 02:04 PM, Tom Rini wrote:
...
> There's two problems here.  The first problem is that we have
> between 256MiB and 1GiB of DDR on the platform, but we could just
> design for the smallest case.  The second problem is, what's big
> enough?  You've got 32MiB (tegra30) which I would hope is enough
> (and I suggested as much in Dennis' thread) for kernel + BSS, but
> how big is a multi platform kernel with a few big features going to
> get?  Or do we say that's an unreasonable out of box use case?

Is there any limit on .data/.bss size like there is .text (due to the
limited range of relative jump encoding), or would data accesses just
fall back to a relative load of the absolute address, and hence be
unbounded.

FWIW, I see the following sizes currently:

tegra_defconfig

.text	005862c4
.data	0005eb68
.bss	00055bf0

multi_v7_defconfig

.text	004a5560
.data	00092600
.bss	00046014

(I think multi_v7_defconfig doesn't yet have that many drivers
enabled, and when it does presumably they'd be modules)

... so BSS isn't terribly large at the moment.