On Thu, Apr 27, 2017 at 07:22:29AM +0000, B, Ravi wrote: > Hi Tom > > >> Since spl-dfu does not dfu-reset, there is no need of run_command_cli, > >> hence compiling out cli.c and cli_hush.c to reduce the spl-dfu memory > >> foot print. > >> > >> Signed-off-by: Ravi Babu <ravib...@ti.com> > [snip] > >> diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile index > >> 61f2b71..ef48f36 100644 > >> --- a/drivers/dfu/Makefile > >> +++ b/drivers/dfu/Makefile > >> @@ -6,8 +6,10 @@ > >> # > >> > >> obj-$(CONFIG_USB_FUNCTION_DFU) += dfu.o > >> +ifndef CONFIG_SPL_BUILD > >> obj-$(CONFIG_DFU_MMC) += dfu_mmc.o > >> obj-$(CONFIG_DFU_NAND) += dfu_nand.o > >> -obj-$(CONFIG_DFU_RAM) += dfu_ram.o > >> obj-$(CONFIG_DFU_SF) += dfu_sf.o > >> obj-$(CONFIG_DFU_TFTP) += dfu_tftp.o > >> +endif > >> +obj-$(CONFIG_DFU_RAM) += dfu_ram.o > > >We should discard at link time the unreachable parts here in SPL, no? > > Yes you are correct. > But what is happening here is, the CONFIG_DFU_<MMC/NAND/SF/TFTP> selected > through Kconfig/Menuconfig is applicable for both SPL and U-Boot. > Hence CONFIG_DFU_MMC/NAND/SF gets compiled for SPL as well, which needs > run_command(). Actually CONFIG_DFU_MMC/NAND/etc is not scoped for SPL-DFU. > As we have aligned, not to increase the SPL size, user shall use SPL-DFU > feature to boot to u-boot, then utilize the full featured DFU to flash > MMC/NAND/SF. > > I get undefined reference to common function run_command(), > "dfu_fill_entitiy_<mmc/nand/sf>" in driver/dfu/dfu.c. > The dfu.c is common for both SPL-DFU and U-boot.
OK. I think we need to introduce SPL_DFU_xxx Kconfig options, and use CONFIG_IS_ENABLED(DFU_xxx) so that we will get things enabled/disabled (and discarded) as needed. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
