date:20190521

Hi Tom, Peng, Fabio,

> On Wed, May 22, 2019 at 01:38:44AM +, Peng Fan wrote:
> > Hi Fabio,
> >   
> > > Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> > > 
> > > Hi Peng,
> > > 
> > > On Thu, May 16, 2019 at 11:29 PM Peng Fan 
> > > wrote: 
> > > > You could enable DEBUG in SPL, and disable SPL_SDP because of
> > > > size will  
> > > exceeds.  
> > > > Then see what happends.
> > > > I have no idea, then. My board is REV C4, chip 1.5  
> > > 
> > > My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> > > 
> > > After further investigation we can confirm that the problem is
> > > caused by SPL size being greater than the 68kB limit (4KB header
> > > + 64KB max size)as explained in include/configs/imx6_spl.h:
> > > 
> > > ---
> > > #ifndef __IMX6_SPL_CONFIG_H
> > > #define __IMX6_SPL_CONFIG_H
> > > 
> > > #ifdef CONFIG_SPL
> > > /*
> > >  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
> > >  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091
> > >  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support
> > > IMX6SDL as well
> > >  *  - BOOT ROM stack is at 0x0091FFB8
> > >  *  - if icache/dcache is enabled (eFuse/strapping controlled)
> > > then the
> > >  *IMX BOOT ROM will setup MMU table at 0x00918000, therefore
> > > we need to
> > >  *fit between 0x00907000 and 0x00918000.
> > >  *  - Additionally the BOOT ROM loads what they consider the
> > > firmware image
> > >  *which consists of a 4K header in front of us that contains
> > > the IVT, DCD
> > >  *and some padding thus 'our' max size is really 0x00908000 -
> > > 0x00918000
> > >  *or 64KB
> > >  */
> > > #define CONFIG_SPL_MAX_SIZE 0x1
> > > #define CONFIG_SPL_STACK0x0091FFB8
> > > /*
> > >  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to
> > > write the
> > >  * SPL/U-Boot combination generated with u-boot-with-spl.imx
> > > directly to a
> > >  * boot media (given that boot media specific offset is
> > > configured properly). */
> > > #define CONFIG_SPL_PAD_TO   0x11000
> > > ---
> > > 
> > > Here are the tests I ran:
> > > 
> > > Test 1: Original U-Boot 2019.07-rc2
> > > ---
> > > 
> > > SPL: 76800 (75 kB)
> > > Result: does not boot
> > > 
> > > Test 2: Removing extra dtbs
> > > -
> > > 
> > > --- a/configs/mx6sabresd_defconfig
> > > +++ b/configs/mx6sabresd_defconfig
> > > @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> > > CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> > > CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> > > -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> > > +CONFIG_OF_LIST="imx6q-sabresd"
> > >  CONFIG_MULTI_DTB_FIT=y
> > >  CONFIG_SPL_MULTI_DTB_FIT=y
> > > -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > > +CONFIG_SPL_OF_LIST="imx6q-sabresd"
> > >  CONFIG_ENV_IS_IN_MMC=y
> > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > >  CONFIG_SPL_DM=y
> > > 
> > > SPL:68608 (67 kB)
> > > Result: boots correctly
> > > 
> > > Test 3: Removing SPL_DM
> > > 
> > > 
> > > --- a/configs/mx6sabresd_defconfig
> > > +++ b/configs/mx6sabresd_defconfig
> > > @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> > > CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > >  CONFIG_ENV_IS_IN_MMC=y
> > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > -CONFIG_SPL_DM=y
> > >  CONFIG_USB_FUNCTION_FASTBOOT=y
> > >  CONFIG_FASTBOOT_BUF_ADDR=0x1200
> > >  CONFIG_FASTBOOT_BUF_SIZE=0x1000
> > > 
> > > SPL: 68608 (67 kB)
> > > Result: boots correctly
> > > 
> > > I will send a v2 removing CONFIG_SPL_DM.  
> > 
> > So what is the real direction moving to use SPL driver, non-dm is
> > allowed in future? 

I think that CONFIG_SPL_DM would be a natural, next step.

However, from my experience the size of SPL grows considerably when
e.g. fitImage is added (~4KiB), DM/DTB support (~8-12KiB), and the
OCRAM memory footprint (as we need space to have malloc).

Solution is to use all the CONFIG_*_TINY* options in SPL as well as
more widely use OF_PLATDATA. This however, would require further
changes in the DM aware (converted) drivers.

> > > 
> > > Also, the SPL size check should be really done after the multi
> > > fit image is concatenated so that we can have a chance to detect
> > > such size overflow in build time.  
> > 
> > Agree. I also meet that SPL size is too large on i.MX8/8M, although
> > still have OCRAM for it.  
> 
> As came up in another thread, CONFIG_MMC_TINY may be more widely
> useable and should help with space.
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpo5GG8uMeV5.pgp
Description: OpenPGP digital signature

Re: [U-Boot] RSA in U-Boot

2019-05-21 Thread AKASHI Takahiro

Wolfgang,

Thank you for your comments.

On Fri, May 17, 2019 at 10:47:56AM +0200, Wolfgang Denk wrote:
> Dear Akashi Takahiro,
> 
> In message <20190517001206.gx11...@linaro.org> you wrote:
> >
> > > Who: usually the responsible custodians
> >
> > "Custodians" don't always mean sub-system maintainers. Right?
> 
> It's just a different name for the same thing.

Okay.

> > In fact, I have already imported relevant kernel code into U-Boot
> > and it now works perfectly with my experimental UEFI secure boot patch,
> > but see the total size (and numbers) of files imported is quite big.
> > I wonder who is willing to maintain them:
> ...
> >  37 files changed, 6409 insertions(+), 11 deletions(-)
> 
> Well, if you compare for example against  libressl-portable , then
> this git repository has 180 files with more than 20,000 lines.

I think that there are two different approaches in using
external code (library).
1.import necessary source files into U-Boot repository, customize them
  and build them with the rest of U-Boot
2.build it as a static library, either totally outside of U-Boot
  or as a git submodule, and link it, i.e. only needed binary blobs,
  to U-Boot.
  (I don't know any existing libraries like this in U-Boot though.)

We can adopt only (1) for kernel code, but *in general* (2) as well
for a library. That way, we may potentially save/minimize our own
maintenance cost, again *in general.*

Those said, it seems to me that, gnutls, for instance, is not well
optimized for smaller (or purpose-specific) systems. For example,
_wrap_nettle_pk_verify(), public key verification function, supports
not only RSA, but also DSA, ECDSA and so on with no "opt-out" options
while UEFI secure boot only needs and supports RSA.

> We are adding a lot of functionality, and anyone who wants to use
> this will have to pay the price.  But this is what I mentioned
> before:  I think the kernel code has already been tweaked with an
> eye on resource consumption, while standard public libraries have
> not.

I'm not very sure about your last statement above, but as far as
the customisability is concerned some libraries may have an issue
in (2) as I mentioned above.

In this sense, I still want to seek a possibility of using other
smaller libraries, like mbedTLS.
(mbedTLS has another issue, lacking pkcs7 parser.)

> The kernel code may be big, but I would be surprised if there are
> smaller and leaner alternatives with similar quality?
> 
> As for who is willing to maintain it: I have no idea.  Usually it
> turns out to be the original implementoer / who pushed the code
> upstream into U-Boot.

Okay, but for most of examples you mentioned as linux-origin code,
there are no explicit maintainers. Right?

-Takahiro Akashi

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> miracle:  an  extremely  outstanding  or  unusual  event,  thing,  or
> accomplishment.- Webster's Dictionary
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] video: Add dependency for VIDEO_IMX_HDP_LOAD

2019-05-21 Thread Alison Wang

As VIDEO_IMX_HDP_LOAD is supported on LS1028A, this patch adds
ARCH_LS1028A dependency for VIDEO_IMX_HDP_LOAD.

Signed-off-by: Alison Wang 
---
 drivers/video/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7aa1727e5b..f1fa25a49e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -552,7 +552,7 @@ config VIDEO
 config VIDEO_IMX_HDP_LOAD
bool "i.MX8 HDMI/DP firmware loading"
default y
-   depends on VIDEO
+   depends on VIDEO && ARCH_LS1028A
help
  Support for HDMI/DP firmware loading for i.MX8QM and LS1028A
  processors. The firmware is copied from system memory to the
-- 
2.17.1

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

[U-Boot] [PATCH v2 4/7] power-domain: Add private data to power domain

Certain drivers want to attach private data corresponding to each
power domain. This data might be specific be to the drvier. So add
a priv entry into the power_domain structure.

Signed-off-by: Lokesh Vutla 
---
 include/power-domain.h | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/include/power-domain.h b/include/power-domain.h
index 00996057b0..ec2b70e0b5 100644
--- a/include/power-domain.h
+++ b/include/power-domain.h
@@ -55,23 +55,12 @@ struct udevice;
  *
  * @dev: The device which implements the power domain.
  * @id: The power domain ID within the provider.
- *
- * Currently, the power domain API assumes that a single integer ID is enough
- * to identify and configure any power domain for any power domain provider. If
- * this assumption becomes invalid in the future, the struct could be expanded
- * to either (a) add more fields to allow power domain providers to store
- * additional information, or (b) replace the id field with an opaque pointer,
- * which the provider would dynamically allocate during its .of_xlate op, and
- * process during is .request op. This may require the addition of an extra op
- * to clean up the allocation.
+ * @priv: Private data corresponding to each power domain.
  */
 struct power_domain {
struct udevice *dev;
-   /*
-* Written by of_xlate. We assume a single id is enough for now. In the
-* future, we might add more fields here.
-*/
unsigned long id;
+   void *priv;
 };
 
 /**
-- 
2.17.1

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

[U-Boot] [PATCH v2 6/7] power: domain: ti_sci_power_domains: Add support for exclusive and shared access

TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.

For keeping the DT backward compatibility intact, defaulting the
device permissions to set the exclusive flag set. In this case the
power-domain-cells is 1.

Signed-off-by: Lokesh Vutla 
---
 drivers/power/domain/ti-sci-power-domain.c | 31 +-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/power/domain/ti-sci-power-domain.c 
b/drivers/power/domain/ti-sci-power-domain.c
index aafde62cbf..b9cd37b612 100644
--- a/drivers/power/domain/ti-sci-power-domain.c
+++ b/drivers/power/domain/ti-sci-power-domain.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct ti_sci_power_domain_data - pm domain controller information structure
@@ -56,11 +57,16 @@ static int ti_sci_power_domain_on(struct power_domain *pd)
struct ti_sci_power_domain_data *data = dev_get_priv(pd->dev);
const struct ti_sci_handle *sci = data->sci;
const struct ti_sci_dev_ops *dops = >ops.dev_ops;
+   u8 flags = (uintptr_t)pd->priv;
int ret;
 
debug("%s(pd=%p)\n", __func__, pd);
 
-   ret = dops->get_device(sci, pd->id);
+   if (flags & TI_SCI_PD_EXCLUSIVE)
+   ret = dops->get_device_exclusive(sci, pd->id);
+   else
+   ret = dops->get_device(sci, pd->id);
+
if (ret)
dev_err(power_domain->dev, "%s: get_device failed (%d)\n",
__func__, ret);
@@ -85,6 +91,28 @@ static int ti_sci_power_domain_off(struct power_domain *pd)
return ret;
 }
 
+static int ti_sci_power_domain_of_xlate(struct power_domain *pd,
+   struct ofnode_phandle_args *args)
+{
+   u8 flags;
+
+   debug("%s(power_domain=%p)\n", __func__, pd);
+
+   if (args->args_count < 1) {
+   debug("Invalid args_count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   pd->id = args->args[0];
+   /* By default request for device exclusive */
+   flags = TI_SCI_PD_EXCLUSIVE;
+   if (args->args_count == 2)
+   flags = args->args[1] & TI_SCI_PD_EXCLUSIVE;
+   pd->priv = (void *)(uintptr_t)flags;
+
+   return 0;
+}
+
 static const struct udevice_id ti_sci_power_domain_of_match[] = {
{ .compatible = "ti,sci-pm-domain" },
{ /* sentinel */ }
@@ -95,6 +123,7 @@ static struct power_domain_ops ti_sci_power_domain_ops = {
.free = ti_sci_power_domain_free,
.on = ti_sci_power_domain_on,
.off = ti_sci_power_domain_off,
+   .of_xlate = ti_sci_power_domain_of_xlate,
 };
 
 U_BOOT_DRIVER(ti_sci_pm_domains) = {
-- 
2.17.1

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

[U-Boot] [PATCH v2 2/7] firmware: ti_sci: Add processor shutdown API method

From: Andreas Dannenberg 

Add and expose a new processor shutdown API that wraps the two TISCI
messages involved in initiating a core shutdown. The API will first
queue a message to have the DMSC wait for a certain processor boot
status to happen followed by a message to trigger the actual shutdown-
with both messages being sent without waiting or requesting for a
response. Note that the processor shutdown API call will need to be
followed up by user software placing the respective core into either
WFE or WFI mode.

Signed-off-by: Andreas Dannenberg 
---
 drivers/firmware/ti_sci.c  | 191 -
 drivers/firmware/ti_sci.h  |  50 +++
 include/linux/soc/ti/ti_sci_protocol.h |   4 +
 3 files changed, 241 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index eadb91e107..8c68f98788 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -101,7 +101,8 @@ struct ti_sci_info {
  * @msg_flags: Flag to set for the message
  * @buf:   Buffer to be send to mailbox channel
  * @tx_message_size: transmit message size
- * @rx_message_size: receive message size
+ * @rx_message_size: receive message size. may be set to zero for send-only
+ *  transactions.
  *
  * Helper function which is used by various command functions that are
  * exposed to clients of this driver for allocating a message traffic event.
@@ -121,7 +122,8 @@ static struct ti_sci_xfer *ti_sci_setup_one_xfer(struct 
ti_sci_info *info,
/* Ensure we have sane transfer sizes */
if (rx_message_size > info->desc->max_msg_size ||
tx_message_size > info->desc->max_msg_size ||
-   rx_message_size < sizeof(*hdr) || tx_message_size < sizeof(*hdr))
+   (rx_message_size > 0 && rx_message_size < sizeof(*hdr)) ||
+   tx_message_size < sizeof(*hdr))
return ERR_PTR(-ERANGE);
 
info->seq = ~info->seq;
@@ -219,7 +221,9 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
 
xfer->tx_message.buf = (u32 *)secure_buf;
xfer->tx_message.len += sizeof(secure_hdr);
-   xfer->rx_len += sizeof(secure_hdr);
+
+   if (xfer->rx_len)
+   xfer->rx_len += sizeof(secure_hdr);
}
 
/* Send the message */
@@ -230,7 +234,11 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
return ret;
}
 
-   return ti_sci_get_response(info, xfer, >chan_rx);
+   /* Get response if requested */
+   if (xfer->rx_len)
+   ret = ti_sci_get_response(info, xfer, >chan_rx);
+
+   return ret;
 }
 
 /**
@@ -469,6 +477,49 @@ static int ti_sci_set_device_state(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_set_device_state_no_wait() - Set device state helper without
+ *requesting or waiting for a response.
+ * @handle:pointer to TI SCI handle
+ * @id:Device identifier
+ * @flags: flags to setup for the device
+ * @state: State to move the device to
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_set_device_state_no_wait(const struct ti_sci_handle *handle,
+  u32 id, u32 flags, u8 state)
+{
+   struct ti_sci_msg_req_set_device_state req;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_SET_DEVICE_STATE,
+flags | TI_SCI_FLAG_REQ_GENERIC_NORESPONSE,
+(u32 *), sizeof(req), 0);
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.id = id;
+   req.state = state;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret)
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+
+   return ret;
+}
+
 /**
  * ti_sci_get_device_state() - Get device state helper
  * @handle:Handle to the device
@@ -2039,6 +2090,137 @@ static int ti_sci_cmd_get_proc_boot_status(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_proc_wait_boot_status_no_wait() - Helper function to wait for a
+ * processor boot status without requesting or
+ * waiting for a response.
+ * @proc_id:   Processor ID this request is for
+ * @num_wait_iterations:   Total number of iterations we will check before
+ * we will timeout and give up
+ * @num_match_iterations:  How many iterations should we

[U-Boot] [PATCH v2 5/7] dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access

TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.

Signed-off-by: Lokesh Vutla 
---
 doc/device-tree-bindings/power/ti,sci-pm-domain.txt | 11 +--
 include/dt-bindings/soc/ti,sci_pm_domain.h  |  9 +
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

diff --git a/doc/device-tree-bindings/power/ti,sci-pm-domain.txt 
b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
index 0e190e20fe..72d9fbc833 100644
--- a/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+++ b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
@@ -17,8 +17,15 @@ child of the sysfw node.
 Required Properties:
 
 - compatible: Must be "ti,sci-pm-domain"
-- #power-domain-cells: Must be 1 so that an id can be provided in each
-  device node.
+- #power-domain-cells: Can be one of the following:
+   1: Containing the device id of each node
+   2: First entry should be device id
+  Second entry should be one of the floowing:
+  TI_SCI_PD_EXCLUSIVE: To allow device to be
+   exclusively controlled by
+   the requesting hosts.
+  TI_SCI_PD_SHARED: To allow device to be shared
+by multiple hosts.
 
 Example (AM65x):
 
diff --git a/include/dt-bindings/soc/ti,sci_pm_domain.h 
b/include/dt-bindings/soc/ti,sci_pm_domain.h
new file mode 100644
index 00..8f2a7360b6
--- /dev/null
+++ b/include/dt-bindings/soc/ti,sci_pm_domain.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
+#define __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
+
+#define TI_SCI_PD_EXCLUSIVE1
+#define TI_SCI_PD_SHARED   0
+
+#endif /* __DT_BINDINGS_TI_SCI_PM_DOMAIN_H */
-- 
2.17.1

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

[U-Boot] [PATCH v2 7/7] armv7R: dts: k3-am654: Update power-domains property for each node

Update the power-domain-cells to 2 and add the permissions
to each node. Mark all the nodes accessed by r5 as shared
in r5 dts.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am65-wakeup.dtsi | 2 +-
 arch/arm/dts/k3-am65.dtsi| 1 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 2 +-
 arch/arm/dts/k3-am654-ddr.dtsi   | 4 ++--
 arch/arm/dts/k3-am654-r5-base-board.dts  | 8 ++--
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1f591ef8bb..9eaecf4cfc 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -20,7 +20,7 @@
 
k3_pds: power-controller {
compatible = "ti,sci-pm-domain";
-   #power-domain-cells = <1>;
+   #power-domain-cells = <2>;
};
 
k3_clks: clocks {
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3d4bf369d0..145e4d219a 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Texas Instruments K3 AM654 SoC";
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 5eaf208e0e..80a04dc1bc 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -32,7 +32,7 @@
reg = <0x0 0x4FA 0x0 0x1000>,
  <0x0 0x4FB 0x0 0x400>;
clocks = <_clks 48 1>;
-   power-domains = <_pds 48>;
+   power-domains = <_pds 48 TI_SCI_PD_SHARED>;
max-frequency = <2500>;
ti,otap-del-sel = <0x2>;
ti,trm-icp = <0x8>;
diff --git a/arch/arm/dts/k3-am654-ddr.dtsi b/arch/arm/dts/k3-am654-ddr.dtsi
index 964eb173eb..622a3edb61 100644
--- a/arch/arm/dts/k3-am654-ddr.dtsi
+++ b/arch/arm/dts/k3-am654-ddr.dtsi
@@ -11,8 +11,8 @@
  <0x0 0x02988000 0x0 0x2000>;
reg-names = "ss", "ctl", "phy";
clocks = <_clks 20 0>;
-   power-domains = <_pds 20>,
-   <_pds 244>;
+   power-domains = <_pds 20 TI_SCI_PD_SHARED>,
+   <_pds 244 TI_SCI_PD_SHARED>;
assigned-clocks = <_clks 20 1>;
assigned-clock-rates = ;
u-boot,dm-spl;
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts 
b/arch/arm/dts/k3-am654-r5-base-board.dts
index a07038be70..9458e4bf0d 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -32,8 +32,8 @@
a53_0: a53@0 {
compatible = "ti,am654-rproc";
reg = <0x0 0x00a9 0x0 0x10>;
-   power-domains = <_pds 61>,
-   <_pds 202>;
+   power-domains = <_pds 61 TI_SCI_PD_SHARED>,
+   <_pds 202 TI_SCI_PD_SHARED>;
resets = <_reset 202 0>;
assigned-clocks = <_clks 202 0>;
assigned-clock-rates = <8>;
@@ -112,6 +112,10 @@
status = "okay";
 };
 
+_uart0 {
+   power-domains = <_pds 146 TI_SCI_PD_SHARED>;
+};
+
 _pmx0 {
u-boot,dm-spl;
wkup_uart0_pins_default: wkup_uart0_pins_default {
-- 
2.17.1

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

[U-Boot] [PATCH v2 3/7] armv7R: K3: am654: Shut down R5 core after ATF startup on A53

From: Andreas Dannenberg 

Rather than simply parking the R5 core in WFE after starting up ATF
on A53 instead use SYSFW API to properly shut down the R5 CPU cores
as well as associated timer resources that were pre-allocated. This
allows software further downstream to properly and gracefully bring
the R5 cores back online if desired.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c   | 62 +++
 arch/arm/mach-k3/common.c |  6 ++-
 arch/arm/mach-k3/include/mach/sys_proto.h |  1 +
 3 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 60a580305d..922bd95580 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -12,6 +12,7 @@
 #include 
 #include "common.h"
 #include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 static void mmr_unlock(u32 base, u32 partition)
@@ -185,3 +186,64 @@ void reset_cpu(ulong ignored)
 {
 }
 #endif
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+
+#define AM6_DEV_MCU_RTI0   134
+#define AM6_DEV_MCU_RTI1   135
+#define AM6_DEV_MCU_ARMSS0_CPU0159
+#define AM6_DEV_MCU_ARMSS0_CPU1245
+
+void release_resources_for_core_shutdown(void)
+{
+   struct udevice *dev;
+   struct ti_sci_handle *ti_sci;
+   struct ti_sci_dev_ops *dev_ops;
+   struct ti_sci_proc_ops *proc_ops;
+   int ret;
+   u32 i;
+
+   const u32 put_device_ids[] = {
+   AM6_DEV_MCU_RTI0,
+   AM6_DEV_MCU_RTI1,
+   };
+
+   /* Get handle to Device Management and Security Controller (SYSFW) */
+   ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", );
+   if (ret)
+   panic("Failed to get handle to SYSFW (%d)\n", ret);
+
+   ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+   dev_ops = _sci->ops.dev_ops;
+   proc_ops = _sci->ops.proc_ops;
+
+   /* Iterate through list of devices to put (shutdown) */
+   for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
+   u32 id = put_device_ids[i];
+
+   ret = dev_ops->put_device(ti_sci, id);
+   if (ret)
+   panic("Failed to put device %u (%d)\n", id, ret);
+   }
+
+   const u32 put_core_ids[] = {
+   AM6_DEV_MCU_ARMSS0_CPU1,
+   AM6_DEV_MCU_ARMSS0_CPU0,/* Handle CPU0 after CPU1 */
+   };
+
+   /* Iterate through list of cores to put (shutdown) */
+   for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
+   u32 id = put_core_ids[i];
+
+   /*
+* Queue up the core shutdown request. Note that this call
+* needs to be followed up by an actual invocation of an WFE
+* or WFI CPU instruction.
+*/
+   ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
+   if (ret)
+   panic("Failed sending core %u shutdown message (%d)\n",
+ id, ret);
+   }
+}
+#endif
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 03f01d07ea..ee84d44de8 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct ti_sci_handle *get_ti_sci_handle(void)
 {
@@ -51,7 +52,10 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
*spl_image)
if (ret)
panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
 
-   debug("ATF started. Waiting indefinitely...\n");
+   debug("Releasing resources...\n");
+   release_resources_for_core_shutdown();
+
+   debug("Finalizing core shutdown...\n");
while (1)
asm volatile("wfe");
 }
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h 
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 018725b4d1..2fa53682ad 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -12,4 +12,5 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, void 
*read_addr,
  u32 bound);
 struct ti_sci_handle *get_ti_sci_handle(void);
 int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name);
+void release_resources_for_core_shutdown(void);
 #endif
-- 
2.17.1

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

