Re: [PATCH v2 0/6] Introduce UBI block device

2024-03-25 Thread Heiko Schocher

Hello Alexey,

On 25.03.24 15:41, Alexey Romanov wrote:

Hello!

This series adds support for the UBI block device, which
allows to read/write data block by block. For example,
it can now be used for BCB or Android AB command:

   $ bcb load ubi 0 part_name

Tested only on SPI NAND, so bind is made only for
SPI NAND drivers. Can be used with mtdblock device [1].

---

Changes V1 -> V2 [2]:

  - Rebased over mtdblock v2 patchset [3].
  - Compile UBI partitions support only if CONFIG_BLK option
is enabled.


Thanks!


- Links:

   [1] 
https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
   [2] 
https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
   [3] 
https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/

Alexey Romanov (6):
   ubi: allow to read from volume with offset
   ubi: allow to write to volume with offset
   drivers: introduce UBI block abstraction
   disk: don't try search for partition type if already set
   disk: support UBI partitions
   spinand: bind UBI block

  cmd/ubi.c   |  77 +++--
  disk/part.c |   7 ++
  drivers/block/blk-uclass.c  |   1 +
  drivers/mtd/nand/spi/core.c |   8 ++-
  drivers/mtd/ubi/Makefile|   1 +
  drivers/mtd/ubi/block.c | 130 
  drivers/mtd/ubi/part.c  |  99 +++
  env/ubi.c   |  16 ++---
  include/part.h  |   2 +
  include/ubi_uboot.h |   8 ++-
  10 files changed, 332 insertions(+), 17 deletions(-)
  create mode 100644 drivers/mtd/ubi/block.c
  create mode 100644 drivers/mtd/ubi/part.c


Looks good to me now.

@Dario: I saw that series is delegetad to you in patchwork.
 From my side it is fine. If you think I should  pick it up, please
 send a Reviewed/Acked-by for the SPI NAND parts, and notify me,
 thanks!

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


Upcoming Analog Devices SoC Support Submission

2024-03-25 Thread Greg Malysa
Hi Tom,

I wanted to get a little bit of guidance before dumping some patches
on the mailing list. I've been preparing to submit support we've
developed for the Analog Devices SC5xx SoCs including both core SoC
support and specific device trees and defconfigs for the eval kits
available from ADI. I've submitted several small patches to touch
various shared parts of U-Boot that we needed to extend to get this
hardware running and to get some familiarity with using patman to
format and submit things, but now I have a roughly 15k line changeset
consisting of a new mach type and all of the required drivers for the
system. It's broken down into a bunch of commits: one for the mach
type support, one per driver we've added, and one per target board
supported.

What is the best way to submit this? Ideally I'd love to get feedback
on individual drivers from the respective subsystem maintainers, but
it seems rude to have a 20-element patch series that gets resubmitted
each time feedback comes in for one component. If we break it down
into separate patches for each piece, what would be the best way to
ensure that all of the dependencies are merged in order?

Thanks,
Greg

-- 
Greg Malysa
Timesys Corporation


[PATCH] usb: dwc2: Add in version 4xx compatibility

2024-03-25 Thread Greg Malysa
From: Nathan Barrett-Morrison 

This adds the Synopsys device id for version 4xx of the designware
IP block and extends the version check to include it to permit
new hardware to run. It does not add any 4xx-specific features.

Signed-off-by: Ian Roberts 
Signed-off-by: Greg Malysa 
Signed-off-by: Nathan Barrett-Morrison 

---


---
 drivers/usb/host/dwc2.c | 3 ++-
 drivers/usb/host/dwc2.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 637eb2dd06..6fdde6a9a7 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -1180,7 +1180,8 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
 snpsid >> 12 & 0xf, snpsid & 0xfff);
 
if ((snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_2xx &&
-   (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_3xx) {
+   (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_3xx &&
+   (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_4xx) {
dev_info(dev, "SNPSID invalid (not DWC2 OTG device): %08x\n",
 snpsid);
return -ENODEV;
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index 6f022e33a1..f202d55eb2 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -739,6 +739,7 @@ struct dwc2_core_regs {
 #define DWC2_PCGCCTL_DEEP_SLEEP_OFFSET 7
 #define DWC2_SNPSID_DEVID_VER_2xx  (0x4f542 << 12)
 #define DWC2_SNPSID_DEVID_VER_3xx  (0x4f543 << 12)
+#define DWC2_SNPSID_DEVID_VER_4xx  (0x4f544 << 12)
 #define DWC2_SNPSID_DEVID_MASK (0xf << 12)
 #define DWC2_SNPSID_DEVID_OFFSET   12
 
-- 
2.43.2



[PATCH] mmc: Support 32-bit only ADMA on 64-bit platforms

2024-03-25 Thread Greg Malysa
Some arm64 platforms may include SDIO host controllers that
only support 32-bit ADMA. While the Linux kernel detects which
size is supported and adjusts the descriptor size used dynamically,
the previous u-boot implementation statically selected between the
two depending on whether DMA_ADDR_T_64BIT was defined. Because the
static selection is already in place and effective for most platforms,
this patch logically separates "64 bit addresses are used for DMA on
this platform" and "64 bit addresses are used by the SDIO host
controller for ADMA" in order to support the small number of platforms
where these statements are not equivalent.

Using 32 bits is opt-in and existing 64 bit platforms should be
unaffected by this change.

Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Signed-off-by: Greg Malysa 

---


---
 drivers/mmc/Kconfig  | 18 ++
 drivers/mmc/sdhci-adma.c |  2 +-
 drivers/mmc/sdhci.c  |  9 -
 include/sdhci.h  |  4 ++--
 4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index cef05790dd..4538286c64 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -495,6 +495,24 @@ config SPL_MMC_SDHCI_ADMA
  This enables support for the ADMA (Advanced DMA) defined
  in the SD Host Controller Standard Specification Version 3.00 in SPL.
 
+config MMC_SDHCI_ADMA_FORCE_32BIT
+   bool "Force 32 bit mode for ADMA on 64 bit platforms"
+   help
+ This forces SDHCI ADMA to be built for 32 bit descriptors, even
+ on a 64 bit platform where they would otherwise be assumed to
+ be 64 bits. This is necessary for certain hardware platforms
+ that are 64-bit but include only 32-bit support within the selected
+ SD host controller IP.
+
+config MMC_SDHCI_ADMA_64BIT
+   bool "Use SHDCI ADMA with 64 bit descriptors"
+   depends on !MMC_SDHCI_ADMA_FORCE_32BIT
+   default y if DMA_ADDR_T_64BIT
+   help
+ This selects 64 bit descriptors for SDHCI ADMA. It is enabled by
+ default on 64 bit systems, but can be disabled if one of these
+ systems includes 32-bit ADMA.
+
 config FIXED_SDHCI_ALIGNED_BUFFER
hex "SDRAM address for fixed buffer"
depends on SPL && MVEBU_SPL_BOOT_DEVICE_MMC
diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
index 8213223d3f..474647c3fd 100644
--- a/drivers/mmc/sdhci-adma.c
+++ b/drivers/mmc/sdhci-adma.c
@@ -22,7 +22,7 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
desc->len = len;
desc->reserved = 0;
desc->addr_lo = lower_32_bits(addr);
-#ifdef CONFIG_DMA_ADDR_T_64BIT
+#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
desc->addr_hi = upper_32_bits(addr);
 #endif
 }
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0178ed8a11..b27ce57d96 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -900,11 +900,10 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
sdhci_host *host,
host->adma_desc_table = sdhci_adma_init();
host->adma_addr = (dma_addr_t)host->adma_desc_table;
 
-#ifdef CONFIG_DMA_ADDR_T_64BIT
-   host->flags |= USE_ADMA64;
-#else
-   host->flags |= USE_ADMA;
-#endif
+   if (IS_ENABLED(CONFIG_MMC_SDHCI_ADMA_64BIT))
+   host->flags |= USE_ADMA64;
+   else
+   host->flags |= USE_ADMA;
 #endif
if (host->quirks & SDHCI_QUIRK_REG32_RW)
host->version =
diff --git a/include/sdhci.h b/include/sdhci.h
index a1b74e3bd7..07b84d6715 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -294,7 +294,7 @@ struct sdhci_ops {
 };
 
 #define ADMA_MAX_LEN   65532
-#ifdef CONFIG_DMA_ADDR_T_64BIT
+#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
 #define ADMA_DESC_LEN  16
 #else
 #define ADMA_DESC_LEN  8
@@ -319,7 +319,7 @@ struct sdhci_adma_desc {
u8 reserved;
u16 len;
u32 addr_lo;
-#ifdef CONFIG_DMA_ADDR_T_64BIT
+#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
u32 addr_hi;
 #endif
 } __packed;
-- 
2.43.2



[PATCH] mmc: sdhci: Fix potential ADMA descriptor table overflow

2024-03-25 Thread Greg Malysa
From: Ian Roberts 

Change ADMA_TABLE_NO_ENTRIES to round the division up to fully
contain CONFIG_SYS_MMC_MAX_BLK_COUNT, fixing potential buffer overflow
of the ADMA descriptor table.

sdhci_prepare_adma_table() expecitily states it does _not_ check for
overflow as the descriptor table size is dependent on
CONFIG_SYS_MMC_MAX_BLK_COUNT. However, the ADMA_TABLE_NO_ENTRIES
calculation does not round up the divison, so with the current u-boot
 defaults:
max_mmc_transfer = (CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN) =
65535 * 512 = 33553920 bytes.
ADMA_TABLE_NO_ENTRIES = max_mmc_transfer / ADMA_MAX_LEN =
33553920 / 65532, which does not divide cleanly.
actual_max_transfer = ADMA_TABLE_NO_ENTRIES * ADMA_MAX_LEN = 512 *
65532 = 33552384, which is smaller than max_mmc_transfer.
This can cause sdhci_prepare_adma_table() to write one extra
descriptor, overflowing the table when a transaction larger than
actual_max_transfer is issued.

Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Greg Malysa 
Signed-off-by: Ian Roberts 

---


---
 include/sdhci.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/sdhci.h b/include/sdhci.h
index a1b74e3bd7..fbc0f0391c 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -299,8 +300,8 @@ struct sdhci_ops {
 #else
 #define ADMA_DESC_LEN  8
 #endif
-#define ADMA_TABLE_NO_ENTRIES (CONFIG_SYS_MMC_MAX_BLK_COUNT * \
-  MMC_MAX_BLOCK_LEN) / ADMA_MAX_LEN
+#define ADMA_TABLE_NO_ENTRIES DIV_ROUND_UP(CONFIG_SYS_MMC_MAX_BLK_COUNT * \
+ MMC_MAX_BLOCK_LEN, ADMA_MAX_LEN)
 
 #define ADMA_TABLE_SZ (ADMA_TABLE_NO_ENTRIES * ADMA_DESC_LEN)
 
-- 
2.43.2



[PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops

2024-03-25 Thread Greg Malysa
From: Ian Roberts 

Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept  so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.

The above is a port of Linux kernel commit 54552e4948cbf

In addition, allow drivers to allocate their own ADMA descriptor
tables if additional space is required.

Finally, fix the assignment of adma_addr to fix compiler warning
on 64-bit platforms that still use 32-bit DMA addressing.

Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Greg Malysa 
Signed-off-by: Ian Roberts 

---


---
 drivers/mmc/fsl_esdhc.c  |  2 +-
 drivers/mmc/sdhci-adma.c | 41 +++-
 drivers/mmc/sdhci.c  |  8 +---
 include/sdhci.h  | 12 ++--
 4 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index d50669..bd0671cc52 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -252,7 +252,7 @@ static void esdhc_setup_dma(struct fsl_esdhc_priv *priv, 
struct mmc_data *data)
priv->adma_desc_table) {
debug("Using ADMA2\n");
/* prefer ADMA2 if it is available */
-   sdhci_prepare_adma_table(priv->adma_desc_table, data,
+   sdhci_prepare_adma_table(NULL, priv->adma_desc_table, data,
 priv->dma_addr);
 
adma_addr = virt_to_phys(priv->adma_desc_table);
diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
index 8213223d3f..8c38448b6a 100644
--- a/drivers/mmc/sdhci-adma.c
+++ b/drivers/mmc/sdhci-adma.c
@@ -9,9 +9,10 @@
 #include 
 #include 
 
-static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
-   dma_addr_t addr, u16 len, bool end)
+void sdhci_adma_write_desc(struct sdhci_host *host, void **next_desc,
+  dma_addr_t addr, int len, bool end)
 {
+   struct sdhci_adma_desc *desc = *next_desc;
u8 attr;
 
attr = ADMA_DESC_ATTR_VALID | ADMA_DESC_TRANSFER_DATA;
@@ -19,17 +20,30 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
attr |= ADMA_DESC_ATTR_END;
 
desc->attr = attr;
-   desc->len = len;
+   desc->len = len & 0x;
desc->reserved = 0;
desc->addr_lo = lower_32_bits(addr);
 #ifdef CONFIG_DMA_ADDR_T_64BIT
desc->addr_hi = upper_32_bits(addr);
 #endif
+
+   *next_desc += ADMA_DESC_LEN;
+}
+
+static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
+  void **desc, dma_addr_t addr,
+  int len, bool end)
+{
+   if (host && host->ops && host->ops->adma_write_desc)
+   host->ops->adma_write_desc(host, desc, addr, len, end);
+   else
+   sdhci_adma_write_desc(host, desc, addr, len, end);
 }
 
 /**
  * sdhci_prepare_adma_table() - Populate the ADMA table
  *
+ * @host:  Pointer to the sdhci_host
  * @table: Pointer to the ADMA table
  * @data:  Pointer to MMC data
  * @addr:  DMA address to write to or read from
@@ -39,25 +53,26 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
  * Please note, that the table size depends on CONFIG_SYS_MMC_MAX_BLK_COUNT and
  * we don't have to check for overflow.
  */
-void sdhci_prepare_adma_table(struct sdhci_adma_desc *table,
- struct mmc_data *data, dma_addr_t addr)
+void sdhci_prepare_adma_table(struct sdhci_host *host,
+ struct sdhci_adma_desc *table,
+ struct mmc_data *data, dma_addr_t start_addr)
 {
+   dma_addr_t addr = start_addr;
uint trans_bytes = data->blocksize * data->blocks;
-   uint desc_count = DIV_ROUND_UP(trans_bytes, ADMA_MAX_LEN);
-   struct sdhci_adma_desc *desc = table;
-   int i = desc_count;
+   void *next_desc = table;
+   int i = DIV_ROUND_UP(trans_bytes, ADMA_MAX_LEN);
 
while (--i) {
-   sdhci_adma_desc(desc, addr, ADMA_MAX_LEN, false);
+   __sdhci_adma_write_desc(host, _desc, addr,
+   ADMA_MAX_LEN, false);
addr += ADMA_MAX_LEN;
trans_bytes -= ADMA_MAX_LEN;
-   desc++;
}
 
-   sdhci_adma_desc(desc, addr, trans_bytes, true);
+   __sdhci_adma_write_desc(host, _desc, addr, trans_bytes, true);
 
-   flush_cache((dma_addr_t)table,
-   ROUND(desc_count * sizeof(struct sdhci_adma_desc),
+   flush_cache((phys_addr_t)table,
+   ROUND(next_desc - (void *)table,
  ARCH_DMA_MINALIGN));
 }
 
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0178ed8a11..65090348ae 100644
--- 

Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet

2024-03-25 Thread Tom Rini
On Mon, Mar 25, 2024 at 02:16:53PM +0200, Roger Quadros wrote:
> Hi Tom / Joe,
> 
> On 05/03/2024 15:24, Roger Quadros wrote:
> > Currently, the GPIO Reset Device Tree properties of the
> > PHY node are ignored when the PHY is probed via mdio-uclass driver [1].
> > 
> > To resolve this, for each child of the MDIO bus node, bind and probe
> > the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled.
> > 
> > This should now show the generic_phy_driver in "dm tree"
> > and also apply the GPIO reset before the MDIO bus driver scans the bus
> > for the PHYs.
> > 
> >  ethernet  0  [ + ]   am65_cpsw_nuss_port   |   |-- 
> > ethernet@800port@1
> >  bootdev   3  [   ]   eth_bootdev   |   |   `-- 
> > port@1.bootdev
> >  mdio  0  [ + ]   cpsw_mdio |   `-- mdio@f00
> >  eth_phy_ge0  [ + ]   eth_phy_generic_drv   |   |-- 
> > ethernet-phy@0
> >  eth_phy_ge1  [ + ]   eth_phy_generic_drv   |   `-- 
> > ethernet-phy@1
> > 
> > To test this on Beagleplay, the following series is required
> > 
> > [1] Switch am65-cpsw to DM MDIO
> >  
> > https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/
> > 
> > The last 3 patches are marked [not-for-merge]. They are to show how the
> > whole solution can work to fix Ethernet on Beagleplay, which has been broken
> > so far. Those DT patches will be sent once the device tree changes are 
> > merged
> > into Linux tree.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> > Roger Quadros (5):
> >   net: mdio-uclass: Bind and probe generic Ethernet PHY driver
> >   configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
> 
> Any comments to the first 2 patches in this series?

Oh, so the CI failure, unfortunately, was because sometimes those tests
hit some resource-related race condition I believe. And I took your
comment at the time to mean you would v2 them. Yes, these patches seem
fine as is and I'll pick up assorted changes for -next soon. Thanks for
your patience.

-- 
Tom


signature.asc
Description: PGP signature


[ANN] U-Boot v2024.04-rc4 released

2024-03-25 Thread Tom Rini
Hey all,

It's very late in thee release day but here's -rc5, and I'll be updating
the next branch with this as well shortly.

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

At this point, we're a week away from release on April 2nd. I know
there's the boot fix for some i.MX8 families but I'm unsure about the
testing impact on non-i.MX8 platforms at this date so I'm tempted to
just let that be picked up as needed in distributions that can get
testing done on other platforms (or are i.MX8 centric in their patch
applications). If there's anything else that must come in at this point,
please speak up now, thanks!

-- 
Tom


signature.asc
Description: PGP signature


tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size

2024-03-25 Thread Tim Harvey
Greetings,

I'm unable to understand why tcg2_platform_get_log is failing to read
a memory region.

For example the following diffs:

diff --git a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
index 7b2130dbdb21..57b3c227ceaf 100644
--- a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
@@ -112,6 +112,7 @@
compatible = "tcg,tpm_tis-spi";
reg = <0x1>;
spi-max-frequency = <3600>;
+   memory-region = <_log>;
};
 };
 diff --git a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
index c305e325d007..697fd1148785 100644
--- a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
@@ -13,6 +13,17 @@
reg = <0x0 0x4000 0 0x8000>;
};

+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <0 0x4000 0x2000>;
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";

And at runtime:
u-boot=> fdt addr $fdtcontroladdr
u-boot=> fdt list /soc@0/bus@3080/spba-bus@3080/spi@3083/tpm@1/
tpm@1 {
compatible = "tcg,tpm_tis-spi";
reg = <0x0001>;
spi-max-frequency = <0x02255100>;
memory-region = <0x0025>;
};
u-boot=> fdt list /reserved-memory/
reserved-memory {
#address-cells = <0x0002>;
#size-cells = <0x0002>;
ranges;
tcg_event_log {
};
};
u-boot=> fdt list /reserved-memory/tcg_event_log
tcg_event_log {
no-map;
reg = <0x 0x4000 0x2000>;
phandle = <0x0025>;
};

So why does the following code in tcg2_platform_get_log() return -ENOMEM?

if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
   0, ))
return -ENODEV;

a = ofnode_get_addr_size(args.node, "reg", );
if (a == FDT_ADDR_T_NONE)
return -ENOMEM;

debugging shows that dev_read_phandle_with_args returns non-zero but
args.args_count is 0.

I feel like the construct of using dev_read_phandle_with_args followed
by the ofnode_get_addr_size is just wrong but I don't understand why
nor do I understand how my dt changes differ from what is in
arch/sandbox/dts/test.dts (other than its using address-size=1 which
doesn't appear to be the issue in my testing). The abstraction of the
ofnode and fdt stuff always trip me up... very confusing.

Can anyone explain the issue here?

Best Regards,

Tim


Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks

2024-03-25 Thread Hiago De Franco
On Mon, Mar 18, 2024 at 04:46:55PM -0300, Fabio Estevam wrote:
> Hi Pierre,
> 
> On Mon, Mar 18, 2024 at 4:35 PM Pierre-Clément Tosi  wrote:
> >
> > The implementation of map_range() creates the requested mapping by
> > walking the page tables, iterating over multiple PTEs and/or descending
> > into existing table mappings as needed. When doing so, it assumes any
> > pre-existing valid PTE to be a table mapping. This assumption is wrong
> > if the platform code attempts to successively map two overlapping ranges
> > where the latter intersects a block mapping created for the former.
> >
> > As a result, map_range() treats the existing block mapping as a table
> > mapping and descends into it i.e. starts interpreting the
> > previously-mapped range as an array of PTEs, writing to them and
> > potentially even descending further (extra fun with MMIO ranges!).
> >
> > Instead, pass any valid non-table mapping to split_block(), which
> > ensures that it actually was a block mapping (calls panic() otherwise)
> > before splitting it.
> >
> > Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity")
> > Signed-off-by: Pierre-Clément Tosi 
> 
> This fixes the boot regression on colibri-imx8x.
> 
> Thanks a lot for your fix!
> 
> Tested-by: Fabio Estevam 

Tested-by: Hiago De Franco  # Toradex Verdin AM62

On Sat, Mar 23, 2024 at 10:34:54AM -0400, Tom Rini wrote:
> On Fri, Mar 22, 2024 at 04:33:03PM -0300, Fabio Estevam wrote:
> > On Fri, Mar 22, 2024 at 4:31 PM Fabio Estevam  wrote:
> > 
> > > As Pierre's explanation addresses Marc's concern,
> > > do you think this can go to 2024.01 to fix the boot regression on 
> > > imx8qxp/8qm?
> > 
> > I meant 2024.04, sorry.
> 
> How much testing has this seen outside of imx?

Tom, I tested with the AM62 TI arm processor (Toradex Verdin AM62) and
it works fine.

U-Boot 2024.04-rc4-1-g5db2e36c8e97 (Mar 25 2024 - 17:28:20 -0300)

SoC:   AM62X SR1.0 HS-FS
DRAM:  1 GiB
Core:  138 devices, 29 uclasses, devicetree: separate
MMC:   mmc@fa1: 0, mmc@fa0: 1
Loading Environment from MMC... OK
In:serial@280
Out:   serial@280
Err:   serial@280
Model: Toradex 0074 Verdin AM62 Dual 1GB IT V1.1A
Serial#: 15133548
Carrier: Toradex Dahlia V1.1C, Serial# 10952631

I've added my Tested-by as well.

> 
> -- 
> Tom

Best Regards,

Hiago.


Re: U-boot fails for khadas-edge -v

2024-03-25 Thread Vivek Jaiswal
Hello Fabio,
I have also attached the Makefile where also the error was reported

make[2]: *** 
[/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/scripts/Makefile.build:280:
 cmd/bootm.o] Error 1


Best Regards,
Vivek

From: Vivek Jaiswal 
Sent: Monday, March 25, 2024 5:37 PM
To: Fabio Estevam 
Cc: u-boot@lists.denx.de 
Subject: Re: U-boot fails for khadas-edge -v

Hello Fabio,
I tried using the this github repository.
https://github.com/u-boot/u-boot.git

And the configuration used was following

[https://res-geo.cdn.office.net/assets/mail/file-icon/png/generic_16x16.png]rockchip-rk3399-khadas-edge-v.conf

UBOOT_MACHINE = "khadas-edge-v-rk3399_defconfig"

I got some error during the build from the u-boot.

Please check the attachment BuildError1.txt or BuildError2.txt

make[2]: *** 
[/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/scripts/Makefile.build:280:
 cmd/bootm.o] Error 1
make[1]: *** 
[/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/Makefile:1317:
 cmd] Error 2
make: *** [Makefile:157: sub-make] Error 2

I have attached the Makefile.txt as well.


I am using this repository as meta rockchip 
https://github.com/JeffyCN/meta-rockchip
Linux : https://github.com/khadas/linux/tree/khadas-edges-5.10.y-release-v1.0.0
Yocto branch : Kirkstone
Layes used:
meta-rockchip
poky/meta
poky/meta-poky
poky/meta-yocto-bsp
meta-openembedded/meta-oe

Can you fix this issue ?

Best regards,
Vivek



From: Fabio Estevam 
Sent: Thursday, March 7, 2024 10:19 PM
To: Vivek Jaiswal 
Cc: u-boot@lists.denx.de 
Subject: Re: U-boot fails for khadas-edge -v

[You don't often get email from feste...@gmail.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On Thu, Mar 7, 2024 at 2:43 PM Vivek Jaiswal  wrote:

> are you saying to use this one?
> https://github.com/u-boot/u-boot/blob/master/configs/khadas-edge-v-rk3399_defconfig

Yes, this one.
# ==
# Building
# ==
#
# SPDX-License-Identifier:  GPL-2.0
#

# Modified for U-Boot
prefix := tpl
src := $(patsubst $(prefix)/%,%,$(obj))
ifeq ($(obj),$(src))
prefix := spl
src := $(patsubst $(prefix)/%,%,$(obj))
ifeq ($(obj),$(src))
prefix := .
endif
endif

PHONY := __build
__build:

# Init all relevant variables used in kbuild files so
# 1) they have correct type
# 2) they do not inherit any value from the environment
obj-y :=
obj-m :=
lib-y :=
lib-m :=
always :=
targets :=
subdir-y :=
subdir-m :=
EXTRA_AFLAGS   :=
EXTRA_CFLAGS   :=
EXTRA_CPPFLAGS :=
EXTRA_LDFLAGS  :=
asflags-y  :=
ccflags-y  :=
cppflags-y :=
ldflags-y  :=

subdir-asflags-y :=
subdir-ccflags-y :=

# Read auto.conf if it exists, otherwise ignore
# Modified for U-Boot
-include include/config/auto.conf
-include $(prefix)/include/autoconf.mk
include scripts/Makefile.uncmd_spl

include scripts/Kbuild.include

# For backward compatibility check that these variables do not change
save-cflags := $(CFLAGS)

# The filename Kbuild has precedence over Makefile
kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
kbuild-file := $(if $(wildcard 
$(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
include $(kbuild-file)

# Added for U-Boot
asflags-y  += $(PLATFORM_CPPFLAGS)
ccflags-y  += $(PLATFORM_CPPFLAGS)
cppflags-y += $(PLATFORM_CPPFLAGS)

# If the save-* variables changed error out
ifeq ($(KBUILD_NOPEDANTIC),)
ifneq ("$(save-cflags)","$(CFLAGS)")
$(error CFLAGS was changed in "$(kbuild-file)". Fix it to use 
ccflags-y)
endif
endif

include scripts/Makefile.lib

ifdef host-progs
ifneq ($(hostprogs-y),$(host-progs))
$(warning kbuild: $(obj)/Makefile - Usage of host-progs is deprecated. Please 
replace with hostprogs-y!)
hostprogs-y += $(host-progs)
endif
endif

# Do not include host rules unless needed
ifneq ($(hostprogs-y)$(hostprogs-m),)
include scripts/Makefile.host
endif

# Uncommented for U-Boot
#  We need to create output dicrectory for SPL and TPL even for in-tree build
#ifneq ($(KBUILD_SRC),)
# Create output directory if not already present
_dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))

# Create directories for object files if directory does not exist
# Needed when obj-y := dir/file.o syntax is used
_dummy := $(foreach d,$(obj-dirs), $(shell [ -d $(d) ] || mkdir -p $(d)))
#endif

ifndef obj
$(warning kbuild: Makefile.build is included 

Re: [PATCH u-boot-mvebu v2 06/18] arm: mvebu: turris_omnia: Print board ECDSA public key if available

2024-03-25 Thread Marek Behún
On Sat, 23 Mar 2024 19:06:59 +0100
Marek Behún  wrote:

> If MCU supports the FEAT_CRYPTO feature, read board ECDSA public key
> from MCU and print it.
> 
> Signed-off-by: Marek Behún 
> ---
>  board/CZ.NIC/turris_omnia/turris_omnia.c | 25 +++-
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
> b/board/CZ.NIC/turris_omnia/turris_omnia.c
> index f63640ad64..896c14bb99 100644
> --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> @@ -253,6 +253,24 @@ static int omnia_mcu_board_info(char *serial, u8 *mac, 
> char *version)
>   return 0;
>  }
>  
> +static int omnia_mcu_get_board_public_key(char pub_key[static 67])
> +{
> + u8 reply[34];
> + int ret;
> +
> + ret = omnia_mcu_read(CMD_CRYPTO_GET_PUBLIC_KEY, reply, sizeof(reply));
> + if (ret)
> + return ret;
> +
> + if (reply[0] != 33)
> + return -EBADMSG;
> +
> + bin2hex(pub_key, [1], 33);
> + reply[66] = '\0';

Aargh, this should be pub_key[66] = '\0'.

And I noticed once more thing, so I will sent another version.


Re: bugs with EFI "reserved" memory and LMB?

2024-03-25 Thread Francesco Dolcini
Hello all,
re-opening this old email thread ...

On Sat, Aug 12, 2023 at 08:23:32AM +0200, Heinrich Schuchardt wrote:
> On 7/27/23 14:14, Emanuele Ghidoli wrote:
> > On 27/07/2023 13:21, Heinrich Schuchardt wrote:
> > > On 27.07.23 13:08, Emanuele Ghidoli wrote:
> > > > Efi loader module have its own memory management that flags as reserved 
> > > > the
> > > > area between ram_top to ram_end (currently where dt reserved-memory is
> > > > falling).  uboot lmb updates reserved-memory by adding these
> > > > efi loader module areas (see lmb_reserve_common->efi_lmb_reserve).
> > > > 
> > > > 
> > > > On our system (AM62xx SoC, 512MB RAM) we have some reserved-memory 
> > > > specified in
> > > > the device tree (used for comunication with other microcontroller on 
> > > > the SoC,
> > > > OPTEE, ...) falling in the DDR range between 456 and 512 MB.
> > > > 
> > > > Normally U-Boot relocate itself at the end of DDR so it overlap this
> > > > reserved-memory and this of course does not work [1].
> > > > 
> > > > In this case U-Boot prints the following errors:
> > > > 
> > > >     ERROR: reserving fdt memory region failed (addr=9c80 
> > > > size=30)
> > > >     ERROR: reserving fdt memory region failed (addr=9cb0 
> > > > size=10)
> > > >     ...
> > > >     ERROR: reserving fdt memory region failed (addr=9e80 
> > > > size=180)
> > > > 
> > > > because U-Boot reserved area (lmb_flag LMB_NONE) overlaps with the FDT 
> > > > reserve
> > > > memories (lmb_flag LMB_NOMAP).
> > > > 
> > > > 
> > > > To fix this I moved the U-Boot relocation address, implementing
> > > > board_get_usable_ram_top() and therefore setting gd->ram_top to a lower 
> > > > value
> > > > with no overlap (448 MB).
> > > > 
> > > > 
> > > > The memory map is:
> > > > +---+ 512 MB
> > > > |DT reserved-mem|
> > > > +---+ 456 MB
> > > > |free space |
> > > > +---+ 448 MB (ram_top)
> > > > |   |
> > > > |uboot  |
> > > > |   |
> > > > +---+ 0 MB
> > > > 
> > > > This is working fine (the board is able to boot, no memory overlaps) ...
> > > > 
> > > > however, in this configuration U-Boot we still have some errors prints 
> > > > while
> > > > loading linux dtb:
> > > > 
> > > >     ERROR: reserving fdt memory region failed (addr=9cb0 
> > > > size=10 flags=4)
> > > >     ERROR: reserving fdt memory region failed (addr=9cc0 
> > > > size=e0 flags=4)
> > > >     ERROR: reserving fdt memory region failed (addr=9da0 
> > > > size=10 flags=4)
> > > >     ERROR: reserving fdt memory region failed (addr=9db0 
> > > > size=c0 flags=4)
> > > >     ERROR: reserving fdt memory region failed (addr=9e78 size=8 
> > > > flags=4)
> > > >     ERROR: reserving fdt memory region failed (addr=9e80 
> > > > size=180 flags=4)
> > > > 
> > > > And the reason of these error is complete different: The efi loader lmb 
> > > > memory
> > > > reservation (lib/lmb.c:efi_lmb_reserve()) is wrongly reserving some 
> > > > area.
> > > > 
> > > > 
> > > > 1) lib/lmb.c:lmb_reserve_common() reserve these memories:
> > > >     ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE)
> > > >      456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP)
> > > > 
> > > > 2) lib/lmb.c:efi_lmb_reserve() reserve a region just before u-boot 
> > > > reserved
> > > > area. This is not coalesced/merged with the u-boot reserved area 
> > > > because it is
> > > > not contiguous.
> > > > 
> > > > This is the reserved-memory array at this point:
> > > >     ~414M - ~414M efi loader reserved area (lmb_flag LMB_NONE)
> > > >     ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE)
> > > >      456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP)
> > > > 
> > > > 3) lib/lmb.c:efi_lmb_reserve() reserve some more areas.
> > > > In the last two steps efi loader add some reserved area that overlap 
> > > > u-boot and fdt
> > > > reserved area BUT they are also contiguous to the "efi loader reserved 
> > > > area".
> > > > The very last step reserve also area between ram_top (448M) to ram_end 
> > > > (512M)
> > > > 
> > > > We fall in this condition (where we have overlapping areas!):
> > > >     ~414M - 512M efi loader reserved area (lmb_flag LMB_NONE)
> > > >     ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE)
> > > >      456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP)
> > > > 
> > > > 4) Now, while loading the linux fdt the reserved-memory areas are 
> > > > checked
> > > > toward efi loader reserved area, they overlap, BUT they have different
> > > > lmb_flag. So we get the ERROR print.
> > > > 
> > > > Hopefully this is clear, I undestand is not that obvious ...
> > > 
> > >     efidebug memmap
> > Verdin AM62 # efidebug memmap
> > MMC: no card present
> > No EFI system partition
> > No EFI system partition
> > Failed to persist EFI variables
> > Type StartEnd  Attributes
> >  

[PATCH] imx8m*-venice: enable TPM support

2024-03-25 Thread Tim Harvey
Enable support for TPM2 devices. As the ATTPM20P TPM2 used on the
Gateworks Venice boards hangs off the SPI bus we enable SPI support
as well.

Signed-off-by: Tim Harvey 
---
 configs/imx8mm_venice_defconfig | 10 ++
 configs/imx8mn_venice_defconfig | 10 ++
 configs/imx8mp_venice_defconfig | 10 ++
 3 files changed, 30 insertions(+)

diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
index cb6b97d097c1..86928687df2d 100644
--- a/configs/imx8mm_venice_defconfig
+++ b/configs/imx8mm_venice_defconfig
@@ -68,6 +68,7 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_TPM=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -127,14 +128,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+# CONFIG_DM_RNG is not set
 CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_MXC_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_TMU=y
+# CONFIG_TPM_V1 is not set
+CONFIG_TPM2_TIS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_HOST_ETHER=y
@@ -152,4 +159,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_IMX_WATCHDOG=y
+CONFIG_TPM=y
+# CONFIG_SPL_SHA512 is not set
+# CONFIG_SPL_SHA384 is not set
 CONFIG_HEXDUMP=y
diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig
index 0a4fba5f1ca8..6bb0f015a9bf 100644
--- a/configs/imx8mn_venice_defconfig
+++ b/configs/imx8mn_venice_defconfig
@@ -71,6 +71,7 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_TPM=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -128,14 +129,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+# CONFIG_DM_RNG is not set
 CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_MXC_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_TMU=y
+# CONFIG_TPM_V1 is not set
+CONFIG_TPM2_TIS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_HOST_ETHER=y
@@ -153,4 +160,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_IMX_WATCHDOG=y
+CONFIG_TPM=y
+# CONFIG_SPL_SHA512 is not set
+# CONFIG_SPL_SHA384 is not set
 CONFIG_HEXDUMP=y
diff --git a/configs/imx8mp_venice_defconfig b/configs/imx8mp_venice_defconfig
index 6e4addc7728f..b1055ef2f066 100644
--- a/configs/imx8mp_venice_defconfig
+++ b/configs/imx8mp_venice_defconfig
@@ -73,6 +73,7 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_TPM=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -135,14 +136,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+# CONFIG_DM_RNG is not set
 CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_MXC_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_TMU=y
+# CONFIG_TPM_V1 is not set
+CONFIG_TPM2_TIS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
@@ -160,4 +167,7 @@ CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_IMX_WATCHDOG=y
+CONFIG_TPM=y
+# CONFIG_SPL_SHA512 is not set
+# CONFIG_SPL_SHA384 is not set
 CONFIG_HEXDUMP=y
-- 
2.25.1



[PATCH] arm: dts: imx8m*-venice-gw72xx: add TPM device

2024-03-25 Thread Tim Harvey
The GW71xx baseboard has a TPM that defined in the upstream dt however
we need to ensure the GPIO reset line is de-asserted which we do in boot
firmware with a gpio hog.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi | 7 +++
 arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi | 9 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi 
b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
index b3592331c72b..07789c8d8835 100644
--- a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
@@ -25,6 +25,13 @@
gpios = <9 GPIO_ACTIVE_HIGH>;
line-name = "dio1";
};
+
+   tpm_rst {
+   gpio-hog;
+   output-high;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "tpm_rst#";
+   };
 };
 
  {
diff --git a/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
index 5c33f8c9cdcf..216a7a0d8d7c 100644
--- a/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
@@ -4,6 +4,15 @@
  */
 #include "imx8mp-venice-gw702x-u-boot.dtsi"
 
+ {
+   tpm_rst {
+   gpio-hog;
+   output-high;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "tpm_rst#";
+   };
+};
+
  {
dio_1 {
gpio-hog;
-- 
2.25.1



[PATCH] arm: dts: imx8mm-venice-gw7901: add digital I/O direction control GPIO's

2024-03-25 Thread Tim Harvey
The GW7901 has GPIO's to configure the direction of its isolated
digital I/O signals. Add the GPIO pinmux, line names, and hog
configuration.

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

diff --git a/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi 
b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
index e68030e7b22c..9fa21942c0c6 100644
--- a/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
@@ -43,6 +43,20 @@
 };
 
  {
+   dig1ctl {
+   gpio-hog;
+   output-low;
+   gpios = <4 GPIO_ACTIVE_HIGH>;
+   line-name = "dig1_ctl";
+   };
+
+   dig2ctl {
+   gpio-hog;
+   output-low;
+   gpios = <5 GPIO_ACTIVE_HIGH>;
+   line-name = "dig2_ctl";
+   };
+
uart3_rs232 {
gpio-hog;
output-high;
-- 
2.25.1



[PATCH v2 6/6] spinand: bind UBI block

2024-03-25 Thread Alexey Romanov
UBI block is virtual block device, which is an abstraction
over MTD layer. Therefore it is logical to use it in combination
with MTD drivers.

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/nand/spi/core.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index dd880adf31..c47f6c1b46 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1182,8 +1183,13 @@ static int spinand_bind(struct udevice *dev)
 {
if (blk_enabled()) {
struct spinand_plat *plat = dev_get_plat(dev);
+   int ret;
+
+   ret = mtd_bind(dev, >mtd);
+   if (ret)
+   return ret;
 
-   return mtd_bind(dev, >mtd);
+   return ubi_bind(dev);
}
 
return 0;
-- 
2.34.1



[PATCH v2 5/6] disk: support UBI partitions

2024-03-25 Thread Alexey Romanov
UBI partition is abstraction over UBI volumes.
Can be used by UBI block device.

Signed-off-by: Alexey Romanov 
Reviewed-by: Heiko Schocher 
---
 drivers/mtd/ubi/Makefile |  2 +-
 drivers/mtd/ubi/part.c   | 99 
 include/part.h   |  2 +
 3 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/ubi/part.c

diff --git a/drivers/mtd/ubi/Makefile b/drivers/mtd/ubi/Makefile
index 67b1a05348..63dc428813 100644
--- a/drivers/mtd/ubi/Makefile
+++ b/drivers/mtd/ubi/Makefile
@@ -7,4 +7,4 @@ obj-y += attach.o build.o vtbl.o vmt.o upd.o kapi.o eba.o io.o 
wl.o crc32.o
 obj-$(CONFIG_MTD_UBI_FASTMAP) += fastmap.o
 obj-y += misc.o
 obj-y += debug.o
-obj-$(CONFIG_BLK) += block.o
+obj-$(CONFIG_BLK) += block.o part.o
diff --git a/drivers/mtd/ubi/part.c b/drivers/mtd/ubi/part.c
new file mode 100644
index 00..8dd7b874af
--- /dev/null
+++ b/drivers/mtd/ubi/part.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2024 SaluteDevices, Inc.
+ *
+ * Author: Alexey Romanov 
+ */
+
+#include 
+#include 
+#include 
+
+static inline struct ubi_device *get_ubi_device(void)
+{
+   return ubi_devices[0];
+}
+
+static struct ubi_volume *ubi_get_volume_by_index(int vol_id)
+{
+   struct ubi_device *ubi = get_ubi_device();
+   int i;
+
+   for (i = 0; i < (ubi->vtbl_slots + 1); i++) {
+   struct ubi_volume *volume = ubi->volumes[i];
+
+   if (!volume)
+   continue;
+
+   if (volume->vol_id >= UBI_INTERNAL_VOL_START)
+   continue;
+
+   if (volume->vol_id == vol_id)
+   return volume;
+   }
+
+   return NULL;
+}
+
+static int __maybe_unused part_get_info_ubi(struct blk_desc *dev_desc, int 
part_idx,
+   struct disk_partition *info)
+{
+   struct ubi_volume *vol;
+
+   /*
+* We must use part_idx - 1 instead of part_idx, because
+* part_get_info_by_name() start indexing at 1, not 0.
+* ubi volumes idexed starting at 0
+*/
+   vol = ubi_get_volume_by_index(part_idx - 1);
+   if (!vol)
+   return 0;
+
+   snprintf(info->name, PART_NAME_LEN, vol->name);
+
+   info->start = 0;
+   info->size = vol->used_bytes / dev_desc->blksz;
+   info->blksz = dev_desc->blksz;
+
+   /* Save UBI volume ID in blk device descriptor */
+   dev_desc->hwpart = vol->vol_id;
+
+   return 0;
+}
+
+static void __maybe_unused part_print_ubi(struct blk_desc *dev_desc)
+{
+   struct ubi_device *ubi = get_ubi_device();
+   int i;
+
+   for (i = 0; i < (ubi->vtbl_slots + 1); i++) {
+   struct ubi_volume *volume = ubi->volumes[i];
+
+   if (!volume)
+   continue;
+
+   if (volume->vol_id >= UBI_INTERNAL_VOL_START)
+   continue;
+
+   printf("%d: %s\n", volume->vol_id, volume->name);
+   }
+}
+
+static int part_test_ubi(struct blk_desc *dev_desc)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
+
+   if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)
+   return -1;
+
+   return 0;
+}
+
+U_BOOT_PART_TYPE(ubi) = {
+   .name   = "ubi",
+   .part_type  = PART_TYPE_UBI,
+   .max_entries= UBI_ENTRY_NUMBERS,
+   .get_info   = part_get_info_ptr(part_get_info_ubi),
+   .print  = part_print_ptr(part_print_ubi),
+   .test   = part_test_ubi,
+};
diff --git a/include/part.h b/include/part.h
index f7f3773a95..10db874e3b 100644
--- a/include/part.h
+++ b/include/part.h
@@ -31,6 +31,7 @@ struct block_drvr {
 #define PART_TYPE_AMIGA0x04
 #define PART_TYPE_EFI  0x05
 #define PART_TYPE_MTD  0x06
+#define PART_TYPE_UBI  0x07
 
 /* maximum number of partition entries supported by search */
 #define DOS_ENTRY_NUMBERS  8
@@ -38,6 +39,7 @@ struct block_drvr {
 #define MAC_ENTRY_NUMBERS  64
 #define AMIGA_ENTRY_NUMBERS8
 #define MTD_ENTRY_NUMBERS  64
+#define UBI_ENTRY_NUMBERS  UBI_MAX_VOLUMES
 /*
  * Type string for U-Boot bootable partitions
  */
-- 
2.34.1



[PATCH v2 4/6] disk: don't try search for partition type if already set

2024-03-25 Thread Alexey Romanov
Block devices can already set partition type at initialization
stage, so, in this case is no point in searching for partition type.

Signed-off-by: Alexey Romanov 
Reviewed-by: Heiko Schocher 
---
 disk/part.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/disk/part.c b/disk/part.c
index 0fc5cc0419..362c9de609 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -285,6 +285,13 @@ void part_init(struct blk_desc *desc)
 
blkcache_invalidate(desc->uclass_id, desc->devnum);
 
+   if (desc->part_type != PART_TYPE_UNKNOWN) {
+   for (entry = drv; entry != drv + n_ents; entry++) {
+   if (entry->part_type == desc->part_type && 
!entry->test(desc))
+   return;
+   }
+   }
+
desc->part_type = PART_TYPE_UNKNOWN;
for (entry = drv; entry != drv + n_ents; entry++) {
int ret;
-- 
2.34.1



[PATCH v2 3/6] drivers: introduce UBI block abstraction

2024-03-25 Thread Alexey Romanov
UBI block is an virtual device, that runs on top
of the MTD layer. The blocks are UBI volumes.
Intended to be used in combination with other MTD
drivers.

Despite the fact that it, like mtdblock abstraction,
it used with UCLASS_MTD, they can be used together
on the system without conflicting. For example,
using bcb command:

  # Trying to load bcb via mtdblock:
  $ bcb load mtd 0 mtd_partition_name

  # Trying to load bcb via UBI block:
  $ bcb load ubi 1 ubi_volume_name

User always must attach UBI layer (for example, using
ubi_part()) before using UBI block device.

Signed-off-by: Alexey Romanov 
Reviewed-by: Heiko Schocher 
Acked-by: Heiko Schocher 
---
 drivers/block/blk-uclass.c |   1 +
 drivers/mtd/ubi/Makefile   |   1 +
 drivers/mtd/ubi/block.c| 130 +
 include/ubi_uboot.h|   4 ++
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/mtd/ubi/block.c

diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index ab0a9105c9..8a457e9f70 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -38,6 +38,7 @@ static struct {
{ UCLASS_BLKMAP, "blkmap" },
{ UCLASS_RKMTD, "rkmtd" },
{ UCLASS_MTD, "mtd" },
+   { UCLASS_MTD, "ubi" },
 };
 
 static enum uclass_id uclass_name_to_iftype(const char *uclass_idname)
diff --git a/drivers/mtd/ubi/Makefile b/drivers/mtd/ubi/Makefile
index 30d00fbdfe..67b1a05348 100644
--- a/drivers/mtd/ubi/Makefile
+++ b/drivers/mtd/ubi/Makefile
@@ -7,3 +7,4 @@ obj-y += attach.o build.o vtbl.o vmt.o upd.o kapi.o eba.o io.o 
wl.o crc32.o
 obj-$(CONFIG_MTD_UBI_FASTMAP) += fastmap.o
 obj-y += misc.o
 obj-y += debug.o
+obj-$(CONFIG_BLK) += block.o
diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
new file mode 100644
index 00..95d5ef5752
--- /dev/null
+++ b/drivers/mtd/ubi/block.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2024 SaluteDevices, Inc.
+ *
+ * Author: Alexey Romanov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int ubi_bind(struct udevice *dev)
+{
+   struct blk_desc *bdesc;
+   struct udevice *bdev;
+   int ret;
+
+   ret = blk_create_devicef(dev, "ubi_blk", "blk", UCLASS_MTD,
+dev_seq(dev), 512, 0, );
+   if (ret) {
+   pr_err("Cannot create block device");
+   return ret;
+   }
+
+   bdesc = dev_get_uclass_plat(bdev);
+
+   bdesc->bdev = bdev;
+   bdesc->part_type = PART_TYPE_UBI;
+
+   return 0;
+}
+
+static struct ubi_device *get_ubi_device(void)
+{
+   return ubi_devices[0];
+}
+
+static char *get_volume_name(int vol_id)
+{
+   struct ubi_device *ubi = get_ubi_device();
+   int i;
+
+   for (i = 0; i < (ubi->vtbl_slots + 1); i++) {
+   struct ubi_volume *volume = ubi->volumes[i];
+
+   if (!volume)
+   continue;
+
+   if (volume->vol_id >= UBI_INTERNAL_VOL_START)
+   continue;
+
+   if (volume->vol_id == vol_id)
+   return volume->name;
+   }
+
+   return NULL;
+}
+
+static ulong ubi_bread(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
+  void *dst)
+{
+   struct blk_desc *block_dev = dev_get_uclass_plat(dev);
+   char *volume_name = get_volume_name(block_dev->hwpart);
+   unsigned int size = blkcnt * block_dev->blksz;
+   loff_t offset = start * block_dev->blksz;
+   int ret;
+
+   if (!volume_name) {
+   pr_err("%s: failed to find volume name for blk=%ld", __func__, 
start);
+   return -EINVAL;
+   }
+
+   ret = ubi_volume_read(volume_name, dst, offset, size);
+   if (ret) {
+   pr_err("%s: failed to read from %s UBI volume\n", __func__, 
volume_name);
+   return ret;
+   }
+
+   return blkcnt;
+}
+
+static ulong ubi_bwrite(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
+   const void *src)
+{
+   struct blk_desc *block_dev = dev_get_uclass_plat(dev);
+   char *volume_name = get_volume_name(block_dev->hwpart);
+   unsigned int size = blkcnt * block_dev->blksz;
+   loff_t offset = start * block_dev->blksz;
+   int ret;
+
+   if (!volume_name) {
+   pr_err("%s: failed to find volume for blk=%ld", __func__, 
start);
+   return -EINVAL;
+   }
+
+   ret = ubi_volume_write(volume_name, (void *)src, offset, size);
+   if (ret) {
+   pr_err("%s: failed to write from %s UBI volume\n", __func__, 
volume_name);
+   return ret;
+   }
+
+   return blkcnt;
+}
+
+static int ubi_blk_probe(struct udevice *dev)
+{
+   int ret;
+
+   ret = device_probe(dev);
+   if (ret) {
+   pr_err("Probing %s failed (err=%d)\n", dev->name, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct 

[PATCH v2 2/6] ubi: allow to write to volume with offset

2024-03-25 Thread Alexey Romanov
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.

Signed-off-by: Alexey Romanov 
Reviewed-by: Heiko Schocher 
Acked-by: Heiko Schocher 
---
 cmd/ubi.c   | 71 +++--
 env/ubi.c   | 10 +++
 include/ubi_uboot.h |  2 +-
 3 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/cmd/ubi.c b/cmd/ubi.c
index 2257f68498..af874b6a46 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -415,9 +415,74 @@ int ubi_volume_begin_write(char *volume, void *buf, size_t 
size,
return ubi_volume_continue_write(volume, buf, size);
 }
 
-int ubi_volume_write(char *volume, void *buf, size_t size)
+static int ubi_volume_offset_write(char *volume, void *buf, loff_t offset,
+  size_t size)
 {
-   return ubi_volume_begin_write(volume, buf, size, size);
+   int lnum, len, tbuf_size, ret;
+   struct ubi_volume *vol;
+   loff_t off = offset;
+   void *tbuf;
+
+   vol = ubi_find_volume(volume);
+   if (!vol)
+   return -ENODEV;
+
+   if (size > vol->reserved_pebs * (ubi->leb_size - vol->data_pad))
+   return -EINVAL;
+
+   tbuf_size = vol->usable_leb_size;
+   tbuf = malloc_cache_aligned(tbuf_size);
+   if (!tbuf)
+   return -ENOMEM;
+
+   lnum = off;
+   off = do_div(lnum, vol->usable_leb_size);
+
+   do {
+   struct ubi_volume_desc desc = {
+   .vol = vol,
+   .mode = UBI_READWRITE,
+   };
+
+   len = size > tbuf_size ? tbuf_size : size;
+   if (off + len >= vol->usable_leb_size)
+   len = vol->usable_leb_size - off;
+
+   ret = ubi_read(, lnum, tbuf, 0, tbuf_size);
+   if (ret) {
+   pr_err("Failed to read leb %d (%d)\n", lnum, ret);
+   goto exit;
+   }
+
+   memcpy(tbuf + off, buf, len);
+
+   ret = ubi_leb_change(, lnum, tbuf, tbuf_size);
+   if (ret) {
+   pr_err("Failed to write leb %d(%d)\n", lnum, ret);
+   goto exit;
+   }
+
+   off += len;
+   if (off >= vol->usable_leb_size) {
+   lnum++;
+   off -= vol->usable_leb_size;
+   }
+
+   buf += len;
+   size -= len;
+   } while (size);
+
+exit:
+   free(tbuf);
+   return ret;
+}
+
+int ubi_volume_write(char *volume, void *buf, loff_t offset, size_t size)
+{
+   if (!offset)
+   return ubi_volume_begin_write(volume, buf, size, size);
+
+   return ubi_volume_offset_write(volume, buf, offset, size);
 }
 
 int ubi_volume_read(char *volume, char *buf, loff_t offset, size_t size)
@@ -761,7 +826,7 @@ static int do_ubi(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
(void *)addr, size, full_size);
}
} else {
-   ret = ubi_volume_write(argv[3], (void *)addr, size);
+   ret = ubi_volume_write(argv[3], (void *)addr, 0, size);
}
if (!ret) {
printf("%lld bytes written to volume %s\n", size,
diff --git a/env/ubi.c b/env/ubi.c
index 661801d5a9..6ae74a500b 100644
--- a/env/ubi.c
+++ b/env/ubi.c
@@ -54,7 +54,7 @@ static int env_ubi_save(void)
if (gd->env_valid == ENV_VALID) {
puts("Writing to redundant UBI... ");
if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME_REDUND,
-(void *)env_new, CONFIG_ENV_SIZE)) {
+(void *)env_new, 0, CONFIG_ENV_SIZE)) {
printf("\n** Unable to write env to %s:%s **\n",
   CONFIG_ENV_UBI_PART,
   CONFIG_ENV_UBI_VOLUME_REDUND);
@@ -63,7 +63,7 @@ static int env_ubi_save(void)
} else {
puts("Writing to UBI... ");
if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME,
-(void *)env_new, CONFIG_ENV_SIZE)) {
+(void *)env_new, 0, CONFIG_ENV_SIZE)) {
printf("\n** Unable to write env to %s:%s **\n",
   CONFIG_ENV_UBI_PART,
   CONFIG_ENV_UBI_VOLUME);
@@ -93,7 +93,7 @@ static int env_ubi_save(void)
return 1;
}
 
-   if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME, (void *)env_new,
+   if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME, (void *)env_new, 0,
 CONFIG_ENV_SIZE)) {
printf("\n** Unable to write env to %s:%s **\n",
   CONFIG_ENV_UBI_PART, CONFIG_ENV_UBI_VOLUME);
@@ -197,7 +197,7 @@ static int 

[PATCH v2 1/6] ubi: allow to read from volume with offset

2024-03-25 Thread Alexey Romanov
Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.

Signed-off-by: Alexey Romanov 
Reviewed-by: Heiko Schocher 
Acked-by: Heiko Schocher 
---
 cmd/ubi.c   | 6 +++---
 env/ubi.c   | 6 +++---
 include/ubi_uboot.h | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cmd/ubi.c b/cmd/ubi.c
index 0a6a80bdd1..2257f68498 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -420,13 +420,13 @@ int ubi_volume_write(char *volume, void *buf, size_t size)
return ubi_volume_begin_write(volume, buf, size, size);
 }
 
-int ubi_volume_read(char *volume, char *buf, size_t size)
+int ubi_volume_read(char *volume, char *buf, loff_t offset, size_t size)
 {
int err, lnum, off, len, tbuf_size;
void *tbuf;
unsigned long long tmp;
struct ubi_volume *vol;
-   loff_t offp = 0;
+   loff_t offp = offset;
size_t len_read;
 
vol = ubi_find_volume(volume);
@@ -787,7 +787,7 @@ static int do_ubi(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
}
 
if (argc == 3) {
-   return ubi_volume_read(argv[3], (char *)addr, size);
+   return ubi_volume_read(argv[3], (char *)addr, 0, size);
}
}
 
diff --git a/env/ubi.c b/env/ubi.c
index 445d34fedb..661801d5a9 100644
--- a/env/ubi.c
+++ b/env/ubi.c
@@ -135,13 +135,13 @@ static int env_ubi_load(void)
return -EIO;
}
 
-   read1_fail = ubi_volume_read(CONFIG_ENV_UBI_VOLUME, (void *)tmp_env1,
+   read1_fail = ubi_volume_read(CONFIG_ENV_UBI_VOLUME, (void *)tmp_env1, 0,
 CONFIG_ENV_SIZE);
if (read1_fail)
printf("\n** Unable to read env from %s:%s **\n",
   CONFIG_ENV_UBI_PART, CONFIG_ENV_UBI_VOLUME);
 
-   read2_fail = ubi_volume_read(CONFIG_ENV_UBI_VOLUME_REDUND,
+   read2_fail = ubi_volume_read(CONFIG_ENV_UBI_VOLUME_REDUND, 0,
 (void *)tmp_env2, CONFIG_ENV_SIZE);
if (read2_fail)
printf("\n** Unable to read redundant env from %s:%s **\n",
@@ -172,7 +172,7 @@ static int env_ubi_load(void)
return -EIO;
}
 
-   if (ubi_volume_read(CONFIG_ENV_UBI_VOLUME, buf, CONFIG_ENV_SIZE)) {
+   if (ubi_volume_read(CONFIG_ENV_UBI_VOLUME, buf, 0, CONFIG_ENV_SIZE)) {
printf("\n** Unable to read env from %s:%s **\n",
   CONFIG_ENV_UBI_PART, CONFIG_ENV_UBI_VOLUME);
env_set_default(NULL, 0);
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 6da348eb62..bcccb76e6c 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -50,7 +50,7 @@ extern int ubi_init(void);
 extern void ubi_exit(void);
 extern int ubi_part(char *part_name, const char *vid_header_offset);
 extern int ubi_volume_write(char *volume, void *buf, size_t size);
-extern int ubi_volume_read(char *volume, char *buf, size_t size);
+extern int ubi_volume_read(char *volume, char *buf, loff_t offset, size_t 
size);
 
 extern struct ubi_device *ubi_devices[];
 int cmd_ubifs_mount(char *vol_name);
-- 
2.34.1



[PATCH v2 0/6] Introduce UBI block device

2024-03-25 Thread Alexey Romanov
Hello!

This series adds support for the UBI block device, which
allows to read/write data block by block. For example,
it can now be used for BCB or Android AB command:

  $ bcb load ubi 0 part_name

Tested only on SPI NAND, so bind is made only for
SPI NAND drivers. Can be used with mtdblock device [1].

--- 

Changes V1 -> V2 [2]:

 - Rebased over mtdblock v2 patchset [3].
 - Compile UBI partitions support only if CONFIG_BLK option
   is enabled.

- Links:

  [1] 
https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
  [2] 
https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
  [3] 
https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/

Alexey Romanov (6):
  ubi: allow to read from volume with offset
  ubi: allow to write to volume with offset
  drivers: introduce UBI block abstraction
  disk: don't try search for partition type if already set
  disk: support UBI partitions
  spinand: bind UBI block

 cmd/ubi.c   |  77 +++--
 disk/part.c |   7 ++
 drivers/block/blk-uclass.c  |   1 +
 drivers/mtd/nand/spi/core.c |   8 ++-
 drivers/mtd/ubi/Makefile|   1 +
 drivers/mtd/ubi/block.c | 130 
 drivers/mtd/ubi/part.c  |  99 +++
 env/ubi.c   |  16 ++---
 include/part.h  |   2 +
 include/ubi_uboot.h |   8 ++-
 10 files changed, 332 insertions(+), 17 deletions(-)
 create mode 100644 drivers/mtd/ubi/block.c
 create mode 100644 drivers/mtd/ubi/part.c

-- 
2.34.1



Re: [PATCH] arm64: zynqmp: dts: Add required properties for rs485 support for KD240

2024-03-25 Thread Michal Simek




On 3/19/24 12:27, Michal Simek wrote:

From: Manikanta Guntupalli 

Add "rts-gpios" and "linux,rs485-enabled-at-boot-time" properties
to uartps node to support RS485 on KD240.

Signed-off-by: Manikanta Guntupalli 
Signed-off-by: Michal Simek 
---

  arch/arm/dts/zynqmp-sck-kd-g-revA.dtso | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso 
b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
index 5202b7c48198..1727a1cc15c1 100644
--- a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
@@ -356,6 +356,8 @@
  
   {

status = "okay";
+   rts-gpios = < 72 GPIO_ACTIVE_HIGH>;
+   linux,rs485-enabled-at-boot-time;
pinctrl-names = "default";
pinctrl-0 = <_uart0_default>;
assigned-clock-rates = <1>;


Applied.
M


Re: [PATCH] arm64: zynqmp: Disable Tri-state for SDIO

2024-03-25 Thread Michal Simek




On 3/21/24 09:52, Tejas Bhumkar wrote:

Since the zynqmp pinctrl driver now includes support for the
tri-state registers, ensure that the pins needing output-enable
are correctly configured for SOMs.

Currently, there is an issue with the detection of the MMC for
the SOM kv260, resulting in the following error:
ZynqMP> mmc dev 1
Card did not respond to voltage select! : -110

To address this problem, configure the SDIO pins for output-enable
to enable MMC detection.

Signed-off-by: Michal Simek 
Signed-off-by: Tejas Bhumkar 
---
  arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 1 +
  arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 1 +
  2 files changed, 2 insertions(+)

diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso 
b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
index 6d0d5c487d..561b546e37 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
@@ -342,6 +342,7 @@
slew-rate = ;
power-source = ;
bias-disable;
+   output-enable;
};
  
  		conf-cd {

diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso 
b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
index a4b4465d20..13876fb47d 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
@@ -329,6 +329,7 @@
slew-rate = ;
power-source = ;
bias-disable;
+   output-enable;
};
  
  		conf-cd {


Applied.
M


Re: [PATCH] arm64: zynqmp: Add bootcmd_usb4 variable

2024-03-25 Thread Michal Simek




On 3/20/24 12:24, Michal Simek wrote:

From: Shubhangi Shrikrushna Mahalle 

Add "bootcmd_usb4" variable to boot through usb4 device.

Signed-off-by: Shubhangi Shrikrushna Mahalle 

Signed-off-by: Michal Simek 
---

It should be the part of
https://lore.kernel.org/r/20240305110256.153308-1-venkatesh.abbar...@amd.com
---
  board/xilinx/zynqmp/zynqmp_kria.env | 1 +
  1 file changed, 1 insertion(+)

diff --git a/board/xilinx/zynqmp/zynqmp_kria.env 
b/board/xilinx/zynqmp/zynqmp_kria.env
index 7d3ad3122605..846eceb0118d 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -17,6 +17,7 @@ bootcmd_usb0=devnum=0; run usb_boot
  bootcmd_usb1=devnum=1; run usb_boot
  bootcmd_usb2=devnum=2; run usb_boot
  bootcmd_usb3=devnum=3; run usb_boot
+bootcmd_usb4=devnum=4; run usb_boot
  bootdelay=2
  bootfstype=fat
  bootm_low=0


Applied.
M


Re: [PATCH] arm64: zynqmp: Also support JTAG as alternative boot mode

2024-03-25 Thread Michal Simek




On 3/20/24 12:18, Michal Simek wrote:

if (reg >> BOOT_MODE_ALT_SHIFT) condition rules out alternative jtag boot
mode which is 0. When 0 was used origin(HW) boot mode was used instead.
That's why directly fill reg variable with requested boot mode and don't
let code to read value back. "else" part of code remain unchanged.

Signed-off-by: Michal Simek 
---

  arch/arm/mach-zynqmp/spl.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index 5af735aa5cef..979ff3aef6c2 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -91,13 +91,14 @@ u32 spl_boot_device(void)
  
  #if defined(CONFIG_SPL_ZYNQMP_ALT_BOOTMODE_ENABLED)

/* Change default boot mode at run-time */
+   reg = CONFIG_SPL_ZYNQMP_ALT_BOOTMODE;
writel(CONFIG_SPL_ZYNQMP_ALT_BOOTMODE << BOOT_MODE_ALT_SHIFT,
   _base->boot_mode);
-#endif
-
+#else
reg = readl(_base->boot_mode);
if (reg >> BOOT_MODE_ALT_SHIFT)
reg >>= BOOT_MODE_ALT_SHIFT;
+#endif
  
  	bootmode = reg & BOOT_MODES_MASK;
  


Applied.
M


Re: [PATCH] phycore_pcl063: Drop leading zero from USB vendor number

2024-03-25 Thread Marek Vasut

On 3/25/24 2:52 PM, Fabio Estevam wrote:

CONFIG_USB_GADGET_VENDOR_NUM is a 16-bit number, so remove
the leading zero.

Reported-by: Marek Vasut 
Signed-off-by: Fabio Estevam 
---
  configs/phycore_pcl063_defconfig | 2 +-
  configs/phycore_pcl063_ull_defconfig | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig
index 6b00df1cffb3..017054a8e12b 100644
--- a/configs/phycore_pcl063_defconfig
+++ b/configs/phycore_pcl063_defconfig
@@ -63,7 +63,7 @@ CONFIG_USB=y
  CONFIG_SPL_USB_HOST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_MANUFACTURER="Phytec"
-CONFIG_USB_GADGET_VENDOR_NUM=0x01b67
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
  CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff
  CONFIG_CI_UDC=y
  CONFIG_USB_GADGET_DOWNLOAD=y
diff --git a/configs/phycore_pcl063_ull_defconfig 
b/configs/phycore_pcl063_ull_defconfig
index 6195fcfb73df..b3da43a5bf1e 100644
--- a/configs/phycore_pcl063_ull_defconfig
+++ b/configs/phycore_pcl063_ull_defconfig
@@ -54,7 +54,7 @@ CONFIG_USB=y
  CONFIG_SPL_USB_HOST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_MANUFACTURER="Phytec"
-CONFIG_USB_GADGET_VENDOR_NUM=0x01b67
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67


Reviewed-by: Marek Vasut 

+CC Yamada-san , can Kconfig somehow sanitize 16bit numbers like this ?


[PATCH] phycore_pcl063: Drop leading zero from USB vendor number

2024-03-25 Thread Fabio Estevam
CONFIG_USB_GADGET_VENDOR_NUM is a 16-bit number, so remove
the leading zero.

Reported-by: Marek Vasut 
Signed-off-by: Fabio Estevam 
---
 configs/phycore_pcl063_defconfig | 2 +-
 configs/phycore_pcl063_ull_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig
index 6b00df1cffb3..017054a8e12b 100644
--- a/configs/phycore_pcl063_defconfig
+++ b/configs/phycore_pcl063_defconfig
@@ -63,7 +63,7 @@ CONFIG_USB=y
 CONFIG_SPL_USB_HOST=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Phytec"
-CONFIG_USB_GADGET_VENDOR_NUM=0x01b67
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
diff --git a/configs/phycore_pcl063_ull_defconfig 
b/configs/phycore_pcl063_ull_defconfig
index 6195fcfb73df..b3da43a5bf1e 100644
--- a/configs/phycore_pcl063_ull_defconfig
+++ b/configs/phycore_pcl063_ull_defconfig
@@ -54,7 +54,7 @@ CONFIG_USB=y
 CONFIG_SPL_USB_HOST=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Phytec"
-CONFIG_USB_GADGET_VENDOR_NUM=0x01b67
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
-- 
2.34.1



Re: [GIT PULL] Please pull u-boot-amlogic-fixes-20240325

2024-03-25 Thread Tom Rini
On Mon, Mar 25, 2024 at 10:45:43AM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> Please pull this set of last minute fixes
> 
> Thanks,
> Neil
> 
> The following changes since commit bd0aedde3ea3691616c17c720e2d25351308c0a1:
> 
>   board: toradex: verdin-am62_r5: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN 
> (2024-03-22 11:10:51 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-fixes-20240325
> 
> for you to fetch changes up to d54f87f09a36ac20154955297b7c999b368b0443:
> 
>   board: amlogic: fix buffler overflow in seria, mac & usid read (2024-03-25 
> 09:16:19 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL next] u-boot-at91-2024.07-a

2024-03-25 Thread Tom Rini
On Mon, Mar 25, 2024 at 09:45:44AM +0200, Eugen Hristev wrote:

> Hello Tom,
> 
> 
> Please pull tag u-boot-at91-2024.07-a , the first set of at91
> features for the next cycle 2024.07 .
> 
> This feature set includes a new board named sama7g54 Curiosity.
> 
> Thanks,
> Eugen
> 
> The following changes since commit 20a0ce574d6642e0dfe651467159039fac48cc4f:
> 
>   Merge tag 'v2024.04-rc4' into next (2024-03-11 15:27:20 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-at91.git 
> tags/u-boot-at91-2024.07-a
> 
> for you to fetch changes up to a7ba3bf65db264c02a774a59e8febc2ecb095f68:
> 
>   configs: at91: sama7g54_curiosity: Add initial default configs (2024-03-13
> 13:35:16 +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [GIT PULL] Please pull u-boot-imx-next-20240324

2024-03-25 Thread Tom Rini
On Sun, Mar 24, 2024 at 02:53:08PM -0300, Fabio Estevam wrote:

> Hi Tom,
> 
> Please pull this material for next from u-boot-imx, thanks.
> 
> The following changes since commit fb49d6c289d942ff7de309a5c5eaa37a7f4235db:
> 
>   remoteproc: uclass: Add methods to load firmware to rproc and boot rproc 
> (2024-03-22 15:50:28 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
> tags/u-boot-imx-next-20240324
> 
> for you to fetch changes up to 9d27e441bb14dd526c60c13d5ff16353ca322eb3:
> 
>   board: phytec: phycore_imx8mp.env fix netboot issues (2024-03-24 13:42:10 
> -0300)
> 
> u-boot-imx-next-20240324

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1 1/3] crypto/fsl: allow accessing Job Ring from non-TrustZone

2024-03-25 Thread Fabio Estevam
Hi Emanuele,

On Mon, Mar 25, 2024 at 8:47 AM Emanuele Ghidoli
 wrote:

> +config FSL_CAAM_JR_NTZ_ACCESS
> +   bool "Give caam Job Ring access to non-secure world"

Please spell CAAM instead.

> +   default n

'default n' is already the default, please drop this line.


Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet

2024-03-25 Thread Roger Quadros
Hi Tom / Joe,

On 05/03/2024 15:24, Roger Quadros wrote:
> Currently, the GPIO Reset Device Tree properties of the
> PHY node are ignored when the PHY is probed via mdio-uclass driver [1].
> 
> To resolve this, for each child of the MDIO bus node, bind and probe
> the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled.
> 
> This should now show the generic_phy_driver in "dm tree"
> and also apply the GPIO reset before the MDIO bus driver scans the bus
> for the PHYs.
> 
>  ethernet  0  [ + ]   am65_cpsw_nuss_port   |   |-- 
> ethernet@800port@1
>  bootdev   3  [   ]   eth_bootdev   |   |   `-- port@1.bootdev
>  mdio  0  [ + ]   cpsw_mdio |   `-- mdio@f00
>  eth_phy_ge0  [ + ]   eth_phy_generic_drv   |   |-- ethernet-phy@0
>  eth_phy_ge1  [ + ]   eth_phy_generic_drv   |   `-- ethernet-phy@1
> 
> To test this on Beagleplay, the following series is required
> 
> [1] Switch am65-cpsw to DM MDIO
>  
> https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/
> 
> The last 3 patches are marked [not-for-merge]. They are to show how the
> whole solution can work to fix Ethernet on Beagleplay, which has been broken
> so far. Those DT patches will be sent once the device tree changes are merged
> into Linux tree.
> 
> Signed-off-by: Roger Quadros 
> ---
> Roger Quadros (5):
>   net: mdio-uclass: Bind and probe generic Ethernet PHY driver
>   configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY

Any comments to the first 2 patches in this series?

>   [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229
>   [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
>   [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset 
> GPIO
> 
>  arch/arm/dts/k3-am62-main.dtsi   | 126 ++---
>  arch/arm/dts/k3-am62-mcu.dtsi|   4 +-
>  arch/arm/dts/k3-am62-phycore-som.dtsi|   5 +-
>  arch/arm/dts/k3-am62-thermal.dtsi|   5 +-
>  arch/arm/dts/k3-am62-verdin-dev.dtsi |   4 +-
>  arch/arm/dts/k3-am62-verdin-wifi.dtsi|   1 -
>  arch/arm/dts/k3-am62-verdin.dtsi |  76 +++---
>  arch/arm/dts/k3-am62-wakeup.dtsi |  38 +++--
>  arch/arm/dts/k3-am62.dtsi|   4 +-
>  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi |  63 +
>  arch/arm/dts/k3-am625-beagleplay.dts |  66 -
>  arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts  | 104 +-
>  arch/arm/dts/k3-am625-sk.dts |   4 +-
>  arch/arm/dts/k3-am625.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a-main.dtsi  | 201 
> +--
>  arch/arm/dts/k3-am62a-mcu.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a-thermal.dtsi   |   5 +-
>  arch/arm/dts/k3-am62a-wakeup.dtsi|   4 +-
>  arch/arm/dts/k3-am62a.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a7-sk.dts| 162 -
>  arch/arm/dts/k3-am62a7.dtsi  |   4 +-
>  arch/arm/dts/k3-am62x-sk-common.dtsi |  24 +++-
>  configs/am62x_beagleplay_a53_defconfig   |   2 +-
>  net/mdio-uclass.c|  41 ++
>  24 files changed, 825 insertions(+), 130 deletions(-)
> ---
> base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e
> change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937
> 
> Best regards,

-- 
cheers,
-roger


[PATCH v1 3/3] configs: colibri-imx7: allow accessing job-rings from non-TrustZone

2024-03-25 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Set FSL_CAAM_JR_NTZ_ACCESS configuration since colibri-imx7
uses Freescale CAAM Job Ring linux driver

Signed-off-by: Emanuele Ghidoli 
---
 configs/colibri_imx7_defconfig  | 1 +
 configs/colibri_imx7_emmc_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 0c6a272ddfc6..16f923b07c22 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -72,6 +72,7 @@ CONFIG_SERVERIP="192.168.10.1"
 CONFIG_BOUNCE_BUFFER=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_BOOTCOUNT_ENV=y
+CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y
 CONFIG_DFU_NAND=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8110
diff --git a/configs/colibri_imx7_emmc_defconfig 
b/configs/colibri_imx7_emmc_defconfig
index 8dd9fe6e6a38..7c6a725ea9a2 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -61,6 +61,7 @@ CONFIG_USE_SERVERIP=y
 CONFIG_SERVERIP="192.168.10.1"
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_BOOTCOUNT_ENV=y
+CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8110
 CONFIG_FASTBOOT_FLASH=y
-- 
2.34.1



[PATCH v1 2/3] configs: colibri-imx7: set non-secure boot mode as default

2024-03-25 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Linux kernel is supposed to run in non-secure world,
fix the defconfig accordingly.

Signed-off-by: Emanuele Ghidoli 
---
 configs/colibri_imx7_emmc_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/colibri_imx7_emmc_defconfig 
b/configs/colibri_imx7_emmc_defconfig
index 9d4423cd0d6a..8dd9fe6e6a38 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -8,7 +8,6 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7d-colibri-emmc-eval-v3"
 CONFIG_TARGET_COLIBRI_IMX7=y
 CONFIG_TARGET_COLIBRI_IMX7_EMMC=y
 CONFIG_OF_LIBFDT_OVERLAY=y
-CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
 CONFIG_IMX_HAB=y
-- 
2.34.1



[PATCH v1 1/3] crypto/fsl: allow accessing Job Ring from non-TrustZone

2024-03-25 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Add a new kconfig option to allow non-secure world access
to the CAAM Job Ring.
This is needed, for example, when running linux without
OP-TEE services, as it's done on Colibri iMX7.

Fixes: 51f1357f3428 ("Revert "drivers/crypto/fsl: assign job-rings to 
non-TrustZone"")
Signed-off-by: Emanuele Ghidoli 
---
 drivers/crypto/fsl/Kconfig |  7 +++
 drivers/crypto/fsl/jr.c| 19 +++
 drivers/crypto/fsl/jr.h|  2 ++
 3 files changed, 28 insertions(+)

diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
index eaad19633f1d..e95675ee3e8e 100644
--- a/drivers/crypto/fsl/Kconfig
+++ b/drivers/crypto/fsl/Kconfig
@@ -62,6 +62,13 @@ config SYS_FSL_SEC_LE
 
 if FSL_CAAM
 
+config FSL_CAAM_JR_NTZ_ACCESS
+   bool "Give caam Job Ring access to non-secure world"
+   default n
+   help
+ It is needed when OP-TEE is not used and Freescale CAAM Job Ring linux
+ driver is used.
+
 config FSL_CAAM_RNG
bool "Enable Random Number Generator support"
depends on DM_RNG
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index ceb66dd6270d..203f16252159 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -673,6 +673,21 @@ static int rng_init(uint8_t sec_idx, ccsr_sec_t *sec)
return ret;
 }
 
+#if CONFIG_IS_ENABLED(FSL_CAAM_JR_NTZ_ACCESS)
+static void jr_setown_non_trusted(ccsr_sec_t *sec)
+{
+   u32 jrown_ns;
+   int i;
+
+   /* Set ownership of job rings to non-TrustZone mode */
+   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
+   jrown_ns = sec_in32(>jrliodnr[i].ms);
+   jrown_ns |= JROWN_NS | JRMID_NS;
+   sec_out32(>jrliodnr[i].ms, jrown_ns);
+   }
+}
+#endif
+
 int sec_init_idx(uint8_t sec_idx)
 {
int ret = 0;
@@ -761,6 +776,10 @@ int sec_init_idx(uint8_t sec_idx)
 #if CONFIG_IS_ENABLED(OF_CONTROL)
 init:
 #endif
+#if CONFIG_IS_ENABLED(FSL_CAAM_JR_NTZ_ACCESS)
+   jr_setown_non_trusted(sec);
+#endif
+
ret = jr_init(sec_idx, caam);
if (ret < 0) {
printf("SEC%u:  initialization failed\n", sec_idx);
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index 4e4c4af5805f..b136cd8d05a9 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -37,6 +37,8 @@
 #define JRNSLIODN_MASK 0x0fff
 #define JRSLIODN_SHIFT 0
 #define JRSLIODN_MASK  0x0fff
+#define JROWN_NS   0x0008
+#define JRMID_NS   0x0001
 
 #define JRDID_MS_PRIM_DID  BIT(0)
 #define JRDID_MS_PRIM_TZ   BIT(4)
-- 
2.34.1



[PATCH v1 0/3] crypto/fsl: allow accessing Job Ring from non-TrustZone

2024-03-25 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

This series allows using Freescale CAAM Job Ring from Linux without having 
OP-TEE,
this is needed for example on Toradex Colibri iMX7 where we just have U-Boot + 
Linux kernel.

To achieve this add a new config option to allow the non-secure world to access 
job rings.

The functionality has been broken since U-Boot v2019.07, with commit 
51f1357f3428
("Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"")

Link: 
https://lore.kernel.org/all/4b64a9de-a840-4065-a530-f81155b4b...@toradex.com/

Regards,
Emanuele Ghidoli

Emanuele Ghidoli (3):
  crypto/fsl: allow accessing Job Ring from non-TrustZone
  configs: colibri-imx7: set non-secure boot mode as default
  configs: colibri-imx7: allow accessing job-rings from non-TrustZone

 configs/colibri_imx7_defconfig  |  1 +
 configs/colibri_imx7_emmc_defconfig |  2 +-
 drivers/crypto/fsl/Kconfig  |  7 +++
 drivers/crypto/fsl/jr.c | 19 +++
 drivers/crypto/fsl/jr.h |  2 ++
 5 files changed, 30 insertions(+), 1 deletion(-)

-- 
2.34.1



Re: [PATCH u-boot v2019.04-aspeed-openbmc] ARM: dts: aspeed: Add Ampere's BMC platform (AST2600)

2024-03-25 Thread Chanh Nguyen




On 25/03/2024 12:32, Andrew Jeffery wrote:

Hi Chanh,

On Tue, 2024-03-19 at 14:21 +0700, Chanh Nguyen wrote:

Add the initial version of the device tree for the Ampere BMC
platform, which is equipped with the Aspeed AST2600 BMC SoC.

Signed-off-by: Chanh Nguyen 
---
  arch/arm/dts/Makefile   |   1 +
  arch/arm/dts/ast2600-ampere.dts | 113 
  2 files changed, 114 insertions(+)
  create mode 100644 arch/arm/dts/ast2600-ampere.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 37675a3277..3642d59c89 100755
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -691,6 +691,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
ast2600-greatlakes.dtb \
ast2600-intel.dtb \
ast2600-ncsi.dtb \
+   ast2600-ampere.dtb \
ast2600-p10bmc.dtb \
ast2600-pfr.dtb \
ast2600-qcom-dc-scm-v1.dtb \


Given this hunk and the tags in the `[PATCH]` prefix of the mail
subject you've based this change on OpenBMC's fork of u-boot, which is
heavily (out of date, and) inspired by Aspeed's SDK tree. I've applied
this to OpenBMC's fork for now.



Thank Andrew! I saw my patch on the OpenBMC's fork.


However, you've sent this to the upstream list. You will need to rework
your patch on top of mainline u-boot if you want it accepted there, and
follow all the usual documentation on how to submit patches to the u-
boot project (e.g. you should not be including `u-boot v2019.04-aspeed-
openbmc` in the patch subject prefix in upstream submissions).

Andrew


Sorry all! It is my mistake. I just want to send this to OpenBMC's fork, 
but I used the upstream mail list.


Re: [PATCH u-boot v2019.04-aspeed-openbmc] ARM: dts: aspeed: Add Ampere's BMC platform (AST2600)

2024-03-25 Thread Andrew Jeffery
Hi Chanh,

On Tue, 2024-03-19 at 14:21 +0700, Chanh Nguyen wrote:
> Add the initial version of the device tree for the Ampere BMC
> platform, which is equipped with the Aspeed AST2600 BMC SoC.
> 
> Signed-off-by: Chanh Nguyen 
> ---
>  arch/arm/dts/Makefile   |   1 +
>  arch/arm/dts/ast2600-ampere.dts | 113 
>  2 files changed, 114 insertions(+)
>  create mode 100644 arch/arm/dts/ast2600-ampere.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 37675a3277..3642d59c89 100755
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -691,6 +691,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   ast2600-greatlakes.dtb \
>   ast2600-intel.dtb \
>   ast2600-ncsi.dtb \
> + ast2600-ampere.dtb \
>   ast2600-p10bmc.dtb \
>   ast2600-pfr.dtb \
>   ast2600-qcom-dc-scm-v1.dtb \

Given this hunk and the tags in the `[PATCH]` prefix of the mail
subject you've based this change on OpenBMC's fork of u-boot, which is
heavily (out of date, and) inspired by Aspeed's SDK tree. I've applied
this to OpenBMC's fork for now.

However, you've sent this to the upstream list. You will need to rework
your patch on top of mainline u-boot if you want it accepted there, and
follow all the usual documentation on how to submit patches to the u-
boot project (e.g. you should not be including `u-boot v2019.04-aspeed-
openbmc` in the patch subject prefix in upstream submissions).

Andrew


Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries

2024-03-25 Thread Neha Malcom Francis

Hi Manorit

On 25/03/24 14:50, Manorit Chawdhry wrote:

Hi Neha,

On 18:40-20240322, Neha Malcom Francis wrote:

Clean up templatized boot binaries for all K3 boards. This includes
modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
code.

All k3--binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.

Signed-off-by: Neha Malcom Francis 
---
  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  | 161 +-
  arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 +
  arch/arm/dts/k3-am625-r5-beagleplay.dts   |  39 ---
  arch/arm/dts/k3-am625-sk-binman.dtsi  | 148 +
  arch/arm/dts/k3-am625-sk-u-boot.dtsi  |  42 +++
  .../dts/k3-am625-verdin-wifi-dev-binman.dtsi  | 296 +-
  arch/arm/dts/k3-am62a-sk-binman.dtsi  | 146 +
  arch/arm/dts/k3-am62a7-sk-u-boot.dtsi |  42 +++
  arch/arm/dts/k3-am642-evm-u-boot.dtsi |  42 +++
  arch/arm/dts/k3-am642-sk-u-boot.dtsi  |  42 +++
  arch/arm/dts/k3-am64x-binman.dtsi | 239 +-
  arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |  49 +++
  arch/arm/dts/k3-am65x-binman.dtsi | 144 +
  .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi |  26 ++
  arch/arm/dts/k3-am69-sk-u-boot.dtsi   |  31 +-
  arch/arm/dts/k3-binman.dtsi   |  96 ++
  arch/arm/dts/k3-j7200-binman.dtsi | 145 +
  .../k3-j7200-common-proc-board-u-boot.dtsi|  40 +++
  .../dts/k3-j721e-beagleboneai64-u-boot.dtsi   | 154 +
  arch/arm/dts/k3-j721e-binman.dtsi | 262 +++-
  .../k3-j721e-common-proc-board-u-boot.dtsi|  84 +
  arch/arm/dts/k3-j721e-r5-beagleboneai64.dts   |  91 +-
  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  |  84 +
  arch/arm/dts/k3-j721s2-binman.dtsi| 231 +-
  .../k3-j721s2-common-proc-board-u-boot.dtsi   |  42 +++
  arch/arm/dts/k3-j784s4-binman.dtsi| 154 +
  arch/arm/dts/k3-j784s4-evm-u-boot.dtsi|  42 +++
  27 files changed, 858 insertions(+), 2305 deletions(-)



[ snip ]


diff --git a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi 
b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
index ed50bfeb031..14fc8468c56 100644
--- a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
+++ b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
@@ -6,309 +6,48 @@
   * Author: Wadim Egorov 
   */
  
-#include "k3-binman.dtsi"

+#define SPL_BOARD_DTB "spl/dts/k3-am625-phyboard-lyra-rdk.dtb"
+#define BOARD_DESCRIPTION "k3-am625-phyboard-lyra-rdk"
+#define UBOOT_BOARD_DESCRIPTION "U-Boot for phyCORE-AM62x"
+
+#include "k3-am625-sk-binman.dtsi"
  
  #ifdef CONFIG_TARGET_PHYCORE_AM62X_R5

   {
tiboot3-am62x-hs-phycore-som.bin {
filename = "tiboot3-am62x-hs-phycore-som.bin";
-   ti-secure-rom {
-   content = <_boot_spl>, <_fs_enc>, 
<_tifs_cfg>,
-   <_dm_cfg>, <_inner_cert>;
-   combined;
-   dm-data;
-   sysfw-inner-cert;
-   keyfile = "custMpk.pem";
-   sw-rev = <1>;
-   content-sbl = <_boot_spl>;
-   content-sysfw = <_fs_enc>;
-   content-sysfw-data = <_tifs_cfg>;
-   content-sysfw-inner-cert = <_inner_cert>;
-   content-dm-data = <_dm_cfg>;


I was looking between SoCs that we have and all this data seems common
to me on first glance, like there is only some delta in tiboot3
templates as well and maybe we can minimise those as well if am not
missing anything.

in k3-binman.dtsi:

tiboot3_combined_gp: template-x {
section {
ti-secure-rom {
content = <_boot_spl_unsigned>, <_fs_gp>,
<_tifs_cfg_gp>, <_dm_cfg_gp>;
combined;
dm-data;
content-sbl = <_boot_spl_unsigned>;
content-sysfw = <_fs_gp>;
content-sysfw-data = <_tifs_cfg_gp>;
content-dm-data = <_dm_cfg_gp>;
sw-rev = <1>;
keyfile = "ti-degenerate-key.pem";
};
u_boot_spl_unsigned: u-boot-spl {
no-expanded;
};
ti_fs_gp: ti-fs-gp.bin {
type = "blob-ext";
optional;
};
combined_tifs_cfg_gp: combined-tifs-cfg-gp.bin {
filename = 

[PATCH] arm64: dts: zynqmp: make hw-ecc as the default ecc mode

2024-03-25 Thread Venkatesh Yadav Abbarapu
Except for Linux no other component (i.e., u-boot, fsbl
or BootRom) of the software stack supports software ecc
engine. So, make hw-ecc as the default ecc mode.
Update the same for mini u-boot nand configuration as well.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
 arch/arm/dts/zynqmp-mini-nand.dts| 6 ++
 arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 6 ++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/zynqmp-mini-nand.dts 
b/arch/arm/dts/zynqmp-mini-nand.dts
index e0517cf460..5889d436ed 100644
--- a/arch/arm/dts/zynqmp-mini-nand.dts
+++ b/arch/arm/dts/zynqmp-mini-nand.dts
@@ -50,6 +50,12 @@
#size-cells = <1>;
arasan,has-mdma;
num-cs = <2>;
+   nand@0 {
+   reg = <0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   nand-ecc-mode = "hw";
+   };
};
};
 };
diff --git a/arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts 
b/arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts
index b97f7ee8d4..48ab619472 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts
@@ -136,8 +136,7 @@
reg = <0x0>;
#address-cells = <0x2>;
#size-cells = <0x1>;
-   nand-ecc-mode = "soft";
-   nand-ecc-algo = "bch";
+   nand-ecc-mode = "hw";
nand-rb = <0>;
label = "main-storage-0";
nand-ecc-step-size = <1024>;
@@ -173,8 +172,7 @@
reg = <0x1>;
#address-cells = <0x2>;
#size-cells = <0x1>;
-   nand-ecc-mode = "soft";
-   nand-ecc-algo = "bch";
+   nand-ecc-mode = "hw";
nand-rb = <0>;
label = "main-storage-1";
nand-ecc-step-size = <1024>;
-- 
2.17.1



[GIT PULL] Please pull u-boot-amlogic-fixes-20240325

2024-03-25 Thread Neil Armstrong

Hi Tom,

Please pull this set of last minute fixes

Thanks,
Neil

The following changes since commit bd0aedde3ea3691616c17c720e2d25351308c0a1:

  board: toradex: verdin-am62_r5: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN 
(2024-03-22 11:10:51 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
tags/u-boot-amlogic-fixes-20240325

for you to fetch changes up to d54f87f09a36ac20154955297b7c999b368b0443:

  board: amlogic: fix buffler overflow in seria, mac & usid read (2024-03-25 
09:16:19 +0100)


- fix Ethernet and random MAC's on WeTek Hub/Play2
- fix buffer overflow in serial, mac & usid read


Christian Hewitt (2):
  ARM: dts: fix Ethernet on WeTek Hub/Play2
  board: amlogic: add meson_generate_serial_ethaddr fallback to p200

Neil Armstrong (1):
  board: amlogic: fix buffler overflow in seria, mac & usid read

 ...b-wetek-u-boot.dtsi => meson-gxbb-wetek-hub-u-boot.dtsi} |  0
 arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi | 13 +
 board/amlogic/beelink-s922x/beelink-s922x.c |  3 ++-
 board/amlogic/jethub-j100/jethub-j100.c |  3 ++-
 board/amlogic/jethub-j80/jethub-j80.c   |  9 ++---
 board/amlogic/odroid-n2/odroid-n2.c |  3 ++-
 board/amlogic/p200/p200.c   |  8 ++--
 board/amlogic/p201/p201.c   |  6 --
 board/amlogic/p212/p212.c   |  6 --
 board/amlogic/q200/q200.c   |  6 --
 board/amlogic/vim3/vim3.c   |  3 ++-
 11 files changed, 45 insertions(+), 15 deletions(-)
 rename arch/arm/dts/{meson-gxbb-wetek-u-boot.dtsi => 
meson-gxbb-wetek-hub-u-boot.dtsi} (100%)
 create mode 100644 arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi


Re: [PATCH v1 3/3] board: amlogic: jethubj100: update docs

2024-03-25 Thread Neil Armstrong

On 27/02/2024 07:54, Viacheslav Bocharov wrote:

Improove documentation, add new revision.

Signed-off-by: Viacheslav Bocharov 
---
  doc/board/amlogic/jethub-j100.rst | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/doc/board/amlogic/jethub-j100.rst 
b/doc/board/amlogic/jethub-j100.rst
index 86acdafa06f..80bed6e919e 100644
--- a/doc/board/amlogic/jethub-j100.rst
+++ b/doc/board/amlogic/jethub-j100.rst
@@ -1,9 +1,9 @@
  .. SPDX-License-Identifier: GPL-2.0+
  
-U-Boot for JetHub J100 (A113X)

+U-Boot for JetHub J100/J110 (A113X)
  ==
  


I have a CI failure: 
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/jobs/804174
/builds/u-boot/custodians/u-boot-amlogic/doc/board/amlogic/jethub-j100.rst:4:Title
 underline too short.
U-Boot for JetHub J100/J110 (A113X)

Could you check and send a follow-up patch I can squash on top?

Thanks,
Neil


Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries

2024-03-25 Thread Manorit Chawdhry
Hi Neha,

On 18:40-20240322, Neha Malcom Francis wrote:
> Clean up templatized boot binaries for all K3 boards. This includes
> modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
> UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
> code.
> 
> All k3--binman.dtsi will contain only templates. Only required boot
> binaries can be built from the templates in the boards' respective
> -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
> clear distinction between the SoC common stuff vs. what is additionally
> needed to boot up a specific board.
> 
> Signed-off-by: Neha Malcom Francis 
> ---
>  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  | 161 +-
>  arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 +
>  arch/arm/dts/k3-am625-r5-beagleplay.dts   |  39 ---
>  arch/arm/dts/k3-am625-sk-binman.dtsi  | 148 +
>  arch/arm/dts/k3-am625-sk-u-boot.dtsi  |  42 +++
>  .../dts/k3-am625-verdin-wifi-dev-binman.dtsi  | 296 +-
>  arch/arm/dts/k3-am62a-sk-binman.dtsi  | 146 +
>  arch/arm/dts/k3-am62a7-sk-u-boot.dtsi |  42 +++
>  arch/arm/dts/k3-am642-evm-u-boot.dtsi |  42 +++
>  arch/arm/dts/k3-am642-sk-u-boot.dtsi  |  42 +++
>  arch/arm/dts/k3-am64x-binman.dtsi | 239 +-
>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |  49 +++
>  arch/arm/dts/k3-am65x-binman.dtsi | 144 +
>  .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi |  26 ++
>  arch/arm/dts/k3-am69-sk-u-boot.dtsi   |  31 +-
>  arch/arm/dts/k3-binman.dtsi   |  96 ++
>  arch/arm/dts/k3-j7200-binman.dtsi | 145 +
>  .../k3-j7200-common-proc-board-u-boot.dtsi|  40 +++
>  .../dts/k3-j721e-beagleboneai64-u-boot.dtsi   | 154 +
>  arch/arm/dts/k3-j721e-binman.dtsi | 262 +++-
>  .../k3-j721e-common-proc-board-u-boot.dtsi|  84 +
>  arch/arm/dts/k3-j721e-r5-beagleboneai64.dts   |  91 +-
>  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  |  84 +
>  arch/arm/dts/k3-j721s2-binman.dtsi| 231 +-
>  .../k3-j721s2-common-proc-board-u-boot.dtsi   |  42 +++
>  arch/arm/dts/k3-j784s4-binman.dtsi| 154 +
>  arch/arm/dts/k3-j784s4-evm-u-boot.dtsi|  42 +++
>  27 files changed, 858 insertions(+), 2305 deletions(-)
> 

[ snip ]

> diff --git a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi 
> b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
> index ed50bfeb031..14fc8468c56 100644
> --- a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
> +++ b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
> @@ -6,309 +6,48 @@
>   * Author: Wadim Egorov 
>   */
>  
> -#include "k3-binman.dtsi"
> +#define SPL_BOARD_DTB "spl/dts/k3-am625-phyboard-lyra-rdk.dtb"
> +#define BOARD_DESCRIPTION "k3-am625-phyboard-lyra-rdk"
> +#define UBOOT_BOARD_DESCRIPTION "U-Boot for phyCORE-AM62x"
> +
> +#include "k3-am625-sk-binman.dtsi"
>  
>  #ifdef CONFIG_TARGET_PHYCORE_AM62X_R5
>   {
>   tiboot3-am62x-hs-phycore-som.bin {
>   filename = "tiboot3-am62x-hs-phycore-som.bin";
> - ti-secure-rom {
> - content = <_boot_spl>, <_fs_enc>, 
> <_tifs_cfg>,
> - <_dm_cfg>, <_inner_cert>;
> - combined;
> - dm-data;
> - sysfw-inner-cert;
> - keyfile = "custMpk.pem";
> - sw-rev = <1>;
> - content-sbl = <_boot_spl>;
> - content-sysfw = <_fs_enc>;
> - content-sysfw-data = <_tifs_cfg>;
> - content-sysfw-inner-cert = <_inner_cert>;
> - content-dm-data = <_dm_cfg>;

I was looking between SoCs that we have and all this data seems common
to me on first glance, like there is only some delta in tiboot3
templates as well and maybe we can minimise those as well if am not
missing anything.

in k3-binman.dtsi:

tiboot3_combined_gp: template-x {
section {
ti-secure-rom {
content = <_boot_spl_unsigned>, <_fs_gp>,
<_tifs_cfg_gp>, <_dm_cfg_gp>;
combined;
dm-data;
content-sbl = <_boot_spl_unsigned>;
content-sysfw = <_fs_gp>;
content-sysfw-data = <_tifs_cfg_gp>;
content-dm-data = <_dm_cfg_gp>;
sw-rev = <1>;
keyfile = "ti-degenerate-key.pem";
};
u_boot_spl_unsigned: u-boot-spl {
no-expanded;
};
ti_fs_gp: ti-fs-gp.bin {
type = "blob-ext";
optional;
};
combined_tifs_cfg_gp: combined-tifs-cfg-gp.bin {
  

Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions

2024-03-25 Thread Lukasz Majewski
Hi Fabio,

> Hi Lukasz,
> 
> On Fri, Mar 22, 2024 at 8:43 AM Lukasz Majewski  wrote:
> 
> >  arch/arm/dts/Makefile |  3 +-
> >  arch/arm/dts/imx28-xea-1-u-boot.dtsi  | 11 
> >  arch/arm/dts/imx28-xea-1.dts  |  8 +++
> >  arch/arm/dts/imx28-xea-2-u-boot.dtsi  | 11 
> >  arch/arm/dts/imx28-xea-2.dts  |  8 +++
> >  arch/arm/dts/imx28-xea-u-boot.dtsi|  1 -
> >  .../arm/dts/{imx28-xea.dts => imx28-xea.dtsi} |  0  
> 
> This rename deviates from the upstream devicetree name.
> 
> Ideally, we should convert to OF_UPSTREAM available in U-Boot next.
> 
> >  board/liebherr/xea/spl_xea.c  | 21 +++---
> >  board/liebherr/xea/xea.c  | 65
> > +++ board/liebherr/xea/xea.env|
> >  4 +- configs/imx28_xea_defconfig   |  5 +-
> >  configs/imx28_xea_sb_defconfig|  5 +-
> >  12 files changed, 128 insertions(+), 14 deletions(-)
> >  create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi  
> 
> >  create mode 100644 arch/arm/dts/imx28-xea-1.dts
> >  create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/imx28-xea-2.dts
> >  rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)  
> 
> You should upstream imx28-xea-1.dts and imx28-xea-2.dts first.

The case here is that I'm modifying the *-u-boot.dts{i} files only. In
other words, u-boot will not support features described in Linux DTS.

Hence, the rename of files (which would be in sync with Linux at some
point) looks like not related to Linux DTS (as even after re-sync with
upstream Linux those changes will not be in Linux DTS).


Best regards,

Lukasz Majewski

--

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


pgpj33eMp5EwM.pgp
Description: OpenPGP digital signature


RE: [PATCH v3 00/20] FWU: Add support for FWU metadata version 2

2024-03-25 Thread kojima.masahisa
Hi Sughosh,

> -Original Message-
> From: Sughosh Ganu 
> Sent: Friday, March 22, 2024 7:57 PM
> To: u-boot@lists.denx.de
> Cc: Heinrich Schuchardt ; Ilias Apalodimas
> ; Yann GAUTIER ;
> Etienne Carriere ; Patrick DELAUNAY - foss
> ; Michal Simek ;
> Kojima, Masahisa/小島 雅久 ; Michal
> Simek 
> Subject: [PATCH v3 00/20] FWU: Add support for FWU metadata version 2
> 
> 
> 
> The following patch series adds support for version 2 of the FWU
> metadata. The version 2 metadata structure is defined in the latest
> revision of the FWU specification [1].
> 
> The earlier versions of these patches were migrating to a version 2
> only support in U-Boot, similar to TF-A. However, based on feedback
> from ST [2], this series has been updated to support both versions. A
> platform would still be needed to enable one of the two versions of
> metadata through a config symbol.
> 
> TF-A has code which reads the FWU metadata and boots the platform from
> the active partition. TF-A has decided to migrate the FWU code to a
> version 2 only support. These changes have been merged in upstream
> TF-A.
> 
> These changes have been tested on the ST DK2 board, which uses the GPT
> based partitioning scheme. Both V1 and V2 metadata versions have been
> tested on the DK2 board.
> 
> These changes need to be tested on platforms with MTD partitioned
> storage devices.
> 
> @Michal and @Kojima-san, please help in this testing.

I have tested this series on the Developerbox that implements the
MTD-based metadata access, multi bank update works fine.

Thanks,
Masahisa Kojima

> 
> Note: The CI is breaking on some sandbox py tests, but the errors look
> unrelated. I will look into those issues, but the code review can
> proceed.
> 
> [1] - https://developer.arm.com/documentation/den0118/latest/
> [2] - https://lists.denx.de/pipermail/u-boot/2024-February/546277.html
> 
> Changes since V2:
> * New patch which retains support for V1 of metadata
> * Earlier patch was catering to v2 only support. These changes support
>   both versions of metadata.
> * Earlier patch was migrating to v2 only support. These changes
>   support both versions.
> * Support both metadata versions instead of only v2.
> * Added documentation changes.
> * Make changes to have the test work with v1 metadata.
> * Make changes to have the test work with updated logic in fwu code.
> * Changes to indicate support for both v1 and v2 instead of only v2.
> * Add config symbol for selecting either of the two metadata versions.
> 
> 
> Sughosh Ganu (20):
>   configs: fwu: remove FWU configs for metadata V2 support
>   tools: mkfwumdata: fix the size parameter to the fwrite call
>   drivers: fwu: add the size parameter to the metadata access API's
>   drivers: fwu: mtd: allocate buffer for image info dynamically
>   fwu: metadata: add support for version 2 of the structure
>   fwu: metadata: add a version agnostic structure
>   fwu: metadata: add functions for handling version specific metadata
> fields
>   fwu: make changes to access version agnostic structure fields
>   capsule: fwu: transition the platform state on a successful update
>   fwu: add config symbols for enabling FWU metadata versions
>   fwu: mtd: remove unused argument from function call
>   fwu: mtd: get MTD partition specific info from driver
>   fwu: mtd: obtain image information from version agnostic structure
>   cmd: fwu: make changes for supporting FWU metadata version 2
>   tools: mkfwumdata: add support for metadata version 2
>   tools: mkfwumdata: add logic to append vendor data to the FWU metadata
>   test: fwu: make changes to the FWU metadata access test
>   doc: fwu: make changes to reflect support for FWU metadata v2
>   MAINTAINERS: add entry for FWU multi bank update feature
>   configs: fwu: re-enable FWU configs
> 
>  MAINTAINERS  |   8 +
>  cmd/fwu_mdata.c  |  39 ++--
>  configs/corstone1000_defconfig   |   1 +
>  configs/sandbox64_defconfig  |   1 +
>  configs/synquacer_developerbox_defconfig |   2 +-
>  doc/board/socionext/developerbox.rst |   7 +-
>  doc/develop/uefi/fwu_updates.rst |  20 +-
>  doc/mkfwumdata.1 |  16 +-
>  drivers/fwu-mdata/fwu-mdata-uclass.c |  10 +-
>  drivers/fwu-mdata/gpt_blk.c  |  23 +-
>  drivers/fwu-mdata/raw_mtd.c  |  78 ---
>  include/fwu.h| 147 -
>  include/fwu_mdata.h  |  71 ++-
>  lib/efi_loader/efi_capsule.c |  14 +-
>  lib/fwu_updates/Kconfig  |  14 ++
>  lib/fwu_updates/Makefile |   2 +
>  lib/fwu_updates/fwu.c| 204 --
>  lib/fwu_updates/fwu_mtd.c|  34 +--
>  lib/fwu_updates/fwu_v1.c | 167 +++
>  lib/fwu_updates/fwu_v2.c | 260
> +++
>  test/dm/fwu_mdata.c  |  16 +-
>  

[PATCH] ARM: dts: renesas: Switch to using upstream DT

2024-03-25 Thread Marek Vasut
Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the
DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from
dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/
directory.

The configuration update has been done using the following script:
```
sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas 
configs`
sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs`
```

The RZN1 Snarc board does not seem to have a matching Linux kernel
DT counterpart, this is currently not switched to OF upstream.

Signed-off-by: Marek Vasut 
---
Cc: Adam Ford 
Cc: Biju Das 
Cc: Lad Prabhakar 
Cc: Paul Barker 
Cc: Ralph Siemsen 
Cc: Sumit Garg 
Cc: Tom Rini 
---
 arch/arm/Kconfig | 1 +
 configs/alt_defconfig| 2 +-
 configs/blanche_defconfig| 2 +-
 configs/gose_defconfig   | 2 +-
 configs/grpeach_defconfig| 2 +-
 configs/koelsch_defconfig| 2 +-
 configs/lager_defconfig  | 2 +-
 configs/porter_defconfig | 2 +-
 configs/rzn1_snarc_defconfig | 1 +
 configs/silk_defconfig   | 2 +-
 configs/stout_defconfig  | 2 +-
 11 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a0842e19330..ab8f30f1142 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1068,6 +1068,7 @@ config ARCH_RENESAS
imply BOARD_EARLY_INIT_F
imply CMD_DM
imply FAT_WRITE
+   imply OF_UPSTREAM
imply SYS_THUMB_BUILD
imply ARCH_MISC_INIT if DISPLAY_CPUINFO
 
diff --git a/configs/alt_defconfig b/configs/alt_defconfig
index 06e9e11f297..c9ca22cbe8f 100644
--- a/configs/alt_defconfig
+++ b/configs/alt_defconfig
@@ -16,7 +16,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0xC
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7794-alt"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7794-alt"
 CONFIG_SPL_TEXT_BASE=0xe630
 CONFIG_ARCH_RENESAS_BOARD_STRING="Alt"
 CONFIG_R8A7794=y
diff --git a/configs/blanche_defconfig b/configs/blanche_defconfig
index c392055e5a7..a2823a614a5 100644
--- a/configs/blanche_defconfig
+++ b/configs/blanche_defconfig
@@ -12,7 +12,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0x4
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7792-blanche"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7792-blanche"
 CONFIG_ARCH_RENESAS_BOARD_STRING="Blanche"
 CONFIG_R8A7792=y
 CONFIG_TARGET_BLANCHE=y
diff --git a/configs/gose_defconfig b/configs/gose_defconfig
index 35edc677c48..0f76ae147ef 100644
--- a/configs/gose_defconfig
+++ b/configs/gose_defconfig
@@ -16,7 +16,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0xC
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7793-gose"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7793-gose"
 CONFIG_SPL_TEXT_BASE=0xe630
 CONFIG_ARCH_RENESAS_BOARD_STRING="Gose"
 CONFIG_R8A7793=y
diff --git a/configs/grpeach_defconfig b/configs/grpeach_defconfig
index 0c581b634a2..70a80088bfb 100644
--- a/configs/grpeach_defconfig
+++ b/configs/grpeach_defconfig
@@ -11,7 +11,7 @@ CONFIG_ENV_SIZE=0x1
 CONFIG_ENV_OFFSET=0x8
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r7s72100-gr-peach"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r7s72100-gr-peach"
 CONFIG_RZA1=y
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_MONITOR_LEN=524288
diff --git a/configs/koelsch_defconfig b/configs/koelsch_defconfig
index ad411b45141..a912e58cf4d 100644
--- a/configs/koelsch_defconfig
+++ b/configs/koelsch_defconfig
@@ -16,7 +16,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0xC
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7791-koelsch"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7791-koelsch"
 CONFIG_SPL_TEXT_BASE=0xe630
 CONFIG_ARCH_RENESAS_BOARD_STRING="Koelsch"
 CONFIG_R8A7791=y
diff --git a/configs/lager_defconfig b/configs/lager_defconfig
index f60d4db5ec2..03f29b8849b 100644
--- a/configs/lager_defconfig
+++ b/configs/lager_defconfig
@@ -16,7 +16,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0xC
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7790-lager"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7790-lager"
 CONFIG_SPL_TEXT_BASE=0xe630
 CONFIG_ARCH_RENESAS_BOARD_STRING="Lager"
 CONFIG_R8A7790=y
diff --git a/configs/porter_defconfig b/configs/porter_defconfig
index f05a0baf215..170ca3a5f43 100644
--- a/configs/porter_defconfig
+++ b/configs/porter_defconfig
@@ -16,7 +16,7 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0xC
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a7791-porter"
+CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a7791-porter"
 CONFIG_SPL_TEXT_BASE=0xe630
 CONFIG_ARCH_RENESAS_BOARD_STRING="Porter"
 CONFIG_R8A7791=y
diff --git a/configs/rzn1_snarc_defconfig b/configs/rzn1_snarc_defconfig
index 29a96d1aefe..1c313d2d4da 100644
--- a/configs/rzn1_snarc_defconfig
+++ 

Re: [PATCH v2] board: amlogic: fix buffler overflow in seria, mac & usid read

2024-03-25 Thread Neil Armstrong
Hi,

On Wed, 20 Mar 2024 09:46:11 +0100, Neil Armstrong wrote:
> While meson_sm_read_efuse() doesn't overflow, the string is not
> zero terminated and env_set*() will buffer overflow and add random
> characters to environment.
> 
> 

Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic 
(u-boot-amlogic)

[1/1] board: amlogic: fix buffler overflow in seria, mac & usid read
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/d54f87f09a36ac20154955297b7c999b368b0443

-- 
Neil



Re: [PATCH v2 0/2] ARM: dts: fix Ethernet and random MAC's on WeTek Hub/Play2

2024-03-25 Thread Neil Armstrong
Hi,

On Sun, 24 Mar 2024 15:19:03 +, Christian Hewitt wrote:
> In submitting the original patches for WeTek Hub/Play2 I appear to have
> squashed an experimental change to place the u-boot.dtsi file on the common
> board dtsi, but this was incorrect and results in broken Ethernet. Patch 1
> creates per-board u-boot.dtsi files to fix that. However, while the NIC is
> now probed correctly the current p200.c board file doesn't find the MAC in
> efuse and we get random MAC addresses. Patch 2 adds a fallback method for
> generating a MAC from the CPU serial.
> 
> [...]

Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic 
(u-boot-amlogic)

[1/2] ARM: dts: fix Ethernet on WeTek Hub/Play2
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/cac77418d6be11445c3e1139f6763b5f5f5fe9fb
[2/2] board: amlogic: add meson_generate_serial_ethaddr fallback to p200
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/65d5c367b00cb392bda560c3da1834979adcf137

-- 
Neil



Re: [PATCH v1 0/3] board: amlogic: jethubj100: small updates

2024-03-25 Thread Neil Armstrong
Hi,

On Tue, 27 Feb 2024 09:54:03 +0300, Viacheslav Bocharov wrote:
> Update JetHub D1/D1+ board support files.
> 
> Viacheslav Bocharov (3):
>   board: amlogic: jethubj100: fix common config header
>   board: amlogic: jethubj100: update MAINTAINERS
>   board: amlogic: jethubj100: update docs
> 
> [...]

Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic 
(u-boot-amlogic-next)

[1/3] board: amlogic: jethubj100: fix common config header
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/803fc9955164e17e8c6d1896ac2770e17c251f11
[2/3] board: amlogic: jethubj100: update MAINTAINERS
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/5e61fedf3424374a065eb23fb48963df2606bb73
[3/3] board: amlogic: jethubj100: update docs
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/2fc5e3c1668cffdb4b894986e98c1ee10f6e9955

-- 
Neil



[PULL next] u-boot-at91-2024.07-a

2024-03-25 Thread Eugen Hristev
Hello Tom,


Please pull tag u-boot-at91-2024.07-a , the first set of at91
features for the next cycle 2024.07 .

This feature set includes a new board named sama7g54 Curiosity.

Thanks,
Eugen

The following changes since commit 20a0ce574d6642e0dfe651467159039fac48cc4f:

  Merge tag 'v2024.04-rc4' into next (2024-03-11 15:27:20 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-at91.git 
tags/u-boot-at91-2024.07-a

for you to fetch changes up to a7ba3bf65db264c02a774a59e8febc2ecb095f68:

  configs: at91: sama7g54_curiosity: Add initial default configs (2024-03-13
13:35:16 +0200)


First set of u-boot-at91 features for the 2024.07 cycle


Mihai Sain (4):
  ARM: dts: at91: sama7g5: Add flexcom 10 node
  ARM: dts: at91: sama7g54_curiosity: Add initial device tree of the board
  board: at91: sama7g54_curiosity: Add initial board support
  configs: at91: sama7g54_curiosity: Add initial default configs

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/at91-sama7g54_curiosity-u-boot.dtsi   |  59 +
 arch/arm/dts/at91-sama7g54_curiosity.dts   | 242 +
 arch/arm/dts/sama7g5.dtsi  |  24 ++
 arch/arm/mach-at91/Kconfig |  10 +
 board/atmel/sama7g54_curiosity/Kconfig |  15 ++
 board/atmel/sama7g54_curiosity/MAINTAINERS |   9 +
 board/atmel/sama7g54_curiosity/Makefile|   7 +
 .../atmel/sama7g54_curiosity/sama7g54_curiosity.c  |  36 +++
 configs/sama7g54_curiosity_mmc_defconfig   | 123 +++
 configs/sama7g54_curiosity_nandflash_defconfig | 122 +++
 configs/sama7g54_curiosity_qspiflash_defconfig | 122 +++
 include/configs/sama7g54_curiosity.h   |  17 ++
 13 files changed, 789 insertions(+)
 create mode 100644 arch/arm/dts/at91-sama7g54_curiosity-u-boot.dtsi
 create mode 100644 arch/arm/dts/at91-sama7g54_curiosity.dts
 create mode 100644 board/atmel/sama7g54_curiosity/Kconfig
 create mode 100644 board/atmel/sama7g54_curiosity/MAINTAINERS
 create mode 100644 board/atmel/sama7g54_curiosity/Makefile
 create mode 100644 board/atmel/sama7g54_curiosity/sama7g54_curiosity.c
 create mode 100644 configs/sama7g54_curiosity_mmc_defconfig
 create mode 100644 configs/sama7g54_curiosity_nandflash_defconfig
 create mode 100644 configs/sama7g54_curiosity_qspiflash_defconfig
 create mode 100644 include/configs/sama7g54_curiosity.h