[PATCH 1/2] config: nxp: bk4: Increase size of CONFIG_SYS_MALLOC_F_LEN (to 0x1000)

[PATCH 1/2] config: nxp: bk4: Increase size of CONFIG_SYS_MALLOC_F_LEN (to 0x1000)

[Lukasz Majewski]

The commit c69103218ee4 ("i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag")
has enabled by default the i2c initialization in the pre-relocation
phase.
It turned out that vf610 based BK4 board had too small SYS_MALLOC_F_LEN
pool size.

After increasing it to 0x1000 the board boots again.

Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
 configs/bk4r1_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index 3ed587a1060..8bff1653859 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_TEXT_BASE=0x3f401000
 CONFIG_SYS_MALLOC_LEN=0x402000
-CONFIG_SYS_MALLOC_F_LEN=0x800
+CONFIG_SYS_MALLOC_F_LEN=0x1000
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x200000
-- 
2.39.5

[PATCH 2/2] dts: Add u-boot specific 'fsl, mux_mask' property to iomuxc for vf610

[Lukasz Majewski]

The commit e8a9521e649f
("vf500/vf610: synchronise device trees with linux")
has synchronized U-Boot's DTS with v5.19 Linux kernel.
It turned out that in Linux's upstream iomuxc node description the
fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's Vybrid
SoC was not working properly.

As by default the mux mask was set to 0, the vf610 based boards (like
BK4) were bricked, due to misconfiguration of gpio at early boot stage.

The fix for all vf610 based boards is to introduce vfxxx-u-boot.dtsi file
with 'fsl,mux_mask' property provided and include it in boards' specific
U-Boot adjustment files (like vf610-bk4r1-u-boot.dtsi).

Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
 arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
 arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
 2 files changed, 11 insertions(+)
 create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi

diff --git a/arch/arm/dts/vf610-bk4r1-u-boot.dtsi b/arch/arm/dts/vf610-bk4r1-u-boot.dtsi
index 1336006e038..af2749803f4 100644
--- a/arch/arm/dts/vf610-bk4r1-u-boot.dtsi
+++ b/arch/arm/dts/vf610-bk4r1-u-boot.dtsi
@@ -4,6 +4,8 @@
  * Lukasz Majewski, DENX Software Engineering, lukma@denx.de
  */
 
+#include "vfxxx-u-boot.dtsi"
+
 / {
 	soc {
 		bootph-all;
diff --git a/arch/arm/dts/vfxxx-u-boot.dtsi b/arch/arm/dts/vfxxx-u-boot.dtsi
new file mode 100644
index 00000000000..d9ed3949232
--- /dev/null
+++ b/arch/arm/dts/vfxxx-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2025
+ * Lukasz Majewski, DENX Software Engineering, lukma@denx.de
+ */
+
+&iomuxc {
+	fsl,mux_mask = <0x700000>;
+};
-- 
2.39.5

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:

> The commit e8a9521e649f
> ("vf500/vf610: synchronise device trees with linux")
> has synchronized U-Boot's DTS with v5.19 Linux kernel.
> It turned out that in Linux's upstream iomuxc node description the
> fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's Vybrid
> SoC was not working properly.
> 
> As by default the mux mask was set to 0, the vf610 based boards (like
> BK4) were bricked, due to misconfiguration of gpio at early boot stage.
> 
> The fix for all vf610 based boards is to introduce vfxxx-u-boot.dtsi file
> with 'fsl,mux_mask' property provided and include it in boards' specific
> U-Boot adjustment files (like vf610-bk4r1-u-boot.dtsi).
> 
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> ---
>  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
>  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
>  2 files changed, 11 insertions(+)
>  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi

It looks like this is still missing upstream, so what's the status on
that? Thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

RE: [PATCH 1/2] config: nxp: bk4: Increase size of CONFIG_SYS_MALLOC_F_LEN (to 0x1000)

[Peng Fan]

> Subject: [PATCH 1/2] config: nxp: bk4: Increase size of
> CONFIG_SYS_MALLOC_F_LEN (to 0x1000)
> 
> The commit c69103218ee4 ("i2c: mxc_i2c: add DM_FLAG_PRE_RELOC
> flag") has enabled by default the i2c initialization in the pre-relocation
> phase.
> It turned out that vf610 based BK4 board had too small
> SYS_MALLOC_F_LEN pool size.
> 
> After increasing it to 0x1000 the board boots again.
> 
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> ---
>  configs/bk4r1_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig index
> 3ed587a1060..8bff1653859 100644
> --- a/configs/bk4r1_defconfig
> +++ b/configs/bk4r1_defconfig
> @@ -4,7 +4,7 @@ CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_VF610=y
>  CONFIG_TEXT_BASE=0x3f401000
>  CONFIG_SYS_MALLOC_LEN=0x402000
> -CONFIG_SYS_MALLOC_F_LEN=0x800
> +CONFIG_SYS_MALLOC_F_LEN=0x1000
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_ENV_SIZE=0x2000
>  CONFIG_ENV_OFFSET=0x200000
> --

Acked-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 1/2] config: nxp: bk4: Increase size of CONFIG_SYS_MALLOC_F_LEN (to 0x1000)

[Fabio Estevam]

Hi Lukasz,

On Tue, Jun 24, 2025 at 5:47 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> The commit c69103218ee4 ("i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag")
> has enabled by default the i2c initialization in the pre-relocation
> phase.
> It turned out that vf610 based BK4 board had too small SYS_MALLOC_F_LEN
> pool size.
>
> After increasing it to 0x1000 the board boots again.
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>

It seems other Vybrid boards also have the same issue.

What about removing CONFIG_SYS_MALLOC_F_LEN from all the Vybrid boards
so that the default of 0x2000 is used?

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index 2b72ec916327..82ebf704c605 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_TEXT_BASE=0x3f401000
 CONFIG_SYS_MALLOC_LEN=0x402000
-CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x200000
diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
index d0d558ab11ad..81d703ec679d 100644
--- a/configs/pcm052_defconfig
+++ b/configs/pcm052_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_TEXT_BASE=0x3f401000
 CONFIG_SYS_MALLOC_LEN=0x202000
-CONFIG_SYS_MALLOC_F_LEN=0x400
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0xA0000
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index c823cb0a30ee..8129484513dd 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_TEXT_BASE=0x3f401000
 CONFIG_SYS_MALLOC_LEN=0x202000
-CONFIG_SYS_MALLOC_F_LEN=0x400
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0xC0000
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
index 84e73c0c6657..51365990d0fb 100644
--- a/configs/vf610twr_nand_defconfig
+++ b/configs/vf610twr_nand_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_TEXT_BASE=0x3f401000
 CONFIG_SYS_MALLOC_LEN=0x0220000
-CONFIG_SYS_MALLOC_F_LEN=0x400
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x20000
 CONFIG_ENV_OFFSET=0x180000

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hi Tom,

> On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:
> 
> > The commit e8a9521e649f
> > ("vf500/vf610: synchronise device trees with linux")
> > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > It turned out that in Linux's upstream iomuxc node description the
> > fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's
> > Vybrid SoC was not working properly.
> > 
> > As by default the mux mask was set to 0, the vf610 based boards
> > (like BK4) were bricked, due to misconfiguration of gpio at early
> > boot stage.
> > 
> > The fix for all vf610 based boards is to introduce
> > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property provided and
> > include it in boards' specific U-Boot adjustment files (like
> > vf610-bk4r1-u-boot.dtsi).
> > 
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> >  2 files changed, 11 insertions(+)
> >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi  
> 
> It looks like this is still missing upstream, so what's the status on
> that? 

It looks like in Linux the mux_mask is hardcoded (for Vybrid vf610):
https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321

In u-boot other SoCs use it as well, but with different values:
- arch/arm/dts/imxrt1050.dtsi -> 0x7
- arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00

In the imx8ulp case above - it is already set in *-u-boot.dtsi specific
file, so I've followed this approach.

> Thanks.
> 




Best regards,

Lukasz Majewski

--

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] config: nxp: bk4: Increase size of CONFIG_SYS_MALLOC_F_LEN (to 0x1000)

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

