[U-Boot] [RFC PATCH 0/5] SPL: DFU Support in SPL

[U-Boot] [RFC PATCH 0/5] SPL: DFU Support in SPL

[Ravi Babu]

Traditionally the DFU support is available only
as part 2nd stage boot loader(u-boot) and DFU
is not supported in SPL.

The SPL-DFU feature is useful for boards which has
only USB inteface and do not have external interface
like ethernet or MMC/SD to boot the board.

This patch adds DFU support in SPL to flash binary
images to factory or bare-metal boards to memory 
devices like SPI, eMMC, MMC/SD card using
USB interface. 
As a reference, refer to application note [3] on SPL-DFU
support based on 2014.07 u-boot.

Note: I could not find better option to isolate dfu source
to include/exclude in Makefile when SPL-DFU feature 
enabled/disabled, please suggest any better option.

Tested on dra7xx SoCs family. 
[1] is EVM console output with SPL-DFU/SPI enabled.
[2] is ubuntu host console output.

references:
[1] http://pastebin.ubuntu.com/16730701/
[2] http://pastebin.ubuntu.com/16730765/
[3] http://www.ti.com/lit/an/sprac33/sprac33.pdf 

Ravi Babu (5):
  spl: dfu: add dfu support in SPL
  spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU
  spl: dfu: adding dfu support functions for SPL-DFU
  dfu: spl: add generic spl-dfu function in common-spl
  dra7x: spl: dfu: adding SPL-DFU support for dra7x platform

 Kconfig                           |   40 +++++++++++++++++++++++++++++++++++++
 board/ti/dra7xx/evm.c             |   20 +++++++++++++++++++
 cmd/Makefile                      |   20 ++++++++++++++++++-
 common/Makefile                   |   32 ++++++++++++++++++++---------
 common/command.c                  |    2 +-
 common/spl/spl.c                  |   11 ++++++++++
 drivers/dfu/dfu.c                 |   28 ++++++++++++++++++++++++++
 drivers/dfu/dfu_mmc.c             |   28 ++++++++++++++++++++++++++
 drivers/mmc/Makefile              |    3 +--
 drivers/mmc/mmc_private.h         |    2 +-
 fs/Makefile                       |   12 ++++++++++-
 include/configs/dra7xx_evm.h      |    3 +--
 include/configs/ti_omap5_common.h |    2 --
 include/dfu.h                     |    8 ++++++++
 include/spl.h                     |    1 +
 scripts/Makefile.spl              |   13 ++++++++++++
 16 files changed, 206 insertions(+), 19 deletions(-)

-- 
1.7.9.5

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Ravi Babu]

Traditionally the DFU support is available only
as part 2nd stage boot loader(u-boot) and DFU
is not supported in SPL.

The SPL-DFU feature is useful for boards which has
only USB inteface and do not have external interface
like ethernet or MMC/SD to boot the board.

This patch add DFU support in SPL to flash boot inital
binary images to factory or bare-metal boards to
memory devices like SPI, eMMC, MMC/SD card using
USB interface.

This SPL-DFU support can be enabled through
Menuconfig->Boot Images->Enable SPL-DFU support

Signed-off-by: Ravi Babu <ravibabu@ti.com>
---
 Kconfig                   |   40 ++++++++++++++++++++++++++++++++++++++++
 cmd/Makefile              |   11 ++++++++++-
 common/Makefile           |   28 ++++++++++++++++++++--------
 common/command.c          |    2 +-
 drivers/mmc/Makefile      |    3 +--
 drivers/mmc/mmc_private.h |    2 +-
 scripts/Makefile.spl      |   13 +++++++++++++
 7 files changed, 86 insertions(+), 13 deletions(-)

diff --git a/Kconfig b/Kconfig
index f53759a..8c033d0 100644
--- a/Kconfig
+++ b/Kconfig
@@ -285,6 +285,46 @@ config SPL_LOAD_FIT
 	  particular it can handle selecting from multiple device tree
 	  and passing the correct one to U-Boot.
 
+config SPL_DFU
+	bool "Enable SPL with DFU to load binaries to bootdevices using USB"
+	depends on USB && CMD_DFU
+	help
+	  Normally with the SPL only image does not have capability to
+	  load the binaries or boot images to boot devices like eMMC,SPI,etc.
+	  This feature enables the DFU (Device Firmware Upgarde) in SPL with
+	  eMMC device as default bootdevice. The ROM code will load and execute
+	  the SPL/MLO dfu image. The user can flash the binaries to selected
+	  dfu device partition from host-pc using dfu-utils.
+		This feature will be useful to flash the binaries to factory
+	  or bare-metal boards using USB interface.
+
+choice
+	bool "DFU device selection"
+	depends on CMD_DFU && SPL_DFU
+
+config SPL_DFU_EMMC
+	bool "eMMC device"
+	depends on CMD_DFU && SPL_DFU
+	help
+	 select eMMC memory device for flashing binary images to
+	 the selection partition using DFU.
+
+config SPL_DFU_MMC
+	bool "MMC/SD device"
+	depends on CMD_DFU && SPL_DFU
+	help
+	 select MMC/SD memory device for flashing binary images to
+	 the selection partition using DFU.
+
+config SPL_DFU_SF
+	bool "SPI device"
+	depends on CMD_DFU && SPL_DFU
+	help
+	 select SPI flash memory device for flashing binary images to
+	 the selection partition using DFU.
+
+endchoice
+
 config SYS_CLK_FREQ
 	depends on ARC || ARCH_SUNXI
 	int "CPU clock frequency"
diff --git a/cmd/Makefile b/cmd/Makefile
index f95759e..139189e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -5,6 +5,13 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+CONFIG_INC_COMMON=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_COMMON=n
+endif
+endif
+
 ifndef CONFIG_SPL_BUILD
 # core command
 obj-y += boot.o
@@ -146,7 +153,6 @@ obj-$(CONFIG_CMD_SPL) += spl.o
 obj-$(CONFIG_CMD_ZIP) += zip.o
 obj-$(CONFIG_CMD_ZFS) += zfs.o
 
-obj-$(CONFIG_CMD_DFU) += dfu.o
 obj-$(CONFIG_CMD_GPT) += gpt.o
 obj-$(CONFIG_CMD_ETHSW) += ethsw.o
 
@@ -161,6 +167,9 @@ obj-$(CONFIG_CMD_SCSI) += scsi.o
 endif
 endif # CONFIG_SPL_BUILD
 
+ifeq ($(CONFIG_INC_COMMON),y)
+obj-$(CONFIG_CMD_DFU) += dfu.o
+endif
 obj-$(CONFIG_CMD_BLOB) += blob.o
 
 # core command
diff --git a/common/Makefile b/common/Makefile
index b23f312..3576fac 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -6,15 +6,31 @@
 #
 
 # core
-ifndef CONFIG_SPL_BUILD
-obj-y += init/
-obj-y += main.o
-obj-y += exports.o
+
+CONFIG_INC_COMMON=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_COMMON=n
+endif
+endif
+
+ifeq ($(CONFIG_INC_COMMON),y)
 obj-y += hash.o
 ifdef CONFIG_SYS_HUSH_PARSER
 obj-y += cli_hush.o
 endif
 
+obj-y += env_attr.o
+obj-y += env_callback.o
+obj-y += env_flags.o
+obj-y += cli.o
+endif
+
+ifndef CONFIG_SPL_BUILD
+obj-y += init/
+obj-y += main.o
+obj-y += exports.o
+
 # This option is not just y/n - it can have a numeric value
 ifdef CONFIG_BOOTDELAY
 obj-y += autoboot.o
@@ -34,9 +50,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o
 
 # environment
-obj-y += env_attr.o
-obj-y += env_callback.o
-obj-y += env_flags.o
 obj-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
 extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
@@ -153,7 +166,6 @@ endif
 # We always have this since drivers/ddr/fs/interactive.c needs it
 obj-$(CONFIG_CMDLINE) += cli_simple.o
 
-obj-y += cli.o
 obj-$(CONFIG_CMDLINE) += cli_readline.o
 obj-y += command.o
 obj-y += s_record.o
