[U-Boot] [PATCH 1/1] efi_loader: factor our efi_check_register_notify_event()

[Heinrich Schuchardt]

The code to check if a registration key is a valid key returned by
RegisterProtocolNotify() can be reused. So let us factor it out into a new
function efi_check_register_notify_event().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 1ccf54c386..dd5f706af7 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1388,6 +1388,27 @@ static int efi_search(enum efi_locate_search_type 
search_type,
}
 }

+/**
+ * efi_check_register_notify_event() - check if registration key is valid
+ *
+ * Check that a pointer is a valid registration key as returned by
+ * RegisterProtocolNotify().
+ *
+ * @key:   registration key
+ * Return: valid registration key or NULL
+ */
+static struct efi_register_notify_event *efi_check_register_notify_event
+   (void *key)
+{
+   struct efi_register_notify_event *event;
+
+   list_for_each_entry(event, _register_notify_events, link) {
+   if (event == (struct efi_register_notify_event *)key)
+   return event;
+   }
+   return NULL;
+}
+
 /**
  * efi_locate_handle() - locate handles implementing a protocol
  *
@@ -1409,7 +1430,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;
+   struct efi_register_notify_event *event;
struct efi_protocol_notification *handle = NULL;

/* Check parameters */
@@ -1420,13 +1441,7 @@ static efi_status_t efi_locate_handle(
if (!search_key)
return EFI_INVALID_PARAMETER;
/* Check that the registration key is valid */
-   list_for_each_entry(item, _register_notify_events, link) {
-   if (item ==
-   (struct efi_register_notify_event *)search_key) {
-   event = item;
-   break;
-   }
-   }
+   event = efi_check_register_notify_event(search_key);
if (!event)
return EFI_INVALID_PARAMETER;
break;
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/5] remoteproc: k3_rproc: Rename to ti_k3_arm64_rproc

[Lokesh Vutla]

k3_rproc driver is specifically meant for controlling an arm64
core using TISCI protocol. So rename the driver, Kconfig symbol,
compatible and functions accordingly.

While at it drop this remoteproc selection for a53 defconfig.

Signed-off-by: Lokesh Vutla 
---
 configs/am65x_evm_a53_defconfig   |  1 -
 configs/am65x_evm_r5_defconfig|  2 +-
 configs/am65x_hs_evm_a53_defconfig|  1 -
 configs/am65x_hs_evm_r5_defconfig |  2 +-
 drivers/remoteproc/Kconfig| 20 ---
 drivers/remoteproc/Makefile   |  2 +-
 .../{k3_rproc.c => ti_k3_arm64_rproc.c}   | 57 ++-
 7 files changed, 43 insertions(+), 42 deletions(-)
 rename drivers/remoteproc/{k3_rproc.c => ti_k3_arm64_rproc.c} (77%)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 41cf0100fa..eb49d48994 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -66,7 +66,6 @@ CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
 CONFIG_TI_SCI_POWER_DOMAIN=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_K3=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 3814872ec7..8c67363ec4 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -78,7 +78,7 @@ CONFIG_SPL_DM_REGULATOR_GPIO=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_K3=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
diff --git a/configs/am65x_hs_evm_a53_defconfig 
b/configs/am65x_hs_evm_a53_defconfig
index 9c55cd37f6..6dad546dc3 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -69,7 +69,6 @@ CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
 CONFIG_TI_SCI_POWER_DOMAIN=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_K3=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
diff --git a/configs/am65x_hs_evm_r5_defconfig 
b/configs/am65x_hs_evm_r5_defconfig
index 0b12f15782..fbca0f87d7 100644
--- a/configs/am65x_hs_evm_r5_defconfig
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -80,7 +80,7 @@ CONFIG_SPL_DM_REGULATOR_GPIO=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
-CONFIG_REMOTEPROC_K3=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9eb532bc7a..db4d4ee856 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -22,15 +22,6 @@ config K3_SYSTEM_CONTROLLER
help
  Say 'y' here to add support for TI' K3 System Controller.
 
-config REMOTEPROC_K3
-   bool "Support for TI's K3 based remoteproc driver"
-   select REMOTEPROC
-   depends on DM
-   depends on ARCH_K3
-   depends on OF_CONTROL
-   help
- Say 'y' here to add support for TI' K3 remoteproc driver.
-
 config REMOTEPROC_SANDBOX
bool "Support for Test processor for Sandbox"
select REMOTEPROC
@@ -40,6 +31,17 @@ config REMOTEPROC_SANDBOX
  Say 'y' here to add support for test processor which does dummy
  operations for sandbox platform.
 
+config REMOTEPROC_TI_K3_ARM64
+   bool "Support for TI's K3 based ARM64 remoteproc driver"
+   select REMOTEPROC
+   depends on DM
+   depends on ARCH_K3
+   depends on OF_CONTROL
+   help
+ Say y here to support TI's ARM64 processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
 config REMOTEPROC_TI_POWER
bool "Support for TI Power processor"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 77eb708523..ccc8e7ec32 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -8,6 +8,6 @@ obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o
 
 # Remote proc drivers - Please keep this list alphabetically sorted.
 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_TI_K3_ARM64) += ti_k3_arm64_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/k3_rproc.c 
b/drivers/remoteproc/ti_k3_arm64_rproc.c
similarity index 77%
rename from drivers/remoteproc/k3_rproc.c
rename to drivers/remoteproc/ti_k3_arm64_rproc.c
index 4f9567c924..9676a96f98 100644
--- a/drivers/remoteproc/k3_rproc.c
+++ b/drivers/remoteproc/ti_k3_arm64_rproc.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Texas Instruments' K3 Remoteproc driver
+ * Texas Instruments' K3 ARM64 Remoteproc driver
  *
  * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
  * Lokesh Vutla 
@@ -24,14 +24,14 @@
 #define GTC_CNTR_EN0x3
 
 /**
- * struct 

[U-Boot] [PATCH 2/5] cmd: remoteproc: Allow list command to print the probed devices

[Lokesh Vutla]

'rproc list' is currently allowed only after probing all the
available remoteproc devices. Given that 'rproc init' is updated
to probe and initialize devices individually, allow the 'rproc list'
command to print all probed devices at any point.

Signed-off-by: Lokesh Vutla 
---
 cmd/remoteproc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/cmd/remoteproc.c b/cmd/remoteproc.c
index 689e1a6a1d..12383f399e 100644
--- a/cmd/remoteproc.c
+++ b/cmd/remoteproc.c
@@ -34,6 +34,10 @@ static int print_remoteproc_list(void)
 
uc_pdata = dev_get_uclass_platdata(dev);
 
+   /* Do not print if rproc is not probed */
+   if (!(dev->flags & DM_FLAG_ACTIVATED))
+   continue;
+
switch (uc_pdata->mem_type) {
case RPROC_INTERNAL_MEMORY_MAPPED:
type = "internal memory mapped";
@@ -101,11 +105,6 @@ static int do_rproc_init(cmd_tbl_t *cmdtp, int flag, int 
argc,
 static int do_remoteproc_list(cmd_tbl_t *cmdtp, int flag, int argc,
  char *const argv[])
 {
-   if (!rproc_is_initialized()) {
-   printf("\t Remote Processors is not initialized\n");
-   return CMD_RET_USAGE;
-   }
-
if (print_remoteproc_list())
return CMD_RET_FAILURE;
 
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/5] remoteproc: k3_rproc: Update the driver to use ti_sci_proc helpers

[Lokesh Vutla]

Update the k3_rproc driver to use the generic ti_sci_proc helper
apis which simplifies the driver a bit.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/k3_rproc.c | 79 ++-
 1 file changed, 31 insertions(+), 48 deletions(-)

diff --git a/drivers/remoteproc/k3_rproc.c b/drivers/remoteproc/k3_rproc.c
index 3c29d925ce..4f9567c924 100644
--- a/drivers/remoteproc/k3_rproc.c
+++ b/drivers/remoteproc/k3_rproc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "ti_sci_proc.h"
 
 #define INVALID_ID 0x
 
@@ -27,18 +28,15 @@
  * @rproc_pwrdmn:  rproc power domain data
  * @rproc_rst: rproc reset control data
  * @sci:   Pointer to TISCI handle
+ * @tsp:   TISCI processor control helper structure
  * @gtc_base:  Timer base address.
- * @proc_id:   TISCI processor ID
- * @host_id:   TISCI host id to which the processor gets assigned to.
  */
 struct k3_rproc_privdata {
struct power_domain rproc_pwrdmn;
struct power_domain gtc_pwrdmn;
struct reset_ctl rproc_rst;
-   const struct ti_sci_handle *sci;
+   struct ti_sci_proc tsp;
void *gtc_base;
-   u16 proc_id;
-   u16 host_id;
 };
 
 /**
@@ -52,27 +50,16 @@ struct k3_rproc_privdata {
 static int k3_rproc_load(struct udevice *dev, ulong addr, ulong size)
 {
struct k3_rproc_privdata *rproc = dev_get_priv(dev);
-   const struct ti_sci_proc_ops *pops = >sci->ops.proc_ops;
int ret;
 
dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
 
/* request for the processor */
-   ret = pops->proc_request(rproc->sci, rproc->proc_id);
-   if (ret) {
-   dev_err(dev, "Requesting processor failed %d\n", ret);
+   ret = ti_sci_proc_request(>tsp);
+   if (ret)
return ret;
-   }
-
-   ret = pops->set_proc_boot_cfg(rproc->sci, rproc->proc_id, addr, 0, 0);
-   if (ret) {
-   dev_err(dev, "set_proc_boot_cfg failed %d\n", ret);
-   return ret;
-   }
-
-   dev_dbg(dev, "%s: rproc successfully loaded\n", __func__);
 
-   return 0;
+   return ti_sci_proc_set_config(>tsp, addr, 0, 0);
 }
 
 /**
@@ -84,7 +71,6 @@ static int k3_rproc_load(struct udevice *dev, ulong addr, 
ulong size)
 static int k3_rproc_start(struct udevice *dev)
 {
struct k3_rproc_privdata *rproc = dev_get_priv(dev);
-   const struct ti_sci_proc_ops *pops = >sci->ops.proc_ops;
int ret;
 
dev_dbg(dev, "%s\n", __func__);
@@ -109,24 +95,7 @@ static int k3_rproc_start(struct udevice *dev)
return ret;
}
 
-   if (rproc->host_id != INVALID_ID) {
-   ret = pops->proc_handover(rproc->sci, rproc->proc_id,
- rproc->host_id);
-   if (ret) {
-   dev_err(dev, "Handover processor failed %d\n", ret);
-   return ret;
-   }
-   } else {
-   ret = pops->proc_release(rproc->sci, rproc->proc_id);
-   if (ret) {
-   dev_err(dev, "Processor release failed %d\n", ret);
-   return ret;
-   }
-   }
-
-   dev_dbg(dev, "%s: rproc successfully started\n", __func__);
-
-   return 0;
+   return ti_sci_proc_release(>tsp);
 }
 
 /**
@@ -151,6 +120,27 @@ static const struct dm_rproc_ops k3_rproc_ops = {
.start = k3_rproc_start,
 };
 
+static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
+{
+   dev_dbg(dev, "%s\n", __func__);
+
+   tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
+   if (IS_ERR(tsp->sci)) {
+   dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
+   return PTR_ERR(tsp->sci);
+   }
+
+   tsp->proc_id = dev_read_u32_default(dev, "ti,sci-proc-id", INVALID_ID);
+   if (tsp->proc_id == INVALID_ID) {
+   dev_err(dev, "proc id not populated\n");
+   return -ENOENT;
+   }
+   tsp->host_id = dev_read_u32_default(dev, "ti,sci-host-id", INVALID_ID);
+   tsp->ops = >sci->ops.proc_ops;
+
+   return 0;
+}
+
 /**
  * k3_of_to_priv() - generate private data from device tree
  * @dev:   corresponding k3 remote processor device
@@ -183,11 +173,9 @@ static int k3_rproc_of_to_priv(struct udevice *dev,
return ret;
}
 
-   rproc->sci = ti_sci_get_by_phandle(dev, "ti,sci");
-   if (IS_ERR(rproc->sci)) {
-   dev_err(dev, "ti_sci get failed: %d\n", ret);
-   return PTR_ERR(rproc->sci);
-   }
+   ret = ti_sci_proc_of_to_priv(dev, >tsp);
+   if (ret)
+   return ret;
 
rproc->gtc_base = dev_read_addr_ptr(dev);
if (!rproc->gtc_base) {
@@ -195,11 +183,6 @@ static int k3_rproc_of_to_priv(struct udevice *dev,
return -ENODEV;
}
 
-   rproc->proc_id = 

[U-Boot] [PATCH 3/5] remoteproc: tisci: add TI-SCI processor control helper functions

[Lokesh Vutla]

Texas Instruments' K3 generation SoCs has specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.

The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.

Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The common macros required
by the R5 remoteproc driver were also added. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Suman Anna 
---
 drivers/remoteproc/ti_sci_proc.h | 121 +++
 1 file changed, 121 insertions(+)
 create mode 100644 drivers/remoteproc/ti_sci_proc.h

diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
new file mode 100644
index 00..ccfc39ec88
--- /dev/null
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Texas Instruments TI-SCI Processor Controller Helper Functions
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ * Suman Anna 
+ */
+
+#ifndef REMOTEPROC_TI_SCI_PROC_H
+#define REMOTEPROC_TI_SCI_PROC_H
+
+#define TISCI_INVALID_HOST 0xff
+
+/**
+ * struct ti_sci_proc - structure representing a processor control client
+ * @sci: cached TI-SCI protocol handle
+ * @ops: cached TI-SCI proc ops
+ * @proc_id: processor id for the consumer remoteproc device
+ * @host_id: host id to pass the control over for this consumer remoteproc
+ *  device
+ */
+struct ti_sci_proc {
+   const struct ti_sci_handle *sci;
+   const struct ti_sci_proc_ops *ops;
+   u8 proc_id;
+   u8 host_id;
+};
+
+static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
+{
+   int ret;
+
+   debug("%s: proc_id = %d\n", __func__, tsp->proc_id);
+
+   ret = tsp->ops->proc_request(tsp->sci, tsp->proc_id);
+   if (ret)
+   pr_err("ti-sci processor request failed: %d\n", ret);
+   return ret;
+}
+
+static inline int ti_sci_proc_release(struct ti_sci_proc *tsp)
+{
+   int ret;
+
+   debug("%s: proc_id = %d\n", __func__, tsp->proc_id);
+
+   if (tsp->host_id != TISCI_INVALID_HOST)
+   ret = tsp->ops->proc_handover(tsp->sci, tsp->proc_id,
+ tsp->host_id);
+   else
+   ret = tsp->ops->proc_release(tsp->sci, tsp->proc_id);
+
+   if (ret)
+   pr_err("ti-sci processor release failed: %d\n", ret);
+   return ret;
+}
+
+static inline int ti_sci_proc_handover(struct ti_sci_proc *tsp)
+{
+   int ret;
+
+   debug("%s: proc_id = %d\n", __func__, tsp->proc_id);
+
+   ret = tsp->ops->proc_handover(tsp->sci, tsp->proc_id, tsp->host_id);
+   if (ret)
+   pr_err("ti-sci processor handover of %d to %d failed: %d\n",
+  tsp->proc_id, tsp->host_id, ret);
+   return ret;
+}
+
+static inline int ti_sci_proc_get_status(struct ti_sci_proc *tsp,
+u64 *boot_vector, u32 *cfg_flags,
+u32 *ctrl_flags, u32 *status_flags)
+{
+   int ret;
+
+   ret = tsp->ops->get_proc_boot_status(tsp->sci, tsp->proc_id,
+boot_vector, cfg_flags, ctrl_flags,
+status_flags);
+   if (ret)
+   pr_err("ti-sci processor get_status failed: %d\n", ret);
+
+   debug("%s: proc_id = %d, boot_vector = 0x%llx, cfg_flags = 0x%x, 
ctrl_flags = 0x%x, sts = 0x%x\n",
+ __func__, tsp->proc_id, *boot_vector, *cfg_flags, *ctrl_flags,
+ *status_flags);
+   return ret;
+}
+
+static inline int ti_sci_proc_set_config(struct ti_sci_proc *tsp,
+u64 boot_vector,
+u32 cfg_set, u32 cfg_clr)
+{
+   int ret;
+
+   debug("%s: proc_id = %d, boot_vector = 0x%llx, cfg_set = 0x%x, cfg_clr 
= 0x%x\n",
+ __func__, tsp->proc_id, boot_vector, cfg_set, cfg_clr);
+
+   ret = tsp->ops->set_proc_boot_cfg(tsp->sci, tsp->proc_id, boot_vector,
+ cfg_set, cfg_clr);
+   if (ret)
+   pr_err("ti-sci processor set_config failed: %d\n", ret);
+   

[U-Boot] [PATCH 1/5] cmd: remoteproc: Add support for initializing devices individually

[Lokesh Vutla]

'rproc init' does the probe and initialization of all the available
remoteproc devices in the system. This doesn't allow the flexibility
to initialize the remote cores needed as per use case. In order
to provide flexibility, update 'rproc init' command to accept one
more parameter with rproc id which when passed initializes only
that specific core. If no id is passed, command will initializes
all the cores which is compatible with the existing behaviour.

Signed-off-by: Lokesh Vutla 
---
 cmd/remoteproc.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/cmd/remoteproc.c b/cmd/remoteproc.c
index 81463f36b6..689e1a6a1d 100644
--- a/cmd/remoteproc.c
+++ b/cmd/remoteproc.c
@@ -68,12 +68,22 @@ static int print_remoteproc_list(void)
 static int do_rproc_init(cmd_tbl_t *cmdtp, int flag, int argc,
 char *const argv[])
 {
+   int id;
+
if (rproc_is_initialized()) {
printf("\tRemote Processors are already initialized\n");
-   } else {
+   return CMD_RET_FAILURE;
+   }
+
+   if (argc == 1) {
if (!rproc_init())
return 0;
-   printf("Few Remote Processors failed to be initalized\n");
+   printf("Few Remote Processors failed to be initialized\n");
+   } else if (argc == 2) {
+   id = (int)simple_strtoul(argv[1], NULL, 10);
+   if (!rproc_dev_init(id))
+   return 0;
+   printf("Remote Processor %d failed to be initialized\n", id);
}
 
return CMD_RET_FAILURE;
@@ -203,8 +213,10 @@ static int do_remoteproc_wrapper(cmd_tbl_t *cmdtp, int 
flag, int argc,
 }
 
 static cmd_tbl_t cmd_remoteproc_sub[] = {
-   U_BOOT_CMD_MKENT(init, 0, 1, do_rproc_init,
-"Enumerate and initialize all processors", ""),
+   U_BOOT_CMD_MKENT(init, 1, 1, do_rproc_init,
+"Enumerate and initialize the remote processor(s)",
+"id - ID of the remote processor\n"
+"If id is not passed, initialize all the remote 
processors"),
U_BOOT_CMD_MKENT(list, 0, 1, do_remoteproc_list,
 "list remote processors", ""),
U_BOOT_CMD_MKENT(load, 5, 1, do_remoteproc_load,
@@ -270,7 +282,8 @@ U_BOOT_CMD(rproc, 5, 1, do_remoteproc,
   "\t\tNote: Services are dependent on the driver capability\n"
   "\t\t  'list' command shows the capability of each device\n"
   "\n\tSubcommands:\n"
-  "\tinit   - Enumerate and initalize the remote processors\n"
+  "\tinit  - Enumerate and initalize the remote processor.\n"
+  "\tif id is not passed, initialize all the remote 
prcessors\n"
   "\tlist   - list available remote processors\n"
   "\tload  [addr] [size]- Load the remote processor with binary\n"
   "\timage stored at address [addr] in memory\n"
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/5] remoteproc: cleanup k3_rpoc driver

[Lokesh Vutla]

This series introduces generic proc helpers for controlling remotecores
using TISCI protocol. Update the k3_rproc driver to use this generic
proc helpers and rename it ti_k3_arm64_rproc as it is controlling arm64
core on k3 devices. This acts as base series for the other remoteprocs
(like r5s, c66x and c7x) drivers for J721e SoC.

This series also updates the 'rproc init' to probe and init devices 
individually.

Sandbox test for the 'rpoc init' update: 
https://pastebin.ubuntu.com/p/tBSp95sKsC/

Lokesh Vutla (5):
  cmd: remoteproc: Add support for initializing devices individually
  cmd: remoteproc: Allow list command to print the probed devices
  remoteproc: tisci: add TI-SCI processor control helper functions
  remoteproc: k3_rproc: Update the driver to use ti_sci_proc helpers
  remoteproc: k3_rproc: Rename to ti_k3_arm64_rproc

 cmd/remoteproc.c  |  32 +++--
 configs/am65x_evm_a53_defconfig   |   1 -
 configs/am65x_evm_r5_defconfig|   2 +-
 configs/am65x_hs_evm_a53_defconfig|   1 -
 configs/am65x_hs_evm_r5_defconfig |   2 +-
 drivers/remoteproc/Kconfig|  20 +--
 drivers/remoteproc/Makefile   |   2 +-
 .../{k3_rproc.c => ti_k3_arm64_rproc.c}   | 136 --
 drivers/remoteproc/ti_sci_proc.h  | 121 
 9 files changed, 217 insertions(+), 100 deletions(-)
 rename drivers/remoteproc/{k3_rproc.c => ti_k3_arm64_rproc.c} (56%)
 create mode 100644 drivers/remoteproc/ti_sci_proc.h

-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/7] remoteproc: add elf file load support

[Lokesh Vutla]

On 27/05/19 5:53 PM, Fabien Dessenne wrote:
> 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 

Can you create a new file(rproc-elf-loader.c) or something similar for elf
loading support. Ill be sending 64bit elf loading support soon. Instead of
cluttering rproc-uclass, it is better to separate out elf loading support.

Thanks and regards,
Lokesh

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

Re: [U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Bin Meng]

On Tue, May 28, 2019 at 6:50 PM Greentime Hu  wrote:
>
> Hi Bin,
> On Tue, May 28, 2019 at 05:58:47PM +0800, Bin Meng wrote:
> > Hi Greentime,
> >
> > On Tue, May 28, 2019 at 3:54 PM Greentime Hu  
> > wrote:
> > >
> > > Hi Bin,
> > > On Fri, May 24, 2019 at 05:40:08PM +0800, Bin Meng wrote:
> > > > Hi Eric,
> > > >
> > > > On Fri, May 24, 2019 at 4:04 PM Eric Lin  wrote:
> > > > >
> > > > > Hi Bin
> > > > >
> > > > > Bin Meng  ??? 2019???5???22??? ?? 
> > > > > ??5:25?
> > > > > >
> > > > > > Hi Eric,
> > > > > >
> > > > > > On Wed, May 22, 2019 at 4:23 PM  wrote:
> > > > > > >
> > > > > > > Hi Bin,
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > > > > > > To: Eric Te-Sheng Lin(?)
> > > > > > > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi 
> > > > > > > > Chen(?);
> > > > > > > > Greentime Ying-Han Hu(?); dslin1...@gmail.com
> > > > > > > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D 
> > > > > > > > ISA extensions
> > > > > > > > support
> > > > > > > >
> > > > > > > > Hi Eric,
> > > > > > > >
> > > > > > > > On Tue, May 21, 2019 at 3:18 PM Eric Lin 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > This patch add Kconfig entries for the F (Single-Precision)
> > > > > > > >
> > > > > > > > adds
> > > > > > > >
> > > > > > >
> > > > > > > OK I'll correct it as adds
> > > > > > >
> > > > > > > > > and D (Double-Precision) floating point instruction-set 
> > > > > > > > > extensions.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Could you please provide reason that why U-Boot has to be 
> > > > > > > > compiled using F/D
> > > > > > > > extension?
> > > > > > > >
> > > > > > >
> > > > > > > Cause on AE350 platform, we have two different kinds of toolchain 
> > > > > > > v5d (support I/M/A/C/F/D ISA) and
> > > > > > > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build 
> > > > > > > U-Boot it will build fail, so we would like to add F/D extension 
> > > > > > > on U-Boot.
> > > > > >
> > > > > > I don't understand. What difference do these two toochains have? 
> > > > > > Isn't
> > > > > > the v5d toolchain's default -march string be pre-configured to 
> > > > > > imafd?
> > > > > > But even if the toolchain is pre-configured to generate fd
> > > > > > instruction, I think it can be override by the compiler flags. Can 
> > > > > > you
> > > > > > please share the details of the toolchain you used? I suspect you 
> > > > > > have
> > > > > > to fix your toolchain, not U-Boot.
> > > > > >
> > > > >
> > > > > It's seems the ABI issue. Because our toolchain don't support
> > > > > multilib, the v5d toolchain libraries ABI is ilp64d.
> > > > > If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
> > > > > get link error as below:
> > > >
> > > > Then please fix your compiler. Passing -mabi=lp64 to compiler is
> > > > definitely correct.
> > >
> > >  One of our customer ever used floating point in their project. They want
> > >  to calculate something with floating point instructions in u-Boot before
> > >  entering kernel.
> >
> > This is a new use case. For other architectures like x86, we don't
> > allow U-Boot to be compiled using hardware float ABI. Why can't they
> > use software floating point instead?
>
> It's because they'd like to calculate something very quickly. It may just be
> done in few cycles with floating point instructions and it will be very useful
> for their usages instead of using soft-float.
>
> That's the reason they ask us to provide such kind of CONFIG and we think it
> might also be helpful for users who are trying to do some mathematics with
> floating point instructions in u-Boot.
>

I will have to leave this to other people to comment. I personally do
not like this to be supported in the upstream U-Boot. However if
others do not object, I am OK too.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: dts: ls1021a: Fixed reg for sata node

[Peng Ma]

This patch is to fixed the reg read to "0" for armv7
architecture.

Signed-off-by: Peng Ma 
---
 arch/arm/dts/ls1021a.dtsi |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 5bde3f3..0e00ac2 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -408,8 +408,8 @@
compatible = "fsl,ls1021a-ahci";
/* ccsr sata base */
/* ecc sata addr*/
-   reg = <0x0 0x320 0x0 0x1
-  0x0 0x20220520 0x0 0x4>;
+   reg = <0x320 0x1
+  0x20220520 0x4>;
reg-names = "sata-base", "ecc-addr";
interrupts = <0 101 4>;
status = "disabled";
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [v3, 5/5] mmc: fsl_esdhc_imx: drop useless code

[Peng Fan]

> Subject: [v3, 5/5] mmc: fsl_esdhc_imx: drop useless code
> 
> Dropped useless code for i.MX eSDHC driver.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - Added this patch.
> Changes for v3:
>   - None.
> ---
>  drivers/mmc/fsl_esdhc_imx.c | 96 ++---
>  include/fsl_esdhc_imx.h |  4 --
>  2 files changed, 4 insertions(+), 96 deletions(-)
> 

[.]

> - { .compatible = "fsl,esdhc", },

Please keep this, the following 2 dts using this compatible.
./arch/arm/dts/vf.dtsi
./arch/arm/dts/imx53-ppd.dts

With this addressed, you could have my
`Reviewed-by: Peng Fan `

>   { /* sentinel */ }
>  };
> 
> diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h index
> e05b24e7e8..8abd28ea50 100644
> --- a/include/fsl_esdhc_imx.h
> +++ b/include/fsl_esdhc_imx.h
> @@ -17,10 +17,6 @@
>  /* needed for the mmc_cfg definition */  #include 
> 
> -#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
> -#include "../board/freescale/common/qixis.h"
> -#endif
> -
>  /* FSL eSDHC-specific constants */
>  #define SYSCTL   0x0002e02c
>  #define SYSCTL_INITA 0x0800
> --
> 2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [v3, 3/5] Convert to use fsl_esdhc_imx for i.MX platforms

[Jason Liu]

> -Original Message-
> From: Y.b. Lu
> Sent: Tuesday, May 21, 2019 4:52 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ;
> dl-uboot-imx ; Albert Aribaud
> ; Eddy Petrișor ;
> Akshay Bhat ; Ken Lin
> ; Heiko Schocher ; Christian
> Gmeiner ; Stefan Roese ; Patrick
> Bruenn ; Troy Kisky
> ; Uri Mashiach
> ; Nikita Kiryanov ;
> Otavio Salvador ; Andreas Geisreiter
> ; Ludwig Zenz ; Eric
> Bénard ; Peng Fan ; Jason Liu
> ; Ye Li ; Adrian Alonso
> ; Alison Wang ;
> thar...@gateworks.com; Ian Ray ; Marcin Niestroj
> ; Andrej Rosano ;
> Marek Vasut ; Lukasz Majewski ; Adam
> Ford ; Olaf Mandel ;
> Martyn Welch ; Ingo Schroeck
> ; Boris Brezillon
> ; Soeren Moch ;
> Richard Hu ; Vanessa Maegima
> ; Max Krummenacher
> ; Stefan Agner
> ; Markus Niebel ;
> Breno Matheus Lima ; Francesco Montefoschi
> ; Parthiban Nallathambi
> ; Albert ARIBAUD ; Jagan Teki
> ; Raffaele RECALCATI
> ; Simone CIANNI ;
> Bhaskar Upadhaya ; Vinitha V Pillai
> ; Prabhakar Kushwaha
> ; Rajesh Bhagat ;
> Antti Mäentausta ; Sébastien Szymanski
> ; Lucile Quirion
> ; Alexey Brodkin
> ; Trevor Woerner ; Anatolij
> Gustschin ; Denis Zalevskiy ; Fabien
> Lahoudere ; Joe Hershberger
> ; Simon Goldschmidt
> ; James Byrne
> ; Angelo Dureghello ; Y.b.
> Lu 
> Subject: [v3, 3/5] Convert to use fsl_esdhc_imx for i.MX platforms
> 
> Converted to use fsl_esdhc_imx for i.MX platforms.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - Rebased.
> Changes for v3:
>   - Rebased.
> ---
>  arch/arm/cpu/arm1136/mx35/generic.c   | 10 +-
>  arch/arm/cpu/arm926ejs/mx25/generic.c |  8 
>  arch/arm/cpu/armv7/vf610/generic.c| 10 +-
>  arch/arm/cpu/armv8/s32v234/generic.c  |  2 +-
>  arch/arm/include/asm/global_data.h|  2 +-
>  arch/arm/mach-imx/cpu.c   |  6 +++---
>  arch/arm/mach-imx/mx6/litesom.c   |  4 ++--
>  arch/arm/mach-imx/mx7/clock.c |  4 ++--
>  arch/arm/mach-imx/mx7ulp/clock.c  |  2 +-
>  arch/arm/mach-imx/speed.c |  4 ++--
>  board/advantech/dms-ba16/dms-ba16.c   |  4 ++--
>  board/aristainetos/aristainetos-v1.c  |  2 +-
>  board/aristainetos/aristainetos-v2.c  |  2 +-
>  board/aristainetos/aristainetos.c |  4 ++--
>  board/bachmann/ot1200/ot1200.c|  2 +-
>  board/barco/platinum/platinum.c   |  2 +-
>  board/barco/titanium/titanium.c   |  4 ++--
>  board/beckhoff/mx53cx9020/mx53cx9020.c|  4 ++--
>  board/boundary/nitrogen6x/nitrogen6x.c|  4 ++--
>  board/ccv/xpress/xpress.c |  2 +-
>  board/compulab/cl-som-imx7/cl-som-imx7.c  |  6 +++---
>  board/compulab/cl-som-imx7/common.c   |  6 +++---
>  board/compulab/cl-som-imx7/common.h   |  8 
>  board/compulab/cl-som-imx7/mux.c  |  8 
>  board/compulab/cl-som-imx7/spl.c  |  6 +++---
>  board/compulab/cm_fx6/cm_fx6.c|  4 ++--
>  board/compulab/cm_fx6/common.c|  4 ++--
>  board/compulab/cm_fx6/spl.c   |  2 +-
>  board/congatec/cgtqmx6eval/cgtqmx6eval.c  |  4 ++--
>  board/dhelectronics/dh_imx6/dh_imx6.c |  4 ++--
>  board/dhelectronics/dh_imx6/dh_imx6_spl.c |  2 +-
>  board/el/el6x/el6x.c  |  4 ++--
>  board/embest/mx6boards/mx6boards.c|  4 ++--
>  board/freescale/imx8mq_evk/imx8mq_evk.c   |  2 +-
>  board/freescale/imx8mq_evk/spl.c  |  2 +-
>  board/freescale/imx8qxp_mek/imx8qxp_mek.c |  2 +-
>  board/freescale/mx25pdk/mx25pdk.c |  6 +++---
>  board/freescale/mx35pdk/mx35pdk.c |  4 ++--
>  board/freescale/mx51evk/mx51evk.c |  6 +++---
>  board/freescale/mx53ard/mx53ard.c |  4 ++--
>  board/freescale/mx53evk/mx53evk.c |  4 ++--
>  board/freescale/mx53loco/mx53loco.c   |  4 ++--
>  board/freescale/mx53smd/mx53smd.c |  4 ++--
>  board/freescale/mx6qarm2/mx6qarm2.c   |  4 ++--
>  board/freescale/mx6sabreauto/mx6sabreauto.c   |  4 ++--
>  board/freescale/mx6sabresd/mx6sabresd.c   |  4 ++--
>  board/freescale/mx6slevk/mx6slevk.c   |  2 +-
>  board/freescale/mx6sxsabreauto/mx6sxsabreauto.c   |  2 +-
>  board/freescale/mx6sxsabresd/mx6sxsabresd.c   |  2 +-
>  board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |  4 ++--
>  board/freescale/mx6ullevk/mx6ullevk.c |  2 +-
>  board/freescale/mx7dsabresd/mx7dsabresd.c |  2 +-
>  board/freescale/s32v234evb/s32v234evb.c   |  4 ++--
>  board/freescale/vf610twr/vf610twr.c   |  4 ++--
>  board/gateworks/gw_ventana/common.c   |  6 +++---
>  

Re: [U-Boot] [v3, 4/5] mmc: fsl_esdhc: drop i.MX code

[Peng Fan]

> Subject: [v3, 4/5] mmc: fsl_esdhc: drop i.MX code
> 
> Dropped i.MX code which couldn't be reused.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - Added this patch.
> Changes for v3:
>   - Rebased.
> ---
>  drivers/mmc/fsl_esdhc.c | 609 ++--
>  include/fsl_esdhc.h |  57 
>  2 files changed, 21 insertions(+), 645 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 1b7de74a72..3f4f75ae4c 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -16,14 +16,11 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> @@ -33,8 +30,6 @@ DECLARE_GLOBAL_DATA_PTR;
>   IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE 
> | \
>   IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR |
> \
>   IRQSTATEN_DINT)
> -#define MAX_TUNING_LOOP 40
> -
>  struct fsl_esdhc {
>   uintdsaddr; /* SDMA system address register */
>   uintblkattr;/* Block attributes register */
> @@ -54,37 +49,20 @@ struct fsl_esdhc {
>   uintautoc12err; /* Auto CMD error status register */
>   uinthostcapblt; /* Host controller capabilities register */
>   uintwml;/* Watermark level register */
> - uintmixctrl;/* For USDHC */
> - charreserved1[4];   /* reserved */
> + charreserved1[8];   /* reserved */
>   uintfevt;   /* Force event register */
>   uintadmaes; /* ADMA error status register */
>   uintadsaddr;/* ADMA system address register */
> - charreserved2[4];
> - uintdllctrl;
> - uintdllstat;
> - uintclktunectrlstatus;
> - charreserved3[4];
> - uintstrobe_dllctrl;
> - uintstrobe_dllstat;
> - charreserved4[72];
> - uintvendorspec;
> - uintmmcboot;
> - uintvendorspec2;
> - uinttuning_ctrl;/* on i.MX6/7/8 */
> - charreserved5[44];
> + charreserved2[160];
>   uinthostver;/* Host controller version register */
> - charreserved6[4];   /* reserved */
> + charreserved3[4];   /* reserved */
>   uintdmaerraddr; /* DMA error address register */
> - charreserved7[4];   /* reserved */
> + charreserved4[4];   /* reserved */
>   uintdmaerrattr; /* DMA error attribute register */
> - charreserved8[4];   /* reserved */
> + charreserved5[4];   /* reserved */
>   uinthostcapblt2;/* Host controller capabilities register 2 */
> - charreserved9[8];   /* reserved */
> - uinttcr;/* Tuning control register */
> - charreserved10[28]; /* reserved */
> - uintsddirctl;   /* SD direction control register */
> - charreserved11[712];/* reserved */
> - uintscr;/* eSDHC control register */
> + charreserved6[756]; /* reserved */
> + uintesdhcctl;   /* eSDHC control register */
>  };
> 
>  struct fsl_esdhc_plat {
> @@ -92,11 +70,6 @@ struct fsl_esdhc_plat {
>   struct mmc mmc;
>  };
> 
> -struct esdhc_soc_data {
> - u32 flags;
> - u32 caps;
> -};
> -
>  /**
>   * struct fsl_esdhc_priv
>   *
> @@ -109,13 +82,6 @@ struct esdhc_soc_data {
>   * @dev: pointer for the device
>   * @non_removable: 0: removable; 1: non-removable
>   * @wp_enable: 1: enable checking wp; 0: no check
> - * @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
> - * @flags: ESDHC_FLAG_xx in include/fsl_esdhc.h
> - * @caps: controller capabilities
> - * @tuning_step: tuning step setting in tuning_ctrl register
> - * @start_tuning_tap: the start point for tuning in tuning_ctrl register
> - * @strobe_dll_delay_target: settings in strobe_dllctrl
> - * @signal_voltage: indicating the current voltage
>   * @cd_gpio: gpio for card detection
>   * @wp_gpio: gpio for write protection
>   */
> @@ -124,7 +90,6 @@ struct fsl_esdhc_priv {
>   unsigned int sdhc_clk;
>   struct clk per_clk;
>   unsigned int clock;
> - unsigned int mode;
>   unsigned int bus_width;
>  #if !CONFIG_IS_ENABLED(BLK)
>   struct mmc *mmc;
> @@ -132,21 +97,6 @@ struct fsl_esdhc_priv {
>   struct udevice *dev;
>   int non_removable;
>   int wp_enable;
> - int vs18_enable;
> - u32 flags;
> - u32 caps;
> - u32 tuning_step;
> - u32 tuning_start_tap;
> - u32 strobe_dll_delay_target;
> - u32 signal_voltage;
> -#if IS_ENABLED(CONFIG_DM_REGULATOR)
> - struct udevice *vqmmc_dev;
> - struct udevice *vmmc_dev;
> -#endif
> -#ifdef CONFIG_DM_GPIO
> - struct gpio_desc cd_gpio;
> - struct gpio_desc wp_gpio;
> -#endif
>  };
> 
>  /* Return the XFERTYP flags for a given command and data packet */ @@
> 

Re: [U-Boot] [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig

[Jason Liu]

> -Original Message-
> From: Y.b. Lu
> Sent: Tuesday, May 21, 2019 4:52 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ;
> dl-uboot-imx ; Albert Aribaud
> ; Eddy Petrișor ;
> Akshay Bhat ; Ken Lin
> ; Heiko Schocher ; Christian
> Gmeiner ; Stefan Roese ; Patrick
> Bruenn ; Troy Kisky
> ; Uri Mashiach
> ; Nikita Kiryanov ;
> Otavio Salvador ; Andreas Geisreiter
> ; Ludwig Zenz ; Eric
> Bénard ; Peng Fan ; Jason Liu
> ; Ye Li ; Adrian Alonso
> ; Alison Wang ;
> thar...@gateworks.com; Ian Ray ; Marcin Niestroj
> ; Andrej Rosano ;
> Marek Vasut ; Lukasz Majewski ; Adam
> Ford ; Olaf Mandel ;
> Martyn Welch ; Ingo Schroeck
> ; Boris Brezillon
> ; Soeren Moch ;
> Richard Hu ; Vanessa Maegima
> ; Max Krummenacher
> ; Stefan Agner
> ; Markus Niebel ;
> Breno Matheus Lima ; Francesco Montefoschi
> ; Parthiban Nallathambi
> ; Albert ARIBAUD ; Jagan Teki
> ; Raffaele RECALCATI
> ; Simone CIANNI ;
> Bhaskar Upadhaya ; Vinitha V Pillai
> ; Prabhakar Kushwaha
> ; Rajesh Bhagat ;
> Antti Mäentausta ; Sébastien Szymanski
> ; Lucile Quirion
> ; Alexey Brodkin
> ; Trevor Woerner ; Anatolij
> Gustschin ; Denis Zalevskiy ; Fabien
> Lahoudere ; Joe Hershberger
> ; Simon Goldschmidt
> ; James Byrne
> ; Angelo Dureghello ; Y.b.
> Lu 
> Subject: [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig
> 
> Moved CONFIG_FSL_ESDHC from header files to defconfig files.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
> - Rebased.
> Changes for v3:
>   - Rebased.
> ---
>  configs/imx8mq_evk_defconfig   | 1 +
>  configs/imx8qm_mek_defconfig   | 1 +
>  configs/imx8qxp_mek_defconfig  | 1 +
>  configs/kp_imx6q_tpc_defconfig | 1 +
>  configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 +
>  configs/ls1012afrwy_qspi_defconfig | 1 +
>  configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig  | 1 +
>  configs/ls1012afrwy_tfa_defconfig  | 1 +
>  include/configs/imx8mq_evk.h   | 1 -
>  include/configs/imx8qm_mek.h   | 1 -
>  include/configs/imx8qxp_mek.h  | 1 -
>  include/configs/kp_imx6q_tpc.h | 1 -
>  include/configs/ls1012afrwy.h  | 1 -
>  13 files changed, 8 insertions(+), 5 deletions(-)

Acked-by: Jason Liu 


> 
> --
> 2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [v3, 2/5] mmc: split fsl_esdhc driver for i.MX

[Peng Fan]

> Subject: [v3, 2/5] mmc: split fsl_esdhc driver for i.MX
> 
> The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX initially.
> The later QoriQ series PowerPC processors (which were evolutions of
> MPC83XX/MPC85XX), QorIQ series ARM processors, and i.MX series
> processors were using this driver for their eSDHCs too.
> 
> For the two series processors, the eSDHCs are becoming more and more
> different. We should have split it into two drivers, like them
> (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
> 
> This patch is just to create a fsl_esdhc_imx driver which is a copy of 
> fsl_esdhc
> driver for i.MX processors. We will convert i.MX processors to use
> fsl_esdhc_imx, and clean up the two drivers separately in the future patches.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> Changes for v3:
>   - None.
> ---
>  drivers/mmc/Kconfig  |  6 ++
>  drivers/mmc/Makefile |  1 +
>  drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} |  5 +++--
>  include/{fsl_esdhc.h => fsl_esdhc_imx.h} | 11 ++-
>  4 files changed, 16 insertions(+), 7 deletions(-)  copy
> drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} (99%)  copy
> include/{fsl_esdhc.h => fsl_esdhc_imx.h} (97%)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> c23299ea96..4e33fa1b2d 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -671,6 +671,12 @@ config FSL_ESDHC
> This selects support for the eSDHC (enhanced secure digital host
> controller) found on numerous Freescale/NXP SoCs.
> 
> +config FSL_ESDHC_IMX
> + bool "Freescale/NXP i.MX eSDHC controller support"
> + help
> +   This selects support for the i.MX eSDHC (enhanced secure digital host
> +   controller) found on numerous Freescale/NXP SoCs.
> +
>  endmenu
> 
>  config SYS_FSL_ERRATUM_ESDHC111
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index
> 0076fc393b..3c8c53a9e1 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MMC_DW_ROCKCHIP)   +=
> rockchip_dw_mmc.o
>  obj-$(CONFIG_MMC_DW_SOCFPGA) += socfpga_dw_mmc.o
>  obj-$(CONFIG_MMC_DW_SNPS)+= snps_dw_mmc.o
>  obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
> +obj-$(CONFIG_FSL_ESDHC_IMX) += fsl_esdhc_imx.o
>  obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
>  obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
>  obj-$(CONFIG_MMC_MESON_GX) += meson_gx_mmc.o diff --git
> a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc_imx.c similarity index
> 99% copy from drivers/mmc/fsl_esdhc.c copy to
> drivers/mmc/fsl_esdhc_imx.c index 1b7de74a72..faf133390f 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -2,6 +2,7 @@
>  /*
>   * Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
>   * Andy Fleming
> + * Copyright 2019 NXP
>   *
>   * Based vaguely on the pxa mmc code:
>   * (C) Copyright 2003
> @@ -18,7 +19,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -110,7 +111,7 @@ struct esdhc_soc_data {
>   * @non_removable: 0: removable; 1: non-removable
>   * @wp_enable: 1: enable checking wp; 0: no check
>   * @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
> - * @flags: ESDHC_FLAG_xx in include/fsl_esdhc.h
> + * @flags: ESDHC_FLAG_xx in include/fsl_esdhc_imx.h
>   * @caps: controller capabilities
>   * @tuning_step: tuning step setting in tuning_ctrl register
>   * @start_tuning_tap: the start point for tuning in tuning_ctrl register diff
> --git a/include/fsl_esdhc.h b/include/fsl_esdhc_imx.h similarity index 97%
> copy from include/fsl_esdhc.h copy to include/fsl_esdhc_imx.h index
> 8dbd5249a7..e05b24e7e8 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc_imx.h
> @@ -4,10 +4,11 @@
>   *---
>   *
>   * Copyright 2007-2008,2010-2011 Freescale Semiconductor, Inc
> + * Copyright 2019 NXP
>   */
> 
> -#ifndef  __FSL_ESDHC_H__
> -#define  __FSL_ESDHC_H__
> +#ifndef __FSL_ESDHC_IMX_H__
> +#define __FSL_ESDHC_IMX_H__
> 
>  #include 
>  #include 
> @@ -258,15 +259,15 @@ struct fsl_esdhc_cfg {  #error "Endianess is not
> defined: please fix to continue"
>  #endif
> 
> -#ifdef CONFIG_FSL_ESDHC
> +#ifdef CONFIG_FSL_ESDHC_IMX
>  int fsl_esdhc_mmc_init(bd_t *bis);
>  int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg);  void
> fdt_fixup_esdhc(void *blob, bd_t *bd);  #else  static inline int
> fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }  static inline void
> fdt_fixup_esdhc(void *blob, bd_t *bd) {} -#endif /* CONFIG_FSL_ESDHC */
> +#endif /* CONFIG_FSL_ESDHC_IMX */
>  void __noreturn mmc_boot(void);
>  void mmc_spl_load_image(uint32_t offs, unsigned int size, void *vdst);
> 
> -#endif  /* __FSL_ESDHC_H__ */
> +#endif  /* __FSL_ESDHC_IMX_H__ */

Reviewed-by: Peng Fan 

> --
> 2.17.1

___
U-Boot mailing 

Re: [U-Boot] [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig

[Peng Fan]

> Subject: [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig
> 
> Moved CONFIG_FSL_ESDHC from header files to defconfig files.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
> - Rebased.
> Changes for v3:
>   - Rebased.
> ---
>  configs/imx8mq_evk_defconfig   | 1 +
>  configs/imx8qm_mek_defconfig   | 1 +
>  configs/imx8qxp_mek_defconfig  | 1 +
>  configs/kp_imx6q_tpc_defconfig | 1 +
>  configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 +
>  configs/ls1012afrwy_qspi_defconfig | 1 +
>  configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig  | 1 +
>  configs/ls1012afrwy_tfa_defconfig  | 1 +
>  include/configs/imx8mq_evk.h   | 1 -
>  include/configs/imx8qm_mek.h   | 1 -
>  include/configs/imx8qxp_mek.h  | 1 -
>  include/configs/kp_imx6q_tpc.h | 1 -
>  include/configs/ls1012afrwy.h  | 1 -
>  13 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
> index 7383124851..534cf96c58 100644
> --- a/configs/imx8mq_evk_defconfig
> +++ b/configs/imx8mq_evk_defconfig
> @@ -31,6 +31,7 @@ CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_MXC=y
>  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_DM_ETH=y
>  CONFIG_PINCTRL=y
> diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig
> index 1a6ce3abf8..173568c0da 100644
> --- a/configs/imx8qm_mek_defconfig
> +++ b/configs/imx8qm_mek_defconfig
> @@ -52,6 +52,7 @@ CONFIG_I2C_MUX=y
>  CONFIG_I2C_MUX_PCA954x=y
>  CONFIG_MISC=y
>  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHY_ATHEROS=y
> diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig
> index c4a8cf3881..7021bd5da8 100644
> --- a/configs/imx8qxp_mek_defconfig
> +++ b/configs/imx8qxp_mek_defconfig
> @@ -55,6 +55,7 @@ CONFIG_I2C_MUX=y
>  CONFIG_I2C_MUX_PCA954x=y
>  CONFIG_MISC=y
>  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ADDR_ENABLE=y
> diff --git a/configs/kp_imx6q_tpc_defconfig b/configs/kp_imx6q_tpc_defconfig
> index 0ca83cbfea..9b6ff4a85b 100644
> --- a/configs/kp_imx6q_tpc_defconfig
> +++ b/configs/kp_imx6q_tpc_defconfig
> @@ -34,6 +34,7 @@ CONFIG_CMD_EXT4_WRITE=y  #
> CONFIG_ISO_PARTITION is not set  # CONFIG_EFI_PARTITION is not set
> CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ATHEROS=y
>  CONFIG_FEC_MXC=y
> diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> index bf98466576..0360d9d4e8 100644
> --- a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> +++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> CONFIG_SATA_CEVA=y  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_qspi_defconfig
> b/configs/ls1012afrwy_qspi_defconfig
> index aa3256fb43..08eedec827 100644
> --- a/configs/ls1012afrwy_qspi_defconfig
> +++ b/configs/ls1012afrwy_qspi_defconfig
> @@ -32,6 +32,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> CONFIG_SATA_CEVA=y  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> index b0fdad6dd0..2c3d8931e7 100644
> --- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> +++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> CONFIG_SATA_CEVA=y  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_tfa_defconfig
> b/configs/ls1012afrwy_tfa_defconfig
> index 6a70f5881b..19aae5aa1a 100644
> --- a/configs/ls1012afrwy_tfa_defconfig
> +++ b/configs/ls1012afrwy_tfa_defconfig
> @@ -32,6 +32,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> CONFIG_SATA_CEVA=y  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
> index e4fa2df342..16e4136fa9 100644
> --- a/include/configs/imx8mq_evk.h
> +++ b/include/configs/imx8mq_evk.h
> @@ -216,7 +216,6 @@
>  #define CONFIG_IMX_BOOTAUX
> 
>  #define CONFIG_CMD_MMC
> -#define CONFIG_FSL_ESDHC
>  #define CONFIG_FSL_USDHC
> 
>  #define CONFIG_SYS_FSL_USDHC_NUM 2
> diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h
> index 2bdf3be654..3679b487e1 100644
> --- a/include/configs/imx8qm_mek.h
> +++ b/include/configs/imx8qm_mek.h
> @@ -47,7 +47,6 @@
>  #undef CONFIG_CMD_CRC32
>  #undef CONFIG_BOOTM_NETBSD
> 
> -#define CONFIG_FSL_ESDHC
>  

[U-Boot] [PATCH] ARM: legoev3: convert to driver model

[David Lechner]

This converts LEGO MINDSTORMS EV3 to the driver model. MMC, SERIAL, SPI
and SPI_FLASH are converted.

The device tree contains only the minimal nodes required by U-Boot
since the size of U-Boot is limited to 256K on this device.

Signed-off-by: David Lechner 
---
 arch/arm/dts/Makefile   |  3 +-
 arch/arm/dts/da850-lego-ev3.dts | 89 +
 board/lego/ev3/README   |  3 ++
 board/lego/ev3/legoev3.c| 22 
 configs/legoev3_defconfig   |  9 +++-
 include/configs/legoev3.h   |  3 --
 6 files changed, 102 insertions(+), 27 deletions(-)
 create mode 100644 arch/arm/dts/da850-lego-ev3.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 31ef2b66a3..fcbfc2a912 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -30,7 +30,8 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
 
 dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-evm.dtb \
-   da850-lcdk.dtb
+   da850-lcdk.dtb \
+   da850-lego-ev3.dtb
 
 dtb-$(CONFIG_KIRKWOOD) += \
kirkwood-atl-sbx81lifkw.dtb \
diff --git a/arch/arm/dts/da850-lego-ev3.dts b/arch/arm/dts/da850-lego-ev3.dts
new file mode 100644
index 00..e281d039fd
--- /dev/null
+++ b/arch/arm/dts/da850-lego-ev3.dts
@@ -0,0 +1,89 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This is an absolute minimum device tree instead of using the one from Linux
+ * because the bootloader on the EV3 is limited to 256k. This saves us >10k.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "lego,ev3", "ti,da850";
+   model = "LEGO MINDSTORMS EV3";
+
+   aliases {
+   serial1 = 
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0xc000 0x0400>;
+   };
+
+   arm {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   intc: interrupt-controller@fffee000 {
+   compatible = "ti,cp-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   ti,intc-size = <101>;
+   reg = <0xfffee000 0x2000>;
+   };
+   };
+
+   soc@1c0 {
+   compatible = "simple-bus";
+   model = "da850";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x01c0 0x40>;
+   interrupt-parent = <>;
+
+   mmc0: mmc@4 {
+   compatible = "ti,da830-mmc";
+   reg = <0x4 0x1000>;
+   cap-sd-highspeed;
+   cap-mmc-highspeed;
+   interrupts = <16>;
+   max-frequency = <5000>;
+   bus-width = <4>;
+   };
+
+   spi0: spi@41000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "ti,da830-spi";
+   reg = <0x41000 0x1000>;
+   num-cs = <6>;
+   ti,davinci-spi-intr-line = <1>;
+   interrupts = <20>;
+
+   flash@0 {
+   compatible = "micron,n25q128a13", 
"jedec,spi-nor", "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+   };
+   };
+
+   serial1: serial@10c000 {
+   compatible = "ti,da830-uart", "ns16550a";
+   reg = <0x10c000 0x100>;
+   reg-io-width = <4>;
+   reg-shift = <2>;
+   interrupts = <53>;
+   };
+   };
+};
diff --git a/board/lego/ev3/README b/board/lego/ev3/README
index da62a649ba..9ad93e8205 100644
--- a/board/lego/ev3/README
+++ b/board/lego/ev3/README
@@ -50,3 +50,6 @@ software or a 3rd party program capable of uploading a 
firmware file.
 If you are booting from the microSD card, it is enough to just write uboot.bin
 to the flash. If you are not using a microSD card, you will need to create an
 image file using the layout described above.
+
+IMPORTANT: The EEPROM bootloader only copies 256k, so u-boot.img must not
+exceed that size!
diff --git a/board/lego/ev3/legoev3.c b/board/lego/ev3/legoev3.c
index 423c2fa44b..fa099e95f5 100644
--- a/board/lego/ev3/legoev3.c
+++ b/board/lego/ev3/legoev3.c
@@ -25,11 +25,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_MMC_DAVINCI
-#include 
-#include 
-#endif
-
 DECLARE_GLOBAL_DATA_PTR;
 
 u8 board_rev;
@@ -38,23 +33,6 @@ u8 board_rev;
 #define EEPROM_REV_OFFSET  0x3F00
 #define EEPROM_MAC_OFFSET

Re: [U-Boot] [PATCH] configs/legoev3: define CONFIG_SKIP_LOWLEVEL_INIT

[David Lechner]

On 5/28/19 8:52 PM, Adam Ford wrote:

On Tue, May 28, 2019 at 7:03 PM David Lechner  wrote:


This adds a define for CONFIG_SKIP_LOWLEVEL_INIT in the legoev3 config.
On the EV3, U-Boot is loaded into RAM by another bootloader, so we
don't need the lowlevel init in U-Boot.

Signed-off-by: David Lechner 
---
  include/configs/legoev3.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 1e239ecadd..36ca3b201e 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -22,6 +22,7 @@
  #define CONFIG_SYS_OSCIN_FREQ  2400
  #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
  #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
+#define CONFIG_SKIP_LOWLEVEL_INIT


If that's the case, does this mean that the NAK'd patch from Bartosz
removing the dead code can be accepted?


Probably
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] configs/legoev3: define CONFIG_SKIP_LOWLEVEL_INIT

[Adam Ford]

On Tue, May 28, 2019 at 7:03 PM David Lechner  wrote:
>
> This adds a define for CONFIG_SKIP_LOWLEVEL_INIT in the legoev3 config.
> On the EV3, U-Boot is loaded into RAM by another bootloader, so we
> don't need the lowlevel init in U-Boot.
>
> Signed-off-by: David Lechner 
> ---
>  include/configs/legoev3.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
> index 1e239ecadd..36ca3b201e 100644
> --- a/include/configs/legoev3.h
> +++ b/include/configs/legoev3.h
> @@ -22,6 +22,7 @@
>  #define CONFIG_SYS_OSCIN_FREQ  2400
>  #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
>  #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
> +#define CONFIG_SKIP_LOWLEVEL_INIT

If that's the case, does this mean that the NAK'd patch from Bartosz
removing the dead code can be accepted?

adam
>
>  /*
>   * Memory Info
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Derald Woods]

On Tue, May 28, 2019 at 7:49 PM Marek Vasut  wrote:
>
> On 5/29/19 2:00 AM, Derald Woods wrote:
> > On Tue, May 28, 2019 at 6:27 PM Marek Vasut  wrote:
> >>
> >> On 5/29/19 1:16 AM, Derald Woods wrote:
> >>> On Tue, May 28, 2019 at 4:16 PM Marek Vasut  wrote:
> 
>  On 5/28/19 4:22 AM, Derald D. Woods wrote:
> > 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
> > [...]
> >>
> >> Skip to the end first
> >>
> > 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;
> >>
> >> Drop this hunk
> >>
> >  #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,
> >>
> >> Replace musbp with host->host
> >>
> > (struct device *)otg_board_data,
> > platdata->base);
> > + if (IS_ERR_OR_NULL(musbp))
> >>
> >> here too
> >>
> > + return -EINVAL;
> 
>  For example the pic32 glue code holds the musb_host_data in private data
>  , so it can call musb_stop() in .remove callback . Can you do the same?
> 
> >>>
> >>> This was just a non-structural change to eliminate a compiler warning.
> >>> I agree that other things can/should be done with this driver. That
> >>> work would be outside of what I was trying to accomplsh here, at the
> >>> moment.
> >>
> >> See above, I believe that should fix the problem _and_ not crash in the
> >> .remove() .
> >>
> >
> > As with 'ti-musb', there needs to be a clear distinction between
> > 'host' and 'peripheral'/'gadget'. The issues here are much more broad
> > than the compile warning that I was trying to address. The required
> > refactoring, for USB Gadgets, deserves a proper series for older OMAP3
> > devices.
> >
> > I would rather _DROP_ this patch than apply something that could
> > result in a series of kludges.
>
> Does the following patch work for you ?
>

My use case does _not_ enable 'CONFIG_USB_MUSB_HOST'. The C
preprocessor directives prevent 'host->host' from being included in
compilation in that case.

Derald

> diff --git a/drivers/usb/musb-new/omap2430.c
> b/drivers/usb/musb-new/omap2430.c
> index 32743aa72c..bffcb61eaf 100644
> --- a/drivers/usb/musb-new/omap2430.c
> +++ b/drivers/usb/musb-new/omap2430.c
> @@ -236,9 +236,12 @@ static int omap2430_musb_probe(struct udevice *dev)
>
> ret = musb_lowlevel_init(host);
>  #else
> -   ret = musb_register(>plat,
> +   host->host = musb_register(>plat,
>   (struct device *)otg_board_data,
>   platdata->base);
> +
> +   if (!host->host)
> +   return -EIO;
>  #endif
> return ret;
>  }
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Marek Vasut]

On 5/29/19 2:00 AM, Derald Woods wrote:
> On Tue, May 28, 2019 at 6:27 PM Marek Vasut  wrote:
>>
>> On 5/29/19 1:16 AM, Derald Woods wrote:
>>> On Tue, May 28, 2019 at 4:16 PM Marek Vasut  wrote:

 On 5/28/19 4:22 AM, Derald D. Woods wrote:
> 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
> [...]
>>
>> Skip to the end first
>>
> 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;
>>
>> Drop this hunk
>>
>  #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,
>>
>> Replace musbp with host->host
>>
> (struct device *)otg_board_data,
> platdata->base);
> + if (IS_ERR_OR_NULL(musbp))
>>
>> here too
>>
> + return -EINVAL;

 For example the pic32 glue code holds the musb_host_data in private data
 , so it can call musb_stop() in .remove callback . Can you do the same?

>>>
>>> This was just a non-structural change to eliminate a compiler warning.
>>> I agree that other things can/should be done with this driver. That
>>> work would be outside of what I was trying to accomplsh here, at the
>>> moment.
>>
>> See above, I believe that should fix the problem _and_ not crash in the
>> .remove() .
>>
> 
> As with 'ti-musb', there needs to be a clear distinction between
> 'host' and 'peripheral'/'gadget'. The issues here are much more broad
> than the compile warning that I was trying to address. The required
> refactoring, for USB Gadgets, deserves a proper series for older OMAP3
> devices.
> 
> I would rather _DROP_ this patch than apply something that could
> result in a series of kludges.

Does the following patch work for you ?

diff --git a/drivers/usb/musb-new/omap2430.c
b/drivers/usb/musb-new/omap2430.c
index 32743aa72c..bffcb61eaf 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -236,9 +236,12 @@ static int omap2430_musb_probe(struct udevice *dev)

ret = musb_lowlevel_init(host);
 #else
-   ret = musb_register(>plat,
+   host->host = musb_register(>plat,
  (struct device *)otg_board_data,
  platdata->base);
+
+   if (!host->host)
+   return -EIO;
 #endif
return ret;
 }

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] configs/legoev3: define CONFIG_SKIP_LOWLEVEL_INIT

[David Lechner]

This adds a define for CONFIG_SKIP_LOWLEVEL_INIT in the legoev3 config.
On the EV3, U-Boot is loaded into RAM by another bootloader, so we
don't need the lowlevel init in U-Boot.

Signed-off-by: David Lechner 
---
 include/configs/legoev3.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 1e239ecadd..36ca3b201e 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -22,6 +22,7 @@
 #define CONFIG_SYS_OSCIN_FREQ  2400
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
+#define CONFIG_SKIP_LOWLEVEL_INIT
 
 /*
  * Memory Info
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Derald Woods]

On Tue, May 28, 2019 at 6:27 PM Marek Vasut  wrote:
>
> On 5/29/19 1:16 AM, Derald Woods wrote:
> > On Tue, May 28, 2019 at 4:16 PM Marek Vasut  wrote:
> >>
> >> On 5/28/19 4:22 AM, Derald D. Woods wrote:
> >>> 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
> >>> [...]
>
> Skip to the end first
>
> >>> 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;
>
> Drop this hunk
>
> >>>  #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,
>
> Replace musbp with host->host
>
> >>> (struct device *)otg_board_data,
> >>> platdata->base);
> >>> + if (IS_ERR_OR_NULL(musbp))
>
> here too
>
> >>> + return -EINVAL;
> >>
> >> For example the pic32 glue code holds the musb_host_data in private data
> >> , so it can call musb_stop() in .remove callback . Can you do the same?
> >>
> >
> > This was just a non-structural change to eliminate a compiler warning.
> > I agree that other things can/should be done with this driver. That
> > work would be outside of what I was trying to accomplsh here, at the
> > moment.
>
> See above, I believe that should fix the problem _and_ not crash in the
> .remove() .
>

As with 'ti-musb', there needs to be a clear distinction between
'host' and 'peripheral'/'gadget'. The issues here are much more broad
than the compile warning that I was trying to address. The required
refactoring, for USB Gadgets, deserves a proper series for older OMAP3
devices.

I would rather _DROP_ this patch than apply something that could
result in a series of kludges.

Thanks for the feedback.

Derald

> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] rtc: add Microcrystal RV-8803 driver

[Michael Walle]

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.

changes since v1:
 - enable driver in sandbox_defconfig and sandbox64_defconfig

 configs/sandbox64_defconfig |   1 +
 configs/sandbox_defconfig   |   1 +
 drivers/rtc/Kconfig |  10 +++
 drivers/rtc/Makefile|   1 +
 drivers/rtc/rv8803.c| 167 
 5 files changed, 180 insertions(+)
 create mode 100644 drivers/rtc/rv8803.c

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 61175e8063..9b63fb0066 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -163,6 +163,7 @@ CONFIG_REMOTEPROC_SANDBOX=y
 CONFIG_DM_RESET=y
 CONFIG_SANDBOX_RESET=y
 CONFIG_DM_RTC=y
+CONFIG_RTC_RV8803=y
 CONFIG_SANDBOX_SERIAL=y
 CONFIG_SMEM=y
 CONFIG_SANDBOX_SMEM=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index ff01315bd8..d57b95a989 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -179,6 +179,7 @@ CONFIG_REMOTEPROC_SANDBOX=y
 CONFIG_DM_RESET=y
 CONFIG_SANDBOX_RESET=y
 CONFIG_DM_RTC=y
+CONFIG_RTC_RV8803=y
 CONFIG_DEBUG_UART_SANDBOX=y
 CONFIG_SANDBOX_SERIAL=y
 CONFIG_SMEM=y
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 & 

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Marek Vasut]

On 5/29/19 1:16 AM, Derald Woods wrote:
> On Tue, May 28, 2019 at 4:16 PM Marek Vasut  wrote:
>>
>> On 5/28/19 4:22 AM, Derald D. Woods wrote:
>>> 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
>>> [...]

Skip to the end first

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

Drop this hunk

>>>  #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,

Replace musbp with host->host

>>> (struct device *)otg_board_data,
>>> platdata->base);
>>> + if (IS_ERR_OR_NULL(musbp))

here too

>>> + return -EINVAL;
>>
>> For example the pic32 glue code holds the musb_host_data in private data
>> , so it can call musb_stop() in .remove callback . Can you do the same?
>>
> 
> This was just a non-structural change to eliminate a compiler warning.
> I agree that other things can/should be done with this driver. That
> work would be outside of what I was trying to accomplsh here, at the
> moment.

See above, I believe that should fix the problem _and_ not crash in the
.remove() .

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Derald Woods]

On Tue, May 28, 2019 at 4:16 PM Marek Vasut  wrote:
>
> On 5/28/19 4:22 AM, Derald D. Woods wrote:
> > 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;
>
> For example the pic32 glue code holds the musb_host_data in private data
> , so it can call musb_stop() in .remove callback . Can you do the same?
>

This was just a non-structural change to eliminate a compiler warning.
I agree that other things can/should be done with this driver. That
work would be outside of what I was trying to accomplsh here, at the
moment.

Derald

> >  #endif
> >   return ret;
> >  }
> >
>
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: davinci: remove leftover assembly

[Tom Rini]

On Mon, May 20, 2019 at 06:29:38PM +0200, Bartosz Golaszewski wrote:

> From: Bartosz Golaszewski 
> 
> There are no more users of lowlevel_init.S. Remove the file.
> 
> Suggested-by: Adam Ford 
> Signed-off-by: Bartosz Golaszewski 

NAK, legoev3 still uses this.

-- 
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] [RESEND, RFC 1/1] splash: display splash in DM_VIDEO configurations

[Anatolij Gustschin]

On Tue, 28 May 2019 15:19:37 +
Igor Opaniuk igor.opan...@toradex.com wrote:
...
> diff --git a/common/splash.c b/common/splash.c
> index d251b3b654..f026390393 100644
> --- a/common/splash.c
> +++ b/common/splash.c
> @@ -80,11 +80,23 @@ void splash_get_pos(int *x, int *y)
>  }
>  #endif /* CONFIG_SPLASH_SCREEN_ALIGN */
>  
> -#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_LCD)
> -int lcd_splash(ulong addr)
> +/*
> + * Common function to show a splash image if env("splashimage") is set.
> + * Is used for both dm_video and lcd video stacks. For additional
> + * details please refer to doc/README.splashprepare.
> + */
> +#if defined(CONFIG_SPLASH_SCREEN)

splash_display() also depends on code in cmd/bmp.c so please use
#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_CMD_BMP)
here to prevent link errors.

...
> diff --git a/common/stdio.c b/common/stdio.c
> index ee22c1fd58..22de7aa491 100644
> --- a/common/stdio.c
> +++ b/common/stdio.c
...
> @@ -366,6 +367,9 @@ int stdio_add_devices(void)
>   if (ret)
>   printf("%s: Video device failed (ret=%d)\n", __func__, ret);
>  #endif /* !CONFIG_SYS_CONSOLE_IS_IN_ENV */
> +#ifdef CONFIG_SPLASH_SCREEN

#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_CMD_BMP)

> + splash_display();
> +#endif /* CONFIG_SPLASH_SCREEN */
>  #else
>  # if defined(CONFIG_LCD)
>   drv_lcd_init ();

--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] usb: musb-new: omap2430: Fix compilation warning with USB_MUSB_GADGET

[Marek Vasut]

On 5/28/19 4:22 AM, Derald D. Woods wrote:
> 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;

For example the pic32 glue code holds the musb_host_data in private data
, so it can call musb_stop() in .remove callback . Can you do the same?

>  #endif
>   return ret;
>  }
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] mcx: remove board

[Anatolij Gustschin]

On Fri, 17 May 2019 11:17:20 +0200
Bartosz Golaszewski b...@bgdev.pl wrote:

> From: Bartosz Golaszewski 
> 
> This board still doesn't select CONFIG_DM and seems to be umaintained.
> As it makes progress on modernizing several DaVinci drivers more
> difficult and the maintainer has not expressed interest in updating
> it, this patch proposes to remove it.
> 
> Signed-off-by: Bartosz Golaszewski 

I do not have this board any more, so

Acked-by: Anatolij Gustschin 

--
Anatolij
___
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

[Simon Goldschmidt]

Am 27.05.2019 um 18:25 schrieb Masahiro Yamada:

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.


Thanks for the hint! The target in question was 'tools-only', not 
'tools'. And in contrast to 'tools', 'tools-only' is missing the 
dependency to 'prepare'. We could just add that unless we go JJ's python 
way.


Regards,
Simon
___
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

[Marek Vasut]

On 5/28/19 1:19 PM, Tom Rini wrote:
> On Tue, May 28, 2019 at 05:24:34AM +0200, Marek Vasut wrote:
>> 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
> 
> Yes, yes it would be worth seeing if other groups that have looked into
> the performance impact here have also decided to optimize this undefined
> behavior or not, thanks.

I will just drop this patch, since U-Boot memcpy() implementation does
this check. But let me be very clear here, that check is part of
undefined behavior (!) and I don't think it's the right thing to do in
memcpy() itself.

-- 
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 5/5] test/py: clarify a package dependency for test_fs

[Tom Rini]

On Tue, May 28, 2019 at 07:18:34PM +0200, Heinrich Schuchardt wrote:
> On 5/24/19 7:10 AM, AKASHI Takahiro wrote:
> >File system tests, test_fs, relies on guestmount so that it can be
> >executed in a user mode. Describe this in README.md.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  test/py/README.md | 19 ++-
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> >
> >diff --git a/test/py/README.md b/test/py/README.md
> >index 2156661d6c42..50b174b51960 100644
> >--- a/test/py/README.md
> >+++ b/test/py/README.md
> >@@ -25,15 +25,16 @@ On Debian or Debian-like distributions, the following 
> >packages are required.
> >  Some packages are required to execute any test, and others only for 
> > specific
> >  tests. Similar package names should exist in other distributions.
> >
> >-| Package| Version tested (Ubuntu 14.04) |
> >-| -- | - |
> >-| python | 2.7.5-5ubuntu3|
> >-| python-pytest  | 2.5.1-1   |
> >-| python-subunit | - |
> >-| gdisk  | 0.8.8-1ubuntu0.1  |
> >-| dfu-util   | 0.5-1 |
> >-| dtc| 1.4.0+dfsg-1  |
> >-| openssl| 1.0.1f-1ubuntu2.22|
> >+| Package | Version tested (Ubuntu 14.04) |
> 
> Ubuntu 14.04 reached end of life in April.

FWIW, I had a local patch to try and update this list to 16.04 a while
ago, but never finished.  We should probably avoid spelling out a host
distribution and version and just say what we need installed.

-- 
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 v2 5/5] test/py: clarify a package dependency for test_fs

[Heinrich Schuchardt]

On 5/24/19 7:10 AM, AKASHI Takahiro wrote:

File system tests, test_fs, relies on guestmount so that it can be
executed in a user mode. Describe this in README.md.

Signed-off-by: AKASHI Takahiro 
---
  test/py/README.md | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/test/py/README.md b/test/py/README.md
index 2156661d6c42..50b174b51960 100644
--- a/test/py/README.md
+++ b/test/py/README.md
@@ -25,15 +25,16 @@ On Debian or Debian-like distributions, the following 
packages are required.
  Some packages are required to execute any test, and others only for specific
  tests. Similar package names should exist in other distributions.

-| Package| Version tested (Ubuntu 14.04) |
-| -- | - |
-| python | 2.7.5-5ubuntu3|
-| python-pytest  | 2.5.1-1   |
-| python-subunit | - |
-| gdisk  | 0.8.8-1ubuntu0.1  |
-| dfu-util   | 0.5-1 |
-| dtc| 1.4.0+dfsg-1  |
-| openssl| 1.0.1f-1ubuntu2.22|
+| Package | Version tested (Ubuntu 14.04) |


Ubuntu 14.04 reached end of life in April.


+| --- | - |
+| python  | 2.7.5-5ubuntu3|
+| python-pytest   | 2.5.1-1   |
+| python-subunit  | - |
+| gdisk   | 0.8.8-1ubuntu0.1  |
+| dfu-util| 0.5-1 |
+| dtc | 1.4.0+dfsg-1  |


A package called dtc does not exist in Ubuntu. Should this be
device-tree-compiler?


+| openssl | 1.0.1f-1ubuntu2.22|
+| libguestfs-tools| 1:1.32.2-4ubuntu2.2   |


This is a version from Ubuntu 16.04). But the table header refers to
Ubuntu 14.04. Please, provide consistent information.

Best regards

Heinrich



  The test script supports either:




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] test/py: test_fs: add tests for creating/deleting many files

[Tom Rini]

On Tue, May 28, 2019 at 06:46:36PM +0200, Heinrich Schuchardt wrote:

> As both Tom and I wrote to you in reply of to the first version of the
> patch it is not clear how these tests can be run.
> 
> make tests
> 
> simply skips them.
> 
> Could you, please, provide a description in test/py/README.md.

To be a bit more clear, https://patchwork.ozlabs.org/patch/1104600/
documents the requirement to install libguestfs-tools but not how to
configure things further.  Just installing that package locally changes
my existing test/py/tests/test_fs/test_basic.py run from
'..s' to full skip.

-- 
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 v2 5/5] test/py: clarify a package dependency for test_fs

[Heinrich Schuchardt]

On 5/24/19 7:10 AM, AKASHI Takahiro wrote:

File system tests, test_fs, relies on guestmount so that it can be
executed in a user mode. Describe this in README.md.


It is unclear where commands from package libguestfs-tools are used. I
could not find any script in directory test/ using it.

As already mentioned in reply to patch 4 of the series, please, provide
clear instructions how to invoke the file system tests in this README.md.

make qemu_arm64_defconfig
make
python3 ./test/py/test.py --bd=qemu-arm64 --build-dir=.

is simply skipping all of them.

Best regards

Heinrich



Signed-off-by: AKASHI Takahiro 
---
  test/py/README.md | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/test/py/README.md b/test/py/README.md
index 2156661d6c42..50b174b51960 100644
--- a/test/py/README.md
+++ b/test/py/README.md
@@ -25,15 +25,16 @@ On Debian or Debian-like distributions, the following 
packages are required.
  Some packages are required to execute any test, and others only for specific
  tests. Similar package names should exist in other distributions.

-| Package| Version tested (Ubuntu 14.04) |
-| -- | - |
-| python | 2.7.5-5ubuntu3|
-| python-pytest  | 2.5.1-1   |
-| python-subunit | - |
-| gdisk  | 0.8.8-1ubuntu0.1  |
-| dfu-util   | 0.5-1 |
-| dtc| 1.4.0+dfsg-1  |
-| openssl| 1.0.1f-1ubuntu2.22|
+| Package | Version tested (Ubuntu 14.04) |
+| --- | - |
+| python  | 2.7.5-5ubuntu3|
+| python-pytest   | 2.5.1-1   |
+| python-subunit  | - |
+| gdisk   | 0.8.8-1ubuntu0.1  |
+| dfu-util| 0.5-1 |
+| dtc | 1.4.0+dfsg-1  |
+| openssl | 1.0.1f-1ubuntu2.22|
+| libguestfs-tools| 1:1.32.2-4ubuntu2.2   |

  The test script supports either:




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] test/py: test_fs: add tests for creating/deleting many files

[Heinrich Schuchardt]

As both Tom and I wrote to you in reply of to the first version of the
patch it is not clear how these tests can be run.

make tests

simply skips them.

Could you, please, provide a description in test/py/README.md.

Best regards

Heinrich

On 5/24/19 7:10 AM, AKASHI Takahiro wrote:

Two test cases are added under test_fs_ext:
 test case 10: for root directory
 test case 11: for non-root directory

Those will verify a behavior fixed by the commits related to
root directory
("fs: fat: allocate a new cluster for root directory of fat32" and
"fs: fat: flush a directory cluster properly"), and focus on
handling long-file-name directory entries under a directory.

Signed-off-by: AKASHI Takahiro 
---
  test/py/tests/test_fs/test_ext.py | 84 +++
  1 file changed, 84 insertions(+)

diff --git a/test/py/tests/test_fs/test_ext.py 
b/test/py/tests/test_fs/test_ext.py
index 2c47738b8df2..361f440dd6d4 100644
--- a/test/py/tests/test_fs/test_ext.py
+++ b/test/py/tests/test_fs/test_ext.py
@@ -233,3 +233,87 @@ class TestFsExt(object):
  % (fs_type, ADDR, MIN_FILE)])
  assert('Unable to write "/dir1' in ''.join(output))
  assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext10(self, u_boot_console, fs_obj_ext):
+"""
+'Test Case 10 - create/delete as many directories under root directory
+as amount of directory entries goes beyond one cluster size)'
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 10 - create/delete (many)'):
+# Test Case 10a - Create many files
+#   Please note that the size of directory entry is 32 bytes.
+#   So one typical cluster may holds 64 (2048/32) entries.
+output = u_boot_console.run_command(
+'host bind 0 %s' % fs_img)
+
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert('FILE0123456789_00' in output)
+assert('FILE0123456789_41' in output)
+
+# Test Case 10b - Delete many files
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%srm host 0:0 /FILE0123456789_%02x'
+% (fs_type, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert(not 'FILE0123456789_00' in output)
+assert(not 'FILE0123456789_41' in output)
+
+# Test Case 10c - Create many files again
+# Please note no.64 and 65 are intentionally re-created
+for i in range(64, 128):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert('FILE0123456789_40' in output)
+assert('FILE0123456789_79' in output)
+
+assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext11(self, u_boot_console, fs_obj_ext):
+"""
+'Test Case 11 - create/delete as many directories under non-root
+directory as amount of directory entries goes beyond one cluster size)'
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 10 - create/delete (many)'):
+# Test Case 11a - Create many files
+#   Please note that the size of directory entry is 32 bytes.
+#   So one typical cluster may holds 64 (2048/32) entries.
+output = u_boot_console.run_command(
+'host bind 0 %s' % fs_img)
+
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /dir1/FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /dir1' % 
fs_type)
+assert('FILE0123456789_00' in output)
+assert('FILE0123456789_41' in output)
+
+# Test Case 11b - Delete many files
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%srm host 0:0 /dir1/FILE0123456789_%02x'
+% (fs_type, i))
+output = u_boot_console.run_command('%sls host 0:0 /dir1' % 
fs_type)
+assert(not 'FILE0123456789_00' in output)
+assert(not 'FILE0123456789_41' in output)
+
+# Test Case 11c - Create many files again
+# Please note no.64 and 65 are intentionally re-created
+for i in range(64, 128):
+output = u_boot_console.run_command(
+'%swrite host 

[U-Boot] Pull request, u-boot-tegra/master

[Tom Warren]

 Tom,

Please pull u-boot-tegra/master into U-Boot/master. Thanks!

All Tegra builds are OK, and Stephen's automated test system reports that
all tests pass.

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-tegra.git master

for you to fetch changes up to 430cfc861be2e5aada26cd96d97f3b9911782b16:

  tegra: nyan-big: Enable sound (2019-05-24 10:14:22 -0700)


Simon Glass (7):
  tegra: Correct tegra124 clock name
  tegra: Add a delay in clock_start_periph_pll()
  tegra: sound: Add an audio hub driver
  tegra: sound: Add an I2S driver
  sound: tegra: Add a sound driver
  tegra: nyan: Add a README
  tegra: nyan-big: Enable sound

 arch/arm/include/asm/arch-tegra/tegra_ahub.h | 475
+++
 arch/arm/include/asm/arch-tegra/tegra_i2s.h  | 206 
 arch/arm/mach-tegra/clock.c  |   1 +
 arch/arm/mach-tegra/tegra124/clock.c |   2 +-
 board/nvidia/nyan-big/README |  18 +
 board/nvidia/nyan-big/nyan-big.c |   2 +-
 configs/nyan-big_defconfig   |   7 +
 drivers/sound/Kconfig|   9 +
 drivers/sound/Makefile   |   1 +
 drivers/sound/tegra_ahub.c   | 256 +++
 drivers/sound/tegra_i2s.c| 123 +++
 drivers/sound/tegra_i2s_priv.h   |  29 ++
 drivers/sound/tegra_sound.c  | 100 ++
 13 files changed, 1227 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra/tegra_ahub.h
 create mode 100644 arch/arm/include/asm/arch-tegra/tegra_i2s.h
 create mode 100644 board/nvidia/nyan-big/README
 create mode 100644 drivers/sound/tegra_ahub.c
 create mode 100644 drivers/sound/tegra_i2s.c
 create mode 100644 drivers/sound/tegra_i2s_priv.h
 create mode 100644 drivers/sound/tegra_sound.c
___
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

[Simon Goldschmidt]

Am 28.05.2019 um 17:18 schrieb Jean-Jacques Hiblot:


On 27/05/2019 17:15, Simon Goldschmidt wrote:



Tom Rini mailto:tr...@konsulko.com>> 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
mailto:simon.k.r.goldschm...@gmail.com>>
> >>---
> >>
> >>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...


Yes that is  what I was trying to express.

Below is an draft of what I had in mind. Admittedly it less clear than 
the C file.


If it works, then it's ok for me (maybe with a little added 
documentation to make it cleare). I'm not at all obsessed by my version :-)


Regards,
Simon



JJ



Regrds,
Simon



  Makefile    |  2 +-

  tools/spl_size_limit.py | 51 +
  2 files changed, 52 insertions(+), 1 deletion(-)
  create mode 100755 tools/spl_size_limit.py

diff --git a/Makefile b/Makefile
index 8de3d4120a..440ea1da2d 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,$@,$$(tools/spl_size_limit))
+SPL_SIZE_CHECK = $(call size_check,$@,$$($(src)/tools/spl_size_limit.py 
SPL))

  else
  SPL_SIZE_CHECK =
  endif
diff --git a/tools/spl_size_limit.py b/tools/spl_size_limit.py
new file mode 100755
index 00..2c40f5701e
--- /dev/null
+++ b/tools/spl_size_limit.py
@@ -0,0 +1,51 @@
+#! /usr/bin/env python
+import os
+import sys
+
+binary_types = {"U-BOOT":("","./"), "SPL":("SPL_","spl/"), 
"TPL":("TPL_","tpl/")}

+
+def get_from_file(f, pattern):
+    for l in f.readlines():
+        if l.startswith(pattern):
+            return l[len(pattern):].strip()
+    return None
+
+def get_from_cfg_file(bintype, name):
+    pattern = '#define CONFIG_{}{} '.format(binary_types[bintype][0], name)
+    with open("{}u-boot.cfg".format(binary_types[bintype][1])) as f:
+        return get_from_file(f, pattern)
+
+def get_from_header(fname, name):
+    pattern = '#define {} '.format(name)
+    with open("{}".format(fname)) as f:
+        return get_from_file(f, pattern).split()[0]
+
+def usage():
+    print("usage: {} [SPL|TPL]")
+    sys.exit(1)
+
+if len(sys.argv) != 2 and len(sys.argv) != 1:
+    usage()
+if len(sys.argv) == 2 and sys.argv[1] not in binary_types.keys():
+    usage()
+
+bintype = sys.argv[1]
+
+gbl_data_size = 
int(get_from_header("include/generated/generic-asm-offsets.h",

+                    "GENERATED_GBL_DATA_SIZE"), 0)
+size_limit_subtract_gd = get_from_cfg_file(bintype, 
"SIZE_LIMIT_SUBTRACT_GD")

+size_limit_subtract_malloc = get_from_cfg_file(bintype,
+                       "SIZE_LIMIT_SUBTRACT_MALLOC")
+sys_malloc_f_len = int(get_from_cfg_file(bintype, "SYS_MALLOC_F_LEN"), 0)
+size_limit_provide_stack = get_from_cfg_file(bintype,
+                     "SIZE_LIMIT_PROVIDE_STACK")
+
+size_limit = int(get_from_cfg_file(bintype, "SIZE_LIMIT"), 0)
+if size_limit_subtract_gd:
+    size_limit = size_limit - gbl_data_size
+if size_limit_subtract_malloc:
+    size_limit = size_limit - sys_malloc_f_len
+if size_limit_provide_stack:
+    size_limit = size_limit - int(size_limit_provide_stack, 0)
+

[U-Boot] [PATCH] cmd/fpga.c: correct typo, capitalize "Xilinx"

[Robert P. J. Day]

A couple minor tweaks to printed strings in cmd/fpga.c.

Signed-off-by: Robert P. J. Day 

---

diff --git a/cmd/fpga.c b/cmd/fpga.c
index b1f224bc6a..62453f0a8f 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -458,7 +458,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga_wrapper,
   "0-device key, 1-user key, 2-no encryption.\n"
   "The optional Userkey address specifies from which address key\n"
   "has to be used for decryption if user key is selected.\n"
-  "NOTE: the sceure bitstream has to be created using xilinx\n"
+  "NOTE: the secure bitstream has to be created using Xilinx\n"
   "bootgen tool only.\n"
 #endif
 );

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/2] net: eth-uclass: Support device tree MAC addresses

[Peter Robinson]

On Tue, May 28, 2019 at 4:26 PM Thierry Reding  wrote:
>
> On Mon, May 20, 2019 at 05:59:57PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> >
> > Add the standard Ethernet device tree bindings (imported from v5.0 of
> > the Linux kernel) and implement support for reading the MAC address for
> > Ethernet devices in the Ethernet uclass. If the "mac-address" property
> > exists, the MAC address will be parsed from that. If that property does
> > not exist, the "local-mac-address" property will be tried as fallback.
> >
> > MAC addresses from device tree take precedence over the ones stored in
> > a network interface card's ROM.
> >
> > Acked-by: Joe Hershberger 
> > Reviewed-by: Grygorii Strashko 
> > Signed-off-by: Thierry Reding 
> > ---
> > Changes in v4:
> > - do not clear MAC address on failure to avoid overwriting existing MAC
> > - fix build on xtensa (missing CONFIG_OF_CONTROL)
> >
> > Changes in v3:
> > - add additional check to make sure the MAC address read from device
> >   tree is a valid MAC address
> >
> > Changes in v2:
> > - use dev_read_u8_array_ptr()
> > ---
> >  .../devicetree/bindings/net/ethernet.txt  | 66 +++
> >  net/eth-uclass.c  | 30 -
> >  2 files changed, 93 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/net/ethernet.txt
>
> Hi Joe,
>
> did you have a chance to look at this updated version? I've manually
> verified that the qemu-x86_64 test failure is no longer there and the
> build failure for xtensa is also gone.
>
> A fairly largish series for Tom's Tegra tree is currently blocked on
> this because without these two patches it will cause a test failure.

I've tested v2 of this series, I have on my list to rebase and test v4
later this week if that will help.

Peter

> Thierry
>
> > diff --git a/Documentation/devicetree/bindings/net/ethernet.txt 
> > b/Documentation/devicetree/bindings/net/ethernet.txt
> > new file mode 100644
> > index ..cfc376bc977a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> > @@ -0,0 +1,66 @@
> > +The following properties are common to the Ethernet controllers:
> > +
> > +NOTE: All 'phy*' properties documented below are Ethernet specific. For the
> > +generic PHY 'phys' property, see
> > +Documentation/devicetree/bindings/phy/phy-bindings.txt.
> > +
> > +- local-mac-address: array of 6 bytes, specifies the MAC address that was
> > +  assigned to the network device;
> > +- mac-address: array of 6 bytes, specifies the MAC address that was last 
> > used by
> > +  the boot program; should be used in cases where the MAC address assigned 
> > to
> > +  the device by the boot program is different from the "local-mac-address"
> > +  property;
> > +- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
> > +- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
> > +- max-speed: number, specifies maximum speed in Mbit/s supported by the 
> > device;
> > +- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather 
> > than
> > +  the maximum frame size (there's contradiction in the Devicetree
> > +  Specification).
> > +- phy-mode: string, operation mode of the PHY interface. This is now a 
> > de-facto
> > +  standard property; supported values are:
> > +  * "internal"
> > +  * "mii"
> > +  * "gmii"
> > +  * "sgmii"
> > +  * "qsgmii"
> > +  * "tbi"
> > +  * "rev-mii"
> > +  * "rmii"
> > +  * "rgmii" (RX and TX delays are added by the MAC when required)
> > +  * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, 
> > the
> > + MAC should not add the RX or TX delays in this case)
> > +  * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
> > + should not add an RX delay in this case)
> > +  * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
> > + should not add an TX delay in this case)
> > +  * "rtbi"
> > +  * "smii"
> > +  * "xgmii"
> > +  * "trgmii"
> > +  * "2000base-x",
> > +  * "2500base-x",
> > +  * "rxaui"
> > +  * "xaui"
> > +  * "10gbase-kr" (10GBASE-KR, XFI, SFI)
> > +- phy-connection-type: the same as "phy-mode" property but described in the
> > +  Devicetree Specification;
> > +- phy-handle: phandle, specifies a reference to a node representing a PHY
> > +  device; this property is described in the Devicetree Specification and so
> > +  preferred;
> > +- phy: the same as "phy-handle" property, not recommended for new bindings.
> > +- phy-device: the same as "phy-handle" property, not recommended for new
> > +  bindings.
> > +- rx-fifo-depth: the size of the controller's receive fifo in bytes. This
> > +  is used for components that can have configurable receive fifo sizes,
> > +  and is useful for determining certain configuration settings such as
> > +  flow control thresholds.
> > +- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
> > +  is used 

Re: [U-Boot] [PATCH v4 2/2] net: eth-uclass: Support device tree MAC addresses

[Thierry Reding]

On Mon, May 20, 2019 at 05:59:57PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Add the standard Ethernet device tree bindings (imported from v5.0 of
> the Linux kernel) and implement support for reading the MAC address for
> Ethernet devices in the Ethernet uclass. If the "mac-address" property
> exists, the MAC address will be parsed from that. If that property does
> not exist, the "local-mac-address" property will be tried as fallback.
> 
> MAC addresses from device tree take precedence over the ones stored in
> a network interface card's ROM.
> 
> Acked-by: Joe Hershberger 
> Reviewed-by: Grygorii Strashko 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v4:
> - do not clear MAC address on failure to avoid overwriting existing MAC
> - fix build on xtensa (missing CONFIG_OF_CONTROL)
> 
> Changes in v3:
> - add additional check to make sure the MAC address read from device
>   tree is a valid MAC address
> 
> Changes in v2:
> - use dev_read_u8_array_ptr()
> ---
>  .../devicetree/bindings/net/ethernet.txt  | 66 +++
>  net/eth-uclass.c  | 30 -
>  2 files changed, 93 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/ethernet.txt

Hi Joe,

did you have a chance to look at this updated version? I've manually
verified that the qemu-x86_64 test failure is no longer there and the
build failure for xtensa is also gone.

A fairly largish series for Tom's Tegra tree is currently blocked on
this because without these two patches it will cause a test failure.

Thierry

> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt 
> b/Documentation/devicetree/bindings/net/ethernet.txt
> new file mode 100644
> index ..cfc376bc977a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -0,0 +1,66 @@
> +The following properties are common to the Ethernet controllers:
> +
> +NOTE: All 'phy*' properties documented below are Ethernet specific. For the
> +generic PHY 'phys' property, see
> +Documentation/devicetree/bindings/phy/phy-bindings.txt.
> +
> +- local-mac-address: array of 6 bytes, specifies the MAC address that was
> +  assigned to the network device;
> +- mac-address: array of 6 bytes, specifies the MAC address that was last 
> used by
> +  the boot program; should be used in cases where the MAC address assigned to
> +  the device by the boot program is different from the "local-mac-address"
> +  property;
> +- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
> +- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
> +- max-speed: number, specifies maximum speed in Mbit/s supported by the 
> device;
> +- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather 
> than
> +  the maximum frame size (there's contradiction in the Devicetree
> +  Specification).
> +- phy-mode: string, operation mode of the PHY interface. This is now a 
> de-facto
> +  standard property; supported values are:
> +  * "internal"
> +  * "mii"
> +  * "gmii"
> +  * "sgmii"
> +  * "qsgmii"
> +  * "tbi"
> +  * "rev-mii"
> +  * "rmii"
> +  * "rgmii" (RX and TX delays are added by the MAC when required)
> +  * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the
> + MAC should not add the RX or TX delays in this case)
> +  * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
> + should not add an RX delay in this case)
> +  * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
> + should not add an TX delay in this case)
> +  * "rtbi"
> +  * "smii"
> +  * "xgmii"
> +  * "trgmii"
> +  * "2000base-x",
> +  * "2500base-x",
> +  * "rxaui"
> +  * "xaui"
> +  * "10gbase-kr" (10GBASE-KR, XFI, SFI)
> +- phy-connection-type: the same as "phy-mode" property but described in the
> +  Devicetree Specification;
> +- phy-handle: phandle, specifies a reference to a node representing a PHY
> +  device; this property is described in the Devicetree Specification and so
> +  preferred;
> +- phy: the same as "phy-handle" property, not recommended for new bindings.
> +- phy-device: the same as "phy-handle" property, not recommended for new
> +  bindings.
> +- rx-fifo-depth: the size of the controller's receive fifo in bytes. This
> +  is used for components that can have configurable receive fifo sizes,
> +  and is useful for determining certain configuration settings such as
> +  flow control thresholds.
> +- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
> +  is used for components that can have configurable fifo sizes.
> +- managed: string, specifies the PHY management type. Supported values are:
> +  "auto", "in-band-status". "auto" is the default, it usess MDIO for
> +  management if fixed-link is not specified.
> +
> +Child nodes of the Ethernet controller are typically the individual PHY 
> devices
> +connected via the MDIO bus (sometimes the MDIO 

[U-Boot] [RESEND, RFC 1/1] splash: display splash in DM_VIDEO configurations

[Igor Opaniuk]

Currently for CONFIG_DM_VIDEO=y setting splashimage env variable doesn't
have any effect. Introduce a common function for both dm-video/lcd stacks,
that checks env("splashimage") and invokes bmp_display() accordingly.
For additional details please check discussion [1].

[1] https://lists.denx.de/pipermail/u-boot/2019-May/371002.html

Signed-off-by: Igor Opaniuk 
---
 common/lcd.c | 10 +++---
 common/splash.c  | 16 ++--
 common/stdio.c   |  4 
 include/splash.h |  6 +++---
 4 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index 95526b1e17..a55f1620a1 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -222,14 +222,10 @@ void lcd_clear(void)
/* Paint the logo and retrieve LCD base address */
debug("[LCD] Drawing the logo...\n");
if (do_splash) {
-   s = env_get("splashimage");
-   if (s) {
+   if (splash_display() == 0) {
do_splash = 0;
-   addr = simple_strtoul(s, NULL, 16);
-   if (lcd_splash(addr) == 0) {
-   lcd_sync();
-   return;
-   }
+   lcd_sync();
+   return;
}
}
 
diff --git a/common/splash.c b/common/splash.c
index d251b3b654..f026390393 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -80,11 +80,23 @@ void splash_get_pos(int *x, int *y)
 }
 #endif /* CONFIG_SPLASH_SCREEN_ALIGN */
 
-#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_LCD)
-int lcd_splash(ulong addr)
+/*
+ * Common function to show a splash image if env("splashimage") is set.
+ * Is used for both dm_video and lcd video stacks. For additional
+ * details please refer to doc/README.splashprepare.
+ */
+#if defined(CONFIG_SPLASH_SCREEN)
+int splash_display(void)
 {
+   ulong addr;
+   char *s;
int x = 0, y = 0, ret;
 
+   s = env_get("splashimage");
+   if (!s)
+   return -EINVAL;
+
+   addr = simple_strtoul(s, NULL, 16);
ret = splash_screen_prepare();
if (ret)
return ret;
diff --git a/common/stdio.c b/common/stdio.c
index ee22c1fd58..22de7aa491 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_SYS_I2C)
 #include 
@@ -366,6 +367,9 @@ int stdio_add_devices(void)
if (ret)
printf("%s: Video device failed (ret=%d)\n", __func__, ret);
 #endif /* !CONFIG_SYS_CONSOLE_IS_IN_ENV */
+#ifdef CONFIG_SPLASH_SCREEN
+   splash_display();
+#endif /* CONFIG_SPLASH_SCREEN */
 #else
 # if defined(CONFIG_LCD)
drv_lcd_init ();
diff --git a/include/splash.h b/include/splash.h
index 228aff441b..4ed8d60325 100644
--- a/include/splash.h
+++ b/include/splash.h
@@ -66,10 +66,10 @@ void splash_get_pos(int *x, int *y);
 static inline void splash_get_pos(int *x, int *y) { }
 #endif
 
-#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_LCD)
-int lcd_splash(ulong addr);
+#ifdef CONFIG_SPLASH_SCREEN
+int splash_display(void);
 #else
-static inline int lcd_splash(ulong addr)
+static inline int splash_display(void)
 {
return -ENOSYS;
 }
-- 
2.17.1

___
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

[Jean-Jacques Hiblot]

On 27/05/2019 17:15, Simon Goldschmidt wrote:



Tom Rini mailto:tr...@konsulko.com>> 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
mailto:simon.k.r.goldschm...@gmail.com>>
> >>---
> >>
> >>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...


Yes that is  what I was trying to express.

Below is an draft of what I had in mind. Admittedly it less clear than 
the C file.


JJ



Regrds,
Simon



 Makefile    |  2 +-

 tools/spl_size_limit.py | 51 +
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100755 tools/spl_size_limit.py

diff --git a/Makefile b/Makefile
index 8de3d4120a..440ea1da2d 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,$@,$$(tools/spl_size_limit))
+SPL_SIZE_CHECK = $(call size_check,$@,$$($(src)/tools/spl_size_limit.py 
SPL))

 else
 SPL_SIZE_CHECK =
 endif
diff --git a/tools/spl_size_limit.py b/tools/spl_size_limit.py
new file mode 100755
index 00..2c40f5701e
--- /dev/null
+++ b/tools/spl_size_limit.py
@@ -0,0 +1,51 @@
+#! /usr/bin/env python
+import os
+import sys
+
+binary_types = {"U-BOOT":("","./"), "SPL":("SPL_","spl/"), 
"TPL":("TPL_","tpl/")}

+
+def get_from_file(f, pattern):
+    for l in f.readlines():
+        if l.startswith(pattern):
+            return l[len(pattern):].strip()
+    return None
+
+def get_from_cfg_file(bintype, name):
+    pattern = '#define CONFIG_{}{} '.format(binary_types[bintype][0], name)
+    with open("{}u-boot.cfg".format(binary_types[bintype][1])) as f:
+        return get_from_file(f, pattern)
+
+def get_from_header(fname, name):
+    pattern = '#define {} '.format(name)
+    with open("{}".format(fname)) as f:
+        return get_from_file(f, pattern).split()[0]
+
+def usage():
+    print("usage: {} [SPL|TPL]")
+    sys.exit(1)
+
+if len(sys.argv) != 2 and len(sys.argv) != 1:
+    usage()
+if len(sys.argv) == 2 and sys.argv[1] not in binary_types.keys():
+    usage()
+
+bintype = sys.argv[1]
+
+gbl_data_size = 
int(get_from_header("include/generated/generic-asm-offsets.h",

+                    "GENERATED_GBL_DATA_SIZE"), 0)
+size_limit_subtract_gd = get_from_cfg_file(bintype, 
"SIZE_LIMIT_SUBTRACT_GD")

+size_limit_subtract_malloc = get_from_cfg_file(bintype,
+                       "SIZE_LIMIT_SUBTRACT_MALLOC")
+sys_malloc_f_len = int(get_from_cfg_file(bintype, "SYS_MALLOC_F_LEN"), 0)
+size_limit_provide_stack = get_from_cfg_file(bintype,
+                     "SIZE_LIMIT_PROVIDE_STACK")
+
+size_limit = int(get_from_cfg_file(bintype, "SIZE_LIMIT"), 0)
+if size_limit_subtract_gd:
+    size_limit = size_limit - gbl_data_size
+if size_limit_subtract_malloc:
+    size_limit = size_limit - sys_malloc_f_len
+if size_limit_provide_stack:
+    size_limit = size_limit - int(size_limit_provide_stack, 0)
+
+print(size_limit)
--
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC 1/1] splash: display splash in DM_VIDEO configurations

[Igor Opaniuk]

Currently for CONFIG_DM_VIDEO=y setting splashimage env variable doesn't
have any effect. Introduce a common function for both dm-video/lcd stacks,
that checks env("splashimage") and invokes bmp_display() accordingly.
For additional details please check discussion [1].

[1] https://lists.denx.de/pipermail/u-boot/2019-May/371002.html

Signed-off-by: Igor Opaniuk 
---
 common/lcd.c | 10 +++---
 common/splash.c  | 16 ++--
 common/stdio.c   |  4 
 include/splash.h |  6 +++---
 4 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index 95526b1e17..1c5d8adb47 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -222,14 +222,10 @@ void lcd_clear(void)
/* Paint the logo and retrieve LCD base address */
debug("[LCD] Drawing the logo...\n");
if (do_splash) {
-   s = env_get("splashimage");
-   if (s) {
+   if (splash_show() == 0) {
do_splash = 0;
-   addr = simple_strtoul(s, NULL, 16);
-   if (lcd_splash(addr) == 0) {
-   lcd_sync();
-   return;
-   }
+   lcd_sync();
+   return;
}
}
 
diff --git a/common/splash.c b/common/splash.c
index d251b3b654..f026390393 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -80,11 +80,23 @@ void splash_get_pos(int *x, int *y)
 }
 #endif /* CONFIG_SPLASH_SCREEN_ALIGN */
 
-#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_LCD)
-int lcd_splash(ulong addr)
+/*
+ * Common function to show a splash image if env("splashimage") is set.
+ * Is used for both dm_video and lcd video stacks. For additional
+ * details please refer to doc/README.splashprepare.
+ */
+#if defined(CONFIG_SPLASH_SCREEN)
+int splash_display(void)
 {
+   ulong addr;
+   char *s;
int x = 0, y = 0, ret;
 
+   s = env_get("splashimage");
+   if (!s)
+   return -EINVAL;
+
+   addr = simple_strtoul(s, NULL, 16);
ret = splash_screen_prepare();
if (ret)
return ret;
diff --git a/common/stdio.c b/common/stdio.c
index ee22c1fd58..22de7aa491 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_SYS_I2C)
 #include 
@@ -366,6 +367,9 @@ int stdio_add_devices(void)
if (ret)
printf("%s: Video device failed (ret=%d)\n", __func__, ret);
 #endif /* !CONFIG_SYS_CONSOLE_IS_IN_ENV */
+#ifdef CONFIG_SPLASH_SCREEN
+   splash_display();
+#endif /* CONFIG_SPLASH_SCREEN */
 #else
 # if defined(CONFIG_LCD)
drv_lcd_init ();
diff --git a/include/splash.h b/include/splash.h
index 228aff441b..4ed8d60325 100644
--- a/include/splash.h
+++ b/include/splash.h
@@ -66,10 +66,10 @@ void splash_get_pos(int *x, int *y);
 static inline void splash_get_pos(int *x, int *y) { }
 #endif
 
