All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: Start using fdt_high for relocation
Date: Fri, 06 Dec 2013 16:05:17 -0700	[thread overview]
Message-ID: <52A2582D.6030507@wwwdotorg.org> (raw)
In-Reply-To: <20131206210435.GC420@bill-the-cat>

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.

  reply	other threads:[~2013-12-06 23:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06 15:48 [U-Boot] [RFC] ARM: Start using fdt_high for relocation Tom Rini
2013-12-06 16:59 ` Albert ARIBAUD
2013-12-06 17:18   ` Tom Rini
2013-12-06 19:28     ` Albert ARIBAUD
2013-12-06 20:31       ` Tom Rini
2013-12-06 20:44         ` Stephen Warren
2013-12-06 21:04           ` Tom Rini
2013-12-06 23:05             ` Stephen Warren [this message]
2013-12-06 20:25 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A2582D.6030507@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.