* [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 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
* [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
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.