-#if defined(CONFIG_SPLASH_SCREEN) && defined(CONFIG_LCD)
-int lcd_splash(ulong addr);
+#ifdef CONFIG_SPLASH_SCREEN
+int splash_display(void);
 #else
-static inline int lcd_splash(ulong addr)
+static inline int splash_display(void)
 {
return -ENOSYS;
 }
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] ARM: davinci: SPL: fix BSS initialization

[Adam Ford]

On Mon, May 27, 2019 at 6:46 AM Sekhar Nori  wrote:
>
> 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.

I like this idea.

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

The da850 uses the device tree to get the serial port information, and
someone else just submitted a patch to enable the device tree for the
LCDK.  At least for the da850-evm, we need to initialize the spl stuff
here to fetch the device tree info in order to enable the serial port
for preload_console_init() or it hangs.

I think we should add spl_early_init(); If you don't want it enabled
all the time, we could encapsulate it in an ifdef checking for the
presence of OF_CONTROL, but I think it should be harmless to have it
executed all the time based on my interpretation of the readme file.


> 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

Re: [U-Boot] [PATCH 4/4] davinci: omapl138-lcdk: enable driver-model in SPL

[Adam Ford]

On Tue, May 28, 2019 at 2:58 AM Bartosz Golaszewski  wrote:
>
> From: Bartosz Golaszewski 
>
> Enable CONFIG_SPL_DM and enable the driver model for serial by defining
> an appropriate device in the board file for da850-lcdk.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
>  board/davinci/da8xxevm/omapl138_lcdk.c | 16 
>  configs/omapl138_lcdk_defconfig|  5 +
>  2 files changed, 21 insertions(+)
>
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 156d61d9fb..b20747ba01 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -369,3 +371,17 @@ int board_mmc_init(bd_t *bis)
>  }
>  #endif
>  #endif
> +
> +#ifdef CONFIG_SPL_BUILD
> +static const struct ns16550_platdata serial_pdata = {
> +   .base = DAVINCI_UART2_BASE,
> +   .reg_shift = 2,
> +   .clock = 22800,
> +   .fcr = UART_FCR_DEFVAL,
> +};
> +
> +U_BOOT_DEVICE(omapl138_uart) = {
> +   .name = "ns16550_serial",
> +   .platdata = _pdata,
> +};
> +#endif
> diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
> index b375da50df..f53a51321c 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -33,10 +33,13 @@ CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_DIAG=y
>  CONFIG_CMD_UBI=y
>  CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y

If SPL_OF_CONTROL is being added, why do you need to manually add the
stuff above for the serial port?  Checkout the da850-evm-u-boot.dtsi
file.  I adds the device tree entries for the serial port to appear in
the SPL DTB.

See 
http://git.denx.de/?p=u-boot.git;a=commit;h=f7c1d53605d9ec528abacda9ba1763c67221fc88


>  CONFIG_DEFAULT_DEVICE_TREE="da850-lcdk"
> +CONFIG_SPL_OF_PLATDATA=y
>  CONFIG_ENV_IS_IN_NAND=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DM=y
> +CONFIG_SPL_DM=y
>  CONFIG_DM_I2C=y
>  CONFIG_DM_I2C_COMPAT=y
>  CONFIG_SYS_I2C_DAVINCI=y
> @@ -53,8 +56,10 @@ CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_MII=y
>  CONFIG_DRIVER_TI_EMAC=y
> +CONFIG_SPECIFY_CONSOLE_INDEX=y
>  CONFIG_DM_SERIAL=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_SPI=y
>  CONFIG_DAVINCI_SPI=y
>  CONFIG_USE_TINY_PRINTF=y
> +# CONFIG_SPL_OF_LIBFDT is not set
> --
> 2.21.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rtc: add Microcrystal RV-8803 driver

[Tom Rini]

On Mon, May 27, 2019 at 10:23:21PM +0200, Michael Walle wrote:

> 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

This overall looks fine.  Can you please enable building this in the
sandbox_defconfig as well so we have compilation coverage too?  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

[J. William Campbell]

On 5/28/2019 4:19 AM, Tom Rini wrote:

On Tue, May 28, 2019 at 05:24:34AM +0200, Marek Vasut wrote:

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

Yes, yes it would be worth seeing if other groups that have looked into
the performance impact here have also decided to optimize this undefined
behavior or not, thanks.


I don't think this is an optimization question, really. Calling memcpy 
with overlapping areas is an error. The result is explicitly undefined. 
It may well be that all the existing implementations effectively do 
nothing, either by explicit check or by actually copying the data over 
itself. However, to rely on that behavior is asking for trouble down the 
line. Undefined behavior is exactly that. Don't do it.





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] DM_VIDEO and splash screen functionality

[Igor Opaniuk]

Hi Anatolij,

On Tue, May 28, 2019 at 3:31 PM Anatolij Gustschin  wrote:
>
> Hi Igor,
>
> On Tue, 28 May 2019 13:35:13 +0300
> Igor Opaniuk igor.opan...@gmail.com wrote:
>
> > Hi all,
> >
> > Just a clarifying question:
> > I assume a splash screen functionality from common/splash.c and
> > common/splash_source.c is marked as deprecated and is not going to be
> > used anymore alongside with DM_VIDEO enabled, right?
>
> no, this is still used with DM_VIDEO enabled. This splash image
> loading code is for pre-loading the bitmap (file) from configurable
> storage source before drawing it (see also doc/README.splashprepare).
>
> The bitmap drawing code is currently at 3 different locations,
> depending on the board and/or video driver configuration:
>  common/lcd.c
>  drivers/video/cfb_console.c (!DM_VIDEO)
>  drivers/video/video_bmp.c (DM_VIDEO)

Actually I meant the difference in behavior I'm observing between
DM_VIDEO enabled drivers and legacy ones.
For example, for legacy lcd video stack drawing of boot logo is a part
of initialization process, where
the main condition is a sane value of env("splashimage"):
lcd_init() (common/lcd.c:245) -> lcd_clear() -> lcd_splash() ->
bmp_display(addr, x, y)

Also I'm observing the same behavior for cfb_console (also with the
same check if env("splashimage") is defined):
cfg_video_init(cfb_console.c:2018) -> video_logo() ->video_display_bitmap()

But for DM_VIDEO enabled drivers there is no any signs of invocation
of bmp_display()/other wrappers during
the overall initialization  (I've followed all possible paths starting
from stdio_add_devices()), and probing of
of DM_VIDEO enabled drivers are deferred till I explicitly invoke
something like `bmp` command), so
I assumed that not adding the same check for env("splashimage") and
further bmp_display() invocation was done for
some purpose (for example, to deprecate and remove splash.c
functionality in the future).

>
> We will most probably remove cfb_console when all remaining users
> are converted to DM_VIDEO. lcd.c can co-exist with DM_VIDEO enabled
> drivers and is still used for some boards. Maybe we will drop it as
> well, unless LCD console for older boards with limited resources must
> be supported.
>
> > I understand that the same result can be achieved (showing a boot
> > logo) using CONFIG_PREBOOT define and with an invocation of something
> > like "bmp display " in "preboot" env variable, but just wanted
> > to know if splashscreen legacy stuff (common/splash.c) is going to be
> > somehow integrated into the new video stack in the future.
>
> Yes, you can load the .bmp file to memory first via commands in "preboot"
> and display it with "bmp" command then. But it would be better to
> implement it in common way reusable for other boards and independent
> of "preboot" configuration. We already have the necessary functions
> splash_screen_prepare() and bmp_display(). The first loads the file
> to memory address defined in "splashimage" env variable. This address
> can be passed to bmp_display(). We can add a common function which
> checks "splashimage" and sets it if not defined, then calls prepare/
> display functions. No other integration is required.

Yeah, this was my initial point that it doesn't work now and there is no such
function for DM_VIDEO configurations. I just assumed that following steps from
doc/README.splashprepare, adding CONFIG_SPLASH_SOURCE define
and providing proper values for splashsource/splashimage env vars
should make a deal, but
obviously it doesn't.

I'll send a patch if don't mind.

>
> --
> Anatolij

Thanks for your reply!

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rk3399-puma: Reduce SPL size.

[Christoph Müllner]

On 28.05.19 15:06, Kever Yang wrote:
> Hi Christoph,
> 
>     This patch need re-base upon latest mainline tree.
> 
>     And see below commons.
> 
> 
> 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 
>> ---
>>
>>  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"
> 
> Did you really need to update "interrupt-parent" to "interrupt-parents",
> I think this is a typo?

Correct.
Thanks for the hint, I will rebase and fix.

Thanks,
Christoph

> 
> Thanks,
> - Kever
>>  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] [PATCH] rockchip: Cleanup of make_fit_atf.py.

[Kever Yang]

Hi Christoph,