Hi Fabio,

> Hi Lukasz,
> 
> On Tue, Jun 24, 2025 at 5:47 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > The commit c69103218ee4 ("i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag")
> > has enabled by default the i2c initialization in the pre-relocation
> > phase.
> > It turned out that vf610 based BK4 board had too small
> > SYS_MALLOC_F_LEN pool size.
> >
> > After increasing it to 0x1000 the board boots again.
> >
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>  
> 
> It seems other Vybrid boards also have the same issue.
> 
> What about removing CONFIG_SYS_MALLOC_F_LEN from all the Vybrid boards
> so that the default of 0x2000 is used?
> 

Good idea.

I will check if this can be safely done - for some reason smaller
values were used on Vybrid boards.

> diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
> index 2b72ec916327..82ebf704c605 100644
> --- a/configs/bk4r1_defconfig
> +++ b/configs/bk4r1_defconfig
> @@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_VF610=y
>  CONFIG_TEXT_BASE=0x3f401000
>  CONFIG_SYS_MALLOC_LEN=0x402000
> -CONFIG_SYS_MALLOC_F_LEN=0x800
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_ENV_SIZE=0x2000
>  CONFIG_ENV_OFFSET=0x200000
> diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
> index d0d558ab11ad..81d703ec679d 100644
> --- a/configs/pcm052_defconfig
> +++ b/configs/pcm052_defconfig
> @@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_VF610=y
>  CONFIG_TEXT_BASE=0x3f401000
>  CONFIG_SYS_MALLOC_LEN=0x202000
> -CONFIG_SYS_MALLOC_F_LEN=0x400
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_ENV_SIZE=0x2000
>  CONFIG_ENV_OFFSET=0xA0000
> diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
> index c823cb0a30ee..8129484513dd 100644
> --- a/configs/vf610twr_defconfig
> +++ b/configs/vf610twr_defconfig
> @@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_VF610=y
>  CONFIG_TEXT_BASE=0x3f401000
>  CONFIG_SYS_MALLOC_LEN=0x202000
> -CONFIG_SYS_MALLOC_F_LEN=0x400
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_ENV_SIZE=0x2000
>  CONFIG_ENV_OFFSET=0xC0000
> diff --git a/configs/vf610twr_nand_defconfig
> b/configs/vf610twr_nand_defconfig index 84e73c0c6657..51365990d0fb
> 100644 --- a/configs/vf610twr_nand_defconfig
> +++ b/configs/vf610twr_nand_defconfig
> @@ -4,7 +4,6 @@ CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_VF610=y
>  CONFIG_TEXT_BASE=0x3f401000
>  CONFIG_SYS_MALLOC_LEN=0x0220000
> -CONFIG_SYS_MALLOC_F_LEN=0x400
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_ENV_SIZE=0x20000
>  CONFIG_ENV_OFFSET=0x180000




Best regards,

Lukasz Majewski

--

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:
> Hi Tom,
> 
> > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:
> > 
> > > The commit e8a9521e649f
> > > ("vf500/vf610: synchronise device trees with linux")
> > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > It turned out that in Linux's upstream iomuxc node description the
> > > fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's
> > > Vybrid SoC was not working properly.
> > > 
> > > As by default the mux mask was set to 0, the vf610 based boards
> > > (like BK4) were bricked, due to misconfiguration of gpio at early
> > > boot stage.
> > > 
> > > The fix for all vf610 based boards is to introduce
> > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property provided and
> > > include it in boards' specific U-Boot adjustment files (like
> > > vf610-bk4r1-u-boot.dtsi).
> > > 
> > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > ---
> > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > >  2 files changed, 11 insertions(+)
> > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi  
> > 
> > It looks like this is still missing upstream, so what's the status on
> > that? 
> 
> It looks like in Linux the mux_mask is hardcoded (for Vybrid vf610):
> https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> 
> In u-boot other SoCs use it as well, but with different values:
> - arch/arm/dts/imxrt1050.dtsi -> 0x7
> - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> 
> In the imx8ulp case above - it is already set in *-u-boot.dtsi specific
> file, so I've followed this approach.

