Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran
El Tue, Jun 20, 2023 at 02:50:48AM +0200, Marek Vasut deia:
> On 6/13/23 08:52, Xavier Drudis Ferran wrote:
> > 
> > U-Boot TPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47)
> 
> Next is already at rc4 , what's this rc2 ?

It's a test I did last week (June 12th). What do you think has changed
in next between rc2 and rc4 so that this shouldn't happen now ?

My last patch (sent yesterday) was tested with the next branch as of
yesterday morning. But you can test it yourself with any version you like.
Do I have to send the logs of each test I do to the list every time ?

I thought Simon Glass reply last week to the mail you quoted already
showed agreement that the issue exists, and the adding of the
UCLASS_BOOTDEV device is per design, so cmd/usb.c needs fixing to deal
with this change.



[PATCH v2 00/19] bootstd: Add a bootmeth for ChromiumOS on x86

2023-06-20 Thread Simon Glass
This series adds a simple bootmeth for ChromiumOS on x86. It uses zimage
to boot the kernel.

Full verified boot is not included at this stage - that is still a
separate chunk of code to be brought into standard boot at some point.
For now it just obtains the kernel and command line and boots. This should
be enough to boot Chrome OS from coreboot on all x86 machines in
circulation, although only Brya (2022) and Coral (2017) have been tested.

ChromiumOS needs quite large kernel parameters, to hold the DM verity
settings and other pieces. This makes it painful to modify just one
parameter, since the whole cmdline must be adjusted at once. To cope with
this, a new cmdline-editing feature is provided: the 'bootflow cmdline'
command allows individual parameters to be added, modified and deleted.

To deal with enabling debug console, a variant supports setting 'earlycon'
and 'console' automatically. The 'bdinfo' command is updated to show
serial-port info also.

Booting the zimage is now done programmatically, rather than running
through the command-line interface. Minor tweaks are made to the coreboot
and coral config so that booting works correctly.

Note that the ACPI tables are not updated with the required firmware
information in this series, so a warning is shown on boot. This will be
addressed later since it requires quite a bit of configuration.

Finally, this fixes a recently introduced bug in unit testing and updates
the algorithm to avoid running flat-tree tests which don't actually use
the devicetree.

Changes in v2:
- Add a comment that this is not a full revert
- Update host_bootdev.c too
- Correct 'it not known' typo
- Explain why the setup information is not behind an #ifdef
- Add comment for copy_in()
- Avoid multiplication on a boolean
- Add a comment as to why @len is needed
- Show error messages when something goes wrong
- Add new patch to create a little more room for U-Boot on qemu-x86_64
- Add new patch to switch x86 qemu to standard boot
- Drop mention of NVMe support

Simon Glass (19):
  test: Restore test behaviour on failure
  test: Skip flat-tree tests if devicetree is not used
  bootstd: Correct the name of the QEMU bootmeth
  bootstd: Use bootdev instead of bootdevice
  bootstd: Correct baudrate typo
  bootstd: Allow storing the OS command line in the bootflow
  bootstd: Use the bootargs env var for changing the cmdline
  bootstd: Allow storing x86 setup information
  bdinfo: Show information about the serial port
  bootstd: Add a function to update a command line
  bootstd: Add support for updating elements of the cmdline
  x86: qemu: Create a little more room for U-Boot
  x86: qemu: Switch to standard boot
  bootstd: Support automatically setting Linux parameters
  x86: Add a function to boot a zimage
  x86: zimage: Export the function to obtain the cmdline
  bootstd: Add a simple bootmeth for ChromiumOS
  x86: coreboot: Adjust various config options
  x86: coral: Adjust various config options

 arch/x86/include/asm/zimage.h  |  27 +++
 arch/x86/lib/zimage.c  |  93 ++--
 boot/Kconfig   |  11 +
 boot/Makefile  |   1 +
 boot/bootflow.c| 339 -
 boot/bootmeth-uclass.c |   2 +-
 boot/bootmeth_cros.c   | 212 ++
 boot/bootmeth_qfw.c|   2 +-
 cmd/bdinfo.c   |  21 ++
 cmd/bootflow.c |  87 +++-
 configs/chromebook_coral_defconfig |  10 +-
 configs/coreboot_defconfig |  16 +-
 configs/qemu-x86_64_defconfig  |   5 +-
 configs/qemu-x86_defconfig |   2 +-
 configs/tools-only_defconfig   |   1 +
 doc/usage/cmd/bootflow.rst | 100 -
 drivers/mmc/mmc_bootdev.c  |   2 +-
 drivers/scsi/scsi_bootdev.c|   2 +-
 drivers/usb/host/usb_bootdev.c |   2 +-
 fs/sandbox/host_bootdev.c  |   2 +-
 include/bootdev.h  |   2 +-
 include/bootflow.h | 100 -
 include/configs/qemu-x86.h |   8 -
 include/env_callback.h |   6 +-
 include/test/ut.h  |  36 +--
 net/eth_bootdev.c  |   2 +-
 test/boot/bootflow.c   | 263 ++
 test/test-main.c   |   3 +-
 28 files changed, 1283 insertions(+), 74 deletions(-)
 create mode 100644 boot/bootmeth_cros.c

-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 01/19] test: Restore test behaviour on failure

2023-06-20 Thread Simon Glass
A recent change makes test continue to run after failure. This results in
a lot of useless output and may lead to a segfault. Fix this by adding
back the 'return' statement.

Note that this is not a full revert of the original commit. It only
removes the unwanted 'return' statements in each macro.

Fixes: fa847bb409d ("test: Wrap assert macros in ({ ... }) and fix")

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add a comment that this is not a full revert

 include/test/ut.h | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/test/ut.h b/include/test/ut.h
index dddf9ad241fe..ea6ee95d7344 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -130,7 +130,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
\
if (!(cond)) {  \
ut_fail(uts, __FILE__, __LINE__, __func__, #cond);  \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -142,7 +142,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
if (!(cond)) {  \
ut_failf(uts, __FILE__, __LINE__, __func__, #cond,  \
 fmt, ##args);  \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -157,7 +157,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
 #expr1 " == " #expr2,  \
 "Expected %#x (%d), got %#x (%d)", \
 _val1, _val1, _val2, _val2);   \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -175,7 +175,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
 (unsigned long long)_val1, \
 (unsigned long long)_val2, \
 (unsigned long long)_val2);\
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -189,7 +189,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
ut_failf(uts, __FILE__, __LINE__, __func__, \
 #expr1 " = " #expr2,   \
 "Expected \"%s\", got \"%s\"", _val1, _val2);  \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -208,7 +208,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
 #expr1 " = " #expr2,   \
 "Expected \"%.*s\", got \"%.*s\"", \
 _len, _val1, _len, _val2); \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret;  \
 })
@@ -228,7 +228,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int 
total_bytes);
 #expr1 " = " #expr2,   \
 "Expected \"%s\", got \"%s\"", \
 __buf1, __buf2);   \
-   __ret = CMD_RET_FAILURE;\
+   return CMD_RET_FAILURE; \
}   \
__ret; 

[PATCH v2 02/19] test: Skip flat-tree tests if devicetree is not used

2023-06-20 Thread Simon Glass
Many tests don't actually use the devicetree at all so there is no point
in running the tests both with livetree and flat tree. Check for this and
skip the flat tree test in that case.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 test/test-main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/test/test-main.c b/test/test-main.c
index b3c30d929376..f770bdb81ea9 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -476,7 +476,8 @@ static int ut_run_test_live_flat(struct unit_test_state 
*uts,
 *   (for sandbox we handle this by copying the tree, but not for other
 *boards)
 */
-   if (!(test->flags & UT_TESTF_LIVE_TREE) &&
+   if ((test->flags & UT_TESTF_SCAN_FDT) &&
+   !(test->flags & UT_TESTF_LIVE_TREE) &&
(CONFIG_IS_ENABLED(OFNODE_MULTI_TREE) ||
 !(test->flags & UT_TESTF_OTHER_FDT)) &&
(!runs || ut_test_run_on_flattree(test)) &&
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 05/19] bootstd: Correct baudrate typo

2023-06-20 Thread Simon Glass
This is a copy error. Fix it.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/bootmeth-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/bootmeth-uclass.c b/boot/bootmeth-uclass.c
index 3b3e0614dafa..33662a753889 100644
--- a/boot/bootmeth-uclass.c
+++ b/boot/bootmeth-uclass.c
@@ -421,7 +421,7 @@ int bootmeth_common_read_file(struct udevice *dev, struct 
bootflow *bflow,
 /**
  * on_bootmeths() - Update the bootmeth order
  *
- * This will check for a valid baudrate and only apply it if valid.
+ * This will check for a valid list of bootmeths and only apply it if valid.
  */
 static int on_bootmeths(const char *name, const char *value, enum env_op op,
int flags)
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 06/19] bootstd: Allow storing the OS command line in the bootflow

2023-06-20 Thread Simon Glass
Some operating systems have a command line which can be adjusted before
booting. Store this in the bootflow so it can be controlled within
U-Boot.

Fix up the example output while we are here, since there are a few new
items.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2:
- Correct 'it not known' typo

 cmd/bootflow.c | 6 ++
 doc/usage/cmd/bootflow.rst | 5 -
 include/bootflow.h | 2 ++
 test/boot/bootflow.c   | 1 +
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 5c61286a2a76..ddb168c70390 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -324,6 +324,12 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int 
flag, int argc,
printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf));
printf("Size:  %x (%d bytes)\n", bflow->size, bflow->size);
printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)");
+   printf("Cmdline:   ");
+   if (bflow->cmdline)
+   puts(bflow->cmdline);
+   else
+   puts("(none)");
+   putc('\n');
printf("Logo:  %s\n", bflow->logo ?
   simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)");
if (bflow->logo) {
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index 8590efca2182..907d44ad9f9b 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -258,7 +258,6 @@ displayed and booted::
 Name:  mmc@7e202000.bootdev.part_2
 Device:mmc@7e202000.bootdev
 Block dev: m...@7e202000.blk
-Sequence:  1
 Method:distro
 State: ready
 Partition: 2
@@ -266,6 +265,10 @@ displayed and booted::
 Filename:  extlinux/extlinux.conf
 Buffer:3db7ae88
 Size:  232 (562 bytes)
+OS:Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl)
+Cmdline:   (none)
+Logo:  (none)
+FDT:   
 Error: 0
 U-Boot> bootflow boot
 ** Booting bootflow 'smsc95xx_eth.bootdev.0'
diff --git a/include/bootflow.h b/include/bootflow.h
index 018d021b8107..a1c16ab93b75 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -81,6 +81,7 @@ enum bootflow_flags_t {
  * @fdt_size: Size of FDT file
  * @fdt_addr: Address of loaded fdt
  * @flags: Flags for the bootflow (see enum bootflow_flags_t)
+ * @cmdline: OS command line, or NULL if not known (allocated)
  */
 struct bootflow {
struct list_head bm_node;
@@ -104,6 +105,7 @@ struct bootflow {
int fdt_size;
ulong fdt_addr;
int flags;
+   char *cmdline;
 };
 
 /**
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 2b5f87d7f091..f7ebf9d7f278 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -226,6 +226,7 @@ static int bootflow_cmd_info(struct unit_test_state *uts)
ut_assert_nextlinen("Buffer:");
ut_assert_nextline("Size:  253 (595 bytes)");
ut_assert_nextline("OS:Fedora-Workstation-armhfp-31-1.9 
(5.3.7-301.fc31.armv7hl)");
+   ut_assert_nextline("Cmdline:   (none)");
ut_assert_nextline("Logo:  (none)");
ut_assert_nextline("FDT:   ");
ut_assert_nextline("Error: 0");
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 07/19] bootstd: Use the bootargs env var for changing the cmdline

2023-06-20 Thread Simon Glass
The "bootargs" environment variable is used to set the command-line
arguments to pass to the OS. Use this same mechanism with bootstd as well.
When the variable is updated, it is written to the current bootflow. When
the current bootflow is updated, the environment variable is updated too.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 boot/bootflow.c| 59 ++
 cmd/bootflow.c |  6 +
 include/env_callback.h |  6 +++--
 3 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 487552fa28c0..62b7f45ab278 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -552,3 +553,61 @@ int bootflow_iter_check_system(const struct bootflow_iter 
*iter)
 
return -ENOTSUPP;
 }
+
+/**
+ * bootflow_cmdline_set() - Set the command line for a bootflow
+ *
+ * @value: New command-line string
+ * Returns 0 if OK, -ENOENT if no current bootflow, -ENOMEM if out of memory
+ */
+int bootflow_cmdline_set(struct bootflow *bflow, const char *value)
+{
+   char *cmdline = NULL;
+
+   if (value) {
+   cmdline = strdup(value);
+   if (!cmdline)
+   return -ENOMEM;
+   }
+
+   free(bflow->cmdline);
+   bflow->cmdline = cmdline;
+
+   return 0;
+}
+
+#ifdef CONFIG_BOOTSTD_FULL
+/**
+ * on_bootargs() - Update the cmdline of a bootflow
+ */
+static int on_bootargs(const char *name, const char *value, enum env_op op,
+  int flags)
+{
+   struct bootstd_priv *std;
+   struct bootflow *bflow;
+   int ret;
+
+   ret = bootstd_get_priv(&std);
+   if (ret)
+   return 0;
+   bflow = std->cur_bootflow;
+   if (!bflow)
+   return 0;
+
+   switch (op) {
+   case env_op_create:
+   case env_op_overwrite:
+   ret = bootflow_cmdline_set(bflow, value);
+   if (ret && ret != ENOENT)
+   return 1;
+   return 0;
+   case env_op_delete:
+   bootflow_cmdline_set(bflow, NULL);
+   fallthrough;
+   default:
+   return 0;
+   }
+}
+U_BOOT_ENV_CALLBACK(bootargs, on_bootargs);
+#endif
+
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index ddb168c70390..f33db7be5f2e 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -288,6 +288,12 @@ static int do_bootflow_select(struct cmd_tbl *cmdtp, int 
flag, int argc,
return CMD_RET_FAILURE;
}
std->cur_bootflow = found;
+   if (IS_ENABLED(CONFIG_BOOTSTD_FULL)) {
+   if (env_set("bootargs", found->cmdline)) {
+   printf("Cannot set bootargs\n");
+   return CMD_RET_FAILURE;
+   }
+   }
 
return 0;
 }
diff --git a/include/env_callback.h b/include/env_callback.h
index a9a14f2a84a5..23bc650c162d 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -60,8 +60,10 @@
 #define NET6_CALLBACKS
 #endif
 
-#ifdef CONFIG_BOOTSTD
-#define BOOTSTD_CALLBACK   "bootmeths:bootmeths,"
+#ifdef CONFIG_BOOTSTD_FULL
+#define BOOTSTD_CALLBACK \
+   "bootmeths:bootmeths," \
+   "bootargs:bootargs,"
 #else
 #define BOOTSTD_CALLBACK
 #endif
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 03/19] bootstd: Correct the name of the QEMU bootmeth

2023-06-20 Thread Simon Glass
This does not relate to sandbox. Correct the name.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/bootmeth_qfw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/bootmeth_qfw.c b/boot/bootmeth_qfw.c
index ecd4b082fd20..8ebbc3ebcd58 100644
--- a/boot/bootmeth_qfw.c
+++ b/boot/bootmeth_qfw.c
@@ -76,7 +76,7 @@ static int qfw_bootmeth_bind(struct udevice *dev)
 {
struct bootmeth_uc_plat *plat = dev_get_uclass_plat(dev);
 
-   plat->desc = "Sandbox boot for testing";
+   plat->desc = "QEMU boot using firmware interface";
 
return 0;
 }
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 08/19] bootstd: Allow storing x86 setup information

2023-06-20 Thread Simon Glass
On x86 boards Linux uses a block of binary data to provide information
about the command line, memory map, etc. Provide a way to store this in
the bootflow so it can be passed on to the OS.

No attempt is made to generalise the code, since other archs don't need
this information. The field is present always, though, to avoid needing
accessors or #ifdefs when building code on other archs.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Explain why the setup information is not behind an #ifdef

 cmd/bootflow.c | 2 ++
 include/bootflow.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index f33db7be5f2e..bf30087c7c4e 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -336,6 +336,8 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int 
flag, int argc,
else
puts("(none)");
putc('\n');
+   if (bflow->x86_setup)
+   printf("X86 setup: %p\n", bflow->x86_setup);
printf("Logo:  %s\n", bflow->logo ?
   simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)");
if (bflow->logo) {
diff --git a/include/bootflow.h b/include/bootflow.h
index a1c16ab93b75..f263173c4da5 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -82,6 +82,7 @@ enum bootflow_flags_t {
  * @fdt_addr: Address of loaded fdt
  * @flags: Flags for the bootflow (see enum bootflow_flags_t)
  * @cmdline: OS command line, or NULL if not known (allocated)
+ * @x86_setup: Pointer to x86 setup block inside @buf, NULL if not present
  */
 struct bootflow {
struct list_head bm_node;
@@ -106,6 +107,7 @@ struct bootflow {
ulong fdt_addr;
int flags;
char *cmdline;
+   char *x86_setup;
 };
 
 /**
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 04/19] bootstd: Use bootdev instead of bootdevice

2023-06-20 Thread Simon Glass
It seems better to call this a 'bootdev' since this is name used in the
documentation. The older 'Bootdevice' name is no-longer used and may cause
confusion with the 'bootdevice' environment variable.

Update throughout to use bootdev.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Update host_bootdev.c too

 boot/bootflow.c| 4 ++--
 drivers/mmc/mmc_bootdev.c  | 2 +-
 drivers/scsi/scsi_bootdev.c| 2 +-
 drivers/usb/host/usb_bootdev.c | 2 +-
 fs/sandbox/host_bootdev.c  | 2 +-
 include/bootdev.h  | 2 +-
 include/bootflow.h | 2 +-
 net/eth_bootdev.c  | 2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 8f2cb876bb49..487552fa28c0 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -315,14 +315,14 @@ static int bootflow_check(struct bootflow_iter *iter, 
struct bootflow *bflow)
 
/* If we got a valid bootflow, return it */
if (!ret) {
-   log_debug("Bootdevice '%s' part %d method '%s': Found 
bootflow\n",
+   log_debug("Bootdev '%s' part %d method '%s': Found bootflow\n",
  dev->name, iter->part, iter->method->name);
return 0;
}
 
/* Unless there is nothing more to try, move to the next device */
else if (ret != BF_NO_MORE_PARTS && ret != -ENOSYS) {
-   log_debug("Bootdevice '%s' part %d method '%s': Error %d\n",
+   log_debug("Bootdev '%s' part %d method '%s': Error %d\n",
  dev->name, iter->part, iter->method->name, ret);
/*
 * For 'all' we return all bootflows, even
diff --git a/drivers/mmc/mmc_bootdev.c b/drivers/mmc/mmc_bootdev.c
index b57b8a62276d..55ecead2ddf9 100644
--- a/drivers/mmc/mmc_bootdev.c
+++ b/drivers/mmc/mmc_bootdev.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Bootdevice for MMC
+ * Bootdev for MMC
  *
  * Copyright 2021 Google LLC
  * Written by Simon Glass 
diff --git a/drivers/scsi/scsi_bootdev.c b/drivers/scsi/scsi_bootdev.c
index 991013fe1ef2..218221fa3062 100644
--- a/drivers/scsi/scsi_bootdev.c
+++ b/drivers/scsi/scsi_bootdev.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Bootdevice for USB
+ * Bootdev for SCSI
  *
  * Copyright 2021 Google LLC
  * Written by Simon Glass 
diff --git a/drivers/usb/host/usb_bootdev.c b/drivers/usb/host/usb_bootdev.c
index 06e8f61aa1c5..7fa1c601dff5 100644
--- a/drivers/usb/host/usb_bootdev.c
+++ b/drivers/usb/host/usb_bootdev.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Bootdevice for USB
+ * Bootdev for USB
  *
  * Copyright 2021 Google LLC
  * Written by Simon Glass 
diff --git a/fs/sandbox/host_bootdev.c b/fs/sandbox/host_bootdev.c
index 0d12ee4ef74f..3ef53627608a 100644
--- a/fs/sandbox/host_bootdev.c
+++ b/fs/sandbox/host_bootdev.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Bootdevice for MMC
+ * Bootdev for sandbox host
  *
  * Copyright 2021 Google LLC
  * Written by Simon Glass 
diff --git a/include/bootdev.h b/include/bootdev.h
index e72ef3650f7c..1533adfe5065 100644
--- a/include/bootdev.h
+++ b/include/bootdev.h
@@ -200,7 +200,7 @@ void bootdev_clear_bootflows(struct udevice *dev);
  * All fields in @bflow must be set up. Note that @bflow->dev is used to add 
the
  * bootflow to that device.
  *
- * @dev: Bootdevice device to add to
+ * @dev: Bootdev device to add to
  * @bflow: Bootflow to add. Note that fields within bflow must be allocated
  * since this function takes over ownership of these. This functions makes
  * a copy of @bflow itself (without allocating its fields again), so the
diff --git a/include/bootflow.h b/include/bootflow.h
index f20f575030f1..018d021b8107 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -58,7 +58,7 @@ enum bootflow_flags_t {
  *
  * @bm_node: Points to siblings in the same bootdev
  * @glob_node: Points to siblings in the global list (all bootdev)
- * @dev: Bootdevice device which produced this bootflow
+ * @dev: Bootdev device which produced this bootflow
  * @blk: Block device which contains this bootflow, NULL if this is a network
  * device or sandbox 'host' device
  * @part: Partition number (0 for whole device)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c
index f7b4196f78db..869adf8cbbd3 100644
--- a/net/eth_bootdev.c
+++ b/net/eth_bootdev.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Bootdevice for ethernet (uses PXE)
+ * Bootdev for ethernet (uses PXE)
  *
  * Copyright 2021 Google LLC
  * Written by Simon Glass 
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 09/19] bdinfo: Show information about the serial port

2023-06-20 Thread Simon Glass
It is useful to see the detailed setting of the serial port, e.g. to
allow setting up earlycon or console for Linux. Add this output to the
'bdinfo' command.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 cmd/bdinfo.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index a864f01525fe..1fe13ca13a0a 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -113,6 +114,25 @@ static void show_video_info(void)
}
 }
 
+static void print_serial(struct udevice *dev)
+{
+   struct serial_device_info info;
+   int ret;
+
+   if (!dev || !IS_ENABLED(CONFIG_DM_SERIAL))
+   return;
+
+   ret = serial_getinfo(dev, &info);
+   if (ret)
+   return;
+
+   bdinfo_print_num_l("serial addr", info.addr);
+   bdinfo_print_num_l(" width", info.reg_width);
+   bdinfo_print_num_l(" shift", info.reg_shift);
+   bdinfo_print_num_l(" offset", info.reg_offset);
+   bdinfo_print_num_l(" clock", info.clock);
+}
+
 int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
struct bd_info *bd = gd->bd;
@@ -151,6 +171,7 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
if (IS_ENABLED(CONFIG_OF_REAL))
printf("devicetree  = %s\n", fdtdec_get_srcname());
}
+   print_serial(gd->cur_serial_dev);
 
if (IS_ENABLED(CONFIG_CMD_BDINFO_EXTRA)) {
bdinfo_print_num_ll("stack ptr", (ulong)&bd);
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 11/19] bootstd: Add support for updating elements of the cmdline

2023-06-20 Thread Simon Glass
Add a bootflow command to update the command line more easily. This allows
changing a particular parameter rather than editing a very long strings.
It is also easier to handle with scripting.

The new 'bootflow cmdline' command allows getting and setting single
parameters.

Fix up the example output while we are here, since there are a few new
items.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2:
- Show error messages when something goes wrong

 boot/bootflow.c|  53 ++
 cmd/bootflow.c |  70 +++-
 doc/usage/cmd/bootflow.rst |  22 +++-
 include/bootflow.h |  42 +++
 test/boot/bootflow.c   | 108 +
 5 files changed, 293 insertions(+), 2 deletions(-)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 26f26aee38a3..8c649e8e66ca 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -801,3 +801,56 @@ int cmdline_set_arg(char *buf, int maxlen, const char 
*cmdline,
 
return to - buf;
 }
+
+int bootflow_cmdline_set_arg(struct bootflow *bflow, const char *set_arg,
+const char *new_val, bool set_env)
+{
+   char buf[2048];
+   char *cmd = NULL;
+   int ret;
+
+   ret = cmdline_set_arg(buf, sizeof(buf), bflow->cmdline, set_arg,
+ new_val, NULL);
+   if (ret < 0)
+   return ret;
+
+   ret = bootflow_cmdline_set(bflow, buf);
+   if (*buf) {
+   cmd = strdup(buf);
+   if (!cmd)
+   return -ENOMEM;
+   }
+   free(bflow->cmdline);
+   bflow->cmdline = cmd;
+
+   if (set_env) {
+   ret = env_set("bootargs", bflow->cmdline);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+int cmdline_get_arg(const char *cmdline, const char *arg, int *posp)
+{
+   int ret;
+
+   ret = cmdline_set_arg(NULL, 1, cmdline, arg, NULL, posp);
+
+   return ret;
+}
+
+int bootflow_cmdline_get_arg(struct bootflow *bflow, const char *arg,
+const char **val)
+{
+   int ret;
+   int pos;
+
+   ret = cmdline_get_arg(bflow->cmdline, arg, &pos);
+   if (ret < 0)
+   return ret;
+   *val = bflow->cmdline + pos;
+
+   return ret;
+}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index bf30087c7c4e..ab00e4a19e14 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -431,6 +431,72 @@ static int do_bootflow_menu(struct cmd_tbl *cmdtp, int 
flag, int argc,
 
return 0;
 }
+
+static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+   struct bootstd_priv *std;
+   struct bootflow *bflow;
+   const char *op, *arg, *val = NULL;
+   int ret;
+
+   if (argc < 3)
+   return CMD_RET_USAGE;
+
+   ret = bootstd_get_priv(&std);
+   if (ret)
+   return CMD_RET_FAILURE;
+
+   bflow = std->cur_bootflow;
+   if (!bflow) {
+   printf("No bootflow selected\n");
+   return CMD_RET_FAILURE;
+   }
+
+   op = argv[1];
+   arg = argv[2];
+   if (*op == 's') {
+   if (argc < 4)
+   return CMD_RET_USAGE;
+   val = argv[3];
+   }
+
+   switch (*op) {
+   case 'c':   /* clear */
+   val = "";
+   fallthrough;
+   case 's':   /* set */
+   case 'd':   /* delete */
+   ret = bootflow_cmdline_set_arg(bflow, arg, val, true);
+   break;
+   case 'g':   /* get */
+   ret = bootflow_cmdline_get_arg(bflow, arg, &val);
+   if (ret >= 0)
+   printf("%.*s\n", ret, val);
+   break;
+   }
+   switch (ret) {
+   case -E2BIG:
+   printf("Argument too long\n");
+   break;
+   case -ENOENT:
+   printf("Argument not found\n");
+   break;
+   case -EINVAL:
+   printf("Mismatched quotes\n");
+   break;
+   case -EBADF:
+   printf("Value must be quoted\n");
+   break;
+   default:
+   if (ret < 0)
+   printf("Unknown error: %dE\n", ret);
+   }
+   if (ret < 0)
+   return CMD_RET_FAILURE;
+
+   return 0;
+}
 #endif /* CONFIG_CMD_BOOTFLOW_FULL */
 
 #ifdef CONFIG_SYS_LONGHELP
@@ -441,7 +507,8 @@ static char bootflow_help_text[] =
"bootflow select [|] - select a bootflow\n"
"bootflow info [-d] - show info on current bootflow (-d 
dump bootflow)\n"
"bootflow boot  - boot current bootflow (or first 
available if none selected)\n"
-   "bootflow menu [-t] - show a menu of available bootflows";
+   "bootflow menu [-t] - show a menu of available bootflows\n"
+

[PATCH v2 13/19] x86: qemu: Switch to standard boot

2023-06-20 Thread Simon Glass
Drop use of the distro boot script and use standard boot instead.

Moving to a text-based environment would be desirable also, but requires
additional work.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to switch x86 qemu to standard boot

 configs/qemu-x86_64_defconfig | 2 +-
 configs/qemu-x86_defconfig| 2 +-
 include/configs/qemu-x86.h| 8 
 3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 45df1e46fa38..3e0970d70e29 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -22,7 +22,7 @@ CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
-CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index fcf429f77115..79ca5cd54c87 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -9,7 +9,7 @@ CONFIG_SMP=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_FIT=y
-CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
index 33263a46a407..3e5235291a28 100644
--- a/include/configs/qemu-x86.h
+++ b/include/configs/qemu-x86.h
@@ -12,14 +12,6 @@
 
 #include 
 
-#define BOOT_TARGET_DEVICES(func) \
-   func(USB, usb, 0) \
-   func(SCSI, scsi, 0) \
-   func(VIRTIO, virtio, 0) \
-   func(IDE, ide, 0) \
-   func(DHCP, dhcp, na)
-
-#include 
 #include 
 
 #define CFG_STD_DEVICES_SETTINGS   "stdin=serial,i8042-kbd\0" \
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 12/19] x86: qemu: Create a little more room for U-Boot

2023-06-20 Thread Simon Glass
We want to enable some of the more interesting bootstd features. Move SPL
up to create some room for the larger U-Boot binary. Also disable
microcode since this is not needed

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to create a little more room for U-Boot on qemu-x86_64

 configs/qemu-x86_64_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 870332a1e625..45df1e46fa38 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -6,13 +6,14 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_MAX_CPUS=2
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
-CONFIG_SPL_TEXT_BASE=0xfffd
+CONFIG_SPL_TEXT_BASE=0xfffd8000
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000
 CONFIG_DEBUG_UART_BASE=0x3f8
 CONFIG_DEBUG_UART_CLOCK=1843200
 CONFIG_X86_RUN_64BIT=y
 CONFIG_TARGET_QEMU_X86_64=y
 CONFIG_DEBUG_UART=y
+# CONFIG_HAVE_MICROCODE is not set
 CONFIG_SMP=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 10/19] bootstd: Add a function to update a command line

