Re: [PATCH v3 4/4] riscv: Update Microchip MPFS Icicle Kit support

2022-10-27 Thread Rick Chen
> From: Padmarao Begari 
> Sent: Thursday, October 27, 2022 2:02 PM
> To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) 
> ; Leo Yu-Chi Liang(梁育齊) ; 
> bmeng...@gmail.com
> Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; 
> valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; 
> Padmarao Begari 
> Subject: [PATCH v3 4/4] riscv: Update Microchip MPFS Icicle Kit support
>
> This patch updates Microchip MPFS Icicle Kit support. For now, add Microchip 
> QSPI driver and a small 4MB reservation is made at the end of 32-bit DDR to 
> provide some memory for the HSS to use.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Conor Dooley 
> ---
>  board/microchip/mpfs_icicle/Kconfig | 7 +++
>  configs/microchip_mpfs_icicle_defconfig | 1 +
>  2 files changed, 8 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v3 2/4] riscv: dts: Add QSPI NAND device node

2022-10-27 Thread Rick Chen
> From: Padmarao Begari 
> Sent: Thursday, October 27, 2022 2:02 PM
> To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) 
> ; Leo Yu-Chi Liang(梁育齊) ; 
> bmeng...@gmail.com
> Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; 
> valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; 
> Padmarao Begari 
> Subject: [PATCH v3 2/4] riscv: dts: Add QSPI NAND device node
>
> Add QSPI NAND device node to the Microchip PolarFire SoC Icicle kit device 
> tree.
>
> The Winbond NAND flash memory can be connected to the Icicle Kit by using the 
> Mikroe Flash 5 click board and the Pi 3 Click shield.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Conor Dooley 
> ---
>  arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 16 
>  1 file changed, 16 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v3 1/4] riscv: dts: Update memory configuration

2022-10-27 Thread Rick Chen
> From: Padmarao Begari 
> Sent: Thursday, October 27, 2022 2:02 PM
> To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) 
> ; Leo Yu-Chi Liang(梁育齊) ; 
> bmeng...@gmail.com
> Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; 
> valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; 
> Padmarao Begari 
> Subject: [PATCH v3 1/4] riscv: dts: Update memory configuration
>
> In the v2022.10 Icicle reference design, the seg registers have been changed, 
> resulting in a required change to the memory map.
> A small 4MB reservation is made at the end of 32-bit DDR to provide some 
> memory for the HSS to use, so that it can cache its payload between reboots 
> of a specific context.
>
> Co-developed-by: Conor Dooley 
> Signed-off-by: Conor Dooley 
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Conor Dooley 
> ---
>  arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 75 +---
>  1 file changed, 17 insertions(+), 58 deletions(-)

Reviewed-by: Rick Chen 


Re: imx8 regression: cyclic_register for watchdog@30280000 failed

2022-10-27 Thread Stefan Roese

Tim,

On 27.10.22 17:34, Tim Harvey wrote:

On Wed, Oct 26, 2022 at 11:32 PM Stefan Roese  wrote:


Tim,

On 26.10.22 21:06, Tim Harvey wrote:

On Wed, Oct 26, 2022 at 5:33 AM Rasmus Villemoes
 wrote:


On 25/10/2022 18.32, Tim Harvey wrote:

Greetings,

I've noticed a regression since the merge of the cyclic framework use
for watchdog on my imx8m boards:

cyclic_register for watchdog@3028 failed
WDT:   Failed to start watchdog@3028

A bisect lead me to the following 3 sequential patches:
29caf9305b6f cyclic: Use schedule() instead of WATCHDOG_RESET()
^^^ bad
881d4108257a cyclic: Introduce schedule() function
^^^ unbuildable
c2fd0ca1a822 watchdog: Integrate watchdog triggering into the cyclic framework
^^^ unbootable


Can you provide some more details on "unbootable" and "unbuildable"?
I.e., what build error do you get for the middle patch, and what do you
see on the console with the "unbootable" image?


Rasmus,

Sure. I'm building and testing for imx8mm_venice.

Here are the patches in question listed in commit order:
d219fc06b30d configs: Resync with savedefconfig
^^^ no issues found

c2fd0ca1a822 watchdog: Integrate watchdog triggering into the cyclic framework
^^^ unbootable for imx8mm_venice - hangs after SPL banner:
U-Boot SPL 2022.10-rc3-00241-gc2fd0ca1a822 (Oct 26 2022 - 10:08:54 -0700)
^^^ this occurs because 'uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(gsc), &dev))' in gateworks/venice/spl.c board_init_f
hangs and I'm not clear why this patch affects that

881d4108257a cyclic: Introduce schedule() function
^^^ unbuildable for imx8mm_venice_defconfig
   CC  arch/arm/lib/sections.o
In file included from include/asm-generic/global_data.h:23,
   from ./arch/arm/include/asm/global_data.h:102,
   from include/dm/of.h:11,
   from include/dm/ofnode.h:12,
   from include/dm/device.h:13,
   from include/linux/mtd/mtd.h:26,
   from include/nand.h:17,
   from cmd/bootm.c:17:
include/cyclic.h:116:19: error: macro "schedule" passed 1 arguments, but takes j
ust 0
   void schedule(void);

29caf9305b6f cyclic: Use schedule() instead of WATCHDOG_RESET()
^^^ build issue resolved, boot issue on imx8mm-venice resolved, but
this is where we now encounter watchdog failures in both the SPL and
U-Boot:

SPL:
cyclic_register for watchdog@3028 failed
WDT:   Failed to start watchdog@3028

The failure here is 'Cyclic IF not ready yet' (which should probably
be an error print not a debug print).


Ye, makes sense. I'll change this.


In this case the watchdog gets
started but never reset via cyclic. This is due to cyclic_init never
being called in the SPL - where is that supposed to occur?


I did not have many targets with WDT in SPL to test with. Seems that
I missed to call into cyclic_init() here.


U-Boot:
cyclic function watchdog@3028 took too long: 2976us vs 1000us max, disabling

Here also the watchdog gets started but never reset via cyclic so the
board will reset itself after 60s sitting in U-Boot for example.


This is already changed in master since yesterday. Now only a warning
will be shown upon long execution time but the function will not
be disabled. So please re-check with master and report if this
works better.


confirmed - the cyclic call no longer gets cancelled and its now just a warning


Good. We should improve this, that this warning will not be displayed,
at least in the WDT event, at some point.


The issue here is that for some reason the first call to wdt_cyclic()
takes about 3ms vs subsequent calls taking about 185us on this
platform which exceeds the 1ms default max of
CONFIG_CYCLIC_MAX_CPU_TIME_US and thus the watchdog reset is disabled
and the board resets in 60s. Setting
CONFIG_CYCLIC_MAX_CPU_TIME_US=5000 resolves that issue but this feels
like a workaround that perhaps shouldn't be required.


I agree.


Sounds like Rasmus is going to spin a patch for this but at least now
it's just a warning message.


Yes. Let's wait for Rasmus'es work on this.


I assume the
extra time in the first call is the probing of the device. So I think
the fix for this U-Boot regression is to move the init part of
wdt_cyclic to wdt_start() and have wdt_cyclic() only call wdt_reset()

Fabio, I assume you see this on other imx8m boards?


Also, the .configs used in each case might be interesting, certainly all
lines containing CYCLIC, WATCHDOG or WDT.



$ grep CYCLIC .config
CONFIG_CYCLIC=y
CONFIG_CYCLIC_MAX_CPU_TIME_US=1000
# CONFIG_CMD_MX_CYCLIC is not set
CONFIG_CMD_CYCLIC=y
$ grep WATCHDOG .config
CONFIG_SPL_WATCHDOG=y
CONFIG_SYSRESET_WATCHDOG=y
# CONFIG_SYSRESET_WATCHDOG_AUTO is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_AUTOSTART=y
CONFIG_WATCHDOG_TIMEOUT_MSECS=6
CONFIG_IMX_WATCHDOG=y
# CONFIG_WATCHDOG_RESET_DISABLE is not set
# CONFIG_ULP_WATCHDOG is not set
# CONFIG_DESIGNWARE_WATCHDOG is not set
# CONFIG_XILINX_TB_WATCHDOG is not set
$ grep WDT .config
# C

Re: [PATCH v1 2/2] i2c: microchip: fix erroneous late ack send

2022-10-27 Thread Padmarao.Begari
Hi Conor,
> On Wed, 2022-10-26 at 07:54 +, Conor Dooley - M52691 wrote:
> On 26/10/2022 08:49, Conor Dooley wrote:
> > A late ack is currently being sent at the end of a transfer due to
> > incorrect logic in mchp_corei2c_empty_rx(). Currently the Assert
> > Ack
> > bit is being written to the controller's control reg after the last
> > byte has been received, causing it to sent another byte with the
> > ack.
> > Instead, the AA flag should be written to the control register when
> > the penultimate byte is read so it is sent out for the last byte.
> > 
> > Reported-by: Andreas Buerkler 
> > Fixes: 0dc0d1e094 ("i2c: Add Microchip PolarFire SoC I2C driver")
> > Fixes: 0190d48488 ("i2c: microchip: fix ack sending logic")
> 
> I had removed this fixes tag but I must have aborted the rebase
> in which I did. If nothing else needs changing, please drop it,
> otherwise I'll remove it if/when I send a v2.
> 
Yes you can remove it because the patch check is showing warning for
this fixes tag

Regards
Padmarao
> Thanks,
> Conor.
> 
> > Signed-off-by: Conor Dooley 
> > ---
> >   drivers/i2c/i2c-microchip.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/i2c/i2c-microchip.c b/drivers/i2c/i2c-
> > microchip.c
> > index 3a27459386..d82b80f535 100644
> > --- a/drivers/i2c/i2c-microchip.c
> > +++ b/drivers/i2c/i2c-microchip.c
> > @@ -224,7 +224,7 @@ static void mpfs_i2c_empty_rx(struct
> > mpfs_i2c_bus *bus)
> > bus->msg_len--;
> > }
> >   
> > -   if (bus->msg_len == 0) {
> > +   if (bus->msg_len <= 1) {
> > ctrl = readl(bus->base + MPFS_I2C_CTRL);
> > ctrl &= ~CTRL_AA;
> > writel(ctrl, bus->base + MPFS_I2C_CTRL);


Re: [PATCH v1 1/2] i2c: microchip: fix ack sending logic

2022-10-27 Thread Padmarao.Begari
> On Wed, 2022-10-26 at 08:49 +0100, Conor Dooley wrote:
> "Master receive mode" was not correctly sending ACKs/NACKs in the
> interrupt handler. Bring the handling of M_SLAR_ACK, M_RX_DATA_ACKED
> &
> M_RX_DATA_NACKED in line with the Linux driver.
> 
> Fixes: 0dc0d1e094 ("i2c: Add Microchip PolarFire SoC I2C driver")
> Reported-by: Shravan Chippa 
> Signed-off-by: Conor Dooley 
> ---
>  drivers/i2c/i2c-microchip.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/i2c-microchip.c b/drivers/i2c/i2c-
> microchip.c
> index 12f65d0af7..3a27459386 100644
> --- a/drivers/i2c/i2c-microchip.c
> +++ b/drivers/i2c/i2c-microchip.c
> @@ -2,8 +2,9 @@
>  /*
>   * Microchip I2C controller driver
>   *
> - * Copyright (C) 2021 Microchip Technology Inc.
> + * Copyright (C) 2021-2022 Microchip Technology Inc.
>   * Padmarao Begari 
> + * Conor Dooley 
>   */
>  #include 
>  #include 
> @@ -265,16 +266,27 @@ static int mpfs_i2c_service_handler(struct
> mpfs_i2c_bus *bus)
>   }
>   break;
>   case STATUS_M_SLAR_ACK:
> - ctrl = readl(bus->base + MPFS_I2C_CTRL);
> - ctrl |= CTRL_AA;
> - writel(ctrl, bus->base + MPFS_I2C_CTRL);
> - if (bus->msg_len == 0) {
> + if (bus->msg_len > 1u) {
> + ctrl = readl(bus->base + MPFS_I2C_CTRL);
> + ctrl |= CTRL_AA;
> + writel(ctrl, bus->base + MPFS_I2C_CTRL);
> + } else if (bus->msg_len == 1u) {
> + ctrl = readl(bus->base + MPFS_I2C_CTRL);
> + ctrl &= ~CTRL_AA;
> + writel(ctrl, bus->base + MPFS_I2C_CTRL);
> + } else {
> + ctrl = readl(bus->base + MPFS_I2C_CTRL);
> + ctrl |= CTRL_AA;
> + writel(ctrl, bus->base + MPFS_I2C_CTRL);
>   /* On the last byte to be transmitted, send
> STOP */
>   mpfs_i2c_stop(bus);
>   finish = true;
>   }
>   break;
>   case STATUS_M_RX_DATA_ACKED:
> + mpfs_i2c_empty_rx(bus);
> + break;
> + case STATUS_M_RX_DATA_NACKED:
>   mpfs_i2c_empty_rx(bus);
>   if (bus->msg_len == 0) {
>   /* On the last byte to be transmitted, send
> STOP */
> @@ -283,7 +295,6 @@ static int mpfs_i2c_service_handler(struct
> mpfs_i2c_bus *bus)
>   }
>   break;
>   case STATUS_M_TX_DATA_NACK:
> - case STATUS_M_RX_DATA_NACKED:
>   case STATUS_M_SLAR_NACK:
>   case STATUS_M_SLAW_NACK:
>   bus->msg_err = -ENXIO;

Reviewed-by: Padmarao Begari 


Re: [PATCH v1 2/2] i2c: microchip: fix erroneous late ack send

2022-10-27 Thread Padmarao.Begari
> On Wed, 2022-10-26 at 08:49 +0100, Conor Dooley wrote:
> A late ack is currently being sent at the end of a transfer due to
> incorrect logic in mchp_corei2c_empty_rx(). Currently the Assert Ack
> bit is being written to the controller's control reg after the last
> byte has been received, causing it to sent another byte with the ack.
> Instead, the AA flag should be written to the control register when
> the penultimate byte is read so it is sent out for the last byte.
> 
> Reported-by: Andreas Buerkler 
> Fixes: 0dc0d1e094 ("i2c: Add Microchip PolarFire SoC I2C driver")
> Fixes: 0190d48488 ("i2c: microchip: fix ack sending logic")
> Signed-off-by: Conor Dooley 
> ---
>  drivers/i2c/i2c-microchip.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/i2c-microchip.c b/drivers/i2c/i2c-
> microchip.c
> index 3a27459386..d82b80f535 100644
> --- a/drivers/i2c/i2c-microchip.c
> +++ b/drivers/i2c/i2c-microchip.c
> @@ -224,7 +224,7 @@ static void mpfs_i2c_empty_rx(struct mpfs_i2c_bus
> *bus)
>   bus->msg_len--;
>   }
>  
> - if (bus->msg_len == 0) {
> + if (bus->msg_len <= 1) {
>   ctrl = readl(bus->base + MPFS_I2C_CTRL);
>   ctrl &= ~CTRL_AA;
>   writel(ctrl, bus->base + MPFS_I2C_CTRL);

Reviewed-by: Padmarao Begari 


[PATCH v8 8/8] board: gw_ventana: enable MV88E61XX DSA support

2022-10-27 Thread Tim Harvey
Add MV88E61XX DSA support:
 - update dt to provide internal MDIO bus and port handles.
   U-Boot requires a more restrictive subset of the dt bindings
   required by Linux for the sake of simplifying code
 - update defconfig to remove old driver and enable new one
 - replace mv88e61xx_hw_reset weak override with board_phy_config support
   for register configuration that is outside the scope of the DSA driver

Signed-off-by: Tim Harvey 
Reviewed-by: Fabio Estevam 
Reviewed-by: Vladimir Oltean 
---
v8:
 - added phy-mode = "internal" to phy ports
v7:
 - added Vladimir's rb tag
v6:
 - update commit message
 - squash accidently change to mv88e6xxx driver into previous patch
 - remove unused label for cpu port
v5:
 - fix typo in defconfig s/MV88E61XX/MV88E6XXX
 - added Fabio's rb tag
v4:
 - use standard Linux internal MDIO dt structure
 - use PHY_FIXED_ID define
v3:
 - move mdio's mdio@0 subnode
v2: no changes
---
 arch/arm/dts/imx6qdl-gw5904.dtsi| 36 +-
 board/gateworks/gw_ventana/gw_ventana.c | 50 +
 configs/gwventana_gw5904_defconfig  |  7 ++--
 3 files changed, 56 insertions(+), 37 deletions(-)

diff --git a/arch/arm/dts/imx6qdl-gw5904.dtsi b/arch/arm/dts/imx6qdl-gw5904.dtsi
index 612b6e068e28..ea54922f15f8 100644
--- a/arch/arm/dts/imx6qdl-gw5904.dtsi
+++ b/arch/arm/dts/imx6qdl-gw5904.dtsi
@@ -212,6 +212,27 @@
compatible = "marvell,mv88e6085";
reg = <0>;
 
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   sw_phy0: ethernet-phy@0 {
+   reg = <0x0>;
+   };
+
+   sw_phy1: ethernet-phy@1 {
+   reg = <0x1>;
+   };
+
+   sw_phy2: ethernet-phy@2 {
+   reg = <0x2>;
+   };
+
+   sw_phy3: ethernet-phy@3 {
+   reg = <0x3>;
+   };
+   };
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -219,27 +240,40 @@
port@0 {
reg = <0>;
label = "lan4";
+   phy-handle = <&sw_phy0>;
+   phy-mode = "internal";
};
 
port@1 {
reg = <1>;
label = "lan3";
+   phy-handle = <&sw_phy1>;
+   phy-mode = "internal";
};
 
port@2 {
reg = <2>;
label = "lan2";
+   phy-handle = <&sw_phy2>;
+   phy-mode = "internal";
};
 
port@3 {
reg = <3>;
label = "lan1";
+   phy-handle = <&sw_phy3>;
+   phy-mode = "internal";
};
 
port@5 {
reg = <5>;
-   label = "cpu";
ethernet = <&fec>;
+   phy-mode = "rgmii-id";
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
};
};
};
diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index 0ecfd98c2261..683def7e9f71 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -83,44 +83,30 @@ int board_phy_config(struct phy_device *phydev)
break;
}
 
