[U-Boot] Board-specific commands unintentionally linked into SPL?

Tyler Olmstead tyler.j.olmstead at gmail.com
Fri Aug 3 01:16:47 CEST 2012


Hi all,

Apologies for the delay in response, I've been working on a high priority issue.

On Thu, Jul 26, 2012 at 4:02 PM, Christian Riesch
<christian.riesch at omicron.at> wrote:
> Hi,
>
>
> On Thursday, July 26, 2012, Aneesh V wrote:
>>
>> Hi Tyler,
>>
>> On 07/26/2012 11:54 AM, Tyler Olmstead wrote:
>>>
>>> Hi Christian,
>>>
>>> On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch
>>> <christian.riesch at omicron.at>  wrote:
>>>>
>>>>
>>>> [cc'd Prabhakar Lad, Tom Rini, and Scott Wood]
>>>>
>>>> Tyler,
>>>>
>>>> On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead
>>>> <tyler.j.olmstead at gmail.com>  wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I have encountered some issues adding a board-specific command to the
>>>>> board file of a project I have been working on. Specifically, after
>>>>> adding a U-Boot shell command to my board file, I have been seeing
>>>>> link-stage failures when attempting to build SPL.
>>>>
>>>>
>>>> It's hard to tell without having your code, but I think this problem
>>>> was already discussed in [1]. However I do not remember how Prabhakar
>>>> solved it in the end.
>>>
>>>
>>> Yes, I ran into this thread while debugging the problem, which
>>> ultimately lead me to my solution. From that same thread [1], Wolfgang
>>> Denk writes:
>>>
>>> <quote>
>>>>
>>>>
>>>> *I want to add a command using U_BOOT_CMD in uboot, where SPL_BUILD is
>>>> enabled for example for da850evm in spl frame work how can i do that *
>>>
>>>
>>> This makes no sense. Commands can only be executed when we have full
>>> U-Boot running (actually even only after relocation).  You cannot run
>>> commands in the SPL.
>>> </quote>
>>>
>>> I understand of course why it makes no sense to have command support
>>> in the SPL. However, the crux of this problem is that U-Boot and SPL
>>> both link in the same board object file, so in that sense compile-time
>>> switches wont work. From later in [1], Scott Wood writes:
>>
>>
>> No that's not correct. For SPL we build the object files into a
>> different directory "spl/". Please see the below in spl/Makefile
Yes, thank you for correcting me. Also, I had confused CONFIG_SPL and
CONFIG_SPL_BUILD.

>>
>> # We want the final binaries in this directory
>> obj := $(OBJTREE)/spl/
>>
>> Object files used for U-Boot and SPL are not the same. You can use
>> compile-time switches and it should work just fine.
>
>
> Thanks for pointing that out, Aneesh.
>
> Therefore an #ifndef CONFIG_SPL_BUILD would work for Tyler's problem and I
> think that it's also easier to read than some build magic that removes
> u-boot commands.
>
> Christian
>
Yes, the #ifndef works perfectly for me. However, I also agree with
your sentiment regarding build magic, which is why I wonder if
removing the $GEN_UBOOT linker magic from the SPL makefile wouldn't be
the best approach. If this was done, then my U-Boot command wouldn't
have been linked into SPL in the first place, it wouldn't require any
cluttering of #ifdef's, and would eliminate the potential of others
encountering this same problem. This seems reasonable given that SPL
shouldn't contain any command support. Thoughts?

>>
>>
>> -Aneesh
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot


More information about the U-Boot mailing list