from:"Lukasz Majewski"

[PATCH 4/4] config: xea: Add limits for SPL and u-boot proper sizes

2024-03-29 Thread Lukasz Majewski

The XEA board has following hard constraints regarding size of binaries:
- u-boot.sb < 48 KiB
- u-boot.img < 448 KiB

Added values are supposed to avoid exceeding size of binaries during
future u-boot development.

Signed-off-by: Lukasz Majewski 

---

(no changes since v1)

 configs/imx28_xea_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 6098c1f3be..822a329187 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -21,12 +21,15 @@ CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_STACK=0x2
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x1000
+CONFIG_SPL_SIZE_LIMIT=0xa000
 CONFIG_SPL=y
 CONFIG_ENV_OFFSET_REDUND=0x9
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 CONFIG_SYS_LOAD_ADDR=0x4200
 CONFIG_SPL_PAYLOAD="u-boot.img"
+CONFIG_HAS_BOARD_SIZE_LIMIT=y
+CONFIG_BOARD_SIZE_LIMIT=458752
 CONFIG_TIMESTAMP=y
 CONFIG_FIT=y
 # CONFIG_BOOTMETH_EXTLINUX is not set
-- 
2.39.2

[PATCH 3/4] arm: xea: Add support for reading SoM (CPU) board HW revision

2024-03-29 Thread Lukasz Majewski

The XEA board now has several HW revisions for SoM boards.
This patch provides support for reading this revision ID values in early
u-boot proper as production devices boot via falcon boot with correct DTB
flashed at production (so there is no need to alter SPL).

Additionally, the maximal SPL size (~55KiB) constraint is not allowing
having even simplified FIT support in it.

As a result it was necessary to handle reading GPIOs values solely in
u-boot proper as one configuration (i.e. 'single binary' -
imx28_xea_sb_defconfig) is not using SPL framework.

Moreover, the 'board_som_rev' environment variable will be used to point
correct configuration from the Linux FIT file.

Additionally, as now XEA has its second HW revision - this information is
printed when u-boot proper starts.

Signed-off-by: Lukasz Majewski 

---

Changes in v2:
Remove "inline" from get_som_rev() function definition
Squash with 'config: xea: Enable late board initialization to set revision 
variable'
Update commit message
Squash with 'arm: xea: Print information about XEA's SoM HW revision'

 board/liebherr/xea/spl_xea.c   | 11 
 board/liebherr/xea/xea.c   | 49 ++
 configs/imx28_xea_defconfig|  1 +
 configs/imx28_xea_sb_defconfig |  1 +
 4 files changed, 62 insertions(+)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 4068a2ad49..6cf8f8390e 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -231,6 +231,17 @@ const iomux_cfg_t iomux_setup[] = {
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
MX28_PAD_GPMI_WRN__GPIO_0_25 | MUX_CONFIG_BOOT, /* TIVA1 */
+
+   /* HW revision ID Base Board */
+   MX28_PAD_LCD_D12__GPIO_1_12,
+   MX28_PAD_LCD_D13__GPIO_1_13,
+   MX28_PAD_LCD_D14__GPIO_1_14,
+
+   /* HW revision ID (SoM) */
+   MX28_PAD_LCD_D15__GPIO_1_15,
+   MX28_PAD_LCD_D16__GPIO_1_16,
+   MX28_PAD_LCD_D17__GPIO_1_17,
+   MX28_PAD_LCD_D18__GPIO_1_18,
 };
 
 u32 mxs_dram_vals[] = {
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index c8ac526cb4..0a6fd7f143 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -216,6 +216,34 @@ int spl_start_uboot(void)
return !boot_tiva0 || !boot_tiva1;
 }
 #else
+/*
+ * Reading the HW ID number for XEA SoM module
+ *
+ * GPIOs from Port 1 (GPIO1_15, GPIO1_16, GPIO1_17 and GPIO1_18)
+ * are used to store HW revision information.
+ * Reading of GPIOs values is performed before the Device Model is
+ * bring up as the proper DTB needs to be chosen first.
+ *
+ * Moreover, this approach is required as "single binary" configuration
+ * of U-Boot (imx28_xea_sb_defconfig) is NOT using SPL framework, so
+ * only minimal subset of functionality is provided when ID is read.
+ *
+ * Hence, the direct registers' access.
+ */
+#define XEA_SOM_HW_ID_GPIO_PORT (MXS_PINCTRL_BASE + (0x0900 + ((1) * 0x10)))
+#define XEA_SOM_REV_MASK GENMASK(18, 15)
+#define XEA_SOM_REV_SHIFT 15
+
+static u8 get_som_rev(void)
+{
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)XEA_SOM_HW_ID_GPIO_PORT;
+
+   u32 tmp = ~readl(>reg);
+   u8 id = (tmp & XEA_SOM_REV_MASK) >> XEA_SOM_REV_SHIFT;
+
+   return id;
+}
 
 int board_early_init_f(void)
 {
@@ -253,6 +281,27 @@ int board_init(void)
return 0;
 }
 
+#if defined(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+   int ret = env_set_ulong("board_som_rev", get_som_rev());
+
+   if (ret)
+   printf("Cannot set XEA's SoM revision env variable!\n");
+
+   return 0;
+}
+#endif
+
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+int checkboard(void)
+{
+   printf("Board: LWE XEA SoM HW rev %d\n", get_som_rev());
+
+   return 0;
+}
+#endif
+
 int dram_init(void)
 {
return mxs_dram_init();
diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 64a0561a34..6098c1f3be 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -39,6 +39,7 @@ CONFIG_BOOTCOMMAND="run ${bootpri} ; run ${bootsec}"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 9872d35c1b..8d48d8c507 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -23,6 +23,7 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 # CONFIG_SPL_FRAMEWORK is not set
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
-- 
2.39.2

[PATCH 2/4] arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2

2024-03-29 Thread Lukasz Majewski

The imx287 based XEA board's revision 2 uses GPIO_3_21 for PHY reset

It is safe to keep the GPIO_2_13 as well, as in the SPL SPI1 is not
used for transmission. This simplifies the code, as the proper
configuration is performed either in falcon boot's read DTB or in
u-boot proper (with correct FIT configuration chosen).

Signed-off-by: Lukasz Majewski 
---

(no changes since v1)

 board/liebherr/xea/spl_xea.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 551ed6fbae..4068a2ad49 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -225,7 +225,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD3__ENET1_TXD1 | MUX_CONFIG_ENET,
-   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset */
+   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset HW Rev. 1*/
+   MX28_PAD_SAIF0_LRCLK__GPIO_3_21, /* PHY reset HW Rev. 2*/
 
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
-- 
2.39.2

[PATCH 1/4] arm: spl: xea: Remove I2S pins configuration from early initialization

2024-03-29 Thread Lukasz Majewski

XEA is not supporting and using I2S codec, so there is no need to
configure pins for it.

Signed-off-by: Lukasz Majewski 
---

(no changes since v1)

 board/liebherr/xea/spl_xea.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index df354cac64..551ed6fbae 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -112,13 +112,6 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_I2C0_SCL__I2C0_SCL,
MX28_PAD_I2C0_SDA__I2C0_SDA,
 
-   /* I2S Codec */
-   MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK,
-   MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK,
-   MX28_PAD_SAIF0_MCLK__SAIF0_MCLK,
-   MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0,
-   MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0,
-
/* PWR-Hold */
MX28_PAD_SPDIF__GPIO_3_27,
 
-- 
2.39.2

[PATCH 0/4] arm: xea: Provide enhancements for XEA board

2024-03-29 Thread Lukasz Majewski



This patch series is a preparatory patch for supporting
different versions of XEA board HW (until problem with
Linux kernel support for multiple revisions is resorted).

Moreover, limits for u-boot.sb and u-boot.img has been set
to avoid binary sizes exceeding in the future.

Changes in v2:
Remove "inline" from get_som_rev() function definition
Squash with 'config: xea: Enable late board initialization to set revision 
variable'
Update commit message
Squash with 'arm: xea: Print information about XEA's SoM HW revision'

Lukasz Majewski (4):
  arm: spl: xea: Remove I2S pins configuration from early initialization
  arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2
  arm: xea: Add support for reading SoM (CPU) board HW revision
  config: xea: Add limits for SPL and u-boot proper sizes

 board/liebherr/xea/spl_xea.c   | 21 +--
 board/liebherr/xea/xea.c   | 49 ++
 configs/imx28_xea_defconfig|  4 +++
 configs/imx28_xea_sb_defconfig |  1 +
 4 files changed, 67 insertions(+), 8 deletions(-)

-- 
2.39.2

[PATCH 6/6] config: xea: Add limits for SPL and u-boot proper sizes

2024-03-28 Thread Lukasz Majewski

The XEA board has following hard constraints regarding size of binaries:
- u-boot.sb < 48 KiB
- u-boot.img < 448 KiB

Added values are supposed to avoid exceeding size of binaries during
future u-boot development.

Signed-off-by: Lukasz Majewski 

---

 configs/imx28_xea_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 6098c1f3be..822a329187 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -21,12 +21,15 @@ CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_STACK=0x2
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x1000
+CONFIG_SPL_SIZE_LIMIT=0xa000
 CONFIG_SPL=y
 CONFIG_ENV_OFFSET_REDUND=0x9
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 CONFIG_SYS_LOAD_ADDR=0x4200
 CONFIG_SPL_PAYLOAD="u-boot.img"
+CONFIG_HAS_BOARD_SIZE_LIMIT=y
+CONFIG_BOARD_SIZE_LIMIT=458752
 CONFIG_TIMESTAMP=y
 CONFIG_FIT=y
 # CONFIG_BOOTMETH_EXTLINUX is not set
-- 
2.39.2

[PATCH 5/6] arm: xea: Print information about XEA's SoM HW revision

2024-03-28 Thread Lukasz Majewski

As now XEA has its second HW revision - this information is printed
when u-boot proper starts.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index 90a1e03077..c117a8cb19 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -294,6 +294,15 @@ int board_late_init(void)
 }
 #endif
 
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+int checkboard(void)
+{
+   printf("Board: LWE XEA SoM HW rev %d\n", get_som_rev());
+
+   return 0;
+}
+#endif
+
 int dram_init(void)
 {
return mxs_dram_init();
-- 
2.39.2

[PATCH 4/6] config: xea: Enable late board initialization to set revision variable

2024-03-28 Thread Lukasz Majewski

The 'board_som_rev' environment variable will be used to point correct
configuration from the Linux FIT file.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c   | 12 
 configs/imx28_xea_defconfig|  1 +
 configs/imx28_xea_sb_defconfig |  1 +
 3 files changed, 14 insertions(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index d9cf27c81b..90a1e03077 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -282,6 +282,18 @@ int board_init(void)
return 0;
 }
 
+#if defined(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+   int ret = env_set_ulong("board_som_rev", get_som_rev());
+
+   if (ret)
+   printf("Cannot set XEA's SoM revision env variable!\n");
+
+   return 0;
+}
+#endif
+
 int dram_init(void)
 {
return mxs_dram_init();
diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 64a0561a34..6098c1f3be 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -39,6 +39,7 @@ CONFIG_BOOTCOMMAND="run ${bootpri} ; run ${bootsec}"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 9872d35c1b..8d48d8c507 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -23,6 +23,7 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 # CONFIG_SPL_FRAMEWORK is not set
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
-- 
2.39.2

[PATCH 3/6] arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2

2024-03-28 Thread Lukasz Majewski

The imx287 based XEA board's revision 2 uses GPIO_3_21 for PHY reset

It is safe to keep the GPIO_2_13 as well, as in the SPL SPI1 is not
used for transmission. This simplifies the code, as the proper
configuration is performed either in falcon boot's read DTB or in
u-boot proper (with correct FIT configuration chosen).

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 71194db235..6cf8f8390e 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -225,7 +225,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD3__ENET1_TXD1 | MUX_CONFIG_ENET,
-   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset */
+   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset HW Rev. 1*/
+   MX28_PAD_SAIF0_LRCLK__GPIO_3_21, /* PHY reset HW Rev. 2*/
 
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
-- 
2.39.2

[PATCH 2/6] arm: xea: Add support for reading SoM (CPU) and base board HW revision

2024-03-28 Thread Lukasz Majewski

The XEA board now has several HW revisions for both SoM and base boards.
This patch provides support for reading those revision ID values in SPL
(u-boot.sb) and then pass this information to u-boot proper, as the
maximal SPL size (~55KiB) is not allowing for having FIT support in it.

It was necessary to handle reading GPIOs values solely in u-boot proper
as one configuration (i.e. 'single binary' - imx28_xea_sb_defconfig)
is not using SPL framework.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 11 +++
 board/liebherr/xea/xea.c | 29 +
 2 files changed, 40 insertions(+)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 551ed6fbae..71194db235 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -230,6 +230,17 @@ const iomux_cfg_t iomux_setup[] = {
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
MX28_PAD_GPMI_WRN__GPIO_0_25 | MUX_CONFIG_BOOT, /* TIVA1 */
+
+   /* HW revision ID Base Board */
+   MX28_PAD_LCD_D12__GPIO_1_12,
+   MX28_PAD_LCD_D13__GPIO_1_13,
+   MX28_PAD_LCD_D14__GPIO_1_14,
+
+   /* HW revision ID (SoM) */
+   MX28_PAD_LCD_D15__GPIO_1_15,
+   MX28_PAD_LCD_D16__GPIO_1_16,
+   MX28_PAD_LCD_D17__GPIO_1_17,
+   MX28_PAD_LCD_D18__GPIO_1_18,
 };
 
 u32 mxs_dram_vals[] = {
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index c8ac526cb4..d9cf27c81b 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -48,6 +48,35 @@ DECLARE_GLOBAL_DATA_PTR;
  * Functions
  */
 
+/*
+ * Reading the HW ID number for XEA SoM module
+ *
+ * GPIOs from Port 1 (GPIO1_15, GPIO1_16, GPIO1_17 and GPIO1_18)
+ * are used to store HW revision information.
+ * Reading of GPIOs values is performed before the Device Model is
+ * bring up as the proper DTB needs to be chosen first.
+ *
+ * Moreover, this approach is required as "single binary" configuration
+ * of U-Boot (imx28_xea_sb_defconfig) is NOT using SPL framework, so
+ * only minimal subset of functionality is provided when ID is read.
+ *
+ * Hence, the direct registers' access.
+ */
+#define XEA_SOM_HW_ID_GPIO_PORT (MXS_PINCTRL_BASE + (0x0900 + ((1) * 0x10)))
+#define XEA_SOM_REV_MASK GENMASK(18, 15)
+#define XEA_SOM_REV_SHIFT 15
+
+static inline u8 get_som_rev(void)
+{
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)XEA_SOM_HW_ID_GPIO_PORT;
+
+   u32 tmp = ~readl(>reg);
+   u8 id = (tmp & XEA_SOM_REV_MASK) >> XEA_SOM_REV_SHIFT;
+
+   return id;
+}
+
 static void init_clocks(void)
 {
/* IO0 clock at 480MHz */
-- 
2.39.2

[PATCH 1/6] arm: spl: xea: Remove I2S pins configuration from early initialization

2024-03-28 Thread Lukasz Majewski

XEA is not supporting and using I2S codec, so there is no need to
configure pins for it.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index df354cac64..551ed6fbae 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -112,13 +112,6 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_I2C0_SCL__I2C0_SCL,
MX28_PAD_I2C0_SDA__I2C0_SDA,
 
-   /* I2S Codec */
-   MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK,
-   MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK,
-   MX28_PAD_SAIF0_MCLK__SAIF0_MCLK,
-   MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0,
-   MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0,
-
/* PWR-Hold */
MX28_PAD_SPDIF__GPIO_3_27,
 
-- 
2.39.2

[PATCH 0/6] arm: xea: Provide enhancements for XEA board

2024-03-28 Thread Lukasz Majewski



This patch series is a preparatory patch for supporting
different versions of XEA board HW (until problem with
Linux kernel support for multiple revisions is resorted).

Moreover, limits for u-boot.sb and u-boot.img has been set
to avoid binary sizes exceeding in the future.


Lukasz Majewski (6):
  arm: spl: xea: Remove I2S pins configuration from early initialization
  arm: xea: Add support for reading SoM (CPU) and base board HW revision
  arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2
  config: xea: Enable late board initialization to set revision variable
  arm: xea: Print information about XEA's SoM HW revision
  config: xea: Add limits for SPL and u-boot proper sizes

 board/liebherr/xea/spl_xea.c   | 21 --
 board/liebherr/xea/xea.c   | 50 ++
 configs/imx28_xea_defconfig|  4 +++
 configs/imx28_xea_sb_defconfig |  1 +
 4 files changed, 68 insertions(+), 8 deletions(-)

-- 
2.39.2

Re: Thoughts about U-boot binary size increase

2024-03-28 Thread Lukasz Majewski

Hi Tom,

> On Thu, Mar 28, 2024 at 01:55:22PM +0100, Lukasz Majewski wrote:
> > Hi Tom,
> >   
> > > On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote:  
> > > > Dear Community,
> > > > 
> > > > I'd like to share with you some thoughts about growth of
> > > > u-boot's binary size for SPL and u-boot proper.
> > > > 
> > > > Board: XEA
> > > > SoC  : imx287 (still in active production)
> > > > Problem: SPL size constrained to ~55 KiB (This cannot be
> > > > exceeded). Board design constraints u-boot proper size to less
> > > > than ~448 KiB
> > > > 
> > > > 
> > > > When XEA was added (2019.07):
> > > > - u-boot.sb (SPL): 37 KiB
> > > > - u-boot.img : 401 KiB
> > > > 
> > > > Now (2024.04):
> > > > - u-boot.sb (SPL): 40 KiB
> > > > - u-boot.img : 427 KiB
> > > > 
> > > > (With a _lot_ of effort put to reduce the size)
> > > > 
> > > > Hence, the question - would it be possible to take more concern
> > > > about the binary size growth?
> > > > 
> > > > Maybe CI could catch patches, which enable by default some
> > > > features and the size is unintentionally increased?
> > > > 
> > > > I'm open for any feedback and thoughts on "stopping" the binary
> > > > size increase.
> > > 
> > > I think that's pretty amazingly small growth for nearly 5 years
> > > of bug fixes and feature enhancements that it's likely minor to
> > > make granular.  
> > 
> > Those results are after using OF_PLATDATA in SPL and other tricks -
> > like compression of DTB in u-boot proper, so this caused some extra
> > effort to keep small.  
> 
> Yes, and I'm still pretty happy with that.

Ok :-)

> I would encourage you to do
> what I suggested, before turning on LTO (as that makes it hard to see
> symbol size changes due to the nature of LTO) as what you asked for in
> your original email is what I do, and have done for a very long time
> now, with 99% of every pull request / branch merge. I'm not saying I
> didn't miss anything, but I am saying it's a matter of specific
> changes and not a general problem. 

Ok. I will check binman's output for symbol sizes changes.

> And if you hadn't previously set
> the options to enforce failure to build if hard size constraints are
> missed, please do so.
> 

I will.

Thanks for input and help.


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: lu...@denx.de


pgpWXlCv80mUZ.pgp
Description: OpenPGP digital signature

Re: Thoughts about U-boot binary size increase

2024-03-28 Thread Lukasz Majewski

Hi Tom,

> On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote:
> > Dear Community,
> > 
> > I'd like to share with you some thoughts about growth of u-boot's
> > binary size for SPL and u-boot proper.
> > 
> > Board: XEA
> > SoC  : imx287 (still in active production)
> > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). 
> >  Board design constraints u-boot proper size to less than
> > ~448 KiB
> > 
> > 
> > When XEA was added (2019.07):
> > - u-boot.sb (SPL): 37 KiB
> > - u-boot.img : 401 KiB
> > 
> > Now (2024.04):
> > - u-boot.sb (SPL): 40 KiB
> > - u-boot.img : 427 KiB
> > 
> > (With a _lot_ of effort put to reduce the size)
> > 
> > Hence, the question - would it be possible to take more concern
> > about the binary size growth?
> > 
> > Maybe CI could catch patches, which enable by default some features
> > and the size is unintentionally increased?
> > 
> > I'm open for any feedback and thoughts on "stopping" the binary size
> > increase.  
> 
> I think that's pretty amazingly small growth for nearly 5 years of bug
> fixes and feature enhancements that it's likely minor to make
> granular.

Those results are after using OF_PLATDATA in SPL and other tricks - like
compression of DTB in u-boot proper, so this caused some extra effort
to keep small.

> If LTO is not enabled on this platform 

As Fabio pointed out - I shall check if LTO can be (safely) enabled for
imx287.

> you should be able
> to use buildman to give you a "bloat" list from v2019.07 to v2024.04
> and see if anything sticks out as being something that can be
> addressed. But that little growth seems pretty good to me at first
> glance.
> 


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: lu...@denx.de


pgpqnWS2bWKxx.pgp
Description: OpenPGP digital signature

Re: Thoughts about U-boot binary size increase

2024-03-28 Thread Lukasz Majewski

Hi Fabio,

