[PATCH v3 10/10] video: tegra20: dsi: add reset support

2024-01-09 Thread Svyatoslav Ryhel
Implement reset use to discard any changes which could have been
applied to DSI before and can interfere with current configuration.

Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dsi.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/video/tegra20/tegra-dsi.c 
b/drivers/video/tegra20/tegra-dsi.c
index f4743e8458..6408026808 100644
--- a/drivers/video/tegra20/tegra-dsi.c
+++ b/drivers/video/tegra20/tegra-dsi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -849,6 +850,7 @@ static int tegra_dsi_bridge_probe(struct udevice *dev)
struct tegra_dsi_priv *priv = dev_get_priv(dev);
struct mipi_dsi_device *device = >device;
struct mipi_dsi_panel_plat *mipi_plat;
+   struct reset_ctl reset_ctl;
int ret;
 
priv->version = dev_get_driver_data(dev);
@@ -862,6 +864,13 @@ static int tegra_dsi_bridge_probe(struct udevice *dev)
priv->video_fifo_depth = 480;
priv->host_fifo_depth = 64;
 
+   ret = reset_get_by_name(dev, "dsi", _ctl);
+   if (ret) {
+   log_debug("%s: reset_get_by_name() failed: %d\n",
+ __func__, ret);
+   return ret;
+   }
+
ret = uclass_get_device_by_phandle(UCLASS_REGULATOR, dev,
   "avdd-dsi-csi-supply", >avdd);
if (ret)
@@ -900,12 +909,17 @@ static int tegra_dsi_bridge_probe(struct udevice *dev)
 
tegra_dsi_get_format(device->format, >format);
 
+   reset_assert(_ctl);
+
ret = regulator_set_enable_if_allowed(priv->avdd, true);
if (ret && ret != -ENOSYS)
return ret;
 
tegra_dsi_init_clocks(dev);
 
+   mdelay(2);
+   reset_deassert(_ctl);
+
return 0;
 }
 
-- 
2.40.1



[PATCH v3 09/10] video: tegra20: dsi: add T114 support

2024-01-09 Thread Svyatoslav Ryhel
Existing Tegra DSI driver mostly fits T114 apart MIPI calibration
which on T114 has dedicated driver. To resolve this MIPI calibration
logic was split for pre-T114 and T114+ devices.

Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dsi.c | 78 ++-
 .../video/tegra20/tegra-dsi.h | 24 +-
 2 files changed, 96 insertions(+), 6 deletions(-)
 rename arch/arm/include/asm/arch-tegra30/dsi.h => 
drivers/video/tegra20/tegra-dsi.h (90%)

diff --git a/drivers/video/tegra20/tegra-dsi.c 
b/drivers/video/tegra20/tegra-dsi.c
index 72b91ed26b..f4743e8458 100644
--- a/drivers/video/tegra20/tegra-dsi.c
+++ b/drivers/video/tegra20/tegra-dsi.c
@@ -20,17 +20,24 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "tegra-dc.h"
+#include "tegra-dsi.h"
 #include "mipi-phy.h"
 
+/* List of supported DSI bridges */
+enum {
+   DSI_V0,
+   DSI_V1,
+};
+
 struct tegra_dsi_priv {
struct mipi_dsi_host host;
struct mipi_dsi_device device;
struct mipi_dphy_timing dphy_timing;
 
struct udevice *panel;
+   struct udevice *mipi;
struct display_timing timing;
 
struct dsi_ctlr *dsi;
@@ -41,6 +48,8 @@ struct tegra_dsi_priv {
int dsi_clk;
int video_fifo_depth;
int host_fifo_depth;
+
+   u32 version;
 };
 
 static void tegra_dc_enable_controller(struct udevice *dev)
@@ -501,6 +510,41 @@ static void tegra_dsi_pad_calibrate(struct 
dsi_pad_ctrl_reg *pad)
writel(value, TEGRA_VI_BASE + (CSI_CIL_PAD_CONFIG << 2));
 }
 
+static void tegra_dsi_mipi_calibrate(struct tegra_dsi_priv *priv)
+{
+   struct dsi_pad_ctrl_reg *pad = >dsi->pad;
+   u32 value;
+   int ret;
+
+   ret = misc_set_enabled(priv->mipi, true);
+   if (ret)
+   log_debug("%s: failed to enable MIPI calibration: %d\n",
+ __func__, ret);
+
+   writel(0, >pad_ctrl);
+   writel(0, >pad_ctrl_1);
+   writel(0, >pad_ctrl_2);
+   writel(0, >pad_ctrl_3);
+   writel(0, >pad_ctrl_4);
+
+   /* DSI pad enable */
+   value = DSI_PAD_CONTROL_VS1_PULLDN(0) | DSI_PAD_CONTROL_VS1_PDIO(0);
+   writel(value, >pad_ctrl);
+
+   value = DSI_PAD_SLEW_UP(0x7) | DSI_PAD_SLEW_DN(0x7) |
+   DSI_PAD_LP_UP(0x1) | DSI_PAD_LP_DN(0x1) |
+   DSI_PAD_OUT_CLK(0x0);
+   writel(value, >pad_ctrl_2);
+
+   value = DSI_PAD_PREEMP_PD_CLK(0x3) | DSI_PAD_PREEMP_PU_CLK(0x3) |
+   DSI_PAD_PREEMP_PD(0x03) | DSI_PAD_PREEMP_PU(0x3);
+   writel(value, >pad_ctrl_3);
+
+   ret = misc_write(priv->mipi, 0, NULL, 0);
+   if (ret)
+   log_debug("%s: MIPI calibration failed %d\n", __func__, ret);
+}
+
 static void tegra_dsi_set_timeout(struct dsi_timeout_reg *rtimeout,
  unsigned long bclk,
  unsigned int vrefresh)
@@ -664,10 +708,25 @@ static int tegra_dsi_encoder_enable(struct udevice *dev)
u32 value;
int ret;
 
+   /* If for some reasone DSI is enabled then it needs to
+* be disabled in order for the panel initialization
+* commands to be properly sent.
+*/
+   value = readl(>dsi_pwr_ctrl);
+
+   if (value & DSI_POWER_CONTROL_ENABLE) {
+   value = readl(>dsi_pwr_ctrl);
+   value &= ~DSI_POWER_CONTROL_ENABLE;
+   writel(value, >dsi_pwr_ctrl);
+   }
+
/* Disable interrupt */
writel(0, >int_enable);
 
-   tegra_dsi_pad_calibrate(>dsi->pad);
+   if (priv->version)
+   tegra_dsi_mipi_calibrate(priv);
+   else
+   tegra_dsi_pad_calibrate(>dsi->pad);
 
tegra_dsi_get_muldiv(device->format, , );
 
@@ -792,6 +851,8 @@ static int tegra_dsi_bridge_probe(struct udevice *dev)
struct mipi_dsi_panel_plat *mipi_plat;
int ret;
 
+   priv->version = dev_get_driver_data(dev);
+
priv->dsi = (struct dsi_ctlr *)dev_read_addr_ptr(dev);
if (!priv->dsi) {
printf("%s: No display controller address\n", __func__);
@@ -814,6 +875,16 @@ static int tegra_dsi_bridge_probe(struct udevice *dev)
return log_ret(ret);
}
 
+   if (priv->version) {
+   ret = uclass_get_device_by_phandle(UCLASS_MISC, dev,
+  "nvidia,mipi-calibrate",
+  >mipi);
+   if (ret) {
+   log_debug("%s: cannot get MIPI: error %d\n", __func__, 
ret);
+   return ret;
+   }
+   }
+
panel_get_display_timing(priv->panel, >timing);
 
mipi_plat = dev_get_plat(priv->panel);
@@ -845,7 +916,8 @@ static const struct panel_ops tegra_dsi_bridge_ops = {
 };
 
 static const struct udevice_id tegra_dsi_bridge_ids[] = {
-   { 

[PATCH v3 08/10] video: tegra20: add MIPI calibration driver

2024-01-09 Thread Svyatoslav Ryhel
Dedicated MIPI calibration driver is used on T114 and newer. Before
T114 MIPI calibration registers were part of VI and CSI.

Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/Makefile |   2 +-
 drivers/video/tegra20/tegra-mipi.c | 188 +
 2 files changed, 189 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/tegra20/tegra-mipi.c

diff --git a/drivers/video/tegra20/Makefile b/drivers/video/tegra20/Makefile
index f0b534c579..a75aea2a87 100644
--- a/drivers/video/tegra20/Makefile
+++ b/drivers/video/tegra20/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-$(CONFIG_VIDEO_TEGRA20) += tegra-dc.o
-obj-$(CONFIG_VIDEO_DSI_TEGRA30) += tegra-dsi.o mipi-phy.o
+obj-$(CONFIG_VIDEO_DSI_TEGRA30) += tegra-dsi.o tegra-mipi.o mipi-phy.o
 obj-$(CONFIG_TEGRA_BACKLIGHT_PWM) += tegra-pwm-backlight.o
diff --git a/drivers/video/tegra20/tegra-mipi.c 
b/drivers/video/tegra20/tegra-mipi.c
new file mode 100644
index 00..2df3c1a994
--- /dev/null
+++ b/drivers/video/tegra20/tegra-mipi.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 NVIDIA Corporation
+ * Copyright (c) 2023 Svyatoslav Ryhel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* MIPI control registers 0x00 ~ 0x60 */
+struct mipi_ctlr {
+   uint mipi_cal_ctrl;
+   uint mipi_cal_autocal_ctrl;
+   uint mipi_cal_status;
+
+   uint unused1[2];
+
+   uint mipi_cal_config_csia;
+   uint mipi_cal_config_csib;
+   uint mipi_cal_config_csic;
+   uint mipi_cal_config_csid;
+   uint mipi_cal_config_csie;
+
+   uint unused2[4];
+
+   uint mipi_cal_config_dsia;
+   uint mipi_cal_config_dsib;
+   uint mipi_cal_config_dsic;
+   uint mipi_cal_config_dsid;
+
+   uint unused3[4];
+
+   uint mipi_cal_bias_pad_cfg0;
+   uint mipi_cal_bias_pad_cfg1;
+   uint mipi_cal_bias_pad_cfg2;
+};
+
+#define MIPI_CAL_CTRL_NOISE_FILTER(x)  (((x) & 0xf) << 26)
+#define MIPI_CAL_CTRL_PRESCALE(x)  (((x) & 0x3) << 24)
+#define MIPI_CAL_CTRL_CLKEN_OVRBIT(4)
+#define MIPI_CAL_CTRL_STARTBIT(0)
+
+#define MIPI_CAL_STATUS_DONE   BIT(16)
+#define MIPI_CAL_STATUS_ACTIVE BIT(0)
+
+#define MIPI_CAL_OVERIDE(x)(((x) & 0x1) << 30)
+#define MIPI_CAL_SEL(x)(((x) & 0x1) << 21)
+#define MIPI_CAL_HSPDOS(x) (((x) & 0x1f) << 16)
+#define MIPI_CAL_HSPUOS(x) (((x) & 0x1f) << 8)
+#define MIPI_CAL_TERMOS(x) (((x) & 0x1f) << 0)
+
+#define MIPI_CAL_BIAS_PAD_PDVCLAMP BIT(1)
+#define MIPI_CAL_BIAS_PAD_E_VCLAMP_REF BIT(0)
+
+#define MIPI_CAL_BIAS_PAD_DRV_DN_REF(x) (((x) & 0x7) << 16)
+#define MIPI_CAL_BIAS_PAD_DRV_UP_REF(x) (((x) & 0x7) << 8)
+
+#define MIPI_CAL_BIAS_PAD_VCLAMP(x)(((x) & 0x7) << 16)
+#define MIPI_CAL_BIAS_PAD_VAUXP(x) (((x) & 0x7) << 4)
+#define MIPI_CAL_BIAS_PAD_PDVREG   BIT(1)
+
+struct tegra_mipi_priv {
+   struct mipi_ctlr*mipi;
+   struct clk  *mipi_cal;
+};
+
+static int tegra_mipi_calibrate(struct udevice *dev, int offset, const void 
*buf,
+   int size)
+{
+   struct tegra_mipi_priv *priv = dev_get_priv(dev);
+   u32 value;
+
+   value = MIPI_CAL_BIAS_PAD_DRV_DN_REF(0x2) |
+   MIPI_CAL_BIAS_PAD_DRV_UP_REF(0x0);
+   writel(value, >mipi->mipi_cal_bias_pad_cfg1);
+
+   value = readl(>mipi->mipi_cal_bias_pad_cfg2);
+   value &= ~MIPI_CAL_BIAS_PAD_VCLAMP(0x7);
+   value &= ~MIPI_CAL_BIAS_PAD_VAUXP(0x7);
+   writel(value, >mipi->mipi_cal_bias_pad_cfg2);
+
+   value = MIPI_CAL_OVERIDE(0x0) | MIPI_CAL_SEL(0x1) |
+   MIPI_CAL_HSPDOS(0x0) | MIPI_CAL_HSPUOS(0x4) |
+   MIPI_CAL_TERMOS(0x5);
+   writel(value, >mipi->mipi_cal_config_dsia);
+   writel(value, >mipi->mipi_cal_config_dsib);
+
+   /* Deselect PAD C */
+   value = readl(>mipi->mipi_cal_config_dsic);
+   value &= ~(MIPI_CAL_SEL(0x1));
+   writel(value, >mipi->mipi_cal_config_dsic);
+
+   /* Deselect PAD D */
+   value = readl(>mipi->mipi_cal_config_dsid);
+   value &= ~(MIPI_CAL_SEL(0x1));
+   writel(value, >mipi->mipi_cal_config_dsid);
+
+   value = readl(>mipi->mipi_cal_ctrl);
+   value &= ~MIPI_CAL_CTRL_NOISE_FILTER(0xf);
+   value &= ~MIPI_CAL_CTRL_PRESCALE(0x3);
+   value |= MIPI_CAL_CTRL_NOISE_FILTER(0xa) |
+MIPI_CAL_CTRL_PRESCALE(0x2) |
+MIPI_CAL_CTRL_CLKEN_OVR;
+   writel(value, >mipi->mipi_cal_ctrl);
+
+   /* clear any pending status bits */
+   value = readl(>mipi->mipi_cal_status);
+   writel(value, >mipi->mipi_cal_status);
+
+   value = readl(>mipi->mipi_cal_ctrl);
+   value |= MIPI_CAL_CTRL_START;
+   writel(value, >mipi->mipi_cal_ctrl);
+
+   /*
+* Wait for min 72uS to let calibration logic finish 

[PATCH v3 07/10] video: tegra20: dc: add powergate

2024-01-09 Thread Svyatoslav Ryhel
Add powergate use on T114 to complete resetting of DC.

Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 35abb6fe46..9a18e38cd8 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "tegra-dc.h"
@@ -32,6 +33,7 @@ DECLARE_GLOBAL_DATA_PTR;
 struct tegra_dc_soc_info {
bool has_timer;
bool has_rgb;
+   bool has_pgate;
 };
 
 /* Information about the display controller */
@@ -360,6 +362,28 @@ static int tegra_lcd_probe(struct udevice *dev)
 
clock_disable(priv->dc_clk[0]);
 
+   if (priv->soc->has_pgate) {
+   uint powergate;
+
+   if (priv->pipe)
+   powergate = TEGRA_POWERGATE_DISB;
+   else
+   powergate = TEGRA_POWERGATE_DIS;
+
+   ret = tegra_powergate_power_off(powergate);
+   if (ret < 0) {
+   log_err("failed to power off DISP gate: %d", ret);
+   return ret;
+   }
+
+   ret = tegra_powergate_sequence_power_up(powergate,
+   priv->dc_clk[0]);
+   if (ret < 0) {
+   log_err("failed to power up DISP gate: %d", ret);
+   return ret;
+   }
+   }
+
/* Reset everything set before */
reset_assert(_ctl);
mdelay(4);
@@ -510,16 +534,19 @@ static const struct video_ops tegra_lcd_ops = {
 static const struct tegra_dc_soc_info tegra20_dc_soc_info = {
.has_timer = true,
.has_rgb = true,
+   .has_pgate = false,
 };
 
 static const struct tegra_dc_soc_info tegra30_dc_soc_info = {
.has_timer = false,
.has_rgb = true,
+   .has_pgate = false,
 };
 
 static const struct tegra_dc_soc_info tegra114_dc_soc_info = {
.has_timer = false,
.has_rgb = false,
+   .has_pgate = true,
 };
 
 static const struct udevice_id tegra_lcd_ids[] = {
-- 
2.40.1



[PATCH v3 06/10] video: tegra20: dc: add reset support

2024-01-09 Thread Svyatoslav Ryhel
Implement reset use to discard any changes which could have been
applied to DC before and can interfere with current configuration.

Tested-by: Agneli  # Toshiba AC100 T20
Tested-by: Robert Eckelmann  # ASUS TF101
Tested-by: Andreas Westman Dorcsak  # ASUS Grouper E1565
Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dc.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 56a23b3c97..35abb6fe46 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -10,7 +10,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -342,6 +344,7 @@ static int tegra_lcd_probe(struct udevice *dev)
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct tegra_lcd_priv *priv = dev_get_priv(dev);
+   struct reset_ctl reset_ctl;
int ret;
 
/* Initialize the Tegra display controller */
@@ -349,6 +352,20 @@ static int tegra_lcd_probe(struct udevice *dev)
funcmux_select(PERIPH_ID_DISP1, FUNCMUX_DEFAULT);
 #endif
 
+   ret = reset_get_by_name(dev, "dc", _ctl);
+   if (ret) {
+   log_err("reset_get_by_name() failed: %d\n", ret);
+   return ret;
+   }
+
+   clock_disable(priv->dc_clk[0]);
+
+   /* Reset everything set before */
+   reset_assert(_ctl);
+   mdelay(4);
+   reset_deassert(_ctl);
+   mdelay(4);
+
if (tegra_display_probe(priv, (void *)plat->base)) {
debug("%s: Failed to probe display driver\n", __func__);
return -1;
-- 
2.40.1



[PATCH v3 04/10] video: tegra20: dc: pass DC id to internal devices

2024-01-09 Thread Svyatoslav Ryhel
Tegra SoC has 2 independent display controllers called DC_A and
DC_B, they are handled differently by internal video devices like
DSI and HDMI controllers so it is important for last to know
which display controller is used to properly set up registers.
To achieve this, a pipe field was added to pdata to pass display
controller id to internal Tegra SoC devices.

Tested-by: Agneli  # Toshiba AC100 T20
Tested-by: Robert Eckelmann  # ASUS TF101
Tested-by: Andreas Westman Dorcsak  # ASUS Grouper E1565
Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dc.c | 6 ++
 drivers/video/tegra20/tegra-dc.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 5d8874f323..0e94e665ef 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -45,6 +45,7 @@ struct tegra_lcd_priv {
unsigned pixel_clock;   /* Pixel clock in Hz */
int dc_clk[2];  /* Contains clk and its parent */
bool rotation;  /* 180 degree panel turn */
+   bool pipe;  /* DC controller: 0 for A, 1 for B */
 };
 
 enum {
@@ -406,6 +407,9 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
 
priv->rotation = dev_read_bool(dev, "nvidia,180-rotation");
 
+   if (!strcmp(dev->name, TEGRA_DC_B))
+   priv->pipe = 1;
+
rgb = fdt_subnode_offset(blob, node, "rgb");
if (rgb < 0) {
debug("%s: Cannot find rgb subnode for '%s' (ret=%d)\n",
@@ -431,12 +435,14 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return ret;
}
 
+   /* Fill the platform data for internal devices */
if (!strcmp(priv->panel->name, TEGRA_DSI_A) ||
!strcmp(priv->panel->name, TEGRA_DSI_B)) {
struct tegra_dc_plat *dc_plat = dev_get_plat(priv->panel);
 
dc_plat->dev = dev;
dc_plat->dc = priv->dc;
+   dc_plat->pipe = priv->pipe;
}
 
ret = panel_get_display_timing(priv->panel, >timing);
diff --git a/drivers/video/tegra20/tegra-dc.h b/drivers/video/tegra20/tegra-dc.h
index 5c05221038..75fc0fa4de 100644
--- a/drivers/video/tegra20/tegra-dc.h
+++ b/drivers/video/tegra20/tegra-dc.h
@@ -14,12 +14,15 @@
 /* arch-tegra/dc exists only because T124 uses it */
 #include 
 
+#define TEGRA_DC_A "dc@5420"
+#define TEGRA_DC_B "dc@5424"
 #define TEGRA_DSI_A"dsi@5430"
 #define TEGRA_DSI_B"dsi@5440"
 
 struct tegra_dc_plat {
struct udevice *dev;/* Display controller device */
struct dc_ctlr *dc; /* Display controller regmap */
+   bool pipe;  /* DC number: 0 for A, 1 for B */
 };
 
 /* This holds information about a window which can be displayed */
-- 
2.40.1



[PATCH v3 05/10] video: tegra20: dc: add PLLD2 parent support

2024-01-09 Thread Svyatoslav Ryhel
T30+ SOC have second PLLD - PLLD2 which can be actively used by
DC and act as main DISP1/2 clock parent.

Tested-by: Agneli  # Toshiba AC100 T20
Tested-by: Robert Eckelmann  # ASUS TF101
Tested-by: Andreas Westman Dorcsak  # ASUS Grouper E1565
Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 0e94e665ef..56a23b3c97 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -304,6 +304,12 @@ static int tegra_display_probe(struct tegra_lcd_priv *priv,
if (priv->dc_clk[1] == CLOCK_ID_DISPLAY)
rate /= 2;
 
+#ifndef CONFIG_TEGRA20
+   /* PLLD2 obeys same rules as PLLD but it is present only on T30+ */
+   if (priv->dc_clk[1] == CLOCK_ID_DISPLAY2)
+   rate /= 2;
+#endif
+
/*
 * HOST1X is init by default at 150MHz with PLLC as parent
 */
-- 
2.40.1



[PATCH v3 03/10] video: tegra20: consolidate DC header

2024-01-09 Thread Svyatoslav Ryhel
Consolidate HD headers and place the result into video/tegra20
since it is used only by devices from this directory.

Tested-by: Agneli  # Toshiba AC100 T20
Tested-by: Robert Eckelmann  # ASUS TF101
Tested-by: Andreas Westman Dorcsak  # ASUS Grouper E1565
Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 arch/arm/include/asm/arch-tegra/dc.h |  8 
 arch/arm/include/asm/arch-tegra114/display.h | 28 -
 arch/arm/include/asm/arch-tegra20/display.h  | 28 -
 arch/arm/include/asm/arch-tegra30/display.h  | 28 -
 drivers/video/tegra20/tegra-dc.c |  3 +-
 drivers/video/tegra20/tegra-dc.h | 41 
 drivers/video/tegra20/tegra-dsi.c|  2 +-
 drivers/video/tegra20/tegra-pwm-backlight.c  |  3 +-
 8 files changed, 46 insertions(+), 95 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-tegra114/display.h
 delete mode 100644 arch/arm/include/asm/arch-tegra20/display.h
 delete mode 100644 arch/arm/include/asm/arch-tegra30/display.h
 create mode 100644 drivers/video/tegra20/tegra-dc.h

diff --git a/arch/arm/include/asm/arch-tegra/dc.h 
b/arch/arm/include/asm/arch-tegra/dc.h
index 7613d84f22..6444af2993 100644
--- a/arch/arm/include/asm/arch-tegra/dc.h
+++ b/arch/arm/include/asm/arch-tegra/dc.h
@@ -569,12 +569,4 @@ enum {
 #define DC_N_WINDOWS   5
 #define DC_REG_SAVE_SPACE  (DC_N_WINDOWS + 5)
 
-#define TEGRA_DSI_A"dsi@5430"
-#define TEGRA_DSI_B"dsi@5440"
-
-struct tegra_dc_plat {
-   struct udevice *dev;/* Display controller device */
-   struct dc_ctlr *dc; /* Display controller regmap */
-};
-
 #endif /* __ASM_ARCH_TEGRA_DC_H */
diff --git a/arch/arm/include/asm/arch-tegra114/display.h 
b/arch/arm/include/asm/arch-tegra114/display.h
deleted file mode 100644
index 9411525799..00
--- a/arch/arm/include/asm/arch-tegra114/display.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- *  (C) Copyright 2010
- *  NVIDIA Corporation 
- */
-
-#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
-#define __ASM_ARCH_TEGRA_DISPLAY_H
-
-#include 
-
-/* This holds information about a window which can be displayed */
-struct disp_ctl_win {
-   enum win_color_depth_id fmt;/* Color depth/format */
-   unsigned intbpp;/* Bits per pixel */
-   phys_addr_t phys_addr;  /* Physical address in memory */
-   unsigned intx;  /* Horizontal address offset (bytes) */
-   unsigned inty;  /* Veritical address offset (bytes) */
-   unsigned intw;  /* Width of source window */
-   unsigned inth;  /* Height of source window */
-   unsigned intstride; /* Number of bytes per line */
-   unsigned intout_x;  /* Left edge of output window (col) */
-   unsigned intout_y;  /* Top edge of output window (row) */
-   unsigned intout_w;  /* Width of output window in pixels */
-   unsigned intout_h;  /* Height of output window in pixels */
-};
-
-#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
diff --git a/arch/arm/include/asm/arch-tegra20/display.h 
b/arch/arm/include/asm/arch-tegra20/display.h
deleted file mode 100644
index e7b3cffd46..00
--- a/arch/arm/include/asm/arch-tegra20/display.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- *  (C) Copyright 2010
- *  NVIDIA Corporation 
- */
-
-#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
-#define __ASM_ARCH_TEGRA_DISPLAY_H
-
-#include 
-
-/* This holds information about a window which can be displayed */
-struct disp_ctl_win {
-   enum win_color_depth_id fmt;/* Color depth/format */
-   unsignedbpp;/* Bits per pixel */
-   phys_addr_t phys_addr;  /* Physical address in memory */
-   unsignedx;  /* Horizontal address offset (bytes) */
-   unsignedy;  /* Veritical address offset (bytes) */
-   unsignedw;  /* Width of source window */
-   unsignedh;  /* Height of source window */
-   unsignedstride; /* Number of bytes per line */
-   unsignedout_x;  /* Left edge of output window (col) */
-   unsignedout_y;  /* Top edge of output window (row) */
-   unsignedout_w;  /* Width of output window in pixels */
-   unsignedout_h;  /* Height of output window in pixels */
-};
-
-#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
diff --git a/arch/arm/include/asm/arch-tegra30/display.h 
b/arch/arm/include/asm/arch-tegra30/display.h
deleted file mode 100644
index 9411525799..00
--- a/arch/arm/include/asm/arch-tegra30/display.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * 

[PATCH v3 01/10] video: tegra20: dc: diverge DC per-SOC

2024-01-09 Thread Svyatoslav Ryhel
Diverge DC driver setup to better fit each of supported generations
of Tegra SOC.

Tested-by: Agneli  # Toshiba AC100 T20
Tested-by: Robert Eckelmann  # ASUS TF101
Tested-by: Andreas Westman Dorcsak  # ASUS Grouper E1565
Tested-by: Ion Agorria  # HTC One X
Tested-by: Svyatoslav Ryhel  # Nvidia Tegratab T114
Signed-off-by: Svyatoslav Ryhel 
---
 arch/arm/dts/tegra114-u-boot.dtsi|  13 +++
 arch/arm/dts/tegra114.dtsi   |   4 +-
 arch/arm/dts/tegra30-u-boot.dtsi |   4 +
 arch/arm/dts/tegra30.dtsi|   2 +-
 arch/arm/include/asm/arch-tegra114/display.h |  28 +
 arch/arm/include/asm/arch-tegra114/pwm.h |  13 +++
 drivers/video/tegra20/tegra-dc.c | 107 +--
 7 files changed, 133 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra114/display.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pwm.h

diff --git a/arch/arm/dts/tegra114-u-boot.dtsi 
b/arch/arm/dts/tegra114-u-boot.dtsi
index 7c11972552..6a02714a25 100644
--- a/arch/arm/dts/tegra114-u-boot.dtsi
+++ b/arch/arm/dts/tegra114-u-boot.dtsi
@@ -1,3 +1,16 @@
 #include 
 
 #include "tegra-u-boot.dtsi"
+
+/ {
+   host1x@5000 {
+   bootph-all;
+   dc@5420 {
+   bootph-all;
+   };
+
+   dc@5424 {
+   bootph-all;
+   };
+   };
+};
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index 68ee7f3165..250d692f6b 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -42,7 +42,7 @@
};
 
dc@5420 {
-   compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
+   compatible = "nvidia,tegra114-dc";
reg = <0x5420 0x0004>;
interrupts = ;
clocks = <_car TEGRA114_CLK_DISP1>,
@@ -61,7 +61,7 @@
};
 
dc@5424 {
-   compatible = "nvidia,tegra114-dc", "nvidia,tegra20-dc";
+   compatible = "nvidia,tegra114-dc";
reg = <0x5424 0x0004>;
interrupts = ;
clocks = <_car TEGRA114_CLK_DISP2>,
diff --git a/arch/arm/dts/tegra30-u-boot.dtsi b/arch/arm/dts/tegra30-u-boot.dtsi
index 3038227dbe..6a02714a25 100644
--- a/arch/arm/dts/tegra30-u-boot.dtsi
+++ b/arch/arm/dts/tegra30-u-boot.dtsi
@@ -8,5 +8,9 @@
dc@5420 {
bootph-all;
};
+
+   dc@5424 {
+   bootph-all;
+   };
};
 };
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index f198bc0edb..1177e2ab1f 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -158,7 +158,7 @@
};
 
dc@5420 {
-   compatible = "nvidia,tegra30-dc", "nvidia,tegra20-dc";
+   compatible = "nvidia,tegra30-dc";
reg = <0x5420 0x0004>;
interrupts = ;
clocks = <_car TEGRA30_CLK_DISP1>,
diff --git a/arch/arm/include/asm/arch-tegra114/display.h 
b/arch/arm/include/asm/arch-tegra114/display.h
new file mode 100644
index 00..9411525799
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra114/display.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ *  (C) Copyright 2010
+ *  NVIDIA Corporation 
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
+#define __ASM_ARCH_TEGRA_DISPLAY_H
+
+#include 
+
+/* This holds information about a window which can be displayed */
+struct disp_ctl_win {
+   enum win_color_depth_id fmt;/* Color depth/format */
+   unsigned intbpp;/* Bits per pixel */
+   phys_addr_t phys_addr;  /* Physical address in memory */
+   unsigned intx;  /* Horizontal address offset (bytes) */
+   unsigned inty;  /* Veritical address offset (bytes) */
+   unsigned intw;  /* Width of source window */
+   unsigned inth;  /* Height of source window */
+   unsigned intstride; /* Number of bytes per line */
+   unsigned intout_x;  /* Left edge of output window (col) */
+   unsigned intout_y;  /* Top edge of output window (row) */
+   unsigned intout_w;  /* Width of output window in pixels */
+   unsigned intout_h;  /* Height of output window in pixels */
+};
+
+#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
diff --git a/arch/arm/include/asm/arch-tegra114/pwm.h 
b/arch/arm/include/asm/arch-tegra114/pwm.h
new file mode 100644
index 00..af39151803
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra114/pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Tegra pulse 

[PATCH v3 02/10] video: tegra20: dc: fix image shift on rotated panels

2024-01-09 Thread Svyatoslav Ryhel
Subtracting 1 from x and y fixes image shifting on rotated
panels.

Tested-by: Robert Eckelmann  # ASUS Grouper E1565
Signed-off-by: Svyatoslav Ryhel 
---
 drivers/video/tegra20/tegra-dc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 7605e77bc1..bcc2748623 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -242,8 +242,8 @@ static int setup_window(struct tegra_lcd_priv *priv,
struct disp_ctl_win *win)
 {
if (priv->rotation) {
-   win->x = priv->width * 2;
-   win->y = priv->height;
+   win->x = priv->width * 2 - 1;
+   win->y = priv->height - 1;
} else {
win->x = 0;
win->y = 0;
-- 
2.40.1



[PATCH v3 00/10] Add T114 video support

2024-01-09 Thread Svyatoslav Ryhel
T114 is not that different from T30 and all T30 drivers will work
on T114 as well with some adjustments.

Patches propose general improvements for existing Tegra DC and DSI
drivers as well Tegra 114 video support (experimentl).

Commits pass buildman for tegra.

---
Changes from v2:
 - fixed image distortion on devices with 180deg rotation

Changes from v1:
 - reworked patchset entirely
 - diverged DC configuration per-SOC
 - consolidated dc headers from different SOC gen
 - initial support of DC detection (tegra has 2 DC)
 - added PLLD2 support, resets and powergating
 - added T114+ MIPI calibration
 - added DSI detection (tegra has 2 DSI) and resets
---

Svyatoslav Ryhel (10):
  video: tegra20: dc: diverge DC per-SOC
  video: tegra20: dc: fix image shift on rotated panels
  video: tegra20: consolidate DC header
  video: tegra20: dc: pass DC id to internal devices
  video: tegra20: dc: add PLLD2 parent support
  video: tegra20: dc: add reset support
  video: tegra20: dc: add powergate
  video: tegra20: add MIPI calibration driver
  video: tegra20: dsi: add T114 support
  video: tegra20: dsi: add reset support

 arch/arm/dts/tegra114-u-boot.dtsi |  13 ++
 arch/arm/dts/tegra114.dtsi|   4 +-
 arch/arm/dts/tegra30-u-boot.dtsi  |   4 +
 arch/arm/dts/tegra30.dtsi |   2 +-
 arch/arm/include/asm/arch-tegra/dc.h  |   8 -
 arch/arm/include/asm/arch-tegra114/pwm.h  |  13 ++
 arch/arm/include/asm/arch-tegra20/display.h   |  28 ---
 arch/arm/include/asm/arch-tegra30/display.h   |  28 ---
 drivers/video/tegra20/Makefile|   2 +-
 drivers/video/tegra20/tegra-dc.c  | 170 
 drivers/video/tegra20/tegra-dc.h  |  44 
 drivers/video/tegra20/tegra-dsi.c |  94 -
 .../video/tegra20/tegra-dsi.h |  24 ++-
 drivers/video/tegra20/tegra-mipi.c| 188 ++
 drivers/video/tegra20/tegra-pwm-backlight.c   |   3 +-
 15 files changed, 511 insertions(+), 114 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra114/pwm.h
 delete mode 100644 arch/arm/include/asm/arch-tegra20/display.h
 delete mode 100644 arch/arm/include/asm/arch-tegra30/display.h
 create mode 100644 drivers/video/tegra20/tegra-dc.h
 rename arch/arm/include/asm/arch-tegra30/dsi.h => 
drivers/video/tegra20/tegra-dsi.h (90%)
 create mode 100644 drivers/video/tegra20/tegra-mipi.c

-- 
2.40.1



RE: [PATCH] arm: socfpga: stratix10: SPI clock support

2024-01-09 Thread Chee, Tien Fong
Hi,

> -Original Message-
> From: Maniyam, Dinesh 
> Sent: Thursday, December 7, 2023 3:46 PM
> To: u-boot@lists.denx.de
> Cc: Marek ; Simon ;
> Chee, Tien Fong ; Hea, Kok Kiang
> ; Maniyam, Dinesh ;
> Ng, Boon Khai ; Yuslaimi, Alif Zakuan
> ; Chong, Teik Heng
> ; Zamri, Muhammad Hazim Izzat
> ; Lim, Jit Loon
> ; Tang, Sieu Mun 
> Subject: [PATCH] arm: socfpga: stratix10: SPI clock support
> 
> From: Dinesh Maniyam 
> 
> This patch is to add SPI clock support for stratix10. Get clock rate function
> always returning 0 because the DW-SPI driver get the rate from clock node in
> dts but Stratix10 does not support device tree clock node.To overcome this spi
> will get the clock_rate directly from spi clock controller override the weaker
> function.
> 
> Signed-off-by: Dinesh Maniyam 
> ---
>  arch/arm/mach-socfpga/clock_manager_s10.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c b/arch/arm/mach-
> socfpga/clock_manager_s10.c
> index 4b4f0749db..45300336d5 100644
> --- a/arch/arm/mach-socfpga/clock_manager_s10.c
> +++ b/arch/arm/mach-socfpga/clock_manager_s10.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2016-2018 Intel Corporation 
> + * Copyright (C) 2016-2023 Intel Corporation 
>   *
>   */
> 
> @@ -399,6 +399,21 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
>   return cm_get_l3_main_clk_hz() / 4;
>  }
> 
> +/*
> + * Override weak dw_spi_get_clk implementation in designware_spi.c
> +driver  */
> +
> +int dw_spi_get_clk(struct udevice *bus, ulong *rate) {
> + *rate = cm_get_spi_controller_clk_hz();
> + if (!*rate) {
> + printf("SPI: clock rate is zero");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  void cm_print_clock_quick_summary(void)
>  {
>   printf("MPU %d kHz\n", (u32)(cm_get_mpu_clk_hz() / 1000));
> --
> 2.26.2

Reviewed-by: Tien Fong Chee 

Regards
Tien Fong



Re: [RFC PATCH 12/16] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration

2024-01-09 Thread MD Danish Anwar
Hi Roger,

On 27/12/23 3:49 pm, MD Danish Anwar wrote:
> On 20/12/23 4:10 pm, Roger Quadros wrote:
>>
>>
>> On 19/12/2023 12:34, MD Danish Anwar wrote:
>>> Add ICSSG2 overlay and configuration to tispl and u-boot images.
>>>
>>> Signed-off-by: MD Danish Anwar 
>>> ---
>>>  arch/arm/dts/k3-am65x-binman.dtsi | 85 +++
>>>  1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/k3-am65x-binman.dtsi 
>>> b/arch/arm/dts/k3-am65x-binman.dtsi
>>> index 8cc24da1f3..9a0c0fca47 100644
>>> --- a/arch/arm/dts/k3-am65x-binman.dtsi
>>> +++ b/arch/arm/dts/k3-am65x-binman.dtsi
>>> @@ -98,6 +98,8 @@
>>>  #define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
>>>  #define AM654_EVM_DTB "u-boot.dtb"
>>>  
>>> +#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
>>> +
>>>   {
>>> ti-spl {
>>> insert-template = <_spl_template>;
>>> @@ -124,6 +126,20 @@
>>> filename = SPL_AM654_EVM_DTB;
>>> };
>>> };
>>> +
>>> +   fdt-1 {
>>> +   description = "k3-am654-icssg2 overlay";
>>> +   type = "flat_dt";
>>> +   arch = "arm";
>>> +   compression = "none";
>>> +   ti-secure {
>>> +   content = 
>>> <_am65x_evm_icssg2_dtb>;
>>> +   keyfile = "custMpk.pem";
>>> +   };
>>> +   spl_am65x_evm_icssg2_dtb: blob-ext {
>>> +   filename = 
>>> AM654_EVM_ICSSG2_DTBO;
>>> +   };
>>
>> This is wrong.
>>
>> ICSSG2 Ethernet should be part of the fdt-0 configuration as the 2 Ethernet 
>> ports
>> on the board are hardwired to ICSSG2. Not having them working by default
>> is an invalid configuration.
>>
> 
> ICSSG2 ethernet ports should be enabled by default. But the ICSSG2 nodes
> is added in the overlay file (k3-am654-icssg2.dtso) in kernel so they
> are added in same overlay file in u-boot as well.
> 
> I am keeping,
> fdt-0  as k3-am654-base-board dtb,
> fdt-1  as k3-am654-icssg2 dtbo,
> conf-0 as k3-am654-base-board and
> conf-1 as k3-am654-icssg2.
> 
> Do you want me to keep k3-am654-icssg2 dtbo as fdt-0 and
> k3-am654-base-board as fdt-1? I tried doing this but this results into
> u-boot getting stuck. The tispl and u-boot images are not able to load
> if I swap fdt-0 and fdt-1 , and conf-0 and conf-1.
> 
> If the current combination doesn't look OK, please let me know what
> should be the correct combinations for fdt-0, fdt-1, conf-0 and conf-1.
> 

Can you please comment on this. I'll send v2 with all the suggested
changes once you confirm the correct fdt and configurations.



-- 
Thanks and Regards,
Danish


[PATCH v2 RESEND 2/2] nvme: Update nvme_scan_namespace to keep trying on busy

2024-01-09 Thread Moritz Fischer
A busy controller shouldn't be game-over for all controllers,
so keep trying on hitting -EBUSY.

This change brings the actual behavior of the routine in line
with what the descriptions says.

Fixes: 982388eaa991 ("nvme: Add NVM Express driver support")
Reviewed-by: Simon Glass 
Signed-off-by: Moritz Fischer 
---
 drivers/nvme/nvme.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index ec45f831a3..59a139baa0 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -695,7 +695,9 @@ int nvme_scan_namespace(void)
if (ret) {
log_err("Failed to probe '%s': err=%dE\n", dev->name,
ret);
-   return ret;
+   /* Bail if we ran out of memory, else keep trying */
+   if (ret != -EBUSY)
+   return ret;
}
}
 
-- 
2.43.0.472.g3155946c3a-goog



[PATCH v2 RESEND 1/2] nvme: Fix error code and log to indicate busy

2024-01-09 Thread Moritz Fischer
Return -EBUSY if controller is found busy rather than -ENOMEM
and update the error message accordingly.

Fixes: 982388eaa991 ("nvme: Add NVM Express driver support")
Reviewed-by: Simon Glass 
Signed-off-by: Moritz Fischer 
---
 drivers/nvme/nvme.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index c39cd41aa3..ec45f831a3 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -835,8 +835,8 @@ int nvme_init(struct udevice *udev)
ndev->udev = udev;
INIT_LIST_HEAD(>namespaces);
if (readl(>bar->csts) == -1) {
-   ret = -ENODEV;
-   printf("Error: %s: Out of memory!\n", udev->name);
+   ret = -EBUSY;
+   printf("Error: %s: Controller not ready!\n", udev->name);
goto free_nvme;
}
 
-- 
2.43.0.472.g3155946c3a-goog



[PATCH v4] drivers: pci: Fix dm_pci_map_bar() to support 64b BARs

2024-01-09 Thread Moritz Fischer
This enables 64b BARs if CONFIG_SYS_PCI_64BIT is enabled.

Reviewed-by: Philip Oberfichtner 
Reviewed-by: Simon Glass 
Signed-off-by: Moritz Fischer 
---

Changes from V3:
- Rebased onto v2024.01

Changes from V2:

- Turned IS_ENABLED() into #if defined to allow
  building on platforms that don't define
  CONFIG_SYS_PCI_64BIT

Changes from V1:

- Reworded commit message / typo

---
 drivers/pci/pci-uclass.c | 11 +++
 include/pci.h|  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index e0d01f6a85..1a48256de0 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1611,6 +1611,17 @@ void *dm_pci_map_bar(struct udevice *dev, int bar, 
size_t offset, size_t len,
dm_pci_read_config32(udev, bar, _response);
pci_bus_addr = (pci_addr_t)(bar_response & ~0xf);
 
+   /* This has a lot of baked in assumptions, but essentially tries
+* to mirror the behavior of BAR assignment for 64 Bit enabled
+* hosts and 64 bit placeable BARs in the auto assign code.
+*/
+#if defined(CONFIG_SYS_PCI_64BIT)
+   if (bar_response & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+   dm_pci_read_config32(udev, bar + 4, _response);
+   pci_bus_addr |= (pci_addr_t)bar_response << 32;
+   }
+#endif /* CONFIG_SYS_PCI_64BIT */
+
if (~((pci_addr_t)0) - pci_bus_addr < offset)
return NULL;
 
diff --git a/include/pci.h b/include/pci.h
index 2f5eb30b83..aad233769a 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -1354,6 +1354,7 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev, 
phys_addr_t addr, size_t len,
  * type 1 functions.
  * Can also be used on type 0 functions that support Enhanced Allocation for
  * 32b/64b BARs.  Note that duplicate BEI entries are not supported.
+ * Can also be used on 64b bars on type 0 functions.
  *
  * @dev:   Device to check
  * @bar:   Bar register offset (PCI_BASE_ADDRESS_...)
-- 
2.43.0.472.g3155946c3a-goog



Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-09 Thread Chen-Yu Tsai
On Tue, Jan 9, 2024 at 9:47 PM Masahiro Yamada  wrote:
>
> On Fri, Dec 29, 2023 at 3:39 PM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > > wrote:
> > > >
> > > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Laurent,
> > > > > >
> > > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > > >  wrote:
> > > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > > >  wrote:
> > > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > > single file
> > > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > > files.
> > > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > > of size and
> > > > > > > > > > > > performance.
> > > > > > > > > > > >
> > > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > > approach.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be used by bootloaders which support it, 
> > > > > > > > > > > > such as U-Boot
> > > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > > correct
> > > > > > > > > > > > devicetree, matching the compatible string of the 
> > > > > > > > > > > > running board with
> > > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > > need for
> > > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > > >
> > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > > Use
> > > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > > >
> > > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > > used. Supported
> > > > > > > > > > > > compression options are the same as the Image.xxx 
> > > > > > > > > > > > files. For now there
> > > > > > > > > > > > is no way to change the compression other than by 
> > > > > > > > > > > > editing the rule for
> > > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > > >
> > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is 
> > > > > > > > > > > > made to support
> > > > > > > > > > > > this here, since it must be built separately from the 
> > > > > > > > > > > > Linux build.
> > > > > > > > > > >
> > > > > > > > > > > FIT images are very useful, so I think this is a very 
> > > > > > > > > > > welcome addition
> > > > > > > > > > > to the kernel build system. It can get tricky though: 
> > > > > > > > > > > given the
> > > > > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > > > > one-size-fits-them-all solution to build them, and 
> > > > > > > > > > > striking the right
> > > > > > > > > > > balance between what makes sense for the kernel and the 
> > > > > > > > > > > features that
> > > > > > > > > > > users may request will probably lead to bikeshedding. As 
> > > > > > > > > > > we all love
> > > > > > > > > > > bikeshedding, I thought I would start selfishly, with a 
> > > > > > > > > > > personal use
> > > > > > > > > > > case :-) This isn't a yak-shaving request though, I don't 
> > > > > > > > > > > see any reason
> > > > > > > > > > > to delay merging this series.
> > > > > > > > > > >
> > > > > > > > > > > Have you envisioned building FIT images with a subset of 
> > > > > > > > > > > DTBs, or adding
> > > > > > > > > > > DTBOs ? Both would be fairly trivial extensions to this 
> > > > > > > > > > > script by
> > > > > > > > > > > extending the supported command line arguments. It would 
> > > > > > > > > > > perhaps be more
> > > > > > > > > > > difficult to integrate in the kernel build system though. 
> > > > > > > > > > > This leads me
> > > > > > > > > > > to a second question: would you consider merging 
> > > > > > > > > > > extensions to this
> > > > > > > > > > > script if they are not used by the kernel build system, 
> > > > > > > > > > > but meant for
> > > > > > > > > > > users who manually invoke the script ? More generally, is 
> > > > > > > > > > > the script
> > > > > > > > > >
> > > > > > > > > > We'd 

[RESEND PATCH v2] board: rockchip: Add the Turing RK1 SoM

2024-01-09 Thread Joshua Riek
The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.

Specifications:

Rockchip RK3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16/32GB memory LPDDR4x
Mali G610MC4 GPU
32GB eMMC HS400
2x USB 2.0, 2x USB 3.0
2x MIPI CSI 4x lanes
1x MIPI-DSI DPHY 2x lanes
PCIe 2.0 x1, PCIe 3.0 x4
1x HDMI 2.1 output, 1x DP 1.4 output
Gigabit Ethernet
Size: 69.6mm x 45mm (260-pin SO-DIMM connector)

Kernel commit:
2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")

Signed-off-by: Joshua Riek 
Tested-by: Sam Edwards 
Reviewed-by: Kever Yang 
---
Changes in v2:
- removed BOOT_TARGET #ifdef ... #endif in the RK1 header file
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi|  25 +
 arch/arm/dts/rk3588-turing-rk1.dts|  21 +
 arch/arm/dts/rk3588-turing-rk1.dtsi   | 614 ++
 arch/arm/mach-rockchip/rk3588/Kconfig |  24 +
 board/turing/turing-rk1-rk3588/Kconfig|  15 +
 board/turing/turing-rk1-rk3588/MAINTAINERS|   9 +
 board/turing/turing-rk1-rk3588/Makefile   |   6 +
 .../turing-rk1-rk3588/turing-rk1-rk3588.c |  39 ++
 configs/turing-rk1-rk3588_defconfig   | 133 
 doc/board/rockchip/rockchip.rst   |   1 +
 include/configs/turing-rk1-rk3588.h   |  15 +
 12 files changed, 903 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-turing-rk1.dts
 create mode 100644 arch/arm/dts/rk3588-turing-rk1.dtsi
 create mode 100644 board/turing/turing-rk1-rk3588/Kconfig
 create mode 100644 board/turing/turing-rk1-rk3588/MAINTAINERS
 create mode 100644 board/turing/turing-rk1-rk3588/Makefile
 create mode 100644 board/turing/turing-rk1-rk3588/turing-rk1-rk3588.c
 create mode 100644 configs/turing-rk1-rk3588_defconfig
 create mode 100644 include/configs/turing-rk1-rk3588.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc..97355d84de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -195,6 +195,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588s-orangepi-5.dtb \
rk3588-orangepi-5-plus.dtb \
rk3588-quartzpro64.dtb \
+   rk3588-turing-rk1.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi 
b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
new file mode 100644
index 00..06c6f327c1
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Joshua Riek 
+ *
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+};
+
+ {
+   bootph-pre-ram;
+   clock-frequency = <2400>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-turing-rk1.dts 
b/arch/arm/dts/rk3588-turing-rk1.dts
new file mode 100644
index 00..7bcad28d73
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * This device tree covers the common case where the RK1 is used as a
+ * "compute node" system, where the carrier board is functioning more like a
+ * generic backplane (with no non-autoenumerable peripherals of its own) than
+ * like a device that the SoM is meant to enable.
+ *
+ * Copyright (c) 2023 Sam Edwards 
+ */
+
+/dts-v1/;
+#include "rk3588-turing-rk1.dtsi"
+
+/ {
+   model = "Turing Machines RK1";
+   compatible = "turing,rk1", "rockchip,rk3588";
+
+   chosen {
+   stdout-path = "serial9:115200n8";
+   };
+};
diff --git a/arch/arm/dts/rk3588-turing-rk1.dtsi 
b/arch/arm/dts/rk3588-turing-rk1.dtsi
new file mode 100644
index 00..9570b34aca
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1.dtsi
@@ -0,0 +1,614 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions for the Turing RK1 SoM.
+ *
+ * Copyright (c) 2023 Sam Edwards 
+ *
+ * Based on RK3588-EVB1 devicetree
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   compatible = "turing,rk1", "rockchip,rk3588";
+
+   aliases {
+   ethernet0 = 
+   mmc0 = 
+   serial2 = 
+   serial9 = 
+   };
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 25 95 145 195 255>;
+   fan-supply = <_sys>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins _int>;
+   interrupt-parent = <>;
+   interrupts = ;
+   pwms = < 0 5 0>;
+   #cooling-cells = <2>;
+   };
+
+   vcc3v3_pcie30: vcc3v3-pcie30-regulator {
+   compatible = 

[PATCH v4 4/4] fs: remove explicit efi configuration dependency

2024-01-09 Thread AKASHI Takahiro
Now it is clear that the feature actually depends on efi interfaces,
not "bootefi" command. efi_set_bootdev() will automatically be nullified
if necessary efi component is disabled.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Simon Glass 
---
 fs/fs.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index f1a0b70d1d57..acf465bdd807 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -791,10 +791,9 @@ int do_load(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[],
return 1;
}
 
-   if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
-   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
-   (argc > 4) ? argv[4] : "", map_sysmem(addr, 0),
-   len_read);
+   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
+   (argc > 4) ? argv[4] : "", map_sysmem(addr, 0),
+   len_read);
 
printf("%llu bytes read in %lu ms", len_read, time);
if (time > 0) {
-- 
2.34.1



[PATCH v4 3/4] net: tftp: remove explicit efi configuration dependency

2024-01-09 Thread AKASHI Takahiro
Now it is clear that the feature actually depends on efi interfaces,
not "bootefi" command. efi_set_bootdev() will automatically be nullified
if necessary efi component is disabled.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Ramon Fried 
Reviewed-by: Tom Rini 
---
 net/tftp.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index 88e71e67de35..2e335413492b 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -302,12 +302,10 @@ static void tftp_complete(void)
time_start * 1000, "/s");
}
puts("\ndone\n");
-   if (IS_ENABLED(CONFIG_CMD_BOOTEFI)) {
-   if (!tftp_put_active)
-   efi_set_bootdev("Net", "", tftp_filename,
-   map_sysmem(tftp_load_addr, 0),
-   net_boot_file_size);
-   }
+   if (!tftp_put_active)
+   efi_set_bootdev("Net", "", tftp_filename,
+   map_sysmem(tftp_load_addr, 0),
+   net_boot_file_size);
net_set_state(NETLOOP_SUCCESS);
 }
 
-- 
2.34.1



[PATCH v4 2/4] efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR

2024-01-09 Thread AKASHI Takahiro
At this point, EFI boot manager interfaces is fully independent from
bootefi command. So just rename the configuration parameter.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Simon Glass 
---
 boot/Makefile   | 2 +-
 cmd/Kconfig | 4 ++--
 cmd/efidebug.c  | 4 ++--
 lib/efi_loader/Kconfig  | 2 +-
 lib/efi_loader/Makefile | 2 +-
 test/boot/bootflow.c| 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/boot/Makefile b/boot/Makefile
index a90ebea5a867..bcd01cfc890c 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -34,7 +34,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootm.o bootm_os.o 
bootmeth_cros.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
 ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
-obj-$(CONFIG_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o
+obj-$(CONFIG_EFI_BOOTMGR) += bootmeth_efi_mgr.o
 obj-$(CONFIG_$(SPL_TPL_)EXPO) += bootflow_menu.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o
 obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 150fa37a50a7..62d2ae3d3f1b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -395,7 +395,7 @@ config CMD_BOOTEFI_BINARY
 
 config CMD_BOOTEFI_BOOTMGR
bool "UEFI Boot Manager command"
-   depends on BOOTEFI_BOOTMGR
+   depends on EFI_BOOTMGR
default y
help
  Select this option to enable the 'bootmgr' subcommand of 'bootefi'.
@@ -2153,7 +2153,7 @@ config CMD_EFIDEBUG
 config CMD_EFICONFIG
bool "eficonfig - provide menu-driven uefi variables maintenance 
interface"
default y if !HAS_BOARD_SIZE_LIMIT
-   depends on BOOTEFI_BOOTMGR
+   depends on EFI_BOOTMGR
select MENU
help
  Enable the 'eficonfig' command which provides the menu-driven UEFI
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index e10fbf891a42..b4954258eeba 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1410,7 +1410,7 @@ static __maybe_unused int do_efi_test_bootmgr(struct 
cmd_tbl *cmdtp, int flag,
 }
 
 static struct cmd_tbl cmd_efidebug_test_sub[] = {
-#ifdef CONFIG_BOOTEFI_BOOTMGR
+#ifdef CONFIG_EFI_BOOTMGR
U_BOOT_CMD_MKENT(bootmgr, CONFIG_SYS_MAXARGS, 1, do_efi_test_bootmgr,
 "", ""),
 #endif
@@ -1604,7 +1604,7 @@ U_BOOT_LONGHELP(efidebug,
"  - show UEFI memory map\n"
"efidebug tables\n"
"  - show UEFI configuration tables\n"
-#ifdef CONFIG_BOOTEFI_BOOTMGR
+#ifdef CONFIG_EFI_BOOTMGR
"efidebug test bootmgr\n"
"  - run simple bootmgr for test\n"
 #endif
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 64f2f1cdd161..db5571de1d95 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -41,7 +41,7 @@ config EFI_BINARY_EXEC
  You may enable CMD_BOOTEFI_BINARY so that you can use bootefi
  command to do that.
 
-config BOOTEFI_BOOTMGR
+config EFI_BOOTMGR
bool "UEFI Boot Manager"
default y
select BOOTMETH_GLOBAL if BOOTSTD
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f85d26d9724c..56e5ce220a3e 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -42,7 +42,7 @@ targets += initrddump.o
 endif
 
 obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
-obj-$(CONFIG_BOOTEFI_BOOTMGR) += efi_bootmgr.o
+obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o
 obj-$(CONFIG_EFI_BINARY_EXEC) += efi_bootbin.o
 obj-y += efi_boottime.o
 obj-y += efi_helper.o
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 104f49deef2a..fa54dde661c8 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -374,7 +374,7 @@ static int bootflow_system(struct unit_test_state *uts)
 {
struct udevice *bootstd, *dev;
 
-   if (!IS_ENABLED(CONFIG_BOOTEFI_BOOTMGR))
+   if (!IS_ENABLED(CONFIG_EFI_BOOTMGR))
return -EAGAIN;
ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
ut_assertok(device_bind(bootstd, DM_DRIVER_GET(bootmeth_efi_mgr),
-- 
2.34.1



[PATCH v4 1/4] efi_loader: split unrelated code from efi_bootmgr.c

2024-01-09 Thread AKASHI Takahiro
Some code moved from cmd/bootefi.c is actually necessary only for "bootefi
" command (starting an image manually loaded by a user using U-Boot
load commands or other methods (like JTAG debugger).

The code will never been opted out as unused code by a compiler which
doesn't know how EFI boot manager is implemented. So introduce a new
configuration, CONFIG_EFI_BINARY_EXEC, to enforce them opted out
explicitly.

Signed-off-by: AKASHI Takahiro 
---
v4
* moved binary execution portion of code (EFI_BINARY_EXEC) to
  a new file, efi_bootbin.c
---
 boot/Kconfig |   4 +-
 cmd/Kconfig  |   6 +-
 include/efi_loader.h |  28 +-
 lib/efi_loader/Kconfig   |   9 +
 lib/efi_loader/Makefile  |   1 +
 lib/efi_loader/efi_bootbin.c | 211 +
 lib/efi_loader/efi_bootmgr.c | 488 ---
 lib/efi_loader/efi_device_path.c |   3 +-
 lib/efi_loader/efi_helper.c  | 286 ++
 9 files changed, 531 insertions(+), 505 deletions(-)
 create mode 100644 lib/efi_loader/efi_bootbin.c

diff --git a/boot/Kconfig b/boot/Kconfig
index 9f5b8a0cb2c8..347f8cca7d0b 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -523,7 +523,7 @@ config BOOTMETH_EXTLINUX_PXE
 
 config BOOTMETH_EFILOADER
bool "Bootdev support for EFI boot"
-   depends on BOOTEFI_BOOTMGR
+   depends on EFI_BINARY_EXEC
default y
help
  Enables support for EFI boot using bootdevs. This makes the
@@ -558,7 +558,7 @@ config BOOTMETH_DISTRO
select BOOTMETH_SCRIPT if CMDLINE # E.g. Armbian uses scripts
select BOOTMETH_EXTLINUX  # E.g. Debian uses these
select BOOTMETH_EXTLINUX_PXE if CMD_PXE && CMD_NET && DM_ETH
-   select BOOTMETH_EFILOADER if BOOTEFI_BOOTMGR # E.g. Ubuntu uses this
+   select BOOTMETH_EFILOADER if EFI_BINARY_EXEC # E.g. Ubuntu uses this
 
 config SPL_BOOTMETH_VBE
bool "Bootdev support for Verified Boot for Embedded (SPL)"
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 26ad03b6..150fa37a50a7 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -294,7 +294,7 @@ config CMD_BOOTMETH
 
 config BOOTM_EFI
bool "Support booting UEFI FIT images"
-   depends on BOOTEFI_BOOTMGR && CMD_BOOTM && FIT
+   depends on EFI_BINARY_EXEC && CMD_BOOTM && FIT
default y
help
  Support booting UEFI FIT images via the bootm command.
@@ -386,7 +386,7 @@ config CMD_BOOTEFI
 if CMD_BOOTEFI
 config CMD_BOOTEFI_BINARY
bool "Allow booting an EFI binary directly"
-   depends on BOOTEFI_BOOTMGR
+   depends on EFI_BINARY_EXEC
default y
help
  Select this option to enable direct execution of binary at 'bootefi'.
@@ -416,7 +416,7 @@ config CMD_BOOTEFI_HELLO_COMPILE
 
 config CMD_BOOTEFI_HELLO
bool "Allow booting a standard EFI hello world for testing"
-   depends on CMD_BOOTEFI_HELLO_COMPILE
+   depends on CMD_BOOTEFI_BINARY && CMD_BOOTEFI_HELLO_COMPILE
default y if CMD_BOOTEFI_SELFTEST
help
  This adds a standard EFI hello world application to U-Boot so that
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 34e7fbbf1840..484c9fad239f 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -90,11 +90,7 @@ efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len);
  * back to u-boot world
  */
 void efi_restore_gd(void);
-/* Call this to unset the current device name */
-void efi_clear_bootdev(void);
-/* Call this to set the current device name */
-void efi_set_bootdev(const char *dev, const char *devnr, const char *path,
-void *buffer, size_t buffer_size);
+
 /* Called by networking code to memorize the dhcp ack package */
 void efi_net_set_dhcp_ack(void *pkt, int len);
 /* Print information about all loaded images */
@@ -116,10 +112,6 @@ static inline efi_status_t efi_add_runtime_mmio(void 
*mmio_ptr, u64 len)
 
 /* No loader configured, stub out EFI_ENTRY */
 static inline void efi_restore_gd(void) { }
-static inline void efi_clear_bootdev(void) { }
-static inline void efi_set_bootdev(const char *dev, const char *devnr,
-  const char *path, void *buffer,
-  size_t buffer_size) { }
 static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
 static inline void efi_print_image_infos(void *pc) { }
 static inline efi_status_t efi_launch_capsules(void)
@@ -129,6 +121,20 @@ static inline efi_status_t efi_launch_capsules(void)
 
 #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
 
+#if CONFIG_IS_ENABLED(EFI_BINARY_EXEC)
+/* Call this to unset the current device name */
+void efi_clear_bootdev(void);
+/* Call this to set the current device name */
+void efi_set_bootdev(const char *dev, const char *devnr, const char *path,
+void *buffer, size_t buffer_size);
+#else
+static inline void efi_clear_bootdev(void) { }
+
+static inline void efi_set_bootdev(const char *dev, const char 

[PATCH v4 0/4] cmd: bootefi: refactor the code for bootmgr

2024-01-09 Thread AKASHI Takahiro
This patch set is motivated by the discussion[1] regarding
CONFIG_BOOTEFI_BOOTMGR option.

# This version (v4) contains only the remaining commits.

At the end, bootefi.c will be decomposed into two parts, one for
providing the command itself and one for implementing helper functions.
EFI_LOADER will now be available without CONFIG_CMDLINE or specifically
CONFIG_CMD_BOOTEFI if invoked via bootmeth/bootstd.

Then, EFI_LOADER library side will be further split into two options
for fine-grain control:
CONFIG_EFI_BINARY_EXEC: execute UEFI binaries which are to be explicitly
loaded by U-Boot's load commands/functions or other methods
(like a jtag debugger?)
It supports bootmeth_efi as well as "bootefi |hello"(/"bootm"?).

CONFIG_EFI_BOOTMGR: provide EFI boot manger functionality
It supports bootmeth_efi_mgr as well as "bootefi bootmgr".

As such, We will no longer need CONFIG_EFI_BINARY_EXEC if we want to only
make use of the UEFI boot manger for booting a next stage OS.

Prerequisite

This patch set is based on top of the latest "master" branch.

Tests
=
* ran and passed py/efi_selftest on sandbox locally
  (I saw an error in tcg2 though)
* ran and passed py/test_efi_bootmgr on sandbox locally
* passed CI check (github pull request)

Changes
===
v4 (Jan 10, 2024)
* rebased onto the latest master branch
* moved binary execution portion of code (EFI_BINARY_EXEC) to
  a new file, efi_bootbin.c, instead of efi_helper.c (patch#1)

v3 (Dec 18, 2023)
* rebased onto Tom's latest next branch
* remove already-merged commits

v2 (Nov 21, 2023)
* rebased onto Tom's next branch
* remove already merged commits
* revise commit messages
* add patch #5 which was split from ex-patch#5
RFC (Oct 26, 2023)

[1] https://lists.denx.de/pipermail/u-boot/2023-October/534598.html

AKASHI Takahiro (4):
  efi_loader: split unrelated code from efi_bootmgr.c
  efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR
  net: tftp: remove explicit efi configuration dependency
  fs: remove explicit efi configuration dependency

 boot/Kconfig |   4 +-
 boot/Makefile|   2 +-
 cmd/Kconfig  |  10 +-
 cmd/efidebug.c   |   4 +-
 fs/fs.c  |   7 +-
 include/efi_loader.h |  28 +-
 lib/efi_loader/Kconfig   |  11 +-
 lib/efi_loader/Makefile  |   3 +-
 lib/efi_loader/efi_bootbin.c | 211 +
 lib/efi_loader/efi_bootmgr.c | 488 ---
 lib/efi_loader/efi_device_path.c |   3 +-
 lib/efi_loader/efi_helper.c  | 286 ++
 net/tftp.c   |  10 +-
 test/boot/bootflow.c |   2 +-
 14 files changed, 546 insertions(+), 523 deletions(-)
 create mode 100644 lib/efi_loader/efi_bootbin.c

-- 
2.34.1



Re: [PATCH v2 2/2] efi_loader: support fmp versioning for multi bank update

2024-01-09 Thread Masahisa Kojima
On Tue, 9 Jan 2024 at 22:02, Ilias Apalodimas
 wrote:
>
> On Tue, 9 Jan 2024 at 03:00, Masahisa Kojima  
> wrote:
> >
> > Hi Ilias,
> >
> > On Thu, 28 Dec 2023 at 00:14, Ilias Apalodimas
> >  wrote:
> > >
> > > Kojima-san
> > >
> > > On Thu, Dec 21, 2023 at 06:52:58PM +0900, Masahisa Kojima wrote:
> > > > This commit stores the firmware version into the array
> > > > of fmp_state structure to support the fmp versioning
> > > > for multi bank update. The index of the array is identified
> > > > by the bank index.
> > >
> > > Why do we all of them? Can't we just always store/use the version of the 
> > > active
> > > bank?
> >
> > Sorry for the late reply.
> > When the capsule update is reverted, the active bank is back to the
> > previous active bank.
> > So I think versions for all banks should be stored.
>
> But even in that case, the active bank should point to the correct
> version when the ESRT tables are generated. Wouldn't it be simpler to
> just set the FmpState variable accordingly when that happens?

The fw_version in FmpState variable comes from UEFI Capsule Header and
FmpState variable is set when the UEFI capsule update is performed.
If we only store the fw_version of the active bank, the fw_version of
the previous active bank is overwritten. When the capsule is reverted,
we can not get the fw_version of the previous active bank.

Thanks,
Masahisa Kojima

> Am I missing anything?
>
> Thanks
> /Ilias
> >
> > Thanks,
> > Masahisa Kojima
> >
> > >
> > > >
> > > > This modification keeps the backward compatibility with
> > > > the existing versioning feature.
> > > >
> > >
> > > Thanks
> > > /Ilias
> > > > Signed-off-by: Masahisa Kojima 
> > > > ---
> > > >  lib/efi_loader/efi_firmware.c | 69 +++
> > > >  1 file changed, 54 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/lib/efi_loader/efi_firmware.c 
> > > > b/lib/efi_loader/efi_firmware.c
> > > > index 9b8630625f..5459f3d38d 100644
> > > > --- a/lib/efi_loader/efi_firmware.c
> > > > +++ b/lib/efi_loader/efi_firmware.c
> > > > @@ -207,18 +207,10 @@ void efi_firmware_fill_version_info(struct 
> > > > efi_firmware_image_descriptor *image_
> > > >  {
> > > >   u16 varname[13]; /* u"FmpState" */
> > > >   efi_status_t ret;
> > > > - efi_uintn_t size;
> > > > - struct fmp_state var_state = { 0 };
> > > > -
> > > > - efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > > - fw_array->image_index);
> > > > - size = sizeof(var_state);
> > > > - ret = efi_get_variable_int(varname, _array->image_type_id,
> > > > -NULL, , _state, NULL);
> > > > - if (ret == EFI_SUCCESS)
> > > > - image_info->version = var_state.fw_version;
> > > > - else
> > > > - image_info->version = 0;
> > > > + efi_uintn_t size, expected_size;
> > > > + uint num_banks = 1;
> > > > + uint active_index = 0;
> > > > + struct fmp_state *var_state;
> > > >
> > > >   efi_firmware_get_lsv_from_dtb(fw_array->image_index,
> > > > _array->image_type_id,
> > > > @@ -227,6 +219,31 @@ void efi_firmware_fill_version_info(struct 
> > > > efi_firmware_image_descriptor *image_
> > > >   image_info->version_name = NULL; /* not supported */
> > > >   image_info->last_attempt_version = 0;
> > > >   image_info->last_attempt_status = LAST_ATTEMPT_STATUS_SUCCESS;
> > > > + image_info->version = 0;
> > > > +
> > > > + /* get the fw_version */
> > > > + efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > > + fw_array->image_index);
> > > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > > + ret = fwu_get_active_index(_index);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + num_banks = CONFIG_FWU_NUM_BANKS;
> > > > + }
> > > > +
> > > > + size = num_banks * sizeof(*var_state);
> > > > + expected_size = size;
> > > > + var_state = calloc(1, size);
> > > > + if (!var_state)
> > > > + return;
> > > > +
> > > > + ret = efi_get_variable_int(varname, _array->image_type_id,
> > > > +NULL, , var_state, NULL);
> > > > + if (ret == EFI_SUCCESS && expected_size == size)
> > > > + image_info->version = var_state[active_index].fw_version;
> > > > +
> > > > + free(var_state);
> > > >  }
> > > >
> > > >  /**
> > > > @@ -362,8 +379,11 @@ efi_status_t efi_firmware_set_fmp_state_var(struct 
> > > > fmp_state *state, u8 image_in
> > > >  {
> > > >   u16 varname[13]; /* u"FmpState" */
> > > >   efi_status_t ret;
> > > > + uint num_banks = 1;
> > > > + uint update_bank = 0;
> > > > + efi_uintn_t size;
> > > >   efi_guid_t *image_type_id;
> > > > - struct fmp_state var_state = { 0 };
> > > > + struct fmp_state *var_state;
> > > >
> > > 

[PATCH] getchar(): Correct usage

2024-01-09 Thread Tom Rini
The function getchar() returns an 'int' and not a 'char'. Coverity notes
that "Assigning the return value of getchar to char ... truncates its value."
and so for the most part we can resolve this easily by using 'int' as
intended, and often used throughout the codebase. A few places are not
so simple and would require further re-architecting of the code in order
to change this, so we leave them be.

Signed-off-by: Tom Rini 
---
 cmd/load.c| 4 ++--
 common/cli_readline.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/load.c b/cmd/load.c
index 2715cf5957ee..540361b43f02 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -230,7 +230,7 @@ static ulong load_serial(long offset)
 static int read_record(char *buf, ulong len)
 {
char *p;
-   char c;
+   int c;
 
--len;  /* always leave room for terminating '\0' byte */
 
@@ -827,7 +827,7 @@ static void handle_send_packet(int n)
 /* k_recv receives a OS Open image file over kermit line */
 static int k_recv(void)
 {
-   char new_char;
+   int new_char;
char k_state, k_state_saved;
int sum;
int done;
diff --git a/common/cli_readline.c b/common/cli_readline.c
index 85453beed762..2507be229526 100644
--- a/common/cli_readline.c
+++ b/common/cli_readline.c
@@ -540,7 +540,7 @@ static int cread_line_simple(const char *const prompt, char 
*p)
int n = 0;  /* buffer index */
int plen = 0;   /* prompt length */
int col;/* output column cnt */
-   char c;
+   int c;
 
/* print prompt */
if (prompt) {
-- 
2.34.1



Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 12:26:13AM -0500, Sean Anderson wrote:
> Comments on NAND stuff only.
> 
> On 1/8/24 12:45, Tom Rini wrote:
> > 
> > *** CID 477216:(BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 3921 in nand_flash_detect_onfi()
> > 3915
> > 3916/*
> > 3917 * pages_per_block and blocks_per_lun may not be a
> > power-of-2 size
> > 3918 * (don't ask me who thought of this...). MTD assumes that 
> > these
> > 3919 * dimensions will be power-of-2, so just truncate the
> > remaining area.
> > 3920 */
> > > > >  CID 477216:(BAD_SHIFT)
> > > > >  In expression "1 << 
> > > > > generic_fls((__u32)(__le32)p->pages_per_block) - 1", shifting by a 
> > > > > negative amount has undefined behavior.  The shift amount, 
> > > > > "generic_fls((__u32)(__le32)p->pages_per_block) - 1", is -1.
> > 3921mtd->erasesize = 1 <<
> > (fls(le32_to_cpu(p->pages_per_block)) - 1);
> > 3922mtd->erasesize *= mtd->writesize;
> > 3923
> > 3924mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
> > 3925
> > 3926/* See erasesize comment */
> > /drivers/mtd/nand/raw/nand_base.c: 3927 in nand_flash_detect_onfi()
> > 3921mtd->erasesize = 1 <<
> > (fls(le32_to_cpu(p->pages_per_block)) - 1);
> > 3922mtd->erasesize *= mtd->writesize;
> > 3923
> > 3924mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
> > 3925
> > 3926/* See erasesize comment */
> > > > >  CID 477216:(BAD_SHIFT)
> > > > >  In expression "1 << 
> > > > > generic_fls((__u32)(__le32)p->blocks_per_lun) - 1", shifting by a 
> > > > > negative amount has undefined behavior.  The shift amount, 
> > > > > "generic_fls((__u32)(__le32)p->blocks_per_lun) - 1", is -1.
> > 3927chip->chipsize = 1 << (fls(le32_to_cpu(p->blocks_per_lun)) 
> > - 1);
> > 3928chip->chipsize *= (uint64_t)mtd->erasesize * p->lun_count;
> > 3929chip->bits_per_cell = p->bits_per_cell;
> > 3930
> > 3931if (onfi_feature(chip) & ONFI_FEATURE_16_BIT_BUS)
> > 3932chip->options |= NAND_BUSWIDTH_16;
> 
> Yeah, this looks like a bug.
> 
> > ** CID 477215:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4978 in nand_scan_tail()
> > 
> > 
> > 
> > *** CID 477215:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4978 in nand_scan_tail()
> > 4972pr_warn("No ECC functions supplied;
> > hardware ECC not possible\n");
> > 4973BUG();
> > 4974}
> > 4975if (!ecc->read_page)
> > 4976ecc->read_page = 
> > nand_read_page_hwecc_oob_first;
> > 4977
> > > > >  CID 477215:  Control flow issues  (MISSING_BREAK)
> > > > >  The case for value "NAND_ECC_HW" is not terminated by a "break" 
> > > > > statement.
> > 4978case NAND_ECC_HW:
> > 4979/* Use standard hwecc read page function? */
> > 4980if (!ecc->read_page)
> > 4981ecc->read_page = nand_read_page_hwecc;
> > 4982if (!ecc->write_page)
> > 4983ecc->write_page = nand_write_page_hwecc;
> 
> I think we just need a fallthrough comment here.
> 
> > ** CID 477214:  Integer handling issues  (BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 4397 in nand_detect()
> > 
> > 
> > 
> > *** CID 477214:  Integer handling issues  (BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 4397 in nand_detect()
> > 4391
> > 4392nand_decode_bbm_options(mtd, chip);
> > 4393
> > 4394/* Calculate the address shift from the page size */
> > 4395chip->page_shift = ffs(mtd->writesize) - 1;
> > 4396/* Convert chipsize to number of pages per chip -1 */
> > > > >  CID 477214:  Integer handling issues  (BAD_SHIFT)
> > > > >  In expression "chip->chipsize >> chip->page_shift", shifting by 
> > > > > a negative amount has undefined behavior.  The shift amount, 
> > > > > "chip->page_shift", is -1.
> > 4397chip->pagemask = (chip->chipsize >> chip->page_shift) - 1;
> > 4398
> > 4399chip->bbt_erase_shift = chip->phys_erase_shift =
> > 4400ffs(mtd->erasesize) - 1;
> > 4401if (chip->chipsize & 0x)
> > 4402chip->chip_shift = ffs((unsigned)chip->chipsize) - 
> > 1;
> 
> Buggy, but only when writesize is 0 (which is a bigger bug in the nand chip).
> 
> > ** CID 477213:  Security best practices violations  (DC.WEAK_CRYPTO)
> 

Re: Pull request smbios-2024-04-rc1

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 06:09:12PM +0100, Heinrich Schuchardt wrote:

> The following changes since commit c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d:
> 
>   Merge tag 'u-boot-imx-master-20240108' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-01-08 13:39:43
> -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/smbios-2024-04-rc1
> 
> for you to fetch changes up to 8aec7031112eba0dbfc8f23f9be11c081ea5cc56:
> 
>   efi_loader: provide tool to dump SMBIOS table (2024-01-09 10:09:15 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] smbios: copy QEMU tables

2024-01-09 Thread Heinrich Schuchardt

On 12/26/23 10:47, Simon Glass wrote:

Hi Heinrich,

On Sat, Dec 23, 2023 at 1:03 AM Heinrich Schuchardt  wrote:


From: Heinrich Schuchardt 

QEMU provides SMBIOS tables with detailed information. We should not try to
replicate them in U-Boot.

If we want to inform about U-Boot, we can add a Firmware Inventory
Information (type 45) table in future.

Signed-off-by: Heinrich Schuchardt 
---
v2:
 fix parsing of SMBIOS anchor
 enable copying on x86 and 32bit ARM/RISC-V
---
  arch/x86/lib/tables.c   |   2 +-
  drivers/misc/Kconfig|   7 ++
  drivers/misc/Makefile   |   1 +
  drivers/misc/qfw_smbios.c   | 197 
  lib/efi_loader/efi_smbios.c |   4 +-
  5 files changed, 209 insertions(+), 2 deletions(-)
  create mode 100644 drivers/misc/qfw_smbios.c

diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 5b5070f7ca..914d9de0cb 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -61,7 +61,7 @@ static struct table_info table_list[] = {
  #ifdef CONFIG_GENERATE_ACPI_TABLE
 { "acpi", write_acpi_tables, BLOBLISTT_ACPI_TABLES, 0x1, 0x1000},
  #endif
-#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+#if defined(CONFIG_GENERATE_SMBIOS_TABLE) && !defined(CONFIG_QFW_SMBIOS)
 { "smbios", write_smbios_table, BLOBLISTT_SMBIOS_TABLES, 0x1000, 
0x100},
  #endif
  };
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e8e4400516..d2536c54e0 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -561,6 +561,13 @@ config QFW_MMIO
   Hidden option to enable MMIO QEMU fw_cfg interface. This will be
   selected by the appropriate QEMU board.

+config QFW_SMBIOS
+   bool
+   default y
+   depends on QFW && SMBIOS && !SANDBOX
+   help
+ Hidden option to read SMBIOS tables from QEMU.
+
  config I2C_EEPROM
 bool "Enable driver for generic I2C-attached EEPROMs"
 depends on MISC
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index cda701d38e..64bea92f51 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -66,6 +66,7 @@ obj-y += qfw.o
  obj-$(CONFIG_QFW_ACPI) += qfw_acpi.o
  obj-$(CONFIG_QFW_PIO) += qfw_pio.o
  obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o
+obj-$(CONFIG_QFW_SMBIOS) += qfw_smbios.o
  obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
  endif
  obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
diff --git a/drivers/misc/qfw_smbios.c b/drivers/misc/qfw_smbios.c
new file mode 100644
index 00..9019345783
--- /dev/null
+++ b/drivers/misc/qfw_smbios.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2023 Heinrich Schuchardt 
+ */
+
+#define LOG_CATEGORY UCLASS_QFW
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * qfw_load_smbios_table() - load a QEMU firmware file
+ *
+ * @dev:   QEMU firmware device
+ * @size:  parameter to return the size of the loaded table
+ * @name:  name of the table to load
+ * Return: address of the loaded table, NULL on error
+ */
+static void *qfw_load_smbios_table(struct udevice *dev, uint32_t *size,
+  char *name)
+{
+   struct fw_file *file;
+   struct bios_linker_entry *table;
+
+   file = qfw_find_file(dev, name);
+   if (!file) {
+   log_debug("Can't find %s\n", name);
+   return NULL;
+   }
+
+   *size = be32_to_cpu(file->cfg.size);
+
+   table = malloc(*size);
+   if (!table) {
+   log_err("Out of memory\n");
+   return NULL;
+   }
+
+   qfw_read_entry(dev, be16_to_cpu(file->cfg.select), *size, table);
+
+   return table;
+}
+
+/**
+ * qfw_parse_smbios_anchor() - parse QEMU's SMBIOS anchor
+ *
+ * @dev:   QEMU firmware device
+ * @entry: SMBIOS 3 structure to be filled from QEMU's anchor
+ * Return: 0 for success, -ve on error
+ */
+static int qfw_parse_smbios_anchor(struct udevice *dev,
+  struct smbios3_entry *entry)
+{
+   void *table;
+   uint32_t size;
+   struct smbios_entry *entry2;
+   struct smbios3_entry *entry3;
+   const char smbios_sig[] = "_SM_";
+   const char smbios3_sig[] = "_SM3_";
+   int ret = 0;
+
+   table = qfw_load_smbios_table(dev, , "etc/smbios/smbios-anchor");
+   if (!table)
+   return -ENOMEM;
+   if (!memcmp(table, smbios3_sig, sizeof(smbios3_sig) - 1)) {
+   entry3 = table;
+   if (entry3->length != sizeof(struct smbios3_entry)) {
+   ret = -ENOENT;
+   goto out;
+   }
+   memcpy(entry, entry3, sizeof(struct smbios3_entry));
+   } else if (!memcmp(table, smbios_sig, sizeof(smbios_sig) - 1)) {
+   entry2 = table;
+   if (entry2->length != sizeof(struct smbios_entry)) {
+   ret = 

Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 02:00:14PM -0600, Nishanth Menon wrote:
> On 14:48-20240109, Tom Rini wrote:
> [...]
> > > > -- 
> > > > 2.34.1
> > > > 
> > > 
> > > Why not a config fragment?
> > 
> > To me, this makes sense to keep in the main config. It can be turned off
> > as needed, and at run time if it's not present, it's safe.
> 
> Three reasons:
> * There is going to be duplication across multiple boards
> * It confuses the affair of trying to find the minimal configuration needed
>   to boot the board.
> * SRAM is limited already - we have been playing all kind of dances
>   around this - NAND is a daughter card addon - while I am not trying to
>   diminish NAND support, we are in a constant struggle to keep SRAM
>   viable and adding additional boot modes to a single config, IMHO is
>   the wrong direction to go.

At the end of the day, I'll leave it to TI folks. I see that
drivers/mtd/Kconfig needs a whole lot of help as while I would have
hoped that turning off just CONFIG_MTD would undo most of the changes
here, it does not.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Nishanth Menon
On 21:00-20240109, Francesco Dolcini wrote:
> On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote:
> > On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote:
> > > On 14:26-20240109, Roger Quadros wrote:
> > > >  CONFIG_CMD_PMIC=y
> > > >  CONFIG_CMD_REGULATOR=y
> > > > +CONFIG_CMD_MTDPARTS=y
> > > > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> > > > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
> > > 
> > > Why not handle this as device tree partitions?
> > 
> > I honestly forget what the preferred way of defining and passing NAND
> > partition information is these days. It might even be the funny case
> > that passing as cmdline args is "best" rather than fixed-partitions
> > binding?
> 
> According to past discussions [1] doing the fixup in U-Boot is not advised.
> 
> Using the command line or having the partition fixed in the DT are both
> valid options.
> 
> [1] https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/

yup - also why I wonder why we cant depend on DT.

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


Re: [PATCH v2 02/17] video: dw_hdmi: Add Vendor PHY handling

2024-01-09 Thread Jagan Teki
Hi Neil,

On Tue, Dec 19, 2023 at 5:21 PM Jagan Teki  wrote:
>
> On Tue, Dec 19, 2023 at 2:34 PM Neil Armstrong
>  wrote:
> >
> > On 18/12/2023 20:10, Jagan Teki wrote:
> > > From: Jagan Teki 
> > >
> > > DW HDMI support Vendor PHY like Rockchip RK3328 Inno HDMI PHY.
> > >
> > > Extend the vendor phy handling by adding platform phy hooks.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > > Changes for v2:
> > > - fix meson cfg
> > >
> > >   drivers/video/dw_hdmi.c  | 29 +++-
> > >   drivers/video/meson/meson_dw_hdmi.c  | 11 ++-
> > >   drivers/video/rockchip/rk3399_hdmi.c |  8 +++-
> > >   drivers/video/rockchip/rk_hdmi.c |  2 +-
> > >   drivers/video/sunxi/sunxi_dw_hdmi.c  | 11 ++-
> > >   include/dw_hdmi.h| 14 +-
> > >   6 files changed, 69 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
> > > index c4fbb18294..ea12a09407 100644
> > > --- a/drivers/video/dw_hdmi.c
> > > +++ b/drivers/video/dw_hdmi.c
> > > @@ -988,7 +988,7 @@ int dw_hdmi_enable(struct dw_hdmi *hdmi, const struct 
> > > display_timing *edid)
> > >
> > >   hdmi_av_composer(hdmi, edid);
> > >
> > > - ret = hdmi->phy_set(hdmi, edid->pixelclock.typ);
> > > + ret = hdmi->ops->phy_set(hdmi, edid->pixelclock.typ);
> > >   if (ret)
> > >   return ret;
> > >
> > > @@ -1009,10 +1009,37 @@ int dw_hdmi_enable(struct dw_hdmi *hdmi, const 
> > > struct display_timing *edid)
> > >   return 0;
> > >   }
> > >
> > > +static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> > > + .phy_set = dw_hdmi_phy_cfg,
> > > +};
> > > +
> > > +static void dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
> > > +{
> > > + if (!hdmi->data)
> > > + return;
> > > +
> > > + /* hook Synopsys PHYs ops */
> > > + if (!hdmi->data->phy_force_vendor) {
> > > + hdmi->ops = _hdmi_synopsys_phy_ops;
> > > + return;
> > > + }
> > > +
> > > + /* Vendor HDMI PHYs must assign phy_ops in plat_data */
> > > + if (!hdmi->data->phy_ops) {
> > > + printf("Unsupported Vendor HDMI phy_ops\n");
> > > + return;
> > > + }
> > > +
> > > + /* hook Vendor HDMI PHYs ops */
> > > + hdmi->ops = hdmi->data->phy_ops;
> >
> > Sorry but I still don't understand why you need phy_force_vendor & phy_ops,
> > this code clearly fails if you have phy_force_vendor=true && phy_ops=NULL,
> > so drop phy_force_vendor and simply use phy_ops if != NULL, and since it's
> > the only element of dw_hdmi_plat_data, drop dw_hdmi_plat_data and pass
> > dw_hdmi_phy_ops directly in the dw_hdmi struct.
> >
> > So in dw_hdmi_detect_phy(), if hdmi->ops is NULL, set it to 
> > dw_hdmi_synopsys_phy_ops.
>
> Let me elaborate more.
>
> DW HDMI IP must have phy ops. It never be NULL. Either it uses
> 1. Internal PHY via DW called them Synopsys PHYs ops - for example, rk3399
> 2. Vendor PHY via vendor phy meson, sunxi, rk3328
>
> For case 1) phy_force_vendor is false so it uses dw_hdmi_synopsys_phy_ops
> For case 2) phy_force_vendor is true so it uses dw_hdmi_plat_data phy ops
>
> dw_hdmi_detect_phy assigns internal phy ops first and then vendor phy
> ops based on phy_force_vendor flag.
>
> If we remove dw_hdmi_plat_data how can we assign or differentiate two
> types of phy ops hooks? can you explain?

Let me know if you have any comments on this. I'm sending V3 would
probably hit in MW.

Thanks,
Jagan.


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Francesco Dolcini
On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote:
> On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote:
> > On 14:26-20240109, Roger Quadros wrote:
> > >  CONFIG_CMD_PMIC=y
> > >  CONFIG_CMD_REGULATOR=y
> > > +CONFIG_CMD_MTDPARTS=y
> > > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> > > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
> > 
> > Why not handle this as device tree partitions?
> 
> I honestly forget what the preferred way of defining and passing NAND
> partition information is these days. It might even be the funny case
> that passing as cmdline args is "best" rather than fixed-partitions
> binding?

According to past discussions [1] doing the fixup in U-Boot is not advised.

Using the command line or having the partition fixed in the DT are both
valid options.

[1] https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/

Francesco



Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Nishanth Menon
On 14:48-20240109, Tom Rini wrote:
[...]
> > > -- 
> > > 2.34.1
> > > 
> > 
> > Why not a config fragment?
> 
> To me, this makes sense to keep in the main config. It can be turned off
> as needed, and at run time if it's not present, it's safe.

Three reasons:
* There is going to be duplication across multiple boards
* It confuses the affair of trying to find the minimal configuration needed
  to boot the board.
* SRAM is limited already - we have been playing all kind of dances
  around this - NAND is a daughter card addon - while I am not trying to
  diminish NAND support, we are in a constant struggle to keep SRAM
  viable and adding additional boot modes to a single config, IMHO is
  the wrong direction to go.


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


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote:
> On 14:26-20240109, Roger Quadros wrote:
> > Enables configuration required for NAND in SPL and u-boot.
> > 
> > Enable MTD Driver model and MTD + UBI command line utilities.
> > 
> > Add mtdids/mtdparts for NAND as it is required for u-boot's
> > MTD subsystem commands to recognize NAND partitions.
> > 
> > Add u-boot partition location.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> >  configs/am64x_evm_a53_defconfig | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/configs/am64x_evm_a53_defconfig 
> > b/configs/am64x_evm_a53_defconfig
> > index 05e35a8db6..e22153a958 100644
> > --- a/configs/am64x_evm_a53_defconfig
> > +++ b/configs/am64x_evm_a53_defconfig
> > @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y
> >  CONFIG_CMD_GPT=y
> >  CONFIG_CMD_I2C=y
> >  CONFIG_CMD_MMC=y
> > +CONFIG_CMD_MTD=y
> >  CONFIG_CMD_USB=y
> >  CONFIG_CMD_TIME=y
> >  CONFIG_CMD_PMIC=y
> >  CONFIG_CMD_REGULATOR=y
> > +CONFIG_CMD_MTDPARTS=y
> > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
> 
> Why not handle this as device tree partitions?

I honestly forget what the preferred way of defining and passing NAND
partition information is these days. It might even be the funny case
that passing as cmdline args is "best" rather than fixed-partitions
binding?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 01:16:27PM -0600, Nishanth Menon wrote:
> On 14:26-20240109, Roger Quadros wrote:
> > Enables configuration required for NAND in SPL and u-boot.
> > 
> > Enable MTD Driver model and MTD + UBI command line utilities.
> > 
> > Add mtdids/mtdparts for NAND as it is required for u-boot's
> > MTD subsystem commands to recognize NAND partitions.
> > 
> > Add u-boot partition location.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> >  configs/am64x_evm_a53_defconfig | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/configs/am64x_evm_a53_defconfig 
> > b/configs/am64x_evm_a53_defconfig
> > index 05e35a8db6..e22153a958 100644
> > --- a/configs/am64x_evm_a53_defconfig
> > +++ b/configs/am64x_evm_a53_defconfig
> > @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y
> >  CONFIG_CMD_GPT=y
> >  CONFIG_CMD_I2C=y
> >  CONFIG_CMD_MMC=y
> > +CONFIG_CMD_MTD=y
> >  CONFIG_CMD_USB=y
> >  CONFIG_CMD_TIME=y
> >  CONFIG_CMD_PMIC=y
> >  CONFIG_CMD_REGULATOR=y
> > +CONFIG_CMD_MTDPARTS=y
> > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
> > +CONFIG_CMD_UBI=y
> >  CONFIG_OF_CONTROL=y
> >  CONFIG_SPL_OF_CONTROL=y
> >  CONFIG_OF_LIST="k3-am642-evm k3-am642-sk"
> > @@ -107,6 +112,9 @@ CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_ADMA=y
> >  CONFIG_SPL_MMC_SDHCI_ADMA=y
> >  CONFIG_MMC_SDHCI_AM654=y
> > +CONFIG_MTD=y
> > +CONFIG_SPL_MTD=y
> > +CONFIG_DM_MTD=y
> >  CONFIG_DM_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> > @@ -161,3 +169,27 @@ CONFIG_USB_GADGET_DOWNLOAD=y
> >  CONFIG_USB_FUNCTION_MASS_STORAGE=y
> >  CONFIG_SPL_DFU=y
> >  CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> > +CONFIG_MEMORY=y
> > +CONFIG_SPL_MEMORY=y
> > +CONFIG_TI_GPMC=y
> > +CONFIG_MTD_RAW_NAND=y
> > +CONFIG_NAND_OMAP_GPMC=y
> > +CONFIG_CMD_NAND=y
> > +CONFIG_NAND_OMAP_ELM=y
> > +CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW=y
> > +CONFIG_SYS_NAND_BLOCK_SIZE=0x4
> > +CONFIG_SYS_NAND_ONFI_DETECTION=y
> > +CONFIG_SYS_NAND_PAGE_SIZE=0x1000
> > +CONFIG_SYS_NAND_PAGE_COUNT=0x40
> > +CONFIG_SYS_NAND_OOBSIZE=0x100
> > +CONFIG_SPL_NAND_SUPPORT=y
> > +CONFIG_SPL_NAND_DRIVERS=y
> > +CONFIG_SPL_NAND_BASE=y
> > +CONFIG_SPL_NAND_IDENT=y
> > +CONFIG_SPL_NAND_ECC=y
> > +CONFIG_SYS_NAND_MAX_CHIPS=1
> > +CONFIG_SYS_MAX_NAND_DEVICE=1
> > +# CONFIG_SPL_NAND_AM33XX_BCH is not set
> > +CONFIG_SPL_MTD_SUPPORT=y
> > +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
> > +CONFIG_SYS_NAND_U_BOOT_OFFS=0x60
> > -- 
> > 2.34.1
> > 
> 
> Why not a config fragment?

To me, this makes sense to keep in the main config. It can be turned off
as needed, and at run time if it's not present, it's safe.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] board: ti: am64: Support TMDS64EVM

2024-01-09 Thread Nishanth Menon
On 15:16-20240108, Roger Quadros wrote:
> The TMDS64EVM [1] ships with AM64X SR2.0 HS-FS chip
> and a slightly different board name in the board information
> EEPROM header. Support this board.
> 
> [1] https://www.ti.com/tool/TMDS64EVM
> 
> Gets rid of below message at boot
> "Unidentified board claims AM64-EVM in eeprom header"
> 
> Signed-off-by: Roger Quadros 
> ---
>  board/ti/am64x/evm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index a6dcff2eb4..a7ca6be436 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -18,6 +18,7 @@
>  #include "../common/board_detect.h"
>  
>  #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
> + board_ti_k3_is("AM64-EVM") || \
>   board_ti_k3_is("AM64-HSEVM"))
>  
>  #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
> 
> base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994
> -- 
> 2.34.1
> 

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


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Nishanth Menon
On 14:26-20240109, Roger Quadros wrote:
> Enables configuration required for NAND in SPL and u-boot.
> 
> Enable MTD Driver model and MTD + UBI command line utilities.
> 
> Add mtdids/mtdparts for NAND as it is required for u-boot's
> MTD subsystem commands to recognize NAND partitions.
> 
> Add u-boot partition location.
> 
> Signed-off-by: Roger Quadros 
> ---
>  configs/am64x_evm_a53_defconfig | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
> index 05e35a8db6..e22153a958 100644
> --- a/configs/am64x_evm_a53_defconfig
> +++ b/configs/am64x_evm_a53_defconfig
> @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_MTD=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_TIME=y
>  CONFIG_CMD_PMIC=y
>  CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"

Why not handle this as device tree partitions?

> +CONFIG_CMD_UBI=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIST="k3-am642-evm k3-am642-sk"
> @@ -107,6 +112,9 @@ CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ADMA=y
>  CONFIG_SPL_MMC_SDHCI_ADMA=y
>  CONFIG_MMC_SDHCI_AM654=y
> +CONFIG_MTD=y
> +CONFIG_SPL_MTD=y
> +CONFIG_DM_MTD=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
> @@ -161,3 +169,27 @@ CONFIG_USB_GADGET_DOWNLOAD=y
>  CONFIG_USB_FUNCTION_MASS_STORAGE=y
>  CONFIG_SPL_DFU=y
>  CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> +CONFIG_MEMORY=y
> +CONFIG_SPL_MEMORY=y
> +CONFIG_TI_GPMC=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_NAND_OMAP_GPMC=y
> +CONFIG_CMD_NAND=y
> +CONFIG_NAND_OMAP_ELM=y
> +CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW=y
> +CONFIG_SYS_NAND_BLOCK_SIZE=0x4
> +CONFIG_SYS_NAND_ONFI_DETECTION=y
> +CONFIG_SYS_NAND_PAGE_SIZE=0x1000
> +CONFIG_SYS_NAND_PAGE_COUNT=0x40
> +CONFIG_SYS_NAND_OOBSIZE=0x100
> +CONFIG_SPL_NAND_SUPPORT=y
> +CONFIG_SPL_NAND_DRIVERS=y
> +CONFIG_SPL_NAND_BASE=y
> +CONFIG_SPL_NAND_IDENT=y
> +CONFIG_SPL_NAND_ECC=y
> +CONFIG_SYS_NAND_MAX_CHIPS=1
> +CONFIG_SYS_MAX_NAND_DEVICE=1
> +# CONFIG_SPL_NAND_AM33XX_BCH is not set
> +CONFIG_SPL_MTD_SUPPORT=y
> +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
> +CONFIG_SYS_NAND_U_BOOT_OFFS=0x60
> -- 
> 2.34.1
> 

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


[PATCH V2 04/10] board: ti: am64x: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.
I have retained the the existing names used in the file as is for now, a
cleanup as suggested in review is probably something to do in a follow
on series.

V1: https://lore.kernel.org/r/20240108173301.2692332-5...@ti.com

 board/ti/am64x/am64x.env | 9 -
 board/ti/am64x/evm.c | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index efd736b99be4..9a8812d4ee54 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,14 +2,6 @@
 #include 
 #include 
 
-findfdt=
-   if test $board_name = am64x_gpevm; then
-   setenv name_fdt ti/k3-am642-evm.dtb; fi;
-   if test $board_name = am64x_skevm; then
-   setenv name_fdt ti/k3-am642-sk.dtb; fi;
-   if test $name_fdt = undefined; then
-   echo WARNING: Could not determine device tree to use; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
@@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
 usbboot=setenv boot usb;
setenv bootpart 0:2;
usb start;
-   run findfdt;
run init_usb;
run get_kern_usb;
run get_fdt_usb;
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a6dcff2eb434..e2f506d2c6ea 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
board_ti_k3_is("AM64-HSEVM"))
@@ -180,6 +181,12 @@ int checkboard(void)
 }
 
 #ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
+   {"am64x_gpevm", "k3-am642-evm.dtb"},
+   {"am64x_skevm", "k3-am642-sk.dtb"},
+   { /* Sentinel. */ }
+};
+
 static void setup_board_eeprom_env(void)
 {
char *name = "am64x_gpevm";
@@ -197,6 +204,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_am64_evm_fdt_map);
 }
 
 static void setup_serial(void)
-- 
2.43.0



[PATCH V2 10/10] include: env: ti: Drop default_findfdt

2024-01-09 Thread Nishanth Menon
We shouldn't need finfdt anymore. Drop the env script.

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.

V1: https://lore.kernel.org/r/20240108173301.2692332-11...@ti.com
 include/env/ti/default_findfdt.env | 12 
 1 file changed, 12 deletions(-)
 delete mode 100644 include/env/ti/default_findfdt.env

diff --git a/include/env/ti/default_findfdt.env 
b/include/env/ti/default_findfdt.env
deleted file mode 100644
index a2b51dd923bb..
--- a/include/env/ti/default_findfdt.env
+++ /dev/null
@@ -1,12 +0,0 @@
-default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
-default_device_tree_arch=ti
-#ifdef CONFIG_ARM64
-findfdt=
-   setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
-   setenv fdtfile ${name_fdt}
-#else
-default_device_tree_subarch=omap
-findfdt=
-   setenv name_fdt 
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
-   setenv fdtfile ${name_fdt}
-#endif
-- 
2.43.0



[PATCH V2 08/10] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
Stop using the findfdt script and switch to setting the fdtfile from C
code.

Signed-off-by: Nishanth Menon 
---
Changes from V1:
* Just macro name change s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH
* Commit message update to drop the "warning added to findfdt" since
  that is not done.

I have retained the explicit setting of fdtfile to remove dependency on
TI evm specific logic. Also, the dynamic population of fdtfile instead
of env_set("fdtfile", "ti/k3-j721e-beagleboneai64.dtb") to allow for the
upcoming board variants to be able to  configure the dtb name via a
config fragment.

V1: https://lore.kernel.org/r/20240108173301.2692332-9...@ti.com
 board/beagle/beagleboneai64/beagleboneai64.c   | 14 ++
 board/beagle/beagleboneai64/beagleboneai64.env |  1 -
 configs/j721e_beagleboneai64_a72_defconfig |  3 ++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..c5b4ff7df47a 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   char fdtfile[50];
+
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+   env_set("fdtfile", fdtfile);
+
+   return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env 
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/configs/j721e_beagleboneai64_a72_defconfig 
b/configs/j721e_beagleboneai64_a72_defconfig
index 959f86844d32..9e53658eacb9 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d 
seconds\n"
 CONFIG_AUTOBOOT_DELAY_STR="d"
 CONFIG_AUTOBOOT_STOP_STR=" "
 CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; 
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan 
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_LOGLEVEL=7
 CONFIG_SPL_MAX_SIZE=0xc
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-- 
2.43.0



[PATCH V2 00/10] board/ti: k3 boards: Stop using findfdt

2024-01-09 Thread Nishanth Menon
This is a wide cleanup to switch to setting fdtfile using env_set
instead of scripted magic. 'fdtfile' is expected to be set by default.
This allows the stdboot triggered efi loaders to find the correct OS
device tree file even if regular boot process is interrupted by user
intervention.

This is a refresh of
https://lore.kernel.org/all/86le9dwz4d@udb0321960.dhcp.ti.com/ which
was the wrong approach.

Updates from V1:
 * Renames of variables and macros for various review comments.
 * Commit message updates in some patches for clarity.

Bootlogs: https://gist.github.com/nmenon/843e343cde645ec4aa57b60cece5256a

based on master: c5e461fbf7cc Merge tag 'u-boot-imx-master-20240108' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-imx

NOTE: There are a couple of checkpatch WARN (around LATE_INIT) and
CHECK (fdt_ops #ifdeffery) that on closer inspection looks fine and
consistent with other similar usage.

V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/

Nishanth Menon (10):
  board: ti: common: Introduce a common fdt ops library
  board: ti: am62ax: Set fdtfile from C code instead of findfdt script
  board: ti: am62x: Set fdtfile from C code instead of findfdt script
  board: ti: am64x: Set fdtfile from C code instead of findfdt script
  board: ti: am65x: Set fdtfile from C code instead of findfdt script
  board: ti: j721e: Set fdtfile from C code instead of findfdt script
  board: ti: j721s2: Set fdtfile from C code instead of findfdt script
  board: beagle: beagleboneai64: Set fdtfile from C code instead of
findfdt script
  board: beagle: beagleplay: Set fdtfile from C code instead of findfdt
script
  include: env: ti: Drop default_findfdt

 board/beagle/beagleboneai64/beagleboneai64.c  | 14 
 .../beagle/beagleboneai64/beagleboneai64.env  |  1 -
 board/beagle/beagleplay/beagleplay.c  | 14 
 board/beagle/beagleplay/beagleplay.env|  1 -
 board/ti/am62ax/am62ax.env|  1 -
 board/ti/am62ax/evm.c | 10 +++
 board/ti/am62x/am62x.env  |  1 -
 board/ti/am62x/evm.c  |  8 +++
 board/ti/am64x/am64x.env  |  9 ---
 board/ti/am64x/evm.c  |  8 +++
 board/ti/am65x/am65x.env  |  3 -
 board/ti/am65x/evm.c  |  2 +
 board/ti/common/Kconfig   | 12 
 board/ti/common/Makefile  |  1 +
 board/ti/common/fdt_ops.c | 64 +++
 board/ti/common/fdt_ops.h | 42 
 board/ti/j721e/evm.c  |  8 +++
 board/ti/j721e/j721e.env  | 10 ---
 board/ti/j721s2/evm.c |  8 +++
 board/ti/j721s2/j721s2.env|  8 ---
 configs/am62ax_evm_a53_defconfig  |  1 +
 configs/am62x_beagleplay_a53_defconfig|  3 +-
 configs/am62x_evm_a53_defconfig   |  1 +
 configs/j721e_beagleboneai64_a72_defconfig|  3 +-
 include/env/ti/default_findfdt.env| 12 
 25 files changed, 197 insertions(+), 48 deletions(-)
 create mode 100644 board/ti/common/fdt_ops.c
 create mode 100644 board/ti/common/fdt_ops.h
 delete mode 100644 include/env/ti/default_findfdt.env

-- 
2.43.0



[PATCH V2 09/10] board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
Stop using the findfdt script and switch to setting the fdtfile from C
code.

Signed-off-by: Nishanth Menon 
---
Changes from V1:
* Just macro name change s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH
* Commit message update to drop the "warning added to findfdt" since
  that is not done.

I have retained the explicit setting of fdtfile to remove dependency on
TI evm specific logic. Also, the dynamic population of fdtfile instead
of env_set("fdtfile", "ti/k3-am625-beagleplay.dtb") to allow for the
upcoming board variants to be able to  configure the dtb name via a
config fragment.

V1: https://lore.kernel.org/r/20240108173301.2692332-10...@ti.com
 board/beagle/beagleplay/beagleplay.c   | 14 ++
 board/beagle/beagleplay/beagleplay.env |  1 -
 configs/am62x_beagleplay_a53_defconfig |  3 ++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/beagle/beagleplay/beagleplay.c 
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..20819ecf45b4 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -27,3 +27,17 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   char fdtfile[50];
+
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+   env_set("fdtfile", fdtfile);
+
+   return 0;
+}
+#endif
diff --git a/board/beagle/beagleplay/beagleplay.env 
b/board/beagle/beagleplay/beagleplay.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/configs/am62x_beagleplay_a53_defconfig 
b/configs/am62x_beagleplay_a53_defconfig
index 0be20045a974..1f43891d10bb 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -33,7 +33,8 @@ CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
 CONFIG_AUTOBOOT_DELAY_STR="d"
 CONFIG_AUTOBOOT_STOP_STR=" "
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; 
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan 
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80c8
-- 
2.43.0



[PATCH V2 06/10] board: ti: j721e: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.

v1: https://lore.kernel.org/r/20240108173301.2692332-7...@ti.com
 board/ti/j721e/evm.c |  8 
 board/ti/j721e/j721e.env | 10 --
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index c541880107ec..ad6ef4553e04 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_j721e_som()   (board_ti_k3_is("J721EX-PM1-SOM") || \
 board_ti_k3_is("J721EX-PM2-SOM"))
@@ -424,6 +425,12 @@ void configure_serdes_sierra(void)
 }
 
 #ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
+   {"j721e", "k3-j721e-common-proc-board.dtb"},
+   {"j721e-sk", "k3-j721e-sk.dtb"},
+   {"j7200", "k3-j7200-common-proc-board.dtb"},
+   { /* Sentinel. */ }
+};
 static void setup_board_eeprom_env(void)
 {
char *name = "j721e";
@@ -443,6 +450,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
 }
 
 static void setup_serial(void)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index cb27bf5e2b24..38bfd7d49634 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -7,16 +7,6 @@
 #include 
 #endif
 
-default_device_tree=ti/k3-j721e-common-proc-board.dtb
-findfdt=
-   setenv name_fdt ${default_device_tree};
-   if test $board_name = j721e; then
-   setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
-   if test $board_name = j7200; then
-   setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
-   if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
-   setenv name_fdt ti/k3-j721e-sk.dtb; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
-- 
2.43.0



[PATCH V2 07/10] board: ti: j721s2: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.

V1: https://lore.kernel.org/r/20240108173301.2692332-8...@ti.com
 board/ti/j721s2/evm.c  | 8 
 board/ti/j721s2/j721s2.env | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 1220cd84519b..5a0281d6b483 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -114,6 +115,12 @@ int checkboard(void)
return 0;
 }
 
+static struct ti_fdt_map ti_j721s2_evm_fdt_map[] = {
+   {"j721s2", "k3-j721s2-common-proc-board.dtb"},
+   {"am68-sk", "k3-am68-sk-base-board.dtb"},
+   { /* Sentinel. */ }
+};
+
 static void setup_board_eeprom_env(void)
 {
char *name = "j721s2";
@@ -131,6 +138,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_j721s2_evm_fdt_map);
 }
 
 static void setup_serial(void)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85f0..9a03b9f30aee 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -7,14 +7,6 @@
 #include 
 #endif
 
-default_device_tree=ti/k3-j721s2-common-proc-board.dtb
-findfdt=
-   setenv name_fdt ${default_device_tree};
-   if test $board_name = j721s2; then  \
-   setenv name_fdt ti/k3-j721s2-common-proc-board.dtb; fi;
-   if test $board_name = am68-sk; then
-   setenv name_fdt ti/k3-am68-sk-base-board.dtb; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
-- 
2.43.0



[PATCH V2 02/10] board: ti: am62ax: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
Stop using the findfdt script and switch to setting the fdtfile from
C code.

While at this, replace findfdt in environment with a warning as it is
no longer needed

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.

V1: https://lore.kernel.org/r/20240108173301.2692332-3...@ti.com

 board/ti/am62ax/am62ax.env   |  1 -
 board/ti/am62ax/evm.c| 10 ++
 configs/am62ax_evm_a53_defconfig |  1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index a6d967e982d4..334374abb73e 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index cd3360a43029..62d3664936e7 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "../common/fdt_ops.h"
+
 int board_init(void)
 {
return 0;
@@ -27,3 +29,11 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   ti_set_fdt_env(NULL, NULL);
+   return 0;
+}
+#endif
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 38083586a3ec..e5fcd8cc5b6f 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 CONFIG_BOOTSTD_FULL=y
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_PAD_TO=0x0
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-- 
2.43.0



[PATCH V2 01/10] board: ti: common: Introduce a common fdt ops library

2024-01-09 Thread Nishanth Menon
Introduce a common fdt operations library for basic device tree
operations that are common between various boards.

The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.

Signed-off-by: Nishanth Menon 
---
Changes Since v1:
* s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH s/name_fdt/board_name
  s/TI_NAME_FDT_MAX/TI_BOARD_NAME_MAX
* Comment updates in various places for review clarification.
* Still maintain the fall back using CONFIG_DEFAULT_DEVICE_TREE for
  reasons explained in review comment response.
* Added a specific u-boot version number for deprecation of legacy
  env variables.

V1: https://lore.kernel.org/r/20240108173301.2692332-2...@ti.com

 board/ti/common/Kconfig   | 12 
 board/ti/common/Makefile  |  1 +
 board/ti/common/fdt_ops.c | 64 +++
 board/ti/common/fdt_ops.h | 42 +
 4 files changed, 119 insertions(+)
 create mode 100644 board/ti/common/fdt_ops.c
 create mode 100644 board/ti/common/fdt_ops.h

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..de44e4de2115 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_FDT_FOLDER_PATH
+   string "Location of Folder path where dtb is present"
+   default "ti/davinci" if ARCH_DAVINCI
+   default "ti/keystone" if ARCH_KEYSTONE
+   default "ti/omap" if ARCH_OMAP2PLUS
+   default "ti" if ARCH_K3
+   depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+   help
+  Folder path for kernel device tree default.
+  This is used along with fdtfile path to locate the kernel
+  device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
 
 obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
 obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..eb917be9e0da
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include 
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
+{
+   char *fdt_file_name = NULL;
+   char fdtfile[TI_FDT_FILE_MAX];
+
+   if (board_name) {
+   while (fdt_map) {
+   /* Check for NULL terminator in the list */
+   if (!fdt_map->board_name)
+   break;
+   if (!strncmp(fdt_map->board_name, board_name, 
TI_BOARD_NAME_MAX)) {
+   fdt_file_name = fdt_map->fdt_file_name;
+   break;
+   }
+   fdt_map++;
+   }
+   }
+
+   /* match not found OR null board_name */
+   if (!fdt_file_name) {
+   /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+   if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_FDT_FOLDER_PATH, 
CONFIG_DEFAULT_FDT_FILE);
+   } else
+#endif
+   {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, 
CONFIG_DEFAULT_DEVICE_TREE);
+   }
+   } else {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s", 
CONFIG_TI_FDT_FOLDER_PATH,
+fdt_file_name);
+   }
+
+   env_set("fdtfile", fdtfile);
+
+   /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions (2024.10).
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+   if (board_name)
+   env_set("name_fdt", fdtfile);
+   /* Also set the findfdt legacy script to warn users to stop using this 
*/
+   env_set("findfdt",
+   "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..5d304994fb6e
--- /dev/null
+++ b/board/ti/common/fdt_ops.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Library to support common device tree manipulation 

[PATCH V2 03/10] board: ti: am62x: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
Stop using the findfdt script and switch to setting the fdtfile from
C code.

While at this, replace findfdt in environment with a warning as it is
no longer needed

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.

V1: https://lore.kernel.org/r/20240108173301.2692332-4...@ti.com
 board/ti/am62x/am62x.env| 1 -
 board/ti/am62x/evm.c| 8 
 configs/am62x_evm_a53_defconfig | 1 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e53a55c38fbb..9cb186c2a03c 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad939088402e..b76ef1b94a61 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -54,6 +54,14 @@ int dram_init(void)
return fdtdec_setup_mem_size_base();
 }
 
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   ti_set_fdt_env(NULL, NULL);
+   return 0;
+}
+#endif
+
 int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index aa96c1b3125c..3cf3b93a93fc 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_BOOTSTD_FULL=y
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_SYS_BOOTM_LEN=0x80
 CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80c8
-- 
2.43.0



[PATCH V2 05/10] board: ti: am65x: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Signed-off-by: Nishanth Menon 
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.

V1: https://lore.kernel.org/r/20240108173301.2692332-6...@ti.com
 board/ti/am65x/am65x.env | 3 ---
 board/ti/am65x/evm.c | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c05..814374d68cf0 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -5,9 +5,6 @@
 #include 
 #endif
 
-findfdt=
-   setenv name_fdt ti/k3-am654-base-board.dtb;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1b7..3109c9a2acac 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
 
@@ -141,6 +142,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(NULL, NULL);
 }
 
 static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
-- 
2.43.0



Re: [PATCH 0/4] arm: mach-k3: am64: Add NAND configuration

2024-01-09 Thread Nishanth Menon
On 14:26-20240109, Roger Quadros wrote:
> Hi,
> 
> AM64-EVM [1] supports NAND via expansion card.
> 
> This series fixes the GPMC memory and NAND drivers
> and provides NAND configuration for AM642 platform.
> 
> The extension card support and NAND DT overlay is
> still missing so NAND is not yet functional just with
> this series.
> 
> It was tested with NAND overlay [2] manually applied to base
> AM64-EVM DT.
> 
> CI test results are available at
> https://github.com/u-boot/u-boot/pull/460
> 
> [1] https://www.ti.com/tool/TMDS64EVM
> [2] https://lore.kernel.org/all/20230923080046.5373-2-rog...@kernel.org/
> 
> Roger Quadros (4):
>   memory: ti-gpmc: Fix build
>   mtd: rawnand: omap_gpmc: Use DT provided IO address
>   arm: mach-k3: am642: Define NAND boot device
>   configs: am64x_evm_a53_defconfig: Enable NAND
> 
>  arch/arm/mach-k3/am642_init.c|  3 +++
>  arch/arm/mach-k3/include/mach/am64_spl.h |  1 +
>  configs/am64x_evm_a53_defconfig  | 32 
>  drivers/memory/ti-gpmc.c |  2 +-
>  drivers/mtd/nand/raw/omap_gpmc.c | 19 ++
>  5 files changed, 51 insertions(+), 6 deletions(-)

Please update am64x documentation as well. People will need to know
how to actually build, flash and use it.

> 
> 
> base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994
> prerequisite-patch-id: e0465f3e924302d1c4bd47f2129b4eb3bd9faead
> -- 
> 2.34.1
> 

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


Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND

2024-01-09 Thread Nishanth Menon
On 14:26-20240109, Roger Quadros wrote:
> Enables configuration required for NAND in SPL and u-boot.
> 
> Enable MTD Driver model and MTD + UBI command line utilities.
> 
> Add mtdids/mtdparts for NAND as it is required for u-boot's
> MTD subsystem commands to recognize NAND partitions.
> 
> Add u-boot partition location.
> 
> Signed-off-by: Roger Quadros 
> ---
>  configs/am64x_evm_a53_defconfig | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
> index 05e35a8db6..e22153a958 100644
> --- a/configs/am64x_evm_a53_defconfig
> +++ b/configs/am64x_evm_a53_defconfig
> @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_MTD=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_TIME=y
>  CONFIG_CMD_PMIC=y
>  CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
> +CONFIG_CMD_UBI=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIST="k3-am642-evm k3-am642-sk"
> @@ -107,6 +112,9 @@ CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ADMA=y
>  CONFIG_SPL_MMC_SDHCI_ADMA=y
>  CONFIG_MMC_SDHCI_AM654=y
> +CONFIG_MTD=y
> +CONFIG_SPL_MTD=y
> +CONFIG_DM_MTD=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
> @@ -161,3 +169,27 @@ CONFIG_USB_GADGET_DOWNLOAD=y
>  CONFIG_USB_FUNCTION_MASS_STORAGE=y
>  CONFIG_SPL_DFU=y
>  CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> +CONFIG_MEMORY=y
> +CONFIG_SPL_MEMORY=y
> +CONFIG_TI_GPMC=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_NAND_OMAP_GPMC=y
> +CONFIG_CMD_NAND=y
> +CONFIG_NAND_OMAP_ELM=y
> +CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW=y
> +CONFIG_SYS_NAND_BLOCK_SIZE=0x4
> +CONFIG_SYS_NAND_ONFI_DETECTION=y
> +CONFIG_SYS_NAND_PAGE_SIZE=0x1000
> +CONFIG_SYS_NAND_PAGE_COUNT=0x40
> +CONFIG_SYS_NAND_OOBSIZE=0x100
> +CONFIG_SPL_NAND_SUPPORT=y
> +CONFIG_SPL_NAND_DRIVERS=y
> +CONFIG_SPL_NAND_BASE=y
> +CONFIG_SPL_NAND_IDENT=y
> +CONFIG_SPL_NAND_ECC=y
> +CONFIG_SYS_NAND_MAX_CHIPS=1
> +CONFIG_SYS_MAX_NAND_DEVICE=1
> +# CONFIG_SPL_NAND_AM33XX_BCH is not set
> +CONFIG_SPL_MTD_SUPPORT=y
> +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
> +CONFIG_SYS_NAND_U_BOOT_OFFS=0x60
> -- 
> 2.34.1
> 

Why not a config fragment?

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


Re: Please pull u-boot-samsung master

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 10:55:16AM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit 2f0282922b2c458eea7f85c500a948a587437b63:
> 
>   Prepare v2024.01-rc4 (2023-12-04 13:46:56 -0500)
> 
> are available in the git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master
> 
> for you to fetch changes up to 5631d20e2ef1008d55569790f79672ea8cc6894b:
> 
>   pinctrl: exynos: Convert to use livetree API for fdt access (2023-12-07
> 18:58:48 +0900)
> 
> 
> Sam Protsenko (7):
>   pinctrl: exynos: Improve coding style
>   pinctrl: exynos: Extract pin parsing code into a separate function
>   pinctrl: exynos: Rework pin_to_bank_base() to obtain data by name
>   pinctrl: exynos: Support different register types in pin banks
>   pinctrl: exynos: Refactor handling the pin related dt properties
>   pinctrl: exynos: Reduce variables scope
>   pinctrl: exynos: Convert to use livetree API for fdt access
> 
> Stefan Bosch (2):
>   common: board_f: change calculation of gd->mon_len to fix s5p4418
> reloc
>   arm: s5p4418: fix relocation of vectors

Taking just the pincttrl changes here (as I know this blocks other work)
I've taken that and I assume Stefan will fix microblaze shortly and then
his work can be picked up.

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request rng-2024-04-rc1

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 10:07:37AM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d:
> 
>   Merge tag 'u-boot-imx-master-20240108' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-01-08 13:39:43
> -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/rng-2024-04-rc1
> 
> for you to fetch changes up to 1351cd3b4b1b18cafa4893a44378ca6b1d091c8e:
> 
>   rng: detect RISC-V Zkr RNG device in bind method (2024-01-09 07:37:05
> +0100)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19241
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2 14/14] fastboot: fb_nand: add missing newlines in pr_err() macro

2024-01-09 Thread Alexey Romanov
pr_err() doesn't add an newline symbol when printing.

Signed-off-by: Alexey Romanov 
Reviewed-by: Sean Anderson 
Reviewed-by: Mattijs Korpershoek 
---
 drivers/fastboot/fb_nand.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
index 6d94bfdc45..6516c4ef29 100644
--- a/drivers/fastboot/fb_nand.c
+++ b/drivers/fastboot/fb_nand.c
@@ -49,13 +49,13 @@ static int fb_nand_lookup(const char *partname,
 
ret = find_dev_and_part(partname, , , part);
if (ret) {
-   pr_err("cannot find partition: '%s'", partname);
+   pr_err("cannot find partition: '%s'\n", partname);
fastboot_fail("cannot find partition", response);
return ret;
}
 
if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type != 
MTD_DEV_TYPE_SPINAND) {
-   pr_err("partition '%s' is not stored on a NAND device",
+   pr_err("partition '%s' is not stored on a NAND device\n",
  partname);
fastboot_fail("not a NAND device", response);
return -EINVAL;
@@ -179,7 +179,7 @@ void fastboot_nand_flash_write(const char *cmd, void 
*download_buffer,
 
ret = fb_nand_lookup(cmd, , , response);
if (ret) {
-   pr_err("invalid NAND device");
+   pr_err("invalid NAND device\n");
fastboot_fail("invalid NAND device", response);
return;
}
@@ -243,7 +243,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
 
ret = fb_nand_lookup(cmd, , , response);
if (ret) {
-   pr_err("invalid NAND device");
+   pr_err("invalid NAND device\n");
fastboot_fail("invalid NAND device", response);
return;
}
@@ -254,7 +254,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
 
ret = _fb_nand_erase(mtd, part);
if (ret) {
-   pr_err("failed erasing from device %s", mtd->name);
+   pr_err("failed erasing from device %s\n", mtd->name);
fastboot_fail("failed erasing from device", response);
return;
}
-- 
2.30.1



[PATCH v2 13/14] fastboot: enable FASTBOOT_FLASH option for SPI NAND devices

2024-01-09 Thread Alexey Romanov
>From now we can use FASTBOOT_FLASH_NAND option for SPI NAND.

Signed-off-by: Alexey Romanov 
Reviewed-by: Mattijs Korpershoek 
---
 drivers/fastboot/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 11fc0fe1c8..733dedb30d 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -87,7 +87,7 @@ config FASTBOOT_USB_DEV
 config FASTBOOT_FLASH
bool "Enable FASTBOOT FLASH command"
default y if ARCH_SUNXI || ARCH_ROCKCHIP
-   depends on MMC || (MTD_RAW_NAND && CMD_MTDPARTS)
+   depends on MMC || ((MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS)
select IMAGE_SPARSE
help
  The fastboot protocol includes a "flash" command for writing
@@ -113,7 +113,7 @@ config FASTBOOT_FLASH_MMC
 
 config FASTBOOT_FLASH_NAND
bool "FASTBOOT on NAND"
-   depends on MTD_RAW_NAND && CMD_MTDPARTS
+   depends on (MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS
 
 endchoice
 
-- 
2.30.1



[PATCH v2 12/14] fastboot: check device type for SPI NAND too

2024-01-09 Thread Alexey Romanov
SPI NAND devices also supports 'fastboot erase / flash' commands.

Signed-off-by: Alexey Romanov 
Reviewed-by: Sean Anderson 
Reviewed-by: Mattijs Korpershoek 
---
 drivers/fastboot/fb_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
index bbe26ddcc9..6d94bfdc45 100644
--- a/drivers/fastboot/fb_nand.c
+++ b/drivers/fastboot/fb_nand.c
@@ -54,7 +54,7 @@ static int fb_nand_lookup(const char *partname,
return ret;
}
 
-   if (dev->id->type != MTD_DEV_TYPE_NAND) {
+   if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type != 
MTD_DEV_TYPE_SPINAND) {
pr_err("partition '%s' is not stored on a NAND device",
  partname);
fastboot_fail("not a NAND device", response);
-- 
2.30.1



[PATCH v2 11/14] cmd: allow to enable CMD_NAND for SPI NAND devices

2024-01-09 Thread Alexey Romanov
Boards with SPI NAND also can use this command.

Signed-off-by: Alexey Romanov 
Reviewed-by: Sean Anderson 
---
 cmd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 26ad03..4332894184 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1381,7 +1381,7 @@ config CMD_MUX
 config CMD_NAND
bool "nand"
default y if NAND_SUNXI
-   depends on MTD_RAW_NAND
+   depends on MTD_RAW_NAND || MTD_SPI_NAND
help
  NAND support.
 
-- 
2.30.1



[PATCH v2 10/14] jffs2: use CMD_RET_FAILURE/SUCCESS defines

2024-01-09 Thread Alexey Romanov
Use CMD_RET_FAILURE and CMD_RET_SUCCESS defines instead
of 1 and 0.

Signed-off-by: Alexey Romanov 
---
 cmd/jffs2.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/cmd/jffs2.c b/cmd/jffs2.c
index 15bf8c0edf..d5aa9bcc7e 100644
--- a/cmd/jffs2.c
+++ b/cmd/jffs2.c
@@ -485,7 +485,7 @@ int do_jffs2_fsload(struct cmd_tbl *cmdtp, int flag, int 
argc,
 
/* make sure we are in sync with env variables */
if (mtdparts_init() !=0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
 
@@ -502,16 +502,16 @@ int do_jffs2_fsload(struct cmd_tbl *cmdtp, int flag, int 
argc,
 
if (size <= 0) {
printf("### %s LOAD ERROR<%x> for %s!\n", fsname, size, 
filename);
-   return 1;
+   return CMD_RET_FAILURE;
}
 
printf("### %s load complete: %d bytes loaded to 0x%lx\n",
fsname, size, offset);
env_set_hex("filesize", size);
 
-   return 0;
+   return CMD_RET_SUCCESS;
}
-   return 1;
+   return CMD_RET_FAILURE;
 }
 
 /**
@@ -535,7 +535,7 @@ int do_jffs2_ls(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 
/* make sure we are in sync with env variables */
if (mtdparts_init() !=0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
 
@@ -547,9 +547,9 @@ int do_jffs2_ls(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
ret = jffs2_1pass_ls(part, filename);
}
 
-   return ret ? 0 : 1;
+   return ret ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
}
-   return 1;
+   return CMD_RET_FAILURE;
 }
 
 /**
@@ -571,7 +571,7 @@ int do_jffs2_fsinfo(struct cmd_tbl *cmdtp, int flag, int 
argc,
 
/* make sure we are in sync with env variables */
if (mtdparts_init() !=0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
 
@@ -586,9 +586,9 @@ int do_jffs2_fsinfo(struct cmd_tbl *cmdtp, int flag, int 
argc,
ret = jffs2_1pass_info(part);
}
 
-   return ret ? 0 : 1;
+   return ret ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
}
-   return 1;
+   return CMD_RET_FAILURE;
 }
 
 /***/
-- 
2.30.1



[PATCH v2 09/14] jffs2: use negative error codes

2024-01-09 Thread Alexey Romanov
It is bad practice to use such error codes. Error codes
must be negative.

Signed-off-by: Alexey Romanov 
---
 cmd/jffs2.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/cmd/jffs2.c b/cmd/jffs2.c
index e00fcc2022..15bf8c0edf 100644
--- a/cmd/jffs2.c
+++ b/cmd/jffs2.c
@@ -151,7 +151,7 @@ extern int cramfs_info (struct part_info *info);
  * Check device number to be within valid range for given device type.
  *
  * @param dev device to validate
- * Return: 0 if device is valid, 1 otherwise
+ * Return: 0 if device is valid, -errno otherwise
  */
 static int mtd_device_validate(u8 type, u8 num, u32 *size)
 {
@@ -191,7 +191,7 @@ static int mtd_device_validate(u8 type, u8 num, u32 *size)
} else
printf("Unknown defice type %d\n", type);
 
-   return 1;
+   return -EINVAL;
 }
 
 /**
@@ -202,7 +202,7 @@ static int mtd_device_validate(u8 type, u8 num, u32 *size)
  * @param ret_id output pointer to next char after parse completes (output)
  * @param dev_type parsed device type (output)
  * @param dev_num parsed device number (output)
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -errno otherwise
  */
 static int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 
*dev_num)
 {
@@ -220,12 +220,12 @@ static int mtd_id_parse(const char *id, const char 
**ret_id, u8 *dev_type, u8 *d
p += 7;
} else {
printf("incorrect device type in %s\n", id);
-   return 1;
+   return -EINVAL;
}
 
if (!isdigit(*p)) {
printf("incorrect device number in %s\n", id);
-   return 1;
+   return -EINVAL;
}
 
*dev_num = simple_strtoul(p, (char **), 0);
@@ -328,7 +328,7 @@ static inline u32 get_part_sector_size(struct mtdids *id, 
struct part_info *part
  * 'Static' version of command line mtdparts_init() routine. Single partition 
on
  * a single device configuration.
  *
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -errno otherwise
  */
 int mtdparts_init(void)
 {
@@ -348,7 +348,7 @@ int mtdparts_init(void)
sizeof(struct mtdids));
if (!current_mtd_dev) {
printf("out of memory\n");
-   return 1;
+   return -ENOMEM;
}
memset(current_mtd_dev, 0, sizeof(struct mtd_device) +
   sizeof(struct part_info) + sizeof(struct mtdids));
@@ -365,7 +365,7 @@ int mtdparts_init(void)
(mtd_device_validate(id->type, id->num, ) 
!= 0)) {
printf("incorrect device: %s%d\n", 
MTD_DEV_TYPE(id->type), id->num);
free(current_mtd_dev);
-   return 1;
+   return -EINVAL;
}
id->size = size;
INIT_LIST_HEAD(>link);
@@ -500,15 +500,16 @@ int do_jffs2_fsload(struct cmd_tbl *cmdtp, int flag, int 
argc,
size = jffs2_1pass_load((char *)offset, part, filename);
}
 
-   if (size > 0) {
-   printf("### %s load complete: %d bytes loaded to 
0x%lx\n",
-   fsname, size, offset);
-   env_set_hex("filesize", size);
-   } else {
+   if (size <= 0) {
printf("### %s LOAD ERROR<%x> for %s!\n", fsname, size, 
filename);
+   return 1;
}
 
-   return !(size > 0);
+   printf("### %s load complete: %d bytes loaded to 0x%lx\n",
+   fsname, size, offset);
+   env_set_hex("filesize", size);
+
+   return 0;
}
return 1;
 }
-- 
2.30.1



[PATCH v2 07/14] mtdparts: use negative error codes

2024-01-09 Thread Alexey Romanov
It is bad practice to use such error codes. Error codes
must be negative.

Also, fastboot code expects that if successful, mtdparts
functions will return a value greater than 0. You can see
fastboot_nand_get_part_info() functions calls inside
getvar_get_part_info().

Signed-off-by: Alexey Romanov 
---
 cmd/mtdparts.c | 134 -
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index b31db73ebf..00c07014b2 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -299,7 +299,7 @@ static void current_save(void)
  * @param type mtd type
  * @param num mtd number
  * @param mtd a pointer to an mtd_info instance (output)
- * Return: 0 if device is valid, 1 otherwise
+ * Return: 0 if device is valid, -errno otherwise
  */
 static int get_mtd_info(u8 type, u8 num, struct mtd_info **mtd)
 {
@@ -309,7 +309,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info 
**mtd)
*mtd = get_mtd_device_nm(mtd_dev);
if (IS_ERR(*mtd)) {
printf("Device %s not found!\n", mtd_dev);
-   return 1;
+   return -ENODEV;
}
put_mtd_device(*mtd);
 
@@ -323,7 +323,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info 
**mtd)
  *
  * @param id of the parent device
  * @param part partition to validate
- * Return: 0 if partition is valid, 1 otherwise
+ * Return: 0 if partition is valid, -errno otherwise
  */
 static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
 {
@@ -333,7 +333,7 @@ static int part_validate_eraseblock(struct mtdids *id, 
struct part_info *part)
u64 offset, size;
 
if (get_mtd_info(id->type, id->num, ))
-   return 1;
+   return -EINVAL;
 
part->sector_size = mtd->erasesize;
 
@@ -347,14 +347,14 @@ static int part_validate_eraseblock(struct mtdids *id, 
struct part_info *part)
printf("%s%d: partition (%s) start offset"
   "alignment incorrect\n",
   MTD_DEV_TYPE(id->type), id->num, part->name);
-   return 1;
+   return -EINVAL;
}
 
size = part->size;
if (do_div(size, mtd->erasesize)) {
printf("%s%d: partition (%s) size alignment 
incorrect\n",
   MTD_DEV_TYPE(id->type), id->num, part->name);
-   return 1;
+   return -EINVAL;
}
} else {
/*
@@ -374,7 +374,7 @@ static int part_validate_eraseblock(struct mtdids *id, 
struct part_info *part)
 
printf("%s%d: partition (%s) start offset alignment 
incorrect\n",
   MTD_DEV_TYPE(id->type), id->num, part->name);
-   return 1;
+   return -EINVAL;
 
start_ok:
 
@@ -393,7 +393,7 @@ static int part_validate_eraseblock(struct mtdids *id, 
struct part_info *part)
 
printf("%s%d: partition (%s) size alignment incorrect\n",
   MTD_DEV_TYPE(id->type), id->num, part->name);
-   return 1;
+   return -EINVAL;
 
end_ok:
return 0;
@@ -410,7 +410,7 @@ static int part_validate_eraseblock(struct mtdids *id, 
struct part_info *part)
  *
  * @param id of the parent device
  * @param part partition to validate
- * Return: 0 if partition is valid, 1 otherwise
+ * Return: 0 if partition is valid, -errno otherwise
  */
 static int part_validate(struct mtdids *id, struct part_info *part)
 {
@@ -420,18 +420,18 @@ static int part_validate(struct mtdids *id, struct 
part_info *part)
if (part->offset > id->size) {
printf("%s: offset %08llx beyond flash size %08llx\n",
id->mtd_id, part->offset, id->size);
-   return 1;
+   return -EINVAL;
}
 
if ((part->offset + part->size) <= part->offset) {
printf("%s%d: partition (%s) size too big\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
-   return 1;
+   return -EINVAL;
}
 
if (part->offset + part->size > id->size) {
printf("%s: partitioning exceeds flash size\n", id->mtd_id);
-   return 1;
+   return -EINVAL;
}
 
/*
@@ -446,7 +446,7 @@ static int part_validate(struct mtdids *id, struct 
part_info *part)
  *
  * @param dev device to delete partition from
  * @param part partition to delete
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -ernno otherwise
  */
 static int part_del(struct mtd_device *dev, struct part_info *part)
 {
@@ -544,7 +544,7 @@ static int part_sort_add(struct mtd_device *dev, struct 
part_info *part)
/* be compliant with kernel cmdline, allow only one partition 
at offset zero */

[PATCH v2 08/14] mtdparts: use CMD_RET_FAILURE define

2024-01-09 Thread Alexey Romanov
Use 'return CMD_RET_FAILURE' define instead of 'return 1'.

Signed-off-by: Alexey Romanov 
---
 cmd/mtdparts.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index 00c07014b2..392ee511c9 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -1923,15 +1923,15 @@ static int do_chpart(struct cmd_tbl *cmdtp, int flag, 
int argc,
u8 pnum;
 
if (mtdparts_init() !=0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if (argc < 2) {
printf("no partition id specified\n");
-   return 1;
+   return CMD_RET_FAILURE;
}
 
if (find_dev_and_part(argv[1], , , ) != 0)
-   return 1;
+   return CMD_RET_FAILURE;
 
current_mtd_dev = dev;
current_mtd_partnum = pnum;
@@ -1978,7 +1978,7 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
/* make sure we are in sync with env variables */
if (mtdparts_init() != 0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if (argc == 1) {
list_partitions();
@@ -2000,11 +2000,11 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag, 
int argc,
struct part_info *p;
 
if (mtd_id_parse(argv[2], NULL, , ) != 0)
-   return 1;
+   return CMD_RET_FAILURE;
 
if ((id = id_find(type, num)) == NULL) {
printf("no such device %s defined in mtdids 
variable\n", argv[2]);
-   return 1;
+   return CMD_RET_FAILURE;
}
 
len = strlen(id->mtd_id) + 1;   /* 'mtd_id:' */
@@ -2015,7 +2015,7 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
if (len >= PART_ADD_DESC_MAXLEN) {
printf("too long partition description\n");
-   return 1;
+   return CMD_RET_FAILURE;
}
sprintf(tmpbuf, "%s:%s(%s)%s",
id->mtd_id, argv[3], argv[4], argv[5] ? argv[5] 
: "");
@@ -2031,7 +2031,7 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
 #if defined(CONFIG_CMD_MTDPARTS_SPREAD)
if (get_mtd_info(dev->id->type, dev->id->num, ))
-   return 1;
+   return CMD_RET_FAILURE;
 
if (!strcmp([1][3], ".spread")) {
spread_partition(mtd, p, _offset);
@@ -2045,12 +2045,12 @@ static int do_mtdparts(struct cmd_tbl *cmdtp, int flag, 
int argc,
} else if (part_add(dev_tmp, p) != 0) {
/* merge new partition with existing ones*/
device_del(dev);
-   return 1;
+   return CMD_RET_FAILURE;
}
 
if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
printf("generated mtdparts too long, resetting to 
null\n");
-   return 1;
+   return CMD_RET_FAILURE;
}
 
return 0;
-- 
2.30.1



[PATCH v2 06/14] spi: use nand_register() instead of add_mtd_device()

2024-01-09 Thread Alexey Romanov
Most functions that work with NAND device (for example fastboot),
use the get_nand_dev_by_index() function to work with NAND MTD.
In order to use this feature, SPI NAND must be registered via
nand_register().

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/nand/spi/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 07e521dbf5..2a3dbcfcb4 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -23,6 +23,7 @@
 #else
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1213,7 +1214,7 @@ static int spinand_probe(struct udevice *dev)
 #ifndef __UBOOT__
ret = mtd_device_register(mtd, NULL, 0);
 #else
-   ret = add_mtd_device(mtd);
+   ret = nand_register(0, mtd);
 #endif
if (ret)
goto err_spinand_cleanup;
-- 
2.30.1



[PATCH v2 05/14] spi: add board_nand_init() function

2024-01-09 Thread Alexey Romanov
By analogy with RAW NAND drivers, select SYS_NAND_SELF_INIT
option and implement board_nand_init() function. It will be
called from nand_init().

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/nand/spi/Kconfig |  1 +
 drivers/mtd/nand/spi/core.c  | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/mtd/nand/spi/Kconfig b/drivers/mtd/nand/spi/Kconfig
index 0777dfdf0a..c9ca76a1c9 100644
--- a/drivers/mtd/nand/spi/Kconfig
+++ b/drivers/mtd/nand/spi/Kconfig
@@ -2,6 +2,7 @@ menuconfig MTD_SPI_NAND
bool "SPI NAND device Support"
depends on DM_MTD && DM_SPI
select MTD_NAND_CORE
+   select SYS_NAND_SELF_INIT
select SPI_MEM
help
  This is the framework for the SPI NAND device drivers.
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 8ca33459f9..07e521dbf5 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1287,3 +1288,16 @@ U_BOOT_DRIVER(spinand) = {
.priv_auto  = sizeof(struct spinand_device),
.probe = spinand_probe,
 };
+
+void board_nand_init(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device_by_driver(UCLASS_SPI,
+ DM_DRIVER_GET(spinand),
+ );
+   if (ret && ret != -ENODEV)
+   log_err("Failed to initialize SPI NAND driver. (error %d)\n",
+   ret);
+}
-- 
2.30.1



[PATCH v2 04/14] nand: move nand_erase_opts() to core NAND folder

2024-01-09 Thread Alexey Romanov
Currently nand_erase_opts() placed in the nand/raw/ folder,
because it uses the RAW NAND specific API (struct nand_chip).
This patch move it to core NAND folder and make function generic,
for both RAW/SPI NAND's usage.

Also, nand_erase_opts() used in fastboot/fb_nand.c, cmd/nand.c
and env/nand.c code. This is also the reason why we should move
it to core folder and make it more general.

Signed-off-by: Alexey Romanov 
Reviewed-By: Michael Trimarchi 
---
 drivers/mtd/nand/raw/nand_util.c | 153 
 drivers/mtd/nand/util.c  | 166 +++
 2 files changed, 166 insertions(+), 153 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_util.c b/drivers/mtd/nand/raw/nand_util.c
index 9c18ce63b9..f7704d4697 100644
--- a/drivers/mtd/nand/raw/nand_util.c
+++ b/drivers/mtd/nand/raw/nand_util.c
@@ -32,159 +32,6 @@
 #include 
 #include 
 #include 
-#include 
-
-typedef struct erase_info  erase_info_t;
-
-/* support only for native endian JFFS2 */
-#define cpu_to_je16(x) (x)
-#define cpu_to_je32(x) (x)
-
-/**
- * nand_erase_opts: - erase NAND flash with support for various options
- *   (jffs2 formatting)
- *
- * @param mtd  nand mtd instance to erase
- * @param opts options,  @see struct nand_erase_options
- * Return: 0 in case of success
- *
- * This code is ported from flash_eraseall.c from Linux mtd utils by
- * Arcom Control System Ltd.
- */
-int nand_erase_opts(struct mtd_info *mtd,
-   const nand_erase_options_t *opts)
-{
-   struct jffs2_unknown_node cleanmarker;
-   erase_info_t erase;
-   unsigned long erase_length, erased_length; /* in blocks */
-   int result;
-   int percent_complete = -1;
-   const char *mtd_device = mtd->name;
-   struct mtd_oob_ops oob_opts;
-   struct nand_chip *chip = mtd_to_nand(mtd);
-
-   if ((opts->offset & (mtd->erasesize - 1)) != 0) {
-   printf("Attempt to erase non block-aligned data\n");
-   return -1;
-   }
-
-   memset(, 0, sizeof(erase));
-   memset(_opts, 0, sizeof(oob_opts));
-
-   erase.mtd = mtd;
-   erase.len = mtd->erasesize;
-   erase.addr = opts->offset;
-   erase_length = lldiv(opts->length + mtd->erasesize - 1,
-mtd->erasesize);
-
-   cleanmarker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK);
-   cleanmarker.nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER);
-   cleanmarker.totlen = cpu_to_je32(8);
-
-   /* scrub option allows to erase badblock. To prevent internal
-* check from erase() method, set block check method to dummy
-* and disable bad block table while erasing.
-*/
-   if (opts->scrub) {
-   erase.scrub = opts->scrub;
-   /*
-* We don't need the bad block table anymore...
-* after scrub, there are no bad blocks left!
-*/
-   if (chip->bbt) {
-   kfree(chip->bbt);
-   }
-   chip->bbt = NULL;
-   chip->options &= ~NAND_BBT_SCANNED;
-   }
-
-   for (erased_length = 0;
-erased_length < erase_length;
-erase.addr += mtd->erasesize) {
-
-   schedule();
-
-   if (opts->lim && (erase.addr >= (opts->offset + opts->lim))) {
-   puts("Size of erase exceeds limit\n");
-   return -EFBIG;
-   }
-   if (!opts->scrub) {
-   int ret = mtd_block_isbad(mtd, erase.addr);
-   if (ret > 0) {
-   if (!opts->quiet)
-   printf("\rSkipping %s at  "
-  "0x%08llx "
-  " \n",
-  ret == 1 ? "bad block" : "bbt 
reserved",
-  erase.addr);
-
-   if (!opts->spread)
-   erased_length++;
-
-   continue;
-
-   } else if (ret < 0) {
-   printf("\n%s: MTD get bad block failed: %d\n",
-  mtd_device,
-  ret);
-   return -1;
-   }
-   }
-
-   erased_length++;
-
-   result = mtd_erase(mtd, );
-   if (result != 0) {
-   printf("\n%s: MTD Erase failure: %d\n",
-  mtd_device, result);
-   continue;
-   }
-
-   /* format for JFFS2 ? */
-   if (opts->jffs2 && chip->ecc.layout->oobavail >= 8) {
-   struct mtd_oob_ops ops;
- 

[PATCH v2 03/14] nand: move nand_util.c to NAND core folder

2024-01-09 Thread Alexey Romanov
This is right place for this API. Now, fastboot code uses this
API: these functions should be available regardless of the
selected NAND type (RAW / SPI).

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/nand/Makefile|   2 +-
 drivers/mtd/nand/raw/nand_util.c | 511 -
 drivers/mtd/nand/util.c  | 543 +++
 3 files changed, 544 insertions(+), 512 deletions(-)
 create mode 100644 drivers/mtd/nand/util.c

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 96e186600a..301b1bceff 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
-nandcore-objs := core.o bbt.o
+nandcore-objs := core.o bbt.o util.o
 obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
 obj-$(CONFIG_MTD_RAW_NAND) += raw/
 obj-$(CONFIG_MTD_SPI_NAND) += spi/
diff --git a/drivers/mtd/nand/raw/nand_util.c b/drivers/mtd/nand/raw/nand_util.c
index 72cc24f403..9c18ce63b9 100644
--- a/drivers/mtd/nand/raw/nand_util.c
+++ b/drivers/mtd/nand/raw/nand_util.c
@@ -35,7 +35,6 @@
 #include 
 
 typedef struct erase_info  erase_info_t;
-typedef struct mtd_infomtd_info_t;
 
 /* support only for native endian JFFS2 */
 #define cpu_to_je16(x) (x)
@@ -395,513 +394,3 @@ int nand_unlock(struct mtd_info *mtd, loff_t start, 
size_t length,
return ret;
 }
 #endif
-
-/**
- * check_skip_len
- *
- * Check if there are any bad blocks, and whether length including bad
- * blocks fits into device
- *
- * @param mtd nand mtd instance
- * @param offset offset in flash
- * @param length image length
- * @param used length of flash needed for the requested length
- * Return: 0 if the image fits and there are no bad blocks
- * 1 if the image fits, but there are bad blocks
- *-1 if the image does not fit
- */
-static int check_skip_len(struct mtd_info *mtd, loff_t offset, size_t length,
- size_t *used)
-{
-   size_t len_excl_bad = 0;
-   int ret = 0;
-
-   while (len_excl_bad < length) {
-   size_t block_len, block_off;
-   loff_t block_start;
-
-   if (offset >= mtd->size)
-   return -1;
-
-   block_start = offset & ~(loff_t)(mtd->erasesize - 1);
-   block_off = offset & (mtd->erasesize - 1);
-   block_len = mtd->erasesize - block_off;
-
-   if (!nand_block_isbad(mtd, block_start))
-   len_excl_bad += block_len;
-   else
-   ret = 1;
-
-   offset += block_len;
-   *used += block_len;
-   }
-
-   /* If the length is not a multiple of block_len, adjust. */
-   if (len_excl_bad > length)
-   *used -= (len_excl_bad - length);
-
-   return ret;
-}
-
-#ifdef CONFIG_CMD_NAND_TRIMFFS
-static size_t drop_ffs(const struct mtd_info *mtd, const u_char *buf,
-   const size_t *len)
-{
-   size_t l = *len;
-   ssize_t i;
-
-   for (i = l - 1; i >= 0; i--)
-   if (buf[i] != 0xFF)
-   break;
-
-   /* The resulting length must be aligned to the minimum flash I/O size */
-   l = i + 1;
-   l = (l + mtd->writesize - 1) / mtd->writesize;
-   l *=  mtd->writesize;
-
-   /*
-* since the input length may be unaligned, prevent access past the end
-* of the buffer
-*/
-   return min(l, *len);
-}
-#endif
-
-/**
- * nand_verify_page_oob:
- *
- * Verify a page of NAND flash, including the OOB.
- * Reads page of NAND and verifies the contents and OOB against the
- * values in ops.
- *
- * @param mtd  nand mtd instance
- * @param ops  MTD operations, including data to verify
- * @param ofs  offset in flash
- * Return: 0 in case of success
- */
-int nand_verify_page_oob(struct mtd_info *mtd, struct mtd_oob_ops *ops,
-loff_t ofs)
-{
-   int rval;
-   struct mtd_oob_ops vops;
-   size_t verlen = mtd->writesize + mtd->oobsize;
-
-   memcpy(, ops, sizeof(vops));
-
-   vops.datbuf = memalign(ARCH_DMA_MINALIGN, verlen);
-
-   if (!vops.datbuf)
-   return -ENOMEM;
-
-   vops.oobbuf = vops.datbuf + mtd->writesize;
-
-   rval = mtd_read_oob(mtd, ofs, );
-   if (!rval)
-   rval = memcmp(ops->datbuf, vops.datbuf, vops.len);
-   if (!rval)
-   rval = memcmp(ops->oobbuf, vops.oobbuf, vops.ooblen);
-
-   free(vops.datbuf);
-
-   return rval ? -EIO : 0;
-}
-
-/**
- * nand_verify:
- *
- * Verify a region of NAND flash.
- * Reads NAND in page-sized chunks and verifies the contents against
- * the contents of a buffer.  The offset into the NAND must be
- * page-aligned, and the function doesn't handle skipping bad blocks.
- *
- * @param mtd  nand mtd instance
- * @param ofs  offset 

[PATCH v2 02/14] nand: don't overwrite mtd name in nand_register()

2024-01-09 Thread Alexey Romanov
We use this function in SPI NAND subsystem, which already
filled mtd->name field with "spi-nand0" string.

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/nand/core.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index f792ef844a..f67421f0cb 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -23,7 +23,7 @@
 int nand_curr_device = -1;
 
 static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
-static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][16];
 static unsigned long total_nand_size; /* in kiB */
 
 /**
@@ -289,8 +289,12 @@ int nand_register(int devnum, struct mtd_info *mtd)
 
nand_info[devnum] = mtd;
 
-   sprintf(dev_name[devnum], "nand%d", devnum);
-   mtd->name = dev_name[devnum];
+   if (!strlen(mtd->name)) {
+   snprintf(dev_name[devnum], ARRAY_SIZE(dev_name[devnum]), 
"nand%d", devnum);
+   mtd->name = dev_name[devnum];
+   } else {
+   strlcpy(dev_name[devnum], mtd->name, 
ARRAY_SIZE(dev_name[devnum]));
+   }
 
 #ifdef CONFIG_MTD
/*
-- 
2.30.1



[PATCH v2 01/14] nand: move NAND initialization API to nand/core.c

2024-01-09 Thread Alexey Romanov
nand_register() and nand_init() is generic API for both
RAW and SPI NAND's. We have to move this functions
from drivers/mtd/nand/raw/nand.c to drivers/mtd/nand/core.c.

Functions designed to work with RAW NAND should remain
in drivers/mtd/nand/raw/nand.c.

Signed-off-by: Alexey Romanov 
---
 drivers/mtd/Kconfig  |   2 +-
 drivers/mtd/nand/Kconfig |  10 ++
 drivers/mtd/nand/core.c  | 189 +++
 drivers/mtd/nand/raw/Kconfig |  10 --
 drivers/mtd/nand/raw/nand.c  | 182 -
 include/nand.h   |   2 +
 6 files changed, 202 insertions(+), 193 deletions(-)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c56840c849..1902351719 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -260,7 +260,7 @@ config SYS_NAND_MAX_ECCPOS
 
 config SYS_NAND_MAX_CHIPS
int "NAND max chips"
-   depends on MTD_RAW_NAND || CMD_ONENAND || TARGET_S5PC210_UNIVERSAL || \
+   depends on MTD_RAW_NAND || MTD_SPI_NAND || CMD_ONENAND || 
TARGET_S5PC210_UNIVERSAL || \
SPL_OMAP3_ID_NAND
default 1
help
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 78ae04bdcb..9a1d4ac0dc 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -1,6 +1,16 @@
 config MTD_NAND_CORE
tristate
 
+config SYS_MAX_NAND_DEVICE
+   int "Maximum number of NAND devices to support"
+   default 1
+
+config SYS_NAND_SELF_INIT
+   bool
+   help
+ This option, if enabled, provides more flexible and linux-like
+ NAND initialization process.
+
 source "drivers/mtd/nand/raw/Kconfig"
 
 source "drivers/mtd/nand/spi/Kconfig"
diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index f6d9c584f7..f792ef844a 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -10,6 +10,7 @@
 #define pr_fmt(fmt)"nand: " fmt
 
 #include 
+#include 
 #include 
 #ifndef __UBOOT__
 #include 
@@ -19,6 +20,12 @@
 #include 
 #include 
 
+int nand_curr_device = -1;
+
+static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+static unsigned long total_nand_size; /* in kiB */
+
 /**
  * nanddev_isbad() - Check if a block is bad
  * @nand: NAND device
@@ -251,6 +258,188 @@ void nanddev_cleanup(struct nand_device *nand)
 }
 EXPORT_SYMBOL_GPL(nanddev_cleanup);
 
+struct mtd_info *get_nand_dev_by_index(int dev)
+{
+   if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE || !nand_info[dev] ||
+   !nand_info[dev]->name)
+   return NULL;
+
+   return nand_info[dev];
+}
+EXPORT_SYMBOL_GPL(get_nand_dev_by_index);
+
+int nand_mtd_to_devnum(struct mtd_info *mtd)
+{
+   int i;
+
+   for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
+   if (mtd && get_nand_dev_by_index(i) == mtd)
+   return i;
+   }
+
+   return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(nand_mtd_to_devnum);
+
+/* Register an initialized NAND mtd device with the U-Boot NAND command. */
+int nand_register(int devnum, struct mtd_info *mtd)
+{
+   if (devnum >= CONFIG_SYS_MAX_NAND_DEVICE)
+   return -EINVAL;
+
+   nand_info[devnum] = mtd;
+
+   sprintf(dev_name[devnum], "nand%d", devnum);
+   mtd->name = dev_name[devnum];
+
+#ifdef CONFIG_MTD
+   /*
+* Add MTD device so that we can reference it later
+* via the mtdcore infrastructure (e.g. ubi).
+*/
+   add_mtd_device(mtd);
+#endif
+
+   total_nand_size += mtd->size / 1024;
+
+   if (nand_curr_device == -1)
+   nand_curr_device = devnum;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(nand_register);
+
+void nand_unregister(struct mtd_info *mtd)
+{
+   int devnum = nand_mtd_to_devnum(mtd);
+
+   if (devnum < 0)
+   return;
+
+   if (nand_curr_device == devnum)
+   nand_curr_device = -1;
+
+   total_nand_size -= mtd->size / 1024;
+
+   del_mtd_device(nand_info[devnum]);
+
+   nand_info[devnum] = NULL;
+}
+EXPORT_SYMBOL(nand_unregister);
+
+#ifdef CONFIG_MTD_CONCAT
+struct mtd_info *concat_mtd;
+
+static void create_mtd_concat(void)
+{
+   struct mtd_info *nand_info_list[CONFIG_SYS_MAX_NAND_DEVICE];
+   int nand_devices_found = 0;
+   int i;
+
+   for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
+   struct mtd_info *mtd = get_nand_dev_by_index(i);
+   if (mtd != NULL) {
+   nand_info_list[nand_devices_found] = mtd;
+   nand_devices_found++;
+   }
+   }
+   if (nand_devices_found > 1) {
+   char c_mtd_name[16];
+
+   /*
+* We detected multiple devices. Concatenate them together.
+*/
+   sprintf(c_mtd_name, "nand%d", nand_devices_found);
+   concat_mtd = mtd_concat_create(nand_info_list,
+  

[PATCH v2 00/14] Support SPI NAND in fastboot protocol

2024-01-09 Thread Alexey Romanov
Currently, fastboot in U-Boot doens't support SPI NAND
devices. This patchset adds support for SPI NAND in fastboot
nand subsystem.

Changes V1 -> V2:

- Rebase patchset over u-boot/next.
- Move nand_unregister(), nand_reinit() and nang_page_size() functions
  to NAND core folder too.
- Move changes about CMD_RET_FAILURE/SUCCESS into separate patches.

Alexey Romanov (14):
  nand: move NAND initialization API to nand/core.c
  nand: don't overwrite mtd name in nand_register()
  nand: move nand_util.c to NAND core folder
  nand: move nand_erase_opts() to core NAND folder
  spi: add board_nand_init() function
  spi: use nand_register() instead of add_mtd_device()
  mtdparts: use negative error codes
  mtdparts: use CMD_RET_FAILURE define
  jffs2: use negative error codes
  jffs2: use CMD_RET_FAILURE/SUCCESS defines
  cmd: allow to enable CMD_NAND for SPI NAND devices
  fastboot: check device type for SPI NAND too
  fastboot: enable FASTBOOT_FLASH option for SPI NAND devices
  fastboot: fb_nand: add missing newlines in pr_err() macro

 cmd/Kconfig  |   2 +-
 cmd/jffs2.c  |  45 +-
 cmd/mtdparts.c   | 154 +++
 drivers/fastboot/Kconfig |   4 +-
 drivers/fastboot/fb_nand.c   |  12 +-
 drivers/mtd/Kconfig  |   2 +-
 drivers/mtd/nand/Kconfig |  10 +
 drivers/mtd/nand/Makefile|   2 +-
 drivers/mtd/nand/core.c  | 193 +
 drivers/mtd/nand/raw/Kconfig |  10 -
 drivers/mtd/nand/raw/nand.c  | 182 
 drivers/mtd/nand/raw/nand_util.c | 664 -
 drivers/mtd/nand/spi/Kconfig |   1 +
 drivers/mtd/nand/spi/core.c  |  17 +-
 drivers/mtd/nand/util.c  | 709 +++
 include/nand.h   |   2 +
 16 files changed, 1042 insertions(+), 967 deletions(-)
 create mode 100644 drivers/mtd/nand/util.c

-- 
2.30.1



Re: [PATCH v3 0/8] Suspend to RAM support for K3 J7200

2024-01-09 Thread Andrew Davis

On 1/8/24 10:56 AM, Thomas Richard wrote:

This series is the U-Boot part of the work to add the suspend to RAM
support for the K3 J7200 EVM board.

During the boot R5 SPL makes a copy of DM-Firmware and TF-A in memory.
Resume detection is done by reading a magic value in a pmic register
(set by DM-Firmware).

If a resume is detected, R5 SPL run the exit retention sequence of the
DDR. Then it load TF-A and DM-Firmware using the copies done during the boot
(fit image processing is skipped).
Before to start TF-A, R5 SPL writes a magic value in scratchpad ram. This
will be used by TF-A to detect that the board is resuming.

The copy of TF-A/DM-Firmware, the SPL stack and malloc are located in a
reserved memory region (for the kernel point of view) to avoid any
memory corruption.

This version is mostly to test the firewall protection with the suspend
to ram.


Seems to show the opposite, if you are able to access and load TF-A
back to its spot after resume from un-trusted SPL then the firewall
did not survive suspend to RAM. That is a huge security gap if TIFS
is forgetting to put back the firewalls on resume.. What is the
point of firewalls on these systems if I can just knock them all
out by doing a simple suspend/resume cycle?


Some comments (for the v2) were not fixed in this version.


Why not?


This series has been tested with the series [1] to enable the firewall.
At the end of the resume sequence, TF-A is well protected by the
firewall, but OP-TEE remains unprotected.



Then why post this? If it is just to get some eyes on it, then label
it as an "RFC" so our silence isn't considered acceptance, otherwise we
have to manually NAK these each time.

Andrew


[1] 
https://lore.kernel.org/all/20231229-binman-firewalling-v7-0-47ed4af30...@ti.com/


Changes in v3:
- At resume, R5 SPL doesn't restore TF-A anymore.
   TF-A is started like during a cold boot. R5 SPL will notify that the board is
   resuming using a magic value written in the scratchpad ram.
   TF-A will restore itself.
- Link to v2:
   
https://lore.kernel.org/u-boot/20231107161802.855154-1-thomas.rich...@bootlin.com/

Changes in v2:
- Set exit retention code for DDR behind CONFIG_K3_J721E_DDRSS
- Check if TF-A is running in DRAM, if yes no need to restore it
- Remove BL31_START macro, and get TF-A start address from the fit image
- Remove the test_enter_suspend command
- Link to v1:
   
https://lore.kernel.org/u-boot/20231016141135.325698-1-thomas.rich...@bootlin.com/

Gowtham Tammana (1):
   DO NOT MERGE: arm: dts: k3-j7200-r5-common: Add pmic node for esm

Gregory CLEMENT (2):
   configs: j7200_evm_r5: Used reserved memory in DDR for stack
   configs: j7200_evm_r5: Move address used for allocation in the
 reserved space

Thomas Richard (5):
   board: ti: j721e: Add resume detection for J7200
   ram: k3-ddrss: Add exit retention support
   board: ti: j721e: Add the missing part of exit retention for k3-ddrss
 (J7200)
   board: ti: j721e: During resume spl notify tf-a that the board is
 resuming
   arm: mach-k3: j7200: Skip fit processing when resuming

  .../arm/dts/k3-j7200-r5-common-proc-board.dts |  17 +-
  arch/arm/mach-k3/common.c |  65 +++-
  .../arm/mach-k3/include/mach/j721e_hardware.h |   1 +
  arch/arm/mach-k3/include/mach/j721e_spl.h |  30 ++
  arch/arm/mach-k3/sysfw-loader.c   |  16 +-
  board/ti/j721e/evm.c  |  77 +
  configs/j7200_evm_r5_defconfig|   4 +-
  drivers/ram/k3-ddrss/k3-ddrss.c   | 307 ++
  8 files changed, 507 insertions(+), 10 deletions(-)



Pull request smbios-2024-04-rc1

2024-01-09 Thread Heinrich Schuchardt

The following changes since commit c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d:

  Merge tag 'u-boot-imx-master-20240108' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-01-08 13:39:43
-0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/smbios-2024-04-rc1

for you to fetch changes up to 8aec7031112eba0dbfc8f23f9be11c081ea5cc56:

  efi_loader: provide tool to dump SMBIOS table (2024-01-09 10:09:15 +0100)


Pull request smbios-2024-04-rc1

* make table_compute_checksum() arguments const
* remove duplicate function verify_checksum()
* enable setting processor family > 0xff
* set correct SMBIOS processor family value for RISC-V
* avoid importing ofnode.h in smbios.h
* provide a UEFI tool to dump SMBIOS table


Heinrich Schuchardt (6):
  lib: make table_compute_checksum() arguments const
  lib: smbios: verify_checksum() is duplicate
  smbios: enable setting processor family > 0xff
  cpu: riscv: set correct SMBIOS processor family value
  smbios: smbios.h should not import ofnode.h
  efi_loader: provide tool to dump SMBIOS table

 drivers/cpu/riscv_cpu.c |   4 +
 include/smbios.h|   6 +-
 include/tables_csum.h   |   2 +-
 lib/efi_loader/Makefile |   7 +
 lib/efi_loader/efi_smbios.c |   3 +
 lib/efi_loader/smbiosdump.c | 622

 lib/smbios-parser.c |  21 +-
 lib/smbios.c|   4 +-
 lib/tables_csum.c   |   4 +-
 9 files changed, 647 insertions(+), 26 deletions(-)
 create mode 100644 lib/efi_loader/smbiosdump.c


Re: [PATCH 06/10] board: ti: j721e: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
On 18:20-20240109, Roger Quadros wrote:
> 
> 
> On 08/01/2024 19:32, Nishanth Menon wrote:
> > We now can provide a map and have the standard fdtfile variable set from
> > code itself. This allows for bootstd to "just work".
> > 
> > While at this, replace findfdt in environment with a warning as it is no
> > longer needed.
> > 
> > Signed-off-by: Nishanth Menon 
> > ---
> >  board/ti/j721e/evm.c |  8 
> >  board/ti/j721e/j721e.env | 10 --
> >  2 files changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
> > index c541880107ec..ad6ef4553e04 100644
> > --- a/board/ti/j721e/evm.c
> > +++ b/board/ti/j721e/evm.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  
> >  #include "../common/board_detect.h"
> > +#include "../common/fdt_ops.h"
> >  
> >  #define board_is_j721e_som()   (board_ti_k3_is("J721EX-PM1-SOM") || \
> >  board_ti_k3_is("J721EX-PM2-SOM"))
> > @@ -424,6 +425,12 @@ void configure_serdes_sierra(void)
> >  }
> >  
> >  #ifdef CONFIG_BOARD_LATE_INIT
> > +static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
> > +   {"j721e", "k3-j721e-common-proc-board.dtb"},
> > +   {"j721e-sk", "k3-j721e-sk.dtb"},
> 
> You missed "j721e-eaik"

Nope, it is intentional - eaik (the older name) is handled as sk in
setup_board_eeprom_env board_name[1] ==> board_is_j721e_sk  provides
that abstraction[2]


[1] https://github.com/u-boot/u-boot/blob/master/board/ti/j721e/evm.c#L427
[2] https://github.com/u-boot/u-boot/blob/master/board/ti/j721e/evm.c#L23
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D


Re: [PATCH 06/10] board: ti: j721e: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Roger Quadros



On 08/01/2024 19:32, Nishanth Menon wrote:
> We now can provide a map and have the standard fdtfile variable set from
> code itself. This allows for bootstd to "just work".
> 
> While at this, replace findfdt in environment with a warning as it is no
> longer needed.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  board/ti/j721e/evm.c |  8 
>  board/ti/j721e/j721e.env | 10 --
>  2 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
> index c541880107ec..ad6ef4553e04 100644
> --- a/board/ti/j721e/evm.c
> +++ b/board/ti/j721e/evm.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include "../common/board_detect.h"
> +#include "../common/fdt_ops.h"
>  
>  #define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
>board_ti_k3_is("J721EX-PM2-SOM"))
> @@ -424,6 +425,12 @@ void configure_serdes_sierra(void)
>  }
>  
>  #ifdef CONFIG_BOARD_LATE_INIT
> +static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
> + {"j721e", "k3-j721e-common-proc-board.dtb"},
> + {"j721e-sk", "k3-j721e-sk.dtb"},

You missed "j721e-eaik"

> + {"j7200", "k3-j7200-common-proc-board.dtb"},
> + { /* Sentinel. */ }
> +};
>  static void setup_board_eeprom_env(void)
>  {
>   char *name = "j721e";
> @@ -443,6 +450,7 @@ static void setup_board_eeprom_env(void)
>  
>  invalid_eeprom:
>   set_board_info_env_am6(name);
> + ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
>  }
>  
>  static void setup_serial(void)
> diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
> index cb27bf5e2b24..38bfd7d49634 100644
> --- a/board/ti/j721e/j721e.env
> +++ b/board/ti/j721e/j721e.env
> @@ -7,16 +7,6 @@
>  #include 
>  #endif
>  
> -default_device_tree=ti/k3-j721e-common-proc-board.dtb
> -findfdt=
> - setenv name_fdt ${default_device_tree};
> - if test $board_name = j721e; then
> - setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
> - if test $board_name = j7200; then
> - setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
> - if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
> - setenv name_fdt ti/k3-j721e-sk.dtb; fi;
> - setenv fdtfile ${name_fdt}
>  name_kern=Image
>  console=ttyS2,115200n8
>  args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280

-- 
cheers,
-roger


Re: [PATCH v3 0/8] Suspend to RAM support for K3 J7200

2024-01-09 Thread Nishanth Menon
On 17:56-20240108, Thomas Richard wrote:
> This series is the U-Boot part of the work to add the suspend to RAM
> support for the K3 J7200 EVM board.
> 
> During the boot R5 SPL makes a copy of DM-Firmware and TF-A in memory.
> Resume detection is done by reading a magic value in a pmic register
> (set by DM-Firmware).
> 
> If a resume is detected, R5 SPL run the exit retention sequence of the
> DDR. Then it load TF-A and DM-Firmware using the copies done during the boot
> (fit image processing is skipped).
> Before to start TF-A, R5 SPL writes a magic value in scratchpad ram. This
> will be used by TF-A to detect that the board is resuming.
> 
> The copy of TF-A/DM-Firmware, the SPL stack and malloc are located in a
> reserved memory region (for the kernel point of view) to avoid any
> memory corruption.
> 
> This version is mostly to test the firewall protection with the suspend
> to ram.
> Some comments (for the v2) were not fixed in this version.
> This series has been tested with the series [1] to enable the firewall.
> At the end of the resume sequence, TF-A is well protected by the
> firewall, but OP-TEE remains unprotected.
> 
> [1] 
> https://lore.kernel.org/all/20231229-binman-firewalling-v7-0-47ed4af30...@ti.com/
> 
> 

And as usual, as I have already responded on 
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/25120

My objection to this series mirrors what I have mentioned previously for
TFA as well - I am looking for some common sequence to be defined
between am62x and J7200 family rather than each go completely
tangentially, until that happens, please consider my standing NAK.

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


Re: Please pull u-boot-samsung master

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 10:55:16AM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit 2f0282922b2c458eea7f85c500a948a587437b63:
> 
>   Prepare v2024.01-rc4 (2023-12-04 13:46:56 -0500)
> 
> are available in the git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master
> 
> for you to fetch changes up to 5631d20e2ef1008d55569790f79672ea8cc6894b:
> 
>   pinctrl: exynos: Convert to use livetree API for fdt access (2023-12-07
> 18:58:48 +0900)
> 

The change:
commit 411094b8afd9553eb34efed258c64bc39b578149
Author: Stefan Bosch 
Date:   Mon Nov 27 18:26:08 2023 +

common: board_f: change calculation of gd->mon_len to fix s5p4418 reloc

No longer builds for microblaze.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1] fastboot: introduce 'oem board' subcommand

2024-01-09 Thread Sean Anderson
On 1/9/24 05:27, Alexey Romanov wrote:
> Hello Sean!
> 
> Thanks for you reply.
> 
> On Thu, Dec 28, 2023 at 11:45:04AM -0500, Sean Anderson wrote:
>> On 12/28/23 10:25, Alexey Romanov wrote:
>> > Currently, fastboot protocol in U-Boot has no opportunity
>> > to execute vendor custom code with verifed boot.
>> 
>> Well, I would say the most conventional way to do this would be something 
>> like
>> 
>> => fastboot 0
>> => source \# CONFIG_FASTBOOT_BUF_ADDR
>> 
>> and on your host machine,
>> 
>> $ fastboot stage my_script.itb
>> 
>> where my_script.its looks like
>> 
>> /dts-v1/;
>> 
>> / {
>> description = "my script";
>> #address-cells = <1>;
>> 
>> images {
>> my-script {
>> data = /incbin/("my_script.scr");
>> type = "script";
>> arch = "arm64";
>> compression = "none";
>> hash-1 {
>> algo = "sha256";
>> };
>> };
>> };
>> 
>> configurations {
>> default = "conf";
>> conf {
>> description = "Load my script";
>> script = "my-script";
>> signature {
>> algo = "sha256,rsa2048";
>> key-name-hint = "vboot";
>> sign-images = "script";
>> };
>> };
>> };
>> };
>> 
>> This method is especially useful to pass complex parameters to your command.
>> This method of course requires commit bcc85b96b5f ("cmd: source: Support
>> specifying config name").
>> 
>> Would it be possible to use the above method for your use case?
> 
> This method sounds good for some cases, but we have encountered some
> problems that prevent us from applying it:
> 
> 1. Looks like this method requires access to UART (for typing 'source'
> command). Open the UART is unsafe at devices with verified boot.

Generally the idea is that you run source after you run fastboot. E.g. you set
your altbootcmd (or whatever) to something like

while true; fastboot 0; source \# || boot; done

so you try to source whatever gets staged, and boot it otherwise.

> 2. We use automation scripts to flash our devices using fastboot
> protocol. A typical example of flashing scripts (device is already in
> fastboot mode):
> 
>   $ fastboot erase bootloader
>   $ fastboot stage bootloader.img
>   $ fastboot oem board:write_bootloader
> 
>   $ fastboot reboot-bootloader
> 
>   $ fastboot erase super
>   $ fastboot flash super super.bin
> 
>   $ fastboot reboot
> 
> This method doesn't assume what something typing additional command in
> U-Boot shell, even if we have access to UART.

I'm curious what you actual usage for this is? That is, what do you need
a custom command for.

--Sean

>> 
>> --Sean
>> 
>> > This patch
>> > introduce new fastboot subcommand fastboot oem board:,
>> > which allow to run custom oem_board function.
>> > =
>> > Default implementation is __weak. Vendor must redefine it in
>> > board/ folder with his own logic.
>> > 
>> > For example, some vendors have their custom nand/emmc partition
>> > flashing or erasing. Here some typical command for such use cases:
>> > 
>> > - flashing:
>> > 
>> >   $ fastboot stage bootloader.img
>> >   $ fastboot oem board:write_bootloader
>> > 
>> > - erasing:
>> > 
>> >   $ fastboot oem board:erase_env
>> > 
>> > Signed-off-by: Alexey Romanov 
>> > ---
>> >  drivers/fastboot/Kconfig  |  7 +++
>> >  drivers/fastboot/fb_command.c | 15 +++
>> >  include/fastboot.h|  1 +
>> >  3 files changed, 23 insertions(+)
>> > 
>> > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
>> > index 3cfeea4837..4c955cabab 100644
>> > --- a/drivers/fastboot/Kconfig
>> > +++ b/drivers/fastboot/Kconfig
>> > @@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
>> >  this feature if you are using verified boot, as it will allow an
>> >  attacker to bypass any restrictions you have in place.
>> >  
>> > +config FASTBOOT_OEM_BOARD
>> > +  bool "Enable the 'oem board' command"
>> > +  help
>> > +This extends the fastboot protocol with an "oem board" command. This
>> > +command allows running vendor custom code defined in board/ files.
>> > +Otherwise, it will do nothing and send fastboot fail.
>> > +
>> >  endif # FASTBOOT
>> >  
>> >  endmenu
>> > diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
>> > index 71cfaec6e9..4d2b451f46 100644
>> > --- a/drivers/fastboot/fb_command.c
>> > +++ b/drivers/fastboot/fb_command.c
>> > @@ -39,6 +39,7 @@ static void reboot_recovery(char *, char *);
>> >  static void oem_format(char *, char *);
>> >  static void oem_partconf(char *, char *);
>> >  static void oem_bootbus(char *, char *);
>> > +static void oem_board(char *, char *);
>> >  static void run_ucmd(char *, char *);
>> >  static void run_acmd(char *, char *);
>> >  
>> > @@ -106,6 +107,10 @@ static const struct {
>> >.command = "oem run",
>> >.dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd), 

Re: [PATCH v7 0/7] Implement fastboot multiresponce

2024-01-09 Thread Mattijs Korpershoek
Hi,

On Fri, 05 Jan 2024 09:22:05 +0200, Svyatoslav Ryhel wrote:
> Currently u-boot fastboot can only send one message back to host,
> so if there is a need to print more than one line messages must be
> kept sending until all the required data is obtained. This behavior
> can be adjusted using multiresponce ability (getting multiple lines
> of response) proposed in this patch set.
> 
> Implementation of multiresponce leads to ability to dump content of
> console buffer which, with use of "oem run", allows to entirely avoid
> need in UART.
> 
> [...]

Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu 
(u-boot-dfu)

[1/7] fastboot: multiresponse support
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/85fcd69dc2c03025648a1b1b511c1f10abf87c1e
[2/7] fastboot: implement "getvar all"
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/475aa9aabee7ab472341d755cc339f1345d5f49e
[3/7] common: console: introduce console_record_isempty helper
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/9ce75f49127858d1aa36d455a869137e4d36681b
[4/7] common: console: record console from the beginning
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/90087dd076d42c196de3506b6fa4d052f0869670
[5/7] lib: membuff: fix readline not returning line in case of overflow
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/e58bafc35fe37491bb3546299593dcc054145adb
[6/7] fastboot: add oem console command support
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/16f79dd4cd624de0ee336dfeeac6db954f99ae68
[7/7] test: hush: dollar: fix bagous behavior
  
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/6c2f753f4ad3dcee60190949d1286736a6d51d17

--
Mattijs


Re: [PATCH v3 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function

2024-01-09 Thread Stefan Roese

Hi Robert,

On 1/9/24 14:16, Robert Marko wrote:

On Wed, Nov 29, 2023 at 11:11 AM Robert Marko  wrote:


Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
which makes it hard to add support for any other board to be fixed up.

So, lets just move the FDT fixup code to a separate function and call it
if compatible matches, there should be no functional change.

Signed-off-by: Robert Marko 
Reviewed-by: Stefan Roese 



Hi Stefan,
Since 2024.01 was released, can this series be pulled in now?


It's on my list. I actually already started with some CI build tests.
Hope to get this done by end of this week, before I leave for a
short vacation.

Thanks,
Stefan


Regards,
Robert



---
  board/Marvell/mvebu_armada-37xx/board.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 04124d8014..1471caa9a6 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
  #endif

  #ifdef CONFIG_OF_BOARD_SETUP
-int ft_board_setup(void *blob, struct bd_info *bd)
+static int espressobin_fdt_setup(void *blob)
  {
-#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
 int ret;
 int spi_off;
 int parts_off;
 int part_off;

 /* Fill SPI MTD partitions for Linux kernel on Espressobin */
-   if (!of_machine_is_compatible("globalscale,espressobin"))
-   return 0;
-
 spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
 if (spi_off < 0)
 return 0;
@@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 return 0;
 }

+   return 0;
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+   if (of_machine_is_compatible("globalscale,espressobin"))
+   return espressobin_fdt_setup(blob);
  #endif
 return 0;
  }
--
2.43.0






Viele Grüße,
Stefan Roese

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


Re: [PATCH] doc: fix three-dash references in reStructuredText

2024-01-09 Thread Mattijs Korpershoek
Hi Grzegorz,

Thank you for the patch.

On sam., janv. 06, 2024 at 11:36, Grzegorz Szymaszek  
wrote:

> The "Sending patches" and "Patman patch manager" documents refer to the
> three-dash, "---", that separates patch parts. The symbol is written in
> the documentation in the same form as it is in actual patches: as three
> U+002D HYPHEN-MINUS characters. When building the documentation, Sphinx
> converts this symbol to a U+2014 EM DASH, that is invalid in this case.
>
> Make the three-dash symbol a reStructuredText inline literal to prevent
> its conversion; that is, enclose it in a pair of double backquotes (`).
>
> Signed-off-by: Grzegorz Szymaszek 

Reviewed-by: Mattijs Korpershoek 

> ---
>  doc/develop/sending_patches.rst | 4 ++--
>  tools/patman/patman.rst | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
> index 5a6962f102..3f25b1d046 100644
> --- a/doc/develop/sending_patches.rst
> +++ b/doc/develop/sending_patches.rst
> @@ -121,7 +121,7 @@ General Patch Submission Rules
> * For new features: a description of the feature and your implementation.
>  
>  * Additional comments which you don't want included in U-Boot's history can 
> be
> -  included below the first "---" in the message body.
> +  included below the first "``---``" in the message body.
>  
>  * If your description gets too long, that's a strong indication that you 
> should
>split up your patch.
> @@ -253,7 +253,7 @@ to observe the following rules.
>  
>  * Please make sure to keep a "change log", i.e. a description of what you 
> have
>changed compared to previous versions of this patch. This change log should
> -  be added below the "---" line in the patch, which starts the "comment
> +  be added below the "``---``" line in the patch, which starts the "comment
>section", i.e. which contains text that does not get included into the
>actual commit message.
>Note: it is *not* sufficient to provide a change log in some cover letter
> diff --git a/tools/patman/patman.rst b/tools/patman/patman.rst
> index a8b317eed6..e01355824c 100644
> --- a/tools/patman/patman.rst
> +++ b/tools/patman/patman.rst
> @@ -280,7 +280,7 @@ Series-notes:
>  
>  Commit-notes:
>  Similar, but for a single commit (patch). These notes will appear
> -immediately below the --- cut in the patch file::
> +immediately below the ``---`` cut in the patch file::
>  
>  Commit-notes:
>  blah blah
> -- 
> 2.43.0


Re: [PATCH 01/10] board: ti: common: Introduce a common fdt ops library

2024-01-09 Thread Nishanth Menon
On 15:08-20240109, Roger Quadros wrote:
[..]
> > +/**
> > + *  struct ti_fdt_map - mapping of device tree blob name to board name
> > + *  @name_fdt: board_name up to TI_NAME_FDT_MAX long
> > + *  @fdt_file_name: device tree blob name as described by kernel
> > + */
> > +struct ti_fdt_map {
> > +   const char *name_fdt;
> 
> Can we call this board_name? as name_fdt corresponds to device tree name.
> 

Done.

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


Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-09 Thread Rasmus Villemoes
On 14/12/2023 08.33, Masahiro Yamada wrote:
> On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  wrote:
>>

> One more question to confirm if I can use this
> for my practical use-cases.
> 
> Is U-Boot able to handle FIT (includes kernel + DTs)
> and a separate initrd?
> 
>   # bootm  :  
> 
> 
> Presumably, it would be difficult to inject initramdisk
> into image.fit later, so I am hoping bootm would work like that,
> but I did not delve into U-Boot code.

I recently had occasion to use this, and it actually already works
out-of-the-box, but perhaps it could be better documented. Though you
need not only the ramdisk address but also the size, as in
:, and of course CONFIG_SUPPORT_RAW_INITRD.

My use case is bootstrapping: I have one FIT image (consisting of
kernel, dtbs and an initramfs) which is the one that will be written to
the target. But for bootstrapping, I (obviously) need to boot with a
different initramfs that contains the bootstrap logic. Since this
project uses fastboot, what I do is: upload the alternative initramfs,
move it out of the way ('cause fastboot only supports one single target
buffer), upload the FIT image, and "bootm $fitaddr $initrdaddr:$initrdsize".

> If it works, is it possible to verify the integrity of initrd?

No, I don't think so. In my case the FIT image is signed, and the kernel
and chosen dtb does get verified, but not the contents of the initrd.
I'm not sure how that should happen - in any case, in the fastboot case,
the host can run arbitrary shell commands so not much U-Boot can do.

Rasmus



Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-09 Thread Tom Rini
On Tue, Jan 09, 2024 at 11:01:42PM +0900, Masahiro Yamada wrote:
> Hi Simon,
> 
> 
> On Wed, Jan 3, 2024 at 8:47 AM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Wed, Dec 13, 2023 at 5:14 AM Will Deacon  wrote:
> > >
> > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > containing the built kernel and associated devicetree files.
> > > > Compression defaults to gzip which gives a good balance of size and
> > > > performance.
> > > >
> > > > The files compress from about 86MB to 24MB using this approach.
> > > >
> > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > and Linuxboot. It permits automatic selection of the correct
> > > > devicetree, matching the compatible string of the running board with
> > > > the closest compatible string in the FIT. There is no need for
> > > > filenames or other workarounds.
> > > >
> > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > FIT_COMPRESSION to select a different algorithm.
> > > >
> > > > The FIT can be examined using 'dumpimage -l'.
> > > >
> > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > requires compression utilities for the algorithm being used. Supported
> > > > compression options are the same as the Image.xxx files. For now there
> > > > is no way to change the compression other than by editing the rule for
> > > > $(obj)/image.fit
> > > >
> > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > this here, since it must be built separately from the Linux build.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v9:
> > > > - Move the compression control into Makefile.lib
> > > >
> > > > Changes in v8:
> > > > - Drop compatible string in FDT node
> > > > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > > > - Turn compress part of the make_fit.py comment in to a sentence
> > > > - Add two blank lines before parse_args() and setup_fit()
> > > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > > > - Use '$( > > > - Add 'mkimage' details Documentation/process/changes.rst
> > > > - Allow changing the compression used
> > > > - Tweak cover letter since there is only one clean-up patch
> > > >
> > > > Changes in v7:
> > > > - Add Image as a dependency of image.fit
> > > > - Drop kbuild tag
> > > > - Add dependency on dtbs
> > > > - Drop unnecessary path separator for dtbs
> > > > - Rebase to -next
> > > >
> > > > Changes in v5:
> > > > - Drop patch previously applied
> > > > - Correct compression rule which was broken in v4
> > > >
> > > > Changes in v4:
> > > > - Use single quotes for UIMAGE_NAME
> > > >
> > > > Changes in v3:
> > > > - Drop temporary file image.itk
> > > > - Drop patch 'Use double quotes for image name'
> > > > - Drop double quotes in use of UIMAGE_NAME
> > > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > > > - Avoid hard-coding "arm64" for the DT architecture
> > > >
> > > > Changes in v2:
> > > > - Drop patch previously applied
> > > > - Add .gitignore file
> > > > - Move fit rule to Makefile.lib using an intermediate file
> > > > - Drop dependency on CONFIG_EFI_ZBOOT
> > > > - Pick up .dtb files separately from the kernel
> > > > - Correct pylint too-many-args warning for write_kernel()
> > > > - Include the kernel image in the file count
> > > > - Add a pointer to the FIT spec and mention of its wide industry usage
> > > > - Mention the kernel version in the FIT description
> > > >
> > > >  Documentation/process/changes.rst |   9 +
> > > >  MAINTAINERS   |   7 +
> > > >  arch/arm64/Makefile   |   7 +-
> > > >  arch/arm64/boot/.gitignore|   1 +
> > > >  arch/arm64/boot/Makefile  |   6 +-
> > > >  scripts/Makefile.lib  |  16 ++
> > > >  scripts/make_fit.py   | 291 ++
> > > >  7 files changed, 334 insertions(+), 3 deletions(-)
> > > >  create mode 100755 scripts/make_fit.py
> > >
> > > I'll need Masahiro's Ack on the scripts/ changes before I can take this
> > > one.
> >
> > Any thoughts on this request, please?
> >
> > Regards,
> > Simon
> >
> 
> 
> 
> As I mentioned before, I am concerned with having
> the same "compatible" entries, with different contents,
> as you use the "compatible" string as an ID to selecting
> the target config node, right?
> 
> 
> 
> 
> 
> $ fdtdump  arch/arm64/boot/image.fit
> 
> ...
> 
> conf-10 {
> compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
> description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier 
> board";
> fdt = "fdt-10";
> kernel = "kernel";
> };
> 
> ...
> 
> conf-25 {
> compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
> description = "TQ-Systems TQMa64xxL 

Re: [PATCH v7 7/7] test: hush: dollar: fix bagous behavior

2024-01-09 Thread Mattijs Korpershoek
Hi Svyatoslav,

On mar., janv. 09, 2024 at 15:57, Svyatoslav  wrote:

> 9 січня 2024 р. 15:54:32 GMT+02:00, Mattijs Korpershoek 
>  написав(-ла):
>>Hi Svyatoslav,
>>
>>Thank you for the patch.
>>
>>On ven., janv. 05, 2024 at 09:22, Svyatoslav Ryhel  wrote:
>>
>>> From: Ion Agorria 
>>>
>>> The dollar test was merged with bagous console behavior, and
>>> instead of fixing it, this behavior was just workarounded.
>>>
>>> It seems like without the fix the ut_assert_skipline(); didn't clear
>>> console and running ut_assert_skipline(); many times would give always
>>> OK. With
>>>
>>> lib: membuff: fix readline not returning line in case of overflow
>>>
>>> the line is cleared correctly and next assert fails because now there
>>> is nothing to clean which is correct if we look the this a bit above
>>> the failing assert:
>>>
>>> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>>>  /*
>>>   * For some strange reasons, the console is not empty after
>>>   * running above command.
>>>   * So, we reset it to not have side effects for other tests.
>>>   */
>>>  console_record_reset_enable();
>>> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>>>  ut_assert_console_end();
>>> }
>>>
>>> Which further confirms that tests workaround the old problem and now
>>> that problem is fixed we can remove the whole if blocks and simply
>>> place ut_assert_console_end() right after ut_assert_skipline() without
>>> any conditional and will pass green.
>>>
>>> So this part of code goes from:
>>> ut_assert_skipline();
>>> ut_assert_skipline();
>>>
>>> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>>> /* See above comments. */
>>> console_record_reset_enable();
>>> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>>> ut_assert_console_end();
>>> }
>>>
>>> to become:
>>> ut_assert_skipline();
>>> ut_assert_console_end();
>>>
>>> Same thing should be done with the if block mentioned above that calls
>>> console_record_reset_enable().
>>>
>>> Signed-off-by: Ion Agorria 
>>> Signed-off-by: Svyatoslav Ryhel 
>>
>>I confirm this fixes the problem reported in:
>>https://lore.kernel.org/all/87wmspm9e5@baylibre.com/
>>
>>Tested-by: Mattijs Korpershoek 
>>
>>The commit message is a bit long, but I don't mind it staying this way.
>>
>>Reviewed-by: Mattijs Korpershoek 
>>
>
> Thanks! Commit title might have a typo. Not "bagous" but "bugous" should be 
> correct. May you adjust on pick if not too hard?

Yes, will update while picking up.

>
>>> ---
>>>  test/hush/dollar.c | 23 +++
>>>  1 file changed, 3 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/test/hush/dollar.c b/test/hush/dollar.c
>>> index 4caa07c192..68d0874d90 100644
>>> --- a/test/hush/dollar.c
>>> +++ b/test/hush/dollar.c
>>> @@ -53,29 +53,12 @@ static int hush_test_simple_dollar(struct 
>>> unit_test_state *uts)
>>> ut_asserteq(1, run_command("dollar_foo='bar quux", 0));
>>> /* Next line contains error message */
>>> ut_assert_skipline();
>>> -
>>> -   if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>>> -   /*
>>> -* For some strange reasons, the console is not empty after
>>> -* running above command.
>>> -* So, we reset it to not have side effects for other tests.
>>> -*/
>>> -   console_record_reset_enable();
>>> -   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>>> -   ut_assert_console_end();
>>> -   }
>>> +   ut_assert_console_end();
>>>  
>>> ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
>>> -   /* Two next lines contain error message */
>>> -   ut_assert_skipline();
>>> +   /* Next line contains error message */
>>> ut_assert_skipline();
>>> -
>>> -   if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>>> -   /* See above comments. */
>>> -   console_record_reset_enable();
>>> -   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>>> -   ut_assert_console_end();
>>> -   }
>>> +   ut_assert_console_end();
>>>  
>>> ut_assertok(run_command("dollar_foo='bar \"quux'", 0));
>>>  
>>> -- 
>>> 2.40.1


Re: [PATCH 2/2] include: env: ti: add default for do_main_cpsw0_qsgmii_phyinit

2024-01-09 Thread Mattijs Korpershoek
Hi Manorit,

Thank you for the patch.

On lun., janv. 08, 2024 at 13:48, Manorit Chawdhry  wrote:

> By default this variable is unset and this causes the test condition to
> fail on devices that don't have this defined. Set a default value for
> this.
>
>=> boot
>## Error: "main_cpsw0_qsgmii_phyinit" not defined
>[...]
>
> Fixes: 0d72b0f2f83b ("include: env: ti: ti_common: Run 
> main_cpsw0_qsgmii_phyinit conditionally")
>
> Signed-off-by: Manorit Chawdhry 

Reviewed-by: Mattijs Korpershoek 

> ---
>  include/env/ti/ti_common.env | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
> index 5473f633aa7d..02b410c3adc4 100644
> --- a/include/env/ti/ti_common.env
> +++ b/include/env/ti/ti_common.env
> @@ -22,6 +22,7 @@ get_fit_overlaystring=
>   done;
>  get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
>  run_fit=run get_fit_config; bootm 
> ${addr_fit}#${name_fit_config}${overlaystring}
> +do_main_cpsw0_qsgmii_phyinit=0
>  bootcmd_ti_mmc=
>   run findfdt; run init_${boot};
>  #if CONFIG_CMD_REMOTEPROC
>
> -- 
> 2.43.0


Re: [PATCH v3 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

2024-01-09 Thread Bryan Brattlof
On January  9, 2024 thus sayeth Sumit Garg:
> On Tue, 9 Jan 2024 at 07:24, Bryan Brattlof  wrote:
> >
> > On January  8, 2024 thus sayeth Sumit Garg:
> > > Hi Bryan,
> > >
> > > On Sat, 6 Jan 2024 at 02:12, Bryan Brattlof  wrote:
> > > >
> > > > Hi Sumit!
> > > >
> > > > On December 28, 2023 thus sayeth Sumit Garg:
> > > > > Allow u-boot to build DTB from a different directory tree such that
> > > > > *-u-boot.dtsi files can be included from a common location. Currently
> > > > > that location is arch/$(ARCH)/dts/, so statically define that common
> > > > > location.
> > > > >
> > > > > This is needed for platform owners to start building DTB files from
> > > > > devicetree-rebasing directory but still being able to include
> > > > > *-u-boot.dtsi files.
> > > > >
> > > > > Reviewed-by: Tom Rini 
> > > > > Reviewed-by: Simon Glass 
> > > > > Reviewed-by: Ilias Apalodimas 
> > > > > Signed-off-by: Sumit Garg 
> > > > > ---
> > > > >
> > > >
> > > > ...
> > > >
> > > > >
> > > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > > > index 27b9437027c..09330421856 100644
> > > > > --- a/scripts/Makefile.lib
> > > > > +++ b/scripts/Makefile.lib
> > > >
> > > > ...
> > > >
> > > > >  # Uncomment for debugging
> > > > > @@ -190,6 +192,7 @@ dtsi_include_list += 
> > > > > $(CONFIG_DEVICE_TREE_INCLUDES)
> > > > >  dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc
> > > > > \
> > > > >$(UBOOTINCLUDE)
> > > > >  \
> > > > >-I$(dir $<)
> > > > >  \
> > > > > +  -I$(u_boot_dtsi_loc)   
> > > > >   \
> > > > >-I$(srctree)/arch/$(ARCH)/dts/include  
> > > > >  \
> > > > >-I$(srctree)/include   
> > > > >  \
> > > > >-D__ASSEMBLY__ 
> > > > >  \
> > > > > @@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> > > > > echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
> > > > >   $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o 
> > > > > $(dtc-tmp) $(pre-tmp) ; \
> > > > >   $(DTC) -O dtb -o $@ -b 0 \
> > > > > - -i $(dir $<) $(DTC_FLAGS) \
> > > > > + -i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
> > > > >   -d $(depfile).dtc.tmp $(dtc-tmp) || \
> > > > >   (echo "Check $(shell pwd)/$(pre-tmp) for errors" && 
> > > > > false) \
> > > > >   ; \
> > > >
> > > > One of the issues I see with having a separate OF_UPSTREAM and U-Boot dt
> > > > directory is when we have U-Boot board files that use dtsi files in the
> > > > OF_UPSTREAM folder.
> > > >
> > > > For example our reference boards uses the primary bootloader's dtb (eg:
> > > > k3-am62a7-r5-sk.dts) which #includes the k3-am62a7-sk.dts that will be
> > > > found in the OF_UPSTREAM directory and modifies it to give it the
> > > > perspective of the micro-controller it will be running on during boot.
> > >
> > > Thanks for bringing this up. I have been playing with the idea to
> > > reuse DT includes from upstream.
> > >
> > > >
> > > > What do you think if we have both paths included regardless if
> > > > OF_UPSTREAM is selected or not? IDK if this will break anyone else
> > >
> > > Sure, we should be able to do that if we maintain the correct order of
> > > include paths as per following patch [1]. If this works for you let me
> > > know and I will include it for v4.
> > >
> >
> > This works beautifully.
> >
> > I did have to hack around to get Makefile.spl working but this is headed
> > in the right direction for me :)
> 
> Thanks for testing. I hope I can take that as a tested-by tag for this patch.
> 

Absolutely 

Tested-by: Bryan Brattlof 

~Bryan


Re: [PATCH 04/10] board: ti: am64x: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
On 15:08-20240109, Roger Quadros wrote:
[..]
> >  #ifdef CONFIG_BOARD_LATE_INIT
> > +static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
> > +   {"am64x_gpevm", "k3-am642-evm.dtb"},
> > +   {"am64x_skevm", "k3-am642-sk.dtb"},
> 
> "am64x_gpevm" and "am64x_skevm" strings are used multiple times in this file.
> see setup_board_eeprom_env()
> 
> Please use a MACRO for them.
> 
> What is the logic of choosing this name and can it be updated at this point?
> e.g."gp" is misleading in the board name as the boards are now shipped with
> HS-FS chip and are no longer GP.

Intent of the series was to get rid of findfdt - it was not meant to
cleanup existing name usage in the files. If there is a desire to do so,
please - patches are welcome.

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


Re: [PATCH] arch: mach-k3: Fix incorrect mapping of higher DDR addresses as device memory

2024-01-09 Thread Nishanth Menon
On 14:15-20240109, Sekhar Nori wrote:
> Entry for physical address 0x5 in memory map table for MMU
> configuration is spilling over and inadvertently making DDR available at
> higher address (above 4GB address space) get mapped as device memory
> (nGnRnE).
> 
> Fix this by adjusting entry size. Tested on AM62A SK. Before this patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 7f34d7ca
> 
> time: 1 minutes, 14.716 seconds
> 
> After patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 7f34d7ca
> 
> time: 2.710 seconds
> 
> Acked-by: Andrew Davis 
> Signed-off-by: Sekhar Nori 
> ---
> Applies to u-boot/next
> 
>  arch/arm/mach-k3/arm64-mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
> index b4308205b2..0e07b1b7ce 100644
> --- a/arch/arm/mach-k3/arm64-mmu.c
> +++ b/arch/arm/mach-k3/arm64-mmu.c
> @@ -41,7 +41,7 @@ struct mm_region k3_mem_map[] = {
>   }, {
>   .virt = 0x5UL,
>   .phys = 0x5UL,
> - .size = 0x4UL,
> + .size = 0x38000UL,
>   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> -- 
> 2.40.0
> 

Thanks.

Reviewed-by: Nishanth Menon 

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


Re: [PATCH 02/10] board: ti: am62ax: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
On 20:48-20240108, Jon Humphreys wrote:
[..]

> > +
> > +#ifdef CONFIG_BOARD_LATE_INIT
> > +int board_late_init(void)
> > +{
> > +   ti_set_fdt_env(NULL, NULL);
> 
> If a board only has one FDT possible, why not just hard code the path
> here, rather than use the set_fdt_env() logic with NULLs and create/set
> TI_EVM_FDT_FOLDER_PATH config that is only used here anyway?

Centralizing the logic has the additional benefit of standardizing
fall back when maps are not matched. It is better than having each of
the board file introduce random way of doing things.

> 
> If you think we might add additional board types / FDTs later, then
> instead let's formalize the fdt_map concept and create a CONFIG_USES_FDT_MAP
> that will then rely on the fdt_map and call the ti_set_fdt_env(), and if
> not set, then it just returns a hard coded value, which could be based on
> the CONFIG_DEFAULT_DEVICE_TREE config.

Ends up being superflous - there is already a push to reduce the config
options.

[..]

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


Re: [PATCH 08/10] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Nishanth Menon
On 20:24-20240108, Jon Humphreys wrote:
> Nishanth Menon  writes:
> 
> > Stop using the findfdt script and switch to setting the fdtfile from C
> > code.
> >
> > While at this, replace findfdt in environment with a warning as it is
> > no longer needed
> >
> > Signed-off-by: Nishanth Menon 
> > ---
> >  board/beagle/beagleboneai64/beagleboneai64.c   | 14 ++
> >  board/beagle/beagleboneai64/beagleboneai64.env |  1 -
> >  configs/j721e_beagleboneai64_a72_defconfig |  3 ++-
> >  3 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
> > b/board/beagle/beagleboneai64/beagleboneai64.c
> > index c8c1c78ae5a2..1982f738b04e 100644
> > --- a/board/beagle/beagleboneai64/beagleboneai64.c
> > +++ b/board/beagle/beagleboneai64/beagleboneai64.c
> > @@ -28,3 +28,17 @@ int dram_init_banksize(void)
> >  {
> > return fdtdec_setup_memory_banksize();
> >  }
> > +
> > +#ifdef CONFIG_BOARD_LATE_INIT
> > +int board_late_init(void)
> > +{
> > +   char fdtfile[50];
> > +
> > +   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
> > +CONFIG_TI_EVM_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
> 
> This would set the board to using the control DT, not boot DT.  Is that
> what you meant?

control DT file name. not the content.

> But anyway, why not just hard code the FDT path/name here since there is
> only one for this board?  I don't see the value in the extra logic of
> using the config values (or having a fdt_map).  (Same for beagleplay)

because there are potentially variants being privately discussed for both the
platforms - though the timelines are unknown at this point. This will
allow fragments to replace the DEFAULT_DEVICE_TREE to the variant and
rest of the logic will *just work*.

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


Re: [PATCH 01/10] board: ti: common: Introduce a common fdt ops library

2024-01-09 Thread Nishanth Menon
On 20:20-20240108, Jon Humphreys wrote:
[...]

> > +config TI_EVM_FDT_FOLDER_PATH
> > +   string "Location of Folder path where dtb is present"
> > +   default "ti/davinci" if ARCH_DAVINCI
> > +   default "ti/keystone" if ARCH_KEYSTONE
> > +   default "ti/omap" if ARCH_OMAP2PLUS
> > +   default "ti" if ARCH_K3
> > +   depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
> > +   help
> > +  Folder path for kernel device tree default.
> > +  This is used along with fdtfile path to locate the kernel
> > +  device tree blob.
> 
> It's not clear to me why we need the flexibility of specifying a FDT
> filename per board independently of the FDT folder path.  Why can't the path
> be part of the fdt_map?

Because of 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=724ba6751532055db75992fc6ae21c3e322e94a7

This does not happen too often, but the folder paths are irritating and
impact multiple platforms at the same time.

[...]
> > + *
> > + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
> > + */
> > +
> > +#include 
> > +#include 
> > +#include "fdt_ops.h"
> > +
> > +void ti_set_fdt_env(const char *name_fdt, struct ti_fdt_map *fdt_map)
> 
> This function takes a board name and sets the FDT name, so why isn't the
> first parameter called 'board_name' or similar?

Fair enough - board_name is more appropriate.
> 
> > +{
> > +   char *fdt_file_name = NULL;
> > +   char fdtfile[TI_FDT_FILE_MAX];
> > +
> > +   if (name_fdt) {
> > +   while (fdt_map) {
> > +   /* Check for NULL terminator in the list */
> > +   if (!fdt_map->name_fdt)
> > +   break;
> > +   if (!strncmp(fdt_map->name_fdt, name_fdt, 
> > TI_NAME_FDT_MAX)) {
> 
> Why do we need a max length?  Shouldn't strcmp() be fine given the
> name_fdt member of the fdt_map is set in code (ie, not read in)?

prefer strncmp to strcmp where possible. it isn't a matter of set in
code or not, it is a possibility of making a mistake - hence the
constant sized string.

> 
> > +   fdt_file_name = fdt_map->fdt_file_name;
> > +   break;
> > +   }
> > +   fdt_map++;
> > +   }
> > +   }
> > +
> > +   /* match not found OR null name_fdt */
> > +   if (!fdt_file_name) {
> > +   /*
> > +* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
> > +* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
> > +*/
> > +#ifdef CONFIG_DEFAULT_FDT_FILE
> > +   if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
> > +   snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
> > +CONFIG_TI_EVM_FDT_FOLDER_PATH, 
> > CONFIG_DEFAULT_FDT_FILE);
> 
> I do not see where any TI platforms set CONFIG_DEFAULT_FDT_FILE, so why
> have logic that checks for it?  We don't use it.  With this patch
> (fdt_map) I don't see why we would start needing it in the future.

You don't need to explicitly set since it is already set by default - check the
.config.

> 
> > +   } else
> > +#endif
> > +   {
> > +   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
> > +CONFIG_TI_EVM_FDT_FOLDER_PATH,
> > +CONFIG_DEFAULT_DEVICE_TREE);
> 
> If fdtfile isn't set, EFI bootmeth falls back to the control DT anyway,
> so this is unnecessary duplication of logic.

Wrong translation of what is going on here - it is assuming the
fdtfile _name_ is the same as the board file used for u-boot not the
control DT content(which is the fall back for bootmeth). It is possible
that the content is the same as what U-Boot is using, but the file
name is what is being selected here.

[...]
> > +
> > +#define TI_NAME_FDT_MAX 20
> 
> TI_BOARD_NAME_MAX??

OK - will fix.
> 
> > +#define TI_FDT_FILE_MAX 200
> > +
> > +/**
> > + *  struct ti_fdt_map - mapping of device tree blob name to board name
> > + *  @name_fdt: board_name up to TI_NAME_FDT_MAX long
> 
> If this is the board_name, why call it name_fdt?  Why not board_name?

will replace with board_name
> 
> > + *  @fdt_file_name: device tree blob name as described by kernel
> > + */
> > +struct ti_fdt_map {
> > +   const char *name_fdt;
> > +   char *fdt_file_name;
> > +};
> > +
> > +/**
> > + * ti_set_fdt_env  - Find the correct device tree file name and set
> > 'fdtfile'
> 
> "Find the correct device tree file name based on the board name and "...

OK.

> 
> > + * env variable with correct folder structure appropriate to the 
> > architecture
> > + * and kernel conventions. This function is invoked typically as part of
> > + * board_late_init
> > + *
> > + * fdt name is picked by:
> > + * a) If a match is found, use the match
> 
> "a) If a board name match is found, use the match"

OK.

[...]

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 

Re: [PATCH 1/2] include: env: ti: ti_common: Fix a missing semicolon

2024-01-09 Thread Mattijs Korpershoek
Hi Manorit,

Thank you for the patch.

On lun., janv. 08, 2024 at 13:48, Manorit Chawdhry  wrote:

> Fix a missing semicolon that leads to syntax error while booting j721s2.
>
> Importing environment from mmc1 ...
> syntax error at 'run'HUSH died!
>
> Fixes: 0d72b0f2f83b ("include: env: ti: ti_common: Run 
> main_cpsw0_qsgmii_phyinit conditionally")
>
> Signed-off-by: Manorit Chawdhry 

Reviewed-by: Mattijs Korpershoek 

> ---
>  include/env/ti/ti_common.env | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
> index f0f89a228767..5473f633aa7d 100644
> --- a/include/env/ti/ti_common.env
> +++ b/include/env/ti/ti_common.env
> @@ -27,7 +27,7 @@ bootcmd_ti_mmc=
>  #if CONFIG_CMD_REMOTEPROC
>   if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
>   then run main_cpsw0_qsgmii_phyinit;
> - fi
> + fi;
>   run boot_rprocs;
>  #endif
>   if test ${boot_fit} -eq 1;
>
> -- 
> 2.43.0


Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-09 Thread Masahiro Yamada
Hi Simon,


On Wed, Jan 3, 2024 at 8:47 AM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Wed, Dec 13, 2023 at 5:14 AM Will Deacon  wrote:
> >
> > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > containing the built kernel and associated devicetree files.
> > > Compression defaults to gzip which gives a good balance of size and
> > > performance.
> > >
> > > The files compress from about 86MB to 24MB using this approach.
> > >
> > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > and Linuxboot. It permits automatic selection of the correct
> > > devicetree, matching the compatible string of the running board with
> > > the closest compatible string in the FIT. There is no need for
> > > filenames or other workarounds.
> > >
> > > Add a 'make image.fit' build target for arm64, as well. Use
> > > FIT_COMPRESSION to select a different algorithm.
> > >
> > > The FIT can be examined using 'dumpimage -l'.
> > >
> > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > requires compression utilities for the algorithm being used. Supported
> > > compression options are the same as the Image.xxx files. For now there
> > > is no way to change the compression other than by editing the rule for
> > > $(obj)/image.fit
> > >
> > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > this here, since it must be built separately from the Linux build.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > > Changes in v9:
> > > - Move the compression control into Makefile.lib
> > >
> > > Changes in v8:
> > > - Drop compatible string in FDT node
> > > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > > - Turn compress part of the make_fit.py comment in to a sentence
> > > - Add two blank lines before parse_args() and setup_fit()
> > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > > - Use '$( > > - Add 'mkimage' details Documentation/process/changes.rst
> > > - Allow changing the compression used
> > > - Tweak cover letter since there is only one clean-up patch
> > >
> > > Changes in v7:
> > > - Add Image as a dependency of image.fit
> > > - Drop kbuild tag
> > > - Add dependency on dtbs
> > > - Drop unnecessary path separator for dtbs
> > > - Rebase to -next
> > >
> > > Changes in v5:
> > > - Drop patch previously applied
> > > - Correct compression rule which was broken in v4
> > >
> > > Changes in v4:
> > > - Use single quotes for UIMAGE_NAME
> > >
> > > Changes in v3:
> > > - Drop temporary file image.itk
> > > - Drop patch 'Use double quotes for image name'
> > > - Drop double quotes in use of UIMAGE_NAME
> > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > > - Avoid hard-coding "arm64" for the DT architecture
> > >
> > > Changes in v2:
> > > - Drop patch previously applied
> > > - Add .gitignore file
> > > - Move fit rule to Makefile.lib using an intermediate file
> > > - Drop dependency on CONFIG_EFI_ZBOOT
> > > - Pick up .dtb files separately from the kernel
> > > - Correct pylint too-many-args warning for write_kernel()
> > > - Include the kernel image in the file count
> > > - Add a pointer to the FIT spec and mention of its wide industry usage
> > > - Mention the kernel version in the FIT description
> > >
> > >  Documentation/process/changes.rst |   9 +
> > >  MAINTAINERS   |   7 +
> > >  arch/arm64/Makefile   |   7 +-
> > >  arch/arm64/boot/.gitignore|   1 +
> > >  arch/arm64/boot/Makefile  |   6 +-
> > >  scripts/Makefile.lib  |  16 ++
> > >  scripts/make_fit.py   | 291 ++
> > >  7 files changed, 334 insertions(+), 3 deletions(-)
> > >  create mode 100755 scripts/make_fit.py
> >
> > I'll need Masahiro's Ack on the scripts/ changes before I can take this
> > one.
>
> Any thoughts on this request, please?
>
> Regards,
> Simon
>



As I mentioned before, I am concerned with having
the same "compatible" entries, with different contents,
as you use the "compatible" string as an ID to selecting
the target config node, right?





$ fdtdump  arch/arm64/boot/image.fit

...

conf-10 {
compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
fdt = "fdt-10";
kernel = "kernel";
};

...

conf-25 {
compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
fdt = "fdt-25";
kernel = "kernel";
};












-- 
Best Regards
Masahiro Yamada


[PATCH] stm32mp2: Fix CONFIG_STM32MP25X flag usage

2024-01-09 Thread Patrice Chotard
"#if" was used instead of "#ifdef"

Fixes: 01a701994b05 ("stm32mp2: initial support")
Signed-off-by: Patrice Chotard 
---

 arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 46d469881b3..175f2a88490 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -157,7 +157,7 @@ enum forced_boot_mode {
 #endif /* __ASSEMBLY__ */
 #endif /* CONFIG_STM32MP15X || CONFIG_STM32MP13X */
 
-#if CONFIG_STM32MP25X
+#ifdef CONFIG_STM32MP25X
 #define STM32_RCC_BASE 0x4420
 #define STM32_TAMP_BASE0x4601
 
-- 
2.25.1



Re: [PATCH v7 7/7] test: hush: dollar: fix bagous behavior

2024-01-09 Thread Svyatoslav



9 січня 2024 р. 15:54:32 GMT+02:00, Mattijs Korpershoek 
 написав(-ла):
>Hi Svyatoslav,
>
>Thank you for the patch.
>
>On ven., janv. 05, 2024 at 09:22, Svyatoslav Ryhel  wrote:
>
>> From: Ion Agorria 
>>
>> The dollar test was merged with bagous console behavior, and
>> instead of fixing it, this behavior was just workarounded.
>>
>> It seems like without the fix the ut_assert_skipline(); didn't clear
>> console and running ut_assert_skipline(); many times would give always
>> OK. With
>>
>> lib: membuff: fix readline not returning line in case of overflow
>>
>> the line is cleared correctly and next assert fails because now there
>> is nothing to clean which is correct if we look the this a bit above
>> the failing assert:
>>
>> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>>  /*
>>   * For some strange reasons, the console is not empty after
>>   * running above command.
>>   * So, we reset it to not have side effects for other tests.
>>   */
>>  console_record_reset_enable();
>> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>>  ut_assert_console_end();
>> }
>>
>> Which further confirms that tests workaround the old problem and now
>> that problem is fixed we can remove the whole if blocks and simply
>> place ut_assert_console_end() right after ut_assert_skipline() without
>> any conditional and will pass green.
>>
>> So this part of code goes from:
>> ut_assert_skipline();
>> ut_assert_skipline();
>>
>> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>> /* See above comments. */
>> console_record_reset_enable();
>> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>> ut_assert_console_end();
>> }
>>
>> to become:
>> ut_assert_skipline();
>> ut_assert_console_end();
>>
>> Same thing should be done with the if block mentioned above that calls
>> console_record_reset_enable().
>>
>> Signed-off-by: Ion Agorria 
>> Signed-off-by: Svyatoslav Ryhel 
>
>I confirm this fixes the problem reported in:
>https://lore.kernel.org/all/87wmspm9e5@baylibre.com/
>
>Tested-by: Mattijs Korpershoek 
>
>The commit message is a bit long, but I don't mind it staying this way.
>
>Reviewed-by: Mattijs Korpershoek 
>

Thanks! Commit title might have a typo. Not "bagous" but "bugous" should be 
correct. May you adjust on pick if not too hard?

>> ---
>>  test/hush/dollar.c | 23 +++
>>  1 file changed, 3 insertions(+), 20 deletions(-)
>>
>> diff --git a/test/hush/dollar.c b/test/hush/dollar.c
>> index 4caa07c192..68d0874d90 100644
>> --- a/test/hush/dollar.c
>> +++ b/test/hush/dollar.c
>> @@ -53,29 +53,12 @@ static int hush_test_simple_dollar(struct 
>> unit_test_state *uts)
>>  ut_asserteq(1, run_command("dollar_foo='bar quux", 0));
>>  /* Next line contains error message */
>>  ut_assert_skipline();
>> -
>> -if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>> -/*
>> - * For some strange reasons, the console is not empty after
>> - * running above command.
>> - * So, we reset it to not have side effects for other tests.
>> - */
>> -console_record_reset_enable();
>> -} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>> -ut_assert_console_end();
>> -}
>> +ut_assert_console_end();
>>  
>>  ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
>> -/* Two next lines contain error message */
>> -ut_assert_skipline();
>> +/* Next line contains error message */
>>  ut_assert_skipline();
>> -
>> -if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>> -/* See above comments. */
>> -console_record_reset_enable();
>> -} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>> -ut_assert_console_end();
>> -}
>> +ut_assert_console_end();
>>  
>>  ut_assertok(run_command("dollar_foo='bar \"quux'", 0));
>>  
>> -- 
>> 2.40.1


Re: [PATCH v7 7/7] test: hush: dollar: fix bagous behavior

2024-01-09 Thread Mattijs Korpershoek
Hi Svyatoslav,

Thank you for the patch.

On ven., janv. 05, 2024 at 09:22, Svyatoslav Ryhel  wrote:

> From: Ion Agorria 
>
> The dollar test was merged with bagous console behavior, and
> instead of fixing it, this behavior was just workarounded.
>
> It seems like without the fix the ut_assert_skipline(); didn't clear
> console and running ut_assert_skipline(); many times would give always
> OK. With
>
> lib: membuff: fix readline not returning line in case of overflow
>
> the line is cleared correctly and next assert fails because now there
> is nothing to clean which is correct if we look the this a bit above
> the failing assert:
>
> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>  /*
>   * For some strange reasons, the console is not empty after
>   * running above command.
>   * So, we reset it to not have side effects for other tests.
>   */
>  console_record_reset_enable();
> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>  ut_assert_console_end();
> }
>
> Which further confirms that tests workaround the old problem and now
> that problem is fixed we can remove the whole if blocks and simply
> place ut_assert_console_end() right after ut_assert_skipline() without
> any conditional and will pass green.
>
> So this part of code goes from:
> ut_assert_skipline();
> ut_assert_skipline();
>
> if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
> /* See above comments. */
> console_record_reset_enable();
> } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
> ut_assert_console_end();
> }
>
> to become:
> ut_assert_skipline();
> ut_assert_console_end();
>
> Same thing should be done with the if block mentioned above that calls
> console_record_reset_enable().
>
> Signed-off-by: Ion Agorria 
> Signed-off-by: Svyatoslav Ryhel 

I confirm this fixes the problem reported in:
https://lore.kernel.org/all/87wmspm9e5@baylibre.com/

Tested-by: Mattijs Korpershoek 

The commit message is a bit long, but I don't mind it staying this way.

Reviewed-by: Mattijs Korpershoek 

> ---
>  test/hush/dollar.c | 23 +++
>  1 file changed, 3 insertions(+), 20 deletions(-)
>
> diff --git a/test/hush/dollar.c b/test/hush/dollar.c
> index 4caa07c192..68d0874d90 100644
> --- a/test/hush/dollar.c
> +++ b/test/hush/dollar.c
> @@ -53,29 +53,12 @@ static int hush_test_simple_dollar(struct unit_test_state 
> *uts)
>   ut_asserteq(1, run_command("dollar_foo='bar quux", 0));
>   /* Next line contains error message */
>   ut_assert_skipline();
> -
> - if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
> - /*
> -  * For some strange reasons, the console is not empty after
> -  * running above command.
> -  * So, we reset it to not have side effects for other tests.
> -  */
> - console_record_reset_enable();
> - } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
> - ut_assert_console_end();
> - }
> + ut_assert_console_end();
>  
>   ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
> - /* Two next lines contain error message */
> - ut_assert_skipline();
> + /* Next line contains error message */
>   ut_assert_skipline();
> -
> - if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
> - /* See above comments. */
> - console_record_reset_enable();
> - } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
> - ut_assert_console_end();
> - }
> + ut_assert_console_end();
>  
>   ut_assertok(run_command("dollar_foo='bar \"quux'", 0));
>  
> -- 
> 2.40.1


Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-09 Thread Masahiro Yamada
On Fri, Dec 29, 2023 at 3:39 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  wrote:
> >
> > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > >  wrote:
> > > > >
> > > > > Hi Laurent,
> > > > >
> > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > >  wrote:
> > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > >  wrote:
> > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > wrote:
> > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > single file
> > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > files.
> > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > of size and
> > > > > > > > > > > performance.
> > > > > > > > > > >
> > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > approach.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be used by bootloaders which support it, such 
> > > > > > > > > > > as U-Boot
> > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > correct
> > > > > > > > > > > devicetree, matching the compatible string of the running 
> > > > > > > > > > > board with
> > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > need for
> > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > >
> > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > Use
> > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > >
> > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > used. Supported
> > > > > > > > > > > compression options are the same as the Image.xxx files. 
> > > > > > > > > > > For now there
> > > > > > > > > > > is no way to change the compression other than by editing 
> > > > > > > > > > > the rule for
> > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > >
> > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made 
> > > > > > > > > > > to support
> > > > > > > > > > > this here, since it must be built separately from the 
> > > > > > > > > > > Linux build.
> > > > > > > > > >
> > > > > > > > > > FIT images are very useful, so I think this is a very 
> > > > > > > > > > welcome addition
> > > > > > > > > > to the kernel build system. It can get tricky though: given 
> > > > > > > > > > the
> > > > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > > > one-size-fits-them-all solution to build them, and striking 
> > > > > > > > > > the right
> > > > > > > > > > balance between what makes sense for the kernel and the 
> > > > > > > > > > features that
> > > > > > > > > > users may request will probably lead to bikeshedding. As we 
> > > > > > > > > > all love
> > > > > > > > > > bikeshedding, I thought I would start selfishly, with a 
> > > > > > > > > > personal use
> > > > > > > > > > case :-) This isn't a yak-shaving request though, I don't 
> > > > > > > > > > see any reason
> > > > > > > > > > to delay merging this series.
> > > > > > > > > >
> > > > > > > > > > Have you envisioned building FIT images with a subset of 
> > > > > > > > > > DTBs, or adding
> > > > > > > > > > DTBOs ? Both would be fairly trivial extensions to this 
> > > > > > > > > > script by
> > > > > > > > > > extending the supported command line arguments. It would 
> > > > > > > > > > perhaps be more
> > > > > > > > > > difficult to integrate in the kernel build system though. 
> > > > > > > > > > This leads me
> > > > > > > > > > to a second question: would you consider merging extensions 
> > > > > > > > > > to this
> > > > > > > > > > script if they are not used by the kernel build system, but 
> > > > > > > > > > meant for
> > > > > > > > > > users who manually invoke the script ? More generally, is 
> > > > > > > > > > the script
> > > > > > > > >
> > > > > > > > > We'd also be interested in some customization, though in a 
> > > > > > > > > different way.
> > > > > > > > > We imagine having a rule file that says X compatible string 
> > > > > > > > > should map
> > > > > > > > > to A base DTB, plus B and C DTBO for the configuration 
> > > > > > > > > 

Re: [PATCH v6 0/6] Implement fastboot multiresponce

2024-01-09 Thread Mattijs Korpershoek
Hi Ion,

On jeu., janv. 04, 2024 at 17:44, Ion Agorria  wrote:

> Hello,
>
> It seems like without the fix the ut_assert_skipline(); didn't clear
> console and running ut_assert_skipline(); many times would give always
> OK. With my fix the line is cleared correctly and next assert fails
> because now there is nothing to clean which is correct if we look the
> this a bit above the failing assert:
>
>if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>/*
> * For some strange reasons, the console is not empty after
> * running above command.
> * So, we reset it to not have side effects for other tests.
> */
>console_record_reset_enable();
>} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>ut_assert_console_end();
>}
>
> Which further confirms that tests workaround the old problem and now
> that problem is fixed we can remove the whole if blocks and simply
> place ut_assert_console_end() right after ut_assert_skipline() without
> any conditional and will pass green.
>
> So this part of code goes from:
>ut_assert_skipline();
>ut_assert_skipline();
>
>if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
>/* See above comments. */
>console_record_reset_enable();
>} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>ut_assert_console_end();
>}
>
> to become:
>ut_assert_skipline();
>ut_assert_console_end();
>
> Same thing should be done with the if block mentioned at start of
> email that calls console_record_reset_enable().

That makes sense. Thank you for looking into this. I see that Svyatoslav
included your suggestion in

https://patchwork.ozlabs.org/project/uboot/patch/20240105072212.6615-8-clamo...@gmail.com/

I will review it there.

>
> Regards,
> Ion
>
> El jue, 4 ene 2024 a las 17:15, Svyatoslav Ryhel
> () escribió:
>>
>> чт, 4 січ. 2024 р. о 17:00 Mattijs Korpershoek  
>> пише:
>> >
>> > Hello Svyatoslav,
>> >
>> > On jeu., déc. 28, 2023 at 20:01, Svyatoslav Ryhel  
>> > wrote:
>> >
>> > > Currently u-boot fastboot can only send one message back to host,
>> > > so if there is a need to print more than one line messages must be
>> > > kept sending until all the required data is obtained. This behavior
>> > > can be adjusted using multiresponce ability (getting multiple lines
>> > > of response) proposed in this patch set.
>> > >
>> > > Implementation of multiresponce leads to ability to dump content of
>> > > console buffer which, with use of "oem run", allows to entirely avoid
>> > > need in UART.
>> > >
>> > > ---
>> > > Changes in v6:
>> > >  - remove prev console changes
>> > >  - add console_record_isempty helper
>> > >  - set record flag on init
>> > >
>> > > Changes in v5:
>> > >  - restored membuff_readline behavior changed in v4
>> > >
>> > > Changes in v4:
>> > >  - adjust membuff_readline behavior with overflow
>> > >
>> > > Changes in v3:
>> > >  - fix missing function calls if CONFIG_CONSOLE_RECORD is not enabled
>> > >
>> > > Changes in v2:
>> > >  - changed variables to static
>> > >  - fixed multiresponce for udp
>> > >  - documented use of "MORE"
>> > >  - converted #if to if (...)
>> > > ---
>> > >
>> > > Ion Agorria (6):
>> > >   fastboot: multiresponse support
>> > >   fastboot: implement "getvar all"
>> > >   common: console: introduce console_record_isempty helper
>> > >   common: console: record console from the beginning
>> > >   lib: membuff: fix readline not returning line in case of overflow
>> > >   fastboot: add oem console command support
>> >
>> > I went on to apply the series, however CI detected a regression in the
>> > unit tests:
>> >
>> > https://source.denx.de/u-boot/custodians/u-boot-dfu/-/jobs/764396
>> >
>> > This can be reproduced with:
>> > $ ./test/py/test.py --bd sandbox --build -k ut_hush_hush_test_simple_dollar
>> >
>> > I've narrowed this down to:
>> >  [PATCH v6 5/6] lib: membuff: fix readline not returning line in case of 
>> > overflow
>> >
>> > Could you please have a look?
>> >
>> > Thank you!
>> >
>>
>> Test contains 2 skiplines, commenting one fixes test
>>
>> ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
>> /* Two next lines contain error message */
>> ut_assert_skipline();
>> ut_assert_skipline();
>>
>> > >
>> > >  boot/bootmeth_extlinux.c  |  2 +-
>> > >  common/console.c  | 10 +++-
>> > >  doc/android/fastboot-protocol.rst |  3 ++
>> > >  doc/android/fastboot.rst  |  1 +
>> > >  drivers/fastboot/Kconfig  |  7 +++
>> > >  drivers/fastboot/fb_command.c | 52 +
>> > >  drivers/fastboot/fb_getvar.c  | 77 +--
>> > >  drivers/usb/gadget/f_fastboot.c   | 29 
>> > >  include/console.h | 13 ++
>> > >  include/fastboot-internal.h   |  7 +++
>> > >  include/fastboot.h 

Re: [PATCH v3 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function

2024-01-09 Thread Robert Marko
On Wed, Nov 29, 2023 at 11:11 AM Robert Marko  wrote:
>
> Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
> which makes it hard to add support for any other board to be fixed up.
>
> So, lets just move the FDT fixup code to a separate function and call it
> if compatible matches, there should be no functional change.
>
> Signed-off-by: Robert Marko 
> Reviewed-by: Stefan Roese 


Hi Stefan,
Since 2024.01 was released, can this series be pulled in now?

Regards,
Robert

>
> ---
>  board/Marvell/mvebu_armada-37xx/board.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
> b/board/Marvell/mvebu_armada-37xx/board.c
> index 04124d8014..1471caa9a6 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
>  #endif
>
>  #ifdef CONFIG_OF_BOARD_SETUP
> -int ft_board_setup(void *blob, struct bd_info *bd)
> +static int espressobin_fdt_setup(void *blob)
>  {
> -#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> int ret;
> int spi_off;
> int parts_off;
> int part_off;
>
> /* Fill SPI MTD partitions for Linux kernel on Espressobin */
> -   if (!of_machine_is_compatible("globalscale,espressobin"))
> -   return 0;
> -
> spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
> if (spi_off < 0)
> return 0;
> @@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> return 0;
> }
>
> +   return 0;
> +}
> +
> +int ft_board_setup(void *blob, struct bd_info *bd)
> +{
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> +   if (of_machine_is_compatible("globalscale,espressobin"))
> +   return espressobin_fdt_setup(blob);
>  #endif
> return 0;
>  }
> --
> 2.43.0
>


-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
1 Zagreb, Croatia
Email: robert.ma...@sartura.hr
Web: www.sartura.hr


Re: [PATCH 01/10] board: ti: common: Introduce a common fdt ops library

2024-01-09 Thread Roger Quadros



On 08/01/2024 19:32, Nishanth Menon wrote:
> Introduce a common fdt operations library for basic device tree
> operations that are common between various boards.
> 
> The first library to introduce here is the capability to set up
> fdtfile as a standard variable as part of board identification rather
> than depend on scripted ifdeffery.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  board/ti/common/Kconfig   | 12 
>  board/ti/common/Makefile  |  1 +
>  board/ti/common/fdt_ops.c | 65 +++
>  board/ti/common/fdt_ops.h | 41 
>  4 files changed, 119 insertions(+)
>  create mode 100644 board/ti/common/fdt_ops.c
>  create mode 100644 board/ti/common/fdt_ops.h
> 
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 49edd98014ab..06a8a36aa1cd 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
>   imply CMD_SPI
>   imply CMD_TIME
>   imply CMD_USB if USB
> +
> +config TI_EVM_FDT_FOLDER_PATH
> + string "Location of Folder path where dtb is present"
> + default "ti/davinci" if ARCH_DAVINCI
> + default "ti/keystone" if ARCH_KEYSTONE
> + default "ti/omap" if ARCH_OMAP2PLUS
> + default "ti" if ARCH_K3
> + depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
> + help
> +Folder path for kernel device tree default.
> +This is used along with fdtfile path to locate the kernel
> +device tree blob.
> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
> index 26bf12e2e6d5..5ac361ba7fcf 100644
> --- a/board/ti/common/Makefile
> +++ b/board/ti/common/Makefile
> @@ -3,3 +3,4 @@
>  
>  obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
>  obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
> +obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
> diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
> new file mode 100644
> index ..f8770cae4a54
> --- /dev/null
> +++ b/board/ti/common/fdt_ops.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Library to support FDT file operations which are common
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include 
> +#include 
> +#include "fdt_ops.h"
> +
> +void ti_set_fdt_env(const char *name_fdt, struct ti_fdt_map *fdt_map)
> +{
> + char *fdt_file_name = NULL;
> + char fdtfile[TI_FDT_FILE_MAX];
> +
> + if (name_fdt) {
> + while (fdt_map) {
> + /* Check for NULL terminator in the list */
> + if (!fdt_map->name_fdt)
> + break;
> + if (!strncmp(fdt_map->name_fdt, name_fdt, 
> TI_NAME_FDT_MAX)) {
> + fdt_file_name = fdt_map->fdt_file_name;
> + break;
> + }
> + fdt_map++;
> + }
> + }
> +
> + /* match not found OR null name_fdt */
> + if (!fdt_file_name) {
> + /*
> +  * Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
> +  * or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
> +  */
> +#ifdef CONFIG_DEFAULT_FDT_FILE
> + if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
> +  CONFIG_TI_EVM_FDT_FOLDER_PATH, 
> CONFIG_DEFAULT_FDT_FILE);
> + } else
> +#endif
> + {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
> +  CONFIG_TI_EVM_FDT_FOLDER_PATH,
> +  CONFIG_DEFAULT_DEVICE_TREE);
> + }
> + } else {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s", 
> CONFIG_TI_EVM_FDT_FOLDER_PATH,
> +  fdt_file_name);
> + }
> +
> + env_set("fdtfile", fdtfile);
> +
> + /*
> +  * XXX: DEPRECATION WARNING: 2 u-boot versions.
> +  *
> +  * Maintain compatibility with downstream scripts that may be using
> +  * name_fdt
> +  */
> + if (name_fdt)
> + env_set("name_fdt", name_fdt);
> + /* Also set the findfdt legacy script to warn users to stop using this 
> */
> + env_set("findfdt",
> + "echo WARN: fdtfile already set. Stop using findfdt in script");
> +}
> diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
> new file mode 100644
> index ..c01697bed28f
> --- /dev/null
> +++ b/board/ti/common/fdt_ops.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Library to support common device tree manipulation for TI EVMs
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
> + */
> +
> +#ifndef __FDT_OPS_H
> +#define __FDT_OPS_H
> +
> +#define TI_NAME_FDT_MAX 20
> +#define TI_FDT_FILE_MAX 200
> +
> +/**
> + *  struct 

Re: [PATCH 04/10] board: ti: am64x: Set fdtfile from C code instead of findfdt script

2024-01-09 Thread Roger Quadros



On 08/01/2024 19:32, Nishanth Menon wrote:
> We now can provide a map and have the standard fdtfile variable set from
> code itself. This allows for bootstd to "just work".
> 
> While at this, replace findfdt in environment with a warning as it is no
> longer needed.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  board/ti/am64x/am64x.env | 9 -
>  board/ti/am64x/evm.c | 8 
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> index efd736b99be4..9a8812d4ee54 100644
> --- a/board/ti/am64x/am64x.env
> +++ b/board/ti/am64x/am64x.env
> @@ -2,14 +2,6 @@
>  #include 
>  #include 
>  
> -findfdt=
> - if test $board_name = am64x_gpevm; then
> - setenv name_fdt ti/k3-am642-evm.dtb; fi;
> - if test $board_name = am64x_skevm; then
> - setenv name_fdt ti/k3-am642-sk.dtb; fi;
> - if test $name_fdt = undefined; then
> - echo WARNING: Could not determine device tree to use; fi;
> - setenv fdtfile ${name_fdt}
>  name_kern=Image
>  console=ttyS2,115200n8
>  args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> @@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
>  usbboot=setenv boot usb;
>   setenv bootpart 0:2;
>   usb start;
> - run findfdt;
>   run init_usb;
>   run get_kern_usb;
>   run get_fdt_usb;
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index a6dcff2eb434..e2f506d2c6ea 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include "../common/board_detect.h"
> +#include "../common/fdt_ops.h"
>  
>  #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
>   board_ti_k3_is("AM64-HSEVM"))
> @@ -180,6 +181,12 @@ int checkboard(void)
>  }
>  
>  #ifdef CONFIG_BOARD_LATE_INIT
> +static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
> + {"am64x_gpevm", "k3-am642-evm.dtb"},
> + {"am64x_skevm", "k3-am642-sk.dtb"},

"am64x_gpevm" and "am64x_skevm" strings are used multiple times in this file.
see setup_board_eeprom_env()

Please use a MACRO for them.

What is the logic of choosing this name and can it be updated at this point?
e.g."gp" is misleading in the board name as the boards are now shipped with
HS-FS chip and are no longer GP.


> + { /* Sentinel. */ }
> +};
> +
>  static void setup_board_eeprom_env(void)
>  {
>   char *name = "am64x_gpevm";
> @@ -197,6 +204,7 @@ static void setup_board_eeprom_env(void)
>  
>  invalid_eeprom:
>   set_board_info_env_am6(name);
> + ti_set_fdt_env(name, ti_am64_evm_fdt_map);
>  }
>  
>  static void setup_serial(void)

-- 
cheers,
-roger


Re: [PATCH v2 2/2] efi_loader: support fmp versioning for multi bank update

2024-01-09 Thread Ilias Apalodimas
On Tue, 9 Jan 2024 at 03:00, Masahisa Kojima  wrote:
>
> Hi Ilias,
>
> On Thu, 28 Dec 2023 at 00:14, Ilias Apalodimas
>  wrote:
> >
> > Kojima-san
> >
> > On Thu, Dec 21, 2023 at 06:52:58PM +0900, Masahisa Kojima wrote:
> > > This commit stores the firmware version into the array
> > > of fmp_state structure to support the fmp versioning
> > > for multi bank update. The index of the array is identified
> > > by the bank index.
> >
> > Why do we all of them? Can't we just always store/use the version of the 
> > active
> > bank?
>
> Sorry for the late reply.
> When the capsule update is reverted, the active bank is back to the
> previous active bank.
> So I think versions for all banks should be stored.

But even in that case, the active bank should point to the correct
version when the ESRT tables are generated. Wouldn't it be simpler to
just set the FmpState variable accordingly when that happens?
Am I missing anything?

Thanks
/Ilias
>
> Thanks,
> Masahisa Kojima
>
> >
> > >
> > > This modification keeps the backward compatibility with
> > > the existing versioning feature.
> > >
> >
> > Thanks
> > /Ilias
> > > Signed-off-by: Masahisa Kojima 
> > > ---
> > >  lib/efi_loader/efi_firmware.c | 69 +++
> > >  1 file changed, 54 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> > > index 9b8630625f..5459f3d38d 100644
> > > --- a/lib/efi_loader/efi_firmware.c
> > > +++ b/lib/efi_loader/efi_firmware.c
> > > @@ -207,18 +207,10 @@ void efi_firmware_fill_version_info(struct 
> > > efi_firmware_image_descriptor *image_
> > >  {
> > >   u16 varname[13]; /* u"FmpState" */
> > >   efi_status_t ret;
> > > - efi_uintn_t size;
> > > - struct fmp_state var_state = { 0 };
> > > -
> > > - efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > - fw_array->image_index);
> > > - size = sizeof(var_state);
> > > - ret = efi_get_variable_int(varname, _array->image_type_id,
> > > -NULL, , _state, NULL);
> > > - if (ret == EFI_SUCCESS)
> > > - image_info->version = var_state.fw_version;
> > > - else
> > > - image_info->version = 0;
> > > + efi_uintn_t size, expected_size;
> > > + uint num_banks = 1;
> > > + uint active_index = 0;
> > > + struct fmp_state *var_state;
> > >
> > >   efi_firmware_get_lsv_from_dtb(fw_array->image_index,
> > > _array->image_type_id,
> > > @@ -227,6 +219,31 @@ void efi_firmware_fill_version_info(struct 
> > > efi_firmware_image_descriptor *image_
> > >   image_info->version_name = NULL; /* not supported */
> > >   image_info->last_attempt_version = 0;
> > >   image_info->last_attempt_status = LAST_ATTEMPT_STATUS_SUCCESS;
> > > + image_info->version = 0;
> > > +
> > > + /* get the fw_version */
> > > + efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > + fw_array->image_index);
> > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > + ret = fwu_get_active_index(_index);
> > > + if (ret)
> > > + return;
> > > +
> > > + num_banks = CONFIG_FWU_NUM_BANKS;
> > > + }
> > > +
> > > + size = num_banks * sizeof(*var_state);
> > > + expected_size = size;
> > > + var_state = calloc(1, size);
> > > + if (!var_state)
> > > + return;
> > > +
> > > + ret = efi_get_variable_int(varname, _array->image_type_id,
> > > +NULL, , var_state, NULL);
> > > + if (ret == EFI_SUCCESS && expected_size == size)
> > > + image_info->version = var_state[active_index].fw_version;
> > > +
> > > + free(var_state);
> > >  }
> > >
> > >  /**
> > > @@ -362,8 +379,11 @@ efi_status_t efi_firmware_set_fmp_state_var(struct 
> > > fmp_state *state, u8 image_in
> > >  {
> > >   u16 varname[13]; /* u"FmpState" */
> > >   efi_status_t ret;
> > > + uint num_banks = 1;
> > > + uint update_bank = 0;
> > > + efi_uintn_t size;
> > >   efi_guid_t *image_type_id;
> > > - struct fmp_state var_state = { 0 };
> > > + struct fmp_state *var_state;
> > >
> > >   image_type_id = efi_firmware_get_image_type_id(image_index);
> > >   if (!image_type_id)
> > > @@ -372,19 +392,38 @@ efi_status_t efi_firmware_set_fmp_state_var(struct 
> > > fmp_state *state, u8 image_in
> > >   efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > >   image_index);
> > >
> > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > + ret = fwu_plat_get_update_index(_bank);
> > > + if (ret)
> > > + return EFI_INVALID_PARAMETER;
> > > +
> > > + num_banks = CONFIG_FWU_NUM_BANKS;
> > > + }
> > > +
> > > + size = num_banks * 

Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver

2024-01-09 Thread Roger Quadros



On 09/01/2024 11:49, MD Danish Anwar wrote:
> 
> 
> On 09/01/24 2:56 pm, Roger Quadros wrote:
>>
>>
>> On 08/01/2024 12:25, MD Danish Anwar wrote:
>>> On 08/01/24 3:00 pm, Roger Quadros wrote:


 On 05/01/2024 12:15, Anwar, Md Danish wrote:
>
>
> On 1/5/2024 1:49 PM, Roger Quadros wrote:
>>
>>
>> On 03/01/2024 12:27, MD Danish Anwar wrote:
>>>
>>>
>>> On 02/01/24 7:26 pm, Andrew Davis wrote:
 On 12/27/23 12:56 AM, MD Danish Anwar wrote:
>
>
> On 22/12/23 6:13 pm, Roger Quadros wrote:
>>
>> On 22/12/2023 12:26, MD Danish Anwar wrote:
>>> Hi Roger,
>>>
>>> On 20/12/23 3:29 pm, Roger Quadros wrote:
 Hi,

 On 19/12/2023 12:11, MD Danish Anwar wrote:
> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used
> in TI
> AM654 SR2.0.
>
> The ICSSG PRU Sub-system runs on EMAC firmware. This series
> Introduces
> support for ICSSG driver in uboot. This series also adds the 
> driver's
> dependencies.
>
> The ICSSG2 node is added in device tree overlay so that it 
> remains in
> sync with linux kernel.
>
> The series introduces device tree and config changes and AM65x
> to enable ICSSG driver. The series also enables
> SPL_LOAD_FIT_APPLY_OVERLAY
> for AM65x in order to load overlay over spl.
>
> This series has been tested on AM65x SR2.0, and the ICSSG
> interface is
> able to ping / dhcp and boot kernel using tftp in uboot.
>
> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to
> PRU RPROC
> cores and RPROC cores need to be booted with the firmware. This
> step is
> done inside driver in kernel as kernel supports APIs like
> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't
> have these
> APIs, the same needs to be done via u-boot cmds.
>
> To make sure icssg-eth works we need to do below steps.
>
> 1. Initialize rproc cores i.e. rproc_init()
> 2. Load $firmware_file from partition '1:2' (root) on device (mmc
> in this
>     example)
> 3. Load the firmware file to rproc cores passing. i.e. 
> rproc_load()
>     taking rproc_id, loadaddr and file size as arguments.
> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as 
> arguments
>
> The above steps are done by running the below commands at u-boot
> prompt.
>
> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc
> start 16; rproc start 17; rproc start 18; rproc start 19'
> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop
> 16; rproc stop 17; rproc stop 18; rproc stop 19'
> => setenv firmware_dir '/lib/firmware/ti-pruss'
> => setenv get_firmware_mmc 'load mmc ${bootpart} ${loadaddr}
> ${firmware_dir}/${firmware_file}'
>
> => setenv init_icssg2 'setenv ethact icssg2-eth; setenv autoload
> no; rproc init; setenv loadaddr 0x8000; \
>  setenv firmware_file am65x-sr2-pru0-prueth-fw.elf; run
> get_firmware_mmc;  rproc load 14 0x8000 ${filesize}; \
>  setenv loadaddr 0x8900; setenv firmware_file
> am65x-sr2-rtu0-prueth-fw.elf; run get_firmware_mmc; rproc load 15
> 0x8900 ${filesize}; \
>  setenv loadaddr 0x9000; setenv firmware_file
> am65x-sr2-txpru0-prueth-fw.elf; run get_firmware_mmc; rproc load
> 16 0x9000 ${filesize}; \
>  setenv loadaddr 0x8000; setenv firmware_file
> am65x-sr2-pru1-prueth-fw.elf; run get_firmware_mmc; rproc load 17
> 0x8000 ${filesize}; \
>  setenv loadaddr 0x8900; setenv firmware_file
> am65x-sr2-rtu1-prueth-fw.elf; run get_firmware_mmc; rproc load 18
> 0x8900 ${filesize}; \
>  setenv loadaddr 0x9000; setenv firmware_file
> am65x-sr2-txpru1-prueth-fw.elf; run get_firmware_mmc; rproc load
> 19 0x9000 ${filesize}; \
>  run start_icssg2;'

 A whole bunch of commands are required to get ethernet functional.
 This is not at all user friendly and will be a maintenance 
 nightmare.
 What worries me is tracking the 6 different rproc cores and the 6
 different firmware files to start 1 ethernet device.

  1   2   >