2023-06-20 Thread Simon Glass
The Linux command line consists of a number of words with optional values.
At present U-Boot allows this to be changed using the bootargs environment
variable.

But this is quite painful, since the command line can be very long.

Add a function which can adjust a single field in the command line, so
that it is easier to make changes before booting.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add comment for copy_in()
- Avoid multiplication on a boolean
- Add a comment as to why @len is needed

 boot/bootflow.c  | 190 +++
 include/bootflow.h   |  40 +
 test/boot/bootflow.c | 154 +++
 3 files changed, 384 insertions(+)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 62b7f45ab278..26f26aee38a3 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -611,3 +611,193 @@ static int on_bootargs(const char *name, const char 
*value, enum env_op op,
 U_BOOT_ENV_CALLBACK(bootargs, on_bootargs);
 #endif
 
+/**
+ * copy_in() - Copy a string into a cmdline buffer
+ *
+ * @buf: Buffer to copy into
+ * @end: End of buffer (pointer to char after the end)
+ * @arg: String to copy from
+ * @len: Number of chars to copy from @arg (note that this is not usually the
+ * sane as strlen(arg) since the string may contain following arguments)
+ * @new_val: Value to put after arg, or BOOTFLOWCL_EMPTY to use an empty value
+ * with no '=' sign
+ * Returns: Number of chars written to @buf
+ */
+static int copy_in(char *buf, char *end, const char *arg, int len,
+  const char *new_val)
+{
+   char *to = buf;
+
+   /* copy the arg name */
+   if (to + len >= end)
+   return -E2BIG;
+   memcpy(to, arg, len);
+   to += len;
+
+   if (new_val == BOOTFLOWCL_EMPTY) {
+   /* no value */
+   } else {
+   bool need_quote = strchr(new_val, ' ');
+   len = strlen(new_val);
+
+   /* need space for value, equals sign and maybe two quotes */
+   if (to + 1 + (need_quote ? 2 : 0) + len >= end)
+   return -E2BIG;
+   *to++ = '=';
+   if (need_quote)
+   *to++ = '"';
+   memcpy(to, new_val, len);
+   to += len;
+   if (need_quote)
+   *to++ = '"';
+   }
+
+   return to - buf;
+}
+
+int cmdline_set_arg(char *buf, int maxlen, const char *cmdline,
+   const char *set_arg, const char *new_val, int *posp)
+{
+   bool found_arg = false;
+   const char *from;
+   char *to, *end;
+   int set_arg_len;
+   char empty = '\0';
+   int ret;
+
+   from = cmdline ?: ∅
+
+   /* check if the value has quotes inside */
+   if (new_val && new_val != BOOTFLOWCL_EMPTY && strchr(new_val, '"'))
+   return -EBADF;
+
+   set_arg_len = strlen(set_arg);
+   for (to = buf, end = buf + maxlen; *from;) {
+   const char *val, *arg_end, *val_end, *p;
+   bool in_quote;
+
+   if (to >= end)
+   return -E2BIG;
+   while (*from == ' ')
+   from++;
+   if (!*from)
+   break;
+
+   /* find the end of this arg */
+   val = NULL;
+   arg_end = NULL;
+   val_end = NULL;
+   in_quote = false;
+   for (p = from;; p++) {
+   if (in_quote) {
+   if (!*p)
+   return -EINVAL;
+   if (*p == '"')
+   in_quote = false;
+   continue;
+   }
+   if (*p == '=') {
+   arg_end = p;
+   val = p + 1;
+   } else if (*p == '"') {
+   in_quote = true;
+   } else if (!*p || *p == ' ') {
+   val_end = p;
+   if (!arg_end)
+   arg_end = p;
+   break;
+   }
+   }
+   /*
+* At this point val_end points to the end of the value, or the
+* last char after the arg name, if there is no label.
+* arg_end is the char after the arg name
+* val points to the value, or NULL if there is none
+* char after the value.
+*
+*fred=1234
+*^   ^^   ^
+*  from  ||   |
+*   / \\
+*arg_end  val   val_end
+*/
+   log_debug("from %s arg_end %ld val %ld val_end %ld\n", from,
+ (long)(arg_end - fr

[PATCH v2 15/19] x86: Add a function to boot a zimage

2023-06-20 Thread Simon Glass
Add a direct interface to booting a zimage, so that bootstd can call it
without going through the command-line interface.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/x86/include/asm/zimage.h | 17 
 arch/x86/lib/zimage.c | 82 ++-
 2 files changed, 88 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 000b38ea8993..966d7224eb18 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -72,4 +72,21 @@ int setup_zimage(struct boot_params *setup_base, char 
*cmd_line, int auto_boot,
  */
 void zimage_dump(struct boot_params *base_ptr);
 
+/**
+ * zboot_start() - Boot a zimage
+ *
+ * Boot a zimage, given the component parts
+ *
+ * @addr: Address where the bzImage is moved before booting, either
+ * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR
+ * @base: Pointer to the boot parameters, typically at address
+ * DEFAULT_SETUP_BASE
+ * @initrd: Address of the initial ramdisk, or 0 if none
+ * @initrd_size: Size of the initial ramdisk, or 0 if none
+ * @cmdline: Command line to use for booting
+ * Return: -EFAULT on error (normally it does not return)
+ */
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+   ulong base, char *cmdline);
+
 #endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index e5ea5129c1e9..540d4d888bc7 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -442,8 +443,7 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, 
int argc,
return 0;
 }
 
-static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
+static int zboot_load(void)
 {
struct boot_params *base_ptr;
 
@@ -460,31 +460,51 @@ static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, 
int argc,
   &state.load_address);
if (!base_ptr) {
puts("## Kernel loading failed ...\n");
-   return CMD_RET_FAILURE;
+   return -EINVAL;
}
}
state.base_ptr = base_ptr;
-   if (env_set_hex("zbootbase", (ulong)base_ptr) ||
+
+   return 0;
+}
+
+static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+   if (zboot_load())
+   return CMD_RET_FAILURE;
+
+   if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) ||
env_set_hex("zbootaddr", state.load_address))
return CMD_RET_FAILURE;
 
return 0;
 }
 
+static int zboot_setup(void)
+{
+   struct boot_params *base_ptr = state.base_ptr;
+   int ret;
+
+   ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
+  0, state.initrd_addr, state.initrd_size,
+  (ulong)state.cmdline);
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
  char *const argv[])
 {
struct boot_params *base_ptr = state.base_ptr;
-   int ret;
 
if (!base_ptr) {
printf("base is not set: use 'zboot load' first\n");
return CMD_RET_FAILURE;
}
-   ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
-  0, state.initrd_addr, state.initrd_size,
-  (ulong)state.cmdline);
-   if (ret) {
+   if (zboot_setup()) {
puts("Setting up boot parameters failed ...\n");
return CMD_RET_FAILURE;
}
@@ -501,8 +521,7 @@ static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, 
int argc,
return 0;
 }
 
-static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
-  char *const argv[])
+static int zboot_go(void)
 {
struct boot_params *params = state.base_ptr;
struct setup_header *hdr = ¶ms->hdr;
@@ -522,11 +541,52 @@ static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
/* we assume that the kernel is in place */
ret = boot_linux_kernel((ulong)state.base_ptr, entry, image_64bit);
+
+   return ret;
+}
+
+static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+   int ret;
+
+   ret = zboot_go();
printf("Kernel returned! (err=%d)\n", ret);
 
return CMD_RET_FAILURE;
 }
 
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+   ulong base, char *cmdline)
+{
+   int ret;
+
+   memset(&state, '\0', sizeof(state));
+
+   if (base) {
+   state.base_ptr = map_sysmem(base, 0);
+   state.load_address = addr;
+

[PATCH v2 16/19] x86: zimage: Export the function to obtain the cmdline

2023-06-20 Thread Simon Glass
Allow reading the command line from a zimage, so that it can be recorded
in the bootflow.

Reviewed-by: Bin Meng 
Signed-off-by: Simon Glass 
---

(no changes since v1)

 arch/x86/include/asm/zimage.h | 10 ++
 arch/x86/lib/zimage.c | 11 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 966d7224eb18..9ad74dc0b946 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -89,4 +89,14 @@ void zimage_dump(struct boot_params *base_ptr);
 int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
ulong base, char *cmdline);
 
+/*
+ * zimage_get_kernel_version() - Get the version string from a kernel
+ *
+ * @params: boot_params pointer
+ * @kernel_base: base address of kernel
+ * Return: Kernel version as a NUL-terminated string
+ */
+const char *zimage_get_kernel_version(struct boot_params *params,
+ void *kernel_base);
+
 #endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 540d4d888bc7..062e3d3e3151 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -181,7 +181,7 @@ static int setup_device_tree(struct setup_header *hdr, 
const void *fdt_blob)
return 0;
 }
 
-static const char *get_kernel_version(struct boot_params *params,
+const char *zimage_get_kernel_version(struct boot_params *params,
  void *kernel_base)
 {
struct setup_header *hdr = ¶ms->hdr;
@@ -189,10 +189,14 @@ static const char *get_kernel_version(struct boot_params 
*params,
const char *s, *end;
 
bootproto = get_boot_protocol(hdr, false);
+   log_debug("bootproto %x, hdr->setup_sects %x\n", bootproto,
+ hdr->setup_sects);
if (bootproto < 0x0200 || hdr->setup_sects < 15)
return NULL;
 
/* sanity-check the kernel version in case it is missing */
+   log_debug("hdr->kernel_version %x, str at %p\n", hdr->kernel_version,
+ kernel_base + hdr->kernel_version + 0x200);
for (s = kernel_base + hdr->kernel_version + 0x200, end = s + 0x100; *s;
 s++) {
if (!isprint(*s))
@@ -239,7 +243,7 @@ struct boot_params *load_zimage(char *image, unsigned long 
kernel_size,
log_debug("Using boot protocol version %x.%02x\n",
  (bootproto & 0xff00) >> 8, bootproto & 0xff);
 
-   version = get_kernel_version(params, image);
+   version = zimage_get_kernel_version(params, image);
if (version)
printf("Linux kernel version %s\n", version);
else
@@ -728,7 +732,8 @@ void zimage_dump(struct boot_params *base_ptr)
print_num("Real mode switch", hdr->realmode_swtch);
print_num("Start sys seg", hdr->start_sys_seg);
print_num("Kernel version", hdr->kernel_version);
-   version = get_kernel_version(base_ptr, (void *)state.bzimage_addr);
+   version = zimage_get_kernel_version(base_ptr,
+   (void *)state.bzimage_addr);
if (version)
printf("   @%p: %s\n", version, version);
print_num("Type of loader", hdr->type_of_loader);
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 14/19] bootstd: Support automatically setting Linux parameters

2023-06-20 Thread Simon Glass
Some Linux parameters can be set automatically by U-Boot, if it knows the
device being used. For example, since U-Boot knows the serial console
being used, it can add parameters for earlycon and console.

Add support for this.

Note that this is an experimental feature and we will see how useful it
turns out to be. It is very handy for ChromeOS, since otherwise it is very
difficult to manually determine the UART address or port number,
particularly in a script.

Provide an example of how this is used with ChromeOS.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/bootflow.c| 33 +
 cmd/bootflow.c |  5 ++-
 doc/usage/cmd/bootflow.rst | 75 +-
 include/bootflow.h | 12 ++
 4 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 8c649e8e66ca..81b5829d5b37 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -854,3 +855,35 @@ int bootflow_cmdline_get_arg(struct bootflow *bflow, const 
char *arg,
 
return ret;
 }
+
+int bootflow_cmdline_auto(struct bootflow *bflow, const char *arg)
+{
+   struct serial_device_info info;
+   char buf[50];
+   int ret;
+
+   ret = serial_getinfo(gd->cur_serial_dev, &info);
+   if (ret)
+   return ret;
+
+   *buf = '\0';
+   if (!strcmp("earlycon", arg)) {
+   snprintf(buf, sizeof(buf),
+"uart8250,mmio32,%#lx,%dn8", info.addr,
+info.baudrate);
+   } else if (!strcmp("console", arg)) {
+   snprintf(buf, sizeof(buf),
+"ttyS0,%dn8", info.baudrate);
+   }
+
+   if (!*buf) {
+   printf("Unknown param '%s\n", arg);
+   return -ENOENT;
+   }
+
+   ret = bootflow_cmdline_set_arg(bflow, arg, buf, true);
+   if (ret)
+   return ret;
+
+   return 0;
+}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index ab00e4a19e14..c0aa4f84fe8d 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -474,6 +474,9 @@ static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int 
flag, int argc,
if (ret >= 0)
printf("%.*s\n", ret, val);
break;
+   case 'a':   /* auto */
+   ret = bootflow_cmdline_auto(bflow, arg);
+   break;
}
switch (ret) {
case -E2BIG:
@@ -508,7 +511,7 @@ static char bootflow_help_text[] =
"bootflow info [-d] - show info on current bootflow (-d 
dump bootflow)\n"
"bootflow boot  - boot current bootflow (or first 
available if none selected)\n"
"bootflow menu [-t] - show a menu of available bootflows\n"
-   "bootflow cmdline [set|get|clear|delete]  [] - update 
cmdline";
+   "bootflow cmdline [set|get|clear|delete|auto]  [] - 
update cmdline";
 #else
"scan - boot first available bootflow\n";
 #endif
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index 07af789e6702..a8af1f8f6030 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -13,7 +13,7 @@ Synopis
 bootflow select []
 bootflow info [-d]
 bootflow boot
-bootflow cmdline [set|get|clear|delete]  []
+bootflow cmdline [set|get|clear|delete|auto]  []
 
 Description
 ---
@@ -218,6 +218,16 @@ To delete a parameter entirely, use::
 
 bootflow cmdline delete 
 
+Automatic parameters are available in a very few cases. You can use these to
+add parmeters where the value is known by U-Boot. For example::
+
+bootflow cmdline auto earlycon
+bootflow cmdline auto console
+
+can be used to set the early console (or console) to a suitable value so that
+output appears on the serial port. This is only supported by the 16550 serial
+driver so far.
+
 Example
 ---
 
@@ -450,6 +460,69 @@ Here is am example using the -e flag to see all errors::
 (21 bootflows, 2 valid)
 U-Boot>
 
+Here is an example of booting ChromeOS, adjusting the console beforehand. Note 
that
+the cmdline is word-wrapped here and some parts of the command line are 
elided::
+
+=> bootfl list
+Showing all bootflows
+Seq  Method   State   UclassPart  Name  
Filename
+---  ---  --        

+0  cros ready   nvme 0  5.10.153-20434-g98da1eb2c 
+1  efi  ready   nvme c  nvme#0.blk#1.bootdev.part 
efi/boot/bootia32.efi
+2  efi  ready   usb_mass_2  usb_mass_storage.lun0.boo 
efi/boot/bootia32.efi
+---  ---  --        

+(3 bootflows, 3 valid)
+=> bootfl sel 0
+=> bootfl inf
+Name:  5.10.153-20434-g98da1eb2cf9d 
(chrom

[PATCH v2 17/19] bootstd: Add a simple bootmeth for ChromiumOS

2023-06-20 Thread Simon Glass
It is possible to boot x86-based ChromeOS machines by parsing a table and
locating the kernel and command line. Add a bootmeth for this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/Kconfig |  11 ++
 boot/Makefile|   1 +
 boot/bootmeth_cros.c | 212 +++
 configs/tools-only_defconfig |   1 +
 4 files changed, 225 insertions(+)
 create mode 100644 boot/bootmeth_cros.c

diff --git a/boot/Kconfig b/boot/Kconfig
index eea5ed6040ff..98eb2ca94c8e 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -463,6 +463,17 @@ config BOOTMETH_GLOBAL
  EFI bootmgr, since they take full control over which bootdevs are
  selected to boot.
 
+config BOOTMETH_CROS
+   bool "Bootdev support for Chromium OS"
+   depends on X86 || SANDBOX
+   default y
+   help
+ Enables support for booting Chromium OS using bootdevs. This uses the
+ kernel A slot and obtains the kernel command line from the parameters
+ provided there.
+
+ Note that only x86 devices are supported at present.
+
 config BOOTMETH_EXTLINUX
bool "Bootdev support for extlinux boot"
select PXE_UTILS
diff --git a/boot/Makefile b/boot/Makefile
index f94c31d922de..6e4cdbd4ce28 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX) += bootmeth_extlinux.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX_PXE) += bootmeth_pxe.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootmeth_cros.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
 ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
new file mode 100644
index ..aa19ae097f56
--- /dev/null
+++ b/boot/bootmeth_cros.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmethod for ChromiumOS
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass 
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_X86
+#include 
+#endif
+#include 
+
+enum {
+   /* Offsets in the kernel-partition header */
+   KERN_START  = 0x4f0,
+   KERN_SIZE   = 0x518,
+
+   SETUP_OFFSET= 0x1000,   /* bytes before base */
+   CMDLINE_OFFSET  = 0x2000,   /* bytes before base */
+   OFFSET_BASE = 0x10, /* assumed kernel load-address */
+};
+
+static int cros_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+   /* This only works on block and network devices */
+   if (bootflow_iter_check_blk(iter))
+   return log_msg_ret("blk", -ENOTSUPP);
+
+   return 0;
+}
+
+static int copy_cmdline(const char *from, const char *uuid, char **bufp)
+{
+   const int maxlen = 2048;
+   char buf[maxlen];
+   char *cmd, *to, *end;
+   int len;
+
+   /* Allow space for cmdline + UUID */
+   len = strnlen(from, sizeof(buf));
+   if (len >= maxlen)
+   return -E2BIG;
+
+   log_debug("uuid %d %s\n", uuid ? (int)strlen(uuid) : 0, uuid);
+   for (to = buf, end = buf + maxlen - UUID_STR_LEN - 1; *from; from++) {
+   if (to >= end)
+   return -E2BIG;
+   if (from[0] == '%' && from[1] == 'U' && uuid &&
+   strlen(uuid) == UUID_STR_LEN) {
+   strcpy(to, uuid);
+   to += UUID_STR_LEN;
+   from++;
+   } else {
+   *to++ = *from;
+   }
+   }
+   *to = '\0';
+   len = to - buf;
+   cmd = strdup(buf);
+   if (!cmd)
+   return -ENOMEM;
+   free(*bufp);
+   *bufp = cmd;
+
+   return 0;
+}
+
+static int cros_read_bootflow(struct udevice *dev, struct bootflow *bflow)
+{
+   struct blk_desc *desc = dev_get_uclass_plat(bflow->blk);
+   ulong base, start, size, setup, cmdline, num_blks, kern_base;
+   struct disk_partition info;
+   const char *uuid = NULL;
+   void *buf, *hdr;
+   int ret;
+
+   log_debug("starting, part=%d\n", bflow->part);
+
+   /* We consider the whole disk, not any one partition */
+   if (bflow->part)
+   return log_msg_ret("max", -ENOENT);
+
+   /* Check partition 2 */
+   ret = part_get_info(desc, 2, &info);
+   if (ret)
+   return log_msg_ret("part", ret);
+
+   /* Make a buffer for the header information */
+   num_blks = SZ_4K >> desc->log2blksz;
+   log_debug("Reading header, blk=%s, start=%lx, blocks=%lx\n",
+ bflow->blk->name, (ulong)info.start, num_blks);
+   hdr = memalign(SZ_1K, SZ_4K);
+   if (!hdr)
+   return l

[PATCH v2 18/19] x86: coreboot: Adjust various config options

2023-06-20 Thread Simon Glass
Drop IDE since this is not widely used anymore. Add NVME since it is
becoming more popular.

Add ms so it is easier to search for tables in memory.

Expand the command-line and print buffers so that we can deal with the
very long ChromeOS command lines. (typically 700 characters).

Enable BOOTSTD_FULL to get the full set up standard-boot options.

Finally, expand the malloc() space so we can read large kernels into a
bootflow.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 configs/coreboot_defconfig | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
index 058caf008f9a..e650fca572f9 100644
--- a/configs/coreboot_defconfig
+++ b/configs/coreboot_defconfig
@@ -1,5 +1,6 @@
 CONFIG_X86=y
 CONFIG_TEXT_BASE=0x111
+CONFIG_SYS_MALLOC_LEN=0x200
 CONFIG_NR_DRAM_BANKS=8
 CONFIG_ENV_SIZE=0x1000
 CONFIG_DEFAULT_DEVICE_TREE="coreboot"
@@ -8,12 +9,11 @@ CONFIG_VENDOR_COREBOOT=y
 CONFIG_TARGET_COREBOOT=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
+CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
 CONFIG_SHOW_BOOT_PROGRESS=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100"
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_LOG=y
@@ -23,9 +23,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_LAST_STAGE_INIT=y
 CONFIG_PCI_INIT_R=y
 CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PBSIZE=532
-CONFIG_CMD_MEM_SEARCH=y
-CONFIG_CMD_IDE=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
@@ -53,13 +50,8 @@ CONFIG_USE_ROOTPATH=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 # CONFIG_ACPIGEN is not set
-CONFIG_SYS_IDE_MAXDEVICE=4
-CONFIG_SYS_ATA_DATA_OFFSET=0
-CONFIG_SYS_ATA_REG_OFFSET=0
-CONFIG_SYS_ATA_ALT_OFFSET=0
-CONFIG_ATAPI=y
-CONFIG_LBA48=y
-CONFIG_SYS_64BIT_LBA=y
+CONFIG_MISC=y
+CONFIG_NVMEM=y
 CONFIG_NVME_PCI=y
 # CONFIG_PCI_PNP is not set
 CONFIG_SOUND=y
-- 
2.41.0.162.gfafddb0af9-goog



[PATCH v2 19/19] x86: coral: Adjust various config options

2023-06-20 Thread Simon Glass
Add ms so it is easier to search for tables in memory.

Expand the command-line and print buffers so that we can deal with the
very long ChromeOS command lines. (typically 700 characters).

Enable BOOTSTD_FULL to get the full set of standard-boot options.

Replace the existing manual script with 'bootflow scan', since it can
find and boot the OS.

Finally, expand the malloc() space so we can read large kernels into a
bootflow.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop mention of NVMe support

 configs/chromebook_coral_defconfig | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/configs/chromebook_coral_defconfig 
b/configs/chromebook_coral_defconfig
index f5995f22004e..fe61153b93d8 100644
--- a/configs/chromebook_coral_defconfig
+++ b/configs/chromebook_coral_defconfig
@@ -1,5 +1,6 @@
 CONFIG_X86=y
 CONFIG_TEXT_BASE=0x111
+CONFIG_SYS_MALLOC_LEN=0x200
 CONFIG_SYS_MALLOC_F_LEN=0x3d00
 CONFIG_NR_DRAM_BANKS=8
 CONFIG_MAX_CPUS=8
@@ -22,6 +23,7 @@ CONFIG_X86_OFFSET_U_BOOT=0xffd0
 CONFIG_X86_OFFSET_SPL=0xffe8
 CONFIG_INTEL_ACPIGEN=y
 CONFIG_INTEL_GENERIC_WIFI=y
+CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
 CONFIG_CHROMEOS=y
 CONFIG_BOOTSTAGE=y
@@ -33,8 +35,10 @@ CONFIG_BOOTSTAGE_STASH=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS_SUBST=y
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; read mmc 0:2 10 0 
80; setexpr loader *001004f0; setexpr size *00100518; setexpr blocks $size / 
200; read mmc 0:2 10 80 $blocks; setexpr setup $loader - 1000; setexpr 
cmdline_ptr $loader - 2000; setexpr.s cmdline *$cmdline_ptr; setexpr cmdline 
gsub %U ${uuid}; if part uuid mmc 0:2 uuid; then zboot start 10 0 0 0 
$setup cmdline; zboot load; zboot setup; zboot dump; zboot go;fi"
+CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; bootflow scan -lb"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_LOG=y
+CONFIG_LOGF_FUNC=y
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_LAST_STAGE_INIT=y
 CONFIG_BLOBLIST=y
@@ -52,9 +56,11 @@ CONFIG_SPL_POWER=y
 CONFIG_TPL_SYS_MALLOC_SIMPLE=y
 CONFIG_TPL_POWER=y
 CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PBSIZE=532
+CONFIG_SYS_CBSIZE=1024
+CONFIG_SYS_PBSIZE=1024
 CONFIG_CMD_CPU=y
 CONFIG_CMD_PMC=y
+CONFIG_CMD_MEM_SEARCH=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_PART=y
-- 
2.41.0.162.gfafddb0af9-goog



Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran
El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia:
> On 6/19/23 12:12, Xavier Drudis Ferran wrote:
> 
> It seems the email addresses are being constantly corrupted in each email.
> This time the ML address is wrong and missing an e at the end. There is some
> e@ nonexistent address which I have to keep removing.
>

Yes, that's my fault. I'm sorry. I apologize to you and others.  I
resent my mail with the proper address. Please just look for my mail
with the wrong address and delete it from your mail archive to prevent
further such problems. You can reply to the other mail I sent (June
19th), because it has the same content, just with an added
apology. Sorry again.

> > When DISTRO_DEFAULTS is not set, the default environment has
> > bootcmd=bootflow
> 
> That is not right, on $randomboard I picked the bootcmd is something else.
>

And how default is your default environment for your $randomboard ?

Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268)

When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y
and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan"
or (for sandbox) "bootflow scan -lb". When there's bootcmd at all.

But this is only the default for the default environment. It can be
overriden and the Kconfig is not exactly simple. An extract:

next branch:

arch/Arm/Kconfig:

config ARCH_ROCKCHIP
[...]
imply BOOTSTD_DEFAULTS
[...]


cmd/Kconfig:

config CMD_BOOTFLOW
bool "bootflow"
depends on BOOTSTD
default y
[...]

config CMD_BOOTFLOW_FULL
bool "bootflow - extract subcommands"
depends on BOOTSTD_FULL
default y
[...]

boot/Kconfig:

config BOOT_DEFAULTS
bool  # Common defaults for standard boot and distroboot
imply USE_BOOTCOMMAND
[...]

config BOOTSTD
bool "Standard boot support"
default y
[...]

config BOOTSTD_FULL
bool "Enhanced features for standard boot"
default y if SANDBOX
[...]


if BOOTSTD
[...]

config BOOTSTD_DEFAULTS
bool "Select some common defaults for standard boot"
depends on BOOTSTD
imply USE_BOOTCOMMAND
select BOOT_DEFAULTS
select BOOTMETH_DISTRO
[...]

config BOOTSTD_BOOTCOMMAND
bool "Use bootstd to boot"
default y if !DISTRO_DEFAULTS
[...]
[...]
endif
[...]
config DISTRO_DEFAULTS
bool "Select defaults suitable for booting general purpose Linux 
distributions"
select BOOT_DEFAULTS
[...]

config BOOTCOMMAND
string "bootcmd value"
depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE
default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL
default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL
default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS
> 
> Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello'
> for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell
> and run 'usb reset ; usb info' too ?
>

I haven't tested it. If bootflow scan is not run it might not happen.
Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device,
for it to fail. But as far as I know the idea is to make bootflow the
default in more and more cases. You'll always be able to avoid it
running in your board by setting your own environment at runtime or
changing the configuration, yes, but what's the point ?

I thought that failing one scenario was enough to fix things.  When
one finds a bug it tries to help others to reproduce it.  When others
help the bug finder to run other scenarios that don't have the bug,
what's that useful for ?

Note that it won't fail if the boot succeeds, because then you won't
have a shell to run usb info/tree. It won't fail if usb is not in
boot_targets. It won't fail if there's no mass storage device
connected to usb when bootflow scan is run...

But I still think the failing case is worth fixing. Someone may be
wondering why bootflow fails, run usb info and find a reset, when
setting up a new board, or trying to boot from the wrong usb stick
after the system partition has been corrupted, or whatever. It's not
something that breaks any board in production, but it's not something
to leave forever broken. In theory a null pointer dereference might be
used by some attacker, but in this case I don't really see any useful
attack, maybe it's my lack of imagination. So I'm not claiming it's a
severe bug. It's just a normal bug that needs fixing when possible.

Or are you trying to hint that the solution shouldn't be changing
cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan
somehow ?

Or I should change the commit message because the point is not so much
what's the default environment or the default default environment, but
simply that bootflow scan is run with an usb mass storage device
connected and no boot content pres

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop 
executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 
mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in 
host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the PHYs in 
this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will turn 
the whole driver into an unmaintainable mess and make the sync that 
much harder in the future. I spent enormous amount of my spare time 
trying to explain to Xilinx how to do that mostly automatically, but 
that was all ignored or countered with reason after reason why this 
cannot be done, but as far as I can tell, nobody in Xilinx actually 
tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and I 
wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see 
why.


It is not just about dwc3. There are other parts which are ported from 
Linux kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an 
automated manner, but chose to ignore all input and be unhelpful. Too bad.


Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut

On 6/20/23 09:03, Xavier Drudis Ferran wrote:

El Tue, Jun 20, 2023 at 02:50:48AM +0200, Marek Vasut deia:

On 6/13/23 08:52, Xavier Drudis Ferran wrote:


U-Boot TPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47)


Next is already at rc4 , what's this rc2 ?


It's a test I did last week (June 12th). What do you think has changed
in next between rc2 and rc4 so that this shouldn't happen now ?


The beginning of the email states:

"
Ok. New test.

This uses yesterday morning's   next   branch.
commit 5b589e139620214f
"

So, that is not the case ?

Also, commit 497967f1ee does not exist in upstream U-Boot, was this some 
patched U-Boot tree ?



My last patch (sent yesterday) was tested with the next branch as of
yesterday morning. But you can test it yourself with any version you like.
Do I have to send the logs of each test I do to the list every time ?


Ideally the claims you make about what you tested and logs from the test 
should match, that would be a good starting point.



I thought Simon Glass reply last week to the mail you quoted already
showed agreement that the issue exists, and the adding of the
UCLASS_BOOTDEV device is per design, so cmd/usb.c needs fixing to deal
with this change.


I am not disputing that. What bothers me is the still missing consistent 
test case, esp. if this is a fix which should be added this late in release.


Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek




On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host mode,
+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I 
noticed that you removed the code that resets the PHYs in this patch hence 
DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in the 
future. I spent enormous amount of my spare time trying to explain to Xilinx 
how to do that mostly automatically, but that was all ignored or countered 
with reason after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start unless 
I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from Linux 
kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an 
automated manner, but chose to ignore all input and be unhelpful. Too bad.


It is not

Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut

On 6/20/23 11:17, Xavier Drudis Ferran wrote:

El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia:

On 6/19/23 12:12, Xavier Drudis Ferran wrote:

It seems the email addresses are being constantly corrupted in each email.
This time the ML address is wrong and missing an e at the end. There is some
e@ nonexistent address which I have to keep removing.



Yes, that's my fault. I'm sorry. I apologize to you and others.  I
resent my mail with the proper address. Please just look for my mail
with the wrong address and delete it from your mail archive to prevent
further such problems. You can reply to the other mail I sent (June
19th), because it has the same content, just with an added
apology. Sorry again.


That's fine


When DISTRO_DEFAULTS is not set, the default environment has
bootcmd=bootflow


That is not right, on $randomboard I picked the bootcmd is something else.



And how default is your default environment for your $randomboard ?


Default, see:
$ git grep CONFIG_BOOTCOMMAND configs/


Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268)

When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y
and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan"
or (for sandbox) "bootflow scan -lb". When there's bootcmd at all.

But this is only the default for the default environment. It can be
overriden and the Kconfig is not exactly simple. An extract:

next branch:

arch/Arm/Kconfig:

config ARCH_ROCKCHIP
[...]
imply BOOTSTD_DEFAULTS
[...]


cmd/Kconfig:

config CMD_BOOTFLOW
 bool "bootflow"
 depends on BOOTSTD
 default y
[...]

config CMD_BOOTFLOW_FULL
 bool "bootflow - extract subcommands"
 depends on BOOTSTD_FULL
 default y
[...]

boot/Kconfig:

config BOOT_DEFAULTS
 bool  # Common defaults for standard boot and distroboot
 imply USE_BOOTCOMMAND
[...]

config BOOTSTD
 bool "Standard boot support"
 default y
[...]

config BOOTSTD_FULL
 bool "Enhanced features for standard boot"
 default y if SANDBOX
 [...]


if BOOTSTD
[...]

config BOOTSTD_DEFAULTS
 bool "Select some common defaults for standard boot"
 depends on BOOTSTD
 imply USE_BOOTCOMMAND
 select BOOT_DEFAULTS
 select BOOTMETH_DISTRO
[...]

config BOOTSTD_BOOTCOMMAND
 bool "Use bootstd to boot"
 default y if !DISTRO_DEFAULTS
[...]
[...]
endif
[...]
config DISTRO_DEFAULTS
 bool "Select defaults suitable for booting general purpose Linux 
distributions"
 select BOOT_DEFAULTS
[...]

config BOOTCOMMAND
 string "bootcmd value"
 depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE
 default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL
 default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL
 default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS


Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello'
for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell
and run 'usb reset ; usb info' too ?



I haven't tested it. If bootflow scan is not run it might not happen.


So, what is the minimal test case ?
I have been asking for that for a while.


Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device,
for it to fail. But as far as I know the idea is to make bootflow the
default in more and more cases. You'll always be able to avoid it
running in your board by setting your own environment at runtime or
changing the configuration, yes, but what's the point ?

I thought that failing one scenario was enough to fix things.  When
one finds a bug it tries to help others to reproduce it.  When others
help the bug finder to run other scenarios that don't have the bug,
what's that useful for ?

Note that it won't fail if the boot succeeds, because then you won't
have a shell to run usb info/tree. It won't fail if usb is not in
boot_targets. It won't fail if there's no mass storage device
connected to usb when bootflow scan is run...

But I still think the failing case is worth fixing. Someone may be
wondering why bootflow fails, run usb info and find a reset, when
setting up a new board, or trying to boot from the wrong usb stick
after the system partition has been corrupted, or whatever. It's not
something that breaks any board in production, but it's not something
to leave forever broken. In theory a null pointer dereference might be
used by some attacker, but in this case I don't really see any useful
attack, maybe it's my lack of imagination. So I'm not claiming it's a
severe bug. It's just a normal bug that needs fixing when possible.

Or are you trying to hint that the solution shouldn't be changing
cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan
somehow ?


I would really like a minimal test case.

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop 
executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to 
detect the

USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, 
u32 mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in 
host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the PHYs 
in this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will 
turn the whole driver into an unmaintainable mess and make the sync 
that much harder in the future. I spent enormous amount of my spare 
time trying to explain to Xilinx how to do that mostly 
automatically, but that was all ignored or countered with reason 
after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and I 
wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly 
start unless I add some manual delays here and there, and I am 
trying to see why.


It is not just about dwc3. There are other parts which are ported 
from Linux kernel and are out of sync from Linux kernel for quite a 
long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in 
an automated manner, but chose to 

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Simon Glass
Hi Xavier,

