From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Why are some global vars part of the image, and some not?
Date: Mon, 06 Nov 2006 13:46:43 -0600 [thread overview]
Message-ID: <454F9123.4050706@freescale.com> (raw)
In-Reply-To: <454F879E.9020803@smiths-aerospace.com>
Jerry Van Baren wrote:
> Does the linker create proper zero initialization?
Yes.
> Does the bss/data end up in the right place?
It ends up where nonzero-initialized data currently is (i.e. in flash
before relocation, in RAM after).
> On start up your stack is
> in cache or dual-port RAM until SDRAM is initialized. When does the
> initialized portion of the data section get initialized and where?
> Before it is in SDRAM or after SDRAM is initialized?
I don't follow what, specifically, you mean by "initialized portion".
The data section contains data which is statically initiallized at
compile/link time; the only difference is that it would now include data
whose initial value is zero. Some pieces of data will be further
"initialized" at runtime by U-Boot code; this, of course, must happen
after SDRAM is initialized (and U-Boot has relocated to it), but that
has nothing to do with moving the BSS into the data segment.
The BSS is purely an optimization; besides increasing flash footprint
somewhat, removing it should not change anything except for code that
was already broken.
> Simple enough things to experiment with, but it all takes time and the
> benefit is questionable. Feel free to prove us curmudgeons wrong. ;-)
The main things that would take effort are changing all the board linker
scripts, and finding large BSS allocations and changing them to be
dynamically allocated so they don't take up space in flash.
The benefit is that bss-related bugs in the pre-RAM code go away and
stay away, and that ugliness such as having to specify __attribute__
((section ("data"))) whenever the value is zero also goes away.
-Scott
next prev parent reply other threads:[~2006-11-06 19:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-03 21:58 [U-Boot-Users] Why are some global vars part of the image, and some not? Timur Tabi
2006-11-03 22:19 ` Timur Tabi
2006-11-03 23:47 ` Wolfgang Denk
2006-11-04 0:09 ` Timur Tabi
2006-11-04 0:33 ` Wolfgang Denk
2006-11-03 23:44 ` Wolfgang Denk
2006-11-04 0:07 ` Timur Tabi
2006-11-04 0:31 ` Wolfgang Denk
2006-11-04 1:38 ` Timur Tabi
2006-11-04 2:04 ` Wolfgang Denk
2006-11-06 17:43 ` Scott Wood
2006-11-06 18:03 ` Jerry Van Baren
2006-11-06 18:08 ` Timur Tabi
2006-11-06 18:48 ` Jerry Van Baren
2006-11-06 18:56 ` Scott Wood
2006-11-06 19:06 ` Jerry Van Baren
2006-11-06 19:46 ` Scott Wood [this message]
2006-11-06 19:54 ` Timur Tabi
2006-11-06 20:13 ` Jerry Van Baren
2006-11-06 20:21 ` Timur Tabi
2006-11-06 20:44 ` Wolfgang Denk
2006-11-06 20:35 ` Tolunay Orkun
2006-11-06 20:29 ` Wolfgang Denk
2006-11-06 20:26 ` Wolfgang Denk
2006-11-06 20:48 ` Scott Wood
2006-11-06 21:15 ` 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=454F9123.4050706@freescale.com \
--to=scottwood@freescale.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox