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

[Masahiro Yamada <yamada.masahiro@socionext.com>]

Hi Nishanth,


2017-03-28 6:44 GMT+09:00 Nishanth Menon <nm@ti.com>:
> 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


When O= is given, the build system runs in the object tree,
not in the source tree.
(This is the same as Linux.)

If you see the top Makefile:

ifeq ($(KBUILD_SRC),)
        # building in the source tree
        srctree := .
else
        ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR)))
                # building in a subdirectory of the source tree
                srctree := ..
        else
                srctree := $(KBUILD_SRC)
        endif
endif




If O=  points to a sub-directory of the source tree,
the relative path "srctree := .." is used.

Otherwise, the absolute path srctree := $(KBUILD_SRC) is used.
In your case, "O=../b" means the source tree and the obj tree
are siblings.  So, absolute path.



If you want to see a short relative path for __FILE__,
I'd recommend to use a sub-directory for O=.

For example, your source tree is located at
~/aaaaaaaaa/bbbbbbb/cccccccc/u-boot,
create a directory  ~/aaaaaaaaa/bbbbbbb/cccccccc/u-boot/foo,
then give  O=foo


Masahiro