* [U-Boot] Board-specific commands unintentionally linked into SPL?
@ 2012-07-26 15:37 Tyler Olmstead
2012-07-26 17:03 ` Christian Riesch
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Olmstead @ 2012-07-26 15:37 UTC (permalink / raw)
To: u-boot
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.
<snip>
UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o
| sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ &&
arm-arago-linux-gnueabi-ld -T
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds
--gc-sections -Bstatic -Ttext 0xc1080000 $UNDEF_SYM
arch/arm/cpu/arm926ejs/start.o --start-group
arch/arm/cpu/arm926ejs/davinci/libdavinci.o
arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o
board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o
drivers/serial/libserial.o lib/libgeneric.o --end-group
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o
-L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3
-lgcc -Map u-boot-spl.map -o u-boot-spl
board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd':
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:121:
undefined reference to `eth_get_dev_by_index'
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:123:
undefined reference to `eth_write_hwaddr'
/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:126:
undefined reference to `printf'
make[1]: *** [/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl]
Error 1
make[1]: Leaving directory
`/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl'
make: *** [spl/u-boot-spl.bin] Error 2
</snip>
In the output above, one can see the environment variable $UNDEF_SYM
being defined as the result of the following SPL makefile
(spl/Makefile) target:
GEN_UBOOT = \
UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \
sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__START) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot-spl.map -o u-boot-spl
$(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds
$(GEN_UBOOT)
For my target, $UNDEF_SYM expands to the following:
-u__u_boot_cmd_mycmd
As I understand it, this is to force the inclusion of the commands
into the command table located in the special .u_boot_cmd section so
that unreferenced commands are not linked out of the final U-Boot
binary. However, I don't think that the inclusion of commands into the
SPL is intended. Removing the $UNDEF_SYM variable from the SPL
makefile resolves my build issues. I am planning on submitting a
patch. Does anyone see a flaw in my thinking?
Thanks,
-- Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 15:37 [U-Boot] Board-specific commands unintentionally linked into SPL? Tyler Olmstead
@ 2012-07-26 17:03 ` Christian Riesch
2012-07-26 18:54 ` Tyler Olmstead
0 siblings, 1 reply; 9+ messages in thread
From: Christian Riesch @ 2012-07-26 17:03 UTC (permalink / raw)
To: u-boot
[cc'd Prabhakar Lad, Tom Rini, and Scott Wood]
Tyler,
On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead
<tyler.j.olmstead@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.
In [1] I suggested to put an
#ifndef CONFIG_SPL_BUILD
U_BOOT_CMD(
...
);
#endif
around the command definition in the board file. But also other
solutions were discussed in that thread, please have a look.
Regards, Christian
[1] http://marc.info/?t=132748548900003
>
> <snip>
>
> UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o
> | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ &&
> arm-arago-linux-gnueabi-ld -T
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds
> --gc-sections -Bstatic -Ttext 0xc1080000 $UNDEF_SYM
> arch/arm/cpu/arm926ejs/start.o --start-group
> arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o
> board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o
> drivers/serial/libserial.o lib/libgeneric.o --end-group
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o
> -L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3
> -lgcc -Map u-boot-spl.map -o u-boot-spl
> board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd':
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:121:
> undefined reference to `eth_get_dev_by_index'
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:123:
> undefined reference to `eth_write_hwaddr'
> /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:126:
> undefined reference to `printf'
> make[1]: *** [/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl]
> Error 1
> make[1]: Leaving directory
> `/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl'
> make: *** [spl/u-boot-spl.bin] Error 2
>
> </snip>
>
> In the output above, one can see the environment variable $UNDEF_SYM
> being defined as the result of the following SPL makefile
> (spl/Makefile) target:
>
> GEN_UBOOT = \
> UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \
> sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
> cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__START) \
> --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
> -Map u-boot-spl.map -o u-boot-spl
>
> $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds
> $(GEN_UBOOT)
>
> For my target, $UNDEF_SYM expands to the following:
> -u__u_boot_cmd_mycmd
>
> As I understand it, this is to force the inclusion of the commands
> into the command table located in the special .u_boot_cmd section so
> that unreferenced commands are not linked out of the final U-Boot
> binary. However, I don't think that the inclusion of commands into the
> SPL is intended. Removing the $UNDEF_SYM variable from the SPL
> makefile resolves my build issues. I am planning on submitting a
> patch. Does anyone see a flaw in my thinking?
>
> Thanks,
> -- Tyler
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 17:03 ` Christian Riesch
@ 2012-07-26 18:54 ` Tyler Olmstead
2012-07-26 20:41 ` Aneesh V
2012-07-27 10:34 ` Lad, Prabhakar
0 siblings, 2 replies; 9+ messages in thread
From: Tyler Olmstead @ 2012-07-26 18:54 UTC (permalink / raw)
To: u-boot
Hi Christian,
On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch
<christian.riesch@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@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:
<quote>
> Maybe we should poke <command.h> to nop out U_BOOT_CMD for
> CONFIG_SPL_BUILD? OTOH, #ifndef'ing U_BOOT_CMD and the code itself
> gets us a space savings we wouldn't get otherwise (I suspect giving
> the MTD/NAND issue I've mentioned before)...
Commands should be stripped out already with the new SPL -- that's what
the (unfortunately uncommented) sed command in GEN_UBOOT appears to be
doing.
-Scott
</quote>
Unfortunately, this is incorrect. From the ld man page [2]:
-u symbol
--undefined=symbol
Force symbol to be entered in the output file as an
undefined symbol. Doing this may, for example, trigger linking of
additional modules from standard libraries. -u may be repeated with
different option arguments to enter additional undefined symbols.
This option is equivalent to the "EXTERN" linker script command.
Which means that the sed command in GEN_UBOOT in the SPL makefile
actually forces the *inclusion* of the command table, and therefore
forces the resolution of any undefined symbols in the command function
(hence my problem). This same command also appears in the top-level
U-Boot makefile, and I find it likely that it was included in the SPL
makefile as the result of a copy-paste error. This problem would only
arise for commands in object files that are linked into the SPL image,
such as the board file.
-- Tyler
[2] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld
>
> In [1] I suggested to put an
>
> #ifndef CONFIG_SPL_BUILD
> U_BOOT_CMD(
> ...
> );
> #endif
>
> around the command definition in the board file. But also other
> solutions were discussed in that thread, please have a look.
>
> Regards, Christian
>
> [1] http://marc.info/?t=132748548900003
>
> >
> > <snip>
> >
> > UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o
> > | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ &&
> > arm-arago-linux-gnueabi-ld -T
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds
> > --gc-sections -Bstatic -Ttext 0xc1080000 $UNDEF_SYM
> > arch/arm/cpu/arm926ejs/start.o --start-group
> > arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> > arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o
> > board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o
> > drivers/serial/libserial.o lib/libgeneric.o --end-group
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o
> > -L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3
> > -lgcc -Map u-boot-spl.map -o u-boot-spl
> > board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd':
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:121:
> > undefined reference to `eth_get_dev_by_index'
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:123:
> > undefined reference to `eth_write_hwaddr'
> > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:126:
> > undefined reference to `printf'
> > make[1]: *** [/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl]
> > Error 1
> > make[1]: Leaving directory
> > `/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl'
> > make: *** [spl/u-boot-spl.bin] Error 2
> >
> > </snip>
> >
> > In the output above, one can see the environment variable $UNDEF_SYM
> > being defined as the result of the following SPL makefile
> > (spl/Makefile) target:
> >
> > GEN_UBOOT = \
> > UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \
> > sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
> > cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__START) \
> > --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
> > -Map u-boot-spl.map -o u-boot-spl
> >
> > $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds
> > $(GEN_UBOOT)
> >
> > For my target, $UNDEF_SYM expands to the following:
> > -u__u_boot_cmd_mycmd
> >
> > As I understand it, this is to force the inclusion of the commands
> > into the command table located in the special .u_boot_cmd section so
> > that unreferenced commands are not linked out of the final U-Boot
> > binary. However, I don't think that the inclusion of commands into the
> > SPL is intended. Removing the $UNDEF_SYM variable from the SPL
> > makefile resolves my build issues. I am planning on submitting a
> > patch. Does anyone see a flaw in my thinking?
> >
> > Thanks,
> > -- Tyler
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 18:54 ` Tyler Olmstead
@ 2012-07-26 20:41 ` Aneesh V
2012-07-26 23:02 ` Christian Riesch
2012-07-27 10:34 ` Lad, Prabhakar
1 sibling, 1 reply; 9+ messages in thread
From: Aneesh V @ 2012-07-26 20:41 UTC (permalink / raw)
To: u-boot
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@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@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
# 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.
-Aneesh
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 20:41 ` Aneesh V
@ 2012-07-26 23:02 ` Christian Riesch
2012-08-02 23:16 ` Tyler Olmstead
0 siblings, 1 reply; 9+ messages in thread
From: Christian Riesch @ 2012-07-26 23:02 UTC (permalink / raw)
To: u-boot
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@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@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
>
> # 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
>
> -Aneesh
> ______________________________**_________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/**listinfo/u-boot<http://lists.denx.de/mailman/listinfo/u-boot>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 18:54 ` Tyler Olmstead
2012-07-26 20:41 ` Aneesh V
@ 2012-07-27 10:34 ` Lad, Prabhakar
1 sibling, 0 replies; 9+ messages in thread
From: Lad, Prabhakar @ 2012-07-27 10:34 UTC (permalink / raw)
To: u-boot
Hi Tyler/Christian,
On Fri, Jul 27, 2012 at 00:24:20, Tyler Olmstead wrote:
> Hi Christian,
>
> On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch
> <christian.riesch@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@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.
>
#ifndef CONFIG_SPL_BUILD solved my problem.
Thx,
--Prabhakar Lad
> 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:
>
> <quote>
> > Maybe we should poke <command.h> to nop out U_BOOT_CMD for
> > CONFIG_SPL_BUILD? OTOH, #ifndef'ing U_BOOT_CMD and the code itself
> > gets us a space savings we wouldn't get otherwise (I suspect giving
> > the MTD/NAND issue I've mentioned before)...
>
> Commands should be stripped out already with the new SPL -- that's what
> the (unfortunately uncommented) sed command in GEN_UBOOT appears to be
> doing.
>
> -Scott
> </quote>
>
> Unfortunately, this is incorrect. From the ld man page [2]:
>
> -u symbol
> --undefined=symbol
> Force symbol to be entered in the output file as an
> undefined symbol. Doing this may, for example, trigger linking of
> additional modules from standard libraries. -u may be repeated with
> different option arguments to enter additional undefined symbols.
> This option is equivalent to the "EXTERN" linker script command.
>
> Which means that the sed command in GEN_UBOOT in the SPL makefile
> actually forces the *inclusion* of the command table, and therefore
> forces the resolution of any undefined symbols in the command function
> (hence my problem). This same command also appears in the top-level
> U-Boot makefile, and I find it likely that it was included in the SPL
> makefile as the result of a copy-paste error. This problem would only
> arise for commands in object files that are linked into the SPL image,
> such as the board file.
>
> -- Tyler
> [2] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld
>
> >
> > In [1] I suggested to put an
> >
> > #ifndef CONFIG_SPL_BUILD
> > U_BOOT_CMD(
> > ...
> > );
> > #endif
> >
> > around the command definition in the board file. But also other
> > solutions were discussed in that thread, please have a look.
> >
> > Regards, Christian
> >
> > [1] http://marc.info/?t=132748548900003
> >
> > >
> > > <snip>
> > >
> > > UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o
> > > | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ &&
> > > arm-arago-linux-gnueabi-ld -T
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds
> > > --gc-sections -Bstatic -Ttext 0xc1080000 $UNDEF_SYM
> > > arch/arm/cpu/arm926ejs/start.o --start-group
> > > arch/arm/cpu/arm926ejs/davinci/libdavinci.o
> > > arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o
> > > board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o
> > > drivers/serial/libserial.o lib/libgeneric.o --end-group
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o
> > > -L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3
> > > -lgcc -Map u-boot-spl.map -o u-boot-spl
> > > board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd':
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:121:
> > > undefined reference to `eth_get_dev_by_index'
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:123:
> > > undefined reference to `eth_write_hwaddr'
> > > /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:126:
> > > undefined reference to `printf'
> > > make[1]: *** [/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl]
> > > Error 1
> > > make[1]: Leaving directory
> > > `/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl'
> > > make: *** [spl/u-boot-spl.bin] Error 2
> > >
> > > </snip>
> > >
> > > In the output above, one can see the environment variable $UNDEF_SYM
> > > being defined as the result of the following SPL makefile
> > > (spl/Makefile) target:
> > >
> > > GEN_UBOOT = \
> > > UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \
> > > sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
> > > cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__START) \
> > > --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
> > > -Map u-boot-spl.map -o u-boot-spl
> > >
> > > $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds
> > > $(GEN_UBOOT)
> > >
> > > For my target, $UNDEF_SYM expands to the following:
> > > -u__u_boot_cmd_mycmd
> > >
> > > As I understand it, this is to force the inclusion of the commands
> > > into the command table located in the special .u_boot_cmd section so
> > > that unreferenced commands are not linked out of the final U-Boot
> > > binary. However, I don't think that the inclusion of commands into the
> > > SPL is intended. Removing the $UNDEF_SYM variable from the SPL
> > > makefile resolves my build issues. I am planning on submitting a
> > > patch. Does anyone see a flaw in my thinking?
> > >
> > > Thanks,
> > > -- Tyler
> > > _______________________________________________
> > > U-Boot mailing list
> > > U-Boot at lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-07-26 23:02 ` Christian Riesch
@ 2012-08-02 23:16 ` Tyler Olmstead
2012-08-03 16:40 ` Daniel Schwierzeck
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Olmstead @ 2012-08-02 23:16 UTC (permalink / raw)
To: u-boot
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@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@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-08-02 23:16 ` Tyler Olmstead
@ 2012-08-03 16:40 ` Daniel Schwierzeck
2012-08-03 19:23 ` Tom Rini
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Schwierzeck @ 2012-08-03 16:40 UTC (permalink / raw)
To: u-boot
Hi Tyler,
2012/8/3 Tyler Olmstead <tyler.j.olmstead@gmail.com>:
> 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?
>
Most of the spl/Makefile code was copied and adapted from the top Makefile.
Unfortunately, we have not optimized the GEN_UBOOT macro so it still
has the UNDEF_SYM magic
which is obviously unnecessary.
I would suggest to remove the UNDEF_SYM magic.
Best regards,
Daniel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Board-specific commands unintentionally linked into SPL?
2012-08-03 16:40 ` Daniel Schwierzeck
@ 2012-08-03 19:23 ` Tom Rini
0 siblings, 0 replies; 9+ messages in thread
From: Tom Rini @ 2012-08-03 19:23 UTC (permalink / raw)
To: u-boot
On Fri, Aug 03, 2012 at 06:40:58PM +0200, Daniel Schwierzeck wrote:
> Hi Tyler,
>
> 2012/8/3 Tyler Olmstead <tyler.j.olmstead@gmail.com>:
>
> > 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?
> >
>
> Most of the spl/Makefile code was copied and adapted from the top Makefile.
> Unfortunately, we have not optimized the GEN_UBOOT macro so it still
> has the UNDEF_SYM magic
> which is obviously unnecessary.
>
> I would suggest to remove the UNDEF_SYM magic.
So, this is another one of the problems with relying on the linker to
discard stuff that's not needed. Current omap3_beagle:
Configuring for omap3_beagle board...
text data bss dec hex filename
326264 8460 266916 601640 92e28 omap3_beagle/u-boot
42856 1812 198020 242688 3b400 omap3_beagle/spl/u-boot-spl
Remove UNDEF_SYM, remove guards around the nandecc command in
arch/arm/cpu/armv7/omap3/board.c:
Configuring for omap3_beagle board...
text data bss dec hex filename
326274 8460 266904 601638 92e26 omap3_beagle/u-boot
43014 1812 198020 242846 3b49e omap3_beagle/spl/u-boot-spl
So we don't discard the command and SPL grows slightly (confirmed by
still removing UNDEF_SYM but putting the guards back on nandecc).
I don't know if we need to be more aggressive in linker commands or what
but I know there's lots of other code not being discarded too, from when
I poked at NAND before.
--
Tom
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-08-03 19:23 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-26 15:37 [U-Boot] Board-specific commands unintentionally linked into SPL? Tyler Olmstead
2012-07-26 17:03 ` Christian Riesch
2012-07-26 18:54 ` Tyler Olmstead
2012-07-26 20:41 ` Aneesh V
2012-07-26 23:02 ` Christian Riesch
2012-08-02 23:16 ` Tyler Olmstead
2012-08-03 16:40 ` Daniel Schwierzeck
2012-08-03 19:23 ` Tom Rini
2012-07-27 10:34 ` Lad, Prabhakar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.