[U-Boot] __FILE__ usage and and SPL limits for SRAM

[Tom Rini]

On Tue, May 23, 2017 at 09:57:10AM +0900, Masahiro Yamada wrote:
> Hi Denys,
> 
> 
> 2017-05-23 2:23 GMT+09:00 Denys Dmytriyenko <denis at denix.org>:
> > 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
> 
> Thanks for you pointer!
> 
> If merged, it will reduce the image size, and also helpful for
> reproducible build.
> 
> (We can not save users of old GCC versions, though...)

Did the kernel side of this die out?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/273b2169/attachment.sig>