> Hi Lukasz,
> 
> On Thu, Mar 28, 2024 at 6:20 AM Lukasz Majewski  wrote:
> >
> > Dear Community,
> >
> > I'd like to share with you some thoughts about growth of u-boot's
> > binary size for SPL and u-boot proper.
> >
> > Board: XEA
> > SoC  : imx287 (still in active production)
> > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded).
> >  Board design constraints u-boot proper size to less than
> > ~448 KiB
> >
> >
> > When XEA was added (2019.07):
> > - u-boot.sb (SPL): 37 KiB
> > - u-boot.img : 401 KiB
> >
> > Now (2024.04):
> > - u-boot.sb (SPL): 40 KiB
> > - u-boot.img : 427 KiB
> >
> > (With a _lot_ of effort put to reduce the size)
> >
> > Hence, the question - would it be possible to take more concern
> > about the binary size growth?
> >
> > Maybe CI could catch patches, which enable by default some features
> > and the size is unintentionally increased?
> >
> > I'm open for any feedback and thoughts on "stopping" the binary size
> > increase.  
> 
> In addition to adding CONFIG_BOARD_SIZE_LIMIT and
> CONFIG_SPL_SIZE_LIMIT checks, could you try the change below?
> 
> diff --git a/arch/arm/mach-imx/mxs/Kconfig
> b/arch/arm/mach-imx/mxs/Kconfig index d2e4205c5ce5..ee8c23d0e04f
> 100644 --- a/arch/arm/mach-imx/mxs/Kconfig
> +++ b/arch/arm/mach-imx/mxs/Kconfig
> @@ -32,6 +32,7 @@ if ARCH_MX28
> 
>  config MX28
> bool
> +   select LTO
> default y
> 
> I did a quick imx28_xea_defconfig build test here:
> 
> U-Boot mainline
> ---
> 
> $ ls -al u-boot.img
> -rw-rw-r-- 1 fabio fabio 444128 mar 28 09:11 u-boot.img
> 
> $ ls -al spl/u-boot-spl.bin
> -rwxrwxr-x 1 fabio fabio 39800 mar 28 09:12 spl/u-boot-spl.bin
> 
> 
> U-Boot mainline + LTO
> ---------
> 
> $ ls -al u-boot.img
> -rw-rw-r-- 1 fabio fabio 424144 mar 28 09:14 u-boot.img
> 
> $ ls -al spl/u-boot-spl.bin
> -rw-rw-r-- 1 fabio fabio 37664 mar 28 09:14 spl/u-boot-spl.bin

Thanks for the tip - I will check if enabling LTO is not causing any
regressions.


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: lu...@denx.de


pgpZann_E8uo3.pgp
Description: OpenPGP digital signature

Re: Thoughts about U-boot binary size increase

2024-03-28 Thread Lukasz Majewski

Hi Marek,

> On 3/28/24 10:20 AM, Lukasz Majewski wrote:
> > Dear Community,
> > 
> > I'd like to share with you some thoughts about growth of u-boot's
> > binary size for SPL and u-boot proper.
> > 
> > Board: XEA
> > SoC  : imx287 (still in active production)
> > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded).
> >  Board design constraints u-boot proper size to less than
> > ~448 KiB
> > 
> > 
> > When XEA was added (2019.07):
> > - u-boot.sb (SPL): 37 KiB
> > - u-boot.img : 401 KiB
> > 
> > Now (2024.04):
> > - u-boot.sb (SPL): 40 KiB  
> 
> Do you know which symbol(s) grew in here ?

I will need to check it.

> 
> > - u-boot.img : 427 KiB
> > 
> > (With a _lot_ of effort put to reduce the size)
> > 
> > Hence, the question - would it be possible to take more concern
> > about the binary size growth?
> > 
> > Maybe CI could catch patches, which enable by default some features
> > and the size is unintentionally increased?  
> 
> Try and set CONFIG_BOARD_SIZE_LIMIT and CONFIG_SPL_SIZE_LIMIT for
> this board, that would trip build error if the size grows too large.

I think that setting CONFIG_BOARD_SIZE_LIMIT and CONFIG_SPL_SIZE_LIMIT
would help for rising the "red flag" of the size limit.

However, I would like to signal that there is a problem with u-boot
size increase.


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: lu...@denx.de


pgpHcGvmLrMzP.pgp
Description: OpenPGP digital signature

Thoughts about U-boot binary size increase

2024-03-28 Thread Lukasz Majewski

Dear Community,

I'd like to share with you some thoughts about growth of u-boot's
binary size for SPL and u-boot proper.

Board: XEA
SoC  : imx287 (still in active production)
Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). 
 Board design constraints u-boot proper size to less than ~448
 KiB


When XEA was added (2019.07):
- u-boot.sb (SPL): 37 KiB
- u-boot.img : 401 KiB

Now (2024.04):
- u-boot.sb (SPL): 40 KiB
- u-boot.img : 427 KiB

(With a _lot_ of effort put to reduce the size)

Hence, the question - would it be possible to take more concern about
the binary size growth?

Maybe CI could catch patches, which enable by default some features and
the size is unintentionally increased?

I'm open for any feedback and thoughts on "stopping" the binary size
increase.

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: lu...@denx.de


pgpLHWRHejX9E.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions

2024-03-27 Thread Lukasz Majewski

Hi Fabio,

> Hi Lukasz,
> 
> On Mon, Mar 25, 2024 at 5:48 AM Lukasz Majewski  wrote:
> 
> > The case here is that I'm modifying the *-u-boot.dts{i} files only.
> > In  
> 
> The diff below shows that you are creating imx28-xea-1.dts and
> imx28-xea-2.dts for U-Boot consumption and renaming the upstream
> imx28-xea.dts to imx28-xea.dts.
> 
> create mode 100644 arch/arm/dts/imx28-xea-1.dts
> create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx28-xea-2.dts
> rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)
> 
> > other words, u-boot will not support features described in Linux
> > DTS.  
> 
> That's OK and this happens frequently.
> 
> For example, upstream devicetree may describes audio codec,
> but U-Boot does not support audio playback.
> 
> Devicetree should be OS agnostic.
> 
> In U-Boot, we want to re-use the upstream Linux devicetree files
> 'as-is'.
> 
> Adding -u-boot.dtsi files is OK though.
> 
> Can you convert the imx28-xea board to OF_UPSTREAM available in the
> U-Boot next branch?
> 
> > Hence, the rename of files (which would be in sync with Linux at
> > some point) looks like not related to Linux DTS (as even after
> > re-sync with upstream Linux those changes will not be in Linux
> > DTS).  
> 
> I did not understand this part, do you mean that Linux will also do
> the imx28-xea.dts => imx28-xea.dtsi rename and will also have the new
> imx28-xea-1.dts and imx28-xea-2.dts?
> 

Just a small update - the Linux kernel's imx28-xea.dts [1] doesn't have
switch/phy properties as the earlier attempts to add L2 switch support
for Linux mainline were not accepted by the network stack community.

Hence, the decision to omit those properties (and there is no decision
if another attempt for L2 switch support upstreaming will be done in the
near future).

In u-boot the -u-boot.dts[i] files were used to add functionality not
(yet) supported in Linux kernel.

To sum up - I cannot create imx28-xea-1.dts and imx28-xea-2.dts in Linux
as properties which are different in those two revisions are not present
in the current Linux dts description. I cannot say when all XEA
functionality will be added to Linux.

Links:

[1] -
https://elixir.bootlin.com/linux/v6.9-rc1/source/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts

> Regards,
> 
> Fabio Estevam




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: lu...@denx.de


pgpKSWujHsiAO.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions

2024-03-26 Thread Lukasz Majewski

Hi Fabio,

> Hi Lukasz,
> 
> On Mon, Mar 25, 2024 at 5:48 AM Lukasz Majewski  wrote:
> 
> > The case here is that I'm modifying the *-u-boot.dts{i} files only.
> > In  
> 
> The diff below shows that you are creating imx28-xea-1.dts and
> imx28-xea-2.dts for U-Boot consumption and renaming the upstream
> imx28-xea.dts to imx28-xea.dts.
> 
> create mode 100644 arch/arm/dts/imx28-xea-1.dts
> create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx28-xea-2.dts
> rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)
> 

Yes, exactly.

> > other words, u-boot will not support features described in Linux
> > DTS.  
> 
> That's OK and this happens frequently.
> 
> For example, upstream devicetree may describes audio codec,
> but U-Boot does not support audio playback.
> 
> Devicetree should be OS agnostic.
> 

Ok.

> In U-Boot, we want to re-use the upstream Linux devicetree files
> 'as-is'.
> 

Yes, I'm fully aware of this. However, the U-Boot size increases
rapidly...

> Adding -u-boot.dtsi files is OK though.
> 

Yes, this is a good way (with /delete-node) to reduce the size.

> Can you convert the imx28-xea board to OF_UPSTREAM available in the
> U-Boot next branch?

I will check if XEA can be moved to OF_UPSTREAM.

> 
> > Hence, the rename of files (which would be in sync with Linux at
> > some point) looks like not related to Linux DTS (as even after
> > re-sync with upstream Linux those changes will not be in Linux
> > DTS).  
> 
> I did not understand this part, do you mean that Linux will also do
> the imx28-xea.dts => imx28-xea.dtsi rename and will also have the new
> imx28-xea-1.dts and imx28-xea-2.dts?

Yes. Exactly. I started the conversion from u-boot. Updating Linux DTS
will be next.

> 
> Regards,
> 
> Fabio Estevam




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: lu...@denx.de


pgppYXgAbZoRO.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions

2024-03-25 Thread Lukasz Majewski

Hi Fabio,

> Hi Lukasz,
> 
> On Fri, Mar 22, 2024 at 8:43 AM Lukasz Majewski  wrote:
> 
> >  arch/arm/dts/Makefile |  3 +-
> >  arch/arm/dts/imx28-xea-1-u-boot.dtsi  | 11 
> >  arch/arm/dts/imx28-xea-1.dts  |  8 +++
> >  arch/arm/dts/imx28-xea-2-u-boot.dtsi  | 11 
> >  arch/arm/dts/imx28-xea-2.dts  |  8 +++
> >  arch/arm/dts/imx28-xea-u-boot.dtsi|  1 -
> >  .../arm/dts/{imx28-xea.dts => imx28-xea.dtsi} |  0  
> 
> This rename deviates from the upstream devicetree name.
> 
> Ideally, we should convert to OF_UPSTREAM available in U-Boot next.
> 
> >  board/liebherr/xea/spl_xea.c  | 21 +++---
> >  board/liebherr/xea/xea.c  | 65
> > +++ board/liebherr/xea/xea.env|
> >  4 +- configs/imx28_xea_defconfig   |  5 +-
> >  configs/imx28_xea_sb_defconfig|  5 +-
> >  12 files changed, 128 insertions(+), 14 deletions(-)
> >  create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi  
> 
> >  create mode 100644 arch/arm/dts/imx28-xea-1.dts
> >  create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/imx28-xea-2.dts
> >  rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)  
> 
> You should upstream imx28-xea-1.dts and imx28-xea-2.dts first.

The case here is that I'm modifying the *-u-boot.dts{i} files only. In
other words, u-boot will not support features described in Linux DTS.

Hence, the rename of files (which would be in sync with Linux at some
point) looks like not related to Linux DTS (as even after re-sync with
upstream Linux those changes will not be in Linux DTS).


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: lu...@denx.de


pgpj33eMp5EwM.pgp
Description: OpenPGP digital signature

[PATCH 12/12] arm: env: Add support for booting different HW revisions of XEA boards

2024-03-22 Thread Lukasz Majewski

In the scenario of recovery, the FitImage is used to boot the system.
This patch provides support for deciding which dtb configuration shall
be used.

Signed-off-by: Lukasz Majewski 

---

 board/liebherr/xea/xea.env | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/liebherr/xea/xea.env b/board/liebherr/xea/xea.env
index ac6ac898ec..9dec4016a0 100644
--- a/board/liebherr/xea/xea.env
+++ b/board/liebherr/xea/xea.env
@@ -112,7 +112,7 @@ sf_swu=
sf read ${loadaddr} ${sf_kernel_offset} ${sf_swu_size} ;
setenv bootargs root=/dev/ram0 rw ;
run addargs ;
-   bootm ${loadaddr} ;
+   bootm ${loadaddr}#conf-imx28-${arch}-${board_som_rev}.dtb ;
fi
 net_mmc=
if run netload mmcargs addargs ; then
-- 
2.39.2

[PATCH 11/12] arm: xea: Print information about XEA's SoM HW revision

2024-03-22 Thread Lukasz Majewski

As now XEA has its second HW revision - this information is printed
when u-boot proper starts.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index 5bac614153..876e8a70ab 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -294,6 +294,15 @@ int board_late_init(void)
 }
 #endif
 
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+int checkboard(void)
+{
+   printf("Board: LWE XEA SoM HW rev %d\n", get_som_rev());
+
+   return 0;
+}
+#endif
+
 int dram_init(void)
 {
return mxs_dram_init();
-- 
2.39.2

[PATCH 10/12] config: xea: Enable late board initialization to set revision variable

2024-03-22 Thread Lukasz Majewski

The 'board_som_rev' environment variable will be used to point correct
configuration from the Linux FIT file.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c   | 12 
 configs/imx28_xea_defconfig|  1 +
 configs/imx28_xea_sb_defconfig |  1 +
 3 files changed, 14 insertions(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index 615d266b8f..5bac614153 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -282,6 +282,18 @@ int board_init(void)
return 0;
 }
 
+#if defined(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+   int ret = env_set_ulong("board_som_rev", get_som_rev());
+
+   if (ret)
+   printf("Cannot set XEA's SoM revision env variable!\n");
+
+   return 0;
+}
+#endif
+
 int dram_init(void)
 {
return mxs_dram_init();
diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index bc8c167b1f..c416635b24 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -39,6 +39,7 @@ CONFIG_BOOTCOMMAND="run ${bootpri} ; run ${bootsec}"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 691edc2834..78e59b4cb2 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -23,6 +23,7 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run prebootcmd"
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
 # CONFIG_SPL_FRAMEWORK is not set
 CONFIG_SPL_NO_BSS_LIMIT=y
 CONFIG_SPL_BOARD_INIT=y
-- 
2.39.2

[PATCH 09/12] arm: config: xea: Enable support for multiple DTBs for XEA board

2024-03-22 Thread Lukasz Majewski

After this change u-boot proper is able to support two HW revisions of the
XEA board.

Signed-off-by: Lukasz Majewski 
---

 configs/imx28_xea_defconfig| 2 ++
 configs/imx28_xea_sb_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 42cbc3d34c..bc8c167b1f 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -81,6 +81,8 @@ CONFIG_CMD_MTDPARTS=y
 CONFIG_DOS_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="imx28-xea-1 imx28-xea-2"
+CONFIG_MULTI_DTB_FIT=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent interrupts"
 CONFIG_SPL_OF_PLATDATA=y
 # CONFIG_SPL_OF_PLATDATA_PARENT is not set
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 30b3568e7f..691edc2834 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -55,6 +55,8 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="imx28-xea-1 imx28-xea-2"
+CONFIG_MULTI_DTB_FIT=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent interrupts"
 CONFIG_SPL_OF_PLATDATA=y
 # CONFIG_SPL_OF_PLATDATA_PARENT is not set
-- 
2.39.2

[PATCH 08/12] arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2

2024-03-22 Thread Lukasz Majewski

The imx287 based XEA board's revision 2 uses GPIO_3_21 for PHY reset

It is safe to keep the GPIO_2_13 as well, as in the SPL SPI1 is not
used for transmission. This simplifies the code, as the proper
configuration is performed either in falcon boot's read DTB or in
u-boot proper (with correct FIT configuration chosen).

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 71194db235..6cf8f8390e 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -225,7 +225,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD3__ENET1_TXD1 | MUX_CONFIG_ENET,
-   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset */
+   MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset HW Rev. 1*/
+   MX28_PAD_SAIF0_LRCLK__GPIO_3_21, /* PHY reset HW Rev. 2*/
 
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
-- 
2.39.2

[PATCH 07/12] dts: xea: Add device tree description for XEA HW rev. 2

2024-03-22 Thread Lukasz Majewski

For SPL and u-boot proper, the difference between revsions boils
down only to the GPIO pin for PHY reset.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/Makefile|  3 ++-
 arch/arm/dts/imx28-xea-2-u-boot.dtsi | 11 +++
 arch/arm/dts/imx28-xea-2.dts |  8 
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx28-xea-2.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4fc508bcfc..69131599ae 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -879,7 +879,8 @@ dtb-$(CONFIG_TARGET_MX23_OLINUXINO) += \
 
 dtb-$(CONFIG_MX28) += \
imx28-evk.dtb \
-   imx28-xea-1.dtb
+   imx28-xea-1.dtb \
+   imx28-xea-2.dtb
 
 dtb-$(CONFIG_MX51) += \
imx51-babbage.dtb
diff --git a/arch/arm/dts/imx28-xea-2-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-2-u-boot.dtsi
new file mode 100644
index 00..6ce82531d5
--- /dev/null
+++ b/arch/arm/dts/imx28-xea-2-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2024
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+#include "imx28-xea-u-boot.dtsi"
+
+ {
+   phy-reset-gpios = < 21 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/dts/imx28-xea-2.dts b/arch/arm/dts/imx28-xea-2.dts
new file mode 100644
index 00..8cb1190ba5
--- /dev/null
+++ b/arch/arm/dts/imx28-xea-2.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2024
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+/dts-v1/;
+#include "imx28-xea.dtsi"
-- 
2.39.2

[PATCH 06/12] arm: xea: Add support for multiple dtbs in u-boot

2024-03-22 Thread Lukasz Majewski

As XEA board uses imx287, which has some constrains on SPL (u-boot.sb)
size - it must be less than ~55 KiB, multiple boards versions are included
in u-boot proper's FIT image.

The decision of using proper configuration is based on information passed
from SPL (u-boot.sb) in OCRAM dedicated location (0xE000 - 2).

This board also uses falcon boot for production setup, so the proper
dtb is flashed during production (also based on GPIO values describing
HW ID).

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index d9cf27c81b..615d266b8f 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -287,6 +287,21 @@ int dram_init(void)
return mxs_dram_init();
 }
 
+#if defined(CONFIG_MULTI_DTB_FIT)
+int board_fit_config_name_match(const char *name)
+{
+   u8 rev_id = get_som_rev();
+   char board[11];
+
+   sprintf(board, "imx28-xea-%d", rev_id);
+
+   if (!strncmp(name, board, sizeof(board)))
+   return 0;
+
+   return -EINVAL;
+}
+#endif
+
 #ifdef CONFIG_OF_BOARD_SETUP
 static int fdt_fixup_l2switch(void *blob)
 {
-- 
2.39.2

[PATCH 05/12] dts: xea: Remove outdated comment

2024-03-22 Thread Lukasz Majewski

The comment in u-boot specific adjustment to XEA DTS is not valid anymore.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-1-u-boot.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/dts/imx28-xea-1-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
index 2903be2089..6cb6c66924 100644
--- a/arch/arm/dts/imx28-xea-1-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
@@ -4,10 +4,6 @@
  * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
  */
 
-/*
- * The minimal augmentation DTS U-Boot file to allow eMMC driver
- * configuration in SPL for falcon boot.
- */
 #include "imx28-xea-u-boot.dtsi"
 
  {
-- 
2.39.2

[PATCH 04/12] dts: xea: Move phy-reset-gpios property to version specific DTS file

2024-03-22 Thread Lukasz Majewski

The DTS description in XEA for mac0 node in u-boot differs considerably
from what we do have available in Linux, as u-boot is not supporting L2
switch (i.e. 'fixed-link' property is used).

To facilitate HW revision management - this particular property has been
moved to version specific file.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-1-u-boot.dtsi | 4 
 arch/arm/dts/imx28-xea-u-boot.dtsi   | 1 -
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/imx28-xea-1-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
index 4b2b21eeae..2903be2089 100644
--- a/arch/arm/dts/imx28-xea-1-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
@@ -9,3 +9,7 @@
  * configuration in SPL for falcon boot.
  */
 #include "imx28-xea-u-boot.dtsi"
+
+ {
+   phy-reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index bdbeca528c..13a581f7a6 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -50,7 +50,6 @@
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
phy-supply = <_fec_3v3>;
-   phy-reset-gpios = < 13 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-post-delay = <1>;
status = "okay";
-- 
2.39.2

[PATCH 03/12] arm: xea: Rename imx28-xea.dts to imx28-xea-1.dts

2024-03-22 Thread Lukasz Majewski

The former imx28-xea.dts file has been renamed to imx28-xea.dtsi, which
is included to new imx28-xea-1.dts file.

This is a preparatory work to add support for multiple versions of XEA
boards to u-boot.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/Makefile  |  2 +-
 arch/arm/dts/imx28-xea-1-u-boot.dtsi   | 11 +++
 arch/arm/dts/imx28-xea-1.dts   |  8 
 arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} |  0
 board/liebherr/xea/xea.env |  2 +-
 configs/imx28_xea_defconfig|  2 +-
 configs/imx28_xea_sb_defconfig |  2 +-
 7 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx28-xea-1.dts
 rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b102ffb5f6..4fc508bcfc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -879,7 +879,7 @@ dtb-$(CONFIG_TARGET_MX23_OLINUXINO) += \
 
 dtb-$(CONFIG_MX28) += \
imx28-evk.dtb \
-   imx28-xea.dtb
+   imx28-xea-1.dtb
 
 dtb-$(CONFIG_MX51) += \
imx51-babbage.dtb
diff --git a/arch/arm/dts/imx28-xea-1-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
new file mode 100644
index 00..4b2b21eeae
--- /dev/null
+++ b/arch/arm/dts/imx28-xea-1-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2024
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+/*
+ * The minimal augmentation DTS U-Boot file to allow eMMC driver
+ * configuration in SPL for falcon boot.
+ */
+#include "imx28-xea-u-boot.dtsi"
diff --git a/arch/arm/dts/imx28-xea-1.dts b/arch/arm/dts/imx28-xea-1.dts
new file mode 100644
index 00..8cb1190ba5
--- /dev/null
+++ b/arch/arm/dts/imx28-xea-1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2024
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+/dts-v1/;
+#include "imx28-xea.dtsi"
diff --git a/arch/arm/dts/imx28-xea.dts b/arch/arm/dts/imx28-xea.dtsi
similarity index 100%
rename from arch/arm/dts/imx28-xea.dts
rename to arch/arm/dts/imx28-xea.dtsi
diff --git a/board/liebherr/xea/xea.env b/board/liebherr/xea/xea.env
index 043099ae87..ac6ac898ec 100644
--- a/board/liebherr/xea/xea.env
+++ b/board/liebherr/xea/xea.env
@@ -3,7 +3,7 @@ bootpri=mmc_mmc
 bootsec=sf_swu
 consdev=ttyAMA0
 baudrate=115200
-dtbfile=imx28-xea.dtb
+dtbfile=imx28-xea-1.dtb
 rootdev=/dev/mmcblk0p2
 netdev=eth0
 swufile=swupdate-image-xea-upd.itb
diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 64a0561a34..42cbc3d34c 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -11,7 +11,7 @@ CONFIG_SF_DEFAULT_SPEED=4000
 CONFIG_IMX_CONFIG=""
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="imx28-xea"
+CONFIG_DEFAULT_DEVICE_TREE="imx28-xea-1"
 CONFIG_SPL_TEXT_BASE=0x1000
 CONFIG_TARGET_XEA=y
 CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 9872d35c1b..30b3568e7f 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -9,7 +9,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_SF_DEFAULT_SPEED=4000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="imx28-xea"
+CONFIG_DEFAULT_DEVICE_TREE="imx28-xea-1"
 CONFIG_SPL_TEXT_BASE=0x1000
 CONFIG_TARGET_XEA=y
 CONFIG_SPL=y
-- 
2.39.2

[PATCH 02/12] arm: xea: Add support for reading SoM (CPU) and base board HW revision

2024-03-22 Thread Lukasz Majewski

The XEA board now has several HW revisions for both SoM and base boards.
This patch provides support for reading those revision ID values in SPL
(u-boot.sb) and then pass this information to u-boot proper, as the
maximal SPL size (~55KiB) is not allowing for having FIT support in it.

It was necessary to handle reading GPIOs values solely in u-boot proper
as one configuration (i.e. 'single binary' - imx28_xea_sb_defconfig)
is not using SPL framework.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 11 +++
 board/liebherr/xea/xea.c | 29 +
 2 files changed, 40 insertions(+)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 551ed6fbae..71194db235 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -230,6 +230,17 @@ const iomux_cfg_t iomux_setup[] = {
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
MX28_PAD_GPMI_WRN__GPIO_0_25 | MUX_CONFIG_BOOT, /* TIVA1 */
+
+   /* HW revision ID Base Board */
+   MX28_PAD_LCD_D12__GPIO_1_12,
+   MX28_PAD_LCD_D13__GPIO_1_13,
+   MX28_PAD_LCD_D14__GPIO_1_14,
+
+   /* HW revision ID (SoM) */
+   MX28_PAD_LCD_D15__GPIO_1_15,
+   MX28_PAD_LCD_D16__GPIO_1_16,
+   MX28_PAD_LCD_D17__GPIO_1_17,
+   MX28_PAD_LCD_D18__GPIO_1_18,
 };
 
 u32 mxs_dram_vals[] = {
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index c8ac526cb4..d9cf27c81b 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -48,6 +48,35 @@ DECLARE_GLOBAL_DATA_PTR;
  * Functions
  */
 
+/*
+ * Reading the HW ID number for XEA SoM module
+ *
+ * GPIOs from Port 1 (GPIO1_15, GPIO1_16, GPIO1_17 and GPIO1_18)
+ * are used to store HW revision information.
+ * Reading of GPIOs values is performed before the Device Model is
+ * bring up as the proper DTB needs to be chosen first.
+ *
+ * Moreover, this approach is required as "single binary" configuration
+ * of U-Boot (imx28_xea_sb_defconfig) is NOT using SPL framework, so
+ * only minimal subset of functionality is provided when ID is read.
+ *
+ * Hence, the direct registers' access.
+ */
+#define XEA_SOM_HW_ID_GPIO_PORT (MXS_PINCTRL_BASE + (0x0900 + ((1) * 0x10)))
+#define XEA_SOM_REV_MASK GENMASK(18, 15)
+#define XEA_SOM_REV_SHIFT 15
+
+static inline u8 get_som_rev(void)
+{
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)XEA_SOM_HW_ID_GPIO_PORT;
+
+   u32 tmp = ~readl(>reg);
+   u8 id = (tmp & XEA_SOM_REV_MASK) >> XEA_SOM_REV_SHIFT;
+
+   return id;
+}
+
 static void init_clocks(void)
 {
/* IO0 clock at 480MHz */
-- 
2.39.2

[PATCH 01/12] arm: spl: xea: Remove I2S pins configuration from early initialization

2024-03-22 Thread Lukasz Majewski

XEA is not supporting and using I2S codec, so there is no need to
configure pins for it.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/spl_xea.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index df354cac64..551ed6fbae 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -112,13 +112,6 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_I2C0_SCL__I2C0_SCL,
MX28_PAD_I2C0_SDA__I2C0_SDA,
 
-   /* I2S Codec */
-   MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK,
-   MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK,
-   MX28_PAD_SAIF0_MCLK__SAIF0_MCLK,
-   MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0,
-   MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0,
-
/* PWR-Hold */
MX28_PAD_SPDIF__GPIO_3_27,
 
-- 
2.39.2

[PATCH 00/12] arm: xea: Provide support for different XEA board HW versions

2024-03-22 Thread Lukasz Majewski



This patch set provides support for different XEA board revisions.
Due to very limited SPL size, the board's switch DTB decision is
performed very early in u-boot proper; before driver model is set.

Adjustments for DTS between revisions are for the u-boot adjustment code
(i.e. tweaks due to functionality not supported in u-boot), hence
there is no need to update them from Linux upstream DTS.


Lukasz Majewski (12):
  arm: spl: xea: Remove I2S pins configuration from early initialization
  arm: xea: Add support for reading SoM (CPU) and base board HW revision
  arm: xea: Rename imx28-xea.dts to imx28-xea-1.dts
  dts: xea: Move phy-reset-gpios property to version specific DTS file
  dts: xea: Remove outdated comment
  arm: xea: Add support for multiple dtbs in u-boot
  dts: xea: Add device tree description for XEA HW rev. 2
  arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2
  arm: config: xea: Enable support for multiple DTBs for XEA board
  config: xea: Enable late board initialization to set revision variable
  arm: xea: Print information about XEA's SoM HW revision
  arm: env: Add support for booting different HW revisions of XEA boards

 arch/arm/dts/Makefile |  3 +-
 arch/arm/dts/imx28-xea-1-u-boot.dtsi  | 11 
 arch/arm/dts/imx28-xea-1.dts  |  8 +++
 arch/arm/dts/imx28-xea-2-u-boot.dtsi  | 11 
 arch/arm/dts/imx28-xea-2.dts  |  8 +++
 arch/arm/dts/imx28-xea-u-boot.dtsi|  1 -
 .../arm/dts/{imx28-xea.dts => imx28-xea.dtsi} |  0
 board/liebherr/xea/spl_xea.c  | 21 +++---
 board/liebherr/xea/xea.c  | 65 +++
 board/liebherr/xea/xea.env|  4 +-
 configs/imx28_xea_defconfig   |  5 +-
 configs/imx28_xea_sb_defconfig|  5 +-
 12 files changed, 128 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx28-xea-1.dts
 create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx28-xea-2.dts
 rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)

-- 
2.39.2

[PATCH v3 3/3] arm: xea: Add support for boot image source descriptor in SPL

2024-01-15 Thread Lukasz Majewski

From: Anatolij Gustschin 

We load two boot image source descriptor structures from last
two sectors in the SPI NOR flash and determine the boot source
for loading the kernel/DTB images, then adjust the boot order for
loading image from eMMC boot0 or boot1 partition.

Signed-off-by: Anatolij Gustschin 
Signed-off-by: Lukasz Majewski 

---

Changes in v3:
- None

 board/liebherr/xea/boot_img_scr.h | 27 ++
 board/liebherr/xea/xea.c  | 85 +++
 2 files changed, 112 insertions(+)
 create mode 100644 board/liebherr/xea/boot_img_scr.h

diff --git a/board/liebherr/xea/boot_img_scr.h 
b/board/liebherr/xea/boot_img_scr.h
new file mode 100644
index 00..baa3072b49
--- /dev/null
+++ b/board/liebherr/xea/boot_img_scr.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Struct for boot image source description for placing in last
+ * two SPI NOR flash sectors on legcom.
+ */
+
+struct boot_img_src {
+   u8 magic;   /* Must be 'B' = 0x42 */
+   u8 flags;   /* flags to specify mmcblk[0|1] boot[0|1] */
+   u8 crc8;/* CRC-8 over above two bytes */
+} __packed;
+
+/*
+ * Bit definition in boot_img_src.flags:
+ *  Bit 0: mmcblk device 0 or 1 (1 - if this bit set)
+ *  Bit 1: mmcblk boot partition 0 or 1.
+ * for eMMC: boot0 if this bit is cleared, boot1 - if set
+ * for SD-card the boot partition value will always be 0
+ * (independent of the value of this bit)
+ *
+ */
+#define BOOT_SRC_MMC1  BIT(0)
+#define BOOT_SRC_PART1 BIT(1)
+
+/* Offset of the first boot image source descriptor in SPI NOR */
+#define SPI_FLASH_BOOT_SRC_OFFS0xFE
+#define SPI_FLASH_SECTOR_SIZE  0x1
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index e4d2eb65cc..c8ac526cb4 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -32,6 +32,11 @@
 #include 
 #include 
 #include 
+#include 
+#include "boot_img_scr.h"
+
+#include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 #include 
@@ -66,6 +71,52 @@ void board_init_f(ulong arg)
preloader_console_init();
 }
 
+static struct boot_img_src img_src[2];
+static int spi_load_boot_info(void)
+{
+   struct spi_flash *flash;
+   int err;
+
+   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+   CONFIG_SF_DEFAULT_CS,
+   CONFIG_SF_DEFAULT_SPEED,
+   CONFIG_SF_DEFAULT_MODE);
+   if (!flash) {
+   printf("%s: SPI probe err\n", __func__);
+   return -ENODEV;
+   }
+
+   /*
+* Load both boot info structs from SPI flash
+*/
+   err = spi_flash_read(flash, SPI_FLASH_BOOT_SRC_OFFS,
+sizeof(img_src[0]),
+(void *)_src[0]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   err = spi_flash_read(flash,
+SPI_FLASH_BOOT_SRC_OFFS + SPI_FLASH_SECTOR_SIZE,
+sizeof(img_src[0]),
+(void *)_src[1]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   debug("%s: BI0 0x%x 0x%x 0x%x\n", __func__,
+ img_src[0].magic, img_src[0].flags, img_src[0].crc8);
+
+   debug("%s: BI1 0x%x 0x%x 0x%x\n", __func__,
+ img_src[1].magic, img_src[1].flags, img_src[1].crc8);
+
+   return 0;
+}
+
 static int boot_tiva0, boot_tiva1;
 
 /* Check if TIVAs request booting via U-Boot proper */
@@ -114,6 +165,40 @@ void spl_board_init(void)
boot_tiva1 = dm_gpio_get_value();
 }
 
+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+   int i, src_idx = -1, ret;
+
+   ret = spi_load_boot_info();
+   if (ret) {
+   printf("%s: Cannot read XEA boot info! [%d]\n", __func__, ret);
+   /* To avoid bricking board - by default boot from boot0 eMMC */
+   return 1;
+   }
+
+   for (i = 0; i < 2; i++) {
+   if (img_src[i].magic == 'B' &&
+   img_src[i].crc8 == crc8(0, _src[i].magic, 2)) {
+   src_idx = i;
+   break;
+   }
+   }
+
+   debug("%s: src idx: %d\n", __func__, src_idx);
+
+   if (src_idx < 0)
+   /*
+* Always use eMMC (mmcblkX) boot0 if no
+* valid image source description found
+*/
+   return 1;
+
+   if (img_src[src_idx].flags & BOOT_SRC_PART1)
+   return 2;
+
+   return 1;
+}
+
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = BOOT_DEVICE_MMC1;
-- 
2.39.2

[PATCH v3 2/3] arm: config: Enable CRC8 support in SPL on imx287 XEA board

2024-01-15 Thread Lukasz Majewski

The boot0/1 feature uses simple CRC8 to check (in SPL) if
SPI-NOR content is not corrupted, hence the need to enable
it.

Signed-off-by: Lukasz Majewski 

---

Changes in v3:
- None

 configs/imx28_xea_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index c1b0487f7e..64a0561a34 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -123,4 +123,5 @@ CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
+CONFIG_SPL_CRC8=y
 # CONFIG_SPL_OF_LIBFDT is not set
-- 
2.39.2

[PATCH v3 1/3] arm: xea: Move XEA's environment variables from xea.h to xea.env

2024-01-15 Thread Lukasz Majewski

The default set of environment variables from CFG_EXTRA_ENV_SETTINGS
has been moved to a separate file - board/liebherr/xea/xea.env

Adjustments done:
- fitImage support
- SPI-NOR layout re-organization

Signed-off-by: Lukasz Majewski 

---

Changes in v3:
- Remove customer's default IP settings for production (hardcoded
  values)
- Add missing dtbfile env variable

 board/liebherr/xea/xea.env | 139 
 include/configs/xea.h  | 140 -
 2 files changed, 139 insertions(+), 140 deletions(-)
 create mode 100644 board/liebherr/xea/xea.env

diff --git a/board/liebherr/xea/xea.env b/board/liebherr/xea/xea.env
new file mode 100644
index 00..b87b7e5801
--- /dev/null
+++ b/board/liebherr/xea/xea.env
@@ -0,0 +1,139 @@
+bootmode=update
+bootpri=mmc_mmc
+bootsec=sf_swu
+consdev=ttyAMA0
+baudrate=115200
+dtbfile=imx28-xea.dtb
+rootdev=/dev/mmcblk0p2
+netdev=eth0
+swufile=swupdate-image-xea-upd.itb
+sf_kernel_offset=0xA
+sf_swu_size=0xF4
+ethact=FEC
+arch=xea
+lwe_env=
+   if dhcp ${loadaddr} ${hostname}/${lwe_uenv} ; then
+   source ${loadaddr};
+   fi
+lwe_uenv=env_uboot_xea.bin
+do_update_mmc=
+   if mmc rescan ; then
+   mmc dev 0 ${update_mmc_part} ;
+   if dhcp ${hostname}/${update_filename} ; then
+   setexpr fw_sz ${filesize} / 0x200 ;
+   setexpr fw_sz ${fw_sz} + 1 ;
+   mmc write ${loadaddr} ${update_offset} ${fw_sz} ;
+   fi ;
+   fi
+do_update_sf=
+   if sf probe ; then
+   if dhcp ${hostname}/${update_filename} ; then
+   sf erase ${update_offset} +${filesize} ;
+   sf write ${loadaddr} ${update_offset} ${filesize} ;
+   fi ;
+   fi
+factory_reset=
+   if sf probe ; then
+   run update_swu ;
+   setenv bootmode update ;
+   saveenv ;
+   fi
+update_spl_filename=u-boot.sb
+update_spl=
+   setenv update_filename ${update_spl_filename} ;
+   setenv update_offset 0 ;
+   run do_update_sf
+update_uboot_filename=u-boot.img
+update_uboot=
+   setenv update_filename ${update_uboot_filename} ;
+   setenv update_offset 0x1 ;
+   run do_update_sf ;
+   setenv update_mmc_part 1 ;
+   setenv update_offset 0 ;
+   run do_update_mmc ;
+   setenv update_mmc_part 2 ;
+   run do_update_mmc
+update_kernel_filename=uImage
+update_kernel=
+   setenv update_mmc_part 1 ;
+   setenv update_filename ${update_kernel_filename} ;
+   setenv update_offset 0x800 ;
+   run do_update_mmc ;
+   setenv update_filename ${dtbfile} ;
+   setenv update_offset 0x400 ;
+   run do_update_mmc
+update_swu=
+   setenv update_filename ${swufile} ;
+   setenv update_offset ${sf_kernel_offset} ;
+   run do_update_sf
+addcons=
+   setenv bootargs ${bootargs}
+   console=${consdev},${baudrate}
+addip=
+   setenv bootargs ${bootargs}
+   ip=${ipaddr}:${serverip}:${gatewayip}:
+   ${netmask}:${hostname}:${netdev}:off
+addmisc=
+   setenv bootargs ${bootargs} ${miscargs}
+addargs=run addcons addmisc
+mmcload=
+   mmc rescan ;
+   mmc dev 0 1 ;
+   mmc read ${loadaddr} 0x800 0x2000 ;
+   mmc read ${dtbaddr} 0x400 0x80
+netload=
+   dhcp ${loadaddr} ${hostname}/${bootfile} ;
+   tftp ${dtbaddr} ${hostname}/${dtbfile}
+usbload=
+   usb start ;
+   load usb 0:1 ${loadaddr} ${bootfile}
+miscargs=panic=1
+mmcargs=setenv bootargs root=${rootdev} rw rootwait
+nfsargs=
+   setenv bootargs root=/dev/nfs rw
+   nfsroot=${serverip}:${rootpath},v3,tcp
+mmc_mmc=
+   if run mmcload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+mmc_nfs=
+   if run mmcload nfsargs addip addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+sf_mmc=
+   if run sfload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+sf_swu=
+   if sf probe ; then
+   sf read ${loadaddr} ${sf_kernel_offset} ${sf_swu_size} ;
+   setenv bootargs root=/dev/ram0 rw ;
+   run addargs ;
+   bootm ${loadaddr} ;
+   fi
+net_mmc=
+   if run netload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+net_nfs=
+   if run netload nfsargs addip addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+prebootcmd=
+   if test ${envsaved} != y ; then ;
+   setenv envsaved y ;
+   saveenv ;
+   fi ;
+   if test ${bootmode} = normal ; then
+   setenv bootdelay 0 ;
+   setenv bootpri mmc_mmc ;
+   elif test ${bootmode} = devel ; then
+   setenv bootdelay 3 ;
+   setenv bootpri net_mmc ;
+   else
+   if test ${bootmode} != update ; then
+   echo Warning: unknown bootmode ${bootmode} ;
+   fi ;
+   setenv bootdelay 1 ;
+   setenv bootpri sf_swu ;
+   fi
diff --git a/include/configs/xea.h b/include/configs/xea.h
index 04ca5aa12a..00d6274873 100644
--- a/include/configs/xea.h
+++ b

[PATCH] defconfig: xea: Change default spi-nor memory bus to 2 (single binary)

2024-01-12 Thread Lukasz Majewski

After the re-sync with Linux kernel (v6.0) of the XEA DTS
(SHA1: 7d08ddd09b75e7a3c103cc0d0d3ed700287f268e) the alias
for SPI bus, to which SPI-NOR  memory is connected, has changed from
'spi3' to 'spi2'.

To be in sync with current u-boot's xea dts, the default bus number
(which allows running 'sf probe' without any extra parameters given)
has been adjusted.

Signed-off-by: Lukasz Majewski 

---

 configs/imx28_xea_sb_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 0b3259866e..9872d35c1b 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -74,7 +74,7 @@ CONFIG_MMC_MXS=y
 CONFIG_MTD=y
 CONFIG_DM_MTD=y
 CONFIG_DM_SPI_FLASH=y
-CONFIG_SF_DEFAULT_BUS=3
+CONFIG_SF_DEFAULT_BUS=2
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.39.2

Re: [PATCH v2 1/3] arm: xea: Move XEA's environment variables from xea.h to xea.env

2024-01-11 Thread Lukasz Majewski

Hi Fabio,

> Hi Fabio,
> 
> > On Thu, Jan 11, 2024 at 8:16 AM Fabio Estevam 
> > wrote:  
> > >
> > > Hi Lukasz,
> > >
> > > On Thu, Jan 11, 2024 at 8:06 AM Lukasz Majewski 
> > > wrote:   
> > > > +serverip=10.8.217.79
> > > > +nfs_serverip=10.8.218.113
> > > > +gatewayip=10.8.209.250
> > >
> > > These IP addresses should not be hardcoded here.
> > >
> > > They were not present in xea.h originally. Please remove them.
> > 
> > One more thing: xea.h had:
> > "dtbfile=imx28-xea.dtb\0"
> > 
> > but  I don't see dtbfile declared inside the new xea.env.  
> 
> Thanks for spotting it - I've forgotten to remove it after moving
> forward to fitImage.
> 
> I will remove it.
> 

This will be added not removed...

> 
> 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:
> lu...@denx.de




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: lu...@denx.de


pgptER0uzTE22.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 1/3] arm: xea: Move XEA's environment variables from xea.h to xea.env

2024-01-11 Thread Lukasz Majewski

Hi Fabio,

> On Thu, Jan 11, 2024 at 8:16 AM Fabio Estevam 
> wrote:
> >
> > Hi Lukasz,
> >
> > On Thu, Jan 11, 2024 at 8:06 AM Lukasz Majewski 
> > wrote: 
> > > +serverip=10.8.217.79
> > > +nfs_serverip=10.8.218.113
> > > +gatewayip=10.8.209.250  
> >
> > These IP addresses should not be hardcoded here.
> >
> > They were not present in xea.h originally. Please remove them.  
> 
> One more thing: xea.h had:
> "dtbfile=imx28-xea.dtb\0"
> 
> but  I don't see dtbfile declared inside the new xea.env.

Thanks for spotting it - I've forgotten to remove it after moving
forward to fitImage.

I will remove it.


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: lu...@denx.de


pgpbgm3mhQ6P0.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 1/3] arm: xea: Move XEA's environment variables from xea.h to xea.env

2024-01-11 Thread Lukasz Majewski

Hi Fabio,

> Hi Lukasz,
> 
> On Thu, Jan 11, 2024 at 8:06 AM Lukasz Majewski  wrote:
> 
> > +serverip=10.8.217.79
> > +nfs_serverip=10.8.218.113
> > +gatewayip=10.8.209.250  
> 
> These IP addresses should not be hardcoded here.
> 
> They were not present in xea.h originally. Please remove them.

Those are the IP's for customer's production setup. In that way I could
just point to mainline SHA1 and just use the sources without any further
adjustments.

I can agree, that on "common devel board" (like e.g. beaglebone) it
would be problematic to have it hardcoded, but as this one is customer
specific HW ...

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: lu...@denx.de

pgpzWpSNKl7oN.pgp
Description: OpenPGP digital signature

[PATCH v2 3/3] arm: xea: Add support for boot image source descriptor in SPL

2024-01-11 Thread Lukasz Majewski

From: Anatolij Gustschin 

We load two boot image source descriptor structures from last
two sectors in the SPI NOR flash and determine the boot source
for loading the kernel/DTB images, then adjust the boot order for
loading image from eMMC boot0 or boot1 partition.

Signed-off-by: Anatolij Gustschin 
Signed-off-by: Lukasz Majewski 

---

Changes in v2:
- Move XEA's env adjustments to xea.env file (from include/configs/xea.h)

 board/liebherr/xea/boot_img_scr.h | 27 ++
 board/liebherr/xea/xea.c  | 85 +++
 2 files changed, 112 insertions(+)
 create mode 100644 board/liebherr/xea/boot_img_scr.h

diff --git a/board/liebherr/xea/boot_img_scr.h 
b/board/liebherr/xea/boot_img_scr.h
new file mode 100644
index 00..baa3072b49
--- /dev/null
+++ b/board/liebherr/xea/boot_img_scr.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Struct for boot image source description for placing in last
+ * two SPI NOR flash sectors on legcom.
+ */
+
+struct boot_img_src {
+   u8 magic;   /* Must be 'B' = 0x42 */
+   u8 flags;   /* flags to specify mmcblk[0|1] boot[0|1] */
+   u8 crc8;/* CRC-8 over above two bytes */
+} __packed;
+
+/*
+ * Bit definition in boot_img_src.flags:
+ *  Bit 0: mmcblk device 0 or 1 (1 - if this bit set)
+ *  Bit 1: mmcblk boot partition 0 or 1.
+ * for eMMC: boot0 if this bit is cleared, boot1 - if set
+ * for SD-card the boot partition value will always be 0
+ * (independent of the value of this bit)
+ *
+ */
+#define BOOT_SRC_MMC1  BIT(0)
+#define BOOT_SRC_PART1 BIT(1)
+
+/* Offset of the first boot image source descriptor in SPI NOR */
+#define SPI_FLASH_BOOT_SRC_OFFS0xFE
+#define SPI_FLASH_SECTOR_SIZE  0x1
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index e4d2eb65cc..c8ac526cb4 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -32,6 +32,11 @@
 #include 
 #include 
 #include 
+#include 
+#include "boot_img_scr.h"
+
+#include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 #include 
@@ -66,6 +71,52 @@ void board_init_f(ulong arg)
preloader_console_init();
 }
 
+static struct boot_img_src img_src[2];
+static int spi_load_boot_info(void)
+{
+   struct spi_flash *flash;
+   int err;
+
+   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+   CONFIG_SF_DEFAULT_CS,
+   CONFIG_SF_DEFAULT_SPEED,
+   CONFIG_SF_DEFAULT_MODE);
+   if (!flash) {
+   printf("%s: SPI probe err\n", __func__);
+   return -ENODEV;
+   }
+
+   /*
+* Load both boot info structs from SPI flash
+*/
+   err = spi_flash_read(flash, SPI_FLASH_BOOT_SRC_OFFS,
+sizeof(img_src[0]),
+(void *)_src[0]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   err = spi_flash_read(flash,
+SPI_FLASH_BOOT_SRC_OFFS + SPI_FLASH_SECTOR_SIZE,
+sizeof(img_src[0]),
+(void *)_src[1]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   debug("%s: BI0 0x%x 0x%x 0x%x\n", __func__,
+ img_src[0].magic, img_src[0].flags, img_src[0].crc8);
+
+   debug("%s: BI1 0x%x 0x%x 0x%x\n", __func__,
+ img_src[1].magic, img_src[1].flags, img_src[1].crc8);
+
+   return 0;
+}
+
 static int boot_tiva0, boot_tiva1;
 
 /* Check if TIVAs request booting via U-Boot proper */
@@ -114,6 +165,40 @@ void spl_board_init(void)
boot_tiva1 = dm_gpio_get_value();
 }
 
+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+   int i, src_idx = -1, ret;
+
+   ret = spi_load_boot_info();
+   if (ret) {
+   printf("%s: Cannot read XEA boot info! [%d]\n", __func__, ret);
+   /* To avoid bricking board - by default boot from boot0 eMMC */
+   return 1;
+   }
+
+   for (i = 0; i < 2; i++) {
+   if (img_src[i].magic == 'B' &&
+   img_src[i].crc8 == crc8(0, _src[i].magic, 2)) {
+   src_idx = i;
+   break;
+   }
+   }
+
+   debug("%s: src idx: %d\n", __func__, src_idx);
+
+   if (src_idx < 0)
+   /*
+* Always use eMMC (mmcblkX) boot0 if no
+* valid image source description found
+*/
+   return 1;
+
+   if (img_src[src_idx].flags & BOOT_SRC_PART1)
+   return 2;
+
+   return 1;
+}
+
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = BOOT_DEVICE_MMC1;
-- 
2.39.2

[PATCH v2 2/3] arm: config: Enable CRC8 support in SPL on imx287 XEA board

2024-01-11 Thread Lukasz Majewski

The boot0/1 feature uses simple CRC8 to check (in SPL) if
SPI-NOR content is not corrupted, hence the need to enable
it.

Signed-off-by: Lukasz Majewski 
---

(no changes since v1)

 configs/imx28_xea_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index c1b0487f7e..64a0561a34 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -123,4 +123,5 @@ CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
+CONFIG_SPL_CRC8=y
 # CONFIG_SPL_OF_LIBFDT is not set
-- 
2.39.2

[PATCH v2 1/3] arm: xea: Move XEA's environment variables from xea.h to xea.env

2024-01-11 Thread Lukasz Majewski

The default set of environment variables from CFG_EXTRA_ENV_SETTINGS
has been moved to a separate file - board/liebherr/xea/xea.env

Adjustments done:
- fitImage support
- SPI-NOR layout re-organization

Signed-off-by: Lukasz Majewski 
---

(no changes since v1)

 board/liebherr/xea/xea.env | 141 +
 include/configs/xea.h  | 140 
 2 files changed, 141 insertions(+), 140 deletions(-)
 create mode 100644 board/liebherr/xea/xea.env

diff --git a/board/liebherr/xea/xea.env b/board/liebherr/xea/xea.env
new file mode 100644
index 00..7dcc122626
--- /dev/null
+++ b/board/liebherr/xea/xea.env
@@ -0,0 +1,141 @@
+bootmode=update
+bootpri=mmc_mmc
+bootsec=sf_swu
+consdev=ttyAMA0
+baudrate=115200
+rootdev=/dev/mmcblk0p2
+netdev=eth0
+swufile=swupdate-image-xea-upd.itb
+sf_kernel_offset=0xA
+sf_swu_size=0xF4
+ethact=FEC
+arch=xea
+serverip=10.8.217.79
+nfs_serverip=10.8.218.113
+gatewayip=10.8.209.250
+lwe_env=
+   if dhcp ${loadaddr} ${hostname}/${lwe_uenv} ; then
+   source ${loadaddr};
+   fi
+lwe_uenv=env_uboot_xea.bin
+do_update_mmc=
+   if mmc rescan ; then
+   mmc dev 0 ${update_mmc_part} ;
+   if dhcp ${hostname}/${update_filename} ; then
+   setexpr fw_sz ${filesize} / 0x200 ;
+   setexpr fw_sz ${fw_sz} + 1 ;
+   mmc write ${loadaddr} ${update_offset} ${fw_sz} ;
+   fi ;
+   fi
+do_update_sf=
+   if sf probe ; then
+   if dhcp ${hostname}/${update_filename} ; then
+   sf erase ${update_offset} +${filesize} ;
+   sf write ${loadaddr} ${update_offset} ${filesize} ;
+   fi ;
+   fi
+factory_reset=
+   if sf probe ; then
+   run update_swu ;
+   setenv bootmode update ;
+   saveenv ;
+   fi
+update_spl_filename=u-boot.sb
+update_spl=
+   setenv update_filename ${update_spl_filename} ;
+   setenv update_offset 0 ;
+   run do_update_sf
+update_uboot_filename=u-boot.img
+update_uboot=
+   setenv update_filename ${update_uboot_filename} ;
+   setenv update_offset 0x1 ;
+   run do_update_sf ;
+   setenv update_mmc_part 1 ;
+   setenv update_offset 0 ;
+   run do_update_mmc ;
+   setenv update_mmc_part 2 ;
+   run do_update_mmc
+update_kernel_filename=uImage
+update_kernel=
+   setenv update_mmc_part 1 ;
+   setenv update_filename ${update_kernel_filename} ;
+   setenv update_offset 0x800 ;
+   run do_update_mmc ;
+   setenv update_filename ${dtbfile} ;
+   setenv update_offset 0x400 ;
+   run do_update_mmc
+update_swu=
+   setenv update_filename ${swufile} ;
+   setenv update_offset ${sf_kernel_offset} ;
+   run do_update_sf
+addcons=
+   setenv bootargs ${bootargs}
+   console=${consdev},${baudrate}
+addip=
+   setenv bootargs ${bootargs}
+   ip=${ipaddr}:${serverip}:${gatewayip}:
+   ${netmask}:${hostname}:${netdev}:off
+addmisc=
+   setenv bootargs ${bootargs} ${miscargs}
+addargs=run addcons addmisc
+mmcload=
+   mmc rescan ;
+   mmc dev 0 1 ;
+   mmc read ${loadaddr} 0x800 0x2000 ;
+   mmc read ${dtbaddr} 0x400 0x80
+netload=
+   dhcp ${loadaddr} ${hostname}/${bootfile} ;
+   tftp ${dtbaddr} ${hostname}/${dtbfile}
+usbload=
+   usb start ;
+   load usb 0:1 ${loadaddr} ${bootfile}
+miscargs=panic=1
+mmcargs=setenv bootargs root=${rootdev} rw rootwait
+nfsargs=
+   setenv bootargs root=/dev/nfs rw
+   nfsroot=${serverip}:${rootpath},v3,tcp
+mmc_mmc=
+   if run mmcload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+mmc_nfs=
+   if run mmcload nfsargs addip addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+sf_mmc=
+   if run sfload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+sf_swu=
+   if sf probe ; then
+   sf read ${loadaddr} ${sf_kernel_offset} ${sf_swu_size} ;
+   setenv bootargs root=/dev/ram0 rw ;
+   run addargs ;
+   bootm ${loadaddr} ;
+   fi
+net_mmc=
+   if run netload mmcargs addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+net_nfs=
+   if run netload nfsargs addip addargs ; then
+   bootm ${loadaddr} - ${dtbaddr} ;
+   fi
+prebootcmd=
+   if test ${envsaved} != y ; then ;
+   setenv envsaved y ;
+   saveenv ;
+   fi ;
+   if test ${bootmode} = normal ; then
+   setenv bootdelay 0 ;
+   setenv bootpri mmc_mmc ;
+   elif test ${bootmode} = devel ; then
+   setenv bootdelay 3 ;
+   setenv bootpri net_mmc ;
+   else
+   if test ${bootmode} != update ; then
+   echo Warning: unknown bootmode ${bootmode} ;
+   fi ;
+   setenv bootdelay 1 ;
+   setenv bootpri sf_swu ;
+   fi
diff --git a/include/configs/xea.h b/include/configs/xea.h
index 04ca5aa12a..00d6274873 100644
--- a/include/configs/xea.h
+++ b/include/configs/xea.h
@@ -25,146 +25,6 @@
 #define

Re: [PATCH v1 1/3] arm: config: xea: Update environment variables for XEA board (imx287)

2024-01-11 Thread Lukasz Majewski

Hi Tom,

> On Wed, Jan 10, 2024 at 03:48:47PM +0100, Lukasz Majewski wrote:
> 
> > As the XEA now supports fitImage, the default envs shall reflect
> > this as well.
> > 
> > Moreover, some SPI-NOR layout re-organization has took place.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > 
> >  include/configs/xea.h | 45
> > --- 1 file changed, 25
> > insertions(+), 20 deletions(-)  
> 
> Please migrate this to a plain text environment.
> 

Ok, so I will prepare new patch especially for it.

(IMHO, patches 2/3 and 3/3 can be applied without this one).


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: lu...@denx.de


pgp0_TgGkwKP3.pgp
Description: OpenPGP digital signature

[PATCH v1 3/3] arm: xea: Add support for boot image source descriptor in SPL

2024-01-10 Thread Lukasz Majewski

From: Anatolij Gustschin 

We load two boot image source descriptor structures from last
two sectors in the SPI NOR flash and determine the boot source
for loading the kernel/DTB images, then adjust the boot order for
loading image from eMMC boot0 or boot1 partition.

Signed-off-by: Anatolij Gustschin 
Signed-off-by: Lukasz Majewski 

---

 board/liebherr/xea/boot_img_scr.h | 27 ++
 board/liebherr/xea/xea.c  | 85 +++
 2 files changed, 112 insertions(+)
 create mode 100644 board/liebherr/xea/boot_img_scr.h

diff --git a/board/liebherr/xea/boot_img_scr.h 
b/board/liebherr/xea/boot_img_scr.h
new file mode 100644
index 00..baa3072b49
--- /dev/null
+++ b/board/liebherr/xea/boot_img_scr.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Struct for boot image source description for placing in last
+ * two SPI NOR flash sectors on legcom.
+ */
+
+struct boot_img_src {
+   u8 magic;   /* Must be 'B' = 0x42 */
+   u8 flags;   /* flags to specify mmcblk[0|1] boot[0|1] */
+   u8 crc8;/* CRC-8 over above two bytes */
+} __packed;
+
+/*
+ * Bit definition in boot_img_src.flags:
+ *  Bit 0: mmcblk device 0 or 1 (1 - if this bit set)
+ *  Bit 1: mmcblk boot partition 0 or 1.
+ * for eMMC: boot0 if this bit is cleared, boot1 - if set
+ * for SD-card the boot partition value will always be 0
+ * (independent of the value of this bit)
+ *
+ */
+#define BOOT_SRC_MMC1  BIT(0)
+#define BOOT_SRC_PART1 BIT(1)
+
+/* Offset of the first boot image source descriptor in SPI NOR */
+#define SPI_FLASH_BOOT_SRC_OFFS0xFE
+#define SPI_FLASH_SECTOR_SIZE  0x1
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index e4d2eb65cc..c8ac526cb4 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -32,6 +32,11 @@
 #include 
 #include 
 #include 
+#include 
+#include "boot_img_scr.h"
+
+#include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 #include 
@@ -66,6 +71,52 @@ void board_init_f(ulong arg)
preloader_console_init();
 }
 
+static struct boot_img_src img_src[2];
+static int spi_load_boot_info(void)
+{
+   struct spi_flash *flash;
+   int err;
+
+   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+   CONFIG_SF_DEFAULT_CS,
+   CONFIG_SF_DEFAULT_SPEED,
+   CONFIG_SF_DEFAULT_MODE);
+   if (!flash) {
+   printf("%s: SPI probe err\n", __func__);
+   return -ENODEV;
+   }
+
+   /*
+* Load both boot info structs from SPI flash
+*/
+   err = spi_flash_read(flash, SPI_FLASH_BOOT_SRC_OFFS,
+sizeof(img_src[0]),
+(void *)_src[0]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   err = spi_flash_read(flash,
+SPI_FLASH_BOOT_SRC_OFFS + SPI_FLASH_SECTOR_SIZE,
+sizeof(img_src[0]),
+(void *)_src[1]);
+   if (err) {
+   debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+   return err;
+   }
+
+   debug("%s: BI0 0x%x 0x%x 0x%x\n", __func__,
+ img_src[0].magic, img_src[0].flags, img_src[0].crc8);
+
+   debug("%s: BI1 0x%x 0x%x 0x%x\n", __func__,
+ img_src[1].magic, img_src[1].flags, img_src[1].crc8);
+
+   return 0;
+}
+
 static int boot_tiva0, boot_tiva1;
 
 /* Check if TIVAs request booting via U-Boot proper */
@@ -114,6 +165,40 @@ void spl_board_init(void)
boot_tiva1 = dm_gpio_get_value();
 }
 
+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+   int i, src_idx = -1, ret;
+
+   ret = spi_load_boot_info();
+   if (ret) {
+   printf("%s: Cannot read XEA boot info! [%d]\n", __func__, ret);
+   /* To avoid bricking board - by default boot from boot0 eMMC */
+   return 1;
+   }
+
+   for (i = 0; i < 2; i++) {
+   if (img_src[i].magic == 'B' &&
+   img_src[i].crc8 == crc8(0, _src[i].magic, 2)) {
+   src_idx = i;
+   break;
+   }
+   }
+
+   debug("%s: src idx: %d\n", __func__, src_idx);
+
+   if (src_idx < 0)
+   /*
+* Always use eMMC (mmcblkX) boot0 if no
+* valid image source description found
+*/
+   return 1;
+
+   if (img_src[src_idx].flags & BOOT_SRC_PART1)
+   return 2;
+
+   return 1;
+}
+
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = BOOT_DEVICE_MMC1;
-- 
2.39.2

[PATCH v1 2/3] arm: config: Enable CRC8 support in SPL on imx287 XEA board

2024-01-10 Thread Lukasz Majewski

The boot0/1 feature uses simple CRC8 to check (in SPL) if
SPI-NOR content is not corrupted, hence the need to enable
it.

Signed-off-by: Lukasz Majewski 
---

 configs/imx28_xea_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index c1b0487f7e..64a0561a34 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -123,4 +123,5 @@ CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
+CONFIG_SPL_CRC8=y
 # CONFIG_SPL_OF_LIBFDT is not set
-- 
2.39.2

[PATCH v1 1/3] arm: config: xea: Update environment variables for XEA board (imx287)

2024-01-10 Thread Lukasz Majewski

As the XEA now supports fitImage, the default envs shall reflect this
as well.

Moreover, some SPI-NOR layout re-organization has took place.

Signed-off-by: Lukasz Majewski 
---

 include/configs/xea.h | 45 ---
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/include/configs/xea.h b/include/configs/xea.h
index 04ca5aa12a..a11bb522cd 100644
--- a/include/configs/xea.h
+++ b/include/configs/xea.h
@@ -33,17 +33,21 @@
"bootsec=sf_swu\0"  \
"consdev=ttyAMA0\0" \
"baudrate=115200\0" \
-   "dtbaddr=0x4400\0"  \
-   "dtbfile=imx28-xea.dtb\0"   \
"rootdev=/dev/mmcblk0p2\0"  \
"netdev=eth0\0" \
-   "rdaddr=0x4300\0"   \
-   "swufile=swupdate.img\0"\
-   "sf_kernel_offset=0x10\0"   \
-   "sf_kernel_size=0x40\0" \
-   "sf_swu_offset=0x50\0"  \
-   "sf_swu_size=0x80\0"\
-   "rootpath=/opt/eldk-5.5/armv5te/rootfs-qte-sdk\0"   \
+   "swufile=swupdate-image-xea-upd.itb\0"  \
+   "sf_kernel_offset=0xA\0"\
+   "sf_swu_size=0xF4\0"\
+   "ethact=FEC\0"  \
+   "arch=xea\0"\
+   "serverip=10.8.217.79\0"\
+   "nfs_serverip=10.8.218.113\0"   \
+   "gatewayip=10.8.209.250\0"  \
+   "lwe_env="  \
+   "if dhcp ${loadaddr} ${hostname}/${lwe_uenv} ; then "   \
+   "source ${loadaddr}; "  \
+   "fi\0"  \
+   "lwe_uenv=env_uboot_xea.bin\0"  \
"do_update_mmc="\
"if mmc rescan ; then " \
"mmc dev 0 ${update_mmc_part} ; "   \
@@ -60,6 +64,12 @@
"sf write ${loadaddr} ${update_offset} ${filesize} ; "  \
"fi ; " \
"fi\0"  \
+   "factory_reset="\
+   "if sf probe ; then "   \
+   "run update_swu ; " \
+   "setenv bootmode update ; " \
+   "saveenv ; "\
+   "fi\0"  \
"update_spl_filename=u-boot.sb\0"   \
"update_spl="   \
"setenv update_filename ${update_spl_filename} ; "  \
@@ -72,6 +82,8 @@
"run do_update_sf ; "   \
"setenv update_mmc_part 1 ; "   \
"setenv update_offset 0 ; " \
+   "run do_update_mmc ; "  \
+   "setenv update_mmc_part 2 ; "   \
"run do_update_mmc\0"   \
"update_kernel_filename=uImage\0"   \
"update_kernel="\
@@ -82,13 +94,9 @@
"setenv update_filename ${dtbfile} ; "  \
"setenv update_offset 0x400 ; " \
"run do_update_mmc\0"   \
-   &qu

Re: [PATCH] net: mv88e6xxx: add missing SMI address init

2023-11-27 Thread Lukasz Majewski

Hi Marek,

> On Wed, Nov 22, 2023 at 04:38:41PM +0100, Lukasz Majewski wrote:
> > Hi Marek,
> >   
> > > Driver does not currently initialize the smi_addr field, but
> > > instead keeps the default value. This leads to issues on systems
> > > with different hardware configuration. We can fix this problem by
> > > reading the SMI address from device tree.
> > > 
> > > Signed-off-by: Marek Mojík 
> > > ---
> > >  drivers/net/mv88e6xxx.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
> > > index c073f81e72..4636dbf156 100644
> > > --- a/drivers/net/mv88e6xxx.c
> > > +++ b/drivers/net/mv88e6xxx.c
> > > @@ -753,6 +753,12 @@ static int mv88e6xxx_probe(struct udevice
> > > *dev) return -ENODEV;
> > >   }
> > >  
> > > + priv->smi_addr = dev_read_addr(dev);
> > > + if (priv->smi_addr == FDT_ADDR_T_NONE) {
> > > + dev_err(dev, "Invalid or missing SMI address\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > >   /* probe internal mdio bus */
> > >   ret = mv88e6xxx_probe_mdio(dev);
> > >   if (ret)  
> > 
> > I've posted some time ago patches for this driver:
> > 
> > https://patchwork.ozlabs.org/project/uboot/cover/2023060115.2216345-1-lu...@denx.de/
> > 
> > Unfortunately, those were not pulled...
> > 
> > Maybe you would find fix for your issue, or prepare new version of
> > it?  
> 
> I looked at your patches, but they don't fix the issue with smi_addr
> initialization. But i may try preparing a new version for them in
> future.
> 

No problem. I just wanted to share some insights. Moreover, I've also
posted some patches to the Linux kernel driver for this chip family.

> Regards,
> Marek




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: lu...@denx.de


pgpPiljzTQOYm.pgp
Description: OpenPGP digital signature

Re: [PATCH] net: mv88e6xxx: add missing SMI address init

2023-11-22 Thread Lukasz Majewski

Hi Marek,

> Driver does not currently initialize the smi_addr field, but instead
> keeps the default value. This leads to issues on systems with
> different hardware configuration. We can fix this problem by reading
> the SMI address from device tree.
> 
> Signed-off-by: Marek Mojík 
> ---
>  drivers/net/mv88e6xxx.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
> index c073f81e72..4636dbf156 100644
> --- a/drivers/net/mv88e6xxx.c
> +++ b/drivers/net/mv88e6xxx.c
> @@ -753,6 +753,12 @@ static int mv88e6xxx_probe(struct udevice *dev)
>   return -ENODEV;
>   }
>  
> + priv->smi_addr = dev_read_addr(dev);
> + if (priv->smi_addr == FDT_ADDR_T_NONE) {
> + dev_err(dev, "Invalid or missing SMI address\n");
> + return -EINVAL;
> + }
> +
>   /* probe internal mdio bus */
>   ret = mv88e6xxx_probe_mdio(dev);
>   if (ret)

I've posted some time ago patches for this driver:

https://patchwork.ozlabs.org/project/uboot/cover/2023060115.2216345-1-lu...@denx.de/

Unfortunately, those were not pulled...

Maybe you would find fix for your issue, or prepare new version of it?


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: lu...@denx.de


pgpF6ViiV1JdW.pgp
Description: OpenPGP digital signature

Re: [PATCH] dfu: mmc: Add support for exposing whole mmc device

2023-10-30 Thread Lukasz Majewski

On Sun, 29 Oct 2023 23:37:22 +0100
Marek Vasut  wrote:

> Add support for exposing the whole mmc device by setting the 'size'
> parameter to 0. This can be useful in case it is not clear what the
> total device size is up front. Update the documentation accordingly.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Lukasz Majewski 
> Cc: Mattijs Korpershoek 
> Cc: Tom Rini 
> ---
>  doc/usage/dfu.rst |  5 +
>  drivers/dfu/dfu_mmc.c | 10 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
> index 68cacbbef66..8845a71df36 100644
> --- a/doc/usage/dfu.rst
> +++ b/doc/usage/dfu.rst
> @@ -121,6 +121,11 @@ mmc
>  
>  with
>  
> +offset
> +is the offset in the device (hexadecimal without "0x")
> +size
> +is the size of the access area (hexadecimal without "0x")
> +or 0 which means whole device
>  partid
>  being the GPT or DOS partition index,
>  num
> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
> index cdb3c18b01d..12c54e90ef7 100644
> --- a/drivers/dfu/dfu_mmc.c
> +++ b/drivers/dfu/dfu_mmc.c
> @@ -386,6 +386,16 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
> char *devstr, char **argv, int a dfu->data.mmc.lba_size
>   = third_arg; dfu->data.mmc.lba_blk_size =
> mmc->read_bl_len; 
> + /*
> +  * In case the size is zero (i.e. mmc raw 0x10 0),
> +  * assume the user intends to use whole device.
> +  */
> + if (third_arg == 0) {
> + struct blk_desc *blk_dev =
> mmc_get_blk_desc(mmc); +
> + dfu->data.mmc.lba_size = blk_dev->lba;
> + }
> +
>   /*
>        * Check for an extra entry at dfu_alt_info env
> variable
>* specifying the mmc HW defined partition number

Reviewed-by: Lukasz Majewski 


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: lu...@denx.de


pgpsLQgythQmB.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/2] MAINTAINERS: Add Mattijs to USB/fastboot maintainers

2023-10-19 Thread Lukasz Majewski

On Thu, 19 Oct 2023 09:40:37 +0200
Mattijs Korpershoek  wrote:

> Hi Lukasz, Marek,
> 
> On mer., oct. 18, 2023 at 12:52, Lukasz Majewski 
> wrote:
> 
> > Hi Mattijs,
> >  
> >> From discussions with Marek at Kernel Recipes, it seems that the
> >> USB subsystem in U-boot need some help.
> >> 
> >> Since I've been asked and I'm willing to help, I've added myself to
> >> the maintainers entry.
> >> 
> >> I have also added myself for fastboot since I'm interested in
> >> keeping that functional as well.
> >> 
> >> Note that I have no previous (open-source) maintainer experience
> >> so I will do my best to learn.
> >>   
> >
> > Thanks for willing to help with maintaining the code. If you need
> > any help - then just ask :-)
> >
> > Acked-by: Lukasz Majewski   
> 
> Thank you for acknowledging. I'm both very happy and a bit nervous to
> start :)
> 
> Do we still use the following custodian tree:
> https://source.denx.de/u-boot/custodians/u-boot-dfu ?
> 

Yes.

> If yes, I imagine I would need write access to it.
> 

I think that Tom shall have credentials to add you.

> 
> >  
> >> Signed-off-by: Mattijs Korpershoek 
> >> ---
> >> Mattijs Korpershoek (2):
> >>   MAINTAINERS: usb gadget: add Mattijs
> >>   MAINTAINERS: fastboot: add Mattijs
> >> 
> >>  MAINTAINERS | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >> ---
> >> base-commit: 65b9b3462bec2966911658836983819ab4e4823e
> >> change-id: 20231005-mattijs-usb-6b83dde256f0
> >> 
> >> Best regards,  
> >
> > 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:
> > lu...@denx.de  




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: lu...@denx.de


pgpjoqBLjQywt.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/2] MAINTAINERS: Add Mattijs to USB/fastboot maintainers

2023-10-18 Thread Lukasz Majewski

Hi Mattijs,

> From discussions with Marek at Kernel Recipes, it seems that the USB
> subsystem in U-boot need some help.
> 
> Since I've been asked and I'm willing to help, I've added myself to
> the maintainers entry.
> 
> I have also added myself for fastboot since I'm interested in keeping
> that functional as well.
> 
> Note that I have no previous (open-source) maintainer experience so I
> will do my best to learn.
> 

Thanks for willing to help with maintaining the code. If you need any
help - then just ask :-)

Acked-by: Lukasz Majewski 

> Signed-off-by: Mattijs Korpershoek 
> ---
> Mattijs Korpershoek (2):
>   MAINTAINERS: usb gadget: add Mattijs
>   MAINTAINERS: fastboot: add Mattijs
> 
>  MAINTAINERS | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> ---
> base-commit: 65b9b3462bec2966911658836983819ab4e4823e
> change-id: 20231005-mattijs-usb-6b83dde256f0
> 
> Best regards,

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: lu...@denx.de


pgpZ8bUIl0ylN.pgp
Description: OpenPGP digital signature

Re: [RFC PATCH] mxs: Don't enable 4P2 reg if mx28 is powered only from DCDC_BATT without 5V

2023-10-09 Thread Lukasz Majewski

Hi Fabio, Alan,

> Hi Alan,
> 
> [Adding Lukasz and Cody]
> 
> On Tue, Aug 30, 2022 at 2:49 PM Alan Kay  wrote:
> >
> > mxs_power_enable_4p2() was added to mxs_batt_boot() in
> > 'commit a0f97610757d ("ARM: mxs: Enable DCDC converter for battery
> > boot")' to enable DCDC converter when board is powered from 5V and
> > has detected sufficient battery voltage.
> > This involves enabling 4P2 regulator and there is a code
> > in mxs_power_enable_4p2() that disables VDDIO, VDDA, VDDD outputs of
> > the DCDC converter and enables BO for each power rail e.g.
> >
> > setbits_le32(_regs->hw_power_vddioctrl,
> > POWER_VDDIOCTRL_DISABLE_FET |
> > POWER_VDDIOCTRL_PWDN_BRNOUT);
> >
> > In case the mx28 is powered by the 5V source and linear regulators
> > are supplying power to the VDDIO, VDDA, VDDD rails there is no
> > issue.
> >
> > However if the mx28 is powered by the DCDC_BATT source only without
> > 5V, disabling the DCDC converter outputs causes brownout power down.
> >
> > The proposed solution is not to call mxs_power_enable_4p2() at all
> > if the mx28 is powered by the DCDC_BATT source only. There is no
> > reason to enable 4P2 regulator in this case and setup of all
> > registers is done in mxs_batt_boot().
> >
> > Also there is no need to enable 5V brownout in
> > mxs_power_init() in this case.
> >
> > Please consider if this is acceptable and I will submit a proper
> > patch.
> >
> > Signed-off-by: Alan Kay   
> 
> Cody also sent a fix for this issue:
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20230703163340.101490-2-c...@londelec.com/

Isn't this already addressed with:
https://source.denx.de/u-boot/u-boot/-/commit/79230640cb4fb780e2be9bb9a47b31976b18cac4

Please also look into the recent patches for imx287 (xea board for
reference):

tig -- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c

At least SHA1: 65b9b3462bec2966911658836983819ab4e4823e


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: lu...@denx.de


pgpQmSvw0ude8.pgp
Description: OpenPGP digital signature

Re: [PATCH] arm: mxs: Clear CPSR V bit to activate low vectors

2023-07-31 Thread Lukasz Majewski

On Sat, 29 Jul 2023 15:30:10 +0200
Marek Vasut  wrote:

> The MXS starts with CPSR V bit set, which makes the CPU jump to high
> vectors in case of an exception. Those high vectors are located at
> 0x, which is where the BootROM exception table is located as
> well. U-Boot should handle exceptions on its own using its own
> exception handling code, which is located at 0x0, i.e. at low
> vectors. Clear the CPSR V bit, so that the CPU would jump to low
> vectors on exception instead, and therefore run the U-Boot exception
> handling code.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: "NXP i.MX U-Boot Team" 
> Cc: Fabio Estevam 
> Cc: Lukasz Majewski 
> Cc: Stefano Babic 
> ---
>  arch/arm/cpu/arm926ejs/mxs/mxs.c  | 3 +++
>  arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c
> b/arch/arm/cpu/arm926ejs/mxs/mxs.c index 4d21e3df76e..d64a8328b04
> 100644 --- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
> @@ -85,6 +85,9 @@ void mx28_fixup_vt(uint32_t start_addr)
>   /* cppcheck-suppress nullPointer */
>   vt[i + 8] = start_addr + (4 * i);
>   }
> +
> + /* Make sure ARM core points to low vectors */
> + set_cr(get_cr() & ~CR_V);
>  }
>  
>  #ifdef   CONFIG_ARCH_MISC_INIT
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c index
> 5598c552ab9..4a7dfc6a2ae 100644 ---
> a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c +++
> b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mxs_init.h"
> @@ -104,6 +105,9 @@ static void mxs_spl_fixup_vectors(void)
>  
>   /* cppcheck-suppress nullPointer */
>   memcpy(0x0, &_start, 0x60);
> +
> + /* Make sure ARM core points to low vectors */
> + set_cr(get_cr() & ~CR_V);
>  }
>  
>  static void mxs_spl_console_init(void)

Reviewed-by: Lukasz Majewski 


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: lu...@denx.de


pgp479h5QokMz.pgp
Description: OpenPGP digital signature

Re: [PATCH] arm: mxs: Fix ICOLL macro name typo

2023-07-31 Thread Lukasz Majewski

On Sat, 29 Jul 2023 15:29:41 +0200
Marek Vasut  wrote:

> The interrupt collector macro name for i.MX23 is MXS_ICOLL_BASE,
> this is correct and matches the documentation of both i.MX23 and
> i.MX28. Align the i.MX28 macro accordingly. No functional change.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: "NXP i.MX U-Boot Team" 
> Cc: Fabio Estevam 
> Cc: Lukasz Majewski 
> Cc: Stefano Babic 
> ---
>  arch/arm/include/asm/arch-mxs/regs-base.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-mxs/regs-base.h
> b/arch/arm/include/asm/arch-mxs/regs-base.h index
> 44d40cade87..33d2ab5230f 100644 ---
> a/arch/arm/include/asm/arch-mxs/regs-base.h +++
> b/arch/arm/include/asm/arch-mxs/regs-base.h @@ -60,7 +60,7 @@
>   * Register base addresses for i.MX28
>   */
>  #elif defined(CONFIG_MX28)
> -#define  MXS_ICOL_BASE   0x8000
> +#define  MXS_ICOLL_BASE  0x8000
>  #define  MXS_HSADC_BASE  0x80002000
>  #define  MXS_APBH_BASE   0x80004000
>  #define  MXS_PERFMON_BASE0x80006000

Reviewed-by: Lukasz Majewski 


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: lu...@denx.de


pgp8otpQUzTHg.pgp
Description: OpenPGP digital signature

[PATCH 2/2] config: xea: Disable support for FAT file system

2023-07-12 Thread Lukasz Majewski

On the XEA (imx287) system the FAT file system is not used neither in
SPL nor u-boot proper.

Hence, to save ~6KiB of u-boot.img size - it has been disabled.

Signed-off-by: Lukasz Majewski 
---
 configs/imx28_xea_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index a174bdb939..96d15e89af 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -123,5 +123,4 @@ CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
-CONFIG_FS_FAT=y
 # CONFIG_SPL_OF_LIBFDT is not set
-- 
2.30.2

[PATCH 1/2] config: xea: Disable support for boot methods EXTLINUX and VBE

2023-07-12 Thread Lukasz Majewski

The XEA system (imx287 based) is not using support for EXTLINUX and VBE.
As those configuration options have been enabled by default with modern
Kconfig it is safe to explicitly disable them.

After that change the u-boot.img size has been reduced by ~16 KiB.

Signed-off-by: Lukasz Majewski 
---
 configs/imx28_xea_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index c6c6a03245..a174bdb939 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -29,6 +29,8 @@ CONFIG_SYS_LOAD_ADDR=0x4200
 CONFIG_SPL_PAYLOAD="u-boot.img"
 CONFIG_FIT=y
 CONFIG_TIMESTAMP=y
+# CONFIG_BOOTMETH_EXTLINUX is not set
+# CONFIG_BOOTMETH_VBE is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyAMA0,115200n8"
-- 
2.30.2

Re: [PATCH 2/2] mxs: Don't enable 4P2 reg if MXS is powered only from DCDC_BATT

2023-07-04 Thread Lukasz Majewski

Hi Marek, Cody,

> On 7/3/23 18:33, Cody Green wrote:
> > 'mxs_power_enable_4p2()' function call was added to
> > 'mxs_batt_boot()' in 'commit a0f97610757d' to enable DCDC converter
> > when board is powered from 5V and has detected sufficient battery
> > voltage. This involves enabling 4P2 regulator and there is a code
> > in 'mxs_power_enable_4p2()' that disables VDDIO, VDDA, VDDD outputs
> > of the DCDC converter and enables BO for each power rail:
> > 
> >setbits_le32(_regs->hw_power_vddioctrl,
> >  POWER_VDDIOCTRL_DISABLE_FET | POWER_VDDIOCTRL_PWDN_BRNOUT);
> > 
> > There is no issue if the MXS is powered from the 5V source and
> > linear regulators are supplying power to the VDDIO, VDDA, VDDD
> > rails. However, if the MXS is powered only from the DCDC_BATT
> > without 5V, disabling the DCDC converter outputs causes VDDIO,
> > VDDA, VDDD rails to lose power.

I think that I've also hit the same issue with the XEA board
(upstreamed).

I've prepared a set of patches:
https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-5-lu...@denx.de/

to fix this problem.

Those patches are now for some time on the mailing list for review - and
I do hope that Stefano will pull them with next PR for u-boot-imx
repository.

> > 
> > The proposed solution is not to call the 'mxs_power_enable_4p2()'
> > function if the MXS is powered only by the DCDC_BATT, because there
> > is no reason to enable 4P2 regulator in this case.

I think this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-3-lu...@denx.de/

address exactly this issue.

> > Also 5V brownout
> > should not be enabled in 'mxs_power_init()' and linear regulator
> > checks should be disabled in 'mxs_power_set_vddx()'.
> > 

I've also added some code to limit the VDD5V current when we intend to
use DCDC_BATT input as the _primary_ source of power (AN4199 advises
this one for industrial applications as the most reliable).