On Wed, 14 Jun 2023 at 09:40, Xavier Drudis Ferran  wrote:
>
>
> Thanks for explaining, Simon Glass.
>
> Can someone please stop me if I'm splitting hairs or bikeshedding or
> something ? I guess we agree both checking for null or UCLASS_BOOTDEV
> would work right now but we are looking for what's more future-proof.
>
> El Tue, Jun 13, 2023 at 09:12:30PM +0100, Simon Glass deia:
> > Hi Xavier,
> >
> > On Tue, 13 Jun 2023 at 17:04, Xavier Drudis Ferran  
> > wrote:
> > >
> > > El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia:
> > > >
> > > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices.
> > >
> > > That's a possibility, yes. It should work until someone adds another
> > > device there for some other purpose.
> > >
> > > > That is better than checking for the NULL pointer.
> > > >
> > >
> > > Why? What's wrong about checking for null ?
> > > Or maybe checking for both not null and  not UCLASS_BOOTDEV ?
> > >
> > > Not that I care too much, just to understand your reasoning.
> >
> > Well, devices may have something attached there, so it may be
> > non-NULL, but point to a different struct from the expected one.
> >
>
> Yes. That is possible. How likely ?
>
> That "there" is dev_get_parent_priv(). If I understand the driver
> model, those devices shouldn't put things there themselves, it should
> be their parent who puts stuff there for them. And the parent should
> be an usb_device->dev (because of the recursive code). So what other
> struct would such a parent put in a child parent_priv_ ? Yes, whatever
> it wants, but I mean, isn't it likely to assume the child would be
> "adopted" with null as parent_priv_ or a "natural child" with a usb_device
> in parent_priv_ ?
>
> I did a very rough search
>
> grep -rIE 'UCLASS_(BLK|BOOTDEV|USB_EMUL)' . |grep -F .id |cut -f1 -d:  |xargs 
> -n 1 grep -l per_child_auto
> ./drivers/usb/emul/usb-emul-uclass.c
>
> Which seems to suggest only UCLASS_USB_EMUL would have parent_priv_,
> and that would be an usb_device, which the current code does not want
> to recurse anyway. (dev_set_parent_priv() is almost never called).
>
> It is also possible that one day a device that is not UCLASS_BLK,
> UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> device (just imagine a future system similar to bootstd for firmware
> updates, trust material, etc.). Is it likely to have a struct in
> parent_priv_ that is not a usb_device ?
>
> So which is more likely to survive future changes ?
>
> - checking for parent_priv_ not null and not UCLASS_USB_EMUL
>
> - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> UCLASS_BLK
>   (my patch, overcautious ?)
>
> - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
>   (Simon Glass' idea)
>
> - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not UCLASS_USB_EMUL
>and parent_priv_ not null

Really the parent_priv thing is a separate issue, a side effect of
something having a UCLASS_USB parent.

The key point here is that we cannot iterate down into a bootdev
device looking for USB devices. So we should use that as the check,
since it is the most direct check.

>
> > >
> > > Or can we check for recursible devices somehow ?
> > > Maybe flag them or something ?
> > >
> > > Why is better to state all devices are recursible except some UCLASSes
> > > (meaning they can have stuff that needs listed in usb info - or
> > > likewise usb tree -) instead of stating that some closed set are
> > > recursible ?
> > >
> >
> > For USB we can have lots of different types of devices as children, so
> > it would be a pain to enumerate them all. At least that's how I see
> > it.
> >
>
> We can have lots of devices as children, but those do get listed
> before the recursive call.  How many of those can have children that
> we have to list too, i.e.  how many of those do we want to recurse
> into ?
>
> I can only think of usb hubs (maybe some node for multifunction
> devices too ???).  Maybe I'm not understanding how U-Boot works with
> USB devices... but it looks like it would be enough to look for
> UCLASS_USB_HUB, then recursive call, else no recursion. I mean instead of
>
> cmd/usb.c : usb_show_tree_graph() :
>
> if ((device_get_uclass_id(  child  ) != UCLASS_USB_EMUL) &&
> (device_get_uclass_id(  child  ) != UCLASS_BOOTDEV) &&
> (device_get_uclass_id(  child  ) != UCLASS_BLK)) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
>
> we could simply have
>
> if (device_get_uclass_id(  dev->dev  ) == UCLASS_USB_HUB) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
>
> (or put the condition directly before the for loop)
>
> Or can we have an UCLASS_USB_EMUL, UCLASS_BLK or UCLASS_BOOTDEV as
> direct child of an UCLASS_USB_HUB ???
>
> Am I opening any cans of worms ?

>From my mem

Re: [PATCH] axi: fix a warning

2023-06-20 Thread Simon Glass
On Mon, 19 Jun 2023 at 21:36, Sergei Antonov  wrote:
>
> Fix an enum/integer mismatch encountered in 'sandbox_defconfig' build.
>
> .../u-boot/drivers/axi/axi-emul-uclass.c:16:5: warning: conflicting types for 
> ‘axi_sandbox_get_emul’ due to enum/integer mismatch; have ‘int(struct udevice 
> *, ulong,  enum axi_size_t,  struct udevice **)’ {aka ‘int(struct udevice *, 
> long unsigned int,  enum axi_size_t,  struct udevice **)’} 
> [-Wenum-int-mismatch]
>16 | int axi_sandbox_get_emul(struct udevice *bus, ulong address,
>   | ^~~~
> In file included from .../u-boot/drivers/axi/axi-emul-uclass.c:14:
> .../u-boot/arch/sandbox/include/asm/axi.h:48:5: note: previous declaration of 
> ‘axi_sandbox_get_emul’ with type ‘int(struct udevice *, ulong,  uint,  struct 
> udevice **)’ {aka ‘int(struct udevice *, long unsigned int,  unsigned int,  
> struct udevice **)’}
>48 | int axi_sandbox_get_emul(struct udevice *bus, ulong address, uint 
> length,
>   | ^~~~
>
> Make function declaration match function definition.
>
> Cc: Mario Six 
> Signed-off-by: Sergei Antonov 
> ---
>  arch/sandbox/include/asm/axi.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 


Re: [BUG] bind command leads to invalid state where plaform data is NULL

2023-06-20 Thread Simon Glass
Hi Heinrich,

On Mon, 19 Jun 2023 at 18:51, Heinrich Schuchardt  wrote:
>
> On 6/19/23 14:57, Simon Glass wrote:
> > I suggest a simple device that needs no setup. The original commit[1]
> > suggests using USB - does that worK?
> >
> > Regards,
> > Simon
> >
> > [1] 49c752c93a78 ("cmd: Add bind/unbind commands to bind a device to a
> > driver from the command line")
>
> I see devices listed after bind but I do not see any device that could
> be used after binding it with the bind command.

It might be worth asking the author. If there is any
parent/uclass/device priv/plat then it won't be set up by this
command.

>
> Here is another instance where using the bind command leads to a crash
> (on pine64-lts_defconfig).
>
> Another question:
> Is it correct that two devices have the same name?

It shouldn't cause any problems since we don't normally reference
devices by name. But it could be confusing for the user if there are
two children of the same device with the same name.

>
> => dm tree
>   Class Index  Probed  Driver  Name
> --
>   watchdog  0  [ + ]   sunxi_wdt   |   |-- watchdog@1c20ca0
>   sysreset  0  [   ]   wdt_reboot  |   |   `-- watchdog@1c20ca0
> => unbind sysreset 0
> => bind watchdog 0 wdt_reboot
> => reset
> resetting ...
> "Synchronous Abort" handler, esr 0x9604, far 0xea06ea70
> elr: 4a044054 lr : 4a034c94 (reloc)
> elr: bdf8d054 lr : bdf7dc94
> x0 :  x1 : 
> x2 : bdf7dc6c x3 : ea06ea08
> x4 : b9f1ec78 x5 : b9f2cbd0
> x6 : 0072 x7 : b9f1ed30
> x8 : 0040 x9 : fff0
> x10: 0006 x11: 0001869f
> x12: b9f1eec8 x13: b9f1efd0
> x14:  x15: b9f1e79f
> x16: bdf7dc6c x17: 
> x18: b9f28d90 x19: 0001
> x20: 0001 x21: 
> x22: b9f38680 x23: 0001
> x24: bdff4f54 x25: 
> x26: b9f2d2d0 x27: 
> x28:  x29: b9f1ecd0
>
> Code: a8c27bfd d65f03c0 d65f03c0 f943 (f9403463)
>
> The crash is in do_reset().

Looking at the device, it needs plat data and uses it in
wdt_reboot_of_to_plat().

Regards,
Simon


Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Ilias Apalodimas
Sorry for being late to the party,

+cc Jose who maintains DEN0118

On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:
> Hi Michal,
>
> On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:
> >
> > Hi Jassi,
> >
> > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:
> > > From: Jassi Brar 
> > >
> > > Introduce support for mtd backed storage for FWU feature and enable it on
> > > Synquacer platform based DeveloperBox.
> > >
> > > This revision is rebased onto patchset that trims the FWU api
> > >   
> > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/
> > >
> .
>
> > Firstly I can generate 2 images per one bank which should be pretty much 
> > regular
> > capsule update for 2 images. I would expect this should still work.
> >
> > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() 
> > generated
> > this description for DFU
> >
> > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw
> > 23a 400;bank1 raw 282 400
> >
> > If you look at size in second entry you will see that it is 8000 instead of
> > 8 because it is the same image. That's why curious if you have tested 
> > any
> > scenario like this.
> >
> I had, and have, strong doubts about the practicality of 2
> images/bank. There aren't enough specification details to explain how
> only 1-out-of-N images could be updated. And if we always update all
> images in a bank together, we might as well have them as one composite
> image. I never got satisfactory clarification from designers and
> implementers. So, sorry, I can't defend that scenario with my limited
> knowledge.

This is intentionally left out, as we consider it a platform policy.
For example you could update a single bank and copy over the remaining
firmware images from a different ban. There's nothing on the spec that
prohibits you from doing so, but I personally think it's a bad idea.
Keep in mind there's a document hosted here[0] which explains the update
flow and documents what we have as code in U-Boot.

As far as individual firmware components go now,  do you have any useful
usecase?  The general guidance of [0] is construct a firmware
image, only update the components you want while leaving the rest on the
same revisions and update the entire firmware.  The reason is that firmware

Updating a single image of another bank is not as easy as it sounds.
Firmware components nowadays, whether we like it or not, depend on each other.
Since firmware updates are not so often and fast,  we didn't see any gains from
over complicating the spec and explicitly describe that case, while dealing
with firmware component compatibility at the same time.

>
> > Next part which I want to take a look is practicality of 
> > CONFIG_FWU_NUM_BANKS
> > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number 
> > of
> > banks and images for every platform and prevent creating one u-boot which 
> > works
> > on different boards and just use information from mdata.
> > DEN0118 doesn't show any field with this information but do you think that 
> > would
> > be possible to extract that information from there based on for example 
> > reserved
> > or accepted field?
> >
> Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
> 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
> use any bit, we'll be in violation of the spec.

Yes this is unfortunate.  We did have similar concerns on when drafting the
spec,  however we never had a solid usecase to justify this.  Arm and
Linaro and working on a v2 (which we try to make compatible with v1) which
addresses this shortcoming.  Maybe Jose can chime in.

>
> However, we can do CRC32 calculations by varying NUM_IMAGES_PER_BANK
> and NUM_BANKS and find the value pair for which the crc32 field
> matches!
> For limiting check-loops and finding corrupted metadata, the .config
> can carry upper limits on both the options, say
> MAX_NUM_IMAGES_PER_BANK=5 and MAX_NUM_BANKS=10 for the most special
> scenario. If we find the approach acceptable, I can cook a patch as
> proof-of-concept.
>
> cheers.

[0] 
https://gitlab.com/Linaro/trustedsubstrate/mbfw/uploads/3d0d7d11ca9874dc9115616b418aa330/mbfw.pdf

Thanks
/Ilias


Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass
Hi Jan,

On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
>
> On 19.06.23 16:09, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 14:36, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
> 
>  On 15.06.23 13:46, Jan Kiszka wrote:
> > On 15.06.23 13:38, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 13:19, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
>  wrote:
> >
> > On 15.06.23 12:55, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 12.06.23 23:17, Simon Glass wrote:
>  Hi Jan,
> 
>  On Mon, 5 Jun 2023 at 15:39, Jan Kiszka  
>  wrote:
> >
> > From: Jan Kiszka 
> >
> > Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to 
> > inject
> > specific settings. Will be used by IOT2050 first to define 
> > multiple
> > of-lists.
> >
> > Signed-off-by: Jan Kiszka 
> > ---
> > CC: Simon Glass 
> > ---
> >  Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> 
>  I'm really not keen on this, since it means that the Makefile 
>  (or some
>  vars it sets) are again involved in controlling the image 
>  generation.
>  It should really all be in the binman image description / .dtsi 
>  file
> >>>
> >>> binman does not allow me to unrole of-list inside the dts file, 
> >>> does it?
> >>> With such a feature, I wouldn't need any custom -a of-list-X 
> >>> switches
> >>> and, thus, no such EXTRA_ARGS.
> >>
> >> Can you explain a bit more about what you mean by 'unrole'? It is 
> >> just
> >> software, so anything should be possible.
> >
> > To use a DT sequence, I need to specify fit,ftd-list. But I can say
> >
> > fit,ftd-list = "first.dtb second.dtb"
> >
> > I rather need to go via the EntryArg indirection of the binman 
> > command line.
> 
>  Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>  wanting to filter that list based on something else?
> 
>  I'm afraid I am really not following this at all.
> >>>
> >>> CONFIG_OF_LIST is not working here as we have two different boards 
> >>> with
> >>> two different lists.
> >>
> >> But we only build one board at a time, don't we?
> >
> > No, this is about building two flash images for two different board
> > generations in the same binman run (see patch 3).
> >
> >>
> >> We could provide a way to select between different lists, but how does
> >> Makefile get access to them?
> >
> > See patch 3: known lists, now put into board config.mk.
> >
> 
>  Any better suggestions for this issue? Otherwise, I will have to keep
>  binman args extension for now.
> >>>
> >>> I've dug into this a bit. The use of #defines and macros looks to be
> >>> unnecessary, unless I am missing something.
> >>>
> >>> You can do things like this:
> >>>
> >>> fit_node: fit {
> >>> // base definition of FIT
> >>> };
> >>>
> >>> the later on:
> >>>
> >>> fit_node: {
> >>> #ifdef xxx
> >>>// override a few things
> >>>fit,fdt-list = ...
> >>> #else
> >>>
> >>> #endif
> >>
> >> As I wrote already, I have a solution for that by using a template dtsi.
> >>
> >>>
> >>> There is no need to specify the properties all at once. You can update
> >>> a property later on just by referring to its node as above.
> >>
> >> Does not help when the anchor name needs to vary as well. That's where I
> >> will use a #define to customize the template on include.
> >>
> >>>
> >>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> >>> and all the #define stuff.
> >>
> >> You still didn't address my question. Should I share my version to make
> >> the problem clearer? But I thought I explained this in various shades
> >> already.
> >
> > Yes, if I am looking at the wrong patches, please point me to the
> > correct series, or push a tree somewhere.
> >
>
> Please have a look at
> https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e

OK that looks a lot better to me. We can go with that until we come up
with something better.

There has been a long-standing request to support common parts of images.

I am thinking something like this:

common_part: common-part {
template;   // indic

Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits

2023-06-20 Thread Simon Glass
Hi Tom, Pali,

On Wed, 14 Jun 2023 at 20:51, Tom Rini  wrote:
>
> On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote:
>
> > These 3 commits broke support for U-Boot Bootmenu on Nokia N900.
> > Issues were reported more than month ago, but nobody reacted to them.
> > So revert these broken commits for now, to fix U-Boot Bootmenu support.
> >
> > With these revered commits, U-Boot Bootmenu from master branch is
> > working fine again on Nokia N900.
> >
> > Pali Rohár (3):
> >   Revert "video: Enable VIDEO_ANSI by default only with EFI"
> >   Revert "menu: Factor out menu-keypress decoding"
> >   Revert "menu: Make use of CLI character processing"
> >
> >  cmd/bootmenu.c|   9 ++--
> >  cmd/eficonfig.c   |  12 ++---
> >  common/cli_getch.c|  12 ++---
> >  common/menu.c | 122 ++
> >  drivers/video/Kconfig |   7 +--
> >  include/cli.h |   4 +-
> >  include/menu.h|  17 +-
> >  7 files changed, 91 insertions(+), 92 deletions(-)
>
> Following up over here, while
> https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/
> addresses some of the issues, but not all (as it clearly isn't working
> in all of the cases Pali has explained), looking in to the VIDEO_ANSI
> part of this too, all three of these reverts are related seemingly to
> something escape-character related.  I'm not taking any of the revert
> commits in just yet, but will by the next -rc if we don't have something
> that fixes all of the issues.

I did send a series [1] with a fix for the nokia_rx51 keyboard driver,
including the previous ansi-code patch. Given that:

- this problem doesn't seem to manifest on other boards
- it does not cause any CI test to fail
- there seem to be bugs in the nokia_rx51 implementation which are a
possible/likely cause
- the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU
- the problem goes away if debugging is added, suggesting it is
related to timing

...I don't think a revert is appropriate.

Pali, can you please take a look and see if you can debug what is
actually going on? Here is my guess:

1. When an arrow key is pressed, cli_ch_process() handles it by being
passed the codes in sequence: \e [ B
2. Calling cli_ch_process() with ichar = 0 causes it to think the
sequence is finished: \e [ \0 B   (this doesn't work since the \0 ends
the sequence)
3. nokia_rx51 keyboard driver is returning '\0' even when key codes
are pending, causing cli_ch_process() to be told that the sequence is
done

It would help to move the keyboard driver into drivers/input/ so it is
easier to find.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=360134


Re: [PATCH] mkimage: Use PATH_MAX for path length

2023-06-20 Thread Simon Glass
On Mon, 19 Jun 2023 at 17:25,  wrote:
>
> From: Mingli Yu 
>
> Fixed when build xilinx_zynqmp in long directory ( >256):
>   |  
> /buildarea1/testtest/wr_build/wr1023test_secureboot/test1-what/test2-what/test3-what/test4-what/test5-what/test6-what/test7-what/test8-what/test9-what/test10-what/test11-what/test12-what/build/tmp-glibc/work/xilinx_zynqmp-wrs-linux/u-boot-xlnx/1_v2023.01-xilinx-v2023.1+gitAUTOINC+40a08d69e7-r0/build/fitImage-linux:
>  Image file name (uboot-mkimage) too long, can't create tmpfile.
>   | Error: Bad parameters for FIT image type
>
> Signed-off-by: Mingli Yu 
> ---
>  tools/mkimage.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v13 03/10] lib: uuid: introduce testcase for uuid_str_to_le_bin

2023-06-20 Thread Simon Glass
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> provide a test case
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Simon Glass 
>
> ---
>
> Changelog:
> ===
>
> v11:
>
> * use ut_asserteq_mem()
>
>  MAINTAINERS   |  5 +
>  test/lib/Makefile |  1 +
>  test/lib/uuid.c   | 41 +
>  3 files changed, 47 insertions(+)
>  create mode 100644 test/lib/uuid.c
>

Reviewed-by: Simon Glass 


Re: [PATCH v13 04/10] arm_ffa: introduce Arm FF-A support

2023-06-20 Thread Simon Glass
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
>
> The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
>
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
>
> The driver uses SMC32 calling convention which means using the first
> 32-bit data of the Xn registers.
>
> All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
> which has 64-bit version supported.
>
> Both 32-bit and 64-bit direct messaging are supported which allows both
> 32-bit and 64-bit clients to use the FF-A bus.
>
> FF-A is a discoverable bus and similar to architecture features.
> FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
> by the PSCI driver.
>
> Clients are able to probe then use the FF-A bus by calling the DM class
> searching APIs (e.g: uclass_first_device).
>
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
>
> The driver exports its operations to be used by upper layers.
>
> Exported operations:
>
> - ffa_partition_info_get
> - ffa_sync_send_receive
> - ffa_rxtx_unmap
>
> Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
> Arm specific methods are implemented in the Arm driver (arm-ffa.c).
>
> For more details please refer to the driver documentation [2].
>
> [1]: https://developer.arm.com/documentation/den0077/latest/
> [2]: doc/arch/arm64.ffa.rst
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> Cc: Heinrich Schuchardt 
>
> ---
>
> Changelog:
> ===
>
> v13:
>
> * doc minor change: specify in the readme that the user
>should call ffa_rxtx_unmap() driver operation to unmap
>the RX/TX buffers on demand.
>
> v12:
>
> * remove dscvry_info
> * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn
>(user drivers can override it)
> * improve FFA_PARTITION_INFO_GET implementation
>(clients no longer need to calloc a buffer)
> * address nits
>
> v11:
>
> * move ffa_try_discovery() from the uclass to the Arm FF-A driver
> * rename ffa_try_discovery() to arm_ffa_discover()
> * pass dev as an argument of arm_ffa_discover()
> * add arm_ prefix to the Arm FF-A driver functions
> * add emul field in struct ffa_discovery_info
> * address nits
>
> v10:
>
> * provide the driver operations through the Uclass
> * move the generic FF-A methods to the Uclass
> * keep Arm specific methods in the Arm driver (arm-ffa.c)
> * rename core.c to arm-ffa.c
> * address nits
>
> v9:
>
> * integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for 
> binding
>
> v8:
>
> * make ffa_get_partitions_info() second argument to be an SP count in both
>   modes
> * update ffa_bus_prvdata_get() to return a pointer rather than a pointer
>   address
> * remove packing from ffa_partition_info and ffa_send_direct_data structures
> * pass the FF-A bus device to the bus operations
>
> v7:
>
> * add support for 32-bit direct messaging
> * rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
> * improve the declaration of error handling mapping
> * stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
>
> v6:
>
> * drop use of EFI runtime support (We decided with Linaro to add this later)
> * drop discovery from initcalls (discovery will be on demand by FF-A users)
> * set the alignment of the RX/TX buffers to the larger translation granule 
> size
> * move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
> * update the documentation and move it to doc/arch/arm64.ffa.rst
>
> v4:
>
> * add doc/README.ffa.drv
> * moving the FF-A driver work to drivers/firmware/arm-ffa
> * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
>   #if defined by #if CONFIG_IS_ENABLED
> * improving error handling by mapping the FF-A errors to standard errors
>   and logs
> * replacing panics with an error log and returning an error code
> * improving features discovery in FFA_FEATURES by introducing
>   rxtx_min_pages private data field
> * add ffa_remove and ffa_unbind functions
> * improve how the driver behaves when bus discovery is done more than
>   once
>
> v3:
>
> * align the interfaces of the U-Boot FF-A driver with those in the linux
>   FF-A driver
> * remove the FF-A helper layer
> * make the U-Boot FF-A driver independent from EFI
> * provide an optional config that enables copying the driver data to EFI
>   runtime section at ExitBootServices service
> * use 64-bit version 

Re: [PATCH v13 09/10] arm_ffa: efi: introduce FF-A MM communication

2023-06-20 Thread Simon Glass
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Add MM communication support using FF-A transport
>
> This feature allows accessing MM partitions services through
> EFI MM communication protocol. MM partitions such as StandAlonneMM
> or smm-gateway secure partitions which reside in secure world.
>
> An MM shared buffer and a door bell event are used to exchange
> the data.
>
> The data is used by EFI services such as GetVariable()/SetVariable()
> and copied from the communication buffer to the MM shared buffer.
>
> The secure partition is notified about availability of data in the
> MM shared buffer by an FF-A message (door bell).
>
> On such event, MM SP can read the data and updates the MM shared
> buffer with the response data.
>
> The response data is copied back to the communication buffer and
> consumed by the EFI subsystem.
>
> MM communication protocol supports FF-A 64-bit direct messaging.
>
> Signed-off-by: Abdellatif El Khlifi 
> Signed-off-by: Gowtham Suresh Kumar 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
>
> ---
>
> Changelog:
> ===
>
> v13:
>
> * remove FF-A and Optee ifdefs
>
> v12:
>
> * drop use of calloc when querying SPs
> * address nits
>
> v11:
>
> * rename select_ffa_mm_comms() to select_mm_comms()
> * improve the logic of MM transport selection in mm_communicate()
> * addressing nits
>
> v10:
>
> * use the FF-A driver Uclass operations
> * use uclass_first_device()
> * addressing nits
>
> v9: align how FF-A is used with FF-A discovery through DM
>
> v8:
>
> * isolate the compilation choices between FF-A and OP-TEE
> * update partition_info_get() second argument to be an SP count
> * pass NULL device pointer to the FF-A bus discovery and operations
>
> v7:
>
> * set the MM door bell event to use 64-bit direct messaging
> * issue a compile time error when one of these macros are not found :
>   FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, 
> FFA_SHARED_MM_BUFFER_ADDR
> * make mm_sp_svc_uuid static
> * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails
> * improve use of unmap_sysmem() in ffa_mm_communicate()
>
> v6:
>
> * add FF-A runtime discovery at MM communication level
> * drop EFI runtime support for FF-A MM communication
> * revert the changes in include/mm_communication.h for
>   efi_mm_communicate_header and smm_variable_access structures
>
> v4:
>
> * use the new FF-A driver interfaces
> * discover MM partitions at runtime
> * copy FF-A driver private data to EFI runtime section at
>   ExitBootServices()
> * drop use of FFA_ERR_STAT_SUCCESS error code
> * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES
>   in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore
> * revert the error log in mm_communicate() in case of failure
> * remove packed attribute from efi_mm_communicate_header and
>   smm_variable_communicate_header
>
> v2:
>
> * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, 
> FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings
>
> v1:
>
> * introduce FF-A MM communication
>
>  include/mm_communication.h|  13 ++
>  lib/efi_loader/Kconfig|  16 +-
>  lib/efi_loader/efi_variable_tee.c | 260 +-
>  3 files changed, 282 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v13 05/10] arm_ffa: introduce armffa command

2023-06-20 Thread Simon Glass
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Provide armffa command showcasing the use of the U-Boot FF-A support
>
> armffa is a command showcasing how to invoke FF-A operations.
> This provides a guidance to the client developers on how to
> call the FF-A bus interfaces. The command also allows to gather secure
> partitions information and ping these  partitions. The command is also
> helpful in testing the communication with secure partitions.
>
> For more details please refer to the command documentation [1].
>
> [1]: doc/usage/cmd/armffa.rst
>
> Signed-off-by: Abdellatif El Khlifi 
> Reviewed-by: Simon Glass 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> Cc: Heinrich Schuchardt 
>
> ---
>
> Changelog:
> ===
>
> v12:
>
> * add subcommands argument checks
> * usage documentation: update command return codes
> * remove calloc when querying SPs
> * address nits
>
> v11:
>
> * use U_BOOT_CMD_WITH_SUBCMDS
> * address nits
>
> v10:
>
> * use the FF-A driver Uclass operations
> * use uclass_first_device()
> * address nits
>
> v9:
>
> * remove manual FF-A discovery and use DM
> * use DM class APIs to probe and interact with the FF-A bus
> * add doc/usage/cmd/armffa.rst
>
> v8:
>
> * update partition_info_get() second argument to be an SP count
> * pass NULL device pointer to the FF-A bus discovery and operations
>
> v7:
>
> * adapt do_ffa_dev_list() following the recent update on
>   uclass_first_device/uclass_next_device functions (they return void now)
> * set armffa command to use 64-bit direct messaging
>
> v4:
>
> * remove pattern data in do_ffa_msg_send_direct_req
>
> v3:
>
> * use the new driver interfaces (partition_info_get, sync_send_receive)
>   in armffa command
>
> v2:
>
> * replace use of ffa_helper_init_device function by
>  ffa_helper_bus_discover
>
> v1:
>
> * introduce armffa command
>
>  MAINTAINERS  |   2 +
>  cmd/Kconfig  |  10 ++
>  cmd/Makefile |   1 +
>  cmd/armffa.c | 196 +++
>  doc/arch/arm64.ffa.rst   |   7 ++
>  doc/usage/cmd/armffa.rst |  93 +++
>  doc/usage/index.rst  |   1 +
>  drivers/firmware/arm-ffa/Kconfig |   1 +
>  8 files changed, 311 insertions(+)
>  create mode 100644 cmd/armffa.c
>  create mode 100644 doc/usage/cmd/armffa.rst
>

Reviewed-by: Simon Glass 


Re: [PATCH] board_f: Relocate fdt if SKIP_RELOC and fdt is in bss

2023-06-20 Thread Kunihiko Hayashi

Hi Simon,

On 2023/06/19 21:36, Simon Glass wrote:

Hi Kunihiko,

On Fri, 16 Jun 2023 at 00:59, Kunihiko Hayashi
 wrote:


Hi Simon,

Thank you for your comment.

On 2023/06/13 6:17, Simon Glass wrote:

Hi Kunihiko,

On Thu, 8 Jun 2023 at 07:53, Kunihiko Hayashi
 wrote:


There are cases that the devicetree blob is placed after _end, such as
fdt_find_separate() returns _end. This is in bss area cleared before
relocation.

When GD_FLG_SKIP_RELOC is set, the blob is still in bss, but will be
cleared. As a result, the devicetree become invalid.

To avoid this issue, should relocate it to the new fdt area using the
latter condition in reloc_fdt().

Signed-off-by: Kunihiko Hayashi 
---
   common/board_f.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 51d2f3c365e9..9a245872d190 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -622,7 +622,8 @@ static int init_post(void)
   static int reloc_fdt(void)
   {
  if (!IS_ENABLED(CONFIG_OF_EMBED)) {
-   if (gd->flags & GD_FLG_SKIP_RELOC)
+   if (gd->flags & GD_FLG_SKIP_RELOC &&
+   gd->fdt_blob != &_end)


!IS_ENABLED(CONFIG_OF_EMBED)  == IS_ENABLED(CONFIG_OF_SEPARATE)

reloc_fdt() is only called by U-Boot (not SP)

So the FDT was found by fdt_find_separate() and gd->fdt_blob == &_end

So, is there any case where:

gd->flags & GD_FLG_SKIP_RELO is true
gd->fdt_blob != &_end is true

?


Yes. But in fact,
if (gd->flags & GD_FLG_SKIP_RELOC is true) and (gd->fdt_blob overlaps .bss
section),
the fdt should be relocated because clear_bss() will clear the fdt after
that.


I misstated my point. I am wondering if  gd(->fdt_blob != &_end) is
ever false? If not, then we can always relocate.


When CONFIG_OF_SEPARATE is true, it seems that (gd->fdt_blob != &_end) is
always false because the fdt file is concatinated to the end of the image file
in Makefile.




I can't think of one.

If that is the case, then you could add a comment to this effect and
unconditionally relocate if !CONFIG_OF_EMBED.


I'm not sure if it is possible to unconditionally relocate the fdt,
I think we need to know if the fdt overlaps .bss section.


What is the down-side of always relocating, and when would the fdt not
overlap the .bss section?


The fdt always overlaps the .bss section, so it should be relocated
even if (gd->flags & GL_FLG_SKIP_RELOC) is true.


Note that OF_EMBED is not to be used in production boards. That is
violated by a few things at present, but IMO always relocating should
be safe.


Yes, I undestand.
I delete the condition in v2, and change to always relocate the fdt
in case of !OF_EMBED.

Thank you,

---
Best Regards
Kunihiko Hayashi


Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Jan Kiszka
On 20.06.23 12:11, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
>>
>> On 19.06.23 16:09, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:

 On 19.06.23 14:36, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
>>
>> On 15.06.23 13:46, Jan Kiszka wrote:
>>> On 15.06.23 13:38, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
 wrote:
>
> On 15.06.23 13:19, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
>> wrote:
>>>
>>> On 15.06.23 12:55, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 11:26, Jan Kiszka  
 wrote:
>
> On 12.06.23 23:17, Simon Glass wrote:
>> Hi Jan,
>>
>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka  
>> wrote:
>>>
>>> From: Jan Kiszka 
>>>
>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to 
>>> inject
>>> specific settings. Will be used by IOT2050 first to define 
>>> multiple
>>> of-lists.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> ---
>>> CC: Simon Glass 
>>> ---
>>>  Makefile | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> I'm really not keen on this, since it means that the Makefile 
>> (or some
>> vars it sets) are again involved in controlling the image 
>> generation.
>> It should really all be in the binman image description / .dtsi 
>> file
>
> binman does not allow me to unrole of-list inside the dts file, 
> does it?
> With such a feature, I wouldn't need any custom -a of-list-X 
> switches
> and, thus, no such EXTRA_ARGS.

 Can you explain a bit more about what you mean by 'unrole'? It is 
 just
 software, so anything should be possible.
>>>
>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say
>>>
>>> fit,ftd-list = "first.dtb second.dtb"
>>>
>>> I rather need to go via the EntryArg indirection of the binman 
>>> command line.
>>
>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>> wanting to filter that list based on something else?
>>
>> I'm afraid I am really not following this at all.
>
> CONFIG_OF_LIST is not working here as we have two different boards 
> with
> two different lists.

 But we only build one board at a time, don't we?
>>>
>>> No, this is about building two flash images for two different board
>>> generations in the same binman run (see patch 3).
>>>

 We could provide a way to select between different lists, but how does
 Makefile get access to them?
>>>
>>> See patch 3: known lists, now put into board config.mk.
>>>
>>
>> Any better suggestions for this issue? Otherwise, I will have to keep
>> binman args extension for now.
>
> I've dug into this a bit. The use of #defines and macros looks to be
> unnecessary, unless I am missing something.
>
> You can do things like this:
>
> fit_node: fit {
> // base definition of FIT
> };
>
> the later on:
>
> fit_node: {
> #ifdef xxx
>// override a few things
>fit,fdt-list = ...
> #else
>
> #endif

 As I wrote already, I have a solution for that by using a template dtsi.

>
> There is no need to specify the properties all at once. You can update
> a property later on just by referring to its node as above.

 Does not help when the anchor name needs to vary as well. That's where I
 will use a #define to customize the template on include.

>
> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> and all the #define stuff.

 You still didn't address my question. Should I share my version to make
 the problem clearer? But I thought I explained this in various shades
 already.
>>>
>>> Yes, if I am looking at the wrong patches, please point me to the
>>> correct series, or push a tree somewhere.
>>>
>>
>> Please have a look at
>> https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e
> 
> OK that looks a lot better to me. We can go with that until we come up
> with something better.
> 
> There has been a long-standing request to support common parts of images.
> 
> I am thinking something 

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran
El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia:
> 
> Default, see:
> $ git grep CONFIG_BOOTCOMMAND configs/
>

I'm lost.

I called default what Kconfig used as default.
You seem to call default what's in board specific config files.
Whatever. Fix the wording in the commit message if you like.


> 
> So, what is the minimal test case ?
> I have been asking for that for a while.
>

I sent a minimal test case last week.

https://lists.denx.de/pipermail/u-boot/2023-June/520109.html

You build for a Rock Pi 4 board, boot with usb stick and no boot media
and run usb info and you get a reset.

I won't send it again because I can't guess what you consider minimal.

> 
> I would really like a minimal test case. Empty your env and figure out the
> commands which need to be executed to trigger this. Without any interference
> from other commands/scripting/...
>

I'm sorry but if what I sent isn't enough I don't think I'll have time
to help you any further. Find your minimal test case yourself or
ignore my patch.

> > If it's just that you can't reproduce it, can you try to ?:
> > 
> > - set up a board with no boot media (I tested like this but it might
> >not be needed),
> > 
> > - put usb in boot_targets (if you put only usb there you may not need
> >the previous step):
> >setenv boot_targets usb
> 
> Here you assume distro bootcommand or some such . Can we remove that
> assumption ? (I think yes, and we should)
>

I don't think I'm assuming anything about bootcommand. That's
precisely why I wrote these steps instead of the "just boot a Rock Pi
4" scenario last week.

The commit message talks about bootcmd because it justifies
that the bootflow scan will be called automatically in some cases,
so the bug has more impact that it would otherwise have.

But the bug should appear whether or not you have bootcmd.
The bug should be an interaction between what bootflow scan does
and what usb info or usb tree do.

I'm assuming bootflow reads the boot_targets environment variable to
know where it searches for boot devices, and therefore to which
devices it will attach a UCLASS_BOOTDEV child to some devices, in
particular to usb mass storage devices if any is present, that will
later break usb info/usb tree. Whether bootflow is called from bootcmd
or not should be irrelevant.

If you follow the code from the bootflow command you may find
yourself that the boot_targets variable is involved. I did it
last week or sometime and won't do it again now for you, sorry.
I know I may have misunderstood something, and I'm sorry for the
noise if so.

> > - plug a non-booting usb mass storage device to an usb port,
> > 
> > - run usb reset in case you already had usb initialized at boot, or
> >skip this if usb is not initialized yet. If in doubt, run usb reset.
> > 
> > - run bootflow scan
> > 
> > - run usb info
> > 
> > It should list some devices, but give you a reset just after listing the
> > usb mass storage device without my patch, and it should just list all
> > usb devices and go back to the prompt with my patch.
> 
> Does it crash if you empty your env and run simply
> 
> => usb reset ; bootflow scan ; usb info
> 
> ?

I guess it won't crash if environment var boot_targets is absent or
empty.  Or even if it's full but has no "usb" in it. But I'm not sure
anymore at what time the variable is read, so it might be that
emptying it when bootflow structures are already set up wouldn't
change things, I don't know, I don't remember.

But I won't try it, sorry.

I found a bug, I sent a 4 line patch. Since I didn't justify it
enough I sent followup mails on how to reproduce.
This week I sent a second version, with redundant measures to seek
consensus. It's a 6 line patch or 8 or whatever.
I didn't write bootflow, and I didn't write cmd/usb.c

And I don't have time to keep writing long emails. I'm sorry.  Not
even to count how many lines of text I wrote compared to the 8 lines
of code or whatever. If someone has the bureaucratic skills and
patience to pursue this further, they can do what they want with my
patch (under GPL2 as implied by the sign off). If not, you all can
keep your bugs, I won't try anymore to steal them.

Bye and sorry for any disturbances.


[PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set

2023-06-20 Thread Kunihiko Hayashi
In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed
after _end, and fdt_find_separate() always returns _end. There is
a .bss section after _end and the section is cleared before relocation.

When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is
still in .bss section, but will be cleared. As a result, the devicetree
become invalid.

To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC
in reloc_fdt().

Signed-off-by: Kunihiko Hayashi 
---
 common/board_f.c | 2 --
 1 file changed, 2 deletions(-)

Changes since v1:
- Remove condition for skipping fdt relocation (always relocate)

diff --git a/common/board_f.c b/common/board_f.c
index 1688e27071fc..334d04af197b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -633,8 +633,6 @@ static int init_post(void)
 static int reloc_fdt(void)
 {
if (!IS_ENABLED(CONFIG_OF_EMBED)) {
-   if (gd->flags & GD_FLG_SKIP_RELOC)
-   return 0;
if (gd->new_fdt) {
memcpy(gd->new_fdt, gd->fdt_blob,
   fdt_totalsize(gd->fdt_blob));
-- 
2.25.1



Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran
El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia:
> Hi Xavier,
>

Hi Simon,

> >
> > It is also possible that one day a device that is not UCLASS_BLK,
> > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> > device (just imagine a future system similar to bootstd for firmware
> > updates, trust material, etc.). Is it likely to have a struct in
> > parent_priv_ that is not a usb_device ?
> >
> > So which is more likely to survive future changes ?
> >
> > - checking for parent_priv_ not null and not UCLASS_USB_EMUL
> >
> > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> > UCLASS_BLK
> >   (my patch, overcautious ?)
> >
> > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
> >   (Simon Glass' idea)
> >
> > - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not 
> > UCLASS_USB_EMUL
> >and parent_priv_ not null
> 
> Really the parent_priv thing is a separate issue, a side effect of
> something having a UCLASS_USB parent.
>

I don't think it's a separate issue. If parent_priv is present it
could be a usb_device (most likely) or not, but if it's null there's
no way the recursive call can succeed.

> The key point here is that we cannot iterate down into a bootdev
> device looking for USB devices. So we should use that as the check,
> since it is the most direct check.
>

But things keep appearing that have a UCLASS_USB* parent and no
parent_priv.
in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK
being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow
may be something else.

The most direct check will miss future cases as the devices tend to
become more abstract instead of mapping one to one to physical stuff.

> 
> >From my memory, I think you can check for a USB hub instead, but I'm
> not completely sure.
>

On second thoughts I didn't find it so easy. There's the root hub,
UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I
don't know anymore how more elegant that could be, so I left it be.

> I suggest adding a test for the command (see test/dm/acpi.c for an
> example) since a test is the best way to ensure this doesn't happen
> again.
>

Makes sense. But I don't have any more time for that, sorry.

I think we'll have to leave it at this unless someone else has the time.

Bye.


[PATCH] Add Renesas patch attribution domain mapping

2023-06-20 Thread Marek Vasut
Add domain mapping for the +renesas mail, so that the patches get
attributed to to Renesas Electronics correctly.

Signed-off-by: Marek Vasut 
---
 u-boot-config/domain-map | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map
index f64147e..478696f 100644
--- a/u-boot-config/domain-map
+++ b/u-boot-config/domain-map
@@ -536,3 +536,6 @@ s...@chromium.org   Google, Inc.
 
 # Louis Yung-Chieh Lo 
 # yj...@google.com Google, Inc.
+
+# Marek Vasut
+marek.vasut+rene...@mailbox.orgRenesas Electronics
-- 
2.39.2



Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-20 Thread Andre Przywara
On Sun, 18 Jun 2023 13:01:33 -0600
Sam Edwards  wrote:

Hi Sam,

thanks for the reply, that's very helpful.

> On 6/14/23 18:07, Andre Przywara wrote:
> > So I finally found some time to address some issues in the series,
> > especially in the first patches (pinctrl rework and preparation).
> > I pushed a branch to https://github.com/apritzel/u-boot/commits/r528-rc
> > I need to do more testing, most importantly regression testing on other
> > SoCs, and will only be able to post something next week, I guess.
> > 
> > If you could briefly list the things that are still missing, I could
> > try to pick some low hanging fruits.  
> 
> Rebasing onto this branch ended up eliminating a good chunk of my local 
> hack commits. I've verified that everything is still working (but have 
> not yet retested NAND SPL).

Great, thanks!

> The remaining local changes I have are two additions to cpu_sunxi_ncat2.h:
> +#define SUNXI_R_CPUCFG_BASE  0x07000400 /* for PSCI */
> +#define SUNXI_RTC_BASE   0x0709 /* for FEL */

Right, I will definitely take the PSCI bit, but not so sure about FEL yet.

> The former can probably be brought into my PSCI series somehow (unless 
> we expect more chips with CPUX blocks which might move those soft entry 
> registers around, then it should be defined in cpu_sunxi_*.h). The 
> latter is to support a reimplementation of Allwinner's `efex` command 
> that I'm using for development (it pokes the magic number 0x5AA5A55A 
> into RTC's GP_DATA_REG[2] and then resets; SPL clears that magic number 
> and then does an early branch to BROM+0x0020 -- exactly what Allwinner's 
> fork does).

So yeah, the request of a "Enter FEL" command came up multiple times, but
so far no one could be bothered to implement this properly. The idea would
be to have a generic command (more like "fel-reset" than efex), and
allow each SoC (family) to implement this differently, as every
SoC requires something a bit different here (32-bit vs. 64-bit, having an
RTC vs not, etc).

If you could post your solution somewhere, we could start this effort.
There was some patch for the H3 already, and it's relatively
straight-forward on the newer SoCs (H616, IIRC), so if at least two
popular, but different SoCs would be supported, we could make sure to have
the right abstractions in place.

> I've also noticed exactly(!) one formatting difference in our clk_d1.c:
> - .num_gates = ARRAY_SIZE(d1_gates),
> + .num_gates  = ARRAY_SIZE(d1_gates),
> 
> Up to you if you prefer to align the = or not, but it does look 
> inconsistent when .gates and .resets are aligned and .num_* aren't - 
> might be a nitpick that comes up in patch review.

Well, this is how it is in all the other clock drivers, so I chose to stay
consistent with them ;-)

> > Interesting, indeed this is left at 0, which I think will result in 288
> > MHz.  
> 
> Correct, at least that's what I was seeing.
> 
> > What is that frequency in your case? Do you know what the BSP
> > programs?  
> 
> 1008 MHz, both.
> 
> > Traditionally we used something conservative that works
> > without cooling and with the default voltage, but I don't know that
> > value for the T113s.  
> 
> For what it's worth, this board has a bare T113-s3 and the current OS 
> does not reclock from 1008 MHz at all, and I don't know of any users of 
> the board having stability issues.
> 
> In my own case, it idles at that clock at around ~35°C.

OK, many thanks, it looks like 1008 MHz it is, then.

> > I think CLK_SUN20I_D1 should be set by default now, so can you check
> > that this is fixed?  
> 
> It is now gone from my defconfig and still working, so indeed this is fixed.
> 
> > Why would we need H6 PSCI support? On the ARMv8 parts we use Trusted
> > Firmware-A (TF-A) to provide PSCI services, which has a much more mature
> > implementation.  
> 
> It's not about the H6 and more about me being unsure whether R528/T113 
> is the first ARMv7-based SoC to use the new CPU management registers. If 
> it's not, and there's another such chip supported in U-Boot that just 
> lacks PSCI, it would make more sense for me to land my PSCI series 
> independently of our work here, and then you can add the R528 case 
> later. It sounds like R528/T113 may be the first such chip needing this 
> new code, though, so this may have to wait until the R528 series lands.
> 
> > How would this conflict, exactly? I don't see any other I2C2
> > definition?  
> 
> Well, no, the other definitions haven't landed in U-Boot yet. But they 
> do exist in the kernel, datasheets, and physical chips themselves:
> 
> PB0/PB1/PB8/PB9/PE4/PE5: i2c2 defined as muxval 4
> PC0/PC1/PD20/PD21/PG6/PG7/PG14/PG15: i2c2 defined as muxval 3
> PE12/PE13: i2c2 defined as muxval 2
> 
> Defining i2c2=2 universally would mean that the pins for i2c2 cannot be 
> changed, since it would conflict with every other definition.

Well, we are well aware that the current pinmux code is limited, but
we figured it does wor

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek




On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host 
mode,

+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I 
noticed that you removed the code that resets the PHYs in this patch 
hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in 
the future. I spent enormous amount of my spare time trying to explain to 
Xilinx how to do that mostly automatically, but that was all ignored or 
countered with reason after reason why this cannot be done, but as far as 
I can tell, nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from Linux 
kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an 
autom

Re: [PATCH v4 0/4] SPL NVMe support

2023-06-20 Thread Tom Rini
On Sat, 03 Jun 2023 19:32:52 +0530, Mayuresh Chitale wrote:

> This patchset adds support to load images of the SPL's next booting
> stage from a NVMe device.
> 
> Changes in v4:
> - Drop patch 4
> - Modify patch 2 to use generic fs.h APIs
> 
> [...]

With one change, which is that the "disk/part.c" in 4/4 were not required for
any platform in tree and also broke testcases, and so was dropped, this has now
been applied to u-boot/next. If you can explain a bit more what the problem you
had was, we can look in to it. I suspect you need to test for not
SPL_ENV_SUPPORT  but ENV_SUPPORT itself.

-- 
Tom



[PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread teik . heng . chong
From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
 drivers/usb/host/dwc2.c | 34 --
 drivers/usb/host/dwc2.h |  4 
 2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
 
/* Turn on the vbus power. */
if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(®s->hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, ®s->hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
 
case USB_PORT_FEAT_RESET:
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_POWER:
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_ENABLE:
@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
 
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
 
for (i = 0; i < MAX_DEVICE; i++) {
for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
 static void dwc2_uninit_common(struct dwc2_core_regs *regs)
 {
/* Put everything in reset. */
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
 }
 
 #if !CONFIG_IS_ENABLED(DM_USB)
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
 #define DWC2_HPRT0_PRTSPD_LOW  (2 << 17)
 #define DWC2_HPRT0_PRTSPD_MASK (0x3 << 17)
 #define DWC2_HPRT0_PRTSPD_OFFSET   17
+#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET 
| \
+   DWC2_HPRT0_PRTENA | \
+   DWC2_HPRT0_PRTENCHNG | \
+  

Re: [PATCH v13 01/10] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers

2023-06-20 Thread Ilias Apalodimas
Hi Abdellatif,

On Fri, 16 Jun 2023 at 18:28, Abdellatif El Khlifi
 wrote:
>
> add support for x0-x17 registers used by the SMC calls
>
> In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
> Results are returned in x0-x17.
>
> This work is inspired from the following kernel commit:
>
> arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
>
> [1]: 
> https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=

I did review this one in the past, any reason why that is missing?
Did the file change?

Thanks
/Ilias
>
> Signed-off-by: Abdellatif El Khlifi 
> Reviewed-by: Jens Wiklander 
> Reviewed-by: Simon Glass 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
>
> ---
>
> Changelog:
> ===
>
> v9:
>
> * update the copyright string
>
> v7:
>
> * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS
>
> v4:
>
> * rename the commit title and improve description
>   new commit title: the current
>
> v3:
>
> * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2
>   commit title:
>   arm64: smccc: add Xn registers support used by SMC calls
>
>  arch/arm/cpu/armv8/smccc-call.S | 57 -
>  arch/arm/lib/asm-offsets.c  | 16 +
>  include/linux/arm-smccc.h   | 45 ++
>  3 files changed, 117 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index dc92b28777..93f66d3366 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -1,7 +1,11 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * Copyright (c) 2015, Linaro Limited
> - */
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
> +*/
>  #include 
>  #include 
>  #include 
> @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc)
>  ENTRY(__arm_smccc_hvc)
> SMCCC   hvc
>  ENDPROC(__arm_smccc_hvc)
> +
> +#ifdef CONFIG_ARM64
> +
> +   .macro SMCCC_1_2 instr
> +   /* Save `res` and free a GPR that won't be clobbered */
> +   stp x1, x19, [sp, #-16]!
> +
> +   /* Ensure `args` won't be clobbered while loading regs in next step */
> +   mov x19, x0
> +
> +   /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */
> +   ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> +   ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> +   ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> +   ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> +   ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> +   ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> +   ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> +   ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> +   ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> +   \instr #0
> +
> +   /* Load the `res` from the stack */
> +   ldr x19, [sp]
> +
> +   /* Store the registers x0 - x17 into the result structure */
> +   stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> +   stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> +   stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> +   stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> +   stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> +   stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> +   stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> +   stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> +   stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> +   /* Restore original x19 */
> +   ldp xzr, x19, [sp], #16
> +   ret
> +   .endm
> +
> +/*
> + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
> + *   struct arm_smccc_1_2_regs *res);
> + */
> +ENTRY(arm_smccc_1_2_smc)
> +   SMCCC_1_2 smc
> +ENDPROC(arm_smccc_1_2_smc)
> +
> +#endif
> diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c
> index 6de0ce9152..181a8ac4c2 100644
> --- a/arch/arm/lib/asm-offsets.c
> +++ b/arch/arm/lib/asm-offsets.c
> @@ -9,6 +9,11 @@
>   * generate asm statements containing #defines,
>   * compile this file to assembler, and then extract the
>   * #defines from the assembly-language output.
> + *
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
>   */
>
>  #include 
> @@ -90,6 +95,17 @@ int main(void)
> DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
> DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id));
> DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, 
> state));
> +#ifdef CONFIG_ARM64
> +   DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a0));
> +   DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a2));
> +   DE

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut

On 6/20/23 15:36, Michal Simek wrote:



On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling 
loop executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to 
detect the

USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 


---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, 
u32 mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're 
in host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset 
state */

-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the 
PHYs in this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will 
turn the whole driver into an unmaintainable mess and make the 
sync that much harder in the future. I spent enormous amount of 
my spare time trying to explain to Xilinx how to do that mostly 
automatically, but that was all ignored or countered with reason 
after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and 
I wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly 
start unless I add some manual delays here and there, and I am 
trying to see why.


It is not just about dwc3. There are other parts which are ported 
from Linux kernel and are out of sync from Linux kernel for quite a 
long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opp

Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Jassi Brar
On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas
 wrote:
>
> Sorry for being late to the party,
>
> +cc Jose who maintains DEN0118
>
> On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:
> > Hi Michal,
> >
> > On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:
> > >
> > > Hi Jassi,
> > >
> > > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:
> > > > From: Jassi Brar 
> > > >
> > > > Introduce support for mtd backed storage for FWU feature and enable it 
> > > > on
> > > > Synquacer platform based DeveloperBox.
> > > >
> > > > This revision is rebased onto patchset that trims the FWU api
> > > >   
> > > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/
> > > >
> > .
> >
> > > Firstly I can generate 2 images per one bank which should be pretty much 
> > > regular
> > > capsule update for 2 images. I would expect this should still work.
> > >
> > > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() 
> > > generated
> > > this description for DFU
> > >
> > > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw
> > > 23a 400;bank1 raw 282 400
> > >
> > > If you look at size in second entry you will see that it is 8000 instead 
> > > of
> > > 8 because it is the same image. That's why curious if you have tested 
> > > any
> > > scenario like this.
> > >
> > I had, and have, strong doubts about the practicality of 2
> > images/bank. There aren't enough specification details to explain how
> > only 1-out-of-N images could be updated. And if we always update all
> > images in a bank together, we might as well have them as one composite
> > image. I never got satisfactory clarification from designers and
> > implementers. So, sorry, I can't defend that scenario with my limited
> > knowledge.
>
> This is intentionally left out, as we consider it a platform policy.
> For example you could update a single bank and copy over the remaining
> firmware images from a different ban. There's nothing on the spec that
> prohibits you from doing so, but I personally think it's a bad idea.
>
Me too.

> Keep in mind there's a document hosted here[0] which explains the update
> flow and documents what we have as code in U-Boot.
>
> As far as individual firmware components go now,  do you have any useful
> usecase?
>
No.  And I don't think current A/B update implementation in u-boot
even has helpers for platforms to implement multiple images per bank.
Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK
config -- which will always be set to 1 I predict ;)

>  The general guidance of [0] is construct a firmware
> image, only update the components you want while leaving the rest on the
> same revisions and update the entire firmware.  The reason is that firmware
>
> Updating a single image of another bank is not as easy as it sounds.
>
exactly.

> Firmware components nowadays, whether we like it or not, depend on each other.
> Since firmware updates are not so often and fast,  we didn't see any gains 
> from
> over complicating the spec and explicitly describe that case, while dealing
> with firmware component compatibility at the same time.
>
Totally.  As I said, I don't believe in the practicality of more than
1 image/bank.
So we are on the same page.

> >
> > > Next part which I want to take a look is practicality of 
> > > CONFIG_FWU_NUM_BANKS
> > > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing 
> > > number of
> > > banks and images for every platform and prevent creating one u-boot which 
> > > works
> > > on different boards and just use information from mdata.
> > > DEN0118 doesn't show any field with this information but do you think 
> > > that would
> > > be possible to extract that information from there based on for example 
> > > reserved
> > > or accepted field?
> > >
> > Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
> > 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
> > use any bit, we'll be in violation of the spec.
>
> Yes this is unfortunate.  We did have similar concerns on when drafting the
> spec,  however we never had a solid usecase to justify this.  Arm and
> Linaro and working on a v2 (which we try to make compatible with v1) which
> addresses this shortcoming.  Maybe Jose can chime in.
>
OK. If we have, say, reserved[0] as last Image and reserved[1] as last
Bank, we could get rid of the two compile-time configs.

Thanks.


Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Michal Simek




On 6/20/23 16:14, Jassi Brar wrote:

On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas
 wrote:


Sorry for being late to the party,

+cc Jose who maintains DEN0118

On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:

Hi Michal,

On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:


Hi Jassi,

On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:

From: Jassi Brar 

Introduce support for mtd backed storage for FWU feature and enable it on
Synquacer platform based DeveloperBox.

This revision is rebased onto patchset that trims the FWU api
   
https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/


.


Firstly I can generate 2 images per one bank which should be pretty much regular
capsule update for 2 images. I would expect this should still work.

And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() generated
this description for DFU

mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw
23a 400;bank1 raw 282 400

If you look at size in second entry you will see that it is 8000 instead of
8 because it is the same image. That's why curious if you have tested any
scenario like this.


I had, and have, strong doubts about the practicality of 2
images/bank. There aren't enough specification details to explain how
only 1-out-of-N images could be updated. And if we always update all
images in a bank together, we might as well have them as one composite
image. I never got satisfactory clarification from designers and
implementers. So, sorry, I can't defend that scenario with my limited
knowledge.


This is intentionally left out, as we consider it a platform policy.
For example you could update a single bank and copy over the remaining
firmware images from a different ban. There's nothing on the spec that
prohibits you from doing so, but I personally think it's a bad idea.


Me too.


Keep in mind there's a document hosted here[0] which explains the update
flow and documents what we have as code in U-Boot.

As far as individual firmware components go now,  do you have any useful
usecase?


No.  And I don't think current A/B update implementation in u-boot
even has helpers for platforms to implement multiple images per bank.
Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK
config -- which will always be set to 1 I predict ;)


Actually support is there but it requires one thing to patch. I will send that 
patch when I clean my repo.

And I have tested it on our platform.




  The general guidance of [0] is construct a firmware
image, only update the components you want while leaving the rest on the
same revisions and update the entire firmware.  The reason is that firmware

Updating a single image of another bank is not as easy as it sounds.


exactly.


Firmware components nowadays, whether we like it or not, depend on each other.
Since firmware updates are not so often and fast,  we didn't see any gains from
over complicating the spec and explicitly describe that case, while dealing
with firmware component compatibility at the same time.


Totally.  As I said, I don't believe in the practicality of more than
1 image/bank.
So we are on the same page.




Next part which I want to take a look is practicality of CONFIG_FWU_NUM_BANKS
and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number of
banks and images for every platform and prevent creating one u-boot which works
on different boards and just use information from mdata.
DEN0118 doesn't show any field with this information but do you think that would
be possible to extract that information from there based on for example reserved
or accepted field?


Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
use any bit, we'll be in violation of the spec.


Yes this is unfortunate.  We did have similar concerns on when drafting the
spec,  however we never had a solid usecase to justify this.  Arm and
Linaro and working on a v2 (which we try to make compatible with v1) which
addresses this shortcoming.  Maybe Jose can chime in.



Another way would be to simply decode this information directly from DT 
fwu-mdata node. Because from that node it is clear how many banks and how many 
images that particular bank has.


Thanks,
Michal




Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek




On 6/20/23 16:13, Marek Vasut wrote:

On 6/20/23 15:36, Michal Simek wrote:



On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host 
mode,

+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , 
I noticed that you removed the code that resets the PHYs in this patch 
hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in 
the future. I spent enormous amount of my spare time trying to explain 
to Xilinx how to do that mostly automatically, but that was all ignored 
or countered with reason after reason why this cannot be done, but as 
far as I can tell, nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current 
state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from 
Linux kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


Re: [PATCH v13 05/10] arm_ffa: introduce armffa command

2023-06-20 Thread Ilias Apalodimas
[...]

>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43603522fd..0d960731cf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -269,7 +269,9 @@ F:  configs/cortina_presidio-asic-pnand_defconfig
>  ARM FF-A
>  M: Abdellatif El Khlifi 
>  S: Maintained
> +F: cmd/armffa.c
>  F: doc/arch/arm64.ffa.rst
> +F: doc/usage/cmd/armffa.rst
>  F: drivers/firmware/arm-ffa/
>  F: include/arm_ffa.h
>  F: include/sandbox_arm_ffa.h
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 365371fb51..86af7bcc9e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -934,6 +934,16 @@ endmenu
>
>  menu "Device access commands"
>
> +config CMD_ARMFFA
> +   bool "Arm FF-A test command"
> +   depends on ARM_FFA_TRANSPORT
> +   help
> + Provides a test command for the FF-A support
> + supported options:
> +   - Listing the partition(s) info
> +   - Sending a data pattern to the specified partition
> +   - Displaying the arm_ffa device info
> +
>  config CMD_ARMFLASH
> #depends on FLASH_CFI_DRIVER
> bool "armflash"
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 6c37521b4e..7d20a85a46 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -12,6 +12,7 @@ obj-y += panic.o
>  obj-y += version.o
>
>  # command
> +obj-$(CONFIG_CMD_ARMFFA) += armffa.o
>  obj-$(CONFIG_CMD_2048) += 2048.o
>  obj-$(CONFIG_CMD_ACPI) += acpi.o
>  obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
> diff --git a/cmd/armffa.c b/cmd/armffa.c
> new file mode 100644
> index 00..fa268e9cb9
> --- /dev/null
> +++ b/cmd/armffa.c
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * ffa_get_dev() - Return the FF-A device
> + * @devp:  pointer to the FF-A device
> + *
> + * Search for the FF-A device.
> + *
> + * Return:
> + * 0 on success. Otherwise, failure
> + */
> +int ffa_get_dev(struct udevice **devp)

Why isn't this static?  If it's used in another file we need to move
it to a library suitable file.

> +{
> +   int ret;
> +
> +   ret = uclass_first_device_err(UCLASS_FFA, devp);
> +   if (ret) {
> +   log_err("Cannot find FF-A bus device\n");
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * do_ffa_getpart() - implementation of the getpart subcommand
> + * @cmdtp: Command Table
> + * @flag:  flags
> + * @argc:  number of arguments
> + * @argv:  arguments
> + *
> + * Query the secure partition information which the UUID is provided
> + * as an argument. The function uses the arm_ffa driver
> + * partition_info_get operation which implements FFA_PARTITION_INFO_GET
> + * ABI to retrieve the data. The input UUID string is expected to be in big
> + * endian format.
> + *
> + * Return:
> + *
> + * CMD_RET_SUCCESS: on success, otherwise failure
> + */
> +static int do_ffa_getpart(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> +   u32 count = 0;
> +   int ret;
> +   struct ffa_partition_desc *descs;
> +   u32 i;
> +   struct udevice *dev;
> +
> +   if (argc != 2) {
> +   log_err("Missing argument\n");
> +   return CMD_RET_USAGE;
> +   }
> +
> +   ret = ffa_get_dev(&dev);
> +   if (ret)
> +   return CMD_RET_FAILURE;
> +
> +   /* Ask the driver to fill the buffer with the SPs info */
> +
> +   ret = ffa_partition_info_get(dev, argv[1], &count, &descs);
> +   if (ret) {
> +   log_err("Failure in querying partition(s) info (error code: 
> %d)\n", ret);
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   /* SPs found , show the partition information */
> +   for (i = 0; i < count ; i++) {
> +   log_info("Partition: id = %x , exec_ctxt %x , properties 
> %x\n",
> +descs[i].info.id,
> +descs[i].info.exec_ctxt,
> +descs[i].info.properties);
> +   }
> +
> +   return CMD_RET_SUCCESS;
> +}
> +
> +/**
> + * do_ffa_ping() - implementation of the ping subcommand
> + * @cmdtp: Command Table
> + * @flag:  flags
> + * @argc:  number of arguments
> + * @argv:  arguments
> + *
> + * Send data to the secure partition which the ID is provided

s/which/ in which/

> + * as an argument. Use the arm_ffa driver sync_send_receive operation
> + * which implements FFA_MSG_SEND_DIRECT_{REQ,RESP} ABIs to send/receive data.
> + *
> + * Return:
> + *
> + * CMD_RET_SUCCESS: on success, otherwise failure
> + */
> +int do_ffa_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[])
> +{
> +   struct ffa_send_direct_data msg = {
> +

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Simon Glass
On Tue, 20 Jun 2023 at 12:20, Xavier Drudis Ferran  wrote:
>
> El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia:
> > Hi Xavier,
> >
>
> Hi Simon,
>
> > >
> > > It is also possible that one day a device that is not UCLASS_BLK,
> > > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> > > device (just imagine a future system similar to bootstd for firmware
> > > updates, trust material, etc.). Is it likely to have a struct in
> > > parent_priv_ that is not a usb_device ?
> > >
> > > So which is more likely to survive future changes ?
> > >
> > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL
> > >
> > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> > > UCLASS_BLK
> > >   (my patch, overcautious ?)
> > >
> > > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
> > >   (Simon Glass' idea)
> > >
> > > - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not 
> > > UCLASS_USB_EMUL
> > >and parent_priv_ not null
> >
> > Really the parent_priv thing is a separate issue, a side effect of
> > something having a UCLASS_USB parent.
> >
>
> I don't think it's a separate issue. If parent_priv is present it
> could be a usb_device (most likely) or not, but if it's null there's
> no way the recursive call can succeed.
>
> > The key point here is that we cannot iterate down into a bootdev
> > device looking for USB devices. So we should use that as the check,
> > since it is the most direct check.
> >
>
> But things keep appearing that have a UCLASS_USB* parent and no
> parent_priv.
> in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK
> being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow
> may be something else.
>
> The most direct check will miss future cases as the devices tend to
> become more abstract instead of mapping one to one to physical stuff.
>
> >
> > >From my memory, I think you can check for a USB hub instead, but I'm
> > not completely sure.
> >
>
> On second thoughts I didn't find it so easy. There's the root hub,
> UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I
> don't know anymore how more elegant that could be, so I left it be.
>
> > I suggest adding a test for the command (see test/dm/acpi.c for an
> > example) since a test is the best way to ensure this doesn't happen
> > again.
> >
>
> Makes sense. But I don't have any more time for that, sorry.
>
> I think we'll have to leave it at this unless someone else has the time.

Reviewed-by: Simon Glass 


Re: [PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set

2023-06-20 Thread Simon Glass
On Tue, 20 Jun 2023 at 11:50, Kunihiko Hayashi
 wrote:
>
> In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed
> after _end, and fdt_find_separate() always returns _end. There is
> a .bss section after _end and the section is cleared before relocation.
>
> When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is
> still in .bss section, but will be cleared. As a result, the devicetree
> become invalid.
>
> To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC
> in reloc_fdt().
>
> Signed-off-by: Kunihiko Hayashi 
> ---
>  common/board_f.c | 2 --
>  1 file changed, 2 deletions(-)
>
> Changes since v1:
> - Remove condition for skipping fdt relocation (always relocate)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass
Hi Jan,

On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
>
> On 20.06.23 12:11, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 16:09, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> 
>  On 19.06.23 14:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
> >>
> >> On 15.06.23 13:46, Jan Kiszka wrote:
> >>> On 15.06.23 13:38, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
>  wrote:
> >
> > On 15.06.23 13:19, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 12:55, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
>   wrote:
> >
> > On 12.06.23 23:17, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
> >>  wrote:
> >>>
> >>> From: Jan Kiszka 
> >>>
> >>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., 
> >>> to inject
> >>> specific settings. Will be used by IOT2050 first to define 
> >>> multiple
> >>> of-lists.
> >>>
> >>> Signed-off-by: Jan Kiszka 
> >>> ---
> >>> CC: Simon Glass 
> >>> ---
> >>>  Makefile | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>
> >> I'm really not keen on this, since it means that the Makefile 
> >> (or some
> >> vars it sets) are again involved in controlling the image 
> >> generation.
> >> It should really all be in the binman image description / 
> >> .dtsi file
> >
> > binman does not allow me to unrole of-list inside the dts file, 
> > does it?
> > With such a feature, I wouldn't need any custom -a of-list-X 
> > switches
> > and, thus, no such EXTRA_ARGS.
> 
>  Can you explain a bit more about what you mean by 'unrole'? It 
>  is just
>  software, so anything should be possible.
> >>>
> >>> To use a DT sequence, I need to specify fit,ftd-list. But I can 
> >>> say
> >>>
> >>> fit,ftd-list = "first.dtb second.dtb"
> >>>
> >>> I rather need to go via the EntryArg indirection of the binman 
> >>> command line.
> >>
> >> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
> >> you
> >> wanting to filter that list based on something else?
> >>
> >> I'm afraid I am really not following this at all.
> >
> > CONFIG_OF_LIST is not working here as we have two different boards 
> > with
> > two different lists.
> 
>  But we only build one board at a time, don't we?
> >>>
> >>> No, this is about building two flash images for two different board
> >>> generations in the same binman run (see patch 3).
> >>>
> 
>  We could provide a way to select between different lists, but how 
>  does
>  Makefile get access to them?
> >>>
> >>> See patch 3: known lists, now put into board config.mk.
> >>>
> >>
> >> Any better suggestions for this issue? Otherwise, I will have to keep
> >> binman args extension for now.
> >
> > I've dug into this a bit. The use of #defines and macros looks to be
> > unnecessary, unless I am missing something.
> >
> > You can do things like this:
> >
> > fit_node: fit {
> > // base definition of FIT
> > };
> >
> > the later on:
> >
> > fit_node: {
> > #ifdef xxx
> >// override a few things
> >fit,fdt-list = ...
> > #else
> >
> > #endif
> 
>  As I wrote already, I have a solution for that by using a template dtsi.
> 
> >
> > There is no need to specify the properties all at once. You can update
> > a property later on just by referring to its node as above.
> 
>  Does not help when the anchor name needs to vary as well. That's where I
>  will use a #define to customize the template on include.
> 
> >
> > I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> > and all the #define stuff.
> 
>  You still didn't address my question. Should I share my version to make
>  the problem clearer? But I thought I explained this in various shades
>  already.
> >>>
> >>> Yes, if I am looking at the wrong patches, please point me

Rockchip DWC2 issue

2023-06-20 Thread Jagan Teki
Hi,

Has anyone tried to use dwc2 and echi port together with USB disk?
look like this is not working with this combination on any Rockchip
SoC's

Here are the issues that I've reproduced in RK3328 where the disk
connected in EHCI port is detecting but DWC2 is not. Any clue?

=> usb start
starting USB...
Bus usb@ff5c: USB EHCI 1.00
Bus usb@ff5d: USB OHCI 1.0
Bus usb@ff60: generic_phy_get_bulk : no phys property
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@ff58: USB DWC2
scanning bus usb@ff5c for devices... 2 USB Device(s) found
scanning bus usb@ff5d for devices... 1 USB Device(s) found
scanning bus usb@ff60 for devices... 1 USB Device(s) found
scanning bus usb@ff58 for devices... Adding disk for
usb_mass_storage.lun0 failed
(err=-9223372036854775788/0x8014)
device 'usb_mass_storage.lun0' failed to unbind
1 USB Device(s) found
device 'usb_mass_storage.lun0' failed to unbind
   scanning usb for storage devices... 2 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
   Generic Teclast CoolFlash 4163831324317134

  1  Hub (12 Mb/s, 0mA)
  U-Boot Root Hub

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  U-Boot Root Hub

Thanks,
Jagan.


Re: [PATCH] Add Renesas patch attribution domain mapping

2023-06-20 Thread Tom Rini
On Tue, Jun 20, 2023 at 01:49:43PM +0200, Marek Vasut wrote:

> Add domain mapping for the +renesas mail, so that the patches get
> attributed to to Renesas Electronics correctly.
> 
> Signed-off-by: Marek Vasut 

Applied to gitdm/u-boot, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] spl: spl_nor: use panic instead of hang if booting fails

2023-06-20 Thread Tom Rini
On Mon, Jan 30, 2023 at 11:03:03AM +0100, Mario Kicherer wrote:

> On systems without a watchdog, using hang() prevents a system to
> recover from an error. For example, a board could implement a boot
> counter to switch to an alternative load address after some failed
> tries.
> 
> Signed-off-by: Mario Kicherer 
> ---
>  common/spl/spl.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 2855cdd117..d1aa2fb8a9 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -822,11 +822,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>   if (ret) {
>   if (CONFIG_IS_ENABLED(SHOW_ERRORS) &&
>   CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT))
> - printf(SPL_TPL_PROMPT "failed to boot from all boot 
> devices (err=%d)\n",
> -ret);
> + panic(SPL_TPL_PROMPT "failed to boot from all boot 
> devices (err=%d)\n",
> +   ret);
>   else
> - puts(SPL_TPL_PROMPT "failed to boot from all boot 
> devices\n");
> - hang();
> + panic_str(SPL_TPL_PROMPT "failed to boot from all boot 
> devices\n");
>   }
>  
>   spl_perform_fixups(&spl_image);

Not all platforms that use SPI in SPL have panic() (and related
functions) available, so this introduces a number of fail to builds.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi

2023-06-20 Thread Tim Harvey
Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-evk-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mm-phg-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-u-boot.dtsi   | 9 +
 arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi   | 7 ---
 7 files changed, 9 insertions(+), 42 deletions(-)

diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
index 484e31824b85..d12ce6069cc7 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
index 1878c4e13fbe..219504f61105 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 13688ec0d0f2..155670da18d1 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &aips4 {
diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
index 65dfd33725ee..1ad9d49a1118 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -16,13 +16,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &crypto {
diff --git a/arch/arm/dts/imx8mm-phg-u-boot.dtsi 
b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
index 3ced97cfaafa..c9e0b4420500 100644
--- a/arch/arm/dts/imx8mm-phg-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &aips4 {
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 7fd5a05fad3c..c48b5f2ef026 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -7,6 +7,15 @@
binman: binman {
multiple-images;
};
+
+#ifdef CONFIG_OPTEE
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+#endif
 };
 
 &soc {
diff --git a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi 
b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
index 494229e4e62a..f2c7bd919970 100644
--- a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
-- 
2.25.1



[PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi

2023-06-20 Thread Tim Harvey
Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 6 --
 arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mp-u-boot.dtsi  | 9 +
 arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi| 7 ---
 arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi  | 7 ---
 7 files changed, 9 insertions(+), 41 deletions(-)

diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi 
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
index 5ca631e9d8c4..bb0f9bd0c8d3 100644
--- a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &{/soc@0/bus@3080/i2c@30a2/pmic@25} {
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi 
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index 6784ed2e7c92..17965c58ba10 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -11,12 +11,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 ®_usdhc2_vmmc {
diff --git a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi 
b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
index d411cf79e85d..fe20938af536 100644
--- a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
@@ -12,13 +12,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 ®_usdhc2_vmmc {
diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi 
b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
index f3fb44046d5c..8f1df232b1b7 100644
--- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
@@ -12,13 +12,6 @@
wdt = <&wdog1>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &iomuxc {
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index 18d1728e1d2a..e8fe92485cd1 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -8,6 +8,15 @@
binman: binman {
multiple-images;
};
+
+#ifdef CONFIG_OPTEE
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+#endif
 };
 
 &soc {
diff --git a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
index c3fb040080b6..44ac315a1241 100644
--- a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mp-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi 
b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
index 9c6c417f7eea..a985645ff8c3 100644
--- a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mp-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
-- 
2.25.1



[PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef

2023-06-20 Thread Tim Harvey
There is no need to include the firmware/optee node if the optee
driver is not enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mn-u-boot.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index cef20dab4688..8191b973b464 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -8,12 +8,14 @@
multiple-images;
};
 
+#ifdef CONFIG_OPTEE
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
+#endif
 
wdt-reboot {
compatible = "wdt-reboot";
-- 
2.25.1



Re: [PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi

2023-06-20 Thread Fabio Estevam
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
> protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
> without the optee driver enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam 


Re: [PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi

2023-06-20 Thread Fabio Estevam
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
> protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
> without the optee driver enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam 


Re: [PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef

2023-06-20 Thread Fabio Estevam
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> There is no need to include the firmware/optee node if the optee
> driver is not enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam 


Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Jan Kiszka
On 20.06.23 16:36, Simon Glass wrote:
> Hi Jan,
> 
> On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
>>
>> On 20.06.23 12:11, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:

 On 19.06.23 16:09, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
>>
>> On 19.06.23 14:36, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:

 On 15.06.23 13:46, Jan Kiszka wrote:
> On 15.06.23 13:38, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
>> wrote:
>>>
>>> On 15.06.23 13:19, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
 wrote:
>
> On 15.06.23 12:55, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
>>  wrote:
>>>
>>> On 12.06.23 23:17, Simon Glass wrote:
 Hi Jan,

 On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
  wrote:
>
> From: Jan Kiszka 
>
> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., 
> to inject
> specific settings. Will be used by IOT2050 first to define 
> multiple
> of-lists.
>
> Signed-off-by: Jan Kiszka 
> ---
> CC: Simon Glass 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)

 I'm really not keen on this, since it means that the Makefile 
 (or some
 vars it sets) are again involved in controlling the image 
 generation.
 It should really all be in the binman image description / 
 .dtsi file
>>>
>>> binman does not allow me to unrole of-list inside the dts file, 
>>> does it?
>>> With such a feature, I wouldn't need any custom -a of-list-X 
>>> switches
>>> and, thus, no such EXTRA_ARGS.
>>
>> Can you explain a bit more about what you mean by 'unrole'? It 
>> is just
>> software, so anything should be possible.
>
> To use a DT sequence, I need to specify fit,ftd-list. But I can 
> say
>
> fit,ftd-list = "first.dtb second.dtb"
>
> I rather need to go via the EntryArg indirection of the binman 
> command line.

 Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
 you
 wanting to filter that list based on something else?

 I'm afraid I am really not following this at all.
>>>
>>> CONFIG_OF_LIST is not working here as we have two different boards 
>>> with
>>> two different lists.
>>
>> But we only build one board at a time, don't we?
>
> No, this is about building two flash images for two different board
> generations in the same binman run (see patch 3).
>
>>
>> We could provide a way to select between different lists, but how 
>> does
>> Makefile get access to them?
>
> See patch 3: known lists, now put into board config.mk.
>

 Any better suggestions for this issue? Otherwise, I will have to keep
 binman args extension for now.
>>>
>>> I've dug into this a bit. The use of #defines and macros looks to be
>>> unnecessary, unless I am missing something.
>>>
>>> You can do things like this:
>>>
>>> fit_node: fit {
>>> // base definition of FIT
>>> };
>>>
>>> the later on:
>>>
>>> fit_node: {
>>> #ifdef xxx
>>>// override a few things
>>>fit,fdt-list = ...
>>> #else
>>>
>>> #endif
>>
>> As I wrote already, I have a solution for that by using a template dtsi.
>>
>>>
>>> There is no need to specify the properties all at once. You can update
>>> a property later on just by referring to its node as above.
>>
>> Does not help when the anchor name needs to vary as well. That's where I
>> will use a #define to customize the template on include.
>>
>>>
>>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
>>> and all the #define stuff.
>>
>> You still didn't address my question. Should I share my version to make
>> the problem clearer? But I thought I explained this in various shades
>> already.
>
> Yes, if I am

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass
Hi Jan,

On Tue, 20 Jun 2023 at 18:05, Jan Kiszka  wrote:
>
> On 20.06.23 16:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
> >>
> >> On 20.06.23 12:11, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
> 
>  On 19.06.23 16:09, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 14:36, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  
> >>> wrote:
> 
>  On 15.06.23 13:46, Jan Kiszka wrote:
> > On 15.06.23 13:38, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 13:19, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:09, Jan Kiszka 
>   wrote:
> >
> > On 15.06.23 12:55, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
> >>  wrote:
> >>>
> >>> On 12.06.23 23:17, Simon Glass wrote:
>  Hi Jan,
> 
>  On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
>   wrote:
> >
> > From: Jan Kiszka 
> >
> > Introduce BINMAN_EXTRA_ARGS that can be set per board, 
> > e.g., to inject
> > specific settings. Will be used by IOT2050 first to define 
> > multiple
> > of-lists.
> >
> > Signed-off-by: Jan Kiszka 
> > ---
> > CC: Simon Glass 
> > ---
> >  Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> 
>  I'm really not keen on this, since it means that the 
>  Makefile (or some
>  vars it sets) are again involved in controlling the image 
>  generation.
>  It should really all be in the binman image description / 
>  .dtsi file
> >>>
> >>> binman does not allow me to unrole of-list inside the dts 
> >>> file, does it?
> >>> With such a feature, I wouldn't need any custom -a of-list-X 
> >>> switches
> >>> and, thus, no such EXTRA_ARGS.
> >>
> >> Can you explain a bit more about what you mean by 'unrole'? It 
> >> is just
> >> software, so anything should be possible.
> >
> > To use a DT sequence, I need to specify fit,ftd-list. But I can 
> > say
> >
> > fit,ftd-list = "first.dtb second.dtb"
> >
> > I rather need to go via the EntryArg indirection of the binman 
> > command line.
> 
>  Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
>  you
>  wanting to filter that list based on something else?
> 
>  I'm afraid I am really not following this at all.
> >>>
> >>> CONFIG_OF_LIST is not working here as we have two different 
> >>> boards with
> >>> two different lists.
> >>
> >> But we only build one board at a time, don't we?
> >
> > No, this is about building two flash images for two different board
> > generations in the same binman run (see patch 3).
> >
> >>
> >> We could provide a way to select between different lists, but how 
> >> does
> >> Makefile get access to them?
> >
> > See patch 3: known lists, now put into board config.mk.
> >
> 
>  Any better suggestions for this issue? Otherwise, I will have to keep
>  binman args extension for now.
> >>>
> >>> I've dug into this a bit. The use of #defines and macros looks to be
> >>> unnecessary, unless I am missing something.
> >>>
> >>> You can do things like this:
> >>>
> >>> fit_node: fit {
> >>> // base definition of FIT
> >>> };
> >>>
> >>> the later on:
> >>>
> >>> fit_node: {
> >>> #ifdef xxx
> >>>// override a few things
> >>>fit,fdt-list = ...
> >>> #else
> >>>
> >>> #endif
> >>
> >> As I wrote already, I have a solution for that by using a template 
> >> dtsi.
> >>
> >>>
> >>> There is no need to specify the properties all at once. You can update
> >>> a property later on just by referring to its node as above.
> >>
> >> Does not help when the anchor name needs to vary as well. That's where 
> >> I
> >> will use a #define to

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Detlev Casanova
On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:
> On 6/19/23 20:27, Detlev Casanova wrote:
> > On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:
> >> On 6/19/23 16:42, Detlev Casanova wrote:
> >>> On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:
>  On 6/16/23 17:21, Detlev Casanova wrote:
> > Expose that information to the command shell to let scripts select the
> > correct devicetree name.
> > 
> > Signed-off-by: Detlev Casanova 
> > ---
> > 
> > drivers/sysinfo/rcar3.c | 46
> > -
> > 1 file changed, 36 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
> > index 7b127986da7..89ad46c5422 100644
> > --- a/drivers/sysinfo/rcar3.c
> > +++ b/drivers/sysinfo/rcar3.c
> > @@ -32,6 +32,8 @@
> > 
> >  */
> > 
> > struct sysinfo_rcar_priv {
> > 
> > charboardmodel[64];
> > 
> > +   u8  id;
> > +   charrevision[4];
> > 
> > u8  val;
> > 
> > };
> > 
> > @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
> > *dev,
> > int id, size_t size, char *>
> > 
> > switch (id) {
> > 
> > case SYSINFO_ID_BOARD_MODEL:
> > -   strncpy(val, priv->boardmodel, size);
> > -   val[size - 1] = '\0';
> > +   strlcpy(val, priv->boardmodel, size);
> > +   break;
> > +   case SYSINFO_ID_BOARD_REVISION:
> > +   strlcpy(val, priv->revision, size);
> > +   break;
> > +   default:
> > +   return -EINVAL;
> > +   };
> > +
> > +   val[size - 1] = '\0';
> > +   return 0;
> > +}
> > +
> > +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
> > *val)
> > +{
> > +   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
> > +
> > +   switch (id) {
> > +   case SYSINFO_ID_BOARD_ID:
> > +   *val = priv->id;
> > 
> > return 0;
>  
>  Why not return SYSINFO_ID_BOARD_REVISION as integer here ?
> >>> 
> >>> Because the revision (on r-car3 boards at least) is in the format X.Y.
> >>> It
> >>> could be returned as "(X << 8) | Y" or split in major/minor. But
> >>> different
> >>> boards will use different revisions and I think that having a str is
> >>> easier to deal with in a shell script.
> >> 
> >> With rcar they are numbers, so lets go with major/minor integers please.
> > 
> > Ok for this part, but shouldn't the sysinfo command use a common interface
> > for all boards ? Or should it also have rev_major/rev_minor arguments ?
> I would expect other boards to either report rev_major/rev_minor if
> implemented, or errno if those boards don't implement this property.

Another thing on rcar is that the revision is stored as 2 char values. Would 
you oppose a change form using a char (e.g. rev_major = '1') to using u8 
values (e.g. rev_major = 1) instead ?





Re: [PATCH] spl: spl-nor: return error if no valid image was loaded

2023-06-20 Thread Tom Rini
On Mon, 30 Jan 2023 10:21:43 +0100, Mario Kicherer wrote:

> If only FIT images are enabled and loading the FIT image fails,
> spl_nor_load_image() should return an error instead of zero.
> 
> Without this patch:
> 
> >>SPL: board_init_r()
> spl_init
> Trying to boot from NOR
> Unsupported OS image.. Jumping nevertheless..
> image entry point: 0x0
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom



Re: [PATCH] usb: eth: lan78xx: Fix logic in lan78xx_read_otp() to avoid a warning

2023-06-20 Thread Tom Rini
On Thu, 04 Jun 2020 16:35:15 -0400, Tom Rini wrote:

> In lan78xx_read_otp() we want to know if sig is LAN78XX_OTP_INDICATOR_1
> or LAN78XX_OTP_INDICATOR_2.  In the case of matching the first one we
> set offset to itself, and clang warns about this.  Rework the logic so
> that if sig is the second indicator we adjust the offset as today and if
> it does not match the first indicator we return -EINVAL
> 
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom



[PATCH] mailbox: k3-sec-proxy: Fill non-message tx data fields with 0x0

2023-06-20 Thread Nishanth Menon
Sec proxy data buffer is 60 bytes with the last of the registers
indicating transmission completion. This however poses a bit of a
challenge.

The backing memory for sec_proxy is regular memory, and all sec proxy
does is to trigger a burst of all 60 bytes of data over to the target
thread backing ring accelerator. It doesn't do a memory scrub when
it moves data out in the burst. When we transmit multiple messages,
remnants of previous message is also transmitted which results in
some random data being set in TISCI fields of messages that have been
expanded forward.

The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.

So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).

This allows us to scale and introduce ABI changes back also work with
other boot stages that may have left data in the internal memory.

While at this, drop the unused accessor function.

Fixes: f9aa41023bd9 ("mailbox: Introduce K3 Secure Proxy Driver")
Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/k3-sec-proxy.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mailbox/k3-sec-proxy.c b/drivers/mailbox/k3-sec-proxy.c
index a862e55bc391..815808498f2e 100644
--- a/drivers/mailbox/k3-sec-proxy.c
+++ b/drivers/mailbox/k3-sec-proxy.c
@@ -94,11 +94,6 @@ static inline u32 sp_readl(void __iomem *addr, unsigned int 
offset)
return readl(addr + offset);
 }
 
-static inline void sp_writel(void __iomem *addr, unsigned int offset, u32 data)
-{
-   writel(data, addr + offset);
-}
-
 /**
  * k3_sec_proxy_of_xlate() - Translation of phandle to channel
  * @chan:  Mailbox channel
@@ -241,15 +236,20 @@ static int k3_sec_proxy_send(struct mbox_chan *chan, 
const void *data)
/* Ensure all unused data is 0 */
data_trail &= 0x >> (8 * (sizeof(u32) - trail_bytes));
writel(data_trail, data_reg);
-   data_reg++;
+   data_reg += sizeof(u32);
}
 
/*
 * 'data_reg' indicates next register to write. If we did not already
 * write on tx complete reg(last reg), we must do so for transmit
+* In addition, we also need to make sure all intermediate data
+* registers(if any required), are reset to 0 for TISCI backward
+* compatibility to be maintained.
 */
-   if (data_reg <= (spt->data + spm->desc->data_end_offset))
-   sp_writel(spt->data, spm->desc->data_end_offset, 0);
+   while (data_reg <= (spt->data + spm->desc->data_end_offset)) {
+   writel(0x0, data_reg);
+   data_reg += sizeof(u32);
+   }
 
debug("%s: Message successfully sent on thread %ld\n",
  __func__, chan->id);
-- 
2.40.0



Re: [PATCH] rockchip: Pinebook Pro: Fix emmc default configuration

2023-06-20 Thread Vagrant Cascadian
On 2023-05-01, Wolfgang Zarre wrote:
> If u-boot is installed on the internal emmc, then this will
> allow to boot without failure.
>
> Signed-off-by: Wolfgang Zarre 
> Reviewed-by: Kever Yang 

This is marked as accepted in patchwork, but I do not see it in git
yet...

Is this planned to land in 2023.07(-rc5?)?

Thanks!

live well,
  vagrant

>  configs/pinebook-pro-rk3399_defconfig | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/configs/pinebook-pro-rk3399_defconfig 
> b/configs/pinebook-pro-rk3399_defconfig
> index dff4695e37..58a8b91aa6 100644
> --- a/configs/pinebook-pro-rk3399_defconfig
> +++ b/configs/pinebook-pro-rk3399_defconfig
> @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> +CONFIG_SF_DEFAULT_SPEED=2000
>  CONFIG_ENV_SIZE=0x8000
>  CONFIG_ENV_OFFSET=0x3F8000
>  CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro"
> @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400
>  CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI=y
>  CONFIG_SYS_LOAD_ADDR=0x800800
> +CONFIG_PCI=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_BOOTDELAY=3
>  CONFIG_USE_PREBOOT=y
> @@ -57,17 +59,23 @@ CONFIG_LED=y
>  CONFIG_LED_GPIO=y
>  CONFIG_MISC=y
>  CONFIG_ROCKCHIP_EFUSE=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_SPL_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_SPL_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_SUPPORT=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_ROCKCHIP=y
>  CONFIG_SF_DEFAULT_BUS=1
> -CONFIG_SF_DEFAULT_SPEED=2000
>  CONFIG_SPI_FLASH_GIGADEVICE=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_NVME_PCI=y
> -CONFIG_PCI=y
>  CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>  CONFIG_PHY_ROCKCHIP_TYPEC=y
>  CONFIG_DM_PMIC_FAN53555=y


signature.asc
Description: PGP signature


[PATCH] doc: statistics: Re-generate the last 3 releases

2023-06-20 Thread Tom Rini
With some changes to our mapping files in gitdm, re-generate the last
few releases worth of statistics to correctly reflect contributions. We
only go back this far to try and find a balance between highlighting
contributions and still being reviewable.

Signed-off-by: Tom Rini 
---
 .../statistics/u-boot-stats-v2022.10.rst  | 27 +-
 .../statistics/u-boot-stats-v2023.01.rst  | 52 ++-
 .../statistics/u-boot-stats-v2023.04.rst  | 27 +-
 3 files changed, 54 insertions(+), 52 deletions(-)

diff --git a/doc/develop/statistics/u-boot-stats-v2022.10.rst 
b/doc/develop/statistics/u-boot-stats-v2022.10.rst
index 6fb71d4753e8..7a5fc2edc7c2 100644
--- a/doc/develop/statistics/u-boot-stats-v2022.10.rst
+++ b/doc/develop/statistics/u-boot-stats-v2022.10.rst
@@ -607,20 +607,21 @@ Release Statistics for U-Boot v2022.10
  =
Name  Count
  =
-   (Unknown) 590 (38.8%)
+   (Unknown) 584 (38.4%)
Konsulko Group265 (17.4%)
Google, Inc.  141 (9.3%)
NXP   77 (5.1%)
+   AMD   70 (4.6%)
ST Microelectronics   67 (4.4%)
Linaro60 (3.9%)
Texas Instruments 56 (3.7%)
-   AMD   53 (3.5%)
DENX Software Engineering 45 (3.0%)
Toradex   45 (3.0%)
Weidmüller Interface GmbH & Co. KG41 (2.7%)
-   Xilinx29 (1.9%)
Amarula Solutions 18 (1.2%)
+   Xilinx12 (0.8%)
ARM   11 (0.7%)
+   Collabora Ltd.7 (0.5%)
BayLibre SAS  5 (0.3%)
SUSE  4 (0.3%)
Socionext Inc.3 (0.2%)
@@ -628,7 +629,6 @@ Release Statistics for U-Boot v2022.10
IBM   2 (0.1%)
Siemens   2 (0.1%)
Broadcom  1 (0.1%)
-   Collabora Ltd.1 (0.1%)
Debian.org1 (0.1%)
Marvell   1 (0.1%)
Samsung   1 (0.1%)
@@ -642,7 +642,7 @@ Release Statistics for U-Boot v2022.10
Name  Count
  =
Konsulko Group98915 (47.3%)
-   (Unknown) 36773 (17.6%)
+   (Unknown) 36630 (17.5%)
Toradex   20197 (9.7%)
NXP   11759 (5.6%)
Google, Inc.  8739 (4.2%)
@@ -651,12 +651,13 @@ Release Statistics for U-Boot v2022.10
Texas Instruments 5930 (2.8%)
ST Microelectronics   3803 (1.8%)
DENX Software Engineering 3551 (1.7%)
-   AMD   2343 (1.1%)
+   AMD   2591 (1.2%)
Amarula Solutions 1360 (0.7%)
-   Xilinx1016 (0.5%)
+   Xilinx768 (0.4%)
Broadcom  315 (0.2%)
ARM   298 (0.1%)
BayLibre SAS  197 (0.1%)
+   Collabora Ltd.144 (0.1%)
SUSE  79 (0.0%)
IBM   34 (0.0%)
Bootlin   32 (0.0%)
@@ -665,7 +666,6 @@ Release Statistics for U-Boot v2022.10
Debian.org4 (0.0%)
Marvell   3 (0.0%)
Samsung   2 (0.0%)
-   Collabora Ltd.1 (0.0%)
  =
 
 
@@ -677,13 +677,14 @@ Release Statistics for U-Boot v2022.10
  =
AMD   81 (30.5%)
NXP   51 (19.2%)
-   (Unknown) 33 (12.4%)
+   (Unknown) 28 (10.5%)
Texas Instruments 19 (7.1%)
Linaro16 (6.0%)
ARM   16 (6.0%)
Amarula Solutions 14 (5.3%)
Xilinx13 (4.9%)
Konsulko Group6 (2.3%)
+   Canonical 5 (1.9%)
Toradex   4 (1.5%)
Google, Inc.  4 (1.5%)
Socionext Inc.

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Marek Vasut

On 6/20/23 19:49, Detlev Casanova wrote:

On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:

On 6/19/23 20:27, Detlev Casanova wrote:

On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:

On 6/19/23 16:42, Detlev Casanova wrote:

On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:

On 6/16/23 17:21, Detlev Casanova wrote:

Expose that information to the command shell to let scripts select the
correct devicetree name.

Signed-off-by: Detlev Casanova 
---

 drivers/sysinfo/rcar3.c | 46
 -
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index 7b127986da7..89ad46c5422 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -32,6 +32,8 @@

  */
 
 struct sysinfo_rcar_priv {
 
 	char	boardmodel[64];


+   u8  id;
+   charrevision[4];

u8  val;
 
 };


@@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
*dev,
int id, size_t size, char *>

switch (id) {

case SYSINFO_ID_BOARD_MODEL:
-   strncpy(val, priv->boardmodel, size);
-   val[size - 1] = '\0';
+   strlcpy(val, priv->boardmodel, size);
+   break;
+   case SYSINFO_ID_BOARD_REVISION:
+   strlcpy(val, priv->revision, size);
+   break;
+   default:
+   return -EINVAL;
+   };
+
+   val[size - 1] = '\0';
+   return 0;
+}
+
+static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
*val)
+{
+   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+   switch (id) {
+   case SYSINFO_ID_BOARD_ID:
+   *val = priv->id;

return 0;


Why not return SYSINFO_ID_BOARD_REVISION as integer here ?


Because the revision (on r-car3 boards at least) is in the format X.Y.
It
could be returned as "(X << 8) | Y" or split in major/minor. But
different
boards will use different revisions and I think that having a str is
easier to deal with in a shell script.


With rcar they are numbers, so lets go with major/minor integers please.


Ok for this part, but shouldn't the sysinfo command use a common interface
for all boards ? Or should it also have rev_major/rev_minor arguments ?

I would expect other boards to either report rev_major/rev_minor if
implemented, or errno if those boards don't implement this property.


Another thing on rcar is that the revision is stored as 2 char values. Would
you oppose a change form using a char (e.g. rev_major = '1') to using u8
values (e.g. rev_major = 1) instead ?


Shouldn't those rev fields just be integer(s) to cover the generic case?


Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Detlev Casanova
On Tuesday, June 20, 2023 4:03:18 P.M. EDT Marek Vasut wrote:
> On 6/20/23 19:49, Detlev Casanova wrote:
> > On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:
> >> On 6/19/23 20:27, Detlev Casanova wrote:
> >>> On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:
>  On 6/19/23 16:42, Detlev Casanova wrote:
> > On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:
> >> On 6/16/23 17:21, Detlev Casanova wrote:
> >>> Expose that information to the command shell to let scripts select
> >>> the
> >>> correct devicetree name.
> >>> 
> >>> Signed-off-by: Detlev Casanova 
> >>> ---
> >>> 
> >>>  drivers/sysinfo/rcar3.c | 46
> >>>  -
> >>>  1 file changed, 36 insertions(+), 10 deletions(-)
> >>> 
> >>> diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
> >>> index 7b127986da7..89ad46c5422 100644
> >>> --- a/drivers/sysinfo/rcar3.c
> >>> +++ b/drivers/sysinfo/rcar3.c
> >>> @@ -32,6 +32,8 @@
> >>> 
> >>>   */
> >>>  
> >>>  struct sysinfo_rcar_priv {
> >>>  
> >>>   charboardmodel[64];
> >>> 
> >>> + u8  id;
> >>> + charrevision[4];
> >>> 
> >>>   u8  val;
> >>>  
> >>>  };
> >>> 
> >>> @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
> >>> *dev,
> >>> int id, size_t size, char *>
> >>> 
> >>>   switch (id) {
> >>> 
> >>>   case SYSINFO_ID_BOARD_MODEL:
> >>> - strncpy(val, priv->boardmodel, size);
> >>> - val[size - 1] = '\0';
> >>> + strlcpy(val, priv->boardmodel, size);
> >>> + break;
> >>> + case SYSINFO_ID_BOARD_REVISION:
> >>> + strlcpy(val, priv->revision, size);
> >>> + break;
> >>> + default:
> >>> + return -EINVAL;
> >>> + };
> >>> +
> >>> + val[size - 1] = '\0';
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
> >>> *val)
> >>> +{
> >>> + struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
> >>> +
> >>> + switch (id) {
> >>> + case SYSINFO_ID_BOARD_ID:
> >>> + *val = priv->id;
> >>> 
> >>>   return 0;
> >> 
> >> Why not return SYSINFO_ID_BOARD_REVISION as integer here ?
> > 
> > Because the revision (on r-car3 boards at least) is in the format X.Y.
> > It
> > could be returned as "(X << 8) | Y" or split in major/minor. But
> > different
> > boards will use different revisions and I think that having a str is
> > easier to deal with in a shell script.
>  
>  With rcar they are numbers, so lets go with major/minor integers
>  please.
> >>> 
> >>> Ok for this part, but shouldn't the sysinfo command use a common
> >>> interface
> >>> for all boards ? Or should it also have rev_major/rev_minor arguments ?
> >> 
> >> I would expect other boards to either report rev_major/rev_minor if
> >> implemented, or errno if those boards don't implement this property.
> > 
> > Another thing on rcar is that the revision is stored as 2 char values.
> > Would you oppose a change form using a char (e.g. rev_major = '1') to
> > using u8 values (e.g. rev_major = 1) instead ?
> 
> Shouldn't those rev fields just be integer(s) to cover the generic case?

On rcar, they are chars. I don't really see a reason for this except to show 
the '?.?' on unknown board ids. But that can be managed in other ways.





Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Tom Rini
On Tue, Jun 20, 2023 at 08:36:11AM +0200, Michal Simek wrote:
> 
> 
> On 6/19/23 19:04, Eugen Hristev wrote:
> > On 6/19/23 19:07, Marek Vasut wrote:
> > > On 6/19/23 15:26, Eugen Hristev wrote:
> > > > On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:
> > > > > [ Felipe: Ported from Linux kernel commit
> > > > >   f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
> > > > > 
> > > > > According to Synopsys Databook, we shouldn't be relying on
> > > > > GCTL.CORESOFTRESET bit as that's only for debugging purposes.
> > > > > Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
> > > > > 
> > > > > Host side block will be reset by XHCI driver if necessary. Note that 
> > > > > this
> > > > > reduces amount of time spent on dwc3_probe() by a long margin.
> > > > > 
> > > > > We're still gonna wait for reset to finish for a long time
> > > > > (default to 1ms max), but tests show that the reset polling loop 
> > > > > executed
> > > > > at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
> > > > > times in a row).
> > > > > 
> > > > > Without proper core reset, observing random issues like when the
> > > > > USB(DWC3) is in device mode, the host device is not able to detect the
> > > > > USB device.
> > > > > 
> > > > > Signed-off-by: Venkatesh Yadav Abbarapu 
> > > > > ---
> > > > >   drivers/usb/dwc3/core.c | 50 
> > > > > +++--
> > > > >   1 file changed, 18 insertions(+), 32 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > > > index 49f6a1900b..8702a54efa 100644
> > > > > --- a/drivers/usb/dwc3/core.c
> > > > > +++ b/drivers/usb/dwc3/core.c
> > > > > @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 
> > > > > mode)
> > > > >   static int dwc3_core_soft_reset(struct dwc3 *dwc)
> > > > >   {
> > > > >   u32    reg;
> > > > > +    int    retries = 1000;
> > > > > -    /* Before Resetting PHY, put Core in Reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > > > > -    reg |= DWC3_GCTL_CORESOFTRESET;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > > > -
> > > > > -    /* Assert USB3 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> > > > > -    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> > > > > -
> > > > > -    /* Assert USB2 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > > > > -    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > > > > -
> > > > > -    mdelay(100);
> > > > > -
> > > > > -    /* Clear USB3 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> > > > > -    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> > > > > -
> > > > > -    /* Clear USB2 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > > > > -    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > > > > +    /*
> > > > > + * We're resetting only the device side because, if we're in 
> > > > > host mode,
> > > > > + * XHCI driver will reset the host block. If dwc3 was configured 
> > > > > for
> > > > > + * host-only mode, then we can return early.
> > > > > + */
> > > > > +    if (dwc->dr_mode == USB_DR_MODE_HOST)
> > > > > +    return 0;
> > > > > -    mdelay(100);
> > > > > +    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > > > > +    reg |= DWC3_DCTL_CSFTRST;
> > > > > +    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
> > > > > -    /* After PHYs are stable we can take Core out of reset state */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > > > > -    reg &= ~DWC3_GCTL_CORESOFTRESET;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > > > +    do {
> > > > > +    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > > > > +    if (!(reg & DWC3_DCTL_CSFTRST))
> > > > > +    return 0;
> > > > > +    udelay(1);
> > > > > +    } while (--retries);
> > > > > -    return 0;
> > > > > +    return -ETIMEDOUT;
> > > > >   }
> > > > >   /*
> > > > 
> > > > Hello Venkatesh, Michal,
> > > > 
> > > > I randomly found this patch while testing the Dwc3 on rockchip
> > > > RK3588 , I noticed that you removed the code that resets the
> > > > PHYs in this patch hence DWC3 is no longer starting in my case.
> > > > Was this intentional with this patch ?
> > > 
> > > All of these patches are NAK until the DWC3 is synchronized with
> > > Linux. Picking random DWC3 patches and ignoring other fixes will
> > > turn the whole driver into an unmaintainable mess and make the sync
> > > that much harder in the future. I spent enormous amount of my spare
> > > time trying to explain to Xilinx how to do that mostly
> > > automatically, but that was all ignored or countered with reason
> > > af

Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Marek Vasut

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
  drivers/usb/host/dwc2.c | 34 --
  drivers/usb/host/dwc2.h |  4 
  2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
  
  	/* Turn on the vbus power. */

if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(®s->hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, ®s->hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
  
  		case USB_PORT_FEAT_RESET:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_POWER:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_ENABLE:

@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
  
-	clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |

-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
  
  	for (i = 0; i < MAX_DEVICE; i++) {

for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
  static void dwc2_uninit_common(struct dwc2_core_regs *regs)
  {
/* Put everything in reset. */
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
  }
  
  #if !CONFIG_IS_ENABLED(DM_USB)

diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
  #define DWC2_HPRT0_PRTSPD_LOW (2 << 17)
  #define DWC2_HPRT0_PRTSPD_MASK(0x3 << 17)
  #define DWC2_HPRT0_PRTSPD_OFFSET  17
+#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET 
| \
+   DWC2_HPRT0_PRTENA | \
+   DWC2_HPRT0_PRTENCH

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-20 Thread Sam Edwards

Hi Andre,

On 6/20/23 06:42, Andre Przywara wrote:

So yeah, the request of a "Enter FEL" command came up multiple times, but
so far no one could be bothered to implement this properly. The idea would
be to have a generic command (more like "fel-reset" than efex), and
allow each SoC (family) to implement this differently, as every
SoC requires something a bit different here (32-bit vs. 64-bit, having an
RTC vs not, etc).

If you could post your solution somewhere, we could start this effort.
There was some patch for the H3 already, and it's relatively
straight-forward on the newer SoCs (H616, IIRC), so if at least two
popular, but different SoCs would be supported, we could make sure to have
the right abstractions in place.


I already have a "go_to_fel()" that does the right thing to enter FEL 
from the SPL; I would pretty much just need to introduce the following 
per-SoC(-family) functions:

- bool sunxi_fel_flag_test(void)
- void sunxi_fel_flag_clear(void)
- void sunxi_fel_flag_set(void)

The "fel-reset" command (which is easier to type than what I have, "run 
fel_do_enter") would then call sunxi_fel_flag_set() and initiate a 
reset, and the SPL's early init just has to do sunxi_fel_flag_test() -> 
sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough.


Could you recommend to me a sufficiently different chip to test my 
abstractions against? Something ARMv8 and *without* RTC? I can then send 
in a series adding FEL support for that. (Also, did that H3 patch 
actually land? I didn't see anything but want to know if I should be 
refactoring my approach to extend what that H3 patch does or not.)



Ah, depending on the BSP kernel is indeed quite bad. I wonder what
features of the kernel you rely on that upstream does not have? Or is it
more about the BMC userland parts that are married to the Allwinner kernel
and its own interfaces?


I don't fully know; getting the kernel back on mainline is, as I said, a 
push for another day. I'm very much making a point of not looking into 
it before the bootloader can be upgraded to something that isn't a 
crashy, hard-to-update, failure-prone mess. (I'm working in "biggest 
fire, first out" order.)


That said, the first such dependent feature that leaps to mind is the 
AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically 
interleaves pages of the NAND in a different ordering vs. what the 
physical NAND (and mainline's spi-nand driver) does. Alas this is a 
feature we're dependent on not because it provides benefits to our users 
(it does not, and in downstream discussions I've been soapboxing about 
how it's likely wearing down people's NANDs) but because the boards are 
flashed at the factory with this flag enabled so we need it set for the 
NAND to be accessible. We've experimented with reflashing the board with 
that flag disabled, but that has so far only resulted in corrupted flash.


Hope is not lost, though, for I have a half-written tool which shows 
some promise in being able to "unscramble the egg" and migrate existing 
NANDs over to the correct layout. That should be sufficient to get 
mainline U-Boot (and Tina Linux with the flag disabled) working, but I 
have no idea about mainline Linux still: this would only peel back one 
layer of the onion, and I don't know whether the next obstacle will be 
easier, harder, or about the same difficulty.


But it does mean that, for now, we're stuck with Tina Linux.


Final DT is a noble goal, but in reality there will always be room for
improvement and additions. So what we typically do is to start with a
simple .dts for the kernel tree, describing the basic peripherals, and
everything that already works and is not subject to debate. If in doubt,
include a node, and we will comment. Could you prepare such a patch?


The peripheral-describing .dts that I have is for Tina Linux, and uses 
incompatible compatibles (ha), includes, dt-bindings, temporary hacks 
while better driver support can be developed, and would otherwise not 
fly upstream. I can send it in *anyway* if for some reason you think 
that's a good idea, but I really don't see that as being anything other 
than a waste of time.


As well, I can't write a fresh .dts for mainline (one more likely to be 
accepted on the list). A mainline kernel has never been booted on this 
board, so I would do no better at this than a kernel contributor 
selected at random. The best I can do now is write something that 
*looks* like the correct .dts.


As I keep saying, that may change in the future. But the answer today is 
still "no, I cannot."



This
should not contradict any DT nodes that U-Boot uses, so it's not a double
effort.


True, in theory it *shouldn't* but in practice, I've found it does.

One way I've been bitten is that the sunxi SPI driver in U-Boot doesn't 
support Quad-SPI, so if the DT says the SPI-NAND is connected with a bus 
width of 4, the SPI-NAND driver requests Quad-SPI transfers, but the SPI 
master driver has no idea tha

Re: imx8m optee load address?

2023-06-20 Thread Tim Harvey
On Mon, Jun 19, 2023 at 1:40 PM Tim Harvey  wrote:
>
> On Fri, Jun 16, 2023 at 4:52 PM Tim Harvey  wrote:
> >
> > On Thu, Jun 15, 2023 at 8:31 PM Peng Fan  wrote:
> > >
> > >
> > >
> > > On 6/16/2023 9:56 AM, Tim Harvey wrote:
> > > > Greetings,
> > > >
> > > > I've seen several IMX8M boards include a firmware/optee node in the
> > > > U-Boot dt (git grep optee arch/arm/dts/imx8m*.dtsi) yet but none that
> > > > I see configure binman to actually add the binary in the u-boot.dtsi,
> > > > do anything to keep U-Boot from accessing the OPTEE memory, or
> > > > document how to configure and build OPTEE for imx8m. I would like to
> > > > add such support but I find it odd that OPTEE needs to be built
> > > > differently depending on the dram size.
> > > >
> > > > Prior to switching to binman (v2021.10)
> > > > arch/arm/mach-imx/mkimage_fit_atf.sh [1] would include tee.bin in the
> > > > FIT image if it was found in the current directory and it was expected
> > > > that you provide a proper TEE_LOAD_ADDR via the env (commit
> > > > a9eed6e1b8d8 ("imx: imx8m: introduce script to generate fit image").
> > > >
> > > > According to the IMX OPTEE documentation [2] the size and location of
> > > > OPTEE is hard coded (CFG_TZDRAM_START and CFG_TZDRAM_SIZE) but looking
> > > > at the imx-optee source [3] this is calculated based off of
> > > > CFG_DDR_SIZE (which you can provide via env at build time or just
> > > > provide CFG_TZDRAM_START and CFG_TZDRAM_SIZE via env directly).
> > >
> > > optee does not support PIE, it could only run at the address that built
> > > time defined.
> >
> > Hi Peng,
> >
> > I wasn't thinking about PIE but just building it at a location other
> > than the top of DRAM in order to come up with a generalized location
> > instead of having to customize u-boot.dtsi for different RAM sizes and
> > to workaround the 4GiB boundary issue.
> >
> > If my understanding is correct optee's load address needs to match between:
> > 1. atf: BL32_BASE at build time defines the address in secure memory
> > where BL2 loads the BL32 binary image (tee.bin) (must be aligned on a
> > page-size boundary)
> > 2. optee: CFG_TZDRAM_START at build time (calculated based off of
> > CFG_DDR_SIZE) defines the address it is built to run at. Note you must
> > still define CFG_DDR_SIZE properly as this is passed to
> > imx_tzc_auto_configure()
> > 3. uboot: tee.bin is contained in u-boot.itb FIT image and specifies
> > the address that U-Boot SPL loads tee.bin into
> >
> > I'm really trying to understand the imx8m 4GiB limit issue as that
> > seems to be a huge limiation.
>
> Peng,
>
> I've made good progress and now have a 4GiB imx8mm board working with
> optee (with 1 hack):
>
> >
> > On an imx8mm board with 4GiB of DRAM configured with
> > atf:BL32_BASE=0x13e00
> > optee:CFG_DDR_SIZE=0x1,CFG_TZDRAM_START=0x13e00 and
> > u-boot.dtsi tee.bin load/entry=<0x1 0x3e00> we get this:
> >
> > U-Boot SPL 2023.04-00027-g578c653cbafa (Jun 16 2023 - 09:22:40 -0700)
> > GSCv3   : v58 0xf098 RST:VIN Thermal protection:disabled
> > RTC : 1970-01-01   0:05:40 UTC
> > Model   : GW7201-01-EB
> > Serial  : 852455
> > MFGDate : 11-10-2020
> > PMIC: MP5416 (IMX8MM)
> > DRAM: LPDDR4 4 GiB 3000MT/s 1500MHz
> > WDT:   Started watchdog@3028 with servicing every 1000ms (60s timeout)
> > Trying to boot from eMMC
> > DTB : imx8mm-venice-gw72xx-0x
> > Cannot use 64 bit addresses with SDMA
> > ^^^ This is the imx mmc driver warning that it can't load data into
> > dram across 32bit boundary
> >
> > Authenticate image from DDR location 0x401fcdc0...
> > NOTICE:  Do not release JR0 to NS as it can be used by HAB
> > ERROR:   mmap_add_region_check() failed. error -34
> > ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:793
> > BACKTRACE: START: assert
> > 0: EL3: 0x9289cc
> > 1: EL3: 0x929efc
> > 2: EL3: 0x92469c
> > 3: EL3: 0x9248f4
> > 4: EL3: 0x928850
> > 5: EL3: 0x927594
> > 6: EL3: 0x920128
> > 7: EL3: 0x7eb19c
> > 8: EL3: 0x7f3de0
> > BACKTRACE: END: assert
> >
> > This is where the atf jumps to optee so I can understand why the above
> > doesn't work as U-Boot can't load tee.bin from the FIT to 0x13e00
> > (not sure where it gets loaded... the 64bit address probably wraps).
> > I've also tried setting CFG_CORE_LARGE_PHYS_ADDR=y and
> > CFG_CORE_ARM64_PA_BITS=36 in optee as this is what the imx8mp-evk
> > config with 6GiB does and it ended with the same result but I do
> > notice that doing this changes the link address
>
> The issue above appears to be a result of not setting
> CFG_CORE_LARGE_PHYS_ADDR=y and CFG_CORE_ARM64_PA_BITS=36 in optee when
> CFG_DDR_SIZE exceeds 3GiB.
>
> >
> > The imx8mp-evk has 6GiB of dram on it. Does NXP not have a solution
> > for secure boot on boards with >3GiB of dram?  Is there some support
> > in their downstream U-Boot that I'm maybe missing? Personally I can't
> > even get NXP's lf_v2022.04 u-boot branch to build flash.bin for
> > imx8mp_evk so I can try it out.
>
> The

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut

On 6/20/23 12:43, Xavier Drudis Ferran wrote:

El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia:


Default, see:
$ git grep CONFIG_BOOTCOMMAND configs/



I'm lost.

I called default what Kconfig used as default.
You seem to call default what's in board specific config files.
Whatever. Fix the wording in the commit message if you like.


All I am really asking for is minimal test case.
That is all I was asking for since the very beginning.

So to answer my own question, this is the minimal test case:

=> usb reset ; bootflow scan ; usb info

Can you please add it to the commit message, collect RB from Simon, add

Reviewed-by: Marek Vasut 
Tested-by: Marek Vasut 

And send V2 so I can pick it for this release ?

Thank you


[PATCH] arm: mvebu: Enable gpio-fan for Thecus N2350 board

2023-06-20 Thread Tony Dinh
Add gpio-fan in the DTS and enable the GPIO in board file to start the fan
during boot.

Note that this patch depends on
https://patchwork.ozlabs.org/project/uboot/patch/20230606214539.4229-1-mibo...@gmail.com/

Signed-off-by: Tony Dinh 
---

 arch/arm/dts/armada-385-thecus-n2350.dts | 15 +++
 board/thecus/n2350/n2350.c   |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts 
b/arch/arm/dts/armada-385-thecus-n2350.dts
index 2ad5158c0c..253cf01130 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -140,6 +140,16 @@
};
};
 
+   fan {
+   compatible = "gpio-fan";
+   gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+   gpio-fan,speed-map = <0  0
+   600  1
+   3000 2 >;
+   pinctrl-0 = <&pmx_fan>;
+   pinctrl-names = "default";
+   };
+
usb3_0_power: v5-vbus0 {
compatible = "regulator-fixed";
regulator-name = "USB3_0_Power";
@@ -378,6 +388,11 @@
marvell,pins = "mpp17";
marvell,function = "gpio";
};
+
+   pmx_fan: pmx-fan {
+   marvell,pins = "mpp48";
+   marvell,function = "gpio";
+   };
 };
 
 &sdhci {
diff --git a/board/thecus/n2350/n2350.c b/board/thecus/n2350/n2350.c
index fd8f95f944..05b125fd7f 100644
--- a/board/thecus/n2350/n2350.c
+++ b/board/thecus/n2350/n2350.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define N2350_GPP_OUT_ENA_LOW  (~(BIT(20) | BIT(21) | BIT(24)))
 #define N2350_GPP_OUT_ENA_MID  (~(BIT(12) | BIT(13) | BIT(16) | BIT(19) | 
BIT(22)))
 #define N2350_GPP_OUT_VAL_LOW  (BIT(21) | BIT(24))
-#define N2350_GPP_OUT_VAL_MID  (BIT(0) | BIT(12) | BIT(13))
+#define N2350_GPP_OUT_VAL_MID  (BIT(0) | BIT(12) | BIT(13) | BIT(16))
 #define N2350_GPP_POL_LOW  0x0
 #define N2350_GPP_POL_MID  0x0
 
-- 
2.39.2



RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Chong, Teik Heng
-Original Message-
From: Marek Vasut  
Sent: Wednesday, 21 June, 2023 5:38 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R ; Simon 
; Kris ; Chee, Tien 
Fong ; Hea, Kok Kiang ; 
Lokanathan, Raaj ; Maniyam, Dinesh 
; Ng, Boon Khai ; Yuslaimi, 
Alif Zakuan ; Zamri, Muhammad Hazim Izzat 
; Lim, Jit Loon ; 
Tang, Sieu Mun ; Patrice CHOTARD 
; Patrick DELAUNAY 
Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT 
register

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:
> From: Teik Heng Chong 
> 
> Fix the write to the HPRT register which treat W1C fields as if they 
> were mere RW. This leads to unintended clearing of such fields
> 
> Signed-off-by: Teik Heng Chong 
> 
> ---
> 
> V1->V2
> - update subject tags to usb:dwc2
> ---
>   drivers/usb/host/dwc2.c | 34 --
>   drivers/usb/host/dwc2.h |  4 
>   2 files changed, 12 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 
> 23060fc369..9818f9be94 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice 
> *dev,
>   
>   /* Turn on the vbus power. */
>   if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
> - hprt0 = readl(®s->hprt0);
> - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
> - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
> + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
>   if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
>   hprt0 |= DWC2_HPRT0_PRTPWR;
>   writel(hprt0, ®s->hprt0);
> @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
> *priv,
>   case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
>   switch (wValue) {
>   case USB_PORT_FEAT_C_CONNECTION:
> - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTCONNDET);
>   break;
>   }
>   break;
> @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
> *priv,
>   break;
>   
>   case USB_PORT_FEAT_RESET:
> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET |
> - DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   mdelay(50);
> - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
> + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | 
> +DWC2_HPRT0_PRTRST);
>   break;
>   
>   case USB_PORT_FEAT_POWER:
> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET |
> - DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   break;
>   
>   case USB_PORT_FEAT_ENABLE:
> @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, 
> struct dwc2_priv *priv)
>   dwc_otg_core_host_init(dev, regs);
>   }
>   
> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   mdelay(50);
> - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
> -  DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
> -  DWC2_HPRT0_PRTRST);
> + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
>   
>   for (i = 0; i < MAX_DEVICE; i++) {
>   for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ 
> static 
> int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>   static void dwc2_uninit_common(struct dwc2_core_regs *regs)
>   {
>   /* Put everything in reset. */
> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   }
>   
>   #if !CONFIG_IS_ENABLED(DM_USB)
> diff --git

Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Marek Vasut

On 6/21/23 02:57, Chong, Teik Heng wrote:

-Original Message-
From: Marek Vasut 
Sent: Wednesday, 21 June, 2023 5:38 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; 
Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh 
; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat 
; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD 
; Patrick DELAUNAY 
Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT 
register

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields as if they
were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
   drivers/usb/host/dwc2.c | 34 --
   drivers/usb/host/dwc2.h |  4 
   2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice
*dev,
   
   	/* Turn on the vbus power. */

if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(®s->hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, ®s->hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
   
   		case USB_PORT_FEAT_RESET:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK |
+DWC2_HPRT0_PRTRST);
break;
   
   		case USB_PORT_FEAT_POWER:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
break;
   
   		case USB_PORT_FEAT_ENABLE:

@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
   
-	clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |

-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
   
   	for (i = 0; i < MAX_DEVICE; i++) {

for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ 
static
int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
   static void dwc2_uninit_common(struct dwc2_core_regs *regs)
   {
/* Put everything in reset. */
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
   }
   
   #if !CONFIG_IS_ENABLED(DM_USB)

diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index
a6f562fe60..6f022e33a1 100644
--- 

Re: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux

2023-06-20 Thread Rick Chen
> From: Conor Dooley 
> Sent: Thursday, June 15, 2023 6:13 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; Padmarao Begari ; 
> Conor Dooley 
> Subject: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux
>
> The "notable" disappearances are:
> - the pac193x stanza - there's nothing in mainline linux w.r.t. bindings
>   for this & what is going to appear in mainline linux is going to be
>   incompatible with what is currently in U-Boot.
> - operating points - these operating points should not be set at the
>   soc.dtsi level as they may not be possible depending on the design
>   programmed to the FPGA
> - clock output names - there are defines for the clock indices, these
>   should not be needed
> - the dt maintainers in linux NAKed using defines for IRQ numbers
> - the qspi nand, which is not part of the icicle's default configuration
>   is removed.
>
> Reviewed-by: Padmarao Begari 
> Tested-by: Padmarao Begari 
> Signed-off-by: Conor Dooley 
> ---
>  arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi|  71 +++
>  arch/riscv/dts/mpfs-icicle-kit.dts| 190 +---
>  arch/riscv/dts/mpfs.dtsi  | 442 --
>  .../dt-bindings/clock/microchip-mpfs-clock.h  |  29 +-
>  .../microchip-mpfs-plic.h | 196 
>  .../interrupt-controller/riscv-hart.h |  17 -

Reviewed-by: Rick Chen 


Re: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 1.2A and 1.3B

2023-06-20 Thread Rick Chen
> From: Yanhong Wang 
> Sent: Thursday, June 15, 2023 5:37 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo 
> Yu-Chi Liang(梁育齊) ; Joe Hershberger 
> ; Ramon Fried 
> Cc: Yanhong Wang ; Torsten Duwe ; 
> Leyfoon Tan ; samin . guo 
> ; Walker Chen ; Hal 
> Feng 
> Subject: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 
> 1.2A and 1.3B
>
> The main difference between StarFive VisionFive 2 1.2A and 1.3B is gmac.
> You can read the PCB version of the current board by 
> get_pcb_revision_from_eeprom(), and then dynamically configure the difference 
> of gmac in spl_perform_fixups() according to different PCB versions, so that 
> one DT and one defconfig can support both 1.2A and 1.3B versions, which is 
> more user-friendly.
>
> Signed-off-by: Yanhong Wang 
> ---
>  board/starfive/visionfive2/spl.c | 157 +++
>  1 file changed, 157 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM

2023-06-20 Thread Rick Chen
> From: Yanhong Wang 
> Sent: Thursday, June 15, 2023 5:37 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo 
> Yu-Chi Liang(梁育齊) ; Joe Hershberger 
> ; Ramon Fried 
> Cc: Yanhong Wang ; Torsten Duwe ; 
> Leyfoon Tan ; samin . guo 
> ; Walker Chen ; Hal 
> Feng 
> Subject: [PATCH v5 10/11] ram: starfive: Read memory size information from 
> EEPROM
>
> StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of DDR 
> capacity includes 2G/4G/8G, a DT can not support multiple capacities, so the 
> capacity size information is recorded to EEPROM, when DDR initialization 
> required capacity size information is read from EEPROM.
>
> If there is no information in EEPROM, it is initialized with the default size 
> defined in DT.
>
> Signed-off-by: Yanhong Wang 
> ---
>  arch/riscv/cpu/jh7110/spl.c | 32 -
>  drivers/ram/starfive/starfive_ddr.c |  2 --
>  2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c index 
> 104f0fe949..72adcefa0e 100644
> --- a/arch/riscv/cpu/jh7110/spl.c
> +++ b/arch/riscv/cpu/jh7110/spl.c
> @@ -3,19 +3,49 @@
>   * Copyright (C) 2022 StarFive Technology Co., Ltd.
>   * Author: Yanhong Wang
>   */
> -
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>
>  #define CSR_U74_FEATURE_DISABLE0x7c1
>  #define L2_LIM_MEM_END 0x81FUL
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static bool check_ddr_size(phys_size_t size) {
> +   switch (size) {
> +   case SZ_2:
> +   case SZ_4:
> +   case SZ_8:
> +   case SZ_16:

In commit message, it describes that "DDR capacity includes 2G/4G/8G".
Is it mismatch here ?

> +   return true;
> +   default:
> +   return false;
> +   }
> +}
> +
>  int spl_soc_init(void)
>  {
> int ret;
> struct udevice *dev;
> +   phys_size_t size;
> +
> +   ret = fdtdec_setup_mem_size_base();
> +   if (ret)
> +   return ret;

It maybe unnecessary to add return above. If it fail to parse memory
node from DT, then there
has no chance to get ddr size from eeprom.

Thanks,
Rick

> +
> +   /* Read the definition of the DDR size from eeprom, and if not,
> +* use the definition in DT
> +*/
> +   size = (get_ddr_size_from_eeprom() >> 16) & 0xFF;
> +   if (check_ddr_size(size))
> +   gd->ram_size = size << 30;
>
> /* DDR init */
> ret = uclass_get_device(UCLASS_RAM, 0, &dev); diff --git 
> a/drivers/ram/starfive/starfive_ddr.c b/drivers/ram/starfive/starfive_ddr.c
> index 553f2ce6f4..a0a3d6b33d 100644
> --- a/drivers/ram/starfive/starfive_ddr.c
> +++ b/drivers/ram/starfive/starfive_ddr.c
> @@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev)
> u64 rate;
> int ret;
>
> -   /* Read memory base and size from DT */
> -   fdtdec_setup_mem_size_base();
> priv->info.base = gd->ram_base;
> priv->info.size = gd->ram_size;
>
> --
> 2.17.1


RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Chong, Teik Heng
> -Original Message-
> From: Marek Vasut 
> Sent: Wednesday, 21 June, 2023 9:20 AM
> To: Chong, Teik Heng ; u-boot@lists.denx.de
> Cc: Jagan Teki ; Vignesh R
> ; Simon ; Kris
> ; Chee, Tien Fong ; Hea,
> Kok Kiang ; Lokanathan, Raaj
> ; Maniyam, Dinesh
> ; Ng, Boon Khai ;
> Yuslaimi, Alif Zakuan ; Zamri, Muhammad
> Hazim Izzat ; Lim, Jit Loon
> ; Tang, Sieu Mun ;
> Patrice CHOTARD ; Patrick DELAUNAY
> 
> Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT
> register
> 
> On 6/21/23 02:57, Chong, Teik Heng wrote:
> > -Original Message-
> > From: Marek Vasut 
> > Sent: Wednesday, 21 June, 2023 5:38 AM
> > To: Chong, Teik Heng ; u-boot@lists.denx.de
> > Cc: Jagan Teki ; Vignesh R
> > ; Simon ; Kris
> > ; Chee, Tien Fong ;
> > Hea, Kok Kiang ; Lokanathan, Raaj
> > ; Maniyam, Dinesh
> > ; Ng, Boon Khai ;
> > Yuslaimi, Alif Zakuan ; Zamri,
> > Muhammad Hazim Izzat ; Lim,
> Jit
> > Loon ; Tang, Sieu Mun
> > ; Patrice CHOTARD
> > ; Patrick DELAUNAY
> > 
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in
> > HPRT register
> >
> > On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:
> >> From: Teik Heng Chong 
> >>
> >> Fix the write to the HPRT register which treat W1C fields as if they
> >> were mere RW. This leads to unintended clearing of such fields
> >>
> >> Signed-off-by: Teik Heng Chong 
> >>
> >> ---
> >>
> >> V1->V2
> >> - update subject tags to usb:dwc2
> >> ---
> >>drivers/usb/host/dwc2.c | 34 --
> >>drivers/usb/host/dwc2.h |  4 
> >>2 files changed, 12 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
> >> 23060fc369..9818f9be94 100644
> >> --- a/drivers/usb/host/dwc2.c
> >> +++ b/drivers/usb/host/dwc2.c
> >> @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice
> >> *dev,
> >>
> >>/* Turn on the vbus power. */
> >>if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
> >> -  hprt0 = readl(®s->hprt0);
> >> -  hprt0 &= ~(DWC2_HPRT0_PRTENA |
> DWC2_HPRT0_PRTCONNDET);
> >> -  hprt0 &= ~(DWC2_HPRT0_PRTENCHNG |
> DWC2_HPRT0_PRTOVRCURRCHNG);
> >> +  hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
> >>if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
> >>hprt0 |= DWC2_HPRT0_PRTPWR;
> >>writel(hprt0, ®s->hprt0);
> >> @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct
> dwc2_priv *priv,
> >>case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER |
> USB_TYPE_CLASS:
> >>switch (wValue) {
> >>case USB_PORT_FEAT_C_CONNECTION:
> >> -  setbits_le32(®s->hprt0,
> DWC2_HPRT0_PRTCONNDET);
> >> +  clrsetbits_le32(®s->hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTCONNDET);
> >>break;
> >>}
> >>break;
> >> @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct
> dwc2_priv *priv,
> >>break;
> >>
> >>case USB_PORT_FEAT_RESET:
> >> -  clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA
> |
> >> -  DWC2_HPRT0_PRTCONNDET |
> >> -  DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(®s->hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>mdelay(50);
> >> -  clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
> >> +  clrbits_le32(®s->hprt0,
> DWC2_HPRT0_W1C_MASK |
> >> +DWC2_HPRT0_PRTRST);
> >>break;
> >>
> >>case USB_PORT_FEAT_POWER:
> >> -  clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA
> |
> >> -  DWC2_HPRT0_PRTCONNDET |
> >> -  DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(®s->hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>break;
> >>
> >>case USB_PORT_FEAT_ENABLE:
> >> @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice
> *dev, struct dwc2_priv *priv)
> >>dwc_otg_core_host_init(dev, regs);
> >>}
> >>
> >> -  clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
> >> -  DWC2_HPRT0_PRTCONNDET |
> DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>mdelay(50);
> >> -  clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTE

[PATCH v3 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread teik . heng . chong
From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

This bug was found during the testing on Simics model. Referring to
specification DesignWare Cores USB 2.0 Hi-Speed On-The-Go (OTG)
Databook (3.30a)"5.3.4.8 Host Port Control and Status Register (HPRT)", the
HPRT.PrtPwr is cleared by this mistake. In the Linux driver (contrary to
U-Boot), HPRT is always read using dwc2_read_hprt0 helper function which
clears W1C bits. So after write back those bits are zeroes.

Signed-off-by: Teik Heng Chong 

---

V2->V3
- update commit message
---
 drivers/usb/host/dwc2.c | 34 --
 drivers/usb/host/dwc2.h |  4 
 2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
 
/* Turn on the vbus power. */
if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(®s->hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, ®s->hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
 
case USB_PORT_FEAT_RESET:
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_POWER:
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_ENABLE:
@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
 
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
 
for (i = 0; i < MAX_DEVICE; i++) {
for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
 static void dwc2_uninit_common(struct dwc2_core_regs *regs)
 {
/* Put everything in reset. */
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
 }
 
 #if !CONFIG_IS_ENABLED(DM_USB)
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
 #define DWC2_HPRT0_PRTSPD_LOW

[PATCH v1 00/17] Agilex5 Platform Enablement

2023-06-20 Thread Jit Loon Lim
Intel Agilex5 is a midrange FPGAs optimized for applications requiring high 
performance, 
lower power, and smaller form factors and lower logic densities. U-Boot is one 
of the 
bootloader to boot along with ARM trusted Firmware to boot the board up.

*** BLURB HERE ***

Jit Loon Lim (16):
  arch: arm: update kconfig for new platform agilex5
  arch: arm: dts: add dts and dtsi for new platform agilex5
  arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga
enablement
  arch: arm: mach-socfpga: include: mach: add new platform agilex5
mach-socfpga enablement
  board: intel: add new platform agilex5 socdk
  configs: add new platform agilex5 defconfig
  doc: device-tree-bindings: misc: add secreg text file for agilex5
  drivers: ddr: altera: add ddr support for agilex5
  drivers: clk: altera: add clock support for agilex5
  drivers: misc: update driver misc for agilex5
  drivers: mmc: add mmc/cadence driver for agilex5
  drivers: phy: add combo phy driver for agilex5
  drivers: reset: add reset driver for agilex5
  drivers: sysreset: add system driver for agilex5
  drivers: watchdog: update watchdog driver for agilex5
  includes: add and update configuration for agilex5

Sieu Mun Tang (1):
  tools: binman: update binman tool for agilex5

 arch/arm/Kconfig  |   5 +-
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_agilex5-u-boot.dtsi  | 459 ++
 arch/arm/dts/socfpga_agilex5.dtsi | 634 +
 .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 +++
 arch/arm/dts/socfpga_agilex5_socdk.dts| 165 
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi|  38 +-
 arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 +++
 arch/arm/dts/socfpga_stratix10.dtsi   |   0
 .../dts/socfpga_stratix10_socdk-u-boot.dtsi   |   0
 arch/arm/dts/socfpga_stratix10_socdk.dts  |   0
 arch/arm/mach-socfpga/Kconfig |  92 ++
 arch/arm/mach-socfpga/Makefile|  69 +-
 arch/arm/mach-socfpga/board.c |  65 +-
 arch/arm/mach-socfpga/clock_manager_agilex5.c |  82 ++
 arch/arm/mach-socfpga/firewall.c  | 107 ---
 .../include/mach/base_addr_soc64.h|  43 +-
 .../mach-socfpga/include/mach/clock_manager.h |   5 +-
 .../include/mach/clock_manager_agilex5.h  |  12 +
 arch/arm/mach-socfpga/include/mach/firewall.h |  42 +-
 .../mach-socfpga/include/mach/handoff_soc64.h |  25 +-
 .../mach-socfpga/include/mach/mailbox_s10.h   |  32 +-
 .../include/mach/reset_manager_soc64.h|  33 +-
 .../mach-socfpga/include/mach/smmu_agilex5.h  |  30 +
 arch/arm/mach-socfpga/include/mach/smmu_s10.h |  73 ++
 .../include/mach/system_manager_soc64.h   | 126 ++-
 arch/arm/mach-socfpga/include/mach/timer.h|  30 +
 arch/arm/mach-socfpga/lowlevel_init_agilex5.S |  61 ++
 arch/arm/mach-socfpga/lowlevel_init_soc64.S   | 167 +++-
 arch/arm/mach-socfpga/mailbox_s10.c   |  21 +
 arch/arm/mach-socfpga/misc.c  |  19 +-
 arch/arm/mach-socfpga/misc_soc64.c|  33 +-
 arch/arm/mach-socfpga/mmu-arm64_s10.c |  43 +-
 arch/arm/mach-socfpga/reset_manager_s10.c | 271 +-
 arch/arm/mach-socfpga/secure_reg_helper.c |   4 +-
 arch/arm/mach-socfpga/smmu_agilex5.c  |  34 +
 arch/arm/mach-socfpga/smmu_s10.c  | 126 +++
 arch/arm/mach-socfpga/spl_agilex5.c   | 180 
 arch/arm/mach-socfpga/spl_soc64.c | 188 +++-
 arch/arm/mach-socfpga/u-boot-spl-soc64.lds|  93 ++
 arch/arm/mach-socfpga/wrap_handoff_soc64.c|   7 +-
 board/intel/agilex5-socdk/MAINTAINERS |   8 +
 board/intel/agilex5-socdk/Makefile|   7 +
 board/intel/agilex5-socdk/socfpga.c   |   7 +
 configs/socfpga_agilex5_defconfig | 125 +++
 configs/socfpga_agilex5_legacy_defconfig  |  87 ++
 .../misc/socfpga_secreg.txt   | 397 
 drivers/clk/altera/Makefile   |   1 +
 drivers/clk/altera/clk-agilex5.c  | 736 +++
 drivers/clk/altera/clk-agilex5.h  | 263 ++
 drivers/ddr/altera/Makefile   |   5 +-
 drivers/ddr/altera/iossm_mailbox.c| 786 
 drivers/ddr/altera/iossm_mailbox.h| 141 +++
 drivers/ddr/altera/sdram_agilex5.c| 329 +++
 drivers/ddr/altera/sdram_soc64.c  |  78 +-
 drivers/ddr/altera/sdram_soc64.h  |  17 +-
 drivers/misc/Kconfig  |   9 +
 drivers/misc/Makefile |   1 +
 drivers/misc/socfpga_secreg.c | 116 +++
 drivers/mmc/mmc.c |  27 +-
 drivers/mmc/sdhci-cadence.c   | 164 +++-
 drivers/phy/cadence/Kconfig   |   9 +
 drivers/phy/cadence/Makefile  |   1 +
 drivers/phy/cadence/phy-cadence-combophy.c| 855 ++
 drivers/reset/reset-socfpga.c |  28 +-
 drivers/sys

[PATCH v1 01/17] arch: arm: update kconfig for new platform agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5

Signed-off-by: Jit Loon Lim 
---
 arch/arm/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 99264a6478..8e36456fa8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1093,6 +1093,8 @@ config ARCH_SOCFPGA
select SPL_LIBGENERIC_SUPPORT
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
+   select SPL_DRIVERS_MISC if TARGET_SOCFPGA_SOC64
+   select SPL_SOCFPGA_SEC_REG if TARGET_SOCFPGA_SOC64
select SPL_SERIAL
select SPL_SYSRESET
select SPL_WATCHDOG
@@ -1101,7 +1103,8 @@ config ARCH_SOCFPGA
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select SYSRESET
select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
-   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64
+   select SYSRESET_SOCFPGA_SOC64 if !TARGET_SOCFPGA_AGILEX5 && 
TARGET_SOCFPGA_SOC64
+   imply SYSRESET_SOCFPGA_AGILEX5 if TARGET_SOCFPGA_AGILEX5
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
-- 
2.26.2



[PATCH v1 02/17] arch: arm: dts: add dts and dtsi for new platform agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add agilex5 dtsi and dts.
Update checkpatch error for stratix10.

Signed-off-by: Jit Loon Lim 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_agilex5-u-boot.dtsi  | 459 +
 arch/arm/dts/socfpga_agilex5.dtsi | 634 ++
 .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 
 arch/arm/dts/socfpga_agilex5_socdk.dts| 165 +
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi|  38 +-
 arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 
 arch/arm/dts/socfpga_stratix10.dtsi   |   0
 .../dts/socfpga_stratix10_socdk-u-boot.dtsi   |   0
 arch/arm/dts/socfpga_stratix10_socdk.dts  |   0
 10 files changed, 1534 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_agilex5-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5_socdk.dts
 create mode 100644 arch/arm/dts/socfpga_soc64_u-boot.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..2e4bc556e1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -456,6 +456,7 @@ dtb-$(CONFIG_TARGET_THUNDERX_88XX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_agilex_socdk.dtb\
+   socfpga_agilex5_socdk.dtb   \
socfpga_arria5_secu1.dtb\
socfpga_arria5_socdk.dtb\
socfpga_arria10_chameleonv3_270_2.dtb   \
diff --git a/arch/arm/dts/socfpga_agilex5-u-boot.dtsi 
b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi
new file mode 100644
index 00..6a1299901a
--- /dev/null
+++ b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2019-2022 Intel Corporation 
+ */
+
+#include "socfpga_soc64_u-boot.dtsi"
+#include "socfpga_soc64_fit-u-boot.dtsi"
+
+/{
+   memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   bootph-all;
+   };
+
+   soc {
+   bootph-all;
+
+   socfpga_secreg: socfpga-secreg {
+   compatible = "intel,socfpga-secreg";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   bootph-all;
+
+   /* DSU */
+   i_ccu_caiu0@1c00 {
+   reg = <0x1c00 0x1000>;
+   intel,offset-settings =
+   /* CAIUAMIGR */
+   <0x03c0 0x0003 0x001f>,
+   /* CAIUMIFSR */
+   <0x03c4 0x 0x07070777>,
+   /* DII1_MPFEREGS */
+   <0x0414 0x00018000 0x>,
+   <0x0418 0x 0x00ff>,
+   <0x0410 0xc0e00200 0xc1f03e1f>,
+   /* DII2_GICREGS */
+   <0x0424 0x0001d000 0x>,
+   <0x0428 0x 0x00ff>,
+   <0x0420 0xc0800400 0xc1f03e1f>,
+   /* NCAIU0_LWSOC2FPGA */
+   <0x0444 0x0002 0x>,
+   <0x0448 0x 0x00ff>,
+   <0x0440 0xc116 0xc1f03e1f>,
+   /* NCAIU0_SOC2FPGA_1G */
+   <0x0454 0x0004 0x>,
+   <0x0458 0x 0x00ff>,
+   <0x0450 0xc126 0xc1f03e1f>,
+   /* DMI_SDRAM_2G */
+   <0x0464 0x0008 0x>,
+   <0x0468 0x 0x00ff>,
+   <0x0460 0x8136 0xc1f03e1f>,
+   /* NCAIU0_SOC2FPGA_16G */
+   <0x0474 0x0040 0x>,
+   <0x0478 0x 0x00ff>,
+   <0x0470 0xc166 0xc1f03e1f>,
+   /* DMI_SDRAM_30G */
+  

[PATCH v1 03/17] arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga enablement

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add platform related files to enable new product.

Signed-off-by: Jit Loon Lim 
---
 arch/arm/mach-socfpga/Kconfig |  37 +++
 arch/arm/mach-socfpga/Makefile|  69 -
 arch/arm/mach-socfpga/board.c |  65 -
 arch/arm/mach-socfpga/clock_manager_agilex5.c |  82 ++
 arch/arm/mach-socfpga/firewall.c  | 107 ---
 arch/arm/mach-socfpga/lowlevel_init_agilex5.S |  61 
 arch/arm/mach-socfpga/lowlevel_init_soc64.S   | 167 ++-
 arch/arm/mach-socfpga/mailbox_s10.c   |  21 ++
 arch/arm/mach-socfpga/misc.c  |  19 +-
 arch/arm/mach-socfpga/misc_soc64.c|  33 ++-
 arch/arm/mach-socfpga/mmu-arm64_s10.c |  43 ++-
 arch/arm/mach-socfpga/reset_manager_s10.c | 271 +++---
 arch/arm/mach-socfpga/secure_reg_helper.c |   4 +-
 arch/arm/mach-socfpga/smmu_agilex5.c  |  34 +++
 arch/arm/mach-socfpga/smmu_s10.c  | 126 
 arch/arm/mach-socfpga/spl_agilex5.c   | 180 
 arch/arm/mach-socfpga/spl_soc64.c | 188 +++-
 arch/arm/mach-socfpga/u-boot-spl-soc64.lds|  93 ++
 arch/arm/mach-socfpga/wrap_handoff_soc64.c|   7 +-
 19 files changed, 1429 insertions(+), 178 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex5.c
 delete mode 100644 arch/arm/mach-socfpga/firewall.c
 create mode 100644 arch/arm/mach-socfpga/lowlevel_init_agilex5.S
 create mode 100644 arch/arm/mach-socfpga/smmu_agilex5.c
 create mode 100644 arch/arm/mach-socfpga/smmu_s10.c
 create mode 100644 arch/arm/mach-socfpga/spl_agilex5.c
 create mode 100644 arch/arm/mach-socfpga/u-boot-spl-soc64.lds

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 503c82d388..562c3796ec 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -44,6 +44,15 @@ config TEXT_BASE
default 0x0140 if TARGET_SOCFPGA_ARRIA10
default 0x0140 if TARGET_SOCFPGA_GEN5
 
+config ARMV8_PSCI_NR_CPUS
+   default 4 if TARGET_SOCFPGA_SOC64
+
+config ARMV8_SECURE_BASE
+   default 0x1000 if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI
+
+config SYS_HAS_ARMV8_SECURE_BASE
+   default y if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI
+
 config TARGET_SOCFPGA_AGILEX
bool
select ARMV8_MULTIENTRY
@@ -51,10 +60,31 @@ config TARGET_SOCFPGA_AGILEX
select BINMAN if SPL_ATF
select CLK
select FPGA_INTEL_SDM_MAILBOX
+   select GICV2
+   select NCORE_CACHE
+   select SPL_CLK if SPL
+   select TARGET_SOCFPGA_SOC64
+
+config TARGET_SOCFPGA_AGILEX5
+   bool
+   select BINMAN if SPL_ATF
+   select CLK
+   select FPGA_INTEL_SDM_MAILBOX
+   select GICV3
select NCORE_CACHE
select SPL_CLK if SPL
select TARGET_SOCFPGA_SOC64
 
+config TARGET_SOCFPGA_AGILEX5_EMU
+   bool "Enable build that bootable only on Agilex5 Emulator"
+   help
+This is to use for Agilex5 Emulator.
+
+config TARGET_SOCFPGA_AGILEX5_SIMICS
+   bool "Enable build that bootable only on Agilex5 Simics platform"
+   help
+This is to use for Agilex5 Simics.
+
 config TARGET_SOCFPGA_ARRIA5
bool
select TARGET_SOCFPGA_GEN5
@@ -126,6 +156,10 @@ config TARGET_SOCFPGA_AGILEX_SOCDK
bool "Intel SOCFPGA SoCDK (Agilex)"
select TARGET_SOCFPGA_AGILEX
 
+config TARGET_SOCFPGA_AGILEX5_SOCDK
+   bool "Intel SOCFPGA SoCDK (Agilex5)"
+   select TARGET_SOCFPGA_AGILEX5
+
 config TARGET_SOCFPGA_ARIES_MCVEVK
bool "Aries MCVEVK (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
@@ -199,6 +233,7 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT
 endchoice
 
 config SYS_BOARD
+   default "agilex5-socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "agilex-socdk" if TARGET_SOCFPGA_AGILEX_SOCDK
default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "arria10-socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK
@@ -220,6 +255,7 @@ config SYS_BOARD
default "vining_fpga" if TARGET_SOCFPGA_SOFTING_VINING_FPGA
 
 config SYS_VENDOR
+   default "intel" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "intel" if TARGET_SOCFPGA_AGILEX_SOCDK
default "intel" if TARGET_SOCFPGA_N5X_SOCDK
default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
@@ -242,6 +278,7 @@ config SYS_SOC
default "socfpga"
 
 config SYS_CONFIG_NAME
+   default "socfpga_agilex5_socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "socfpga_agilex_socdk" if TARGET_SOCFPGA_AGILEX_SOCDK
default "socfpga_arria5_secu1" if TARGET_SOCFPGA_ARRIA5_SECU1
default "socfpga_arria5_socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index ec38b64dd4..771e7ce77d 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -35,10 +35,22 @@ obj-y   += mailbox_s10.o
 obj-y  += misc_s

[PATCH v1 04/17] arch: arm: mach-socfpga: include: mach: add new platform agilex5 mach-socfpga enablement

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add platform related header files to enable new product.

Signed-off-by: Jit Loon Lim 
---
 .../include/mach/base_addr_soc64.h|  43 +-
 .../mach-socfpga/include/mach/clock_manager.h |   5 +-
 .../include/mach/clock_manager_agilex5.h  |  12 ++
 arch/arm/mach-socfpga/include/mach/firewall.h |  42 +-
 .../mach-socfpga/include/mach/handoff_soc64.h |  25 +++-
 .../mach-socfpga/include/mach/mailbox_s10.h   |  32 +++--
 .../include/mach/reset_manager_soc64.h|  33 -
 .../mach-socfpga/include/mach/smmu_agilex5.h  |  30 +
 arch/arm/mach-socfpga/include/mach/smmu_s10.h |  73 ++
 .../include/mach/system_manager_soc64.h   | 126 --
 arch/arm/mach-socfpga/include/mach/timer.h|  30 +
 11 files changed, 419 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex5.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_agilex5.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_s10.h

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
index 3f899fcfa3..4a88770638 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
@@ -1,21 +1,60 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Copyright (C) 2016-2021 Intel Corporation 
+ * Copyright (C) 2016-2023 Intel Corporation 
  */
 
 #ifndef _SOCFPGA_SOC64_BASE_HARDWARE_H_
 #define _SOCFPGA_SOC64_BASE_HARDWARE_H_
 
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)
+#define SOCFPGA_CCU_ADDRESS0x1c00
+#define SOCFPGA_F2SDRAM_MGR_ADDRESS0x18001000
+#define SOCFPGA_SMMU_ADDRESS   0x1600
+#define SOCFPGA_OCRAM_FIREWALL_ADDRESS 0x108cc400
+#define SOCFPGA_MAILBOX_ADDRESS0x10a3
+#define SOCFPGA_UART0_ADDRESS  0x10c02000
+#define SOCFPGA_UART1_ADDRESS  0x10c02100
+#define SOCFPGA_SPTIMER0_ADDRESS   0x10c03000
+#define SOCFPGA_SPTIMER1_ADDRESS   0x10c03100
+#define SOCFPGA_SYSTIMER0_ADDRESS  0x10d0
+#define SOCFPGA_SYSTIMER1_ADDRESS  0x10d00100
+#define SOCFPGA_L4WD0_ADDRESS  0x10d00200
+#define SOCFPGA_L4WD1_ADDRESS  0x10d00300
+#define SOCFPGA_L4WD2_ADDRESS  0x10d00400
+#define SOCFPGA_L4WD3_ADDRESS  0x10d00500
+#define SOCFPGA_L4WD4_ADDRESS  0x10d00600
+#define SOCFPGA_GTIMER_SEC_ADDRESS 0x10d01000
+#define SOCFPGA_GTIMER_NSEC_ADDRESS0x10d02000
+#define SOCFPGA_CLKMGR_ADDRESS 0x10d1
+#define SOCFPGA_RSTMGR_ADDRESS 0x10d11000
+#define SOCFPGA_SYSMGR_ADDRESS 0x10d12000
+#define SOCFPGA_OCRAM_ADDRESS  0x
+#define SOCFPGA_FW_DDR_CCU_DMI0_ADDRESS0x18000800
+#define SOCFPGA_FW_DDR_CCU_DMI1_ADDRESS0x18000A00
+#define SOCFPGA_FW_TBU2NOC_ADDRESS 0x18000C00
+#define SOCFPGA_FIREWALL_L4_PER0xffd21000 /* TODO */
+#define SOCFPGA_FIREWALL_L4_SYS0xffd21100 /* TODO */
+#define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200 /* TODO */
+#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300 /* TODO */
+#define SOCFPGA_FIREWALL_TCU   0xffd21400 /* TODO */
+#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV   0xffd24800 /* TODO */
+#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda /* TODO */
+#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000 /* TODO */
+#define GICD_BASE  0x1d00
+#define GICR_BASE  0x1d06
+#else
 #define SOCFPGA_CCU_ADDRESS0xf700
 #define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
 #define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
 #define SOCFPGA_SDR_ADDRESS0xf8011000
+#define SOCFPGA_FW_MPFE_SCR_ADDRESS0xf802
 #if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) || \
IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200
 #else
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020100
 #endif
+#define SOCFPGA_F2SDRAM_MGR_ADDRESS0xf8024000
 #define SOCFPGA_SMMU_ADDRESS   0xfa00
 #define SOCFPGA_MAILBOX_ADDRESS0xffa3
 #define SOCFPGA_UART0_ADDRESS  0xffc02000
@@ -39,10 +78,12 @@
 #define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200
 #define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300
 #define SOCFPGA_FIREWALL_TCU   0xffd21400
+#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV   0xffd24800
 #define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
 #define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
 #define SOCFP

[PATCH v1 05/17] board: intel: add new platform agilex5 socdk

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add new platform socdk and update maintainer list.

Signed-off-by: Jit Loon Lim 
---
 board/intel/agilex5-socdk/MAINTAINERS | 8 
 board/intel/agilex5-socdk/Makefile| 7 +++
 board/intel/agilex5-socdk/socfpga.c   | 7 +++
 3 files changed, 22 insertions(+)
 create mode 100644 board/intel/agilex5-socdk/MAINTAINERS
 create mode 100644 board/intel/agilex5-socdk/Makefile
 create mode 100644 board/intel/agilex5-socdk/socfpga.c

diff --git a/board/intel/agilex5-socdk/MAINTAINERS 
b/board/intel/agilex5-socdk/MAINTAINERS
new file mode 100644
index 00..f0bb2b796b
--- /dev/null
+++ b/board/intel/agilex5-socdk/MAINTAINERS
@@ -0,0 +1,8 @@
+SOCFPGA BOARD
+M: Tien Fong Chee 
+M: Jit Loon Lim 
+M: Sieu Mun Tang 
+S: Maintained
+F: board/intel/agilex5-socdk/
+F: include/configs/socfpga_agilex5_socdk.h
+F: configs/socfpga_agilex5_defconfig
diff --git a/board/intel/agilex5-socdk/Makefile 
b/board/intel/agilex5-socdk/Makefile
new file mode 100644
index 00..52f7de8880
--- /dev/null
+++ b/board/intel/agilex5-socdk/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2022 Intel Corporation 
+#
+# SPDX-License-Identifier: GPL-2.0
+#
+
+obj-y  := socfpga.o
diff --git a/board/intel/agilex5-socdk/socfpga.c 
b/board/intel/agilex5-socdk/socfpga.c
new file mode 100644
index 00..ae5c04557c
--- /dev/null
+++ b/board/intel/agilex5-socdk/socfpga.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Intel Corporation 
+ *
+ */
+
+#include 
-- 
2.26.2



[PATCH v1 07/17] doc: device-tree-bindings: misc: add secreg text file for agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add new secure register text file for new platform.

Signed-off-by: Jit Loon Lim 
---
 .../misc/socfpga_secreg.txt   | 397 ++
 1 file changed, 397 insertions(+)
 create mode 100644 doc/device-tree-bindings/misc/socfpga_secreg.txt

diff --git a/doc/device-tree-bindings/misc/socfpga_secreg.txt 
b/doc/device-tree-bindings/misc/socfpga_secreg.txt
new file mode 100644
index 00..97640b74d9
--- /dev/null
+++ b/doc/device-tree-bindings/misc/socfpga_secreg.txt
@@ -0,0 +1,397 @@
+* Firewall and privilege register settings in device tree
+
+Required properties:
+
+
+- compatible: should contain "intel,socfpga-secreg"
+- reg: Physical base address and size of block register.
+- intel,offset-settings: 32-bit offset address of block register,
+followed by 32-bit value settings and
+the masking bits, only masking bit
+set to 1 allows modification.
+
+The device tree node which describes secure and privilege register access
+configuration in compile time.
+
+Most of these registers are expected to work except for the case which some
+registers configuration are required for granting access to some other
+registers, for example CCU registers have to be properly configured before
+allowing register configuration access to fpga2sdram firewall as shown in
+below example.
+
+Some registers depend on runtime data for proper configuration are expected
+to be part of driver that generating these data for example configuration for
+soc_noc_fw_ddr_mpu_inst_0_ddr_scr block register depend on DDR size parsed from
+memory device tree node.
+
+Please refer details of tested examples below for both fpga2sdram and QoS
+configuration with default reset value and the comments.
+
+Example:
+
+
+Common configuration for all SoC64 devices:
+Path: arch/arm/dts/socfpga_soc64_u-boot.dtsi
+
+   socfpga_secreg: socfpga-secreg {
+   compatible = "intel,socfpga-secreg";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   u-boot,dm-pre-reloc;
+
+   i_sys_mgr_core@ffd12000 {
+   reg = <0xffd12000 0x0230>;
+   intel,offset-settings =
+   /* Enable non-secure interface to DMA */
+   <0x0020 0xff01 0xff010011>,
+   /* Enable non-secure interface to DMA periph */
+   <0x0024 0x 0x>;
+   u-boot,dm-pre-reloc;
+   };
+
+   noc_fw_l4_per_l4_per_scr@ffd21000 {
+   reg = <0xffd21000 0x0074>;
+   intel,offset-settings =
+   /* Disable L4 periphs firewall */
+   <0x 0x01010001 0x01010001>,
+   <0x0004 0x01010001 0x01010001>,
+   <0x000c 0x01010001 0x01010001>,
+   <0x0010 0x01010001 0x01010001>,
+   <0x001c 0x01010001 0x01010101>,
+   <0x0020 0x01010001 0x01010101>,
+   <0x0024 0x01010001 0x01010101>,
+   <0x0028 0x01010001 0x01010101>,
+   <0x002c 0x01010001 0x01010001>,
+   <0x0030 0x01010001 0x01010001>,
+   <0x0034 0x01010001 0x01010001>,
+   <0x0040 0x01010001 0x01010001>,
+   <0x0044 0x01010001 0x01010101>,
+   <0x0048 0x01010001 0x01010101>,
+   <0x0050 0x01010001 0x01010101>,
+   <0x0054 0x01010001 0x01010101>,
+   <0x0058 0x01010001 0x01010101>,
+   <0x005c 0x01010001 0x01010101>,
+   <0x0060 0x01010001 0x01010101>,
+   <0x0064 0x01010001 0x01010101>,
+   <0x0068 0x01010001 0x01010101>,
+   <0x006c 0x01010001 0x01010101>,
+   <0x0070 0x01010001 0x01010101>;
+   u-boot,dm-pre-reloc;
+   };
+
+   noc_fw_l4_sys_l4_sys_scr@ffd21100 {
+   reg = <0xffd21100 0x0098>;
+   intel,offset-settings =
+   /* Disable L4 system firewall */
+   <0x0008 0x01010001 0x01010001>,
+   <0x000c 0x01010001 0x01010001>,
+   <0x0010 0x01010001 0x01010001>,
+   <0x0014 0x01

[PATCH v1 06/17] configs: add new platform agilex5 defconfig

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add new platform defconfig for new platform.

Signed-off-by: Jit Loon Lim 
---
 configs/socfpga_agilex5_defconfig| 123 +++
 configs/socfpga_agilex5_legacy_defconfig |  85 
 2 files changed, 208 insertions(+)
 create mode 100644 configs/socfpga_agilex5_defconfig
 create mode 100644 configs/socfpga_agilex5_legacy_defconfig

diff --git a/configs/socfpga_agilex5_defconfig 
b/configs/socfpga_agilex5_defconfig
new file mode 100644
index 00..6a90fa0b27
--- /dev/null
+++ b/configs/socfpga_agilex5_defconfig
@@ -0,0 +1,123 @@
+CONFIG_ARM=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_TEXT_BASE=0x8020
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk"
+# CONFIG_SPL_MMC is not set
+CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y
+CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_agilex5"
+CONFIG_SPL_FS_FAT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8200
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 initrd=0x9000 root=/dev/ram0 rw 
init=/sbin/init ramdisk_size=1000 earlycon panic=-1 nosmp kvm-arm.mode=nvhe"
+CONFIG_LEGACY_IMAGE_FORMAT=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_CRC32=y
+CONFIG_SPL_CACHE=y
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_SYS_PROMPT="SOCFPGA_AGILEX5 # "
+CONFIG_CMD_NVEDIT_SELECT=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_COMBOPHY=y
+CONFIG_DM_MMC=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_CADENCE=y
+CONFIG_CMD_FAT=y
+CONFIG_DOS_PARTITION=y
+CONFIG_SPL_DOS_PARTITION=y
+CONFIG_SPL_SYS_DISABLE_DCACHE_OPS=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_NAND_LOCK_UNLOCK=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_MTDIDS_DEFAULT="nand0=ffb9.nand.0"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=ffb9.nand.0:2m(u-boot),-(root)"
+CONFIG_CMD_UBI=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_LIST=""
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_ALTERA_SDRAM=y
+CONFIG_FPGA_INTEL_PR=y
+CONFIG_DWAPB_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_DW=y
+CONFIG_MISC=y
+CONFIG_MMC_DW=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
+CONFIG_SYS_NAND_U_BOOT_OFFS=0x0
+CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x10
+CONFIG_SF_DEFAULT_MODE=0x2003
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_UBI_SILENCE_MSG=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_MII=y
+CONFIG_DM_RESET=y
+CONFIG_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_DESIGNWARE_SPI=y
+CONFIG_NOP_PHY=y
+CONFIG_USB=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_UBIFS_SILENCE_MSG=y
+# CONFIG_SPL_USE_TINY_PRINTF is not set
+CONFIG_PANIC_HANG=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_WDT=y
+CONFIG_CMD_WDT=y
+CONFIG_DESIGNWARE_WATCHDOG=y
+CONFIG_SPL_WDT=y
+CONFIG_WATCHDOG_AUTOSTART=n
+CONFIG_TIMER=y
+CONFIG_DESIGNWARE_APB_TIMER=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8030
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x8ff0
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK=0xffe3f000
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8fa0
+CONFIG_SYS_SPL_MALLOC_SIZE=0x50
+CONFIG_SPL_BSS_MAX_SIZE=0x10
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/socfpga_agilex5_legacy_defconfig 
b/configs/socfpga_agilex5_legacy_defconfig
new file mode 100644
index 00..cede11c880
--- /dev/null
+++ b/configs/socfpga_agilex5_legacy_defconfig
@@ -0,0 +1,85 @@
+CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_SYS_TEXT_BASE=0x80001000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+# CONFIG_SPL_DM_SPI is not set
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk"
+CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y
+CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_agilex5"
+CONFIG_SPL_FS_FAT=y
+# CONFIG_SPL_SPI is not set
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_ARMV8_PSCI=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARG

[PATCH v1 10/17] drivers: misc: update driver misc for agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Update secure registers, Kconfig and makefile for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/misc/Kconfig  |   9 +++
 drivers/misc/Makefile |   1 +
 drivers/misc/socfpga_secreg.c | 116 ++
 3 files changed, 126 insertions(+)
 create mode 100644 drivers/misc/socfpga_secreg.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 04460f1acb..3b6f5314ff 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -666,4 +666,13 @@ config SL28CPLD
  the base driver which provides common access methods for the
  sub-drivers.
 
+config SPL_SOCFPGA_SEC_REG
+   bool "Enable register setting from device tree in SPL"
+   depends on SPL
+   help
+ Enable register setting from device tree in SPL, which require
+ high privilege access like firewall registers. This also
+ provides user a clean interface and all register settings are
+ centralized in one place, device tree.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 52aed09602..441c03509f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_K3_AVS0) += k3_avs.o
 obj-$(CONFIG_ESM_K3) += k3_esm.o
 obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
 obj-$(CONFIG_SL28CPLD) += sl28cpld.o
+obj-$(CONFIG_SPL_SOCFPGA_SEC_REG) += socfpga_secreg.o
diff --git a/drivers/misc/socfpga_secreg.c b/drivers/misc/socfpga_secreg.c
new file mode 100644
index 00..3f3ba8b0c1
--- /dev/null
+++ b/drivers/misc/socfpga_secreg.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021-2023 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUMBER_OF_ELEMENTS 3
+
+static int socfpga_secreg_probe(struct udevice *dev)
+{
+   const fdt32_t *list;
+   fdt_addr_t offset, base;
+   fdt_val_t val, read_val, mask, set_mask;
+   int size, i;
+   u32 blk_sz, reg;
+   ofnode node;
+   const char *name = NULL;
+
+   debug("%s(dev=%p)\n", __func__, dev);
+
+   if (!dev_has_ofnode(dev))
+   return 0;
+
+   dev_for_each_subnode(node, dev) {
+   name = ofnode_get_name(node);
+   if (!name)
+   return -EINVAL;
+
+   if (ofnode_read_u32_index(node, "reg", 1, &blk_sz))
+   return -EINVAL;
+
+   base = ofnode_get_addr(node);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   debug("%s(node_offset 0x%lx node_name %s ", __func__,
+ node.of_offset, name);
+   debug("node addr 0x%llx blk sz 0x%x)\n", base, blk_sz);
+
+   list = ofnode_read_prop(node, "intel,offset-settings", &size);
+   if (!list)
+   return -EINVAL;
+
+   debug("%s(intel,offset-settings property size=%x)\n", __func__,
+ size);
+   size /= sizeof(*list) * NUMBER_OF_ELEMENTS;
+
+   /*
+* First element: offset
+* Second element: val
+* Third element: mask
+*/
+   for (i = 0; i < size; i++) {
+   offset = fdt32_to_cpu(*list++);
+   val = fdt32_to_cpu(*list++);
+
+   /* Reads the masking bit value from the list */
+   mask = fdt32_to_cpu(*list++);
+
+   /*
+* Reads out the offsets, value and masking bits
+* Ex: <0x 0x0230 0x>
+*/
+   debug("%s(intel,offset-settings 0x%llx : 0x%llx : 
0x%llx)\n",
+ __func__, offset, val, mask);
+
+   if (blk_sz < offset + SZ_4) {
+   printf("%s: Overflow as offset 0x%llx or reg",
+  __func__, offset);
+   printf(" write is more than block size 0x%x\n",
+  blk_sz);
+   return -EINVAL;
+   }
+
+   if (mask != 0) {
+   if (mask == 0x) {
+   reg = base + offset;
+   writel(val, (uintptr_t)reg);
+   } else {
+   /* Mask the value with the masking bits 
*/
+   set_mask = val & mask;
+
+   reg = base + offset;
+
+   /* Clears and sets specific bits in the 
register */
+   clrsetbits_le32((uintptr_t)reg, mask, 
set_mask);
+   }
+ 

[PATCH v1 08/17] drivers: ddr: altera: add ddr support for agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add new ddr and iossm mailbox files for new platform.Add

Signed-off-by: Jit Loon Lim 
---
 drivers/ddr/altera/Makefile|   5 +-
 drivers/ddr/altera/iossm_mailbox.c | 786 +
 drivers/ddr/altera/iossm_mailbox.h | 141 ++
 drivers/ddr/altera/sdram_agilex5.c | 329 
 drivers/ddr/altera/sdram_soc64.c   |  78 ++-
 drivers/ddr/altera/sdram_soc64.h   |  17 +-
 6 files changed, 1345 insertions(+), 11 deletions(-)
 create mode 100644 drivers/ddr/altera/iossm_mailbox.c
 create mode 100644 drivers/ddr/altera/iossm_mailbox.h
 create mode 100644 drivers/ddr/altera/sdram_agilex5.c

diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile
index 9fa5d85a27..fa6c880b39 100644
--- a/drivers/ddr/altera/Makefile
+++ b/drivers/ddr/altera/Makefile
@@ -7,9 +7,10 @@
 # Copyright (C) 2014-2021 Altera Corporation 
 
 ifdef CONFIG_$(SPL_)ALTERA_SDRAM
-obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o
-obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_soc32.o sdram_gen5.o sequencer.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_soc32.o sdram_arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += sdram_soc64.o sdram_s10.o
 obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += sdram_soc64.o sdram_agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += sdram_soc64.o sdram_n5x.o
+obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += sdram_soc64.o sdram_agilex5.o 
iossm_mailbox.o
 endif
diff --git a/drivers/ddr/altera/iossm_mailbox.c 
b/drivers/ddr/altera/iossm_mailbox.c
new file mode 100644
index 00..c7ceed7c45
--- /dev/null
+++ b/drivers/ddr/altera/iossm_mailbox.c
@@ -0,0 +1,786 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Intel Corporation 
+ *
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include "iossm_mailbox.h"
+#include 
+
+/* supported DDR type list */
+static const char *ddr_type_list[7] = {
+   "DDR4", "DDR5", "DDR5_RDIMM", "LPDDR4", "LPDDR5", "QDRIV", 
"UNKNOWN"
+};
+
+/* Mailbox request function
+ * This function will send the request to IOSSM mailbox and wait for response 
return
+ *
+ * @io96b_csr_addr: CSR address for the target IO96B
+ * @ip_type:   IP type for the specified memory interface
+ * @instance_id:IP instance ID for the specified memory interface
+ * @usr_cmd_type:   User desire IOSSM mailbox command type
+ * @usr_cmd_opcode: User desire IOSSM mailbox command opcode
+ * @cmd_param_*:Parameters (if applicable) for the requested IOSSM mailbox 
command
+ * @resp_data_len:  User desire extra response data fields other than
+ * CMD_RESPONSE_DATA_SHORT field on 
CMD_RESPONSE_STATUS
+ * @resp:  Structure contain responses returned from the 
requested IOSSM
+ * mailbox command
+ */
+int io96b_mb_req(phys_addr_t io96b_csr_addr, u32 ip_type, u32 instance_id
+   , u32 usr_cmd_type, u32 usr_cmd_opcode, 
u32 cmd_param_0
+   , u32 cmd_param_1, u32 cmd_param_2, u32 
cmd_param_3
+   , u32 cmd_param_4, u32 cmd_param_5, u32 
cmd_param_6
+   , u32 resp_data_len, struct 
io96b_mb_resp *resp)
+{
+   int i;
+   int ret;
+   u32 cmd_req, cmd_resp;
+
+   /* Initialized zeros for responses*/
+   resp->cmd_resp_status = 0;
+   resp->cmd_resp_data_0 = 0;
+   resp->cmd_resp_data_1 = 0;
+   resp->cmd_resp_data_2 = 0;
+
+   /* Ensure CMD_REQ is cleared before write any command request */
+   ret = wait_for_bit_le32((const void *)(io96b_csr_addr + 
IOSSM_CMD_REQ_OFFSET)
+   , GENMASK(31, 0), 0, TIMEOUT, false);
+
+   if (ret) {
+   printf("%s: CMD_REQ not ready\n", __func__);
+   return -1;
+   }
+
+   /* Write CMD_PARAM_* */
+   for (i = 0; i < 6 ; i++) {
+   switch (i) {
+   case 0:
+   if (cmd_param_0)
+   writel(cmd_param_0, io96b_csr_addr + 
IOSSM_CMD_PARAM_0_OFFSET);
+   break;
+   case 1:
+   if (cmd_param_1)
+   writel(cmd_param_1, io96b_csr_addr + 
IOSSM_CMD_PARAM_1_OFFSET);
+   break;
+   case 2:
+   if (cmd_param_2)
+   writel(cmd_param_2, io96b_csr_addr + 
IOSSM_CMD_PARAM_2_OFFSET);
+   break;
+   case 3:
+   if (cmd_param_3)
+   writel(cmd_param_3, io96b_csr_addr + 
IOSSM_CMD_PARAM_3_OFFSET);
+   break;
+   case 4:
+   if (cmd_param_4)
+   writel(cmd_param_4, io96b_csr_addr + 
IOSSM_CMD_PARAM_4_OFFSET);
+   

[PATCH v1 09/17] drivers: clk: altera: add clock support for agilex5

2023-06-20 Thread Jit Loon Lim
This is for new platform enablement for agilex5.
Add new clock files for new platform.Add

Signed-off-by: Jit Loon Lim 
---
 drivers/clk/altera/Makefile  |   1 +
 drivers/clk/altera/clk-agilex5.c | 736 +++
 drivers/clk/altera/clk-agilex5.h | 263 +++
 3 files changed, 1000 insertions(+)
 create mode 100644 drivers/clk/altera/clk-agilex5.c
 create mode 100644 drivers/clk/altera/clk-agilex5.h

diff --git a/drivers/clk/altera/Makefile b/drivers/clk/altera/Makefile
index 33db092918..61ffa4179a 100644
--- a/drivers/clk/altera/Makefile
+++ b/drivers/clk/altera/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += clk-agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clk-arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-n5x.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-mem-n5x.o
+obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += clk-agilex5.o
diff --git a/drivers/clk/altera/clk-agilex5.c b/drivers/clk/altera/clk-agilex5.c
new file mode 100644
index 00..05ee5f9874
--- /dev/null
+++ b/drivers/clk/altera/clk-agilex5.c
@@ -0,0 +1,736 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2023 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MPIDR_AFF1_OFFSET  8
+#define MPIDR_AFF1_MASK0x3
+#define CORE0  1
+#define CORE1  2
+#define CORE2  3
+#define CORE3  4
+
+struct socfpga_clk_plat {
+   void __iomem *regs;
+};
+
+/*
+ * function to write the bypass register which requires a poll of the
+ * busy bit
+ */
+static void clk_write_bypass_mainpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_MAINPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+static void clk_write_bypass_perpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_PERPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+/* function to write the ctrl register which requires a poll of the busy bit */
+static void clk_write_ctrl(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_CTRL);
+   cm_wait_for_fsm();
+}
+
+#define MEMBUS_MAINPLL 0
+#define MEMBUS_PERPLL  1
+#define MEMBUS_TIMEOUT 1000
+
+#define MEMBUS_CLKSLICE_REG0x27
+#define MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG0xb3
+#define MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG   0xe6
+#define MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG0x03
+#define MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG0x07
+
+static const struct {
+   u32 reg;
+   u32 val;
+   u32 mask;
+} membus_pll[] = {
+   {
+   MEMBUS_CLKSLICE_REG,
+   /*
+* BIT[7:7]
+* Enable source synchronous mode
+*/
+   BIT(7),
+   BIT(7)
+   },
+   {
+   MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG,
+   /*
+* BIT[0:0]
+* Sets synthcalfosc_init_centerfreq=1 to limit overshoot
+* frequency during lock
+*/
+   BIT(0),
+   BIT(0)
+   },
+   {
+   MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG,
+   /*
+* BIT[0:0]
+* Sets synthppm_watchdogtmr_vf0=1 to give the pll more time
+* to settle before lock is asserted.
+*/
+   BIT(0),
+   BIT(0)
+   },
+   {
+   MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG,
+   /*
+* BIT[6:0]
+* Centering duty cycle for clkslice0 output
+*/
+   0x4a,
+   GENMASK(6, 0)
+   },
+   {
+   MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG,
+   /*
+* BIT[6:0]
+* Centering duty cycle for clkslice1 output
+*/
+   0x4a,
+   GENMASK(6, 0)
+   },
+};
+
+static int membus_wait_for_req(struct socfpga_clk_plat *plat, u32 pll,
+  int timeout)
+{
+   int cnt = 0;
+   u32 req_status;
+
+   if (pll == MEMBUS_MAINPLL)
+   req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM);
+   else
+   req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM);
+
+   while ((cnt < timeout) && (req_status & CLKMGR_MEM_REQ_SET_MSK)) {
+   if (pll == MEMBUS_MAINPLL)
+   req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM);
+   else
+   req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM);
+   cnt++;
+   }
+
+   if (cnt >= timeout)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+static int membus_write_pll(struct socfpga_clk_pl

  1   2   >