+   /* Fixed PHY: for GW5904/GW5909 this is Marvell 88E6176 GbE Switch */
+   if (phydev->phy_id == PHY_FIXED_ID &&
+   (board_type == GW5904 || board_type == GW5909)) {
+   struct mii_dev *bus = miiphy_get_dev_by_name("mdio");
+
+   puts("MV88E61XX ");
+   /* GPIO[0] output CLK125 for RGMII_REFCLK */
+   bus->write(bus, 0x1c, 0, 0x1a, (1 << 15) | (0x62 << 8) | 0xfe);
+

[PATCH v8 7/8] net: add MV88E6xxx DSA driver

2022-10-27 Thread Tim Harvey
Add a DSA driver for the MV88E6xxx compatible Ethernet switches.

Cc: Marek Behún 
Cc: Vladimir Oltean 
Signed-off-by: Tim Harvey 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Fabio Estevam 
---
v8:
- remove energy-detect low-power mode config

v7:
 - rebase on master
 - update commit short msg (s/MV88E61xx/MV88E6xxx)
 - replace inline smi_cmd* with macros using logical operators
 - replace bitfield_replace with logical operators for readibility
 - removed some unused register definitions
 - config switch based SERDES mode once in probe vs port_enable
 - rework port_enable to clean up and:
  - enable energy-detect for all non fixed PHY ports
  - configure RGMII delays based on interface type

v6:
 - update commit msg (s/MV88E61xx/MV88E6xxx)
 - remove GbE from commit msg and Kconfig desc
 - squash accidental change from patch 7 into patch 6
 - added error print on failure to read switch id
 - mv88e6xxx_probe:
  - check for switch enabled
  - remove unused variable enabled
  - remove unnecessary call to dsa_set_tagging
 - port_probe:
  - new function to configure phy features by calling phy_config
 - port_enable:
  - only enable energy-detect sensing on phy ports
  - add phy/cmode verification mistmatch warning
  - remove mv88e6xxx_fixed_port_setup()
  - always force link up for fixed ports
  - always set SERDES mode regardless of cpu port
  - remove unnecessary setting of CPUDEST
 - port_disable:
  - remove pointless error check
 - removed unnecessary priv data for mdio controller
 - fix indentation
 - change variable name for clarity

v5:
 - added support for MV88E6320
 - added Fabio's rb tag

v4:
 - rename to mv88e6xxx
 - sort includes alphabetically
 - remove dsa term from function names
 - reduce indentation level and remove unecessary code in of probe_mdio function
 - rename pdev to mdev to represent mdio device

v3:
 - Added Vladimir's rb tag

v2:
 - rebase on v2022.07-rc1 (use ofnode_get_phy_node)
 - remove unused commented out fields from struct
 - remove unused PORT_MASK macro
 - remove phy from priv struct name
 - refactor code from original drivers/net/phy/mv88e61xx with
   suggestions from review to consolidate some functions
   into mv88e61xx_dsa_port_enable
 - remove unecessary skiping of disabling of CPU port
 - remove unecessary dev_set_parent_priv
 - remove unnecessary static init flag
 - replace debug with a dev_warn if switch device-id unsupported
 - remove unnecessary xmit/recv functions as we rely on the fact that
   only a single port is active instead of mangling packets
---
 drivers/net/Kconfig |   7 +
 drivers/net/Makefile|   1 +
 drivers/net/mv88e6xxx.c | 755 
 3 files changed, 763 insertions(+)
 create mode 100644 drivers/net/mv88e6xxx.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5eef3..67f23917f42c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -438,6 +438,13 @@ config KSZ9477
  This driver implements a DSA switch driver for the KSZ9477 family
  of GbE switches using the I2C interface.
 
+config MV88E6XXX
+   bool "Marvell MV88E6xxx Ethernet switch DSA driver"
+   depends on DM_DSA && DM_MDIO
+   help
+ This driver implements a DSA switch driver for the MV88E6xxx family
+ of Ethernet switches using the MDIO interface
+
 config MVGBE
bool "Marvell Orion5x/Kirkwood network interface support"
depends on ARCH_KIRKWOOD || ARCH_ORION5X
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 96b7678e9882..f05fd58e3fa7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
 obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
 obj-$(CONFIG_MT7620_ETH) += mt7620-eth.o
 obj-$(CONFIG_MT7628_ETH) += mt7628-eth.o
+obj-$(CONFIG_MV88E6XXX) += mv88e6xxx.o
 obj-$(CONFIG_MVGBE) += mvgbe.o
 obj-$(CONFIG_MVMDIO) += mvmdio.o
 obj-$(CONFIG_MVNETA) += mvneta.o
diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
new file mode 100644
index ..64e860e324dc
--- /dev/null
+++ b/drivers/net/mv88e6xxx.c
@@ -0,0 +1,755 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Gateworks Corporation 
+ * Tim Harvey 
+ *
+ * (C) Copyright 2015
+ * Elecsys Corporation 
+ * Kevin Smith 
+ *
+ * Original driver:
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ * Prafulla Wadaskar 
+ */
+
+/*
+ * DSA driver for mv88e6xxx ethernet switches.
+ *
+ * This driver configures the mv88e6xxx for basic use as a DSA switch.
+ *
+ * This driver was adapted from drivers/net/phy/mv88e61xx and tested
+ * on the mv88e6176 via an SGMII interface.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Device addresses */
+#define DEVADDR_PHY(p) (p)
+#define DEVADDR_SERDES 0x0F
+
+/* SMI indirection registers for multichip addressing mode */
+#define SMI_CMD_REG0x00
+#define SMI_DATA_REG

[PATCH v8 6/8] net: fec: add support for DM_MDIO

2022-10-27 Thread Tim Harvey
Add support for DM_MDIO by registering a UCLASS_MDIO driver and
attempting to use it. This is necessary if wanting to use a DSA
driver for example hanging off of the FEC MAC.

Care is taken to fallback to non DM_MDIO mii bus as several boards define
DM_MDIO without having the proper device-tree configuration necessary
such as an mdio subnode, a phy-mode prop, and either a valid phy-handle
prop or fixed-phy subnode which will cause dm_eth_phy_connect() to fail.

Signed-off-by: Tim Harvey 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - no changes
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - no changes
v2:
 - fix fallback mechanism for legacy dt's that do not have phy-handle
   and mdio subnode
---
 drivers/net/fec_mxc.c | 90 ++-
 1 file changed, 88 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bbc4434ddb9e..7057472710fa 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "fec_mxc.h"
 #include 
@@ -1026,6 +1028,81 @@ struct mii_dev *fec_get_miibus(ulong base_addr, int 
dev_id)
return bus;
 }
 
