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

From: Lokesh Vutla <lokeshvutla@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] __FILE__ usage and and SPL limits for SRAM
Date: Tue, 28 Mar 2017 11:37:45 +0530	[thread overview]
Message-ID: <52c824f5-117a-718e-80ef-7d2142e4cfb3@ti.com> (raw)
In-Reply-To: <7522fff3-a33e-21bd-00fe-55c03b4169c1@ti.com>

+ more folks.

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

Any suggestions would be really helpful.

Thanks and regards,
Lokesh