Someone should unify upstream to one approach or another I would think.
Or find a good explanation as to why it's not unified, and then we
should follow.

I'm not nak'ing this patch but I am noting a problem that needs to be
addressed.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Fabio Estevam]

Hi Lukasz,

On Wed, Jun 25, 2025 at 3:36 AM Lukasz Majewski <lukma@denx.de> wrote:

> It looks like in Linux the mux_mask is hardcoded (for Vybrid vf610):
> https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321

I suggest doing the same approach in U-Boot's pinctrl-vf610.c driver
instead of doing it in u-boot.dtsi.

The less we diverge from Linux, the better.

> In u-boot other SoCs use it as well, but with different values:
> - arch/arm/dts/imxrt1050.dtsi -> 0x7
> - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00

imxrt1050 and imx8ulp use different pinctrl drivers.

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:
> On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> > 
> > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:
> > > 
> > > > The commit e8a9521e649f
> > > > ("vf500/vf610: synchronise device trees with linux")
> > > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > > It turned out that in Linux's upstream iomuxc node description the
> > > > fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's
> > > > Vybrid SoC was not working properly.
> > > > 
> > > > As by default the mux mask was set to 0, the vf610 based boards
> > > > (like BK4) were bricked, due to misconfiguration of gpio at early
> > > > boot stage.
> > > > 
> > > > The fix for all vf610 based boards is to introduce
> > > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property provided and
> > > > include it in boards' specific U-Boot adjustment files (like
> > > > vf610-bk4r1-u-boot.dtsi).
> > > > 
> > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > ---
> > > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > > >  2 files changed, 11 insertions(+)
> > > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi  
> > > 
> > > It looks like this is still missing upstream, so what's the status on
> > > that? 
> > 
> > It looks like in Linux the mux_mask is hardcoded (for Vybrid vf610):
> > https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> > 
> > In u-boot other SoCs use it as well, but with different values:
> > - arch/arm/dts/imxrt1050.dtsi -> 0x7
> > - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> > 
> > In the imx8ulp case above - it is already set in *-u-boot.dtsi specific
> > file, so I've followed this approach.
> 
> Someone should unify upstream to one approach or another I would think.
> Or find a good explanation as to why it's not unified, and then we
> should follow.

If these values are per-SoC, which they appear to be given these
look like 3 different devices, I don't see a reason for these to be
accepted "upstream".

And if there're not per-SoC then please make sure the _ becomes a - in
the property name Lukasz.

> I'm not nak'ing this patch but I am noting a problem that needs to be
> addressed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

On Wed, Jun 25, 2025 at 05:28:56PM +0100, Conor Dooley wrote:
> On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:
> > On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:
> > > Hi Tom,
> > > 
> > > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski wrote:
> > > > 
> > > > > The commit e8a9521e649f
> > > > > ("vf500/vf610: synchronise device trees with linux")
> > > > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > > > It turned out that in Linux's upstream iomuxc node description the
> > > > > fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's
> > > > > Vybrid SoC was not working properly.
> > > > > 
> > > > > As by default the mux mask was set to 0, the vf610 based boards
> > > > > (like BK4) were bricked, due to misconfiguration of gpio at early
> > > > > boot stage.
> > > > > 
> > > > > The fix for all vf610 based boards is to introduce
> > > > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property provided and
> > > > > include it in boards' specific U-Boot adjustment files (like
> > > > > vf610-bk4r1-u-boot.dtsi).
> > > > > 
> > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > > ---
> > > > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > > > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > > > >  2 files changed, 11 insertions(+)
> > > > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi  
> > > > 
> > > > It looks like this is still missing upstream, so what's the status on
> > > > that? 
> > > 
> > > It looks like in Linux the mux_mask is hardcoded (for Vybrid vf610):
> > > https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> > > 
> > > In u-boot other SoCs use it as well, but with different values:
> > > - arch/arm/dts/imxrt1050.dtsi -> 0x7
> > > - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> > > 
> > > In the imx8ulp case above - it is already set in *-u-boot.dtsi specific
> > > file, so I've followed this approach.
> > 
> > Someone should unify upstream to one approach or another I would think.
> > Or find a good explanation as to why it's not unified, and then we
> > should follow.
> 
> If these values are per-SoC, which they appear to be given these
> look like 3 different devices, I don't see a reason for these to be
> accepted "upstream".