[U-Boot] [PATCH v2 1/7] firmware: ti_sci: Allow for device shared and exclusive requests

Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw. Current tisci
driver enables this flag for every device requests. But this may not
be true for all the devices. So provide a separate commands in driver
for exclusive and shared device requests.

Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 25 -
 include/linux/soc/ti/ti_sci_protocol.h |  3 +++
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 303aa6a631..eadb91e107 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -547,8 +547,14 @@ static int ti_sci_get_device_state(const struct 
ti_sci_handle *handle,
  */
 static int ti_sci_cmd_get_device(const struct ti_sci_handle *handle, u32 id)
 {
-   return ti_sci_set_device_state(handle, id,
-  MSG_FLAG_DEVICE_EXCLUSIVE,
+   return ti_sci_set_device_state(handle, id, 0,
+  MSG_DEVICE_SW_STATE_ON);
+}
+
+static int ti_sci_cmd_get_device_exclusive(const struct ti_sci_handle *handle,
+  u32 id)
+{
+   return ti_sci_set_device_state(handle, id, MSG_FLAG_DEVICE_EXCLUSIVE,
   MSG_DEVICE_SW_STATE_ON);
 }
 
@@ -566,7 +572,14 @@ static int ti_sci_cmd_get_device(const struct 
ti_sci_handle *handle, u32 id)
 static int ti_sci_cmd_idle_device(const struct ti_sci_handle *handle, u32 id)
 {
return ti_sci_set_device_state(handle, id,
-  MSG_FLAG_DEVICE_EXCLUSIVE,
+  0,
+  MSG_DEVICE_SW_STATE_RETENTION);
+}
+
+static int ti_sci_cmd_idle_device_exclusive(const struct ti_sci_handle *handle,
+   u32 id)
+{
+   return ti_sci_set_device_state(handle, id, MSG_FLAG_DEVICE_EXCLUSIVE,
   MSG_DEVICE_SW_STATE_RETENTION);
 }
 
@@ -583,8 +596,8 @@ static int ti_sci_cmd_idle_device(const struct 
ti_sci_handle *handle, u32 id)
  */
 static int ti_sci_cmd_put_device(const struct ti_sci_handle *handle, u32 id)
 {
-   return ti_sci_set_device_state(handle, id,
-  0, MSG_DEVICE_SW_STATE_AUTO_OFF);
+   return ti_sci_set_device_state(handle, id, 0,
+  MSG_DEVICE_SW_STATE_AUTO_OFF);
 }
 
 /**
@@ -2632,7 +2645,9 @@ static void ti_sci_setup_ops(struct ti_sci_info *info)
bops->board_config_pm = ti_sci_cmd_set_board_config_pm;
 
dops->get_device = ti_sci_cmd_get_device;
+   dops->get_device_exclusive = ti_sci_cmd_get_device_exclusive;
dops->idle_device = ti_sci_cmd_idle_device;
+   dops->idle_device_exclusive = ti_sci_cmd_idle_device_exclusive;
dops->put_device = ti_sci_cmd_put_device;
dops->is_valid = ti_sci_cmd_dev_is_valid;
dops->get_context_loss_count = ti_sci_cmd_dev_get_clcnt;
diff --git a/include/linux/soc/ti/ti_sci_protocol.h 
b/include/linux/soc/ti/ti_sci_protocol.h
index c57802f293..842fb596f7 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -117,7 +117,10 @@ struct ti_sci_board_ops {
  */
 struct ti_sci_dev_ops {
int (*get_device)(const struct ti_sci_handle *handle, u32 id);
+   int (*get_device_exclusive)(const struct ti_sci_handle *handle, u32 id);
int (*idle_device)(const struct ti_sci_handle *handle, u32 id);
+   int (*idle_device_exclusive)(const struct ti_sci_handle *handle,
+u32 id);
int (*put_device)(const struct ti_sci_handle *handle, u32 id);
int (*is_valid)(const struct ti_sci_handle *handle, u32 id);
int (*get_context_loss_count)(const struct ti_sci_handle *handle,
-- 
2.17.1

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

[U-Boot] [PATCH v2 0/7] arm: k3: Allow for exclusive and shared device requests

Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw.

Current tisci firmware and pm drivers always requests for device with
exclusive permissions set. But this is not be true for certain devices
that are expcted to be shared across different host contexts.
So add support for getting the shared or exclusive permissions from DT
and request firmware accordingly.

Same bindings are acked in kernel: 
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=103447

Also this series adds support for shutting down cores so that R5 cores
can be shutdown right after jumping to ATF.

Changes since v2:
- Dropped patch 8.

Andreas Dannenberg (2):
  firmware: ti_sci: Add processor shutdown API method
  armv7R: K3: am654: Shut down R5 core after ATF startup on A53

Lokesh Vutla (5):
  firmware: ti_sci: Allow for device shared and exclusive requests
  power-domain: Add private data to power domain
  dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
access
  power: domain: ti_sci_power_domains: Add support for exclusive and
shared access
  armv7R: dts: k3-am654: Update power-domains property for each node

 arch/arm/dts/k3-am65-wakeup.dtsi  |   2 +-
 arch/arm/dts/k3-am65.dtsi |   1 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |   2 +-
 arch/arm/dts/k3-am654-ddr.dtsi|   4 +-
 arch/arm/dts/k3-am654-r5-base-board.dts   |   8 +-
 arch/arm/mach-k3/am6_init.c   |  62 +
 arch/arm/mach-k3/common.c |   6 +-
 arch/arm/mach-k3/include/mach/sys_proto.h |   1 +
 .../power/ti,sci-pm-domain.txt|  11 +-
 drivers/firmware/ti_sci.c | 216 +-
 drivers/firmware/ti_sci.h |  50 
 drivers/power/domain/ti-sci-power-domain.c|  31 ++-
 include/dt-bindings/soc/ti,sci_pm_domain.h|   9 +
 include/linux/soc/ti/ti_sci_protocol.h|   7 +
 include/power-domain.h|  15 +-
 15 files changed, 393 insertions(+), 32 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

-- 
2.17.1

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

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



On 21/05/19 11:27 PM, Lokesh Vutla wrote:
> '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 

Oops. This should be part of my next series. Will re send the series by dropping
the patch.

Thanks and regards,
Lokesh

> ---
>  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"
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/8] dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access

TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.

Signed-off-by: Lokesh Vutla 
---
 doc/device-tree-bindings/power/ti,sci-pm-domain.txt | 11 +--
 include/dt-bindings/soc/ti,sci_pm_domain.h  |  9 +
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

diff --git a/doc/device-tree-bindings/power/ti,sci-pm-domain.txt 
b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
index 0e190e20fe..72d9fbc833 100644
--- a/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+++ b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
@@ -17,8 +17,15 @@ child of the sysfw node.
 Required Properties:
 
 - compatible: Must be "ti,sci-pm-domain"
-- #power-domain-cells: Must be 1 so that an id can be provided in each
-  device node.
+- #power-domain-cells: Can be one of the following:
+   1: Containing the device id of each node
+   2: First entry should be device id
+  Second entry should be one of the floowing:
+  TI_SCI_PD_EXCLUSIVE: To allow device to be
+   exclusively controlled by
+   the requesting hosts.
+  TI_SCI_PD_SHARED: To allow device to be shared
+by multiple hosts.
 
 Example (AM65x):
 
diff --git a/include/dt-bindings/soc/ti,sci_pm_domain.h 
b/include/dt-bindings/soc/ti,sci_pm_domain.h
new file mode 100644
index 00..8f2a7360b6
--- /dev/null
+++ b/include/dt-bindings/soc/ti,sci_pm_domain.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
+#define __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
+
+#define TI_SCI_PD_EXCLUSIVE1
+#define TI_SCI_PD_SHARED   0
+
+#endif /* __DT_BINDINGS_TI_SCI_PM_DOMAIN_H */
-- 
2.17.1

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

[U-Boot] [PATCH 3/8] armv7R: K3: am654: Shut down R5 core after ATF startup on A53

From: Andreas Dannenberg 

Rather than simply parking the R5 core in WFE after starting up ATF
on A53 instead use SYSFW API to properly shut down the R5 CPU cores
as well as associated timer resources that were pre-allocated. This
allows software further downstream to properly and gracefully bring
the R5 cores back online if desired.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c   | 62 +++
 arch/arm/mach-k3/common.c |  6 ++-
 arch/arm/mach-k3/include/mach/sys_proto.h |  1 +
 3 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 60a580305d..922bd95580 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -12,6 +12,7 @@
 #include 
 #include "common.h"
 #include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 static void mmr_unlock(u32 base, u32 partition)
@@ -185,3 +186,64 @@ void reset_cpu(ulong ignored)
 {
 }
 #endif
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+
+#define AM6_DEV_MCU_RTI0   134
+#define AM6_DEV_MCU_RTI1   135
+#define AM6_DEV_MCU_ARMSS0_CPU0159
+#define AM6_DEV_MCU_ARMSS0_CPU1245
+
+void release_resources_for_core_shutdown(void)
+{
+   struct udevice *dev;
+   struct ti_sci_handle *ti_sci;
+   struct ti_sci_dev_ops *dev_ops;
+   struct ti_sci_proc_ops *proc_ops;
+   int ret;
+   u32 i;
+
+   const u32 put_device_ids[] = {
+   AM6_DEV_MCU_RTI0,
+   AM6_DEV_MCU_RTI1,
+   };
+
+   /* Get handle to Device Management and Security Controller (SYSFW) */
+   ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", );
+   if (ret)
+   panic("Failed to get handle to SYSFW (%d)\n", ret);
+
+   ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+   dev_ops = _sci->ops.dev_ops;
+   proc_ops = _sci->ops.proc_ops;
+
+   /* Iterate through list of devices to put (shutdown) */
+   for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
+   u32 id = put_device_ids[i];
+
+   ret = dev_ops->put_device(ti_sci, id);
+   if (ret)
+   panic("Failed to put device %u (%d)\n", id, ret);
+   }
+
+   const u32 put_core_ids[] = {
+   AM6_DEV_MCU_ARMSS0_CPU1,
+   AM6_DEV_MCU_ARMSS0_CPU0,/* Handle CPU0 after CPU1 */
+   };
+
+   /* Iterate through list of cores to put (shutdown) */
+   for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
+   u32 id = put_core_ids[i];
+
+   /*
+* Queue up the core shutdown request. Note that this call
+* needs to be followed up by an actual invocation of an WFE
+* or WFI CPU instruction.
+*/
+   ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
+   if (ret)
+   panic("Failed sending core %u shutdown message (%d)\n",
+ id, ret);
+   }
+}
+#endif
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 03f01d07ea..ee84d44de8 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct ti_sci_handle *get_ti_sci_handle(void)
 {
@@ -51,7 +52,10 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
*spl_image)
if (ret)
panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
 
-   debug("ATF started. Waiting indefinitely...\n");
+   debug("Releasing resources...\n");
+   release_resources_for_core_shutdown();
+
+   debug("Finalizing core shutdown...\n");
while (1)
asm volatile("wfe");
 }
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h 
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 018725b4d1..2fa53682ad 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -12,4 +12,5 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, void 
*read_addr,
  u32 bound);
 struct ti_sci_handle *get_ti_sci_handle(void);
 int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name);
+void release_resources_for_core_shutdown(void);
 #endif
-- 
2.17.1

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

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

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

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

[U-Boot] [PATCH 7/8] armv7R: dts: k3-am654: Update power-domains property for each node

Update the power-domain-cells to 2 and add the permissions
to each node. Mark all the nodes accessed by r5 as shared
in r5 dts.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am65-wakeup.dtsi | 2 +-
 arch/arm/dts/k3-am65.dtsi| 1 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 2 +-
 arch/arm/dts/k3-am654-ddr.dtsi   | 4 ++--
 arch/arm/dts/k3-am654-r5-base-board.dts  | 8 ++--
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1f591ef8bb..9eaecf4cfc 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -20,7 +20,7 @@
 
k3_pds: power-controller {
compatible = "ti,sci-pm-domain";
-   #power-domain-cells = <1>;
+   #power-domain-cells = <2>;
};
 