diff --git a/common/command.c b/common/command.c
index e5d9b9c..d1c049c 100644
--- a/common/command.c
+++ b/common/command.c
@@ -520,7 +520,7 @@ enum command_ret_t cmd_process(int flag, int argc, char * const argv[],
 	if (argc > cmdtp->maxargs)
 		rc = CMD_RET_USAGE;
 
-#if defined(CONFIG_CMD_BOOTD)
+#if defined(CONFIG_CMD_BOOTD) && !defined(CONFIG_SPL_BUILD)
 	/* avoid "bootd" recursion */
 	else if (cmdtp->cmd == do_bootd) {
 		if (flag & CMD_FLAG_BOOTD) {
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 585aaf3..7abac59 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -43,11 +43,10 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
 obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
 obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
 obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
+obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
-else
-obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
 endif
 obj-$(CONFIG_PIC32_SDHCI) += pic32_sdhci.o
 obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
diff --git a/drivers/mmc/mmc_private.h b/drivers/mmc/mmc_private.h
index d3f6bfe..d221362 100644
--- a/drivers/mmc/mmc_private.h
+++ b/drivers/mmc/mmc_private.h
@@ -20,7 +20,7 @@ extern int mmc_set_blocklen(struct mmc *mmc, int len);
 void mmc_adapter_card_type_ident(void);
 #endif
 
-#ifndef CONFIG_SPL_BUILD
+#ifdef CONFIG_GENERIC_MMC
 
 unsigned long mmc_berase(struct blk_desc *block_dev, lbaint_t start,
 			 lbaint_t blkcnt);
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ec8d8f1..6e9a589 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -35,6 +35,13 @@ else
 SPL_BIN := u-boot-spl
 endif
 
+CONFIG_INC_COMMON=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_COMMON=n
+endif
+endif
+
 include $(srctree)/config.mk
 include $(srctree)/arch/$(ARCH)/Makefile
 
@@ -56,6 +63,12 @@ libs-y += common/init/
 libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/
 libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/
 libs-y += drivers/
+ifeq ($(CONFIG_INC_COMMON),y)
+libs-y += drivers/dfu/
+libs-y += drivers/usb/gadget/
+libs-y += drivers/usb/gadget/udc/
+libs-y += drivers/usb/dwc3/
+endif
 libs-y += dts/
 libs-y += fs/
 libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
-- 
1.7.9.5

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

Thanks for adding this functionality to DFU.

Please find below organizational tips:

- Please use 'patman' (./tools/patman/patman) tool when sending patches
  (it adds me automatically to CC).

- Would it be hard to add SPL-DFU support also to BeagleBone
  Black(am335x) (BBB) board? I'm asking since BBB is far more pervasive
  than dra7x (and I might be able to cover SPL-DFU easily with our
  new ptest (DFU) test suite).

> Traditionally the DFU support is available only
> as part 2nd stage boot loader(u-boot) and DFU
> is not supported in SPL.
> 
> The SPL-DFU feature is useful for boards which has
> only USB inteface and do not have external interface
> like ethernet or MMC/SD to boot the board.
> 
> This patch add DFU support in SPL to flash boot inital
> binary images to factory or bare-metal boards to
> memory devices like SPI, eMMC, MMC/SD card using
> USB interface.
> 
> This SPL-DFU support can be enabled through
> Menuconfig->Boot Images->Enable SPL-DFU support
> 
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>  Kconfig                   |   40
> ++++++++++++++++++++++++++++++++++++++++ cmd/Makefile
> |   11 ++++++++++- common/Makefile           |   28
> ++++++++++++++++++++-------- common/command.c          |    2 +-
>  drivers/mmc/Makefile      |    3 +--
>  drivers/mmc/mmc_private.h |    2 +-
>  scripts/Makefile.spl      |   13 +++++++++++++
>  7 files changed, 86 insertions(+), 13 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index f53759a..8c033d0 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -285,6 +285,46 @@ config SPL_LOAD_FIT
>  	  particular it can handle selecting from multiple device
> tree and passing the correct one to U-Boot.
>  
> +config SPL_DFU
> +	bool "Enable SPL with DFU to load binaries to bootdevices
> using USB"
> +	depends on USB && CMD_DFU
> +	help
> +	  Normally with the SPL only image does not have capability
> to
> +	  load the binaries or boot images to boot devices like
> eMMC,SPI,etc.
> +	  This feature enables the DFU (Device Firmware Upgarde) in
> SPL with
> +	  eMMC device as default bootdevice. The ROM code will load
> and execute
> +	  the SPL/MLO dfu image. The user can flash the binaries to
> selected
> +	  dfu device partition from host-pc using dfu-utils.
> +		This feature will be useful to flash the binaries to
> factory
> +	  or bare-metal boards using USB interface.
> +
> +choice
> +	bool "DFU device selection"
> +	depends on CMD_DFU && SPL_DFU
> +
> +config SPL_DFU_EMMC
> +	bool "eMMC device"
> +	depends on CMD_DFU && SPL_DFU
> +	help
> +	 select eMMC memory device for flashing binary images to
> +	 the selection partition using DFU.
> +
> +config SPL_DFU_MMC
> +	bool "MMC/SD device"
> +	depends on CMD_DFU && SPL_DFU
> +	help
> +	 select MMC/SD memory device for flashing binary images to
> +	 the selection partition using DFU.
> +
> +config SPL_DFU_SF
> +	bool "SPI device"
> +	depends on CMD_DFU && SPL_DFU
> +	help
> +	 select SPI flash memory device for flashing binary images to
> +	 the selection partition using DFU.
> +
> +endchoice
> +
>  config SYS_CLK_FREQ
>  	depends on ARC || ARCH_SUNXI
>  	int "CPU clock frequency"
> diff --git a/cmd/Makefile b/cmd/Makefile
> index f95759e..139189e 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -5,6 +5,13 @@
>  # SPDX-License-Identifier:	GPL-2.0+
>  #
>  
> +CONFIG_INC_COMMON=y

I think that we should not introduce any extra "common" defines.

I'd be more than happy if you would try to implement DFU support
according to SPL framework (./doc/README.spl).

As an example we could use ./common/spl/spl_{mmc|usb}.c files.

> +ifdef CONFIG_SPL_BUILD
> +ifndef CONFIG_SPL_DFU
> +CONFIG_INC_COMMON=n
> +endif
> +endif
> +
>  ifndef CONFIG_SPL_BUILD
>  # core command
>  obj-y += boot.o
> @@ -146,7 +153,6 @@ obj-$(CONFIG_CMD_SPL) += spl.o
>  obj-$(CONFIG_CMD_ZIP) += zip.o
>  obj-$(CONFIG_CMD_ZFS) += zfs.o
>  
> -obj-$(CONFIG_CMD_DFU) += dfu.o
>  obj-$(CONFIG_CMD_GPT) += gpt.o
>  obj-$(CONFIG_CMD_ETHSW) += ethsw.o
>  
> @@ -161,6 +167,9 @@ obj-$(CONFIG_CMD_SCSI) += scsi.o
>  endif
>  endif # CONFIG_SPL_BUILD
>  
> +ifeq ($(CONFIG_INC_COMMON),y)
> +obj-$(CONFIG_CMD_DFU) += dfu.o

It seems like other subsystems used enabled in SPL do not need to add
whole commands to SPL.

It IMHO seems like an overkill to support all, full blown DFU command
interface in SPL. For other IP blocks (like USB, MMC) only small subset
of commands is provided.

> +endif
>  obj-$(CONFIG_CMD_BLOB) += blob.o
>  
>  # core command
> diff --git a/common/Makefile b/common/Makefile
> index b23f312..3576fac 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -6,15 +6,31 @@
>  #
>  
>  # core
> -ifndef CONFIG_SPL_BUILD
> -obj-y += init/
> -obj-y += main.o
> -obj-y += exports.o
> +
> +CONFIG_INC_COMMON=y
> +ifdef CONFIG_SPL_BUILD
> +ifndef CONFIG_SPL_DFU
> +CONFIG_INC_COMMON=n
> +endif
> +endif
> +
> +ifeq ($(CONFIG_INC_COMMON),y)
>  obj-y += hash.o
>  ifdef CONFIG_SYS_HUSH_PARSER
>  obj-y += cli_hush.o
>  endif
>  
> +obj-y += env_attr.o
> +obj-y += env_callback.o
> +obj-y += env_flags.o
> +obj-y += cli.o
> +endif
> +
> +ifndef CONFIG_SPL_BUILD
> +obj-y += init/
> +obj-y += main.o
> +obj-y += exports.o
> +
>  # This option is not just y/n - it can have a numeric value
>  ifdef CONFIG_BOOTDELAY
>  obj-y += autoboot.o
> @@ -34,9 +50,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
>  obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o
>  
>  # environment
> -obj-y += env_attr.o
> -obj-y += env_callback.o
> -obj-y += env_flags.o
>  obj-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
>  obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
>  extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
> @@ -153,7 +166,6 @@ endif
>  # We always have this since drivers/ddr/fs/interactive.c needs it
>  obj-$(CONFIG_CMDLINE) += cli_simple.o
>  
> -obj-y += cli.o
>  obj-$(CONFIG_CMDLINE) += cli_readline.o
>  obj-y += command.o
>  obj-y += s_record.o
> diff --git a/common/command.c b/common/command.c
> index e5d9b9c..d1c049c 100644
> --- a/common/command.c
> +++ b/common/command.c
> @@ -520,7 +520,7 @@ enum command_ret_t cmd_process(int flag, int
> argc, char * const argv[], if (argc > cmdtp->maxargs)
>  		rc = CMD_RET_USAGE;
>  
> -#if defined(CONFIG_CMD_BOOTD)
> +#if defined(CONFIG_CMD_BOOTD) && !defined(CONFIG_SPL_BUILD)
>  	/* avoid "bootd" recursion */
>  	else if (cmdtp->cmd == do_bootd) {
>  		if (flag & CMD_FLAG_BOOTD) {
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 585aaf3..7abac59 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -43,11 +43,10 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
>  obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
>  obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
>  obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
> +obj-$(CONFIG_GENERIC_MMC) += mmc_write.o

I'm wondering if this could be added/extended at ./common/spl/ code?

>  
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
> -else
> -obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
>  endif
>  obj-$(CONFIG_PIC32_SDHCI) += pic32_sdhci.o
>  obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
> diff --git a/drivers/mmc/mmc_private.h b/drivers/mmc/mmc_private.h
> index d3f6bfe..d221362 100644
> --- a/drivers/mmc/mmc_private.h
> +++ b/drivers/mmc/mmc_private.h
> @@ -20,7 +20,7 @@ extern int mmc_set_blocklen(struct mmc *mmc, int
> len); void mmc_adapter_card_type_ident(void);
>  #endif
>  
> -#ifndef CONFIG_SPL_BUILD
> +#ifdef CONFIG_GENERIC_MMC
>  
>  unsigned long mmc_berase(struct blk_desc *block_dev, lbaint_t start,
>  			 lbaint_t blkcnt);
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index ec8d8f1..6e9a589 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -35,6 +35,13 @@ else
>  SPL_BIN := u-boot-spl
>  endif
>  
> +CONFIG_INC_COMMON=y
> +ifdef CONFIG_SPL_BUILD
> +ifndef CONFIG_SPL_DFU
> +CONFIG_INC_COMMON=n
> +endif
> +endif
> +
>  include $(srctree)/config.mk
>  include $(srctree)/arch/$(ARCH)/Makefile
>  
> @@ -56,6 +63,12 @@ libs-y += common/init/
>  libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/
>  libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/
>  libs-y += drivers/
> +ifeq ($(CONFIG_INC_COMMON),y)
> +libs-y += drivers/dfu/
> +libs-y += drivers/usb/gadget/
> +libs-y += drivers/usb/gadget/udc/
> +libs-y += drivers/usb/dwc3/
> +endif
>  libs-y += dts/
>  libs-y += fs/
>  libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz 

> On 30-May-2016, at 5:24 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 
> Hi Ravi,
> 
> Thanks for adding this functionality to DFU.
> 
> Please find below organizational tips:
> 
> - Please use 'patman' (./tools/patman/patman) tool when sending patches
>  (it adds me automatically to CC).
> 
> - Would it be hard to add SPL-DFU support also to BeagleBone
>  Black(am335x) (BBB) board? I'm asking since BBB is far more pervasive
>  than dra7x (and I might be able to cover SPL-DFU easily with our
>  new ptest (DFU) test suite).
> 

It's possible to extend this for other platform, but SPL size would be 152k.

>> Traditionally the DFU support is available only
>> as part 2nd stage boot loader(u-boot) and DFU
>> is not supported in SPL.
>> 
>> The SPL-DFU feature is useful for boards which has
>> only USB inteface and do not have external interface
>> like ethernet or MMC/SD to boot the board.
>> 
>> This patch add DFU support in SPL to flash boot inital
>> binary images to factory or bare-metal boards to
>> memory devices like SPI, eMMC, MMC/SD card using
>> USB interface.
>> 
>> This SPL-DFU support can be enabled through
>> Menuconfig->Boot Images->Enable SPL-DFU support
>> 
>> Signed-off-by: Ravi Babu <ravibabu@ti.com>
>> ---
>> Kconfig                   |   40
>> ++++++++++++++++++++++++++++++++++++++++ cmd/Makefile
>> |   11 ++++++++++- common/Makefile           |   28
>> ++++++++++++++++++++-------- common/command.c          |    2 +-
>> drivers/mmc/Makefile      |    3 +--
>> drivers/mmc/mmc_private.h |    2 +-
>> scripts/Makefile.spl      |   13 +++++++++++++
>> 7 files changed, 86 insertions(+), 13 deletions(-)
>> 
>> diff --git a/Kconfig b/Kconfig
>> index f53759a..8c033d0 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -285,6 +285,46 @@ config SPL_LOAD_FIT
>>      particular it can handle selecting from multiple device
>> tree and passing the correct one to U-Boot.
>> 
>> +config SPL_DFU
>> +    bool "Enable SPL with DFU to load binaries to bootdevices
>> using USB"
>> +    depends on USB && CMD_DFU
>> +    help
>> +      Normally with the SPL only image does not have capability
>> to
>> +      load the binaries or boot images to boot devices like
>> eMMC,SPI,etc.
>> +      This feature enables the DFU (Device Firmware Upgarde) in
>> SPL with
>> +      eMMC device as default bootdevice. The ROM code will load
>> and execute
>> +      the SPL/MLO dfu image. The user can flash the binaries to
>> selected
>> +      dfu device partition from host-pc using dfu-utils.
>> +        This feature will be useful to flash the binaries to
>> factory
>> +      or bare-metal boards using USB interface.
>> +
>> +choice
>> +    bool "DFU device selection"
>> +    depends on CMD_DFU && SPL_DFU
>> +
>> +config SPL_DFU_EMMC
>> +    bool "eMMC device"
>> +    depends on CMD_DFU && SPL_DFU
>> +    help
>> +     select eMMC memory device for flashing binary images to
>> +     the selection partition using DFU.
>> +
>> +config SPL_DFU_MMC
>> +    bool "MMC/SD device"
>> +    depends on CMD_DFU && SPL_DFU
>> +    help
>> +     select MMC/SD memory device for flashing binary images to
>> +     the selection partition using DFU.
>> +
>> +config SPL_DFU_SF
>> +    bool "SPI device"
>> +    depends on CMD_DFU && SPL_DFU
>> +    help
>> +     select SPI flash memory device for flashing binary images to
>> +     the selection partition using DFU.
>> +
>> +endchoice
>> +
>> config SYS_CLK_FREQ
>>    depends on ARC || ARCH_SUNXI
>>    int "CPU clock frequency"
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index f95759e..139189e 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -5,6 +5,13 @@
>> # SPDX-License-Identifier:    GPL-2.0+
>> #
>> 
>> +CONFIG_INC_COMMON=y
> 
> I think that we should not introduce any extra "common" defines.
> 
> I'd be more than happy if you would try to implement DFU support
> according to SPL framework (./doc/README.spl).
> 
> As an example we could use ./common/spl/spl_{mmc|usb}.c files.
> 

I want to avoid such defines, but could not find best way, the problem there are many dependent modules for DFU which is only defined for u-boot.

>> +ifdef CONFIG_SPL_BUILD
>> +ifndef CONFIG_SPL_DFU
>> +CONFIG_INC_COMMON=n
>> +endif
>> +endif
>> +
>> ifndef CONFIG_SPL_BUILD
>> # core command
>> obj-y += boot.o
>> @@ -146,7 +153,6 @@ obj-$(CONFIG_CMD_SPL) += spl.o
>> obj-$(CONFIG_CMD_ZIP) += zip.o
>> obj-$(CONFIG_CMD_ZFS) += zfs.o
>> 
>> -obj-$(CONFIG_CMD_DFU) += dfu.o
>> obj-$(CONFIG_CMD_GPT) += gpt.o
>> obj-$(CONFIG_CMD_ETHSW) += ethsw.o
>> 
>> @@ -161,6 +167,9 @@ obj-$(CONFIG_CMD_SCSI) += scsi.o
>> endif
>> endif # CONFIG_SPL_BUILD
>> 
>> +ifeq ($(CONFIG_INC_COMMON),y)
>> +obj-$(CONFIG_CMD_DFU) += dfu.o
> 
> It seems like other subsystems used enabled in SPL do not need to add
> whole commands to SPL.
> 
> It IMHO seems like an overkill to support all, full blown DFU command
> interface in SPL. For other IP blocks (like USB, MMC) only small subset
> of commands is provided.
> 
>> +endif
>> obj-$(CONFIG_CMD_BLOB) += blob.o
>> 
>> # core command
>> diff --git a/common/Makefile b/common/Makefile
>> index b23f312..3576fac 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -6,15 +6,31 @@
>> #
>> 
>> # core
>> -ifndef CONFIG_SPL_BUILD
>> -obj-y += init/
>> -obj-y += main.o
>> -obj-y += exports.o
>> +
>> +CONFIG_INC_COMMON=y
>> +ifdef CONFIG_SPL_BUILD
>> +ifndef CONFIG_SPL_DFU
>> +CONFIG_INC_COMMON=n
>> +endif
>> +endif
>> +
>> +ifeq ($(CONFIG_INC_COMMON),y)
>> obj-y += hash.o
>> ifdef CONFIG_SYS_HUSH_PARSER
>> obj-y += cli_hush.o
>> endif
>> 
>> +obj-y += env_attr.o
>> +obj-y += env_callback.o
>> +obj-y += env_flags.o
>> +obj-y += cli.o
>> +endif
>> +
>> +ifndef CONFIG_SPL_BUILD
>> +obj-y += init/
>> +obj-y += main.o
>> +obj-y += exports.o
>> +
>> # This option is not just y/n - it can have a numeric value
>> ifdef CONFIG_BOOTDELAY
>> obj-y += autoboot.o
>> @@ -34,9 +50,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
>> obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o
>> 
>> # environment
>> -obj-y += env_attr.o
>> -obj-y += env_callback.o
>> -obj-y += env_flags.o
>> obj-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
>> obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
>> extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
>> @@ -153,7 +166,6 @@ endif
>> # We always have this since drivers/ddr/fs/interactive.c needs it
>> obj-$(CONFIG_CMDLINE) += cli_simple.o
>> 
>> -obj-y += cli.o
>> obj-$(CONFIG_CMDLINE) += cli_readline.o
>> obj-y += command.o
>> obj-y += s_record.o
>> diff --git a/common/command.c b/common/command.c
>> index e5d9b9c..d1c049c 100644
>> --- a/common/command.c
>> +++ b/common/command.c
>> @@ -520,7 +520,7 @@ enum command_ret_t cmd_process(int flag, int
>> argc, char * const argv[], if (argc > cmdtp->maxargs)
>>        rc = CMD_RET_USAGE;
>> 
>> -#if defined(CONFIG_CMD_BOOTD)
>> +#if defined(CONFIG_CMD_BOOTD) && !defined(CONFIG_SPL_BUILD)
>>    /* avoid "bootd" recursion */
>>    else if (cmdtp->cmd == do_bootd) {
>>        if (flag & CMD_FLAG_BOOTD) {
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index 585aaf3..7abac59 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -43,11 +43,10 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
>> obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
>> obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
>> obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
>> +obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
> 
> I'm wondering if this could be added/extended at ./common/spl/ code?
> 

I will check.
>> 
>> ifdef CONFIG_SPL_BUILD
>> obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
>> -else
>> -obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
>> endif
>> obj-$(CONFIG_PIC32_SDHCI) += pic32_sdhci.o
>> obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
>> diff --git a/drivers/mmc/mmc_private.h b/drivers/mmc/mmc_private.h
>> index d3f6bfe..d221362 100644
>> --- a/drivers/mmc/mmc_private.h
>> +++ b/drivers/mmc/mmc_private.h
>> @@ -20,7 +20,7 @@ extern int mmc_set_blocklen(struct mmc *mmc, int
>> len); void mmc_adapter_card_type_ident(void);
>> #endif
>> 
>> -#ifndef CONFIG_SPL_BUILD
>> +#ifdef CONFIG_GENERIC_MMC
>> 
>> unsigned long mmc_berase(struct blk_desc *block_dev, lbaint_t start,
>>             lbaint_t blkcnt);
>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
>> index ec8d8f1..6e9a589 100644
>> --- a/scripts/Makefile.spl
>> +++ b/scripts/Makefile.spl
>> @@ -35,6 +35,13 @@ else
>> SPL_BIN := u-boot-spl
>> endif
>> 
>> +CONFIG_INC_COMMON=y
>> +ifdef CONFIG_SPL_BUILD
>> +ifndef CONFIG_SPL_DFU
>> +CONFIG_INC_COMMON=n
>> +endif
>> +endif
>> +
>> include $(srctree)/config.mk
>> include $(srctree)/arch/$(ARCH)/Makefile
>> 
>> @@ -56,6 +63,12 @@ libs-y += common/init/
>> libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/
>> libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/
>> libs-y += drivers/
>> +ifeq ($(CONFIG_INC_COMMON),y)
>> +libs-y += drivers/dfu/
>> +libs-y += drivers/usb/gadget/
>> +libs-y += drivers/usb/gadget/udc/
>> +libs-y += drivers/usb/dwc3/
>> +endif
>> libs-y += dts/
>> libs-y += fs/
>> libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
> 
> 
> 

Regards
Ravi
> -- 
> Best regards,
> 
> Lukasz Majewski
> 
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz 
> 
> > On 30-May-2016, at 5:24 PM, Lukasz Majewski
> > <l.majewski@samsung.com> wrote:
> > 
> > Hi Ravi,
> > 
> > Thanks for adding this functionality to DFU.
> > 
> > Please find below organizational tips:
> > 
> > - Please use 'patman' (./tools/patman/patman) tool when sending
> > patches (it adds me automatically to CC).
> > 
> > - Would it be hard to add SPL-DFU support also to BeagleBone
> >  Black(am335x) (BBB) board? I'm asking since BBB is far more
> > pervasive than dra7x (and I might be able to cover SPL-DFU easily
> > with our new ptest (DFU) test suite).
> >   
> 
> It's possible to extend this for other platform, but SPL size would
> be 152k.

That was my point to reduce the size as much as possible and only
provide minimal functionality to fit the bill.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Lukasz

>> Hi Lukasz
>> 
>> > On 30-May-2016, at 5:24 PM, Lukasz Majewski <l.majewski@samsung.com> 
>> > wrote:
>> > 
>> > Hi Ravi,
>> > 
>> > Thanks for adding this functionality to DFU.
>> > 
>> > Please find below organizational tips:
>> > 
>> > - Please use 'patman' (./tools/patman/patman) tool when sending 
>> > patches (it adds me automatically to CC). 
>> > 
>> > - Would it be hard to add SPL-DFU support also to BeagleBone
>> >  Black(am335x) (BBB) board? I'm asking since BBB is far more 
>> > pervasive than dra7x (and I might be able to cover SPL-DFU easily 
>> > with our new ptest (DFU) test suite).
>> >   
>> 
>> It's possible to extend this for other platform, but SPL size would be 
>> 152k.

>That was my point to reduce the size as much as possible and only provide minimal functionality to fit the bill.

Since DFU is tighly coupled to u-boot infrastructure , the size will increase due to multiple dependencies to compile u-boot DFU source in SPL.
Let me re-think on possibility and come back.

Regards
Ravi

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Lukasz
> 
> >> Hi Lukasz
> >> 
> >> > On 30-May-2016, at 5:24 PM, Lukasz Majewski
> >> > <l.majewski@samsung.com> wrote:
> >> > 
> >> > Hi Ravi,
> >> > 
> >> > Thanks for adding this functionality to DFU.
> >> > 
> >> > Please find below organizational tips:
> >> > 
> >> > - Please use 'patman' (./tools/patman/patman) tool when sending 
> >> > patches (it adds me automatically to CC). 
> >> > 
> >> > - Would it be hard to add SPL-DFU support also to BeagleBone
> >> >  Black(am335x) (BBB) board? I'm asking since BBB is far more 
> >> > pervasive than dra7x (and I might be able to cover SPL-DFU
> >> > easily with our new ptest (DFU) test suite).
> >> >   
> >> 
> >> It's possible to extend this for other platform, but SPL size
> >> would be 152k.
> 
> >That was my point to reduce the size as much as possible and only
> >provide minimal functionality to fit the bill.
> 
> Since DFU is tighly coupled to u-boot infrastructure , the size will
> increase due to multiple dependencies to compile u-boot DFU source in
> SPL. Let me re-think on possibility and come back.

If you would need any assistance, please let me know (I don't have
dra7x, but I do have Beagle Bone Black).

> 
> Regards
> Ravi
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lucasz

Thanks for active support.

>> >> > 
>> >> > - Would it be hard to add SPL-DFU support also to BeagleBone
>> >> >  Black(am335x) (BBB) board? I'm asking since BBB is far more 
>> >> > pervasive than dra7x (and I might be able to cover SPL-DFU easily 
>> >> > with our new ptest (DFU) test suite).
>> >> >   
>> >> 
>> >> It's possible to extend this for other platform, but SPL size would 
>> >> be 152k.
>> 
>> >That was my point to reduce the size as much as possible and only 
>> >provide minimal functionality to fit the bill.
>> 
>> Since DFU is tighly coupled to u-boot infrastructure , the size will 
>> increase due to multiple dependencies to compile u-boot DFU source in 
>> SPL. Let me re-think on possibility and come back.

>If you would need any assistance, please let me know (I don't have dra7x, but I do have Beagle Bone Black).

The current implementation of dfu (drivers/dfu/dfu.c) relies on environment modules (getenv,setenv), and hash algo methods.
The mandatory modules for DFU includes USB(dwc3/musb), gadget, drivers/dfu, hash, environ modules.
Added to this mmc/sf support, with filesystem fat/ext4 would definitely increase the size.

I have tried minimal subset adding DFU-SF serial flash support alone in SPL, this itself increases SPL size to 30K+ (SPL size approx. 107KB for dra7x). 

But beagle bone IRAM would be around 64KB right? Definetly this will not fit.

Can we enable this feature for platform with minimum SRAM size of 160KB.
So SPL-DFU cannot be supported for platform less than 160KB (like am335x).

Any suggestion ?

Regards
Ravi 

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lucasz
> 
> Thanks for active support.
> 
> >> >> > 
> >> >> > - Would it be hard to add SPL-DFU support also to BeagleBone
> >> >> >  Black(am335x) (BBB) board? I'm asking since BBB is far more 
> >> >> > pervasive than dra7x (and I might be able to cover SPL-DFU
> >> >> > easily with our new ptest (DFU) test suite).
> >> >> >   
> >> >> 
> >> >> It's possible to extend this for other platform, but SPL size
> >> >> would be 152k.
> >> 
> >> >That was my point to reduce the size as much as possible and only 
> >> >provide minimal functionality to fit the bill.
> >> 
> >> Since DFU is tighly coupled to u-boot infrastructure , the size
> >> will increase due to multiple dependencies to compile u-boot DFU
> >> source in SPL. Let me re-think on possibility and come back.
> 
> >If you would need any assistance, please let me know (I don't have
> >dra7x, but I do have Beagle Bone Black).
> 
> The current implementation of dfu (drivers/dfu/dfu.c) relies on
> environment modules (getenv,setenv), and hash algo methods. The
> mandatory modules for DFU includes USB(dwc3/musb), gadget,
> drivers/dfu, hash, environ modules. Added to this mmc/sf support,
> with filesystem fat/ext4 would definitely increase the size.
> 

I've double checked BBB SPL setup:

- SPL is the MLO (./common/spl/)
- Its size shall be less than 128 KiB
- It can reside on eMMC (fat partition, raw LBA offset), NAND or be sent
  via serial port.

I've build the am335x_boneblack_defconfig and MLO size is 75 KiB.

Please correct me, but it seems that the SPL-DFU support adds around
30 KiB to SPL binary size.

If yes, then even BBB's SPL can support DFU without any problems (105KiB
< 128 KiB).

I'm also wondering if we could even shrink the code more with
reusing or extending the code@./common/spl/spl_{ext|fat|mmc|sf,
etc}.c (in this way we avoid adding the whole fat, ext, sf "commands").

For more aggressive size reduction we could for example disable hash
algo checking and add ./common/spl/spl_dfu.c file with ordinary
functions and rid of the need to add the whole dfu command.


> I have tried minimal subset adding DFU-SF serial flash support alone
> in SPL, this itself increases SPL size to 30K+ (SPL size approx.
> 107KB for dra7x). 
> 
> But beagle bone IRAM would be around 64KB right? Definetly this will
> not fit.
> 
> Can we enable this feature for platform with minimum SRAM size of
> 160KB. So SPL-DFU cannot be supported for platform less than 160KB
> (like am335x).

I will ask on ML if there is any other interested party in SPL-DFU
support (and what are their limitations of SPL code size).

> 
> Any suggestion ?
> 
> Regards
> Ravi 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz

>> >> Since DFU is tighly coupled to u-boot infrastructure , the size 
>> >> will increase due to multiple dependencies to compile u-boot DFU 
>> >> source in SPL. Let me re-think on possibility and come back.
>> 
>> >If you would need any assistance, please let me know (I don't have 
>> >dra7x, but I do have Beagle Bone Black).
>> 
>> The current implementation of dfu (drivers/dfu/dfu.c) relies on 
>> environment modules (getenv,setenv), and hash algo methods. The 
>> mandatory modules for DFU includes USB(dwc3/musb), gadget, 
>> drivers/dfu, hash, environ modules. Added to this mmc/sf support, with 
>> filesystem fat/ext4 would definitely increase the size.
>> 

>I've double checked BBB SPL setup:

>- SPL is the MLO (./common/spl/)
>- Its size shall be less than 128 KiB
>- It can reside on eMMC (fat partition, raw LBA offset), NAND or be sent
 > via serial port.

>I've build the am335x_boneblack_defconfig and MLO size is 75 KiB.

>Please correct me, but it seems that the SPL-DFU support adds around
>30 KiB to SPL binary size.

30KB+ is just approx size optimitzed for DFU-SF (qspi) support only, without fat/ext4, mmc support. 
But all device support may increase size.

>If yes, then even BBB's SPL can support DFU without any problems (105KiB < 128 KiB).

You mean BBB must have 128KB ? Can you confirm.
If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash through SPL-DFU/SF would be sufficient right ?
Further dfu support for mmc/sd, ram available from u-boot.

>>I'm also wondering if we could even shrink the code more with reusing or extending the code at ./common/spl/spl_{ext|fat|mmc|sf, etc}.c (in this way we avoid adding the whole fat, ext, sf "commands").

Yes we must see this option. I will check on this.

>>For more aggressive size reduction we could for example disable hash algo checking and add ./common/spl/spl_dfu.c file with ordinary functions and rid of the need to add the whole dfu command.

>> I have tried minimal subset adding DFU-SF serial flash support alone 
>> in SPL, this itself increases SPL size to 30K+ (SPL size approx.
>> 107KB for dra7x). 
>> 
>> But beagle bone IRAM would be around 64KB right? Definetly this will 
>> not fit.
>> 
>> Can we enable this feature for platform with minimum SRAM size of 
>> 160KB. So SPL-DFU cannot be supported for platform less than 160KB 
>> (like am335x).

>I will ask on ML if there is any other interested party in SPL-DFU support (and what are their limitations of SPL code size).

OK.

Regards
Ravi 

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
> 
> >> >> Since DFU is tighly coupled to u-boot infrastructure , the size 
> >> >> will increase due to multiple dependencies to compile u-boot
> >> >> DFU source in SPL. Let me re-think on possibility and come back.
> >> 
> >> >If you would need any assistance, please let me know (I don't
> >> >have dra7x, but I do have Beagle Bone Black).
> >> 
> >> The current implementation of dfu (drivers/dfu/dfu.c) relies on 
> >> environment modules (getenv,setenv), and hash algo methods. The 
> >> mandatory modules for DFU includes USB(dwc3/musb), gadget, 
> >> drivers/dfu, hash, environ modules. Added to this mmc/sf support,
> >> with filesystem fat/ext4 would definitely increase the size.
> >> 
> 
> >I've double checked BBB SPL setup:
> 
> >- SPL is the MLO (./common/spl/)
> >- Its size shall be less than 128 KiB
> >- It can reside on eMMC (fat partition, raw LBA offset), NAND or be
> >sent
>  > via serial port.
> 
> >I've build the am335x_boneblack_defconfig and MLO size is 75 KiB.
> 
> >Please correct me, but it seems that the SPL-DFU support adds around
> >30 KiB to SPL binary size.
> 
> 30KB+ is just approx size optimitzed for DFU-SF (qspi) support only,

So the 30KiB+ is for the DFU-SF support only.

> without fat/ext4, mmc support. But all device support may increase
> size.

Ok.

However, adding fat/ext4/mmc (and other) support should be on demand
(and enabled by proper Kconfig options).

This would allow others to add only what is really needed.

> 
> >If yes, then even BBB's SPL can support DFU without any problems
> >(105KiB < 128 KiB).
> 
> You mean BBB must have 128KB ? Can you confirm.

I didn't find any _hard_ rule about the size.

In the am335x_evm.h file the spice reserved for SPL (on raw eMMC) is 128
KiB.

> If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash through
> SPL-DFU/SF would be sufficient right ?

I don't know the exact use cases, but yes, BBB can boot from SPI flash.


I'm just wondering - the use case for your board is to use USB to flash
your device in u-boot SPL. 
If I might ask, why cannot you wait for the U-Boot to use fully-fledged
DFU for flashing?


> Further dfu support for
> mmc/sd, ram available from u-boot.
> 
> >>I'm also wondering if we could even shrink the code more with
> >>reusing or extending the code at ./common/spl/spl_{ext|fat|mmc|sf,
> >>etc}.c (in this way we avoid adding the whole fat, ext, sf
> >>"commands").
> 
> Yes we must see this option. I will check on this.
> 
> >>For more aggressive size reduction we could for example disable
> >>hash algo checking and add ./common/spl/spl_dfu.c file with
> >>ordinary functions and rid of the need to add the whole dfu command.
> 
> >> I have tried minimal subset adding DFU-SF serial flash support
> >> alone in SPL, this itself increases SPL size to 30K+ (SPL size
> >> approx. 107KB for dra7x). 
> >> 
> >> But beagle bone IRAM would be around 64KB right? Definetly this
> >> will not fit.
> >> 
> >> Can we enable this feature for platform with minimum SRAM size of 
> >> 160KB. So SPL-DFU cannot be supported for platform less than 160KB 
> >> (like am335x).
> 
> >I will ask on ML if there is any other interested party in SPL-DFU
> >support (and what are their limitations of SPL code size).
> 
> OK.
> 
> Regards
> Ravi 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz

>> without fat/ext4, mmc support. But all device support may increase 
>> size.

> Ok.

> However, adding fat/ext4/mmc (and other) support should be on demand (and enabled by proper Kconfig options).
> This would allow others to add only what is really needed.

True, we provide incremental build option on need basis.  

>> 
>> >If yes, then even BBB's SPL can support DFU without any problems 
>> >(105KiB < 128 KiB).
>> 
>> You mean BBB must have 128KB ? Can you confirm.

>I didn't find any _hard_ rule about the size.

>In the am335x_evm.h file the spice reserved for SPL (on raw eMMC) is 128 KiB.

Are you referring to eMMC raw boot option ?

>> If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash through 
>> SPL-DFU/SF would be sufficient right ?

>I don't know the exact use cases, but yes, BBB can boot from SPI flash.

>I'm just wondering - the use case for your board is to use USB to flash your device in u-boot SPL. 
>If I might ask, why cannot you wait for the U-Boot to use fully-fledged DFU for flashing?

Full-fledged DFU already supported in u-boot. 
The problem here is, how to flash the images first time to fresh boards to 	QSPI or eMMC device, where there is no MMC/SD boot option available. 
The solution to this problem is use peripheral USB boot mode (configuring sysboot switches), where the ROM loads the intial SPL(+DFU builtin for spi/eMMC) to IRAM, then run dfu/sf or dfu/eMMC to flash the binaries from PC using USB interface.
Refer to SPL-DFU support based on 2014.07 u-boot http://www.ti.com/lit/an/sprac33/sprac33.pdf. 

The SPL-DFU definitely helpful in production/development, where just connect EVM to PC through USB cable, and flash the MLO/U-BOOT, binaries to selected device (QSPI/eMMC).

I think based on discussion we had, some conclusion we could arrive, 
1) SPL size is constraint based on IRAM size, that all platform cannot be supported by default.
2) Kconfig option to compile only required device (eMMC, SPI)
3) Kconfig option for fat/ext4 support.
4) Try using common/spl/spl_fat{ext}.. to reduce footprint.

Regards
Ravi 

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
> 
> >> without fat/ext4, mmc support. But all device support may increase 
> >> size.
> 
> > Ok.
> 
> > However, adding fat/ext4/mmc (and other) support should be on
> > demand (and enabled by proper Kconfig options). This would allow
> > others to add only what is really needed.
> 
> True, we provide incremental build option on need basis.  

+1

> 
> >> 
> >> >If yes, then even BBB's SPL can support DFU without any problems 
> >> >(105KiB < 128 KiB).
> >> 
> >> You mean BBB must have 128KB ? Can you confirm.
> 
> >I didn't find any _hard_ rule about the size.
> 
> >In the am335x_evm.h file the spice reserved for SPL (on raw eMMC) is
> >128 KiB.
> 
> Are you referring to eMMC raw boot option ?

Yes, this is LBA address of eMMC memory.

> 
> >> If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash
> >> through SPL-DFU/SF would be sufficient right ?
> 
> >I don't know the exact use cases, but yes, BBB can boot from SPI
> >flash.
> 
> >I'm just wondering - the use case for your board is to use USB to
> >flash your device in u-boot SPL. If I might ask, why cannot you wait
> >for the U-Boot to use fully-fledged DFU for flashing?
> 
> Full-fledged DFU already supported in u-boot. 

This is a good news.

> The problem here is, how to flash the images first time to fresh
> boards to 	QSPI or eMMC device, where there is no MMC/SD boot
> option available. The solution to this problem is use peripheral USB
> boot mode (configuring sysboot switches), where the ROM loads the
> intial SPL(+DFU builtin for spi/eMMC) to IRAM, then run dfu/sf or
> dfu/eMMC to flash the binaries from PC using USB interface. Refer to
> SPL-DFU support based on 2014.07 u-boot
> http://www.ti.com/lit/an/sprac33/sprac33.pdf. 

I know about similar bootstrap (on TI board), which uses serial instead
of USB.

In this approach MLO was loaded by serial, then it loaded u-boot, which
was responsible for factory setting of the device (flashing rootfs,
boot and other partitions).

One question:

Would it be possible to develop SPL (MLO) for your platform, which does
following things:

1. Loads the full-fledge u-boot to SDRAM
2. Starts the u-boot and
3. u-boot flash all the needed stuff


By using such approach we could restrict our dfu support in SPL u-boot
only to receiving data and uploading it to SDRAM (i.e. we wouldn't
need to add write support for ext, fat and eMMC).



> 
> The SPL-DFU definitely helpful in production/development, where just
> connect EVM to PC through USB cable, and flash the MLO/U-BOOT,
> binaries to selected device (QSPI/eMMC).
> 
> I think based on discussion we had, some conclusion we could arrive, 
> 1) SPL size is constraint based on IRAM size, that all platform
> cannot be supported by default. 2) Kconfig option to compile only
> required device (eMMC, SPI) 3) Kconfig option for fat/ext4 support.
> 4) Try using common/spl/spl_fat{ext}.. to reduce footprint.
> 
> Regards
> Ravi 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz

>> The problem here is, how o flash the images first time to fresh
>> boards to 	QSPI or eMMC device, where there is no MMC/SD boot
>> option available. The solution to this problem is use peripheral USB 
>> boot mode (configuring sysboot switches), where the ROM loads the 
>> intial SPL(+DFU builtin for spi/eMMC) to IRAM, then run dfu/sf or 
>> dfu/eMMC to flash the binaries from PC using USB interface. Refer to 
>> SPL-DFU support based on 2014.07 u-boot 
>> http://www.ti.com/lit/an/sprac33/sprac33.pdf.

>I know about similar bootstrap (on TI board), which uses serial instead of USB.

>In this approach MLO was loaded by serial, then it loaded u-boot, which was responsible for factory setting of the device (flashing rootfs, boot and other partitions).

>One question:

>Would it be possible to develop SPL (MLO) for your platform, which does following things:

>1. Loads the full-fledge u-boot to SDRAM 2. Starts the u-boot and 3. u-boot flash all the needed stuff

>By using such approach we could restrict our dfu support in SPL u-boot only to receiving data and uploading it to SDRAM (i.e. we wouldn't need to add write support for ext, fat and eMMC).


This is not possible, because combining MLO and u-boot.img will not fit in IRAM (512k). The u-boot.img itself is around 640K.

Regards
Ravi

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
> 
> >> The problem here is, how o flash the images first time to fresh
> >> boards to 	QSPI or eMMC device, where there is no MMC/SD
> >> boot option available. The solution to this problem is use
> >> peripheral USB boot mode (configuring sysboot switches), where the
> >> ROM loads the intial SPL(+DFU builtin for spi/eMMC) to IRAM, then
> >> run dfu/sf or dfu/eMMC to flash the binaries from PC using USB
> >> interface. Refer to SPL-DFU support based on 2014.07 u-boot 
> >> http://www.ti.com/lit/an/sprac33/sprac33.pdf.
> 
> >I know about similar bootstrap (on TI board), which uses serial
> >instead of USB.
> 
> >In this approach MLO was loaded by serial, then it loaded u-boot,
> >which was responsible for factory setting of the device (flashing
> >rootfs, boot and other partitions).
> 
> >One question:
> 
> >Would it be possible to develop SPL (MLO) for your platform, which
> >does following things:
> 
> >1. Loads the full-fledge u-boot to SDRAM 2. Starts the u-boot and 3.
> >u-boot flash all the needed stuff
> 
> >By using such approach we could restrict our dfu support in SPL
> >u-boot only to receiving data and uploading it to SDRAM (i.e. we
> >wouldn't need to add write support for ext, fat and eMMC).
> 
> 
> This is not possible, because combining MLO and u-boot.img will not
> fit in IRAM (512k). The u-boot.img itself is around 640K.

My point here is to first load SPL u-boot (which size is around 110
KiB), and then download via DFU full-featured u-boot, which would be
placed in SDRAM.

Then u-boot downloads and flash all needed images.

One big advantage is that our SPL DFU support can be minimal - we don't
need to implement fat, ext ,emmc write support.

> 
> Regards
> Ravi
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz
 
>> >One question:
>> 
>> >Would it be possible to develop SPL (MLO) for your platform, which 
>> >does following things:
>> 
>> >1. Loads the full-fledge u-boot to SDRAM 2. Starts the u-boot and 3.
>> >u-boot flash all the needed stuff
>> 
>> >By using such approach we could restrict our dfu support in SPL 
>> >u-boot only to receiving data and uploading it to SDRAM (i.e. we 
>> >wouldn't need to add write support for ext, fat and eMMC).
>> 
>> 
>> This is not possible, because combining MLO and u-boot.img will not 
>> fit in IRAM (512k). The u-boot.img itself is around 640K.

>My point here is to first load SPL u-boot (which size is around 110 KiB), and then download via DFU full-featured u-boot, which would be placed in SDRAM.

Yes this is good idea, so the SPL-DFU will have only RAM device support (to load u-boot into DDR).
But we don't have DFU command to jump to u-boot after loading u-boot into DDR.
The DFU basically just download firmware to memory devices like mmc/sd/eMMC/RAM.
So the question is how to transfer control to u-boot after downloading the u-boot to DDR using SPL-DFU/RAM. 

>Then u-boot downloads and flash all needed images.
>One big advantage is that our SPL DFU support can be minimal - we don't need to implement fat, ext ,emmc write support.

Yes, I agree, if we could workaround above bottle neck.

Regards
Ravi

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
>  
> >> >One question:
> >> 
> >> >Would it be possible to develop SPL (MLO) for your platform,
> >> >which does following things:
> >> 
> >> >1. Loads the full-fledge u-boot to SDRAM 2. Starts the u-boot and
> >> >3. u-boot flash all the needed stuff
> >> 
> >> >By using such approach we could restrict our dfu support in SPL 
> >> >u-boot only to receiving data and uploading it to SDRAM (i.e. we 
> >> >wouldn't need to add write support for ext, fat and eMMC).
> >> 
> >> 
> >> This is not possible, because combining MLO and u-boot.img will
> >> not fit in IRAM (512k). The u-boot.img itself is around 640K.
> 
> >My point here is to first load SPL u-boot (which size is around 110
> >KiB), and then download via DFU full-featured u-boot, which would be
> >placed in SDRAM.
> 
> Yes this is good idea, so the SPL-DFU will have only RAM device
> support (to load u-boot into DDR). But we don't have DFU command to
> jump to u-boot after loading u-boot into DDR.

I think that we don't need dfu command in SPL to boot fully-featured
u-boot.

Lets consider following scenario:

- ROM bootloader (IPL) fetches SPL u-boot via USB. Then it passes
  execution to it.
- The running SPL downloads fully-fledged u-boot [*] to RAM and passes
  execution to it (as it is done in board_init_r @ ./common/spl/spl.c).
  There is no need for any special command(s) to do that.
- Fully-blown u-boot flashes all needed images and reboots the board.
- Now the board is setup with proper u-boot, kernel and rootfs

[*] - This version of u-boot only requires to have hardcoded "bootcmd"
env variable. It would consist the list of commands needed for flashing
your target board. The "dfu_alt_info" should be hardcoded as well.


> The DFU basically just
> download firmware to memory devices like mmc/sd/eMMC/RAM.
> So the
> question is how to transfer control to u-boot after downloading the
> u-boot to DDR using SPL-DFU/RAM.

Please consult board_init_r function at ./common/spl/spl.c
 
> 
> >Then u-boot downloads and flash all needed images.
> >One big advantage is that our SPL DFU support can be minimal - we
> >don't need to implement fat, ext ,emmc write support.
> 
> Yes, I agree, if we could workaround above bottle neck.
> 
> Regards
> Ravi
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz

>> 
>> >My point here is to first load SPL u-boot (which size is around 110 
>> >KiB), and then download via DFU full-featured u-boot, which would be 
>> >placed in SDRAM.
>> 
>> Yes this is good idea, so the SPL-DFU will have only RAM device 
>> support (to load u-boot into DDR). But we don't have DFU command to 
>> jump to u-boot after loading u-boot into DDR.

>I think that we don't need dfu command in SPL to boot fully-featured u-boot.

>Lets consider following scenario:

>- ROM bootloader (IPL) fetches SPL u-boot via USB. Then it passes
>  execution to it.
>- The running SPL downloads fully-fledged u-boot [*] to RAM and passes
>  execution to it (as it is done in board_init_r @ ./common/spl/spl.c).
>  There is no need for any special command(s) to do that.
>- Fully-blown u-boot flashes all needed images and reboots the board.
>- Now the board is setup with proper u-boot, kernel and rootfs

> [*] - This version of u-boot only requires to have hardcoded "bootcmd"
>env variable. It would consist the list of commands needed for flashing your target board. The "dfu_alt_info" should be hardcoded as well.


>> The DFU basically just
>> download firmware to memory devices like mmc/sd/eMMC/RAM.
>> So the
>> question is how to transfer control to u-boot after downloading the 
>> u-boot to DDR using SPL-DFU/RAM.

> Please consult board_init_r function at ./common/spl/spl.c
 
Yes, this is common u-boot flow, make sense, I was thinking exiting from DFU loop, user has to press Ctrl+C to exit from DFU after download of u-boot to IRAM. 
We can leverage the existing DFU/RAM support.  Main concern is SPL+DFU size. I will rework and come back on how much size can be reduced.

Thanks Lukasz for great support. 

Regards
Ravi

[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
> 
> >> 
> >> >My point here is to first load SPL u-boot (which size is around
> >> >110 KiB), and then download via DFU full-featured u-boot, which
> >> >would be placed in SDRAM.
> >> 
> >> Yes this is good idea, so the SPL-DFU will have only RAM device 
> >> support (to load u-boot into DDR). But we don't have DFU command
> >> to jump to u-boot after loading u-boot into DDR.
> 
> >I think that we don't need dfu command in SPL to boot fully-featured
> >u-boot.
> 
> >Lets consider following scenario:
> 
> >- ROM bootloader (IPL) fetches SPL u-boot via USB. Then it passes
> >  execution to it.
> >- The running SPL downloads fully-fledged u-boot [*] to RAM and
> >passes
> >  execution to it (as it is done in board_init_r
> > @ ./common/spl/spl.c). There is no need for any special command(s)
> > to do that.
> >- Fully-blown u-boot flashes all needed images and reboots the board.
> >- Now the board is setup with proper u-boot, kernel and rootfs
> 
> > [*] - This version of u-boot only requires to have hardcoded
> > "bootcmd"
> >env variable. It would consist the list of commands needed for
> >flashing your target board. The "dfu_alt_info" should be hardcoded
> >as well.
> 
> 
> >> The DFU basically just
> >> download firmware to memory devices like mmc/sd/eMMC/RAM.
> >> So the
> >> question is how to transfer control to u-boot after downloading
> >> the u-boot to DDR using SPL-DFU/RAM.
> 
> > Please consult board_init_r function at ./common/spl/spl.c
>  
> Yes, this is common u-boot flow, make sense, I was thinking exiting
> from DFU loop, user has to press Ctrl+C to exit from DFU after
> download of u-boot to IRAM. 

It is not needed to press Ctrl+C to exit the loop.

Please try dfu-util -e -a0 -D <your_image>

The '-e' switch allows to exit the loop and go into the prompt.

Moreover, your can also try out the '-R' switch, which would impose
board reset after successful dfu flashing.


> We can leverage the existing DFU/RAM
> support.  Main concern is SPL+DFU size. I will rework and come back
> on how much size can be reduced.

Great.

> 
> Thanks Lukasz for great support. 

No problem :-)

> 
> Regards
> Ravi
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 2/5] spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU

[Ravi Babu]

Adding ext4/fat filesytem support for SPL-DFU to
write ext4/fat files to eMMC, MMC/SD device

Signed-off-by: Ravi Babu <ravibabu@ti.com>
---
 cmd/Makefile    |    9 +++++++++
 common/Makefile |    4 +++-
 fs/Makefile     |   12 +++++++++++-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/cmd/Makefile b/cmd/Makefile
index 139189e..ad89e09 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,15 @@ CONFIG_INC_COMMON=n
 endif
 endif
 
+ifeq ($(CONFIG_INC_COMMON),y)
+obj-$(CONFIG_CMD_EXT4) += ext4.o
+obj-$(CONFIG_CMD_EXT2) += ext2.o
+obj-$(CONFIG_CMD_FAT) += fat.o
+obj-$(CONFIG_CMD_FDC) += fdc.o
+obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
+obj-$(CONFIG_CMD_SCSI) += scsi.o
+endif
+
 ifndef CONFIG_SPL_BUILD
 # core command
 obj-y += boot.o
diff --git a/common/Makefile b/common/Makefile
index 3576fac..99de9e1 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -24,6 +24,9 @@ obj-y += env_attr.o
 obj-y += env_callback.o
 obj-y += env_flags.o
 obj-y += cli.o
+ifdef CONFIG_CMD_USB
+obj-$(CONFIG_USB_STORAGE) += usb_storage.o
+endif
 endif
 
 ifndef CONFIG_SPL_BUILD
@@ -78,7 +81,6 @@ obj-$(CONFIG_PHYLIB) += miiphyutil.o
 
 ifdef CONFIG_CMD_USB
 obj-y += usb.o usb_hub.o
-obj-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
 
 # others
diff --git a/fs/Makefile b/fs/Makefile
index 51d06fc..d4490a9 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -6,11 +6,21 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+CONFIG_INC_COMMON=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_COMMON=n
+endif
+endif
+
+ifeq ($(CONFIG_INC_COMMON),y)
+obj-y				+= fs.o
+endif
+
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/
 obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/
 else
-obj-y				+= fs.o
 
 obj-$(CONFIG_CMD_CBFS) += cbfs/
 obj-$(CONFIG_CMD_CRAMFS) += cramfs/
-- 
1.7.9.5

[U-Boot] [RFC PATCH 2/5] spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU

[Lukasz Majewski]

Hi Ravi,

> Adding ext4/fat filesytem support for SPL-DFU to
> write ext4/fat files to eMMC, MMC/SD device
> 
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>  cmd/Makefile    |    9 +++++++++
>  common/Makefile |    4 +++-
>  fs/Makefile     |   12 +++++++++++-
>  3 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 139189e..ad89e09 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -12,6 +12,15 @@ CONFIG_INC_COMMON=n
>  endif
>  endif
>  
> +ifeq ($(CONFIG_INC_COMMON),y)
> +obj-$(CONFIG_CMD_EXT4) += ext4.o
> +obj-$(CONFIG_CMD_EXT2) += ext2.o
> +obj-$(CONFIG_CMD_FAT) += fat.o
> +obj-$(CONFIG_CMD_FDC) += fdc.o
> +obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
> +obj-$(CONFIG_CMD_SCSI) += scsi.o
> +endif

Could we extend code from ./common/spl/spl_fat.c
or ./common/spl/spl_ext to support write ?

> +
>  ifndef CONFIG_SPL_BUILD
>  # core command
>  obj-y += boot.o
> diff --git a/common/Makefile b/common/Makefile
> index 3576fac..99de9e1 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -24,6 +24,9 @@ obj-y += env_attr.o
>  obj-y += env_callback.o
>  obj-y += env_flags.o
>  obj-y += cli.o
> +ifdef CONFIG_CMD_USB
> +obj-$(CONFIG_USB_STORAGE) += usb_storage.o
> +endif
>  endif
>  
>  ifndef CONFIG_SPL_BUILD
> @@ -78,7 +81,6 @@ obj-$(CONFIG_PHYLIB) += miiphyutil.o
>  
>  ifdef CONFIG_CMD_USB
>  obj-y += usb.o usb_hub.o
> -obj-$(CONFIG_USB_STORAGE) += usb_storage.o
>  endif
>  
>  # others
> diff --git a/fs/Makefile b/fs/Makefile
> index 51d06fc..d4490a9 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -6,11 +6,21 @@
>  # SPDX-License-Identifier:	GPL-2.0+
>  #
>  
> +CONFIG_INC_COMMON=y
> +ifdef CONFIG_SPL_BUILD
> +ifndef CONFIG_SPL_DFU
> +CONFIG_INC_COMMON=n
> +endif
> +endif
> +
> +ifeq ($(CONFIG_INC_COMMON),y)
> +obj-y				+= fs.o
> +endif
> +
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/
>  obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/
>  else
> -obj-y				+= fs.o
>  
>  obj-$(CONFIG_CMD_CBFS) += cbfs/
>  obj-$(CONFIG_CMD_CRAMFS) += cramfs/

Just side question:

How large could be the SPL code for your board (dra7x)?

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 2/5] spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU

[B, Ravi]

Hi Lukasz 


> On 30-May-2016, at 5:30 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 
> Hi Ravi,
> 
>> Adding ext4/fat filesytem support for SPL-DFU to
>> write ext4/fat files to eMMC, MMC/SD device
>> 
>> Signed-off-by: Ravi Babu <ravibabu@ti.com>
>> ---
>> cmd/Makefile    |    9 +++++++++
>> common/Makefile |    4 +++-
>> fs/Makefile     |   12 +++++++++++-
>> 3 files changed, 23 insertions(+), 2 deletions(-)
>> 
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index 139189e..ad89e09 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -12,6 +12,15 @@ CONFIG_INC_COMMON=n
>> endif
>> endif
>> 
>> +ifeq ($(CONFIG_INC_COMMON),y)
>> +obj-$(CONFIG_CMD_EXT4) += ext4.o
>> +obj-$(CONFIG_CMD_EXT2) += ext2.o
>> +obj-$(CONFIG_CMD_FAT) += fat.o
>> +obj-$(CONFIG_CMD_FDC) += fdc.o
>> +obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
>> +obj-$(CONFIG_CMD_SCSI) += scsi.o
>> +endif
> 
> Could we extend code from ./common/spl/spl_fat.c
> or ./common/spl/spl_ext to support write ?
> 

I will check this and let you know.

>> +
>> ifndef CONFIG_SPL_BUILD
>> # core command
>> obj-y += boot.o
>> diff --git a/common/Makefile b/common/Makefile
>> index 3576fac..99de9e1 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -24,6 +24,9 @@ obj-y += env_attr.o
>> obj-y += env_callback.o
>> obj-y += env_flags.o
>> obj-y += cli.o
>> +ifdef CONFIG_CMD_USB
>> +obj-$(CONFIG_USB_STORAGE) += usb_storage.o
>> +endif
>> endif
>> 
>> ifndef CONFIG_SPL_BUILD
>> @@ -78,7 +81,6 @@ obj-$(CONFIG_PHYLIB) += miiphyutil.o
>> 
>> ifdef CONFIG_CMD_USB
>> obj-y += usb.o usb_hub.o
>> -obj-$(CONFIG_USB_STORAGE) += usb_storage.o
>> endif
>> 
>> # others
>> diff --git a/fs/Makefile b/fs/Makefile
>> index 51d06fc..d4490a9 100644
>> --- a/fs/Makefile
>> +++ b/fs/Makefile
>> @@ -6,11 +6,21 @@
>> # SPDX-License-Identifier:    GPL-2.0+
>> #
>> 
>> +CONFIG_INC_COMMON=y
>> +ifdef CONFIG_SPL_BUILD
>> +ifndef CONFIG_SPL_DFU
>> +CONFIG_INC_COMMON=n
>> +endif
>> +endif
>> +
>> +ifeq ($(CONFIG_INC_COMMON),y)
>> +obj-y                += fs.o
>> +endif
>> +
>> ifdef CONFIG_SPL_BUILD
>> obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/
>> obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/
>> else
>> -obj-y                += fs.o
>> 
>> obj-$(CONFIG_CMD_CBFS) += cbfs/
>> obj-$(CONFIG_CMD_CRAMFS) += cramfs/
> 
> Just side question:
> 
> How large could be the SPL code for your board (dra7x)?
> 

The SPL code size is about 152K.

> -- 
> Best regards,
> 
> Lukasz Majewski
> 
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 2/5] spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU

[Lukasz Majewski]

Hi Ravi,

> > 
> > How large could be the SPL code for your board (dra7x)?
> >   
> 
> The SPL code size is about 152K.

And what is the overall size of IRAM on this board?

My concern here is that other potential users of DFU SPL boards could
have smaller available memory (for example 64KiB or even better -
24KiB).

That is why we struggle to have the SPL as tiny as possible.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 2/5] spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU

[B, Ravi]

Lucasz 


> On 30-May-2016, at 6:51 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 
> Hi Ravi,
> 
>>> 
>>> How large could be the SPL code for your board (dra7x)?
>> 
>> The SPL code size is about 152K.
> 
> And what is the overall size of IRAM on this board?
> 
> My concern here is that other potential users of DFU SPL boards could
> have smaller available memory (for example 64KiB or even better -
> 24KiB).
> 
> That is why we struggle to have the SPL as tiny as possible.
> 
Yes, I am aware of this, the dra7x has 512kb. SPL-DFU shall enabled only for platform has IRAM has more space.

> -- 
> Best regards,
> 
> Lukasz Majewski
> 
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 3/5] spl: dfu: adding dfu support functions for SPL-DFU