OK, yes. But it should either be "hard code a thing" or "get the
property" not maybe-one-maybe-the-other? That was what I was trying to
make as my point.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]

Hi Tom,

> On Wed, Jun 25, 2025 at 05:28:56PM +0100, Conor Dooley wrote:
> > On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:  
> > > On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:  
> > > > Hi Tom,
> > > >   
> > > > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski
> > > > > wrote: 
> > > > > > The commit e8a9521e649f
> > > > > > ("vf500/vf610: synchronise device trees with linux")
> > > > > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > > > > It turned out that in Linux's upstream iomuxc node
> > > > > > description the fsl,mux_mask' was missing, so the U-Boot's
> > > > > > pinctrl driver for NXP's Vybrid SoC was not working
> > > > > > properly.
> > > > > > 
> > > > > > As by default the mux mask was set to 0, the vf610 based
> > > > > > boards (like BK4) were bricked, due to misconfiguration of
> > > > > > gpio at early boot stage.
> > > > > > 
> > > > > > The fix for all vf610 based boards is to introduce
> > > > > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property
> > > > > > provided and include it in boards' specific U-Boot
> > > > > > adjustment files (like vf610-bk4r1-u-boot.dtsi).
> > > > > > 
> > > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > > > ---
> > > > > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > > > > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > > > > >  2 files changed, 11 insertions(+)
> > > > > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi    
> > > > > 
> > > > > It looks like this is still missing upstream, so what's the
> > > > > status on that?   
> > > > 
> > > > It looks like in Linux the mux_mask is hardcoded (for Vybrid
> > > > vf610):
> > > > https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> > > > 
> > > > In u-boot other SoCs use it as well, but with different values:
> > > > - arch/arm/dts/imxrt1050.dtsi -> 0x7
> > > > - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> > > > 
> > > > In the imx8ulp case above - it is already set in *-u-boot.dtsi
> > > > specific file, so I've followed this approach.  
> > > 
> > > Someone should unify upstream to one approach or another I would
> > > think. Or find a good explanation as to why it's not unified, and
> > > then we should follow.  
> > 
> > If these values are per-SoC, which they appear to be given these
> > look like 3 different devices, I don't see a reason for these to be
> > accepted "upstream".  
> 
> OK, yes. But it should either be "hard code a thing" or "get the
> property" not maybe-one-maybe-the-other? That was what I was trying to
> make as my point.
> 

Agreed.

Then some decision shall be made if:

1. We keep the fsl,mux-mask as *-u-boot.dtsi specific

2. Modify the pinctrl driver for Vybrid
(drivers/pinctrl/nxp/pinctrl-imx-mmio.c) and maybe add mux_mask field
to:
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.h?ref_type=heads#L26

3. Try to upstream (to Linux) the property. That would require rewriting
kernel pinctrl driver for vf610 to parse "fsl,mux_mask" property.

As Conor pointed out - the approach from 3. is not feasible.

Then we shall decide if 1. or 2. shall be implemented.

Approach from 1. doesn't require any driver's modification. Approach
from 2. would introduce the extra field and some code modification to:
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.c?ref_type=heads
and
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx-mmio.c?ref_type=heads

I would personally opt for 1.


Best regards,

Lukasz Majewski

--

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]

On Wed, Jun 25, 2025 at 10:32:50PM +0200, Lukasz Majewski wrote:
> Hi Tom,
> 
> > On Wed, Jun 25, 2025 at 05:28:56PM +0100, Conor Dooley wrote:
> > > On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:  
> > > > On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski wrote:  
> > > > > Hi Tom,
> > > > >   
> > > > > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski
> > > > > > wrote: 
> > > > > > > The commit e8a9521e649f
> > > > > > > ("vf500/vf610: synchronise device trees with linux")
> > > > > > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > > > > > It turned out that in Linux's upstream iomuxc node
> > > > > > > description the fsl,mux_mask' was missing, so the U-Boot's
> > > > > > > pinctrl driver for NXP's Vybrid SoC was not working
> > > > > > > properly.
> > > > > > > 
> > > > > > > As by default the mux mask was set to 0, the vf610 based
> > > > > > > boards (like BK4) were bricked, due to misconfiguration of
> > > > > > > gpio at early boot stage.
> > > > > > > 
> > > > > > > The fix for all vf610 based boards is to introduce
> > > > > > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property
> > > > > > > provided and include it in boards' specific U-Boot
> > > > > > > adjustment files (like vf610-bk4r1-u-boot.dtsi).
> > > > > > > 
> > > > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > > > > ---
> > > > > > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > > > > > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > > > > > >  2 files changed, 11 insertions(+)
> > > > > > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi    
> > > > > > 
> > > > > > It looks like this is still missing upstream, so what's the
> > > > > > status on that?   
> > > > > 
> > > > > It looks like in Linux the mux_mask is hardcoded (for Vybrid
> > > > > vf610):
> > > > > https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> > > > > 
> > > > > In u-boot other SoCs use it as well, but with different values:
> > > > > - arch/arm/dts/imxrt1050.dtsi -> 0x7
> > > > > - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> > > > > 
> > > > > In the imx8ulp case above - it is already set in *-u-boot.dtsi
> > > > > specific file, so I've followed this approach.  
> > > > 
> > > > Someone should unify upstream to one approach or another I would
> > > > think. Or find a good explanation as to why it's not unified, and
> > > > then we should follow.  
> > > 
> > > If these values are per-SoC, which they appear to be given these
> > > look like 3 different devices, I don't see a reason for these to be
> > > accepted "upstream".  
> > 
> > OK, yes. But it should either be "hard code a thing" or "get the
> > property" not maybe-one-maybe-the-other? That was what I was trying to
> > make as my point.
> > 
> 
> Agreed.
> 
> Then some decision shall be made if:
> 
> 1. We keep the fsl,mux-mask as *-u-boot.dtsi specific
> 
> 2. Modify the pinctrl driver for Vybrid
> (drivers/pinctrl/nxp/pinctrl-imx-mmio.c) and maybe add mux_mask field
> to:
> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.h?ref_type=heads#L26
> 
> 3. Try to upstream (to Linux) the property. That would require rewriting
> kernel pinctrl driver for vf610 to parse "fsl,mux_mask" property.
> 
> As Conor pointed out - the approach from 3. is not feasible.
> 
> Then we shall decide if 1. or 2. shall be implemented.
> 
> Approach from 1. doesn't require any driver's modification. Approach
> from 2. would introduce the extra field and some code modification to:
> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.c?ref_type=heads
> and
> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx-mmio.c?ref_type=heads
> 
> I would personally opt for 1.

Well, my question is wouldn't option 2 bring us closer to how this works
in Linux?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] dts: Add u-boot specific 'fsl,mux_mask' property to iomuxc for vf610

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 4550 bytes --]

Hi Tom,

