Hi,
I’m trying to build an SPL image for an iMX7 platform with the following
options active:
CONFIG_SPL=y
CONFIG_SPL_USB_GADGET_SUPPORT=y
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_CMD_USB=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_CI_UDC=y
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_FUNCTION_SDP=y
This leads
> Sweet! Is this s/CONFIG_DM_USB/CONFIG_IS_ENABLED(DM_USB)/ or is there
> some other stuff in the patch too ?
There is also a bunch of CONFIG_BLK replacements.
> If the later is the case, it'd be
> nice to do the s/CONFIG_DM_USB/CONFIG_IS_ENABLED(DM_USB)/ in a separate
> patch, to make the later
Hi again,
> Did you have a chance to run it through travis CI to see if it builds on
> all and every platform ?
This was a really good tip. I discovered a bunch of problems and will basically
replace CONFIG_DM_USB in the entire driver/usb directory. I’ll prepare split
patches.
Sven
an eMMC on this board, that
seems to be the only way to boot when the eMMC is blank/invalid.
Any remarks and suggestions on how to deal with this are appreciated :-)
Best regards,
Sven
> On 12 Nov 2018, at 08:31, Sven Schwermer wrote:
>
> Hi,
>
> I’m trying to build an SPL im
This allows building the SPL without driver model for USB. So far,
support has only been added to the iMX6/7 host driver. Other boards will
keep their existing behaviour.
Signed-off-by: Sven Schwermer
---
This solves the dependency problem I described in [1].
[1]: http://u-boot.10912.n7
>>> This configuration doesn't use USB in the SPL, so we need to disable
>>> driver model for USB in the SPL.
>>>
>>> Signed-off-by: Sven Schwermer
>>
>> How many other boards will need such a patch ?
>
> In this case, "all" am3
Hi!
>> -ifdef CONFIG_CMD_USB
>> +ifdef CONFIG_USB
>
> Shouldn't this be a separate change ?
Do you mean a separate patch set or its own patch? I was actually not 100% sure
about this one but ran into link problems with the status quo. It seemed odd
that this code would depend on the USB
Hi,
> OK, can you resend the series one more time ? The patches somehow
> disintegrated and I'm not having 3/5. Did you use git send-email ?
See https://patchwork.ozlabs.org/patch/176 for part 3.
I used imap-send, I think my mailer might have slaughtered the threading. Let
me know if I
> Well, the easiest test might be to run this through buildman, since it
> reports if there was any size increase for any board.
Isn’t that run during the Travis CI builds? If so, I’ve done it:
https://travis-ci.org/svenschwermer/u-boot/builds/456862718
Sven
>> This configuration doesn't use USB in the SPL, so we need to disable
>> driver model for USB in the SPL.
>>
>> Signed-off-by: Sven Schwermer
>
> Is this also needed on other boards ?
As per the cover letter, I have successfully run the Travis CI build for this
Hi Marek,
>> This allows building the SPL without driver model for USB. Since
>> CONFIG_SPL_DM_USB is enabled if and only if CONFIG_DM_USB was enabled
>> before, this patch does not change the build behaviour.
>>
>> Signed-off-by: Sven Schwermer
>
> I ask
This fixes link issues when building the SPL without USB driver model
but with USB storage support. CONFIG_BLK can be enabled and disabled
independently for SPL and non-SPL builds. We leverage that existing
functionality here.
Signed-off-by: Sven Schwermer
---
common/usb_storage.c | 28
This allows building the SPL without driver model for USB. Since
CONFIG_SPL_DM_USB is enabled if and only if CONFIG_DM_USB was enabled
before, this patch does not change the build behaviour.
Signed-off-by: Sven Schwermer
---
drivers/usb/Kconfig | 5 +
drivers/usb/common/Makefile | 2
boards still build.
Version 2:
* Globally replace CONFIG_DM_USB
* Split the CONFIG_DM_USB replacement into separate patch
* Fix am335x_evm build
Sven Schwermer (5):
usb: Introduce CONFIG_SPL_DM_USB
usb: am335x_evm: Disable CONFIG_SPL_DM_USB
usb: Remove CMD_USB dependency for common code
usb: s
This allows to disable the USB driver model in SPL because it checks
the CONFIG_SPL_DM_USB variable for SPL builds. Nothing changes for
regular non-SPL builds.
Signed-off-by: Sven Schwermer
---
common/usb.c | 14 +++---
common/usb_hub.c | 16
Common USB code is built whenever USB is enabled (in non-SPL builds).
The USB uclass is built whenever (SPL_)DM_USB is enabled. Both need to
be independent from CMD_USB.
Signed-off-by: Sven Schwermer
---
common/Makefile | 2 +-
drivers/usb/host/Makefile | 2 +-
2 files changed, 2
This configuration doesn't use USB in the SPL, so we need to disable
driver model for USB in the SPL.
Signed-off-by: Sven Schwermer
---
configs/am335x_evm_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
>>>> This configuration doesn't use USB in the SPL, so we need to disable
>>>> driver model for USB in the SPL.
>>>>
>>>> Signed-off-by: Sven Schwermer
>>>
>>> Is this also needed on other boards ?
>>
>> As per th
>> Here are the reasons why I don’t think so:
>> 1) This particular order doesn’t break any builds. I triggered Travis CI
>> runs for every patch in order and they have all succeeded.
>> 2) Before this patch series, DM was enabled for both SPL and proper when
>> setting CONFIG_DM_USB=y.
>
> Are
Hi again,
> On 20 Nov 2018, at 15:14, Marek Vasut wrote:
>
> On 11/20/2018 03:10 PM, Sven Schwermer wrote:
>>
>>>> Well, since CONFIG_SPL_DM_USB depends on SPL_DM_USB, I don’t think that’s
>>>> the case.
>>>
>>> Are you _sure_ ? Sor
>> Well, since CONFIG_SPL_DM_USB depends on SPL_DM_USB, I don’t think that’s
>> the case.
>
> Are you _sure_ ? Sorry if I'm being hard, but this affects a lot of
> users, so I have to be cautious.
I am _not_ sure. That’s why I used the verb “think” ;-) I’m sorry, but I don’t
think I can
Hi,
> On 20 Nov 2018, at 14:32, Marek Vasut wrote:
>
> On 11/20/2018 02:27 PM, Sven Schwermer wrote:
>>>> Here are the reasons why I don’t think so:
>>>> 1) This particular order doesn’t break any builds. I triggered Travis CI
>>>> runs for eve
This solves the dependency problem I described in [1].
[1]: http://u-boot.10912.n7.nabble.com/-td347224.html
Version 2:
* Globally replace CONFIG_DM_USB
* Split the CONFIG_DM_USB replacement into separate patch
* Fix am335x_evm build
Sven Schwermer (4):
usb: Introduce CONFIG_SPL_DM_USB
Signed-off-by: Sven Schwermer
---
common/usb.c | 14 +++---
common/usb_hub.c | 16
common/usb_kbd.c | 4 ++--
common/usb_storage.c | 6 +++---
drivers/usb/dwc3/core.c | 2 +-
drivers/usb
This allows building the SPL without driver model for USB.
Signed-off-by: Sven Schwermer
---
common/Makefile | 2 +-
drivers/usb/Kconfig | 5 +
drivers/usb/common/Makefile | 2 +-
drivers/usb/host/Makefile | 5 +++--
4 files changed, 10 insertions(+), 4 deletions
Signed-off-by: Sven Schwermer
---
common/usb_storage.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index c9a99b1ca2..8c889bb1a6 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -66,7
This configuration doesn't use USB in the SPL, so we need to disable
driver model for USB in the SPL.
Signed-off-by: Sven Schwermer
---
configs/am335x_evm_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
Hi again,
However, that was my train of thought.
If you have a concrete defconfig I should check, I can do so.
>>>
>>> dh_imx6 for example.
>>
>> The generated .config is identical before and after the patch series for
>> this board. It also compiles fine after the patch series.
>
>
Hi,
> On 20 Nov 2018, at 16:47, Marek Vasut wrote:
>
> On 11/20/2018 04:21 PM, Sven Schwermer wrote:
>> Hi again,
>>
>>> On 20 Nov 2018, at 15:14, Marek Vasut >> <mailto:ma...@denx.de>> wrote:
>>>
>>> On 11/20/2018 03:10 PM, S
This allows building the SPL without driver model for USB. Since
CONFIG_SPL_DM_USB is enabled if and only if CONFIG_DM_USB was enabled
before, this patch does not change the build behaviour.
Signed-off-by: Sven Schwermer
---
drivers/usb/Kconfig | 5 +
drivers/usb/common/Makefile | 2
This allows to disable the USB driver model in SPL because it checks
the CONFIG_SPL_DM_USB variable for SPL builds. Nothing changes for
regular non-SPL builds.
Signed-off-by: Sven Schwermer
---
common/usb.c | 14 +++---
common/usb_hub.c | 16
This configuration doesn't use USB in the SPL, so we need to disable
driver model for USB in the SPL.
Signed-off-by: Sven Schwermer
---
configs/am335x_evm_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
boards still build.
Version 2:
* Globally replace CONFIG_DM_USB
* Split the CONFIG_DM_USB replacement into separate patch
* Fix am335x_evm build
Sven Schwermer (5):
usb: Introduce CONFIG_SPL_DM_USB
usb: am335x_evm: Disable CONFIG_SPL_DM_USB
usb: Remove CMD_USB dependency for common code
usb: s
Common USB code is built whenever USB is enabled (in non-SPL builds).
The USB uclass is built whenever (SPL_)DM_USB is enabled. Both need to
be independent from CMD_USB.
Signed-off-by: Sven Schwermer
---
common/Makefile | 2 +-
drivers/usb/host/Makefile | 2 +-
2 files changed, 2
This fixes link issues when building the SPL without USB driver model
but with USB storage support. CONFIG_BLK can be enabled and disabled
independently for SPL and non-SPL builds. We leverage that existing
functionality here.
Signed-off-by: Sven Schwermer
---
common/usb_storage.c | 28
Fixed regulators don't have a set_value method. Therefore,
regulator_set_value will return -ENOSYS when called from
regulator_autoset.
Accepting this return value allows autosetting fixed regulators.
Signed-off-by: Sven Schwermer
Cc: Jaehoon Chung
Cc: Peng Fan
---
drivers/power/regulator
Hi Peng,
> According to code:
>if (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UV)
>ret = regulator_set_value(dev, uc_pdata->min_uV);
>if (!ret && (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UA))
>ret = regulator_set_current(dev, uc_pdata->min_uA);
>
>
> For fixed regulator, will min_uV/max_uV be set to value other
> than -ENODATA? I think no.
I see this commonly done (see Linux device trees as well as the u-boot device
trees) and the kernel documentation seems to encourage it:
> How about the following patch? not tested
>
> diff --git a/drivers/power/regulator/regulator-uclass.c
> b/drivers/power/regulator/regulator-uclass.c
> index 9118b8eb39..76be95bcd1 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@
Hi,
I’m trying to implement the VQMMC supply for the an eMMC on my board using a
GPIO regulator, i.e.
reg_sd_vsel: regulator-sd-vsel {
pinctrl-names = "default";
pinctrl-0 = <_sd_vsel>;
compatible = "regulator-gpio";
regulator-name = "sd-vsel";
regulator-min-microvolt = <180>;
Fixed regulators don't have a set_value method. Therefore, trying to
set their value will always return -ENOSYS.
Signed-off-by: Sven Schwermer
Cc: Jaehoon Chung
Cc: Peng Fan
---
drivers/power/regulator/regulator-uclass.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/power
Drivers need to be able to enable regulators that may be implemented as
GPIO regulators. Example: fsl_esdhc enables the vqmmc supply which is
commonly implemented as a GPIO regulator in order to switch between I/O
voltage levels.
Signed-off-by: Sven Schwermer
---
drivers/power/regulator/Kconfig
In preparation of being able to enable/disable GPIO regulators, the
code that will be shared among the two kinds to regulators is factored
out into its own source files.
Signed-off-by: Sven Schwermer
---
drivers/power/regulator/Kconfig| 10 +++
drivers/power/regulator/Makefile
Hi,
I’m running into linking issues when enabling CONFIG_DM_USB_GADGET with
CONFIG_CI_UDC because dm_usb_gadget_handle_interrupts is not available. That
made me look into what’s required to port ci_udc to driver model. I have a few
conceptual questions about this:
1. Some other USB gadget
Hi,
I am using an iMX7 with a DataTraveler 3.0 and I’m seeing the same timeout
error. However, I have CONFIG_DM_USB=y configured so your patch doesn’t fix my
issue. The USB class queries the EHCI driver for its maximum transfer size
which is SIZE_MAX. I believe a solution that works with DM is
Hi Peng,
Yes, this works.
Best regards,
Sven
> On 24 Apr 2019, at 10:59, Peng Fan wrote:
>
>
>
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peng Fan
>> Sent: 2019年4月24日 16:57
>> To: Sven Schwermer ; Ma
Hi again,
Is there anything else I should do in order to get this applied?
Best regards
Sven
> On 28 Jun 2019, at 11:46, Lukasz Majewski wrote:
>
> On Mon, 24 Jun 2019 13:03:34 +0200
> s...@svenschwermer.de wrote:
>
>> From: Sven Schwermer
>>
>> Drivers nee
Hi Fabio,
Thank you for the hint. That's a _very_ useful document. In the
meantime, I have been able to boot my Linux FIT image straight from SPL
on my i.MX6ULL platform.
I have, however, noticed that Linux boots much faster when launched from
u-boot proper compared to SPL. Time to
Hi Fabio,
You could try performing the setting of ACTLR.SMP bit inside SPL.
Currently, it is done only inside U-Boot proper.
I have one more question about this: Is it save to just enable D/I
caches (enable_caches) in SPL for all of mach-imx or will this have
unforeseen side effects? In
Hi Fabio,
Glad you got it to work. It would be nice if you could submit a patch
adding a document adapted for i.MX6ULL.
I'll need to sort my notes and go through my changes. I'll try to submit
relevant patches.
You could try performing the setting of ACTLR.SMP bit inside SPL.
Currently,
FIT image specification which
does not mention a "default" property in the "/images" node.
Signed-off-by: Sven Schwermer
---
boot/Makefile | 8 ++--
cmd/source.c| 22 +-
include/image.h | 1 +
3 files changed, 16 insertions(+), 15 deletions(-)
dif
sourcing the "script@1" fails.
This implementation should be backward-compatible with existing ITS
files.
Signed-off-by: Sven Schwermer
---
drivers/usb/gadget/f_sdp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_s
Hi,
I was wondering whether it's possible to boot a Linux FIT image (kernel
zImage, DTB, initramfs) straight from SPL? Specifically, I'm trying to
reduce the boot time when booting into a tiny Linux with RAM disk over
USB SDP (i.MX6ULL). This works fine with the chain ROM -> SPL -> u-boot
in Linux.
Signed-off-by: Sven Schwermer
---
arch/arm/include/asm/mach-imx/sys_proto.h | 5 +
arch/arm/mach-imx/cache.c | 2 +-
arch/arm/mach-imx/mx6/soc.c | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/mach-imx
FIT image specification which
does not mention a "default" property in the "/images" node.
Signed-off-by: Sven Schwermer
---
(no changes since v1)
boot/Makefile | 8 ++--
cmd/source.c| 22 +-
include/image.h | 1 +
3 files changed, 16 insertions(+), 15 d
in Linux.
Signed-off-by: Sven Schwermer
---
arch/arm/include/asm/mach-imx/sys_proto.h | 5 +
arch/arm/mach-imx/cache.c | 2 +-
arch/arm/mach-imx/mx6/soc.c | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/mach-imx
sourcing the "script@1" fails.
This implementation should be backward-compatible with existing ITS
files.
Signed-off-by: Sven Schwermer
---
Changes in v2:
- Fixed patman issues
drivers/usb/gadget/f_sdp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gad
Hi,
I'm looking into booting Linux FIT images from SPL. In board_init_r
(common/spl/spl.c), the boot argument is set to CONFIG_SYS_SPL_ARGS_ADDR
if defined. When booting a FIT image including a DTB, shouldn't this
automatically be set to fdt_addr (struct spl_image_info)? This would
ensure a
in Linux.
On an i.MX6ULL (528MHz), this reduces a minimal kernel's boot time into
an initramfs shell from ~6.1s down to ~1.2s.
Signed-off-by: Sven Schwermer
---
Changes in v2:
- Apply fix for i.MX7(ULP) as well
- Document quantitive improvement in boot time
arch/arm/include/asm/mach-imx
6ulx-eval.dtb";
conf-imx6ull-myir-mys-6ulx-eval.dtb {
description = "1 Linux kernel, FDT blob, u-boot script";
kernel = "kernel-1";
fdt = "fdt-imx6ull-myir-mys-6ulx-eval.dtb";
bootscr = "bootscr-boot.sh";
Hi Tom,
I think you have have misunderstood me. I meant fdt_addr, the member of
struct spl_image_info, not an environment variable with that name. Does
that make sense?
Best regards,
Sven
On 1/11/22 17:17, Tom Rini wrote:
On Sat, Jan 01, 2022 at 08:00:45PM +0100, Sven Schwermer wrote:
Hi
Hi Tom,
Thanks for the pointers. I understand your concerns about the growth in
size. I'll look into it.
Best regards,
Sven
On 1/24/22 19:08, Tom Rini wrote:
On Sat, Jan 22, 2022 at 09:36:58PM +0100, Sven Schwermer wrote:
Hi Tom,
I didn't think this would result in a size increase. Could
62 matches
Mail list logo