[Ravi Babu]

Adding support functions to run dfu commands
with support for eMMC/MMC/SD memory device.

Signed-off-by: Ravi Babu <ravibabu@ti.com>
---
 drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
 drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
 include/dfu.h         |    8 ++++++++
 3 files changed, 64 insertions(+)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 20dfcbb..1d4690b 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -16,6 +16,7 @@
 #include <hash.h>
 #include <linux/list.h>
 #include <linux/compiler.h>
+#include <environment.h>
 
 static LIST_HEAD(dfu_list);
 static int dfu_alt_num;
@@ -596,3 +597,30 @@ int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size)
 
 	return ret;
 }
+
+int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str)
+{
+	char *str_env;
+	int ret;
+
+	/* set default environment */
+	set_default_env(0);
+	str_env = getenv(dfu_alt_info);
+	if (!str_env) {
+		error("\"dfu_alt_info\" env variable not defined!\n");
+		return -EINVAL;
+	}
+
+	ret = setenv("dfu_alt_info", str_env);
+	if (ret) {
+		error("unable to set env variable \"dfu_alt_info\"!\n");
+		return -EINVAL;
+	}
+
+	/* invoke dfu command */
+	ret = run_command(dfu_cmd_str, 0);
+	if (ret)
+		error("dfu: error = %d\n", ret);
+
+	return ret;
+}
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index faece88..28517e8 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -15,6 +15,7 @@
 #include <ext4fs.h>
 #include <fat.h>
 #include <mmc.h>
