Re: [PATCHv10 14/15] net/lwip: replace original net commands with lwip

[Simon Goldschmidt]

Am 4. Oktober 2023 10:29:54 MESZ schrieb Maxim Uvarov :
>On Wed, 4 Oct 2023 at 08:12, Simon Glass  wrote:
>
>> Hi Sean,
>>
>> On Tue, 3 Oct 2023 at 11:58, Sean Edmond 
>> wrote:
>> >
>> >
>> > On 2023-09-26 2:41 a.m., Maxim Uvarov wrote:
>> > > Replace original commands: ping, tftp, dhcp and wget.
>> > >
>> > > Signed-off-by: Maxim Uvarov
>> > > ---
>> > >   boot/bootmeth_efi.c | 18 +++---
>> > >   boot/bootmeth_pxe.c | 21 ++-
>> > >   cmd/net.c   | 86
>> +
>> > >   cmd/pxe.c   | 19 +-
>> > >   include/net.h   |  8 +++--
>> > >   include/net/ulwip.h | 64 +
>> > >   6 files changed, 113 insertions(+), 103 deletions(-)
>> > >   create mode 100644 include/net/ulwip.h
>> > >
>> > > diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
>> > > index ae936c8daa..52399d627c 100644
>> > > --- a/boot/bootmeth_efi.c
>> > > +++ b/boot/bootmeth_efi.c
>> > > @@ -20,6 +20,8 @@
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > +#include 
>> > > +#include 
>> > >   #include 
>> > >   #include 
>> > >
>> > > @@ -319,9 +321,7 @@ static int distro_efi_try_bootflow_files(struct
>> udevice *dev,
>> > >
>> > >   static int distro_efi_read_bootflow_net(struct bootflow *bflow)
>> > >   {
>> > > - char file_addr[17], fname[256];
>> > > - char *tftp_argv[] = {"tftp", file_addr, fname, NULL};
>> > > - struct cmd_tbl cmdtp = {};  /* dummy */
>> > > + char fname[256];
>> > >   const char *addr_str, *fdt_addr_str;
>> > >   int ret, arch, size;
>> > >   ulong addr, fdt_addr;
>> > > @@ -368,7 +368,6 @@ static int distro_efi_read_bootflow_net(struct
>> bootflow *bflow)
>> > >   if (!fdt_addr_str)
>> > >   return log_msg_ret("fdt", -EINVAL);
>> > >   fdt_addr = hextoul(fdt_addr_str, NULL);
>> > > - sprintf(file_addr, "%lx", fdt_addr);
>> > >
>> > >   /* We only allow the first prefix with PXE */
>> > >   ret = distro_efi_get_fdt_name(fname, sizeof(fname), 0);
>> > > @@ -379,7 +378,16 @@ static int distro_efi_read_bootflow_net(struct
>> bootflow *bflow)
>> > >   if (!bflow->fdt_fname)
>> > >   return log_msg_ret("fil", -ENOMEM);
>> > >
>> > > - if (!do_tftpb(, 0, 3, tftp_argv)) {
>> > > + ret = ulwip_init();
>> > > + if (ret)
>> > > + return log_msg_ret("ulwip_init", ret);
>> > > +
>> > > + ret = ulwip_tftp(fdt_addr, fname);
>> > > + if (ret)
>> > > + return log_msg_ret("ulwip_tftp", ret);
>> > > +
>> > > + ret = ulwip_loop();
>> > > + if (!ret) {
>> > >   bflow->fdt_size = env_get_hex("filesize", 0);
>> > >   bflow->fdt_addr = fdt_addr;
>> > >   } else {
>> > > diff --git a/boot/bootmeth_pxe.c b/boot/bootmeth_pxe.c
>> > > index 8d489a11aa..fc6aabaa18 100644
>> > > --- a/boot/bootmeth_pxe.c
>> > > +++ b/boot/bootmeth_pxe.c
>> > > @@ -21,6 +21,8 @@
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > +#include 
>> > > +#include 
>> > >   #include 
>> > >
>> > >   static int extlinux_pxe_getfile(struct pxe_context *ctx, const char
>> *file_path,
>> > > @@ -116,18 +118,21 @@ static int extlinux_pxe_read_file(struct udevice
>> *dev, struct bootflow *bflow,
>> > > const char *file_path, ulong addr,
>> > > ulong *sizep)
>> > >   {
>> > > - char *tftp_argv[] = {"tftp", NULL, NULL, NULL};
>> > > - struct pxe_context *ctx = dev_get_priv(dev);
>> > > - char file_addr[17];
>> > >   ulong size;
>> > >   int ret;
>> > >
>> > > - sprintf(file_addr, "%lx", addr);
>> > > - tftp_argv[1] = file_addr;
>> > > - tftp_argv[2] = (void *)file_path;
>> > > + ret = ulwip_init();
>> > > + if (ret)
>> > > + return log_msg_ret("ulwip_init", ret);
>> > > +
>> > > + ret = ulwip_tftp(addr, file_path);
>> > > + if (ret)
>> > > + return log_msg_ret("ulwip_tftp", ret);
>> > > +
>> > > + ret = ulwip_loop();
>> > > + if (ret)
>> > > + return log_msg_ret("ulwip_loop", ret);
>> > >
>> > > - if (do_tftpb(ctx->cmdtp, 0, 3, tftp_argv))
>> > > - return -ENOENT;
>> > >   ret = pxe_get_file_size();
>> > >   if (ret)
>> > >   return log_msg_ret("tftp", ret);
>> > > diff --git a/cmd/net.c b/cmd/net.c
>> > > index d407d8320a..dc5a114309 100644
>> > > --- a/cmd/net.c
>> > > +++ b/cmd/net.c
>> > > @@ -22,6 +22,7 @@
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > +#include 
>> > >
>> > >   static int netboot_common(enum proto_t, struct cmd_tbl *, int, char
>> * const []);
>> > >
>> > > @@ -40,19 +41,9 @@ U_BOOT_CMD(
>> > >   #endif
>> > >
>> > >   #ifdef CONFIG_CMD_TFTPBOOT
>> > > -int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const
>> argv[])
>> > > -{
>> > > - int ret;
>> > > -
>> > > - bootstage_mark_name(BOOTSTAGE_KERNELREAD_START, "tftp_start");
>> > > - 

Re: [PATCHv9 01/15] submodule: add lwIP as git submodule

[Simon Goldschmidt]

On 21.09.2023 09:09, Maxim Uvarov wrote:

On Thu, 21 Sept 2023 at 07:06, Simon Glass  wrote:


Hi Maxim,

On Thu, 14 Sept 2023 at 10:20, Maxim Uvarov 
wrote:


add external lwIP library as a git submodule.


Oh dear...what is the motivation for using a submodule?

Our current stack is nicely integrated into U-Boot. This would make
moving between development branches much more painful.

I would much prefer that we bring in the necessary code, and that you
send a patch every 3 months or so to deal with updates, making sure
there are no code-size regressions.

Regards,
Simon



I would like the project maintainer to make the final decision.

And this time I'm trying to understand how lwIP maintenance works. And how
long does it
take to merge a patch to lwip. For the latest Ilias comment I did a fix to
lwip, which is pending.
https://lists.nongnu.org/archive/html/lwip-devel/2023-09/msg4.html
and created a bug with the same patch:
https://savannah.nongnu.org/bugs/?64697
And it's interesting when patches get merged.

Also there is a long list of not yet accepted patches (86 open items):
https://savannah.nongnu.org/patch/?group=lwip


The list of open bugs and patches has largely to do with users sending
things in the form of "this or that doesn't work for me, here's my poor
quality patch that fixes exactly my issue". We simply don't have the
manpower to check all that for correctness and for not breaking other
use cases. Nearly noone sends a working test case for things. But we're
trying to catch up.


I am afraid that if lwip patch acceptance will be too slow it also can slow
down U-Boot development.


Our response time greatly varies and greatly depends on how the supplier
of a patch works with us. Many bugs in our bug tracker are like "this
doesn't work for me, please do my work and fix it for me". Nearly noone
even sends so much as a working reproduction. We're not a project like
that. We need people needing things fixed to implement the fix.

However, if you're talking about accepting and pushing code that easy
for us to review, clear, and in good form, accepting should normally be
a matter of some days.

Regards,
Simon

Re: [PATCHv8 00/15] net/lwip: add lwip library for the network stack

[Simon Goldschmidt]

On 21.09.2023 18:29, Simon Glass wrote:

Hi,

On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov  wrote:




On Wed, 13 Sept 2023 at 19:14, Tom Rini  wrote:


On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote:

Then if for development you need  to pull he history of lwip, you can do it 
with:
git pull -s subtree lwip  master --allow-unrelated-histories
(but I think nobody will need this.)

New update of the lwip net/lwip/lwip-external dir will be done with:
git pull -s subtree lwip  master --allow-unrelated-histories --squash
Squash commit also has to be git format-patch friendly.

If you are ok with that proposal I will send v9 with the first patch created 
with steps above.


We've gone through this before.  The whole purpose of this is not
having to maintain patches.
Simon, instead of "I had problems in the past", can you elaborate a bit more?

Tom said he is fine with subtrees instead of submodules and I know for
a fact EDK2 doesn't have too many issues with submodules.
Their documentation is pretty clear on building and requires

git clone https://github.com/tianocore/edk2.git
cd edk2
git submodule update --init

Perhaps the situation has improved since you had issues?


Nope.



While I don't really care how you solve this technically, I'd *strongly*
be interested for U-Boot to use *unmodified* lwIP sources where an
explicit reference to an lwIP commit is used. I'd rather integrate
bugfixes for U-Boot into lwIP than having the sources drift apart.


Strongly agree here, we want to use upstream and all the combined
development and reviews etc rather than forking off and ending up with
yet another slightly different IP stack. The whole advantage of
adopting LWIP is the advantage of combined security, features and bugs
from a wide range of projects :-)


Yes, this is what I want as well, and why I'm perhaps more agreeable
with the approaches where it's a lot harder for us to start forking
things unintentionally.  I gather submodule rather than subtree would be
better for that case?

--
Tom



Yes, submodule will be a much better solution for us. And I also don't think 
that today
there are any issues with submodules. It works well of OE, RPM and DEB builds,
distributions should not have problems with it.


My particular experience is with coreboot. Some problems I have:

1. Updating the modules doesn't work and I need to reset, try the
--init thing, fetch things manually, etc. etc.
2. In ChromiumOS coreboot we can't use submodules internally since
each package has its own build script. E.g. we need to build coreboot
separately from its blobs, fsp, external libraries, etc. At least
there we can do this, but if U-Boot adopts a submodule for a core
feature, this is going to create no end of problems.
3. It makes it impossible to patch lwip for any fix we need for a release
4. We still have to 'fast forward' to a new commit every now and then,
which really is no easier than doing a merge commit for the changes
since the last sync, is it?

Really, we need a maintainer for the lwip piece, if we are to adopt
it. Using submodules is not a substitute for that.


As an lwIP maintainer, I cannot step up as a maintainer of lwIP in
U-Boot, however, I can assure you I will do my best to work with you on
integrating fixes into upstream lwIP if required.

Without wanting to promote using submodules: all other examples of lwIP
being copied into another repository have practically never resulted in
bugfixes being sent back to us (ok, that's not 100% true, but we do get
them only once in a while) and being like that, those projects are
facing problems upgrading our stack in turn. I wouldn't want to be a
maintainer of such code, either.

Regards,
Simon

Re: [PATCHv8 00/15] net/lwip: add lwip library for the network stack

[Simon Goldschmidt]

On 13.09.2023 09:53, Ilias Apalodimas wrote:

Hi Maxim,

On Wed, 13 Sept 2023 at 10:32, Maxim Uvarov  wrote:




On Wed, 13 Sept 2023 at 01:27, Simon Glass  wrote:


Hi Maxim,

On Tue, 12 Sept 2023 at 05:42, Maxim Uvarov  wrote:


On Fri, 8 Sept 2023 at 19:59, Tom Rini  wrote:


On Fri, Sep 08, 2023 at 07:53:05PM +0600, Maxim Uvarov wrote:


Before apply these patches it  is needed to create lwIP merge into

U-Boot:

git subtree add --prefix net/lwip/lwip-external

https://git.savannah.nongnu.org/git/lwip.git master --squash

or
create git submodule, depends how it's more easy to maintain external
library.


So, I think we're going to go with subtree.  Please work out how to
integrate the above in to the build process automatically (and such that
we can maintain it via upgrades moving forward).

--
Tom



I did not find a good way to friend git format-patch, git am and subtree.
And now with using subtree I can provide my thoughts, in general I do not
see any big advantages
with maintaining subtree code.

Problem is that:

1. subtree does some root reset. So rebase looks like:
label onto



# Branch acbc0469a49de7055141cc730aa9c728e61b6de2-2

reset [new root]

pick acbc0469a4 Squashed 'net/lwip/lwip-external/' content from commit
84fde1ebbf
label acbc0469a49de7055141cc730aa9c728e61b6de2-2



reset onto

merge -C ec4a128c8d acbc0469a49de7055141cc730aa9c728e61b6de2-2 # Merge
commit 'acbc0469a49de7055141cc730aa9c728e61b6de2' as
'net/lwip/lwip-external'
pick 739681a6f5 net/lwip: add doc/develop/net_lwip.rst

pick f0ecab85e0 net/lwip: integrate lwIP library

2. if  --rebase-merges option was not provided to rebase, then rebase will
omit subtree directory and try to apply rebase patches to root directory.
I.e. in current case squashed commit for lwip, will be applied to uboot
root directory instead of ./net/lwip/lwip-external.

3. due to broken rebases without --rebase-merges more likely things like
git bisect also will not work.

4.  change in subtree code ./net/lwip/lwip-external/../something.c will
create a git commit which looks like a standard U-Boot commit. I.e. path
starts with ./net/lwip/lwip-external/


I don't really understand most of the above, but I take it that
subtree has some problems...I did find an article about subtree [1]



5. lwip maintains code with a mailing list.  So we don't need to push
subtree git somewhere to create a pull request.

6. I rechecked the latest edk2 and they use submodules now. (openssl,
libfdt, berkeley-softfloat-3 and others).

7. dynamic download also looks horrible for me. I.e. create subtree in
Makefile on compilation process. I think maintaining that will give you a
bunch of problems. I think we should not touch git structure after cloning.

So what I can here suggest:
1.  lwip source code is 9.4M.  If we compare all code it will be 564M in
total. So just having 1 commit witn copy of lwip library will work here.


So we add a 9.4MB patch for the code we need? I suppose that is OK,
although it is much larger than net/ today (0.5MB).

What is the churn on lwip? E.g. would it be easy to add a commit every
few months to bring in upstream changes?



or

2. use git submodules. Size of the project will be lower.  Submodule will
not allow you to use local changes. I.e. change needs to be merged into the
upstream project and then you can update git HEAD for the submodule.


I really don't want to work with a submodule project. I've just had
too many problems.



or

3. inside u-boot.git create branch lib-lwip and clone lwip repo there. Then
use git submoule to connect this branch as a folder to the main U-Boot code.


It really needs to be properly part of U-Boot.



Ok. Then more likely we don't need all the git history of lwip inside 
uboot.git. Then the option with a single commit is more preferable.
Then we can use part 2 of this article, how to  go with standard git commands:

1.

git remote add -f lwip https://git.savannah.nongnu.org/git/lwip.git
git read-tree --prefix=net/lwip/lwip-external -u lwip/master
git commit -m "lwip merge sha: "

this will create a git format-patch friendly commit. Then we send it to the 
mailing list  and apply.
I hope the mailing list will allow us to send a 7.8 MB patch.


Then if for development you need  to pull he history of lwip, you can do it 
with:
git pull -s subtree lwip  master --allow-unrelated-histories
(but I think nobody will need this.)

New update of the lwip net/lwip/lwip-external dir will be done with:
git pull -s subtree lwip  master --allow-unrelated-histories --squash
Squash commit also has to be git format-patch friendly.

If you are ok with that proposal I will send v9 with the first patch created 
with steps above.


We've gone through this before.  The whole purpose of this is not
having to maintain patches.
Simon, instead of "I had problems in the past", can you elaborate a bit more?

Tom said he is fine with subtrees instead of submodules and I know for
a fact EDK2 doesn't have too many issues with 

Re: [PATCHv8 05/15] net/lwip: implement tftp cmd

[Simon Goldschmidt]

On 13.09.2023 08:15, Ilias Apalodimas wrote:

+
+/*
+ * (C) Copyright 2023 Linaro Ltd. 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "tftp_client.h"
+#include "tftp_server.h"
+#include 
+
+#include 
+
+#include 
+
+static ulong daddr;
+static ulong size;
+
+static void *tftp_open(const char *fname, const char *mode, u8_t is_write)
+{
+   return NULL;
+}
+
+static void tftp_close(void *handle)
+{
+   log_info("\ndone\n");
+   log_info("Bytes transferred = %ld (0x%lx hex)\n", size, size);
+
+   bootstage_mark_name(BOOTSTAGE_KERNELREAD_STOP, "tftp_done");
+   if (env_set_hex("filesize", size)) {
+   log_err("filesize not updated\n");
+   ulwip_exit(-1);
+   return;
+   }
+   ulwip_exit(0);
+}
+
+static int tftp_read(void *handle, void *buf, int bytes)
+{
+   return 0;
+}
+
+static int tftp_write(void *handle, struct pbuf *p)
+{
+   struct pbuf *q;
+
+   for (q = p; q != NULL; q = q->next) {
+   memcpy((void *)daddr, q->payload, q->len);
+   daddr += q->len;
+   size += q->len;
+   log_info("#");
+   }
+
+   return 0;
+}
+
+static void tftp_error(void *handle, int err, const char *msg, int size)
+{
+   char message[100];
+
+   memset(message, 0, sizeof(message));
+   memcpy(message, msg, LWIP_MIN(sizeof(message) - 1, (size_t)size));
+
+   log_info("TFTP error: %d (%s)", err, message);
+}
+
+static const struct tftp_context tftp = {
+   tftp_open,
+   tftp_close,
+   tftp_read,
+   tftp_write,
+   tftp_error
+};
+
+int ulwip_tftp(ulong addr, char *fname)
+{
+   void *f = (void *)0x1; /* unused fake file handle*/


I haven't dug into lwip details yet, but I am not sure this is safe to use.
Simon, since you maintain the lwip part can you elaborate a bit more?


From the lwIP design, using an invalid pointer here is ok: that pointer
is only used as a client handle which is never dereferenced internally.
The only requirement is that it is not NULL, as that is the validity
check for the tftp client to know the handle is valid (or e.g. open
failed etc.).

So while we can leave 0x1 here, using a static uint8_t would probably be
better, at the expense of using a byte for nothing.

Regards,
Simon




+   err_t err;
+   ip_addr_t srv;
+   int ret;
+   char *server_ip;
+
+   if (!fname || addr == 0)
+   return CMD_RET_FAILURE;
+
+   size = 0;
+   daddr = addr;
+   server_ip = env_get("serverip");
+   if (!server_ip) {
+   log_err("error: serverip variable has to be set\n");
+   return CMD_RET_FAILURE;
+   }
+
+   ret = ipaddr_aton(server_ip, );
+   if (!ret) {
+   log_err("error: ipaddr_aton\n");
+   return CMD_RET_FAILURE;
+   }
+
+   log_info("TFTP from server %s; our IP address is %s\n",
+server_ip, env_get("ipaddr"));
+   log_info("Filename '%s'.\n", fname);
+   log_info("Load address: 0x%lx\n", daddr);
+   log_info("Loading:");
+
+   bootstage_mark_name(BOOTSTAGE_KERNELREAD_START, "tftp_start");
+
+   err = tftp_init_client();
+   if (!(err == ERR_OK || err == ERR_USE))
+   log_err("tftp_init_client err: %d\n", err);
+
+   err = tftp_get(f, , TFTP_PORT, fname, TFTP_MODE_OCTET);
+   /* might return different errors, like routing problems */
+   if (err != ERR_OK) {
+   log_err("tftp_get err=%d\n", err);
+   return CMD_RET_FAILURE;
+   }
+
+   if (env_set_hex("fileaddr", addr)) {
+   log_err("fileaddr not updated\n");
+   return CMD_RET_FAILURE;
+   }
+
+   return CMD_RET_SUCCESS;
+}
--
2.30.2



Thanks
/Ilias

Re: [PATCHv8 04/15] net/lwip: implement dhcp cmd

[Simon Goldschmidt]

On 13.09.2023 08:07, Ilias Apalodimas wrote:

On Fri, Sep 08, 2023 at 07:53:09PM +0600, Maxim Uvarov wrote:

+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "lwip/timeouts.h"
+
+#include 
+#include 
+
+#define DHCP_WAIT_MS 2000


Is this the time we wait for a dhcp reply? If so we should bump it to
something higher


+
+static void dhcp_tmo(void *arg)
+{
+   struct netif *netif = (struct netif *)arg;
+   struct dhcp *dhcp;
+   int err = 0;
+
+   dhcp = netif_get_client_data(netif, LWIP_NETIF_CLIENT_DATA_INDEX_DHCP);
+   if (!dhcp)
+   return;
+
+   switch (dhcp->state) {
+   case DHCP_STATE_BOUND:
+   err += env_set("bootfile", dhcp->boot_file_name);
+   err += env_set("ipaddr", ip4addr_ntoa(>offered_ip_addr));
+   err += env_set("netmask", ip4addr_ntoa(>offered_sn_mask));
+   err += env_set("serverip", ip4addr_ntoa(>server_ip_addr));
+   if (err)
+   log_err("error update envs\n");
+   log_info("DHCP client bound to address %s\n", 
ip4addr_ntoa(>offered_ip_addr));
+   break;
+   default:
+   return;
+   }
+}
+
+int ulwip_dhcp(void)
+{
+   struct netif *netif;
+   int eth_idx;
+
+   eth_idx = eth_get_dev_index();
+   if (eth_idx < 0)
+   return -EPERM;
+
+   netif = netif_get_by_index(eth_idx + 1);


Why is the +1 needed here?


Netif index is driven by posix design and is 1-based in contrast to
U-Boot's 0-based dev index. A comment noting that would probably help
the ones not knowing lwIP.

Regards,
Simon




+   if (!netif)
+   return -ENOENT;
+
+   sys_timeout(DHCP_WAIT_MS, dhcp_tmo, netif);
+
+   return dhcp_start(netif) ? 0 : -EPERM;
+}
--
2.30.2

Re: [PATCHv8 03/15] net/lwip: implement dns cmd

[Simon Goldschmidt]

On 13.09.2023 07:56, Ilias Apalodimas wrote:

On Fri, Sep 08, 2023 at 07:53:08PM +0600, Maxim Uvarov wrote:

U-Boot recently got support for an alternative network stack using LWIP.
Replace dns command with the LWIP variant while keeping the output and
error messages identical.

Signed-off-by: Maxim Uvarov 
---
  include/net/lwip.h   | 19 +++
  net/lwip/Makefile|  2 ++
  net/lwip/apps/dns/lwip-dns.c | 63 
  3 files changed, 84 insertions(+)
  create mode 100644 include/net/lwip.h
  create mode 100644 net/lwip/apps/dns/lwip-dns.c

diff --git a/include/net/lwip.h b/include/net/lwip.h
new file mode 100644
index 00..ab3db1a214
--- /dev/null
+++ b/include/net/lwip.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+int do_lwip_dns(struct cmd_tbl *cmdtp, int flag, int argc,
+   char *const argv[]);
+
+/**
+ * ulwip_dns() - creates the DNS request to resolve a domain host name
+ *
+ * This function creates the DNS request to resolve a domain host name. 
Function
+ * can return immediately if previous request was cached or it might require
+ * entering the polling loop for a request to a remote server.
+ *
+ * @name:dns name to resolve
+ * @varname: (optional) U-Boot variable name to store the result
+ * Returns: ERR_OK(0) for fetching entry from the cache
+ *  -EINPROGRESS success, can go to the polling loop
+ *  Other value < 0, if error
+ */
+int ulwip_dns(char *name, char *varname);
diff --git a/net/lwip/Makefile b/net/lwip/Makefile
index 3fd5d34564..5d8d5527c6 100644
--- a/net/lwip/Makefile
+++ b/net/lwip/Makefile
@@ -62,3 +62,5 @@ obj-$(CONFIG_NET) += lwip-external/src/netif/ethernet.o

  obj-$(CONFIG_NET) += port/if.o
  obj-$(CONFIG_NET) += port/sys-arch.o
+
+obj-y += apps/dns/lwip-dns.o
diff --git a/net/lwip/apps/dns/lwip-dns.c b/net/lwip/apps/dns/lwip-dns.c
new file mode 100644
index 00..b340302f2c
--- /dev/null
+++ b/net/lwip/apps/dns/lwip-dns.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * (C) Copyright 2023 Linaro Ltd. 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+static void dns_found_cb(const char *name, const ip_addr_t *ipaddr, void 
*callback_arg)
+{
+   char *varname = (char *)callback_arg;
+   char *ipstr = ip4addr_ntoa(ipaddr);
+
+   if (varname)
+   env_set(varname, ipstr);
+   log_info("resolved %s to %s\n",  name, ipstr);
+   ulwip_exit(0);
+}
+
+int ulwip_dns(char *name, char *varname)
+{
+   int err;
+   ip_addr_t ipaddr; /* not used */
+   ip_addr_t dns1;
+   ip_addr_t dns2;
+   char *dnsenv = env_get("dnsip");
+   char *dns2env = env_get("dnsip2");
+
+   if (!dnsenv && !dns2env) {
+   log_err("nameserver is not set with dnsip and dnsip2 vars\n");
+   return -ENOENT;
+   }
+
+   if (!dnsenv)
+   log_warning("dnsip var is not set\n");
+   if (!dns2env)
+   log_warning("dnsip2 var is not set\n");
+
+   dns_init();
+
+   if (ipaddr_aton(dnsenv, ))
+   dns_setserver(0, );
+
+   if (ipaddr_aton(dns2env, ))
+   dns_setserver(1, );


env_get will return NULL if any of these is not set.  Looking at
ipaddr_aton() of lwip that might lead to a NULL deref in ip_2_ip6()


Looking at the NULL checks in ipaddr_aton(), you found a bug in lwIP.
I'd vote to leave the above code as is and rely on the bug being fixed
in lwIP before U-Boot enables IPv6 (this is only a bug in dual-stack
mode where IPv4 and IPv6 is enabled).

Regards,
Simon




+
+   err = dns_gethostbyname(name, , dns_found_cb, varname);
+   if (err == ERR_OK)
+   dns_found_cb(name, , varname);
+
+   /* convert lwIP ERR_INPROGRESS to U-Boot -EINPROGRESS */
+   if (err == ERR_INPROGRESS)
+   err = -EINPROGRESS;
+
+   return err;
+}
--
2.30.2

Re: [PATCHv6 09/14] net/lwip: implement lwIP port to U-Boot

[Simon Goldschmidt]

Hi all,

could you please remove the lwip-devel list from CC? I am interested in these 
mails, but the more you dive into U-Boot specific things here, the less people 
on our lwip list will be interested in this topic.

Thanks,
Simon


Am 18. August 2023 14:53:43 MESZ schrieb Maxim Uvarov :
>On Wed, 16 Aug 2023 at 15:01, Ilias Apalodimas 
>wrote:
>
>> On Mon, Aug 14, 2023 at 07:32:48PM +0600, Maxim Uvarov wrote:
>> > Implement network lwIP interface connected to the U-boot.
>> > Keep original file structure widely used fro lwIP ports.
>> > (i.e. port/if.c port/sys-arch.c).
>>
>> What the patch does is obvious.  Try to describe *why* we need this
>>
>> >
>> > Signed-off-by: Maxim Uvarov 
>> > ---
>> >  net/eth-uclass.c  |   8 +
>> >  net/lwip/port/if.c| 260 ++
>> >  net/lwip/port/include/arch/cc.h   |  39 
>> >  net/lwip/port/include/arch/sys_arch.h |  56 ++
>> >  net/lwip/port/include/limits.h|   0
>> >  net/lwip/port/sys-arch.c  |  20 ++
>> >  6 files changed, 383 insertions(+)
>> >  create mode 100644 net/lwip/port/if.c
>> >  create mode 100644 net/lwip/port/include/arch/cc.h
>> >  create mode 100644 net/lwip/port/include/arch/sys_arch.h
>> >  create mode 100644 net/lwip/port/include/limits.h
>> >  create mode 100644 net/lwip/port/sys-arch.c
>> >
>> > diff --git a/net/eth-uclass.c b/net/eth-uclass.c
>> > index c393600fab..6625f6d8a5 100644
>> > --- a/net/eth-uclass.c
>> > +++ b/net/eth-uclass.c
>> > @@ -32,6 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
>> >  struct eth_device_priv {
>> >   enum eth_state_t state;
>> >   bool running;
>> > + ulwip ulwip;
>> >  };
>> >
>> >  /**
>> > @@ -347,6 +348,13 @@ int eth_init(void)
>> >   return ret;
>> >  }
>> >
>> > +struct ulwip *eth_lwip_priv(struct udevice *current)
>> > +{
>> > + struct eth_device_priv *priv = dev_get_uclass_priv(current);
>> > +
>> > + return >ulwip;
>> > +}
>> > +
>> >  void eth_halt(void)
>> >  {
>> >   struct udevice *current;
>> > diff --git a/net/lwip/port/if.c b/net/lwip/port/if.c
>> > new file mode 100644
>> > index 00..625a9c10bf
>> > --- /dev/null
>> > +++ b/net/lwip/port/if.c
>> > @@ -0,0 +1,260 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +
>> > +/*
>> > + * (C) Copyright 2023 Linaro Ltd. 
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "lwip/debug.h"
>> > +#include "lwip/arch.h"
>> > +#include "netif/etharp.h"
>> > +#include "lwip/stats.h"
>> > +#include "lwip/def.h"
>> > +#include "lwip/mem.h"
>> > +#include "lwip/pbuf.h"
>> > +#include "lwip/sys.h"
>> > +#include "lwip/netif.h"
>> > +#include "lwip/ethip6.h"
>> > +
>> > +#include "lwip/ip.h"
>> > +
>> > +#define IFNAME0 'e'
>> > +#define IFNAME1 '0'
>>
>> Why is this needed and how was 'e0' chosen?
>> Dont we have a device name in the udevice struct?
>>
>>
>If we assume that we have lwip netif on top of an active U-Boot eth device,
>then it can be any name.
>
>  /** descriptive abbreviation */
>
>  char name[2];
>
>./net/lwip/lwip-external/contrib/examples/ethernetif/ethernetif.c:#define
>IFNAME0 'e'
>./net/lwip/lwip-external/contrib/examples/ethernetif/ethernetif.c:#define
>IFNAME1 'n'
>./net/lwip/lwip-external/contrib/ports/unix/port/netif/tapif.c:#define
>IFNAME0 't'
>./net/lwip/lwip-external/contrib/ports/unix/port/netif/tapif.c:#define
>IFNAME1 'p'
>./net/lwip/lwip-external/contrib/ports/unix/port/netif/vdeif.c:#define
>IFNAME0 'v'
>./net/lwip/lwip-external/contrib/ports/unix/port/netif/vdeif.c:#define
>IFNAME1 'd'
>./net/lwip/lwip-external/contrib/ports/win32/pcapif.c:#define IFNAME0
>'e'
>./net/lwip/lwip-external/contrib/ports/win32/pcapif.c:#define IFNAME1
>'0'
>./net/lwip/lwip-external/src/netif/bridgeif.c:#define IFNAME0 'b'
>./net/lwip/lwip-external/src/netif/bridgeif.c:#define IFNAME1 'r'
>./net/lwip/port/if.c:#define IFNAME0 'u'
>./net/lwip/port/if.c:#define IFNAME1 '0'
>
>
>
>> > +
>> > +static struct pbuf *low_level_input(struct netif *netif);
>> > +
>> > +int ulwip_enabled(void)
>> > +{
>> > + struct ulwip *ulwip;
>> > +
>> > + ulwip = eth_lwip_priv(eth_get_dev());
>>
>> eth_get_dev() can return NULL.  There are various locations of this call
>> that needs fixing
>>
>
>
>ok.
>
>
>>
>> > + return ulwip->init_done;
>> > +}
>> > +
>> > +
>> > +struct ulwip_if {
>> > +};
>>
>> Why the forward declaration?
>>
>> > +
>> > +#define LWIP_PORT_INIT_NETMASK(addr)  IP4_ADDR((addr), 255, 255, 255, 0)
>>
>> Why are we limiting the netmask to a class C network?
>>
>>
>that can be completely removed.
>
>
>> > +
>> > +void ulwip_poll(void)
>> > +{
>> > + struct pbuf *p;
>> > + int err;
>> > + struct netif *netif = netif_get_by_index(1);
>>
>> First of all netif can be NULL. Apart from that always requesting index 1
>> feels wrong.  We should do something similar to eth_get_dev() and get the
>> *active* device correlation to an index
>>
>>
>I expect that it will be 1 

Re: [PATCHv5 05/13] net/lwip: implement tftp cmd

[Simon Goldschmidt]

On 10.08.2023 13:28, Maxim Uvarov wrote:

On Thu, 3 Aug 2023 at 12:42, Ilias Apalodimas 
wrote:


On Wed, Aug 02, 2023 at 08:06:50PM +0600, Maxim Uvarov wrote:

Signed-off-by: Maxim Uvarov 
---
  lib/lwip/Makefile  |   1 +
  lib/lwip/apps/tftp/Makefile|  16 +
  lib/lwip/apps/tftp/lwip-tftp.c | 124 +
  3 files changed, 141 insertions(+)
  create mode 100644 lib/lwip/apps/tftp/Makefile
  create mode 100644 lib/lwip/apps/tftp/lwip-tftp.c

diff --git a/lib/lwip/Makefile b/lib/lwip/Makefile
index a3521a9d18..1893162c1a 100644
--- a/lib/lwip/Makefile
+++ b/lib/lwip/Makefile
@@ -67,3 +67,4 @@ obj-$(CONFIG_NET) += port/sys-arch.o

  obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
  obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
+obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/
diff --git a/lib/lwip/apps/tftp/Makefile b/lib/lwip/apps/tftp/Makefile
new file mode 100644
index 00..299c95e9c0
--- /dev/null
+++ b/lib/lwip/apps/tftp/Makefile
@@ -0,0 +1,16 @@
+
+ccflags-y += -I$(srctree)/lib/lwip/port/include
+ccflags-y += -I$(srctree)/lib/lwip/lwip-external/src/include

-I$(srctree)/lib/lwip

+ccflags-y += -I$(obj)
+
+$(obj)/tftp.o: $(obj)/tftp.c
+.PHONY: $(obj)/tftp.c
+$(obj)/tftp.c:
+ cp $(srctree)/lib/lwip/lwip-external/src/apps/tftp/tftp.c

$(obj)/tftp.c

+ cp

$(srctree)/lib/lwip/lwip-external/src/include/lwip/apps/tftp_client.h
$(obj)/tftp_client.h

+ cp

$(srctree)/lib/lwip/lwip-external/src/include/lwip/apps/tftp_common.h
$(obj)/tftp_common.h

+ cp

$(srctree)/lib/lwip/lwip-external/contrib/examples/tftp/tftp_example.h
$(obj)/tftp_example.h

+
+obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
+obj-$(CONFIG_CMD_TFTPBOOT) += lwip-tftp.o
+
diff --git a/lib/lwip/apps/tftp/lwip-tftp.c

b/lib/lwip/apps/tftp/lwip-tftp.c

new file mode 100644
index 00..511d82e600
--- /dev/null
+++ b/lib/lwip/apps/tftp/lwip-tftp.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * (C) Copyright 2023 Linaro Ltd. 
+ */
+
+#include 
+#include 
+#include 
+
+#include "lwip/apps/tftp_client.h"
+#include "lwip/apps/tftp_server.h"
+#include 
+
+#include 
+
+#include "../../../lwip/ulwip.h"
+
+#if LWIP_UDP
+
+static ulong daddr;
+static ulong size;
+
+static void *tftp_open(const char *fname, const char *mode, u8_t

is_write)

+{
+ LWIP_UNUSED_ARG(mode);
+ return NULL;
+}
+
+static void tftp_close(void *handle)
+{
+ printf("\ndone\n");
+ printf("Bytes transferred = %ld (0x%lx hex)\n", size, size);


Can you replace all the printf occurences with log_ ?


+
+ env_set_ulong("filesize", size);
+ ulwip_exit(0);
+}
+
+static int tftp_read(void *handle, void *buf, int bytes)
+{
+ return 0;
+}
+
+static int tftp_write(void *handle, struct pbuf *p)
+{
+ struct pbuf *q;
+
+ for (q = p; q != NULL; q = q->next) {
+ memcpy((void *)daddr, q->payload, q->len);
+ /* printf("downloaded chunk size %d, to addr 0x%lx\n",

q->len, daddr); */

Remove all those debug comments on  the next version


+ daddr += q->len;
+ size += q->len;
+ printf("#");
+ }
+
+ return 0;
+}
+
+/* For TFTP client only */
+static void tftp_error(void *handle, int err, const char *msg, int size)
+{
+ char message[100];
+
+ LWIP_UNUSED_ARG(handle);
+
+ memset(message, 0, sizeof(message));
+ MEMCPY(message, msg, LWIP_MIN(sizeof(message)-1, (size_t)size));


Why aren't we using the native memcpy?


+
+ printf("TFTP error: %d (%s)", err, message);
+}
+
+static const struct tftp_context tftp = {
+ tftp_open,
+ tftp_close,
+ tftp_read,
+ tftp_write,
+ tftp_error
+};
+
+int lwip_tftp(ulong addr, char *fname)
+{
+ void *f = (void *)0x1; /*fake handle*/


If it's fake can't it just be NULL? What does 'fake' mean? is that safe to
be passed around the LWIP APIs?



Here I reuse a tftp example from lwIP. f here is a file handle to write
output. I do write to memory and do not use this value.
But there is a check that his value can not be NULL. So something needs to
be passed here to not do modifications to
the example code.


Sorry I did not have the time to follow all your patches here throgouhly
enough. However, if things like this come up, please also do not
hesitate to come to us (lwip developers) with ideas to make our code
more easily integratable into target applications (like U-Boot here).

As I said before (to Maxim in a private mail I think), I think it would
be best to start targeting this integration based on lwIP's master
branch, so modifications in the upstream lwIP sources would be possible
to make this work neatly.

Regards,
Simon







+ err_t err;
+ ip_addr_t srv;
+ int ret;
+ char *server_ip;
+
+ if (!fname || addr == 0)
+ return CMD_RET_FAILURE;
+
+ size = 0;
+ daddr = addr;
+ server_ip = env_get("serverip");
+ if (!server_ip) {
+ printf("error: serverip variable has to be set\n");
+ 

Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration

[Simon Goldschmidt]

Hi Maxim, Tom,

On 24.05.2023 16:05, Maxim Uvarov wrote:

On Tue, 23 May 2023 at 03:23, Tom Rini  wrote:


On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote:

On Mon, 22 May 2023 at 10:20, Tom Rini  wrote:


On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote:

Hi Maxim

On Mon, 22 May 2023 at 12:01, Maxim Uvarov 

wrote:


My measurements for binary after LTO looks like:

U-boot WGET |  LWIP WGET + ping |  LWIP WGET| diff bytes| diff %
870728|  915000| 912560  |

41832| 4.8



I think you'll need to analyze that a bit more.  First of all I don't
think the '+ping' tab is useful.  What is is trying to achieve?




To show the  difference of extra bytes if we add a ping app on top.



- How was LWIP compiled?




It has a really huge configuration. I tried to turn off everything off
everything what can impact on size but still make http app work:
#define LWIP_HAVE_LOOPIF0
#define LWIP_NETCONN0
#define LWIP_SOCKET 0
#define SO_REUSE0
#define LWIP_STATS  0
#define PPP_SUPPORT 0

Disabling loopback:
#define LWIP_NETIF_LOOPBACK 0
can lower to 912288 bytes.

And it's the same compilation option (optimization for size) as the main
u-boot. I will do more experiments, but I think the goal is not to turn

off

everything.



- Was ipv6 supported?




No.  I.e. when I sent results it was enabled on the compilation stage but
not used. I just checked that size remains the same if IPv6 is not even
compiled.



- Can we strip it down even further?





There is always room for optimization. I think I tried to turn off
everything that is configurable with defines. I can play with disable IP
reassembly and things like that or figure out which functions have more
size and if it's possible to exclude them.



  In general please give as much information as you can with what we
gain in functionality from LWIP with those extra bytes of code.




The main idea is to reuse a maintainable IP stack outside of U-boot.

LWIP

can give a nice separation between IP stack code and network application
code.  I.e. application should not take care about any TCP details  (SYN,
ACK, retransmission, reassembly etc) and should open connection and use
functions similar to recv() and send() to transfer data. Data means
application data, no network packets. And LWIP allows
us to do that.
Because LWIP has an API similar to sockets, it has to be very easy to

port

a linux application to LWIP. Then you can test it with a tap device. Then
copy sources to U-boot, add a small integration layer (cmd command to
call), compile and use.

So my suggestion was:
-  do not maintain new network stack code in the current U-boot. Use lwip
sources as an external project.  All bugs related to network stack go to
lwip project first, then sync with U-boot.
- maintain network apps code* or
   -- inside U-boot. Write our own code for application and maintain it
inside U-boot.
   -- inside LWIP. Add examples to LWIP which are suitable for both

U-boot

and LWIP.

* Let's define a U-boot network application as a cmd command. It might be
ping, wget (http or https download), telnet, arp dns etc..

Let's consider the real use case, like HTTPS download client. We need to
enable TLS connection, validate certificates, then do http download.
Looking at the current code of wget command it's quite difficult to
implement this due to the application having some protol level things. On
the other side we can find embedTLS examples to do https download on
sockets. If LWIP socket API is ported then the only thing you need to do

is

change socket() -> lwip_socket(), recv()->lwip_recv(),

send()->lwip_send()

and etc, even function names are similar. If LWIP socket API is not
supported, then use callback API for recv() and send(), which are also
easy.

So yes we add extra bytes, but that will allow us to write more complex
apps, use standard debug tools, use applications with very minimal
integration changes, use help from the LWIP community to fix protocol

bugs,

etc..
Bunch of things already implemented there:
- ipv6
- dhcp
- snmp
- igmp
- dns
- tcp and udp and raw.
- loopback
- netconn
- socket
- stats
- ppp
(I just followed configurable defines).


And please make sure to disable the previous support, my guess fro that

much growth is that you didn't.



# CONFIG_PROT_TCP is not set
# CONFIG_PROT_UDP is not set
# CONFIG_UDP_CHECKSUM is not set
# CONFIG_UDP_FUNCTION_FASTBOOT is not set
# CONFIG_CMD_WGET is not set


I think you need to step back and figure out a better way to measure the
size change and growth.

I am not interested in a path that long term means two networking stacks
in U-Boot.

I am not interested in massively growing the overall binary size for
every platform.  Given how much larger just TCP support is, that's
strongly implying a huge growth for the older use cases too.

But I 

Re: [PATCH V2 1/7] env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set

[Simon Goldschmidt]

Am 23.10.2020 um 11:52 schrieb Marek Vasut:
> On 10/23/20 10:58 AM, Simon Goldschmidt wrote:
>> Am 31.07.2020 um 23:40 schrieb Tom Rini:
>>> On Tue, Jul 07, 2020 at 08:51:33PM +0200, Marek Vasut wrote:
>>>
>>>> If the ENV_ACCESS_IGNORE_FORCE is set, inform user that the variable
>>>> cannot be force-set if such attempt happens.
>>>>
>>>> Signed-off-by: Marek Vasut 
>>>> Reviewed-by: Tom Rini 
>>>
>>> Applied to u-boot/master, thanks!
>>>
>>
>> Sorry I haven't followed this and wasn't able to report this earlier,
>> but I think this is wrong: This warning is issued when 0 is returned,
>> which means the change is accepted, not rejected.
> 
> I think there was a subsequent discussion on this topic in the ML,
> [PATCH] Revert "env: Warn on force access if ENV_ACCESS_IGNORE_FORCE
> set", I think we reached a conclusion this patch was OK. But if you did
> more digging and found a problem, please send a patch / provide details.
> 

I use a script that reads ethaddrs from external storage and then use
"env set -f ethaddr ". With v2020.10, I now get a warning that
this can't be written, but I still see the value later with 'env print'.

I think this should just be reverted. I'll try to find the thread
discussing the revert patch you mentioned.

Regards,
Simon

Re: [PATCH V2 1/7] env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set

[Simon Goldschmidt]

Am 31.07.2020 um 23:40 schrieb Tom Rini:
> On Tue, Jul 07, 2020 at 08:51:33PM +0200, Marek Vasut wrote:
> 
>> If the ENV_ACCESS_IGNORE_FORCE is set, inform user that the variable
>> cannot be force-set if such attempt happens.
>>
>> Signed-off-by: Marek Vasut 
>> Reviewed-by: Tom Rini 
> 
> Applied to u-boot/master, thanks!
> 

Sorry I haven't followed this and wasn't able to report this earlier,
but I think this is wrong: This warning is issued when 0 is returned,
which means the change is accepted, not rejected.

Regards,
Simon

Re: [PATCH v1 00/16] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Chee Hong Ang  schrieb am Mo., 17. Aug. 2020,
06:34:

> Repost of the following patchs:
> https://lists.denx.de/pipermail/u-boot/2020-March/402705.html


If this is a repost, please send as such instead of sending as a new series
v1.

Regards,
Simon


>
> New U-boot flow with ARM Trusted Firmware (ATF) support:
> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
>
> SPL loads the u-boot.itb which consist of:
> 1) u-boot-nodtb.bin (U-Boot Proper image)
> 2) u-boot.dtb (U-Boot Proper DTB)
> 3) bl31.bin (ATF-BL31 image)
>
> Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
>
> Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> register accesses and mailbox communications with Secure Device Manager
> (SDM).
>
> Steps to build the U-Boot with ATF support:
> 1) Build U-Boot
> 2) Build ATF BL31
> 3) Copy ATF BL31 binary image into U-Boot's root folder
> 4) "make u-boot.itb" to generate u-boot.itb
>
> These patchsets have dependency on:
> arm: socfpga: soc64: Add timeout waiting for NOC idle ACK
> https://lists.denx.de/pipermail/u-boot/2020-August/423029.html
>
> Rename Stratix10 FPGA driver and support Agilex
> https://lists.denx.de/pipermail/u-boot/2020-August/422798.html
>
> SoCFPGA mailbox driver fixes and enhancements
> https://lists.denx.de/pipermail/u-boot/2020-August/423140.html
>
> arm: socfpga: soc64: Initialize timer in SPL only
> https://lists.denx.de/pipermail/u-boot/2020-July/419692.html
>
> arm: socfpga: soc64: Remove PHY interface setup from misc arch init
> https://lists.denx.de/pipermail/u-boot/2020-July/419690.html
>
> Enable sysreset support for SoCFPGA SoC64 platforms
> https://lists.denx.de/pipermail/u-boot/2020-August/422509.html
>
> arm: socfpga: soc64: Disable CONFIG_PSCI_RESET
> https://lists.denx.de/pipermail/u-boot/2020-August/423373.html
>
> Chee Hong Ang (16):
>   arm: socfpga: soc64: Remove CONFIG_OF_EMBED
>   arm: socfpga: soc64: Add FIT generator script for pack itb with ATF
>   arm: socfpga: Add function for checking description from FIT image
>   arm: socfpga: soc64: Load FIT image with ATF support
>   arm: socfpga: soc64: Override 'lowlevel_init' to support ATF
>   arm: socfpga: Disable "spin-table" method for booting Linux
>   arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA
> (64bits)
>   arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP
> services
>   mmc: dwmmc: socfpga: Add ATF support for MMC driver
>   net: designware: socfpga: Add ATF support for MAC driver
>   arm: socfpga: soc64: Add ATF support for Reset Manager driver
>   arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
>   arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
> mbox_reset_cold()
>   arm: socfpga: soc64: SSBL shall not setup stack on OCRAM
>   arm: socfpga: soc64: Skip handoff data access in SSBL
>   configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
> support
>
>  arch/arm/mach-socfpga/Kconfig |   2 -
>  arch/arm/mach-socfpga/Makefile|   4 +
>  arch/arm/mach-socfpga/board.c |  12 +-
>  arch/arm/mach-socfpga/include/mach/smc_api.h  |  13 +
>  arch/arm/mach-socfpga/lowlevel_init_soc64.S   |  76 +++
>  arch/arm/mach-socfpga/mailbox_s10.c   |   5 +
>  arch/arm/mach-socfpga/reset_manager_s10.c |  10 +
>  arch/arm/mach-socfpga/smc_api.c   |  56 ++
>  arch/arm/mach-socfpga/wrap_pll_config_s10.c   |   3 +-
>  board/altera/soc64/fit_spl_atf.sh |  91 +++
>  ...defconfig => socfpga_agilex_atf_defconfig} |  25 +-
>  configs/socfpga_agilex_defconfig  |   1 -
>  ...config => socfpga_stratix10_atf_defconfig} |  25 +-
>  configs/socfpga_stratix10_defconfig   |   1 -
>  drivers/fpga/intel_sdm_mb.c   | 139 +
>  drivers/mmc/socfpga_dw_mmc.c  |  20 +
>  drivers/net/dwmac_socfpga.c   |  43 +-
>  include/configs/socfpga_soc64_common.h|   9 +
>  include/linux/intel-smc.h | 573 ++
>  19 files changed, 1078 insertions(+), 30 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
>  create mode 100644 arch/arm/mach-socfpga/lowlevel_init_soc64.S
>  create mode 100644 arch/arm/mach-socfpga/smc_api.c
>  create mode 100755 board/altera/soc64/fit_spl_atf.sh
>  copy configs/{socfpga_agilex_defconfig => socfpga_agilex_atf_defconfig}
> (77%)
>  copy configs/{socfpga_stratix10_defconfig =>
> socfpga_stratix10_atf_defconfig} (80%)
>  create mode 100644 include/linux/intel-smc.h
>
> --
> 2.19.0
>
>

Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images

[Simon Goldschmidt]

Am 11.08.2020 um 16:21 schrieb Tom Rini:
> On Tue, Aug 11, 2020 at 03:14:39PM +0200, Marek Vasut wrote:
>> On 8/11/20 3:06 PM, Tom Rini wrote:
>>> On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote:
>>>
 Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required
 for booting up Cyclone5/Arria10.

 For Cyclone5 using NAND flash image layout for 128 KB memory blocks,
 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp
 which contains four 128KB SPL images (each 64KB SPL is followed by
 64KB of zero-padding).

 Signed-off-by: Chee Hong Ang 
 ---
  Makefile | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

 diff --git a/Makefile b/Makefile
 index 4483a9b..f4631f1 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE
  ifneq ($(CONFIG_ARCH_SOCFPGA),)
  quiet_cmd_socboot = SOCBOOT $@
  cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp   \
 -  spl/u-boot-spl.sfp spl/u-boot-spl.sfp   \
 -  u-boot.img > $@ || rm -f $@
 +  spl/u-boot-spl.sfp \
 +  spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \
 +cat   spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@
  u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
$(call if_changed,socboot)
  
 @@ -1592,8 +1593,10 @@ cmd_socnandboot =  dd if=/dev/zero 
 of=spl/u-boot-spl.pad bs=64 count=1024 ; \
   cat  spl/u-boot-spl.sfp spl/u-boot-spl.pad \
spl/u-boot-spl.sfp spl/u-boot-spl.pad \
spl/u-boot-spl.sfp spl/u-boot-spl.pad \
 -  spl/u-boot-spl.sfp spl/u-boot-spl.pad \
 -  u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad
 +  spl/u-boot-spl.sfp \
 +  spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \
 + cat  spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \
 + rm   -f $@ spl/u-boot-spl.pad
  u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
$(call if_changed,socnandboot)
>>>
>>> It's not immediately clear to me why we're doing this here, rather than
>>> instructing the user to write the file 4 times when programming.  On TI
>>> platforms, even on NAND, for forever there's been multiple locations the
>>> ROM will check for the loader.  Is there a reason to not handle this at
>>> that level?
>>
>> The u-boot-with-spl.sfp was there to have one U-Boot image including
>> SPL, other platforms do that as well. Except for the NAND case, where
>> the padding is different.
> 
> Right, it's a convenience file and handy in some cases.  But what's the
> reason for doing the 4 copy case?  It makes sense to create
> "u-boot-with-stuff-plus-header" when there's a header that has to cover
> the whole load, or you're going to write it to an SD card or there's
> some non-trivial mangling involved.  Is the problem that
> "u-boot-spl.sfp" isn't ever expected to be seen by the user and so it
> would be odd to tell them to write that in the 4 places and then write
> u-boot.img in the correct place, so instead we have to pad everything
> out and make a large file?

As U-Boot and SPL have to fit together, I think it's better to create
just one file that has to be written to SD card or flash. And writing to
NOR flash is, depending on how you do it, not too quick, so it's *very*
convenient to have this "4x SPL plus U-Boot" single file (start the
command, get a coffee and wait).

And yes, it *is* just a convenience thing. But I think it's a good thing
to have as result from the build. Even if it's only for the "dumb
standard user" not having to know the offset where U-Boot has to be put...

Regards,
Simon

Re: [PATCH v2] configs: socfpga: add kernel parameter for immediate reboot

[Simon Goldschmidt]

Tan, Ley Foon  schrieb am Fr., 7. Aug. 2020, 09:25:

>
>
> Ooi, Joyce wrote:
> > From: Joyce Ooi 
> >
> > Add Linux kernel line parameters for socfpga soc64 U-Boot. The "panic=-1"
> > indicates the reset should occur immediately (without a delay).
> >
> > Signed-off-by: Joyce Ooi 
> > ---
> > v2: fix typo in commit message
> > ---
> >  include/configs/socfpga_soc64_common.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/configs/socfpga_soc64_common.h
> > b/include/configs/socfpga_soc64_common.h
> > index 7237ec95e34..d51a532a929 100644
> > --- a/include/configs/socfpga_soc64_common.h
> > +++ b/include/configs/socfpga_soc64_common.h
> > @@ -79,7 +79,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >   * CONFIG_BOOTARGS goes into the environment value "bootargs".
> >   * Do note the value will override also the chosen node in FDT blob.
> >   */
> > -#define CONFIG_BOOTARGS "earlycon"
> > +#define CONFIG_BOOTARGS "earlycon panic=-1"
> >  #define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run
> > linux_qspi_enable;" \
> >  "run mmcboot"
> Hi Joyce
>
> Just noticed CONFIG_BOOTARGS is supported in Kconfig now.
> Can you move this #define to Stratix10 and Agilex *_defconfig?
>

Of course _defconfig is a much better place so that people can easily
override it...
But why do we need this in the defconfig at all? I don't know how other
platforms handle this, but to me it seems like a user setting, not a thing
that should be changed by general config?

Regards,
Simon


> Regards
> Ley Foon
>

Re: [PATCH] arm: socfpga: gen5: Enable cache driver in SPL

[Simon Goldschmidt]

Marek Vasut  schrieb am Fr., 5. Juni 2020, 14:52:

> On 6/5/20 10:20 AM, Ley Foon Tan wrote:
> > Adding "u-boot,dm-pre-reloc" and enable CONFIG_SPL_CACHE
> > to enable cache driver in SPL.
> >
> > This fixed error below in SPL:
> > cache controller driver NOT found!
>

What's the size impact of this? What is the actual problem? From this
description, I would think the message needs to be fixed instead of adding
cache drivers?

We're already quite constrained in gen5. I'm not keen on adding drivers
just because of an error message...

Regards,
Simon

>
> > Signed-off-by: Ley Foon Tan 
>
> Is this for current release or next ?
>

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Goldschmidt]

Am 14.04.2020 um 23:04 schrieb Tom Rini:
> On Tue, Apr 14, 2020 at 10:38:47PM +0200, Simon Goldschmidt wrote:
>> Masahiro Yamada  schrieb am Di., 14. Apr. 2020, 17:34:
>>
>>> Hi Simon,
>>>
>>> On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:
>>>>
>>>> Hi Masahiro,
>>>>
>>>> On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada 
>>> wrote:
>>>>>
>>>>> On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
>>>>>>
>>>>>> Some places use __ASSEMBLER__ instead which does not work since the
>>>>>> Makefile does not define it. Fix them.
>>>>>
>>>>>
>>>>> In my understanding,
>>>>> __ASSEMBLER__ is passed by the compiler
>>>>> while building *.S files.
>>>>>
>>>>> On which compiler didn't this work for you?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Simon Glass 
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Add new patch to fix occurances of __ASSEMBLER__
>>>>>>
>>>>
>>>> I think I hit this with device tree, but I would need to go back and
>>>> check. Anyway I think we should be consistent.
>>>
>>>
>>> DT files are pre-processed with  '-x assembler-with-cpp'.
>>>
>>> So, __ASSEMBLER__ is pre-defined by the compiler.
>>>
>>
>> I have just seen this thread now. It touches socfpga headers but we're not
>> in CC (possibly the maintainers file needs updating).
>>
>> Anyway, why do we have 2 defines for assembler? If one is predefined by the
>> compiler, why don't we use that? Can you explain that for someone not too
>> deeply involved?
> 
> Generally and broadly speaking, the assembler will set __ASSEMBLER__.
> That said, the Linux kernel has been setting __ASSEMBLY__ for
> practically forever and we've copied that behavior also practically for
> forever.  In both trees there are a handful of __ASSEMBLER__ tests and a
> vast majority of __ASSEMBLY__ tests.  It doesn't normally matter which
> is used as the only non-compiler in the Linux kernel that might care is
> handled as shown above.  Under the assumption that the feature
> Yamada-san pointed out in binman is used, it should also define
> __ASSEMBLER__ I believe, to match other tooling.  Thanks!

Ok, thanks for the explanation.

Regards,
Simon

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Goldschmidt]

Masahiro Yamada  schrieb am Di., 14. Apr. 2020, 17:34:

> Hi Simon,
>
> On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada 
> wrote:
> > >
> > > On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
> > > >
> > > > Some places use __ASSEMBLER__ instead which does not work since the
> > > > Makefile does not define it. Fix them.
> > >
> > >
> > > In my understanding,
> > > __ASSEMBLER__ is passed by the compiler
> > > while building *.S files.
> > >
> > > On which compiler didn't this work for you?
> > >
> > >
> > >
> > >
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Add new patch to fix occurances of __ASSEMBLER__
> > > >
> >
> > I think I hit this with device tree, but I would need to go back and
> > check. Anyway I think we should be consistent.
>
>
> DT files are pre-processed with  '-x assembler-with-cpp'.
>
> So, __ASSEMBLER__ is pre-defined by the compiler.
>

I have just seen this thread now. It touches socfpga headers but we're not
in CC (possibly the maintainers file needs updating).

Anyway, why do we have 2 defines for assembler? If one is predefined by the
compiler, why don't we use that? Can you explain that for someone not too
deeply involved?

Regards,
Simon


> You can easily confirm it by dumping the
> compiler's pre-defined macros.
>
>
>
> $ gcc -dM -E  - < /dev/null  | grep __ASSEMBLER__
> $ gcc -dM -E -x assembler-with-cpp - < /dev/null  | grep __ASSEMBLER__
> #define __ASSEMBLER__ 1
>
>
>
>
> Since the following commit, DT started including U-Boot headers.
> This project is progressively going strange.  :-/
>
>
> commit b116aff27c56dbc9132d847f7134eb7e4cc26aa3
> Author: Simon Glass 
> Date:   Fri Nov 25 20:15:58 2016 -0700
>
> binman: Allow configuration options to be used in .dts files
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
>

Re: [PATCH 22/26 v6] spl: spl_legacy: Add cache flush after reading U-Boot image

[Simon Goldschmidt]

Am 09.04.2020 um 09:43 schrieb Stefan Roese:
> On 09.04.20 09:29, Simon Goldschmidt wrote:
>> Am 08.04.2020 um 10:09 schrieb Stefan Roese:
>>> From: Weijie Gao 
>>>
>>> Flush the cache after reading of the U-Boot proper into SDRAM so that
>>> it can be started.
>>>
>>> This is needed on some platforms, e.g. MT76x8.
>>>
>>> Signed-off-by: Weijie Gao 
>>> Signed-off-by: Stefan Roese 
>>> Cc: Weijie Gao 
>>> Cc: Simon Goldschmidt 
>>> ---
>>> Changes in v6:
>>> - New patch
>>>
>>>   common/spl/spl_legacy.c | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
>>> index 2cd2a74a4c..e320206098 100644
>>> --- a/common/spl/spl_legacy.c
>>> +++ b/common/spl/spl_legacy.c
>>> @@ -4,6 +4,7 @@
>>>*/
>>>   
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   
>>> @@ -108,5 +109,8 @@ int spl_load_legacy_img(struct spl_image_info 
>>> *spl_image,
>>> return -EINVAL;
>>> }
>>>   
>>> +   /* Flush cache of loaded U-Boot image */
>>> +   flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
>>> +
>>
>> I failed to find the mail, but haven't we discussed moving this cache
>> flush to your arch before starting a binary?
> 
> I don't remember such an agreement. But I don't object in general.

Ok, maybe I remember wrong then.

> 
>> I cannot see this being required or implemented for non-legacy images,
>> and it still seems wrong here.
> 
> Its pretty common when an OS image is loaded and booted, that the cache
> is flushed before running code from it.

Yes, of course. I can follow you there. I'm just curious why it's added
here and only for legacy images.

> 
> But I can rework this to add some empty weak function (I don't see an
> easy better way) to do this platform specific image handling before its
> booted. Or do you have a better idea on how to handle this?

I don't know. And I'm not totally opposed to this patch. I just think
it's a strange thing to do here. If you need it, I think it should be in
a more central place. Surely, you'd need it for non-legacy images, too?

I could imagine this being added to jump_to_image_no_args(). That way,
we would have the cache flush in a central place instead of stumbling
accross it again in the future (e.g. for non-legacy images). OTOH, I'm
not sure that would be free of side-effects...?

Regards,
Simon


> 
> Thanks,
> Stefan
> 

Re: [PATCH 22/26 v6] spl: spl_legacy: Add cache flush after reading U-Boot image

[Simon Goldschmidt]

Am 08.04.2020 um 10:09 schrieb Stefan Roese:
> From: Weijie Gao 
> 
> Flush the cache after reading of the U-Boot proper into SDRAM so that
> it can be started.
> 
> This is needed on some platforms, e.g. MT76x8.
> 
> Signed-off-by: Weijie Gao 
> Signed-off-by: Stefan Roese 
> Cc: Weijie Gao 
> Cc: Simon Goldschmidt 
> ---
> Changes in v6:
> - New patch
> 
>  common/spl/spl_legacy.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
> index 2cd2a74a4c..e320206098 100644
> --- a/common/spl/spl_legacy.c
> +++ b/common/spl/spl_legacy.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -108,5 +109,8 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
>   return -EINVAL;
>   }
>  
> + /* Flush cache of loaded U-Boot image */
> + flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
> +

I failed to find the mail, but haven't we discussed moving this cache
flush to your arch before starting a binary?

I cannot see this being required or implemented for non-legacy images,
and it still seems wrong here.

Regards,
Simon

>   return 0;
>  }
> 

Re: [PATCH 19/26 v6] spl: spl_nor: Copy image header to local struct

[Simon Goldschmidt]

On Wed, Apr 8, 2020 at 10:10 AM Stefan Roese  wrote:
>
> From: Weijie Gao 
>
> The image header may be unaligned causing a crash, e.g. on the MT76x8
> platform. This patch copies the header to a local struct to fix this
> potential issue.
>
> Signed-off-by: Weijie Gao 
> Signed-off-by: Stefan Roese 
> Cc: Weijie Gao 
> Cc: Simon Goldschmidt 

Reviewed-by: Simon Goldschmidt 

> ---
> Changes in v6:
> - New patch
>
>  common/spl/spl_nor.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index b1e79b9ded..cb8e06fe1f 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -27,6 +27,8 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
> int ret;
> __maybe_unused const struct image_header *header;
> __maybe_unused struct spl_load_info load;
> +   struct image_header hdr;
> +   uintptr_t dataptr;
>
> /*
>  * Loading of the payload to SDRAM is done with skipping of
> @@ -112,9 +114,12 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
> if (ret)
> return ret;
>
> +   /* Payload image may not be aligned, so copy it for safety */
> +   memcpy(, (void *)spl_nor_get_uboot_base(), sizeof(hdr));
> +   dataptr = spl_nor_get_uboot_base() + sizeof(struct image_header);
> +
> memcpy((void *)(unsigned long)spl_image->load_addr,
> -  (void *)(spl_nor_get_uboot_base() + sizeof(struct 
> image_header)),
> -  spl_image->size);
> +  (void *)dataptr, spl_image->size);
>
> return 0;
>  }
> --
> 2.26.0
>

Re: [PATCH v2 1/3] arm: dts: arria10: Move uboot specific properties to u-boot.dtsi

[Simon Goldschmidt]

On Tue, Apr 7, 2020 at 9:43 AM Ley Foon Tan  wrote:
>
> Move Uboot specific properties to *u-boot.dtsi files.
> Preparation to sync Arria 10 device tree from Linux.
>
> Signed-off-by: Ley Foon Tan 

Reviewed-by: Simon Goldschmidt 

> ---
>  arch/arm/dts/socfpga_arria10-u-boot.dtsi  | 123 ++
>  arch/arm/dts/socfpga_arria10.dtsi |  28 
>  .../arm/dts/socfpga_arria10_socdk-u-boot.dtsi |  17 +++
>  arch/arm/dts/socfpga_arria10_socdk.dtsi   |  27 
>  .../socfpga_arria10_socdk_sdmmc-u-boot.dtsi   |  46 +++
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts  |  37 --
>  6 files changed, 186 insertions(+), 92 deletions(-)
>  create mode 100644 arch/arm/dts/socfpga_arria10-u-boot.dtsi
>  create mode 100644 arch/arm/dts/socfpga_arria10_socdk-u-boot.dtsi
>  create mode 100644 arch/arm/dts/socfpga_arria10_socdk_sdmmc-u-boot.dtsi
>
> diff --git a/arch/arm/dts/socfpga_arria10-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> new file mode 100644
> index ..c637b100738a
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2014, 2020, Intel Corporation
> + */
> +
> +/ {
> +   chosen {
> +   tick-timer = 
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   memory@0 {
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   soc {
> +   u-boot,dm-pre-reloc;
> +   };
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +
> +   clocks {
> +   u-boot,dm-pre-reloc;
> +   };
> +};
> +
> +_intosc_hs_div2_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_intosc_ls_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_free_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   reset-names = "i2c";
> +};
> +
> + {
> +   reset-names = "i2c";
> +};
> +
> + {
> +   reset-names = "i2c";
> +};
> +
> + {
> +   reset-names = "i2c";
> +};
> +
> + {
> +   reset-names = "i2c";
> +};
> +
> +_mp_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_sp_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_sys_free_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_periph_ref_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_pll {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_noc_base_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_free_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_noc_base_clk {
> +   u-boot,dm-pre-reloc;
> +};
> +
> +_pll {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   bank-name = "porta";
> +};
> +
> + {
> +   bank-name = "portb";
> +};
> +
> + {
> +   bank-name = "portc";
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
> b/arch/arm/dts/socfpga_arria10.dtsi
> index cc529bcd1156..c8cd5a84b8a8 100644
> --- a/arch/arm/dts/socfpga_arria10.dtsi
> +++ b/arch/arm/dts/socfpga_arria10.dtsi
> @@ -21,11 +21,6 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> -   chosen {
> -   tick-timer = 
> -   u-boot,dm-pre-reloc;
> -   };
> -
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -60,7 +55,6 @@
> device_type = "soc";
> interrupt-parent = <>;
> ranges;
> -   u-boot,dm-pre-reloc;
>
> amba {
> compatible = "simple-bus";
> @@ -99,35 +93,29 @@
> clkmgr: clkmgr@ffd04000 {
> compatible = "altr,clk-mgr";
> reg = <0xffd04000 0x1000>;
> -   u-boot,dm-pre-reloc;
>
> clocks {
> #address-cells = <1>;
> #size-cells = <0>;
> -   u-boot,dm-pre-reloc;
>
> cb_intosc_hs_div2_clk: 
> cb_intosc_hs_div2_clk {
>

Re: [PATCH v2 2/3] arm: dts: arria10: Update dtsi/dts from Linux

[Simon Goldschmidt]

On Tue, Apr 7, 2020 at 9:43 AM Ley Foon Tan  wrote:
>
> Update these 3 files from Linux:.
> - socfpga_arria10.dtsi (Commit ID c1459a9d7e92)
> - socfpga_arria10_socdk.dtsi (Commit ID d9b9f805ee2b)
> - socfpga_arria10_socdk_sdmmc.dts (Commit ID 17808d445b6f)
>
> Change in socfpga_arria10.dtsi:
> - Add clkmgr label, so that can reference to it in u-boot.dtsi.
>
> Change in socfpga_arria10-u-boot.dtsi:
> - Add compatible and altr,sysmgr-syscon for uboot.
>
> Signed-off-by: Ley Foon Tan 

Reviewed-by: Simon Goldschmidt 

>
> ---
> v2: Update commit ID in description.
> ---
>  arch/arm/dts/socfpga_arria10-u-boot.dtsi | 15 
>  arch/arm/dts/socfpga_arria10.dtsi| 90 ++--
>  arch/arm/dts/socfpga_arria10_socdk.dtsi  | 43 +++---
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 16 +---
>  4 files changed, 108 insertions(+), 56 deletions(-)
>
> diff --git a/arch/arm/dts/socfpga_arria10-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> index c637b100738a..0db358cf1f2b 100644
> --- a/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> @@ -38,6 +38,21 @@
> u-boot,dm-pre-reloc;
>  };
>
> + {
> +   compatible = "altr,socfpga-stmmac", "snps,dwmac-3.72a", "snps,dwmac";
> +   altr,sysmgr-syscon = < 0x44 0>;
> +};
> +
> + {
> +   compatible = "altr,socfpga-stmmac", "snps,dwmac-3.72a", "snps,dwmac";
> +   altr,sysmgr-syscon = < 0x48 0>;
> +};
> +
> + {
> +   compatible = "altr,socfpga-stmmac", "snps,dwmac-3.72a", "snps,dwmac";
> +   altr,sysmgr-syscon = < 0x4C 0>;
> +};
> +
>   {
> reset-names = "i2c";
>  };
> diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
> b/arch/arm/dts/socfpga_arria10.dtsi
> index c8cd5a84b8a8..a598c7554266 100644
> --- a/arch/arm/dts/socfpga_arria10.dtsi
> +++ b/arch/arm/dts/socfpga_arria10.dtsi
> @@ -1,17 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright Altera Corporation (C) 2014. All rights reserved.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms and conditions of the GNU General Public License,
> - * version 2, as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope it will be useful, but WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>
>  #include 
> @@ -79,6 +68,8 @@
> #dma-requests = <32>;
> clocks = <_main_clk>;
> clock-names = "apb_pclk";
> +   resets = < DMA_RESET>, < 
> DMA_OCP_RESET>;
> +   reset-names = "dma", "dma-ocp";
> };
> };
>
> @@ -377,13 +368,28 @@
> clk-gate = <0xC8 11>;
> };
>
> -   nand_clk: nand_clk {
> +   nand_x_clk: nand_x_clk {
> #clock-cells = <0>;
> compatible = 
> "altr,socfpga-a10-gate-clk";
> clocks = <_mp_clk>;
> clk-gate = <0xC8 10>;
> };
>
> +   nand_ecc_clk: nand_ecc_clk {
> +   #clock-cells = <0>;
> +   compatible = 
> "altr,socfpga-a10-gate-clk";
> +   clocks = <_x_clk>;
> +   clk-gate = <0xC8 10>;
> +   };
> +
> +   nand_clk: nand_clk {
> +   #clock-cells = <0>;
> +   compatible = 
> "altr,socfpga-a10-gate-clk";
> +   clocks = <_x_clk>;
> +   

Re: [PATCH v2 3/3] arm: socfpga: arria10: Enable cache driver in SPL

[Simon Goldschmidt]

On Tue, Apr 7, 2020 at 9:43 AM Ley Foon Tan  wrote:
>
> Adding "u-boot,dm-pre-reloc" and enable CONFIG_SPL_CACHE
> to enable cache driver in SPL.
>
> This fixed error below in SPL:
> cache controller driver NOT found!
>
> Signed-off-by: Ley Foon Tan 

Reviewed-by: Simon Goldschmidt 

>
> ---
> v2: Enable SPL_CACHE in Kconfig instead of defconfig.
> ---
>  arch/arm/dts/socfpga_arria10-u-boot.dtsi | 4 
>  arch/arm/mach-socfpga/Kconfig| 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/dts/socfpga_arria10-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> index 0db358cf1f2b..6ff1ea6e5eb7 100644
> --- a/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> @@ -73,6 +73,10 @@
> reset-names = "i2c";
>  };
>
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
>  _mp_clk {
> u-boot,dm-pre-reloc;
>  };
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> index 38d6c1b2ba32..a3699e82a19e 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -46,6 +46,7 @@ config TARGET_SOCFPGA_ARRIA10
> bool
> select SPL_ALTERA_SDRAM
> select SPL_BOARD_INIT if SPL
> +   select SPL_CACHE if SPL
> select CLK
> select SPL_CLK if SPL
> select DM_I2C
> --
> 2.19.0
>

Re: [PATCH 3/3] arm: socfpga: arria10: Enable cache driver in SPL

[Simon Goldschmidt]

Am 06.04.2020 um 11:18 schrieb Ley Foon Tan:
> Adding "u-boot,dm-pre-reloc" and enable CONFIG_SPL_CACHE
> to enable cache driver in SPL.
> 
> This fixed error below in SPL:
> cache controller driver NOT found!
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/dts/socfpga_arria10-u-boot.dtsi | 4 
>  configs/socfpga_arria10_defconfig| 1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/dts/socfpga_arria10-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> index 0db358cf1f2b..6ff1ea6e5eb7 100644
> --- a/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
> @@ -73,6 +73,10 @@
>   reset-names = "i2c";
>  };
>  
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
>  _mp_clk {
>   u-boot,dm-pre-reloc;
>  };
> diff --git a/configs/socfpga_arria10_defconfig 
> b/configs/socfpga_arria10_defconfig
> index ca34457ddd16..875031a77e3a 100644
> --- a/configs/socfpga_arria10_defconfig
> +++ b/configs/socfpga_arria10_defconfig
> @@ -22,6 +22,7 @@ CONFIG_VERSION_VARIABLE=y
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_ENV_SUPPORT=y
>  CONFIG_SPL_FPGA_SUPPORT=y
> +CONFIG_SPL_CACHE=y

Can you select or default this in Kconfig if it's required for all
Arria10 boards (even if we only have one right now)?

Regards,
Simon
>  CONFIG_CMD_ASKENV=y
>  CONFIG_CMD_GREPENV=y
>  # CONFIG_CMD_FLASH is not set
> 

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Goldschmidt]

On 02.04.2020 21:54, Marek Vasut wrote:

On 4/2/20 9:53 PM, Simon Goldschmidt wrote:



On 02.04.2020 21:49, Simon Glass wrote:

Hi Marek,

On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:


On 4/2/20 8:50 PM, Simon Glass wrote:

Hi.


Hi,

[...]


I suspect we could change this, so that
device_ofdata_to_platdata() first calls itself on its parent.

I can think of various reasons why this change might be
desirable.


I think this is how it worked before already.


Well effectively, yes, because ofdata and probe were joined
together.



Simon, do you have plan to fix this DM core issue ?


I'm not sure it definitely should be changed. But I'll do a patch
and
see how it looks.


Do I understand it correctly that the patch
82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
SoCFPGA ? Then I would say this is a release blocker ?

Yes. A10 SPL won't boot at all. It crashes during the clock manager
setup.


This came in right at the beginning of the cycle. I thought the
purpose of the 3-month cycle was to allow time to test?


It was ... altera ?


I do plan to try out changing the behaviour to read a parent's ofdata
before the child, but I am not comfortable adding such a major change
just before a release. It could have any number of ill effects.

Can you update the clock driver? E.g. you could move some of the code
from socfpga_a10_ofdata_to_platdata() to a probe() method?


Can we revert the patch which broke arria10 instead ? It did work
before, so who knows how many other ill side effects there are ...


No, sorry, we need to fix Altera. Other boards have fixed driver bugs
exposed by the patch.

BTW what is a good Altera board to get that doesn't cost too much?


A problem here might be that you'd need to have a gen5, an A10 and a
stratix board to find all problems...


And agilex too ...


Hmm, I thought we would try and keep stratix and agilex more close than 
gen5/A10...


I even don't have any non-gen5 boards myself here, so I cannot even test 
those, either.


But in the end, yes, it would be a good thing to have all those boards 
execute basic tests at least after rc1 has been tagged. I wonder if 
OSADL could help out here, given they already have a broad range of 
boards testing linux-rt already. Or do we have a separate hardware area 
for this?


Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Goldschmidt]

On 02.04.2020 21:49, Simon Glass wrote:

Hi Marek,

On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:


On 4/2/20 8:50 PM, Simon Glass wrote:

Hi.


Hi,

[...]


I suspect we could change this, so that
device_ofdata_to_platdata() first calls itself on its parent.

I can think of various reasons why this change might be desirable.


I think this is how it worked before already.


Well effectively, yes, because ofdata and probe were joined together.



Simon, do you have plan to fix this DM core issue ?


I'm not sure it definitely should be changed. But I'll do a patch and
see how it looks.


Do I understand it correctly that the patch
82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
SoCFPGA ? Then I would say this is a release blocker ?

Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.


This came in right at the beginning of the cycle. I thought the
purpose of the 3-month cycle was to allow time to test?


It was ... altera ?


I do plan to try out changing the behaviour to read a parent's ofdata
before the child, but I am not comfortable adding such a major change
just before a release. It could have any number of ill effects.

Can you update the clock driver? E.g. you could move some of the code
from socfpga_a10_ofdata_to_platdata() to a probe() method?


Can we revert the patch which broke arria10 instead ? It did work
before, so who knows how many other ill side effects there are ...


No, sorry, we need to fix Altera. Other boards have fixed driver bugs
exposed by the patch.

BTW what is a good Altera board to get that doesn't cost too much?


A problem here might be that you'd need to have a gen5, an A10 and a 
stratix board to find all problems...


Regards,
Simon


Regards,
Simon

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

Am 16.03.2020 um 20:55 schrieb Dalon L Westergreen:
> 
> 
> On Mon, 2020-03-16 at 20:06 +0100, Marek Vasut wrote:
>> On 3/16/20 8:04 PM, Simon Goldschmidt wrote:
>>> Am 16.03.2020 um 19:04 schrieb Dalon L Westergreen:
>>>>
>>>> On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote:
>>>>> On 3/12/20 4:54 PM, Dalon L Westergreen wrote:
>>>>> [...]
>>>>>
>>>>> (thanks for fixing your mailer :))
>>>>>
>>>>>>>>>>> The problem was that this was causing weird sporadic hangs
>>>>>>>>>>> on
>>>>>>>>>>> Gen5,
>>>>>>>>>>> which is why it was removed. So until there is an
>>>>>>>>>>> explanation for
>>>>>>>>>>> those
>>>>>>>>>>> hangs, I'm not really OK with this.
>>>>>>>>>>
>>>>>>>>>> These sporadic hangs you saw were on devices without an FPGA
>>>>>>>>>> image
>>>>>>>>>> directly
>>>>>>>>>> accessing the SDRAM ports, right?
>>>>>>>>>
>>>>>>>>> Yes
>>>>>>>>>
>>>>>>>>>>> Maybe the application of static config should happen in SPL,
>>>>>>>>>>> before
>>>>>>>>>>> the
>>>>>>>>>>> DRAM is running, or something like that ?
>>>>>>>>>>
>>>>>>>>>> Thinking this further, limiting it to applying in SPL is not a
>>>>>>>>>> good
>>>>>>>>>> idea
>>>>>>>>>> since
>>>>>>>>>> that prevents us from implementing different FPGA
>>>>>>>>>> images/configs by
>>>>>>>>>> loading a
>>>>>>>>>> config later in the boot (i.e. in U-Boot from a FIT-image).
>>>>>>>>>
>>>>>>>>> Well, but later we have SDRAM running and we cannot make it go
>>>>>>>>> idle,
>>>>>>>>> can
>>>>>>>>> we?
>>>>>>>>>
>>>>>>
>>>>>> Unfortunately the sdram cfg apply must occur AFTER the fpga is
>>>>>> configured.  This
>>>>>> is because the FPGA drives configuration bits, around the interfaces
>>>>>> datawidth
>>>>>> for example, that are used in setting up the dram interface.  I
>>>>>> believe the
>>>>>> intent is for the command to only run when the ridge enable function
>>>>>> is
>>>>>> called.
>>>>>
>>>>> So that's one part of the fix -- only run this apply_static_cfg if the
>>>>> bitstream uses the F2S bridge.
>>>>
>>>> actually, the restriction is to apply this only if the FPGA is configured,
>>>> whether the bridge is used is irrelevant.  you can further restrict this
>>>> to only when the bridge is used, but to me that means devicetree entries
>>>> or something to determine whether it is used.
>>>
>>> In my opinion, we need an FPGA-specific devicetree (or something
>>> similar) to describe the FPGA image, anyway.
>>
>> Like a DTO ?
> 
> DTOs are how i suggest solving this in linux, so i would assume a dto would
> be best here too.

Yes. That DTO should be beside the FPGA image, either in a FIT image or
just loaded separately. It should contain pin settings, bridge settings etc.

However, to ensure the bus is idle, we still would have to limit
applying that config bit to before RAM is set up, so quite early in SPL,
right? I cannot see how that would work, given the limit of 64K. Plus
it's kind of a bad boot flow to configure the FPGA before even starting
U-Boot...

Regards,
Simon

> 
>>
>>> Today, too much
>>> configuration is applied at compile time (or when programming SPL to
>>> flash at latest) - there's currently no way to switch peripherals to
>>> FPGA for one image but not for another, for example.
>>
>> Yes
>>
>>> Worse: if you enable bridges but there's no slave attached, the CPU can
>>> be stuck. That would need to be described with the FPGA image as well.
>>
>> Can you propose a patch ?
>>
> 

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

Am 16.03.2020 um 20:06 schrieb Marek Vasut:
> On 3/16/20 8:04 PM, Simon Goldschmidt wrote:
>> Am 16.03.2020 um 19:04 schrieb Dalon L Westergreen:
>>>
>>>
>>> On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote:
>>>> On 3/12/20 4:54 PM, Dalon L Westergreen wrote:
>>>> [...]
>>>>
>>>> (thanks for fixing your mailer :))
>>>>
>>>>>>>>>> The problem was that this was causing weird sporadic hangs on
>>>>>>>>>> Gen5,
>>>>>>>>>> which is why it was removed. So until there is an explanation for
>>>>>>>>>> those
>>>>>>>>>> hangs, I'm not really OK with this.
>>>>>>>>>
>>>>>>>>> These sporadic hangs you saw were on devices without an FPGA image
>>>>>>>>> directly
>>>>>>>>> accessing the SDRAM ports, right?
>>>>>>>>
>>>>>>>> Yes
>>>>>>>>
>>>>>>>>>> Maybe the application of static config should happen in SPL,
>>>>>>>>>> before
>>>>>>>>>> the
>>>>>>>>>> DRAM is running, or something like that ?
>>>>>>>>>
>>>>>>>>> Thinking this further, limiting it to applying in SPL is not a good
>>>>>>>>> idea
>>>>>>>>> since
>>>>>>>>> that prevents us from implementing different FPGA images/configs by
>>>>>>>>> loading a
>>>>>>>>> config later in the boot (i.e. in U-Boot from a FIT-image).
>>>>>>>>
>>>>>>>> Well, but later we have SDRAM running and we cannot make it go idle,
>>>>>>>> can
>>>>>>>> we?
>>>>>>>>
>>>>>
>>>>> Unfortunately the sdram cfg apply must occur AFTER the fpga is
>>>>> configured.  This
>>>>> is because the FPGA drives configuration bits, around the interfaces
>>>>> datawidth
>>>>> for example, that are used in setting up the dram interface.  I believe 
>>>>> the
>>>>> intent is for the command to only run when the ridge enable function is
>>>>> called.
>>>>
>>>> So that's one part of the fix -- only run this apply_static_cfg if the
>>>> bitstream uses the F2S bridge.
>>>
>>> actually, the restriction is to apply this only if the FPGA is configured,
>>> whether the bridge is used is irrelevant.  you can further restrict this
>>> to only when the bridge is used, but to me that means devicetree entries
>>> or something to determine whether it is used.
>>
>> In my opinion, we need an FPGA-specific devicetree (or something
>> similar) to describe the FPGA image, anyway.
> 
> Like a DTO ?
> 
>> Today, too much
>> configuration is applied at compile time (or when programming SPL to
>> flash at latest) - there's currently no way to switch peripherals to
>> FPGA for one image but not for another, for example.
> 
> Yes
> 
>> Worse: if you enable bridges but there's no slave attached, the CPU can
>> be stuck. That would need to be described with the FPGA image as well.
> 
> Can you propose a patch ?

In corona times and with kids now at home, I don't know if I can soon :-(

Regards,
Simon

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

Am 16.03.2020 um 19:04 schrieb Dalon L Westergreen:
> 
> 
> On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote:
>> On 3/12/20 4:54 PM, Dalon L Westergreen wrote:
>> [...]
>>
>> (thanks for fixing your mailer :))
>>
 The problem was that this was causing weird sporadic hangs on
 Gen5,
 which is why it was removed. So until there is an explanation for
 those
 hangs, I'm not really OK with this.
>>>
>>> These sporadic hangs you saw were on devices without an FPGA image
>>> directly
>>> accessing the SDRAM ports, right?
>>
>> Yes
>>
 Maybe the application of static config should happen in SPL,
 before
 the
 DRAM is running, or something like that ?
>>>
>>> Thinking this further, limiting it to applying in SPL is not a good
>>> idea
>>> since
>>> that prevents us from implementing different FPGA images/configs by
>>> loading a
>>> config later in the boot (i.e. in U-Boot from a FIT-image).
>>
>> Well, but later we have SDRAM running and we cannot make it go idle,
>> can
>> we?
>>
>>>
>>> Unfortunately the sdram cfg apply must occur AFTER the fpga is
>>> configured.  This
>>> is because the FPGA drives configuration bits, around the interfaces
>>> datawidth
>>> for example, that are used in setting up the dram interface.  I believe the
>>> intent is for the command to only run when the ridge enable function is
>>> called.
>>
>> So that's one part of the fix -- only run this apply_static_cfg if the
>> bitstream uses the F2S bridge.
> 
> actually, the restriction is to apply this only if the FPGA is configured,
> whether the bridge is used is irrelevant.  you can further restrict this
> to only when the bridge is used, but to me that means devicetree entries
> or something to determine whether it is used.

In my opinion, we need an FPGA-specific devicetree (or something
similar) to describe the FPGA image, anyway. Today, too much
configuration is applied at compile time (or when programming SPL to
flash at latest) - there's currently no way to switch peripherals to
FPGA for one image but not for another, for example.

Worse: if you enable bridges but there's no slave attached, the CPU can
be stuck. That would need to be described with the FPGA image as well.

Regards,
Simon

> 
>>
>>> Would it work to make setting this optional, i.e. only write the bit
>>> if
>>> an FPGA
>>> config actually uses these ports? Then it couldn't lead to problems
>>> on
>>> other
>>> hardware...
>>
>> Can you make SDRAM bus really idle ?
>
> From the CPU side, that should work, no? Of course you have to make sure
> no
> other peripheraly (including FPGA!) are using the RAM.
>
> And if this would be an explicit command, people needing this could
> experiment with it - and hopefully give better hints as to what's going
> wrong
> if we *do* see problems again.

 Maybe altera has something hidden somewhere in the bus tunables ? :)
>>>
>>> The only trick i am aware of, and Ley Foon, please comment, is isolating
>>> relevant code to the caches before executing.
>>
>> How do you make sure some DMA doesn't do something funny or some pending
>> write doesn't trigger DRAM write ? There is more than the CPU that can
>> access the DRAM and cause bus traffic.
> 
> True, and it is unclear how we could ensure there is absolutely no traffic.
> 
> --dalon
> 
> 

Re: [PATCH 1/1] fit: check return value of fit_image_get_data_size()

[Simon Goldschmidt]

On Wed, Mar 11, 2020 at 9:51 PM Heinrich Schuchardt  wrote:
>
> GCC-10 reports:
>
> In file included from tools/common/image-fit.c:1:
> include/image.h: In function ‘fit_image_get_data_and_size’:
> ./tools/../common/image-fit.c:1015:9: warning: ‘len’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>  1015 |   *size = len;
>   |   ~~^
> ./tools/../common/image-fit.c:996:6: note: ‘len’ was declared here
>   996 |  int len;
>   |  ^~~
>
> Add the missing check of the return value of fit_image_get_data_size().
>
> Fixes: c3c863880479 ("add FIT data-position & data-offset property support")
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Simon Goldschmidt 

> ---
>  common/image-fit.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index f3bb00c98a..4435bc4f1d 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1011,8 +1011,10 @@ int fit_image_get_data_and_size(const void *fit, int 
> noffset,
> if (external_data) {
> debug("External Data\n");
> ret = fit_image_get_data_size(fit, noffset, );
> -   *data = fit + offset;
> -   *size = len;
> +   if (!ret) {
> +   *data = fit + offset;
> +   *size = len;
> +   }
> } else {
> ret = fit_image_get_data(fit, noffset, data, size);
> }
> --
> 2.25.1
>

Re: [PATCH v6 1/5] dm: clk: add stub when CONFIG_CLK is deactivated

[Simon Goldschmidt]

Am 10.03.2020 um 11:09 schrieb Patrick Delaunay:
> Add stub for functions clk_...() when CONFIG_CLK is deactivated.
> 
> This patch avoids compilation issues for driver using these API
> without protection (#if CONFIG_IS_ENABLED(CLK))
> 
> For example, before this patch we have undefined reference to
> `clk_disable_bulk') for code:
>   clk_disable_bulk(>clks);
>   clk_release_bulk(>clks);
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Simon Goldschmidt 

> ---
> 
> Changes in v6:
> - return success in stub for clk_free/clk_enable/clk_disable/
>   clk_enable_bulk/clk_disable_bulk
> 
> Changes in v5:
> - use ERR_PTR in clk_get_parent()
> - force bulk->count = 0 in clk_get_bulk to avoid issue
>   for next call of clk_enable_bulk / clk_enable_bulk
> - update commit message
> 
> Changes in v4:
> - Add stub for all functions using 'struct clk' or 'struct clk_bulk'
>   after remarks on v3
> 
> Changes in v3:
> - Add stub for clk_disable_bulk
> 
> Changes in v2: None
> 
>  include/clk.h | 102 +++---
>  1 file changed, 89 insertions(+), 13 deletions(-)
> 
> diff --git a/include/clk.h b/include/clk.h
> index 3336301815..60c4b7d075 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -9,6 +9,7 @@
>  #define _CLK_H_
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -312,6 +313,7 @@ static inline int clk_release_bulk(struct clk_bulk *bulk)
>   return clk_release_all(bulk->clks, bulk->count);
>  }
>  
> +#if CONFIG_IS_ENABLED(CLK)
>  /**
>   * clk_request - Request a clock by provider-specific ID.
>   *
> @@ -433,19 +435,6 @@ int clk_disable_bulk(struct clk_bulk *bulk);
>   */
>  bool clk_is_match(const struct clk *p, const struct clk *q);
>  
> -int soc_clk_dump(void);
> -
> -/**
> - * clk_valid() - check if clk is valid
> - *
> - * @clk: the clock to check
> - * @return true if valid, or false
> - */
> -static inline bool clk_valid(struct clk *clk)
> -{
> - return clk && !!clk->dev;
> -}
> -
>  /**
>   * clk_get_by_id() - Get the clock by its ID
>   *
> @@ -465,6 +454,93 @@ int clk_get_by_id(ulong id, struct clk **clkp);
>   * @return true on binded, or false on no
>   */
>  bool clk_dev_binded(struct clk *clk);
> +
> +#else /* CONFIG_IS_ENABLED(CLK) */
> +
> +static inline int clk_request(struct udevice *dev, struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_free(struct clk *clk)
> +{
> + return 0;
> +}
> +
> +static inline ulong clk_get_rate(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline struct clk *clk_get_parent(struct clk *clk)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +
> +static inline long long clk_get_parent_rate(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline ulong clk_set_rate(struct clk *clk, ulong rate)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_enable(struct clk *clk)
> +{
> + return 0;
> +}
> +
> +static inline int clk_enable_bulk(struct clk_bulk *bulk)
> +{
> + return 0;
> +}
> +
> +static inline int clk_disable(struct clk *clk)
> +{
> + return 0;
> +}
> +
> +static inline int clk_disable_bulk(struct clk_bulk *bulk)
> +{
> + return 0;
> +}
> +
> +static inline bool clk_is_match(const struct clk *p, const struct clk *q)
> +{
> + return false;
> +}
> +
> +static inline int clk_get_by_id(ulong id, struct clk **clkp)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline bool clk_dev_binded(struct clk *clk)
> +{
> + return false;
> +}
> +#endif /* CONFIG_IS_ENABLED(CLK) */
> +
> +/**
> + * clk_valid() - check if clk is valid
> + *
> + * @clk: the clock to check
> + * @return true if valid, or false
> + */
> +static inline bool clk_valid(struct clk *clk)
> +{
> + return clk && !!clk->dev;
> +}
> +
> +int soc_clk_dump(void);
> +
>  #endif
>  
>  #define clk_prepare_enable(clk) clk_enable(clk)
> 

Re: [PATCH v6 4/5] usb: host: dwc2: force reset assert

[Simon Goldschmidt]

Am 10.03.2020 um 11:09 schrieb Patrick Delaunay:
> Assert reset before deassert in dwc2_reset;
> this patch solve issues when the DWC2 registers are already
> initialized with value incompatible with host mode.
> 
> Force a hardware reset of the IP reset all the DWC2 registers at
> default value, the host driver start with a clean state
> (Core Soft reset doen in dwc_otg_core_reset is not enought
>  to reset all register).
> 
> The error can occurs in U-Boot when DWC2 device gadget driver
> force device mode (called by ums or dfu command, before to execute
> the usb start command).
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Simon Goldschmidt 

> ---
> 
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - add clk_disable_bulk in dwc2_usb_remove
> 
>  drivers/usb/host/dwc2.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index b1b79d0a18..640ae3e730 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -1151,6 +1151,8 @@ static int dwc2_reset(struct udevice *dev)
>   return ret;
>   }
>  
> + /* force reset to clear all IP register */
> + reset_assert_bulk(>resets);
>   ret = reset_deassert_bulk(>resets);
>   if (ret) {
>   reset_release_bulk(>resets);
> 

Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver

[Simon Goldschmidt]

Am 10.03.2020 um 17:42 schrieb Ang, Chee Hong:
>> -Original Message-
>> From: Simon Goldschmidt 
>> Sent: Wednesday, March 11, 2020 12:17 AM
>> To: Ang, Chee Hong 
>> Cc: u-boot@lists.denx.de; Marek Vasut ; See, Chin Liang
>> ; Tan, Ley Foon ;
>> Westergreen, Dalon ; Gong, Richard
>> 
>> Subject: Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager
>> driver
>>
>> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
>>> From: Chee Hong Ang 
>>>
>>> This driver (misc uclass) handle the read/write access to System
>>> Manager. For 64 bits platforms, processor needs to be in secure mode
>>> to has write access to most of the System Manager's registers (except
>>> boot scratch registers). When the processor is running in EL2
>>> (non-secure), this driver will invoke the SMC call to ATF to perform
>>> write access to the System Manager's registers.
>>> All other drivers that require access to System Manager should go
>>> through this driver.
>>>
>>> Signed-off-by: Chee Hong Ang 
>>> ---
>>>  drivers/misc/Makefile|   1 +
>>>  drivers/misc/altera_sysmgr.c | 115
>>> +++
>>>  2 files changed, 116 insertions(+)
>>>  create mode 100644 drivers/misc/altera_sysmgr.c
>>>
>>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
>>> 2b843de..9fa2411 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -29,6 +29,7 @@ endif
>>>  endif
>>>  obj-$(CONFIG_ALI152X) += ali512x.o
>>>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
>>> +obj-$(CONFIG_ARCH_SOCFPGA) += altera_sysmgr.o
>>>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>>>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>>>  obj-$(CONFIG_DS4510)  += ds4510.o
>>> diff --git a/drivers/misc/altera_sysmgr.c
>>> b/drivers/misc/altera_sysmgr.c new file mode 100644 index
>>> 000..b36ecae
>>> --- /dev/null
>>> +++ b/drivers/misc/altera_sysmgr.c
>>
>> I think this file should have something in the name specifying it is for 
>> s10/agilex.
>> I will post a misc/sysmgr for gen5 that needs a specific name, too
> Gen5/A10/S10/Agilex are using same DW MMC/MAC drivers and these drivers 
> access system manager.
> Therefore, this driver is enabled for all platforms. Gen5/A10, S10/Agilex all 
> are using it.
> Can I know what does your gen5 sysmgr driver do ?
> I can change the name to avoid conflict but Gen5 will have 2 sysmgr drivers 
> for different purposes.
> Are you OK with that ?
>>
>>> @@ -0,0 +1,115 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2020 Intel Corporation   */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define IS_OUT_OF_SYSMGR(addr, range) ((addr) > (range))
>>> +
>>> +struct altera_sysmgr_priv {
>>> +   fdt_addr_t base_addr;
>>> +   fdt_addr_t base_size;
>>> +};
>>> +
>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) static int
>>> +secure_write32(u32 val, fdt_addr_t addr) {
>>> +   int ret;
>>> +   u64 args[2];
>>> +
>>> +   args[0] = (u64)addr;
>>> +   args[1] = val;
>>> +   ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
>>
>> Hmm, so you're just using misc_ops to still issue generic writes. From the
>> discussion with Marek in the last version, I would have thought you wanted to
>> create a higher level API instead of still tunnelling reads and writes?

Any response to this?

Thanks,
Simon

>>
>> In my gen5 series to abstract the gen5 sysmgr, I have used 'ioctl' and 
>> 'call' from
>> misc_ops to have an API.
>>
>> Regards,
>> Simon
>>
>>> +   if (ret)
>>> +   return -EIO;
>>> +
>>> +   return 0;
>>> +}
>>> +#endif
>>> +
>>> +static int write32(u32 val, fdt_addr_t addr) { #if
>>> +!defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
>>> +   return secure_write32(val, addr);
>>> +#else
>>> +   writel(val, addr);
>>> +
>>> +   return 0;
>>> +#endif
>>> +}
>>> +
>>> +static int altera_sysmgr_read(struct udevice *dev,
>>> +  

Re: [PATCH v4 14/21] arch: arm: socfpga: Add 'altr, sysmgr-syscon' for MMC node in device tree

[Simon Goldschmidt]

Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> From: Chee Hong Ang 
> 
> In device tree for all socfpga platforms, a phandle to System Manager
> ('altr,sysmgr-syscon') is needed for MMC node to enable the MMC driver
> to configure the SDMMC's clock phase shift via System Manager driver
> (altera_sysmgr).
> This phandle specifies the offset of the SDMCC control register in
> System Manager, start of bit field for drvsel and start of bit field
> for smplsel.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi| 1 +
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 1 +
>  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi| 1 +
>  arch/arm/dts/socfpga_cyclone5.dtsi   | 1 +
>  arch/arm/dts/socfpga_stratix10.dtsi  | 1 -
>  arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 7 +++
>  arch/arm/dts/socfpga_stratix10_socdk.dts | 2 --

This looks strange. I would have expected you add the 'syscon' entry to
the base dtsi files (and to the ones in Linux, too, btw). But you're
adding it to "-u-boot.dtsi" files, too. Why?

Regards,
Simon

>  7 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi 
> b/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> index 1908be4..56fd7d9 100644
> --- a/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> @@ -34,6 +34,7 @@
>   {
>   drvsel = <3>;
>   smplsel = <0>;
> + altr,sysmgr-syscon = < 0x28 0 4>;
>   u-boot,dm-pre-reloc;
>  };
>  
> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts 
> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> index d6b6c2d..887673b 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> @@ -44,6 +44,7 @@
>   cap-sd-highspeed;
>   broken-cd;
>   bus-width = <4>;
> + altr,sysmgr-syscon = < 0x28 0 4>;
>  };
>  
>   {
> diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> index dfaff4c..d2189f1 100644
> --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> @@ -20,6 +20,7 @@
>  };
>  
>   {
> + altr,sysmgr-syscon = < 0x108 0 3>;
>   u-boot,dm-pre-reloc;
>  };
>  
> diff --git a/arch/arm/dts/socfpga_cyclone5.dtsi 
> b/arch/arm/dts/socfpga_cyclone5.dtsi
> index 319a71e..c309681 100644
> --- a/arch/arm/dts/socfpga_cyclone5.dtsi
> +++ b/arch/arm/dts/socfpga_cyclone5.dtsi
> @@ -23,6 +23,7 @@
>   bus-width = <4>;
>   cap-mmc-highspeed;
>   cap-sd-highspeed;
> + altr,sysmgr-syscon = < 0x108 0 3>;
>   };
>  
>   sysmgr@ffd08000 {
> diff --git a/arch/arm/dts/socfpga_stratix10.dtsi 
> b/arch/arm/dts/socfpga_stratix10.dtsi
> index a8e61cf..9c89065 100755
> --- a/arch/arm/dts/socfpga_stratix10.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> @@ -228,7 +228,6 @@
>   interrupts = <0 96 4>;
>   fifo-depth = <0x400>;
>   resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> - u-boot,dm-pre-reloc;
>   status = "disabled";
>   };
>  
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi 
> b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> index a903040..ca91b40 100755
> --- a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> @@ -28,6 +28,13 @@
>   u-boot,dm-pre-reloc;
>  };
>  
> + {
> + drvsel = <3>;
> + smplsel = <0>;
> + altr,sysmgr-syscon = < 0x28 0 4>;
> + u-boot,dm-pre-reloc;
> +};
> +
>   {
>   u-boot,dm-pre-reloc;
>  };
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> index b7b48a5..ff6e1b2 100755
> --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -91,8 +91,6 @@
>   cap-mmc-highspeed;
>   broken-cd;
>   bus-width = <4>;
> - drvsel = <3>;
> - smplsel = <0>;
>  };
>  
>   {
> 

Re: [PATCH v4 12/21] arch: arm: socfpga: Enable driver model for misc drivers.

[Simon Goldschmidt]

Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> From: Chee Hong Ang 
> 
> Enable this misc driver model for 'altera_sysmgr' driver for
> socfpga platforms.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  arch/arm/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8d9f7fc..4ee8ae0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -937,9 +937,11 @@ config ARCH_SOCFPGA
>   select DM
>   select DM_SERIAL
>   select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || 
> TARGET_SOCFPGA_ARRIA10
> + select MISC

Please don't 'select' this. You prevent building smaller configs that
don't need it. Please use 'imply' instead.

>   select OF_CONTROL
>   select SPL_DM_RESET if DM_RESET
>   select SPL_DM_SERIAL
> + select SPL_DRIVERS_MISC_SUPPORT

Especially this one makes gen5 SPL uneccessary large.

Regards,
Simon

>   select SPL_LIBCOMMON_SUPPORT
>   select SPL_LIBGENERIC_SUPPORT
>   select SPL_NAND_SUPPORT if SPL_NAND_DENALI
> 

Re: [PATCH v4 00/21] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> From: "Ang, Chee Hong" 
> 
> v4 changes:
> [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager
> - Add System Manager driver (UCLASS_MISC) to handle secure access for SoC64
> 
> [PATCH v4 13/21] mmc: dwmmc: socfpga: MMC driver access System Manager via 
> 'altera_sysmgr'
> - DW MMC driver access System Manager via the System Manager driver
> 
> [PATCH v4 14/21] arch: arm: socfpga: Add 'altr,sysmgr-syscon' for MMC
> - DW MMC driver get DRVSEL & SMPLSEL clock settings from device tree
> 
> [PATCH v4 15/21] net: designware: socfpga: MAC driver access System via 
> 'altera_sysmgr'
> - DW MAC driver access System Manager via the System Manager driver
> 
> v3:
> https://lists.denx.de/pipermail/u-boot/2020-February/400986.html
> 
> These patchsets have dependency on:
> https://lists.denx.de/pipermail/u-boot/2019-September/384906.html
> 
> Chee Hong Ang (21):
>   configs: agilex: Remove CONFIG_OF_EMBED
>   arm: socfpga: add fit source file for pack itb with ATF
>   arm: socfpga: Add function for checking description from FIT image
>   arm: socfpga: Load FIT image with ATF support
>   arm: socfpga: Override 'lowlevel_init' to support ATF
>   configs: socfpga: Enable FIT image loading with ATF support
>   arm: socfpga: Disable "spin-table" method for booting Linux
>   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
>   arm: socfpga: Define SMC function identifiers for PSCI SiP services
>   arm: socfpga: soc64: Remove PHY interface setup from misc arch init
>   misc: altera_sysmgr: Add Altera System Manager driver
>   arch: arm: socfpga: Enable driver model for misc drivers.
>   mmc: dwmmc: socfpga: MMC driver access System Manager via
> 'altera_sysmgr'
>   arch: arm: socfpga: Add 'altr,sysmgr-syscon' for MMC node in device
> tree
>   net: designware: socfpga: MAC driver access System Manager via
> 'altera_sysmgr'
>   arm: socfpga: Add ATF support for Reset Manager driver
>   arm: socfpga: stratix10: Initialize timer in SPL
>   arm: socfpga: Add ATF support to query FPGA configuration status
>   arm: socfpga: stratix10: Add ATF support for FPGA reconfig driver
>   arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
> mbox_reset_cold()
>   configs: socfpga: Add defconfig for Agilex and Stratix 10 without ATF
> support

Are you sure building all previously existing defconfigs keeps working
with every single commit here? If not, that would break 'git bisect' in
the future...

I have the feeling that things might be broken in between - escpecially
since you're adding the 'old' "without ATF" defconfig in the last patch.
I think it would make more sense to keep the old defconfig name, keep it
building correctly throughout this series and add a "with ATF" defconfig
at the end. That way, you ensure existing usages keep working.

Regards,
Simon

> 
>  arch/arm/Kconfig   |   2 +
>  arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi  |   1 +
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |   1 +
>  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi  |   1 +
>  arch/arm/dts/socfpga_cyclone5.dtsi |   1 +
>  arch/arm/dts/socfpga_stratix10.dtsi|   1 -
>  arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi   |   7 +
>  arch/arm/dts/socfpga_stratix10_socdk.dts   |   2 -
>  arch/arm/mach-socfpga/Kconfig  |   2 -
>  arch/arm/mach-socfpga/Makefile |   2 +
>  arch/arm/mach-socfpga/board.c  |  10 +
>  arch/arm/mach-socfpga/include/mach/misc.h  |   3 +
>  arch/arm/mach-socfpga/lowlevel_init_64.S   |  81 +
>  arch/arm/mach-socfpga/mailbox_s10.c|   4 +
>  arch/arm/mach-socfpga/misc_s10.c   | 121 ++-
>  arch/arm/mach-socfpga/reset_manager_s10.c  |  10 +
>  arch/arm/mach-socfpga/timer_s10.c  |   3 +-
>  board/altera/soc64/its/fit_spl_atf.its |  52 +++
>  configs/socfpga_agilex_defconfig   |   8 +-
>  ...lex_defconfig => socfpga_agilex_nofw_defconfig} |   2 +-
>  configs/socfpga_stratix10_defconfig|   7 +-
>  ..._defconfig => socfpga_stratix10_nofw_defconfig} |   2 +-
>  drivers/fpga/stratix10.c   | 141 +++-
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/altera_sysmgr.c   | 115 ++
>  drivers/mmc/socfpga_dw_mmc.c   |  63 +++-
>  drivers/net/dwmac_socfpga.c|  37 +-
>  include/configs/socfpga_soc64_common.h |   4 +
>  include/linux/intel-smc.h  | 393 
> +
>  29 files changed, 955 insertions(+), 122 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/lowlevel_init_64.S
>  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>  copy configs/{socfpga_agilex_defconfig => 

Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver

[Simon Goldschmidt]

Am 10.03.2020 um 17:42 schrieb Ang, Chee Hong:
>> -Original Message-
>> From: Simon Goldschmidt 
>> Sent: Wednesday, March 11, 2020 12:17 AM
>> To: Ang, Chee Hong 
>> Cc: u-boot@lists.denx.de; Marek Vasut ; See, Chin Liang
>> ; Tan, Ley Foon ;
>> Westergreen, Dalon ; Gong, Richard
>> 
>> Subject: Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager
>> driver
>>
>> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
>>> From: Chee Hong Ang 
>>>
>>> This driver (misc uclass) handle the read/write access to System
>>> Manager. For 64 bits platforms, processor needs to be in secure mode
>>> to has write access to most of the System Manager's registers (except
>>> boot scratch registers). When the processor is running in EL2
>>> (non-secure), this driver will invoke the SMC call to ATF to perform
>>> write access to the System Manager's registers.
>>> All other drivers that require access to System Manager should go
>>> through this driver.
>>>
>>> Signed-off-by: Chee Hong Ang 
>>> ---
>>>  drivers/misc/Makefile|   1 +
>>>  drivers/misc/altera_sysmgr.c | 115
>>> +++
>>>  2 files changed, 116 insertions(+)
>>>  create mode 100644 drivers/misc/altera_sysmgr.c
>>>
>>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
>>> 2b843de..9fa2411 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -29,6 +29,7 @@ endif
>>>  endif
>>>  obj-$(CONFIG_ALI152X) += ali512x.o
>>>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
>>> +obj-$(CONFIG_ARCH_SOCFPGA) += altera_sysmgr.o
>>>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>>>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>>>  obj-$(CONFIG_DS4510)  += ds4510.o
>>> diff --git a/drivers/misc/altera_sysmgr.c
>>> b/drivers/misc/altera_sysmgr.c new file mode 100644 index
>>> 000..b36ecae
>>> --- /dev/null
>>> +++ b/drivers/misc/altera_sysmgr.c
>>
>> I think this file should have something in the name specifying it is for 
>> s10/agilex.
>> I will post a misc/sysmgr for gen5 that needs a specific name, too
> Gen5/A10/S10/Agilex are using same DW MMC/MAC drivers and these drivers 
> access system manager.
> Therefore, this driver is enabled for all platforms. Gen5/A10, S10/Agilex all 
> are using it.

Ah, I missed that part of the series. I'm still reading it. Making gen5
use misc_read/misc_write seems a bit strange, but I can't think of a
better way right now, either...

> Can I know what does your gen5 sysmgr driver do ?

I moved "pin init", "freezereq" and "get fpga ID" there to have less
ad-hoc code in the main SPL file...

The series where it's in targets moving as much as I can to DM drivers.
Sadly, I still haven't found a way to make it fit into the gen5 SRAM,
which is why I haven't posted it, yet...

> I can change the name to avoid conflict but Gen5 will have 2 sysmgr drivers 
> for different purposes.
> Are you OK with that ?

Hmm, I don't think that will work. That would mean binding 2 drivers to
one ofnode. I can split the gen5 driver later and implement read/write
like it's needed if this one gets applied as is.

>>
>>> @@ -0,0 +1,115 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2020 Intel Corporation   */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define IS_OUT_OF_SYSMGR(addr, range) ((addr) > (range))
>>> +
>>> +struct altera_sysmgr_priv {
>>> +   fdt_addr_t base_addr;
>>> +   fdt_addr_t base_size;
>>> +};
>>> +
>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) static int
>>> +secure_write32(u32 val, fdt_addr_t addr) {
>>> +   int ret;
>>> +   u64 args[2];
>>> +
>>> +   args[0] = (u64)addr;
>>> +   args[1] = val;
>>> +   ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
>>
>> Hmm, so you're just using misc_ops to still issue generic writes. From the
>> discussion with Marek in the last version, I would have thought you wanted to
>> create a higher level API instead of still tunnelling reads and writes?
>>
>> In my gen5 series to abstract the gen5 sysmgr, I have used 'ioctl' and 
>> 'call' from
>> misc_o

Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver

[Simon Goldschmidt]

Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> From: Chee Hong Ang 
> 
> This driver (misc uclass) handle the read/write access to
> System Manager. For 64 bits platforms, processor needs to be
> in secure mode to has write access to most of the System Manager's
> registers (except boot scratch registers). When the processor is
> running in EL2 (non-secure), this driver will invoke the SMC call
> to ATF to perform write access to the System Manager's registers.
> All other drivers that require access to System Manager should
> go through this driver.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  drivers/misc/Makefile|   1 +
>  drivers/misc/altera_sysmgr.c | 115 
> +++
>  2 files changed, 116 insertions(+)
>  create mode 100644 drivers/misc/altera_sysmgr.c
> 
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 2b843de..9fa2411 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -29,6 +29,7 @@ endif
>  endif
>  obj-$(CONFIG_ALI152X) += ali512x.o
>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
> +obj-$(CONFIG_ARCH_SOCFPGA) += altera_sysmgr.o
>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>  obj-$(CONFIG_DS4510)  += ds4510.o
> diff --git a/drivers/misc/altera_sysmgr.c b/drivers/misc/altera_sysmgr.c
> new file mode 100644
> index 000..b36ecae
> --- /dev/null
> +++ b/drivers/misc/altera_sysmgr.c

I think this file should have something in the name specifying it is for
s10/agilex. I will post a misc/sysmgr for gen5 that needs a specific
name, too

> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Intel Corporation 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IS_OUT_OF_SYSMGR(addr, range) ((addr) > (range))
> +
> +struct altera_sysmgr_priv {
> + fdt_addr_t base_addr;
> + fdt_addr_t base_size;
> +};
> +
> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
> +static int secure_write32(u32 val, fdt_addr_t addr)
> +{
> + int ret;
> + u64 args[2];
> +
> + args[0] = (u64)addr;
> + args[1] = val;
> + ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);

Hmm, so you're just using misc_ops to still issue generic writes. From
the discussion with Marek in the last version, I would have thought you
wanted to create a higher level API instead of still tunnelling reads
and writes?

In my gen5 series to abstract the gen5 sysmgr, I have used 'ioctl' and
'call' from misc_ops to have an API.

Regards,
Simon

> + if (ret)
> + return -EIO;
> +
> + return 0;
> +}
> +#endif
> +
> +static int write32(u32 val, fdt_addr_t addr)
> +{
> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
> + return secure_write32(val, addr);
> +#else
> + writel(val, addr);
> +
> + return 0;
> +#endif
> +}
> +
> +static int altera_sysmgr_read(struct udevice *dev,
> +  int offset, void *buf, int size)
> +{
> + struct altera_sysmgr_priv *priv = dev_get_priv(dev);
> + fdt_addr_t addr = priv->base_addr + offset;
> +
> + if (IS_OUT_OF_SYSMGR(addr, priv->base_addr + priv->base_size - size))
> + return -EINVAL;
> +
> + if (size != sizeof(u32))
> + return -EIO;
> +
> + *(u32 *)buf = readl(addr);
> +
> + return 0;
> +}
> +
> +static int altera_sysmgr_write(struct udevice *dev, int offset,
> + const void *buf, int size)
> +{
> + struct altera_sysmgr_priv *priv = dev_get_priv(dev);
> + fdt_addr_t addr = priv->base_addr + offset;
> +
> + if (IS_OUT_OF_SYSMGR(addr, priv->base_addr + priv->base_size - size))
> + return -EINVAL;
> +
> + if (size != sizeof(u32))
> + return -EIO;
> +
> + return write32(*(u32 *)buf, addr);
> +}
> +
> +static int altera_sysmgr_probe(struct udevice *dev)
> +{
> + struct altera_sysmgr_priv *priv = dev_get_priv(dev);
> + fdt_addr_t addr;
> + fdt_size_t size;
> +
> + addr = ofnode_get_addr_size_index(dev_ofnode(dev), 0, );
> +
> + if (addr == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->base_addr = addr;
> + priv->base_size = size;
> +
> + return 0;
> +}
> +
> +static const struct misc_ops altera_sysmgr_ops = {
> + .read = altera_sysmgr_read,
> + .write = altera_sysmgr_write,
> +};
> +
> +static const struct udevice_id altera_sysmgr_ids[] = {
> + { .compatible = "altr,sys-mgr" },
> + {}
> +};
> +
> +U_BOOT_DRIVER(altera_sysmgr) = {
> + .name   = "altr,sys-mgr",
> + .id = UCLASS_MISC,
> + .of_match = altera_sysmgr_ids,
> + .priv_auto_alloc_size = sizeof(struct altera_sysmgr_priv),
> + .probe = altera_sysmgr_probe,
> + .ops= _sysmgr_ops,
> +};
> 

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Mon, Mar 9, 2020 at 3:15 PM Marek Vasut  wrote:
>
> On 3/9/20 3:10 PM, Simon Goldschmidt wrote:
> > On Mon, Mar 9, 2020 at 1:57 PM Marek Vasut  wrote:
> >>
> >> On 3/9/20 9:50 AM, Ley Foon Tan wrote:
> >>> On Thu, Feb 13, 2020 at 2:52 AM Dalon L Westergreen
> >>>  wrote:
> >>>>
> >>>> I am reading through this thread, and want to point out that it is not 
> >>>> that the
> >>>> FPGA bridge need be actively used in the fpga, but
> >>>> rather that this port be configured in the FPGA configuration.  This is 
> >>>> an
> >>>> important distinction, ecery FPGA design that
> >>>> instantiates the HPS does configure the F2S Bridge.  it drives select 
> >>>> pins,
> >>>> control pins, data pins, etc, on the interface to known values,
> >>>> and so the apply can always be done as all SoC FPGA designs have the soc
> >>>> instantiated.  If someone boots the arm, and uses an
> >>>> FPGA design without having the soc instantiated, it may then cause 
> >>>> issues, but i
> >>>> would argue that is not a supported use
> >>>> in the first place.
> >>>>
> >>>> --dalon
> >>>>
> >>>
> >>> I can reproduce the issue if without setting applycfg bit. Access to
> >>> F2sdram interface will cause system hang.
> >>>
> >>> From the Cyclone 5 Soc datasheet:
> >>> applycfg - Write with this bit set to apply all the settings loaded in
> >>> SDR registers to the memory interface. This bit is write-only and
> >>> always returns 0 if read.
> >>>
> >>> Software should set applycfg bit if change any register under SDR
> >>> register range. SW is allowed to set this bit multiple times, the only
> >>> condition is SDRAM need to be idle.
> >>> My suggestion is we add back socfpga_sdram_apply_static_cfg(), but
> >>> change the sequence to below:
> >>> writel(iswgrp_handoff[3], _ctrl->fpgaport_rst);
> >>> socfpga_sdram_apply_static_cfg();
> >>>
> >>> Marek and Simon, are you okay with this? If yes, I will submit patch for 
> >>> this.
> >>
> >> The problem was that this was causing weird sporadic hangs on Gen5,
> >> which is why it was removed. So until there is an explanation for those
> >> hangs, I'm not really OK with this.
> >
> > These sporadic hangs you saw were on devices without an FPGA image directly
> > accessing the SDRAM ports, right?
>
> Yes
>
> >> Maybe the application of static config should happen in SPL, before the
> >> DRAM is running, or something like that ?
> >
> > Thinking this further, limiting it to applying in SPL is not a good idea 
> > since
> > that prevents us from implementing different FPGA images/configs by loading 
> > a
> > config later in the boot (i.e. in U-Boot from a FIT-image).
>
> Well, but later we have SDRAM running and we cannot make it go idle, can we?
>
> > Would it work to make setting this optional, i.e. only write the bit if an 
> > FPGA
> > config actually uses these ports? Then it couldn't lead to problems on other
> > hardware...
>
> Can you make SDRAM bus really idle ?

>From the CPU side, that should work, no? Of course you have to make sure no
other peripheraly (including FPGA!) are using the RAM.

And if this would be an explicit command, people needing this could
experiment with it - and hopefully give better hints as to what's going wrong
if we *do* see problems again.

Regards,
Simon

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Mon, Mar 9, 2020 at 1:57 PM Marek Vasut  wrote:
>
> On 3/9/20 9:50 AM, Ley Foon Tan wrote:
> > On Thu, Feb 13, 2020 at 2:52 AM Dalon L Westergreen
> >  wrote:
> >>
> >> I am reading through this thread, and want to point out that it is not 
> >> that the
> >> FPGA bridge need be actively used in the fpga, but
> >> rather that this port be configured in the FPGA configuration.  This is an
> >> important distinction, ecery FPGA design that
> >> instantiates the HPS does configure the F2S Bridge.  it drives select pins,
> >> control pins, data pins, etc, on the interface to known values,
> >> and so the apply can always be done as all SoC FPGA designs have the soc
> >> instantiated.  If someone boots the arm, and uses an
> >> FPGA design without having the soc instantiated, it may then cause issues, 
> >> but i
> >> would argue that is not a supported use
> >> in the first place.
> >>
> >> --dalon
> >>
> >
> > I can reproduce the issue if without setting applycfg bit. Access to
> > F2sdram interface will cause system hang.
> >
> > From the Cyclone 5 Soc datasheet:
> > applycfg - Write with this bit set to apply all the settings loaded in
> > SDR registers to the memory interface. This bit is write-only and
> > always returns 0 if read.
> >
> > Software should set applycfg bit if change any register under SDR
> > register range. SW is allowed to set this bit multiple times, the only
> > condition is SDRAM need to be idle.
> > My suggestion is we add back socfpga_sdram_apply_static_cfg(), but
> > change the sequence to below:
> > writel(iswgrp_handoff[3], _ctrl->fpgaport_rst);
> > socfpga_sdram_apply_static_cfg();
> >
> > Marek and Simon, are you okay with this? If yes, I will submit patch for 
> > this.
>
> The problem was that this was causing weird sporadic hangs on Gen5,
> which is why it was removed. So until there is an explanation for those
> hangs, I'm not really OK with this.

These sporadic hangs you saw were on devices without an FPGA image directly
accessing the SDRAM ports, right?

>
> Maybe the application of static config should happen in SPL, before the
> DRAM is running, or something like that ?

Thinking this further, limiting it to applying in SPL is not a good idea since
that prevents us from implementing different FPGA images/configs by loading a
config later in the boot (i.e. in U-Boot from a FIT-image).

Would it work to make setting this optional, i.e. only write the bit if an FPGA
config actually uses these ports? Then it couldn't lead to problems on other
hardware...

Regards,
Simon

Re: [PATCH v5 1/5] dm: clk: add stub when CONFIG_CLK is deactivated

[Simon Goldschmidt]

On Fri, Mar 6, 2020 at 11:01 AM Patrick Delaunay
 wrote:
>
> Add stub for functions clk_...() when CONFIG_CLK is deactivated.
>
> This patch avoids compilation issues for driver using these API
> without protection (#if CONFIG_IS_ENABLED(CLK))
>
> For example, before this patch we have undefined reference to
> `clk_disable_bulk') for code:
>   clk_disable_bulk(>clks);
>   clk_release_bulk(>clks);
>
> The bulk stub set and test bulk->count to avoid error for the sequence:
>
>   clk_get_bulk(dev, >bulk);
> 
>   if (clk_enable(>bulk))
> return -EIO;
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v5:
> - use ERR_PTR in clk_get_parent()
> - force bulk->count = 0 in clk_get_bulk to avoid issue
>   for next call of clk_enable_bulk / clk_enable_bulk

I wonder if this is correct. I think it only produces additional code. If you
always set bulk->count to 0, the enable code will never fail.

However, the enable function should never be executed as enable returns an
error. I can imagine the *disable* function could be called, but the return
value of this function is currently only handled in clk_sandbox_test.c...

Wouldn't it work to just remove all checks for bulk->count and let *all*
redefined functions return a constant (success or failure)? That would help
to keep the code small.

Looking at linux, clock disable functions have *no* return value that needs
to be checked, clock enable functions return success when compiled without
clock support.

Regards,
Simon

> - update commit message
>
> Changes in v4:
> - Add stub for all functions using 'struct clk' or 'struct clk_bulk'
>   after remarks on v3
>
> Changes in v3:
> - Add stub for clk_disable_bulk
>
> Changes in v2: None
>
>  include/clk.h | 104 +++---
>  1 file changed, 91 insertions(+), 13 deletions(-)
>
> diff --git a/include/clk.h b/include/clk.h
> index 3336301815..ca8f1cfec7 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -9,6 +9,7 @@
>  #define _CLK_H_
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -249,6 +250,8 @@ static inline int clk_get_by_index(struct udevice *dev, 
> int index,
>
>  static inline int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
>  {
> +   if (bulk)
> +   bulk->count = 0;
> return -ENOSYS;
>  }
>
> @@ -312,6 +315,7 @@ static inline int clk_release_bulk(struct clk_bulk *bulk)
> return clk_release_all(bulk->clks, bulk->count);
>  }
>
> +#if CONFIG_IS_ENABLED(CLK)
>  /**
>   * clk_request - Request a clock by provider-specific ID.
>   *
> @@ -433,19 +437,6 @@ int clk_disable_bulk(struct clk_bulk *bulk);
>   */
>  bool clk_is_match(const struct clk *p, const struct clk *q);
>
> -int soc_clk_dump(void);
> -
> -/**
> - * clk_valid() - check if clk is valid
> - *
> - * @clk:   the clock to check
> - * @return true if valid, or false
> - */
> -static inline bool clk_valid(struct clk *clk)
> -{
> -   return clk && !!clk->dev;
> -}
> -
>  /**
>   * clk_get_by_id() - Get the clock by its ID
>   *
> @@ -465,6 +456,93 @@ int clk_get_by_id(ulong id, struct clk **clkp);
>   * @return true on binded, or false on no
>   */
>  bool clk_dev_binded(struct clk *clk);
> +
> +#else /* CONFIG_IS_ENABLED(CLK) */
> +
> +static inline int clk_request(struct udevice *dev, struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline int clk_free(struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline ulong clk_get_rate(struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline struct clk *clk_get_parent(struct clk *clk)
> +{
> +   return ERR_PTR(-ENOSYS);
> +}
> +
> +static inline long long clk_get_parent_rate(struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline ulong clk_set_rate(struct clk *clk, ulong rate)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline int clk_enable(struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline int clk_enable_bulk(struct clk_bulk *bulk)
> +{
> +   return bulk && bulk->count == 0 ? 0 : -ENOSYS;
> +}
> +
> +static inline int clk_disable(struct clk *clk)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline int clk_disable_bulk(struct clk_bulk *bulk)
> +{
> +   return bulk && bulk->count == 0 ? 0 : -ENOSYS;
> +}
> +
> +static inline bool clk_is_match(const struct clk *p, const struct clk *q)
> +{
> +   return false;
> +}
> +
> +static inline int clk_get_by_id(ulong id, struct clk **clkp)
> +{
> +   return -ENOSYS;
> +}
> +
> +static inline bool clk_dev_binded(struct clk *clk)
> +{
> +   return false;
> +}
> +#endif /* CONFIG_IS_ENABLED(CLK) */
> +
> +/**
> + * clk_valid() - check if clk is valid
> + *
> + * @clk:   the clock to check
> + * @return true if valid, or false
> + */
> +static inline bool clk_valid(struct clk *clk)
> +{
> +   return clk 

Re: [PATCH] net: phy: Fix overlong PHY timeout

[Simon Goldschmidt]

On Fri, Feb 21, 2020 at 5:33 PM Matthias Brugger  wrote:
>
> Hi Joe,
>
> On 30/01/2020 12:00, Matthias Brugger wrote:
> >
> >
> > On 03/01/2020 23:08, Andre Przywara wrote:
> >> Commit 27c3f70f3b50 ("net: phy: Increase link up delay in
> >> genphy_update_link()") increased the per-iteration waiting time from
> >> 1ms to 50ms, without adjusting the timeout counter. This lead to the
> >> timeout increasing from the typical 4 seconds to over three minutes.
> >>
> >> Adjust the timeout counter evaluation by that factor of 50 to bring the
> >> timeout back to the intended value.
> >>
> >> Signed-off-by: Andre Przywara 

A "Fixes:" tag would have been nice...

Anyway:
Tested-by: Simon Goldschmidt 

> >
> > I tested this on RPi4 with the genet patches on top. Now the timeout is
> > reasonable :)
> >
> > Tested-by: Matthias Brugger 
> >
>
> Friedly reminder, are you planning to take this fix for v2020.04?

Yes, please! This timeout is really annoying right now!

Regards,
Simon

>
> Regards,
> Matthias
>
> >> ---
> >>  drivers/net/phy/phy.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> >> index 80a7664e49..5cf9c165b6 100644
> >> --- a/drivers/net/phy/phy.c
> >> +++ b/drivers/net/phy/phy.c
> >> @@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
> >>  /*
> >>   * Timeout reached ?
> >>   */
> >> -if (i > PHY_ANEG_TIMEOUT) {
> >> +if (i > (PHY_ANEG_TIMEOUT / 50)) {
> >>  printf(" TIMEOUT !\n");
> >>  phydev->link = 0;
> >>  return -ETIMEDOUT;
> >>
>

Re: [PATCH] net: phy: fix autoneg timeout

[Simon Goldschmidt]

On Thu, Mar 5, 2020 at 5:40 AM Stefan Roese  wrote:
>
> Hi Simon,
>
> On 04.03.20 21:12, Simon Goldschmidt wrote:
> > Recently, genphy_update_link() has been changed to use a 50ms polling
> > interval instead of the previous 1ms. However, the timeout to give up
> > waiting for a link remained unchanged, calculating the iterations.
> >
> > As a result, PHY_ANEG_TIMEOUT now specifies "multiples of 50ms" instead
> > of just to be a number of milliseconds.
> >
> > Fix this by dividing PHY_ANEG_TIMEOUT by 50 in this loop. This gets us
> > back to a 4 seconds timeout for the default value (instead of 200s).
> >
> > Fixes: net: phy: Increase link up delay in genphy_update_link() 
> > ("27c3f70f3b50")
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > This should be applied before the next release as it fixes a regression
> > of v2020.01!
> >
> >   drivers/net/phy/phy.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> > index 80a7664e49..5cf9c165b6 100644
> > --- a/drivers/net/phy/phy.c
> > +++ b/drivers/net/phy/phy.c
> > @@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
> >   /*
> >* Timeout reached ?
> >*/
> > - if (i > PHY_ANEG_TIMEOUT) {
> > + if (i > (PHY_ANEG_TIMEOUT / 50)) {
> >   printf(" TIMEOUT !\n");
> >   phydev->link = 0;
> >   return -ETIMEDOUT;
> >
>
> A similar fix from Andre for this is queued for this for quite some
> time now:
>
> https://patchwork.ozlabs.org/patch/1217524/

Right. I thought I remembered a patch but hadn't found it...

I'll drop this one then.

Regards,
Simon

>
> Joe or Tom, could you please take this one?
>
> Thanks,
> Stefan

Re: [PATCH 1/8] malloc: implement USE_DL_PREFIX via inline functions

[Simon Goldschmidt]

Am 20.02.2020 um 04:05 schrieb Simon Glass:
> On Wed, 19 Feb 2020 at 12:39, Simon Goldschmidt
>  wrote:
>>
>> Commit cfda60f99ae2 ("sandbox: Use a prefix for all allocation functions")
>> introduced preprocessor macros for malloc/free etc.
>>
>> This is bad practice as it essentially makes 'free' a reserved keyword and
>> resulted in quite a bit of renaming to avoid that reserved keyword.
>>
>> A better solution is to define the allocation functions as 'static inline'.
>>
>> As a side effect, exports.h must not export malloc/free for sandbox.
>>
>> Signed-off-by: Simon Goldschmidt 
>> ---
>>
>> A side-effect is that exports.h may not declare malloc/free. I'm not really
>> sure if this is correct, but for sandbox, it should probably be ok?
> 
> Is it possible to fix this? E.g. don't use inline for these two
> functions on sandbox?

Not using inline for sandbox for these two is *not* an option as these
two are exactly the ones offending globally known names.

I guess we have to know what we want here: what is exports.h meant for?
To me it looks like it is meant for "U-Boot API" applications to link
against. If so, why is it included in U-Boot sources (in over 20 files)?

I guess one solution would be to move (or copy) the DL prefix handling
into exports.h and _exports.h so that applications linking with
exports.h implicily call dlmalloc/dlfree, not malloc/free (which would
be the OS versions for sandbox).

I'll try to prepare v2 in that direction, but I'm still not unsure since
exports.h is included in internal U-Boot code.

Regards,
Simon

> 
>>
>>  include/_exports.h |  2 ++
>>  include/exports.h  |  2 ++
>>  include/malloc.h   | 44 +---
>>  3 files changed, 33 insertions(+), 15 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 

Re: [PATCH 2/8] Revert "mtd: Rename free() to rfree()"

[Simon Goldschmidt]

Am 19.02.2020 um 21:04 schrieb Fabio Estevam:
> On Wed, Feb 19, 2020 at 4:40 PM Simon Goldschmidt
>  wrote:
>>
>> This reverts commit 8d38a8459b0de45f5ff41f3e11c278a5cf395fd0.
> 
> You missed to explain the reason for the revert.

Yes, I'll fix that in v2.

Regards,
Simon

[PATCH] net: phy: fix autoneg timeout

[Simon Goldschmidt]

Recently, genphy_update_link() has been changed to use a 50ms polling
interval instead of the previous 1ms. However, the timeout to give up
waiting for a link remained unchanged, calculating the iterations.

As a result, PHY_ANEG_TIMEOUT now specifies "multiples of 50ms" instead
of just to be a number of milliseconds.

Fix this by dividing PHY_ANEG_TIMEOUT by 50 in this loop. This gets us
back to a 4 seconds timeout for the default value (instead of 200s).

Fixes: net: phy: Increase link up delay in genphy_update_link() ("27c3f70f3b50")
Signed-off-by: Simon Goldschmidt 
---

This should be applied before the next release as it fixes a regression
of v2020.01!

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

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 80a7664e49..5cf9c165b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
/*
 * Timeout reached ?
 */
-   if (i > PHY_ANEG_TIMEOUT) {
+   if (i > (PHY_ANEG_TIMEOUT / 50)) {
printf(" TIMEOUT !\n");
phydev->link = 0;
return -ETIMEDOUT;
-- 
2.20.1

Re: [PATCH v4 0/5] usb: host: dwc2: use driver model for PHY and CLOCK

[Simon Goldschmidt]

Am 19.02.2020 um 08:27 schrieb Simon Goldschmidt:
> On Tue, Feb 18, 2020 at 6:53 PM Marek Vasut  wrote:
>>
>> On 2/18/20 9:34 AM, Patrick Delaunay wrote:
>>>
>>> In this serie I update the DWC2 host driver to use the device tree
>>> information and the associated PHY and CLOCK drivers when they are
>>> availables.
>>>
>>> The V4 is rebased on latest master (v2020.04-rc2).
>>> CI-Tavis build is OK:
>>> https://travis-ci.org/patrickdelaunay/u-boot/builds/651479714
>>>
>>> NB: CI-Travis build was OK for all target after V3:
>>> https://travis-ci.org/patrickdelaunay/u-boot/builds/609496187
>>> As in V2, I cause the warnings for some boards:
>>> drivers/usb/host/built-in.o: In function `dwc2_usb_remove':
>>> drivers/usb/host/dwc2.c:1441: undefined reference to `clk_disable_bulk'
>>>
>>> I test this serie on stm32mp157c-ev1 board, with PHY and CLK
>>> support
>>>
>>> The U-CLASS are provided by:
>>> - PHY by USBPHYC driver = ./drivers/phy/phy-stm32-usbphyc.c
>>> - CLOCK by RCC clock driver = drivers/clk/clk_stm32mp1.c
>>> - RESET by RCC reset driver = drivers/reset/stm32-reset.c
>>>
>>> And I activate the configuration
>>> +CONFIG_USB_DWC2=y
>>
>> Simon, can you test this on SOCFPGA ?
> 
> I can test if it probes, but I don't have anything running on that USB port
> the socfpga_socrates board has. Would that be enought to test?

Tested the whole series on socfpga_socrates by instantiating the driver.
Shows the same behaviour as before (I still have no OTG cable to test
attaching a storage device).

Regards,
Simon

> 
> Regards,
> Simon
> 
>>
>> [...]

Re: [PATCH v4 3/5] usb: host: dwc2: add clk support

[Simon Goldschmidt]

Am 18.02.2020 um 09:35 schrieb Patrick Delaunay:
> Add support for clock with driver model.
> 
> This patch don't added dependency because when CONFIG_CLK
> is not activated the clk function are stubbed.
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Simon Goldschmidt 

> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/usb/host/dwc2.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index 5e7ffaddd9..d56d0e61b5 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -5,14 +5,15 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -39,6 +40,7 @@ struct dwc2_priv {
>   struct udevice *vbus_supply;
>  #endif
>   struct phy phy;
> + struct clk_bulk clks;
>  #else
>   uint8_t *aligned_buffer;
>   uint8_t *status_buffer;
> @@ -1377,6 +1379,26 @@ static int dwc2_shutdown_phy(struct udevice *dev)
>   return 0;
>  }
>  
> +static int dwc2_clk_init(struct udevice *dev)
> +{
> + struct dwc2_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = clk_get_bulk(dev, >clks);
> + if (ret == -ENOSYS || ret == -ENOENT)
> + return 0;
> + if (ret)
> + return ret;
> +
> + ret = clk_enable_bulk(>clks);
> + if (ret) {
> + clk_release_bulk(>clks);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int dwc2_usb_probe(struct udevice *dev)
>  {
>   struct dwc2_priv *priv = dev_get_priv(dev);
> @@ -1385,6 +1407,10 @@ static int dwc2_usb_probe(struct udevice *dev)
>  
>   bus_priv->desc_before_addr = true;
>  
> + ret = dwc2_clk_init(dev);
> + if (ret)
> + return ret;
> +
>   ret = dwc2_setup_phy(dev);
>   if (ret)
>   return ret;
> @@ -1410,6 +1436,8 @@ static int dwc2_usb_remove(struct udevice *dev)
>   dwc2_uninit_common(priv->regs);
>  
>   reset_release_bulk(>resets);
> + clk_disable_bulk(>clks);
> + clk_release_bulk(>clks);
>  
>   return 0;
>  }
> 

Re: [PATCH v4 2/5] usb: host: dwc2: add phy support

[Simon Goldschmidt]

Am 18.02.2020 um 09:35 schrieb Patrick Delaunay:
> Use generic phy to initialize the PHY associated to the
> DWC2 device and available in the device tree.
> 
> This patch don't added dependency because when CONFIG_PHY
> is not activated, the generic PHY function are stubbed.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - update dev_err
> - update commit message
> - change dev_err to dev_dbg for PHY function call
> - treat dwc2_shutdown_phy error
> 
>  drivers/usb/host/dwc2.c | 66 +
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index e4efaf1e59..5e7ffaddd9 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -37,6 +38,7 @@ struct dwc2_priv {
>  #ifdef CONFIG_DM_REGULATOR
>   struct udevice *vbus_supply;
>  #endif
> + struct phy phy;
>  #else
>   uint8_t *aligned_buffer;
>   uint8_t *status_buffer;
> @@ -1322,13 +1324,71 @@ static int dwc2_usb_ofdata_to_platdata(struct udevice 
> *dev)
>   return 0;
>  }
>  
> +static int dwc2_setup_phy(struct udevice *dev)
> +{
> + struct dwc2_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = generic_phy_get_by_index(dev, 0, >phy);
> + if (ret) {
> + if (ret != -ENOENT) {

Could you invert this logic and add a comment like "no PHY" or something?

> + dev_err(dev, "Failed to get USB PHY: %d.\n", ret);
> + return ret;
> + }
> + return 0;
> + }
> +
> + ret = generic_phy_init(>phy);
> + if (ret) {
> + dev_dbg(dev, "Failed to init USB PHY: %d.\n", ret);
> + return ret;
> + }
> +
> + ret = generic_phy_power_on(>phy);
> + if (ret) {
> + dev_dbg(dev, "Failed to power on USB PHY: %d.\n", ret);
> + generic_phy_exit(>phy);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int dwc2_shutdown_phy(struct udevice *dev)
> +{
> + struct dwc2_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + if (!generic_phy_valid(>phy))

A comment saying that this is for platforms without a phy driver would
be nice.

Other than that:
Reviewed-by: Simon Goldschmidt 

> + return 0;
> +
> + ret = generic_phy_power_off(>phy);
> + if (ret) {
> + dev_dbg(dev, "Failed to power off USB PHY: %d.\n", ret);
> + return ret;
> + }
> +
> + ret = generic_phy_exit(>phy);
> + if (ret) {
> + dev_dbg(dev, "Failed to power off USB PHY: %d.\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int dwc2_usb_probe(struct udevice *dev)
>  {
>   struct dwc2_priv *priv = dev_get_priv(dev);
>   struct usb_bus_priv *bus_priv = dev_get_uclass_priv(dev);
> + int ret;
>  
>   bus_priv->desc_before_addr = true;
>  
> + ret = dwc2_setup_phy(dev);
> + if (ret)
> + return ret;
> +
>   return dwc2_init_common(dev, priv);
>  }
>  
> @@ -1341,6 +1401,12 @@ static int dwc2_usb_remove(struct udevice *dev)
>   if (ret)
>   return ret;
>  
> + ret = dwc2_shutdown_phy(dev);
> + if (ret) {
> + dev_dbg(dev, "Failed to shutdown USB PHY: %d.\n", ret);
> + return ret;
> + }
> +
>   dwc2_uninit_common(priv->regs);
>  
>   reset_release_bulk(>resets);
> 

Re: [PATCH v4 1/5] dm: clk: add stub when CONFIG_CLK is desactivated

[Simon Goldschmidt]

Am 18.02.2020 um 09:34 schrieb Patrick Delaunay:
> Add stub for functions clk_...() when CONFIG_CLK is desactivated.
> 
> This patch avoids compilation issues for driver using these API
> without protection (#if CONFIG_IS_ENABLED(CLK))
> 
> For example, before this patch we have undefined reference to
> `clk_disable_bulk') for code:
>   clk_disable_bulk(>clks);
>   clk_release_bulk(>clks);
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
> Changes in v4:
> - Add stub for all functions using 'struct clk' or 'struct clk_bulk'
>   after remarks on v3
> 
> Changes in v3:
> - Add stub for clk_disable_bulk
> 
> Changes in v2: None
> 
>  include/clk.h | 101 +++---
>  1 file changed, 88 insertions(+), 13 deletions(-)
> 
> diff --git a/include/clk.h b/include/clk.h
> index 3336301815..1fb415ddc8 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -312,6 +312,7 @@ static inline int clk_release_bulk(struct clk_bulk *bulk)
>   return clk_release_all(bulk->clks, bulk->count);
>  }
>  
> +#if CONFIG_IS_ENABLED(CLK)
>  /**
>   * clk_request - Request a clock by provider-specific ID.
>   *
> @@ -433,19 +434,6 @@ int clk_disable_bulk(struct clk_bulk *bulk);
>   */
>  bool clk_is_match(const struct clk *p, const struct clk *q);
>  
> -int soc_clk_dump(void);
> -
> -/**
> - * clk_valid() - check if clk is valid
> - *
> - * @clk: the clock to check
> - * @return true if valid, or false
> - */
> -static inline bool clk_valid(struct clk *clk)
> -{
> - return clk && !!clk->dev;
> -}
> -
>  /**
>   * clk_get_by_id() - Get the clock by its ID
>   *
> @@ -465,6 +453,93 @@ int clk_get_by_id(ulong id, struct clk **clkp);
>   * @return true on binded, or false on no
>   */
>  bool clk_dev_binded(struct clk *clk);
> +
> +#else /* CONFIG_IS_ENABLED(CLK) */
> +
> +static inline int clk_request(struct udevice *dev, struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_free(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline ulong clk_get_rate(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline struct clk *clk_get_parent(struct clk *clk)
> +{
> + return (struct clk *)-ENOSYS;

This should use ERR_PTR() to care for platforms defining
CONFIG_ERR_PTR_OFFSET.

> +}
> +
> +static inline long long clk_get_parent_rate(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline ulong clk_set_rate(struct clk *clk, ulong rate)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_enable(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_enable_bulk(struct clk_bulk *bulk)
> +{
> + return bulk && bulk->count == 0 ? 0 : -ENOSYS;

For this test to work, someone would need to set bulk->count to 0. This
is normally done by clk_get_bulk(), but you defined it to only return an
error.

I guess it works for you because all clk_bulk objects you use are from
the heap (which is currently zeroed out in U-Boot) or if they are on the
stack, you have if/else code that doesn't bring you here. Still it seems
wrong.

Regards,
Simon

> +}
> +
> +static inline int clk_disable(struct clk *clk)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int clk_disable_bulk(struct clk_bulk *bulk)
> +{
> + return bulk && bulk->count == 0 ? 0 : -ENOSYS;
> +}
> +
> +static inline bool clk_is_match(const struct clk *p, const struct clk *q)
> +{
> + return false;
> +}
> +
> +static inline int clk_get_by_id(ulong id, struct clk **clkp)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline bool clk_dev_binded(struct clk *clk)
> +{
> + return false;
> +}
> +#endif /* CONFIG_IS_ENABLED(CLK) */
> +
> +/**
> + * clk_valid() - check if clk is valid
> + *
> + * @clk: the clock to check
> + * @return true if valid, or false
> + */
> +static inline bool clk_valid(struct clk *clk)
> +{
> + return clk && !!clk->dev;
> +}
> +
> +int soc_clk_dump(void);
> +
>  #endif
>  
>  #define clk_prepare_enable(clk) clk_enable(clk)
> 

Re: DE1-SoC Board Config

[Simon Goldschmidt]

Am 02.03.2020 um 01:39 schrieb Jack Frye:
> I am trying to build uboot-socfpga for Terasic DE1-SoC board (Cyclone V), 
> booting from SDMMC. I am unable to get u-boot to program the FPGA.

First question: which version of U-Boot are you using? Upstream sources
or Altera sources?

> I am following this guide from RocketBoards.
> https://rocketboards.org/foswiki/Documentation/BuildingBootloader
> with a few addenda. I have successfully built the u-boot-with_spl.sfp file 
> using the configuration socfpga_cyclone5_defconfig. 
> 
> I added 
> #define CONFIG_BOOTCOMMAND "run callscript"
> to socfpga_cyclone5_socsdk.h
> 
> I also added 
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "scriptfile=u-boot.scr" "\0" \
> "fpgadata=0x200" "\0" \
> "callscript=fatload mmc 0:1 $fpgadata $scriptfile;" \
> "source $fpgadata" "\0"
> to socfpga_common.h
> 
> My u-boot script contains the commands
> echo --- Programming FPGA ---
> # load rbf from FAT partition into memory
> fatload mmc 0:1 ${fpgadata} output_file.rbf;
> # program FPGA
> fpga load 0 ${fpgadata} ${filesize};
> # enable HPS-to-FPGA, FPGA-to-HPS, LWHPS-to-FPGA bridges
> bridge enable;
> 
> When I reach this part of the script, I am seeing 
> 7007204 bytes read in 366 ms (18.3 MiB/s)
> Command ‘load’ failed: Error -6

That "-6" is not an error code. The code here invalidly returns negative
numbers instead of error codes.

Anyway, the function returning this is fpgamgr_program_poll_initphase()
and it says that FPGA does not enter init phase or user mode after
programming.

Have you tried to execute the steps manually? If so, how long does the
"fpga load" command execute?
Have you tried listing memory contents (or using crc32) after loading
the rbf to see if it is correct?

> 
> I have scoured the internet for answers and posted on RocketBoards forums, 
> but no one seems to be able to diagnose the problem. Those who have assisted 
> me have commented they were able to perform this operation using older 
> versions of the tools. The big difference I understand is that now the SOCEDS 
> builds the preloader into u-boot using the filter_qts script. I wonder if 
> there may be some bug or compatibility issue here.

I'm not sure fpga programming depends on the handoff files...

Regards,
Simon

> 
> I have also tried using socfpga_de1_soc_defconfig, but I do not see any 
> console output when I boot.
> 

Re: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits

[Simon Goldschmidt]

Ang, Chee Hong  schrieb am Fr., 28. Feb. 2020,
03:53:

> > > On 2/24/20 3:21 AM, Ang, Chee Hong wrote:
> > > [...]
> > >
> > > > Currently, we have like 20+ secure registers allowed access by
> > > > drivers running in non-secure mode (U-Boot proper / Linux).
> > > > I don't think we want to define and maintain those high level
> > > > interfaces for each of those secure register accesses in ATF and
> U-Boot.
> > > 
> > >  See above.
> > > >>> OK. Then these secure access register should be set up in SPL
> (EL3).
> > > >>> U-Boot drivers shouldn't access them at all because the driver may
> > > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too.
> > > >>> I can take a look at those drivers accessing secure registers and
> > > >>> try to move/decouple those secure access from U-Boot drivers to
> > > >>> SPL
> > > >>> (EL3) then we no longer need those secure register access
> functions.
> > > >>
> > > >> I think that would be great, no ?
> > > > Since the SDMMC/DWMAC drivers read the device tree to configure the
> > > > behaviour of the hardware via the secure registers. I think it
> > > > should still be part of the driver instead of configuring the
> > > > hardware in different places. I have proposed using ATF's high-level
> > > > APIs to achieve this
> > > when the driver is running in EL2.
> > > > I have already proposed this in other email threads.
> > > > Are you OK with this approach ?
> > >
> > > I think something more high level might be a good idea here.
> > What do you mean by 'more high level' ?
> > We handle this in SPL (EL3) ?
> >
> > Since you are the author of this 'drivers/net/dwmac_socfpga.c':
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/drivers/net/dwmac_socfpga.c#L101
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98
> >
> > Your driver selects the PHY interface (RGMII/RMII and etc) using the
> following
> > register (part of System Manager):
> > https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> > 10/hps.html#topic/jng1505406892594.html
> >
> > I personally think this PHY interface select for EMACx shouldn't be part
> of
> > System Manager.
> > I don't see the security benefits here by making this PHY interface
> select as
> > 'secure zone' register.
> >
> > Same applies to DW MMC driver as well:
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60
> >
> > It sets the following register in System Manager (secure zone) to
> configure the
> > SDMMC clocks:
> > https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> > 10/hps.html#topic/gil1505406886282.html
> >
> > Don't you think these things should be part of driver itself as what we
> are doing
> > now instead of removing these from drivers and place them in SPL (EL3)?
>
> These 2 drivers that access the system manager:
> drivers/mmc/socfpga_dw_mmc.c
> - MMC driver access System Manager's 'SDMMC' register to set clock phase
>
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/gil1505406886282.html
>
> drivers/net/dwmac_socfpga.c
> - MAC driver access System Manager's 'EMACx' registers to set MAC's PHY
> interface:
>
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html
>
> Gen5/Arria10/Stratix10 & Agilex all using these drivers.
> They do not cause any issue in Gen5/Arria10 because there is no 'secure
> zone' in System Manager.
> For Stratix10 & Agilex, it has issue with U-Boot proper running in EL2.
>
> I don't think is good idea to separate those System Manager access from
> these 2 drivers and move them to SPL as they are shared by all SOCFPGA
> platforms.
>
> I think the proper way to resolve this is we add a new System Manager
> driver under 'drivers/misc'.
> The device type should be 'UCLASS_MISC'.


I have a pending patchset that adds such a sysmgr driver at least for gen5.
I haven't published it yet because the whole series as one makes gen5 SRAM
overlow, but maybe that part can be split out...

Regards,
Simon


Then we make changes to those drivers (SDMMC/MAC) to access the System
> Manager through the System Manager driver by using 'misc_read(dev...)' &
> 'misc_write(dev...)'
> The System Manager driver should decide whether to access those 'secure
> zone' registers directly in EL3 or making SMC call to ATF to access the
> System Manager if it's running in EL2.
>
> Linux has similar MAC driver running in EL1 (non-secure) accessing System
> Manager:
>
> https://elixir.bootlin.com/linux/v5.5/source/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c#L302
>
> Linux MAC driver access System Manager via this 'altr,system_manager'
> driver:
>
> https://elixir.bootlin.com/linux/v5.5/source/drivers/mfd/altera-sysmgr.c#L44
> System Manager driver will make SMC/PSCI call to ATF to access the System
> Manager's registers.
>

Re: [PATCH] spi: cadence-qspi: Move ref clock calculation to probe

[Simon Goldschmidt]

Vignesh Raghavendra  schrieb am Mi., 26. Feb. 2020, 08:29:

> +Simon who converted driver to use clk_get* APIs
>
> On 24/02/20 12:40 pm, Pratyush Yadav wrote:
> > "assigned-clock-parents" and "assigned-clock-rates" DT properties take
> > effect only after ofdata_to_platdata() when clk_set_defaults() is called
> > in device_probe(). Therefore clk get rate() would return a wrong value
> > in ofdata_to_platdata() when compared with probe. Hence it needs to be
> > moved to probe.
> >
> > Tested on u-boot-ti/next.
> >
>
> Acked-by: Vignesh Raghavendra 
>

Fine by me. I actually moved it there after someone requested me to :-) I
first had it in the set_rate function...

Acked-by: Simon Goldschmidt 

>
> Regards
> Vignesh
>
> > Signed-off-by: Pratyush Yadav 
> > ---
> >  drivers/spi/cadence_qspi.c | 33 +
> >  1 file changed, 17 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > index 83b114ffe7..994a5948f1 100644
> > --- a/drivers/spi/cadence_qspi.c
> > +++ b/drivers/spi/cadence_qspi.c
> > @@ -166,11 +166,28 @@ static int cadence_spi_probe(struct udevice *bus)
> >  {
> >   struct cadence_spi_platdata *plat = bus->platdata;
> >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > + struct clk clk;
> >   int ret;
> >
> >   priv->regbase = plat->regbase;
> >   priv->ahbbase = plat->ahbbase;
> >
> > + if (plat->ref_clk_hz == 0) {
> > + ret = clk_get_by_index(bus, 0, );
> > + if (ret) {
> > +#ifdef CONFIG_CQSPI_REF_CLK
> > + plat->ref_clk_hz = CONFIG_CQSPI_REF_CLK;
> > +#else
> > + return ret;
> > +#endif
> > + } else {
> > + plat->ref_clk_hz = clk_get_rate();
> > + clk_free();
> > + if (IS_ERR_VALUE(plat->ref_clk_hz))
> > + return plat->ref_clk_hz;
> > + }
> > + }
> > +
> >   ret = reset_get_bulk(bus, >resets);
> >   if (ret)
> >   dev_warn(bus, "Can't get reset: %d\n", ret);
> > @@ -268,8 +285,6 @@ static int cadence_spi_ofdata_to_platdata(struct
> udevice *bus)
> >  {
> >   struct cadence_spi_platdata *plat = bus->platdata;
> >   ofnode subnode;
> > - struct clk clk;
> > - int ret;
> >
> >   plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
> >   plat->ahbbase = (void *)devfdt_get_addr_size_index(bus, 1,
> > @@ -305,20 +320,6 @@ static int cadence_spi_ofdata_to_platdata(struct
> udevice *bus)
> >   plat->tchsh_ns = ofnode_read_u32_default(subnode, "cdns,tchsh-ns",
> 20);
> >   plat->tslch_ns = ofnode_read_u32_default(subnode, "cdns,tslch-ns",
> 20);
> >
> > - ret = clk_get_by_index(bus, 0, );
> > - if (ret) {
> > -#ifdef CONFIG_CQSPI_REF_CLK
> > - plat->ref_clk_hz = CONFIG_CQSPI_REF_CLK;
> > -#else
> > - return ret;
> > -#endif
> > - } else {
> > - plat->ref_clk_hz = clk_get_rate();
> > - clk_free();
> > - if (IS_ERR_VALUE(plat->ref_clk_hz))
> > - return plat->ref_clk_hz;
> > - }
> > -
> >   debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
> > __func__, plat->regbase, plat->ahbbase, plat->max_hz,
> > plat->page_size);
> >
>
>
>

Re: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)

[Simon Goldschmidt]

Ang, Chee Hong  schrieb am Mo., 24. Feb. 2020,
10:12:

>
>
>
>
> *From:* Ang, Chee Hong
> *Sent:* Saturday, February 22, 2020 6:00 PM
> *To:* Simon Goldschmidt 
> *Cc:* U-Boot Mailing List ; Marek Vasut <
> ma...@denx.de>; See, Chin Liang ; Tan, Ley Foon
> ; Westergreen, Dalon ;
> Gong, Richard 
> *Subject:* RE: [PATCH v2 11/21] arm: socfpga: Secure register access for
> clock manager (SoC 64bits)
>
>
>
> Ang, Chee Hong  schrieb am Sa., 22. Feb. 2020,
> 06:30:
>
> > From: Chee Hong Ang 
> >
> > Allow clock manager driver to access the System Manager's Boot Scratch
> > Register 0 in non-secure mode (EL2) on SoC 64bits platform.
> >
> > Signed-off-by: Chee Hong Ang 
> > ---
> >  arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +++--
> >  arch/arm/mach-socfpga/clock_manager_s10.c| 5 +++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c
> b/arch/arm/mach-
> > socfpga/clock_manager_agilex.c
> > index 4ee2b7b..e5a0998 100644
> > --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> > +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -65,8 +66,8 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
> >
> >  u32 cm_get_qspi_controller_clk_hz(void)
> >  {
> > - return readl(socfpga_get_sysmgr_addr() +
> > -  SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> > + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
> > +
> > SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> >  }
> >
> >  void cm_print_clock_quick_summary(void)
> > diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c b/arch/arm/mach-
> > socfpga/clock_manager_s10.c
> > index 05e4212..02578cc 100644
> > --- a/arch/arm/mach-socfpga/clock_manager_s10.c
> > +++ b/arch/arm/mach-socfpga/clock_manager_s10.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -385,8 +386,8 @@ unsigned int cm_get_l4_sp_clk_hz(void)
> >
> >  unsigned int cm_get_qspi_controller_clk_hz(void)
> >  {
> > - return readl(socfpga_get_sysmgr_addr() +
> > -  SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> > + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
> > +
> > SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> >  }
> >
> >  unsigned int cm_get_spi_controller_clk_hz(void)
> > --
> > 2.7.4
> >SPL reads the clock info from handoff table (OCRAM) and write
> >the clock info into the System Manager's boot scratch register.
> >U-Boot proper will read from the System Manager's boot scratch
> >register to get the clock info in case the handoff table (OCRAM)
> >is no longer available.
> >After some investigations, the handoff table in OCRAM should be preserved
> >for warm boot. In other words, this handoff table should be left
> untouched.
> >SPL and U-Boot should directly read the clock info from handoff table in
> OCRAM.
> >Therefore, U-Boot proper no longer need to read the clock info from
> >System Manager's boot scratch register (secure zone) from non-secure
> world (EL2).
>
>
>
> >I don't think that's a good idea: for security reasons, SPL memory should
> not be accessible from EL2 if it is required/used for the next reboot.
>
> >
>
> >Regards,
>
> >Simon
>
> Right. I think I will have to go for proper high-level API in ATF for EL2
> to query the clock frequency:
>
> INTEL_SIP_SMC_CLK_GET_QSPI
>
>
>
> I found out System Manager is read only in EL2 and read/write in EL3.
>
> Will drop this patch.
>
> No change required since it only read back from System Manager’s registers.
>

So reading these registers is allowed in EL2? I would have expected all
access is blocked? Is this specified somewhere, or will it be?

Regards,
Simon

>

Re: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)

[Simon Goldschmidt]

Ang, Chee Hong  schrieb am Sa., 22. Feb. 2020,
06:30:

> > From: Chee Hong Ang 
> >
> > Allow clock manager driver to access the System Manager's Boot Scratch
> > Register 0 in non-secure mode (EL2) on SoC 64bits platform.
> >
> > Signed-off-by: Chee Hong Ang 
> > ---
> >  arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +++--
> >  arch/arm/mach-socfpga/clock_manager_s10.c| 5 +++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c
> b/arch/arm/mach-
> > socfpga/clock_manager_agilex.c
> > index 4ee2b7b..e5a0998 100644
> > --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> > +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -65,8 +66,8 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
> >
> >  u32 cm_get_qspi_controller_clk_hz(void)
> >  {
> > - return readl(socfpga_get_sysmgr_addr() +
> > -  SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> > + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
> > +
> > SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> >  }
> >
> >  void cm_print_clock_quick_summary(void)
> > diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c b/arch/arm/mach-
> > socfpga/clock_manager_s10.c
> > index 05e4212..02578cc 100644
> > --- a/arch/arm/mach-socfpga/clock_manager_s10.c
> > +++ b/arch/arm/mach-socfpga/clock_manager_s10.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -385,8 +386,8 @@ unsigned int cm_get_l4_sp_clk_hz(void)
> >
> >  unsigned int cm_get_qspi_controller_clk_hz(void)
> >  {
> > - return readl(socfpga_get_sysmgr_addr() +
> > -  SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> > + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
> > +
> > SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> >  }
> >
> >  unsigned int cm_get_spi_controller_clk_hz(void)
> > --
> > 2.7.4
> SPL reads the clock info from handoff table (OCRAM) and write
> the clock info into the System Manager's boot scratch register.
> U-Boot proper will read from the System Manager's boot scratch
> register to get the clock info in case the handoff table (OCRAM)
> is no longer available.
> After some investigations, the handoff table in OCRAM should be preserved
> for warm boot. In other words, this handoff table should be left untouched.
> SPL and U-Boot should directly read the clock info from handoff table in
> OCRAM.
> Therefore, U-Boot proper no longer need to read the clock info from
> System Manager's boot scratch register (secure zone) from non-secure world
> (EL2).
>

I don't think that's a good idea: for security reasons, SPL memory should
not be accessible from EL2 if it is required/used for the next reboot.

Regards,
Simon

Re: [PATCH v2 06/21] configs: socfpga: Enable FIT image loading with ATF support

[Simon Goldschmidt]

Am 20.02.2020 um 17:45 schrieb Marek Vasut:
> On 2/20/20 3:15 AM, Ang, Chee Hong wrote:
>>> On 2/19/20 1:25 PM, chee.hong@intel.com wrote:
 From: Chee Hong Ang 

 SPL now loads ATF (BL31), U-Boot proper and DTB from FIT image. The
 new boot flow with ATF support is as follow:

 SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)

 Signed-off-by: Chee Hong Ang 
 ---
  configs/socfpga_agilex_defconfig| 8 +++-
  configs/socfpga_stratix10_defconfig | 8 +++-
  2 files changed, 14 insertions(+), 2 deletions(-)

 diff --git a/configs/socfpga_agilex_defconfig
 b/configs/socfpga_agilex_defconfig
 index 693a774..0065ff0 100644
 --- a/configs/socfpga_agilex_defconfig
 +++ b/configs/socfpga_agilex_defconfig
 @@ -1,6 +1,6 @@
  CONFIG_ARM=y
  CONFIG_ARCH_SOCFPGA=y
 -CONFIG_SYS_TEXT_BASE=0x1000
 +CONFIG_SYS_TEXT_BASE=0x20
>>>
>>> Why did the text base change ?
>> This defconfig support ATF.
>> ATF will occupy from this address range (0x1000)
>> U-Boot now starts at 0x20.
> 
> Then please document it in the commit message.

Or even better, could we have 2 defconfigs, one for ATF, one for
non-ATF? That way, we get build coverage that this still works.

Regards,
Simon

> 
  CONFIG_SYS_MALLOC_F_LEN=0x2000
  CONFIG_ENV_SIZE=0x1000
  CONFIG_ENV_OFFSET=0x200
 @@ -10,10 +10,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
  CONFIG_IDENT_STRING="socfpga_agilex"
  CONFIG_SPL_FS_FAT=y
  CONFIG_SPL_TEXT_BASE=0xFFE0
 +CONFIG_FIT=y
 +CONFIG_SPL_LOAD_FIT=y
 +CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
  CONFIG_BOOTDELAY=5
 +CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
>>>
>>> Is legacy image support really needed ?
>> Let me check. Will get rid of this if it's not needed. Thanks.
> 
> Thanks
> 

[PATCH 8/8] Revert "mailbox: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit cc92c3cc68a9053f53b2814e9233d86553cc998e.

Signed-off-by: Simon Goldschmidt 
---

 drivers/mailbox/k3-sec-proxy.c   | 2 +-
 drivers/mailbox/mailbox-uclass.c | 4 ++--
 drivers/mailbox/sandbox-mbox.c   | 2 +-
 drivers/mailbox/stm32-ipcc.c | 2 +-
 drivers/mailbox/tegra-hsp.c  | 2 +-
 include/mailbox-uclass.h | 4 ++--
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mailbox/k3-sec-proxy.c b/drivers/mailbox/k3-sec-proxy.c
index a560209f03..0546752f5f 100644
--- a/drivers/mailbox/k3-sec-proxy.c
+++ b/drivers/mailbox/k3-sec-proxy.c
@@ -293,7 +293,7 @@ static int k3_sec_proxy_recv(struct mbox_chan *chan, void 
*data)
 struct mbox_ops k3_sec_proxy_mbox_ops = {
.of_xlate = k3_sec_proxy_of_xlate,
.request = k3_sec_proxy_request,
-   .rfree = k3_sec_proxy_free,
+   .free = k3_sec_proxy_free,
.send = k3_sec_proxy_send,
.recv = k3_sec_proxy_recv,
 };
diff --git a/drivers/mailbox/mailbox-uclass.c b/drivers/mailbox/mailbox-uclass.c
index 291f5c218e..f408f05cf9 100644
--- a/drivers/mailbox/mailbox-uclass.c
+++ b/drivers/mailbox/mailbox-uclass.c
@@ -106,8 +106,8 @@ int mbox_free(struct mbox_chan *chan)
 
debug("%s(chan=%p)\n", __func__, chan);
 
-   if (ops->rfree)
-   return ops->rfree(chan);
+   if (ops->free)
+   return ops->free(chan);
 
return 0;
 }
diff --git a/drivers/mailbox/sandbox-mbox.c b/drivers/mailbox/sandbox-mbox.c
index 25e23eb05b..0f09dfa951 100644
--- a/drivers/mailbox/sandbox-mbox.c
+++ b/drivers/mailbox/sandbox-mbox.c
@@ -88,7 +88,7 @@ static const struct udevice_id sandbox_mbox_ids[] = {
 
 struct mbox_ops sandbox_mbox_mbox_ops = {
.request = sandbox_mbox_request,
-   .rfree = sandbox_mbox_free,
+   .free = sandbox_mbox_free,
.send = sandbox_mbox_send,
.recv = sandbox_mbox_recv,
 };
diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
index 13e642ab70..c58d9fa001 100644
--- a/drivers/mailbox/stm32-ipcc.c
+++ b/drivers/mailbox/stm32-ipcc.c
@@ -154,7 +154,7 @@ static const struct udevice_id stm32_ipcc_ids[] = {
 
 struct mbox_ops stm32_ipcc_mbox_ops = {
.request = stm32_ipcc_request,
-   .rfree = stm32_ipcc_free,
+   .free = stm32_ipcc_free,
.send = stm32_ipcc_send,
.recv = stm32_ipcc_recv,
 };
diff --git a/drivers/mailbox/tegra-hsp.c b/drivers/mailbox/tegra-hsp.c
index 60f6a38321..00fc3972f9 100644
--- a/drivers/mailbox/tegra-hsp.c
+++ b/drivers/mailbox/tegra-hsp.c
@@ -176,7 +176,7 @@ static const struct udevice_id tegra_hsp_ids[] = {
 struct mbox_ops tegra_hsp_mbox_ops = {
.of_xlate = tegra_hsp_of_xlate,
.request = tegra_hsp_request,
-   .rfree = tegra_hsp_free,
+   .free = tegra_hsp_free,
.send = tegra_hsp_send,
.recv = tegra_hsp_recv,
 };
diff --git a/include/mailbox-uclass.h b/include/mailbox-uclass.h
index 3c60c76506..e0618aad97 100644
--- a/include/mailbox-uclass.h
+++ b/include/mailbox-uclass.h
@@ -49,14 +49,14 @@ struct mbox_ops {
 */
int (*request)(struct mbox_chan *chan);
/**
-* rfree - Free a previously requested channel.
+* free - Free a previously requested channel.
 *
 * This is the implementation of the client mbox_free() API.
 *
 * @chan:   The channel to free.
 * @return 0 if OK, or a negative error code.
 */
-   int (*rfree)(struct mbox_chan *chan);
+   int (*free)(struct mbox_chan *chan);
/**
* send - Send a message over a mailbox channel
*
-- 
2.20.1

[PATCH 6/8] Revert "reset: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit 94474b25c3a60a746bf641a975c3db239dae29b9.

Signed-off-by: Simon Goldschmidt 
---

 drivers/reset/reset-bcm6345.c   | 2 +-
 drivers/reset/reset-hisilicon.c | 2 +-
 drivers/reset/reset-hsdk.c  | 2 +-
 drivers/reset/reset-imx7.c  | 2 +-
 drivers/reset/reset-mediatek.c  | 2 +-
 drivers/reset/reset-meson.c | 2 +-
 drivers/reset/reset-mtmips.c| 2 +-
 drivers/reset/reset-rockchip.c  | 2 +-
 drivers/reset/reset-socfpga.c   | 2 +-
 drivers/reset/reset-sunxi.c | 2 +-
 drivers/reset/reset-ti-sci.c| 2 +-
 drivers/reset/reset-uclass.c| 2 +-
 drivers/reset/reset-uniphier.c  | 2 +-
 drivers/reset/sandbox-reset.c   | 2 +-
 drivers/reset/sti-reset.c   | 2 +-
 drivers/reset/stm32-reset.c | 2 +-
 drivers/reset/tegra-car-reset.c | 2 +-
 drivers/reset/tegra186-reset.c  | 2 +-
 include/reset-uclass.h  | 4 ++--
 19 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/reset/reset-bcm6345.c b/drivers/reset/reset-bcm6345.c
index c1f1e7f70b..f26582479e 100644
--- a/drivers/reset/reset-bcm6345.c
+++ b/drivers/reset/reset-bcm6345.c
@@ -53,7 +53,7 @@ static int bcm6345_reset_request(struct reset_ctl *rst)
 }
 
 struct reset_ops bcm6345_reset_reset_ops = {
-   .rfree = bcm6345_reset_free,
+   .free = bcm6345_reset_free,
.request = bcm6345_reset_request,
.rst_assert = bcm6345_reset_assert,
.rst_deassert = bcm6345_reset_deassert,
diff --git a/drivers/reset/reset-hisilicon.c b/drivers/reset/reset-hisilicon.c
index a678b8f745..54a254f9cb 100644
--- a/drivers/reset/reset-hisilicon.c
+++ b/drivers/reset/reset-hisilicon.c
@@ -73,7 +73,7 @@ static int hisi_reset_of_xlate(struct reset_ctl *rst,
 static const struct reset_ops hisi_reset_reset_ops = {
.of_xlate = hisi_reset_of_xlate,
.request = hisi_reset_request,
-   .rfree = hisi_reset_free,
+   .free = hisi_reset_free,
.rst_assert = hisi_reset_assert,
.rst_deassert = hisi_reset_deassert,
 };
diff --git a/drivers/reset/reset-hsdk.c b/drivers/reset/reset-hsdk.c
index f9a432a7a2..213d6c87be 100644
--- a/drivers/reset/reset-hsdk.c
+++ b/drivers/reset/reset-hsdk.c
@@ -81,7 +81,7 @@ static int hsdk_reset_noop(struct reset_ctl *rst_ctl)
 
 static const struct reset_ops hsdk_reset_ops = {
.request= hsdk_reset_noop,
-   .rfree  = hsdk_reset_noop,
+   .free   = hsdk_reset_noop,
.rst_assert = hsdk_reset_noop,
.rst_deassert   = hsdk_reset_reset,
 };
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index a61855e9ed..59d7088c9f 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -273,7 +273,7 @@ static int imx7_reset_request(struct reset_ctl *rst)
 
 static const struct reset_ops imx7_reset_reset_ops = {
.request = imx7_reset_request,
-   .rfree = imx7_reset_free,
+   .free = imx7_reset_free,
.rst_assert = imx7_reset_assert,
.rst_deassert = imx7_reset_deassert,
 };
diff --git a/drivers/reset/reset-mediatek.c b/drivers/reset/reset-mediatek.c
index 6d17f52ac7..0680abbe28 100644
--- a/drivers/reset/reset-mediatek.c
+++ b/drivers/reset/reset-mediatek.c
@@ -57,7 +57,7 @@ static int mediatek_reset_deassert(struct reset_ctl 
*reset_ctl)
 
 struct reset_ops mediatek_reset_ops = {
.request = mediatek_reset_request,
-   .rfree = mediatek_reset_free,
+   .free = mediatek_reset_free,
.rst_assert = mediatek_reset_assert,
.rst_deassert = mediatek_reset_deassert,
 };
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index 70f96355b3..180780061e 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -63,7 +63,7 @@ static int meson_reset_deassert(struct reset_ctl *reset_ctl)
 
 struct reset_ops meson_reset_ops = {
.request = meson_reset_request,
-   .rfree = meson_reset_free,
+   .free = meson_reset_free,
.rst_assert = meson_reset_assert,
.rst_deassert = meson_reset_deassert,
 };
diff --git a/drivers/reset/reset-mtmips.c b/drivers/reset/reset-mtmips.c
index 677de0a6f9..5df95f1324 100644
--- a/drivers/reset/reset-mtmips.c
+++ b/drivers/reset/reset-mtmips.c
@@ -46,7 +46,7 @@ static int mtmips_reset_deassert(struct reset_ctl *reset_ctl)
 
 static const struct reset_ops mtmips_reset_ops = {
.request= mtmips_reset_request,
-   .rfree  = mtmips_reset_free,
+   .free   = mtmips_reset_free,
.rst_assert = mtmips_reset_assert,
.rst_deassert   = mtmips_reset_deassert,
 };
diff --git a/drivers/reset/reset-rockchip.c b/drivers/reset/reset-rockchip.c
index 100afc8103..a4dc103951 100644
--- a/drivers/reset/reset-rockchip.c
+++ b/drivers/reset/reset-rockchip.c
@@ -77,7 +77,7 @@ static int rockchip_reset_deassert(struct reset_ctl 
*reset_ctl)
 
 struct reset_ops rockchip_reset_ops = {
.request = rockchip_reset_request,
-   .rfree = rockchip_reset_free,
+   .free

[PATCH 5/8] Revert "gpio: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit 093152f275e036e54d48b3d9fc0adbc1ca4cc5b0.

Signed-off-by: Simon Goldschmidt 
---

 drivers/gpio/gpio-rcar.c   | 2 +-
 drivers/gpio/gpio-uclass.c | 8 
 include/asm-generic/gpio.h | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 9dc4cd6042..25bbbcde4b 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -130,7 +130,7 @@ static int rcar_gpio_free(struct udevice *dev, unsigned 
offset)
 
 static const struct dm_gpio_ops rcar_gpio_ops = {
.request= rcar_gpio_request,
-   .rfree  = rcar_gpio_free,
+   .free   = rcar_gpio_free,
.direction_input= rcar_gpio_direction_input,
.direction_output   = rcar_gpio_direction_output,
.get_value  = rcar_gpio_get_value,
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 0a22441d38..90fbed455b 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -364,8 +364,8 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
uc_priv = dev_get_uclass_priv(dev);
if (!uc_priv->name[offset])
return -ENXIO;
-   if (gpio_get_ops(dev)->rfree) {
-   ret = gpio_get_ops(dev)->rfree(dev, offset);
+   if (gpio_get_ops(dev)->free) {
+   ret = gpio_get_ops(dev)->free(dev, offset);
if (ret)
return ret;
}
@@ -1043,8 +1043,8 @@ static int gpio_post_bind(struct udevice *dev)
if (!reloc_done) {
if (ops->request)
ops->request += gd->reloc_off;
-   if (ops->rfree)
-   ops->rfree += gd->reloc_off;
+   if (ops->free)
+   ops->free += gd->reloc_off;
if (ops->direction_input)
ops->direction_input += gd->reloc_off;
if (ops->direction_output)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 05777e6afe..d6cf18744f 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -248,7 +248,7 @@ int gpio_xlate_offs_flags(struct udevice *dev, struct 
gpio_desc *desc,
  */
 struct dm_gpio_ops {
int (*request)(struct udevice *dev, unsigned offset, const char *label);
-   int (*rfree)(struct udevice *dev, unsigned int offset);
+   int (*free)(struct udevice *dev, unsigned offset);
int (*direction_input)(struct udevice *dev, unsigned offset);
int (*direction_output)(struct udevice *dev, unsigned offset,
int value);
-- 
2.20.1

[PATCH 2/8] Revert "mtd: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit 8d38a8459b0de45f5ff41f3e11c278a5cf395fd0.

Signed-off-by: Simon Goldschmidt 
---

 drivers/mtd/mtdcore.c | 4 ++--
 drivers/mtd/nand/raw/denali.c | 2 +-
 drivers/mtd/nand/spi/core.c   | 2 +-
 drivers/mtd/nand/spi/gigadevice.c | 2 +-
 drivers/mtd/nand/spi/macronix.c   | 2 +-
 drivers/mtd/nand/spi/micron.c | 2 +-
 drivers/mtd/nand/spi/winbond.c| 2 +-
 include/linux/mtd/mtd.h   | 4 ++--
 8 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index f8d3f4d246..4567e5eb7a 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1180,10 +1180,10 @@ int mtd_ooblayout_free(struct mtd_info *mtd, int 
section,
if (!mtd || section < 0)
return -EINVAL;
 
-   if (!mtd->ooblayout || !mtd->ooblayout->rfree)
+   if (!mtd->ooblayout || !mtd->ooblayout->free)
return -ENOTSUPP;
 
-   return mtd->ooblayout->rfree(mtd, section, oobfree);
+   return mtd->ooblayout->free(mtd, section, oobfree);
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_free);
 
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index f51d3e25c7..550fb7c771 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1160,7 +1160,7 @@ static int denali_ooblayout_free(struct mtd_info *mtd, 
int section,
 
 static const struct mtd_ooblayout_ops denali_ooblayout_ops = {
.ecc = denali_ooblayout_ecc,
-   .rfree = denali_ooblayout_free,
+   .free = denali_ooblayout_free,
 };
 
 static int denali_multidev_fixup(struct denali_nand_info *denali)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index cd624ec6ae..5e3704e4d0 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -1023,7 +1023,7 @@ static int spinand_noecc_ooblayout_free(struct mtd_info 
*mtd, int section,
 
 static const struct mtd_ooblayout_ops spinand_noecc_ooblayout = {
.ecc = spinand_noecc_ooblayout_ecc,
-   .rfree = spinand_noecc_ooblayout_free,
+   .free = spinand_noecc_ooblayout_free,
 };
 
 static int spinand_init(struct spinand_device *spinand)
diff --git a/drivers/mtd/nand/spi/gigadevice.c 
b/drivers/mtd/nand/spi/gigadevice.c
index 0b228dcb5b..4c8bb1e12d 100644
--- a/drivers/mtd/nand/spi/gigadevice.c
+++ b/drivers/mtd/nand/spi/gigadevice.c
@@ -104,7 +104,7 @@ static int gd5fxgq4xexxg_ecc_get_status(struct 
spinand_device *spinand,
 
 static const struct mtd_ooblayout_ops gd5fxgq4xexxg_ooblayout = {
.ecc = gd5fxgq4xexxg_ooblayout_ecc,
-   .rfree = gd5fxgq4xexxg_ooblayout_free,
+   .free = gd5fxgq4xexxg_ooblayout_free,
 };
 
 static const struct spinand_info gigadevice_spinand_table[] = {
diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index 67d092be2c..2948e2ea41 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -48,7 +48,7 @@ static int mx35lfxge4ab_ooblayout_free(struct mtd_info *mtd, 
int section,
 
 static const struct mtd_ooblayout_ops mx35lfxge4ab_ooblayout = {
.ecc = mx35lfxge4ab_ooblayout_ecc,
-   .rfree = mx35lfxge4ab_ooblayout_free,
+   .free = mx35lfxge4ab_ooblayout_free,
 };
 
 static int mx35lf1ge4ab_get_eccsr(struct spinand_device *spinand, u8 *eccsr)
diff --git a/drivers/mtd/nand/spi/micron.c b/drivers/mtd/nand/spi/micron.c
index 687306e33e..718c4b42ca 100644
--- a/drivers/mtd/nand/spi/micron.c
+++ b/drivers/mtd/nand/spi/micron.c
@@ -64,7 +64,7 @@ static int mt29f2g01abagd_ooblayout_free(struct mtd_info 
*mtd, int section,
 
 static const struct mtd_ooblayout_ops mt29f2g01abagd_ooblayout = {
.ecc = mt29f2g01abagd_ooblayout_ecc,
-   .rfree = mt29f2g01abagd_ooblayout_free,
+   .free = mt29f2g01abagd_ooblayout_free,
 };
 
 static int mt29f2g01abagd_ecc_get_status(struct spinand_device *spinand,
diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index 6ede98c85d..b05cd70457 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -60,7 +60,7 @@ static int w25m02gv_ooblayout_free(struct mtd_info *mtd, int 
section,
 
 static const struct mtd_ooblayout_ops w25m02gv_ooblayout = {
.ecc = w25m02gv_ooblayout_ecc,
-   .rfree = w25m02gv_ooblayout_free,
+   .free = w25m02gv_ooblayout_free,
 };
 
 static int w25m02gv_select_target(struct spinand_device *spinand,
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 1b9151714c..ceffd994de 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -129,8 +129,8 @@ struct mtd_oob_region {
 struct mtd_ooblayout_ops {
int (*ecc)(struct mtd_info *mtd, int section,
   struct mtd_oob_region *oobecc);
-   int (*rfree)(struct mtd_info *mtd, int section,
-struct mtd_oob_region *oobfree);
+   int (*free)(struct mtd_info *mtd, int section,
+   struct mtd_oob_region *oobfree);
 };
 
 /*
-- 
2.20.1

[PATCH 3/8] Revert "dma: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit aae95882232a24ee49c89d0356febf3685a87c8a.

Signed-off-by: Simon Goldschmidt 
---

 drivers/dma/dma-uclass.c   | 4 ++--
 drivers/dma/sandbox-dma-test.c | 4 ++--
 drivers/dma/ti/k3-udma.c   | 4 ++--
 include/dma-uclass.h   | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 9d5a7fc796..68e17ed1f9 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -123,10 +123,10 @@ int dma_free(struct dma *dma)
 
debug("%s(dma=%p)\n", __func__, dma);
 
-   if (!ops->rfree)
+   if (!ops->free)
return 0;
 
-   return ops->rfree(dma);
+   return ops->free(dma);
 }
 
 int dma_enable(struct dma *dma)
diff --git a/drivers/dma/sandbox-dma-test.c b/drivers/dma/sandbox-dma-test.c
index 234a7d2134..e8c809fa64 100644
--- a/drivers/dma/sandbox-dma-test.c
+++ b/drivers/dma/sandbox-dma-test.c
@@ -89,7 +89,7 @@ static int sandbox_dma_request(struct dma *dma)
return 0;
 }
 
-static int sandbox_dma_rfree(struct dma *dma)
+static int sandbox_dma_free(struct dma *dma)
 {
struct sandbox_dma_dev *ud = dev_get_priv(dma->dev);
struct sandbox_dma_chan *uc;
@@ -230,7 +230,7 @@ static const struct dma_ops sandbox_dma_ops = {
.transfer   = sandbox_dma_transfer,
.of_xlate   = sandbox_dma_of_xlate,
.request= sandbox_dma_request,
-   .rfree  = sandbox_dma_rfree,
+   .free   = sandbox_dma_free,
.enable = sandbox_dma_enable,
.disable= sandbox_dma_disable,
.send   = sandbox_dma_send,
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index f274100f32..d6eb6d9339 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1553,7 +1553,7 @@ static int udma_request(struct dma *dma)
return 0;
 }
 
-static int udma_rfree(struct dma *dma)
+static int udma_free(struct dma *dma)
 {
struct udma_dev *ud = dev_get_priv(dma->dev);
struct udma_chan *uc;
@@ -1848,7 +1848,7 @@ static const struct dma_ops udma_ops = {
.transfer   = udma_transfer,
.of_xlate   = udma_of_xlate,
.request= udma_request,
-   .rfree  = udma_rfree,
+   .free   = udma_free,
.enable = udma_enable,
.disable= udma_disable,
.send   = udma_send,
diff --git a/include/dma-uclass.h b/include/dma-uclass.h
index 340437acc1..a1d9d26ac5 100644
--- a/include/dma-uclass.h
+++ b/include/dma-uclass.h
@@ -58,14 +58,14 @@ struct dma_ops {
 */
int (*request)(struct dma *dma);
/**
-* rfree - Free a previously requested dma.
+* free - Free a previously requested dma.
 *
 * This is the implementation of the client dma_free() API.
 *
 * @dma: The DMA to free.
 * @return 0 if OK, or a negative error code.
 */
-   int (*rfree)(struct dma *dma);
+   int (*free)(struct dma *dma);
/**
 * enable() - Enable a DMA Channel.
 *
-- 
2.20.1

[PATCH 7/8] Revert "power-domain: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit 4f51188e47921b17e6b3ce9606c8e71234c9f2df.

Signed-off-by: Simon Goldschmidt 
---

 drivers/power/domain/bcm6328-power-domain.c | 2 +-
 drivers/power/domain/imx8-power-domain-legacy.c | 2 +-
 drivers/power/domain/imx8-power-domain.c| 2 +-
 drivers/power/domain/imx8m-power-domain.c   | 2 +-
 drivers/power/domain/meson-ee-pwrc.c| 2 +-
 drivers/power/domain/meson-gx-pwrc-vpu.c| 2 +-
 drivers/power/domain/mtk-power-domain.c | 2 +-
 drivers/power/domain/power-domain-uclass.c  | 2 +-
 drivers/power/domain/sandbox-power-domain.c | 2 +-
 drivers/power/domain/tegra186-power-domain.c| 2 +-
 drivers/power/domain/ti-sci-power-domain.c  | 2 +-
 include/power-domain-uclass.h   | 4 ++--
 12 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/power/domain/bcm6328-power-domain.c 
b/drivers/power/domain/bcm6328-power-domain.c
index a6426bee27..e261d22b50 100644
--- a/drivers/power/domain/bcm6328-power-domain.c
+++ b/drivers/power/domain/bcm6328-power-domain.c
@@ -63,7 +63,7 @@ static const struct udevice_id bcm6328_power_domain_ids[] = {
 };
 
 struct power_domain_ops bcm6328_power_domain_ops = {
-   .rfree = bcm6328_power_domain_free,
+   .free = bcm6328_power_domain_free,
.off = bcm6328_power_domain_off,
.on = bcm6328_power_domain_on,
.request = bcm6328_power_domain_request,
diff --git a/drivers/power/domain/imx8-power-domain-legacy.c 
b/drivers/power/domain/imx8-power-domain-legacy.c
index 6f01a60b34..f489083f2d 100644
--- a/drivers/power/domain/imx8-power-domain-legacy.c
+++ b/drivers/power/domain/imx8-power-domain-legacy.c
@@ -297,7 +297,7 @@ static const struct udevice_id imx8_power_domain_ids[] = {
 
 struct power_domain_ops imx8_power_domain_ops = {
.request = imx8_power_domain_request,
-   .rfree = imx8_power_domain_free,
+   .free = imx8_power_domain_free,
.on = imx8_power_domain_on,
.off = imx8_power_domain_off,
.of_xlate = imx8_power_domain_of_xlate,
diff --git a/drivers/power/domain/imx8-power-domain.c 
b/drivers/power/domain/imx8-power-domain.c
index 571146e19d..eaf8635899 100644
--- a/drivers/power/domain/imx8-power-domain.c
+++ b/drivers/power/domain/imx8-power-domain.c
@@ -74,7 +74,7 @@ static const struct udevice_id imx8_power_domain_ids[] = {
 
 struct power_domain_ops imx8_power_domain_ops_v2 = {
.request = imx8_power_domain_request,
-   .rfree = imx8_power_domain_free,
+   .free = imx8_power_domain_free,
.on = imx8_power_domain_on,
.off = imx8_power_domain_off,
 };
diff --git a/drivers/power/domain/imx8m-power-domain.c 
b/drivers/power/domain/imx8m-power-domain.c
index 5b6467cda7..48a3fca6bd 100644
--- a/drivers/power/domain/imx8m-power-domain.c
+++ b/drivers/power/domain/imx8m-power-domain.c
@@ -122,7 +122,7 @@ static const struct udevice_id imx8m_power_domain_ids[] = {
 
 struct power_domain_ops imx8m_power_domain_ops = {
.request = imx8m_power_domain_request,
-   .rfree = imx8m_power_domain_free,
+   .free = imx8m_power_domain_free,
.on = imx8m_power_domain_on,
.off = imx8m_power_domain_off,
.of_xlate = imx8m_power_domain_of_xlate,
diff --git a/drivers/power/domain/meson-ee-pwrc.c 
b/drivers/power/domain/meson-ee-pwrc.c
index 7082c80bfa..f09bc03811 100644
--- a/drivers/power/domain/meson-ee-pwrc.c
+++ b/drivers/power/domain/meson-ee-pwrc.c
@@ -354,7 +354,7 @@ static int meson_ee_pwrc_of_xlate(struct power_domain 
*power_domain,
 }
 
 struct power_domain_ops meson_ee_pwrc_ops = {
-   .rfree = meson_ee_pwrc_free,
+   .free = meson_ee_pwrc_free,
.off = meson_ee_pwrc_off,
.on = meson_ee_pwrc_on,
.request = meson_ee_pwrc_request,
diff --git a/drivers/power/domain/meson-gx-pwrc-vpu.c 
b/drivers/power/domain/meson-gx-pwrc-vpu.c
index 12cdfcdd1f..8381cb226d 100644
--- a/drivers/power/domain/meson-gx-pwrc-vpu.c
+++ b/drivers/power/domain/meson-gx-pwrc-vpu.c
@@ -271,7 +271,7 @@ static int meson_pwrc_vpu_of_xlate(struct power_domain 
*power_domain,
 }
 
 struct power_domain_ops meson_gx_pwrc_vpu_ops = {
-   .rfree = meson_pwrc_vpu_free,
+   .free = meson_pwrc_vpu_free,
.off = meson_pwrc_vpu_off,
.on = meson_pwrc_vpu_on,
.request = meson_pwrc_vpu_request,
diff --git a/drivers/power/domain/mtk-power-domain.c 
b/drivers/power/domain/mtk-power-domain.c
index 3ff7ca1bef..dcf33678d7 100644
--- a/drivers/power/domain/mtk-power-domain.c
+++ b/drivers/power/domain/mtk-power-domain.c
@@ -398,7 +398,7 @@ static const struct udevice_id mtk_power_domain_ids[] = {
 };
 
 struct power_domain_ops mtk_power_domain_ops = {
-   .rfree = scpsys_power_free,
+   .free = scpsys_power_free,
.off = scpsys_power_off,
.on = scpsys_power_on,
.request = scpsys_power_request,
diff --git a/drivers/power/domain/power-domain-uclass.c 
b/drivers/power/domain/power-domain-uclass.c
index d9c623b56e

[PATCH 4/8] Revert "clk: Rename free() to rfree()"

[Simon Goldschmidt]

This reverts commit fb8c0d595f1ad83bee5dd398b59b0ee16d8d15a9.

Signed-off-by: Simon Goldschmidt 
---

 drivers/clk/clk-ti-sci.c  | 2 +-
 drivers/clk/clk-uclass.c  | 4 ++--
 drivers/clk/clk_sandbox.c | 2 +-
 drivers/clk/tegra/tegra-car-clk.c | 2 +-
 include/clk-uclass.h  | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk-ti-sci.c b/drivers/clk/clk-ti-sci.c
index 82241d9f3f..e272003d30 100644
--- a/drivers/clk/clk-ti-sci.c
+++ b/drivers/clk/clk-ti-sci.c
@@ -206,7 +206,7 @@ static const struct udevice_id ti_sci_clk_of_match[] = {
 static struct clk_ops ti_sci_clk_ops = {
.of_xlate = ti_sci_clk_of_xlate,
.request = ti_sci_clk_request,
-   .rfree = ti_sci_clk_free,
+   .free = ti_sci_clk_free,
.get_rate = ti_sci_clk_get_rate,
.set_rate = ti_sci_clk_set_rate,
.set_parent = ti_sci_clk_set_parent,
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 71878474eb..24353fae53 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -426,10 +426,10 @@ int clk_free(struct clk *clk)
return 0;
ops = clk_dev_ops(clk->dev);
 
-   if (!ops->rfree)
+   if (!ops->free)
return 0;
 
-   return ops->rfree(clk);
+   return ops->free(clk);
 }
 
 ulong clk_get_rate(struct clk *clk)
diff --git a/drivers/clk/clk_sandbox.c b/drivers/clk/clk_sandbox.c
index 768fbb7c52..7059979606 100644
--- a/drivers/clk/clk_sandbox.c
+++ b/drivers/clk/clk_sandbox.c
@@ -108,7 +108,7 @@ static struct clk_ops sandbox_clk_ops = {
.enable = sandbox_clk_enable,
.disable= sandbox_clk_disable,
.request= sandbox_clk_request,
-   .rfree  = sandbox_clk_free,
+   .free   = sandbox_clk_free,
 };
 
 static int sandbox_clk_probe(struct udevice *dev)
diff --git a/drivers/clk/tegra/tegra-car-clk.c 
b/drivers/clk/tegra/tegra-car-clk.c
index 6083f14e75..1f0e2dc95b 100644
--- a/drivers/clk/tegra/tegra-car-clk.c
+++ b/drivers/clk/tegra/tegra-car-clk.c
@@ -81,7 +81,7 @@ static int tegra_car_clk_disable(struct clk *clk)
 
 static struct clk_ops tegra_car_clk_ops = {
.request = tegra_car_clk_request,
-   .rfree = tegra_car_clk_free,
+   .free = tegra_car_clk_free,
.get_rate = tegra_car_clk_get_rate,
.set_rate = tegra_car_clk_set_rate,
.enable = tegra_car_clk_enable,
diff --git a/include/clk-uclass.h b/include/clk-uclass.h
index dac42dab36..e76d98e2f6 100644
--- a/include/clk-uclass.h
+++ b/include/clk-uclass.h
@@ -53,14 +53,14 @@ struct clk_ops {
 */
int (*request)(struct clk *clock);
/**
-* rfree - Free a previously requested clock.
+* free - Free a previously requested clock.
 *
 * This is the implementation of the client clk_free() API.
 *
 * @clock:  The clock to free.
 * @return 0 if OK, or a negative error code.
 */
-   int (*rfree)(struct clk *clock);
+   int (*free)(struct clk *clock);
/**
 * get_rate() - Get current clock rate.
 *
-- 
2.20.1

[PATCH 1/8] malloc: implement USE_DL_PREFIX via inline functions

[Simon Goldschmidt]

Commit cfda60f99ae2 ("sandbox: Use a prefix for all allocation functions")
introduced preprocessor macros for malloc/free etc.

This is bad practice as it essentially makes 'free' a reserved keyword and
resulted in quite a bit of renaming to avoid that reserved keyword.

A better solution is to define the allocation functions as 'static inline'.

As a side effect, exports.h must not export malloc/free for sandbox.

Signed-off-by: Simon Goldschmidt 
---

A side-effect is that exports.h may not declare malloc/free. I'm not really
sure if this is correct, but for sandbox, it should probably be ok?

 include/_exports.h |  2 ++
 include/exports.h  |  2 ++
 include/malloc.h   | 44 +---
 3 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/include/_exports.h b/include/_exports.h
index 0dee05f077..acfbf97c17 100644
--- a/include/_exports.h
+++ b/include/_exports.h
@@ -22,9 +22,11 @@
EXPORT_FUNC(dummy, void, install_hdlr, void)
EXPORT_FUNC(dummy, void, free_hdlr, void)
 #endif
+#ifndef CONFIG_SANDBOX
EXPORT_FUNC(malloc, void *, malloc, size_t)
 #if !CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
EXPORT_FUNC(free, void, free, void *)
+#endif
 #endif
EXPORT_FUNC(udelay, void, udelay, unsigned long)
EXPORT_FUNC(get_timer, unsigned long, get_timer, unsigned long)
diff --git a/include/exports.h b/include/exports.h
index cbd16fc518..5d161824c8 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -25,10 +25,12 @@ void puts(const char*);
 int printf(const char* fmt, ...);
 void install_hdlr(int, interrupt_handler_t, void*);
 void free_hdlr(int);
+#ifndef CONFIG_SANDBOX
 void *malloc(size_t);
 #if !CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
 void free(void*);
 #endif
+#endif
 void __udelay(unsigned long);
 unsigned long get_timer(unsigned long);
 int vprintf(const char *, va_list);
diff --git a/include/malloc.h b/include/malloc.h
index f66c2e8617..50d4873b08 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -897,21 +897,6 @@ void malloc_simple_info(void);
 # define pvALLOc   dlpvalloc
 # define mALLINFo  dlmallinfo
 # define mALLOPt   dlmallopt
-
-/* Ensure that U-Boot actually uses these too */
-#define calloc dlcalloc
-#define free(ptr) dlfree(ptr)
-#define malloc(x) dlmalloc(x)
-#define memalign dlmemalign
-#define realloc dlrealloc
-#define valloc dlvalloc
-#define pvalloc dlpvalloc
-#define mallinfo() dlmallinfo()
-#define mallopt dlmallopt
-#define malloc_trim dlmalloc_trim
-#define malloc_usable_size dlmalloc_usable_size
-#define malloc_stats dlmalloc_stats
-
 # else /* USE_DL_PREFIX */
 # define cALLOccalloc
 # define fREe  free
@@ -966,6 +951,35 @@ voidmalloc_stats();
 int mALLOPt();
 struct mallinfo mALLINFo();
 # endif
+
+# ifdef USE_DL_PREFIX
+/* Ensure that U-Boot actually uses the redefined functions: */
+static inline void *calloc(size_t n, size_t elem_size)
+{
+   return dlcalloc(n, elem_size);
+}
+
+static inline void free(void *ptr) { dlfree(ptr); }
+static inline void *malloc(size_t bytes) { return dlmalloc(bytes); }
+static inline void *memalign(size_t alignment, size_t bytes)
+{
+   return dlmemalign(alignment, bytes);
+}
+
+static inline void *realloc(void *oldmem, size_t bytes)
+{
+   return dlrealloc(oldmem, bytes);
+}
+
+static inline void *valloc(size_t bytes) { return dlvalloc(bytes); }
+static inline void *pvalloc(size_t bytes) { return dlpvalloc(bytes); }
+static inline struct mallinfo mallinfo(void) { return dlmallinfo(); }
+static inline int mallopt(int param_number, int value)
+{
+   return dlmallopt(param_number, value);
+}
+# endif
+
 #endif
 #pragma GCC visibility pop
 
-- 
2.20.1

[PATCH 0/8] malloc: implement USE_DL_PREFIX using inline functions

[Simon Goldschmidt]

Commit cfda60f99ae2 ("sandbox: Use a prefix for all allocation functions")
introduced preprocessor macros for malloc/free etc.

This is bad practice as it essentially makes 'free' a reserved keyword and
resulted in quite a bit of renaming to avoid that reserved keyword.

A better solution is to define the allocation functions as 'static inline'.

This should go in before the release, as it's a regression not seen before
the last release.

A side-effect is that exports.h may not declare malloc/free. I'm not really
sure if this is correct, but for sandbox, it should probably be ok?


Simon Goldschmidt (8):
  malloc: implement USE_DL_PREFIX via inline functions
  Revert "mtd: Rename free() to rfree()"
  Revert "dma: Rename free() to rfree()"
  Revert "clk: Rename free() to rfree()"
  Revert "gpio: Rename free() to rfree()"
  Revert "reset: Rename free() to rfree()"
  Revert "power-domain: Rename free() to rfree()"
  Revert "mailbox: Rename free() to rfree()"

 drivers/clk/clk-ti-sci.c  |  2 +-
 drivers/clk/clk-uclass.c  |  4 +-
 drivers/clk/clk_sandbox.c |  2 +-
 drivers/clk/tegra/tegra-car-clk.c |  2 +-
 drivers/dma/dma-uclass.c  |  4 +-
 drivers/dma/sandbox-dma-test.c|  4 +-
 drivers/dma/ti/k3-udma.c  |  4 +-
 drivers/gpio/gpio-rcar.c  |  2 +-
 drivers/gpio/gpio-uclass.c|  8 ++--
 drivers/mailbox/k3-sec-proxy.c|  2 +-
 drivers/mailbox/mailbox-uclass.c  |  4 +-
 drivers/mailbox/sandbox-mbox.c|  2 +-
 drivers/mailbox/stm32-ipcc.c  |  2 +-
 drivers/mailbox/tegra-hsp.c   |  2 +-
 drivers/mtd/mtdcore.c |  4 +-
 drivers/mtd/nand/raw/denali.c |  2 +-
 drivers/mtd/nand/spi/core.c   |  2 +-
 drivers/mtd/nand/spi/gigadevice.c |  2 +-
 drivers/mtd/nand/spi/macronix.c   |  2 +-
 drivers/mtd/nand/spi/micron.c |  2 +-
 drivers/mtd/nand/spi/winbond.c|  2 +-
 drivers/power/domain/bcm6328-power-domain.c   |  2 +-
 .../power/domain/imx8-power-domain-legacy.c   |  2 +-
 drivers/power/domain/imx8-power-domain.c  |  2 +-
 drivers/power/domain/imx8m-power-domain.c |  2 +-
 drivers/power/domain/meson-ee-pwrc.c  |  2 +-
 drivers/power/domain/meson-gx-pwrc-vpu.c  |  2 +-
 drivers/power/domain/mtk-power-domain.c   |  2 +-
 drivers/power/domain/power-domain-uclass.c|  2 +-
 drivers/power/domain/sandbox-power-domain.c   |  2 +-
 drivers/power/domain/tegra186-power-domain.c  |  2 +-
 drivers/power/domain/ti-sci-power-domain.c|  2 +-
 drivers/reset/reset-bcm6345.c |  2 +-
 drivers/reset/reset-hisilicon.c   |  2 +-
 drivers/reset/reset-hsdk.c|  2 +-
 drivers/reset/reset-imx7.c|  2 +-
 drivers/reset/reset-mediatek.c|  2 +-
 drivers/reset/reset-meson.c   |  2 +-
 drivers/reset/reset-mtmips.c  |  2 +-
 drivers/reset/reset-rockchip.c|  2 +-
 drivers/reset/reset-socfpga.c |  2 +-
 drivers/reset/reset-sunxi.c   |  2 +-
 drivers/reset/reset-ti-sci.c  |  2 +-
 drivers/reset/reset-uclass.c  |  2 +-
 drivers/reset/reset-uniphier.c|  2 +-
 drivers/reset/sandbox-reset.c |  2 +-
 drivers/reset/sti-reset.c |  2 +-
 drivers/reset/stm32-reset.c   |  2 +-
 drivers/reset/tegra-car-reset.c   |  2 +-
 drivers/reset/tegra186-reset.c|  2 +-
 include/_exports.h|  2 +
 include/asm-generic/gpio.h|  2 +-
 include/clk-uclass.h  |  4 +-
 include/dma-uclass.h  |  4 +-
 include/exports.h |  2 +
 include/linux/mtd/mtd.h   |  4 +-
 include/mailbox-uclass.h  |  4 +-
 include/malloc.h  | 44 ---
 include/power-domain-uclass.h |  4 +-
 include/reset-uclass.h|  4 +-
 60 files changed, 105 insertions(+), 87 deletions(-)

-- 
2.20.1

Re: [PATCH v4 0/5] usb: host: dwc2: use driver model for PHY and CLOCK

[Simon Goldschmidt]

On Tue, Feb 18, 2020 at 6:53 PM Marek Vasut  wrote:
>
> On 2/18/20 9:34 AM, Patrick Delaunay wrote:
> >
> > In this serie I update the DWC2 host driver to use the device tree
> > information and the associated PHY and CLOCK drivers when they are
> > availables.
> >
> > The V4 is rebased on latest master (v2020.04-rc2).
> > CI-Tavis build is OK:
> > https://travis-ci.org/patrickdelaunay/u-boot/builds/651479714
> >
> > NB: CI-Travis build was OK for all target after V3:
> > https://travis-ci.org/patrickdelaunay/u-boot/builds/609496187
> > As in V2, I cause the warnings for some boards:
> > drivers/usb/host/built-in.o: In function `dwc2_usb_remove':
> > drivers/usb/host/dwc2.c:1441: undefined reference to `clk_disable_bulk'
> >
> > I test this serie on stm32mp157c-ev1 board, with PHY and CLK
> > support
> >
> > The U-CLASS are provided by:
> > - PHY by USBPHYC driver = ./drivers/phy/phy-stm32-usbphyc.c
> > - CLOCK by RCC clock driver = drivers/clk/clk_stm32mp1.c
> > - RESET by RCC reset driver = drivers/reset/stm32-reset.c
> >
> > And I activate the configuration
> > +CONFIG_USB_DWC2=y
>
> Simon, can you test this on SOCFPGA ?

I can test if it probes, but I don't have anything running on that USB port
the socfpga_socrates board has. Would that be enought to test?

Regards,
Simon

>
> [...]

Re: [PATCH V2 1/2] ARM: socfpga: Permit overriding the default timer frequency

[Simon Goldschmidt]

Am 17.02.2020 um 18:30 schrieb Marek Vasut:
> The default timer rate may be different than 25 MHz, permit overriding
> the default rate in board configuration file. Ultimatelly, this should
> be properly handled by a clock driver, however that is not available
> on Gen5 yet.
> 
> Signed-off-by: Marek Vasut 
> Cc: Ley Foon Tan 
> Cc: Simon Goldschmidt 

Reviewed-by: Simon Goldschmidt 

> ---
> V2: Drop misleading comment
> ---
>  include/configs/socfpga_common.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 8d10469e7c..54a43569dc 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -94,12 +94,13 @@
>   * L4 OSC1 Timer 0
>   */
>  #ifndef CONFIG_TIMER
> -/* This timer uses eosc1, whose clock frequency is fixed at any condition. */
>  #define CONFIG_SYS_TIMERBASE SOCFPGA_OSC1TIMER0_ADDRESS
>  #define CONFIG_SYS_TIMER_COUNTS_DOWN
>  #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE + 0x4)
> +#ifndef CONFIG_SYS_TIMER_RATE
>  #define CONFIG_SYS_TIMER_RATE2500
>  #endif
> +#endif
>  
>  /*
>   * L4 Watchdog
> 

Re: [PATCH 1/2] ARM: socfpga: Permit overriding the default timer frequency

[Simon Goldschmidt]

On Sat, Feb 15, 2020 at 10:40 PM Marek Vasut  wrote:
>
> On 2/15/20 8:39 PM, Simon Goldschmidt wrote:
> > Am 15.02.2020 um 15:02 schrieb Marek Vasut:
> >> The default timer rate may be different than 25 MHz, permit overriding
> >> the default rate in board configuration file. Ultimatelly, this should
> >> be properly handled by a clock driver, however that is not available
> >> on Gen5 yet.
> >
> > Sigh, yes, I still haven't found the time to fight those size problems I
> > have... :-(
> >
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Ley Foon Tan 
> >> Cc: Simon Goldschmidt 
> >> ---
> >>  include/configs/socfpga_common.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/include/configs/socfpga_common.h 
> >> b/include/configs/socfpga_common.h
> >> index 8d10469e7c..8c5dcfa57c 100644
> >> --- a/include/configs/socfpga_common.h
> >> +++ b/include/configs/socfpga_common.h
> >> @@ -98,8 +98,10 @@
> >
> > Just above this line, there's this comment: "This timer uses eosc1,
> > whose clock frequency is fixed at any condition".
> >
> > While I'm ok with the change below, it does look a bit funny to make
> > this overriable if it's "fixed at any condition". Could you elaborate on
> > this? Do we need to change the comment?
>
> The comment is probably wrong, since you can connect the SoCFPGA
> external oscillator input to any applicable xtal ?

Right. Could you delete that comment then with this patch to
prevent confusion?

Regards,
Simon

Re: [PATCH 1/2] ARM: socfpga: Permit overriding the default timer frequency

[Simon Goldschmidt]

Am 15.02.2020 um 15:02 schrieb Marek Vasut:
> The default timer rate may be different than 25 MHz, permit overriding
> the default rate in board configuration file. Ultimatelly, this should
> be properly handled by a clock driver, however that is not available
> on Gen5 yet.

Sigh, yes, I still haven't found the time to fight those size problems I
have... :-(

> 
> Signed-off-by: Marek Vasut 
> Cc: Ley Foon Tan 
> Cc: Simon Goldschmidt 
> ---
>  include/configs/socfpga_common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 8d10469e7c..8c5dcfa57c 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -98,8 +98,10 @@

Just above this line, there's this comment: "This timer uses eosc1,
whose clock frequency is fixed at any condition".

While I'm ok with the change below, it does look a bit funny to make
this overriable if it's "fixed at any condition". Could you elaborate on
this? Do we need to change the comment?

Regards,
Simon

>  #define CONFIG_SYS_TIMERBASE SOCFPGA_OSC1TIMER0_ADDRESS
>  #define CONFIG_SYS_TIMER_COUNTS_DOWN
>  #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE + 0x4)
> +#ifndef CONFIG_SYS_TIMER_RATE
>  #define CONFIG_SYS_TIMER_RATE2500
>  #endif
> +#endif
>  
>  /*
>   * L4 Watchdog
> 

Re: [PATCH 10/33] mtd: Rename free() to rfree()

[Simon Goldschmidt]

On Wed, Feb 12, 2020 at 6:14 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Wed, 12 Feb 2020 at 06:14, Masahiro Yamada  wrote:
> >
> > On Mon, Jan 13, 2020 at 4:08 AM Simon Glass  wrote:
> > >
> > > This function name conflicts with our desire to #define free() to
> > > something else on sandbox. Since it deals with resources, rename it to
> > > rfree().
> > >
> > > Signed-off-by: Simon Glass 
> >
> >
> > I noticed this commit was merged recently.
> >
> > Now 'free' is a reserved keyword
> > you cannot use in U-Boot.
> >
> >
> > Commit cc92c3c thru cf23c7c are horrible.
> >
> >
> > Commit cfda60f should have used
> > 'static inline' instead of #define.
> >
> > I cannot believe it.
>
> Are you sure you understand the problem I was trying to solve? I am
> using dlmalloc's existing means of adding a prefix, but I'm sure we
> could change it to another way.
>
> If we define malloc() as dlmalloc() in dlmalloc.c, then we could add a
> declaration in dlmalloc.h that uses static inline to convert calls to
> malloc() to call dlmalloc(). Then anything that doesn't include
> malloc.h would still call the C library malloc(). Is that what you are
> thinking?

There is no "malloc()" in dlmalloc.c. It is called "mALLOc()" and by defining
USE_DL_PREFIX, you already have converted that to be linked as "dlmalloc()".

I think there should be no difference in who calls what when converting your
defines to static inline functions.

And yes, I also dislike the other patches that remove all occurrences of
'free'. I think without knowing the backgrounds of your patches, that just
looks strange.

Regards,
Simon

>
> I did look at using a link script instead but it is pretty messy.
>
> What do you mean by 'free' being a reserved keyword? Where? So is
> 'rfree' a good substitute or do you suggest something else?
>
> Regards,
> Simon

Re: [PATCH v5 00/20] Refactor the architecture parts of mt7628

[Simon Goldschmidt]

On Thu, Feb 13, 2020 at 9:42 AM Weijie Gao  wrote:
>
> On Thu, 2020-02-13 at 08:48 +0100, Simon Goldschmidt wrote:
> > On Wed, Feb 12, 2020 at 10:43 AM Weijie Gao  wrote:
> > >
> > > This patch series are divided into two parts:
> > >
> > > The main part is to rewrite the whole architecture code of mt7628:
> > > * Lock parts of the d-cache for initial stack so the rest of the code can
> > >   be reimplemented in C.
> > > * Memory controller & DDR initialization have been fully written to 
> > > support
> > >   detecting DDR size automatically.
> > > * DDR calibration has also been reimplemented with a clear logic.
> > > * Implemented a new sysreset driver to take advantage of the reset
> > >   controller so we can drop the use of syscon-based sysreset to reduce 
> > > size.
> > >
> > > The second part is to add SPL support for mt7628:
> > > * With SPL enabled we can build the ROM-bootable and RAM-bootable binary
> > >   simultaneously, and we can drop RAM boot related configs and defconfig
> > >   files.
> > > * Generate compressed u-boot.bin image for SPL to reduce size of final
> > >   combined binary.
> > > * Enable DM support for SPL for a more flexible device probing.
> > > * Add a demo board (mt7628_rfb) aims at router application.
> > >
> > > Changes since v2:
> > > * Dropped a patch which removes unused parts of mt7628a.dtsi
> > > * Move lzma decompression support to common spl_nor.c
> > > * Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
> > >
> > > Changes since v3:
> > > * Rebased on newest master branch
> > > * Add a test for binman etype u-boot-lzma-img to make sure binman passes 
> > > 100%
> > >   code coverage
> > > * Use u-boot-with-spl.bin for SPL-enabled output file
> > > * Remove unused code from spl_nor loader.
> >
> > No changes for v5 (since v4)?
>
> v5 is based on v3, for replacing v4. Because v4 has an obvious mistake.
> Modifying based on v3 is more clear than on v4.

Hm, ok, you probably should have mentioned that somewhere. I got confused.

Regards,
Simon

>
> >
> > Regards,
> > Simon
> >
> > >
> > > Weijie Gao (20):
> > >   mips: add support to restore exception vector base before booting
> > > linux
> > >   mips: mtmips: add predefined i-cache/d-cache size and linesize
> > >   mips: add an option to support initialize SRAM for initial stack
> > >   mips: start.S: avoid overwriting outside gd when clearing global data
> > > in stack
> > >   sysreset: add reset controller based reboot driver
> > >   mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
> > >   configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips
> > > boards
> > >   mips: add a mtmips-specific field to architecture-specific global data
> > >   mips: add a option to support not reserving malloc space on initial
> > > stack
> > >   mips: mtmips: rewrite lowlevel codes of mt7628
> > >   dts: mtmips: add alternative pinmux node for uart2
> > >   mips: enable support for appending dtb to spl binary
> > >   mips: add an option to enable u_boot_list section for SPL loaders in
> > > u-boot-spl.lds
> > >   lib: enable lzma decompression support for SPL build
> > >   Makefile: add support to generate LZMA compressed u-boot image
> > >   tools: binman: add etype file for u-boot-lzma-img
> > >   spl: nor: add lzma decompression support for legacy image
> > >   mips: mtmips: add SPL support
> > >   mips: mtmips: enable SPL for all boards
> > >   mips: mtmips: add support for mt7628-rfb
> > >
> > >  Makefile  |  19 +
> > >  arch/mips/Kconfig |  66 
> > >  arch/mips/cpu/start.S |  16 +-
> > >  arch/mips/cpu/u-boot-spl.lds  |   4 +-
> > >  arch/mips/dts/Makefile|   1 +
> > >  arch/mips/dts/mediatek,mt7628-rfb.dts |  67 
> > >  arch/mips/dts/mt7628-u-boot.dtsi  |  56 +++
> > >  arch/mips/dts/mt7628a.dtsi|  17 +-
> > >  arch/mips/include/asm/global_data.h   |   3 +
> > >  arch/mips/include/asm/u-boot-mips.h   |   2 +
> > >  arch/mips/lib/bootm.c |   3 +
> > >  arch/mips/lib/traps.c |  19 +
> > >  arch/mips/mach-mtm

Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

On Thu, Feb 13, 2020 at 8:53 AM Stefan  wrote:
>
> Hi Simon,
>
> On 13.02.20 08:40, Simon Goldschmidt wrote:
> > Sorry if it seems I ignored this mail yesterday, I just found it now :)
> >
> > On Wed, Feb 12, 2020 at 10:05 AM Stefan Roese  wrote:
> >>
> >> On 12.02.20 09:57, Weijie Gao wrote:
> >>
> >> 
> >>
> >>>> And more general: why do we need to code this in every loader? I think 
> >>>> it would
> >>>> be preferrable to have the loader load the binary data and do the 
> >>>> decompression
> >>>> (and entry_point assignment) in a central place so that all loaders can 
> >>>> benefit
> >>>> from compression. As it is now, we are duplicating code when 
> >>>> implementing LZMA
> >>>> in the next loader.
> >>
> >> I agree with Simon, that it would make sense to move this code into a
> >> even more generic location, so that other "loaders" can also use this
> >> feature. I know, that I suggested to add it here and I think we can
> >> make this move into the common SPL interface at a later point, after
> >> this patch set has been integrated.
> >
> > My concern is that we add poor code now and that cleanup at a "later point"
> > just gets forgotten.
>
> I understand.
>
> > To me, this patch looks like another "get the stuff I need in fast" thing,
> > without thinking about overall code quality. Yes it might be more work to
> > do it properly, but in my opinion, the result will be code that is easier to
> > maintain in the long run.
>
> I fully agree. But I already pushed Weijie to make many enhancements to
> the code and I fear that this work gets just too complex (time
> consuming) right now. As this type of generalization is not restricted
> on this new lzma implementation, but will very likely touch other
> features as well.
>
> So again, I'm still okay with adding this feature for spi_nor only right
> now. But if Weijie volunteers to move it to a even more generic
> location, that would be very welcome of course. ;)

Ok, I'm not the one in charge to decide if it's ok to merge this code.

Regards,
Simon

>
> Thanks,
> Stefan

Re: [PATCH v5 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

On Wed, Feb 12, 2020 at 10:46 AM Weijie Gao  wrote:
>
> This patch adds support for decompressing LZMA compressed u-boot payload in
> legacy uImage format.
>
> Using this patch together with u-boot-lzma.img is useful for NOR flashes as
> they can reduce the size and load time of u-boot payload.
>
> Reviewed-by: Stefan Roese 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v3: removed unused code. add description for cache flushing

This is v5. What has changed since v4?

> ---
>  common/spl/spl_nor.c | 51 +++-
>  1 file changed, 46 insertions(+), 5 deletions(-)
>
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index b1e79b9ded..b8e133e7b6 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -4,8 +4,17 @@
>   */
>
>  #include 
> +#include 
>  #include 
>
> +#include 
> +#include 
> +#include 
> +
> +#ifndef CONFIG_SYS_BOOTM_LEN
> +#define CONFIG_SYS_BOOTM_LEN   (8 << 20)
> +#endif
> +
>  static ulong spl_nor_load_read(struct spl_load_info *load, ulong sector,
>ulong count, void *buf)
>  {
> @@ -27,6 +36,9 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
> int ret;
> __maybe_unused const struct image_header *header;
> __maybe_unused struct spl_load_info load;
> +   __maybe_unused SizeT lzma_len;
> +   struct image_header hdr;
> +   uintptr_t dataptr;
>
> /*
>  * Loading of the payload to SDRAM is done with skipping of
> @@ -107,14 +119,43 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
>   spl_nor_get_uboot_base());
> }
>
> -   ret = spl_parse_image_header(spl_image,
> -   (const struct image_header 
> *)spl_nor_get_uboot_base());
> +   /* Payload image may not be aligned, so copy it for safety. */
> +   memcpy(, (void *)spl_nor_get_uboot_base(), sizeof(hdr));
> +   ret = spl_parse_image_header(spl_image, );
> if (ret)
> return ret;
>
> -   memcpy((void *)(unsigned long)spl_image->load_addr,
> -  (void *)(spl_nor_get_uboot_base() + sizeof(struct 
> image_header)),
> -  spl_image->size);
> +   dataptr = spl_nor_get_uboot_base() + sizeof(struct image_header);
> +
> +   switch (image_get_comp()) {
> +   case IH_COMP_NONE:
> +   memmove((void *)(unsigned long)spl_image->load_addr,
> +   (void *)dataptr, spl_image->size);
> +   break;
> +#if IS_ENABLED(CONFIG_SPL_LZMA)
> +   case IH_COMP_LZMA:
> +   lzma_len = CONFIG_SYS_BOOTM_LEN;
> +
> +   ret = lzmaBuffToBuffDecompress((void *)spl_image->load_addr,
> +  _len, (void *)dataptr,
> +  spl_image->size);

Is using CONFIG_SYS_BOOTM_LEN correct here at all? The name says it is used for
bootm but now it is used for SPL loading U-Boot as well. How do we know this is
the available memory size for both use cases? (And no, you're not adding this,
it is being used in spl_fit.c already. Still, I'm not sure this is correct.)

> +
> +   if (ret) {
> +   printf("LZMA decompression error: %d\n", ret);
> +   return ret;
> +   }
> +
> +   spl_image->size = lzma_len;
> +   break;
> +#endif
> +   default:
> +   debug("Compression method %s is not supported\n",
> + genimg_get_comp_short_name(image_get_comp()));
> +   return -EINVAL;
> +   }
> +
> +   /* Flush instruction cache */

Is this "add description for cache flushing" mentioned in the log above? I can
see from the function name that you're flushing cache. Only I still don't see
why this is necessary here (but not in the rest of the code where SPL starts a
U-Boot image).

Regards,
Simon

> +   flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
>
> return 0;
>  }
> --
> 2.17.1

Re: [PATCH v5 00/20] Refactor the architecture parts of mt7628

[Simon Goldschmidt]

On Wed, Feb 12, 2020 at 10:43 AM Weijie Gao  wrote:
>
> This patch series are divided into two parts:
>
> The main part is to rewrite the whole architecture code of mt7628:
> * Lock parts of the d-cache for initial stack so the rest of the code can
>   be reimplemented in C.
> * Memory controller & DDR initialization have been fully written to support
>   detecting DDR size automatically.
> * DDR calibration has also been reimplemented with a clear logic.
> * Implemented a new sysreset driver to take advantage of the reset
>   controller so we can drop the use of syscon-based sysreset to reduce size.
>
> The second part is to add SPL support for mt7628:
> * With SPL enabled we can build the ROM-bootable and RAM-bootable binary
>   simultaneously, and we can drop RAM boot related configs and defconfig
>   files.
> * Generate compressed u-boot.bin image for SPL to reduce size of final
>   combined binary.
> * Enable DM support for SPL for a more flexible device probing.
> * Add a demo board (mt7628_rfb) aims at router application.
>
> Changes since v2:
> * Dropped a patch which removes unused parts of mt7628a.dtsi
> * Move lzma decompression support to common spl_nor.c
> * Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
>
> Changes since v3:
> * Rebased on newest master branch
> * Add a test for binman etype u-boot-lzma-img to make sure binman passes 100%
>   code coverage
> * Use u-boot-with-spl.bin for SPL-enabled output file
> * Remove unused code from spl_nor loader.

No changes for v5 (since v4)?

Regards,
Simon

>
> Weijie Gao (20):
>   mips: add support to restore exception vector base before booting
> linux
>   mips: mtmips: add predefined i-cache/d-cache size and linesize
>   mips: add an option to support initialize SRAM for initial stack
>   mips: start.S: avoid overwriting outside gd when clearing global data
> in stack
>   sysreset: add reset controller based reboot driver
>   mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
>   configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips
> boards
>   mips: add a mtmips-specific field to architecture-specific global data
>   mips: add a option to support not reserving malloc space on initial
> stack
>   mips: mtmips: rewrite lowlevel codes of mt7628
>   dts: mtmips: add alternative pinmux node for uart2
>   mips: enable support for appending dtb to spl binary
>   mips: add an option to enable u_boot_list section for SPL loaders in
> u-boot-spl.lds
>   lib: enable lzma decompression support for SPL build
>   Makefile: add support to generate LZMA compressed u-boot image
>   tools: binman: add etype file for u-boot-lzma-img
>   spl: nor: add lzma decompression support for legacy image
>   mips: mtmips: add SPL support
>   mips: mtmips: enable SPL for all boards
>   mips: mtmips: add support for mt7628-rfb
>
>  Makefile  |  19 +
>  arch/mips/Kconfig |  66 
>  arch/mips/cpu/start.S |  16 +-
>  arch/mips/cpu/u-boot-spl.lds  |   4 +-
>  arch/mips/dts/Makefile|   1 +
>  arch/mips/dts/mediatek,mt7628-rfb.dts |  67 
>  arch/mips/dts/mt7628-u-boot.dtsi  |  56 +++
>  arch/mips/dts/mt7628a.dtsi|  17 +-
>  arch/mips/include/asm/global_data.h   |   3 +
>  arch/mips/include/asm/u-boot-mips.h   |   2 +
>  arch/mips/lib/bootm.c |   3 +
>  arch/mips/lib/traps.c |  19 +
>  arch/mips/mach-mtmips/Kconfig | 135 +++
>  arch/mips/mach-mtmips/Makefile|   8 +-
>  arch/mips/mach-mtmips/cpu.c   |  58 +---
>  arch/mips/mach-mtmips/ddr_cal.c   | 211 +++
>  arch/mips/mach-mtmips/ddr_calibrate.c | 309 -
>  arch/mips/mach-mtmips/ddr_init.c  | 194 +++
>  arch/mips/mach-mtmips/include/mach/ddr.h  |  52 +++
>  arch/mips/mach-mtmips/include/mach/mc.h   | 180 ++
>  arch/mips/mach-mtmips/include/mach/serial.h   |  13 +
>  arch/mips/mach-mtmips/lowlevel_init.S | 328 --
>  arch/mips/mach-mtmips/mt7628/Makefile |   6 +
>  arch/mips/mach-mtmips/mt7628/ddr.c| 173 +
>  arch/mips/mach-mtmips/mt7628/init.c   | 109 ++
>  arch/mips/mach-mtmips/mt7628/lowlevel_init.S  | 161 +
>  arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++
>  arch/mips/mach-mtmips/mt7628/serial.c |  34 ++
>  arch/mips/mach-mtmips/mt76xx.h|  32 --
>  arch/mips/mach-mtmips/spl.c   |  44 +++
>  board/gardena/smart-gateway-mt7688/board.c|   2 +
>  board/mediatek/mt7628/Kconfig |  12 +
>  board/mediatek/mt7628/MAINTAINERS |   7 +
>  board/mediatek/mt7628/Makefile|   3 +
>  board/mediatek/mt7628/board.c |   8 +
>  common/spl/spl_nor.c

Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

On Thu, Feb 13, 2020 at 3:53 AM Weijie Gao  wrote:
>
> On Wed, 2020-02-12 at 11:18 +0100, Simon Goldschmidt wrote:
> > On Wed, Feb 12, 2020 at 9:57 AM Weijie Gao  wrote:
> > >
> > > On Wed, 2020-02-12 at 09:22 +0100, Simon Goldschmidt wrote:
> > > > On Wed, Feb 12, 2020 at 8:49 AM Weijie Gao  
> > > > wrote:
> > > > >
> > > > > This patch adds support for decompressing LZMA compressed u-boot 
> > > > > payload in
> > > > > legacy uImage format.
> > > > >
> > > > > Using this patch together with u-boot-lzma.img is useful for NOR 
> > > > > flashes as
> > > > > they can reduce the size and load time of u-boot payload.
> > > > >
> > > > > Reviewed-by: Stefan Roese 
> > > > > Signed-off-by: Weijie Gao 
> > > > > ---
> > > > > Changes since v3: none
> > > > > ---
> > > > >  common/spl/spl_nor.c | 59 
> > > > > 
> > > > >  1 file changed, 54 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> > > > > index b1e79b9ded..7c81fb28f6 100644
> > > > > --- a/common/spl/spl_nor.c
> > > > > +++ b/common/spl/spl_nor.c
> > > > > @@ -4,8 +4,19 @@
> > > > >   */
> > > > >
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >
> > > > > +#if IS_ENABLED(CONFIG_SPL_LZMA)
> > > >
> > > > Is this guard really necessary? What happens without it?
> > >
> > > Actually nothing will happen.
> >
> > So can you drop it?
>
> Already dropped in v5.

Which v5? Oh, I see you sent a v5 just about 2 hours after v4?
That's way too fast to have a discussion about a version.

>
> >
> > >
> > > >
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#endif
> > > > > +
> > > > > +#ifndef CONFIG_SYS_BOOTM_LEN
> > > > > +#define CONFIG_SYS_BOOTM_LEN   (8 << 20)
> > > > > +#endif
> > > >
> > > > This looks strange. I think we should have a central place where this 
> > > > is defined
> > > > to a default value. As it is now, you are adding the 3rd place where 
> > > > this is
> > > > defined to a "fallback" value, each with a different value.
> > >
> > > This is copied from common/bootm.c. It does exist in two files:
> > > common/bootm.c and common/spl/spl_fit.c.
> >
> > Exactly. It is copied. Yet another duplication, which is bad.
> > And it is not even copied 1:1, as those two files define a different default
> > value and you define yet another different default value.
>
> Actually the same value. from common/bootm.c, 0x80 = (8 << 20).

Same value, different code. Still ugly and hard to maintain to have this
code copied (*and* not copied literally, even if the resulting value is the
same).

>
> >
> > >
> > > >
> > > > > +
> > > > >  static ulong spl_nor_load_read(struct spl_load_info *load, ulong 
> > > > > sector,
> > > > >ulong count, void *buf)
> > > > >  {
> > > > > @@ -27,6 +38,9 @@ static int spl_nor_load_image(struct spl_image_info 
> > > > > *spl_image,
> > > > > int ret;
> > > > > __maybe_unused const struct image_header *header;
> > > > > __maybe_unused struct spl_load_info load;
> > > > > +   __maybe_unused SizeT lzma_len;
> > > > > +   struct image_header hdr;
> > > > > +   uintptr_t dataptr;
> > > > >
> > > > > /*
> > > > >  * Loading of the payload to SDRAM is done with skipping of
> > > > > @@ -107,14 +121,49 @@ static int spl_nor_load_image(struct 
> > > > > spl_image_info *spl_image,
> > > > >   
> > > > > spl_nor_get_uboot_base());
> > > > > }
> > > > >
> > > > > -   ret = spl_parse_image_header(spl_image,
> > > > > -   (const struct image_header 
> > > > > *)spl_nor_get_uboot_base());

Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

Sorry if it seems I ignored this mail yesterday, I just found it now :)

On Wed, Feb 12, 2020 at 10:05 AM Stefan Roese  wrote:
>
> On 12.02.20 09:57, Weijie Gao wrote:
>
> 
>
> >> And more general: why do we need to code this in every loader? I think it 
> >> would
> >> be preferrable to have the loader load the binary data and do the 
> >> decompression
> >> (and entry_point assignment) in a central place so that all loaders can 
> >> benefit
> >> from compression. As it is now, we are duplicating code when implementing 
> >> LZMA
> >> in the next loader.
>
> I agree with Simon, that it would make sense to move this code into a
> even more generic location, so that other "loaders" can also use this
> feature. I know, that I suggested to add it here and I think we can
> make this move into the common SPL interface at a later point, after
> this patch set has been integrated.

My concern is that we add poor code now and that cleanup at a "later point"
just gets forgotten.

To me, this patch looks like another "get the stuff I need in fast" thing,
without thinking about overall code quality. Yes it might be more work to
do it properly, but in my opinion, the result will be code that is easier to
maintain in the long run.

Regards,
Simon

>
> > This feature is originally designed for the case that u-boot is stored
> > in a small capacity storage device, mostly NOR flashes, and the space
> > reserved for u-boot is very small. Most loaders (MMC, NAND, SATA, ...)
> > do not need this at all.
>
> Yes and no. As you pointed out, it might be faster to load and
> decompress a smaller U-Boot proper image than just loading a bigger
> image. So other platforms might very well take advantage of this
> feature. And size increase is always a big issue in modern U-Boot. So a
> smaller image is always welcome. ;)
>
> Thanks,
> Stefan

Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

On Wed, Feb 12, 2020 at 9:57 AM Weijie Gao  wrote:
>
> On Wed, 2020-02-12 at 09:22 +0100, Simon Goldschmidt wrote:
> > On Wed, Feb 12, 2020 at 8:49 AM Weijie Gao  wrote:
> > >
> > > This patch adds support for decompressing LZMA compressed u-boot payload 
> > > in
> > > legacy uImage format.
> > >
> > > Using this patch together with u-boot-lzma.img is useful for NOR flashes 
> > > as
> > > they can reduce the size and load time of u-boot payload.
> > >
> > > Reviewed-by: Stefan Roese 
> > > Signed-off-by: Weijie Gao 
> > > ---
> > > Changes since v3: none
> > > ---
> > >  common/spl/spl_nor.c | 59 
> > >  1 file changed, 54 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> > > index b1e79b9ded..7c81fb28f6 100644
> > > --- a/common/spl/spl_nor.c
> > > +++ b/common/spl/spl_nor.c
> > > @@ -4,8 +4,19 @@
> > >   */
> > >
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > > +#if IS_ENABLED(CONFIG_SPL_LZMA)
> >
> > Is this guard really necessary? What happens without it?
>
> Actually nothing will happen.

So can you drop it?

>
> >
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#endif
> > > +
> > > +#ifndef CONFIG_SYS_BOOTM_LEN
> > > +#define CONFIG_SYS_BOOTM_LEN   (8 << 20)
> > > +#endif
> >
> > This looks strange. I think we should have a central place where this is 
> > defined
> > to a default value. As it is now, you are adding the 3rd place where this is
> > defined to a "fallback" value, each with a different value.
>
> This is copied from common/bootm.c. It does exist in two files:
> common/bootm.c and common/spl/spl_fit.c.

Exactly. It is copied. Yet another duplication, which is bad.
And it is not even copied 1:1, as those two files define a different default
value and you define yet another different default value.

>
> >
> > > +
> > >  static ulong spl_nor_load_read(struct spl_load_info *load, ulong sector,
> > >ulong count, void *buf)
> > >  {
> > > @@ -27,6 +38,9 @@ static int spl_nor_load_image(struct spl_image_info 
> > > *spl_image,
> > > int ret;
> > > __maybe_unused const struct image_header *header;
> > > __maybe_unused struct spl_load_info load;
> > > +   __maybe_unused SizeT lzma_len;
> > > +   struct image_header hdr;
> > > +   uintptr_t dataptr;
> > >
> > > /*
> > >  * Loading of the payload to SDRAM is done with skipping of
> > > @@ -107,14 +121,49 @@ static int spl_nor_load_image(struct spl_image_info 
> > > *spl_image,
> > >   spl_nor_get_uboot_base());
> > > }
> > >
> > > -   ret = spl_parse_image_header(spl_image,
> > > -   (const struct image_header 
> > > *)spl_nor_get_uboot_base());
> > > +   /* Payload image may not be aligned, so copy it for safety. */
> > > +   memcpy(, (void *)spl_nor_get_uboot_base(), sizeof(hdr));
> > > +   ret = spl_parse_image_header(spl_image, );
> > > if (ret)
> > > return ret;
> > >
> > > -   memcpy((void *)(unsigned long)spl_image->load_addr,
> > > -  (void *)(spl_nor_get_uboot_base() + sizeof(struct 
> > > image_header)),
> > > -  spl_image->size);
> > > +   dataptr = spl_nor_get_uboot_base() + sizeof(struct image_header);
> > > +
> > > +   switch (image_get_comp()) {
> > > +   case IH_COMP_NONE:
> >
> > I guess this will increase the size even when LZMA is not enabled, right?
> > Do you have numbers for that?
>
> Yes. about 8KiB on mips32r2 platform.

8KiB more in SPL even without LZMA enabled? That sounds a bit too high?

>
> >
> > > +   memmove((void *)(unsigned long)spl_image->load_addr,
> > > +   (void *)dataptr, spl_image->size);
> > > +   break;
> > > +#if IS_ENABLED(CONFIG_SPL_LZMA)
> > > +   case IH_COMP_LZMA:
> > > +   lzma_len = CONFIG_SYS_BOOTM_LEN;
> > > +
> > > +   ret = lzmaBuffToBuffDecompress((void 
> > > *)spl_image->load_addr,
>

Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Simon Goldschmidt]

On Wed, Feb 12, 2020 at 8:49 AM Weijie Gao  wrote:
>
> This patch adds support for decompressing LZMA compressed u-boot payload in
> legacy uImage format.
>
> Using this patch together with u-boot-lzma.img is useful for NOR flashes as
> they can reduce the size and load time of u-boot payload.
>
> Reviewed-by: Stefan Roese 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v3: none
> ---
>  common/spl/spl_nor.c | 59 
>  1 file changed, 54 insertions(+), 5 deletions(-)
>
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index b1e79b9ded..7c81fb28f6 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -4,8 +4,19 @@
>   */
>
>  #include 
> +#include 
>  #include 
>
> +#if IS_ENABLED(CONFIG_SPL_LZMA)

Is this guard really necessary? What happens without it?

> +#include 
> +#include 
> +#include 
> +#endif
> +
> +#ifndef CONFIG_SYS_BOOTM_LEN
> +#define CONFIG_SYS_BOOTM_LEN   (8 << 20)
> +#endif

This looks strange. I think we should have a central place where this is defined
to a default value. As it is now, you are adding the 3rd place where this is
defined to a "fallback" value, each with a different value.

> +
>  static ulong spl_nor_load_read(struct spl_load_info *load, ulong sector,
>ulong count, void *buf)
>  {
> @@ -27,6 +38,9 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
> int ret;
> __maybe_unused const struct image_header *header;
> __maybe_unused struct spl_load_info load;
> +   __maybe_unused SizeT lzma_len;
> +   struct image_header hdr;
> +   uintptr_t dataptr;
>
> /*
>  * Loading of the payload to SDRAM is done with skipping of
> @@ -107,14 +121,49 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
>   spl_nor_get_uboot_base());
> }
>
> -   ret = spl_parse_image_header(spl_image,
> -   (const struct image_header 
> *)spl_nor_get_uboot_base());
> +   /* Payload image may not be aligned, so copy it for safety. */
> +   memcpy(, (void *)spl_nor_get_uboot_base(), sizeof(hdr));
> +   ret = spl_parse_image_header(spl_image, );
> if (ret)
> return ret;
>
> -   memcpy((void *)(unsigned long)spl_image->load_addr,
> -  (void *)(spl_nor_get_uboot_base() + sizeof(struct 
> image_header)),
> -  spl_image->size);
> +   dataptr = spl_nor_get_uboot_base() + sizeof(struct image_header);
> +
> +   switch (image_get_comp()) {
> +   case IH_COMP_NONE:

I guess this will increase the size even when LZMA is not enabled, right?
Do you have numbers for that?

> +   memmove((void *)(unsigned long)spl_image->load_addr,
> +   (void *)dataptr, spl_image->size);
> +   break;
> +#if IS_ENABLED(CONFIG_SPL_LZMA)
> +   case IH_COMP_LZMA:
> +   lzma_len = CONFIG_SYS_BOOTM_LEN;
> +
> +   ret = lzmaBuffToBuffDecompress((void *)spl_image->load_addr,
> +  _len, (void *)dataptr,
> +  spl_image->size);
> +
> +   if (ret) {
> +   printf("LZMA decompression error: %d\n", ret);
> +   return ret;
> +   }
> +
> +   spl_image->size = lzma_len;
> +   break;
> +#endif
> +   default:
> +   debug("Compression method %s is not supported\n",
> + genimg_get_comp_short_name(image_get_comp()));
> +   return -EINVAL;
> +   }
> +
> +   flush_cache((unsigned long)spl_image->load_addr, spl_image->size);

Why is this necessary? I can't see this from the commit message.

> +
> +   /*
> +* If the image did not provide an entry point, assume the entry point
> +* is the same as its load address.
> +*/
> +   if (!spl_image->entry_point)
> +   spl_image->entry_point = spl_image->load_addr;

And another change that is not described in the commit message.

And more general: why do we need to code this in every loader? I think it would
be preferrable to have the loader load the binary data and do the decompression
(and entry_point assignment) in a central place so that all loaders can benefit
from compression. As it is now, we are duplicating code when implementing LZMA
in the next loader.

Regards,
Simon

>
> return 0;
>  }
> --
> 2.17.1

Re: [PATCH v2 06/10] mmc: am654_sdhci: Implement workaround for card detect

[Simon Goldschmidt]

+Simon Glass for the xxx_get_ops() functions in DM

On Mon, Feb 10, 2020 at 10:46 AM Faiz Abbas  wrote:
>
> Simon,
>
> On 29/01/20 7:48 pm, Simon Goldschmidt wrote:
> > On Fri, Jan 24, 2020 at 12:52 PM Faiz Abbas  wrote:
> >>
> >> The 4 bit MMC controllers have an internal debounce for the SDCD line
> >> with a debounce delay of 1 second. Therefore, after clocks to the IP are
> >> enabled, software has to wait for this time before it can power on the
> >> controller.
> >>
> >> Add an init() callback which polls on sdcd for a maximum of 2 seconds
> >> before switching on power to the controller or (in the case of no card)
> >> returning a ENOMEDIUM. This pushes the 1 second wait time to when the
> >> card is actually needed rather than at every probe() making sure that
> >> users who don't insert an SD card in the slot don't have to wait such a
> >> long time.
> >>
> >> Signed-off-by: Faiz Abbas 
> >> Signed-off-by: Lokesh Vutla 
> >> ---
> >>  drivers/mmc/am654_sdhci.c | 35 ---
> >>  1 file changed, 32 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> >> index ff0a81eaab..ccae3fea31 100644
> >> --- a/drivers/mmc/am654_sdhci.c
> >> +++ b/drivers/mmc/am654_sdhci.c
> >> @@ -254,7 +254,7 @@ const struct am654_driver_data j721e_4bit_drv_data = {
> >> .flags = IOMUX_PRESENT,
> >>  };
> >>
> >> -int am654_sdhci_init(struct am654_sdhci_plat *plat)
> >> +int am654_sdhci_init_phy(struct am654_sdhci_plat *plat)
> >>  {
> >> u32 ctl_cfg_2 = 0;
> >> u32 mask, val;
> >> @@ -331,8 +331,37 @@ static int sdhci_am654_get_otap_delay(struct udevice 
> >> *dev,
> >> return 0;
> >>  }
> >>
> >> +#define MAX_SDCD_DEBOUNCE_TIME 2000
> >> +int am654_sdhci_init(struct udevice *dev)
> >> +{
> >> +   struct am654_sdhci_plat *plat = dev_get_platdata(dev);
> >> +   struct mmc *mmc = mmc_get_mmc_dev(dev);
> >> +   struct sdhci_host *host = mmc->priv;
> >> +   unsigned long start;
> >> +   int val;
> >> +
> >> +   /*
> >> +* The controller takes about 1 second to debounce the card detect 
> >> line
> >> +* and doesn't let us power on until that time is up. Instead of 
> >> waiting
> >> +* for 1 second at every stage, poll on the CARD_PRESENT bit upto a
> >> +* maximum of 2 seconds to be safe..
> >> +*/
> >> +   start = get_timer(0);
> >> +   do {
> >> +   if (get_timer(start) > MAX_SDCD_DEBOUNCE_TIME)
> >> +   return -ENOMEDIUM;
> >> +
> >> +   val = mmc_getcd(host->mmc);
> >> +   } while (!val);
> >> +
> >> +   am654_sdhci_init_phy(plat);
> >> +
> >> +   return sdhci_init(mmc);
> >> +}
> >> +
> >>  static int am654_sdhci_probe(struct udevice *dev)
> >>  {
> >> +   struct dm_mmc_ops *ops = mmc_get_ops(dev);
> >> struct am654_driver_data *drv_data =
> >> (struct am654_driver_data 
> >> *)dev_get_driver_data(dev);
> >> struct am654_sdhci_plat *plat = dev_get_platdata(dev);
> >> @@ -373,9 +402,9 @@ static int am654_sdhci_probe(struct udevice *dev)
> >>
> >> regmap_init_mem_index(dev_ofnode(dev), >base, 1);
> >>
> >> -   am654_sdhci_init(plat);
> >> +   ops->init = am654_sdhci_init;
> >
> > Is this a valid approach? I mean, many drivers create their 'ops' const like
> > this:
> >static const struct ram_ops altera_gen5_sdram_ops (...)
> >
> > That would mean you write to a const region. I know the U-Boot sources make
> > this easy for you by providing the ops non-const via mmc_get_ops, but I 
> > still
> > think this is not good.
> >
>
> Sorry I missed this earlier.
>
> I do see other drivers following this approach (see
> drivers/mmc/sdhci-cadence.c). The issue is that I then have to export
> every API in drivers/mmc/sdhci.c:694
>
> const struct dm_mmc_ops sdhci_ops = {
> .send_cmd   = sdhci_send_command,
> .set_ios= sdhci_set_ios,
> .get_cd = sdhci_get_cd,
> #ifdef MMC_SUPPORTS_TUNING
> .execute_tuning = sdhci_execute_tuning,
> #endif
>

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Fri, Feb 7, 2020 at 1:27 PM Marek Vasut  wrote:
>
> On 2/7/20 1:09 PM, Simon Goldschmidt wrote:
> > On Fri, Feb 7, 2020 at 8:56 AM Marek Vasut  wrote:
> >>
> >> On 2/6/20 3:57 PM, Simon Goldschmidt wrote:
> >>> On Thu, Feb 6, 2020 at 3:41 PM Nico Becker  
> >>> wrote:
> >>>>
> >>>> Am 06.02.2020 um 14:00 schrieb Marek Vasut:
> >>>>> On 2/6/20 1:57 PM, Nico Becker wrote:
> >>>>>> Am 06.02.2020 um 12:53 schrieb Marek Vasut:
> >>>>>>> On 2/6/20 11:50 AM, Nico Becker wrote:
> >>>>>>>> Hello,
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>> after removing the function socfpga_sdram_apply_static_cfg() in
> >>>>>>>> misc_gen5 we can not use the FPGA2SDRAM bridge.
> >>>>>>>>
> >>>>>>>> Without the apply static cfg the kernel crash every time,
> >>>>>>>> if we try to write @ the fpga2sdram bridge. After an soft reset
> >>>>>>>> everything is working.
> >>>>>>>>
> >>>>>>>> If we add the socfpga_sdram_apply_static_cfg() in the
> >>>>>>>> u-boot source code, everything is fine.
> >>>>>>>> Now we can use the fpga2sdram bridge after power on.
> >>>>>>>>
> >>>>>>>> Our setup:
> >>>>>>>> - u-boot v2020.01
> >>>>>>>> - load and write fpga firmware
> >>>>>>>> - enable bridges
> >>>>>>>> - boot linux
> >>>>>>>>
> >>>>>>>> I have found some information at
> >>>>>>>> <https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> <http://u-boot.10912.n7.nabble.com/WG-Linux-hang-td314276.html>
> >>>>>>>
> >>>>>>> Can you send a patch which fixes this for you, with Fixes: tag ?
> >>>>>>> Then it would be clear what you changed.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>
> >>>>>> Hello,
> >>>>>> the code was removed @ commit c5f4b805.
> >>>>>
> >>>>> Did you read the commit message of that commit and what problem that was
> >>>>> solving ? Clearly, reverting the commit isn't the way to go. We need to
> >>>>> find a way to unbreak this for you, while not break other platforms.
> >>>>>
> >>>>>> I attached my patch, sorry for the format, i am new in this.
> >>>>>
> >>>>> [...]
> >>>>>
> >>>> Hi,
> >>>> yes i read the commit message.
> >>>>
> >>>> but i found no other option to enable the sdram bridges,
> >>>> without crashes/hanging up linux, with the removed source code.
> >>>>
> >>>> i ve found some more information @intel
> >>>> <https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/embedded/2016/how-and-when-can-i-enable-the-fpga2sdram-bridge-on-cyclone-v-soc.html>
> >>>>
> >>>> Intel talk about an bridge_enable_handoff in my opionion
> >>>> the cmd set the sram aply cfg
> >>>>
> >>>> /* add signle command to enable all bridges based on handoff */
> >>>> setenv("bridge_enable_handoff",
> >>>> "mw $fpgaintf ${fpgaintf_handoff}; "
> >>>> "go $fpga2sdram_apply; "
> >>>> "mw $fpga2sdram ${fpga2sdram_handoff}; "
> >>>> "mw $axibridge ${axibridge_handoff}; "
> >>>> "mw $l3remap ${l3remap_handoff} ");
> >>>>
> >>>> setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);
> >>>>
> >>>> /*
> >>>>   * Relocate the sdram_applycfg_ocram function to OCRAM and call it
> >>>>   */
> >>>> ENTRY(sdram_applycfg_uboot)
> >>>> PUSH{r4-r11, lr}/* save registers per AAPCS */
>

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Fri, Feb 7, 2020 at 8:56 AM Marek Vasut  wrote:
>
> On 2/6/20 3:57 PM, Simon Goldschmidt wrote:
> > On Thu, Feb 6, 2020 at 3:41 PM Nico Becker  
> > wrote:
> >>
> >> Am 06.02.2020 um 14:00 schrieb Marek Vasut:
> >>> On 2/6/20 1:57 PM, Nico Becker wrote:
> >>>> Am 06.02.2020 um 12:53 schrieb Marek Vasut:
> >>>>> On 2/6/20 11:50 AM, Nico Becker wrote:
> >>>>>> Hello,
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>>> after removing the function socfpga_sdram_apply_static_cfg() in
> >>>>>> misc_gen5 we can not use the FPGA2SDRAM bridge.
> >>>>>>
> >>>>>> Without the apply static cfg the kernel crash every time,
> >>>>>> if we try to write @ the fpga2sdram bridge. After an soft reset
> >>>>>> everything is working.
> >>>>>>
> >>>>>> If we add the socfpga_sdram_apply_static_cfg() in the
> >>>>>> u-boot source code, everything is fine.
> >>>>>> Now we can use the fpga2sdram bridge after power on.
> >>>>>>
> >>>>>> Our setup:
> >>>>>> - u-boot v2020.01
> >>>>>> - load and write fpga firmware
> >>>>>> - enable bridges
> >>>>>> - boot linux
> >>>>>>
> >>>>>> I have found some information at
> >>>>>> <https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge>
> >>>>>>
> >>>>>>
> >>>>>> <http://u-boot.10912.n7.nabble.com/WG-Linux-hang-td314276.html>
> >>>>>
> >>>>> Can you send a patch which fixes this for you, with Fixes: tag ?
> >>>>> Then it would be clear what you changed.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>
> >>>> Hello,
> >>>> the code was removed @ commit c5f4b805.
> >>>
> >>> Did you read the commit message of that commit and what problem that was
> >>> solving ? Clearly, reverting the commit isn't the way to go. We need to
> >>> find a way to unbreak this for you, while not break other platforms.
> >>>
> >>>> I attached my patch, sorry for the format, i am new in this.
> >>>
> >>> [...]
> >>>
> >> Hi,
> >> yes i read the commit message.
> >>
> >> but i found no other option to enable the sdram bridges,
> >> without crashes/hanging up linux, with the removed source code.
> >>
> >> i ve found some more information @intel
> >> <https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/embedded/2016/how-and-when-can-i-enable-the-fpga2sdram-bridge-on-cyclone-v-soc.html>
> >>
> >> Intel talk about an bridge_enable_handoff in my opionion
> >> the cmd set the sram aply cfg
> >>
> >> /* add signle command to enable all bridges based on handoff */
> >> setenv("bridge_enable_handoff",
> >> "mw $fpgaintf ${fpgaintf_handoff}; "
> >> "go $fpga2sdram_apply; "
> >> "mw $fpga2sdram ${fpga2sdram_handoff}; "
> >> "mw $axibridge ${axibridge_handoff}; "
> >> "mw $l3remap ${l3remap_handoff} ");
> >>
> >> setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);
> >>
> >> /*
> >>   * Relocate the sdram_applycfg_ocram function to OCRAM and call it
> >>   */
> >> ENTRY(sdram_applycfg_uboot)
> >> PUSH{r4-r11, lr}/* save registers per AAPCS */
> >>
> >> ldr r1, =sdram_applycfg_ocram
> >> ldr r2, =CONFIG_SYS_INIT_RAM_ADDR
> >> mov r3, r2
> >> ldmia   r1!, {r4 - r11}
> >> stmia   r3!, {r4 - r11}
> >> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> >> stmia   r3!, {r4 - r11} /* in the future */
> >> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> >> stmia   r3!, {r4 - r11} /* in the future */
> >> dsb
> >> isb
> >> blx r2  /* jump to OCRAM */
> >> POP {r4-r11, pc}
> >

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Thu, Feb 6, 2020 at 3:41 PM Nico Becker  wrote:
>
> Am 06.02.2020 um 14:00 schrieb Marek Vasut:
> > On 2/6/20 1:57 PM, Nico Becker wrote:
> >> Am 06.02.2020 um 12:53 schrieb Marek Vasut:
> >>> On 2/6/20 11:50 AM, Nico Becker wrote:
>  Hello,
> >>>
> >>> Hi,
> >>>
>  after removing the function socfpga_sdram_apply_static_cfg() in
>  misc_gen5 we can not use the FPGA2SDRAM bridge.
> 
>  Without the apply static cfg the kernel crash every time,
>  if we try to write @ the fpga2sdram bridge. After an soft reset
>  everything is working.
> 
>  If we add the socfpga_sdram_apply_static_cfg() in the
>  u-boot source code, everything is fine.
>  Now we can use the fpga2sdram bridge after power on.
> 
>  Our setup:
>  - u-boot v2020.01
>  - load and write fpga firmware
>  - enable bridges
>  - boot linux
> 
>  I have found some information at
>  
> 
> 
>  
> >>>
> >>> Can you send a patch which fixes this for you, with Fixes: tag ?
> >>> Then it would be clear what you changed.
> >>>
> >>> Thanks
> >>>
> >>
> >> Hello,
> >> the code was removed @ commit c5f4b805.
> >
> > Did you read the commit message of that commit and what problem that was
> > solving ? Clearly, reverting the commit isn't the way to go. We need to
> > find a way to unbreak this for you, while not break other platforms.
> >
> >> I attached my patch, sorry for the format, i am new in this.
> >
> > [...]
> >
> Hi,
> yes i read the commit message.
>
> but i found no other option to enable the sdram bridges,
> without crashes/hanging up linux, with the removed source code.
>
> i ve found some more information @intel
> 
>
> Intel talk about an bridge_enable_handoff in my opionion
> the cmd set the sram aply cfg
>
> /* add signle command to enable all bridges based on handoff */
> setenv("bridge_enable_handoff",
> "mw $fpgaintf ${fpgaintf_handoff}; "
> "go $fpga2sdram_apply; "
> "mw $fpga2sdram ${fpga2sdram_handoff}; "
> "mw $axibridge ${axibridge_handoff}; "
> "mw $l3remap ${l3remap_handoff} ");
>
> setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);
>
> /*
>   * Relocate the sdram_applycfg_ocram function to OCRAM and call it
>   */
> ENTRY(sdram_applycfg_uboot)
> PUSH{r4-r11, lr}/* save registers per AAPCS */
>
> ldr r1, =sdram_applycfg_ocram
> ldr r2, =CONFIG_SYS_INIT_RAM_ADDR
> mov r3, r2
> ldmia   r1!, {r4 - r11}
> stmia   r3!, {r4 - r11}
> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> stmia   r3!, {r4 - r11} /* in the future */
> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> stmia   r3!, {r4 - r11} /* in the future */
> dsb
> isb
> blx r2  /* jump to OCRAM */
> POP {r4-r11, pc}
> ENDPROC(sdram_applycfg_uboot)
>
>
> it could be an option to write the fpga firmware with u-boot,
> and do a soft reset.
> boot u-boot
> check fpga configuration state
> not configured write firmware reset
> if configured boot linux
>
> i ll check howto to determine the fpga configuration state
> and try this.

That doesn't look like a safe plan: what if you explicitly *want* a reboot
and want to reconfigure the FPGA then to ensure it is in a well-known state?

Marek, what were the problems why this has been removed? Aside from "is
confirmed to lead to a rare system hang when enabling bridges", the commit
message stays rather vague. Maybe that "apply config" bit should only be written
if explicitly configured so, but that would mean we need some kind of config
options included/coming with the FPGA image we program.

Oh, and by now I'm glad our own design connects to DDR via the main bus ;-)

Regards,
Simon

Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static

[Simon Goldschmidt]

Am 30.01.2020 um 23:21 schrieb Jaehoon Chung:

Hi Simon,

On 1/29/20 11:16 PM, Simon Goldschmidt wrote:

On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung  wrote:


On 1/24/20 8:52 PM, Faiz Abbas wrote:

Expose sdhci_init() as non-static.


Does it need to change to non-static?


And even if it needs to, can we have a reason *why* in the commit message?


When i read entire your series, it seems that doesn't need to change to 
non-static.
All of change that touched MMC code are only for your board.
I don't know Peng's opinion, but it's not my prefer.


+1!

We need to keep the core code clean of such hacks in order to keep the 
size small for constrained targets!


Regards,
Simon



Best Regards,
Jaehoon Chung



Thanks,
Simon



Best Regards,
Jaehoon Chung



Signed-off-by: Faiz Abbas 
Signed-off-by: Lokesh Vutla 
---
  drivers/mmc/sdhci.c | 2 +-
  include/sdhci.h | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 01fa5a9d4d..4fce85a0ea 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -618,7 +618,7 @@ static int sdhci_set_ios(struct mmc *mmc)
   return 0;
  }

-static int sdhci_init(struct mmc *mmc)
+int sdhci_init(struct mmc *mmc)
  {
   struct sdhci_host *host = mmc->priv;
  #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
diff --git a/include/sdhci.h b/include/sdhci.h
index 01addb7a60..0830e05d53 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -487,6 +487,7 @@ void sdhci_set_uhs_timing(struct sdhci_host *host);
  #ifdef CONFIG_DM_MMC
  /* Export the operations to drivers */
  int sdhci_probe(struct udevice *dev);
+int sdhci_init(struct mmc *mmc);
  int sdhci_set_clock(struct mmc *mmc, unsigned int clock);
  extern const struct dm_mmc_ops sdhci_ops;
  #else

Re: [U-Boot] [PATCH v2 2/3] env: Tidy up some of the env code

[Simon Goldschmidt]

Am 30.01.2020 um 21:33 schrieb Wolfgang Denk:

Dear James,

In message 
<0102016eac3ac1a7-8a163dd4-aa1a-4331-a266-e9f461a07db8-000...@eu-west-1.amazonses.com>
 you wrote:


As I said in my commit log comment, there are two key arguments against
this:

- The fact that the 'data' member of 'struct env_entry' is a 'char *' is
really inconvenient because this is a read-only function where most of
the callers should be using 'const char *' pointers, and having to cast
away the constness isn't good practice and makes the calling code less
readable.


So the 'data' member of 'struct env_entry' should be a "const char
*", but that does not mean you have to change the interface of
hsearch_r() ??


- As you can see from the calling code I've had to tidy up, the callers
were very inconsistent about whether they bothered to initialise any
fields other than 'key' and 'value', so if you ever wanted to extend the
interface to check other parameters you'd have to go around and fix them
all up anyway to avoid unpredictable behaviour.


Well, is is good practice to always initialize the complete sruct.
Where this is missing, the code should be fixed.


Given that only 'key' and 'value' are used at the moment I think my
change is preferable because it makes it explicit what is being used and
avoids any nasty surprises you might get if you changed hsearch_r()
without changing all the callers. If you anticipate wanting to match on
other fields, it might be better to define an alternative query
structure using 'const char *' pointers for key and value, then extend
that, but I would argue that that's something you could do at the point
you find it is needed rather than now.


You miss the point that hsearch_r() actually a standard function,
see "man 3 hsearch_r":

HSEARCH(3)   Linux Programmer's Manual  
 HSEARCH(3)

NAME
hcreate, hdestroy, hsearch, hcreate_r, hdestroy_r, hsearch_r - hash 
table management

SYNOPSIS
#include 

int hcreate(size_t nel);

ENTRY *hsearch(ENTRY item, ACTION action);

void hdestroy(void);

#define _GNU_SOURCE /* See feature_test_macros(7) */
#include 

int hcreate_r(size_t nel, struct hsearch_data *htab);

int hsearch_r(ENTRY item, ACTION action, ENTRY **retval,
  struct hsearch_data *htab);


Hm, U-Boot's 'hsearch_r' does not conform to this 'standard' since 
December 2012, see these 2 commits from 2012 and 2019:


https://github.com/u-boot/u-boot/commit/c4e0057fa78ebb524b9241ad7245fcd1074ba414

https://github.com/u-boot/u-boot/commit/3f0d6807459bb22431e5bc19e597c1786b3d1ce6

Note I say 'standard' (with quotation marks) because this function seems 
to only be a GNU extension, according to that man page. Nevertheless, it 
does seem to have been adopted by *BSD, even if it hasn't made it to 
opengroups.org (the reference I use when implementing 'standard' calls 
for lwIP).


Obviously, my comments have no real relation to the intention of the 
patch to 'clean up' things. I do think the current situation could be 
improved (e.g. regarding constness), but looking at the nonchalant way 
such a 'standard' function has been change nonstandard, I think this 
should be a change we actively vote for (and the above 2 patches did not 
seem to take this into account).


Regards,
Simon



void hdestroy_r(struct hsearch_data *htab);


I object against changing standard interfaces.


I also dislike the seocnd part of the patch.  First, this is
unrelated to the hsearch_r changes, so it should have been a
separate commit anyway.

But renaming _do_env_set() into do_interactive_env_set() makes
absolutely no sense.  It is called in many places from code, which
hav nothing to do with any interactive mode.  Also, I cannot see
what you win by splitting two actions that belong together.


I recommend dropping this patch.

Naked-by: Wolfgang Denk 

Best regards,

Wolfgang Denk

Re: [PATCH v2 02/10] mmc: Add init() API

[Simon Goldschmidt]

Tom Rini  schrieb am Do., 30. Jan. 2020, 16:32:

> On Thu, Jan 30, 2020 at 04:30:54PM +0100, Michal Simek wrote:
> > On 30. 01. 20 16:14, Faiz Abbas wrote:
> > > Hi Michal,
> > >
> > > On 30/01/20 8:37 pm, Michal Simek wrote:
> > >> On 30. 01. 20 16:03, Faiz Abbas wrote:
> > >>> Hi,
> > >>>
> > >>> +Lokesh, Tom
> > >>>
> > >>> On 29/01/20 1:37 pm, Simon Goldschmidt wrote:
> > >>>> Forgot to ask: why isn't the subsystem maintainer on CC?
> > >>>> If you would use patman to send patches or at least the
> get_maintainer script,
> > >>>> he would have been...
> > >>>>
> > >>>
> > >>> I did use get_maintainer for my send-email CC list but everyone other
> > >>> than Michal seems to have been dropped. Here is an excerpt from the
> > >>> email header I received:
> > >>>
> > >>> From: Faiz Abbas 
> > >>> To: 
> > >>> CC: , , <
> lokeshvu...@ti.com>,
> > >>>   , 
> > >>> Subject: [PATCH v2 02/10] mmc: Add init() API
> > >>> Date: Fri, 24 Jan 2020 17:22:44 +0530
> > >>>
> > >>>
> > >>> But in the patchworks and in your reply, only Michal is remaining:
> > >>> https://patchwork.ozlabs.org/patch/1228781/
> > >>>
> > >>> Michal,
> > >>>
> > >>> What do you see in your message header? Does it have other people
> copied?
> > >>
> > >> [u-boot]$ ./scripts/get_maintainer.pl -f drivers/mmc/mmc.c
> > >> Peng Fan  (maintainer:MMC)
> > >> u-boot@lists.denx.de (open list)
> > >>
> > >> I see Peng there.
> > >>
> > >
> > > You misunderstood. I am not asking if you see Peng in the
> get_maintainer
> > > output. Do you see him CC'd in the original patch email?
> >
> > Nope. I can't see him there.
>
> Wolfgang, is there some mailman setting that needs tweaking or looking
> at here?  Thanks!
>

Can this be a mailman issue? If Michal was CCed, is mailman involved in the
way to him? I would have thought that mail got delivered directly.

Regards,
Simon

Re: [PATCH v2 02/10] mmc: Add init() API

[Simon Goldschmidt]

Faiz Abbas  schrieb am Do., 30. Jan. 2020, 16:01:

> Hi,
>
> +Lokesh, Tom
>
> On 29/01/20 1:37 pm, Simon Goldschmidt wrote:
> > Forgot to ask: why isn't the subsystem maintainer on CC?
> > If you would use patman to send patches or at least the get_maintainer
> script,
> > he would have been...
> >
>
> I did use get_maintainer for my send-email CC list but everyone other
> than Michal seems to have been dropped. Here is an excerpt from the
> email header I received:
>
> From: Faiz Abbas 
> To: 
> CC: , , ,
> , 
> Subject: [PATCH v2 02/10] mmc: Add init() API
> Date: Fri, 24 Jan 2020 17:22:44 +0530
>
>
> But in the patchworks and in your reply, only Michal is remaining:
> https://patchwork.ozlabs.org/patch/1228781/


I hit reply all in the gmail web interface. My header only shows Michal.

Regards,
Simon


>
> Michal,
>
> What do you see in your message header? Does it have other people copied?


> Thanks,
> Faiz
>

Re: [PATCH v2 3/4] mtd: rawnand: denali_dt: use UCLASS_MTD instead of UCLASS_MISC

[Simon Goldschmidt]

Am 29.01.2020 um 16:55 schrieb Masahiro Yamada:

UCLASS_MTD is a better fit for NAND drivers.

Make NAND_DENALI_DT depend on DM_MTD, which is needed to compile
drivers/mtd/mtd-uclass.c

Also, make ARCH_SOCFPGA and ARCH_UNIPHIER select DM_MTD because
they use this driver.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - new patch

  arch/arm/Kconfig | 2 ++
  drivers/mtd/nand/raw/Kconfig | 2 +-
  drivers/mtd/nand/raw/denali_dt.c | 4 ++--
  3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1236315168..d1c58667c7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -935,6 +935,7 @@ config ARCH_SOCFPGA
select ARM64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
select CPU_V7A if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select DM
+   select DM_MTD


Does any socfpga actually enable the denali driver? Do we need to 
default to this instead of enabling it in a defconfig?


If we need it, could you please change that to 'imply'? Not all configs 
will need this.


Thanks,
Simon


select DM_SERIAL
select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || 
TARGET_SOCFPGA_ARRIA10
select OF_CONTROL
@@ -1548,6 +1549,7 @@ config ARCH_UNIPHIER
select DM_GPIO
select DM_I2C
select DM_MMC
+   select DM_MTD
select DM_RESET
select DM_SERIAL
select DM_USB
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 7814d84ba0..23201ca720 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -116,7 +116,7 @@ config NAND_DENALI
  config NAND_DENALI_DT
bool "Support Denali NAND controller as a DT device"
select NAND_DENALI
-   depends on OF_CONTROL && DM
+   depends on OF_CONTROL && DM_MTD
help
  Enable the driver for NAND flash on platforms using a Denali NAND
  controller as a DT device.
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 587e480faa..759ad40e51 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -160,7 +160,7 @@ static int denali_dt_probe(struct udevice *dev)
  
  U_BOOT_DRIVER(denali_nand_dt) = {

.name = "denali-nand-dt",
-   .id = UCLASS_MISC,
+   .id = UCLASS_MTD,
.of_match = denali_nand_dt_ids,
.probe = denali_dt_probe,
.priv_auto_alloc_size = sizeof(struct denali_nand_info),
@@ -171,7 +171,7 @@ void board_nand_init(void)
struct udevice *dev;
int ret;
  
-	ret = uclass_get_device_by_driver(UCLASS_MISC,

+   ret = uclass_get_device_by_driver(UCLASS_MTD,
  DM_GET_DRIVER(denali_nand_dt),
  );
if (ret && ret != -ENODEV)

Re: [PATCH v2 06/10] mmc: am654_sdhci: Implement workaround for card detect

[Simon Goldschmidt]

On Fri, Jan 24, 2020 at 12:52 PM Faiz Abbas  wrote:
>
> The 4 bit MMC controllers have an internal debounce for the SDCD line
> with a debounce delay of 1 second. Therefore, after clocks to the IP are
> enabled, software has to wait for this time before it can power on the
> controller.
>
> Add an init() callback which polls on sdcd for a maximum of 2 seconds
> before switching on power to the controller or (in the case of no card)
> returning a ENOMEDIUM. This pushes the 1 second wait time to when the
> card is actually needed rather than at every probe() making sure that
> users who don't insert an SD card in the slot don't have to wait such a
> long time.
>
> Signed-off-by: Faiz Abbas 
> Signed-off-by: Lokesh Vutla 
> ---
>  drivers/mmc/am654_sdhci.c | 35 ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index ff0a81eaab..ccae3fea31 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -254,7 +254,7 @@ const struct am654_driver_data j721e_4bit_drv_data = {
> .flags = IOMUX_PRESENT,
>  };
>
> -int am654_sdhci_init(struct am654_sdhci_plat *plat)
> +int am654_sdhci_init_phy(struct am654_sdhci_plat *plat)
>  {
> u32 ctl_cfg_2 = 0;
> u32 mask, val;
> @@ -331,8 +331,37 @@ static int sdhci_am654_get_otap_delay(struct udevice 
> *dev,
> return 0;
>  }
>
> +#define MAX_SDCD_DEBOUNCE_TIME 2000
> +int am654_sdhci_init(struct udevice *dev)
> +{
> +   struct am654_sdhci_plat *plat = dev_get_platdata(dev);
> +   struct mmc *mmc = mmc_get_mmc_dev(dev);
> +   struct sdhci_host *host = mmc->priv;
> +   unsigned long start;
> +   int val;
> +
> +   /*
> +* The controller takes about 1 second to debounce the card detect 
> line
> +* and doesn't let us power on until that time is up. Instead of 
> waiting
> +* for 1 second at every stage, poll on the CARD_PRESENT bit upto a
> +* maximum of 2 seconds to be safe..
> +*/
> +   start = get_timer(0);
> +   do {
> +   if (get_timer(start) > MAX_SDCD_DEBOUNCE_TIME)
> +   return -ENOMEDIUM;
> +
> +   val = mmc_getcd(host->mmc);
> +   } while (!val);
> +
> +   am654_sdhci_init_phy(plat);
> +
> +   return sdhci_init(mmc);
> +}
> +
>  static int am654_sdhci_probe(struct udevice *dev)
>  {
> +   struct dm_mmc_ops *ops = mmc_get_ops(dev);
> struct am654_driver_data *drv_data =
> (struct am654_driver_data *)dev_get_driver_data(dev);
> struct am654_sdhci_plat *plat = dev_get_platdata(dev);
> @@ -373,9 +402,9 @@ static int am654_sdhci_probe(struct udevice *dev)
>
> regmap_init_mem_index(dev_ofnode(dev), >base, 1);
>
> -   am654_sdhci_init(plat);
> +   ops->init = am654_sdhci_init;

Is this a valid approach? I mean, many drivers create their 'ops' const like
this:
   static const struct ram_ops altera_gen5_sdram_ops (...)

That would mean you write to a const region. I know the U-Boot sources make
this easy for you by providing the ops non-const via mmc_get_ops, but I still
think this is not good.

Regards,
Simon

>
> -   return sdhci_probe(dev);
> +   return 0;
>  }
>
>  static int am654_sdhci_ofdata_to_platdata(struct udevice *dev)
> --
> 2.19.2
>

Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static

[Simon Goldschmidt]

On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung  wrote:
>
> On 1/24/20 8:52 PM, Faiz Abbas wrote:
> > Expose sdhci_init() as non-static.
>
> Does it need to change to non-static?

And even if it needs to, can we have a reason *why* in the commit message?

Thanks,
Simon

>
> Best Regards,
> Jaehoon Chung
>
> >
> > Signed-off-by: Faiz Abbas 
> > Signed-off-by: Lokesh Vutla 
> > ---
> >  drivers/mmc/sdhci.c | 2 +-
> >  include/sdhci.h | 1 +
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index 01fa5a9d4d..4fce85a0ea 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -618,7 +618,7 @@ static int sdhci_set_ios(struct mmc *mmc)
> >   return 0;
> >  }
> >
> > -static int sdhci_init(struct mmc *mmc)
> > +int sdhci_init(struct mmc *mmc)
> >  {
> >   struct sdhci_host *host = mmc->priv;
> >  #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
> > diff --git a/include/sdhci.h b/include/sdhci.h
> > index 01addb7a60..0830e05d53 100644
> > --- a/include/sdhci.h
> > +++ b/include/sdhci.h
> > @@ -487,6 +487,7 @@ void sdhci_set_uhs_timing(struct sdhci_host *host);
> >  #ifdef CONFIG_DM_MMC
> >  /* Export the operations to drivers */
> >  int sdhci_probe(struct udevice *dev);
> > +int sdhci_init(struct mmc *mmc);
> >  int sdhci_set_clock(struct mmc *mmc, unsigned int clock);
> >  extern const struct dm_mmc_ops sdhci_ops;
> >  #else
> >
>

Re: [PATCH v2 02/10] mmc: Add init() API

[Simon Goldschmidt]

Forgot to ask: why isn't the subsystem maintainer on CC?
If you would use patman to send patches or at least the get_maintainer script,
he would have been...

Regards,
Simon

On Wed, Jan 29, 2020 at 9:03 AM Simon Goldschmidt
 wrote:
>
> On Fri, Jan 24, 2020 at 12:52 PM Faiz Abbas  wrote:
> >
> > Add an init() API for platform specific init() operations.
>
> Could you describe why this cannot be done in the probe callback? It's not
> easily visible as the function you changed (mmc_get_op_cond) doesn't even have
> a comment to describe what it does...
>
> In general, I think commit messages could be more detailed than one line. If
> only to make it easier in the future to recap why things have been done.
>
> >
> > Signed-off-by: Faiz Abbas 
> > Signed-off-by: Lokesh Vutla 
> > ---
> >  drivers/mmc/mmc.c | 13 ++---
> >  include/mmc.h |  7 +++
> >  2 files changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index d43983d4a6..50df8c8626 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -2787,14 +2787,13 @@ int mmc_get_op_cond(struct mmc *mmc)
> > }
> > if (err)
> > return err;
> > -
> >  #if CONFIG_IS_ENABLED(DM_MMC)
> > -   /* The device has already been probed ready for use */
> > -#else
> > -   /* made sure it's not NULL earlier */
> > -   err = mmc->cfg->ops->init(mmc);
> > -   if (err)
> > -   return err;
>
> You're removing the init code for non-DM MMC here and did not describe it in
> the commit message. Is this change intended at all?
>
> Regards,
> Simon
>
> > +   struct dm_mmc_ops *ops = mmc_get_ops(mmc->dev);
> > +   if (ops->init) {
> > +   err = ops->init(mmc->dev);
> > +   if (err)
> > +   return err;
> > +   }
> >  #endif
> > mmc->ddr_mode = 0;
> >
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 2f21dbf1b7..6aef125f25 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -406,6 +406,13 @@ struct mmc;
> >
> >  #if CONFIG_IS_ENABLED(DM_MMC)
> >  struct dm_mmc_ops {
> > +   /**
> > +* init() - platform specific initialization for the host controller
> > +*
> > +* @dev:Device to init
> > +* @return 0 if Ok, -ve if error
> > +*/
> > +   int (*init)(struct udevice *dev);
> > /**
> >  * send_cmd() - Send a command to the MMC device
> >  *
> > --
> > 2.19.2
> >

Re: [PATCH v2 02/10] mmc: Add init() API

[Simon Goldschmidt]

On Fri, Jan 24, 2020 at 12:52 PM Faiz Abbas  wrote:
>
> Add an init() API for platform specific init() operations.

Could you describe why this cannot be done in the probe callback? It's not
easily visible as the function you changed (mmc_get_op_cond) doesn't even have
a comment to describe what it does...

In general, I think commit messages could be more detailed than one line. If
only to make it easier in the future to recap why things have been done.

>
> Signed-off-by: Faiz Abbas 
> Signed-off-by: Lokesh Vutla 
> ---
>  drivers/mmc/mmc.c | 13 ++---
>  include/mmc.h |  7 +++
>  2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d43983d4a6..50df8c8626 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2787,14 +2787,13 @@ int mmc_get_op_cond(struct mmc *mmc)
> }
> if (err)
> return err;
> -
>  #if CONFIG_IS_ENABLED(DM_MMC)
> -   /* The device has already been probed ready for use */
> -#else
> -   /* made sure it's not NULL earlier */
> -   err = mmc->cfg->ops->init(mmc);
> -   if (err)
> -   return err;

You're removing the init code for non-DM MMC here and did not describe it in
the commit message. Is this change intended at all?

Regards,
Simon

> +   struct dm_mmc_ops *ops = mmc_get_ops(mmc->dev);
> +   if (ops->init) {
> +   err = ops->init(mmc->dev);
> +   if (err)
> +   return err;
> +   }
>  #endif
> mmc->ddr_mode = 0;
>
> diff --git a/include/mmc.h b/include/mmc.h
> index 2f21dbf1b7..6aef125f25 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -406,6 +406,13 @@ struct mmc;
>
>  #if CONFIG_IS_ENABLED(DM_MMC)
>  struct dm_mmc_ops {
> +   /**
> +* init() - platform specific initialization for the host controller
> +*
> +* @dev:Device to init
> +* @return 0 if Ok, -ve if error
> +*/
> +   int (*init)(struct udevice *dev);
> /**
>  * send_cmd() - Send a command to the MMC device
>  *
> --
> 2.19.2
>

Re: [GIT PULL] TI changes for 2020.04-rc1

[Simon Goldschmidt]

On Wed, Jan 29, 2020 at 8:48 AM Lokesh Vutla  wrote:
>
> Hi Simon,
>
> On 29/01/20 12:40 PM, Simon Goldschmidt wrote:
> > On Wed, Jan 29, 2020 at 6:00 AM Lokesh Vutla  wrote:
> >>
> >> Hi Tom,
> >>
> >> Please find the pull request for v2020.04-rc1 containing TI specific 
> >> changes.
> >> This PR brings in multiple features and should have sent before rc1 is
> >> tagged. Due to multiple reviews, this is being sent a bit late. For
> >> detailed changes please see the PR description below.
> >>
> >> Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014
> >> Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715
> >>
> >> Thanks and regards,
> >> Lokesh
> >>
> >>
> >> The following changes since commit 
> >> b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26:
> >>
> >>   Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500)
> >>
> >> are available in the Git repository at:
> >>
> >>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git 
> >> tags/ti-2020.04-rc1
> >>
> >> for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539:
> >>
> >>   configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 
> >> 08:07:12 +0530)
> >>
> >> 
> >> Below are the major changes in this PR:
> >> - EMMC boot support on J721e
> >> - DFU boot support for J721e
> >> - I2C support for J721e
> >> - Android boot image updates on AM57XX
> >>
> >> 
> >> Faiz Abbas (11):
> >>   mmc: Add a saved_clock member
> >
> > Sorry for not reacting on this one earlier, I was kind of offline for a 
> > week,
> > but:
> > This one has comments pending that weren't answered.
>
> Sorry for that. I missed the comment  as I was not Cc ed.
>
> >
> >>   mmc: Add init() API
> >
> > This patch contains more than it says (removes non-DM init) and is not 
> > reviewed
> > by the subsystem maintainer. In fact, it is not reviewed by anyone outside 
> > TI.
> > I thought we wanted to establish the rule that code has to go through a
> > subsystem maintainer's tree or get an RB by them to improve code quality?
>
> Agreed. IIRC, these were assigned to me in Patchworks, so I picked it as there
> were no comments for quite some time. Peng, please let me know how you would
> like to pick these patches once the comments are addressed

I would have written a comment if I hadn't been kind of offline the last week.
Let me do that now.

Regards,
Simon

>
> Tom,
> Please ignore this pull-request.
>
> Thanks and regards,
> Lokesh
>
>
> >
> >>   mmc: Merge SD_LEGACY and MMC_LEGACY bus modes
> >>   mmc: sdhci: Expose sdhci_init() as non-static
> >
> > More unaddressed comments...
> >
> > Regards,
> > Simon
> >
> >>   mmc: am654_sdhci: Update output tap delay writes
> >>   mmc: am654_sdhci: Implement workaround for card detect
> >>   spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation
> >>   arm: K3: sysfw-loader: Add a config_pm_pre_callback()
> >>   configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT
> >>   configs: j721e_evm: Add Support for eMMC boot
> >>   configs: j721e_evm_a72: Fix redundant environment offset
> >>
> >> Sam Protsenko (10):
> >>   image: android: Add functions for handling dtb field
> >>   image: android: Add routine to get dtbo params
> >>   cmd: abootimg: Add abootimg command
> >>   doc: android: Add documentation for Android Boot Image
> >>   doc: android: Convert to Sphinx format
> >>   test/py: android: Add test for abootimg
> >>   configs: am57xx_evm: Enable Android commands
> >>   env: ti: boot: Respect slot_suffix in AVB commands
> >>   env: ti: boot: Boot Android with dynamic partitions
> >>   arm: ti: boot: Use correct dtb and dtbo on Android boot
> >>
> >> Vignesh Raghavendra (12):
> >>   arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU
> >>   arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU
> >>   arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode
> >>   configs: j721e_evm: Add DFU related variables
> >>   co

Re: [GIT PULL] TI changes for 2020.04-rc1

[Simon Goldschmidt]

On Wed, Jan 29, 2020 at 6:00 AM Lokesh Vutla  wrote:
>
> Hi Tom,
>
> Please find the pull request for v2020.04-rc1 containing TI specific changes.
> This PR brings in multiple features and should have sent before rc1 is
> tagged. Due to multiple reviews, this is being sent a bit late. For
> detailed changes please see the PR description below.
>
> Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014
> Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715
>
> Thanks and regards,
> Lokesh
>
>
> The following changes since commit b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26:
>
>   Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500)
>
> are available in the Git repository at:
>
>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-2020.04-rc1
>
> for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539:
>
>   configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 
> 08:07:12 +0530)
>
> 
> Below are the major changes in this PR:
> - EMMC boot support on J721e
> - DFU boot support for J721e
> - I2C support for J721e
> - Android boot image updates on AM57XX
>
> 
> Faiz Abbas (11):
>   mmc: Add a saved_clock member

Sorry for not reacting on this one earlier, I was kind of offline for a week,
but:
This one has comments pending that weren't answered.

>   mmc: Add init() API

This patch contains more than it says (removes non-DM init) and is not reviewed
by the subsystem maintainer. In fact, it is not reviewed by anyone outside TI.
I thought we wanted to establish the rule that code has to go through a
subsystem maintainer's tree or get an RB by them to improve code quality?

>   mmc: Merge SD_LEGACY and MMC_LEGACY bus modes
>   mmc: sdhci: Expose sdhci_init() as non-static

More unaddressed comments...

Regards,
Simon

>   mmc: am654_sdhci: Update output tap delay writes
>   mmc: am654_sdhci: Implement workaround for card detect
>   spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation
>   arm: K3: sysfw-loader: Add a config_pm_pre_callback()
>   configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT
>   configs: j721e_evm: Add Support for eMMC boot
>   configs: j721e_evm_a72: Fix redundant environment offset
>
> Sam Protsenko (10):
>   image: android: Add functions for handling dtb field
>   image: android: Add routine to get dtbo params
>   cmd: abootimg: Add abootimg command
>   doc: android: Add documentation for Android Boot Image
>   doc: android: Convert to Sphinx format
>   test/py: android: Add test for abootimg
>   configs: am57xx_evm: Enable Android commands
>   env: ti: boot: Respect slot_suffix in AVB commands
>   env: ti: boot: Boot Android with dynamic partitions
>   arm: ti: boot: Use correct dtb and dtbo on Android boot
>
> Vignesh Raghavendra (12):
>   arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU
>   arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU
>   arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode
>   configs: j721e_evm: Add DFU related variables
>   configs: j721e_evm_r5_defconfig: Increase early malloc size
>   configs: j721e_evm_r5/a72_defconfig: Enable USB Gadget related configs
>   configs: j721e_evm_r5/a72_defconfig: Enable DFU related configs
>   gpio: pca953x_gpio: Add support for 24 bit IO expander
>   arm: dts: k3-j721e: Add I2C nodes
>   arm: dts: k3-j721e-common-proc-board: Add I2C GPIO expander
>   arm: dts: k3-j721e-common-proc-board: Enable I2C expander for SPL
>   configs: j721e_evm_defconfig: Enable PCA953x IO expander
>
>  MAINTAINERS|   4 +-
>  arch/arm/dts/k3-am65-main.dtsi |  12 +-
>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi   |  11 +-
>  .../arm/dts/k3-j721e-common-proc-board-u-boot.dtsi |  12 +
>  arch/arm/dts/k3-j721e-common-proc-board.dts|  27 ++
>  arch/arm/dts/k3-j721e-main.dtsi|  92 ++-
>  arch/arm/dts/k3-j721e-mcu-wakeup.dtsi  |  22 ++
>  arch/arm/dts/k3-j721e-r5-common-proc-board.dts |  45 
>  arch/arm/dts/k3-j721e.dtsi |  10 +
>  arch/arm/mach-imx/imx8/image.c |   3 +-
>  arch/arm/mach-k3/am6_init.c|  33 ++-
>  arch/arm/mach-k3/include/mach/j721e_spl.h  |   2 +-
>  arch/arm/mach-k3/include/mach/sysfw-loader.h   |   2 +-
>  arch/arm/mach-k3/j721e_init.c  |  33 ++-
>  arch/arm/mach-k3/sysfw-loader.c|  36 ++-
>  cmd/Kconfig|  12 +-
>  cmd/Makefile   |   1 +
>  cmd/abootimg.c | 258 +++
>  common/Makefile

Re: [RFC] azure: Move to vs2017-win2016 platform build host

[Simon Goldschmidt]

Tom Rini  schrieb am Mo., 27. Jan. 2020, 22:23:

> Azure is moving to remove the vs2015-win2012r2 platform build host.  The
> two suggested new platforms to use are vs2017-win2016 and windows-2019.
> For now, move up to vs2017-win2016.
>
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> ---
> I'm sending this as RFC as it fails to build for i686 but builds for
> x86_64 and I'm out of my depth on fixing that.  Can you please take a
> look Bin?  Thanks!
>

Is this build publicly available? I just failed to find it, having no
experience with azure whatsoever...

Regards,
Simon

---
>  .azure-pipelines.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index 916ab84ea0c4..a0713dd66c0a 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -1,5 +1,5 @@
>  variables:
> -  windows_vm: vs2015-win2012r2
> +  windows_vm: vs2017-win2016
>ubuntu_vm: ubuntu-18.04
>ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200112-17Jan2020
># Add '-u 0' options for Azure pipelines, otherwise we get "permission
> --
> 2.17.1
>
>

Re: [PATCH] common: fix regression on block cache init

[Simon Goldschmidt]

On Sun, Jan 26, 2020 at 7:30 PM Angelo Dureghello
 wrote:
>
> From: Angelo Durgehello 
>
> m68k needs block cache list initialized after relocation.
> Other architectures must not be involved.
>
> Fixing regression related to:
>
> commit 1526bcce0f7285087621e16e6720636d01839da8
> ("common: add blkcache init")
>
> Signed-off-by: Angelo Durgehello 
> ---
>  common/board_r.c | 2 +-
>  drivers/block/blkcache.c | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 4f56c19fcc..0bbeaa7594 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -865,7 +865,7 @@ static init_fnc_t init_sequence_r[] = {
>  #if defined(CONFIG_PRAM)
> initr_mem,
>  #endif
> -#ifdef CONFIG_BLOCK_CACHE
> +#if defined(CONFIG_M68K) && defined(CONFIG_BLOCK_CACHE)

Sorry for not reacting earlier here, but is this really M68K specific?
Or would COFIG_NEES_MANUAL_RELOC be a better fit?

Regards,
Simon

> blkcache_init,
>  #endif
> run_main_loop,
> diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
> index f603aa129d..ea40929e3e 100644
> --- a/drivers/block/blkcache.c
> +++ b/drivers/block/blkcache.c
> @@ -21,19 +21,25 @@ struct block_cache_node {
> char *cache;
>  };
>
> +#ifndef CONFIG_M68K
> +static LIST_HEAD(block_cache);
> +#else
>  static struct list_head block_cache;
> +#endif
>
>  static struct block_cache_stats _stats = {
> .max_blocks_per_entry = 8,
> .max_entries = 32
>  };
>
> +#ifdef CONFIG_M68K
>  int blkcache_init(void)
>  {
> INIT_LIST_HEAD(_cache);
>
> return 0;
>  }
> +#endif
>
>  static struct block_cache_node *cache_find(int iftype, int devnum,
>lbaint_t start, lbaint_t blkcnt,
> --
> 2.24.1
>

Re: [PATCHv3] cmd/gpt: Address error cases during gpt rename more correctly

[Simon Goldschmidt]

On Tue, Jan 21, 2020 at 5:53 PM Tom Rini  wrote:
>
> New analysis by the tool has shown that we have some cases where we
> weren't handling the error exit condition correctly.  When we ran into
> the ENOMEM case we wouldn't exit the function and thus incorrect things
> could happen.  Rework the unwinding such that we don't need a helper
> function now and free what we may have allocated.
>
> Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity")
> Reported-by: Coverity (CID: 275475, 275476)
> Cc: Alison Chaiken 
> Cc: Simon Goldschmidt 
> Cc: Jordy 
> Signed-off-by: Tom Rini 

Looks good to me.

Reviewed-by: Simon Goldschmidt 

> ---
> Changes in v3:
> - Move del_gpt_info() call into the unwind as set_gpt_info() will have
>   been called at that point and we need to clear it. (Simon)
> Changes in v2:
> - Initialize str_disk_guid to NULL to be sure we can test that it has
>   been set later on (Simon, Jordy).
> ---
>  cmd/gpt.c | 47 ---
>  1 file changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 0c4349f4b249..964702bad43e 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -633,21 +633,6 @@ static int do_disk_guid(struct blk_desc *dev_desc, char 
> * const namestr)
>  }
>
>  #ifdef CONFIG_CMD_GPT_RENAME
> -/*
> - * There are 3 malloc() calls in set_gpt_info() and there is no info about 
> which
> - * failed.
> - */
> -static void set_gpt_cleanup(char **str_disk_guid,
> -   disk_partition_t **partitions)
> -{
> -#ifdef CONFIG_RANDOM_UUID
> -   if (str_disk_guid)
> -   free(str_disk_guid);
> -#endif
> -   if (partitions)
> -   free(partitions);
> -}
> -
>  static int do_rename_gpt_parts(struct blk_desc *dev_desc, char *subcomm,
>char *name1, char *name2)
>  {
> @@ -655,7 +640,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
> char *subcomm,
> struct disk_part *curr;
> disk_partition_t *new_partitions = NULL;
> char disk_guid[UUID_STR_LEN + 1];
> -   char *partitions_list, *str_disk_guid;
> +   char *partitions_list, *str_disk_guid = NULL;
> u8 part_count = 0;
> int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 = 
> 0;
>
> @@ -697,14 +682,8 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
> /* set_gpt_info allocates new_partitions and str_disk_guid */
> ret = set_gpt_info(dev_desc, partitions_list, _disk_guid,
>_partitions, _count);
> -   if (ret < 0) {
> -   del_gpt_info();
> -   free(partitions_list);
> -   if (ret == -ENOMEM)
> -   set_gpt_cleanup(_disk_guid, _partitions);
> -   else
> -   goto out;
> -   }
> +   if (ret < 0)
> +   goto out;
>
> if (!strcmp(subcomm, "swap")) {
> if ((strlen(name1) > PART_NAME_LEN) || (strlen(name2) > 
> PART_NAME_LEN)) {
> @@ -766,14 +745,8 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
>  * Even though valid pointers are here passed into set_gpt_info(),
>  * it mallocs again, and there's no way to tell which failed.
>  */
> -   if (ret < 0) {
> -   del_gpt_info();
> -   free(partitions_list);
> -   if (ret == -ENOMEM)
> -   set_gpt_cleanup(_disk_guid, _partitions);
> -   else
> -   goto out;
> -   }
> +   if (ret < 0)
> +   goto out;
>
> debug("Writing new partition table\n");
> ret = gpt_restore(dev_desc, disk_guid, new_partitions, numparts);
> @@ -795,10 +768,14 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
> }
> printf("new partition table with %d partitions is:\n", numparts);
> print_gpt_info();
> -   del_gpt_info();
>   out:
> -   free(new_partitions);
> -   free(str_disk_guid);
> +   del_gpt_info();
> +#ifdef CONFIG_RANDOM_UUID
> +   if (str_disk_guid)
> +   free(str_disk_guid);
> +#endif
> +   if (new_partitions)
> +   free(new_partitions);
> free(partitions_list);
> return ret;
>  }
> --
> 2.17.1
>

Re: [PATCHv2] cmd/gpt: Address error cases during gpt rename more correctly

[Simon Goldschmidt]

On Mon, Jan 20, 2020 at 11:53 PM Tom Rini  wrote:
>
> New analysis by the tool has shown that we have some cases where we
> weren't handling the error exit condition correctly.  When we ran into
> the ENOMEM case we wouldn't exit the function and thus incorrect things
> could happen.  Rework the unwinding such that we don't need a helper
> function now and free what we may have allocated.
>
> Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity")
> Reported-by: Coverity (CID: 275475, 275476)
> Cc: Alison Chaiken 
> Cc: Simon Goldschmidt 
> Cc: Jordy 
> Signed-off-by: Tom Rini 
>
> ---
> Changes in v2:
> - Initialize str_disk_guid to NULL to be sure we can test that it has
>   been set later on (Simon, Jordy).
>
>  cmd/gpt.c | 37 +
>  1 file changed, 9 insertions(+), 28 deletions(-)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 0c4349f4b249..c0e3c5161789 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -633,21 +633,6 @@ static int do_disk_guid(struct blk_desc *dev_desc, char 
> * const namestr)
>  }
>
>  #ifdef CONFIG_CMD_GPT_RENAME
> -/*
> - * There are 3 malloc() calls in set_gpt_info() and there is no info about 
> which
> - * failed.
> - */
> -static void set_gpt_cleanup(char **str_disk_guid,
> -   disk_partition_t **partitions)
> -{
> -#ifdef CONFIG_RANDOM_UUID
> -   if (str_disk_guid)
> -   free(str_disk_guid);
> -#endif
> -   if (partitions)
> -   free(partitions);
> -}
> -
>  static int do_rename_gpt_parts(struct blk_desc *dev_desc, char *subcomm,
>char *name1, char *name2)
>  {
> @@ -655,7 +640,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
> char *subcomm,
> struct disk_part *curr;
> disk_partition_t *new_partitions = NULL;
> char disk_guid[UUID_STR_LEN + 1];
> -   char *partitions_list, *str_disk_guid;
> +   char *partitions_list, *str_disk_guid = NULL;
> u8 part_count = 0;
> int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 = 
> 0;
>
> @@ -699,11 +684,7 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
>_partitions, _count);
> if (ret < 0) {
> del_gpt_info();
> -   free(partitions_list);
> -   if (ret == -ENOMEM)
> -   set_gpt_cleanup(_disk_guid, _partitions);
> -   else
> -   goto out;
> +   goto out;
> }
>
> if (!strcmp(subcomm, "swap")) {
> @@ -768,11 +749,7 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
>  */
> if (ret < 0) {
> del_gpt_info();
> -   free(partitions_list);
> -   if (ret == -ENOMEM)
> -   set_gpt_cleanup(_disk_guid, _partitions);
> -   else
> -   goto out;
> +   goto out;
> }
>
> debug("Writing new partition table\n");
> @@ -797,8 +774,12 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
> print_gpt_info();
> del_gpt_info();
>   out:

OK, so the freeing below looks good to me now. However, what worries me is that
when reaching 'out:' via different code flows, del_gpt_info is not always
called. I think that could lead to memory leaks when calling this code again, as
get_gpt_info just reinitializes the list head without checking if there's
actually something allocated in the list.

Maybe we should move the last call to del_gpt_info below 'out:' so that it is
always called?

Regards,
Simon

> -   free(new_partitions);
> -   free(str_disk_guid);
> +#ifdef CONFIG_RANDOM_UUID
> +   if (str_disk_guid)
> +   free(str_disk_guid);
> +#endif
> +   if (new_partitions)
> +   free(new_partitions);
> free(partitions_list);
> return ret;
>  }
> --
> 2.17.1

Re: Double free vulnerability in do_rename_gpt_parts

[Simon Goldschmidt]

Am 17.01.2020 um 17:31 schrieb Tom Rini:

On Fri, Jan 17, 2020 at 04:29:52PM +0100, Simon Goldschmidt wrote:

+ Some contributors of this file

On Fri, Jan 17, 2020 at 1:03 PM Jordy  wrote:


Hello U-Boot lists!

I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function 
do_rename_gpt_parts().

On line 702 the partition_list is being free'd if ret is smaller than 0.
If the return value is not -ENOMEM it will go to the out: label and free the 
partition_list again.


Reading the code, I can confirm that. Funny enough, the code in question was
introduced by commit 18030d04 ("GPT: fix memory leaks identified by Coverity").
Although I think Coverity should have detected the resulting double-free...

However, I'm not sure of the fix: the code just continues for -ENOMEM and then
goes on using partitions_list at line 757...


So, Coverity later did complain about that change (but not immediately,
funny enough).  I posted http://patchwork.ozlabs.org/patch/1192036/ and
was hoping for a review on it as it's complex enough I'd like to avoid
adding a 3rd round of issues there.  Thanks!



Ah, yes. I've just responded there.

Regards,
Simon

Re: [U-Boot] [PATCH] cmd/gpt: Address error cases during gpt rename more correctly

[Simon Goldschmidt]

+ Jordy, who just found a bug here...

Am 08.11.2019 um 17:24 schrieb Tom Rini:

New analysis by the tool has shown that we have some cases where we
weren't handling the error exit condition correctly.  When we ran into
the ENOMEM case we wouldn't exit the function and thus incorrect things
could happen.  Rework the unwinding such that we don't need a helper
function now and free what we may have allocated.

Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity")
Reported-by: Coverity (CID: 275475, 275476)
Cc: Alison Chaiken 
Signed-off-by: Tom Rini 
---
  cmd/gpt.c | 35 ---
  1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 0c4349f4b249..2da8df60dca3 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -633,21 +633,6 @@ static int do_disk_guid(struct blk_desc *dev_desc, char * 
const namestr)
  }
  
  #ifdef CONFIG_CMD_GPT_RENAME

-/*
- * There are 3 malloc() calls in set_gpt_info() and there is no info about 
which
- * failed.
- */
-static void set_gpt_cleanup(char **str_disk_guid,
-   disk_partition_t **partitions)
-{
-#ifdef CONFIG_RANDOM_UUID
-   if (str_disk_guid)
-   free(str_disk_guid);
-#endif
-   if (partitions)
-   free(partitions);
-}
-
  static int do_rename_gpt_parts(struct blk_desc *dev_desc, char *subcomm,
   char *name1, char *name2)
  {
@@ -699,11 +684,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
   _partitions, _count);
if (ret < 0) {
del_gpt_info();
-   free(partitions_list);
-   if (ret == -ENOMEM)
-   set_gpt_cleanup(_disk_guid, _partitions);
-   else
-   goto out;
+   goto out;
}
  
  	if (!strcmp(subcomm, "swap")) {

@@ -768,11 +749,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
 */
if (ret < 0) {
del_gpt_info();
-   free(partitions_list);
-   if (ret == -ENOMEM)
-   set_gpt_cleanup(_disk_guid, _partitions);
-   else
-   goto out;
+   goto out;
}
  
  	debug("Writing new partition table\n");

@@ -797,8 +774,12 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
print_gpt_info();
del_gpt_info();
   out:
-   free(new_partitions);
-   free(str_disk_guid);
+#ifdef CONFIG_RANDOM_UUID
+   if (str_disk_guid)


Looks good overall, but could it be required to initialize str_disk_guid 
and new_partitions to 0 to make this test here work? Because 
set_gpt_info does not always seem to set these pointers in the error 
case, so they could be left uninitialized?


Regards,
Simon


+   free(str_disk_guid);
+#endif
+   if (new_partitions)
+   free(new_partitions);
free(partitions_list);
return ret;
  }