Re: [PATCH] i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7

2020-07-06 Thread Heiko Schocher

Hello Patrick,

Am 06.07.2020 um 13:31 schrieb Patrick Delaunay:

Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus
speed is selected.

Handle the stm32mp15 specific compatible to handle FastMode+
registers handling which is different on the stm32mp15 compared
to the stm32f7 or stm32h7.
Indeed, on the stm32mp15, the FastMode+ set and clear registers
are separated while on the other platforms (F7 or H7) the control
is done in a unique register.

Signed-off-by: Patrick Delaunay 
---

  drivers/i2c/stm32f7_i2c.c | 74 ++-
  1 file changed, 73 insertions(+), 1 deletion(-)


Just tried to apply your patch on current mainline, but this fails
for me, reason is missing patch:

http://patchwork.ozlabs.org/project/uboot/patch/20200706112653.18951-2-patrick.delau...@st.com/

So I add this patch also to my repo, if nobody has objections.

Beside of this:

Reviewed-by: Heiko Schocher 

Thanks!

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


Re: [PATCH 2/3] i2c: stm32f7: add stm32mp15 compatible

2020-07-06 Thread Heiko Schocher

Hello Patrick,

Am 06.07.2020 um 13:26 schrieb Patrick Delaunay:

Add a new compatible "st,stm32mp15-i2c" introduced in Linux kernel v5.8

Signed-off-by: Patrick Delaunay 
---

  drivers/i2c/stm32f7_i2c.c | 1 +
  1 file changed, 1 insertion(+)


Reviewed-by: Heiko Schocher 

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


Re: [PATCH v4 00/11] new rtc methods, rtc command, and tests

2020-07-06 Thread Heiko Schocher

Hello Rasmus,

Am 06.07.2020 um 22:01 schrieb Rasmus Villemoes:

I need access to registers other than just the timekeeping ones of the
pcf2127, so I wanted to implement ->read8 and ->write8. But for
testing these it appeared there was no convenient way to invoke those
from the shell, so I also ended up adding such a command.

Also, it seemed more natural to provide array variants that can read
or write several registers at once, so rtc_ops is expanded a bit.

Changes in v4:

- Add CONFIG_CMD_RTC to sandbox defconfigs (new patch 10/11). Not
   quite sure exactly which it needed to be added to, but at least
   sandbox and sandbox_flattree showed CI failures.

- Add Heiko's R-B to the 10 v3 patches (1-9 + 11), and Simon's R-B to 6/11.

- Fix some checkpatch warnings - I don't really agree with most of


Sorry, I should have mentioned which warnings you should fix ...


   them - e.g. having to add an empty line in

   int foo = something();
   if (foo < 0)
 return foo;
   return something_else(foo);

   doesn't make the code more readable IMO.


You find this rule all over the source code in U-Boot...


   The remaining checkpatch blurps are things I really don't think
   warrant "fixing", e.g. "WARNING: ENOSYS means 'invalid syscall nr'
   and nothing else" seems irrelevant in context of U-Boot, and in any
   case I've only copied existing practice. For "WARNING: please write
   a paragraph that describes the config symbol fully", that seems to
   be a false positive, there's certainly a full help text for CMD_RTC.


Yes, this is fine.

Just applied your patches now, there is one warning in patch

"test: dm: rtc: add test of dm_rtc_read, dm_rtc_write"

CHECK: Comparison to NULL could be written "emul"
#218: FILE: test/dm/rtc.c:162:
+   ut_assert(emul != NULL);

I think, this should be fixed! But looking into the source file, there
are more such lines, so I let this at it is... may this should be cleaned!

Thanks for your work!

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


[PATCH v2 17/17] efi_selftest: adjust runtime test for variables

2020-07-06 Thread Heinrich Schuchardt
As variable services are available at runtime we have to expect EFI_SUCCESS
when calling the services.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_variables_runtime.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_variables_runtime.c 
b/lib/efi_selftest/efi_selftest_variables_runtime.c
index b3b40ad2cf..3226069c0b 100644
--- a/lib/efi_selftest/efi_selftest_variables_runtime.c
+++ b/lib/efi_selftest/efi_selftest_variables_runtime.c
@@ -16,9 +16,7 @@

 static struct efi_boot_services *boottime;
 static struct efi_runtime_services *runtime;
-static const efi_guid_t guid_vendor0 =
-   EFI_GUID(0x67029eb5, 0x0af2, 0xf6b1,
-0xda, 0x53, 0xfc, 0xb5, 0x66, 0xdd, 0x1c, 0xe6);
+static const efi_guid_t guid_vendor0 = EFI_GLOBAL_VARIABLE_GUID;

 /*
  * Setup unit test.
@@ -68,17 +66,18 @@ static int execute(void)
efi_st_error("SetVariable failed\n");
return EFI_ST_FAILURE;
}
-   len = 3;
-   ret = runtime->get_variable(L"efi_st_var0", _vendor0,
+   len = EFI_ST_MAX_DATA_SIZE;
+   ret = runtime->get_variable(L"PlatformLangCodes", _vendor0,
, , data);
-   if (ret != EFI_UNSUPPORTED) {
+   if (ret != EFI_SUCCESS) {
efi_st_error("GetVariable failed\n");
return EFI_ST_FAILURE;
}
memset(, 0, 16);
*varname = 0;
+   len = 2 * EFI_ST_MAX_VARNAME_SIZE;
ret = runtime->get_next_variable_name(, varname, );
-   if (ret != EFI_UNSUPPORTED) {
+   if (ret != EFI_SUCCESS) {
efi_st_error("GetNextVariableName failed\n");
return EFI_ST_FAILURE;
}
--
2.27.0



[PATCH v2 11/17] efi_loader: export efi_convert_pointer()

2020-07-06 Thread Heinrich Schuchardt
We need ConvertPointer() to adjust pointers when implementing  runtime
services within U-Boot.

After ExitBootServices() gd is not available anymore. So we should not use
EFI_ENTRY() and EFI_EXIT().

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h | 3 +++
 lib/efi_loader/efi_runtime.c | 8 +++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index fc9344c742..fe8774f133 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -397,6 +397,9 @@ efi_status_t efi_root_node_register(void);
 efi_status_t efi_initialize_system_table(void);
 /* efi_runtime_detach() - detach unimplemented runtime functions */
 void efi_runtime_detach(void);
+/* efi_convert_pointer() - convert pointer to virtual address */
+efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t debug_disposition,
+   void **address);
 /* Called by bootefi to make console interface available */
 efi_status_t efi_console_register(void);
 /* Called by bootefi to make all disk storage accessible as EFI objects */
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 121e2f65c6..45baa2fd3e 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -496,15 +496,13 @@ static __efi_runtime efi_status_t EFIAPI 
efi_convert_pointer_runtime(
  * @address:   pointer to be converted
  * Return: status code
  */
-static __efi_runtime efi_status_t EFIAPI efi_convert_pointer(
-   efi_uintn_t debug_disposition, void **address)
+__efi_runtime efi_status_t EFIAPI
+efi_convert_pointer(efi_uintn_t debug_disposition, void **address)
 {
efi_physical_addr_t addr;
efi_uintn_t i;
efi_status_t ret = EFI_NOT_FOUND;

-   EFI_ENTRY("%zu %p", debug_disposition, address);
-
if (!efi_virtmap) {
ret = EFI_UNSUPPORTED;
goto out;
@@ -533,7 +531,7 @@ static __efi_runtime efi_status_t EFIAPI 
efi_convert_pointer(
}

 out:
-   return EFI_EXIT(ret);
+   return ret;
 }

 static __efi_runtime void efi_relocate_runtime_table(ulong offset)
--
2.27.0



[PATCH v2 10/17] efi_loader: UEFI variable persistence

2020-07-06 Thread Heinrich Schuchardt
Persist non-volatile UEFI variables in a file on the EFI system partition.

The file is written whenever a non-volatile UEFI variable is changed after
initialization of the UEFI sub-system.

The file is read during the UEFI sub-system initialization to restore
non-volatile UEFI variables.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_variable.h|  62 +
 lib/efi_loader/Kconfig|   8 ++
 lib/efi_loader/Makefile   |   1 +
 lib/efi_loader/efi_var_file.c | 239 ++
 lib/efi_loader/efi_variable.c |  10 +-
 5 files changed, 319 insertions(+), 1 deletion(-)
 create mode 100644 lib/efi_loader/efi_var_file.c

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 3ba274fce1..01054209c4 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -79,4 +79,66 @@ efi_status_t efi_query_variable_info_int(u32 attributes,
 u64 *remaining_variable_storage_size,
 u64 *maximum_variable_size);

+#define EFI_VAR_FILE_NAME "ubootefi.var"
+
+#define EFI_VAR_BUF_SIZE 0x4000
+
+#define EFI_VAR_FILE_MAGIC 0x0161566966456255 /* UbEfiVa, version 1 */
+
+/**
+ * struct efi_var_entry - UEFI variable file entry
+ *
+ * @length:length of enty, multiple of 8
+ * @attr:  variable attributes
+ * @time:  authentication time (seconds since start of epoch)
+ * @guid:  vendor GUID
+ * @name:  UTF16 variable name
+ */
+struct efi_var_entry {
+   u32 length;
+   u32 attr;
+   u64 time;
+   efi_guid_t guid;
+   u16 name[];
+};
+
+/**
+ * struct efi_var_file - file for storing UEFI variables
+ *
+ * @reserved:  unused, may be overwritten by memory probing
+ * @magic: identifies file format
+ * @length:length including header
+ * @crc32: CRC32 without header
+ * @var:   variables
+ */
+struct efi_var_file {
+   u64 reserved;
+   u64 magic;
+   u32 length;
+   u32 crc32;
+   struct efi_var_entry var[];
+};
+
+/**
+ * efi_var_to_file() - save non-volatile variables as file
+ *
+ * File ubootefi.var is created on the EFI system partion.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_to_file(void);
+
+/**
+ * efi_var_from_file() - read variables from file
+ *
+ * File ubootefi.var is read from the EFI system partitions and the variables
+ * stored in the file are created.
+ *
+ * In case the file does not exist yet or a variable cannot be set EFI_SUCCESS
+ * is returned.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_from_file(void);
+
 #endif
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6c9df3a767..4324694d48 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -27,6 +27,14 @@ config EFI_LOADER

 if EFI_LOADER

+config EFI_VARIABLE_FILE_STORE
+   bool "Store non-volatile UEFI variables as file"
+   depends on FAT_WRITE
+   default y
+   help
+ Select tis option if you want non-volatile UEFI variables to be stored
+ as file /ubootefi.var on the EFI system partition.
+
 config EFI_GET_TIME
bool "GetTime() runtime service"
depends on DM_RTC
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 7eddd7ef37..c87b82db32 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -40,6 +40,7 @@ ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
 obj-y += efi_variable_tee.o
 else
 obj-y += efi_variable.o
+obj-y += efi_var_file.o
 endif
 obj-y += efi_watchdog.o
 obj-$(CONFIG_LCD) += efi_gop.o
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
new file mode 100644
index 00..b1b7532495
--- /dev/null
+++ b/lib/efi_loader/efi_var_file.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * File interface for UEFI variables
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PART_STR_LEN 10
+
+/**
+ * efi_set_blk_dev_to_system_partition() - select EFI system partition
+ *
+ * Set the EFI system partition as current block device.
+ *
+ * Return: status code
+ */
+static efi_status_t __maybe_unused efi_set_blk_dev_to_system_partition(void)
+{
+   char part_str[PART_STR_LEN];
+   int r;
+
+   if (!efi_system_partition.if_type) {
+   log_err("No EFI system partition\n");
+   return EFI_DEVICE_ERROR;
+   }
+   snprintf(part_str, PART_STR_LEN, "%u:%u",
+efi_system_partition.devnum, efi_system_partition.part);
+   r = fs_set_blk_dev(blk_get_if_type_name(efi_system_partition.if_type),
+  part_str, FS_TYPE_ANY);
+   if (r) {
+   log_err("Cannot read EFI system partition\n");
+   return EFI_DEVICE_ERROR;
+   }
+   return EFI_SUCCESS;
+}
+
+/**
+ * efi_var_collect() - collect non-volatile variables in buffer
+ *
+ * 

[PATCH v2 16/17] efi_loader: enable UEFI variables at runtime

2020-07-06 Thread Heinrich Schuchardt
Enable UEFI variables at runtime.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_runtime.c  | 2 ++
 lib/efi_loader/efi_variable.c | 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 5b6506fbdc..91a4551448 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -121,6 +121,8 @@ efi_status_t efi_init_runtime_supported(void)
rt_table->version = EFI_RT_PROPERTIES_TABLE_VERSION;
rt_table->length = sizeof(struct efi_rt_properties_table);
rt_table->runtime_services_supported =
+   EFI_RT_SUPPORTED_GET_VARIABLE |
+   EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME |
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
EFI_RT_SUPPORTED_CONVERT_POINTER;

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 13123e7e41..c472a054d0 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -672,7 +672,8 @@ static efi_status_t __efi_runtime EFIAPI
 efi_get_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
 u32 *attributes, efi_uintn_t *data_size, void *data)
 {
-   return EFI_UNSUPPORTED;
+   return efi_get_variable_int(variable_name, vendor, attributes,
+   data_size, data, NULL);
 }

 /**
@@ -688,7 +689,8 @@ static efi_status_t __efi_runtime EFIAPI
 efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
   u16 *variable_name, efi_guid_t *vendor)
 {
-   return EFI_UNSUPPORTED;
+   return efi_get_next_variable_name_int(variable_name_size, variable_name,
+ vendor);
 }

 /**
--
2.27.0



[PATCH v2 14/17] efi_loader: memory buffer for variables

2020-07-06 Thread Heinrich Schuchardt
Saving UEFI variable as encoded U-Boot environment variables does not allow
support at runtime.

Provide functions to manage a memory buffer with UEFI variables.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_variable.h   |  54 +++
 lib/efi_loader/Makefile  |   1 +
 lib/efi_loader/efi_var_mem.c | 266 +++
 3 files changed, 321 insertions(+)
 create mode 100644 lib/efi_loader/efi_var_mem.c

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 01054209c4..bc5985cfdb 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -141,4 +141,58 @@ efi_status_t efi_var_to_file(void);
  */
 efi_status_t efi_var_from_file(void);

+/**
+ * efi_var_mem_init() - set-up variable list
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_mem_init(void);
+
+/**
+ * efi_var_mem_find() - find a variable in the list
+ *
+ * @guid:  GUID of the variable
+ * @name:  name of the variable
+ * @next:  on exit pointer to the next variable after the found one
+ * Return: found variable
+ */
+struct efi_var_entry *efi_var_mem_find(const efi_guid_t *guid, const u16 *name,
+  struct efi_var_entry **next);
+
+/**
+ * efi_var_mem_del() - delete a variable from the list of variables
+ *
+ * @var:   variable to delete
+ */
+void efi_var_mem_del(struct efi_var_entry *var);
+
+/**
+ * efi_var_mem_ins() - append a variable to the list of variables
+ *
+ * The variable is appended without checking if a variable of the same name
+ * already exists. The two data buffers are concatenated.
+ *
+ * @variable_name: variable name
+ * @vendor:GUID
+ * @attributes:variable attributes
+ * @size1: size of the first data buffer
+ * @data1: first data buffer
+ * @size2: size of the second data field
+ * @data2: second data buffer
+ * @time:  time of authentication (as seconds since start of epoch)
+ * Result: status code
+ */
+efi_status_t efi_var_mem_ins(u16 *variable_name,
+const efi_guid_t *vendor, u32 attributes,
+const efi_uintn_t size1, const void *data1,
+const efi_uintn_t size2, const void *data2,
+const u64 time);
+
+/**
+ * efi_var_mem_free() - determine free memory for variables
+ *
+ * Return: maximum data size plus variable name size
+ */
+u64 efi_var_mem_free(void);
+
 #endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c87b82db32..f81ec8d277 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -36,6 +36,7 @@ obj-y += efi_runtime.o
 obj-y += efi_setup.o
 obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
 obj-y += efi_var_common.o
+obj-y += efi_var_mem.o
 ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
 obj-y += efi_variable_tee.o
 else
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
new file mode 100644
index 00..ac55d8f8dc
--- /dev/null
+++ b/lib/efi_loader/efi_var_mem.c
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * File interface for UEFI variables
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct efi_var_file __efi_runtime_data *efi_var_buf;
+static struct efi_var_entry __efi_runtime_data *efi_current_var;
+
+/**
+ * efi_var_mem_compare() - compare GUID and name with a variable
+ *
+ * @var:   variable to compare
+ * @guid:  GUID to compare
+ * @name:  variable name to compare
+ * @next:  pointer to next variable
+ * Return: true if match
+ */
+static bool __efi_runtime
+efi_var_mem_compare(struct efi_var_entry *var, const efi_guid_t *guid,
+   const u16 *name, struct efi_var_entry **next)
+{
+   int i;
+   u8 *guid1, *guid2;
+   const u16 *data, *var_name;
+   bool match = true;
+
+   for (guid1 = (u8 *)>guid, guid2 = (u8 *)guid, i = 0;
+i < sizeof(efi_guid_t) && match; ++i)
+   match = (guid1[i] == guid2[i]);
+
+   for (data = var->name, var_name = name;; ++data, ++var_name) {
+   if (match)
+   match = (*data == *var_name);
+   if (!*data)
+   break;
+   }
+
+   ++data;
+
+   if (next)
+   *next = (struct efi_var_entry *)
+   ALIGN((uintptr_t)data + var->length, 8);
+
+   return match;
+}
+
+struct efi_var_entry __efi_runtime
+*efi_var_mem_find(const efi_guid_t *guid, const u16 *name,
+ struct efi_var_entry **next)
+{
+   struct efi_var_entry *var, *last;
+
+   last = (struct efi_var_entry *)
+  ((uintptr_t)efi_var_buf + efi_var_buf->length);
+
+   if (!*name) {
+   if (next) {
+   *next = efi_var_buf->var;
+   if (*next >= last)
+   

[PATCH v2 15/17] efi_loader: use memory based variable storage

2020-07-06 Thread Heinrich Schuchardt
Saving UEFI variable as encoded U-Boot environment variables does not allow
implement run-time support.

Use a memory buffer for storing UEFI variables.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 556 ++
 1 file changed, 93 insertions(+), 463 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index f2f787fc8d..13123e7e41 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -30,145 +30,6 @@ static bool efi_secure_boot;
 static enum efi_secure_mode efi_secure_mode;
 static u8 efi_vendor_keys;

-/*
- * Mapping between EFI variables and u-boot variables:
- *
- *   efi_$guid_$varname = {attributes}(type)value
- *
- * For example:
- *
- *   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
- *  "{ro,boot,run}(blob)"
- *   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
- *  "(blob)0001"
- *
- * The attributes are a comma separated list of these possible
- * attributes:
- *
- *   + ro   - read-only
- *   + boot - boot-services access
- *   + run  - runtime access
- *
- * NOTE: with current implementation, no variables are available after
- * ExitBootServices, and all are persisted (if possible).
- *
- * If not specified, the attributes default to "{boot}".
- *
- * The required type is one of:
- *
- *   + utf8 - raw utf8 string
- *   + blob - arbitrary length hex string
- *
- * Maybe a utf16 type would be useful to for a string value to be auto
- * converted to utf16?
- */
-
-#define PREFIX_LEN (strlen("efi_----_"))
-
-/**
- * efi_to_native() - convert the UEFI variable name and vendor GUID to U-Boot
- *  variable name
- *
- * The U-Boot variable name is a concatenation of prefix 'efi', the hexstring
- * encoded vendor GUID, and the UTF-8 encoded UEFI variable name separated by
- * underscores, e.g. 'efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder'.
- *
- * @native:pointer to pointer to U-Boot variable name
- * @variable_name: UEFI variable name
- * @vendor:vendor GUID
- * Return: status code
- */
-static efi_status_t efi_to_native(char **native, const u16 *variable_name,
- const efi_guid_t *vendor)
-{
-   size_t len;
-   char *pos;
-
-   len = PREFIX_LEN + utf16_utf8_strlen(variable_name) + 1;
-   *native = malloc(len);
-   if (!*native)
-   return EFI_OUT_OF_RESOURCES;
-
-   pos = *native;
-   pos += sprintf(pos, "efi_%pUl_", vendor);
-   utf16_utf8_strcpy(, variable_name);
-
-   return EFI_SUCCESS;
-}
-
-/**
- * prefix() - skip over prefix
- *
- * Skip over a prefix string.
- *
- * @str:   string with prefix
- * @prefix:prefix string
- * Return: string without prefix, or NULL if prefix not found
- */
-static const char *prefix(const char *str, const char *prefix)
-{
-   size_t n = strlen(prefix);
-   if (!strncmp(prefix, str, n))
-   return str + n;
-   return NULL;
-}
-
-/**
- * parse_attr() - decode attributes part of variable value
- *
- * Convert the string encoded attributes of a UEFI variable to a bit mask.
- * TODO: Several attributes are not supported.
- *
- * @str:   value of U-Boot variable
- * @attrp: pointer to UEFI attributes
- * @timep: pointer to time attribute
- * Return: pointer to remainder of U-Boot variable value
- */
-static const char *parse_attr(const char *str, u32 *attrp, u64 *timep)
-{
-   u32 attr = 0;
-   char sep = '{';
-
-   if (*str != '{') {
-   *attrp = EFI_VARIABLE_BOOTSERVICE_ACCESS;
-   return str;
-   }
-
-   while (*str == sep) {
-   const char *s;
-
-   str++;
-
-   if ((s = prefix(str, "ro"))) {
-   attr |= EFI_VARIABLE_READ_ONLY;
-   } else if ((s = prefix(str, "nv"))) {
-   attr |= EFI_VARIABLE_NON_VOLATILE;
-   } else if ((s = prefix(str, "boot"))) {
-   attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
-   } else if ((s = prefix(str, "run"))) {
-   attr |= EFI_VARIABLE_RUNTIME_ACCESS;
-   } else if ((s = prefix(str, "time="))) {
-   attr |= 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
-   hex2bin((u8 *)timep, s, sizeof(*timep));
-   s += sizeof(*timep) * 2;
-   } else if (*str == '}') {
-   break;
-   } else {
-   printf("invalid attribute: %s\n", str);
-   break;
-   }
-
-   str = s;
-   sep = ',';
-   }
-
-   str++;
-
-   *attrp = attr;
-
-   return str;
-}
-
 /**
  * efi_set_secure_state - modify secure boot state variables
  * @secure_boot:   value of SecureBoot
@@ 

[PATCH v2 12/17] efi_loader: optional pointer for ConvertPointer

2020-07-06 Thread Heinrich Schuchardt
If the EFI_OPTIONAL_PTR is set in DebugDisposition, a NULL pointer does not
constitute an invalid parameter.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h| 2 ++
 lib/efi_loader/efi_runtime.c | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index 759d911875..5744f6aed8 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -251,6 +251,8 @@ struct efi_rt_properties_table {
u32 runtime_services_supported;
 };

+#define EFI_OPTIONAL_PTR   0x0001
+
 struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 45baa2fd3e..a4aa1d8b6c 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -512,6 +512,12 @@ efi_convert_pointer(efi_uintn_t debug_disposition, void 
**address)
ret = EFI_INVALID_PARAMETER;
goto out;
}
+   if (!*address) {
+   if (debug_disposition & EFI_OPTIONAL_PTR)
+   return EFI_SUCCESS;
+   else
+   return EFI_INVALID_PARAMETER;
+   }

addr = (uintptr_t)*address;
for (i = 0; i < efi_descriptor_count; i++) {
--
2.27.0



[PATCH v2 13/17] efi_loader: new function efi_memcpy_runtime()

2020-07-06 Thread Heinrich Schuchardt
Provide a memcpy() function that we can use at UEFI runtime.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h |  3 +++
 lib/efi_loader/efi_runtime.c | 19 +++
 2 files changed, 22 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index fe8774f133..bf03a89ca5 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -789,6 +789,9 @@ bool efi_secure_boot_enabled(void);
 bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
 WIN_CERTIFICATE **auth, size_t *auth_len);

+/* runtime implementation of memcpy() */
+void efi_memcpy_runtime(void *dest, const void *src, size_t n);
+
 #else /* CONFIG_IS_ENABLED(EFI_LOADER) */

 /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index a4aa1d8b6c..5b6506fbdc 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -137,6 +137,25 @@ efi_status_t efi_init_runtime_supported(void)
return ret;
 }

+/**
+ * efi_memcpy_runtime() - copy memory area
+ *
+ * At runtime memcpy() is not available.
+ *
+ * @dest:  destination buffer
+ * @src:   source buffer
+ * @n: number of bytes to copy
+ * Return: pointer to destination buffer
+ */
+void __efi_runtime efi_memcpy_runtime(void *dest, const void *src, size_t n)
+{
+   u8 *d = dest;
+   const u8 *s = src;
+
+   for (; n; --n)
+   *d++ = *s++;
+}
+
 /**
  * efi_update_table_header_crc32() - Update crc32 in table header
  *
--
2.27.0



[PATCH v2 09/17] efi_loader: secure boot flag

2020-07-06 Thread Heinrich Schuchardt
In audit mode the UEFI variable SecureBoot is set to zero but the
efi_secure_boot flag is set to true.

The efi_secure_boot flag should match the UEFIvariable SecureBoot.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index b84b86672a..f8a50bb1be 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -190,6 +190,8 @@ static efi_status_t efi_set_secure_state(u8 secure_boot, u8 
setup_mode,
const u32 attributes_rw = EFI_VARIABLE_BOOTSERVICE_ACCESS |
  EFI_VARIABLE_RUNTIME_ACCESS;

+   efi_secure_boot = secure_boot;
+
ret = efi_set_variable_int(L"SecureBoot", _global_variable_guid,
   attributes_ro, sizeof(secure_boot),
   _boot, false);
@@ -240,8 +242,6 @@ static efi_status_t efi_transfer_secure_state(enum 
efi_secure_mode mode)
ret = efi_set_secure_state(1, 0, 0, 1);
if (ret != EFI_SUCCESS)
goto err;
-
-   efi_secure_boot = true;
} else if (mode == EFI_MODE_AUDIT) {
ret = efi_set_variable_int(L"PK", _global_variable_guid,
   EFI_VARIABLE_BOOTSERVICE_ACCESS |
@@ -253,14 +253,10 @@ static efi_status_t efi_transfer_secure_state(enum 
efi_secure_mode mode)
ret = efi_set_secure_state(0, 1, 1, 0);
if (ret != EFI_SUCCESS)
goto err;
-
-   efi_secure_boot = true;
} else if (mode == EFI_MODE_USER) {
ret = efi_set_secure_state(1, 0, 0, 0);
if (ret != EFI_SUCCESS)
goto err;
-
-   efi_secure_boot = true;
} else if (mode == EFI_MODE_SETUP) {
ret = efi_set_secure_state(0, 1, 0, 0);
if (ret != EFI_SUCCESS)
--
2.27.0



[PATCH v2 08/17] efi_loader: read-only AuditMode and DeployedMode

2020-07-06 Thread Heinrich Schuchardt
Set the read only property of the UEFI variables AuditMode and DeployedMode
conforming to the UEFI specification.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index e3b29663a0..b84b86672a 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -183,32 +183,36 @@ static const char *parse_attr(const char *str, u32 
*attrp, u64 *timep)
 static efi_status_t efi_set_secure_state(u8 secure_boot, u8 setup_mode,
 u8 audit_mode, u8 deployed_mode)
 {
-   u32 attributes;
efi_status_t ret;
+   const u32 attributes_ro = EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY;
+   const u32 attributes_rw = EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS;

-   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
-EFI_VARIABLE_RUNTIME_ACCESS |
-EFI_VARIABLE_READ_ONLY;
ret = efi_set_variable_int(L"SecureBoot", _global_variable_guid,
-  attributes, sizeof(secure_boot),
+  attributes_ro, sizeof(secure_boot),
   _boot, false);
if (ret != EFI_SUCCESS)
goto err;

ret = efi_set_variable_int(L"SetupMode", _global_variable_guid,
-  attributes, sizeof(setup_mode),
+  attributes_ro, sizeof(setup_mode),
   _mode, false);
if (ret != EFI_SUCCESS)
goto err;

ret = efi_set_variable_int(L"AuditMode", _global_variable_guid,
-  attributes, sizeof(audit_mode),
-  _mode, false);
+  audit_mode || setup_mode ?
+  attributes_ro : attributes_rw,
+  sizeof(audit_mode), _mode, false);
if (ret != EFI_SUCCESS)
goto err;

ret = efi_set_variable_int(L"DeployedMode",
-  _global_variable_guid, attributes,
+  _global_variable_guid,
+  audit_mode || deployed_mode || setup_mode ?
+  attributes_ro : attributes_rw,
   sizeof(deployed_mode), _mode,
   false);
 err:
--
2.27.0



[PATCH v2 07/17] efi_loader: value of VendorKeys

2020-07-06 Thread Heinrich Schuchardt
According to the UEFI specification the variable VendorKeys is 1 if the
"system is configured to use only vendor-provided keys".

As we do not supply any vendor keys yet the variable VendorKeys must be
zero.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 75 +++
 1 file changed, 15 insertions(+), 60 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index a7de0b4022..e3b29663a0 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -282,45 +282,29 @@ err:
  */
 static efi_status_t efi_init_secure_state(void)
 {
-   enum efi_secure_mode mode;
-   efi_uintn_t size;
+   enum efi_secure_mode mode = EFI_MODE_SETUP;
+   efi_uintn_t size = 0;
efi_status_t ret;

-   /*
-* TODO:
-* Since there is currently no "platform-specific" installation
-* method of Platform Key, we can't say if VendorKeys is 0 or 1
-* precisely.
-*/
-
-   size = 0;
ret = efi_get_variable_int(L"PK", _global_variable_guid,
   NULL, , NULL, NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
if (IS_ENABLED(CONFIG_EFI_SECURE_BOOT))
mode = EFI_MODE_USER;
-   else
-   mode = EFI_MODE_SETUP;
-
-   efi_vendor_keys = 0;
-   } else if (ret == EFI_NOT_FOUND) {
-   mode = EFI_MODE_SETUP;
-   efi_vendor_keys = 1;
-   } else {
-   goto err;
}

ret = efi_transfer_secure_state(mode);
-   if (ret == EFI_SUCCESS)
-   ret = efi_set_variable_int(L"VendorKeys",
-  _global_variable_guid,
-  EFI_VARIABLE_BOOTSERVICE_ACCESS |
-  EFI_VARIABLE_RUNTIME_ACCESS |
-  EFI_VARIABLE_READ_ONLY,
-  sizeof(efi_vendor_keys),
-  _vendor_keys, false);
+   if (ret != EFI_SUCCESS)
+   return ret;

-err:
+   /* As we do not provide vendor keys this variable is always 0. */
+   ret = efi_set_variable_int(L"VendorKeys",
+  _global_variable_guid,
+  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+  EFI_VARIABLE_RUNTIME_ACCESS |
+  EFI_VARIABLE_READ_ONLY,
+  sizeof(efi_vendor_keys),
+  _vendor_keys, false);
return ret;
 }

@@ -998,39 +982,10 @@ out:
if (env_set(native_name, val)) {
ret = EFI_DEVICE_ERROR;
} else {
-   bool vendor_keys_modified = false;
-
-   if ((u16_strcmp(variable_name, L"PK") == 0 &&
-guidcmp(vendor, _global_variable_guid) == 0)) {
-   ret = efi_transfer_secure_state(
-   (delete ? EFI_MODE_SETUP :
- EFI_MODE_USER));
-   if (ret != EFI_SUCCESS)
-   goto err;
-
-   if (efi_secure_mode != EFI_MODE_SETUP)
-   vendor_keys_modified = true;
-   } else if ((u16_strcmp(variable_name, L"KEK") == 0 &&
-guidcmp(vendor, _global_variable_guid) == 0)) {
-   if (efi_secure_mode != EFI_MODE_SETUP)
-   vendor_keys_modified = true;
-   }
-
-   /* update VendorKeys */
-   if (vendor_keys_modified & efi_vendor_keys) {
-   efi_vendor_keys = 0;
-   ret = efi_set_variable_int(
-   L"VendorKeys",
-   _global_variable_guid,
-   EFI_VARIABLE_BOOTSERVICE_ACCESS
-| EFI_VARIABLE_RUNTIME_ACCESS
-| EFI_VARIABLE_READ_ONLY,
-   sizeof(efi_vendor_keys),
-   _vendor_keys,
-   false);
-   } else {
+   if (!u16_strcmp(variable_name, L"PK"))
+   ret = efi_init_secure_state();
+   else
ret = EFI_SUCCESS;
-   }
}

 err:
--
2.27.0



[PATCH v2 06/17] efi_loader: keep attributes in efi_set_variable_int

2020-07-06 Thread Heinrich Schuchardt
Do not change the value of parameter attributes in function
efi_set_variable_int(). This allows to use it later.

Do not use variable attr for different purposes but declare separate
variables (attr and old_attr).

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6706438b26..a7de0b4022 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -827,7 +827,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
efi_uintn_t old_size;
bool append, delete;
u64 time = 0;
-   u32 attr;
+   u32 old_attr;
efi_status_t ret = EFI_SUCCESS;

if (!variable_name || !*variable_name || !vendor ||
@@ -843,8 +843,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,

/* check if a variable exists */
old_size = 0;
-   attr = 0;
-   ret = efi_get_variable_int(variable_name, vendor, ,
+   old_attr = 0;
+   ret = efi_get_variable_int(variable_name, vendor, _attr,
   _size, NULL, );
append = !!(attributes & EFI_VARIABLE_APPEND_WRITE);
attributes &= ~(u32)EFI_VARIABLE_APPEND_WRITE;
@@ -852,15 +852,15 @@ efi_status_t efi_set_variable_int(u16 *variable_name, 
const efi_guid_t *vendor,

/* check attributes */
if (old_size) {
-   if (ro_check && (attr & EFI_VARIABLE_READ_ONLY)) {
+   if (ro_check && (old_attr & EFI_VARIABLE_READ_ONLY)) {
ret = EFI_WRITE_PROTECTED;
goto err;
}

/* attributes won't be changed */
if (!delete &&
-   ((ro_check && attr != attributes) ||
-(!ro_check && ((attr & ~(u32)EFI_VARIABLE_READ_ONLY)
+   ((ro_check && old_attr != attributes) ||
+(!ro_check && ((old_attr & ~(u32)EFI_VARIABLE_READ_ONLY)
!= (attributes & 
~(u32)EFI_VARIABLE_READ_ONLY) {
ret = EFI_INVALID_PARAMETER;
goto err;
@@ -902,7 +902,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) {
ret = efi_variable_authenticate(variable_name, vendor,
_size, ,
-   attributes, ,
+   attributes, _attr,
);
if (ret != EFI_SUCCESS)
goto err;
@@ -936,7 +936,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
goto err;
}
ret = efi_get_variable_int(variable_name, vendor,
-  , _size, old_data, NULL);
+  _attr, _size, old_data, 
NULL);
if (ret != EFI_SUCCESS)
goto err;
} else {
@@ -962,8 +962,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
   EFI_VARIABLE_RUNTIME_ACCESS |
   EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS);
s += sprintf(s, "{");
-   while (attributes) {
-   attr = 1 << (ffs(attributes) - 1);
+   for (u32 attr_rem = attributes; attr_rem;) {
+   u32 attr = 1 << (ffs(attr_rem) - 1);

if (attr == EFI_VARIABLE_READ_ONLY) {
s += sprintf(s, "ro");
@@ -979,8 +979,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
s = bin2hex(s, (u8 *), sizeof(time));
}

-   attributes &= ~attr;
-   if (attributes)
+   attr_rem &= ~attr;
+   if (attr_rem)
s += sprintf(s, ",");
}
s += sprintf(s, "}");
--
2.27.0



[PATCH v2 02/17] efi_loader: display RO attribute in printenv -e

2020-07-06 Thread Heinrich Schuchardt
Let the 'printenv -e' command display the read only flag.
If the variable is time authenticated write the time stamp.

Avoid EFI_CALL() when calling SetVariable() and GetVariable().

Signed-off-by: Heinrich Schuchardt 
---
 cmd/nvedit_efi.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index 29cad38e19..3f61d5d6cc 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -9,11 +9,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -34,6 +36,7 @@ static const struct {
{EFI_VARIABLE_RUNTIME_ACCESS, "RT"},
{EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS, "AW"},
{EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, "AT"},
+   {EFI_VARIABLE_READ_ONLY, "RO"},
 };

 static const struct {
@@ -87,20 +90,22 @@ static void efi_dump_single_var(u16 *name, const efi_guid_t 
*guid, bool verbose)
 {
u32 attributes;
u8 *data;
+   u64 time;
+   struct rtc_time tm;
efi_uintn_t size;
int count, i;
efi_status_t ret;

data = NULL;
size = 0;
-   ret = EFI_CALL(efi_get_variable(name, guid, , , data));
+   ret = efi_get_variable_int(name, guid, , , data, );
if (ret == EFI_BUFFER_TOO_SMALL) {
data = malloc(size);
if (!data)
goto out;

-   ret = EFI_CALL(efi_get_variable(name, guid, , ,
-   data));
+   ret = efi_get_variable_int(name, guid, , ,
+  data, );
}
if (ret == EFI_NOT_FOUND) {
printf("Error: \"%ls\" not defined\n", name);
@@ -109,13 +114,16 @@ static void efi_dump_single_var(u16 *name, const 
efi_guid_t *guid, bool verbose)
if (ret != EFI_SUCCESS)
goto out;

-   printf("%ls:\n%s:", name, efi_guid_to_str(guid));
+   rtc_to_tm(time, );
+   printf("%ls:\n%s:\n", name, efi_guid_to_str(guid));
+   if (attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)
+   printf("%04d-%02d-%02d %02d:%02d:%02d\n", tm.tm_year,
+  tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
+   printf("");
for (count = 0, i = 0; i < ARRAY_SIZE(efi_var_attrs); i++)
if (attributes & efi_var_attrs[i].mask) {
if (count)
putc('|');
-   else
-   putc(' ');
count++;
puts(efi_var_attrs[i].text);
}
@@ -592,8 +600,8 @@ int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int 
argc,
p = var_name16;
utf8_utf16_strncpy(, var_name, len + 1);

-   ret = EFI_CALL(efi_set_variable(var_name16, , attributes,
-   size, value));
+   ret = efi_set_variable_int(var_name16, , attributes, size, value,
+  true);
unmap_sysmem(value);
if (ret == EFI_SUCCESS) {
ret = CMD_RET_SUCCESS;
--
2.27.0



[PATCH v2 05/17] efi_loader: simplify boot manager

2020-07-06 Thread Heinrich Schuchardt
Simplify the implementation of the UEFI boot manager:

* avoid EFI_CALL for SetVariable() and GetVariable()
* remove unnecessary type conversions

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_bootmgr.c | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index e268e9c4b8..e03198b57a 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 static const struct efi_boot_services *bs;
@@ -147,15 +148,14 @@ unsigned long efi_serialize_load_option(struct 
efi_load_option *lo, u8 **data)
 static void *get_var(u16 *name, const efi_guid_t *vendor,
 efi_uintn_t *size)
 {
-   efi_guid_t *v = (efi_guid_t *)vendor;
efi_status_t ret;
void *buf = NULL;

*size = 0;
-   EFI_CALL(ret = rs->get_variable(name, v, NULL, size, buf));
+   ret = efi_get_variable_int(name, vendor, NULL, size, buf, NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
buf = malloc(*size);
-   EFI_CALL(ret = rs->get_variable(name, v, NULL, size, buf));
+   ret = efi_get_variable_int(name, vendor, NULL, size, buf, NULL);
}

if (ret != EFI_SUCCESS) {
@@ -219,10 +219,9 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t 
*handle)
attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
 EFI_VARIABLE_RUNTIME_ACCESS;
size = sizeof(n);
-   ret = EFI_CALL(efi_set_variable(
-   L"BootCurrent",
-   (efi_guid_t *)_global_variable_guid,
-   attributes, size, ));
+   ret = efi_set_variable_int(L"BootCurrent",
+  _global_variable_guid,
+  attributes, size, , false);
if (ret != EFI_SUCCESS) {
if (EFI_CALL(efi_unload_image(*handle))
!= EFI_SUCCESS)
@@ -262,22 +261,19 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
rs = systab.runtime;

/* BootNext */
-   bootnext = 0;
size = sizeof(bootnext);
-   ret = EFI_CALL(efi_get_variable(L"BootNext",
-   (efi_guid_t *)_global_variable_guid,
-   NULL, , ));
+   ret = efi_get_variable_int(L"BootNext",
+  _global_variable_guid,
+  NULL, , , NULL);
if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
/* BootNext does exist here */
if (ret == EFI_BUFFER_TOO_SMALL || size != sizeof(u16))
log_err("BootNext must be 16-bit integer\n");

/* delete BootNext */
-   ret = EFI_CALL(efi_set_variable(
-   L"BootNext",
-   (efi_guid_t *)_global_variable_guid,
-   EFI_VARIABLE_NON_VOLATILE, 0,
-   ));
+   ret = efi_set_variable_int(L"BootNext",
+  _global_variable_guid,
+  0, 0, NULL, false);

/* load BootNext */
if (ret == EFI_SUCCESS) {
--
2.27.0



[PATCH v2 03/17] efi_loader: separate UEFI variable API from implemementation

2020-07-06 Thread Heinrich Schuchardt
Separate the remaining UEFI variable API functions GetNextVariableName and
QueryVariableInfo() from internal functions implementing them.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_variable.h| 39 +++
 lib/efi_loader/efi_var_common.c   | 62 +++
 lib/efi_loader/efi_variable.c | 57 
 lib/efi_loader/efi_variable_tee.c | 55 +--
 4 files changed, 134 insertions(+), 79 deletions(-)

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 6789118eba..3ba274fce1 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -40,4 +40,43 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
  u32 attributes, efi_uintn_t data_size,
  const void *data, bool ro_check);

+/**
+ * efi_get_next_variable_name_int() - enumerate the current variable names
+ *
+ * @variable_name_size:size of variable_name buffer in byte
+ * @variable_name: name of uefi variable's name in u16
+ * @vendor:vendor's guid
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * Return: status code
+ */
+efi_status_t efi_get_next_variable_name_int(efi_uintn_t *variable_name_size,
+   u16 *variable_name,
+   efi_guid_t *vendor);
+
+/**
+ * efi_query_variable_info_int() - get information about EFI variables
+ *
+ * This function implements the QueryVariableInfo() runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @attributes:bitmask to select variables to 
be
+ * queried
+ * @maximum_variable_storage_size: maximum size of storage area for the
+ * selected variable types
+ * @remaining_variable_storage_size:   remaining size of storage are for the
+ * selected variable types
+ * @maximum_variable_size: maximum size of a variable of the
+ * selected type
+ * Returns:status code
+ */
+efi_status_t efi_query_variable_info_int(u32 attributes,
+u64 *maximum_variable_storage_size,
+u64 *remaining_variable_storage_size,
+u64 *maximum_variable_size);
+
 #endif
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index 6a4efa3f27..1e2be1135b 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -76,3 +76,65 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,

return EFI_EXIT(ret);
 }
+
+/**
+ * efi_get_next_variable_name() - enumerate the current variable names
+ *
+ * @variable_name_size:size of variable_name buffer in byte
+ * @variable_name: name of uefi variable's name in u16
+ * @vendor:vendor's guid
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t *variable_name_size,
+  u16 *variable_name,
+  efi_guid_t *vendor)
+{
+   efi_status_t ret;
+
+   EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
+
+   ret = efi_get_next_variable_name_int(variable_name_size, variable_name,
+vendor);
+
+   return EFI_EXIT(ret);
+}
+
+/**
+ * efi_query_variable_info() - get information about EFI variables
+ *
+ * This function implements the QueryVariableInfo() runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @attributes:bitmask to select variables to 
be
+ * queried
+ * @maximum_variable_storage_size: maximum size of storage area for the
+ * selected variable types
+ * @remaining_variable_storage_size:   remaining size of storage are for the
+ * selected variable types
+ * @maximum_variable_size: maximum size of a variable of the
+ * selected type
+ * Returns:status code
+ */
+efi_status_t EFIAPI efi_query_variable_info(
+   u32 attributes, u64 *maximum_variable_storage_size,
+   u64 *remaining_variable_storage_size,
+   u64 *maximum_variable_size)
+{
+   efi_status_t ret;
+
+   EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
+

[PATCH v2 04/17] efi_loader: OsIndicationsSupported, PlatformLangCodes

2020-07-06 Thread Heinrich Schuchardt
UEFI variables OsIndicationsSupported, PlatformLangCodes should be read
only.

Avoid EFI_CALL() for SetVariable().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_setup.c | 59 --
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index a3b05a4a9b..6196c0a06c 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 

 #define OBJ_LIST_NOT_INITIALIZED 1

@@ -40,12 +41,13 @@ static efi_status_t efi_init_platform_lang(void)
 * Variable PlatformLangCodes defines the language codes that the
 * machine can support.
 */
-   ret = EFI_CALL(efi_set_variable(L"PlatformLangCodes",
-   _global_variable_guid,
-   EFI_VARIABLE_BOOTSERVICE_ACCESS |
-   EFI_VARIABLE_RUNTIME_ACCESS,
-   sizeof(CONFIG_EFI_PLATFORM_LANG_CODES),
-   CONFIG_EFI_PLATFORM_LANG_CODES));
+   ret = efi_set_variable_int(L"PlatformLangCodes",
+  _global_variable_guid,
+  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+  EFI_VARIABLE_RUNTIME_ACCESS |
+  EFI_VARIABLE_READ_ONLY,
+  sizeof(CONFIG_EFI_PLATFORM_LANG_CODES),
+  CONFIG_EFI_PLATFORM_LANG_CODES, false);
if (ret != EFI_SUCCESS)
goto out;

@@ -53,9 +55,9 @@ static efi_status_t efi_init_platform_lang(void)
 * Variable PlatformLang defines the language that the machine has been
 * configured for.
 */
-   ret = EFI_CALL(efi_get_variable(L"PlatformLang",
-   _global_variable_guid,
-   NULL, _size, ));
+   ret = efi_get_variable_int(L"PlatformLang",
+  _global_variable_guid,
+  NULL, _size, , NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
/* The variable is already set. Do not change it. */
ret = EFI_SUCCESS;
@@ -70,12 +72,12 @@ static efi_status_t efi_init_platform_lang(void)
if (pos)
*pos = 0;

-   ret = EFI_CALL(efi_set_variable(L"PlatformLang",
-   _global_variable_guid,
-   EFI_VARIABLE_NON_VOLATILE |
-   EFI_VARIABLE_BOOTSERVICE_ACCESS |
-   EFI_VARIABLE_RUNTIME_ACCESS,
-   1 + strlen(lang), lang));
+   ret = efi_set_variable_int(L"PlatformLang",
+  _global_variable_guid,
+  EFI_VARIABLE_NON_VOLATILE |
+  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+  EFI_VARIABLE_RUNTIME_ACCESS,
+  1 + strlen(lang), lang, false);
 out:
if (ret != EFI_SUCCESS)
printf("EFI: cannot initialize platform language settings\n");
@@ -96,13 +98,13 @@ static efi_status_t efi_init_secure_boot(void)
};
efi_status_t ret;

-   /* TODO: read-only */
-   ret = EFI_CALL(efi_set_variable(L"SignatureSupport",
-   _global_variable_guid,
-   EFI_VARIABLE_BOOTSERVICE_ACCESS
-| EFI_VARIABLE_RUNTIME_ACCESS,
-   sizeof(signature_types),
-   _types));
+   ret = efi_set_variable_int(L"SignatureSupport",
+  _global_variable_guid,
+  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+  EFI_VARIABLE_RUNTIME_ACCESS |
+  EFI_VARIABLE_READ_ONLY,
+  sizeof(signature_types),
+  _types, false);
if (ret != EFI_SUCCESS)
printf("EFI: cannot initialize SignatureSupport variable\n");

@@ -160,12 +162,13 @@ efi_status_t efi_init_obj_list(void)
goto out;

/* Indicate supported features */
-   ret = EFI_CALL(efi_set_variable(L"OsIndicationsSupported",
-   _global_variable_guid,
-   EFI_VARIABLE_BOOTSERVICE_ACCESS |
-   EFI_VARIABLE_RUNTIME_ACCESS,
-   sizeof(os_indications_supported),
-   _indications_supported));
+   ret = 

[PATCH v2 01/17] efi_loader: prepare for read only OP-TEE variables

2020-07-06 Thread Heinrich Schuchardt
We currently have two implementations of UEFI variables:

* variables provided via an OP-TEE module
* variables stored in the U-Boot environment

Read only variables are up to now only implemented in the U-Boot
environment implementation.

Provide a common interface for both implementations that allows handling
read-only variables.

As variable access is limited to very few source files put variable
related definitions into new include efi_variable.h instead of efi_loader.

Signed-off-by: Heinrich Schuchardt 
---
 doc/api/efi.rst   |   2 +
 include/efi_variable.h|  43 
 lib/efi_loader/Makefile   |   1 +
 lib/efi_loader/efi_var_common.c   |  78 +
 lib/efi_loader/efi_variable.c | 175 --
 lib/efi_loader/efi_variable_tee.c |  75 -
 6 files changed, 193 insertions(+), 181 deletions(-)
 create mode 100644 include/efi_variable.h
 create mode 100644 lib/efi_loader/efi_var_common.c

diff --git a/doc/api/efi.rst b/doc/api/efi.rst
index d5114f05b3..cb2a1c897e 100644
--- a/doc/api/efi.rst
+++ b/doc/api/efi.rst
@@ -93,6 +93,8 @@ Runtime services
 Variable services
 ~

+.. kernel-doc:: include/efi_variable.h
+   :internal:
 .. kernel-doc:: lib/efi_loader/efi_variable.c
:internal:

diff --git a/include/efi_variable.h b/include/efi_variable.h
new file mode 100644
index 00..6789118eba
--- /dev/null
+++ b/include/efi_variable.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020, Heinrich Schuchardt 
+ */
+
+#ifndef _EFI_VARIABLE_H
+#define _EFI_VARIABLE_H
+
+#include 
+
+#define EFI_VARIABLE_READ_ONLY BIT(31)
+
+/**
+ * efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data:  buffer to which the variable value is copied
+ * @timep: authentication time (seconds since start of epoch)
+ * Return: status code
+ */
+efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 *attributes, efi_uintn_t *data_size,
+ void *data, u64 *timep);
+
+/**
+ * efi_set_variable() - set value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer with the variable value
+ * @data:  buffer with the variable value
+ * @ro_check:  check the read only read only bit in attributes
+ * Return: status code
+ */
+efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 attributes, efi_uintn_t data_size,
+ const void *data, bool ro_check);
+
+#endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 57c7e66ea0..7eddd7ef37 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -35,6 +35,7 @@ obj-y += efi_root_node.o
 obj-y += efi_runtime.o
 obj-y += efi_setup.o
 obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
+obj-y += efi_var_common.o
 ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
 obj-y += efi_variable_tee.o
 else
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
new file mode 100644
index 00..6a4efa3f27
--- /dev/null
+++ b/lib/efi_loader/efi_var_common.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UEFI runtime variable services
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt 
+ */
+
+#include 
+#include 
+#include 
+
+/**
+ * efi_efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * This function implements the GetVariable runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data:  buffer to which the variable value is copied
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
+const efi_guid_t *vendor, u32 *attributes,
+efi_uintn_t *data_size, void *data)
+{
+   efi_status_t ret;
+
+   EFI_ENTRY("\"%ls\" %pUl %p %p %p", variable_name, vendor, attributes,
+ data_size, data);
+
+   ret = efi_get_variable_int(variable_name, vendor, attributes,
+  data_size, data, NULL);
+
+   /* Remove EFI_VARIABLE_READ_ONLY flag */
+   if (attributes)
+   *attributes &= 

[PATCH v2 00/17] efi_loader: non-volatile and runtime variables

2020-07-06 Thread Heinrich Schuchardt
Up to now UEFI variables where stored in U-Boot environment variables.
Saving UEFI variables was not possible without saving the U-Boot
environment variables.

With this patch series file ubootefi.var in the EFI system partition is
used for saving UEFI variables.

Furthermore the UEFI variables are exposed for reading at runtime.

v2:
Rebase the series to consider OP-TEE based variables and
authenticated variables.
Do not enable SetVariable() at runtime as we cannot persist
non-volatile variables at runtime.
Display read-only attribute in printenv -e.

Heinrich Schuchardt (17):
  efi_loader: prepare for read only OP-TEE variables
  efi_loader: display RO attribute in printenv -e
  efi_loader: separate UEFI variable API from implemementation
  efi_loader: OsIndicationsSupported, PlatformLangCodes
  efi_loader: simplify boot manager
  efi_loader: keep attributes in efi_set_variable_int
  efi_loader: value of VendorKeys
  efi_loader: read-only AuditMode and DeployedMode
  efi_loader: secure boot flag
  efi_loader: UEFI variable persistence
  efi_loader: export efi_convert_pointer()
  efi_loader: optional pointer for ConvertPointer
  efi_loader: new function efi_memcpy_runtime()
  efi_loader: memory buffer for variables
  efi_loader: use memory based variable storage
  efi_loader: enable UEFI variables at runtime
  efi_selftest: adjust runtime test for variables

 cmd/nvedit_efi.c  |  24 +-
 doc/api/efi.rst   |   2 +
 include/efi_api.h |   2 +
 include/efi_loader.h  |   6 +
 include/efi_variable.h| 198 +
 lib/efi_loader/Kconfig|   8 +
 lib/efi_loader/Makefile   |   3 +
 lib/efi_loader/efi_bootmgr.c  |  28 +-
 lib/efi_loader/efi_runtime.c  |  35 +-
 lib/efi_loader/efi_setup.c|  59 +-
 lib/efi_loader/efi_var_common.c   | 140 +++
 lib/efi_loader/efi_var_file.c | 239 +
 lib/efi_loader/efi_var_mem.c  | 266 ++
 lib/efi_loader/efi_variable.c | 823 --
 lib/efi_loader/efi_variable_tee.c | 130 +--
 .../efi_selftest_variables_runtime.c  |  13 +-
 16 files changed, 1154 insertions(+), 822 deletions(-)
 create mode 100644 include/efi_variable.h
 create mode 100644 lib/efi_loader/efi_var_common.c
 create mode 100644 lib/efi_loader/efi_var_file.c
 create mode 100644 lib/efi_loader/efi_var_mem.c

--
2.27.0



Re: [PATCH] x86: remove unused setup_pcat_compatibility() stub

2020-07-06 Thread Masahiro Yamada
Simon,

On Tue, Jul 7, 2020 at 3:44 AM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Sat, 4 Jul 2020 at 11:43, Masahiro Yamada  wrote:
> >
> > 'git grep' did not find any user of this stub.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/x86/include/asm/u-boot-x86.h |  2 --
> >  arch/x86/lib/zimage.c | 10 --
> >  2 files changed, 12 deletions(-)
> >
>
> See also: 
> http://patchwork.ozlabs.org/project/uboot/patch/20200615035738.248710-21-...@chromium.org/


That's fine if you are removing this function.

Thanks.


-- 
Best Regards
Masahiro Yamada


[PATCH 1/1] efi_loader: NULL dereference in efi_convert_pointer

2020-07-06 Thread Heinrich Schuchardt
Avoid a possible NULL pointer dereference in efi_convert_pointer().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_runtime.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index c0bd99b867..121e2f65c6 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -499,7 +499,7 @@ static __efi_runtime efi_status_t EFIAPI 
efi_convert_pointer_runtime(
 static __efi_runtime efi_status_t EFIAPI efi_convert_pointer(
efi_uintn_t debug_disposition, void **address)
 {
-   efi_physical_addr_t addr = (uintptr_t)*address;
+   efi_physical_addr_t addr;
efi_uintn_t i;
efi_status_t ret = EFI_NOT_FOUND;

@@ -515,6 +515,7 @@ static __efi_runtime efi_status_t EFIAPI 
efi_convert_pointer(
goto out;
}

+   addr = (uintptr_t)*address;
for (i = 0; i < efi_descriptor_count; i++) {
struct efi_mem_desc *map = (void *)efi_virtmap +
   (efi_descriptor_size * i);
--
2.27.0



Re: [RFC PATCH 01/16] patman: Use test_util to show test results

2020-07-06 Thread Daniel Axtens
Simon Glass  writes:

> Hi Daniel,
>
> On Sun, 5 Jul 2020 at 22:50, Daniel Axtens  wrote:
>>
>> Daniel Axtens  writes:
>>
>> > Hi Simon,
>> >
>> > I can't see a cover letter so apologies if I've misunderstood something
>> > basic, but this doesn't appear to apply to the patchwork tree - I'm
>> > guessing the patchwork relevance is with regards to the last few patches
>> > that (AFAICT) parse the patchwork web interface for information?
>>
>> Ah, nevermind, the cover letter got caught in moderation. I've released it.
>>
>> pwclient speaks the old, less documented XML-RPC API. We have a new
>> REST API which is much better documented, and is explorable
>> (e.g. https://patchwork.ozlabs.org/api/ and
>> https://patchwork.readthedocs.io/en/latest/api/rest/ )
>>
>> > I haven't fully digested the patches (and I lack a lot of context) but
>> > is there a reason the patchwork API isn't able to meet your needs here?
>> > (And if so, could we extend it rather than having you parse the frontend?)
>>
>> So these questions still stand but for the REST API.
>
> So use the REST API instead of the web page? That sounds fine to me.
> Is it generally enabled on patchwork servers?

I mean patman is your code so it's ultimately not my call :P But yes,
I'd strongly prefer you used the REST API! It is enabled on ozlabs.org
and kernel.org and has been for a while (~a couple of years).

> What is the status of pwclient? Is it dead? Is there a replacement?
> I'd love to use a Python library if one exists.

Stephen F is the expert on the client stuff, so I'm not going to make a
call on the status of pwclient. All I am confident to say is that I have
migrated to using 'git-pw' and I recommend others do so to too.

I'm not sure if a dedicated Python client library exists: the last time
I wanted to write a Python client app I found it simple enough to just
use the JSON that the API provides directly. But the place I'd start
with is git-pw.

Regards,
Daniel

> Regards,
> SImon


Re: Cover Letter of Patchsets

2020-07-06 Thread Leo Liang
Dear Wolfgang,

On Mon, Jul 06, 2020 at 08:03:46PM +0800, Wolfgang Denk wrote:
> Dear Leo,
> 
> In message <20200706023510.gb2...@andestech.com> you wrote:
> >
> > I am Leo, just recently joined the community.
> > and been picking up the guide line of uboot's development.
> >
> > I am a bit curious about the policy on the cover letter of patchsets.
> > Is cover letter mandatory ?
> 
> No, it is not really mandatoryh, but strongl recommended for patch
> series.
> 
> > IMHO, making it mandatory, especially on patchsets that consist of
> > more than 1 patch, is more than useful and of great advantages.
> 
> For single patches a cover letter usually makes little sense.
> 
> > 1. Making patches clearer for peer and maintainer review
> ...
> > 2. Helping the author better organize the patchset
> ...
> > In all, I think it would be nice to write cover letter to introduce the 
> > work.
> 
> All your arguments make a lot of sense, indeed.
> 
> > If I miss anything or misunderstand anything please let me know, thanks in 
> > advance.
> 
> Please keep in mind that an inherent property of the cover letter is
> that it is NOT part of the patches itself, i. e. it helps only
> during the review process, but not any time later when someone tries
> to understand the code from reading the git commit logs.
> 
> 
> So the essential information to understand the purpose and the
> implementation (and ideally also how it has been tested / can be
> tested) should always be part of the commit messages itself.
> 
> THe cover letter can summarize such information and provide the
> overview information for a patch series.  Also it should commet on
> the changes between versions of the patch series, if these are
> needed (especially when major rework is done between submissions).
> 
> But it is only supplementary information which gets lost when the
> patches are pulled into the git repository.
> 

Understood!
Thank you very much for the clarification.

Best regards,
Leo


Re: [PATCH v1 07/43] dm: acpi: Add support for the NHLT table

2020-07-06 Thread Bin Meng
Hi Simon,

On Tue, Jul 7, 2020 at 3:22 AM Simon Glass  wrote:
>
> Hi Bin,
>
> On Thu, 2 Jul 2020 at 22:33, Bin Meng  wrote:
> >
> > Hi Simon,
> >
> > On Fri, Jul 3, 2020 at 11:50 AM Simon Glass  wrote:
> > >
> > > Hi Bin,
> > >
> > > On Thu, 2 Jul 2020 at 18:54, Bin Meng  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Jul 3, 2020 at 8:46 AM Simon Glass  wrote:
> > > > >
> > > > > Hi Bin,
> > > > >
> > > > > On Mon, 29 Jun 2020 at 20:49, Bin Meng  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > The Intel Non-High-Definition-Audio Link Table (NHLT) table 
> > > > > > > describes the
> > > > > > > audio codecs and connections in a system. Various devices can 
> > > > > > > contribute
> > > > > > > information to produce the table.
> > > > > > >
> > > > > > > Add core support for this, based on a structure which is built up 
> > > > > > > through
> > > > > > > calls to the driver.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass 
> > > > > > > ---
> > > > > > >
> > > > > > >  drivers/core/acpi.c | 15 +++
> > > > > > >  include/dm/acpi.h   | 26 ++
> > > > > > >  2 files changed, 41 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> > > > > > > index ea304a3067..a5053fec6f 100644
> > > > > > > --- a/drivers/core/acpi.c
> > > > > > > +++ b/drivers/core/acpi.c
> > > > > > > @@ -31,6 +31,7 @@ enum method_t {
> > > > > > > METHOD_WRITE_TABLES,
> > > > > > > METHOD_FILL_SSDT,
> > > > > > > METHOD_INJECT_DSDT,
> > > > > > > +   METHOD_SETUP_NHLT,
> > > > > >
> > > > > > Do we really need to promote this to be an ACPI core method? Can we
> > > > > > reuse the SSDT/DSDT one?
> > > > >
> > > > > I don't think so. Those two are for a particular purpose. In fact NHLT
> > > > > is generated while doing SSDT I think. The idea is that drivers that
> > > > > want to contribute to NHLT can do so. But we cannot use the SSDT
> > > > > mechanism since each driver contributes only a part of the info, and
> > > > > we need something else to bring it all together.
> > > >
> > > > Will there be only one device that sets up the NHLT info?
> > >
> > > WIth coral it is two devices. I'm not sure of the maximum, but I
> > > suppose it depends on the audio codecs present.
> >
> > Could we make this method to be provided by the codec device, instead
> > of a generic ACPI core method?
>
> The codec device does implement this. See the drivers where they
> actually implement the NHLT method.
>
> This is definitely an ACPI-specific thing, so I think we need core
> support for iterating through drivers that want to provide this info.

My concern is that this is not generic enough to promote this to ACPI core.

I wanted to have something like this:

Create a codec uclass driver, and in the code uclass driver, create an
op that is used to set up the NHLT infor if ACPI_GEN is on.

Regards,
Bin


[PATCH] Revert "riscv: sifive: fu540: Add gpio-restart support"

2020-07-06 Thread Tom Rini
As part of merging the next branch in to master, the sifive_fu540 will
fail to link:
riscv64-linux-ld.bfd: lib/built-in.o: in function `panic_finish':
lib/panic.c:28: undefined reference to `do_reset'
make[2]: *** [spl/u-boot-spl] Error 1
make[1]: *** [spl/u-boot-spl] Error 2
make: *** [sub-make] Error 2

And while the "fix the build" option of enabling CONFIG_SPL_SYSRESET may
solve the issue, it is unclear that it is the correct path exactly.  For
the moment, I am reverting this commit and take a "revert the revert"
and proper fix as soon as it's available.

This reverts commit cdae446461191714d692190da1ad4344398adc57.

Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Anup Patel 
Cc: Atish Patra 
Cc: Bin Meng 
Signed-off-by: Tom Rini 
---
 board/sifive/fu540/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 6f6568196561..86193d7668be 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -65,7 +65,5 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply SMP
imply MISC
imply SIFIVE_OTP
-   imply SYSRESET
-   imply SYSRESET_GPIO
 
 endif
-- 
2.17.1



Re: [PATCH v3 14/14] test: sandbox: add test for erase command

2020-07-06 Thread Stephen Warren
On 6/25/20 1:59 AM, Patrick Delaunay wrote:
> Add test for the erase command tested on ENV in EXT4.

Acked-by: Stephen Warren 


Re: [PATCH v3 11/14] test: environment in ext4

2020-07-06 Thread Stephen Warren
On 6/25/20 1:59 AM, Patrick Delaunay wrote:
> Add basic test to persistent environment in ext4:
> save and load in host ext4 file 'uboot.env'.
> 
> On first execution an empty EXT4 file system is created in
> persistent data dir: env.ext4.img.

Acked-by: Stephen Warren 

A couple nits below; feel free not to skip them, but if you end up
sending another revision for other reasons, may as well fix them.

> diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py

> +from subprocess import call, check_call, CalledProcessError

I believe only CalledProcessError is used now.

> +def test_env_ext4(state_test_env):
> +
> +"""Test ENV in EXT4 on sandbox."""
> +c = state_test_env.u_boot_console
> +fs_img = ''

"None" would be a better unset value.


[PATCH v4 09/11] test: dm: rtc: add test of dm_rtc_read, dm_rtc_write

2020-07-06 Thread Rasmus Villemoes
Define a few aux registers and check that they can be read/written
individually. Also check that one can access the time-keeping
registers directly and get the expected results.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 arch/sandbox/include/asm/rtc.h |  5 
 test/dm/rtc.c  | 45 ++
 2 files changed, 50 insertions(+)

diff --git a/arch/sandbox/include/asm/rtc.h b/arch/sandbox/include/asm/rtc.h
index 1fbfea7999..5bb032f59f 100644
--- a/arch/sandbox/include/asm/rtc.h
+++ b/arch/sandbox/include/asm/rtc.h
@@ -21,6 +21,11 @@ enum {
 
REG_RESET   = 0x20,
 
+   REG_AUX0= 0x30,
+   REG_AUX1,
+   REG_AUX2,
+   REG_AUX3,
+
REG_COUNT   = 0x80,
 };
 
diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index e072fd618b..ff1bc7b7f6 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,50 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_rtc_set_get, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+static int dm_test_rtc_read_write(struct unit_test_state *uts)
+{
+   struct rtc_time time;
+   struct udevice *dev, *emul;
+   long old_offset;
+   u8 buf[4], reg;
+
+   ut_assertok(uclass_get_device(UCLASS_RTC, 0, ));
+
+   memcpy(buf, "car", 4);
+   ut_assertok(dm_rtc_write(dev, REG_AUX0, buf, 4));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(dm_rtc_read(dev, REG_AUX0, buf, 4));
+   ut_asserteq(memcmp(buf, "car", 4), 0);
+
+   reg = 'b';
+   ut_assertok(dm_rtc_write(dev, REG_AUX0, , 1));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(dm_rtc_read(dev, REG_AUX0, buf, 4));
+   ut_asserteq(memcmp(buf, "bar", 4), 0);
+
+   reg = 't';
+   ut_assertok(dm_rtc_write(dev, REG_AUX2, , 1));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(dm_rtc_read(dev, REG_AUX1, buf, 3));
+   ut_asserteq(memcmp(buf, "at", 3), 0);
+
+   ut_assertok(i2c_emul_find(dev, ));
+   ut_assert(emul != NULL);
+
+   old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
+   ut_assertok(dm_rtc_get(dev, ));
+
+   ut_assertok(dm_rtc_read(dev, REG_SEC, , 1));
+   ut_asserteq(time.tm_sec, reg);
+   ut_assertok(dm_rtc_read(dev, REG_MDAY, , 1));
+   ut_asserteq(time.tm_mday, reg);
+
+   sandbox_i2c_rtc_set_offset(emul, true, old_offset);
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /* Reset the time */
 static int dm_test_rtc_reset(struct unit_test_state *uts)
 {
-- 
2.23.0



[PATCH v4 11/11] test: dm: rtc: add tests of rtc shell command

2020-07-06 Thread Rasmus Villemoes
Add tests of the "list", "read" and "write" subcommands of the rtc
shell command.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 test/dm/rtc.c | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index ff1bc7b7f6..dd037a6e17 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -175,6 +176,63 @@ static int dm_test_rtc_read_write(struct unit_test_state 
*uts)
 }
 DM_TEST(dm_test_rtc_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+/* Test 'rtc list' command */
+static int dm_test_rtc_cmd_list(struct unit_test_state *uts)
+{
+   console_record_reset();
+
+   run_command("rtc list", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_nextline("RTC #1 - rtc@61");
+   ut_assert_console_end();
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_cmd_list, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test 'rtc read' and 'rtc write' commands */
+static int dm_test_rtc_cmd_rw(struct unit_test_state *uts)
+{
+   console_record_reset();
+
+   run_command("rtc dev 0", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_console_end();
+
+   run_command("rtc write 0x30 aabb", 0);
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("0030: aa bb 
 ..");
+   ut_assert_console_end();
+
+   run_command("rtc dev 1", 0);
+   ut_assert_nextline("RTC #1 - rtc@61");
+   ut_assert_console_end();
+
+   run_command("rtc write 0x30 ccdd", 0);
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("0030: cc dd 
 ..");
+   ut_assert_console_end();
+
+   /*
+* Switch back to device #0, check that its aux registers
+* still have the same values.
+*/
+   run_command("rtc dev 0", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("0030: aa bb 
 ..");
+   ut_assert_console_end();
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_cmd_rw, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /* Reset the time */
 static int dm_test_rtc_reset(struct unit_test_state *uts)
 {
-- 
2.23.0



[PATCH v4 10/11] sandbox: add rtc command to defconfigs

2020-07-06 Thread Rasmus Villemoes
In order to allow adding unit tests of the rtc command, add it to the
various sandbox defconfigs.

Signed-off-by: Rasmus Villemoes 
---
 configs/sandbox64_defconfig| 1 +
 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 0f9a27c39c..0d0a4fcec5 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -59,6 +59,7 @@ CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_ETHSW=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_RTC=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_SOUND=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 6f450aa637..1061933643 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -68,6 +68,7 @@ CONFIG_CMD_ETHSW=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_RTC=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_SOUND=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 05ce9bda37..2be428ba27 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -48,6 +48,7 @@ CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_RTC=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_SOUND=y
-- 
2.23.0



[PATCH v4 07/11] rtc: sandbox-rtc: fix set method

2020-07-06 Thread Rasmus Villemoes
The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/sandbox_rtc.c | 65 +++
 test/dm/rtc.c | 15 -
 2 files changed, 38 insertions(+), 42 deletions(-)

diff --git a/drivers/rtc/sandbox_rtc.c b/drivers/rtc/sandbox_rtc.c
index b08d758a74..77065e49c7 100644
--- a/drivers/rtc/sandbox_rtc.c
+++ b/drivers/rtc/sandbox_rtc.c
@@ -14,55 +14,38 @@
 
 static int sandbox_rtc_get(struct udevice *dev, struct rtc_time *time)
 {
-   time->tm_sec = dm_i2c_reg_read(dev, REG_SEC);
-   if (time->tm_sec < 0)
-   return time->tm_sec;
-   time->tm_min = dm_i2c_reg_read(dev, REG_MIN);
-   if (time->tm_min < 0)
-   return time->tm_min;
-   time->tm_hour = dm_i2c_reg_read(dev, REG_HOUR);
-   if (time->tm_hour < 0)
-   return time->tm_hour;
-   time->tm_mday = dm_i2c_reg_read(dev, REG_MDAY);
-   if (time->tm_mday < 0)
-   return time->tm_mday;
-   time->tm_mon = dm_i2c_reg_read(dev, REG_MON);
-   if (time->tm_mon < 0)
-   return time->tm_mon;
-   time->tm_year = dm_i2c_reg_read(dev, REG_YEAR);
-   if (time->tm_year < 0)
-   return time->tm_year;
-   time->tm_year += 1900;
-   time->tm_wday = dm_i2c_reg_read(dev, REG_WDAY);
-   if (time->tm_wday < 0)
-   return time->tm_wday;
+   u8 buf[7];
+   int ret;
+
+   ret = dm_i2c_read(dev, REG_SEC, buf, sizeof(buf));
+   if (ret < 0)
+   return ret;
+
+   time->tm_sec  = buf[REG_SEC - REG_SEC];
+   time->tm_min  = buf[REG_MIN - REG_SEC];
+   time->tm_hour = buf[REG_HOUR - REG_SEC];
+   time->tm_mday = buf[REG_MDAY - REG_SEC];
+   time->tm_mon  = buf[REG_MON - REG_SEC];
+   time->tm_year = buf[REG_YEAR - REG_SEC] + 1900;
+   time->tm_wday = buf[REG_WDAY - REG_SEC];
 
return 0;
 }
 
 static int sandbox_rtc_set(struct udevice *dev, const struct rtc_time *time)
 {
+   u8 buf[7];
int ret;
 
-   ret = dm_i2c_reg_write(dev, REG_SEC, time->tm_sec);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MIN, time->tm_min);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_HOUR, time->tm_hour);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MDAY, time->tm_mday);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MON, time->tm_mon);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_YEAR, time->tm_year - 1900);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_WDAY, time->tm_wday);
+   buf[REG_SEC - REG_SEC]  = time->tm_sec;
+   buf[REG_MIN - REG_SEC]  = time->tm_min;
+   buf[REG_HOUR - REG_SEC] = time->tm_hour;
+   buf[REG_MDAY - REG_SEC] = time->tm_mday;
+   buf[REG_MON  - REG_SEC] = time->tm_mon;
+   buf[REG_YEAR - REG_SEC] = time->tm_year - 1900;
+   buf[REG_WDAY - REG_SEC] = time->tm_wday;
+
+   ret = dm_i2c_write(dev, REG_SEC, buf, sizeof(buf));
if (ret < 0)
return ret;
 
diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index 88f86581cc..e072fd618b 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -70,7 +70,20 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
 
memset(, '\0', sizeof(time));
-   time.tm_mday = 25;
+   time.tm_mday = 3;
+   time.tm_mon = 6;
+   time.tm_year = 2004;
+   time.tm_sec = 0;
+   time.tm_min = 18;
+   time.tm_hour = 18;
+   ut_assertok(dm_rtc_set(dev, ));
+
+   memset(, '\0', sizeof(cmp));
+   ut_assertok(dm_rtc_get(dev, ));
+   ut_assertok(cmp_times(, , true));
+
+   

[PATCH v4 08/11] rtc: i2c_rtc_emul: catch any write to the "reset" register

2020-07-06 Thread Rasmus Villemoes
It's more natural that any write that happens to touch the reset
register should cause a reset, rather than just a write that starts at
that offset.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/i2c_rtc_emul.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/i2c_rtc_emul.c b/drivers/rtc/i2c_rtc_emul.c
index a010af411b..7f78ff83cb 100644
--- a/drivers/rtc/i2c_rtc_emul.c
+++ b/drivers/rtc/i2c_rtc_emul.c
@@ -197,7 +197,8 @@ static int sandbox_i2c_rtc_xfer(struct udevice *emul, 
struct i2c_msg *msg,
 
/* Write the register */
memcpy(plat->reg + offset, ptr, len);
-   if (offset == REG_RESET)
+   /* If the reset register was written to, do reset. */
+   if (offset <= REG_RESET && REG_RESET < offset + len)
reset_time(emul);
}
}
-- 
2.23.0



[PATCH v4 05/11] rtc: pcf2127: provide ->write method

2020-07-06 Thread Rasmus Villemoes
Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/pcf2127.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index eea72ad522..88ff8c52c3 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -43,6 +43,12 @@ static int pcf2127_rtc_read(struct udevice *dev, uint 
offset, u8 *buffer, uint l
return dm_i2c_xfer(dev, , 1);
 }
 
+static int pcf2127_rtc_write(struct udevice *dev, uint offset,
+const u8 *buffer, uint len)
+{
+   return dm_i2c_write(dev, offset, buffer, len);
+}
+
 static int pcf2127_rtc_set(struct udevice *dev, const struct rtc_time *tm)
 {
uchar buf[7] = {0};
@@ -110,6 +116,7 @@ static const struct rtc_ops pcf2127_rtc_ops = {
.set = pcf2127_rtc_set,
.reset = pcf2127_rtc_reset,
.read = pcf2127_rtc_read,
+   .write = pcf2127_rtc_write,
 };
 
 static const struct udevice_id pcf2127_rtc_ids[] = {
-- 
2.23.0



[PATCH v4 02/11] rtc: add dm_rtc_write() helper

2020-07-06 Thread Rasmus Villemoes
Similar to dm_rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 19 +++
 include/rtc.h| 24 
 2 files changed, 43 insertions(+)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index 4a0e3c5643..44da500c03 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -59,6 +59,25 @@ int dm_rtc_read(struct udevice *dev, unsigned int reg, u8 
*buf, unsigned int len
return 0;
 }
 
+int dm_rtc_write(struct udevice *dev, unsigned int reg,
+const u8 *buf, unsigned int len)
+{
+   struct rtc_ops *ops = rtc_get_ops(dev);
+
+   assert(ops);
+   if (ops->write)
+   return ops->write(dev, reg, buf, len);
+   if (!ops->write8)
+   return -ENOSYS;
+   while (len--) {
+   int ret = ops->write8(dev, reg++, *buf++);
+
+   if (ret < 0)
+   return ret;
+   }
+   return 0;
+}
+
 int rtc_read8(struct udevice *dev, unsigned int reg)
 {
struct rtc_ops *ops = rtc_get_ops(dev);
diff --git a/include/rtc.h b/include/rtc.h
index f30e908221..1efc0db3de 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -67,6 +67,18 @@ struct rtc_ops {
int (*read)(struct udevice *dev, unsigned int reg,
u8 *buf, unsigned int len);
 
+   /**
+* write() - Write multiple 8-bit registers
+*
+* @dev:Device to write to
+* @reg:First register to write
+* @buf:Input buffer
+* @len:Number of registers to write
+* @return 0 if OK, -ve on error
+*/
+   int (*write)(struct udevice *dev, unsigned int reg,
+const u8 *buf, unsigned int len);
+
/**
 * read8() - Read an 8-bit register
 *
@@ -132,6 +144,18 @@ int dm_rtc_reset(struct udevice *dev);
  */
 int dm_rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int 
len);
 
+/**
+ * dm_rtc_write() - Write multiple 8-bit registers
+ *
+ * @dev:   Device to write to
+ * @reg:   First register to write
+ * @buf:   Input buffer
+ * @len:   Number of registers to write
+ * @return 0 if OK, -ve on error
+ */
+int dm_rtc_write(struct udevice *dev, unsigned int reg,
+const u8 *buf, unsigned int len);
+
 /**
  * rtc_read8() - Read an 8-bit register
  *
-- 
2.23.0



[PATCH v4 06/11] rtc: add rtc command

2020-07-06 Thread Rasmus Villemoes
Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 cmd/Kconfig  |   6 ++
 cmd/Makefile |   1 +
 cmd/rtc.c| 167 +++
 3 files changed, 174 insertions(+)
 create mode 100644 cmd/rtc.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 192b3b262f..c4d40cbce6 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1718,6 +1718,12 @@ config CMD_DATE
  Enable the 'date' command for getting/setting the time/date in RTC
  devices.
 
+config CMD_RTC
+   bool "rtc"
+   depends on DM_RTC
+   help
+ Enable the 'rtc' command for low-level access to RTC devices.
+
 config CMD_TIME
bool "time"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 974ad48b0a..c7992113e4 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_CMD_REISER) += reiser.o
 obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
 obj-$(CONFIG_CMD_RNG) += rng.o
 obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
+obj-$(CONFIG_CMD_RTC) += rtc.o
 obj-$(CONFIG_SANDBOX) += host.o
 obj-$(CONFIG_CMD_SATA) += sata.o
 obj-$(CONFIG_CMD_NVME) += nvme.o
diff --git a/cmd/rtc.c b/cmd/rtc.c
new file mode 100644
index 00..b4f61b2e83
--- /dev/null
+++ b/cmd/rtc.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_RTC_BYTES 32
+
+static int do_rtc_read(struct udevice *dev, int argc, char * const argv[])
+{
+   u8 buf[MAX_RTC_BYTES];
+   int reg, len, ret, r;
+
+   if (argc < 2 || argc > 3)
+   return CMD_RET_USAGE;
+
+   reg = simple_strtoul(argv[0], NULL, 16);
+   len = simple_strtoul(argv[1], NULL, 16);
+
+   if (argc == 3) {
+   u8 *addr;
+
+   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
+   ret = dm_rtc_read(dev, reg, addr, len);
+   unmap_sysmem(addr);
+   if (ret) {
+   printf("dm_rtc_read() failed: %d\n", ret);
+   return CMD_RET_FAILURE;
+   }
+   return CMD_RET_SUCCESS;
+   }
+
+   while (len) {
+   r = min_t(int, len, sizeof(buf));
+   ret = dm_rtc_read(dev, reg, buf, r);
+   if (ret) {
+   printf("dm_rtc_read() failed: %d\n", ret);
+   return CMD_RET_FAILURE;
+   }
+   print_buffer(reg, buf, 1, r, 0);
+   len -= r;
+   reg += r;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
+static int do_rtc_write(struct udevice *dev, int argc, char * const argv[])
+{
+   u8 buf[MAX_RTC_BYTES];
+   int reg, len, ret;
+   const char *s;
+   int slen;
+
+   if (argc < 2 || argc > 3)
+   return CMD_RET_USAGE;
+
+   reg = simple_strtoul(argv[0], NULL, 16);
+
+   if (argc == 3) {
+   u8 *addr;
+
+   len = simple_strtoul(argv[1], NULL, 16);
+   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
+   ret = dm_rtc_write(dev, reg, addr, len);
+   unmap_sysmem(addr);
+   if (ret) {
+   printf("dm_rtc_write() failed: %d\n", ret);
+   return CMD_RET_FAILURE;
+   }
+   return CMD_RET_SUCCESS;
+   }
+
+   s = argv[1];
+   slen = strlen(s);
+
+   if (slen % 2) {
+   printf("invalid hex string\n");
+   return CMD_RET_FAILURE;
+   }
+
+   while (slen) {
+   len = min_t(int, slen / 2, sizeof(buf));
+   if (hex2bin(buf, s, len)) {
+   printf("invalid hex string\n");
+   return CMD_RET_FAILURE;
+   }
+
+   ret = dm_rtc_write(dev, reg, buf, len);
+   if (ret) {
+   printf("dm_rtc_write() failed: %d\n", ret);
+   return CMD_RET_FAILURE;
+   }
+   s += 2 * len;
+   slen -= 2 * len;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
+int do_rtc(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[])
+{
+   static int curr_rtc;
+   struct udevice *dev;
+   int ret, idx;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   argc--;
+   argv++;
+
+   if (!strcmp(argv[0], "list")) {
+   struct uclass *uc;
+
+   idx = 0;
+   uclass_id_foreach_dev(UCLASS_RTC, dev, uc) {
+   printf("RTC #%d - %s\n", idx++, dev->name);
+   }
+   if (!idx) {
+   printf("*** no RTC devices available ***\n");
+   

[PATCH v4 04/11] rtc: pcf2127: provide ->read method

2020-07-06 Thread Rasmus Villemoes
This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_) and changing the type of its
"len" parameter.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/pcf2127.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index c423960b34..eea72ad522 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -23,8 +23,7 @@
 #define PCF2127_REG_MO 0x08
 #define PCF2127_REG_YR 0x09
 
-static int pcf2127_read_reg(struct udevice *dev, uint offset,
-   u8 *buffer, int len)
+static int pcf2127_rtc_read(struct udevice *dev, uint offset, u8 *buffer, uint 
len)
 {
struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
struct i2c_msg msg;
@@ -73,7 +72,7 @@ static int pcf2127_rtc_get(struct udevice *dev, struct 
rtc_time *tm)
int ret = 0;
uchar buf[10] = { PCF2127_REG_CTRL1 };
 
-   ret = pcf2127_read_reg(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
+   ret = pcf2127_rtc_read(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
if (ret < 0)
return ret;
 
@@ -110,6 +109,7 @@ static const struct rtc_ops pcf2127_rtc_ops = {
.get = pcf2127_rtc_get,
.set = pcf2127_rtc_set,
.reset = pcf2127_rtc_reset,
+   .read = pcf2127_rtc_read,
 };
 
 static const struct udevice_id pcf2127_rtc_ids[] = {
-- 
2.23.0



[PATCH v4 03/11] rtc: fall back to ->{read, write} if ->{read, write}8 are not provided

2020-07-06 Thread Rasmus Villemoes
Similar to how the dm_rtc_{read,write} functions fall back to using
the {read,write}8 methods, do the opposite in the rtc_{read,write}8
functions.

This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and dm_rtc_read() work - without this, a
driver that provides ->read() would most likely just duplicate the
logic here for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index 44da500c03..8035f7fe9c 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -83,9 +83,17 @@ int rtc_read8(struct udevice *dev, unsigned int reg)
struct rtc_ops *ops = rtc_get_ops(dev);
 
assert(ops);
-   if (!ops->read8)
-   return -ENOSYS;
-   return ops->read8(dev, reg);
+   if (ops->read8)
+   return ops->read8(dev, reg);
+   if (ops->read) {
+   u8 buf[1];
+   int ret = ops->read(dev, reg, buf, 1);
+
+   if (ret < 0)
+   return ret;
+   return buf[0];
+   }
+   return -ENOSYS;
 }
 
 int rtc_write8(struct udevice *dev, unsigned int reg, int val)
@@ -93,9 +101,14 @@ int rtc_write8(struct udevice *dev, unsigned int reg, int 
val)
struct rtc_ops *ops = rtc_get_ops(dev);
 
assert(ops);
-   if (!ops->write8)
-   return -ENOSYS;
-   return ops->write8(dev, reg, val);
+   if (ops->write8)
+   return ops->write8(dev, reg, val);
+   if (ops->write) {
+   u8 buf[1] = { val };
+
+   return ops->write(dev, reg, buf, 1);
+   }
+   return -ENOSYS;
 }
 
 int rtc_read16(struct udevice *dev, unsigned int reg, u16 *valuep)
-- 
2.23.0



[PATCH v4 01/11] rtc: add dm_rtc_read helper and ->read method

2020-07-06 Thread Rasmus Villemoes
Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a dm_rtc_read() helper. Also, allow a driver to provide a
->read method, which can be more efficient than reading one register
at a time.

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 19 +++
 include/rtc.h| 23 +++
 2 files changed, 42 insertions(+)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index 926cca234e..4a0e3c5643 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -40,6 +40,25 @@ int dm_rtc_reset(struct udevice *dev)
return ops->reset(dev);
 }
 
+int dm_rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int 
len)
+{
+   struct rtc_ops *ops = rtc_get_ops(dev);
+
+   assert(ops);
+   if (ops->read)
+   return ops->read(dev, reg, buf, len);
+   if (!ops->read8)
+   return -ENOSYS;
+   while (len--) {
+   int ret = ops->read8(dev, reg++);
+
+   if (ret < 0)
+   return ret;
+   *buf++ = ret;
+   }
+   return 0;
+}
+
 int rtc_read8(struct udevice *dev, unsigned int reg)
 {
struct rtc_ops *ops = rtc_get_ops(dev);
diff --git a/include/rtc.h b/include/rtc.h
index 8aabfc1162..f30e908221 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -55,6 +55,18 @@ struct rtc_ops {
 */
int (*reset)(struct udevice *dev);
 
+   /**
+* read() - Read multiple 8-bit registers
+*
+* @dev:Device to read from
+* @reg:First register to read
+* @buf:Output buffer
+* @len:Number of registers to read
+* @return 0 if OK, -ve on error
+*/
+   int (*read)(struct udevice *dev, unsigned int reg,
+   u8 *buf, unsigned int len);
+
/**
 * read8() - Read an 8-bit register
 *
@@ -109,6 +121,17 @@ int dm_rtc_set(struct udevice *dev, struct rtc_time *time);
  */
 int dm_rtc_reset(struct udevice *dev);
 
+/**
+ * dm_rtc_read() - Read multiple 8-bit registers
+ *
+ * @dev:   Device to read from
+ * @reg:   First register to read
+ * @buf:   Output buffer
+ * @len:   Number of registers to read
+ * @return 0 if OK, -ve on error
+ */
+int dm_rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int 
len);
+
 /**
  * rtc_read8() - Read an 8-bit register
  *
-- 
2.23.0



[PATCH v4 00/11] new rtc methods, rtc command, and tests

2020-07-06 Thread Rasmus Villemoes
I need access to registers other than just the timekeeping ones of the
pcf2127, so I wanted to implement ->read8 and ->write8. But for
testing these it appeared there was no convenient way to invoke those
from the shell, so I also ended up adding such a command.

Also, it seemed more natural to provide array variants that can read
or write several registers at once, so rtc_ops is expanded a bit.

Changes in v4:

- Add CONFIG_CMD_RTC to sandbox defconfigs (new patch 10/11). Not
  quite sure exactly which it needed to be added to, but at least
  sandbox and sandbox_flattree showed CI failures.

- Add Heiko's R-B to the 10 v3 patches (1-9 + 11), and Simon's R-B to 6/11.

- Fix some checkpatch warnings - I don't really agree with most of
  them - e.g. having to add an empty line in

  int foo = something();
  if (foo < 0)
return foo;
  return something_else(foo);

  doesn't make the code more readable IMO.

  The remaining checkpatch blurps are things I really don't think
  warrant "fixing", e.g. "WARNING: ENOSYS means 'invalid syscall nr'
  and nothing else" seems irrelevant in context of U-Boot, and in any
  case I've only copied existing practice. For "WARNING: please write
  a paragraph that describes the config symbol fully", that seems to
  be a false positive, there's certainly a full help text for CMD_RTC.

Changes in v3:

- Call the functions dm_rtc_read/dm_rtc_write rather than just
  rtc_read/rtc_write, since the latter names are used for local
  helpers by a number of drivers. That also matches the existing
  dm_rtc_set/dm_rtc_get (though then not the existing
  rtc_read{8,16,32}).

- Update the rtc command (patch 6) as per Simon's feedback (parse
  input as hex, avoid overlong lines, use print_buffer()).
  
- Update the tests (patches 9 and 10) according to these changes.

Changes in v2:

- Use simply "read" and "write" instead of "read8_array",
  "write8_array", both for functions and methods, as suggested by
  Simon.

- The rtc command's interface has been simplified a bit (no separate
  read/readm; the number of arguments determines whether the user
  wants the result on the console or to a memory address)

- Add tests, both of rtc_{read,write}() and of the shell command,
  fixing a few things I stumbled on.

Rasmus Villemoes (11):
  rtc: add dm_rtc_read helper and ->read method
  rtc: add dm_rtc_write() helper
  rtc: fall back to ->{read,write} if ->{read,write}8 are not provided
  rtc: pcf2127: provide ->read method
  rtc: pcf2127: provide ->write method
  rtc: add rtc command
  rtc: sandbox-rtc: fix set method
  rtc: i2c_rtc_emul: catch any write to the "reset" register
  test: dm: rtc: add test of dm_rtc_read, dm_rtc_write
  sandbox: add rtc command to defconfigs
  test: dm: rtc: add tests of rtc shell command

 arch/sandbox/include/asm/rtc.h |   5 +
 cmd/Kconfig|   6 ++
 cmd/Makefile   |   1 +
 cmd/rtc.c  | 167 +
 configs/sandbox64_defconfig|   1 +
 configs/sandbox_defconfig  |   1 +
 configs/sandbox_flattree_defconfig |   1 +
 drivers/rtc/i2c_rtc_emul.c |   3 +-
 drivers/rtc/pcf2127.c  |  13 ++-
 drivers/rtc/rtc-uclass.c   |  59 +-
 drivers/rtc/sandbox_rtc.c  |  65 +--
 include/rtc.h  |  47 
 test/dm/rtc.c  | 118 +++-
 13 files changed, 437 insertions(+), 50 deletions(-)
 create mode 100644 cmd/rtc.c

-- 
2.23.0



Re: Chainloading U-Boot from Fastboot on Tegra30

2020-07-06 Thread Peter Geis
On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren  wrote:
>
> On 7/3/20 6:32 AM, Peter Geis wrote:
> > Good Morning,
> >
> > I am attempting to expand on the work for chainloading U-Boot on the
> > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from 
> > fastboot.
> > I have so far been unsuccessful at getting any output from U-Boot
> > through this method.
>
> I assume that fastboot executes the loaded code on the main CPU not on
> the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on
> the AVP though; you would have to disable SPL to make this all work, and
> perhaps fix U-Boot to work without SPL present. I'm not sure what, if
> any, changes would be required to support that.
>
> For background, see:
> https://http.download.nvidia.com/tegra-public-appnotes/index.html

Apologies for the resend, I realized I didn't reply to the list.

I admit I'm still extremely new to U-Boot, but this is the way I
understand the boot flow.
ROM does extremely low level init, then loads U-boot SPL.
U-Boot SPL does basic init, ram, cpu and required peripherals, then
loads U-Boot.bin.
U-Boot.bin is U-Boot proper, with the full interface.

By loading U-Boot.bin as the nyan instructions indicated, I'm
bypassing the SPL code as if it was already complete.
The issue I have is I'm not sure what modifications were done to the
T124 code to allow nyan to do this.
I've compared the nyan configs to the cardhu configs and I don't see
anything that sticks out to me.
I've also dug through the nyan git log and I don't see anything that
was specifically changed to allow chainloading on T124.

I also am unsure of where fastboot is loading the kernel in order to
set the text base correctly.


[ANN] U-Boot v2020.07 released

2020-07-06 Thread Tom Rini
Hey all,

It is release day and here is the v2020.07 release.  The current
schedule has been working well enough I think, but I really would like
to see broader testing after the -rc1 release.  I know I should test a
few more platforms then than I do regularly.  I hope others will do the
same, especially given that we're fairly good about doing them on
schedule.

In terms of a changelog, 
git log --merges v2020.07-rc5..v2020.07
or
git log --merges v2020.04..v2020.07

The merge window is once again open and I plan to tag -rc1 on July
27th, bi-weekly -rcs thereafter and final release on October 5th, 2020.

I am merging the next branch to master now and will send a separate
email when that is done.

-- 
Tom


signature.asc
Description: PGP signature


Re: [RFC 1/4] dtoc: add POC for dtb shrink

2020-07-06 Thread Simon Glass
Hi Walter,

On Fri, 19 Jun 2020 at 15:11, Walter Lozano  wrote:
>
> Based on several reports and discussions [1], [2] it is clear that U-Boot's
> footprint is always a concern, and any kind of reduction is an
> improvement.
>
> In particular dtb is one of the sources of footprint increment, as
> U-Boot uses the same dtb as Linux. However is interesting to note that
> U-Boot does not require all the nodes and properties declared in it.
> Some improvements in this sense are already present, such as
> removing properties based on configuration and using specific "u-boot"
> properties to keep only specific node in SPL. However, this require
> manual configuration.
>
> Additionally reducing dtb, will allow ATF for better handing FDT buffer, which
> is an issue in some contexts [3].
>
> In order to improve this situation, this patch adds a proof of concept
> for dtb shrink. The idea behind this is simple, remove all the nodes
> from dtb which compatible string is not supported by any driver present.
> This approach makes sense for those configuration where Linux is
> expected to have its own dtb.
>
> This patch is based on the work of Simon Glass present in [4] which adds
> support to dtoc for parsing compatible strings.
>
> Some early untested results shows that the reduction in size is 50 % in
> case of mx6_cuboxi_defconfig, which is promising.
>
> Some additional reduction could be possible by only keeping the nodes for
> whose compatible string is supported by any enabled driver. However,
> this requires to add extra logic to parse config files and map
> configuration to compatible strings.
>
> This proof of concept uses fdtgrep to implement the node removal, but
> the idea is to implement this logic inside the dtoc for better handling.
>
> [1] 
> http://patchwork.ozlabs.org/project/uboot/patch/20200525093539.1.Ibf2d19439cde35e39192a9d4a8dad23539fae2e6@changeid/
> [2] 
> http://u-boot.10912.n7.nabble.com/PATCH-v1-00-15-add-basic-driver-support-for-broadcom-NS3-soc-tt412411.html#none
> [3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4512
> [4] https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/dtb_platdata.py | 42 +++---
>  1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
> index 21cce5afb5..1df13b2cd2 100644
> --- a/tools/dtoc/dtb_platdata.py
> +++ b/tools/dtoc/dtb_platdata.py
> @@ -399,7 +399,10 @@ class DtbPlatdata(object):
>  """Scan the driver folders to build a list of driver names and 
> possible
>  aliases
>  """
> -for (dirpath, dirnames, filenames) in os.walk('/home/sglass/u'):
> +basedir = sys.argv[0].replace('tools/dtoc/dtoc', '')

Instead of this logic, can we pass the source-tree location into dtoc
with a flag? It could default to the current dir perhaps.

> +if basedir == '':
> +basedir = './'
> +for (dirpath, dirnames, filenames) in os.walk(basedir):
>  for fn in filenames:
>  if not fn.endswith('.c'):
>  continue
> @@ -802,6 +805,32 @@ class DtbPlatdata(object):
>  self.out(''.join(self.get_buf()))
>  self.close_output()
>
> +def shrink(self):
> +"""Generate a shrunk version of DTB bases on valid drivers
> +
> +This function removes nodes from dtb which compatible string is not
> +found in drivers. The output is saved in a file with suffix name 
> -shrink.dtb
> +"""
> +compat = []
> +cmd = './tools/fdtgrep '
> +#print(self._drivers)
> +for dr in self._drivers.values():
> +compat = compat + dr.compat
> +
> +for cp in compat:
> +#print(cp)
> +cmd += ' -c ' + cp
> +
> +cmd += ' -O dtb -o ' + self._dtb_fname.replace('.dtb', '') + 
> '-shrink.dtb ' + self._dtb_fname
> +
> +if False:
> +with open('dt_shrink.sh', 'w+') as script:
> +script.write(cmd)
> +
> +os.system(cmd)
> +
> +return
> +
>  def run_steps(args, dtb_file, config_file, include_disabled, output):
>  """Run all the steps of the dtoc tool
>
> @@ -816,6 +845,10 @@ def run_steps(args, dtb_file, config_file, 
> include_disabled, output):
>  if not args:
>  raise ValueError('Please specify a command: struct, platdata')
>
> +skip_scan = False
> +if args == ['shrink']:
> +skip_scan = True

I think that would be better as a positive variable, like 'scan'.

> +
>  plat = DtbPlatdata(dtb_file, config_file, include_disabled)
>  plat.scan_drivers()
>  plat.scan_dtb()
> @@ -823,14 +856,17 @@ def run_steps(args, dtb_file, config_file, 
> include_disabled, output):
>  plat.scan_config()
>  plat.scan_reg_sizes()

Are those two needed with this new command?

>  plat.setup_output(output)
> -structs = 

Re: [PATCH v1 07/43] dm: acpi: Add support for the NHLT table

2020-07-06 Thread Simon Glass
Hi Bin,

On Thu, 2 Jul 2020 at 22:33, Bin Meng  wrote:
>
> Hi Simon,
>
> On Fri, Jul 3, 2020 at 11:50 AM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On Thu, 2 Jul 2020 at 18:54, Bin Meng  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Jul 3, 2020 at 8:46 AM Simon Glass  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Mon, 29 Jun 2020 at 20:49, Bin Meng  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  
> > > > > wrote:
> > > > > >
> > > > > > The Intel Non-High-Definition-Audio Link Table (NHLT) table 
> > > > > > describes the
> > > > > > audio codecs and connections in a system. Various devices can 
> > > > > > contribute
> > > > > > information to produce the table.
> > > > > >
> > > > > > Add core support for this, based on a structure which is built up 
> > > > > > through
> > > > > > calls to the driver.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > >
> > > > > >  drivers/core/acpi.c | 15 +++
> > > > > >  include/dm/acpi.h   | 26 ++
> > > > > >  2 files changed, 41 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> > > > > > index ea304a3067..a5053fec6f 100644
> > > > > > --- a/drivers/core/acpi.c
> > > > > > +++ b/drivers/core/acpi.c
> > > > > > @@ -31,6 +31,7 @@ enum method_t {
> > > > > > METHOD_WRITE_TABLES,
> > > > > > METHOD_FILL_SSDT,
> > > > > > METHOD_INJECT_DSDT,
> > > > > > +   METHOD_SETUP_NHLT,
> > > > >
> > > > > Do we really need to promote this to be an ACPI core method? Can we
> > > > > reuse the SSDT/DSDT one?
> > > >
> > > > I don't think so. Those two are for a particular purpose. In fact NHLT
> > > > is generated while doing SSDT I think. The idea is that drivers that
> > > > want to contribute to NHLT can do so. But we cannot use the SSDT
> > > > mechanism since each driver contributes only a part of the info, and
> > > > we need something else to bring it all together.
> > >
> > > Will there be only one device that sets up the NHLT info?
> >
> > WIth coral it is two devices. I'm not sure of the maximum, but I
> > suppose it depends on the audio codecs present.
>
> Could we make this method to be provided by the codec device, instead
> of a generic ACPI core method?

The codec device does implement this. See the drivers where they
actually implement the NHLT method.

This is definitely an ACPI-specific thing, so I think we need core
support for iterating through drivers that want to provide this info.

Regards,
Simon


Re: [RFC 2/4] dtoc: add initial support for deleting DTB nodes

2020-07-06 Thread Simon Glass
Hi Walter,

On Fri, 19 Jun 2020 at 15:12, Walter Lozano  wrote:
>
> This patch introduce a test for deleting DTB nodes using Python library.
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/dtb_platdata.py | 28 
>  tools/dtoc/fdt.py  |  3 +++
>  2 files changed, 31 insertions(+)

This test should go in test_dtoc.py

Regards,
Simon


Re: [RFC 3/4] dtoc: add support for generate stuct udevice_id

2020-07-06 Thread Simon Glass
Hi Walter,

On Fri, 19 Jun 2020 at 15:12, Walter Lozano  wrote:
>
> Based on several reports there is an increasing concern in the impact
> of adding additional features to drivers based on compatible strings.
> A good example of this situation is found in [1].
>
> In order to reduce this impact and as an initial step for further
> reduction, propose a new way to declare compatible strings, which allows
> to only include the useful ones.

What are the useful ones?

>
> The idea is to define compatible strings in a way to be easily parsed by
> dtoc, which will be responsible to build struct udevice_id [] based on
> the compatible strings present in the dtb.
>
> Additional features can be easily added, such as define constants
> depending on the presence of compatible strings, which allows to enable
> code blocks only in such cases without the need of adding additional
> configuration options.
>
> [1] 
> http://patchwork.ozlabs.org/project/uboot/patch/20200525202429.2146-1-ag...@denx.de/
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/dtb_platdata.py | 32 
>  1 file changed, 32 insertions(+)

I think dtoc should be able to parse the compatible strings as they
are today - e.g. see the tiny-dm stuff.

Regards,
Simon


Re: [PATCH] x86: remove unused setup_pcat_compatibility() stub

2020-07-06 Thread Simon Glass
Hi Masahiro,

On Sat, 4 Jul 2020 at 11:43, Masahiro Yamada  wrote:
>
> 'git grep' did not find any user of this stub.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/x86/include/asm/u-boot-x86.h |  2 --
>  arch/x86/lib/zimage.c | 10 --
>  2 files changed, 12 deletions(-)
>

See also: 
http://patchwork.ozlabs.org/project/uboot/patch/20200615035738.248710-21-...@chromium.org/

Regards,
Simon


Re: [PATCH v1 18/43] x86: pinctrl: Update comment for intel_pinctrl_get_pad()

2020-07-06 Thread Simon Glass
Hi Bin,

On Thu, 2 Jul 2020 at 18:59, Bin Meng  wrote:
>
> Hi Simon,
>
> On Fri, Jul 3, 2020 at 8:46 AM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On Tue, 30 Jun 2020 at 00:43, Bin Meng  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Jun 15, 2020 at 11:58 AM Simon Glass  wrote:
> > > >
> > > > Add information about what is returned on error.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > >  arch/x86/include/asm/intel_pinctrl.h | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/x86/include/asm/intel_pinctrl.h 
> > > > b/arch/x86/include/asm/intel_pinctrl.h
> > > > index f39ebde539..982b2514a0 100644
> > > > --- a/arch/x86/include/asm/intel_pinctrl.h
> > > > +++ b/arch/x86/include/asm/intel_pinctrl.h
> > > > @@ -300,6 +300,7 @@ u32 intel_pinctrl_get_config_reg(struct udevice 
> > > > *dev, uint offset);
> > > >   * @pad: Pad to check
> > > >   * @devp: Returns pinctrl device containing that pad
> > > >   * @offsetp: Returns offset of pad within that pinctrl device
> > > > + * @return 0 if OK, -ENOTBLK if pad number is invalid
> > >
> > > It's weird that ENOTBLK is used for a pinctrl.
> > >
> >
> > Yes. I want it to be very distinctive since it is passed through many
> > functions. Can you suggest a better value?
>
> How about -EINVAL?

That is not distinctive though. Lots of things produce that error and
it is mostly reserved for bad arguments in ofdata_to_platdata methods.

Regards,
Simon


Re: Pull request for UEFI sub-system for efi-2020-10-rc1

2020-07-06 Thread Tom Rini
On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote:

> The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7:
> 
>   Merge tag 'efi-2020-07-rc6-2' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-10-rc1
> 
> for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357:
> 
>   efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200)
> 

Given that I see you've addressed the size growth from FAT_WRITE,
applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Chainloading U-Boot from Fastboot on Tegra30

2020-07-06 Thread Stephen Warren
On 7/3/20 6:32 AM, Peter Geis wrote:
> Good Morning,
> 
> I am attempting to expand on the work for chainloading U-Boot on the
> nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from 
> fastboot.
> I have so far been unsuccessful at getting any output from U-Boot
> through this method.

I assume that fastboot executes the loaded code on the main CPU not on
the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on
the AVP though; you would have to disable SPL to make this all work, and
perhaps fix U-Boot to work without SPL present. I'm not sure what, if
any, changes would be required to support that.

For background, see:
https://http.download.nvidia.com/tegra-public-appnotes/index.html


Re: Chainloading U-Boot from Fastboot on Tegra30

2020-07-06 Thread Simon Glass
Hi Peter,

On Mon, 6 Jul 2020 at 05:52, Peter Geis  wrote:
>
> On Sun, Jul 5, 2020 at 11:35 AM Simon Glass  wrote:
> >
> > Hi Peter,
> >
> > On Sun, 5 Jul 2020 at 05:33, Peter Geis  wrote:
> > >
> > > On Sat, Jul 4, 2020 at 3:53 PM Simon Glass  wrote:
> > > >
> > > > Hi Peter,
> > > >
> > > > On Fri, 3 Jul 2020 at 06:33, Peter Geis  wrote:
> > > > >
> > > > > Good Morning,
> > > > >
> > > > > I am attempting to expand on the work for chainloading U-Boot on the
> > > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from 
> > > > > fastboot.
> > > > > I have so far been unsuccessful at getting any output from U-Boot
> > > > > through this method.
> > > > >
> > > > > I'm building the cardhu board with tweaks for Ouya's specifications
> > > > > similar to my work for the linux kernel.
> > > > > I build the image using mkbootimg --kernel u-boot.bin --ramdisk
> > > > > /dev/null --output u-boot-android.bin.
> > > > > I then fastboot boot u-boot-android.bin.
> > > > >
> > > > > I've tried tweaking the text base and tried both standard debug and
> > > > > low level debug.
> > > > >
> > > > > Do you think you could give me some insight into where I'm going 
> > > > > wrong?
> > > >
> > > > Is it possible that fastboot expects a relocatable image? If you set
> > > > up the debug UART very early you might be able to output a character
> > > > in start.S ?
> > >
> > > Yes, fastboot expects a relocatable image.
> > > As I understand it though, if I get the text base correct, U-boot will
> > > not need to relocate.
> > >
> > > The debug UART is already set up when it fastboot jumps to the loaded 
> > > kernel,
> > > So I should be able to dump data to the expected raw address and it
> > > will show up?
> >
> > Yes, so long as you know the address. Is the MMU turned off? Cache?
>
> It is unknown what state either of these are in, since I am unfamiliar
> at all with how fastboot functions with these.
> In U-boot yes the MMU was enabled as well as both I and D cache.
>
> >
> > >
> > > >
> > > > BTW does U-Boot have support for the fastboot protocol? Perhaps you
> > > > could just use U-Boot?
> > >
> > > The Ouya is locked with a signed boot loader, like most consumer
> > > android devices.
> > > Unlike most other devices, it does not have a hardware method for
> > > entering the bootloader in case of a brick.
> > > We are currently using a hacked kernel that stores another kernel in
> > > "safe" ram via kexec and hard resets the board, but a proper
> > > bootloader would be much more preferable.
> >
> > OK. Maybe there is someone on this list with a bit more Android
> > booting experienec?
> >
> > >
> > > I found one example of where fastboot chainloaded u-boot successfully
> > > on the galaxy nexus, from 2013.
> > > https://forum.xda-developers.com/galaxy-nexus/bootloader-boot-multi-boot-support-t2201146
> >
> > OK, I'm sure it is possible. Do you have the source code for the
> > fastboot code that boots U-Boot?
>
> No, we have the reference code here:
> https://android.googlesource.com/platform/bootable/bootloader/legacy/+/b1fde5cd7d5158b8e6876139ca76a341d0e49708/usbloader/usbloader.c
>
> Unfortunately the behavior observed in the Ouya shows it has been
> heavily modified from this baseline.
>
> I've reached out to the dev who performed the work on u-boot for
> insight as well.

If you have a kernel that loads at the same address that works, and it
can display a UART character very early, then you should be able to
make a U-Boot that does the same in the first few instructions. If you
can't get that far, something else is going on. Do you have JTAG
access?

Regards,
Simon


Re: U-boot Designware SPI driver issue

2020-07-06 Thread Johannes Krottmayer
Hi Yakov,

have you fixed the issue?

I'm not a real developer from the U-Boot project, but I had a similar
issue on a PINE64 Rock64 board. The error code -19 was a missing alias
in the Device-Tree files on my used board.

Fixed this issue with the correct alias. Maybe it's the same issue
on your board. After that I got the error code -2, but fixed it too
(missing SPI support in the clock driver from the SoC).

Kind regards,

Johannes K.

On 24.06.20 at 10:37,  Yakov Shmulevich wrote:
> Hello,
> 
> We develop the system that based on MIPS that includes Synopsys SPI with 
> NACRONIX SPI flash connected to it.
> For U-boot we are using version 2019.04-rc4.
> I want to save environment on SPI flash. For this I enabled the DesignWare 
> SPI driver and MACRONIX SPI flash driver in U-boot .config and add 
> corresponding definitions in our dts file.
> Following the .config relevant lines:
> 
> CONFIG_CMD_SAVEENV=y
> 
> CONFIG_DM_SPI_FLASH=y
> CONFIG_SPI_FLASH=y
> CONFIG_SPI_FLASH_MACRONIX=y
> 
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_SPI_MEM=y
> CONFIG_DESIGNWARE_SPI=y
> 
> Following the dts file relevant lines:
> 
> ahb {
> compatible = "simple-bus";
> 
> spi0: spi-master@1FCD {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "snps,dw-apb-ssi";
> reg = <0x1FCD 0x40>;
> num-chipselect = <4>;
> bus-num = <0>;
> reg-io-width = <4>;
> reg-shift = <2>;
> spi-max-frequency = <1800>; /* input 
> clock */
> 
> status = "okay";
> 
> spi-flash@0 {
> compatible = 
> "spi-flash";
> 
> spi-max-frequency = <1800>; /* input clock */
> reg = <0>; /* 
> CS0 */
> };
> };
> };
> 
> In the U-boot startup I get the following error:
> Loading Environment from SPI Flash...
> Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
> Also the "sf probe" command gives the similar error:
> 
> 
> 
> # sf probe 0:0
> 
> Invalid bus 0 (err=-19)
> 
> Failed to initialize SPI flash at 0:0 (error -19) The error 
> -19 is ENODEV error.
> 
> 
> 
> After the problem evaluation I found that both "load environment" and "sf 
> probe" failed in uclass_find_device_by_seq() function (drivers/core/uclass.c).
> 
> This function failed to find device for uclass_id= UCLASS_SPI on bus 0  
> (spi0). In main there are no devices on this bus.
> 
> 
> 
> In both cases the flow is started from spi_flash_probe_bus_cs() function 
> (drivers/mtd/spi/sf-uclass.c) for device "spi_flash@0:0".
> 
> In the start of this flow uclass_get() function (drivers/core/uclass.c)) is 
> executed to find UCLASS_SPI driver.
> 
> This function returns uclass with driver "spi" and not "dw_spi" as I expected.
> Also I found that the DesignWare SPI driver probe (designware_spi.c) doesn't 
> even executed.
> 
> Can somebody point me on my problem?
> Or maybe there is some example of working Synopsis SPI with flash definitions 
> in U-boot.
> 
> Thanks,
> Yakov
> 
> This email message and any attachments are intended solely for the use of the 
> addressees hereof. 
> This message and any attachments may contain information that is 
> confidential, privileged and exempt from disclosure under applicable law.
> If you are not the intended recipient of this message, you are prohibited 
> from reading, disclosing, reproducing, distributing, disseminating or 
> otherwise using this transmission.
> If you have received this message in error, please promptly notify the sender 
> at Ceragon by reply E-mail and immediately delete this message from your 
> system.
> 


[PATCH] bugfix: tpm2_tis_spi: redeclaration compile error

2020-07-06 Thread Bruno Thomsen
tpm2_tis_spi driver fails to compile with errors like this:

drivers/tpm/tpm_tis.h:117:2: error: redeclaration of enumerator 
'TPM_ACCESS_VALID'
drivers/tpm/tpm_tis.h:118:2: error: redeclaration of enumerator 
'TPM_ACCESS_ACTIVE_LOCALITY'
drivers/tpm/tpm_tis.h:119:2: error: redeclaration of enumerator 
'TPM_ACCESS_REQUEST_PENDING'
drivers/tpm/tpm_tis.h:120:2: error: redeclaration of enumerator 
'TPM_ACCESS_REQUEST_USE'
drivers/tpm/tpm_tis.h:124:2: error: redeclaration of enumerator 'TPM_STS_VALID'
drivers/tpm/tpm_tis.h:125:2: error: redeclaration of enumerator 
'TPM_STS_COMMAND_READY'
drivers/tpm/tpm_tis.h:126:2: error: redeclaration of enumerator 'TPM_STS_GO'
drivers/tpm/tpm_tis.h:127:2: error: redeclaration of enumerator 
'TPM_STS_DATA_AVAIL'
drivers/tpm/tpm_tis.h:128:2: error: redeclaration of enumerator 
'TPM_STS_DATA_EXPECT'

This is due to redeclaration of 9 values in tis_access and tis_status enums
from tpm_tis.h. Defines are now declared in include/tpm-v2.h, so removing
duplicates from tpm_tis.h.

Signed-off-by: Bruno Thomsen 
---
 drivers/tpm/tpm_tis.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/tpm/tpm_tis.h b/drivers/tpm/tpm_tis.h
index 947585f8e3..4043f1aeaf 100644
--- a/drivers/tpm/tpm_tis.h
+++ b/drivers/tpm/tpm_tis.h
@@ -113,19 +113,4 @@ struct tpm_cmd_t {
  */
 #define MAX_COUNT_LONG 50
 
-enum tis_access {
-   TPM_ACCESS_VALID= 0x80,
-   TPM_ACCESS_ACTIVE_LOCALITY  = 0x20,
-   TPM_ACCESS_REQUEST_PENDING  = 0x04,
-   TPM_ACCESS_REQUEST_USE  = 0x02,
-};
-
-enum tis_status {
-   TPM_STS_VALID   = 0x80,
-   TPM_STS_COMMAND_READY   = 0x40,
-   TPM_STS_GO  = 0x20,
-   TPM_STS_DATA_AVAIL  = 0x10,
-   TPM_STS_DATA_EXPECT = 0x08,
-};
-
 #endif

base-commit: 04da1cd8076b44ff49a79b7fe048a9e8e56b5f60
-- 
2.26.2



Re: [RFC PATCH 01/16] patman: Use test_util to show test results

2020-07-06 Thread Simon Glass
Hi Daniel,

On Sun, 5 Jul 2020 at 22:50, Daniel Axtens  wrote:
>
> Daniel Axtens  writes:
>
> > Hi Simon,
> >
> > I can't see a cover letter so apologies if I've misunderstood something
> > basic, but this doesn't appear to apply to the patchwork tree - I'm
> > guessing the patchwork relevance is with regards to the last few patches
> > that (AFAICT) parse the patchwork web interface for information?
>
> Ah, nevermind, the cover letter got caught in moderation. I've released it.
>
> pwclient speaks the old, less documented XML-RPC API. We have a new
> REST API which is much better documented, and is explorable
> (e.g. https://patchwork.ozlabs.org/api/ and
> https://patchwork.readthedocs.io/en/latest/api/rest/ )
>
> > I haven't fully digested the patches (and I lack a lot of context) but
> > is there a reason the patchwork API isn't able to meet your needs here?
> > (And if so, could we extend it rather than having you parse the frontend?)
>
> So these questions still stand but for the REST API.

So use the REST API instead of the web page? That sounds fine to me.
Is it generally enabled on patchwork servers?

What is the status of pwclient? Is it dead? Is there a replacement?
I'd love to use a Python library if one exists.

Regards,
SImon


[PATCH] configs: stm32mp15: activate CMD_ADTIMG

2020-07-06 Thread Patrick Delaunay
Activate the support of the command adtimg to handle android images.

Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   | 1 +
 configs/stm32mp15_trusted_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index f0abc89a43..e69897 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_POWER_SUPPORT=y
 CONFIG_SYS_PROMPT="STM32MP> "
+CONFIG_CMD_ADTIMG=y
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index ca4a10813b..93f605901c 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -11,6 +11,7 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_PROMPT="STM32MP> "
+CONFIG_CMD_ADTIMG=y
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
-- 
2.17.1



[PATCH] ARM: dts: stm32: add reset support to uart nodes on stm32mp15x

2020-07-06 Thread Patrick Delaunay
STM32 serial IP can be reset via reset controller.
Add the support of reset to uart nodes on stm32mp15-u-boot.dtsi,
the ad-dons file for U-Boot.

This patch fix issues when previous UART configuration, for example
done in TF-A or ROM code, is not handled in U-Boot stm32 serial driver
init.

This reset property won't be not added in Linux kernel device tree
as this reset is not used in Linux STM32 serial driver.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp15-u-boot.dtsi | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi 
b/arch/arm/dts/stm32mp15-u-boot.dtsi
index 142ad25c43..c463b49dda 100644
--- a/arch/arm/dts/stm32mp15-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
@@ -179,6 +179,38 @@
compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
 };
 
+ {
+   resets = < USART1_R>;
+};
+
+ {
+   resets = < USART2_R>;
+};
+
+ {
+   resets = < USART3_R>;
+};
+
+ {
+   resets = < UART4_R>;
+};
+
+ {
+   resets = < UART5_R>;
+};
+
+ {
+   resets = < USART6_R>;
+};
+
+ {
+   resets = < UART7_R>;
+};
+
+{
+   resets = < UART8_R>;
+};
+
 _hs {
compatible = "st,stm32mp1-hsotg", "snps,dwc2";
 };
-- 
2.17.1



Re: [PATCH 00/15] net: sun8i-emac fixes and cleanups

2020-07-06 Thread Maxime Ripard
On Mon, Jul 06, 2020 at 01:40:31AM +0100, Andre Przywara wrote:
> Hi,
> 
> while looking at several U-Boot network drivers in the past year, I
> typically compared them to the sun8i-emac driver, as a kind of personal
> reference. While doing so, I figured that there are quite some things
> broken in here, and other things are not so nice.
> This series attempts the fix those shortcomings.
> Fix-wise we get proper handling of PHY failures (try without a
> cable connected), support for external RMII PHYs (as seen on the
> Pine64-non-plus model), and more future-proof internal PHY handling.
> The rest of the patches are cleanups, which fix things that are wrong,
> but we get away with so far, for one or another reason.
> This also cleans up a good part of the cache maintenance. There is more
> to be done (and I have patches for that), but that requires to drop
> the overzealous alignment checks in cache_v7.c first, which is part of
> another, upcoming series.
> 
> A git repo with those patches can be found here:
> https://github.com/apritzel/u-boot/commits/sun8i-emac-cleanup
> 
> Please have a look and send comments!

Acked-by: Maxime Ripard 

Thanks!
Maxime


Re: Cover Letter of Patchsets

2020-07-06 Thread Wolfgang Denk
Dear Leo,

In message <20200706023510.gb2...@andestech.com> you wrote:
>
> I am Leo, just recently joined the community.
> and been picking up the guide line of uboot's development.
>
> I am a bit curious about the policy on the cover letter of patchsets.
> Is cover letter mandatory ?

No, it is not really mandatoryh, but strongl recommended for patch
series.

> IMHO, making it mandatory, especially on patchsets that consist of
> more than 1 patch, is more than useful and of great advantages.

For single patches a cover letter usually makes little sense.

> 1. Making patches clearer for peer and maintainer review
...
> 2. Helping the author better organize the patchset
...
> In all, I think it would be nice to write cover letter to introduce the work.

All your arguments make a lot of sense, indeed.

> If I miss anything or misunderstand anything please let me know, thanks in 
> advance.

Please keep in mind that an inherent property of the cover letter is
that it is NOT part of the patches itself, i. e. it helps only
during the review process, but not any time later when someone tries
to understand the code from reading the git commit logs.


So the essential information to understand the purpose and the
implementation (and ideally also how it has been tested / can be
tested) should always be part of the commit messages itself.

THe cover letter can summarize such information and provide the
overview information for a patch series.  Also it should commet on
the changes between versions of the patch series, if these are
needed (especially when major rework is done between submissions).

But it is only supplementary information which gets lost when the
patches are pulled into the git repository.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Where shall I begin, please your Majesty?" he asked. "Begin  at  the
beginning,"  the  King said, gravely, "and go on till you come to the
end: then stop."- Alice's Adventures in Wonderland, Lewis Carroll


Re: Chainloading U-Boot from Fastboot on Tegra30

2020-07-06 Thread Peter Geis
On Sun, Jul 5, 2020 at 11:35 AM Simon Glass  wrote:
>
> Hi Peter,
>
> On Sun, 5 Jul 2020 at 05:33, Peter Geis  wrote:
> >
> > On Sat, Jul 4, 2020 at 3:53 PM Simon Glass  wrote:
> > >
> > > Hi Peter,
> > >
> > > On Fri, 3 Jul 2020 at 06:33, Peter Geis  wrote:
> > > >
> > > > Good Morning,
> > > >
> > > > I am attempting to expand on the work for chainloading U-Boot on the
> > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from 
> > > > fastboot.
> > > > I have so far been unsuccessful at getting any output from U-Boot
> > > > through this method.
> > > >
> > > > I'm building the cardhu board with tweaks for Ouya's specifications
> > > > similar to my work for the linux kernel.
> > > > I build the image using mkbootimg --kernel u-boot.bin --ramdisk
> > > > /dev/null --output u-boot-android.bin.
> > > > I then fastboot boot u-boot-android.bin.
> > > >
> > > > I've tried tweaking the text base and tried both standard debug and
> > > > low level debug.
> > > >
> > > > Do you think you could give me some insight into where I'm going wrong?
> > >
> > > Is it possible that fastboot expects a relocatable image? If you set
> > > up the debug UART very early you might be able to output a character
> > > in start.S ?
> >
> > Yes, fastboot expects a relocatable image.
> > As I understand it though, if I get the text base correct, U-boot will
> > not need to relocate.
> >
> > The debug UART is already set up when it fastboot jumps to the loaded 
> > kernel,
> > So I should be able to dump data to the expected raw address and it
> > will show up?
>
> Yes, so long as you know the address. Is the MMU turned off? Cache?

It is unknown what state either of these are in, since I am unfamiliar
at all with how fastboot functions with these.
In U-boot yes the MMU was enabled as well as both I and D cache.

>
> >
> > >
> > > BTW does U-Boot have support for the fastboot protocol? Perhaps you
> > > could just use U-Boot?
> >
> > The Ouya is locked with a signed boot loader, like most consumer
> > android devices.
> > Unlike most other devices, it does not have a hardware method for
> > entering the bootloader in case of a brick.
> > We are currently using a hacked kernel that stores another kernel in
> > "safe" ram via kexec and hard resets the board, but a proper
> > bootloader would be much more preferable.
>
> OK. Maybe there is someone on this list with a bit more Android
> booting experienec?
>
> >
> > I found one example of where fastboot chainloaded u-boot successfully
> > on the galaxy nexus, from 2013.
> > https://forum.xda-developers.com/galaxy-nexus/bootloader-boot-multi-boot-support-t2201146
>
> OK, I'm sure it is possible. Do you have the source code for the
> fastboot code that boots U-Boot?

No, we have the reference code here:
https://android.googlesource.com/platform/bootable/bootloader/legacy/+/b1fde5cd7d5158b8e6876139ca76a341d0e49708/usbloader/usbloader.c

Unfortunately the behavior observed in the Ouya shows it has been
heavily modified from this baseline.

I've reached out to the dev who performed the work on u-boot for
insight as well.

>
> Regards,
> Simon


[PATCH] i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7

2020-07-06 Thread Patrick Delaunay
Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus
speed is selected.

Handle the stm32mp15 specific compatible to handle FastMode+
registers handling which is different on the stm32mp15 compared
to the stm32f7 or stm32h7.
Indeed, on the stm32mp15, the FastMode+ set and clear registers
are separated while on the other platforms (F7 or H7) the control
is done in a unique register.

Signed-off-by: Patrick Delaunay 
---

 drivers/i2c/stm32f7_i2c.c | 74 ++-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 593f713d6b..2f60911549 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
@@ -154,6 +156,7 @@ struct stm32_i2c_spec {
  * @fall_time: Fall time (ns)
  * @dnf: Digital filter coefficient (0-16)
  * @analog_filter: Analog filter delay (On/Off)
+ * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
  */
 struct stm32_i2c_setup {
u32 speed_freq;
@@ -162,6 +165,7 @@ struct stm32_i2c_setup {
u32 fall_time;
u8 dnf;
bool analog_filter;
+   u32 fmp_clr_offset;
 };
 
 /**
@@ -181,11 +185,26 @@ struct stm32_i2c_timings {
u8 scll;
 };
 
+/**
+ * struct stm32_i2c_priv - private data of the controller
+ * @regs: I2C registers address
+ * @clk: hw i2c clock
+ * @setup: I2C timing setup parameters
+ * @speed: I2C clock frequency of the controller. Standard, Fast or Fast+
+ * @regmap: holds SYSCFG phandle for Fast Mode Plus bit
+ * @regmap_sreg: register address for setting Fast Mode Plus bits
+ * @regmap_creg: register address for clearing Fast Mode Plus bits
+ * @regmap_mask: mask for Fast Mode Plus bits
+ */
 struct stm32_i2c_priv {
struct stm32_i2c_regs *regs;
struct clk clk;
struct stm32_i2c_setup *setup;
u32 speed;
+   struct regmap *regmap;
+   u32 regmap_sreg;
+   u32 regmap_creg;
+   u32 regmap_mask;
 };
 
 static const struct stm32_i2c_spec i2c_specs[] = {
@@ -237,6 +256,14 @@ static const struct stm32_i2c_setup stm32f7_setup = {
.analog_filter = STM32_I2C_ANALOG_FILTER_ENABLE,
 };
 
+static const struct stm32_i2c_setup stm32mp15_setup = {
+   .rise_time = STM32_I2C_RISE_TIME_DEFAULT,
+   .fall_time = STM32_I2C_FALL_TIME_DEFAULT,
+   .dnf = STM32_I2C_DNF_DEFAULT,
+   .analog_filter = STM32_I2C_ANALOG_FILTER_ENABLE,
+   .fmp_clr_offset = 0x40,
+};
+
 static int stm32_i2c_check_device_busy(struct stm32_i2c_priv *i2c_priv)
 {
struct stm32_i2c_regs *regs = i2c_priv->regs;
@@ -761,6 +788,29 @@ static int stm32_i2c_setup_timing(struct stm32_i2c_priv 
*i2c_priv,
return 0;
 }
 
+static int stm32_i2c_write_fm_plus_bits(struct stm32_i2c_priv *i2c_priv)
+{
+   int ret;
+   bool enable = i2c_priv->speed > I2C_SPEED_FAST_RATE;
+
+   /* Optional */
+   if (IS_ERR_OR_NULL(i2c_priv->regmap))
+   return 0;
+
+   if (i2c_priv->regmap_sreg == i2c_priv->regmap_creg)
+   ret = regmap_update_bits(i2c_priv->regmap,
+i2c_priv->regmap_sreg,
+i2c_priv->regmap_mask,
+enable ? i2c_priv->regmap_mask : 0);
+   else
+   ret = regmap_write(i2c_priv->regmap,
+  enable ? i2c_priv->regmap_sreg :
+   i2c_priv->regmap_creg,
+  i2c_priv->regmap_mask);
+
+   return ret;
+}
+
 static int stm32_i2c_hw_config(struct stm32_i2c_priv *i2c_priv)
 {
struct stm32_i2c_regs *regs = i2c_priv->regs;
@@ -775,6 +825,11 @@ static int stm32_i2c_hw_config(struct stm32_i2c_priv 
*i2c_priv)
/* Disable I2C */
clrbits_le32(>cr1, STM32_I2C_CR1_PE);
 
+   /* Setup Fast mode plus if necessary */
+   ret = stm32_i2c_write_fm_plus_bits(i2c_priv);
+   if (ret)
+   return ret;
+
/* Timing settings */
timing |= STM32_I2C_TIMINGR_PRESC(t.presc);
timing |= STM32_I2C_TIMINGR_SCLDEL(t.scldel);
@@ -850,6 +905,7 @@ static int stm32_ofdata_to_platdata(struct udevice *dev)
 {
struct stm32_i2c_priv *i2c_priv = dev_get_priv(dev);
u32 rise_time, fall_time;
+   int ret;
 
i2c_priv->setup = (struct stm32_i2c_setup *)dev_get_driver_data(dev);
if (!i2c_priv->setup)
@@ -863,6 +919,22 @@ static int stm32_ofdata_to_platdata(struct udevice *dev)
if (fall_time)
i2c_priv->setup->fall_time = fall_time;
 
+   /* Optional */
+   i2c_priv->regmap = syscon_regmap_lookup_by_phandle(dev,
+  "st,syscfg-fmp");
+   if (!IS_ERR(i2c_priv->regmap)) {
+   u32 fmp[3];
+
+   ret = dev_read_u32_array(dev, 

[PATCH 3/3] ARM: dts: stm32mp1: DT alignment with Linux kernel v5.8-rc1

2020-07-06 Thread Patrick Delaunay
DT alignment with Linux kernel v5.8-rc1 for the STM32MP15x soc
device tree files and the STMicroelectronics boards device tree files.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp15-pinctrl.dtsi | 562 ++--
 arch/arm/dts/stm32mp15-u-boot.dtsi  |   4 +
 arch/arm/dts/stm32mp151.dtsi|  48 +--
 arch/arm/dts/stm32mp157.dtsi|   8 +-
 arch/arm/dts/stm32mp157c-dk2.dts|   8 -
 arch/arm/dts/stm32mp157c-ed1.dts|   7 +-
 arch/arm/dts/stm32mp157c-ev1.dts|  14 +-
 arch/arm/dts/stm32mp15xx-dkx.dtsi   |  20 +-
 8 files changed, 577 insertions(+), 94 deletions(-)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index b0c2aa52f8..e9525b5d06 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -6,7 +6,7 @@
 #include 
 
  {
-   adc1_in6_pins_a: adc1-in6 {
+   adc1_in6_pins_a: adc1-in6-0 {
pins {
pinmux = ;
};
@@ -21,6 +21,13 @@
};
};
 
+   adc12_ain_pins_b: adc12-ain-1 {
+   pins {
+   pinmux = , /* ADC1 in6 */
+; /* ADC2 in2 */
+   };
+   };
+
adc12_usb_cc_pins_a: adc12-usb-cc-pins-0 {
pins {
pinmux = , /* ADC12 in18 
*/
@@ -37,7 +44,7 @@
};
};
 
-   cec_pins_sleep_a: cec-sleep-0 {
+   cec_sleep_pins_a: cec-sleep-0 {
pins {
pinmux = ; /* HDMI_CEC */
};
@@ -52,19 +59,19 @@
};
};
 
-   cec_pins_sleep_b: cec-sleep-1 {
+   cec_sleep_pins_b: cec-sleep-1 {
pins {
pinmux = ; /* HDMI_CEC */
};
};
 
-   dac_ch1_pins_a: dac-ch1 {
+   dac_ch1_pins_a: dac-ch1-0 {
pins {
pinmux = ;
};
};
 
-   dac_ch2_pins_a: dac-ch2 {
+   dac_ch2_pins_a: dac-ch2-0 {
pins {
pinmux = ;
};
@@ -142,7 +149,7 @@
};
};
 
-   ethernet0_rgmii_pins_sleep_a: rgmii-sleep-0 {
+   ethernet0_rgmii_sleep_pins_a: rgmii-sleep-0 {
pins1 {
pinmux = , /* 
ETH_RGMII_CLK125 */
 , /* 
ETH_RGMII_GTX_CLK */
@@ -162,6 +169,57 @@
};
};
 
+   ethernet0_rgmii_pins_b: rgmii-1 {
+   pins1 {
+   pinmux = , /* 
ETH_RGMII_CLK125 */
+, /* 
ETH_RGMII_GTX_CLK */
+, /* 
ETH_RGMII_TXD0 */
+, /* 
ETH_RGMII_TXD1 */
+, /* 
ETH_RGMII_TXD2 */
+, /* 
ETH_RGMII_TXD3 */
+, /* 
ETH_RGMII_TX_CTL */
+; /* ETH_MDC */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   pins2 {
+   pinmux = ; /* ETH_MDIO */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins3 {
+   pinmux = , /* 
ETH_RGMII_RXD0 */
+, /* 
ETH_RGMII_RXD1 */
+, /* 
ETH_RGMII_RXD2 */
+, /* 
ETH_RGMII_RXD3 */
+, /* 
ETH_RGMII_RX_CLK */
+; /* 
ETH_RGMII_RX_CTL */
+   bias-disable;
+   };
+   };
+
+   ethernet0_rgmii_sleep_pins_b: rgmii-sleep-1 {
+   pins1 {
+   pinmux = , /* 
ETH_RGMII_CLK125 */
+, /* 
ETH_RGMII_GTX_CLK */
+, /* 
ETH_RGMII_TXD0 */
+, /* 
ETH_RGMII_TXD1 */
+, /* 
ETH_RGMII_TXD2 */
+, /* 
ETH_RGMII_TXD3 */
+, /* 
ETH_RGMII_TX_CTL */
+, /* ETH_MDC */
+, /* ETH_MDIO */
+, /* 
ETH_RGMII_RXD0 */
+, /* 
ETH_RGMII_RXD1 */
+, /* 
ETH_RGMII_RXD2 */
+, /* 
ETH_RGMII_RXD3 */
+, /* 
ETH_RGMII_RX_CLK */
+; /* 
ETH_RGMII_RX_CTL */
+};
+   };
+
ethernet0_rgmii_pins_c: rgmii-2 {
pins1 {
pinmux = , /* 
ETH_RGMII_CLK125 */
@@ -233,7 +291,7 @@
};
};
 
-   ethernet0_rmii_pins_sleep_a: 

[PATCH 2/3] i2c: stm32f7: add stm32mp15 compatible

2020-07-06 Thread Patrick Delaunay
Add a new compatible "st,stm32mp15-i2c" introduced in Linux kernel v5.8

Signed-off-by: Patrick Delaunay 
---

 drivers/i2c/stm32f7_i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index ada8f4095e..593f713d6b 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -873,6 +873,7 @@ static const struct dm_i2c_ops stm32_i2c_ops = {
 
 static const struct udevice_id stm32_i2c_of_match[] = {
{ .compatible = "st,stm32f7-i2c", .data = (ulong)_setup },
+   { .compatible = "st,stm32mp15-i2c", .data = (ulong)_setup },
{}
 };
 
-- 
2.17.1



[PATCH 1/3] ARM: dts: rename stm32mp15xx-avenger96 ethernet0_rgmii_pins

2020-07-06 Thread Patrick Delaunay
Alignment with pins name used in Linux kernel v5.8.

It is a preleminary step for device tree alignment.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp15-pinctrl.dtsi  | 4 ++--
 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index c385896ebc..b0c2aa52f8 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -162,7 +162,7 @@
};
};
 
-   ethernet0_rgmii_pins_b: rgmii-1 {
+   ethernet0_rgmii_pins_c: rgmii-2 {
pins1 {
pinmux = , /* 
ETH_RGMII_CLK125 */
 , /* 
ETH_RGMII_GTX_CLK */
@@ -193,7 +193,7 @@
};
};
 
-   ethernet0_rgmii_pins_sleep_b: rgmii-sleep-1 {
+   ethernet0_rgmii_sleep_pins_c: rgmii-sleep-2 {
pins1 {
pinmux = , /* 
ETH_RGMII_CLK125 */
 , /* 
ETH_RGMII_GTX_CLK */
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts 
b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
index c1cc80bcf5..88f25d89b2 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
+++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
@@ -89,8 +89,8 @@
 
  {
status = "okay";
-   pinctrl-0 = <_rgmii_pins_b>;
-   pinctrl-1 = <_rgmii_pins_sleep_b>;
+   pinctrl-0 = <_rgmii_pins_c>;
+   pinctrl-1 = <_rgmii_sleep_pins_c>;
pinctrl-names = "default", "sleep";
phy-mode = "rgmii";
max-speed = <1000>;
-- 
2.17.1



Re: [RFC PATCH 01/16] patman: Use test_util to show test results

2020-07-06 Thread Daniel Axtens
Daniel Axtens  writes:

> Hi Simon,
>
> I can't see a cover letter so apologies if I've misunderstood something
> basic, but this doesn't appear to apply to the patchwork tree - I'm
> guessing the patchwork relevance is with regards to the last few patches
> that (AFAICT) parse the patchwork web interface for information?

Ah, nevermind, the cover letter got caught in moderation. I've released it.

pwclient speaks the old, less documented XML-RPC API. We have a new
REST API which is much better documented, and is explorable
(e.g. https://patchwork.ozlabs.org/api/ and
https://patchwork.readthedocs.io/en/latest/api/rest/ )

> I haven't fully digested the patches (and I lack a lot of context) but
> is there a reason the patchwork API isn't able to meet your needs here?
> (And if so, could we extend it rather than having you parse the frontend?)

So these questions still stand but for the REST API.

Regards,
Daniel

>
> Regards,
> Daniel
>
>> This handles skipped tests correctly, so use it instead of the existing
>> code.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  tools/patman/main.py  | 8 ++--
>>  tools/patman/test_util.py | 6 +++---
>>  2 files changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/patman/main.py b/tools/patman/main.py
>> index 28a9a26087..03668d1bb8 100755
>> --- a/tools/patman/main.py
>> +++ b/tools/patman/main.py
>> @@ -25,6 +25,7 @@ from patman import patchstream
>>  from patman import project
>>  from patman import settings
>>  from patman import terminal
>> +from patman import test_util
>>  from patman import test_checkpatch
>>  
>>  
>> @@ -101,12 +102,7 @@ elif options.test:
>>  suite = doctest.DocTestSuite(module)
>>  suite.run(result)
>>  
>> -# TODO: Surely we can just 'print' result?
>> -print(result)
>> -for test, err in result.errors:
>> -print(err)
>> -for test, err in result.failures:
>> -print(err)
>> +sys.exit(test_util.ReportResult('patman', None, result))
>>  
>>  # Called from git with a patch filename as argument
>>  # Printout a list of additional CC recipients for this patch
>> diff --git a/tools/patman/test_util.py b/tools/patman/test_util.py
>> index aac58fb72f..0827488f33 100644
>> --- a/tools/patman/test_util.py
>> +++ b/tools/patman/test_util.py
>> @@ -123,12 +123,12 @@ def ReportResult(toolname:str, test_name: str, result: 
>> unittest.TestResult):
>>  for test, err in result.failures:
>>  print(err, result.failures)
>>  if result.skipped:
>> -print('%d binman test%s SKIPPED:' %
>> -  (len(result.skipped), 's' if len(result.skipped) > 1 else ''))
>> +print('%d %s test%s SKIPPED:' % (len(result.skipped), toolname,
>> +'s' if len(result.skipped) > 1 else ''))
>>  for skip_info in result.skipped:
>>  print('%s: %s' % (skip_info[0], skip_info[1]))
>>  if result.errors or result.failures:
>> -print('binman tests FAILED')
>> +print('%s tests FAILED' % toolname)
>>  return 1
>>  return 0
>>  
>> -- 
>> 2.27.0.212.ge8ba1cc988-goog
>>
>> ___
>> Patchwork mailing list
>> patchw...@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/patchwork


Secondary UART

2020-07-06 Thread Ralf Spiwoks
Hello,

I need to use a secondary UART, in addition to the primary UART used for the 
console.
The secondary UART will be used to run IPMI commands to an IPMController over a 
serial interface.

What do I have to do?

Cheers,
Ralf.


Re: [RFC PATCH 01/16] patman: Use test_util to show test results

2020-07-06 Thread Daniel Axtens
Hi Simon,

I can't see a cover letter so apologies if I've misunderstood something
basic, but this doesn't appear to apply to the patchwork tree - I'm
guessing the patchwork relevance is with regards to the last few patches
that (AFAICT) parse the patchwork web interface for information?

I haven't fully digested the patches (and I lack a lot of context) but
is there a reason the patchwork API isn't able to meet your needs here?
(And if so, could we extend it rather than having you parse the frontend?)

Regards,
Daniel

> This handles skipped tests correctly, so use it instead of the existing
> code.
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/patman/main.py  | 8 ++--
>  tools/patman/test_util.py | 6 +++---
>  2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/tools/patman/main.py b/tools/patman/main.py
> index 28a9a26087..03668d1bb8 100755
> --- a/tools/patman/main.py
> +++ b/tools/patman/main.py
> @@ -25,6 +25,7 @@ from patman import patchstream
>  from patman import project
>  from patman import settings
>  from patman import terminal
> +from patman import test_util
>  from patman import test_checkpatch
>  
>  
> @@ -101,12 +102,7 @@ elif options.test:
>  suite = doctest.DocTestSuite(module)
>  suite.run(result)
>  
> -# TODO: Surely we can just 'print' result?
> -print(result)
> -for test, err in result.errors:
> -print(err)
> -for test, err in result.failures:
> -print(err)
> +sys.exit(test_util.ReportResult('patman', None, result))
>  
>  # Called from git with a patch filename as argument
>  # Printout a list of additional CC recipients for this patch
> diff --git a/tools/patman/test_util.py b/tools/patman/test_util.py
> index aac58fb72f..0827488f33 100644
> --- a/tools/patman/test_util.py
> +++ b/tools/patman/test_util.py
> @@ -123,12 +123,12 @@ def ReportResult(toolname:str, test_name: str, result: 
> unittest.TestResult):
>  for test, err in result.failures:
>  print(err, result.failures)
>  if result.skipped:
> -print('%d binman test%s SKIPPED:' %
> -  (len(result.skipped), 's' if len(result.skipped) > 1 else ''))
> +print('%d %s test%s SKIPPED:' % (len(result.skipped), toolname,
> +'s' if len(result.skipped) > 1 else ''))
>  for skip_info in result.skipped:
>  print('%s: %s' % (skip_info[0], skip_info[1]))
>  if result.errors or result.failures:
> -print('binman tests FAILED')
> +print('%s tests FAILED' % toolname)
>  return 1
>  return 0
>  
> -- 
> 2.27.0.212.ge8ba1cc988-goog
>
> ___
> Patchwork mailing list
> patchw...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork


Cover Letter of Patchsets

2020-07-06 Thread Leo Liang
Hi Tom,

I am Leo, just recently joined the community.
and been picking up the guide line of uboot's development.

I am a bit curious about the policy on the cover letter of patchsets.
Is cover letter mandatory ?

IMHO, making it mandatory, especially on patchsets that consist of more than 1 
patch, is more than useful and of great advantages.

1. Making patches clearer for peer and maintainer review
   
   The reviewer and maintainer could immediately understand,
   or at least get the idea of, the whole patchset
   through only reading this ONE cover letter
   without having to dive into each of the patch.

   And thus quickly determine if the patchset solves the problem
   or if the patchset is well organized.

2. Helping the author better organize the patchset
   
   Writing the cover letter would require the author 
   to scrutinize the patchset structure again,
   in order to elaborate his/her craft.

   So when composing the letter, the relevance of each patch
   would be thoroghly looked over and the patchset might be
   refined into small but more closely-related patchsets.

   And it would be easier for the maintainer to pull small gradual changes 
   than a huge patchset with lots of changes at once.
   

In all, I think it would be nice to write cover letter to introduce the work.

If I miss anything or misunderstand anything please let me know, thanks in 
advance.

Best regards,
Leo


[PATCH] arm: stm32mp: stm32prog: check result of find_mmc_device

2020-07-06 Thread Patrick Delaunay
Check result of find_mmc_device() before calling mmc_init().

This patch avoid a data abort when the command try to acces
to sd/mmc device deactivated in device tree.

Fixes: aff4c5dd8265 ("stm32mp: stm32prog: add MMC device")
Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index c5b8841b23..e4199dbaa5 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -560,7 +560,7 @@ static int init_device(struct stm32prog_data *data,
 #ifdef CONFIG_MMC
case STM32PROG_MMC:
mmc = find_mmc_device(dev->dev_id);
-   if (mmc_init(mmc)) {
+   if (!mmc || mmc_init(mmc)) {
stm32prog_err("mmc device %d not found", dev->dev_id);
return -ENODEV;
}
-- 
2.17.1



Re: [PATCH 2/2] test/py: efi_secboot: more fixes against pylint

2020-07-06 Thread Heinrich Schuchardt
On 16.06.20 01:16, AKASHI Takahiro wrote:
> More fixes against pylint warnings that autopep8 didn't handle
> in the previous commit.
>
> Signed-off-by: AKASHI Takahiro 

This patch has to be rebased:

error: patch failed: test/py/tests/test_efi_secboot/conftest.py:14
error: test/py/tests/test_efi_secboot/conftest.py: patch does not apply
error: patch failed: test/py/tests/test_efi_secboot/test_authvar.py:9
error: test/py/tests/test_efi_secboot/test_authvar.py: patch does not apply
error: patch failed: test/py/tests/test_efi_secboot/test_signed.py:9
error: test/py/tests/test_efi_secboot/test_signed.py: patch does not apply
error: patch failed: test/py/tests/test_efi_secboot/test_unsigned.py:9
error: test/py/tests/test_efi_secboot/test_unsigned.py: patch does not apply
Patch failed at 0001 test/py: efi_secboot: more fixes against pylint

Best regards

Heinrich


Re: [PATCH 1/2] test/py: efi_secboot: apply autopep8

2020-07-06 Thread Heinrich Schuchardt
On 16.06.20 01:16, AKASHI Takahiro wrote:
> Python's autopep8 can automatically correct some of warnings from pylint
> and rewrite the code in a pretty print format. So just do it.
>
> Signed-off-by: AKASHI Takahiro 
> Suggested-by: Heinrich Schuchardt 
> ---
>  test/py/tests/test_efi_secboot/conftest.py| 162 ++
>  test/py/tests/test_efi_secboot/defs.py|  14 +-
>  .../py/tests/test_efi_secboot/test_authvar.py |   1 +
>  test/py/tests/test_efi_secboot/test_signed.py |   1 +
>  .../tests/test_efi_secboot/test_unsigned.py   |  37 ++--
>  5 files changed, 118 insertions(+), 97 deletions(-)
>
> diff --git a/test/py/tests/test_efi_secboot/conftest.py 
> b/test/py/tests/test_efi_secboot/conftest.py
> index 5ac0389064e8..f74b4b109a7b 100644
> --- a/test/py/tests/test_efi_secboot/conftest.py
> +++ b/test/py/tests/test_efi_secboot/conftest.py
> @@ -10,6 +10,8 @@ from subprocess import call, check_call, check_output, 
> CalledProcessError
>  from defs import *
>
>  # from test/py/conftest.py
> +
> +
>  def tool_is_in_path(tool):
>  for path in os.environ["PATH"].split(os.pathsep):
>  fn = os.path.join(path, tool)
> @@ -20,13 +22,15 @@ def tool_is_in_path(tool):
>  #
>  # Fixture for UEFI secure boot test
>  #
> +
> +
>  @pytest.fixture(scope='session')
>  def efi_boot_env(request, u_boot_config):
>  """Set up a file system to be used in UEFI secure boot test.
>
>  Args:
>  request: Pytest request object.
> - u_boot_config: U-boot configuration.
> +u_boot_config: U-boot configuration.
>
>  Return:
>  A path to disk image to be used for testing
> @@ -48,20 +52,21 @@ def efi_boot_env(request, u_boot_config):
>
>  # create a disk/partition
>  check_call('dd if=/dev/zero of=%s bs=1MiB count=%d'
> -% (image_path, image_size), shell=True)
> +   % (image_path, image_size), shell=True)
>  check_call('sgdisk %s -n 1:0:+%dMiB'
> -% (image_path, part_size), shell=True)
> +   % (image_path, part_size), shell=True)
>  # create a file system
>  check_call('dd if=/dev/zero of=%s.tmp bs=1MiB count=%d'
> -% (image_path, part_size), shell=True)
> +   % (image_path, part_size), shell=True)
>  check_call('mkfs -t %s %s.tmp' % (fs_type, image_path), shell=True)
>  check_call('dd if=%s.tmp of=%s bs=1MiB seek=1 count=%d conv=notrunc'
> -% (image_path, image_path, 1), shell=True)
> +   % (image_path, image_path, 1), shell=True)
>  check_call('rm %s.tmp' % image_path, shell=True)
> -loop_dev = check_output('sudo losetup -o 1MiB --sizelimit %dMiB 
> --show -f %s | tr -d "\n"'
> -% (part_size, image_path), 
> shell=True).decode()
> +loop_dev = check_output(
> +'sudo losetup -o 1MiB --sizelimit %dMiB --show -f %s | tr -d 
> "\n"' %
> +(part_size, image_path), shell=True).decode()
>  check_output('sudo mount -t %s -o umask=000 %s %s'
> -% (fs_type, loop_dev, mnt_point), shell=True)
> + % (fs_type, loop_dev, mnt_point), shell=True)
>
>  # suffix
>  # *.key: RSA private key in PEM
> @@ -73,75 +78,88 @@ def efi_boot_env(request, u_boot_config):
>  # *.efi.signed: signed UEFI image
>
>  # Create signature database
> -## PK
> -check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj 
> /CN=TEST_PK/ -keyout PK.key -out PK.crt -nodes -days 365'
> -% mnt_point, shell=True)
> -check_call('cd %s; %scert-to-efi-sig-list -g %s PK.crt PK.esl; 
> %ssign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth'
> -% (mnt_point, EFITOOLS_PATH, GUID, 
> EFITOOLS_PATH),
> -shell=True)
> -## PK_null for deletion
> -check_call('cd %s; sleep 2; touch PK_null.esl; %ssign-efi-sig-list 
> -c PK.crt -k PK.key PK PK_null.esl PK_null.auth'
> -% (mnt_point, EFITOOLS_PATH), shell=True)
> -## KEK
> -check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj 
> /CN=TEST_KEK/ -keyout KEK.key -out KEK.crt -nodes -days 365'
> -% mnt_point, shell=True)
> -check_call('cd %s; %scert-to-efi-sig-list -g %s KEK.crt KEK.esl; 
> %ssign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth'
> -% (mnt_point, EFITOOLS_PATH, GUID, 
> EFITOOLS_PATH),
> -shell=True)
> -## db
> -check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj 
> /CN=TEST_db/ -keyout db.key -out db.crt -nodes -days 365'
> -% mnt_point, shell=True)
> -check_call('cd %s; %scert-to-efi-sig-list -g %s db.crt db.esl; 

Re: Pull request for UEFI sub-system for efi-2020-10-rc1

2020-07-06 Thread Heinrich Schuchardt
On 06.07.20 01:40, Tom Rini wrote:
> On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote:
>> The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7:
>>
>>   Merge tag 'efi-2020-07-rc6-2' of
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39
>> -0400)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
>> tags/efi-2020-10-rc1
>>
>> for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357:
>>
>>   efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200)
>>
>> 
>> Pull request for UEFI sub-system for efi-2020-10-rc1
>>
>> This series comprises error corrections for the UEFI subsystem:
>>
>> * correct consideration of timestamps for variable authentication
>> * correct collection of data regions for code authentication
>> * correct unit tests to test loading dbx
>> * enable FAT_WRITE as required by the UEFI spec
>
> So, FAT_WRITE is required by the UEFI spec, ok.  Are we exposing the
> ability to write files via the UEFI API?  What happens if we return

Yes the UEFI API allows to write files. If the write fails we return an
error code conforming to the UEFI specification.

But especially I want to save non-volatile UEFI variables on the EFI
system partition in v2020.10. Cf.
https://patchwork.ozlabs.org/project/uboot/list/?series=167069
Currently I am reworking that patch series.

> failure to write here?  I'm asking because the first thing I see
> reviewing this is thee large number of platforms with:
>u-boot: add: 30/0, grow: 5/-4 bytes: 139792/-10412 (129380)
>  function   old new   
> delta
>  tmpbuf_cluster   -  131072 
> +131072
>
> For FAT write support.  Perhaps another way of looking at it is, can we
> rework the FAT write support to get that buffer dynamically?  Thanks!
>

I will send a patch to allocate tmpbuf_cluster dynamically.

Best regards

Heinrich



Re: [PATCH v9 1/2] i2c: i2c-cortina: added CAxxxx I2C support

2020-07-06 Thread Heiko Schocher

Hello Alex, Arthur,

Am 01.06.2020 um 21:56 schrieb Alex Nemirovsky:

From: Arthur Li 

Add I2C controller support for Cortina Access CA SoCs

Signed-off-by: Arthur Li 
Signed-off-by: Alex Nemirovsky 
CC: Heiko Schocher 
Reviewed-by: Heiko Schocher 

---

Changes in v9:
- specially include bitops.h and delay.h which
were removed from common.h

Changes in v8:
- No code change
- Split out individual driver from Cortina Package 2 patch series
to help streamline acceptence into master

Changes in v7:
- Added additional description info in I2C KConfig

Changes in v6:
- Add I2C DT binding document

Changes in v4:
- Utilize standard I2C macros from 
- Return ETIMEDOUT in funcs that can timeout
- Return i2c_xfer_init() result to caller of i2c_read() if it
fails within i2c_read() execution
- Fix misc. style guide conformance issues
- Use printf() to report i2c_xfer() runtime errors
instead of debug()

  MAINTAINERS  |   4 +
  doc/device-tree-bindings/i2c/i2c-cortina.txt |  18 ++
  drivers/i2c/Kconfig  |   8 +
  drivers/i2c/Makefile |   1 +
  drivers/i2c/i2c-cortina.c| 346 +++
  drivers/i2c/i2c-cortina.h|  87 +++
  6 files changed, 464 insertions(+)
  create mode 100644 doc/device-tree-bindings/i2c/i2c-cortina.txt
  create mode 100644 drivers/i2c/i2c-cortina.c
  create mode 100644 drivers/i2c/i2c-cortina.h


travis build fails:

https://travis-ci.org/github/hsdenx/u-boot-i2c/jobs/705286814#L1358

seems you need to add:

#include 


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


Re: [PATCH 17/17] board: xen: De-initialize before jumping to Linux

2020-07-06 Thread Anastasiia Lukianenko
On Thu, 2020-07-02 at 21:50 -0600, Simon Glass wrote:
> On Wed, 1 Jul 2020 at 10:30, Anastasiia Lukianenko <
> vicooo...@gmail.com> wrote:
> > 
> > From: Oleksandr Andrushchenko 
> > 
> > Free resources used by Xen board before jumping to Linux kernel.
> > 
> > Signed-off-by: Oleksandr Andrushchenko <
> > oleksandr_andrushche...@epam.com>
> > Signed-off-by: Anastasiia Lukianenko <
> > anastasiia_lukiane...@epam.com>
> > ---
> >  board/xen/xenguest_arm64/xenguest_arm64.c | 6 ++
> >  drivers/xen/hypervisor.c  | 8 
> >  include/xen.h | 1 +
> >  3 files changed, 15 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> 
> 
> > 
> > diff --git a/board/xen/xenguest_arm64/xenguest_arm64.c
> > b/board/xen/xenguest_arm64/xenguest_arm64.c
> > index b4e1650f99..76a18bea8b 100644
> > --- a/board/xen/xenguest_arm64/xenguest_arm64.c
> > +++ b/board/xen/xenguest_arm64/xenguest_arm64.c
> > @@ -13,6 +13,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #include 
> >  #include 
> > @@ -195,3 +196,8 @@ int print_cpuinfo(void)
> > return 0;
> >  }
> > 
> > +void board_cleanup_before_linux(void)
> > +{
> > +   xen_fini();
> > +}
> > +
> > diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
> > index f3c2504d72..8d7d320839 100644
> > --- a/drivers/xen/hypervisor.c
> > +++ b/drivers/xen/hypervisor.c
> > @@ -279,3 +279,11 @@ void xen_init(void)
> > init_gnttab();
> >  }
> > 
> > +void xen_fini(void)
> > +{
> > +   debug("%s\n", __func__);
> > +
> > +   fini_gnttab();
> > +   fini_xenbus();
> > +   fini_events();
> > +}
> > diff --git a/include/xen.h b/include/xen.h
> > index 1d6f74cc92..327d7e132b 100644
> > --- a/include/xen.h
> > +++ b/include/xen.h
> > @@ -7,5 +7,6 @@
> >  #define __XEN_H__
> > 
> >  void xen_init(void);
> > +void xen_fini(void);
> 
> Comment? What does this do?
> 
Ok, will add.
> 
> > 
> >  #endif /* __XEN_H__ */
> > --
> > 2.17.1
> > 
> 
> - SImon

Regards,
Anastasiia


Re: Seemless Boot Splash on iMX-based boards

2020-07-06 Thread Stefano Babic
Hi Igor,

my two cents from previous experience:

On 06.07.20 10:34, Igor Opaniuk wrote:
> Hi,
> 
> Does anyone have experience in setting up seamless
> boot splash on iMX-based platforms?
> 
> I'm currently trying to do that on iMX7-based board with
> 4.9 2.3.x IMX downstream kernel running.
> 

Well, i.MX7 have a chance because it has no GPU. I did this for TI based
boards, too.

But let me say that it is tricky and it creates big dependencies between
U-Boot and kernel. And to get a flicker-free images, the clock setup
should be exactly the same between U-Boot and kernel, and this is not
often (or never) the same because we need a lot of more features
(layers, overlays, ..) in kernel, while we just to need to show
something like a logo in U-Boot.

With the introduction of DRM, things are more difficult. Take also into
account that a small change in kernel can be enough to have a weird
transition on the framebuffer, and it is more nasty as to start with a
black screen.

> I've backported console deferred takeover patch-series for fbcon [1],
> which permits the contents of the framebuffer (initialized before in U-Boot)
> to stay in place as is till error message is shown
> or boot is finished.
> 
> The initial splash is shown in U-Boot(mainline) (mxsfb driver is used
> for controller/fb initialization).
> 
> Nevertheless, MXSFB controller every time keeps resetting just after
> U-Boot->Linux takeover and fb is cleared (I see a black screen) till
> login request shows up.

Right.

> 
> Questions:
> 1. Did anyone have a chance to work on such setups based on deferred
> console "feature"?
> 2. Does it make sense at all to continue moving towards with this approach
> (we initialize graphics core and show boot splash by firmware/bootloader,
> then hand over it to Linux).

My personal point of view: it makes much more sense to invest the time
to speed up the boot process, and let the kernel to boot in a shorten
time. And if this time is short enough, kernel has initialized the
framebuffer and can show something. This leads also to the main focus
for U-Boot, that should be to start the kernel in the shortest time
possible.

> Taking into account on-going transition to DRM/KMS in the mainline kernel

Fully agree.

> and that fact that there is no any mainline compatible way to take over
> an initialized graphics core, I assume the only generic solution could be
> avoiding showing boot logo

This is my position, too, and I do not show logo in U-Boot since some
years (ok, since starting from DRM /KMS). And well, with i.MX6 / i.MX8,
I do not see a chance without a very big effort, and IMHO it is not
worth of it.

> at all and do that only from the Linux (
> Plymouth-based etc.)

Agree.

> 
> Any comments are welcome. Thanks!
> 
> [1] https://patchwork.kernel.org/patch/10432641/
> 

Best regards,
Stefano

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


Re: [PATCH 15/17] xen: pvblock: Implement front-back protocol and do IO

2020-07-06 Thread Anastasiia Lukianenko
On Thu, 2020-07-02 at 21:50 -0600, Simon Glass wrote:
> On Wed, 1 Jul 2020 at 10:30, Anastasiia Lukianenko <
> vicooo...@gmail.com> wrote:
> > 
> > From: Anastasiia Lukianenko 
> > 
> > Implement Xen para-virtual frontend to backend communication
> > and actually read/write disk data.
> > 
> > This is based on mini-os implementation of the para-virtual block
> > frontend driver.
> > 
> > Signed-off-by: Oleksandr Andrushchenko <
> > oleksandr_andrushche...@epam.com>
> > Signed-off-by: Anastasiia Lukianenko <
> > anastasiia_lukiane...@epam.com>
> > ---
> >  drivers/xen/events.c  |   2 +-
> >  drivers/xen/pvblock.c | 311
> > --
> >  2 files changed, 301 insertions(+), 12 deletions(-)
> 
> Please can you comment structs and non-trival functions?

Sure.

Regards,
Anastasiia


Re: [PATCH 14/17] xen: pvblock: Read XenStore configuration and initialize

2020-07-06 Thread Anastasiia Lukianenko
On Thu, 2020-07-02 at 21:50 -0600, Simon Glass wrote:
> Hi Anastasiia,
> 
> On Wed, 1 Jul 2020 at 10:30, Anastasiia Lukianenko <
> vicooo...@gmail.com> wrote:
> > 
> > From: Anastasiia Lukianenko 
> > 
> > Read essential virtual block device configuration data from
> > XenStore,
> > initialize front ring and event channel.
> > Update block device description with actual block size.
> > 
> > Use code for XenStore from mini-os.
> > 
> > Signed-off-by: Oleksandr Andrushchenko <
> > oleksandr_andrushche...@epam.com>
> > Signed-off-by: Anastasiia Lukianenko <
> > anastasiia_lukiane...@epam.com>
> > ---
> >  drivers/xen/pvblock.c | 272
> > +-
> >  1 file changed, 271 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/xen/pvblock.c b/drivers/xen/pvblock.c
> > index 6ce0ae97c3..9ed18be633 100644
> > --- a/drivers/xen/pvblock.c
> > +++ b/drivers/xen/pvblock.c
> > @@ -1,6 +1,7 @@
> >  /*
> >   * SPDX-License-Identifier:GPL-2.0+
> >   *
> > + * (C) 2007-2008 Samuel Thibault.
> >   * (C) Copyright 2020 EPAM Systems Inc.
> >   */
> >  #include 
> > @@ -10,26 +11,289 @@
> >  #include 
> >  #include 
> > 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> > 
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #define DRV_NAME   "pvblock"
> >  #define DRV_NAME_BLK   "pvblock_blk"
> > 
> > +#define O_RDONLY   00
> > +#define O_RDWR 02
> > +
> > +struct blkfront_info {
> > +   u64 sectors;
> > +   unsigned int sector_size;
> > +   int mode;
> > +   int info;
> > +   int barrier;
> > +   int flush;
> > +};
> > +
> >  struct blkfront_dev {
> > -   char dummy;
> > +   domid_t dom;
> > +
> > +   struct blkif_front_ring ring;
> > +   grant_ref_t ring_ref;
> > +   evtchn_port_t evtchn;
> > +   blkif_vdev_t handle;
> > +
> > +   char *nodename;
> > +   char *backend;
> > +   struct blkfront_info info;
> > +   unsigned int devid;
> 
> How about some comments?
> 

Ok, will add.

> Regards,
> Simon

Regards,
Anastasiia


Re: [PATCH v3 00/10] new rtc methods, rtc command, and tests

2020-07-06 Thread Heiko Schocher

Hello Rasmu,

Am 02.06.2020 um 21:13 schrieb Rasmus Villemoes:

I need access to registers other than just the timekeeping ones of the
pcf2127, so I wanted to implement ->read8 and ->write8. But for
testing these it appeared there was no convenient way to invoke those
from the shell, so I also ended up adding such a command.

Also, it seemed more natural to provide array variants that can read
or write several registers at once, so rtc_ops is expanded a bit.

Simon, I've taken the liberty of keeping your R-Bs despite the first
bullet below, yell if that's inappropriate.

Changes in v3:

- Call the functions dm_rtc_read/dm_rtc_write rather than just
   rtc_read/rtc_write, since the latter names are used for local
   helpers by a number of drivers. That also matches the existing
   dm_rtc_set/dm_rtc_get (though then not the existing
   rtc_read{8,16,32}).

- Update the rtc command (patch 6) as per Simon's feedback (parse
   input as hex, avoid overlong lines, use print_buffer()).
   
- Update the tests (patches 9 and 10) according to these changes.


Changes in v2:

- Use simply "read" and "write" instead of "read8_array",
   "write8_array", both for functions and methods, as suggested by
   Simon.

- The rtc command's interface has been simplified a bit (no separate
   read/readm; the number of arguments determines whether the user
   wants the result on the console or to a memory address)

- Add tests, both of rtc_{read,write}() and of the shell command,
   fixing a few things I stumbled on.

Rasmus Villemoes (10):
   rtc: add dm_rtc_read helper and ->read method
   rtc: add dm_rtc_write() helper
   rtc: fall back to ->{read,write} if ->{read,write}8 are not provided
   rtc: pcf2127: provide ->read method
   rtc: pcf2127: provide ->write method
   rtc: add rtc command
   rtc: sandbox-rtc: fix set method
   rtc: i2c_rtc_emul: catch any write to the "reset" register
   test: dm: rtc: add test of dm_rtc_read, dm_rtc_write
   test: dm: rtc: add tests of rtc shell command

  arch/sandbox/include/asm/rtc.h |   5 +
  cmd/Kconfig|   6 ++
  cmd/Makefile   |   1 +
  cmd/rtc.c  | 167 +
  drivers/rtc/i2c_rtc_emul.c |   3 +-
  drivers/rtc/pcf2127.c  |  13 ++-
  drivers/rtc/rtc-uclass.c   |  56 ++-
  drivers/rtc/sandbox_rtc.c  |  65 +
  include/rtc.h  |  47 ++
  test/dm/rtc.c  | 118 ++-
  10 files changed, 431 insertions(+), 50 deletions(-)
  create mode 100644 cmd/rtc.c



I just added (locally only) your patches to my U-Boot tree, to integrate
them into mainline, see:

https://github.com/hsdenx/u-boot-i2c/commits/work

test.py run on Azure shows following error:

https://dev.azure.com/hs0298/hs/_build/results?buildId=37=logs=50449d1b-398e-53ae-48fa-6bf338edeb51=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6=679
"""
Unknown command 'rtc' - try 'help'
"""

May you need to add the new RTC command to sandbox config?

Can you look into it?

Also I have fixed some chackpatch warnings ... if you need to post
a new patchset, please check your patches before with checkpatch
script:

u-boot:/scripts/checkpatch.pl

Thanks!

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


[PATCH 3/3] msm_gpio: Add support for Qualcomm IPQ40xx

2020-07-06 Thread Robert Marko
Snapdragon SoCs and IPQ40xx use common TLMM IP,
so existing driver supports IPQ40xx as well.

So lets simply add a compatible for IPQ40xx.

Signed-off-by: Robert Marko 
---
 doc/device-tree-bindings/gpio/gpio-msm.txt | 3 ++-
 drivers/gpio/msm_gpio.c| 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/device-tree-bindings/gpio/gpio-msm.txt 
b/doc/device-tree-bindings/gpio/gpio-msm.txt
index 966ce0af09..70a2c7f0dd 100644
--- a/doc/device-tree-bindings/gpio/gpio-msm.txt
+++ b/doc/device-tree-bindings/gpio/gpio-msm.txt
@@ -1,7 +1,8 @@
 Qualcomm Snapdragon GPIO controller
 
 Required properties:
-- compatible : "qcom,msm8916-pinctrl" or "qcom,apq8016-pinctrl"
+- compatible : "qcom,msm8916-pinctrl", "qcom,apq8016-pinctrl" or
+   "qcom,ipq4019-pinctrl"
 - reg : Physical base address and length of the controller's registers.
This controller is called "Top Level Mode Multiplexing" in
Qualcomm documentation.
diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
index ac5d20c1b9..868291eddb 100644
--- a/drivers/gpio/msm_gpio.c
+++ b/drivers/gpio/msm_gpio.c
@@ -118,6 +118,7 @@ static int msm_gpio_ofdata_to_platdata(struct udevice *dev)
 static const struct udevice_id msm_gpio_ids[] = {
{ .compatible = "qcom,msm8916-pinctrl" },
{ .compatible = "qcom,apq8016-pinctrl" },
+   { .compatible = "qcom,ipq4019-pinctrl" },
{ }
 };
 
-- 
2.26.2



[PATCH 2/3] msm_serial: Read bit rate register value from DT

2020-07-06 Thread Robert Marko
IPQ40xx and currently supported Snapdragon boards don't use the same one
so enable reading it from DT, if no DT property is found default value
is the same as the previous define.

Signed-off-by: Robert Marko 
---
 doc/device-tree-bindings/serial/msm-serial.txt | 4 
 drivers/serial/serial_msm.c| 6 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/device-tree-bindings/serial/msm-serial.txt 
b/doc/device-tree-bindings/serial/msm-serial.txt
index 48b8428aca..dca995798a 100644
--- a/doc/device-tree-bindings/serial/msm-serial.txt
+++ b/doc/device-tree-bindings/serial/msm-serial.txt
@@ -4,3 +4,7 @@ Required properties:
 - compatible: must be "qcom,msm-uartdm-v1.4"
 - reg: start address and size of the registers
 - clock: interface clock (must accept baudrate as a frequency)
+
+Optional properties:
+- bit-rate: Data Mover bit rate register value
+   (If not defined then 0xCC is used as default)
diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index 0cc1aadce4..a32de373d7 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -61,6 +61,7 @@ struct msm_serial_data {
phys_addr_t base;
unsigned chars_cnt; /* number of buffered chars */
uint32_t chars_buf; /* buffered chars */
+   uint32_t clk_bit_rate; /* data mover mode bit rate register value */
 };
 
 static int msm_serial_fetch(struct udevice *dev)
@@ -190,7 +191,7 @@ static int msm_uart_clk_init(struct udevice *dev)
 
 static void uart_dm_init(struct msm_serial_data *priv)
 {
-   writel(UART_DM_CLK_RX_TX_BIT_RATE, priv->base + UARTDM_CSR);
+   writel(priv->clk_bit_rate, priv->base + UARTDM_CSR);
writel(0x0, priv->base + UARTDM_MR1);
writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
@@ -223,6 +224,9 @@ static int msm_serial_ofdata_to_platdata(struct udevice 
*dev)
if (priv->base == FDT_ADDR_T_NONE)
return -EINVAL;
 
+   priv->clk_bit_rate = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), 
+   "bit-rate", 
UART_DM_CLK_RX_TX_BIT_RATE);
+
return 0;
 }
 
-- 
2.26.2



[PATCH 1/3] arm: Add support for Qualcomm IPQ40xx family

2020-07-06 Thread Robert Marko
This introduces initial support for the popular Qualcomm
IPQ40x8 and IPQ40x9 WiSoC series.

IPQ40xx series have 4x Cortex A7 ARM-v7A cores.
Supported are: IPQ4018, IPQ4019, IPQ4028 and IPQ4029.

IPQ40x8 and IPQ40x9 use the same cores, but differ in
addressable RAM size (1GB for IPQ40x9 and 256MB for IPQ40x8)
and supported peripherals (IPQ40x8 lacks RGMII, LCD controller
and EMMC/SDHCI controllers).

IQP4028/IPQ4029 models differ from IPQ4018/IPQ4019 only
by their rated temperatures rates with IPQ402X models being
rated for wider temperature ranges.

Initially this supports:
* Simple clock driver (Only for UART1 now, will be extended)
* Pinctrl driver (Supports UARTX and GPIO now, will be extended)
* GPIOs already supported by msm_gpio driver with updates
* UARTs already supported by serial_msm driver with updates

Further peripherals will come in later patches.

Signed-off-by: Robert Marko 
---
 MAINTAINERS|   7 ++
 arch/arm/Kconfig   |  13 ++
 arch/arm/Makefile  |   1 +
 arch/arm/dts/qcom-ipq4019.dtsi |  79 
 arch/arm/mach-ipq40xx/Kconfig  |  15 +++
 arch/arm/mach-ipq40xx/Makefile |   9 ++
 arch/arm/mach-ipq40xx/clock-ipq4019.c  |  64 ++
 arch/arm/mach-ipq40xx/include/mach/gpio.h  |  10 ++
 arch/arm/mach-ipq40xx/pinctrl-ipq4019.c|  47 +++
 arch/arm/mach-ipq40xx/pinctrl-snapdragon.c | 137 +
 arch/arm/mach-ipq40xx/pinctrl-snapdragon.h |  30 +
 11 files changed, 412 insertions(+)
 create mode 100644 arch/arm/dts/qcom-ipq4019.dtsi
 create mode 100644 arch/arm/mach-ipq40xx/Kconfig
 create mode 100644 arch/arm/mach-ipq40xx/Makefile
 create mode 100644 arch/arm/mach-ipq40xx/clock-ipq4019.c
 create mode 100644 arch/arm/mach-ipq40xx/include/mach/gpio.h
 create mode 100644 arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
 create mode 100644 arch/arm/mach-ipq40xx/pinctrl-snapdragon.c
 create mode 100644 arch/arm/mach-ipq40xx/pinctrl-snapdragon.h

diff --git a/MAINTAINERS b/MAINTAINERS
index db8cecd5e0..e689d1ebeb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -216,6 +216,13 @@ F: arch/arm/cpu/armv8/hisilicon
 F: arch/arm/include/asm/arch-hi6220/
 F: arch/arm/include/asm/arch-hi3660/
 
+ARM IPQ40XX
+M: Robert Marko 
+M: Luka Kovacic 
+M: Luka Perkov 
+S: Maintained
+F: arch/arm/mach-ipq40xx/
+
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
 S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54d65f8488..3868c5c674 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -763,6 +763,17 @@ config ARCH_INTEGRATOR
select PL01X_SERIAL
imply CMD_DM
 
+config ARCH_IPQ40XX
+   bool "Qualcomm IPQ40xx SoCs"
+   select CPU_V7A
+   select DM
+   select DM_GPIO
+   select DM_SERIAL
+   select PINCTRL
+   select CLK
+   select OF_CONTROL
+   imply CMD_DM
+
 config ARCH_KEYSTONE
bool "TI Keystone"
select CMD_POWEROFF
@@ -1772,6 +1783,8 @@ source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
 
+source "arch/arm/mach-ipq40xx/Kconfig"
+
 source "arch/arm/mach-k3/Kconfig"
 
 source "arch/arm/mach-keystone/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 94eb50bf72..a20b82bc8d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -58,6 +58,7 @@ machine-$(CONFIG_ARCH_BCMSTB) += bcmstb
 machine-$(CONFIG_ARCH_DAVINCI) += davinci
 machine-$(CONFIG_ARCH_EXYNOS)  += exynos
 machine-$(CONFIG_ARCH_HIGHBANK)+= highbank
+machine-$(CONFIG_ARCH_IPQ40XX) += ipq40xx
 machine-$(CONFIG_ARCH_K3)  += k3
 machine-$(CONFIG_ARCH_KEYSTONE)+= keystone
 machine-$(CONFIG_ARCH_KIRKWOOD)+= kirkwood
diff --git a/arch/arm/dts/qcom-ipq4019.dtsi b/arch/arm/dts/qcom-ipq4019.dtsi
new file mode 100644
index 00..5f78bc5ab9
--- /dev/null
+++ b/arch/arm/dts/qcom-ipq4019.dtsi
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Sartura Ltd.
+ *
+ * Author: Robert Marko 
+ */
+
+ /dts-v1/;
+
+#include "skeleton.dtsi"
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   model = "Qualcomm Technologies, Inc. IPQ4019";
+   compatible = "qcom,ipq4019";
+
+   aliases {
+   serial0 = _uart1;
+   };
+
+   reserved-memory {
+   #address-cells = <0x1>;
+   #size-cells = <0x1>;
+   ranges;
+
+   smem_mem: smem_region: smem@87e0 {
+   reg = <0x87e0 0x08>;
+   no-map;
+   };
+
+   tz@87e8 {
+   reg = <0x87e8 0x18>;
+   no-map;
+   };
+   };
+
+   soc: soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+  

Seemless Boot Splash on iMX-based boards

2020-07-06 Thread Igor Opaniuk
Hi,

Does anyone have experience in setting up seamless
boot splash on iMX-based platforms?

I'm currently trying to do that on iMX7-based board with
4.9 2.3.x IMX downstream kernel running.

I've backported console deferred takeover patch-series for fbcon [1],
which permits the contents of the framebuffer (initialized before in U-Boot)
to stay in place as is till error message is shown
or boot is finished.

The initial splash is shown in U-Boot(mainline) (mxsfb driver is used
for controller/fb initialization).

Nevertheless, MXSFB controller every time keeps resetting just after
U-Boot->Linux takeover and fb is cleared (I see a black screen) till
login request shows up.

Questions:
1. Did anyone have a chance to work on such setups based on deferred
console "feature"?
2. Does it make sense at all to continue moving towards with this approach
(we initialize graphics core and show boot splash by firmware/bootloader,
then hand over it to Linux).
Taking into account on-going transition to DRM/KMS in the mainline kernel
and that fact that there is no any mainline compatible way to take over
an initialized graphics core, I assume the only generic solution could be
avoiding showing boot logo at all and do that only from the Linux (
Plymouth-based etc.)

Any comments are welcome. Thanks!

[1] https://patchwork.kernel.org/patch/10432641/

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

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk


[PATCH 5/5] arm: dts: k3-am65: Sync CPSW DT node from kernel

2020-07-06 Thread Vignesh Raghavendra
Sync CPSW DT node from kernel and move it out of -u-boot.dtsi file.

Signed-off-by: Vignesh Raghavendra 
---
 arch/arm/dts/k3-am65-mcu.dtsi| 84 
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 54 +
 2 files changed, 85 insertions(+), 53 deletions(-)

diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index d1a9fb5de6..1355685839 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -6,6 +6,20 @@
  */
 
 _mcu {
+   mcu_conf: scm_conf@40f0 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0x40f0 0x0 0x2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x40f0 0x2>;
+
+   phy_gmii_sel: phy@4040 {
+   compatible = "ti,am654-phy-gmii-sel";
+   reg = <0x4040 0x4>;
+   #phy-cells = <1>;
+   };
+   };
+
mcu_uart0: serial@40a0 {
compatible = "ti,am654-uart";
reg = <0x00 0x40a0 0x00 0x100>;
@@ -146,4 +160,74 @@
ti,sci-rm-range-rflow = <0x5>; /* GP RFLOW */
};
};
+
+   mcu_cpsw: ethernet@4600 {
+   compatible = "ti,am654-cpsw-nuss";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x4600 0x0 0x20>;
+   reg-names = "cpsw_nuss";
+   ranges = <0x0 0x0 0x0 0x4600 0x0 0x20>;
+   dma-coherent;
+   clocks = <_clks 5 10>;
+   clock-names = "fck";
+   power-domains = <_pds 5 TI_SCI_PD_EXCLUSIVE>;
+
+   dmas = <_udmap 0xf000>,
+  <_udmap 0xf001>,
+  <_udmap 0xf002>,
+  <_udmap 0xf003>,
+  <_udmap 0xf004>,
+  <_udmap 0xf005>,
+  <_udmap 0xf006>,
+  <_udmap 0xf007>,
+  <_udmap 0x7000>;
+   dma-names = "tx0", "tx1", "tx2", "tx3",
+   "tx4", "tx5", "tx6", "tx7",
+   "rx";
+
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw_port1: port@1 {
+   reg = <1>;
+   ti,mac-only;
+   label = "port1";
+   ti,syscon-efuse = <_conf 0x200>;
+   phys = <_gmii_sel 1>;
+   };
+   };
+
+   davinci_mdio: mdio@f00 {
+   compatible = "ti,cpsw-mdio","ti,davinci_mdio";
+   reg = <0x0 0xf00 0x0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clks 5 10>;
+   clock-names = "fck";
+   bus_freq = <100>;
+   };
+
+   cpts@3d000 {
+   compatible = "ti,am65-cpts";
+   reg = <0x0 0x3d000 0x0 0x400>;
+   clocks = <_cpsw_cpts_mux>;
+   clock-names = "cpts";
+   interrupts-extended = < GIC_SPI 570 
IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "cpts";
+   ti,cpts-ext-ts-inputs = <4>;
+   ti,cpts-periodic-outputs = <2>;
+
+   mcu_cpsw_cpts_mux: refclk-mux {
+   #clock-cells = <0>;
+   clocks = <_clks 118 5>, <_clks 118 11>,
+   <_clks 118 6>, <_clks 118 3>,
+   <_clks 118 8>, <_clks 118 14>,
+   <_clks 120 3>, <_clks 121 3>;
+   assigned-clocks = <_cpsw_cpts_mux>;
+   assigned-clock-parents = <_clks 118 5>;
+   };
+   };
+   };
 };
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 1a40fa12b7..d9ff3ed47b 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -57,59 +57,6 @@
u-boot,dm-spl;
};
};
-
-   mcu_conf: scm_conf@40f0 {
-   compatible = "syscon";
-   reg = <0x0 0x40f0 0x0 0x2>;
-   };
-
-   mcu_cpsw: cpsw_nuss@04600 {
-   compatible = "ti,am654-cpsw-nuss";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   reg = <0x0 0x4600 0x0 0x20>;
-   reg-names = "cpsw_nuss";
-   ranges;
-

[PATCH 4/5] arm: dts: k3-j721e: Sync CPSW DT node from kernel

2020-07-06 Thread Vignesh Raghavendra
Sync CPSW DT node from Kernel and move it out of -u-boot.dtsi file.

Signed-off-by: Vignesh Raghavendra 
---
 .../k3-j721e-common-proc-board-u-boot.dtsi| 74 +--
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 74 +++
 2 files changed, 75 insertions(+), 73 deletions(-)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 6273133303..6e748bfebb 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -31,20 +31,6 @@
u-boot,dm-spl;
};
 
-   mcu_conf: scm_conf@40f0 {
-   compatible = "syscon", "simple-mfd";
-   reg = <0x0 0x40f0 0x0 0x2>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x0 0x0 0x40f0 0x2>;
-
-   phy_sel: cpsw-phy-sel@4040 {
-   compatible = "ti,am654-cpsw-phy-sel";
-   reg = <0x4040 0x4>;
-   reg-names = "gmii-sel";
-   };
-   };
-
mcu_navss {
u-boot,dm-spl;
 
@@ -56,65 +42,6 @@
u-boot,dm-spl;
};
};
-
-   mcu_cpsw: ethernet@04600 {
-   compatible = "ti,j721e-cpsw-nuss";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   reg = <0x0 0x4600 0x0 0x20>;
-   reg-names = "cpsw_nuss";
-   ranges;
-   dma-coherent;
-   clocks = <_clks 18 22>;
-   clock-names = "fck";
-   power-domains = <_pds 18 TI_SCI_PD_EXCLUSIVE>;
-   cpsw-phy-sel = <_sel>;
-
-   dmas = <_udmap 0xf000>,
-  <_udmap 0xf001>,
-  <_udmap 0xf002>,
-  <_udmap 0xf003>,
-  <_udmap 0xf004>,
-  <_udmap 0xf005>,
-  <_udmap 0xf006>,
-  <_udmap 0xf007>,
-  <_udmap 0x7000>;
-   dma-names = "tx0", "tx1", "tx2", "tx3",
-   "tx4", "tx5", "tx6", "tx7",
-   "rx";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   host: host@0 {
-   reg = <0>;
-   ti,label = "host";
-   };
-
-   cpsw_port1: port@1 {
-   reg = <1>;
-   ti,mac-only;
-   ti,label = "port1";
-   ti,syscon-efuse = <_conf 0x200>;
-   };
-   };
-
-   davinci_mdio: mdio {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   bus_freq = <100>;
-   };
-
-   cpts {
-   clocks = <_clks 18 2>;
-   clock-names = "cpts";
-   interrupts-extended = < GIC_SPI 858 
IRQ_TYPE_LEVEL_HIGH>;
-   interrupt-names = "cpts";
-   ti,cpts-ext-ts-inputs = <4>;
-   ti,cpts-periodic-outputs = <2>;
-   };
-   };
 };
 
 _proxy_main {
@@ -224,6 +151,7 @@
reg = <0x0 0x4600 0x0 0x20>,
  <0x0 0x40f00200 0x0 0x2>;
reg-names = "cpsw_nuss", "mac_efuse";
+   /delete-property/ ranges;
 
cpsw-phy-sel@40f04040 {
compatible = "ti,am654-cpsw-phy-sel";
diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi 
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 70d5bcaa72..e6c99ab698 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -35,6 +35,20 @@
};
};
 
+   mcu_conf: syscon@40f0 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0x40f0 0x0 0x2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x40f0 0x2>;
+
+   phy_gmii_sel: phy@4040 {
+   compatible = "ti,am654-phy-gmii-sel";
+   reg = <0x4040 0x4>;
+   #phy-cells = <1>;
+   };
+   };
+
wkup_pmx0: pinmux@4301c000 {
compatible = "pinctrl-single";
/* Proxy 0 addressing */
@@ -242,4 +256,64 @@
ti,sci-rm-range-rflow = <0x00>; /* GP RFLOW */
};
};
+
+   mcu_cpsw: ethernet@4600 {
+   compatible = "ti,j721e-cpsw-nuss";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x4600 0x0 0x20>;
+   reg-names = 

[PATCH 2/5] net: ti: am65-cpsw-nuss: Set ALE default thread enable

2020-07-06 Thread Vignesh Raghavendra
Force default thread to be used for RX as ALE is anyways set to Bypass
mode.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/net/ti/am65-cpsw-nuss.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index e8fe875e70..753a117300 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -61,6 +61,9 @@
 #define AM65_CPSW_ALE_PN_CTL_REG_MODE_FORWARD  0x3
 #define AM65_CPSW_ALE_PN_CTL_REG_MAC_ONLY  BIT(11)
 
+#define AM65_CPSW_ALE_THREADMAPDEF_REG 0x134
+#define AM65_CPSW_ALE_DEFTHREAD_EN BIT(15)
+
 #define AM65_CPSW_MACSL_CTL_REG0x0
 #define AM65_CPSW_MACSL_CTL_REG_IFCTL_ABIT(15)
 #define AM65_CPSW_MACSL_CTL_EXT_EN BIT(18)
@@ -364,6 +367,9 @@ static int am65_cpsw_start(struct udevice *dev)
writel(AM65_CPSW_ALE_PN_CTL_REG_MODE_FORWARD,
   common->ale_base + AM65_CPSW_ALE_PN_CTL_REG(0));
 
+   writel(AM65_CPSW_ALE_DEFTHREAD_EN,
+  common->ale_base + AM65_CPSW_ALE_THREADMAPDEF_REG);
+
/* PORT x configuration */
 
/* Port x Max length register */
-- 
2.27.0



[PATCH 1/5] net: ti: am65-cpsw-nuss: Remove dead code

2020-07-06 Thread Vignesh Raghavendra
MDIO node is not referenced further, therefore drop the dead code.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/net/ti/am65-cpsw-nuss.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 85f3e49c05..e8fe875e70 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -746,13 +746,6 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
goto out;
}
 
-   node = dev_read_subnode(dev, "mdio");
-   if (!ofnode_valid(node)) {
-   dev_err(dev, "can't find mdio\n");
-   ret = -ENOENT;
-   goto out;
-   }
-
cpsw_common->bus_freq =
dev_read_u32_default(dev, "bus_freq",
 AM65_CPSW_MDIO_BUS_FREQ_DEF);
-- 
2.27.0



[PATCH 3/5] net: ti: am65-cpsw-nuss: Update driver to use kernel DT

2020-07-06 Thread Vignesh Raghavendra
Kernel DT has CPSW ports under ethernet-ports subnode. Update the driver
to look for the same.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/net/ti/am65-cpsw-nuss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 753a117300..971bdcdfda 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -686,7 +686,7 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
 
-   ports_np = dev_read_subnode(dev, "ports");
+   ports_np = dev_read_subnode(dev, "ethernet-ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
goto out;
-- 
2.27.0



[PATCH 0/5] TI: AM654/J721e: Sync CPSW DT node from kernel

2020-07-06 Thread Vignesh Raghavendra
Make necessary driver changes to sync DT nodes from kernel.
Depends on [1]

Due to the dependencies, I would like this entire series to be merged via TI
tree.

Tested on AM654 and J721e boards

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


Vignesh Raghavendra (5):
  net: ti: am65-cpsw-nuss: Remove dead code
  net: ti: am65-cpsw-nuss: Set ALE default thread enable
  net: ti: am65-cpsw-nuss: Update driver to use kernel DT
  arm: dts: k3-j721e: Sync CPSW DT node from kernel
  arm: dts: k3-am65: Sync CPSW DT node from kernel

 arch/arm/dts/k3-am65-mcu.dtsi | 84 +++
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  | 54 +---
 .../k3-j721e-common-proc-board-u-boot.dtsi| 74 +---
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 74 
 drivers/net/ti/am65-cpsw-nuss.c   | 15 ++--
 5 files changed, 167 insertions(+), 134 deletions(-)

-- 
2.27.0



[PATCH 2/6] soc: ti: k3-ringacc: Add an API to request pair of rings

2020-07-06 Thread Vignesh Raghavendra
Add new API k3_ringacc_request_rings_pair() to request pair of rings at
once, as in the most case Rings are used with DMA channels which required
to request pair of rings - one to feed DMA with descriptors (TX/RX FDQ) and
one to receive completions (RX/TX CQ). This will allow to simplify Ringacc
API users.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/soc/ti/k3-navss-ringacc.c   | 23 +++
 include/linux/soc/ti/k3-navss-ringacc.h |  4 
 2 files changed, 27 insertions(+)

diff --git a/drivers/soc/ti/k3-navss-ringacc.c 
b/drivers/soc/ti/k3-navss-ringacc.c
index f31ffaf5ae..81de75af20 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -321,6 +321,29 @@ error:
return NULL;
 }
 
+int k3_nav_ringacc_request_rings_pair(struct k3_nav_ringacc *ringacc,
+ int fwd_id, int compl_id,
+ struct k3_nav_ring **fwd_ring,
+ struct k3_nav_ring **compl_ring)
+{
+   int ret = 0;
+
+   if (!fwd_ring || !compl_ring)
+   return -EINVAL;
+
+   *fwd_ring = k3_nav_ringacc_request_ring(ringacc, fwd_id, 0);
+   if (!(*fwd_ring))
+   return -ENODEV;
+
+   *compl_ring = k3_nav_ringacc_request_ring(ringacc, compl_id, 0);
+   if (!(*compl_ring)) {
+   k3_nav_ringacc_ring_free(*fwd_ring);
+   ret = -ENODEV;
+   }
+
+   return ret;
+}
+
 static void k3_ringacc_ring_reset_sci(struct k3_nav_ring *ring)
 {
struct k3_nav_ringacc *ringacc = ring->parent;
diff --git a/include/linux/soc/ti/k3-navss-ringacc.h 
b/include/linux/soc/ti/k3-navss-ringacc.h
index 7b027f8bd4..9176277ff0 100644
--- a/include/linux/soc/ti/k3-navss-ringacc.h
+++ b/include/linux/soc/ti/k3-navss-ringacc.h
@@ -100,6 +100,10 @@ struct k3_nav_ring_cfg {
 struct k3_nav_ring *k3_nav_ringacc_request_ring(struct k3_nav_ringacc *ringacc,
int id, u32 flags);
 
+int k3_nav_ringacc_request_rings_pair(struct k3_nav_ringacc *ringacc,
+ int fwd_id, int compl_id,
+ struct k3_nav_ring **fwd_ring,
+ struct k3_nav_ring **compl_ring);
 /**
  * k3_nav_ringacc_get_dev - get pointer on RA device
  * @ringacc: pointer on RA
-- 
2.27.0



[PATCH 6/6] dma: ti: k3-udma: Switch to k3_ringacc_request_rings_pair

2020-07-06 Thread Vignesh Raghavendra
We only request ring pairs via K3 DMA driver, switch to use the new
k3_ringacc_request_rings_pair() to simplify the code.

As a good side effect, all boot stages now use exposed RING mode which
avoid maintaining proxy mode for 32 bit R5 core.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/dma/ti/k3-udma.c | 52 
 1 file changed, 15 insertions(+), 37 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 77790b66e4..57d9fbfabb 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -32,12 +32,6 @@
 #include "k3-udma-hwdef.h"
 #include "k3-psil-priv.h"
 
-#if BITS_PER_LONG == 64
-#define RINGACC_RING_USE_PROXY (0)
-#else
-#define RINGACC_RING_USE_PROXY (1)
-#endif
-
 #define K3_UDMA_MAX_RFLOWS 1024
 
 struct udma_chan;
@@ -796,21 +790,14 @@ static int udma_alloc_tx_resources(struct udma_chan *uc)
if (ret)
return ret;
 
-   uc->tchan->t_ring = k3_nav_ringacc_request_ring(
-   ud->ringacc, uc->tchan->id,
-   RINGACC_RING_USE_PROXY);
-   if (!uc->tchan->t_ring) {
+   ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, uc->tchan->id, -1,
+   >tchan->t_ring,
+   >tchan->tc_ring);
+   if (ret) {
ret = -EBUSY;
goto err_tx_ring;
}
 
-   uc->tchan->tc_ring = k3_nav_ringacc_request_ring(
-   ud->ringacc, -1, RINGACC_RING_USE_PROXY);
-   if (!uc->tchan->tc_ring) {
-   ret = -EBUSY;
-   goto err_txc_ring;
-   }
-
memset(_cfg, 0, sizeof(ring_cfg));
ring_cfg.size = 16;
ring_cfg.elm_size = K3_NAV_RINGACC_RING_ELSIZE_8;
@@ -827,7 +814,6 @@ static int udma_alloc_tx_resources(struct udma_chan *uc)
 err_ringcfg:
k3_nav_ringacc_ring_free(uc->tchan->tc_ring);
uc->tchan->tc_ring = NULL;
-err_txc_ring:
k3_nav_ringacc_ring_free(uc->tchan->t_ring);
uc->tchan->t_ring = NULL;
 err_tx_ring:
@@ -857,6 +843,7 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
 {
struct k3_nav_ring_cfg ring_cfg;
struct udma_dev *ud = uc->ud;
+   struct udma_rflow *rflow;
int fd_ring_id;
int ret;
 
@@ -876,40 +863,31 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
 
fd_ring_id = ud->tchan_cnt + ud->echan_cnt + uc->rchan->id;
 
-   uc->rflow->fd_ring = k3_nav_ringacc_request_ring(
-   ud->ringacc, fd_ring_id,
-   RINGACC_RING_USE_PROXY);
-   if (!uc->rflow->fd_ring) {
+   rflow = uc->rflow;
+   ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, fd_ring_id, -1,
+   >fd_ring, 
>r_ring);
+   if (ret) {
ret = -EBUSY;
goto err_rx_ring;
}
 
-   uc->rflow->r_ring = k3_nav_ringacc_request_ring(
-   ud->ringacc, -1, RINGACC_RING_USE_PROXY);
-   if (!uc->rflow->r_ring) {
-   ret = -EBUSY;
-   goto err_rxc_ring;
-   }
-
memset(_cfg, 0, sizeof(ring_cfg));
ring_cfg.size = 16;
ring_cfg.elm_size = K3_NAV_RINGACC_RING_ELSIZE_8;
ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_RING;
 
-   ret = k3_nav_ringacc_ring_cfg(uc->rflow->fd_ring, _cfg);
-   ret |= k3_nav_ringacc_ring_cfg(uc->rflow->r_ring, _cfg);
-
+   ret = k3_nav_ringacc_ring_cfg(rflow->fd_ring, _cfg);
+   ret |= k3_nav_ringacc_ring_cfg(rflow->r_ring, _cfg);
if (ret)
goto err_ringcfg;
 
return 0;
 
 err_ringcfg:
-   k3_nav_ringacc_ring_free(uc->rflow->r_ring);
-   uc->rflow->r_ring = NULL;
-err_rxc_ring:
-   k3_nav_ringacc_ring_free(uc->rflow->fd_ring);
-   uc->rflow->fd_ring = NULL;
+   k3_nav_ringacc_ring_free(rflow->r_ring);
+   rflow->r_ring = NULL;
+   k3_nav_ringacc_ring_free(rflow->fd_ring);
+   rflow->fd_ring = NULL;
 err_rx_ring:
udma_put_rflow(uc);
 err_rflow:
-- 
2.27.0



[PATCH 3/6] soc: ti: k3-ringacc: Separate soc specific initialization

2020-07-06 Thread Vignesh Raghavendra
In preparation of adding more K3 SoCs, separate soc specific
initialization add a SoC specific initialization hook.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/soc/ti/k3-navss-ringacc.c | 49 +--
 1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/ti/k3-navss-ringacc.c 
b/drivers/soc/ti/k3-navss-ringacc.c
index 81de75af20..c48e9befe4 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -180,6 +180,10 @@ struct k3_nav_ring {
int proxy_id;
 };
 
+struct k3_nav_ringacc_ops {
+   int (*init)(struct udevice *dev, struct k3_nav_ringacc *ringacc);
+};
+
 /**
  * struct k3_nav_ringacc - Rings accelerator descriptor
  *
@@ -195,6 +199,7 @@ struct k3_nav_ring {
  * @tisci - pointer ti-sci handle
  * @tisci_ring_ops - ti-sci rings ops
  * @tisci_dev_id - ti-sci device id
+ * @ops: SoC specific ringacc operation
  */
 struct k3_nav_ringacc {
struct udevice *dev;
@@ -213,6 +218,8 @@ struct k3_nav_ringacc {
const struct ti_sci_handle *tisci;
const struct ti_sci_rm_ringacc_ops *tisci_ring_ops;
u32  tisci_dev_id;
+
+   const struct k3_nav_ringacc_ops *ops;
 };
 
 static long k3_nav_ringacc_ring_get_fifo_pos(struct k3_nav_ring *ring)
@@ -1008,18 +1015,11 @@ static int k3_nav_ringacc_probe_dt(struct 
k3_nav_ringacc *ringacc)
return 0;
 }
 
-static int k3_nav_ringacc_probe(struct udevice *dev)
+static int k3_nav_ringacc_init(struct udevice *dev, struct k3_nav_ringacc 
*ringacc)
 {
-   struct k3_nav_ringacc *ringacc;
void __iomem *base_fifo, *base_rt;
int ret, i;
 
-   ringacc = dev_get_priv(dev);
-   if (!ringacc)
-   return -ENOMEM;
-
-   ringacc->dev = dev;
-
ret = k3_nav_ringacc_probe_dt(ringacc);
if (ret)
return ret;
@@ -1089,11 +1089,42 @@ static int k3_nav_ringacc_probe(struct udevice *dev)
return 0;
 }
 
+struct ringacc_match_data {
+   struct k3_nav_ringacc_ops ops;
+};
+
+static struct ringacc_match_data k3_nav_ringacc_data = {
+   .ops = {
+   .init = k3_nav_ringacc_init,
+   },
+};
+
 static const struct udevice_id knav_ringacc_ids[] = {
-   { .compatible = "ti,am654-navss-ringacc" },
+   { .compatible = "ti,am654-navss-ringacc", .data = 
(ulong)_nav_ringacc_data, },
{},
 };
 
+static int k3_nav_ringacc_probe(struct udevice *dev)
+{
+   struct k3_nav_ringacc *ringacc;
+   int ret;
+   const struct ringacc_match_data *match_data;
+
+   match_data = (struct ringacc_match_data *)dev_get_driver_data(dev);
+
+   ringacc = dev_get_priv(dev);
+   if (!ringacc)
+   return -ENOMEM;
+
+   ringacc->dev = dev;
+   ringacc->ops = _data->ops;
+   ret = ringacc->ops->init(dev, ringacc);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
 U_BOOT_DRIVER(k3_navss_ringacc) = {
.name   = "k3-navss-ringacc",
.id = UCLASS_MISC,
-- 
2.27.0



[PATCH 5/6] dma: ti: k3-udma: Move RX descriptor ring entries to rflow struct

2020-07-06 Thread Vignesh Raghavendra
In K3 UDMA architecture, RX rings are associated with RX flows rather
than RX channels, therefore move the ring pointers to udma_rflow struct

Signed-off-by: Vignesh Raghavendra 
---
 drivers/dma/ti/k3-udma.c | 52 +---
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 375e904fa9..77790b66e4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -65,8 +65,6 @@ struct udma_rchan {
void __iomem *reg_rt;
 
int id;
-   struct k3_nav_ring *fd_ring; /* Free Descriptor ring */
-   struct k3_nav_ring *r_ring; /* Receive ring*/
 };
 
 #define UDMA_FLAG_PDMA_ACC32   BIT(0)
@@ -86,6 +84,9 @@ struct udma_match_data {
 
 struct udma_rflow {
int id;
+
+   struct k3_nav_ring *fd_ring; /* Free Descriptor ring */
+   struct k3_nav_ring *r_ring; /* Receive ring*/
 };
 
 enum udma_rm_range {
@@ -335,7 +336,7 @@ static int udma_pop_from_ring(struct udma_chan *uc, 
dma_addr_t *addr)
 
switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
-   ring = uc->rchan->r_ring;
+   ring = uc->rflow->r_ring;
break;
case DMA_MEM_TO_DEV:
ring = uc->tchan->tc_ring;
@@ -360,8 +361,8 @@ static void udma_reset_rings(struct udma_chan *uc)
 
switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
-   ring1 = uc->rchan->fd_ring;
-   ring2 = uc->rchan->r_ring;
+   ring1 = uc->rflow->fd_ring;
+   ring2 = uc->rflow->r_ring;
break;
case DMA_MEM_TO_DEV:
ring1 = uc->tchan->t_ring;
@@ -840,12 +841,15 @@ static void udma_free_rx_resources(struct udma_chan *uc)
if (!uc->rchan)
return;
 
-   k3_nav_ringacc_ring_free(uc->rchan->fd_ring);
-   k3_nav_ringacc_ring_free(uc->rchan->r_ring);
-   uc->rchan->fd_ring = NULL;
-   uc->rchan->r_ring = NULL;
+if (uc->rflow) {
+   k3_nav_ringacc_ring_free(uc->rflow->fd_ring);
+   k3_nav_ringacc_ring_free(uc->rflow->r_ring);
+   uc->rflow->fd_ring = NULL;
+   uc->rflow->r_ring = NULL;
+
+   udma_put_rflow(uc);
+   }
 
-   udma_put_rflow(uc);
udma_put_rchan(uc);
 }
 
@@ -872,17 +876,17 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
 
fd_ring_id = ud->tchan_cnt + ud->echan_cnt + uc->rchan->id;
 
-   uc->rchan->fd_ring = k3_nav_ringacc_request_ring(
+   uc->rflow->fd_ring = k3_nav_ringacc_request_ring(
ud->ringacc, fd_ring_id,
RINGACC_RING_USE_PROXY);
-   if (!uc->rchan->fd_ring) {
+   if (!uc->rflow->fd_ring) {
ret = -EBUSY;
goto err_rx_ring;
}
 
-   uc->rchan->r_ring = k3_nav_ringacc_request_ring(
+   uc->rflow->r_ring = k3_nav_ringacc_request_ring(
ud->ringacc, -1, RINGACC_RING_USE_PROXY);
-   if (!uc->rchan->r_ring) {
+   if (!uc->rflow->r_ring) {
ret = -EBUSY;
goto err_rxc_ring;
}
@@ -892,8 +896,8 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
ring_cfg.elm_size = K3_NAV_RINGACC_RING_ELSIZE_8;
ring_cfg.mode = K3_NAV_RINGACC_RING_MODE_RING;
 
-   ret = k3_nav_ringacc_ring_cfg(uc->rchan->fd_ring, _cfg);
-   ret |= k3_nav_ringacc_ring_cfg(uc->rchan->r_ring, _cfg);
+   ret = k3_nav_ringacc_ring_cfg(uc->rflow->fd_ring, _cfg);
+   ret |= k3_nav_ringacc_ring_cfg(uc->rflow->r_ring, _cfg);
 
if (ret)
goto err_ringcfg;
@@ -901,11 +905,11 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
return 0;
 
 err_ringcfg:
-   k3_nav_ringacc_ring_free(uc->rchan->r_ring);
-   uc->rchan->r_ring = NULL;
+   k3_nav_ringacc_ring_free(uc->rflow->r_ring);
+   uc->rflow->r_ring = NULL;
 err_rxc_ring:
-   k3_nav_ringacc_ring_free(uc->rchan->fd_ring);
-   uc->rchan->fd_ring = NULL;
+   k3_nav_ringacc_ring_free(uc->rflow->fd_ring);
+   uc->rflow->fd_ring = NULL;
 err_rx_ring:
udma_put_rflow(uc);
 err_rflow:
@@ -952,8 +956,8 @@ static int udma_alloc_tchan_sci_req(struct udma_chan *uc)
 static int udma_alloc_rchan_sci_req(struct udma_chan *uc)
 {
struct udma_dev *ud = uc->ud;
-   int fd_ring = k3_nav_ringacc_get_ring_id(uc->rchan->fd_ring);
-   int rx_ring = k3_nav_ringacc_get_ring_id(uc->rchan->r_ring);
+   int fd_ring = k3_nav_ringacc_get_ring_id(uc->rflow->fd_ring);
+   int rx_ring = k3_nav_ringacc_get_ring_id(uc->rflow->r_ring);
int tc_ring = k3_nav_ringacc_get_ring_id(uc->tchan->tc_ring);
struct ti_sci_msg_rm_udmap_rx_ch_cfg req = { 0 };
struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
@@ -1715,7 +1719,7 @@ static int udma_receive(struct dma *dma, void **dst, void 
*metadata)
if 

[PATCH 4/6] dma: ti: k3-udma: Introduce udma_chan_config struct

2020-07-06 Thread Vignesh Raghavendra
Encapsulate channel configuration in a separate struct so as to ease
resetting of these fields with memset() and also to increase readability
of the code.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/dma/ti/k3-udma.c | 197 +--
 1 file changed, 108 insertions(+), 89 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 5fc8692e19..375e904fa9 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -137,6 +137,26 @@ struct udma_dev {
u32 ch_count;
 };
 
+struct udma_chan_config {
+   u32 psd_size; /* size of Protocol Specific Data */
+   u32 metadata_size; /* (needs_epib ? 16:0) + psd_size */
+   u32 hdesc_size; /* Size of a packet descriptor in packet mode */
+   int remote_thread_id;
+   u32 atype;
+   u32 src_thread;
+   u32 dst_thread;
+   enum psil_endpoint_type ep_type;
+   enum udma_tp_level channel_tpl; /* Channel Throughput Level */
+
+   enum dma_direction dir;
+
+   unsigned int pkt_mode:1; /* TR or packet */
+   unsigned int needs_epib:1; /* EPIB is needed for the communication or 
not */
+   unsigned int enable_acc32:1;
+   unsigned int enable_burst:1;
+   unsigned int notdpkt:1; /* Suppress sending TDC packet */
+};
+
 struct udma_chan {
struct udma_dev *ud;
char name[20];
@@ -149,20 +169,11 @@ struct udma_chan {
 
u32 bcnt; /* number of bytes completed since the start of the channel */
 
-   bool pkt_mode; /* TR or packet */
-   bool needs_epib; /* EPIB is needed for the communication or not */
-   u32 psd_size; /* size of Protocol Specific Data */
-   u32 metadata_size; /* (needs_epib ? 16:0) + psd_size */
-   int slave_thread_id;
-   u32 src_thread;
-   u32 dst_thread;
-   u32 static_tr_type;
+   struct udma_chan_config config;
 
u32 id;
-   enum dma_direction dir;
 
struct cppi5_host_desc_t *desc_tx;
-   u32 hdesc_size;
bool in_use;
void*desc_rx;
u32 num_rx_bufs;
@@ -288,7 +299,7 @@ static inline bool udma_is_chan_running(struct udma_chan 
*uc)
u32 trt_ctl = 0;
u32 rrt_ctl = 0;
 
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
rrt_ctl = udma_rchanrt_read(uc->rchan, UDMA_RCHAN_RT_CTL_REG);
pr_debug("%s: rrt_ctl: 0x%08x (peer: 0x%08x)\n",
@@ -322,7 +333,7 @@ static int udma_pop_from_ring(struct udma_chan *uc, 
dma_addr_t *addr)
struct k3_nav_ring *ring = NULL;
int ret = -ENOENT;
 
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
ring = uc->rchan->r_ring;
break;
@@ -347,7 +358,7 @@ static void udma_reset_rings(struct udma_chan *uc)
struct k3_nav_ring *ring1 = NULL;
struct k3_nav_ring *ring2 = NULL;
 
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
ring1 = uc->rchan->fd_ring;
ring2 = uc->rchan->r_ring;
@@ -409,7 +420,7 @@ static inline int udma_stop_hard(struct udma_chan *uc)
 {
pr_debug("%s: ENTER (chan%d)\n", __func__, uc->id);
 
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
udma_rchanrt_write(uc->rchan, UDMA_RCHAN_RT_PEER_RT_EN_REG, 0);
udma_rchanrt_write(uc->rchan, UDMA_RCHAN_RT_CTL_REG, 0);
@@ -435,9 +446,8 @@ static int udma_start(struct udma_chan *uc)
if (udma_is_chan_running(uc))
goto out;
 
-   pr_debug("%s: chan:%d dir:%s (static_tr_type: %d)\n",
-__func__, uc->id, udma_get_dir_text(uc->dir),
-uc->static_tr_type);
+   pr_debug("%s: chan:%d dir:%s\n",
+__func__, uc->id, udma_get_dir_text(uc->config.dir));
 
/* Make sure that we clear the teardown bit, if it is set */
udma_stop_hard(uc);
@@ -445,7 +455,7 @@ static int udma_start(struct udma_chan *uc)
/* Reset all counters */
udma_reset_counters(uc);
 
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
udma_rchanrt_write(uc->rchan, UDMA_RCHAN_RT_CTL_REG,
   UDMA_CHAN_RT_CTL_EN);
@@ -547,10 +557,10 @@ static inline void udma_stop_dev2mem(struct udma_chan 
*uc, bool sync)
 static inline int udma_stop(struct udma_chan *uc)
 {
pr_debug("%s: chan:%d dir:%s\n",
-__func__, uc->id, udma_get_dir_text(uc->dir));
+__func__, uc->id, udma_get_dir_text(uc->config.dir));
 
udma_reset_counters(uc);
-   switch (uc->dir) {
+   switch (uc->config.dir) {
case DMA_DEV_TO_MEM:
udma_stop_dev2mem(uc, true);
break;
@@ -851,7 +861,7 @@ static int udma_alloc_rx_resources(struct udma_chan *uc)
return ret;
 
/* For MEM_TO_MEM we don't need 

[PATCH 1/6] soc: ti: k3-ringacc: Move state tracking variables under a struct

2020-07-06 Thread Vignesh Raghavendra
Move the free, occ, windex and rinfex under a struct.
We can use memset to zero them and it will allow a cleaner way to extend
the variables for duplex rings.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/soc/ti/k3-navss-ringacc.c | 89 ---
 1 file changed, 46 insertions(+), 43 deletions(-)

diff --git a/drivers/soc/ti/k3-navss-ringacc.c 
b/drivers/soc/ti/k3-navss-ringacc.c
index ecc4b8b5a0..f31ffaf5ae 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -126,6 +126,22 @@ struct k3_nav_ring_ops {
int (*pop_head)(struct k3_nav_ring *ring, void *elm);
 };
 
+/**
+ * struct k3_nav_ring_state - Internal state tracking structure
+ *
+ * @free: Number of free entries
+ * @occ: Occupancy
+ * @windex: Write index
+ * @rindex: Read index
+ */
+struct k3_nav_ring_state {
+   u32 free;
+   u32 occ;
+   u32 windex;
+   u32 rindex;
+   u32 tdown_complete:1;
+};
+
 /**
  * struct k3_nav_ring - RA Ring descriptor
  *
@@ -139,10 +155,6 @@ struct k3_nav_ring_ops {
  * @elm_size - Size of the ring element
  * @mode - Ring mode
  * @flags - flags
- * @free - Number of free elements
- * @occ - Ring occupancy
- * @windex - Write index (only for @K3_NAV_RINGACC_RING_MODE_RING)
- * @rindex - Read index (only for @K3_NAV_RINGACC_RING_MODE_RING)
  * @ring_id - Ring Id
  * @parent - Pointer on struct @k3_nav_ringacc
  * @use_count - Use count for shared rings
@@ -161,10 +173,7 @@ struct k3_nav_ring {
u32 flags;
 #define KNAV_RING_FLAG_BUSYBIT(1)
 #define K3_NAV_RING_FLAG_SHAREDBIT(2)
-   u32 free;
-   u32 occ;
-   u32 windex;
-   u32 rindex;
+   struct k3_nav_ring_state state;
u32 ring_id;
struct k3_nav_ringacc   *parent;
u32 use_count;
@@ -338,10 +347,7 @@ void k3_nav_ringacc_ring_reset(struct k3_nav_ring *ring)
if (!ring || !(ring->flags & KNAV_RING_FLAG_BUSY))
return;
 
-   ring->occ = 0;
-   ring->free = 0;
-   ring->rindex = 0;
-   ring->windex = 0;
+   memset(>state, 0, sizeof(ring->state));
 
k3_ringacc_ring_reset_sci(ring);
 }
@@ -546,10 +552,7 @@ int k3_nav_ringacc_ring_cfg(struct k3_nav_ring *ring,
ring->size = cfg->size;
ring->elm_size = cfg->elm_size;
ring->mode = cfg->mode;
-   ring->occ = 0;
-   ring->free = 0;
-   ring->rindex = 0;
-   ring->windex = 0;
+   memset(>state, 0, sizeof(ring->state));
 
if (ring->proxy_id != K3_RINGACC_PROXY_NOT_USED)
ring->proxy = ringacc->proxy_target_base +
@@ -625,10 +628,10 @@ u32 k3_nav_ringacc_ring_get_free(struct k3_nav_ring *ring)
if (!ring || !(ring->flags & KNAV_RING_FLAG_BUSY))
return -EINVAL;
 
-   if (!ring->free)
-   ring->free = ring->size - ringacc_readl(>rt->occ);
+   if (!ring->state.free)
+   ring->state.free = ring->size - ringacc_readl(>rt->occ);
 
-   return ring->free;
+   return ring->state.free;
 }
 
 u32 k3_nav_ringacc_ring_get_occ(struct k3_nav_ring *ring)
@@ -694,21 +697,21 @@ static int k3_nav_ringacc_ring_access_proxy(
pr_debug("proxy:memcpy_fromio(x): --> ptr(%p), mode:%d\n",
 ptr, access_mode);
memcpy_fromio(elem, ptr, (4 << ring->elm_size));
-   ring->occ--;
+   ring->state.occ--;
break;
case K3_RINGACC_ACCESS_MODE_PUSH_TAIL:
case K3_RINGACC_ACCESS_MODE_PUSH_HEAD:
pr_debug("proxy:memcpy_toio(x): --> ptr(%p), mode:%d\n",
 ptr, access_mode);
memcpy_toio(ptr, elem, (4 << ring->elm_size));
-   ring->free--;
+   ring->state.free--;
break;
default:
return -EINVAL;
}
 
pr_debug("proxy: free%d occ%d\n",
-ring->free, ring->occ);
+ring->state.free, ring->state.occ);
return 0;
 }
 
@@ -763,21 +766,21 @@ static int k3_nav_ringacc_ring_access_io(
pr_debug("memcpy_fromio(x): --> ptr(%p), mode:%d\n",
 ptr, access_mode);
memcpy_fromio(elem, ptr, (4 << ring->elm_size));
-   ring->occ--;
+   ring->state.occ--;
break;
case K3_RINGACC_ACCESS_MODE_PUSH_TAIL:
case K3_RINGACC_ACCESS_MODE_PUSH_HEAD:
pr_debug("memcpy_toio(x): --> ptr(%p), mode:%d\n",
 ptr, access_mode);
memcpy_toio(ptr, elem, (4 << ring->elm_size));
-   ring->free--;
+   ring->state.free--;
break;
default:
return -EINVAL;
}
 
pr_debug("free%d index%d occ%d index%d\n",
-ring->free, ring->windex, ring->occ, ring->rindex);
+

[PATCH 0/6] TI: AM654/j721e: Ringacc and UDMA updates

2020-07-06 Thread Vignesh Raghavendra
Align Ringacc and UDMA driver with kernel updates.

Depends on [1]

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

Vignesh Raghavendra (6):
  soc: ti: k3-ringacc: Move state tracking variables under a struct
  soc: ti: k3-ringacc: Add an API to request pair of rings
  soc: ti: k3-ringacc: Separate soc specific initialization
  dma: ti: k3-udma: Introduce udma_chan_config struct
  dma: ti: k3-udma: Move RX descriptor ring entries to rflow struct
  dma: ti: k3-udma: Switch to k3_ringacc_request_rings_pair

 drivers/dma/ti/k3-udma.c| 281 
 drivers/soc/ti/k3-navss-ringacc.c   | 161 +-
 include/linux/soc/ti/k3-navss-ringacc.h |   4 +
 3 files changed, 254 insertions(+), 192 deletions(-)

-- 
2.27.0



[PATCH 2/2] configs: migrate CONFIG_SPL_LOAD_FIT_ADDRESS to defconfigs

2020-07-06 Thread peng . fan
From: Peng Fan 

Done with:
./tools/moveconfig.py -S SPL_LOAD_FIT_ADDRESS
./tools/moveconfig.py -S SPL_LOAD_FIT_ADDRESS -H

Signed-off-by: Peng Fan 
---
 configs/am57xx_hs_evm_usb_defconfig| 3 ++-
 configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 +
 configs/dra7xx_evm_defconfig   | 3 ++-
 configs/dra7xx_hs_evm_defconfig| 1 +
 configs/dra7xx_hs_evm_usb_defconfig| 3 ++-
 configs/j721e_evm_a72_defconfig| 3 ++-
 configs/j721e_evm_r5_defconfig | 3 ++-
 configs/j721e_hs_evm_a72_defconfig | 3 ++-
 configs/j721e_hs_evm_r5_defconfig  | 3 ++-
 configs/xilinx_zynq_virt_defconfig | 1 +
 configs/xilinx_zynqmp_virt_defconfig   | 1 +
 include/configs/am57xx_evm.h   | 1 -
 include/configs/ax25-ae350.h   | 6 --
 include/configs/dra7xx_evm.h   | 1 -
 include/configs/j721e_evm.h| 2 --
 include/configs/qemu-riscv.h   | 2 --
 include/configs/sifive-fu540.h | 2 --
 include/configs/xilinx_zynqmp.h| 3 ---
 include/configs/zynq-common.h  | 2 --
 scripts/config_whitelist.txt   | 1 -
 20 files changed, 18 insertions(+), 27 deletions(-)

diff --git a/configs/am57xx_hs_evm_usb_defconfig 
b/configs/am57xx_hs_evm_usb_defconfig
index 3b155cc202..2fa60ac517 100644
--- a/configs/am57xx_hs_evm_usb_defconfig
+++ b/configs/am57xx_hs_evm_usb_defconfig
@@ -6,6 +6,7 @@ CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
 CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0x40306D50
 CONFIG_OMAP54XX=y
 CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
 CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
@@ -17,10 +18,10 @@ CONFIG_ENV_OFFSET_REDUND=0x28
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_ARMV7_LPAE=y
-CONFIG_SPL_TEXT_BASE=0x40306D50
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8020
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTARGS=y
diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig 
b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
index 030d28a5df..0ae610be56 100644
--- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
+++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
@@ -13,6 +13,7 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000
 CONFIG_BOOTDELAY=0
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_OS_BOOT=y
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index e4547d9dcc..393020fbd5 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -4,6 +4,7 @@ CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_SYS_MALLOC_F_LEN=0x18000
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
 CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0x4030
 CONFIG_OMAP54XX=y
 CONFIG_TARGET_DRA7XX_EVM=y
 CONFIG_NR_DRAM_BANKS=2
@@ -12,10 +13,10 @@ CONFIG_ENV_OFFSET_REDUND=0x28
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_ARMV7_LPAE=y
-CONFIG_SPL_TEXT_BASE=0x4030
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8020
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200 
androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index c08bcce903..ee57b7997a 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -20,6 +20,7 @@ CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8020
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTARGS=y
diff --git a/configs/dra7xx_hs_evm_usb_defconfig 
b/configs/dra7xx_hs_evm_usb_defconfig
index 879c2b650b..5ea6e8bf07 100644
--- a/configs/dra7xx_hs_evm_usb_defconfig
+++ b/configs/dra7xx_hs_evm_usb_defconfig
@@ -6,6 +6,7 @@ CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_SYS_MALLOC_F_LEN=0x18000
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
 CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0x40306D50
 CONFIG_OMAP54XX=y
 CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
 CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
@@ -17,11 +18,11 @@ CONFIG_ENV_OFFSET_REDUND=0x28
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_ARMV7_LPAE=y
-CONFIG_SPL_TEXT_BASE=0x40306D50
 

[PATCH 1/2] Kconfig: add SPL_LOAD_FIT_ADDRESS

2020-07-06 Thread peng . fan
From: Peng Fan 

Add SPL_LOAD_FIT_ADDRESS to make user could add it in defconfig

Signed-off-by: Peng Fan 
---
 Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/Kconfig b/Kconfig
index 8f3fba085a..1e63e1d7ba 100644
--- a/Kconfig
+++ b/Kconfig
@@ -474,6 +474,14 @@ config SPL_LOAD_FIT
  particular it can handle selecting from multiple device tree
  and passing the correct one to U-Boot.
 
+config SPL_LOAD_FIT_ADDRESS
+   hex "load address of fit image"
+   depends on SPL_LOAD_FIT
+   default 0x0
+   help
+ Specify the load address of the fit image that will be loaded
+ by SPL.
+
 config SPL_LOAD_FIT_APPLY_OVERLAY
bool "Enable SPL applying DT overlays from FIT"
depends on SPL_LOAD_FIT
-- 
2.16.4



Re: [PATCH v3 04/14] i2c: add nexell driver

2020-07-06 Thread Stefan Bosch

Hello Heiko,

thank you for your proposals. I'll make the appropriate changes.

Regards
Stefan

Am 03.07.20 um 08:03 schrieb Heiko Schocher:

Hello Stefan,

Am 29.06.2020 um 19:46 schrieb Stefan Bosch:

Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- i2c/nx_i2c.c: Some adaptions mainly because of changes in
   "struct udevice".
- several Bugfixes in nx_i2c.c.
- the driver has been for s5p6818 only. Code extended appropriately
   in order s5p4418 is also working.
- "probe_chip" added.
- pinctrl-driver/dt is used instead of configuring the i2c I/O-pins
   in the i2c-driver.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
   possible (and similar).
- livetree API (dev_read_...) is used instead of fdt one (fdt...).

Signed-off-by: Stefan Bosch 


Reviewed-by: Heiko Schocher 

Nitpick only ...

[...]

diff --git a/drivers/i2c/nx_i2c.c b/drivers/i2c/nx_i2c.c
new file mode 100644
index 000..cefc774
--- /dev/null
+++ b/drivers/i2c/nx_i2c.c
@@ -0,0 +1,624 @@

[...]

+static uint i2c_set_clk(struct nx_i2c_bus *bus, uint enb)
+{
+    struct clk *clk;
+    char name[50];
+
+    sprintf(name, "%s.%d", DEV_NAME_I2C, bus->bus_num);
+    clk = clk_get((const char *)name);
+    if (!clk) {
+    debug("%s(): clk_get(%s) error!\n",
+  __func__, (const char *)name);
+    return -EINVAL;
+    }
+
+    if (enb) {
+    clk_disable(clk);
+    clk_enable(clk);
+    } else {
+    clk_disable(clk);
+    }


You can do here:

 clk_disable(clk);
 if (enb)
     clk_enable(clk);


+
+    return 0;
+}
+
+#ifdef CONFIG_ARCH_S5P6818
+/* Set SDA line delay, not available at S5P4418 */
+static int nx_i2c_set_sda_delay(struct nx_i2c_bus *bus)
+{
+    struct nx_i2c_regs *i2c = bus->regs;
+    uint pclk = 0;
+    uint t_pclk = 0;
+    uint delay = 0;
+
+    /* get input clock of the I2C-controller */
+    pclk = i2c_get_clkrate(bus);
+
+    if (bus->sda_delay) {
+    /* t_pclk = period time of one pclk [ns] */
+    t_pclk = DIV_ROUND_UP(1000, pclk / 100);
+    /* delay = number of pclks required for sda_delay [ns] */
+    delay = DIV_ROUND_UP(bus->sda_delay, t_pclk);
+    /* delay = register value (step of 5 clocks) */
+    delay = DIV_ROUND_UP(delay, 5);
+    /* max. possible register value = 3 */
+    if (delay > 3) {


May you use defines here?


+    delay = 3;
+    debug("%s(): sda-delay des.: %dns, sat. to max.: %dns 
(granularity: %dns)\n",

+  __func__, bus->sda_delay, t_pclk * delay * 5,
+  t_pclk * 5);
+    } else {
+    debug("%s(): sda-delay des.: %dns, act.: %dns 
(granularity: %dns)\n",

+  __func__, bus->sda_delay, t_pclk * delay * 5,
+  t_pclk * 5);
+    }
+
+    delay |= I2CLC_FILTER;
+    } else {
+    delay = 0;
+    debug("%s(): sda-delay = 0\n", __func__);
+    }
+
+    delay &= 0x7;
+    writel(delay, >iiclc);
+
+    return 0;
+}
+#endif
+
+static int nx_i2c_set_bus_speed(struct udevice *dev, uint speed)
+{
+    struct nx_i2c_bus *bus = dev_get_priv(dev);
+    struct nx_i2c_regs *i2c = bus->regs;
+    unsigned long pclk, pres = 16, div;
+
+    if (i2c_set_clk(bus, 1))
+    return -EINVAL;
+
+    /* get input clock of the I2C-controller */
+    pclk = i2c_get_clkrate(bus);
+
+    /* calculate prescaler and divisor values */
+    if ((pclk / pres / (16 + 1)) > speed)
+    /* set prescaler to 256 */
+    pres = 256;
+
+    div = 0;
+    /* actual divider = div + 1 */
+    while ((pclk / pres / (div + 1)) > speed)
+    div++;
+
+    if (div > 0xF) {
+    debug("%s(): pres==%ld, div==0x%lx is saturated to 0xF !)\n",
+  __func__, pres, div);
+    div = 0xF;
+    } else {
+    debug("%s(): pres==%ld, div==0x%lx)\n", __func__, pres, div);
+    }
+
+    /* set prescaler, divisor according to pclk, also set ACKGEN, IRQ */
+    writel((div & 0x0F) | ((pres == 256) ? 0x40 : 0), >iiccon);


Ok, I am really nitpicking now ... can you use defines here instead
this magic values?

[...]

Thanks!

bye,
Heiko


Re: [PATCH 3/3] cmd: adtimg: Refactor usage style

2020-07-06 Thread Eugeniu Rosca
Hi Patrick,

On Fri, Jul 03, 2020 at 04:40:28PM +, Patrick DELAUNAY wrote:
> > From: U-Boot  On Behalf Of Eugeniu Rosca
> > Sent: samedi 11 janvier 2020 00:30
> > 
> > Hi Tom,
> > 
> > On Fri, Jan 10, 2020 at 04:50:52PM -0500, Tom Rini wrote:
> > > On Tue, Dec 24, 2019 at 05:51:08PM +0100, Eugeniu Rosca wrote:
> > > > Signed-off-by: Eugeniu Rosca 
> > > > Reviewed-by: Sam Protsenko 
> > >
> > > Applied to u-boot/master, thanks!
> > 
> > Thanks for merging!
> 
> For the planned update of the command adtimg:
> 
> > [6] Soon-to-be-provided "by id|rev" add-on functionality adtimg get dt 
> > --id= --rev= [avar [svar [ivar]]]
> >  - Get DT address/size/index by id|rev fields
> 
> Do you have plan to upstream this code or it is available  in downstream ?
> 
> Because stm32mp1 platform needs this feature

Good to hear that the features are used by people out there.

> We code in downstream [1] based on v2020.01 almost the same command
> but based on the old usage = [2]

After a quick look, this is certainly missing the latest vanilla
patches, so is out of sync with mainline.

>   dtimg getindex[varname] 
>   - get index of FDT in the image, by board identifier and revision
> : image address in RAM, in hex
> : board identifier
> : board revision (0 if not used)
> [varname]: name of variable where to store index of FDT
> 
> So if you have nothing ready, I can update my code with your proposed 
> parameters.
> 
> [1] 
> https://github.com/STMicroelectronics/u-boot/blob/v2020.01-stm32mp/cmd/dtimg.c
> [2] 
> https://github.com/STMicroelectronics/u-boot/commit/21b57a166e73a8457d4caea6a1d37f1f3fda3d45

You would need to rebase these commits first.
A quicker route is to just take my patches available below:
 https://github.com/erosca/u-boot/commits/master_adtimg_id_rev

These have been extensively tested and are now running in
development/production systems for months w/o any issues.

Do you have any comments concerning the two commits below?
 
https://github.com/erosca/u-boot/commit/936a08faaf3f485527e2d1cfb8a53dcf44e17b3a
 
https://github.com/erosca/u-boot/commit/e37d090dabb6973762376adca5ae10292ca3ba3d

-- 
Best regards,
Eugeniu Rosca


Re: [PATCH v3 07/15] dt-bindings: memory: ns3: update GIC LPI address

2020-07-06 Thread Rayagonda Kokatanur
On Mon, Jul 6, 2020 at 10:56 AM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Sun, 5 Jul 2020 at 12:21, Rayagonda Kokatanur 
>  wrote:
> >
> > Hi Simon,
> >
> > On Sun, Jul 5, 2020 at 12:20 AM Rayagonda Kokatanur
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sat, Jul 4, 2020 at 1:20 PM Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
> > > > >
> > > > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
> > > > >  wrote:
> > > > > >
> > > > > > Update NS3 GIC LPI address.
> > > > > >
> > > > > > Signed-off-by: Rayagonda Kokatanur 
> > > > > > 
> > > > > > ---
> > > > > >  include/dt-bindings/memory/bcm-ns3-mc.h | 3 +++
> > > > > >  1 file changed, 3 insertions(+)
> > > > > >
> > > > >
> > > > > Reviewed-by: Simon Glass 
> > > > >
> > > > > Lower case hex
> > > > >
> > > > > Can these be in the device tree and use a driver, like syscon maybe?
> >
> > I will use dt and syscon to get the LPI base address.
> > This will require change in arch/arm/lib/gic-v3-its.c driver.
> >
> > Hope this is okay. Please let me know.
>
> Yes of course, change whatever you like.

Thank you Simon.

>
> Regards,
> SImon


  1   2   >