+#include <environment.h>
 
 static unsigned char *dfu_file_buf;
 static long dfu_file_buf_len;
@@ -401,3 +402,30 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char *s)
 
 	return 0;
 }
+
+int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info)
+{
+	char cmd_buf[DFU_CMD_BUF_SIZE];
+	struct mmc *mmcdev;
+	struct mmc **mmc = &mmcdev;
+	int device = mmc_dev;
+	int ret;
+
+	/* initialize the mmc module */
+	mmc_initialize(0);
+
+	*mmc = find_mmc_device(device);
+	if (!*mmc) {
+		error("failed to find mmc device %d\n", device);
+		return -ENODEV;
+	}
+
+	ret = mmc_init(*mmc);
+	if (ret) {
+		error("spl: mmc init failed with error: %d\n", ret);
+		return ret;
+	}
+
+	sprintf(cmd_buf, "dfu %d mmc %d", usb_index, device);
+	return dfu_run_cmd(dfu_alt_info, cmd_buf);
+}
diff --git a/include/dfu.h b/include/dfu.h
index f39d3f1..0bc75bc 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -274,4 +274,12 @@ static inline int dfu_tftp_write(char *dfu_entity_name, unsigned int addr,
 #endif
 
 int dfu_add(struct usb_configuration *c);
+/* dfu_run_umc - run dfu command with chosen mmc device interface
+ * @param usb_index - usb controller number
+ * @param mmc_dev -  mmc device nubmer
+ *
+ * @return 0 on success, otherwise error code
+ */
+int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info);
+int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str);
 #endif /* __DFU_ENTITY_H_ */