+#ifdef CONFIG_DM_MDIO
+struct dm_fec_mdio_priv {
+   struct ethernet_regs *regs;
+};
+
+static int dm_fec_mdio_read(struct udevice *dev, int addr, int devad, int reg)
+{
+   struct dm_fec_mdio_priv *priv = dev_get_priv(dev);
+
+   return fec_mdio_read(priv->regs, addr, reg);
+}
+
+static int dm_fec_mdio_write(struct udevice *dev, int addr, int devad, int 
reg, u16 data)
+{
+   struct dm_fec_mdio_priv *priv = dev_get_priv(dev);
+
+   return fec_mdio_write(priv->regs, addr, reg, data);
+}
+
+static const struct mdio_ops dm_fec_mdio_ops = {
+   .read = dm_fec_mdio_read,
+   .write = dm_fec_mdio_write,
+};
+
+static int dm_fec_mdio_probe(struct udevice *dev)
+{
+   struct dm_fec_mdio_priv *priv = dev_get_priv(dev);
+
+   priv->regs = (struct ethernet_regs 
*)ofnode_get_addr(dev_ofnode(dev->parent));
+
+   return 0;
+}
+
+U_BOOT_DRIVER(fec_mdio) = {
+   .name   = "fec_mdio",
+   .id = UCLASS_MDIO,
+   .probe  = dm_fec_mdio_probe,
+   .ops= &dm_fec_mdio_ops,
+   .priv_auto  = sizeof(struct dm_fec_mdio_priv),
+};
+
+static int dm_fec_bind_mdio(struct udevice *dev)
+{
+   struct udevice *mdiodev;
+   const char *name;
+   ofnode mdio;
+   int ret = -ENODEV;
+
+   /* for a UCLASS_MDIO driver we need to bind and probe manually
+* for an internal MDIO bus that has no dt compatible of its own
+*/
+   ofnode_for_each_subnode(mdio, dev_ofnode(dev)) {
+   name = ofnode_get_name(mdio);
+
+   if (strcmp(name, "mdio"))
+   continue;
+
+   ret = device_bind_driver_to_node(dev, "fec_mdio",
+name, mdio, &mdiodev);
+   if (ret) {
+   printf("%s bind %s failed: %d\n", __func__, name, ret);
+   break;
+   }
+
+   /* need to probe it as there is no compatible to do so */
+   ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, &mdiodev);
+   if (!ret)
+   return 0;
+   printf("%s probe %s failed: %d\n", __func__, name, ret);
+   }
+
+   return ret;
+}
+#endif
+
 static int fecmxc_read_rom_hwaddr(struct udevice *dev)
 {
struct fec_priv *priv = dev_get_priv(dev);
@@ -1089,7 +1166,7 @@ static int device_get_phy_addr(struct fec_priv *priv, 
struct udevice *dev)
 
 static int fec_phy_init(struct fec_priv *priv, struct udevice *dev)
 {
-   struct phy_device *phydev;
+   struct phy_device *phydev = NULL;
int addr;
 
addr = device_get_phy_addr(priv, dev);
@@ -1097,7 +1174,10 @@ static int fec_phy_init(struct fec_priv *priv, struct 
udevice *dev)
addr = CONFIG_FEC_MXC_PHYADDR;
 #endif
 
-   phydev = phy_connect(priv->bus, addr, dev, priv->interface);
+   if (IS_ENABLED(CONFIG_DM_MDIO))
+   phydev = dm_eth_phy_connect(dev);
+   if (!phydev)
+   phydev = phy_connect(priv->bus, addr, dev, priv->interface);
if (!phydev)
return -ENODEV;
 
@@ -1228,6 +1308,12 @@ static int fecmxc_probe(struct udevice *dev)
 
priv->dev_id = dev_seq(dev);
 
+   if (IS_ENABLED(CONFIG_DM_MDIO)) {
+   ret = dm_fec_bind_mdio(dev);
+   if (ret && ret != -ENODEV)
+   return ret;
+   }
+
 #ifdef CONFIG_DM_ETH_PHY
bus = eth_phy_get_mdio_bus(dev);
 #endif
-- 
2.25.1



[PATCH v8 4/8] net: dsa: allow rcv() and xmit() to be optional

2022-10-27 Thread Tim Harvey
Allow rcv() and xmit() dsa driver ops to be optional in case a driver
does not care to mangle a packet as in U-Boot only one network port is
enabled at a time and thus no packet mangling is necessary.

Suggested-by: Vladimir Oltean 
Signed-off-by: Tim Harvey 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - no changes
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - added Vladimir's rb tag
v2: new patch
---
 net/dsa-uclass.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 211a991cdd0d..eba8347ae21a 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -131,16 +131,14 @@ static void dsa_port_stop(struct udevice *pdev)
  * We copy the frame to a stack buffer where we have reserved headroom and
  * tailroom space.  Headroom and tailroom are set to 0.
  */
-static int dsa_port_send(struct udevice *pdev, void *packet, int length)
+static int dsa_port_mangle_packet(struct udevice *pdev, void *packet, int 
length)
 {
+   struct dsa_port_pdata *port_pdata = dev_get_parent_plat(pdev);
struct udevice *dev = dev_get_parent(pdev);
struct dsa_priv *priv = dev_get_uclass_priv(dev);
int head = priv->headroom, tail = priv->tailroom;
-   struct udevice *master = dsa_get_master(dev);
struct dsa_ops *ops = dsa_get_ops(dev);
uchar dsa_packet_tmp[PKTSIZE_ALIGN];
-   struct dsa_port_pdata *port_pdata;
-   int err;
 
if (length + head + tail > PKTSIZE_ALIGN)
return -EINVAL;
@@ -152,10 +150,21 @@ static int dsa_port_send(struct udevice *pdev, void 
*packet, int length)
/* copy back to preserve original buffer alignment */
memcpy(packet, dsa_packet_tmp, length);
 
-   port_pdata = dev_get_parent_plat(pdev);
-   err = ops->xmit(dev, port_pdata->index, packet, length);
-   if (err)
-   return err;
+   return ops->xmit(dev, port_pdata->index, packet, length);
+}
+
+static int dsa_port_send(struct udevice *pdev, void *packet, int length)
+{
+   struct udevice *dev = dev_get_parent(pdev);
+   struct udevice *master = dsa_get_master(dev);
+   struct dsa_ops *ops = dsa_get_ops(dev);
+   int err;
+
+   if (ops->xmit) {
+   err = dsa_port_mangle_packet(pdev, packet, length);
+   if (err)
+   return err;
+   }
 
return eth_get_ops(master)->send(master, packet, length);
 }
@@ -172,7 +181,7 @@ static int dsa_port_recv(struct udevice *pdev, int flags, 
uchar **packetp)
int length, port_index, err;
 
length = eth_get_ops(master)->recv(master, flags, packetp);
-   if (length <= 0)
+   if (length <= 0 || !ops->rcv)
return length;
 
/*
-- 
2.25.1



[PATCH v8 5/8] net: ksz9477: remove unnecessary xmit and recv functions

2022-10-27 Thread Tim Harvey
Remove the unnecessary xmit and recv functions.

Signed-off-by: Tim Harvey 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - no changes
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - added Vladimir's rb tag
v2: new patch
---
 drivers/net/ksz9477.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/net/ksz9477.c b/drivers/net/ksz9477.c
index ed8f1895cb12..fb5c76c600be 100644
--- a/drivers/net/ksz9477.c
+++ b/drivers/net/ksz9477.c
@@ -62,7 +62,6 @@
 
 struct ksz_dsa_priv {
struct udevice *dev;
-   int active_port;
 };
 
 static inline int ksz_read8(struct udevice *dev, u32 reg, u8 *val)
@@ -382,9 +381,6 @@ static int ksz_port_enable(struct udevice *dev, int port, 
struct phy_device *phy
data8 |= SW_START;
ksz_write8(priv->dev, REG_SW_OPERATION, data8);
 
-   /* keep track of current enabled non-cpu port */
-   priv->active_port = port;
-
return 0;
 }
 
@@ -413,28 +409,9 @@ static void ksz_port_disable(struct udevice *dev, int 
port, struct phy_device *p
 */
 }
 
-static int ksz_xmit(struct udevice *dev, int port, void *packet, int length)
-{
-   dev_dbg(dev, "%s P%d %d\n", __func__, port + 1, length);
-
-   return 0;
-}
-
-static int ksz_recv(struct udevice *dev, int *port, void *packet, int length)
-{
-   struct ksz_dsa_priv *priv = dev_get_priv(dev);
-
-   dev_dbg(dev, "%s P%d %d\n", __func__, priv->active_port + 1, length);
-   *port = priv->active_port;
-
-   return 0;
-};
-
 static const struct dsa_ops ksz_dsa_ops = {
.port_enable = ksz_port_enable,
.port_disable = ksz_port_disable,
-   .xmit = ksz_xmit,
-   .rcv = ksz_recv,
 };
 
 static int ksz_probe_mdio(struct udevice *dev)
-- 
2.25.1



[PATCH v8 3/8] net: dsa: ensure dsa driver has proper ops

2022-10-27 Thread Tim Harvey
Add a function to sanity check a dsa driver having proper ops.

Suggested-by: Vladimir Oltean 
Signed-off-by: Tim Harvey 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - no changes
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - added Vladimir's rb tag
v2: new patch
---
 net/dsa-uclass.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 5759cedcbec3..211a991cdd0d 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -342,6 +342,19 @@ U_BOOT_DRIVER(dsa_port) = {
.plat_auto = sizeof(struct eth_pdata),
 };
 
+static int dsa_sanitize_ops(struct udevice *dev)
+{
+   struct dsa_ops *ops = dsa_get_ops(dev);
+
+   if ((!ops->xmit || !ops->rcv) &&
+   (!ops->port_enable && !ops->port_disable)) {
+   dev_err(dev, "Packets cannot be steered to ports\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /*
  * This function mostly deals with pulling information out of the device tree
  * into the pdata structure.
@@ -358,6 +371,10 @@ static int dsa_post_bind(struct udevice *dev)
if (!ofnode_valid(node))
return -ENODEV;
 
+   err = dsa_sanitize_ops(dev);
+   if (err)
+   return err;
+
pdata->master_node = ofnode_null();
 
node = ofnode_find_subnode(node, "ports");
-- 
2.25.1



[PATCH v8 0/8] Add MV88E6xxx DSA driver and use on gwventana

2022-10-27 Thread Tim Harvey
This series adds a DSA driver for the MV88E6xxx based on
drivers/net/phy/mv88e61xx and uses it in the gwventana_gw5904_defconfig.

The hope is that the other three boards that use the MV88E61xx driver
can move to this as well eventually so that we can remove the non-dm
driver and the 4 Kconfig options it requires.

The MV88E6xxx has an MDIO interface thus DM_MDIO must be used so support
for a UCLASS_MDIO driver is added to the fec_mxc ethernet driver in a
way that allows a fallback to the previous non DM_MDIO case as there are
many boards out there using this driver that define DM_MDIO but do not
have the required dt props for a DM_MDIO driver which would cause a
regression.

Additionally some other patches are here suggested by Vladimir:
 - ensure MDIO children are scanned on post-bind is needed
 - sanity check DSA driver required ops are present
 - allow DSA drivers to not require xmit/recv functions
 - remove unecessary xmit/recv functions from ksz9477 driver

v8:
 - en remove energy-detect low-power mode config
 - add phy-mode internal dt prop to phy ports

v7:
 - rebase on master
 - update commit short msg (s/MV88E61xx/MV88E6xxx)
 - replace inline smi_cmd* with macros using logical operators
 - replace bitfield_replace with logical operators for readibility
 - removed some unused register definitions
 - config switch based SERDES mode once in probe vs port_enable
 - rework port_enable to clean up and:
  - enable energy-detect for all non fixed PHY ports
  - configure RGMII delays based on interface type
 - add Vladimir's rb tag to patch 8

v6:
 - update commit messages
 - squash accidently change to mv88e6xxx driver into previous patch
 - remove unused dt label for cpu port
 - removed unnecessary semicolon
 - update commit msg (s/MV88E61xx/MV88E6xxx)
 - remove GbE from commit msg and Kconfig desc
 - squash accidental change from patch 7 into patch 6
 - added error print on failure to read switch id
 - mv88e6xxx_probe:
  - check for switch enabled
  - remove unused variable enabled
  - remove unnecessary call to dsa_set_tagging
 - port_probe:
  - new function to configure phy features by calling phy_config
 - port_enable:
  - only enable energy-detect sensing on phy ports
  - add phy/cmode verification mistmatch warning
  - remove mv88e6xxx_fixed_port_setup()
  - always force link up for fixed ports
  - always set SERDES mode regardless of cpu port
  - remove unnecessary setting of CPUDEST
 - port_disable:
  - remove pointless error check
 - removed unnecessary priv data for mdio controller
 - fix indentation
 - change variable name for clarity

v5:
 - fix typo in defconfig update
 - added support for MV88E6320
 - added Fabio's rb tag

v4:
 - use standard Linux internal MDIO dt structure
 - use PHY_FIXED_ID define
 - rename to mv88e6xxx
 - sort includes alphabetically
 - remove dsa term from function names
 - reduce indentation level and remove unecessary code in of probe_mdio
   function
 - rename pdev to mdev to represent mdio device

v3:
 - fix mdios node in dt
 - add Vladimir's rb tag's

v2:
 - added Ramon's rb tag's to first two patches
 - add patches for dsa-uclass to sanity check ops and make xmit/recv
   optional
 - fec: fix fallback for non conforming DM_MDIO dts
 - mv88e61xx:
  - rebase on v2022.07-rc2 (use ofnode_get_phy_node)
  - remove unused commented out fields from struct
  - remove unused PORT_MASK macro
  - remove phy from priv struct name
  - refactor code from original drivers/net/phy/mv88e61xx with
suggestions from review to consolidate some functions
into mv88e61xx_dsa_port_enable
  - remove unecessary skiping of disabling of CPU port
  - remove unecessary dev_set_parent_priv
  - remove unnecessary static init flag
  - replace debug with a dev_warn if switch device-id unsupported
  - remove unnecessary xmit/recv functions as we rely on the fact that
only a single port is active instead of mangling packets

Tested on a Gateworks GW5904 which has a Marvell 88E6176 switch hanging
off the IMX6 FEC.

Best Regards,

Tim

Tim Harvey (8):
  net: mdio-uclass: scan for dm mdio children on post-bind
  net: dsa: move cpu port probe to dsa_post_probe
  net: dsa: ensure dsa driver has proper ops
  net: dsa: allow rcv() and xmit() to be optional
  net: ksz9477: remove unnecessary xmit and recv functions
  net: fec: add support for DM_MDIO
  net: add MV88E6xxx DSA driver
  board: gw_ventana: enable MV88E61XX DSA support

 arch/arm/dts/imx6qdl-gw5904.dtsi|  36 +-
 board/gateworks/gw_ventana/gw_ventana.c |  50 +-
 configs/gwventana_gw5904_defconfig  |   7 +-
 drivers/net/Kconfig |   7 +
 drivers/net/Makefile|   1 +
 drivers/net/fec_mxc.c   |  90 ++-
 drivers/net/ksz9477.c   |  23 -
 drivers/net/mv88e6xxx.c | 755 
 net/dsa-uclass.c|  55 +-
 net/mdio-uclass.c   |   4 +
 10 files changed, 956 insertions(+), 72 deletions(-)
 

[PATCH v8 1/8] net: mdio-uclass: scan for dm mdio children on post-bind

2022-10-27 Thread Tim Harvey
If a DM_MDIO driver is used we need to scan the subnodes as well.

Signed-off-by: Tim Harvey 
Signed-off-by: Vladimir Oltean 
Reviewed-by: Ramon Fried 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - no changes
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - no changes
v2:
 - added Ramon's rb tag
---
 net/mdio-uclass.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 4401492ca015..d80037d0ac71 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -49,7 +49,11 @@ static int dm_mdio_post_bind(struct udevice *dev)
return -EINVAL;
}
 
+#if CONFIG_IS_ENABLED(OF_REAL)
+   return dm_scan_fdt_dev(dev);
+#else
return 0;
+#endif
 }
 
 int dm_mdio_read(struct udevice *mdio_dev, int addr, int devad, int reg)
-- 
2.25.1



[PATCH v8 2/8] net: dsa: move cpu port probe to dsa_post_probe

2022-10-27 Thread Tim Harvey
In order to ensure that a DSA driver probe gets called before
dsa_ops->port_probe move the port_probe of the cpu_port to
a post-probe function.

Signed-off-by: Tim Harvey 
Reviewed-by: Ramon Fried 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Fabio Estevam 
---
v8:
 - no changes
v7:
 - no changes
v6:
 - removed unnecessary semicolon
v5:
 - added Fabio's rb tag
v4:
 - no changes
v3:
 - added Vladimir's rb tag
v2:
 - added Ramon's rb tag
---
 net/dsa-uclass.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 5b7046432ff3..5759cedcbec3 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -466,7 +466,6 @@ static int dsa_pre_probe(struct udevice *dev)
 {
struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
struct dsa_priv *priv = dev_get_uclass_priv(dev);
-   struct dsa_ops *ops = dsa_get_ops(dev);
int err;
 
priv->num_ports = pdata->num_ports;
@@ -482,6 +481,15 @@ static int dsa_pre_probe(struct udevice *dev)
if (err)
return err;
 
+   return 0;
+}
+
+static int dsa_post_probe(struct udevice *dev)
+{
+   struct dsa_priv *priv = dev_get_uclass_priv(dev);
+   struct dsa_ops *ops = dsa_get_ops(dev);
+   int err;
+
/* Simulate a probing event for the CPU port */
if (ops->port_probe) {
err = ops->port_probe(dev, priv->cpu_port,
@@ -498,6 +506,7 @@ UCLASS_DRIVER(dsa) = {
.name = "dsa",
.post_bind = dsa_post_bind,
.pre_probe = dsa_pre_probe,
+   .post_probe = dsa_post_probe,
.per_device_auto = sizeof(struct dsa_priv),
.per_device_plat_auto = sizeof(struct dsa_pdata),
.per_child_plat_auto = sizeof(struct dsa_port_pdata),
-- 
2.25.1



Re: [PATCH v7 7/8] net: add MV88E6xxx DSA driver

2022-10-27 Thread Vladimir Oltean
On Wed, Oct 26, 2022 at 01:59:19PM -0700, Tim Harvey wrote:
> not sure honestly - it's in the original drivers/net/phy/mv88e61xxx.c
> driver that I based this one off of.

You keep saying this; it doesn't matter where it comes from, the point
is whether it's useful to keep it in a new driver or not...

> From the functional spec of the 88E6176:
> - energy detect mode1 (what I'm doing here):
> only the signal detection circuitry and the serial management
> interface are active. If the PHY detects energy on the line, it starts
> to Auto-Negotiate sending FLPs for 5 seconds. If at the end of 5
> seconds the Auto-Negotiation is not completed, then the PHY stops
> sending FLPs and goes back to monitoring receive energy. If
> Auto-Negotation is completed, then the PHY goes into normal
> 10/100/1000 MBps operation. If during normal operation the link is
> lost, the PHY will re-start Auto-Negotiation. If no energy is detected
> after 5 seconds, the PHY goes back to monitoring receive energy.
> - energy detect mode2 (appears to be the power-on default):
> The PHY sends out a single 10Mbps NLP (Normal Link Pulse) every on
> second. Except for this difference, Mode 2 is identical to Mode 1
> operation. If the device is in Mode 1, it cannot wake up a connected
> device; therefore, the connected device must be transmitting NLPs, or
> either device must be woken up through register access. If the device
> is in Mode 2, then it can wake a connected device.
> - energy detect disabled:
> Normal 10/100/1000 mbps operation
> 
> You bring up a great point regarding the Marvell PHY driver not doing
> this... I'm happy to kill it off?

Ah, ok, it's a low power mode.

That being said, it seems like Marvell is saying: hey, we offer you the
ability to save power (when the PHY should be up) by disabling much of
the PHY circuitry, just leave on some signal detection circuit.
We certainly won't be emitting any NLP such that the link partner will
know the link is up. You go first and then we'll respond!

I wonder what happens if you connect 2 Marvell PHY ports with Energy
Detect to each other... the link shouldn't come up, right?

I absolutely think that this setting has no purpose in a bootloader driver.
Just a potential pain point. You want the bootloader networking to be
bullet proof.

Kill it!

[PATCH] ARM: stm32: Add boot counter to DHSOM

2022-10-27 Thread Marek Vasut
Add boot counter to STM32MP15xx DHSOM. This aligns the software with
other upstream DHSOM products which already do enable boot counter.

The boot counter on STM32MP15xx is placed in the TAMP block TAMP_BKPxR
register 19, right past register 17 and 18 used for CM4 resource table
and state by the Linux kernel. The TAMP_BKPxR register block is used
because its contents survives warm reset, but not cold reset.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 configs/stm32mp15_dhcom_basic_defconfig | 5 +
 configs/stm32mp15_dhcor_basic_defconfig | 5 +
 2 files changed, 10 insertions(+)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index 3ba396b9671..c8093c4e152 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -8,6 +8,8 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp15xx-dhcom-pdk2"
 CONFIG_SPL_TEXT_BASE=0x2FFC2500
 CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_SPL_MMC=y
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_ADDR=0x5C00A14C
 CONFIG_SPL=y
 CONFIG_TARGET_DH_STM32MP1_PDK2=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -74,6 +76,7 @@ CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_SYS_DISABLE_AUTOLOAD=y
+CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
@@ -99,6 +102,8 @@ CONFIG_IP_DEFRAG=y
 CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_SYS_BOOTCOUNT_MAGIC=0xB0C4
 CONFIG_DFU_MMC=y
 CONFIG_DFU_MTD=y
 CONFIG_DFU_RAM=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index ddd96ac4d29..7b2b92e15e3 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -8,6 +8,8 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp15xx-dhcor-avenger96"
 CONFIG_SPL_TEXT_BASE=0x2FFC2500
 CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_SPL_MMC=y
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_ADDR=0x5C00A14C
 CONFIG_SPL=y
 CONFIG_TARGET_DH_STM32MP1_PDK2=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -72,6 +74,7 @@ CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_SYS_DISABLE_AUTOLOAD=y
+CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
@@ -96,6 +99,8 @@ CONFIG_IP_DEFRAG=y
 CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_SYS_BOOTCOUNT_MAGIC=0xB0C4
 CONFIG_DFU_MMC=y
 CONFIG_DFU_MTD=y
 CONFIG_DFU_RAM=y
-- 
2.35.1



Re: [PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices

2022-10-27 Thread Tom Rini
On Thu, Oct 27, 2022 at 11:22:52AM -0400, Detlev Casanova wrote:

> In commit d0399a46e7cda63c07e3eb8558bef84cfb068028, the device tree was
> synchronized from linux and the aliases were dropped.
> 
> They need to be kept so that the mmc cards are in the right order.
> Without the aliases, u-boot reports:
> MMC:   FSL_SDHC: 2, FSL_SDHC: 3
> 
> With the aliases, u-boot reports:
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> 
> Signed-off-by: Detlev Casanova 
> ---
>  arch/arm/dts/imx6qdl-sabrelite.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/dts/imx6qdl-sabrelite.dtsi 
> b/arch/arm/dts/imx6qdl-sabrelite.dtsi
> index 22f8e2783c..6564e3b82c 100644
> --- a/arch/arm/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/dts/imx6qdl-sabrelite.dtsi
> @@ -10,6 +10,13 @@
>  #include 
>  
>  / {
> + aliases {
> + mmc0 = &usdhc3;
> + mmc1 = &usdhc4;
> + pwm_lcd = &pwm1;
> + pwm_lvds = &pwm4;
> + };
> +
>   chosen {
>   stdout-path = &uart2;
>   };

This really belongs in the upstream dts file so they aren't lost again
and again.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] cli: always show cursor

2022-10-27 Thread Heinrich Schuchardt




On 10/27/22 17:22, Simon Glass wrote:

Hi Heinrich,

On Wed, 26 Oct 2022 at 00:13, Heinrich Schuchardt
 wrote:




On 10/26/22 01:35, Simon Glass wrote:

Hi Heinrich,

On Sat, 22 Oct 2022 at 03:21, Heinrich Schuchardt
 wrote:


We may enter the command line interface in a state where on the remote
console the cursor is not shown. Send an escape sequence to enable it.

Signed-off-by: Heinrich Schuchardt 
---
   common/main.c | 4 
   1 file changed, 4 insertions(+)

diff --git a/common/main.c b/common/main.c
index 682f3359ea..4e7e7b17d6 100644
--- a/common/main.c
+++ b/common/main.c
@@ -7,6 +7,7 @@
   /* #define DEBUG   */

   #include 
+#include 
   #include 
   #include 
   #include 
@@ -66,6 +67,9 @@ void main_loop(void)

  autoboot_command(s);

+   if (!CONFIG_IS_ENABLED(DM_VIDEO) || CONFIG_IS_ENABLED(VIDEO_ANSI))
+   printf(ANSI_CURSOR_SHOW "\n");


Could we create a library which emits these codes? Like ansi_cursor_show() ?


The question is not if we could but if we should.

Up to now we tried to call printf() only once where ANSI_* is only one
part of the output string.

E.g. cmd/eficonfig.c:415:
  printf(ANSI_CLEAR_CONSOLE
 ANSI_CURSOR_POSITION
 ANSI_CURSOR_SHOW, 1, 1);

This minimizes the number of call library calls but may not be very elegant.

Creating a library function for ANSI_CURSOR_SHOW alone does not make
much sense to me. Should you want to convert our code base from using
ANSI_* to library functions this should cover the whole code base.

So I think we should let this patch pass as it solves a current problem
and leave creating a ANSI_* function library to a separate exercise.


Then we should add this to the serial API...what we have here is quite
bizarre in a way, since it outputs escape characters as the default
for U-Boot. Mostly we don't need it.

So add a set_cursor_visible() method to the serial API and allow it to
be controlled via platform data in the serial driver.


I have no clue which platform data you might be thinking of.

It is also not my intention to eject the escape sequence whenever a 
serial console is probed.


Using serial_puts() in this patch instead of printf() would help to 
avoid the CONFIG dependency.


Best regards

Heinrich



Regards,
SImon


Re: imx8 regression: cyclic_register for watchdog@30280000 failed

2022-10-27 Thread Tim Harvey
On Wed, Oct 26, 2022 at 11:32 PM Stefan Roese  wrote:
>
> Tim,
>
> On 26.10.22 21:06, Tim Harvey wrote:
> > On Wed, Oct 26, 2022 at 5:33 AM Rasmus Villemoes
> >  wrote:
> >>
> >> On 25/10/2022 18.32, Tim Harvey wrote:
> >>> Greetings,
> >>>
> >>> I've noticed a regression since the merge of the cyclic framework use
> >>> for watchdog on my imx8m boards:
> >>>
> >>> cyclic_register for watchdog@3028 failed
> >>> WDT:   Failed to start watchdog@3028
> >>>
> >>> A bisect lead me to the following 3 sequential patches:
> >>> 29caf9305b6f cyclic: Use schedule() instead of WATCHDOG_RESET()
> >>> ^^^ bad
> >>> 881d4108257a cyclic: Introduce schedule() function
> >>> ^^^ unbuildable
> >>> c2fd0ca1a822 watchdog: Integrate watchdog triggering into the cyclic 
> >>> framework
> >>> ^^^ unbootable
> >>
> >> Can you provide some more details on "unbootable" and "unbuildable"?
> >> I.e., what build error do you get for the middle patch, and what do you
> >> see on the console with the "unbootable" image?
> >
> > Rasmus,
> >
> > Sure. I'm building and testing for imx8mm_venice.
> >
> > Here are the patches in question listed in commit order:
> > d219fc06b30d configs: Resync with savedefconfig
> > ^^^ no issues found
> >
> > c2fd0ca1a822 watchdog: Integrate watchdog triggering into the cyclic 
> > framework
> > ^^^ unbootable for imx8mm_venice - hangs after SPL banner:
> > U-Boot SPL 2022.10-rc3-00241-gc2fd0ca1a822 (Oct 26 2022 - 10:08:54 -0700)
> > ^^^ this occurs because 'uclass_get_device_by_driver(UCLASS_MISC,
> > DM_DRIVER_GET(gsc), &dev))' in gateworks/venice/spl.c board_init_f
> > hangs and I'm not clear why this patch affects that
> >
> > 881d4108257a cyclic: Introduce schedule() function
> > ^^^ unbuildable for imx8mm_venice_defconfig
> >   CC  arch/arm/lib/sections.o
> > In file included from include/asm-generic/global_data.h:23,
> >   from ./arch/arm/include/asm/global_data.h:102,
> >   from include/dm/of.h:11,
> >   from include/dm/ofnode.h:12,
> >   from include/dm/device.h:13,
> >   from include/linux/mtd/mtd.h:26,
> >   from include/nand.h:17,
> >   from cmd/bootm.c:17:
> > include/cyclic.h:116:19: error: macro "schedule" passed 1 arguments, but 
> > takes j
> > ust 0
> >   void schedule(void);
> >
> > 29caf9305b6f cyclic: Use schedule() instead of WATCHDOG_RESET()
> > ^^^ build issue resolved, boot issue on imx8mm-venice resolved, but
> > this is where we now encounter watchdog failures in both the SPL and
> > U-Boot:
> >
> > SPL:
> > cyclic_register for watchdog@3028 failed
> > WDT:   Failed to start watchdog@3028
> >
> > The failure here is 'Cyclic IF not ready yet' (which should probably
> > be an error print not a debug print).
>
> Ye, makes sense. I'll change this.
>
> > In this case the watchdog gets
> > started but never reset via cyclic. This is due to cyclic_init never
> > being called in the SPL - where is that supposed to occur?
>
> I did not have many targets with WDT in SPL to test with. Seems that
> I missed to call into cyclic_init() here.
>
> > U-Boot:
> > cyclic function watchdog@3028 took too long: 2976us vs 1000us max, 
> > disabling
> >
> > Here also the watchdog gets started but never reset via cyclic so the
> > board will reset itself after 60s sitting in U-Boot for example.
>
> This is already changed in master since yesterday. Now only a warning
> will be shown upon long execution time but the function will not
> be disabled. So please re-check with master and report if this
> works better.

confirmed - the cyclic call no longer gets cancelled and its now just a warning

>
> > The issue here is that for some reason the first call to wdt_cyclic()
> > takes about 3ms vs subsequent calls taking about 185us on this
> > platform which exceeds the 1ms default max of
> > CONFIG_CYCLIC_MAX_CPU_TIME_US and thus the watchdog reset is disabled
> > and the board resets in 60s. Setting
> > CONFIG_CYCLIC_MAX_CPU_TIME_US=5000 resolves that issue but this feels
> > like a workaround that perhaps shouldn't be required.
>
> I agree.

Sounds like Rasmus is going to spin a patch for this but at least now
it's just a warning message.

>
> > I assume the
> > extra time in the first call is the probing of the device. So I think
> > the fix for this U-Boot regression is to move the init part of
> > wdt_cyclic to wdt_start() and have wdt_cyclic() only call wdt_reset()
> >
> > Fabio, I assume you see this on other imx8m boards?
> >
> >> Also, the .configs used in each case might be interesting, certainly all
> >> lines containing CYCLIC, WATCHDOG or WDT.
> >>
> >
> > $ grep CYCLIC .config
> > CONFIG_CYCLIC=y
> > CONFIG_CYCLIC_MAX_CPU_TIME_US=1000
> > # CONFIG_CMD_MX_CYCLIC is not set
> > CONFIG_CMD_CYCLIC=y
> > $ grep WATCHDOG .config
> > CONFIG_SPL_WATCHDOG=y
> > CONFIG_SYSRESET_WATCHDOG=y
> > # CONFIG_SYSRESET_WATCHDOG_AUTO is not set
> > CONFIG_WATCHDOG=y
> > CONFIG_WATCHD

[PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices

2022-10-27 Thread Detlev Casanova
In commit d0399a46e7cda63c07e3eb8558bef84cfb068028, the device tree was
synchronized from linux and the aliases were dropped.

They need to be kept so that the mmc cards are in the right order.
Without the aliases, u-boot reports:
MMC:   FSL_SDHC: 2, FSL_SDHC: 3

With the aliases, u-boot reports:
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Signed-off-by: Detlev Casanova 
---
 arch/arm/dts/imx6qdl-sabrelite.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/dts/imx6qdl-sabrelite.dtsi
index 22f8e2783c..6564e3b82c 100644
--- a/arch/arm/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/dts/imx6qdl-sabrelite.dtsi
@@ -10,6 +10,13 @@
 #include 
 
 / {
+   aliases {
+   mmc0 = &usdhc3;
+   mmc1 = &usdhc4;
+   pwm_lcd = &pwm1;
+   pwm_lvds = &pwm4;
+   };
+
chosen {
stdout-path = &uart2;
};
-- 
2.38.1



Re: [PATCH 1/1] cli: always show cursor

2022-10-27 Thread Simon Glass
Hi Heinrich,

On Wed, 26 Oct 2022 at 00:13, Heinrich Schuchardt
 wrote:
>
>
>
> On 10/26/22 01:35, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sat, 22 Oct 2022 at 03:21, Heinrich Schuchardt
> >  wrote:
> >>
> >> We may enter the command line interface in a state where on the remote
> >> console the cursor is not shown. Send an escape sequence to enable it.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>   common/main.c | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/common/main.c b/common/main.c
> >> index 682f3359ea..4e7e7b17d6 100644
> >> --- a/common/main.c
> >> +++ b/common/main.c
> >> @@ -7,6 +7,7 @@
> >>   /* #define DEBUG   */
> >>
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -66,6 +67,9 @@ void main_loop(void)
> >>
> >>  autoboot_command(s);
> >>
> >> +   if (!CONFIG_IS_ENABLED(DM_VIDEO) || CONFIG_IS_ENABLED(VIDEO_ANSI))
> >> +   printf(ANSI_CURSOR_SHOW "\n");
> >
> > Could we create a library which emits these codes? Like ansi_cursor_show() ?
>
> The question is not if we could but if we should.
>
> Up to now we tried to call printf() only once where ANSI_* is only one
> part of the output string.
>
> E.g. cmd/eficonfig.c:415:
>  printf(ANSI_CLEAR_CONSOLE
> ANSI_CURSOR_POSITION
> ANSI_CURSOR_SHOW, 1, 1);
>
> This minimizes the number of call library calls but may not be very elegant.
>
> Creating a library function for ANSI_CURSOR_SHOW alone does not make
> much sense to me. Should you want to convert our code base from using
> ANSI_* to library functions this should cover the whole code base.
>
> So I think we should let this patch pass as it solves a current problem
> and leave creating a ANSI_* function library to a separate exercise.

Then we should add this to the serial API...what we have here is quite
bizarre in a way, since it outputs escape characters as the default
for U-Boot. Mostly we don't need it.

So add a set_cursor_visible() method to the serial API and allow it to
be controlled via platform data in the serial driver.

Regards,
SImon


Re: [PATCH] dm: pmic: ignore disabled node in pmic_bind_children

2022-10-27 Thread Simon Glass
On Wed, 26 Oct 2022 at 07:05, Patrick Delaunay
 wrote:
>
> Ignore the disabled children node in pmic_bind_children() so the
> disabled regulators in device tree are not registered.
>
> This patch is based on the dm_scan_fdt_node() code - only the
> activated nodes are bound -  and it solves possible issue when a
> deactivated regulator is bound, error for duplicated regulator name
> for example.
>
> Signed-off-by: Patrick Delaunay 
> ---
> This patch solves the errors for duplicated regulator names on STM32MP15x
> boards since the alignment with Linux device tree with the commit
> 9157a4ce36b18 ("ARM: dts: stm32: update SCMI dedicated file").
>
> When SCMI is activated in "-scmi.dts" device tree, the 3 regulators
> reg11, reg18, usb33 are duplicated (children of scmi_reguls and of
> pwr_regulators) even if the children of pwr_regulators are deactivated in
> the file arch/arm/dts/stm32mp15-scmi.dtsi.
>
>  drivers/power/pmic/pmic-uclass.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH 0/3] AM62x SK EVM DT Sync + OSPI Support

2022-10-27 Thread Dhruva Gole

On 27/10/22 20:23, Dhruva Gole wrote:

* Sync the AM62x DTS files with the linux kernel.
* Also add configs necessary to enable ospi in uboot
* Add support for booting from OSPI Flash.

All changes have been tested on the AM62x SK EVM and the board
successfully reached u-boot prompt using OSPI Flash:

```
U-Boot SPL 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:24:55
+0530)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
Trying to boot from SPI
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.7(release):v2.7.0-dirty
NOTICE:  BL31: Built : 00:19:16, Sep 24 2022

U-Boot SPL 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:25:21
+0530)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
Trying to boot from SPI


U-Boot 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:25:21 +0530)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  47 devices, 18 uclasses, devicetree: separate
MMC:   mmc@fa1: 0, mmc@fa0: 1, mmc@fa2: 2
Loading Environment from nowhere... OK
In:serial@280
Out:   serial@280
Err:   serial@280
Net:   No ethernet found.
Hit any key to stop autoboot:  0
```

Also the board was tested to boot till linux kernel after the DT sync
changes. Hence verifying that the changes are valid.
Additionally, it is also worth noting that this effort of syncing the DT 
with upstream linux kernel seems to have also gotten the am62x-sk evm's 
on-board emmc to work (which is mmc dev 0).


I have tested the same after booting to uboot prompt from the SD Card 
and then selecting mmc dev 0.


I tested erase, write and read operations and then compared the data 
written to and from the mmc dev 0 and the data remained intact.




Dhruva Gole (3):
   arm: dts: k3-am62x: sync dt with linux kernel
   arm: dts: Add OSPI support for AM62-SK
   configs: enable OSPI related configs in AM62x

  arch/arm/dts/k3-am62-main.dtsi   |  54 
  arch/arm/dts/k3-am62-mcu.dtsi|  28 +++
  arch/arm/dts/k3-am62.dtsi|   1 +
  arch/arm/dts/k3-am625-r5-sk.dts  |   5 +
  arch/arm/dts/k3-am625-sk-u-boot.dtsi |  24 ++
  arch/arm/dts/k3-am625-sk.dts | 354 +++
  configs/am62x_evm_a53_defconfig  |  19 ++
  configs/am62x_evm_r5_defconfig   |  22 ++
  8 files changed, 507 insertions(+)


--
Best regards,
Dhruva Gole
Texas Instruments Incorporated



Re: [PATCH v2] spi: spi-mem: ease checks in dtr_supports_op()

2022-10-27 Thread Dhruva Gole

Hi,

A gentle reminder to review the following patch:

spi: spi-mem: ease checks in dtr_supports_op()

https://lore.kernel.org/u-boot/20221025062036.383460-1-d-g...@ti.com/

Kindly merge if it looks okay.

On 25/10/22 11:50, Dhruva Gole wrote:

Remove the extra conditions that cause some cases to fail prematurely
like if the data number of bytes is odd. The controller can handle odd
number of bytes data read in DTR Mode. Don't fail supports op for this
condition. This change can also be justified by taking a look at the
equivalent code in the linux kernel (v6.0.3), in drivers/spi/spi-mem.c,
where such an even number of data bytes check is absent as well.
The presence of this even byte check causes supports op failure even if
the controller can indeed work in case of odd bytes data reads in
DTR (Dual Transfer Rate) mode in xSPI.
There have not been any sort of major bugs in the absence of this
particular supports_op check, so it is safe to discard this
check from here.

Signed-off-by: Dhruva Gole 
---
v1 of the patch had a relatively shorter commit body that did not
sufficiently describe and justify this patch. link to v1:
https://lore.kernel.org/u-boot/20221020083424.86848-1-d-g...@ti.com/

v2 has just updated the commit body while preserving the code changes from
earlier v1 patch. This tries to address the changes requested from Jagan Teki.

  drivers/spi/spi-mem.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 8e8995fc537f..eecc13bec90d 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -181,10 +181,6 @@ bool spi_mem_dtr_supports_op(struct spi_slave *slave,
if (op->dummy.nbytes && op->dummy.buswidth == 8 && op->dummy.nbytes % 2)
return false;
  
-	if (op->data.dir != SPI_MEM_NO_DATA &&

-   op->dummy.buswidth == 8 && op->data.nbytes % 2)
-   return false;
-
return spi_mem_check_buswidth(slave, op);
  }
  EXPORT_SYMBOL_GPL(spi_mem_dtr_supports_op);


--
Best regards,
Dhruva Gole
Texas Instruments Incorporated



Re: [PATCH] lib: fix buggy strcmp and strncmp

2022-10-27 Thread Tom Rini
On Wed, Oct 05, 2022 at 11:09:25AM +0200, Rasmus Villemoes wrote:

> There are two problems with both strcmp and strncmp:
> 
> (1) The C standard is clear that the contents should be compared as
> "unsigned char":
> 
>   The sign of a nonzero value returned by the comparison functions
>   memcmp, strcmp, and strncmp is determined by the sign of the
>   difference between the values of the first pair of characters (both
>   interpreted as unsigned char) that differ in the objects being
>   compared.
> 
> (2) The difference between two char (or unsigned char) values can
> range from -255 to +255; so that's (due to integer promotion) the
> range of values we could get in the *cs-*ct expressions, but when that
> is then shoe-horned into an 8-bit quantity the sign may of course
> change.
> 
> The impact is somewhat limited by the way these functions
> are used in practice:
> 
> - Most of the time, one is only interested in equality (or for
>   strncmp, "starts with"), and the existing functions do correctly
>   return 0 if and only if the strings are equal [for strncmp, up to
>   the given bound].
> 
> - Also most of the time, the strings being compared only consist of
>   ASCII characters, i.e. have values in the range [0, 127], and in
>   that case it doesn't matter if they are interpreted as signed or
>   unsigned char, and the possible difference range is bounded to
>   [-127, 127] which does fit the signed char.
> 
> For size, one could implement strcmp() in terms of strncmp() - just
> make it "return strncmp(a, b, (size_t)-1);". However, performance of
> strcmp() does matter somewhat, since it is used all over when parsing
> and matching DT nodes and properties, so let's find some other place
> to save those ~30 bytes.
> 
> Signed-off-by: Rasmus Villemoes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 3/3] configs: enable OSPI related configs in AM62x

2022-10-27 Thread Dhruva Gole
Add am62x_evm_r5_defconfig for OSPI Flash support in R5 SPL
and am62x_evm_a53_defconfig for A53 SPL and U-Boot
support.
These configs enable OSPI Flash boot functionality in the board as well
as the usage of OSPI Flash from U-Boot.

Signed-off-by: Dhruva Gole 
---
 configs/am62x_evm_a53_defconfig | 19 +++
 configs/am62x_evm_r5_defconfig  | 22 ++
 2 files changed, 41 insertions(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index ff258bcbc102..e6ffd166927a 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -14,6 +14,7 @@ CONFIG_SPL_SERIAL=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
@@ -31,7 +32,14 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
 CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_SPL_DM_SPI_FLASH=y
 CONFIG_SPL_POWER_DOMAIN=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_SYS_BOOTM_LEN=0x80
 CONFIG_CMD_MMC=y
@@ -56,6 +64,14 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_SPL_MMC_SDHCI_ADMA=y
 CONFIG_MMC_SDHCI_AM654=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SF_DEFAULT_MODE=0x3
+CONFIG_SF_DEFAULT_SPEED=2500
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HS512T=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
@@ -69,6 +85,9 @@ CONFIG_DM_SERIAL=y
 CONFIG_SOC_DEVICE=y
 CONFIG_SOC_DEVICE_TI_K3=y
 CONFIG_SOC_TI=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
index 20172557ef4a..f95bc5f22218 100644
--- a/configs/am62x_evm_r5_defconfig
+++ b/configs/am62x_evm_r5_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_K3=y
+CONFIG_SYS_MALLOC_LEN=0x0800
 CONFIG_SYS_MALLOC_F_LEN=0x9000
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
@@ -17,6 +18,10 @@ CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_SIZE_LIMIT=0x4
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_SF_DEFAULT_SPEED=2500
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x7000
 CONFIG_SPL_LOAD_FIT=y
@@ -37,12 +42,17 @@ CONFIG_SYS_SPL_MALLOC_SIZE=0x100
 CONFIG_SPL_EARLY_BSS=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_DM_SPI_FLASH=y
 CONFIG_SPL_POWER_DOMAIN=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
 CONFIG_SPL_REMOTEPROC=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_ASKENV=y
@@ -91,6 +101,16 @@ CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_DM_SERIAL=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SF_DEFAULT_MODE=0
+CONFIG_SPI=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HS512T=y
 CONFIG_SOC_DEVICE=y
 CONFIG_SOC_DEVICE_TI_K3=y
 CONFIG_SOC_TI=y
@@ -99,3 +119,5 @@ CONFIG_SPL_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_LIB_RATIONAL=y
 CONFIG_SPL_LIB_RATIONAL=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
-- 
2.25.1



[PATCH 2/3] arm: dts: Add OSPI support for AM62-SK

2022-10-27 Thread Dhruva Gole
Add OSPI Support such that this device can boot up using OSPI Flash.
Also can use the flash for other purposes if required from uboot.

Signed-off-by: Dhruva Gole 
---
 arch/arm/dts/k3-am625-r5-sk.dts  |  5 +
 arch/arm/dts/k3-am625-sk-u-boot.dtsi | 24 
 2 files changed, 29 insertions(+)

diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 6d696e720de6..d39b334ed032 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -155,3 +155,8 @@
status = "okay";
u-boot,dm-spl;
 };
+
+&ospi0 {
+   reg = <0x00 0x0fc4 0x00 0x100>,
+ <0x00 0x6000 0x00 0x0800>;
+};
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index 159fa36bbe9f..92788bae3e09 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -102,3 +102,27 @@
 &main_mmc1_pins_default {
u-boot,dm-spl;
 };
+
+&fss {
+   u-boot,dm-spl;
+};
+
+&ospi0_pins_default {
+   u-boot,dm-spl;
+};
+
+&ospi0 {
+   u-boot,dm-spl;
+
+   flash@0 {
+   u-boot,dm-spl;
+
+   partitions {
+   u-boot,dm-spl;
+
+   partition@3fc {
+   u-boot,dm-spl;
+   };
+   };
+   };
+};
-- 
2.25.1



[PATCH 0/3] AM62x SK EVM DT Sync + OSPI Support

2022-10-27 Thread Dhruva Gole
* Sync the AM62x DTS files with the linux kernel.
* Also add configs necessary to enable ospi in uboot
* Add support for booting from OSPI Flash.

All changes have been tested on the AM62x SK EVM and the board
successfully reached u-boot prompt using OSPI Flash:

```
U-Boot SPL 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:24:55
+0530)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
Trying to boot from SPI
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.7(release):v2.7.0-dirty
NOTICE:  BL31: Built : 00:19:16, Sep 24 2022

U-Boot SPL 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:25:21
+0530)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
Trying to boot from SPI


U-Boot 2022.10-00677-g160b1b2cd007-dirty (Oct 27 2022 - 14:25:21 +0530)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  47 devices, 18 uclasses, devicetree: separate
MMC:   mmc@fa1: 0, mmc@fa0: 1, mmc@fa2: 2
Loading Environment from nowhere... OK
In:serial@280
Out:   serial@280
Err:   serial@280
Net:   No ethernet found.
Hit any key to stop autoboot:  0
```

Also the board was tested to boot till linux kernel after the DT sync
changes. Hence verifying that the changes are valid.

Dhruva Gole (3):
  arm: dts: k3-am62x: sync dt with linux kernel
  arm: dts: Add OSPI support for AM62-SK
  configs: enable OSPI related configs in AM62x

 arch/arm/dts/k3-am62-main.dtsi   |  54 
 arch/arm/dts/k3-am62-mcu.dtsi|  28 +++
 arch/arm/dts/k3-am62.dtsi|   1 +
 arch/arm/dts/k3-am625-r5-sk.dts  |   5 +
 arch/arm/dts/k3-am625-sk-u-boot.dtsi |  24 ++
 arch/arm/dts/k3-am625-sk.dts | 354 +++
 configs/am62x_evm_a53_defconfig  |  19 ++
 configs/am62x_evm_r5_defconfig   |  22 ++
 8 files changed, 507 insertions(+)

-- 
2.25.1



[PATCH 1/3] arm: dts: k3-am62x: sync dt with linux kernel

2022-10-27 Thread Dhruva Gole
Sync the DT Files with linux kernel (tag v6.0.3)

Signed-off-by: Dhruva Gole 
---
 arch/arm/dts/k3-am62-main.dtsi |  54 +
 arch/arm/dts/k3-am62-mcu.dtsi  |  28 +++
 arch/arm/dts/k3-am62.dtsi  |   1 +
 arch/arm/dts/k3-am625-sk.dts   | 354 +
 4 files changed, 437 insertions(+)

diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index 4b6ba98dd0a2..4a42f1b2e314 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -165,6 +165,19 @@
};
};
 
+   crypto: crypto@4090 {
+   compatible = "ti,am62-sa3ul";
+   reg = <0x00 0x4090 0x00 0x1200>;
+   power-domains = <&k3_pds 70 TI_SCI_PD_SHARED>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x00 0x4090 0x00 0x4090 0x00 0x3>;
+
+   dmas = <&main_pktdma 0xf501 0>, <&main_pktdma 0x7506 0>,
+  <&main_pktdma 0x7507 0>;
+   dma-names = "tx", "rx1", "rx2";
+   };
+
main_pmx0: pinctrl@f4000 {
compatible = "pinctrl-single";
reg = <0x00 0xf4000 0x00 0x2ac>;
@@ -530,4 +543,45 @@
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <16>;
};
+
+   ecap0: pwm@2310 {
+   compatible = "ti,am3352-ecap";
+   #pwm-cells = <3>;
+   reg = <0x00 0x2310 0x00 0x100>;
+   power-domains = <&k3_pds 51 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 51 0>;
+   clock-names = "fck";
+   };
+
+   ecap1: pwm@2311 {
+   compatible = "ti,am3352-ecap";
+   #pwm-cells = <3>;
+   reg = <0x00 0x2311 0x00 0x100>;
+   power-domains = <&k3_pds 52 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 52 0>;
+   clock-names = "fck";
+   };
+
+   ecap2: pwm@2312 {
+   compatible = "ti,am3352-ecap";
+   #pwm-cells = <3>;
+   reg = <0x00 0x2312 0x00 0x100>;
+   power-domains = <&k3_pds 53 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 53 0>;
+   clock-names = "fck";
+   };
+
+   main_mcan0: can@20701000 {
+   compatible = "bosch,m_can";
+   reg = <0x00 0x20701000 0x00 0x200>,
+ <0x00 0x20708000 0x00 0x8000>;
+   reg-names = "m_can", "message_ram";
+   power-domains = <&k3_pds 98 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 98 6>, <&k3_clks 98 1>;
+   clock-names = "hclk", "cclk";
+   interrupts = ,
+;
+   interrupt-names = "int0", "int1";
+   bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
+   };
 };
diff --git a/arch/arm/dts/k3-am62-mcu.dtsi b/arch/arm/dts/k3-am62-mcu.dtsi
index d103824c963f..f56c803560f2 100644
--- a/arch/arm/dts/k3-am62-mcu.dtsi
+++ b/arch/arm/dts/k3-am62-mcu.dtsi
@@ -53,4 +53,32 @@
power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 148 0>;
};
+
+   mcu_gpio_intr: interrupt-controller@421 {
+   compatible = "ti,sci-intr";
+   reg = <0x00 0x0421 0x00 0x200>;
+   ti,intr-trigger-type = <1>;
+   interrupt-controller;
+   interrupt-parent = <&gic500>;
+   #interrupt-cells = <1>;
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <5>;
+   ti,interrupt-ranges = <0 104 4>;
+   };
+
+   mcu_gpio0: gpio@4201000 {
+   compatible = "ti,am64-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x4201000 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&mcu_gpio_intr>;
+   interrupts = <30>, <31>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <24>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <&k3_pds 79 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 79 0>;
+   clock-names = "gpio";
+   };
 };
diff --git a/arch/arm/dts/k3-am62.dtsi b/arch/arm/dts/k3-am62.dtsi
index bc2997b18556..37fcbe7a3c33 100644
--- a/arch/arm/dts/k3-am62.dtsi
+++ b/arch/arm/dts/k3-am62.dtsi
@@ -66,6 +66,7 @@
 <0x00 0x3020 0x00 0x3020 0x00 0x0001>, /* 
DSS */
 <0x00 0x3100 0x00 0x3100 0x00 0x0005>, /* 
USB0 DWC3 Core window */
 <0x00 0x3110 0x00 0x3110 0x00 0x0005>, /* 
USB1 DWC3 Core window */
+<0x00 0x4090 0x00 0x4090 0x00 0x0003>, /* 
SA3UL */
 <0x00 0x4360 0x00 0x4360 0x00 0x0001>, /* 
SA3 sproxy data */
   

[PATCH v2] imx: imx8qm: imx8qm_mek switch to binman

2022-10-27 Thread Oliver Graute
Signed-off-by: Oliver Graute 
---
 arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 2 ++
 arch/arm/mach-imx/imx8/Kconfig  | 1 +
 board/freescale/imx8qm_mek/README   | 2 +-
 configs/imx8qm_2ek_defconfig| 2 ++
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi 
b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
index a95209e141..eefdccf992 100644
--- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
+++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
@@ -3,6 +3,8 @@
  * Copyright 2018, 2021 NXP
  */
 
+#include "imx8qm-u-boot.dtsi"
+
 &{/imx8qm-pm} {
 
u-boot,dm-spl;
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index 23a7fcf361..4ccbabf506 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -68,6 +68,7 @@ config TARGET_GIEDI
 
 config TARGET_IMX8QM_MEK
bool "Support i.MX8QM MEK board"
+   select BINMAN
select BOARD_LATE_INIT
select IMX8QM
select FSL_CAAM
diff --git a/board/freescale/imx8qm_mek/README 
b/board/freescale/imx8qm_mek/README
index 570ed7e210..b1a4c6cc82 100644
--- a/board/freescale/imx8qm_mek/README
+++ b/board/freescale/imx8qm_mek/README
@@ -40,7 +40,7 @@ And copy the following firmwares to U-Boot folder:
 Build U-Boot
 
 $ make imx8qm_mek_defconfig
-$ make flash.bin
+$ make
 
 Flash the binary into the SD card
 =
diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig
index b973b809be..25b51cf1ec 100644
--- a/configs/imx8qm_mek_defconfig
+++ b/configs/imx8qm_mek_defconfig
@@ -23,6 +23,8 @@ CONFIG_SYS_LOAD_ADDR=0x8028
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
 CONFIG_REMAKE_ELF=y
+CONFIG_FIT=y
+CONFIG_FIT_EXTERNAL_OFFSET=0x3000
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_BOOTDELAY=3
-- 
2.17.1



Re: [PATCH v1] imx: imx8qm: imx8qm_mek switch to binman

2022-10-27 Thread Oliver Graute
On 26/10/22, Peng Fan wrote:
> 
> 
> On 10/26/2022 4:09 PM, Oliver Graute wrote:
> > Signed-off-by: Oliver Graute 
> > ---
> >   arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 2 ++
> >   arch/arm/mach-imx/imx8/Kconfig  | 1 +
> >   board/freescale/imx8qm_mek/README   | 2 +-
> >   board/freescale/imx8qm_mek/imximage.cfg | 2 +-
> >   configs/imx8qm_mek_defconfig| 2 ++
> >   5 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi 
> > b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > index a95209e141..eefdccf992 100644
> > --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > @@ -3,6 +3,8 @@
> >* Copyright 2018, 2021 NXP
> >*/
> > +#include "imx8qm-u-boot.dtsi"
> > +
> 
> I think the build system would automatically include this.
> Please correct if I am wrong.

That's not the case if I remove the include I run into following error:

make[1]: Für das Ziel „SPL“ ist nichts zu tun.
  BINMAN  all
binman: Device tree 'u-boot.dtb' does not have a 'binman' node
Makefile:1109: recipe for target 'all' failed
make: *** [all] Error 1
> 
> >   &{/imx8qm-pm} {
> > u-boot,dm-spl;
> > diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
> > index 23a7fcf361..4ccbabf506 100644
> > --- a/arch/arm/mach-imx/imx8/Kconfig
> > +++ b/arch/arm/mach-imx/imx8/Kconfig
> > @@ -68,6 +68,7 @@ config TARGET_GIEDI
> >   config TARGET_IMX8QM_MEK
> > bool "Support i.MX8QM MEK board"
> > +   select BINMAN
> > select BOARD_LATE_INIT
> > select IMX8QM
> > select FSL_CAAM
> > diff --git a/board/freescale/imx8qm_mek/README 
> > b/board/freescale/imx8qm_mek/README
> > index 570ed7e210..b1a4c6cc82 100644
> > --- a/board/freescale/imx8qm_mek/README
> > +++ b/board/freescale/imx8qm_mek/README
> > @@ -40,7 +40,7 @@ And copy the following firmwares to U-Boot folder:
> >   Build U-Boot
> >   
> >   $ make imx8qm_mek_defconfig
> > -$ make flash.bin
> > +$ make
> >   Flash the binary into the SD card
> >   =
> > diff --git a/board/freescale/imx8qm_mek/imximage.cfg 
> > b/board/freescale/imx8qm_mek/imximage.cfg
> > index 71612678c9..46ca3bf817 100644
> > --- a/board/freescale/imx8qm_mek/imximage.cfg
> > +++ b/board/freescale/imx8qm_mek/imximage.cfg
> > @@ -5,7 +5,7 @@
> >   /* Boot from SD, sector size 0x400 */
> > -BOOT_FROM SD 0x400
> > +BOOT_FROM  sd
> 
> Why update this?

you are right its unneccessary, will fix it in v2
> 
> >   /* SoC type IMX8QM */
> >   SOC_TYPE IMX8QM
> >   /* Append seco container image */
> > diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig
> > index b973b809be..25b51cf1ec 100644
> > --- a/configs/imx8qm_mek_defconfig
> > +++ b/configs/imx8qm_mek_defconfig
> > @@ -23,6 +23,8 @@ CONFIG_SYS_LOAD_ADDR=0x8028
> >   CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
> >   CONFIG_REMAKE_ELF=y
> > +CONFIG_FIT=y
> > +CONFIG_FIT_EXTERNAL_OFFSET=0x3000
> >   CONFIG_OF_BOARD_SETUP=y
> >   CONFIG_OF_SYSTEM_SETUP=y
> >   CONFIG_BOOTDELAY=3
> 
> Regards,
> Peng.

Best Regards,

Oliver


Re: [PATCH 08/11] arm: dts: Add initial support for AM68 Starter Kit System on Module

2022-10-27 Thread Tom Rini
On Thu, Oct 27, 2022 at 04:18:43PM +0530, Sinthu Raja wrote:
> From: Sinthu Raja 
> 
> AM68 Starter Kit (SK) is a low cost, small form factor board designed
> for TI’s AM68 SoC. TI’s AM68 SoC comprises of dual core A72, high
> performance vision accelerators, hardware accelerators, latest C71x
> DSP, high bandwidth real-time IPs for capture and display. The SoC is
> power optimized to provide best in class performance for industrial
> applications.
> 
> AM68 SK supports the following interfaces:
> * 16 GB LPDDR4 RAM
> * x1 Gigabit Ethernet interface
> * x1 USB 3.1 Type-C port
> * x2 USB 3.1 Type-A ports
> * x1 PCIe M.2 M Key
> * 512 Mbit OSPI flash
> * x2 CSI2 Camera interface (RPi and TI Camera connector)
> * 40-pin Raspberry Pi GPIO header
> 
> SK's System on Module (SoM) contains the SoC, PMIC, DDR and OSPI flash.
> Therefore, add support for the components present on the SoM.
> 
> Schematics: https://www.ti.com/lit/zip/SPRR463
> TRM: http://www.ti.com/lit/pdf/spruj28
> 
> Signed-off-by: Sinthu Raja 
> ---
>  arch/arm/dts/k3-am68-sk-som.dtsi | 167 +++

What is the status of this dtsi file (and the ones in subsequent
patches) with upstream Linux? Please mention the tag they're synced from
in the commit message to make future updates easier.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 07/11] arm: j721s2: Add support for selecting DT based on EEPROM

2022-10-27 Thread Tom Rini
On Thu, Oct 27, 2022 at 04:18:42PM +0530, Sinthu Raja wrote:
> From: Sinthu Raja 
> 
> Enable support for selecting DTB from FIT within SPL based on the
> board name read from EEPROM. This will help to use single defconfig
> for both EVM and SK.
> 
> Signed-off-by: Sinthu Raja 
> ---
>  arch/arm/mach-k3/j721s2_init.c | 59 ++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
> index 12da8136f9..fc5eee03b6 100644
> --- a/arch/arm/mach-k3/j721s2_init.c
> +++ b/arch/arm/mach-k3/j721s2_init.c
> @@ -19,8 +19,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  static void ctrl_mmr_unlock(void)
>  {
> @@ -93,6 +95,59 @@ static void store_boot_info_from_rom(void)
>  sizeof(struct rom_extended_boot_data));
>  }
>  
> +#ifdef CONFIG_SPL_OF_LIST
> +void do_dt_magic(void)
> +{
> + int ret, rescan, mmc_dev = -1;
> + static struct mmc *mmc;
> +
> + if (IS_ENABLED(CONFIG_TI_I2C_BOARD_DETECT))
> + do_board_detect();

We need to try and avoid putting the CONFIG_TI_I2C_BOARD_DETECT calls
and checks in the generic mach-k3 code as it's not required nor likely
used on non-reference platforms. And again, if we do not need to move to
a board-specific DTB in SPL, we do not want to, we want to push that off
to full U-Boot.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 06/11] board: ti: j721s2: Add support for detecting multiple device trees

2022-10-27 Thread Tom Rini
On Thu, Oct 27, 2022 at 04:18:41PM +0530, Sinthu Raja wrote:
> From: Sinthu Raja 
> 
> Update the board_fit_config_name_match() to choose the right dtb
> based on the board name read from EEPROM.
> 
> Also restrict multpile EEPROM reads by verifying if EEPROM is already
> read
> 
> Signed-off-by: Sinthu Raja 
> ---
>  board/ti/j721s2/evm.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
> index 8ada924e3f..25667900ce 100644
> --- a/board/ti/j721s2/evm.c
> +++ b/board/ti/j721s2/evm.c
> @@ -79,8 +79,17 @@ int dram_init_banksize(void)
>  #ifdef CONFIG_SPL_LOAD_FIT
>  int board_fit_config_name_match(const char *name)
>  {
> - if (!strcmp(name, "k3-j721s2-common-proc-board"))
> - return 0;
> + bool eeprom_read = board_ti_was_eeprom_read();
> +
> + if (!eeprom_read || board_is_j721s2_som()) {
> + if (!strcmp(name, "k3-j721s2-common-proc-board") ||
> + !strcmp(name, "k3-j721s2-r5-common-proc-board"))
> + return 0;
> + } else if (!eeprom_read || board_is_am68_sk_som()) {
> + if (!strcmp(name, "k3-am68-sk-base-board") ||
> + !strcmp(name, "k3-am68-sk-r5-base-board"))
> + return 0;
> + }
>  
>   return -1;
>  }

Do we actually need a different DTB to be used in SPL, in order to get
the right DTB for full U-Boot? It's an intentional design decision here
that we go board-specific as late as possible, so that it's clearer for
custom designs what they do and do not need to modify.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 04/11] board: ti: j721s2: Add support to update board_name for am68-sk

