public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] __FILE__ usage and and SPL limits for SRAM
Date: Mon, 22 May 2017 13:23:29 -0400	[thread overview]
Message-ID: <20170522172329.GX28053@denix.org> (raw)
In-Reply-To: <CAK7LNARP0Urn=0LdCk+Es+uK9=sBAWGWz+jm+J+jTtK-5+AmtA@mail.gmail.com>

On Sat, Apr 22, 2017 at 02:30:09PM +0900, Masahiro Yamada wrote:
> >>> On Tuesday 28 March 2017 03:14 AM, Nishanth Menon wrote:
> >>> > Hi,
> >>> >
> >>> > we've kind of run into an interesting situation recently, but might be
> >>> > of interest for various folks trying to reduce the image sizes.
> >>> >
> >>> > our AM335x device has a limited amount of sram.. and the SPL tries to
> >>> > fit into it (a bit tricky given the restricted space we have on it on
> >>> > certain class of devices).
> >>> >
> >>> > arch/arm/mach-omap2/am33xx/u-boot-spl.lds is a bit custom tailored
> >>> > around this.
> >>> >
> >>> > Key in this is:
> >>> > . = ALIGN(4);
> >>> > .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
> >>> >
> >>> > . = ALIGN(4);
> >>> > .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
> >>> >
> >>> >
> >>> > Now, our jenkins build system happens to use a varied build path and
> >>> > uses O= path. to simplify the details:
> >>> > mkdir
> >>> > /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccccccccccccccccccccccccccccccc
> >>> >
> >>> > mkdir
> >>> > /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccccccccccccccccccccccccccccccc/b
> >>> >
> >>> >
> >>> > git clone u-boot
> >>> > cd u-boot
> >>> >
> >>> > git clean -fdx
> >>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b am335x_evm_defconfig
> >>> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b all
> >>> >
> >>> > depending on depth of the path, this would fail.. a little bit of
> >>> > headscratching later..
> >>> > when using O= build system uses absolute paths, which translates to
> >>> > __FILE__ being absolute paths as well..
> >>> >
> >>> > in u-boot, any printf("%s", __FILE__) makes u-boot allocate this file
> >>> > path in rodata.
> >>> >
> >>> > So, depending on how deep the path is rodata size varies and ends up
> >>> > pushing .data out of sram max range.
> >>> >
> >>> > we dont really care to put a print of complete absolute path anyways,
> >>> > and I am not really sure of a clean way to resolve this:
> >>> > a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in
> >>> > b) replace usage of __FILE__ with something like __FILENAME__ as
> >>> > recommended by [1]
> >>> >
> >>> >
> >>> > What is the suggestion we do?
> >>> >
> >>> > [1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path

<snip>

> I can do this, but
> I'd like to move forward synced with Linux.
> 
> 
> Yesterday, I took some time to write patches
> and sent them to Linux ML.
> 
> 
> Plan A:
> https://lkml.org/lkml/2017/4/21/623
> https://patchwork.kernel.org/patch/9693559/
> https://patchwork.kernel.org/patch/9693563/
> 
> 
> Plan B:
> https://patchwork.kernel.org/patch/9693623/

FWIW:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268

-- 
Denys

  reply	other threads:[~2017-05-22 17:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 21:44 [U-Boot] __FILE__ usage and and SPL limits for SRAM Nishanth Menon
2017-03-28  6:07 ` Lokesh Vutla
2017-04-04 19:06   ` Tom Rini
2017-04-05 11:27     ` Wolfgang Denk
2017-04-09 19:27     ` Simon Glass
2017-04-22  5:30       ` Masahiro Yamada
2017-05-22 17:23         ` Denys Dmytriyenko [this message]
2017-05-23  0:57           ` Masahiro Yamada
2017-05-23  1:27             ` Tom Rini
2017-05-31  4:51               ` Masahiro Yamada
2017-05-31 11:32                 ` Tom Rini
2017-03-28  6:29 ` Masahiro Yamada
2017-03-28 11:20   ` Nishanth Menon
2017-03-28 11:47     ` Felipe Balbi
2017-03-28 11:59       ` Nishanth Menon
2017-03-29 10:57       ` Masahiro Yamada

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=20170522172329.GX28053@denix.org \
    --to=denis@denix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox