SPL: DFU Support in SPL

RFC PATCH New Ravi Babu 5 participants 33 messages May 27, 2016 – Jun 3, 2016

Subsystems (3)

VFS Kbuild MMC, SD and SDIO

lore

Share & tools

lore

Ravi Babu

author

2016-05-27 13:39 UTC #0 lore raw

cover SPL: DFU Support in SPL

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(-)

Signature · 1 line

1.7.9.5

Ravi Babu

author

2016-05-27 13:39 UTC #1 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

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 <[email protected]>

---
 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(-)

Kconfig +40 -0

index f53759a..8c033d0 100644
@@ -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"

cmd/Makefile +10 -1

index f95759e..139189e 100644
@@ -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

common/Makefile +20 -8

index b23f312..3576fac 100644
@@ -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

common/command.c +1 -1

index e5d9b9c..d1c049c 100644
@@ -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) {

drivers/mmc/Makefile +1 -2

index 585aaf3..7abac59 100644
@@ -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

drivers/mmc/mmc_private.h +1 -1

index d3f6bfe..d221362 100644
@@ -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);

scripts/Makefile.spl +13 -0

index ec8d8f1..6e9a589 100644
@@ -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/

Signature · 1 line

1.7.9.5

Lukasz Majewski

2016-05-30 11:54 UTC #2 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

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).

Quoted 90 lines

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 <[email protected]>

---
 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(-)

Kconfig +0 -0

index f53759a..8c033d0 100644
@@ -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.

Kconfig +2 -0

+config SPL_DFU
+	bool "Enable SPL with DFU to load binaries to bootdevices

using USB"

Kconfig +3 -0

+	depends on USB && CMD_DFU
+	help
+	  Normally with the SPL only image does not have capability

Kconfig +1 -0

+	  load the binaries or boot images to boot devices like

eMMC,SPI,etc.

Kconfig +1 -0

+	  This feature enables the DFU (Device Firmware Upgarde) in

SPL with

Kconfig +1 -0

+	  eMMC device as default bootdevice. The ROM code will load

and execute

Kconfig +1 -0

+	  the SPL/MLO dfu image. The user can flash the binaries to

selected

Kconfig +2 -0

+	  dfu device partition from host-pc using dfu-utils.
+		This feature will be useful to flash the binaries to

factory

Kconfig +29 -0

+	  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"

cmd/Makefile +0 -0

index f95759e..139189e 100644

cmd/Makefile line 8

Quoted 4 lines

cmd/Makefile +1 -0

@@ -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.

Quoted 18 lines

cmd/Makefile +6 -1

+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

cmd/Makefile obj-$(CONFIG_CMD_SCSI) += scsi.o · line 171

Quoted 5 lines

cmd/Makefile +2 -0

@@ -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.

Quoted 80 lines

cmd/Makefile +1 -0

+endif
 obj-$(CONFIG_CMD_BLOB) += blob.o
 
 # core command

common/Makefile +20 -8

index b23f312..3576fac 100644
@@ -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

common/command.c +1 -1

index e5d9b9c..d1c049c 100644
@@ -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) {

drivers/mmc/Makefile +0 -0

index 585aaf3..7abac59 100644

drivers/mmc/Makefile obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o · line 46

Quoted 4 lines

drivers/mmc/Makefile +1 -0

@@ -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?

Quoted 52 lines

drivers/mmc/Makefile +0 -2

 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

drivers/mmc/mmc_private.h +1 -1

index d3f6bfe..d221362 100644
@@ -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);

scripts/Makefile.spl +13 -0

index ec8d8f1..6e9a589 100644
@@ -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/

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-30 13:43 UTC #3 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 8 lines · Lukasz Majewski

Hi Ravi,
Thanks for adding this functionality to DFU.
Please find below organizational tips:

Quoted 8 lines

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

Quoted 93 lines

Quoted 93 lines
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 <[email protected]>
---
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(-)
Kconfig +0 -0
index f53759a..8c033d0 100644
@@ -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.
Kconfig +2 -0
+config SPL_DFU
+    bool "Enable SPL with DFU to load binaries to bootdevices
using USB"
Kconfig +3 -0
+    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
Kconfig +2 -0
+      dfu device partition from host-pc using dfu-utils.
+        This feature will be useful to flash the binaries to
factory
Kconfig +29 -0
+      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"
cmd/Makefile +0 -0
index f95759e..139189e 100644
@@ -5,6 +5,13 @@
 # SPDX-License-Identifier:    GPL-2.0+
 #
 

Quoted 9 lines

cmd/Makefile line 8
Quoted 1 line
cmd/Makefile +1 -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.

Quoted 101 lines

Quoted 21 lines
cmd/Makefile +6 -0
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_COMMON=n
+endif
+endif
+
ifndef CONFIG_SPL_BUILD
# core command
obj-y += boot.o
cmd/Makefile +0 -0
@@ -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
cmd/Makefile +0 -0
@@ -161,6 +167,9 @@ obj-$(CONFIG_CMD_SCSI) += scsi.o
endif
endif # CONFIG_SPL_BUILD
cmd/Makefile obj-$(CONFIG_CMD_SCSI) += scsi.o · line 171
Quoted 2 lines
cmd/Makefile +2 -0
+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.
Quoted 70 lines
+endif
obj-$(CONFIG_CMD_BLOB) += blob.o
# core command
common/Makefile +9 -4
index b23f312..3576fac 100644
@@ -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
common/Makefile +11 -0
+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
common/Makefile +0 -0
@@ -34,9 +50,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o
# environment
common/Makefile +0 -3
-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
common/Makefile +0 -0
@@ -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
common/command.c +0 -0
index e5d9b9c..d1c049c 100644
@@ -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;
 

Quoted 17 lines

Quoted 10 lines
common/command.c +1 -1
-#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) {
drivers/mmc/Makefile +0 -0
index 585aaf3..7abac59 100644
@@ -43,11 +43,10 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
Quoted 4 lines
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.

Quoted 39 lines

Quoted 39 lines
ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
drivers/mmc/Makefile +0 -2
-else
-obj-$(CONFIG_GENERIC_MMC) += mmc_write.o
endif
obj-$(CONFIG_PIC32_SDHCI) += pic32_sdhci.o obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
drivers/mmc/mmc_private.h +1 -1
index d3f6bfe..d221362 100644
@@ -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);
scripts/Makefile.spl +0 -0
index ec8d8f1..6e9a589 100644
@@ -35,6 +35,13 @@ else
SPL_BIN := u-boot-spl
endif
scripts/Makefile.spl +7 -0
+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

Quoted 16 lines

Quoted 10 lines
scripts/Makefile.spl +0 -0
@@ -56,6 +63,12 @@ libs-y += common/init/
libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/ libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/ libs-y += drivers/
scripts/Makefile.spl +6 -0
+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
Quoted 3 lines
libs-y += dts/
libs-y += fs/ libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/

Regards
Ravi

Quoted 6 lines

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Lukasz Majewski

2016-05-30 14:59 UTC #4 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 14 lines

Hi Lukasz
Quoted 12 lines
On 30-May-2016, at 5:24 PM, Lukasz Majewski
<[email protected]> 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).

Quoted 8 lines

Quoted 5 lines
- 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.

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-31 06:39 UTC #5 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Lukasz

Quoted 20 lines

Quoted 20 lines
Hi Lukasz
Quoted 17 lines
On 30-May-2016, at 5:24 PM, Lukasz Majewski <[email protected]> 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).

Quoted 4 lines

Quoted 2 lines
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

Lukasz Majewski

2016-05-31 08:39 UTC #6 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 25 lines

Lukasz
Quoted 22 lines
Quoted 22 lines
Hi Lukasz
Quoted 9 lines
On 30-May-2016, at 5:24 PM, Lukasz Majewski
<[email protected]> wrote:
Hi Ravi,
Thanks for adding this functionality to DFU.
Please find below organizational tips:
Quoted 8 lines
- 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.

Quoted 6 lines

Quoted 2 lines
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).

Quoted 4 lines

Regards
Ravi

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-31 09:04 UTC #7 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lucasz

Thanks for active support.

Quoted 10 lines

Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
- 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.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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

Lukasz Majewski

2016-05-31 09:55 UTC #8 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 21 lines

Hi Lucasz
Thanks for active support.
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
- 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).
Quoted 5 lines
Quoted 2 lines
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.

Quoted 9 lines

Quoted 2 lines
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.

Quoted 10 lines

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).

Quoted 6 lines

Any suggestion ?
Regards
Ravi

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-31 10:34 UTC #9 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 21 lines

Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 1 line

Quoted 1 line
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.

Quoted 6 lines

Quoted 6 lines
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).

Quoted 8 lines

Quoted 6 lines
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

Lukasz Majewski

2016-05-31 12:47 UTC #10 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 24 lines

Hi Lukasz
Quoted 21 lines
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 2 lines
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.

Quoted 6 lines

Quoted 4 lines
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.

Quoted 2 lines

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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 2 lines

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?

Quoted 33 lines

Further dfu support for
mmc/sd, ram available from u-boot.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 11 lines
Quoted 11 lines
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.
Quoted 6 lines
Quoted 3 lines
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

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-31 13:31 UTC #11 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 7 lines

Quoted 2 lines
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.

Quoted 9 lines

Quoted 5 lines
Quoted 3 lines
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 ?

Quoted 7 lines

Quoted 2 lines
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

Lukasz Majewski

2016-05-31 15:13 UTC #12 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 5 lines

Hi Lukasz
Quoted 2 lines
Quoted 2 lines
without fat/ext4, mmc support. But all device support may increase size.

Quoted 7 lines

Quoted 5 lines
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.

Quoted 5 lines

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

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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.

Quoted 4 lines

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

Quoted 8 lines

Quoted 6 lines
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.

Quoted 8 lines

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).

Quoted 14 lines

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

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-06-02 12:39 UTC #13 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 13 lines

Quoted 8 lines
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).

Quoted 7 lines

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

Lukasz Majewski

2016-06-02 14:14 UTC #14 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 26 lines

Hi Lukasz
Quoted 23 lines
Quoted 8 lines
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

Quoted 7 lines

Quoted 3 lines
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.

Quoted 4 lines

Regards
Ravi

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-06-02 14:22 UTC #15 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 13 lines

Quoted 13 lines
Quoted 11 lines
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).

Quoted 4 lines

Quoted 2 lines
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.

Quoted 2 lines

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

Lukasz Majewski

2016-06-03 09:27 UTC #16 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 18 lines

Hi Lukasz
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 5 lines

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

Quoted 10 lines

Quoted 4 lines
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

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-06-03 11:35 UTC #17 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Lukasz

Quoted 25 lines

Quoted 8 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 5 lines
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

Lukasz Majewski

2016-06-03 11:45 UTC #18 lore raw

RFC PATCH 1/5 spl: dfu: add dfu support in SPL

Hi Ravi,

Quoted 39 lines

Hi Lukasz
Quoted 36 lines
Quoted 8 lines
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 5 lines

Quoted 1 line
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.

Quoted 3 lines

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.

Quoted 2 lines

Thanks Lukasz for great support.

No problem :-)

Quoted 4 lines

Regards
Ravi

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Ravi Babu

author

2016-05-27 13:39 UTC #19 lore raw

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

In reply to 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 <[email protected]>

---
 cmd/Makefile    |    9 +++++++++
 common/Makefile |    4 +++-
 fs/Makefile     |   12 +++++++++++-
 3 files changed, 23 insertions(+), 2 deletions(-)

cmd/Makefile +9 -0

index 139189e..ad89e09 100644
@@ -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

common/Makefile +3 -1

index 3576fac..99de9e1 100644
@@ -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

fs/Makefile +11 -1

index 51d06fc..d4490a9 100644
@@ -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/

Signature · 1 line

1.7.9.5

Lukasz Majewski

2016-05-30 11:59 UTC #20 lore raw

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

Hi Ravi,

Quoted 16 lines

Adding ext4/fat filesytem support for SPL-DFU to
write ext4/fat files to eMMC, MMC/SD device
Signed-off-by Ravi Babu <[email protected]>
---
 cmd/Makefile    |    9 +++++++++
 common/Makefile |    4 +++-
 fs/Makefile     |   12 +++++++++++-
 3 files changed, 23 insertions(+), 2 deletions(-)
cmd/Makefile +0 -0
index 139189e..ad89e09 100644
@@ -12,6 +12,15 @@ CONFIG_INC_COMMON=n
 endif

cmd/Makefile CONFIG_INC_COMMON=n · line 22

Quoted 10 lines

cmd/Makefile +8 -0

 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 ?

Quoted 43 lines

cmd/Makefile +1 -0

+
 ifndef CONFIG_SPL_BUILD
 # core command
 obj-y += boot.o

common/Makefile +3 -1

index 3576fac..99de9e1 100644
@@ -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

fs/Makefile +9 -0

index 51d06fc..d4490a9 100644
@@ -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

fs/Makefile line 26

Quoted 10 lines

fs/Makefile +2 -1

+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)?

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-30 12:52 UTC #21 lore raw

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

Hi Lukasz

Quoted 22 lines · Lukasz Majewski

Hi Ravi,
Quoted 18 lines
Adding ext4/fat filesytem support for SPL-DFU to
write ext4/fat files to eMMC, MMC/SD device
Signed-off-by Ravi Babu <[email protected]>
---
cmd/Makefile    |    9 +++++++++
common/Makefile |    4 +++-
fs/Makefile     |   12 +++++++++++-
3 files changed, 23 insertions(+), 2 deletions(-)
cmd/Makefile +0 -0
index 139189e..ad89e09 100644
@@ -12,6 +12,15 @@ CONFIG_INC_COMMON=n
endif
endif

Quoted 12 lines

cmd/Makefile CONFIG_INC_COMMON=n · line 22
Quoted 8 lines
cmd/Makefile +8 -0
+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.

Quoted 51 lines

Quoted 51 lines
+
ifndef CONFIG_SPL_BUILD
# core command
obj-y += boot.o
common/Makefile +0 -0
index 3576fac..99de9e1 100644
@@ -24,6 +24,9 @@ obj-y += env_attr.o
obj-y += env_callback.o
obj-y += env_flags.o
obj-y += cli.o
common/Makefile +3 -0
+ifdef CONFIG_CMD_USB
+obj-$(CONFIG_USB_STORAGE) += usb_storage.o
+endif
endif
ifndef CONFIG_SPL_BUILD
common/Makefile +0 -0
@@ -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
fs/Makefile +11 -0
index 51d06fc..d4490a9 100644
@@ -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

Quoted 7 lines

Quoted 2 lines
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.

Quoted 6 lines

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Lukasz Majewski

2016-05-30 13:20 UTC #22 lore raw

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

Hi Ravi,

Quoted 5 lines

Quoted 3 lines
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.

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-30 13:52 UTC #23 lore raw

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

Lucasz

Quoted 9 lines · Lukasz Majewski

Hi Ravi,
Quoted 4 lines
Quoted 2 lines
How large could be the SPL code for your board (dra7x)?
The SPL code size is about 152K.

Quoted 8 lines

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.

Quoted 6 lines

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Ravi Babu

author

2016-05-27 13:39 UTC #24 lore raw

RFC PATCH 3/5 spl: dfu: adding dfu support functions for SPL-DFU

In reply to Ravi Babu

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

Signed-off-by Ravi Babu <[email protected]>

---
 drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
 drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
 include/dfu.h         |    8 ++++++++
 3 files changed, 64 insertions(+)

drivers/dfu/dfu.c +28 -0

index 20dfcbb..1d4690b 100644
@@ -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;
+}

drivers/dfu/dfu_mmc.c +28 -0

index faece88..28517e8 100644
@@ -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);
+}

include/dfu.h +8 -0

index f39d3f1..0bc75bc 100644
@@ -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_ */

Signature · 1 line

1.7.9.5

Heiko Schocher

2016-05-30 05:27 UTC #25 lore raw

RFC PATCH 3/5 spl: dfu: adding dfu support functions for SPL-DFU

Hello Ravi,

Am 27.05.2016 um 15:39 schrieb Ravi Babu:

Quoted 35 lines

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

Signed-off-by Ravi Babu <[email protected]>

---
  drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
  drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
  include/dfu.h         |    8 ++++++++
  3 files changed, 64 insertions(+)

drivers/dfu/dfu.c +10 -0

index 20dfcbb..1d4690b 100644
@@ -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);

drivers/dfu/dfu.c int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size) · line 618

Quoted 10 lines

drivers/dfu/dfu.c +10 -0

+	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

Signature · 2 lines

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

Lukasz Majewski

2016-05-30 12:04 UTC #26 lore raw

RFC PATCH 3/5 spl: dfu: adding dfu support functions for SPL-DFU

In reply to Ravi Babu

Hi Ravi,

Quoted 105 lines

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

Signed-off-by Ravi Babu <[email protected]>

---
 drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
 drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
 include/dfu.h         |    8 ++++++++
 3 files changed, 64 insertions(+)

drivers/dfu/dfu.c +12 -0

index 20dfcbb..1d4690b 100644
@@ -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");

drivers/dfu/dfu.c +6 -0

+		return -EINVAL;
+	}
+
+	ret = setenv("dfu_alt_info", str_env);
+	if (ret) {
+		error("unable to set env variable

\"dfu_alt_info\"!\n");

drivers/dfu/dfu.c +10 -0

+		return -EINVAL;
+	}
+
+	/* invoke dfu command */
+	ret = run_command(dfu_cmd_str, 0);
+	if (ret)
+		error("dfu: error = %d\n", ret);
+
+	return ret;
+}

drivers/dfu/dfu_mmc.c +28 -0

index faece88..28517e8 100644
@@ -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);
+}

include/dfu.h +0 -0

index f39d3f1..0bc75bc 100644
@@ -274,4 +274,12 @@ static inline int dfu_tftp_write(char
 *dfu_entity_name, unsigned int addr, #endif

include/dfu.h static inline int dfu_tftp_write(char · line 285

Quoted 10 lines

include/dfu.h +8 -0

 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

Signature · 5 lines

Best regards,

Lukasz Majewski

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

B

2016-05-30 12:49 UTC #27 lore raw

RFC PATCH 3/5 spl: dfu: adding dfu support functions for SPL-DFU

Hi Lukasz

Quoted 122 lines · Lukasz Majewski

Hi Ravi,

Quoted 105 lines

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

Signed-off-by Ravi Babu <[email protected]>

---

drivers/dfu/dfu.c     |   28 ++++++++++++++++++++++++++++
drivers/dfu/dfu_mmc.c |   28 ++++++++++++++++++++++++++++
include/dfu.h         |    8 ++++++++
3 files changed, 64 insertions(+)

drivers/dfu/dfu.c +12 -0

index 20dfcbb..1d4690b 100644
@@ -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");

drivers/dfu/dfu.c +6 -0

+        return -EINVAL;
+    }
+
+    ret = setenv("dfu_alt_info", str_env);
+    if (ret) {
+        error("unable to set env variable

\"dfu_alt_info\"!\n");

drivers/dfu/dfu.c +10 -0

+        return -EINVAL;
+    }
+
+    /* invoke dfu command */
+    ret = run_command(dfu_cmd_str, 0);
+    if (ret)
+        error("dfu: error = %d\n", ret);
+
+    return ret;
+}

drivers/dfu/dfu_mmc.c +28 -0

index faece88..28517e8 100644
@@ -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);
+}

include/dfu.h +0 -0

index f39d3f1..0bc75bc 100644
@@ -274,4 +274,12 @@ static inline int dfu_tftp_write(char
 *dfu_entity_name, unsigned int addr, #endif

include/dfu.h static inline int dfu_tftp_write(char · line 285

Quoted 10 lines

include/dfu.h +8 -0

 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:

Quoted 7 lines

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

Quoted 6 lines

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Ravi Babu

author

2016-05-27 13:39 UTC #28 lore raw

RFC PATCH 4/5 dfu: spl: add generic spl-dfu function in common-spl

In reply to 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 <[email protected]>

---
 common/spl/spl.c |   11 +++++++++++
 include/spl.h    |    1 +
 2 files changed, 12 insertions(+)

common/spl/spl.c +11 -0

index 82e7f58..ef6d2d1 100644
@@ -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++) {

include/spl.h +1 -0

index 5f0b0db..5794b05 100644
@@ -158,4 +158,5 @@ void spl_board_init(void);
  */
 bool spl_was_boot_source(void);
 
+int spl_run_dfu(void);
 #endif

Signature · 1 line

1.7.9.5

Lukasz Majewski

2016-05-30 12:07 UTC #29 lore raw

RFC PATCH 4/5 dfu: spl: add generic spl-dfu function in common-spl

Hi Ravi,

Quoted 44 lines

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 <[email protected]>

---
 common/spl/spl.c |   11 +++++++++++
 include/spl.h    |    1 +
 2 files changed, 12 insertions(+)

common/spl/spl.c +11 -0

index 82e7f58..ef6d2d1 100644
@@ -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++) {

include/spl.h +0 -0

index 5f0b0db..5794b05 100644

include/spl.h void spl_board_init(void); · line 162

Quoted 5 lines

include/spl.h +1 -0

@@ -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 <[email protected]>

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Ravi Babu

author

2016-05-27 13:39 UTC #30 lore raw

RFC PATCH 5/5 dra7x: spl: dfu: adding SPL-DFU support for dra7x platform

In reply to 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 <[email protected]>

---
 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(-)

board/ti/dra7xx/evm.c +20 -0

index f194999..0ce0e97 100644
@@ -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;

include/configs/dra7xx_evm.h +1 -2

index da84f1c..ec10cd8 100644
@@ -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 */

include/configs/ti_omap5_common.h +0 -2

index 59f0f70..f9c6576 100644
@@ -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

Signature · 1 line

1.7.9.5

Lukasz Majewski

2016-05-30 12:19 UTC #31 lore raw

RFC PATCH 5/5 dra7x: spl: dfu: adding SPL-DFU support for dra7x platform

Hi Ravi,

Quoted 25 lines

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 <[email protected]>
---
 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(-)
board/ti/dra7xx/evm.c +1 -0
index f194999..0ce0e97 100644
@@ -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"

board/ti/dra7xx/evm.c int spl_start_uboot(void) · line 627

Quoted 8 lines

board/ti/dra7xx/evm.c +5 -0

@@ -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?

board/ti/dra7xx/evm.c int spl_start_uboot(void) · line 636

Quoted 9 lines

board/ti/dra7xx/evm.c +9 -0

+#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?

Quoted 55 lines

board/ti/dra7xx/evm.c +5 -0

+#endif
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_DRIVER_TI_CPSW
 extern u32 *const omap_si_rev;

(quoted diff) +0 -0

b/include/configs/dra7xx_evm.h index da84f1c..ec10cd8 100644

include/configs/dra7xx_evm.h +1 -2

@@ -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 */

(quoted diff) +0 -0

b/include/configs/ti_omap5_common.h index 59f0f70..f9c6576 100644

include/configs/ti_omap5_common.h +0 -2

@@ -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

Signature · 5 lines

Best regards,

Lukasz Majewski

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

Marek Vasut

2016-05-27 13:42 UTC #32 lore raw

cover SPL: DFU Support in SPL

In reply to Ravi Babu

Quoted 44 lines · 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 +--

Quoted 9 lines

 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

Signature · 2 lines

Best regards,
Marek Vasut