date:20210831

There are trivial typos in the Kconfig file. Fix them.

Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and 
CMD_UBIFS")
Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
Signed-off-by: Oleksandr Suvorov 
---

 lib/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index c535147aea..d8f312f37e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -478,7 +478,7 @@ config LZMA
 config LZO
bool "Enable LZO decompression support"
help
- This enables support for LZO compression algorithm.r
+ This enables support for LZO compression algorithm.
 
 config GZIP
bool "Enable gzip decompression support"
@@ -537,7 +537,7 @@ config SPL_GZIP
bool "Enable gzip decompression support for SPL build"
select SPL_ZLIB
help
- This enables support for GZIP compression altorithm for SPL boot.
+ This enables support for GZIP compression algorithm for SPL boot.
 
 config SPL_ZLIB
bool
-- 
2.31.1

Subject: [PATCH 1/6 v2] serial: qcom: add support for GENI serial driver

>From b2516d965ee933bdb10fc158e36dedcf65bd7ce9 Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Fri, 27 Aug 2021 17:47:22 +0300
Subject: [PATCH 1/6 v2] serial: qcom: add support for GENI serial driver

Generic Interface (GENI) Serial Engine (SE) based uart
can be found on newer qualcomm SOCs, starting from SDM845.
Tested on Samsung SM-G9600(starqltechn)
by chain-loading u-boot with stock bootloader.

Signed-off-by: Dzmitry Sankouski 
Cc: Ramon Fried 
---
Changes for v2:
- change functions return type to void, where possible
- remove '.' from summary line

 MAINTAINERS   |   1 +
 .../serial/msm-geni-serial.txt|   6 +
 drivers/serial/Kconfig|  17 +
 drivers/serial/Makefile   |   1 +
 drivers/serial/serial_msm_geni.c  | 579 ++
 5 files changed, 604 insertions(+)
 create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt
 create mode 100644 drivers/serial/serial_msm_geni.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 776ff703b9..52ddc99cda 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -390,6 +390,7 @@ F: drivers/gpio/msm_gpio.c
 F: drivers/mmc/msm_sdhci.c
 F: drivers/phy/msm8916-usbh-phy.c
 F: drivers/serial/serial_msm.c
+F: drivers/serial/serial_msm_geni.c
 F: drivers/smem/msm_smem.c
 F: drivers/usb/host/ehci-msm.c

diff --git a/doc/device-tree-bindings/serial/msm-geni-serial.txt
b/doc/device-tree-bindings/serial/msm-geni-serial.txt
new file mode 100644
index 00..9eadc2561b
--- /dev/null
+++ b/doc/device-tree-bindings/serial/msm-geni-serial.txt
@@ -0,0 +1,6 @@
+Qualcomm GENI UART
+
+Required properties:
+- compatible: must be "qcom,msm-geni-uart"
+- reg: start address and size of the registers
+- clock: interface clock (must accept baudrate as a frequency)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 93348c0929..b420a5720d 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -278,6 +278,14 @@ config DEBUG_UART_S5P
   will need to provide parameters to make this work. The driver will
   be available until the real driver-model serial is running.

+config DEBUG_UART_MSM_GENI
+ bool "Qualcomm snapdragon"
+ depends on ARCH_SNAPDRAGON
+ help
+  Select this to enable a debug UART using the serial_msm driver. You
+  will need to provide parameters to make this work. The driver will
+  be available until the real driver-model serial is running.
+
 config DEBUG_UART_MESON
  bool "Amlogic Meson"
  depends on MESON_SERIAL
@@ -783,6 +791,15 @@ config MSM_SERIAL
   for example APQ8016 and MSM8916.
   Single baudrate is supported in current implementation (115200).

+config MSM_GENI_SERIAL
+ bool "Qualcomm on-chip GENI UART"
+ help
+  Support UART based on Generic Interface (GENI) Serial Engine (SE), used
on Qualcomm Snapdragon SoCs.
+  Should support all qualcomm SOCs with Qualcomm Universal Peripheral
(QUP) Wrapper cores,
+  i.e. newer ones, starting from SDM845.
+  Driver works in FIFO mode.
+  Multiple baudrates supported.
+
 config OCTEON_SERIAL_BOOTCMD
  bool "MIPS Octeon PCI remote bootcmd input"
  depends on ARCH_OCTEON
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 3cbea8156f..d44caf4ea2 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o
 obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
 obj-$(CONFIG_BCM283X_PL011_SERIAL) += serial_bcm283x_pl011.o
 obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
+obj-$(CONFIG_MSM_GENI_SERIAL) += serial_msm_geni.o
 obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
 obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
 obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
diff --git a/drivers/serial/serial_msm_geni.c
b/drivers/serial/serial_msm_geni.c
new file mode 100644
index 00..833e7df82e
--- /dev/null
+++ b/drivers/serial/serial_msm_geni.c
@@ -0,0 +1,579 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm GENI serial engine UART driver
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ * Based on Linux driver.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UART_OVERSAMPLING (32)
+#define STALE_TIMEOUT (160)
+#define SE_UART_RX_STALE_CNT (0x294)
+#define S_GENI_CMD_ABORT (BIT(1))
+
+#define SE_GENI_S_CMD_CTRL_REG (0x634)
+#define SE_GENI_M_CMD_CTRL_REG (0x604)
+
+/* GENI_M_CMD_CTRL_REG */
+#define M_GENI_CMD_CANCEL BIT(2)
+#define M_GENI_CMD_ABORT BIT(1)
+#define M_GENI_DISABLE BIT(0)
+
+/* GENI_S_CMD0 fields */
+#define S_OPCODE_MSK GENMASK(31, 27)
+#define S_OPCODE_SHFT 27
+#define S_PARAMS_MSK GENMASK(26, 0)
+
+/* GENI_STATUS fields */
+#define M_GENI_CMD_ACTIVE BIT(0)
+#define S_GENI_CMD_ACTIVE BIT(12)
+#define S_CMD_DONE_EN (BIT(0))
+#define M_CMD_DONE_EN (BIT(0))
+
+#define USEC_PER_SEC 100L
+
+#define SE_GENI_STATUS 0x40
+#define GENI_SER_M_CLK_CFG (0x48)
+#define GENI_SER_S_CLK_CFG (0x4C)

Re: [PATCH v2 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset

2021-08-31 Thread liao jaime

Hi Pratyush

Thanks for your reply, I want to create "CONFIG_SPI_EXT_INVERT"
to separate extension types.
Changed as below, do you have any suggestion?

ext = nor->cmd_ext_type;
if (!nor->cmd_ext_type) {
nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
#ifdef CONFIG_SPI_NOR_EXT_INVERT
nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
#endif
}

Pratyush Yadav  於 2021年8月30日 週一 下午7:30寫道：

> Hi,
>
> On 20/08/21 02:58PM, JaimeLiao wrote:
> > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> 8D-8D-8D
> > in the begging of probe.
> >
> > Command extension type is not standardized across flash vendors in DTR
> mode.
> >
> > For suiting different vendor flash devices, having second times
> Softreset with
> > different types is clumsy but useful in the begging of probe.
>
> Yes, it is indeed clumsy, and I am not convinced this is the right way
> to go.
>
> Firstly, you issue the reset twice. This is obviously not ideal and you
> have to hope the command with incorrect extension is ignored, and not
> interpreted as something different. But more importantly, you also do
> the same when called via spi_nor_remove(). At that point you have parsed
> SFDP and know the flash we are dealing with so you should already know
> which extension to use.
>
> So here is my suggestion: create a separate function, something like
> spi_nor_early_soft_reset(). In that function check a config variable to
> decide which extension to use and temporarily set nor->cmd_ext_type to
> that. Then in spi_nor_soft_reset() just use nor->cmd_ext_type, no need
> to hard code the extension. This way you will certainly use the correct
> extension at remove and will have a more accurate guess at probe time.
>
> I admit this isn't the cleanest solution, but this is the best I can
> come up with right now.
>
> >
> > Signed-off-by: JaimeLiao 
> > ---
> >  drivers/mtd/spi/spi-nor-core.c | 30 ++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> > index 351ca9c3a8..707eb9c1d2 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3692,6 +3692,36 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> >*/
> >   udelay(SPI_NOR_SRST_SLEEP_LEN);
> >
> > + /* Manufacturers with different command extension type. For
> suitting
> > +  * different flash devices, using command extension type is equal
> "INVERT"
> > +  * when second time Software Reset.
> > +  */
> > +
> > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > + op = (struct
> spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_NO_ADDR,
> > + SPI_MEM_OP_NO_DATA);
> > + spi_nor_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret) {
> > + dev_warn(nor->dev, "Software reset enable failed: %d\n",
> ret);
> > + goto out;
> > + }
> > +
> > + op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST,
> 0),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_NO_ADDR,
> > + SPI_MEM_OP_NO_DATA);
> > + spi_nor_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret) {
> > + dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> > + goto out;
> > + }
> > +
> > + udelay(SPI_NOR_SRST_SLEEP_LEN);
> > +
> >  out:
> >   nor->cmd_ext_type = ext;
> >   return ret;
> > --
> > 2.17.1
> >
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
>

Subject: [PATCH 2/6 v2] spmi: msm: add arbiter version 5 support

>From b65826c49fee93dd7ded11a848814d8fa79fdb2e Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Sat, 28 Aug 2021 13:53:42 +0300
Subject: [PATCH 2/6 v2] spmi: msm: add arbiter version 5 support

Currently driver supports only version 1 and 2.
Version 5 has slightly different registers structure

Signed-off-by: Dzmitry Sankouski 
Cc: Ramon Fried 
---
Changes for v2:
- change string formats in debug statements

 MAINTAINERS |   1 +
 drivers/spmi/spmi-msm.c | 156 +++-
 2 files changed, 107 insertions(+), 50 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 52ddc99cda..6b8b0783d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -392,6 +392,7 @@ F: drivers/phy/msm8916-usbh-phy.c
 F: drivers/serial/serial_msm.c
 F: drivers/serial/serial_msm_geni.c
 F: drivers/smem/msm_smem.c
+F: drivers/spmi/spmi-msm.c
 F: drivers/usb/host/ehci-msm.c

 ARM STI
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 5a335e50aa..c5bc55bc6f 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -19,39 +19,63 @@
 DECLARE_GLOBAL_DATA_PTR;

 /* PMIC Arbiter configuration registers */
-#define PMIC_ARB_VERSION 0x
-#define PMIC_ARB_VERSION_V2_MIN 0x2001
-
-#define ARB_CHANNEL_OFFSET(n) (0x4 * (n))
-#define SPMI_CH_OFFSET(chnl) ((chnl) * 0x8000)
-
-#define SPMI_REG_CMD0 0x0
-#define SPMI_REG_CONFIG 0x4
-#define SPMI_REG_STATUS 0x8
-#define SPMI_REG_WDATA 0x10
-#define SPMI_REG_RDATA 0x18
-
-#define SPMI_CMD_OPCODE_SHIFT 27
-#define SPMI_CMD_SLAVE_ID_SHIFT 20
-#define SPMI_CMD_ADDR_SHIFT 12
-#define SPMI_CMD_ADDR_OFFSET_SHIFT 4
-#define SPMI_CMD_BYTE_CNT_SHIFT 0
-
-#define SPMI_CMD_EXT_REG_WRITE_LONG 0x00
-#define SPMI_CMD_EXT_REG_READ_LONG 0x01
-
-#define SPMI_STATUS_DONE 0x1
+#define PMIC_ARB_VERSION 0x
+#define PMIC_ARB_VERSION_V2_MIN 0x2001
+#define PMIC_ARB_VERSION_V3_MIN 0x3000
+#define PMIC_ARB_VERSION_V5_MIN 0x5000
+
+#define APID_MAP_OFFSET_V1_V2_V3 (0x800)
+#define APID_MAP_OFFSET_V5 (0x900)
+#define ARB_CHANNEL_OFFSET(n) (0x4 * (n))
+#define SPMI_CH_OFFSET(chnl) ((chnl) * 0x8000)
+#define SPMI_V5_OBS_CH_OFFSET(chnl) ((chnl) * 0x80)
+#define SPMI_V5_RW_CH_OFFSET(chnl) ((chnl) * 0x1)
+
+#define SPMI_REG_CMD0 0x0
+#define SPMI_REG_CONFIG 0x4
+#define SPMI_REG_STATUS 0x8
+#define SPMI_REG_WDATA 0x10
+#define SPMI_REG_RDATA 0x18
+
+#define SPMI_CMD_OPCODE_SHIFT 27
+#define SPMI_CMD_SLAVE_ID_SHIFT 20
+#define SPMI_CMD_ADDR_SHIFT 12
+#define SPMI_CMD_ADDR_OFFSET_SHIFT 4
+#define SPMI_CMD_BYTE_CNT_SHIFT 0
+
+#define SPMI_CMD_EXT_REG_WRITE_LONG 0x00
+#define SPMI_CMD_EXT_REG_READ_LONG 0x01
+
+#define SPMI_STATUS_DONE 0x1
+
+#define SPMI_MAX_CHANNELS 128
+#define SPMI_MAX_SLAVES 16
+#define SPMI_MAX_PERIPH 256
+
+enum arb_ver {
+ V1 = 1,
+ V2,
+ V3,
+ V5 = 5
+};

-#define SPMI_MAX_CHANNELS 128
-#define SPMI_MAX_SLAVES 16
-#define SPMI_MAX_PERIPH 256
+/*
+ * PMIC arbiter version 5 uses different register offsets for read/write vs
+ * observer channels.
+ */
+enum pmic_arb_channel {
+ PMIC_ARB_CHANNEL_RW,
+ PMIC_ARB_CHANNEL_OBS,
+};

 struct msm_spmi_priv {
- phys_addr_t arb_chnl; /* ARB channel mapping base */
+ phys_addr_t arb_chnl;  /* ARB channel mapping base */
  phys_addr_t spmi_core; /* SPMI core */
- phys_addr_t spmi_obs; /* SPMI observer */
+ phys_addr_t spmi_obs;  /* SPMI observer */
  /* SPMI channel map */
  uint8_t channel_map[SPMI_MAX_SLAVES][SPMI_MAX_PERIPH];
+ /* SPMI bus arbiter version */
+ u32 arb_ver;
 };

 static int msm_spmi_write(struct udevice *dev, int usid, int pid, int off,
@@ -59,6 +83,7 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
 {
  struct msm_spmi_priv *priv = dev_get_priv(dev);
  unsigned channel;
+ unsigned int ch_offset;
  uint32_t reg = 0;

  if (usid >= SPMI_MAX_SLAVES)
@@ -69,8 +94,8 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
  channel = priv->channel_map[usid][pid];

  /* Disable IRQ mode for the current channel*/
- writel(0x0, priv->spmi_core + SPMI_CH_OFFSET(channel) +
-   SPMI_REG_CONFIG);
+ writel(0x0,
+   priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);

  /* Write single byte */
  writel(val, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_WDATA);
@@ -82,6 +107,12 @@ static int msm_spmi_write(struct udevice *dev, int
usid, int pid, int off,
  reg |= (off << SPMI_CMD_ADDR_OFFSET_SHIFT);
  reg |= 1; /* byte count */

+ if (priv->arb_ver == V5) {
+ ch_offset = SPMI_V5_RW_CH_OFFSET(channel);
+ } else {
+ ch_offset = SPMI_CH_OFFSET(channel);
+ }
+
  /* Send write command */
  writel(reg, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);

@@ -104,6 +135,7 @@ static int msm_spmi_read(struct udevice *dev, int usid,
int pid, int off)
 {
  struct msm_spmi_priv *priv = dev_get_priv(dev);
  unsigned channel;
+ unsigned int ch_offset;
  uint32_t reg = 0;

  if (usid >= SPMI_MAX_SLAVES)
@@ -113,8 +145,14 @@ static int msm_spmi_read(struct udevice *dev, int
usid, int pid, int off)

  channel

Subject: [PATCH 0/6] Add support for SDM845 based boards, and SM-G9600

>From 94e21cc200e09c51752e4bb86cfac320a92c48a5 Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Tue, 31 Aug 2021 11:25:37 +0300
Subject: [PATCH 0/6] Add support for SDM845 based boards, and SM-G9600

Snapdragon 845 - hi-end qualcomm chip, introduced in late 2017.
Mostly used in flagship phones and tablets of 2018.
Features:
- arm64 arch
- total of 8 Kryo 385 Gold / Silver cores
- Hexagon 685 DSP
- Adreno 630 GPU

Tested only as second-stage bootloader.

Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
for China \ Hong Kong markets.
Has unlockable bootloader, unlike SM-G960U (American market version),
which allows running u-boot as a chain-loaded bootloader.

Dzmitry Sankouski (6):
  serial: qcom: add support for GENI serial driver
  spmi: msm: add arbiter version 5 support
  pinctrl: qcom: add pinctrl and gpio drivers for SDM845  SoC
  clocks: qcom: add clocks for SDM845 debug uart
  SoC: qcom: add support for SDM845
  board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board

 MAINTAINERS   |   2 +
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sdm845.dtsi  | 118 
 arch/arm/dts/starqltechn-uboot.dtsi   |  39 ++
 arch/arm/dts/starqltechn.dts  |  53 ++
 arch/arm/mach-snapdragon/Kconfig  |  17 +
 arch/arm/mach-snapdragon/Makefile |   4 +
 arch/arm/mach-snapdragon/clock-sdm845.c   |  92 +++
 arch/arm/mach-snapdragon/clock-snapdragon.c   |   1 +
 arch/arm/mach-snapdragon/clock-snapdragon.h   |   3 +-
 .../include/mach/sysmap-sdm845.h  |  42 ++
 arch/arm/mach-snapdragon/init_sdm845.c|  82 +++
 arch/arm/mach-snapdragon/pinctrl-sdm845.c |  44 ++
 arch/arm/mach-snapdragon/pinctrl-snapdragon.c |   1 +
 arch/arm/mach-snapdragon/pinctrl-snapdragon.h |   1 +
 arch/arm/mach-snapdragon/sysmap-sdm845.c  |  31 +
 board/samsung/starqltechn/Kconfig |  14 +
 board/samsung/starqltechn/MAINTAINERS |   6 +
 board/samsung/starqltechn/Makefile|   9 +
 board/samsung/starqltechn/starqltechn.c   |  10 +
 configs/starqltechn_defconfig |  33 +
 .../serial/msm-geni-serial.txt|   6 +
 drivers/gpio/msm_gpio.c   |   1 +
 drivers/gpio/pm8916_gpio.c|   8 +-
 drivers/serial/Kconfig|  17 +
 drivers/serial/Makefile   |   1 +
 drivers/serial/serial_msm_geni.c  | 579 ++
 drivers/spmi/spmi-msm.c   | 156 +++--
 include/configs/sdm845.h  |  32 +
 include/configs/starqltechn.h |  16 +
 30 files changed, 1365 insertions(+), 54 deletions(-)
 create mode 100644 arch/arm/dts/sdm845.dtsi
 create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi
 create mode 100644 arch/arm/dts/starqltechn.dts
 create mode 100644 arch/arm/mach-snapdragon/clock-sdm845.c
 create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h
 create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c
 create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c
 create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c
 create mode 100644 board/samsung/starqltechn/Kconfig
 create mode 100644 board/samsung/starqltechn/MAINTAINERS
 create mode 100644 board/samsung/starqltechn/Makefile
 create mode 100644 board/samsung/starqltechn/starqltechn.c
 create mode 100644 configs/starqltechn_defconfig
 create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt
 create mode 100644 drivers/serial/serial_msm_geni.c
 create mode 100644 include/configs/sdm845.h
 create mode 100644 include/configs/starqltechn.h

-- 
2.20.1

Re: incompatible device trees between u-boot and linux

2021-08-31 Thread Rob Herring

On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean  wrote:
>
> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that there is a fallback to the u-boot device tree for linux
> > > > > (esp. EFI boot) if no other device tree was found, see [1]. It seems 
> > > > > this
> > > > > is working fine for imx devices, for example, where you can just boot 
> > > > > a
> > > > > stock installer iso via EFI. It will just work and it is quite a nice
> > > > > feature as a fallback.
> > > > >
> > > > > Now for the layerscape architecture, the ls1028a in my case, things 
> > > > > are
> > > > > more difficult because the bindings differ between u-boot and linux - 
> > > > > one
> > > > > which comes to mind is DSA and ethernet.
> > > > >
> > > > > Which begs the general question, is it encouraged to have both 
> > > > > bindings
> > > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and 
> > > > > there
> > > > > is no real review or alignment but just added as needed, which is ok 
> > > > > if
> > > > > they are local to u-boot. But since they are nowadays passed to linux
> > > > > (by default!) I'm not so sure anymore.
> > > > >
> > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > > > > they should (could?) be shared between linux and u-boot.
> > > > >
> > > > > -michael
> > > > >
> > > > > [1]
> > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > >
> > > > The U-Boot device tree is supposed to be able to be passed on to Linux
> > > > and Just Work.  The bindings are not supposed to be different between
> > > > the two (except for when we take the binding while it's being hashed out
> > > > upstream BUT THEN RESYNCED).
> > >
> > > You might need to spell that out a bit clearer.
> > >
> > > You are saying that both U-Boot and Linux are allowed to have their own
> > > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = 
> > > "in-band-status"'
> > > for Linux), as long as the device tree files themselves are in sync, and
> > > the subset of the device tree blob understood by Linux (i.e. the U-Boot
> > > blob sans the U-Boot specifics) is compatible with the Linux DT blob?
> >
> > I don't know what about the Linux example makes it Linux specific.  But
> > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > by Linux.  The whole reason we have the -u-boot.dtsi automatic drop-in
> > logic (as much as it can be used is that device trees are device trees
> ^
> I don't think this parenthesis ever closes...
>
> > and describe the hardware and developers don't need to write a device
> > tree for Linux and a device tree for U-Boot and a device tree for
> > FreeBSD and ...  So yes, you're supposed to use the device tree for a
> ^
> so I never get the answer to "the whole reason is...".
>
> > platform and it works here and there and every where.
>
> The fact that only Linux uses it makes it Linux specific.
>
> > > To expand even further on that, it means we should put 'managed = 
> > > "in-band-status"'
> > > in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> > > does not use phylink?
> >
> > We should be able to drop in the device trees from Linux and use them.
> > Custodians should be re-syncing them periodically.  Some are, even.
>
> Are you ready to take up device tree bindings for PTP timers, PCIe root
> complex event collectors, cascaded interrupt controllers, things which
> U-Boot will never ever need to support?
>
> At least in Linux there is a policy to not add device tree nodes that do
> not have drivers.

That is not the policy. The policy is DT nodes must have binding
(schema) documentation and the binding should be complete as possible
(not what some driver currently uses). However, for complex bindings,
it might be difficult to write the binding in absence of a driver.

> Is the same policy not true for U-Boot? At least your
> ./scripts/checkpatch.pl does have the same "check for DT compatible
> documentation" section as Linux. You might consider removing it if you
> want people to not strip the DTs they submit to U-Boot.

That hacky checkpatch.pl check is going away. While somewhat
effective, it will take 'the' or any other word in a binding doc as a
valid compatible. With the schemas now, we have an exact list of what
compatibles are documented and that is checked on dts files. Though
anything with a free form text binding will be reported as
undocumented, but I view that as a todo list.

> And why do we even maintain the device tree bindings in Linux at all?
> It seems rather counter-productive for both ends to do that, if it is
> expected that the kernel works

Re: [PATCH] lib: fix typos in Kconfig

2021-08-31 Thread Bin Meng

On Tue, Aug 31, 2021 at 7:58 PM Oleksandr Suvorov
 wrote:
>
> There are trivial typos in the Kconfig file. Fix them.
>
> Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and 
> CMD_UBIFS")
> Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
> Signed-off-by: Oleksandr Suvorov 
> ---
>
>  lib/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng

[PATCH v1 2/2] apalis-imx6: use dynamic DDR calibration

2021-08-31 Thread Francesco Dolcini

Enable dynamic DDR calibration to have a reliable behavior on edge
temperatures conditions.

Signed-off-by: Max Krummenacher 
Signed-off-by: Francesco Dolcini 

---

 board/toradex/apalis_imx6/apalis_imx6.c | 19 +++
 configs/apalis_imx6_defconfig   |  1 +
 2 files changed, 20 insertions(+)

diff --git a/board/toradex/apalis_imx6/apalis_imx6.c 
b/board/toradex/apalis_imx6/apalis_imx6.c
index 74060daadd..ce64ace0d4 100644
--- a/board/toradex/apalis_imx6/apalis_imx6.c
+++ b/board/toradex/apalis_imx6/apalis_imx6.c
@@ -1077,6 +1077,24 @@ static void ddr_init(int *table, int size)
writel(table[2 * i + 1], table[2 * i]);
 }
 
+/* Perform DDR DRAM calibration */
+static void spl_dram_perform_cal(void)
+{
+#ifdef CONFIG_MX6_DDRCAL
+   int err;
+   struct mx6_ddr_sysinfo ddr_sysinfo = {
+   .dsize = 2,
+   };
+
+   err = mmdc_do_write_level_calibration(_sysinfo);
+   if (err)
+   printf("error %d from write level calibration\n", err);
+   err = mmdc_do_dqs_calibration(_sysinfo);
+   if (err)
+   printf("error %d from dqs calibration\n", err);
+#endif
+}
+
 static void spl_dram_init(void)
 {
int minc, maxc;
@@ -1095,6 +1113,7 @@ static void spl_dram_init(void)
break;
};
udelay(100);
+   spl_dram_perform_cal();
 }
 
 void board_init_f(ulong dummy)
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index a0e85ba23a..0e06e75818 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_MEMTEST_END=0x1001
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0xDE00
 CONFIG_MX6Q=y
+CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_APALIS_IMX6=y
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6-apalis"
-- 
2.25.1

[PATCH v1 1/2] colibri-imx6: use dynamic DDR calibration

2021-08-31 Thread Francesco Dolcini

Enable dynamic DDR calibration to have a reliable behavior on edge
temperatures conditions.

Signed-off-by: Max Krummenacher 
Signed-off-by: Francesco Dolcini 
---

 board/toradex/colibri_imx6/colibri_imx6.c | 22 ++
 configs/colibri_imx6_defconfig|  1 +
 2 files changed, 23 insertions(+)

diff --git a/board/toradex/colibri_imx6/colibri_imx6.c 
b/board/toradex/colibri_imx6/colibri_imx6.c
index 587d92a8e9..0fdeec51c4 100644
--- a/board/toradex/colibri_imx6/colibri_imx6.c
+++ b/board/toradex/colibri_imx6/colibri_imx6.c
@@ -998,9 +998,28 @@ static void ddr_init(int *table, int size)
writel(table[2 * i + 1], table[2 * i]);
 }
 
+/* Perform DDR DRAM calibration */
+static void spl_dram_perform_cal(u8 dsize)
+{
+#ifdef CONFIG_MX6_DDRCAL
+   int err;
+   struct mx6_ddr_sysinfo ddr_sysinfo = {
+   .dsize = dsize,
+   };
+
+   err = mmdc_do_write_level_calibration(_sysinfo);
+   if (err)
+   printf("error %d from write level calibration\n", err);
+   err = mmdc_do_dqs_calibration(_sysinfo);
+   if (err)
+   printf("error %d from dqs calibration\n", err);
+#endif
+}
+
 static void spl_dram_init(void)
 {
int minc, maxc;
+   u8 dsize = 2;
 
switch (get_cpu_temp_grade(, )) {
case TEMP_COMMERCIAL:
@@ -1010,6 +1029,7 @@ static void spl_dram_init(void)
ddr_init(mx6dl_dcd_table, ARRAY_SIZE(mx6dl_dcd_table));
} else {
puts("Commercial temperature grade DDR3 timings, 32bit 
bus width.\n");
+   dsize = 1;
ddr_init(mx6s_dcd_table, ARRAY_SIZE(mx6s_dcd_table));
}
break;
@@ -1021,11 +1041,13 @@ static void spl_dram_init(void)
ddr_init(mx6dl_dcd_table, ARRAY_SIZE(mx6dl_dcd_table));
} else {
puts("Industrial temperature grade DDR3 timings, 32bit 
bus width.\n");
+   dsize = 1;
ddr_init(mx6s_dcd_table, ARRAY_SIZE(mx6s_dcd_table));
}
break;
};
udelay(100);
+   spl_dram_perform_cal(dsize);
 }
 
 static iomux_v3_cfg_t const gpio_reset_pad[] = {
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 47b1cfb191..5a4f901fa7 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_MEMTEST_END=0x1001
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0xDE00
 CONFIG_MX6DL=y
+CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_COLIBRI_IMX6=y
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6-colibri"
-- 
2.25.1

[PATCH v1 0/2] board: toradex: enable dynamic DDR calibration for iMX6 boards

2021-08-31 Thread Francesco Dolcini



Enable dynamic DDR calibration to have a reliable behavior on edge
temperatures conditions for Toradex Apalis and Colibri iMX6 boards.


Francesco Dolcini (2):
  colibri-imx6: use dynamic DDR calibration
  apalis-imx6: use dynamic DDR calibration

 board/toradex/apalis_imx6/apalis_imx6.c   | 19 +++
 board/toradex/colibri_imx6/colibri_imx6.c | 22 ++
 configs/apalis_imx6_defconfig |  1 +
 configs/colibri_imx6_defconfig|  1 +
 4 files changed, 43 insertions(+)

-- 
2.25.1

Re: [PATCH v2] mx7ulp: add getting a board serial number

2021-08-31 Thread Fabio Estevam

Hi Oleksandr,

On Tue, Aug 31, 2021 at 8:53 AM Oleksandr Suvorov
 wrote:
>
> From: Ricardo Salveti 
>
> Get Unique ID of SoC iMX7ULP, using the logic described in Fusemap
> (IMX7ULPRMB2_Rev0_Fusemap) attached in the i.MX 7ULP APRM [1].
>
> [1]
> https://www.nxp.com/docs/en/reference-manual/IMX7ULPRMB2.pdf
>
> Signed-off-by: Ricardo Salveti 
> Co-developed-by: Oleksandr Suvorov 
> Signed-off-by: Oleksandr Suvorov 

Reviewed-by: Fabio Estevam

Re: [PATCH] x86: Change SYS_LOAD_ADDR to 0x01000000

2021-08-31 Thread Bin Meng

Hi Tom,

On Tue, Aug 31, 2021 at 9:13 PM Tom Rini  wrote:
>
> At least on qemu, and likely other platforms, a load address of
> 0x0200 ends up without our protected range currently.  Move this
> down to 0x0100.

What is the protected range?

>
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> ---
>  Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Regards,
Bin

Re: [PATCH v6 12/12] sandbox: add test of wdt-uclass' watchdog_reset()

2021-08-31 Thread Stefan Roese


On 31.08.21 11:29, Rasmus Villemoes wrote:

On 31/08/2021 10.17, Stefan Roese wrote:

Hi Rasmus,

I've pulled this patchset now into next [1] and have run it through
CI via Azure. Here an error occurs:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=109=logs=50449d1b-398e-53ae-48fa-6bf338edeb51=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6=533


Could you please take a look at this?


I'm pretty confident that has nothing to do with my patches, but is a
broken (or, to put it more gently, fragile) test.

It does

// fetch the emulated device's current base_time value, setting it to 0
 old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);

// fetch the emuluated device's current base_time value, don't (-1) set
// a new value, check that we got 0
 ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));

// call the device's ->reset method
 /* Resetting the RTC should put he base time back to normal */
 ut_assertok(dm_rtc_reset(dev));
// fetch the new base_time value, without altering it
 base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
// and check that the base time was put back to "normal"
 ut_asserteq(old_base_time, base_time);

The thing is, the ->reset method does

static void reset_time(struct udevice *dev)
{
 struct sandbox_i2c_rtc_plat_data *plat = dev_get_plat(dev);
 struct rtc_time now;

 os_localtime();
 plat->base_time = rtc_mktime();

It's inevitable that this will cause occasional spurious failures. I can
trivially reproduce it with

=> while ut dm rtc_reset ; do echo . ; done

it fails after a few screenfuls of successes.


Thanks for looking into this.

Thanks,
Stefan

Re: [PATCH v6 12/12] sandbox: add test of wdt-uclass' watchdog_reset()

On Tue, Aug 31, 2021 at 11:29:51AM +0200, Rasmus Villemoes wrote:
> On 31/08/2021 10.17, Stefan Roese wrote:
> > Hi Rasmus,
> > 
> > I've pulled this patchset now into next [1] and have run it through
> > CI via Azure. Here an error occurs:
> > 
> > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=109=logs=50449d1b-398e-53ae-48fa-6bf338edeb51=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6=533
> > 
> > 
> > Could you please take a look at this?
> 
> I'm pretty confident that has nothing to do with my patches, but is a
> broken (or, to put it more gently, fragile) test.
> 
> It does
> 
> // fetch the emulated device's current base_time value, setting it to 0
> old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
> 
> // fetch the emuluated device's current base_time value, don't (-1) set
> // a new value, check that we got 0
> ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
> 
> // call the device's ->reset method
> /* Resetting the RTC should put he base time back to normal */
> ut_assertok(dm_rtc_reset(dev));
> // fetch the new base_time value, without altering it
> base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
> // and check that the base time was put back to "normal"
> ut_asserteq(old_base_time, base_time);
> 
> The thing is, the ->reset method does
> 
> static void reset_time(struct udevice *dev)
> {
> struct sandbox_i2c_rtc_plat_data *plat = dev_get_plat(dev);
> struct rtc_time now;
> 
> os_localtime();
> plat->base_time = rtc_mktime();
> 
> It's inevitable that this will cause occasional spurious failures. I can
> trivially reproduce it with
> 
> => while ut dm rtc_reset ; do echo . ; done
> 
> it fails after a few screenfuls of successes.

Yes, this test fails sometimes and just needs to be re-run.  Currently
we even have code in the test framework to allow for a little bit of
wiggle room in the value, but perhaps it needs to be bumped up slightly.

-- 
Tom


signature.asc
Description: PGP signature

Re: incompatible device trees between u-boot and linux

2021-08-31 Thread Sean Anderson


On 8/31/21 9:35 AM, Rob Herring wrote:

On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean  wrote:


On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:

On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:

On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:

On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:


Hi,

I noticed that there is a fallback to the u-boot device tree for linux
(esp. EFI boot) if no other device tree was found, see [1]. It seems this
is working fine for imx devices, for example, where you can just boot a
stock installer iso via EFI. It will just work and it is quite a nice
feature as a fallback.

Now for the layerscape architecture, the ls1028a in my case, things are
more difficult because the bindings differ between u-boot and linux - one
which comes to mind is DSA and ethernet.

Which begs the general question, is it encouraged to have both bindings
diverge? To me it seems, that most bindings in u-boot are ad-hoc and there
is no real review or alignment but just added as needed, which is ok if
they are local to u-boot. But since they are nowadays passed to linux
(by default!) I'm not so sure anymore.

OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
they should (could?) be shared between linux and u-boot.

-michael

[1]
https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471


The U-Boot device tree is supposed to be able to be passed on to Linux
and Just Work.  The bindings are not supposed to be different between
the two (except for when we take the binding while it's being hashed out
upstream BUT THEN RESYNCED).


You might need to spell that out a bit clearer.

You are saying that both U-Boot and Linux are allowed to have their own
custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = 
"in-band-status"'
for Linux), as long as the device tree files themselves are in sync, and
the subset of the device tree blob understood by Linux (i.e. the U-Boot
blob sans the U-Boot specifics) is compatible with the Linux DT blob?


I don't know what about the Linux example makes it Linux specific.  But
yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
by Linux.  The whole reason we have the -u-boot.dtsi automatic drop-in
logic (as much as it can be used is that device trees are device trees

 ^
 I don't think this parenthesis ever closes...


and describe the hardware and developers don't need to write a device
tree for Linux and a device tree for U-Boot and a device tree for
FreeBSD and ...  So yes, you're supposed to use the device tree for a

 ^
 so I never get the answer to "the whole reason is...".


platform and it works here and there and every where.


The fact that only Linux uses it makes it Linux specific.


To expand even further on that, it means we should put 'managed = 
"in-band-status"'
in U-Boot, which is a Linux phylink device tree property, even if U-Boot
does not use phylink?


We should be able to drop in the device trees from Linux and use them.
Custodians should be re-syncing them periodically.  Some are, even.


Are you ready to take up device tree bindings for PTP timers, PCIe root
complex event collectors, cascaded interrupt controllers, things which
U-Boot will never ever need to support?

At least in Linux there is a policy to not add device tree nodes that do
not have drivers.


That is not the policy. The policy is DT nodes must have binding
(schema) documentation and the binding should be complete as possible
(not what some driver currently uses). However, for complex bindings,
it might be difficult to write the binding in absence of a driver.


It is effective policy for some arches...

When the K210 patches were submitted, any bindings for devices without
enabled drivers were requested to be (and subsequently were) removed,
even though many of those bindings were based off of existing
documentation. This is the primary cause of divergence between the Linux
and U-Boot devicetrees for this platform. It is also the main reason
that I have not bothered putting together a sync patch.

--Sean

Re: [RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP


Hi Alexandru,

On 8/26/21 11:47 PM, Alexandru Gagniuc wrote:

Hi Patrick,

I proposing a better fix fir the issues I outlined earlier, I made a
classification of the currently supported boot modes.

1) BL1 -> SPL -> U-Boot
2) BL1 -> SPL -> OP-TEE
-
|  3) BL1 -> TF-A -> U-Boot |
|  4) BL1 -> TF-A -> OP-TEE |
| _ |
|| 5) BL1 -> TF-A -> FIP container ||
|| CONFIG_TFABOOT_FIP  ||
||_||
|   |
| CONFIG_TFABOOT|
-

Here, I'm looking at FIP as a new boot mode. In order to avoid
breakage, any changes to support FIP it should naturally be done only
to this new path.

This proposal contains several changes, but I've squashed them into
one for ease of discussion.

This better matches the boot mode classification above.


1) is supported but with many constraint for security part and low power 
management


    it is not recommended for real product / it will be not supported 
by STMicroelectronics


2) is not supported by STMicroelectronics, introduced by your patchset

3 and 4) are common for U-Boot point of view: running in normal world, 
STM32IMAGE container


BL1 -> TF-A -> SecureMonitor -> U-Boot (STM32IMAGE or FIP container)

With Secure Monitor

= SPMIN (included in a  the STM32IMAGE container of TF-A)

   or OP-TEE (loaded by TF-A BL2 in "tf-a.stm32", using the STM32IMAGE 
container)



The STM32IMAGE container are correct for the BL1 load with first root of 
trust but have limitations


for new security features (Public key infrastructure, secure software 
update, M4 firmware load by TF-A)


or for next products (coming soon) with limited size of embedded RAM.


So we decide to use for future development/product the default TF-A 
container = the FIP.


=> For the next products only we only support FIP container.


And the FIP containers is now the recommended TF-A container for 
STM32MP15 platform


and we could decide one day to deprecate/remove the STM32IMAGE support 
for STM32MP15 platform



It is why I introduced the CONFIG_STM32MP15x_STM32IMAGE,

to keep the compatibility with the previous "trusted" boot chain

and the default container is/becomes the FIP for all STM32MP product

=> this STM32IMAGE support (under compilation flag) could be removed in 
future


  by choice for the maintenance I prefer to mark the code

  to remove under a specific compilation flags only supported for 
STM32MP15x



Today I have the classification:

   1) BL1 -> SPL -> u-boot ("basic" boot)

-
|  2) BL1 -> TF-A -> u-boot ("trusted" boot)|
|   |
| 2.1) TF-A BL2 use STM32IMAGE container|
|  (CONFIG_STM32MP15x_STM32IMAGE => deprecated) |
|   |
| 2.2) TF-A BL2 use FIP container (new default) |
|   |
| CONFIG_TFABOOT|
-

The STM32IMAGE container support is only variant for STM32MP15x trusted boot.

FIP is a evolution of the STMicroelectronics proposal

and is now the default recommended container for trusted boot.


OP-TEE presence is detected dynamically in U-Boot (it should be
mandatory for next STM32MP product).



The root cause the of the issue is the introduction of

the "strange" OP-TEE after SPL boot mode (*)

1) BL1 -> SPL (secure) -> U-Boot (secure)

*) BL1 -> SPL (secure) -> OP-TEE (secure) -> kernel (normal world) for falcon 
mode

  -> U-Boot (normal world)

it is strange for me, because SPL and U-Boot are not running at the same 
exception level,
and OP-TEE firmware is only present/running when U-Boot proper is running.

So all my assumption in STM32MP platform are false
(SPL support => U-Boot is running in secure world when TFABOOT is not present)
and not only the FIP support.

This mode is not recommended: it will not supported by STMicroelectronics
and not supported by next products.

But you are free to manage it.

This new boot scheme could be managed by a new defconfig
to avoid to break the existing configuration (basic / trusted)
 



This config mixes boot path (2) with paths (3) and (4), and thus is
contrary to our goal of making changes only to the

Re: [PATCH] x86: Change SYS_LOAD_ADDR to 0x01000000

On Tue, Aug 31, 2021 at 10:11:36PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Tue, Aug 31, 2021 at 9:13 PM Tom Rini  wrote:
> >
> > At least on qemu, and likely other platforms, a load address of
> > 0x0200 ends up without our protected range currently.  Move this
> > down to 0x0100.
> 
> What is the protected range?

That's a good question.  I think we can disregard this patch for now.
While I was sure I bisected this failure:
https://source.denx.de/u-boot/u-boot/-/jobs/315982#L216
to the default load address being populated to loadaddr, I'm not seeing
it fail now locally like I was this morning.  I think maybe I had
mis-merged the SYS_LOAD_ADDR patch last night and cleaned that up as
part of making this patch work.

-- 
Tom

signature.asc
Description: PGP signature

Subject: [PATCH 3/6] pinctrl: qcom: add pinctrl and gpio drivers for SDM845

>From 520bc565a5a6f62c59f87bbd15a194ee61c103af Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Sun, 29 Aug 2021 21:53:40 +0300
Subject: [PATCH 3/6] pinctrl: qcom: add pinctrl and gpio drivers for SDM845
 SoC

Signed-off-by: Dzmitry Sankouski 
Cc: Ramon Fried 
---
 arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 +++
 arch/arm/mach-snapdragon/pinctrl-snapdragon.c |  1 +
 arch/arm/mach-snapdragon/pinctrl-snapdragon.h |  1 +
 drivers/gpio/msm_gpio.c   |  1 +
 drivers/gpio/pm8916_gpio.c|  8 ++--
 5 files changed, 52 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c