On 05/07/2019 05:11 PM, Christoph Muellner wrote:
> This patch cleans up make_fit_atf.py in the following way:
>
> * Fix all issues reported by pylint
> * Move copyright notice from file-to-generate to script
> * Fix of-by-one bugs in loadables property
> * Remove commented-out (dead) code.
>
> Besides the bugfix no intended changes.
>
> Tested on RK3399-Q7 with TF-A v2.1 as BL31.
>
> Signed-off-by: Christoph Muellner 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
>  arch/arm/mach-rockchip/make_fit_atf.py | 153 
> ++---
>  1 file changed, 64 insertions(+), 89 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> b/arch/arm/mach-rockchip/make_fit_atf.py
> index d1faff1957..212bd0a854 100755
> --- a/arch/arm/mach-rockchip/make_fit_atf.py
> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> @@ -1,10 +1,12 @@
>  #!/usr/bin/env python
>  """
> -A script to generate FIT image source for rockchip boards
> -with ARM Trusted Firmware
> -and multiple device trees (given on the command line)
> -
> -usage: $0  [ [ +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# A script to generate FIT image source for rockchip boards
> +# with ARM Trusted Firmware
> +# and multiple device trees (given on the command line)
> +#
> +# usage: $0  [ [  """
>  
>  import os
> @@ -14,26 +16,27 @@ import getopt
>  # pip install pyelftools
>  from elftools.elf.elffile import ELFFile
>  
> -ELF_SEG_P_TYPE='p_type'
> -ELF_SEG_P_PADDR='p_paddr'
> -ELF_SEG_P_VADDR='p_vaddr'
> -ELF_SEG_P_OFFSET='p_offset'
> -ELF_SEG_P_FILESZ='p_filesz'
> -ELF_SEG_P_MEMSZ='p_memsz'
> +ELF_SEG_P_TYPE = 'p_type'
> +ELF_SEG_P_PADDR = 'p_paddr'
> +ELF_SEG_P_VADDR = 'p_vaddr'
> +ELF_SEG_P_OFFSET = 'p_offset'
> +ELF_SEG_P_FILESZ = 'p_filesz'
> +ELF_SEG_P_MEMSZ = 'p_memsz'
>  
> -DT_HEADER="""// SPDX-License-Identifier: GPL-2.0+ OR X11
> +DT_HEADER = """
>  /*
> - * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> - *
> - * Minimal dts for a SPL FIT image payload.
> + * This is a generated file.
>   */
>  /dts-v1/;
>  
>  / {
> - description = "Configuration to load ATF before U-Boot";
> + description = "FIT image for U-Boot with bl31 (TF-A)";
>   #address-cells = <1>;
>  
>   images {
> +"""
> +
> +DT_UBOOT = """
>   uboot {
>   description = "U-Boot (64-bit)";
>   data = /incbin/("u-boot-nodtb.bin");
> @@ -46,18 +49,14 @@ DT_HEADER="""// SPDX-License-Identifier: GPL-2.0+ OR X11
>  
>  """
>  
> -DT_IMAGES_NODE_END="""
> -};
> -"""
> +DT_IMAGES_NODE_END = """ };
>  
> -DT_END="""
> -};
>  """
>  
> -def append_atf_node(file, atf_index, phy_addr, elf_entry):
> -"""
> -Append ATF DT node to input FIT dts file.
> -"""
> +DT_END = "};"
> +
> +def append_bl31_node(file, atf_index, phy_addr, elf_entry):
> +# Append BL31 DT node to input FIT dts file.
>  data = 'bl31_0x%08x.bin' % phy_addr
>  file.write('\t\tatf_%d {\n' % atf_index)
>  file.write('\t\t\tdescription = \"ARM Trusted Firmware\";\n')
> @@ -73,9 +72,7 @@ def append_atf_node(file, atf_index, phy_addr, elf_entry):
>  file.write('\n')
>  
>  def append_fdt_node(file, dtbs):
> -"""
> -Append FDT nodes.
> -"""
> +# Append FDT nodes.
>  cnt = 1
>  for dtb in dtbs:
>  dtname = os.path.basename(dtb)
> @@ -88,14 +85,14 @@ def append_fdt_node(file, dtbs):
>  file.write('\n')
>  cnt = cnt + 1
>  
> -def append_conf_section(file, cnt, dtname, atf_cnt):
> +def append_conf_section(file, cnt, dtname, segments):
>  file.write('\t\tconfig_%d {\n' % cnt)
>  file.write('\t\t\tdescription = "%s";\n' % dtname)
>  file.write('\t\t\tfirmware = "atf_1";\n')
>  file.write('\t\t\tloadables = "uboot",')
> -for i in range(1, atf_cnt):
> -file.write('"atf_%d"' % (i+1))
> -if i != (atf_cnt - 1):
> +for i in range(1, segments):
> +file.write('"atf_%d"' % (i))
> +if i != (segments - 1):
>  file.write(',')
>  else:
>  file.write(';\n')
> @@ -103,57 +100,58 @@ def append_conf_section(file, cnt, dtname, atf_cnt):
>  file.write('\t\t};\n')
>  file.write('\n')
>  
> -def append_conf_node(file, dtbs, atf_cnt):
> -"""
> -Append configeration nodes.
> -"""
> +def append_conf_node(file, dtbs, segments):
> +# Append configeration nodes.
>  cnt = 1
>  file.write('\tconfigurations {\n')
>  file.write('\t\tdefault = "config_1";\n')
>  for dtb in dtbs:
>  dtname = os.path.basename(dtb)
> -append_conf_section(file, cnt, dtname, atf_cnt)
> +append_conf_section(file, cnt, dtname, segments)
>  cnt = cnt + 1
>  file.write('\t};\n')
>  file.write('\n')
>  
> -def generate_atf_fit_dts(fit_file_name, bl31_file_name, uboot_file_name, 
> dtbs_file_name):
> -"""
> -Generate FIT script for ATF image.
> -"""
> -if fit_file_name != sys.stdout:
> -fit_file = 

Re: [U-Boot] [PATCH] rockchip: rk3399-puma: Re-disable SPL_ATF_NO_PLATFORM_PARAM

[Christoph Müllner]

On 28.05.19 14:55, Kever Yang wrote:
> Hi Christoph and Mark,
> 
>     Does this patch ready for rk3399-puma?

Hi Kever,

yes, this commit is ready for mainline.
However, there are more (not Puma specific) commits needed to make get
mainline ATF working. I haven't got time recently to work on them.

If you want we can wait for the complete series.
But, as I said, the commit is ready for mainline now and
would just be merged later.

Thanks,
Christoph

> 
> 
> Thanks,
> - Kever
> On 05/07/2019 05:18 PM, Christoph Müllner wrote:
>> Hi Mark,
>>
>> On 07.05.19 10:57, Mark Kettenis wrote:
 From: Christoph Muellner 
 Date: Tue,  7 May 2019 10:39:54 +0200

 This reverts commit c869d63f2785ccde22582f96cf40cb8809f838ba.

 Mainline ATF already supports fdt-parsing, which allows us to
 pass rk3399-puma specific data to setup things like the correct
 UART. Therefore we can re-enable platform parameterss again.
>>> Hi Christoph,
>>>
>>> I tried this last weekend on my rk3399-puma board with the (then)
>>> latest ATF and that didn't work for me.  Looked like the board simply
>>> reset shortly after jumping into the ATF code.  Now I may very well
>>> have done something wrong, and I ran out of time debugging this.
>> There's a lot more needed to get mainline ATF up and running on RK3399:
>>
>> * Only mainline ATF will be able to use correct console (UART0)
>> * bouncebuf needs to be aware of SD DMA not being able to copy to 
>> SRAM/PMUSRAM
>> * bouncebuf needs static buffer to address heap limitation
>> * bugfix in ITS generatorscript
>>
>> I've already addressed all issues for SD card boot (Fedora boots fine).
>>
>> If you want to test, you can use my ATF tree:
>>
>> https://git.theobroma-systems.com/puma-u-boot.git/log/?h=puma-v2019.04-atf
>>
>> Status for booting from SPI NOR is, that ATF will be branched to,
>> but then the board hangs. However, I haven't analyzed the situation
>> in detail yet.
>>
>> BR
>> Christoph
>>
>>> Cheers,
>>>
>>> Mark
>>>
  configs/puma-rk3399_defconfig | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
 index 964464ac0f..f4c5168011 100644
 --- a/configs/puma-rk3399_defconfig
 +++ b/configs/puma-rk3399_defconfig
 @@ -33,7 +33,6 @@ CONFIG_SPL_I2C_SUPPORT=y
  CONFIG_SPL_POWER_SUPPORT=y
  CONFIG_SPL_SPI_LOAD=y
  CONFIG_SPL_ATF=y
 -CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
  CONFIG_CMD_BOOTZ=y
  CONFIG_CMD_GPT=y
  CONFIG_CMD_I2C=y
 -- 
 2.11.0

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 https://lists.denx.de/listinfo/u-boot
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rk3399-puma: Reduce SPL size.

[Kever Yang]

Hi Christoph,

    This patch need re-base upon latest mainline tree.

    And see below commons.


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

Did you really need to update "interrupt-parent" to "interrupt-parents",
I think this is a typo?

Thanks,
- Kever
>  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] [PATCH] rockchip: rk3399-puma: Re-disable SPL_ATF_NO_PLATFORM_PARAM

[Kever Yang]

Hi Christoph and Mark,

    Does this patch ready for rk3399-puma?


Thanks,
- Kever
On 05/07/2019 05:18 PM, Christoph Müllner wrote:
> Hi Mark,
>
> On 07.05.19 10:57, Mark Kettenis wrote:
>>> From: Christoph Muellner 
>>> Date: Tue,  7 May 2019 10:39:54 +0200
>>>
>>> This reverts commit c869d63f2785ccde22582f96cf40cb8809f838ba.
>>>
>>> Mainline ATF already supports fdt-parsing, which allows us to
>>> pass rk3399-puma specific data to setup things like the correct
>>> UART. Therefore we can re-enable platform parameterss again.
>> Hi Christoph,
>>
>> I tried this last weekend on my rk3399-puma board with the (then)
>> latest ATF and that didn't work for me.  Looked like the board simply
>> reset shortly after jumping into the ATF code.  Now I may very well
>> have done something wrong, and I ran out of time debugging this.
> There's a lot more needed to get mainline ATF up and running on RK3399:
>
> * Only mainline ATF will be able to use correct console (UART0)
> * bouncebuf needs to be aware of SD DMA not being able to copy to SRAM/PMUSRAM
> * bouncebuf needs static buffer to address heap limitation
> * bugfix in ITS generatorscript
>
> I've already addressed all issues for SD card boot (Fedora boots fine).
>
> If you want to test, you can use my ATF tree:
>
> https://git.theobroma-systems.com/puma-u-boot.git/log/?h=puma-v2019.04-atf
>
> Status for booting from SPI NOR is, that ATF will be branched to,
> but then the board hangs. However, I haven't analyzed the situation
> in detail yet.
>
> BR
> Christoph
>
>> Cheers,
>>
>> Mark
>>
>>>  configs/puma-rk3399_defconfig | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
>>> index 964464ac0f..f4c5168011 100644
>>> --- a/configs/puma-rk3399_defconfig
>>> +++ b/configs/puma-rk3399_defconfig
>>> @@ -33,7 +33,6 @@ CONFIG_SPL_I2C_SUPPORT=y
>>>  CONFIG_SPL_POWER_SUPPORT=y
>>>  CONFIG_SPL_SPI_LOAD=y
>>>  CONFIG_SPL_ATF=y
>>> -CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
>>>  CONFIG_CMD_BOOTZ=y
>>>  CONFIG_CMD_GPT=y
>>>  CONFIG_CMD_I2C=y
>>> -- 
>>> 2.11.0
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rk3399-puma: Move ENV_OFFSET to end of SPI NOR.

[Kever Yang]

Hi Christoph,


On 05/07/2019 04:37 PM, Christoph Muellner wrote:
> Puma SoMs have a 4 MB SPI NOR flash.
> Therefore we can move the environment to the end of the flash
> (4 MiB - 16 kiB) in order to not overlap with SPL.
>
> Reported-by: Jakob Unterwurzacher 
> Signed-off-by: Christoph Muellner 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
>  board/theobroma-systems/puma_rk3399/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/theobroma-systems/puma_rk3399/Kconfig 
> b/board/theobroma-systems/puma_rk3399/Kconfig
> index 8a94cbd9ed..9e23252754 100644
> --- a/board/theobroma-systems/puma_rk3399/Kconfig
> +++ b/board/theobroma-systems/puma_rk3399/Kconfig
> @@ -16,6 +16,6 @@ config ENV_SIZE
>   default 0x2000
>  
>  config ENV_OFFSET
> - default 0x3c000 if ENV_IS_IN_SPI_FLASH
> + default 0x3fc000 if ENV_IS_IN_SPI_FLASH
>  
>  endif



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] DM_VIDEO and splash screen functionality

[Anatolij Gustschin]

Hi Igor,

On Tue, 28 May 2019 13:35:13 +0300
Igor Opaniuk igor.opan...@gmail.com wrote:

> Hi all,
> 
> Just a clarifying question:
> I assume a splash screen functionality from common/splash.c and
> common/splash_source.c is marked as deprecated and is not going to be
> used anymore alongside with DM_VIDEO enabled, right?

no, this is still used with DM_VIDEO enabled. This splash image
loading code is for pre-loading the bitmap (file) from configurable
storage source before drawing it (see also doc/README.splashprepare).

The bitmap drawing code is currently at 3 different locations,
depending on the board and/or video driver configuration:
 common/lcd.c
 drivers/video/cfb_console.c (!DM_VIDEO)
 drivers/video/video_bmp.c (DM_VIDEO)

We will most probably remove cfb_console when all remaining users
are converted to DM_VIDEO. lcd.c can co-exist with DM_VIDEO enabled
drivers and is still used for some boards. Maybe we will drop it as
well, unless LCD console for older boards with limited resources must
be supported.

> I understand that the same result can be achieved (showing a boot
> logo) using CONFIG_PREBOOT define and with an invocation of something
> like "bmp display " in "preboot" env variable, but just wanted
> to know if splashscreen legacy stuff (common/splash.c) is going to be
> somehow integrated into the new video stack in the future.

Yes, you can load the .bmp file to memory first via commands in "preboot"
and display it with "bmp" command then. But it would be better to
implement it in common way reusable for other boards and independent
of "preboot" configuration. We already have the necessary functions
splash_screen_prepare() and bmp_display(). The first loads the file
to memory address defined in "splashimage" env variable. This address
can be passed to bmp_display(). We can add a common function which
checks "splashimage" and sets it if not defined, then calls prepare/
display functions. No other integration is required.

--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] arm, imx, Makefile: fix u-boot-dtb.imx build in CONFIG_MULTI_DTB_FIT case

[Heiko Schocher]

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.

Signed-off-by: Heiko Schocher 
---
clean travis build, see:
https://travis-ci.org/hsdenx/u-boot-test/builds/537359339

Changes in v2:
- reworded commit subject and commit message
  as Fabio recommended

 Makefile   |  4 
 arch/arm/mach-imx/Makefile | 11 ++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 059978bfe6..8c05e5cff1 100644
--- a/Makefile
+++ b/Makefile
@@ -1077,6 +1077,10 @@ endif
 
 u-boot.bin: u-boot-fit-dtb.bin FORCE
$(call if_changed,copy)
+
+u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
+   $(call if_changed,cat)
+
 else ifeq ($(CONFIG_OF_SEPARATE),y)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 37675d0558..3a65bd5b28 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -126,7 +126,16 @@ u-boot.imx: u-boot.bin u-boot.cfgout $(PLUGIN).bin FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
 
-ifeq ($(CONFIG_OF_SEPARATE),y)
+ifeq ($(CONFIG_MULTI_DTB_FIT),y)
+MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \
+   -T $(IMAGE_TYPE) -e $(CONFIG_SYS_TEXT_BASE)
+u-boot-dtb.imx: MKIMAGEOUTPUT = u-boot-dtb.imx.log
+
+u-boot-dtb.imx: u-boot-fit-dtb.bin u-boot-dtb.cfgout $(PLUGIN).bin FORCE
+ifeq ($(DEPFILE_EXISTS),0)
+   $(call if_changed,mkimage)
+endif
+else ifeq ($(CONFIG_OF_SEPARATE),y)
 MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \
-T $(IMAGE_TYPE) -e $(CONFIG_SYS_TEXT_BASE)
 u-boot-dtb.imx: MKIMAGEOUTPUT = u-boot-dtb.imx.log
-- 
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

[Fabio Estevam]

Hi Heiko,

On Tue, May 28, 2019 at 1:39 AM Heiko Schocher  wrote:

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

Yes, much clearer now, thanks :-)
___
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

[Tom Rini]

On Tue, May 28, 2019 at 05:24:34AM +0200, Marek Vasut wrote:
> 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

Yes, yes it would be worth seeing if other groups that have looked into
the performance impact here have also decided to optimize this undefined
behavior 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

[U-Boot] [PATCH] boards: amlogic-g200: remove phy reset

[Neil Armstrong]

The PHY reset is now handled by the MAC driver, remove this leftover.

Signed-off-by: Neil Armstrong 
---
 board/amlogic/q200/q200.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/board/amlogic/q200/q200.c b/board/amlogic/q200/q200.c
index 1932c14aa2..2ea97c362e 100644
--- a/board/amlogic/q200/q200.c
+++ b/board/amlogic/q200/q200.c
@@ -26,12 +26,6 @@ int misc_init_r(void)
 
meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
 
-   /* Reset PHY on GPIOZ_14 */
-   clrbits_le32(GX_GPIO_EN(3), BIT(14));
-   clrbits_le32(GX_GPIO_OUT(3), BIT(14));
-   mdelay(10);
-   setbits_le32(GX_GPIO_OUT(3), BIT(14));
-
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
  mac_addr, EFUSE_MAC_SIZE);
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: meson-gx: Reset GXL/GXM to external PHY when not using internal PHY

[Neil Armstrong]

When using External PHY, reset the mux to use the external PHY in case U-Boot
was chainloaded from a misconfigured bootloader.

Fixes: 33e3378091 ("ARM: meson: rework soc arch file to prepare for new SoC")
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-meson/board-gx.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-meson/board-gx.c b/arch/arm/mach-meson/board-gx.c
index e41552db52..2b0614b79b 100644
--- a/arch/arm/mach-meson/board-gx.c
+++ b/arch/arm/mach-meson/board-gx.c
@@ -112,6 +112,11 @@ void meson_eth_init(phy_interface_t mode, unsigned int 
flags)
 GX_ETH_REG_0_TX_RATIO(4) |
 GX_ETH_REG_0_PHY_CLK_EN |
 GX_ETH_REG_0_CLK_EN);
+
+   /* Reset to external PHY */
+   if(!IS_ENABLED(CONFIG_MESON_GXBB))
+   writel(0x2009087f, GX_ETH_REG_3);
+
break;
 
case PHY_INTERFACE_MODE_RMII:
@@ -119,11 +124,13 @@ void meson_eth_init(phy_interface_t mode, unsigned int 
flags)
out_le32(GX_ETH_REG_0, GX_ETH_REG_0_INVERT_RMII_CLK |
 GX_ETH_REG_0_CLK_EN);
 
-   /* Use GXL RMII Internal PHY */
-   if (IS_ENABLED(CONFIG_MESON_GXL) &&
-   (flags & MESON_USE_INTERNAL_RMII_PHY)) {
-   writel(0x10110181, GX_ETH_REG_2);
-   writel(0xe40908ff, GX_ETH_REG_3);
+   /* Use GXL RMII Internal PHY (also on GXM) */
+   if (!IS_ENABLED(CONFIG_MESON_GXBB)) {
+   if ((flags & MESON_USE_INTERNAL_RMII_PHY)) {
+   writel(0x10110181, GX_ETH_REG_2);
+   writel(0xe40908ff, GX_ETH_REG_3);
+   } else
+   writel(0x2009087f, GX_ETH_REG_3);
}
 
break;
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Greentime Hu]

Hi Bin,
On Tue, May 28, 2019 at 05:58:47PM +0800, Bin Meng wrote:
> Hi Greentime,
> 
> On Tue, May 28, 2019 at 3:54 PM Greentime Hu  wrote:
> >
> > Hi Bin,
> > On Fri, May 24, 2019 at 05:40:08PM +0800, Bin Meng wrote:
> > > Hi Eric,
> > >
> > > On Fri, May 24, 2019 at 4:04 PM Eric Lin  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > Bin Meng  ??? 2019???5???22??? ?? 
> > > > ??5:25?
> > > > >
> > > > > Hi Eric,
> > > > >
> > > > > On Wed, May 22, 2019 at 4:23 PM  wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > > > > > To: Eric Te-Sheng Lin(?)
> > > > > > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi 
> > > > > > > Chen(?);
> > > > > > > Greentime Ying-Han Hu(?); dslin1...@gmail.com
> > > > > > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D 
> > > > > > > ISA extensions
> > > > > > > support
> > > > > > >
> > > > > > > Hi Eric,
> > > > > > >
> > > > > > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > This patch add Kconfig entries for the F (Single-Precision)
> > > > > > >
> > > > > > > adds
> > > > > > >
> > > > > >
> > > > > > OK I'll correct it as adds
> > > > > >
> > > > > > > > and D (Double-Precision) floating point instruction-set 
> > > > > > > > extensions.
> > > > > > > >
> > > > > > >
> > > > > > > Could you please provide reason that why U-Boot has to be 
> > > > > > > compiled using F/D
> > > > > > > extension?
> > > > > > >
> > > > > >
> > > > > > Cause on AE350 platform, we have two different kinds of toolchain 
> > > > > > v5d (support I/M/A/C/F/D ISA) and
> > > > > > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build 
> > > > > > U-Boot it will build fail, so we would like to add F/D extension on 
> > > > > > U-Boot.
> > > > >
> > > > > I don't understand. What difference do these two toochains have? Isn't
> > > > > the v5d toolchain's default -march string be pre-configured to imafd?
> > > > > But even if the toolchain is pre-configured to generate fd
> > > > > instruction, I think it can be override by the compiler flags. Can you
> > > > > please share the details of the toolchain you used? I suspect you have
> > > > > to fix your toolchain, not U-Boot.
> > > > >
> > > >
> > > > It's seems the ABI issue. Because our toolchain don't support
> > > > multilib, the v5d toolchain libraries ABI is ilp64d.
> > > > If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
> > > > get link error as below:
> > >
> > > Then please fix your compiler. Passing -mabi=lp64 to compiler is
> > > definitely correct.
> >
> >  One of our customer ever used floating point in their project. They want
> >  to calculate something with floating point instructions in u-Boot before
> >  entering kernel.
> 
> This is a new use case. For other architectures like x86, we don't
> allow U-Boot to be compiled using hardware float ABI. Why can't they
> use software floating point instead?

It's because they'd like to calculate something very quickly. It may just be
done in few cycles with floating point instructions and it will be very useful
for their usages instead of using soft-float.

That's the reason they ask us to provide such kind of CONFIG and we think it
might also be helpful for users who are trying to do some mathematics with
floating point instructions in u-Boot.

Thanks. :)

> >
> >  IMHO, we may consider this case for user to use -mabi=ilp64d.
> >  This CONFIG will be useful for them to compile their codes and linking 
> > together
> >  with u-Boot.
> >
> >  Thanks :)
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] pwm: imx: add Kconfig support

[Martyn Welch]

On Tue, 2019-05-28 at 06:51 +0200, Heiko Schocher wrote:
> add Kconfig support for this driver.
> 
> Signed-off-by: Heiko Schocher 

Acked-by: Martyn Welch 

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

Re: [U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Greentime Hu]

Hi Bin,
On Fri, May 24, 2019 at 05:40:08PM +0800, Bin Meng wrote:
> Hi Eric,
> 
> On Fri, May 24, 2019 at 4:04 PM Eric Lin  wrote:
> >
> > Hi Bin
> >
> > Bin Meng  ??? 2019???5???22??? ?? 
> > ??5:25?
> > >
> > > Hi Eric,
> > >
> > > On Wed, May 22, 2019 at 4:23 PM  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > > -Original Message-
> > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > > > To: Eric Te-Sheng Lin(?)
> > > > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi 
> > > > > Chen(?);
> > > > > Greentime Ying-Han Hu(?); dslin1...@gmail.com
> > > > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D ISA 
> > > > > extensions
> > > > > support
> > > > >
> > > > > Hi Eric,
> > > > >
> > > > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  
> > > > > wrote:
> > > > > >
> > > > > > This patch add Kconfig entries for the F (Single-Precision)
> > > > >
> > > > > adds
> > > > >
> > > >
> > > > OK I'll correct it as adds
> > > >
> > > > > > and D (Double-Precision) floating point instruction-set extensions.
> > > > > >
> > > > >
> > > > > Could you please provide reason that why U-Boot has to be compiled 
> > > > > using F/D
> > > > > extension?
> > > > >
> > > >
> > > > Cause on AE350 platform, we have two different kinds of toolchain v5d 
> > > > (support I/M/A/C/F/D ISA) and
> > > > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build U-Boot 
> > > > it will build fail, so we would like to add F/D extension on U-Boot.
> > >
> > > I don't understand. What difference do these two toochains have? Isn't
> > > the v5d toolchain's default -march string be pre-configured to imafd?
> > > But even if the toolchain is pre-configured to generate fd
> > > instruction, I think it can be override by the compiler flags. Can you
> > > please share the details of the toolchain you used? I suspect you have
> > > to fix your toolchain, not U-Boot.
> > >
> >
> > It's seems the ABI issue. Because our toolchain don't support
> > multilib, the v5d toolchain libraries ABI is ilp64d.
> > If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
> > get link error as below:
> 
> Then please fix your compiler. Passing -mabi=lp64 to compiler is
> definitely correct.

 One of our customer ever used floating point in their project. They want
 to calculate something with floating point instructions in u-Boot before
 entering kernel.

 IMHO, we may consider this case for user to use -mabi=ilp64d.
 This CONFIG will be useful for them to compile their codes and linking together
 with u-Boot.

 Thanks :)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] DM_VIDEO and splash screen functionality

[Igor Opaniuk]

Hi all,

Just a clarifying question:
I assume a splash screen functionality from common/splash.c and
common/splash_source.c is marked as deprecated and is not going to be
used anymore alongside with DM_VIDEO enabled, right?

I understand that the same result can be achieved (showing a boot
logo) using CONFIG_PREBOOT define and with an invocation of something
like "bmp display " in "preboot" env variable, but just wanted
to know if splashscreen legacy stuff (common/splash.c) is going to be
somehow integrated into the new video stack in the future.

Thanks!

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
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

[Igor Opaniuk]

On Mon, May 27, 2019 at 5:58 PM Tom Rini  wrote:
>
> 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

Stefan, Anatolij, Tom,

Thanks a lot for your input!

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] armv8/fsl-layerscape: Add loop to check L3 dcache status

[Meenakshi Aggarwal]

Flushing L3 cache may need variable time depending upon cache line
allocation.

Coming up with a proper timeout value would be best handled by
simulations under multiple scenarios in your actual system.
From the purely HN-F point of view, the flush would take ~15 cycles for
a clean line, and ~22 cycles for a dirty line.  For the dirty line case,
there are many variables outside the HN-F that will increase the
duration per line.  For example, a *DBIDResp from the SN-F/SBSX,
memory controller latency, SN-F/SBSX RetryAck responses, CCN ring
congestion, CCN ring hops, etc, etc.  The worst-case timeout would
have to factor in all of these variables plus the HN-F cycles for
every line in the L3, and assuming all lines are dirty

In case if L3 is not flushed properly, system behaviour will be
erratic, so remove timeout and add loop to check status of L3 cache.

System will stuck in while loop if there is some issue in L3 cache
flushing.

Signed-off-by: Udit Kumar 
Signed-off-by: Meenakshi Aggarwal 

---
changed for v2:
- An increase in timeout doesn't ensure completion of
  L3 cache flushing operation. So checking the L3 cache
  status till it succedd.

changed for v3:
- Updated Copyright
- add loop to poll for l3 dcache status in hnf_pstate_poll
  function
- removed timeout related code as it is not needed
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 30 
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 6721a57..711ab87 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * (C) Copyright 2014-2015 Freescale Semiconductor
+ * Copyright 2019 NXP
  *
  * Extracted from armv8/start.S
  */
@@ -356,31 +357,22 @@ get_svr:
 
 #if defined(CONFIG_SYS_FSL_HAS_CCN504) || defined(CONFIG_SYS_FSL_HAS_CCN508)
 hnf_pstate_poll:
-   /* x0 has the desired status, return 0 for success, 1 for timeout
-* clobber x1, x2, x3, x4, x6, x7
+   /* x0 has the desired status, return only if operation succeed
+* clobber x1, x2, x6
 */
mov x1, x0
-   mov x7, #0  /* flag for timeout */
-   mrs x3, cntpct_el0  /* read timer */
-   add x3, x3, #1200   /* timeout after 100 microseconds */
+   mov w6, #8  /* HN-F node count */
mov x0, #0x18
movkx0, #0x420, lsl #16 /* HNF0_PSTATE_STATUS */
-   mov w6, #8  /* HN-F node count */
 1:
ldr x2, [x0]
cmp x2, x1  /* check status */
b.eq2f
-   mrs x4, cntpct_el0
-   cmp x4, x3
-   b.ls1b
-   mov x7, #1  /* timeout */
-   b   3f
+   b   1b
 2:
add x0, x0, #0x1/* move to next node */
subsw6, w6, #1
cbnzw6, 1b
-3:
-   mov x0, x7
ret
 
 hnf_set_pstate:
@@ -405,10 +397,8 @@ ENTRY(__asm_flush_l3_dcache)
/*
 * Return status in x0
 *success 0
-*timeout 1 for setting SFONLY, 2 for FAM, 3 for both
 */
mov x29, lr
-   mov x8, #0
 
dsb sy
mov x0, #0x1/* HNFPSTAT_SFONLY */
@@ -416,19 +406,15 @@ ENTRY(__asm_flush_l3_dcache)
 
mov x0, #0x4/* SFONLY status */
bl  hnf_pstate_poll
-   cbz x0, 1f
-   mov x8, #1  /* timeout */
-1:
+
dsb sy
mov x0, #0x3/* HNFPSTAT_FAM */
bl  hnf_set_pstate
 
mov x0, #0xc/* FAM status */
bl  hnf_pstate_poll
-   cbz x0, 1f
-   add x8, x8, #0x2
-1:
-   mov x0, x8
+
+   mov x0, #0
mov lr, x29
ret
 ENDPROC(__asm_flush_l3_dcache)
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4] riscv: Add Microchip MPFS Icicle board support

[Padmarao Begari]

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 
Reviewed-by: Bin Meng 
---
Changes in V4
- Remove CONFIG_DISTRO_DEFAULTS from microchip_mpfs_icicle_defconfig

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   |  8 
 include/configs/microchip_mpfs_icicle.h   | 63 +++
 7 files changed, 145 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 0d04d91..8cfc7d0 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"
 
@@ -48,6 +51,7 @@ config SPL_SYS_DCACHE_OFF
 # 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 Technology Inc.
+ * Padmarao Begari 
+ */
+
+#include 
+#include 
+#include 
+
+#define MPFS_SYSREG_SOFT_RESET ((unsigned int *)0x20002088)
+
+int board_init(void)
+{
+   /* For now nothing to do here. */
+
+   return 0;
+}
+
+int board_early_init_f(void)
+{
+   unsigned int val;
+
+   /* Reset uart peripheral */
+   val = readl(MPFS_SYSREG_SOFT_RESET);
+   val = (val & ~(1u << 5u));
+   writel(val, MPFS_SYSREG_SOFT_RESET);
+
+   return 0;
+}
diff --git a/configs/microchip_mpfs_icicle_defconfig 
b/configs/microchip_mpfs_icicle_defconfig
new file mode 100644
index 000..a375546
--- /dev/null
+++ b/configs/microchip_mpfs_icicle_defconfig
@@ -0,0 +1,8 @@
+CONFIG_RISCV=y
+CONFIG_ARCH_RV64I=y
+CONFIG_NR_CPUS=5
+CONFIG_TARGET_MICROCHIP_ICICLE=y
+CONFIG_BOOTDELAY=3
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_FIT=y

[U-Boot] [PATCH 1/1] efi_loader: bootmgr: print a message when loading from BootNext failed

[Heinrich Schuchardt]

From: AKASHI Takahiro 

If a user defines BootNext but not BootOrder and loading from BootNext
fails, you will see only a message like this:
BootOrder not defined

This may confuse a user. Adding an error message will be helpful.

Signed-off-by: AKASHI Takahiro 

Adjust message for fallback from BootNext to BootOrder.

An example output looks like this:

=> bootefi bootmgr
Loading from Boot0010 failed
Loading from BootNext failed, falling back to BootOrder
Loading from Boot0002 failed
Loading from Boot0003 failed
Loading from Boot0004 failed
EFI boot manager: Cannot load any image

Reviewed-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_bootmgr.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 7bf51874c1..00de8165d0 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -149,8 +149,10 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t 
*handle)

ret = EFI_CALL(efi_load_image(true, efi_root, lo.file_path,
  NULL, 0, handle));
-   if (ret != EFI_SUCCESS)
+   if (ret != EFI_SUCCESS) {
+   printf("Loading from Boot%04X failed\n", n);
goto error;
+   }

attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
 EFI_VARIABLE_RUNTIME_ACCESS;
@@ -215,6 +217,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
ret = try_load_entry(bootnext, handle);
if (ret == EFI_SUCCESS)
return ret;
+   printf("Loading from BootNext failed, falling 
back to BootOrder\n");
}
} else {
printf("Deleting BootNext failed\n");
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc3: Handle case where setup_phy is not needed

[Siva Durga Prasad Paladugu]

Hi,

> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Monday, April 1, 2019 4:10 PM
> To: Siva Durga Prasad Paladugu ; Lukasz Majewski
> 
> Cc: u-boot@lists.denx.de; ma...@denx.de; jjhib...@ti.com;
> s...@chromium.org; patrick.delau...@st.com
> Subject: Re: [PATCH] usb: dwc3: Handle case where setup_phy is not needed
> 
> On 01. 04. 19 12:38, Siva Durga Prasad Paladugu wrote:
> > Hi Lukasz,
> >
> >> -Original Message-
> >> From: Lukasz Majewski [mailto:lu...@denx.de]
> >> Sent: Monday, April 01, 2019 4:04 PM
> >> To: Siva Durga Prasad Paladugu 
> >> Cc: u-boot@lists.denx.de; ma...@denx.de; jjhib...@ti.com;
> >> s...@chromium.org; patrick.delau...@st.com; Michal Simek
> >> 
> >> Subject: Re: [PATCH] usb: dwc3: Handle case where setup_phy is not
> >> needed
> >>
> >> On Mon, 1 Apr 2019 10:23:42 +
> >> Siva Durga Prasad Paladugu  wrote:
> >>
> >>> Hi Lukasz,
> >>>
>  -Original Message-
>  From: Lukasz Majewski [mailto:lu...@denx.de]
>  Sent: Monday, April 01, 2019 1:03 PM
>  To: Siva Durga Prasad Paladugu 
>  Cc: u-boot@lists.denx.de; ma...@denx.de; jjhib...@ti.com;
>  s...@chromium.org; patrick.delau...@st.com; Michal Simek
>  
>  Subject: Re: [PATCH] usb: dwc3: Handle case where setup_phy is not
>  needed
> 
>  Hi Siva Durga Prasad Paladugu,
> 
> > If CONFIG_PHY is not enabled then the dwc3_setup_phy() returns
> > ENOTSUPP which can be still valid and intentional
>  ^^^ - could
>  you elaborate on this a bit more?
> 
>  What is the use case when -ENOTSUPP is valid and intentional ?
> >>>
> >>> In the cases where phy will be setup by First stage boot loader
> >>> itself and don't want to do it again at u-boot.
> >>
> >> I think that I saw some time ago similar patch for uart - on IMX IIRC
> >> (it was also setup by BootROM on SoC).
> >>
> >> Maybe we would need some kind of switch in Kconfig to indicate this
> >> use case?
> >>
> >> Another option would be to mark this in DTS as TI specific property?
> >>
> >> My point is that we shall not proceed with the flow when we do
> >> receive - ENOTSUPP
> >
> > TBH, I feel we should not call dwc3_setup_phy() if CONFIG_PHY is not
> > enabled. If we look at dwc3_setup_phy() definition, it is under
> CONFIG_PHY.
> 
> +1 on this.

Any update on this patch?

Thanks,
Siva

> 
> M

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Bin Meng]

Hi Greentime,

On Tue, May 28, 2019 at 3:54 PM Greentime Hu  wrote:
>
> Hi Bin,
> On Fri, May 24, 2019 at 05:40:08PM +0800, Bin Meng wrote:
> > Hi Eric,
> >
> > On Fri, May 24, 2019 at 4:04 PM Eric Lin  wrote:
> > >
> > > Hi Bin
> > >
> > > Bin Meng  ??? 2019???5???22??? ?? 
> > > ??5:25?
> > > >
> > > > Hi Eric,
> > > >
> > > > On Wed, May 22, 2019 at 4:23 PM  wrote:
> > > > >
> > > > > Hi Bin,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > > > > To: Eric Te-Sheng Lin(?)
> > > > > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi 
> > > > > > Chen(?);
> > > > > > Greentime Ying-Han Hu(?); dslin1...@gmail.com
> > > > > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D ISA 
> > > > > > extensions
> > > > > > support
> > > > > >
> > > > > > Hi Eric,
> > > > > >
> > > > > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  
> > > > > > wrote:
> > > > > > >
> > > > > > > This patch add Kconfig entries for the F (Single-Precision)
> > > > > >
> > > > > > adds
> > > > > >
> > > > >
> > > > > OK I'll correct it as adds
> > > > >
> > > > > > > and D (Double-Precision) floating point instruction-set 
> > > > > > > extensions.
> > > > > > >
> > > > > >
> > > > > > Could you please provide reason that why U-Boot has to be compiled 
> > > > > > using F/D
> > > > > > extension?
> > > > > >
> > > > >
> > > > > Cause on AE350 platform, we have two different kinds of toolchain v5d 
> > > > > (support I/M/A/C/F/D ISA) and
> > > > > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build U-Boot 
> > > > > it will build fail, so we would like to add F/D extension on U-Boot.
> > > >
> > > > I don't understand. What difference do these two toochains have? Isn't
> > > > the v5d toolchain's default -march string be pre-configured to imafd?
> > > > But even if the toolchain is pre-configured to generate fd
> > > > instruction, I think it can be override by the compiler flags. Can you
> > > > please share the details of the toolchain you used? I suspect you have
> > > > to fix your toolchain, not U-Boot.
> > > >
> > >
> > > It's seems the ABI issue. Because our toolchain don't support
> > > multilib, the v5d toolchain libraries ABI is ilp64d.
> > > If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
> > > get link error as below:
> >
> > Then please fix your compiler. Passing -mabi=lp64 to compiler is
> > definitely correct.
>
>  One of our customer ever used floating point in their project. They want
>  to calculate something with floating point instructions in u-Boot before
>  entering kernel.

This is a new use case. For other architectures like x86, we don't
allow U-Boot to be compiled using hardware float ABI. Why can't they
use software floating point instead?

>
>  IMHO, we may consider this case for user to use -mabi=ilp64d.
>  This CONFIG will be useful for them to compile their codes and linking 
> together
>  with u-Boot.
>
>  Thanks :)

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] davinci: omapl138-lcdk: enable driver-model in SPL

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Enable CONFIG_SPL_DM and enable the driver model for serial by defining
an appropriate device in the board file for da850-lcdk.

Signed-off-by: Bartosz Golaszewski 
---
 board/davinci/da8xxevm/omapl138_lcdk.c | 16 
 configs/omapl138_lcdk_defconfig|  5 +
 2 files changed, 21 insertions(+)

diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 156d61d9fb..b20747ba01 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -369,3 +371,17 @@ int board_mmc_init(bd_t *bis)
 }
 #endif
 #endif
+
+#ifdef CONFIG_SPL_BUILD
+static const struct ns16550_platdata serial_pdata = {
+   .base = DAVINCI_UART2_BASE,
+   .reg_shift = 2,
+   .clock = 22800,
+   .fcr = UART_FCR_DEFVAL,
+};
+
+U_BOOT_DEVICE(omapl138_uart) = {
+   .name = "ns16550_serial",
+   .platdata = _pdata,
+};
+#endif
diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index b375da50df..f53a51321c 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -33,10 +33,13 @@ CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_DIAG=y
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-lcdk"
+CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_SPL_DM=y
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
 CONFIG_SYS_I2C_DAVINCI=y
@@ -53,8 +56,10 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_EMAC=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DAVINCI_SPI=y
 CONFIG_USE_TINY_PRINTF=y
+# CONFIG_SPL_OF_LIBFDT is not set
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/4] davinci: omapl138-lcdk: enable CONFIG_USE_TINY_PRINTF

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We're working towards enabling the driver-model in SPL for da850-lcdk.
Enable CONFIG_USE_TINY_PRINTF in defconfig to reduce SPL size.

Signed-off-by: Bartosz Golaszewski 
---
 configs/omapl138_lcdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index c8c20b0de1..b375da50df 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -57,3 +57,4 @@ CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DAVINCI_SPI=y
+CONFIG_USE_TINY_PRINTF=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] davinci: omapl138-lcdk: remove unneeded includes

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

There's no SPI on da850-lcdk. Remove unnecessary includes.

Signed-off-by: Bartosz Golaszewski 
---
 board/davinci/da8xxevm/omapl138_lcdk.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 2c2f885d43..156d61d9fb 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -12,8 +12,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-- 
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: omapl138-lcdk: enable SPL_SYS_MALLOC_SIMPLE

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We're working towards enabling the driver model in SPL for da850-lcdk.
Enable SPL_SYS_MALLOC_SIMPLE in defconfig to reduce SPL size.

Signed-off-by: Bartosz Golaszewski 
---
 configs/omapl138_lcdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index e43141844a..c8c20b0de1 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -19,6 +19,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_TEXT_BASE=0x8000
 CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
 CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_HUSH_PARSER=y
-- 
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: omapl138-lcdk: enable CONFIG_SPL_DM

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

This series enables the driver model in SPL on omapl138-lcdk. First two
patches enable size-reducing options in defconfig. The third patch is
just a cleanup of the board file. Last patch enables the driver model
and defines the serial device so that we don't have to disable
CONFIG_SPL_DM_SERIAL which is enabled by default when selecting
CONFIG_SPL_DM.

Bartosz Golaszewski (4):
  davinci: omapl138-lcdk: enable SPL_SYS_MALLOC_SIMPLE
  davinci: omapl138-lcdk: enable CONFIG_USE_TINY_PRINTF
  davinci: omapl138-lcdk: remove unneeded includes
  davinci: omapl138-lcdk: enable driver-model in SPL

 board/davinci/da8xxevm/omapl138_lcdk.c | 18 --
 configs/omapl138_lcdk_defconfig|  7 +++
 2 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] configs: atmel: sama5d4_xplained_mmc: enable HW PMECC

[Eugen.Hristev]

From: Eugen Hristev 

NAND:  BUG at drivers/mtd/nand/raw/nand_base.c:4361/nand_scan_tail()!

This board has a NAND flash enabled, and it requires the HW PMECC in order
to correctly probe this flash.
In the NAND flash configuration , this is selected by the GENERATE_PMECC_HEADER
which is not needed for mmc configuration.

Signed-off-by: Eugen Hristev 
---
 configs/sama5d4_xplained_mmc_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/sama5d4_xplained_mmc_defconfig 
b/configs/sama5d4_xplained_mmc_defconfig
index 6914c29..c232da9 100644
--- a/configs/sama5d4_xplained_mmc_defconfig
+++ b/configs/sama5d4_xplained_mmc_defconfig
@@ -58,6 +58,8 @@ CONFIG_DM_MMC=y
 CONFIG_GENERIC_ATMEL_MCI=y
 CONFIG_NAND=y
 CONFIG_NAND_ATMEL=y
+CONFIG_ATMEL_NAND_HW_PMECC=y
+CONFIG_PMECC_CAP=8
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=3000
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 6/6] riscv: ax25: use CCTL to flush d-cache

[Andes]

From: Rick Chen 

Use CCTL command to do d-cache write back and invalidate
instead of fence.

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/cpu/ax25/cache.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
index 228fc55..d30071e 100644
--- a/arch/riscv/cpu/ax25/cache.c
+++ b/arch/riscv/cpu/ax25/cache.c
@@ -5,17 +5,21 @@
  */
 
 #include 
+#include 
+
+#ifdef CONFIG_RISCV_NDS_CACHE
+/* mcctlcommand */
+#define CCTL_REG_MCCTLCOMMAND_NUM  0x7cc
+
+/* D-cache operation */
+#define CCTL_L1D_WBINVAL_ALL   6
+#endif
 
 void flush_dcache_all(void)
 {
-   /*
-* Andes' AX25 does not have a coherence agent. U-Boot must use data
-* cache flush and invalidate functions to keep data in the system
-* coherent.
-* The implementation of the fence instruction in the AX25 flushes the
-* data cache and is used for this purpose.
-*/
-   asm volatile ("fence" ::: "memory");
+#ifdef CONFIG_RISCV_NDS_CACHE
+   csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
+#endif
 }
 
 void flush_dcache_range(unsigned long start, unsigned long end)
@@ -72,8 +76,8 @@ void dcache_disable(void)
 {
 #ifndef CONFIG_SYS_DCACHE_OFF
 #ifdef CONFIG_RISCV_NDS_CACHE
+   csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
asm volatile (
-   "fence\n\t"
"csrr t1, mcache_ctl\n\t"
"andi t0, t1, ~0x2\n\t"
"csrw mcache_ctl, t0\n\t"
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/6] riscv: cache: Flush L2 cache before jump to linux

[Andes]

From: Rick Chen 

Flush and disable cache in cleanup_before_linux()
which will be called before jump to linux.

The sequence will be preferred as below:
L1 flush -> L1 disable -> L2 flush -> L2 disable

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/cpu/ax25/cpu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c
index 76689b2..9e7579a 100644
--- a/arch/riscv/cpu/ax25/cpu.c
+++ b/arch/riscv/cpu/ax25/cpu.c
@@ -7,6 +7,7 @@
 /* CPU specific code */
 #include 
 #include 
+#include 
 
 /*
  * cleanup_before_linux() is called just before we call linux
@@ -22,6 +23,9 @@ int cleanup_before_linux(void)
cache_flush();
icache_disable();
dcache_disable();
+#ifdef CONFIG_RISCV_NDS_CACHE
+   v5l2_disable();
+#endif
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/6] riscv: dts: move out AE350 L2 node from cpus node

[Andes]

From: Rick Chen 

When L2 node exists inside cpus node, uclass_get_device
can not parse L2 node successfully. So move it outside
from cpus node.

Also add tag-ram-ctl and data-ram-ctl attributes for
v5l2 cache controller driver. This can adjust timing
by requirement from dtb to improve performance.

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/dts/ae350_32.dts | 17 +++--
 arch/riscv/dts/ae350_64.dts | 17 +++--
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index cb6ee13..83abfcb 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -62,13 +62,18 @@
compatible = "riscv,cpu-intc";
};
};
+   };
 
-   L2: l2-cache@e050 {
-   compatible = "cache";
-   cache-level = <2>;
-   cache-size = <0x4>;
-   reg = <0x0 0xe050 0x0 0x4>;
-   };
+   L2: l2-cache@e050 {
+   compatible = "cache";
+   cache-level = <2>;
+   cache-size = <0x4>;
+   reg = <0xe050 0x4>;
+   andes,inst-prefetch = <3>;
+   andes,data-prefetch = <3>;
+   // The value format is 
+   andes,tag-ram-ctl = <0 0>;
+   andes,data-ram-ctl = <0 0>;
};
 
memory@0 {
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 705491a..7009bdc 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -62,13 +62,18 @@
compatible = "riscv,cpu-intc";
};
};
+   };
 
-   L2: l2-cache@e050 {
-   compatible = "cache";
-   cache-level = <2>;
-   cache-size = <0x4>;
-   reg = <0x0 0xe050 0x0 0x4>;
-   };
+   L2: l2-cache@e050 {
+   compatible = "cache";
+   cache-level = <2>;
+   cache-size = <0x4>;
+   reg = <0x0 0xe050 0x0 0x4>;
+   andes,inst-prefetch = <3>;
+   andes,data-prefetch = <3>;
+   // The value format is 
+   andes,tag-ram-ctl = <0 0>;
+   andes,data-ram-ctl = <0 0>;
};
 
memory@0 {
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/6] dm: cache: add v5l2 cache controller driver

[Andes]

From: Rick Chen 

Add a v5l2 cache controller driver that is usually found on
Andes RISC-V ae350 platform. It will parse the cache settings
from the dtb.

In this version tag and data ram control timing can be adjusted
by the requirement from the dtb.

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/include/asm/global_data.h |   3 ++
 arch/riscv/include/asm/v5l2cache.h   |  61 +
 drivers/cache/Kconfig|   9 
 drivers/cache/Makefile   |   1 +
 drivers/cache/cache-v5l2.c   | 102 +++
 5 files changed, 176 insertions(+)
 create mode 100644 arch/riscv/include/asm/v5l2cache.h
 create mode 100644 drivers/cache/cache-v5l2.c

diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index b74bd7e..6e52d5d 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -24,6 +24,9 @@ struct arch_global_data {
 #ifdef CONFIG_ANDES_PLMT
void __iomem *plmt; /* plmt base address */
 #endif
+#ifdef CONFIG_V5L2_CACHE
+   void __iomem *v5l2; /* v5l2 base address */
+#endif
 #ifdef CONFIG_SMP
struct ipi_data ipi[CONFIG_NR_CPUS];
 #endif
diff --git a/arch/riscv/include/asm/v5l2cache.h 
b/arch/riscv/include/asm/v5l2cache.h
new file mode 100644
index 000..8ed1c6c
--- /dev/null
+++ b/arch/riscv/include/asm/v5l2cache.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation 
+ */
+
+#ifndef _ASM_V5_L2CACHE_H
+#define _ASM_V5_L2CACHE_H
+
+struct l2cache {
+   volatile u64configure;
+   volatile u64control;
+   volatile u64hpm0;
+   volatile u64hpm1;
+   volatile u64hpm2;
+   volatile u64hpm3;
+   volatile u64error_status;
+   volatile u64ecc_error;
+   volatile u64cctl_command0;
+   volatile u64cctl_access_line0;
+   volatile u64cctl_command1;
+   volatile u64cctl_access_line1;
+   volatile u64cctl_command2;
+   volatile u64cctl_access_line2;
+   volatile u64cctl_command3;
+   volatile u64cctl_access_line4;
+   volatile u64cctl_status;
+};
+
+/* Control Register */
+#define L2_ENABLE  0x1
+/* prefetch */
+#define IPREPETCH_OFF  3
+#define DPREPETCH_OFF  5
+#define IPREPETCH_MSK  (3 << IPREPETCH_OFF)
+#define DPREPETCH_MSK  (3 << DPREPETCH_OFF)
+/* tag ram */
+#define TRAMOCTL_OFF   8
+#define TRAMICTL_OFF   10
+#define TRAMOCTL_MSK   (3 << TRAMOCTL_OFF)
+#define TRAMICTL_MSK   BIT(TRAMICTL_OFF)
+/* data ram */
+#define DRAMOCTL_OFF   11
+#define DRAMICTL_OFF   13
+#define DRAMOCTL_MSK   (3 << DRAMOCTL_OFF)
+#define DRAMICTL_MSK   BIT(DRAMICTL_OFF)
+
+/* CCTL Command Register */
+#define CCTL_CMD_REG(base, hart)   ((ulong)(base) + 0x40 + (hart) * 0x10)
+#define L2_WBINVAL_ALL 0x12
+
+/* CCTL Status Register */
+#define CCTL_STATUS_MSK(hart)  (0xf << ((hart) * 4))
+#define CCTL_STATUS_IDLE(hart) (0 << ((hart) * 4))
+#define CCTL_STATUS_PROCESS(hart)  (1 << ((hart) * 4))
+#define CCTL_STATUS_ILLEGAL(hart)  (2 << ((hart) * 4))
+
+void v5l2_enable(void);
+void v5l2_disable(void);
+
+#endif /* _ASM_V5_L2CACHE_H */
diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
index 24def7a..665689a 100644
--- a/drivers/cache/Kconfig
+++ b/drivers/cache/Kconfig
@@ -22,4 +22,13 @@ config L2X0_CACHE
  ARMv7(32-bit) devices. The driver configures the cache settings
  found in the device tree.
 
+config V5L2_CACHE
+   tristate "Andes V5L2 cache driver"
+   select CACHE
+   depends on RISCV_NDS_CACHE
+   help
+ Support Andes V5L2 cache controller in AE350 platform.
+ It will configure tag and data ram timing control from the
+ device tree and enable L2 cache.
+
 endmenu
diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
index 9deb961..4a6458c 100644
--- a/drivers/cache/Makefile
+++ b/drivers/cache/Makefile
@@ -2,3 +2,4 @@
 obj-$(CONFIG_CACHE) += cache-uclass.o
 obj-$(CONFIG_SANDBOX) += sandbox_cache.o
 obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
+obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o
diff --git a/drivers/cache/cache-v5l2.c b/drivers/cache/cache-v5l2.c
new file mode 100644
index 000..7022feb
--- /dev/null
+++ b/drivers/cache/cache-v5l2.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void v5l2_enable(void)
+{
+   struct l2cache *regs = gd->arch.v5l2;
+
+   if (regs)
+   setbits_le32(>control, L2_ENABLE);
+}
+
+void v5l2_disable(void)
+{
+   volatile struct l2cache *regs = gd->arch.v5l2;
+   u8 hart = gd->arch.boot_hart;
+   void __iomem *cctlcmd = (void __iomem 

[U-Boot] [PATCH 3/6] riscv: ae350: add imply v5l2 cache controller

[Andes]

From: Rick Chen 

Select the v5l2 UCLASS_CACHE driver for AE350.

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 board/AndesTech/ax25-ae350/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/AndesTech/ax25-ae350/Kconfig 
b/board/AndesTech/ax25-ae350/Kconfig
index 5e682b6..dd299d9 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,5 +25,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select RISCV_NDS
imply SMP
+   imply V5L2_CACHE
 
 endif
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/6] riscv: ae350: use the v5l2 driver to configure the cache

[Andes]

From: Rick Chen 

Find the UCLASS_CACHE driver to configure the cache controller's
settings.

Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 board/AndesTech/ax25-ae350/ax25-ae350.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 3d65ce7..686ec4a 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -93,10 +94,24 @@ int smc_init(void)
return 0;
 }
 
+int v5l2_init(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device(UCLASS_CACHE, 0, );
+
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
 #ifdef CONFIG_BOARD_EARLY_INIT_F
 int board_early_init_f(void)
 {
smc_init();
+   v5l2_init();
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/6] Support Andes RISC-V l2cache on AE350 platform

[Andes]

From: Rick Chen 

Add a v5l2 cache controller driver that is usually found on
Andes RISC-V ae350 platform. It will parse and configure the
cache settings (data & instruction prefetch, data & tag latency)
from the device tree blob.

Also implement L2 cache flush and disable before jump to linux.
The sequence will be preferred as below:
L1 flush -> L1 disable -> L2 flush -> L2 disable

Rick Chen (6):
  dm: cache: add v5l2 cache controller driver
  riscv: ae350: use the v5l2 driver to configure the cache
  riscv: ae350: add imply v5l2 cache controller
  riscv: cache: Flush L2 cache before jump to linux
  riscv: dts: move out AE350 L2 node from cpus node
  riscv: ax25: use CCTL to flush d-cache

 arch/riscv/cpu/ax25/cache.c |  22 ---
 arch/riscv/cpu/ax25/cpu.c   |   4 ++
 arch/riscv/dts/ae350_32.dts |  17 --
 arch/riscv/dts/ae350_64.dts |  17 --
 arch/riscv/include/asm/global_data.h|   3 +
 arch/riscv/include/asm/v5l2cache.h  |  61 +++
 board/AndesTech/ax25-ae350/Kconfig  |   1 +
 board/AndesTech/ax25-ae350/ax25-ae350.c |  15 +
 drivers/cache/Kconfig   |   9 +++
 drivers/cache/Makefile  |   1 +
 drivers/cache/cache-v5l2.c  | 102 
 11 files changed, 231 insertions(+), 21 deletions(-)
 create mode 100644 arch/riscv/include/asm/v5l2cache.h
 create mode 100644 drivers/cache/cache-v5l2.c

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] ARM: dts: Add missing DT for Meson G12A support

[Neil Armstrong]

The following DT nodes in the process on review for Linux 5.3,
until Linux 5.3 is tagged, add the missing DT nodes in u-boot specific
DTSI files that will be dropped when the v5.3-rc1 DT is synced again.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-g12a-u-boot.dtsi  | 216 +++
 arch/arm/dts/meson-g12a-u200-u-boot.dtsi |  63 +++
 2 files changed, 279 insertions(+)
 create mode 100644 arch/arm/dts/meson-g12a-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-g12a-u200-u-boot.dtsi

diff --git a/arch/arm/dts/meson-g12a-u-boot.dtsi 
b/arch/arm/dts/meson-g12a-u-boot.dtsi
new file mode 100644
index 00..5065d8b65a
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-u-boot.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Maxime Jourdan 
+ */
+
+/ {
+   soc {
+   ethmac: ethernet@ff3f {
+   compatible = "amlogic,meson-axg-dwmac", 
"snps,dwmac-3.710",
+"snps,dwmac";
+   reg = <0x0 0xff3f 0x0 0x1
+  0x0 0xff634540 0x0 0x8>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < CLKID_ETH>,
+< CLKID_FCLK_DIV2>,
+< CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+   status = "disabled";
+
+   mdio0: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,dwmac-mdio";
+   };
+   };
+
+   sd_emmc_a: sd@ffe03000 {
+   compatible = "amlogic,meson-axg-mmc";
+   reg = <0x0 0xffe03000 0x0 0x800>;
+   interrupts = ;
+   status = "disabled";
+   clocks = < CLKID_SD_EMMC_A>,
+< CLKID_SD_EMMC_A_CLK0>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+   resets = < RESET_SD_EMMC_A>;
+   };
+
+   sd_emmc_b: sd@ffe05000 {
+   compatible = "amlogic,meson-axg-mmc";
+   reg = <0x0 0xffe05000 0x0 0x800>;
+   interrupts = ;
+   status = "disabled";
+   clocks = < CLKID_SD_EMMC_B>,
+< CLKID_SD_EMMC_B_CLK0>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+   resets = < RESET_SD_EMMC_B>;
+   };
+
+   sd_emmc_c: mmc@ffe07000 {
+   compatible = "amlogic,meson-axg-mmc";
+   reg = <0x0 0xffe07000 0x0 0x800>;
+   interrupts = ;
+   status = "disabled";
+   clocks = < CLKID_SD_EMMC_C>,
+< CLKID_SD_EMMC_C_CLK0>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+   resets = < RESET_SD_EMMC_C>;
+   };
+   };
+};
+
+_pinctrl {
+   emmc_pins: emmc {
+   mux {
+   groups = "emmc_nand_d0",
+"emmc_nand_d1",
+"emmc_nand_d2",
+"emmc_nand_d3",
+"emmc_nand_d4",
+"emmc_nand_d5",
+"emmc_nand_d6",
+"emmc_nand_d7",
+"emmc_clk",
+"emmc_cmd";
+   function = "emmc";
+   bias-pull-up;
+   };
+   };
+
+   emmc_ds_pins: emmc-ds {
+   mux {
+   groups = "emmc_nand_ds";
+   function = "emmc";
+   bias-pull-down;
+   };
+   };
+
+   emmc_clk_gate_pins: emmc_clk_gate {
+   mux {
+   groups = "BOOT_8";
+   function = "gpio_periphs";
+   bias-pull-down;
+   };
+   };
+
+   eth_leds_pins: eth-leds {
+   mux {
+   groups = "eth_link_led",
+"eth_act_led";
+   function = "eth";
+   bias-disable;
+   };
+   };
+
+   eth_rmii_pins: eth-rmii {
+   mux {
+   groups = "eth_mdio",
+"eth_mdc",
+

[U-Boot] [PATCH 2/3] clk: meson-g12a: Add PCIE PLL support

[Neil Armstrong]

The G12A PCIE PLL clock was introduced in Linux 5.2-rc1, and is needed
for USB to operate, add basic support for it and associated gates.

Signed-off-by: Neil Armstrong 
---
 drivers/clk/meson/g12a.c | 103 +++
 1 file changed, 103 insertions(+)

diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index fedc9eb7dd..112326e553 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -22,6 +22,8 @@ struct meson_clk {
struct regmap *map;
 };
 
+static ulong meson_clk_set_rate_by_id(struct clk *clk, unsigned long id,
+ ulong rate, ulong current_rate);
 static ulong meson_clk_get_rate_by_id(struct clk *clk, unsigned long id);
 
 #define NUM_CLKS 178
@@ -36,6 +38,8 @@ static struct meson_gate gates[NUM_CLKS] = {
MESON_GATE(CLKID_SD_EMMC_C, HHI_GCLK_MPEG0, 26),
MESON_GATE(CLKID_ETH, HHI_GCLK_MPEG1, 3),
MESON_GATE(CLKID_UART1, HHI_GCLK_MPEG1, 16),
+   MESON_GATE(CLKID_USB, HHI_GCLK_MPEG1, 25),
+   MESON_GATE(CLKID_USB1_DDR_BRIDGE, HHI_GCLK_MPEG2, 8),
 
/* Peripheral Gates */
MESON_GATE(CLKID_SD_EMMC_B_CLK0, HHI_SD_EMMC_CLK_CNTL, 23),
@@ -231,6 +235,36 @@ static ulong meson_pll_get_rate(struct clk *clk, unsigned 
long id)
return ((parent_rate_mhz * m / n) >> od) * 100;
 }
 
+static struct parm meson_pcie_pll_parm[3] = {
+   {HHI_PCIE_PLL_CNTL0, 0, 8}, /* pm */
+   {HHI_PCIE_PLL_CNTL0, 10, 5}, /* pn */
+   {HHI_PCIE_PLL_CNTL0, 16, 5}, /* pod */
+};
+
+static ulong meson_pcie_pll_get_rate(struct clk *clk)
+{
+   struct meson_clk *priv = dev_get_priv(clk->dev);
+   struct parm *pm, *pn, *pod;
+   unsigned long parent_rate_mhz = XTAL_RATE / 100;
+   u16 n, m, od;
+   uint reg;
+
+   pm = _pcie_pll_parm[0];
+   pn = _pcie_pll_parm[1];
+   pod = _pcie_pll_parm[2];
+
+   regmap_read(priv->map, pn->reg_off, );
+   n = PARM_GET(pn->width, pn->shift, reg);
+
+   regmap_read(priv->map, pm->reg_off, );
+   m = PARM_GET(pm->width, pm->shift, reg);
+
+   regmap_read(priv->map, pod->reg_off, );
+   od = PARM_GET(pod->width, pod->shift, reg);
+
+   return ((parent_rate_mhz * m / n) / 2 / od / 2) * 100;
+}
+
 static ulong meson_clk_get_rate_by_id(struct clk *clk, unsigned long id)
 {
ulong rate;
@@ -263,6 +297,9 @@ static ulong meson_clk_get_rate_by_id(struct clk *clk, 
unsigned long id)
case CLKID_CLK81:
rate = meson_clk81_get_rate(clk);
break;
+   case CLKID_PCIE_PLL:
+   rate = meson_pcie_pll_get_rate(clk);
+   break;
default:
if (gates[id].reg != 0) {
/* a clock gate */
@@ -281,6 +318,71 @@ static ulong meson_clk_get_rate(struct clk *clk)
return meson_clk_get_rate_by_id(clk, clk->id);
 }
 
+static ulong meson_pcie_pll_set_rate(struct clk *clk, ulong rate)
+{
+   struct meson_clk *priv = dev_get_priv(clk->dev);
+
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL0, 0x20090496);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL0, 0x30090496);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL1, 0x);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL2, 0x1100);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL3, 0x10058e00);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL4, 0x000100c0);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL5, 0x6848);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL5, 0x6868);
+   udelay(20);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL4, 0x008100c0);
+   udelay(10);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL0, 0x34090496);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL0, 0x14090496);
+   udelay(10);
+   regmap_write(priv->map, HHI_PCIE_PLL_CNTL2, 0x1000);
+   regmap_update_bits(priv->map, HHI_PCIE_PLL_CNTL0,
+   0x1f << 16, 9 << 16);
+
+   return 1;
+}
+
+static ulong meson_clk_set_rate_by_id(struct clk *clk, unsigned long id,
+ ulong rate, ulong current_rate)
+{
+   if (current_rate == rate)
+   return 0;
+
+   switch (id) {
+   /* Fixed clocks */
+   case CLKID_PCIE_PLL:
+   return meson_pcie_pll_set_rate(clk, rate);
+
+   default:
+   return -ENOENT;
+   }
+
+   return -EINVAL;
+}
+
+
+static ulong meson_clk_set_rate(struct clk *clk, ulong rate)
+{
+   ulong current_rate = meson_clk_get_rate_by_id(clk, clk->id);
+   int ret;
+
+   if (IS_ERR_VALUE(current_rate))
+   return current_rate;
+
+   debug("%s: setting rate of %ld from %ld to %ld\n",
+ __func__, clk->id, current_rate, rate);
+
+   ret = meson_clk_set_rate_by_id(clk, clk->id, rate, current_rate);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+
+   debug("clock %lu has new rate %lu\n", clk->id,
+ 

[U-Boot] [PATCH 1/3] ARM: dts: sync Amlogic G12A DT with Linux 5.2-rc1

[Neil Armstrong]

Sync from Linux commit a188339ca5a3 ("Linux 5.2-rc1")

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-g12a-u200.dts  | 147 ++
 arch/arm/dts/meson-g12a.dtsi  | 465 ++
 include/dt-bindings/clock/g12a-aoclkc.h   |   2 +
 include/dt-bindings/clock/g12a-clkc.h |   5 +
 .../reset/amlogic,meson-g12a-reset.h  |   5 +-
 5 files changed, 623 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/meson-g12a-u200.dts b/arch/arm/dts/meson-g12a-u200.dts
index c44dbdddf2..0e8045b8a9 100644
--- a/arch/arm/dts/meson-g12a-u200.dts
+++ b/arch/arm/dts/meson-g12a-u200.dts
@@ -6,6 +6,8 @@
 /dts-v1/;
 
 #include "meson-g12a.dtsi"
+#include 
+#include 
 
 / {
compatible = "amlogic,u200", "amlogic,g12a";
@@ -21,9 +23,154 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   cvbs-connector {
+   compatible = "composite-video-connector";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   flash_1v8: regulator-flash_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "FLASH_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+
+   main_12v: regulator-main_12v {
+   compatible = "regulator-fixed";
+   regulator-name = "12V";
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   regulator-always-on;
+   };
+
+   vcc_1v8: regulator-vcc_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   /* FIXME: actually controlled by VDDCPU_B_EN */
+   };
+
+   vcc_5v: regulator-vcc_5v {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+
+   gpio = < GPIOH_8 GPIO_OPEN_DRAIN>;
+   enable-active-high;
+   };
+
+   usb_pwr_en: regulator-usb_pwr_en {
+   compatible = "regulator-fixed";
+   regulator-name = "USB_PWR_EN";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_5v>;
+
+   gpio = < GPIOH_6 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vddao_1v8: regulator-vddao_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vddao_3v3: regulator-vddao_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_12v>;
+   regulator-always-on;
+   };
+
+};
+
+_AO {
+   pinctrl-0 = <_ao_a_h_pins>;
+   pinctrl-names = "default";
+   status = "disabled";
+   hdmi-phandle = <_tx>;
+};
+
+_AO {
+   pinctrl-0 = <_ao_b_h_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+   hdmi-phandle = <_tx>;
+};
+
+_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+};
+
+_tx {
+   status = "okay";
+   pinctrl-0 = <_hpd_pins>, <_ddc_pins>;
+   pinctrl-names = "default";
+   hdmi-supply = <_5v>;
+};
+
+_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
 };
 
 _AO {
status = "okay";
+   pinctrl-0 = <_ao_a_pins>;
+   pinctrl-names = "default";
 };
 
+ {

[U-Boot] [PATCH 0/3] ARM: meson-g12a: Add missing support from Linux 5.2-rc1

[Neil Armstrong]

This patchset :
- Syncs the G12A DT from v5.2-rc1
- Add support for the G12A PCIE PLL, introduced in v5.2-rc1
- Add missing DT to fill the gaps, that will be synced in Linux 5.3-rc1

Neil Armstrong (3):
  ARM: dts: sync Amlogic G12A DT with Linux 5.2-rc1
  clk: meson-g12a: Add PCIE PLL support
  ARM: dts: Add missing DT for Meson G12A support

 arch/arm/dts/meson-g12a-u-boot.dtsi   | 216 
 arch/arm/dts/meson-g12a-u200-u-boot.dtsi  |  63 +++
 arch/arm/dts/meson-g12a-u200.dts  | 147 ++
 arch/arm/dts/meson-g12a.dtsi  | 465 ++
 drivers/clk/meson/g12a.c  | 103 
 include/dt-bindings/clock/g12a-aoclkc.h   |   2 +
 include/dt-bindings/clock/g12a-clkc.h |   5 +
 .../reset/amlogic,meson-g12a-reset.h  |   5 +-
 8 files changed, 1005 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/meson-g12a-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-g12a-u200-u-boot.dtsi

-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

[Andy Yan]

Hi Simon:

On 2019/5/23 上午3:39, Simon Glass wrote:

Hi Andy,

On Tue, 21 May 2019 at 19:43, Andy Yan  wrote:

Hi Andre:

Andre Przywara  于2019年5月20日周一 下午11:59写道：


On Mon, 20 May 2019 14:34:01 +0800
Andy Yan  wrote:

Hi,


On 2019/5/19 上午12:26, Simon Glass wrote:

Hi Andy,

Instead of this could you:

- move ATF?

All rockchip based arm64 ATF run from the start 64KB of dram as this
will give convenient for kernel manage the memory.

This is just BL31 of ATF, right?
ATF recently gained PIE support for BL31 [1], so by just enabling this in
platform.mk you will get a relocatable BL31 image, with a very minimal
runtime linker. Worked out of the box on Allwinner for me, but YMMV.
So you could load newer ATF builds everywhere.



This is not the root case, actually we want put ATF as close as possible to
the start of dram, this give linux kernel convenient to manage the memory.

But instead of 64KB you could put it at 32KB or 128KB. It's still in
the first 1MB. Linux won't care, right?





Does that help you?


On the other hand, change the ATF load address will break the
compatibility of the exiting firmware.

I am not sure what you mean with "compatibility of existing firmware"?
Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper)
into one image? And there would be no real mix and match, with older
pre-compiled builds? So by changing the ATF base address and the load
address in TPL at the same time you won't have issues?


I mean older pre-compiled builds published by rockchip rkbin [1], many
projects and popular boards directly use this , for example Armbian. How to
change the base address of the pre-build binary?
  [1] https://github.com/rockchip-linux/rkbin

Perhaps I am misunderstanding your intent here, but mainline U-Boot
should not be bound to the design decisions of old closed-source
binaries.


Indeed rockchip have submit the ATF support for rockchip platforms to 
ATF mainline. But the situation is: we see many people like  directly 
use the pre-build binary from rkbin, they are used on many popular 
boards and projects. Armbian is one of the example for this[0] , it use 
mainline u-boot, but use atf from rkbin for  some boards.


So we are really care about the compatibility.

[0]https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf 




[...]

Regards,
Simon




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

[Andy Yan]

Hi Simon:

On 2019/5/23 上午3:39, Simon Glass wrote:

Hi Andy,

On Tue, 21 May 2019 at 19:56, Andy Yan  wrote:

Hi Simon:

Simon Glass  于2019年5月22日周三 上午8:28写道：

Hi Andy,

On Tue, 21 May 2019 at 00:51, Andy Yan  wrote:

Hi Simon:

On 2019/5/20 下午11:35, Simon Glass wrote:

Hi Andy,

On Mon, 20 May 2019 at 00:34, Andy Yan  wrote:

Hi Simon:

On 2019/5/19 上午12:26, Simon Glass wrote:

Hi Andy,

Instead of this could you:

- move ATF?

All rockchip based arm64 ATF run from the start 64KB of dram as this
will give convenient for kernel manage the memory.

On the other hand, change the ATF load address will break the
compatibility of the exiting firmware.


- change the SPL load address so it is not in the way (since TPL can
load to any address)

The SPL is loaded by bootrom after TPL back to bootrom, so the load
address if fixed by bootrom code.

I think you are creating a nightmare here. If you have to do things
like this for older and smaller SoCs, OK. But it should not be used
for newer ones that can do things properly.


Most rockchip based SOC sram is small,  even in the future soc roadmap,
this situation  will still exist, larger sram means more cost.

I believe the RK3399 has 192KB. What is the minimum size in new chips?


The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without 
storage drive is 28KB.
The available sram size for TPL on RK3326 is 10KB,  our another A35 based IOT 
SOC has the same limitation.

OK, I see.




As for the current spl for rockchip soc in mainline, we use a workaround
by reserve large space at the head of spl(see
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary.

Yes.


As for my patch, the spl relocation is disabled default, we only enable
it on necessary platform, so it won't hurt others .

Well it adds more code and complexity. Perhaps it makes sense to add
this, but I want to understand the need.


The bootrom has so many limitations that it just creates pain.


I know we can build mmc or other storage driver into TPL so we can use
tpl load spl on some platform that sram is big enough, but there are
also many rockchip soc has very small sram, so we tend to only do dram
initialization in tpl, and let bootrom load next stage .

See above


For the consideration of software development, we also want to keep TPL
clean,  only do dram initialization(as it current status), this make our
internal dram team work more simple, they don't need to care about other
modules like mmc.

Yes I understand this, but the boot ROM should be provided as a
library to call into:

int mmc_read(void *addr, int start_block, int end_block)
int spi_read(void *addr, int start_block, int end_block)

Then SPL or TPL can use it without all the strange limitations we have now.

Since you probably already have these functions somewhere in the boot
ROM, you could implement this using a function table somewhere in the
ROM with a magic number before it, so that SPL can find it.


The Bootrom do much more work than directly load the spl binary. It will do 
somthing like checksum, look for the backup when the current image is invalid, 
also including security check when secure boot is enabled. This is why we did 
much work to add back_too_bootrom   mechanism in mainline in 2017.

Yes I understand that, but it is also quite inflexible, and creates
enormous problems with bootloaders.

I am not suggesting that you remove functionality. I am suggesting
that you allow bootloaders to call into some of it, to reduce the
problems caused by the inflexible bootrom.



I checked with people who write bootrom code these days,  as different 
chip written by different people from different team, it took a bit long 
time to figure out this.


Yes , bootrom have storage access api like 
mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not 
provide a fixed table for these api, and the address for these api are 
different on different chip, this means we have to list the api address 
chip by chip in SPL code. There is another thing, as the bootrom code 
are written by different person, the api interface don't keep constant: 
sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int 
len), but on another chip is sfc_nor_read(int start, void *addr, int 
len), this make things complicated.


Also as what I mentioned before, the Bootrom do much more work than 
directly load the spl binary, especially in secure boot mode, but the 
bootrom don't want to export secure related api for security concern .


So this seems not a good choice to reuse bootrom api in spl.


Regards,
Simon







- (in extremis) create a function which does a memmove() and a jump,
copy it somewhere and run it (I think x86 does this)

?

I am not very understand about this, just a memmove may not work, we
need to link the code by pie, and fix the rela.dyn sections after copy.
see arm/relocate_64.S

Well if you don't access absolute addresses (which you generally don't
in ARM) your memmove() and 

Re: [U-Boot] [PATCH v2 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit

[Michal Simek]

On 24. 05. 19 15:40, Luca Ceresoli wrote:
> Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
> only publicly-available compatible carrier card. The SoM is based on the EV
> version of the Xilinx ZynqMP SoC+FPGA.
> 
> The psu_init_gpl.c file has been generated from the board definition files
> at [0] using Vivado 2018.3 and then minimized by
> tools/zynqmp_psu_init_minimize.sh. Manually removed serdes init code since
> it is not mentioned in device tree and fixed a checkpatch error.
> 
> [0] 
> https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
> 
> Signed-off-by: Luca Ceresoli 
> 
> ---
> 
> Changes v1 -> v2:
>  - remove serdes code from psu_init_gpl.c since no serdes is enabled in DT
>(Michal)
>  - split DT in two files: SOM and carrier card (Michal)
>  - improved DT comments, added product URLs
>  - DT: add missing phy-handle under ethernet node (Michal)
> 
> Whole patchset tested on:
>  - current u-boot/master, as is
>  - current u-boot-microblaze/master
>  - current u-boot-microblaze/master with the addtion of
>commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/avnet-ultrazedev-cc.dts  |  58 ++
>  arch/arm/dts/avnet-ultrazedev-som.dtsi|  54 ++
>  .../zynqmp/avnet-ultrazedev-cc/psu_init_gpl.c | 663 ++
>  configs/avnet_ultrazedev_defconfig|  64 ++
>  5 files changed, 840 insertions(+)
>  create mode 100644 arch/arm/dts/avnet-ultrazedev-cc.dts
>  create mode 100644 arch/arm/dts/avnet-ultrazedev-som.dtsi
>  create mode 100644 board/xilinx/zynqmp/avnet-ultrazedev-cc/psu_init_gpl.c
>  create mode 100644 configs/avnet_ultrazedev_defconfig

I am still not happy with this one. Boards have certain revisions which
is not reflected anywhere. Please add it model and also to file name.
I am missing model property - there should be one in SOM. And another
one for carrier card.

I had similar thing recently about how to name board with specific FMC
card.
Name is composed like this
---.dts

And the same style should be used here.
avnet-ultrazedev-cc-revC-ultrazedev-som-revA.dts

It is longer but it describe that configuration fully.
When new som is added to the same base you can put that stuff together.


> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 8167cdb4e856..d82dc6529749 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>   zynq-zybo-z7.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += \
>   avnet-ultra96-rev1.dtb  \
> + avnet-ultrazedev-cc.dtb \
>   zynqmp-mini.dtb \
>   zynqmp-mini-emmc0.dtb   \
>   zynqmp-mini-emmc1.dtb   \
> diff --git a/arch/arm/dts/avnet-ultrazedev-cc.dts 
> b/arch/arm/dts/avnet-ultrazedev-cc.dts
> new file mode 100644
> index ..d94dd4246f7b
> --- /dev/null
> +++ b/arch/arm/dts/avnet-ultrazedev-cc.dts
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +
> +/*
> + * UltraZed-EV Carrier Card (based on the UltraZed-EV SoM)
> + * http://ultrazed.org/product/ultrazed-ev-carrier-card
> + */
> +
> +/dts-v1/;
> +
> +#include "avnet-ultrazedev-som.dtsi"
> +
> +/ {

please add model and compatibility here.

> + chosen {
> + stdout-path = "serial0:115200n8";
> + xlnx,eeprom = 
> + };
> + aliases {
> + ethernet0 = 
> + serial0 = 
> + };
> +};
> +
> + {
> + device_type = "serial";
> + port-number = <0>;

This property shouldn't be needed.

> + status = "okay";
> + u-boot,dm-pre-reloc;
> +};
> +
> +_cc {
> + /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROM with EUI-48 */
> + eeprom: eeprom@51 {
> + compatible = "at,24c02", "i2c-eeprom";

please remove i2c-eeprom - this is just u-boot thing and

at,24c02 should replaced by atmel,24c02. Done in kernel some time ago.


> + reg = <0x51>;
> + };
> +
> + /* IDT Versa Clock 5P49V5935B */
> + vc5: clock-generator@6a {
> + compatible = "idt,5p49v5935";
> + reg = <0x6a>;
> + #clock-cells = <1>;
> + };
> +};
> +
> +/* Ethernet RJ-45 */
> + {
> + status = "okay";
> +};
> +
> +/* microSD card slot */
> + {
> + status = "okay";
> + xlnx,mio_bank = <1>;
> + clock-frequency = <18000>;
> + max-frequency = <5000>;
> + no-1-8-v;
> + disable-wp;
> +};
> diff --git a/arch/arm/dts/avnet-ultrazedev-som.dtsi 
> b/arch/arm/dts/avnet-ultrazedev-som.dtsi
> new file mode 100644
> index ..4ce0a2d31786
> --- /dev/null
> +++ b/arch/arm/dts/avnet-ultrazedev-som.dtsi
> @@ -0,0 +1,54 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +
> +/*
> + * UltraZed-EV SoM
> + * http://ultrazed.org/product/ultrazed-ev
> + */
> +
> +/dts-v1/;
> +
> 

Re: [U-Boot] [PATCH v2 2/3] arm64: zynqmp: add tool to minimize psu_init_gpl.c files

[Michal Simek]

On 24. 05. 19 15:40, Luca Ceresoli wrote:
> This script transforms a pair of psu_init_gpl.c and .h files produced by
> the Xilinx Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that
> is almost checkpatch compliant.
> 
> Based on a script by Michal Simek.
> 
> Signed-off-by: Luca Ceresoli 
> 
> ---
> 
> Changes v1 -> v2:
>  - document that is INPUT_DIR==OUTPUT_DIR then psu_init_gpl.c is overwritten
>  - minor improvement to commit message
>  - show help text if script is called without parameters (Michal)
> ---
>  tools/zynqmp_psu_init_minimize.sh | 145 ++
>  1 file changed, 145 insertions(+)
>  create mode 100755 tools/zynqmp_psu_init_minimize.sh
> 
> diff --git a/tools/zynqmp_psu_init_minimize.sh 
> b/tools/zynqmp_psu_init_minimize.sh
> new file mode 100755
> index ..b0a07f9080a6
> --- /dev/null
> +++ b/tools/zynqmp_psu_init_minimize.sh
> @@ -0,0 +1,145 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2018 Michal Simek 
> +# Copyright (C) 2019 Luca Ceresoli 
> +
> +usage()
> +{
> +cat < +
> +Transform a pair of psu_init_gpl.c and .h files produced by the Xilinx
> +Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that is almost
> +checkpatch compliant. Minor coding style might still be needed. Must be
> +run from the top-level U-Boot source directory.
> +
> +Usage:   zynqmp_psu_init_minimize.sh INPUT_DIR OUTPUT_DIR
> +Example: zynqmp_psu_init_minimize.sh \\
> + /path/to/original/psu_init_gpl_c_and_h/ \\
> + board/xilinx/zynqmp//
> +
> +Notes:   INPUT_DIR must contain both .c and .h files.
> + If INPUT_DIR and OUTPUT_DIR are the same directory,
> + psu_init_gpl.c will be overwritten.
> +
> +EOF
> +}
> +
> +set -o errexit -o errtrace
> +set -o nounset
> +
> +if [ $# -ne 2 ]
> +then
> +usage >&2
> +exit 1
> +fi
> +
> +IN="${1}/psu_init_gpl.c"
> +OUT="${2}/psu_init_gpl.c"
> +TMP=$(mktemp /tmp/psu_init_gpl.XX)
> +trap "rm ${TMP}" ERR
> +
> +# Step through a temp file to allow both $IN!=$OUT and $IN==$OUT
> +sed -e '/sleep.h/d' \
> +-e '/xil_io.h/d' \
> +${IN} >${TMP}
> +cp ${TMP} ${OUT}
> +
> +# preprocess to expand defines, then remove cpp lines starting with '#'
> +gcc -I${1} -E ${OUT} -o ${TMP}
> +sed '/^#/d' ${TMP} >${OUT}
> +
> +# Remove trivial code before psu_pll_init_data()
> +sed -ni '/psu_pll_init_data/,$p' ${OUT}
> +
> +# Functions are lowercase in U-Boot, rename them
> +sed -i 's/PSU_Mask_Write/psu_mask_write/g' ${OUT}
> +sed -i 's/mask_pollOnValue/mask_pollonvalue/g' ${OUT}
> +sed -i 's/RegValue/regvalue/g' ${OUT}
> +sed -i 's/MaskStatus/maskstatus/g' ${OUT}
> +
> +sed -i '/&= psu_peripherals_powerdwn_data()/d' ${OUT}
> +
> +FUNCS_TO_REMOVE="psu_protection
> +psu_..._protection
> +psu_init_xppu_aper_ram
> +mask_delay(u32
> +mask_read(u32
> +dpll_prog
> +mask_poll(u32
> +mask_pollonvalue(u32
> +psu_ps_pl_reset_config_data
> +psu_ps_pl_isolation_removal_data
> +psu_apply_master_tz
> +psu_post_config_data
> +psu_post_config_data
> +psu_peripherals_powerdwn_data
> +psu_init_ddr_self_refresh
> +xmpu
> +xppu
> +"
> +for i in $FUNCS_TO_REMOVE; do
> +sed -i "/$i/,/^}$/d" ${OUT}
> +done
> +
> +scripts/Lindent ${OUT}
> +
> +# Prepend 'static' to internal functions
> +sed -i 's/^.*data(void)$/static &/g' ${OUT}
> +sed -i 's/^.*psu_afi_config(void)$/static &/g' ${OUT}
> +sed -i 's/^void init_peripheral/static &/g' ${OUT}
> +sed -i 's/^int serdes/static &/g' ${OUT}
> +sed -i 's/^int init_serdes/static &/g' ${OUT}
> +sed -i 's/^unsigned long /static &/g' ${OUT}
> +
> +sed -i 's/()$/(void)/g' ${OUT}
> +sed -i 's/0X/0x/g' ${OUT}
> +
> +# Add header
> +cat << EOF >${TMP}
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +
> +EOF
> +
> +cat ${OUT} >>${TMP}
> +cp ${TMP} ${OUT}
> +
> +# Temporarily convert newlines to do some mangling across lines
> +tr "\n" "\r" <${OUT} >${TMP}
> +
> +# Cleanup empty loops. E.g.:
> +# |while (e) {|
> +# |   | ==> |while (e)|
> +# |}  | |;|
> +# |   |
> +sed -i -r 's| \{\r+(\t*)\}\r\r|\n\1\t;\n|g' ${TMP}
> +
> +# Remove empty line between variable declaration
> +sed -i -r 's|\r(\r\t(unsigned )?int )|\1|g' ${TMP}
> +
> +# Remove empty lines at function beginning/end
> +sed -i -e 's|\r{\r\r|\r{\r|g' ${TMP}
> +sed -i -e 's|\r\r}\r|\r}\r|g' ${TMP}
> +
> +# Remove empty lines after '{' line
> +sed -i -e 's| {\r\r| {\r|g' ${TMP}
> +
> +# Remove braces {} around single statement blocks. E.g.:
> +# | while (e) { || while (e) |
> +# | stg();  | => | stg();|
> +# | }   |
> +sed -i -r 's| \{(\r[^\r]*;)\r\t*\}|\1|g' ${TMP}
> +
> +# Remove Unnecessary parentheses around 'n_code <= 0x3C' and similar. E.g.:
> +# if ((p_code >= 0x26) && ...) -> if (p_code >= 0x26 && ...)
> +sed -i -r 's|\((._code .= [x[:xdigit:]]+)\)|\1|g' ${TMP}
> +
> +# Convert back newlines
> +tr "\r" "\n" <${TMP} >${OUT}
> +

Re: [U-Boot] [PATCH v2 1/3] arm64: zynqmp: xil_io.h: declare functions as static

[Michal Simek]

On 24. 05. 19 15:40, Luca Ceresoli wrote:
> Fixes sparse warnings when building zynqmp defconfigs:
>   ./board/xilinx/zynqmp/xil_io.h:12:6: warning: symbol 'Xil_Out32' was not 
> declared. Should it be static?
>   ./board/xilinx/zynqmp/xil_io.h:17:5: warning: symbol 'Xil_In32' was not 
> declared. Should it be static?
>   ./board/xilinx/zynqmp/xil_io.h:22:6: warning: symbol 'usleep' was not 
> declared. Should it be static?
> 
> Also add __maybe_unused to usleep() since it is not used by minimized
> psu_init_gpl.c files, so it would warn as "defined but not used".
> 
> Signed-off-by: Luca Ceresoli 
> 
> ---
> 
> Chages v1 -> v2:
>  - fix commit text (Michal)
> ---
>  board/xilinx/zynqmp/xil_io.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/board/xilinx/zynqmp/xil_io.h b/board/xilinx/zynqmp/xil_io.h
> index c476c902ebcb..1c1bf32adaae 100644
> --- a/board/xilinx/zynqmp/xil_io.h
> +++ b/board/xilinx/zynqmp/xil_io.h
> @@ -9,17 +9,17 @@
>  
>  #define xil_printf(...)
>  
> -void Xil_Out32(unsigned long addr, unsigned long val)
> +static void Xil_Out32(unsigned long addr, unsigned long val)
>  {
>   writel(val, addr);
>  }
>  
> -int Xil_In32(unsigned long addr)
> +static int Xil_In32(unsigned long addr)
>  {
>   return readl(addr);
>  }
>  
> -void usleep(u32 sleep)
> +static void __maybe_unused usleep(u32 sleep)
>  {
>   udelay(sleep);
>  }
> 

applied.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] efi_loader: bootmgr: print a message when loading from BootNext failed

[AKASHI Takahiro]

On Tue, May 28, 2019 at 08:16:37AM +0200, Heinrich Schuchardt wrote:
> On 5/24/19 8:59 AM, AKASHI Takahiro wrote:
> >If a user defines BootNext but not BootOrder and loading from BootNext
> >fails, you will see only a message like this:
> > BootOrder not defined
> >
> >This may confuse a user. Adding an error message will be helpful.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >Changes in v2 (May 24, 2019)
> >* add an error message to try_load_entry()
> >---
> >  lib/efi_loader/efi_bootmgr.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >index 7bf51874c1c1..bb66fee0a3d2 100644
> >--- a/lib/efi_loader/efi_bootmgr.c
> >+++ b/lib/efi_loader/efi_bootmgr.c
> >@@ -149,8 +149,10 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t 
> >*handle)
> >
> > ret = EFI_CALL(efi_load_image(true, efi_root, lo.file_path,
> >   NULL, 0, handle));
> >-if (ret != EFI_SUCCESS)
> >+if (ret != EFI_SUCCESS) {
> >+printf("Loading from Boot%04X failed\n", n);
> > goto error;
> >+}
> >
> > attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >  EFI_VARIABLE_RUNTIME_ACCESS;
> >@@ -215,6 +217,8 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
> > ret = try_load_entry(bootnext, handle);
> > if (ret == EFI_SUCCESS)
> > return ret;
> >+printf("Loading from Boot%04X failed, falling 
> >back into BootOrder...\n",
> 
> This is an example output:
> 
> => bootefi bootmgr
> Loading from Boot0004 failed
> Loading from Boot0004 failed, falling back into BootOrder...
> Loading from Boot0005 failed
> Loading from Boot0003 failed
> Loading from Boot0004 failed
> EFI boot manager: Cannot load any image
> 
> "Loading from Boot0004 failed" appears twice in the beginning.
> 
> Either leave the message away or change it to
> 
> printf("Falling back into BootOrder...\n");

Please make this change for me so that I don't have to send out
another patch?

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >+   bootnext);
> > }
> > } else {
> > printf("Deleting BootNext failed\n");
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] efi_loader: bootmgr: print a message when loading from BootNext failed

[Heinrich Schuchardt]

On 5/24/19 8:59 AM, AKASHI Takahiro wrote:

If a user defines BootNext but not BootOrder and loading from BootNext
fails, you will see only a message like this:
BootOrder not defined

This may confuse a user. Adding an error message will be helpful.

Signed-off-by: AKASHI Takahiro 
---
Changes in v2 (May 24, 2019)
* add an error message to try_load_entry()
---
  lib/efi_loader/efi_bootmgr.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 7bf51874c1c1..bb66fee0a3d2 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -149,8 +149,10 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t 
*handle)

ret = EFI_CALL(efi_load_image(true, efi_root, lo.file_path,
  NULL, 0, handle));
-   if (ret != EFI_SUCCESS)
+   if (ret != EFI_SUCCESS) {
+   printf("Loading from Boot%04X failed\n", n);
goto error;
+   }

attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
 EFI_VARIABLE_RUNTIME_ACCESS;
@@ -215,6 +217,8 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
ret = try_load_entry(bootnext, handle);
if (ret == EFI_SUCCESS)
return ret;
+   printf("Loading from Boot%04X failed, falling back 
into BootOrder...\n",


This is an example output:

=> bootefi bootmgr
Loading from Boot0004 failed
Loading from Boot0004 failed, falling back into BootOrder...
Loading from Boot0005 failed
Loading from Boot0003 failed
Loading from Boot0004 failed
EFI boot manager: Cannot load any image

"Loading from Boot0004 failed" appears twice in the beginning.

Either leave the message away or change it to

printf("Falling back into BootOrder...\n");

Best regards

Heinrich


+  bootnext);
}
} else {
printf("Deleting BootNext failed\n");



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mips: mt76xx: Implement new d-cache fix in last_stage_init()

[Stefan Roese]

With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
version") the init sequence has changed in arch_misc_init(), resulting
in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
When this happens, the first (or sometimes later ones as well) TFTP
command hangs and does not complete correctly. This leads to the
assumption that the d-cache is not in a clean state once the ethernet
driver is called (d-cache is used here for the buffers). The old work-
around with the cache flush somehow does not work any more now with
the new code change.

Unfortunately adding CONFIG_SYS_MALLOC_CLEAR_ON_INIT also did not fix
this issue. With v2019.07-rc3 it shows again. The time of accessing
the data seems to be very important here. It needs to be "very late"
in the boot process.

Testing has shown, that copying a 64KiB area in DDR at a very late
bootup time, directly before calling into the prompt, fixes this issue.
Flushing of the complete d-cache does not seem to necessary, as this
copy alone seems to fix this problem.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
 arch/mips/Kconfig   |  2 +-
 arch/mips/mach-mtmips/cpu.c | 26 ++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5cb9bdf2ee..e3e7945567 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -84,13 +84,13 @@ config ARCH_MTMIPS
select DM_SERIAL
imply DM_SPI
imply DM_SPI_FLASH
+   select LAST_STAGE_INIT
select MIPS_TUNE_24KC
select OF_CONTROL
select ROM_EXCEPTION_VECTORS
select SUPPORTS_CPU_MIPS32_R1
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
-   select SYS_MALLOC_CLEAR_ON_INIT
select SYSRESET
 
 config ARCH_JZ47XX
diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
index b0a6397d68..7afc2c5940 100644
--- a/arch/mips/mach-mtmips/cpu.c
+++ b/arch/mips/mach-mtmips/cpu.c
@@ -68,3 +68,29 @@ int print_cpuinfo(void)
 
return 0;
 }
+
+int last_stage_init(void)
+{
+   void *src, *dst;
+
+   src = malloc(SZ_64K);
+   dst = malloc(SZ_64K);
+   if (!src || !dst) {
+   printf("Can't allocate buffer for cache cleanup copy!\n");
+   return 0;
+   }
+
+   /*
+* It has been noticed, that sometimes the d-cache is not in a
+* "clean-state" when U-Boot is running on MT7688. This was
+* detected when using the ethernet driver (which uses d-cache)
+* and a TFTP command does not complete. Copying an area of 64KiB
+* in DDR at a very late bootup time in U-Boot, directly before
+* calling into the prompt, seems to fix this issue.
+*/
+   memcpy(dst, src, SZ_64K);
+   free(src);
+   free(dst);
+
+   return 0;
+}
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot