[PATCH 6/7] ARM: dts: rockchip: rock5b: enable pcie2x1l2 and associated combphy

2023-04-17 Thread Eugen Hristev
From: Christopher Obbard 

Enable the pciE 2x1l 2 device and associated combphy.
On this bus, the Rock5B has an Ethernet transceiver connected.

Signed-off-by: Christopher Obbard 
[eugen.hris...@collabora.com: minor tweaks]
Signed-off-by: Eugen Hristev 
---
 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 8a5b0ce42034..8293738407c4 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -31,10 +31,21 @@
};
 };
 
+_ps {
+   status = "okay";
+};
+
 _pins {
bootph-all;
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_h>;
+   reset-gpios = < RK_PB0 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+};
+
  {
bus-width = <4>;
bootph-all;
@@ -45,6 +56,12 @@
  {
bootph-all;
 
+   pcie {
+   pcie_reset_h: pcie-reset-h {
+   rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+
usb {
vcc5v0_host_en: vcc5v0-host-en {
rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO _pull_none>;
-- 
2.34.1



[PATCH 7/7] configs: rock5b-rk3588: add pci drivers and command

2023-04-17 Thread Eugen Hristev
Add drivers for pciE , phy, and command.

Signed-off-by: Eugen Hristev 
---
 configs/rock5b-rk3588_defconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 8c097ab3a109..a14fcd2ee924 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -47,6 +47,7 @@ CONFIG_SPL_ATF=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
@@ -71,7 +72,10 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PCI=y
+CONFIG_PCIE_DW_ROCKCHIP=y
 CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_REGULATOR_PWM=y
 CONFIG_DM_REGULATOR_FIXED=y
@@ -81,7 +85,6 @@ CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_ROCKCHIP_SFC=y
 CONFIG_SYSRESET=y
-# CONFIG_BINMAN_FDT is not set
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
@@ -95,4 +98,5 @@ CONFIG_USB_ETHER_LAN78XX=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+# CONFIG_BINMAN_FDT is not set
 CONFIG_ERRNO_STR=y
-- 
2.34.1



[PATCH 3/7] phy: rockchip: naneng-combphy: Add support for multiple resets

2023-04-17 Thread Eugen Hristev
Some variants of the PHY have more than just one reset.
To cover all cases, request the rests in bulk rather than just
the reset at index 0.

Co-developed-by: Ren Jianing 
Signed-off-by: Ren Jianing 
Signed-off-by: Eugen Hristev 
---
 drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c 
b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
index 78da5fe79700..b673a8da9f8e 100644
--- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
@@ -76,7 +76,7 @@ struct rockchip_combphy_priv {
struct regmap *pipe_grf;
struct regmap *phy_grf;
struct phy *phy;
-   struct reset_ctl phy_rst;
+   struct reset_ctl_bulk phy_rsts;
struct clk ref_clk;
const struct rockchip_combphy_cfg *cfg;
 };
@@ -189,7 +189,7 @@ static int rockchip_combphy_init(struct phy *phy)
if (ret)
goto err_clk;
 
-   reset_deassert(>phy_rst);
+   reset_deassert_bulk(>phy_rsts);
 
return 0;
 
@@ -204,7 +204,7 @@ static int rockchip_combphy_exit(struct phy *phy)
struct rockchip_combphy_priv *priv = dev_get_priv(phy->dev);
 
clk_disable(>ref_clk);
-   reset_assert(>phy_rst);
+   reset_assert_bulk(>phy_rsts);
 
return 0;
 }
@@ -255,7 +255,7 @@ static int rockchip_combphy_parse_dt(struct udevice *dev,
return PTR_ERR(>ref_clk);
}
 
-   ret = reset_get_by_index(dev, 0, >phy_rst);
+   ret = reset_get_bulk(dev, >phy_rsts);
if (ret) {
dev_err(dev, "no phy reset control specified\n");
return ret;
-- 
2.34.1



[PATCH 2/7] pci: pcie_dw_rockchip: Support max_link_speed dts property

2023-04-17 Thread Eugen Hristev
From: Jon Lin 

Add support for max_link_speed specified in the PCI DT binding.

Signed-off-by: Jon Lin 
[eugen.hris...@collabora.com: port to latest API, set default correctly,
align to 80 chars]
Signed-off-by: Eugen Hristev 
---
 drivers/pci/pcie_dw_rockchip.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index ff121046604a..6a2a5e15646e 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -42,6 +42,7 @@ struct rk_pcie {
struct clk_bulk clks;
struct reset_ctl_bulk   rsts;
struct gpio_descrst_gpio;
+   u32 gen;
 };
 
 /* Parameters for the waiting for iATU enabled routine */
@@ -331,7 +332,7 @@ static int rockchip_pcie_init_port(struct udevice *dev)
rk_pcie_writel_apb(priv, 0x0, 0xf00040);
pcie_dw_setup_host(>dw);
 
-   ret = rk_pcie_link_up(priv, LINK_SPEED_GEN_3);
+   ret = rk_pcie_link_up(priv, priv->gen);
if (ret < 0)
goto err_link_up;
 
@@ -351,6 +352,7 @@ err_exit_phy:
 static int rockchip_pcie_parse_dt(struct udevice *dev)
 {
struct rk_pcie *priv = dev_get_priv(dev);
+   u32 max_link_speed;
int ret;
 
priv->dw.dbi_base = (void *)dev_read_addr_index(dev, 0);
@@ -397,6 +399,13 @@ static int rockchip_pcie_parse_dt(struct udevice *dev)
goto rockchip_pcie_parse_dt_err_phy_get_by_index;
}
 
+   ret = ofnode_read_u32(dev_ofnode(dev), "max-link-speed",
+ _link_speed);
+   if (ret < 0 || max_link_speed > 4)
+   priv->gen = LINK_SPEED_GEN_3;
+   else
+   priv->gen = max_link_speed;
+
return 0;
 
 rockchip_pcie_parse_dt_err_phy_get_by_index:
-- 
2.34.1



[PATCH 1/7] pci: pcie_dw_rockchip: Add rk3588 compatible

2023-04-17 Thread Eugen Hristev
From: Jon Lin 

Add compatible for RK3588 SoC.

Signed-off-by: Jon Lin 
---
 drivers/pci/pcie_dw_rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index 6155710a9f5f..ff121046604a 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -468,6 +468,7 @@ static const struct dm_pci_ops rockchip_pcie_ops = {
 
 static const struct udevice_id rockchip_pcie_ids[] = {
{ .compatible = "rockchip,rk3568-pcie" },
+   { .compatible = "rockchip,rk3588-pcie" },
{ }
 };
 
-- 
2.34.1



Re: [PATCH v1 1/6] drivers/nvmxip: introduce NVM XIP block storage emulation

2023-04-17 Thread Abdellatif El Khlifi
On Tue, Feb 07, 2023 at 11:38:57AM -0700, Simon Glass wrote:
> Hi,
> 
> On Mon, 16 Jan 2023 at 10:28,  wrote:
> >
> > From: Abdellatif El Khlifi 
> >
> > add block storage emulation for NVM XIP flash devices
> >
> > Some paltforms such as Corstone-1000 need to see NVM XIP raw flash
> > as a block storage device with read only capability.
> 
> As mentioned I didn't see this patch originally. It generally looks OK
> but have made some comments below.
> 
> >
> > Here NVM flash devices are devices with addressable
> > memory (e.g: QSPI NOR flash).
> >
> > The implementation is generic and can be used by different platforms.
> >
> > Two drivers are provided as follows.
> >
> >   nvmxip-blk :
> >
> > a generic block driver allowing to read from the XIP flash
> >
> >   nvmxip_qspi :
> >
> > The driver probed with the DT and parent of the nvmxip-blk device.
> > nvmxip_qspi can be reused by other platforms. If the platform
> > has custom settings to apply before using the flash, then the platform
> > can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
> > nvmxip-blk. The custom driver can be implmented like nvmxip_qspi in
> > addition to the platform custom settings.
> >
> > Platforms can use multiple NVM XIP devices at the same time by defining a
> > DT node for each one of them.
> >
> > For more details please refer to doc/develop/driver-model/nvmxip.rst
> >
> > Signed-off-by: Abdellatif El Khlifi 
> > ---
> >  MAINTAINERS|   7 ++
> >  doc/develop/driver-model/index.rst |   1 +
> >  doc/develop/driver-model/nvmxip.rst|  70 +++
> >  doc/device-tree-bindings/nvmxip/nvmxip.txt |  56 +
> >  drivers/Kconfig|   2 +
> >  drivers/Makefile   |   1 +
> >  drivers/block/blk-uclass.c |   1 +
> >  drivers/nvmxip/Kconfig |  19 +++
> >  drivers/nvmxip/Makefile|   8 ++
> >  drivers/nvmxip/nvmxip-uclass.c |  15 +++
> >  drivers/nvmxip/nvmxip.c| 129 +
> >  drivers/nvmxip/nvmxip.h|  48 
> >  drivers/nvmxip/nvmxip_qspi.c   |  67 +++
> >  include/dm/uclass-id.h |   1 +
> >  14 files changed, 425 insertions(+)
> >  create mode 100644 doc/develop/driver-model/nvmxip.rst
> >  create mode 100644 doc/device-tree-bindings/nvmxip/nvmxip.txt
> >  create mode 100644 drivers/nvmxip/Kconfig
> >  create mode 100644 drivers/nvmxip/Makefile
> >  create mode 100644 drivers/nvmxip/nvmxip-uclass.c
> >  create mode 100644 drivers/nvmxip/nvmxip.c
> >  create mode 100644 drivers/nvmxip/nvmxip.h
> >  create mode 100644 drivers/nvmxip/nvmxip_qspi.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index b2de50ccfc..539d01f68c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1193,6 +1193,13 @@ F:   cmd/nvme.c
> >  F: include/nvme.h
> >  F: doc/develop/driver-model/nvme.rst
> >
> > +NVMXIP
> > +M: Abdellatif El Khlifi 
> > +S: Maintained
> > +F: doc/develop/driver-model/nvmxip.rst
> > +F: doc/device-tree-bindings/nvmxip/nvmxip.txt
> > +F: drivers/nvmxip/
> > +
> >  NVMEM
> >  M: Sean Anderson 
> >  S: Maintained
> > diff --git a/doc/develop/driver-model/index.rst 
> > b/doc/develop/driver-model/index.rst
> > index 7366ef818c..8e12bbd936 100644
> > --- a/doc/develop/driver-model/index.rst
> > +++ b/doc/develop/driver-model/index.rst
> > @@ -20,6 +20,7 @@ subsystems
> > livetree
> > migration
> > nvme
> > +   nvmxip
> > of-plat
> > pci-info
> > pmic-framework
> > diff --git a/doc/develop/driver-model/nvmxip.rst 
> > b/doc/develop/driver-model/nvmxip.rst
> > new file mode 100644
> > index 00..91b24e4e50
> > --- /dev/null
> > +++ b/doc/develop/driver-model/nvmxip.rst
> > @@ -0,0 +1,70 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +
> > +NVM XIP Block Storage Emulation Driver
> > +===
> > +
> > +Summary
> > +---
> > +
> > +Non-Volatile Memory devices with addressable memory (e.g: QSPI NOR flash) 
> > could
> > +be used for block storage needs (e.g: parsing a GPT layout in a raw QSPI 
> > NOR flash).
> > +
> > +The NVMXIP class provides this functionality and can be used for any 
> > 64-bit platform.
> > +
> > +The NVMXIP class provides the following drivers:
> > +
> > +  nvmxip-blk :
> > +
> > +A generic block driver allowing to read from the XIP flash.
> > +   The driver belongs to UCLASS_BLK.
> > +   The driver implemented by drivers/nvmxip/nvmxip.c
> > +
> > +  nvmxip_qspi :
> > +
> > +The driver probed with the DT and parent of the nvmxip-blk device.
> > +nvmxip_qspi can be reused by other platforms. If the platform
> > +has custom settings to apply before using the flash, then the 
> > platform
> > +can provide its own parent driver belonging to 

[PATCH v2 7/7] sandbox64: add a test case for UCLASS_NVMXIP

2023-04-17 Thread Abdellatif El Khlifi
provide a test for NVM XIP devices

The test case allows to make sure of the following:

- The NVM XIP QSPI devices are probed
- The DT entries are read correctly
- the data read from the flash by the NVMXIP block driver is correct

Signed-off-by: Abdellatif El Khlifi 

---

Changelog:
===

v2:

* address nits

 MAINTAINERS  |   1 +
 test/dm/Makefile |   5 ++
 test/dm/nvmxip.c | 145 +++
 3 files changed, 151 insertions(+)
 create mode 100644 test/dm/nvmxip.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 77acce79c5..25beb8c48b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1208,6 +1208,7 @@ S:Maintained
 F: doc/develop/driver-model/nvmxip.rst
 F: doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
 F: drivers/mtd/nvmxip/
+F: test/dm/nvmxip.c
 
 NVMEM
 M: Sean Anderson 
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7a79b6e1a2..7f9d0b3c38 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 # Copyright (c) 2013 Google, Inc
+# Copyright 2023 Arm Limited and/or its affiliates 
 
 obj-$(CONFIG_UT_DM) += test-dm.o
 
@@ -17,6 +18,10 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
 obj-$(CONFIG_UT_DM) += core.o
 obj-$(CONFIG_UT_DM) += read.o
 obj-$(CONFIG_UT_DM) += phys2bus.o
+ifeq ($(CONFIG_NVMXIP_QSPI)$(CONFIG_SANDBOX64),yy)
+obj-y += nvmxip.o
+endif
+
 ifneq ($(CONFIG_SANDBOX),)
 ifeq ($(CONFIG_ACPIGEN),y)
 obj-y += acpi.o
diff --git a/test/dm/nvmxip.c b/test/dm/nvmxip.c
new file mode 100644
index 00..e934748eb5
--- /dev/null
+++ b/test/dm/nvmxip.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA  class
+ *
+ * Copyright 2023 Arm Limited and/or its affiliates 

+ *
+ * Authors:
+ *   Abdellatif El Khlifi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../../drivers/mtd/nvmxip/nvmxip.h"
+
+/* NVMXIP devices described in the device tree */
+#define SANDBOX_NVMXIP_DEVICES 2
+
+/* reference device tree data for the probed devices */
+static struct nvmxip_plat nvmqspi_refdata[SANDBOX_NVMXIP_DEVICES] = {
+   {0x0800, 9, 4096}, {0x0820, 9, 2048}
+};
+
+#define NVMXIP_BLK_START_PATTERN 0x1122334455667788ULL
+#define NVMXIP_BLK_END_PATTERN 0xa1a2a3a4a5a6a7a8ULL
+
+/**
+ * dm_nvmxip_flash_sanity() - check flash data
+ * @uts: test state
+ * @device_idx:the NVMXIP device index
+ * @buffer:the user buffer where the blocks data is copied to
+ *
+ * Mode 1: When buffer is NULL, initialize the flash with pattern data at the 
start
+ * and at the end of each block. This pattern data will be used to check data 
consistency
+ * when verifying the data read.
+ * Mode 2: When the user buffer is provided in the argument (not NULL), 
compare the data
+ * of the start and the end of each block in the user buffer with the expected 
pattern data.
+ * Return an error when the check fails.
+ *
+ * Return:
+ *
+ * 0 on success. Otherwise, failure
+ */
+static int dm_nvmxip_flash_sanity(struct unit_test_state *uts, u8 device_idx, 
void *buffer)
+{
+   int i;
+   u64 *ptr;
+   u8 *base;
+   unsigned long blksz;
+
+   blksz = BIT(nvmqspi_refdata[device_idx].lba_shift);
+
+   if (!buffer) {
+   /* Mode 1: point at the flash start address. Pattern data will 
be written */
+   base = map_sysmem(nvmqspi_refdata[device_idx].phys_base, 0);
+   } else {
+   /* Mode 2: point at the user buffer containing the data read 
and to be verified */
+   base = buffer;
+   }
+
+   for (i = 0; i < nvmqspi_refdata[device_idx].lba ; i++) {
+   ptr = (u64 *)(base + i * blksz);
+
+   /* write an 8 bytes pattern at the start of the current block */
+   if (!buffer)
+   *ptr = NVMXIP_BLK_START_PATTERN;
+   else
+   ut_asserteq_64(NVMXIP_BLK_START_PATTERN, *ptr);
+
+   ptr = (u64 *)((u8 *)ptr + blksz - sizeof(u64));
+
+   /* write an 8 bytes pattern at the end of the current block */
+   if (!buffer)
+   *ptr = NVMXIP_BLK_END_PATTERN;
+   else
+   ut_asserteq_64(NVMXIP_BLK_END_PATTERN, *ptr);
+   }
+
+   if (!buffer)
+   unmap_sysmem(base);
+
+   return 0;
+}
+
+/**
+ * dm_test_nvmxip() - check flash data
+ * @uts: test state
+ * Return:
+ *
+ * CMD_RET_SUCCESS on success. Otherwise, failure
+ */
+static int dm_test_nvmxip(struct unit_test_state *uts)
+{
+   struct nvmxip_plat *plat_data = NULL;
+   struct udevice *dev = NULL, *bdev = NULL;
+   u8 device_idx;
+   void *buffer = NULL;
+   unsigned long flashsz;
+
+   /* set the flash content first for both devices */
+   dm_nvmxip_flash_sanity(uts, 0, NULL);
+   dm_nvmxip_flash_sanity(uts, 1, NULL);
+
+   /* probing 

[PATCH v2 6/7] corstone1000: enable NVM XIP QSPI flash

2023-04-17 Thread Abdellatif El Khlifi
add the QSPI flash device with block storage capability

Signed-off-by: Abdellatif El Khlifi 
---
 configs/corstone1000_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig
index 383317fefe..35f763596a 100644
--- a/configs/corstone1000_defconfig
+++ b/configs/corstone1000_defconfig
@@ -52,3 +52,4 @@ CONFIG_DM_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_ISP1760=y
 CONFIG_ERRNO_STR=y
+CONFIG_NVMXIP_QSPI=y
-- 
2.25.1



[PATCH v2 5/7] corstone1000: add NVM XIP QSPI device tree node

2023-04-17 Thread Abdellatif El Khlifi
add QSPI flash device node for block storage access

Signed-off-by: Abdellatif El Khlifi 
---
 arch/arm/dts/corstone1000.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/corstone1000.dtsi b/arch/arm/dts/corstone1000.dtsi
index 4e46826f88..533dfdf8e1 100644
--- a/arch/arm/dts/corstone1000.dtsi
+++ b/arch/arm/dts/corstone1000.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0 or MIT
 /*
- * Copyright (c) 2022, Arm Limited. All rights reserved.
+ * Copyright 2022-2023 Arm Limited and/or its affiliates 

  * Copyright (c) 2022, Linaro Limited. All rights reserved.
  *
  */
@@ -38,6 +38,13 @@
reg = <0x8820 0x77e0>;
};
 
+   nvmxip-qspi@0800 {
+   compatible = "nvmxip,qspi";
+   reg = <0x0800 0x200>;
+   lba_shift = <9>;
+   lba = <65536>;
+   };
+
gic: interrupt-controller@1c00 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
2.25.1



[PATCH v2 4/7] sandbox64: add support for NVMXIP QSPI

2023-04-17 Thread Abdellatif El Khlifi
enable NVMXIP QSPI for sandbox 64-bit

Adding two NVM XIP QSPI storage devices.

Signed-off-by: Abdellatif El Khlifi 
Reviewed-by: Simon Glass 

---

Changelog:
===

v2:

* address nits

 arch/sandbox/dts/sandbox64.dts  | 13 +
 arch/sandbox/dts/test.dts   | 14 ++
 configs/sandbox64_defconfig |  1 +
 doc/develop/driver-model/nvmxip.rst |  2 +-
 doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt |  6 +++---
 drivers/mtd/nvmxip/nvmxip-uclass.c  |  7 +++
 6 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index f21fc181f3..195365580a 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -89,6 +89,19 @@
cs-gpios = <0>, <_a 0>;
};
 
+   nvmxip-qspi1@0800 {
+   compatible = "nvmxip,qspi";
+   reg = /bits/ 64 <0x0800 0x0020>;
+   lba_shift = <9>;
+   lba = <4096>;
+   };
+
+   nvmxip-qspi2@0820 {
+   compatible = "nvmxip,qspi";
+   reg = /bits/ 64 <0x0820 0x0010>;
+   lba_shift = <9>;
+   lba = <2048>;
+   };
 };
 
 #include "sandbox.dtsi"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index d72d7a567a..da08012834 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1802,6 +1802,20 @@
compatible = "u-boot,fwu-mdata-gpt";
fwu-mdata-store = <>;
};
+
+   nvmxip-qspi1@0800 {
+   compatible = "nvmxip,qspi";
+   reg = <0x0800 0x0020>;
+   lba_shift = <9>;
+   lba = <4096>;
+   };
+
+   nvmxip-qspi2@0820 {
+   compatible = "nvmxip,qspi";
+   reg = <0x0820 0x0010>;
+   lba_shift = <9>;
+   lba = <2048>;
+   };
 };
 
 #include "sandbox_pmic.dtsi"
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index af2c56ad4c..bb877b6a58 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -260,3 +260,4 @@ CONFIG_FWU_MULTI_BANK_UPDATE=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
+CONFIG_NVMXIP_QSPI=y
diff --git a/doc/develop/driver-model/nvmxip.rst 
b/doc/develop/driver-model/nvmxip.rst
index 09afdbcccf..e85dc220b9 100644
--- a/doc/develop/driver-model/nvmxip.rst
+++ b/doc/develop/driver-model/nvmxip.rst
@@ -56,7 +56,7 @@ The implementation is generic and can be used by different 
platforms.
 Supported hardware
 
 
-Any 64-bit plaform.
+Any plaform supporting readq().
 
 Configuration
 --
diff --git a/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt 
b/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
index cc60e9efdc..882728d541 100644
--- a/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
+++ b/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
@@ -16,7 +16,7 @@ If a platform has its own driver, please provide your own 
compatible
 string.
 
 2)
-   reg = <0x0 0x0800 0x0 0x0020>;
+   reg = /bits/ 64 <0x0800 0x0020>;
 
 The start address and size of the flash device. The values give here are an
 example (when the cell size is 2).
@@ -43,14 +43,14 @@ Example of multiple flash devices
 
nvmxip-qspi1@0800 {
compatible = "nvmxip,qspi";
-   reg = <0x0 0x0800 0x0 0x0020>;
+   reg = /bits/ 64 <0x0800 0x0020>;
lba_shift = <9>;
lba = <4096>;
};
 
nvmxip-qspi2@0820 {
compatible = "nvmxip,qspi";
-   reg = <0x0 0x0820 0x0 0x0010>;
+   reg = /bits/ 64 <0x0820 0x0010>;
lba_shift = <9>;
lba = <2048>;
};
diff --git a/drivers/mtd/nvmxip/nvmxip-uclass.c 
b/drivers/mtd/nvmxip/nvmxip-uclass.c
index 9f96041e3d..6d8eb177b5 100644
--- a/drivers/mtd/nvmxip/nvmxip-uclass.c
+++ b/drivers/mtd/nvmxip/nvmxip-uclass.c
@@ -9,6 +9,9 @@
 #include 
 #include 
 #include 
+#if CONFIG_IS_ENABLED(SANDBOX64)
+#include 
+#endif
 #include 
 #include "nvmxip.h"
 
@@ -36,6 +39,10 @@ static int nvmxip_post_bind(struct udevice *udev)
char bdev_name[NVMXIP_BLKDEV_NAME_SZ + 1];
int devnum;
 
+#if CONFIG_IS_ENABLED(SANDBOX64)
+   sandbox_set_enable_memio(true);
+#endif
+
devnum = uclass_id_count(UCLASS_NVMXIP);
snprintf(bdev_name, NVMXIP_BLKDEV_NAME_SZ, "blk#%d", devnum);
 
-- 
2.25.1



[PATCH v2 3/7] sandbox64: fix: return unsigned long in readq()

2023-04-17 Thread Abdellatif El Khlifi
make readq return unsigned long

readq should return 64-bit data

Signed-off-by: Abdellatif El Khlifi 
---
 arch/sandbox/cpu/cpu.c| 2 +-
 arch/sandbox/include/asm/io.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 636d3545b9..248d17a85c 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -230,7 +230,7 @@ phys_addr_t map_to_sysmem(const void *ptr)
return mentry->tag;
 }
 
-unsigned int sandbox_read(const void *addr, enum sandboxio_size_t size)
+unsigned long sandbox_read(const void *addr, enum sandboxio_size_t size)
 {
struct sandbox_state *state = state_get_current();
 
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index ad6c29a4e2..31ab7289b4 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -45,7 +45,7 @@ static inline void unmap_sysmem(const void *vaddr)
 /* Map from a pointer to our RAM buffer */
 phys_addr_t map_to_sysmem(const void *ptr);
 
-unsigned int sandbox_read(const void *addr, enum sandboxio_size_t size);
+unsigned long sandbox_read(const void *addr, enum sandboxio_size_t size);
 void sandbox_write(void *addr, unsigned int val, enum sandboxio_size_t size);
 
 #define readb(addr) sandbox_read((const void *)addr, SB_SIZE_8)
-- 
2.25.1



[PATCH v2 2/7] drivers/mtd/nvmxip: introduce QSPI XIP driver

2023-04-17 Thread Abdellatif El Khlifi
add nvmxip_qspi driver under UCLASS_NVMXIP

The device associated with this driver is the parent of the blk# device
nvmxip_qspi can be reused by other platforms. If the platform
has custom settings to apply before using the flash, then the platform
can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in
addition to the platform custom settings.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst

Signed-off-by: Abdellatif El Khlifi 
---
 MAINTAINERS   |  1 +
 doc/develop/driver-model/nvmxip.rst   | 45 +++-
 .../nvmxip/nvmxip_qspi.txt| 56 +++
 drivers/mtd/nvmxip/Kconfig|  6 ++
 drivers/mtd/nvmxip/Makefile   |  1 +
 drivers/mtd/nvmxip/nvmxip_qspi.c  | 70 +++
 6 files changed, 178 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
 create mode 100644 drivers/mtd/nvmxip/nvmxip_qspi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 39f143e60b..77acce79c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1206,6 +1206,7 @@ NVMXIP
 M: Abdellatif El Khlifi 
 S: Maintained
 F: doc/develop/driver-model/nvmxip.rst
+F: doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
 F: drivers/mtd/nvmxip/
 
 NVMEM
diff --git a/doc/develop/driver-model/nvmxip.rst 
b/doc/develop/driver-model/nvmxip.rst
index fe087b13d2..09afdbcccf 100644
--- a/doc/develop/driver-model/nvmxip.rst
+++ b/doc/develop/driver-model/nvmxip.rst
@@ -25,7 +25,33 @@ The NVMXIP Uclass provides the following drivers:
 the Uclass creates a block device and binds it with the nvmxip-blk.
The Uclass driver implemented by drivers/mtd/nvmxip/nvmxip-uclass.c
 
-The implementation is generic and can be used by different platforms.
+  nvmxip_qspi driver :
+
+The driver probed with the DT and is the parent of the blk# device.
+nvmxip_qspi can be reused by other platforms. If the platform
+has custom settings to apply before using the flash, then the platform
+can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
+nvmxip-blk. The custom driver can be implemented like nvmxip_qspi in
+addition to the platform custom settings.
+   The nvmxip_qspi driver belongs to UCLASS_NVMXIP.
+   The driver implemented by drivers/mtd/nvmxip/nvmxip_qspi.c
+
+   For example, if we have two NVMXIP devices described in the DT
+   The devices hierarchy is as follows:
+
+::
+
+   => dm tree
+
+Class Index  Probed  DriverName
+---
+...
+ nvmxip0  [ + ]   nvmxip_qspi   |-- nvmxip-qspi1@0800
+ blk   3  [ + ]   nvmxip-blk|   `-- 
nvmxip-qs...@0800.blk#1
+ nvmxip1  [ + ]   nvmxip_qspi   |-- nvmxip-qspi2@0820
+ blk   4  [ + ]   nvmxip-blk|   `-- 
nvmxip-qs...@0820.blk#2
+
+The implementation is generic and can be used by different platforms.
 
 Supported hardware
 
@@ -43,6 +69,23 @@ config NVMXIP
  handles the read operation. This driver is HW agnostic and can support
  multiple flash devices at the same time.
 
+config NVMXIP_QSPI
+ This option allows the emulation of a block storage device on top of 
a QSPI XIP flash.
+ Any platform that needs to emulate one or multiple QSPI XIP flash 
devices can turn this
+ option on to enable the functionality. NVMXIP config is selected 
automatically.
+ Platforms that need to add custom treatments before accessing to the 
flash, can
+ write their own driver (same as nvmxip_qspi in addition to the custom 
settings).
+
+Device Tree nodes
+
+
+Multiple QSPI XIP flash devices can be used at the same time by describing 
them through DT
+nodes.
+
+Please refer to the documentation of the DT binding at:
+
+doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
+
 Contributors
 
* Abdellatif El Khlifi 
diff --git a/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt 
b/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
new file mode 100644
index 00..cc60e9efdc
--- /dev/null
+++ b/doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
@@ -0,0 +1,56 @@
+Specifying NVMXIP information for devices
+==
+
+QSPI XIP flash device nodes
+---
+
+Each flash device should have its own node.
+
+Each node must specify the following fields:
+
+1)
+   compatible = "nvmxip,qspi";
+
+This allows to bind the flash device with the nvmxip_qspi driver
+If a platform has its own driver, 

[PATCH v2 1/7] drivers/mtd/nvmxip: introduce NVM XIP block storage emulation

2023-04-17 Thread Abdellatif El Khlifi
add block storage emulation for NVM XIP flash devices

Some paltforms such as Corstone-1000 need to see NVM XIP raw flash
as a block storage device with read only capability.

Here NVM flash devices are devices with addressable
memory (e.g: QSPI NOR flash).

The implementation is generic and can be used by different platforms.

Two drivers are provided as follows.

  nvmxip-blk :

a generic block driver allowing to read from the XIP flash

  nvmxip Uclass driver :

When a device is described in the DT and associated with
UCLASS_NVMXIP, the Uclass creates a block device and binds it with
 the nvmxip-blk.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

Signed-off-by: Abdellatif El Khlifi 

---

Changelog:
===

v2:

* move the drivers under drivers/mtd
* shorten the block device name
* rename nvmxip_init() to nvmxip_post_bind(), call it from the uclass when
   a new device is bound
* use uclass_id_count() in place of nvmxip_bdev_max_devs
* moving the NVMXIP QSPI driver to a seperate commit
* address nits

 MAINTAINERS |   6 ++
 doc/develop/driver-model/index.rst  |   1 +
 doc/develop/driver-model/nvmxip.rst |  48 +++
 drivers/block/blk-uclass.c  |   1 +
 drivers/mtd/Kconfig |   2 +
 drivers/mtd/Makefile|   1 +
 drivers/mtd/nvmxip/Kconfig  |  13 +++
 drivers/mtd/nvmxip/Makefile |   7 ++
 drivers/mtd/nvmxip/nvmxip-uclass.c  |  67 
 drivers/mtd/nvmxip/nvmxip.c | 119 
 drivers/mtd/nvmxip/nvmxip.h |  32 
 include/dm/uclass-id.h  |   1 +
 12 files changed, 298 insertions(+)
 create mode 100644 doc/develop/driver-model/nvmxip.rst
 create mode 100644 drivers/mtd/nvmxip/Kconfig
 create mode 100644 drivers/mtd/nvmxip/Makefile
 create mode 100644 drivers/mtd/nvmxip/nvmxip-uclass.c
 create mode 100644 drivers/mtd/nvmxip/nvmxip.c
 create mode 100644 drivers/mtd/nvmxip/nvmxip.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d2e245e5e9..39f143e60b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1202,6 +1202,12 @@ F:   cmd/nvme.c
 F: include/nvme.h
 F: doc/develop/driver-model/nvme.rst
 
+NVMXIP
+M: Abdellatif El Khlifi 
+S: Maintained
+F: doc/develop/driver-model/nvmxip.rst
+F: drivers/mtd/nvmxip/
+
 NVMEM
 M: Sean Anderson 
 S: Maintained
diff --git a/doc/develop/driver-model/index.rst 
b/doc/develop/driver-model/index.rst
index 7366ef818c..8e12bbd936 100644
--- a/doc/develop/driver-model/index.rst
+++ b/doc/develop/driver-model/index.rst
@@ -20,6 +20,7 @@ subsystems
livetree
migration
nvme
+   nvmxip
of-plat
pci-info
pmic-framework
diff --git a/doc/develop/driver-model/nvmxip.rst 
b/doc/develop/driver-model/nvmxip.rst
new file mode 100644
index 00..fe087b13d2
--- /dev/null
+++ b/doc/develop/driver-model/nvmxip.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+NVM XIP Block Storage Emulation Driver
+===
+
+Summary
+---
+
+Non-Volatile Memory devices with addressable memory (e.g: QSPI NOR flash) could
+be used for block storage needs (e.g: parsing a GPT layout in a raw QSPI NOR 
flash).
+
+The NVMXIP Uclass provides this functionality and can be used for any 64-bit 
platform.
+
+The NVMXIP Uclass provides the following drivers:
+
+  nvmxip-blk block driver:
+
+A generic block driver allowing to read from the XIP flash.
+   The driver belongs to UCLASS_BLK.
+   The driver implemented by drivers/mtd/nvmxip/nvmxip.c
+
+  nvmxip Uclass driver:
+
+When a device is described in the DT and associated with UCLASS_NVMXIP,
+the Uclass creates a block device and binds it with the nvmxip-blk.
+   The Uclass driver implemented by drivers/mtd/nvmxip/nvmxip-uclass.c
+
+The implementation is generic and can be used by different platforms.
+
+Supported hardware
+
+
+Any 64-bit plaform.
+
+Configuration
+--
+
+config NVMXIP
+ This option allows the emulation of a block storage device
+ on top of a direct access non volatile memory XIP flash devices.
+ This support provides the read operation.
+ This option provides the block storage driver nvmxip-blk which
+ handles the read operation. This driver is HW agnostic and can support
+ multiple flash devices at the same time.
+
+Contributors
+
+   * Abdellatif El Khlifi 
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index c69fc4d518..e8ab576c32 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -28,6 +28,7 @@ static struct {
{ UCLASS_AHCI, "sata" },
{ UCLASS_HOST, "host" },
{ UCLASS_NVME, "nvme" },
+   { UCLASS_NVMXIP, "nvmxip" },
{ UCLASS_EFI_MEDIA, "efi" },
{ 

[PATCH v2 0/7] introduce NVM XIP block storage emulation

2023-04-17 Thread Abdellatif El Khlifi
Adding block storage emulation for NVM XIP flash devices.

Some paltforms such as Corstone-1000 need to see NVM XIP raw flash
as a block storage device with read only capability.

Here NVM flash devices are devices with addressable
memory (e.g: QSPI NOR flash).

The NVM XIP block storage emulation provides the following features:

- Emulate NVM XIP raw flash as a block storage device with read only capability
- Being generic by design and can be used by any platform
- Device tree node
- Platforms can use multiple NVM XIP devices at the same time by defining a
  DT node for each one of them
- A generic NVMXIP block driver allowing to read from the XIP flash
- A generic NVMXIP Uclass driver for binding the block device
- A generic NVMXIP QSPI driver
- Implemented on top of memory-mapped IO (using readq macro)
- Enabling NVMXIP in sandbox64
- A sandbox test case
- Enabling NVMXIP in Corstone1000 platform as a use case

For more details please refer to the readme [A].

Changelog of the major changes:
===

v2:

* move the drivers under drivers/mtd
* shorten the block device name
* rename nvmxip_init() to nvmxip_post_bind(), call it from the uclass when
   a new device is bound
* use uclass_id_count() in place of nvmxip_bdev_max_devs
* moving the NVMXIP QSPI driver to a seperate commit
* address nits

v1: [1]

* introduce the new feature

Cheers,
Abdellatif

List of previous patches:

[1]: 
https://lore.kernel.org/all/20230116172832.1946-1-abdellatif.elkhl...@arm.com/

More details:

[A]: doc/develop/driver-model/nvmxip.rst

Cc: Tom Rini 
Cc: Simon Glass 
Cc: Drew Reed 
Cc: Xueliang Zhong 
Cc: Rui Miguel Silva 

Abdellatif El Khlifi (7):
  drivers/mtd/nvmxip: introduce NVM XIP block storage emulation
  drivers/mtd/nvmxip: introduce QSPI XIP driver
  sandbox64: fix: return unsigned long in readq()
  sandbox64: add support for NVMXIP QSPI
  corstone1000: add NVM XIP QSPI device tree node
  corstone1000: enable NVM XIP QSPI flash
  sandbox64: add a test case for UCLASS_NVMXIP

 MAINTAINERS   |   8 +
 arch/arm/dts/corstone1000.dtsi|   9 +-
 arch/sandbox/cpu/cpu.c|   2 +-
 arch/sandbox/dts/sandbox64.dts|  13 ++
 arch/sandbox/dts/test.dts |  14 ++
 arch/sandbox/include/asm/io.h |   2 +-
 configs/corstone1000_defconfig|   1 +
 configs/sandbox64_defconfig   |   1 +
 doc/develop/driver-model/index.rst|   1 +
 doc/develop/driver-model/nvmxip.rst   |  91 +++
 .../nvmxip/nvmxip_qspi.txt|  56 +++
 drivers/block/blk-uclass.c|   1 +
 drivers/mtd/Kconfig   |   2 +
 drivers/mtd/Makefile  |   1 +
 drivers/mtd/nvmxip/Kconfig|  19 +++
 drivers/mtd/nvmxip/Makefile   |   8 +
 drivers/mtd/nvmxip/nvmxip-uclass.c|  74 +
 drivers/mtd/nvmxip/nvmxip.c   | 119 ++
 drivers/mtd/nvmxip/nvmxip.h   |  32 
 drivers/mtd/nvmxip/nvmxip_qspi.c  |  70 +
 include/dm/uclass-id.h|   1 +
 test/dm/Makefile  |   5 +
 test/dm/nvmxip.c  | 145 ++
 23 files changed, 672 insertions(+), 3 deletions(-)
 create mode 100644 doc/develop/driver-model/nvmxip.rst
 create mode 100644 doc/device-tree-bindings/nvmxip/nvmxip_qspi.txt
 create mode 100644 drivers/mtd/nvmxip/Kconfig
 create mode 100644 drivers/mtd/nvmxip/Makefile
 create mode 100644 drivers/mtd/nvmxip/nvmxip-uclass.c
 create mode 100644 drivers/mtd/nvmxip/nvmxip.c
 create mode 100644 drivers/mtd/nvmxip/nvmxip.h
 create mode 100644 drivers/mtd/nvmxip/nvmxip_qspi.c
 create mode 100644 test/dm/nvmxip.c

-- 
2.25.1



Re: [PATCH 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices

2023-04-17 Thread Neha Malcom Francis

Hi Krzysztof

On 14/04/23 17:10, Krzysztof Kozlowski wrote:

On 14/04/2023 12:52, Neha Malcom Francis wrote:

Document the binding for TI K3 ESM (Error Signaling Module) block.

Signed-off-by: Neha Malcom Francis 
---
  .../devicetree/bindings/misc/esm-k3.yaml  | 54 +++
  1 file changed, 54 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml

diff --git a/Documentation/devicetree/bindings/misc/esm-k3.yaml 
b/Documentation/devicetree/bindings/misc/esm-k3.yaml
new file mode 100644
index ..5e637add3b0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/esm-k3.yaml


Filename matching compatible. Missing vendor prefix and device name.


@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/esm-k3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM Binding


Drop: Binding


+
+maintainers:
+  - Neha Malcom Francis 
+
+description: |
+  The ESM (Error Signaling Module) is an IP block on TI K3 devices
+  that allows handling of safety events somewhat similar to what interrupt
+  controller would do. The safety signals have their separate paths within
+  the SoC, and they are handld by the ESM, which routes them to the proper


typo: handled


+  destination, which can be system reset, interrupt controller, etc. In the
+  simplest configuration the signals are just routed to reset the SoC.


There is no proper bindings directory for ESM? Misc is discouraged.



There is no other directory I see fit for a block like ESM; it could 
either remain in misc/ or maybe create a directory error/ for all error 
signaling and correction mechanisms? I see misc/xlnx,sd-fec.txt that 
could also go in error/


What do you think is fit?


+
+properties:
+  compatible:
+const: ti,j721e-esm
+
+  reg:
+items:
+  - description: physical address and length of the registers which
+  contain revision and debug features


Drop useless "physical address and length of the registers which". reg
cannot be anything else.


+  - description: physical address and length of the registers which
+  indicate strapping options
+
+  ti,esm-pins:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |


Do not need '|' unless you need to preserve formatting.


+  integer array of ESM event IDs to route to external event pin which can
+  be used to reset the SoC. The array can have an arbitrary amount of event
+  IDs listed on it.


What is ESM event ID? The property name suggests pins...



+minItems: 1
+maxItems: 255
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - ti,esm-pins
+
+examples:
+  - |
+main_esm: esm@70 {


Drop label.



Thanks for the reviews! I'll send v2 after we decide on the location.


+compatible = "ti,j721e-esm";
+reg = <0x0 0x70 0x0 0x1000>;
+ti,esm-pins = <344>, <345>;
+};


Best regards,
Krzysztof



--
Thanking You
Neha Malcom Francis


Re: [PATCH] nand: raw: octeontx: Make list static

2023-04-17 Thread Dario Binacchi
Hi Bin,

On Wed, Apr 5, 2023 at 8:42 PM Michael Nazzareno Trimarchi
 wrote:
>
> Hi
>
> On Wed, Apr 5, 2023 at 4:38 PM Bin Meng  wrote:
> >
> > octeontx_bch_devices and octeontx_pci_nand_deferred_devices are only
> > referenced in the files where they are defined. Make them static.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  drivers/mtd/nand/raw/octeontx_bch.c  | 2 +-
> >  drivers/mtd/nand/raw/octeontx_nand.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/octeontx_bch.c 
> > b/drivers/mtd/nand/raw/octeontx_bch.c
> > index fc16b77416..056a685782 100644
> > --- a/drivers/mtd/nand/raw/octeontx_bch.c
> > +++ b/drivers/mtd/nand/raw/octeontx_bch.c
> > @@ -27,7 +27,7 @@
> >  #include 
> >  #include "octeontx_bch.h"
> >
> > -LIST_HEAD(octeontx_bch_devices);
> > +static LIST_HEAD(octeontx_bch_devices);
> >  static unsigned int num_vfs = BCH_NR_VF;
> >  static void *bch_pf;
> >  static void *bch_vf;
> > diff --git a/drivers/mtd/nand/raw/octeontx_nand.c 
> > b/drivers/mtd/nand/raw/octeontx_nand.c
> > index 1ffadad9ca..65a03d22c1 100644
> > --- a/drivers/mtd/nand/raw/octeontx_nand.c
> > +++ b/drivers/mtd/nand/raw/octeontx_nand.c
> > @@ -354,7 +354,7 @@ struct octeontx_probe_device {
> >
> >  static struct bch_vf *bch_vf;
> >  /** Deferred devices due to BCH not being ready */
> > -LIST_HEAD(octeontx_pci_nand_deferred_devices);
> > +static LIST_HEAD(octeontx_pci_nand_deferred_devices);
> >
> >  /** default parameters used for probing chips */
> >  #define MAX_ONFI_MODE  5
> > --
>
> Acked-by: Michael Trimarchi 
>
> Michael
>
> > 2.34.1
> >
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com


Applied to nand-next,

Thanks and regards
Dario
-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com


Re: [PATCH v2] nand: brcmnand: add iproc support

2023-04-17 Thread Dario Binacchi
Hi Linus,

On Sat, Mar 11, 2023 at 2:03 AM William Zhang
 wrote:
>
>
>
> On 03/08/2023 01:42 PM, Linus Walleij wrote:
> > Add support for the iproc Broadcom NAND controller,
> > used in Northstar SoCs for example. Based on the Linux
> > driver.
> >
> > Cc: Philippe Reynes 
> > Cc: Dario Binacchi 
> > Reviewed-by: Michael Trimarchi 
> > Signed-off-by: Linus Walleij 
> > ---
> > ChangeLog v1->v2:
> > - Check return value of dev_read_resource()
> > - Use devm_ioremap()
> > - Collect Michael's Review tag
> > ---
> >   drivers/mtd/nand/raw/Kconfig   |   7 +
> >   drivers/mtd/nand/raw/brcmnand/Makefile |   1 +
> >   drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 148 +
> >   3 files changed, 156 insertions(+)
> >   create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> >
> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > index 5b35da45f584..6a13bc1e228a 100644
> > --- a/drivers/mtd/nand/raw/Kconfig
> > +++ b/drivers/mtd/nand/raw/Kconfig
> > @@ -156,6 +156,13 @@ config NAND_BRCMNAND_63158
> >  help
> >Enable support for broadcom nand driver on bcm63158.
> >
> > +config NAND_BRCMNAND_IPROC
> > +   bool "Support Broadcom NAND controller on the iproc family"
> > +   depends on NAND_BRCMNAND
> > +   help
> > + Enable support for broadcom nand driver on the Broadcom
> > + iproc family such as Northstar (BCM5301x, BCM4708...)
> > +
> >   config NAND_DAVINCI
> >   bool "Support TI Davinci NAND controller"
> >   select SYS_NAND_SELF_INIT if TARGET_DA850EVM
> > diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile 
> > b/drivers/mtd/nand/raw/brcmnand/Makefile
> > index f46a7edae321..0c6325aaa618 100644
> > --- a/drivers/mtd/nand/raw/brcmnand/Makefile
> > +++ b/drivers/mtd/nand/raw/brcmnand/Makefile
> > @@ -6,5 +6,6 @@ obj-$(CONFIG_NAND_BRCMNAND_6753) += bcm6753_nand.o
> >   obj-$(CONFIG_NAND_BRCMNAND_68360) += bcm68360_nand.o
> >   obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
> >   obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
> > +obj-$(CONFIG_NAND_BRCMNAND_IPROC) += iproc_nand.o
> >   obj-$(CONFIG_NAND_BRCMNAND) += brcmnand.o
> >   obj-$(CONFIG_NAND_BRCMNAND) += brcmnand_compat.o
> > diff --git a/drivers/mtd/nand/raw/brcmnand/iproc_nand.c 
> > b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> > new file mode 100644
> > index ..69711d98ce1b
> > --- /dev/null
> > +++ b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
> > @@ -0,0 +1,148 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Code borrowed from the Linux driver
> > + * Copyright (C) 2015 Broadcom Corporation
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "brcmnand.h"
> > +
> > +struct iproc_nand_soc {
> > + struct brcmnand_soc soc;
> > + void __iomem *idm_base;
> > + void __iomem *ext_base;
> > +};
> > +
> > +#define IPROC_NAND_CTLR_READY_OFFSET 0x10
> > +#define IPROC_NAND_CTLR_READYBIT(0)
> > +
> > +#define IPROC_NAND_IO_CTRL_OFFSET0x00
> > +#define IPROC_NAND_APB_LE_MODE   BIT(24)
> > +#define IPROC_NAND_INT_CTRL_READ_ENABLE  BIT(6)
> > +
> > +static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
> > +{
> > + struct iproc_nand_soc *priv =
> > + container_of(soc, struct iproc_nand_soc, soc);
> > + void __iomem *mmio = priv->ext_base + IPROC_NAND_CTLR_READY_OFFSET;
> > + u32 val = brcmnand_readl(mmio);
> > +
> > + if (val & IPROC_NAND_CTLR_READY) {
> > + brcmnand_writel(IPROC_NAND_CTLR_READY, mmio);
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +static void iproc_nand_intc_set(struct brcmnand_soc *soc, bool en)
> > +{
> > + struct iproc_nand_soc *priv =
> > + container_of(soc, struct iproc_nand_soc, soc);
> > + void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
> > + u32 val = brcmnand_readl(mmio);
> > +
> > + if (en)
> > + val |= IPROC_NAND_INT_CTRL_READ_ENABLE;
> > + else
> > + val &= ~IPROC_NAND_INT_CTRL_READ_ENABLE;
> > +
> > + brcmnand_writel(val, mmio);
> > +}
> > +
> > +static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool prepare,
> > +   bool is_param)
> > +{
> > + struct iproc_nand_soc *priv =
> > + container_of(soc, struct iproc_nand_soc, soc);
> > + void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
> > + u32 val;
> > +
> > + val = brcmnand_readl(mmio);
> > +
> > + /*
> > +  * In the case of BE or when dealing with NAND data, always configure
> > +  * the APB bus to LE mode before accessing the FIFO and back to BE 
> > mode
> > +  * after the access is done
> > +  */
> > + if (IS_ENABLED(CONFIG_SYS_BIG_ENDIAN) || !is_param) {
> > +

Re: [PATCH 1/2] MAINTAINERS: Add entry for SPI NAND framework and drivers

2023-04-17 Thread Dario Binacchi
Hi Frieder,

On Tue, Mar 28, 2023 at 10:04 AM Dario Binacchi
 wrote:
>
> Hi Frieder,
>
> On Tue, Mar 28, 2023 at 10:00 AM Frieder Schrempf
>  wrote:
> >
> > On 28.02.23 15:48, Tom Rini wrote:
> > > On Tue, Feb 28, 2023 at 09:52:45AM +0100, Frieder Schrempf wrote:
> > >> On 27.02.23 16:24, Dario Binacchi wrote:
> > >>> Hi Frieder,
> > >>>
> > >>> On Mon, Feb 13, 2023 at 10:47 AM Frieder Schrempf  
> > >>> wrote:
> > 
> >  From: Frieder Schrempf 
> > 
> >  In [1] Michael agreed on taking patches for SPI NAND through the RAW
> >  NAND tree. Add a dedicated entry to the MAINTAINERS file which adds
> >  Michael and Dario as maintainers and myself as reviewer.
> > 
> >  [1] 
> >  https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-February%2F508571.html=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4HDR%2BwouzdpqPFWPdvnZWRXSyjc94T%2F0pPHaXTYNrsM%3D=0
> > 
> >  Signed-off-by: Frieder Schrempf 
> >  Cc: Jagan Teki 
> >  Cc: Dario Binacchi 
> >  Cc: Michael Nazzareno Trimarchi 
> >  Cc: Tom Rini 
> >  ---
> >   MAINTAINERS | 8 
> >   1 file changed, 8 insertions(+)
> > 
> >  diff --git a/MAINTAINERS b/MAINTAINERS
> >  index b9c505d5fa..e40c401337 100644
> >  --- a/MAINTAINERS
> >  +++ b/MAINTAINERS
> >  @@ -1375,6 +1375,14 @@ T:   git 
> >  https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-spi.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RPFcfbNZYy7sKTu8PruDhcIDts7ufkzrUtPr1cR8yhw%3D=0
> >   F: drivers/spi/
> >   F: include/spi*
> > 
> >  +SPI NAND
> >  +M: Dario Binacchi 
> >  +M: Michael Trimarchi 
> >  +R: Frieder Schrempf 
> >  +S: Maintained
> >  +T: git 
> >  https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-nand-flash.git=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pGjKSC7chQZ4%2BvT7QVNDdselY2P4llM5AeEMLTjzYUI%3D=0
> >  +F: drivers/mtd/nand/spi/
> >  +
> > >>>
> > >>> Please re-send a single patch where you only consider drivers/mtd/nand
> > >>> for NAND FLASH
> > >>> in order to be as similar as possible to the Linux kernel MAINTAINERS 
> > >>> file.
> > >>> Add to it "+R: Frieder Schrempf "
> > >>
> > >> Actually, I don't really like to be listed as reviewer for the whole
> > >> NAND subsystem. I only have limited time and knowledge and SPI NAND is
> > >> an area I feel I can provide help.
> > >>
> > >>> Neither SPI NAND nor  RAW NAND exists in the Linux kernel MAINTAINERS 
> > >>> file.
> > >>
> > >> Is there a requirement to have MAINTAINERS in sync with Linux?
> > >
> > > What matters most is that get_maintainers.pl returns something useful
> > > and correct. So if you're only comfortable with SPI NAND, the above is
> > > fine, we have similar for SPI-NOR already.
> >
> > This sounds like an Ack from Tom, so can someone pick up this series,
> > please?
>
> I'll do it.
>
> Thanks and reagrds,
> Dario
>
> --
>
> Dario Binacchi
>
> Senior Embedded Linux Developer
>
> dario.binac...@amarulasolutions.com
>
> __
>
>
> Amarula Solutions SRL
>
> Via Le Canevare 30, 31100 Treviso, Veneto, IT
>
> T. +39 042 243 5310
> i...@amarulasolutions.com
>
> www.amarulasolutions.com

Applied to nand-next,

Thanks and regards
Dario

-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com


Re: [PATCH] arm64: zynqmp: Fix User MTD partition size

2023-04-17 Thread Michal Simek




On 4/12/23 16:30, Michal Simek wrote:

The commit c8630167e0dc ("arm64: zynqmp: Add mtd partition for secure OS
storage area") didn't update User partition size that's why size was beyond
actual device size.

Signed-off-by: Michal Simek 
---

  arch/arm/dts/zynqmp-sm-k26-revA.dts | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts 
b/arch/arm/dts/zynqmp-sm-k26-revA.dts
index ed7504974194..f6ed047f3d9c 100644
--- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
+++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
@@ -224,7 +224,7 @@
};
partition@22A {
label = "User";
-   reg = <0x22A 0x1db>; /* 29.5 MB */
+   reg = <0x22A 0x1d6>; /* 29.375 MB */
};
};
};



Applied.
M


Re: [PATCH] arm64: zynqmp: Fix issue of apps executing from R5 core 1

2023-04-17 Thread Michal Simek




On 4/5/23 15:06, Michal Simek wrote:

From: Ashok Reddy Soma 

In current implementation, applications can execute only on R5 core 0.
The boot address for R5 core 1 is not supplied. Pass TCM address for
R5 core 1 based on the argument to fix the issue.

Remove incomplete comment.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Michal Simek 
---

  arch/arm/mach-zynqmp/mp.c | 26 --
  1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-zynqmp/mp.c b/arch/arm/mach-zynqmp/mp.c
index d98c34ea8a5a..7a12f4b2b6c7 100644
--- a/arch/arm/mach-zynqmp/mp.c
+++ b/arch/arm/mach-zynqmp/mp.c
@@ -32,7 +32,8 @@
  #define ZYNQMP_CRLAPB_RST_LPD_R51_RST_MASK0x02
  #define ZYNQMP_CRLAPB_CPU_R5_CTRL_CLKACT_MASK 0x100
  
-#define ZYNQMP_TCM_START_ADDRESS		0xFFE0

+#define ZYNQMP_R5_0_TCM_START_ADDR 0xFFE0
+#define ZYNQMP_R5_1_TCM_START_ADDR 0xFFE9
  #define ZYNQMP_TCM_BOTH_SIZE  0x4
  
  #define ZYNQMP_CORE_APU0	0

@@ -215,9 +216,14 @@ static void set_r5_start(u8 high)
writel(tmp, _base->rpu1_cfg);
  }
  
-static void write_tcm_boot_trampoline(u32 boot_addr)

+static void write_tcm_boot_trampoline(u32 nr, u32 boot_addr)
  {
if (boot_addr) {
+   u64 tcm_start_addr = ZYNQMP_R5_0_TCM_START_ADDR;
+
+   if (nr == ZYNQMP_CORE_RPU1)
+   tcm_start_addr = ZYNQMP_R5_1_TCM_START_ADDR;
+
/*
 * Boot trampoline is simple ASM code below.
 *
@@ -229,12 +235,12 @@ static void write_tcm_boot_trampoline(u32 boot_addr)
 *  bx  r1
 */
debug("Write boot trampoline for %x\n", boot_addr);
-   writel(0xea00, ZYNQMP_TCM_START_ADDRESS);
-   writel(boot_addr, ZYNQMP_TCM_START_ADDRESS + 0x4);
-   writel(0xe59f0004, ZYNQMP_TCM_START_ADDRESS + 0x8);
-   writel(0xe5901000, ZYNQMP_TCM_START_ADDRESS + 0xc);
-   writel(0xe12fff11, ZYNQMP_TCM_START_ADDRESS + 0x10);
-   writel(0x0004, ZYNQMP_TCM_START_ADDRESS + 0x14); // address 
for
+   writel(0xea00, tcm_start_addr);
+   writel(boot_addr, tcm_start_addr + 0x4);
+   writel(0xe59f0004, tcm_start_addr + 0x8);
+   writel(0xe5901000, tcm_start_addr + 0xc);
+   writel(0xe12fff11, tcm_start_addr + 0x10);
+   writel(0x0004, tcm_start_addr + 0x14);
}
  }
  
@@ -328,7 +334,7 @@ int cpu_release(u32 nr, int argc, char *const argv[])

enable_clock_r5();
release_r5_reset(nr, LOCK);
dcache_disable();
-   write_tcm_boot_trampoline(boot_addr_uniq);
+   write_tcm_boot_trampoline(nr, boot_addr_uniq);
dcache_enable();
set_r5_halt_mode(nr, RELEASE, LOCK);
mark_r5_used(nr, LOCK);
@@ -341,7 +347,7 @@ int cpu_release(u32 nr, int argc, char *const argv[])
enable_clock_r5();
release_r5_reset(nr, SPLIT);
dcache_disable();
-   write_tcm_boot_trampoline(boot_addr_uniq);
+   write_tcm_boot_trampoline(nr, boot_addr_uniq);
dcache_enable();
set_r5_halt_mode(nr, RELEASE, SPLIT);
mark_r5_used(nr, SPLIT);



Applied.
M


Re: [PATCH] ARM: zynq: Sync Microzed board with Linux kernel

2023-04-17 Thread Michal Simek




On 3/28/23 09:21, Michal Simek wrote:

Fix model name, node locations and also add pinctrl description for usb.

Signed-off-by: Michal Simek 
---

---
  arch/arm/dts/zynq-microzed.dts | 42 --
  1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
index b95eb3ed2434..5f280f4d8ece 100644
--- a/arch/arm/dts/zynq-microzed.dts
+++ b/arch/arm/dts/zynq-microzed.dts
@@ -8,7 +8,7 @@
  #include "zynq-7000.dtsi"
  
  / {

-   model = "Zynq MicroZED Board";
+   model = "Avnet MicroZed board";
compatible = "avnet,zynq-microzed", "xlnx,zynq-microzed", 
"xlnx,zynq-7000";
  
  	aliases {

@@ -19,7 +19,7 @@
  
  	memory@0 {

device_type = "memory";
-   reg = <0 0x4000>;
+   reg = <0x0 0x4000>;
};
  
  	chosen {

@@ -42,11 +42,6 @@
status = "okay";
  };
  
- {

-   bootph-all;
-   status = "okay";
-};
-
   {
status = "okay";
phy-mode = "rgmii-id";
@@ -62,8 +57,41 @@
status = "okay";
  };
  
+ {

+   bootph-all;
+   status = "okay";
+};
+
   {
status = "okay";
dr_mode = "host";
usb-phy = <_phy0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb0_default>;
+};
+
+ {
+   pinctrl_usb0_default: usb0-default {
+   mux {
+   groups = "usb0_0_grp";
+   function = "usb0";
+   };
+
+   conf {
+   groups = "usb0_0_grp";
+   slew-rate = <0>;
+   io-standard = <1>;
+   };
+
+   conf-rx {
+   pins = "MIO29", "MIO31", "MIO36";
+   bias-high-impedance;
+   };
+
+   conf-tx {
+   pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
+  "MIO35", "MIO37", "MIO38", "MIO39";
+   bias-disable;
+   };
+   };
  };


Applied.
M


Re: [PATCH] ARM: zynq: Switch from earlyprintk to earlycon

2023-04-17 Thread Michal Simek




On 3/28/23 09:17, Michal Simek wrote:

Switch to earlycon which is preffered over earlyprintk.
It is also sync with Linux kernel (zynq-microzed).

Signed-off-by: Michal Simek 
---

---
  arch/arm/dts/zynq-dlc20-rev1.0.dts | 2 +-
  arch/arm/dts/zynq-microzed.dts | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynq-dlc20-rev1.0.dts 
b/arch/arm/dts/zynq-dlc20-rev1.0.dts
index cbf52c88b9a4..cfe07102297b 100644
--- a/arch/arm/dts/zynq-dlc20-rev1.0.dts
+++ b/arch/arm/dts/zynq-dlc20-rev1.0.dts
@@ -26,7 +26,7 @@
};
  
  	chosen {

-   bootargs = "earlyprintk";
+   bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
  
diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts

index 875ee080df20..b95eb3ed2434 100644
--- a/arch/arm/dts/zynq-microzed.dts
+++ b/arch/arm/dts/zynq-microzed.dts
@@ -23,7 +23,7 @@
};
  
  	chosen {

-   bootargs = "earlyprintk";
+   bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
  


Applied.
M


Re: [PATCH v2 2/2] configs: Add CONFIG_DEFAULT_ENV_IS_RW config for armada

2023-04-17 Thread Michal Simek




On 4/17/23 06:28, Venkatesh Yadav Abbarapu wrote:

From: Algapally Santosh Sagar 

The DEFAULT_ENV_IS_RW is moved to the Kconfig for easier configuration.
Hence, the CONFIG_DEFAULT_ENV_IS_RW config is added to the defconfig files
to allow enabling them for armada boards.

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Venkatesh Yadav Abbarapu 
---
  configs/mvebu_db-88f3720_defconfig  | 1 +
  configs/mvebu_espressobin-88f3720_defconfig | 1 +
  configs/mvebu_mcbin-88f8040_defconfig   | 1 +
  3 files changed, 3 insertions(+)

diff --git a/configs/mvebu_db-88f3720_defconfig 
b/configs/mvebu_db-88f3720_defconfig
index ed0d28fd7d..e3bbaa2173 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -21,6 +21,7 @@ CONFIG_USE_PREBOOT=y
  CONFIG_SYS_CONSOLE_INFO_QUIET=y
  # CONFIG_DISPLAY_CPUINFO is not set
  # CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_ARCH_EARLY_INIT_R=y
  CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index ce696787e8..a06eb2dd42 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -22,6 +22,7 @@ CONFIG_USE_PREBOOT=y
  CONFIG_SYS_CONSOLE_INFO_QUIET=y
  # CONFIG_DISPLAY_CPUINFO is not set
  # CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_ARCH_EARLY_INIT_R=y
  CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/mvebu_mcbin-88f8040_defconfig 
b/configs/mvebu_mcbin-88f8040_defconfig
index 058c04333a..4ee5f242f7 100644
--- a/configs/mvebu_mcbin-88f8040_defconfig
+++ b/configs/mvebu_mcbin-88f8040_defconfig
@@ -22,6 +22,7 @@ CONFIG_USE_PREBOOT=y
  CONFIG_SYS_CONSOLE_INFO_QUIET=y
  # CONFIG_DISPLAY_CPUINFO is not set
  # CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_ARCH_EARLY_INIT_R=y
  CONFIG_BOARD_EARLY_INIT_F=y


This smells. If this is the part of armada it should be in that patch only.

M



Re: [PATCH v2 1/2] serial: zynqmp: Fetch baudrate from dtb and update

2023-04-17 Thread Michal Simek




On 4/17/23 06:28, Venkatesh Yadav Abbarapu wrote:

From: Algapally Santosh Sagar 

The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.

To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.

The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/serial/Kconfig  | 16 
  drivers/serial/serial-uclass.c  | 32 +++
  include/configs/mvebu_armada-37xx.h |  1 -
  include/configs/xilinx_zynqmp.h |  3 ++-
  include/env_default.h   |  7 -
  include/env_internal.h  |  2 +-
  include/fdtdec.h|  8 ++
  include/serial.h|  1 +
  lib/fdtdec.c| 40 +
  9 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 10d07daf27..96cea87f45 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -24,6 +24,22 @@ config BAUDRATE
  in the SPL stage (most drivers) or for choosing a default baudrate
  in the absence of an environment setting (serial_mxc.c).
  
+config SERIAL_DT_BAUD

+   bool "Fetch serial baudrate from device tree"
+   depends on DM_SERIAL && SPL_ENV_SUPPORT
+   select DEFAULT_ENV_IS_RW
+   help
+ Select this to enable fetching and setting of the baudrate
+ configured in the DT. Replace the default baudrate with the DT
+ baudrate and also set it to the environment.
+
+config DEFAULT_ENV_IS_RW
+   bool "Make default environment as writable"
+   depends on DM_SERIAL
+   help
+ Select this to enable to make default environment writable. This
+ allows modifying the default environment.


This is one separate patch which is simply move to Kconfig and convert armada.



+
  config REQUIRE_SERIAL_CONSOLE
bool "Require a serial port for console"
# Running without a serial console is not supported by the
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 067fae2614..d77d3bda36 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -154,12 +154,44 @@ static void serial_find_console_or_panic(void)
  }
  #endif /* CONFIG_SERIAL_PRESENT */
  
+#ifdef CONFIG_SERIAL_DT_BAUD

+int serial_get_valid_baudrate(int baud)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(baudrate_table); ++i) {
+   if (baud == baudrate_table[i])
+   return 0;
+   }
+
+   return -EINVAL;
+}
+#endif
+
  /* Called prior to relocation */
  int serial_init(void)
  {
  #if CONFIG_IS_ENABLED(SERIAL_PRESENT)
serial_find_console_or_panic();
gd->flags |= GD_FLG_SERIAL_READY;
+#ifdef CONFIG_SERIAL_DT_BAUD
+   int ret = 0;
+   char *ptr = _environment[0];
+
+   /*
+* Fetch the baudrate from the dtb and update the value in the
+* default environment.
+*/
+   ret = fdtdec_get_baud_from_dtb(gd->fdt_blob);
+   if (ret != -EINVAL && ret != -EFAULT) {
+   gd->baudrate = ret;
+
+   while (*ptr != '\0' && *(ptr + 1) != '\0')
+   ptr++;
+   ptr += 2;
+   sprintf(ptr, "baudrate=%d", gd->baudrate);
+   }
+#endif
serial_setbrg();
  #endif
  
diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h

index 76e148f55e..18b55be0d8 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -30,7 +30,6 @@
  /*
   * Environment
   */
-#define DEFAULT_ENV_IS_RW  /* required for configuring default 
fdtfile= */
  
  #ifdef CONFIG_MMC

  #define BOOT_TARGET_DEVICES_MMC(func, i) func(MMC, mmc, i)
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 011f0034c5..8620bda489 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -176,7 +176,8 @@
  #ifndef CFG_EXTRA_ENV_SETTINGS
  #define CFG_EXTRA_ENV_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
-   BOOTENV
+   BOOTENV \
+   ENV_RW_FILLER


This is not what TOM was saying. You shouldn't have a need to update every board 
which wants this feature. Just enable it and get it. It means this 

[PATCH 1/1] sandbox: correct posix_types.h define

2023-04-17 Thread Heinrich Schuchardt
arch/arm/include/asm/posix_types.h and
arch/sandbox/include/asm/posix_types.h should use different defines.

Add SPDX header.

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/include/asm/posix_types.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/sandbox/include/asm/posix_types.h 
b/arch/sandbox/include/asm/posix_types.h
index ec18ed7e3c..e1442c455b 100644
--- a/arch/sandbox/include/asm/posix_types.h
+++ b/arch/sandbox/include/asm/posix_types.h
@@ -1,5 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
- *  linux/include/asm-arm/posix_types.h
+ * Based on linux/include/asm-arm/posix_types.h
  *
  *  Copyright (C) 1996-1998 Russell King.
  *
@@ -10,8 +11,8 @@
  *  Changelog:
  *   27-06-1996RMK Created
  */
-#ifndef __ARCH_ARM_POSIX_TYPES_H
-#define __ARCH_ARM_POSIX_TYPES_H
+#ifndef __ARCH_SANDBOX_POSIX_TYPES_H
+#define __ARCH_SANDBOX_POSIX_TYPES_H
 
 /*
  * This file is generally used by user-level software, so you need to
-- 
2.39.2



Re: [PATCH u-boot 2/4] cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in mmc_burn_image()

2023-04-17 Thread Pali Rohár
+ Martin

On Thursday 13 April 2023 23:10:55 Pali Rohár wrote:
> When determining eMMC boot partition for a bootloader, validate that
> EXT_CSD[179] eMMC register is set to recognized value.
> 
> This prevent situation that EXT_CSD[179] Boot Enable value is improperly
> parsed and passed into EXT_CSD[179] Partition Access.
> 
> Signed-off-by: Pali Rohár 
> ---
>  cmd/mvebu/bubt.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
> index ca24a5c1c4ba..b8fe7c7a1461 100644
> --- a/cmd/mvebu/bubt.c
> +++ b/cmd/mvebu/bubt.c
> @@ -223,9 +223,29 @@ static int mmc_burn_image(size_t image_size)
>   orig_part = mmc->block_dev.hwpart;
>  #endif
>  
> - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> - if (part == 7)
> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
>   part = 0;
> + } else {
> + switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> + case 0: /* Booting from this eMMC device is disabled */
> + printf("Error - Booting from this eMMC device is 
> disabled\n");
> + printf("Hint: Use 'mmc partconf' command to choose boot 
> partition\n");
> + return -ENODEV;
> + case 1: /* Boot partition 1 is used for booting */
> + part = 1;
> + break;
> + case 2: /* Boot partition 2 is used for booting */
> + part = 2;
> + break;
> + case 7: /* User area is used for booting */
> + part = 0;
> + break;
> + default: /* Other values are reserved / unsupported */
> + printf("Error - This eMMC device has configured 
> Reserved boot option\n");
> + printf("Hint: Use 'mmc partconf' command to choose boot 
> partition\n");
> + return -ENODEV;
> + }
> + }
>  
>  #ifdef CONFIG_BLK
>   err = blk_dselect_hwpart(blk_desc, part);
> -- 
> 2.20.1
> 


Re: [PATCH u-boot 0/3] pci: mpc85xx: Fixes for PCI config space

2023-04-17 Thread Pali Rohár
On Monday 17 April 2023 07:12:16 Heiko Schocher wrote:
> Hello Pali,
> 
> On 13.04.23 22:41, Pali Rohár wrote:
> > This patch series contains small fixes for mpc85xx old PCI Local Bus driver.
> > 
> > Heiko: Are you able to test these changes? Has your Socrates board
> > available old PCI Local Bus support?
> > 
> > Pali Rohár (3):
> >   pci: mpc85xx: Add missing sync() after writing to PCI config space
> >   pci: mpc85xx: Allow 8/16-bit access to PCI config space
> >   pci: mpc85xx: Do not try to access extended PCIe registers
> > 
> >  drivers/pci/pci_mpc85xx.c | 39 +++
> >  1 file changed, 35 insertions(+), 4 deletions(-)
> 
> I just applied your patches to my U-Boot (based on 2023.04) running
> on the socrates board. I see no problems.
> 
> I have there:
> 
> => pci
> BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
> _
> 00.00.00   0x1957 0x0033 Processor   0x20
> 00.11.00   0x1131 0x1561 Serial bus controller   0x03
> 00.11.01   0x1131 0x1561 Serial bus controller   0x03
> 00.11.02   0x1131 0x1562 Serial bus controller   0x03
> 00.12.00   0x1131 0x1561 Serial bus controller   0x03
> 00.12.01   0x1131 0x1561 Serial bus controller   0x03
> 00.12.02   0x1131 0x1562 Serial bus controller   0x03
> =>
> 
> => usb start
> starting USB...
> Bus ohci_pci: USB OHCI 1.0
> Bus ohci_pci: USB OHCI 1.0
> Bus ohci_pci: USB OHCI 1.0
> Bus ohci_pci: USB OHCI 1.0
> scanning bus ohci_pci for devices... 1 USB Device(s) found
> scanning bus ohci_pci for devices... 1 USB Device(s) found
> scanning bus ohci_pci for devices... 1 USB Device(s) found
> scanning bus ohci_pci for devices... 2 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> => usb storage
>   Device 0: Vendor: Mass Rev: 1.00 Prod: Storage Device
> Type: Removable Hard Disk
> Capacity: 30424.5 MB = 29.7 GB (62309376 x 512)
> =>
> 
> So, I see no problems with your patches.

Thanks for testing!

Could you send me dump of the PCI config space from u-boot and also from
Linux? So I could compare it if U-Boot is doing everything correctly.

In U-Boot for first two devices:

  => pci display.b 00.00.00 0x0 0x1000
  => pci display.b 00.11.00 0x0 0x1000

And in Linux for all devices:

  # lspci - -nn

> 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


Re: commit 787f04bb6a - imx: add USB2_BOOT type

2023-04-17 Thread Rasmus Villemoes
On 26/10/2022 01.42, Rasmus Villemoes wrote:
> On 18/10/2022 02.43, Peng Fan wrote:
>> + Stefano & Fabio
>>
> 
>
> Is there any chance you could make some information on that ROM API
> public so it's possible for outsiders to understand what's going on?
>>
>> What could only help is to ask the ROM team to see whether they have
>> plan to public the ROM API details and when. Otherwise you could only
>> read the code to understand how it works.
>>

 Could you please try below changes to check whether it fixes your issue?
>>>
>>> Well, it seems very likely it would, but could you _please_ answer the
>>> real question so we as a community has a chance of evaluating whether
>>> that's the proper fix or something else entirely is needed. And so that
>>> in the future we as a community would have a chance of objecting to
>>> including 787f04bb6a in the first place.
>>
>> You could help reviewing if you have time.
> 
> Don't you see the absurdity of on the one hand saying that the only way
> to understand the ROM API is to study the U-Boot side of the code, and
> on the other hand asking others to review changes to said code?
> 
> If the API could be understood from merely reading existing U-Boot code,
> than that code is by definition perfect and won't need to be changed.
> 
> Now that I know there is a dedicated ROM team, let me rephrase:
> 
> Is there any chance you could reach out to said ROM team and ask if they
> could make some information on the API public?
> 
> [The "you" in the previous questions have always meant NXP, not you
> personally.]

And here we are, half a year later, and mainline U-Boot is still broken.

I'm not gonna offer a tested-by or reviewed-by on that patch you
suggested upthread until and unless the ROM API gets documented.

Rasmus



Re: [PATCH V3 2/2] ARM: dts: rockchip: rk3588s-u-boot: Add rng node

2023-04-17 Thread Sughosh Ganu
hi Chris,

On Thu, 13 Apr 2023 at 19:43, Chris Morgan  wrote:
>
> From: Chris Morgan 
>
> Add a node for the trng found on RK3588 SoCs.
>
> Changes in V3:
>  - Added Reviewed-By tag.
>
> Changes in V2:
>  - None

Same comment for the changelog lines as in the other patch.

Other than that

Acked-by: Sughosh Ganu 

-sughosh

>
> Signed-off-by: Chris Morgan 
> Reviewed-by: Kever Yang 
> ---
>  arch/arm/dts/rk3588s-u-boot.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi 
> b/arch/arm/dts/rk3588s-u-boot.dtsi
> index f880f4a167..43aeeb4de3 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -43,6 +43,12 @@
> reg = <0x07 0x10>;
> };
> };
> +
> +   rng: rng@fe378000 {
> +   compatible = "rockchip,trngv1";
> +   reg = <0x0 0xfe378000 0x0 0x200>;
> +   status = "disabled";
> +   };
>  };
>
>   {
> --
> 2.34.1
>


Re: [PATCH V3 1/2] rockchip: rng: add trngv1 for rk3588

2023-04-17 Thread Sughosh Ganu
hi Chris,

On Thu, 13 Apr 2023 at 19:43, Chris Morgan  wrote:
>
> From: Chris Morgan 
>
> This adds support for the TRNG found in the RK3588 SoC to the
> rockchip_rng driver so that it can be used for things such as
> seeding randomness to Linux.
>
> Changes in V3:
>  - Moved notes from commit to cover letter.
>  - Added Reviewed-By tag.
>
> Changes in V2:
>  - Modified Kconfig to note that the Rockchip RNG driver supports all
>versions of the hardware (v1, v2, and the trng in the rk3588).

The changelog lines should come below the --- line after the
Signed-off-by, R-b lines.

>
> Signed-off-by: Lin Jinhan 
> Signed-off-by: Chris Morgan 
> Reviewed-by: Kever Yang 
> ---
>  drivers/rng/Kconfig|   5 +-
>  drivers/rng/rockchip_rng.c | 120 ++---
>  2 files changed, 114 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> index 5dcf68176a..5deb5db5b7 100644
> --- a/drivers/rng/Kconfig
> +++ b/drivers/rng/Kconfig
> @@ -58,8 +58,9 @@ config RNG_ROCKCHIP
> bool "Enable random number generator for rockchip crypto rng"
> depends on ARCH_ROCKCHIP && DM_RNG
> help
> - Enable random number generator for rockchip.This driver is
> - support rng module of crypto v1 and crypto v2.
> + Enable random number generator for rockchip. This driver
> + supports the rng module of crypto v1, crypto v2, and the
> + trng module of the rk3588 series.
>
>  config RNG_IPROC200
> bool "Broadcom iProc RNG200 random number generator"
> diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
> index 800150f114..705b424cf3 100644
> --- a/drivers/rng/rockchip_rng.c
> +++ b/drivers/rng/rockchip_rng.c
> @@ -43,9 +43,41 @@
>  #define CRYPTO_V2_RNG_DOUT_0   0x0410
>  /* end of CRYPTO V2 register define */
>
> +/* start of TRNG V1 register define */
> +#define TRNG_V1_CTRL   0x
> +#define TRNG_V1_CTRL_NOP   _SBF(0, 0x00)
> +#define TRNG_V1_CTRL_RAND  _SBF(0, 0x01)
> +#define TRNG_V1_CTRL_SEED  _SBF(0, 0x02)
> +
> +#define TRNG_V1_MODE   0x0008
> +#define TRNG_V1_MODE_128_BIT   _SBF(3, 0x00)
> +#define TRNG_V1_MODE_256_BIT   _SBF(3, 0x01)
> +
> +#define TRNG_V1_IE 0x0010
> +#define TRNG_V1_IE_GLBL_EN BIT(31)
> +#define TRNG_V1_IE_SEED_DONE_ENBIT(1)
> +#define TRNG_V1_IE_RAND_RDY_EN BIT(0)
> +
> +#define TRNG_V1_ISTAT  0x0014
> +#define TRNG_V1_ISTAT_RAND_RDY BIT(0)
> +
> +/* RAND0 ~ RAND7 */
> +#define TRNG_V1_RAND0  0x0020
> +#define TRNG_V1_RAND7  0x003C
> +
> +#define TRNG_V1_AUTO_RQSTS 0x0060
> +
> +#define TRNG_V1_VERSION0x00F0
> +#define TRNG_v1_VERSION_CODE   0x46BC
> +/* end of TRNG V1 register define */
> +
>  #define RK_RNG_TIME_OUT5  /* max 50ms */
>
> +#define trng_write(pdata, pos, val)writel(val, (pdata)->base + (pos))
> +#define trng_read(pdata, pos)  readl((pdata)->base + (pos))
> +
>  struct rk_rng_soc_data {
> +   int (*rk_rng_init)(struct udevice *dev);
> int (*rk_rng_read)(struct udevice *dev, void *data, size_t len);
>  };
>
> @@ -75,7 +107,7 @@ static int rk_rng_read_regs(fdt_addr_t addr, void *buf, 
> size_t size)
> return 0;
>  }
>
> -static int rk_v1_rng_read(struct udevice *dev, void *data, size_t len)
> +static int rk_cryptov1_rng_read(struct udevice *dev, void *data, size_t len)
>  {
> struct rk_rng_plat *pdata = dev_get_priv(dev);
> u32 reg = 0;
> @@ -106,7 +138,7 @@ exit:
> return 0;
>  }
>
> -static int rk_v2_rng_read(struct udevice *dev, void *data, size_t len)
> +static int rk_cryptov2_rng_read(struct udevice *dev, void *data, size_t len)
>  {
> struct rk_rng_plat *pdata = dev_get_priv(dev);
> u32 reg = 0;
> @@ -140,6 +172,63 @@ exit:
> return retval;
>  }
>
> +static int rk_trngv1_init(struct udevice *dev)
> +{
> +   u32 status, version;
> +   u32 auto_reseed_cnt = 1000;
> +   struct rk_rng_plat *pdata = dev_get_priv(dev);
> +
> +   version = trng_read(pdata, TRNG_V1_VERSION);
> +   if (version != TRNG_v1_VERSION_CODE) {
> +   printf("wrong trng version, expected = %08x, actual = %08x",
> +  TRNG_V1_VERSION, version);
> +   return -EFAULT;
> +   }
> +
> +   /* wait in case of RND_RDY triggered at firs power on */
> +   readl_poll_timeout(pdata->base + TRNG_V1_ISTAT, status,
> +  (status & TRNG_V1_ISTAT_RAND_RDY),
> +  RK_RNG_TIME_OUT);
> +
> +   /* clear RAND_RDY flag for first power on */
> +   trng_write(pdata, TRNG_V1_ISTAT, 

Re: [PATCH v4 3/6] tools: Add mkfwumdata tool for FWU metadata image

2023-04-17 Thread Michal Simek




On 4/14/23 17:02, Jassi Brar wrote:

On Fri, Apr 14, 2023 at 8:53 AM Michal Simek  wrote:




On 4/10/23 06:05, Jassi Brar wrote:

On Wed, 29 Mar 2023 at 07:29, Michal Simek  wrote:

On 3/27/23 23:16, jassisinghb...@gmail.com wrote:



diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
new file mode 100644
index 00..43dabf3b72
--- /dev/null
+++ b/tools/mkfwumdata.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* This will dynamically allocate the fwu_mdata */
+#define CONFIG_FWU_NUM_BANKS 0
+#define CONFIG_FWU_NUM_IMAGES_PER_BANK   0


These two are completely unused.


these are necessary for include/fwu_mdata.h that comes later.


If that's come later, add it later.


Can you please actually look at the code to see the underlying constraint?


Ok. I misunderstand your comment.

You have it there because of #include  and using macros there.
Can you just allocated that structures at run time instead of statically defined 
them via array? That would clean that design and also fix checkpatch issue.


Thanks,
Michal

$ ./scripts/checkpatch.pl -f tools/mkfwumdata.c
ERROR: All CONFIG symbols are managed by Kconfig
#18: FILE: tools/mkfwumdata.c:18:
+#define CONFIG_FWU_NUM_BANKS   0

ERROR: All CONFIG symbols are managed by Kconfig
#19: FILE: tools/mkfwumdata.c:19:
+#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0

total: 2 errors, 0 warnings, 0 checks, 334 lines checked


[PATCH] arm: mach-k3: j7200: Fix firewall warnings at boot time

2023-04-17 Thread Manorit Chawdhry
J721E and J7200 have same file j721e_init.c which had the firewall
configs for J721E being applied on J7200 causing the warnings. Split the
firewalls for both the boards to remove those warnings.

Signed-off-by: Manorit Chawdhry 
---
 arch/arm/mach-k3/j721e_init.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 9cae3ac67e9c..e60173529726 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -26,6 +26,7 @@
 
 #ifdef CONFIG_K3_LOAD_SYSFW
 struct fwl_data cbass_hc_cfg0_fwls[] = {
+#if defined(CONFIG_TARGET_J721E_R5_EVM)
{ "PCIE0_CFG", 2560, 8 },
{ "PCIE1_CFG", 2561, 8 },
{ "USB3SS0_CORE", 2568, 4 },
@@ -34,11 +35,16 @@ struct fwl_data cbass_hc_cfg0_fwls[] = {
{ "UFS_HCI0_CFG", 2580, 4 },
{ "SERDES0", 2584, 1 },
{ "SERDES1", 2585, 1 },
+#elif defined(CONFIG_TARGET_J7200_R5_EVM)
+   { "PCIE1_CFG", 2561, 7 },
+#endif
 }, cbass_hc0_fwls[] = {
+#if defined(CONFIG_TARGET_J721E_R5_EVM)
{ "PCIE0_HP", 2528, 24 },
{ "PCIE0_LP", 2529, 24 },
{ "PCIE1_HP", 2530, 24 },
{ "PCIE1_LP", 2531, 24 },
+#endif
 }, cbass_rc_cfg0_fwls[] = {
{ "EMMCSD4SS0_CFG", 2380, 4 },
 }, cbass_rc0_fwls[] = {

---
base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d
change-id: 20230414-upstream-j7200-firewall-fix-9f768170862b

Best regards,
-- 
Manorit Chawdhry 



Re: [PATCH] riscv: Add a 64-bit image type

2023-04-17 Thread Bin Meng
Hi Leo,

On Mon, Apr 17, 2023 at 1:22 PM Leo Liang  wrote:
>
> Hi Bin,
>
> On Thu, Apr 13, 2023 at 06:06:29PM +0800, Bin Meng wrote:
> > On Mon, Apr 10, 2023 at 3:25 PM Rick Chen  wrote:
> > >
> > > > From: Simon Glass 
> > > > Sent: Monday, April 03, 2023 4:28 AM
> > > > To: U-Boot Mailing List 
> > > > Cc: Sean Anderson ; Bin Meng ; 
> > > > Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> > > > ; Simon Glass ; Andre 
> > > > Przywara ; Marc Kleine-Budde 
> > > > ; SESA644425 ; Samuel 
> > > > Holland ; Steven Lawrance 
> > > > 
> > > > Subject: [PATCH] riscv: Add a 64-bit image type
> > > >
> > > > At present it is not possible to know whether an image can be booted by 
> > > > a 32- or 64-bit bootloader. This means that U-Boot may attempt to boot 
> > > > the wrong image. This may cause a crash which might be hard to debug.
> > > >
> > > > Add a new property to make this explicit.
> > > >
> > > > The existing 'RISC-V' is now taken to mean 32-bit.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > >  boot/image.c| 3 ++-
> > > >  include/image.h | 3 ++-
> > > >  2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > Reviewed-by: Rick Chen 
> >
> > This might create compatibility issues if the shipped host tool
> > (mkimage) does not match U-Boot version. Any idea how to avoid that?
> >
>
> I am not sure if I understand you correctly.
> Do you mean that there could be compatibility issue
> if one uses 2023.04 release host tool (mkimage) to build images
> that are to be booted by 2023.07 release u-boot (if this patch is merged in 
> 2023.07 u-boot)?

Yes.

>
> If that is the case, I guess there is no easy way to avoid that.
> We could probably have RISCV represent 64 bit riscv architecture
> and RISCV32 32 bit because most of the boards are 64 bit.
>
> If that is not the case, could you elaborate more ?
>
> And Rick has sent out a patch to fix booting issue based on Simon's patch as 
> well.

I believe we should be querying some wider audience other than U-Boot
that if the RISC-V community intends to support 64-bit U-Boot booting
a 32-bit kernel, before we introduce such incompatibility change.

Regards,
Bin


Re: [PATCH u-boot 2/4] cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in mmc_burn_image()

2023-04-17 Thread Stefan Roese

On 4/13/23 23:10, Pali Rohár wrote:

When determining eMMC boot partition for a bootloader, validate that
EXT_CSD[179] eMMC register is set to recognized value.

This prevent situation that EXT_CSD[179] Boot Enable value is improperly
parsed and passed into EXT_CSD[179] Partition Access.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/mvebu/bubt.c | 24 ++--
  1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index ca24a5c1c4ba..b8fe7c7a1461 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -223,9 +223,29 @@ static int mmc_burn_image(size_t image_size)
orig_part = mmc->block_dev.hwpart;
  #endif
  
-	part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);

-   if (part == 7)
+   if (mmc->part_config == MMCPART_NOAVAILABLE) {
part = 0;
+   } else {
+   switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+   case 0: /* Booting from this eMMC device is disabled */
+   printf("Error - Booting from this eMMC device is 
disabled\n");
+   printf("Hint: Use 'mmc partconf' command to choose boot 
partition\n");
+   return -ENODEV;
+   case 1: /* Boot partition 1 is used for booting */
+   part = 1;
+   break;
+   case 2: /* Boot partition 2 is used for booting */
+   part = 2;
+   break;
+   case 7: /* User area is used for booting */
+   part = 0;
+   break;
+   default: /* Other values are reserved / unsupported */
+   printf("Error - This eMMC device has configured Reserved 
boot option\n");
+   printf("Hint: Use 'mmc partconf' command to choose boot 
partition\n");
+   return -ENODEV;
+   }
+   }
  
  #ifdef CONFIG_BLK

err = blk_dselect_hwpart(blk_desc, part);


Viele Grüße,
Stefan Roese

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


<    1   2