date:20221103

From: Jassi Brar 

The common code can now read, verify and fix meta-data copies
while exposing one consistent structure to users.
 Only the .read_mdata() and .write_mdata() callbacks of fwu_mdata_ops
are needed. Get rid of .get_mdata() .update_mdata() .get_mdata_part_num()
.read_mdata_partition() and .write_mdata_partition() and also the
corresponding wrapper functions.

Signed-off-by: Jassi Brar 
---
 cmd/fwu_mdata.c  |  17 +-
 drivers/fwu-mdata/fwu-mdata-uclass.c | 165 ---
 drivers/fwu-mdata/gpt_blk.c  | 124 +-
 include/fwu.h| 199 ---
 lib/fwu_updates/fwu.c| 235 ---
 5 files changed, 38 insertions(+), 702 deletions(-)

diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index f04af27de6..9b70340368 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -43,23 +43,10 @@ static void print_mdata(struct fwu_mdata *mdata)
 int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
 int argc, char * const argv[])
 {
-   struct udevice *dev;
int ret = CMD_RET_SUCCESS, res;
-   struct fwu_mdata mdata = { 0 };
+   struct fwu_mdata mdata;
 
-   if (uclass_get_device(UCLASS_FWU_MDATA, 0, &dev) || !dev) {
-   log_err("Unable to get FWU metadata device\n");
-   return CMD_RET_FAILURE;
-   }
-
-   res = fwu_check_mdata_validity();
-   if (res < 0) {
-   log_err("FWU Metadata check failed\n");
-   ret = CMD_RET_FAILURE;
-   goto out;
-   }
-
-   res = fwu_get_mdata(dev, &mdata);
+   res = fwu_get_verified_mdata(&mdata);
if (res < 0) {
log_err("Unable to get valid FWU metadata\n");
ret = CMD_RET_FAILURE;
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
index ded9902971..8190113843 100644
--- a/drivers/fwu-mdata/fwu-mdata-uclass.c
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -14,7 +14,6 @@
 
 #include 
 #include 
-#include 
 
 /**
  * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
@@ -50,170 +49,6 @@ int fwu_write_mdata(struct udevice *dev, struct fwu_mdata 
*mdata, bool primary);
return ops->write_mdata(dev, mdata, primary);
 }
 
-/**
- * fwu_get_mdata_part_num() - Get the FWU metadata partition numbers
- * @dev: FWU metadata device
- * @mdata_parts: array for storing the metadata partition numbers
- *
- * Get the partition numbers on the storage device on which the
- * FWU metadata is stored. Two partition numbers will be returned.
- *
- * Return: 0 if OK, -ve on error
- *
- */
-int fwu_get_mdata_part_num(struct udevice *dev, uint *mdata_parts)
-{
-   const struct fwu_mdata_ops *ops = device_get_ops(dev);
-
-   if (!ops->get_mdata_part_num) {
-   log_debug("get_mdata_part_num() method not defined\n");
-   return -ENOSYS;
-   }
-
-   return ops->get_mdata_part_num(dev, mdata_parts);
-}
-
-/**
- * fwu_read_mdata_partition() - Read the FWU metadata from a partition
- * @dev: FWU metadata device
- * @mdata: Copy of the FWU metadata
- * @part_num: Partition number from which FWU metadata is to be read
- *
- * Read the FWU metadata from the specified partition number
- *
- * Return: 0 if OK, -ve on error
- *
- */
-int fwu_read_mdata_partition(struct udevice *dev, struct fwu_mdata *mdata,
-uint part_num)
-{
-   const struct fwu_mdata_ops *ops = device_get_ops(dev);
-
-   if (!ops->read_mdata_partition) {
-   log_debug("read_mdata_partition() method not defined\n");
-   return -ENOSYS;
-   }
-
-   return ops->read_mdata_partition(dev, mdata, part_num);
-}
-
-/**
- * fwu_write_mdata_partition() - Write the FWU metadata to a partition
- * @dev: FWU metadata device
- * @mdata: Copy of the FWU metadata
- * @part_num: Partition number to which FWU metadata is to be written
- *
- * Write the FWU metadata to the specified partition number
- *
- * Return: 0 if OK, -ve on error
- *
- */
-int fwu_write_mdata_partition(struct udevice *dev, struct fwu_mdata *mdata,
- uint part_num)
-{
-   const struct fwu_mdata_ops *ops = device_get_ops(dev);
-
-   if (!ops->write_mdata_partition) {
-   log_debug("write_mdata_partition() method not defined\n");
-   return -ENOSYS;
-   }
-
-   return ops->write_mdata_partition(dev, mdata, part_num);
-}
-
-/**
- * fwu_mdata_check() - Check if the FWU metadata is valid
- * @dev: FWU metadata device
- *
- * Validate both copies of the FWU metadata. If one of the copies
- * has gone bad, restore it from the other copy.
- *
- * Return: 0 if OK, -ve on error
- *
- */
-int fwu_mdata_check(struct udevice *dev)
-{
-   const struct fwu_mdata_ops *ops = device_get_ops(dev);
-
-   if (!ops->check_mdata) {
-   log_debug("check_mdata() method not defined\n");
-

[PATCH 3/4] fwu: gpt: implement read_mdata and write_mdata callbacks

From: Jassi Brar 

Moving towards using common code for meta-data management,
implement the read/write mdata hooks.

Signed-off-by: Jassi Brar 
---
 drivers/fwu-mdata/gpt_blk.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/fwu-mdata/gpt_blk.c b/drivers/fwu-mdata/gpt_blk.c
index d706e3d4e4..7fda041302 100644
--- a/drivers/fwu-mdata/gpt_blk.c
+++ b/drivers/fwu-mdata/gpt_blk.c
@@ -272,7 +272,43 @@ static int fwu_mdata_gpt_blk_probe(struct udevice *dev)
return 0;
 }
 
+static int fwu_gpt_read_mdata(struct udevice *dev, struct fwu_mdata *mdata,
+bool primary)
+{
+   struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
+   struct blk_desc *desc = dev_get_uclass_plat(priv->blk_dev);
+   int ret;
+
+   ret = gpt_get_mdata_partitions(desc);
+   if (ret < 0) {
+   log_debug("Error getting the FWU metadata partitions\n");
+   return -ENOENT;
+   }
+
+   return gpt_read_write_mdata(desc, mdata, MDATA_READ,
+   primary ? g_mdata_part[0] : 
g_mdata_part[1]);
+}
+
+static int fwu_gpt_write_mdata(struct udevice *dev, struct fwu_mdata *mdata,
+bool primary)
+{
+   struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
+   struct blk_desc *desc = dev_get_uclass_plat(priv->blk_dev);
+   int ret;
+
+   ret = gpt_get_mdata_partitions(desc);
+   if (ret < 0) {
+   log_debug("Error getting the FWU metadata partitions\n");
+   return -ENOENT;
+   }
+
+   return gpt_read_write_mdata(desc, mdata, MDATA_WRITE,
+   primary ? g_mdata_part[0] : 
g_mdata_part[1]);
+}
+
 static const struct fwu_mdata_ops fwu_gpt_blk_ops = {
+   .read_mdata = fwu_gpt_read_mdata,
+   .write_mdata = fwu_gpt_write_mdata,
.get_mdata = fwu_gpt_get_mdata,
.update_mdata = fwu_gpt_update_mdata,
.get_mdata_part_num = fwu_gpt_get_mdata_partitions,
-- 
2.25.1

[PATCH 2/4] fwu: move meta-data management in core

From: Jassi Brar 

Instead of each i/f having to implement their own meta-data verification
and storage, move the logic in common code. This simplifies the i/f code
much simpler and compact.

Signed-off-by: Jassi Brar 
---
 drivers/fwu-mdata/fwu-mdata-uclass.c |  34 +++
 include/fwu.h|  41 
 lib/fwu_updates/fwu.c| 136 ++-
 3 files changed, 207 insertions(+), 4 deletions(-)

diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
index b477e9603f..ded9902971 100644
--- a/drivers/fwu-mdata/fwu-mdata-uclass.c
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -16,6 +16,40 @@
 #include 
 #include 
 
+/**
+ * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int fwu_read_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool primary);
+{
+   const struct fwu_mdata_ops *ops = device_get_ops(dev);
+
+   if (!ops->read_mdata) {
+   log_debug("read_mdata() method not defined\n");
+   return -ENOSYS;
+   }
+
+   return ops->read_mdata(dev, mdata, primary);
+}
+
+/**
+ * fwu_write_mdata() - Wrapper around fwu_mdata_ops.write_mdata()
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int fwu_write_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool 
primary);
+{
+   const struct fwu_mdata_ops *ops = device_get_ops(dev);
+
+   if (!ops->write_mdata) {
+   log_debug("write_mdata() method not defined\n");
+   return -ENOSYS;
+   }
+
+   return ops->write_mdata(dev, mdata, primary);
+}
+
 /**
  * fwu_get_mdata_part_num() - Get the FWU metadata partition numbers
  * @dev: FWU metadata device
diff --git a/include/fwu.h b/include/fwu.h
index 0919ced812..1a700c9e6a 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -24,6 +24,26 @@ struct fwu_mdata_gpt_blk_priv {
  * @update_mdata() - Update the FWU metadata copy
  */
 struct fwu_mdata_ops {
+   /**
+* read_mdata() - Populate the asked FWU metadata copy
+* @dev: FWU metadata device
+* @mdata: Copy of the FWU metadata
+* @primary: If primary or secondary copy of meta-data is to be read
+*
+* Return: 0 if OK, -ve on error
+*/
+   int (*read_mdata)(struct udevice *dev, struct fwu_mdata *mdata, bool 
primary);
+
+   /**
+* write_mdata() - Write the given FWU metadata copy
+* @dev: FWU metadata device
+* @mdata: Copy of the FWU metadata
+* @primary: If primary or secondary copy of meta-data is to be written
+*
+* Return: 0 if OK, -ve on error
+*/
+   int (*write_mdata)(struct udevice *dev, struct fwu_mdata *mdata, bool 
primary);
+
/**
 * check_mdata() - Check if the FWU metadata is valid
 * @dev:FWU device
@@ -126,6 +146,27 @@ struct fwu_mdata_ops {
EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
 
+/**
+ * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
+ */
+int fwu_read_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool primary);
+
+/**
+ * fwu_write_mdata() - Wrapper around fwu_mdata_ops.write_mdata()
+ */
+int fwu_write_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool 
primary);
+
+/**
+ * fwu_get_verified_mdata() - Read, verify and return the FWU metadata
+ *
+ * Read both the metadata copies from the storage media, verify their checksum,
+ * and ascertain that both copies match. If one of the copies has gone bad,
+ * restore it from the good copy.
+ *
+ * Return: 0 if OK, -ve on error
+*/
+int fwu_get_verified_mdata(struct fwu_mdata *mdata);
+
 /**
  * fwu_check_mdata_validity() - Check for validity of the FWU metadata copies
  *
diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index 5313d07302..3d51b91ed5 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -15,13 +15,13 @@
 #include 
 #include 
 
+#include 
+
+static struct fwu_mdata g_mdata = { 0 };
+static struct udevice *g_dev;
 static u8 in_trial;
 static u8 boottime_check;
 
-#include 
-#include 
-#include 
-
 enum {
IMAGE_ACCEPT_SET = 1,
IMAGE_ACCEPT_CLEAR,
@@ -161,6 +161,134 @@ static int fwu_get_image_type_id(u8 *image_index, 
efi_guid_t *image_type_id)
return -ENOENT;
 }
 
+/**
+ * fwu_sync_mdata() - Update given meta-data partition(s) with the copy 
provided
+ * @mdata: FWU metadata structure
+ * @part: Bitmask of FWU metadata partitions to be written to
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static int fwu_sync_mdata(struct fwu_mdata *mdata, int part)
+{
+   void *buf = &mdata->version;
+   int err = 0;
+
+   /*
+* Calculate the crc32 for the updated FWU metadata
+* and put the updated value in the FWU metadata crc32
+* field
+*/
+   mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
+
+   if (part & PRIMARY_PART)
+

[PATCH 1/4] fwu: gpt: use cached meta-data partition numbers

From: Jassi Brar 

Use cached values and avoid parsing and scanning through partitions
everytime for meta-data partitions because they can't change after bootup.

Signed-off-by: Jassi Brar 
---
 drivers/fwu-mdata/gpt_blk.c | 43 +
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/fwu-mdata/gpt_blk.c b/drivers/fwu-mdata/gpt_blk.c
index d35ce49c5c..d706e3d4e4 100644
--- a/drivers/fwu-mdata/gpt_blk.c
+++ b/drivers/fwu-mdata/gpt_blk.c
@@ -24,8 +24,9 @@ enum {
MDATA_WRITE,
 };
 
-static int gpt_get_mdata_partitions(struct blk_desc *desc,
-   uint mdata_parts[2])
+static uint g_mdata_part[2] = {0, 0};
+
+static int gpt_get_mdata_partitions(struct blk_desc *desc)
 {
int i, ret;
u32 nparts;
@@ -33,18 +34,19 @@ static int gpt_get_mdata_partitions(struct blk_desc *desc,
struct disk_partition info;
const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
 
+   /* if primary and secondary partitons already found */
+   if (g_mdata_part[0] && g_mdata_part[1])
+   return 0;
+
nparts = 0;
-   for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
+   for (i = 1; i < MAX_SEARCH_PARTITIONS && nparts < 2; i++) {
if (part_get_info(desc, i, &info))
continue;
uuid_str_to_bin(info.type_guid, part_type_guid.b,
UUID_STR_FORMAT_GUID);
 
-   if (!guidcmp(&fwu_mdata_guid, &part_type_guid)) {
-   if (nparts < 2)
-   mdata_parts[nparts] = i;
-   ++nparts;
-   }
+   if (!guidcmp(&fwu_mdata_guid, &part_type_guid))
+   g_mdata_part[nparts++] = i;
}
 
if (nparts != 2) {
@@ -127,26 +129,25 @@ static int fwu_gpt_update_mdata(struct udevice *dev, 
struct fwu_mdata *mdata)
 {
int ret;
struct blk_desc *desc;
-   uint mdata_parts[2];
struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
 
desc = dev_get_uclass_plat(priv->blk_dev);
 
-   ret = gpt_get_mdata_partitions(desc, mdata_parts);
+   ret = gpt_get_mdata_partitions(desc);
if (ret < 0) {
log_debug("Error getting the FWU metadata partitions\n");
return -ENOENT;
}
 
/* First write the primary partition */
-   ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, mdata_parts[0]);
+   ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, g_mdata_part[0]);
if (ret < 0) {
log_debug("Updating primary FWU metadata partition failed\n");
return ret;
}
 
/* And now the replica */
-   ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, mdata_parts[1]);
+   ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, g_mdata_part[1]);
if (ret < 0) {
log_debug("Updating secondary FWU metadata partition failed\n");
return ret;
@@ -158,16 +159,14 @@ static int fwu_gpt_update_mdata(struct udevice *dev, 
struct fwu_mdata *mdata)
 static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata *mdata)
 {
int ret;
-   uint mdata_parts[2];
-
-   ret = gpt_get_mdata_partitions(desc, mdata_parts);
 
+   ret = gpt_get_mdata_partitions(desc);
if (ret < 0) {
log_debug("Error getting the FWU metadata partitions\n");
return -ENOENT;
}
 
-   ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, mdata_parts[0]);
+   ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, g_mdata_part[0]);
if (ret < 0) {
log_debug("Failed to read the FWU metadata from the device\n");
return -EIO;
@@ -182,7 +181,7 @@ static int gpt_get_mdata(struct blk_desc *desc, struct 
fwu_mdata *mdata)
 * Try to read the replica.
 */
memset(mdata, '\0', sizeof(struct fwu_mdata));
-   ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, mdata_parts[1]);
+   ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, g_mdata_part[1]);
if (ret < 0) {
log_debug("Failed to read the FWU metadata from the device\n");
return -EIO;
@@ -206,9 +205,15 @@ static int fwu_gpt_get_mdata(struct udevice *dev, struct 
fwu_mdata *mdata)
 static int fwu_gpt_get_mdata_partitions(struct udevice *dev, uint *mdata_parts)
 {
struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
+   int err;
+
+   err = gpt_get_mdata_partitions(dev_get_uclass_plat(priv->blk_dev));
+   if (!err) {
+   mdata_parts[0] = g_mdata_part[0];
+   mdata_parts[1] = g_mdata_part[1];
+   }
 
-   return gpt_get_mdata_partitions(dev_get_uclass_plat(priv->blk_dev),
-   mdata_parts);
+   return err;
 }
 
 static int fwu_gpt_read_mdata_partition(struct udevice *dev,
-- 
2.2

[PATCH 0/4] FWU: Handle meta-data in common code

From: Jassi Brar 

Hi,
   The patchset reduces 400 lines of code, while keeping the functionality same 
and making
meta-data operations much faster (by using cached structures).

Issue:
 meta-data copies (primary and secondary) are being handled by the 
backend/storage layer
instead of the common core in fwu.c (as also noted by Ilias)  that is, 
gpt_blk.c manages
meta-data and similarly raw_mtd.c will have to do the same when it arrives. The 
code
could by make smaller, cleaner and optimised.

Basic idea:
 Introduce  .read_mdata() and .write_mdata() in fwu_mdata_ops  that simply 
read/write
meta-data copy. The core code takes care of integrity and redundancy of the 
meta-data,
as a result we can get rid of every other callback .get_mdata() .update_mdata()
.get_mdata_part_num()  .read_mdata_partition()  .write_mdata_partition() and the
corresponding wrapper functions thereby making the code 100s of LOC smaller.

Get rid of fwu_check_mdata_validity() and fwu_mdata_check() which expected 
underlying
layer to manage and verify mdata copies.
Implement  fwu_get_verified_mdata(struct fwu_mdata *mdata) public function that 
reads,
verifies and, if needed, fixes the meta-data copies.

Verified copy of meta-data is now cached as 'g_mdata' in fwu.c, which avoids 
multiple
low-level expensive read and parse calls.
gpt meta-data partition numbers are now cached in gpt_blk.c, so that we don't 
have to do expensive part_get_info() and uid ops.

Jassi Brar (4):
  fwu: gpt: use cached meta-data partition numbers
  fwu: move meta-data management in core
  fwu: gpt: implement read_mdata and write_mdata callbacks
  fwu: meta-data: switch to management by common code

 cmd/fwu_mdata.c  |  17 +-
 drivers/fwu-mdata/fwu-mdata-uclass.c | 151 +-
 drivers/fwu-mdata/gpt_blk.c  | 175 +
 include/fwu.h| 198 ++-
 lib/fwu_updates/fwu.c| 283 +++
 5 files changed, 202 insertions(+), 622 deletions(-)

-- 
2.25.1

Re: [PULL] u-boot-riscv/master

2022-11-03 Thread Leo Liang

Hi Tom,

On Thu, Nov 03, 2022 at 12:57:05PM -0400, Tom Rini wrote:
> On Thu, Nov 03, 2022 at 07:04:33AM +, Leo Liang wrote:
> 
> > Hi Tom, 
> > 
> > The following changes since commit c8d9ff634fc429db5acf2f5386ea937f0fef1ae7:
> > 
> >   Merge branch '2022-10-31-FWU-add-FWU-multi-bank-update-feature-support' 
> > (2022-11-01 09:32:21 -0400)
> > 
> > are available in the Git repository at:
> > 
> >   https://source.denx.de/u-boot/custodians/u-boot-riscv.git
> 
> Can you please start including a few line summary of the changes in your
> pull requests?
> 

Sorry for not including any summary before,
will for sure summarize the PRs in the pull requests.

> > 
> > for you to fetch changes up to 7321bad25f18684b53cff4346543fb2da2a2c0d0:
> > 
> >   riscv: Update Microchip MPFS Icicle Kit support (2022-11-03 13:27:56 
> > +0800)
> > 
> > CI result shows no issue: 
> > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/13999
> > 
> 
> Applied to u-boot/master, thanks!
> 
> -- 
> Tom

Best regards,
Leo

[PATCH 5/8] arm: mach-k3: introduce basic files to support the am62a

Introduce the mach-k3 files needed to properly boot TI's am62a SoC
family of devices

Signed-off-by: Bryan Brattlof 
---
 arch/arm/mach-k3/Kconfig  |  14 +-
 arch/arm/mach-k3/Makefile |   2 +
 arch/arm/mach-k3/am62a7_init.c| 250 ++
 arch/arm/mach-k3/arm64-mmu.c  |   6 +-
 .../arm/mach-k3/include/mach/am62a_hardware.h |  74 ++
 arch/arm/mach-k3/include/mach/am62a_spl.h |  49 
 arch/arm/mach-k3/include/mach/hardware.h  |   4 +
 arch/arm/mach-k3/include/mach/spl.h   |   4 +
 8 files changed, 396 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/mach-k3/am62a7_init.c
 create mode 100644 arch/arm/mach-k3/include/mach/am62a_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/am62a_spl.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 171a7f2f25f8d..87da6b49ee6b7 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -19,6 +19,9 @@ config SOC_K3_AM642
 config SOC_K3_AM625
bool "TI's K3 based AM625 SoC Family Support"
 
+config SOC_K3_AM62A7
+   bool "TI's K3 based AM62A7 SoC Family Support"
+
 endchoice
 
 config SYS_SOC
@@ -29,7 +32,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE
default 0x8 if SOC_K3_AM654
default 0x10 if SOC_K3_J721E || SOC_K3_J721S2
default 0x1c if SOC_K3_AM642
-   default 0x3c000 if SOC_K3_AM625
+   default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7
help
  Describes the total size of the MCU or OCMC MSRAM present on
  the SoC in use. This doesn't specify the total size of SPL as
@@ -41,7 +44,7 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
default 0x58000 if SOC_K3_AM654
default 0xc if SOC_K3_J721E || SOC_K3_J721S2
default 0x18 if SOC_K3_AM642
-   default 0x38000 if SOC_K3_AM625
+   default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7
help
  Describes the maximum size of the image that ROM can download
  from any boot media.
@@ -66,7 +69,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
default 0x41cffbfc if SOC_K3_J721E
default 0x41cfdbfc if SOC_K3_J721S2
default 0x701bebfc if SOC_K3_AM642
-   default 0x43c3f290 if SOC_K3_AM625
+   default 0x43c3f290 if SOC_K3_AM625 || SOC_K3_AM62A7
help
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
@@ -135,7 +138,7 @@ config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
 config K3_SYSFW_IMAGE_SIZE_MAX
int "Amount of memory dynamically allocated for loading SYSFW blob"
depends on K3_LOAD_SYSFW
-   default 163840 if SOC_K3_AM625
+   default 163840 if SOC_K3_AM625 || SOC_K3_AM62A7
default 278000
help
  Amount of memory (in bytes) reserved through dynamic allocation at
@@ -167,7 +170,7 @@ config K3_ATF_LOAD_ADDR
 
 config K3_DM_FW
bool "Separate DM firmware image"
-   depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || 
SOC_K3_AM625) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN
+   depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || 
SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN
default y
help
  Enabling this will indicate that the system has separate DM
@@ -185,6 +188,7 @@ config K3_X509_SWRV
 source "board/ti/am65x/Kconfig"
 source "board/ti/am64x/Kconfig"
 source "board/ti/am62x/Kconfig"
+source "board/ti/am62ax/Kconfig"
 source "board/ti/j721e/Kconfig"
 source "board/siemens/iot2050/Kconfig"
 source "board/ti/j721s2/Kconfig"
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 6ac2b61c3d7ba..b5bc2367813c8 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
 obj-$(CONFIG_SOC_K3_AM625) += am62x/
+obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
 obj-$(CONFIG_ARM64) += cache.o
@@ -15,6 +16,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
 obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
 obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
+obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
 obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
 endif
 obj-y += common.o security.o
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
new file mode 100644
index 0..e9569f0d26418
--- /dev/null
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM62A7: SoC specific initialization
+ *
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "common.h"
+#include 
+#include 
+#include 
+
+/*
+ * This uninitialized global variable would normal e

[PATCH 3/8] ram: k3-ddrss: add am62a controller support

TI's am62a family of SoCs uses a new 32bit DDR controller that shares
much of the same functionality with the existing am64 and j721e
controllers.

Select this controller by default when u-boot is build for the am62a

Signed-off-by: Bryan Brattlof 
---
 drivers/ram/Kconfig | 1 +
 drivers/ram/k3-ddrss/k3-ddrss.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index bf279b79f6d1a..e085119963b6c 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -65,6 +65,7 @@ choice
default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2
default K3_AM64_DDRSS if SOC_K3_AM642
default K3_AM64_DDRSS if SOC_K3_AM625
+   default K3_AM62A_DDRSS if SOC_K3_AM62A7
 
 config K3_J721E_DDRSS
bool "Enable J721E DDRSS support"
diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index e8b7aec9e0bb3..7e445d2b737b3 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -706,6 +706,7 @@ static const struct k3_ddrss_data j721s2_data = {
 };
 
 static const struct udevice_id k3_ddrss_ids[] = {
+   {.compatible = "ti,am62a-ddrss", .data = (ulong)&k3_data, },
{.compatible = "ti,am64-ddrss", .data = (ulong)&k3_data, },
{.compatible = "ti,j721e-ddrss", .data = (ulong)&k3_data, },
{.compatible = "ti,j721s2-ddrss", .data = (ulong)&j721s2_data, },
-- 
2.38.1

[PATCH 7/8] board: ti: introduce the basic files needed to support the am62a

Introduce the bare minimum SD and UART support for the am62a sk.

Signed-off-by: Bryan Brattlof 
---
 board/ti/am62ax/Kconfig   | 52 +++
 board/ti/am62ax/MAINTAINERS   |  9 +
 board/ti/am62ax/Makefile  |  7 
 board/ti/am62ax/evm.c | 31 
 drivers/firmware/ti_sci_static_data.h |  4 +--
 5 files changed, 101 insertions(+), 2 deletions(-)
 create mode 100644 board/ti/am62ax/Kconfig
 create mode 100644 board/ti/am62ax/MAINTAINERS
 create mode 100644 board/ti/am62ax/Makefile
 create mode 100644 board/ti/am62ax/evm.c

diff --git a/board/ti/am62ax/Kconfig b/board/ti/am62ax/Kconfig
new file mode 100644
index 0..2c18cd49b5d27
--- /dev/null
+++ b/board/ti/am62ax/Kconfig
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+
+choice
+   prompt "TI K3 AM62Ax based boards"
+   optional
+
+config TARGET_AM62A7_A53_EVM
+   bool "TI K3 based AM62A7 EVM running on A53"
+   select ARM64
+   select SOC_K3_AM62A7
+   imply BOARD
+   imply SPL_BOARD
+   imply TI_I2C_BOARD_DETECT
+
+config TARGET_AM62A7_R5_EVM
+   bool "TI K3 based AM62A7 EVM running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select K3_LOAD_SYSFW
+   select SOC_K3_AM62A7
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
+   imply SYS_K3_SPL_ATF
+   imply TI_I2C_BOARD_DETECT
+
+endchoice
+
+if TARGET_AM62A7_R5_EVM || TARGET_AM62A7_A53_EVM
+
+config SYS_BOARD
+   default "am62ax"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "am62ax_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_AM62A7_R5_EVM
+
+config SPL_LDSCRIPT
+   default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+endif
diff --git a/board/ti/am62ax/MAINTAINERS b/board/ti/am62ax/MAINTAINERS
new file mode 100644
index 0..590f683584e52
--- /dev/null
+++ b/board/ti/am62ax/MAINTAINERS
@@ -0,0 +1,9 @@
+AM62Ax BOARD
+M: Vignesh Raghavendra 
+M: Bryan Brattlof 
+M: Tom Rini 
+S: Maintained
+F: board/ti/am62ax/
+F: include/configs/am62a7_evm.h
+F: configs/am62ax_evm_r5_defconfig
+F: configs/am62ax_evm_a53_defconfig
diff --git a/board/ti/am62ax/Makefile b/board/ti/am62ax/Makefile
new file mode 100644
index 0..4e8e7aa23003e
--- /dev/null
+++ b/board/ti/am62ax/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += evm.o
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
new file mode 100644
index 0..beef3f2f3da70
--- /dev/null
+++ b/board/ti/am62ax/evm.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for AM62Ax platforms
+ *
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+   return fdtdec_setup_memory_banksize();
+}
diff --git a/drivers/firmware/ti_sci_static_data.h 
b/drivers/firmware/ti_sci_static_data.h
index 5ae0556a9a453..1a461fab6199b 100644
--- a/drivers/firmware/ti_sci_static_data.h
+++ b/drivers/firmware/ti_sci_static_data.h
@@ -84,7 +84,7 @@ static struct ti_sci_resource_static_data rm_static_data[] = {
 };
 #endif /* CONFIG_SOC_K3_J721S2 */
 
-#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+#if IS_ENABLED(CONFIG_SOC_K3_AM625) || IS_ENABLED(CONFIG_SOC_K3_AM62A7)
 static struct ti_sci_resource_static_data rm_static_data[] = {
/* BC channels */
{
@@ -95,7 +95,7 @@ static struct ti_sci_resource_static_data rm_static_data[] = {
},
{ },
 };
-#endif /* CONFIG_SOC_K3_AM625 */
+#endif /* CONFIG_SOC_K3_AM625 || CONFIG_SOC_K3_AM62A7 */
 
 #else
 static struct ti_sci_resource_static_data rm_static_data[] = {
-- 
2.38.1

[PATCH 1/8] arm: dts: introduce am62a7 dtbs from linux kernel

Introduce the basic am62a7 SoC dtbs from the linux kernel along with the
new am62a specific pinmux definition that we will use to generate the
dtbs for the u-boot-spl and u-boot binaries

Co-developed-by: Vignesh Raghavendra 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Bryan Brattlof 
---
 arch/arm/dts/k3-am62a-main.dtsi   | 298 ++
 arch/arm/dts/k3-am62a-mcu.dtsi|  39 
 arch/arm/dts/k3-am62a-wakeup.dtsi |  54 ++
 arch/arm/dts/k3-am62a.dtsi| 122 
 arch/arm/dts/k3-am62a7-sk.dts | 223 ++
 arch/arm/dts/k3-am62a7.dtsi   | 103 +++
 include/dt-bindings/pinctrl/k3.h  |   3 +
 7 files changed, 842 insertions(+)
 create mode 100644 arch/arm/dts/k3-am62a-main.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-mcu.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-wakeup.dtsi
 create mode 100644 arch/arm/dts/k3-am62a.dtsi
 create mode 100644 arch/arm/dts/k3-am62a7-sk.dts
 create mode 100644 arch/arm/dts/k3-am62a7.dtsi

diff --git a/arch/arm/dts/k3-am62a-main.dtsi b/arch/arm/dts/k3-am62a-main.dtsi
new file mode 100644
index 0..bc4b50bcd1773
--- /dev/null
+++ b/arch/arm/dts/k3-am62a-main.dtsi
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM62A SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_main {
+   oc_sram: sram@7000 {
+   compatible = "mmio-sram";
+   reg = <0x00 0x7000 0x00 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x00 0x7000 0x1>;
+   };
+
+   gic500: interrupt-controller@180 {
+   compatible = "arm,gic-v3";
+   reg = <0x00 0x0180 0x00 0x1>,   /* GICD */
+ <0x00 0x0188 0x00 0xc>,   /* GICR */
+ <0x00 0x0188 0x00 0xc>,   /* GICR */
+ <0x01 0x 0x00 0x2000>,/* GICC */
+ <0x01 0x0001 0x00 0x1000>,/* GICH */
+ <0x01 0x0002 0x00 0x2000>;/* GICV */
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   /*
+* vcpumntirq:
+* virtual CPU interface maintenance interrupt
+*/
+   interrupts = ;
+
+   gic_its: msi-controller@182 {
+   compatible = "arm,gic-v3-its";
+   reg = <0x00 0x0182 0x00 0x1>;
+   socionext,synquacer-pre-its = <0x100 0x40>;
+   msi-controller;
+   #msi-cells = <1>;
+   };
+   };
+
+   main_conf: syscon@10 {
+   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
+   reg = <0x00 0x0010 0x00 0x2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x00 0x00 0x0010 0x2>;
+   };
+
+   dmss: bus@4800 {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   dma-ranges;
+   ranges = <0x00 0x4800 0x00 0x4800 0x00 0x0600>;
+
+   ti,sci-dev-id = <25>;
+
+   secure_proxy_main: mailbox@4d00 {
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x00 0x4d00 0x00 0x8>,
+ <0x00 0x4a60 0x00 0x8>,
+ <0x00 0x4a40 0x00 0x8>;
+   reg-names = "target_data", "rt", "scfg";
+   #mbox-cells = <1>;
+   interrupt-names = "rx_012";
+   interrupts = ;
+   };
+   };
+
+   dmsc: system-controller@44043000 {
+   compatible = "ti,k2g-sci";
+   reg = <0x00 0x44043000 0x00 0xfe0>;
+   reg-names = "debug_messages";
+   ti,host-id = <12>;
+   mbox-names = "rx", "tx";
+   mboxes= <&secure_proxy_main 12>,
+   <&secure_proxy_main 13>;
+
+   k3_pds: power-controller {
+   compatible = "ti,sci-pm-domain";
+   #power-domain-cells = <2>;
+   };
+
+   k3_clks: clock-controller {
+   compatible = "ti,k2g-sci-clk";
+   #clock-cells = <2>;
+   };
+
+   k3_reset: reset-controller {
+   compatible = "ti,sci-reset";
+   #reset-cells = <2>;
+   };
+   };
+
+   main_pmx0: pinctrl@f4000 {
+   compatible = "pinctrl-single";
+

[PATCH 0/8] Introduce initial TI's am62a support

Hello Everyone!

This series will introduce basic support (SD and UART) support for Texas 
Instruments AM62Ax SK EVM. 

The am62ax shares many of the same features as the am62x however it uses 
a new 32bit controller and therefore depends on the patch I sent last 
week updating the macros used by the k3-ddrss ram driver[0].

Here is some proof of life & more documentation if you're interested :)

Bootlog:https://paste.sr.ht/~bryanb/e0a418ba7dd452749d2dd1efb5e91b2875a01708
Technical Reference Manual:https://www.ti.com/lit/zip/spruj16
Schematics:https://www.ti.com/lit/zip/sprr459

Thanks for reviewing!
~Bryan

[0] https://lore.kernel.org/u-boot/20221024215328.22373-1...@ti.com/

Bryan Brattlof (8):
  arm: dts: introduce am62a7 dtbs from linux kernel
  arm: dts: introduce am62a7 u-boot dtbs
  ram: k3-ddrss: add am62a controller support
  soc: ti: k3-socinfo: add am62a SoC entry
  arm: mach-k3: introduce basic files to support the am62a
  arm: mach-k3: am62a: introduce auto-generated SoC data
  board: ti: introduce the basic files needed to support the am62a
  configs: introduce configs for the am62a

 arch/arm/dts/Makefile |3 +
 arch/arm/dts/k3-am62a-ddr-1866mhz-32bit.dtsi  | 2798 
 arch/arm/dts/k3-am62a-ddr.dtsi| 2814 +
 arch/arm/dts/k3-am62a-main.dtsi   |  298 ++
 arch/arm/dts/k3-am62a-mcu.dtsi|   39 +
 arch/arm/dts/k3-am62a-wakeup.dtsi |   54 +
 arch/arm/dts/k3-am62a.dtsi|  122 +
 arch/arm/dts/k3-am62a7-r5-sk.dts  |  143 +
 arch/arm/dts/k3-am62a7-sk-u-boot.dtsi |  140 +
 arch/arm/dts/k3-am62a7-sk.dts |  223 ++
 arch/arm/dts/k3-am62a7.dtsi   |  103 +
 arch/arm/mach-k3/Kconfig  |   14 +-
 arch/arm/mach-k3/Makefile |2 +
 arch/arm/mach-k3/am62a7_init.c|  250 ++
 arch/arm/mach-k3/am62ax/Makefile  |6 +
 arch/arm/mach-k3/am62ax/clk-data.c|  317 ++
 arch/arm/mach-k3/am62ax/dev-data.c|   73 +
 arch/arm/mach-k3/arm64-mmu.c  |6 +-
 .../arm/mach-k3/include/mach/am62a_hardware.h |   74 +
 arch/arm/mach-k3/include/mach/am62a_spl.h |   49 +
 arch/arm/mach-k3/include/mach/hardware.h  |4 +
 arch/arm/mach-k3/include/mach/spl.h   |4 +
 board/ti/am62ax/Kconfig   |   52 +
 board/ti/am62ax/MAINTAINERS   |9 +
 board/ti/am62ax/Makefile  |7 +
 board/ti/am62ax/evm.c |   31 +
 configs/am62ax_evm_a53_defconfig  |   79 +
 configs/am62ax_evm_r5_defconfig   |  106 +
 drivers/clk/ti/clk-k3.c   |6 +
 drivers/firmware/ti_sci_static_data.h |4 +-
 drivers/power/domain/ti-power-domain.c|6 +
 drivers/ram/Kconfig   |1 +
 drivers/ram/k3-ddrss/k3-ddrss.c   |1 +
 drivers/soc/soc_ti_k3.c   |4 +
 include/configs/am62ax_evm.h  |   68 +
 include/dt-bindings/pinctrl/k3.h  |3 +
 include/k3-clk.h  |1 +
 include/k3-dev.h  |1 +
 38 files changed, 7906 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/dts/k3-am62a-ddr-1866mhz-32bit.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-ddr.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-main.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-mcu.dtsi
 create mode 100644 arch/arm/dts/k3-am62a-wakeup.dtsi
 create mode 100644 arch/arm/dts/k3-am62a.dtsi
 create mode 100644 arch/arm/dts/k3-am62a7-r5-sk.dts
 create mode 100644 arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am62a7-sk.dts
 create mode 100644 arch/arm/dts/k3-am62a7.dtsi
 create mode 100644 arch/arm/mach-k3/am62a7_init.c
 create mode 100644 arch/arm/mach-k3/am62ax/Makefile
 create mode 100644 arch/arm/mach-k3/am62ax/clk-data.c
 create mode 100644 arch/arm/mach-k3/am62ax/dev-data.c
 create mode 100644 arch/arm/mach-k3/include/mach/am62a_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/am62a_spl.h
 create mode 100644 board/ti/am62ax/Kconfig
 create mode 100644 board/ti/am62ax/MAINTAINERS
 create mode 100644 board/ti/am62ax/Makefile
 create mode 100644 board/ti/am62ax/evm.c
 create mode 100644 configs/am62ax_evm_a53_defconfig
 create mode 100644 configs/am62ax_evm_r5_defconfig
 create mode 100644 include/configs/am62ax_evm.h

-- 
2.38.1

[PATCH 8/8] configs: introduce configs for the am62a

Introduce the minimum configs, only SD-MMC and UART boot related
settings, to serve as a good starting point for the am62a as we add more
functionality.

Signed-off-by: Bryan Brattlof 
---
 configs/am62ax_evm_a53_defconfig |  79 +++
 configs/am62ax_evm_r5_defconfig  | 106 +++
 include/configs/am62ax_evm.h |  68 
 3 files changed, 253 insertions(+)
 create mode 100644 configs/am62ax_evm_a53_defconfig
 create mode 100644 configs/am62ax_evm_r5_defconfig
 create mode 100644 include/configs/am62ax_evm.h

diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
new file mode 100644
index 0..79f3592656530
--- /dev/null
+++ b/configs/am62ax_evm_a53_defconfig
@@ -0,0 +1,79 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_AM62A7=y
+CONFIG_K3_ATF_LOAD_ADDR=0x9e78
+CONFIG_TARGET_AM62A7_A53_EVM=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am62a7-sk"
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_SPL_MAX_SIZE=0x58000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x80a0
+CONFIG_SPL_BSS_MAX_SIZE=0x8
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_CMD_MMC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+# CONFIG_GPIO is not set
+# CONFIG_I2C is not set
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+# CONFIG_NETDEVICES is not set
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig
new file mode 100644
index 0..b871a5143cb14
--- /dev/null
+++ b/configs/am62ax_evm_r5_defconfig
@@ -0,0 +1,106 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SYS_MALLOC_F_LEN=0x9000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SOC_K3_AM62A7=y
+CONFIG_TARGET_AM62A7_R5_EVM=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am62a7-r5-sk"
+CONFIG_SPL_TEXT_BASE=0x43c0
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x7000
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_MAX_SIZE=0x58000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x43c37800
+CONFIG_SPL_BSS_MAX_SIZE=0x5000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_THERMAL=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_A

[PATCH 4/8] soc: ti: k3-socinfo: add am62a SoC entry

Add identification support for TI's am62ax family of SoCs

Signed-off-by: Bryan Brattlof 
---
 drivers/soc/soc_ti_k3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index b1e7c4ae5f6aa..8af0ac7051925 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -16,6 +16,7 @@
 #define AM64X  0xbb38
 #define J721S2 0xbb75
 #define AM62X  0xbb7e
+#define AM62AX 0xbb8d
 
 #define JTAG_ID_VARIANT_SHIFT  28
 #define JTAG_ID_VARIANT_MASK   (0xf << 28)
@@ -53,6 +54,9 @@ static const char *get_family_string(u32 idreg)
case AM62X:
family = "AM62X";
break;
+   case AM62AX:
+   family = "AM62AX";
+   break;
default:
family = "Unknown Silicon";
};
-- 
2.38.1

[PATCH 6/8] arm: mach-k3: am62a: introduce auto-generated SoC data

Introduce the auto-generated clock tree and power domain data needed to
attach the am62a into the power-domain and clock frameworks of uboot

Signed-off-by: Bryan Brattlof 
---
 arch/arm/mach-k3/am62ax/Makefile   |   6 +
 arch/arm/mach-k3/am62ax/clk-data.c | 317 +
 arch/arm/mach-k3/am62ax/dev-data.c |  73 ++
 drivers/clk/ti/clk-k3.c|   6 +
 drivers/power/domain/ti-power-domain.c |   6 +
 include/k3-clk.h   |   1 +
 include/k3-dev.h   |   1 +
 7 files changed, 410 insertions(+)
 create mode 100644 arch/arm/mach-k3/am62ax/Makefile
 create mode 100644 arch/arm/mach-k3/am62ax/clk-data.c
 create mode 100644 arch/arm/mach-k3/am62ax/dev-data.c

diff --git a/arch/arm/mach-k3/am62ax/Makefile b/arch/arm/mach-k3/am62ax/Makefile
new file mode 100644
index 0..c58e52df1fa27
--- /dev/null
+++ b/arch/arm/mach-k3/am62ax/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/am62ax/clk-data.c 
b/arch/arm/mach-k3/am62ax/clk-data.c
new file mode 100644
index 0..d950b35e0beb7
--- /dev/null
+++ b/arch/arm/mach-k3/am62ax/clk-data.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * AM62AX specific clock platform data
+ *
+ * This file is auto generated. Please do not hand edit and report any issues
+ * to Bryan Brattlof .
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+   NULL,
+   NULL,
+   "osc_24_mhz",
+   "osc_25_mhz",
+   "osc_26_mhz",
+   NULL,
+};
+
+static const char * const clk_32k_rc_sel_out0_parents[] = {
+   "gluelogic_rcosc_clk_1p0v_97p65k",
+   "gluelogic_hfosc0_clkout",
+   "gluelogic_rcosc_clk_1p0v_97p65k",
+   "gluelogic_lfosc0_clkout",
+};
+
+static const char * const main_emmcsd0_io_clklb_sel_out0_parents[] = {
+   "board_0_mmc0_clklb_out",
+   "board_0_mmc0_clk_out",
+};
+
+static const char * const main_emmcsd1_io_clklb_sel_out0_parents[] = {
+   "board_0_mmc1_clklb_out",
+   "board_0_mmc1_clk_out",
+};
+
+static const char * const main_ospi_loopback_clk_sel_out0_parents[] = {
+   "board_0_ospi0_dqs_out",
+   "board_0_ospi0_lbclko_out",
+};
+
+static const char * const main_usb0_refclk_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "postdiv4_16ff_main_0_hsdivout8_clk",
+};
+
+static const char * const main_usb1_refclk_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "postdiv4_16ff_main_0_hsdivout8_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = 
{
+   "gluelogic_hfosc0_clkout",
+   "hsdiv4_16fft_main_0_hsdivout0_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "hsdiv4_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const clkout0_ctrl_out0_parents[] = {
+   "hsdiv4_16fft_main_2_hsdivout1_clk",
+   "hsdiv4_16fft_main_2_hsdivout1_clk",
+};
+
+static const char * const main_emmcsd0_refclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_0_hsdivout5_clk",
+   "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_emmcsd1_refclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_0_hsdivout5_clk",
+   "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_gtcclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_2_hsdivout5_clk",
+   "postdiv4_16ff_main_0_hsdivout6_clk",
+   "board_0_cp_gemac_cpts0_rft_clk_out",
+   NULL,
+   "board_0_mcu_ext_refclk0_out",
+   "board_0_ext_refclk1_out",
+   "sam62_pll_ctrl_wrap_mcu_0_chip_div1_clk_clk",
+   "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
+};
+
+static const char * const main_ospi_ref_clk_sel_out0_parents[] = {
+   "hsdiv4_16fft_main_0_hsdivout1_clk",
+   "postdiv1_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_clkout_sel_out0_parents[] = {
+   NULL,
+   "gluelogic_lfosc0_clkout",
+   "hsdiv4_16fft_main_0_hsdivout2_clk",
+   "hsdiv4_16fft_main_1_hsdivout2_clk",
+   "postdiv4_16ff_main_2_hsdivout9_clk",
+   "clk_32k_rc_sel_out0",
+   "gluelogic_rcosc_clkout",
+   "gluelogic_hfosc0_clkout",
+};
+
+static const char * const wkup_clkout_sel_io_out0_parents[] = {
+   "wkup_clkout_sel_out0",
+   "gluelogic_hfosc0_clkout",
+};
+
+static const char * const wkup_clksel_out0_parents[] = {
+   "hsdiv2_16fft_main_15_hsdivout0_clk",
+   "hsdiv4_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const main_usart0_fclk_sel_out0_parents[] = {
+   "usart_programmable_clock_divider_out0",
+   "hsdiv4_16fft_main_1_hsdivout1_clk",
+};
+
+stat

Re: [PATCH v2 1/1] usb: storage: continue probe on "Invalid device"


On 11/3/22 23:23, Marek Vasut wrote:

On 11/3/22 22:36, Janne Grunau wrote:

On 2022-09-28 04:20:52 -0600, Simon Glass wrote:

+Marek Vasut
+Tom Rini

On Sun, 25 Sept 2022 at 23:07, Janne Grunau  wrote:


On 2022-08-10 21:54:22 +0200, Janne Grunau wrote:
Fixes a crash during probing of sd card readers without medium 
present.


Link: https://github.com/AsahiLinux/linux/issues/44
Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html
Signed-off-by: Janne Grunau 
---
Changes since v1:
  - changed unconditiona return to "continue" as proposed by AKASHI 
Takahiro


  common/usb_storage.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/common/usb_storage.c b/common/usb_storage.c
index eaa31374ef73..f9204552a683 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct 
usb_device *udev)

   ret = device_unbind(dev);
   if (ret)
   return ret;
+ continue;
   }

   ret = blk_probe_or_unbind(dev);


ping. Is there anything holding up merging this fix?


ping2

This fixes a 100% reproducible crash when an USB storage device with
"medium not ready" is connected.


Can you please CC me next time when submitting these kinds of USB fixes ?

Also, can you tell which device this is ?


Reading through the rest of the links, can you please just fill in 
details of the USB card reader for future reference (like lsusb -vvvn or 
similar). And then send V3 with my:


Reviewed-by: Marek Vasut

Re: [PATCH v2 1/1] usb: storage: continue probe on "Invalid device"


On 11/3/22 22:36, Janne Grunau wrote:

On 2022-09-28 04:20:52 -0600, Simon Glass wrote:

+Marek Vasut
+Tom Rini

On Sun, 25 Sept 2022 at 23:07, Janne Grunau  wrote:


On 2022-08-10 21:54:22 +0200, Janne Grunau wrote:

Fixes a crash during probing of sd card readers without medium present.

Link: https://github.com/AsahiLinux/linux/issues/44
Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html
Signed-off-by: Janne Grunau 
---
Changes since v1:
  - changed unconditiona return to "continue" as proposed by AKASHI Takahiro

  common/usb_storage.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/common/usb_storage.c b/common/usb_storage.c
index eaa31374ef73..f9204552a683 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct usb_device *udev)
   ret = device_unbind(dev);
   if (ret)
   return ret;
