Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
Hi Tyler, 2012/8/3 Tyler Olmstead tyler.j.olmst...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
On Fri, Aug 03, 2012 at 06:40:58PM +0200, Daniel Schwierzeck wrote: Hi Tyler, 2012/8/3 Tyler Olmstead tyler.j.olmst...@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... textdata bss dec hex filename 3262648460 266916 601640 92e28 omap3_beagle/u-boot 428561812 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... textdata bss dec hex filename 3262748460 266904 601638 92e26 omap3_beagle/u-boot 430141812 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
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.rie...@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.rie...@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.olmst...@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
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.rie...@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.olmst...@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=13274854893 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 0xc108 $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':
[U-Boot] Board-specific commands unintentionally linked into SPL?
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 0xc108 $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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
[cc'd Prabhakar Lad, Tom Rini, and Scott Wood] Tyler, On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead tyler.j.olmst...@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=13274854893 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 0xc108 $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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
Hi Christian, On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch christian.rie...@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.olmst...@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=13274854893 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 0xc108 $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'
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
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.rie...@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.olmst...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
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.rie...@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.olmst...@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@lists.denx.de http://lists.denx.de/mailman/**listinfo/u-boothttp://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