2022-10-27 Thread Tom Rini
On Thu, Oct 27, 2022 at 04:18:39PM +0530, Sinthu Raja wrote:

> From: Sinthu Raja 
> 
> Update setup_board_eeprom_env() to choose the right board name
> for am68-sk.
> 
> Signed-off-by: Sinthu Raja 
> ---
>  board/ti/j721s2/evm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
> index e09adc8ad3..e3c75b35b6 100644
> --- a/board/ti/j721s2/evm.c
> +++ b/board/ti/j721s2/evm.c
> @@ -28,6 +28,8 @@
>  
>  #define board_is_j721s2_som()board_ti_k3_is("J721S2X-PM1-SOM")
>  
> +#define board_is_am68_sk_som() board_ti_k3_is("AM68-SK-SOM")
> +
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  int board_init(void)
> @@ -136,6 +138,8 @@ static void setup_board_eeprom_env(void)
>  
>   if (board_is_j721s2_som())
>   name = "j721s2";
> + else if (board_is_am68_sk_som())
> + name = "am68-sk";
>   else
>   printf("Unidentified board claims %s in eeprom header\n",
>  board_ti_get_name());

What I'd like to see is moving the board_is_XXX defines moved down to by
do_board_detect() and then a comment inside the start of that block to
explain that all of this functionality is specific to the EVM family
designs. This will hopefully make it clearer that when making a custom
board that doesn't have this EEPROM all of this can be omitted and we
don't loose the "mini" U-Boot concept for this SoC.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V2 01/13] env: Complete generic support for writable list

2022-10-27 Thread Jan Kiszka
On 27.10.22 09:49, Stefan Herbrechtsmeier wrote:
> Hi,
> 
> Am 05.10.2022 um 10:33 schrieb Jan Kiszka:
>> From: Jan Kiszka 
>>
>> This completes what 890feecaab72 started by selecting ENV_APPEND and
>> ENV_IS_NOWHERE and by moving this driver to top if the list. This
>> ensures that load operations pick up both the default env and the
>> permitted parts of the next-prio location. When writing though, we must
>> use the regular ordering.
>>
>> With this change, boards only need to define the list of writable
>> variables but no longer have to provide a custom env_get_location
>> implementation.
>>
>> CC: Joe Hershberger 
>> CC: Marek Vasut 
>> Signed-off-by: Jan Kiszka 
>> ---
>>   env/Kconfig |  2 ++
>>   env/env.c   | 22 ++
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/env/Kconfig b/env/Kconfig
>> index 24111dfaf47..05b5fbf17d1 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -715,6 +715,8 @@ config ENV_APPEND
>>     config ENV_WRITEABLE_LIST
>>   bool "Permit write access only to listed variables"
>> +    select ENV_IS_NOWHERE
>> +    select ENV_APPEND
>>   help
>>     If defined, only environment variables which explicitly set
>> the 'w'
>>     writeable flag can be written and modified at runtime. No
>> variables
>> diff --git a/env/env.c b/env/env.c
>> index 69848fb0608..d0649f9540d 100644
>> --- a/env/env.c
>> +++ b/env/env.c
>> @@ -133,6 +133,28 @@ __weak enum env_location
>> arch_env_get_location(enum env_operation op, int prio)
>>   if (prio >= ARRAY_SIZE(env_locations))
>>   return ENVL_UNKNOWN;
>>   +    if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {
>> +    /*
>> + * In writeable-list mode, ENVL_NOWHERE gains highest prio by
>> + * virtually injecting it at prio 0.
>> + */
>> +    if (prio == 0) {
>> +    /*
>> + * Avoid the injection for write operations as that
>> + * would block it.
>> + */
>> +    if (op != ENVOP_SAVE && op != ENVOP_ERASE)
>> +    return ENVL_NOWHERE;
> 
> Is it consensus now to use ENVL_NOWHERE as synonym for default
> environment? If I remember correct this was rejected in the past and
> ENVL_NOWHERE  should only be used if no enviroment is available.
> 
> Why don't you call env_set_default(NULL, 0) in env_load() before
> env_driver_lookup()?

Worth to explore... if that should avoid this logic here... Let me try.

Jan

> 
>> +    } else {
>> +    /*
>> + * always subtract 1, also for writing because
>> + * env_load_prio, which is used for writing, was
>> + * initialized with that offset.
>> + */
>> +    prio--;
>> +    }
>> +    }
>> +
>>   return env_locations[prio];
>>   }
>>   
> 
> Regards
> 
>   Stefan
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux



[PATCH 11/11] include: configs: Update env for selecting right dtb

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Now that single defconfig shall be used for booting J721S2 EVM and
AM68 SK, the default device tree will not work for selecting dtb for
kernel. Update the findfdt env to select right dtb based on
board_name env variable.

Signed-off-by: Sinthu Raja 
---
 include/configs/j721s2_evm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index 932d7d3c8c..715f03048a 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -32,6 +32,10 @@
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
"findfdt="  \
"setenv name_fdt ${default_device_tree};"   \
+   "if test $board_name = j721s2; then "   \
+   "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
+   "if test $board_name = am68-sk; then "  \
+   "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
-- 
2.36.1



[PATCH 10/11] arm: dts: k3-am68-sk: Add r5 specific dt support

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Add initial support for AM68 SK device tree that runs on R5.

Signed-off-by: Sinthu Raja 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/k3-am68-sk-r5-base-board.dts | 226 ++
 2 files changed, 227 insertions(+)
 create mode 100644 arch/arm/dts/k3-am68-sk-r5-base-board.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b1fcd20f39..6e9e4310d8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1222,6 +1222,7 @@ dtb-$(CONFIG_SOC_K3_J721E) += 
k3-j721e-common-proc-board.dtb \
  k3-j721e-sk.dtb \
  k3-j721e-r5-sk.dtb
 dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
+  k3-am68-sk-r5-base-board.dtb\
   k3-j721s2-common-proc-board.dtb\
   k3-j721s2-r5-common-proc-board.dtb
 dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
diff --git a/arch/arm/dts/k3-am68-sk-r5-base-board.dts 
b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
new file mode 100644
index 00..7d70d8ce81
--- /dev/null
+++ b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am68-sk-som.dtsi"
+#include "k3-j721s2-ddr-evm-lp4-4266.dtsi"
+#include "k3-j721s2-ddr.dtsi"
+
+/ {
+   chosen {
+   firmware-loader = &fs_loader0;
+   stdout-path = &main_uart8;
+   tick-timer = &timer1;
+   };
+
+   aliases {
+   remoteproc0 = &sysctrler;
+   remoteproc1 = &a72_0;
+   };
+
+   fs_loader0: fs_loader@0 {
+   compatible = "u-boot,fs-loader";
+   u-boot,dm-pre-reloc;
+   };
+
+   a72_0: a72@0 {
+   compatible = "ti,am654-rproc";
+   reg = <0x0 0x00a9 0x0 0x10>;
+   power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
+   <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>;
+   resets = <&k3_reset 202 0>;
+   clocks = <&k3_clks 61 1>;
+   assigned-clocks = <&k3_clks 61 1>, <&k3_clks 202 0>;
+   assigned-clock-parents = <&k3_clks 61 2>;
+   assigned-clock-rates = <2>, <20>;
+   ti,sci = <&sms>;
+   ti,sci-proc-id = <32>;
+   ti,sci-host-id = <10>;
+   u-boot,dm-spl;
+   };
+
+   clk_200mhz: dummy_clock_200mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   u-boot,dm-spl;
+   };
+
+   clk_19_2mhz: dummy_clock_19_2mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   u-boot,dm-spl;
+   };
+};
+
+&cbass_mcu_wakeup {
+   sa3_secproxy: secproxy@4488 {
+   u-boot,dm-spl;
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x0 0x4488 0x0 0x2>,
+ <0x0 0x4486 0x0 0x2>,
+ <0x0 0x4360 0x0 0x1>;
+   reg-names = "rt", "scfg", "target_data";
+   #mbox-cells = <1>;
+   };
+
+   mcu_secproxy: secproxy@2a38 {
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x0 0x2a38 0x0 0x8>,
+ <0x0 0x2a40 0x0 0x8>,
+ <0x0 0x2a48 0x0 0x8>;
+   reg-names = "rt", "scfg", "target_data";
+   #mbox-cells = <1>;
+   u-boot,dm-spl;
+   };
+
+   sysctrler: sysctrler {
+   compatible = "ti,am654-system-controller";
+   mboxes= <&mcu_secproxy 4>, <&mcu_secproxy 5>, <&sa3_secproxy 5>;
+   mbox-names = "tx", "rx", "boot_notify";
+   u-boot,dm-spl;
+   };
+
+   dm_tifs: dm-tifs {
+   compatible = "ti,j721e-dm-sci";
+   ti,host-id = <3>;
+   ti,secure-host;
+   mbox-names = "rx", "tx";
+   mboxes= <&mcu_secproxy 21>,
+   <&mcu_secproxy 23>;
+   u-boot,dm-spl;
+   };
+};
+
+&main_pmx0 {
+   main_uart8_pins_default: main-uart8-pins-default {
+   pinctrl-single,pins = <
+   J721S2_IOPAD(0x0d0, PIN_INPUT, 11) /* (AF26) 
SPI0_CS1.UART8_RXD */
+   J721S2_IOPAD(0x0d4, PIN_OUTPUT, 11) /* (AH27) 
SPI0_CLK.UART8_TXD */
+   >;
+   };
+
+   main_mmc1_pins_default: main-mmc1-pins-default {
+   pinctrl-single,pins = <
+   J721S2_IOPAD(0x104, PIN_INPUT, 0) /* (P23) MMC1_CLK */
+   J721S2_IOPAD(0x108, PIN_INPUT, 0) /* (N24) MMC1_CMD */
+   J721S2_IOPAD(0x100, PIN_INPUT, 0) /*

[PATCH 09/11] arm: dts: Add support for A72 specific AM68 Starter Kit Base Board

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

The SK architecture comprises of baseboard and a SOM board. The
AM68 Starter Kit's baseboard contains most of the actual connectors,
power supply etc. The System on Module (SoM) is plugged on to the base
board. Therefore, add support for peripherals brought out in the base
board.

Schematics: https://www.ti.com/lit/zip/SPRR463

Signed-off-by: Sinthu Raja 
---
 arch/arm/dts/Makefile |   3 +-
 .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 216 ++
 arch/arm/dts/k3-am68-sk-base-board.dts| 395 ++
 3 files changed, 613 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am68-sk-base-board.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9b00b64509..b1fcd20f39 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1221,7 +1221,8 @@ dtb-$(CONFIG_SOC_K3_J721E) += 
k3-j721e-common-proc-board.dtb \
  k3-j7200-r5-common-proc-board.dtb \
  k3-j721e-sk.dtb \
  k3-j721e-r5-sk.dtb
-dtb-$(CONFIG_SOC_K3_J721S2) += k3-j721s2-common-proc-board.dtb\
+dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
+  k3-j721s2-common-proc-board.dtb\
   k3-j721s2-r5-common-proc-board.dtb
 dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
  k3-am642-r5-evm.dtb \
diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
new file mode 100644
index 00..01e00862df
--- /dev/null
+++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+   chosen {
+   stdout-path = "serial2:115200n8";
+   tick-timer = &timer1;
+   };
+
+   aliases {
+   serial0 = &wkup_uart0;
+   serial1 = &mcu_uart0;
+   serial2 = &main_uart8;
+   i2c0 = &wkup_i2c0;
+   i2c1 = &mcu_i2c0;
+   i2c2 = &mcu_i2c1;
+   i2c3 = &main_i2c0;
+   ethernet0 = &cpsw_port1;
+   spi0 = &ospi0;
+   mmc1 = &main_sdhci1;
+   };
+};
+
+&wkup_i2c0 {
+   u-boot,dm-spl;
+};
+
+&cbass_main {
+   u-boot,dm-spl;
+};
+
+&main_navss {
+   u-boot,dm-spl;
+};
+
+&main_r5fss0 {
+   ti,cluster-mode = <0>;
+};
+
+&main_r5fss1 {
+   ti,cluster-mode = <0>;
+};
+
+&cbass_mcu_wakeup {
+   u-boot,dm-spl;
+
+   timer1: timer@4040 {
+   compatible = "ti,omap5430-timer";
+   reg = <0x0 0x4040 0x0 0x80>;
+   ti,timer-alwon;
+   clock-frequency = <25000>;
+   u-boot,dm-spl;
+   };
+
+   chipid@4314 {
+   u-boot,dm-spl;
+   };
+};
+
+&mcu_navss {
+   u-boot,dm-spl;
+};
+
+&mcu_ringacc {
+   reg =   <0x0 0x2b80 0x0 0x40>,
+   <0x0 0x2b00 0x0 0x40>,
+   <0x0 0x2859 0x0 0x100>,
+   <0x0 0x2a50 0x0 0x4>,
+   <0x0 0x2844 0x0 0x4>;
+   reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
+   u-boot,dm-spl;
+};
+
+&mcu_udmap {
+   reg =   <0x0 0x285c 0x0 0x100>,
+   <0x0 0x284c 0x0 0x4000>,
+   <0x0 0x2a80 0x0 0x4>,
+   <0x0 0x284a 0x0 0x4000>,
+   <0x0 0x2aa0 0x0 0x4>,
+   <0x0 0x2840 0x0 0x2000>;
+   reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+   "tchanrt", "rflow";
+   u-boot,dm-spl;
+};
+
+&secure_proxy_main {
+   u-boot,dm-spl;
+};
+
+&sms {
+   u-boot,dm-spl;
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   u-boot,dm-spl;
+   };
+};
+
+&main_pmx0 {
+   u-boot,dm-spl;
+};
+
+&main_uart8_pins_default {
+   u-boot,dm-spl;
+};
+
+&main_mmc1_pins_default {
+   u-boot,dm-spl;
+};
+
+&main_usbss0_pins_default {
+   u-boot,dm-spl;
+};
+
+&wkup_pmx0 {
+   u-boot,dm-spl;
+};
+
+&k3_pds {
+   u-boot,dm-spl;
+};
+
+&k3_clks {
+   u-boot,dm-spl;
+};
+
+&k3_reset {
+   u-boot,dm-spl;
+};
+
+&main_uart8 {
+   u-boot,dm-spl;
+};
+
+&mcu_uart0 {
+   u-boot,dm-spl;
+};
+
+&wkup_uart0 {
+   u-boot,dm-spl;
+};
+
+&fss {
+   u-boot,dm-spl;
+};
+
+&usbss0 {
+   u-boot,dm-spl;
+};
+
+&usb0 {
+   dr_mode = "peripheral";
+   u-boot,dm-spl;
+};
+
+&mcu_cpsw {
+   reg = <0x0 0x4600 0x0 0x20>,
+ <0x0 0x40f00200 0x0 0x8>;
+   reg-names = "cpsw_nuss", "mac_efuse";
+   /delete-property/ ranges;
+
+   cpsw-phy-sel@40f04040 {
+   compatible = "ti,am654-cpsw-phy-sel";
+   reg= <0x0 0x40f04040 0x0 0x

[PATCH 08/11] arm: dts: Add initial support for AM68 Starter Kit System on Module

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

AM68 Starter Kit (SK) is a low cost, small form factor board designed
for TI’s AM68 SoC. TI’s AM68 SoC comprises of dual core A72, high
performance vision accelerators, hardware accelerators, latest C71x
DSP, high bandwidth real-time IPs for capture and display. The SoC is
power optimized to provide best in class performance for industrial
applications.

AM68 SK supports the following interfaces:
* 16 GB LPDDR4 RAM
* x1 Gigabit Ethernet interface
* x1 USB 3.1 Type-C port
* x2 USB 3.1 Type-A ports
* x1 PCIe M.2 M Key
* 512 Mbit OSPI flash
* x2 CSI2 Camera interface (RPi and TI Camera connector)
* 40-pin Raspberry Pi GPIO header

SK's System on Module (SoM) contains the SoC, PMIC, DDR and OSPI flash.
Therefore, add support for the components present on the SoM.

Schematics: https://www.ti.com/lit/zip/SPRR463
TRM: http://www.ti.com/lit/pdf/spruj28

Signed-off-by: Sinthu Raja 
---
 arch/arm/dts/k3-am68-sk-som.dtsi | 167 +++
 1 file changed, 167 insertions(+)
 create mode 100644 arch/arm/dts/k3-am68-sk-som.dtsi

diff --git a/arch/arm/dts/k3-am68-sk-som.dtsi b/arch/arm/dts/k3-am68-sk-som.dtsi
new file mode 100644
index 00..b8bec1f335
--- /dev/null
+++ b/arch/arm/dts/k3-am68-sk-som.dtsi
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721s2.dtsi"
+#include 
+
+/ {
+   memory@8000 {
+   device_type = "memory";
+   /* 16 GB RAM */
+   reg = <0x00 0x8000 0x00 0x8000>,
+ <0x08 0x8000 0x03 0x8000>;
+   };
+
+   /* Reserving memory regions still pending */
+   reserved_memory: reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   secure_ddr: optee@9e80 {
+   reg = <0x00 0x9e80 0x00 0x0180>;
+   alignment = <0x1000>;
+   no-map;
+   };
+   };
+};
+
+&wkup_pmx0 {
+   mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
+   pinctrl-single,pins = <
+   J721S2_WKUP_IOPAD(0x000, PIN_OUTPUT, 0) /* (D19) 
MCU_OSPI0_CLK */
+   J721S2_WKUP_IOPAD(0x02c, PIN_OUTPUT, 0) /* (F15) 
MCU_OSPI0_CSn0 */
+   J721S2_WKUP_IOPAD(0x03c, PIN_OUTPUT, 0) /* (F17) 
MCU_OSPI0_CSn3 */
+   J721S2_WKUP_IOPAD(0x00c, PIN_INPUT, 0) /* (C19) 
MCU_OSPI0_D0 */
+   J721S2_WKUP_IOPAD(0x010, PIN_INPUT, 0) /* (F16) 
MCU_OSPI0_D1 */
+   J721S2_WKUP_IOPAD(0x014, PIN_INPUT, 0) /* (G15) 
MCU_OSPI0_D2 */
+   J721S2_WKUP_IOPAD(0x018, PIN_INPUT, 0) /* (F18) 
MCU_OSPI0_D3 */
+   J721S2_WKUP_IOPAD(0x01c, PIN_INPUT, 0) /* (E19) 
MCU_OSPI0_D4 */
+   J721S2_WKUP_IOPAD(0x020, PIN_INPUT, 0) /* (G19) 
MCU_OSPI0_D5 */
+   J721S2_WKUP_IOPAD(0x024, PIN_INPUT, 0) /* (F19) 
MCU_OSPI0_D6 */
+   J721S2_WKUP_IOPAD(0x028, PIN_INPUT, 0) /* (F20) 
MCU_OSPI0_D7 */
+   J721S2_WKUP_IOPAD(0x008, PIN_INPUT, 0) /* (E18) 
MCU_OSPI0_DQS */
+   J721S2_WKUP_IOPAD(0x004, PIN_INPUT, 0) /* (E20) 
MCU_OSPI0_LBCLKO */
+   >;
+   };
+};
+
+&ospi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0x0>;
+   spi-tx-bus-width = <8>;
+   spi-rx-bus-width = <8>;
+   spi-max-frequency = <2500>;
+   cdns,tshsl-ns = <60>;
+   cdns,tsd2d-ns = <60>;
+   cdns,tchsh-ns = <60>;
+   cdns,tslch-ns = <60>;
+   cdns,read-delay = <4>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
+
+&mailbox0_cluster0 {
+   status = "disabled";
+};
+
+&mailbox0_cluster1 {
+   status = "disabled";
+};
+
+&mailbox0_cluster2 {
+   status = "disabled";
+};
+
+&mailbox0_cluster3 {
+   status = "disabled";
+};
+
+&mailbox0_cluster4 {
+   status = "disabled";
+};
+
+&mailbox0_cluster5 {
+   status = "disabled";
+};
+
+&mailbox0_cluster6 {
+   status = "disabled";
+};
+
+&mailbox0_cluster7 {
+   status = "disabled";
+};
+
+&mailbox0_cluster8 {
+   status = "disabled";
+};
+
+&mailbox0_cluster9 {
+   status = "disabled";
+};
+
+&mailbox0_cluster10 {
+   status = "disabled";
+};
+
+&mailbox0_cluster11 {
+   status = "disabled";
+};
+
+&mailbox1_cluster0 {
+   status = "disabled";
+};
+
+&mailbox1_cluster1 {
+   status = "disabled";
+};
+
+&mailbox1_cluster2 {
+   status = "disabled";
+};
+
+&mailbox1_cluster3 {
+   status = "dis

[PATCH 07/11] arm: j721s2: Add support for selecting DT based on EEPROM

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Enable support for selecting DTB from FIT within SPL based on the
board name read from EEPROM. This will help to use single defconfig
for both EVM and SK.

Signed-off-by: Sinthu Raja 
---
 arch/arm/mach-k3/j721s2_init.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index 12da8136f9..fc5eee03b6 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -19,8 +19,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 static void ctrl_mmr_unlock(void)
 {
@@ -93,6 +95,59 @@ static void store_boot_info_from_rom(void)
   sizeof(struct rom_extended_boot_data));
 }
 
+#ifdef CONFIG_SPL_OF_LIST
+void do_dt_magic(void)
+{
+   int ret, rescan, mmc_dev = -1;
+   static struct mmc *mmc;
+
+   if (IS_ENABLED(CONFIG_TI_I2C_BOARD_DETECT))
+   do_board_detect();
+
+   /*
+* Board detection has been done.
+* Let us see if another dtb wouldn't be a better match
+* for our board
+*/
+   if (IS_ENABLED(CONFIG_CPU_V7R)) {
+   ret = fdtdec_resetup(&rescan);
+   if (!ret && rescan) {
+   dm_uninit();
+   dm_init_and_scan(true);
+   }
+   }
+
+   /*
+* Because of multi DTB configuration, the MMC device has
+* to be re-initialized after reconfiguring FDT inorder to
+* boot from MMC. Do this when boot mode is MMC and ROM has
+* not loaded SYSFW.
+*/
+   switch (spl_boot_device()) {
+   case BOOT_DEVICE_MMC1:
+   mmc_dev = 0;
+   break;
+   case BOOT_DEVICE_MMC2:
+   case BOOT_DEVICE_MMC2_2:
+   mmc_dev = 1;
+   break;
+   }
+
+   if (mmc_dev > 0 && !is_rom_loaded_sysfw(&bootdata)) {
+   ret = mmc_init_device(mmc_dev);
+   if (!ret) {
+   mmc = find_mmc_device(mmc_dev);
+   if (mmc) {
+   ret = mmc_init(mmc);
+   if (ret) {
+   printf("mmc init failed with error: 
%d\n", ret);
+   }
+   }
+   }
+   }
+}
+#endif
+
 void board_init_f(ulong dummy)
 {
struct udevice *dev;
@@ -139,6 +194,10 @@ void board_init_f(ulong dummy)
k3_sysfw_loader(is_rom_loaded_sysfw(&bootdata),
k3_mmc_stop_clock, k3_mmc_restart_clock);
 
+#ifdef CONFIG_SPL_OF_LIST
+   do_dt_magic();
+#endif
+
if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
/*
 * Force probe of clk_k3 driver here to ensure basic 
default clock
-- 
2.36.1



[PATCH 06/11] board: ti: j721s2: Add support for detecting multiple device trees

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Update the board_fit_config_name_match() to choose the right dtb
based on the board name read from EEPROM.

Also restrict multpile EEPROM reads by verifying if EEPROM is already
read

Signed-off-by: Sinthu Raja 
---
 board/ti/j721s2/evm.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 8ada924e3f..25667900ce 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -79,8 +79,17 @@ int dram_init_banksize(void)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-   if (!strcmp(name, "k3-j721s2-common-proc-board"))
-   return 0;
+   bool eeprom_read = board_ti_was_eeprom_read();
+
+   if (!eeprom_read || board_is_j721s2_som()) {
+   if (!strcmp(name, "k3-j721s2-common-proc-board") ||
+   !strcmp(name, "k3-j721s2-r5-common-proc-board"))
+   return 0;
+   } else if (!eeprom_read || board_is_am68_sk_som()) {
+   if (!strcmp(name, "k3-am68-sk-base-board") ||
+   !strcmp(name, "k3-am68-sk-r5-base-board"))
+   return 0;
+   }
 
return -1;
 }
@@ -107,6 +116,9 @@ int do_board_detect(void)
 {
int ret;
 
+   if (board_ti_was_eeprom_read())
+   return 0;
+
ret = ti_i2c_eeprom_am6_get_base(CONFIG_EEPROM_BUS_ADDRESS,
 CONFIG_EEPROM_CHIP_ADDRESS);
if (ret) {
-- 
2.36.1



[PATCH 05/11] board: ti: j721s2: Enable support for reading EEPROM at next alternate address

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

J721S2 EVM has EEPROM populated at 0x50. AM68 SK has EEPROM populated at
next address 0x51 in order to be compatible with RPi. So start looking
for TI specific EEPROM at 0x50, if not found look for EEPROM at 0x51.

Signed-off-by: Sinthu Raja 
---
 board/ti/j721s2/evm.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index e3c75b35b6..8ada924e3f 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -109,9 +109,15 @@ int do_board_detect(void)
 
ret = ti_i2c_eeprom_am6_get_base(CONFIG_EEPROM_BUS_ADDRESS,
 CONFIG_EEPROM_CHIP_ADDRESS);
-   if (ret)
-   pr_err("Reading on-board EEPROM at 0x%02x failed %d\n",
-  CONFIG_EEPROM_CHIP_ADDRESS, ret);
+   if (ret) {
+   printf("EEPROM not available at 0x%02x, trying to read at 
0x%02x\n",
+  CONFIG_EEPROM_CHIP_ADDRESS, CONFIG_EEPROM_CHIP_ADDRESS + 
1);
+   ret = ti_i2c_eeprom_am6_get_base(CONFIG_EEPROM_BUS_ADDRESS,
+CONFIG_EEPROM_CHIP_ADDRESS + 
1);
+   if (ret)
+   pr_err("Reading on-board EEPROM at 0x%02x failed %d\n",
+   CONFIG_EEPROM_CHIP_ADDRESS + 1, ret);
+   }
 
return ret;
 }
-- 
2.36.1



[PATCH 04/11] board: ti: j721s2: Add support to update board_name for am68-sk

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Update setup_board_eeprom_env() to choose the right board name
for am68-sk.

Signed-off-by: Sinthu Raja 
---
 board/ti/j721s2/evm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index e09adc8ad3..e3c75b35b6 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -28,6 +28,8 @@
 
 #define board_is_j721s2_som()  board_ti_k3_is("J721S2X-PM1-SOM")
 
+#define board_is_am68_sk_som() board_ti_k3_is("AM68-SK-SOM")
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
@@ -136,6 +138,8 @@ static void setup_board_eeprom_env(void)
 
if (board_is_j721s2_som())
name = "j721s2";
+   else if (board_is_am68_sk_som())
+   name = "am68-sk";
else
printf("Unidentified board claims %s in eeprom header\n",
   board_ti_get_name());
-- 
2.36.1



[PATCH 00/11] AM68 SK: Add initial support for AM68 Starter Kit

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

AM68 Starter Kit (SK) is a low cost, small form factor board designed
for TI’s J721S2/AM68 SoC. TI’s J721S2/AM68 SoC comprises of dual core A72, high
performance vision accelerators, hardware accelerators, latest C71x
DSP, high bandwidth real-time IPs for capture and display. The SoC is
power optimized to provide best in class performance for industrial
and automotive applications.

Refer below link to J721S2/AM68 Technical Reference Manual for further details: 
http://www.ti.com/lit/pdf/spruj28

AM68 SK supports the following interfaces:
  * 16 GB LPDDR4 RAM
  * x1 Gigabit Ethernet interface
  * x1 USB 3.1 Type-C port
  * x2 USB 3.1 Type-A ports
  * x1 PCIe M.2 M Key
  * 512 Mbit OSPI flash
  * x2 CSI2 Camera interface (RPi and TI Camera connector)
  * 40-pin Raspberry Pi GPIO header

This series of patch add initial support for AM68 starter kit.
Design files can be referrred from https://www.ti.com/lit/zip/SPRR463

Sinthu Raja (11):
  configs: j721s2_evm_r5: Enable support for building multiple dtbs into
FIT
  configs: j721s2_evm_a72: Enable support for building multiple dtbs
into FIT
  configs: j721s2_evm: Enable configs to store env in MMC FAT partition
  board: ti: j721s2: Add support to update board_name for am68-sk
  board: ti: j721s2: Enable support for reading EEPROM at next alternate
address
  board: ti: j721s2: Add support for detecting multiple device trees
  arm: j721s2: Add support for selecting DT based on EEPROM
  arm: dts: Add initial support for AM68 Starter Kit System on Module
  arm: dts: Add support for A72 specific AM68 Starter Kit Base Board
  arm: dts: k3-am68-sk: Add r5 specific dt support
  include: configs: Update env for selecting right dtb

 arch/arm/dts/Makefile |   4 +-
 .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 216 ++
 arch/arm/dts/k3-am68-sk-base-board.dts| 395 ++
 arch/arm/dts/k3-am68-sk-r5-base-board.dts | 226 ++
 arch/arm/dts/k3-am68-sk-som.dtsi  | 167 
 arch/arm/mach-k3/j721s2_init.c|  59 +++
 board/ti/j721s2/evm.c |  32 +-
 configs/j721s2_evm_a72_defconfig  |   5 +-
 configs/j721s2_evm_r5_defconfig   |   4 +
 include/configs/j721s2_evm.h  |   4 +
 10 files changed, 1105 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am68-sk-base-board.dts
 create mode 100644 arch/arm/dts/k3-am68-sk-r5-base-board.dts
 create mode 100644 arch/arm/dts/k3-am68-sk-som.dtsi

-- 
2.36.1



[PATCH 03/11] configs: j721s2_evm: Enable configs to store env in MMC FAT partition

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

J721S2 EVM used to store env on eMMC, since EVM and SK uses same
defconfig and there is no eMMC on SK, we need to keep env in an
interface which available on both EVM and SK. So, save env in FAT
partition of MMC SD Card.

Enable defconfigs relevant for storing env on FAT partition of MMC.

Signed-off-by: Sinthu Raja 
---
 configs/j721s2_evm_a72_defconfig | 4 +++-
 configs/j721s2_evm_r5_defconfig  | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index 2084ed020e..cf23a73222 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -92,7 +92,9 @@ CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_OF_LIST="k3-j721s2-common-proc-board k3-am68-sk-base-board"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig
index b72ed1dbd5..6e694c8d55 100644
--- a/configs/j721s2_evm_r5_defconfig
+++ b/configs/j721s2_evm_r5_defconfig
@@ -88,6 +88,7 @@ CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="k3-j721s2-r5-common-proc-board k3-am68-sk-r5-base-board"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ENV_OVERWRITE=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
-- 
2.36.1



[PATCH 02/11] configs: j721s2_evm_a72: Enable support for building multiple dtbs into FIT

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Enable configs for building multiple dtbs into a single fit image
and load the right dtb for next stage. Add k3-am68-sk-base-board
dtb along with evm dtb inside DTB FIT image. This helps to use same
defconfig for both EVM and SK

Signed-off-by: Sinthu Raja 
---
 configs/j721s2_evm_a72_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index a06312f4f5..2084ed020e 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -89,6 +89,7 @@ CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_OF_LIST="k3-j721s2-common-proc-board k3-am68-sk-base-board"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
-- 
2.36.1



[PATCH 01/11] configs: j721s2_evm_r5: Enable support for building multiple dtbs into FIT

2022-10-27 Thread Sinthu Raja
From: Sinthu Raja 

Enable configs for building multiple dtbs into a single fit image
and load the right dtb for next stage. This will help to use same
defconfig for both EVM and SK.

Signed-off-by: Sinthu Raja 
---
 configs/j721s2_evm_r5_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig
index 98d69a18b9..b72ed1dbd5 100644
--- a/configs/j721s2_evm_r5_defconfig
+++ b/configs/j721s2_evm_r5_defconfig
@@ -84,6 +84,9 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_OF_LIST="k3-j721s2-r5-common-proc-board k3-am68-sk-r5-base-board"
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
-- 
2.36.1



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

2022-10-27 Thread Nylon Chen
change iverted to inverted.

Signed-off-by: Nylon Chen 
---
 drivers/led/led_pwm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c
index 0ebae358eb..7c8eae9337 100644
--- a/drivers/led/led_pwm.c
+++ b/drivers/led/led_pwm.c
@@ -123,7 +123,7 @@ static int led_pwm_of_to_plat(struct udevice *dev)
priv->enabled =  !!def_brightness;
 
/*
-* No need to handle pwm iverted case (active_low)
+* No need to handle pwm inverted case (active_low)
 * because of pwm_set_invert function
 */
if (def_brightness < max_brightness)
-- 
2.36.1



Re: imx8 regression: cyclic_register for watchdog@30280000 failed

2022-10-27 Thread Stefan Roese

On 27.10.22 12:06, Rasmus Villemoes wrote:

On 27/10/2022 08.32, Stefan Roese wrote:


In this case the watchdog gets
started but never reset via cyclic. This is due to cyclic_init never
being called in the SPL - where is that supposed to occur?


I did not have many targets with WDT in SPL to test with. Seems that
I missed to call into cyclic_init() here.


I have an idea for getting rid of cyclic_init() (and thus the need for
ensuring it gets called) completely, give me a day or two to spin a
small series.


Perfect Rasmus. Thanks for looking into this. I've read your other
mail as well but haven't found the time yet to answer.

Still the test from Tim would be interesting, if quickly possible -
which I assume should be possible.

Thanks,
Stefan


Re: imx8 regression: cyclic_register for watchdog@30280000 failed

2022-10-27 Thread Rasmus Villemoes
On 27/10/2022 08.32, Stefan Roese wrote:

>> In this case the watchdog gets
>> started but never reset via cyclic. This is due to cyclic_init never
>> being called in the SPL - where is that supposed to occur?
> 
> I did not have many targets with WDT in SPL to test with. Seems that
> I missed to call into cyclic_init() here.

I have an idea for getting rid of cyclic_init() (and thus the need for
ensuring it gets called) completely, give me a day or two to spin a
small series.

Rasmus


Re: Adapteva Parallella board

2022-10-27 Thread Michal Simek

Hi,
On 10/26/22 20:00, Martin Husemann wrote:

Hey folks,

the other day I was asked to test some changes on my Adapteva Parallella board,
which I hadn't used for ages.

I noticed it has an ancient u-boot:

U-Boot 2012.10-3-g792c31c (Jan 03 2014 - 12:24:08)

I2C:   ready
DRAM:  992 MiB
WARNING: Caches not enabled
MMC:   SDHCI: 0
SF: Detected N25Q128 with page size 64 KiB, total 16 MiB
In:serial
Out:   serial
Err:   serial
Net:   zynq_gem
Hit any key to stop autoboot:

... and a quick search turned up lots of supported similar boards
in u-boot mainline under board/xilinx/zynq - but no concrete instructions
or test results for the Parallella.

Anyone know what would be missing or is it just something simple like
"take u-boot for z702 and replace the dtb"?


add DT to tree. If you have ps7_init create folder in board/xilinx/zynq/ folder

export DEVICE_TREE=...

xilinx_zynq_virt_defconfig

Load it and it should just work

Thanks,
Michal

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



Re: [PATCH V2 01/13] env: Complete generic support for writable list

2022-10-27 Thread Stefan Herbrechtsmeier

Hi,

Am 05.10.2022 um 10:33 schrieb Jan Kiszka:

From: Jan Kiszka 

This completes what 890feecaab72 started by selecting ENV_APPEND and
ENV_IS_NOWHERE and by moving this driver to top if the list. This
ensures that load operations pick up both the default env and the
permitted parts of the next-prio location. When writing though, we must
use the regular ordering.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger 
CC: Marek Vasut 
Signed-off-by: Jan Kiszka 
---
  env/Kconfig |  2 ++
  env/env.c   | 22 ++
  2 files changed, 24 insertions(+)

diff --git a/env/Kconfig b/env/Kconfig
index 24111dfaf47..05b5fbf17d1 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -715,6 +715,8 @@ config ENV_APPEND
  
  config ENV_WRITEABLE_LIST

bool "Permit write access only to listed variables"
+   select ENV_IS_NOWHERE
+   select ENV_APPEND
help
  If defined, only environment variables which explicitly set the 'w'
  writeable flag can be written and modified at runtime. No variables
diff --git a/env/env.c b/env/env.c
index 69848fb0608..d0649f9540d 100644
--- a/env/env.c
+++ b/env/env.c
@@ -133,6 +133,28 @@ __weak enum env_location arch_env_get_location(enum 
env_operation op, int prio)
if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
  
+	if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {

+   /*
+* In writeable-list mode, ENVL_NOWHERE gains highest prio by
+* virtually injecting it at prio 0.
+*/
+   if (prio == 0) {
+   /*
+* Avoid the injection for write operations as that
+* would block it.
+*/
+   if (op != ENVOP_SAVE && op != ENVOP_ERASE)
+   return ENVL_NOWHERE;


Is it consensus now to use ENVL_NOWHERE as synonym for default 
environment? If I remember correct this was rejected in the past and 
ENVL_NOWHERE  should only be used if no enviroment is available.


Why don't you call env_set_default(NULL, 0) in env_load() before 
env_driver_lookup()?



+   } else {
+   /*
+* always subtract 1, also for writing because
+* env_load_prio, which is used for writing, was
+* initialized with that offset.
+*/
+   prio--;
+   }
+   }
+
return env_locations[prio];
  }
  


Regards

  Stefan



Re: [PATCH v1] spi: nuvoton: add NPCM PSPI controller driver

2022-10-27 Thread Jagan Teki
On Fri, Jul 1, 2022 at 5:42 PM Jagan Teki  wrote:
>
> On Tue, May 31, 2022 at 3:44 PM Jim Liu  wrote:
> >
> > Add Nuvoton NPCM BMC Peripheral SPI controller driver.
> > NPCM750 include two general-purpose SPI interface.
> >
> > Signed-off-by: Jim Liu 
> > ---
>
> Reviewed-by: Jagan Teki 

Applied to u-boot-spi/master


Re: [PATCH v1] spi: nuvoton: add NPCM PSPI controller driver

2022-10-27 Thread Jim Liu
Hi Jagan

My upstream topic status is Awaiting Upstream.
but now Meta needs to use this driver.
What could I do to make it merge fast?

Best regards,
Jim





On Thu, Oct 27, 2022 at 2:57 PM jjl...@nuvoton.com  wrote:
>
> fyi
>
> -Original Message-
> From: Jim Liu 
> Sent: Tuesday, May 31, 2022 6:14 PM
> To: CS20 JJLiu0 ; ja...@amarulasolutions.com; CS20 YSChu 
> ; CS20 KWLiu 
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v1] spi: nuvoton: add NPCM PSPI controller driver
>
> Add Nuvoton NPCM BMC Peripheral SPI controller driver.
> NPCM750 include two general-purpose SPI interface.
>
> Signed-off-by: Jim Liu 
> ---
>  drivers/spi/Kconfig |   5 +
>  drivers/spi/Makefile|   1 +
>  drivers/spi/npcm_pspi.c | 226 
>  3 files changed, 232 insertions(+)
>  create mode 100644 drivers/spi/npcm_pspi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 
> a1e515cb2b..4e4e05f849 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -289,6 +289,11 @@ config NPCM_FIU_SPI
>   This enables support for the Flash Interface Unit SPI controller
>   in master mode.
>
> +config NPCM_PSPI
> +   bool "PSPI driver for Nuvoton NPCM SoC"
> +   help
> + PSPI driver for NPCM SoC
> +
>  config NXP_FSPI
> bool "NXP FlexSPI driver"
> depends on SPI_MEM
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 
> 06e81b465b..1b843636bc 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
>  obj-$(CONFIG_MXC_SPI) += mxc_spi.o
>  obj-$(CONFIG_MXS_SPI) += mxs_spi.o
>  obj-$(CONFIG_NPCM_FIU_SPI) += npcm_fiu_spi.o
> +obj-$(CONFIG_NPCM_PSPI) += npcm_pspi.o
>  obj-$(CONFIG_NXP_FSPI) += nxp_fspi.o
>  obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o
>  obj-$(CONFIG_OCTEON_SPI) += octeon_spi.o diff --git 
> a/drivers/spi/npcm_pspi.c b/drivers/spi/npcm_pspi.c new file mode 100644 
> index 00..bd9ac65411
> --- /dev/null
> +++ b/drivers/spi/npcm_pspi.c
> @@ -0,0 +1,226 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021 Nuvoton Technology.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_DIV127
> +
> +/* Register offsets */
> +#define PSPI_DATA  0
> +#define PSPI_CTL1  2
> +#define PSPI_STAT  4
> +
> +/* PSPI_CTL1 fields */
> +#define PSPI_CTL1_SPIENBIT(0)
> +#define PSPI_CTL1_SCM  BIT(7)
> +#define PSPI_CTL1_SCIDLBIT(8)
> +#define PSPI_CTL1_SCDV_MASKGENMASK(15, 9)
> +#define PSPI_CTL1_SCDV_SHIFT   9
> +
> +/* PSPI_STAT fields */
> +#define PSPI_STAT_BSY  BIT(0)
> +#define PSPI_STAT_RBF  BIT(1)
> +
> +struct npcm_pspi_priv {
> +   void __iomem *base;
> +   struct clk clk;
> +   struct gpio_desc cs_gpio;
> +   u32 max_hz;
> +};
> +
> +static inline void spi_cs_activate(struct udevice *dev) {
> +   struct udevice *bus = dev->parent;
> +   struct npcm_pspi_priv *priv = dev_get_priv(bus);
> +
> +   dm_gpio_set_value(&priv->cs_gpio, 0);
> +}
> +
> +static inline void spi_cs_deactivate(struct udevice *dev) {
> +   struct udevice *bus = dev->parent;
> +   struct npcm_pspi_priv *priv = dev_get_priv(bus);
> +
> +   dm_gpio_set_value(&priv->cs_gpio, 1);
> +}
> +
> +static inline void npcm_pspi_enable(struct npcm_pspi_priv *priv) {
> +   u16 val;
> +
> +   val = readw(priv->base + PSPI_CTL1);
> +   val |= PSPI_CTL1_SPIEN;
> +   writew(val, priv->base + PSPI_CTL1);
> +}
> +
> +static inline void npcm_pspi_disable(struct npcm_pspi_priv *priv) {
> +   u16 val;
> +
> +   val = readw(priv->base + PSPI_CTL1);
> +   val &= ~PSPI_CTL1_SPIEN;
> +   writew(val, priv->base + PSPI_CTL1);
> +}
> +
> +static int npcm_pspi_xfer(struct udevice *dev, unsigned int bitlen,
> + const void *dout, void *din, unsigned long flags) {
> +   struct udevice *bus = dev->parent;
> +   struct npcm_pspi_priv *priv = dev_get_priv(bus);
> +   void __iomem *base = priv->base;
> +   const u8 *tx = dout;
> +   u8 *rx = din;
> +   u32 bytes = bitlen / 8;
> +   u8 tmp;
> +   u32 val;
> +   int i, ret = 0;
> +
> +   npcm_pspi_enable(priv);
> +
> +   if (flags & SPI_XFER_BEGIN)
> +   spi_cs_activate(dev);
> +
> +   for (i = 0; i < bytes; i++) {
> +   /* Making sure we can write */
> +   ret = readb_poll_timeout(base + PSPI_STAT, val,
> +!(val & PSPI_STAT_BSY),
> +100);
> +   if (ret < 0)
> +   break;
> +
> +   if (tx)
> +   writeb(*tx++, base + PSPI_DATA);
> +   else
> +   writeb(0, base + PSPI_DATA);
> +
> +   /* Wait till write comp

Re: [PATCH] drivers: mmc: Reset watchdog when accessing mmc device

2022-10-27 Thread Stefan Roese

On 27.10.22 08:49, qianfan wrote:



在 2022/10/26 17:18, Jaehoon Chung 写道:

Hi,


-Original Message-
From: qianfan [mailto:qianfangui...@163.com]
Sent: Tuesday, August 30, 2022 12:43 PM
To: Jaehoon Chung ; u-boot@lists.denx.de
Cc: Peng Fan 
Subject: Re: [PATCH] drivers: mmc: Reset watchdog when accessing mmc 
device




在 2022/7/26 16:31, Jaehoon Chung 写道:

On 7/13/22 16:32, qianfangui...@163.com wrote:

From: qianfan Zhao 

watchdog will reset when 'mmc read' or 'ext4load' a large file from
mmc device. Reset watchdog when accessing mmc device.

I don't know why this patch is need.

Hi:

maybe your's board doesn't have a hardware watchdog.
on my board there has a gpio watchdog and we should trigger it no 
more than 1.2 second.

otherwise it will reset CPU.

But 'mmc read' command doesn't trigger watchdog, it's ok if we load a 
smaller imges, but if we
load a very bigger image which more than 100MiB, the watchdog will 
dead and trigger a system reset.

Sorry for too late. I had missed your email.
Is there a case to load more bigger image than 100MiB?
The case is loading rootfs.img from mmc and upgrade. The rootfs based on 
debian or ubuntu

is very bigger.


Best Regards,
Jaehoon Chung


So I make this patch to make sure we can trigger watchdog while 
loading mmc.

Best Regards,
Jaehoon Chung


Signed-off-by: qianfan Zhao 
---
   drivers/mmc/mmc.c | 4 
   1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
4d9871d69f..27ffdb7fa7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -24,6 +24,7 @@
   #include 
   #include 
   #include 
+#include 


Please include cyclic.h now.


   #include "mmc_private.h"

   #define DEFAULT_CMD6_TIMEOUT_MS  500 @@ -297,6 +298,7 @@ int
mmc_poll_for_busy(struct mmc *mmc, int timeout_ms)
   if (timeout_ms-- <= 0)
   break;

+    WATCHDOG_RESET();


And please use schedule() here now instead of WATCHDOG_RESET().

Thanks,
Stefan


   udelay(1000);
   }

@@ -500,6 +502,8 @@ ulong mmc_bread(struct blk_desc *block_dev, 
lbaint_t start, lbaint_t blkcnt,

   blocks_todo -= cur;
   start += cur;
   dst += cur * mmc->read_bl_len;
+
+    WATCHDOG_RESET();
   } while (blocks_todo > 0);

   return blkcnt;







Viele Grüße,
Stefan Roese

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