k3_clks: clocks {
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3d4bf369d0..145e4d219a 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Texas Instruments K3 AM654 SoC";
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 5eaf208e0e..80a04dc1bc 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -32,7 +32,7 @@
reg = <0x0 0x4FA 0x0 0x1000>,
  <0x0 0x4FB 0x0 0x400>;
clocks = <_clks 48 1>;
-   power-domains = <_pds 48>;
+   power-domains = <_pds 48 TI_SCI_PD_SHARED>;
max-frequency = <2500>;
ti,otap-del-sel = <0x2>;
ti,trm-icp = <0x8>;
diff --git a/arch/arm/dts/k3-am654-ddr.dtsi b/arch/arm/dts/k3-am654-ddr.dtsi
index 964eb173eb..622a3edb61 100644
--- a/arch/arm/dts/k3-am654-ddr.dtsi
+++ b/arch/arm/dts/k3-am654-ddr.dtsi
@@ -11,8 +11,8 @@
  <0x0 0x02988000 0x0 0x2000>;
reg-names = "ss", "ctl", "phy";
clocks = <_clks 20 0>;
-   power-domains = <_pds 20>,
-   <_pds 244>;
+   power-domains = <_pds 20 TI_SCI_PD_SHARED>,
+   <_pds 244 TI_SCI_PD_SHARED>;
assigned-clocks = <_clks 20 1>;
assigned-clock-rates = ;
u-boot,dm-spl;
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts 
b/arch/arm/dts/k3-am654-r5-base-board.dts
index a07038be70..9458e4bf0d 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -32,8 +32,8 @@
a53_0: a53@0 {
compatible = "ti,am654-rproc";
reg = <0x0 0x00a9 0x0 0x10>;
-   power-domains = <_pds 61>,
-   <_pds 202>;
+   power-domains = <_pds 61 TI_SCI_PD_SHARED>,
+   <_pds 202 TI_SCI_PD_SHARED>;
resets = <_reset 202 0>;
assigned-clocks = <_clks 202 0>;
assigned-clock-rates = <8>;
@@ -112,6 +112,10 @@
status = "okay";
 };
 
+_uart0 {
+   power-domains = <_pds 146 TI_SCI_PD_SHARED>;
+};
+
 _pmx0 {
u-boot,dm-spl;
wkup_uart0_pins_default: wkup_uart0_pins_default {
-- 
2.17.1

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

[U-Boot] [PATCH 4/8] power-domain: Add private data to power domain

Certain drivers want to attach private data corresponding to each
power domain. This data might be specific be to the drvier. So add
a priv entry into the power_domain structure.

Signed-off-by: Lokesh Vutla 
---
 include/power-domain.h | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/include/power-domain.h b/include/power-domain.h
index 00996057b0..ec2b70e0b5 100644
--- a/include/power-domain.h
+++ b/include/power-domain.h
@@ -55,23 +55,12 @@ struct udevice;
  *
  * @dev: The device which implements the power domain.
  * @id: The power domain ID within the provider.
- *
- * Currently, the power domain API assumes that a single integer ID is enough
- * to identify and configure any power domain for any power domain provider. If
- * this assumption becomes invalid in the future, the struct could be expanded
- * to either (a) add more fields to allow power domain providers to store
- * additional information, or (b) replace the id field with an opaque pointer,
- * which the provider would dynamically allocate during its .of_xlate op, and
- * process during is .request op. This may require the addition of an extra op
- * to clean up the allocation.
+ * @priv: Private data corresponding to each power domain.
  */
 struct power_domain {
struct udevice *dev;
-   /*
-* Written by of_xlate. We assume a single id is enough for now. In the
-* future, we might add more fields here.
-*/
unsigned long id;
+   void *priv;
 };
 
 /**
-- 
2.17.1

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

[U-Boot] [PATCH 6/8] power: domain: ti_sci_power_domains: Add support for exclusive and shared access

TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.

For keeping the DT backward compatibility intact, defaulting the
device permissions to set the exclusive flag set. In this case the
power-domain-cells is 1.

Signed-off-by: Lokesh Vutla 
---
 drivers/power/domain/ti-sci-power-domain.c | 31 +-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/power/domain/ti-sci-power-domain.c 
b/drivers/power/domain/ti-sci-power-domain.c
index aafde62cbf..b9cd37b612 100644
--- a/drivers/power/domain/ti-sci-power-domain.c
+++ b/drivers/power/domain/ti-sci-power-domain.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct ti_sci_power_domain_data - pm domain controller information structure
@@ -56,11 +57,16 @@ static int ti_sci_power_domain_on(struct power_domain *pd)
struct ti_sci_power_domain_data *data = dev_get_priv(pd->dev);
const struct ti_sci_handle *sci = data->sci;
const struct ti_sci_dev_ops *dops = >ops.dev_ops;
+   u8 flags = (uintptr_t)pd->priv;
int ret;
 
debug("%s(pd=%p)\n", __func__, pd);
 
-   ret = dops->get_device(sci, pd->id);
+   if (flags & TI_SCI_PD_EXCLUSIVE)
+   ret = dops->get_device_exclusive(sci, pd->id);
+   else
+   ret = dops->get_device(sci, pd->id);
+
if (ret)
dev_err(power_domain->dev, "%s: get_device failed (%d)\n",
__func__, ret);
@@ -85,6 +91,28 @@ static int ti_sci_power_domain_off(struct power_domain *pd)
return ret;
 }
 
+static int ti_sci_power_domain_of_xlate(struct power_domain *pd,
+   struct ofnode_phandle_args *args)
+{
+   u8 flags;
+
+   debug("%s(power_domain=%p)\n", __func__, pd);
+
+   if (args->args_count < 1) {
+   debug("Invalid args_count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   pd->id = args->args[0];
+   /* By default request for device exclusive */
+   flags = TI_SCI_PD_EXCLUSIVE;
+   if (args->args_count == 2)
+   flags = args->args[1] & TI_SCI_PD_EXCLUSIVE;
+   pd->priv = (void *)(uintptr_t)flags;
+
+   return 0;
+}
+
 static const struct udevice_id ti_sci_power_domain_of_match[] = {
{ .compatible = "ti,sci-pm-domain" },
{ /* sentinel */ }
@@ -95,6 +123,7 @@ static struct power_domain_ops ti_sci_power_domain_ops = {
.free = ti_sci_power_domain_free,
.on = ti_sci_power_domain_on,
.off = ti_sci_power_domain_off,
+   .of_xlate = ti_sci_power_domain_of_xlate,
 };
 
 U_BOOT_DRIVER(ti_sci_pm_domains) = {
-- 
2.17.1

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

[U-Boot] [PATCH 2/8] firmware: ti_sci: Add processor shutdown API method

From: Andreas Dannenberg 

Add and expose a new processor shutdown API that wraps the two TISCI
messages involved in initiating a core shutdown. The API will first
queue a message to have the DMSC wait for a certain processor boot
status to happen followed by a message to trigger the actual shutdown-
with both messages being sent without waiting or requesting for a
response. Note that the processor shutdown API call will need to be
followed up by user software placing the respective core into either
WFE or WFI mode.

Signed-off-by: Andreas Dannenberg 
---
 drivers/firmware/ti_sci.c  | 191 -
 drivers/firmware/ti_sci.h  |  50 +++
 include/linux/soc/ti/ti_sci_protocol.h |   4 +
 3 files changed, 241 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index eadb91e107..8c68f98788 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -101,7 +101,8 @@ struct ti_sci_info {
  * @msg_flags: Flag to set for the message
  * @buf:   Buffer to be send to mailbox channel
  * @tx_message_size: transmit message size
- * @rx_message_size: receive message size
+ * @rx_message_size: receive message size. may be set to zero for send-only
+ *  transactions.
  *
  * Helper function which is used by various command functions that are
  * exposed to clients of this driver for allocating a message traffic event.
@@ -121,7 +122,8 @@ static struct ti_sci_xfer *ti_sci_setup_one_xfer(struct 
ti_sci_info *info,
/* Ensure we have sane transfer sizes */
if (rx_message_size > info->desc->max_msg_size ||
tx_message_size > info->desc->max_msg_size ||
-   rx_message_size < sizeof(*hdr) || tx_message_size < sizeof(*hdr))
+   (rx_message_size > 0 && rx_message_size < sizeof(*hdr)) ||
+   tx_message_size < sizeof(*hdr))
return ERR_PTR(-ERANGE);
 
info->seq = ~info->seq;
@@ -219,7 +221,9 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
 
xfer->tx_message.buf = (u32 *)secure_buf;
xfer->tx_message.len += sizeof(secure_hdr);
-   xfer->rx_len += sizeof(secure_hdr);
+
+   if (xfer->rx_len)
+   xfer->rx_len += sizeof(secure_hdr);
}
 
/* Send the message */
@@ -230,7 +234,11 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
return ret;
}
 
-   return ti_sci_get_response(info, xfer, >chan_rx);
+   /* Get response if requested */
+   if (xfer->rx_len)
+   ret = ti_sci_get_response(info, xfer, >chan_rx);
+
+   return ret;
 }
 
 /**
@@ -469,6 +477,49 @@ static int ti_sci_set_device_state(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_set_device_state_no_wait() - Set device state helper without
+ *requesting or waiting for a response.
+ * @handle:pointer to TI SCI handle
+ * @id:Device identifier
+ * @flags: flags to setup for the device
+ * @state: State to move the device to
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_set_device_state_no_wait(const struct ti_sci_handle *handle,
+  u32 id, u32 flags, u8 state)
+{
+   struct ti_sci_msg_req_set_device_state req;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_SET_DEVICE_STATE,
+flags | TI_SCI_FLAG_REQ_GENERIC_NORESPONSE,
+(u32 *), sizeof(req), 0);
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.id = id;
+   req.state = state;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret)
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+
+   return ret;
+}
+
 /**
  * ti_sci_get_device_state() - Get device state helper
  * @handle:Handle to the device
@@ -2039,6 +2090,137 @@ static int ti_sci_cmd_get_proc_boot_status(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_proc_wait_boot_status_no_wait() - Helper function to wait for a
+ * processor boot status without requesting or
+ * waiting for a response.
+ * @proc_id:   Processor ID this request is for
+ * @num_wait_iterations:   Total number of iterations we will check before
+ * we will timeout and give up
+ * @num_match_iterations:  How many iterations should we

[U-Boot] [PATCH 1/8] firmware: ti_sci: Allow for device shared and exclusive requests

Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw. Current tisci
driver enables this flag for every device requests. But this may not
be true for all the devices. So provide a separate commands in driver
for exclusive and shared device requests.

Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 25 -
 include/linux/soc/ti/ti_sci_protocol.h |  3 +++
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 303aa6a631..eadb91e107 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -547,8 +547,14 @@ static int ti_sci_get_device_state(const struct 
ti_sci_handle *handle,
  */
 static int ti_sci_cmd_get_device(const struct ti_sci_handle *handle, u32 id)
 {
-   return ti_sci_set_device_state(handle, id,
-  MSG_FLAG_DEVICE_EXCLUSIVE,
+   return ti_sci_set_device_state(handle, id, 0,
+  MSG_DEVICE_SW_STATE_ON);
+}
+
+static int ti_sci_cmd_get_device_exclusive(const struct ti_sci_handle *handle,
+  u32 id)
+{
+   return ti_sci_set_device_state(handle, id, MSG_FLAG_DEVICE_EXCLUSIVE,
   MSG_DEVICE_SW_STATE_ON);
 }
 
@@ -566,7 +572,14 @@ static int ti_sci_cmd_get_device(const struct 
ti_sci_handle *handle, u32 id)
 static int ti_sci_cmd_idle_device(const struct ti_sci_handle *handle, u32 id)
 {
return ti_sci_set_device_state(handle, id,
-  MSG_FLAG_DEVICE_EXCLUSIVE,
+  0,
+  MSG_DEVICE_SW_STATE_RETENTION);
+}
+
+static int ti_sci_cmd_idle_device_exclusive(const struct ti_sci_handle *handle,
+   u32 id)
+{
+   return ti_sci_set_device_state(handle, id, MSG_FLAG_DEVICE_EXCLUSIVE,
   MSG_DEVICE_SW_STATE_RETENTION);
 }
 
@@ -583,8 +596,8 @@ static int ti_sci_cmd_idle_device(const struct 
ti_sci_handle *handle, u32 id)
  */
 static int ti_sci_cmd_put_device(const struct ti_sci_handle *handle, u32 id)
 {
-   return ti_sci_set_device_state(handle, id,
-  0, MSG_DEVICE_SW_STATE_AUTO_OFF);
+   return ti_sci_set_device_state(handle, id, 0,
+  MSG_DEVICE_SW_STATE_AUTO_OFF);
 }
 
 /**
@@ -2632,7 +2645,9 @@ static void ti_sci_setup_ops(struct ti_sci_info *info)
bops->board_config_pm = ti_sci_cmd_set_board_config_pm;
 
dops->get_device = ti_sci_cmd_get_device;
+   dops->get_device_exclusive = ti_sci_cmd_get_device_exclusive;
dops->idle_device = ti_sci_cmd_idle_device;
+   dops->idle_device_exclusive = ti_sci_cmd_idle_device_exclusive;
dops->put_device = ti_sci_cmd_put_device;
dops->is_valid = ti_sci_cmd_dev_is_valid;
dops->get_context_loss_count = ti_sci_cmd_dev_get_clcnt;
diff --git a/include/linux/soc/ti/ti_sci_protocol.h 
b/include/linux/soc/ti/ti_sci_protocol.h
index c57802f293..842fb596f7 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -117,7 +117,10 @@ struct ti_sci_board_ops {
  */
 struct ti_sci_dev_ops {
int (*get_device)(const struct ti_sci_handle *handle, u32 id);
+   int (*get_device_exclusive)(const struct ti_sci_handle *handle, u32 id);
int (*idle_device)(const struct ti_sci_handle *handle, u32 id);
+   int (*idle_device_exclusive)(const struct ti_sci_handle *handle,
+u32 id);
int (*put_device)(const struct ti_sci_handle *handle, u32 id);
int (*is_valid)(const struct ti_sci_handle *handle, u32 id);
int (*get_context_loss_count)(const struct ti_sci_handle *handle,
-- 
2.17.1

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

[U-Boot] [PATCH 0/8] arm: k3: Allow for exclusive and shared device requests

Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw.

Current tisci firmware and pm drivers always requests for device with
exclusive permissions set. But this is not be true for certain devices
that are expcted to be shared across different host contexts.
So add support for getting the shared or exclusive permissions from DT
and request firmware accordingly.

Same bindings are acked in kernel: 
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=103447

Also this series adds support for shutting down cores so that R5 cores
can be shutdown right after jumping to ATF.

Andreas Dannenberg (2):
  firmware: ti_sci: Add processor shutdown API method
  armv7R: K3: am654: Shut down R5 core after ATF startup on A53

Lokesh Vutla (6):
  firmware: ti_sci: Allow for device shared and exclusive requests
  power-domain: Add private data to power domain
  dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
access
  power: domain: ti_sci_power_domains: Add support for exclusive and
shared access
  armv7R: dts: k3-am654: Update power-domains property for each node
  cmd: remoteproc: Add support for initializing devices individually

 arch/arm/dts/k3-am65-wakeup.dtsi  |   2 +-
 arch/arm/dts/k3-am65.dtsi |   1 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |   2 +-
 arch/arm/dts/k3-am654-ddr.dtsi|   4 +-
 arch/arm/dts/k3-am654-r5-base-board.dts   |   8 +-
 arch/arm/mach-k3/am6_init.c   |  62 +
 arch/arm/mach-k3/common.c |   6 +-
 arch/arm/mach-k3/include/mach/sys_proto.h |   1 +
 cmd/remoteproc.c  |  23 +-
 .../power/ti,sci-pm-domain.txt|  11 +-
 drivers/firmware/ti_sci.c | 216 +-
 drivers/firmware/ti_sci.h |  50 
 drivers/power/domain/ti-sci-power-domain.c|  31 ++-
 include/dt-bindings/soc/ti,sci_pm_domain.h|   9 +
 include/linux/soc/ti/ti_sci_protocol.h|   7 +
 include/power-domain.h|  15 +-
 16 files changed, 411 insertions(+), 37 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

-- 
2.17.1

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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-21 Thread Peng Fan

Hi Lukasz,

> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年5月21日 16:33
> To: Peng Fan 
> Cc: Marek Vasut ; Marek Vasut ;
> Simon Glass ; u-boot@lists.denx.de; Tien Fong Chee
> ; York Sun ; dl-uboot-imx
> 
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> Hi Peng,
> 
> > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > > container format file
> > >
> > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > [...]
> > >
> > > > I do not know how other SoC vendor did FIT hardware secure
> > > > boot, please share you have any information.
> > > 
> > >  The SPL can be in the custom format, but then can load fitImage
> > >  with the next stage(s), right ?
> > > >>>
> > > >>> I am not able to follow you, could you share more details?
> > > >>
> > > >> Wrap the SPL into this custom format and then have the SPL
> > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > > >> etc). Would that work ?
> > > >
> > > > It not work.
> > > > We already wrap SPL in i.MX container format, this patchset is to
> > > > let SPL could load the 2nd container file which contains
> > > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > > authentication, because ROM not know fitimage, it only know i.MX
> > > > container format.
> > >
> > > It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> > > BootROM already authenticated and started the U-Boot SPL, so that's
> > > a trusted code. Now this trusted code can authenticate and start the
> > > next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out
> > > of the picture at this point.
> >
> > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API
> > for others to use, sc_seco_authenticate is the API that used for
> > authentication. I could not share more information about this API
> > works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc,
> > sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
> >
> > SPL will call this API, one parameter is address which needs a
> > container image there.
> 
> Please consider following scenario (I think that this is in sync with Marek's
> point):
> 
> 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised an
> checked by secure code in ROM.
> 
> 2. Then we do have SPL "trusted". It is up to SPL to:
> 
> 2.1. Use its private key to check u-boot, dtb, etc embedded into FitImage (as
> written here: ./doc/uImage.FIT/verified-boot.txt).
> 
> 2.2. Use crypto engine (it's API) with fused keys to speed-up the process of
> boot (by HW support to check the binary). Such approach is in i.MX6Q.

I suppose you talking HAB.

> 
> 
> By using above approach we do have the NXP's "container" format only seen
> in the SPL (which is OK, as for example Samsung does similar thing with
> FBL/BL1). When SPL is "trused" we may use available facilities.

The issue to me is that sc_seco_authenticate could not take a FIT image
as input.

If I switch to FIT, I need to use FIT to wrap a container image, it does not
make sense to me.

Thanks,
Peng.
> 
> >
> > >
> > > > For authentication, we always let ROM to authenticate including
> > > > SPL authenticating U-Boot, so we need pass an image to ROM that
> > > > ROM could recognize when SPL booting 2nd image.
> > >
> > > Shouldn't the CPU have some sort of facility, like a crypto engine,
> > > which authenticates whatever blob with the right signature against a
> > > key burned into the CPU ? If so, then you would just implement a
> > > crypto driver and pass the blob and signature to it. I suspect
> > > that's how it should work, how else would Linux be able to make use
> > > of these secure bits if it cannot call the bootrom anymore ?
> >
> > sc_seco_authenticate on i.MX8 will always be available. It is exported
> > by a runtime firmware running on a Cortex-M core inside i.MX8. The API
> > will do authentication, its accepts container format image as input
> > and no other format.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > --
> > > Best regards,
> > > Marek Vasut
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] efi_loader: efi_runtime_detach()?

2019-05-21 Thread AKASHI Takahiro

Alex,

It seems to me that the current efi_runtime_detach() has
two meanings:
* changes relating to the transition to virtual address mode
* changes relating to exiting boot services

In the current implementation, efi_runtime_detach() is
called from efi_set_virtual_address_map() as those two
purposes are apparently the same.
For instance, however, systab.con_in/out/std_err/boottime are set
to NULL in exit_boot_services() as well.
Logically, efi_get_variable() won't work as U-Boot environment data
can be potentially re-used at any time after exit_boot_services().
The only meaningful change is to invalidate efi_set_virtual_address_map().

So I believe that we should distinguish the two purposes
and make appropriate changes in efi_set_virtual_address_map() and
and exit_boot_services() respectively.

This will be crucial particularly when I will add
runtime variable support using "cache".

Any thoughts?

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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-21 Thread Peng Fan

Simon,

> Subject: RE: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> 
> Hi Simon,
> 
> > Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> > format file
> >
> > Hi Peng,
> >
> > On Tue, 7 May 2019 at 06:52, Peng Fan  wrote:
> > >
> > > i.MX8 only support AHAB secure boot with Container format image, we
> > > could not use FIT to support secure boot, so introduce container
> >
> > Why not FIT?
> 
> Actually before we implement secure boot, we use FIT image, however
> i.MX8 only support i.MX container format image for secure boot, The chip will
> verify the container image when secure boot. It could not recognize FIT image.
> So we have to drop FIT image.
> 
> >
> > > support to let SPL could load container images.
> >
> > What is a container image? Can you please point to documentation?
> 
> Sadly, there is no public reference manual. There is a doc that has a bit of
> information. https://community.nxp.com/docs/DOC-343178

https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Chapter 5.9.4 High Level Container Format

Thanks,
Peng.

> 
> Thanks,
> Peng.
> 
> >
> > >
> > > Cc: Simon Goldschmidt 
> > > Cc: Tien Fong Chee 
> > > Cc: York Sun 
> > > Cc: Marek Vasut 
> > > Cc: Alex Kiernan 
> > > Cc: Simon Glass 
> > > Cc: Philipp Tomsich 
> > > Cc: Kever Yang 
> > > Cc: Heiko Schocher 
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  common/spl/spl_mmc.c | 10 ++
> > >  include/spl.h| 12 
> > >  2 files changed, 22 insertions(+)
> >
> > Regards,
> > Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] armv8: lx2160aqds: Enable sata

2019-05-21 Thread Peng Ma

Change sata node status to enable sata.

Signed-off-by: Peng Ma 
---
 arch/arm/dts/fsl-lx2160a-qds.dts |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/fsl-lx2160a-qds.dts b/arch/arm/dts/fsl-lx2160a-qds.dts
index 6192156..77cf2ce 100644
--- a/arch/arm/dts/fsl-lx2160a-qds.dts
+++ b/arch/arm/dts/fsl-lx2160a-qds.dts
@@ -15,3 +15,18 @@
compatible = "fsl,lx2160aqds", "fsl,lx2160a";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
1.7.1

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

Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

On Wed, May 22, 2019 at 01:38:44AM +, Peng Fan wrote:
> Hi Fabio,
> 
> > Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> > 
> > Hi Peng,
> > 
> > On Thu, May 16, 2019 at 11:29 PM Peng Fan  wrote:
> > 
> > > You could enable DEBUG in SPL, and disable SPL_SDP because of size will
> > exceeds.
> > > Then see what happends.
> > > I have no idea, then. My board is REV C4, chip 1.5
> > 
> > My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> > 
> > After further investigation we can confirm that the problem is caused by SPL
> > size being greater than the 68kB limit (4KB header + 64KB max size)as
> > explained in include/configs/imx6_spl.h:
> > 
> > ---
> > #ifndef __IMX6_SPL_CONFIG_H
> > #define __IMX6_SPL_CONFIG_H
> > 
> > #ifdef CONFIG_SPL
> > /*
> >  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
> >  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091
> >  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
> > well
> >  *  - BOOT ROM stack is at 0x0091FFB8
> >  *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
> >  *IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
> > need to
> >  *fit between 0x00907000 and 0x00918000.
> >  *  - Additionally the BOOT ROM loads what they consider the firmware
> > image
> >  *which consists of a 4K header in front of us that contains the IVT, 
> > DCD
> >  *and some padding thus 'our' max size is really 0x00908000 -
> > 0x00918000
> >  *or 64KB
> >  */
> > #define CONFIG_SPL_MAX_SIZE 0x1
> > #define CONFIG_SPL_STACK0x0091FFB8
> > /*
> >  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
> >  * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
> >  * boot media (given that boot media specific offset is configured 
> > properly).
> >  */
> > #define CONFIG_SPL_PAD_TO   0x11000
> > ---
> > 
> > Here are the tests I ran:
> > 
> > Test 1: Original U-Boot 2019.07-rc2
> > ---
> > 
> > SPL: 76800 (75 kB)
> > Result: does not boot
> > 
> > Test 2: Removing extra dtbs
> > -
> > 
> > --- a/configs/mx6sabresd_defconfig
> > +++ b/configs/mx6sabresd_defconfig
> > @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> > CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> > CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> > -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> > +CONFIG_OF_LIST="imx6q-sabresd"
> >  CONFIG_MULTI_DTB_FIT=y
> >  CONFIG_SPL_MULTI_DTB_FIT=y
> > -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > +CONFIG_SPL_OF_LIST="imx6q-sabresd"
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> >  CONFIG_SPL_DM=y
> > 
> > SPL:68608 (67 kB)
> > Result: boots correctly
> > 
> > Test 3: Removing SPL_DM
> > 
> > 
> > --- a/configs/mx6sabresd_defconfig
> > +++ b/configs/mx6sabresd_defconfig
> > @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> > CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > -CONFIG_SPL_DM=y
> >  CONFIG_USB_FUNCTION_FASTBOOT=y
> >  CONFIG_FASTBOOT_BUF_ADDR=0x1200
> >  CONFIG_FASTBOOT_BUF_SIZE=0x1000
> > 
> > SPL: 68608 (67 kB)
> > Result: boots correctly
> > 
> > I will send a v2 removing CONFIG_SPL_DM.
> 
> So what is the real direction moving to use SPL driver, non-dm is allowed in 
> future?
> 
> > 
> > Also, the SPL size check should be really done after the multi fit image is
> > concatenated so that we can have a chance to detect such size overflow in
> > build time.
> 
> Agree. I also meet that SPL size is too large on i.MX8/8M, although still 
> have OCRAM for it.

As came up in another thread, CONFIG_MMC_TINY may be more widely useable
and should help with space.

-- 
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 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

2019-05-21 Thread Andy Yan

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.


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

>
> >
> >
> > >>> - (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 jump code should be relocatable.
>
> Also I wonder what you think of Andre's solution?
>
>
 See my reply .

> [..]
>
> Regards
> Simon
> ___
> 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 v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

2019-05-21 Thread Andy Yan

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.



> 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


> Cheers,
> Andre.
>
> [1]
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=fc922ca87cc6af8277dc0eb710fc63a2957f0194
>
> > > - 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 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 .
> >
> > > - (in extremis) create a function which does a memmove() and a jump,
> > > copy it somewhere and run it (I think x86 does this)
> > >
> > > Regards,
> > > Simon
> > >
> > > On Thu, 16 May 2019 at 06:22, Andy Yan 
> wrote:
> > >> Some times we want to relocate spl code to dram after dram
> > >> initialization or relocate spl code to a high memory to avoid
> > >> code overid.
> > >>
> > >> For example on Rockchip armv8 platform, we run with boot flow
> > >> TPL->SPL->ATF->U-Boot.
> > >> TPL run in sram and is responsible for dram initialization.
> > >> SPL run from the start address of dram and is responsible for
> > >> loading ATF and U-Boot.
> > >>
> > >> The case here is that the ATF load address is from 64KB of dram,
> > >> which overlaps with spl code itself.
> > >>
> > >> So we want to relocate spl itself to high memory to aovid this.
> > >>
> > >> Signed-off-by: Andy Yan 
> > >> ---
> > >>
> > >> Changes in v2:
> > >> - Move Kconfig modification to PATCH 1/3
> > >>
> > >>   common/spl/spl.c | 55
> 
> > >>   1 file changed, 55 insertions(+)
> > >>
> > >> diff --git a/common/spl/spl.c b/common/spl/spl.c
> > >> index 88d4b8a9bf..affb65ccbd 100644
> > >> --- a/common/spl/spl.c
> > >> +++ b/common/spl/spl.c
> > >> @@ -12,6 +12,7 @@
> > >>   #include 
> > >>   #include 
> > >>   #include 
> > >> +#include 
> > >>   #include 
> > >>   #include 
> > >>   #include 
> > >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc)
> > >>  return 0;
> > >>   }
> > >>
> > >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD)
> > >> +static void spl_setup_relocate(void)
> > >> +{
> > >> +   gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE;
> > >> +   gd->new_gd = (gd_t *)gd;
> > >> +   gd->start_addr_sp = gd->relocaddr;
> > >> +   gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000,
> 32);
> > >> +
> > >> +   gd->start_addr_sp -= gd->fdt_size;
> > >> +   gd->new_fdt = (void *)gd->start_addr_sp;
> > >> +   memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
> > >> +   gd->fdt_blob = gd->new_fdt;
> > >> +
> > >> +   gd->reloc_off = gd->relocaddr - (unsigned
> long)__image_copy_start;
> > >> +}
> > >> +#else
> > >> +static void spl_setup_relocate(void)
> > >> +{
> > >> +
> > >> +}
> > >> +#endif
> > >> +
> > >>   void spl_set_bd(void)
> > >>   {
> > >>  /*
> > >> @@ -460,6 +483,8 @@ int spl_early_init(void)
> > >>  return ret;
> > >>  gd->flags |= GD_FLG_SPL_EARLY_INIT;
> > >>
> > >> +   spl_setup_relocate();
> > >> +
> > >>  return 0;
> > >>   }
> > >>
> > >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct
> spl_image_info *spl_image,
> > >>  return -ENODEV;

Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

2019-05-21 Thread Peng Fan

Hi Fabio,

> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> 
> Hi Peng,
> 
> On Thu, May 16, 2019 at 11:29 PM Peng Fan  wrote:
> 
> > You could enable DEBUG in SPL, and disable SPL_SDP because of size will
> exceeds.
> > Then see what happends.
> > I have no idea, then. My board is REV C4, chip 1.5
> 
> My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> 
> After further investigation we can confirm that the problem is caused by SPL
> size being greater than the 68kB limit (4KB header + 64KB max size)as
> explained in include/configs/imx6_spl.h:
> 
> ---
> #ifndef __IMX6_SPL_CONFIG_H
> #define __IMX6_SPL_CONFIG_H
> 
> #ifdef CONFIG_SPL
> /*
>  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
>  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091
>  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
> well
>  *  - BOOT ROM stack is at 0x0091FFB8
>  *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
>  *IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
> need to
>  *fit between 0x00907000 and 0x00918000.
>  *  - Additionally the BOOT ROM loads what they consider the firmware
> image
>  *which consists of a 4K header in front of us that contains the IVT, DCD
>  *and some padding thus 'our' max size is really 0x00908000 -
> 0x00918000
>  *or 64KB
>  */
> #define CONFIG_SPL_MAX_SIZE 0x1
> #define CONFIG_SPL_STACK0x0091FFB8
> /*
>  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
>  * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
>  * boot media (given that boot media specific offset is configured properly).
>  */
> #define CONFIG_SPL_PAD_TO   0x11000
> ---
> 
> Here are the tests I ran:
> 
> Test 1: Original U-Boot 2019.07-rc2
> ---
> 
> SPL: 76800 (75 kB)
> Result: does not boot
> 
> Test 2: Removing extra dtbs
> -
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> +CONFIG_OF_LIST="imx6q-sabresd"
>  CONFIG_MULTI_DTB_FIT=y
>  CONFIG_SPL_MULTI_DTB_FIT=y
> -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> +CONFIG_SPL_OF_LIST="imx6q-sabresd"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_SPL_DM=y
> 
> SPL:68608 (67 kB)
> Result: boots correctly
> 
> Test 3: Removing SPL_DM
> 
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -CONFIG_SPL_DM=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_FASTBOOT_BUF_SIZE=0x1000
> 
> SPL: 68608 (67 kB)
> Result: boots correctly
> 
> I will send a v2 removing CONFIG_SPL_DM.

So what is the real direction moving to use SPL driver, non-dm is allowed in 
future?

> 
> Also, the SPL size check should be really done after the multi fit image is
> concatenated so that we can have a chance to detect such size overflow in
> build time.

Agree. I also meet that SPL size is too large on i.MX8/8M, although still have 
OCRAM for it.

Regards,
Peng.

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

Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

Hi Andreas,

On Tue, 21 May 2019 at 15:01, Andreas Dannenberg  wrote:
>
> Hi Simon (Glass),
>
> On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote:
> > Hi Andreas,
> >
> > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote:
> > > > Hi Andreas,
> > > >
> > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg  
> > > > wrote:
> > > > >
> > > > > Simon,
> > > > >
> > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote:
> > > > > > Simon Glass  schrieb am Sa., 30. März 2019, 
> > > > > > 21:06:
> > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If 
> > > > > > > > enabled, it
> > > > > > > clears
> > > > > > > > the bss before calling board_init_f() instead of clearing it 
> > > > > > > > before
> > > > > > > calling
> > > > > > > > board_init_r().
> > > > > > > >
> > > > > > > > This also ensures that variables placed in BSS can be shared 
> > > > > > > > between
> > > > > > > > board_init_f() and board_init_r() in SPL.
> > > > > > > >
> > > > > > > > Such global variables are used, for example, when loading 
> > > > > > > > things from FAT
> > > > > > > > before SDRAM is available: the full heap required for FAT uses 
> > > > > > > > global
> > > > > > > > variables and clearing BSS after board_init_f() would reset the 
> > > > > > > > heap
> > > > > > > state.
> > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA 
> > > > > > > > configuration
> > > > > > > > is required before SDRAM can be used.
> > > > > > > >
> > > > > > > > Make the new option depend on ARM for now until more 
> > > > > > > > implementations
> > > > > > > follow.
> > > > > > > >
> > > > > > >
> > > > > > > I still have objections to this series and I think we should 
> > > > > > > discuss
> > > > > > > other ways of solving this problem.
> > > > > > >
> > > > > > > Does socfgpa have SRAM that could be used before SDRAM is 
> > > > > > > available?
> > > > > > > If so, can we not use that for the configuration? What various are
> > > > > > > actually in BSS that are needed before board_init_r() is called? 
> > > > > > > Can
> > > > > > > they not be in a struct created from malloc()?
> > > > > > >
> > > > > >
> > > > > > The problem is the board needs to load an FPGA configuration from 
> > > > > > FAT
> > > > > > before SDRAM is available. Yes, this is loaded into SRAM of course, 
> > > > > > but the
> > > > > > whole code until that is done uses so many malloc/free iterations 
> > > > > > that The
> > > > > > simple mall of implementation would require too much memory.
> > > > > >
> > > > > > And it's the full malloc state variables only that use BSS, not the 
> > > > > > FAT
> > > > > > code.
> > > > >
> > > > > I've actually faced very similar issues working on our TI AM654x 
> > > > > "System
> > > > > Firmware Loader" implementation (will post upstream soon), where I 
> > > > > need
> > > > > to load this firmware and other files from media such as MMC/FAT in a 
> > > > > very
> > > > > memory-constrained SPL pre-relocation environment *before* I can 
> > > > > bring up
> > > > > DDR.
> > > > >
> > > > > Initially, I modified the fat.c driver to re-use memory so it is not 
> > > > > as
> > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this 
> > > > > solution [1]
> > > > > this allowed us to get going, allowing to load multiple files without
> > > > > issues in pre-relocation SPL.
> > > >
> > > > That seems to point the way to a useful solution I think. We could
> > > > have a struct containing allocated pointers which is private to FAT,
> > > > and just allocate them the first time.
> > >
> > > The board_init_f()-based loader solution we use extends beyond MMC/FAT,
> > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc.
> > >
> > > Background:
> > > On our "TI K3" devices we need to do a whole bunch of stuff before
> > > DDR is up with limited memory, namely loading and installing a firmware
> > > that controls the entire SoC called "System Firmware". It is only after
> > > this FW is loaded from boot media and successfully started that I can
> > > bring up DDR. So all this is done in SPL board_init_f(), which as the
> > > last step brings up DDR.
> > >
> > > Not having BSS available to carry over certain state to the
> > > board_init_r() world would lead to a bunch of hacky changes across
> > > the board I'm afraid, more below.
> >
> > This is really unfortunate.
> >
> > It seems to me that we have two choises:
> >
> > 1. Hack around with board_init_f() such as to remove the distinction
> > between this and board_init_r().
> >
> > 2. Enter board_init_r() without DRAM ready, and deal with setting it up 
> > there.
> >
> > I feel that the second solution is worth exploring. We could have

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

Hi Eugeniu,

On Fri, 17 May 2019 at 08:46, Eugeniu Rosca  wrote:
>
> 'Bootloader Control Block' (BCB) is a well established term/acronym in
> the Android namespace which refers to a location in a dedicated raw
> (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> which is used as media for exchanging messages between Android userspace
> (particularly recovery [1]) and an Android-capable bootloader.
>
> On higher level, this allows implementing a subset of Android Bootloader
> Requirements [2], amongst which is the Android-specific bootloader
> flow [3]. Regardless how the latter is implemented in U-Boot ([3] being
> the most memorable example), reading/writing/dumping the BCB fields in
> the development process from inside the U-Boot is a convenient feature.
> Hence, make it available to the users.
>
> Some usage examples of the new command recorded on R-Car H3ULCB-KF
> ('>>>' is an overlay on top of the original console output):
>
> => bcb
> bcb - Load/set/clear/test/dump/store Android BCB fields
>
> Usage:
> bcb load  - load  BCB from mmc :
> bcb set  - set   BCB  to 
> bcb clear []  - clear BCB  or all fields
> bcb test - test  BCB  against 
> bcb dump  - dump  BCB 
> bcb store- store BCB back to mmc
>
> Legend:
>- MMC device index containing the BCB partition
>   - MMC partition index or name containing the BCB
>  - one of {command,status,recovery,stage,reserved}
> - the binary operator used in 'bcb test':
>   '=' returns true if  matches the string stored in 
>   '~' returns true if  matches a subset of 's string
>- string/text provided as input to bcb {set,test}
>   NOTE: any ':' character in  will be replaced by line feed
>   during 'bcb set' and used as separator by upper layers
>
> => bcb dump command
> Error: BCB not loaded!
>  >>> Users must specify mmc device and partition before any other call
>
> => bcb load 1 misc
> => bcb load 1 1
>  >>> The two calls are equivalent (assuming "misc" has index 1)
>
> => bcb dump command
> : 62 6f 6f 74 6f 6e 63 65 2d 73 68 65 6c 6c 00 72bootonce-shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
>  >>> The output is in binary/string format for convenience
>  >>> The output size matches the size of inspected BCB field
>  >>> (32 bytes in case of 'command')
>
> => bcb test command = bootonce-shell && echo true
> true
> => bcb test command = bootonce-shell- && echo true
> => bcb test command = bootonce-shel && echo true
>  >>> The '=' operator returns 'true' on perfect match
>
> => bcb test command ~ bootonce-shel && echo true
> true
> => bcb test command ~ bootonce-shell && echo true
> true
>  >>> The '~' operator returns 'true' on substring match
>
> => bcb set command recovery
> => bcb dump command
> : 72 65 63 6f 76 65 72 79 00 73 68 65 6c 6c 00 72recovery.shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
>  >>> The new value is NULL-terminated and stored in the BCB field
>
> => bcb set recovery "msg1:msg2:msg3"
> => bcb dump recovery
> 0040: 6d 73 67 31 0a 6d 73 67 32 0a 6d 73 67 33 00 00msg1.msg2.msg3..
> 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  >>> --- snip ---
>  >>> Every ':' is replaced by line-feed '\n' (0xA). The latter is used
>  >>> as separator between individual commands by Android userspace
>
> => bcb store
>  >>> Flush/store the BCB structure to MMC
>
> [1] https://android.googlesource.com/platform/bootable/recovery
> [2] https://source.android.com/devices/bootloader
> [3] https://patchwork.ozlabs.org/patch/746835/
> ("[U-Boot,5/6] Initial support for the Android Bootloader flow")

As discussed, please add these docs somewhere in the U-Boot tree (can
be in a separate patch)

>
> Signed-off-by: Eugeniu Rosca 
> ---
> v2:
>  - [Heinrich Schuchardt] Implement sub-commands via U_BOOT_CMD_MKENT.
>  - Polished the code. Ensured no warnings returned by sparse, smatch,
>`cppcheck --force --enable=all --inconclusive`, make W=1.
>  - Tested on R-Car-H3-ES20 ULCB-KF.
>
> v1:
>  - https://patchwork.ozlabs.org/patch/1080395/
> ---
>  cmd/Kconfig  |  17 +++
>  cmd/Makefile |   1 +
>  cmd/bcb.c| 330 +++
>  3 files changed, 348 insertions(+)
>  create mode 100644 cmd/bcb.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 0d36da2a5c43..495bc1052f50 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -631,6 +631,23 @@ config CMD_ADC
>   Shows ADC device info and permit printing one-shot analog converted
>   data from a named Analog to Digital Converter.
>
> +config CMD_BCB
> +   bool "bcb"
> +   depends on MMC
> +   depends on PARTITIONS
> +   help
> + Read/modify/write the fields of Bootloader Control Block,

Re: [U-Boot] [PATCH v3 1/3] test: check u-boot properties in SPL device tree

On Tue, 21 May 2019 at 11:19, Patrick Delaunay  wrote:
>
> Add a test to check the management of the U-boot relocation properties
> for device tree SPL generation (fdtgrep result) and platdata:
> - 'dm-pre-proper' and 'dm-tpl' not included in SPL
> - 'dm-pre-reloc' and 'dm-spl' included in SPL
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v3:
> - simplify test after Simon remarks by using fdtgrep on spl dtb
>
> Changes in v2: None
>
>  arch/sandbox/dts/sandbox.dtsi| 18 ++
>  test/py/tests/test_ofplatdata.py | 28 
>  2 files changed, 46 insertions(+)

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

Re: [U-Boot] [PATCH v2 0/8] fdt: Allow indicating a node is for U-Boot proper only

Hi Patrick,

On Tue, 21 May 2019 at 10:07, Patrick DELAUNAY  wrote:
>
> Hi Simon,
>
> I will reply for the serie
>
> > Hi Patrick,
> >
> > On Mon, 20 May 2019 at 07:00, Patrick Delaunay 
> > wrote:
> > >
> > >
> > > Hi,
> > >
> > > I create this v2 serie with:
> > >
> > > 1/ documentation update for previous patch
> > >[U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
> > >http://patchwork.ozlabs.org/patch/1081155/
> > >
> > >PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
> > >pre reloc properties in SPL and TPL device tree")
> > >but not the documentation.
> > >
> > > 2/ missing part for (patch 1/2)
> > >http://patchwork.ozlabs.org/project/uboot/list/?series=89846
> > >
> > > 3/ new tests for pre-reloc propertie in SPL as suggested by Simon
> > >(http://patchwork.ozlabs.org/patch/1081155/#2156621)
> > >
> > > Tell me if is better to split the serie.
> >
> > Somehow this cover letter appears in a patch, hence some of my confusion. I 
> > see
> > what you are doing and it is a comprehensive approach.
> >
> > But please see my comments about comparing the .dtb file instead of making
> > sandbox print it out.
>
> I will change the test to only compare the device tree : it is more simple.
>
> => v3 in few days
>
> My first approach was complicated but it is to allow
> - check if sandbox SPL with devicetree and libfdt in working as is already 
> done for platdata
> - check if sandbox SPL can start U-Boot in booth case
>   (by executing the simple test_000_version in ./py/tests/test_000_version.py)
> - split test and normal device tree (I move the "spl-tests" nodes in test.dts)

Yes, certainly this is useful and it does provide an end-to-end sanity check.

But if we do this I think it should be *in addition* to smaller test.

So could we start with the simpler, smaller test and then see how far
that gets us? I am not saying that the functional test is bad, but if
something goes wrong with the test, there are a lot of pieces to look
at to figure out what went wrong.

>
> But it is too complicated just the purpose of this test.
>
> NB: the executable "u-boot-spl" for sandbox_spl_defconfig already
>include the devicetree information, with platdata.

Yes.

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

Re: [U-Boot] [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to U-boot (tag: 5.0-rc3)

Hi Lukasz,

On Tue, 21 May 2019 at 08:48, Lukasz Majewski  wrote:
>
> Hi Simon,
>
> > Hi Lukasz,
> >
> > On Sun, 19 May 2019 at 15:03, Lukasz Majewski  wrote:
> > >
> > > Hi Simon,
> > >
> > > > Hi Lukasz,
> > > >
> > > > On Sat, 18 May 2019 at 15:28, Lukasz Majewski 
> > > > wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > This is not the newest patch set version of CCF (v3 vs. v4),
> > > > > but the comments/issues apply.
> > > > >
> > > > > > Hi Lukasz,
> > > > > >
> > > > > > On Thu, 25 Apr 2019 at 04:30, Lukasz Majewski 
> > > > > > wrote:
> > > > > > >
> > > > > > > This patch series brings the files from Linux kernel to
> > > > > > > provide clocks support as it is used on the Linux kernel
> > > > > > > with common clock framework [CCF] setup.
> > > > > > >
> > > > > > > This series also fixes several problems with current clocks
> > > > > > > and provides sandbox tests for functions addded to
> > > > > > > clk-uclass.c file.
> > > > > > >
> > > > > > > Design decisions/issues:
> > > > > > > =
> > > > > > >
> > > > > > > - U-boot's DM for clk differs from Linux CCF. The most
> > > > > > > notably difference is the lack of support for hierarchical
> > > > > > > clocks and "clock as a manager driver" (single clock DTS
> > > > > > > node acts as a starting point for all other clocks).
> > > > > > >
> > > > > > > - The clk_get_rate() now caches the previously read data (no
> > > > > > > need for recursive access.
> > > > > > >
> > > > > > > - On purpose the "manager" clk driver (clk-imx6q.c) is not
> > > > > > > using large table to store pointers to clocks - e.g.
> > > > > > > clk[IMX6QDL_CLK_USDHC2_SEL] =  Instead we use udevice's
> > > > > > > linked list for the same class (UCLASS_CLK). The rationale -
> > > > > > > when porting the code as is from Linux, one would need
> > > > > > > ~1KiB of RAM to store it. This is way too much if we do
> > > > > > > plan to use this driver in SPL.
> > > > > > >
> > > > > > > - The "central" structure of this patch series is struct
> > > > > > > udevice and its driver_data field contains the struct clk
> > > > > > > pointer (to the originally created one).
> > > > > > >
> > > > > > > - Up till now U-boot's driver model's CLK operates on
> > > > > > > udevice (main access to clock is by udevice ops)
> > > > > > >   In the CCF the access to struct clk (comprising pointer to
> > > > > > > *dev) is possible via dev_get_driver_data()
> > > > > > >
> > > > > > >   Storing back pointer (from udevice to struct clk) as
> > > > > > > driver_data is a convention for CCF.
> > > > > >
> > > > > > Ick. Why not use uclass-private data to store this, since
> > > > > > every UCLASS_CLK device can have a parent.
> > > > >
> > > > > The "private_data" field would be also a good place to store the
> > > > > back pointer from udevice to struct clk [*]. The problem with
> > > > > CCF and udevice's priv pointer is explained just below:
> > > > >
> > > > > >
> > > > > > >
> > > > > > > - I could use *private_alloc_size to allocate driver's
> > > > > > > 'private" structures (dev->priv) for e.g. divider (struct
> > > > > > > clk_divider *divider) for IMX6Q clock, but this would
> > > > > > > change the original structure of the CCF code.
> > > > >
> > > > > The original Linux's CCF code for iMX relies on using kmalloc
> > > > > internally:
> > > > >
> > > > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/imx/clk-gate2.c#L139
> > > > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/clk-divider.c#L471
> > > > >
> > > > > By using driver_data I've avoided the need to make more changes
> > > > > to the original Linux code.
> > > > >
> > > > > I could use udevice's priv with automatic data allocation but
> > > > > then the CCF ported code would require more changes and
> > > > > considering the (from the outset) need to "fit" this code into
> > > > > U-Boot's DM, it drives away from the original Linux code.
> > > >
> > > > Is the main change the need to cast driver_data?
> > >
> > > The main change would be to remove the per clock device memory
> > > allocation code (with exit paths) from the original CCF code.
> > >
> > > This shall not be so difficult.
> > >
> > > > Perhaps that could be
> > > > hidden in a helper function/macro, so that in U-Boot it can hide
> > > > the use of (struct clk_uc_priv
> > > > *)dev_get_uclass_priv(clk->dev))>parent  ?
> > >
> > > Helper function would help to some extend as we operate on
> > > structures similar to:
> > >
> > > struct clk_gate2 {
> > > struct clk clk;
> > > void __iomem*reg;
> > > u8  bit_idx;
> > > u8  cgr_val;
> > > u8  flags;
> > > };
> > >
> > > The helper would return struct clk's address which is the same as
> > > struct's clk_gate2 (this is assured by C standard).
> > >
> > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > > The question is if it would be better to use
> > > > > > >

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

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?

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

>
>
> >>> - (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 jump code should be relocatable.

Also I wonder what you think of Andre's solution?

[..]

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

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

2019-05-21 Thread Peter Howard

On Tue, 2019-05-21 at 20:39 +0530, 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(). Since
> the
> README recommends calling preloader_console_init() from
> spl_board_init(),
> we keep it as-it-is.
> 
> Tested using MMC/SD boot on OMAP-L138 LCDK board.
> 
> Signed-off-by: Sekhar Nori 

Tested-by: Peter Howard 

> ---
>  arch/arm/mach-davinci/spl.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-
> davinci/spl.c
> index 103639e34757..117b5ee836f8 100644
> --- a/arch/arm/mach-davinci/spl.c
> +++ b/arch/arm/mach-davinci/spl.c
> @@ -33,10 +33,14 @@ void putc(char c)
>  
>  void spl_board_init(void)
>  {
> - arch_cpu_init();
>   preloader_console_init();
>  }
>  
> +void board_init_f(ulong dummy)
> +{
> + arch_cpu_init();
> +}
> +
>  u32 spl_boot_device(void)
>  {
>   switch (davinci_syscfg_regs->bootcfg) {


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion

2019-05-21 Thread Peter Howard

On Tue, 2019-05-21 at 20:39 +0530, Sekhar Nori wrote:
> commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
> wanted to enable DM_MMC only for U-Boot and not for SPL.
> 
> But CONFIG_DM_MMC is defined for SPL build too. Because of this
> MMC device was not getting registered for SPL causing MMC/SD
> boot breakage.
> 
> Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
> CONFIG_SPL_DM_MMC is defined.
> 
> Signed-off-by: Sekhar Nori 

Tested-by: Peter Howard 

> ---
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 2c2f885d43e4..fe1bf4410145 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -353,7 +353,7 @@ int misc_init_r(void)
>   return 0;
>  }
>  
> -#ifndef CONFIG_DM_MMC
> +#if !CONFIG_IS_ENABLED(DM_MMC)
>  #ifdef CONFIG_MMC_DAVINCI
>  static struct davinci_mmc mmc_sd0 = {
>   .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] ARM: davinci: omapl138_lcdk: fix MMC/SD boot breakage.

2019-05-21 Thread Peter Howard

Hi Sekhar

On Tue, 2019-05-21 at 20:39 +0530, Sekhar Nori wrote:
> Hi,
> 
> Here is a set of patches that fixes MMC/SD boot breakage introduced
> after 2018.09 release.
> 
> This was tested with MMC/SD boot on OMAP-L138 LCDK. I still need to
> do SPI and NAND boot on this board.
> 

I have tested NAND boot with the two patches and it seems to work fine.
I can confirm MMC boot (at least on the original LCDK)

The original LCDK didn't have SPI NAND - has that changed with the
latest board?

> Thanks,
> Sekhar
> 
> Sekhar Nori (2):
>   ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver
> model
> conversion
>   ARM: davinci: SPL: fix BSS initialization
> 
>  arch/arm/mach-davinci/spl.c| 6 +-
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 


-- 
Peter Howard 
Peter Howard 


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/8] test: py: add option to select device tree used during compilation

2019-05-21 Thread Stephen Warren


On 5/21/19 12:32 PM, Patrick DELAUNAY wrote:

Hi Stephen,

For information after the remarksSimon's  remark,
I simplify the test, so this part is no more needed
See http://patchwork.ozlabs.org/patch/1102938/

But I will answer with my status and my tests done on the python code.



On 5/20/19 7:00 AM, Patrick Delaunay wrote:

Only used for spl compilation which include the device tree (with
platdata or embedded device tree).
For U-boot, test use config.dtb, by default :
 "build_dir + '/arch/sandbox/dts/test.dtb'"

Signed-off-by: Patrick Delaunay 
---
I need to force o_dt = 'all' to avoid make error:

make: *** empty string invalid as file name.  Stop.

But, I don't sure that it is the better solution for pytest.


This feels a bit odd. What board are you compiling for? I would expect the same
compilation commands to "just work" for all boards, and would initially claim 
that if
they don't, it's a bug in the makefiles that should be fixed there.


Yes, it is strange.

When I compile the board I have not the problem, I have issue only when I use 
pytest.

...

But if I use =

...

 if device_tree:
 o_dt = 'DEVICE_TREE=%s' % device_tree
 else:
 o_dt = ''

...

But the second command I have got the next error:

./test/py/test.py --bd sandbox --build  -k 'test_000_version'
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox -s 
sandbox_defconfig
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox  -s -j8
make: *** empty string invalid as file name.  Stop.


Right, o_dt is '' so there's an extra zero-length parameter between the 
"O=" and "-s" argument in that last command, which is what the error 
message complains about.


But this is all with your patch applied. I still don't understand what 
issue this was trying to solve in the first place, i.e. what is/was 
wrong with u-boot.git's master branch. I can run test/py for both 
sandbox and sandbox_spl with unmodified u-boot.git master branch; see 
logs below. Is there still some bug I need to fix, that exists without 
your patch series?



[swarren@swarren-lx1 u-boot]$ ./test/py/test.py --bd sandbox --build -k 
test_000_version
+make O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-sandbox -s 
sandbox_defconfig
+make O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-sandbox -s 
-j8
= test session starts ==
platform linux2 -- Python 2.7.12, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
rootdir: /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot, inifile: 
collected 503 items 


test/py/tests/test_000_version.py .

= 502 tests deselected by '-ktest_000_version' =
=== 1 passed, 502 deselected in 0.17 seconds ===



[swarren@swarren-lx1 u-boot]$ ./test/py/test.py --bd sandbox_spl --build -k 
test_000_version
+make 
O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-sandbox_spl -s 
sandbox_spl_defconfig
+make 
O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-sandbox_spl -s 
-j8
= test session starts ==
platform linux2 -- Python 2.7.12, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
rootdir: /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot, inifile: 
collected 492 items 


test/py/tests/test_000_version.py .

= 491 tests deselected by '-ktest_000_version' =
=== 1 passed, 491 deselected in 0.31 seconds ===

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

Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

2019-05-21 Thread Andreas Dannenberg

Hi Simon (Glass),

On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote:
> Hi Andreas,
> 
> On Mon, 6 May 2019 at 22:49, Andreas Dannenberg  wrote:
> >
> > Hi Simon,
> >
> > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote:
> > > Hi Andreas,
> > >
> > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg  wrote:
> > > >
> > > > Simon,
> > > >
> > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote:
> > > > > Simon Glass  schrieb am Sa., 30. März 2019, 21:06:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
> > > > > >  wrote:
> > > > > > >
> > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, 
> > > > > > > it
> > > > > > clears
> > > > > > > the bss before calling board_init_f() instead of clearing it 
> > > > > > > before
> > > > > > calling
> > > > > > > board_init_r().
> > > > > > >
> > > > > > > This also ensures that variables placed in BSS can be shared 
> > > > > > > between
> > > > > > > board_init_f() and board_init_r() in SPL.
> > > > > > >
> > > > > > > Such global variables are used, for example, when loading things 
> > > > > > > from FAT
> > > > > > > before SDRAM is available: the full heap required for FAT uses 
> > > > > > > global
> > > > > > > variables and clearing BSS after board_init_f() would reset the 
> > > > > > > heap
> > > > > > state.
> > > > > > > An example for such a usage is socfpa_arria10 where an FPGA 
> > > > > > > configuration
> > > > > > > is required before SDRAM can be used.
> > > > > > >
> > > > > > > Make the new option depend on ARM for now until more 
> > > > > > > implementations
> > > > > > follow.
> > > > > > >
> > > > > >
> > > > > > I still have objections to this series and I think we should discuss
> > > > > > other ways of solving this problem.
> > > > > >
> > > > > > Does socfgpa have SRAM that could be used before SDRAM is available?
> > > > > > If so, can we not use that for the configuration? What various are
> > > > > > actually in BSS that are needed before board_init_r() is called? Can
> > > > > > they not be in a struct created from malloc()?
> > > > > >
> > > > >
> > > > > The problem is the board needs to load an FPGA configuration from FAT
> > > > > before SDRAM is available. Yes, this is loaded into SRAM of course, 
> > > > > but the
> > > > > whole code until that is done uses so many malloc/free iterations 
> > > > > that The
> > > > > simple mall of implementation would require too much memory.
> > > > >
> > > > > And it's the full malloc state variables only that use BSS, not the 
> > > > > FAT
> > > > > code.
> > > >
> > > > I've actually faced very similar issues working on our TI AM654x "System
> > > > Firmware Loader" implementation (will post upstream soon), where I need
> > > > to load this firmware and other files from media such as MMC/FAT in a 
> > > > very
> > > > memory-constrained SPL pre-relocation environment *before* I can bring 
> > > > up
> > > > DDR.
> > > >
> > > > Initially, I modified the fat.c driver to re-use memory so it is not as
> > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution 
> > > > [1]
> > > > this allowed us to get going, allowing to load multiple files without
> > > > issues in pre-relocation SPL.
> > >
> > > That seems to point the way to a useful solution I think. We could
> > > have a struct containing allocated pointers which is private to FAT,
> > > and just allocate them the first time.
> >
> > The board_init_f()-based loader solution we use extends beyond MMC/FAT,
> > but also for OSPI, X/Y-Modem, and (later) USB, network, etc.
> >
> > Background:
> > On our "TI K3" devices we need to do a whole bunch of stuff before
> > DDR is up with limited memory, namely loading and installing a firmware
> > that controls the entire SoC called "System Firmware". It is only after
> > this FW is loaded from boot media and successfully started that I can
> > bring up DDR. So all this is done in SPL board_init_f(), which as the
> > last step brings up DDR.
> >
> > Not having BSS available to carry over certain state to the
> > board_init_r() world would lead to a bunch of hacky changes across
> > the board I'm afraid, more below.
> 
> This is really unfortunate.
> 
> It seems to me that we have two choises:
> 
> 1. Hack around with board_init_f() such as to remove the distinction
> between this and board_init_r().
> 
> 2. Enter board_init_r() without DRAM ready, and deal with setting it up there.
> 
> I feel that the second solution is worth exploring. We could have some
> board-specific init in board_init_r(). We already have
> spl_board_init() so perhaps we could have spl_early_board_init()
> called right near the top?
> 
> We can refactor a few of the functions in spl/spl.c so they can be
> called from board-specific code if necessary. We could also add new
> flags to global_data to control the behaviour of the SPL code, and the
> board code could set these.

Let me

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

Hi Eugeniu,

On Tue, 21 May 2019 at 11:32, Eugeniu Rosca  wrote:
>
> Hi Simon,
>
> On Tue, May 21, 2019 at 10:43:04AM -0600, Simon Glass wrote:
> > On Mon, 20 May 2019 at 01:23, Eugeniu Rosca  wrote:
> [..]
> > > I can identify two Android-dedicated README files, but none of them
> > > seems to be suitable for the new command:
> > >  - doc/README.android-fastboot
> > >  - doc/README.avb2
> > >
> > > Igor, Sam, what's your view on the above? Would you suggest creating
> > > a doc/README.android-bcb or there is a more elegant solution to it?
> >
> > How about a new README.android which links to the other two and adds
> > your new info?
>
> How about below directory structure:
>
>  u-boot $ tree doc/android
>  doc/android
>  ├── avb2.txt
>  ├── bcb.txt
>  └── fastboot.txt
>

Sounds good

> >
> > >
> > > >
> > > > Should it default to enabled if avb is used?
> > >
> > > I think at this specific moment in time, 'bcb' is orthogonal (meaning it
> > > is neither a direct, nor a reverse dependency) to any other Android
> > > feature in U-Boot. This could be re-assessed, if platform maintainers
> > > start to rely on 'bcb' in their U-Boot environments on regular basis.
> >
> > OK. Also is there a sandbox driver for this? We should have a test.
>
> Emulating and exposing MMC devices in sandbox should be the only
> prerequisite for sandbox testing and this seems to be already supported
> via drivers/mmc/sandbox_mmc.c. However, to be honest, I was unsuccessful
> bringing up the MMC devices on sandbox in the past. Particularly,
> booting the latest sandbox U-Boot (CMD_MMC=y) I get:
>
> => mmc list
> No MMC device available
>
> I think there is something elementary which I am missing?

Probably need to copy an mmc node over from test.dts to sandbox.dts


>
> Regardless, I need some more days to implement the test and repartition
> the README files. I think Sam would appreciate if you can provide your
> Ack to the series as-is (it was extensively statically and dynamically
> tested on R-Car H3ULCB) and I submit the doc/test updates separately.
> Otherwise, I will push the next revision hopefully in a week or so.

That's OK with me, but let me review it first.

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

Re: [U-Boot] [PATCH] gpio: dwapb_gpio: fix broken dev->node

On 5/21/19 10:03 PM, Simon Goldschmidt wrote:
> commit 1b898ffc040b ("gpio: dwapb_gpio: convert to livetree") introduced
> a bug in that dev->node of the gpio chip was accidentally set to the
> of_node of its bank subnode.
> 
> What it meant to do was assign subdev->node, not dev->node.
> 
> While this doesn't affect too many use cases, iterating over the gpio
> chip's properties doesn't work any more after that, so fix this.
> 
> Fixes: commit 1b898ffc040b ("gpio: dwapb_gpio: convert to livetree")
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> This fixes a commit that is only 12 days old, so it's a fix for v2019.07
> 
> ---
>  drivers/gpio/dwapb_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> index 04a2381acd..d6887a396a 100644
> --- a/drivers/gpio/dwapb_gpio.c
> +++ b/drivers/gpio/dwapb_gpio.c
> @@ -190,7 +190,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
>   if (ret)
>   return ret;
>  
> - dev->node = node;
> + subdev->node = node;
>   bank++;
>   }
>  
> 
Applied, thanks

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

Re: [U-Boot] Making U-Boot smaller

On 5/21/19 10:10 PM, Tom Rini wrote:
> On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote:
>> On 5/21/19 9:59 PM, Tom Rini wrote:
>>> On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
 On 5/21/19 9:53 PM, Tom Rini wrote:
> On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
>> On 5/21/19 6:56 PM, Jagan Teki wrote:
>>> On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:

 Hi,

 (moved from thread "U-Boot PXA support")

 We have of-platdata, which produces C data from the DT, for linking
 into U-Boot. It saves libfdt and DT space. But we still have the DM
 overhead.

 We have binman which can insert values into the binary after
 link-time. This is barely used at present, only for accessing the
 location of things in flash.

 Another thing is that every little tweak and feature adds a few bytes
 and there are dozens of them in each release. It would be interesting
 to build a board from 10 years ago (like PXA) and see where the growth
 is. My bet is that we could add Kconfig options to disable extra
 features (and enhancements of features) and make quite a difference.

 For DM, I think it would be interesting to revisit and compare against
 the initial release, and see if some features could be made optional
 in SPL.

 Finally I feel we could implement a single-device API for where
 CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
 single instance of tiny MMC for MMC, etc.
>>>
>>> This is what I'm looking for quite sometime, a tiny MMC which would
>>> bypass the mmc stack and do the possible stuff in SPL, since we don't
>>> have any option to use full DM in SPL (specifically for Allwinner 64
>>> SoC's). API that would atleast compatible with DM with small
>>> foot-print would help.
>>
>> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
>
> I want to start by saying I'm not criticizing MMC_TINY.  But I think
> this highlights part of the problem of "lets do something that's not the
> normal framework".  Developers come up with a one-off, do their best to
> make others know about it, and then a year later when someone else has a
> similar problem, they may or may not stumble into the alternate path
> fix.
>
> So, getting back to specifics, what would it take to do both:
> - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
>   this for the "we just need MMC read, ROM probably already did enough
>   init for us for this"
> - NOT blow up CI20 which I know is super tight on space.

 You can already do just that.

 Isn't the current problem a good/searchable documentation then ?
 Like the readthedocs stuff ?
>>>
>>> Oh?  Good!  So, yes, it's documented as:
>>>   Enable MMC framework tinification support. This option is useful 
>>> if
>>>   if your SPL is extremely size constrained. Heed the warning, 
>>> enable
>>>   this option if and only if you know exactly what you are doing, if
>>>   you are reading this help text, you most likely have no idea :-)
>>>
>>>   The MMC framework is reduced to bare minimum to be useful. No 
>>> malloc
>>>   support is needed for the MMC framework operation with this option
>>>   enabled. The framework supports exactly one MMC device and exactly
>>>   one MMC driver. The MMC driver can be adjusted to avoid any malloc
>>>   operations too, which can remove the need for malloc support in 
>>> SPL
>>>   and thus further reduce footprint.
>>>
>>> So, is write supported?
>>
>> No, what for ?
> 
> For the cases where writing is required, OK, so not possible here,
> that's a fine trade-off.

Isn't there CONFIG_MMC_WRITE for that ?

>>> When you say "one MMC device", is that static
>>> at run-time or you can run-time init and use only one?
>>
>> IIRC it's compile time.
> 
> Where/how?  I don't see it from the code right away..

CCing Ezequiel, he was digging in that recently and he likes CI20 .

>>> What would a
>>> patch look like that enabled this on SoCFPGA?  Thanks!
>>
>> Like nothing , since SoCFPGA probes itself from DT in SPL and there's
>> enough space for that. However, if you want an example, CI20 is one.
> 
> Yes, and now I'm trying to get it understood, so we can update the
> Kconfig help if nothing else, how limited the driver is and how to
> switch to it.  So what would it look like to use this on SoCFPA, or
> some other platform you're familiar with and that uses SPL?  iMX6 is
> another "we have no SPL space!" platform that isn't using MMC_TINY, for
> example.

See above, I'll deflect this question to the expert(s).

-- 
Best regards,
Marek Vasut

Re: [U-Boot] Making U-Boot smaller

On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote:
> On 5/21/19 9:59 PM, Tom Rini wrote:
> > On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
> >> On 5/21/19 9:53 PM, Tom Rini wrote:
> >>> On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
>  On 5/21/19 6:56 PM, Jagan Teki wrote:
> > On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
> >>
> >> Hi,
> >>
> >> (moved from thread "U-Boot PXA support")
> >>
> >> We have of-platdata, which produces C data from the DT, for linking
> >> into U-Boot. It saves libfdt and DT space. But we still have the DM
> >> overhead.
> >>
> >> We have binman which can insert values into the binary after
> >> link-time. This is barely used at present, only for accessing the
> >> location of things in flash.
> >>
> >> Another thing is that every little tweak and feature adds a few bytes
> >> and there are dozens of them in each release. It would be interesting
> >> to build a board from 10 years ago (like PXA) and see where the growth
> >> is. My bet is that we could add Kconfig options to disable extra
> >> features (and enhancements of features) and make quite a difference.
> >>
> >> For DM, I think it would be interesting to revisit and compare against
> >> the initial release, and see if some features could be made optional
> >> in SPL.
> >>
> >> Finally I feel we could implement a single-device API for where
> >> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
> >> single instance of tiny MMC for MMC, etc.
> >
> > This is what I'm looking for quite sometime, a tiny MMC which would
> > bypass the mmc stack and do the possible stuff in SPL, since we don't
> > have any option to use full DM in SPL (specifically for Allwinner 64
> > SoC's). API that would atleast compatible with DM with small
> > foot-print would help.
> 
>  It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
> >>>
> >>> I want to start by saying I'm not criticizing MMC_TINY.  But I think
> >>> this highlights part of the problem of "lets do something that's not the
> >>> normal framework".  Developers come up with a one-off, do their best to
> >>> make others know about it, and then a year later when someone else has a
> >>> similar problem, they may or may not stumble into the alternate path
> >>> fix.
> >>>
> >>> So, getting back to specifics, what would it take to do both:
> >>> - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
> >>>   this for the "we just need MMC read, ROM probably already did enough
> >>>   init for us for this"
> >>> - NOT blow up CI20 which I know is super tight on space.
> >>
> >> You can already do just that.
> >>
> >> Isn't the current problem a good/searchable documentation then ?
> >> Like the readthedocs stuff ?
> > 
> > Oh?  Good!  So, yes, it's documented as:
> >   Enable MMC framework tinification support. This option is useful 
> > if
> >   if your SPL is extremely size constrained. Heed the warning, 
> > enable
> >   this option if and only if you know exactly what you are doing, if
> >   you are reading this help text, you most likely have no idea :-)
> > 
> >   The MMC framework is reduced to bare minimum to be useful. No 
> > malloc
> >   support is needed for the MMC framework operation with this option
> >   enabled. The framework supports exactly one MMC device and exactly
> >   one MMC driver. The MMC driver can be adjusted to avoid any malloc
> >   operations too, which can remove the need for malloc support in 
> > SPL
> >   and thus further reduce footprint.
> > 
> > So, is write supported?
> 
> No, what for ?

For the cases where writing is required, OK, so not possible here,
that's a fine trade-off.

> > When you say "one MMC device", is that static
> > at run-time or you can run-time init and use only one?
> 
> IIRC it's compile time.

Where/how?  I don't see it from the code right away..

> > What would a
> > patch look like that enabled this on SoCFPGA?  Thanks!
> 
> Like nothing , since SoCFPGA probes itself from DT in SPL and there's
> enough space for that. However, if you want an example, CI20 is one.

Yes, and now I'm trying to get it understood, so we can update the
Kconfig help if nothing else, how limited the driver is and how to
switch to it.  So what would it look like to use this on SoCFPA, or
some other platform you're familiar with and that uses SPL?  iMX6 is
another "we have no SPL space!" platform that isn't using MMC_TINY, for
example.

-- 
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] gpio: dwapb_gpio: fix broken dev->node

2019-05-21 Thread Simon Goldschmidt

commit 1b898ffc040b ("gpio: dwapb_gpio: convert to livetree") introduced
a bug in that dev->node of the gpio chip was accidentally set to the
of_node of its bank subnode.

What it meant to do was assign subdev->node, not dev->node.

While this doesn't affect too many use cases, iterating over the gpio
chip's properties doesn't work any more after that, so fix this.

Fixes: commit 1b898ffc040b ("gpio: dwapb_gpio: convert to livetree")
Signed-off-by: Simon Goldschmidt 
---

This fixes a commit that is only 12 days old, so it's a fix for v2019.07

---
 drivers/gpio/dwapb_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 04a2381acd..d6887a396a 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -190,7 +190,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
if (ret)
return ret;
 
-   dev->node = node;
+   subdev->node = node;
bank++;
}
 
-- 
2.20.1

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

Re: [U-Boot] Making U-Boot smaller

On 5/21/19 9:59 PM, Tom Rini wrote:
> On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
>> On 5/21/19 9:53 PM, Tom Rini wrote:
>>> On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
 On 5/21/19 6:56 PM, Jagan Teki wrote:
> On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
>>
>> Hi,
>>
>> (moved from thread "U-Boot PXA support")
>>
>> We have of-platdata, which produces C data from the DT, for linking
>> into U-Boot. It saves libfdt and DT space. But we still have the DM
>> overhead.
>>
>> We have binman which can insert values into the binary after
>> link-time. This is barely used at present, only for accessing the
>> location of things in flash.
>>
>> Another thing is that every little tweak and feature adds a few bytes
>> and there are dozens of them in each release. It would be interesting
>> to build a board from 10 years ago (like PXA) and see where the growth
>> is. My bet is that we could add Kconfig options to disable extra
>> features (and enhancements of features) and make quite a difference.
>>
>> For DM, I think it would be interesting to revisit and compare against
>> the initial release, and see if some features could be made optional
>> in SPL.
>>
>> Finally I feel we could implement a single-device API for where
>> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
>> single instance of tiny MMC for MMC, etc.
>
> This is what I'm looking for quite sometime, a tiny MMC which would
> bypass the mmc stack and do the possible stuff in SPL, since we don't
> have any option to use full DM in SPL (specifically for Allwinner 64
> SoC's). API that would atleast compatible with DM with small
> foot-print would help.

 It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
>>>
>>> I want to start by saying I'm not criticizing MMC_TINY.  But I think
>>> this highlights part of the problem of "lets do something that's not the
>>> normal framework".  Developers come up with a one-off, do their best to
>>> make others know about it, and then a year later when someone else has a
>>> similar problem, they may or may not stumble into the alternate path
>>> fix.
>>>
>>> So, getting back to specifics, what would it take to do both:
>>> - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
>>>   this for the "we just need MMC read, ROM probably already did enough
>>>   init for us for this"
>>> - NOT blow up CI20 which I know is super tight on space.
>>
>> You can already do just that.
>>
>> Isn't the current problem a good/searchable documentation then ?
>> Like the readthedocs stuff ?
> 
> Oh?  Good!  So, yes, it's documented as:
>   Enable MMC framework tinification support. This option is useful if
>   if your SPL is extremely size constrained. Heed the warning, enable
>   this option if and only if you know exactly what you are doing, if
>   you are reading this help text, you most likely have no idea :-)
> 
>   The MMC framework is reduced to bare minimum to be useful. No malloc
>   support is needed for the MMC framework operation with this option
>   enabled. The framework supports exactly one MMC device and exactly
>   one MMC driver. The MMC driver can be adjusted to avoid any malloc
>   operations too, which can remove the need for malloc support in SPL
>   and thus further reduce footprint.
> 
> So, is write supported?

No, what for ?

> When you say "one MMC device", is that static
> at run-time or you can run-time init and use only one?

IIRC it's compile time.

> What would a
> patch look like that enabled this on SoCFPGA?  Thanks!

Like nothing , since SoCFPGA probes itself from DT in SPL and there's
enough space for that. However, if you want an example, CI20 is one.

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

Re: [U-Boot] Making U-Boot smaller

On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
> On 5/21/19 9:53 PM, Tom Rini wrote:
> > On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
> >> On 5/21/19 6:56 PM, Jagan Teki wrote:
> >>> On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
> 
>  Hi,
> 
>  (moved from thread "U-Boot PXA support")
> 
>  We have of-platdata, which produces C data from the DT, for linking
>  into U-Boot. It saves libfdt and DT space. But we still have the DM
>  overhead.
> 
>  We have binman which can insert values into the binary after
>  link-time. This is barely used at present, only for accessing the
>  location of things in flash.
> 
>  Another thing is that every little tweak and feature adds a few bytes
>  and there are dozens of them in each release. It would be interesting
>  to build a board from 10 years ago (like PXA) and see where the growth
>  is. My bet is that we could add Kconfig options to disable extra
>  features (and enhancements of features) and make quite a difference.
> 
>  For DM, I think it would be interesting to revisit and compare against
>  the initial release, and see if some features could be made optional
>  in SPL.
> 
>  Finally I feel we could implement a single-device API for where
>  CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
>  single instance of tiny MMC for MMC, etc.
> >>>
> >>> This is what I'm looking for quite sometime, a tiny MMC which would
> >>> bypass the mmc stack and do the possible stuff in SPL, since we don't
> >>> have any option to use full DM in SPL (specifically for Allwinner 64
> >>> SoC's). API that would atleast compatible with DM with small
> >>> foot-print would help.
> >>
> >> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
> > 
> > I want to start by saying I'm not criticizing MMC_TINY.  But I think
> > this highlights part of the problem of "lets do something that's not the
> > normal framework".  Developers come up with a one-off, do their best to
> > make others know about it, and then a year later when someone else has a
> > similar problem, they may or may not stumble into the alternate path
> > fix.
> > 
> > So, getting back to specifics, what would it take to do both:
> > - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
> >   this for the "we just need MMC read, ROM probably already did enough
> >   init for us for this"
> > - NOT blow up CI20 which I know is super tight on space.
> 
> You can already do just that.
> 
> Isn't the current problem a good/searchable documentation then ?
> Like the readthedocs stuff ?

Oh?  Good!  So, yes, it's documented as:
  Enable MMC framework tinification support. This option is useful if
  if your SPL is extremely size constrained. Heed the warning, enable
  this option if and only if you know exactly what you are doing, if
  you are reading this help text, you most likely have no idea :-)

  The MMC framework is reduced to bare minimum to be useful. No malloc
  support is needed for the MMC framework operation with this option
  enabled. The framework supports exactly one MMC device and exactly
  one MMC driver. The MMC driver can be adjusted to avoid any malloc
  operations too, which can remove the need for malloc support in SPL
  and thus further reduce footprint.

So, is write supported?  When you say "one MMC device", is that static
at run-time or you can run-time init and use only one? What would a
patch look like that enabled this on SoCFPGA?  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] Making U-Boot smaller

On 5/21/19 9:53 PM, Tom Rini wrote:
> On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
>> On 5/21/19 6:56 PM, Jagan Teki wrote:
>>> On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:

 Hi,

 (moved from thread "U-Boot PXA support")

 We have of-platdata, which produces C data from the DT, for linking
 into U-Boot. It saves libfdt and DT space. But we still have the DM
 overhead.

 We have binman which can insert values into the binary after
 link-time. This is barely used at present, only for accessing the
 location of things in flash.

 Another thing is that every little tweak and feature adds a few bytes
 and there are dozens of them in each release. It would be interesting
 to build a board from 10 years ago (like PXA) and see where the growth
 is. My bet is that we could add Kconfig options to disable extra
 features (and enhancements of features) and make quite a difference.

 For DM, I think it would be interesting to revisit and compare against
 the initial release, and see if some features could be made optional
 in SPL.

 Finally I feel we could implement a single-device API for where
 CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
 single instance of tiny MMC for MMC, etc.
>>>
>>> This is what I'm looking for quite sometime, a tiny MMC which would
>>> bypass the mmc stack and do the possible stuff in SPL, since we don't
>>> have any option to use full DM in SPL (specifically for Allwinner 64
>>> SoC's). API that would atleast compatible with DM with small
>>> foot-print would help.
>>
>> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
> 
> I want to start by saying I'm not criticizing MMC_TINY.  But I think
> this highlights part of the problem of "lets do something that's not the
> normal framework".  Developers come up with a one-off, do their best to
> make others know about it, and then a year later when someone else has a
> similar problem, they may or may not stumble into the alternate path
> fix.
> 
> So, getting back to specifics, what would it take to do both:
> - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
>   this for the "we just need MMC read, ROM probably already did enough
>   init for us for this"
> - NOT blow up CI20 which I know is super tight on space.

You can already do just that.

Isn't the current problem a good/searchable documentation then ?
Like the readthedocs stuff ?

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

Re: [U-Boot] Making U-Boot smaller

On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
> On 5/21/19 6:56 PM, Jagan Teki wrote:
> > On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
> >>
> >> Hi,
> >>
> >> (moved from thread "U-Boot PXA support")
> >>
> >> We have of-platdata, which produces C data from the DT, for linking
> >> into U-Boot. It saves libfdt and DT space. But we still have the DM
> >> overhead.
> >>
> >> We have binman which can insert values into the binary after
> >> link-time. This is barely used at present, only for accessing the
> >> location of things in flash.
> >>
> >> Another thing is that every little tweak and feature adds a few bytes
> >> and there are dozens of them in each release. It would be interesting
> >> to build a board from 10 years ago (like PXA) and see where the growth
> >> is. My bet is that we could add Kconfig options to disable extra
> >> features (and enhancements of features) and make quite a difference.
> >>
> >> For DM, I think it would be interesting to revisit and compare against
> >> the initial release, and see if some features could be made optional
> >> in SPL.
> >>
> >> Finally I feel we could implement a single-device API for where
> >> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
> >> single instance of tiny MMC for MMC, etc.
> > 
> > This is what I'm looking for quite sometime, a tiny MMC which would
> > bypass the mmc stack and do the possible stuff in SPL, since we don't
> > have any option to use full DM in SPL (specifically for Allwinner 64
> > SoC's). API that would atleast compatible with DM with small
> > foot-print would help.
> 
> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.

I want to start by saying I'm not criticizing MMC_TINY.  But I think
this highlights part of the problem of "lets do something that's not the
normal framework".  Developers come up with a one-off, do their best to
make others know about it, and then a year later when someone else has a
similar problem, they may or may not stumble into the alternate path
fix.

So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
  this for the "we just need MMC read, ROM probably already did enough
  init for us for this"
- NOT blow up CI20 which I know is super tight on space.

-- 
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] Making U-Boot smaller

On 5/21/19 6:56 PM, Jagan Teki wrote:
> On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
>>
>> Hi,
>>
>> (moved from thread "U-Boot PXA support")
>>
>> We have of-platdata, which produces C data from the DT, for linking
>> into U-Boot. It saves libfdt and DT space. But we still have the DM
>> overhead.
>>
>> We have binman which can insert values into the binary after
>> link-time. This is barely used at present, only for accessing the
>> location of things in flash.
>>
>> Another thing is that every little tweak and feature adds a few bytes
>> and there are dozens of them in each release. It would be interesting
>> to build a board from 10 years ago (like PXA) and see where the growth
>> is. My bet is that we could add Kconfig options to disable extra
>> features (and enhancements of features) and make quite a difference.
>>
>> For DM, I think it would be interesting to revisit and compare against
>> the initial release, and see if some features could be made optional
>> in SPL.
>>
>> Finally I feel we could implement a single-device API for where
>> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
>> single instance of tiny MMC for MMC, etc.
> 
> This is what I'm looking for quite sometime, a tiny MMC which would
> bypass the mmc stack and do the possible stuff in SPL, since we don't
> have any option to use full DM in SPL (specifically for Allwinner 64
> SoC's). API that would atleast compatible with DM with small
> foot-print would help.

It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.

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

Re: [U-Boot] Making U-Boot smaller

On 5/21/19 6:43 PM, Simon Glass wrote:
> Hi,
> 
> (moved from thread "U-Boot PXA support")
> 
> We have of-platdata, which produces C data from the DT, for linking
> into U-Boot. It saves libfdt and DT space. But we still have the DM
> overhead.
> 
> We have binman which can insert values into the binary after
> link-time. This is barely used at present, only for accessing the
> location of things in flash.
> 
> Another thing is that every little tweak and feature adds a few bytes
> and there are dozens of them in each release. It would be interesting
> to build a board from 10 years ago (like PXA) and see where the growth
> is. My bet is that we could add Kconfig options to disable extra
> features (and enhancements of features) and make quite a difference.
> 
> For DM, I think it would be interesting to revisit and compare against
> the initial release, and see if some features could be made optional
> in SPL.
> 
> Finally I feel we could implement a single-device API for where
> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
> single instance of tiny MMC for MMC, etc.

If it's a single-instance, then maybe we can somehow compile-out or
short-circuit the DM altogether ?

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

Re: [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader

2019-05-21 Thread Andreas Dannenberg

Hi Tom,

On Fri, May 17, 2019 at 07:24:48AM -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 03:54:43PM -0500, Andreas Dannenberg wrote:
> 
> > This series provides an alternative solution to the previously posted
> > series titled "System Firmware Loader for TI K3 family SoCs" [1] using
> > the existing FS loader driver rather than extending the SPL loader
> > framework like the original patch series. Unlike the original series,
> > it does not support eMMC/SD partition/sector based RAW loading, and
> > it is larger in size.
> > 
> > It is only provided to support the discussion around to the initial
> > series posted as "System Firmware Loader for TI K3 family SoCs" and
> > is not intended to supersede this series, hence it is labeled as
> > "RFC".
> > 
> > The interesting pieces are really in patches 04/11 (extension of
> > FS loader to allow using platform data so one does not have to use
> > either ENV or DTS), and 05/11 which implementes the usage of FS
> > loader, including the required sequence of MMC initialization steps
> > inspired by how SPL does it.
> > 
> > [1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461
> 
> Andreas, thanks for posting this.
> 
> TF, do you see some way, given this series, to make changes such that
> "fs_loader" can be made smaller?  And support more of Andreas' use cases
> than it does here?  Thanks!

I'm not sure FS loader can be made much smaller but I'm more concerned
how it would scale if I were to add support for the other boot modes we
need such as eMMC/SD raw mode, QSPI/OSPI, Y-Modem, and others to come.

For all of those we have a solution in production similar to what was
proposed here [1] tapping into the SPL loader framework at (almost) zero
cost. Growing FS loader beyond what it is today plus adding in the
support for runtime-selection of firmware load media all added up may
quickly become prohibitive for very space constrained scenarios like on
our AM654x devices.

--
Andreas Dannenberg
Texas Instruments Inc

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

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

Re: [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC

2019-05-21 Thread dannenb...@ti.com

Hi TF,

On Tue, May 21, 2019 at 05:40:19AM +, Chee, Tien Fong wrote:
> > +   fs_loader0: fs_loader@0 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> 
> Why not using phandlepart = < 1>, this would help to avoid mmc init
> duplication in a few places such as patch [05/11].
> 

See comment on earlier patch, this path was chosen to allow for
flexibility during runtime. When using FS loader as you intended it to
get used it works very well (we are actually using it for other purposes
on another device).

Hence my argument that the approach I chose with the original [1] SYSFW
loader series of opening up the SPL loader framework in a "lean & mean"
fashion and the FS loader driver as it is today are really things that
are complementary and can co-exist when one starts looking under the hood.

--
Andreas Dannenberg
Texas Instruments Inc

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

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

Re: [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework

2019-05-21 Thread dannenb...@ti.com

Hi TF,

On Tue, May 21, 2019 at 05:21:15AM +, Chee, Tien Fong wrote:
> On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> > +   if (mmc_dev < 0) {
> > +   pr_err("%s: Getting MMC device index failed (%d)\n",
> > __func__,
> > +      mmc_dev);
> > +   return mmc_dev;
> > +   }
> > +
> > +   ret = uclass_get_device(UCLASS_MMC, mmc_dev, );
> > +   if (ret < 0) {
> > +   pr_err("%s: Getting MMC device failed (%d)\n",
> > __func__, ret);
> > +   return ret;
> > +   }
> > +
> > +   ret = mmc_initialize(NULL);
> > +   if (ret < 0) {
> > +   pr_err("%s: Initializing MMC device failed (%d)\n",
> > __func__,
> > +      ret);
> > +   return ret;
> > +   }
> > +
> > +   mmc = mmc_get_mmc_dev(mmcdev);
> > +   if (!mmc) {
> > +   pr_err("%s: Getting underlying MMC device failed\n",
> > __func__);
> > +   return -ENODEV;
> > +   }
> > +
> > +   ret = mmc_init(mmc);
> > +   if (ret) {
> > +   printf("%s: mmc init failed with error: %d\n",
> > __func__, ret);
> > +   return ret;
> > +   }
> > +
> 
> The probe function in fs loader already support the block init, and the
> block init would init the mmc.

Yes I'm sure this could have gotten simplified if I were to use the DTS
to describe the boot device. But as explained earlier I was exploring a
way to make it work without DTS for added flexibility so I can pick the
boot device at runtime.

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data

2019-05-21 Thread dannenb...@ti.com

Hi TF,
first, thanks for taking time to continue having the discussion around
this patch series.

On Tue, May 21, 2019 at 05:40:59AM +, Chee, Tien Fong wrote:
> On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> > To give us more flexibility using the FS loader eliminate the need of
> > always having to use the ENV to configure the block device but rather
> > allow the respective block device and partition to be setup through
> > platform data.
> > 
> > Signed-off-by: Andreas Dannenberg 
> 
> Why not using DT method?

We would like to use a single U-Boot build to support all of the
different boot modes (boot media) a given device supports. In case of
this RFC series this is really distilled down to only mmc0 and mmc1 but
this already illustrates the point. The patch 05/11 shows how
spl_boot_device() is used to make the MMC probing dependent on the boot
device mmc0 vs mmc1. So hard-coding in DT will lose this flexibility. Of
course there would be ways out such as dynamically updating DTS or to
extend the FS loader probe function to select from multiple DTS nodes
based on boot device, but all would come at a cost of additional memory
consumption.

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/8] test: py: add option to select device tree used during compilation

2019-05-21 Thread Patrick DELAUNAY

Hi Stephen,

For information after the remarksSimon's  remark, 
I simplify the test, so this part is no more needed
See http://patchwork.ozlabs.org/patch/1102938/

But I will answer with my status and my tests done on the python code.

> 
> On 5/20/19 7:00 AM, Patrick Delaunay wrote:
> > Only used for spl compilation which include the device tree (with
> > platdata or embedded device tree).
> > For U-boot, test use config.dtb, by default :
> > "build_dir + '/arch/sandbox/dts/test.dtb'"
> >
> > Signed-off-by: Patrick Delaunay 
> > ---
> > I need to force o_dt = 'all' to avoid make error:
> >
> > make: *** empty string invalid as file name.  Stop.
> >
> > But, I don't sure that it is the better solution for pytest.
> 
> This feels a bit odd. What board are you compiling for? I would expect the 
> same
> compilation commands to "just work" for all boards, and would initially claim 
> that if
> they don't, it's a bug in the makefiles that should be fixed there.

Yes, it is strange.

When I compile the board I have not the problem, I have issue only when I use 
pytest.

For example:

./test/py/test.py --bd sandbox_spl --build --device-tree sandbox -k 
'test_000_version'
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox_spl -s 
sandbox_spl_defconfig
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox_spl 
DEVICE_TREE=sandbox -s -j8

=> it tis OK

./test/py/test.py --bd sandbox --build  -k 'test_000_version'
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox -s 
sandbox_defconfig
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox all -s -j8

=> it is OK

But if I use =

if build_dir != source_dir:
o_opt = 'O=%s' % build_dir
else:
o_opt = 'all'

if device_tree:
o_dt = 'DEVICE_TREE=%s' % device_tree
else:
o_dt = ''

Same result for the first command : 
./test/py/test.py --bd sandbox --build  -k 'test_000_version'
=> it is OK

But the second command I have got the next error:

./test/py/test.py --bd sandbox --build  -k 'test_000_version'
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox -s 
sandbox_defconfig
+make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox  -s -j8
make: *** empty string invalid as file name.  Stop.
Exit code: 2
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/main.py", line 
86, in wrap_session
INTERNALERROR> config._do_configure()
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/config.py", 
line 830, in _do_configure
INTERNALERROR> 
self.hook.pytest_configure.call_historic(kwargs=dict(config=self))
INTERNALERROR>   File 
"/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", line 
729, in call_historic
INTERNALERROR> self._hookexec(self, self._nonwrappers + self._wrappers, 
kwargs)
INTERNALERROR>   File 
"/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", line 
338, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File 
"/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", line 
333, in 
INTERNALERROR> _MultiCall(methods, kwargs, hook.spec_opts).execute()
INTERNALERROR>   File 
"/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", line 
596, in execute
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR>   File 
"/local/home/frq07632/views/u-boot/u-boot/test/py/conftest.py", line 148, in 
pytest_configure
INTERNALERROR> runner.run(cmd, cwd=source_dir)
INTERNALERROR>   File 
"/local/home/frq07632/views/u-boot/u-boot/test/py/multiplexed_log.py", line 
173, in run
INTERNALERROR> raise exception
INTERNALERROR> Exception: Exit code: 2


Moreover when I execute the command manually (without python), the compilation 
is accepted 

$> make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox -s 
sandbox_defconfig
$> make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox  -s -j8


I also try: 

options = []
if build_dir != source_dir:
options.append('O=%s ' % build_dir)
if device_tree:
options.append('DEVICE_TREE=%s ' % device_tree)
o_opt = ' '.join(options)

cmds = (
['make', o_opt, '-s', board_type + '_defconfig'],
['make', o_opt, '-s', '-j8'],
)


Then the o_opt is correctly build but the DEVICE_TREE option is not used when 
the build is requested by python(it is done manually)

make O=/local/home/frq07632/views/u-boot/u-boot/build-sandbox_spl  
DEVICE_TREE=bad  -s -j8

Device Tree Source is not correctly specified.
Please define 'CONFIG_DEFAULT_DEVICE_TREE'
or build with 'DEVICE_TREE=' argument

./test/py/test.py --bd sandbox_spl --build --device-tree bad -k 
'test_000_version'

=> no error !

> > diff --git a/test/py/conftest.py b/test/py/conftest.py
> 
> > +if device_tree:
>

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

2019-05-21 Thread Eugeniu Rosca

Hi Simon,

On Tue, May 21, 2019 at 10:43:04AM -0600, Simon Glass wrote:
> On Mon, 20 May 2019 at 01:23, Eugeniu Rosca  wrote:
[..]
> > I can identify two Android-dedicated README files, but none of them
> > seems to be suitable for the new command:
> >  - doc/README.android-fastboot
> >  - doc/README.avb2
> >
> > Igor, Sam, what's your view on the above? Would you suggest creating
> > a doc/README.android-bcb or there is a more elegant solution to it?
> 
> How about a new README.android which links to the other two and adds
> your new info?

How about below directory structure:

 u-boot $ tree doc/android
 doc/android
 ├── avb2.txt
 ├── bcb.txt
 └── fastboot.txt

> 
> >
> > >
> > > Should it default to enabled if avb is used?
> >
> > I think at this specific moment in time, 'bcb' is orthogonal (meaning it
> > is neither a direct, nor a reverse dependency) to any other Android
> > feature in U-Boot. This could be re-assessed, if platform maintainers
> > start to rely on 'bcb' in their U-Boot environments on regular basis.
> 
> OK. Also is there a sandbox driver for this? We should have a test.

Emulating and exposing MMC devices in sandbox should be the only
prerequisite for sandbox testing and this seems to be already supported
via drivers/mmc/sandbox_mmc.c. However, to be honest, I was unsuccessful
bringing up the MMC devices on sandbox in the past. Particularly,
booting the latest sandbox U-Boot (CMD_MMC=y) I get:

=> mmc list
No MMC device available

I think there is something elementary which I am missing?

Regardless, I need some more days to implement the test and repartition
the README files. I think Sam would appreciate if you can provide your
Ack to the series as-is (it was extensively statically and dynamically
tested on R-Car H3ULCB) and I submit the doc/test updates separately.
Otherwise, I will push the next revision hopefully in a week or so.

> 
> Regards,
> Simon

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

[U-Boot] [PATCH v3 3/3] dm: doc: add documentation for pre-reloc properties in SPL and TPL

Add documentation for the pre-reloc property in SPL and TPL device-tree:
- u-boot,dm-pre-proper
- u-boot,dm-pre-reloc
- u-boot,dm-spl
- u-boot,dm-tpl

Signed-off-by: Patrick Delaunay 
Reviewed-by: Simon Glass 
---

Changes in v3:
- rebase on u-boot-dm/sandbox-working

Changes in v2:
- rebase on master

 doc/README.SPL  | 16 
 doc/README.TPL  |  4 
 doc/driver-model/README.txt |  4 
 include/dm/ofnode.h |  6 --
 include/dm/util.h   |  6 --
 5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/doc/README.SPL b/doc/README.SPL
index 7a30fef..6eed83f 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -66,6 +66,22 @@ CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
 CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
 CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
 
+Device tree
+---
+The U-Boot device tree is filtered by the fdtgrep tools during the build
+process to generate a much smaller device tree used in SPL (spl/u-boot-spl.dtb)
+with:
+- the mandatory nodes (/alias, /chosen, /config)
+- the nodes with one pre-relocation property:
+  'u-boot,dm-pre-reloc' or 'u-boot,dm-spl'
+
+ftgrep is also used to remove:
+- the properties defined in CONFIG_OF_SPL_REMOVE_PROPS
+- all the pre-relocation properties
+  ('u-boot,dm-pre-reloc', 'u-boot,dm-spl' and 'u-boot,dm-tpl')
+
+All the nodes remaining in the SPL devicetree are bound
+(see driver-model/README.txt).
 
 Debugging
 -
diff --git a/doc/README.TPL b/doc/README.TPL
index 980debe..c94129f 100644
--- a/doc/README.TPL
+++ b/doc/README.TPL
@@ -34,6 +34,10 @@ determine which SPL options to choose based on whether 
CONFIG_TPL_BUILD
 is set. Source files can be compiled for TPL with options choosed in the
 board config file.
 
+TPL use a small device tree (u-boot-tpl.dtb), containing only the nodes with
+the pre-relocation properties: 'u-boot,dm-pre-reloc' and 'u-boot,dm-tpl'
+(see README.SPL for details).
+
 For example:
 
 spl/Makefile:
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 07b120d..532a771 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -849,6 +849,10 @@ in the device tree node. For U-Boot proper you can use 
'u-boot,dm-pre-proper'
 which means that it will be processed (and a driver bound) in U-Boot proper
 prior to relocation, but will not be available in SPL or TPL.
 
+To reduce the size of SPL and TPL, only the nodes with pre-relocation 
properties
+('u-boot,dm-pre-reloc', 'u-boot,dm-spl' or 'u-boot,dm-tpl') are keept in their
+device trees (see README.SPL for details); the remaining nodes are always 
bound.
+
 Then post relocation we throw that away and re-init driver model again.
 For drivers which require some sort of continuity between pre- and
 post-relocation devices, we can provide access to the pre-relocation
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index d206ee2..b45da5e 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -662,12 +662,14 @@ int ofnode_read_simple_size_cells(ofnode node);
  * After relocation and jumping into the real U-Boot binary it is possible to
  * determine if a node was bound in one of SPL/TPL stages.
  *
- * There are 3 settings currently in use
- * -
+ * There are 4 settings currently in use
+ * - u-boot,dm-pre-proper: U-Boot proper pre-relocation only
  * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
  *   Existing platforms only use it to indicate nodes needed in
  *   SPL. Should probably be replaced by u-boot,dm-spl for
  *   new platforms.
+ * - u-boot,dm-spl: SPL and U-Boot pre-relocation
+ * - u-boot,dm-tpl: TPL and U-Boot pre-relocation
  *
  * @node: node to check
  * @return true if node is needed in SPL/TL, false otherwise
diff --git a/include/dm/util.h b/include/dm/util.h
index 60d3b93..348c2ac 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -52,12 +52,14 @@ static inline void dm_dump_devres(void)
  * it is possible to determine if a node was bound in one of
  * SPL/TPL stages.
  *
- * There are 3 settings currently in use
- * -
+ * There are 4 settings currently in use
+ * - u-boot,dm-pre-proper: U-Boot proper pre-relocation only
  * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
  *   Existing platforms only use it to indicate nodes needed in
  *   SPL. Should probably be replaced by u-boot,dm-spl for
  *   existing platforms.
+ * - u-boot,dm-spl: SPL and U-Boot pre-relocation
+ * - u-boot,dm-tpl: TPL and U-Boot pre-relocation
  * @node: of node
  *
  * Returns true if node is needed in SPL/TL, false otherwise.
-- 
2.7.4

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

[U-Boot] [PATCH v3 0/3] fdt: Allow indicating a node is for U-Boot proper only


Hi,

I create this serie with:

1/ documentation update for previous patch
   [U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
   http://patchwork.ozlabs.org/patch/1081155/

   PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
   pre reloc properties in SPL and TPL device tree")
   but not the documentation.

2/ missing part for v1 serie (patch 1/2)
   http://patchwork.ozlabs.org/project/uboot/list/?series=89846
   => http://patchwork.ozlabs.org/patch/1035797

3/ new tests for pre-reloc propertie in SPL as suggested by Simon
   (http://patchwork.ozlabs.org/patch/1081155/#2156621)

Regards
Patrick


Changes in v3:
- simplify test after Simon remarks by using fdtgrep on spl dtb
- rebase on u-boot-dm/sandbox-working

Changes in v2:
- rebase on master

Patrick Delaunay (3):
  test: check u-boot properties in SPL device tree
  fdt: Allow indicating a node is for U-Boot proper only
  dm: doc: add documentation for pre-reloc properties in SPL and TPL

 arch/sandbox/dts/sandbox.dtsi| 18 ++
 doc/README.SPL   | 16 
 doc/README.TPL   |  4 
 doc/driver-model/README.txt  |  4 
 drivers/core/util.c  |  2 ++
 drivers/video/video-uclass.c |  4 +++-
 include/dm/ofnode.h  |  6 --
 include/dm/util.h|  6 --
 test/py/tests/test_ofplatdata.py | 28 
 9 files changed, 83 insertions(+), 5 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH v3 1/3] test: check u-boot properties in SPL device tree

Add a test to check the management of the U-boot relocation properties
for device tree SPL generation (fdtgrep result) and platdata:
- 'dm-pre-proper' and 'dm-tpl' not included in SPL
- 'dm-pre-reloc' and 'dm-spl' included in SPL

Signed-off-by: Patrick Delaunay 
---

Changes in v3:
- simplify test after Simon remarks by using fdtgrep on spl dtb

Changes in v2: None

 arch/sandbox/dts/sandbox.dtsi| 18 ++
 test/py/tests/test_ofplatdata.py | 28 
 2 files changed, 46 insertions(+)

diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 2fb365d..c6d5650 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -192,6 +192,24 @@
compatible = "sandbox,spl-test.2";
};
 
+   spl-test5 {
+   u-boot,dm-tpl;
+   compatible = "sandbox,spl-test";
+   stringarray = "tpl";
+   };
+
+   spl-test6 {
+   u-boot,dm-pre-proper;
+   compatible = "sandbox,spl-test";
+   stringarray = "pre-proper";
+   };
+
+   spl-test7 {
+   u-boot,dm-spl;
+   compatible = "sandbox,spl-test";
+   stringarray = "spl";
+   };
+
square {
compatible = "demo-shape";
colour = "blue";
diff --git a/test/py/tests/test_ofplatdata.py b/test/py/tests/test_ofplatdata.py
index 98103ee..263334b 100644
--- a/test/py/tests/test_ofplatdata.py
+++ b/test/py/tests/test_ofplatdata.py
@@ -2,6 +2,7 @@
 # Copyright (c) 2016 Google, Inc
 
 import pytest
+import u_boot_utils as util
 
 OF_PLATDATA_OUTPUT = '''
 of-platdata probe:
@@ -31,6 +32,15 @@ intarray 0 0 0 0
 longbytearray 00 00 00 00 00 00 00 00 00
 string 
 stringarray "one" "" ""
+of-platdata probe:
+bool 0
+byte 00
+bytearray 00 00 00
+int 0
+intarray 0 0 0 0
+longbytearray 00 00 00 00 00 00 00 00 00
+string 
+stringarray "spl" "" ""
 '''
 
 @pytest.mark.buildconfigspec('spl_of_platdata')
@@ -40,3 +50,21 @@ def test_ofplatdata(u_boot_console):
 cons.restart_uboot_with_flags(['--show_of_platdata'])
 output = cons.get_spawn_output().replace('\r', '')
 assert OF_PLATDATA_OUTPUT in output
+
+@pytest.mark.buildconfigspec('spl_of_platdata')
+def test_spl_devicetree(u_boot_console):
+"""Test content of spl device-tree"""
+cons = u_boot_console
+dtb = cons.config.build_dir + '/spl/u-boot-spl.dtb'
+fdtgrep = cons.config.build_dir + '/tools/fdtgrep'
+output = util.run_and_log(cons, [fdtgrep, '-l', dtb])
+
+assert "u-boot,dm-pre-reloc" not in output
+assert "u-boot,dm-pre-proper" not in output
+assert "u-boot,dm-spl" not in output
+assert "u-boot,dm-tpl" not in output
+
+assert "spl-test4" in output
+assert "spl-test5" not in output
+assert "spl-test6" not in output
+assert "spl-test7" in output
-- 
2.7.4

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

[U-Boot] [PATCH v3 2/3] fdt: Allow indicating a node is for U-Boot proper only

This add missing parts for previous commit 06f94461a9f4
("fdt: Allow indicating a node is for U-Boot proper only")

At present it is not possible to specify that a node should be used before
relocation (in U-Boot proper) without it also ending up in SPL and TPL
device trees. Add a new "u-boot,dm-pre-proper" boolean property for this.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/core/util.c  | 2 ++
 drivers/video/video-uclass.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/core/util.c b/drivers/core/util.c
index 96e47dc..60b939a 100644
--- a/drivers/core/util.c
+++ b/drivers/core/util.c
@@ -42,6 +42,8 @@ bool dm_ofnode_pre_reloc(ofnode node)
 #else
if (ofnode_read_bool(node, "u-boot,dm-pre-reloc"))
return true;
+   if (ofnode_read_bool(node, "u-boot,dm-pre-proper"))
+   return true;
 
/*
 * In regular builds individual spl and tpl handling both
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 14aac88..d922e53 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -291,7 +291,9 @@ static int video_post_bind(struct udevice *dev)
return 0;
size = alloc_fb(dev, );
if (addr < gd->video_bottom) {
-   /* Device tree node may need the 'u-boot,dm-pre-reloc' tag */
+   /* Device tree node may need the 'u-boot,dm-pre-reloc' or
+* 'u-boot,dm-pre-proper' tag
+*/
printf("Video device '%s' cannot allocate frame buffer memory 
-ensure the device is set up before relocation\n",
   dev->name);
return -ENOSPC;
-- 
2.7.4

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

Re: [U-Boot] Making U-Boot smaller

2019-05-21 Thread Jagan Teki

On Tue, May 21, 2019 at 10:14 PM Simon Glass  wrote:
>
> Hi,
>
> (moved from thread "U-Boot PXA support")
>
> We have of-platdata, which produces C data from the DT, for linking
> into U-Boot. It saves libfdt and DT space. But we still have the DM
> overhead.
>
> We have binman which can insert values into the binary after
> link-time. This is barely used at present, only for accessing the
> location of things in flash.
>
> Another thing is that every little tweak and feature adds a few bytes
> and there are dozens of them in each release. It would be interesting
> to build a board from 10 years ago (like PXA) and see where the growth
> is. My bet is that we could add Kconfig options to disable extra
> features (and enhancements of features) and make quite a difference.
>
> For DM, I think it would be interesting to revisit and compare against
> the initial release, and see if some features could be made optional
> in SPL.
>
> Finally I feel we could implement a single-device API for where
> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
> single instance of tiny MMC for MMC, etc.

This is what I'm looking for quite sometime, a tiny MMC which would
bypass the mmc stack and do the possible stuff in SPL, since we don't
have any option to use full DM in SPL (specifically for Allwinner 64
SoC's). API that would atleast compatible with DM with small
foot-print would help.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

2019-05-21 Thread Sam Protsenko

Hi Eugeniu,

On Tue, May 21, 2019 at 2:20 PM Eugeniu Rosca  wrote:
>
> Hi Sam,
>
> On Mon, May 20, 2019 at 06:16:38PM +0300, Sam Protsenko wrote:
> > Hi Eugeniu,
> >
> > On Mon, May 20, 2019 at 10:23 AM Eugeniu Rosca  
> > wrote:
> [..]
> > > Igor, Sam, what's your view on the above? Would you suggest creating
> > > a doc/README.android-bcb or there is a more elegant solution to it?
> > >
> >
> > Documentation would be nice. Although you already provided a generic
> > description of 'bcb' command in 'help bcb', the user often wants to
> > read more high-level documentation. I'd say, you can copy the
> > description from commit message to doc/README.android-bcb, extending
> > it with usual use-cases, and how this command can be used in those
> > use-cases. For example, your pseudo-code for reboot reason you
> > provided to me earlier, etc.
>
> Agreed. In my queue.
>

Just to be clear: can we expect it to be sent in v3, or it will be
separate patch-set?

> > Also, it can be useful to mention if
> > Google have any requirements (mandatory or optional) for the
> > bootloader (misc partition, reboot reason, recovery, etc), and how
> > this 'bcb' command can help in those requirements implementation.
>
> Well, a subset of the Android bootloader requirements is publicly
> available via https://source.android.com/devices/bootloader, but I saw
> traces of the "Android Boot/Bootloader Requirements" document name
> mentioned in the descriptions of U-Boot commits received from our
> suppliers. I _do not_ have access to the latter. If anybody from Google
> sees this message and can share the document or a subset of it, that
> would be great.
>
> To be clear, the background behind the 'bcb' command is not because I
> was assigned the task to implement any of the Android bootloader
> requirements, but because I saw improper implementations of some of
> those requirements in the patches received from our supplier and
> wanted to showcase a better/U-Boot-compliant way to accomplish those.
>
> So, I don't give any commitment to support the Android-related parts in
> U-Boot, but will signal and express my opinion whenever any features
> backported from AOSP don't follow the patterns established in community.
>

Sure, I just meant that it could be nice to mention it in the
documentation, that 'bcb' command can help in those Google
requirements implementation.

> >
> > All that said, IMHO documentation/test wise: it's not critical in this
> > case, you can add that later, just to speed-up the whole development
> > process and divide it into iterations. But that's for maintainers to
> > decide, of course.
> >
> > Also, I've a feeling that we have another problem, more common than
> > just a documentation. At the moment we have a bunch of Android related
> > features, which don't have namespace separation on several levels:
> >  - file/directories: we may want to move all Android related commands
> > to sub-directory
> >  - commands: we may want to add main command called "android" for all
> > Android-related commands, or maybe just a prefix
> >  - Kconfig: we may want to have some generic naming scheme for all
> > Android-related commands
> >  - Documentation, tests: the same here
> >
> > So at some point we will probably need to discuss and fix that
> > somehow. Not here, of course :)
>
> Agree with the most of the bullets. However, WRT merging all the
> available Android commands into a single command, I see room for
> more discussion. Here is some valuable feedback from Ruslan Trofymenko:
>
>  --- quote from https://patchwork.ozlabs.org/patch/1004002/#2049412 ---
> On Thu, 6 Dec 2018 at 03:31, Simon Glass  wrote:
> > Perhaps we need a new 'android' command with an 'ab_select'
> > subcommand? Then the automatica abbreviation will work.
> >
>
> Agree with all your previous comments, will send v2 shortly. But this
> one I'd like to leave as is (I will drop android_ prefix though). I
> think adding "android" command may lead to unneeded architecture
> complexity in future, e.g.:
>   - we will need to re-work next commands as sub-commands of "android"
> command: fastboot, dtimg, mmc_swrite (which can be hard as ab_select
> command file has BSD license and other commands have GPL license)
>  - we will need to implement sub-sub-commands (e.g. for "android dtimg
> dump ..." etc.)
>  - having "android" command can be inconvenient for users and may
> break existing API (e.g. it will force users to use "android fastboot"
> instead of just "fastboot" command)
>  - actually I don't see any namespace issues that can be solved by
> adding "android" command
>
> Also, in subsequent patch, I will add the dedicated menu option for
> Android-related commands and will pull all existing Android commands
> (along with ab_select) to that menu entry.
>
> So I hope it's fine with you if I leave this command as "ab_select"?
>  --- end quote https://patchwork.ozlabs.org/patch/1004002/#2049412 ---
>
> In addition, based on the feedback from Alex

[U-Boot] Making U-Boot smaller

Hi,

(moved from thread "U-Boot PXA support")

We have of-platdata, which produces C data from the DT, for linking
into U-Boot. It saves libfdt and DT space. But we still have the DM
overhead.

We have binman which can insert values into the binary after
link-time. This is barely used at present, only for accessing the
location of things in flash.

Another thing is that every little tweak and feature adds a few bytes
and there are dozens of them in each release. It would be interesting
to build a board from 10 years ago (like PXA) and see where the growth
is. My bet is that we could add Kconfig options to disable extra
features (and enhancements of features) and make quite a difference.

For DM, I think it would be interesting to revisit and compare against
the initial release, and see if some features could be made optional
in SPL.

Finally I feel we could implement a single-device API for where
CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
single instance of tiny MMC for MMC, etc.

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

Re: [U-Boot] [PATCH 1/1] cmd: remove unused `display` command

On Mon, 20 May 2019 at 23:50, Heinrich Schuchardt  wrote:
>
> Compiling the display command leads to an error
>
> undefined reference to `display_set'
>
> No implementation of display_set() exists in U-Boot.
>
> Eliminate the `display` command as well as the accompanying files.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/Kconfig|  8 ---
>  cmd/Makefile   |  1 -
>  cmd/display.c  | 53 --
>  doc/README.LED_display | 26 -
>  include/led-display.h  | 18 --
>  5 files changed, 106 deletions(-)
>  delete mode 100644 cmd/display.c
>  delete mode 100644 doc/README.LED_display
>  delete mode 100644 include/led-display.h

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

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

Hi Eugeniu,

On Mon, 20 May 2019 at 01:23, Eugeniu Rosca  wrote:
>
> Hi Simon
> cc: Sam, Igor, feel free to correct/augment anything of below
>
> On Sat, May 18, 2019 at 10:33:02AM -0600, Simon Glass wrote:
> > Hi Eugeniu,
> >
> > On Fri, 17 May 2019 at 08:46, Eugeniu Rosca  wrote:
> > >
> > > 'Bootloader Control Block' (BCB) is a well established term/acronym in
> > > the Android namespace which refers to a location in a dedicated raw
> > > (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> > > which is used as media for exchanging messages between Android userspace
> > > (particularly recovery [1]) and an Android-capable bootloader.
> > >
> [..]
> >
> > Where is this documented? Perhaps it should go in README.avb2?
>
> README.avb2 is solely about the "verified/secure" booting of Android,
> while the 'bcb' command proposed in this patch can be useful both in
> verified boot scenarios (e.g. full-featured U-Boot builds), as well
> as in non-avb ones (e.g. development, PoC, demos, custom
> configurations). Thus, I think that README.avb2 is not the best
> place for 'bcb'.
>
> More generally, as somebody who uses git as an extension of himself, I
> am quite happy with commit-only documentation. OTOH, for those who
> receive U-Boot in tarballs or expect source-level docs/tutorials, I
> agree that having the 'bcb' described in a README might be helpful.
>
> I can identify two Android-dedicated README files, but none of them
> seems to be suitable for the new command:
>  - doc/README.android-fastboot
>  - doc/README.avb2
>
> Igor, Sam, what's your view on the above? Would you suggest creating
> a doc/README.android-bcb or there is a more elegant solution to it?

How about a new README.android which links to the other two and adds
your new info?

>
> >
> > Should it default to enabled if avb is used?
>
> I think at this specific moment in time, 'bcb' is orthogonal (meaning it
> is neither a direct, nor a reverse dependency) to any other Android
> feature in U-Boot. This could be re-assessed, if platform maintainers
> start to rely on 'bcb' in their U-Boot environments on regular basis.

OK. Also is there a sandbox driver for this? We should have a test.

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

Re: [U-Boot] U-Boot PXA support

Hi,

On Tue, 21 May 2019 at 08:50, Tom Rini  wrote:
>
> On Tue, May 21, 2019 at 04:34:19PM +0200, Marek Vasut wrote:
> > On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> > > On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
> > >> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> > >>> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
> >  It's slightly off-topic but I wonder whether this ongoing
> >  deprecation
> >  of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really
> >  simplifies
> >  anything at all.
> >  There are tons of devices that are still working good and there
> >  are
> >  even ARMv5-based MCUs that are still produced (such as CH561
> >  manufactured by WCH).
> > >>>
> > >>> Please note that as of today Marvell is also still producing them
> > >>> PXAs
> > >>> which are not to go end-of-life before later next year I believe.
> > >>>
> >  IMHO it makes sense to drop only the XScale-specific tuning first
> >  and
> >  to treat PXA (and similar CPUs) as a more generic armv5te. I
> >  wonder
> >  what to do when GCC drops ARMv5 completely...
> > >>>
> > >>> I believe it was only an issue with early gcc 8 but does work just
> > >>> fine
> > >>> again with later 8.2 or 8.3 versions.
> > >>>
> > >>> However, what is more concerning to me is that in today's
> > >>> convoluted
> > >>> moloch known as U-Boot there may simply not be any space any more
> > >>> for
> > >>> something truly embedded but somewhat limited like PXA based
> > >>> hardware.
> > >>
> > >> If we ignore the PXA25x/26x, the PXA27x has loads of SRAM for U-Boot
> > >> SPL
> > >> and then can load U-Boot proper into DRAM. What's the problem ?
> > >
> > > At least on the Colibri PXA270 it is more about NOR flash storage. The
> > > factory configuration block gets stored at an offset of 0x4 which
> > > leaves only 256 KB for the boot loader. However, of course one could
> > > migrate it all over to using SPL and store U-Boot proper after the
> > > factory configuration block. But to change all that for our very oldest
> > > module which is going end-of-live the next year may not make too much
> > > sense.
> >
> > True
> >
> > > So the real issue with U-Boot for such platforms is basically that the
> > > complexity and footprint increased steadily leaving them behind and
> > > eventually just removing them may be the logical conclusion. After all
> > > we are talking about just a boot loader which is used to boot the
> > > "real" system and good is. However, if even one percent of today's U-
> > > Boot is actually used for booting it is probably already quite a lot
> > > (;-p).
> >
> > The size growth is a problem, even for todays' systems, and it
> > contradicts this "universal" part in U-Boot . That's a real issue which
> > should be addressed , and this fevered push for DM/DT conversion does
> > not help at all.
>
> As I thought I had said before, I think it's really interesting how
> Zephyr takes a DT and spits out a lot of static information.  Taking
> that idea far enough for platforms where no, we don't need any real
> run-time detection of this-or-that could be pretty interesting and
> result in some real space reduction.

I'll reply in a new thread.

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

Re: [U-Boot] [PATCH 1/2] fdtdec: test: Fix memory leak

Hi Thierry,

On Tue, 21 May 2019 at 04:21, Thierry Reding  wrote:
>
> On Mon, May 20, 2019 at 02:51:08PM -0600, Simon Glass wrote:
> > Hi Thierry,
> >
> > On Mon, 20 May 2019 at 10:05, Thierry Reding  
> > wrote:
> > >
> > > From: Thierry Reding 
> > >
> > > Free the memory allocated to store the test FDT upon test completion to
> > > avoid leaking the memory. We don't bother cleaning up on test failure
> > > since the code is broken in that case and should be fixed, in which case
> > > the leak would also go away.
> > >
> > > Reported-by: Tom Rini 
> > > Suggested-by: Heinrich Schuchardt 
> > > Signed-off-by: Thierry Reding 
> > > ---
> > >  lib/fdtdec_test.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
> > > index f6defe16c5a6..54efcc3d46ac 100644
> > > --- a/lib/fdtdec_test.c
> > > +++ b/lib/fdtdec_test.c
> > > @@ -138,6 +138,7 @@ static int run_test(const char *aliases, const char 
> > > *nodes, const char *expect)
> > > }
> > >
> > > printf("pass\n");
> > > +   free(blob);
> >
> > Strictly speaking, CHECKVAL() can cause a function return in the case
> > of an error.
> >
> > So a better solution might be to put the code after the malloc() into
> > a separate function.
>
> When Heinrich suggested this fix he brought up the same issue, but
> concluded, and I agree with him, that it wasn't worth addressing the
> CHECKVAL case because if CHECKVAL failed, our code was buggy and would
> need fixing, at which point the leak would go away along with the bug.
>
> Do you feel strongly about reworking this so it doesn't leak in the
> error case either?

No. Oddly enough I haven't seen a Coverity report on this.

Reviewed-by: Simon Glass 

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

[U-Boot] fit_check_sign - offline FIT verification with public certificate only

2019-05-21 Thread Luca Boccassi

Hi,

Is there a particular reason why fit_check_sign can only verify an
image using a DTB, rather than just the x509 public cert? Or is it just
that nobody has added the option so far? It would be useful to verify
images offline.

Thanks!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/8] test: py: add option to select device tree used during compilation

2019-05-21 Thread Stephen Warren


On 5/20/19 7:00 AM, Patrick Delaunay wrote:

Only used for spl compilation which include the device tree
(with platdata or embedded device tree).
For U-boot, test use config.dtb, by default :
"build_dir + '/arch/sandbox/dts/test.dtb'"

Signed-off-by: Patrick Delaunay 
---
I need to force o_dt = 'all' to avoid make error:

make: *** empty string invalid as file name.  Stop.

But, I don't sure that it is the better solution for pytest.


This feels a bit odd. What board are you compiling for? I would expect 
the same compilation commands to "just work" for all boards, and would 
initially claim that if they don't, it's a bug in the makefiles that 
should be fixed there.



diff --git a/test/py/conftest.py b/test/py/conftest.py



+if device_tree:
+o_dt = 'DEVICE_TREE=%s' % device_tree
+else:
+o_dt = 'all'


You might want to make o_dt be a list that's either empty or contains 
one string. Then ...



  cmds = (
  ['make', o_opt, '-s', board_type + '_defconfig'],
-['make', o_opt, '-s', '-j8'],
+['make', o_opt, o_dt, '-s', '-j8'],
  )


... you can modify that line so that it doesn't add any additional 
options if o_dt is empty, so there's no change to the command-line 
except in the case where a DT is specified, to avoid the potential for 
any change to the existing flow:


['make', o_opt, *o_dt, '-s', '-j8'],

or:

['make', o_opt, '-s', '-j8'] + o_dt,
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/8] fdt: Allow indicating a node is for U-Boot proper only

2019-05-21 Thread Patrick DELAUNAY

Hi Simon,

I will reply for the serie
 
> Hi Patrick,
> 
> On Mon, 20 May 2019 at 07:00, Patrick Delaunay 
> wrote:
> >
> >
> > Hi,
> >
> > I create this v2 serie with:
> >
> > 1/ documentation update for previous patch
> >[U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
> >http://patchwork.ozlabs.org/patch/1081155/
> >
> >PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
> >pre reloc properties in SPL and TPL device tree")
> >but not the documentation.
> >
> > 2/ missing part for (patch 1/2)
> >http://patchwork.ozlabs.org/project/uboot/list/?series=89846
> >
> > 3/ new tests for pre-reloc propertie in SPL as suggested by Simon
> >(http://patchwork.ozlabs.org/patch/1081155/#2156621)
> >
> > Tell me if is better to split the serie.
> 
> Somehow this cover letter appears in a patch, hence some of my confusion. I 
> see
> what you are doing and it is a comprehensive approach.
> 
> But please see my comments about comparing the .dtb file instead of making
> sandbox print it out.

I will change the test to only compare the device tree : it is more simple.

=> v3 in few days

My first approach was complicated but it is to allow
- check if sandbox SPL with devicetree and libfdt in working as is already done 
for platdata
- check if sandbox SPL can start U-Boot in booth case 
  (by executing the simple test_000_version in ./py/tests/test_000_version.py)
- split test and normal device tree (I move the "spl-tests" nodes in test.dts)

But it is too complicated just the purpose of this test.

NB: the executable "u-boot-spl" for sandbox_spl_defconfig already 
   include the devicetree information, with platdata.


> Regards,
> Simon

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

[U-Boot] [PATCH v5 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary

2019-05-21 Thread Luca Ceresoli

The recently-added ZYNQMP_SPL_PM_CFG_OBJ_FILE option allows SPL to load a
PMUFW configuration object from a binary blob. However the configuration
object is produced by Xilinx proprietary tools as a C source file and no
tool exists to easily convert it to a binary blob in an embedded Linux
build system for U-Boot to use.

Add a simple Python script to do the conversion.

It is definitely not a complete C language parser, but it is enough to
parse the known patterns generated by Xilinx tools, including:

 - defines
 - literal integers, optionally with a 'U' suffix
 - bitwise OR between them

Signed-off-by: Luca Ceresoli 

---

Changes v4 -> v5:
 - remove argparse allow_abbrev to run on Python < 3.5, Ubuntu 14.04
   (Michal)

Changes v3 -> v4:
 - move to tools/ directory
 - remove double item.strip() call
---
 tools/zynqmp_pm_cfg_obj_convert.py | 301 +
 1 file changed, 301 insertions(+)
 create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py

diff --git a/tools/zynqmp_pm_cfg_obj_convert.py 
b/tools/zynqmp_pm_cfg_obj_convert.py
new file mode 100755
index ..dd27f4792131
--- /dev/null
+++ b/tools/zynqmp_pm_cfg_obj_convert.py
@@ -0,0 +1,301 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Luca Ceresoli 
+
+import sys
+import re
+import struct
+import logging
+import argparse
+
+parser = argparse.ArgumentParser(
+description='Convert a PMU configuration object from C source to a binary 
blob.')
+parser.add_argument('-D', '--debug', action="store_true")
+parser.add_argument(
+"in_file", metavar='INPUT_FILE',
+help='PMU configuration object (C source as produced by Xilinx XSDK)')
+parser.add_argument(
+"out_file", metavar='OUTPUT_FILE',
+help='PMU configuration object binary blob')
+args = parser.parse_args()
+
+logging.basicConfig(format='%(levelname)s:%(message)s',
+level=(logging.DEBUG if args.debug else logging.WARNING))
+
+pm_define = {
+'PM_CAP_ACCESS'   : 0x1,
+'PM_CAP_CONTEXT'  : 0x2,
+'PM_CAP_WAKEUP'   : 0x4,
+
+'NODE_UNKNOWN':  0,
+'NODE_APU':  1,
+'NODE_APU_0'  :  2,
+'NODE_APU_1'  :  3,
+'NODE_APU_2'  :  4,
+'NODE_APU_3'  :  5,
+'NODE_RPU':  6,
+'NODE_RPU_0'  :  7,
+'NODE_RPU_1'  :  8,
+'NODE_PLD':  9,
+'NODE_FPD': 10,
+'NODE_OCM_BANK_0' : 11,
+'NODE_OCM_BANK_1' : 12,
+'NODE_OCM_BANK_2' : 13,
+'NODE_OCM_BANK_3' : 14,
+'NODE_TCM_0_A': 15,
+'NODE_TCM_0_B': 16,
+'NODE_TCM_1_A': 17,
+'NODE_TCM_1_B': 18,
+'NODE_L2' : 19,
+'NODE_GPU_PP_0'   : 20,
+'NODE_GPU_PP_1'   : 21,
+'NODE_USB_0'  : 22,
+'NODE_USB_1'  : 23,
+'NODE_TTC_0'  : 24,
+'NODE_TTC_1'  : 25,
+'NODE_TTC_2'  : 26,
+'NODE_TTC_3'  : 27,
+'NODE_SATA'   : 28,
+'NODE_ETH_0'  : 29,
+'NODE_ETH_1'  : 30,
+'NODE_ETH_2'  : 31,
+'NODE_ETH_3'  : 32,
+'NODE_UART_0' : 33,
+'NODE_UART_1' : 34,
+'NODE_SPI_0'  : 35,
+'NODE_SPI_1'  : 36,
+'NODE_I2C_0'  : 37,
+'NODE_I2C_1'  : 38,
+'NODE_SD_0'   : 39,
+'NODE_SD_1'   : 40,
+'NODE_DP' : 41,
+'NODE_GDMA'   : 42,
+'NODE_ADMA'   : 43,
+'NODE_NAND'   : 44,
+'NODE_QSPI'   : 45,
+'NODE_GPIO'   : 46,
+'NODE_CAN_0'  : 47,
+'NODE_CAN_1'  : 48,
+'NODE_EXTERN' : 49,
+'NODE_APLL'   : 50,
+'NODE_VPLL'   : 51,
+'NODE_DPLL'   : 52,
+'NODE_RPLL'   : 53,
+'NODE_IOPLL'  : 54,
+'NODE_DDR': 55,
+'NODE_IPI_APU': 56,
+'NODE_IPI_RPU_0'  : 57,
+'NODE_GPU': 58,
+'NODE_PCIE'   : 59,
+'NODE_PCAP'   : 60,
+'NODE_RTC': 61,
+'NODE_LPD': 62,
+'NODE_VCU': 63,
+'NODE_IPI_RPU_1'  : 64,
+'NODE_IPI_PL_0'   : 65,
+'NODE_IPI_PL_1'   : 66,
+'NODE_IPI_PL_2'   : 67,
+'NODE_IPI_PL_3'   : 68,
+'NODE_PL' : 69,
+'NODE_ID_MA'  : 70,
+
+'XILPM_RESET_PCIE_CFG' : 1000,
+'XILPM_RESET_PCIE_BRIDGE'  : 1001,
+'XILPM_RESET_PCIE_CTRL': 1002,
+'XILPM_RESET_DP'   : 1003,
+'XILPM_RESET_SWDT_CRF' : 1004,
+'XILPM_RESET_AFI_FM5'  : 1005,
+'XILPM_RESET_AFI_FM4'  : 1006,
+'XILPM_RESET_AFI_FM3'  : 1007,
+'XILPM_RESET_AFI_FM2'  : 1008,
+'XILPM_RESET_AFI_FM1'  : 1009,
+'XILPM_RESET_AFI_FM0'  : 1010,
+'XILPM_RESET_GDMA' : 1011,
+'XILPM_RESET_GPU_PP1'  : 1012,
+'XILPM_RESET_GPU_PP0'  : 1013,
+'XILPM_RESET_GPU'  : 1014,
+'XILPM_RESET_GT'   : 1015,
+'XILPM_RESET_SATA' : 1016,
+'XILPM_RESET_ACPU3_PWRON'  : 1017,
+'XILPM_RESET_ACPU2_PWRON'  : 1018,
+

[U-Boot] [PATCH v5 0/2] arm64: zynqmp: pass a PMUFW config object

2019-05-21 Thread Luca Ceresoli

Hi,

here's a minor improvement to 2/2 over v4. 1/1 is unchanged.

This patchset aims at solving a long-standing issue in the ZynqMP users
community: loading a PMU firmware configuration object when U-Boot SPL is
used.

The Platform Management Unit (PMU) needs a configuration object (cfg obj)
to know how to operate the SoC. When using the "Xilinx workflow", the
Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in
cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot
proper.

This is just not implemented in the U-Boot code. The best workaround for
U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj
built-in and self-load it. This approach has some drawbacks: among others,
it forces to use a different PMUFW binary for each hardware and hardware
configuation. It also makes it impossible to change the configuration after
boot.

The first patch fills the gap by allowing U-Boot SPL to load the cfg
obj firmware at runtime. It adds a Kconfig string option to point to
the cfg obj in the form of a binary blob. If the option is non-empty,
code is enabled to link that file in U-Boot SPL and send the
configuration to PMUFW.

Patch 2 adds a tool to convert the cfg obj C file (as produced by the
Xilinx XSDK proprietary tool) in a binary blob suitable for
loading. As suggested by Mike Looijmans it has been implemented as a
Python script to make it easily usable.

These patches are tested on the UltraZed EV board, on u-boot/master and
microblaze/master, using the defconfig I submitted a few days ago [1].

Future work on this topic include moving the PMU IPC code to a mailbox
uclass driver and adding a command in U-Boot proper to load a config object
blob (e.g. from a file based on a script).

Many thanks to Michal Simek for his many suggestions on how to improve
this work.

[0]
https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch
[1] https://lists.denx.de/pipermail/u-boot/2019-May/368957.html
RFCv1: https://lists.denx.de/pipermail/u-boot/2019-February/360450.html
RFCv2: https://lists.denx.de/pipermail/u-boot/2019-March/362464.html
v3: https://lists.denx.de/pipermail/u-boot/2019-April/365410.html
v4: https://lists.denx.de/pipermail/u-boot/2019-May/369427.html

Luca

Luca Ceresoli (2):
arm64: zynqmp: spl: install a PMU firmware config object at runtime
arm64: zynqmp: add tool to convert PMU config object .c to binary

arch/arm/mach-zynqmp/Kconfig | 18 ++
arch/arm/mach-zynqmp/Makefile | 4 +
arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 +
arch/arm/mach-zynqmp/pmu_ipc.c| 112 +++
board/xilinx/zynqmp/Makefile | 5 +
board/xilinx/zynqmp/pm_cfg_obj.S | 17 +
board/xilinx/zynqmp/pm_cfg_obj.h | 9 +
board/xilinx/zynqmp/zynqmp.c | 9 +
tools/zynqmp_pm_cfg_obj_convert.py| 301 ++
9 files changed, 477 insertions(+)
create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c
create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S
create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h
create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py

--
2.21.0

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

[U-Boot] [PATCH v5 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime

2019-05-21 Thread Luca Ceresoli

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

 * 
https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
 * 
https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

  U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
  Loading PMUFW cfg obj (2008 bytes)
  EL Level: EL3
  ...

Signed-off-by: Luca Ceresoli 

---

Changes v4 -> v5: none

Changes v3 -> v4:
 - fix pointer-to-integer typecast warning
 - fix integer-to-pointer typecast warning with proper typecasting and
   add parentheses to avoid ambiguity
 - fix kerneldoc syntax (Michal)
 - remove empty line in Kconfig (Michal)
 - remove #ifdefs around function declaration (Michal)
 - remove unneeded file copy (Michal)
 - move externs to a new .h file (Michal)
 - avoid passing the extra -DZYNQMP_LOAD_PM_CFG_OBJ (using sizeof(), it
   looks a bit of a hack but seems to be working)
 - rename CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE to
   CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE and clarify in menuconfig that it's
   SPL-related

Changes RFC v2 -> v3:
 - don't compile pm_cfg_obj.c from source, load it from a binary file
   (suggested by Michal)
 - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal)

Changes RFC v1 -> RFC v2:
 - Load the cfg_obj in SPL, not U-Boot proper: this required a complete
   reimplementation since we cannot rely on ATF now
 - Update and refine the Kconfig option help
---
 arch/arm/mach-zynqmp/Kconfig  |  18 +++
 arch/arm/mach-zynqmp/Makefile |   4 +
 arch/arm/mach-zynqmp/include/mach/sys_proto.h |   2 +
 arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++
 board/xilinx/zynqmp/Makefile  |   5 +
 board/xilinx/zynqmp/pm_cfg_obj.S  |  17 +++
 board/xilinx/zynqmp/pm_cfg_obj.h  |   9 ++
 board/xilinx/zynqmp/zynqmp.c  |   9 ++
 8 files changed, 176 insertions(+)
 create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c
 create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S
 create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h

diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index 9bb5a5c20201..6cf17eb94e11 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -65,6 +65,24 @@ config PMUFW_INIT_FILE
  Include external PMUFW (Platform Management Unit FirmWare) to
  a Xilinx bootable image (boot.bin).
 
+config ZYNQMP_SPL_PM_CFG_OBJ_FILE
+   string "PMU firmware configuration object to load at runtime by SPL"
+   depends on SPL
+   help
+ Path to a binary PMU firmware configuration object to be linked
+ into U-Boot SPL and loaded at runtime into the PMU firmware.
+
+ The ZynqMP Power Management Unit (PMU) needs a configuration
+ object for most SoC peripherals to work. To have it loaded by
+ U-Boot SPL set here the file name (absolute path or relative to
+ the top source tree) of your configuration, which must be a
+ binary blob. It will be linked in the SPL binary and loaded
+ into the PMU firmware by U-Boot SPL during board
+ initialization.
+
+ Leave this option empty if your PMU firmware has a hard-coded
+ configuration object or you are loading it by any other means.
+
 config ZYNQMP_USB
bool "Configure ZynqMP USB"
 
diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile
index 8a3b0747244a..f3765e45b1b9 100644
--- a/arch/arm/mach-zynqmp/Makefile
+++ b/arch/arm/mach-zynqmp/Makefile
@@ -8,3 +8,7 @@ obj-y   += cpu.o
 obj-$(CONFIG_MP)   += mp.o
 obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o
 obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED)  += psu_spl_init.o
+
+ifneq ($(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE),"")
+obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o
+endif
diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h 
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index 385c8825f2f6..915badc6fbee 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -72,4 +72,6 @@ int chip_id(unsigned char id);
 void tcm_init(u8 mode);
 #endif
 
+void

Re: [U-Boot] [PULL] u-boot-mpc83xx/master (take 2)

On Tue, May 21, 2019 at 08:23:23AM +0200, Mario Six wrote:

> Hi Tom,
> 
> The following changes since commit d494cdb97e18a30214d0414376d4eacdf82224fe:
> 
>   mpc83xx: Add gazerbeam board (2019-05-21 08:03:38 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mpc83xx.git
> 
> for you to fetch changes up to d494cdb97e18a30214d0414376d4eacdf82224fe:
> 
>   mpc83xx: Add gazerbeam board (2019-05-21 08:03:38 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request for mmc sub-system for v2019.07

On Tue, May 21, 2019 at 01:28:19AM +, Peng Fan wrote:

> Hi Tom,
> 
> Please pull mmc-5-20 for v2019.07, this is to avoid break i.MX53 boot.
> 
> Thanks,
> Peng
> 
> The following changes since commit e14d9ca4919e5bc987fc628135104f2b2c91af90:
> 
>   Merge git://git.denx.de/u-boot-x86 (2019-05-19 09:42:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/MrVan/u-boot.git tags/mmc-5-20
> 
> for you to fetch changes up to b6a0427554424a9d6bb563cae4f487f38caf:
> 
>   Revert "mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue" 
> (2019-05-20 11:34:27 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-video

On Mon, May 20, 2019 at 04:39:25PM +0200, Anatolij Gustschin wrote:

> Hi Tom,
> 
> please pull video updates for v2019.07-rc3. cx9020 DM_VIDEO migration and
> splash source patches have been submitted to the list before merge window
> for v2019.07 closed, so I'm including them with some video fixes here.
> 
> Travis CI: https://travis-ci.org/vdsao/u-boot-video/builds/534729949
> 
> Thanks,
> Anatolij
> 
> The following changes since commit 98b3156b0df4b0df9cb3a0bbfc240d0c4edd2638:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-samsung (2019-05-16 
> 07:09:59 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-video.git tags/video-for-2019.07-rc3
> 
> for you to fetch changes up to e63168a9ffae18f807f59925bb5d9d4623633e46:
> 
>   video: Factor out vidconsole_put_string() (2019-05-20 12:00:05 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request: u-boot-sunxi/master

On Mon, May 20, 2019 at 10:45:06PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Summary:
> - H6 WDT reset fix (Clément)
> - H6 SPL_TEXT_BASE fixes (Clément, Jonas)
> - NPI-M1+ emac enablment (Emmanuel)
> 
> The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3:
> 
>   Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to c598c4837d782f6d9481f4be07ae5d679c6df976:
> 
>   sun8i: h3: NanoPi M1 Plus: Add emac configuration (2019-05-20 22:37:35 
> +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH 1/1] efi_loader: comments for structs

2019-05-21 Thread Heinrich Schuchardt

Change comments for struct efi_open_protocol_info_item and
struct efi_handler to Sphinx format.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 8167e6ffcb..43d3a08428 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -160,27 +160,36 @@ extern const efi_guid_t efi_guid_hii_string_protocol;
 extern unsigned int __efi_runtime_start, __efi_runtime_stop;
 extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;

-/*
+/**
+ * struct efi_open_protocol_info_item - open protocol info item
+ *
  * When a protocol is opened a open protocol info entry is created.
  * These are maintained in a list.
+ *
+ * @link:  link to the list of open protocol info entries of a protocol
+ * @info:  information about the opening of a protocol
  */
 struct efi_open_protocol_info_item {
-   /* Link to the list of open protocol info entries of a protocol */
struct list_head link;
struct efi_open_protocol_info_entry info;
 };

-/*
+/**
+ * struct efi_handler - single protocol interface of a handle
+ *
  * When the UEFI payload wants to open a protocol on an object to get its
  * interface (usually a struct with callback functions), this struct maps the
  * protocol GUID to the respective protocol interface
+ *
+ * @link:  link to the list of protocols of a handle
+ * @guid:  GUID of the protocol
+ * @protocol_interface:protocol interface
+ * @open_infos link to the list of open protocol info items
  */
 struct efi_handler {
-   /* Link to the list of protocols of a handle */
struct list_head link;
const efi_guid_t *guid;
void *protocol_interface;
-   /* Link to the list of open protocol info items */
struct list_head open_infos;
 };

--
2.20.1

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

[U-Boot] [PATCH 1/1] efi_loader: correct device path check

2019-05-21 Thread Heinrich Schuchardt

Since commit 226cddbe32f0 ("efi_loader: check device path in
InstallMultipleProtocolInterfaces") iPXE fails to access the network.

LocateDevicePath() returns EFI_SUCCESS even if a shorter path is found as a
partial match. It returns the remaining path. So to be sure that we found a
complete match we need to check that the remaining path refers to an end
node.

Provide debug output if a device path has already been installed.

Fixes: 226cddbe32f0 ("efi_loader: check device path in
   InstallMultipleProtocolInterfaces")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 971bd5ffa3..54fff85e64 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2360,7 +2360,10 @@ efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces

r = EFI_CALL(efi_locate_device_path(protocol, ,
_handle));
-   if (r == EFI_SUCCESS) {
+   if (r == EFI_SUCCESS &&
+   dp->type == DEVICE_PATH_TYPE_END) {
+   EFI_PRINT("Path %pD already installed\n",
+ protocol_interface);
r = EFI_ALREADY_STARTED;
break;
}
--
2.20.1

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

[U-Boot] [PATCH v2 1/1] efi_loader: implement SetTime

2019-05-21 Thread Heinrich Schuchardt

Implement the SetTime() runtime service.

Extend the real time clock selftest to check setting the clock.

Signed-off-by: Heinrich Schuchardt 
---
v2
fix reference to unknown parameter for CONFIG_DM_RTC=n
---
 lib/efi_loader/efi_runtime.c| 73 -
 lib/efi_selftest/efi_selftest_rtc.c | 56 ++
 2 files changed, 120 insertions(+), 9 deletions(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 636dfdab39..5f40659ee7 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -214,7 +214,57 @@ out:
 #endif
 }

+/**
+ * efi_set_time_boottime() - set current time
+ *
+ * This function implements the SetTime() runtime service before
+ * SetVirtualAddressMap() is called.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification
+ * for details.
+ *
+ * @time:  pointer to structure to with current time
+ * Returns:status code
+ */
+static efi_status_t EFIAPI efi_set_time_boottime(struct efi_time *time)
+{
+#ifdef CONFIG_DM_RTC
+   efi_status_t ret = EFI_SUCCESS;
+   struct rtc_time tm;
+   struct udevice *dev;
+
+   EFI_ENTRY("%p", time);
+
+   if (!time) {
+   ret = EFI_INVALID_PARAMETER;
+   goto out;
+   }
+
+   if (uclass_get_device(UCLASS_RTC, 0, )) {
+   ret = EFI_UNSUPPORTED;
+   goto out;
+   }

+   memset(, 0, sizeof(tm));
+   tm.tm_year = time->year;
+   tm.tm_mon = time->month;
+   tm.tm_mday = time->day;
+   tm.tm_hour = time->hour;
+   tm.tm_min = time->minute;
+   tm.tm_sec = time->second;
+   tm.tm_isdst = time->daylight == EFI_TIME_IN_DAYLIGHT;
+   /* Calculate day of week */
+   rtc_calc_weekday();
+
+   if (dm_rtc_set(dev, ))
+   ret = EFI_DEVICE_ERROR;
+out:
+   return EFI_EXIT(ret);
+#else
+   EFI_ENTRY("%p", time);
+   return EFI_EXIT(EFI_UNSUPPORTED);
+#endif
+}
 /**
  * efi_reset_system() - reset system
  *
@@ -271,6 +321,24 @@ efi_status_t __weak __efi_runtime EFIAPI efi_get_time(
return EFI_DEVICE_ERROR;
 }

+/**
+ * efi_set_time() - set current time
+ *
+ * This function implements the SetTime runtime service after
+ * SetVirtualAddressMap() is called. As the U-Boot driver are not available
+ * anymore only an error code is returned.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification
+ * for details.
+ *
+ * @time:  pointer to structure to with current time
+ * Returns:status code
+ */
+efi_status_t __weak __efi_runtime EFIAPI efi_set_time(struct efi_time *time)
+{
+   return EFI_UNSUPPORTED;
+}
+
 struct efi_runtime_detach_list_struct {
void *ptr;
void *patchto;
@@ -289,6 +357,9 @@ static const struct efi_runtime_detach_list_struct 
efi_runtime_detach_list[] = {
/* RTC accessors are gone */
.ptr = _runtime_services.get_time,
.patchto = _get_time,
+   }, {
+   .ptr = _runtime_services.set_time,
+   .patchto = _set_time,
}, {
/* Clean up system table */
.ptr = _in,
@@ -697,7 +768,7 @@ struct efi_runtime_services __efi_runtime_data 
efi_runtime_services = {
.headersize = sizeof(struct efi_runtime_services),
},
.get_time = _get_time_boottime,
-   .set_time = (void *)_device_error,
+   .set_time = _set_time_boottime,
.get_wakeup_time = (void *)_unimplemented,
.set_wakeup_time = (void *)_unimplemented,
.set_virtual_address_map = _set_virtual_address_map,
diff --git a/lib/efi_selftest/efi_selftest_rtc.c 
b/lib/efi_selftest/efi_selftest_rtc.c
index 8d440dc0b3..9eb29add3b 100644
--- a/lib/efi_selftest/efi_selftest_rtc.c
+++ b/lib/efi_selftest/efi_selftest_rtc.c
@@ -10,6 +10,7 @@
 #include 

 #define EFI_ST_NO_RTC "Could not read real time clock\n"
+#define EFI_ST_NO_RTC_SET "Could not set real time clock\n"

 static struct efi_runtime_services *runtime;

@@ -30,17 +31,26 @@ static int setup(const efi_handle_t handle,
 /*
  * Execute unit test.
  *
- * Display current time.
+ * Read and display current time.
+ * Set a new value and read it back.
+ * Set the real time clock back the current time.
  *
  * @return:EFI_ST_SUCCESS for success
  */
 static int execute(void)
 {
efi_status_t ret;
-   struct efi_time tm;
+   struct efi_time tm, tm_old, tm_new = {
+   .year = 2017,
+   .month = 5,
+   .day = 19,
+   .hour = 13,
+   .minute = 47,
+   .second = 53,
+   };

/* Display current time */
-   ret = runtime->get_time(, NULL);
+   ret = runtime->get_time(_old, NULL);
if (ret != EFI_SUCCESS) {
 #ifdef CONFIG_CMD_DATE
efi_st_error(EFI_ST_NO_RTC);
@@ -49,11 +59,41 @@ static int execute(void)

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

2019-05-21 Thread Adam Ford

On Tue, May 21, 2019 at 10:09 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(). Since the
> README recommends calling preloader_console_init() from spl_board_init(),
> we keep it as-it-is.

The README also states preloader_console_init() can get called from
board_init_f().  Doing this enables for debugging of board_init_r

>
> Tested using MMC/SD boot on OMAP-L138 LCDK board.
>
> Signed-off-by: Sekhar Nori 
> ---
>  arch/arm/mach-davinci/spl.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
> index 103639e34757..117b5ee836f8 100644
> --- a/arch/arm/mach-davinci/spl.c
> +++ b/arch/arm/mach-davinci/spl.c
> @@ -33,10 +33,14 @@ void putc(char c)
>
>  void spl_board_init(void)
>  {
> -   arch_cpu_init();
> preloader_console_init();
>  }
>
> +void board_init_f(ulong dummy)
> +{
> +   arch_cpu_init();

What about a reference to board_early_init_f()?
Looking at other boards, it appears that we should call that here.
Both the LCDK and da850 evm have the function enabled to configure the
DSP.

adam
> +}
> +
>  u32 spl_boot_device(void)
>  {
> switch (davinci_syscfg_regs->bootcfg) {
> --
> 2.16.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1 4/5] ARM: imx: Convert mccmon6 to use fitImage instead of uImage+DTB

This commit enabled support for fitImage on mccmon6 when we
switch to DT/DTS (including falcon mode).

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/mccmon6/spl.c  |  7 ++
 configs/mccmon6_nor_defconfig |  8 +-
 configs/mccmon6_sd_defconfig  |  6 -
 include/configs/mccmon6.h | 57 +--
 4 files changed, 42 insertions(+), 36 deletions(-)

diff --git a/board/liebherr/mccmon6/spl.c b/board/liebherr/mccmon6/spl.c
index da28a22f84..e1aa23da3e 100644
--- a/board/liebherr/mccmon6/spl.c
+++ b/board/liebherr/mccmon6/spl.c
@@ -332,6 +332,13 @@ void board_boot_order(u32 *spl_boot_list)
}
 }
 
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_SPL_OS_BOOT
 int spl_start_uboot(void)
 {
diff --git a/configs/mccmon6_nor_defconfig b/configs/mccmon6_nor_defconfig
index 770ef9bed6..62e957c0cf 100644
--- a/configs/mccmon6_nor_defconfig
+++ b/configs/mccmon6_nor_defconfig
@@ -10,6 +10,7 @@ CONFIG_SPL=y
 # CONFIG_CMD_BMODE is not set
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/liebherr/mccmon6/mon6_imximage_nor.cfg"
 # CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_BOUNCE_BUFFER=y
@@ -17,6 +18,11 @@ CONFIG_SPL_TEXT_BASE=0x00908000
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_NOR_SUPPORT=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_SYS_OS_BASE=0x818
+CONFIG_CMD_SPL=y
+CONFIG_CMD_SPL_NOR_OFS=0x0960
+CONFIG_CMD_SPL_WRITE_SIZE=0x2
 CONFIG_CMD_CLK=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -29,7 +35,7 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nor0=800.nor"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nor:32m@0x0(mccmon6-image.nor),256k@0x4(u-boot-env.nor),1m@0x8(u-boot.nor),8m@0x18(kernel.nor),8m@0x98(swupdate-kernel.nor),8m@0x118(swupdate-rootfs.nor),128k@0x198(kernel-dtb.nor),128k@0x19C(swupdate-kernel-dtb.nor)"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nor:32m@0x0(mccmon6-image.nor),256k@0x4(u-boot-env.nor),1m@0x8(u-boot.nor),8m@0x18(kernel.nor),8m@0x98(swupdate-kernel.nor),8m@0x118(swupdate-rootfs.nor)"
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-mccmon6"
 CONFIG_ENV_IS_IN_FLASH=y
diff --git a/configs/mccmon6_sd_defconfig b/configs/mccmon6_sd_defconfig
index 9a11b59738..c72580e362 100644
--- a/configs/mccmon6_sd_defconfig
+++ b/configs/mccmon6_sd_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL=y
 # CONFIG_CMD_BMODE is not set
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/liebherr/mccmon6/mon6_imximage_sd.cfg"
 # CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_BOUNCE_BUFFER=y
@@ -18,6 +19,9 @@ CONFIG_SPL_TEXT_BASE=0x00908000
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_NOR_SUPPORT=y
+CONFIG_CMD_SPL=y
+CONFIG_CMD_SPL_NOR_OFS=0x0960
+CONFIG_CMD_SPL_WRITE_SIZE=0x2
 CONFIG_CMD_CLK=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -30,7 +34,7 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nor0=800.nor"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nor:32m@0x0(mccmon6-image.nor),256k@0x4(u-boot-env.nor),1m@0x8(u-boot.nor),8m@0x18(kernel.nor),8m@0x98(swupdate-kernel.nor),8m@0x118(swupdate-rootfs.nor),128k@0x198(kernel-dtb.nor),128k@0x19C(swupdate-kernel-dtb.nor)"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nor:32m@0x0(mccmon6-image.nor),256k@0x4(u-boot-env.nor),1m@0x8(u-boot.nor),8m@0x18(kernel.nor),8m@0x98(swupdate-kernel.nor),8m@0x118(swupdate-rootfs.nor)"
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-mccmon6"
 CONFIG_ENV_IS_IN_FLASH=y
diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h
index b25aacbf41..c685de6551 100644
--- a/include/configs/mccmon6.h
+++ b/include/configs/mccmon6.h
@@ -14,10 +14,6 @@
 
 #define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE
 #define CONFIG_SYS_UBOOT_BASE (CONFIG_SYS_FLASH_BASE + 0x8)
-#define CONFIG_SPL_OS_BOOT
-#define CONFIG_SYS_OS_BASE (CONFIG_SYS_FLASH_BASE + 0x18)
-#define CONFIG_SYS_FDT_BASE (CONFIG_SYS_FLASH_BASE + 0x198)
-#define CONFIG_SYS_FDT_SIZE (48 * SZ_1K)
 #define CONFIG_SYS_SPL_ARGS_ADDR   0x1800
 
 /*
@@ -28,8 +24,7 @@
 #define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR (0x800)
 #define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS (0x80)
 #define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR (0x1000)
-#define CONFIG_SPL_FS_LOAD_KERNEL_NAME "uImage"
-#define CONFIG_SPL_FS_LOAD_ARGS_NAME "imx6q-mccmon.dtb"
+#define CONFIG_SPL_FS_LOAD_KERNEL_NAME "fitImage"
 
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (10 * SZ_1M)
@@ -61,14 +56,13 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"console=ttymxc0,115200 quiet\0" \
-   "fdtfile=imx6q-mccmon6.dtb\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \

[U-Boot] [PATCH v1 2/5] ARM: imx: Decouple mccmon6's SPL and u-boot proper code

The mccmon6 has been used a "mixed" approach between SPL and
U-Boot proper sources.

This commit decoupes SPL and u-boot proper, which allows clear
distinction between those two code bases and facilitates
conversion to DM/DTS on this particular board.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/mccmon6/Makefile  |   7 +-
 board/liebherr/mccmon6/mccmon6.c | 285 ---
 board/liebherr/mccmon6/spl.c | 274 -
 3 files changed, 276 insertions(+), 290 deletions(-)

diff --git a/board/liebherr/mccmon6/Makefile b/board/liebherr/mccmon6/Makefile
index ead6750ebf..3c9786c6b7 100644
--- a/board/liebherr/mccmon6/Makefile
+++ b/board/liebherr/mccmon6/Makefile
@@ -2,5 +2,8 @@
 #
 # (C) Copyright 2016-2017
 # Lukasz Majewski, DENX Software Engineering, lu...@denx.de
-
-obj-y  := mccmon6.o spl.o
+ifdef CONFIG_SPL_BUILD
+obj-y  := spl.o
+else
+obj-y  := mccmon6.o
+endif
diff --git a/board/liebherr/mccmon6/mccmon6.c b/board/liebherr/mccmon6/mccmon6.c
index 497095572e..33b28aca11 100644
--- a/board/liebherr/mccmon6/mccmon6.c
+++ b/board/liebherr/mccmon6/mccmon6.c
@@ -8,37 +8,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
-   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP |   \
-   PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
-   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define WEIM_NOR_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |  \
-   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
-   PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST)
-
-#define USDHC2_CD_GPIO IMX_GPIO_NR(1, 4)
-#define NOR_WP IMX_GPIO_NR(1, 1)
-#define DISPLAY_EN IMX_GPIO_NR(1, 2)
-
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -46,198 +20,11 @@ int dram_init(void)
return 0;
 }
 
-static iomux_v3_cfg_t const uart1_pads[] = {
-   IOMUX_PADS(PAD_CSI0_DAT10__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
-   IOMUX_PADS(PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
-};
-
-static iomux_v3_cfg_t const usdhc2_pads[] = {
-   IOMUX_PADS(PAD_SD2_CLK__SD2_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD2_CMD__SD2_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   /* Carrier MicroSD Card Detect */
-   IOMUX_PADS(PAD_GPIO_4__GPIO1_IO04  | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
-static iomux_v3_cfg_t const usdhc3_pads[] = {
-   IOMUX_PADS(PAD_SD3_CLK__SD3_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_CMD__SD3_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_DAT7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-   IOMUX_PADS(PAD_SD3_RST__SD3_RESET  | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
-};
-
-static void setup_iomux_uart(void)
-{
-   SETUP_IOMUX_PADS(uart1_pads);
-}
-
-static struct fsl_esdhc_cfg usdhc_cfg[2] = {
-   {USDHC3_BASE_ADDR},
-   {USDHC2_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
-   int ret = 0;
-
-   switch (cfg->esdhc_base) {
-   case USDHC2_BASE_ADDR:
-   ret = !gpio_get_value(USDHC2_CD_GPIO);
-   break;
-   case USDHC3_BASE_ADDR:
-   /*
-* eMMC don't have card detect pin - since it is soldered to the
-* PCB board
-*/
-   ret = 1;
-   break;
-   }
-   return ret;
-}
-
-int board_mmc_init(bd_t *bis)
-{
-   int ret;
-   u32 index = 0;
-
-   /*
-* MMC MAP
-* (U-Boot device node)(Physical Port)
-* mmc0Soldered on board eMMC device
-* mmc1MicroSD card
-*/
-   for (index = 0; index < CONFIG_SYS_FSL_USDHC_NUM; ++index) {
-

[U-Boot] [PATCH v1 5/5] mccmon6: defconfig: nor: Enable usage of _TINY_ drivers in SPL

After this change the SPL size has been reduced from 38K to 34K.

Signed-off-by: Lukasz Majewski 

---

 configs/mccmon6_nor_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/mccmon6_nor_defconfig b/configs/mccmon6_nor_defconfig
index 62e957c0cf..ffb1025a13 100644
--- a/configs/mccmon6_nor_defconfig
+++ b/configs/mccmon6_nor_defconfig
@@ -16,6 +16,7 @@ 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/liebherr/mccmon6/mon6_imximage_nor.cf
 CONFIG_BOUNCE_BUFFER=y
 CONFIG_SPL_TEXT_BASE=0x00908000
 CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
@@ -81,3 +82,5 @@ CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_DM_THERMAL=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_SPL_TINY_MEMSET=y
-- 
2.11.0

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

[U-Boot] [PATCH v1 3/5] spl: nor: Provide falcon boot support for NOR memories

This commit adds falcon boot support (by also copying args necessary for
booting) to the SPL NOR memory driver.

After this change it is possible to use the falcon boot in the same way
as on NAND memories. The necessary configs (i.e. CONFIG_CMD_SPL_NOR_OFS)
are now defined in Kconfig.

Signed-off-by: Lukasz Majewski 
---

 common/spl/spl_nor.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index 969e319de0..de58c43101 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -48,6 +48,11 @@ static int spl_nor_load_image(struct spl_image_info 
*spl_image,
  CONFIG_SYS_OS_BASE,
  (void *)header);
 
+#if defined CONFIG_SYS_SPL_ARGS_ADDR && defined CONFIG_CMD_SPL_NOR_OFS
+   memcpy((void *)CONFIG_SYS_SPL_ARGS_ADDR,
+  (void *)CONFIG_CMD_SPL_NOR_OFS,
+  CONFIG_CMD_SPL_WRITE_SIZE);
+#endif
return ret;
}
 #endif
-- 
2.11.0

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

[U-Boot] [PATCH v1 1/5] ARM: imx: Covnert mccmon6 to use DM/DTS in the u-boot proper

This commit converts mccmon6's u-boot proper (in a single commit to avoid
build breaks) to use solely DM/DTS.

The DTS description of the mccmon6 has been ported from Linux kernel
(v4.20, SHA1: 8fe28cb58bcb235034b64cbbb7550a8a43fd88be)

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/imx6q-mccmon6.dts   | 382 +++
 arch/arm/mach-imx/mx6/Kconfig|   7 +
 board/liebherr/mccmon6/mccmon6.c | 161 -
 configs/mccmon6_nor_defconfig|  31 +++-
 configs/mccmon6_sd_defconfig |  29 ++-
 include/configs/mccmon6.h|  13 --
 7 files changed, 444 insertions(+), 180 deletions(-)
 create mode 100644 arch/arm/dts/imx6q-mccmon6.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 83058c4452..0a5b13c35d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -548,6 +548,7 @@ dtb-$(CONFIG_MX6QDL) += \
imx6q-icore.dtb \
imx6q-icore-mipi.dtb \
imx6q-icore-rqs.dtb \
+   imx6q-mccmon6.dtb \
imx6q-sabreauto.dtb \
imx6q-sabresd.dtb \
imx6dl-sabreauto.dtb \
diff --git a/arch/arm/dts/imx6q-mccmon6.dts b/arch/arm/dts/imx6q-mccmon6.dts
new file mode 100644
index 00..27cde56115
--- /dev/null
+++ b/arch/arm/dts/imx6q-mccmon6.dts
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+
+/dts-v1/;
+#include 
+#include "imx6q.dtsi"
+
+/ {
+   model = "Liebherr Nenzig (LWN) iMX6Q";
+   compatible = "lwn,imx6-mccmon6", "fsl,imx6";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory@1000 {
+   reg = <0x1000 0x8000>;
+   };
+};
+
+ {
+   cs-gpios = < 24 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ecspi3 _ecspi3_cs _ecspi3_flwp>;
+   spi-max-frequency = <2500>;
+   status = "okay";
+
+   s25sl032p: flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <4000>;
+   reg = <0>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet>;
+   phy-mode = "rgmii";
+   phy-reset-gpios = < 27 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <10>;
+   phy-reset-post-delay = <1>;
+   /* KSZ9031 PHY SKEW setup - old values * 60 ps */
+   rxc-skew-ps = <1860>;
+   txc-skew-ps = <1860>;
+   txen-skew-ps = <900>;
+   rxdv-skew-ps = <900>;
+   rxd0-skew-ps = <180>;
+   rxd1-skew-ps = <180>;
+   rxd2-skew-ps = <180>;
+   rxd3-skew-ps = <180>;
+   txd0-skew-ps = <120>;
+   txd1-skew-ps = <300>;
+   txd2-skew-ps = <0>;
+   txd3-skew-ps = <120>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+
+   pfuze100: pmic@8 {
+   compatible = "fsl,pfuze100";
+   reg = <0x08>;
+
+   regulators {
+   sw1a_reg: sw1ab {
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1875000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   sw1c_reg: sw1c {
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1875000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   sw2_reg: sw2 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <395>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3a_reg: sw3a {
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1975000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3b_reg: sw3b {
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1975000>;
+

[U-Boot] [PATCH v1 0/5] imx: dm: Update mccmon6 board to only use DM/DTS in U-Boot proper

This patch series converts mccmon6 to use Driver Model and Device
Tree in U-Boot proper.

As the SPL is size constrained (and most notably the device has a strict
boot time requirements) for this board (and uses falcon boot)
- its conversion to DM/DTB will be added with separate patch series.

The SPL/U-Boot proper now uses fitImage instead of legacy uImage and DTB.

Some notable changes:
- Use fitImage to boot Linux kernel (and also use of SPL's Falcon mode
  when running from parallel NOR flash)
- DTS sync with kernel (tag: v4.20)
- Decoupling SPL and U-Boot proper for easy future SPL DM/DTS conversion
- Conversion to DM_MMC, DM_SPI, and BLK (U-Boot proper)

Dependencies (on top of 2019.07-rc2):
"imx: Cleanup i.MX6Q mccmon6 boardconfiguration"
http://patchwork.ozlabs.org/cover/1100398/

then:
http://patchwork.ozlabs.org/patch/1100580/
http://patchwork.ozlabs.org/patch/1100582/
http://patchwork.ozlabs.org/patch/1100584/
http://patchwork.ozlabs.org/patch/1100583/

On top of above patches this series shall be applied.



Lukasz Majewski (5):
  ARM: imx: Covnert mccmon6 to use DM/DTS in the u-boot proper
  ARM: imx: Decouple mccmon6's SPL and u-boot proper code
  spl: nor: Provide falcon boot support for NOR memories
  ARM: imx: Convert mccmon6 to use fitImage instead of uImage+DTB
  mccmon6: defconfig: nor: Enable usage of *_TINY_* drivers in SPL

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/imx6q-mccmon6.dts   | 382 +
 arch/arm/mach-imx/mx6/Kconfig|   7 +
 board/liebherr/mccmon6/Makefile  |   7 +-
 board/liebherr/mccmon6/mccmon6.c | 446 ---
 board/liebherr/mccmon6/spl.c | 279 +++-
 common/spl/spl_nor.c |   5 +
 configs/mccmon6_nor_defconfig|  42 +++-
 configs/mccmon6_sd_defconfig |  35 ++-
 include/configs/mccmon6.h|  70 ++
 10 files changed, 769 insertions(+), 505 deletions(-)
 create mode 100644 arch/arm/dts/imx6q-mccmon6.dts

-- 
2.11.0

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

[U-Boot] [PATCH 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion

2019-05-21 Thread Sekhar Nori

commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
wanted to enable DM_MMC only for U-Boot and not for SPL.

But CONFIG_DM_MMC is defined for SPL build too. Because of this
MMC device was not getting registered for SPL causing MMC/SD
boot breakage.

Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
CONFIG_SPL_DM_MMC is defined.

Signed-off-by: Sekhar Nori 
---
 board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 2c2f885d43e4..fe1bf4410145 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -353,7 +353,7 @@ int misc_init_r(void)
return 0;
 }
 
-#ifndef CONFIG_DM_MMC
+#if !CONFIG_IS_ENABLED(DM_MMC)
 #ifdef CONFIG_MMC_DAVINCI
 static struct davinci_mmc mmc_sd0 = {
.reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
-- 
2.16.2

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

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

2019-05-21 Thread Sekhar Nori

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(). Since the
README recommends calling preloader_console_init() from spl_board_init(),
we keep it as-it-is.

Tested using MMC/SD boot on OMAP-L138 LCDK board.

Signed-off-by: Sekhar Nori 
---
 arch/arm/mach-davinci/spl.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index 103639e34757..117b5ee836f8 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -33,10 +33,14 @@ void putc(char c)
 
 void spl_board_init(void)
 {
-   arch_cpu_init();
preloader_console_init();
 }
 
+void board_init_f(ulong dummy)
+{
+   arch_cpu_init();
+}
+
 u32 spl_boot_device(void)
 {
switch (davinci_syscfg_regs->bootcfg) {
-- 
2.16.2

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

[U-Boot] [PATCH 0/2] ARM: davinci: omapl138_lcdk: fix MMC/SD boot breakage.

2019-05-21 Thread Sekhar Nori

Hi,

Here is a set of patches that fixes MMC/SD boot breakage introduced
after 2018.09 release.

This was tested with MMC/SD boot on OMAP-L138 LCDK. I still need to
do SPI and NAND boot on this board.

Thanks,
Sekhar

Sekhar Nori (2):
  ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model
conversion
  ARM: davinci: SPL: fix BSS initialization

 arch/arm/mach-davinci/spl.c| 6 +-
 board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.16.2

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

Re: [U-Boot] [PATCHv2 11/11] configs: Disable now unbuildable SPI options for boards

Dear Tom

> -Original Message-
> From: Tom Rini 
> Sent: Sunday, May 19, 2019 7:22 PM
> To: u-boot@lists.denx.de
> Cc: Albert ARIBAUD ; Andy Fleming
> ; Ashish Kumar ; Dirk Eibach
> ; Fabio Estevam ; Marek
> Vasut ; Naveen Burmi ; Oleksandr
> Zhadan and Michael Durrant ; Po Liu
> ; Poonam Aggrwal ; Prabhakar
> Kushwaha ; Priyanka Jain
> ; Qiang Zhao ; Ruchika Gupta
> ; Shengzhou Liu ; Sumit
> Garg ; Timur Tabi ; Valentin
> Longchamp ; Vasily Khoruzhick
> ; Vladimir Zapolskiy ; Xiaobo Xie
> 
> Subject: [PATCHv2 11/11] configs: Disable now unbuildable SPI options for
> boards
> 
> Now that various SPI related options depend on CONFIG_DEPRECATED, in
> order for platforms to build out of the box they need to disable various
> other options.
> 
> Cc: Albert ARIBAUD 
> Cc: Andy Fleming 
> Cc: Ashish Kumar 
> Cc: Dirk Eibach 
> Cc: Fabio Estevam 
> Cc: Marek Vasut 
> Cc: Naveen Burmi 
> Cc: Oleksandr Zhadan and Michael Durrant
> 
> Cc: Po Liu 
> Cc: Poonam Aggrwal 
> Cc: Prabhakar Kushwaha 
> Cc: Priyanka Jain 
> Cc: Qiang Zhao 
> Cc: Ruchika Gupta 
> Cc: Shengzhou Liu 
> Cc: Sumit Garg 
> Cc: Timur Tabi 
> Cc: Valentin Longchamp 
> Cc: Vasily Khoruzhick 
> Cc: Vladimir Zapolskiy 
> Cc: Xiaobo Xie 
> Signed-off-by: Tom Rini 
> ---
> As I'm sadly sure some of you won't have seen all of this before, in
> short, SPI drivers are to have been converted to DM by this past
> release.  There have been build time warnings for a while, and at
> various times I and others have tried (but, failed) to get ahold of all
> board maintainers that use drivers that need to be updated to current
> best practices.  The whole of this series will be in patchwork
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwo
> rk.ozlabs.org%2Fproject%2Fuboot%2Flist%2Fdata=02%7C01%7Cprabhak
> ar.kushwaha%40nxp.com%7Cb60fd2f4267244e97b5508d6dc613edc%7C686ea1
> d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636938707633946758sdat
> a=yrbcetwG2UoSz4ktTHjM4KJVtuRWb%2B7Mw2ZVLKtbTYQ%3Dreserved
> =0) shortly after you get
> this email.  If you're trying to update the drivers but need help or
> more time, please reach out.  If you're also no longer interested in
> having your board in U-Boot, again, please reach out.  Thanks!

Below patch-set is under review for conversion of NXP's eSPI driver on DM model
http://patchwork.ozlabs.org/project/uboot/list/?series=104110

Chuanhua Han has migrated T2080QDS as reference. Once this patch-set is 
accepted all other mpc85xx/mpc86xx platforms can follow. 

Nutshell,  We need more time. 

@Jagan:  Thanks for being kind to review this patch series.  Will it be 
possible for you to reply submitter's last query.  


Thanks,
--pk


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

Re: [U-Boot] U-Boot PXA support

On Tue, May 21, 2019 at 04:34:19PM +0200, Marek Vasut wrote:
> On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> > On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
> >> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> >>> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
>  It's slightly off-topic but I wonder whether this ongoing
>  deprecation
>  of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really
>  simplifies
>  anything at all.
>  There are tons of devices that are still working good and there
>  are
>  even ARMv5-based MCUs that are still produced (such as CH561
>  manufactured by WCH).
> >>>
> >>> Please note that as of today Marvell is also still producing them
> >>> PXAs
> >>> which are not to go end-of-life before later next year I believe.
> >>>
>  IMHO it makes sense to drop only the XScale-specific tuning first
>  and
>  to treat PXA (and similar CPUs) as a more generic armv5te. I
>  wonder
>  what to do when GCC drops ARMv5 completely...
> >>>
> >>> I believe it was only an issue with early gcc 8 but does work just
> >>> fine
> >>> again with later 8.2 or 8.3 versions.
> >>>
> >>> However, what is more concerning to me is that in today's
> >>> convoluted
> >>> moloch known as U-Boot there may simply not be any space any more
> >>> for
> >>> something truly embedded but somewhat limited like PXA based
> >>> hardware.
> >>
> >> If we ignore the PXA25x/26x, the PXA27x has loads of SRAM for U-Boot
> >> SPL
> >> and then can load U-Boot proper into DRAM. What's the problem ?
> > 
> > At least on the Colibri PXA270 it is more about NOR flash storage. The
> > factory configuration block gets stored at an offset of 0x4 which
> > leaves only 256 KB for the boot loader. However, of course one could
> > migrate it all over to using SPL and store U-Boot proper after the
> > factory configuration block. But to change all that for our very oldest
> > module which is going end-of-live the next year may not make too much
> > sense.
> 
> True
> 
> > So the real issue with U-Boot for such platforms is basically that the
> > complexity and footprint increased steadily leaving them behind and
> > eventually just removing them may be the logical conclusion. After all
> > we are talking about just a boot loader which is used to boot the
> > "real" system and good is. However, if even one percent of today's U-
> > Boot is actually used for booting it is probably already quite a lot
> > (;-p).
> 
> The size growth is a problem, even for todays' systems, and it
> contradicts this "universal" part in U-Boot . That's a real issue which
> should be addressed , and this fevered push for DM/DT conversion does
> not help at all.

As I thought I had said before, I think it's really interesting how
Zephyr takes a DT and spits out a lot of static information.  Taking
that idea far enough for platforms where no, we don't need any real
run-time detection of this-or-that could be pretty interesting and
result in some real space reduction.

-- 
Tom


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

Re: [U-Boot] [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to U-boot (tag: 5.0-rc3)

Hi Simon,

> Hi Lukasz,
> 
> On Sun, 19 May 2019 at 15:03, Lukasz Majewski  wrote:
> >
> > Hi Simon,
> >  
> > > Hi Lukasz,
> > >
> > > On Sat, 18 May 2019 at 15:28, Lukasz Majewski 
> > > wrote:  
> > > >
> > > > Hi Simon,
> > > >
> > > > This is not the newest patch set version of CCF (v3 vs. v4),
> > > > but the comments/issues apply.
> > > >  
> > > > > Hi Lukasz,
> > > > >
> > > > > On Thu, 25 Apr 2019 at 04:30, Lukasz Majewski 
> > > > > wrote:  
> > > > > >
> > > > > > This patch series brings the files from Linux kernel to
> > > > > > provide clocks support as it is used on the Linux kernel
> > > > > > with common clock framework [CCF] setup.
> > > > > >
> > > > > > This series also fixes several problems with current clocks
> > > > > > and provides sandbox tests for functions addded to
> > > > > > clk-uclass.c file.
> > > > > >
> > > > > > Design decisions/issues:
> > > > > > =
> > > > > >
> > > > > > - U-boot's DM for clk differs from Linux CCF. The most
> > > > > > notably difference is the lack of support for hierarchical
> > > > > > clocks and "clock as a manager driver" (single clock DTS
> > > > > > node acts as a starting point for all other clocks).
> > > > > >
> > > > > > - The clk_get_rate() now caches the previously read data (no
> > > > > > need for recursive access.
> > > > > >
> > > > > > - On purpose the "manager" clk driver (clk-imx6q.c) is not
> > > > > > using large table to store pointers to clocks - e.g.
> > > > > > clk[IMX6QDL_CLK_USDHC2_SEL] =  Instead we use udevice's
> > > > > > linked list for the same class (UCLASS_CLK). The rationale -
> > > > > > when porting the code as is from Linux, one would need
> > > > > > ~1KiB of RAM to store it. This is way too much if we do
> > > > > > plan to use this driver in SPL.
> > > > > >
> > > > > > - The "central" structure of this patch series is struct
> > > > > > udevice and its driver_data field contains the struct clk
> > > > > > pointer (to the originally created one).
> > > > > >
> > > > > > - Up till now U-boot's driver model's CLK operates on
> > > > > > udevice (main access to clock is by udevice ops)
> > > > > >   In the CCF the access to struct clk (comprising pointer to
> > > > > > *dev) is possible via dev_get_driver_data()
> > > > > >
> > > > > >   Storing back pointer (from udevice to struct clk) as
> > > > > > driver_data is a convention for CCF.  
> > > > >
> > > > > Ick. Why not use uclass-private data to store this, since
> > > > > every UCLASS_CLK device can have a parent.  
> > > >
> > > > The "private_data" field would be also a good place to store the
> > > > back pointer from udevice to struct clk [*]. The problem with
> > > > CCF and udevice's priv pointer is explained just below:
> > > >  
> > > > >  
> > > > > >
> > > > > > - I could use *private_alloc_size to allocate driver's
> > > > > > 'private" structures (dev->priv) for e.g. divider (struct
> > > > > > clk_divider *divider) for IMX6Q clock, but this would
> > > > > > change the original structure of the CCF code.  
> > > >
> > > > The original Linux's CCF code for iMX relies on using kmalloc
> > > > internally:
> > > >
> > > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/imx/clk-gate2.c#L139
> > > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/clk-divider.c#L471
> > > >
> > > > By using driver_data I've avoided the need to make more changes
> > > > to the original Linux code.
> > > >
> > > > I could use udevice's priv with automatic data allocation but
> > > > then the CCF ported code would require more changes and
> > > > considering the (from the outset) need to "fit" this code into
> > > > U-Boot's DM, it drives away from the original Linux code.  
> > >
> > > Is the main change the need to cast driver_data?  
> >
> > The main change would be to remove the per clock device memory
> > allocation code (with exit paths) from the original CCF code.
> >
> > This shall not be so difficult.
> >  
> > > Perhaps that could be
> > > hidden in a helper function/macro, so that in U-Boot it can hide
> > > the use of (struct clk_uc_priv
> > > *)dev_get_uclass_priv(clk->dev))>parent  ?  
> >
> > Helper function would help to some extend as we operate on
> > structures similar to:
> >
> > struct clk_gate2 {
> > struct clk clk;
> > void __iomem*reg;
> > u8  bit_idx;
> > u8  cgr_val;
> > u8  flags;
> > };
> >
> > The helper would return struct clk's address which is the same as
> > struct's clk_gate2 (this is assured by C standard).
> >  
> > >  
> > > >
> > > >  
> > > > > >
> > > > > > The question is if it would be better to use
> > > > > > private_alloc_size (and dev->private) or stay with
> > > > > > driver_data. The former requires some rewritting in CCF
> > > > > > original code (to remove (c)malloc, etc), but comply with
> > > > > > u-boot DM. The latter allows re-using the CCF code as is,
> > > > > > but introduces some

Re: [U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106

Dear Ran

> -Original Message-
> From: Ran Wang 
> Sent: Monday, May 13, 2019 8:49 AM
> To: Albert Aribaud ; Prabhakar Kushwaha
> 
> Cc: York Sun ; u-boot@lists.denx.de; Ran Wang
> 
> Subject: [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-
> 050106
> 
> USB3.0 Receiver needs to enable fixed equalization for each of PHY instances 
> in
> an SOC. This is similar to erratum A-009007, but this one is for LX2160A, and 
> the
> register value is different.
> 
> Signed-off-by: Ran Wang 
> ---

This patch is for adding workaround for errata A-050106. 
But you are modifying erratum_a008997(). 

Please avid hidden changes in a patch. 
I will suggest to generate 2 patches one for A-050106 and other for a008997

-pk

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

Re: [U-Boot] [PATCH v2] cover letter for drivers: net: mc: Report extra memory to linux


> -Original Message-
> From: Meenakshi Aggarwal 
> Sent: Wednesday, May 15, 2019 4:40 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> 
> Cc: Meenakshi Aggarwal 
> Subject: [PATCH v2] cover letter for drivers: net: mc: Report extra memory to
> linux
> 
> changes in different versions:
> 
> v1 : Incorporated review comments in one board, Missed for other boards
> v2 : Incorporated review comments in all boards.
> 

Cover letter is not required for one patch. It is usually done for patch-set. 

Please add revision history as part of your patch after "..."

--pk

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

Re: [U-Boot] [PATCH v2] drivers: net: mc: Report extra memory to Linux


> -Original Message-
> From: Meenakshi Aggarwal 
> Sent: Wednesday, May 15, 2019 4:40 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> 
> Cc: Meenakshi Aggarwal 
> Subject: [PATCH v2] drivers: net: mc: Report extra memory to Linux
> 

V2 but no revision history

> MC firmware need to be aligned to 512M, so minimum 512MB DDR is reserved.
> But MC support to work with 128MB or 256MB DDR memory also, in this case,
> rest of the memory is not usable.
> So reporting this extra memory to Linux through dtb memory fixup.
> 
> Signed-off-by: Meenakshi Aggarwal 
> ---
>  board/freescale/ls1088a/ls1088a.c   | 34
> +---
>  board/freescale/ls2080ardb/ls2080ardb.c | 35
> ++---
>  board/freescale/lx2160a/lx2160a.c   | 34
> +---
>  drivers/net/fsl-mc/mc.c | 10 ++
>  include/fsl-mc/fsl_mc.h |  1 +
>  5 files changed, 105 insertions(+), 9 deletions(-)
> 
> diff --git a/board/freescale/ls1088a/ls1088a.c
> b/board/freescale/ls1088a/ls1088a.c
> index 6d11a13..88c34cb 100644
> --- a/board/freescale/ls1088a/ls1088a.c
> +++ b/board/freescale/ls1088a/ls1088a.c
> @@ -28,6 +28,9 @@
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> +#define TRUE 1
> +#define FALSE0
> +
>  #ifdef CONFIG_TARGET_LS1088AQDS
>  #ifdef CONFIG_TFABOOT
>  struct ifc_regs ifc_cfg_ifc_nor_boot[CONFIG_SYS_FSL_IFC_BANK_COUNT] = {
> @@ -738,11 +741,26 @@ void fsl_fdt_fixup_flash(void *fdt)  int
> ft_board_setup(void *blob, bd_t *bd)  {
>   int i;
> - u64 base[CONFIG_NR_DRAM_BANKS];
> - u64 size[CONFIG_NR_DRAM_BANKS];
> + bool mc_memory_bank = FALSE;
> +
> + u64 *base;
> + u64 *size;
> + u64 mc_memory_base = 0;
> + u64 mc_memory_size = 0;
> + u16 total_memory_banks;
> 
>   ft_cpu_setup(blob, bd);
> 
> + fdt_fixup_mc_ddr(_memory_base, _memory_size);
> +
> + if (mc_memory_base != 0)
> + mc_memory_bank = TRUE;
> +

Again same mistake ☹

--pk

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

Re: [U-Boot] U-Boot PXA support