-- 
1.7.9.5

[U-Boot] [RFC PATCH 3/5] spl: dfu: adding dfu support functions for SPL-DFU

[Heiko Schocher]

Hello Ravi,

Am 27.05.2016 um 15:39 schrieb Ravi Babu:
> Adding support functions to run dfu commands
> with support for eMMC/MMC/SD memory device.
>
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>   drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
>   drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
>   include/dfu.h         |    8 ++++++++
>   3 files changed, 64 insertions(+)
>
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 20dfcbb..1d4690b 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -16,6 +16,7 @@
>   #include <hash.h>
>   #include <linux/list.h>
>   #include <linux/compiler.h>
> +#include <environment.h>
>
>   static LIST_HEAD(dfu_list);
>   static int dfu_alt_num;
> @@ -596,3 +597,30 @@ int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size)
>
>   	return ret;
>   }
> +
> +int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str)
> +{
> +	char *str_env;
> +	int ret;
> +
> +	/* set default environment */
> +	set_default_env(0);
> +	str_env = getenv(dfu_alt_info);
> +	if (!str_env) {
> +		error("\"dfu_alt_info\" env variable not defined!\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = setenv("dfu_alt_info", str_env);
> +	if (ret) {
> +		error("unable to set env variable \"dfu_alt_info\"!\n");
> +		return -EINVAL;
> +	}

Why you read the Envvariable and store it again?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC PATCH 3/5] spl: dfu: adding dfu support functions for SPL-DFU

[Lukasz Majewski]

Hi Ravi,

> Adding support functions to run dfu commands
> with support for eMMC/MMC/SD memory device.
> 
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>  drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
>  drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
>  include/dfu.h         |    8 ++++++++
>  3 files changed, 64 insertions(+)
> 
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 20dfcbb..1d4690b 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -16,6 +16,7 @@
>  #include <hash.h>
>  #include <linux/list.h>
>  #include <linux/compiler.h>
> +#include <environment.h>
>  
>  static LIST_HEAD(dfu_list);
>  static int dfu_alt_num;
> @@ -596,3 +597,30 @@ int dfu_write_from_mem_addr(struct dfu_entity
> *dfu, void *buf, int size) 
>  	return ret;
>  }
> +
> +int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str)
> +{
> +	char *str_env;
> +	int ret;
> +
> +	/* set default environment */
> +	set_default_env(0);
> +	str_env = getenv(dfu_alt_info);
> +	if (!str_env) {
> +		error("\"dfu_alt_info\" env variable not
> defined!\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = setenv("dfu_alt_info", str_env);
> +	if (ret) {
> +		error("unable to set env variable
> \"dfu_alt_info\"!\n");
> +		return -EINVAL;
> +	}
> +
> +	/* invoke dfu command */
> +	ret = run_command(dfu_cmd_str, 0);
> +	if (ret)
> +		error("dfu: error = %d\n", ret);
> +
> +	return ret;
> +}
> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
> index faece88..28517e8 100644
> --- a/drivers/dfu/dfu_mmc.c
> +++ b/drivers/dfu/dfu_mmc.c
> @@ -15,6 +15,7 @@
>  #include <ext4fs.h>
>  #include <fat.h>
>  #include <mmc.h>
> +#include <environment.h>
>  
>  static unsigned char *dfu_file_buf;
>  static long dfu_file_buf_len;
> @@ -401,3 +402,30 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
> char *devstr, char *s) 
>  	return 0;
>  }
> +
> +int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info)
> +{
> +	char cmd_buf[DFU_CMD_BUF_SIZE];
> +	struct mmc *mmcdev;
> +	struct mmc **mmc = &mmcdev;
> +	int device = mmc_dev;
> +	int ret;
> +
> +	/* initialize the mmc module */
> +	mmc_initialize(0);
> +
> +	*mmc = find_mmc_device(device);
> +	if (!*mmc) {
> +		error("failed to find mmc device %d\n", device);
> +		return -ENODEV;
> +	}
> +
> +	ret = mmc_init(*mmc);
> +	if (ret) {
> +		error("spl: mmc init failed with error: %d\n", ret);
> +		return ret;
> +	}
> +
> +	sprintf(cmd_buf, "dfu %d mmc %d", usb_index, device);
> +	return dfu_run_cmd(dfu_alt_info, cmd_buf);
> +}
> diff --git a/include/dfu.h b/include/dfu.h
> index f39d3f1..0bc75bc 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -274,4 +274,12 @@ static inline int dfu_tftp_write(char
> *dfu_entity_name, unsigned int addr, #endif
>  
>  int dfu_add(struct usb_configuration *c);
> +/* dfu_run_umc - run dfu command with chosen mmc device interface
> + * @param usb_index - usb controller number
> + * @param mmc_dev -  mmc device nubmer
> + *
> + * @return 0 on success, otherwise error code
> + */
> +int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info);
> +int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str);
>  #endif /* __DFU_ENTITY_H_ */