> On Wed, Jun 25, 2025 at 10:32:50PM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> >   
> > > On Wed, Jun 25, 2025 at 05:28:56PM +0100, Conor Dooley wrote:  
> > > > On Wed, Jun 25, 2025 at 08:14:24AM -0600, Tom Rini wrote:    
> > > > > On Wed, Jun 25, 2025 at 08:36:37AM +0200, Lukasz Majewski
> > > > > wrote:    
> > > > > > Hi Tom,
> > > > > >     
> > > > > > > On Tue, Jun 24, 2025 at 10:47:00PM +0200, Lukasz Majewski
> > > > > > > wrote:   
> > > > > > > > The commit e8a9521e649f
> > > > > > > > ("vf500/vf610: synchronise device trees with linux")
> > > > > > > > has synchronized U-Boot's DTS with v5.19 Linux kernel.
> > > > > > > > It turned out that in Linux's upstream iomuxc node
> > > > > > > > description the fsl,mux_mask' was missing, so the
> > > > > > > > U-Boot's pinctrl driver for NXP's Vybrid SoC was not
> > > > > > > > working properly.
> > > > > > > > 
> > > > > > > > As by default the mux mask was set to 0, the vf610 based
> > > > > > > > boards (like BK4) were bricked, due to misconfiguration
> > > > > > > > of gpio at early boot stage.
> > > > > > > > 
> > > > > > > > The fix for all vf610 based boards is to introduce
> > > > > > > > vfxxx-u-boot.dtsi file with 'fsl,mux_mask' property
> > > > > > > > provided and include it in boards' specific U-Boot
> > > > > > > > adjustment files (like vf610-bk4r1-u-boot.dtsi).
> > > > > > > > 
> > > > > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > > > > > ---
> > > > > > > >  arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 2 ++
> > > > > > > >  arch/arm/dts/vfxxx-u-boot.dtsi       | 9 +++++++++
> > > > > > > >  2 files changed, 11 insertions(+)
> > > > > > > >  create mode 100644 arch/arm/dts/vfxxx-u-boot.dtsi      
> > > > > > > 
> > > > > > > It looks like this is still missing upstream, so what's
> > > > > > > the status on that?     
> > > > > > 
> > > > > > It looks like in Linux the mux_mask is hardcoded (for Vybrid
> > > > > > vf610):
> > > > > > https://elixir.bootlin.com/linux/v6.16-rc3/source/drivers/pinctrl/freescale/pinctrl-vf610.c#L321
> > > > > > 
> > > > > > In u-boot other SoCs use it as well, but with different
> > > > > > values:
> > > > > > - arch/arm/dts/imxrt1050.dtsi -> 0x7
> > > > > > - arch/arm/dts/imx8ulp-evk-u-boot.dtsi -> 0xf00
> > > > > > 
> > > > > > In the imx8ulp case above - it is already set in
> > > > > > *-u-boot.dtsi specific file, so I've followed this
> > > > > > approach.    
> > > > > 
> > > > > Someone should unify upstream to one approach or another I
> > > > > would think. Or find a good explanation as to why it's not
> > > > > unified, and then we should follow.    
> > > > 
> > > > If these values are per-SoC, which they appear to be given these
> > > > look like 3 different devices, I don't see a reason for these
> > > > to be accepted "upstream".    
> > > 
> > > OK, yes. But it should either be "hard code a thing" or "get the
> > > property" not maybe-one-maybe-the-other? That was what I was
> > > trying to make as my point.
> > >   
> > 
> > Agreed.
> > 
> > Then some decision shall be made if:
> > 
> > 1. We keep the fsl,mux-mask as *-u-boot.dtsi specific
> > 
> > 2. Modify the pinctrl driver for Vybrid
> > (drivers/pinctrl/nxp/pinctrl-imx-mmio.c) and maybe add mux_mask
> > field to:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.h?ref_type=heads#L26
> > 
> > 3. Try to upstream (to Linux) the property. That would require
> > rewriting kernel pinctrl driver for vf610 to parse "fsl,mux_mask"
> > property.
> > 
> > As Conor pointed out - the approach from 3. is not feasible.
> > 
> > Then we shall decide if 1. or 2. shall be implemented.
> > 
> > Approach from 1. doesn't require any driver's modification. Approach
> > from 2. would introduce the extra field and some code modification
> > to:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx.c?ref_type=heads
> > and
> > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/nxp/pinctrl-imx-mmio.c?ref_type=heads
> > 
> > I would personally opt for 1.  
> 
> Well, my question is wouldn't option 2 bring us closer to how this
> works in Linux?
> 

Yes, it should.


Best regards,

Lukasz Majewski

--

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]