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

Lad, Prabhakar prabhakar.lad at ti.com
Fri Jul 27 12:34:30 CEST 2012


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 at omicron.at> wrote:
> >
> > [cc'd Prabhakar Lad, Tom Rini, and Scott Wood]
> >
> > Tyler,
> >
> > On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead
> > <tyler.j.olmstead at gmail.com> wrote:
> > > Hi all,
> > >
> > > I have encountered some issues adding a board-specific command to the
> > > board file of a project I have been working on. Specifically, after
> > > adding a U-Boot shell command to my board file, I have been seeing
> > > link-stage failures when attempting to build SPL.
> >
> > It's hard to tell without having your code, but I think this problem
> > was already discussed in [1]. However I do not remember how Prabhakar
> > solved it in the end.
> 
  #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
> 



More information about the U-Boot mailing list