I would like to avoid mixing SPL and non SPL code as much as possible:

I can propose two options here:
1. In the ./drivers/dfu/ create dfu_spl.c file and put the needed
functionality there.

2. Or better, move all dfu related code to ./common/spl/spl_dfu.c 


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 3/5] spl: dfu: adding dfu support functions for SPL-DFU

[B, Ravi]

Hi Lukasz


> On 30-May-2016, at 5:34 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 
> Hi Ravi,
> 
>> Adding support functions to run dfu commands
>> with support for eMMC/MMC/SD memory device.
>> 
>> Signed-off-by: Ravi Babu <ravibabu@ti.com>
>> ---
>> drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
>> drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
>> include/dfu.h         |    8 ++++++++
>> 3 files changed, 64 insertions(+)
>> 
>> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
>> index 20dfcbb..1d4690b 100644
>> --- a/drivers/dfu/dfu.c
>> +++ b/drivers/dfu/dfu.c
>> @@ -16,6 +16,7 @@
>> #include <hash.h>
>> #include <linux/list.h>
>> #include <linux/compiler.h>
>> +#include <environment.h>
>> 
>> static LIST_HEAD(dfu_list);
>> static int dfu_alt_num;
>> @@ -596,3 +597,30 @@ int dfu_write_from_mem_addr(struct dfu_entity
>> *dfu, void *buf, int size) 
>>    return ret;
>> }
>> +
>> +int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str)
>> +{
>> +    char *str_env;
>> +    int ret;
>> +
>> +    /* set default environment */
>> +    set_default_env(0);
>> +    str_env = getenv(dfu_alt_info);
>> +    if (!str_env) {
>> +        error("\"dfu_alt_info\" env variable not
>> defined!\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    ret = setenv("dfu_alt_info", str_env);
>> +    if (ret) {
>> +        error("unable to set env variable
>> \"dfu_alt_info\"!\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    /* invoke dfu command */
>> +    ret = run_command(dfu_cmd_str, 0);
>> +    if (ret)
>> +        error("dfu: error = %d\n", ret);
>> +
>> +    return ret;
>> +}
>> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
>> index faece88..28517e8 100644
>> --- a/drivers/dfu/dfu_mmc.c
>> +++ b/drivers/dfu/dfu_mmc.c
>> @@ -15,6 +15,7 @@
>> #include <ext4fs.h>
>> #include <fat.h>
>> #include <mmc.h>
>> +#include <environment.h>
>> 
>> static unsigned char *dfu_file_buf;
>> static long dfu_file_buf_len;
>> @@ -401,3 +402,30 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
>> char *devstr, char *s) 
>>    return 0;
>> }
>> +
>> +int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info)
>> +{
>> +    char cmd_buf[DFU_CMD_BUF_SIZE];
>> +    struct mmc *mmcdev;
>> +    struct mmc **mmc = &mmcdev;
>> +    int device = mmc_dev;
>> +    int ret;
>> +
>> +    /* initialize the mmc module */
>> +    mmc_initialize(0);
>> +
>> +    *mmc = find_mmc_device(device);
>> +    if (!*mmc) {
>> +        error("failed to find mmc device %d\n", device);
>> +        return -ENODEV;
>> +    }
>> +
>> +    ret = mmc_init(*mmc);
>> +    if (ret) {
>> +        error("spl: mmc init failed with error: %d\n", ret);
>> +        return ret;
>> +    }
>> +
>> +    sprintf(cmd_buf, "dfu %d mmc %d", usb_index, device);
>> +    return dfu_run_cmd(dfu_alt_info, cmd_buf);
>> +}
>> diff --git a/include/dfu.h b/include/dfu.h
>> index f39d3f1..0bc75bc 100644
>> --- a/include/dfu.h
>> +++ b/include/dfu.h
>> @@ -274,4 +274,12 @@ static inline int dfu_tftp_write(char
>> *dfu_entity_name, unsigned int addr, #endif
>> 
>> int dfu_add(struct usb_configuration *c);
>> +/* dfu_run_umc - run dfu command with chosen mmc device interface
>> + * @param usb_index - usb controller number
>> + * @param mmc_dev -  mmc device nubmer
>> + *
>> + * @return 0 on success, otherwise error code
>> + */
>> +int dfu_run_mmc(int usb_index, int mmc_dev, char *dfu_alt_info);
>> +int dfu_run_cmd(char *dfu_alt_info, char *dfu_cmd_str);
>> #endif /* __DFU_ENTITY_H_ */
> 
> I would like to avoid mixing SPL and non SPL code as much as possible:
> 
> I can propose two options here:
> 1. In the ./drivers/dfu/ create dfu_spl.c file and put the needed
> functionality there.
> 
> 2. Or better, move all dfu related code to ./common/spl/spl_dfu.c 
> 
> 
Ok. That make sense. 

Regards
Ravi
> -- 
> Best regards,
> 
> Lukasz Majewski
> 
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 4/5] dfu: spl: add generic spl-dfu function in common-spl

[Ravi Babu]

Add generic spl-dfu function in common-spl, specific
implemention for configuring dfu memory device is
done in platform board specific source file.

Signed-off-by: Ravi Babu <ravibabu@ti.com>
---
 common/spl/spl.c |   11 +++++++++++
 include/spl.h    |    1 +
 2 files changed, 12 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 82e7f58..ef6d2d1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -273,6 +273,13 @@ static void announce_boot_device(u32 boot_device)
 static inline void announce_boot_device(u32 boot_device) { }
 #endif
 
+#ifdef CONFIG_SPL_DFU
+__weak int spl_run_dfu(void)
+{
+	return 0;
+}
+#endif
+
 static int spl_load_image(u32 boot_device)
 {
 	switch (boot_device) {
@@ -367,6 +374,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 	spl_board_init();
 #endif
 
+#ifdef CONFIG_SPL_DFU
+	spl_run_dfu();
+#endif
+
 	board_boot_order(spl_boot_list);
 	for (i = 0; i < ARRAY_SIZE(spl_boot_list) &&
 			spl_boot_list[i] != BOOT_DEVICE_NONE; i++) {
diff --git a/include/spl.h b/include/spl.h
index 5f0b0db..5794b05 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -158,4 +158,5 @@ void spl_board_init(void);
  */
 bool spl_was_boot_source(void);
 
+int spl_run_dfu(void);
 #endif
-- 
1.7.9.5

[U-Boot] [RFC PATCH 4/5] dfu: spl: add generic spl-dfu function in common-spl

[Lukasz Majewski]

Hi Ravi,

> Add generic spl-dfu function in common-spl, specific
> implemention for configuring dfu memory device is
> done in platform board specific source file.
> 
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>  common/spl/spl.c |   11 +++++++++++
>  include/spl.h    |    1 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 82e7f58..ef6d2d1 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -273,6 +273,13 @@ static void announce_boot_device(u32 boot_device)
>  static inline void announce_boot_device(u32 boot_device) { }
>  #endif
>  
> +#ifdef CONFIG_SPL_DFU
> +__weak int spl_run_dfu(void)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static int spl_load_image(u32 boot_device)
>  {
>  	switch (boot_device) {
> @@ -367,6 +374,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>  	spl_board_init();
>  #endif
>  
> +#ifdef CONFIG_SPL_DFU
> +	spl_run_dfu();
> +#endif
> +
>  	board_boot_order(spl_boot_list);
>  	for (i = 0; i < ARRAY_SIZE(spl_boot_list) &&
>  			spl_boot_list[i] != BOOT_DEVICE_NONE; i++) {
> diff --git a/include/spl.h b/include/spl.h
> index 5f0b0db..5794b05 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -158,4 +158,5 @@ void spl_board_init(void);
>   */
>  bool spl_was_boot_source(void);
>  
> +int spl_run_dfu(void);
>  #endif

Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 5/5] dra7x: spl: dfu: adding SPL-DFU support for dra7x platform

[Ravi Babu]

Adding SPL-DFU support for dra7x platform. The DFU
support for dra7x includes QSPI, MMC/SD and eMMC
memory devices. The SPL-DFU memory devices can be
selected through meunconfig->Boot Images.

Signed-off-by: Ravi Babu <ravibabu@ti.com>
---
 board/ti/dra7xx/evm.c             |   20 ++++++++++++++++++++
 include/configs/dra7xx_evm.h      |    3 +--
 include/configs/ti_omap5_common.h |    2 --
 3 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index f194999..0ce0e97 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -30,6 +30,7 @@
 #include <miiphy.h>
 #include <spl.h>
 #include <pcf8575.h>
+#include <dfu.h>
 
 #include "mux_data.h"
 #include "../common/board_detect.h"
@@ -619,6 +620,25 @@ int spl_start_uboot(void)
 }
 #endif
 
+#ifdef CONFIG_SPL_DFU
+int spl_run_dfu(void)
+{
+#ifdef CONFIG_SPL_DFU_EMMC
+	return dfu_run_mmc(0, 1, "dfu_alt_info_emmc");
+#endif
+
+#ifdef CONFIG_SPL_DFU_MMC
+	return dfu_run_mmc(0, 0, "dfu_alt_info_mmc");
+#endif
+
+#ifdef CONFIG_SPL_DFU
+	return dfu_run_cmd("dfu_alt_info_qspi",
+		"dfu 0 sf 0:0:64000000:0");
+#endif
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_DRIVER_TI_CPSW
 extern u32 *const omap_si_rev;
 
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index da84f1c..ec10cd8 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -44,7 +44,6 @@
 
 #define CONFIG_SYS_OMAP_ABE_SYSCK
 
-#ifndef CONFIG_SPL_BUILD
 /* Define the default GPT table for eMMC */
 #define PARTS_DEFAULT \
 	/* Linux partitions */ \
@@ -122,6 +121,7 @@
 	DFU_ALT_INFO_QSPI
 
 /* Fastboot */
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_ANDROID_BOOT_IMAGE
@@ -331,5 +331,4 @@
 /* pcf support */
 #define CONFIG_PCF8575
 #define CONFIG_SYS_I2C_PCF8575_CHIP { {0x21, 0xeaf7} }
-
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h
index 59f0f70..f9c6576 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -66,7 +66,6 @@
 #define DFUARGS
 #endif
 
-#ifndef CONFIG_SPL_BUILD
 #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	DEFAULT_LINUX_BOOT_ENV \
@@ -136,7 +135,6 @@
 	"setenv mmcroot /dev/mmcblk0p2 rw; " \
 	"run mmcboot;" \
 	""
-#endif
 
 /*
  * SPL related defines.  The Public RAM memory map the ROM defines the
-- 
1.7.9.5

[U-Boot] [RFC PATCH 5/5] dra7x: spl: dfu: adding SPL-DFU support for dra7x platform

[Lukasz Majewski]

Hi Ravi,

> Adding SPL-DFU support for dra7x platform. The DFU
> support for dra7x includes QSPI, MMC/SD and eMMC
> memory devices. The SPL-DFU memory devices can be
> selected through meunconfig->Boot Images.
> 
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> ---
>  board/ti/dra7xx/evm.c             |   20 ++++++++++++++++++++
>  include/configs/dra7xx_evm.h      |    3 +--
>  include/configs/ti_omap5_common.h |    2 --
>  3 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index f194999..0ce0e97 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -30,6 +30,7 @@
>  #include <miiphy.h>
>  #include <spl.h>
>  #include <pcf8575.h>
> +#include <dfu.h>
>  
>  #include "mux_data.h"
>  #include "../common/board_detect.h"
> @@ -619,6 +620,25 @@ int spl_start_uboot(void)
>  }
>  #endif
>  
> +#ifdef CONFIG_SPL_DFU
> +int spl_run_dfu(void)
> +{
> +#ifdef CONFIG_SPL_DFU_EMMC
> +	return dfu_run_mmc(0, 1, "dfu_alt_info_emmc");

Maybe dfu_run_mmc() -> dfu_spl_flash_mmc()? 
Which would be dfu tunned command with minimal space footprint?

> +#endif
> +
> +#ifdef CONFIG_SPL_DFU_MMC
> +	return dfu_run_mmc(0, 0, "dfu_alt_info_mmc");
> +#endif
> +
> +#ifdef CONFIG_SPL_DFU
> +	return dfu_run_cmd("dfu_alt_info_qspi",
> +		"dfu 0 sf 0:0:64000000:0");

I do feel like running commands in SPL context is the overkill.

However, I do not know what would be the SPL binary size reduction if
we re-implement the dfu_run_cmd() as a set of dedicated commands (like
dfu_spl_flash_sf(0, X, <sf proper alt setting @ envs>,
dfu_spl_flash_nand(0, X, <nand proper alt setting @ envs>), etc.).

If the difference is minimal, then we could leave dfu_run_cmd() in the
presented form.

As I've asked previously - what is the u-boot SPL binary size increase
after adding DFU SPL support to your platform?

> +#endif
> +	return 0;
> +}
> +#endif
> +
>  #ifdef CONFIG_DRIVER_TI_CPSW
>  extern u32 *const omap_si_rev;
>  
> diff --git a/include/configs/dra7xx_evm.h
> b/include/configs/dra7xx_evm.h index da84f1c..ec10cd8 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -44,7 +44,6 @@
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
> -#ifndef CONFIG_SPL_BUILD
>  /* Define the default GPT table for eMMC */
>  #define PARTS_DEFAULT \
>  	/* Linux partitions */ \
> @@ -122,6 +121,7 @@
>  	DFU_ALT_INFO_QSPI
>  
>  /* Fastboot */
> +#ifndef CONFIG_SPL_BUILD
>  #define CONFIG_USB_FUNCTION_FASTBOOT
>  #define CONFIG_CMD_FASTBOOT
>  #define CONFIG_ANDROID_BOOT_IMAGE
> @@ -331,5 +331,4 @@
>  /* pcf support */
>  #define CONFIG_PCF8575
>  #define CONFIG_SYS_I2C_PCF8575_CHIP { {0x21, 0xeaf7} }
> -
>  #endif /* __CONFIG_DRA7XX_EVM_H */
> diff --git a/include/configs/ti_omap5_common.h
> b/include/configs/ti_omap5_common.h index 59f0f70..f9c6576 100644
> --- a/include/configs/ti_omap5_common.h
> +++ b/include/configs/ti_omap5_common.h
> @@ -66,7 +66,6 @@
>  #define DFUARGS
>  #endif
>  
> -#ifndef CONFIG_SPL_BUILD
>  #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>  	DEFAULT_LINUX_BOOT_ENV \
> @@ -136,7 +135,6 @@
>  	"setenv mmcroot /dev/mmcblk0p2 rw; " \
>  	"run mmcboot;" \
>  	""
> -#endif
>  
>  /*
>   * SPL related defines.  The Public RAM memory map the ROM defines
> the



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [RFC PATCH 0/5] SPL: DFU Support in SPL

[Marek Vasut]

On 05/27/2016 03:39 PM, Ravi Babu wrote:
> Traditionally the DFU support is available only
> as part 2nd stage boot loader(u-boot) and DFU
> is not supported in SPL.
> 
> The SPL-DFU feature is useful for boards which has
> only USB inteface and do not have external interface
> like ethernet or MMC/SD to boot the board.
> 
> This patch adds DFU support in SPL to flash binary
> images to factory or bare-metal boards to memory 
> devices like SPI, eMMC, MMC/SD card using
> USB interface. 
> As a reference, refer to application note [3] on SPL-DFU
> support based on 2014.07 u-boot.
> 
> Note: I could not find better option to isolate dfu source
> to include/exclude in Makefile when SPL-DFU feature 
> enabled/disabled, please suggest any better option.
> 
> Tested on dra7xx SoCs family. 
> [1] is EVM console output with SPL-DFU/SPI enabled.
> [2] is ubuntu host console output.
> 
> references:
> [1] http://pastebin.ubuntu.com/16730701/
> [2] http://pastebin.ubuntu.com/16730765/
> [3] http://www.ti.com/lit/an/sprac33/sprac33.pdf 
> 
> Ravi Babu (5):
>   spl: dfu: add dfu support in SPL
>   spl: dfu: fs: adding ext4/fat filesystem support for SPL-DFU
>   spl: dfu: adding dfu support functions for SPL-DFU
>   dfu: spl: add generic spl-dfu function in common-spl
>   dra7x: spl: dfu: adding SPL-DFU support for dra7x platform
> 
>  Kconfig                           |   40 +++++++++++++++++++++++++++++++++++++
>  board/ti/dra7xx/evm.c             |   20 +++++++++++++++++++
>  cmd/Makefile                      |   20 ++++++++++++++++++-
>  common/Makefile                   |   32 ++++++++++++++++++++---------
>  common/command.c                  |    2 +-
>  common/spl/spl.c                  |   11 ++++++++++
>  drivers/dfu/dfu.c                 |   28 ++++++++++++++++++++++++++
>  drivers/dfu/dfu_mmc.c             |   28 ++++++++++++++++++++++++++
>  drivers/mmc/Makefile              |    3 +--
>  drivers/mmc/mmc_private.h         |    2 +-
>  fs/Makefile                       |   12 ++++++++++-
>  include/configs/dra7xx_evm.h      |    3 +--
>  include/configs/ti_omap5_common.h |    2 --
>  include/dfu.h                     |    8 ++++++++
>  include/spl.h                     |    1 +
>  scripts/Makefile.spl              |   13 ++++++++++++
>  16 files changed, 206 insertions(+), 19 deletions(-)
> 
+CC Lukasz , this is his turf

-- 
Best regards,
Marek Vasut