Lukasz
Ping !!
Did you get time to look into these patches.
Regards
Ravi
-Original Message-
From: B, Ravi
Sent: Tuesday, June 14, 2016 4:32 PM
To: u-boot@lists.denx.de; l.majew...@samsung.com
Cc: tr...@konsulko.com; ma...@denx.de; B, Ravi
Subject: [RFC PATCH v1 0/6] SPL: DFU Support
Hi Lukasz
> > 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
> > b
> > diff --git a/include/spl.h b/include/spl.h index af02a6d..8849678
> > 100644
> > --- a/include/spl.h
> > +++ b/include/spl.h
> > @@ -139,4 +139,14 @@ void spl_board_init(void);
> > */
> > bool spl_was_boot_source(void);
> >
> > +/* spl dfu functions */
> > +/* spl_dfu_mmc - run dfu comman
Hi Lukasz
>> /* USB Device Firmware Update support */ #define
>> CONFIG_USB_FUNCTION_DFU #define CONFIG_DFU_RAM
>> -
>> -#define CONFIG_DFU_MMC
>> -#define CONFIG_DFU_RAM
>Please correct me if I am wrong, but from this patch it seems like you disable
>MMC and RAM DFU support in the fully-fle
Hi Lukasz
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "mux_data.h"
>> #include "../common/board_detect.h"
>> @@ -706,6 +707,22 @@ int spl_start_uboot(void) } #endif
>>
>> +#ifdef CONFIG_SPL_DFU
>> +int spl_run_dfu(void)
>We can replace int with bool here.
Ok, m
Hi Lukasz
>>
>> config SPL_DFU
>> bool "Enable SPL with DFU to load binaries to bootdevices using USB"
>> -depends on USB && CMD_DFU && TARGET_DRA7XX_EVM
>> +depends on USB && CMD_DFU && (TARGET_DRA7XX_EVM ||
>Here also please remove not needed dependencies (CMD_DFU).
Ok. Will re
Hi Marek
>> The crash at dwc3 driver observed due to offset misalignment of
>> structure members across files causing wrong code generation and leads
>> to crash, the issue is found during dfu test.
>>
>> For instance, ther is is mismatch in code generation to access the
>> address of structur
Hi Marek
>>> Please explain why this patch fixes the issue.
>>
>> Ok I will explain, due to the commit[1] the resource_size_t size has
>> increased to 8 bytes (64 bit), compared to earlier 32 bit (4bytes) and the
>> definition is moved to includes/linux/types.h from asm.h. Due to this change
Hi Marek
>>
> Please explain why this patch fixes the issue.
Ok I will explain, due to the commit[1] the resource_size_t size has
increased to 8 bytes (64 bit), compared to earlier 32 bit (4bytes) and the
definition is moved to includes/linux/types.h from asm.h. Due to
Hi Masahiro-san
>>
>>>Please explain why this patch fixes the issue.
>>
>> Ok I will explain, due to the commit[1] the resource_size_t size has
>> increased to 8 bytes (64 bit), compared to earlier 32 bit (4bytes) and the
>> definition is moved to includes/linux/types.h from asm.h. Due to this c
Tom
> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Rini
> Sent: Saturday, April 09, 2016 1:14 AM
> To: Sam Protsenko
> Cc: Marek Vasut; Steve Rae; U-Boot Mailing List
> Subject: Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be
>
Hi Lukasz
> On 30-May-2016, at 5:34 PM, Lukasz Majewski wrote:
>
> Hi Ravi,
>
>> Adding support functions to run dfu commands
>> with support for eMMC/MMC/SD memory device.
>>
>> Signed-off-by: Ravi Babu
>> ---
>> drivers/dfu/dfu.c | 28
>> drivers/dfu/dfu_m
Hi Lukasz
> On 30-May-2016, at 5:30 PM, Lukasz Majewski 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
>> ---
>> cmd/Makefile|9 +
>> common/Makefile |4 +++-
>> fs/Mak
Hi Lukasz
> On 30-May-2016, at 5:24 PM, Lukasz Majewski 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).
>
> - Woul
Lucasz
> On 30-May-2016, at 6:51 PM, Lukasz Majewski 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 DF
Lukasz
>> Hi Lukasz
>>
>> > On 30-May-2016, at 5:24 PM, Lukasz Majewski
>> > wrote:
>> >
>> > Hi Ravi,
>> >
>> > Thanks for adding this functionality to DFU.
>> >
>> > Please find below organizational tips:
>> >
>> > - Please use 'patman' (./tools/patman/patman) tool when sending
>> > patc
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
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
>>
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 increm
Hi Lukasz
>> The problem here is, how o flash the images first time to fresh
>> boards toQSPI 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 S
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 ou
Hi Tom
>> Avoid use of hard coded mmcdev value so finduuid works based on
>> current mmcdev selected.
>>
>> Signed-off-by: Ravi Babu
>> ---
>> include/configs/ti_armv7_common.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/configs/ti_armv7_common.h
>>
Hi
>>> #define DEFAULT_MMC_TI_ARGS \
>>> "mmcdev=0\0" \
>>> "mmcrootfstype=ext4 rootwait\0" \
>>> - "finduuid=part uuid mmc 0:2 uuid\0" \
>>> + "finduuid=part uuid mmc ${mmcdev}:2 uuid\0" \
>>> "args_mmc=run finduuid;setenv bootargs console=${console} " \
>>> "${optarg
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
Hi Tom
>> diff --git a/include/configs/ti_armv7_common.h
>> b/include/configs/ti_armv7_common.h
>> index 7db0881..bbff06b 100644
>> --- a/include/configs/ti_armv7_common.h
>> +++ b/include/configs/ti_armv7_common.h
>> @@ -59,7 +59,7 @@
>> #define DEFAULT_MMC_TI_ARGS \
>> "mmcdev=0\0" \
>>
Tom
>> The SPL size for dra7x platform increased beyond 64K, increasing the
>> size to 256K to cater for future enhancement.
>>
>> Signed-off-by: Ravi Babu
>Have you tested this with a larger SPL to confirm that the ROM will read more
>than one sector?
Yes, I have tested SPL size upto 160KB,
Hi Simon
>On 26 September 2016 at 06:56, Ravi Babu wrote:
>> By default saveenv option is not supported for SPL. This patch enable
>> the support for save environment variable for SPL build.
>>
>> Enable save environment support in SPL after setenv. By default the
>> saveenv option is not provi
Drop this send wrong version
Regards
Ravi
-Original Message-
From: B, Ravi
Sent: Wednesday, September 28, 2016 2:43 PM
To: u-boot@lists.denx.de
Cc: tr...@konsulko.com; s...@chromium.org; jh80.ch...@samsung.com; Vutla,
Lokesh; B, Ravi
Subject: [PATCH] spl: saveenv: adding saveenv
Hi Lukasz
>> Adding support functions to run dfu spl commands.
>>
>> Signed-off-by: Ravi Babu
>> ---
>> common/spl/Makefile |1 +
>> common/spl/spl_dfu.c | 57
>> ++
>> include/spl.h|8 +++ 3 files changed, 66 insertions(+)
>>
Hi Lukasz
>> +++ b/common/dfu.c
>> @@ -0,0 +1,88 @@
>> +/*
>> + * dfu.c -- dfu command
>Please write:
>dfu.c -- common dfu command code
Ok.
>> + *
>> + * Copyright (C) 2015
>> + * Lukasz Majewski
>> + *
>> + * Copyright (C) 2012 Samsung Electronics
>> + * authors: Andrzej Pietrasiewicz
>> +
Hi Tom
>> +++ b/arch/arm/include/asm/arch-omap5/spl.h
>> @@ -20,7 +20,7 @@
>> #define BOOT_DEVICE_QSPI_1 0x0A
>> #define BOOT_DEVICE_QSPI_4 0x0B
>> #define BOOT_DEVICE_UART0x43
>> -#define BOOT_DEVICE_USB 0x45
>> +#define BOOT_DEVICE_DFU 0x45
>So you're breaking r
Tom
>> 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 does not have MMC/SD,
>> ethernet boot mechanism to boot the board and only has USB inteface.
>How well did you
Hi Tom
>>
>> You are correct. This platform does not support BOOT_DEVICE_USB support.
>> The BOOT_DEVICE_USB is basically the USBHOST-MSC support
>> (CONFIG_SPL_USB_SUPPORT), i.e, boot from mass storage device.
>So, we have 3 SoCs that share these values here, and we need to be correct for
>al
Tom
>> >How well did you test DFU on other platforms after these changes?
>> >Thanks
>>
>> Actually earlier platforms did not had this support, support for
>> either RNDIS boot mode (CONFIG_SPL_USBETH_SUPPORT) or CONFIG_SPL_USB_SUPPORT
>> (boot from mass-storage device) were only supported.
>
Hi Tom
>> I got your point, You are referring to generic dfu code changes, that
>> is moving common dfu code to common/dfu.c , so that both u-boot and SPL can
>> leverage common code. But this change is generic cleanup code.
>> Yes, I did test DFU functionality on other platforms (say AM335X).
Tom
>> based on phys_addr_t, so it triggered
>> the problem for DWC3, which had already potentially existed.
>>
>>
>> CONFIGs in Kconfig are guaranteed to be defined for all files, but
>> CONFIGs in board headers are not.
>>
>> So we need to make sure to add
>> #include (or #include ) in each
Hi Tom
>> >> So, your patch is doing a right thing.
>> >>
>> >> I will issue my Reviewed-by when you update the git-log.
>> >>
>> >>
>> >> (Moving CONFIG_PHYS_64BIT is a right thing as well)
>>
>> >Can we move PHYS_64BIT to Kconfig instead here please? This is the kind of
>> >thing we should
Hi Tom
Missed this thread to reply.
>> index ef12f9f..ed3e295 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -336,6 +336,33 @@ config SPL_FIT_IMAGE_POST_PROCESS
>>injected into the FIT creation (i.e. the blobs would have been pre-
>>processed before being added to the FIT image).
Tom
> On 27-Jul-2016, at 8:55 PM, Tom Rini wrote:
>
>> On Wed, Jul 27, 2016 at 02:04:24PM +0000, B, Ravi wrote:
>> Hi Tom
>>
>> Missed this thread to reply.
>>
>>>> index ef12f9f..ed3e295 100644
>>>> --- a/Kconfig
>>>> +
Masahiro-san
>#if !defined(CONFIG_PPC_P5020) && !defined(CONFIG_PPC_P5040) #error Must call
>Cyrus CONFIG with a specific CPU enabled.
>#endif
>diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index
>0d51aeb..a11b692 100644
>--- a/include/configs/dra7xx_evm.h
>+++ b/incl
Masahiro-san
>>#if !defined(CONFIG_PPC_P5020) && !defined(CONFIG_PPC_P5040) #error Must
>>call Cyrus CONFIG with a specific CPU enabled.
>>#endif
>>diff --git a/include/configs/dra7xx_evm.h
>>b/include/configs/dra7xx_evm.h index 0d51aeb..a11b692 100644
>>--- a/include/configs/dra7xx_evm.h
>>+++
Masahiro-san
>>>#if !defined(CONFIG_PPC_P5020) && !defined(CONFIG_PPC_P5040) #error Must
>>>call Cyrus CONFIG with a specific CPU enabled.
>>>#endif
>>>diff --git a/include/configs/dra7xx_evm.h
>>>b/include/configs/dra7xx_evm.h index 0d51aeb..a11b692 100644
>>>--- a/include/configs/dra7xx_evm.h
Masihiro-san
>See, the following hunk
>> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig
>> b/arch/arm/cpu/armv7/omap5/Kconfig
>> index 4fb5ef9..a8600b1 100644
>> --- a/arch/arm/cpu/armv7/omap5/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
>> @@ -13,6 +13,7 @@ config TARGET_OMAP5_UEVM config
Hi Lukasz, Marek
>>
>> is that for master or next ?
>This patch _was_ supposed to go to "master"
>> Was this build tested ?
>Unfortunately, not so thoroughly as I thought.
>Moving dfu code to SPL causes following error on some boards:
> arm: + smartweb
>+In file included from ../i
Hi Heiko
>>>
>>> is that for master or next ?
>>This patch _was_ supposed to go to "master"
>>> Was this build tested ?
>>Unfortunately, not so thoroughly as I thought.
>>Moving dfu code to SPL causes following error on some boards:
>> arm: + smartweb
>>+In file included from ../
+is not an integer constant
+ struct usb_device_descriptor __aligned(CONFIG_SYS_CACHELINE_SIZE) desc;
+ ^
+make[3]: *** [spl/common/dfu.o] Error 1
+make[2]: *** [spl/common] Error 2
>>> +make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
>>
>>
Hi Tom
>>
>> > The CONFIG_SYS_CACHELINE_SIZE is not defined for some of the
>> > platforms due to which buildman iill fail for these platforms.
>> >
>> > Fixing this issue in generic way in Kconfig by selecting cacheline
>> > size based on arm processor type.
>> >
>> > This patch is based on
Hi Lukasz
>> /*
>> * Weak default function for board specific cleanup/preparation
>> before
>> * Linux boot. Some boards/platforms might not need it, so just
>> provide @@ -323,6 +359,9 @@ void board_init_r(gd_t *dummy1, ulong
>> dummy2)
>> debug(">>spl:board_init_r()\n");
>> gd-
Hi
>> diff --git a/arch/arm/mach-omap2/am33xx/board.c
>> b/arch/arm/mach-omap2/am33xx/board.c index 2bfc864..568f36f 100644
>> --- a/arch/arm/mach-omap2/am33xx/board.c
>> +++ b/arch/arm/mach-omap2/am33xx/board.c
>> @@ -327,6 +327,10 @@ void board_init_f(ulong dummy)
>> early_system_init();
>>
Hi Lukasz
>> diff --git a/common/cli.c b/common/cli.c index a433ef2..5e0869b 100644
>> --- a/common/cli.c
>> +++ b/common/cli.c
>> @@ -28,7 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>> */
>> int run_command(const char *cmd, int flag) { -#ifndef
>> CONFIG_HUSH_PARSER
>> +#if defined(CONFIG_SPL_DFU_SUP
Hi Lukasz
>>
>> diff --git a/common/Makefile b/common/Makefile index bcd2486..dc5cb1d
>> 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -90,7 +90,6 @@ endif # !CONFIG_SPL_BUILD
>>
>> ifdef CONFIG_SPL_BUILD
>> obj-$(CONFIG_SPL_DFU_SUPPORT) += dfu.o
>> -obj-$(CONFIG_SPL_DFU_SUP
Hi Lukasz
>>> a/common/cli.c b/common/cli.c index a433ef2..3dd4c2b 100644
>>> --- a/common/cli.c
>>> +++ b/common/cli.c
>>> @@ -28,7 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>> */
>>> int run_command(const char *cmd, int flag) { -#ifndef
>>> CONFIG_HUSH_PARSER
>>> +#if defined(CONFIG_SPL_BUILD) ||
Hi Tom
>> The SPL-DFU feature enable to load and execute u-boot over usb from PC
>> using dfu-util.
>> Hence dfu-reset should not be issued
>> when dfu-util -R switch is issued.
>>
>> Signed-off-by: Ravi Babu
>> ---
>> common/dfu.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git
Hi Tom
>>
>> The SPL-DFU will load and execute u-boot.img from RAM. If we issue
>> dfu-reset (-R switch), this leads to cpu-reset and we lost the purpose
>> of SPL-DFU itself. Hence dfu-reset issue shall not be issued for
>> SPL-DFU.
>>
>> I agree, the dfu-reset is needed in u-boot, after f
Hi Tom
>> Since spl-dfu does not dfu-reset, there is no need of run_command_cli,
>> hence compiling out cli.c and cli_hush.c to reduce the spl-dfu memory
>> foot print.
>>
>> Signed-off-by: Ravi Babu
[snip]
>> diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile index
>> 61f2b71..ef48f36
Lukasz
>> diff --git a/common/dfu.c b/common/dfu.c index 0e9f5f5..fa77526 100644
>> --- a/common/dfu.c
>> +++ b/common/dfu.c
>> @@ -87,6 +87,9 @@ exit:
>> g_dnl_unregister();
>> board_usb_cleanup(usbctrl_index, USB_INIT_DEVICE);
>>
>> +#ifdef CONFIG_SPL_BUILD
>> +dfu_reset = 0;
>>
Lukasz
>> >
>> > The SPL-DFU will load and execute u-boot.img from RAM. If we issue
>> > dfu-reset (-R switch), this leads to cpu-reset and we lost the
>> > purpose of SPL-DFU itself. Hence dfu-reset issue shall not be
>> > issued for SPL-DFU.
>It seems like a valid use case - maybe it woul
Lukasz
>> >
>> > The SPL-DFU will load and execute u-boot.img from RAM. If we issue
>> > dfu-reset (-R switch), this leads to cpu-reset and we lost the
>> > purpose of SPL-DFU itself. Hence dfu-reset issue shall not be
>> > issued for SPL-DFU.
>It seems like a valid use case - maybe it woul
Hi Lukasz
>> > >> +#ifdef CONFIG_SPL_BUILD
>> > >> + dfu_reset = 0;
>> > >> +#endif
>> >
>> > >Why do you only ifdef this part? What problem does this solve?
>> >
>> > Common/dfu.c is common code for SPL and U-boot, for SPL-DFU
>> > dfu_reset should not be given. This is must fix. Also
{Corrected typo u-boot mailing list.}
Hi Lukasz
>> Since spl-dfu does not dfu-reset, there is no need of
>> run_command_cli, hence compiling out cli.c and cli_hush.c to reduce
>> the spl-dfu memory foot print.
>>
[..]
>> */
>> -#ifdef CONFIG_DFU_TFTP
>> +#if defined(CONFIG_DFU_TFTP) && !defi
Hi Tom
>>
>> diff --git a/common/dfu.c b/common/dfu.c index 0e9f5f5..546a1ab 100644
>> --- a/common/dfu.c
>> +++ b/common/dfu.c
>> @@ -88,7 +88,7 @@ exit:
>> board_usb_cleanup(usbctrl_index, USB_INIT_DEVICE);
>>
>> if (dfu_reset)
>> -run_command("reset", 0);
>> +
Hi Tom
>>
>> Yes you are correct.
>> But what is happening here is, the CONFIG_DFU_ selected
>> through Kconfig/Menuconfig is applicable for both SPL and U-Boot.
>> Hence CONFIG_DFU_MMC/NAND/SF gets compiled for SPL as well, which needs
>> run_command(). Actually CONFIG_DFU_MMC/NAND/etc is not
Hi Lukasz,
>>
>> Also changing run_command() to do_reset().
>>
>> If (dfu_reset)
>> do_reset(NULL, 0, 0, NULL);
>+1
>One question - could you write some numbers before SPL dfu tinification and
>afterwards?
>I'm just curious how much we can save up.
I am OOO till May 2nd. Will provide
Hi Tom
>> >> obj-$(CONFIG_USB_FUNCTION_DFU) += dfu.o
>> >> +ifndef CONFIG_SPL_BUILD
>> >> obj-$(CONFIG_DFU_MMC) += dfu_mmc.o
>> >> +endif
>> >> +obj-$(CONFIG_SPL_DFU_MMC) += dfu_mmc.o
>>
>> >This becomes obj-$(CONFIG_$(SPL_)DFU_MMC) += dfu_mmc.o
>>
>> >> diff --git a/drivers/dfu/dfu_mmc.c b/dr
Hi Tom
>> >> >This doesn't make sense. CONFIG_IS_ENABLED(DFU_MMC) is true for
>> >> >CONFIG_DFU_MMC or CONFIG_SPL_DFU_MMC. Thanks!
>> >>
>> >> True, My bad, I realized it lately after posting the patch.
>> >>
>> >> I will use run_command() only, which abstrace use of both
>> >> simple_cli_xx(
Tom
>> >>
>> >> static int dfu_find_alt_num(const char *s)
>>
>> >So do we still need the above, in order to save space? How much are we
>> >saving here even, now? Thanks!
>>
>> I observed around 7K reduced.
>I don't just mean dropping out CLI, I mean after dropping out CLI but leaving
>Tom
>>> >>
>>> >> static int dfu_find_alt_num(const char *s)
>>>
>>> >So do we still need the above, in order to save space? How much are we
>>> >saving here even, now? Thanks!
>>>
>>> I observed around 7K reduced.
Ignore 7K figure provided, that's wrong calculation.
>I don't just mean
Tom
>> >>
>> >> I observed around 7K reduced.
>>
>> >I don't just mean dropping out CLI, I mean after dropping out CLI but
>> >leaving in the reset logic. That's _still_ 7k?
>>
>> Without this fix, with cli_simple_run_command(), size of MLO with default
>> dra7xx_evm_defconfig is 130K.
>> W
Tom
>> >> >I don't just mean dropping out CLI, I mean after dropping out CLI but
>> >> >leaving in the reset logic. That's _still_ 7k?
>> >>
>> >> Without this fix, with cli_simple_run_command(), size of MLO with default
>> >> dra7xx_evm_defconfig is 130K.
>> >> With this fix, compile out cli.
Tom
>>Can you give the exact bytes saved in each case, with your specific compiler?
>> I ask since I'm surprised it's more than a function being dropped by the
>>linker in this case. diff'ing the u-boot-spl.map files would also say what
>>is dropped and I'd be interested in that. > (And >yes,
>-Original Message-
>From: Tom Rini [mailto:tr...@konsulko.com]
>Sent: Tuesday, May 02, 2017 8:24 PM
>To: B, Ravi
>Cc: u-boot@lists.denx.de
>Subject: Re: [U-Boot] [PATCH v2 2/3] common: dfu: ignore reset for spl-dfu
>On Tue, May 02, 2017 at 01:56:45PM +,
Tom
>>>
>>> Yes you are correct.
>>> But what is happening here is, the CONFIG_DFU_ selected
>>> through Kconfig/Menuconfig is applicable for both SPL and U-Boot.
>>> Hence CONFIG_DFU_MMC/NA
>ND/SF gets compiled for SPL as well, which needs run_command(). Actually
>CONFIG_DFU_MMC/NAND/etc is n
Hi Tom
>>
>> >>OK. I think we need to introduce SPL_DFU_xxx Kconfig options, and
>> >>use
>> >>CONFIG_IS_ENABLED(DFU_xxx) so that we will get things enabled/disabled
>> >>(and discarded) as needed.
>>
>> >Ok, will do.
>>
>> Correct me if I am wrong, I need understand if we introduce say
>>
Hi Tom
Sorry for late response, some how missed this mail.
>>
>> obj-$(CONFIG_USB_FUNCTION_DFU) += dfu.o
>> +ifndef CONFIG_SPL_BUILD
>> obj-$(CONFIG_DFU_MMC) += dfu_mmc.o
>> +endif
>> +obj-$(CONFIG_SPL_DFU_MMC) += dfu_mmc.o
>This becomes obj-$(CONFIG_$(SPL_)DFU_MMC) += dfu_mmc.o
>> diff --g
Stefan
> From: Stefan Agner
>This patchset cleans up the SPL USB Gadget Kconfig and Makfile.
>The first two patches are actual fixes and we might consider to add these two
>for the v2016.11 release. The third one adds a new config option for cleaner
>structure. I plan to add another USB functi
Hi Stephen
>>Adding this:
> >config SPL_DFU_SUPPORT
> > bool "Support DFU (Device Firmware Upgarde)"
>- depends on SPL_GADGET_SUPPORT
>+ depends on SPL_USB_GADGET_SUPPORT
>select SPL_HASH_SUPPORT
> help
> This feature enables the DFU (Device Firmware Upgarde
Hi Stefan
>From: Stefan Agner
>This patchset cleans up the SPL USB Gadget Kconfig and Makfile.
>The first two patches are actual fixes and we might consider to add these two
>for the v2016.11 release. The third one adds a new config option >for cleaner
>structure. I plan to add another USB fu
77 matches
Mail list logo