+ continue;
   }

   ret = blk_probe_or_unbind(dev);


ping. Is there anything holding up merging this fix?


ping2

This fixes a 100% reproducible crash when an USB storage device with
"medium not ready" is connected.


Can you please CC me next time when submitting these kinds of USB fixes ?

Also, can you tell which device this is ?

Re: [PATCH] usb: Add 1ms delay after first Get Descriptor request


On 11/3/22 22:31, Janne Grunau wrote:

Hi,

[...]


In any case we need a way to enable/disable this as it will slow down
unaffected platforms.


This makes little difference, since anyone can plug such device into a port
and suddenly the platform is affected. We cannot really predict what users
have on their desks.


Would it make sense to limit it to dwc3 host controllers or do you fear
the same problem could happen with other controllers on fast boards?


I believe the DWC3 triggers it on "fast" devices now, but this is a 
generic issue. The U-Boot USB stack is just way too efficient (well, 
more efficient than any OS anyway, because it is basically just a tight 
loop), no OS triggers this because the OSes take their time.



In any case patch fixes the problem here as well.

Tested-by: Janne Grunau 


Thanks!

(and sorry for the delay)

[PULL] u-boot-mips

2022-11-03 Thread Daniel Schwierzeck

Hi Tom,

please pull the Kconfig migration for CONFIG_SYS_MIPS_TIMER_FREQ as well as the 
mtmips bugfix
for the incorrectly converted default value for CONFIG_SPL_PAD_TO.

Gitlab:
  https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/14002



The following changes since commit cca41ed3d63f462ca044e0d2d30a34d4917fc6c5:

  Merge branch 'master' of 
https://source.denx.de/u-boot/custodians/u-boot-watchdog (2022-11-02 09:10:30 
-0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-mips.git/ 
tags/mips-pull-2022-11-03

for you to fetch changes up to 8450b97bf4464ab8b9c1b33b5a9150ae80c6136e:

  mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS 
(2022-11-02 21:54:26 +0100)


- MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig
- MIPS: mtmips: fix incorrectly converted default value for CONFIG_SPL_PAD_TO


Daniel Schwierzeck (4):
  MIPS: remove deprecated TARGET_VCT option
  MIPS: remove CONFIG_SYS_MHZ
  MIPS: mscc: remove unused CPU_CLOCK_RATE
  MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig

Stefan Roese (1):
  mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS

 arch/mips/Kconfig  | 26 ++
 arch/mips/mach-jz47xx/include/mach/jz4780.h|  2 +-
 arch/mips/mach-jz47xx/jz4780/pll.c |  6 +-
 board/imgtec/ci20/ci20.c   |  4 
 common/spl/Kconfig |  1 +
 configs/ap121_defconfig|  1 +
 configs/ap143_defconfig|  1 +
 configs/ap152_defconfig|  1 +
 configs/bcm968380gerg_ram_defconfig|  1 +
 configs/boston32r2_defconfig   |  1 +
 configs/boston32r2el_defconfig |  1 +
 configs/boston32r6_defconfig   |  1 +
 configs/boston32r6el_defconfig |  1 +
 configs/boston64r2_defconfig   |  1 +
 configs/boston64r2el_defconfig |  1 +
 configs/boston64r6_defconfig   |  1 +
 configs/boston64r6el_defconfig |  1 +
 configs/ci20_mmc_defconfig |  1 +
 configs/comtrend_ar5315u_ram_defconfig |  1 +
 configs/comtrend_ar5387un_ram_defconfig|  1 +
 configs/comtrend_ct5361_ram_defconfig  |  1 +
 configs/comtrend_vr3032u_ram_defconfig |  1 +
 configs/comtrend_wap5813n_ram_defconfig|  1 +
 configs/gardena-smart-gateway-mt7688_defconfig |  1 +
 configs/huawei_hg556a_ram_defconfig|  1 +
 configs/imgtec_xilfpga_defconfig   |  1 +
 configs/linkit-smart-7688_defconfig|  1 +
 configs/malta64_defconfig  |  1 +
 configs/malta64el_defconfig|  1 +
 configs/malta_defconfig|  1 +
 configs/maltael_defconfig  |  1 +
 configs/mscc_jr2_defconfig |  1 +
 configs/mscc_luton_defconfig   |  1 +
 configs/mscc_ocelot_defconfig  |  1 +
 configs/mscc_serval_defconfig  |  1 +
 configs/mscc_servalt_defconfig |  1 +
 configs/mt7620_mt7530_rfb_defconfig|  1 +
 configs/mt7620_rfb_defconfig   |  1 +
 configs/mt7621_nand_rfb_defconfig  |  1 +
 configs/mt7621_rfb_defconfig   |  1 +
 configs/mt7628_rfb_defconfig   |  1 +
 configs/netgear_cg3100d_ram_defconfig  |  1 +
 configs/netgear_dgnd3700v2_ram_defconfig   |  1 +
 configs/pic32mzdask_defconfig  |  1 +
 configs/sagem_f@st1704_ram_defconfig   |  1 +
 configs/sfr_nb4-ser_ram_defconfig  |  1 +
 configs/tplink_wdr4300_defconfig   |  1 +
 configs/vocore2_defconfig  |  1 +
 include/configs/ap121.h|  3 ---
 include/configs/ap143.h|  3 ---
 include/configs/ap152.h|  3 ---
 include/configs/bmips_bcm3380.h|  3 ---
 include/configs/bmips_bcm6318.h|  3 ---
 include/configs/bmips_bcm63268.h   |  3 ---
 include/configs/bmips_bcm6328.h|  3 ---
 include/configs/bmips_bcm6338.h|  3 ---
 include/configs/bmips_bcm6348.h|  3 ---
 include/configs/bmips_bcm6358.h|  3 ---
 include/configs/bmips_bcm6362.h|  3 ---
 include/configs/bmips_bcm6368.h|  3 ---
 include/configs/bmips_bcm6838.h|  3 ---
 include/configs/boston.h   |  1 -
 include/configs/ci20.h |  4 
 include/configs/gardena-smart-gateway-mt7688.h |  3 ---
 include/configs/imgtec_xilfpga.h   |  2 --
 include/configs/linkit-smart-

