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

[Felipe Balbi]

Hi,

Nishanth Menon <nm at ti.com> writes:
> Hi Masahiro-san,
>
> On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada
> <yamada.masahiro at socionext.com> wrote:
> [...]
>>
>> 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.
>
> I did simplify this a bit with O=../b to highlight exactly what you
> mentioned above. in our case, the O=path points to a completely
> different directory 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
>
> Typical product build such as OE recipes used (in our case) does not
> build into the source folder, instead, all binary builds are pointed
> to either a temporary location or a package build location. So, while
> O=source_path/build would aliviate the problem, it still does'nt
> really solve the root of the issue.

have you tried using __BASE_FILE__ instead of __FILE__? You could also
redefine __FILE__ or __BASE_FILE__ while building SPL.

-- 
balbi