date:20210914

[PATCH 3/3] efi_loader: add DeployedMode and AuditMode variable measurement

2021-09-14 Thread Masahisa Kojima

This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client PFP Spec.

Signed-off-by: Masahisa Kojima 
---
 lib/efi_loader/efi_tcg2.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 35810615ed..427d6e22b1 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1828,6 +1829,50 @@ out:
return ret;
 }
 
+/**
+ * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
+ *
+ * @dev:   TPM device
+ *
+ * Return: status code
+ */
+static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
+{
+   u8 deployed_mode;
+   u8 audit_mode;
+   efi_uintn_t size;
+   efi_status_t ret;
+   u32 pcr_index;
+
+   size = sizeof(deployed_mode);
+   ret = efi_get_variable_int(L"DeployedMode", _global_variable_guid,
+  NULL, , _mode, NULL);
+   if (ret != EFI_SUCCESS)
+   return ret;
+
+   pcr_index = (deployed_mode ? 1 : 7);
+
+   ret = tcg2_measure_variable(dev, pcr_index,
+   EV_EFI_VARIABLE_DRIVER_CONFIG,
+   L"DeployedMode",
+   _global_variable_guid,
+   size, _mode);
+
+   size = sizeof(audit_mode);
+   ret = efi_get_variable_int(L"AuditMode", _global_variable_guid,
+  NULL, , _mode, NULL);
+   if (ret != EFI_SUCCESS)
+   return ret;
+
+   ret = tcg2_measure_variable(dev, pcr_index,
+   EV_EFI_VARIABLE_DRIVER_CONFIG,
+   L"AuditMode",
+   _global_variable_guid,
+   size, _mode);
+
+   return ret;
+}
+
 /**
  * tcg2_measure_secure_boot_variable() - measure secure boot variables
  *
@@ -1891,6 +1936,8 @@ static efi_status_t 
tcg2_measure_secure_boot_variable(struct udevice *dev)
free(data);
}
 
+   ret = tcg2_measure_deployed_audit_mode(dev);
+
 error:
return ret;
 }
-- 
2.17.1

[PATCH 1/3] efi_loader: add SMBIOS table measurement

2021-09-14 Thread Masahisa Kojima

TCG PC Client spec requires to measure the SMBIOS
table that contain static configuration information
(e.g. Platform Manufacturer Enterprise Number assigned by IANA,
platform model number, Vendor and Device IDs for each SMBIOS table).

The device and environment dependent information such as
serial number is cleared to zero or space character for
the measurement.

This commit also fixes the following compiler warning:

lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
  const struct smbios_header *header = (struct smbios_header 
*)entry->struct_table_address;

Signed-off-by: Masahisa Kojima 
---
 include/efi_loader.h  |   2 +
 include/efi_tcg2.h|  15 
 include/smbios.h  |  13 
 lib/efi_loader/Kconfig|   1 +
 lib/efi_loader/efi_boottime.c |   2 +
 lib/efi_loader/efi_smbios.c   |   2 -
 lib/efi_loader/efi_tcg2.c |  84 ++
 lib/smbios-parser.c   | 127 +-
 8 files changed, 243 insertions(+), 3 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index c440962fe5..13f0c24058 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -308,6 +308,8 @@ extern const efi_guid_t efi_guid_capsule_report;
 extern const efi_guid_t efi_guid_firmware_management_protocol;
 /* GUID for the ESRT */
 extern const efi_guid_t efi_esrt_guid;
+/* GUID of the SMBIOS table */
+extern const efi_guid_t smbios_guid;
 
 extern char __efi_runtime_start[], __efi_runtime_stop[];
 extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 5a1a36212e..da33f8a1d0 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -215,6 +215,21 @@ struct efi_tcg2_uefi_variable_data {
u8 variable_data[1];
 };
 
+/**
+ * struct tdUEFI_HANDOFF_TABLE_POINTERS2 - event log structure of SMBOIS tables
+ * @table_description_size:size of table description
+ * @table_description: table description
+ * @number_of_tables:  number of uefi configuration table
+ * @table_entry:   uefi configuration table entry
+ */
+#define SMBIOS_HANDOFF_TABLE_DESC  "SmbiosTable"
+struct smbios_handoff_table_pointers2 {
+   u8 table_description_size;
+   u8 table_description[sizeof(SMBIOS_HANDOFF_TABLE_DESC)];
+   u64 number_of_tables;
+   struct efi_configuration_table table_entry[1];
+} __packed;
+
 struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
   struct 
efi_tcg2_boot_service_capability *capability);
diff --git a/include/smbios.h b/include/smbios.h
index aa6b6f3849..0c22c0c489 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -292,4 +292,17 @@ int smbios_update_version(const char *version);
  */
 int smbios_update_version_full(void *smbios_tab, const char *version);
 
+/**
+ * smbios_prepare_measurement() - Update smbios table for the measurement
+ *
+ * TCG specification requires to measure static configuration information.
+ * This function clear the device dependent parameters such as
+ * serial number for the measurement.
+ *
+ * @entry: pointer to a struct smbios_entry
+ * @header: pointer to a struct smbios_header
+ */
+void smbios_prepare_measurement(const struct smbios_entry *entry,
+   struct smbios_header *header);
+
 #endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index dacc3b5881..ac1a281a36 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -327,6 +327,7 @@ config EFI_TCG2_PROTOCOL
select SHA384
select SHA512
select HASH
+   select SMBIOS_PARSER
help
  Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
  of the platform.
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f0283b539e..701e2212c8 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -86,6 +86,8 @@ const efi_guid_t efi_guid_event_group_reset_system =
 /* GUIDs of the Load File and Load File2 protocols */
 const efi_guid_t efi_guid_load_file_protocol = EFI_LOAD_FILE_PROTOCOL_GUID;
 const efi_guid_t efi_guid_load_file2_protocol = EFI_LOAD_FILE2_PROTOCOL_GUID;
+/* GUID of the SMBIOS table */
+const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
 static efi_status_t EFIAPI efi_disconnect_controller(
efi_handle_t controller_handle,
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 2eb4cb1c1a..fc0b23397c 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -13,8 +13,6 @@
 #include 
 #include 
 
-static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
-
 /*
  * Install the SMBIOS table as a configuration table.
  *
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index

[PATCH 2/3] efi_loader: add UEFI GPT measurement

2021-09-14 Thread Masahisa Kojima

This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client PFP Spec.

Signed-off-by: Masahisa Kojima 
---
 include/blk.h |   3 +
 include/efi_loader.h  |   2 +-
 include/efi_tcg2.h|  12 +++
 lib/efi_loader/efi_boottime.c |   2 +-
 lib/efi_loader/efi_tcg2.c | 175 +-
 5 files changed, 191 insertions(+), 3 deletions(-)

diff --git a/include/blk.h b/include/blk.h
index 19bab081c2..f0cc7ca1a2 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -45,6 +45,9 @@ enum if_type {
 #define BLK_PRD_SIZE   20
 #define BLK_REV_SIZE   8
 
+#define PART_FORMAT_PCAT   0x1
+#define PART_FORMAT_GPT0x2
+
 /*
  * Identifies the partition table type (ie. MBR vs GPT GUID) signature
  */
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 13f0c24058..dbcc296e01 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
 void efi_variables_boot_exit_notify(void);
 efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
 /* Measure efi application invocation */
-efi_status_t efi_tcg2_measure_efi_app_invocation(void);
+efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj 
*handle);
 /* Measure efi application exit */
 efi_status_t efi_tcg2_measure_efi_app_exit(void);
 /* Called by bootefi to initialize root node */
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index da33f8a1d0..33257fa96b 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -230,6 +230,18 @@ struct smbios_handoff_table_pointers2 {
struct efi_configuration_table table_entry[1];
 } __packed;
 
+/**
+ * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
+ * @uefi_partition_header: gpt partition header
+ * @number_of_partitions:  the number of partition
+ * @partitions:partition entries
+ */
+struct efi_gpt_data {
+   gpt_header uefi_partition_header;
+   u64 number_of_partitions;
+   gpt_entry partitions[];
+} __packed;
+
 struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
   struct 
efi_tcg2_boot_service_capability *capability);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 701e2212c8..bf5661e1ee 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3003,7 +3003,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
 
if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) {
-   ret = efi_tcg2_measure_efi_app_invocation();
+   ret = efi_tcg2_measure_efi_app_invocation(image_obj);
if (ret != EFI_SUCCESS) {
log_warning("tcg2 measurement fails(0x%lx)\n",
ret);
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 7f47998a55..35810615ed 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1525,12 +1525,181 @@ static void *search_smbios_table(void)
return NULL;
 }
 
+/**
+ * search_gpt_dp_node() - search gpt device path node
+ *
+ * @device_path:   device path
+ *
+ * Return: pointer to the gpt device path node
+ */
+static struct
+efi_device_path *search_gpt_dp_node(struct efi_device_path *device_path)
+{
+   struct efi_device_path *dp = device_path;
+
+   while (dp) {
+   if (dp->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+   dp->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+   struct efi_device_path_hard_drive_path *hd_dp =
+   (struct efi_device_path_hard_drive_path *)dp;
+
+   if (hd_dp->partmap_type == PART_FORMAT_GPT &&
+   hd_dp->signature_type == SIG_TYPE_GUID)
+   return dp;
+   }
+   dp = efi_dp_next(dp);
+   }
+
+   return NULL;
+}
+
+/**
+ * tcg2_measure_gpt_table() - measure gpt table
+ *
+ * @dev:   TPM device
+ * @loaded_image:  handle to the loaded image
+ *
+ * Return: status code
+ */
+static efi_status_t
+tcg2_measure_gpt_data(struct udevice *dev,
+ struct efi_loaded_image_obj *loaded_image)
+{
+   efi_status_t ret;
+   efi_handle_t handle;
+   struct efi_handler *dp_handler;
+   struct efi_device_path *orig_device_path;
+   struct efi_device_path *device_path;
+   struct efi_device_path *dp;
+   struct efi_block_io *block_io;
+   struct efi_gpt_data *event = NULL;
+   efi_guid_t null_guid = NULL_GUID;
+   gpt_header *orig_gpt_h = NULL;
+   gpt_entry *orig_gpt_e = NULL;
+   gpt_header *gpt_h = NULL;
+   gpt_entry

[PATCH 0/3] Enhance Measured Boot

2021-09-14 Thread Masahisa Kojima

This patch series add the following measurement mandated in the
TCG PC Client PFP Specification.
 - SMBIOS tables
 - GPT disk partition topology
 - AuditMode and Deployed mode

Masahisa Kojima (3):
  efi_loader: add SMBIOS table measurement
  efi_loader: add UEFI GPT measurement
  efi_loader: add DeployedMode and AuditMode variable measurement

 include/blk.h |   3 +
 include/efi_loader.h  |   4 +-
 include/efi_tcg2.h|  27 +++
 include/smbios.h  |  13 ++
 lib/efi_loader/Kconfig|   1 +
 lib/efi_loader/efi_boottime.c |   4 +-
 lib/efi_loader/efi_smbios.c   |   2 -
 lib/efi_loader/efi_tcg2.c | 306 +-
 lib/smbios-parser.c   | 127 +-
 9 files changed, 481 insertions(+), 6 deletions(-)

-- 
2.17.1

Re: [PATCH 4/9] i2c: ocores: Fix -Wint-to-pointer-cast warning

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 11:15:11AM +0800, Bin Meng wrote:
> The following warning is seen in ocores_i2c.c in a 32-bit build:
> 
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
> 
> Change to use dev_read_addr_ptr().
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/i2c/ocores_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

2021-09-14 Thread Heiko Schocher

Hi Marek,

On 15.09.21 01:06, Marek Vasut wrote:
> The flash->mtd.name used to be nor%d before, now it is the type of the
> SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
> of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
> the later is ambiguous if there are multiple flashes of the same type in
> the system and breaks existing environments.
> 
> This does no longer get recognized when running 'mtdparts' for example:
> CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
> 
> Fix this by setting the correct mtd.name to nor%d.
> 
> Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
> enabled")
> Signed-off-by: Marek Vasut 
> Cc: Heiko Schocher 
> Cc: Jagan Teki 
> Cc: Marek Behún 
> Cc: Miquel Raynal 
> Cc: Pali Rohár 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Priyanka Jain 
> Cc: Simon Glass 
> ---
>  drivers/mtd/spi/sf_mtd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Seem fixes the same problem as Patrick already posted here:

https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/

I find your approach cleaner, so:

Acked-by: Heiko Schocher 

@Patrick: Could you test this patch please?

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 3/9] gpio: sifive: Fix -Wint-to-pointer-cast warning

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 11:15:10AM +0800, Bin Meng wrote:
> dev_read_addr() returns a value of type fdt_addr_t which is a 64-bit
> address and plat->base is a pointer. In a 32-bit build, this causes the
> following warning seen when building sifive-gpio.c:
> 
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
> 
> Change to use dev_read_addr_ptr().
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/gpio/sifive-gpio.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Reviewed-by: Leo Yu-Chi Liang

[PATCH] mtd: spi-nor-core: Add fixups for s25fs512s

2021-09-14 Thread tkuw584924

From: Takahiro Kuwano 

The current S25FS512S support has following issues that need to be fixed.

  - Non-uniform sectors by factory default. The setting needs to be
checked and assign erase hook as needed.
  - Page size is wrongly advertised in SFDP.
  - READ_1_1_2 (3Bh/3Ch), READ_1_1_4 (6Bh/6Ch), and PP_1_1_4 (32h/34h)
are not supported.
  - Bank Address Register (BAR) is not supported.

In addtion, volatile version of Quad Enable is used for safety.

For future use, the fixups is assigned for S25FS-S family.

The datasheet can be found in the following link.
https://www.cypress.com/file/216376/download

Tested on Xilinx Zynq-7000 FPGA board.

Signed-off-by: Takahiro Kuwano 
---
 drivers/mtd/spi/spi-nor-core.c | 101 +
 1 file changed, 101 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a..5e847ebf6a 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3097,6 +3097,102 @@ static int spi_nor_setup(struct spi_nor *nor, const 
struct flash_info *info,
 }
 
 #ifdef CONFIG_SPI_FLASH_SPANSION
+static int s25fs_s_quad_enable(struct spi_nor *nor)
+{
+   return spansion_quad_enable_volatile(nor, 0, 8);
+}
+
+static int s25fs_s_erase_non_uniform(struct spi_nor *nor, loff_t addr)
+{
+   /* Support 8 x 4KB sectors at bottom */
+   return spansion_erase_non_uniform(nor, addr, SPINOR_OP_BE_4K_4B, 0,
+ SZ_32K);
+}
+
+static int s25fs_s_setup(struct spi_nor *nor, const struct flash_info *info,
+const struct spi_nor_flash_parameter *params)
+{
+   int ret;
+   u8 cfr3v;
+
+#ifdef CONFIG_SPI_FLASH_BAR
+   return -ENOTSUPP; /* Bank Address Register is not supported */
+#endif
+   /*
+* Read CR3V to check if uniform sector is selected. If not, assign an
+* erase hook that supports non-uniform erase.
+*/
+   ret = spansion_read_any_reg(nor, SPINOR_REG_ADDR_CFR3V, 8, );
+   if (ret)
+   return ret;
+   if (!(cfr3v & CFR3V_UNHYSA))
+   nor->erase = s25fs_s_erase_non_uniform;
+
+   return spi_nor_default_setup(nor, info, params);
+}
+
+static void s25fs_s_default_init(struct spi_nor *nor)
+{
+   nor->setup = s25fs_s_setup;
+}
+
+static int s25fs_s_post_bfpt_fixup(struct spi_nor *nor,
+  const struct sfdp_parameter_header *header,
+  const struct sfdp_bfpt *bfpt,
+  struct spi_nor_flash_parameter *params)
+{
+   int ret;
+   u8 cfr3v;
+
+   /* The erase size is set to 4K from BFPT, but it's wrong. Fix it. */
+   nor->erase_opcode = SPINOR_OP_SE;
+   nor->mtd.erasesize = nor->info->sector_size;
+
+   if (params->size > SZ_16M) {
+   ret = nor->write_reg(nor, SPINOR_OP_EN4B, NULL, 0);
+   if (ret)
+   return ret;
+   nor->addr_width = 4;
+   } else {
+   nor->addr_width = 3;
+   }
+
+   /*
+* The page_size is set to 512B from BFPT, but it actually depends on
+* the configuration register. Look up the CFR3V and determine the
+* page_size.
+*/
+   ret = spansion_read_any_reg(nor, SPINOR_REG_ADDR_CFR3V, 8, );
+   if (ret)
+   return ret;
+
+   if (cfr3v & CFR3V_PGMBUF)
+   params->page_size = 512;
+   else
+   params->page_size = 256;
+
+   return 0;
+}
+
+static void s25fs_s_post_sfdp_fixup(struct spi_nor *nor,
+   struct spi_nor_flash_parameter *params)
+{
+   /* READ_1_1_2 is not supported */
+   params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
+   /* READ_1_1_4 is not supported */
+   params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
+   /* PP_1_1_4 is not supported */
+   params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
+   /* Use volatile register to enable quad */
+   params->quad_enable = s25fs_s_quad_enable;
+}
+
+static struct spi_nor_fixups s25fs_s_fixups = {
+   .default_init = s25fs_s_default_init,
+   .post_bfpt = s25fs_s_post_bfpt_fixup,
+   .post_sfdp = s25fs_s_post_sfdp_fixup,
+};
+
 static int s25hx_t_mdp_ready(struct spi_nor *nor)
 {
u32 addr;
@@ -3644,6 +3740,11 @@ void spi_nor_set_fixups(struct spi_nor *nor)
break;
}
}
+
+   /* For FS-S (family ID = 0x81)  */
+   if (JEDEC_MFR(nor->info) == SNOR_MFR_SPANSION &&
+   nor->info->id[5] == 0x81)
+   nor->fixups = _s_fixups;
 #endif
 
 #ifdef CONFIG_SPI_FLASH_S28HS512T
-- 
2.25.1

Re: [PATCH 2/9] clk: sifive: Fix -Wint-to-pointer-cast warning

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 11:15:09AM +0800, Bin Meng wrote:
> dev_read_addr() returns a value of type fdt_addr_t which is a 64-bit
> address and pd->va is a pointer. In a 32-bit build, this causes the
> following warning seen when building sifive-prci.c:
> 
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
> 
> Change to use dev_read_addr_ptr().
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/clk/sifive/sifive-prci.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Leo Yu-Chi Liang

Re: [PATCH 1/9] cache: sifive: Fix -Wint-to-pointer-cast warning

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 11:15:08AM +0800, Bin Meng wrote:
> The following warning is seen in cache-sifive-ccache.c in a 32-bit build:
>
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
>
> Fix by casting it with uintptr_t.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/cache/cache-sifive-ccache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH 1/5] kgdb: Remove unused serial related options

2021-09-14 Thread Tom Rini

On Wed, Sep 15, 2021 at 10:07:23AM +0800, Peng Fan (OSS) wrote:

> Just wonder anyone using kgdb in U-Boot?
> And sharing the same uart with normal output?

The KGDB code is also likely broken and could be removed in a follow-up
patch.  It is however in Kconfig currently.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 3/3] imx8qm_mek: Increase CONFIG_SYS_BOOTM_LEN to 64MB

2021-09-14 Thread Peng Fan (OSS)





On 2021/8/30 19:11, Oleksandr Suvorov wrote:

On Sun, Aug 29, 2021 at 10:55 PM Marek Vasut  wrote:


On 8/29/21 9:39 PM, Oleksandr Suvorov wrote:

The BSP platform LmP supports the board NXP iMX8QM MEK. The
kernel size in LmP exceeds 32Mb. Increase the maximum size
of an uncompressed kernel to fix the following error:
  Uncompressing Kernel Image
  Error: inflate() returned -5
  Image too large: increase CONFIG_SYS_BOOTM_LEN
  Must RESET board to recover



Maybe we should increase the default for arm64 instead ? 8 MiB is too small.


I completely agree if NXP doesn't have objections.
@Peng Fan Do you mind?



I am ok with increase ARM64 default bootm len.

Regards,
Peng.

Re: [PATCH] arm: dts: imx8mp: Delete default clocks for clock controller node

2021-09-14 Thread Peng Fan (OSS)





On 2021/8/17 14:32, Ye Li wrote:

Since SPL has initialized clocks for bus and core. We don't need to
set the default clocks for clock controller node.

Signed-off-by: Ye Li 
---
  arch/arm/dts/imx8mp-u-boot.dtsi | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index d61346d..a6ede2e 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -18,6 +18,9 @@
   {
u-boot,dm-spl;
u-boot,dm-pre-reloc;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
  };
  
  _32k {




For a release fix, this is ok.
Acked-by: Peng Fan 

But for distro boot, we need think Linux Kernel will
use the device tree exported by U-Boot. Removing
this property may cause issue.

I think other vendors may has similar issue
that U-Boot modify dtb and corrupt distribution
kernel booting.

Thanks,
Peng.

Re: [PATCH] arm: imx8mp-evk: CLOCK Enable SPI and QOS clock

2021-09-14 Thread Peng Fan (OSS)


Please resend with plain text.

On 2021/9/8 13:26, Arendt, Steffen wrote:

Enable clocks for SPI and QOS (Ethernet) for the imx8mp SoC


diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index c77500bcce..1ab5587e4e 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -116,6 +116,30 @@ static const char *imx8mp_i2c6_sels[] = 
{"clock-osc-24m", "sys_pll1_160m", "sys_
  "sys_pll3_out", 
"audio_pll1_out", "video_pll1_out",
  "audio_pll2_out", 
"sys_pll1_133m", };


+#if CONFIG_IS_ENABLED(DM_SPI)
+static const char *imx8mp_ecspi1_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
+  "sys_pll2_250m", 
"audio_pll2_out", };

+
+static const char *imx8mp_ecspi2_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
+  "sys_pll2_250m", 
"audio_pll2_out", };

+
+static const char *imx8mp_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
+  "sys_pll2_250m", 
"audio_pll2_out", };

+#endif
+
+#if CONFIG_IS_ENABLED(DWC_ETH_QOS)
+static const char *imx8mp_enet_qos_sels[] = {"osc_24m", 
"sys_pll2_125m", "sys_pll2_50m",
+    "sys_pll2_100m", 
"sys_pll1_160m", "audio_pll1_out",
+    "video_pll1_out", 
"clk_ext4", };

+
+static const char *imx8mp_enet_qos_timer_sels[] = {"osc_24m", 
"sys_pll2_100m", "audio_pll1_out",
+  "clk_ext1", 
"clk_ext2", "clk_ext3",
+  "clk_ext4", 
"video_pll1_out", };

+#endif
+
  static const char *imx8mp_usdhc1_sels[] = {"clock-osc-24m", 
"sys_pll1_400m", "sys_pll1_800m",
    "sys_pll2_500m", 
"sys_pll3_out", "sys_pll1_266m",
    "audio_pll2_out", 
"sys_pll1_100m", };

@@ -397,6 +421,28 @@ static int imx8mp_clk_probe(struct udevice *dev)

     clk_dm(IMX8MP_CLK_USDHC3_ROOT, imx_clk_gate4("usdhc3_root_clk", 
"usdhc3", base + 0x45e0, 0));


+#if CONFIG_IS_ENABLED(DM_SPI)
+   clk_dm(IMX8MP_CLK_ECSPI1,
+  imx8m_clk_composite("ecspi1", imx8mp_ecspi1_sels, base + 
0xb280));

+   clk_dm(IMX8MP_CLK_ECSPI2,
+  imx8m_clk_composite("ecspi2", imx8mp_ecspi2_sels, base + 
0xb300));

+   clk_dm(IMX8MP_CLK_ECSPI3,
+  imx8m_clk_composite("ecspi3", imx8mp_ecspi3_sels, base + 
0xc180));

+   clk_dm(IMX8MP_CLK_ECSPI1_ROOT,
+  imx_clk_gate4("ecspi1_root_clk", "ecspi1", base + 0x4070, 
0));

+   clk_dm(IMX8MP_CLK_ECSPI2_ROOT,
+  imx_clk_gate4("ecspi2_root_clk", "ecspi2", base + 0x4080, 
0));

+   clk_dm(IMX8MP_CLK_ECSPI3_ROOT,
+  imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 
0));

+#endif
+
+#if CONFIG_IS_ENABLED(DWC_ETH_QOS)
+   clk_dm(IMX8MP_CLK_ENET_QOS,
+   imx8m_clk_composite("enet_qos", 
imx8mp_enet_qos_sels, base + 0xa880));

+   clk_dm(IMX8MP_CLK_ENET_QOS_TIMER,
+   imx8m_clk_composite("enet_qos_timer", 
imx8mp_enet_qos_timer_sels, base + 0xa900));

+#endif
+
     return 0;
  }

SensoPart

Re: [PATCH] arm: imx: imx8mq: add support to get values for more clocks

2021-09-14 Thread Peng Fan (OSS)





On 2021/9/9 20:59, Heiko Thiery wrote:

Return the root clock values for MXC_CSPI_CLK, MXC_I2C_CLK,
MXC_UART_CLK and MXC_QSPI_CLK.

At least for the I2C clock the missing support leads to a wrong
configured I2C frequency. The expected value is 100kHz but the resulting
value is about 1MHz.

Signed-off-by: Heiko Thiery 
---

More information and measurements about the wrong configure I2C
frequency can be found here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2021-September%2F460176.htmldata=04%7C01%7Cpeng.fan%40nxp.com%7C3fd04432d40141466d4208d97391b927%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637667891977601595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2BYXFWRvw3LG%2FhqKU0uxxrvCXiqfKD3qL80DISvG6PQA%3Dreserved=0


  arch/arm/mach-imx/imx8m/clock_imx8mq.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c 
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
index 60e2218a3c..9db62b944e 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
@@ -359,10 +359,18 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
clock_get_target_val(IPG_CLK_ROOT, );
val = val & 0x3;
return get_root_clk(AHB_CLK_ROOT) / (val + 1);
+   case MXC_CSPI_CLK:
+   return get_root_clk(ECSPI1_CLK_ROOT);
case MXC_ESDHC_CLK:
return get_root_clk(USDHC1_CLK_ROOT);
case MXC_ESDHC2_CLK:
return get_root_clk(USDHC2_CLK_ROOT);
+   case MXC_I2C_CLK:
+   return get_root_clk(I2C1_CLK_ROOT);
+   case MXC_UART_CLK:
+   return get_root_clk(UART1_CLK_ROOT);
+   case MXC_QSPI_CLK:
+   return get_root_clk(QSPI_CLK_ROOT);
default:
return get_root_clk(clk);
}



Reviewed-by: Peng Fan

Re: imx: imx8mq: mxc_get_clock for MXC_I2C_CLK is missing

2021-09-14 Thread Peng Fan (OSS)





On 2021/9/8 21:08, Heiko Thiery wrote:

Hi Peng,

I faced an issue with the I2C bus speed in SPL for the imx8mq. I
figured out that the bus frequency is set to about 1MHz. While digging
into that I found that the clk ID for the I2C is not returned for the
imx8mq correctly.

Can you confirm that this is missing here.


You are right! Thanks for spotting this.

Regards,
Peng.



This is what I added and now it looks better.

diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
index 60e2218a3c..9e45ffd66b 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
@@ -363,6 +363,12 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
 return get_root_clk(USDHC1_CLK_ROOT);
 case MXC_ESDHC2_CLK:
 return get_root_clk(USDHC2_CLK_ROOT);
+   case MXC_I2C_CLK:
+   return get_root_clk(I2C1_CLK_ROOT);
+   case MXC_UART_CLK:
+   return get_root_clk(UART1_CLK_ROOT);
+   case MXC_QSPI_CLK:
+   return get_root_clk(QSPI_CLK_ROOT);
 default:
 return get_root_clk(clk);
 }

Re: [PATCH] imx8mn_beacon: Fix booting hang and switch to binman

2021-09-14 Thread Peng Fan (OSS)





On 2021/9/11 4:19, Adam Ford wrote:

Somewhere along the line, the board stopped being able to boot.
Rather than just fixing the issue, let's fix the issue and migrate
to binman to eliminate a warning when using custom imx tools for
generating the binary.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi 
b/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
index bbc64a2819..69fd69c8d0 100644
--- a/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
@@ -4,6 +4,10 @@
   */
  
  / {

+   binman: binman {
+   multiple-images;
+   };
+
wdt-reboot {
compatible = "wdt-reboot";
wdt = <>;
@@ -40,6 +44,9 @@
   {
u-boot,dm-spl;
u-boot,dm-pre-reloc;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
  };
  
   {

@@ -99,6 +106,10 @@
u-boot,off-on-delay-us = <2>;
  };
  
+ {

+   u-boot,dm-spl;
+};
+
   {
u-boot,dm-spl;
sd-uhs-sdr104;
@@ -120,3 +131,122 @@
   {
u-boot,dm-spl;
  };
+
+ {
+u-boot-spl-ddr {
+   filename = "u-boot-spl-ddr.bin";
+   pad-byte = <0xff>;
+   align-size = <4>;
+   align = <4>;
+
+   u-boot-spl {
+   align-end = <4>;
+   };
+
+   blob_1: blob-ext@1 {
+   filename = "lpddr4_pmu_train_1d_imem.bin";
+   size = <0x8000>;
+   };
+
+   blob_2: blob-ext@2 {
+   filename = "lpddr4_pmu_train_1d_dmem.bin";
+   size = <0x4000>;
+   };
+
+   blob_3: blob-ext@3 {
+   filename = "lpddr4_pmu_train_2d_imem.bin";
+   size = <0x8000>;
+   };
+
+   blob_4: blob-ext@4 {
+   filename = "lpddr4_pmu_train_2d_dmem.bin";
+   size = <0x4000>;
+   };
+   };
+
+
+   spl {
+   filename = "spl.bin";
+
+   mkimage {
+   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
0x912000";
+
+   blob {
+   filename = "u-boot-spl-ddr.bin";
+   };
+   };
+   };
+
+   itb {
+   filename = "u-boot.itb";
+
+   fit {
+   description = "Configuration to load ATF before U-Boot";
+   #address-cells = <1>;
+   fit,external-offset = ;
+
+   images {
+   uboot {
+   description = "U-Boot (64-bit)";
+   type = "standalone";
+   arch = "arm64";
+   compression = "none";
+   load = ;
+
+   uboot_blob: blob-ext {
+   filename = "u-boot-nodtb.bin";
+   };
+   };
+
+   atf {
+   description = "ARM Trusted Firmware";
+   type = "firmware";
+   arch = "arm64";
+   compression = "none";
+   load = <0x96>;
+   entry = <0x96>;
+
+   atf_blob: blob-ext {
+   filename = "bl31.bin";
+   };
+   };
+
+   fdt {
+   description = "NAME";
+   type = "flat_dt";
+   compression = "none";
+
+   uboot_fdt_blob: blob-ext {
+   filename = "u-boot.dtb";
+   };
+   };
+   };
+
+   configurations {
+   default = "conf";
+
+   conf {
+   description = "NAME";
+   firmware = "uboot";
+   loadables = "atf";
+   fdt = "fdt";
+   };
+   };
+   };
+   };
+
+   imx-boot {
+   filename = "flash.bin";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+

Re: [PATCH] cmd: mmc: Support mmc hwpartition user enh start -

2021-09-14 Thread Peng Fan (OSS)




On 2021/9/12 5:14, Marek Vasut wrote:

Add option to extend the hardware partition to the maximum size by
using the '-' dash sign instead of $cnt parameter. This is useful
in case we want to switch the entire eMMC user area into pSLC mode,
especially in case the device may be populated with different size
eMMCs. With this change, we do not have to calculate the number of
blocks of the user area manually.

To switch the pSLC mode for user area, use e.g. the following.
WARNING: This is a one-time irreversible change.
=> mmc hwpartition user enh 0 - wrrel on complete

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  cmd/mmc.c | 32 
  1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index c67ad762422..b6bb951347d 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -560,7 +560,32 @@ static int do_mmc_list(struct cmd_tbl *cmdtp, int flag,
  }
  
  #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)

-static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
+static void parse_hwpart_user_enh_size(struct mmc *mmc,
+  struct mmc_hwpart_conf *pconf,
+  char *argv)
+{
+   int ret;
+
+   pconf->user.enh_size = 0;
+
+   if (!strcmp(argv, "-"))   { /* The rest of eMMC */
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+   ret = mmc_send_ext_csd(mmc, ext_csd);
+   if (ret)
+   return;
+   pconf->user.enh_size =
+   ((ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+2] << 16) +


space before/after "+"


+   (ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+1] << 8) +


Ditto


+   ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT]) * 1024 *


Hardcode HC_WP_GRP_SIZE to 1024?
Per spec:

(GP_SIZE_MULT_X_2 * 2^16 + GP_SIZE_MULT_X_1 * 2^8 + GP_SIZE_MULT_X_0 * 
2^0) * HC_WP_GRP_SIZE * HC_ERASE_GRP_SIZE * 512kBytes


Thanks,
Peng.



+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
+   pconf->user.enh_size -= pconf->user.enh_start;
+   } else {
+   pconf->user.enh_size = dectoul(argv, NULL);
+   }
+}
+
+static int parse_hwpart_user(struct mmc *mmc, struct mmc_hwpart_conf *pconf,
 int argc, char *const argv[])
  {
int i = 0;
@@ -573,8 +598,7 @@ static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
return -1;
pconf->user.enh_start =
dectoul(argv[i + 1], NULL);
-   pconf->user.enh_size =
-   dectoul(argv[i + 2], NULL);
+   parse_hwpart_user_enh_size(mmc, pconf, argv[i + 2]);
i += 3;
} else if (!strcmp(argv[i], "wrrel")) {
if (i + 1 >= argc)
@@ -646,7 +670,7 @@ static int do_mmc_hwpartition(struct cmd_tbl *cmdtp, int 
flag,
while (i < argc) {
if (!strcmp(argv[i], "user")) {
i++;
-   r = parse_hwpart_user(, argc-i, [i]);
+   r = parse_hwpart_user(mmc, , argc-i, [i]);
if (r < 0)
return CMD_RET_USAGE;
i += r;

Re: [PATCH] apalis/colibri_imx6: move setting bootcmd to defconfig

2021-09-14 Thread Peng Fan (OSS)





On 2021/9/13 3:39, Oleksandr Suvorov wrote:

Move setting the default boot command to the
apalis/colibri_imx6_defconfig. It allows replacing the command
without code modification.

Signed-off-by: Oleksandr Suvorov 
---

  configs/apalis_imx6_defconfig  | 1 +
  configs/colibri_imx6_defconfig | 1 +
  include/configs/apalis_imx6.h  | 4 
  include/configs/colibri_imx6.h | 4 
  4 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index a0e85ba23a4..a2e0f8e3936 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y
  CONFIG_FIT=y
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
  CONFIG_BOOTDELAY=1
+CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
serial,vidconsole;setenv stdin serial,usbkbd"
  # CONFIG_DISPLAY_BOARDINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 47b1cfb1917..bee4e7edd63 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y
  CONFIG_FIT=y
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
  CONFIG_BOOTDELAY=1
+CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
serial,vidconsole;setenv stdin serial,usbkbd"
  # CONFIG_DISPLAY_BOARDINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 12de0105c6c..ade479cb943 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -133,10 +133,6 @@
  #endif
  #define CONFIG_EXTRA_ENV_SETTINGS \
BOOTENV \
-   "bootcmd=run distro_bootcmd ; " \
-   "usb start ; " \
-   "setenv stdout serial,vidconsole; " \
-   "setenv stdin serial,usbkbd\0" \
"boot_file=zImage\0" \
"console=ttymxc0\0" \
"defargs=enable_wait_mode=off vmalloc=400M\0" \
diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h
index 804a144a03e..f91d6b49ea8 100644
--- a/include/configs/colibri_imx6.h
+++ b/include/configs/colibri_imx6.h
@@ -115,10 +115,6 @@
  #define FDT_FILE "imx6dl-colibri-eval-v3.dtb"
  #define CONFIG_EXTRA_ENV_SETTINGS \
BOOTENV \
-   "bootcmd=run distro_bootcmd; " \
-   "usb start ; " \
-   "setenv stdout serial,vidconsole; " \
-   "setenv stdin serial,usbkbd\0" \
"boot_file=zImage\0" \
"console=ttymxc0\0" \
"defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \



Reviewed-by: Peng Fan

Re: [PATCH 1/5] kgdb: Remove unused serial related options

2021-09-14 Thread Peng Fan (OSS)


Just wonder anyone using kgdb in U-Boot?
And sharing the same uart with normal output?

Thanks,
Peng

On 2021/9/14 5:24, Tom Rini wrote:

We have a few CONFIG options for KGDB that are not referenced, remove
them.

Signed-off-by: Tom Rini 
---
  README  | 5 -
  include/configs/MPC8349EMDS.h   | 4 
  include/configs/MPC8349EMDS_SDRAM.h | 4 
  include/configs/MPC837XERDB.h   | 4 
  include/configs/MPC8540ADS.h| 4 
  include/configs/MPC8548CDS.h| 4 
  include/configs/MPC8560ADS.h| 4 
  include/configs/P1010RDB.h  | 4 
  include/configs/P2041RDB.h  | 4 
  include/configs/T102xRDB.h  | 4 
  include/configs/T104xRDB.h  | 4 
  include/configs/T208xQDS.h  | 5 -
  include/configs/T208xRDB.h  | 5 -
  include/configs/T4240RDB.h  | 4 
  include/configs/UCP1020.h   | 5 -
  include/configs/corenet_ds.h| 4 
  include/configs/p1_p2_rdb_pc.h  | 4 
  include/configs/pxa-common.h| 7 ---
  include/configs/socrates.h  | 4 
  include/configs/x86-common.h| 4 
  20 files changed, 87 deletions(-)

diff --git a/README b/README
index 6df06c79bc83..e9a6df4cd1de 100644
--- a/README
+++ b/README
@@ -648,11 +648,6 @@ The following options need to be configured:
time on others. This setting #define's the initial
value of the "loads_echo" environment variable.
  
-- Kgdb Serial Baudrate: (if CONFIG_CMD_KGDB is defined)

-   CONFIG_KGDB_BAUDRATE
-   Select one of the baudrates listed in
-   CONFIG_SYS_BAUDRATE_TABLE, see below.
-
  - Removal of commands
If no commands are needed to boot, you can disable
CONFIG_CMDLINE to remove them. In this case, the command line
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index 2f1fc6a6a2b9..d96d3ce6967b 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -255,10 +255,6 @@
  #define CONFIG_PCI_INDIRECT_BRIDGE
  #endif
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/MPC8349EMDS_SDRAM.h 
b/include/configs/MPC8349EMDS_SDRAM.h
index d6a151d20ce6..0f8db35ae90e 100644
--- a/include/configs/MPC8349EMDS_SDRAM.h
+++ b/include/configs/MPC8349EMDS_SDRAM.h
@@ -312,10 +312,6 @@
  #define CONFIG_PCI_INDIRECT_BRIDGE
  #endif
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index 0e2e034dcd9b..ce810e5f2cbe 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -323,10 +323,6 @@
  #define CONFIG_SYS_BOOTMAPSZ  (256 << 20) /* Initial Memory map for Linux */
  #define CONFIG_SYS_BOOTM_LEN  (64 << 20)/* Increase max gunzip size */
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/MPC8540ADS.h b/include/configs/MPC8540ADS.h
index 66cf2053f980..b73a7c9ac955 100644
--- a/include/configs/MPC8540ADS.h
+++ b/include/configs/MPC8540ADS.h
@@ -289,10 +289,6 @@
  #define CONFIG_SYS_BOOTMAPSZ  (64 << 20)/* Initial Memory map for 
Linux*/
  #define CONFIG_SYS_BOOTM_LEN  (64 << 20)/* Increase max gunzip size */
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h
index f7d05ffa89a1..5c54bad4964f 100644
--- a/include/configs/MPC8548CDS.h
+++ b/include/configs/MPC8548CDS.h
@@ -415,10 +415,6 @@ extern unsigned long get_clock_freq(void);
  #define CONFIG_SYS_BOOTMAPSZ  (64 << 20)/* Initial Memory map for 
Linux*/
  #define CONFIG_SYS_BOOTM_LEN  (64 << 20)/* Increase max gunzip size */
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/MPC8560ADS.h b/include/configs/MPC8560ADS.h
index 224314366439..23ac9f8e6ece 100644
--- a/include/configs/MPC8560ADS.h
+++ b/include/configs/MPC8560ADS.h
@@ -279,10 +279,6 @@
  #define CONFIG_SYS_BOOTMAPSZ  (64 << 20)/* Initial Memory map for 
Linux*/
  #define CONFIG_SYS_BOOTM_LEN  (64 << 20)/* Increase max gunzip size */
  
-#if defined(CONFIG_CMD_KGDB)

-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
  /*
   * Environment Configuration
   */
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index

boot using encrypted

2021-09-14 Thread Cedrick Kukela

Hello Guys,
I am in the process of configuring u-boot so that I can boot an encrypted 
zImage. I was looking for a guide or documentation to make sure my 
understanding of what I need to do is correct. Could anyone point me in the 
correct direction?

Thank you
Cedrick

S25HS512 not functional with u-boot 2021.10.rc3

2021-09-14 Thread Harkirat Virk

I have a custom board using imx6ul and Spansion S25HS512T Flash. On the current 
version of u-boot (2021.10.rc3) and I am guessing even previous ones the 
Spansion flash is not functioning

=> sf probe
drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0 'spi@21e'
drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
drivers/spi/spi-uclass.c:282-spi_find_chip_select() fsl_qspi spi@21e: 
spi_find_chip_select: plat=9ef2bf60, cs=0
drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0 'spi@21e'
drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
drivers/spi/spi-uclass.c:282-spi_find_chip_select() fsl_qspi spi@21e: 
spi_find_chip_select: plat=9ef2bf60, cs=0
drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0 'iomuxc@20e'
drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
drivers/pinctrl/pinctrl-uclass.c:300-pinctrl_select_state_simple() 
jedec_spi_nor s25hs512t@0: set_state_simple op missing
drivers/spi/fsl_qspi.c:464-fsl_qspi_prepare_lut() fsl_qspi spi@21e: CMD[9f] 
lutval[0:1c00049f1:0 2:0 3:0]
drivers/spi/spi-uclass.c:438-  spi_get_bus_and_cs() spi_get_bus_and_cs: Error 
path, created=0, device 's25hs512t@0'
Failed to initialize SPI flash at 0:0 (error -524)

Result is the same with different modes and frequencies, bus and CS are correct

My DTSI is 

 {
pinctrl-names = "default";
pinctrl-0 = <_qspi>;
status = "okay";

flash0: s25hs512t@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,s25hs512t", "jedec,spi-nor";
spi-max-frequency = <4000>;
spi-rx-bus-width = <4>;
spi-tx-bus-width = <4>;
reg = <0>;
spi-mode = <0>;
m25p,fast-read;
status = "okay";
/* some partition information*/
};
};

Defconfig has

CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_FSL_QSPI=y
CONFIG_MTD=y
CONFIG_DM_MTD=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SF_DEFAULT_MODE=0
CONFIG_SF_DEFAULT_SPEED=4000
CONFIG_SPI_FLASH_SPANSION=y

 DM Tree

=> dm tree
 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver   root_driver
 thermal   0  [   ]   imx_thermal   |-- imx_thermal
 simple_bus0  [ + ]   simple_bus|-- soc
 simple_bus1  [ + ]   simple_bus|   |-- aips-bus@200
 simple_bus2  [ + ]   simple_bus|   |   |-- spba-bus@200
 serial0  [ + ]   serial_mxc|   |   |   `-- serial@202
 gpio  0  [   ]   gpio_mxc  |   |   |-- gpio@209c000
 gpio  1  [   ]   gpio_mxc  |   |   |-- gpio@20a
 gpio  2  [   ]   gpio_mxc  |   |   |-- gpio@20a4000
 gpio  3  [   ]   gpio_mxc  |   |   |-- gpio@20a8000
 gpio  4  [   ]   gpio_mxc  |   |   |-- gpio@20ac000
 simple_bus3  [   ]   simple_bus|   |   |-- anatop@20c8000
 simple_bus4  [   ]   simple_bus|   |   |-- snvs@20cc000
 pinctrl   0  [ + ]   fsl_imx6q_iomuxc  |   |   `-- iomuxc@20e
 pinconfig 0  [   ]   pinconfig |   |   |-- i2c1grp
 pinconfig 1  [   ]   pinconfig |   |   |-- i2c2grp
 pinconfig 2  [ + ]   pinconfig |   |   |-- qspigrp
 pinconfig 3  [   ]   pinconfig |   |   |-- ledsgrp
 pinconfig 4  [ + ]   pinconfig |   |   |-- uart1grp
 pinconfig 5  [ + ]   pinconfig |   |   |-- usdhc2grp
 pinconfig 6  [   ]   pinconfig |   |   `-- wdoggrp
 simple_bus5  [ + ]   simple_bus|   `-- aips-bus@210
 usb   0  [   ]   ehci_mx6  |   |-- usb@2184000
 mmc   0  [ + ]   fsl_esdhc |   |-- usdhc@2194000
 blk   0  [   ]   mmc_blk   |   |   `-- 
us...@2194000.blk
 i2c   0  [   ]   i2c_mxc   |   |-- i2c@21a
 i2c   1  [   ]   i2c_mxc   |   |-- i2c@21a4000
 spi   0  [ + ]   fsl_qspi  |   `-- spi@21e
 spi_flash 0  [   ]   jedec_spi_nor |   `-- s25hs512t@0
 regulator 0  [   ]   regulator_fixed   |-- regulator-sd2-vmmc
 led   0  [   ]   gpio_led  `-- leds
 led   1  [   ]   gpio_led  |-- green
 led   2  [   ]   gpio_led  |-- red
 led   3  [   ]   gpio_led  `— amber

I am unable to identify source of error returning -524 or why SPI Flash 
initialisation fails

[PATCH 4/4] doc: boards: amlogic: update for Radxa Zero

2021-09-14 Thread Christian Hewitt

Add documentation bits for the Radxa Zero

Signed-off-by: Christian Hewitt 
---
 doc/board/amlogic/index.rst  |  3 +-
 doc/board/amlogic/radxa-zero.rst | 74 
 2 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 doc/board/amlogic/radxa-zero.rst

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 2913ab281a..e2ab600f7f 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -17,7 +17,7 @@ This matrix concerns the actual source code version.
 
+===+===+=+==+++=+==+
 | Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
 |  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
-|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
+|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  | Radxa Zero | GT-King/Pro | Odroid-C4|
 |  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
 |   |   | |  | 
   || | BananaPi-M5  |
 
+---+---+-+--+++-+--+
@@ -96,6 +96,7 @@ Board Documentation
p201
p212
q200
+   radxa-zero
s400
sei510
sei610
diff --git a/doc/board/amlogic/radxa-zero.rst b/doc/board/amlogic/radxa-zero.rst
new file mode 100644
index 00..423403f3c7
--- /dev/null
+++ b/doc/board/amlogic/radxa-zero.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Radxa Zero
+=
+
+Radxa Zero is a small form factor SBC based on the Amlogic S905Y2
+chipset that ships in a number of RAM/eMMC configurations:
+
+Boards with 512MB/1GB LPDDR4 RAM have no eMMC storage and BCM43436
+wireless (2.4GHz b/g/n) while 2GB/4GB boards have 8/16/32/64/128GB
+eMMC storage and BCM4345 wireless (2.4/5GHz a/b/g/n/ac).
+
+- Amlogic S905Y2 quad-core Cortex-A53
+- Mali G31-MP2 GPU
+- HDMI 2.1 output (micro)
+- 1x USB 2.0 port - Type C (OTG)
+- 1x USB 3.0 port - Type C (Host)
+- 1x micro SD Card slot
+- 40 Pin GPIO header
+
+Schematics are available on the manufacturer website:
+
+https://dl.radxa.com/zero/docs/hw/RADAX_ZERO_V13_SCH_20210309.pdf
+
+U-Boot compilation
+--
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=aarch64-none-elf-
+$ make radxa-zero_defconfig
+$ make
+
+Image creation
+--
+
+Amlogic does not provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+git trees published by the board vendor:
+
+.. code-block:: bash
+
+$ git clone -b radxa-zero-v2021.07 https://github.com/radxa/u-boot.git
+$ git clone https://github.com/radxa/fip.git
+
+$ sudo apt-get install -y gcc-aarch64-linux-gnu device-tree-compiler 
libncurses5 libncurses5-dev
+$ sudo apt-get install -y bc python dosfstools flex build-essential 
libssl-dev mtools
+
+$ wget 
https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf.tar.xz
+$ sudo tar xvf gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf.tar.xz -C /opt
+
+$ export 
CROSS_COMPILE=/opt/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/aarch64-none-elf-
+$ export ARCH=arm
+$ cd u-boot
+$ make radxa-zero_defconfig
+$ make
+
+$ cp u-boot.bin ../fip/radxa-zero/bl33.bin
+$ cd ../fip/radxa-zero
+$ make
+
+This will generate:
+
+.. code-block:: bash
+
+$ u-boot.bin u-boot.bin.sd.bin u-boot.bin.usb.bl2 u-boot.bin.usb.tpl
+
+Then write the image to SD with:
+
+.. code-block:: bash
+
+$ DEV=/dev/your_sd_device
+$ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 
seek=1
+$ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
-- 
2.17.1

[PATCH 3/4] boards: amlogic: add Radxa Zero defconfig

2021-09-14 Thread Christian Hewitt

Add a defconfig for the Radxa Zero SBC, using an Amlogic S905Y2 chip.

Signed-off-by: Christian Hewitt 
---
 configs/radxa-zero_defconfig | 70 
 1 file changed, 70 insertions(+)
 create mode 100644 configs/radxa-zero_defconfig

diff --git a/configs/radxa-zero_defconfig b/configs/radxa-zero_defconfig
new file mode 100644
index 00..acd13f1c6b
--- /dev/null
+++ b/configs/radxa-zero_defconfig
@@ -0,0 +1,70 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-g12a-radxa-zero"
+CONFIG_MESON_G12A=y
+CONFIG_DEBUG_UART_BASE=0xff803000
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" radxa-zero"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET_RANDOM_ETHADDR is not set
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+# CONFIG_PHY_REALTEK is not set
+# CONFIG_DM_ETH is not set
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+# CONFIG_ETH_DESIGNWARE_MESON8B is not set
+CONFIG_MDIO_MUX_MESON_G12A=y
+CONFIG_MESON_G12A_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_EE_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_G12A=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.17.1

[PATCH 2/4] ARM: dts: add support for Radxa Zero

2021-09-14 Thread Christian Hewitt

Import the initial dts queued for Linux 5.16.y

Signed-off-by: Christian Hewitt 
---
 arch/arm/dts/Makefile |   1 +
 .../arm/dts/meson-g12a-radxa-zero-u-boot.dtsi |   7 +
 arch/arm/dts/meson-g12a-radxa-zero.dts| 405 ++
 3 files changed, 413 insertions(+)
 create mode 100644 arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-g12a-radxa-zero.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 461448c579..2ab55f7e2d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -174,6 +174,7 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
+   meson-g12a-radxa-zero.dtb \
meson-g12a-sei510.dtb \
meson-g12a-u200.dtb \
meson-g12b-a311d-khadas-vim3.dtb \
diff --git a/arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi 
b/arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi
new file mode 100644
index 00..236f2468dc
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-g12-common-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-g12a-radxa-zero.dts 
b/arch/arm/dts/meson-g12a-radxa-zero.dts
new file mode 100644
index 00..e3bb6df42f
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-radxa-zero.dts
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 BayLibre SAS. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-g12a.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "radxa,zero", "amlogic,g12a";
+   model = "Radxa Zero";
+
+   aliases {
+   serial0 = _AO;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   cvbs-connector {
+   status = "disabled";
+   compatible = "composite-video-connector";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_12 GPIO_ACTIVE_LOW>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = < GPIOX_6 GPIO_ACTIVE_LOW>;
+   clocks = <>;
+   clock-names = "ext_clock";
+   };
+
+   ao_5v: regulator-ao_5v {
+   compatible = "regulator-fixed";
+   regulator-name = "AO_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   vcc_1v8: regulator-vcc_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   hdmi_pw: regulator-hdmi_pw {
+   compatible = "regulator-fixed";
+   regulator-name = "HDMI_PW";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_5v>;
+   regulator-always-on;
+   };
+
+   vddao_1v8: regulator-vddao_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vddao_3v3: regulator-vddao_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_5v>;
+   regulator-always-on;
+   };
+
+   vddcpu: regulator-vddcpu {
+

[PATCH 1/4] ARM: dts: sort Amlogic Makefile section

2021-09-14 Thread Christian Hewitt

Alpha sort the Amlogic dtb list (same as the kernel).

Signed-off-by: Christian Hewitt 
---
 arch/arm/dts/Makefile | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f0160d2dc0..461448c579 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -158,6 +158,7 @@ dtb-$(CONFIG_ARCH_S5P4418) += \
s5p4418-nanopi2.dtb
 
 dtb-$(CONFIG_ARCH_MESON) += \
+   meson-axg-s400.dtb \
meson-gxbb-nanopi-k2.dtb \
meson-gxbb-odroidc2.dtb \
meson-gxbb-nanopi-k2.dtb \
@@ -165,22 +166,22 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-p201.dtb \
meson-gxl-s905x-p212.dtb \
meson-gxl-s805x-libretech-ac.dtb \
+   meson-gxl-s905d-libretech-pc.dtb \
+   meson-gxl-s905x-khadas-vim.dtb \
meson-gxl-s905x-libretech-cc.dtb \
meson-gxl-s905x-libretech-cc-v2.dtb \
-   meson-gxl-s905x-khadas-vim.dtb \
-   meson-gxl-s905d-libretech-pc.dtb \
+   meson-gxl-s905x-p212.dtb \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
-   meson-axg-s400.dtb \
-   meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
+   meson-g12a-u200.dtb \
+   meson-g12b-a311d-khadas-vim3.dtb \
meson-g12b-gtking.dtb \
meson-g12b-gtking-pro.dtb \
meson-g12b-gsking-x.dtb \
meson-g12b-odroid-n2.dtb \
meson-g12b-odroid-n2-plus.dtb \
-   meson-g12b-a311d-khadas-vim3.dtb \
meson-sm1-bananapi-m5.dtb \
meson-sm1-khadas-vim3l.dtb \
meson-sm1-odroid-c4.dtb \
-- 
2.17.1

[PATCH 0/4] ARM: amlogic: add Radxa Zero

2021-09-14 Thread Christian Hewitt

This series alpha sorts the Amlogic Makefile, then adds
support for the Radxa Zero SBC using the device-tree
queued in the Amlogic maintainer tree for Linux 5.16.y

Patches are based on custodians/u-boot-amlogic-next

Christian Hewitt (4):
  ARM: dts: sort Amlogic Makefile section
  ARM: dts: add support for Radxa Zero
  boards: amlogic: add Radxa Zero defconfig
  doc: boards: amlogic: update for Radxa Zero

 arch/arm/dts/Makefile |  12 +-
 .../arm/dts/meson-g12a-radxa-zero-u-boot.dtsi |   7 +
 arch/arm/dts/meson-g12a-radxa-zero.dts| 405 ++
 configs/radxa-zero_defconfig  |  70 +++
 doc/board/amlogic/index.rst   |   3 +-
 doc/board/amlogic/radxa-zero.rst  |  74 
 6 files changed, 565 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-g12a-radxa-zero.dts
 create mode 100644 configs/radxa-zero_defconfig
 create mode 100644 doc/board/amlogic/radxa-zero.rst

-- 
2.17.1

[PATCH 2/2] mmc: bcm2835-host: let firmware manage the clock divisor

2021-09-14 Thread Vincent Fazio

Newer firmware can manage the SDCDIV clock divisor register, allowing
the divisor to scale with the core as necessary.

Leverage this ability if the firmware supports it.

Adapted from the following raspberrypi Linux kernel commit:

  bcm2835-sdhost: Firmware manages the clock divisor
  
https://github.com/raspberrypi/linux/commit/08532d242d7702ae0add95096aa49c5e96e066e2

Signed-off-by: Vincent Fazio 
---
 arch/arm/mach-bcm283x/include/mach/mbox.h | 16 +++
 arch/arm/mach-bcm283x/include/mach/msg.h  | 10 +
 arch/arm/mach-bcm283x/msg.c   | 28 
 drivers/mmc/bcm2835_sdhost.c  | 53 ++-
 4 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h 
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 7dcac583cc..490664f878 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -252,6 +252,22 @@ struct bcm2835_mbox_tag_get_clock_rate {
} body;
 };
 
+#define BCM2835_MBOX_TAG_SET_SDHOST_CLOCK  0x00038042
+
+struct bcm2835_mbox_tag_set_sdhost_clock {
+   struct bcm2835_mbox_tag_hdr tag_hdr;
+   union {
+   struct {
+   u32 rate_hz;
+   } req;
+   struct {
+   u32 rate_hz;
+   u32 rate_1;
+   u32 rate_2;
+   } resp;
+   } body;
+};
+
 #define BCM2835_MBOX_TAG_ALLOCATE_BUFFER   0x00040001
 
 struct bcm2835_mbox_tag_allocate_buffer {
diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h 
b/arch/arm/mach-bcm283x/include/mach/msg.h
index e45c1bf010..ab37abdb6c 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -22,6 +22,16 @@ int bcm2835_power_on_module(u32 module);
  */
 int bcm2835_get_mmc_clock(u32 clock_id);
 
+/**
+ * bcm2835_set_sdhost_clock() - determine if firmware controls sdhost cdiv
+ *
+ * @rate_hz: Input clock frequency
+ * @rate_1: Returns a clock frequency
+ * @rate_2: Returns a clock frequency
+ * @return 0 of OK, -EIO on error
+ */
+int bcm2835_set_sdhost_clock(u32 rate_hz, u32 *rate_1, u32 *rate_2);
+
 /**
  * bcm2835_get_video_size() - get the current display size
  *
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index ae85e9159e..adab15da4e 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -21,6 +21,12 @@ struct msg_get_clock_rate {
u32 end_tag;
 };
 
+struct msg_set_sdhost_clock {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_set_sdhost_clock set_sdhost_clock;
+   u32 end_tag;
+};
+
 struct msg_query {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_physical_w_h physical_w_h;
@@ -110,6 +116,28 @@ int bcm2835_get_mmc_clock(u32 clock_id)
return clock_rate;
 }
 
+int bcm2835_set_sdhost_clock(u32 rate_hz, u32 *rate_1, u32 *rate_2)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_sdhost_clock, msg_sdhost_clk, 
1);
+   int ret;
+
+   BCM2835_MBOX_INIT_HDR(msg_sdhost_clk);
+   BCM2835_MBOX_INIT_TAG(_sdhost_clk->set_sdhost_clock, 
SET_SDHOST_CLOCK);
+
+   msg_sdhost_clk->set_sdhost_clock.body.req.rate_hz = rate_hz;
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, 
_sdhost_clk->hdr);
+   if (ret) {
+   printf("bcm2835: Could not query sdhost clock rate\n");
+   return -EIO;
+   }
+
+   *rate_1 = msg_sdhost_clk->set_sdhost_clock.body.resp.rate_1;
+   *rate_2 = msg_sdhost_clk->set_sdhost_clock.body.resp.rate_2;
+
+   return 0;
+}
+
 int bcm2835_get_video_size(int *widthp, int *heightp)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_query, msg_query, 1);
diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
index 894dbdd686..5c23c03d10 100644
--- a/drivers/mmc/bcm2835_sdhost.c
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -181,6 +181,7 @@ struct bcm2835_host {
struct udevice  *dev;
struct mmc  *mmc;
struct bcm2835_plat *plat;
+   unsigned intfirmware_sets_cdiv:1;
 };
 
 static void bcm2835_dumpregs(struct bcm2835_host *host)
@@ -233,7 +234,7 @@ static void bcm2835_reset_internal(struct bcm2835_host 
*host)
msleep(20);
host->clock = 0;
writel(host->hcfg, host->ioaddr + SDHCFG);
-   writel(host->cdiv, host->ioaddr + SDCDIV);
+   writel(SDCDIV_MAX_CDIV, host->ioaddr + SDCDIV);
 }
 
 static int bcm2835_wait_transfer_complete(struct bcm2835_host *host)
@@ -598,6 +599,7 @@ static int bcm2835_transmit(struct bcm2835_host *host)
 static void bcm2835_set_clock(struct bcm2835_host *host, unsigned int clock)
 {
int div;
+   u32 clock_rate[2] = { 0 };
 
/* The SDCDIV register has 11 bits, and holds (div - 2).  But
 * in data mode the max is 50MHz wihout a minimum, and only
@@ -620,26 +622,34 @@ static void bcm2835_set_clock(struct

[PATCH 1/2] arm: rpi: fallback to max clock rate for MMC clock

2021-09-14 Thread Vincent Fazio

In rpi-firmware 25e2b597ebfb2495eab4816a276758dcc6ea21f1,
the GET_CLOCK_RATE mailbox property was changed to return the last
value set by SET_CLOCK_RATE.

https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917025502

Due to this change in firmware behavior, bcm2835_get_mmc_clock now
returns a clock rate of zero since we do not issue SET_CLOCK_RATE.
This results in degraded MMC performance.

SET_CLOCK_RATE fixes the clock to a specific value and disables scaling
so is not an ideal solution.

Instead, fallback to GET_MAX_CLOCK_RATE in bcm2835_get_mmc_clock if
GET_CLOCK_RATE returns zero.

Signed-off-by: Vincent Fazio 
---
 arch/arm/mach-bcm283x/include/mach/mbox.h |  2 ++
 arch/arm/mach-bcm283x/msg.c   | 19 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h 
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 2ae2d3d97c..7dcac583cc 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -224,6 +224,8 @@ struct bcm2835_mbox_tag_set_power_state {
 };
 
 #define BCM2835_MBOX_TAG_GET_CLOCK_RATE0x00030002
+#define BCM2835_MBOX_TAG_GET_MAX_CLOCK_RATE0x00030004
+#define BCM2835_MBOX_TAG_GET_MIN_CLOCK_RATE0x00030007
 
 #define BCM2835_MBOX_CLOCK_ID_EMMC 1
 #define BCM2835_MBOX_CLOCK_ID_UART 2
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 347aece3cd..ae85e9159e 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -75,6 +75,7 @@ int bcm2835_get_mmc_clock(u32 clock_id)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1);
int ret;
+   u32 clock_rate = 0;
 
ret = bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
if (ret)
@@ -90,7 +91,23 @@ int bcm2835_get_mmc_clock(u32 clock_id)
return -EIO;
}
 
-   return msg_clk->get_clock_rate.body.resp.rate_hz;
+   clock_rate = msg_clk->get_clock_rate.body.resp.rate_hz;
+
+   if (clock_rate == 0) {
+   BCM2835_MBOX_INIT_HDR(msg_clk);
+   BCM2835_MBOX_INIT_TAG(_clk->get_clock_rate, 
GET_MAX_CLOCK_RATE);
+   msg_clk->get_clock_rate.body.req.clock_id = clock_id;
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, 
_clk->hdr);
+   if (ret) {
+   printf("bcm2835: Could not query max eMMC clock 
rate\n");
+   return -EIO;
+   }
+
+   clock_rate = msg_clk->get_clock_rate.body.resp.rate_hz;
+   }
+
+   return clock_rate;
 }
 
 int bcm2835_get_video_size(int *widthp, int *heightp)
-- 
2.25.1

[PATCH 0/2] mmc: bcm2835_sdhost: use fallback clock rate

2021-09-14 Thread Vincent Fazio

Recent raspberry pi firmware has modified the behavior of GET_CLOCK_RATE
to return zero (0) when there is no previous call to SET_CLOCK_RATE.

This affects callers of bcm2835_get_mmc_clock and can lead to degraded
MMC performance.

Now, return the result of GET_MAX_CLOCK_RATE if GET_CLOCK_RATE is zero.

Additionally, let the firmware manage SDCDIV when possible.


Vincent Fazio (2):
  arm: rpi: fallback to max clock rate for MMC clock
  mmc: bcm2835-host: let firmware manage the clock divisor

 arch/arm/mach-bcm283x/include/mach/mbox.h | 18 
 arch/arm/mach-bcm283x/include/mach/msg.h  | 10 +
 arch/arm/mach-bcm283x/msg.c   | 47 +++-
 drivers/mmc/bcm2835_sdhost.c  | 53 ++-
 4 files changed, 106 insertions(+), 22 deletions(-)

-- 
2.25.1

Re: [PATCH] efi_loader: Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again in efi_net_receive()

2021-09-14 Thread Masami Hiramatsu

Hi Heinrich,

This is obscure in the specification (I can not see any detailed
description about EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT).
If EFI_SIMPLE_NETWORK.GetStatus() returns only the hardware interrupt
state, it is an useless interface, because it doesn't sync to the
status of the packet buffer and wait_for_event() result.
If EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT is set only if the rx
interrupts (this is not the rx interrupt in U-Boot anyway...) is
coming, the efi selftest code must not use the net->get_status() for
checking the packet is received, or call net->receive() until the
packet buffer is empty(EFI_NOT_READY) (and also, it has to ensure the
packet buffer is empty before calling wait_for_event()).

So, I think the correct test code will be something like this;

submit_dhcp_discover()
for (;;) {
  wait_for_event(net)
  net->get_status() // and check receive interrupt
  while (net->receive() != EFI_NOT_READY) {
 // check dhcp reply
  }
}

Thank you,

2021年9月15日(水) 0:45 Heinrich Schuchardt :

>
> On 9/14/21 4:06 AM, Masami Hiramatsu wrote:
> > From: Kazuhiko Sakamoto 
> >
> > Since 'this->int_status' is cleared by efi_net_get_status(), if user
>
> Is it correct to clear int_status unconditionally in efi_net_get_status()?
>
> Shouldn't two consecutive calls to EFI_SIMPLE_NETWORK.GetStatus() return
> the same result?
>
> Best regards
>
> Heinrich
>
> > does wait_for_event(wait_for_packet) and efi_net_get_status() loop
> > and there are several received packets on the buffer, the second
> > efi_net_get_status() does not return EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
> > even if the 'wait_for_packet' is ready.
> >
> > This happens on "efiboot selftest" with noisy network.
> > (The network device can receive both of other packets and dhcp discover
> >   packet in a short time.)
> >
> > Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again when we found any
> > packet still on the receive buffer.
> >
> > Signed-off-by: Kazuhiko Sakamoto 
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >   lib/efi_loader/efi_net.c |   13 +++--
> >   1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
> > index 69276b275d..9ca1e0c354 100644
> > --- a/lib/efi_loader/efi_net.c
> > +++ b/lib/efi_loader/efi_net.c
> > @@ -640,10 +640,19 @@ static efi_status_t EFIAPI efi_net_receive
> >   *buffer_size = receive_lengths[rx_packet_idx];
> >   rx_packet_idx = (rx_packet_idx + 1) % ETH_PACKETS_BATCH_RECV;
> >   rx_packet_num--;
> > - if (rx_packet_num)
> > + if (rx_packet_num) {
> > + /*
> > +  * Since 'this->int_status' is cleared by 
> > efi_net_get_status(),
> > +  * if user does wait_for_event(wait_for_packet) and
> > +  * efi_net_get_status() again, 
> > EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
> > +  * is not set even if 'wait_for_packet' is ready.
> > +  * Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again here.
> > +  */
> > + this->int_status |= EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
> >   wait_for_packet->is_signaled = true;
> > - else
> > + } else {
> >   this->int_status &= ~EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
> > + }
> >   out:
> >   return EFI_EXIT(ret);
> >   }
> >
>


--
Masami Hiramatsu

Re: [PATCH v3 29/29] arm: dts: sl28: sync dtbs

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:58PM +0200, Michael Walle wrote:
> Copy the board device tree files from linux v5.14. On top of the v5.14
> dtbs the changes of these two patches are included here which are needed
> for u-boot:
>   
> https://lore.kernel.org/linux-devicetree/20210831134013.1625527-7-mich...@walle.cc/
>   
> https://lore.kernel.org/linux-devicetree/20210831134013.1625527-8-mich...@walle.cc/
> 
> At the time of this writing the patches are still pending but already
> have Reviewed-by tags.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 28/29] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:57PM +0200, Michael Walle wrote:
> Now that everything is prepared, copy the fsl-ls1028a.dtsi from the
> linux kernel v5.14.
> 
> Notable changes:
>  - second watchdog added
>  - the number of chip selects of the SPI controller is now correct and
>reflects what the hardware offers
>  - the LPUARTs have the correct clock parent
>  - USB controllers are enabled by default, which was already the case
>before this sync because all board enabled all the USB controller
>nodes. A linux patch to fix this is pending.
>  - the eSDHC controller changes from big-endian to little-endian, but
>that property seems to be not used at all.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 27/29] arm: dts: ls1028a: drop non-removable property from esdhc controller node

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:56PM +0200, Michael Walle wrote:
> The linux device tree hasn't set this property. To be similarly we remove

s/similarly/similar/

> it from the u-boot device tree, too. The second controller of the
> LS1028A has indeed no card detect pin.

Because it is an eMMC controller.

> The present state register of the
> second controller will always report the card as present. Thus, there
> should be no functional change otherwise than one more register access
> to read the present state.

Tested?

> The property should still be introduced in
> the linux device tree.

How do you feel about dropping this patch?

> 
> Signed-off-by: Michael Walle 
> ---
>  arch/arm/dts/fsl-ls1028a.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index d2f558d208..af6dabe847 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -210,7 +210,6 @@
>   reg = <0x0 0x215 0x0 0x1>;
>   interrupts = ;
>   big-endian;
> - non-removable;
>   bus-width = <4>;
>   status = "disabled";
>   };
> -- 
> 2.30.2
>

Re: [PATCH v3 26/29] arm: dts: ls1028a: disable the PCIe controller by default

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:55PM +0200, Michael Walle wrote:
> Disable the PCIe controllers by default, just like in the linux device
> tree. But there is one catch, for linux they are enabled in-place by the
> bootloader. Obviously, this doesn't work for the bootloader. Thus we
> explicitly enable the controllers in the -u-boot.dtsi files.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 25/29] arm: dts: ls1028a: move the PCI I/O window to match

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:54PM +0200, Michael Walle wrote:
> To make the synchronization of the u-boot device tree with the one from
> linux easier, move the I/O window to the one which is specified in the
> linux device tree. The actual value shouldn't matter as long as it
> mapped to the corresponding memory window of the PCIe controller which
> is a 32GiB window at 80__h (first controller) or 88__h
> (second controller).
> 
> Signed-off-by: Michael Walle 
> ---
>  arch/arm/dts/fsl-ls1028a.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index 3ef710bb3d..f11e75032b 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -352,7 +352,7 @@
>   #size-cells = <2>;
>   device_type = "pci";
>   bus-range = <0x0 0xff>;
> - ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 
> 0x0001   /* downstream I/O */
> + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0 
> 0x0001   /* downstream I/O */
> 0x8200 0x0 0x4000 0x80 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
>   };
>  
> @@ -365,7 +365,7 @@
>   #size-cells = <2>;
>   device_type = "pci";
>   bus-range = <0x0 0xff>;
> - ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 
> 0x0001   /* downstream I/O */
> + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0 
> 0x0001   /* downstream I/O */
> 0x8200 0x0 0x4000 0x88 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
>   };
>  
> -- 
> 2.30.2
> 

Zhiqiang, can you please review this patch?

Re: [PATCH v3 24/29] arm: dts: ls1028a: remove num-lanes in the PCIe controller nodes

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:53PM +0200, Michael Walle wrote:
> This property is unused in the layerscape PCIe controller driver and not
> present in the linux device tree. Remove it to be similarly.
> 
> Signed-off-by: Michael Walle 
> ---

Looks pretty much unused, indeed.

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 21/29] scsi: ceva: rename the resource name to match the linux kernel one

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:50PM +0200, Michael Walle wrote:
> The driver will look for a named resource "ecc-addr", but this isn't the
> official binding. In fact, the official device tree binding
> documentation doesn't mention any resource names at all. But it is safe
> to assume that it's the linux ones we have to use if we want to be
> compatible with the linux device tree. Thus rename "ecc-addr" to
> "sata-ecc" and convert all the users in u-boot.
> 
> While at it, also rename "sata-base" to "ahci" although its not used at
> all.
> 
> This change doesn't affect the SATA controller on the ZynqMP.

Because the "ceva,ahci-1v84" device doesn't have an ECC region, right.

> 
> Cc: Michal Simek 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 19/29] spi: fsl_dspi: rename num-cs to spi-num-chipselects

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:48PM +0200, Michael Walle wrote:
> The official devicetree bindings specifies spi-num-chipselects as the
> name. Use it.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 16/29] arm: dts: ls1028a: update the labels

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:45PM +0200, Michael Walle wrote:
> Update the labels of the nodes to match the kernel ones.
> 
> Signed-off-by: Michael Walle 
> Reviewed-by: Vladimir Oltean 
> Tested-by: Vladimir Oltean 
> ---
> - gpio0: gpio@230 {
> + gpio1: gpio@230 {

For better or for worse. It seems that in Linux our GPIO controller
labels are not zero-based. Whatever.

I maintain my Reviewed-by and Tested-by tags.

Re: [PATCH v3 15/29] arm: dts: ls1028a: move the iRC node and its devices into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:44PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> While at it fix the indentation.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 14/29] arm: dts: ls1028a: move the watchdog node into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:43PM +0200, Michael Walle wrote:
> While inserting it into the new location, keep it sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 13/29] arm: dts: ls1028a: move the PCIe controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:42PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> While at it fix the indentation.
> 
> Signed-off-by: Michael Walle 
> ---
>  arch/arm/dts/fsl-ls1028a.dtsi | 64 +--
>  1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index 7d18085615..d0f90941b9 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -43,38 +43,6 @@
> IRQ_TYPE_LEVEL_LOW)>;
>   };
>  
> - pcie1: pcie@340 {
> -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> -reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4   /* lut registers */
> -0x00 0x034c 0x0 0x4  /* pf controls registers */
> -0x80 0x 0x0 0x2>; /* configuration space */
> -reg-names = "dbi", "lut", "ctrl", "config";
> -#address-cells = <3>;
> -#size-cells = <2>;
> -device_type = "pci";
> -num-lanes = <4>;
> -bus-range = <0x0 0xff>;
> -ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 
> 0x0001   /* downstream I/O */
> -0x8200 0x0 0x4000 0x80 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
> - };
> -
> - pcie2: pcie@350 {
> -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> -reg = <0x00 0x0350 0x0 0x8
> -0x00 0x0358 0x0 0x4   /* lut registers */
> -0x00 0x035c 0x0 0x4  /* pf controls registers */
> -0x88 0x 0x0 0x2>; /* configuration space */
> -reg-names = "dbi", "lut", "ctrl", "config";
> -#address-cells = <3>;
> -#size-cells = <2>;
> -device_type = "pci";
> -num-lanes = <4>;
> -bus-range = <0x0 0xff>;
> -ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 
> 0x0001   /* downstream I/O */
> -0x8200 0x0 0x4000 0x88 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
> - };

Impossible for me to understand how somebody could have gotten it that wrong.

> -
>   pcie@1f000 {
>   compatible = "pci-host-ecam-generic";
>   /* ECAM bus 0, HW has more space reserved but not populated */
> @@ -484,5 +452,37 @@
>   interrupts = ;
>   status = "disabled";
>   };
> +
> + pcie1: pcie@340 {
> + compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", 
> "snps,dw-pcie";
> + reg = <0x00 0x0340 0x0 0x8
> +0x00 0x0348 0x0 0x4   /* lut registers */
> +0x00 0x034c 0x0 0x4   /* pf controls 
> registers */
> +0x80 0x 0x0 0x2>; /* configuration 
> space */
> + reg-names = "dbi", "lut", "ctrl", "config";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + num-lanes = <4>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 
> 0x0001   /* downstream I/O */
> +   0x8200 0x0 0x4000 0x80 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
> + };
> +
> + pcie2: pcie@350 {
> + compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", 
> "snps,dw-pcie";
> + reg = <0x00 0x0350 0x0 0x8
> +0x00 0x0358 0x0 0x4   /* lut registers */
> +0x00 0x035c 0x0 0x4   /* pf controls 
> registers */
> +0x88 0x 0x0 0x2>; /* configuration 
> space */
> + reg-names = "dbi", "lut", "ctrl", "config";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + num-lanes = <4>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 
> 0x0001   /* downstream I/O */
> +   0x8200 0x0 0x4000 0x88 0x4000 0x0 
> 0x4000>; /* non-prefetchable memory */
> + };
>   };
>  };
> -- 
> 2.30.2
> 

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 12/29] arm: dts: ls1028a: move SATA and USB controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:41PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 11/29] arm: dts: ls1028a: move the GPIO controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:40PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 10/29] arm: dts: ls1028a: move the low-power UART nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:39PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 09/29] arm: dts: ls1028a: move the UART controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:38PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 08/29] arm: dts: ls1028a: move the SPI and eSDHC controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:37PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 07/29] arm: dts: ls1028a: move the FlexSPI controller node

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:36PM +0200, Michael Walle wrote:
> While inserting it into the new location, keep it sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 06/29] arm: dts: ls1028a: move I2C controller nodes into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:35PM +0200, Michael Walle wrote:
> While inserting them into the new location, keep them sorted by the
> register base offset just like in the linux kernel device tree.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 05/29] arm: dts: ls1028a: move the clockgen node into /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:34PM +0200, Michael Walle wrote:
> Populate the /soc node with the first device node.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 04/29] arm: dts: ls1028a: add an empty /soc

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:33PM +0200, Michael Walle wrote:
> To keep the device tree similar to the linux kernel one, we need to move
> all CCSR related devices into the /soc node. To keep the patches easy to
> review, we initially add an empty /soc node and populate it piece by
> piece.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

Re: [PATCH v3 03/29] arm: dts: ls1028a-{rdb, qds}: remove dm-pre-reloc property

2021-09-14 Thread Vladimir Oltean

On Thu, Sep 02, 2021 at 06:45:32PM +0200, Michael Walle wrote:
> Nowadays, both boards boot using the TF-A BL1/BL2 and SPL isn't used at
> all. The property is not needed, remove it.
> 
> Signed-off-by: Michael Walle 
> ---

Reviewed-by: Vladimir Oltean

[PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

2021-09-14 Thread Marek Vasut

The flash->mtd.name used to be nor%d before, now it is the type of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the same type in
the system and breaks existing environments.

This does no longer get recognized when running 'mtdparts' for example:
CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"

Fix this by setting the correct mtd.name to nor%d.

Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
enabled")
Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Cc: Marek Behún 
Cc: Miquel Raynal 
Cc: Pali Rohár 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Priyanka Jain 
Cc: Simon Glass 
---
 drivers/mtd/spi/sf_mtd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 04de8680809..1a81689fe4a 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -14,7 +14,10 @@
 
 int spi_flash_mtd_register(struct spi_flash *flash)
 {
-   return add_mtd_device(>mtd);
+   int ret = add_mtd_device(>mtd);
+   if (!ret)
+   sprintf(flash->mtd.name, "nor%d", flash->mtd.index);
+   return ret;
 }
 
 void spi_flash_mtd_unregister(struct spi_flash *flash)
-- 
2.33.0

[ANN] U-Boot v2021.10-rc4 released

2021-09-14 Thread Tom Rini

Hey all,

Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
regressions pop up of late, unfortunately.  I've pushed the fix for
(what I believe are) existing FIT images showing a problem where we
calculated the crc32 wrong.  And we're just now starting to figure out
the proper fix for a problem that was introduced late in v2021.07 with
SPI buses not being configured in the right mode (or in Linux Kernel
terms, spi-cpha/spi-cpol being set on platforms where that's not
correct).

In terms of a changelog, 
git log --merges v2021.10-rc3..v2021.10-rc4
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

We should be releasing on October 4th, 2021 as expected.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] image: Avoid erroneous double byte-swap in CRC value

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 03:53:33PM -0500, Alexandru Gagniuc wrote:

> The hash algorithm selection was streamlined in commit 92055e138f28
> ("image: Drop if/elseif hash selection in calculate_hash()"). Said
> commit kept the call to cpu_to_uimage() to convert the CRC to big
> endian format.
> 
> This would have been correct when calling crc32_wd(). However, the
> ->hash_func_ws member of crc32 points to crc32_wd_buf(), which already
> converts the CRC to big endian. On a little endian host, doing both
> conversions results in a little-endian CRC. This is incorrect.
> 
> To remedy this, simply drop the call to cpu_to_uimage(), thus only
> doing the byte-order conversion once.
> 
> Fixes: 92055e138f28 ("image: Drop if/elseif hash selection in
>calculate_hash()")
> Tested-by: Tom Rini 
> Signed-off-by: Alexandru Gagniuc 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] pinctrl: fix typo

2021-09-14 Thread Tom Rini

On Wed, Sep 08, 2021 at 07:06:48PM +0800, Yuan Fang wrote:

> From: Yuan Fang 
> 
> fix typo in pinctrl Kconfig file to avoid git commit failure on
> some commit hooks check.
> 
> Signed-off-by: Yuan Fang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] lib: fix typos in Kconfig

2021-09-14 Thread Tom Rini

On Wed, Sep 01, 2021 at 04:05:08PM +0300, Oleksandr Suvorov wrote:

> There are trivial typos in the Kconfig file. Fixed them.
> Also, fixed grammar in the descriptions with typos.
> 
> Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and 
> CMD_UBIFS")
> Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/rsa: don't use NULL as key_id

2021-09-14 Thread Tom Rini

On Sat, Aug 28, 2021 at 12:13:05PM +0200, Heinrich Schuchardt wrote:

> If keydir is not provided but name is we want to use name as key_id.
> 
> But with the current coding name is only used on its own if it is NULL
> and keydir is provided which never occurs.
> 
> Fixes: 824ee745fbca ("lib/rsa: Use the 'keyfile' argument from mkimage")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] image: rsa: Move padding_algos to linker lists

2021-09-14 Thread Tom Rini

On Wed, Aug 18, 2021 at 05:49:02PM -0500, Alexandru Gagniuc wrote:

> We are not guaranteed to have the padding_pkcs_15_verify symbol since
> commit 92c960bc1d ("lib: rsa: Remove #ifdefs from rsa.h"), and
> commit 61416fe9df ("Kconfig: FIT_SIGNATURE should not select RSA_VERIFY")
> 
> The padding_algos only make sense with RSA verification, which can now
> be disabled in lieu of ECDSA. In fact this will lead to build failures
> because of the missing symbol mentioned earlier.
> 
> To resolve this, move the padding_algos to a linker list, with
> declarations moved to rsa_verify.c. This is consistent with commit
> 6909edb4ce ("image: rsa: Move verification algorithm to a linker list")
> 
> One could argue that the added #ifdef USE_HOSTCC is ugly, and should
> be hidden within the U_BOOT_PADDING_ALGO() macro. However, this would
> be inconsistent with the "cryptos" list. This logic for was not
> previously explored:
> 
> Without knowledge of the U_BOOT_PADDING_ALGO() macro, its use is
> similar to something being declared. However, should #ifndef
> USE_HOSTCC be part of the macro, it would not be obvious that it
> behaves differently on host code and target code. Having the #ifndef
> outside the macro makes this obvious.
> 
> Also, the #ifdef is not always necessary. For example ecda-verify
> makes use of U_BOOT_CRYPTO_ALGO() without any accompanying #ifdefs.
> The fundamental issue is a lack of separation of host and target code
> in rsa_verify. Therefore, the declaration of a padding algo with the
> external #ifdef is more readable and consistent.
> 
> Signed-off-by: Alexandru Gagniuc 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 11:30:01PM +0200, Marek Vasut wrote:
> On 9/14/21 10:45 PM, Tom Rini wrote:
> > On Tue, Sep 14, 2021 at 10:10:22PM +0200, Marek Vasut wrote:
> > > On 9/14/21 9:19 PM, Tom Rini wrote:
> > > > On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:
> > > > 
> > > > > Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
> > > > > silently defaulted to SF bus mode 0. Now the mode is always updated,
> > > > > which causes breakage. It seems most SF which are used as boot media
> > > > > operate in bus mode 0, so switch that as the default.
> > > > > 
> > > > > This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
> > > > > ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
> > > > > with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
> > > > > as those might need mode 3.
> > > > > 
> > > > > Signed-off-by: Marek Vasut 
> > > > > Cc: Aleksandar Gerasimovski 
> > > > > 
> > > > > Cc: Andreas Biessmann 
> > > > > Cc: Eugen Hristev 
> > > > > Cc: Michal Simek 
> > > > > Cc: Patrice Chotard 
> > > > > Cc: Patrick Delaunay 
> > > > > Cc: Peng Fan 
> > > > > Cc: Siew Chin Lim 
> > > > > Cc: Tom Rini 
> > > > > Cc: Valentin Longchamp 
> > > > > Cc: Vignesh Raghavendra 
> > > > 
> > > > So, some background.  With commit 88e34e5ff76b ("spl: replace
> > > > CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
> > > > related moved from having their default value of SPI_MODE_3 (which
> > > > evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
> > > > to include/spi_flash.h, and a more visible global default than it was
> > > > before.  At that time, the following platforms either set or implied
> > > > SPI_MODE_3 should be used:
> > > > alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
> > > > am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
> > > > am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
> > > > at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
> > > > at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
> > > > bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
> > > > da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
> > > > dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
> > > > inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
> > > > km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
> > > > lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
> > > > netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
> > > > nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
> > > > sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
> > > > zynq_zc770_xm010
> > > > 
> > > > Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
> > > > needs flipping some DIP switches) which has SPI flash by default.  With
> > > > current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
> > > > reading the whole of flash and crc32'ing it, and getting the same result
> > > > back.  So, SPI_MODE_3 seems correct / function here, and likely so on
> > > > the rest of the TI platforms listed above.
> > > > 
> > > > With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
> > > > migrate these values to Kconfig, and a quick spot-check shows that yes,
> > > > the migration did not change any values.
> > > > 
> > > > A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
> > > > platforms have been added (it was 5 years, after all) and those
> > > > platforms seem to be where the problems reside.  I'm not sure if or why
> > > > SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
> > > > see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
> > > > the default to SPI_MODE_0 if there's not a more fundamental problem to
> > > > solve on some platforms such that SPI_MODE_3 could / should be enabled.
> > > 
> > > I rather suspect mode 3 is special case for atmel/am335x and co. and maybe
> > > marvell kirkwood from the list above. So shouldn't we default to 0 and
> > > special-case the two or three instead ?
> > 
> > I guess my question boils down to why is that the right default?  My
> > argument that 3 is the right default is that it's what it was in
> > introduction back in b6368467e6a9 ("SPI Flash: Add "sf" command").  But
> > references to something else such as the Linux Kernel defaults to mode 0
> > or some SPI specs saying you should default to mode 0 or something else
> > would be much appreciated.
> 
> Probably check a couple of board schematics and SoC datasheets to build up
> your own statistics ? In Linux it is 0 because that's likely what most of
> the systems expect it to be, and the few odd ones just set it to 3
> explicitly there (or enable CPOL/CPHA as needed). My statistics indicates
> that I keep

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Marek Vasut


On 9/14/21 10:45 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 10:10:22PM +0200, Marek Vasut wrote:

On 9/14/21 9:19 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:


Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.

This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.

Signed-off-by: Marek Vasut 
Cc: Aleksandar Gerasimovski 
Cc: Andreas Biessmann 
Cc: Eugen Hristev 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Peng Fan 
Cc: Siew Chin Lim 
Cc: Tom Rini 
Cc: Valentin Longchamp 
Cc: Vignesh Raghavendra 


So, some background.  With commit 88e34e5ff76b ("spl: replace
CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
related moved from having their default value of SPI_MODE_3 (which
evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
to include/spi_flash.h, and a more visible global default than it was
before.  At that time, the following platforms either set or implied
SPI_MODE_3 should be used:
alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
zynq_zc770_xm010

Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
needs flipping some DIP switches) which has SPI flash by default.  With
current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
reading the whole of flash and crc32'ing it, and getting the same result
back.  So, SPI_MODE_3 seems correct / function here, and likely so on
the rest of the TI platforms listed above.

With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
migrate these values to Kconfig, and a quick spot-check shows that yes,
the migration did not change any values.

A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
platforms have been added (it was 5 years, after all) and those
platforms seem to be where the problems reside.  I'm not sure if or why
SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
the default to SPI_MODE_0 if there's not a more fundamental problem to
solve on some platforms such that SPI_MODE_3 could / should be enabled.


I rather suspect mode 3 is special case for atmel/am335x and co. and maybe
marvell kirkwood from the list above. So shouldn't we default to 0 and
special-case the two or three instead ?


I guess my question boils down to why is that the right default?  My
argument that 3 is the right default is that it's what it was in
introduction back in b6368467e6a9 ("SPI Flash: Add "sf" command").  But
references to something else such as the Linux Kernel defaults to mode 0
or some SPI specs saying you should default to mode 0 or something else
would be much appreciated.


Probably check a couple of board schematics and SoC datasheets to build 
up your own statistics ? In Linux it is 0 because that's likely what 
most of the systems expect it to be, and the few odd ones just set it to 
3 explicitly there (or enable CPOL/CPHA as needed). My statistics 
indicates that I keep running into "oh, here it is also 3, and it should 
be 0" recently.


I don't have any of the am335x/atmel boards easily available, so I 
cannot check those, hence the CC list.

[PATCH] image: Avoid erroneous double byte-swap in CRC value

2021-09-14 Thread Alexandru Gagniuc

The hash algorithm selection was streamlined in commit 92055e138f28
("image: Drop if/elseif hash selection in calculate_hash()"). Said
commit kept the call to cpu_to_uimage() to convert the CRC to big
endian format.

This would have been correct when calling crc32_wd(). However, the
->hash_func_ws member of crc32 points to crc32_wd_buf(), which already
converts the CRC to big endian. On a little endian host, doing both
conversions results in a little-endian CRC. This is incorrect.

To remedy this, simply drop the call to cpu_to_uimage(), thus only
doing the byte-order conversion once.

Fixes: 92055e138f28 ("image: Drop if/elseif hash selection in
   calculate_hash()")
Tested-by: Tom Rini 
Signed-off-by: Alexandru Gagniuc 
---
 common/image-fit.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 92d9141bcd..f02d437539 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1193,12 +1193,6 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)
return 0;
 }
 
-static void crc32_uimage_fixup(void *value)
-{
-   /* TODO: In C, this type punning is undefined behavior: */
-   *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
-}
-
 /**
  * calculate_hash - calculate and return hash for provided input data
  * @data: pointer to the input data
@@ -1232,9 +1226,6 @@ int calculate_hash(const void *data, int data_len, const 
char *name,
algo->hash_func_ws(data, data_len, value, algo->chunk_size);
*value_len = algo->digest_size;
 
-   if (!strcmp(name, "crc32"))
-   crc32_uimage_fixup(value);
-
return 0;
 }
 
-- 
2.31.1

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 10:10:22PM +0200, Marek Vasut wrote:
> On 9/14/21 9:19 PM, Tom Rini wrote:
> > On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:
> > 
> > > Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
> > > silently defaulted to SF bus mode 0. Now the mode is always updated,
> > > which causes breakage. It seems most SF which are used as boot media
> > > operate in bus mode 0, so switch that as the default.
> > > 
> > > This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
> > > ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
> > > with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
> > > as those might need mode 3.
> > > 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Aleksandar Gerasimovski 
> > > 
> > > Cc: Andreas Biessmann 
> > > Cc: Eugen Hristev 
> > > Cc: Michal Simek 
> > > Cc: Patrice Chotard 
> > > Cc: Patrick Delaunay 
> > > Cc: Peng Fan 
> > > Cc: Siew Chin Lim 
> > > Cc: Tom Rini 
> > > Cc: Valentin Longchamp 
> > > Cc: Vignesh Raghavendra 
> > 
> > So, some background.  With commit 88e34e5ff76b ("spl: replace
> > CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
> > related moved from having their default value of SPI_MODE_3 (which
> > evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
> > to include/spi_flash.h, and a more visible global default than it was
> > before.  At that time, the following platforms either set or implied
> > SPI_MODE_3 should be used:
> > alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
> > am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
> > am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
> > at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
> > at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
> > bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
> > da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
> > dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
> > inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
> > km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
> > lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
> > netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
> > nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
> > sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
> > zynq_zc770_xm010
> > 
> > Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
> > needs flipping some DIP switches) which has SPI flash by default.  With
> > current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
> > reading the whole of flash and crc32'ing it, and getting the same result
> > back.  So, SPI_MODE_3 seems correct / function here, and likely so on
> > the rest of the TI platforms listed above.
> > 
> > With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
> > migrate these values to Kconfig, and a quick spot-check shows that yes,
> > the migration did not change any values.
> > 
> > A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
> > platforms have been added (it was 5 years, after all) and those
> > platforms seem to be where the problems reside.  I'm not sure if or why
> > SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
> > see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
> > the default to SPI_MODE_0 if there's not a more fundamental problem to
> > solve on some platforms such that SPI_MODE_3 could / should be enabled.
> 
> I rather suspect mode 3 is special case for atmel/am335x and co. and maybe
> marvell kirkwood from the list above. So shouldn't we default to 0 and
> special-case the two or three instead ?

I guess my question boils down to why is that the right default?  My
argument that 3 is the right default is that it's what it was in
introduction back in b6368467e6a9 ("SPI Flash: Add "sf" command").  But
references to something else such as the Linux Kernel defaults to mode 0
or some SPI specs saying you should default to mode 0 or something else
would be much appreciated.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Marek Vasut


On 9/14/21 9:19 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:


Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.

This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.

Signed-off-by: Marek Vasut 
Cc: Aleksandar Gerasimovski 
Cc: Andreas Biessmann 
Cc: Eugen Hristev 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Peng Fan 
Cc: Siew Chin Lim 
Cc: Tom Rini 
Cc: Valentin Longchamp 
Cc: Vignesh Raghavendra 


So, some background.  With commit 88e34e5ff76b ("spl: replace
CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
related moved from having their default value of SPI_MODE_3 (which
evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
to include/spi_flash.h, and a more visible global default than it was
before.  At that time, the following platforms either set or implied
SPI_MODE_3 should be used:
alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
zynq_zc770_xm010

Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
needs flipping some DIP switches) which has SPI flash by default.  With
current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
reading the whole of flash and crc32'ing it, and getting the same result
back.  So, SPI_MODE_3 seems correct / function here, and likely so on
the rest of the TI platforms listed above.

With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
migrate these values to Kconfig, and a quick spot-check shows that yes,
the migration did not change any values.

A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
platforms have been added (it was 5 years, after all) and those
platforms seem to be where the problems reside.  I'm not sure if or why
SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
the default to SPI_MODE_0 if there's not a more fundamental problem to
solve on some platforms such that SPI_MODE_3 could / should be enabled.


I rather suspect mode 3 is special case for atmel/am335x and co. and 
maybe marvell kirkwood from the list above. So shouldn't we default to 0 
and special-case the two or three instead ?

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:

> Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
> silently defaulted to SF bus mode 0. Now the mode is always updated,
> which causes breakage. It seems most SF which are used as boot media
> operate in bus mode 0, so switch that as the default.
> 
> This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
> ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
> with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
> as those might need mode 3.
> 
> Signed-off-by: Marek Vasut 
> Cc: Aleksandar Gerasimovski 
> Cc: Andreas Biessmann 
> Cc: Eugen Hristev 
> Cc: Michal Simek 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Peng Fan 
> Cc: Siew Chin Lim 
> Cc: Tom Rini 
> Cc: Valentin Longchamp 
> Cc: Vignesh Raghavendra 

So, some background.  With commit 88e34e5ff76b ("spl: replace
CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
related moved from having their default value of SPI_MODE_3 (which
evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
to include/spi_flash.h, and a more visible global default than it was
before.  At that time, the following platforms either set or implied
SPI_MODE_3 should be used:
alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
zynq_zc770_xm010

Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
needs flipping some DIP switches) which has SPI flash by default.  With
current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
reading the whole of flash and crc32'ing it, and getting the same result
back.  So, SPI_MODE_3 seems correct / function here, and likely so on
the rest of the TI platforms listed above.

With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
migrate these values to Kconfig, and a quick spot-check shows that yes,
the migration did not change any values.

A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
platforms have been added (it was 5 years, after all) and those
platforms seem to be where the problems reside.  I'm not sure if or why
SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
the default to SPI_MODE_0 if there's not a more fundamental problem to
solve on some platforms such that SPI_MODE_3 could / should be enabled.

-- 
Tom

signature.asc
Description: PGP signature

[RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

2021-09-14 Thread Marek Vasut

Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.

This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.

Signed-off-by: Marek Vasut 
Cc: Aleksandar Gerasimovski 
Cc: Andreas Biessmann 
Cc: Eugen Hristev 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Peng Fan 
Cc: Siew Chin Lim 
Cc: Tom Rini 
Cc: Valentin Longchamp 
Cc: Vignesh Raghavendra 
---
 drivers/mtd/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index b2291f72905..f03fe05e333 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -57,7 +57,7 @@ config SF_DEFAULT_CS
 config SF_DEFAULT_MODE
hex "SPI Flash default mode (see include/spi.h)"
depends on SPI_FLASH || DM_SPI_FLASH
-   default 3
+   default 0
help
  The default mode may be provided by the platform
  to handle the common case when only a single serial
-- 
2.33.0

Re: [PATCH] mtd: cqspi: Wait for transfer completion

2021-09-14 Thread Marek Vasut


On 9/14/21 7:42 PM, Pratyush Yadav wrote:

On 14/09/21 05:22AM, Marek Vasut wrote:

Wait for the read/write transfer finish bit get actually cleared,
this does not happen immediately on at least SoCFPGA Gen5.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
Cc: Pratyush Yadav 
---
  drivers/spi/cadence_qspi_apb.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 429ee335db6..2cdf4c9c9f8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_plat *plat,
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
  
+	/* Check indirect done status */

+   ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
+   CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
+   if (ret) {
+   printf("Indirect read clear completion error (%i)\n", ret);
+   goto failrd;
+   }
+


Huh, this is strange. I would expect the bit to clear immediately since
it doesn't really do any operation on the flash. How long does it
usually take to clear? If you don't wait for it to clear does anything
break?


Often it does clear immediately, but there were a few odd cases where it 
did not happen right away, in which case I had transfer corruption.

Re: [PATCH] mtd: cqspi: Fix division by zero

2021-09-14 Thread Marek Vasut


On 9/14/21 7:46 PM, Pratyush Yadav wrote:

On 14/09/21 05:21AM, Marek Vasut wrote:

Both dummy.nbytes and dummy.buswidth may be zero. By not checking
the later, it is possible to trigger division by zero and a crash.
This does happen with tiny SPI NOR framework in SPL. Fix this by
adding the check and returning zero dummy bytes in such a case.

Fixes: 38b0852b0ea ("spi: cadence-qspi: Add support for octal DTR flashes")
Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
Cc: Pratyush Yadav 
---
  drivers/spi/cadence_qspi_apb.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index c36a652211a..429ee335db6 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -219,6 +219,9 @@ static unsigned int cadence_qspi_calc_dummy(const struct 
spi_mem_op *op,
  {
unsigned int dummy_clk;
  
+	if (!op->dummy.nbytes || !op->dummy.buswidth)

+   return 0;


Thanks. A similar fix was sent for Linux as well [0]. I don't think you
should check for dummy buswidth here since nbytes == 0 should be enough
of an indicator that the dummy phase does not exist. Any op with
dummy.nbytes > 1 and dummy.buswidth == 0 is a malformed op that should
ideally never happen, or if it does, then it should be dealt by the SPI
MEM core.

With this fixed,

Reviewed-by: Pratyush Yadav 

[0] 
https://patchwork.kernel.org/project/spi-devel-general/patch/92eea403-9b21-2488-9cc1-664bee760...@nskint.co.jp/


+
dummy_clk = op->dummy.nbytes * (8 / op->dummy.buswidth);


Yes, indeed, the division by zero happens if op->dummy.buswidth == 0, so 
we must check it. Checking for op->dummy.nbytes == 0 is a minor 
optimization.

Re: [PATCH] mtd: cqspi: Fix division by zero

2021-09-14 Thread Pratyush Yadav

On 14/09/21 05:21AM, Marek Vasut wrote:
> Both dummy.nbytes and dummy.buswidth may be zero. By not checking
> the later, it is possible to trigger division by zero and a crash.
> This does happen with tiny SPI NOR framework in SPL. Fix this by
> adding the check and returning zero dummy bytes in such a case.
> 
> Fixes: 38b0852b0ea ("spi: cadence-qspi: Add support for octal DTR flashes")
> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 
> Cc: Vignesh R 
> Cc: Pratyush Yadav 
> ---
>  drivers/spi/cadence_qspi_apb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index c36a652211a..429ee335db6 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -219,6 +219,9 @@ static unsigned int cadence_qspi_calc_dummy(const struct 
> spi_mem_op *op,
>  {
>   unsigned int dummy_clk;
>  
> + if (!op->dummy.nbytes || !op->dummy.buswidth)
> + return 0;

Thanks. A similar fix was sent for Linux as well [0]. I don't think you 
should check for dummy buswidth here since nbytes == 0 should be enough 
of an indicator that the dummy phase does not exist. Any op with 
dummy.nbytes > 1 and dummy.buswidth == 0 is a malformed op that should 
ideally never happen, or if it does, then it should be dealt by the SPI 
MEM core.

With this fixed,

Reviewed-by: Pratyush Yadav 

[0] 
https://patchwork.kernel.org/project/spi-devel-general/patch/92eea403-9b21-2488-9cc1-664bee760...@nskint.co.jp/

> +
>   dummy_clk = op->dummy.nbytes * (8 / op->dummy.buswidth);
>   if (dtr)
>   dummy_clk /= 2;
> -- 
> 2.33.0
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH] mtd: cqspi: Wait for transfer completion

2021-09-14 Thread Pratyush Yadav

On 14/09/21 05:22AM, Marek Vasut wrote:
> Wait for the read/write transfer finish bit get actually cleared,
> this does not happen immediately on at least SoCFPGA Gen5.
> 
> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 
> Cc: Vignesh R 
> Cc: Pratyush Yadav 
> ---
>  drivers/spi/cadence_qspi_apb.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index 429ee335db6..2cdf4c9c9f8 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
> cadence_spi_plat *plat,
>   writel(CQSPI_REG_INDIRECTRD_DONE,
>  plat->regbase + CQSPI_REG_INDIRECTRD);
>  
> + /* Check indirect done status */
> + ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
> + CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
> + if (ret) {
> + printf("Indirect read clear completion error (%i)\n", ret);
> + goto failrd;
> + }
> +

Huh, this is strange. I would expect the bit to clear immediately since 
it doesn't really do any operation on the flash. How long does it 
usually take to clear? If you don't wait for it to clear does anything 
break?

>   return 0;
>  
>  failrd:
> @@ -1012,6 +1020,15 @@ cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_plat *plat,
>   /* Clear indirect completion status */
>   writel(CQSPI_REG_INDIRECTWR_DONE,
>  plat->regbase + CQSPI_REG_INDIRECTWR);
> +
> + /* Check indirect done status */
> + ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTWR,
> + CQSPI_REG_INDIRECTWR_DONE, 0, 10, 0);
> + if (ret) {
> + printf("Indirect write clear completion error (%i)\n", ret);
> + goto failwr;
> + }
> +
>   if (bounce_buf)
>   free(bounce_buf);
>   return 0;
> -- 
> 2.33.0
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: RFC: exclude partitions from efi_selftest

2021-09-14 Thread Heinrich Schuchardt


On 9/14/21 4:56 PM, Michael Lawnick wrote:

Hi,

in our environment we get error on efi_selftest if one of several SSD
partitions isn't properly initialized (due to some other error, but
that's a different topic). I tried to track down to where the partitions
get registered for test but got a bit lost so I request advice from you.


When the UEFI sub-system is intialized we call efi_disk_register(). If
it fails, we don't enter the UEFI sub-system.

Are you able to identify where efi_disk_register() fails?



Shouldn't be the registering of partitions for self test been made
dependent on successful basic init? I wouldn't qualify a non-initialized
partition as reason to let self test fail. If at all a warning should be
sufficient.
As far as I understand efi self test is intended more as a functional
regression test, not a H/W system test, isn't it?
What about the idea to allow to exclude partitions by environment variable?


We use efi_selftest in our continuous integration. Patches that make it
fail will not be accepted upstream. It is nothing that you need on a
deployed production system.

Best regards

Heinrich



KR
Michael

Re: [PATCHv2 1/2] arm: Remove flea3 board

2021-09-14 Thread Stefano Babic


On 14.09.21 15:09, Tom Rini wrote:

This board has not been converted to CONFIG_DM by the deadline.
Remove it.  As this is the last mx35 platform, remove that support as
well.

Cc: Stefano Babic 
Signed-off-by: Tom Rini 
---


Acked-by: Stefano Babic 

Best regards,
Stefano Babic

--
=
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] efi_loader: Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again in efi_net_receive()

2021-09-14 Thread Heinrich Schuchardt


On 9/14/21 4:06 AM, Masami Hiramatsu wrote:

From: Kazuhiko Sakamoto 

Since 'this->int_status' is cleared by efi_net_get_status(), if user


Is it correct to clear int_status unconditionally in efi_net_get_status()?

Shouldn't two consecutive calls to EFI_SIMPLE_NETWORK.GetStatus() return
the same result?

Best regards

Heinrich


does wait_for_event(wait_for_packet) and efi_net_get_status() loop
and there are several received packets on the buffer, the second
efi_net_get_status() does not return EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
even if the 'wait_for_packet' is ready.

This happens on "efiboot selftest" with noisy network.
(The network device can receive both of other packets and dhcp discover
  packet in a short time.)

Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again when we found any
packet still on the receive buffer.

Signed-off-by: Kazuhiko Sakamoto 
Signed-off-by: Masami Hiramatsu 
---
  lib/efi_loader/efi_net.c |   13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 69276b275d..9ca1e0c354 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -640,10 +640,19 @@ static efi_status_t EFIAPI efi_net_receive
*buffer_size = receive_lengths[rx_packet_idx];
rx_packet_idx = (rx_packet_idx + 1) % ETH_PACKETS_BATCH_RECV;
rx_packet_num--;
-   if (rx_packet_num)
+   if (rx_packet_num) {
+   /*
+* Since 'this->int_status' is cleared by efi_net_get_status(),
+* if user does wait_for_event(wait_for_packet) and
+* efi_net_get_status() again, 
EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
+* is not set even if 'wait_for_packet' is ready.
+* Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again here.
+*/
+   this->int_status |= EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
wait_for_packet->is_signaled = true;
-   else
+   } else {
this->int_status &= ~EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
+   }
  out:
return EFI_EXIT(ret);
  }

RFC: exclude partitions from efi_selftest

2021-09-14 Thread Michael Lawnick


Hi,

in our environment we get error on efi_selftest if one of several SSD
partitions isn't properly initialized (due to some other error, but
that's a different topic). I tried to track down to where the partitions
get registered for test but got a bit lost so I request advice from you.

Shouldn't be the registering of partitions for self test been made
dependent on successful basic init? I wouldn't qualify a non-initialized
partition as reason to let self test fail. If at all a warning should be
sufficient.
As far as I understand efi self test is intended more as a functional
regression test, not a H/W system test, isn't it?
What about the idea to allow to exclude partitions by environment variable?

KR
Michael

[PATCHv2 2/2] arm: Remove aspenite board

2021-09-14 Thread Tom Rini

This board has not been converted to CONFIG_DM by the deadline.
Remove it.  As this is the last armada100 platform, remove that support
as well.

Cc: Prafulla Wadaskar 
Signed-off-by: Tom Rini 
---
Changes in v2:
This is the last armada100 platform, remove all of that related code now
too.
---
 arch/arm/Kconfig  |   6 -
 arch/arm/cpu/arm926ejs/Makefile   |   1 -
 arch/arm/cpu/arm926ejs/armada100/Makefile |   7 -
 arch/arm/cpu/arm926ejs/armada100/cpu.c|  93 
 arch/arm/cpu/arm926ejs/armada100/dram.c   | 117 ---
 arch/arm/cpu/arm926ejs/armada100/timer.c  | 198 --
 .../include/asm/arch-armada100/armada100.h|  59 --
 arch/arm/include/asm/arch-armada100/config.h  |  27 ---
 arch/arm/include/asm/arch-armada100/cpu.h | 161 --
 arch/arm/include/asm/arch-armada100/gpio.h|  31 ---
 arch/arm/include/asm/arch-armada100/mfp.h |  79 ---
 arch/arm/include/asm/arch-armada100/spi.h |  78 ---
 .../asm/arch-armada100/utmi-armada100.h   |  62 --
 board/Marvell/aspenite/Kconfig|  15 --
 board/Marvell/aspenite/MAINTAINERS|   6 -
 board/Marvell/aspenite/Makefile   |   8 -
 board/Marvell/aspenite/aspenite.c |  45 
 configs/aspenite_defconfig|  17 --
 drivers/gpio/Makefile |   1 -
 drivers/gpio/mvmfp.c  |  55 -
 drivers/mmc/mv_sdhci.c|  24 ---
 include/configs/aspenite.h|  32 ---
 22 files changed, 1122 deletions(-)
 delete mode 100644 arch/arm/cpu/arm926ejs/armada100/Makefile
 delete mode 100644 arch/arm/cpu/arm926ejs/armada100/cpu.c
 delete mode 100644 arch/arm/cpu/arm926ejs/armada100/dram.c
 delete mode 100644 arch/arm/cpu/arm926ejs/armada100/timer.c
 delete mode 100644 arch/arm/include/asm/arch-armada100/armada100.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/config.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/cpu.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/gpio.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/mfp.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/spi.h
 delete mode 100644 arch/arm/include/asm/arch-armada100/utmi-armada100.h
 delete mode 100644 board/Marvell/aspenite/Kconfig
 delete mode 100644 board/Marvell/aspenite/MAINTAINERS
 delete mode 100644 board/Marvell/aspenite/Makefile
 delete mode 100644 board/Marvell/aspenite/aspenite.c
 delete mode 100644 configs/aspenite_defconfig
 delete mode 100644 drivers/gpio/mvmfp.c
 delete mode 100644 include/configs/aspenite.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5e465e8e526c..c33bae9f9476 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -525,11 +525,6 @@ config ARCH_AT91
select SPL_BOARD_INIT if SPL && !TARGET_SMARTWEB
select SPL_SEPARATE_BSS if SPL
 
-config TARGET_ASPENITE
-   bool "Support aspenite"
-   select CPU_ARM926EJS
-   select GPIO_EXTRA_HEADER
-
 config ARCH_DAVINCI
bool "TI DaVinci"
select CPU_ARM926EJS
@@ -2043,7 +2038,6 @@ source "board/armltd/total_compute/Kconfig"
 
 source "board/bosch/shc/Kconfig"
 source "board/bosch/guardian/Kconfig"
-source "board/Marvell/aspenite/Kconfig"
 source "board/Marvell/octeontx/Kconfig"
 source "board/Marvell/octeontx2/Kconfig"
 source "board/armltd/vexpress64/Kconfig"
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index 98aafe805a22..a6b29af8f4c9 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -12,7 +12,6 @@ extra-y   :=
 endif
 endif
 
-obj-$(CONFIG_ARMADA100) += armada100/
 obj-$(CONFIG_MX25) += mx25/
 obj-$(CONFIG_MX27) += mx27/
 obj-$(if $(filter mxs,$(SOC)),y) += mxs/
diff --git a/arch/arm/cpu/arm926ejs/armada100/Makefile 
b/arch/arm/cpu/arm926ejs/armada100/Makefile
deleted file mode 100644
index 77ac0e2624ab..
--- a/arch/arm/cpu/arm926ejs/armada100/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2010
-# Marvell Semiconductor 
-# Written-by: Prafulla Wadaskar 
-
-obj-y  = cpu.o timer.o dram.o
diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c 
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
deleted file mode 100644
index 96726b3144ec..
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ /dev/null
@@ -1,93 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2010
- * Marvell Semiconductor 
- * Written-by: Prafulla Wadaskar 
- * Contributor: Mahavir Jain 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define UARTCLK14745KHZ(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1))
-#define SET_MRVL_ID(1<<8)
-#define L2C_RAM_SEL(1<<4)
-
-int arch_cpu_init(void)
-{
-   u32 val;
-   struct armd1cpu_registers *cpuregs =
-   (struct armd1cpu_registers *) ARMD1_CPU_BASE;
-
-   struct

Re: [PATCH] image: fit: fix byte order for crc32 hash check

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 06:31:41AM +, Mathew McBride wrote:

> In 92055e138f ("image: Drop if/elseif hash selection in calculate_hash()")
> the FIT image hash verification code was simplified to use the hash API.
> 
> This broke verification of CRC32 hash FIT images (e.g NXP MC firmware)
> as the hash API crc32 calculates in big endian (refer commit
> 74a18ee8a563, "crc32: Correct endianness of crc32 result"), whereas
> the previous call directly to crc32_wd does not do a byteswap.
> 
> Example:
> dumpimage -l qoriq-mc-binary/ls1088a/mc_ls1088a_10.29.1.itb
> FIT description: MC Firmware
> Created: Fri Aug 27 14:14:32 2021
> ...
>   Hash algo:crc32
>   Hash value:   c09d959c
> Was returning FB9D3710 to fit_image_check_hash instead of C09D959C
> 
> Correct the byte order in the crc32_uimage_fixup so the little endian
> values are returned.
> 
> Fixes: 92055e138f "image: Drop if/elseif hash selection in calculate_hash()"
> Signed-off-by: Mathew McBride 

Good catch.  However:
   sandbox:  w+   sandbox
+(sandbox)   *((uint32_t *)value) = ntohl(*((uint32_t *)value));
+(sandbox)  ^
+(sandbox)  atoll
w+(sandbox) tools/../common/image-fit.c: In function ‘crc32_uimage_fixup’:
w+(sandbox) tools/../common/image-fit.c:1201:25: warning: implicit declaration 
of function ‘ntohl’; did you mean ‘atoll’? [-Wimplicit-function-declaration]

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 2/2] phy: stm32-usbphyc: stm32: usbphyc: add protection on phy sub-node

2021-09-14 Thread Patrick Delaunay

Add protection on presence and order of the phy node sub node
by using the mandatory reg information.

Signed-off-by: Patrick Delaunay 
---

 drivers/phy/phy-stm32-usbphyc.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-stm32-usbphyc.c b/drivers/phy/phy-stm32-usbphyc.c
index c206efd28d..9c1dcfae52 100644
--- a/drivers/phy/phy-stm32-usbphyc.c
+++ b/drivers/phy/phy-stm32-usbphyc.c
@@ -340,7 +340,7 @@ static int stm32_usbphyc_probe(struct udevice *dev)
struct stm32_usbphyc *usbphyc = dev_get_priv(dev);
struct reset_ctl reset;
ofnode node, connector;
-   int i, ret;
+   int ret;
 
usbphyc->base = dev_read_addr(dev);
if (usbphyc->base == FDT_ADDR_T_NONE)
@@ -378,14 +378,18 @@ static int stm32_usbphyc_probe(struct udevice *dev)
return ret;
}
 
-   /*
-* parse all PHY subnodes in order to populate regulator associated
-* to each PHY port
-*/
-   node = dev_read_first_subnode(dev);
-   for (i = 0; i < MAX_PHYS; i++) {
-   struct stm32_usbphyc_phy *usbphyc_phy = usbphyc->phys + i;
+   /* parse all PHY subnodes to populate regulator associated to each PHY 
port */
+   dev_for_each_subnode(node, dev) {
+   fdt_addr_t phy_id;
+   struct stm32_usbphyc_phy *usbphyc_phy;
 
+   phy_id = ofnode_read_u32_default(node, "reg", FDT_ADDR_T_NONE);
+   if (phy_id >= MAX_PHYS) {
+   dev_err(dev, "invalid reg value %lx for %s\n",
+   phy_id, ofnode_get_name(node));
+   return -ENOENT;
+   }
+   usbphyc_phy = usbphyc->phys + phy_id;
usbphyc_phy->init = false;
usbphyc_phy->powered = false;
ret = stm32_usbphyc_get_regulator(node, "phy-supply",
@@ -401,8 +405,6 @@ static int stm32_usbphyc_probe(struct udevice *dev)
ret = stm32_usbphyc_get_regulator(connector, 
"vbus-supply",
  _phy->vbus);
}
-
-   node = dev_read_next_subnode(node);
}
 
/* Check if second port has to be used for host controller */
-- 
2.25.1

[PATCH 1/2] phy: stm32-usbphyc: use connector for vbus-supply with phy-stm32-usbphyc

2021-09-14 Thread Patrick Delaunay

The vbus-supply is an optional property of sub-node connector node.
and no more in the usb phyc node (in first proposed binding).

This regulator for USB VBUS may be needed for host mode.

See the latest kernel binding for details in
Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml.

  usbphyc_port0: usb-phy@0 {
  reg = <0>;
  phy-supply = <_usb>;
  #phy-cells = <0>;
  connector {
  compatible = "usb-a-connector";
  vbus-supply = <_sw>;
  };
  };

Signed-off-by: Patrick Delaunay 
---

 drivers/phy/phy-stm32-usbphyc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-stm32-usbphyc.c b/drivers/phy/phy-stm32-usbphyc.c
index 02d859a039..c206efd28d 100644
--- a/drivers/phy/phy-stm32-usbphyc.c
+++ b/drivers/phy/phy-stm32-usbphyc.c
@@ -339,7 +339,7 @@ static int stm32_usbphyc_probe(struct udevice *dev)
 {
struct stm32_usbphyc *usbphyc = dev_get_priv(dev);
struct reset_ctl reset;
-   ofnode node;
+   ofnode node, connector;
int i, ret;
 
usbphyc->base = dev_read_addr(dev);
@@ -395,10 +395,12 @@ static int stm32_usbphyc_probe(struct udevice *dev)
return ret;
}
 
-   ret = stm32_usbphyc_get_regulator(node, "vbus-supply",
- _phy->vbus);
-   if (ret)
-   usbphyc_phy->vbus = NULL;
+   usbphyc_phy->vbus = NULL;
+   connector = ofnode_find_subnode(node, "connector");
+   if (ofnode_valid(connector)) {
+   ret = stm32_usbphyc_get_regulator(connector, 
"vbus-supply",
+ _phy->vbus);
+   }
 
node = dev_read_next_subnode(node);
}
-- 
2.25.1

Re: [PATCH 0/3] stm32mp: Attempt to resolve unintended breakage with v2021.10-rc2

2021-09-14 Thread Patrick DELAUNAY


Hi Alexandru,

On 9/9/21 4:55 PM, Alexandru Gagniuc wrote:

u-boot v2021.10-rc2 Introduced support for booting from FIP images
(not to be confused with FIT) for stm32mp. I am also working on a
different boot flow based on u-boot's falcon mode. The changes to
accommodate the FIP mode inadvertently broke the falcon flow. This
series intends to address that.

The core issue is that optee nodes are removed from the u-boot
devicetree. For reasons detailed in my other series
("[PATCH v2 00/11] stm32mp1: Support falcon mode with OP-TEE payloads")
the "optee" nodes are required.

It might seem like an obvious solution to "just re-add the nodes", but
I found out it didn't work like that. I couldn't use
STM32MP15x_STM32IMAGE to get me back my nodes, because that would have
required TFABOOT. What I needed was a new config that more accuratelyreflected 
the available boot flows.

STM32MP15x_STM32IMAGE is a confusing because it conflates image
generation with u-boot behavior. I'm proposing replacing it with
TFABOOT_FIP_CONTAINER because I think this new config is much easier
to understand in layman's terms. I also thinks it maps more elegantly
to what STM is trying to do: add a new boot flow.


Again, I don't add a new boot flow BUT the support of the default

container = the FIP for the existing TFA BOOT flow .


It is the SAME boot flow, previously named "trusted"


TF-A (BL2) => secure monitor => U-Boot => kernel


And we have also 2 variant here: the secure monitor can be OP-TEE or SP_MIN


The only difference is the containers used by TF-A BL2 (FSBL) to load

the next stage (secure monitor / SSBL) and the DT is provided to U-Boot 
by TF-A/OP-TEE.


And booth container can be used with  OP-TEE or SP_MIN.


In the first support of STM32MP15 in TF-A, we use the STM32IMAGE 
container (several files *.stm32)


but after some requests (PKI) and evolution and to avoid limitation 
(SYSRAM size)


we conclude it was a error to a use this proprietary format after TF-A BL2.


We keep this format only for ROM code, for the first boot stage loader = 
TF-A BL2 or SPL.



Now we are migrating the "trusted" boot (with TF-A boot) to use the FIP

container.


So the usage of STM32IMAGE container for U-Boot is STM32MP15x specific

and the FIP is the default container for TFABOOT

(for me no need to specific CONFIG to managed generic behavior),


It is strange to add a config for all board (so always activated), to 
solve a problem


only present in the STM32MP platform because we badly support TFA in the

first upstreamed code.


So I prefer use a "CONFIG_STM32MP15x_" config to manage it;

it is only activated for TFABOOT and for STM32MP15


But perhaps you prefer a longer name ?


=> CONFIG_STM32MP15x_TFABOOT_STM32IMAGE_CONTAINER

or

=> CONFIG_STM32MP15x_TFABOOT_WITH_STM32IMAGE


For the OP-TEE nodes, on ST boards at least, they are assumes added by 
OP-TEE


firmware. It is the expected behavior when OP-TEE is compiled for ST boards.


So for me it is not a issue but the expected behavior for ST boards for 
upstream.



This behavior allows to dynamically manage the case when OP-TEE is not 
present: driver is not probed,


because it can be replaced by SP-MIN in FIP or in STM32IMAGE, and avoid 
to force information


in U-Boot device tree configuration which can be managed by OP-TEE.


U-Boot can start any OP-TEE binary, even if memory configuration change

and I try to limit the number of U-Bot add-on in "stm32mp*-u-boot.dtsi".


I agree that for you use can you could force OP-TEE nodes, when OP-TEE is

not compiled to update device tree, by it is not a option chosen

on ST Microelectronics boards for upstream support.


Moreover for me it is not possible to have one compilation flag which 
defined the boot flow


and I see several other issue with the "falcon OP-TEE" mode:


SPL => OP-TEE => U-Boot


OP-TEE should provide PSCI / SCMI server to U-Boot running in non secure,

so the U-Boot configuration change:

=> CONFIG_ARCH_SUPPORT_PSCI = n

=> CONFIG_ARM_SMCCC

=> CONFIG_CPU_V7_HAS_NONSEC

=> CONFIG_SYSRESET_PSCI

=> CONFIG_SCMI_FIRMWARE / CONFIG_CLK_SCMI / CONFIG_RESET_SCMI

=> CONFIG_TEE / CONFIG_OPTEE

Today they configuration are only activate for TF-A boot
because I assume that with SPL, U-Boot is running is secure level with direct 
access
to secure ressources / wihtout OPTEE


I think you need to update  arch/arm/mach-stm32mp/Kconfig


something like:


 config STM32MP15x
 bool "Support STMicroelectronics STM32MP15x Soc"
-    select ARCH_SUPPORT_PSCI if !TFABOOT
-    select ARM_SMCCC if TFABOOT
+    select ARCH_SUPPORT_PSCI if !TFABOOT && !SPL_OPTEE_IMAGE
+    select ARM_SMCCC if TFABOOT || SPL_OPTEE_IMAGE
 select CPU_V7A
-    select CPU_V7_HAS_NONSEC if !TFABOOT
+    select CPU_V7_HAS_NONSEC if !TFABOOT && !SPL_OPTEE_IMAGE
 select CPU_V7_HAS_VIRT
 select OF_BOARD_SETUP
 select PINCTRL_STM32
@@ -47,8 +47,8 @@ config STM32MP15x
 select STM32_SERIAL
 select SYS_ARCH_TIMER
 imply

[PATCH] arm: dts: stm32mp1: use ssbl partition name for U-Boot

2021-09-14 Thread Patrick Delaunay

Continue to use the "ssbl" name for GPT partition of secondary boot
stage = U-Boot for basic boot with SPL to avoid to disturb existing user.

The "fip" partition name is only used for TFA_BOOT with FIP, it is a TF-A
BL2 requirement; it the default configuration for STMicroelectronics
boards.

Fixes: b73e8bf453f8 ("arm: stm32mp: add defconfig for trusted boot with FIP")
Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 +++-
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 0101962ea5..15a04ae927 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -21,11 +21,13 @@
st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW | 
GPIO_PULL_UP)>;
};
 
-#ifdef CONFIG_STM32MP15x_STM32IMAGE
+#if defined(CONFIG_STM32MP15x_STM32IMAGE) || defined(CONFIG_SPL)
config {
u-boot,mmc-env-partition = "ssbl";
};
+#endif
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
/* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 32777384c6..408abaf52f 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -20,11 +20,13 @@
st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW | 
GPIO_PULL_UP)>;
};
 
-#ifdef CONFIG_STM32MP15x_STM32IMAGE
+#if defined(CONFIG_STM32MP15x_STM32IMAGE) || defined(CONFIG_SPL)
config {
u-boot,mmc-env-partition = "ssbl";
};
+#endif
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
/* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
-- 
2.25.1

Re: [PATCH 5/6] arm: Remove edminiv2 board and orion5x support

2021-09-14 Thread Tom Rini

On Tue, Sep 14, 2021 at 10:37:43AM +0200, Simon Guinot wrote:

> Hi Stefan and Tom,
> 
> I finally managed to find a Disk Mini v2 Ethernet card and I will be
> working on the DM conversion as soon as possible.
> 
> Please, let me know what is my deadline to complete this job ?

Great.  So, the deadline for DM conversion was v2020.01, which means I
was going to remove it for the v2022.01 release.  That's pretty far
away.  But there's also only a handful of non-converted platforms, so I
was going to instead try and drop everything for v2021.01.  Do you think
you can have this converted by some time in October?  End of October
would be OK.  If you need more time than that, let me know.

But please update the MAINTAINERS file now :)

-- 
Tom

signature.asc
Description: PGP signature

ECC strength for device tree with imx6 processor

2021-09-14 Thread Torrelli, Maxime

Hello dear U-Boot members,

We recently tried to add support for a nand Flash (Micron MT29F4G08ABAEAWP 
among others) from U-Boot 2020.04 on an iMX6DL processor.
We try to configure the ECC strength to 16 bits through the DTSI but when the 
U-Boot is started, the command mtd list returns that the ECC strength is 8 bits.

An extract of our defconfig :
CONFIG_NAND_MXS=y
CONFIG_CMD_NAND=y
CONFIG_NAND_MXS_DT=y
CONFIG_MTD_RAW_NAND=y
CONFIG_DM_MTD=y

Content of our configs/*.h file :
#define CONFIG_SYS_NAND_ONFI_DETECTION

Content of our *.dtsi file :
 {
pinctrl-names = "default";
pinctrl-0 = <_nandflash_pins>;
status = "okay";
nand-ecc-strength=<16>;
nand-ecc-step-size=<512>;
nand-on-flash-bbt;
};

I dug into the source code of the drivers and found out the function 
nand_dt_init (nand_base.c) reads the nand-ecc-strength property form the dtsi 
and puts its value into chip->ecc.strength.
Whereas, when the function mxs_nand_set_geometry (mxs_nand.c) calls 
mxs_nand_calc_ecc_layout_by_info, instead of using chip->ecc.strength as a 
parameter of mxs_nand_calc_ecc_layout_by_info, it uses chip->ecc_strength_ds.
The ecc_strength_ds value is set to 8 bits by nand_flash_detect_onfi 
(nand_base.c) which reads the ONFI data of our Nand.

I have tried to remove the define CONFIG_SYS_NAND_ONFI_DETECTION, but doing so 
the driver uses Legacy BCH Geometry and set the ECC strength to 8 bits.

I managed to get the driver to work by changing the following line from the 
function mxs_nand_set_geometry (mxs_nand.c) :
return mxs_nand_calc_ecc_layout_by_info(geo, mtd, chip->ecc_strength_ds, 
chip->ecc_step_ds);
changed to
return mxs_nand_calc_ecc_layout_by_info(geo, mtd, chip->ecc.strength, 
chip->ecc_step_ds);

Even though this quick fix solves our issue, I have no clue if it works with 
all the different configurations supported by the U-Boot.

If you have any suggestion to solve this issue, please let me know.
And if you have any question, I will do my utmost to answer.


Salutations/Greetings,

Maxime Torrelli
Embbeded Software Engineer
Conduent Business Solutions France

[cid:image001.png@01D7A951.8A9B5600]
1 rue Claude Chappe
07500 Guilherand-Granges

T +334 75 81 56 81
maxime.torre...@conduent.com

Through our dedicated associates, we deliver mission-critical services and 
solutions on behalf of businesses and governments - creating exceptional 
outcomes for our clients and the millions of people who count on them. Learn 
more at www.conduent.com.

[PATCH] efi_loader: Fix spec ID event creation

2021-09-14 Thread Ruchika Gupta

TCG EFI Protocol Specification defines the number_of_algorithms
field in spec ID event to be equal to the number of active
algorithms supported by the TPM device. In current implementation,
this field is populated with the count of all algorithms supported
by the TPM which leads to incorrect spec ID event creation.

Similarly, the algorithm array in spec ID event should be a variable
length array with length being equal to the number_of_algorithms field.
In current implementation this is defined as a fixed length array
which has been fixed.

Signed-off-by: Ruchika Gupta 
CC: Masahisa Kojima 
CC: Ilias Apalodimas 
CC: Heinrich Schuchardt 
---
 include/efi_tcg2.h|  7 +--
 lib/efi_loader/efi_tcg2.c | 40 ++-
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index c99384fb00..6c9f448a26 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -165,8 +165,6 @@ struct tcg_efi_spec_id_event_algorithm_size {
  * @digest_sizes:  array of number_of_algorithms pairs
  * 1st member defines the algorithm id
  * 2nd member defines the algorithm size
- * @vendor_info_size:  size in bytes for vendor specific info
- * @vendor_info:   vendor specific info
  */
 struct tcg_efi_spec_id_event {
u8 signature[16];
@@ -176,10 +174,7 @@ struct tcg_efi_spec_id_event {
u8 spec_errata;
u8 uintn_size;
u32 number_of_algorithms;
-   struct tcg_efi_spec_id_event_algorithm_size 
digest_sizes[TPM2_NUM_PCR_BANKS];
-   u8 vendor_info_size;
-   /* U-Boot does not provide any vendor info */
-   u8 vendor_info[];
+   struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
 } __packed;
 
 /**
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index b268a02976..3fd6bc30a1 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -575,9 +575,10 @@ static efi_status_t tcg2_create_digest(const u8 *input, 
u32 length,
EFI_PRINT("Unsupported algorithm %x\n", hash_alg);
return EFI_INVALID_PARAMETER;
}
+   digest_list->digests[digest_list->count].hash_alg = hash_alg;
+   memcpy(_list->digests[digest_list->count].digest, final,
+  (u32)alg_to_len(hash_alg));
digest_list->count++;
-   digest_list->digests[i].hash_alg = hash_alg;
-   memcpy(_list->digests[i].digest, final, 
(u32)alg_to_len(hash_alg));
}
 
return EFI_SUCCESS;
@@ -798,8 +799,9 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64 
efi_size,
EFI_PRINT("Unsupported algorithm %x\n", hash_alg);
return EFI_INVALID_PARAMETER;
}
-   digest_list->digests[i].hash_alg = hash_alg;
-   memcpy(_list->digests[i].digest, hash, 
(u32)alg_to_len(hash_alg));
+   digest_list->digests[digest_list->count].hash_alg = hash_alg;
+   memcpy(_list->digests[digest_list->count].digest, hash,
+  (u32)alg_to_len(hash_alg));
digest_list->count++;
}
 
@@ -1123,7 +1125,7 @@ static efi_status_t create_specid_event(struct udevice 
*dev, void *buffer,
struct tcg_efi_spec_id_event *spec_event;
size_t spec_event_size;
efi_status_t ret = EFI_DEVICE_ERROR;
-   u32 active = 0, supported = 0;
+   u32 active = 0, supported = 0, pcr_count = 0, alg_count = 0;
int err;
size_t i;
 
@@ -1145,25 +1147,29 @@ static efi_status_t create_specid_event(struct udevice 
*dev, void *buffer,
TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2;
spec_event->uintn_size = sizeof(efi_uintn_t) / sizeof(u32);
 
-   err = tpm2_get_pcr_info(dev, , ,
-   _event->number_of_algorithms);
+   err = tpm2_get_pcr_info(dev, , , _count);
+
if (err)
goto out;
-   if (spec_event->number_of_algorithms > MAX_HASH_COUNT ||
-   spec_event->number_of_algorithms < 1)
-   goto out;
 
-   for (i = 0; i < spec_event->number_of_algorithms; i++) {
+   for (i = 0; i < pcr_count; i++) {
u16 hash_alg = hash_algo_list[i].hash_alg;
u16 hash_len = hash_algo_list[i].hash_len;
 
-   if (active && alg_to_mask(hash_alg)) {
+   if (active & alg_to_mask(hash_alg)) {
put_unaligned_le16(hash_alg,
-  
_event->digest_sizes[i].algorithm_id);
+  
_event->digest_sizes[alg_count].algorithm_id);
put_unaligned_le16(hash_len,
-  
_event->digest_sizes[i].digest_size);
+

[PATCH] mtd: rawnand: Add Macronix raw NAND controller driver

2021-09-14 Thread Zhengxun Li

Add a driver for Macronix raw NAND controller.

This patch referred from linux mxic_nand.c. The difference from the
linux version is described here.

1. In order to adapt to the uboot nand framework, add function
   binding (cmdfunc, read_byte, read_buf, write_buf).

2. Added parsing command format to use hardware correctly.

3. Remove the incompatible functions of Uboot.

Signed-off-by: Zhengxun Li 
---
 drivers/mtd/nand/raw/Kconfig |   6 +
 drivers/mtd/nand/raw/Makefile|   1 +
 drivers/mtd/nand/raw/mxic_nand.c | 603 +++
 3 files changed, 610 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/mxic_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index a901ce5..3adbf18 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -278,6 +278,12 @@ config NAND_MXS_USE_MINIMUM_ECC
 
 endif
 
+config NAND_MXIC
+   bool "Macronix raw NAND controller"
+   select SYS_NAND_SELF_INIT
+   help
+ This selects the Macronix raw NAND controller driver.
+
 config NAND_ZYNQ
bool "Support for Zynq Nand controller"
select SYS_NAND_SELF_INIT
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index a5ed2c5..6ec3581 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
 obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
+obj-$(CONFIG_NAND_MXIC) += mxic_nand.o
 obj-$(CONFIG_NAND_ZYNQ) += zynq_nand.o
 obj-$(CONFIG_NAND_STM32_FMC2) += stm32_fmc2_nand.o
 obj-$(CONFIG_CORTINA_NAND) += cortina_nand.o
diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c
new file mode 100644
index 000..e54df46
--- /dev/null
+++ b/drivers/mtd/nand/raw/mxic_nand.c
@@ -0,0 +1,603 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Macronix International Co., Ltd.
+ *
+ * Author:
+ * Zhengxun Li 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HC_CFG 0x0
+#define HC_CFG_IF_CFG(x)   ((x) << 27)
+#define HC_CFG_DUAL_SLAVE  BIT(31)
+#define HC_CFG_INDIVIDUAL  BIT(30)
+#define HC_CFG_NIO(x)  (((x) / 4) << 27)
+#define HC_CFG_TYPE(s, t)  ((t) << (23 + ((s) * 2)))
+#define HC_CFG_TYPE_SPI_NOR0
+#define HC_CFG_TYPE_SPI_NAND   1
+#define HC_CFG_TYPE_SPI_RAM2
+#define HC_CFG_TYPE_RAW_NAND   3
+#define HC_CFG_SLV_ACT(x)  ((x) << 21)
+#define HC_CFG_CLK_PH_EN   BIT(20)
+#define HC_CFG_CLK_POL_INV BIT(19)
+#define HC_CFG_BIG_ENDIAN  BIT(18)
+#define HC_CFG_DATA_PASS   BIT(17)
+#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16)
+#define HC_CFG_MAN_START_ENBIT(3)
+#define HC_CFG_MAN_START   BIT(2)
+#define HC_CFG_MAN_CS_EN   BIT(1)
+#define HC_CFG_MAN_CS_ASSERT   BIT(0)
+
+#define INT_STS0x4
+#define INT_STS_EN 0x8
+#define INT_SIG_EN 0xc
+#define INT_STS_ALLGENMASK(31, 0)
+#define INT_RDY_PINBIT(26)
+#define INT_RDY_SR BIT(25)
+#define INT_LNR_SUSP   BIT(24)
+#define INT_ECC_ERRBIT(17)
+#define INT_CRC_ERRBIT(16)
+#define INT_LWR_DISBIT(12)
+#define INT_LRD_DISBIT(11)
+#define INT_SDMA_INT   BIT(10)
+#define INT_DMA_FINISH BIT(9)
+#define INT_RX_NOT_FULLBIT(3)
+#define INT_RX_NOT_EMPTY   BIT(2)
+#define INT_TX_NOT_FULLBIT(1)
+#define INT_TX_EMPTY   BIT(0)
+
+#define HC_EN  0x10
+#define HC_EN_BIT  BIT(0)
+
+#define TXD(x) (0x14 + ((x) * 4))
+#define RXD0x24
+
+#define SS_CTRL(s) (0x30 + ((s) * 4))
+#define LRD_CFG0x44
+#define LWR_CFG0x80
+#define RWW_CFG0x70
+#define OP_READBIT(23)
+#define OP_DUMMY_CYC(x)((x) << 17)
+#define OP_ADDR_BYTES(x)   ((x) << 14)
+#define OP_CMD_BYTES(x)(((x) - 1) << 13)
+#define OP_OCTA_CRC_EN BIT(12)
+#define OP_DQS_EN  BIT(11)
+#define OP_ENHC_EN BIT(10)
+#define OP_PREAMBLE_EN BIT(9)
+#define OP_DATA_DDRBIT(8)
+#define OP_DATA_BUSW(x)((x) << 6)
+#define OP_ADDR_DDRBIT(5)
+#define OP_ADDR_BUSW(x)((x) << 3)
+#define OP_CMD_DDR BIT(2)
+#define OP_CMD_BUSW(x) (x)
+#define OP_BUSW_1  0
+#define OP_BUSW_2  1
+#define OP_BUSW_4  2
+#define OP_BUSW_8  3
+
+#define OCTA_CRC   0x38
+#define OCTA_CRC_IN_EN(s)  BIT(3 + ((s) * 16))
+#define OCTA_CRC_CHUNK(s, x)   ((fls((x) / 32)) << (1 + ((s) *

Re: [PATCH] dfu: dfu_sf: Add support for multiple flashes

2021-09-14 Thread Lukasz Majewski

On Tue, 14 Sep 2021 05:27:51 +0200
Marek Vasut  wrote:

> Add dfu_alt_info option which allows specifying multiple SPI flashes
> as an alt info. The syntax is as follows:
> 
> altname sf bus:cs[:speed[:mode]]
> 
> Example:
> dfu_alt_info=qspi0 sf 0:0;qspi1 sf 0:1
> 
> Signed-off-by: Marek Vasut 
> Cc: Lukasz Majewski 
> ---
>  drivers/dfu/dfu_sf.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
> index b72493ced86..d246e1b21ff 100644
> --- a/drivers/dfu/dfu_sf.c
> +++ b/drivers/dfu/dfu_sf.c
> @@ -168,22 +168,31 @@ static struct spi_flash *parse_dev(char *devstr)
>  int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, char *s)
>  {
>   char *st;
> - char *devstr_bkup = strdup(devstr);
> -
> - dfu->data.sf.dev = parse_dev(devstr_bkup);
> - free(devstr_bkup);
> - if (!dfu->data.sf.dev)
> - return -ENODEV;
>  
>   dfu->dev_type = DFU_DEV_SF;
>   dfu->max_buf_size = dfu->data.sf.dev->sector_size;
>  
>   st = strsep(, " ");
>   if (!strcmp(st, "raw")) {
> + char *devstr_bkup = strdup(devstr);
> + dfu->data.sf.dev = parse_dev(devstr_bkup);
> + free(devstr_bkup);
> + if (!dfu->data.sf.dev)
> + return -ENODEV;
> +
>   dfu->layout = DFU_RAW_ADDR;
>   dfu->data.sf.start = hextoul(s, );
>   s++;
>   dfu->data.sf.size = hextoul(s, );
> + } else if (!strcmp(st, "sf")) {
> + st = strsep(, " ");
> + dfu->data.sf.dev = parse_dev(st);
> + if (!dfu->data.sf.dev)
> + return -ENODEV;
> +
> + dfu->layout = DFU_RAW_ADDR;
> + dfu->data.sf.start = 0;
> + dfu->data.sf.size = dfu->data.sf.dev->size;
>   } else if (CONFIG_IS_ENABLED(DFU_SF_PART) &&
>  (!strcmp(st, "part") || !strcmp(st, "partubi"))) {
>   char mtd_id[32];

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

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


pgpeaERE9_BhW.pgp
Description: OpenPGP digital signature

Re: [PATCH] dfu: dfu_sf: Read the SPI flash in 16 MiB chunks

2021-09-14 Thread Lukasz Majewski

On Tue, 14 Sep 2021 05:26:51 +0200
Marek Vasut  wrote:

> Not all SPI flashes and controllers can do continuous transfer longer
> than 16 MiB, so perform the DFU read in 16 MiB chunks.
> 
> Signed-off-by: Marek Vasut 
> Cc: Lukasz Majewski 
> ---
>  drivers/dfu/dfu_sf.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
> index 7e64ab772f0..b72493ced86 100644
> --- a/drivers/dfu/dfu_sf.c
> +++ b/drivers/dfu/dfu_sf.c
> @@ -24,8 +24,18 @@ static int dfu_get_medium_size_sf(struct
> dfu_entity *dfu, u64 *size) static int dfu_read_medium_sf(struct
> dfu_entity *dfu, u64 offset, void *buf, long *len)
>  {
> - return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
> offset,
> - *len, buf);
> + long seglen = *len;
> + int ret;
> +
> + if (seglen > (16 << 20))
> + seglen = (16 << 20);
> +
> + ret = spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
> offset,
> + seglen, buf);
> + if (!ret)
> + *len = seglen;
> +
> + return ret;
>  }
>  
>  static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

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


pgpxjuQjlsleu.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 6/6] net: dsa: felix: propagate the error code from phy_startup()

2021-09-14 Thread Ramon Fried

On Tue, Aug 24, 2021 at 3:01 PM Vladimir Oltean  wrote:
>
> Make sure that the link status returned by phy_startup() is propagated
> to the .start() method of struct eth_ops.
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> Tested-by: Michael Walle 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index c8ecf4f19442..6aa79784460d 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -352,9 +352,7 @@ static int felix_port_enable(struct udevice *dev, int 
> port,
>  FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
>  FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
>
> -   phy_startup(phy);
> -
> -   return 0;
> +   return phy_startup(phy);
>  }
>
>  static void felix_port_disable(struct udevice *dev, int pidx,
> --
> 2.25.1
>
Applied to u-boot-net/network-master
Thanks,
Ramon.

Re: [PATCH v2 4/6] net: dsa: introduce a .port_probe() method in struct dsa_ops

2021-09-14 Thread Ramon Fried

On Tue, Aug 24, 2021 at 3:01 PM Vladimir Oltean  wrote:
>
> Some drivers might want to execute code for each port at probe time, as
> opposed to executing code just-in-time for the port selected for
> networking.
>
> To cater to that use case, introduce a .port_probe() callback method
> into the DSA switch operations which is called for each available port,
> at the end of dsa_port_probe().
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> Tested-by: Michael Walle 
> ---
>  include/net/dsa.h | 5 -
>  net/dsa-uclass.c  | 8 
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 0f31a908c9d1..ab2a9dfbea2d 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -57,7 +57,8 @@
>  /**
>   * struct dsa_ops - DSA operations
>   *
> - * @port_enable:  Initialize a switch port for I/O.
> + * @port_probe:   Initialize a switch port.
> + * @port_enable:  Enable I/O for a port.
>   * @port_disable: Disable I/O for a port.
>   * @xmit: Insert the DSA tag for transmission.
>   *DSA drivers receive a copy of the packet with headroom and
> @@ -69,6 +70,8 @@
>   *master including any additional headers.
>   */
>  struct dsa_ops {
> +   int (*port_probe)(struct udevice *dev, int port,
> + struct phy_device *phy);
> int (*port_enable)(struct udevice *dev, int port,
>struct phy_device *phy);
> void (*port_disable)(struct udevice *dev, int port,
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index dbd8558b6486..9b8ae1e82b92 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -270,6 +270,7 @@ static void dsa_port_set_hwaddr(struct udevice *pdev, 
> struct udevice *master)
>  static int dsa_port_probe(struct udevice *pdev)
>  {
> struct udevice *dev = dev_get_parent(pdev);
> +   struct dsa_ops *ops = dsa_get_ops(dev);
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> @@ -299,6 +300,13 @@ static int dsa_port_probe(struct udevice *pdev)
>
> dsa_port_set_hwaddr(pdev, master);
>
> +   if (ops->port_probe) {
> +   err = ops->port_probe(dev, port_pdata->index,
> + port_pdata->phy);
> +   if (err)
> +   return err;
> +   }
> +
> return 0;
>  }
>
> --
> 2.25.1
>
Applied to u-boot-net/network-master
Thanks,
Ramon.

Re: [PATCH v2 3/6] net: dsa: refactor the code to set the port MAC address into a dedicated function

2021-09-14 Thread Ramon Fried

On Tue, Aug 24, 2021 at 3:01 PM Vladimir Oltean  wrote:
>
> This snippet of code has a bothering "if (...) return 0" in it which
> assumes it is the last piece of code running in dsa_port_probe().
>
> This makes it difficult to add further code at the end of dsa_port_probe()
> which does not depend on MAC address stuff.
>
> So move the code to a dedicated function which returns void and let the
> code flow through.
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> Tested-by: Michael Walle 
> ---
>  net/dsa-uclass.c | 50 +++-
>  1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index f279ca7d2d6c..dbd8558b6486 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -240,11 +240,36 @@ static const struct eth_ops dsa_port_ops = {
> .free_pkt   = dsa_port_free_pkt,
>  };
>
> -static int dsa_port_probe(struct udevice *pdev)
> +/*
> + * Inherit port's hwaddr from the DSA master, unless the port already has a
> + * unique MAC address specified in the environment.
> + */
> +static void dsa_port_set_hwaddr(struct udevice *pdev, struct udevice *master)
>  {
> -   struct udevice *dev = dev_get_parent(pdev);
> struct eth_pdata *eth_pdata, *master_pdata;
> unsigned char env_enetaddr[ARP_HLEN];
> +
> +   eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
> +   if (!is_zero_ethaddr(env_enetaddr)) {
> +   /* individual port mac addrs require master to be promisc */
> +   struct eth_ops *eth_ops = eth_get_ops(master);
> +
> +   if (eth_ops->set_promisc)
> +   eth_ops->set_promisc(master, 1);
> +
> +   return;
> +   }
> +
> +   master_pdata = dev_get_plat(master);
> +   eth_pdata = dev_get_plat(pdev);
> +   memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
> +   eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
> + master_pdata->enetaddr);
> +}
> +
> +static int dsa_port_probe(struct udevice *pdev)
> +{
> +   struct udevice *dev = dev_get_parent(pdev);
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> @@ -272,26 +297,7 @@ static int dsa_port_probe(struct udevice *pdev)
> if (err)
> return err;
>
> -   /*
> -* Inherit port's hwaddr from the DSA master, unless the port already
> -* has a unique MAC address specified in the environment.
> -*/
> -   eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
> -   if (!is_zero_ethaddr(env_enetaddr)) {
> -   /* individual port mac addrs require master to be promisc */
> -   struct eth_ops *eth_ops = eth_get_ops(master);
> -
> -   if (eth_ops->set_promisc)
> -   eth_ops->set_promisc(master, 1);
> -
> -   return 0;
> -   }
> -
> -   master_pdata = dev_get_plat(master);
> -   eth_pdata = dev_get_plat(pdev);
> -   memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
> -   eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
> - master_pdata->enetaddr);
> +   dsa_port_set_hwaddr(pdev, master);
>
> return 0;
>  }
> --
> 2.25.1
>
Applied to u-boot-net/network-master
Thanks,
Ramon.

Re: [PATCH v2 2/6] net: dsa: use "err" instead of "ret" in dsa_port_probe

2021-09-14 Thread Ramon Fried

On Tue, Aug 24, 2021 at 3:01 PM Vladimir Oltean  wrote:
>
> DM DSA uses "err" for error code values, so use this consistently.
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> Tested-by: Michael Walle 
> ---
>  net/dsa-uclass.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 694664d81bbb..f279ca7d2d6c 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -248,7 +248,7 @@ static int dsa_port_probe(struct udevice *pdev)
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> -   int ret;
> +   int err;
>
> port_pdata = dev_get_parent_plat(pdev);
> dsa_priv = dev_get_uclass_priv(dev);
> @@ -268,9 +268,9 @@ static int dsa_port_probe(struct udevice *pdev)
>  * TODO: we assume the master device is always there and doesn't get
>  * removed during runtime.
>  */
> -   ret = device_probe(master);
> -   if (ret)
> -   return ret;
> +   err = device_probe(master);
> +   if (err)
> +   return err;
>
> /*
>  * Inherit port's hwaddr from the DSA master, unless the port already
> --
> 2.25.1
>
Applied to u-boot-net/network-master
Thanks,
Ramon.

Re: [PATCH v2 1/6] net: dsa: felix: felix_init() can be static

2021-09-14 Thread Ramon Fried

On Tue, Aug 24, 2021 at 3:01 PM Vladimir Oltean  wrote:
>
> No one is calling this function from outside felix_switch.c.
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> Tested-by: Michael Walle 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index f20e84e0f10c..75073880cf87 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -233,7 +233,7 @@ static void felix_start_pcs(struct udevice *dev, int port,
> }
>  }
>
> -void felix_init(struct udevice *dev)
> +static void felix_init(struct udevice *dev)
>  {
> struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
> struct felix_priv *priv = dev_get_priv(dev);
> --
> 2.25.1
>
Applied to u-boot-net/network-master
Thanks,
Ramon.

Re: [PATCH] Allow colon in PXE bootfile URLs

2021-09-14 Thread Ramon Fried

On Tue, Sep 14, 2021 at 12:13 PM Ramon Fried  wrote:
>
> On Sun, Aug 15, 2021 at 5:09 PM Lyle Franklin  wrote:
> >
> > From: Lyle Franklin 
> > Date: Sun, 15 Aug 2021 07:17:14 -0400
> > Subject: [PATCH] Allow colon in PXE bootfile URLs
> >
> > - U-boot's PXE flow supports prefixing your bootfile name with an
> >   IP address to fetch from a server other than the DHCP server,
> >   e.g. `hostIPaddr:bootfilename`:
> >
> > https://github.com/u-boot/u-boot/commit/a93907c43f847f076dd0e34ee3b69b5e8e6d0d29
> > - However, this breaks bootfile paths which contain a colon, e.g.
> >   `f0:ad:4e:10:1b:87/7/pxelinux.cfg/default`
> > - This patch checks whether the `hostIPaddr` prefix is a valid
> >   IP address before overriding the serverIP otherwise the whole
> >   bootfile path is preserved
> >
> > Signed-off-by: Lyle Franklin 
> > ---
> >  net/net.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/net.c b/net/net.c
> > index c2992a0908..30fc0a29d7 100644
> > --- a/net/net.c
> > +++ b/net/net.c
> > @@ -1540,14 +1540,18 @@ int is_serverip_in_cmd(void)
> >  int net_parse_bootfile(struct in_addr *ipaddr, char *filename, int max_len)
> >  {
> >   char *colon;
> > + struct in_addr ip;
> >
> >   if (net_boot_file_name[0] == '\0')
> >   return 0;
> >
> >   colon = strchr(net_boot_file_name, ':');
> >   if (colon) {
> > - if (ipaddr)
> > - *ipaddr = string_to_ip(net_boot_file_name);
> > + ip = string_to_ip(net_boot_file_name);
> > + if (ipaddr && ip.s_addr)
> > + *ipaddr = ip;
> > + }
> > + if (ip.s_addr) {
> >   strncpy(filename, colon + 1, max_len);
> >   } else {
> >   strncpy(filename, net_boot_file_name, max_len);
> > --
> > 2.31.1
> Reviewed-by: Ramon Fried 

Patch doesn't apply, please rebase and resend.
Additionally, it looks like there is wrong indentation, please check
patch with checkpatch before resubmitting
Thanks,
Ramon

Re: [PATCH] Allow colon in PXE bootfile URLs

2021-09-14 Thread Ramon Fried

On Sun, Aug 15, 2021 at 5:09 PM Lyle Franklin  wrote:
>
> From: Lyle Franklin 
> Date: Sun, 15 Aug 2021 07:17:14 -0400
> Subject: [PATCH] Allow colon in PXE bootfile URLs
>
> - U-boot's PXE flow supports prefixing your bootfile name with an
>   IP address to fetch from a server other than the DHCP server,
>   e.g. `hostIPaddr:bootfilename`:
>
> https://github.com/u-boot/u-boot/commit/a93907c43f847f076dd0e34ee3b69b5e8e6d0d29
> - However, this breaks bootfile paths which contain a colon, e.g.
>   `f0:ad:4e:10:1b:87/7/pxelinux.cfg/default`
> - This patch checks whether the `hostIPaddr` prefix is a valid
>   IP address before overriding the serverIP otherwise the whole
>   bootfile path is preserved
>
> Signed-off-by: Lyle Franklin 
> ---
>  net/net.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index c2992a0908..30fc0a29d7 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1540,14 +1540,18 @@ int is_serverip_in_cmd(void)
>  int net_parse_bootfile(struct in_addr *ipaddr, char *filename, int max_len)
>  {
>   char *colon;
> + struct in_addr ip;
>
>   if (net_boot_file_name[0] == '\0')
>   return 0;
>
>   colon = strchr(net_boot_file_name, ':');
>   if (colon) {
> - if (ipaddr)
> - *ipaddr = string_to_ip(net_boot_file_name);
> + ip = string_to_ip(net_boot_file_name);
> + if (ipaddr && ip.s_addr)
> + *ipaddr = ip;
> + }
> + if (ip.s_addr) {
>   strncpy(filename, colon + 1, max_len);
>   } else {
>   strncpy(filename, net_boot_file_name, max_len);
> --
> 2.31.1
Reviewed-by: Ramon Fried

Re: [PATCH v6 4/4] configs: enable SYSRESET_SBI on qemu-riscvXX_smode_defconfig

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 09:11:47PM +0200, Heinrich Schuchardt wrote:
> There should be a platform compiled with the new driver.
>
> Enable CONFIG_SYSRESET_SBI for all QEMU boards using SBI.
>
> If you want to test the SBI sysreset driver, disable
> CONFIG_SYSRESET_SYSCON.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v6:
>   enable CONFIG_SYSRESET_SBI on qemu-riscvXX_spl_defconfig, too
> v5:
>   new patch
> ---
>  configs/qemu-riscv32_smode_defconfig | 1 +
>  configs/qemu-riscv32_spl_defconfig   | 1 +
>  configs/qemu-riscv64_smode_defconfig | 1 +
>  configs/qemu-riscv64_spl_defconfig   | 1 +
>  4 files changed, 4 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH v2 3/4] test: dm: k210: Reduce duplication in test cases

2021-09-14 Thread Leo Liang

On Sat, Sep 11, 2021 at 01:20:02PM -0400, Sean Anderson wrote:
> Having to copy-paste the same 3 lines makes adding new test cases
> error-prone. Use a macro.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  test/dm/k210_pll.c | 30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)
>
Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH v2 2/4] k210: clk: Refactor out_of_spec tests

2021-09-14 Thread Leo Liang

On Sat, Sep 11, 2021 at 01:20:01PM -0400, Sean Anderson wrote:
> Everything here sits in a while (true) loop. However, this introduces a
> couple of layers of indentation. We can simplify the code by introducing a
> single goto instead of using continue/break. This will also make adding
> loops in the next patch easier.
>
> Signed-off-by: Sean Anderson 
> ---
>
> (no changes since v1)
>
>  drivers/clk/clk_kendryte.c | 105 ++---
>  1 file changed, 52 insertions(+), 53 deletions(-)
>

Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH v2 1/4] clk: k210: Fix checking if ulongs are less than 0

2021-09-14 Thread Leo Liang

On Sat, Sep 11, 2021 at 01:20:00PM -0400, Sean Anderson wrote:
> The PLL functions take ulong arguments for rate, but still check if that
> rate is negative (which is never true). The correct way to handle this is
> to use IS_ERR_VALUE (like is already done in k210_clk_set_rate). While
> we're at it, we can move the error checking up into the caller of the pll
> set/get rate functions.  This also protects our other calculations from
> using bogus values for rate.
>
> Fixes: 609bd60b94 ("clk: k210: Rewrite to remove CCF")
> Reported-by: Coverity Scan 
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - Reworked patch to use IS_ERR_VALUE instead of changing arguments to long
>
>  drivers/clk/clk_kendryte.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH 5/6] arm: Remove edminiv2 board and orion5x support

2021-09-14 Thread Simon Guinot

Hi Stefan and Tom,

I finally managed to find a Disk Mini v2 Ethernet card and I will be
working on the DM conversion as soon as possible.

Please, let me know what is my deadline to complete this job ?

Simon

On Fri, Sep 10, 2021 at 06:41:14AM +0200, Stefan Roese wrote:
> Hi Simon,
> 
> On 10.09.21 00:54, Simon Guinot wrote:
> > On Thu, Sep 09, 2021 at 02:05:29PM +0200, Stefan Roese wrote:
> > > On 09.09.21 13:54, Tom Rini wrote:
> > > > This board has not been converted to CONFIG_DM by the deadline.
> > > > Remove it.  As this is the last orion5x platform, remove that support as
> > > > well.
> > > > 
> > > > Cc: Albert ARIBAUD 
> > > > Cc: Stefan Roese 
> > > > Signed-off-by: Tom Rini 
> > > > ---
> > > >arch/arm/Kconfig  |   7 -
> > > >arch/arm/Makefile |   1 -
> > > >arch/arm/include/asm/arch-orion5x/spl.h   |   9 -
> > > >arch/arm/mach-orion5x/Kconfig |  18 --
> > > >arch/arm/mach-orion5x/Makefile|  26 --
> > > >arch/arm/mach-orion5x/cpu.c   | 298 
> > > > --
> > > >arch/arm/mach-orion5x/dram.c  |  58 
> > > >arch/arm/mach-orion5x/include/mach/cpu.h  | 242 --
> > > >.../arm/mach-orion5x/include/mach/mv88f5182.h |  23 --
> > > >arch/arm/mach-orion5x/include/mach/orion5x.h  |  66 
> > > >arch/arm/mach-orion5x/lowlevel_init.S | 286 -
> > > >arch/arm/mach-orion5x/timer.c | 174 --
> > > >arch/arm/mach-orion5x/u-boot-spl.lds  |  60 
> > > 
> > > If nobody steps up to start / continue maintaining orion5, then:
> > 
> > Hi,
> > 
> > It would be a shame to remove the whole Orion support.
> > 
> > If you can wait until this week-end, I'll look into my boxes if I can
> > find an Ethernet Disk mini v2.
> > 
> > If it is the case, I'll do the CONFIG_DM conversion.
> 
> Thanks Simon, that would be great.
> 
> Thanks,
> Stefan


signature.asc
Description: PGP signature

Re: [PATCH] riscv: image: Use the first DRAM bank for bootm_low

2021-09-14 Thread Leo Liang

On Sun, Sep 12, 2021 at 11:26:45AM -0500, Samuel Holland wrote:
> bootm_low is used as a base address is used to allocate space for the
> FDT blob, initrd, cmdline, etc. when booting Linux. Set the default
> value for RISC-V to the start of the first DRAM bank, so platforms can
> get their DRAM layout from the device tree, and do not need to define
> CONFIG_SYS_SDRAM_BASE.
>
> Signed-off-by: Samuel Holland 
> ---
>
>  common/image.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang 
CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein is strictly 
prohibited. In this case, please immediately notify the sender by return 
e-mail, delete the message (and any accompanying documents) and destroy all 
printed hard copies. Thank you for your cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

1 2 >

1 - 100 of 103 matches

Mail list logo