[PATCH] drivers: net: aquantia: fix typos

2022-11-03 Thread Tim Harvey

Fix a couple of typos:
- s/Acquantia/Aquantia/
- s/firmare/firmware/

Signed-off-by: Tim Harvey 
---
 drivers/net/phy/aquantia.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
index 7e950fe0c2fe..79fbc115368a 100644
--- a/drivers/net/phy/aquantia.c
+++ b/drivers/net/phy/aquantia.c
@@ -136,7 +136,7 @@ static int aquantia_read_fw(u8 **fw_addr, size_t *fw_length)
 
*fw_addr = NULL;
*fw_length = 0;
-   debug("Loading Acquantia microcode from %s %s\n",
+   debug("Loading Aquantia microcode from %s %s\n",
  CONFIG_PHY_AQUANTIA_FW_PART, CONFIG_PHY_AQUANTIA_FW_NAME);
ret = fs_set_blk_dev("mmc", CONFIG_PHY_AQUANTIA_FW_PART, FS_TYPE_ANY);
if (ret < 0)
@@ -163,7 +163,7 @@ static int aquantia_read_fw(u8 **fw_addr, size_t *fw_length)
 
*fw_addr = addr;
*fw_length = length;
-   debug("Found Acquantia microcode.\n");
+   debug("Found Aquantia microcode.\n");
 
 cleanup:
if (ret < 0) {
@@ -257,7 +257,7 @@ static int aquantia_upload_firmware(struct phy_device 
*phydev)
 
strlcpy(version, (char *)&addr[dram_offset + VERSION_STRING_OFFSET],
VERSION_STRING_SIZE);
-   printf("%s loading firmare version '%s'\n", phydev->dev->name, version);
+   printf("%s loading firmware version '%s'\n", phydev->dev->name, 
version);
 
/* stall the microcprocessor */
phy_write(phydev, MDIO_MMD_VEND1, UP_CONTROL,
@@ -288,7 +288,7 @@ static int aquantia_upload_firmware(struct phy_device 
*phydev)
 
phy_write(phydev, MDIO_MMD_VEND1, UP_CONTROL, UP_RUN_STALL_OVERRIDE);
 
-   printf("%s firmare loading done.\n", phydev->dev->name);
+   printf("%s firmware loading done.\n", phydev->dev->name);
 done:
free(addr);
return ret;
-- 
2.25.1

Re: [PATCH v2 1/1] usb: storage: continue probe on "Invalid device"

2022-11-03 Thread Janne Grunau

On 2022-09-28 04:20:52 -0600, Simon Glass wrote:
> +Marek Vasut
> +Tom Rini
> 
> On Sun, 25 Sept 2022 at 23:07, Janne Grunau  wrote:
> >
> > On 2022-08-10 21:54:22 +0200, Janne Grunau wrote:
> > > Fixes a crash during probing of sd card readers without medium present.
> > >
> > > Link: https://github.com/AsahiLinux/linux/issues/44
> > > Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html
> > > Signed-off-by: Janne Grunau 
> > > ---
> > > Changes since v1:
> > >  - changed unconditiona return to "continue" as proposed by AKASHI 
> > > Takahiro
> > >
> > >  common/usb_storage.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/common/usb_storage.c b/common/usb_storage.c
> > > index eaa31374ef73..f9204552a683 100644
> > > --- a/common/usb_storage.c
> > > +++ b/common/usb_storage.c
> > > @@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct usb_device 
> > > *udev)
> > >   ret = device_unbind(dev);
> > >   if (ret)
> > >   return ret;
> > > + continue;
> > >   }
> > >
> > >   ret = blk_probe_or_unbind(dev);
> >
> > ping. Is there anything holding up merging this fix?

ping2

This fixes a 100% reproducible crash when an USB storage device with 
"medium not ready" is connected.

Janne

[PATCH v3 4/4] cmd: source: Support specifying config name

As discussed previously [1,2], the source command is not safe to use with
verified boot unless there is a key with required = "images" (which has its
own problems). This is because if such a key is absent, signatures are
verified but not required. It is assumed that configuration nodes will
provide the signature. Because the source command does not use
configurations to determine the image to source, effectively no
verification takes place.

To address this, allow specifying configuration nodes. We use the same
syntax as the bootm command (helpfully provided for us by fit_parse_conf).
By default, we first try the default config and then the default image. To
force using a config, # must be present in the command (e.g. `source
$loadaddr#my-conf`). For convenience, the config may be omitted, just like
the address may be (e.g. `source \#`). This also works for images
(`source \:` behaves exactly like `source` currently does).

[1] 
https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9ee...@prevas.dk/
[2] 
https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005...@gmail.com/

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v3:
- Halve the quotes

 .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
 boot/bootmeth_script.c|  2 +-
 cmd/source.c  | 73 +--
 doc/uImage.FIT/source_file_format.txt |  3 +
 drivers/usb/gadget/f_sdp.c|  2 +-
 include/image.h   | 19 +++--
 test/py/tests/test_source.py  | 11 ++-
 7 files changed, 82 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 3627b4c35c9..cb13a14d829 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
do_bootz(cmdtp, 0, 4, bootm_argv);
}
if (data->script)
-   image_source_script(data->script, NULL);
+   image_source_script(data->script, NULL, NULL);
 
if (reset) {
puts("Reset...\n");
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index d1c3f940037..6c84721d1cd 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -101,7 +101,7 @@ static int script_boot(struct udevice *dev, struct bootflow 
*bflow)
log_debug("mmc_bootdev: %s\n", env_get("mmc_bootdev"));
 
addr = map_to_sysmem(bflow->buf);
-   ret = image_source_script(addr, NULL);
+   ret = image_source_script(addr, NULL, NULL);
if (ret)
return log_msg_ret("boot", ret);
 
diff --git a/cmd/source.c b/cmd/source.c
index 59738246018..e1ba9a2a578 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -42,7 +42,7 @@ static const char *get_default_image(const void *fit)
 }
 #endif
 
-int image_source_script(ulong addr, const char *fit_uname)
+int image_source_script(ulong addr, const char *fit_uname, const char 
*confname)
 {
ulong   len;
 #if defined(CONFIG_LEGACY_IMAGE_FORMAT)
@@ -112,19 +112,46 @@ int image_source_script(ulong addr, const char *fit_uname)
return 1;
}
 
-   if (!fit_uname)
-   fit_uname = get_default_image(fit_hdr);
-
if (!fit_uname) {
-   puts("No FIT subimage unit name\n");
-   return 1;
-   }
+   /* If confname is empty, use the default */
+   if (confname && *confname)
+   noffset = fit_conf_get_node(fit_hdr, confname);
+   else
+   noffset = fit_conf_get_node(fit_hdr, NULL);
+   if (noffset < 0) {
+   if (!confname)
+   goto fallback;
+   printf("Could not find config %s\n", confname);
+   return 1;
+   }
 
-   /* get script component image node offset */
-   noffset = fit_image_get_node (fit_hdr, fit_uname);
-   if (noffset < 0) {
-   printf ("Can't find '%s' FIT subimage\n", fit_uname);
-   return 1;
+   if (verify && fit_config_verify(fit_hdr, noffset))
+   return 1;
+
+   noffset = fit_conf_get_prop_node(fit_hdr, noffset,
+FIT_SCRIPT_PROP);
+   if (noffset < 0) {
+   if (!confname)
+   goto fallback;
+   printf("Could not find script in %s\n", 
confname);
+

[PATCH v3 2/4] treewide: Use NULL for script image name

Two callers of image_source_script specify an image name. However, both
use the deprecated @ syntax, indicating that they have not been updated
in a while. If CONFIG_FIT_SIGNATURE is enabled, we will reject such
names outright. Back in commit 152576a598c ("stm32mp: stm32prog: handle
U-Boot script in flashlayout alternate"), we even renamed one of the
nodes. Instead of hard-coding a script image name, just use the default
image.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
Reviewed-by: Patrick Delaunay 
---
This has a non-zero chance of breaking something, especially for SDP.
It's not strictly necessary for the following patches, so I can drop it
if there are any issues.

(no changes since v1)

 arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +-
 drivers/usb/gadget/f_sdp.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 007f7131306..3627b4c35c9 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
do_bootz(cmdtp, 0, 4, bootm_argv);
}
if (data->script)
-   image_source_script(data->script, "script@stm32prog");
+   image_source_script(data->script, NULL);
 
if (reset) {
puts("Reset...\n");
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index af4b167e17a..1643d289477 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -868,7 +868,7 @@ static int sdp_handle_in_ep(struct spl_image_info 
*spl_image,
jump_to_image_no_args(&spl_image);
 #else
/* In U-Boot, allow jumps to scripts */
-   image_source_script(sdp_func->jmp_address, "script@1");
+   image_source_script(sdp_func->jmp_address, NULL);
 #endif
}
 
-- 
2.35.1.1320.gc452695387.dirty

[PATCH v3 1/4] test: Add test for source command

This adds a basic test for FIT image handling by the source command.
It's a python test becase we need to run mkimage.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v3:
- Halve the quotes

Changes in v2:
- New

 test/py/tests/source.its | 43 
 test/py/tests/test_source.py | 28 +++
 2 files changed, 71 insertions(+)
 create mode 100644 test/py/tests/source.its
 create mode 100644 test/py/tests/test_source.py

diff --git a/test/py/tests/source.its b/test/py/tests/source.its
new file mode 100644
index 000..3c62f777f17
--- /dev/null
+++ b/test/py/tests/source.its
@@ -0,0 +1,43 @@
+/dts-v1/;
+
+/ {
+description = "FIT image to test the source command";
+#address-cells = <1>;
+
+images {
+default = "script-1";
+
+script-1 {
+data = "echo 1";
+type = "script";
+arch = "sandbox";
+compression = "none";
+};
+
+script-2 {
+data = "echo 2";
+type = "script";
+arch = "sandbox";
+compression = "none";
+};
+
+not-a-script {
+data = "echo 3";
+type = "kernel";
+arch = "sandbox";
+compression = "none";
+};
+};
+
+configurations {
+default = "conf-2";
+
+conf-1 {
+script = "script-1";
+};
+
+conf-2 {
+script = "script-2";
+};
+};
+};
diff --git a/test/py/tests/test_source.py b/test/py/tests/test_source.py
new file mode 100644
index 000..e5ffdfe3fc4
--- /dev/null
+++ b/test/py/tests/test_source.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Sean Anderson 
+
+import os
+import pytest
+import u_boot_utils as util
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_echo')
+@pytest.mark.buildconfigspec('cmd_source')
+@pytest.mark.buildconfigspec('fit')
+def test_source(u_boot_console):
+# Compile our test script image
+cons = u_boot_console
+mkimage = os.path.join(cons.config.build_dir, 'tools/mkimage')
+its = os.path.join(cons.config.source_dir, 'test/py/tests/source.its')
+fit = os.path.join(cons.config.build_dir, 'source.itb')
+util.run_and_log(cons, (mkimage, '-f', its, fit))
+cons.run_command(f'host load hostfs - $loadaddr {fit}')
+
+assert '1' in cons.run_command('source')
+assert '1' in cons.run_command('source :script-1')
+assert '2' in cons.run_command('source :script-2')
+assert 'Fail' in cons.run_command('source :not-a-script || echo Fail')
+
+cons.run_command('fdt addr $loadaddr')
+cons.run_command('fdt rm /images default')
+assert 'Fail' in cons.run_command('source || echo Fail')
-- 
2.35.1.1320.gc452695387.dirty

[PATCH v3 0/4] cmd: source: Support specifying config name

This series adds support for using configs with the source command. See
the third patch for details.

Changes in v3:
- Halve the quotes

Changes in v2:
- Add test for source command

Sean Anderson (4):
  test: Add test for source command
  treewide: Use NULL for script image name
  cmd: source: Clean up a few lines
  cmd: source: Support specifying config name

 .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
 boot/bootmeth_script.c|  2 +-
 cmd/source.c  | 83 +--
 doc/uImage.FIT/source_file_format.txt |  3 +
 drivers/usb/gadget/f_sdp.c|  2 +-
 include/image.h   | 19 +++--
 test/py/tests/source.its  | 43 ++
 test/py/tests/test_source.py  | 37 +
 8 files changed, 156 insertions(+), 35 deletions(-)
 create mode 100644 test/py/tests/source.its
 create mode 100644 test/py/tests/test_source.py

-- 
2.35.1.1320.gc452695387.dirty

[PATCH v3 3/4] cmd: source: Clean up a few lines

This simplifies a few lines and corrects an error message.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 cmd/source.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/cmd/source.c b/cmd/source.c
index 698d9f86d96..59738246018 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -128,16 +128,14 @@ int image_source_script(ulong addr, const char *fit_uname)
}
 
if (!fit_image_check_type (fit_hdr, noffset, IH_TYPE_SCRIPT)) {
-   puts ("Not a image image\n");
+   puts("Not a script image\n");
return 1;
}
 
/* verify integrity */
-   if (verify) {
-   if (!fit_image_verify(fit_hdr, noffset)) {
-   puts ("Bad Data Hash\n");
-   return 1;
-   }
+   if (verify && !fit_image_verify(fit_hdr, noffset)) {
+   puts("Bad Data Hash\n");
+   return 1;
}
 
/* get script subimage data address and length */
-- 
2.35.1.1320.gc452695387.dirty

Re: [PATCH] usb: Add 1ms delay after first Get Descriptor request

2022-11-03 Thread Janne Grunau

On 2022-10-31 21:57:39 +0100, Marek Vasut wrote:
> On 10/31/22 20:27, Simon Glass wrote:
> > Hi Marek,
> 
> Hi,
> 
> > On Sun, 30 Oct 2022 at 16:38, Marek Vasut  wrote:
> > > 
> > > Logitech Unifying Receiver 046d:c52b bcdDevice 12.10 seems
> > > sensitive about the first Get Descriptor request. If there
> > > are any other requests in the same microframe, the device
> > > reports bogus data, first of the descriptor parts is not
> > > sent to the host. Wait over one microframe duration before
> > > issuing subsequent requests to avoid probe failure with
> > > this device, since it can be used to connect USB keyboards.
> > > 
> > > Signed-off-by: Marek Vasut 
> > > ---
> > > Cc: Janne Grunau 
> > > Cc: Mark Kettenis 
> > > ---
> > >   common/usb.c | 11 +++
> > >   1 file changed, 11 insertions(+)
> > 
> > Is this device complying with the spec or is it broken?

This is not just this device. We have seen this reported with a few 
keyboards on apple silicon devices. Keychron devices are one group I can 
remember.

> > 
> > In any case we need a way to enable/disable this as it will slow down
> > unaffected platforms.
> 
> This makes little difference, since anyone can plug such device into a port
> and suddenly the platform is affected. We cannot really predict what users
> have on their desks.

Would it make sense to limit it to dwc3 host controllers or do you fear 
the same problem could happen with other controllers on fast boards?

In any case patch fixes the problem here as well.

Tested-by: Janne Grunau 

Thanks,

Janne

Re: [PATCH v2 4/4] cmd: source: Support specifying config name

On Thu, Nov 03, 2022 at 02:46:35PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Oct 2022 at 13:37, Tom Rini  wrote:
> >
> > On Mon, Oct 31, 2022 at 01:27:08PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 30 Oct 2022 at 08:40, Tom Rini  wrote:
> > > >
> > > > On Sat, Oct 29, 2022 at 07:44:00PM -0600, Simon Glass wrote:
> > > > > Hi Sean,
> > > > >
> > > > > On Fri, 21 Oct 2022 at 15:04, Sean Anderson  
> > > > > wrote:
> > > > > >
> > > > > > On 10/21/22 4:17 PM, Simon Glass wrote:
> > > > > > > On Thu, 20 Oct 2022 at 13:24, Sean Anderson 
> > > > > > >  wrote:
> > > > > > >>
> > > > > > >> As discussed previously [1,2], the source command is not safe to 
> > > > > > >> use with
> > > > > > >> verified boot unless there is a key with required = "images" 
> > > > > > >> (which has its
> > > > > > >> own problems). This is because if such a key is absent, 
> > > > > > >> signatures are
> > > > > > >> verified but not required. It is assumed that configuration 
> > > > > > >> nodes will
> > > > > > >> provide the signature. Because the source command does not use
> > > > > > >> configurations to determine the image to source, effectively no
> > > > > > >> verification takes place.
> > > > > > >>
> > > > > > >> To address this, allow specifying configuration nodes. We use 
> > > > > > >> the same
> > > > > > >> syntax as the bootm command (helpfully provided for us by 
> > > > > > >> fit_parse_conf).
> > > > > > >> By default, we first try the default config and then the default 
> > > > > > >> image. To
> > > > > > >> force using a config, # must be present in the command (e.g. 
> > > > > > >> `source
> > > > > > >> $loadaddr#my-conf`). For convenience, the config may be omitted, 
> > > > > > >> just like
> > > > > > >> the address may be (e.g. `source \#`). This also works for images
> > > > > > >> (`source \:` behaves exactly like `source` currently does).
> > > > > > >>
> > > > > > >> [1] 
> > > > > > >> https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9ee...@prevas.dk/
> > > > > > >> [2] 
> > > > > > >> https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005...@gmail.com/
> > > > > > >>
> > > > > > >> Signed-off-by: Sean Anderson 
> > > > > > >> ---
> > > > > > >>
> > > > > > >> (no changes since v1)
> > > > > > >>
> > > > > > >>  .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
> > > > > > >>  boot/bootmeth_script.c|  2 +-
> > > > > > >>  cmd/source.c  | 73 
> > > > > > >> +--
> > > > > > >>  doc/uImage.FIT/source_file_format.txt |  3 +
> > > > > > >>  drivers/usb/gadget/f_sdp.c|  2 +-
> > > > > > >>  include/image.h   | 19 +++--
> > > > > > >>  test/py/tests/test_source.py  | 11 ++-
> > > > > > >>  7 files changed, 82 insertions(+), 30 deletions(-)
> > > > > > >
> > > > > > > Reviewed-by: Simon Glass 
> > > > > > >
> > > > > > > But please use single quotes in Python. Double quotes should only 
> > > > > > > be
> > > > > > > used when the string includes single quotes.
> > > > > > >
> > > > > >
> > > > > > Do we have a style guide for python? Judging by `git grep '"' 
> > > > > > '**.py'`,
> > > > > > double quoting is endemic. IMO single quotes should be used for
> > > > > > identifiers (or things which would be enums in C), and double quotes
> > > > > > elsewhere. But if you want to go the other way, perhaps add 
> > > > > > something
> > > > > > to checkpatch.
> > > > >
> > > > > Well we use PEP8, with single quotes used for nearly everything. The
> > > > > exceptions are the one I mentioned, and module/function comments.
> > > > >
> > > > > Do we use checkpatch for Python?
> > > >
> > > > Is there a standard python PEP8 checking tool? We should see if
> > > > upstream is interested in a flag or similar to call another tool for
> > > > python linting.
> > >
> > > Yes this is pylint and we do already use it, but not in patman so far.
> > > It would be a good thing to add.
> >
> > I'd start by trying to put it in checkpatch.pl and seeing if upstream is
> > interested, the kernel has a bunch of python tools too these days.
> 
> Oh dear that seems a bit tricky. Checkpatch does its own checking of C
> patches. It would be better to just call pylint I think. Adding a call
> to pylint from checkpatch seems odd, but perhaps it would fly? I don't
> know how the output would work though. So I think adding to patman
> makes more sense.

Yes, sorry, I was suggesting that checkpatch.pl call out to pylint. I
assumed it would be straightforward as it already calls out to other
tools for things like SPDX tag checking. 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] docs: Add a basic security document

On Thu, Nov 03, 2022 at 09:05:59PM +0100, Heinrich Schuchardt wrote:
> On 11/3/22 19:25, Tom Rini wrote:
> > Based loosely on the Linux kernel
> > Documentation/admin-guide/security-bugs.rst file, create a basic
> > security document for U-Boot.  In sum, security issues should be
> > disclosed in public on the mailing list if at all possible as an initial
> > position.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> >   doc/develop/index.rst|  1 +
> >   doc/develop/security.rst | 32 
> >   2 files changed, 33 insertions(+)
> >   create mode 100644 doc/develop/security.rst
> > 
> > diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> > index 5934d9ffb115..04322efe59fd 100644
> > --- a/doc/develop/index.rst
> > +++ b/doc/develop/index.rst
> > @@ -15,6 +15,7 @@ General
> >  process
> >  release_cycle
> >  system_configuration
> > +   security
> 
> Should we get this into alphabetic order?
> 

Whoops, can you fix when applying please?

> >  sending_patches
> > 
> >   Implementation
> > diff --git a/doc/develop/security.rst b/doc/develop/security.rst
> > new file mode 100644
> > index ..84b130646f31
> > --- /dev/null
> > +++ b/doc/develop/security.rst
> > @@ -0,0 +1,32 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +Handling of security vulnerabilities
> > +
> > +
> > +The U-Boot project takes security very seriously.  As such, we'd like to 
> > know
> > +when a security bug is found so that it can be fixed and disclosed as 
> > quickly
> > +as possible.
> > +
> > +Contact
> > +---
> > +
> > +The preferred initial point of contact is to send email to
> > +`u-boot@lists.denx.de` and use `scripts/get_maintainers.pl` to also 
> > include any
> > +relevant custodians. In addition, Tom Rini should be contacted at
> > +`tr...@konsulko.com`.
> > +
> > +CVE assignment
> > +--
> > +
> > +The U-Boot project cannot directly assign CVEs, nor do we require them for
> > +reports or fixes, as this can needlessly complicate the process and may 
> > delay
> > +the bug handling. If a reporter wishes to have a CVE identifier assigned 
> > ahead
> > +of public disclosure, they will need to coordinate this on their own.  When
> > +such a CVE identifier is known before a patch is provided, it is desirable 
> > to
> > +mention it in the commit message if the reporter agrees.
> > +
> > +Non-disclosure agreements
> > +-
> > +
> > +The U-Boot project is not a formal body and therefore unable to enter any
> > +non-disclosure agreements.
> 
> Otherwise
> Reviewed-by: Heinrich Schuchardt 

-- 
Tom


signature.asc
Description: PGP signature

Re: double quoted strings in env.txt files

Hi Holger,

On Thu, 3 Nov 2022 at 02:18, Holger Brunck
 wrote:
>
> Hi all,
> I currently try to convert some boards to the new env.txt files and this 
> works quite well so far.
> But I encountered one problem which I am not sure how to solve it.
>
> If I  have some string in a Kconfig file defined like:
> config KM_DEF_NETDEV
>string "Default Netdevice"
>default "eth0"
>
> When I use this config now in one of the env.txt files:
> netdev=CONFIG_KM_DEF_NETDEV
>
> I end up with:
> netdev="eth0"
> formerly in the environment I had:
> netdev=eth0
>
> So in this case I would like to strip away the double quoted string and I 
> don't see that
> there is a way to do so. Surely there would be some workarounds to solve
> this but as I have this at several places and I can imagine that this will 
> hit others too,
> it might be good to think about a general way to solve this.
> For example we could add a tag around these CONFIG options in such cases
> which then can be parsed in the script processing the env.txt to strip away 
> the double
> quotes.
>
> Any ideas about this? Or is there already a way to solve this problem which I 
> miss?

I am not sure how to solve this in general, since sometimes we need
the quotes. But I will send a patch that can solve it for this
particular case.

Regards,
SImon

Re: [PATCH v2 4/4] cmd: source: Support specifying config name

Hi Tom,

On Mon, 31 Oct 2022 at 13:37, Tom Rini  wrote:
>
> On Mon, Oct 31, 2022 at 01:27:08PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 30 Oct 2022 at 08:40, Tom Rini  wrote:
> > >
> > > On Sat, Oct 29, 2022 at 07:44:00PM -0600, Simon Glass wrote:
> > > > Hi Sean,
> > > >
> > > > On Fri, 21 Oct 2022 at 15:04, Sean Anderson  
> > > > wrote:
> > > > >
> > > > > On 10/21/22 4:17 PM, Simon Glass wrote:
> > > > > > On Thu, 20 Oct 2022 at 13:24, Sean Anderson 
> > > > > >  wrote:
> > > > > >>
> > > > > >> As discussed previously [1,2], the source command is not safe to 
> > > > > >> use with
> > > > > >> verified boot unless there is a key with required = "images" 
> > > > > >> (which has its
> > > > > >> own problems). This is because if such a key is absent, signatures 
> > > > > >> are
> > > > > >> verified but not required. It is assumed that configuration nodes 
> > > > > >> will
> > > > > >> provide the signature. Because the source command does not use
> > > > > >> configurations to determine the image to source, effectively no
> > > > > >> verification takes place.
> > > > > >>
> > > > > >> To address this, allow specifying configuration nodes. We use the 
> > > > > >> same
> > > > > >> syntax as the bootm command (helpfully provided for us by 
> > > > > >> fit_parse_conf).
> > > > > >> By default, we first try the default config and then the default 
> > > > > >> image. To
> > > > > >> force using a config, # must be present in the command (e.g. 
> > > > > >> `source
> > > > > >> $loadaddr#my-conf`). For convenience, the config may be omitted, 
> > > > > >> just like
> > > > > >> the address may be (e.g. `source \#`). This also works for images
> > > > > >> (`source \:` behaves exactly like `source` currently does).
> > > > > >>
> > > > > >> [1] 
> > > > > >> https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9ee...@prevas.dk/
> > > > > >> [2] 
> > > > > >> https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005...@gmail.com/
> > > > > >>
> > > > > >> Signed-off-by: Sean Anderson 
> > > > > >> ---
> > > > > >>
> > > > > >> (no changes since v1)
> > > > > >>
> > > > > >>  .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
> > > > > >>  boot/bootmeth_script.c|  2 +-
> > > > > >>  cmd/source.c  | 73 
> > > > > >> +--
> > > > > >>  doc/uImage.FIT/source_file_format.txt |  3 +
> > > > > >>  drivers/usb/gadget/f_sdp.c|  2 +-
> > > > > >>  include/image.h   | 19 +++--
> > > > > >>  test/py/tests/test_source.py  | 11 ++-
> > > > > >>  7 files changed, 82 insertions(+), 30 deletions(-)
> > > > > >
> > > > > > Reviewed-by: Simon Glass 
> > > > > >
> > > > > > But please use single quotes in Python. Double quotes should only be
> > > > > > used when the string includes single quotes.
> > > > > >
> > > > >
> > > > > Do we have a style guide for python? Judging by `git grep '"' 
> > > > > '**.py'`,
> > > > > double quoting is endemic. IMO single quotes should be used for
> > > > > identifiers (or things which would be enums in C), and double quotes
> > > > > elsewhere. But if you want to go the other way, perhaps add something
> > > > > to checkpatch.
> > > >
> > > > Well we use PEP8, with single quotes used for nearly everything. The
> > > > exceptions are the one I mentioned, and module/function comments.
> > > >
> > > > Do we use checkpatch for Python?
> > >
> > > Is there a standard python PEP8 checking tool? We should see if
> > > upstream is interested in a flag or similar to call another tool for
> > > python linting.
> >
> > Yes this is pylint and we do already use it, but not in patman so far.
> > It would be a good thing to add.
>
> I'd start by trying to put it in checkpatch.pl and seeing if upstream is
> interested, the kernel has a bunch of python tools too these days.

Oh dear that seems a bit tricky. Checkpatch does its own checking of C
patches. It would be better to just call pylint I think. Adding a call
to pylint from checkpatch seems odd, but perhaps it would fly? I don't
know how the output would work though. So I think adding to patman
makes more sense.

Regards,
Simon

[PATCH] env: Allow string CONFIG options in the text environment

Sometimes it is useful to include a CONFIG option that contains a string.
This is hard to do in general, since in many cases it is useful to have
the quotes around the string so that, for example:

   bootcmd=run CONFIG_BOARD_CMD

becomes

   bootcmd=run "boot_board"

But for the special case where there is a single quoted, it seems
reasonable to suppress the quotes, so that:

   board=CONFIG_SYS_BOARD

becomes

   board=sandbox

Update the script, documentation and tests accordingly.

Signed-off-by: Simon Glass 
---

 doc/usage/environment.rst |  7 ++-
 scripts/env2string.awk|  8 
 test/py/tests/test_env.py | 10 +-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 15897f63dd9..7272c6abbb4 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -55,7 +55,12 @@ variable but assigning to a new one::
 
 This file can include C-style comments. Blank lines and multi-line
 variables are supported, and you can use normal C preprocessor directives
-and CONFIG defines from your board config also.
+and CONFIG defines from your board config also. If the CONFIG value consists of
+a string and this is the only thing in the variable, the quotes will be
+dropped::
+
+   something=CONFIG_SYS_BOARD
+   # where CONFIG_SYS_BOARD is "sandbox" this becomes: something=sandbox
 
 For example, for snapper9260 you would create a text file called
 `board/bluewater/snapper9260.env` containing the environment text.
diff --git a/scripts/env2string.awk b/scripts/env2string.awk
index de470a49941..3a0fac47d07 100644
--- a/scripts/env2string.awk
+++ b/scripts/env2string.awk
@@ -43,6 +43,14 @@ NF {
var = substr($0, 1, RLENGTH - 1)
env = substr($0, RLENGTH + 1)
 
+   # If the env value consists entirely of a quoted string, drop
+   # the quotes. This handles things like fred=CONFIG_SYS_BOARD
+   # which would otherwise result in fred=\"sandbox\" in this
+   # output and fred="sandbox" in the final environment.
+   if (length(env) != 0 && match(env, /^\\"([^"]*)\\"$/)) {
+   env = substr(env, RSTART + 2, RLENGTH - 4)
+   }
+
# Deal with += which concatenates the new string to the existing
# variable. Again we are careful to use POSIX match()
if (length(env) != 0 && match(var, "^(.*)[+]$")) {
diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
index 6d08565f0b5..9bec12a2269 100644
--- a/test/py/tests/test_env.py
+++ b/test/py/tests/test_env.py
@@ -588,8 +588,16 @@ e=456
 m+= 456''', 'e=456\\0m=123 456\\0')
 
 # contains quotes
+check_script('''fred=run "my var"
+mary=another"''', 'fred=run \\"my var\\"\\0mary=another\\"\\0')
+
+# contains only a quoted strings, so quotes are removed
 check_script('''fred="my var"
-mary=another"''', 'fred=\\"my var\\"\\0mary=another\\"\\0')
+mary=another"''', 'fred=my var\\0mary=another\\"\\0')
+
+# contains more than one quoted string
+check_script('''fred="my var" or "this var"
+mary=another"''', 'fred=\\"my var\\" or \\"this var\\"\\0mary=another\\"\\0')
 
 # variable name ending in +
 check_script('''fred\\+=my var
-- 
2.38.1.431.g37b22c650d-goog

Re: [PATCH 00/24] bootstd: Add a boot menu

Hi Heinrich,

On Mon, 17 Oct 2022 at 15:23, Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Mon, 17 Oct 2022 at 15:11, Heinrich Schuchardt  wrote:
> >
> > On 10/17/22 22:29, Simon Glass wrote:
> > > So far standard boot lacks a boot menu, although it is possible to create
> > > a rudimentary one using the existing 'bootmenu' command.
> > >
> > > Even then, this text-based menu offer only basic functionality and does
> > > not take full advantage of the displays which are common on many devices.
> > >
> > > This series provides a 'bootflow menu' command which allows the user to
> > > select from the available bootflows. An attempt is made to show the name
> > > of the available operating systems, by reading more information into the
> > > bootflow. A logo can be read also, where supported, so that this can be
> > > presented to the user when an option is highlighted.
> > >
> > > Full use is made of TrueType fonts, if enabled. For cases where only a
> > > serial console is available, it falls back to a simple text-based menu.
> > >
> > > All of this is implementing using a new 'expo' construct, a collection of
> > > scenes (like menu screens) which can be navigated by the user to view
> > > information and select option. This is fairly general and should be able
> > > to cope with a wider array of use cases, with less hacking of the menu
> > > code, such as is currently needed for CMD_BOOTEFI_BOOTMGR.
> > >
> > > Of course it would be possible to enhance the existing menu rather than
> > > creating a new setup. Instead it seems better to make the existing menu
> > > use expo, if code space permits. It avoids the event-loop problem and
> > > should be more extensible, given its loosely coupled components and use of
> > > IDs instead of pointers. Further motivation is provided in the
> > > documentation.
> > >
> > > For now the CLI keypress-decoding code is split out to be used by the new
> > > menu. The key codes defined by menu.h are reused also.
> > >
> > > This is of course just a starting point. Some ideas for future work are
> > > included in the documentation.
> >
> > Hello Simon,
> >
> > Linaro's implementation of a boot menu for UEFI booting showed that the
> > current basis of bootmenu is inadequate for properly designing a GUI
> > like user interface.
> >
> > With your patch set you try to overcome this. Your design document in
> > patch 24 identifies a hierarchy of objects expo - scene - design element
> > but otherwise remains rather sketchy to me.
>
> For now the doc is here:
>
> https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?usp=sharing&resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ
>
> >
> > Before investing into code we should a more holistic design perspective.
> >
> > First thing we need to define is our requirements, e.g.
> >
> > ** Which input devices do we want to support in future **
> >
> > - keyboard
> > - mouse
>
> I have patches for mouse, actually.
>
> >
> > ** What type of GUI do we want to support **
> >
> > - text terminal
> > - graphical output
> >
> > ** Which design elements do we need **
> >
> > - lists
> > - trees
> > - grids
> > - menus
> > - labels
> > - buttons
> > - drop down lists
> > - combo boxes
> > - bitmaps
> > - screens (you call them scene)
> > - transactions (you call them expo)
>
> (this series has rudimentary menus, labels and bitmaps, but does not
> support the others)
>
> >
> > ** How do we want to structure our GUI **
> >
> > - Good practice is to clearly separate model, view, and controller.
>
> Expo is the view. Controller is the client code. Model is currently
> the expo, updated by the controller. That part of it needs though if
> we are to expand the capabilities of this effort.
>
> >
> > ** Which constraints do we have to observe? **
> >
> > - How much is the code base allowed to grow?
> > - Who will be the long term sponsor and maintainer?
> >
> > After having this rough cut overview we may start with a draft
> > implementation and detail our design document.
> >
> > How do you plan to organize the design work?
>
> See also the bottom of the docs for some future work, also whether we
> should consider using a GUI library like Nuklear in the future:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20221017203000.2207887-25-...@chromium.org/
>
> It has evolved since that doc. The doc needs to evolve further.
> Perhaps we can start by agreeing the requirements.

I have updated the doc to accommodate some of your comments and to
indicate exactly how unicode and languages might be supported.

https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ#

Please add any comments to the doc, or put them in this thread.

I'll rework the patches a little and send out a new version.

Regards,
Simon

Re: [PATCH] docs: Add a basic security document

Hi Tom,

On Thu, 3 Nov 2022 at 12:25, Tom Rini  wrote:
>
> Based loosely on the Linux kernel
> Documentation/admin-guide/security-bugs.rst file, create a basic
> security document for U-Boot.  In sum, security issues should be
> disclosed in public on the mailing list if at all possible as an initial
> position.
>
> Signed-off-by: Tom Rini 
> ---
>  doc/develop/index.rst|  1 +
>  doc/develop/security.rst | 32 
>  2 files changed, 33 insertions(+)
>  create mode 100644 doc/develop/security.rst

Reviewed-by: Simon Glass 

>
> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> index 5934d9ffb115..04322efe59fd 100644
> --- a/doc/develop/index.rst
> +++ b/doc/develop/index.rst
> @@ -15,6 +15,7 @@ General
> process
> release_cycle
> system_configuration
> +   security
> sending_patches
>
>  Implementation
> diff --git a/doc/develop/security.rst b/doc/develop/security.rst
> new file mode 100644
> index ..84b130646f31
> --- /dev/null
> +++ b/doc/develop/security.rst
> @@ -0,0 +1,32 @@
> +.. SPDX-License-Identifier: GPL-2.0+:
> +
> +Handling of security vulnerabilities
> +
> +
> +The U-Boot project takes security very seriously.  As such, we'd like to know
> +when a security bug is found so that it can be fixed and disclosed as quickly
> +as possible.
> +
> +Contact
> +---
> +
> +The preferred initial point of contact is to send email to
> +`u-boot@lists.denx.de` and use `scripts/get_maintainers.pl` to also include 
> any

link to patman docs?

:doc:`doc/develop/sending_patches`

> +relevant custodians. In addition, Tom Rini should be contacted at
> +`tr...@konsulko.com`.
> +
> +CVE assignment
> +--
> +
> +The U-Boot project cannot directly assign CVEs, nor do we require them for
> +reports or fixes, as this can needlessly complicate the process and may delay
> +the bug handling. If a reporter wishes to have a CVE identifier assigned 
> ahead
> +of public disclosure, they will need to coordinate this on their own.  When
> +such a CVE identifier is known before a patch is provided, it is desirable to
> +mention it in the commit message if the reporter agrees.
> +
> +Non-disclosure agreements
> +-
> +
> +The U-Boot project is not a formal body and therefore unable to enter any
> +non-disclosure agreements.
> --
> 2.25.1
>

Regards,
Simon

Re: [PATCH] docs: Add a basic security document

2022-11-03 Thread Heinrich Schuchardt


On 11/3/22 19:25, Tom Rini wrote:

Based loosely on the Linux kernel
Documentation/admin-guide/security-bugs.rst file, create a basic
security document for U-Boot.  In sum, security issues should be
disclosed in public on the mailing list if at all possible as an initial
position.

Signed-off-by: Tom Rini 
---
  doc/develop/index.rst|  1 +
  doc/develop/security.rst | 32 
  2 files changed, 33 insertions(+)
  create mode 100644 doc/develop/security.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 5934d9ffb115..04322efe59fd 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -15,6 +15,7 @@ General
 process
 release_cycle
 system_configuration
+   security


Should we get this into alphabetic order?


 sending_patches

  Implementation
diff --git a/doc/develop/security.rst b/doc/develop/security.rst
new file mode 100644
index ..84b130646f31
--- /dev/null
+++ b/doc/develop/security.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Handling of security vulnerabilities
+
+
+The U-Boot project takes security very seriously.  As such, we'd like to know
+when a security bug is found so that it can be fixed and disclosed as quickly
+as possible.
+
+Contact
+---
+
+The preferred initial point of contact is to send email to
+`u-boot@lists.denx.de` and use `scripts/get_maintainers.pl` to also include any
+relevant custodians. In addition, Tom Rini should be contacted at
+`tr...@konsulko.com`.
+
+CVE assignment
+--
+
+The U-Boot project cannot directly assign CVEs, nor do we require them for
+reports or fixes, as this can needlessly complicate the process and may delay
+the bug handling. If a reporter wishes to have a CVE identifier assigned ahead
+of public disclosure, they will need to coordinate this on their own.  When
+such a CVE identifier is known before a patch is provided, it is desirable to
+mention it in the commit message if the reporter agrees.
+
+Non-disclosure agreements
+-
+
+The U-Boot project is not a formal body and therefore unable to enter any
+non-disclosure agreements.


Otherwise
Reviewed-by: Heinrich Schuchardt

Re: Running u-boot standalone hello_world on an image partition with qemu

Hi Lists,

On Thu, 3 Nov 2022 at 05:11, Lists Nick Betteridge
 wrote:
>
> I'm developing on an ubuntu x86 machine, trying to run the u-boot
> hello_world standalone application which resides on an image |sd.img|
> which contains a partition
>
> I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig|
>
> I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom
> -drive format=raw,file=sd.img"|
>
> u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits
> a command. If I type |"ext4ls ide 0:1|", I can clearly see
> hello_world.bin (|3932704 hello_world.bin|).
>
> When I do a |ext4load ide 0:1 0x4 hello_world.bin| (in preparation
> for |go 4 This is another test|), qemu/u-boot restarts.
>
> 0x4 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86.
>
> I have also tried making an image of hello_world |"mkimage -n "Hello
> stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x4 -d
> hello_world.bin -v hello_world.img|" and tried to load the image into
> 0x4 with the intention of using |bootm| in case of cache issues -
> qemu/u-boot still resets.
>
> Could anyone possibly point out the basic mistake I'm making?

Is the app linked to start at that address. Could you try 'dcache off'
before the 'go'? Do you have a debugger?

Regards,
Simon

[PATCH] docs: Add a basic security document

Based loosely on the Linux kernel
Documentation/admin-guide/security-bugs.rst file, create a basic
security document for U-Boot.  In sum, security issues should be
disclosed in public on the mailing list if at all possible as an initial
position.

Signed-off-by: Tom Rini 
---
 doc/develop/index.rst|  1 +
 doc/develop/security.rst | 32 
 2 files changed, 33 insertions(+)
 create mode 100644 doc/develop/security.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 5934d9ffb115..04322efe59fd 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -15,6 +15,7 @@ General
process
release_cycle
system_configuration
+   security
sending_patches
 
 Implementation
diff --git a/doc/develop/security.rst b/doc/develop/security.rst
new file mode 100644
index ..84b130646f31
--- /dev/null
+++ b/doc/develop/security.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Handling of security vulnerabilities
+
+
+The U-Boot project takes security very seriously.  As such, we'd like to know
+when a security bug is found so that it can be fixed and disclosed as quickly
+as possible.
+
+Contact
+---
+
+The preferred initial point of contact is to send email to
+`u-boot@lists.denx.de` and use `scripts/get_maintainers.pl` to also include any
+relevant custodians. In addition, Tom Rini should be contacted at
+`tr...@konsulko.com`.
+
+CVE assignment
+--
+
+The U-Boot project cannot directly assign CVEs, nor do we require them for
+reports or fixes, as this can needlessly complicate the process and may delay
+the bug handling. If a reporter wishes to have a CVE identifier assigned ahead
+of public disclosure, they will need to coordinate this on their own.  When
+such a CVE identifier is known before a patch is provided, it is desirable to
+mention it in the commit message if the reporter agrees.
+
+Non-disclosure agreements
+-
+
+The U-Boot project is not a formal body and therefore unable to enter any
+non-disclosure agreements.
-- 
2.25.1

Enabling CCGR of eCSPI bus

2022-11-03 Thread Shashank Anand


Hi U-Boot community,

I am attempting to use the eCSPI bus on a compulab imx8mm iot-gateway 
device to communicate with a tpm module. I am using the MXC SPI driver 
in U-Boot for this.


The eCSPI bus initially did not work and timed out. After debugging I 
found that the reason for this is that the corresponding Clock Control 
Gating Register (CCGR) of the eCSPI bus was disabled. Manually enabling 
this in the driver code fixed the issue.


How do I enable the CCGR without having to modify the driver code? 
Ideally I would like to get it enabled by simply modifying the DTS of 
the device.


Thanks!

Regards,

Shashank Anand

0x4B2A8203.asc
Description: application/pgp-keys

Re: Running u-boot standalone hello_world on an image partition with qemu

On Thu, Nov 03, 2022 at 09:54:40AM +, Lists Nick Betteridge wrote:

> I'm developing on an ubuntu x86 machine, trying to run the u-boot
> hello_world standalone application which resides on an image |sd.img| which
> contains a partition
> 
> I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig|
> 
> I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom
> -drive format=raw,file=sd.img"|
> 
> u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a
> command. If I type |"ext4ls ide 0:1|", I can clearly see hello_world.bin
> (|3932704 hello_world.bin|).
> 
> When I do a |ext4load ide 0:1 0x4 hello_world.bin| (in preparation for
> |go 4 This is another test|), qemu/u-boot restarts.
> 
> 0x4 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86.
> 
> I have also tried making an image of hello_world |"mkimage -n "Hello stand
> alone" -A x86_64 -O u-boot -T standalone -C none -a 0x4 -d
> hello_world.bin -v hello_world.img|" and tried to load the image into
> 0x4 with the intention of using |bootm| in case of cache issues -
> qemu/u-boot still resets.
> 
> Could anyone possibly point out the basic mistake I'm making?

Using the standalone API on platforms where we support UEFI applications
is strongly discouraged. If some part of the UEFI support in U-Boot is
lacking for your use case we strongly encourage patches adding support
for that (as we're doing right now for enhancing SPI support).

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] arm: dts: ti: k3-am64-main: Add RTI watchdog nodes

On Thu, Nov 03, 2022 at 12:27:39AM -0500, Nishanth Menon wrote:
> On 13:15-20221026, Christian Gmeiner wrote:
> > Add the needed bus mappings for the two main RTI memory ranges and
> > the required device tree nodes in the main domain.
> > 
> > Same as kernel commit 6dd8457dc20693e2ba9054c171499b22664fd4e7
> > 
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  arch/arm/dts/k3-am64-main.dtsi | 18 ++
> >  arch/arm/dts/k3-am64.dtsi  |  2 ++
> >  2 files changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
> > index 02c3fdf9cc..57b0f53ac9 100644
> > --- a/arch/arm/dts/k3-am64-main.dtsi
> > +++ b/arch/arm/dts/k3-am64-main.dtsi
> > @@ -859,4 +859,22 @@
> > clock-names = "fck";
> > max-functions = /bits/ 8 <1>;
> > };
> > +
> > +   main_rti0: watchdog@e00 {
> > +   compatible = "ti,j7-rti-wdt";
> > +   reg = <0x00 0xe00 0x00 0x100>;
> > +   clocks = <&k3_clks 125 0>;
> > +   power-domains = <&k3_pds 125 TI_SCI_PD_EXCLUSIVE>;
> > +   assigned-clocks = <&k3_clks 125 0>;
> > +   assigned-clock-parents = <&k3_clks 125 2>;
> > +   };
> > +
> > +   main_rti1: watchdog@e01 {
> > +   compatible = "ti,j7-rti-wdt";
> > +   reg = <0x00 0xe01 0x00 0x100>;
> > +   clocks = <&k3_clks 126 0>;
> > +   power-domains = <&k3_pds 126 TI_SCI_PD_EXCLUSIVE>;
> > +   assigned-clocks = <&k3_clks 126 0>;
> > +   assigned-clock-parents = <&k3_clks 126 2>;
> > +   };
> >  };
> > diff --git a/arch/arm/dts/k3-am64.dtsi b/arch/arm/dts/k3-am64.dtsi
> > index 7aa94d5a6e..053e7f42e9 100644
> > --- a/arch/arm/dts/k3-am64.dtsi
> > +++ b/arch/arm/dts/k3-am64.dtsi
> > @@ -70,6 +70,8 @@
> >  <0x00 0x0100 0x00 0x0100 0x00 0x02330400>, /* 
> > First peripheral window */
> >  <0x00 0x0800 0x00 0x0800 0x00 0x0020>, /* 
> > Main CPSW */
> >  <0x00 0x0d00 0x00 0x0d00 0x00 0x0080>, /* 
> > PCIE_CORE */
> > +<0x00 0x0e00 0x00 0x0e00 0x00 0x0100>, /* 
> > Main RTI0 */
> > +<0x00 0x0e01 0x00 0x0e01 0x00 0x0100>, /* 
> > Main RTI1 */
> >  <0x00 0x0f00 0x00 0x0f00 0x00 0x00c44200>, /* 
> > Second peripheral window */
> >  <0x00 0x2000 0x00 0x2000 0x00 0x0a008000>, /* 
> > Third peripheral window */
> >  <0x00 0x3000 0x00 0x3000 0x00 0x000bc100>, /* 
> > ICSSG0/1 */
> > -- 
> > 2.37.3
> > 
> As I responded to
> https://lore.kernel.org/u-boot/20221103052101.l77rsp4siutbe72n@scientist/
> as well..
> 
> I think we need to sync upstream kernel dts back into u-boot -> we will end up
> having more of these cherry-pick cases otherwise.

Sorry, I had this queued up to merge and missed this email.  How would
you like to proceed?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mx6cuboxi: migrate to DM_SERIAL

On Thu, Nov 03, 2022 at 06:03:38PM +0200, Baruch Siach wrote:

> Add the needed DT overrides to enable UART in SPL.
> 
> Cc: Fabio Estevam 
> Signed-off-by: Baruch Siach 

Tested-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] led: led_pwm: typo 'iverted' on code comment

On Thu, Oct 27, 2022 at 02:25:37PM +0800, Nylon Chen wrote:

> change iverted to inverted.
> 
> Signed-off-by: Nylon Chen 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/4] configs: evb-ast2500: Set environment in SPI flash

On Wed, Oct 26, 2022 at 03:11:15PM +0200, Cédric Le Goater wrote:

> We now have a SPI flash driver. Let's use it.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Joel Stanley 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/4] configs: evb-ast2500: Remove MMC support from default settings

On Wed, Oct 26, 2022 at 03:11:12PM +0200, Cédric Le Goater wrote:

> This saves ~50K in the resulting u-boot.bin file which is important to
> fit in the U-Boot partition defined in the flash layout of upstream Linux.
> 
> Signed-off-by: Cédric Le Goater 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/4] configs: evb-ast2500: Add support for FIT format

On Wed, Oct 26, 2022 at 03:11:14PM +0200, Cédric Le Goater wrote:

> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Joel Stanley 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/4] configs: evb-ast2500: Adjust boot command

On Wed, Oct 26, 2022 at 03:11:13PM +0200, Cédric Le Goater wrote:

> Loading a kernel image is enough.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Joel Stanley 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] arm: dts: ti: k3-am64-main: Add RTI watchdog nodes

On Wed, Oct 26, 2022 at 01:15:55PM +0200, Christian Gmeiner wrote:

> Add the needed bus mappings for the two main RTI memory ranges and
> the required device tree nodes in the main domain.
> 
> Same as kernel commit 6dd8457dc20693e2ba9054c171499b22664fd4e7
> 
> Signed-off-by: Christian Gmeiner 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] treewide: Remove the unnecessary space before semicolon

On Wed, Oct 26, 2022 at 12:40:07PM +0800, Bin Meng wrote:

> %s/return ;/return;
> 
> Signed-off-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] cmd: eeprom: don't truncate target address at 32-bit

On Sun, Oct 23, 2022 at 12:28:12PM +0300, Baruch Siach wrote:

> On 64-bit platforms where int is 32-bit wide, the eeprom command
> parse_numeric_param() routine truncates the memory address parameter to
> the lower 32-bit. Make parse_numeric_param() return long to allow
> read/write of addresses beyond the lower 4GB.
> 
> Signed-off-by: Baruch Siach 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] xen: pvblock: Use uclass_probe_all

On Sat, Oct 22, 2022 at 04:33:05PM +0200, Michal Suchanek wrote:

> Also eliminate useless code and variables.
> 
> Signed-off-by: Michal Suchanek 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] highbank: switch to use the Arm SP804 DM_TIMER driver

On Thu, Oct 20, 2022 at 11:10:25PM +0100, Andre Przywara wrote:

> So far the Calxeda machines were using the CONFIG_SYS_TIMER_* macros to
> simply hardcode the address of the counter register of the SP804 timer.
> This method is deprecated and scheduled for removal.
> 
> Use the newly introduced SP804 DM_TIMER driver to provide timer
> functionality on Highbank and Midway machines. The base address and base
> frequency are taken from the devicetree.
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/3] highbank: scan into hb_sregs DT subnodes

On Thu, Oct 20, 2022 at 11:10:24PM +0100, Andre Przywara wrote:

> The DT used for Calxeda Highbank and Midway systems exposes a "system
> registers" block, modeled as a DT subnode.
> This includes several clocks, including the two fixed clocks for the
> main oscillator and timer.
> 
> So far U-Boot was ignorant of this special construct (a "clocks" node
> within the "hb-sregs" node), as it didn't need the PLL clocks in there.
> But that also meant we lost the fixed clocks, which form the base for
> the UART baudrate generator and also the SP804 timer.
> 
> To allow the generic PL011 and SP804 driver to read the clock rate,
> add a simple bus driver, which triggers the DT node discovery inside this
> special node. As we only care about the fixed clocks (we don't have
> drivers for the PLLs anyway), just ignore the address translation (for
> now).
> 
> The binding is described in bindings/arm/calxeda/hb-sregs.yaml, the DT
> snippet in question looks like:
> 
> ===
>   sregs@fff3c000 {
>   compatible = "calxeda,hb-sregs";
>   reg = <0xfff3c000 0x1000>;
> 
>   clocks {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   osc: oscillator {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
>   clock-frequency = <3000>;
>   };
>   
>   };
>   };
> ===
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1] pinctrl: nuvoton: Add NPCM8xx pinctrl driver

On Tue, Oct 11, 2022 at 04:09:13PM +0800, Jim Liu wrote:

> Add Nuvoton BMC NPCM845 Pinmux and Pinconf support.
> 
> Signed-off-by: Jim Liu 
> Signed-off-by: Stanley Chu 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] timer: add SP804 UCLASS timer driver

On Thu, Oct 20, 2022 at 11:10:23PM +0100, Andre Przywara wrote:

> The "Arm Ltd. Dual-Timer Module (SP804)" is a simple 32-bit count-down
> timer IP with interrupt functionality, and is used in some SoCs from
> various vendors.
> 
> Add a simple DM compliant timer driver, to allow users of the SP804 to
> switch to DM_TIMER.
> 
> This relies on the input clock to be accessible via the DM clock
> framework, which should be fine as we probably look at fixed-clock's
> here anyway.
> We re-program the control register in the probe() function, but keep
> the divider in place, in case this has been set to something on purpose
> before.
> 
> The TRM for the timer IP can be found here:
> https://developer.arm.com/documentation/ddi0271/latest
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] arm: smh: Allow semihosting trap calls to be inlined

On Wed, Oct 05, 2022 at 05:38:49PM +0100, Andre Przywara wrote:

> Currently our semihosting trap function is somewhat fragile: we rely
> on the current compiler behaviour to assign the second inline assembly
> argument to the next free register (r1/x1), which happens to be the
> "addr" argument to the smh_trap() function (per the calling convention).
> I guess this is also the reason for the noinline attribute.
> 
> Make it explicit what we want: the "addr" argument needs to go into r1,
> so we add another register variable. This allows to drop the "noinline"
> attribute, so now the compiler beautifully inlines just the trap
> instruction directly into the calling function.
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/3] arm: smh: Make semihosting trap calls more robust

On Wed, Oct 05, 2022 at 05:38:48PM +0100, Andre Przywara wrote:

> Commit f4b540e25c5c("arm: smh: Fix uninitialized parameters with newer
> GCCs") added a memory clobber to the semihosting inline assembly trap
> calls, to avoid too eager GCC optimisation: when passing a pointer, newer
> compilers couldn't be bothered to actually fill in the structure that it
> pointed to, as this data would seemingly never be used (at least from the
> compiler's point of view).
> But instead of the memory clobber we need to tell the compiler that we are
> passing an *array* instead of some generic pointer, this forces the
> compiler to actually populate the data structure.
> This involves some rather hideous cast, which is best hidden in a macro.
> 
> But regardless of that, we actually need the memory clobber, but for two
> different reasons: explain them in comments.
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] arm: smh: specify Thumb trap instruction

On Wed, Oct 05, 2022 at 05:38:47PM +0100, Andre Przywara wrote:

> The ARM semihosting interface uses different trap instructions for
> different architectures and instruction sets. So far we were using
> AArch64 and ARMv7-M, and had an untested v7-A entry. The latter does
> not work when building for Thumb, as can be verified by using
> qemu_arm_defconfig, then enabling SEMIHOSTING and SYS_THUMB_BUILD:
> ==
> {standard input}:35: Error: invalid swi expression
> {standard input}:35: Error: value of 1193046 too large for field of 2 bytes 
> at 0
> ==
> 
> Fix this by providing the recommended instruction[1] for Thumb, and
> using the ARM instruction only when not building for Thumb. This also
> removes some comment, as QEMU for ARM allows to now test this case.
> Also use the opportunity to clean up the inline assembly, and just define
> the actual trap instruction inside #ifdef's, to improve readability.
> 
> [1] 
> https://developer.arm.com/documentation/dui0471/g/Semihosting/The-semihosting-interface?lang=en
> 
> Signed-off-by: Andre Przywara 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL] u-boot-riscv/master

On Thu, Nov 03, 2022 at 07:04:33AM +, Leo Liang wrote:

> Hi Tom, 
> 
> The following changes since commit c8d9ff634fc429db5acf2f5386ea937f0fef1ae7:
> 
>   Merge branch '2022-10-31-FWU-add-FWU-multi-bank-update-feature-support' 
> (2022-11-01 09:32:21 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-riscv.git

Can you please start including a few line summary of the changes in your
pull requests?

> 
> for you to fetch changes up to 7321bad25f18684b53cff4346543fb2da2a2c0d0:
> 
>   riscv: Update Microchip MPFS Icicle Kit support (2022-11-03 13:27:56 +0800)
> 
> CI result shows no issue: 
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/13999
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-watchdog/master

On Wed, Nov 02, 2022 at 09:46:18AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following watchdog related fixes / enhancements
> from Rasmus:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/22] sunxi: Prepare platform Kconfig to support multiple architectures

2022-11-03 Thread Andre Przywara

On Tue,  1 Nov 2022 00:08:12 -0500
Samuel Holland  wrote:

Hi Samuel,

> sunxi is getting a new RISC-V platform, D1. We want to share as much of
> the existing configuration as possible, to provide a familiar
> environment, DRAM layout, partition layout, etc.
> 
> Because U-Boot includes all architecture Kconfig files at once, we must
> use a symbol outside of both CONFIG_ARM and CONFIG_RISCV to contain
> shared Kconfig options. I chose BOARD_SUNXI, corresponding to the file
> location and somewhat following the BOARD_SPECIFIC_OPTIONS pattern.

many thanks for sending this, indeed our Kconfig deserved some cleanups,
plus we need to fix the woes with RISC-V.
I just skimmed over this for now, and it seems to look good.

I have some gripes with the name BOARD_SUNXI though. Bad enough we have
board-agnostic generic code in board/sunxi, but maybe we shouldn't add to
the confusion. Would PLAT_SUNXI be a better name? After all it's all about
the Allwinner platform (and not even "architecture", for that matter).

> I did a buildman run on this series. The only net option changes are the
> expected ones:
>  - Host-side USB gets enabled on several boards by the first patch
>(emlid_neutis_n5_devboard orangepi_zero2 pinephone pinetab tanix_tx6
>x96_mate teres_i)
>  - CONFIG_BOARD_SUNXI gets added everywhere
>  - CONFIG_SYS_I2C_MVTWSI gets enabled by the corresponding patch
> 
> Andre, please feel free to take any subset of these; they don't all have
> to go in at once. And I'm open to suggestions about what instances of
> ARCH_SUNXI should (not) be converted. Some of them are open to opinion.

Yeah, I will definitely cherry-pick some patches, especially the more
innocent ones. I will run my before/after defconfig comparisons to test
them.

Cheers,
Andre

> I left alone the options in arch/arm/mach-sunxi/Kconfig that are covered
> by other series (MMC CD/USB PHY/power pins, AXP GPIO).
> 
> After this series, the Kconfig changes needed for D1 support are quite
> small, something like this commit:
> https://github.com/smaeul/u-boot/commit/c12cf6c5d72f5327eff793518229ddbd41dcf729.patch
> 
> Adding SUNXI_MINIMUM_DRAM_MB certainly made things nicer. There are a
> few options that probably still need some adjustment to respect it.
> 
> 
> Samuel Holland (22):
>   sunxi: Fix default-enablement of USB host drivers
>   sunxi: Remove unnecessary Kconfig selections
>   sunxi: Add missing dependencies to Kconfig selections
>   sunxi: Hide image type selection if SPL is disabled
>   sunxi: Share the board Kconfig across architectures
>   sunxi: Move most Kconfig selections to the board Kconfig
>   sunxi: Globally enable SUPPORT_SPL
>   sunxi: Downgrade driver selections to implications
>   sunxi: Enable the I2C driver by default
>   sunxi: Move default values to the board Kconfig
>   sunxi: Hide the SUNXI_MINIMUM_DRAM_MB symbol
>   sunxi: Clean up the SPL_STACK_R_ADDR defaults
>   sunxi: Move PRE_CON_BUF_ADDR to the board Kconfig
>   sunxi: Move SPL_BSS_START_ADDR to the board Kconfig
>   sunxi: Move SPL_TEXT_BASE to the board Kconfig
>   sunxi: Move SYS_LOAD_ADDR to the board Kconfig
>   sunxi: Move TEXT_BASE to the board Kconfig
>   sunxi: Move most board options to the board Kconfig
>   env: sunxi: Replace ARCH_SUNXI with BOARD_SUNXI
>   drivers: sunxi: Replace ARCH_SUNXI with BOARD_SUNXI
>   disk: sunxi: Replace ARCH_SUNXI with BOARD_SUNXI
>   spl: sunxi: Replace ARCH_SUNXI with BOARD_SUNXI
> 
>  Kconfig   |   3 -
>  arch/Kconfig  |   1 +
>  arch/arm/Kconfig  |  48 +---
>  arch/arm/mach-sunxi/Kconfig   | 154 ---
>  board/sunxi/Kconfig   | 224 ++
>  boot/Kconfig  |   4 -
>  common/Kconfig|   2 -
>  common/spl/Kconfig|  18 +--
>  disk/Kconfig  |   6 +-
>  drivers/clk/sunxi/Kconfig |   2 +-
>  drivers/fastboot/Kconfig  |  13 +-
>  drivers/gpio/Kconfig  |   2 +-
>  drivers/mmc/Kconfig   |   2 +-
>  drivers/net/phy/Kconfig   |   4 +-
>  drivers/phy/allwinner/Kconfig |   2 +-
>  drivers/pinctrl/sunxi/Kconfig |   2 +-
>  drivers/reset/Kconfig |   2 +-
>  drivers/spi/Kconfig   |   2 +-
>  drivers/usb/Kconfig   |   2 +-
>  drivers/usb/gadget/Kconfig|   8 +-
>  drivers/usb/host/Kconfig  |   2 -
>  drivers/usb/musb-new/Kconfig  |   2 +-
>  drivers/video/Kconfig |   2 +-
>  drivers/watchdog/Kconfig  |   4 +-
>  env/Kconfig   |  12 +-
>  scripts/Makefile.spl  |   2 +-
>  26 files changed, 267 insertions(+), 258 deletions(-)
>

Re: [PATCH] usb: gadget: dfu: Fix the unchecked length field

On Thu, Nov 03, 2022 at 04:22:58PM +0100, Marek Vasut wrote:
> On 11/3/22 05:07, Venkatesh Yadav Abbarapu wrote:
> > DFU implementation does not bound the length field in USB
> > DFU download setup packets, and it does not verify that
> > the transfer direction. Fixing the length and transfer
> > direction.
> > 
> > CVE-2022-2347
> 
> +CC Tom
> 
> Reading through https://seclists.org/oss-sec/2022/q3/41 the disclosure
> timeline at the end, I am really sad that this only reached me (as the USB
> maintainer) now in this form.
> 
> Maybe there should be some dedicated advertised ML for these things ?

A doc/develop/security.rst would be good to have in hopes of getting the
initial inquiries out correctly (I see this one went to several wrong
places). My strong preference is to disclose things in public first as
it's unlikely malicious actors don't already know about an issue. I
don't want a list for the cases where that's not possible for other
reasons, but I'm fine with (continuing) to be the primary point of
contact for issues.

> > Signed-off-by: Venkatesh Yadav Abbarapu 
> 
> Reviewed-by: Marek Vasut 
> 
> Tom, please pick this directly soon.

I see some other USB patches outstanding as well atm, I can grab this
all the same but do you want to make a USB PR with this and a few
others?

-- 
Tom

signature.asc
Description: PGP signature

[PATCH] mx6cuboxi: migrate to DM_SERIAL

Add the needed DT overrides to enable UART in SPL.

Cc: Fabio Estevam 
Signed-off-by: Baruch Siach 
---
 ...mx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 16 
 board/solidrun/mx6cuboxi/mx6cuboxi.c |  3 +++
 configs/mx6cuboxi_defconfig  |  2 +-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..e1cb9b3e89ec 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,22 @@
};
 };
 
+&soc {
+   u-boot,dm-pre-reloc;
+};
+
+&aips1 {
+   u-boot,dm-pre-reloc;
+};
+
+&pinctrl_microsom_uart1 {
+   u-boot,dm-pre-reloc;
+};
+
+&uart1 {
+   u-boot,dm-pre-reloc;
+};
+
 &gpio2 {
u-boot,dm-pre-reloc;
 };
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index debf4f6a3b06..8e80ca6e17e0 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -844,6 +844,9 @@ void board_init_f(ulong dummy)
/* setup GP timer */
timer_init();
 
+   /* Enable device tree and early DM support*/
+   spl_early_init();
+
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
 
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..4fa51a483bfb 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15 
imx6q-hummingboard2-emmc-som-v15"
 CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -68,6 +67,7 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
-- 
2.35.1

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Baruch,

On Thu, Nov 3, 2022 at 12:33 PM Baruch Siach  wrote:

> Without any u-boot,dm-pre-reloc or u-boot,dm-spl? I don't see any for
> wandboard DT files in current master.

Correct, just passing CONFIG_DM_SERIAL=y boots fine on wandboard.

It does not have a imx6qdl-wandboard-u-boot.dtsi currently, so
u-boot,dm-spl is not being passed.

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Fabio,

On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 11:28 AM Fabio Estevam  wrote:
>> On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam  wrote:
>>
>> > Please try using u-boot,dm-spl for all nodes instead.
>>
>> In addition to using u-boot,dm-spl, please try calling
>> spl_early_init() like done here:
>> https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829
>
> Interestingly, on a wandboard I did:
>
> diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
> index 70b4cf9ffaa3..33d9db56e1cb 100644
> --- a/configs/wandboard_defconfig
> +++ b/configs/wandboard_defconfig
> @@ -72,6 +72,7 @@ CONFIG_PINCTRL_IMX6=y
>  CONFIG_DM_PMIC=y
>  CONFIG_DM_PMIC_PFUZE100=y
>  CONFIG_DM_SCSI=y
> +CONFIG_DM_SERIAL=y
>  CONFIG_MXC_UART=y
>  CONFIG_DM_THERMAL=y
>  CONFIG_USB=y
>
> and it boots fine.

Without any u-boot,dm-pre-reloc or u-boot,dm-spl? I don't see any for
wandboard DT files in current master.

baruch

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Fabio,

On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam  wrote:
>
>> Please try using u-boot,dm-spl for all nodes instead.
>
> In addition to using u-boot,dm-spl, please try calling
> spl_early_init() like done here:
> https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829

That did the trick. Thanks.

A patch is forthcoming.

baruch

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH] usb: gadget: dfu: Fix the unchecked length field


On 11/3/22 05:07, Venkatesh Yadav Abbarapu wrote:

DFU implementation does not bound the length field in USB
DFU download setup packets, and it does not verify that
the transfer direction. Fixing the length and transfer
direction.

CVE-2022-2347


+CC Tom

Reading through https://seclists.org/oss-sec/2022/q3/41 the disclosure 
timeline at the end, I am really sad that this only reached me (as the 
USB maintainer) now in this form.


Maybe there should be some dedicated advertised ML for these things ?


Signed-off-by: Venkatesh Yadav Abbarapu 


Reviewed-by: Marek Vasut 

Tom, please pick this directly soon.

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

On Thu, Nov 3, 2022 at 11:28 AM Fabio Estevam  wrote:
>
> Hi Baruch,
>
> On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam  wrote:
>
> > Please try using u-boot,dm-spl for all nodes instead.
>
> In addition to using u-boot,dm-spl, please try calling
> spl_early_init() like done here:
> https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829

Interestingly, on a wandboard I did:

diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
index 70b4cf9ffaa3..33d9db56e1cb 100644
--- a/configs/wandboard_defconfig
+++ b/configs/wandboard_defconfig
@@ -72,6 +72,7 @@ CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_DM_SCSI=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_DM_THERMAL=y
 CONFIG_USB=y

and it boots fine.

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Baruch,

On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam  wrote:

> Please try using u-boot,dm-spl for all nodes instead.

In addition to using u-boot,dm-spl, please try calling
spl_early_init() like done here:
https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Baruch,

On Thu, Nov 3, 2022 at 11:06 AM Baruch Siach  wrote:

> I tried this (see below) but no luck yet. The tbs2910 appears not to use
> SPL. I might be missing an SPL driver.

That's a good point.

imx8mm_evk_defconfig has been converted to DM_SERIAL and it uses SPL.

> +&soc {
> +   u-boot,dm-pre-reloc;

Please try using u-boot,dm-spl for all nodes instead.

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Fabio,

On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 9:29 AM Baruch Siach  wrote:
>> I am trying to migrate the Hummingboard platform to DM_SERIAL. See below
>> what I got so far. Booting this on top of master (as of commit
>> 8bc87a4c5) shows nothing on the serial console. Next thing I plan to try
>> is toggle GPIOs in entry code to see how far the code proceeds.
>>
>> Any idea where to look before I go down that way?
>>
>> Thanks,
>> baruch
>>
>> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi 
>> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> index 400b885e4370..8507b818d4cf 100644
>> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> @@ -15,6 +15,10 @@
>> };
>>  };
>>
>> +&uart1 {
>> +   u-boot,dm-pre-reloc;
>> +};
>
> Here you also need to pass &aips1, &pinctrl_uart1, and &soc.

I tried this (see below) but no luck yet. The tbs2910 appears not to use
SPL. I might be missing an SPL driver.

Thanks for your help,
baruch

diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..e1cb9b3e89ec 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,22 @@
};
 };
 
+&soc {
+   u-boot,dm-pre-reloc;
+};
+
+&aips1 {
+   u-boot,dm-pre-reloc;
+};
+
+&pinctrl_microsom_uart1 {
+   u-boot,dm-pre-reloc;
+};
+
+&uart1 {
+   u-boot,dm-pre-reloc;
+};
+
 &gpio2 {
u-boot,dm-pre-reloc;
 };
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..9d7b2764c969 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15 
imx6q-hummingboard2-emmc-som-v15"
 CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -65,9 +64,11 @@ CONFIG_FEC_MXC=y
 CONFIG_RGMII=y
 CONFIG_MII=y
 CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y

> Please look at the following commit for reference:
>
> commit 8fbca1a8b9b02fbc40147401d9af764e07dc96af
> Author: Fabio Estevam 
> Date:   Tue Mar 15 17:47:05 2022 -0300
>
> tbs2910: Convert to DM_SERIAL
>
> Conversion to DM_SERIAL is mandatory.
>
> Select DM_SERIAL and add a imx6q-tbs2910-u-boot.dtsi file
> that describes the nodes that require dm-pre-reloc, which allows
> the DM model to configure the UART pinctrl early.
>
> Remove the now unneeded board UART initialization.
>
> Signed-off-by: Fabio Estevam 
> Tested-by: Soeren Moch 


-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v2 2/3] arm: dts: rockchip: Separate rockchip-binman.dtsi

2022-11-03 Thread Quentin Schulz

Hi Jagan,

On 11/3/22 13:37, Jagan Teki wrote:

On Thu, 3 Nov 2022 at 15:32, Quentin Schulz
wrote:

Hi Jagan,

On 11/3/22 07:19, Jagan Teki wrote:

rockchip-u-boot.dtsi has the FIT image for the final stage of
binman image creation.

If the actual binman node is part of this dtsi then there are
build issues to use optee as input to this final stage binman
image since optee is built via another binman image creation
unlike ATF built via tools like make_fit_atf.py.

binman: Filename 'u-boot.itb' not found in input path

Fix this by separating binman FIT image in rockchip-binman.dtsi

My understanding is that this is a work-around for something that should
be implemented in binman instead (e.g. dependency between images). If
i'm not mistaken, what you're suggesting is to not build
u-boot-rockchip.bin for some platforms? IIRC the plan for this binary
was that it would apply to all Rockchip platforms, and this patch makes
this "promise" go away.

Not really, no functionality is changed. It is just that we cannot
create the final binman image for optee. It is not possible to
implement in binman alone however if you want to add optee binman
prior to the final binman can be solvable but it makes unnecessary
ifdefs and maintaining many binman node definitions in one file seems
confusing and difficult to maintain.

The project does not want us to use a separate script for building the
SPL fit image, c.f. the message printed when you build
(https://source.denx.de/u-boot/u-boot/-/blob/master/Makefile#L1134-L1140)
so we'll need to migrate to binman eventually.

Patches or suggestions on how to make the binman nodes easier to
maintain welcome obviously. That's a different topic though.

rockchip-u-boot.dtsi: binman node
rockchip-binman.dtsi: binman FIT image node

The inclusion of rockchip-binman.dtsi is always to be last in
included files as it has a FIT image node for final image creation.

You are not respecting this in your patch. Please update or remove this
section if not required. (I assume you have this limitation because you
use a binman phandle, meaning the node needs to be defined before).

Also, rockchip-u-boot.dtsi content is now literally:
/ {
binman: binman {
multiple-images;
};
};

which is pretty much useless.

Since you want to work around your build issue, why just not include
rockchip-u-boot.dtsi instead of moving part of it to another file
without any added benefit (at least at first glance, I may be missing
some context).

BTW, we were discussing some months ago on moving away from
make_fit_atf.py to binman for all Rockchip platforms, c.f. the long
discussion here:
https://urldefense.com/v3/__https://lore.kernel.org/u-boot/20220725172953.GD2029@begut/__;!!OOPJP91ZZw!loeWJQdnvs4xp1KOPE_UekBxO1MVtI8zdMU2brPPR5vPO312JHwp5kdeK2xAzXnMrepRjers3vG5dmMKdVNqzWA2G5WTCZE$
So maybe we
should just do this and that might fix the problem you're trying to
work-around?

In any case, can you provide a bit more context on the failing platform(s)?

As I explained above, the functionality remains unchanged. Even if you
build atf via binam dts files the final binman node has to be in the
order of last since input files like bl31 and tee.bin have depended.

Yes, that's something we discussed on the linked topic. Binman would
need to gain the ability to express dependencies between nodes.
Otherwise, one could also force binman to build images sequentially in
which case (AFAIK) the images are created top to bottom in the binman
node. It makes the image creation slower but you should get what you want.

AFAIK, binman is what we're supposed to use to create U-Boot binaries
and binman uses FDT for how to generate them. If there's a better way to
configure the FDT without ifdef, feel free to suggest something.

Adding all the binman image creations and the final binman image
creation in one file make it difficult to read and maintain and
unnecessary ifdef.

We'll eventually have to make this migration anyways.

Back to the patch.

Applying your patch, rockchip-u-boot.dtsi only contains:
/ {
binman: binman {
multiple-images;
};
};
This makes very little sense since it is useless and meaningless on its own.

You would need to move this node to the newly added rockchip-binman.dtsi
which would make this patch just about a file rename. All of this
because of a build issue for one platform/SoC (as per my understanding).
If you don't want to work on improving binman to support your use case
right now, just don't include rockchip-u-boot.dtsi for your platform
until what you want is supported?

Cheers,
Quentin

Re: Adapteva Parallella board

2022-11-03 Thread Michal Simek

Hi,

čt 3. 11. 2022 v 5:24 odesílatel Martin Husemann  napsal:
>
> On Fri, Oct 28, 2022 at 07:20:36PM +0200, Martin Husemann wrote:
> > Is my dtb not correct for this purpose? How can I easily make the u-boot
> > build regen it from .dts? I found the slightly hidden dts/.*.cmd files,
> > do I need to clone one of that and adjust?
>
> It was a toolchain issue and with a bit of help I now have a boot.bin
> and a u-boot.img from 2022.10, but both are happily ignored by the
> board when booting. Do I need to set something special to make it boot
> from SD card instead of SPI flash?

You need to take a look at jumpers, dip switches to change bootmode to
SD if possible.

M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi Baruch,

On Thu, Nov 3, 2022 at 9:29 AM Baruch Siach  wrote:
>
> Hi u-boot list,
>
> I am trying to migrate the Hummingboard platform to DM_SERIAL. See below
> what I got so far. Booting this on top of master (as of commit
> 8bc87a4c5) shows nothing on the serial console. Next thing I plan to try
> is toggle GPIOs in entry code to see how far the code proceeds.
>
> Any idea where to look before I go down that way?
>
> Thanks,
> baruch
>
> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi 
> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> index 400b885e4370..8507b818d4cf 100644
> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> @@ -15,6 +15,10 @@
> };
>  };
>
> +&uart1 {
> +   u-boot,dm-pre-reloc;
> +};

Here you also need to pass &aips1, &pinctrl_uart1, and &soc.

Please look at the following commit for reference:

commit 8fbca1a8b9b02fbc40147401d9af764e07dc96af
Author: Fabio Estevam 
Date:   Tue Mar 15 17:47:05 2022 -0300

tbs2910: Convert to DM_SERIAL

Conversion to DM_SERIAL is mandatory.

Select DM_SERIAL and add a imx6q-tbs2910-u-boot.dtsi file
that describes the nodes that require dm-pre-reloc, which allows
the DM model to configure the UART pinctrl early.

Remove the now unneeded board UART initialization.

Signed-off-by: Fabio Estevam 
Tested-by: Soeren Moch

Re: [PATCH v2 2/3] arm: dts: rockchip: Separate rockchip-binman.dtsi

2022-11-03 Thread Jagan Teki

On Thu, 3 Nov 2022 at 15:32, Quentin Schulz
 wrote:
>
> Hi Jagan,
>
> On 11/3/22 07:19, Jagan Teki wrote:
> > rockchip-u-boot.dtsi has the FIT image for the final stage of
> > binman image creation.
> >
> > If the actual binman node is part of this dtsi then there are
> > build issues to use optee as input to this final stage binman
> > image since optee is built via another binman image creation
> > unlike ATF built via tools like make_fit_atf.py.
> >
> > binman: Filename 'u-boot.itb' not found in input path
> >
> > Fix this by separating binman FIT image in rockchip-binman.dtsi
> >
>
> My understanding is that this is a work-around for something that should
> be implemented in binman instead (e.g. dependency between images). If
> i'm not mistaken, what you're suggesting is to not build
> u-boot-rockchip.bin for some platforms? IIRC the plan for this binary
> was that it would apply to all Rockchip platforms, and this patch makes
> this "promise" go away.

Not really, no functionality is changed. It is just that we cannot
create the final binman image for optee. It is not possible to
implement in binman alone however if you want to add optee binman
prior to the final binman can be solvable but it makes unnecessary
ifdefs and maintaining many binman node definitions in one file seems
confusing and difficult to maintain.

>
> > rockchip-u-boot.dtsi: binman node
> > rockchip-binman.dtsi: binman FIT image node
> >
> > The inclusion of rockchip-binman.dtsi is always to be last in
> > included files as it has a FIT image node for final image creation.
> >
>
> You are not respecting this in your patch. Please update or remove this
> section if not required. (I assume you have this limitation because you
> use a binman phandle, meaning the node needs to be defined before).
>
> Also, rockchip-u-boot.dtsi content is now literally:
> / {
> binman: binman {
> multiple-images;
> };
> };
>
> which is pretty much useless.
>
> Since you want to work around your build issue, why just not include
> rockchip-u-boot.dtsi instead of moving part of it to another file
> without any added benefit (at least at first glance, I may be missing
> some context).
>
> BTW, we were discussing some months ago on moving away from
> make_fit_atf.py to binman for all Rockchip platforms, c.f. the long
> discussion here:
> https://lore.kernel.org/u-boot/20220725172953.GD2029@begut/ So maybe we
> should just do this and that might fix the problem you're trying to
> work-around?
>
> In any case, can you provide a bit more context on the failing platform(s)?

As I explained above, the functionality remains unchanged. Even if you
build atf via binam dts files the final binman node has to be in the
order of last since input files like bl31 and tee.bin have depended.
Adding all the binman image creations and the final binman image
creation in one file make it difficult to read and maintain and
unnecessary ifdef.

Thanks,
Jagan.

DM_SERIAL for i.MX6 Hummingboard/Cubox-i

Hi u-boot list,

I am trying to migrate the Hummingboard platform to DM_SERIAL. See below
what I got so far. Booting this on top of master (as of commit
8bc87a4c5) shows nothing on the serial console. Next thing I plan to try
is toggle GPIOs in entry code to see how far the code proceeds.

Any idea where to look before I go down that way?

Thanks,
baruch

diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..8507b818d4cf 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,10 @@
};
 };
 
+&uart1 {
+   u-boot,dm-pre-reloc;
+};
+
 &gpio2 {
u-boot,dm-pre-reloc;
 };
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..a29e973eccce 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15 
imx6q-hummingboard2-emmc-som-v15"
 CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -68,6 +67,8 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y


-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: Adapteva Parallella board

2022-11-03 Thread Martin Husemann

On Fri, Oct 28, 2022 at 07:20:36PM +0200, Martin Husemann wrote:
> Is my dtb not correct for this purpose? How can I easily make the u-boot
> build regen it from .dts? I found the slightly hidden dts/.*.cmd files,
> do I need to clone one of that and adjust?

It was a toolchain issue and with a bit of help I now have a boot.bin
and a u-boot.img from 2022.10, but both are happily ignored by the
board when booting. Do I need to set something special to make it boot
from SD card instead of SPI flash?

Martin

Re: [PATCH] cmd: ubifs: Do not show usage when command fails

2022-11-03 Thread Dhruva Gole





On 08/08/22 01:28, Pali Rohár wrote:

Return value -1 cause U-Boot to print usage message. Return value
1 (CMD_RET_FAILURE) indicates failure. So fix return value when ubifs
command starts it execution and fails.

Signed-off-by: Pali Rohár 


[...]

Reviewed-by: Dhruva Gole 

--
Best regards,
Dhruva Gole
Texas Instruments Incorporated

Re: [PATCH v5 2/2] serial: mxc: have putc use the TXFIFO