Re: [U-Boot] [PATCH v3] cmd: env: print a message when setting UEFI variable failed
On 5/28/19 2:00 AM, AKASHI Takahiro wrote: Error message will alert a user that setting/deleting a variable failed. Signed-off-by: AKASHI Takahiro Reviewed-by: Heinrich Schuchardt --- Changes in v3 (May 28, 2019) * change messages as Heinrich suggested Changes in v2 (May 24, 2019) * change a message to "Out of memory" * add more error messages --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: correct notification of protocol installation
When a protocol is installed the handle should be queued for the
registration key of each registered event. LocateHandle() should return the
first handle from the queue for the registration key and delete it from the
queue.
Implement the queueing.
Correct the selftest.
With the patch the UEFI SCT tests for LocateHandle() are passed without
failure.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 26 +++--
lib/efi_loader/efi_boottime.c | 58 ++-
.../efi_selftest_register_notify.c| 21 ---
3 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 43d3a08428..77b2f60bdc 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -286,20 +286,38 @@ extern struct list_head efi_obj_list;
/* List of all events */
extern struct list_head efi_events;
+/**
+ * struct efi_protocol_notification - handle for notified protocol
+ *
+ * When a protocol interface is installed for which an event was registered
with
+ * the RegisterProtocolNotify() service this structure is used to hold the
+ * handle on which the protocol interface was installed.
+ *
+ * @link: link to list of all handles notified for this event
+ * @handle:handle on which the notified protocol interface was installed
+ */
+struct efi_protocol_notification {
+ struct list_head link;
+ efi_handle_t handle;
+};
+
/**
* efi_register_notify_event - event registered by RegisterProtocolNotify()
*
* The address of this structure serves as registration value.
*
- * @link: link to list of all registered events
- * @event: registered event. The same event may registered for
- * multiple GUIDs.
- * @protocol: protocol for which the event is registered
+ * @link: link to list of all registered events
+ * @event: registered event. The same event may registered for multiple
+ * GUIDs.
+ * @protocol: protocol for which the event is registered
+ * @handles: linked list of all handles on which the notified protocol was
+ * installed
*/
struct efi_register_notify_event {
struct list_head link;
struct efi_event *event;
efi_guid_t protocol;
+ struct list_head handles;
};
/* List of all events registered by RegisterProtocolNotify() */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 54fff85e64..1ccf54c386 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -921,6 +921,14 @@ static efi_status_t EFIAPI efi_close_event(struct
efi_event *event)
list_for_each_entry_safe(item, next, _register_notify_events,
link) {
if (event == item->event) {
+ struct efi_protocol_notification *hitem, *hnext;
+
+ /* Remove signaled handles */
+ list_for_each_entry_safe(hitem, hnext, >handles,
+link) {
+ list_del(>link);
+ free(hitem);
+ }
list_del(>link);
free(item);
}
@@ -1049,8 +1057,19 @@ efi_status_t efi_add_protocol(const efi_handle_t handle,
/* Notify registered events */
list_for_each_entry(event, _register_notify_events, link) {
- if (!guidcmp(protocol, >protocol))
+ if (!guidcmp(protocol, >protocol)) {
+ struct efi_protocol_notification *notif;
+
+ notif = calloc(1, sizeof(*notif));
+ if (!notif) {
+ list_del(>link);
+ free(handler);
+ return EFI_OUT_OF_RESOURCES;
+ }
+ notif->handle = handle;
+ list_add_tail(>link, >handles);
efi_signal_event(event->event, true);
+ }
}
if (!guidcmp(_guid_device_path, protocol))
@@ -1332,6 +1351,7 @@ static efi_status_t EFIAPI efi_register_protocol_notify(
item->event = event;
memcpy(>protocol, protocol, sizeof(efi_guid_t));
+ INIT_LIST_HEAD(>handles);
list_add_tail(>link, _register_notify_events);
@@ -1359,7 +1379,6 @@ static int efi_search(enum efi_locate_search_type
search_type,
switch (search_type) {
case ALL_HANDLES:
return 0;
- case BY_REGISTER_NOTIFY:
case BY_PROTOCOL:
ret = efi_search_protocol(handle, protocol, NULL);
return (ret != EFI_SUCCESS);
@@ -1391,6 +1410,7 @@ static efi_status_t efi_locate_handle(
struct efi_object *efiobj;
efi_uintn_t size = 0;
struct efi_register_notify_event *item, *event = NULL;
+
Re: [U-Boot] [PATCH RESEND 1/1] Add ps7_init_gpl.c for Z-turn board
On 27. 05. 19 23:17, tos...@gmail.com wrote: > Hi Michal, > > thank you for your review. > >> Sorry I missed this patch. Please take a look at script which was sent >> by Luca (arm64: zynqmp: add tool to minimize psu_init_gpl.c files) >> for tuning psu_init_gpl files. >> You should use the same for this file to align it with checkpatch. > > I'm not sure whether this tool works well for old ps7 devices, but I've fixed > the warnings from checkpatch.pl, , sorry for not doing it right away. Will > send > in a moment. Definitely not but that's good manual how to do it. Anyway here are steps I used for tuning ps7 files + some manual steps. If you can c what Luca did for psu and use these steps + Luca's steps we can have one more script for ps7 init files too. Thanks, Michal #!/bin/bash rm -f ps7_init_gpl.h sed -i '/perf_start_clock/,$d' ps7_init_gpl.c sed -i '/^#/d' ps7_init_gpl.c sed -i '/\/\*/,/*\//d' ps7_init_gpl.c sed -i '/^[ \t]*\/\//d' ps7_init_gpl.c /mnt/disk/linux/scripts/Lindent ps7_init_gpl.c sed -i 's/^unsigned long /static &/g' ps7_init_gpl.c sed -i 's/()$/(void)/g' ps7_init_gpl.c sed -i 's/0X/0x/g' ps7_init_gpl.c sed -i 's/long\ ps7GetSiliconVersion/long_ps7GetSiliconVersion/g' ps7_init_gpl.c sed -i 's/int\ ps7_config/int_ps7_config/g' ps7_init_gpl.c cat ps7_init_gpl.c | tr "\n" "\z" | sed 's/EXIT(),zz};zz/EXIT(),z};zz/g' | tr "\z" "\n" > /tmp/1; cp /tmp/1 ps7_init_gpl.c NAME="ps7_debug_._.\[\] \ " for i in $NAME; do echo $i sed -i "/$i/,/^};$/d" ps7_init_gpl.c done NAME="ps7_debug \ getPS7MessageInfo \ mask_write \ mask_poll \ mask_read \ int_ps7_config \ long_ps7GetSiliconVersion \ " for i in $NAME; do echo $i sed -i "/$i/,/^}$/d" ps7_init_gpl.c done /mnt/disk/linux/scripts/Lindent ps7_init_gpl.c cat << EOF | cat - ps7_init_gpl.c | tee ps7_init_gpl.c /* * (c) Copyright 2010-2014 Xilinx, Inc. All rights reserved. * * SPDX-License-Identifier: GPL-2.0+ */ #include EOF -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.07-rc3 released
Hi Tom, On 27.05.19 20:35, Tom Rini wrote: It's release day and here is v2019.07-rc3. I think I have a few outstanding regression fixes to pull in still, and then of course Kconfig migrations. So, what are we doing about DM migration deadlines? Well, first, let me say again, that DM is not required for SPL. This comes up enough that I want to say it again here. Next, if there is active progress on converting things, we'll keep from pulling the code out. This is why for example, we haven't yet pulled out a lot of deprecated SPI code. Some of it is still in progress on being converted, so I need to update the series I posted after the last -rc to remove still less drivers. In terms of a changelog, git log --merges v2019.07-rc2..v2019.07-rc3 continues to improve in quality. If you're sending me a PR, please include a few lines or words in summary and I'll be sure to put it into the merge commit. As this cycle is coming closer to an end, I feel it's time to ask. Is anyone out there being more frustrated with a 3 month release cycle than with a 2 month cycle? I feel like the answer is that the 3 month cycle is working better than 2 and we should keep that going. I personally favor the 2 months release cycle. My main (mostly practical) reason being here, that I don't have to queue non-fixes patches that long and can push them upstream more frequently / sooner. But I can also live with the 3 month release cycle, so if the majority prefers this, then lets stick with it. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] pwm: imx: add Kconfig support
add Kconfig support for this driver. Signed-off-by: Heiko Schocher --- README| 4 configs/aristainetos2_defconfig | 1 + configs/aristainetos2b_defconfig | 1 + configs/aristainetos_defconfig| 1 + configs/dms-ba16-1g_defconfig | 1 + configs/dms-ba16_defconfig| 1 + configs/ge_bx50v3_defconfig | 1 + configs/mx53ppd_defconfig | 1 + configs/vining_2000_defconfig | 1 + drivers/pwm/Kconfig | 5 + include/configs/advantech_dms-ba16.h | 1 - include/configs/aristainetos-common.h | 1 - include/configs/aristainetos2.h | 3 --- include/configs/aristainetos2b.h | 3 --- include/configs/ge_bx50v3.h | 1 - include/configs/mx53ppd.h | 1 - include/configs/vining_2000.h | 1 - scripts/config_whitelist.txt | 1 - 18 files changed, 13 insertions(+), 16 deletions(-) diff --git a/README b/README index fd1e17c513..730e28db88 100644 --- a/README +++ b/README @@ -964,10 +964,6 @@ The following options need to be configured: CONFIG_SH_ETHER_CACHE_WRITEBACK If this option is set, the driver enables cache flush. -- PWM Support: - CONFIG_PWM_IMX - Support for PWM module on the imx6. - - TPM Support: CONFIG_TPM Support TPM devices. diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig index 87a8678233..8bd1be4e05 100644 --- a/configs/aristainetos2_defconfig +++ b/configs/aristainetos2_defconfig @@ -50,6 +50,7 @@ CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig index 256d7229ba..ed9faa74f0 100644 --- a/configs/aristainetos2b_defconfig +++ b/configs/aristainetos2b_defconfig @@ -48,6 +48,7 @@ CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig index 44b30e33e8..e67aded809 100644 --- a/configs/aristainetos_defconfig +++ b/configs/aristainetos_defconfig @@ -49,6 +49,7 @@ CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ8XXX=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y diff --git a/configs/dms-ba16-1g_defconfig b/configs/dms-ba16-1g_defconfig index 980f7b4abb..5c06a4f03d 100644 --- a/configs/dms-ba16-1g_defconfig +++ b/configs/dms-ba16-1g_defconfig @@ -41,6 +41,7 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHYLIB=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y diff --git a/configs/dms-ba16_defconfig b/configs/dms-ba16_defconfig index bea75b5d23..bc518f9fed 100644 --- a/configs/dms-ba16_defconfig +++ b/configs/dms-ba16_defconfig @@ -40,6 +40,7 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHYLIB=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig index 3111451162..6adad7a995 100644 --- a/configs/ge_bx50v3_defconfig +++ b/configs/ge_bx50v3_defconfig @@ -55,6 +55,7 @@ CONFIG_CMD_E1000=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y +CONFIG_PWM_IMX=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MXC_SPI=y diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig index 6c3818d845..b9ed46617b 100644 --- a/configs/mx53ppd_defconfig +++ b/configs/mx53ppd_defconfig @@ -43,6 +43,7 @@ CONFIG_FSL_ESDHC=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX5=y +CONFIG_PWM_IMX=y CONFIG_RTC_S35392A=y CONFIG_USB=y CONFIG_USB_EHCI_MX5=y diff --git a/configs/vining_2000_defconfig b/configs/vining_2000_defconfig index 073ff48329..0d87cd1431 100644 --- a/configs/vining_2000_defconfig +++ b/configs/vining_2000_defconfig @@ -37,6 +37,7 @@ CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_ESDHC=y CONFIG_PHYLIB=y CONFIG_MII=y +CONFIG_PWM_IMX=y CONFIG_PCI=y CONFIG_USB=y CONFIG_USB_STORAGE=y diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 2984b79766..1f36fc78fa 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -18,6 +18,11 @@ config PWM_EXYNOS used. It provides 5 channels which can be independently programmed. Channel 4 (the last) is normally used as a timer. +config PWM_IMX + bool "Enable support for i.MX27 and later PWM" + help + This PWM is found i.MX27 and later i.MX SoCs. + config PWM_ROCKCHIP bool "Enable support for the Rockchip PWM" depends on DM_PWM diff --git a/include/configs/advantech_dms-ba16.h b/include/configs/advantech_dms-ba16.h index 22d1e41bc8..a037349162 100644 --- a/include/configs/advantech_dms-ba16.h +++ b/include/configs/advantech_dms-ba16.h @@ -223,7 +223,6 @@ #define
[U-Boot] [PATCH 2/2] pwm: imx: add DM_PWM support
add DM support for pwm-imx driver.
Signed-off-by: Heiko Schocher
---
drivers/pwm/pwm-imx.c | 110 ++
1 file changed, 101 insertions(+), 9 deletions(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 83c1bfa820..8d8f3e6f9f 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -24,18 +25,12 @@ int pwm_init(int pwm_id, int div, int invert)
return 0;
}
-int pwm_config(int pwm_id, int duty_ns, int period_ns)
+int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles,
+ unsigned long duty_cycles, unsigned long prescale)
{
- struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
- unsigned long period_cycles, duty_cycles, prescale;
u32 cr;
- if (!pwm)
- return -1;
-
- pwm_imx_get_parms(period_ns, duty_ns, _cycles, _cycles,
- );
-
+ writel(0, >ir);
cr = PWMCR_PRESCALER(prescale) |
PWMCR_DOZEEN | PWMCR_WAITEN |
PWMCR_DBGEN | PWMCR_CLKSRC_IPG_HIGH;
@@ -48,6 +43,20 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
return 0;
}
+int pwm_config(int pwm_id, int duty_ns, int period_ns)
+{
+ struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
+ unsigned long period_cycles, duty_cycles, prescale;
+
+ if (!pwm)
+ return -1;
+
+ pwm_imx_get_parms(period_ns, duty_ns, _cycles, _cycles,
+ );
+
+ return pwm_config_internal(pwm, period_cycles, duty_cycles, prescale);
+}
+
int pwm_enable(int pwm_id)
{
struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
@@ -68,3 +77,86 @@ void pwm_disable(int pwm_id)
clrbits_le32(>cr, PWMCR_EN);
}
+
+#if defined(CONFIG_DM_PWM)
+struct imx_pwm_priv {
+ struct pwm_regs *regs;
+ bool invert;
+};
+
+static int imx_pwm_set_invert(struct udevice *dev, uint channel,
+ bool polarity)
+{
+ struct imx_pwm_priv *priv = dev_get_priv(dev);
+
+ debug("%s: polarity=%u\n", __func__, polarity);
+ priv->invert = polarity;
+
+ return 0;
+}
+
+static int imx_pwm_set_config(struct udevice *dev, uint channel,
+ uint period_ns, uint duty_ns)
+{
+ struct imx_pwm_priv *priv = dev_get_priv(dev);
+ struct pwm_regs *regs = priv->regs;
+ unsigned long period_cycles, duty_cycles, prescale;
+
+ debug("%s: Config '%s' channel: %d\n", __func__, dev->name, channel);
+
+ pwm_imx_get_parms(period_ns, duty_ns, _cycles, _cycles,
+ );
+
+ return pwm_config_internal(regs, period_cycles, duty_cycles, prescale);
+};
+
+static int imx_pwm_set_enable(struct udevice *dev, uint channel, bool enable)
+{
+ struct imx_pwm_priv *priv = dev_get_priv(dev);
+ struct pwm_regs *regs = priv->regs;
+
+ debug("%s: Enable '%s' state: %d\n", __func__, dev->name, enable);
+
+ if (enable)
+ setbits_le32(>cr, PWMCR_EN);
+ else
+ clrbits_le32(>cr, PWMCR_EN);
+
+ return 0;
+};
+
+static int imx_pwm_ofdata_to_platdata(struct udevice *dev)
+{
+ struct imx_pwm_priv *priv = dev_get_priv(dev);
+
+ priv->regs = (struct pwm_regs *)devfdt_get_addr(dev);
+
+ return 0;
+}
+
+static int imx_pwm_probe(struct udevice *dev)
+{
+ return 0;
+}
+
+static const struct pwm_ops imx_pwm_ops = {
+ .set_invert = imx_pwm_set_invert,
+ .set_config = imx_pwm_set_config,
+ .set_enable = imx_pwm_set_enable,
+};
+
+static const struct udevice_id imx_pwm_ids[] = {
+ { .compatible = "fsl,imx27-pwm" },
+ { }
+};
+
+U_BOOT_DRIVER(imx_pwm) = {
+ .name = "imx_pwm",
+ .id = UCLASS_PWM,
+ .of_match = imx_pwm_ids,
+ .ops= _pwm_ops,
+ .ofdata_to_platdata = imx_pwm_ofdata_to_platdata,
+ .probe = imx_pwm_probe,
+ .priv_auto_alloc_size = sizeof(struct imx_pwm_priv),
+};
+#endif
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] pwm, imx: add Kconfig and DM support
add Kconfig and DM support for imx pwm driver Travis builds clean, see: https://travis-ci.org/hsdenx/u-boot-test/builds/537631288 Heiko Schocher (2): pwm: imx: add Kconfig support pwm: imx: add DM_PWM support README| 4 - configs/aristainetos2_defconfig | 1 + configs/aristainetos2b_defconfig | 1 + configs/aristainetos_defconfig| 1 + configs/dms-ba16-1g_defconfig | 1 + configs/dms-ba16_defconfig| 1 + configs/ge_bx50v3_defconfig | 1 + configs/mx53ppd_defconfig | 1 + configs/vining_2000_defconfig | 1 + drivers/pwm/Kconfig | 5 ++ drivers/pwm/pwm-imx.c | 110 +++--- include/configs/advantech_dms-ba16.h | 1 - include/configs/aristainetos-common.h | 1 - include/configs/aristainetos2.h | 3 - include/configs/aristainetos2b.h | 3 - include/configs/ge_bx50v3.h | 1 - include/configs/mx53ppd.h | 1 - include/configs/vining_2000.h | 1 - scripts/config_whitelist.txt | 1 - 19 files changed, 114 insertions(+), 25 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, imx, Makefile: support CONFIG_MULTI_DTB_FIT
Hello Fabio, Am 27.05.2019 um 14:07 schrieb Fabio Estevam: Hi Heiko, On Mon, May 27, 2019 at 3:08 AM Heiko Schocher wrote: in case CONFIG_MULTI_DTB_FIT is active, use u-boot-fit-dtb.bin. We currently use CONFIG_MULTI_DTB_FIT on mx6sabresd target. Could you please expand the commit log explaining why we need to introduce u-boot-fit-dtb.bin? Ok, I had to recover why I needed this patch (yes, commit message needs update!)... I just working on moving the aristainetos board to support DM/DTB and I need MULTI_DTB_FIT support... When I activated CONFIG_MULTI_DTB_FIT not the fit blob was appended to the u-boot-nodtb.bin to get the u-boot-dtb.imx binary, instead dt/dtb.bin from the dts subdirectory was used. (Yes, currently aristainetos board do not use SPL ...) Reason is: in arch/arm/mach-imx/Makefile: 129 ifeq ($(CONFIG_OF_SEPARATE),y) 130 MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \ 131 -T $(IMAGE_TYPE) -e $(CONFIG_SYS_TEXT_BASE) 132 u-boot-dtb.imx: MKIMAGEOUTPUT = u-boot-dtb.imx.log 133 134 u-boot-dtb.imx: u-boot-dtb.bin u-boot-dtb.cfgout $(PLUGIN).bin FORCE 135 ifeq ($(DEPFILE_EXISTS),0) 136 $(call if_changed,mkimage) with Makefile 1080 else ifeq ($(CONFIG_OF_SEPARATE),y) 1081 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE 1082 $(call if_changed,cat) So there is not the fit image appended to u-boot-nodtb.bin to get the u-boot-dtb.imx binary, which my patch fixes. I would reword the commit message and subject to: """ arm, imx, Makefile: fix u-boot-dtb.imx build in CONFIG_MULTI_DTB_FIT case in case CONFIG_MULTI_DTB_FIT is set and u-boot-dtb.imx image is build, currently u-boot-dtb.bin is used for generating the u-boot-dtb.imx binary, which is wrong, as it contains only a dtb blob not the fit.blob Use instead the u-boot-fit-dtb.bin for generating u-boot-dtb.imx which contains the fit.blob. """ Is this OK? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On 5/28/19 5:04 AM, Tom Rini wrote: > On Tue, May 28, 2019 at 04:44:52AM +0200, Marek Vasut wrote: >> On 5/28/19 4:42 AM, Tom Rini wrote: >>> On Tue, May 28, 2019 at 04:07:44AM +0200, Marek Vasut wrote: On 5/28/19 4:06 AM, Tom Rini wrote: > On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: > >> If the source and destination buffer address is identical, there is >> no need to memcpy() the content. Skip the memcpy() in such a case. >> >> Signed-off-by: Marek Vasut >> Cc: Michal Simek >> Cc: Tom Rini > > Shouldn't memcpy catch that itself? > memcpy(3) says The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas must not overlap. Use memmove(3) if the memory areas do overlap. >>> >>> OK, and shouldn't memcpy optimize that case? Does it usually? >> >> As the manpage says "The memory areas must not overlap." , I would >> expect it does not have to ? > > I guess I'm not being clear enough, sorry. Go look at how this is > implemented in a few places please and report back to us. Someone else, > or many someone else, have probably already figured out if optimizing > this case in general, in memcpy, is a good idea or not. Thanks! If even [1] says the behavior is undefined, then what does it matter whether some implementation added an optimization for such undefined behavior? We cannot depend on it, can we ? [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On Tue, May 28, 2019 at 04:44:52AM +0200, Marek Vasut wrote: > On 5/28/19 4:42 AM, Tom Rini wrote: > > On Tue, May 28, 2019 at 04:07:44AM +0200, Marek Vasut wrote: > >> On 5/28/19 4:06 AM, Tom Rini wrote: > >>> On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: > >>> > If the source and destination buffer address is identical, there is > no need to memcpy() the content. Skip the memcpy() in such a case. > > Signed-off-by: Marek Vasut > Cc: Michal Simek > Cc: Tom Rini > >>> > >>> Shouldn't memcpy catch that itself? > >>> > >> memcpy(3) says > >>The memcpy() function copies n bytes from memory area src to > >> memory area dest. The memory areas must not overlap. Use memmove(3) if > >> the memory areas do overlap. > > > > OK, and shouldn't memcpy optimize that case? Does it usually? > > As the manpage says "The memory areas must not overlap." , I would > expect it does not have to ? I guess I'm not being clear enough, sorry. Go look at how this is implemented in a few places please and report back to us. Someone else, or many someone else, have probably already figured out if optimizing this case in general, in memcpy, is a good idea or not. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On 5/28/19 4:42 AM, Tom Rini wrote: > On Tue, May 28, 2019 at 04:07:44AM +0200, Marek Vasut wrote: >> On 5/28/19 4:06 AM, Tom Rini wrote: >>> On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: >>> If the source and destination buffer address is identical, there is no need to memcpy() the content. Skip the memcpy() in such a case. Signed-off-by: Marek Vasut Cc: Michal Simek Cc: Tom Rini >>> >>> Shouldn't memcpy catch that itself? >>> >> memcpy(3) says >>The memcpy() function copies n bytes from memory area src to >> memory area dest. The memory areas must not overlap. Use memmove(3) if >> the memory areas do overlap. > > OK, and shouldn't memcpy optimize that case? Does it usually? As the manpage says "The memory areas must not overlap." , I would expect it does not have to ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On Tue, May 28, 2019 at 04:07:44AM +0200, Marek Vasut wrote: > On 5/28/19 4:06 AM, Tom Rini wrote: > > On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: > > > >> If the source and destination buffer address is identical, there is > >> no need to memcpy() the content. Skip the memcpy() in such a case. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Michal Simek > >> Cc: Tom Rini > > > > Shouldn't memcpy catch that itself? > > > memcpy(3) says >The memcpy() function copies n bytes from memory area src to > memory area dest. The memory areas must not overlap. Use memmove(3) if > the memory areas do overlap. OK, and shouldn't memcpy optimize that case? Does it usually? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET
This commit addresses the following warning, when _NOT_ USB_MUSB_HOST:
[...]
CC drivers/usb/gadget/f_mass_storage.o
CC drivers/usb/musb-new/omap2430.o
CC drivers/usb/gadget/f_fastboot.o
CC env/common.o
CC env/env.o
/src/etinker/software/u-boot-master/drivers/usb/musb-new/omap2430.c: In
function ‘omap2430_musb_probe’:
/src/etinker/software/u-boot-master/drivers/usb/musb-new/omap2430.c:239:6:
warning: assignment to ‘int’ from ‘struct musb *’ makes integer from pointer
without a cast [-Wint-conversion]
ret = musb_register(>plat,
^
LD drivers/usb/host/built-in.o
CC drivers/usb/gadget/f_sdp.o
CC fs/ext4/ext4fs.o
[...]
Signed-off-by: Derald D. Woods
---
drivers/usb/musb-new/omap2430.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
index 32743aa72c..cca1653f1e 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -215,11 +215,13 @@ static int omap2430_musb_probe(struct udevice *dev)
{
#ifdef CONFIG_USB_MUSB_HOST
struct musb_host_data *host = dev_get_priv(dev);
+#else
+ struct musb *musbp;
#endif
struct omap2430_musb_platdata *platdata = dev_get_platdata(dev);
struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct omap_musb_board_data *otg_board_data;
- int ret;
+ int ret = 0;
void *base = dev_read_addr_ptr(dev);
priv->desc_before_addr = true;
@@ -236,9 +238,11 @@ static int omap2430_musb_probe(struct udevice *dev)
ret = musb_lowlevel_init(host);
#else
- ret = musb_register(>plat,
+ musbp = musb_register(>plat,
(struct device *)otg_board_data,
platdata->base);
+ if (IS_ERR_OR_NULL(musbp))
+ return -EINVAL;
#endif
return ret;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: omap3: evm: Enable DM_USB in defconfig
This addresses the following warning message:
= WARNING ==
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
As USB support for older OMAP3 SoC's improves, OMAP3 EVM can be
readily adapted. There is some additional 'gpio-hog' support
needed to fully setup USB in a similar manner to Linux.
Signed-off-by: Derald D. Woods
---
board/ti/evm/evm.c | 31 ---
configs/omap3_evm_defconfig | 3 +++
include/configs/omap3_evm.h | 2 --
3 files changed, 3 insertions(+), 33 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index daecb4af3e..93408047b2 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -30,11 +30,6 @@
#include
#include "evm.h"
-#ifdef CONFIG_USB_EHCI_HCD
-#include
-#include
-#endif
-
#define OMAP3EVM_GPIO_ETH_RST_GEN1 64
#define OMAP3EVM_GPIO_ETH_RST_GEN2 7
@@ -307,32 +302,6 @@ void board_mmc_power_init(void)
}
#endif /* CONFIG_MMC */
-#if defined(CONFIG_USB_EHCI_HCD) && !defined(CONFIG_SPL_BUILD)
-/* Call usb_stop() before starting the kernel */
-void show_boot_progress(int val)
-{
- if (val == BOOTSTAGE_ID_RUN_OS)
- usb_stop();
-}
-
-static struct omap_usbhs_board_data usbhs_bdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED
-};
-
-int ehci_hcd_init(int index, enum usb_init_type init,
- struct ehci_hccr **hccr, struct ehci_hcor **hcor)
-{
- return omap_ehci_hcd_init(index, _bdata, hccr, hcor);
-}
-
-int ehci_hcd_stop(int index)
-{
- return omap_ehci_hcd_stop();
-}
-#endif /* CONFIG_USB_EHCI_HCD */
-
#if defined(CONFIG_USB_ETHER) && defined(CONFIG_USB_MUSB_GADGET) &&
!defined(CONFIG_CMD_NET)
int board_eth_init(bd_t *bis)
{
diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig
index a3b662db2b..26d0e65589 100644
--- a/configs/omap3_evm_defconfig
+++ b/configs/omap3_evm_defconfig
@@ -66,7 +66,10 @@ CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_OMAP3_SPI=y
CONFIG_USB=y
+CONFIG_DM_USB=y
+# CONFIG_SPL_DM_USB is not set
CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OMAP3=y
CONFIG_USB_MUSB_GADGET=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_USB_GADGET=y
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 5b9d8a57e3..082a4edb2b 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -56,8 +56,6 @@
/* Environment */
#define CONFIG_ENV_SIZE SZ_128K
-#define CONFIG_PREBOOT "usb start"
-
#define MEM_LAYOUT_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: dts: omap3-evm: Sync dts(i) files from Linux 5.1.5
Signed-off-by: Derald D. Woods
---
arch/arm/dts/omap3-evm-37xx.dts | 8
arch/arm/dts/omap3-evm-common.dtsi | 7 +--
arch/arm/dts/omap3-evm-processor-common.dtsi | 10 +-
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/omap3-evm-37xx.dts b/arch/arm/dts/omap3-evm-37xx.dts
index 5a4ba0aea4..a14303b09a 100644
--- a/arch/arm/dts/omap3-evm-37xx.dts
+++ b/arch/arm/dts/omap3-evm-37xx.dts
@@ -90,19 +90,19 @@
label = "X-Loader";
reg = <0 0x8>;
};
- partition@0x8 {
+ partition@8 {
label = "U-Boot";
reg = <0x8 0x1c>;
};
- partition@0x1c {
+ partition@1c {
label = "Environment";
reg = <0x24 0x4>;
};
- partition@0x28 {
+ partition@28 {
label = "Kernel";
reg = <0x28 0x50>;
};
- partition@0x78 {
+ partition@78 {
label = "Filesystem";
reg = <0x78 0x1f88>;
};
diff --git a/arch/arm/dts/omap3-evm-common.dtsi
b/arch/arm/dts/omap3-evm-common.dtsi
index ee64191e41..17c89df6ce 100644
--- a/arch/arm/dts/omap3-evm-common.dtsi
+++ b/arch/arm/dts/omap3-evm-common.dtsi
@@ -122,6 +122,7 @@
};
{
+ interrupts-extended = < 86 _pmx_core 0x12e>;
vmmc-supply = <_vmmc>;
non-removable;
bus-width = <4>;
@@ -132,8 +133,10 @@
wlcore: wlcore@2 {
compatible = "ti,wl1271";
reg = <2>;
- interrupt-parent = <>;
- interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio 149 */
+ /* gpio_149 with uart1_rts pad as wakeirq */
+ interrupts-extended = < 21 IRQ_TYPE_EDGE_RISING>,
+ <_pmx_core 0x14e>;
+ interrupt-names = "irq", "wakeup";
ref-clock-frequency = <3840>;
};
};
diff --git a/arch/arm/dts/omap3-evm-processor-common.dtsi
b/arch/arm/dts/omap3-evm-processor-common.dtsi
index ce7f42f944..b4109f48ec 100644
--- a/arch/arm/dts/omap3-evm-processor-common.dtsi
+++ b/arch/arm/dts/omap3-evm-processor-common.dtsi
@@ -86,6 +86,10 @@
OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat2.sdmmc2_dat2 */
OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat4.sdmmc2_dir_dat0 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat5.sdmmc2_dir_dat1 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat6.sdmmc2_dir_cmd */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
>;
};
@@ -127,9 +131,13 @@
>;
};
+ /*
+* Note that gpio_150 pulled high with internal pull to prevent wlcore
+* reset on return from off mode in idle.
+*/
wl12xx_gpio: pinmux_wl12xx_gpio {
pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2180, PIN_OUTPUT | MUX_MODE4)
/* uart1_cts.gpio_150 */
+ OMAP3_CORE1_IOPAD(0x2180, PIN_INPUT_PULLUP | MUX_MODE7)
/* uart1_cts.gpio_150 */
OMAP3_CORE1_IOPAD(0x217e, PIN_INPUT | MUX_MODE4)
/* uart1_rts.gpio_149 */
>;
};
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On 5/28/19 4:06 AM, Tom Rini wrote: > On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: > >> If the source and destination buffer address is identical, there is >> no need to memcpy() the content. Skip the memcpy() in such a case. >> >> Signed-off-by: Marek Vasut >> Cc: Michal Simek >> Cc: Tom Rini > > Shouldn't memcpy catch that itself? > memcpy(3) says The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas must not overlap. Use memmove(3) if the memory areas do overlap. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
On Tue, May 28, 2019 at 03:49:13AM +0200, Marek Vasut wrote: > If the source and destination buffer address is identical, there is > no need to memcpy() the content. Skip the memcpy() in such a case. > > Signed-off-by: Marek Vasut > Cc: Michal Simek > Cc: Tom Rini Shouldn't memcpy catch that itself? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] spl: fit: Place OS_BOOT DTB at CONFIG_SYS_SPL_ARGS_ADDR if defined
If SPL OS_BOOT is enabled and CONFIG_SYS_SPL_ARGS_ADDR is defined, place the kernel DTB at that location, so the rest of the OS_BOOT machinery in SPL has the DTB blob at the correct location. Signed-off-by: Marek Vasut Cc: Tom Rini --- common/spl/spl_fit.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index 87ecf0bb9e..e3312b3477 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -291,7 +291,11 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image, * Read the device tree and place it after the image. * Align the destination address to ARCH_DMA_MINALIGN. */ +#if defined(CONFIG_SPL_OS_BOOT) && defined(CONFIG_SYS_SPL_ARGS_ADDR) + image_info.load_addr = CONFIG_SYS_SPL_ARGS_ADDR; +#else image_info.load_addr = spl_image->load_addr + spl_image->size; +#endif ret = spl_load_fit_image(info, sector, fit, base_offset, node, _info); @@ -472,7 +476,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, * Booting a next-stage U-Boot may require us to append the FDT. * We allow this to fail, as the U-Boot image might embed its FDT. */ - if (spl_image->os == IH_OS_U_BOOT) + if (spl_image->os == IH_OS_U_BOOT || spl_image->os == IH_OS_LINUX) spl_fit_append_fdt(spl_image, info, sector, fit, images, base_offset); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers
If the source and destination buffer address is identical, there is
no need to memcpy() the content. Skip the memcpy() in such a case.
Signed-off-by: Marek Vasut
Cc: Michal Simek
Cc: Tom Rini
---
common/spl/spl_ram.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
index 954e91a004..2ef33f717e 100644
--- a/common/spl/spl_ram.c
+++ b/common/spl/spl_ram.c
@@ -24,7 +24,8 @@ static ulong spl_ram_load_read(struct spl_load_info *load,
ulong sector,
{
debug("%s: sector %lx, count %lx, buf %lx\n",
__func__, sector, count, (ulong)buf);
- memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count);
+ if (buf != CONFIG_SPL_LOAD_FIT_ADDRESS + sector)
+ memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector),
count);
return count;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] spl: ubi: Add support for loading simple fitImage
Add code to load simple fitImage from the kernel volume, the args
volume is unnecessary.
Signed-off-by: Marek Vasut
Cc: Ladislav Michl
Cc: Tom Rini
---
common/spl/spl_ubi.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_ubi.c b/common/spl/spl_ubi.c
index 67e5fadd7c..6addd46ece 100644
--- a/common/spl/spl_ubi.c
+++ b/common/spl/spl_ubi.c
@@ -11,6 +11,14 @@
#include
#include
+static ulong spl_ubi_load_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ if (buf != (void *)CONFIG_SPL_LOAD_FIT_ADDRESS + sector)
+ memcpy(buf, (void *)(CONFIG_SYS_LOAD_ADDR + sector), count);
+ return count;
+}
+
int spl_ubi_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
{
@@ -54,7 +62,19 @@ int spl_ubi_load_image(struct spl_image_info *spl_image,
ret = ubispl_load_volumes(, volumes, 2);
if (!ret) {
header = (struct image_header *)volumes[0].load_addr;
- spl_parse_image_header(spl_image, header);
+
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+ image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ debug("Found FIT\n");
+ load.bl_len = 1;
+ load.read = spl_ubi_load_read;
+ spl_load_simple_fit(spl_image, , 0,
header);
+ } else {
+ spl_parse_image_header(spl_image, header);
+ }
+
puts("Linux loaded.\n");
goto out;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi Schrempf, On Mon, May 27, 2019 at 3:40 AM Schrempf Frieder wrote: > I need to do some rebasing and cleanup, but I'm definitely planning to > send this as a patch for upstream. Excellent, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] cmd: env: print a message when setting UEFI variable failed
Error message will alert a user that setting/deleting a variable failed.
Signed-off-by: AKASHI Takahiro
---
Changes in v3 (May 28, 2019)
* change messages as Heinrich suggested
Changes in v2 (May 24, 2019)
* change a message to "Out of memory"
* add more error messages
---
cmd/nvedit_efi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index 2805e8182b41..ff8eaa1aad2d 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -373,6 +373,8 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
for ( ; argc > 0; argc--, argv++)
if (append_value(, , argv[0]) < 0) {
+ printf("## Failed to process an argument, %s\n",
+ argv[0]);
ret = CMD_RET_FAILURE;
goto out;
}
@@ -381,6 +383,7 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
len = utf8_utf16_strnlen(var_name, strlen(var_name));
var_name16 = malloc((len + 1) * 2);
if (!var_name16) {
+ printf("## Out of memory\n");
ret = CMD_RET_FAILURE;
goto out;
}
@@ -392,7 +395,12 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, value));
- ret = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ if (ret == EFI_SUCCESS) {
+ ret = CMD_RET_SUCCESS;
+ } else {
+ printf("## Failed to set EFI variable\n");
+ ret = CMD_RET_FAILURE;
+ }
out:
free(value);
free(var_name16);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 1/1] Add ps7_init_gpl.c for Z-turn board
No, sorry, it ceased to boot after processing with the script. I can debug, but I'm pretty sure it's because opcodes are defined differently in Vivado's ps7_init_gpl.h and the one in u-boot, and the script preprocesses the c file with the Vivado's header. Are you sure the script does it's thing for Zynq-7000 devices? Maybe it's better to just fix errors manually? Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 1/1] Add ps7_init_gpl.c for Z-turn board
Hi Michal, thank you for your review. > Sorry I missed this patch. Please take a look at script which was sent > by Luca (arm64: zynqmp: add tool to minimize psu_init_gpl.c files) > for tuning psu_init_gpl files. > You should use the same for this file to align it with checkpatch. I'm not sure whether this tool works well for old ps7 devices, but I've fixed the warnings from checkpatch.pl, , sorry for not doing it right away. Will send in a moment. Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rtc: add Microcrystal RV-8803 driver
Signed-off-by: Michael Walle
---
Btw if anybody notices the compatible string difference to the rv3029
driver, ie mc,rv3029 vs microcrystal,rv8803. The "mc" prefix is actually
the legacy one.
drivers/rtc/Kconfig | 10 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rv8803.c | 167 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/rtc/rv8803.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index fd0009b2e2..532e94d337 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -70,6 +70,16 @@ config RTC_RV3029
This driver supports reading and writing the RTC/calendar and the
battery-baced SRAM section.
+config RTC_RV8803
+ bool "Enable RV8803 driver"
+ depends on DM_RTC
+ help
+ The Micro Crystal RV8803 is a high accuracy, ultra-low power I2C
+ Real Time Clock (RTC) with temperature compensation.
+
+ This driver supports reading and writing the RTC/calendar and
+ detects total power failures.
+
config RTC_RX8010SJ
bool "Enable RX8010SJ driver"
depends on DM_RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1724602f1c..915adb87fe 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PL031) += pl031.o
obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
obj-$(CONFIG_RTC_RV3029) += rv3029.o
+obj-$(CONFIG_RTC_RV8803) += rv8803.o
obj-$(CONFIG_RTC_RX8025) += rx8025.o
obj-$(CONFIG_RTC_RX8010SJ) += rx8010sj.o
obj-$(CONFIG_RTC_S3C24X0) += s3c24x0_rtc.o
diff --git a/drivers/rtc/rv8803.c b/drivers/rtc/rv8803.c
new file mode 100644
index 00..2ab40f0833
--- /dev/null
+++ b/drivers/rtc/rv8803.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Date & Time support for Micro Crystal RV-8803-C7.
+ *
+ * based on ds1307.c which is
+ * (C) Copyright 2001, 2002, 2003
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ * Keith Outwater, keith_outwa...@mvis.com`
+ * Steven Scholz, steven.sch...@imc-berlin.de
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * RTC register addresses
+ */
+#define RTC_SEC_REG_ADDR 0x00
+#define RTC_MIN_REG_ADDR 0x01
+#define RTC_HR_REG_ADDR0x02
+#define RTC_DAY_REG_ADDR 0x03
+#define RTC_DATE_REG_ADDR 0x04
+#define RTC_MON_REG_ADDR 0x05
+#define RTC_YR_REG_ADDR0x06
+
+#define RTC_FLAG_REG_ADDR 0x0E
+#define RTC_FLAG_BIT_V1F BIT(0)
+#define RTC_FLAG_BIT_V2F BIT(1)
+
+#define RTC_CTL_REG_ADDR 0x0F
+#define RTC_CTL_BIT_RSTBIT(0)
+
+static int rv8803_rtc_set(struct udevice *dev, const struct rtc_time *tm)
+{
+ int ret;
+ u8 buf[7];
+
+ debug("Set DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
+ tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+ if (tm->tm_year < 2000 || tm->tm_year > 2099)
+ printf("WARNING: year should be between 2000 and 2099!\n");
+
+ buf[RTC_YR_REG_ADDR] = bin2bcd(tm->tm_year % 100);
+ buf[RTC_MON_REG_ADDR] = bin2bcd(tm->tm_mon);
+ buf[RTC_DAY_REG_ADDR] = 1 << (tm->tm_wday & 0x7);
+ buf[RTC_DATE_REG_ADDR] = bin2bcd(tm->tm_mday);
+ buf[RTC_HR_REG_ADDR] = bin2bcd(tm->tm_hour);
+ buf[RTC_MIN_REG_ADDR] = bin2bcd(tm->tm_min);
+ buf[RTC_SEC_REG_ADDR] = bin2bcd(tm->tm_sec);
+
+ ret = dm_i2c_write(dev, 0, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int rv8803_rtc_get(struct udevice *dev, struct rtc_time *tm)
+{
+ int ret;
+ u8 buf[7];
+ int flags;
+
+ flags = dm_i2c_reg_read(dev, RTC_FLAG_REG_ADDR);
+ if (flags < 0)
+ return flags;
+ debug("%s: flags=%Xh\n", __func__, flags);
+
+ if (flags & RTC_FLAG_BIT_V1F)
+ printf("### Warning: temperature compensation has stopped\n");
+
+ if (flags & RTC_FLAG_BIT_V2F) {
+ printf("### Warning: Voltage low, data is invalid\n");
+ return -1;
+ }
+
+ ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ tm->tm_sec = bcd2bin(buf[RTC_SEC_REG_ADDR] & 0x7F);
+ tm->tm_min = bcd2bin(buf[RTC_MIN_REG_ADDR] & 0x7F);
+ tm->tm_hour = bcd2bin(buf[RTC_HR_REG_ADDR] & 0x3F);
+ tm->tm_mday = bcd2bin(buf[RTC_DATE_REG_ADDR] & 0x3F);
+ tm->tm_mon = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F);
+ tm->tm_year = bcd2bin(buf[RTC_YR_REG_ADDR]) + 2000;
+ tm->tm_wday = fls(buf[RTC_DAY_REG_ADDR] & 0x7F) - 1;
+ tm->tm_yday = 0;
+ tm->tm_isdst = 0;
+
+ debug("Get DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
+ tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
Am 27.05.2019 um 18:48 schrieb Tom Rini: On Tue, May 28, 2019 at 01:35:52AM +0900, Masahiro Yamada wrote: On Sat, May 25, 2019 at 5:07 AM Simon Goldschmidt wrote: This adds a size check for SPL that can dynamically check generated SPL binaries (including devicetree) for a size limit that ensures this image plus global data, heap and stack fit in initial SRAM. Since some of these sizes are not available to make, a new host tool 'spl_size_limit' is added that dumps the resulting maximum size for an SPL binary to stdout. This tool is used in toplevel Makefile to implement the size check on SPL binaries. Signed-off-by: Simon Goldschmidt --- Some architectures have SPL size checks. CONFIG_SPL_MAX_FOOTPRINT CONFIG_SPL_MAX_SIZE CONFIG_SPL_BSS_MAX_SIZE Will they be replaced by this new mechanism? Yes, as the existing checks are only sufficient for final link time overflows and not final image overflows. This patch builds on Heinrich Schuchardt's series that add CONFIG_SPL_SIZE_LIMIT to check maximum image size (after potentially adding image headers): https://patchwork.ozlabs.org/patch/1074741/ I just now realize I have forgotton to add that dependency to the patch mail. However, we do have numerous max size defines. This patch tries to bring a better calculation for the maximum SPL image size by taking SRAM size and subtracting what's required in addition to the binary size. In general, the different max size defines could need a cleanup as well, I guess... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2019.07-rc3 released
Hey all, It's release day and here is v2019.07-rc3. I think I have a few outstanding regression fixes to pull in still, and then of course Kconfig migrations. So, what are we doing about DM migration deadlines? Well, first, let me say again, that DM is not required for SPL. This comes up enough that I want to say it again here. Next, if there is active progress on converting things, we'll keep from pulling the code out. This is why for example, we haven't yet pulled out a lot of deprecated SPI code. Some of it is still in progress on being converted, so I need to update the series I posted after the last -rc to remove still less drivers. In terms of a changelog, git log --merges v2019.07-rc2..v2019.07-rc3 continues to improve in quality. If you're sending me a PR, please include a few lines or words in summary and I'll be sure to put it into the merge commit. As this cycle is coming closer to an end, I feel it's time to ask. Is anyone out there being more frustrated with a 3 month release cycle than with a 2 month cycle? I feel like the answer is that the 3 month cycle is working better than 2 and we should keep that going. I'm planning on doing -rc4 on June 10th and -rc5 on June 24th with the release scheduled on July 8th. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master
On Mon, May 27, 2019 at 01:35:21PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell related fix: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Mon, May 27, 2019 at 01:14:04AM +0200, Marek Vasut wrote: > Gen3 PCIe driver + enablement on Salvator-X platforms, > Gen3 recovery SPL used to reload ATF/OpTee/U-Boot instead of minimon, > SDHI HS400 fixes ported from latest BSP and datasheet. > > The following changes since commit e1a2ed7180adeefb6164239a18249dca5701319d: > > Merge git://git.denx.de/u-boot-mpc83xx (2019-05-21 07:13:35 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to b5900a58caf0416355ccab4dc9da55c9a388a953: > > mmc: tmio: sdhi: HS400 manual adjustment (2019-05-21 22:15:32 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Mon, May 27, 2019 at 01:11:36AM +0200, Marek Vasut wrote: > SoCFPGA PL310 cleanup + A10 fix, A10 DT cleanup, DW GPIO fix. > > The following changes since commit 40920bdecc4e1b7096de6f546d7b5c2185554ba6: > > Merge tag 'dm-pull-22may19' of git://git.denx.de/u-boot-dm (2019-05-22 > 12:58:58 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to ca9387e8b1e276e17244010620319cc8bbd1c655: > > Arm: dts: socfpga: Remove invalid property from chose node (2019-05-24 > 14:29:51 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
On Tue, May 28, 2019 at 01:35:52AM +0900, Masahiro Yamada wrote: > On Sat, May 25, 2019 at 5:07 AM Simon Goldschmidt > wrote: > > > > This adds a size check for SPL that can dynamically check generated > > SPL binaries (including devicetree) for a size limit that ensures > > this image plus global data, heap and stack fit in initial SRAM. > > > > Since some of these sizes are not available to make, a new host tool > > 'spl_size_limit' is added that dumps the resulting maximum size for > > an SPL binary to stdout. This tool is used in toplevel Makefile to > > implement the size check on SPL binaries. > > > > Signed-off-by: Simon Goldschmidt > > --- > > Some architectures have SPL size checks. > CONFIG_SPL_MAX_FOOTPRINT > CONFIG_SPL_MAX_SIZE > CONFIG_SPL_BSS_MAX_SIZE > > Will they be replaced by this new mechanism? Yes, as the existing checks are only sufficient for final link time overflows and not final image overflows. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
On Sat, May 25, 2019 at 5:07 AM Simon Goldschmidt wrote: > > This adds a size check for SPL that can dynamically check generated > SPL binaries (including devicetree) for a size limit that ensures > this image plus global data, heap and stack fit in initial SRAM. > > Since some of these sizes are not available to make, a new host tool > 'spl_size_limit' is added that dumps the resulting maximum size for > an SPL binary to stdout. This tool is used in toplevel Makefile to > implement the size check on SPL binaries. > > Signed-off-by: Simon Goldschmidt > --- Some architectures have SPL size checks. CONFIG_SPL_MAX_FOOTPRINT CONFIG_SPL_MAX_SIZE CONFIG_SPL_BSS_MAX_SIZE Will they be replaced by this new mechanism? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: add overall SPL size check
On Fri, May 24, 2019 at 5:17 AM Tom Rini wrote: > > On Thu, May 23, 2019 at 10:08:54PM +0200, Simon Goldschmidt wrote: > > Am 13.05.2019 um 14:45 schrieb Simon Goldschmidt: > > >On Sat, May 11, 2019 at 3:55 AM Tom Rini wrote: > > >> > > >>On Mon, Apr 22, 2019 at 10:27:21PM +0200, Simon Goldschmidt wrote: > > >> > > >>>This adds a size check for SPL that can dynamically check generated > > >>>SPL binaries (including devicetree) for a size limit that ensures > > >>>this image plus global data, heap and stack fit in initial SRAM. > > >>> > > >>>Since some of these sizes are not available to make, a new host tool > > >>>'spl_size_limit' is added that dumps the resulting maximum size for > > >>>an SPL binary to stdout. This tool is used in toplevel Makefile to > > >>>implement the size check on SPL binaries. > > >>> > > >>>Signed-off-by: Simon Goldschmidt > > >> > > >>OK, this has a race / dependency problem: > > >>https://travis-ci.org/trini/u-boot/jobs/530803338 > > > > > >Hmm, let me check that. > > > > OK, so as I see it, this is not a race but a dependency problem: the > > "tools-only" target just does not generate the "generic-asm-offsets.h" file. > > > > However, just adding a dependency to include/generated/generic-asm-offsets.h > > leads to an error (no rule to build that file) since that file is generated > > by Kbuild magic that I don't really get... > > > > Any idea how to make this depend on /Kbuild being run? > > For context, https://patchwork.ozlabs.org/patch/105/ > > Yamada-san, do you have any ideas? Thanks! No, I have no idea. 'tools' depends on 'prepare', which depends on 'prepare0'. So, the dependency should be correct, but I do not see CHK include/generated/generic-asm-offsets.h in the log at all. I do not know why. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] Add 'bcb' command to read/modify/write Android BCB
Hi Sam, On Fri, May 24, 2019 at 01:58:18AM +0300, Sam Protsenko wrote: > For the whole series: > > Reviewed-by: Sam Protsenko > > Thank you for handling this, Eugeniu! Thanks for your support. Assuming there will be little to no changes in the 'bcb' command (which still awaits Simon's Ack), I think you are unblocked with the A/B patches. Looking forward to seeing them. -- Best Regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
Tom Rini schrieb am Mo., 27. Mai 2019, 16:54:
> On Mon, May 27, 2019 at 03:47:13PM +0200, Jean-Jacques Hiblot wrote:
> > Simon,
> >
> >
> > On 24/05/2019 22:10, Simon Goldschmidt wrote:
> > >Am 24.05.2019 um 22:07 schrieb Simon Goldschmidt:
> > >>This adds a size check for SPL that can dynamically check generated
> > >>SPL binaries (including devicetree) for a size limit that ensures
> > >>this image plus global data, heap and stack fit in initial SRAM.
> > >>
> > >>Since some of these sizes are not available to make, a new host tool
> > >>'spl_size_limit' is added that dumps the resulting maximum size for
> > >>an SPL binary to stdout. This tool is used in toplevel Makefile to
> > >>implement the size check on SPL binaries.
> > >>
> > >>Signed-off-by: Simon Goldschmidt
> > >>---
> > >>
> > >>Changes in v3:
> > >>- don't build this new tools for 'make tools-only'
> > >
> > >So this is how far I got.
> > >
> > >Tom, your idea with making this multi-config aware (U-Boot, SPL and TPL)
> > >does not seem to work as 'tools' are only built once, not once per
> > >U-Boot/SPL/TPL. So if we wanted to use this for TPL, too, that would
> > >either mean create yet another tool or pass an option to this new tool
> to
> > >differ between SPL and TPL.
> >
> > If the trouble comes from GENERATED_GBL_DATA_SIZE, you could get its
> value
> > by parsing lib/asm-offsets.s. all the other values could be extracted
> from
> > {.,spl,tpl}/u-boot.cfg
>
> Getting that file to exist has the same problem over for "tools-only".
>
> > If this flies, it could be done by a python script without the need to
> > compile a program
>
> I'm not sure that provides better clarity over what we have here tho.
>
I also think a python script would be less clear than a C tool. But it
could have the problem hidden by not being used for "tools-only" - it would
only be executed after linking SPL...
Regrds,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On Mon, May 27, 2019 at 09:22:05AM +0200, Stefan Agner wrote: > On 27.05.2019 07:21, Igor Opaniuk wrote: > > Hi everyone, > > > > I've finally started looking into the cfb_console.c driver and it's > > conversion to DM_VIDEO after our initial discussion [1]. > > Unfortunately I've a bit underestimated the amount of effort that > > should be done, as mxsfb.c in the Linux mainline obviously pulls the > > whole core fb subsystem > > (drivers/video/fbdev/core), which can take a while and frankly I doubt > > that this is a proper way to do things here. > > Just wanted to mention that the Linux mxsfb fbdev driver is considered > deprecated. > > See: https://lore.kernel.org/patchwork/patch/950619/#1135990 > > Also note that the new DRM driver does use OF graph style bindings, see: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > > > > Taking into account that the deadline for DM_VIDEO conversion is > > 2019.07, it's unlikely that we will manage to do the full conversions > > this cfb_console driver and all dependent hw specific drivers in a > > proper way (where we can provide information about videomodes as > > properties in a proper nodes in DT). > > IMHO, if the deadline hinders us to do it properly, we should extend the > deadline. Agreed. We can always extend deadlines as needed when people are working to solve the problem, and we want it solved correctly. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
On Mon, May 27, 2019 at 03:47:13PM +0200, Jean-Jacques Hiblot wrote:
> Simon,
>
>
> On 24/05/2019 22:10, Simon Goldschmidt wrote:
> >Am 24.05.2019 um 22:07 schrieb Simon Goldschmidt:
> >>This adds a size check for SPL that can dynamically check generated
> >>SPL binaries (including devicetree) for a size limit that ensures
> >>this image plus global data, heap and stack fit in initial SRAM.
> >>
> >>Since some of these sizes are not available to make, a new host tool
> >>'spl_size_limit' is added that dumps the resulting maximum size for
> >>an SPL binary to stdout. This tool is used in toplevel Makefile to
> >>implement the size check on SPL binaries.
> >>
> >>Signed-off-by: Simon Goldschmidt
> >>---
> >>
> >>Changes in v3:
> >>- don't build this new tools for 'make tools-only'
> >
> >So this is how far I got.
> >
> >Tom, your idea with making this multi-config aware (U-Boot, SPL and TPL)
> >does not seem to work as 'tools' are only built once, not once per
> >U-Boot/SPL/TPL. So if we wanted to use this for TPL, too, that would
> >either mean create yet another tool or pass an option to this new tool to
> >differ between SPL and TPL.
>
> If the trouble comes from GENERATED_GBL_DATA_SIZE, you could get its value
> by parsing lib/asm-offsets.s. all the other values could be extracted from
> {.,spl,tpl}/u-boot.cfg
Getting that file to exist has the same problem over for "tools-only".
> If this flies, it could be done by a python script without the need to
> compile a program
I'm not sure that provides better clarity over what we have here tho.
Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] configs: stm32mp15: enable stm32 remoteproc
Activate the remote processor support for stm32mp15 configs. Signed-off-by: Fabien Dessenne --- configs/stm32mp15_basic_defconfig | 2 ++ configs/stm32mp15_trusted_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 0ea9dff..5185072 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -67,6 +67,8 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_STM32_VREFBUF=y CONFIG_DM_REGULATOR_STPMIC1=y +CONFIG_REMOTEPROC=y +CONFIG_REMOTEPROC_STM32_COPRO=y CONFIG_SERIAL_RX_BUFFER=y CONFIG_STM32_SERIAL=y CONFIG_USB=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 3c2bb75..037d7e8 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -57,6 +57,8 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_STM32_VREFBUF=y CONFIG_DM_REGULATOR_STPMIC1=y +CONFIG_REMOTEPROC=y +CONFIG_REMOTEPROC_STM32_COPRO=y CONFIG_SERIAL_RX_BUFFER=y CONFIG_STM32_SERIAL=y CONFIG_USB=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] MAINTAINERS: Add stm32 remoteproc driver
Signed-off-by: Fabien Dessenne --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 33fd465..5c505d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -309,6 +309,7 @@ F: drivers/power/pmic/stpmic1.c F: drivers/power/regulator/stm32-vrefbuf.c F: drivers/power/regulator/stpmic1.c F: drivers/ram/stm32mp1/ +F: drivers/remoteproc/stm32_copro.c F: drivers/misc/stm32_rcc.c F: drivers/reset/stm32-reset.c F: drivers/spi/stm32_qspi.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] remoteproc: Introduce STM32 Cortex-M4 remoteproc driver
This patch introduces support of Cortex-M4 remote processor for STM32
MCU and MPU families.
Signed-off-by: Loic Pallardy
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/Kconfig | 10 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/stm32_copro.c | 257 +++
3 files changed, 268 insertions(+)
create mode 100644 drivers/remoteproc/stm32_copro.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9eb532b..fa6f111 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -40,6 +40,16 @@ config REMOTEPROC_SANDBOX
Say 'y' here to add support for test processor which does dummy
operations for sandbox platform.
+config REMOTEPROC_STM32_COPRO
+ bool "Support for STM32 coprocessor"
+ select REMOTEPROC
+ depends on DM
+ depends on ARCH_STM32MP
+ depends on OF_CONTROL
+ help
+ Say 'y' here to add support for STM32 Cortex-M4 coprocessors via the
+ remoteproc framework.
+
config REMOTEPROC_TI_POWER
bool "Support for TI Power processor"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 77eb708..5b120c1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o
obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
obj-$(CONFIG_REMOTEPROC_K3) += k3_rproc.o
obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
+obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
new file mode 100644
index 000..91e9d6f
--- /dev/null
+++ b/drivers/remoteproc/stm32_copro.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ */
+#define pr_fmt(fmt) "%s: " fmt, __func__
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RCC_GCR_HOLD_BOOT 0
+#define RCC_GCR_RELEASE_BOOT 1
+
+/**
+ * struct stm32_copro_privdata - power processor private data
+ * @reset_ctl: reset controller handle
+ * @hold_boot_regmap: regmap for remote processor reset hold boot
+ * @hold_boot_offset: offset of the register controlling the hold boot setting
+ * @hold_boot_mask:bitmask of the register for the hold boot field
+ * @is_running:is the remote processor running
+ */
+struct stm32_copro_privdata {
+ struct reset_ctl reset_ctl;
+ struct regmap *hold_boot_regmap;
+ uint hold_boot_offset;
+ uint hold_boot_mask;
+ bool is_running;
+};
+
+/**
+ * stm32_copro_probe() - Basic probe
+ * @dev: corresponding STM32 remote processor device
+ * @return 0 if all went ok, else corresponding -ve error
+ */
+static int stm32_copro_probe(struct udevice *dev)
+{
+ struct stm32_copro_privdata *priv;
+ struct regmap *regmap;
+ const fdt32_t *cell;
+ int len, ret;
+
+ priv = dev_get_priv(dev);
+
+ regmap = syscon_regmap_lookup_by_phandle(dev, "st,syscfg-holdboot");
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "unable to find holdboot regmap (%ld)\n",
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+ cell = dev_read_prop(dev, "st,syscfg-holdboot", );
+ if (len < 3 * sizeof(fdt32_t)) {
+ dev_err(dev, "holdboot offset and mask not available\n");
+ return -EINVAL;
+ }
+
+ priv->hold_boot_regmap = regmap;
+ priv->hold_boot_offset = fdtdec_get_number(cell + 1, 1);
+ priv->hold_boot_mask = fdtdec_get_number(cell + 2, 1);
+
+ ret = reset_get_by_index(dev, 0, >reset_ctl);
+ if (ret) {
+ dev_err(dev, "failed to get reset (%d)\n", ret);
+ return ret;
+ }
+
+ dev_dbg(dev, "probed\n");
+
+ return 0;
+}
+
+/**
+ * stm32_copro_set_hold_boot() - Hold boot bit management
+ * @dev: corresponding STM32 remote processor device
+ * @hold: hold boot value
+ * @return 0 if all went ok, else corresponding -ve error
+ */
+static int stm32_copro_set_hold_boot(struct udevice *dev, bool hold)
+{
+ struct stm32_copro_privdata *priv;
+ uint val;
+ int ret;
+
+ priv = dev_get_priv(dev);
+
+ val = hold ? RCC_GCR_HOLD_BOOT : RCC_GCR_RELEASE_BOOT;
+
+ /*
+* Note: shall run an SMC call (STM32_SMC_RCC) if platform is secured.
+* To be updated when the code for this SMC service is available which
+* is not the case for the time being.
+*/
+ ret = regmap_update_bits(priv->hold_boot_regmap, priv->hold_boot_offset,
+priv->hold_boot_mask, val);
+ if (ret)
+ dev_err(dev, "failed to set hold
[U-Boot] [PATCH 1/2] ls1046ardb: Add CONFIG_ENV_ADDR to init env in qspi boot
Signed-off-by: Pankit Garg --- include/configs/ls1046ardb.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h index f22e863..5741014 100644 --- a/include/configs/ls1046ardb.h +++ b/include/configs/ls1046ardb.h @@ -162,6 +162,8 @@ #define CONFIG_ENV_SIZE0x2000 /* 8KB */ #define CONFIG_ENV_OFFSET 0x50/* 5MB */ #define CONFIG_ENV_SECT_SIZE 0x4 /* 256KB */ +#define CONFIG_SYS_FSL_QSPI_BASE0x4000 +#define CONFIG_ENV_ADDR CONFIG_SYS_FSL_QSPI_BASE + CONFIG_ENV_OFFSET #else #if defined(CONFIG_SD_BOOT) #define CONFIG_SYS_MMC_ENV_DEV 0 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] armv8: fsl-layerscape: Change bootcmd update logic
Change bootcmd update logic when CONFIG_ENV_ADDR is not defined
Signed-off-by: Pankit Garg
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index aeaf7b8..09f6413 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -874,7 +874,11 @@ int board_late_init(void)
* check if gd->env_addr is default_environment; then setenv bootcmd
* and mcinitcmd.
*/
+#if !defined(CONFIG_ENV_ADDR) || defined(ENV_IS_EMBEDDED)
+ if (gd->env_addr == (ulong)_environment[0]) {
+#else
if (gd->env_addr + gd->reloc_off == (ulong)_environment[0]) {
+#endif
fsl_setenv_bootcmd();
fsl_setenv_mcinitcmd();
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] remoteproc: fix function headers
Add full function comment headers.
Fix rproc_is_initialized() return value description.
Signed-off-by: Fabien Dessenne
---
include/remoteproc.h | 104 +--
1 file changed, 68 insertions(+), 36 deletions(-)
diff --git a/include/remoteproc.h b/include/remoteproc.h
index a59dba8..aa90a67 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -45,32 +45,73 @@ struct dm_rproc_uclass_pdata {
};
/**
- * struct dm_rproc_ops - Operations that are provided by remote proc driver
- * @init: Initialize the remoteproc device invoked after probe (optional)
- * Return 0 on success, -ve error on fail
- * @load: Load the remoteproc device using data provided(mandatory)
- * This takes the following additional arguments.
- * addr- Address of the binary image to be loaded
- * size- Size of the binary image to be loaded
- * Return 0 on success, -ve error on fail
- * @start: Start the remoteproc device (mandatory)
- * Return 0 on success, -ve error on fail
- * @stop: Stop the remoteproc device (optional)
- * Return 0 on success, -ve error on fail
- * @reset: Reset the remote proc device (optional)
- * Return 0 on success, -ve error on fail
- * @is_running:Check if the remote processor is running(optional)
- * Return 0 on success, 1 if not running, -ve on others errors
- * @ping: Ping the remote device for basic communication check(optional)
- * Return 0 on success, 1 if not responding, -ve on other errors
+ * struct dm_rproc_ops - Driver model remote proc operations.
+ *
+ * This defines the operations provided by remote proc driver.
*/
struct dm_rproc_ops {
+ /**
+* init() - Initialize the remoteproc device (optional)
+*
+* This is called after the probe is completed allowing the remote
+* processor drivers to split up the initializations between probe and
+* init if needed.
+*
+* @dev:Remote proc device
+* @return 0 if all ok, else appropriate error value.
+*/
int (*init)(struct udevice *dev);
+
+ /**
+* load() - Load the remoteproc device using data provided (mandatory)
+*
+* Load the remoteproc device with an image, do not start the device.
+*
+* @dev:Remote proc device
+* @addr: Address of the image to be loaded
+* @size: Size of the image to be loaded
+* @return 0 if all ok, else appropriate error value.
+*/
int (*load)(struct udevice *dev, ulong addr, ulong size);
+
+ /**
+* start() - Start the remoteproc device (mandatory)
+*
+* @dev:Remote proc device
+* @return 0 if all ok, else appropriate error value.
+*/
int (*start)(struct udevice *dev);
+
+ /**
+* stop() - Stop the remoteproc device (optional)
+*
+* @dev:Remote proc device
+* @return 0 if all ok, else appropriate error value.
+*/
int (*stop)(struct udevice *dev);
+
+ /**
+* reset() - Reset the remoteproc device (optional)
+*
+* @dev:Remote proc device
+* @return 0 if all ok, else appropriate error value.
+*/
int (*reset)(struct udevice *dev);
+
+ /**
+* is_running() - Check if the remote processor is running (optional)
+*
+* @dev:Remote proc device
+* @return 0 if running, 1 if not running, -ve on error.
+*/
int (*is_running)(struct udevice *dev);
+
+ /**
+* ping() - Ping the remote device for basic communication (optional)
+*
+* @dev:Remote proc device
+* @return 0 on success, 1 if not responding, -ve on other errors.
+*/
int (*ping)(struct udevice *dev);
};
@@ -80,23 +121,20 @@ struct dm_rproc_ops {
#ifdef CONFIG_REMOTEPROC
/**
* rproc_init() - Initialize all bound remote proc devices
- *
- * Return: 0 if all ok, else appropriate error value.
+ * @return 0 if all ok, else appropriate error value.
*/
int rproc_init(void);
/**
* rproc_dev_init() - Initialize a remote proc device based on id
* @id:id of the remote processor
- *
- * Return: 0 if all ok, else appropriate error value.
+ * @return 0 if all ok, else appropriate error value.
*/
int rproc_dev_init(int id);
/**
* rproc_is_initialized() - check to see if remoteproc devices are initialized
- *
- * Return: 0 if all devices are initialized, else appropriate error value.
+ * @return true if all devices are initialized, false otherwise.
*/
bool rproc_is_initialized(void);
@@ -105,55 +143,49 @@ bool rproc_is_initialized(void);
* @id:id of the remote processor
* @addr: address in memory where the binary image
[U-Boot] [PATCH v2 4/7] remoteproc: add elf file load support
The current implementation supports only binary file load.
Add helpers to support ELF format (sanity check, and load).
Note that since an ELF image is built for the remote processor, the load
function uses the device_to_virt ops to translate the addresses.
Implement a basic translation for sandbox_testproc.
Add related tests. Test result:
=> ut dm remoteproc_elf
Test: dm_test_remoteproc_elf: remoteproc.c
Test: dm_test_remoteproc_elf: remoteproc.c (flat tree)
Failures: 0
Signed-off-by: Loic Pallardy
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/rproc-uclass.c | 99 +++
drivers/remoteproc/sandbox_testproc.c | 19 ++
include/remoteproc.h | 30 -
test/dm/remoteproc.c | 122 ++
4 files changed, 267 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index c8a41a6..4d85732 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -5,6 +5,7 @@
*/
#define pr_fmt(fmt) "%s: " fmt, __func__
#include
+#include
#include
#include
#include
@@ -291,6 +292,104 @@ int rproc_dev_init(int id)
return ret;
}
+/* Basic function to verify ELF image format */
+int rproc_elf_sanity_check(ulong addr, ulong size)
+{
+ Elf32_Ehdr *ehdr;
+ char class;
+
+ if (!addr) {
+ pr_debug("Invalid fw address?\n");
+ return -EFAULT;
+ }
+
+ if (size < sizeof(Elf32_Ehdr)) {
+ pr_debug("Image is too small\n");
+ return -ENOSPC;
+ }
+
+ ehdr = (Elf32_Ehdr *)addr;
+ class = ehdr->e_ident[EI_CLASS];
+
+ if (!IS_ELF(*ehdr) || ehdr->e_type != ET_EXEC || class != ELFCLASS32) {
+ pr_debug("Not an executable ELF32 image\n");
+ return -EPROTONOSUPPORT;
+ }
+
+ /* We assume the firmware has the same endianness as the host */
+# ifdef __LITTLE_ENDIAN
+ if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
+# else /* BIG ENDIAN */
+ if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
+# endif
+ pr_debug("Unsupported firmware endianness\n");
+ return -EILSEQ;
+ }
+
+ if (size < ehdr->e_shoff + sizeof(Elf32_Shdr)) {
+ pr_debug("Image is too small\n");
+ return -ENOSPC;
+ }
+
+ if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+ pr_debug("Image is corrupted (bad magic)\n");
+ return -EBADF;
+ }
+
+ if (ehdr->e_phnum == 0) {
+ pr_debug("No loadable segments\n");
+ return -ENOEXEC;
+ }
+
+ if (ehdr->e_phoff > size) {
+ pr_debug("Firmware size is too small\n");
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
+/* A very simple elf loader, assumes the image is valid */
+int rproc_elf_load_image(struct udevice *dev, unsigned long addr)
+{
+ Elf32_Ehdr *ehdr; /* Elf header structure pointer */
+ Elf32_Phdr *phdr; /* Program header structure pointer */
+ const struct dm_rproc_ops *ops;
+ unsigned int i;
+
+ ehdr = (Elf32_Ehdr *)addr;
+ phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
+
+ ops = rproc_get_ops(dev);
+
+ /* Load each program header */
+ for (i = 0; i < ehdr->e_phnum; ++i) {
+ void *dst = (void *)(uintptr_t)phdr->p_paddr;
+ void *src = (void *)addr + phdr->p_offset;
+
+ if (phdr->p_type != PT_LOAD)
+ continue;
+
+ if (ops->device_to_virt)
+ dst = ops->device_to_virt(dev, (ulong)dst);
+
+ dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
+ i, dst, phdr->p_filesz);
+ if (phdr->p_filesz)
+ memcpy(dst, src, phdr->p_filesz);
+ if (phdr->p_filesz != phdr->p_memsz)
+ memset(dst + phdr->p_filesz, 0x00,
+ phdr->p_memsz - phdr->p_filesz);
+ flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN),
+ roundup((unsigned long)dst + phdr->p_filesz,
+ ARCH_DMA_MINALIGN) -
+ rounddown((unsigned long)dst, ARCH_DMA_MINALIGN));
+ ++phdr;
+ }
+
+ return 0;
+}
+
int rproc_load(int id, ulong addr, ulong size)
{
struct udevice *dev = NULL;
diff --git a/drivers/remoteproc/sandbox_testproc.c
b/drivers/remoteproc/sandbox_testproc.c
index 51a67e6..5f35119 100644
--- a/drivers/remoteproc/sandbox_testproc.c
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/**
* enum sandbox_state - different device states
@@ -300,6 +301,23 @@ static int sandbox_testproc_ping(struct udevice *dev)
return ret;
}
+#define
[U-Boot] [PATCH v2 3/7] remoteproc: add device_to_virt ops
Introduce the device_to_virt function to allow translation between
device address (remote processor view) and virtual address (main
processor view).
Signed-off-by: Loic Pallardy
Signed-off-by: Fabien Dessenne
---
include/remoteproc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/remoteproc.h b/include/remoteproc.h
index aa90a67..aef6ff2 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -113,6 +113,18 @@ struct dm_rproc_ops {
* @return 0 on success, 1 if not responding, -ve on other errors.
*/
int (*ping)(struct udevice *dev);
+
+ /**
+* device_to_virt() - Return translated virtual address (optional)
+*
+* Translate a device address (remote processor view) to virtual
+* address (main processor view).
+*
+* @dev:Remote proc device
+* @da: Device address
+* @return virtual address.
+*/
+ void * (*device_to_virt)(struct udevice *dev, ulong da);
};
/* Accessor */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] dm: core: Introduce xxx_translate_dma_address()
Add the following functions to translate DMA address to CPU address:
- dev_translate_dma_address()
- ofnode_translate_dma_address()
- of_translate_dma_address()
- fdt_translate_dma_address()
These functions work the same way as xxx_translate_address(), with the
difference that the translation relies on the "dma-ranges" property
instead of the "ranges" property.
Add related test. Test report:
=> ut dm fdt_translation
Test: dm_test_fdt_translation: test-fdt.c
Test: dm_test_fdt_translation: test-fdt.c (flat tree)
Failures: 0
Signed-off-by: Fabien Dessenne
---
arch/sandbox/dts/test.dts | 4
common/fdt_support.c | 6 ++
drivers/core/of_addr.c| 4
drivers/core/ofnode.c | 8
drivers/core/read.c | 5 +
include/dm/of_addr.h | 18 ++
include/dm/ofnode.h | 16 +++-
include/dm/read.h | 20 +++-
include/fdt_support.h | 24
test/dm/test-fdt.c| 12
10 files changed, 115 insertions(+), 2 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d645..a37e10c 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -732,6 +732,10 @@
3 0x300 0xB000 0x1000
>;
+ dma-ranges = <0 0x000 0x1000 0x1000
+ 1 0x100 0x2000 0x1000
+>;
+
dev@0,0 {
compatible = "denx,u-boot-fdt-dummy";
reg = <0 0x0 0x1000>;
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 4e7cf6e..6ec0742 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1279,6 +1279,12 @@ u64 fdt_translate_address(const void *blob, int
node_offset,
return __of_translate_address(blob, node_offset, in_addr, "ranges");
}
+u64 fdt_translate_dma_address(const void *blob, int node_offset,
+ const fdt32_t *in_addr)
+{
+ return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
+}
+
/**
* fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
* who's reg property matches a physical cpu address
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 1bfaaee..4e256d9 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -318,6 +318,10 @@ u64 of_translate_address(const struct device_node *dev,
const __be32 *in_addr)
return __of_translate_address(dev, in_addr, "ranges");
}
+u64 of_translate_dma_address(const struct device_node *dev, const __be32
*in_addr)
+{
+ return __of_translate_address(dev, in_addr, "dma-ranges");
+}
static int __of_address_to_resource(const struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index cc0c031..e68a735 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -763,6 +763,14 @@ u64 ofnode_translate_address(ofnode node, const fdt32_t
*in_addr)
return fdt_translate_address(gd->fdt_blob,
ofnode_to_offset(node), in_addr);
}
+u64 ofnode_translate_dma_address(ofnode node, const fdt32_t *in_addr)
+{
+ if (ofnode_is_np(node))
+ return of_translate_dma_address(ofnode_to_np(node), in_addr);
+ else
+ return fdt_translate_dma_address(gd->fdt_blob,
ofnode_to_offset(node), in_addr);
+}
+
int ofnode_device_is_compatible(ofnode node, const char *compat)
{
if (ofnode_is_np(node))
diff --git a/drivers/core/read.c b/drivers/core/read.c
index 6bda077..1a044b0 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -265,6 +265,11 @@ u64 dev_translate_address(struct udevice *dev, const
fdt32_t *in_addr)
return ofnode_translate_address(dev_ofnode(dev), in_addr);
}
+u64 dev_translate_dma_address(struct udevice *dev, const fdt32_t *in_addr)
+{
+ return ofnode_translate_dma_address(dev_ofnode(dev), in_addr);
+}
+
int dev_read_alias_highest_id(const char *stem)
{
if (of_live_active())
diff --git a/include/dm/of_addr.h b/include/dm/of_addr.h
index 12b1a99..3fa1ffc 100644
--- a/include/dm/of_addr.h
+++ b/include/dm/of_addr.h
@@ -27,6 +27,24 @@
u64 of_translate_address(const struct device_node *no, const __be32 *in_addr);
/**
+ * of_translate_dma_address() - translate a device-tree DMA address to a CPU
+ * address
+ *
+ * Translate a DMA address from the device-tree into a CPU physical address,
+ * this walks up the tree and applies the various bus mappings on the way.
+ *
+ * Note: We consider that crossing any level with #size-cells == 0 to mean
+ * that translation is impossible (that is we are not dealing with a value
+ * that can be mapped to a cpu physical address). This is not really specified
+ * that way, but this is traditionally the way IBM at least do things
+ *
+ * @np: node to
[U-Boot] [MMC] RPMB: Transfer data timeout error
Hello,
I am using Broadcom northstar2 platform, which uses Arasan eMMC 5.0
controller and micron 4.5.1 eMMC card.
Switched to “rpmb” partition using “mmc dev 0 3” command.
I am trying to use “mmc rpmb counter” command and results is “Transfer data
timeout”.
Further investigation, found, mmc_rpmb_get_counter () -à
mmc_rpmb_request(), which expects response type of MMC_RSP_R1b.
As part of the rpmb protocol, MMC_CMD_SET_BLOCK_COUNT (23) is set to #1 and
MMC_CMD_WRITE_MULTIPLE_BLOCK (25) is send. For multi block write command,
data is rpmb data.
As the expected response is set to MMC_RSP_R1b, in sdhci_send_command(),
data mask is or’ed with SDHCI_INT_DATA_END (mask |= SDHCI_INT_DATA_END).
After the sdhci_cmd_done() happens, data mask is written to
SDHCI_INT_STATUS. I guess this is sending STOP, because of
SDHCI_INT_DATA_END. As the actual rpmb data is transferred in
sdhci_transfer_data (), which will check for rdy (SDHCI_INT_SPACE_AVAIL|
SDHCI_INT_DATA_AVAIL). The SDHCI_INT_STATUS register read value will be
always 0x0 and causing for “Transfer data timeout”
Would like to know whether response type for mmc_rpmb_request() can be
changed to MMC_RSP_R1 (instead of MMC_RSP_R1b)
Or using SDHCI_QUIRK_BROKEN_R1B quirk in mmc_rpmb_request() like the
following or any other alternative ways, please suggest:
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -91,6 +91,7 @@ static int mmc_rpmb_request(struct mmc *mmc, const struct
s_rpmb *s,
{
struct mmc_cmd cmd = {0};
struct mmc_data data;
+ struct sdhci_host *host = mmc->priv;
int ret;
ret = mmc_set_blockcount(mmc, count, is_rel_write);
@@ -105,6 +106,9 @@ static int mmc_rpmb_request(struct mmc *mmc, const
struct s_rpmb *s,
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
+ if (host->quirks & SDHCI_QUIRK_BROKEN_R1B)
+ cmd.resp_type = MMC_RSP_R1;
+
data.src = (const char *)s;
data.blocks = 1;
data.blocksize = MMC_MAX_BLOCK_LEN;
Thanks,
-Bharat
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Add STM32 Cortex-M4 remoteproc driver
This patchset adds an STM32 remoteproc driver. Patch 1 adds the xxx_translate_dma_address() API which is the equivalent of the xxx_translate_address() relying on the "dma-ranges" property instead of the "ranges" property. Patch 2 fixes and completes function headers of remoteproc.h. Patch 3 & 4 add the support of the ELF image loading (the current implementation supports only binary image loading). Patch 5 is about the driver, and patches 6 & 7 are about MAINTAINERS and configs update. Changes since v1: -Added tests for rproc_elf*() and *_translate_dma_address() -Changed memory translation ops from da_to_pa() to device_to_virt() : the name is updated and the translation now converts to virtual instead of physical. -Merged rproc_elf_is_valid() in rproc_elf_sanity_check() -Used explicit error values in rproc_elf_sanity_check() -Added and fix comments in various headers -Misc minor changes Fabien Dessenne (7): dm: core: Introduce xxx_translate_dma_address() remoteproc: fix function headers remoteproc: add device_to_virt ops remoteproc: add elf file load support remoteproc: Introduce STM32 Cortex-M4 remoteproc driver MAINTAINERS: Add stm32 remoteproc driver configs: stm32mp15: enable stm32 remoteproc MAINTAINERS | 1 + arch/sandbox/dts/test.dts | 4 + common/fdt_support.c | 6 + configs/stm32mp15_basic_defconfig | 2 + configs/stm32mp15_trusted_defconfig | 2 + drivers/core/of_addr.c| 4 + drivers/core/ofnode.c | 8 ++ drivers/core/read.c | 5 + drivers/remoteproc/Kconfig| 10 ++ drivers/remoteproc/Makefile | 1 + drivers/remoteproc/rproc-uclass.c | 99 + drivers/remoteproc/sandbox_testproc.c | 19 +++ drivers/remoteproc/stm32_copro.c | 257 ++ include/dm/of_addr.h | 18 +++ include/dm/ofnode.h | 16 ++- include/dm/read.h | 20 ++- include/fdt_support.h | 24 include/remoteproc.h | 146 +-- test/dm/remoteproc.c | 122 test/dm/test-fdt.c| 12 ++ 20 files changed, 735 insertions(+), 41 deletions(-) create mode 100644 drivers/remoteproc/stm32_copro.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v5] sun8i: h3: Add support for the Beelink-x2 STB
On Mon, 27 May 2019 at 09:30, Clément Péron wrote:
>
> Hi Marcus,
>
> On Sun, 26 May 2019 at 16:57, wrote:
> >
> > From: Marcus Cooper
> >
> > The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> > 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
> > SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, an IR receiver, a
> > dual colour LED and an optical S/PDIF connector.
> >
> > Signed-off-by: Marcus Cooper
> > ---
> > Changes in v5:
> > - Corrected DRAM Clock to what is reported on Android boot
> > - Removed support for SY8106A regulator
> > - Set CONFIG_SPL_TEXT_BASE which is now required.
> >
> > Changes in v4:
> > - updated dts to reflex current linux kernel status
> >
> > Changes in v3:
> > - Removed incorrect commit author
> > - Included v1-v2 change info
> >
> > Changes in v2:
> > - updated dts to reflex current linux kernel status
> > ---
> > arch/arm/dts/Makefile| 1 +
> > arch/arm/dts/sun8i-h3-beelink-x2.dts | 216 +++
> > board/sunxi/MAINTAINERS | 5 +
> > configs/beelink_x2_defconfig | 18 +++
> > 4 files changed, 240 insertions(+)
> > create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
> > create mode 100644 configs/beelink_x2_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 83058c4452..716108dd2e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -472,6 +472,7 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
> > sun8i-h2-plus-orangepi-r1.dtb \
> > sun8i-h2-plus-orangepi-zero.dtb \
> > sun8i-h3-bananapi-m2-plus.dtb \
> > + sun8i-h3-beelink-x2.dtb \
> > sun8i-h3-libretech-all-h3-cc.dtb \
> > sun8i-h3-nanopi-m1.dtb \
> > sun8i-h3-nanopi-m1-plus.dtb \
> > diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts
> > b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> > new file mode 100644
> > index 00..25540b7694
> > --- /dev/null
> > +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> > @@ -0,0 +1,216 @@
> > +/*
> > + * Copyright (C) 2017 Marcus Cooper
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun8i-h3.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "Beelink X2";
> > + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
> > +
> > + aliases {
> > + serial0 =
> > + ethernet0 =
> > + ethernet1 =
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + connector {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <_out_con>;
> > +
Re: [U-Boot] [PATCH v3] spl: add overall SPL size check
Simon,
On 24/05/2019 22:10, Simon Goldschmidt wrote:
Am 24.05.2019 um 22:07 schrieb Simon Goldschmidt:
This adds a size check for SPL that can dynamically check generated
SPL binaries (including devicetree) for a size limit that ensures
this image plus global data, heap and stack fit in initial SRAM.
Since some of these sizes are not available to make, a new host tool
'spl_size_limit' is added that dumps the resulting maximum size for
an SPL binary to stdout. This tool is used in toplevel Makefile to
implement the size check on SPL binaries.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- don't build this new tools for 'make tools-only'
So this is how far I got.
Tom, your idea with making this multi-config aware (U-Boot, SPL and
TPL) does not seem to work as 'tools' are only built once, not once
per U-Boot/SPL/TPL. So if we wanted to use this for TPL, too, that
would either mean create yet another tool or pass an option to this
new tool to differ between SPL and TPL.
If the trouble comes from GENERATED_GBL_DATA_SIZE, you could get its
value by parsing lib/asm-offsets.s. all the other values could be
extracted from {.,spl,tpl}/u-boot.cfg
If this flies, it could be done by a python script without the need to
compile a program
JJ
Regard,
Simon
Changes in v2:
- added missing tools/spl_size_limit.c
Kconfig | 8
Makefile | 3 ++-
common/spl/Kconfig | 36
tools/Makefile | 4
tools/spl_size_limit.c | 30 ++
5 files changed, 72 insertions(+), 9 deletions(-)
create mode 100644 tools/spl_size_limit.c
diff --git a/Kconfig b/Kconfig
index 1221d1af69..5f5c5ccfd6 100644
--- a/Kconfig
+++ b/Kconfig
@@ -172,14 +172,6 @@ config TPL_SYS_MALLOC_F_LEN
particular needs this to operate, so that it can allocate the
initial serial device and any others that are needed.
-config SPL_SIZE_LIMIT
- int "Maximum size of SPL image"
- depends on SPL
- default 0
- help
- Specifies the maximum length of the U-Boot SPL image.
- If this value is zero, it is ignored.
-
menuconfig EXPERT
bool "Configure standard U-Boot features (expert users)"
default y
diff --git a/Makefile b/Makefile
index 7d910b3682..ed7e12120f 100644
--- a/Makefile
+++ b/Makefile
@@ -797,7 +797,7 @@ BOARD_SIZE_CHECK =
endif
ifneq ($(CONFIG_SPL_SIZE_LIMIT),0)
-SPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_SPL_SIZE_LIMIT))
+SPL_SIZE_CHECK = @$(call size_check,$@,$$(tools/spl_size_limit))
else
SPL_SIZE_CHECK =
endif
@@ -1779,6 +1779,7 @@ checkarmreloc: u-boot
envtools: scripts_basic $(version_h) $(timestamp_h)
$(Q)$(MAKE) $(build)=tools/env
+tools-only: export TOOLS_ONLY=y
tools-only: scripts_basic $(version_h) $(timestamp_h)
$(Q)$(MAKE) $(build)=tools
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index c7cd34449a..6a98536f20 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -25,6 +25,42 @@ config SPL_FRAMEWORK
supports MMC, NAND and YMODEM and other methods loading of
U-Boot
and the Linux Kernel. If unsure, say Y.
+config SPL_SIZE_LIMIT
+ hex "Maximum size of SPL image"
+ depends on SPL
+ default 0
+ help
+ Specifies the maximum length of the U-Boot SPL image.
+ If this value is zero, it is ignored.
+
+config SPL_SIZE_LIMIT_SUBTRACT_GD
+ bool "SPL image size check: provide space for global data"
+ depends on SPL_SIZE_LIMIT > 0
+ help
+ If enabled, aligned size of global data is reserved in
+ SPL_SIZE_LIMIT check to ensure such an image does not overflow
SRAM
+ if SPL_SIZE_LIMIT describes the size of SRAM available for SPL
when
+ pre-reloc global data is put into this SRAM, too.
+
+config SPL_SIZE_LIMIT_SUBTRACT_MALLOC
+ bool "SPL image size check: provide space for malloc() pool
before relocation"
+ depends on SPL_SIZE_LIMIT > 0
+ help
+ If enabled, SPL_SYS_MALLOC_F_LEN is reserved in SPL_SIZE_LIMIT
check
+ to ensure such an image does not overflow SRAM if SPL_SIZE_LIMIT
+ describes the size of SRAM available for SPL when pre-reloc
malloc
+ pool is put into this SRAM, too.
+
+config SPL_SIZE_LIMIT_PROVIDE_STACK
+ hex "SPL image size check: provide stack space before relocation"
+ depends on SPL_SIZE_LIMIT > 0
+ default 0
+ help
+ If set, this size is reserved in SPL_SIZE_LIMIT check to
ensure such
+ an image does not overflow SRAM if SPL_SIZE_LIMIT describes
the size
+ of SRAM available for SPL when the stack required before
reolcation
+ uses this SRAM, too.
+
config HANDOFF
bool "Pass hand-off information from SPL to U-Boot proper"
depends on BLOBLIST
diff --git a/tools/Makefile b/tools/Makefile
index e2f572cae1..33e90a8025 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -199,6 +199,10 @@ hostprogs-$(CONFIG_RISCV) += prelink-riscv
[U-Boot] [PATCH v2 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion
commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
wanted to enable DM_MMC only for U-Boot and not for SPL.
But CONFIG_DM_MMC is defined for SPL build too. Because of this
MMC device was not getting registered for SPL causing MMC/SD
boot breakage.
Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
CONFIG_SPL_DM_MMC is defined.
Signed-off-by: Sekhar Nori
---
board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 2c2f885d43e4..fe1bf4410145 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -353,7 +353,7 @@ int misc_init_r(void)
return 0;
}
-#ifndef CONFIG_DM_MMC
+#if !CONFIG_IS_ENABLED(DM_MMC)
#ifdef CONFIG_MMC_DAVINCI
static struct davinci_mmc mmc_sd0 = {
.reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: davinci: SPL: fix BSS initialization
U-Boot README recommends initializing SDRAM in board_init_f(). DA850
was doing it as part of board_init_r() (through call to spl_board_init()
which calls arch_cpu_init() which calls da850_ddr_setup())
This worked fine till commit 15b8c7505819 ("davinci:
da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full") moved
BSS to SDRAM.
Functions like mmc_initialize() called in board_init_r() assume BSS is
available. Since SDRAM was not initialized when arch/arm/lib/crt0.S tried
to initialize BSS to 0, BSS is not initialized correctly.
Fix this by simply calling arch_cpu_init() from board_init_f(). Also move
preloader_console_init() there to help debug issues with board_init_r().
With this spl_board_init() is no longer needed, we remove it.
Tested using MMC/SD boot on OMAP-L138 LCDK board.
Signed-off-by: Sekhar Nori
---
arch/arm/mach-davinci/spl.c | 2 +-
configs/da850_am18xxevm_defconfig | 1 -
configs/da850evm_defconfig| 1 -
configs/da850evm_nand_defconfig | 1 -
configs/ipam390_defconfig | 1 -
configs/omapl138_lcdk_defconfig | 1 -
6 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index 103639e34757..9861afd820a1 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -31,7 +31,7 @@ void putc(char c)
}
#endif /* CONFIG_SPL_LIBCOMMON_SUPPORT */
-void spl_board_init(void)
+void board_init_f(ulong dummy)
{
arch_cpu_init();
preloader_console_init();
diff --git a/configs/da850_am18xxevm_defconfig
b/configs/da850_am18xxevm_defconfig
index f09822211312..7ecdc361ce85 100644
--- a/configs/da850_am18xxevm_defconfig
+++ b/configs/da850_am18xxevm_defconfig
@@ -20,7 +20,6 @@ CONFIG_VERSION_VARIABLE=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SPI_LOAD=y
CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="U-Boot > "
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 8c16d5c4f5a7..c09505828255 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -21,7 +21,6 @@ CONFIG_VERSION_VARIABLE=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_SPI_LOAD=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index b8eac0e65995..727101634679 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -19,7 +19,6 @@ CONFIG_VERSION_VARIABLE=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_NAND_SUPPORT=y
diff --git a/configs/ipam390_defconfig b/configs/ipam390_defconfig
index f2270264bda4..88a0d971ef28 100644
--- a/configs/ipam390_defconfig
+++ b/configs/ipam390_defconfig
@@ -14,7 +14,6 @@ CONFIG_VERSION_VARIABLE=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_NAND_SUPPORT=y
CONFIG_SPL_OS_BOOT=y
CONFIG_HUSH_PARSER=y
diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index e43141844a10..48f251ebb804 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -18,7 +18,6 @@ CONFIG_VERSION_VARIABLE=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
CONFIG_SPL_NAND_SUPPORT=y
CONFIG_HUSH_PARSER=y
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] ARM: davinci: omapl138_lcdk: fix MMC/SD boot breakage
Hi, Here is a set of patches that fixes MMC/SD boot breakage introduced after 2018.09 release. This was tested with MMC/SD boot on OMAP-L138 LCDK. Peter, I dropped your Tested-by: because the patches changed. It will be great to get your testing done again. v2: Move console init to board_init_f() and drop spl_board_init() as its not needed anymore. Thanks, Sekhar Sekhar Nori (2): ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion ARM: davinci: SPL: fix BSS initialization arch/arm/mach-davinci/spl.c| 2 +- board/davinci/da8xxevm/omapl138_lcdk.c | 2 +- configs/da850_am18xxevm_defconfig | 1 - configs/da850evm_defconfig | 1 - configs/da850evm_nand_defconfig| 1 - configs/ipam390_defconfig | 1 - configs/omapl138_lcdk_defconfig| 1 - 7 files changed, 2 insertions(+), 7 deletions(-) -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: add gpio-hog support
On 27. 05. 19 14:48, Heiko Schocher wrote:
> Hello Michal,
>
> Am 27.05.2019 um 14:31 schrieb Michal Simek:
>> Hi,
>>
>> On 27. 05. 19 14:06, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 27.05.2019 um 13:34 schrieb Michal Simek:
On 27. 05. 19 12:49, Heiko Schocher wrote:
> add gpio-hog support. GPIO hogging is a mechanism
> providing automatic GPIO request and configuration
> as part of the gpio-controller's driver probe function.
>
> for more infos see:
> doc/device-tree-bindings/gpio/gpio.txt
>
> Signed-off-by: Heiko Schocher
>
> ---
> not yet started clean travis build, see result:
> https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
>
> Changes in v2:
> - move gpio_hog() call from post_probe() to post_bind()
> call. Check if current gpio device has gpio-hog
> definitions, if so, probe it.
I am using i2c to gpio chip and with v2 this chip is not listed via dm
completely. It means something is wrong for sure.
>>>
>>> What do you mean with "this chip is not listed via dm completely" ?
>>
>> first of all I am using zcu102
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynqmp-zcu102-revA.dts;h=6e22871713139517ad5f7f1d2e659690233bd946;hb=HEAD#l129
>>
>>
>> There are 2 i2c-gpio chips @20 and @21. @20 has hogs and it is not
>> listed via dm tree when v2 is applied (v1 is without any issue).
>> @21 is seen there.
>
> Hmm... look like the same setup as mine ...
>
It looks like that parent is not probed that's why it is failing.
>>>
>>> I use this on the aristainetos board, work currently on rework for DM/DT
>>> usage in U-Boot, dts not yet in u-boot but in linux, see:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi#n286
>>>
>>>
>>>
>>> and added for u-boot now gpio hog definitons:
>>>
>>> {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_i2c3>;
>>> status = "okay";
>>>
>>> expander: tca6416@20 {
>>> compatible = "ti,tca6416";
>>> reg = <0x20>;
>>> #gpio-cells = <2>;
>>> gpio-controller;
>>>
>>> env_reset {
>>> gpio-hog;
>>> input;
>>> gpios = <6 GPIO_ACTIVE_LOW>;
>>> };
>>> boot_rescue {
>>> gpio-hog;
>>> input;
>>> gpios = <7 GPIO_ACTIVE_LOW>;
>>
>> nit: there could be also line-name setup.
>
> Ok, I add support for it.
>
>>> };
>>> };
>>> };
>>
>> The setup looks the same as I have here.
>
> Yes.
>
>>>
>>> works fine for me ...
>>>
>>> => dm tree
>>> Class Index Probed Driver Name
>>> ---
>>> root 0 [ + ] root_driver root_driver
>>> [...]
>>> i2c 2 [ + ] i2c_mxc | | |-- i2c@21a8000
>>> gpio 7 [ + ] pca953x | | | |--
>>> tca6416@20
>>>
>>> => gpio status
>>> [...]
>>> Bank gpio@20_:
>>> gpio@20_6: input: 0 [x] env_reset.gpio-hog
>>> gpio@20_7: input: 1 [x] boot_rescue.gpio-hog
>>> =>
>>>
>>> Hmm.. how can I reproduce your problem?
>>
>> Take a look but IIRC you should have zcu102 around too.
>
> Indeed we have one:
>
> $ remote_power -l | grep zcu102
> katmai3 off r360 off zcu102 off
>
> I have to look, how I can test without breaking the board... Is there
> something like a bootmode switch, so I can restore the board if I broke
> it? (Sorry if dummy question, never worked on the board).
yes - there are easy way how to restore the board. Not sure if you use
jtag, qspi or sd boot mode.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: add gpio-hog support
Hello Michal,
Am 27.05.2019 um 14:31 schrieb Michal Simek:
Hi,
On 27. 05. 19 14:06, Heiko Schocher wrote:
Hello Michal,
Am 27.05.2019 um 13:34 schrieb Michal Simek:
On 27. 05. 19 12:49, Heiko Schocher wrote:
add gpio-hog support. GPIO hogging is a mechanism
providing automatic GPIO request and configuration
as part of the gpio-controller's driver probe function.
for more infos see:
doc/device-tree-bindings/gpio/gpio.txt
Signed-off-by: Heiko Schocher
---
not yet started clean travis build, see result:
https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
Changes in v2:
- move gpio_hog() call from post_probe() to post_bind()
call. Check if current gpio device has gpio-hog
definitions, if so, probe it.
I am using i2c to gpio chip and with v2 this chip is not listed via dm
completely. It means something is wrong for sure.
What do you mean with "this chip is not listed via dm completely" ?
first of all I am using zcu102
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynqmp-zcu102-revA.dts;h=6e22871713139517ad5f7f1d2e659690233bd946;hb=HEAD#l129
There are 2 i2c-gpio chips @20 and @21. @20 has hogs and it is not
listed via dm tree when v2 is applied (v1 is without any issue).
@21 is seen there.
Hmm... look like the same setup as mine ...
It looks like that parent is not probed that's why it is failing.
I use this on the aristainetos board, work currently on rework for DM/DT
usage in U-Boot, dts not yet in u-boot but in linux, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi#n286
and added for u-boot now gpio hog definitons:
{
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
status = "okay";
expander: tca6416@20 {
compatible = "ti,tca6416";
reg = <0x20>;
#gpio-cells = <2>;
gpio-controller;
env_reset {
gpio-hog;
input;
gpios = <6 GPIO_ACTIVE_LOW>;
};
boot_rescue {
gpio-hog;
input;
gpios = <7 GPIO_ACTIVE_LOW>;
nit: there could be also line-name setup.
Ok, I add support for it.
};
};
};
The setup looks the same as I have here.
Yes.
works fine for me ...
=> dm tree
Class Index Probed Driver Name
---
root 0 [ + ] root_driver root_driver
[...]
i2c 2 [ + ] i2c_mxc | | |-- i2c@21a8000
gpio 7 [ + ] pca953x | | | |-- tca6416@20
=> gpio status
[...]
Bank gpio@20_:
gpio@20_6: input: 0 [x] env_reset.gpio-hog
gpio@20_7: input: 1 [x] boot_rescue.gpio-hog
=>
Hmm.. how can I reproduce your problem?
Take a look but IIRC you should have zcu102 around too.
Indeed we have one:
$ remote_power -l | grep zcu102
katmai3 offr360 off zcu102off
I have to look, how I can test without breaking the board... Is there
something like a bootmode switch, so I can restore the board if I broke
it? (Sorry if dummy question, never worked on the board).
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: add gpio-hog support
Hi,
On 27. 05. 19 14:06, Heiko Schocher wrote:
> Hello Michal,
>
> Am 27.05.2019 um 13:34 schrieb Michal Simek:
>> On 27. 05. 19 12:49, Heiko Schocher wrote:
>>> add gpio-hog support. GPIO hogging is a mechanism
>>> providing automatic GPIO request and configuration
>>> as part of the gpio-controller's driver probe function.
>>>
>>> for more infos see:
>>> doc/device-tree-bindings/gpio/gpio.txt
>>>
>>> Signed-off-by: Heiko Schocher
>>>
>>> ---
>>> not yet started clean travis build, see result:
>>> https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
>>>
>>> Changes in v2:
>>> - move gpio_hog() call from post_probe() to post_bind()
>>> call. Check if current gpio device has gpio-hog
>>> definitions, if so, probe it.
>>
>> I am using i2c to gpio chip and with v2 this chip is not listed via dm
>> completely. It means something is wrong for sure.
>
> What do you mean with "this chip is not listed via dm completely" ?
first of all I am using zcu102
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynqmp-zcu102-revA.dts;h=6e22871713139517ad5f7f1d2e659690233bd946;hb=HEAD#l129
There are 2 i2c-gpio chips @20 and @21. @20 has hogs and it is not
listed via dm tree when v2 is applied (v1 is without any issue).
@21 is seen there.
>
>> It looks like that parent is not probed that's why it is failing.
>
> I use this on the aristainetos board, work currently on rework for DM/DT
> usage in U-Boot, dts not yet in u-boot but in linux, see:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi#n286
>
>
> and added for u-boot now gpio hog definitons:
>
> {
> pinctrl-names = "default";
> pinctrl-0 = <_i2c3>;
> status = "okay";
>
> expander: tca6416@20 {
> compatible = "ti,tca6416";
> reg = <0x20>;
> #gpio-cells = <2>;
> gpio-controller;
>
> env_reset {
> gpio-hog;
> input;
> gpios = <6 GPIO_ACTIVE_LOW>;
> };
> boot_rescue {
> gpio-hog;
> input;
> gpios = <7 GPIO_ACTIVE_LOW>;
nit: there could be also line-name setup.
> };
> };
> };
The setup looks the same as I have here.
>
> works fine for me ...
>
> => dm tree
> Class Index Probed Driver Name
> ---
> root 0 [ + ] root_driver root_driver
> [...]
> i2c 2 [ + ] i2c_mxc | | |-- i2c@21a8000
> gpio 7 [ + ] pca953x | | | |-- tca6416@20
>
> => gpio status
> [...]
> Bank gpio@20_:
> gpio@20_6: input: 0 [x] env_reset.gpio-hog
> gpio@20_7: input: 1 [x] boot_rescue.gpio-hog
> =>
>
> Hmm.. how can I reproduce your problem?
Take a look but IIRC you should have zcu102 around too.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
Hi Igor, On Mon, 27 May 2019 08:21:17 +0300 Igor Opaniuk igor.opan...@gmail.com wrote: > Hi everyone, > > I've finally started looking into the cfb_console.c driver and it's > conversion to DM_VIDEO after our initial discussion [1]. This initial discussion was only about DM_VIDEO support for mxsfb driver, we don't need to convert cfb_console.c. With DM_VIDEO cfb_console is obsolete and the basic functionality (text/bitmap output on video frame buffer) is replaced by video console uclass driver, drivers/video/vidconsole-uclass.c. > Unfortunately I've a bit underestimated the amount of effort that > should be done, as mxsfb.c in the Linux mainline obviously pulls the > whole core fb subsystem > (drivers/video/fbdev/core), which can take a while and frankly I doubt > that this is a proper way to do things here. Yes, we should not port the Linux code from drivers/video/fbdev/core, we don't need it in U-Boot. > Taking into account that the deadline for DM_VIDEO conversion is > 2019.07, it's unlikely that we will manage to do the full conversions > this cfb_console driver and all dependent hw specific drivers in a > proper way (where we can provide information about videomodes as > properties in a proper nodes in DT). Speaking only about mxsfb, it shouldn't be too difficult to convert the existing U-Boot driver, even if we decide to extend it to support video mode description in DT. We already have some converted drivers using existing code for reading video modes from DT (grep for ofnode_decode_display_timing() or fdtdec_decode_display_timing()). E.g. see commits 9dc89a053d and d63ec26a49 for atmel_lcdfb.c driver. > Currently the init chain for fb stuff in U-boot (on the other hand, in > the Linux, hw specific driver is probed initially, then they trigger > fb common routines that are needed from `video/fbdev/core`): > stdio_add_devices() -> ./common/stdio.c -> drv_video_init () > (drivers/cfb_console.c) - > video_hw_init (particular hw backend, > which was statically linked at compile time with a proper > video_hw_init() implementation, for example look into mxsfb.c) With DM_VIDEO the framebuffer/videoconsole probing and init will only happen when there is a display user, e.g. when the board starts to output text or bitmap on the video console (stdio_probe_device() for UCLASS_VIDEO ID in common/stdio.c or bmp_display()). > 2 ways of conversion that come to my mind: > 1. Start with simple DM wrappers in cfb_console.c, and introduce dumb > DT nodes so the device at least can be probed. All video configuration > will be stored the same way as before in the U-boot env (for example, > "videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0\0"). > Then, step by step, driver by driver, we can move some properties to > DT and try to sync Linux/U-boot video DT nodes (at least avoid > divergence of tree nodes, so Linux/U-boot video-related DT nodes > conform to each other). Yes, this is kind of dirty workaround, but at > least this something we can start with, and with minimal amount of > intrusive changes. No, please don't use cfb_console at all. > 2. Perform full conversion, where everything works the same way as in > Linux kernel. Initially I thought that it could be the proper way to > go, but taking into account all differences in the implementation of > fb in U-boot/Linux (even the way how the drivers are initialized), I > think we will just end up pulling the whole big piece from the Linux > kernel, that will definitely take a while (especially further support > of this code base, testing/fixing issues etc.). No, we should not pull Linux fbdev code, we already have basic video console code and can use it (probably with some extensions for not yet supported combinations of frame buffer color depth and bitmap color depth, when needed). ... > Drivers, that don't imply CFG_CONSOLE, but are used alongside with > cfb_console.c (kind of particular hw backend driver for fb console): > * mxsfb.c > * mb862xx.c > * sunxi_display.c > * ati_radeon_fb.c > * fsl_dcu_fb.c > * omap3_dss.c > * da8xx-fb.c I think that we will remove CFB_CONSOLE driver when the backend drivers above are ported to use DM_VIDEO code. > Looking forward to your suggestions/recommendations here (and let me > know if I missed something), thanks! I'd suggest to look at the existing already converted code or to inspect in tree commits moving drivers to DM_VIDEO. For 2019.07 release we can add extended mxsfb driver with DM_VIDEO support still using timing info from videomode environment. When you want to extend the mxsfb driver to read the display timings from DT, see e.g. 6d9a98c583 and f182209190. Also make sure to add "u-boot,dm-pre-reloc" properties in the device tree node for lcdif controller and in its parent node. Otherwise the allocation of frame buffer memory in video uclass driver won't work. Thanks, -- Anatolij ___ U-Boot mailing
Re: [U-Boot] [PATCH] arm, imx, Makefile: support CONFIG_MULTI_DTB_FIT
Hi Heiko, On Mon, May 27, 2019 at 3:08 AM Heiko Schocher wrote: > > in case CONFIG_MULTI_DTB_FIT is active, use > u-boot-fit-dtb.bin. We currently use CONFIG_MULTI_DTB_FIT on mx6sabresd target. Could you please expand the commit log explaining why we need to introduce u-boot-fit-dtb.bin? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: add gpio-hog support
Hello Michal,
Am 27.05.2019 um 13:34 schrieb Michal Simek:
On 27. 05. 19 12:49, Heiko Schocher wrote:
add gpio-hog support. GPIO hogging is a mechanism
providing automatic GPIO request and configuration
as part of the gpio-controller's driver probe function.
for more infos see:
doc/device-tree-bindings/gpio/gpio.txt
Signed-off-by: Heiko Schocher
---
not yet started clean travis build, see result:
https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
Changes in v2:
- move gpio_hog() call from post_probe() to post_bind()
call. Check if current gpio device has gpio-hog
definitions, if so, probe it.
I am using i2c to gpio chip and with v2 this chip is not listed via dm
completely. It means something is wrong for sure.
What do you mean with "this chip is not listed via dm completely" ?
It looks like that parent is not probed that's why it is failing.
I use this on the aristainetos board, work currently on rework for DM/DT
usage in U-Boot, dts not yet in u-boot but in linux, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi#n286
and added for u-boot now gpio hog definitons:
{
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
status = "okay";
expander: tca6416@20 {
compatible = "ti,tca6416";
reg = <0x20>;
#gpio-cells = <2>;
gpio-controller;
env_reset {
gpio-hog;
input;
gpios = <6 GPIO_ACTIVE_LOW>;
};
boot_rescue {
gpio-hog;
input;
gpios = <7 GPIO_ACTIVE_LOW>;
};
};
};
works fine for me ...
=> dm tree
Class Index Probed DriverName
---
root 0 [ + ] root_driver root_driver
[...]
i2c 2 [ + ] i2c_mxc | | |-- i2c@21a8000
gpio 7 [ + ] pca953x | | | |-- tca6416@20
=> gpio status
[...]
Bank gpio@20_:
gpio@20_6: input: 0 [x] env_reset.gpio-hog
gpio@20_7: input: 1 [x] boot_rescue.gpio-hog
=>
Hmm.. how can I reproduce your problem?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell/master
Hi Tom, please pull the following Marvell related fix: - defconfig updates to remove the DM-move build warnings for helios4 and controlcenterdc (Mario & Stefan) Thanks, Stefan The following changes since commit 344a0e4367d0820b8eb2ea4a90132433e038095f: configs: Resync with savedefconfig (2019-05-26 14:45:25 -0400) are available in the Git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to 0a60da960fead40a73e306ac5e6b5e399329a5d1: arm: mvebu: controlcenterdc: Update config (2019-05-27 13:31:04 +0200) Mario Six (1): arm: mvebu: controlcenterdc: Update config Stefan Roese (1): arm: mvebu: helios4: Enable CONFIG_BLK and CONFIG_DM_MMC configs/controlcenterdc_defconfig | 2 ++ configs/helios4_defconfig | 1 + 2 files changed, 3 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: add gpio-hog support
On 27. 05. 19 12:49, Heiko Schocher wrote: > add gpio-hog support. GPIO hogging is a mechanism > providing automatic GPIO request and configuration > as part of the gpio-controller's driver probe function. > > for more infos see: > doc/device-tree-bindings/gpio/gpio.txt > > Signed-off-by: Heiko Schocher > > --- > not yet started clean travis build, see result: > https://travis-ci.org/hsdenx/u-boot-test/builds/537732421 > > Changes in v2: > - move gpio_hog() call from post_probe() to post_bind() > call. Check if current gpio device has gpio-hog > definitions, if so, probe it. I am using i2c to gpio chip and with v2 this chip is not listed via dm completely. It means something is wrong for sure. It looks like that parent is not probed that's why it is failing. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/27/19 11:49 AM, Peng Fan wrote: > Hi Marek, Lukasz, > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> Hi Marek, >> >> On 2019/5/22 19:41, Marek Vasut wrote: >>> Caution: EXT Email >>> >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: >>> [...] >> By using above approach we do have the NXP's "container" >> format only seen in the SPL (which is OK, as for example >> Samsung does similar thing with FBL/BL1). When SPL is "trused" >> we may use available facilities. > > The issue to me is that sc_seco_authenticate could not take a > FIT image as input. Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or Linux crypro engine driver? >>> >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know >>> about Linux crypto driver. >> >> Maybe it would be worth to check how Linux handle this? Maybe it >> would shed some more light on it? > > I am not familiar with that, so might be stupid question below. > Does it really matter? I would check it just out of curiosity. >>> >>> Yes, it matters, because there should be such API. How would Linux >>> authenticate e.g. userspace binaries if there wasn't one, surely not >>> by wrapping every single object into the custom vendor-specific container ? >>> And if there is one, you can use it to authenticate raw binaries from >>> U-Boot SPL too, e.g. fitImage blobs with an associated signature. >>> >> >> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called >> SRK is a array of public key hash which is dedicated for AHAB. It is not a >> real >> key. The real public key is in container. >> AHAB will check the public key with the on-chip SRK before using it to >> authenticate the image. >> Seco which contains the crypto engine on imx8 does not allow to use the SRK >> by user. No such API exported. >> And the fuse of SRK is locked, can't be read directly. >> >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM >> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot >> authenticatse kernel. We just follow this same way on imx8, the difference is >> imx8 needs container format for signed image. We prefer directly loading >> container image than fit image. >> If we pack fit image into container, obviously this will cause one more copy. >> As a boot loader, isn't it better to have more image format supported? If the functionality of the new image format is a subset of already present image format, then no, that's called a duplication. >> We >> don't force to use container, just set it as default. Users still can choose >> fit or >> raw image. They can. however they cannot authenticate the fitImage because the firmware doesn't provide the necessary API for that ? > > Do you have more comment? How could Linux use this iMX8 chain of trust stuff to authenticate e.g. userspace binaries ? It's the same thing as authenticating blob in a fitImage. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 6/7] arm: mvebu: turris_omnia: call pci_init from board init code
On 24.05.19 14:57, Marek Behún wrote: We always want to enumerate PCIe devices, because withouth this they won't work in Linux. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan BTW: There should be no any such dependencies, that the bootloader has already done some initializations on some subsystems. Linux should be able to function correctly on all interfaces without any such pre- configurations. So you might want to look into the Linux drivers here to find the root cause for this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 7/7] arm: mvebu: turris_omnia: fix rescue mode bootcmd bootargs setting
On 24.05.19 14:57, Marek Behún wrote: Rescue mode bootcmd currently only appends the "omniarescue" parameter to the bootargs variable. We do not want the user to be able to change rescue mode bootargs. Therefore change this so that bootcmd sets the bootargs variable in an absolute way (adding console device information and the omniarescue paramterer). Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 5/7] arm: mvebu: turris_omnia: prefer SCSI booting before USB
On 24.05.19 14:57, Marek Behún wrote: If SCSI and USB boot options are both available, try to boot from SCSI first. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 4/7] arm: mvebu: turris_omnia: remove unneeded macro from board config
On 24.05.19 14:57, Marek Behún wrote: This is not needed here since Omnia is using DM_PCI now. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 3/7] arm: mvebu: turris_omnia: change environment address in SPI flash
On 24.05.19 14:57, Marek Behún wrote: The U-Boot partition is 1 MiB and environment is 64 KiB. It does not make sense to have environment at 0xc when it could be at 0xf and we can have more space for U-Boot binary. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 1/7] arm: mvebu: turris_omnia: set default ethernet adapter
On 24.05.19 14:57, Marek Behún wrote: Set default value for the ethact variable to the WAN port. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot-marvell 2/7] arm: mvebu: turris_omnia: fix adapters MAC addresses
On 24.05.19 14:57, Marek Behún wrote: The board code reads MAC addresses from the ATSHA204A cryptochip. For compatibility reasons the ethernet adapters on this SOC are not enumerated in register address order. But when Omnia was first manufactured this was done differently. Change setting of MAC addresses to conform to the description on the stickers sticked on actual Omnias. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: add gpio-hog support
On 27. 05. 19 11:36, Heiko Schocher wrote:
> Hello Michal,
>
> Am 27.05.2019 um 09:13 schrieb Michal Simek:
>> On 27. 05. 19 8:30, Heiko Schocher wrote:
>>> add gpio-hog support. GPIO hogging is a mechanism
>>> providing automatic GPIO request and configuration
>>> as part of the gpio-controller's driver probe function.
>>>
>>> for more infos see:
>>> doc/device-tree-bindings/gpio/gpio.txt
>>>
>>> Signed-off-by: Heiko Schocher
>>
>> I have tested it on zcu102 where I use gpio hogs for gt muxes.
>
> Thanks!
>
>> gpio hogs are handled and setup only when gpio controller is probed.
>
> Yes, with my current approach ... If you need a gpio-hog in a gpio
> device, wich is not used, you can add in board code:
>
> gpio_hog_lookup_name("name_of_the_gpio_hog");
>
> and gpio driver (and gpio hogs) get probed ... but not really nice...
>
>> Do we have a way how to say that controllers with gpio hogs should be
>> probed automatically?
>
> No yet, but I am open for suggestions ;-)
>
>> Right now you are calling it in post_probe which make sense but on the
>> other hand if you find gpio hog in bind you should probe the whole
>> driver without asking for request.
>
> Yes, I also thought about this approach, but the problem is in
>
> static int gpio_hog(struct udevice *dev)
> {
> ofnode node;
> struct gpio_dev_priv *uc_priv = NULL;
>
> uc_priv = dev_get_uclass_priv(dev);
> if (!uc_priv) {
> printf("%s: missing private data.\n", __func__);
> return -EINVAL;
> }
>
> uc_priv is not valid @bind stage ...
>
> But I can think of a function which scans all gpio nodes for
> gpio hog subnodes, and call device_probe() ?
>
> But from where should this function be called?
The question is if this patch is reading that gpio-hogs at right stage.
Right now you are decoding them in post_probe. Normally getting
information from DT is done in ofdata_to_platdata.
It is question if this approach is also working for non DT case.
Anyway let's say you setup a flag in ofdata_to_platdata that there are
gpio hogs and then you know if you should probe that device or not.
btw: didn't send this before you v2 but should be still valid.
Let me test v2 now.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] At present the GEM ethernet on SiFive Unleashed board can only work
Hi Joe, On Wed, May 22, 2019 at 3:10 PM Bin Meng wrote: > > in 1000 Mbps mode. With a 10/100 Mbps connection it just fails to do > any network communication. > > This adds a new GEMGXL clock driver to adjust the clock settings per > the connection speed so that 10/100 Mbps works. > Lukas has reviewed and tested this series (thanks Lukas!) Would you please apply this series for v2019.07? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] gpio: add gpio-hog support
add gpio-hog support. GPIO hogging is a mechanism
providing automatic GPIO request and configuration
as part of the gpio-controller's driver probe function.
for more infos see:
doc/device-tree-bindings/gpio/gpio.txt
Signed-off-by: Heiko Schocher
---
not yet started clean travis build, see result:
https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
Changes in v2:
- move gpio_hog() call from post_probe() to post_bind()
call. Check if current gpio device has gpio-hog
definitions, if so, probe it.
doc/device-tree-bindings/gpio/gpio.txt | 52
drivers/gpio/Kconfig | 10 ++
drivers/gpio/gpio-uclass.c | 162 +++--
include/asm-generic/gpio.h | 24
4 files changed, 236 insertions(+), 12 deletions(-)
diff --git a/doc/device-tree-bindings/gpio/gpio.txt
b/doc/device-tree-bindings/gpio/gpio.txt
index f7a158d858..54f5ff6c7f 100644
--- a/doc/device-tree-bindings/gpio/gpio.txt
+++ b/doc/device-tree-bindings/gpio/gpio.txt
@@ -210,3 +210,55 @@ Example 2:
Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
are named "foo" and "bar".
+
+3) GPIO hog definitions
+---
+
+The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
+providing automatic GPIO request and configuration as part of the
+gpio-controller's driver probe function.
+
+Each GPIO hog definition is represented as a child node of the GPIO controller.
+Required properties:
+- gpio-hog: A property specifying that this child node represents a GPIO hog.
+- gpios: Store the GPIO information (id, flags) for the GPIO to
+ affect.
+
+ ! Not yet support more than one gpio !
+
+Only one of the following properties scanned in the order shown below.
+- input: A property specifying to set the GPIO direction as input.
+- output-low A property specifying to set the GPIO direction as output with
+ the value low.
+- output-high A property specifying to set the GPIO direction as output with
+ the value high.
+
+Example:
+
+tca6416@20 {
+compatible = "ti,tca6416";
+reg = <0x20>;
+#gpio-cells = <2>;
+gpio-controller;
+
+env_reset {
+gpio-hog;
+input;
+gpios = <6 GPIO_ACTIVE_LOW>;
+};
+boot_rescue {
+gpio-hog;
+input;
+gpios = <7 GPIO_ACTIVE_LOW>;
+};
+};
+
+For the above Example you can than access the gpio in your boardcode
+with:
+
+desc = gpio_hog_lookup_name("boot_rescue.gpio-hog");
+if (desc) {
+if (dm_gpio_get_value(desc))
+printf("\nBooting into Rescue System\n");
+ else
+ printf("\nBoot normal\n");
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index e36a8abc42..fa1c99700f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -14,6 +14,16 @@ config DM_GPIO
particular GPIOs that they provide. The uclass interface
is defined in include/asm-generic/gpio.h.
+config DM_GPIO_HOG
+ bool "Enable GPIO hog support"
+ depends on DM_GPIO
+ default n
+ help
+ Enable gpio hog support
+ The GPIO chip may contain GPIO hog definitions. GPIO hogging
+ is a mechanism providing automatic GPIO request and config-
+ uration as part of the gpio-controller's driver probe function.
+
config ALTERA_PIO
bool "Altera PIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index da5e9ba6e5..4a21554d45 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,17 @@
DECLARE_GLOBAL_DATA_PTR;
+struct gpio_priv_one {
+ struct list_head list;
+ char *name;
+ struct gpio_desc gpiod;
+};
+
+#if defined(CONFIG_DM_GPIO_HOG)
+static struct list_head hogs;
+static int probed_hogs;
+#endif
+
/**
* gpio_to_device() - Convert global GPIO number to device, number
*
@@ -141,6 +153,112 @@ static int gpio_find_and_xlate(struct gpio_desc *desc,
return gpio_xlate_offs_flags(desc->dev, desc, args);
}
+#if defined(CONFIG_DM_GPIO_HOG)
+struct gpio_desc *gpio_hog_lookup_name(const char *name)
+{
+ struct list_head *entry;
+ struct gpio_priv_one *cur;
+
+ list_for_each(entry, ) {
+ cur = list_entry(entry, struct gpio_priv_one, list);
+ if (strcmp(cur->name, name) == 0)
+ return >gpiod;
+ }
+
+ return NULL;
+}
+
+static int gpio_hog(struct udevice *dev)
+{
+ ofnode
Re: [U-Boot] [PATCH v2] cmd: env: print a message when setting UEFI variable failed
On 5/27/19 2:46 AM, AKASHI Takahiro wrote:
On Fri, May 24, 2019 at 08:38:41PM +0200, Heinrich Schuchardt wrote:
On 5/24/19 8:59 AM, AKASHI Takahiro wrote:
Error message will alert a user that setting/deleting a variable failed.
Signed-off-by: AKASHI Takahiro
---
Changes in v2 (May 24, 2019)
* change a message to "Out of memory"
* add more error messages
---
cmd/nvedit_efi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index 2805e8182b41..88d6ca1cd7f2 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -373,6 +373,8 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
for ( ; argc > 0; argc--, argv++)
if (append_value(, , argv[0]) < 0) {
+ printf("## Failed to process an argument, %s\n",
+ argv[0]);
ret = CMD_RET_FAILURE;
goto out;
}
@@ -381,6 +383,7 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
len = utf8_utf16_strnlen(var_name, strlen(var_name));
var_name16 = malloc((len + 1) * 2);
if (!var_name16) {
+ printf("## Out of memory (%ld bytes)\n", (len + 1) * 2);
cmd/nvedit_efi.c: In function ‘do_env_set_efi’:
cmd/nvedit_efi.c:386:31: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’}
[-Wformat=]
printf("## Out of memory (%ld bytes)\n", (len + 1) * 2);
~~^~
%d
If you want to print the number of bytes use %zu. But why should the
user care if it is 10 bytes or 100 bytes that could not be assigned? If
he is out of memory here anyway the system is messed up.
Can you please clarify what you want me to do?
Otherwise, I cannot submit a next version.
I would suggest to leave the size information away.
ret = CMD_RET_FAILURE;
goto out;
}
@@ -392,7 +395,13 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, value));
- ret = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ if (ret == EFI_SUCCESS) {
+ ret = CMD_RET_SUCCESS;
+ } else {
+ printf("## Failed to set EFI variable (%ld)\n",
ret has type size_t so this has to %zu.
Think of a non-developer user who bought a device with pre-installedö
U-Boot. What would he do with the error code?
Ditto.
I would suggest to leave the return code away.
Best regards
Heinrich
Thanks,
-Takahiro Akashi
Best regards
Heinrich
+ ret & ~EFI_ERROR_MASK);
+ ret = CMD_RET_FAILURE;
+ }
out:
free(value);
free(var_name16);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, Lukasz, > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's "container" > format only seen in the SPL (which is OK, as for example > Samsung does similar thing with FBL/BL1). When SPL is "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not take a > >>> FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, U-Boot > >> proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not know > > about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? Maybe it > would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would Linux > > authenticate e.g. userspace binaries if there wasn't one, surely not > > by wrapping every single object into the custom vendor-specific container ? > > And if there is one, you can use it to authenticate raw binaries from > > U-Boot SPL too, e.g. fitImage blobs with an associated signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called > SRK is a array of public key hash which is dedicated for AHAB. It is not a > real > key. The real public key is in container. > AHAB will check the public key with the on-chip SRK before using it to > authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to use the SRK > by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM > HAB to implement the trust chain, like SPL authenticates u-boot, u-boot > authenticatse kernel. We just follow this same way on imx8, the difference is > imx8 needs container format for signed image. We prefer directly loading > container image than fit image. > If we pack fit image into container, obviously this will cause one more copy. > As a boot loader, isn't it better to have more image format supported? We > don't force to use container, just set it as default. Users still can choose > fit or > raw image. Do you have more comment? Thanks, Peng. > > > > [...] > > > > -- > > Best regards, > > Marek Vasut > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] omapl138_lcdk_defconfig: don't build support for SPI
Hello Bartosz, Am 27.05.2019 um 10:57 schrieb Bartosz Golaszewski: From: Bartosz Golaszewski The following warning is emited when building u-boot for da850-lcdk: = WARNING == This board does not use CONFIG_DM_SPI. Please update the board before v2019.04 for no dm conversion and v2019.07 for partially dm converted drivers. Failure to update can lead to driver/board removal See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_SPI_FLASH. Please update the board to use CONFIG_SPI_FLASH before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. While we could fix it by selecting CONFIG_DM_SPI, there's no need to build it at all as SPI is disabled on da850-lcdk. Remove all unneeded options from the defconfig. Signed-off-by: Bartosz Golaszewski --- configs/omapl138_lcdk_defconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) Acked-by: Heiko Schocher Thanks! bye, Heiko -- -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] i2c: remove i2c driver-model compatibility layer
Hello Bartosz, Am 27.05.2019 um 10:57 schrieb Bartosz Golaszewski: From: Bartosz Golaszewski There are no more users of the compatibility layer for i2c. Remove the driver and all references to it. Signed-off-by: Bartosz Golaszewski --- Makefile| 7 -- drivers/i2c/Kconfig | 13 +--- drivers/i2c/Makefile| 1 - drivers/i2c/i2c-uclass-compat.c | 128 include/_exports.h | 3 +- include/exports.h | 3 +- include/i2c.h | 80 7 files changed, 3 insertions(+), 232 deletions(-) delete mode 100644 drivers/i2c/i2c-uclass-compat.c Acked-by: Heiko Schocher Thanks! bye, Heiko -- -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sandbox: remove CONFIG_DM_I2C_COMPAT from defconfigs
Hello Bartosz, Am 27.05.2019 um 10:57 schrieb Bartosz Golaszewski: From: Bartosz Golaszewski There are no more "real" users of CONFIG_DM_I2C_COMPAT and we'll soon remove it altogether. Stop building it in sandbox mode. Signed-off-by: Bartosz Golaszewski --- Makefile | 2 +- configs/sandbox64_defconfig| 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_noblk_defconfig| 1 - configs/sandbox_spl_defconfig | 1 - configs/tools-only_defconfig | 1 - 7 files changed, 1 insertion(+), 7 deletions(-) Acked-by: Heiko Schocher Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] davinci: remove CONFIG_DM_I2C_COMPAT from defconfigs
Hello Bartosz, Am 27.05.2019 um 10:57 schrieb Bartosz Golaszewski: From: Bartosz Golaszewski This option is no longer used on any davinci board but still selected in defconfigs which causes the following warning: = WARNING == This board uses CONFIG_DM_I2C_COMPAT. Please remove (possibly in a subsequent patch in your series) before sending patches to the mailing list. Remove all references to CONFIG_DM_I2C_COMPAT from davinci. Signed-off-by: Bartosz Golaszewski --- configs/da850_am18xxevm_defconfig | 1 - configs/omapl138_lcdk_defconfig | 1 - include/configs/am3517_evm.h | 1 - include/configs/da850evm.h| 8 include/configs/omapl138_lcdk.h | 8 5 files changed, 19 deletions(-) Acked-by: Heiko Schocher Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: add gpio-hog support
Hello Michal,
Am 27.05.2019 um 09:13 schrieb Michal Simek:
On 27. 05. 19 8:30, Heiko Schocher wrote:
add gpio-hog support. GPIO hogging is a mechanism
providing automatic GPIO request and configuration
as part of the gpio-controller's driver probe function.
for more infos see:
doc/device-tree-bindings/gpio/gpio.txt
Signed-off-by: Heiko Schocher
I have tested it on zcu102 where I use gpio hogs for gt muxes.
Thanks!
gpio hogs are handled and setup only when gpio controller is probed.
Yes, with my current approach ... If you need a gpio-hog in a gpio
device, wich is not used, you can add in board code:
gpio_hog_lookup_name("name_of_the_gpio_hog");
and gpio driver (and gpio hogs) get probed ... but not really nice...
Do we have a way how to say that controllers with gpio hogs should be
probed automatically?
No yet, but I am open for suggestions ;-)
Right now you are calling it in post_probe which make sense but on the
other hand if you find gpio hog in bind you should probe the whole
driver without asking for request.
Yes, I also thought about this approach, but the problem is in
static int gpio_hog(struct udevice *dev)
{
ofnode node;
struct gpio_dev_priv *uc_priv = NULL;
uc_priv = dev_get_uclass_priv(dev);
if (!uc_priv) {
printf("%s: missing private data.\n", __func__);
return -EINVAL;
}
uc_priv is not valid @bind stage ...
But I can think of a function which scans all gpio nodes for
gpio hog subnodes, and call device_probe() ?
But from where should this function be called?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB
Hi, On Mon, 2019-05-27 at 00:50 +0100, André Przywara wrote: > On 17/04/2019 12:28, Jagan Teki wrote: > > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski > > wrote: > > Hi, > > > > Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit : > > > > On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski > > > > wrote: > > > > > Recent Allwinner platforms (starting with the H3) only use the MUSB > > > > > controller for peripheral mode and use HCI for host mode. As a result, > > > > > extra steps need to be taken to properly route USB signals to one or > > > > > the other. More precisely, the following is required: > > > > > * Routing the pins to either HCI/MUSB (controlled by PHY); > > > > > * Enabling USB PHY passby in HCI mode (controlled by PMU). > > > > > > > > > > The current code will enable passby for each PHY and reroute PHY0 to > > > > > MUSB, which is inconsistent and results in broken USB peripheral > > > > > support. > > > > > > > > > > Passby on PHY0 must only be enabled when we want to use HCI. Since > > > > > host/device mode detection is not available from the PHY code and > > > > > because U-Boot does not support changing the mode dynamically anyway, > > > > > we can just mux the controller to MUSB if it is enabled and mux it to > > > > > HCI otherwise. > > > > > > > > > > This fixes USB peripheral support for platforms with PHY0 dual-route, > > > > > especially H3/H5 and V3s. > > > > > > > > > > Signed-off-by: Paul Kocialkowski > > > > > --- > > > > > drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- > > > > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > > > > > b/drivers/phy/allwinner/phy-sun4i-usb.c > > > > > index f206fa3f5d48..4f1c7e519d71 100644 > > > > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > > > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > > > > @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy) > > > > > data->cfg->disc_thresh, > > > > > PHY_DISCON_TH_LEN); > > > > > } > > > > > > > > > > +#ifdef CONFIG_USB_MUSB_SUNXI > > > > > + /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB > > > > > */ > > > > > + if (usb_phy->id != 0) > > > > > + sun4i_usb_phy_passby(phy, true); > > > > > + > > > > > + /* Route PHY0 to MUSB to allow USB gadget */ > > > > > + if (data->cfg->phy0_dual_route) > > > > > + sun4i_usb_phy0_reroute(data, true); > > > > > +#else > > > > > sun4i_usb_phy_passby(phy, true); > > > > > > > > > > - sun4i_usb_phy0_reroute(data, true); > > > > > + /* Route PHY0 to HCI to allow USB host */ > > > > > + if (data->cfg->phy0_dual_route) > > > > > + sun4i_usb_phy0_reroute(data, false); > > > > > +#endif > > > > > > > > I think we can manage this route and passby dynamically by detecting > > > > id since we have dr_mode verify the MUSB host or peripheral via > > > > usb_get_dr_mode, any chance to try that way? > > > > > > Oh, I didn't know that U-Boot has support for usb_get_dr_mode these > > > days. Thanks! > > > > > > So far, the sunxi port has been using Kconfig to distinguish between > > > host/device (unless I'm mistaken?) so I feel like this should be a > > > separate follow-up patch to convert the sunxi MUSB glue + PHY to > > > detecting dr_mode using usb_get_dr_mode. This feels like a significant > > > rework, too. > > > > Yes. > > > > > Also, how should we handle the OTG case? I'm not sure we can support > > > having both musb host and gadget built-in at this point. But that would > > > certainly be welcome as part of the rework, too. > > > > > > What do you think? > > > > You mean handling dr_mode at runtime. > > > > If yes, It is bit new where we can register the musb as UCLASS_MISC > > wrapper and decide to bind driver for host and peripheral by decoding > > dr_mode. and indeed host should register with UCLASS_USB and > > peripheral with UCLASS_USB_GADGET_GENERIC. > > > > I tried this wrapper before, not placed in-between because of other > > work but TI musb has similar code to manage this > > drivers/usb/musb-new/ti-musb.c > > Before we go wild with any fancy rework, can we possibly take this patch > as it? As I realised, this is basically a better version of the patch I > sent two weeks ago [1]. I tried Paul's patch back then, but was missing > the phys property in the DT, which I addressed in patch 2/2. I fully agree, and believe the rework should be a separate subsequent series. > So I would appreciate if we can take this patch, as it solves a real > problem (upper USB port not working) on many Pine64 boards (given the > small DT change is in place). And on those boards the OTG functionality > is not really feasible anyway, as VBUS is either permanently enabled or > at least tied to the other host port's supply, so we can't turn it off > for peripheral mode. It makes USB OTG
[U-Boot] [PATCH 4/4] omapl138_lcdk_defconfig: don't build support for SPI
From: Bartosz Golaszewski The following warning is emited when building u-boot for da850-lcdk: = WARNING == This board does not use CONFIG_DM_SPI. Please update the board before v2019.04 for no dm conversion and v2019.07 for partially dm converted drivers. Failure to update can lead to driver/board removal See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_SPI_FLASH. Please update the board to use CONFIG_SPI_FLASH before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. While we could fix it by selecting CONFIG_DM_SPI, there's no need to build it at all as SPI is disabled on da850-lcdk. Remove all unneeded options from the defconfig. Signed-off-by: Bartosz Golaszewski --- configs/omapl138_lcdk_defconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig index b03d8160af..1c232b47f3 100644 --- a/configs/omapl138_lcdk_defconfig +++ b/configs/omapl138_lcdk_defconfig @@ -27,6 +27,7 @@ CONFIG_CRC32_VERIFY=y # CONFIG_CMD_FLASH is not set # CONFIG_CMD_GPIO is not set CONFIG_CMD_NAND=y +# CONFIG_CMD_SPI is not set # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_MTDPARTS=y CONFIG_CMD_DIAG=y @@ -45,13 +46,8 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y CONFIG_SYS_NAND_U_BOOT_OFFS=0x28000 CONFIG_SPL_NAND_SIMPLE=y -CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_SPEED=3000 -CONFIG_SPI_FLASH_STMICRO=y -CONFIG_SPI_FLASH_WINBOND=y CONFIG_MII=y CONFIG_DRIVER_TI_EMAC=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y -CONFIG_SPI=y -CONFIG_DAVINCI_SPI=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] i2c: remove i2c driver-model compatibility layer
From: Bartosz Golaszewski
There are no more users of the compatibility layer for i2c. Remove the
driver and all references to it.
Signed-off-by: Bartosz Golaszewski
---
Makefile| 7 --
drivers/i2c/Kconfig | 13 +---
drivers/i2c/Makefile| 1 -
drivers/i2c/i2c-uclass-compat.c | 128
include/_exports.h | 3 +-
include/exports.h | 3 +-
include/i2c.h | 80
7 files changed, 3 insertions(+), 232 deletions(-)
delete mode 100644 drivers/i2c/i2c-uclass-compat.c
diff --git a/Makefile b/Makefile
index ff38b5d19f..bc5774d975 100644
--- a/Makefile
+++ b/Makefile
@@ -918,13 +918,6 @@ cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
$(srctree)/scripts/config_whitelist.txt $(srctree)
all: $(ALL-y)
-ifeq ($(CONFIG_DM_I2C_COMPAT),y)
- @echo >&2 "= WARNING =="
- @echo >&2 "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
- @echo >&2 "(possibly in a subsequent patch in your series)"
- @echo >&2 "before sending patches to the mailing list."
- @echo >&2 ""
-endif
ifeq ($(CONFIG_MMC),y)
ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy)
@echo >&2 "= WARNING =="
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 095a9bc6a4..9c26471f94 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -12,18 +12,7 @@ config DM_I2C
write and speed, is implemented with the bus drivers operations,
which provide methods for bus setting and data transfer. Each chip
device (bus child) info is kept as parent platdata. The interface
- is defined in include/i2c.h. When i2c bus driver supports the i2c
- uclass, but the device drivers not, then DM_I2C_COMPAT config can
- be used as compatibility layer.
-
-config DM_I2C_COMPAT
- bool "Enable I2C compatibility layer"
- depends on DM
- help
- Enable old-style I2C functions for compatibility with existing code.
- This option can be enabled as a temporary measure to avoid needing
- to convert all code for a board in a single commit. It should not
- be enabled for any board in an official release.
+ is defined in include/i2c.h.
config I2C_CROS_EC_TUNNEL
tristate "Chrome OS EC tunnel I2C bus"
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index dc40055efb..c2f75d8755 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -3,7 +3,6 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DM_I2C) += i2c-uclass.o
-obj-$(CONFIG_DM_I2C_COMPAT) += i2c-uclass-compat.o
obj-$(CONFIG_DM_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
diff --git a/drivers/i2c/i2c-uclass-compat.c b/drivers/i2c/i2c-uclass-compat.c
deleted file mode 100644
index b3ade88113..00
--- a/drivers/i2c/i2c-uclass-compat.c
+++ /dev/null
@@ -1,128 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2014 Google, Inc
- */
-
-#include
-#include
-#include
-#include
-
-static int cur_busnum __attribute__((section(".data")));
-
-static int i2c_compat_get_device(uint chip_addr, int alen,
-struct udevice **devp)
-{
- struct dm_i2c_chip *chip;
- int ret;
-
- ret = i2c_get_chip_for_busnum(cur_busnum, chip_addr, alen, devp);
- if (ret)
- return ret;
- chip = dev_get_parent_platdata(*devp);
- if (chip->offset_len != alen) {
- printf("I2C chip %x: requested alen %d does not match chip
offset_len %d\n",
- chip_addr, alen, chip->offset_len);
- return -EADDRNOTAVAIL;
- }
-
- return 0;
-}
-
-int i2c_probe(uint8_t chip_addr)
-{
- struct udevice *bus, *dev;
- int ret;
-
- ret = uclass_get_device_by_seq(UCLASS_I2C, cur_busnum, );
- if (ret) {
- debug("Cannot find I2C bus %d: err=%d\n", cur_busnum, ret);
- return ret;
- }
-
- if (!bus)
- return -ENOENT;
-
- return dm_i2c_probe(bus, chip_addr, 0, );
-}
-
-int i2c_read(uint8_t chip_addr, unsigned int addr, int alen, uint8_t *buffer,
-int len)
-{
- struct udevice *dev;
- int ret;
-
- ret = i2c_compat_get_device(chip_addr, alen, );
- if (ret)
- return ret;
-
- return dm_i2c_read(dev, addr, buffer, len);
-}
-
-int i2c_write(uint8_t chip_addr, unsigned int addr, int alen, uint8_t *buffer,
- int len)
-{
- struct udevice *dev;
- int ret;
-
- ret = i2c_compat_get_device(chip_addr, alen, );
- if (ret)
-
[U-Boot] [PATCH 2/4] sandbox: remove CONFIG_DM_I2C_COMPAT from defconfigs
From: Bartosz Golaszewski There are no more "real" users of CONFIG_DM_I2C_COMPAT and we'll soon remove it altogether. Stop building it in sandbox mode. Signed-off-by: Bartosz Golaszewski --- Makefile | 2 +- configs/sandbox64_defconfig| 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_noblk_defconfig| 1 - configs/sandbox_spl_defconfig | 1 - configs/tools-only_defconfig | 1 - 7 files changed, 1 insertion(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 059978bfe6..ff38b5d19f 100644 --- a/Makefile +++ b/Makefile @@ -918,7 +918,7 @@ cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \ $(srctree)/scripts/config_whitelist.txt $(srctree) all: $(ALL-y) -ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) +ifeq ($(CONFIG_DM_I2C_COMPAT),y) @echo >&2 "= WARNING ==" @echo >&2 "This board uses CONFIG_DM_I2C_COMPAT. Please remove" @echo >&2 "(possibly in a subsequent patch in your series)" diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index 1bc3bd3801..85226f5009 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -89,7 +89,6 @@ CONFIG_BOARD=y CONFIG_BOARD_SANDBOX=y CONFIG_PM8916_GPIO=y CONFIG_SANDBOX_GPIO=y -CONFIG_DM_I2C_COMPAT=y CONFIG_I2C_CROS_EC_TUNNEL=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_DM_I2C_GPIO=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 4877f1099a..9bc567b672 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -104,7 +104,6 @@ CONFIG_PM8916_GPIO=y CONFIG_SANDBOX_GPIO=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_SANDBOX=y -CONFIG_DM_I2C_COMPAT=y CONFIG_I2C_CROS_EC_TUNNEL=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_DM_I2C_GPIO=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 40593ee3a1..f78d45ad1c 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -74,7 +74,6 @@ CONFIG_BOARD=y CONFIG_BOARD_SANDBOX=y CONFIG_PM8916_GPIO=y CONFIG_SANDBOX_GPIO=y -CONFIG_DM_I2C_COMPAT=y CONFIG_I2C_CROS_EC_TUNNEL=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_DM_I2C_GPIO=y diff --git a/configs/sandbox_noblk_defconfig b/configs/sandbox_noblk_defconfig index 24ff4b41da..653341699b 100644 --- a/configs/sandbox_noblk_defconfig +++ b/configs/sandbox_noblk_defconfig @@ -81,7 +81,6 @@ CONFIG_BOARD=y CONFIG_BOARD_SANDBOX=y CONFIG_PM8916_GPIO=y CONFIG_SANDBOX_GPIO=y -CONFIG_DM_I2C_COMPAT=y CONFIG_I2C_CROS_EC_TUNNEL=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_DM_I2C_GPIO=y diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig index bebd78d55b..6b8b923dda 100644 --- a/configs/sandbox_spl_defconfig +++ b/configs/sandbox_spl_defconfig @@ -95,7 +95,6 @@ CONFIG_BOARD=y CONFIG_BOARD_SANDBOX=y CONFIG_PM8916_GPIO=y CONFIG_SANDBOX_GPIO=y -CONFIG_DM_I2C_COMPAT=y CONFIG_I2C_CROS_EC_TUNNEL=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_DM_I2C_GPIO=y diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig index fb06076785..e3b3018158 100644 --- a/configs/tools-only_defconfig +++ b/configs/tools-only_defconfig @@ -11,7 +11,6 @@ CONFIG_OF_HOSTFILE=y CONFIG_DEFAULT_DEVICE_TREE="sandbox" # CONFIG_UDP_FUNCTION_FASTBOOT is not set CONFIG_SANDBOX_GPIO=y -CONFIG_DM_I2C_COMPAT=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCI_SANDBOX=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] davinci: remove CONFIG_DM_I2C_COMPAT from defconfigs
From: Bartosz Golaszewski This option is no longer used on any davinci board but still selected in defconfigs which causes the following warning: = WARNING == This board uses CONFIG_DM_I2C_COMPAT. Please remove (possibly in a subsequent patch in your series) before sending patches to the mailing list. Remove all references to CONFIG_DM_I2C_COMPAT from davinci. Signed-off-by: Bartosz Golaszewski --- configs/da850_am18xxevm_defconfig | 1 - configs/omapl138_lcdk_defconfig | 1 - include/configs/am3517_evm.h | 1 - include/configs/da850evm.h| 8 include/configs/omapl138_lcdk.h | 8 5 files changed, 19 deletions(-) diff --git a/configs/da850_am18xxevm_defconfig b/configs/da850_am18xxevm_defconfig index f098222113..ad01957fa1 100644 --- a/configs/da850_am18xxevm_defconfig +++ b/configs/da850_am18xxevm_defconfig @@ -44,7 +44,6 @@ CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_DA8XX_GPIO=y CONFIG_DM_I2C=y -CONFIG_DM_I2C_COMPAT=y CONFIG_SYS_I2C_DAVINCI=y CONFIG_MTD_DEVICE=y CONFIG_DM_SPI_FLASH=y diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig index e43141844a..b03d8160af 100644 --- a/configs/omapl138_lcdk_defconfig +++ b/configs/omapl138_lcdk_defconfig @@ -37,7 +37,6 @@ CONFIG_ENV_IS_IN_NAND=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_DM_I2C=y -CONFIG_DM_I2C_COMPAT=y CONFIG_SYS_I2C_DAVINCI=y CONFIG_DM_MMC=y CONFIG_NAND=y diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 9475e9975d..11f8f6d213 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -14,7 +14,6 @@ #include -#undef CONFIG_DM_I2C_COMPAT #define CONFIG_REVISION_TAG /* Hardware drivers */ diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index ccdac0abec..5d02c35279 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -18,14 +18,6 @@ #define CONFIG_USE_SPIFLASH #endif -/* -* Disable DM_* for SPL build and can be re-enabled after adding -* DM support in SPL -*/ -#ifdef CONFIG_SPL_BUILD -#undef CONFIG_DM_I2C -#undef CONFIG_DM_I2C_COMPAT -#endif /* * SoC Configuration */ diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h index da615e5063..db4a663c53 100644 --- a/include/configs/omapl138_lcdk.h +++ b/include/configs/omapl138_lcdk.h @@ -16,14 +16,6 @@ #undef CONFIG_USE_SPIFLASH #undef CONFIG_SYS_USE_NOR -/* -* Disable DM_* for SPL build and can be re-enabled after adding -* DM support in SPL -*/ -#ifdef CONFIG_SPL_BUILD -#undef CONFIG_DM_I2C -#undef CONFIG_DM_I2C_COMPAT -#endif /* * SoC Configuration */ -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] davinci: fix build warnings
From: Bartosz Golaszewski There are several build warnings related to driver-model usage emitted when building u-boot for da850-evm and da850-lcdk. This series fixes them and - while we're at it - removes the i2c compatiblity layer as davinci was the last user of it. Bartosz Golaszewski (4): davinci: remove CONFIG_DM_I2C_COMPAT from defconfigs sandbox: remove CONFIG_DM_I2C_COMPAT from defconfigs i2c: remove i2c driver-model compatibility layer omapl138_lcdk_defconfig: don't build support for SPI Makefile | 7 -- configs/da850_am18xxevm_defconfig | 1 - configs/omapl138_lcdk_defconfig| 7 +- configs/sandbox64_defconfig| 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_noblk_defconfig| 1 - configs/sandbox_spl_defconfig | 1 - configs/tools-only_defconfig | 1 - drivers/i2c/Kconfig| 13 +-- drivers/i2c/Makefile | 1 - drivers/i2c/i2c-uclass-compat.c| 128 - include/_exports.h | 3 +- include/configs/am3517_evm.h | 1 - include/configs/da850evm.h | 8 -- include/configs/omapl138_lcdk.h| 8 -- include/exports.h | 3 +- include/i2c.h | 80 -- 18 files changed, 4 insertions(+), 262 deletions(-) delete mode 100644 drivers/i2c/i2c-uclass-compat.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] riscv: Add Microchip MPFS Icicle board support
Hi Padmarao, On Mon, 2019-05-27 at 11:13 +0530, Padmarao Begari wrote: > Hi Lukas, > > On Mon, May 20, 2019 at 5:33 PM Auer, Lukas > wrote: > > Hi Padmarao, > > > > On Mon, 2019-05-13 at 16:18 +0530, Padmarao Begari wrote: > > > This patch adds Microchip MPFS Icicle board support. > > > For now, NS16550 serial driver is only enabled. > > > The Microchip MPFS Icicle defconfig by default builds > > > U-Boot for M-Mode with SMP support. > > > > > > Signed-off-by: Padmarao Begari > > > --- > > > Changes in v3 > > > - Fix some typos > > > - Remove CONFIG_DM, CONFIG_DM_SERIAL, CONFIG_BAUDRATE, > > > CONFIG_SYS_NS16550, CONFIG_SYS_TEXT_BASE and CONFIG_NR_DRAM_BANKS > > > from microchip_mpfs_icicle_defconfig > > > - Add config SYS_TEXT_BASE in board kconfig > > > - Imply SYS_NS16550 in BOARD_SPECIFIC_OPTIONS > > > - select BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > > > > > > Changes in v2 > > > - Fix some typos > > > - Rename target board to TARGET_MICROCHIP_ICICLE > > > - select CONFIG_BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > > > - Remove #ifdef CONFIG_BOARD_EARLY_INIT_F > > > --- > > > arch/riscv/Kconfig| 4 ++ > > > board/microchip/mpfs_icicle/Kconfig | 26 + > > > board/microchip/mpfs_icicle/MAINTAINERS | 7 > > > board/microchip/mpfs_icicle/Makefile | 7 > > > board/microchip/mpfs_icicle/mpfs_icicle.c | 30 +++ > > > configs/microchip_mpfs_icicle_defconfig | 9 + > > > include/configs/microchip_mpfs_icicle.h | 63 > > > +++ > > > 7 files changed, 146 insertions(+) > > > create mode 100644 board/microchip/mpfs_icicle/Kconfig > > > create mode 100644 board/microchip/mpfs_icicle/MAINTAINERS > > > create mode 100644 board/microchip/mpfs_icicle/Makefile > > > create mode 100644 board/microchip/mpfs_icicle/mpfs_icicle.c > > > create mode 100644 configs/microchip_mpfs_icicle_defconfig > > > create mode 100644 include/configs/microchip_mpfs_icicle.h > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > index 362f3cd..573d6d6 100644 > > > --- a/arch/riscv/Kconfig > > > +++ b/arch/riscv/Kconfig > > > @@ -11,6 +11,9 @@ choice > > > config TARGET_AX25_AE350 > > > bool "Support ax25-ae350" > > > > > > +config TARGET_MICROCHIP_ICICLE > > > + bool "Support Microchip PolarFire-SoC Icicle Board" > > > + > > > config TARGET_QEMU_VIRT > > > bool "Support QEMU Virt Board" > > > > > > @@ -22,6 +25,7 @@ endchoice > > > # board-specific options below > > > source "board/AndesTech/ax25-ae350/Kconfig" > > > source "board/emulation/qemu-riscv/Kconfig" > > > +source "board/microchip/mpfs_icicle/Kconfig" > > > source "board/sifive/fu540/Kconfig" > > > > > > # platform-specific options below > > > diff --git a/board/microchip/mpfs_icicle/Kconfig > > > b/board/microchip/mpfs_icicle/Kconfig > > > new file mode 100644 > > > index 000..bf8e1a1 > > > --- /dev/null > > > +++ b/board/microchip/mpfs_icicle/Kconfig > > > @@ -0,0 +1,26 @@ > > > +if TARGET_MICROCHIP_ICICLE > > > + > > > +config SYS_BOARD > > > + default "mpfs_icicle" > > > + > > > +config SYS_VENDOR > > > + default "microchip" > > > + > > > +config SYS_CPU > > > + default "generic" > > > + > > > +config SYS_CONFIG_NAME > > > + default "microchip_mpfs_icicle" > > > + > > > +config SYS_TEXT_BASE > > > + default 0x8000 if !RISCV_SMODE > > > + default 0x8020 if RISCV_SMODE > > > + > > > +config BOARD_SPECIFIC_OPTIONS # dummy > > > + def_bool y > > > + select GENERIC_RISCV > > > + select BOARD_EARLY_INIT_F > > > + imply SMP > > > + imply SYS_NS16550 > > > + > > > +endif > > > diff --git a/board/microchip/mpfs_icicle/MAINTAINERS > > > b/board/microchip/mpfs_icicle/MAINTAINERS > > > new file mode 100644 > > > index 000..22f3b97 > > > --- /dev/null > > > +++ b/board/microchip/mpfs_icicle/MAINTAINERS > > > @@ -0,0 +1,7 @@ > > > +Microchip MPFS icicle > > > +M: Padmarao Begari > > > +M: Cyril Jean > > > +S: Maintained > > > +F: board/microchip/mpfs_icicle/ > > > +F: include/configs/microchip_mpfs_icicle.h > > > +F: configs/microchip_mpfs_icicle_defconfig > > > diff --git a/board/microchip/mpfs_icicle/Makefile > > > b/board/microchip/mpfs_icicle/Makefile > > > new file mode 100644 > > > index 000..72b0410 > > > --- /dev/null > > > +++ b/board/microchip/mpfs_icicle/Makefile > > > @@ -0,0 +1,7 @@ > > > +# SPDX-License-Identifier: GPL-2.0+ > > > +# > > > +# Copyright (C) 2019 Microchip Technology Inc. > > > +# Padmarao Begari > > > +# > > > + > > > +obj-y+= mpfs_icicle.o > > > diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c > > > b/board/microchip/mpfs_icicle/mpfs_icicle.c > > > new file mode 100644 > > > index 000..0ef2431 > > > --- /dev/null > > > +++ b/board/microchip/mpfs_icicle/mpfs_icicle.c > > > @@ -0,0 +1,30 @@ > > > +// SPDX-License-Identifier: GPL-2.0+ > > > +/* > > > + * Copyright (C) 2019 Microchip
Re: [U-Boot] [PATCH 2/2] riscv: qemu: Enable e1000 and nvme support
On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > Since we have added the PCI support to the 'virt' target, enable > e1000 and NVME as alternate network and storage devices for these > virtio based devices. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-riscv/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/board/emulation/qemu-riscv/Kconfig > b/board/emulation/qemu-riscv/Kconfig > index 2a03e43..7f9a74d 100644 > --- a/board/emulation/qemu-riscv/Kconfig > +++ b/board/emulation/qemu-riscv/Kconfig > @@ -40,5 +40,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > imply DM_PCI > imply PCIE_ECAM_GENERIC > imply CMD_PCI > + imply E1000 > + imply NVME > > endif Tested the series in QEMU master with an e1000 and a NVMe device, accessing them from U-Boot. Reviewed-by: Lukas Auer Tested-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > Enable the driver for it. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-riscv/Kconfig | 4 > 1 file changed, 4 insertions(+) > Reviewed-by: Lukas Auer Tested-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] dm: net: macb: Implement link speed change callback
On Wed, 2019-05-22 at 00:09 -0700, Bin Meng wrote: > At present the link speed change callback is a nop. According to > macb device tree bindings, an optional "tx_clk" is used to clock > the ethernet controller's TX_CLK under different link speed. > > In 10/100 MII mode, transmit logic must be clocked from a free > running clock generated by the external PHY. In gigabit GMII mode, > the controller, not the external PHY, must generate the 125 MHz > transmit clock towards the PHY. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - add a comment for getting "tx_clk" via clk_get_by_name() > - does not change anything in the default case > - check the return value of clk_set_rate() > > drivers/net/macb.c | 35 +++ > 1 file changed, 35 insertions(+) > Successfully tested the series on a SiFive HiFive Unleashed board at 1000, 100, and 10 Mbps link rates. Reviewed-by: Lukas Auer Tested-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v5] sun8i: h3: Add support for the Beelink-x2 STB
Hi Marcus,
On Sun, 26 May 2019 at 16:57, wrote:
>
> From: Marcus Cooper
>
> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
> SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, an IR receiver, a
> dual colour LED and an optical S/PDIF connector.
>
> Signed-off-by: Marcus Cooper
> ---
> Changes in v5:
> - Corrected DRAM Clock to what is reported on Android boot
> - Removed support for SY8106A regulator
> - Set CONFIG_SPL_TEXT_BASE which is now required.
>
> Changes in v4:
> - updated dts to reflex current linux kernel status
>
> Changes in v3:
> - Removed incorrect commit author
> - Included v1-v2 change info
>
> Changes in v2:
> - updated dts to reflex current linux kernel status
> ---
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/sun8i-h3-beelink-x2.dts | 216 +++
> board/sunxi/MAINTAINERS | 5 +
> configs/beelink_x2_defconfig | 18 +++
> 4 files changed, 240 insertions(+)
> create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
> create mode 100644 configs/beelink_x2_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 83058c4452..716108dd2e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -472,6 +472,7 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
> sun8i-h2-plus-orangepi-r1.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> + sun8i-h3-beelink-x2.dtb \
> sun8i-h3-libretech-all-h3-cc.dtb \
> sun8i-h3-nanopi-m1.dtb \
> sun8i-h3-nanopi-m1-plus.dtb \
> diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts
> b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> new file mode 100644
> index 00..25540b7694
> --- /dev/null
> +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2017 Marcus Cooper
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "Beelink X2";
> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
> +
> + aliases {
> + serial0 =
> + ethernet0 =
> + ethernet1 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + blue {
> + label = "beelink-x2:blue:pwr";
> + gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
> +
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On 27.05.2019 07:21, Igor Opaniuk wrote: > Hi everyone, > > I've finally started looking into the cfb_console.c driver and it's > conversion to DM_VIDEO after our initial discussion [1]. > Unfortunately I've a bit underestimated the amount of effort that > should be done, as mxsfb.c in the Linux mainline obviously pulls the > whole core fb subsystem > (drivers/video/fbdev/core), which can take a while and frankly I doubt > that this is a proper way to do things here. Just wanted to mention that the Linux mxsfb fbdev driver is considered deprecated. See: https://lore.kernel.org/patchwork/patch/950619/#1135990 Also note that the new DRM driver does use OF graph style bindings, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > Taking into account that the deadline for DM_VIDEO conversion is > 2019.07, it's unlikely that we will manage to do the full conversions > this cfb_console driver and all dependent hw specific drivers in a > proper way (where we can provide information about videomodes as > properties in a proper nodes in DT). IMHO, if the deadline hinders us to do it properly, we should extend the deadline. > > Currently the init chain for fb stuff in U-boot (on the other hand, in > the Linux, hw specific driver is probed initially, then they trigger > fb common routines that are needed from `video/fbdev/core`): > stdio_add_devices() -> ./common/stdio.c -> drv_video_init () > (drivers/cfb_console.c) - > video_hw_init (particular hw backend, > which was statically linked at compile time with a proper > video_hw_init() implementation, for example look into mxsfb.c) > > 2 ways of conversion that come to my mind: > 1. Start with simple DM wrappers in cfb_console.c, and introduce dumb > DT nodes so the device at least can be probed. All video configuration > will be stored the same way as before in the U-boot env (for example, > "videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0\0"). > Then, step by step, driver by driver, we can move some properties to > DT and try to sync Linux/U-boot video DT nodes (at least avoid > divergence of tree nodes, so Linux/U-boot video-related DT nodes > conform to each other). Yes, this is kind of dirty workaround, but at > least this something we can start with, and with minimal amount of > intrusive changes. > 2. Perform full conversion, where everything works the same way as in > Linux kernel. Initially I thought that it could be the proper way to > go, but taking into account all differences in the implementation of > fb in U-boot/Linux (even the way how the drivers are initialized), I > think we will just end up pulling the whole big piece from the Linux > kernel, that will definitely take a while (especially further support > of this code base, testing/fixing issues etc.). Is there maybe option 3, start a new DM_VIDEO capable driver mxsfb driver without converting the existing stuff. It is probably not much different from 2, but it allows you to start with a minimal feature set, and go from there incrementally. That is what Marek did when he implemented the Linux mxsfb DRM driver.. Haven't looked into the code much, so this might not really make sense... -- Stefan > > Just to be aware about the amount of effort that should be done: > > : u-boot.git$ grep -e CONFIG_CFB_CONSOLE -r ./configs/ > ./configs/T1042RDB_PI_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/nokia_rx51_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_internal_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > > Additional Kconfig symbols, that depend on CFB_CONSOLE: > * VGA_AS_SINGLE_DEVICE > * CONSOLE_EXTRA_INFO > * CONSOLE_SCROLL_LINES > * SYS_CONSOLE_BG_COL > * SYS_CONSOLE_FG_COL > > Drivers, that don't imply CFG_CONSOLE, but are used alongside with > cfb_console.c (kind of particular hw backend driver for fb console): > * mxsfb.c > * mb862xx.c > * sunxi_display.c > * ati_radeon_fb.c > * fsl_dcu_fb.c > * omap3_dss.c > * da8xx-fb.c > > Looking forward to your suggestions/recommendations here (and let me > know if I missed something), thanks! > > [1] https://lists.denx.de/pipermail/u-boot/2019-April/365506.html ___ U-Boot mailing list
Re: [U-Boot] [PATCH] gpio: add gpio-hog support
On 27. 05. 19 8:30, Heiko Schocher wrote: > add gpio-hog support. GPIO hogging is a mechanism > providing automatic GPIO request and configuration > as part of the gpio-controller's driver probe function. > > for more infos see: > doc/device-tree-bindings/gpio/gpio.txt > > Signed-off-by: Heiko Schocher I have tested it on zcu102 where I use gpio hogs for gt muxes. gpio hogs are handled and setup only when gpio controller is probed. Do we have a way how to say that controllers with gpio hogs should be probed automatically? Right now you are calling it in post_probe which make sense but on the other hand if you find gpio hog in bind you should probe the whole driver without asking for request. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: dts: ficus: Enable booting from eMMC when using SPL
On 05/20/2019 11:46 PM, Manivannan Sadhasivam wrote:
> This commits enables booting from eMMC when using SPL on 96Boards
> Ficus board by adding SDHCI to boot order. Since the SDHCI driver
> already has the reloc flag, this works straightaway.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-ficus-u-boot.dtsi | 1 +
> arch/arm/dts/rk3399-ficus.dts | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> index eab86bdb30..67b63a8352 100644
> --- a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> @@ -3,4 +3,5 @@
> * Copyright (C) 2019 Jagan Teki
> */
>
> +#include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-ddr3-1600.dtsi"
> diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
> index 4b2dd82b67..0f219f4a9c 100644
> --- a/arch/arm/dts/rk3399-ficus.dts
> +++ b/arch/arm/dts/rk3399-ficus.dts
> @@ -15,6 +15,8 @@
>
> chosen {
> stdout-path = "serial2:150n8";
> + u-boot,spl-boot-order = \
> + ,
> };
>
> clkin_gmac: external-gmac-clock {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL
On 05/20/2019 11:46 PM, Manivannan Sadhasivam wrote:
> This commits enables booting from eMMC when using SPL on 96Boards
> Rock960 board by adding SDHCI to boot order. Since the SDHCI driver
> already has the reloc flag, this works straightaway.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-rock960-u-boot.dtsi | 1 +
> arch/arm/dts/rk3399-rock960.dts | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> index 5256f6d3f2..7fb5072a9b 100644
> --- a/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> @@ -3,4 +3,5 @@
> * Copyright (C) 2019 Jagan Teki
> */
>
> +#include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr3-2GB-1600.dtsi"
> diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
> index 7e06bc97e5..c8b9075c73 100644
> --- a/arch/arm/dts/rk3399-rock960.dts
> +++ b/arch/arm/dts/rk3399-rock960.dts
> @@ -12,6 +12,8 @@
>
> chosen {
> stdout-path = "serial2:150n8";
> + u-boot,spl-boot-order = \
> + ,
> };
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: clk: rk3399: allow requests for all UART clocks
On 05/07/2019 04:58 PM, Christoph Muellner wrote: > This patch adds the rate for UART1 and UART3 the same way > as already implemented for UART0 and UART2. > > This is required for boards, which have their console output > on these UARTs. > > Signed-off-by: Christoph Muellner Reviewed-by: Kever Yang Thanks, - Kever > --- > > drivers/clk/rockchip/clk_rk3399.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/rockchip/clk_rk3399.c > b/drivers/clk/rockchip/clk_rk3399.c > index 93a652e5ff..aa6a8ad1c9 100644 > --- a/drivers/clk/rockchip/clk_rk3399.c > +++ b/drivers/clk/rockchip/clk_rk3399.c > @@ -912,7 +912,9 @@ static ulong rk3399_clk_get_rate(struct clk *clk) > rate = rk3399_spi_get_clk(priv->cru, clk->id); > break; > case SCLK_UART0: > + case SCLK_UART1: > case SCLK_UART2: > + case SCLK_UART3: > return 2400; > break; > case PCLK_HDMI_CTRL: ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: rk3399: Add option to print on UART3.
On 05/07/2019 04:58 PM, Christoph Muellner wrote: > The RK3399 SPL does not use a pinctrl driver to setup the UART pins. > Instead it works based on config macros, which set the base address > of the actual UART block. > > Currently the RK3399 SPL support UART0 and UART2. > This patch adds UART3 in the same way as UART0. > > Signed-off-by: Christoph Muellner Reviewed-by: Kever Yang Thanks, - Kever > --- > > arch/arm/mach-rockchip/rk3399/rk3399.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c > b/arch/arm/mach-rockchip/rk3399/rk3399.c > index a7ccd4f3ed..e1f9f8b8ef 100644 > --- a/arch/arm/mach-rockchip/rk3399/rk3399.c > +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c > @@ -80,6 +80,14 @@ void board_debug_uart_init(void) > rk_clrsetreg(>gpio2c_iomux, >GRF_GPIO2C1_SEL_MASK, >GRF_UART0BT_SOUT << GRF_GPIO2C1_SEL_SHIFT); > +#elif defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == > 0xff1B) > + /* Enable early UART3 on the RK3399 */ > + rk_clrsetreg(>gpio3b_iomux, > + GRF_GPIO3B6_SEL_MASK, > + GRF_UART3_SIN << GRF_GPIO3B6_SEL_SHIFT); > + rk_clrsetreg(>gpio3b_iomux, > + GRF_GPIO3B7_SEL_MASK, > + GRF_UART3_SOUT << GRF_GPIO3B7_SEL_SHIFT); > #else > # ifdef CONFIG_TARGET_CHROMEBOOK_BOB > rk_setreg(>io_vsel, 1 << 0); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] rockchip: pinctrl: rk3399: Add support for UART3.
On 05/07/2019 04:58 PM, Christoph Muellner wrote:
> This patch adds the missing GRF bit definitions for UART3 on the RK3399.
>
> Signed-off-by: Christoph Muellner
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
>
> arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> index b32c7d56c5..dd89cd2050 100644
> --- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> @@ -423,6 +423,10 @@ enum {
> GRF_GPIO3B6_SEL_SHIFT = 12,
> GRF_GPIO3B6_SEL_MASK= 3 << GRF_GPIO3B6_SEL_SHIFT,
> GRF_MAC_RXCLK = 1,
> + GRF_UART3_SIN = 2,
> + GRF_GPIO3B7_SEL_SHIFT = 14,
> + GRF_GPIO3B7_SEL_MASK= 3 << GRF_GPIO3B7_SEL_SHIFT,
> + GRF_UART3_SOUT = 2,
>
> /* GRF_GPIO3C_IOMUX */
> GRF_GPIO3C1_SEL_SHIFT = 2,
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rk3399: Restore broken USB3 DTS description.
On 05/07/2019 04:49 PM, Christoph Muellner wrote:
> This is a partial revert of commit 0a09f2f1173d
> ("rockchip: Adjust rk3399 device tree to be closer to linux").
>
> Harmonizing the rk3399.dtsi with the one from Linux is a good idea.
> However, this is only true if the information within that file can be
> used by U-Boot. Before the named commit USB3 was working fine, after the
> commit USB3 was broken on all RK3399 boards.
>
> This commit reverts the USB3 changes to the original ones, which provide
> the required information for the corresponding drivers in the U-Boot tree.
>
> Signed-off-by: Christoph Muellner
Yes, USB dts node is different from Linux now, and I thinks there are
patches
on the list are still working on sync with Linux, we have to make it
work first
before sync everything with Linux.
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
>
> arch/arm/dts/rk3399.dtsi | 88
> ++--
> 1 file changed, 32 insertions(+), 56 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
> index b53e41b4dc..823d459957 100644
> --- a/arch/arm/dts/rk3399.dtsi
> +++ b/arch/arm/dts/rk3399.dtsi
> @@ -349,69 +349,45 @@
> status = "disabled";
> };
>
> - usbdrd3_0: dwc3_typec0: usb@fe80 {
> - compatible = "rockchip,rk3399-dwc3";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>,
> - < ACLK_USB3OTG0>, < ACLK_USB3_RKSOC_AXI_PERF>,
> - < ACLK_USB3>, < ACLK_USB3_GRF>;
> - clock-names = "ref_clk", "suspend_clk",
> - "bus_clk", "aclk_usb3_rksoc_axi_perf",
> - "aclk_usb3", "grf_clk";
> - resets = < SRST_A_USB3_OTG0>;
> - reset-names = "usb3-otg";
> + dwc3_typec0: usb@fe80 {
> + compatible = "rockchip,rk3399-xhci";
> + reg = <0x0 0xfe80 0x0 0x10>;
> status = "disabled";
> + snps,dis-enblslpm-quirk;
> + snps,phyif-utmi-bits = <16>;
> + snps,dis-u2-freeclk-exists-quirk;
> + snps,dis-u2-susphy-quirk;
>
> - usbdrd_dwc3_0: dwc3 {
> - compatible = "snps,dwc3";
> - reg = <0x0 0xfe80 0x0 0x10>;
> - interrupts = ;
> - dr_mode = "otg";
> - phys = <_otg>, <_usb3>;
> - phy-names = "usb2-phy", "usb3-phy";
> - phy_type = "utmi_wide";
> - snps,dis_enblslpm_quirk;
> - snps,dis-u2-freeclk-exists-quirk;
> - snps,dis_u2_susphy_quirk;
> - snps,dis-del-phy-power-chg-quirk;
> - snps,dis-tx-ipgap-linecheck-quirk;
> - power-domains = < RK3399_PD_USB3>;
> - status = "disabled";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + hub {
> + compatible = "usb-hub";
> + usb,device-class = ;
> + };
> + typec_phy0 {
> + compatible = "rockchip,rk3399-usb3-phy";
> + reg = <0x0 0xff7c 0x0 0x4>;
> };
> };
>
> - dwc3_typec1: usbdrd3_1: usb@fe90 {
> - compatible = "rockchip,rk3399-dwc3";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - clocks = < SCLK_USB3OTG1_REF>, < SCLK_USB3OTG1_SUSPEND>,
> - < ACLK_USB3OTG1>, < ACLK_USB3_RKSOC_AXI_PERF>,
> - < ACLK_USB3>, < ACLK_USB3_GRF>;
> - clock-names = "ref_clk", "suspend_clk",
> - "bus_clk", "aclk_usb3_rksoc_axi_perf",
> - "aclk_usb3", "grf_clk";
> - resets = < SRST_A_USB3_OTG1>;
> - reset-names = "usb3-otg";
> + dwc3_typec1: usb@fe90 {
> + compatible = "rockchip,rk3399-xhci";
> + reg = <0x0 0xfe90 0x0 0x10>;
> status = "disabled";
> + snps,dis-enblslpm-quirk;
> + snps,phyif-utmi-bits = <16>;
> + snps,dis-u2-freeclk-exists-quirk;
> + snps,dis-u2-susphy-quirk;
>
> - usbdrd_dwc3_1: dwc3 {
> - compatible = "snps,dwc3";
> - reg = <0x0 0xfe90 0x0 0x10>;
> - interrupts = ;
> - dr_mode = "otg";
> - phys = <_otg>, <_usb3>;
> - phy-names = "usb2-phy", "usb3-phy";
> - phy_type = "utmi_wide";
> - snps,dis_enblslpm_quirk;
> - snps,dis-u2-freeclk-exists-quirk;
> -
Re: [U-Boot] [PATCH] rockchip: rk3399-puma: Reduce SPL size.
Hi Christoph, On 05/07/2019 04:42 PM, Christoph Muellner wrote: > This commit reduces the SPL size by fixing typos in the removed property > string list, switching to the tiny versions of printf/memset and > disabling SPL_DOS/EFI_PARTITION support. > > Signed-off-by: Christoph Muellner Reviewed-by: Kever Yang Thanks, - Kever > --- > > configs/puma-rk3399_defconfig | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig > index 964464ac0f..95e6eef10f 100644 > --- a/configs/puma-rk3399_defconfig > +++ b/configs/puma-rk3399_defconfig > @@ -47,10 +47,12 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +# CONFIG_SPL_DOS_PARTITION is not set > +# CONFIG_SPL_EFI_PARTITION is not set > CONFIG_SPL_OF_CONTROL=y > CONFIG_OF_LIVE=y > CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-ddr1600" > -CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent > assigned-clocks assigned-clock-rates assigned-clock-parents" > +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parents > assigned-clocks assigned-clock-rates assigned-clock-parents" > CONFIG_ENV_IS_IN_MMC=y > CONFIG_REGMAP=y > CONFIG_SPL_REGMAP=y > @@ -110,4 +112,6 @@ CONFIG_DM_VIDEO=y > CONFIG_DISPLAY=y > CONFIG_VIDEO_ROCKCHIP=y > CONFIG_DISPLAY_ROCKCHIP_HDMI=y > +CONFIG_USE_TINY_PRINTF=y > +CONFIG_SPL_TINY_MEMSET=y > CONFIG_ERRNO_STR=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi Fabio, On 23.05.19 19:45, Fabio Estevam wrote: > Hi Schrempf, > > On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder > wrote: > >> As luck would have it, I needed to load a FIT via SDP today, so I came >> up with a quick patch (see below). There are probably better ways to do >> this, but it works. > > Thanks for your patch! > > I would like to give it a try, but it does not apply against U-Boot mainline. > > I manually applied it, but failed to build: > > cmd/usb_gadget_sdp.c: In function ‘do_sdp’: > cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ >sdp_handle(controller_index); Sorry, I just picked the patch from my messy working tree and it's based on 2019.04 and some other changes. > Could you please rebase it against U-Boot mainline and post it like a > formal patch? I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream. Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
