From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL
Date: Thu, 5 Jan 2012 10:09:54 +0100 [thread overview]
Message-ID: <201201051009.55036.marek.vasut@gmail.com> (raw)
In-Reply-To: <CA+M6bX=s+hgutbUD6ZDW4-RdTKSE_6de-y49v_9BcQHCqr0dRQ@mail.gmail.com>
> On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood <scottwood@freescale.com> wrote:
> > On 12/05/2011 05:17 PM, Marek Vasut wrote:
> >> This will be beneficial for the PXA3XX NAND driver, which uses the NAND
> >> IDs to identify the chip and configure the controller accordingly.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> >> Cc: Scott Wood <scottwood@freescale.com>
> >> ---
> >> drivers/mtd/nand/Makefile | 4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> >> index a63c0e4..46e79e3 100644
> >> --- a/drivers/mtd/nand/Makefile
> >> +++ b/drivers/mtd/nand/Makefile
> >> @@ -35,10 +35,10 @@ COBJS-y += nand_spl_load.o
> >> endif
> >> else
> >> COBJS-y += nand.o
> >> -COBJS-y += nand_bbt.o
> >> -COBJS-y += nand_ids.o
> >> COBJS-y += nand_util.o
> >> endif
> >> +COBJS-y += nand_bbt.o
> >> +COBJS-y += nand_ids.o
> >> COBJS-y += nand_ecc.o
> >> COBJS-y += nand_base.o
> >
> > So, in theory with gc-sections this shouldn't increase the size of any
> > SPL that currently successfully links (at least in the absence of things
> > like weak symbols). However, I observed a devkit8000 build go from this:
> >
> > text data bss dec hex filename
> > 40709 1792 197764 240265 3aa89 /tmp/u-boot-arm/spl/u-boot-spl
> >
> > to this:
> >
> > text data bss dec hex filename
> > 42277 1792 197764 241833 3b0a9 /tmp/u-boot-arm/spl/u-boot-spl
> >
> > I verified that --function-sections/-fdata-sections/--gc-sections are
> > being used on the SPL. It looks like strings are not getting dropped.
> >
> > If there's no way to fix this, this is going to be a big problem for the
> > existing users of nand_spl to migrate to the new SPL model, unless the
> > notion of "include a bunch of stuff and let gc-sections take care of it"
> > is dropped.
>
> I'll confirm gc-sections/etc are not as awesome as we think. You can
> drop the size of current SPL builds (for say devkit8000) by taking
> things that should be dropped for us and forcing them out with #ifndef
> CONFIG_SPL_BUILD.
Maybe if we had those LTO tables at the gc-sections time, it'd drop. But we
can't rely on those.
So instead of compiling in the nand-ids, it'd be better to allow SPL to pull in
the whole NAND/MTD stack.
M
next prev parent reply other threads:[~2012-01-05 9:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 23:17 [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL Marek Vasut
2012-01-04 23:56 ` Scott Wood
2012-01-05 3:11 ` Tom Rini
2012-01-05 9:09 ` Marek Vasut [this message]
2012-01-05 14:15 ` Tom Rini
2012-01-05 23:04 ` Scott Wood
2012-01-06 0:41 ` Tom Rini
2012-01-06 19:03 ` Scott Wood
2012-01-06 19:14 ` Tom Rini
2012-01-06 19:18 ` Scott Wood
2012-01-08 9:56 ` Mike Frysinger
2012-01-09 19:41 ` Scott Wood
2012-01-09 21:21 ` Mike Frysinger
2012-01-09 21:23 ` Tom Rini
2012-01-09 21:25 ` Tom Rini
2012-01-10 18:25 ` Mike Frysinger
2012-01-10 18:36 ` Tom Rini
2012-01-09 21:27 ` Scott Wood
2012-01-10 18:25 ` Mike Frysinger
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=201201051009.55036.marek.vasut@gmail.com \
--to=marek.vasut@gmail.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 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.