diff --git a/arch/arm/mach-snapdragon/pinctrl-sdm845.c
b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
new file mode 100644
index 00..6d66582aa6
--- /dev/null
+++ b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm SDM845 pinctrl
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ */
+
+#include "pinctrl-snapdragon.h"
+#include 
+
+#define MAX_PIN_NAME_LEN 32
+static char pin_name[MAX_PIN_NAME_LEN];
+
+static const struct pinctrl_function msm_pinctrl_functions[] = {
+ {"qup9", 1},
+ {"gpio", 0},
+};
+
+static const char *sdm845_get_function_name(struct udevice *dev,
+ unsigned int selector)
+{
+ return msm_pinctrl_functions[selector].name;
+}
+
+static const char *sdm845_get_pin_name(struct udevice *dev,
+ unsigned int selector)
+{
+ snprintf(pin_name, MAX_PIN_NAME_LEN, "GPIO_%u", selector);
+ return pin_name;
+}
+
+static unsigned int sdm845_get_function_mux(unsigned int selector)
+{
+ return msm_pinctrl_functions[selector].val;
+}
+
+struct msm_pinctrl_data sdm845_data = {
+ .pin_count = 150,
+ .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
+ .get_function_name = sdm845_get_function_name,
+ .get_function_mux = sdm845_get_function_mux,
+ .get_pin_name = sdm845_get_pin_name,
+};
diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
index e6b87c3573..c0ed943036 100644
--- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
+++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
@@ -116,6 +116,7 @@ static struct pinctrl_ops msm_pinctrl_ops = {
 static const struct udevice_id msm_pinctrl_ids[] = {
  { .compatible = "qcom,tlmm-apq8016", .data = (ulong)_data },
  { .compatible = "qcom,tlmm-apq8096", .data = (ulong)_data },
+ { .compatible = "qcom,tlmm-sdm845", .data = (ulong)_data },
  { }
 };

diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
index 61d466f4d8..ea524312a0 100644
--- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
+++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
@@ -27,5 +27,6 @@ struct pinctrl_function {

 extern struct msm_pinctrl_data apq8016_data;
 extern struct msm_pinctrl_data apq8096_data;
+extern struct msm_pinctrl_data sdm845_data;

 #endif
diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
index e1ff84c1c0..a3c3cd7824 100644
--- a/drivers/gpio/msm_gpio.c
+++ b/drivers/gpio/msm_gpio.c
@@ -120,6 +120,7 @@ static const struct udevice_id msm_gpio_ids[] = {
  { .compatible = "qcom,msm8916-pinctrl" },
  { .compatible = "qcom,apq8016-pinctrl" },
  { .compatible = "qcom,ipq4019-pinctrl" },
+ { .compatible = "qcom,sdm845-pinctrl" },
  { }
 };

diff --git a/drivers/gpio/pm8916_gpio.c b/drivers/gpio/pm8916_gpio.c
index 40b0f2578b..7ad95784a8 100644
--- a/drivers/gpio/pm8916_gpio.c
+++ b/drivers/gpio/pm8916_gpio.c
@@ -202,6 +202,7 @@ static int pm8916_gpio_of_to_plat(struct udevice *dev)
 static const struct udevice_id pm8916_gpio_ids[] = {
  { .compatible = "qcom,pm8916-gpio" },
  { .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
+ { .compatible = "qcom,pm8998-gpio" },
  { }
 };

@@ -266,7 +267,7 @@ static int pm8941_pwrkey_probe(struct udevice *dev)
  return log_msg_ret("bad type", -ENXIO);

  reg = pmic_reg_read(dev->parent, priv->pid + REG_SUBTYPE);
- if (reg != 0x1)
+ if ((reg & 0x5) == 0)
  return log_msg_ret("bad subtype", -ENXIO);

  return 0;
@@ -287,11 +288,12 @@ static int pm8941_pwrkey_of_to_plat(struct udevice
*dev)
 static const struct udevice_id pm8941_pwrkey_ids[] = {
  { .compatible = "qcom,pm8916-pwrkey" },
  { .compatible = "qcom,pm8994-pwrkey" },
+ { .compatible = "qcom,pm8998-pwrkey" },
  { }
 };

-U_BOOT_DRIVER(pwrkey_pm8941) = {
- .name = "pwrkey_pm8916",
+U_BOOT_DRIVER(pwrkey_pm89xx) = {
+ .name = "pwrkey_pm89xx",
  .id = UCLASS_GPIO,
  .of_match = pm8941_pwrkey_ids,
  .of_to_plat = pm8941_pwrkey_of_to_plat,
-- 
2.20.1

Subject: [PATCH 6/6] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board

>From 94e21cc200e09c51752e4bb86cfac320a92c48a5 Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Sun, 29 Aug 2021 21:57:33 +0300
Subject: [PATCH 6/6] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0)
board

Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
for China \ Hong Kong markets.
Has unlockable bootloader, unlike SM-G960U (American market version),
which allows running u-boot as a chain-loaded bootloader.

Signed-off-by: Dzmitry Sankouski 
---
 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/starqltechn-uboot.dtsi | 39 ++
 arch/arm/dts/starqltechn.dts| 53 +
 arch/arm/mach-snapdragon/Kconfig| 13 ++
 board/samsung/starqltechn/Kconfig   | 14 +++
 board/samsung/starqltechn/MAINTAINERS   |  6 +++
 board/samsung/starqltechn/Makefile  |  9 +
 board/samsung/starqltechn/starqltechn.c | 10 +
 configs/starqltechn_defconfig   | 33 +++
 include/configs/starqltechn.h   | 16 
 10 files changed, 194 insertions(+)
 create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi
 create mode 100644 arch/arm/dts/starqltechn.dts
 create mode 100644 board/samsung/starqltechn/Kconfig
 create mode 100644 board/samsung/starqltechn/MAINTAINERS
 create mode 100644 board/samsung/starqltechn/Makefile
 create mode 100644 board/samsung/starqltechn/starqltechn.c
 create mode 100644 configs/starqltechn_defconfig
 create mode 100644 include/configs/starqltechn.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 82a0790cc0..90d922dab7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -467,6 +467,7 @@ dtb-$(CONFIG_TARGET_SL28) +=
fsl-ls1028a-kontron-sl28.dtb \

 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
+dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb

 dtb-$(CONFIG_TARGET_STEMMY) += ste-ux500-samsung-stemmy.dtb

diff --git a/arch/arm/dts/starqltechn-uboot.dtsi
b/arch/arm/dts/starqltechn-uboot.dtsi
new file mode 100644
index 00..d8d75e018a
--- /dev/null
+++ b/arch/arm/dts/starqltechn-uboot.dtsi
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot addition to handle Samsung S9 SM-G9600 (starqltechn) pins
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ */
+
+/
+{
+ soc {
+ u-boot,dm-pre-reloc;
+ gcc {
+ clock-controller@10 {
+ u-boot,dm-pre-reloc;
+ };
+ serial@0xa84000 {
+ u-boot,dm-pre-reloc;
+ };
+ gpio_north@390 {
+ u-boot,dm-pre-reloc;
+ };
+ pinctrl@390 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+ };
+};
+
+_pon {
+ key_vol_down {
+ gpios = <_pon 1 0>;
+ label = "key_vol_down";
+ };
+ key_power {
+ gpios = <_pon 0 0>;
+ label = "key_power";
+ };
+};
diff --git a/arch/arm/dts/starqltechn.dts b/arch/arm/dts/starqltechn.dts
new file mode 100644
index 00..387420f30b
--- /dev/null
+++ b/arch/arm/dts/starqltechn.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Samsung S9 SM-G9600 (starqltechn) board device tree source
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ */
+
+/dts-v1/;
+
+#include "sdm845.dtsi"
+
+/ {
+ model = "Samsung S9 (SM-G9600)";
+ compatible = "qcom,sdm845-mtp", "qcom,sdm845", "qcom,mtp";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+
+ aliases {
+ serial0 = _uart;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000 0 0xfe1b>;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ soc: soc {
+ serial@0xa84000 {
+ status = "ok";
+ };
+
+ pinctrl@390 {
+ muic_i2c: muic_i2c {
+ pins = "GPIO_33", "GPIO_34";
+ drive-strength = <0x2>;
+ function = "gpio";
+ bias-disable;
+ };
+ };
+ };
+};
+
+#include "starqltechn-uboot.dtsi"
diff --git a/arch/arm/mach-snapdragon/Kconfig
b/arch/arm/mach-snapdragon/Kconfig
index 1a6a608967..90c9fcca2c 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -40,9 +40,22 @@ config TARGET_DRAGONBOARD820C
   - 3GiB RAM
   - 32GiB UFS drive

+config TARGET_STARQLTECHN
+ bool "Samsung S9 SM-G9600(starqltechn)"
+ help
+  Support for Samsung S9 SM-G9600(starqltechn) board.
+  Features:
+  - Qualcomm Snapdragon SDM845 SoC
+  - 4GiB RAM
+  - 64GiB UFS drive
+ select MISC_INIT_R
+ select SDM845
+ select DM_ETH if NET
+
 endchoice

 source "board/qualcomm/dragonboard410c/Kconfig"
 source "board/qualcomm/dragonboard820c/Kconfig"
+source "board/samsung/starqltechn/Kconfig"

 endif
diff --git a/board/samsung/starqltechn/Kconfig
b/board/samsung/starqltechn/Kconfig
new file mode 100644
index 00..7662eb87ab
--- /dev/null
+++ b/board/samsung/starqltechn/Kconfig
@@ -0,0 +1,14 @@
+if TARGET_STARQLTECHN
+
+config SYS_BOARD
+ default "starqltechn"
+ help
+  starqltechn is a production board for S9 and S9+ phones(SM-G96x0) phones
based on SDM845 SoC.
+
+config SYS_VENDOR
+ default "samsung"
+
+config SYS_CONFIG_NAME
+ default "starqltechn"
+
+endif
diff --git

Subject: [PATCH 5/6] SoC: qcom: add support for SDM845

>From 1deb063fe8d0e527b0fd412505b7614462c7fd19 Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Sun, 29 Aug 2021 21:55:31 +0300
Subject: [PATCH 5/6] SoC: qcom: add support for SDM845

Hi-end qualcomm chip, introduced in late 2017.
Mostly used in flagship phones and tablets of 2018.
Features:
- arm64 arch
- total of 8 Kryo 385 Gold / Silver cores
- Hexagon 685 DSP
- Adreno 630 GPU

Tested only as second-stage bootloader.

Signed-off-by: Dzmitry Sankouski 
Cc: Ramon Fried 
---
 arch/arm/dts/sdm845.dtsi  | 118 ++
 arch/arm/mach-snapdragon/Kconfig  |   4 +
 arch/arm/mach-snapdragon/Makefile |   4 +
 .../include/mach/sysmap-sdm845.h  |  42 +++
 arch/arm/mach-snapdragon/init_sdm845.c|  82 
 arch/arm/mach-snapdragon/sysmap-sdm845.c  |  31 +
 include/configs/sdm845.h  |  32 +
 7 files changed, 313 insertions(+)
 create mode 100644 arch/arm/dts/sdm845.dtsi
 create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h
 create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c
 create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c
 create mode 100644 include/configs/sdm845.h

diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
new file mode 100644
index 00..bf32c6995d
--- /dev/null
+++ b/arch/arm/dts/sdm845.dtsi
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm SDM845 chip device tree source
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ */
+
+/dts-v1/;
+
+#include "skeleton64.dtsi"
+
+/ {
+ soc: soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0x>;
+ compatible = "simple-bus";
+
+ gcc: clock-controller@10 {
+ u-boot,dm-pre-reloc;
+ compatible = "qcom,gcc-sdm845";
+ reg = <0x0010 0x1f>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ gpio_north: gpio_north@390 {
+ u-boot,dm-pre-reloc;
+ #gpio-cells = <2>;
+ compatible = "qcom,sdm845-pinctrl";
+ reg = <0x390 0x40>;
+ gpio-count = <150>;
+ gpio-controller;
+ gpio-ranges = <_north 0 0 150>;
+ gpio-bank-name = "soc_north.";
+ };
+
+ tlmm_north: pinctrl_north@390 {
+ u-boot,dm-pre-reloc;
+ compatible = "qcom,tlmm-sdm845";
+ reg = <0x0390 0x40>;
+ gpio-count = <150>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <_north 0 0 150>;
+
+ /* DEBUG UART */
+ qup_uart9: qup-uart9-default {
+ pinmux {
+ pins = "GPIO_4", "GPIO_5";
+ function = "qup9";
+ };
+ };
+ };
+
+ debug_uart: serial@0xa84000 {
+ compatible = "qcom,msm-geni-uart";
+ reg = <0xa84000 0x4000>;
+ reg-names = "se_phys";
+ clock-names = "se-clk";
+ clocks = < 0x58>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart9>;
+ qcom,wrapper-core = <0x8a>;
+ status = "disabled";
+ };
+
+ spmi@c44 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0xc44 0x1100>,
+  <0xc60 0x200>,
+  <0xe60 0x10>;
+ reg-names = "cnfg", "core", "obsrvr";
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ qcom,revid@100 {
+ compatible = "qcom,qpnp-revid";
+ reg = <0x100 0x100>;
+ linux,phandle = <0x3ac>;
+ phandle = <0x3ac>;
+ };
+
+ pmic0: pm8998@0 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x0 0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ pm8998_pon: pm8998_pon@800 {
+ compatible = "qcom,pm8998-pwrkey";
+ reg = <0x800 0x100>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-bank-name="pm8998_key.";
+ };
+
+ pm8998_gpios: pm8998_gpios@c000 {
+ compatible = "qcom,pm8998-gpio";
+ reg = <0xc000 0x1a00>;
+ gpio-controller;
+ gpio-count = <21>;
+ #gpio-cells = <2>;
+ gpio-bank-name="pm8998.";
+ };
+ };
+
+ pmic1: pm8998@1 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x1 0x0>;
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-snapdragon/Kconfig
b/arch/arm/mach-snapdragon/Kconfig
index 0ec74fa5d3..1a6a608967 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -9,6 +9,10 @@ config SYS_MALLOC_F_LEN
 config SPL_SYS_MALLOC_F_LEN
  default 0x2000

+config SDM845
+ bool "Qualcomm Snapdragon 845 SoC"
+ default n
+
 choice
  prompt "Snapdragon board select"

diff --git a/arch/arm/mach-snapdragon/Makefile
b/arch/arm/mach-snapdragon/Makefile
index 709919fce4..962855eb8c 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -2,6 +2,9 @@
 #
 # (C) Copyright 2015 Mateusz Kulikowski 

+obj-$(CONFIG_SDM845) += clock-sdm845.o
+obj-$(CONFIG_SDM845) += sysmap-sdm845.o
+obj-$(CONFIG_SDM845) += init_sdm845.o
 obj-$(CONFIG_TARGET_DRAGONBOARD820C) += clock-apq8096.o
 obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
 obj-$(CONFIG_TARGET_DRAGONBOARD410C) += clock-apq8016.o
@@ -12,3 +15,4 @@ obj-y += dram.o
 obj-y += pinctrl-snapdragon.o
 obj-y += pinctrl-apq8016.o
 obj-y += pinctrl-apq8096.o
+obj-$(CONFIG_SDM845) += pinctrl-sdm845.o
diff --git a/arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h

Re: [PATCH v6 12/12] sandbox: add test of wdt-uclass' watchdog_reset()

2021-08-31 Thread Rasmus Villemoes

On 31/08/2021 10.17, Stefan Roese wrote:
> Hi Rasmus,
> 
> I've pulled this patchset now into next [1] and have run it through
> CI via Azure. Here an error occurs:
> 
> https://dev.azure.com/sr0718/u-boot/_build/results?buildId=109=logs=50449d1b-398e-53ae-48fa-6bf338edeb51=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6=533
> 
> 
> Could you please take a look at this?

I'm pretty confident that has nothing to do with my patches, but is a
broken (or, to put it more gently, fragile) test.

It does

// fetch the emulated device's current base_time value, setting it to 0
old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);

// fetch the emuluated device's current base_time value, don't (-1) set
// a new value, check that we got 0
ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));

// call the device's ->reset method
/* Resetting the RTC should put he base time back to normal */
ut_assertok(dm_rtc_reset(dev));
// fetch the new base_time value, without altering it
base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
// and check that the base time was put back to "normal"
ut_asserteq(old_base_time, base_time);

The thing is, the ->reset method does

static void reset_time(struct udevice *dev)
{
struct sandbox_i2c_rtc_plat_data *plat = dev_get_plat(dev);
struct rtc_time now;

os_localtime();
plat->base_time = rtc_mktime();

It's inevitable that this will cause occasional spurious failures. I can
trivially reproduce it with

=> while ut dm rtc_reset ; do echo . ; done

it fails after a few screenfuls of successes.

Rasmus

Subject: [PATCH 4/6] clocks: qcom: add clocks for SDM845 debug uart

>From 647a2cd58fff0e9d7e232dc5970071c5c91bb09f Mon Sep 17 00:00:00 2001
From: Dzmitry Sankouski 
Date: Sun, 29 Aug 2021 21:54:57 +0300
Subject: [PATCH 4/6] clocks: qcom: add clocks for SDM845 debug uart

Allows to change clock frequency of debug uart,
thus supporting wide range of baudrates.
Enable / disable functionality is not implemented yet.
In most use cases of SDM845 (i.e. mobile phones and tablets)
it's not needed, because qualcomm first stage bootloader leaves it
initialized, and on the other hand there's no possibility to
replace signed first stage bootloader with u-boot.

Signed-off-by: Dzmitry Sankouski 
Cc: Ramon Fried 
---
 arch/arm/mach-snapdragon/clock-sdm845.c | 92 +
 arch/arm/mach-snapdragon/clock-snapdragon.c |  1 +
 arch/arm/mach-snapdragon/clock-snapdragon.h |  3 +-
 3 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-snapdragon/clock-sdm845.c

diff --git a/arch/arm/mach-snapdragon/clock-sdm845.c
b/arch/arm/mach-snapdragon/clock-sdm845.c
new file mode 100644
index 00..9572639238
--- /dev/null
+++ b/arch/arm/mach-snapdragon/clock-sdm845.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Clock drivers for Qualcomm SDM845
+ *
+ * (C) Copyright 2017 Jorge Ramirez Ortiz 
+ * (C) Copyright 2021 Dzmitry Sankouski 
+ *
+ * Based on Little Kernel driver, simplified
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clock-snapdragon.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+struct freq_tbl {
+ uint freq;
+ uint src;
+ u8 pre_div;
+ u16 m;
+ u16 n;
+};
+
+static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
+ F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
+ F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
+ F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+ F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
+ F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
+ F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
+ F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
+ F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
+ F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
+ F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
+ F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
+ F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
+ F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
+ F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
+ F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
+ { }
+};
+
+static const struct bcr_regs uart2_regs = {
+ .cfg_rcgr = SE9_UART_APPS_CFG_RCGR,
+ .cmd_rcgr = SE9_UART_APPS_CMD_RCGR,
+ .M = SE9_UART_APPS_M,
+ .N = SE9_UART_APPS_N,
+ .D = SE9_UART_APPS_D,
+};
+
+const struct freq_tbl *qcom_find_freq(const struct freq_tbl *f, uint rate)
+{
+ if (!f)
+ return NULL;
+
+ if (!f->freq)
+ return f;
+
+ for (; f->freq; f++)
+ if (rate <= f->freq)
+ return f;
+
+ /* Default to our fastest rate */
+ return f - 1;
+}
+
+static int clk_init_uart(struct msm_clk_priv *priv, uint rate)
+{
+ const struct freq_tbl *freq =
qcom_find_freq(ftbl_gcc_qupv3_wrap0_s0_clk_src, rate);
+
+ clk_rcg_set_rate_mnd(priv->base, _regs,
+ freq->pre_div, freq->m, freq->n, freq->src);
+
+ return 0;
+}
+
+ulong msm_set_rate(struct clk *clk, ulong rate)
+{
+ struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+
+ switch (clk->id) {
+ case 0x58: /*UART2*/
+ return clk_init_uart(priv, rate);
+ default:
+ return 0;
+ }
+}
diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.c
b/arch/arm/mach-snapdragon/clock-snapdragon.c
index 2b76371718..3deb08ac4a 100644
--- a/arch/arm/mach-snapdragon/clock-snapdragon.c
+++ b/arch/arm/mach-snapdragon/clock-snapdragon.c
@@ -135,6 +135,7 @@ static const struct udevice_id msm_clk_ids[] = {
  { .compatible = "qcom,gcc-apq8016" },
  { .compatible = "qcom,gcc-msm8996" },
  { .compatible = "qcom,gcc-apq8096" },
+ { .compatible = "qcom,gcc-sdm845" },
  { }
 };

diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.h
b/arch/arm/mach-snapdragon/clock-snapdragon.h
index 58fab40a2e..2ac53b538d 100644
--- a/arch/arm/mach-snapdragon/clock-snapdragon.h
+++ b/arch/arm/mach-snapdragon/clock-snapdragon.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Qualcomm APQ8016, APQ8096
+ * Qualcomm APQ8016, APQ8096, SDM845
  *
  * (C) Copyright 2017 Jorge Ramirez-Ortiz 
  */
@@ -9,6 +9,7 @@

 #define CFG_CLK_SRC_CXO   (0 << 8)
 #define CFG_CLK_SRC_GPLL0 (1 << 8)
+#define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
 #define CFG_CLK_SRC_MASK  (7 << 8)

 struct pll_vote_clk {
-- 
2.20.1

[PATCH v2] mx7ulp: add getting a board serial number

From: Ricardo Salveti 

Get Unique ID of SoC iMX7ULP, using the logic described in Fusemap
(IMX7ULPRMB2_Rev0_Fusemap) attached in the i.MX 7ULP APRM [1].

[1]
https://www.nxp.com/docs/en/reference-manual/IMX7ULPRMB2.pdf

Signed-off-by: Ricardo Salveti 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
---

Changes in v2:
- rebase the commit on top of the following series:
  https://patchwork.ozlabs.org/project/uboot/list/?series=260161

 arch/arm/mach-imx/mx7ulp/soc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 320f24dd29..baf18cf8b7 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define PMC0_BASE_ADDR 0x410a1000
@@ -363,3 +364,25 @@ enum boot_device get_boot_device(void)
 
return boot_dev;
 }
+
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+/*
+ * OCOTP_CFG (SJC CHALLENGE, Unique ID)
+ * i.MX 7ULP Applications Processor Reference Manual, Rev. 0, 09/2020
+ *
+ * OCOTP_CFG0 offset 0x4B0: 15:0 -> 15:0  bits of Unique ID
+ * OCOTP_CFG1 offset 0x4C0: 15:0 -> 31:16 bits of Unique ID
+ * OCOTP_CFG2 offset 0x4D0: 15:0 -> 47:32 bits of Unique ID
+ * OCOTP_CFG3 offset 0x4E0: 15:0 -> 63:48 bits of Unique ID
+ */
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank->fuse_regs;
+
+   serialnr->low = (fuse->cfg0 & 0x) + ((fuse->cfg1 & 0x) << 16);
+   serialnr->high = (fuse->cfg2 & 0x) + ((fuse->cfg3 & 0x) << 16);
+}
+#endif /* CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG */
-- 
2.31.1

[PATCH] x86: Change SYS_LOAD_ADDR to 0x01000000

At least on qemu, and likely other platforms, a load address of
0x0200 ends up without our protected range currently.  Move this
down to 0x0100.

Cc: Bin Meng 
Signed-off-by: Tom Rini 
---
 Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index 931a22806e4e..eaf48b80196f 100644
--- a/Kconfig
+++ b/Kconfig
@@ -389,8 +389,8 @@ config SYS_LDSCRIPT
 
 config SYS_LOAD_ADDR
hex "Address in memory to use by default"
-   default 0x0100 if ARCH_SOCFPGA
-   default 0x0200 if PPC || X86
+   default 0x0100 if ARCH_SOCFPGA || X86
+   default 0x0200 if PPC
default 0x2200 if MACH_SUN9I
default 0x4200 if ARCH_SUNXI && !MACH_SUN9I
default 0x8200 if ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
-- 
2.17.1

Re: [PATCH 4/9] mvebu: ddr: Rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE

On Tue, Aug 31, 2021 at 07:51:29AM +0200, Stefan Roese wrote:
> Hi Tom,
> 
> On 21.08.21 19:50, Tom Rini wrote:
> > We have a number of CONFIG symbols to express the fixed size of system
> > memory.  For now, rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE
> > and adjust usage to match that CONFIG_SYS_SDRAM_SIZE expects the entire
> > size rather than MiB.
> > 
> > Cc: Marek Behún 
> > Cc: Stefan Roese 
> > Signed-off-by: Tom Rini 
> > ---
> >   drivers/ddr/marvell/axp/ddr3_axp.h | 4 ++--
> >   include/configs/maxbcm.h   | 4 +++-
> >   include/configs/theadorable.h  | 4 +++-
> >   3 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/ddr/marvell/axp/ddr3_axp.h 
> > b/drivers/ddr/marvell/axp/ddr3_axp.h
> > index 270691e9bcd3..970651f87029 100644
> > --- a/drivers/ddr/marvell/axp/ddr3_axp.h
> > +++ b/drivers/ddr/marvell/axp/ddr3_axp.h
> > @@ -19,10 +19,10 @@
> >   #define FAR_END_DIMM_ADDR 0x50
> >   #define MAX_DIMM_ADDR 0x60
> > -#ifndef CONFIG_DDR_FIXED_SIZE
> > +#ifndef CONFIG_SYS_SDRAM_SIZE
> >   #define SDRAM_CS_SIZE 0xFFF
> >   #else
> > -#define SDRAM_CS_SIZE  (CONFIG_DDR_FIXED_SIZE - 1)
> > +#define SDRAM_CS_SIZE  ((CONFIG_SYS_SDRAM_SIZE >> 10) 
> > - 1)
> 
> Why are you using ">> 10" (dividing by 1024) here?
> 
> Thanks,
> Stefan
> 
> >   #endif
> >   #define SDRAM_CS_BASE 0x0
> >   #define SDRAM_DIMM_SIZE   0x8000
> > diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
> > index fc2393204bec..5098f12f5425 100644
> > --- a/include/configs/maxbcm.h
> > +++ b/include/configs/maxbcm.h
> > @@ -6,6 +6,8 @@
> >   #ifndef _CONFIG_DB_MV7846MP_GP_H
> >   #define _CONFIG_DB_MV7846MP_GP_H
> > +#include 
> > +
> >   /*
> >* High Level Configuration Options (easy to change)
> >*/
> > @@ -65,7 +67,7 @@
> >   /* SPL related SPI defines */
> >   /* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
> > -#define CONFIG_DDR_FIXED_SIZE  (1 << 20)   /* 1GiB */
> > +#define CONFIG_SYS_SDRAM_SIZE  SZ_1G

OK, so before my change, SDRAM_CS_SIZE = 0xf.  After my change,
SDRAM_CS_SIZE = 0xf, still.

> >   #define CONFIG_BOARD_ECC_SUPPORT  /* this board supports ECC */
> >   #endif /* _CONFIG_DB_MV7846MP_GP_H */
> > diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h
> > index 760713d3ef87..abc48ff44ca5 100644
> > --- a/include/configs/theadorable.h
> > +++ b/include/configs/theadorable.h
> > @@ -6,6 +6,8 @@
> >   #ifndef _CONFIG_THEADORABLE_H
> >   #define _CONFIG_THEADORABLE_H
> > +#include 
> > +
> >   /*
> >* High Level Configuration Options (easy to change)
> >*/
> > @@ -93,6 +95,6 @@
> >   #define CONFIG_SPL_BOOTROM_SAVE   (CONFIG_SPL_STACK + 4)
> >   /* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
> > -#define CONFIG_DDR_FIXED_SIZE  (2 << 20)   /* 2GiB */
> > +#define CONFIG_SYS_SDRAM_SIZE  SZ_2G

Here, before SDRAM_CS_SIZE = 0x1f and then after SDRAM_CS_SIZE =
0x1f.

This is because CONFIG_DDR_FIXED_SIZE is kilobytes and
CONFIG_SYS_SDRAM_SIZE is bytes, yes?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 07/10] stm32mp1: spl: Configure MAC address when booting OP-TEE


Hi,


On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

When OP-TEE is booted as the SPL payload, the stage after OP-TEE is
not guaranteed to be u-boot. Thus the FDT patching in u-boot is not
guaranteed to occur. Add this step to SPL.

The patching by stm32_fdt_setup_mac_addr() is done in SPL, and patches
the target FDT directly. This differs is different from
setup_mac_address(), which sets the "ethaddr" env variable, and does
not work in SPL.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/cpu.c   | 22 +++
  .../arm/mach-stm32mp/include/mach/sys_proto.h |  3 +++
  arch/arm/mach-stm32mp/spl.c   |  1 +
  3 files changed, 26 insertions(+)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 8727de513c..2b8b67bb40 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -646,6 +647,27 @@ __weak int setup_mac_address(void)
return 0;
  }
  
+int stm32_fdt_setup_mac_addr(void *fdt)

+{
+   int ret;
+   uchar enetaddr[ARP_HLEN];
+
+   ret = stm32_read_otp_mac(enetaddr);
+   if (ret < 0)
+   return ret;
+
+   if (!is_valid_ethaddr(enetaddr)) {
+   printf("invalid MAC address in OTP\n");
+   return -EINVAL;
+   }
+
+   ret = fdt_ethernet_set_macaddr(fdt, 0, enetaddr);
+   if (ret)
+   debug("Failed to set mac address from OTP: %d\n", ret);
+
+   return ret;
+}
+
  static int setup_serial_number(void)
  {
char serial_string[25];
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h 
b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
index 4149d3a133..2d24cfee3f 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -47,7 +47,10 @@ void get_soc_name(char name[SOC_NAME_SIZE]);
  /* return boot mode */
  u32 get_bootmode(void);
  
+/* Set 'ethaddr' env variable with MAC from OTP (useful for u-boot proper) */

  int setup_mac_address(void);
+/* Patch the first 'ethernet' node of FDT with MAC from OTP (useful for SPL) */
+int stm32_fdt_setup_mac_addr(void *fdt);
  
  /* board power management : configure vddcore according OPP */

  void board_vddcore_init(u32 voltage_mv);
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index 405eff68a3..d9fdc5926c 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -181,6 +181,7 @@ void stm32_init_tzc_for_optee(void)
  
  void spl_board_prepare_for_optee(void *fdt)

  {
+   stm32_fdt_setup_mac_addr(fdt);
stm32_init_tzc_for_optee();
  }
  



I think that all this part is not required for falcon mode:

let the Linux driver fallback to nvmem access to read the MAC address in 
OTP when the DT is not updated by boot loader


remove also the patch 06/10 and 04/40

PS: it is already working in OpenSTLinux based on the device tree 
modification for your board


{
            ethernet_mac_address: mac@e4 {
        reg = <0xe4 0x6>;
};

 {
    nvmem-cells = <_mac_address>;
    nvmem-cell-names = "mac-address";
};

PS: this part is not yet upstreamed in Linux

Linux reference = 
Documentation/devicetree/bindings/net/ethernet-controller.yaml



  nvmem-cells:
    maxItems: 1
    description:
  Reference to an nvmem node for the MAC address

  nvmem-cell-names:
    const: mac-address


Patrick

[PATCH 0/2] arm: mach-k3: Fix corruption of device manager firmware

The following series takes care of two problems:
a) A potential race when R5 (boot processor) is parsing and loading DM
  firmware elf sections way slower than A53 executing.
b) We load the FIT image to the same address as the elf sections. See
 [1] as example.

NOTE: Though, in theory, the Device Manager's linker file could be constructed
such as to avoid the overlap address, there is no guarentee of implicit
assumptions and the fact that DM's firmware can be combined with additional
functionality could result in unexpected behavior as well.

To prevent this, lets just have explicit load address and sequencing.

Nishanth Menon (2):
  arm: mach-k3: common: Make sure firmware sections are loaded prior to
armv8 startup
  tools: k3_fit_atf: Change DM load address to avoid conflict

 arch/arm/mach-k3/common.c | 30 ++
 tools/k3_fit_atf.sh   |  4 ++--
 2 files changed, 20 insertions(+), 14 deletions(-)

[1]
$ arm-none-linux-gnueabihf-readelf -S 
ti-dm/j721e/ipc_echo_testb_mcu1_0_release_strip.xer5f
There are 39 section headers, starting at offset 0x2aa98:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .freertosrst[...] PROGBITS4101 38 40 00  AX  0   0  8
  [ 2] .bootCode PROGBITS41010a60 000a98 000118 00  AX  0   0  8
  [ 3] .startupCode  PROGBITS41010410 000448 000338 00  AX  0   0  8
  [ 4] .startupData  PROGBITS41010748 000780 000318 00   A  0   0  8
  [ 5] .text.hwi PROGBITS41010040 78 0003d0 00  AX  0   0  8
  [ 6] .text.cache   NOBITS  41010410 02a680 00 00  AX  0   0  8
  [ 7] .text.mpu NOBITS  41010410 02a680 00 00  AX  0   0  8
  [ 8] .text.bootNOBITS  41010410 02a680 00 00  AX  0   0  8
  [ 9] .text PROGBITSa05b8fb0 002000 016340 00  AX  0   0  8
  [10] .constPROGBITSa05cf2f0 018340 00c470 00   A  0   0  8
  [11] .cinitPROGBITSa0581400 001100 000818 00   A  0   0  8
  [12] .bss  NOBITS  a0582000 002000 036faa 00  WA  0   0 
8192
  [13] .far  NOBITS   00 00 00  0   0  4
  [14] .data NOBITS  a05db780 024800 008100 00  WA  0   0 
128
  [15] .sysmem   NOBITS   00 00 00  0   0  1
  [16] .data_buffer  NOBITS   02a680 00 00  WA  0   0 
128
  [17] .bss.devgroup*NOBITS  a05e9700 02a680 0011f8 00  WA  0   0  4
  [18] .const.devgroup*  PROGBITSa05e3880 024800 004710 00   A  0   0  4
  [19] .boardcfg_dataPROGBITSa05e8000 028f80 001700 00   A  0   0 
128
  [20] .benchmark_buffer NOBITS   00 00 00  0   0  8
  [21] ipc_data_buffer   NOBITS  a040 001100 181400 00  WA  0   0 
128
  [22] .resource_table   PROGBITSa018 001000 8c 00   A  0   0 
4096
  [23] .tracebuf NOBITS  a010 000c00 08 00  WA  0   0 
1024
  [24] .stackNOBITS  a0ffc000 02a680 004000 00  WA  0   0  8
  [25] .irqStack NOBITS  a0ffae00 02a880 001000 00   A  0   0  4
  [26] .fiqStack NOBITS  a0ffbe00 02b880 000100 00   A  0   0  4
  [27] .abortStack   NOBITS  a0ffbf00 02b980 000100 00   A  0   0  4
  [28] .undStack NOBITS  a0ffac00 02a680 000100 00   A  0   0  4
  [29] .svcStack NOBITS  a0ffad00 02a780 000100 00   A  0   0  4
  [30] .TI.noinitNOBITS   00 00 00  0   0  4
  [31] .TI.persistentNOBITS   00 00 00  0   0 
128
  [32] __llvm_prf_cnts   NOBITS  a040 02a680 00 00   A  0   0  4
  [33] Veneer$$CMSE  NOBITS   00 00 00  0   0  1
  [34] .ARM.attributes   ARM_ATTRIBUTES   02a680 5b 00  0   0  0
  [35] .symtab   SYMTAB   02a6dc 30 10 37   1  0
  [36] .TI.section.flags PROGBITS 02a70c 20 00  0   0  0
  [37] .strtab   STRTAB   02a72c 14 01   S  0   0  0
  [38] .shstrtab STRTAB   02a740 0001b6 01   S  0   0  0

-- 
2.32.0

[PATCH 1/2] arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 startup

With Device Manager firmware in an elf file form, we cannot load the FIT
image to the exact same address as any of the executable sections of the
elf file itself is located.

However, the device tree descriptions for the ARMV8 bootloader/OS
includes DDR regions only the final sections in DDR where the Device
Manager firmware is actually executing out of.

As the R5 uC is usually operating at a slower rate than an ARMv8 MPU,
by starting the Armv8 ahead of parsing the elf and copying the correct
sections to the required memories creates a race condition where the
ARMv8 could overwrite the elf image loaded from the FIT image prior to
the R5 completing parsing and putting the correct sections of elf in
the required memory locations. OR create rather obscure debug conditions
where data in the section is being modified by ARMV8 OS while the elf
copy is in progress.

To prevent all these conditions, lets make sure that the elf parse and
copy operations are completed ahead of ARMv8 being released to execute.

We will pay a penalty of elf copy time, but that is a valid tradeoff in
comparison to debug of alternate scenarios.

Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-k3/common.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index bb0f64194f4e..64933933fe1f 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -198,7 +198,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
*spl_image)
typedef void __noreturn (*image_entry_noargs_t)(void);
struct ti_sci_handle *ti_sci = get_ti_sci_handle();
u32 loadaddr = 0;
-   int ret, size = 0;
+   int ret, size = 0, shut_cpu = 0;
 
/* Release all the exclusive devices held by SPL before starting ATF */
ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
@@ -226,19 +226,10 @@ void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
if (ret)
panic("%s: ATF failed to load on rproc (%d)\n", __func__, ret);
 
-   /* Add an extra newline to differentiate the ATF logs from SPL */
-   printf("Starting ATF on ARM64 core...\n\n");
-
-   ret = rproc_start(1);
-   if (ret)
-   panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
if (!fit_image_info[IMAGE_ID_DM_FW].image_len &&
!(size > 0 && valid_elf_image(loadaddr))) {
-   debug("Shutting down...\n");
-   release_resources_for_core_shutdown();
-
-   while (1)
-   asm volatile("wfe");
+   shut_cpu = 1;
+   goto start_arm64;
}
 
if (!fit_image_info[IMAGE_ID_DM_FW].image_start) {
@@ -251,6 +242,21 @@ void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
 
debug("%s: jumping to address %x\n", __func__, loadaddr);
 
+start_arm64:
+   /* Add an extra newline to differentiate the ATF logs from SPL */
+   printf("Starting ATF on ARM64 core...\n\n");
+
+   ret = rproc_start(1);
+   if (ret)
+   panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
+
+   if (shut_cpu) {
+   debug("Shutting down...\n");
+   release_resources_for_core_shutdown();
+
+   while (1)
+   asm volatile("wfe");
+   }
image_entry_noargs_t image_entry = (image_entry_noargs_t)loadaddr;
 
image_entry();
-- 
2.32.0

[PATCH 2/2] tools: k3_fit_atf: Change DM load address to avoid conflict

DM binary is expected to be an elf file. The expected address of
this elf is in the range of 0xa000_ in DDR. In the current
configuration, elf file is loaded to the exact same address and we
invoke load_elf_image_phdr to decode and memcpy sections of the elf to
the same address range, we are eventually going to overwrite sections
of the original elf image itself corrupting the DM firmware as a
result.

To prevent this, we must load the DM section to an address that does'nt
overlap with the actual section address where it will eventually be
copied to.

Lets add an offset of 256MB to a lesser used DDR address, yet within
the typical 1GB address space.

We may need to consider going for a configuration option if this is
turning to be a limitation (boards with lesser DDR space).

Signed-off-by: Nishanth Menon 
---
 tools/k3_fit_atf.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
index 3a476ced98b1..6469f188e8ff 100755
--- a/tools/k3_fit_atf.sh
+++ b/tools/k3_fit_atf.sh
@@ -67,8 +67,8 @@ cat << __HEADER_EOF
arch = "arm32";
compression = "none";
os = "DM";
-   load = <0xa000>;
-   entry = <0xa000>;
+   load = <0xb000>;
+   entry = <0xb000>;
};
spl {
description = "SPL (64-bit)";
-- 
2.32.0

Re: [PATCH 01/10] stm32mp1: Add support for baudrates higher than 115200


Hi,

I add in CC the ARM STM STM32MP Maintainers...

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

The UART can reliably go up to 200 baud when connected to the
on-board st-link. Unfortunately u-boot will fall back to 115200 unless
higher rates are declared via CONFIG_SYS_BAUDRATE_TABLE.

Signed-off-by: Alexandru Gagniuc 
---
  include/configs/stm32mp1.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index b372838be8..9fcd60285a 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -16,6 +16,10 @@
  #define CONFIG_ARMV7_SECURE_MAX_SIZE  STM32_SYSRAM_SIZE
  #endif
  
+#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200, \

+230400, 460800, 921600, \
+100, 200 }
+
  /*
   * Configuration of the external SRAM memory used by U-Boot
   */


Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH 02/10] stm32mp1: Add support for falcon mode boot from SD card


Hi,

Add in CC the MAINTAINERS

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

Falcon mode requires a board-specific mechanism to select between
fast and normal boot. This is done via spl_start_uboot()

Use the B2 button as the selection mechanism. This is connected to
GPIO PA13. Incidentally, this GPIO is already accessible via the
"st,fastboot-gpios" devicetree node.

Offsets for raw MMC loading are defined. These point to the partition
after "ssbl".

Signed-off-by: Alexandru Gagniuc 
---
  board/st/stm32mp1/spl.c| 39 ++
  include/configs/stm32mp1.h | 13 +
  2 files changed, 52 insertions(+)

diff --git a/board/st/stm32mp1/spl.c b/board/st/stm32mp1/spl.c
index 8e4549a1b3..bb210d7727 100644
--- a/board/st/stm32mp1/spl.c
+++ b/board/st/stm32mp1/spl.c
@@ -8,6 +8,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include "../common/stpmic1.h"
@@ -29,6 +30,44 @@ int board_early_init_f(void)
return 0;
  }
  
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT)

+int spl_start_uboot(void)
+{
+   ofnode node;
+   struct gpio_desc gpio;
+   int boot_uboot = 1;
+
+   node = ofnode_path("/config");
+   if (!ofnode_valid(node)) {
+   pr_warn("%s: no /config node?\n", __func__);
+   return 0;
+   }
+
+   if (gpio_request_by_name_nodev(node, "st,fastboot-gpios", 0, ,
+  GPIOD_IS_IN)) {
+   pr_warn("%s: could not find a /config/st,fastboot-gpios\n",
+   __func__);
+   return 1;
+   }


The node "st,fastboot-gpios" is used in STMicroelectronics devicetree / board
to select the KEY to launch the ANDROID command fastboot in board_key_check()

=> it can't be re-used to other purpose else you will have conflict when the key
   is pressed:
   
   what append when key pressed in basic boot mode when KEY is pressed ?

   => falcon mode selected in SPL or FASTBOOT mode selected 

"st,fastboot-gpios" meaning is defined in:

https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#Config_node

you should use a other config ?
=> "mrnuke,falcon-gpios" managed in your board .c file / dts file

or hardcoded in your board.c ?

or use environment
if (env_get_yesno("boot_os") != 0)


+
+   boot_uboot = dm_gpio_get_value();
+   dm_gpio_free(NULL, );
+
+   return boot_uboot;
+}
+
+#if IS_ENABLED(CONFIG_ARMV7_NONSEC)
+/*
+ * A bit of a hack, but armv7_boot_nonsec() is provided by bootm.c. This is not
+ * available in SPL, so we have to provide an implementation.
+ */
+bool armv7_boot_nonsec(void)
+{
+   return 0;
+}
+#endif /* CONFIG_ARMV7_NONSEC */
+#endif /* CONFIG_SPL_OS_BOOT */
+
  #ifdef CONFIG_DEBUG_UART_BOARD_INIT
  void board_debug_uart_init(void)
  {
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 9fcd60285a..0849a1bddb 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -10,6 +10,19 @@
  #include 
  #include 
  
+/*

+ * Arguments if falcon mode is used
+ * CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR is the partition after "ssbl"
+ * CONFIG_SYS_SPL_ARGS_ADDR is not used, but needs to point to valid RAM.
+ */
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 5154


The offset of kernel is hardcoded

=> it is not acceptable here (generic stm32mp1 file)


+#define CONFIG_SYS_SPL_ARGS_ADDR 0xc400
+
+/* Falcon mode from SPI is not supported, but the defines are needed */
+#define CONFIG_SYS_SPI_KERNEL_OFFS (~0)
+#define CONFIG_SYS_SPI_ARGS_OFFS   (~0)
+#define CONFIG_SYS_SPI_ARGS_SIZE   0
+


Falcon mode is not supported by ST Microelectronics
and this file is expected to support the ST boards (board/st/stm32mp1)

=> these defines should be in your configuration not in the GENERIC stm32mp1 
files

for example in

include/configs/stm32mp15_falcon.h

#include "stm32mp1.h"



with CONFIG_SYS_CONFIG_NAME =  "stm32mp15_falcon" in your Kconfig



  #ifndef CONFIG_TFABOOT
  /* PSCI support */
  #define CONFIG_ARMV7_SECURE_BASE  STM32_SYSRAM_BASE



Patrick

nand/am335x_spl_bch - SPL NAND loading hang on power on only

2021-08-31 Thread Kevin Baker

 Hi all,

I am working on updating our version of u-boot, and came across something
weird - the SPL hangs after "Trying to load NAND" on the first power-on
boot, but after a watchdog reset or power-on reset, the NAND works fine.

U-Boot SPL 2021.01-00010-g8c91cf967b-dirty (Aug 30 2021 - 19:03:45
-0500)
Trying to boot from NAND   hangs here until watchdog reset

After checking more common issues - pinmux/config/timing/NAND connections,
etc. and printf-tracing it, it is actually hanging after board_nand_init
and at this call to select_chip before getting to NAND_CMD_RESET:

drivers/mtd/nand/raw/am335x_spl_bch.c: nand_init()
...
board_nand_init(_chip);

if (nand_chip.select_chip)
nand_chip.select_chip(mtd, 0); stuck here ??? 

/* NAND chip may require reset after power-on */
nand_command(0, 0, 0, NAND_CMD_RESET);
...

Somehow, the first power up, nand_chip.select_chip is 0x, so it
hangs at that point. Whereas future power-on resets have the location
cleared to 0, so it works fine...

Explicitly setting select_chip to NULL in the call to board_nand_init for
omap_gpmc makes everything work fine:

drivers/mtd/nand/raw/omap_gpmc.c: board_nand_init()
...
writel(gpmc_config, _cfg->config)

+nand->select_chip = NULL;
+
nand->IO_ADDR_R = (void __iomem *)_cfg->cs[cs].nand_dat;
...

But now I am worried about other things not being cleared out properly at
reset... The am335x SPL NAND driver is pretty old and presumably
well-tested code, so I was kinda surprised at this fix working. Would
anyone know if a configuration setting, compiler setting or similar
contributes to this? Or is it some artifact of the power-up state of the
board?

Is there a better way of 'clearing' the static nand_chip struct in
am335x_spl_bch.c, or is there really a missing setup of this function
pointer somewhere for am335x_spl_bch/omap_gpmc?

This is against TI's u-boot @ d77252021a85c72d7ff9a4e151b81c4b4b9e1205 ,
with a Variscite VAR-SOM-AM33 module. Just wanted to check with the list to
see if I am missing something...

Thanks,
Kevin

Re: [PATCH 07/10] stm32mp1: spl: Configure MAC address when booting OP-TEE

2021-08-31 Thread Alex G.


On 8/31/21 12:10 PM, Patrick DELAUNAY wrote:

Hi,


On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

When OP-TEE is booted as the SPL payload, the stage after OP-TEE is
not guaranteed to be u-boot. Thus the FDT patching in u-boot is not
guaranteed to occur. Add this step to SPL.

The patching by stm32_fdt_setup_mac_addr() is done in SPL, and patches
the target FDT directly. This differs is different from
setup_mac_address(), which sets the "ethaddr" env variable, and does
not work in SPL.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/cpu.c   | 22 +++
  .../arm/mach-stm32mp/include/mach/sys_proto.h |  3 +++
  arch/arm/mach-stm32mp/spl.c   |  1 +
  3 files changed, 26 insertions(+)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 8727de513c..2b8b67bb40 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -646,6 +647,27 @@ __weak int setup_mac_address(void)
  return 0;
  }
+int stm32_fdt_setup_mac_addr(void *fdt)
+{
+    int ret;
+    uchar enetaddr[ARP_HLEN];
+
+    ret = stm32_read_otp_mac(enetaddr);
+    if (ret < 0)
+    return ret;
+
+    if (!is_valid_ethaddr(enetaddr)) {
+    printf("invalid MAC address in OTP\n");
+    return -EINVAL;
+    }
+
+    ret = fdt_ethernet_set_macaddr(fdt, 0, enetaddr);
+    if (ret)
+    debug("Failed to set mac address from OTP: %d\n", ret);
+
+    return ret;
+}
+
  static int setup_serial_number(void)
  {
  char serial_string[25];
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h 
b/arch/arm/mach-stm32mp/include/mach/sys_proto.h

index 4149d3a133..2d24cfee3f 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -47,7 +47,10 @@ void get_soc_name(char name[SOC_NAME_SIZE]);
  /* return boot mode */
  u32 get_bootmode(void);
+/* Set 'ethaddr' env variable with MAC from OTP (useful for u-boot 
proper) */

  int setup_mac_address(void);
+/* Patch the first 'ethernet' node of FDT with MAC from OTP (useful 
for SPL) */

+int stm32_fdt_setup_mac_addr(void *fdt);
  /* board power management : configure vddcore according OPP */
  void board_vddcore_init(u32 voltage_mv);
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index 405eff68a3..d9fdc5926c 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -181,6 +181,7 @@ void stm32_init_tzc_for_optee(void)
  void spl_board_prepare_for_optee(void *fdt)
  {
+    stm32_fdt_setup_mac_addr(fdt);
  stm32_init_tzc_for_optee();
  }



I think that all this part is not required for falcon mode:

let the Linux driver fallback to nvmem access to read the MAC address in 
OTP when the DT is not updated by boot loader


remove also the patch 06/10 and 04/40

PS: it is already working in OpenSTLinux based on the device tree 
modification for your board


{
             ethernet_mac_address: mac@e4 {
         reg = <0xe4 0x6>;
};

 {
     nvmem-cells = <_mac_address>;
     nvmem-cell-names = "mac-address";
};


I was looking at this, following Sean's suggestion from last week. The 
linux BSEC driver backends on stm32_bsec_smc(). This requires a 
corresponding secure-world callout. which is not currently implemented 
for SPL. We'd just get "Can't read data57 (-5)" error from linux, and a 
random MAC address.


Is this change as proposed ideal? Probably not. It works with SPL and 
the current LTS linux (v5.10), and is likely the least intensive 
solution in terms of lines of code.


Alex


PS: this part is not yet upstreamed in Linux


That's not problematic. I can accommodate devicetree changes by using 
overlays in the FIT image. This flexibility is also a huge reason why 
I've chosen to go with FIT versus other image formats.

[PATCH 2/2] mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

Import HS400 support for iMX7ULP B0 from the Linux kernel:

2eaf5a533afd ("mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP")

According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
before any setting of STROBE_DLL_CTRL register.

USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
for slave sel value. If this register bits value is 0,  it needs
256 ref_clk cycles to update slave sel value. IC suggest to set
bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
sel value. This will short the lock time of slave.

i.MX7ULP B0 will need more time to lock the REF and SLV, so change
to add 5us delay.

Signed-off-by: Oleksandr Suvorov 
Series-notes
fsl_esdhc_imx improvements

Import individual settings for soc imx7ulp and add support of HS400 for
this soc.
END

---

 drivers/mmc/fsl_esdhc_imx.c | 11 ---
 include/fsl_esdhc_imx.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 6c8f77f9ee..569f099d9b 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -727,17 +727,21 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
 
if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
esdhc_write32(>strobe_dllctrl, 
ESDHC_STROBE_DLL_CTRL_RESET);
+   /* clear the reset bit on strobe dll before any setting */
+   esdhc_write32(>strobe_dllctrl, 0);
+
 
/*
 * enable strobe dll ctrl and adjust the delay target
 * for the uSDHC loopback read clock
 */
val = ESDHC_STROBE_DLL_CTRL_ENABLE |
+   ESDHC_STROBE_DLL_CTRL_SLV_UPDATE_INT_DEFAULT |
(priv->strobe_dll_delay_target <<
 ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT);
esdhc_write32(>strobe_dllctrl, val);
-   /* wait 1us to make sure strobe dll status register stable */
-   mdelay(1);
+   /* wait 5us to make sure strobe dll status register stable */
+   mdelay(5);
val = esdhc_read32(>strobe_dllstat);
if (!(val & ESDHC_STROBE_DLL_STS_REF_LOCK))
pr_warn("HS400 strobe DLL status REF not lock!\n");
@@ -1708,7 +1712,8 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
 
 static struct esdhc_soc_data usdhc_imx7ulp_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
-   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
+   | ESDHC_FLAG_HS400,
 };
 
 static struct esdhc_soc_data usdhc_imx8qm_data = {
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 45ed635a77..12e9163382 100644
--- a/include/fsl_esdhc_imx.h
+++ b/include/fsl_esdhc_imx.h
@@ -194,6 +194,7 @@
 #define ESDHC_STROBE_DLL_CTRL_RESETBIT(1)
 #define ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_DEFAULT   0x7
 #define ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT 3
+#define ESDHC_STROBE_DLL_CTRL_SLV_UPDATE_INT_DEFAULT   (4 << 20)
 
 #define ESDHC_STROBE_DLL_STATUS0x74
 #define ESDHC_STROBE_DLL_STS_REF_LOCK  BIT(1)
-- 
2.31.1

[PATCH 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp

From: Jorge Ramirez-Ortiz 

Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel.
Set supported by u-boot flags only.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Ricardo Salveti 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
---

 drivers/mmc/fsl_esdhc_imx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index aabf39535f..6c8f77f9ee 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1706,6 +1706,11 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
| ESDHC_FLAG_HS400,
 };
 
+static struct esdhc_soc_data usdhc_imx7ulp_data = {
+   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
+};
+
 static struct esdhc_soc_data usdhc_imx8qm_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING |
ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 |
@@ -1720,7 +1725,7 @@ static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,imx6sl-usdhc", },
{ .compatible = "fsl,imx6q-usdhc", },
{ .compatible = "fsl,imx7d-usdhc", .data = (ulong)_imx7d_data,},
-   { .compatible = "fsl,imx7ulp-usdhc", },
+   { .compatible = "fsl,imx7ulp-usdhc", .data = 
(ulong)_imx7ulp_data,},
{ .compatible = "fsl,imx8qm-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mm-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mn-usdhc", .data = (ulong)_imx8qm_data,},
-- 
2.31.1

Re: [RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

2021-08-31 Thread Marek Vasut


On 8/31/21 4:54 PM, Patrick DELAUNAY wrote:

Hi Alexandru,


Hi,


On 8/26/21 11:47 PM, Alexandru Gagniuc wrote:

Hi Patrick,

I proposing a better fix fir the issues I outlined earlier, I made a
classification of the currently supported boot modes.

    1) BL1 -> SPL -> U-Boot
    2) BL1 -> SPL -> OP-TEE
-
|  3) BL1 -> TF-A -> U-Boot |
|  4) BL1 -> TF-A -> OP-TEE |
| _ |
|| 5) BL1 -> TF-A -> FIP container ||
|| CONFIG_TFABOOT_FIP  ||
||_||
|   |
| CONFIG_TFABOOT    |
-

Here, I'm looking at FIP as a new boot mode. In order to avoid
breakage, any changes to support FIP it should naturally be done only
to this new path.

This proposal contains several changes, but I've squashed them into
one for ease of discussion.

This better matches the boot mode classification above.


1) is supported but with many constraint for security part and low power 
management


     it is not recommended for real product / it will be not supported 
by STMicroelectronics


Does this mean ST will be cutting off their own customers who use this 
boot mode because they do not need/want additional complex 
problematically licensed components in their boot chain and/or ST will 
be forcing those customers into adding such unneeded/unwanted components 
unconditionally ?


I am strongly opposed to that.

I would argue that the U-Boot crypto code went through multiple 
independent security reviews, personally I trust that more than code 
fully controlled and maintained by any one single company, so I am not 
buying the security constraint argument here.


Regarding power management and low power modes, there is literally 
nothing preventing Linux from implementing those low power modes, so 
there is no reason to hide all that code in firmware, so I am not buying 
the low power argument either.


Finally, the argument that the component that is being forced upon 
everyone is "open source" is really turning any design with such a SoC 
into a huge risk.


There have been SoCs where the vendor took "open source" bootloader 
code, compiled a blob, released a blob and never gave out the sources, 
because it is "open source" and not "free software", the BSD license 
permits such practice, GPL does not. Whoever wanted to design a board or 
SoM with such a SoC, had to adjust their design to match that one blob. 
Of course, that also implies that any security problems were not fixable 
in that blob.


[...]

Re: [PATCH 05/10] arm: stm32mp: bsec: Do not skip .probe() for SPL


Hi

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:


stm32mp_bsec_probe() was skipped for TFABOOT and SPL_BUILD. The idea
of skipping probe() is that we can't access BSEC from the normal
world. This is true with TFABOOT. However, in SPL, we are in the
secure world, so skipping probe is incorrect. In fact, SPL is not
even built when TFABOOT is selected.

Thus, only skip probe with TFABOOT, but not SPL_BUILD.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/bsec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index fe39bd80cf..a02d19c1b9 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -506,7 +506,7 @@ static int stm32mp_bsec_probe(struct udevice *dev)
 * only executed in U-Boot proper when TF-A is not used
 */
  
-	if (!IS_ENABLED(CONFIG_TFABOOT) && !IS_ENABLED(CONFIG_SPL_BUILD)) {

+   if (!IS_ENABLED(CONFIG_TFABOOT)) {
plat = dev_get_plat(dev);
  
  		for (otp = 57; otp <= BSEC_OTP_MAX_VALUE; otp++)



in this part the dirver don't skip the BSEC probe (still return 0)

BUT the BSEC driver skip only the shadow of the OTP

=> this initialisation is necessary only one time to save time

a/ for TF-A boot it is done in TF-A

b/ for basic boot (SPL + U-Boot) is only done in U-Boot proper (because 
is not mandatory in SPL


and the U-Boot execution was faster - before the data cache activation 
in SPL)



With this patch the copy of the OTP in shadow memory is done 2 times

1/ in SPL (BSEC probe) = with CONFIG_SPL_BUILD

2/ in U-Boot (BSEC probe)

see comment:

    /*
     * update unlocked shadow for OTP cleared by the rom code
     * only executed in U-Boot proper when TF-A is not used
     */


but for falcon mode, as the Linux driver expected the OTP are shadowed,

the operation need to be done in SPL and in U-Boot proper

I propose


    /*

     * update unlocked shadow for OTP cleared by the rom code

-     * only executed in U-Boot proper when TF-A is not used

+     * only executed in U-Boot SPL, it is done in TF-A when used

     */

-   if (!IS_ENABLED(CONFIG_TFABOOT) && !IS_ENABLED(CONFIG_SPL_BUILD)) {
+   if (IS_ENABLED(CONFIG_SPL_BUILD)) {


Regards

Patrick

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2021-08-31 Thread Heinrich Schuchardt





On 8/31/21 1:12 PM, Kristian Amlie wrote:

On 31/08/2021 12:46, Heinrich Schuchardt wrote:




*Von:* Ard Biesheuvel 
*Gesendet:* 31. August 2021 12:33:56 MESZ
*An:* Heinrich Schuchardt 
*CC:* Kristian Amlie 
*Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
returning memory map.

On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  wrote:


 On 8/27/21 9:55 AM, Kristian Amlie wrote:

 You can use scripts/get_maintainer.pl to find the right addressees for
 your patches.

 efi_reserve_memory() states that memory marked with "no-map"
 shall not
 be accessed by the UEFI payload. Make sure efi_get_memory_map()
 honors
 this.


Accessing memory and describing memory are two different things.
Describing reserved memory in the memory map is important, because it
helps us distinguish it from MMIO regions.


Ok, my mistake, I thought the kernel would deduce this separately
through the DTB.



 This helps the case when booting vexpress_ca9x4 under QEMU. Because
 the kernel wants to use an address in the lowest 128MiB of the
 range,
 but this range is reserved with "no-map", the kernel complains
 that it
 can not allocate the low memory it needs. In reality the actual
 usable
 memory starts much higher, which is reflected correctly in the
 memory
 map after this fix.



This is a u-boot patch right? (I cannot tell from the context, as
there are no mailing lists on cc)

It is u-boot's job to describe all the memory, no matter how it is
used. Even if the kernel itself may not use it as system memory, there
are cases where kernel infrastructure is used to map these regions:
for instance, the ACPI core may need to map a SystemMemory OpRegion,
and we need the EFI memory map to tell us whether to use memory or I/O
semantics.

As for the 128 MB issue: can you reproduce this with a recent kernel?
We made some changes recently to the EFI stub as well as the
decompressor code to prevent the decompressor code from relocating
itself to the base of DRAM, and to allow the decompressed kernel to
reside at any 2 MB aligned offset in memory.


This would allow putting the kernel at the very top of memory. But
consider this function that misbehaves:

arch/arm/include/asm/efi.h:

76 /* on ARM, the initrd should be loaded in a lowmem region */
77 static inline unsigned long efi_get_max_initrd_addr(unsigned long
image_addr)
78 {
79 return round_down(image_addr, SZ_4M) + SZ_512M;
80 }

0x1F00 = efi_get_max_initrd_addr(0xff00);

And below 0x1f00 there may be no RAM at all.

Best regards

Heinrich



I'll try this and get back to you!

--
Kristian




 The 'no-map' requirement needs to be fulfilled by the kernel.

 The GetMemoryMap() boot time service must comply to the UEFI
 specification.

 The Devicetree Specification has this clarification:

 "Reserved regions with the no-map property must be listed in the memory
 map with type EfiReservedMemoryType. All other reserved regions must be
 listed with type EfiBootServicesData."
 
https://devicetree-specification.readthedocs.io/en/latest/chapter3-devicenodes.html
 


 Should the kernel calculate its internal 128 MiB requirement incorrectly
 this needs be fixed in the kernel EFI stub. Does the problem exist with
 kernel 5.14?

 I wonder if the 128 MiB requirement of the kernel can be lifted for
 32bit ARM as we already did for RISC-V. Cf.


As mentioned above, this should already be fixed, in v5.11 or later

 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.14=c79e89ecaa246c880292ba68cbe08c9c30db77e3
 


 Cc Ard, maintainer of the kernel EFI stub.

 Best regards

 Heinrich


 Signed-off-by: Kristian Amlie 
 

 lib/efi_loader/efi_memory.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

 diff --git a/lib/efi_loader/efi_memory.c
 b/lib/efi_loader/efi_memory.c
 index f4acbee4f9..7f8543143a 100644
 --- a/lib/efi_loader/efi_memory.c
 +++ b/lib/efi_loader/efi_memory.c
 @@ -646,8 +646,16 @@ efi_status_t efi_get_memory_map(efi_uintn_t
 *memory_map_size,

 provided_map_size = *memory_map_size;

 - list_for_each(lhandle, _mem)
 + list_for_each(lhandle, _mem) {
 + struct efi_mem_list *lmem;
 +
 + lmem = list_entry(lhandle, struct efi_mem_list, link);
 +
 + if (lmem->desc.type == EFI_RESERVED_MEMORY_TYPE)

Re: [PATCH 10/10] stm32mp1: spl: Copy optee nodes to target FDT for OP-TEE payloads


Hi,

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

OP-TEE does not take a devicetree for its own use. However, it does
pass the devicetree to the normal world OS. In most cases that will
be some other devicetree-bearing platform, such as linux.

As in other cases where there's an OPTEE payload (e.g. BOOTM_OPTEE),
it is required to copy the optee nodes to he target's FDT. Do this as
part of spl_board_prepare_for_optee().

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/spl.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index d9fdc5926c..94fbb45cf9 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  
  u32 spl_boot_device(void)

  {
@@ -182,6 +183,7 @@ void stm32_init_tzc_for_optee(void)
  void spl_board_prepare_for_optee(void *fdt)
  {
stm32_fdt_setup_mac_addr(fdt);
+   optee_copy_fdt_nodes(fdt);
stm32_init_tzc_for_optee();
  }
  



NAK the OP-TEE nodes are ADDED by the OP-TEE firmware in the unsecure 
device tree (when CFG_DT is activated)


before to jump to the kernel (that remove the need to have DT 
allignement with U-Boot SPL device tree)


=> SPL should not copy the OP-TEE nodes in next stage DT

reference in optee_os = core/arch/arm/kernel/boot.c: add_optee_dt_node()

add_optee_dt_node() <= update_external_dt() <= paged_init_primary()

It is the expected configuration for OP-TEE on STM32MP15 platform.

regards


Patrick

Re: [PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi

On Tue, Aug 31, 2021 at 05:40:25PM +0200, Michael Walle wrote:
> The offical ls1028a binding of the driver uses the following as

Same typo as before.

> compatibles:
>   compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
> 
> Add the missing compatible to the driver and update the device tree.
> 
> Signed-off-by: Michael Walle 
> ---
> diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
> index 8fe3508c64..23d812f476 100644
> --- a/drivers/spi/fsl_dspi.c
> +++ b/drivers/spi/fsl_dspi.c
> @@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
>  
>  static const struct udevice_id fsl_dspi_ids[] = {
>   { .compatible = "fsl,vf610-dspi" },
> + { .compatible = "fsl,ls1021a-v1.0-dspi" },

Okay, so you say it is pointless to add the "fsl,ls1028a-dspi"
compatible string as well, since the U-Boot driver will match on the
fallback compatible, and that is absolutely sufficient, since U-Boot
will never implement any of the LS1028A specifics (DMA) anyway.
I'm fine with that.

Reviewed-by: Vladimir Oltean 

>   { }
>  };
>  
> -- 
> 2.30.2
>

[PATCH 9/9] arm: dts: sl28: sync dtbs

Copy the board device tree files from linux v5.14. On top of the v5.14
dtbs the changes of these two patches are included here which are needed
for u-boot:
  
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-7-mich...@walle.cc/
  
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-8-mich...@walle.cc/

At the time of this writing the patches are still pending but already
have Reviewed-by tags.

Signed-off-by: Michael Walle 
---
 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  |  12 +-
 .../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts |  31 +--
 .../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi |   8 +
 .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts |  40 +--
 .../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts |  16 +-
 arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 250 +++---
 6 files changed, 265 insertions(+), 92 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 42bd3138b2..f80c699a3c 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -4,12 +4,9 @@
 
 / {
aliases {
-   mmc0 = 
-   mmc1 = 
i2c0 = 
i2c1 = 
i2c2 = 
-   rtc0 = 
ethernet2 = _port2;
ethernet3 = _port3;
};
@@ -234,11 +231,6 @@
 };
 #endif
 
- {
-   rtc: rtc@32 {
-   };
-};
-
  {
u-boot,dm-pre-reloc;
flash@0 {
@@ -266,6 +258,10 @@
u-boot,dm-pre-reloc;
 };
 
+ {
+   status = "okay";
+};
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index ba2e4de96d..7cd29ab970 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -8,7 +8,7 @@
  * None of the  four SerDes lanes are used by the module, instead they are
  * all led out to the carrier for customer use.
  *
- * Copyright (C) 2020 Michael Walle 
+ * Copyright (C) 2021 Michael Walle 
  *
  */
 
@@ -21,28 +21,17 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
 };
 
-_port0 {
-   status = "disabled";
-   /delete-property/ phy-handle;
-};
-
-_port1 {
-   phy-handle = <>;
-   phy-mode = "rgmii-id";
-   status = "okay";
-};
-
-/delete-node/ 
 _mdio_pf3 {
+   /* Delete unused phy node */
+   /delete-node/ ethernet-phy@5;
+
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
eee-broken-100tx;
-
qca,clk-out-frequency = <12500>;
qca,clk-out-strength = ;
qca,keep-pll-enabled;
-
vddio-supply = <>;
 
vddio: vddio-regulator {
@@ -56,3 +45,15 @@
};
};
 };
+
+_port0 {
+   status = "disabled";
+   /* Delete the phy-handle to the old phy0 label */
+   /delete-property/ phy-handle;
+};
+
+_port1 {
+   phy-handle = <>;
+   phy-mode = "rgmii-id";
+   status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
index 4e0ce3f77d..c010ea0dc7 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
@@ -7,3 +7,11 @@
ethernet1 = _felix_port1;
};
 };
+
+_felix_port0 {
+   label = "gbe0";
+};
+
+_felix_port1 {
+   label = "gbe1";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index db80874f4e..330e34f933 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -2,10 +2,10 @@
 /*
  * Device Tree file for the Kontron SMARC-sAL28 board.
  *
- * This is for the network variant 2 which has no ethernet support in the
- * bootloader.
+ * This is for the network variant 2 which has two ethernet ports. These
+ * ports are connected to the internal switch.
  *
- * Copyright (C) 2020 Michael Walle 
+ * Copyright (C) 2021 Michael Walle 
  *
  */
 
@@ -17,8 +17,21 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
 };
 
+_mdio_pf3 {
+   phy1: ethernet-phy@4 {
+   reg = <0x4>;
+   eee-broken-1000t;
+   eee-broken-100tx;
+   };
+};
+
 _port0 {
status = "disabled";
+   /*
+* In the base device tree the PHY at address 5 was assigned for
+* this port. On this module this PHY is connected to a switch
+* port instead. Therefore, delete the phy-handle property here.
+*/
/delete-property/ phy-handle;
 };
 
@@ -31,14 +44,16 @@
 };
 
 _felix_port0 {
-   label = "gbe0";
+   label = "swp0";
+   managed = "in-band-status";
phy-handle = <>;
phy-mode =

[PATCH 2/9] arm: dts: ls1028a: move devices into /soc

Move all the CCSR related device nodes into /soc similiar to the linux
device tree.

Signed-off-by: Michael Walle 
---
 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  |   4 +
 .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds--sch-30841.dtsi   |   8 +-
 .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi  |   4 +-
 .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |   2 +-
 .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi  |   8 +-
 .../dts/fsl-ls1028a-qds--sch-24801.dtsi   |   8 +-
 .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi  |   8 +-
 .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi  |   8 +-
 .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi   |   2 +-
 arch/arm/dts/fsl-ls1028a-qds.dtsi |   4 +
 arch/arm/dts/fsl-ls1028a-rdb.dts  |   4 +
 arch/arm/dts/fsl-ls1028a.dtsi | 767 +-
 15 files changed, 426 insertions(+), 407 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index b3861ed98c..fa4c05212a 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -266,6 +266,10 @@
u-boot,dm-pre-reloc;
 };
 
+ {
+   u-boot,dm-pre-reloc;
+};
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index 23816da8ee..181fd2ddcb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -16,5 +16,5 @@
  {
status = "okay";
phy-mode = "usxgmii";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
index c6558ae2e0..67b68f1b3d 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
@@ -15,5 +15,5 @@
  {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index 5a0f060c16..433731df0e 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -31,25 +31,25 @@
 _felix_port0 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
 };
 
 _felix_port1 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
 };
 
 _felix_port2 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
 };
 
 _felix_port3 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
 };
 
 _felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index 39a83e10c4..cb74c8b371 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -20,13 +20,13 @@
 _felix_port0 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
 };
 
 _felix_port3 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
 };
 
 _felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 7d4702e4ff..979c0ddd48 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -15,5 +15,5 @@
  {
status = "okay";
phy-mode = "sgmii";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
+   phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi

[PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi

The offical ls1028a binding of the driver uses the following as
compatibles:
  compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";

Add the missing compatible to the driver and update the device tree.

Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 6 +++---
 drivers/spi/fsl_dspi.c| 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 09d748c4d0..4186df17e1 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -381,7 +381,7 @@
};
 
dspi0: dspi@210 {
-   compatible = "fsl,vf610-dspi";
+   compatible = "fsl,ls1028a-dspi", 
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
@@ -394,7 +394,7 @@
};
 
dspi1: dspi@211 {
-   compatible = "fsl,vf610-dspi";
+   compatible = "fsl,ls1028a-dspi", 
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x211 0x0 0x1>;
@@ -407,7 +407,7 @@
};
 
dspi2: dspi@212 {
-   compatible = "fsl,vf610-dspi";
+   compatible = "fsl,ls1028a-dspi", 
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x212 0x0 0x1>;
diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
index 8fe3508c64..23d812f476 100644
--- a/drivers/spi/fsl_dspi.c
+++ b/drivers/spi/fsl_dspi.c
@@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
 
 static const struct udevice_id fsl_dspi_ids[] = {
{ .compatible = "fsl,vf610-dspi" },
+   { .compatible = "fsl,ls1021a-v1.0-dspi" },
{ }
 };
 
-- 
2.30.2

[PATCH 3/9] arm: dts: ls1028a: remove /memory node

This node is some hodgepodge between the ddr controller node at SoC
offset 0x108 and some static memory size of 2GiB. Remove this bogus
node because it doesn't seem to be used at all.

Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index b3b497218f..8559562803 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -21,12 +21,6 @@
clock-output-names = "sysclk";
};
 
-   memory@0108 {
-   device_type = "memory";
-   reg = <0x 0x0108 0 0x8000>;
- /* DRAM space - 1, size : 2 GB DRAM */
-   };
-
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
-- 
2.30.2

[PATCH 4/9] arm: dts: ls1028a: update the labels

Update the labels of the nodes to match the kernel ones.

Signed-off-by: Michael Walle 
---
 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  | 10 +++
 .../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi |  2 +-
 .../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts |  6 ++---
 .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts |  8 +++---
 .../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi |  2 +-
 .../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi |  4 +--
 .../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts |  4 +--
 arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 22 
 .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |  2 +-
 arch/arm/dts/fsl-ls1028a-qds-duart.dts|  2 +-
 .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi  |  4 +--
 arch/arm/dts/fsl-ls1028a-qds.dtsi | 16 ++--
 arch/arm/dts/fsl-ls1028a-rdb.dts  | 22 
 arch/arm/dts/fsl-ls1028a.dtsi | 26 +--
 14 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index fa4c05212a..42bd3138b2 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -5,13 +5,13 @@
 / {
aliases {
mmc0 = 
-   mmc1 = 
+   mmc1 = 
i2c0 = 
i2c1 = 
i2c2 = 
rtc0 = 
-   ethernet2 = 
-   ethernet3 = 
+   ethernet2 = _port2;
+   ethernet3 = _port3;
};
 
binman: binman {
@@ -250,7 +250,7 @@
u-boot,dm-pre-reloc;
 };
 
- {
+ {
u-boot,dm-pre-reloc;
 };
 
@@ -262,7 +262,7 @@
u-boot,dm-pre-reloc;
 };
 
- {
+ {
u-boot,dm-pre-reloc;
 };
 
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
index 98e8939369..a46e07dc6b 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
@@ -3,6 +3,6 @@
 
 / {
aliases {
-   ethernet0 = 
+   ethernet0 = _port1;
};
 };
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index 33d85ed83a..ba2e4de96d 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -21,19 +21,19 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
 };
 
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
 };
 
- {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
status = "okay";
 };
 
 /delete-node/ 
- {
+_mdio_pf3 {
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 7a3aa21408..db80874f4e 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -17,12 +17,12 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
 };
 
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -45,12 +45,12 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
 
 /delete-node/ 
- {
+_mdio_pf3 {
phy0: ethernet-phy@5 {
reg = <0x5>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
index 879a76415b..3d6bf5a0bd 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
@@ -3,6 +3,6 @@
 
 / {
aliases {
-   ethernet0 = 
+   ethernet0 = _port0;
};
 };
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
index fce4694682..5d82973bba 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
@@ -3,7 +3,7 @@
 
 / {
aliases {
-   ethernet0 = 
-   ethernet1 = 
+   ethernet0 = _port0;
+   ethernet1 = _port1;
};
 };
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4.dts 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4.dts
index b95e082b70..54d12ab992 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4.dts
@@ -18,13 +18,13 @@
compatible = "kontron,sl28-var4", "kontron,sl28", "fsl,ls1028a";
 };
 
- {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
status = "okay";
 };
 
- {
+_mdio_pf3 {
phy1:

[PATCH 7/9] serial: lpuart: add new compatible fsl,ls1028a-lpuart

The offical ls1028a binding of the driver uses the following as
compatibles:
  compatible = "fsl,ls1028a-lpuart";

Add the missing compatible to the driver and update the device tree.

Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi  | 12 ++--
 drivers/serial/serial_lpuart.c |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 4186df17e1..69850fe7f2 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -305,7 +305,7 @@
};
 
lpuart0: serial@226 {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x226 0x0 0x1000>;
interrupts = <0 232 0x4>;
clocks = <>;
@@ -315,7 +315,7 @@
};
 
lpuart1: serial@227 {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x227 0x0 0x1000>;
interrupts = <0 233 0x4>;
clocks = <>;
@@ -325,7 +325,7 @@
};
 
lpuart2: serial@228 {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x228 0x0 0x1000>;
interrupts = <0 234 0x4>;
clocks = <>;
@@ -335,7 +335,7 @@
};
 
lpuart3: serial@229 {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x229 0x0 0x1000>;
interrupts = <0 235 0x4>;
clocks = <>;
@@ -345,7 +345,7 @@
};
 
lpuart4: serial@22a {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22a 0x0 0x1000>;
interrupts = <0 236 0x4>;
clocks = <>;
@@ -355,7 +355,7 @@
};
 
lpuart5: serial@22b {
-   compatible = "fsl,ls1021a-lpuart";
+   compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22b 0x0 0x1000>;
interrupts = <0 237 0x4>;
clocks = <>;
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index 2b473d70f6..3c9a69598a 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -553,6 +553,8 @@ static const struct dm_serial_ops lpuart_serial_ops = {
 static const struct udevice_id lpuart_serial_ids[] = {
{ .compatible = "fsl,ls1021a-lpuart", .data =
LPUART_FLAG_REGMAP_32BIT_REG | LPUART_FLAG_REGMAP_ENDIAN_BIG },
+   { .compatible = "fsl,ls1028a-lpuart",
+   .data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,imx7ulp-lpuart",
.data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,vf610-lpuart"},
-- 
2.30.2

Re: [PATCH 08/10] lib: Makefile: Make optee library available in SPL


Hi

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

We want the optee_copy_fdt_nodes symbols in SPL. This is for cases
when booting an OPTEE payload directly.

Signed-off-by: Alexandru Gagniuc 
---
  lib/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Makefile b/lib/Makefile
index 8ba745faa0..73dacbb01b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_FIT) += libfdt/
  obj-$(CONFIG_OF_LIVE) += of_live.o
  obj-$(CONFIG_CMD_DHRYSTONE) += dhry/
  obj-$(CONFIG_ARCH_AT91) += at91/
-obj-$(CONFIG_OPTEE) += optee/
  obj-$(CONFIG_ASN1_DECODER) += asn1_decoder.o
  obj-y += crypto/
  
@@ -74,6 +73,7 @@ obj-$(CONFIG_$(SPL_)GZIP) += gunzip.o

  obj-$(CONFIG_$(SPL_)LZO) += lzo/
  obj-$(CONFIG_$(SPL_)LZMA) += lzma/
  obj-$(CONFIG_$(SPL_)LZ4) += lz4_wrapper.o
+obj-$(CONFIG_OPTEE) += optee/
  
  obj-$(CONFIG_$(SPL_)LIB_RATIONAL) += rational.o
  


I will propose in other thread to have a specific CONFIG to compile the the 
OP-TEE library

CONFIG_OPTEE => CONFIG_OPTEE_LIB

CONFIG_OPTEE will be kept only to manage the OP-TEE driver compilation
(depending TEE uclass / CONFIG_TEE)

but if you need to have the LIBRARY available in SPL
(to avoid to increase the SPL size of other board)

I think the configuraiton CONFIG_SPL_OPTEE_LIB should be added
then the Makefile becomes
 
+obj-$(CONFIG_$(SPL_)OPTEE) += optee/


Patrick

Re: [PATCH 09/10] ARM: dts: stm32mp: Add OP-TEE "/firmware" node to SPL dtb


Hi,

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

This node is required in SPL when booting an OP-TEE payload. Add it to
the SPL devicetree.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 0101962ea5..2e65b9b4d5 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -31,6 +31,7 @@
optee {
compatible = "linaro,optee-tz";
method = "smc";
+   u-boot,dm-spl;
};
};
  



NAK = the OP-TEE nodes are ADDED by the OP-TEE firmware

when SPL is running the OP-TEE firmware is not running and the OP-TEE 
driver is not probed


=> this nodes are not required

This node should be present ONLY for backyard compatibility (STM32IMAGE 
support in U-Boot trusted boot)



regards


Patrick

Re: [PATCH 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp

2021-08-31 Thread Fabio Estevam

On Tue, Aug 31, 2021 at 1:42 PM Oleksandr Suvorov
 wrote:
>
> From: Jorge Ramirez-Ortiz 
>
> Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel.
> Set supported by u-boot flags only.
>
> Signed-off-by: Jorge Ramirez-Ortiz 
> Signed-off-by: Ricardo Salveti 
> Co-developed-by: Oleksandr Suvorov 
> Signed-off-by: Oleksandr Suvorov 

Reviewed-by: Fabio Estevam

Re: [PATCH 2/2] mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

2021-08-31 Thread Fabio Estevam

Hi Oleksandr,

On Tue, Aug 31, 2021 at 1:42 PM Oleksandr Suvorov
 wrote:
>
> Import HS400 support for iMX7ULP B0 from the Linux kernel:
>
> 2eaf5a533afd ("mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP")
>
> According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
> before any setting of STROBE_DLL_CTRL register.
>
> USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
> for slave sel value. If this register bits value is 0,  it needs
> 256 ref_clk cycles to update slave sel value. IC suggest to set
> bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
> sel value. This will short the lock time of slave.
>
> i.MX7ULP B0 will need more time to lock the REF and SLV, so change
> to add 5us delay.
>
> Signed-off-by: Oleksandr Suvorov 
> Series-notes
> fsl_esdhc_imx improvements
>
> Import individual settings for soc imx7ulp and add support of HS400 for
> this soc.
> END

The text below the Signed-off-by should be removed.

Other than that, the patch looks good:

Reviewed-by: Fabio Estevam

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

On Tue, Aug 31, 2021 at 05:40:19PM +0200, Michael Walle wrote:
> This series sync the device tree of the LS1028A SoC with the linux one.
> To ease future debugging and reviewing, we first clean up the existing one,
> removing bogus nodes, moving all CCSR related nodes in /soc and update the
> drivers to accept the offical compatible strings.
>
> This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the
> LS1028A-RDB and -QDS. It would be nice if someone could actually test it on
> such a board.
>
> I didn't sync the device trees for the NXP boards because u-boot related
> things aren't split into its own -u-boot.dtsi file. So I'll leave that task
> to NXP :)

No apparent regression apart from a failure to build.

LS1028A-RDB:

Before:
=> dm tree
 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver   root_driver
 irq   0  [   ]   gic-v3|-- interrupt-controller@600
 spi   0  [   ]   nxp_fspi  |-- flexspi@20c
 spi_flash 0  [   ]   jedec_spi_nor |   `-- flash@0
 pci   0  [ + ]   pci_layerscape|-- pcie@340
 pci   3  [ + ]   pci_bridge_drv|   `-- pci_0:0.0
 pci   1  [ + ]   pci_layerscape|-- pcie@350
 pci   4  [ + ]   pci_bridge_drv|   `-- pci_2:0.0
 pci   2  [ + ]   pci_generic_ecam  |-- pcie@1f000
 ethernet  0  [ + ]   enetc_eth |   |-- enetc-0
 ethernet  1  [ + ]   enetc_eth |   |-- enetc-2
 mdio  0  [ + ]   enetc_mdio|   |-- emdio-3
 pci_generi0  [   ]   pci_generic_drv   |   |-- pci_4:0.4
 dsa   0  [ + ]   felix-switch  |   |-- felix-switch
 ethernet  2  [ + ]   dsa-port  |   |   |-- swp0
 ethernet  3  [ + ]   dsa-port  |   |   |-- swp1
 ethernet  4  [ + ]   dsa-port  |   |   |-- swp2
 ethernet  5  [ + ]   dsa-port  |   |   `-- swp3
 pci_generi1  [   ]   pci_generic_drv   |   `-- pci_4:1f.0
 i2c   0  [ + ]   i2c_mxc   |-- i2c@200
 i2c_mux   0  [ + ]   pca954x   |   |-- i2c-mux@77
 i2c   1  [   ]   i2c_mux_bus_drv   |   |   `-- 
i2c@200->i2c-mux@77->i2c@3
 rtc   0  [   ]   rtc-pcf2127   |   |   `-- rtc@51
 i2c_generi0  [ + ]   i2c_generic_chip_drv  |   |-- generic_66
 i2c_generi1  [ + ]   i2c_generic_chip_drv  |   `-- generic_57
 i2c   2  [   ]   i2c_mxc   |-- i2c@201
 i2c   3  [   ]   i2c_mxc   |-- i2c@202
 i2c   4  [   ]   i2c_mxc   |-- i2c@203
 i2c   5  [   ]   i2c_mxc   |-- i2c@204
 i2c   6  [   ]   i2c_mxc   |-- i2c@205
 i2c   7  [   ]   i2c_mxc   |-- i2c@206
 i2c   8  [   ]   i2c_mxc   |-- i2c@207
 usb   0  [   ]   xhci_fsl  |-- usb3@310
 usb   1  [   ]   xhci_fsl  |-- usb3@311
 spi   1  [   ]   fsl_dspi  |-- dspi@210
 spi   2  [   ]   fsl_dspi  |-- dspi@211
 spi   3  [   ]   fsl_dspi  |-- dspi@212
 mmc   0  [ + ]   fsl-esdhc-mmc |-- esdhc@214
 blk   0  [ + ]   mmc_blk   |   `-- es...@214.blk
 mmc   1  [ + ]   fsl-esdhc-mmc |-- esdhc@215
 blk   1  [   ]   mmc_blk   |   `-- es...@215.blk
 gpio  0  [   ]   gpio_mpc8xxx  |-- gpio@230
 gpio  1  [   ]   gpio_mpc8xxx  |-- gpio@231
 gpio  2  [   ]   gpio_mpc8xxx  |-- gpio@232
 ahci  0  [   ]   ceva_sata |-- sata@320
 scsi  0  [   ]   ahci_scsi |   `-- ahci_scsi
 watchdog  0  [ + ]   sp805_wdt `-- wdt@c00

After:
=> dm tree
 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver   root_driver
 irq   0  [   ]   gic-v3|-- interrupt-controller@600
 simple_bus0  [ + ]   simple_bus`-- soc
 syscon0  [   ]   syscon|-- syscon@1e0
 syscon1  [   ]   syscon|-- syscon@1e6
 syscon2  [   ]   syscon|-- syscon@1fc
 i2c   0  [ + ]   i2c_mxc   |-- i2c@200
 i2c_mux   0  [ + ]   pca954x   |   |-- i2c-mux@77
 i2c   1  [   ]   i2c_mux_bus_drv   |   |   `-- 
i2c@200->i2c-mux@77->i2c@3
 rtc   0  [   ]   rtc-pcf2127   |   |   `-- rtc@51
 i2c_generi0  [ + ]   i2c_generic_chip_drv  |   |-- generic_66
 i2c_generi1  [ + ]   i2c_generic_chip_drv  |   `--

Re: [PATCH 2/2] tools: k3_fit_atf: Change DM load address to avoid conflict

On 13:20-20210831, Nishanth Menon wrote:
> DM binary is expected to be an elf file. The expected address of
> this elf is in the range of 0xa000_ in DDR. In the current
> configuration, elf file is loaded to the exact same address and we
> invoke load_elf_image_phdr to decode and memcpy sections of the elf to
> the same address range, we are eventually going to overwrite sections
> of the original elf image itself corrupting the DM firmware as a
> result.
> 
> To prevent this, we must load the DM section to an address that does'nt
> overlap with the actual section address where it will eventually be
> copied to.
> 
> Lets add an offset of 256MB to a lesser used DDR address, yet within
> the typical 1GB address space.
> 
> We may need to consider going for a configuration option if this is
> turning to be a limitation (boards with lesser DDR space).
> 
> Signed-off-by: Nishanth Menon 
> ---
>  tools/k3_fit_atf.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
> index 3a476ced98b1..6469f188e8ff 100755
> --- a/tools/k3_fit_atf.sh
> +++ b/tools/k3_fit_atf.sh
> @@ -67,8 +67,8 @@ cat << __HEADER_EOF
>   arch = "arm32";
>   compression = "none";
>   os = "DM";
> - load = <0xa000>;
> - entry = <0xa000>;
> + load = <0xb000>;
> + entry = <0xb000>;
>   };
>   spl {
>   description = "SPL (64-bit)";
> -- 
> 2.32.0
> 


Sigh.. I see Suman also discovered the exact same error in [1] - I think
I prefer Suman's choice of address to mine.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210814064901.3840-1-s-a...@ti.com/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

[PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

This series sync the device tree of the LS1028A SoC with the linux one.
To ease future debugging and reviewing, we first clean up the existing one,
removing bogus nodes, moving all CCSR related nodes in /soc and update the
drivers to accept the offical compatible strings.

This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the
LS1028A-RDB and -QDS. It would be nice if someone could actually test it on
such a board.

I didn't sync the device trees for the NXP boards because u-boot related
things aren't split into its own -u-boot.dtsi file. So I'll leave that task
to NXP :)

The following patch is a prerequisite for this series:
  
https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/

Michael Walle (9):
  armv8: ls1028a: add IOMMU stream ID to vivante node
  arm: dts: ls1028a: move devices into /soc
  arm: dts: ls1028a: remove /memory node
  arm: dts: ls1028a: update the labels
  watchdog: sp805_wdt: use correct compatible string
  spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi
  serial: lpuart: add new compatible fsl,ls1028a-lpuart
  arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
  arm: dts: sl28: sync dtbs

 .../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c |1 +
 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  |   24 +-
 .../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi |2 +-
 .../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts |   31 +-
 .../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi |8 +
 .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts |   46 +-
 .../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi |2 +-
 .../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi |4 +-
 .../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts |   18 +-
 arch/arm/dts/fsl-ls1028a-kontron-sl28.dts |  256 ++-
 .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi   |2 +-
 .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi   |2 +-
 .../dts/fsl-ls1028a-qds--sch-30841.dtsi   |8 +-
 .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi  |4 +-
 .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |4 +-
 .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi  |8 +-
 .../dts/fsl-ls1028a-qds--sch-24801.dtsi   |8 +-
 arch/arm/dts/fsl-ls1028a-qds-duart.dts|2 +-
 .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi  |8 +-
 .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi  |   12 +-
 .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi   |2 +-
 .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi   |2 +-
 arch/arm/dts/fsl-ls1028a-qds.dtsi |   20 +-
 arch/arm/dts/fsl-ls1028a-rdb.dts  |   26 +-
 arch/arm/dts/fsl-ls1028a.dtsi | 1443 -
 arch/arm/dts/hi3660.dtsi  |4 +-
 drivers/serial/serial_lpuart.c|2 +
 drivers/spi/fsl_dspi.c|1 +
 drivers/watchdog/sp805_wdt.c  |2 +-
 .../dt-bindings/clock/fsl,qoriq-clockgen.h|   15 +
 30 files changed, 1423 insertions(+), 544 deletions(-)
 create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h

-- 
2.30.2

[PATCH 5/9] watchdog: sp805_wdt: use correct compatible string

According to the linux device tree specification the compatible string
is:
  compatible = "arm,sp805", "arm,primecell";

Fix all users in u-boot.

Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
 arch/arm/dts/hi3660.dtsi  | 4 ++--
 drivers/watchdog/sp805_wdt.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index beee59e95c..09d748c4d0 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -481,7 +481,7 @@
};
 
cluster1_core0_watchdog: wdt@c00 {
-   compatible = "arm,sp805-wdt";
+   compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc00 0x0 0x1000>;
};
};
diff --git a/arch/arm/dts/hi3660.dtsi b/arch/arm/dts/hi3660.dtsi
index 65a45b0e80..028f4db60d 100644
--- a/arch/arm/dts/hi3660.dtsi
+++ b/arch/arm/dts/hi3660.dtsi
@@ -1087,7 +1087,7 @@
};
 
watchdog0: watchdog@e8a06000 {
-   compatible = "arm,sp805-wdt", "arm,primecell";
+   compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a06000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
@@ -1095,7 +1095,7 @@
};
 
watchdog1: watchdog@e8a07000 {
-   compatible = "arm,sp805-wdt", "arm,primecell";
+   compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a07000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index bec8827ceb..0d6fb12065 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -134,7 +134,7 @@ static const struct wdt_ops sp805_wdt_ops = {
 };
 
 static const struct udevice_id sp805_wdt_ids[] = {
-   { .compatible = "arm,sp805-wdt" },
+   { .compatible = "arm,sp805" },
{}
 };
 
-- 
2.30.2

[PATCH 1/9] armv8: ls1028a: add IOMMU stream ID to vivante node

The fixup is done for the "fsl,ls1028a-gpu" which isn't any official
device tree binding. Don't break it, but instead add a fixup for another
compatible "vivante,gc" which is the offical one for the GPU on the
LS1028A.

Signed-off-by: Michael Walle 
---
 arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index 49df8b3790..d93a793f39 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -18,6 +18,7 @@ struct icid_id_table icid_tbl[] = {
SET_SATA_ICID(1, "fsl,ls1028a-ahci", FSL_SATA1_STREAM_ID),
SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
SET_QDMA_ICID("fsl,ls1028a-qdma", FSL_DMA_STREAM_ID),
+   SET_GPU_ICID("vivante,gc", FSL_GPU_STREAM_ID),
SET_GPU_ICID("fsl,ls1028a-gpu", FSL_GPU_STREAM_ID),
SET_DISPLAY_ICID(FSL_DISPLAY_STREAM_ID),
 #ifdef CONFIG_FSL_CAAM
-- 
2.30.2

Re: [PATCH 03/10] board: stm32mp1: Implement board_fit_config_name_match() for SPL


Hi

Add in CC the MAINTAINERS.

On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:

This function is needed when loading a FIT image from SPL. It selects
the correct configuration node for the current board. Implement it.

Signed-off-by: Alexandru Gagniuc 
---
  board/st/stm32mp1/spl.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/board/st/stm32mp1/spl.c b/board/st/stm32mp1/spl.c
index bb210d7727..543c037ad8 100644
--- a/board/st/stm32mp1/spl.c
+++ b/board/st/stm32mp1/spl.c
@@ -5,6 +5,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -92,3 +93,12 @@ void board_debug_uart_init(void)
  #endif
  }
  #endif
+
+int board_fit_config_name_match(const char *name)
+{
+   if (of_machine_is_compatible("st,stm32mp157c-dk2"))
+   return !strstr(name, "stm32mp157c-dk2");
+
+   /* Okay, it's most likely an EV board */
+   return !strstr(name, "stm32mp157") + !strstr(name, "-ev");
+}


It is not working for all STMicroelectronics boards

=> st,stm32mp157a-dk1 for example

based on board_late_init => I propose board_name extraction from compatible :

#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
const void *fdt_compat;
int fdt_compat_len;

fdt_compat = fdt_getprop(gd->fdt_blob, 0, "compatible", 
_compat_len);

/* only STMicrolectronics board are supported */
if (strncmp(fdt_compat, "st,", 3) != 0)
return 1;

return !strstr(name, fdt_compat + 3);
}
#endif

Re: [PATCH 4/9] arm: dts: ls1028a: update the labels

On Tue, Aug 31, 2021 at 05:40:23PM +0200, Michael Walle wrote:
> Update the labels of the nodes to match the kernel ones.
> 
> Signed-off-by: Michael Walle 
> ---

-[ cut here ]-
>From 6583bc615f3e6f49d90fabb2033a49e9eab804dc Mon Sep 17 00:00:00 2001
From: Vladimir Oltean 
Date: Tue, 31 Aug 2021 20:55:37 +0300
Subject: [PATCH] fixup! arm: dts: ls1028a: update the labels

Signed-off-by: Vladimir Oltean 
---
 arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi  | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi  | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi  | 4 ++--
 arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi  | 4 ++--
 9 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index 181fd2ddcb3f..68e048966f13 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -13,7 +13,7 @@
#include "fsl-sch-30842.dtsi"
 };
 
- {
+_port0 {
status = "okay";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
index 67b68f1b3dbe..297ffa8878dc 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
@@ -12,7 +12,7 @@
#include "fsl-sch-30842.dtsi"
 };
 
- {
+_port0 {
status = "okay";
phy-mode = "sgmii-2500";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index 433731df0eb0..4b935412cdd2 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -20,7 +20,7 @@
 #include "fsl-sch-30841.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -53,6 +53,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index cb74c8b37160..2c0012bcb441 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -9,7 +9,7 @@
 #include "fsl-sch-30841.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -30,6 +30,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index f74c1433af06..ce35f3567af7 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
@@ -34,7 +34,7 @@
#include "fsl-sch-24801.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -67,6 +67,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
index 4edc428b2749..cd8c9a34a0fe 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
@@ -19,7 +19,7 @@
#include "fsl-sch-24801.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -52,6 +52,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
index 7fefb4c99fe3..6d089a401cdf 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
@@ -19,7 +19,7 @@
 #include "fsl-sch-30841.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -52,6 +52,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
index 1834418ae234..23e2a298bb67 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
@@ -9,7 +9,7 @@
 #include "fsl-sch-30842.dtsi"
 };
 
- {
+_port2 {
status = "okay";
 };
 
@@ -24,6 +24,6 @@
 };
 
 _felix_port4 {
-   ethernet = <>;
+   ethernet = <_port2>;
status =

Re: [PATCH 3/9] arm: dts: ls1028a: remove /memory node

On Tue, Aug 31, 2021 at 05:40:22PM +0200, Michael Walle wrote:
> This node is some hodgepodge between the ddr controller node at SoC
> offset 0x108 and some static memory size of 2GiB. Remove this bogus
> node because it doesn't seem to be used at all.
> 
> Signed-off-by: Michael Walle 
> ---
>  arch/arm/dts/fsl-ls1028a.dtsi | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index b3b497218f..8559562803 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -21,12 +21,6 @@
>   clock-output-names = "sysclk";
>   };
>  
> - memory@0108 {
> - device_type = "memory";
> - reg = <0x 0x0108 0 0x8000>;
> -   /* DRAM space - 1, size : 2 GB DRAM */
> - };
> -
>   gic: interrupt-controller@600 {
>   compatible = "arm,gic-v3";
>   reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
> -- 
> 2.30.2
> 

Yeah it was supposed to be the DDR controller I guess. It should have
had the "fsl,qoriq-memory-controller" compatible string, and a reg size
of 0x1000 bytes, not.. 2GB.

Reviewed-by: Vladimir Oltean 
Tested-by: Vladimir Oltean

[PATCH 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux

Now that everything is prepared, copy the fsl-ls1028a.dtsi from the
linux kernel v5.14.

Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 1212 +
 .../dt-bindings/clock/fsl,qoriq-clockgen.h|   15 +
 2 files changed, 958 insertions(+), 269 deletions(-)
 create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 69850fe7f2..343ecf0e89 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -1,12 +1,16 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * NXP ls1028a SOC common device tree source
+ * Device Tree Include file for NXP Layerscape-1028A family SoC.
  *
- * Copyright 2019-2020 NXP
+ * Copyright 2018-2020 NXP
+ *
+ * Harninder Rai 
  *
  */
 
+#include 
 #include 
+#include 
 
 / {
compatible = "fsl,ls1028a";
@@ -14,6 +18,54 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a72";
+   reg = <0x0>;
+   enable-method = "psci";
+   clocks = < QORIQ_CLK_CMUX 0>;
+   next-level-cache = <>;
+   cpu-idle-states = <_PW20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a72";
+   reg = <0x1>;
+   enable-method = "psci";
+   clocks = < QORIQ_CLK_CMUX 0>;
+   next-level-cache = <>;
+   cpu-idle-states = <_PW20>;
+   #cooling-cells = <2>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   idle-states {
+   /*
+* PSCI node is not added default, U-boot will add missing
+* parts if it determines to use PSCI.
+*/
+   entry-method = "psci";
+
+   CPU_PW20: cpu-pw20 {
+ compatible = "arm,idle-state";
+ idle-state-name = "PW20";
+ arm,psci-suspend-param = <0x0>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+   };
+   };
+
sysclk: sysclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -21,14 +73,33 @@
clock-output-names = "sysclk";
};
 
-   gic: interrupt-controller@600 {
-   compatible = "arm,gic-v3";
-   reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
- <0x0 0x0604 0 0x4>;
-   #interrupt-cells = <3>;
-   interrupt-controller;
-   interrupts = ;
+   osc_27m: clock-osc-27m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2700>;
+   clock-output-names = "phy_27m";
+   };
+
+   dpclk: clock-controller@f1f {
+   compatible = "fsl,ls1028a-plldig";
+   reg = <0x0 0xf1f 0x0 0x>;
+   #clock-cells = <0>;
+   clocks = <_27m>;
+   };
+
+   firmware {
+   optee: optee  {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   status = "disabled";
+   };
+   };
+
+   reboot {
+   compatible ="syscon-reboot";
+   regmap = <>;
+   offset = <0>;
+   mask = <0x02>;
};
 
timer {
@@ -43,177 +114,127 @@
  IRQ_TYPE_LEVEL_LOW)>;
};
 
-   soc: soc {
-   compatible = "simple-bus";
+   pmu {
+   compatible = "arm,cortex-a72-pmu";
+   interrupts = ;
+   };
+
+   gic: interrupt-controller@600 {
+   compatible= "arm,gic-v3";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-
-   clockgen: clocking@130 {
-   compatible = "fsl,ls1028a-clockgen";
-   reg = <0x0 0x130 0x0 0xa>;
-   #clock-cells = <2>;
-   clocks = <>;
+   reg= <0x0 0x0600 0 0x1>, /* GIC Dist */
+   <0x0 0x0604 0 0x4>; /* GIC Redistributor */
+   #interrupt-cells= <3>;
+   interrupt-controller;
+

Re: [PATCH] lib: fix typos in Kconfig

2021-08-31 Thread Heinrich Schuchardt





On 8/31/21 1:58 PM, Oleksandr Suvorov wrote:

There are trivial typos in the Kconfig file. Fix them.

Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and 
CMD_UBIFS")
Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
Signed-off-by: Oleksandr Suvorov 
---

  lib/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index c535147aea..d8f312f37e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -478,7 +478,7 @@ config LZMA
  config LZO
bool "Enable LZO decompression support"
help
- This enables support for LZO compression algorithm.r
+ This enables support for LZO compression algorithm.


%s/for LZO/for the LZO/



  config GZIP
bool "Enable gzip decompression support"
@@ -537,7 +537,7 @@ config SPL_GZIP
bool "Enable gzip decompression support for SPL build"
select SPL_ZLIB
help
- This enables support for GZIP compression altorithm for SPL boot.
+ This enables support for GZIP compression algorithm for SPL boot.


%s/for GZIP/for the GZIP/

Best regards

Heinrich



  config SPL_ZLIB
bool

Re: Re: [PATCH 2/2] drivers: mmc: Add wait_dat0 support for sdhci driver

2021-08-31 Thread Stephen Carlson


Jaehoon,

readx_poll_timeout expands to read_poll_timeout which accepts the signature:

read_poll_timeout(op, addr, val, cond, sleep_us, timeout_us)

sdhci_readl requires two arguments, host and SHCI_PRESENT_STATE, which 
cannot both be provided to that macro in the addr parameter. One potential 
workaround would be to declare a static helper function to call 
sdhci_readl with a constant second parameter, but this proposal would 
increase function call overhead and stack usage. Is it worth changing for 
the readability improvement?


Thanks,

Stephen Carlson

-Original Message-
From: Jaehoon Chung 
Sent: Friday, August 27, 2021 10:14 PM
To: stcar...@linux.microsoft.com; u-boot@lists.denx.de
Cc: Peng Fan 
Subject: Re: [PATCH 2/2] drivers: mmc: Add wait_dat0 support for sdhci 
driver


On 8/18/21 4:46 AM, stcar...@linux.microsoft.com wrote:

From: Stephen Carlson 

Adds an implementation of the wait_dat0 MMC operation for the DM SDHCI
driver, allowing the driver to continue when the card is ready rather
than waiting for the worst case time on each MMC switch operation.

Signed-off-by: Stephen Carlson 
---
 drivers/mmc/sdhci.c | 20 
 include/sdhci.h |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
eea4701d8a..bb55e00ef5 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -775,6 +775,25 @@ static int sdhci_get_cd(struct udevice *dev)
return value;
 }

+static int sdhci_wait_dat0(struct udevice *dev, int state,
+  int timeout_us)
+{
+   int tmp;
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+   struct sdhci_host *host = mmc->priv;
+   unsigned long timeout = timer_get_us() + timeout_us;
+
+   // readx_poll_timeout is unsuitable because sdhci_readl accepts
+   // two arguments


Removed the comment or use "/* */" instead of "//"
And i didn't understand what's unsuitable?

Best Regards,
Jaehoon Chung


+   do {
+   tmp = sdhci_readl(host, SDHCI_PRESENT_STATE);
+   if (!!(tmp & SDHCI_DATA_0_LVL_MASK) == !!state)
+   return 0;
+   } while (!timeout_us || !time_after(timer_get_us(), timeout));
+
+   return -ETIMEDOUT;
+}
+
 const struct dm_mmc_ops sdhci_ops = {
.send_cmd   = sdhci_send_command,
.set_ios= sdhci_set_ios,
@@ -783,6 +802,7 @@ const struct dm_mmc_ops sdhci_ops = {  #ifdef
MMC_SUPPORTS_TUNING
.execute_tuning = sdhci_execute_tuning,
 #endif
+   .wait_dat0  = sdhci_wait_dat0,
 };
 #else
 static const struct mmc_ops sdhci_ops = { diff --git
a/include/sdhci.h b/include/sdhci.h index 0ae9471ad7..dd4eb41442
100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -65,6 +65,8 @@
 #define  SDHCI_CARD_STATE_STABLE   BIT(17)
 #define  SDHCI_CARD_DETECT_PIN_LEVEL   BIT(18)
 #define  SDHCI_WRITE_PROTECT   BIT(19)
+#define  SDHCI_DATA_LVL_MASK   0x00F0
+#define   SDHCI_DATA_0_LVL_MASK BIT(20)

 #define SDHCI_HOST_CONTROL 0x28
 #define  SDHCI_CTRL_LEDBIT(0)

[PATCH] dt-bindings: pinctrl: k3: Synchronize with v5.14 kernel

Synchronize with the upstream version as of v5.14 kernel tag

Signed-off-by: Nishanth Menon 
---

NOTE: checkpatch complains about BIT() macro usage, but I propose that
we are better off staying in sync with the kernel tag itself.

 include/dt-bindings/pinctrl/k3.h | 51 +++-
 1 file changed, 24 insertions(+), 27 deletions(-)

diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
index e6cb1d0540e6..e085f102b283 100644
--- a/include/dt-bindings/pinctrl/k3.h
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -1,36 +1,33 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * This header provides constants for TI K3-AM65 pinctrl bindings.
+ * This header provides constants for pinctrl bindings for TI's K3 SoC
+ * family.
  *
- * Copyright (C) 2018-2021 Texas Instruments
+ * Copyright (C) 2018-2021 Texas Instruments Incorporated - https://www.ti.com/
  */
-#ifndef _DT_BINDINGS_PINCTRL_TI_K3_AM65_H
-#define _DT_BINDINGS_PINCTRL_TI_K3_AM65_H
-
-#define PULL_DISABLE   (1 << 16)
-#define PULL_UP(1 << 17)
-#define INPUT_EN   (1 << 18)
-#define SLEWCTRL_200MHZ0
-#define SLEWCTRL_150MHZ(1 << 19)
-#define SLEWCTRL_100MHZ(2 << 19)
-#define SLEWCTRL_50MHZ (3 << 19)
-#define TX_DIS (1 << 21)
-#define ISO_OVR(1 << 22)
-#define ISO_BYPASS (1 << 23)
-#define DS_EN  (1 << 24)
-#define DS_INPUT   (1 << 25)
-#define DS_FORCE_OUT_HIGH  (1 << 26)
-#define DS_PULL_UP_DOWN_EN 0
-#define DS_PULL_UP_DOWN_DIS(1 << 27)
-#define DS_PULL_UP_SEL (1 << 28)
-#define WAKEUP_ENABLE  (1 << 29)
-
-#define PIN_OUTPUT (PULL_DISABLE)
-#define PIN_OUTPUT_PULLUP  (PULL_UP)
-#define PIN_OUTPUT_PULLDOWN0
+#ifndef _DT_BINDINGS_PINCTRL_TI_K3_H
+#define _DT_BINDINGS_PINCTRL_TI_K3_H
+
+#define PULLUDEN_SHIFT (16)
+#define PULLTYPESEL_SHIFT  (17)
+#define RXACTIVE_SHIFT (18)
+
+#define PULL_DISABLE   (1 << PULLUDEN_SHIFT)
+#define PULL_ENABLE(0 << PULLUDEN_SHIFT)
+
+#define PULL_UP(1 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+#define PULL_DOWN  (0 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+
+#define INPUT_EN   (1 << RXACTIVE_SHIFT)
+#define INPUT_DISABLE  (0 << RXACTIVE_SHIFT)
+
+/* Only these macros are expected be used directly in device tree files */
+#define PIN_OUTPUT (INPUT_DISABLE | PULL_DISABLE)
+#define PIN_OUTPUT_PULLUP  (INPUT_DISABLE | PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(INPUT_DISABLE | PULL_DOWN)
 #define PIN_INPUT  (INPUT_EN | PULL_DISABLE)
 #define PIN_INPUT_PULLUP   (INPUT_EN | PULL_UP)
-#define PIN_INPUT_PULLDOWN (INPUT_EN)
+#define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN)
 
 #define AM65X_IOPAD(pa, val, muxmode)  (((pa) & 0x1fff)) ((val) | 
(muxmode))
 #define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | 
(muxmode))
-- 
2.32.0

Re: [PATCH 7/9] serial: lpuart: add new compatible fsl, ls1028a-lpuart

On Tue, Aug 31, 2021 at 05:40:26PM +0200, Michael Walle wrote:
> The offical ls1028a binding of the driver uses the following as
> compatibles:
>   compatible = "fsl,ls1028a-lpuart";

s/offical/official/

> diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
> index 2b473d70f6..3c9a69598a 100644
> --- a/drivers/serial/serial_lpuart.c
> +++ b/drivers/serial/serial_lpuart.c
> @@ -553,6 +553,8 @@ static const struct dm_serial_ops lpuart_serial_ops = {
>  static const struct udevice_id lpuart_serial_ids[] = {
>   { .compatible = "fsl,ls1021a-lpuart", .data =
>   LPUART_FLAG_REGMAP_32BIT_REG | LPUART_FLAG_REGMAP_ENDIAN_BIG },
> + { .compatible = "fsl,ls1028a-lpuart",
> + .data = LPUART_FLAG_REGMAP_32BIT_REG },

The LS1028A LPUART is identical to LS1021A except for endianness, true.
So the U-Boot driver uses the "little-endian" OF property to clear the
LPUART_FLAG_REGMAP_ENDIAN_BIG flag from LS1021A, while the Linux driver
selects endianness based on compatible string.

>   { .compatible = "fsl,imx7ulp-lpuart",
>   .data = LPUART_FLAG_REGMAP_32BIT_REG },
>   { .compatible = "fsl,vf610-lpuart"},
> -- 
> 2.30.2

Reviewed-by: Vladimir Oltean

Re: incompatible device trees between u-boot and linux

2021-08-31 Thread Rob Herring

On Tue, Aug 31, 2021 at 9:21 AM Sean Anderson  wrote:
>
> On 8/31/21 9:35 AM, Rob Herring wrote:
> > On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean  wrote:
> >>
> >> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> >>> On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
>  On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> >
> >> Hi,
> >>
> >> I noticed that there is a fallback to the u-boot device tree for linux
> >> (esp. EFI boot) if no other device tree was found, see [1]. It seems 
> >> this
> >> is working fine for imx devices, for example, where you can just boot a
> >> stock installer iso via EFI. It will just work and it is quite a nice
> >> feature as a fallback.
> >>
> >> Now for the layerscape architecture, the ls1028a in my case, things are
> >> more difficult because the bindings differ between u-boot and linux - 
> >> one
> >> which comes to mind is DSA and ethernet.
> >>
> >> Which begs the general question, is it encouraged to have both bindings
> >> diverge? To me it seems, that most bindings in u-boot are ad-hoc and 
> >> there
> >> is no real review or alignment but just added as needed, which is ok if
> >> they are local to u-boot. But since they are nowadays passed to linux
> >> (by default!) I'm not so sure anymore.
> >>
> >> OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> >> they should (could?) be shared between linux and u-boot.
> >>
> >> -michael
> >>
> >> [1]
> >> https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> >
> > The U-Boot device tree is supposed to be able to be passed on to Linux
> > and Just Work.  The bindings are not supposed to be different between
> > the two (except for when we take the binding while it's being hashed out
> > upstream BUT THEN RESYNCED).
> 
>  You might need to spell that out a bit clearer.
> 
>  You are saying that both U-Boot and Linux are allowed to have their own
>  custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = 
>  "in-band-status"'
>  for Linux), as long as the device tree files themselves are in sync, and
>  the subset of the device tree blob understood by Linux (i.e. the U-Boot
>  blob sans the U-Boot specifics) is compatible with the Linux DT blob?
> >>>
> >>> I don't know what about the Linux example makes it Linux specific.  But
> >>> yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> >>> by Linux.  The whole reason we have the -u-boot.dtsi automatic drop-in
> >>> logic (as much as it can be used is that device trees are device trees
> >>  ^
> >>  I don't think this parenthesis ever closes...
> >>
> >>> and describe the hardware and developers don't need to write a device
> >>> tree for Linux and a device tree for U-Boot and a device tree for
> >>> FreeBSD and ...  So yes, you're supposed to use the device tree for a
> >>  ^
> >>  so I never get the answer to "the whole reason is...".
> >>
> >>> platform and it works here and there and every where.
> >>
> >> The fact that only Linux uses it makes it Linux specific.
> >>
>  To expand even further on that, it means we should put 'managed = 
>  "in-band-status"'
>  in U-Boot, which is a Linux phylink device tree property, even if U-Boot
>  does not use phylink?
> >>>
> >>> We should be able to drop in the device trees from Linux and use them.
> >>> Custodians should be re-syncing them periodically.  Some are, even.
> >>
> >> Are you ready to take up device tree bindings for PTP timers, PCIe root
> >> complex event collectors, cascaded interrupt controllers, things which
> >> U-Boot will never ever need to support?
> >>
> >> At least in Linux there is a policy to not add device tree nodes that do
> >> not have drivers.
> >
> > That is not the policy. The policy is DT nodes must have binding
> > (schema) documentation and the binding should be complete as possible
> > (not what some driver currently uses). However, for complex bindings,
> > it might be difficult to write the binding in absence of a driver.
>
> It is effective policy for some arches...
>
> When the K210 patches were submitted, any bindings for devices without
> enabled drivers were requested to be (and subsequently were) removed,
> even though many of those bindings were based off of existing
> documentation. This is the primary cause of divergence between the Linux
> and U-Boot devicetrees for this platform. It is also the main reason
> that I have not bothered putting together a sync patch.

Well, that's a perfect example of why it shouldn't be policy. We need
to make sync'ing easier, not harder.

Rob

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

On Tue, Aug 31, 2021 at 05:40:19PM +0200, Michael Walle wrote:
> This series sync the device tree of the LS1028A SoC with the linux one.
> To ease future debugging and reviewing, we first clean up the existing one,
> removing bogus nodes, moving all CCSR related nodes in /soc and update the
> drivers to accept the offical compatible strings.
> 
> This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the
> LS1028A-RDB and -QDS. It would be nice if someone could actually test it on
> such a board.
> 
> I didn't sync the device trees for the NXP boards because u-boot related
> things aren't split into its own -u-boot.dtsi file. So I'll leave that task
> to NXP :)
> 
> The following patch is a prerequisite for this series:
>   
> https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/

Thanks for the work, this is appreciated.

So this needs a v2, but in general, who do you expect to pick up your patches?

After reviewing the patches I noticed further cleanup to be done, we
need to replace
phy-mode = "sgmii-2500";
with
phy-mode = "2500base-x";

and
phy-mode = "xfi";
with
phy-mode = "10gbase-r";

and then delete the fsl_enetc.c driver's support for
PHY_INTERFACE_MODE_XFI and PHY_INTERFACE_MODE_XGMII, that's completely
bogus.

Re: [PATCH 2/2] mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

On Tue, Aug 31, 2021 at 8:34 PM Fabio Estevam  wrote:
>
> Hi Oleksandr,
>
> On Tue, Aug 31, 2021 at 1:42 PM Oleksandr Suvorov
>  wrote:
> >
> > Import HS400 support for iMX7ULP B0 from the Linux kernel:
> >
> > 2eaf5a533afd ("mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP")
> >
> > According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
> > before any setting of STROBE_DLL_CTRL register.
> >
> > USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
> > for slave sel value. If this register bits value is 0,  it needs
> > 256 ref_clk cycles to update slave sel value. IC suggest to set
> > bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
> > sel value. This will short the lock time of slave.
> >
> > i.MX7ULP B0 will need more time to lock the REF and SLV, so change
> > to add 5us delay.
> >
> > Signed-off-by: Oleksandr Suvorov 
> > Series-notes
> > fsl_esdhc_imx improvements
> >
> > Import individual settings for soc imx7ulp and add support of HS400 for
> > this soc.
> > END
>
> The text below the Signed-off-by should be removed.

Oops, missed ":" :) The fix is coming.

>
> Other than that, the patch looks good:
>
> Reviewed-by: Fabio Estevam 

Thanks, Fabio!


-- 
Best regards
Oleksandr

Oleksandr Suvorov
cryo...@gmail.com

[PATCH v2 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp

From: Jorge Ramirez-Ortiz 

Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel.
Set supported by u-boot flags only.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Ricardo Salveti 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
Reviewed-by: Fabio Estevam 
---

Changes in v2:
- add a Reviewed-by record

 drivers/mmc/fsl_esdhc_imx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index aabf39535f..6c8f77f9ee 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1706,6 +1706,11 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
| ESDHC_FLAG_HS400,
 };
 
+static struct esdhc_soc_data usdhc_imx7ulp_data = {
+   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
+};
+
 static struct esdhc_soc_data usdhc_imx8qm_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING |
ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 |
@@ -1720,7 +1725,7 @@ static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,imx6sl-usdhc", },
{ .compatible = "fsl,imx6q-usdhc", },
{ .compatible = "fsl,imx7d-usdhc", .data = (ulong)_imx7d_data,},
-   { .compatible = "fsl,imx7ulp-usdhc", },
+   { .compatible = "fsl,imx7ulp-usdhc", .data = 
(ulong)_imx7ulp_data,},
{ .compatible = "fsl,imx8qm-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mm-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mn-usdhc", .data = (ulong)_imx8qm_data,},
-- 
2.31.1

[PATCH v2 2/2] mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

Import HS400 support for iMX7ULP B0 from the Linux kernel:

2eaf5a533afd ("mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP")

According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
before any setting of STROBE_DLL_CTRL register.

USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
for slave sel value. If this register bits value is 0,  it needs
256 ref_clk cycles to update slave sel value. IC suggest to set
bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
sel value. This will short the lock time of slave.

i.MX7ULP B0 will need more time to lock the REF and SLV, so change
to add 5us delay.

Signed-off-by: Oleksandr Suvorov 
Reviewed-by: Fabio Estevam 
---

Changes in v2:
- fixed Series-notes record.
- added Reviewed-by records.

 drivers/mmc/fsl_esdhc_imx.c | 11 ---
 include/fsl_esdhc_imx.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 6c8f77f9ee..569f099d9b 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -727,17 +727,21 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
 
if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
esdhc_write32(>strobe_dllctrl, 
ESDHC_STROBE_DLL_CTRL_RESET);
+   /* clear the reset bit on strobe dll before any setting */
+   esdhc_write32(>strobe_dllctrl, 0);
+
 
/*
 * enable strobe dll ctrl and adjust the delay target
 * for the uSDHC loopback read clock
 */
val = ESDHC_STROBE_DLL_CTRL_ENABLE |
+   ESDHC_STROBE_DLL_CTRL_SLV_UPDATE_INT_DEFAULT |
(priv->strobe_dll_delay_target <<
 ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT);
esdhc_write32(>strobe_dllctrl, val);
-   /* wait 1us to make sure strobe dll status register stable */
-   mdelay(1);
+   /* wait 5us to make sure strobe dll status register stable */
+   mdelay(5);
val = esdhc_read32(>strobe_dllstat);
if (!(val & ESDHC_STROBE_DLL_STS_REF_LOCK))
pr_warn("HS400 strobe DLL status REF not lock!\n");
@@ -1708,7 +1712,8 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
 
 static struct esdhc_soc_data usdhc_imx7ulp_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
-   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
+   | ESDHC_FLAG_HS400,
 };
 
 static struct esdhc_soc_data usdhc_imx8qm_data = {
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 45ed635a77..12e9163382 100644
--- a/include/fsl_esdhc_imx.h
+++ b/include/fsl_esdhc_imx.h
@@ -194,6 +194,7 @@
 #define ESDHC_STROBE_DLL_CTRL_RESETBIT(1)
 #define ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_DEFAULT   0x7
 #define ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT 3
+#define ESDHC_STROBE_DLL_CTRL_SLV_UPDATE_INT_DEFAULT   (4 << 20)
 
 #define ESDHC_STROBE_DLL_STATUS0x74
 #define ESDHC_STROBE_DLL_STS_REF_LOCK  BIT(1)
-- 
2.31.1

Re: [PATCH 2/9] arm: dts: ls1028a: move devices into /soc

On Tue, Aug 31, 2021 at 05:40:21PM +0200, Michael Walle wrote:
> Move all the CCSR related device nodes into /soc similiar to the linux
> device tree.
> 
> Signed-off-by: Michael Walle 
> ---
>  .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  |   4 +
>  .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi   |   2 +-
>  .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi   |   2 +-
>  .../dts/fsl-ls1028a-qds--sch-30841.dtsi   |   8 +-
>  .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi  |   4 +-
>  .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |   2 +-
>  .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi  |   8 +-
>  .../dts/fsl-ls1028a-qds--sch-24801.dtsi   |   8 +-
>  .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi  |   8 +-
>  .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi  |   8 +-
>  .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi   |   2 +-
>  .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi   |   2 +-
>  arch/arm/dts/fsl-ls1028a-qds.dtsi |   4 +
>  arch/arm/dts/fsl-ls1028a-rdb.dts  |   4 +
>  arch/arm/dts/fsl-ls1028a.dtsi | 767 +-
>  15 files changed, 426 insertions(+), 407 deletions(-)
> 
> diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
> b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
> index b3861ed98c..fa4c05212a 100644
> --- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
> @@ -266,6 +266,10 @@
>   u-boot,dm-pre-reloc;
>  };
>  
> + {
> + u-boot,dm-pre-reloc;
> +};
> +

Does the Kontron SL28 use SPL?

>   {
>   u-boot,dm-pre-reloc;
>  };
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi 
> b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
> index 1fb2cdf0c2..1834418ae2 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
> @@ -20,7 +20,7 @@
>  _felix_port1 {
>   status = "okay";
>   phy-mode = "sgmii-2500";
> - phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@02}>;
> + phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@02}>;
>  };
>  
>  _felix_port4 {
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi 
> b/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi
> index 2333f74e5a..2ee11bcacb 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi
> @@ -20,7 +20,7 @@
>  _felix_port2 {
>   status = "okay";
>   phy-mode = "sgmii-2500";
> - phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@60/phy@02}>;
> + phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@60/phy@02}>;
>  };
>  
>  _felix_port4 {
> diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi 
> b/arch/arm/dts/fsl-ls1028a-qds.dtsi
> index 69632fa796..3b223a5b52 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
> @@ -241,6 +241,10 @@
>   status = "okay";
>  };
>  
> + {
> + u-boot,dm-pre-reloc;
> +};
> +

The LS1028A-QDS does not use SPL, it uses TF-A, hence the name:
configs/ls1028aqds_tfa_defconfig

>   {
>   status = "okay";
>  };
> diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts 
> b/arch/arm/dts/fsl-ls1028a-rdb.dts
> index 82a8c0a0cd..06ee4e747a 100644
> --- a/arch/arm/dts/fsl-ls1028a-rdb.dts
> +++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
> @@ -123,6 +123,10 @@
>   status = "okay";
>  };
>  
> + {
> + u-boot,dm-pre-reloc;
> +};
> +

Likewise.


Otherwise, the patch itself is pretty much impossible to follow. I guess
the only option would be to move nodes one by one to /soc such that it
becomes obvious. I don't have a strong preference, just saying that I
can't judge it for correctness.

Re: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache

2021-08-31 Thread Rick Chen

> From: Zong Li 
> Sent: Tuesday, August 31, 2021 5:21 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache
>
> The enable_caches is a generic hook for architecture-implemented, we define 
> this function to enable composable cache of sifive platforms.
>
> In sifive_cache, it invokes the generic cache_enable interface of cache 
> uclass to execute the relative implementation in SiFive ccache driver.
>
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/Kconfig|  5 +
>  arch/riscv/lib/Makefile   |  1 +
>  arch/riscv/lib/sifive_cache.c | 27 +++
>  common/board_r.c  |  4 ++--
>  4 files changed, 35 insertions(+), 2 deletions(-)  create mode 100644 
> arch/riscv/lib/sifive_cache.c
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> 4b0c3dffa6..ec651fe0a4 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
>   The SiFive CLINT block holds memory-mapped control and status 
> registers
>   associated with software and timer interrupts.
>
> +config SIFIVE_CACHE
> +   bool
> +   help
> + This enables the operations to configure SiFive cache
> +
>  config ANDES_PLIC
> bool
> depends on RISCV_MMODE || SPL_RISCV_MMODE diff --git 
> a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> c4cc41434b..06020fcc2a 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
>  obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
>  obj-$(CONFIG_CMD_GO) += boot.o
>  obj-y  += cache.o
> +obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
>  ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
>  obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
>  obj-$(CONFIG_ANDES_PLIC) += andes_plic.o diff --git 
> a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c new file mode 
> 100644 index 00..28154878fc
> --- /dev/null
> +++ b/arch/riscv/lib/sifive_cache.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 SiFive, Inc
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void enable_caches(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /* Enable ways of ccache */
> +   ret = uclass_get_device_by_driver(UCLASS_CACHE,
> + DM_DRIVER_GET(sifive_ccache),
> + );
> +   if (ret) {
> +   log_debug("Cannot enable cache ways");
> +   } else {
> +   ret = cache_enable(dev);
> +   if (ret)
> +   log_debug("ccache enable failed");
> +   }
> +}
> diff --git a/common/board_r.c b/common/board_r.c index e3e6248a1f..630c2451a2 
> 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -114,7 +114,7 @@ static int initr_reloc(void)
> return 0;
>  }
>
> -#ifdef CONFIG_ARM
> +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)

Here may cause other RISC-V platforms build error.
eq, ae350 will compile error as below:
common/board_r.o: in function `initr_caches':
/u-boot-riscv/common/board_r.c:124: undefined reference to `enable_caches'
Makefile:1795: recipe for target 'u-boot' failed

Maybe you can separate this part an isolate patch:
board_r: enable initr_caches for RISC-V ...
And also implement the week function for others.

Thanks,
Rick



>  /*
>   * Some of these functions are needed purely because the functions they
>   * call return void. If we change them to return 0, these stubs can go away.
> @@ -607,7 +607,7 @@ static init_fnc_t init_sequence_r[] = {
> initr_trace,
> initr_reloc,
> /* TODO: could x86/PPC have this also perhaps? */ -#ifdef CONFIG_ARM
> +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
> initr_caches,
> /* Note: For Freescale LS2 SoCs, new MMU table is created in DDR.
>  *   A temporary mapping of IFC high region is since removed,
> --
> 2.32.0

Re: [PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi


Am 2021-08-31 20:32, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 05:40:25PM +0200, Michael Walle wrote:

The offical ls1028a binding of the driver uses the following as


Same typo as before.


compatibles:
  compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";

Add the missing compatible to the driver and update the device tree.

Signed-off-by: Michael Walle 
---
diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
index 8fe3508c64..23d812f476 100644
--- a/drivers/spi/fsl_dspi.c
+++ b/drivers/spi/fsl_dspi.c
@@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {

 static const struct udevice_id fsl_dspi_ids[] = {
{ .compatible = "fsl,vf610-dspi" },
+   { .compatible = "fsl,ls1021a-v1.0-dspi" },


Okay, so you say it is pointless to add the "fsl,ls1028a-dspi"
compatible string as well, since the U-Boot driver will match on the
fallback compatible, and that is absolutely sufficient, since U-Boot
will never implement any of the LS1028A specifics (DMA) anyway.
I'm fine with that.


I'll add that to the commit message in the next version.



Reviewed-by: Vladimir Oltean 


-michael

Re: [PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi

On Tue, Aug 31, 2021 at 11:35:25PM +0200, Michael Walle wrote:
> Am 2021-08-31 20:32, schrieb Vladimir Oltean:
> > On Tue, Aug 31, 2021 at 05:40:25PM +0200, Michael Walle wrote:
> > > The offical ls1028a binding of the driver uses the following as
> > 
> > Same typo as before.
> > 
> > > compatibles:
> > >   compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
> > > 
> > > Add the missing compatible to the driver and update the device tree.
> > > 
> > > Signed-off-by: Michael Walle 
> > > ---
> > > diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
> > > index 8fe3508c64..23d812f476 100644
> > > --- a/drivers/spi/fsl_dspi.c
> > > +++ b/drivers/spi/fsl_dspi.c
> > > @@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
> > > 
> > >  static const struct udevice_id fsl_dspi_ids[] = {
> > >   { .compatible = "fsl,vf610-dspi" },
> > > + { .compatible = "fsl,ls1021a-v1.0-dspi" },
> > 
> > Okay, so you say it is pointless to add the "fsl,ls1028a-dspi"
> > compatible string as well, since the U-Boot driver will match on the
> > fallback compatible, and that is absolutely sufficient, since U-Boot
> > will never implement any of the LS1028A specifics (DMA) anyway.
> > I'm fine with that.
> 
> I'll add that to the commit message in the next version.

There is a subtler point to be made.
While in the case of lpuart, there is that difference between Linux and
U-Boot, in that:
- Linux sets endianness based on compatible string
- U-Boot sets endianness based on "little-endian" property
For the dspi, it is different. Both Linux and U-Boot set endianness
based on the "big-endian" property. So that's why both the LS1021A and
LS1028A DSPI modules work with the same compatible string. Quite
inconsistent, but it is what it is.

Re: [PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi


Am 2021-08-31 23:39, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 11:35:25PM +0200, Michael Walle wrote:

Am 2021-08-31 20:32, schrieb Vladimir Oltean:
> On Tue, Aug 31, 2021 at 05:40:25PM +0200, Michael Walle wrote:
> > The offical ls1028a binding of the driver uses the following as
>
> Same typo as before.
>
> > compatibles:
> >   compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
> >
> > Add the missing compatible to the driver and update the device tree.
> >
> > Signed-off-by: Michael Walle 
> > ---
> > diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
> > index 8fe3508c64..23d812f476 100644
> > --- a/drivers/spi/fsl_dspi.c
> > +++ b/drivers/spi/fsl_dspi.c
> > @@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
> >
> >  static const struct udevice_id fsl_dspi_ids[] = {
> >   { .compatible = "fsl,vf610-dspi" },
> > + { .compatible = "fsl,ls1021a-v1.0-dspi" },
>
> Okay, so you say it is pointless to add the "fsl,ls1028a-dspi"
> compatible string as well, since the U-Boot driver will match on the
> fallback compatible, and that is absolutely sufficient, since U-Boot
> will never implement any of the LS1028A specifics (DMA) anyway.
> I'm fine with that.

I'll add that to the commit message in the next version.


There is a subtler point to be made.
While in the case of lpuart, there is that difference between Linux and
U-Boot, in that:
- Linux sets endianness based on compatible string
- U-Boot sets endianness based on "little-endian" property


You mean before this clean-up series?


For the dspi, it is different. Both Linux and U-Boot set endianness
based on the "big-endian" property. So that's why both the LS1021A and
LS1028A DSPI modules work with the same compatible string. Quite
inconsistent, but it is what it is.


Consistently inconsistent :p

-michael

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

Am 1. September 2021 00:03:58 MESZ schrieb Vladimir Oltean 
:
>On Tue, Aug 31, 2021 at 11:19:20PM +0200, Michael Walle wrote:
>> > So this needs a v2, but in general, who do you expect to pick up your
>> > patches?
>>
>> Mh, I haven't found a rule how patches are picked up in u-boot but most of 
>> the
>> time they go through the qoriq git tree. Why do you ask?
>
>Just curious.
>
>> > After reviewing the patches I noticed further cleanup to be done, we
>> > need to replace
>> >phy-mode = "sgmii-2500";
>> > with
>> >phy-mode = "2500base-x";
>> >
>> > and
>> >phy-mode = "xfi";
>> > with
>> >phy-mode = "10gbase-r";
>> >
>> > and then delete the fsl_enetc.c driver's support for
>> > PHY_INTERFACE_MODE_XFI and PHY_INTERFACE_MODE_XGMII, that's completely
>> > bogus.
>>
>> Ok, that sounds easy enough. Will pick that up.
>
>"Will pick that up" means that you intend to do it? There are many
>device trees and drivers that use the non-standard "sgmii-2500" and
>"xfi" compatibles, not just LS1028A stuff.

mh. i just grepped in arm/dts and it was only the qds stuff? I'll have a look 
tomorrow again. might have missed something. so yeah, maybe not in this series 
if there are more. 

-michael

Re: [PATCH 2/9] arm: dts: ls1028a: move devices into /soc


Am 2021-08-31 20:46, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 05:40:21PM +0200, Michael Walle wrote:

Move all the CCSR related device nodes into /soc similiar to the linux
device tree.

Signed-off-by: Michael Walle 
---
 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  |   4 +
 .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds--sch-30841.dtsi   |   8 +-
 .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi  |   4 +-
 .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |   2 +-
 .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi  |   8 +-
 .../dts/fsl-ls1028a-qds--sch-24801.dtsi   |   8 +-
 .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi  |   8 +-
 .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi  |   8 +-
 .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi   |   2 +-
 .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi   |   2 +-
 arch/arm/dts/fsl-ls1028a-qds.dtsi |   4 +
 arch/arm/dts/fsl-ls1028a-rdb.dts  |   4 +
 arch/arm/dts/fsl-ls1028a.dtsi | 767 
+-

 15 files changed, 426 insertions(+), 407 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi

index b3861ed98c..fa4c05212a 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -266,6 +266,10 @@
u-boot,dm-pre-reloc;
 };

+ {
+   u-boot,dm-pre-reloc;
+};
+


Does the Kontron SL28 use SPL?


Yep :) No BL1/BL2 for TF-A, BL31 is optionally loaded by the
u-boot SPL. Mainly because NXP doesn't seem to be interested
in bringing layerscape (besides one architecture) support in
upstream TF-A. And I don't want to fork yet another software
part from some vendor supplied tree. Not really needed, so I
skipped that. Sorry for that rant ;)


  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi

index 1fb2cdf0c2..1834418ae2 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
@@ -20,7 +20,7 @@
 _felix_port1 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@02}>;
+	phy-handle = 
<&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@02}>;

 };

 _felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi

index 2333f74e5a..2ee11bcacb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi
@@ -20,7 +20,7 @@
 _felix_port2 {
status = "okay";
phy-mode = "sgmii-2500";
-   phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@60/phy@02}>;
+	phy-handle = 
<&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@60/phy@02}>;

 };

 _felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds.dtsi

index 69632fa796..3b223a5b52 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -241,6 +241,10 @@
status = "okay";
 };

+ {
+   u-boot,dm-pre-reloc;
+};
+


The LS1028A-QDS does not use SPL, it uses TF-A, hence the name:
configs/ls1028aqds_tfa_defconfig


The fsl-ls1028a-qds.dts has "u-boot,dm-pre-reloc" set for the
i2c0 node, which doesn't work without the same flag for /soc.
So that means I should remove the u-boot,dm-pre-reloc from the
i2c0 node instead?


  {
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts 
b/arch/arm/dts/fsl-ls1028a-rdb.dts

index 82a8c0a0cd..06ee4e747a 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -123,6 +123,10 @@
status = "okay";
 };

+ {
+   u-boot,dm-pre-reloc;
+};
+


Likewise.


likewise ;)

Otherwise, the patch itself is pretty much impossible to follow. I 
guess

the only option would be to move nodes one by one to /soc such that it
becomes obvious. I don't have a strong preference, just saying that I
can't judge it for correctness.


Sounds like many small patches, but I don't have a strong optinion
either.

-michael

Re: [PATCH 7/9] serial: lpuart: add new compatible fsl, ls1028a-lpuart


Am 2021-08-31 20:28, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 05:40:26PM +0200, Michael Walle wrote:

The offical ls1028a binding of the driver uses the following as
compatibles:
  compatible = "fsl,ls1028a-lpuart";


s/offical/official/

diff --git a/drivers/serial/serial_lpuart.c 
b/drivers/serial/serial_lpuart.c

index 2b473d70f6..3c9a69598a 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -553,6 +553,8 @@ static const struct dm_serial_ops 
lpuart_serial_ops = {

 static const struct udevice_id lpuart_serial_ids[] = {
{ .compatible = "fsl,ls1021a-lpuart", .data =
LPUART_FLAG_REGMAP_32BIT_REG | LPUART_FLAG_REGMAP_ENDIAN_BIG },
+   { .compatible = "fsl,ls1028a-lpuart",
+   .data = LPUART_FLAG_REGMAP_32BIT_REG },


The LS1028A LPUART is identical to LS1021A except for endianness, true.
So the U-Boot driver uses the "little-endian" OF property to clear the
LPUART_FLAG_REGMAP_ENDIAN_BIG flag from LS1021A, while the Linux driver
selects endianness based on compatible string.


Yeah, and it seems that parsing of the little-endian flag was introduced
just for the ls1028a. If that is true, one could remove that, but I 
wasn't

sure, so I just left it there.


{ .compatible = "fsl,imx7ulp-lpuart",
.data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,vf610-lpuart"},
--
2.30.2


Reviewed-by: Vladimir Oltean 


--
-michael

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux


Am 2021-08-31 20:22, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 05:40:19PM +0200, Michael Walle wrote:
This series sync the device tree of the LS1028A SoC with the linux 
one.
To ease future debugging and reviewing, we first clean up the existing 
one,
removing bogus nodes, moving all CCSR related nodes in /soc and update 
the

drivers to accept the offical compatible strings.

This was tested on a sl28 board, but the ls1028a.dtsi sync also 
affects the
LS1028A-RDB and -QDS. It would be nice if someone could actually test 
it on

such a board.

I didn't sync the device trees for the NXP boards because u-boot 
related
things aren't split into its own -u-boot.dtsi file. So I'll leave that 
task

to NXP :)


No apparent regression apart from a failure to build.


Thanks for testing!

-michael

Re: [PATCH 6/9] spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi

On Tue, Aug 31, 2021 at 11:53:22PM +0200, Michael Walle wrote:
> Am 2021-08-31 23:39, schrieb Vladimir Oltean:
> > On Tue, Aug 31, 2021 at 11:35:25PM +0200, Michael Walle wrote:
> > > Am 2021-08-31 20:32, schrieb Vladimir Oltean:
> > > > On Tue, Aug 31, 2021 at 05:40:25PM +0200, Michael Walle wrote:
> > > > > The offical ls1028a binding of the driver uses the following as
> > > >
> > > > Same typo as before.
> > > >
> > > > > compatibles:
> > > > >   compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
> > > > >
> > > > > Add the missing compatible to the driver and update the device tree.
> > > > >
> > > > > Signed-off-by: Michael Walle 
> > > > > ---
> > > > > diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
> > > > > index 8fe3508c64..23d812f476 100644
> > > > > --- a/drivers/spi/fsl_dspi.c
> > > > > +++ b/drivers/spi/fsl_dspi.c
> > > > > @@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
> > > > >
> > > > >  static const struct udevice_id fsl_dspi_ids[] = {
> > > > >   { .compatible = "fsl,vf610-dspi" },
> > > > > + { .compatible = "fsl,ls1021a-v1.0-dspi" },
> > > >
> > > > Okay, so you say it is pointless to add the "fsl,ls1028a-dspi"
> > > > compatible string as well, since the U-Boot driver will match on the
> > > > fallback compatible, and that is absolutely sufficient, since U-Boot
> > > > will never implement any of the LS1028A specifics (DMA) anyway.
> > > > I'm fine with that.
> > > 
> > > I'll add that to the commit message in the next version.
> > 
> > There is a subtler point to be made.
> > While in the case of lpuart, there is that difference between Linux and
> > U-Boot, in that:
> > - Linux sets endianness based on compatible string
> > - U-Boot sets endianness based on "little-endian" property
> 
> You mean before this clean-up series?

Yes, I mean in the current git trees.

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

On Tue, Aug 31, 2021 at 11:19:20PM +0200, Michael Walle wrote:
> > So this needs a v2, but in general, who do you expect to pick up your
> > patches?
>
> Mh, I haven't found a rule how patches are picked up in u-boot but most of the
> time they go through the qoriq git tree. Why do you ask?

Just curious.

> > After reviewing the patches I noticed further cleanup to be done, we
> > need to replace
> > phy-mode = "sgmii-2500";
> > with
> > phy-mode = "2500base-x";
> >
> > and
> > phy-mode = "xfi";
> > with
> > phy-mode = "10gbase-r";
> >
> > and then delete the fsl_enetc.c driver's support for
> > PHY_INTERFACE_MODE_XFI and PHY_INTERFACE_MODE_XGMII, that's completely
> > bogus.
>
> Ok, that sounds easy enough. Will pick that up.

"Will pick that up" means that you intend to do it? There are many
device trees and drivers that use the non-standard "sgmii-2500" and
"xfi" compatibles, not just LS1028A stuff.

Re: [PATCH] Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig

On Fri, Aug 27, 2021 at 09:18:30PM -0400, Tom Rini wrote:

> This converts the following to Kconfig:
>CONFIG_SKIP_LOWLEVEL_INIT
>CONFIG_SKIP_LOWLEVEL_INIT_ONLY
> 
> In order to do this, we need to introduce SPL and TPL variants of these
> options so that we can clearly disable these options only in SPL in some
> cases, and both instances in other cases.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Finish converting CONFIG_SYS_CACHELINE_SIZE to Kconfig

On Thu, Aug 26, 2021 at 11:47:59AM -0400, Tom Rini wrote:

> We move the SYS_CACHE_SHIFT_N options from arch/arm/Kconfig to
> arch/Kconfig, and introduce SYS_CACHE_SHIFT_4 to provide a size of 16.
> Introduce select statements for other architectures based on current
> usage.  For MIPS, we take the existing arch-specific symbol and migrate
> to the generic symbol.  This lets us remove a little bit of otherwise
> unused code.
> 
> Cc: Alexey Brodkin 
> Cc: Anup Patel 
> Cc: Atish Patra 
> Cc: Bin Meng 
> Cc: Daniel Schwierzeck 
> Cc: Leo 
> Cc: Palmer Dabbelt 
> Cc: Paul Walmsley 
> Cc: Rick Chen 
> Cc: Sean Anderson 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> Acked-by: Sean Anderson 
> Reviewed-by: Rick Chen 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Convert CONFIG_SYS_MALLOC_LEN to Kconfig

On Sat, Aug 28, 2021 at 09:34:49PM -0400, Tom Rini wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_MALLOC_LEN
> 
> Signed-off-by: Tom Rini 
> Acked-by: Sean Anderson 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

On Tue, Aug 31, 2021 at 11:19:20PM +0200, Michael Walle wrote:
> Am 2021-08-31 20:51, schrieb Vladimir Oltean:
> > On Tue, Aug 31, 2021 at 05:40:19PM +0200, Michael Walle wrote:
> > > This series sync the device tree of the LS1028A SoC with the linux
> > > one.
> > > To ease future debugging and reviewing, we first clean up the
> > > existing one,
> > > removing bogus nodes, moving all CCSR related nodes in /soc and
> > > update the
> > > drivers to accept the offical compatible strings.
> > > 
> > > This was tested on a sl28 board, but the ls1028a.dtsi sync also
> > > affects the
> > > LS1028A-RDB and -QDS. It would be nice if someone could actually
> > > test it on
> > > such a board.
> > > 
> > > I didn't sync the device trees for the NXP boards because u-boot
> > > related
> > > things aren't split into its own -u-boot.dtsi file. So I'll leave
> > > that task
> > > to NXP :)
> > > 
> > > The following patch is a prerequisite for this series:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/
> > 
> > Thanks for the work, this is appreciated.

Yes, thanks for getting the ball rolling on this!

> > So this needs a v2, but in general, who do you expect to pick up your
> > patches?
> 
> Mh, I haven't found a rule how patches are picked up in u-boot but most of
> the
> time they go through the qoriq git tree. Why do you ask?

I too would expect these to come ia the qoriq tree.  We don't have the
number of custodians/maintainers Linux has, so we also don't have the
very fine grained tree merge path.  For driver changes, etc, that aren't
also touching a core subsystem, I'm fine with whichever custodian feels
most comfortable taking them and sending me a pull request.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Kconfig: Remove all default n/no options

On Fri, Aug 27, 2021 at 08:48:10AM +0200, Michal Simek wrote:

> default n/no doesn't need to be specified. It is default option anyway.
> 
> Signed-off-by: Michal Simek 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache

2021-08-31 Thread Zong Li

On Wed, Sep 1, 2021 at 10:06 AM Rick Chen  wrote:
>
> > From: Zong Li 
> > Sent: Tuesday, August 31, 2021 5:21 PM
> > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> > ; bmeng...@gmail.com; sean...@gmail.com; 
> > green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> > u-boot@lists.denx.de
> > Cc: Zong Li 
> > Subject: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache
> >
> > The enable_caches is a generic hook for architecture-implemented, we define 
> > this function to enable composable cache of sifive platforms.
> >
> > In sifive_cache, it invokes the generic cache_enable interface of cache 
> > uclass to execute the relative implementation in SiFive ccache driver.
> >
> > Signed-off-by: Zong Li 
> > ---
> >  arch/riscv/Kconfig|  5 +
> >  arch/riscv/lib/Makefile   |  1 +
> >  arch/riscv/lib/sifive_cache.c | 27 +++
> >  common/board_r.c  |  4 ++--
> >  4 files changed, 35 insertions(+), 2 deletions(-)  create mode 100644 
> > arch/riscv/lib/sifive_cache.c
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > 4b0c3dffa6..ec651fe0a4 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
> >   The SiFive CLINT block holds memory-mapped control and status 
> > registers
> >   associated with software and timer interrupts.
> >
> > +config SIFIVE_CACHE
> > +   bool
> > +   help
> > + This enables the operations to configure SiFive cache
> > +
> >  config ANDES_PLIC
> > bool
> > depends on RISCV_MMODE || SPL_RISCV_MMODE diff --git 
> > a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> > c4cc41434b..06020fcc2a 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> >  obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
> >  obj-$(CONFIG_CMD_GO) += boot.o
> >  obj-y  += cache.o
> > +obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
> >  ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> >  obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
> >  obj-$(CONFIG_ANDES_PLIC) += andes_plic.o diff --git 
> > a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c new file 
> > mode 100644 index 00..28154878fc
> > --- /dev/null
> > +++ b/arch/riscv/lib/sifive_cache.c
> > @@ -0,0 +1,27 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021 SiFive, Inc
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +void enable_caches(void)
> > +{
> > +   struct udevice *dev;
> > +   int ret;
> > +
> > +   /* Enable ways of ccache */
> > +   ret = uclass_get_device_by_driver(UCLASS_CACHE,
> > + DM_DRIVER_GET(sifive_ccache),
> > + );
> > +   if (ret) {
> > +   log_debug("Cannot enable cache ways");
> > +   } else {
> > +   ret = cache_enable(dev);
> > +   if (ret)
> > +   log_debug("ccache enable failed");
> > +   }
> > +}
> > diff --git a/common/board_r.c b/common/board_r.c index 
> > e3e6248a1f..630c2451a2 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -114,7 +114,7 @@ static int initr_reloc(void)
> > return 0;
> >  }
> >
> > -#ifdef CONFIG_ARM
> > +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
>
> Here may cause other RISC-V platforms build error.
> eq, ae350 will compile error as below:
> common/board_r.o: in function `initr_caches':
> /u-boot-riscv/common/board_r.c:124: undefined reference to `enable_caches'
> Makefile:1795: recipe for target 'u-boot' failed
>
> Maybe you can separate this part an isolate patch:
> board_r: enable initr_caches for RISC-V ...
> And also implement the week function for others.
>

Thanks for reviewing that. I would fix it and send the next version.

> Thanks,
> Rick
>
>
>
> >  /*
> >   * Some of these functions are needed purely because the functions they
> >   * call return void. If we change them to return 0, these stubs can go 
> > away.
> > @@ -607,7 +607,7 @@ static init_fnc_t init_sequence_r[] = {
> > initr_trace,
> > initr_reloc,
> > /* TODO: could x86/PPC have this also perhaps? */ -#ifdef CONFIG_ARM
> > +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
> > initr_caches,
> > /* Note: For Freescale LS2 SoCs, new MMU table is created in DDR.
> >  *   A temporary mapping of IFC high region is since removed,
> > --
> > 2.32.0

Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux

Am 2021-08-31 20:51, schrieb Vladimir Oltean:

On Tue, Aug 31, 2021 at 05:40:19PM +0200, Michael Walle wrote:
This series sync the device tree of the LS1028A SoC with the linux
one.
To ease future debugging and reviewing, we first clean up the existing
one,
removing bogus nodes, moving all CCSR related nodes in /soc and update
the

drivers to accept the offical compatible strings.

This was tested on a sl28 board, but the ls1028a.dtsi sync also
affects the
LS1028A-RDB and -QDS. It would be nice if someone could actually test
it on

such a board.

I didn't sync the device trees for the NXP boards because u-boot
related
things aren't split into its own -u-boot.dtsi file. So I'll leave that
task

to NXP :)

The following patch is a prerequisite for this series:

https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/

Thanks for the work, this is appreciated.

So this needs a v2, but in general, who do you expect to pick up your
patches?

Mh, I haven't found a rule how patches are picked up in u-boot but most
of the

time they go through the qoriq git tree. Why do you ask?

After reviewing the patches I noticed further cleanup to be done, we
need to replace
phy-mode = "sgmii-2500";
with
phy-mode = "2500base-x";

and
phy-mode = "xfi";
with
phy-mode = "10gbase-r";

and then delete the fsl_enetc.c driver's support for
PHY_INTERFACE_MODE_XFI and PHY_INTERFACE_MODE_XGMII, that's completely
bogus.

Ok, that sounds easy enough. Will pick that up.

-michael

Re: [PATCH 2/9] arm: dts: ls1028a: move devices into /soc

On Tue, Aug 31, 2021 at 11:32:22PM +0200, Michael Walle wrote:
> > Does the Kontron SL28 use SPL?
> 
> Yep :) No BL1/BL2 for TF-A, BL31 is optionally loaded by the
> u-boot SPL. Mainly because NXP doesn't seem to be interested
> in bringing layerscape (besides one architecture) support in
> upstream TF-A. And I don't want to fork yet another software
> part from some vendor supplied tree. Not really needed, so I
> skipped that. Sorry for that rant ;)

No problem, negative feedback is the best feedback!

> > The LS1028A-QDS does not use SPL, it uses TF-A, hence the name:
> > configs/ls1028aqds_tfa_defconfig
> 
> The fsl-ls1028a-qds.dts has "u-boot,dm-pre-reloc" set for the
> i2c0 node, which doesn't work without the same flag for /soc.
> So that means I should remove the u-boot,dm-pre-reloc from the
> i2c0 node instead?

To be clear, the discussion is practically about the pcf2127-rtc.
I'll be honest with you, I've no idea why anyone would need an RTC
driver in SPL, nor how can I even test it if I wanted to.
I've tested just now, and I can run "date" (which calls dm_rtc_get)
in Hush after deleting the "u-boot,dm-pre-reloc" property, and it
behaved absolutely the same (no surprises).

> > Otherwise, the patch itself is pretty much impossible to follow. I guess
> > the only option would be to move nodes one by one to /soc such that it
> > becomes obvious. I don't have a strong preference, just saying that I
> > can't judge it for correctness.
> 
> Sounds like many small patches, but I don't have a strong optinion
> either.

Whichever way you feel like. Just stating that proper review will be
very difficult in this format.

Re: [PATCH 2/3] global: Convert CONFIG_LOADADDR to CONFIG_SYS_LOADADDR

On Mon, Aug 23, 2021 at 10:25:30AM -0400, Tom Rini wrote:

> - In most of the codebase, we reference CONFIG_SYS_LOAD_ADDR and not
>   CONFIG_LOADADDR.
> - Generally, CONFIG_SYS_LOADADDR is set to CONFIG_LOADADDR and then as
>   noted, we use CONFIG_SYS_LOADADDR.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] qfw: Switch to CONFIG_SYS_LOAD_ADDR from CONFIG_LOADADDR

On Mon, Aug 23, 2021 at 10:25:29AM -0400, Tom Rini wrote:

> All platforms define CONFIG_SYS_LOAD_ADDR, but only some define
> CONFIG_LOADADDR.  Very very rarely are these not the same address, and
> qemu-ppce500 is one such case.  However, based on reading the history of
> the code, this mismatched value was simply a copy-paste from other
> PowerPC platforms where it is this unused currently.  Switch the code to
> use CONFIG_SYS_LOAD_ADDR and update the documentation.
> 
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> Reviewed-by: Bin Meng 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/9] Kconfig: Use spaces not tabs in Kconfig entires

On Sat, Aug 21, 2021 at 01:50:11PM -0400, Tom Rini wrote:

> While the Kconfig language seems to accept either form of whitespace, we
> use a space throughout the project, except in these spots.
> 
> Signed-off-by: Tom Rini 

For the series, applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Convert CONFIG_MX7D to Kconfig

On Mon, Aug 23, 2021 at 04:35:25PM -0400, Tom Rini wrote:

> This converts the following to Kconfig:
>CONFIG_MX7D
> 
> Cc: Oleksandr Suvorov 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

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

On Tue, Aug 31, 2021 at 12:41:17AM +0200, Marek Vasut wrote:

> The following changes since commit 4865db07169126ca0205f1a6265adf01bd69b3df:
> 
>   Merge tag 'efi-2021-10-rc3' of
> https://source.denx.de/u-boot/custodians/u-boot-efi (2021-08-23 12:44:12
> -0400)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 221146c55868e0f1c1cd3d9add440081b677f559:
> 
>   ARM: rmobile: beacon-renesom: Enable QSPI NOR Flash (2021-08-24 20:03:09
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 1/4] cache: add sifive composable cache driver

2021-08-31 Thread Rick Chen

> From: Zong Li 
> Sent: Tuesday, August 31, 2021 5:21 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v4 1/4] cache: add sifive composable cache driver
>
> This driver is currently responsible for enabling all ccache ways.
> Composable cache could be configure as RAM or cache, we will use it as RAM at 
> the beginning to put the u-boot SPL there. In u-boot proper phrase, we will 
> use the composable cache as cache, and try to enable the cache ways.
>
> Signed-off-by: Zong Li 
> Reviewed-by: Sean Anderson 
> ---
>  drivers/cache/Kconfig   |  7 +++
>  drivers/cache/Makefile  |  1 +
>  drivers/cache/cache-sifive-ccache.c | 75 +
>  3 files changed, 83 insertions(+)
>  create mode 100644 drivers/cache/cache-sifive-ccache.c

Reviewed-by: Rick Chen

Re: [PATCH 7/9] serial: lpuart: add new compatible fsl, ls1028a-lpuart

On Tue, Aug 31, 2021 at 11:37:19PM +0200, Michael Walle wrote:
> Yeah, and it seems that parsing of the little-endian flag was introduced
> just for the ls1028a. If that is true, one could remove that, but I wasn't
> sure, so I just left it there.

Leave NXP something to do too ;)

Re: [PATCH 1/6] imx: Introduce CONFIG_MACH_IMX

On Tue, Aug 24, 2021 at 08:40:59PM -0400, Tom Rini wrote:

> Currently, there is no over-arching symbol for access to
> arch/arm/mach-imx nor the CONFIG symbols that are common over all of
> these related platforms.  This new CONFIG symbol will allow us to start
> down this path.
> 
> Signed-off-by: Tom Rini 

For the series, applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ls1046ardb_qspi*: Enable RAMBOOT_PBL

On Tue, Aug 24, 2021 at 11:11:50PM -0400, Tom Rini wrote:

> Based on include/configs/ls1046ardb.h it seems that CONFIG_RAMBOOT_PBL
> should have been enabled, but was not.  Enable and migrate the values to
> Kconfig.
> 
> Cc: Mingkai Hu 
> Cc: Rajesh Bhagat 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] Convert CONFIG_SYS_LOAD_ADDR to Kconfig