> > Signed-off-by: Cody Green 
> > Cc: Stefano Babic 
> > Cc: Marek Vasut 
> > Cc: Fabio Estevam 
> > ---
> >   arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 7 +++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index
> > 33b76533e4..72172705f2 100644 ---
> > a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++
> > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -752,7 +752,9 @@
> > static void mxs_batt_boot(void) POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
> > 0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
> >   
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > mxs_power_enable_4p2();
> > +#endif
> >   }
> >   
> >   /**
> > @@ -1137,8 +1139,11 @@ static void mxs_power_set_vddx(const struct
> > mxs_vddx_cfg *cfg, cur_target += cfg->lowest_mV;
> >   
> > adjust_up = new_target > cur_target;
> > +
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > if (cfg->powered_by_linreg)
> > powered_by_linreg = cfg->powered_by_linreg();
> > +#endif
> >   
> > if (adjust_up && cfg->bo_irq) {
> > if (powered_by_linreg) {
> > @@ -1269,7 +1274,9 @@ void mxs_power_init(void)
> > POWER_CTRL_VBUS_VALID_IRQ |
> > POWER_CTRL_BATT_BO_IRQ | POWER_CTRL_DCDC4P2_BO_IRQ,
> > _regs->hw_power_ctrl_clr); 
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > writel(POWER_5VCTRL_PWDN_5VBRNOUT,
> > _regs->hw_power_5vctrl_set); +#endif
> >   
> > early_delay(1000);
> >   }  
> 
> +CC Lukasz




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: lu...@denx.de


pgpYvMAwzuEpt.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them

2023-06-02 Thread Lukasz Majewski

Hi Vladimir,

> Hi Lukasz,
> 
> On Thu, Jun 01, 2023 at 01:44:30PM +0200, Marek Vasut wrote:
> > I think after two years, it would be good to drop the RB tags and
> > do another round of reviews.  
> 
> To expand on Marek's point.
> 
> In those past 2 years, Tim Harvey has put in a considerable amount of
> effort to add another driver for mv88e6xxx that uses DM_DSA. I believe
> the current "PHY" driver for the same hardware should be considered
> obsolete until all platforms are converted to DM_DSA, then it can be
> deleted. So, no new features for it.

Ok. Thanks for the clarification.

> 
> Then, there's also the question of the sanity of the proposed change
> itself.
> 
> I believe that we need to be humble enough to recognize that the
> U-Boot network stack is not competent enough to handle the switching
> capabilities of a switch, not even enough for it to be safe. It
> doesn't handle STP (Spanning Tree Protocol), for one thing. So it
> will never be capable of detecting switching loops, such as to block
> one of its ports in order to not kill the network.
> 
> In principle, I would say: as long as there is no plan to handle STP,
> there should be no plan to allow autonomous packet forwarding from
> U-Boot. The U-Boot network stack is there so that you can TFTP a
> kernel and boot it, which is also the only use case behind DM_DSA.
> 
> But you may say: I'm never going to allow packet forwarding from
> U-Boot in a network with loops!
> 
> Okay, but your patch suggests otherwise. Which ports allow forwarding
> is a compile-time option, which... is by definition contrary to any
> runtime network topology determinations.
> 
> Maybe enabling forwarding between switch ports through a CLI command
> that communicates with DM_DSA would be tolerable - assuming that users
> are smart enough to not use it in a network with STP.

No - adding extra command line option is not planned.

> But again, I'm
> not really sure what's the use case.

This is a simple use case - the board on which I do work has two LAN
ports, so the device is "attached" to the single LAN cable.

When booting the device (even in u-boot) - packet's shall be forwarded
between LAN ports to keep the ETH connection.

However, I don't want to add STP for the u-boot network stack.

I've also looked to Tim's patch set [1] (also in mainline), and I do
believe that some extra features for this driver can be added; like
ADDR4 (so the address is 'shifted' to 0x10) and !NO_CPU bootstraps
(so ports need to be reset at power up).

Those features are common for all mv88e6xxx devices.


Links:

[1] -
https://patchwork.ozlabs.org/project/uboot/cover/20221130174251.82087-1-thar...@gateworks.com/


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: lu...@denx.de


pgp0yjSCKGb8L.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 6/6] net: mv88e61xx: Reset switch PHYs when bootstrapped to !NO_CPU

2023-06-01 Thread Lukasz Majewski

Hi Marek,

> On 6/1/23 12:00, Lukasz Majewski wrote:
> > Some devices, when configured in bootstrap to 'no cpu' mode require
> > PHY manual reset to get them operational and responding to reading
> > their ID registers.
> > 
> > Without this step - the PHYLIB probing will fail.
> > 
> > In more details - the bootstrap configuration from switch must be
> > read. The value of CONFIG Data1 (0x71) of Scratch and Misc register
> > is read to check if 'no_cpu' and 'addr4' bits were set.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Reviewed-by: Ramon Fried 
> > 
> > ---
> > 
> >   drivers/net/phy/mv88e61xx.c | 63
> > +++-- 1 file changed, 61
> > insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/phy/mv88e61xx.c
> > b/drivers/net/phy/mv88e61xx.c index 69a87bead469..cf8f5e833e82
> > 100644 --- a/drivers/net/phy/mv88e61xx.c
> > +++ b/drivers/net/phy/mv88e61xx.c
> > @@ -194,6 +194,17 @@ struct mv88e61xx_phy_priv {
> > u8 phy_ctrl1_en_det_width; /* Width of 'EDet' bit field */
> > u8 phy_ctrl1_en_det_ctrl;  /* 'EDet' control value */
> > u8 direct_access;  /* Access switch device
> > directly */
> > +   /*
> > +* Bootstrap configuration:
> > +*
> > +* If addr4 = 1 device is accessible from 0x10 address on
> > MDIO bus.
> > +*/
> > +   u8 addr4;
> > +   /*
> > +* If no_cpu = 1 switch is automatically setup, otherwise
> > PHY reset is
> > +* required from CPU for normal operation.
> > +*/
> > +   u8 no_cpu;
> >   };
> >   
> >   static inline int smi_cmd(int cmd, int addr, int reg)
> > @@ -1218,6 +1229,33 @@ U_BOOT_PHY_DRIVER(mv88e6071) = {
> > .shutdown = _shutdown,
> >   };
> >   
> > +static int mv88e61xx_read_bootstrap(struct phy_device *phydev)
> > +{
> > +   struct mv88e61xx_phy_priv *priv = phydev->priv;
> > +   struct mii_dev *mdio_bus = priv->mdio_bus;
> > +   int val;
> > +
> > +   /* mv88e6020 - ID = 0x0200 (REG 3 on non PHY port) */
> > +   if (priv->id == PORT_SWITCH_ID_6020) {
> > +   /* Prepare to read scratch and misc register */
> > +   mdio_bus->write(mdio_bus, priv->global2, 0,
> > +   0x1a /*MV_SCRATCH_MISC*/,
> > +   (0x71 /*MV_CONFIG_DATA1*/ << 8));  
> 
> Introduce macros for these magic values.

Frankly speaking, this is more readable than macros as it is in sync
with vendor's documentation.

In other words - it is easier to find this information in documentation
when presented like above.

> 
> > +   val = mdio_bus->read(mdio_bus, priv->global2, 0,
> > +0x1a /*MV_SCRATCH_MISC*/);
> > +
> > +   if (val & (1 << 0))
> > +   priv->no_cpu = 1;
> > +   if (val & (1 << 4))  
> 
> Macros, and also BIT()
> 
> [..]

Ok.


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: lu...@denx.de


pgpfoWPsEjxVo.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them

2023-06-01 Thread Lukasz Majewski

Hi Marek,

> On 6/1/23 12:00, Lukasz Majewski wrote:
> > After this change PHY ports are able to pass packets between them
> > (and also to CPU port).
> > 
> > The Kconfig variable - CONFIG_MV88E61XX_PHY_PORTS - is used to get
> > the PHY ports of the switch and generate proper mask.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Reviewed-by: Ramon Fried   
> 
> Was there a V0 before ? Or where did these RB tags come from ?
> 

There was v1 in 2021 - The patman is not allowing "v1 RESEND" tag
adding.

> > ---
> > 
> >   drivers/net/phy/mv88e61xx.c | 9 +++--
> >   1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/phy/mv88e61xx.c
> > b/drivers/net/phy/mv88e61xx.c index 31f9b57456d6..4aee83551beb
> > 100644 --- a/drivers/net/phy/mv88e61xx.c
> > +++ b/drivers/net/phy/mv88e61xx.c
> > @@ -865,14 +865,19 @@ static int mv88e61xx_phy_setup(struct
> > phy_device *phydev, u8 phy) 
> >   static int mv88e61xx_phy_config_port(struct phy_device *phydev,
> > u8 phy) {
> > +   struct mv88e61xx_phy_priv *priv = phydev->priv;
> > +   u16 port_mask;
> > int val;
> >   
> > val = mv88e61xx_port_enable(phydev, phy);
> > if (val < 0)
> > return val;
> >   
> > -   val = mv88e61xx_port_set_vlan(phydev, phy,
> > -   1 << CONFIG_MV88E61XX_CPU_PORT);
> > +   port_mask = PORT_MASK(priv->port_count) &
> > CONFIG_MV88E61XX_PHY_PORTS;
> > +   port_mask &= ~(1 << phy);
> > +   port_mask |= (1 << CONFIG_MV88E61XX_CPU_PORT);  
> 
> BIT() ?

I've kept the "style" from the rest of the file.


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: lu...@denx.de


pgplnrgcgpC2R.pgp
Description: OpenPGP digital signature

[PATCH v1 4/6] net: mv88e61xx: Directly access the switch chip

2023-06-01 Thread Lukasz Majewski

The mv88e6020 is accessed in a direct way (i.e. with direct read and
write to mdio bus). The only necessary indirection is required when
accessing its PHY registers.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 
---

 drivers/net/phy/mv88e61xx.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index c19c3dfa8b6d..c9917953f3d7 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -261,8 +261,11 @@ static int mv88e61xx_reg_read(struct phy_device *phydev, 
int dev, int reg)
int smi_addr = priv->smi_addr;
int res;
 
-   /* In single-chip mode, the device can be addressed directly */
-   if (smi_addr == 0)
+   /*
+* In single-chip or dual-chip (like mv88e6020) mode, the device can
+* be addressed directly.
+*/
+   if (smi_addr == 0 || priv->direct_access)
return mdio_bus->read(mdio_bus, dev, MDIO_DEVAD_NONE, reg);
 
/* Wait for the bus to become free */
@@ -298,11 +301,13 @@ static int mv88e61xx_reg_write(struct phy_device *phydev, 
int dev, int reg,
int smi_addr = priv->smi_addr;
int res;
 
-   /* In single-chip mode, the device can be addressed directly */
-   if (smi_addr == 0) {
+   /*
+* In single-chip or dual-chip (like mv88e6020) mode, the device can
+* be addressed directly.
+*/
+   if (smi_addr == 0 || priv->direct_access)
return mdio_bus->write(mdio_bus, dev, MDIO_DEVAD_NONE, reg,
val);
-   }
 
/* Wait for the bus to become free */
res = mv88e61xx_smi_wait(mdio_bus, smi_addr);
-- 
2.30.2

[PATCH v1 5/6] net: mv88e61xx: Set proper offset when R0_LED/ADDR4 is set on bootstrap

2023-06-01 Thread Lukasz Majewski

The mv88e61xx driver need to be adjusted to handle situation when
switch MDIO addresses are switched by offset (0x10 in this case).

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 
---

 drivers/net/phy/mv88e61xx.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index c9917953f3d7..69a87bead469 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -45,7 +45,6 @@
 #define PORT_MASK(port_count)  ((1 << (port_count)) - 1)
 
 /* Device addresses */
-#define DEVADDR_PHY(p) (p)
 #define DEVADDR_SERDES 0x0F
 
 /* SMI indirection registers for multichip addressing mode */
@@ -406,7 +405,7 @@ static int mv88e61xx_phy_write_indirect(struct mii_dev 
*smi_wrapper, int dev,
 /* Wrapper function to make calls to phy_read_indirect simpler */
 static int mv88e61xx_phy_read(struct phy_device *phydev, int phy, int reg)
 {
-   return mv88e61xx_phy_read_indirect(phydev->bus, DEVADDR_PHY(phy),
+   return mv88e61xx_phy_read_indirect(phydev->bus, phydev->addr,
   MDIO_DEVAD_NONE, reg);
 }
 
@@ -414,7 +413,7 @@ static int mv88e61xx_phy_read(struct phy_device *phydev, 
int phy, int reg)
 static int mv88e61xx_phy_write(struct phy_device *phydev, int phy,
int reg, u16 val)
 {
-   return mv88e61xx_phy_write_indirect(phydev->bus, DEVADDR_PHY(phy),
+   return mv88e61xx_phy_write_indirect(phydev->bus, phydev->addr,
MDIO_DEVAD_NONE, reg, val);
 }
 
@@ -918,12 +917,21 @@ static int mv88e61xx_priv_reg_offs_pre_init(struct 
phy_device *phydev)
/*
 * Now try via port registers with device address 0x08
 * (88E6020 and compatible switches).
+*
+* When R0_LED/ADDR4 is set during bootstrap, one needs
+* to add 0x10 offset to switch addresses.
+*
+* The phydev->addr is set according to device tree address
+* of MDIO accessible device:
+*
+* When on board RO_LED/ADDR4 = 1 -> 0x10
+*  0 -> 0x0
 */
-   priv->port_reg_base = 0x08;
+   priv->port_reg_base = 0x08 + phydev->addr;
priv->id = mv88e61xx_get_switch_id(phydev);
if (priv->id != 0xfff0) {
-   priv->global1 = 0x0F;
-   priv->global2 = 0x07;
+   priv->global1 = 0x0F + phydev->addr;
+   priv->global2 = 0x07 + phydev->addr;
return 0;
}
 
@@ -1082,7 +1090,10 @@ static int mv88e61xx_phy_config(struct phy_device 
*phydev)
 
for (i = 0; i < priv->port_count; i++) {
if ((1 << i) & CONFIG_MV88E61XX_PHY_PORTS) {
-   phydev->addr = i;
+   if (phydev->addr)
+   phydev->addr += i;
+   else
+   phydev->addr = i;
 
res = mv88e61xx_phy_enable(phydev, i);
if (res < 0) {
-- 
2.30.2

[PATCH v1 6/6] net: mv88e61xx: Reset switch PHYs when bootstrapped to !NO_CPU

2023-06-01 Thread Lukasz Majewski

Some devices, when configured in bootstrap to 'no cpu' mode require PHY
manual reset to get them operational and responding to reading their ID
registers.

Without this step - the PHYLIB probing will fail.

In more details - the bootstrap configuration from switch must be read.
The value of CONFIG Data1 (0x71) of Scratch and Misc register is read
to check if 'no_cpu' and 'addr4' bits were set.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 

---

 drivers/net/phy/mv88e61xx.c | 63 +++--
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 69a87bead469..cf8f5e833e82 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -194,6 +194,17 @@ struct mv88e61xx_phy_priv {
u8 phy_ctrl1_en_det_width; /* Width of 'EDet' bit field */
u8 phy_ctrl1_en_det_ctrl;  /* 'EDet' control value */
u8 direct_access;  /* Access switch device directly */
+   /*
+* Bootstrap configuration:
+*
+* If addr4 = 1 device is accessible from 0x10 address on MDIO bus.
+*/
+   u8 addr4;
+   /*
+* If no_cpu = 1 switch is automatically setup, otherwise PHY reset is
+* required from CPU for normal operation.
+*/
+   u8 no_cpu;
 };
 
 static inline int smi_cmd(int cmd, int addr, int reg)
@@ -1218,6 +1229,33 @@ U_BOOT_PHY_DRIVER(mv88e6071) = {
.shutdown = _shutdown,
 };
 
+static int mv88e61xx_read_bootstrap(struct phy_device *phydev)
+{
+   struct mv88e61xx_phy_priv *priv = phydev->priv;
+   struct mii_dev *mdio_bus = priv->mdio_bus;
+   int val;
+
+   /* mv88e6020 - ID = 0x0200 (REG 3 on non PHY port) */
+   if (priv->id == PORT_SWITCH_ID_6020) {
+   /* Prepare to read scratch and misc register */
+   mdio_bus->write(mdio_bus, priv->global2, 0,
+   0x1a /*MV_SCRATCH_MISC*/,
+   (0x71 /*MV_CONFIG_DATA1*/ << 8));
+
+   val = mdio_bus->read(mdio_bus, priv->global2, 0,
+0x1a /*MV_SCRATCH_MISC*/);
+
+   if (val & (1 << 0))
+   priv->no_cpu = 1;
+   if (val & (1 << 4))
+   priv->addr4 = 1;
+   debug("mv88e6020: no_cpu=%d addr4=%d\n", priv->no_cpu,
+ priv->addr4);
+   }
+
+   return 0;
+}
+
 /*
  * Overload weak get_phy_id definition since we need non-standard functions
  * to read PHY registers
@@ -1257,13 +1295,34 @@ int get_phy_id(struct mii_dev *bus, int smi_addr, int 
devad, u32 *phy_id)
if (val < 0)
return val;
 
-   val = mv88e61xx_phy_read_indirect(_mii, 0, devad, MII_PHYSID1);
+   mv88e61xx_read_bootstrap(_phy);
+
+   /*
+* When switch is configured to work with CPU (i.e. NO_CPU == 0), PHYs
+* require reset (to at least single one) to have its registers
+* accessible.
+*/
+   if (!temp_priv.no_cpu && temp_priv.id == PORT_SWITCH_ID_6020) {
+   /* Reset PHY */
+   val = mv88e61xx_phy_read_indirect(_mii, temp_phy.addr,
+ devad, MII_BMCR);
+   if (val & BMCR_PDOWN)
+   val &= ~BMCR_PDOWN;
+
+   mv88e61xx_phy_write_indirect(_mii, temp_phy.addr, devad,
+MII_BMCR, val);
+   }
+
+   /* Read PHY_ID */
+   val = mv88e61xx_phy_read_indirect(_mii, temp_phy.addr, devad,
+ MII_PHYSID1);
if (val < 0)
return -EIO;
 
*phy_id = val << 16;
 
-   val = mv88e61xx_phy_read_indirect(_mii, 0, devad, MII_PHYSID2);
+   val = mv88e61xx_phy_read_indirect(_mii, temp_phy.addr, devad,
+ MII_PHYSID2);
if (val < 0)
return -EIO;
 
-- 
2.30.2

[PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them

2023-06-01 Thread Lukasz Majewski

After this change PHY ports are able to pass packets between them (and
also to CPU port).

The Kconfig variable - CONFIG_MV88E61XX_PHY_PORTS - is used to get the
PHY ports of the switch and generate proper mask.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 
---

 drivers/net/phy/mv88e61xx.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 31f9b57456d6..4aee83551beb 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -865,14 +865,19 @@ static int mv88e61xx_phy_setup(struct phy_device *phydev, 
u8 phy)
 
 static int mv88e61xx_phy_config_port(struct phy_device *phydev, u8 phy)
 {
+   struct mv88e61xx_phy_priv *priv = phydev->priv;
+   u16 port_mask;
int val;
 
val = mv88e61xx_port_enable(phydev, phy);
if (val < 0)
return val;
 
-   val = mv88e61xx_port_set_vlan(phydev, phy,
-   1 << CONFIG_MV88E61XX_CPU_PORT);
+   port_mask = PORT_MASK(priv->port_count) & CONFIG_MV88E61XX_PHY_PORTS;
+   port_mask &= ~(1 << phy);
+   port_mask |= (1 << CONFIG_MV88E61XX_CPU_PORT);
+
+   val = mv88e61xx_port_set_vlan(phydev, phy, port_mask);
if (val < 0)
return val;
 
-- 
2.30.2

[PATCH v1 3/6] net: mv88e61xx: Clear temporary structs before using them in get_phy_id()

2023-06-01 Thread Lukasz Majewski

Those automatically created structures can have random value.
However, mv88e61xx driver assumes that those are zeroed.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 
---

 drivers/net/phy/mv88e61xx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 4aee83551beb..c19c3dfa8b6d 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -1213,6 +1213,10 @@ int get_phy_id(struct mii_dev *bus, int smi_addr, int 
devad, u32 *phy_id)
struct mii_dev temp_mii;
int val;
 
+   memset(_phy, 0, sizeof(temp_phy));
+   memset(_priv, 0, sizeof(temp_priv));
+   memset(_mii, 0, sizeof(temp_mii));
+
/*
 * Buid temporary data structures that the chip reading code needs to
 * read the ID
-- 
2.30.2

[PATCH v1 1/6] net: mv88e61xx: Add support for checking addressing mode

2023-06-01 Thread Lukasz Majewski

Some Marvell switch devices are dual chip ones, like mv88e6020, which
use direct MDIO addressing to access its ports' registers. Such approach
allows connecting two such devices in a single MDIO bus with simple
addressing scheme.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Ramon Fried 
---

 drivers/net/phy/mv88e61xx.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 85778106eddc..31f9b57456d6 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -194,6 +194,7 @@ struct mv88e61xx_phy_priv {
u8 phy_ctrl1_en_det_shift; /* 'EDet' bit field offset */
u8 phy_ctrl1_en_det_width; /* Width of 'EDet' bit field */
u8 phy_ctrl1_en_det_ctrl;  /* 'EDet' control value */
+   u8 direct_access;  /* Access switch device directly */
 };
 
 static inline int smi_cmd(int cmd, int addr, int reg)
@@ -920,6 +921,40 @@ static int mv88e61xx_priv_reg_offs_pre_init(struct 
phy_device *phydev)
return -ENODEV;
 }
 
+static int mv88e61xx_check_addressing(struct phy_device *phydev)
+{
+   if (!CONFIG_IS_ENABLED(OF_CONTROL))
+   return 0;
+
+   /*
+* Some devices - like mv88e6020 are dual chip - i.e. two
+* such devices can be directly accessed via SMI bus.
+* The addressing depends on R0_LED/ADDR4 pin value duing
+* bootstrap.
+*
+* This means that there is no need for indirect access.
+*/
+   struct mv88e61xx_phy_priv *priv = phydev->priv;
+
+   /*
+* As this function is called very early and hence the phydev
+* is not yet initialized we use aliast and DTS to asses if
+* device shall be directly accessed or not.
+*/
+   ofnode sw0;
+   int ret;
+
+   sw0 = ofnode_get_aliases_node("switch0");
+   if (!ofnode_valid(sw0))
+   return -ENODEV;
+
+   ret = ofnode_device_is_compatible(sw0, "marvell,mv88e6020");
+   if (ret)
+   priv->direct_access = 1;
+
+   return 0;
+}
+
 static int mv88e61xx_probe(struct phy_device *phydev)
 {
struct mii_dev *smi_wrapper;
@@ -974,6 +1009,8 @@ static int mv88e61xx_probe(struct phy_device *phydev)
 
phydev->priv = priv;
 
+   mv88e61xx_check_addressing(phydev);
+
res = mv88e61xx_priv_reg_offs_pre_init(phydev);
if (res < 0)
return res;
@@ -1180,6 +1217,11 @@ int get_phy_id(struct mii_dev *bus, int smi_addr, int 
devad, u32 *phy_id)
temp_phy.priv = _priv;
temp_mii.priv = _phy;
 
+   mv88e61xx_check_addressing(_phy);
+   /* For direct access the phy address equals to smi_addr */
+   if (temp_priv.direct_access)
+   temp_phy.addr = smi_addr;
+
/*
 * get_phy_id() can be called by framework before mv88e61xx driver
 * probing, in this case the global register offsets are not
-- 
2.30.2

[PATCH v1 0/6] Provide support for mv88e6020 Marvell switch

2023-06-01 Thread Lukasz Majewski

This patch set provides support for mv88e6020 switch. It is a dual chip
device, with direct access to port register on SMI bus. However, PHYs
are accessed indirectly.

I've rebased this series (unmodified) on v2023.07-rcX
(SHA1: cb4437e530ec1ff3deae85754010344afab8bcc5)  and added reviewed
by tags.


Lukasz Majewski (6):
  net: mv88e61xx: Add support for checking addressing mode
  net: mv88e61xx: Configure PHY ports to also pass packets between them
  net: mv88e61xx: Clear temporary structs before using them in
get_phy_id()
  net: mv88e61xx: Directly access the switch chip
  net: mv88e61xx: Set proper offset when R0_LED/ADDR4 is set on
bootstrap
  net: mv88e61xx: Reset switch PHYs when bootstrapped to !NO_CPU

 drivers/net/phy/mv88e61xx.c | 158 
 1 file changed, 142 insertions(+), 16 deletions(-)

-- 
2.30.2

[PATCH v1 16/16] config: xea: Enable DM_SERIAL for the XEA - single binary (SB) u-boot

2023-05-19 Thread Lukasz Majewski

The single binary version of u-boot for XEA board is used to debrick and
factory programming.

The produced u-boot.sb is a single file, which allows having fully
operational u-boot prompt loaded with imx287 ROM.

Signed-off-by: Lukasz Majewski 

---

 configs/imx28_xea_sb_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index bb7bf5d9da..a43183444d 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -94,7 +94,9 @@ CONFIG_PINCTRL_MXS=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_CONS_INDEX=0
+CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
-- 
2.30.2

[PATCH v1 12/16] arm: mxs: Prevent serial console init when in very early SPL boot code

2023-05-19 Thread Lukasz Majewski

When DM_SERIAL is enabled on mxs (i.e. imx28) platform, the console
early initialization must be postponed until the driver model is
correctly setup.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 763d79e803..5598c552ab 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -128,8 +128,10 @@ void mxs_common_spl_init(const uint32_t arg, const 
uint32_t *resptr,
 
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
 
-   mxs_spl_console_init();
-   debug("SPL: Serial Console Initialised\n");
+   if (!CONFIG_IS_ENABLED(DM_SERIAL)) {
+   mxs_spl_console_init();
+   debug("SPL: Serial Console Initialised\n");
+   }
 
mxs_power_init();
 
-- 
2.30.2

[PATCH v1 15/16] config: xea: Enable DM_SERIAL for the XEA (imx287 based) board

2023-05-19 Thread Lukasz Majewski

The XEA board now supports the DM_SERIAL feature in u-boot.

The SPL is using the SPL_OF_PLATDATA - i.e. NOT SPL_DM_SERIAL to
reduce the overall size of the SPL binary.

Signed-off-by: Lukasz Majewski 
---

 configs/imx28_xea_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 4a217b1f91..b4a051a859 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -113,7 +113,8 @@ CONFIG_PINCTRL_MXS=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
-CONFIG_CONS_INDEX=0
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MXS_SPI=y
-- 
2.30.2

[PATCH v1 14/16] arm: Kconfig: Switch XEA (imx287 based) board to use CONFIG_PL01X_SERIAL

2023-05-19 Thread Lukasz Majewski

The CONFIG_PL011 used by all other ARCH_MX28 based boards is not
supporting DM_SERIAL. Instead, other define - namely CONFIG_PL01X_SERIAL
shall be used by boards supporting DM_SERIAL.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/Kconfig  | 2 +-
 arch/arm/mach-imx/mxs/Kconfig | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 99264a6478..4604d41410 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -919,7 +919,7 @@ config ARCH_MX28
bool "NXP i.MX28 family"
select CPU_ARM926EJS
select GPIO_EXTRA_HEADER
-   select PL011_SERIAL
+   select PL011_SERIAL if !TARGET_XEA
select MACH_IMX
select SUPPORT_SPL
 
diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index b2026a3758..ded16aac46 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -45,6 +45,7 @@ config TARGET_MX28EVK
 
 config TARGET_XEA
bool "Support XEA"
+   select PL01X_SERIAL
 
 endchoice
 
-- 
2.30.2

[PATCH v1 13/16] arm: xea: Call spl_early_init() before DM serial console is enabled in SPL

2023-05-19 Thread Lukasz Majewski

The in-spl enabled DM serial console requires the board setup to be
able to parse SPL_OF_PLATDATA based serial driver (pl01x) for the
imx28 based XEA board.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index ed2b39f70e..e4d2eb65cc 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -62,6 +62,7 @@ static void init_clocks(void)
 void board_init_f(ulong arg)
 {
init_clocks();
+   spl_early_init();
preloader_console_init();
 }
 
-- 
2.30.2

[PATCH v1 11/16] serial: pl01x: Modify pending callback to test if transmit FIFO is empty

2023-05-19 Thread Lukasz Majewski

Before this change the FR_TXFF (Transmit FIFO full) bit (5 in
HW_UARTDBG_FR) has been used to assess if there is still data pending
to be sent via UART.

This approach is problematic, as it may happen that serial is in the
middle of transmission (so the TX FIFO is NOT full anymore) and this
test returns true infinitely. As a result, for example in _serial_flush()
DM serial function we are locked in endless while().

The fix here is to test explicitly if the TX FIFO is empty.

Signed-off-by: Lukasz Majewski 
---

 drivers/serial/serial_pl01x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index dbf2b2df34..428a4d210d 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -329,7 +329,7 @@ int pl01x_serial_pending(struct udevice *dev, bool input)
if (input)
return pl01x_tstc(priv->regs);
else
-   return fr & UART_PL01x_FR_TXFF ? 0 : 1;
+   return fr & UART_PL01x_FR_TXFE ? 0 : 1;
 }
 
 static const struct dm_serial_ops pl01x_serial_ops = {
-- 
2.30.2

[PATCH v1 09/16] serial: pl01x: Change OF_CONTROL to OF_REAL

2023-05-19 Thread Lukasz Majewski

Before this change, building this driver for SPL with enabled SPL_DM_SERIAL
was problematic, as '-Wunused-const-variable=' warning was visible.

Now, the code is only considered when u-boot proper is build.

Signed-off-by: Lukasz Majewski 
---

 drivers/serial/serial_pl01x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index f5468353e1..18332c2192 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -331,7 +331,7 @@ static const struct dm_serial_ops pl01x_serial_ops = {
.setbrg = pl01x_serial_setbrg,
 };
 
-#if CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_REAL)
 static const struct udevice_id pl01x_serial_id[] ={
{.compatible = "arm,pl011", .data = TYPE_PL011},
{.compatible = "arm,pl010", .data = TYPE_PL010},
-- 
2.30.2

[PATCH v1 10/16] serial: pl01x: Prepare the driver to support SPL_OF_PLATDATA

2023-05-19 Thread Lukasz Majewski

This commit prepares the pl01x serial driver to be used with
SPL_OF_PLATDATA enabled.

Signed-off-by: Lukasz Majewski 
---

 drivers/serial/serial_pl01x.c   | 12 
 include/dm/platform_data/serial_pl01x.h |  4 
 2 files changed, 16 insertions(+)

diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 18332c2192..dbf2b2df34 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -291,8 +291,16 @@ int pl01x_serial_probe(struct udevice *dev)
struct pl01x_serial_plat *plat = dev_get_plat(dev);
struct pl01x_priv *priv = dev_get_priv(dev);
 
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct dtd_serial_pl01x *dtplat = >dtplat;
+
+   priv->regs = (struct pl01x_regs *)dtplat->reg[0];
+   plat->type = dtplat->type;
+#else
priv->regs = (struct pl01x_regs *)plat->base;
+#endif
priv->type = plat->type;
+
if (!plat->skip_init)
return pl01x_generic_serial_init(priv->regs, priv->type);
else
@@ -380,8 +388,10 @@ int pl01x_serial_of_to_plat(struct udevice *dev)
 U_BOOT_DRIVER(serial_pl01x) = {
.name   = "serial_pl01x",
.id = UCLASS_SERIAL,
+#if CONFIG_IS_ENABLED(OF_REAL)
.of_match = of_match_ptr(pl01x_serial_id),
.of_to_plat = of_match_ptr(pl01x_serial_of_to_plat),
+#endif
.plat_auto  = sizeof(struct pl01x_serial_plat),
.probe = pl01x_serial_probe,
.ops= _serial_ops,
@@ -389,6 +399,8 @@ U_BOOT_DRIVER(serial_pl01x) = {
.priv_auto  = sizeof(struct pl01x_priv),
 };
 
+DM_DRIVER_ALIAS(serial_pl01x, arm_pl011)
+DM_DRIVER_ALIAS(serial_pl01x, arm_pl010)
 #endif
 
 #if defined(CONFIG_DEBUG_UART_PL010) || defined(CONFIG_DEBUG_UART_PL011)
diff --git a/include/dm/platform_data/serial_pl01x.h 
b/include/dm/platform_data/serial_pl01x.h
index e3d4e308a1..811697ce5c 100644
--- a/include/dm/platform_data/serial_pl01x.h
+++ b/include/dm/platform_data/serial_pl01x.h
@@ -20,7 +20,11 @@ enum pl01x_type {
  * @skip_init: Don't attempt to change port configuration (also means @clock
  * is ignored)
  */
+#include 
 struct pl01x_serial_plat {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct dtd_serial_pl01x dtplat;
+#endif
unsigned long base;
enum pl01x_type type;
unsigned int clock;
-- 
2.30.2

[PATCH v1 08/16] dts: xea: Disable 'clks' node for xea (imx287)

2023-05-19 Thread Lukasz Majewski

As imx28 family of SoCs is NOT supporting the Common Clock Framework (CCF)
the 'clks' property shall NOT be enabled by default.

Without this change u-boot proper before relocation tries to bind driver
(which doesn't exists) for this device. As a result, pre-relocation DTB
parsing is finished with error and the board hangs in a very early stage
of u-boot proper boot process.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index 52fec31fbb..bdbeca528c 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -32,6 +32,7 @@
 
  {
bootph-pre-ram;
+   status = "disable";
 };
 
  {
-- 
2.30.2

[PATCH v1 07/16] dts: xea: Remove clocks property from debug UART on XEA

2023-05-19 Thread Lukasz Majewski

The imx287 SoC doesn't support common clock framework (CCF), so the
'clocks' property is removed to avoid early (i.e. in SPL) errors when
SPL_OF_PLATDATA is used.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index 50289cf6d7..52fec31fbb 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -35,6 +35,7 @@
 };
 
  {
+   /delete-property/ clocks;
bootph-pre-ram;
type = <1>; /* TYPE_PL011 */
 };
-- 
2.30.2

[PATCH v1 06/16] dts: xea: Add u-boot specific 'type' property to duart

2023-05-19 Thread Lukasz Majewski

The DM_SERIAL implicitly requires CONFIG_PL01X_SERIAL, which
allows support for both serial IP block versions (i.e. PL011 and
PL010).

The decision about used IP block is based on the compatible string,
when DM is used.

In the XEA, the OF_PLATDATA is used to allow usage of serial driver in
the SPL (as the size of SPL is crucial). In this case one cannot extract
the type of IP block from .data field (corresponding to compatible) and
it must be explicitly read at probe from dtoc generated, u-boot specific
property.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index e40a6d240c..50289cf6d7 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -36,6 +36,7 @@
 
  {
bootph-pre-ram;
+   type = <1>; /* TYPE_PL011 */
 };
 
  {
-- 
2.30.2

[PATCH v1 05/16] dts: xea: Enable debug UART support in XEA's SPL (DM_SERIAL)

2023-05-19 Thread Lukasz Majewski

After enabling DM_SERIAL for XEA board, the same serial shall be used
in the SPL (with SPL_OF_PLATDATA support).

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index 9f1e261b2f..e40a6d240c 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -34,6 +34,10 @@
bootph-pre-ram;
 };
 
+ {
+   bootph-pre-ram;
+};
+
  {
bootph-pre-ram;
 };
-- 
2.30.2

[PATCH v1 04/16] spl: xea: Provide stub DM driver for imx28 clocks

2023-05-19 Thread Lukasz Majewski

This code fixes following WARNING:
  DTOCspl/dts/dt-plat.c
fsl_imx28_clkctrl: WARNING: the driver fsl_imx28_clkctrl was not found in the 
driver list

As imx28 doesn't yet support common clock framework, this prevents from
DTOC warnings during SPL build.

Signed-off-by: Lukasz Majewski 
---

 board/liebherr/xea/xea.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index 38e841c5f6..ed2b39f70e 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -203,5 +203,22 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
 }
 #endif
-
+/*
+ * NOTE:
+ *
+ * IMX28 clock "stub" DM driver!
+ *
+ * Only used for SPL stage, which is NOT using DM; serial and
+ * eMMC configuration.
+ */
+static const struct udevice_id imx28_clk_ids[] = {
+   { .compatible = "fsl,imx28-clkctrl", },
+   { }
+};
+
+U_BOOT_DRIVER(fsl_imx28_clkctrl) = {
+   .name   = "fsl_imx28_clkctrl",
+   .id = UCLASS_CLK,
+   .of_match   = imx28_clk_ids,
+};
 #endif /* CONFIG_SPL_BUILD */
-- 
2.30.2

[PATCH v1 03/16] defconfig: xea: Change default spi-nor memory bus to 2

2023-05-19 Thread Lukasz Majewski

After the re-sync with Linux kernel (v6.0) of the XEA DTS
(SHA1: 7d08ddd09b75e7a3c103cc0d0d3ed700287f268e) the alias
for SPI bus, to which SPI-NOR  memory is connected, has changed from
'spi3' to 'spi2'.

To be in sync with current u-boot's xea dts, the default bus number
(which allows running 'sf probe' without any extra parameters given)
has been adjusted.

Signed-off-by: Lukasz Majewski 
---

 configs/imx28_xea_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 06dd6b1f0e..4a217b1f91 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -95,7 +95,7 @@ CONFIG_MMC_MXS=y
 CONFIG_MTD=y
 CONFIG_DM_MTD=y
 CONFIG_DM_SPI_FLASH=y
-CONFIG_SF_DEFAULT_BUS=3
+CONFIG_SF_DEFAULT_BUS=2
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.30.2

[PATCH v1 02/16] dts: xea: Provide missing FEC required properties (mac0 and reg_fec_3v3)

2023-05-19 Thread Lukasz Majewski

After the commit (SHA1: 7d08ddd09b75e7a3c103cc0d0d3ed700287f268e) some
u-boot specific XEA FEC related properties have been replaced by ones
from the Linux kernel.

To be more specific - XEA board (and imx287 in general) has built L2
switch connected to FEC, which needs some special treatment.

In u-boot it is handled with 'mac0' node, whereas Linux uses dedicated
switch DTS node.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index 22dd7bc8a8..9f1e261b2f 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -38,12 +38,34 @@
bootph-pre-ram;
 };
 
+ {
+   phy-mode = "rmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   phy-supply = <_fec_3v3>;
+   phy-reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <1>;
+   phy-reset-post-delay = <1>;
+   status = "okay";
+
+   fixed-link {
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
/delete-property/ pinctrl-names;
/delete-property/ pinctrl-0;
bootph-pre-ram;
 };
 
+_fec_3v3 {
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+};
+
  {
bootph-pre-ram;
 };
-- 
2.30.2

[PATCH v1 01/16] dts: xea: Delete not used in u-boot DTS nodes

2023-05-19 Thread Lukasz Majewski

After the re-sync with Linux Kernel's DTS
(SHA1: 7d08ddd09b75e7a3c103cc0d0d3ed700287f268e), the XEA's
descripion has nodes and properties, which are NOT utilized
in the u-boot.

To avoid confusion - those are deleted.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/imx28-xea-u-boot.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi 
b/arch/arm/dts/imx28-xea-u-boot.dtsi
index f6488154d8..22dd7bc8a8 100644
--- a/arch/arm/dts/imx28-xea-u-boot.dtsi
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -12,6 +12,11 @@
  */
 #include "imx28-u-boot.dtsi"
 / {
+   aliases {
+   /delete-property/ spi1;
+   /delete-property/ usbphy0;
+   /delete-property/ usbphy1;
+   };
apb@8000 {
bootph-pre-ram;
 
@@ -34,6 +39,8 @@
 };
 
  {
+   /delete-property/ pinctrl-names;
+   /delete-property/ pinctrl-0;
bootph-pre-ram;
 };
 
@@ -46,3 +53,12 @@
spi-max-frequency = <4000>;
bootph-pre-ram;
 };
+
+/delete-node/ 
+/delete-node/ 
+/delete-node/ 
+/delete-node/ 
+/delete-node/ 
+/delete-node/ _pins_a;
+/delete-node/ _pins_tiva;
+/delete-node/ _pins_coding;
-- 
2.30.2

[PATCH v1 00/16] arm: xea: Update i.MX28 XEA board to use DM_SERIAL

2023-05-19 Thread Lukasz Majewski

This patch series fixes i.MX28 based XEA board to utilize DM_SERIAL

Changes:
- Patches 1-3 - fix DTS (after Linux update) to debrick XEA
- Patches 4-8 - prepare XEA's DTS to support DM_SERIAL
- Patches 9-11 - fixes serial_pl01x.c driver (as this driver is
 used by XEA, I would prefer to have this in a single
 patchset - otherwise board may be bricked
- Patches 12-14 - XEA and imx28 generic code fixes to support
  DM_SERIAL with OF_PLATDATA
- Patches 15-16 - config modification to support DM_SERIAL

CI:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=44=results

Applied on top of u-boot/master branch
SHA1: 6e1852ca2c418e2536ead4b51c4d84a59926b3f1



Lukasz Majewski (16):
  dts: xea: Delete not used in u-boot DTS nodes
  dts: xea: Provide missing FEC required properties (mac0 and
reg_fec_3v3)
  defconfig: xea: Change default spi-nor memory bus to 2
  spl: xea: Provide stub DM driver for imx28 clocks
  dts: xea: Enable debug UART support in XEA's SPL (DM_SERIAL)
  dts: xea: Add u-boot specific 'type' property to duart
  dts: xea: Remove clocks property from debug UART on XEA
  dts: xea: Disable 'clks' node for xea (imx287)
  serial: pl01x: Change OF_CONTROL to OF_REAL
  serial: pl01x: Prepare the driver to support SPL_OF_PLATDATA
  serial: pl01x: Modify pending callback to test if transmit FIFO is
empty
  arm: mxs: Prevent serial console init when in very early SPL boot code
  arm: xea: Call spl_early_init() before DM serial console is enabled in
SPL
  arm: Kconfig: Switch XEA (imx287 based) board to use
CONFIG_PL01X_SERIAL
  config: xea: Enable DM_SERIAL for the XEA (imx287 based) board
  config: xea: Enable DM_SERIAL for the XEA - single binary (SB) u-boot

 arch/arm/Kconfig|  2 +-
 arch/arm/cpu/arm926ejs/mxs/spl_boot.c   |  6 ++--
 arch/arm/dts/imx28-xea-u-boot.dtsi  | 45 +
 arch/arm/mach-imx/mxs/Kconfig   |  1 +
 board/liebherr/xea/xea.c| 20 ++-
 configs/imx28_xea_defconfig |  5 +--
 configs/imx28_xea_sb_defconfig  |  2 ++
 drivers/serial/serial_pl01x.c   | 16 +++--
 include/dm/platform_data/serial_pl01x.h |  4 +++
 9 files changed, 93 insertions(+), 8 deletions(-)

-- 
2.30.2

Re: [PATCH 1/5] arm: mxs: Provide Kconfig option to to not use VDD5V as IMX28 PMU source

2023-05-19 Thread Lukasz Majewski

Hi Marek,

> On 5/9/23 17:04, Lukasz Majewski wrote:
> > Hi Marek,
> >   
> >> On 5/9/23 16:46, Lukasz Majewski wrote:  
> >>> Hi Marek,  
> >>
> >> Hi,
> >>  
> >>>> On 5/9/23 16:32, Lukasz Majewski wrote:  
> >>>>> This option sets the current limit for 5V source to zero, so all
> >>>>> the PMU outputs are primarily powered from battery source
> >>>>> (DCDC_BAT).
> >>>>>
> >>>>> This option may be set on systems, where the 5V is NOT supposed
> >>>>> to be in any scenario powering the system - for example on
> >>>>> systems where DCDC_BAT is connected to fixed and regulated 4.2V
> >>>>> source (so the "battery" is not present).  
> >>>>
> >>>> Is it possible to dig this information out of DT or is the DT not
> >>>> available in SPL for this platform ?  
> >>>
> >>> This platform uses only SPL_OF_PLATDATA to keep the SPL size < 40
> >>> KiB.
> >>>
> >>> I would prefer to keep this as Kconfig as the PMU driver is not
> >>> supporting DT and in fact now ARCH_MX28 only has two boards
> >>> supported - XEA and imx28evk.  
> >>
> >> Why not use the platdata then ?
> >> This makes it far better, as the code is actually always compiled
> >> and doesn't start to bitrot.  
> > 
> > As fair as I can tell - the MX28 PMU driver in SPL is not supporting
> > OF_PLATDATA. Or have I overlooked something?
> > 
> > I would like to investigate the PMU issue, and avoid extra work to
> > provide platdata support for two supported imx287 based boards.  
> 
> Hum, considering that this platform is basically legacy and winding 
> down, I guess that's OK too.

Are there any other issues to be solved? Or is this patch set eligible
for pulling?

(Especially that NXP has confirmed that approach used in this patch set
is in sync with their idea of PMU usage).

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: lu...@denx.de


pgpThhz1lUiPu.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/5] arm: mxs: Provide Kconfig option to to not use VDD5V as IMX28 PMU source

2023-05-09 Thread Lukasz Majewski

Hi Marek,

> On 5/9/23 16:46, Lukasz Majewski wrote:
> > Hi Marek,  
> 
> Hi,
> 
> >> On 5/9/23 16:32, Lukasz Majewski wrote:  
> >>> This option sets the current limit for 5V source to zero, so all
> >>> the PMU outputs are primarily powered from battery source
> >>> (DCDC_BAT).
> >>>
> >>> This option may be set on systems, where the 5V is NOT supposed to
> >>> be in any scenario powering the system - for example on systems
> >>> where DCDC_BAT is connected to fixed and regulated 4.2V source (so
> >>> the "battery" is not present).  
> >>
> >> Is it possible to dig this information out of DT or is the DT not
> >> available in SPL for this platform ?  
> > 
> > This platform uses only SPL_OF_PLATDATA to keep the SPL size < 40
> > KiB.
> > 
> > I would prefer to keep this as Kconfig as the PMU driver is not
> > supporting DT and in fact now ARCH_MX28 only has two boards
> > supported - XEA and imx28evk.  
> 
> Why not use the platdata then ?
> This makes it far better, as the code is actually always compiled and 
> doesn't start to bitrot.

As fair as I can tell - the MX28 PMU driver in SPL is not supporting
OF_PLATDATA. Or have I overlooked something?

I would like to investigate the PMU issue, and avoid extra work to
provide platdata support for two supported imx287 based boards.

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: lu...@denx.de


pgpCF8QxjXwwh.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/5] arm: mxs: Provide Kconfig option to to not use VDD5V as IMX28 PMU source

2023-05-09 Thread Lukasz Majewski

Hi Marek,

> On 5/9/23 16:32, Lukasz Majewski wrote:
> > This option sets the current limit for 5V source to zero, so all
> > the PMU outputs are primarily powered from battery source
> > (DCDC_BAT).
> > 
> > This option may be set on systems, where the 5V is NOT supposed to
> > be in any scenario powering the system - for example on systems
> > where DCDC_BAT is connected to fixed and regulated 4.2V source (so
> > the "battery" is not present).  
> 
> Is it possible to dig this information out of DT or is the DT not 
> available in SPL for this platform ?

This platform uses only SPL_OF_PLATDATA to keep the SPL size < 40 KiB.

I would prefer to keep this as Kconfig as the PMU driver is not
supporting DT and in fact now ARCH_MX28 only has two boards supported -
XEA and imx28evk.


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: lu...@denx.de


pgpbD8zezcdFu.pgp
Description: OpenPGP digital signature

[PATCH 5/5] arm: config: Adjust imx287 based XEA board PMU configuration

2023-05-09 Thread Lukasz Majewski

This patch adjusts XEA's PMU setup as this board is supposed to be
mainly powered from DCDC_BATT source.

Moreover, in this HW design the VDD_4P2 is not used as well.

Signed-off-by: Lukasz Majewski 
---
 configs/imx28_xea_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 579545f4ed..3d92a06999 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -13,6 +13,9 @@ CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="imx28-xea"
 CONFIG_SPL_TEXT_BASE=0x1000
 CONFIG_TARGET_XEA=y
+CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y
+CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y
+# CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR is not set
 CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_STACK=0x2
-- 
2.30.2

[PATCH 4/5] arm: mxs: Add function to dump PMU registers

2023-05-09 Thread Lukasz Majewski

This commit provides function, which when debugging
output is enabled dumps the IMX28 PMU registers.

Signed-off-by: Lukasz Majewski 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 24 +
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 24f61b4b56..7ea029e371 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -41,6 +41,29 @@ static void mxs_power_clock2xtal(void)
_regs->hw_clkctrl_clkseq_set);
 }
 
+static void mxs_power_regs_dump(void)
+{
+   struct mxs_power_regs *power_regs =
+   (struct mxs_power_regs *)MXS_POWER_BASE;
+
+   debug("ctrl:\t\t 0x%x\n", readl(_regs->hw_power_ctrl));
+   debug("5vctrl:\t\t 0x%x\n", readl(_regs->hw_power_5vctrl));
+   debug("minpwr:\t\t 0x%x\n", readl(_regs->hw_power_minpwr));
+   debug("charge:\t\t 0x%x\n", readl(_regs->hw_power_charge));
+   debug("vddctrl:\t 0x%x\n", readl(_regs->hw_power_vdddctrl));
+   debug("vddactrl:\t 0x%x\n", readl(_regs->hw_power_vddactrl));
+   debug("vddioctrl:\t 0x%x\n", readl(_regs->hw_power_vddioctrl));
+   debug("vddmemctrl:\t 0x%x\n", readl(_regs->hw_power_vddmemctrl));
+   debug("dcdc4p2:\t 0x%x\n", readl(_regs->hw_power_dcdc4p2));
+   debug("misc:\t\t 0x%x\n", readl(_regs->hw_power_misc));
+   debug("dclimits:\t 0x%x\n", readl(_regs->hw_power_dclimits));
+   debug("loopctrl:\t 0x%x\n", readl(_regs->hw_power_loopctrl));
+   debug("sts:\t\t 0x%x\n", readl(_regs->hw_power_sts));
+   debug("speed:\t\t 0x%x\n", readl(_regs->hw_power_speed));
+   debug("battmonitor:\t 0x%x\n",
+ readl(_regs->hw_power_battmonitor));
+}
+
 /**
  * mxs_power_clock2pll() - Switch CPU core clock source to PLL
  *
@@ -1280,6 +1303,7 @@ void mxs_power_init(void)
POWER_CTRL_DCDC4P2_BO_IRQ, _regs->hw_power_ctrl_clr);
 
writel(POWER_5VCTRL_PWDN_5VBRNOUT, _regs->hw_power_5vctrl_set);
+   mxs_power_regs_dump();
 
early_delay(1000);
 }
-- 
2.30.2

[PATCH 3/5] arm: mxs: Provide Kconfig option to not enable 4P2 regulator in IMX28 PMU

2023-05-09 Thread Lukasz Majewski

The IMX28 PMU (Power Management Unit) has a dedicated Linear Regulator
to produce (by default) 4.2V output - available outside the chip as
VDD_4P2.

When system is supposed to not use VDD5V as a main power source - instead
the DCDC_BATT is used; it is safe to disable this regulator.

As the in-PMU DCDC switching regulator (from which DCDC_VDDA, DCDC_VDDIO
and DCDC_VDDD are generated) can be driven from DCDC_BATT or output
of this 4P2 regulator - by disabling the latter the use of the DCDC_BATT
is forced.

To be more specific - according to NXP's AN4199 the DCDC_BATT source is
preferred (over VDD5V), as more efficient and stable source for
industrial applications.

Signed-off-by: Lukasz Majewski 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 3 ++-
 arch/arm/mach-imx/mxs/Kconfig   | 7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 7c584db27c..24f61b4b56 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -763,7 +763,8 @@ static void mxs_batt_boot(void)
   _regs->hw_power_5vctrl_set);
}
 
-   mxs_power_enable_4p2();
+   if (CONFIG_IS_ENABLED(MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR))
+   mxs_power_enable_4p2();
 }
 
 /**
diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index f5e45ae846..5cffc26103 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -63,6 +63,13 @@ config SPL_MXS_PMU_DISABLE_BATT_CHARGE
bool "Disable Battery Charging in MX28 PMU"
default n
 
+config SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR
+   bool "Enable the 4P2 linear regulator in MX28 PMU"
+   default y
+   help
+ This option enables the 4P2 linear regulator (derived
+ from VDD5V) - so the VDD4P2 power source is operational.
+
 source "board/freescale/mx28evk/Kconfig"
 source "board/liebherr/xea/Kconfig"
 
-- 
2.30.2

[PATCH 2/5] arm: mxs: Provide Kconfig option to disable battery charging at IMX28 PMU

2023-05-09 Thread Lukasz Majewski

This new Kconfig option allows disabling the in-PMU battery charging
block. This may be required when DCDC_BAT source is powered not from
battery, but from already regulated, good quality source.

Signed-off-by: Lukasz Majewski 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 7 +++
 arch/arm/mach-imx/mxs/Kconfig   | 4 
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 9965810ac2..7c584db27c 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -756,6 +756,13 @@ static void mxs_batt_boot(void)
setbits_le32(_regs->hw_power_5vctrl,
 POWER_5VCTRL_ILIMIT_EQ_ZERO);
 
+   if (CONFIG_IS_ENABLED(MXS_PMU_DISABLE_BATT_CHARGE)) {
+   writel(POWER_CHARGE_PWD_BATTCHRG,
+  _regs->hw_power_charge_set);
+   writel(POWER_5VCTRL_PWD_CHARGE_4P2_MASK,
+  _regs->hw_power_5vctrl_set);
+   }
+
mxs_power_enable_4p2();
 }
 
diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index 3232b0fb67..f5e45ae846 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -59,6 +59,10 @@ config SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT
  by the PMU is reduced to zero - the DCDC_BATT is used as
  the main power source for PMU.
 
+config SPL_MXS_PMU_DISABLE_BATT_CHARGE
+   bool "Disable Battery Charging in MX28 PMU"
+   default n
+
 source "board/freescale/mx28evk/Kconfig"
 source "board/liebherr/xea/Kconfig"
 
-- 
2.30.2

[PATCH 1/5] arm: mxs: Provide Kconfig option to to not use VDD5V as IMX28 PMU source

2023-05-09 Thread Lukasz Majewski

This option sets the current limit for 5V source to zero, so all
the PMU outputs are primarily powered from battery source (DCDC_BAT).

This option may be set on systems, where the 5V is NOT supposed to be
in any scenario powering the system - for example on systems where
DCDC_BAT is connected to fixed and regulated 4.2V source (so the
"battery" is not present).

Signed-off-by: Lukasz Majewski 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 4 
 arch/arm/mach-imx/mxs/Kconfig   | 8 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index c33170f06d..9965810ac2 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -752,6 +752,10 @@ static void mxs_batt_boot(void)
POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
 
+   if (CONFIG_IS_ENABLED(MXS_PMU_MINIMAL_VDD5V_CURRENT))
+   setbits_le32(_regs->hw_power_5vctrl,
+POWER_5VCTRL_ILIMIT_EQ_ZERO);
+
mxs_power_enable_4p2();
 }
 
diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index b2026a3758..3232b0fb67 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -51,6 +51,14 @@ endchoice
 config SYS_SOC
default "mxs"
 
+config SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT
+   bool "Force minimal current draw from VDD5V by MX28 PMU"
+   default n
+   help
+ After setting this option, the current drawn from VDD5V
+ by the PMU is reduced to zero - the DCDC_BATT is used as
+ the main power source for PMU.
+
 source "board/freescale/mx28evk/Kconfig"
 source "board/liebherr/xea/Kconfig"
 
-- 
2.30.2

Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled

2023-05-04 Thread Lukasz Majewski

On Sun, 30 Apr 2023 23:20:35 +0200
Marek Vasut  wrote:

> In case NET networking is not enabled, it is not possible to compile
> the USB ethernet gadget. Protect the symbols in Makefile to avoid
> build failure. Such build failure may occur e.g. in case NET and USB
> ethernet gadget is enabled in U-Boot proper, but not in SPL.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Lukasz Majewski 
> ---
>  drivers/usb/gadget/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
> index 6cfe0f3a041..36f65e7eb95 100644
> --- a/drivers/usb/gadget/Makefile
> +++ b/drivers/usb/gadget/Makefile
> @@ -34,8 +34,10 @@ endif
>  
>  obj-$(CONFIG_CI_UDC) += ci_udc.o
>  
> +ifeq ($(CONFIG_$(SPL_TPL_)NET),y)
>  obj-$(CONFIG_USB_ETHER) += ether.o
>  obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o
> +endif
>  
>  # Devices not related to the new gadget layer depend on
> CONFIG_USB_DEVICE # This is really only N900 and USBTTY now.

Reviewed-by: Lukasz Majewski 


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: lu...@denx.de


pgprhg_u6wz1J.pgp
Description: OpenPGP digital signature

Question regarding CONFIG_SPL_OF_PLATDATA_INST usage

2023-04-27 Thread Lukasz Majewski

Hi Simon,

I'm trying to convert imx28 based XEA board to use CONFIG_DM_SERIAL.
This board uses SPL_OF_PLATDATA to have as small SPL as possible.

It looks like the 'duart' description/driver is properly instantiated,
but serial console is configured too early -> apparently
serial_find_console_or_panic() from serial_init() at serial-uclass.c is
called before DM is setup in SPL.


To fix this problem - in the commit (SHA1: 5a1b25c2011) the
CONFIG_SPL_OF_PLATDATA_INST has been introduced; without it (after
commit SHA1: 1e9ced28f18ed75bef96df08e47baad27dd51829) uclass_get()
returns -EDEADLOCK.


Grepping the sources show that only two "boards" use it:

1. arch/x86/cpu/apollolake/Kconfig -> TPL_OF_PLATDATA_INST 
   (configs/chromebook_coral_defconfig and corresponding
   ./arch/x86/dts/chromebook_coral.dts)

2. configs/sandbox_spl_defconfig   -> CONFIG_SPL_OF_PLATDATA_INST=y



I would like to ask if:

- Anybody managed to use CONFIG_SPL_OF_PLATDATA_INST=y on real HW?

- Is it on purpose, that dtoc tool is not extracting structures
  definitions from *.c files ? 

- Is the "coral" board (from point 1 above) using any extra
  coral*-u-boot.dtsi to specify which parts of dts shall be included to
  the in-TPL DTS? Or is it just using full-blown DTS support ins TPL?


I'm using cutting-edge mainline u-boot - SHA1:
6a11fdf0536e02ac9cd4a3da0535a271c694715f

Thanks in advance for any help.



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: lu...@denx.de


pgp30eQ73nLd5.pgp
Description: OpenPGP digital signature

Re: [PATCH] net: eth-uclass: change state before stop() in eth_halt()

2022-12-01 Thread Lukasz Majewski

On Wed, 30 Nov 2022 17:42:25 +0100
Niel Fourie  wrote:

> In eth_halt(), change the private uclass state before calling
> stop() instead of afterwards, to avoid writing to memory which
> may have been freed during stop().
> 
> In the ethernet gadget implementation, the gadget device gets
> probed during start() and removed during stop(), which includes
> freeing `uclass_priv_` to which `priv` is pointing. Writing to
> `priv` after stop() may corrupt the `fd` member of `struct
> malloc_chunk`, which represents the freed block, and could cause
> hard-to-debug crashes on subsequent calls to malloc()/free().
> 
> Signed-off-by: Niel Fourie 
> Cc: Ramon Fried 
> Cc: Marek Vasut 
> Cc: Lukasz Majewski 
> ---
>  net/eth-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index f41da4b37b3..bc3b9751e32 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -342,9 +342,9 @@ void eth_halt(void)
>   if (!priv || !priv->running)
>   return;
>  
> - eth_get_ops(current)->stop(current);
>   priv->state = ETH_STATE_PASSIVE;
>   priv->running = false;
> +     eth_get_ops(current)->stop(current);
>  }
>  
>  int eth_is_active(struct udevice *dev)

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

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


pgpUyKqY6QvtU.pgp
Description: OpenPGP digital signature

Re: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration

2022-06-20 Thread Lukasz Majewski

Hi Jaehoon,

> Add CONFIG_DFU_NAME_MAX_SIZE to change the proper size.
> If name is longer than default size, it can do wrong behavior during
> updating image. So it need to change the proper maximum size.
> 
> This patch is proviced the solution to change value with
> configuration.
> 
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/dfu/Kconfig | 9 +
>  include/dfu.h   | 2 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> index 8d7f13dcb0b5..a181f0b8d7ba 100644
> --- a/drivers/dfu/Kconfig
> +++ b/drivers/dfu/Kconfig
> @@ -111,5 +111,14 @@ config SYS_DFU_MAX_FILE_SIZE
> the buffer once we've been given the whole file.  Define
> this to the maximum filesize (in bytes) for the buffer.
> If undefined it defaults to the
> CONFIG_SYS_DFU_DATA_BUF_SIZE. +
> +config DFU_NAME_MAX_SIZE
> + int "Size of the name to be added in dfu entity"
> + default 32
> + depends on DFU
> + help
> +   This value is used to maximum size. If name is longer than
> default size,
> +   we need to change the proper maximum size.
> +
>  endif
>  endmenu
> diff --git a/include/dfu.h b/include/dfu.h
> index dcb9cd9d799a..948596f367d9 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -99,7 +99,7 @@ struct virt_internal_data {
>   int dev_num;
>  };
>  
> -#define DFU_NAME_SIZE32
> +#define DFU_NAME_SIZE    CONFIG_DFU_NAME_MAX_SIZE
>  #ifndef DFU_DEFAULT_POLL_TIMEOUT
>  #define DFU_DEFAULT_POLL_TIMEOUT 0
>  #endif

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

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


pgpm4HoRBWnwD.pgp
Description: OpenPGP digital signature

Re: [RFC] serial: mxc: get the clock frequency from the used clock for the device

2022-03-17 Thread Lukasz Majewski

Hi Sean,

> Hi Heiko,
> 
> On 3/17/22 8:41 AM, Heiko Thiery wrote:
> > With the clock driver enabled for the imx8mq, it was noticed that
> > the frequency used to calculate the baud rate is always taken from
> > the root clock of UART1. This can cause problems if UART1 is not
> > used as console and the settings are different from UART1. The
> > result is that the console output is garbage. To do this correctly
> > the UART frequency is taken from the used device. For the
> > implementations that don't have the igp clock frequency written or
> > can't return it the old way is tried.
> > 
> > Signed-off-by: Heiko Thiery 
> > ---
> >   drivers/serial/serial_mxc.c | 15 +--
> >   1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/serial/serial_mxc.c
> > b/drivers/serial/serial_mxc.c index e4970a169b..6fdb2b2397 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -3,6 +3,7 @@
> >* (c) 2007 Sascha Hauer 
> >*/
> >   
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -266,9 +267,19 @@ __weak struct serial_device
> > *default_serial_console(void) int mxc_serial_setbrg(struct udevice
> > *dev, int baudrate) {
> > struct mxc_serial_plat *plat = dev_get_plat(dev);
> > -   u32 clk = imx_get_uartclk();
> > +   u32 rate = 0;
> > +
> > +   if (IS_ENABLED(CONFIG_CLK)) {  
> 
> CONFIG_IS_ENABLED?
> 
> mx6ull at least does not have CONFIG_SPL_CLK enabled.

The problem with serial is that not all boards support DM clock in SPL.
I'm wondering if this patch has passed the CI tests for all boards.

> 
> > +   struct clk clk;
> > +   if(!clk_get_by_name(dev, "ipg", ))
> > +   rate = clk_get_rate();
> > +   }
> > +
> > +   /* as fallback we try to get the clk rate that way */
> > +   if (rate == 0)  
> 
> !rate || IS_ERR_VALUE(rate)
> 
> > +   rate = imx_get_uartclk();
> >   
> > -   _mxc_serial_setbrg(plat->reg, clk, baudrate,
> > plat->use_dte);
> > +   _mxc_serial_setbrg(plat->reg, rate, baudrate,
> > plat->use_dte); 
> > return 0;
> >   }
> >   
> --Sean




Best regards,

Lukasz Majewski

--

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


pgpOreM1OrRz3.pgp
Description: OpenPGP digital signature

[PATCH v2 3/3] defconfig: Enable DM_PMIC and DM PMIC_TPS65217 on AM335x EVM board

2022-03-11 Thread Lukasz Majewski

As this board now supports DM_I2C, it is safe for it to also use the
DM converted PMIC tps65217 driver.

Signed-off-by: Lukasz Majewski 

---

Changes in v2:
- Move the Kconfig definition for PMIC to patch, which adds support for DM

 configs/am335x_boneblack_vboot_defconfig | 3 +++
 configs/am335x_evm_defconfig | 3 +++
 configs/am335x_evm_spiboot_defconfig | 3 +++
 configs/am335x_hs_evm_defconfig  | 3 +++
 configs/am335x_hs_evm_uart_defconfig | 3 +++
 include/configs/am335x_evm.h | 1 -
 6 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/configs/am335x_boneblack_vboot_defconfig 
b/configs/am335x_boneblack_vboot_defconfig
index c79ffde91c..d46b2ac470 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -64,6 +64,9 @@ CONFIG_DM_ETH=y
 CONFIG_PHY_GIGE=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_DM_PMIC is not set
+CONFIG_PMIC_TPS65217=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 33d0fb818f..7f7556971b 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -83,6 +83,9 @@ CONFIG_DM_ETH=y
 CONFIG_PHY_GIGE=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_DM_PMIC is not set
+CONFIG_PMIC_TPS65217=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_evm_spiboot_defconfig 
b/configs/am335x_evm_spiboot_defconfig
index f8acb7e1a9..f7be718b58 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -77,6 +77,9 @@ CONFIG_PHY_SMSC=y
 CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_DM_PMIC is not set
+CONFIG_PMIC_TPS65217=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 993fbbcd39..fbb2d1f382 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -70,6 +70,9 @@ CONFIG_PHY_SMSC=y
 CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_DM_PMIC is not set
+CONFIG_PMIC_TPS65217=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_hs_evm_uart_defconfig 
b/configs/am335x_hs_evm_uart_defconfig
index ecb0526c33..b7008025de 100644
--- a/configs/am335x_hs_evm_uart_defconfig
+++ b/configs/am335x_hs_evm_uart_defconfig
@@ -72,6 +72,9 @@ CONFIG_PHY_SMSC=y
 CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_DM_PMIC is not set
+CONFIG_PMIC_TPS65217=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 7b02d91e47..42660f09d6 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -166,7 +166,6 @@
 #define CONFIG_SYS_NS16550_COM60x481aa000  /* UART5 */
 
 /* PMIC support */
-#define CONFIG_PMIC_TPS65217
 #define CONFIG_POWER_TPS65910
 
 /* SPL */
-- 
2.20.1

[PATCH v2 2/3] power: pmic: Provide DM_PMIC support for tps65217 driver

2022-03-11 Thread Lukasz Majewski

The tps65217 PMIC driver is used with am335x SoC based designs.

It is used in the SPL (MLO) as well, so the DM conversion only is
for u-boot proper.

This driver only allows simple reading/writing/dumping of the content
of its registers and requires the DM_I2C for proper operation.

Signed-off-by: Lukasz Majewski 
---

(no changes since v1)

 drivers/power/pmic/pmic_tps65217.c | 82 ++
 1 file changed, 82 insertions(+)

diff --git a/drivers/power/pmic/pmic_tps65217.c 
b/drivers/power/pmic/pmic_tps65217.c
index c7f532df4d..ccbf223593 100644
--- a/drivers/power/pmic/pmic_tps65217.c
+++ b/drivers/power/pmic/pmic_tps65217.c
@@ -6,8 +6,13 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
+#if !CONFIG_IS_ENABLED(DM_PMIC)
 struct udevice *tps65217_dev __section(".data") = NULL;
 
 /**
@@ -148,3 +153,80 @@ int power_tps65217_init(unsigned char bus)
 #endif
return 0;
 }
+#else /* CONFIG_IS_ENABLED(DM_PMIC) */
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "ldo", .driver = "tps65217_ldo" },
+   { },
+};
+
+static int tps65217_reg_count(struct udevice *dev)
+{
+   return TPS65217_PMIC_NUM_OF_REGS;
+}
+
+static int tps65217_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   pr_err("write error to device: %p register: %#x!\n", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65217_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret) {
+   pr_err("read error %d from device: %p register: %#x!\n", ret,
+  dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65217_bind(struct udevice *dev)
+{
+   ofnode regulators_node;
+   int children;
+
+   regulators_node = dev_read_subnode(dev, "regulators");
+   if (!ofnode_valid(regulators_node)) {
+   debug("%s: %s regulators subnode not found!\n", __func__,
+ dev->name);
+   return -ENXIO;
+   }
+
+   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   debug("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Always return success for this device */
+   return 0;
+}
+
+static struct dm_pmic_ops tps65217_ops = {
+   .reg_count = tps65217_reg_count,
+   .read = tps65217_read,
+   .write = tps65217_write,
+};
+
+static const struct udevice_id tps65217_ids[] = {
+   { .compatible = "ti,tps65217" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_tps65217) = {
+   .name = "tps65217 pmic",
+   .id = UCLASS_PMIC,
+   .of_match = tps65217_ids,
+   .bind = tps65217_bind,
+   .ops = _ops,
+};
+#endif
-- 
2.20.1

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 4007 matches

Mail list logo