Re: [PATCH 07/11] watchdog: Add support for ADI SC5XX-family watchdog peripheral

2024-05-15 Thread Stefan Roese

On 5/15/24 23:57, Greg Malysa wrote:

From: Nathan Barrett-Morrison 

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

  MAINTAINERS|   1 +
  drivers/watchdog/Kconfig   |   9 +++
  drivers/watchdog/Makefile  |   1 +
  drivers/watchdog/adi_wdt.c | 145 +
  4 files changed, 156 insertions(+)
  create mode 100644 drivers/watchdog/adi_wdt.c


Reviewed-by: Stefan Roese 

Thanks,
Stefan


diff --git a/MAINTAINERS b/MAINTAINERS
index c1685f0352..6feb7e540b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -618,6 +618,7 @@ F:  drivers/pinctrl/pinctrl-adi-adsp.c
  F:drivers/serial/serial_adi_uart4.c
  F:drivers/timer/adi_sc5xx_timer.c
  F:drivers/usb/musb-new/sc5xx.c
+F: drivers/watchdog/adi_wdt.c
  F:include/env/adi/
  
  ARM SNAPDRAGON

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8318fd77a3..5a62000272 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -94,6 +94,15 @@ config WDT_APPLE
  The watchdog will perform a full SoC reset resulting in a
  reboot of the entire system.
  
+config WDT_ADI

+   bool "Analog Devices watchdog timer support"
+   select WDT
+   select SPL_WDT if SPL
+   depends on (SC57X || SC58X || SC59X || SC59X_64)
+   help
+ Enable this to support Watchdog Timer on ADI SC57X, SC58X, SC59X,
+ and SC59X_64 processors
+
  config WDT_ARMADA_37XX
bool "Marvell Armada 37xx watchdog timer support"
depends on WDT && ARMADA_3700
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7b39adcf0f..7ad61b513c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -50,3 +50,4 @@ obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
  obj-$(CONFIG_WDT_SUNXI) += sunxi_wdt.o
  obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
  obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+obj-$(CONFIG_WDT_ADI) += adi_wdt.o
diff --git a/drivers/watchdog/adi_wdt.c b/drivers/watchdog/adi_wdt.c
new file mode 100644
index 00..67d17dc692
--- /dev/null
+++ b/drivers/watchdog/adi_wdt.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Converted to driver model by Nathan Barrett-Morrison
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ *
+ * adi_wtd.c - driver for ADI on-chip watchdog
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDOG_CTL  0x0
+#define WDOG_CNT  0x4
+#define WDOG_STAT 0x8
+
+#define RCU_CTL   0x0
+#define RCU_STAT  0x4
+
+#define SEC_GCTL  0x0
+#define SEC_FCTL  0x10
+#define SEC_SCTL0 0x800
+
+#define WDEN  0x0010
+#define WDDIS 0x0AD0
+
+struct adi_wdt_priv {
+   void __iomem *rcu_base;
+   void __iomem *sec_base;
+   void __iomem *wdt_base;
+   struct clk clock;
+};
+
+static int adi_wdt_reset(struct udevice *dev)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(0, priv->wdt_base + WDOG_STAT);
+
+   return 0;
+}
+
+static int adi_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+   u32 sctl_val;
+
+   /* Disable SYSCD_RESETb input and clear the RCU0 reset status */
+   writel(0xf, priv->rcu_base + RCU_STAT);
+   writel(0x0, priv->rcu_base + RCU_CTL);
+
+   /* reset the SEC controller */
+   writel(0x2, priv->sec_base + SEC_GCTL);
+   writel(0x2, priv->sec_base + SEC_FCTL);
+
+   udelay(50);
+
+   /* enable SEC fault event */
+   writel(0x1, priv->sec_base + SEC_GCTL);
+
+   /* ANOMALY 3614 Spurious External Fault event occurs when FCTL
+* is re-programmed when currently active fault is not cleared
+*/
+   writel(0xc0, priv->sec_base + SEC_FCTL);
+   writel(0xc1, priv->sec_base + SEC_FCTL);
+
+   /* enable SEC fault source for watchdog0 */
+   sctl_val = readl((priv->sec_base + SEC_SCTL0) + 3 * 8) | 0x6;
+   writel(sctl_val, (priv->sec_base + SEC_SCTL0) + 3 * 8);
+
+   /* Enable SYSCD_RESETb input */
+   writel(0x100, priv->rcu_base + RCU_CTL);
+
+   /* enable watchdog0 */
+   writel(WDDIS, priv->wdt_base + WDOG_CTL);
+
+   writel(timeout_ms / 1000 *
+  (clk_get_rate(>clock) / (IS_ENABLED(CONFIG_SC58X) ? 2 : 
1)),
+  priv->wdt_base + WDOG_CNT);
+
+   writel(0, priv->wdt_base + WDOG_STAT);
+   writel(WDEN, priv->wdt_base + WDOG_CTL);
+
+   return 0;
+}
+
+static int adi_wdt_probe(struct udevice *dev)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+   int ret;
+   struct resource res;
+
+   ret = dev_read_resource_byname(dev, "rcu", );
+ 

[PATCH 00/11] drivers: Driver support for ADI SC5xx SoCs

2024-05-15 Thread Greg Malysa


This series adds all of the supported peripheral drivers for the sc5xx
series of SoCs from Analog Devices and other drivers that are used by
the evaluation kits, such as a GPIO expander used by the EZLITE carrier
boards.

This series is based on uboot/next as it references the sc5xx machine
type at times and currently passes CI.


Greg Malysa (4):
  pinctrl: Add support for ADI SC5XX-family pinctrl
  gpio: Add support for SC5XX-family processor GPIO driver
  net: Add support for ADI SC5xx SoCs with DWC QoS ethernet
  dma: Add driver for ADI SC5xx-family SoC MDMA functionality

Nathan Barrett-Morrison (7):
  gpio: Add support for ADI ADP5588 GPIO expander chips
  usb: musb-new: Add support for Analog Devices SC5xx SoCs
  i2c: Add support for ADI SC5XX-family I2C peripheral
  watchdog: Add support for ADI SC5XX-family watchdog peripheral
  remoteproc: Add in SHARC loading for ADI SC5XX-family processors
  spi: Add support for ADI SC5XX-family processor SPI peripherals
  mmc: Add support for ADI SC5XX-family processor SDHCI peripherals

 MAINTAINERS|  11 +
 drivers/dma/Kconfig|   7 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/adi_dma.c  | 255 +
 drivers/gpio/Kconfig   |  17 +
 drivers/gpio/Makefile  |   2 +
 drivers/gpio/adp5588_gpio.c| 208 
 drivers/gpio/gpio-adi-adsp.c   | 179 +++
 drivers/i2c/Kconfig|   7 +
 drivers/i2c/Makefile   |   1 +
 drivers/i2c/adi_i2c.c  | 393 ++
 drivers/mmc/Kconfig|   8 +
 drivers/mmc/Makefile   |   1 +
 drivers/mmc/adi_sdhci.c| 152 ++
 drivers/net/Kconfig|   7 +
 drivers/net/Makefile   |   1 +
 drivers/net/dwc_eth_qos.c  |   6 +
 drivers/net/dwc_eth_qos.h  |   2 +
 drivers/net/dwc_eth_qos_adi.c  | 101 
 drivers/pinctrl/Kconfig|   8 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-adi-adsp.c | 156 ++
 drivers/remoteproc/Kconfig |  11 +
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/adi_sc5xx_rproc.c   | 276 ++
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/adi_spi3.c | 690 +
 drivers/usb/musb-new/Kconfig   |   7 +
 drivers/usb/musb-new/Makefile  |   1 +
 drivers/usb/musb-new/sc5xx.c   | 202 
 drivers/watchdog/Kconfig   |   9 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/adi_wdt.c | 145 ++
 include/dt-bindings/pinctrl/adi-adsp.h |  21 +
 35 files changed, 2895 insertions(+)
 create mode 100644 drivers/dma/adi_dma.c
 create mode 100644 drivers/gpio/adp5588_gpio.c
 create mode 100644 drivers/gpio/gpio-adi-adsp.c
 create mode 100644 drivers/i2c/adi_i2c.c
 create mode 100644 drivers/mmc/adi_sdhci.c
 create mode 100644 drivers/net/dwc_eth_qos_adi.c
 create mode 100644 drivers/pinctrl/pinctrl-adi-adsp.c
 create mode 100644 drivers/remoteproc/adi_sc5xx_rproc.c
 create mode 100644 drivers/spi/adi_spi3.c
 create mode 100644 drivers/usb/musb-new/sc5xx.c
 create mode 100644 drivers/watchdog/adi_wdt.c
 create mode 100644 include/dt-bindings/pinctrl/adi-adsp.h

-- 
2.43.2



Re: [PATCH 10/11] spi: Add support for ADI SC5XX-family processor SPI peripherals

2024-05-15 Thread Christophe Leroy


Le 15/05/2024 à 23:57, Greg Malysa a écrit :
> [Vous ne recevez pas souvent de courriers de greg.mal...@timesys.com. 
> Découvrez pourquoi ceci est important à 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Nathan Barrett-Morrison 
> 
> This adds support for the ADI-specific SPI driver present in the ADI
> SC5xx line of SoCs. This IP block is distinct from the QSPI/OSPI block
> that uses the Cadence driver. Both may be used at once with appropriate
> pin muxing configuration.
> 
> Co-developed-by: Greg Malysa 
> Signed-off-by: Greg Malysa 
> Co-developed-by: Angelo Dureghello 
> Signed-off-by: Angelo Dureghello 
> Co-developed-by: Ian Roberts 
> Signed-off-by: Ian Roberts 
> Co-developed-by: Piotr Wojtaszczyk 
> Signed-off-by: Piotr Wojtaszczyk 
> Signed-off-by: Vasileios Bimpikas 
> Signed-off-by: Utsav Agarwal 
> Signed-off-by: Arturs Artamonovs 
> Signed-off-by: Nathan Barrett-Morrison 
> ---
> 
>   MAINTAINERS|   1 +
>   drivers/spi/Kconfig|   6 +
>   drivers/spi/Makefile   |   1 +
>   drivers/spi/adi_spi3.c | 690 +
>   4 files changed, 698 insertions(+)
>   create mode 100644 drivers/spi/adi_spi3.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8ca7da4c02..1131c85d22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -618,6 +618,7 @@ F:  drivers/net/dwc_eth_qos_adi.c
>   F: drivers/pinctrl/pinctrl-adi-adsp.c
>   F: drivers/remoteproc/adi_sc5xx_rproc.c
>   F: drivers/serial/serial_adi_uart4.c
> +F: drivers/spi/adi_spi3.c
>   F: drivers/timer/adi_sc5xx_timer.c
>   F: drivers/usb/musb-new/sc5xx.c
>   F: drivers/watchdog/adi_wdt.c
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 35030ab355..6634494d84 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -52,6 +52,12 @@ config SPI_DIRMAP
> 
>   if DM_SPI
> 
> +config ADI_SPI3
> +   bool "Enable ADI SPI Driver"
> +   help
> + Enable the ADI (Analog Devices) SPI controller driver. This
> + driver enables the support for SC5XX spi controller.
> +
>   config ALTERA_SPI
>  bool "Altera SPI driver"
>  help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 32d7bf7237..fa1b47f2f9 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -19,6 +19,7 @@ obj-y += spi.o
>   obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
>   endif
> 
> +obj-$(CONFIG_ADI_SPI3) += adi_spi3.o
>   obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
>   obj-$(CONFIG_APPLE_SPI) += apple_spi.o
>   obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
> diff --git a/drivers/spi/adi_spi3.c b/drivers/spi/adi_spi3.c
> new file mode 100644
> index 00..9e75050a89
> --- /dev/null
> +++ b/drivers/spi/adi_spi3.c
> @@ -0,0 +1,690 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * (C) Copyright 2022 - Analog Devices, Inc.
> + *
> + * Written and/or maintained by Timesys Corporation
> + *
> + * Converted to driver model by Nathan Barrett-Morrison
> + *
> + * Contact: Nathan Barrett-Morrison 
> + * Contact: Greg Malysa 
> + * Contact: Ian Roberts 
> + * Contact: Piotr Wojtaszczyk 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SPI_IDLE_VAL   0xff
> +
> +#define MAX_CTRL_CS 7
> +
> +/* SPI_CONTROL */
> +#define SPI_CTL_EN  0x0001 /* Enable */
> +#define SPI_CTL_MSTR0x0002 /* Master/Slave */
> +#define SPI_CTL_PSSE0x0004 /* controls modf error in master mode 
> */
> +#define SPI_CTL_ODM 0x0008 /* Open Drain Mode */
> +#define SPI_CTL_CPHA0x0010 /* Clock Phase */
> +#define SPI_CTL_CPOL0x0020 /* Clock Polarity */
> +#define SPI_CTL_ASSEL   0x0040 /* Slave Select Pin Control */
> +#define SPI_CTL_SELST   0x0080 /* Slave Select Polarity in transfers 
> */
> +#define SPI_CTL_EMISO   0x0100 /*Enable MISO */
> +#define SPI_CTL_SIZE0x0600 /*Word Transfer Size */
> +#define SPI_CTL_SIZE08  0x /*SIZE: 8 bits */
> +#define SPI_CTL_SIZE16  0x0200 /*SIZE: 16 bits */
> +#define SPI_CTL_SIZE32  0x0400 /*SIZE: 32 bits */
> +#define SPI_CTL_LSBF0x1000 /*LSB First */
> +#define SPI_CTL_FCEN0x2000 /*Flow-Control Enable */
> +#define SPI_CTL_FCCH0x4000 /*Flow-Control Channel Selection */
> +#define SPI_CTL_FCPL0x8000 /*Flow-Control Polarity */
> +#define SPI_CTL_FCWM0x0003 /*Flow-Control Water-Mark */
> +#define SPI_CTL_FIFO0   0x /*FCWM: Tx empty or Rx Full */
> +#define SPI_CTL_FIFO1   0x0001 /*FCWM: Tx empty or Rx full (>=75%) */
> +#define SPI_CTL_FIFO2   0x0002 /*FCWM: Tx empty or Rx full (>=50%) */
> +#define SPI_CTL_FMODE   0x0004 /*Fast-mode Enable */
> +#define SPI_CTL_MIOM0x0030 /*Multiple I/O Mode */
> +#define SPI_CTL_MIO_DIS 0x /*MIOM: Disable */
> +#define SPI_CTL_MIO_DUAL0x0010 /*MIOM: Enable DIOM 

Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing

2024-05-15 Thread Marek Vasut

On 5/16/24 12:31 AM, Tim Harvey wrote:

Hi,


(this is a resend... apologies if its a duplicate. I got some strange
bounce that mime types were included so I'm resending with the otuput
of strace cliped out)

strace was a good idea and showed me what was going on.

The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems to need both of
these:

so if I hack the path to my certs in like this it works:diff --git
a/tools/binman/etype/nxp_imx8mcst.py
b/tools/binman/etype/nxp_imx8mcst.py
index 132127ad4827..b432200960df 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -67,10 +67,11 @@ class Entry_nxp_imx8mcst(Entry_mkimage):

  def ReadNode(self):
  super().ReadNode()
+self.certpath =3D '/usr/src/nxp/cst-3.3.2/crts/';


=3D , seems like your email is acting funny today indeed.


  self.loader_address =3D fdt_util.GetInt(self._node, 'nxp,loader-ad=
dress')
  self.srk_table =3D fdt_util.GetString(self._node,
'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
-self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
-self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
+self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
self.certpath + '/CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
+self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
self.certpath + '/IMG1_1_sha256_4096_65537_v3_usr_crt.pem')


What about this:

diff --git a/tools/binman/etype/nxp_imx8mcst.py 
b/tools/binman/etype/nxp_imx8mcst.py

index 132127ad482..9ead7488a2d 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -68,9 +68,9 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
 def ReadNode(self):
 super().ReadNode()
 self.loader_address = fdt_util.GetInt(self._node, 
'nxp,loader-address')
-self.srk_table = fdt_util.GetString(self._node, 
'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
-self.csf_crt = fdt_util.GetString(self._node, 'nxp,csf-crt', 
'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
-self.img_crt = fdt_util.GetString(self._node, 'nxp,img-crt', 
'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
+self.srk_table = os.getenv('SRK_TABLE', 
fdt_util.GetString(self._node, 'nxp,srk-table', 'SRK_1_2_3_4_table.bin'))
+self.csf_crt = os.getenv('CSF_KEY', 
fdt_util.GetString(self._node, 'nxp,csf-crt', 
'CSF1_1_sha256_4096_65537_v3_usr_crt.pem'))
+self.img_crt = os.getenv('IMG_KEY', 
fdt_util.GetString(self._node, 'nxp,img-crt', 
'IMG1_1_sha256_4096_65537_v3_usr_crt.pem'))

 self.unlock = fdt_util.GetBool(self._node, 'nxp,unlock')
 self.ReadEntries()

Then you can also use the old behavior with keys supplied via env vars.

This might in fact be useful for build systems too.


  self.unlock =3D fdt_util.GetBool(self._node, 'nxp,unlock')
  self.ReadEntries()

$ make -j8
   BINMAN  .binman_stamp
   OFCHK   .config

Strace indicatest the following with the above patch:
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/crts//IMG1_1_sha256_4096_65537_v3_usr_crt.pem",
O_RDONLY)
...
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/keys//IMG1_1_sha256_4096_65537_v3_usr_key.pem",
O_RDONLY)
^^^ look how it sneakily changes the PATH!

And without the above patch using a key file without a path:
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_crt.pem", O_RDONLY)
...
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_key.pem", O_RDONLY)
ENOENT (No such file or directory)
^^^ fails

Simply copying both usr_crt.pem and usr_key.pem to the build directory
still fails:
binman: Error 1 running 'cst -i
./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
0:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:crypto/evp/evp_enc.c:612:
0:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal
error:crypto/pkcs12/p12_decr.c:62:
0:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe
crypt error:crypto/pkcs12/p12_decr.c:93:
0:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1
lib:crypto/pem/pem_pkey.c:88:

Do you not run into this and if not is it because you have put full
paths in the dtsi overriding the defaults I'm using?


I just do '$ cp -Lv /CST/{keys,crts}/* .' to copy the keys and certs 
into the build directory for testing.



Maybe this has
something to do with how my keys were generated or the version of cst
I'm using or maybe we just need to also add a 

Re: [PATCH v3] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend

2024-05-15 Thread Tim Harvey
On Fri, Apr 19, 2024 at 1:04 PM Ilias Apalodimas
 wrote:
>
> On Fri, 19 Apr 2024 at 20:52, Tim Harvey  wrote:
> >
> > On Fri, Apr 19, 2024 at 10:37 AM Ilias Apalodimas
> >  wrote:
> > >
> > > Also quickly looking at this,  you need a new function for
> > > tpm2_algorithm_to_mask() (look below)
> > >
> > > On Fri, 19 Apr 2024 at 20:20, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Fri, 19 Apr 2024 at 20:13, Tim Harvey  wrote:
> > > > >
> > > > > On Sat, Apr 6, 2024 at 9:33 AM Ilias Apalodimas
> > > > >  wrote:
> > > > > >
> > > > > > Hi Tim,
> > > > > >
> > > > > > Thanks for the patch
> > > > > >
> > > > > > I'll be away next week, I'll try to find time and take a closer 
> > > > > > look.
> > > > > > The pipeline [0] shows some TPM related failures
> > > > > >
> > > > > > [0] 
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/9b4be64e41454e17269a968397933eeff300c380
> > > > > >
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > I changed the output of 'tpm pcr_read' so that it shows the algo and
> > > > > size causing the test in test/py/tests/test_tpm2.py to fail:
> > > > > @@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl
> > > > > *cmdtp, int flag, int argc,
> > > > >
> > > > > data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> > > > >
> > > > > -   rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, 
> > > > > TPM2_ALG_SHA256,
> > > > > -  data, TPM2_DIGEST_LEN, );
> > > > > +   rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
> > > > > +  data, algo_len, );
> > > > > if (!rc) {
> > > > > -   printf("PCR #%u content (%u known updates):\n", 
> > > > > index, updates);
> > > > > -   print_byte_string(data, TPM2_DIGEST_LEN);
> > > > > +   printf("PCR #%u %s %d byte content (%u known
> > > > > updates):\n", index,
> > > > > +  tpm2_algorithm_name(algo), algo_len, updates);
> > > > > +   print_byte_string(data, algo_len);
> > > > > }
> > > > >
> > > > > failure:
> > > > > E   AssertionError: assert 'PCR #10 content' in 'PCR #10 sha256 32
> > > > > byte content (723 known updates):\r\r\n 00 00 00 00 00 00 00 00 00 00
> > > > > 00 00 00 00 00 00\r\r\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00'
> > > > >
> > > > > So I suppose I need to update test/py/tests/test_tpm2.py as well.
> > > >
> > > > Yes
> > > >
> > > > >
> > > > > Would I update test/py/tests/test_tpm2.py in the same patch as the one
> > > > > that causes the failure?
> > > >
> > > > Yes please, I'd like patches merged that won't break the CI
> > > >
> > > > >
> > > > > How do I go about running the tests manually to make sure I've 
> > > > > addressed it?
> > > >
> > > > You can send a PR against U-Boots repo (in github)
> > > >
> > > > Cheers
> > > > /Ilias
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > Tim
> > > > >
> > > > > > Cheers
> > > > > > /Ilias
> > > > > >
> > > > > > On Fri, 5 Apr 2024 at 03:17, Tim Harvey  
> > > > > > wrote:
> > > > > > >
> > > > > > > For pcr_read and pcr_extend commands allow the digest algorithm 
> > > > > > > to be
> > > > > > > specified by an additional argument. If not specified it will 
> > > > > > > default to
> > > > > > > SHA256 for backwards compatibility.
> > > > > > >
> > > > > > > A follow-on to this could be to extend all PCR banks with the 
> > > > > > > detected
> > > > > > > algo when the  argument is 'auto'.
> > > > > > >
> > > > > > > Signed-off-by: Tim Harvey 
> > > > > > > ---
> > > > > > > v3:
> > > > > > >  - replace tpm2_supported_algorithms with struct and use this to 
> > > > > > > relate hash algoirthm
> > > > > > >details
> > > > > > > v2:
> > > > > > >  - use tpm2_algorithm_to_len
> > > > > > >  - use enum tpm2_algorithms
> > > > > > >  - make function names and parameter names more consistent with 
> > > > > > > existing
> > > > > > >tpm-v2 functions
> > > > > > >  - fix various spelling errors
> > > > > > > ---
> > > > > > >  cmd/tpm-v2.c  | 49 
> > > > > > >  include/tpm-v2.h  | 67 
> > > > > > > ++-
> > > > > > >  lib/efi_loader/efi_tcg2.c |  4 +--
> > > > > > >  lib/tpm-v2.c  | 62 
> > > > > > > +++-
> > > > > > >  4 files changed, 143 insertions(+), 39 deletions(-)
> > > > > > >
> > > > > > > diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> > > > > > > index 7e479b9dfe36..2343b4d9cb9e 100644
> > > > > > > --- a/cmd/tpm-v2.c
> > > > > > > +++ b/cmd/tpm-v2.c
> > > > > > > @@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl 
> > > > > > > *cmdtp, int flag, int argc,
> > > > > > > struct tpm_chip_priv *priv;
> > > > > > > u32 index = simple_strtoul(argv[1], NULL, 0);
> > > > > > > void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 
> > > > > > > 0), 0);
> > > > > > 

[PATCH 6/6] power: pmic: sunxi: add AXP707 support

2024-05-15 Thread Andre Przywara
The X-Powers AXP707 is a PMIC with some buck converters and a larger
number of LDOs, alongside some charging and USB circuitry.

Add the descriptions for the five DC/DC regulators that we will need,
and enable that when CONFIG_AXP707_POWER is enabled. We won't need DCDC2
till DCDC4, but by using the position in the array for the index we keep
the code cleaner.

Signed-off-by: Andre Przywara 
---
 drivers/power/axp_spl.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/power/axp_spl.c b/drivers/power/axp_spl.c
index e38895c5c7d..8c9698612b5 100644
--- a/drivers/power/axp_spl.c
+++ b/drivers/power/axp_spl.c
@@ -62,6 +62,21 @@ static const struct axp_reg_desc_spl 
axp_spl_dcdc_regulators[] = {
 #define AXP_SHUTDOWN_REG   0x32
 #define AXP_SHUTDOWN_MASK  BIT(7)
 
+#elif defined(CONFIG_AXP707_POWER) /* AXP707 */
+
+static const struct axp_reg_desc_spl axp_spl_dcdc_regulators[] = {
+{ 0x10, BIT(0), 0x20, 0x1f, 1600, 3400, 100, NA },
+{ 0x10, BIT(1), 0x21, 0x7f,  500, 1300,  10, 70 },
+{ 0x10, BIT(2), 0x22, 0x7f,  500, 1300,  10, 70 },
+{ 0x10, BIT(3), 0x23, 0x7f,  500, 1300,  10, 70 },
+{ 0x10, BIT(4), 0x24, 0x7f,  800, 1840,  10, 32 },
+};
+#define AXP_CHIP_VERSION   0x3
+#define AXP_CHIP_VERSION_MASK  0xcf
+#define AXP_CHIP_ID0x81
+#define AXP_SHUTDOWN_REG   0x32
+#define AXP_SHUTDOWN_MASK  BIT(7)
+
 #else
 
#error "Please define the regulator registers in axp_spl_regulators[]."
-- 
2.35.8



[PATCH 5/6] power: pmic: sunxi: use generic AXP SPL driver for AXP305

2024-05-15 Thread Andre Przywara
The generic AXP SPL driver implementation can cover all regulators we
need for the AXP305.

Add the descriptions for four of the six DC/DC regulators of the AXP305,
and enable that when CONFIG_AXP305_POWER is enabled. We won't need DCDC2
and DCDC3, but by using the position in the array for the index we keep
the code cleaner.
Also remove the old driver, and switch the Makefile to include the new,
generic driver.

Signed-off-by: Andre Przywara 
---
 drivers/power/Makefile  |  2 +-
 drivers/power/axp305.c  | 82 -
 drivers/power/axp_spl.c | 15 
 3 files changed, 16 insertions(+), 83 deletions(-)
 delete mode 100644 drivers/power/axp305.c

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 30e0daf0621..8d36f87ed32 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -12,7 +12,7 @@ ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_AXP152_POWER) += axp152.o
 obj-$(CONFIG_AXP209_POWER) += axp209.o
 obj-$(CONFIG_AXP221_POWER) += axp221.o
-obj-$(CONFIG_AXP305_POWER) += axp305.o
+obj-$(CONFIG_AXP305_POWER) += axp_spl.o
 obj-$(CONFIG_AXP313_POWER) += axp_spl.o
 obj-$(CONFIG_AXP717_POWER) += axp_spl.o
 obj-$(CONFIG_AXP809_POWER) += axp809.o
diff --git a/drivers/power/axp305.c b/drivers/power/axp305.c
deleted file mode 100644
index 0312ad9af76..000
--- a/drivers/power/axp305.c
+++ /dev/null
@@ -1,82 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * AXP305 driver
- *
- * (C) Copyright 2020 Jernej Skrabec 
- *
- * Based on axp221.c
- * (C) Copyright 2014 Hans de Goede 
- * (C) Copyright 2013 Oliver Schinagl 
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#define AXP305_DCDC4_1600MV_OFFSET 46
-
-static u8 axp305_mvolt_to_cfg(int mvolt, int min, int max, int div)
-{
-   if (mvolt < min)
-   mvolt = min;
-   else if (mvolt > max)
-   mvolt = max;
-
-   return  (mvolt - min) / div;
-}
-
-int axp_set_dcdc4(unsigned int mvolt)
-{
-   int ret;
-   u8 cfg;
-
-   if (mvolt >= 1600)
-   cfg = AXP305_DCDC4_1600MV_OFFSET +
-   axp305_mvolt_to_cfg(mvolt, 1600, 3300, 100);
-   else
-   cfg = axp305_mvolt_to_cfg(mvolt, 600, 1500, 20);
-
-   if (mvolt == 0)
-   return pmic_bus_clrbits(AXP305_OUTPUT_CTRL1,
-   AXP305_OUTPUT_CTRL1_DCDCD_EN);
-
-   ret = pmic_bus_write(AXP305_DCDCD_VOLTAGE, cfg);
-   if (ret)
-   return ret;
-
-   return pmic_bus_setbits(AXP305_OUTPUT_CTRL1,
-   AXP305_OUTPUT_CTRL1_DCDCD_EN);
-}
-
-int axp_init(void)
-{
-   u8 axp_chip_id;
-   int ret;
-
-   ret = pmic_bus_init();
-   if (ret)
-   return ret;
-
-   ret = pmic_bus_read(AXP305_CHIP_VERSION, _chip_id);
-   if (ret)
-   return ret;
-
-   if ((axp_chip_id & AXP305_CHIP_VERSION_MASK) != 0x40)
-   return -ENODEV;
-
-   return ret;
-}
-
-#if !CONFIG_IS_ENABLED(ARM_PSCI_FW) && 
!IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
-int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
-{
-   pmic_bus_write(AXP305_SHUTDOWN, AXP305_POWEROFF);
-
-   /* infinite loop during shutdown */
-   while (1) {}
-
-   /* not reached */
-   return 0;
-}
-#endif
diff --git a/drivers/power/axp_spl.c b/drivers/power/axp_spl.c
index f72d106315e..e38895c5c7d 100644
--- a/drivers/power/axp_spl.c
+++ b/drivers/power/axp_spl.c
@@ -47,6 +47,21 @@ static const struct axp_reg_desc_spl 
axp_spl_dcdc_regulators[] = {
 #define AXP_SHUTDOWN_REG   0x1a
 #define AXP_SHUTDOWN_MASK  BIT(7)
 
+#elif defined(CONFIG_AXP305_POWER) /* AXP305 */
+
+static const struct axp_reg_desc_spl axp_spl_dcdc_regulators[] = {
+{ 0x10, BIT(0), 0x12, 0x7f,  600, 1520,  10, 50 },
+{ 0x10, BIT(1), 0x13, 0x1f, 1000, 2550,  50, NA },
+{ 0x10, BIT(2), 0x14, 0x7f,  600, 1520,  10, 50 },
+{ 0x10, BIT(3), 0x15, 0x3f,  600, 1500,  20, NA },
+{ 0x10, BIT(4), 0x16, 0x1f, 1100, 3400, 100, NA },
+};
+#define AXP_CHIP_VERSION   0x3
+#define AXP_CHIP_VERSION_MASK  0xcf
+#define AXP_CHIP_ID0x40
+#define AXP_SHUTDOWN_REG   0x32
+#define AXP_SHUTDOWN_MASK  BIT(7)
+
 #else
 
#error "Please define the regulator registers in axp_spl_regulators[]."
-- 
2.35.8



[PATCH 4/6] power: pmic: sunxi: use generic AXP SPL driver for AXP313

2024-05-15 Thread Andre Przywara
The generic AXP SPL driver implementation can cover all regulators we
need for the AXP313.

Add the descriptions for the three DC/DC regulators of the AXP313, and
enable that when CONFIG_AXP313_POWER is enabled. Also remove the old
driver, and switch the Makefile to include the new, generic version.

Signed-off-by: Andre Przywara 
---
 drivers/power/Makefile  |   2 +-
 drivers/power/axp313.c  | 133 
 drivers/power/axp_spl.c |  13 
 3 files changed, 14 insertions(+), 134 deletions(-)
 delete mode 100644 drivers/power/axp313.c

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 6df23a81c29..30e0daf0621 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_AXP152_POWER)+= axp152.o
 obj-$(CONFIG_AXP209_POWER) += axp209.o
 obj-$(CONFIG_AXP221_POWER) += axp221.o
 obj-$(CONFIG_AXP305_POWER) += axp305.o
-obj-$(CONFIG_AXP313_POWER) += axp313.o
+obj-$(CONFIG_AXP313_POWER) += axp_spl.o
 obj-$(CONFIG_AXP717_POWER) += axp_spl.o
 obj-$(CONFIG_AXP809_POWER) += axp809.o
 obj-$(CONFIG_AXP818_POWER) += axp818.o
diff --git a/drivers/power/axp313.c b/drivers/power/axp313.c
deleted file mode 100644
index 09ecb5b1ec2..000
--- a/drivers/power/axp313.c
+++ /dev/null
@@ -1,133 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * AXP313(a) driver
- *
- * (C) Copyright 2023 Arm Ltd.
- *
- * Based on axp305.c
- * (C) Copyright 2020 Jernej Skrabec 
- * (C) Copyright 2014 Hans de Goede 
- * (C) Copyright 2013 Oliver Schinagl 
- */
-
-#include 
-#include 
-#include 
-#include 
-
-enum axp313_reg {
-   AXP313_CHIP_VERSION = 0x03,
-   AXP313_OUTPUT_CTRL  = 0x10,
-   AXP313_DCDC1_CTRL   = 0x13,
-   AXP313_SHUTDOWN = 0x1a,
-};
-
-#define AXP313_CHIP_VERSION_MASK   0xcf
-#define AXP313_CHIP_VERSION_AXP15300x48
-#define AXP313_CHIP_VERSION_AXP313A0x4b
-#define AXP313_CHIP_VERSION_AXP313B0x4c
-
-#define AXP313_DCDC_SPLIT_OFFSET   71
-#define AXP313_DCDC_SPLIT_MVOLT1200
-
-#define AXP313_POWEROFFBIT(7)
-
-static u8 mvolt_to_cfg(int mvolt, int min, int max, int div)
-{
-   if (mvolt < min)
-   mvolt = min;
-   else if (mvolt > max)
-   mvolt = max;
-
-   return (mvolt - min) / div;
-}
-
-static int axp_set_dcdc(int dcdc_num, unsigned int mvolt)
-{
-   int ret;
-   u8 cfg, enable_mask = 1U << (dcdc_num - 1);
-   int volt_reg = AXP313_DCDC1_CTRL + dcdc_num - 1;
-   int max_mV;
-
-   switch (dcdc_num) {
-   case 1:
-   case 2:
-   max_mV  = 1540;
-   break;
-   case 3:
-   /*
-* The manual defines a different split point, but tests
-* show that it's the same 1200mV as for DCDC1/2.
-*/
-   max_mV  = 1840;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (mvolt > AXP313_DCDC_SPLIT_MVOLT)
-   cfg = AXP313_DCDC_SPLIT_OFFSET + mvolt_to_cfg(mvolt,
-   AXP313_DCDC_SPLIT_MVOLT + 20, max_mV, 20);
-   else
-   cfg = mvolt_to_cfg(mvolt, 500, AXP313_DCDC_SPLIT_MVOLT, 10);
-
-   if (mvolt == 0)
-   return pmic_bus_clrbits(AXP313_OUTPUT_CTRL, enable_mask);
-
-   debug("DCDC%d: writing 0x%x to reg 0x%x\n", dcdc_num, cfg, volt_reg);
-   ret = pmic_bus_write(volt_reg, cfg);
-   if (ret)
-   return ret;
-
-   return pmic_bus_setbits(AXP313_OUTPUT_CTRL, enable_mask);
-}
-
-int axp_set_dcdc2(unsigned int mvolt)
-{
-   return axp_set_dcdc(2, mvolt);
-}
-
-int axp_set_dcdc3(unsigned int mvolt)
-{
-   return axp_set_dcdc(3, mvolt);
-}
-
-int axp_init(void)
-{
-   u8 axp_chip_id;
-   int ret;
-
-   ret = pmic_bus_init();
-   if (ret)
-   return ret;
-
-   ret = pmic_bus_read(AXP313_CHIP_VERSION, _chip_id);
-   if (ret)
-   return ret;
-
-   axp_chip_id &= AXP313_CHIP_VERSION_MASK;
-   switch (axp_chip_id) {
-   case AXP313_CHIP_VERSION_AXP1530:
-   case AXP313_CHIP_VERSION_AXP313A:
-   case AXP313_CHIP_VERSION_AXP313B:
-   break;
-   default:
-   debug("unknown PMIC: 0x%x\n", axp_chip_id);
-   return -EINVAL;
-   }
-
-   return ret;
-}
-
-#if !CONFIG_IS_ENABLED(ARM_PSCI_FW) && 
!IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
-int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
-{
-   pmic_bus_write(AXP313_SHUTDOWN, AXP313_POWEROFF);
-
-   /* infinite loop during shutdown */
-   while (1) {}
-
-   /* not reached */
-   return 0;
-}
-#endif
diff --git a/drivers/power/axp_spl.c b/drivers/power/axp_spl.c
index 36eb6bd0b2a..f72d106315e 100644
--- a/drivers/power/axp_spl.c
+++ b/drivers/power/axp_spl.c
@@ -34,6 +34,19 @@ static const struct axp_reg_desc_spl 

[PATCH 3/6] power: pmic: sunxi: replace AXP717 SPL driver

2024-05-15 Thread Andre Przywara
We now have a generic AXP SPL driver implementation, that already covers
the DC/DC converters of the AXP717 PMIC.

Remove the old, dedicated driver and switch to the new generic driver.
This should not introduce any change in behaviour.

Signed-off-by: Andre Przywara 
---
 drivers/power/Makefile |  2 +-
 drivers/power/axp717.c | 92 --
 2 files changed, 1 insertion(+), 93 deletions(-)
 delete mode 100644 drivers/power/axp717.c

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 9d1f4c65262..6df23a81c29 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_AXP209_POWER)+= axp209.o
 obj-$(CONFIG_AXP221_POWER) += axp221.o
 obj-$(CONFIG_AXP305_POWER) += axp305.o
 obj-$(CONFIG_AXP313_POWER) += axp313.o
-obj-$(CONFIG_AXP717_POWER) += axp717.o
+obj-$(CONFIG_AXP717_POWER) += axp_spl.o
 obj-$(CONFIG_AXP809_POWER) += axp809.o
 obj-$(CONFIG_AXP818_POWER) += axp818.o
 endif
diff --git a/drivers/power/axp717.c b/drivers/power/axp717.c
deleted file mode 100644
index 7c77c09ea8f..000
--- a/drivers/power/axp717.c
+++ /dev/null
@@ -1,92 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * AXP717 SPL driver
- * (C) Copyright 2024 Arm Ltd.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-enum axp717_reg {
-   AXP717_CHIP_VERSION = 0x3,
-   AXP717_SHUTDOWN = 0x27,
-   AXP717_OUTPUT_CTRL1 = 0x80,
-   AXP717_DCDC1_VOLTAGE = 0x83,
-};
-
-#define AXP717_CHIP_VERSION_MASK   0xc8
-#define AXP717_DCDC_1220MV_OFFSET  71
-#define AXP717_POWEROFF(1U << 0)
-#define DCDC_DVM_ENABLE(1U << 7)
-
-static u8 axp_mvolt_to_cfg(int mvolt, int min, int max, int div)
-{
-   if (mvolt < min)
-   mvolt = min;
-   else if (mvolt > max)
-   mvolt = max;
-
-   return (mvolt - min) / div;
-}
-
-static int axp_set_dcdc(int dcdc_num, unsigned int mvolt)
-{
-   int ret;
-   u8 cfg = DCDC_DVM_ENABLE;
-
-   if (dcdc_num < 1 || dcdc_num > 3)
-   return -EINVAL;
-
-   if (mvolt >= 1220)
-   cfg |= AXP717_DCDC_1220MV_OFFSET +
-   axp_mvolt_to_cfg(mvolt, 1220,
-dcdc_num == 3 ? 1840 : 1540, 20);
-   else
-   cfg |= axp_mvolt_to_cfg(mvolt, 500, 1200, 10);
-
-   if (mvolt == 0)
-   return pmic_bus_clrbits(AXP717_OUTPUT_CTRL1,
-   1U << (dcdc_num -1));
-
-   ret = pmic_bus_write(AXP717_DCDC1_VOLTAGE + dcdc_num - 1, cfg);
-   if (ret)
-   return ret;
-
-   return pmic_bus_setbits(AXP717_OUTPUT_CTRL1, 1U << (dcdc_num - 1));
-}
-
-int axp_set_dcdc1(unsigned int mvolt)
-{
-   return axp_set_dcdc(1, mvolt);
-}
-
-int axp_set_dcdc2(unsigned int mvolt)
-{
-   return axp_set_dcdc(2, mvolt);
-}
-
-int axp_set_dcdc3(unsigned int mvolt)
-{
-   return axp_set_dcdc(3, mvolt);
-}
-
-int axp_init(void)
-{
-   return pmic_bus_init();
-}
-
-#if !CONFIG_IS_ENABLED(ARM_PSCI_FW) && 
!IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
-int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
-{
-   pmic_bus_setbits(AXP717_SHUTDOWN, AXP717_POWEROFF);
-
-   /* infinite loop during shutdown */
-   while (1) {}
-
-   /* not reached */
-   return 0;
-}
-#endif
-- 
2.35.8



[PATCH 2/6] power: pmic: sunxi: introduce generic SPL AXP DC/DC driver

2024-05-15 Thread Andre Przywara
So far we had a separate driver file for each AXP PMIC chip that we need
to support in the SPL. The code in there was largely similar, but
differed in many details.

Based on the idea of the DM AXP driver, introduce a data structure to
describe each regulator in a compact way. This is a simplified version
of the struct used in the DM driver, as we don't need to support the full
voltage range and not every regulator in the SPL.
For now we only support the DC/DC buck converters, since that's what we
need the SPL to configure, mostly. Also we get rid of the regulator name,
and hardcode the regulator number by its position in the array (first is
DCDC1, second is DCDC2, etc). We also drop support for the value table,
we ideally won't need that for the subset of regulators required.
At the end each regulator is described by a 10 bytes struct, so we avoid
blowing up the SPL footprint, but still can use generic code.

Each chip is supposed to be described separately, and protected by
ifdef's, to only build in the regulators needed for a particular board.
We also describe the bits to help identifying the AXP chip, and the
shutdown details in that section.

Add a generic driver, that exports axp_set_dcdc() functions to set up
the buck converters. For now this just contains the bits for the (new)
AXP717, but it's not wired up anywhere yet.

Signed-off-by: Andre Przywara 
---
 drivers/power/axp_spl.c | 141 
 1 file changed, 141 insertions(+)
 create mode 100644 drivers/power/axp_spl.c

diff --git a/drivers/power/axp_spl.c b/drivers/power/axp_spl.c
new file mode 100644
index 000..36eb6bd0b2a
--- /dev/null
+++ b/drivers/power/axp_spl.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * AXP PMIC SPL driver
+ * (C) Copyright 2024 Arm Ltd.
+ */
+
+#include 
+#include 
+#include 
+
+struct axp_reg_desc_spl {
+   u8  enable_reg;
+   u8  enable_mask;
+   u8  volt_reg;
+   u8  volt_mask;
+   u16 min_mV;
+   u16 max_mV;
+   u8  step_mV;
+   u8  split;
+};
+
+#define NA 0xff
+
+#if defined(CONFIG_AXP717_POWER)   /* AXP717 */
+
+static const struct axp_reg_desc_spl axp_spl_dcdc_regulators[] = {
+   { 0x80, BIT(0), 0x83, 0x7f,  500, 1540,  10, 70 },
+   { 0x80, BIT(1), 0x84, 0x7f,  500, 1540,  10, 70 },
+   { 0x80, BIT(2), 0x85, 0x7f,  500, 1840,  10, 70 },
+};
+#define AXP_CHIP_VERSION   0x0
+#define AXP_CHIP_VERSION_MASK  0x0
+#define AXP_CHIP_ID0x0
+#define AXP_SHUTDOWN_REG   0x27
+#define AXP_SHUTDOWN_MASK  BIT(0)
+
+#else
+
+   #error "Please define the regulator registers in axp_spl_regulators[]."
+
+#endif
+
+static u8 axp_mvolt_to_cfg(int mvolt, const struct axp_reg_desc_spl *reg)
+{
+   if (mvolt < reg->min_mV)
+   mvolt = reg->min_mV;
+   else if (mvolt > reg->max_mV)
+   mvolt = reg->max_mV;
+
+   mvolt -= reg->min_mV;
+
+   /* voltage in the first range ? */
+   if (mvolt <= reg->split * reg->step_mV)
+   return mvolt / reg->step_mV;
+
+   mvolt -= reg->split * reg->step_mV;
+
+   return reg->split + mvolt / (reg->step_mV * 2);
+}
+
+static int axp_set_dcdc(int dcdc_num, unsigned int mvolt)
+{
+   const struct axp_reg_desc_spl *reg;
+   int ret;
+
+   if (dcdc_num < 1 || dcdc_num > ARRAY_SIZE(axp_spl_dcdc_regulators))
+   return -EINVAL;
+
+   reg = _spl_dcdc_regulators[dcdc_num - 1];
+
+
+   if (mvolt == 0)
+   return pmic_bus_clrbits(reg->enable_reg, reg->enable_mask);
+
+   ret = pmic_bus_write(reg->volt_reg, axp_mvolt_to_cfg(mvolt, reg));
+   if (ret)
+   return ret;
+
+   return pmic_bus_setbits(reg->enable_reg, reg->enable_mask);
+}
+
+int axp_set_dcdc1(unsigned int mvolt)
+{
+   return axp_set_dcdc(1, mvolt);
+}
+
+int axp_set_dcdc2(unsigned int mvolt)
+{
+   return axp_set_dcdc(2, mvolt);
+}
+
+int axp_set_dcdc3(unsigned int mvolt)
+{
+   return axp_set_dcdc(3, mvolt);
+}
+
+int axp_set_dcdc4(unsigned int mvolt)
+{
+   return axp_set_dcdc(4, mvolt);
+}
+
+int axp_set_dcdc5(unsigned int mvolt)
+{
+   return axp_set_dcdc(5, mvolt);
+}
+
+int axp_init(void)
+{
+   int ret = pmic_bus_init();
+
+   if (ret)
+   return ret;
+
+   if (AXP_CHIP_VERSION_MASK) {
+   u8 axp_chip_id;
+
+   ret = pmic_bus_read(AXP_CHIP_VERSION, _chip_id);
+   if (ret)
+   return ret;
+
+   if ((axp_chip_id & AXP_CHIP_VERSION_MASK) != AXP_CHIP_ID) {
+   debug("unknown PMIC: 0x%x\n", axp_chip_id);
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+
+#if !CONFIG_IS_ENABLED(ARM_PSCI_FW) && 
!IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
+int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+   pmic_bus_setbits(AXP_SHUTDOWN_REG, 

[PATCH 1/6] power: pmic: sunxi: only build AXP drivers for SPL

2024-05-15 Thread Andre Przywara
The axp.c drivers are only used for the SPL, for U-Boot proper we
have a separate, DM compliant driver.
Mask the build instructions with CONFIG_SPL_BUILD, to avoid them being
build for U-Boot proper as well.

Signed-off-by: Andre Przywara 
---
 drivers/power/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 41ebb494fff..9d1f4c65262 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_$(SPL_TPL_)POWER_DOMAIN) += domain/
 obj-y += pmic/
 obj-y += regulator/
 
+ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_AXP152_POWER) += axp152.o
 obj-$(CONFIG_AXP209_POWER) += axp209.o
 obj-$(CONFIG_AXP221_POWER) += axp221.o
@@ -16,6 +17,7 @@ obj-$(CONFIG_AXP313_POWER)+= axp313.o
 obj-$(CONFIG_AXP717_POWER) += axp717.o
 obj-$(CONFIG_AXP809_POWER) += axp809.o
 obj-$(CONFIG_AXP818_POWER) += axp818.o
+endif
 obj-$(CONFIG_EXYNOS_TMU)   += exynos-tmu.o
 obj-$(CONFIG_SY8106A_POWER)+= sy8106a.o
 obj-$(CONFIG_TPS6586X_POWER)   += tps6586x.o
-- 
2.35.8



[PATCH 0/6] power: pmic: sunxi: consolidate AXP SPL drivers

2024-05-15 Thread Andre Przywara
Hi,

this is the first series in an attempt to clean up the X-Powers AXP PMIC
drivers used by the SPL for sunxi boards. So far we have a separate
driver file for each AXP variant, but the code was largely the same,
just differing by the regulator ranges.

This adds a new generic driver, which reads the regulator description
from an array of structs. This is similar to how the DM AXP driver used
for U-Boot proper works, but is simplified, since we won't need the full
feature set for the SPL, and we want to keep the code size small.

To help bisect-ability, and to simplify review, each of the simpler AXP
drivers covered by this approach is handled in a separate patch.
We just convert the AXP313, AXP305, AXP717 for now, and on the way add
support for the AXP707, just because it's now very easy, and we will
need it soon enough.
The other AXP SPL drivers are more complex, and support more regulators,
but my hunch is that we really just need the DC/DC converters in the
SPL. However I need to prove and test this, so I will convert the other
AXP chips later.

Please have a look and comment whether the approach in general is a good
idea.

Cheers,
Andre

Andre Przywara (6):
  power: pmic: sunxi: only build AXP drivers for SPL
  power: pmic: sunxi: introduce generic SPL AXP DC/DC driver
  power: pmic: sunxi: replace AXP717 SPL driver
  power: pmic: sunxi: use generic AXP SPL driver for AXP313
  power: pmic: sunxi: use generic AXP SPL driver for AXP305
  power: pmic: sunxi: add AXP707 support

 drivers/power/Makefile  |   8 +-
 drivers/power/axp305.c  |  82 --
 drivers/power/axp313.c  | 133 -
 drivers/power/axp717.c  |  92 
 drivers/power/axp_spl.c | 184 
 5 files changed, 189 insertions(+), 310 deletions(-)
 delete mode 100644 drivers/power/axp305.c
 delete mode 100644 drivers/power/axp313.c
 delete mode 100644 drivers/power/axp717.c
 create mode 100644 drivers/power/axp_spl.c

-- 
2.35.8



Re: [PATCH 1/5] net: eth-uclass: guard against reentrant eth_init()/eth_halt() calls

2024-05-15 Thread Tom Rini
On Fri, 26 Apr 2024 10:02:24 +0200, Matthias Schiffer wrote:

> With netconsole, any log message can result in an eth_init(), possibly
> causing an reentrant call into eth_init() if a driver's ops print
> anything:
> 
> eth_init() -> driver.start() -> printf() -> netconsole -> eth_init()
> eth_halt() -> driver.stop() -> printf() -> netconsole -> eth_init()
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 0/4] Add remoteproc driver for AM62a SoC

2024-05-15 Thread Tom Rini
On Thu, 09 May 2024 09:20:33 -0500, Hari Nagalla wrote:

> This series adds relevant ip data in remoteproc driver for AM62a devices.
> 
> Logs: https://paste.sr.ht/~hnagalla/5e20838705c1d688bca81886dad56451b56d3913
> 
> Hari Nagalla (4):
>   remoteproc: k3-dsp: Enable C71x support for AM62A
>   remoteproc: k3-r5: Add support for R5F core on AM62A SoCs
>   configs: am62ax: enable remote proc drivers
>   board: ti: am62ax: Add support for remote proc load
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH v5 0/6] Add DFU and usb boot for TI am62x SK and beagleplay

2024-05-15 Thread Tom Rini
On Mon, 06 May 2024 15:38:40 +0100, Martyn Welch wrote:

> This series adds DFU support for TI AM62 SK and beagleplay boards.
> 
> I have picked this series up from Sjoerd due to time constraints.
> 
> Since the last revision:
> * Removed dwc3 mode setting in favour of reinstating forced peripheral
>   mode for usb0
> * Use of config fragments for both r5 and a53 DFU configuration to
>   reduce duplication
> * Typographical improvements to documentation
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 1/1] arm: dts: k3-j7200: Move to OF_UPSTREAM

2024-05-15 Thread Tom Rini
On Mon, May 06, 2024 at 07:18:34PM +0530, Aniket Limaye wrote:

> Move to using OF_UPSTREAM config and thus using the devicetree-rebasing
> subtree.
> 
> Signed-off-by: Aniket Limaye 
> ---
>  arch/arm/dts/Makefile |1 -
>  .../k3-j7200-common-proc-board-u-boot.dtsi|   16 +-
>  arch/arm/dts/k3-j7200-common-proc-board.dts   |  396 -
>  arch/arm/dts/k3-j7200-main.dtsi   | 1284 -
>  arch/arm/dts/k3-j7200-mcu-wakeup.dtsi |  647 -
>  arch/arm/dts/k3-j7200-som-p0.dtsi |  327 -
>  arch/arm/dts/k3-j7200-thermal.dtsi|   47 -
>  arch/arm/dts/k3-j7200.dtsi|  164 ---
>  configs/j7200_evm_a72_defconfig   |3 +-
>  9 files changed, 8 insertions(+), 2877 deletions(-)
>  delete mode 100644 arch/arm/dts/k3-j7200-common-proc-board.dts
>  delete mode 100644 arch/arm/dts/k3-j7200-main.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-som-p0.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200.dtsi

This no longer applies cleanly to -next, please rebase, thanks.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v3] tpm: display warning if using gpio reset with TPM

2024-05-15 Thread Tim Harvey
Instead of displaying what looks like an error message if a
gpio-reset dt prop is missing for a TPM display a warning that
having a gpio reset on a TPM should not be used for a secure production
device.

TCG TIS spec [1] says:
"The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
platform CPU Reset signal such that it complies with the requirements
specified in section 1.2.7 HOST Platform Reset in the PC Client
Implementation Specification for Conventional BIOS."

The reasoning is that you should not be able to toggle a GPIO and reset
the TPM without resetting the CPU as well because if an attacker can
break into your OS via an OS level security flaw they can then reset the
TPM via GPIO and replay the measurements required to unseal keys
that you have otherwise protected.

Additionally restructure the code for improved readability allowing for
removal of the init label.

Before:
 - board with no reset gpio
u-boot=> tpm init && tpm info
tpm_tis_spi_probe: missing reset GPIO
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
 - board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]

After:
 - board with no reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
 - board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1: TPM gpio reset should not be used on secure production devices
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]

[1] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf

Signed-off-by: Tim Harvey 
---
v3: restructure code for improved readability (recommended by Miquel)
v2: change the message to a warning
---
 drivers/tpm/tpm2_tis_spi.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 28079b5039a3..b0fe97ab1d08 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -237,19 +237,22 @@ static int tpm_tis_spi_probe(struct udevice *dev)
/* legacy reset */
ret = gpio_request_by_name(dev, "gpio-reset", 0,
   _gpio, GPIOD_IS_OUT);
-   if (ret) {
+   if (!ret) {
log(LOGC_NONE, LOGL_NOTICE,
-   "%s: missing reset GPIO\n", __func__);
-   goto init;
+   "%s: gpio-reset is deprecated\n", __func__);
}
-   log(LOGC_NONE, LOGL_NOTICE,
-   "%s: gpio-reset is deprecated\n", __func__);
}
-   dm_gpio_set_value(_gpio, 1);
-   mdelay(1);
-   dm_gpio_set_value(_gpio, 0);
+
+   if (!ret) {
+   log(LOGC_NONE, LOGL_WARNING,
+   "%s: TPM gpio reset should not be used on secure 
production devices\n",
+   dev->name);
+   dm_gpio_set_value(_gpio, 1);
+   mdelay(1);
+   dm_gpio_set_value(_gpio, 0);
+   }
}
-init:
+
/* Ensure a minimum amount of time elapsed since reset of the TPM */
mdelay(drv_data->time_before_first_cmd_ms);
 
-- 
2.25.1



Re: [PATCH] imx: hab: add documentation about the required keys/certs

2024-05-15 Thread Tim Harvey
On Tue, May 14, 2024 at 11:50 AM Tim Harvey  wrote:
>
> On Sun, May 12, 2024 at 10:08 PM Marek Vasut  wrote:
> >
> > On 5/8/24 9:23 AM, Claudius Heine wrote:
> > > Hi Marek,
> >
> > Hi,
> >
> > > On 2024-05-07 3:28 pm, Marek Vasut wrote:
> > >> On 5/7/24 3:06 PM, Claudius Heine wrote:
> > >>> For CST to find the certificates and keys for signing, some keys and
> > >>> certs need to be copied into the u-boot build directory.
> > >>
> > >> Make sure to CC "NXP i.MX U-Boot Team" , else NXP is not informed. Use
> > >> scripts/get_maintainer to get the full list or just reuse the CC list
> > >> from patches in this thread.
> > >
> > > I send the patch with `--to-cmd scripts/get_maintainer.pl`, maybe I
> > > should have used `--cc-cmd`, but that would not change the list of
> > > recipients.
> >
> > Should now be fixed in
> > [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry
> >
> > >>> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> index ce1de659d8..42214df21a 100644
> > >>> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> @@ -144,6 +144,22 @@ The signing is activated by wrapping SPL and
> > >>> fitImage sections into nxp-imx8mcst
> > >>>   etype, which is done automatically in
> > >>> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
> > >>>   in case CONFIG_IMX_HAB Kconfig symbol is enabled.
> > >>> +Per default the HAB keys and certificates need to be located in the
> > >>> build
> > >>> +directory, this means copying the following files from the HAB keys
> > >>> directory
> > >>> +flat (e.g. removing the `keys` and `cert` subdirectory) into the
> > >>> u-boot build
> > >>> +directory for the CST Code Signing Tool to locate them:
> > >>
> > >> Do symlink(s) work too ?
> > >
> > > I have not tested it, but I don't see any reason why it would not. I
> > > also don't see a reason for mentioning it. I want to keep it simple, if
> > > the dev whats to do things differently, they are free to do so.
> >
> > "
> > Per default the HAB keys and certificates need to be located in the
> > build directory, this means {+creating a symbolic link or +}copying the
> > following...
> > "
> >
> > Please test it and add it in V2 if it works, I think symlink is better
> > than bluntly copying files around, esp. for crypto material.
>
> Hi Marek and Claudius,
>
> Yes, this documentation is needed as well but I'm still unclear why
> the old method before this series did not require the usr_key.pem
> files, why I don't have the *usr_key.pem files in my crts dir created
> (long ago) with cst-3.3.1 and cst-3.3.2, and what I need to do to
> generate them now that they are apparently needed.
>
> Best Regards,
>
> Tim
>
> >
> > >>> +- `crts/SRK_1_2_3_4_table.bin`
> > >>> +- `crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem`
> > >>> +- `keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem`
> > >>> +- `crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem`
> > >>> +- `keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem`
> > >>> +- `keys/key_pass.txt`
> > >>> +
> > >>> +The paths to the SRK table and the certificates can be modified via
> > >>> changes to
> > >>> +the nxp_imx8mcst device tree node
> > >>
> > >> "nodes", plural, there are two, one for SPL and one for fitImage.
> > >
> > > Well, I was thinking here more generally about the node type and was
> > > assuming that the person reading this knows how many they have of that
> > > type. But I can add a `s` in v2.
> >
> > Use "node(s)" which covers both options.
> >
> > >> It would be good to mention the DT properties which govern the crypto
> > >> material paths -- nxp,srk-table, nxp,csf-crt, nxp,img-crt -- somewhere
> > >> around this sentence.
> > >
> > > This is something that should be documented with the changes where that
> > > code was added, IMO. I only documented here what I found out and have
> > > used myself, I haven't used those.
> > >
> > > I would be interested in reading how to best overwrite those paths and
> > > the image structured from board u-boot.dtsi files myself.
> > >
> > > If you want to can pickup my patch and integrate it into your series and
> > > extend it.
> >
> > I'll keep it in mind for V3.

Hi Marek,

The documentation patch here by Claudius does resolve my issues
discussed in the other thread and I can confirm symlinks work fine so
I think something like the following should be added:

CST_DIR=/usr/src/cst-3.3.2/
ln -s $CST_DIR/crts .
ln -s $CST_DIR/keys .

then with the following change to nxp_imx8mcst.py you can build a
signed image without code modification:
diff --git a/tools/binman/etype/nxp_imx8mcst.py
b/tools/binman/etype/nxp_imx8mcst.py
index 132127ad4827..7d8abc78fc89 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -68,9 +68,9 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
 def ReadNode(self):
 super().ReadNode()
 self.loader_address = fdt_util.GetInt(self._node, 

Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing

2024-05-15 Thread Tim Harvey
On Tue, May 14, 2024 at 1:58 PM Marek Vasut  wrote:
>
> On 5/14/24 8:34 PM, Tim Harvey wrote:
>
> Hi,
>
> >> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt 
> >> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> index e16e5410bd9..ce1de659d8c 100644
> >> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> @@ -121,6 +121,9 @@ build configuration:
> >>   - Defconfig:
> >>
> >> CONFIG_IMX_HAB=y
> >> +  CONFIG_FSL_CAAM=y
> >> +  CONFIG_ARCH_MISC_INIT=y
> >> +  CONFIG_SPL_CRYPTO=y
> >>
> >
> > Hi Marek,
> >
> > Thanks for wrapping the dts bits with a config item.
> >
> > Is there any other reason to build with CONFIG_IMX_HAB than to use a
> > signed image? I see that there are several ARCH_MX6 and ARCH_MX7
> > configs that have this enabled (not ARCH_IMX8M so this certainly
> > doesn't break anything) and I'm not sure what the value of that is.
>
> I think those few either enabled in preemptively in anticipation of
> possibly using HAB, or are wrong. I suspect it should be disabled for
> those, as it only adds to the board boot time and I am not even sure if
> those machines would boot correctly.
>
> Francesco, maybe you do have MX7 Colibri ?
>
> > I notice that FSL_CAAM is selected when you select IMX_HAB... is there
> > any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
> > IMX_HAB as well (future patch perhaps)?
>
> ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
> on MX8M I think . As for SPL_CRYPTO, that should be selected by
> SPL_FSL_CAAM I think.
>
> >>   - Kconfig:
> >>
> >
> > We definitely need to describe the additional requirements here. Maybe
> > something like:
> >
> > - Tools:
> > cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
> >
> > - Files: (created with NXP IMX_CST_TOOL)
> > SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
> > CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): 
> > CSF_KEY
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): 
> > IMG_KEY
> >
> > The following works fine for me on v2024.01
> > export CST_DIR=/usr/src/nxp/cst-3.3.2/
> > export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> > export PATH=$CST_DIR/linux64/bin:$PATH
> > make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
> >
> > But with the above defines and your series this fails:
> > ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
> > ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > make
> >BINMAN  .binman_stamp
> > Wrote map file './image.map' to show errors
> > binman: Error 1 running 'cst -i
> > ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
> > Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
> > 0:error:02001002:system library:fopen:No such file or
> > directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
> > pem','r')
> > 0:error:20074002:BIO routines:file_ctrl:system 
> > lib:crypto/bio/bss_file.c:290:
> >
> > make: *** [Makefile:1126: .binman_stamp] Error 1
> >
> > So how is it that the default for nxp,img-crt
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
> > IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
> > vs ln them.
> >
> > So what am I missing here?
>
> I think CST is using both the certificate and the key files. Try and run
> strace on the CST to test that:
>
> $ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst@0

Hi Marek,

(this is a resend... apologies if its a duplicate. I got some strange
bounce that mime types were included so I'm resending with the otuput
of strace cliped out)

strace was a good idea and showed me what was going on.

The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems to need both of
these:

so if I hack the path to my certs in like this it works:diff --git
a/tools/binman/etype/nxp_imx8mcst.py
b/tools/binman/etype/nxp_imx8mcst.py
index 132127ad4827..b432200960df 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -67,10 +67,11 @@ class Entry_nxp_imx8mcst(Entry_mkimage):

 def ReadNode(self):
 super().ReadNode()
+self.certpath =3D '/usr/src/nxp/cst-3.3.2/crts/';
 self.loader_address =3D fdt_util.GetInt(self._node, 'nxp,loader-ad=
dress')
 self.srk_table 

Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing

2024-05-15 Thread Tim Harvey
On Tue, May 14, 2024 at 1:58 PM Marek Vasut  wrote:
>
> On 5/14/24 8:34 PM, Tim Harvey wrote:
>
> Hi,
>
> >> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt 
> >> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> index e16e5410bd9..ce1de659d8c 100644
> >> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> @@ -121,6 +121,9 @@ build configuration:
> >>   - Defconfig:
> >>
> >> CONFIG_IMX_HAB=y
> >> +  CONFIG_FSL_CAAM=y
> >> +  CONFIG_ARCH_MISC_INIT=y
> >> +  CONFIG_SPL_CRYPTO=y
> >>
> >
> > Hi Marek,
> >
> > Thanks for wrapping the dts bits with a config item.
> >
> > Is there any other reason to build with CONFIG_IMX_HAB than to use a
> > signed image? I see that there are several ARCH_MX6 and ARCH_MX7
> > configs that have this enabled (not ARCH_IMX8M so this certainly
> > doesn't break anything) and I'm not sure what the value of that is.
>
> I think those few either enabled in preemptively in anticipation of
> possibly using HAB, or are wrong. I suspect it should be disabled for
> those, as it only adds to the board boot time and I am not even sure if
> those machines would boot correctly.
>
> Francesco, maybe you do have MX7 Colibri ?
>
> > I notice that FSL_CAAM is selected when you select IMX_HAB... is there
> > any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
> > IMX_HAB as well (future patch perhaps)?
>
> ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
> on MX8M I think . As for SPL_CRYPTO, that should be selected by
> SPL_FSL_CAAM I think.
>
> >>   - Kconfig:
> >>
> >
> > We definitely need to describe the additional requirements here. Maybe
> > something like:
> >
> > - Tools:
> > cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
> >
> > - Files: (created with NXP IMX_CST_TOOL)
> > SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
> > CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): 
> > CSF_KEY
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): 
> > IMG_KEY
> >
> > The following works fine for me on v2024.01
> > export CST_DIR=/usr/src/nxp/cst-3.3.2/
> > export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> > export PATH=$CST_DIR/linux64/bin:$PATH
> > make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
> >
> > But with the above defines and your series this fails:
> > ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
> > ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > make
> >BINMAN  .binman_stamp
> > Wrote map file './image.map' to show errors
> > binman: Error 1 running 'cst -i
> > ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
> > Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
> > 0:error:02001002:system library:fopen:No such file or
> > directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
> > pem','r')
> > 0:error:20074002:BIO routines:file_ctrl:system 
> > lib:crypto/bio/bss_file.c:290:
> >
> > make: *** [Makefile:1126: .binman_stamp] Error 1
> >
> > So how is it that the default for nxp,img-crt
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
> > IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
> > vs ln them.
> >
> > So what am I missing here?
>
> I think CST is using both the certificate and the key files. Try and run
> strace on the CST to test that:
>
> $ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst@0

Hi Marek,

strace was a good idea and showed me what was going on.

The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems to need both of
these:

so if I hack the path to my certs in like this it works:
diff --git a/tools/binman/etype/nxp_imx8mcst.py
b/tools/binman/etype/nxp_imx8mcst.py
index 132127ad4827..b432200960df 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -67,10 +67,11 @@ class Entry_nxp_imx8mcst(Entry_mkimage):

 def ReadNode(self):
 super().ReadNode()
+self.certpath = '/usr/src/nxp/cst-3.3.2/crts/';
 self.loader_address = fdt_util.GetInt(self._node, 'nxp,loader-address')
 self.srk_table = fdt_util.GetString(self._node,
'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
-self.csf_crt = fdt_util.GetString(self._node, 'nxp,csf-crt',

[PATCH 11/11] mmc: Add support for ADI SC5XX-family processor SDHCI peripherals

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS |   1 +
 drivers/mmc/Kconfig |   8 +++
 drivers/mmc/Makefile|   1 +
 drivers/mmc/adi_sdhci.c | 152 
 4 files changed, 162 insertions(+)
 create mode 100644 drivers/mmc/adi_sdhci.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1131c85d22..b4c00c4d5a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -614,6 +614,7 @@ F:  drivers/dma/adi_dma.c
 F: drivers/gpio/adp5588_gpio.c
 F: drivers/gpio/gpio-adi-adsp.c
 F: drivers/i2c/adi_i2c.c
+F: drivers/mmc/adi_sdhci.c
 F: drivers/net/dwc_eth_qos_adi.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/remoteproc/adi_sc5xx_rproc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index d0944793c9..f32c8a3c13 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -283,6 +283,14 @@ config MMC_DW_ROCKCHIP
  SD 3.0, SDIO 3.0 and MMC 4.5 and supports common eMMC chips as well
  as removeable SD and micro-SD cards.
 
+config MMC_SDHCI_ADI
+   bool "ADI SD/MMC controller support"
+   depends on DM_MMC && OF_CONTROL
+   depends on MMC_SDHCI && MMC_SDHCI_ADMA
+   help
+ This enables support for the SD/MMC controller included in some Analog
+ Devices SC5XX Socs.
+
 config MMC_DW_SOCFPGA
bool "SOCFPGA specific extensions for Synopsys DW Memory Card Interface"
depends on ARCH_SOCFPGA
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 72c3fb66ce..eac8c28ee5 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_MMC_SDHCI_MV)+= mv_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_NPCM)+= npcm_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_PIC32)  += pic32_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_ROCKCHIP)   += rockchip_sdhci.o
+obj-$(CONFIG_MMC_SDHCI_ADI)+= adi_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_S5P)+= s5p_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_STI)+= sti_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_TANGIER)+= tangier_sdhci.o
diff --git a/drivers/mmc/adi_sdhci.c b/drivers/mmc/adi_sdhci.c
new file mode 100644
index 00..a8484e0e7a
--- /dev/null
+++ b/drivers/mmc/adi_sdhci.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ *
+ * Based on Rockchip's sdhci.c file
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* 400KHz is max freq for card ID etc. Use that as min */
+#define EMMC_MIN_FREQ  40
+
+#define ADMA_BOUNDARY_ALGN SZ_128M
+#define BOUNDARY_OK(addr, len) \
+   (((addr) | (ADMA_BOUNDARY_ALGN - 1)) == (((addr) + (len) - 1) | \
+   (ADMA_BOUNDARY_ALGN - 1)))
+/* We split a descriptor for every crossing of the ADMA alignment boundary,
+ * so we need an additional descriptor for every expected crossing.
+ * As I understand it, the max expected transaction size is:
+ *  CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN
+ *
+ * With the way the SDHCI-ADMA driver is implemented, if ADMA_MAX_LEN was a
+ * clean power of two, we'd only ever need +1 descriptor as the first
+ * descriptor that got split would then bring the remaining DMA
+ * destination addresses into alignment. Unfortunately, it's currently
+ * hardcoded to a non-power-of-two value.
+ *
+ * If that ever becomes parameterized, ADMA max length can be set to
+ * 0x1, and set this to 1.
+ */
+#define ADMA_POTENTIAL_CROSSINGS \
+   DIV_ROUND_UP((CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN), \
+ADMA_BOUNDARY_ALGN)
+/* +1 descriptor for each crossing.
+ */
+#define ADMA_TABLE_EXTRA_SZ (ADMA_POTENTIAL_CROSSINGS * ADMA_DESC_LEN)
+
+struct adi_sdhc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct adi_sdhc {
+   struct sdhci_host host;
+   void *base;
+};
+
+void adi_dwcmshc_adma_write_desc(struct sdhci_host *host, void **desc,
+dma_addr_t addr, int len, bool end)
+{
+   int tmplen, offset;
+
+   if (likely(!len || BOUNDARY_OK(addr, len))) {
+   sdhci_adma_write_desc(host, desc, addr, len, end);
+   return;
+   }
+
+   offset = addr & (ADMA_BOUNDARY_ALGN - 1);
+   tmplen = ADMA_BOUNDARY_ALGN - offset;
+   sdhci_adma_write_desc(host, desc, addr, tmplen, false);
+
+   addr += tmplen;
+   len -= tmplen;
+   sdhci_adma_write_desc(host, desc, addr, len, end);
+}
+
+struct sdhci_ops adi_dwcmshc_sdhci_ops = {
+   .adma_write_desc = adi_dwcmshc_adma_write_desc,
+};
+
+static int adi_dwcmshc_sdhci_probe(struct udevice *dev)
+{
+   

[PATCH 10/11] spi: Add support for ADI SC5XX-family processor SPI peripherals

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

This adds support for the ADI-specific SPI driver present in the ADI
SC5xx line of SoCs. This IP block is distinct from the QSPI/OSPI block
that uses the Cadence driver. Both may be used at once with appropriate
pin muxing configuration.

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Angelo Dureghello 
Signed-off-by: Angelo Dureghello 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Co-developed-by: Piotr Wojtaszczyk 
Signed-off-by: Piotr Wojtaszczyk 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS|   1 +
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/adi_spi3.c | 690 +
 4 files changed, 698 insertions(+)
 create mode 100644 drivers/spi/adi_spi3.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8ca7da4c02..1131c85d22 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -618,6 +618,7 @@ F:  drivers/net/dwc_eth_qos_adi.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/remoteproc/adi_sc5xx_rproc.c
 F: drivers/serial/serial_adi_uart4.c
+F: drivers/spi/adi_spi3.c
 F: drivers/timer/adi_sc5xx_timer.c
 F: drivers/usb/musb-new/sc5xx.c
 F: drivers/watchdog/adi_wdt.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 35030ab355..6634494d84 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -52,6 +52,12 @@ config SPI_DIRMAP
 
 if DM_SPI
 
+config ADI_SPI3
+   bool "Enable ADI SPI Driver"
+   help
+ Enable the ADI (Analog Devices) SPI controller driver. This
+ driver enables the support for SC5XX spi controller.
+
 config ALTERA_SPI
bool "Altera SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 32d7bf7237..fa1b47f2f9 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-y += spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
 endif
 
+obj-$(CONFIG_ADI_SPI3) += adi_spi3.o
 obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
 obj-$(CONFIG_APPLE_SPI) += apple_spi.o
 obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
diff --git a/drivers/spi/adi_spi3.c b/drivers/spi/adi_spi3.c
new file mode 100644
index 00..9e75050a89
--- /dev/null
+++ b/drivers/spi/adi_spi3.c
@@ -0,0 +1,690 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Converted to driver model by Nathan Barrett-Morrison
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ * Contact: Ian Roberts 
+ * Contact: Piotr Wojtaszczyk 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPI_IDLE_VAL   0xff
+
+#define MAX_CTRL_CS 7
+
+/* SPI_CONTROL */
+#define SPI_CTL_EN  0x0001 /* Enable */
+#define SPI_CTL_MSTR0x0002 /* Master/Slave */
+#define SPI_CTL_PSSE0x0004 /* controls modf error in master mode */
+#define SPI_CTL_ODM 0x0008 /* Open Drain Mode */
+#define SPI_CTL_CPHA0x0010 /* Clock Phase */
+#define SPI_CTL_CPOL0x0020 /* Clock Polarity */
+#define SPI_CTL_ASSEL   0x0040 /* Slave Select Pin Control */
+#define SPI_CTL_SELST   0x0080 /* Slave Select Polarity in transfers */
+#define SPI_CTL_EMISO   0x0100 /*Enable MISO */
+#define SPI_CTL_SIZE0x0600 /*Word Transfer Size */
+#define SPI_CTL_SIZE08  0x /*SIZE: 8 bits */
+#define SPI_CTL_SIZE16  0x0200 /*SIZE: 16 bits */
+#define SPI_CTL_SIZE32  0x0400 /*SIZE: 32 bits */
+#define SPI_CTL_LSBF0x1000 /*LSB First */
+#define SPI_CTL_FCEN0x2000 /*Flow-Control Enable */
+#define SPI_CTL_FCCH0x4000 /*Flow-Control Channel Selection */
+#define SPI_CTL_FCPL0x8000 /*Flow-Control Polarity */
+#define SPI_CTL_FCWM0x0003 /*Flow-Control Water-Mark */
+#define SPI_CTL_FIFO0   0x /*FCWM: Tx empty or Rx Full */
+#define SPI_CTL_FIFO1   0x0001 /*FCWM: Tx empty or Rx full (>=75%) */
+#define SPI_CTL_FIFO2   0x0002 /*FCWM: Tx empty or Rx full (>=50%) */
+#define SPI_CTL_FMODE   0x0004 /*Fast-mode Enable */
+#define SPI_CTL_MIOM0x0030 /*Multiple I/O Mode */
+#define SPI_CTL_MIO_DIS 0x /*MIOM: Disable */
+#define SPI_CTL_MIO_DUAL0x0010 /*MIOM: Enable DIOM (Dual I/O Mode) */
+#define SPI_CTL_MIO_QUAD0x0020 /*MIOM: Enable QUAD (Quad SPI Mode) */
+#define SPI_CTL_SOSI0x0040 /*Start on MOSI */
+#define SPI_CTL_MMWEM   0x4000 /*Start on MMWEM */
+#define SPI_CTL_MMSE0x8000 /*Start on MMSE */
+/* SPI_RX_CONTROL */
+#define SPI_RXCTL_REN   0x0001 /*Receive Channel Enable */
+#define SPI_RXCTL_RTI   0x0004 /*Receive Transfer Initiate */
+#define SPI_RXCTL_RWCEN 0x0008 /*Receive Word 

[PATCH 09/11] remoteproc: Add in SHARC loading for ADI SC5XX-family processors

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

This adds the ability to load ldr-formatted files to the SHARC
coprocessors using the rproc interface. Only a minimal subset
of rproc functionality is supported: loading and starting
the remote core.

Secure boot and signed ldr verification are not available
at this time through the U-Boot interface.

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Co-developed-by: Piotr Wojtaszczyk 
Signed-off-by: Piotr Wojtaszczyk 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS  |   1 +
 drivers/remoteproc/Kconfig   |  11 ++
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/adi_sc5xx_rproc.c | 276 +++
 4 files changed, 289 insertions(+)
 create mode 100644 drivers/remoteproc/adi_sc5xx_rproc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ce92ce107d..8ca7da4c02 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -616,6 +616,7 @@ F:  drivers/gpio/gpio-adi-adsp.c
 F: drivers/i2c/adi_i2c.c
 F: drivers/net/dwc_eth_qos_adi.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
+F: drivers/remoteproc/adi_sc5xx_rproc.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
 F: drivers/usb/musb-new/sc5xx.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index a49802c132..3f7cebaeb7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -13,6 +13,7 @@ config REMOTEPROC
depends on DM
 
 # Please keep the configuration alphabetically sorted.
+
 config K3_SYSTEM_CONTROLLER
bool "Support for TI' K3 System Controller"
select REMOTEPROC
@@ -22,6 +23,16 @@ config K3_SYSTEM_CONTROLLER
help
  Say 'y' here to add support for TI' K3 System Controller.
 
+config REMOTEPROC_ADI_SC5XX
+   bool "Support for ADI SC5xx SHARC cores"
+   select REMOTEPROC
+   depends on DM
+   depends on ARCH_SC5XX
+   depends on SYSCON
+   help
+ Say 'y' here to add support for loading code onto SHARC cores in
+ an ADSP-SC5xx SoC from Analog Devices
+
 config REMOTEPROC_SANDBOX
bool "Support for Test processor for Sandbox"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index e09ed1aa4d..c2aaf6f8c3 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o 
rproc-elf-loader.o
 
 # Remote proc drivers - Please keep this list alphabetically sorted.
 obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
+obj-$(CONFIG_REMOTEPROC_ADI_SC5XX) += adi_sc5xx_rproc.o
 obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
diff --git a/drivers/remoteproc/adi_sc5xx_rproc.c 
b/drivers/remoteproc/adi_sc5xx_rproc.c
new file mode 100644
index 00..fc9730ef32
--- /dev/null
+++ b/drivers/remoteproc/adi_sc5xx_rproc.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ *
+ * Analog Devices SC5xx remoteproc driver for loading code onto SHARC cores
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#ifdef CONFIG_SC58X
+#define ADI_RCU_REG_CTL0x00
+#define ADI_RCU_REG_STAT   0x04
+#define ADI_RCU_REG_CRCTL  0x08
+#define ADI_RCU_REG_CRSTAT 0x0c
+#define ADI_RCU_REG_SIDIS  0x10
+#define ADI_RCU_REG_SISTAT 0x14
+#define ADI_RCU_REG_BCODE  0x1c
+#define ADI_RCU_REG_SVECT0 0x20
+#define ADI_RCU_REG_SVECT1 0x24
+#define ADI_RCU_REG_SVECT2 0x28
+#define ADI_RCU_REG_MSG0x60
+#define ADI_RCU_REG_MSG_SET0x64
+#define ADI_RCU_REG_MSG_CLR0x68
+#else
+#define ADI_RCU_REG_CTL0x00
+#define ADI_RCU_REG_STAT   0x04
+#define ADI_RCU_REG_CRCTL  0x08
+#define ADI_RCU_REG_CRSTAT 0x0c
+#define ADI_RCU_REG_SRRQSTAT   0x18
+#define ADI_RCU_REG_SIDIS  0x1c
+#define ADI_RCU_REG_SISTAT 0x20
+#define ADI_RCU_REG_SVECT_LCK  0x24
+#define ADI_RCU_REG_BCODE  0x28
+#define ADI_RCU_REG_SVECT0 0x2c
+#define ADI_RCU_REG_SVECT1 0x30
+#define ADI_RCU_REG_SVECT2 0x34
+#define ADI_RCU_REG_MSG0x6c
+#define ADI_RCU_REG_MSG_SET0x70
+#define ADI_RCU_REG_MSG_CLR0x74
+#endif /* CONFIG_SC58X */
+
+/* Register bit definitions */
+#define ADI_RCU_CTL_SYSRST BIT(0)
+
+/* Bit values for the RCU0_MSG register */
+#define RCU0_MSG_C0IDLE0x0100  /* Core 
0 Idle */
+#define RCU0_MSG_C1IDLE

[PATCH 08/11] dma: Add driver for ADI SC5xx-family SoC MDMA functionality

2024-05-15 Thread Greg Malysa
Add a rudimentary MDMA driver for the Analog Devices SC5xx SoCs,
primarily intended for use with and tested against the QSPI/OSPI
IP included in the SoC.

Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Greg Malysa 
---

 MAINTAINERS   |   1 +
 drivers/dma/Kconfig   |   7 ++
 drivers/dma/Makefile  |   1 +
 drivers/dma/adi_dma.c | 255 ++
 4 files changed, 264 insertions(+)
 create mode 100644 drivers/dma/adi_dma.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6feb7e540b..ce92ce107d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -610,6 +610,7 @@ T:  git https://github.com/analogdevicesinc/lnxdsp-u-boot
 F: arch/arm/include/asm/arch-adi/
 F: arch/arm/mach-sc5xx/
 F: drivers/clk/adi/
+F: drivers/dma/adi_dma.c
 F: drivers/gpio/adp5588_gpio.c
 F: drivers/gpio/gpio-adi-adsp.c
 F: drivers/i2c/adi_i2c.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 3c64e89464..4b47be6b01 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -76,6 +76,13 @@ config XILINX_DPDMA
  this file is used as placeholder for driver. The main reason is
  to record compatible string and calling power domain driver.
 
+config ADI_DMA
+   bool "ADI DMA driver"
+   depends on DMA && DMA_CHANNELS
+   help
+ Enable DMA support for Analog Devices SOCs, such as the SC5xx.
+ Currently this is a minimalistic driver tested against OSPI use only.
+
 if APBH_DMA
 config APBH_DMA_BURST
bool "Enable DMA BURST"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 48811eaaeb..00d765864c 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
 obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
 obj-$(CONFIG_XILINX_DPDMA) += xilinx_dpdma.o
+obj-$(CONFIG_ADI_DMA) += adi_dma.o
 
 obj-y += ti/
diff --git a/drivers/dma/adi_dma.c b/drivers/dma/adi_dma.c
new file mode 100644
index 00..56eceff712
--- /dev/null
+++ b/drivers/dma/adi_dma.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Analog Devices DMA controller driver
+ *
+ * (C) Copyright 2024 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ * Contact: Ian Roberts 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HAS_MDMA   BIT(0)
+
+#define REG_ADDRSTART  0x04
+#define REG_CFG0x08
+#define REG_XCNT   0x0C
+#define REG_XMOD   0x10
+#define REG_STAT   0x30
+
+#define BITP_DMA_CFG_MSIZE8
+#define BITP_DMA_CFG_PSIZE4
+#define BITM_DMA_CFG_WNR 0x0002
+#define BITM_DMA_CFG_EN  0x0001
+#define ENUM_DMA_CFG_XCNT_INT0x0010
+
+#define BITP_DMA_STAT_PBWID  12
+#define BITP_DMA_STAT_ERRC4
+#define BITM_DMA_STAT_PBWID  0x3000
+#define BITM_DMA_STAT_ERRC   0x0070
+#define BITM_DMA_STAT_PIRQ   0x0004
+#define BITM_DMA_STAT_IRQERR 0x0002
+#define BITM_DMA_STAT_IRQDONE0x0001
+
+#define DMA_MDMA_SRC_DEFAULT_CONFIG(psize, msize) \
+   (BITM_DMA_CFG_EN | ((psize) << BITP_DMA_CFG_PSIZE) | ((msize) << 
BITP_DMA_CFG_MSIZE))
+#define DMA_MDMA_DST_DEFAULT_CONFIG(psize, msize) \
+   (BITM_DMA_CFG_EN | BITM_DMA_CFG_WNR | ENUM_DMA_CFG_XCNT_INT | \
+   ((psize) << BITP_DMA_CFG_PSIZE) | ((msize) << BITP_DMA_CFG_MSIZE))
+
+struct adi_dma_channel {
+   int id;
+   struct adi_dma *dma;
+   void __iomem *iosrc;
+   void __iomem *iodest;
+};
+
+struct adi_dma {
+   struct udevice *dev;
+   struct adi_dma_channel channels[1];
+   void __iomem *ioaddr;
+   unsigned long hw_cfg;
+};
+
+static const struct udevice_id dma_dt_ids[] = {
+   { .compatible = "adi,mdma-controller", .data = HAS_MDMA },
+   { }
+};
+
+static u8 adi_dma_get_msize(u32 n_bytecount, u32 n_address)
+{
+   /* Calculate MSIZE, PSIZE, XCNT and XMOD */
+   u8 n_msize = 0;
+   u32 n_value = n_bytecount | n_address;
+   u32 n_mask = 0x1;
+
+   for (n_msize = 0; n_msize < 5; n_msize++, n_mask <<= 1) {
+   if ((n_value & n_mask) == n_mask)
+   break;
+   }
+
+   return n_msize;
+}
+
+static int adi_dma_get_ch_error(void __iomem *ch)
+{
+   u32 cause = (readl(ch + REG_STAT) &  BITM_DMA_STAT_ERRC) >>
+   BITP_DMA_STAT_ERRC;
+   switch (cause) {
+   case 0:
+   return -EINVAL;
+   case 1:
+   return -EBUSY;
+   case 2:
+

[PATCH 07/11] watchdog: Add support for ADI SC5XX-family watchdog peripheral

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS|   1 +
 drivers/watchdog/Kconfig   |   9 +++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/adi_wdt.c | 145 +
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/watchdog/adi_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c1685f0352..6feb7e540b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -618,6 +618,7 @@ F:  drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
 F: drivers/usb/musb-new/sc5xx.c
+F: drivers/watchdog/adi_wdt.c
 F: include/env/adi/
 
 ARM SNAPDRAGON
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8318fd77a3..5a62000272 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -94,6 +94,15 @@ config WDT_APPLE
  The watchdog will perform a full SoC reset resulting in a
  reboot of the entire system.
 
+config WDT_ADI
+   bool "Analog Devices watchdog timer support"
+   select WDT
+   select SPL_WDT if SPL
+   depends on (SC57X || SC58X || SC59X || SC59X_64)
+   help
+ Enable this to support Watchdog Timer on ADI SC57X, SC58X, SC59X,
+ and SC59X_64 processors
+
 config WDT_ARMADA_37XX
bool "Marvell Armada 37xx watchdog timer support"
depends on WDT && ARMADA_3700
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7b39adcf0f..7ad61b513c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -50,3 +50,4 @@ obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
 obj-$(CONFIG_WDT_SUNXI) += sunxi_wdt.o
 obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
 obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+obj-$(CONFIG_WDT_ADI) += adi_wdt.o
diff --git a/drivers/watchdog/adi_wdt.c b/drivers/watchdog/adi_wdt.c
new file mode 100644
index 00..67d17dc692
--- /dev/null
+++ b/drivers/watchdog/adi_wdt.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Converted to driver model by Nathan Barrett-Morrison
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ *
+ * adi_wtd.c - driver for ADI on-chip watchdog
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDOG_CTL  0x0
+#define WDOG_CNT  0x4
+#define WDOG_STAT 0x8
+
+#define RCU_CTL   0x0
+#define RCU_STAT  0x4
+
+#define SEC_GCTL  0x0
+#define SEC_FCTL  0x10
+#define SEC_SCTL0 0x800
+
+#define WDEN  0x0010
+#define WDDIS 0x0AD0
+
+struct adi_wdt_priv {
+   void __iomem *rcu_base;
+   void __iomem *sec_base;
+   void __iomem *wdt_base;
+   struct clk clock;
+};
+
+static int adi_wdt_reset(struct udevice *dev)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(0, priv->wdt_base + WDOG_STAT);
+
+   return 0;
+}
+
+static int adi_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+   u32 sctl_val;
+
+   /* Disable SYSCD_RESETb input and clear the RCU0 reset status */
+   writel(0xf, priv->rcu_base + RCU_STAT);
+   writel(0x0, priv->rcu_base + RCU_CTL);
+
+   /* reset the SEC controller */
+   writel(0x2, priv->sec_base + SEC_GCTL);
+   writel(0x2, priv->sec_base + SEC_FCTL);
+
+   udelay(50);
+
+   /* enable SEC fault event */
+   writel(0x1, priv->sec_base + SEC_GCTL);
+
+   /* ANOMALY 3614 Spurious External Fault event occurs when FCTL
+* is re-programmed when currently active fault is not cleared
+*/
+   writel(0xc0, priv->sec_base + SEC_FCTL);
+   writel(0xc1, priv->sec_base + SEC_FCTL);
+
+   /* enable SEC fault source for watchdog0 */
+   sctl_val = readl((priv->sec_base + SEC_SCTL0) + 3 * 8) | 0x6;
+   writel(sctl_val, (priv->sec_base + SEC_SCTL0) + 3 * 8);
+
+   /* Enable SYSCD_RESETb input */
+   writel(0x100, priv->rcu_base + RCU_CTL);
+
+   /* enable watchdog0 */
+   writel(WDDIS, priv->wdt_base + WDOG_CTL);
+
+   writel(timeout_ms / 1000 *
+  (clk_get_rate(>clock) / (IS_ENABLED(CONFIG_SC58X) ? 2 : 
1)),
+  priv->wdt_base + WDOG_CNT);
+
+   writel(0, priv->wdt_base + WDOG_STAT);
+   writel(WDEN, priv->wdt_base + WDOG_CTL);
+
+   return 0;
+}
+
+static int adi_wdt_probe(struct udevice *dev)
+{
+   struct adi_wdt_priv *priv = dev_get_priv(dev);
+   int ret;
+   struct resource res;
+
+   ret = dev_read_resource_byname(dev, "rcu", );
+   if (ret)
+   return ret;
+   priv->rcu_base = devm_ioremap(dev, res.start, 

[PATCH 06/11] net: Add support for ADI SC5xx SoCs with DWC QoS ethernet

2024-05-15 Thread Greg Malysa
The ADI SC598 includes a Designware QoS 5.20a IP block. This
commit adds support for using the existing ethernet QoS driver
with the SC598 SoC.

Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Greg Malysa 
---

 MAINTAINERS   |   1 +
 drivers/net/Kconfig   |   7 +++
 drivers/net/Makefile  |   1 +
 drivers/net/dwc_eth_qos.c |   6 ++
 drivers/net/dwc_eth_qos.h |   2 +
 drivers/net/dwc_eth_qos_adi.c | 101 ++
 6 files changed, 118 insertions(+)
 create mode 100644 drivers/net/dwc_eth_qos_adi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 977233451e..c1685f0352 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -613,6 +613,7 @@ F:  drivers/clk/adi/
 F: drivers/gpio/adp5588_gpio.c
 F: drivers/gpio/gpio-adi-adsp.c
 F: drivers/i2c/adi_i2c.c
+F: drivers/net/dwc_eth_qos_adi.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b4ff033afa..9ae471e371 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -236,6 +236,13 @@ config DWC_ETH_QOS
  Of Service) IP block. The IP supports many options for bus type,
  clocking/reset structure, and feature list.
 
+config DWC_ETH_QOS_ADI
+   bool "Synopsys DWC Ethernet QOS device support for ADI SC59x-64 parts"
+   depends on DWC_ETH_QOS
+   help
+   The Synopsis Designware Ethernet QoS IP block with the specific
+   configuration used in the ADI ADSP-SC59X 64 bit SoCs
+
 config DWC_ETH_QOS_IMX
bool "Synopsys DWC Ethernet QOS device support for IMX"
depends on DWC_ETH_QOS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index dce71685c3..612f5644f3 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DM_ETH_PHY) += eth-phy-uclass.o
 obj-$(CONFIG_DRIVER_DM9000) += dm9000x.o
 obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
 obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
+obj-$(CONFIG_DWC_ETH_QOS_ADI) += dwc_eth_qos_adi.o
 obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
 obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
 obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 67ac86f82b..10528368ca 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1544,6 +1544,12 @@ static const struct udevice_id eqos_ids[] = {
.compatible = "starfive,jh7110-dwmac",
.data = (ulong)_jh7110_config
},
+#endif
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_ADI)
+   {
+   .compatible = "adi,sc59x-dwmac-eqos",
+   .data = (ulong)_adi_config
+   },
 #endif
{ }
 };
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index 8b3d0d464d..1b28f2a056 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -84,6 +84,7 @@ struct eqos_mac_regs {
 #define EQOS_MAC_MDIO_ADDRESS_CR_SHIFT 8
 #define EQOS_MAC_MDIO_ADDRESS_CR_100_150   1
 #define EQOS_MAC_MDIO_ADDRESS_CR_20_35 2
+#define EQOS_MAC_MDIO_ADDRESS_CR_150_250   4
 #define EQOS_MAC_MDIO_ADDRESS_CR_250_300   5
 #define EQOS_MAC_MDIO_ADDRESS_SKAP BIT(4)
 #define EQOS_MAC_MDIO_ADDRESS_GOC_SHIFT2
@@ -293,3 +294,4 @@ extern struct eqos_config eqos_qcom_config;
 extern struct eqos_config eqos_stm32mp13_config;
 extern struct eqos_config eqos_stm32mp15_config;
 extern struct eqos_config eqos_jh7110_config;
+extern struct eqos_config eqos_adi_config;
diff --git a/drivers/net/dwc_eth_qos_adi.c b/drivers/net/dwc_eth_qos_adi.c
new file mode 100644
index 00..8e770c0dcb
--- /dev/null
+++ b/drivers/net/dwc_eth_qos_adi.c
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * (C) Copyright 2024 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Author: Greg Malysa 
+ * Additional Contact: Nathan Barrett-Morrison 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "dwc_eth_qos.h"
+
+static int eqos_start_resets_adi(struct udevice *dev)
+{
+   struct eqos_priv *eqos = dev_get_priv(dev);
+   u32 val;
+
+   /*
+* Settings need to latch with the DMA reset below. Currently only
+* rgmii is supported but other phy interfaces may be supported in
+* the future
+*/
+   sc5xx_enable_rgmii();
+
+   val = readl(>dma_regs->mode);
+   val |= EQOS_DMA_MODE_SWR;
+   writel(val, >dma_regs->mode);
+
+   return 0;
+}
+
+static int eqos_probe_resources_adi(struct udevice *dev)
+{
+   

[PATCH 05/11] i2c: Add support for ADI SC5XX-family I2C peripheral

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Co-developed-by: Angelo Dureghello 
Signed-off-by: Angelo Dureghello 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS   |   1 +
 drivers/i2c/Kconfig   |   7 +
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/adi_i2c.c | 393 ++
 4 files changed, 402 insertions(+)
 create mode 100644 drivers/i2c/adi_i2c.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bcdb73e6e..977233451e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -612,6 +612,7 @@ F:  arch/arm/mach-sc5xx/
 F: drivers/clk/adi/
 F: drivers/gpio/adp5588_gpio.c
 F: drivers/gpio/gpio-adi-adsp.c
+F: drivers/i2c/adi_i2c.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 34b02114dc..efcb0589ca 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -154,6 +154,13 @@ config SPL_DM_I2C_GPIO
  bindings are supported.
  Binding info: doc/device-tree-bindings/i2c/i2c-gpio.txt
 
+config SYS_I2C_ADI
+   bool "ADI I2C driver"
+   depends on DM_I2C && (SC57X || SC58X || SC59X || SC59X_64)
+   help
+ Add support for the ADI (Analog Devices) I2C driver as used
+ in SC57X, SC58X, SC59X, SC59X_64.
+
 config SYS_I2C_AT91
bool "Atmel I2C driver"
depends on DM_I2C && ARCH_AT91
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 00b90523c6..30c1a43a57 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
+obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
 obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
 obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
diff --git a/drivers/i2c/adi_i2c.c b/drivers/i2c/adi_i2c.c
new file mode 100644
index 00..cfc5561299
--- /dev/null
+++ b/drivers/i2c/adi_i2c.c
@@ -0,0 +1,393 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Converted to driver model by Nathan Barrett-Morrison
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLKLOW(x) ((x) & 0xFF) // Periods Clock Is Held Low
+#define CLKHI(y) (((y) & 0xFF) << 0x8) // Periods Clock Is High
+
+#define PRESCALE0x007F // SCLKs Per Internal Time Reference (10MHz)
+#define TWI_ENA 0x0080 // TWI Enable
+#define SCCB0x0200 // SCCB Compatibility Enable
+
+#define SEN 0x0001 // Slave Enable
+#define SADD_LEN0x0002 // Slave Address Length
+#define STDVAL  0x0004 // Slave Transmit Data Valid
+#define TSC_NAK 0x0008 // NAK Generated At Conclusion Of Transfer
+#define GEN 0x0010 // General Call Adrress Matching Enabled
+
+#define SDIR0x0001 // Slave Transfer Direction
+#define GCALL   0x0002 // General Call Indicator
+
+#define MEN 0x0001 // Master Mode Enable
+#define MADD_LEN0x0002 // Master Address Length
+#define MDIR0x0004 // Master Transmit Direction (RX/TX*)
+#define FAST0x0008 // Use Fast Mode Timing Specs
+#define STOP0x0010 // Issue Stop Condition
+#define RSTART  0x0020 // Repeat Start or Stop* At End Of Transfer
+#define DCNT0x3FC0 // Data Bytes To Transfer
+#define SDAOVR  0x4000 // Serial Data Override
+#define SCLOVR  0x8000 // Serial Clock Override
+
+#define MPROG   0x0001 // Master Transfer In Progress
+#define LOSTARB 0x0002 // Lost Arbitration Indicator (Xfer Aborted)
+#define ANAK0x0004 // Address Not Acknowledged
+#define DNAK0x0008 // Data Not Acknowledged
+#define BUFRDERR0x0010 // Buffer Read Error
+#define BUFWRERR0x0020 // Buffer Write Error
+#define SDASEN  0x0040 // Serial Data Sense
+#define SCLSEN  0x0080 // Serial Clock Sense
+#define BUSBUSY 0x0100 // Bus Busy Indicator
+
+#define SINIT   0x0001 // Slave Transfer Initiated
+#define SCOMP   0x0002 // Slave Transfer Complete
+#define SERR0x0004 // Slave Transfer Error
+#define SOVF0x0008 // Slave Overflow
+#define MCOMP   0x0010 // Master Transfer Complete
+#define MERR0x0020 // Master Transfer Error
+#define XMTSERV 

[PATCH 04/11] usb: musb-new: Add support for Analog Devices SC5xx SoCs

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

This adds support for the MUSB-based USB controller found in the
Analog Devices SC57x and SC58x SoCs.

Co-developed-by: Greg Malysa 
Signed-off-by: Greg Malysa 
Co-developed-by: Ian Roberts 
Signed-off-by: Ian Roberts 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS   |   1 +
 drivers/usb/musb-new/Kconfig  |   7 ++
 drivers/usb/musb-new/Makefile |   1 +
 drivers/usb/musb-new/sc5xx.c  | 202 ++
 4 files changed, 211 insertions(+)
 create mode 100644 drivers/usb/musb-new/sc5xx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d07d13dbc..3bcdb73e6e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -615,6 +615,7 @@ F:  drivers/gpio/gpio-adi-adsp.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
+F: drivers/usb/musb-new/sc5xx.c
 F: include/env/adi/
 
 ARM SNAPDRAGON
diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index c52afd41a7..ad9072a532 100644
--- a/drivers/usb/musb-new/Kconfig
+++ b/drivers/usb/musb-new/Kconfig
@@ -22,6 +22,13 @@ config USB_MUSB_GADGET
  Enables the MUSB USB dual-role controller in gadget mode.
 
 if USB_MUSB_HOST || USB_MUSB_GADGET
+config USB_MUSB_SC5XX
+bool "Analog Devices MUSB support"
+depends on (SC57X || SC58X)
+   help
+Say y here to enable support for the USB controller on
+ADI SC57X/SC58X processors.
+
 config USB_MUSB_DA8XX
bool "Enable DA8xx MUSB Controller"
depends on ARCH_DAVINCI
diff --git a/drivers/usb/musb-new/Makefile b/drivers/usb/musb-new/Makefile
index 396ff02654..6638772dac 100644
--- a/drivers/usb/musb-new/Makefile
+++ b/drivers/usb/musb-new/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_MUSB_PIC32) += pic32.o
 obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
 obj-$(CONFIG_USB_MUSB_TI) += ti-musb.o
 obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
+obj-$(CONFIG_USB_MUSB_SC5XX) += sc5xx.o
 
 ccflags-y := $(call cc-option,-Wno-unused-variable) \
$(call cc-option,-Wno-unused-but-set-variable) \
diff --git a/drivers/usb/musb-new/sc5xx.c b/drivers/usb/musb-new/sc5xx.c
new file mode 100644
index 00..16201480b4
--- /dev/null
+++ b/drivers/usb/musb-new/sc5xx.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * ADI SC5XX MUSB "glue layer"
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Loosely ported from Linux driver:
+ * Author: Nathan Barrett-Morrison 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "linux-compat.h"
+#include "musb_core.h"
+#include "musb_uboot.h"
+
+#define MUSB_SOFTRST   0x7f
+#define  MUSB_SOFTRST_NRST BIT(0)
+#define  MUSB_SOFTRST_NRSTXBIT(1)
+
+#define REG_USB_VBUS_CTL   0x380
+#define REG_USB_ID_CTL 0x382
+#define REG_USB_PHY_CTL0x394
+#define REG_USB_PLL_OSC0x398
+#define REG_USB_UTMI_CTL   0x39c
+
+/* controller data */
+struct sc5xx_musb_data {
+   struct musb_host_data mdata;
+   struct device dev;
+};
+
+#define to_sc5xx_musb_data(d)  \
+   container_of(d, struct sc5xx_musb_data, dev)
+
+static void sc5xx_musb_disable(struct musb *musb)
+{
+   /* no way to shut the controller */
+}
+
+static int sc5xx_musb_enable(struct musb *musb)
+{
+   /* soft reset by NRSTx */
+   musb_writeb(musb->mregs, MUSB_SOFTRST, MUSB_SOFTRST_NRSTX);
+   /* set mode */
+   musb_platform_set_mode(musb, musb->board_mode);
+
+   return 0;
+}
+
+static irqreturn_t sc5xx_interrupt(int irq, void *hci)
+{
+   struct musb  *musb = hci;
+   irqreturn_t ret = IRQ_NONE;
+   u8 devctl;
+
+   musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
+   musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
+   musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
+
+   if (musb->int_usb & MUSB_INTR_VBUSERROR) {
+   musb->int_usb &= ~MUSB_INTR_VBUSERROR;
+   devctl = musb_readw(musb->mregs, MUSB_DEVCTL);
+   devctl |= MUSB_DEVCTL_SESSION;
+   musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
+   }
+   if (musb->int_usb || musb->int_tx || musb->int_rx) {
+   musb_writeb(musb->mregs, MUSB_INTRUSB, musb->int_usb);
+   musb_writew(musb->mregs, MUSB_INTRTX, musb->int_tx);
+   musb_writew(musb->mregs, MUSB_INTRRX, musb->int_rx);
+   ret = musb_interrupt(musb);
+   }
+
+   if (musb->int_usb & MUSB_INTR_DISCONNECT && is_host_active(musb))
+   musb_writeb(musb->mregs, REG_USB_VBUS_CTL, 0x0);
+
+   return ret;
+}
+
+static int sc5xx_musb_set_mode(struct musb *musb, u8 mode)
+{
+   struct device *dev = musb->controller;
+   struct sc5xx_musb_data *pdata = 

[PATCH 03/11] gpio: Add support for ADI ADP5588 GPIO expander chips

2024-05-15 Thread Greg Malysa
From: Nathan Barrett-Morrison 

This adds support for the ADP588 GPIO expander from Analog Devices. It
is accessed over I2C and provides up to 18 pins. It is largely a port of
the Linux driver developed by Michael Hennerich


Signed-off-by: Ian Roberts 
Signed-off-by: Greg Malysa 
Signed-off-by: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Nathan Barrett-Morrison 
---

 MAINTAINERS |   1 +
 drivers/gpio/Kconfig|   8 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/adp5588_gpio.c | 208 
 4 files changed, 218 insertions(+)
 create mode 100644 drivers/gpio/adp5588_gpio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d7b0f39ac..7d07d13dbc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -610,6 +610,7 @@ T:  git https://github.com/analogdevicesinc/lnxdsp-u-boot
 F: arch/arm/include/asm/arch-adi/
 F: arch/arm/mach-sc5xx/
 F: drivers/clk/adi/
+F: drivers/gpio/adp5588_gpio.c
 F: drivers/gpio/gpio-adi-adsp.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 142fe44533..37be5008f3 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -531,6 +531,14 @@ config DM_PCA953X
  Now, max 24 bits chips and PCA953X compatible chips are
  supported
 
+config ADP5588_GPIO
+   bool "ADP5588 GPIO expander driver"
+   depends on DM_GPIO && DM_I2C
+   help
+ Say yes here to support GPIO functionality of ADI ADP5588 chips.
+
+ The ADP5588 is an 18-port I2C GPIO expander and keypad controller.
+
 config SPL_DM_PCA953X
bool "PCA95[357]x, PCA9698, TCA64xx, and MAX7310 I/O ports in SPL"
depends on SPL_DM_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ba58fbafd1..f3935638f9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_NOMADIK_GPIO)+= nmk_gpio.o
 obj-$(CONFIG_MAX7320_GPIO) += max7320_gpio.o
 obj-$(CONFIG_$(SPL_)MAX77663_GPIO) += max77663_gpio.o
 obj-$(CONFIG_SL28CPLD_GPIO)+= sl28cpld-gpio.o
+obj-$(CONFIG_ADP5588_GPIO) += adp5588_gpio.o
 obj-$(CONFIG_ZYNQMP_GPIO_MODEPIN)  += zynqmp_gpio_modepin.o
 obj-$(CONFIG_SLG7XL45106_I2C_GPO)  += gpio_slg7xl45106.o
 obj-$(CONFIG_FTGPIO010)+= ftgpio010.o
diff --git a/drivers/gpio/adp5588_gpio.c b/drivers/gpio/adp5588_gpio.c
new file mode 100644
index 00..d081e16989
--- /dev/null
+++ b/drivers/gpio/adp5588_gpio.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * GPIO Chip driver for Analog Devices
+ * ADP5588/ADP5587 I/O Expander and QWERTY Keypad Controller
+ *
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Contact: Nathan Barrett-Morrison 
+ * Contact: Greg Malysa 
+ *
+ * Based on Michael Hennerich's Linux driver:
+ * Michael Hennerich 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define ADP5588_MAXGPIO 18
+#define ADP5588_BANK(offs)  ((offs) >> 3)
+#define ADP5588_BIT(offs)   (1u << ((offs) & 0x7))
+
+#define DEV_ID  0x00/* Device ID */
+#define GPIO_DAT_STAT1  0x14/* GPIO Data Status, Read twice to clear */
+#define GPIO_DAT_STAT2  0x15/* GPIO Data Status, Read twice to clear */
+#define GPIO_DAT_STAT3  0x16/* GPIO Data Status, Read twice to clear */
+#define GPIO_DAT_OUT1   0x17/* GPIO DATA OUT */
+#define GPIO_DAT_OUT2   0x18/* GPIO DATA OUT */
+#define GPIO_DAT_OUT3   0x19/* GPIO DATA OUT */
+#define GPIO_INT_EN10x1A/* GPIO Interrupt Enable */
+#define GPIO_INT_EN20x1B/* GPIO Interrupt Enable */
+#define GPIO_INT_EN30x1C/* GPIO Interrupt Enable */
+#define KP_GPIO10x1D/* Keypad or GPIO Selection */
+#define KP_GPIO20x1E/* Keypad or GPIO Selection */
+#define KP_GPIO30x1F/* Keypad or GPIO Selection */
+#define GPIO_DIR1   0x23/* GPIO Data Direction */
+#define GPIO_DIR2   0x24/* GPIO Data Direction */
+#define GPIO_DIR3   0x25   /* GPIO Data Direction */
+#define GPIO_PULL1  0x2C/* GPIO Pull Disable */
+#define GPIO_PULL2  0x2D/* GPIO Pull Disable */
+#define GPIO_PULL3  0x2E/* GPIO Pull Disable */
+#define ID_MASK0x0F
+
+struct adp5588_gpio {
+   u8 dat_out[3];
+   u8 dir[3];
+};
+
+static int adp5588_gpio_read(struct udevice *dev, u8 reg)
+{
+   int ret;
+   u8 val;
+
+   ret = dm_i2c_read(dev, reg, , 1);
+
+   if (ret < 0) {
+   pr_err("%s: read error\n", __func__);
+   return ret;
+   }
+
+   return val;
+}
+
+static int adp5588_gpio_write(struct udevice *dev, u8 reg, u8 val)
+{
+   int ret;
+
+   ret = dm_i2c_write(dev, reg, , 1);
+   if (ret < 0) {
+   pr_err("%s: write error\n", __func__);
+   return ret;
+   }
+
+   return 

[PATCH 02/11] gpio: Add support for SC5XX-family processor GPIO driver

2024-05-15 Thread Greg Malysa
This adds support for using the GPIO pins on the SC5XX family of SoCs
from Analog Devices.

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: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Greg Malysa 
---

 MAINTAINERS  |   1 +
 drivers/gpio/Kconfig |   9 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-adi-adsp.c | 179 +++
 4 files changed, 190 insertions(+)
 create mode 100644 drivers/gpio/gpio-adi-adsp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dabc7d0591..5d7b0f39ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -610,6 +610,7 @@ T:  git https://github.com/analogdevicesinc/lnxdsp-u-boot
 F: arch/arm/include/asm/arch-adi/
 F: arch/arm/mach-sc5xx/
 F: drivers/clk/adi/
+F: drivers/gpio/gpio-adi-adsp.c
 F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b050585389..142fe44533 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -97,6 +97,15 @@ config SPL_DM_GPIO_LOOKUP_LABEL
  different gpios on different hardware versions
  for the same functionality in board code.
 
+config ADI_GPIO
+   bool "ADI GPIO driver"
+   depends on DM_GPIO && (SC57X || SC58X || SC59X || SC59X_64)
+   help
+ This driver supports GPIO banks on SC5xx processors. It
+ supports inputs and outputs but does not support pin
+ interrupt functionality (PINT) or other features in the
+ Linux version of the driver.
+
 config ALTERA_PIO
bool "Altera PIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4a29315435..ba58fbafd1 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_TPL_)DM_GPIO) += gpio-uclass.o
 
 obj-$(CONFIG_$(SPL_)DM_PCA953X)+= pca953x_gpio.o
 
+obj-$(CONFIG_ADI_GPIO) += gpio-adi-adsp.o
 obj-$(CONFIG_ASPEED_GPIO)  += gpio-aspeed.o
 obj-$(CONFIG_AT91_GPIO)+= at91_gpio.o
 obj-$(CONFIG_ATMEL_PIO4)   += atmel_pio4.o
diff --git a/drivers/gpio/gpio-adi-adsp.c b/drivers/gpio/gpio-adi-adsp.c
new file mode 100644
index 00..0ce00572e0
--- /dev/null
+++ b/drivers/gpio/gpio-adi-adsp.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Author: Greg Malysa 
+ * Additional Contact: Nathan Barrett-Morrison 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADSP_PORT_MMIO_SIZE0x80
+#define ADSP_PORT_PIN_SIZE 16
+
+#define ADSP_PORT_REG_FER  0x00
+#define ADSP_PORT_REG_FER_SET  0x04
+#define ADSP_PORT_REG_FER_CLEAR0x08
+#define ADSP_PORT_REG_DATA 0x0c
+#define ADSP_PORT_REG_DATA_SET 0x10
+#define ADSP_PORT_REG_DATA_CLEAR   0x14
+#define ADSP_PORT_REG_DIR  0x18
+#define ADSP_PORT_REG_DIR_SET  0x1c
+#define ADSP_PORT_REG_DIR_CLEAR0x20
+#define ADSP_PORT_REG_INEN 0x24
+#define ADSP_PORT_REG_INEN_SET 0x28
+#define ADSP_PORT_REG_INEN_CLEAR   0x2c
+#define ADSP_PORT_REG_PORT_MUX 0x30
+#define ADSP_PORT_REG_DATA_TGL 0x34
+#define ADSP_PORT_REG_POLAR0x38
+#define ADSP_PORT_REG_POLAR_SET0x3c
+#define ADSP_PORT_REG_POLAR_CLEAR  0x40
+#define ADSP_PORT_REG_LOCK 0x44
+#define ADSP_PORT_REG_TRIG_TGL 0x48
+
+struct adsp_gpio_priv {
+   void __iomem *base;
+   int ngpio;
+};
+
+static u32 get_port(unsigned int pin)
+{
+   return pin / ADSP_PORT_PIN_SIZE;
+}
+
+static u32 get_offset(unsigned int pin)
+{
+   return pin % ADSP_PORT_PIN_SIZE;
+}
+
+static int adsp_gpio_input(struct udevice *udev, unsigned int pin)
+{
+   struct adsp_gpio_priv *priv = dev_get_priv(udev);
+   u32 port, offset;
+   void __iomem *portbase;
+
+   if (pin < priv->ngpio) {
+   port = get_port(pin);
+   offset = get_offset(pin);
+   portbase = priv->base + port * ADSP_PORT_MMIO_SIZE;
+
+   iowrite16(BIT(offset), portbase + ADSP_PORT_REG_FER_CLEAR);
+   iowrite16(BIT(offset), portbase + ADSP_PORT_REG_DIR_CLEAR);
+   iowrite16(BIT(offset), portbase + ADSP_PORT_REG_INEN_SET);
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
+static int adsp_gpio_output(struct udevice *udev, unsigned int pin, int value)
+{
+   struct adsp_gpio_priv *priv = dev_get_priv(udev);
+   u32 port, offset;
+   void __iomem *portbase;
+
+   if (pin < priv->ngpio) {
+   port = 

[PATCH 01/11] pinctrl: Add support for ADI SC5XX-family pinctrl

2024-05-15 Thread Greg Malysa
This adds support for pin configuration on the Analog Devices SC5XX SoC
family. This commit is largely a port of the Linux driver, which has not
yet been submitted upstream.

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: Vasileios Bimpikas 
Signed-off-by: Utsav Agarwal 
Signed-off-by: Arturs Artamonovs 
Signed-off-by: Greg Malysa 

---


---
 MAINTAINERS|   1 +
 drivers/pinctrl/Kconfig|   8 ++
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-adi-adsp.c | 156 +
 include/dt-bindings/pinctrl/adi-adsp.h |  21 
 5 files changed, 187 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-adi-adsp.c
 create mode 100644 include/dt-bindings/pinctrl/adi-adsp.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6853288975..dabc7d0591 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -610,6 +610,7 @@ T:  git https://github.com/analogdevicesinc/lnxdsp-u-boot
 F: arch/arm/include/asm/arch-adi/
 F: arch/arm/mach-sc5xx/
 F: drivers/clk/adi/
+F: drivers/pinctrl/pinctrl-adi-adsp.c
 F: drivers/serial/serial_adi_uart4.c
 F: drivers/timer/adi_sc5xx_timer.c
 F: include/env/adi/
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index a1d53cfbdb..0f3fb65e4e 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -170,6 +170,14 @@ config PINCTRL_APPLE
  both the GPIO definitions and pin control functions for each
  available multiplex function.
 
+config PINCTRL_ADI
+   bool "ADI pinctrl driver"
+   depends on DM && (SC57X || SC58X || SC59X || SC59X_64)
+   help
+ This driver enables pinctrl support on SC5xx processors. This
+ driver covers only the pin configuration functionality, and
+ GPIO functionality is contained in the separate GPIO driver.
+
 config PINCTRL_AR933X
bool "QCA/Athores ar933x pin control driver"
depends on DM && SOC_AR933X
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 6d7b7cd905..7dd56774bd 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -3,6 +3,7 @@
 obj-y  += pinctrl-uclass.o
 obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)   += pinctrl-generic.o
 
+obj-$(CONFIG_PINCTRL_ADI)  += pinctrl-adi-adsp.o
 obj-$(CONFIG_PINCTRL_APPLE)+= pinctrl-apple.o
 obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
 obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
diff --git a/drivers/pinctrl/pinctrl-adi-adsp.c 
b/drivers/pinctrl/pinctrl-adi-adsp.c
new file mode 100644
index 00..717ac8e005
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-adi-adsp.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Author: Greg Malysa 
+ * Additional Contact: Nathan Barrett-Morrison 
+ *
+ * dm pinctrl implementation for ADI ADSP SoCs
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADSP_PORT_MMIO_SIZE0x80
+#define ADSP_PORT_PIN_SIZE 16
+
+#define ADSP_PORT_PORT_MUX_BITS2
+#define ADSP_PORT_PORT_MUX_MASK0x03
+#define ADSP_PINCTRL_FUNCTION_COUNT 4
+
+#define ADSP_PORT_REG_FER  0x00
+#define ADSP_PORT_REG_FER_SET  0x04
+#define ADSP_PORT_REG_FER_CLEAR0x08
+#define ADSP_PORT_REG_DATA 0x0c
+#define ADSP_PORT_REG_DATA_SET 0x10
+#define ADSP_PORT_REG_DATA_CLEAR   0x14
+#define ADSP_PORT_REG_DIR  0x18
+#define ADSP_PORT_REG_DIR_SET  0x1c
+#define ADSP_PORT_REG_DIR_CLEAR0x20
+#define ADSP_PORT_REG_INEN 0x24
+#define ADSP_PORT_REG_INEN_SET 0x28
+#define ADSP_PORT_REG_INEN_CLEAR   0x2c
+#define ADSP_PORT_REG_PORT_MUX 0x30
+#define ADSP_PORT_REG_DATA_TGL 0x34
+#define ADSP_PORT_REG_POLAR0x38
+#define ADSP_PORT_REG_POLAR_SET0x3c
+#define ADSP_PORT_REG_POLAR_CLEAR  0x40
+#define ADSP_PORT_REG_LOCK 0x44
+#define ADSP_PORT_REG_TRIG_TGL 0x48
+
+struct adsp_pinctrl_priv {
+   void __iomem *base;
+   int npins;
+   char pinbuf[16];
+};
+
+static u32 get_port(unsigned int pin)
+{
+   return pin / ADSP_PORT_PIN_SIZE;
+}
+
+static u32 get_offset(unsigned int pin)
+{
+   return pin % ADSP_PORT_PIN_SIZE;
+}
+
+static int adsp_pinctrl_pinmux_set(struct udevice *udev, unsigned int pin, 
unsigned int func)
+{
+   struct adsp_pinctrl_priv *priv = dev_get_priv(udev);
+   void __iomem *portbase;
+   u32 port, offset;
+   u32 val;
+
+   if (pin >= priv->npins)
+   return -ENODEV;
+
+   if (func >= ADSP_PINCTRL_FUNCTION_COUNT)
+   

Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Marek Vasut

On 5/15/24 11:11 PM, Tim Harvey wrote:

On Wed, May 15, 2024 at 2:06 PM Marek Vasut  wrote:


On 5/15/24 10:50 PM, Tim Harvey wrote:

[...]


diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..3455d60d69dc 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -8,6 +8,7 @@

   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
   if (nodeoffset < 0)
   return nodeoffset;

+ if (IS_ENABLED(CONFIG_DM_RNG) && !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) 
{
+ err = fdt_kaslrseed(fdt);
+ if (err) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+fdt_strerror(err));
+ return err;


Is this warning really a critical boot-breaking error ?


no, and in fact I'm printing a warning inside of fdt_kaslrseed so I
can remove the duplication of error prints in the various other places
it's called as well.

Thanks for pointing that out!


Glad I could help.


Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Tim Harvey
On Wed, May 15, 2024 at 2:06 PM Marek Vasut  wrote:
>
> On 5/15/24 10:50 PM, Tim Harvey wrote:
>
> [...]
>
> > diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> > index 874ca4d6f5af..3455d60d69dc 100644
> > --- a/boot/fdt_support.c
> > +++ b/boot/fdt_support.c
> > @@ -8,6 +8,7 @@
> >
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
> >   if (nodeoffset < 0)
> >   return nodeoffset;
> >
> > + if (IS_ENABLED(CONFIG_DM_RNG) && 
> > !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {
> > + err = fdt_kaslrseed(fdt);
> > + if (err) {
> > + printf("WARNING: could not set kaslr-seed %s.\n",
> > +fdt_strerror(err));
> > + return err;
>
> Is this warning really a critical boot-breaking error ?

no, and in fact I'm printing a warning inside of fdt_kaslrseed so I
can remove the duplication of error prints in the various other places
it's called as well.

Thanks for pointing that out!

Best Regards,

Tim

>
> > + }
> > + }
> > +
> >   if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
> >   err = fdt_setprop(fdt, nodeoffset, "rng-seed",
> > abuf_data(), abuf_size());
>
> [...]
>
> The rest looks good !


Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Marek Vasut

On 5/15/24 10:50 PM, Tim Harvey wrote:

[...]


diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..3455d60d69dc 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -8,6 +8,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
  
+	if (IS_ENABLED(CONFIG_DM_RNG) && !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {

+   err = fdt_kaslrseed(fdt);
+   if (err) {
+   printf("WARNING: could not set kaslr-seed %s.\n",
+  fdt_strerror(err));
+   return err;


Is this warning really a critical boot-breaking error ?


+   }
+   }
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
  abuf_data(), abuf_size());


[...]

The rest looks good !


[PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Tim Harvey
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
it's implementation uses a different source of entropy.

As this fdt node is added elsewhere create a library function and
use it to deduplicate code.

Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.

Signed-off-by: Tim Harvey 
---
v2:
 - fix typo in commit msg
 - use stack for seed to avoid unecessary malloc/free
 - move to a library function and deduplicate code by using it elsewhere
---
 board/xilinx/common/board.c | 35 -
 boot/fdt_support.c  | 10 +
 boot/pxe_utils.c| 35 +++--
 cmd/kaslrseed.c | 45 ++---
 include/kaslrseed.h | 17 ++
 lib/Makefile|  1 +
 lib/kaslrseed.c | 34 
 7 files changed, 72 insertions(+), 105 deletions(-)
 create mode 100644 include/kaslrseed.h
 create mode 100644 lib/kaslrseed.c

diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 30a81376ac41..f741e8957818 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) && 
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
 
-   if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
-   debug("No RNG device\n");
-   return 0;
-   }
-
-   if (dm_rng_read(dev, buf, n)) {
-   debug("Reading RNG failed\n");
-   return 0;
-   }
-
-   if (!blob) {
-   debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
-   return 0;
-   }
-
-   ret = fdt_check_header(blob);
-   if (ret < 0) {
-   debug("fdt_chosen: %s\n", fdt_strerror(ret));
-   return ret;
-   }
-
-   nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
-   if (nodeoffset < 0) {
-   debug("Reading chosen node failed\n");
-   return nodeoffset;
-   }
-
-   ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
-   if (ret < 0) {
-   debug("Unable to set kaslr-seed on chosen node: %s\n", 
fdt_strerror(ret));
-   return ret;
-   }
-
return 0;
 }
 #endif
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..3455d60d69dc 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
 
+   if (IS_ENABLED(CONFIG_DM_RNG) && 
!IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {
+   err = fdt_kaslrseed(fdt);
+   if (err) {
+   printf("WARNING: could not set kaslr-seed %s.\n",
+  fdt_strerror(err));
+   return err;
+   }
+   }
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
  abuf_data(), abuf_size());
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 4b22bb6f525a..8d70233fc08d 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -323,10 +324,6 @@ static void label_boot_kaslrseed(void)
 #if CONFIG_IS_ENABLED(DM_RNG)
ulong fdt_addr;
struct fdt_header *working_fdt;
-   size_t n = 0x8;
-   struct udevice *dev;
-   u64 *buf;
-   int nodeoffset;
int err;
 
/* Get the main fdt and map it */
@@ -342,35 +339,9 @@ static void label_boot_kaslrseed(void)
if (err <= 0)
return;
 
-   if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
-   printf("No RNG device\n");
-   return;
-   }
-
-   nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
-   if (nodeoffset < 0) {
-   printf("Reading chosen node failed\n");
-   return;
-   }
-
-   buf = malloc(n);
-   if (!buf) {
-

[PATCH] dm: use newly added linux/compat alloc functions

2024-05-15 Thread Maxim Moskalets
Signed-off-by: Maxim Moskalets 
---
 include/dm/devres.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/dm/devres.h b/include/dm/devres.h
index 697534aa5b..27761deb6d 100644
--- a/include/dm/devres.h
+++ b/include/dm/devres.h
@@ -266,17 +266,13 @@ static inline void *devm_kzalloc(struct udevice *dev, 
size_t size, gfp_t gfp)
 static inline void *devm_kmalloc_array(struct udevice *dev,
   size_t n, size_t size, gfp_t flags)
 {
-   /* TODO: add kmalloc_array() to linux/compat.h */
-   if (size != 0 && n > SIZE_MAX / size)
-   return NULL;
-   return kmalloc(n * size, flags);
+   return kmalloc_array(n, size, flags);
 }
 
 static inline void *devm_kcalloc(struct udevice *dev,
 size_t n, size_t size, gfp_t flags)
 {
-   /* TODO: add kcalloc() to linux/compat.h */
-   return kmalloc(n * size, flags | __GFP_ZERO);
+   return kcalloc(n, size, flags);
 }
 
 static inline void devm_kfree(struct udevice *dev, void *ptr)
-- 
2.39.2



Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Marek Vasut

On 5/15/24 9:57 PM, Tim Harvey wrote:

[...]


The kaslrseed command similarly becomes obsolete with your patch and
should be removed. 'git grep -n CMD_KASLR' indicates which defconfigs
would be impacted.



There are several users of this command currently:
$ git grep CMD_KASLR configs/
configs/evb-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y


These four i.MX8M I can test (and you can drop the kaslrseed command 
from them, no worries).



configs/imx8mm_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk2_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk3_defconfig:CONFIG_CMD_KASLRSEED=y
configs/roc-cc-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/rock-pi-s-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_net_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_kria_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_virt_defconfig:CONFIG_CMD_KASLRSEED=y

While I can deduplicate code by calling a shared function in that
command I don't feel like I should remove that command until the
maintainers of the boards above agree on removing it from their
defconfigs as they could have bootscripts that fail with the command
missing.

I could add a warning print in the kaslrseed command indicating that
the use of this command is no longer needed.


That sounds good to me.


Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Tim Harvey
On Tue, May 14, 2024 at 10:17 PM Heinrich Schuchardt  wrote:
>
> On 5/15/24 02:50, Marek Vasut wrote:
> > On 5/15/24 2:22 AM, Tim Harvey wrote:
> >> If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> >> randomize the virtual address at which the kernel image is loaded, it
> >> expects entropy to be provided by the bootloader by populating
> >> /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> >
> > Thanks for working on this one, this is really nice.
>
> The general direction of always supplying a seed for KASLR is right. But
> there are some items to observe:
>
> We already have multiple places where /chosen/kaslr-seed is set, e.g.
> arch/arm/cpu/armv8/sec_firmware.c and board/xilinx/common/board.c.
>

Hi Heinrich,

Yes, Marek pointed out the same thing about de-duplicating code. I can
add a lib/kaslrseed.c with a fdt_kaslrseed function to deduplicate the
usage.

> Some boards are using the kaslrseed command to initialize
> /chosen/kaslr-seed from DM_RNG.
>
> It does not make sense to set it multiple times from different sources
> of randomness. I am missing the necessary clean-up in this patch.
>
> For CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y the right way forward could be
> moving sec_firmware_get_random() into the driver model. Tom is the
> maintainer for this code.

ok, I will not address arch/arm/cpu/armv8/sec_firmware.c and will
protect my implementation with 'if (IS_ENABLED(CONFIG_DM_RNG) &&
!IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT))'

>
> For Xilinx boards your patch obsoletes part of the code in
> ft_board_setup() of board/xilinx/common/board.c. CCing Michal as maintainer.
>

yes, I can remove that code to deduplicate as they are using
dm_rng_read() thus users of that must have CONFIG_DM_RNG enabled.

> The kaslrseed command similarly becomes obsolete with your patch and
> should be removed. 'git grep -n CMD_KASLR' indicates which defconfigs
> would be impacted.
>

There are several users of this command currently:
$ git grep CMD_KASLR configs/
configs/evb-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mm_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk2_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk3_defconfig:CONFIG_CMD_KASLRSEED=y
configs/roc-cc-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/rock-pi-s-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_net_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_kria_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_virt_defconfig:CONFIG_CMD_KASLRSEED=y

While I can deduplicate code by calling a shared function in that
command I don't feel like I should remove that command until the
maintainers of the boards above agree on removing it from their
defconfigs as they could have bootscripts that fail with the command
missing.

I could add a warning print in the kaslrseed command indicating that
the use of this command is no longer needed.

> label_boot_kaslrseed() needs review too.
>

yes, this can be deduplicated

> kaslr-seed is not compatible with measured boot if the device-tree is
> measured. When booting via EFI in efi_try_purge_kaslr_seed() we can
> safely remove the value because it is not used anyway; we provide the
> EFI_RNG_PROTOCOL instead. We also support measured boot via the legacy
> Linux entry point. See patch dec166d6b2c2 ("bootm: Support boot
> measurement"). We should not populate kaslr-seed if
> CONFIG_MEASURE_DEVICETREE=y. CCing Eddie and Ilias as they have been
> working on measured boot.
>

board/raspberrypi/rpi/rpi.c:ft_board_setup copies /chosen/kaslr-seed
from an fdt apparently passed in from a lower level firmware stage.

should I check to see if /chosen/kaslr-seed exists and never overwrite
it or just let this get overwritten?

> >
> >> If we have DM_RNG enabled poulate this value automatically when
>
> nits
>
> %s/poulate/populate/
>

yes, I will fix that as well.

Thanks for the review!

Best Regards,

Tim


Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Marek Vasut

On 5/15/24 6:29 PM, Tim Harvey wrote:

On Tue, May 14, 2024 at 5:50 PM Marek Vasut  wrote:


On 5/15/24 2:22 AM, Tim Harvey wrote:

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.


Thanks for working on this one, this is really nice.


If we have DM_RNG enabled poulate this value automatically when
fdt_chosen is called.


Hi Marek,

Just noticed a typo in the commit log - I'll s/poulate/populate/ in v2



Signed-off-by: Tim Harvey 
---
   boot/fdt_support.c | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..cd3069baf450 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,10 +7,12 @@
*/

   #include 
+#include 
   #include 
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
   if (nodeoffset < 0)
   return nodeoffset;

+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ struct udevice *dev;
+ size_t len = 0x8;
+ u64 *data;
+
+ data = malloc(len);


Can you allocate this 8 byte array on stack , i.e. u64 data[2]; ?



Sure... that makes sense - u64 data (just 1 64bit value)


Oh, right. Thanks for fixing it all up and keeping an eye on all the bugs !


Re: [PATCH 1/2] doc: Detailed example for netconsole setup

2024-05-15 Thread Tony Dinh
Hi Fiona,

On Tue, May 14, 2024 at 5:28 PM Fiona Klute  wrote:
>
> This adds details that I would have liked to have readily available,
> in particular how to activate the network interface before enabling
> netconsole, and how to integrate netconsole so you can use the U-Boot
> prompt.
>
> Signed-off-by: Fiona Klute 
> ---
>  doc/usage/netconsole.rst | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
> index 2aa3b9ccc5..0c983e6970 100644
> --- a/doc/usage/netconsole.rst
> +++ b/doc/usage/netconsole.rst
> @@ -18,7 +18,9 @@ broadcast address and port  are used. If it is set to 
> an IP
>  address of 0 (or 0.0.0.0) then no messages are sent to the network.
>  The source / listening port can be configured separately by setting
>  the 'ncinport' environment variable and the destination port can be
> -configured by setting the 'ncoutport' environment variable.
> +configured by setting the 'ncoutport' environment variable. Note that
> +you need to set up the network interface (e.g. using DHCP) before it
> +can be used for network console.
>
>  For example, if your server IP is 192.168.1.1, you could use::
>
> @@ -107,3 +109,32 @@ as follows:
>
>  Note that unlike the U-Boot implementation the Linux netconsole is
>  unidirectional, i. e. you have console output only in Linux.
> +
> +Setup via environment
> +-
> +
> +If persistent environment is enabled in your U-Boot configuration, you
> +can configure the network console using the environment. For example::
> +
> +   => env set autoload no
> +   => env set hostname "u-boot"
> +   => env set bootdelay 5
> +   => env set nc 'dhcp; env set stdout nc; env set stdin nc'

We would need "env set stderr nc" here, too.

All the best,
Tony

> +   => env set ncip 192.168.1.1
> +   => env set preboot "${preboot}; run nc;"
> +   => env save
> +   => reset
> +
> +``autoload no`` tells the ``dhcp`` command to configure the network
> +interface without trying to load an image. ``hostname "u-boot"`` sets
> +the hostname to be sent in DHCP requests, so they are easy to
> +recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
> +to make sure the network interface is set up before enabling
> +netconsole.
> +
> +Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
> +before trying to find any boot options, so you can interact with it if
> +desired.
> +
> +``env save`` stores the settings persistently, and ``reset`` then
> +triggers a fresh start that will use the changed settings.
> --
> 2.43.0
>


Re: [PATCH v1] board: nuvoton: Use an event to replace last_stage_init() and fix build error

2024-05-15 Thread Tom Rini
On Tue, May 07, 2024 at 05:10:55PM +0800, Jim Liu wrote:

> Followed the new style use event to replace last_stage_init().
> Fixed build error After replace last_stage_init().
> And remove CONFIG_SYS_SKIP_UART_INIT from defconfig,
> system will reuse the setting from bootblock
> and skip the baud rate setting.
> 
> Signed-off-by: Jim Liu 
> ---
>  board/nuvoton/arbel_evb/arbel_evb.c | 7 +--
>  board/nuvoton/common/Makefile   | 2 +-
>  board/nuvoton/poleg_evb/poleg_evb.c | 6 +-
>  configs/arbel_evb_defconfig | 1 -
>  4 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/board/nuvoton/arbel_evb/arbel_evb.c 
> b/board/nuvoton/arbel_evb/arbel_evb.c
> index 53c931c3c2..d112329dc1 100644
> --- a/board/nuvoton/arbel_evb/arbel_evb.c
> +++ b/board/nuvoton/arbel_evb/arbel_evb.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "../common/uart.h"
> @@ -95,9 +96,11 @@ int dram_init_banksize(void)
>   return 0;
>  }
>  
> -int last_stage_init(void)
> +static int last_stage_init(void)
>  {
> +#if CONFIG_IS_ENABLED(CONFIG_SYS_SKIP_UART_INIT)

The CONFIG_IS_ENABLED takes symbols without the CONFIG_ prefix part so
that it will be true for FOO, and SPL_FOO and TPL_FOO.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 2/2] configs: add defconfigs for the am625-lp-sk

2024-05-15 Thread Andrew Davis

On 5/15/24 1:21 PM, Tom Rini wrote:

On Fri, May 03, 2024 at 11:44:29AM -0500, Bryan Brattlof wrote:


The am62x-lp-sk is a package and reference board spin of the am62x-sk to
showcase the low-power features of the am62x SoC family. Because it so
closely resembles the am62x-sk board, use the preprocessor to inherit
its configuration making the needed changes for this board where
necessary.

Reviewed-by: Dhruva Gole 
Signed-off-by: Bryan Brattlof 
---
  configs/am62x_lp_sk_a53_defconfig | 3 +++
  configs/am62x_lp_sk_r5_defconfig  | 2 ++
  2 files changed, 5 insertions(+)

diff --git a/configs/am62x_lp_sk_a53_defconfig 
b/configs/am62x_lp_sk_a53_defconfig
new file mode 100644
index 0..904b2142b2f53
--- /dev/null
+++ b/configs/am62x_lp_sk_a53_defconfig
@@ -0,0 +1,3 @@
+#include 
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk"
+CONFIG_OF_UPSTREAM=y


So, there's a problem here. The #include trick for defconfig files isn't
working as intended, exactly. The example here doesn't work right.
First, it shows up as a variant of "sandbox" (as buildman will show and
leads to https://source.denx.de/u-boot/u-boot/-/jobs/835067#L119)

And this becomes clearer if you look at configs/am69_sk_r5_defconfig
which has to set some symbols already found in
configs/j784s4_evm_r5_defconfig in order to work. This is seemingly very
not equivalent to invoking "make foo_defconfig bar.config" to combine
things.



This is equivalent when running make. The issue is with buildman which
manually checks the content of the defconfig to find what ARCH it should
run the defconfig with. buildman doesn't understand the #include yet.
Until buildman can be fixed, you'll need to do what we did with
am69_sk_r5_defconfig and redefine the ARCH/SOC/TARGET info in the
defconfig file so buildman can find it without following the #include.

Andrew


Re: [PATCH v3 2/2] configs: add defconfigs for the am625-lp-sk

2024-05-15 Thread Tom Rini
On Fri, May 03, 2024 at 11:44:29AM -0500, Bryan Brattlof wrote:

> The am62x-lp-sk is a package and reference board spin of the am62x-sk to
> showcase the low-power features of the am62x SoC family. Because it so
> closely resembles the am62x-sk board, use the preprocessor to inherit
> its configuration making the needed changes for this board where
> necessary.
> 
> Reviewed-by: Dhruva Gole 
> Signed-off-by: Bryan Brattlof 
> ---
>  configs/am62x_lp_sk_a53_defconfig | 3 +++
>  configs/am62x_lp_sk_r5_defconfig  | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/configs/am62x_lp_sk_a53_defconfig 
> b/configs/am62x_lp_sk_a53_defconfig
> new file mode 100644
> index 0..904b2142b2f53
> --- /dev/null
> +++ b/configs/am62x_lp_sk_a53_defconfig
> @@ -0,0 +1,3 @@
> +#include 
> +CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk"
> +CONFIG_OF_UPSTREAM=y

So, there's a problem here. The #include trick for defconfig files isn't
working as intended, exactly. The example here doesn't work right.
First, it shows up as a variant of "sandbox" (as buildman will show and
leads to https://source.denx.de/u-boot/u-boot/-/jobs/835067#L119)

And this becomes clearer if you look at configs/am69_sk_r5_defconfig
which has to set some symbols already found in
configs/j784s4_evm_r5_defconfig in order to work. This is seemingly very
not equivalent to invoking "make foo_defconfig bar.config" to combine
things.

-- 
Tom


signature.asc
Description: PGP signature


Re: [NFS] fetching kernel via nfs

2024-05-15 Thread Sébastien Szymanski

Hello,

On 5/15/24 14:40, Johannes Kirchmair - SKIDATA wrote:

Dear u-boot people,

I encountered some problems trying to fetch the Linux kernel via nfs (v3).
One problem was that the nfs file lookup always returned NFS3ERR_BADHANDLE.


I have fixed this. See:

https://source.denx.de/u-boot/u-boot/-/commit/d2986567b27dae764b19886bcda1d24b7c41d075

Regards,


This is due to the following line in nfs_lookup_req() function (net/nfs.c):

len = (uint32_t *)p - (uint32_t *)&(data[0]);
rpc_req(PROG_NFS, NFS_LOOKUP, data, len);
} else {  /* NFS_V3 */
*p++ = htonl(NFS_FHSIZE);   /* Dir handle length */
<=  this line
memcpy(p, dirfh, NFS_FHSIZE);
p += (NFS_FHSIZE / 4);
*p++ = htonl(fnamelen);

In the NFS_V3 case we add the dir file handle  size to data and then the dir 
file handle.
IUC, this is not correct here because dirfh includes already the size of the 
handle in the first 4 bytes.
Feel free to correct me if I am wrong.

As a result, if I remove the line "*p++ = htonl(NFS_FHSIZE);", it works fine.

Don't have an in deps understanding of nfs, so I am not sure if this is the 
root problem here.

Best regards Johannes


--
Sébastien Szymanski, Armadeus Systems
Software engineer



Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled

2024-05-15 Thread Tim Harvey
On Tue, May 14, 2024 at 5:50 PM Marek Vasut  wrote:
>
> On 5/15/24 2:22 AM, Tim Harvey wrote:
> > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > randomize the virtual address at which the kernel image is loaded, it
> > expects entropy to be provided by the bootloader by populating
> > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
>
> Thanks for working on this one, this is really nice.
>
> > If we have DM_RNG enabled poulate this value automatically when
> > fdt_chosen is called.

Hi Marek,

Just noticed a typo in the commit log - I'll s/poulate/populate/ in v2

> >
> > Signed-off-by: Tim Harvey 
> > ---
> >   boot/fdt_support.c | 23 +++
> >   1 file changed, 23 insertions(+)
> >
> > diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> > index 874ca4d6f5af..cd3069baf450 100644
> > --- a/boot/fdt_support.c
> > +++ b/boot/fdt_support.c
> > @@ -7,10 +7,12 @@
> >*/
> >
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
> >   if (nodeoffset < 0)
> >   return nodeoffset;
> >
> > + if (IS_ENABLED(CONFIG_DM_RNG)) {
> > + struct udevice *dev;
> > + size_t len = 0x8;
> > + u64 *data;
> > +
> > + data = malloc(len);
>
> Can you allocate this 8 byte array on stack , i.e. u64 data[2]; ?
>

Sure... that makes sense - u64 data (just 1 64bit value)

> cmd/kaslrseed.c could use similar clean up (and
> lib/efi_loader/efi_dt_fixup.c and boot/pxe_utils.c ... uhhh). Maybe you
> can deduplicate this functionality into common code shared by all those
> duplicates before the duplication gets out of control ?
>
> lib/kaslrseed.c looks like a good place to put the common stuff.

Yes I started off making a function to do this but then I noticed we
had an fdt_chosen function and it fit there nicer as I didn't have to
find/create the chosen node. I also didn't know of a great place to
put it.

I will create a lib/kaslrseed.c with function for v2.

>
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + err = uclass_get_device(UCLASS_RNG, 0, );
> > + if (!err)
> > + err = dm_rng_read(dev, data, len);
> > + if (!err)
> > + err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", 
> > data, len);
> > + if (err < 0) {
> > + printf("WARNING: could not set kaslr-seed %s.\n",
> > +fdt_strerror(err));
> > + return err;
> > + }
>
> You're missing free() here, but it shouldn't be needed if you allocate
> the array on stack, which is better/simpler.

Yes, I will avoid the malloc to fix that.

Thanks,

Tim


Re: [PATCH v2 5/8] drivers: ram: Kconfig: Add CONFIG_K3_INLINE_ECC

2024-05-15 Thread Andrew Davis

On 5/10/24 3:47 AM, Santhosh Kumar K wrote:

From: Neha Malcom Francis 

Add CONFIG_K3_INLINE_ECC so that ECC functions can be compiled into R5 SPL
only when the config has been enabled.

Signed-off-by: Neha Malcom Francis 
---
  drivers/ram/Kconfig | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 9838a2798f92..9d1eee1d5cad 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -107,6 +107,17 @@ config IMXRT_SDRAM
  to support external memories like sdram, psram & nand.
  This driver is for the sdram memory interface with the SEMC.
  
+config K3_INLINE_ECC

+   bool "Enable TI Inline ECC support"
+   depends on K3_DDRSS
+   default n


n is already the default, this line is never needed.

Maybe we want this to be `default y` so that we do not change
current behavior and platforms can opt-out as needed instead.

Andrew


+   help
+ Enable Inline ECC support on K3 platforms. 1/9th of the SDRAM space
+ is used for ECC storage and the rest 8/9th is available for system
+ use. Enabling ECC increases boot time as the ECC protected regions
+ need to be primed with a predefined value prior to enabling ECC
+ check.
+
  source "drivers/ram/aspeed/Kconfig"
  source "drivers/ram/cadence/Kconfig"
  source "drivers/ram/octeon/Kconfig"


Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Tom Rini
On Wed, May 15, 2024 at 11:39:08AM +0200, Jonas Karlman wrote:

[snip]
> My main concern is how to best handle new boards and features/drivers.
> E.g. for Rockchip the RK3588 SoC is under active development, new boards
> and features/drivers are actively added/fixed in upstream Linux.

To this question specifically, dts/update-dts-subtree.sh has a "pick"
option and in some previous quick testing, it does what one would hope.
So for this case you could pick the N commits that need to be brought
it, the resulting patch would be small enough to send to the list
normally (the resync patch for v6.9 is 2.7MB) and then when I do the
next full resync it goes cleanly still.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Tom Rini
On Wed, May 15, 2024 at 09:29:41AM +0200, Jonas Karlman wrote:
> Hi Tom,
> 
> On 2024-05-14 18:42, Tom Rini wrote:> 
> > git-subtree-dir: dts/upstream
> > git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> > ---
> > This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> > -next branch. To test these changes yourself locally, either use my
> > "WIP/14May2024-next" branch or run:
> > ./dts/update-dts-subtree.sh pull v6.9-dts
> > yourself locally. I intend to wait a few days to apply this to -next, to
> > give people time to test.
> > 
> 
> There are currently more boards/SoCs that use OF_UPSTREAM in master
> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> Next dts/upstream sync will probably be good to do together with a merge
> of master into next :-)

Yeah, with -rc3 I'll pull that in to next. And I did this sync now since
Quentin reminded me on IRC about it. The massive CC list comes from
using qconfig.py to see who enables it, and then a quick one-off to get
a list out of get_maintainers.pl.

> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> probably be released shortly after U-Boot v2024.07. So will next sync be
> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> U-Boot merge window?

So, I need to put something in to doc/develop/process.rst about when the
full dts/upstream resyncs happen, and where. The plan currently is every
Linux kernel release gets pulled in, and master or next depends on if
the -next branch is open (which is with -rc2). This should give us the
most time to get changes tested, while minimizing drift away from
upstream sources. This is also because, and related to, that I try and
make sure that nothing breaking comes in to master once next is open,
and so if a board maintainer has time to test things at -rc3 or what
have you, it should still work in the release proper. More testing is
always great, but given our release cadence and generally predictable
schedule, I am hopeful this provides the best trade-offs in terms of
time demands on board maintainers.

> Linux kernel typically have all major DT changes in -rc1 and fixes in
> later -rcX, so for next branch I would suggest an early sync to a
> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> gets released. That should give more time for testing, migration and
> cleanup using v6.10 DTs in time for a 2024.10 release.

The issue in my mind is that we just don't have a lot of people with
time to test things in U-Boot. So I'd rather avoid possible broken
upstream and then fixed later upstream problems. And having done it now,
I can also say it's really easy to use dts/update-dts-subtree.sh so if
someone has time they can do that locally.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot

2024-05-15 Thread Marek Vasut

On 3/6/24 1:55 PM, Michael Walle wrote:

Hi,

On Wed Mar 6, 2024 at 3:56 AM CET, Marek Vasut wrote:

I'd argue if one wants to use the locking at all, you have to set
UNLOCK_ALL=n. Otherwise, the bootloader might come alone and just
clear your locking bits again. Clearing the WPS bit there is just
one more thing which IMHO doesn't make much sense.


On the other hand, if UNLOCK_ALL=y is supposed to work and reset
locking, then the SR3 WPS bit has to be configured to select the
standard SPI NOR locking scheme, so the locking can actually be reset
using that scheme.


Yes, that's what I've meant with "the unlock all works as
advertised" and your patch is fine.


Can this be applied ?


Re: [PATCH u-boot-mvebu 10/10] arm: mvebu: turris_omnia: Support old DDR3 training, selectable via env var

2024-05-15 Thread Stefan Roese

On 5/15/24 11:24, Marek Behún wrote:

On Wed, 15 May 2024 11:10:09 +0200
Stefan Roese  wrote:


Hi Marek,

On 5/15/24 10:59, Marek Behún wrote:

On Mon, 6 May 2024 12:03:55 +0200
Stefan Roese  wrote:
   

Hi Marek,

On 4/15/24 18:30, Marek Behún wrote:

Support old DDR3 training code on Turris Omnia, selectable by U-Boot
enviroment variable.

Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting the
environment variable
 env set omnia_ddr3_training old
 env save

Signed-off-by: Marek Behún 
---
arch/arm/mach-mvebu/Kconfig   |  1 +
board/CZ.NIC/turris_omnia/Makefile|  1 +
board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 +++
board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 +-
4 files changed, 82 insertions(+), 1 deletion(-)
create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c


For turris_omnia_defconfig, this is dropped when compiled:

drivers/ddr/marvell/a38x/old/ddr3_debug.c:776:12: warning:
'ddr3_tip_access_atr' declared 'static' but never defined
[-Wunused-function]
 776 | static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, u32
value, u32 **ptr);
 |^~~


And it also seems that there is still something wrong with this
old DDR training code port. Some boards still experience random bugs
with this, but not with the U-Boot from 2015. :-(


Hmmm, strange.

How to continue? Are these "old DDR training patches" on hold for now?


The first 5 patches should be fine, the "old DDR training" comes in the
second half. Is it possible to merge only the first 5? And also the one
patch I sent on April 30:
   arm: mvebu: turris_omnia: Fix ethernet PHY reset gpio FDT fixup


Yes, that might be possible. Let me check...

Thanks,
Stefan


[PATCH v1 2/2] board: microchip: icicle: make both ethernets optional

2024-05-15 Thread Conor Dooley
From: Conor Dooley 

A given AMP configuration for a board may make either one, or neither
of, the ethernet ports available to U-Boot. The Icicle's init code will
fail if mac1 is not present, so move it to the optional approach taken
for mac0.

Signed-off-by: Conor Dooley 
---
 board/microchip/mpfs_icicle/mpfs_icicle.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c 
b/board/microchip/mpfs_icicle/mpfs_icicle.c
index 5fd0ec66a9..4d7d843dfa 100644
--- a/board/microchip/mpfs_icicle/mpfs_icicle.c
+++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
@@ -79,18 +79,6 @@ int board_late_init(void)
char icicle_mac_addr[20];
void *blob = (void *)gd->fdt_blob;
 
-   node = fdt_path_offset(blob, "/soc/ethernet@20112000");
-   if (node < 0) {
-   printf("No ethernet0 path offset\n");
-   return -ENODEV;
-   }
-
-   ret = fdtdec_get_byte_array(blob, node, "local-mac-address", mac_addr, 
6);
-   if (ret) {
-   printf("No local-mac-address property for ethernet@20112000\n");
-   return -EINVAL;
-   }
-
read_device_serial_number(device_serial_number, 16);
 
/* Update MAC address with device serial number */
@@ -101,10 +89,13 @@ int board_late_init(void)
mac_addr[4] = device_serial_number[1];
mac_addr[5] = device_serial_number[0];
 
-   ret = fdt_setprop(blob, node, "local-mac-address", mac_addr, 6);
-   if (ret) {
-   printf("Error setting local-mac-address property for 
ethernet@20112000\n");
-   return -ENODEV;
+   node = fdt_path_offset(blob, "/soc/ethernet@20112000");
+   if (node >= 0) {
+   ret = fdt_setprop(blob, node, "local-mac-address", mac_addr, 6);
+   if (ret) {
+   printf("Error setting local-mac-address property for 
ethernet@20112000\n");
+   return -ENODEV;
+   }
}
 
icicle_mac_addr[0] = '[';
-- 
2.43.0



[PATCH v1 1/2] board: microchip: icicle: correct type for node offset

2024-05-15 Thread Conor Dooley
From: Conor Dooley 

Node offsets returned by libfdt can contain negative error numbers, so
the variable type should be "int". As things stand, if the ethernet
nodes are not found in the early init callback, the if (node < 0) tests
pass and the code errors out while trying to set the local-mac-address
for a non-existent node.

Fixes: 64413e1b7c ("riscv: Add Microchip MPFS Icicle Kit support")
Signed-off-by: Conor Dooley 
---
 board/microchip/mpfs_icicle/mpfs_icicle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c 
b/board/microchip/mpfs_icicle/mpfs_icicle.c
index 7beac33cfb..5fd0ec66a9 100644
--- a/board/microchip/mpfs_icicle/mpfs_icicle.c
+++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
@@ -72,7 +72,7 @@ int board_early_init_f(void)
 int board_late_init(void)
 {
u32 ret;
-   u32 node;
+   int node;
u8 idx;
u8 device_serial_number[16] = { 0 };
unsigned char mac_addr[6];
-- 
2.43.0



[PATCH v1 0/2] Two mpfs icicle init fixes

2024-05-15 Thread Conor Dooley
From: Conor Dooley 

Two fixes for issues that I spotted today while looking into passing a
minimal dtb to U-Boot from the first bootloader stage. This minimal dtb
had no ethernet nodes, and the code in this patches fell over :\

Cheers,
Conor.
---
CC: Padmarao Begari 
CC: Cyril Jean 
CC: Tom Rini 
CC: Conor Dooley 
CC: u-boot@lists.denx.de

Conor Dooley (2):
  board: microchip: icicle: correct type for node offset
  board: microchip: icicle: make both ethernets optional

 board/microchip/mpfs_icicle/mpfs_icicle.c | 25 ---
 1 file changed, 8 insertions(+), 17 deletions(-)

-- 
2.43.0



Re: [PATCH v2 4/4] include: Move snprintf to stdio.h

2024-05-15 Thread Tom Rini
On Wed, May 15, 2024 at 05:31:59AM -0700, Raymond Mao wrote:

> Move snprintf to stdio.h since it is needed by exteranl libraries.
> 
> Signed-off-by: Raymond Mao 

Thanks for doing the work. One problem:

> diff --git a/include/stdio.h b/include/stdio.h
> index 3241e2d493f..ecd0f996efb 100644
> --- a/include/stdio.h
> +++ b/include/stdio.h
> @@ -45,6 +45,7 @@ static inline int vprintf(const char *fmt, va_list args)
>   return 0;
>  }
>  #endif
> +int snprintf(char *buf, size_t size, const char *fmt, ...);
>  
>  /*
>   * FILE based functions (can only be used AFTER relocation!)
> diff --git a/include/vsprintf.h b/include/vsprintf.h
> index ed8a060ee17..fe951471426 100644
> --- a/include/vsprintf.h
> +++ b/include/vsprintf.h
> @@ -218,23 +218,6 @@ char *simple_itoa(ulong val);
>   */
>  char *simple_xtoa(ulong num);
>  
> -/**
> - * Format a string and place it in a buffer
> - *
> - * @buf: The buffer to place the result into
> - * @size: The size of the buffer, including the trailing null space
> - * @fmt: The format string to use
> - * @...: Arguments for the format string
> - * Return: the number of characters which would be
> - * generated for the given input, excluding the trailing null,
> - * as per ISO C99.  If the return is greater than or equal to
> - * @size, the resulting string is truncated.
> - *
> - * See the vsprintf() documentation for format string extensions over C99.
> - */
> -int snprintf(char *buf, size_t size, const char *fmt, ...)
> - __attribute__ ((format (__printf__, 3, 4)));
> -
>  /**
>   * Format a string and place it in a buffer
>   *

Please move the whole thing, comment and attributes over not just the
basic prototype, thanks.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2 2/2] drivers: misc: Add driver to access ZynqMP efuses

2024-05-15 Thread lukas . funke-oss
From: Lukas Funke 

Add driver to access ZynqMP efuses. This is a u-boot port of [1].

[1] 
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/

Signed-off-by: Lukas Funke 
---

Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)

 drivers/misc/Kconfig|   8 +
 drivers/misc/Makefile   |   1 +
 drivers/misc/zynqmp_efuse.c | 324 
 3 files changed, 333 insertions(+)
 create mode 100644 drivers/misc/zynqmp_efuse.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
  Security Monitor can be transitioned on any security failures,
  like software violations or hardware security violations.
 
+config ZYNQMP_EFUSE
+   bool "Enable ZynqMP eFUSE Driver"
+   depends on ZYNQMP_FIRMWARE
+   help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security 
related
+ and cannot be read back (i.e. AES key).
+
 choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
 obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
 obj-$(CONFIG_SL28CPLD) += sl28cpld.o
 obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..98a39c1ebdd
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK 0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES   (4)
+#define SOC_VER_SIZE   (0x4)
+#define SOC_VERSION_OFFSET (0x0)
+#define EFUSE_START_OFFSET (0xC)
+#define EFUSE_END_OFFSET   (0xFC)
+#define EFUSE_PUF_START_OFFSET (0x100)
+#define EFUSE_PUF_MID_OFFSET   (0x140)
+#define EFUSE_PUF_END_OFFSET   (0x17F)
+#define EFUSE_NOT_ENABLED  (29)
+#define EFUSE_READ (0)
+#define EFUSE_WRITE(1)
+
+/**
+ * struct efuse_map_entry - offset and length of zynqmp fuses
+ * @offset:offset of efuse to be read/write
+ * @length:length of efuse
+ */
+struct efuse_map_entry {
+   u32 offset;
+   u32 length;
+};
+
+struct efuse_map_entry zynqmp_efuse_table[] = {
+   {0x000, 0x04}, /* soc revision */
+   {0x00c, 0x0c}, /* SoC DNA */
+   {0x020, 0x04}, /* efuse-usr0 */
+   {0x024, 0x04}, /* efuse-usr1 */
+   {0x028, 0x04}, /* efuse-usr2 */
+   {0x02c, 0x04}, /* efuse-usr3 */
+   {0x030, 0x04}, /* efuse-usr4 */
+   {0x034, 0x04}, /* efuse-usr5 */
+   {0x038, 0x04}, /* efuse-usr6 */
+   {0x03c, 0x04}, /* efuse-usr7 */
+   {0x040, 0x04}, /* efuse-miscusr */
+   {0x050, 0x04}, /* efuse-chash */
+   {0x054, 0x04}, /* efuse-pufmisc */
+   {0x058, 0x04}, /* efuse-sec */
+   {0x05c, 0x04}, /* efuse-spkid */
+   {0x060, 0x30}, /* efuse-aeskey */
+   {0x0a0, 0x30}, /* ppk0-hash */
+   {0x0d0, 0x30}, /* ppk1-hash */
+   {0x100, 0x7f}, /* pufuser */
+};
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src:   address of the buffer to store the data to be write/read
+ * @size:  no of words to be read/write
+ * @offset:offset to be read/write`
+ * @flag:  0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+   u64 src;
+   u32 size;
+   u32 offset;
+   u32 flag;
+   u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_get_length(u32 offset, u32 *base_offset, u32 *len)
+{
+   struct efuse_map_entry *fuse;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(zynqmp_efuse_table); ++i) {
+   fuse = _efuse_table[i];
+   if (offset >= fuse->offset &&
+   offset < fuse->offset + fuse->length) {
+   *base_offset = fuse->offset;
+   *len = fuse->length;
+   return 0;
+   }
+   }
+
+   return -ENOENT;
+}
+
+static int zynqmp_efuse_access(struct udevice *dev, unsigned int offset,
+ 

[PATCH v2 1/2] firmware: zynqmp: Add support to access efuses

2024-05-15 Thread lukas . funke-oss
From: Lukas Funke 

Add functions to access efuses through PMU firmware
interface.

Signed-off-by: Lukas Funke 
---

(no changes since v1)

 drivers/firmware/firmware-zynqmp.c | 31 ++
 include/zynqmp_firmware.h  |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/firmware/firmware-zynqmp.c 
b/drivers/firmware/firmware-zynqmp.c
index f99507d86c6..d7fbe6a3efb 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -210,6 +210,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
 }
 
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!idcode || !version)
+   return -EINVAL;
+
+   ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+   *idcode = ret_payload[1];
+   *version = ret_payload[2];
+
+   return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!out)
+   return -EINVAL;
+
+   ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+   lower_32_bits(address), 0, 0, ret_payload);
+
+   *out = ret_payload[1];
+
+   return ret;
+}
+
 int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
 {
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32 
arg2,
 int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 
value);
 int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
 u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
 int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
 int zynqmp_mmio_read(const u32 address, u32 *value);
 int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
-- 
2.30.2



[PATCH v2 0/2] Add eFuse access for ZynqMP

2024-05-15 Thread lukas . funke-oss
From: Lukas Funke 


This series adds a driver to read and write ZynqMP eFuses [1]. The
driver can be accessed by the 'fuse read' and 'fuse write' commands

Example:

=> fuse read 0 0xc 3
Reading bank 0:

Word 0x000c: 3cb16685 013af244 4000

Note: Accessing eFuses requires eFuse access to be enabled in the
underlying PMU firmware.

Use cases are:
 - Reading/writing user specific eFuses to enable device specific
   implementations
 - Revoking SPK IDs
 - Reading SoC version/DNA

[1] https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/eFUSE


Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)

Lukas Funke (2):
  firmware: zynqmp: Add support to access efuses
  drivers: misc: Add driver to access ZynqMP efuses

 drivers/firmware/firmware-zynqmp.c |  31 +++
 drivers/misc/Kconfig   |   8 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/zynqmp_efuse.c| 324 +
 include/zynqmp_firmware.h  |   2 +
 5 files changed, 366 insertions(+)
 create mode 100644 drivers/misc/zynqmp_efuse.c

-- 
2.30.2



[NFS] fetching kernel via nfs

2024-05-15 Thread Johannes Kirchmair - SKIDATA
Dear u-boot people,

I encountered some problems trying to fetch the Linux kernel via nfs (v3).
One problem was that the nfs file lookup always returned NFS3ERR_BADHANDLE.
This is due to the following line in nfs_lookup_req() function (net/nfs.c):

len = (uint32_t *)p - (uint32_t *)&(data[0]);
rpc_req(PROG_NFS, NFS_LOOKUP, data, len);
} else {  /* NFS_V3 */
*p++ = htonl(NFS_FHSIZE);   /* Dir handle length */
<=  this line
memcpy(p, dirfh, NFS_FHSIZE);
p += (NFS_FHSIZE / 4);
*p++ = htonl(fnamelen);

In the NFS_V3 case we add the dir file handle  size to data and then the dir 
file handle.
IUC, this is not correct here because dirfh includes already the size of the 
handle in the first 4 bytes.
Feel free to correct me if I am wrong.

As a result, if I remove the line "*p++ = htonl(NFS_FHSIZE);", it works fine.

Don't have an in deps understanding of nfs, so I am not sure if this is the 
root problem here.

Best regards Johannes


[PATCH v2 4/4] include: Move snprintf to stdio.h

2024-05-15 Thread Raymond Mao
Move snprintf to stdio.h since it is needed by exteranl libraries.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch.

 arch/arc/lib/cpu.c |  2 +-
 board/Synology/common/legacy.c |  1 +
 board/ti/common/fdt_ops.c  |  2 +-
 cmd/part.c |  2 +-
 common/button_cmd.c|  2 +-
 drivers/cpu/mpc83xx_cpu.c  |  2 +-
 include/stdio.h|  1 +
 include/vsprintf.h | 17 -
 lib/display_options.c  |  1 +
 lib/fwu_updates/fwu_mtd.c  |  2 +-
 lib/hexdump.c  |  2 +-
 lib/vsprintf.c |  1 +
 test/dm/scmi.c |  2 +-
 test/print_ut.c|  1 +
 14 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
index 593950449f2..269b4dbdd15 100644
--- a/arch/arc/lib/cpu.c
+++ b/arch/arc/lib/cpu.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/board/Synology/common/legacy.c b/board/Synology/common/legacy.c
index a0bace7b46c..2e3aa660eaa 100644
--- a/board/Synology/common/legacy.c
+++ b/board/Synology/common/legacy.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
index eb917be9e0d..8a3300993ed 100644
--- a/board/ti/common/fdt_ops.c
+++ b/board/ti/common/fdt_ops.c
@@ -6,7 +6,7 @@
  */
 
 #include 
-#include 
+#include 
 #include "fdt_ops.h"
 
 void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
diff --git a/cmd/part.c b/cmd/part.c
index c75f85acd52..b1c06064ad5 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -20,7 +20,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 enum cmd_part_info {
CMD_PART_INFO_START = 0,
diff --git a/common/button_cmd.c b/common/button_cmd.c
index 8642c26735c..72dac1f9ef6 100644
--- a/common/button_cmd.c
+++ b/common/button_cmd.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* Some sane limit "just in case" */
 #define MAX_BTN_CMDS 32
diff --git a/drivers/cpu/mpc83xx_cpu.c b/drivers/cpu/mpc83xx_cpu.c
index e451c6a..5b2d0485258 100644
--- a/drivers/cpu/mpc83xx_cpu.c
+++ b/drivers/cpu/mpc83xx_cpu.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "mpc83xx_cpu.h"
diff --git a/include/stdio.h b/include/stdio.h
index 3241e2d493f..ecd0f996efb 100644
--- a/include/stdio.h
+++ b/include/stdio.h
@@ -45,6 +45,7 @@ static inline int vprintf(const char *fmt, va_list args)
return 0;
 }
 #endif
+int snprintf(char *buf, size_t size, const char *fmt, ...);
 
 /*
  * FILE based functions (can only be used AFTER relocation!)
diff --git a/include/vsprintf.h b/include/vsprintf.h
index ed8a060ee17..fe951471426 100644
--- a/include/vsprintf.h
+++ b/include/vsprintf.h
@@ -218,23 +218,6 @@ char *simple_itoa(ulong val);
  */
 char *simple_xtoa(ulong num);
 
-/**
- * Format a string and place it in a buffer
- *
- * @buf: The buffer to place the result into
- * @size: The size of the buffer, including the trailing null space
- * @fmt: The format string to use
- * @...: Arguments for the format string
- * Return: the number of characters which would be
- * generated for the given input, excluding the trailing null,
- * as per ISO C99.  If the return is greater than or equal to
- * @size, the resulting string is truncated.
- *
- * See the vsprintf() documentation for format string extensions over C99.
- */
-int snprintf(char *buf, size_t size, const char *fmt, ...)
-   __attribute__ ((format (__printf__, 3, 4)));
-
 /**
  * Format a string and place it in a buffer
  *
diff --git a/lib/display_options.c b/lib/display_options.c
index d6b93553dcb..d5df53ab15f 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 char *display_options_get_banner_priv(bool newlines, const char *build_tag,
diff --git a/lib/fwu_updates/fwu_mtd.c b/lib/fwu_updates/fwu_mtd.c
index 69cd3d7001f..4a52834b61a 100644
--- a/lib/fwu_updates/fwu_mtd.c
+++ b/lib/fwu_updates/fwu_mtd.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 33e3e6e5182..2bc508ff504 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -10,7 +10,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 27ea9c907a3..cfd1f1914ed 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/test/dm/scmi.c b/test/dm/scmi.c
index adf36ffaab1..a03824ab653 100644
--- a/test/dm/scmi.c
+++ b/test/dm/scmi.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/test/print_ut.c b/test/print_ut.c
index 

[PATCH v2 3/4] md5: Use typedef for MD5 context

2024-05-15 Thread Raymond Mao
Use of typedef is beneficial for porting with other crypto libs
without changing the API callers.
Secondly, it is for the code consistency with other digest libs.
SHA1, SHA256 and SHA512 are all using typedef for their context.

Signed-off-by: Raymond Mao 
Reviewed-by: Tom Rini 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- None.

 drivers/crypto/hash/hash_sw.c |  8 
 include/u-boot/md5.h  | 10 +-
 lib/md5.c | 10 +-
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/hash/hash_sw.c b/drivers/crypto/hash/hash_sw.c
index d8065d68ea4..a5033677930 100644
--- a/drivers/crypto/hash/hash_sw.c
+++ b/drivers/crypto/hash/hash_sw.c
@@ -51,17 +51,17 @@ static void hash_finish_crc32(void *ctx, void *obuf)
 /* MD5 */
 static void hash_init_md5(void *ctx)
 {
-   MD5Init((struct MD5Context *)ctx);
+   MD5Init((MD5Context *)ctx);
 }
 
 static void hash_update_md5(void *ctx, const void *ibuf, uint32_t ilen)
 {
-   MD5Update((struct MD5Context *)ctx, ibuf, ilen);
+   MD5Update((MD5Context *)ctx, ibuf, ilen);
 }
 
 static void hash_finish_md5(void *ctx, void *obuf)
 {
-   MD5Final(obuf, (struct MD5Context *)ctx);
+   MD5Final(obuf, (MD5Context *)ctx);
 }
 
 /* SHA1 */
@@ -159,7 +159,7 @@ static struct sw_hash_impl sw_hash_impl[HASH_ALGO_NUM] = {
.init = hash_init_md5,
.update = hash_update_md5,
.finish = hash_finish_md5,
-   .ctx_alloc_sz = sizeof(struct MD5Context),
+   .ctx_alloc_sz = sizeof(MD5Context),
},
 
[HASH_ALGO_SHA1] = {
diff --git a/include/u-boot/md5.h b/include/u-boot/md5.h
index d61364c0ae3..c465925ea8d 100644
--- a/include/u-boot/md5.h
+++ b/include/u-boot/md5.h
@@ -10,18 +10,18 @@
 
 #define MD5_SUM_LEN16
 
-struct MD5Context {
+typedef struct MD5Context {
__u32 buf[4];
__u32 bits[2];
union {
unsigned char in[64];
__u32 in32[16];
};
-};
+} MD5Context;
 
-void MD5Init(struct MD5Context *ctx);
-void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len);
-void MD5Final(unsigned char digest[16], struct MD5Context *ctx);
+void MD5Init(MD5Context *ctx);
+void MD5Update(MD5Context *ctx, unsigned char const *buf, unsigned int len);
+void MD5Final(unsigned char digest[16], MD5Context *ctx);
 
 /*
  * Calculate and store in 'output' the MD5 digest of 'len' bytes at
diff --git a/lib/md5.c b/lib/md5.c
index faf3f78ab1e..34343cf8e23 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -55,7 +55,7 @@ byteReverse(unsigned char *buf, unsigned longs)
  * initialization constants.
  */
 void
-MD5Init(struct MD5Context *ctx)
+MD5Init(MD5Context *ctx)
 {
ctx->buf[0] = 0x67452301;
ctx->buf[1] = 0xefcdab89;
@@ -71,7 +71,7 @@ MD5Init(struct MD5Context *ctx)
  * of bytes.
  */
 void
-MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
+MD5Update(MD5Context *ctx, unsigned char const *buf, unsigned int len)
 {
register __u32 t;
 
@@ -120,7 +120,7 @@ MD5Update(struct MD5Context *ctx, unsigned char const *buf, 
unsigned len)
  * 1 0* (64-bit count of bits processed, MSB-first)
  */
 void
-MD5Final(unsigned char digest[16], struct MD5Context *ctx)
+MD5Final(unsigned char digest[16], MD5Context *ctx)
 {
unsigned int count;
unsigned char *p;
@@ -269,7 +269,7 @@ MD5Transform(__u32 buf[4], __u32 const in[16])
 void
 md5 (unsigned char *input, int len, unsigned char output[16])
 {
-   struct MD5Context context;
+   MD5Context context;
 
MD5Init();
MD5Update(, input, len);
@@ -286,7 +286,7 @@ void
 md5_wd(const unsigned char *input, unsigned int len, unsigned char output[16],
unsigned int chunk_sz)
 {
-   struct MD5Context context;
+   MD5Context context;
 #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
const unsigned char *end, *curr;
int chunk;
-- 
2.25.1



[PATCH v2 2/4] efi_loader: remove redundant hash includes

2024-05-15 Thread Raymond Mao
Remove the redundant includes of u-boot/sha1.h, u-boot/sha256.h
and u-boot/sha512.h

Signed-off-by: Raymond Mao 
Reviewed-by: Tom Rini 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- None.

 lib/efi_loader/efi_signature.c | 1 -
 lib/efi_loader/efi_tcg2.c  | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
index f338e732759..184eac8cddb 100644
--- a/lib/efi_loader/efi_signature.c
+++ b/lib/efi_loader/efi_signature.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 
 const efi_guid_t efi_guid_sha256 = EFI_CERT_SHA256_GUID;
 const efi_guid_t efi_guid_cert_rsa2048 = EFI_CERT_RSA2048_GUID;
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index b07e0099c27..ac056dcfc55 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -19,9 +19,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1



[PATCH v2 1/4] image: remove redundant hash includes

2024-05-15 Thread Raymond Mao
Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
u-boot/sha256.h and u-boot/sha512.h

Signed-off-by: Raymond Mao 
Reviewed-by: Tom Rini 
Reviewed-by: Igor Opaniuk 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- None.

 boot/image-fit.c | 4 
 boot/image.c | 2 --
 2 files changed, 6 deletions(-)

diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563ce..1efc39f4408 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -38,10 +38,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
 
 /*/
 /* New uImage format routines */
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a3..e57d6eae52d 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -26,8 +26,6 @@
 #endif
 
 #include 
-#include 
-#include 
 #include 
 #include 
 
-- 
2.25.1



[PATCH v2 0/4] Clean-up patch set for MbedTLS integration

2024-05-15 Thread Raymond Mao
This patch set is picked from the previously posted serie:
"[RFC] Integrate MbedTLS v3.6 LTS with U-Boot"

They are not directly related to MbedTLS integration, but the
prerequisite for a few clean-up, refactoring and minor fixes.

For V2, the linker script patch is dropped and added one patch
to move the snprintf to stdio.h

Raymond Mao (4):
  image: remove redundant hash includes
  efi_loader: remove redundant hash includes
  md5: Use typedef for MD5 context
  include: Move snprintf to stdio.h

 arch/arc/lib/cpu.c |  2 +-
 board/Synology/common/legacy.c |  1 +
 board/ti/common/fdt_ops.c  |  2 +-
 boot/image-fit.c   |  4 
 boot/image.c   |  2 --
 cmd/part.c |  2 +-
 common/button_cmd.c|  2 +-
 drivers/cpu/mpc83xx_cpu.c  |  2 +-
 drivers/crypto/hash/hash_sw.c  |  8 
 include/stdio.h|  1 +
 include/u-boot/md5.h   | 10 +-
 include/vsprintf.h | 17 -
 lib/display_options.c  |  1 +
 lib/efi_loader/efi_signature.c |  1 -
 lib/efi_loader/efi_tcg2.c  |  3 ---
 lib/fwu_updates/fwu_mtd.c  |  2 +-
 lib/hexdump.c  |  2 +-
 lib/md5.c  | 10 +-
 lib/vsprintf.c |  1 +
 test/dm/scmi.c |  2 +-
 test/print_ut.c|  1 +
 21 files changed, 27 insertions(+), 49 deletions(-)

-- 
2.25.1



[PATCH] memory: ti-gpmc: use printf to dump settings/timings

2024-05-15 Thread Roger Quadros
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has
enabled CONFIG_TI_GPMC_DEBUG then we should print the
GPMC settings/timings regardless of CONFIG_LOGLEVEL.

So use printf() instead of pr_info().

Signed-off-by: Roger Quadros 
---
 drivers/memory/ti-gpmc.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
index 8af48e199a7..e979c431e33 100644
--- a/drivers/memory/ti-gpmc.c
+++ b/drivers/memory/ti-gpmc.c
@@ -242,20 +242,20 @@ static int get_gpmc_timing_reg(/* timing specifiers */
if (l)
time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1;
time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
-   pr_info("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n",
-   name, time_ns, time_ns_min, time_ns, l,
-   invalid ? "; invalid " : " ");
+   printf("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n",
+  name, time_ns, time_ns_min, time_ns, l,
+  invalid ? "; invalid " : " ");
} else {
/* raw format */
-   pr_info("gpmc,%s = <%u>;%s\n", name, l,
-   invalid ? " /* invalid */" : "");
+   printf("gpmc,%s = <%u>;%s\n", name, l,
+  invalid ? " /* invalid */" : "");
}
 
return l;
 }
 
 #define GPMC_PRINT_CONFIG(cs, config) \
-   pr_info("CS%i %s: 0x%08x\n", cs, #config, \
+   printf("CS%i %s: 0x%08x\n", cs, #config, \
gpmc_cs_read_reg(cs, config))
 #define GPMC_GET_RAW(reg, st, end, field) \
get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0, 
1, 0)
@@ -274,7 +274,7 @@ static int get_gpmc_timing_reg(/* timing specifiers */
 
 static void gpmc_show_regs(int cs, const char *desc)
 {
-   pr_info("gpmc cs%i %s:\n", cs, desc);
+   printf("gpmc cs%i %s:\n", cs, desc);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG1);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG2);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG3);
@@ -291,7 +291,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
 {
gpmc_show_regs(cs, desc);
 
-   pr_info("gpmc cs%i access configuration:\n", cs);
+   printf("gpmc cs%i access configuration:\n", cs);
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1,  4,  4, "time-para-granularity");
GPMC_GET_RAW(GPMC_CS_CONFIG1,  8,  9, "mux-add-data");
GPMC_GET_RAW_SHIFT_MAX(GPMC_CS_CONFIG1, 12, 13, 1,
@@ -318,7 +318,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6,  7,  7, "cycle2cycle-samecsen");
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6,  6,  6, "cycle2cycle-diffcsen");
 
-   pr_info("gpmc cs%i timings configuration:\n", cs);
+   printf("gpmc cs%i timings configuration:\n", cs);
GPMC_GET_TICKS(GPMC_CS_CONFIG2,  0,  3, "cs-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG2,  8, 12, "cs-rd-off-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG2, 16, 20, "cs-wr-off-ns");
@@ -409,9 +409,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, 
int end_bit, int max
 
l = gpmc_cs_read_reg(cs, reg);
if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) {
-   pr_info("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) 
%3d ns\n",
-   cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 
1000,
-   (l >> st_bit) & mask, time);
+   printf("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) 
%3d ns\n",
+  cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 
1000,
+  (l >> st_bit) & mask, time);
}
 
l &= ~(mask << st_bit);
@@ -618,8 +618,8 @@ static int gpmc_cs_set_timings(int cs, const struct 
gpmc_timings *t,
return -ENXIO;
 
if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) {
-   pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n",
-   cs, (div * gpmc_get_fclk_period()) / 1000, div);
+   printf("GPMC CS%d CLK period is %lu ns (div %d)\n",
+  cs, (div * gpmc_get_fclk_period()) / 1000, div);
}
 
gpmc_cs_bool_timings(cs, >bool_timings);

---
base-commit: e7992828adcd5fad75bce9e6c41dfa9277ab93b0
change-id: 20240515-for-2024-10-gpmc-printf-dcd5f446d951

Best regards,
-- 
Roger Quadros 



AW: Use header file from external library in u-boot

2024-05-15 Thread Johannes Kirchmair - SKIDATA
Dear Fabio and Lukas, 

will have a thanks for your suggestions. I will have a look at it. 

Best regards 
Johannes

-Ursprüngliche Nachricht-
Von: Lukas Funke  
Gesendet: Donnerstag, 2. Mai 2024 15:33
An: u-boot@lists.denx.de; Johannes Kirchmair - SKIDATA 

Betreff: Re: Use header file from external library in u-boot

EXTERNAL EMAIL


On 02.05.2024 08:57, Johannes Kirchmair - SKIDATA wrote:
> Dear u-boot folks,
>
> we are trying to share some information between u-boot and a Linux user space 
> tool. For this we place some information in a FRAM. This information is just 
> some numeric values, indicating some wanted behaviour. I thought of using a 
> header file to keep these values aligned between the user space tool and 
> u-boot. This header is provided by a library.  Including it into the user 
> space tool is straight forward, but into u-boot does seem complicated, as the 
> build system is not meant to include external libraries. Is there a preferred 
> way to do this kind of alignment or a suggestion on how to handle this?
>
> Best regards
> Johannes

How about writing it into the linux device-tree. 'bootstage' does this in the 
same way if I remember correctly.



Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Sumit Garg
On Wed, 15 May 2024 at 15:09, Jonas Karlman  wrote:
>
> Hi Sumit,
>
> On 2024-05-15 10:49, Sumit Garg wrote:
> > Hi Jonas,
> >
> > On Wed, 15 May 2024 at 13:11, Jonas Karlman  wrote:
> >>
> >> Hi Tom,
> >>
> >> On 2024-05-14 18:42, Tom Rini wrote:>
> >>> git-subtree-dir: dts/upstream
> >>> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> >>> ---
> >>> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> >>> -next branch. To test these changes yourself locally, either use my
> >>> "WIP/14May2024-next" branch or run:
> >>> ./dts/update-dts-subtree.sh pull v6.9-dts
> >>> yourself locally. I intend to wait a few days to apply this to -next, to
> >>> give people time to test.
> >>>
> >>
> >> There are currently more boards/SoCs that use OF_UPSTREAM in master
> >> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> >
> > Glad to see more OF_UPSTREAM adoption.
> >
> >> Next dts/upstream sync will probably be good to do together with a merge
> >> of master into next :-)
> >
> > I don't have any particular opinion here and rather leave it upto Tom
> > how he would like to merge stuff.
> >
> >>
> >> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> >> probably be released shortly after U-Boot v2024.07. So will next sync be
> >> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> >> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> >> U-Boot merge window?
> >>
> >> Linux kernel typically have all major DT changes in -rc1 and fixes in
> >> later -rcX, so for next branch I would suggest an early sync to a
> >> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> >> gets released. That should give more time for testing, migration and
> >> cleanup using v6.10 DTs in time for a 2024.10 release.
> >
> > I can see the reasoning for an aggressive DT syncing approach, it has
> > been brought up in the past too. And the major reason for the current
> > moderate sync approach [1] is to limit any DT ABI breakages for
> > U-Boot, we are even prone to breakages with syncs against major Linux
> > kernel releases (eg. v6.10-dts etc.). It has been a long time
> > discussion topic where we have been advocating about requirements for
> > DT ABI stability [2].
> >
> > So having DT syncs done during the merge window will shorten the
> > testing window for developers/maintainers. And more syncs means a
> > multiplicative factor for testing. However, time will tell with more
> > and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
> > breakages seen in the future. But surely if they are very rare then I
> > am open to adopting aggressive DT sync approaches.
>
> I agree that syncing multiple rcX tags may not be that helpful, but an
> approach where maybe rc1, rc2 or rc3 and then the final tag is merged or
> something similar. At least when we can foresee when next Linux version
> will be released close to an U-Boot release. At least early in U-Boot
> release cycle know what Linux version dts/upstream will be targeted.
>
> My main concern is how to best handle new boards and features/drivers.
> E.g. for Rockchip the RK3588 SoC is under active development, new boards
> and features/drivers are actively added/fixed in upstream Linux.
>
> New Rockchip boards have typically been added after board DT have been
> merged into linux maintainer tree. Now if we wait until merge window to
> do a dts/upstream sync, the result may be that it may take up to three
> U-Boot releases until a new board is easily added using dts/upstream.
>
> Another approach could be that we add new boards using !OF_UPSTREAM once
> they are merged into linux maintainer tree. And then migrate the board
> to use OF_UPSTREAM once the board finally ends up in dts/upstream.
>
> But that can also be problematic when board .dts-file start referencing
> nodes/symbols not yet added in the soc .dts-file in dts/upstream.
> Adding the "missing" but maintainer merged soc nodes to the soc
> u-boot.dtsi could be one way to work around such issue.

I would suggest you to then maintain the under development soc
.dts-file in U-Boot too. Since with !OF_UPSTREAM, the soc .dts-file
present in the U-Boot DTS tree (arch/${ARCH}/dts/) will be used
instead of one from dts/upstream. This was especially done to support
use-cases like this via the directory include ordering. You can later
switch once you think the board is well supported by dts/upstream.

>
> Anyway, some guidance, predictability and earlier sync related to
> dts/upstream would be much appreciated :-)

IMHO, let's try to provide a stable base to encourage further adoption
of OF_UPSTREAM and have sufficient data regarding DT ABI stability.
IOW, let's stick to the current moderate sync approach for a few more
U-Boot releases. My motivation has really been to reduce
developers/maintainers' pain regarding DT maintenance in U-Boot.

-Sumit

>
> Regards,
> Jonas
>
> >
> > [1] 
> > 

Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Jonas Karlman
Hi Sumit,

On 2024-05-15 10:49, Sumit Garg wrote:
> Hi Jonas,
> 
> On Wed, 15 May 2024 at 13:11, Jonas Karlman  wrote:
>>
>> Hi Tom,
>>
>> On 2024-05-14 18:42, Tom Rini wrote:>
>>> git-subtree-dir: dts/upstream
>>> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
>>> ---
>>> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
>>> -next branch. To test these changes yourself locally, either use my
>>> "WIP/14May2024-next" branch or run:
>>> ./dts/update-dts-subtree.sh pull v6.9-dts
>>> yourself locally. I intend to wait a few days to apply this to -next, to
>>> give people time to test.
>>>
>>
>> There are currently more boards/SoCs that use OF_UPSTREAM in master
>> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> 
> Glad to see more OF_UPSTREAM adoption.
> 
>> Next dts/upstream sync will probably be good to do together with a merge
>> of master into next :-)
> 
> I don't have any particular opinion here and rather leave it upto Tom
> how he would like to merge stuff.
> 
>>
>> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
>> probably be released shortly after U-Boot v2024.07. So will next sync be
>> to v6.10-dts if that happens in the U-Boot merge window or do we expect
>> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
>> U-Boot merge window?
>>
>> Linux kernel typically have all major DT changes in -rc1 and fixes in
>> later -rcX, so for next branch I would suggest an early sync to a
>> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
>> gets released. That should give more time for testing, migration and
>> cleanup using v6.10 DTs in time for a 2024.10 release.
> 
> I can see the reasoning for an aggressive DT syncing approach, it has
> been brought up in the past too. And the major reason for the current
> moderate sync approach [1] is to limit any DT ABI breakages for
> U-Boot, we are even prone to breakages with syncs against major Linux
> kernel releases (eg. v6.10-dts etc.). It has been a long time
> discussion topic where we have been advocating about requirements for
> DT ABI stability [2].
> 
> So having DT syncs done during the merge window will shorten the
> testing window for developers/maintainers. And more syncs means a
> multiplicative factor for testing. However, time will tell with more
> and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
> breakages seen in the future. But surely if they are very rare then I
> am open to adopting aggressive DT sync approaches.

I agree that syncing multiple rcX tags may not be that helpful, but an
approach where maybe rc1, rc2 or rc3 and then the final tag is merged or
something similar. At least when we can foresee when next Linux version
will be released close to an U-Boot release. At least early in U-Boot
release cycle know what Linux version dts/upstream will be targeted.

My main concern is how to best handle new boards and features/drivers.
E.g. for Rockchip the RK3588 SoC is under active development, new boards
and features/drivers are actively added/fixed in upstream Linux.

New Rockchip boards have typically been added after board DT have been
merged into linux maintainer tree. Now if we wait until merge window to
do a dts/upstream sync, the result may be that it may take up to three
U-Boot releases until a new board is easily added using dts/upstream.

Another approach could be that we add new boards using !OF_UPSTREAM once
they are merged into linux maintainer tree. And then migrate the board
to use OF_UPSTREAM once the board finally ends up in dts/upstream.

But that can also be problematic when board .dts-file start referencing
nodes/symbols not yet added in the soc .dts-file in dts/upstream.
Adding the "missing" but maintainer merged soc nodes to the soc
u-boot.dtsi could be one way to work around such issue.

Anyway, some guidance, predictability and earlier sync related to
dts/upstream would be much appreciated :-)

Regards,
Jonas

> 
> [1] 
> https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing
> [2] 
> https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg02162.html
> 
> -Sumit
> 
>>
>> Regards,
>> Jonas



Re: [PATCH u-boot-mvebu 10/10] arm: mvebu: turris_omnia: Support old DDR3 training, selectable via env var

2024-05-15 Thread Marek Behún
On Wed, 15 May 2024 11:10:09 +0200
Stefan Roese  wrote:

> Hi Marek,
> 
> On 5/15/24 10:59, Marek Behún wrote:
> > On Mon, 6 May 2024 12:03:55 +0200
> > Stefan Roese  wrote:
> >   
> >> Hi Marek,
> >>
> >> On 4/15/24 18:30, Marek Behún wrote:  
> >>> Support old DDR3 training code on Turris Omnia, selectable by U-Boot
> >>> enviroment variable.
> >>>
> >>> Users experiencing DDR3 initialization failures or random crashes of the
> >>> operating system due to incorrect DDR3 configuration can select the old
> >>> DDR3 training implementation to fix those issues by setting the
> >>> environment variable
> >>> env set omnia_ddr3_training old
> >>> env save
> >>>
> >>> Signed-off-by: Marek Behún 
> >>> ---
> >>>arch/arm/mach-mvebu/Kconfig   |  1 +
> >>>board/CZ.NIC/turris_omnia/Makefile|  1 +
> >>>board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 +++
> >>>board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 +-
> >>>4 files changed, 82 insertions(+), 1 deletion(-)
> >>>create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c  
> >>
> >> For turris_omnia_defconfig, this is dropped when compiled:
> >>
> >> drivers/ddr/marvell/a38x/old/ddr3_debug.c:776:12: warning:
> >> 'ddr3_tip_access_atr' declared 'static' but never defined
> >> [-Wunused-function]
> >> 776 | static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, u32
> >> value, u32 **ptr);
> >> |^~~  
> > 
> > And it also seems that there is still something wrong with this
> > old DDR training code port. Some boards still experience random bugs
> > with this, but not with the U-Boot from 2015. :-(  
> 
> Hmmm, strange.
> 
> How to continue? Are these "old DDR training patches" on hold for now?

The first 5 patches should be fine, the "old DDR training" comes in the
second half. Is it possible to merge only the first 5? And also the one
patch I sent on April 30:
  arm: mvebu: turris_omnia: Fix ethernet PHY reset gpio FDT fixup

Marek


Re: [PATCH 3/3] drivers: misc: Add driver to access ZynqMP efuses

2024-05-15 Thread Stefan Roese

Hi Lukas,

On 5/15/24 08:33, Lukas Funke wrote:

Hi Stefan,

On 15.05.2024 08:12, Stefan Roese wrote:

Hi Lukas,

On 5/14/24 16:04, lukas.funke-...@weidmueller.com wrote:

From: Lukas Funke 

Add driver to access ZynqMP efuses. This is a u-boot port of [1].

[1] 
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/


Signed-off-by: Lukas Funke 
---

  drivers/misc/Kconfig    |   8 ++
  drivers/misc/Makefile   |   1 +
  drivers/misc/zynqmp_efuse.c | 213 
  3 files changed, 222 insertions(+)
  create mode 100644 drivers/misc/zynqmp_efuse.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
    Security Monitor can be transitioned on any security failures,
    like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+    bool "Enable ZynqMP eFUSE Driver"
+    depends on ZYNQMP_FIRMWARE
+    help
+  Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU 
firmware
+  interface. ZnyqMP has 256 eFUSEs where some of them are 
security related

+  and cannot be read back (i.e. AES key).
+
  choice
  prompt "Security monitor interaction endianess"
  depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
  obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
  obj-$(CONFIG_SL28CPLD) += sl28cpld.o
  obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..0cfc42a4f39
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK    0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES    (4)
+#define SOC_VER_SIZE    (0x4)
+#define EFUSE_MEMORY_SIZE    (0x177)
+#define UNUSED_SPACE    (0x8)
+#define ZYNQMP_NVMEM_SIZE    (SOC_VER_SIZE + UNUSED_SPACE + \
+ EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET    (0x0)
+#define EFUSE_START_OFFSET    (0xC)
+#define EFUSE_END_OFFSET    (0xFC)
+#define EFUSE_PUF_START_OFFSET    (0x100)
+#define EFUSE_PUF_MID_OFFSET    (0x140)
+#define EFUSE_PUF_END_OFFSET    (0x17F)
+#define EFUSE_NOT_ENABLED    (29)
+#define EFUSE_READ    (0)
+#define EFUSE_WRITE    (1)
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src:    address of the buffer to store the data to be write/read
+ * @size:    no of words to be read/write
+ * @offset:    offset to be read/write`
+ * @flag:    0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for 
read/write

+ *    1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+    u64 src;
+    u32 size;
+    u32 offset;
+    u32 flag;
+    u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_access(struct udevice *dev, unsigned int 
offset,

+   void *val, size_t bytes, unsigned int flag,
+   unsigned int pufflag)
+{
+    size_t words = bytes / WORD_INBYTES;
+    ulong dma_addr, dma_buf;
+    struct xilinx_efuse *efuse;
+    char *data;
+    int ret, value;
+
+    if (bytes % WORD_INBYTES != 0) {
+    dev_err(dev, "Bytes requested should be word aligned\n");
+    return -EOPNOTSUPP;
+    }
+
+    if (pufflag == 0 && offset % WORD_INBYTES) {
+    dev_err(dev, "Offset requested should be word aligned\n");
+    return -EOPNOTSUPP;
+    }
+
+    if (pufflag == 1 && flag == EFUSE_WRITE) {
+    memcpy(, val, bytes);
+    if ((offset == EFUSE_PUF_START_OFFSET ||
+ offset == EFUSE_PUF_MID_OFFSET) &&
+    value & P_USER_0_64_UPPER_MASK) {
+    dev_err(dev, "Only lower 4 bytes are allowed to be 
programmed in P_USER_0 & P_USER_64\n");

+    return -EOPNOTSUPP;
+    }
+
+    if (offset == EFUSE_PUF_END_OFFSET &&
+    (value & P_USER_127_LOWER_4_BIT_MASK)) {
+    dev_err(dev, "Only MSB 28 bits are allowed to be 
programmed for P_USER_127\n");

+    return -EOPNOTSUPP;
+    }
+    }
+
+    efuse = dma_alloc_coherent(sizeof(struct xilinx_efuse), _addr);
+    if (!efuse)
+    return -ENOMEM;
+
+    data = dma_alloc_coherent(bytes, _buf);
+    if (!data) {
+    dma_free_coherent(efuse);
+    return -ENOMEM;
+    }

Re: [PATCH u-boot-mvebu 10/10] arm: mvebu: turris_omnia: Support old DDR3 training, selectable via env var

2024-05-15 Thread Stefan Roese

Hi Marek,

On 5/15/24 10:59, Marek Behún wrote:

On Mon, 6 May 2024 12:03:55 +0200
Stefan Roese  wrote:


Hi Marek,

On 4/15/24 18:30, Marek Behún wrote:

Support old DDR3 training code on Turris Omnia, selectable by U-Boot
enviroment variable.

Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting the
environment variable
env set omnia_ddr3_training old
env save

Signed-off-by: Marek Behún 
---
   arch/arm/mach-mvebu/Kconfig   |  1 +
   board/CZ.NIC/turris_omnia/Makefile|  1 +
   board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 +++
   board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 +-
   4 files changed, 82 insertions(+), 1 deletion(-)
   create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c


For turris_omnia_defconfig, this is dropped when compiled:

drivers/ddr/marvell/a38x/old/ddr3_debug.c:776:12: warning:
'ddr3_tip_access_atr' declared 'static' but never defined
[-Wunused-function]
776 | static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, u32
value, u32 **ptr);
|^~~


And it also seems that there is still something wrong with this
old DDR training code port. Some boards still experience random bugs
with this, but not with the U-Boot from 2015. :-(


Hmmm, strange.

How to continue? Are these "old DDR training patches" on hold for now?

Thanks,
Stefan


Re: [PATCH u-boot-mvebu 10/10] arm: mvebu: turris_omnia: Support old DDR3 training, selectable via env var

2024-05-15 Thread Marek Behún
On Mon, 6 May 2024 12:03:55 +0200
Stefan Roese  wrote:

> Hi Marek,
> 
> On 4/15/24 18:30, Marek Behún wrote:
> > Support old DDR3 training code on Turris Omnia, selectable by U-Boot
> > enviroment variable.
> > 
> > Users experiencing DDR3 initialization failures or random crashes of the
> > operating system due to incorrect DDR3 configuration can select the old
> > DDR3 training implementation to fix those issues by setting the
> > environment variable
> >env set omnia_ddr3_training old
> >env save
> > 
> > Signed-off-by: Marek Behún 
> > ---
> >   arch/arm/mach-mvebu/Kconfig   |  1 +
> >   board/CZ.NIC/turris_omnia/Makefile|  1 +
> >   board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 +++
> >   board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 +-
> >   4 files changed, 82 insertions(+), 1 deletion(-)
> >   create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c  
> 
> For turris_omnia_defconfig, this is dropped when compiled:
> 
> drivers/ddr/marvell/a38x/old/ddr3_debug.c:776:12: warning: 
> 'ddr3_tip_access_atr' declared 'static' but never defined 
> [-Wunused-function]
>776 | static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, u32 
> value, u32 **ptr);
>|^~~

And it also seems that there is still something wrong with this
old DDR training code port. Some boards still experience random bugs
with this, but not with the U-Boot from 2015. :-(


Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Sumit Garg
Hi Jonas,

On Wed, 15 May 2024 at 13:11, Jonas Karlman  wrote:
>
> Hi Tom,
>
> On 2024-05-14 18:42, Tom Rini wrote:>
> > git-subtree-dir: dts/upstream
> > git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> > ---
> > This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> > -next branch. To test these changes yourself locally, either use my
> > "WIP/14May2024-next" branch or run:
> > ./dts/update-dts-subtree.sh pull v6.9-dts
> > yourself locally. I intend to wait a few days to apply this to -next, to
> > give people time to test.
> >
>
> There are currently more boards/SoCs that use OF_UPSTREAM in master
> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.

Glad to see more OF_UPSTREAM adoption.

> Next dts/upstream sync will probably be good to do together with a merge
> of master into next :-)

I don't have any particular opinion here and rather leave it upto Tom
how he would like to merge stuff.

>
> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> probably be released shortly after U-Boot v2024.07. So will next sync be
> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> U-Boot merge window?
>
> Linux kernel typically have all major DT changes in -rc1 and fixes in
> later -rcX, so for next branch I would suggest an early sync to a
> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> gets released. That should give more time for testing, migration and
> cleanup using v6.10 DTs in time for a 2024.10 release.

I can see the reasoning for an aggressive DT syncing approach, it has
been brought up in the past too. And the major reason for the current
moderate sync approach [1] is to limit any DT ABI breakages for
U-Boot, we are even prone to breakages with syncs against major Linux
kernel releases (eg. v6.10-dts etc.). It has been a long time
discussion topic where we have been advocating about requirements for
DT ABI stability [2].

So having DT syncs done during the merge window will shorten the
testing window for developers/maintainers. And more syncs means a
multiplicative factor for testing. However, time will tell with more
and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
breakages seen in the future. But surely if they are very rare then I
am open to adopting aggressive DT sync approaches.

[1] 
https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing
[2] 
https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg02162.html

-Sumit

>
> Regards,
> Jonas


[PATCH v1 2/2] arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control

2024-05-15 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.

Signed-off-by: Emanuele Ghidoli 
---
 arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi 
b/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
index ca883ae82c7d..5062447547b6 100644
--- a/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
@@ -850,7 +850,7 @@
 #define DDRSS_PHY_62_DATA 0x
 #define DDRSS_PHY_63_DATA 0x
 #define DDRSS_PHY_64_DATA 0x
-#define DDRSS_PHY_65_DATA 0x0004
+#define DDRSS_PHY_65_DATA 0x0104
 #define DDRSS_PHY_66_DATA 0x
 #define DDRSS_PHY_67_DATA 0x
 #define DDRSS_PHY_68_DATA 0x
@@ -1106,7 +1106,7 @@
 #define DDRSS_PHY_318_DATA 0x
 #define DDRSS_PHY_319_DATA 0x
 #define DDRSS_PHY_320_DATA 0x
-#define DDRSS_PHY_321_DATA 0x0004
+#define DDRSS_PHY_321_DATA 0x0104
 #define DDRSS_PHY_322_DATA 0x
 #define DDRSS_PHY_323_DATA 0x
 #define DDRSS_PHY_324_DATA 0x
-- 
2.34.1



[PATCH v1 1/2] arm: dts: k3-am625-verdin: Update autogenerated LPDDR4 configuration

2024-05-15 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Update the autogenerated LPDDR4 configuration using the latest available
SysConfig tool.
This changes are cosmetic and are made to track the last used tool version.

Signed-off-by: Emanuele Ghidoli 
---
 arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi 
b/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
index 841541bb2433..ca883ae82c7d 100644
--- a/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * This file was generated with the
- * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.10
- * Mon Dec 11 2023 17:07:35 GMT+0100 (Central European Standard Time)
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.10.01
+ * Tue May 14 2024 12:55:28 GMT+0200 (Central European Summer Time)
  * DDR Type: LPDDR4
  * F0 = 50MHzF1 = NA F2 = 800MHz
  * Density (per channel): 16Gb
@@ -10,9 +10,11 @@
  * Number of Ranks: 1
 */
 
+
 #define DDRSS_PLL_FHS_CNT 3
 #define DDRSS_PLL_FREQUENCY_1 4
 #define DDRSS_PLL_FREQUENCY_2 4
+#define DDRSS_SDRAM_IDX 15
 
 
 #define DDRSS_CTL_0_DATA 0x0B00
-- 
2.34.1



[PATCH v1 0/2] arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control

2024-05-15 Thread Emanuele Ghidoli
From: Emanuele Ghidoli 

Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.

Emanuele Ghidoli (2):
  arm: dts: k3-am625-verdin: Update autogenerated LPDDR4 configuration
  arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control

 arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.34.1



Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Jonas Karlman
Hi Tom,

On 2024-05-14 18:42, Tom Rini wrote:> 
> git-subtree-dir: dts/upstream
> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> ---
> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> -next branch. To test these changes yourself locally, either use my
> "WIP/14May2024-next" branch or run:
> ./dts/update-dts-subtree.sh pull v6.9-dts
> yourself locally. I intend to wait a few days to apply this to -next, to
> give people time to test.
> 

There are currently more boards/SoCs that use OF_UPSTREAM in master
branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
Next dts/upstream sync will probably be good to do together with a merge
of master into next :-)

Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
probably be released shortly after U-Boot v2024.07. So will next sync be
to v6.10-dts if that happens in the U-Boot merge window or do we expect
2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
U-Boot merge window?

Linux kernel typically have all major DT changes in -rc1 and fixes in
later -rcX, so for next branch I would suggest an early sync to a
v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
gets released. That should give more time for testing, migration and
cleanup using v6.10 DTs in time for a 2024.10 release.

Regards,
Jonas


[PATCH 2/2] scripts/setlocalversion: sync with linux v6.9

2024-05-15 Thread Rasmus Villemoes
The changes upstream since the last sync (2ed1b242ab2
"scripts/setlocalversion: sync with linux 5.8") are

(5) 548b8b5168c9 scripts/setlocalversion: make git describe output more reliable
77a88274dc1a kbuild: replace LANG=C with LC_ALL=C
2a73cce2dad3 scripts/setlocalversion: remove mercurial, svn and git-svn 
supports
a2be76a352f1 scripts/setlocalversion: remove workaround for old make-kpkg
ffaf62a8050b scripts/setlocalversion: add more comments to -dirty flag 
detection
630ff0faf84e scripts/setlocalversion: factor out 12-chars hash construction
042da426f8eb scripts/setlocalversion: simplify the short version part
5df99bec210a scripts/setlocalversion: fix a bug when LOCALVERSION is empty
(1) 7d153696e5db kbuild: do not include include/config/auto.conf from shell 
scripts
(2) 129ab0d2d9f3 kbuild: do not quote string values in include/config/auto.conf
f6e09b07cc12 kbuild: do not put .scmversion into the source tarball
992ebfab2a75 setlocalversion: simplify the construction of the short version
75280bdf49b2 setlocalversion: make indentation shallower
(3) ec31f868ec67 setlocalversion: absorb $(KERNELVERSION)
eed36d775177 setlocalversion: clean up the construction of version output
(4) 6ab7e1f95e96 setlocalversion: use only the correct release tag for 
git-describe
05e96e96a315 kbuild: use git-archive for source package creation
3354c64d4184 scripts/setlocalversion: clean up stale comment
01e89a4acefc scripts/setlocalversion: also consider annotated tags of the 
form vx.y.z-${file_localversion}

The only thing U-Boot has been applying on top was to deal with not
sourcing include/config/auto.conf but instead using awk to extract the
right value. Commit (1) did a very similar thing upstream, so we no
longer need to do that. However, upstream then went a step further (2)
and changed the convention for what goes into auto.conf, so RHS no
longer contain double-quotes. That commit thus changed the sed pattern
to no longer match those quotes, but as U-Boot has not yet adopted
that change, we have to deal with that. In order to be a little
forward-compatible, I did that in a way that should work both ways:

 # version string from CONFIG_LOCALVERSION
-config_localversion=$(sed -n 's/^CONFIG_LOCALVERSION=\(.*\)$/\1/p' 
include/config/auto.conf)
+config_localversion=$(sed -n 's/^CONFIG_LOCALVERSION=\(.*\)$/\1/p' 
include/config/auto.conf | tr -d '"')

Furthermore, (3) now requires that there is an appropriate
KERNELVERSION environment variable set. One way to deal with that
would be to just modify the script to use UBOOTVERSION instead, but
for now I've instead opted to let the Makefile provide
KERNELVERSION=$(UBOOTVERSION) to keep the setlocalversion changes
minimal.

That variable is further put to use in (4). Note that the logic for
mapping *VERSION -> [upstream annotated tag to look for] works
unchanged in U-Boot for the current versioning scheme 20XX.YY(-rcN)?.

My motivation for wanting to do this sync is to get (4) and (5), in
order to get the setlocalversion output both more predictable and
consistent across different build environments, i.e. independent of
random local .gitconfig settings, total number of git objects and/or
existence of unrelated tags (possibly from some tracked fork).

Signed-off-by: Rasmus Villemoes 
---
 Makefile|   5 +-
 scripts/setlocalversion | 226 
 2 files changed, 116 insertions(+), 115 deletions(-)

diff --git a/Makefile b/Makefile
index efaf24e58e7..14acea9c6b9 100644
--- a/Makefile
+++ b/Makefile
@@ -1898,8 +1898,11 @@ $(filter-out tools, $(u-boot-dirs)): tools
 # is "yes"), so compile examples after U-Boot is compiled.
 examples: $(filter-out examples, $(u-boot-dirs))
 
+# The setlocalversion script comes from linux and expects a
+# KERNELVERSION variable in the environment for figuring out which
+# annotated tags are relevant. Pass UBOOTVERSION.
 define filechk_uboot.release
-   echo "$(UBOOTVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
+   KERNELVERSION=$(UBOOTVERSION) $(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree)
 endef
 
 # Store (new) UBOOTRELEASE string in include/config/uboot.release
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 4a631437067..dbe048210d6 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 # This scripts adds local version information from the version
-# control systems git, mercurial (hg) and subversion (svn).
+# control system git.
 #
 # If something goes wrong, send a mail the kernel build mailinglist
 # (see MAINTAINERS) and CC Nico Schottelius
@@ -11,16 +11,17 @@
 #
 
 usage() {
-   echo "Usage: $0 [--save-scmversion] [srctree]" >&2
+   echo "Usage: $0 [--no-local] [srctree]" >&2
exit 1
 }
 
-scm_only=false
-srctree=.
-if test "$1" = "--save-scmversion"; then
-   scm_only=true

[PATCH 0/2] scripts/setlocalversion sync with linux 6.9

2024-05-15 Thread Rasmus Villemoes
The first commit is trivial cleanup. The second syncs
scripts/setlocalversion with linux 6.9, with just a one-line change on
top to account for a Kbuild change that U-Boot has not yet adopted.

Rasmus Villemoes (2):
  Makefile: refactor ubootrelease target
  scripts/setlocalversion: sync with linux v6.9

 Makefile|   7 +-
 scripts/setlocalversion | 226 
 2 files changed, 117 insertions(+), 116 deletions(-)

-- 
2.40.1.1.g1c60b9335d



[PATCH 1/2] Makefile: refactor ubootrelease target

2024-05-15 Thread Rasmus Villemoes
Instead of duplicating the contents of the filechk_uboot.release
variable, use it directly.

This is preparation for the next patch which will modify
filechk_uboot.release, and reflects what the linux kernel does
nowadays:

kernelrelease:
@$(filechk_kernel.release)
Signed-off-by: Rasmus Villemoes 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 44deb339af1..efaf24e58e7 100644
--- a/Makefile
+++ b/Makefile
@@ -2426,7 +2426,7 @@ checkstack:
$(PERL) $(src)/scripts/checkstack.pl $(ARCH)
 
 ubootrelease:
-   @echo "$(UBOOTVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
+   @$(filechk_uboot.release)
 
 ubootversion:
@echo $(UBOOTVERSION)
-- 
2.40.1.1.g1c60b9335d



Re: [PATCH 0/3] Add eFuse access for ZynqMP

2024-05-15 Thread Marek Behún
On Tue, 14 May 2024 16:04:13 +0200
lukas.funke-...@weidmueller.com wrote:

> From: Lukas Funke 
> 
> 
> This series adds a driver to read and write ZynqMP eFuses [1]. The
> driver can be accessed by the 'efuse_read' and 'efuse_write' subcommands
> of the 'zynqmp' command.

Vendor specific commands aren't great.

There is the 'fuse' command in u-boot. You need to implement the
  fuse_read()
  fuse_sense()
  fuse_prog()
  fuse_override()
functions.

See for example arch/arm/mach-mvebu/efuse.c, or other implementations.

Please don't invent new vendor specific commands in new code, it is an
antipattern.

Marek


Re: [PATCH v1] usb: remove not used variable in usb_ether_curr_dev

2024-05-15 Thread Marek Vasut

On 5/15/24 8:24 AM, Heiko Schocher wrote:

grepping for usb_ether_curr_dev in u-boot source code shows

$ grep -r usb_ether_curr_dev .
./cmd/usb.c:static int __maybe_unused usb_ether_curr_dev = -1; /* current 
ethernet device */
$

only declared but never used, so it can safely
removed from code.

Signed-off-by: Heiko Schocher 


Reviewed-by: Marek Vasut 


Re: [PATCH 3/3] drivers: misc: Add driver to access ZynqMP efuses

2024-05-15 Thread Lukas Funke

Hi Stefan,

On 15.05.2024 08:12, Stefan Roese wrote:

Hi Lukas,

On 5/14/24 16:04, lukas.funke-...@weidmueller.com wrote:

From: Lukas Funke 

Add driver to access ZynqMP efuses. This is a u-boot port of [1].

[1] 
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/


Signed-off-by: Lukas Funke 
---

  drivers/misc/Kconfig    |   8 ++
  drivers/misc/Makefile   |   1 +
  drivers/misc/zynqmp_efuse.c | 213 
  3 files changed, 222 insertions(+)
  create mode 100644 drivers/misc/zynqmp_efuse.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
    Security Monitor can be transitioned on any security failures,
    like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+    bool "Enable ZynqMP eFUSE Driver"
+    depends on ZYNQMP_FIRMWARE
+    help
+  Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU 
firmware
+  interface. ZnyqMP has 256 eFUSEs where some of them are 
security related

+  and cannot be read back (i.e. AES key).
+
  choice
  prompt "Security monitor interaction endianess"
  depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
  obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
  obj-$(CONFIG_SL28CPLD) += sl28cpld.o
  obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..0cfc42a4f39
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK    0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES    (4)
+#define SOC_VER_SIZE    (0x4)
+#define EFUSE_MEMORY_SIZE    (0x177)
+#define UNUSED_SPACE    (0x8)
+#define ZYNQMP_NVMEM_SIZE    (SOC_VER_SIZE + UNUSED_SPACE + \
+ EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET    (0x0)
+#define EFUSE_START_OFFSET    (0xC)
+#define EFUSE_END_OFFSET    (0xFC)
+#define EFUSE_PUF_START_OFFSET    (0x100)
+#define EFUSE_PUF_MID_OFFSET    (0x140)
+#define EFUSE_PUF_END_OFFSET    (0x17F)
+#define EFUSE_NOT_ENABLED    (29)
+#define EFUSE_READ    (0)
+#define EFUSE_WRITE    (1)
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src:    address of the buffer to store the data to be write/read
+ * @size:    no of words to be read/write
+ * @offset:    offset to be read/write`
+ * @flag:    0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for 
read/write

+ *    1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+    u64 src;
+    u32 size;
+    u32 offset;
+    u32 flag;
+    u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_access(struct udevice *dev, unsigned int offset,
+   void *val, size_t bytes, unsigned int flag,
+   unsigned int pufflag)
+{
+    size_t words = bytes / WORD_INBYTES;
+    ulong dma_addr, dma_buf;
+    struct xilinx_efuse *efuse;
+    char *data;
+    int ret, value;
+
+    if (bytes % WORD_INBYTES != 0) {
+    dev_err(dev, "Bytes requested should be word aligned\n");
+    return -EOPNOTSUPP;
+    }
+
+    if (pufflag == 0 && offset % WORD_INBYTES) {
+    dev_err(dev, "Offset requested should be word aligned\n");
+    return -EOPNOTSUPP;
+    }
+
+    if (pufflag == 1 && flag == EFUSE_WRITE) {
+    memcpy(, val, bytes);
+    if ((offset == EFUSE_PUF_START_OFFSET ||
+ offset == EFUSE_PUF_MID_OFFSET) &&
+    value & P_USER_0_64_UPPER_MASK) {
+    dev_err(dev, "Only lower 4 bytes are allowed to be 
programmed in P_USER_0 & P_USER_64\n");

+    return -EOPNOTSUPP;
+    }
+
+    if (offset == EFUSE_PUF_END_OFFSET &&
+    (value & P_USER_127_LOWER_4_BIT_MASK)) {
+    dev_err(dev, "Only MSB 28 bits are allowed to be 
programmed for P_USER_127\n");

+    return -EOPNOTSUPP;
+    }
+    }
+
+    efuse = dma_alloc_coherent(sizeof(struct xilinx_efuse), _addr);
+    if (!efuse)
+    return -ENOMEM;
+
+    data = dma_alloc_coherent(bytes, _buf);
+    if (!data) {
+    dma_free_coherent(efuse);
+    return -ENOMEM;
+    }
+
+    if (flag == EFUSE_WRITE) {
+    

Re: [PATCH 09/13] syscon: Probe device first in syscon_get_regmap

2024-05-15 Thread Jonas Karlman
Hi Jiaxun,

On 2024-05-15 02:12, Jiaxun Yang wrote:
> 
> 
> 在2024年5月14日五月 下午3:50,Jonas Karlman写道:
>> Hi Jiaxun,
> [...]
>>> +   return ERR_PTR(ret);
>>
>> Please explain in more details what the issue this is trying to solve.
>>
>> Typically syscon_get_regmap() is called on a udevice returned from a
>> uclass_get_device call, and that should trigger a probe for the device
>> and its parents.
>>
>> Adding device_probe() here possible just hides an issue that exists
>> somewhere else. In what instance are you ending up with a call to
>> this function with a udevice that has not been probed?
> 
> Hi Jonas,
> 
> Thanks for the reply, my problem is in [PATCH 10/13] I'm using dev->parent
> directly to get parent device and then use that pointer to access
> syscon_get_regmap.

Looking at the driver model lifecycle docs and the clk_boston driver I
would suggest you to change from using the of_to_plat() ops and do same
in probe() ops instead.

That way your parent udevice will have been probed and you do not need
to manually probe it at of_to_plat() stage.

https://docs.u-boot.org/en/latest/develop/driver-model/design.html#driver-lifecycle

"""
If your device relies on its parent setting up a suitable address space,
so that dev_read_addr() works correctly, then make sure that the parent
device has its setup code in of_to_plat(). If it has it in the probe
method, then you cannot call dev_read_addr() from the child device's
of_to_plat() method. Move it to probe() instead.
"""

Moving your syscon_get_regmap() call from of_to_plat() to probe() should
make this syscon patch unnecessary.

Regards,
Jonas

> 
> There is no chance to invoke uclass_get_device_* as what we need is just
> the parent device.
> 
> I can think of two solution without touching syscon code here.
> 
> First would be performing uclass_get_device_by_ofnode against parent's
> ofnode, which seems a little bit overkilling.
> 
> Second would be trigger probing in dev_get_parent.
> 
> Thanks
> - Jiaxun
> 
>>
>> Also, please add a new test to test/dm/regmap.c if this solves a real
>> issue.
>>
>> Regards,
>> Jonas
>>
>>> priv = dev_get_uclass_priv(dev);
>>> return priv->regmap;
>>>  }
>>>
> 



[PATCH v1] usb: remove not used variable in usb_ether_curr_dev

2024-05-15 Thread Heiko Schocher
grepping for usb_ether_curr_dev in u-boot source code shows

$ grep -r usb_ether_curr_dev .
./cmd/usb.c:static int __maybe_unused usb_ether_curr_dev = -1; /* current 
ethernet device */
$

only declared but never used, so it can safely
removed from code.

Signed-off-by: Heiko Schocher 

---
azure build started for it, see:

https://dev.azure.com/hs0298/hs/_build/results?buildId=112=results

 cmd/usb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index 3a3764a5b8..225d929176 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -25,9 +25,6 @@
 #ifdef CONFIG_USB_STORAGE
 static int usb_stor_curr_dev = -1; /* current device */
 #endif
-#if defined(CONFIG_USB_HOST_ETHER) && !defined(CONFIG_DM_ETH)
-static int __maybe_unused usb_ether_curr_dev = -1; /* current ethernet device 
*/
-#endif
 
 /* some display routines (info command) */
 static char *usb_get_class_desc(unsigned char dclass)
-- 
2.37.3



Re: [PATCH 3/3] drivers: misc: Add driver to access ZynqMP efuses

2024-05-15 Thread Stefan Roese

Hi Lukas,

On 5/14/24 16:04, lukas.funke-...@weidmueller.com wrote:

From: Lukas Funke 

Add driver to access ZynqMP efuses. This is a u-boot port of [1].

[1] 
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/

Signed-off-by: Lukas Funke 
---

  drivers/misc/Kconfig|   8 ++
  drivers/misc/Makefile   |   1 +
  drivers/misc/zynqmp_efuse.c | 213 
  3 files changed, 222 insertions(+)
  create mode 100644 drivers/misc/zynqmp_efuse.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
  Security Monitor can be transitioned on any security failures,
  like software violations or hardware security violations.
  
+config ZYNQMP_EFUSE

+   bool "Enable ZynqMP eFUSE Driver"
+   depends on ZYNQMP_FIRMWARE
+   help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security 
related
+ and cannot be read back (i.e. AES key).
+
  choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
  obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
  obj-$(CONFIG_SL28CPLD) += sl28cpld.o
  obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..0cfc42a4f39
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK 0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES   (4)
+#define SOC_VER_SIZE   (0x4)
+#define EFUSE_MEMORY_SIZE  (0x177)
+#define UNUSED_SPACE   (0x8)
+#define ZYNQMP_NVMEM_SIZE  (SOC_VER_SIZE + UNUSED_SPACE + \
+EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET (0x0)
+#define EFUSE_START_OFFSET (0xC)
+#define EFUSE_END_OFFSET   (0xFC)
+#define EFUSE_PUF_START_OFFSET (0x100)
+#define EFUSE_PUF_MID_OFFSET   (0x140)
+#define EFUSE_PUF_END_OFFSET   (0x17F)
+#define EFUSE_NOT_ENABLED  (29)
+#define EFUSE_READ (0)
+#define EFUSE_WRITE(1)
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src:   address of the buffer to store the data to be write/read
+ * @size:  no of words to be read/write
+ * @offset:offset to be read/write`
+ * @flag:  0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+   u64 src;
+   u32 size;
+   u32 offset;
+   u32 flag;
+   u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_access(struct udevice *dev, unsigned int offset,
+  void *val, size_t bytes, unsigned int flag,
+  unsigned int pufflag)
+{
+   size_t words = bytes / WORD_INBYTES;
+   ulong dma_addr, dma_buf;
+   struct xilinx_efuse *efuse;
+   char *data;
+   int ret, value;
+
+   if (bytes % WORD_INBYTES != 0) {
+   dev_err(dev, "Bytes requested should be word aligned\n");
+   return -EOPNOTSUPP;
+   }
+
+   if (pufflag == 0 && offset % WORD_INBYTES) {
+   dev_err(dev, "Offset requested should be word aligned\n");
+   return -EOPNOTSUPP;
+   }
+
+   if (pufflag == 1 && flag == EFUSE_WRITE) {
+   memcpy(, val, bytes);
+   if ((offset == EFUSE_PUF_START_OFFSET ||
+offset == EFUSE_PUF_MID_OFFSET) &&
+   value & P_USER_0_64_UPPER_MASK) {
+   dev_err(dev, "Only lower 4 bytes are allowed to be programmed in 
P_USER_0 & P_USER_64\n");
+   return -EOPNOTSUPP;
+   }
+
+   if (offset == EFUSE_PUF_END_OFFSET &&
+   (value & P_USER_127_LOWER_4_BIT_MASK)) {
+   dev_err(dev, "Only MSB 28 bits are allowed to be programmed 
for P_USER_127\n");
+   return -EOPNOTSUPP;
+   }
+   }
+
+   efuse = dma_alloc_coherent(sizeof(struct xilinx_efuse), _addr);
+   

Re: [PATCH 1/3] firmware: zynqmp: Add support to access efuses

2024-05-15 Thread Stefan Roese

Hi Lukas,

On 5/14/24 16:04, lukas.funke-...@weidmueller.com wrote:

From: Lukas Funke 

Add functions to access efuses through PMU firmware
interface.

Signed-off-by: Lukas Funke 
---

  drivers/firmware/firmware-zynqmp.c | 31 ++
  include/zynqmp_firmware.h  |  2 ++
  2 files changed, 33 insertions(+)

diff --git a/drivers/firmware/firmware-zynqmp.c 
b/drivers/firmware/firmware-zynqmp.c
index f99507d86c6..7483f2a8709 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -210,6 +210,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
  }
  
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)

+{
+   int ret;
+   u32 ret_payload[PAYLOAD_ARG_CNT];


Reverse x-mas tree ordering looks better IMHO.


+
+   if (!idcode || !version)
+   return -EINVAL;
+
+   ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+   *idcode = ret_payload[1];
+   *version = ret_payload[2];


You don't check ret for an error above but still pass the return values
here. Perhaps it makes sense to return with error above instead?


+
+   return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+   int ret;
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+
+   if (!out)
+   return -EINVAL;
+
+   ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+   lower_32_bits(address), 0, 0, ret_payload);


Same here.

Thanks,
Stefan


+
+   *out = ret_payload[1];
+
+   return ret;
+}
+
  int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
  {
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32 
arg2,
  int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 
value);
  int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
 u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
  int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
  int zynqmp_mmio_read(const u32 address, u32 *value);
  int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);


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