Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
On 12/4/23 08:27, Stefan Roese wrote: On 12/4/23 02:05, Marek Vasut wrote: On 12/4/23 01:44, Simon Glass wrote: Hi Marek, On Sun, 3 Dec 2023 at 14:01, Marek Vasut wrote: On 12/3/23 18:44, Simon Glass wrote: Hi Marek, On Sat, 2 Dec 2023 at 16:41, Marek Vasut wrote: In case the cyclic framework is enabled, poll the card detect of already initialized cards and deinitialize them in case they are removed. Since the card initialization is a longer process and card initialization is done on first access to an uninitialized card anyway, avoid initializing newly detected uninitialized cards in the cyclic callback. Signed-off-by: Marek Vasut --- Cc: Jaehoon Chung Cc: Peng Fan --- drivers/mmc/mmc-uclass.c | 27 +++ 1 file changed, 27 insertions(+) This is really nice! I wonder whether we can use this cyclic stuff for USB , that's on my roadmap to look at . We could auto-detect new devices in the background, which would be tidy. And maybe do block transfers in the background ? Just the detect would be amazing!! One thing on my mind is that we could have a console buffer, so that output from background tasks can be collected and written just before displaying the U-Boot prompt. I am itching to implement that part of it :-) And a 'dmesg' command to go along with it ? Go for it. It's very nice to see, that the cyclic infrastructure is finally getting used by other interfaces / devices etc. Really interesting. I assume there are many more potential use cases where it may be helpful. Yes, many indeed.
[PATCH v1 0/3] Add T114 video support
T114 is not that different from T30 and all T30 drivers will work on T114 as well with some minor adjustments. Commits pass buildman for tegra and U-Boot tests. Svyatoslav Ryhel (3): video: tegra20: dc: add T114 support video: tegra20: add MIPI calibration driver video: tegra20: dsi: add T114 support arch/arm/dts/tegra114-u-boot.dtsi| 9 + arch/arm/include/asm/arch-tegra/dsi.h| 235 +++ arch/arm/include/asm/arch-tegra114/display.h | 28 +++ arch/arm/include/asm/arch-tegra114/pwm.h | 13 + arch/arm/include/asm/arch-tegra30/dsi.h | 211 + drivers/video/tegra20/Makefile | 2 +- drivers/video/tegra20/tegra-dc.c | 1 + drivers/video/tegra20/tegra-dsi.c| 78 +- drivers/video/tegra20/tegra-mipi.c | 185 +++ 9 files changed, 550 insertions(+), 212 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra/dsi.h create mode 100644 arch/arm/include/asm/arch-tegra114/display.h create mode 100644 arch/arm/include/asm/arch-tegra114/pwm.h create mode 100644 drivers/video/tegra20/tegra-mipi.c -- 2.40.1
[PATCH v1 1/3] video: tegra20: dc: add T114 support
Existing Tegra DC driver fits perfectly well for Tegra 4 so
let's add a compatible to state this.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra114-u-boot.dtsi| 9 +++
arch/arm/include/asm/arch-tegra114/display.h | 28
arch/arm/include/asm/arch-tegra114/pwm.h | 13 +
drivers/video/tegra20/tegra-dc.c | 1 +
4 files changed, 51 insertions(+)
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..3038227dbe 100644
--- a/arch/arm/dts/tegra114-u-boot.dtsi
+++ b/arch/arm/dts/tegra114-u-boot.dtsi
@@ -1,3 +1,12 @@
#include
#include "tegra-u-boot.dtsi"
+
+/ {
+ host1x@5000 {
+ bootph-all;
+ dc@5420 {
+ bootph-all;
+ };
+ };
+};
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 width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ */
+
+#ifndef __ASM_ARCH_TEGRA114_PWM_H
+#define __ASM_ARCH_TEGRA114_PWM_H
+
+#include
+
+#endif /* __ASM_ARCH_TEGRA114_PWM_H */
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index f53ad46397..20fa4bb27c 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -467,6 +467,7 @@ static const struct video_ops tegra_lcd_ops = {
static const struct udevice_id tegra_lcd_ids[] = {
{ .compatible = "nvidia,tegra20-dc" },
{ .compatible = "nvidia,tegra30-dc" },
+ { .compatible = "nvidia,tegra114-dc" },
{ }
};
--
2.40.1
[PATCH v1 2/3] video: tegra20: add MIPI calibration driver
Dedicated MIPI calibration driver is used on T114 and newer. Before
T114 MIPI calibration registers were part of VI and CSI.
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/Makefile | 2 +-
drivers/video/tegra20/tegra-mipi.c | 185 +
2 files changed, 186 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..52e5ea0ff6
--- /dev/null
+++ b/drivers/video/tegra20/tegra-mipi.c
@@ -0,0 +1,185 @@
+// 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;
+ int mipi_clk;
+};
+
+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, &priv->mipi->mipi_cal_bias_pad_cfg1);
+
+ value = readl(&priv->mipi->mipi_cal_bias_pad_cfg2);
+ value &= ~MIPI_CAL_BIAS_PAD_VCLAMP(0x7);
+ value &= ~MIPI_CAL_BIAS_PAD_VAUXP(0x7);
+ writel(value, &priv->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, &priv->mipi->mipi_cal_config_dsia);
+ writel(value, &priv->mipi->mipi_cal_config_dsib);
+
+ /* Deselect PAD C */
+ value = readl(&priv->mipi->mipi_cal_config_dsic);
+ value &= ~(MIPI_CAL_SEL(0x1));
+ writel(value, &priv->mipi->mipi_cal_config_dsic);
+
+ /* Deselect PAD D */
+ value = readl(&priv->mipi->mipi_cal_config_dsid);
+ value &= ~(MIPI_CAL_SEL(0x1));
+ writel(value, &priv->mipi->mipi_cal_config_dsid);
+
+ value = readl(&priv->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, &priv->mipi->mipi_cal_ctrl);
+
+ /* clear any pending status bits */
+ value = readl(&priv->mipi->mipi_cal_status);
+ writel(value, &priv->mipi->mipi_cal_status);
+
+ value = readl(&priv->mipi->mipi_cal_ctrl);
+ value |= MIPI_CAL_CTRL_START;
+ writel(value, &priv->mipi->mipi_cal_ctrl);
+
+ /*
+* Wait for min 72uS to let calibration logic fi
[PATCH v1 3/3] video: tegra20: dsi: add T114 support
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.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/include/asm/arch-tegra/dsi.h | 235
arch/arm/include/asm/arch-tegra30/dsi.h | 211 +
drivers/video/tegra20/tegra-dsi.c | 78 +++-
3 files changed, 313 insertions(+), 211 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra/dsi.h
diff --git a/arch/arm/include/asm/arch-tegra/dsi.h
b/arch/arm/include/asm/arch-tegra/dsi.h
new file mode 100644
index 00..0a399d8d51
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/dsi.h
@@ -0,0 +1,235 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DSI_H
+#define __ASM_ARCH_TEGRA_DSI_H
+
+#ifndef __ASSEMBLY__
+#include
+#endif
+
+/* Register definitions for the Tegra display serial interface */
+
+/* DSI syncpoint register 0x000 ~ 0x002 */
+struct dsi_syncpt_reg {
+ /* Address 0x000 ~ 0x002 */
+ uint incr_syncpt; /* _INCR_SYNCPT_0 */
+ uint incr_syncpt_ctrl; /* _INCR_SYNCPT_CNTRL_0 */
+ uint incr_syncpt_err; /* _INCR_SYNCPT_ERROR_0 */
+};
+
+/* DSI misc register 0x008 ~ 0x015 */
+struct dsi_misc_reg {
+ /* Address 0x008 ~ 0x015 */
+ uint ctxsw; /* _CTXSW_0 */
+ uint dsi_rd_data; /* _DSI_RD_DATA_0 */
+ uint dsi_wr_data; /* _DSI_WR_DATA_0 */
+ uint dsi_pwr_ctrl; /* _DSI_POWER_CONTROL_0 */
+ uint int_enable;/* _INT_ENABLE_0 */
+ uint int_status;/* _INT_STATUS_0 */
+ uint int_mask; /* _INT_MASK_0 */
+ uint host_dsi_ctrl; /* _HOST_DSI_CONTROL_0 */
+ uint dsi_ctrl; /* _DSI_CONTROL_0 */
+ uint dsi_sol_delay; /* _DSI_SOL_DELAY_0 */
+ uint dsi_max_threshold; /* _DSI_MAX_THRESHOLD_0 */
+ uint dsi_trigger; /* _DSI_TRIGGER_0 */
+ uint dsi_tx_crc;/* _DSI_TX_CRC_0 */
+ uint dsi_status;/* _DSI_STATUS_0 */
+};
+
+/* DSI init sequence register 0x01a ~ 0x022 */
+struct dsi_init_seq_reg {
+ /* Address 0x01a ~ 0x022 */
+ uint dsi_init_seq_ctrl; /* _DSI_INIT_SEQ_CONTROL_0 */
+ uint dsi_init_seq_data_0; /* _DSI_INIT_SEQ_DATA_0_0 */
+ uint dsi_init_seq_data_1; /* _DSI_INIT_SEQ_DATA_1_0 */
+ uint dsi_init_seq_data_2; /* _DSI_INIT_SEQ_DATA_2_0 */
+ uint dsi_init_seq_data_3; /* _DSI_INIT_SEQ_DATA_3_0 */
+ uint dsi_init_seq_data_4; /* _DSI_INIT_SEQ_DATA_4_0 */
+ uint dsi_init_seq_data_5; /* _DSI_INIT_SEQ_DATA_5_0 */
+ uint dsi_init_seq_data_6; /* _DSI_INIT_SEQ_DATA_6_0 */
+ uint dsi_init_seq_data_7; /* _DSI_INIT_SEQ_DATA_7_0 */
+};
+
+/* DSI packet sequence register 0x023 ~ 0x02e */
+struct dsi_pkt_seq_reg {
+ /* Address 0x023 ~ 0x02e */
+ uint dsi_pkt_seq_0_lo; /* _DSI_PKT_SEQ_0_LO_0 */
+ uint dsi_pkt_seq_0_hi; /* _DSI_PKT_SEQ_0_HI_0 */
+ uint dsi_pkt_seq_1_lo; /* _DSI_PKT_SEQ_1_LO_0 */
+ uint dsi_pkt_seq_1_hi; /* _DSI_PKT_SEQ_1_HI_0 */
+ uint dsi_pkt_seq_2_lo; /* _DSI_PKT_SEQ_2_LO_0 */
+ uint dsi_pkt_seq_2_hi; /* _DSI_PKT_SEQ_2_HI_0 */
+ uint dsi_pkt_seq_3_lo; /* _DSI_PKT_SEQ_3_LO_0 */
+ uint dsi_pkt_seq_3_hi; /* _DSI_PKT_SEQ_3_HI_0 */
+ uint dsi_pkt_seq_4_lo; /* _DSI_PKT_SEQ_4_LO_0 */
+ uint dsi_pkt_seq_4_hi; /* _DSI_PKT_SEQ_4_HI_0 */
+ uint dsi_pkt_seq_5_lo; /* _DSI_PKT_SEQ_5_LO_0 */
+ uint dsi_pkt_seq_5_hi; /* _DSI_PKT_SEQ_5_HI_0 */
+};
+
+/* DSI packet length register 0x033 ~ 0x037 */
+struct dsi_pkt_len_reg {
+ /* Address 0x033 ~ 0x037 */
+ uint dsi_dcs_cmds; /* _DSI_DCS_CMDS_0 */
+ uint dsi_pkt_len_0_1; /* _DSI_PKT_LEN_0_1_0 */
+ uint dsi_pkt_len_2_3; /* _DSI_PKT_LEN_2_3_0 */
+ uint dsi_pkt_len_4_5; /* _DSI_PKT_LEN_4_5_0 */
+ uint dsi_pkt_len_6_7; /* _DSI_PKT_LEN_6_7_0 */
+};
+
+/* DSI PHY timing register 0x03c ~ 0x03f */
+struct dsi_timing_reg {
+ /* Address 0x03c ~ 0x03f */
+ uint dsi_phy_timing_0; /* _DSI_PHY_TIMING_0_0 */
+ uint dsi_phy_timing_1; /* _DSI_PHY_TIMING_1_0 */
+ uint dsi_phy_timing_2; /* _DSI_PHY_TIMING_2_0 */
+ uint dsi_bta_timing;/* _DSI_BTA_TIMING_0 */
+};
+
+/* DSI timeout register 0x044 ~ 0x046 */
+struct dsi_timeout_reg {
+ /* Address 0x044 ~ 0x046 */
+ uint dsi_timeout_0; /* _DSI_TIMEOUT_0_0 */
+ uint dsi_timeout_1; /* _DSI_TIMEOUT_1_0 */
+ ui
Re: [PATCH v4 4/5] lib: membuff: fix readline not returning line in case of overflow
Hello Simon!
This is the latest iteration of commit, one you have checked is
already outdated.
Sorry for misunderstanding.
Best regards,
Svyatoslav R.
чт, 23 лист. 2023 р. о 13:02 Svyatoslav Ryhel пише:
>
> From: Ion Agorria
>
> If a line overflows readline's maxlen it won't advance the membuffer
> and will return 0 as read amount which isn't even documented.
> Fix by removing this behavior alltogether.
>
> Signed-off-by: Ion Agorria
> Signed-off-by: Svyatoslav Ryhel
> Reviewed-by: Mattijs Korpershoek
> ---
> lib/membuff.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/lib/membuff.c b/lib/membuff.c
> index 36dc43a523..f582193dcd 100644
> --- a/lib/membuff.c
> +++ b/lib/membuff.c
> @@ -292,15 +292,12 @@ int membuff_readline(struct membuff *mb, char *str, int
> maxlen, int minch)
> {
> int len; /* number of bytes read (!= string length) */
> char *s, *end;
> - bool ok = false;
> - char *orig = str;
>
> end = mb->head >= mb->tail ? mb->head : mb->end;
> for (len = 0, s = mb->tail; s < end && len < maxlen - 1; str++) {
> *str = *s++;
> len++;
> if (*str == '\n' || *str < minch) {
> - ok = true;
> break;
> }
> if (s == end && mb->tail > mb->head) {
> @@ -309,13 +306,6 @@ int membuff_readline(struct membuff *mb, char *str, int
> maxlen, int minch)
> }
> }
>
> - /* couldn't get the whole string */
> - if (!ok) {
> - if (maxlen)
> - *orig = '\0';
> - return 0;
> - }
> -
> /* terminate the string, update the membuff and return success */
> *str = '\0';
> mb->tail = s == mb->end ? mb->start : s;
> --
> 2.40.1
>
[PATCH v1 0/8] Convert Tegra pinctrl to DM
Create a DM supported wrapper arround existing Tegra pinmux logic. This implementation is backwards compatible with all existing board setups and early stages of setup. All new boards must be device tree based. Linux dts pinmux nodes are fully compatible with this driver. As an example I have converted recently merged T30 boards to this layout (I have those devices and was able to test them properly) and Paz00 T20 board which was tested as well by owner. Svyatoslav Ryhel (8): ARM: mach-tegra: rearrange SPL configs drivers: pinctrl: create Tegra DM pinctrl driver drivers: pinctrl: tegra: incorporate existing code board: asus: grouper: switch to DM pinmux board: lg: x3-t30: switch to DM pinmux board: asus: transformer: switch to DM pinmux board: htc: endeavoru: switch to DM pinmux board: compal: paz00: clean up the board arch/arm/dts/tegra20-paz00.dts|4 +- arch/arm/dts/tegra30-asus-grouper-common.dtsi | 712 ++ .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 113 ++ .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 113 ++ .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 149 +++ arch/arm/dts/tegra30-asus-p1801-t.dts | 982 ++ arch/arm/dts/tegra30-asus-tf201.dts | 45 + arch/arm/dts/tegra30-asus-tf300t.dts | 45 + arch/arm/dts/tegra30-asus-tf300tg.dts | 128 ++ arch/arm/dts/tegra30-asus-tf300tl.dts | 163 +++ arch/arm/dts/tegra30-asus-tf600t.dts | 889 + arch/arm/dts/tegra30-asus-tf700t.dts | 53 + arch/arm/dts/tegra30-asus-transformer.dtsi| 984 ++ arch/arm/dts/tegra30-htc-endeavoru.dts| 1147 + arch/arm/dts/tegra30-lg-p880.dts | 90 ++ arch/arm/dts/tegra30-lg-p895.dts | 93 ++ arch/arm/dts/tegra30-lg-x3.dtsi | 845 arch/arm/include/asm/arch-tegra114/pinmux.h | 303 + arch/arm/include/asm/arch-tegra124/pinmux.h | 327 + arch/arm/include/asm/arch-tegra20/pinmux.h| 291 + arch/arm/include/asm/arch-tegra210/pinmux.h | 394 ++ arch/arm/include/asm/arch-tegra30/pinmux.h| 381 ++ arch/arm/mach-tegra/Kconfig | 16 +- arch/arm/mach-tegra/Makefile |1 - arch/arm/mach-tegra/board.c |6 +- arch/arm/mach-tegra/board2.c |2 +- arch/arm/mach-tegra/tegra114/Makefile |2 +- arch/arm/mach-tegra/tegra124/Makefile |2 - arch/arm/mach-tegra/tegra20/Makefile |2 +- arch/arm/mach-tegra/tegra210/Makefile |1 - arch/arm/mach-tegra/tegra30/Makefile |2 +- board/asus/grouper/grouper.c | 18 - board/asus/grouper/pinmux-config-grouper.h| 362 -- .../pinmux-config-transformer.h | 365 -- board/asus/transformer-t30/transformer-t30.c | 23 - board/compal/paz00/Makefile |8 - board/compal/paz00/paz00.c| 53 - board/htc/endeavoru/endeavoru.c | 14 - board/htc/endeavoru/pinmux-config-endeavoru.h | 362 -- board/lg/x3-t30/Kconfig | 12 - board/lg/x3-t30/configs/p880.config |1 - board/lg/x3-t30/configs/p895.config |1 - board/lg/x3-t30/pinmux-config-x3.h| 449 --- board/lg/x3-t30/x3-t30.c | 23 - configs/paz00_defconfig |3 + drivers/pinctrl/Kconfig |1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/tegra/Kconfig | 18 + drivers/pinctrl/tegra/Makefile| 16 + .../pinctrl/tegra/funcmux-tegra114.c |0 .../pinctrl/tegra/funcmux-tegra124.c |0 .../pinctrl/tegra/funcmux-tegra20.c |0 .../pinctrl/tegra/funcmux-tegra210.c |0 .../pinctrl/tegra/funcmux-tegra30.c |0 drivers/pinctrl/tegra/pinctrl-tegra.c | 248 drivers/pinctrl/tegra/pinctrl-tegra20.c | 177 +++ .../pinctrl/tegra}/pinmux-common.c|0 .../pinctrl/tegra/pinmux-tegra114.c |0 .../pinctrl/tegra/pinmux-tegra124.c |0 .../pinctrl/tegra/pinmux-tegra20.c|0 drivers/pinctrl/tegra/pinmux-tegra210.c | 190 +++ .../pinctrl/tegra/pinmux-tegra30.c|0 include/configs/x3-t30.h | 13 +- 63 files changed, 8920 insertions(+), 1723 deletions(-) delete mode 100644 board/asus/grouper/pinmux-config-grouper.h delete mode 100644 board/asus/transformer-t30/pinmux-config-transformer.h delete mode 100644 board/compal/paz00/Makefile delete mode 100644 board/compal/paz00/paz00.c delete mode 100644 board/htc/endeavoru/pinmux-config-endeavoru.h delete mode 100644 board/lg/x3-t30/pinmux-config-x3.h create mode 100644 drivers/pinctrl/tegra/Kconfig create mode 100644 drivers/pinctrl/teg
[PATCH v1 1/8] ARM: mach-tegra: rearrange SPL configs
SPL configs are used only by the ARMv7-based Tegra SOC's, so move SPL_SYSRESET under TEGRA_ARMV7_COMMON selection and enable SPL_DM since SPL_SYSRESET depends on it. Signed-off-by: Svyatoslav Ryhel --- arch/arm/mach-tegra/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index f273778128..547372a639 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -61,7 +61,6 @@ config TEGRA_COMMON select OF_CONTROL select SPI select SYSRESET - select SPL_SYSRESET if SPL select SYSRESET_TEGRA imply CMD_DM imply CRC32_VERIFY @@ -78,7 +77,9 @@ config TEGRA_ARMV7_COMMON select CPU_V7A select SPL select SPL_BOARD_INIT if SPL + select SPL_DM if SPL select SPL_SKIP_LOWLEVEL_INIT_ONLY if SPL + select SPL_SYSRESET if SPL select SUPPORT_SPL select TIMER select TEGRA_CLKRST -- 2.40.1
[PATCH v1 2/8] drivers: pinctrl: create Tegra DM pinctrl driver
The existing pinctrl driver available for Tegra SOC is well
designed, but it lacks DM support. Let's add a DM compatible
overlay, which allows use of the device tree, along with preserving
backward compatibility with all existing setups and the ability
to use it in SPL board configuration stage.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/include/asm/arch-tegra114/pinmux.h | 303 +++
arch/arm/include/asm/arch-tegra124/pinmux.h | 327
arch/arm/include/asm/arch-tegra20/pinmux.h | 291 +++
arch/arm/include/asm/arch-tegra210/pinmux.h | 394
arch/arm/include/asm/arch-tegra30/pinmux.h | 381 +++
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile| 1 +
drivers/pinctrl/tegra/Kconfig | 18 +
drivers/pinctrl/tegra/Makefile | 8 +
drivers/pinctrl/tegra/pinctrl-tegra.c | 248
drivers/pinctrl/tegra/pinctrl-tegra20.c | 177 +
11 files changed, 2149 insertions(+)
create mode 100644 drivers/pinctrl/tegra/Kconfig
create mode 100644 drivers/pinctrl/tegra/Makefile
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra.c
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra20.c
diff --git a/arch/arm/include/asm/arch-tegra114/pinmux.h
b/arch/arm/include/asm/arch-tegra114/pinmux.h
index 414b22e201..63b3684931 100644
--- a/arch/arm/include/asm/arch-tegra114/pinmux.h
+++ b/arch/arm/include/asm/arch-tegra114/pinmux.h
@@ -312,6 +312,309 @@ enum pmux_func {
PMUX_FUNC_COUNT,
};
+static const char * const tegra_pinctrl_to_pingrp[] = {
+ [PMUX_PINGRP_ULPI_DATA0_PO1] = "ulpi_data0_po1",
+ [PMUX_PINGRP_ULPI_DATA1_PO2] = "ulpi_data1_po2",
+ [PMUX_PINGRP_ULPI_DATA2_PO3] = "ulpi_data2_po3",
+ [PMUX_PINGRP_ULPI_DATA3_PO4] = "ulpi_data3_po4",
+ [PMUX_PINGRP_ULPI_DATA4_PO5] = "ulpi_data4_po5",
+ [PMUX_PINGRP_ULPI_DATA5_PO6] = "ulpi_data5_po6",
+ [PMUX_PINGRP_ULPI_DATA6_PO7] = "ulpi_data6_po7",
+ [PMUX_PINGRP_ULPI_DATA7_PO0] = "ulpi_data7_po0",
+ [PMUX_PINGRP_ULPI_CLK_PY0] = "ulpi_clk_py0",
+ [PMUX_PINGRP_ULPI_DIR_PY1] = "ulpi_dir_py1",
+ [PMUX_PINGRP_ULPI_NXT_PY2] = "ulpi_nxt_py2",
+ [PMUX_PINGRP_ULPI_STP_PY3] = "ulpi_stp_py3",
+ [PMUX_PINGRP_DAP3_FS_PP0] = "dap3_fs_pp0",
+ [PMUX_PINGRP_DAP3_DIN_PP1] = "dap3_din_pp1",
+ [PMUX_PINGRP_DAP3_DOUT_PP2] = "dap3_dout_pp2",
+ [PMUX_PINGRP_DAP3_SCLK_PP3] = "dap3_sclk_pp3",
+ [PMUX_PINGRP_PV0] = "pv0",
+ [PMUX_PINGRP_PV1] = "pv1",
+ [PMUX_PINGRP_SDMMC1_CLK_PZ0] = "sdmmc1_clk_pz0",
+ [PMUX_PINGRP_SDMMC1_CMD_PZ1] = "sdmmc1_cmd_pz1",
+ [PMUX_PINGRP_SDMMC1_DAT3_PY4] = "sdmmc1_dat3_py4",
+ [PMUX_PINGRP_SDMMC1_DAT2_PY5] = "sdmmc1_dat2_py5",
+ [PMUX_PINGRP_SDMMC1_DAT1_PY6] = "sdmmc1_dat1_py6",
+ [PMUX_PINGRP_SDMMC1_DAT0_PY7] = "sdmmc1_dat0_py7",
+ [PMUX_PINGRP_CLK2_OUT_PW5] = "clk2_out_pw5",
+ [PMUX_PINGRP_CLK2_REQ_PCC5] = "clk2_req_pcc5",
+ [PMUX_PINGRP_HDMI_INT_PN7] = "hdmi_int_pn7",
+ [PMUX_PINGRP_DDC_SCL_PV4] = "ddc_scl_pv4",
+ [PMUX_PINGRP_DDC_SDA_PV5] = "ddc_sda_pv5",
+ [PMUX_PINGRP_UART2_RXD_PC3] = "uart2_rxd_pc3",
+ [PMUX_PINGRP_UART2_TXD_PC2] = "uart2_txd_pc2",
+ [PMUX_PINGRP_UART2_RTS_N_PJ6] = "uart2_rts_n_pj6",
+ [PMUX_PINGRP_UART2_CTS_N_PJ5] = "uart2_cts_n_pj5",
+ [PMUX_PINGRP_UART3_TXD_PW6] = "uart3_txd_pw6",
+ [PMUX_PINGRP_UART3_RXD_PW7] = "uart3_rxd_pw7",
+ [PMUX_PINGRP_UART3_CTS_N_PA1] = "uart3_cts_n_pa1",
+ [PMUX_PINGRP_UART3_RTS_N_PC0] = "uart3_rts_n_pc0",
+ [PMUX_PINGRP_PU0] = "pu0",
+ [PMUX_PINGRP_PU1] = "pu1",
+ [PMUX_PINGRP_PU2] = "pu2",
+ [PMUX_PINGRP_PU3] = "pu3",
+ [PMUX_PINGRP_PU4] = "pu4",
+ [PMUX_PINGRP_PU5] = "pu5",
+ [PMUX_PINGRP_PU6] = "pu6",
+ [PMUX_PINGRP_GEN1_I2C_SDA_PC5] = "gen1_i2c_sda_pc5",
+ [PMUX_PINGRP_GEN1_I2C_SCL_PC4] = "gen1_i2c_scl_pc4",
+ [PMUX_PINGRP_DAP4_FS_PP4] = "dap4_fs_pp4",
+ [PMUX_PINGRP_DAP4_DIN_PP5] = "dap4_din_pp5",
+ [PMUX_PINGRP_DAP4_DOUT_PP6] = "dap4_dout_pp6",
+ [PMUX_PINGRP_DAP4_SCLK_PP7] = "dap4_sclk_pp7",
+ [PMUX_PINGRP_CLK3_OUT_PEE0] = "clk3_out_pee0",
+ [PMUX_PINGRP_CLK3_REQ_PEE1] = "clk3_req_pee1",
+ [PMUX_PINGRP_GMI_WP_N_PC7] = "gmi_wp_n_pc7",
+ [PMUX_PINGRP_GMI_IORDY_PI5] = "gmi_iordy_pi5",
+ [PMUX_PINGRP_GMI_WAIT_PI7] = "gmi_wait_pi7",
+ [PMUX_PINGRP_GMI_ADV_N_PK0] = "gmi_adv_n_pk0",
+ [PMUX_PINGRP_GMI_CLK_PK1] = "gmi_clk_pk1",
+ [PMUX_PINGRP_GMI_CS0_N_PJ0] = "gmi_cs0_n_pj0",
+ [PMUX_PINGRP_GMI_CS1_N_PJ2] = "gmi_cs1_n_pj2",
+ [PMUX_PINGRP_GMI_CS2_N_PK3] = "gmi_cs2_n_pk3",
+ [PMUX_PINGRP_GMI_CS3_N_PK4] = "gmi_cs3_n_pk4",
+ [PMUX_PINGRP_GMI_CS4_N_PK2] = "gmi_cs4_n_pk2",
+ [PMUX_PINGRP_GMI_CS6_N_PI3] = "gmi_cs6_n_pi3",
+ [PMUX_PINGRP_GMI_CS7_N_PI6] = "gmi_cs7_n
[PATCH v1 3/8] drivers: pinctrl: tegra: incorporate existing code
Move all existing pinmux and funcmux code into a dedicated folder in
pinctrl to simplify further maintenance.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/mach-tegra/Kconfig | 13 +-
arch/arm/mach-tegra/Makefile | 1 -
arch/arm/mach-tegra/board.c | 6 +-
arch/arm/mach-tegra/board2.c | 2 +-
arch/arm/mach-tegra/tegra114/Makefile | 2 +-
arch/arm/mach-tegra/tegra124/Makefile | 2 -
arch/arm/mach-tegra/tegra20/Makefile | 2 +-
arch/arm/mach-tegra/tegra210/Makefile | 1 -
arch/arm/mach-tegra/tegra30/Makefile | 2 +-
drivers/pinctrl/tegra/Makefile| 8 +
.../pinctrl/tegra/funcmux-tegra114.c | 0
.../pinctrl/tegra/funcmux-tegra124.c | 0
.../pinctrl/tegra/funcmux-tegra20.c | 0
.../pinctrl/tegra/funcmux-tegra210.c | 0
.../pinctrl/tegra/funcmux-tegra30.c | 0
.../pinctrl/tegra}/pinmux-common.c| 0
.../pinctrl/tegra/pinmux-tegra114.c | 0
.../pinctrl/tegra/pinmux-tegra124.c | 0
.../pinctrl/tegra/pinmux-tegra20.c| 0
drivers/pinctrl/tegra/pinmux-tegra210.c | 190 ++
.../pinctrl/tegra/pinmux-tegra30.c| 0
21 files changed, 212 insertions(+), 17 deletions(-)
rename arch/arm/mach-tegra/tegra114/funcmux.c =>
drivers/pinctrl/tegra/funcmux-tegra114.c (100%)
rename arch/arm/mach-tegra/tegra124/funcmux.c =>
drivers/pinctrl/tegra/funcmux-tegra124.c (100%)
rename arch/arm/mach-tegra/tegra20/funcmux.c =>
drivers/pinctrl/tegra/funcmux-tegra20.c (100%)
rename arch/arm/mach-tegra/tegra210/funcmux.c =>
drivers/pinctrl/tegra/funcmux-tegra210.c (100%)
rename arch/arm/mach-tegra/tegra30/funcmux.c =>
drivers/pinctrl/tegra/funcmux-tegra30.c (100%)
rename {arch/arm/mach-tegra => drivers/pinctrl/tegra}/pinmux-common.c (100%)
rename arch/arm/mach-tegra/tegra114/pinmux.c =>
drivers/pinctrl/tegra/pinmux-tegra114.c (100%)
rename arch/arm/mach-tegra/tegra124/pinmux.c =>
drivers/pinctrl/tegra/pinmux-tegra124.c (100%)
rename arch/arm/mach-tegra/tegra20/pinmux.c =>
drivers/pinctrl/tegra/pinmux-tegra20.c (100%)
create mode 100644 drivers/pinctrl/tegra/pinmux-tegra210.c
rename arch/arm/mach-tegra/tegra30/pinmux.c =>
drivers/pinctrl/tegra/pinmux-tegra30.c (100%)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 547372a639..b18885f4c1 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -33,9 +33,6 @@ config TEGRA_IVC
config TEGRA_MC
bool
-config TEGRA_PINCTRL
- bool
-
config TEGRA_PMC
bool
@@ -75,9 +72,13 @@ config TEGRA_ARMV7_COMMON
bool "Tegra 32-bit common options"
select BINMAN
select CPU_V7A
+ select PINCTRL
+ select PINCTRL_TEGRA
select SPL
select SPL_BOARD_INIT if SPL
select SPL_DM if SPL
+ select SPL_PINCTRL if SPL
+ select SPL_PINCTRL_TEGRA if SPL
select SPL_SKIP_LOWLEVEL_INIT_ONLY if SPL
select SPL_SYSRESET if SPL
select SUPPORT_SPL
@@ -88,7 +89,6 @@ config TEGRA_ARMV7_COMMON
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
- select TEGRA_PINCTRL
select TEGRA_PMC
select TEGRA_TIMER
@@ -135,6 +135,8 @@ config TEGRA124
config TEGRA210
bool "Tegra210 family"
select GICV2
+ select PINCTRL
+ select PINCTRL_TEGRA
select TIMER
select TEGRA_ARMV8_COMMON
select TEGRA_CLKRST
@@ -142,7 +144,6 @@ config TEGRA210
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
- select TEGRA_PINCTRL
select TEGRA_PMC
select TEGRA_PMC_SECURE
select TEGRA_TIMER
@@ -195,7 +196,7 @@ config TEGRA_SPI
choice
prompt "UART to use for console"
- depends on TEGRA_PINCTRL
+ depends on PINCTRL_TEGRA
default TEGRA_ENABLE_UARTA
config TEGRA_ENABLE_UARTA
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index a5733b0bf6..1d22dc3942 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -17,7 +17,6 @@ obj-y += board.o board2.o
obj-y += cache.o
obj-$(CONFIG_TEGRA_CLKRST) += clock.o
obj-$(CONFIG_$(SPL_)TEGRA_CRYPTO) += crypto.o
-obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
obj-$(CONFIG_TEGRA_PMC) += powergate.o
obj-y += xusb-padctl-dummy.o
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index f8b61a2b3e..9224743d0e 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -17,7 +17,7 @@
#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
#include
#endif
-#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
+#if CONFIG_IS_ENABLED(PINCTRL_TEGRA)
#include
#endif
#if IS_ENABLED(CONFIG_TEGRA_MC)
@@ -163,7 +163,7 @@ int dram_init(void)
return 0;
}
-#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
+#if CONFIG_IS_ENABLED(PINCT
[PATCH v1 4/8] board: asus: grouper: switch to DM pinmux
Drop the pinmux setup in the board in favor of setting it up in
the device tree. Device tree nodes match nodes used in the Linux
device tree.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra30-asus-grouper-common.dtsi | 712 ++
.../dts/tegra30-asus-nexus7-grouper-E1565.dts | 113 +++
.../dts/tegra30-asus-nexus7-grouper-PM269.dts | 113 +++
.../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 149
board/asus/grouper/grouper.c | 18 -
board/asus/grouper/pinmux-config-grouper.h| 362 -
6 files changed, 1087 insertions(+), 380 deletions(-)
delete mode 100644 board/asus/grouper/pinmux-config-grouper.h
diff --git a/arch/arm/dts/tegra30-asus-grouper-common.dtsi
b/arch/arm/dts/tegra30-asus-grouper-common.dtsi
index c9277388c9..e8a3511a9f 100644
--- a/arch/arm/dts/tegra30-asus-grouper-common.dtsi
+++ b/arch/arm/dts/tegra30-asus-grouper-common.dtsi
@@ -44,6 +44,718 @@
};
};
+ pinmux@7868 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+
+ state_default: pinmux {
+ clk_32k_out_pa0 {
+ nvidia,pins = "clk_32k_out_pa0";
+ nvidia,function = "blink";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ uart3_cts_n_pa1 {
+ nvidia,pins = "uart3_cts_n_pa1",
+ "uart3_rxd_pw7";
+ nvidia,function = "uartc";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap2_fs_pa2 {
+ nvidia,pins = "dap2_fs_pa2",
+ "dap2_sclk_pa3",
+ "dap2_din_pa4",
+ "dap2_dout_pa5";
+ nvidia,function = "i2s1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc3_clk_pa6 {
+ nvidia,pins = "sdmmc3_clk_pa6";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc3_cmd_pa7 {
+ nvidia,pins = "sdmmc3_cmd_pa7",
+ "sdmmc3_dat3_pb4",
+ "sdmmc3_dat2_pb5",
+ "sdmmc3_dat1_pb6",
+ "sdmmc3_dat0_pb7",
+ "sdmmc3_dat4_pd1",
+ "sdmmc3_dat6_pd3",
+ "sdmmc3_dat7_pd4";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ gmi_a17_pb0 {
+ nvidia,pins = "gmi_a17_pb0",
+ "gmi_a18_pb1";
+ nvidia,function = "uartd";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ lcd_pwr0_pb2 {
+ nvidia,pins = "lcd_pwr0_pb2",
+ "lcd_pwr1_pc1",
+ "lcd_m1_pw1";
+ nvidia,function = "displaya";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ lcd_pclk_pb3 {
+ nvidia,pins = "lcd_pclk_pb3",
+ "lcd_d0_pe0",
+ "lcd_d1_pe1",
+ "lcd_d2_pe2",
+ "lcd_d3_pe3",
+ "lcd_d4_pe4",
+ "lcd_d5_pe5",
+ "lcd_d6_pe6",
+
[PATCH v1 5/8] board: lg: x3-t30: switch to DM pinmux
Drop the pinmux setup in the board in favor of setting it up in
the device tree. Device tree nodes match nodes used for the Linux
device tree and are set according to the service manual.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra30-lg-p880.dts| 90 +++
arch/arm/dts/tegra30-lg-p895.dts| 93 +++
arch/arm/dts/tegra30-lg-x3.dtsi | 845
board/lg/x3-t30/Kconfig | 12 -
board/lg/x3-t30/configs/p880.config | 1 -
board/lg/x3-t30/configs/p895.config | 1 -
board/lg/x3-t30/pinmux-config-x3.h | 449 ---
board/lg/x3-t30/x3-t30.c| 23 -
include/configs/x3-t30.h| 13 +-
9 files changed, 1029 insertions(+), 498 deletions(-)
delete mode 100644 board/lg/x3-t30/pinmux-config-x3.h
diff --git a/arch/arm/dts/tegra30-lg-p880.dts b/arch/arm/dts/tegra30-lg-p880.dts
index 81d364310d..1d5ca1459b 100644
--- a/arch/arm/dts/tegra30-lg-p880.dts
+++ b/arch/arm/dts/tegra30-lg-p880.dts
@@ -11,6 +11,96 @@
mmc1 = &sdmmc3; /* uSD slot */
};
+ pinmux@7868 {
+ state_default: pinmux {
+ /* WLAN SDIO pinmux */
+ host_wlan_wake {
+ nvidia,pins = "pu4";
+ nvidia,function = "pwm1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* GNSS UART-B pinmux */
+ uartb_rxd {
+ nvidia,pins = "uart2_rxd_pc3";
+ nvidia,function = "uartb";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ uartb_txd {
+ nvidia,pins = "uart2_txd_pc2";
+ nvidia,function = "uartb";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ gps_reset {
+ nvidia,pins = "kb_row7_pr7";
+ nvidia,function = "kbc";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* MicroSD pinmux */
+ sdmmc3_clk {
+ nvidia,pins = "sdmmc3_clk_pa6";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc3_data {
+ nvidia,pins = "sdmmc3_cmd_pa7",
+ "sdmmc3_dat0_pb7",
+ "sdmmc3_dat1_pb6",
+ "sdmmc3_dat2_pb5",
+ "sdmmc3_dat3_pb4";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ microsd_detect {
+ nvidia,pins = "clk2_out_pw5";
+ nvidia,function = "rsvd2";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* GPIO keys pinmux */
+ volume_up {
+ nvidia,pins = "ulpi_data6_po7";
+ nvidia,function = "spi2";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* Sensors pinmux */
+ current_alert_irq {
+ nvidia,pins = "uart2_rts_n_pj6";
+ nvidia,function = "uartb";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* AUDIO pinmux */
+ sub_mic_ldo {
+ nvidia,pins = "gmi_cs7_n_pi6";
+ nvidia,function = "gmi";
+ nvidia,pull = ;
+
[PATCH v1 8/8] board: compal: paz00: clean up the board
Since implementation of pinctrl driver for T20 Paz00 can switch
to device tree pinmux setup along with remove of board pinmux
and some minor device tree and defconfig tweaks.
Tested-by: Agneli # Toshiba AC100 T20
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra20-paz00.dts | 4 +--
board/compal/paz00/Makefile| 8 -
board/compal/paz00/paz00.c | 53 --
configs/paz00_defconfig| 3 ++
4 files changed, 5 insertions(+), 63 deletions(-)
delete mode 100644 board/compal/paz00/Makefile
delete mode 100644 board/compal/paz00/paz00.c
diff --git a/arch/arm/dts/tegra20-paz00.dts b/arch/arm/dts/tegra20-paz00.dts
index 5d8f21059f..5cf604e865 100644
--- a/arch/arm/dts/tegra20-paz00.dts
+++ b/arch/arm/dts/tegra20-paz00.dts
@@ -522,8 +522,8 @@
power-supply = <&vdd_bl_reg>;
pwms = <&pwm 0 500>;
- brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176
192 208 224 240 255>;
- default-brightness-level = <10>;
+ brightness-levels = <1 35 70 105 140 175 210 255>;
+ default-brightness-level = <2>;
backlight-boot-off;
};
diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile
deleted file mode 100644
index 22c26ed1f6..00
--- a/board/compal/paz00/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# Copyright (c) 2010-2012, NVIDIA CORPORATION. All rights reserved.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-
-obj-y := paz00.o
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
deleted file mode 100644
index d92eb16224..00
--- a/board/compal/paz00/paz00.c
+++ /dev/null
@@ -1,53 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (c) 2010-2012, NVIDIA CORPORATION. All rights reserved.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#ifdef CONFIG_MMC_SDHCI_TEGRA
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-void pin_mux_mmc(void)
-{
- /* SDMMC4: config 3, x8 on 2nd set of pins */
- pinmux_set_func(PMUX_PINGRP_ATB, PMUX_FUNC_SDIO4);
- pinmux_set_func(PMUX_PINGRP_GMA, PMUX_FUNC_SDIO4);
- pinmux_set_func(PMUX_PINGRP_GME, PMUX_FUNC_SDIO4);
-
- pinmux_tristate_disable(PMUX_PINGRP_ATB);
- pinmux_tristate_disable(PMUX_PINGRP_GMA);
- pinmux_tristate_disable(PMUX_PINGRP_GME);
-
- /* SDIO1: SDIO1_CLK, SDIO1_CMD, SDIO1_DAT[3:0] */
- pinmux_set_func(PMUX_PINGRP_SDIO1, PMUX_FUNC_SDIO1);
-
- pinmux_tristate_disable(PMUX_PINGRP_SDIO1);
-
- /* For power GPIO PV1 */
- pinmux_tristate_disable(PMUX_PINGRP_UAC);
- /* For CD GPIO PV5 */
- pinmux_tristate_disable(PMUX_PINGRP_GPV);
-}
-#endif
-
-#ifdef CONFIG_VIDEO
-/* this is a weak define that we are overriding */
-void pin_mux_display(void)
-{
- debug("init display pinmux\n");
-
- /* EN_VDD_PANEL GPIO A4 */
- pinmux_tristate_disable(PMUX_PINGRP_DAP2);
-}
-#endif
diff --git a/configs/paz00_defconfig b/configs/paz00_defconfig
index 9f3893dd60..c698493ad2 100644
--- a/configs/paz00_defconfig
+++ b/configs/paz00_defconfig
@@ -46,6 +46,9 @@ CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_TEGRA=y
+CONFIG_USB_ULPI_VIEWPORT=y
+CONFIG_USB_ULPI=y
+CONFIG_USB_KEYBOARD=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_VIDEO=y
--
2.40.1
[PATCH v1 7/8] board: htc: endeavoru: switch to DM pinmux
Drop the pinmux setup in the board in favor of setting it up in
the device tree. Device tree nodes match nodes used for the Linux
device tree and are set according to the downstream kernel.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra30-htc-endeavoru.dts| 1147 +
board/htc/endeavoru/endeavoru.c | 14 -
board/htc/endeavoru/pinmux-config-endeavoru.h | 362 --
3 files changed, 1147 insertions(+), 376 deletions(-)
delete mode 100644 board/htc/endeavoru/pinmux-config-endeavoru.h
diff --git a/arch/arm/dts/tegra30-htc-endeavoru.dts
b/arch/arm/dts/tegra30-htc-endeavoru.dts
index 21cd0f9207..dbff795bd8 100644
--- a/arch/arm/dts/tegra30-htc-endeavoru.dts
+++ b/arch/arm/dts/tegra30-htc-endeavoru.dts
@@ -52,6 +52,1153 @@
};
};
+ pinmux@7868 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+
+ state_default: pinmux {
+ /* PORT A */
+ clk_32k_out {
+ nvidia,pins = "clk_32k_out_pa0";
+ nvidia,function = "blink";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ bt_uart_cts {
+ nvidia,pins = "uart3_cts_n_pa1";
+ nvidia,function = "uartc";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ aud_aic3008_i2s {
+ nvidia,pins = "dap2_fs_pa2",
+ "dap2_sclk_pa3",
+ "dap2_din_pa4",
+ "dap2_dout_pa5";
+ nvidia,function = "i2s1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ wifi_sdio_clock {
+ nvidia,pins = "sdmmc3_clk_pa6";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ wifi_sdio_command {
+ nvidia,pins = "sdmmc3_cmd_pa7";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* PORT B */
+ mdm_imc_uart {
+ nvidia,pins = "gmi_a17_pb0",
+ "gmi_a18_pb1";
+ nvidia,function = "uartd";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ aud_3v3_en {
+ nvidia,pins = "lcd_pwr0_pb2",
+ "lcd_pclk_pb3";
+ nvidia,function = "displaya";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ wifi_sdio_data {
+ nvidia,pins = "sdmmc3_dat3_pb4",
+ "sdmmc3_dat2_pb5",
+ "sdmmc3_dat1_pb6",
+ "sdmmc3_dat0_pb7";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* PORT C */
+ bt_uart_rts {
+ nvidia,pins = "uart3_rts_n_pc0";
+ nvidia,function = "uartc";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ mdm_ap2bb_rst_pwrdwn {
+ nvidia,pins = "lcd_pwr1_pc1";
+ nvidia,function = "rsvd4";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+
Re: [PATCH v2 01/18] bloblist: Update the tag numbering
Hi all,
[...]
> common/bloblist.c | 16 +---
> include/bloblist.h | 65 --
> test/bloblist.c| 4 +--
> 3 files changed, 48 insertions(+), 37 deletions(-)
>
> diff --git a/common/bloblist.c b/common/bloblist.c
> index a22f6c12b0..349ceddea5 100644
> --- a/common/bloblist.c
> +++ b/common/bloblist.c
> @@ -36,16 +36,24 @@ static struct tag_name {
> enum bloblist_tag_t tag;
> const char *name;
> } tag_name[] = {
> - { BLOBLISTT_NONE, "(none)" },
> + { BLOBLISTT_VOID, "(void)" },
>
> /* BLOBLISTT_AREA_FIRMWARE_TOP */
> + { BLOBLISTT_CONTROL_FDT, "Control FDT" },
> + { BLOBLISTT_HOB_BLOCK, "HOB block" },
> + { BLOBLISTT_HOB_LIST, "HOB list" },
> + { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>
> /* BLOBLISTT_AREA_FIRMWARE */
> - { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> - { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> { BLOBLISTT_TCPA_LOG, "TPM log space" },
> - { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
There are some TPM Eventlog related entries that are missing here.
Can we add them?
> + { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> +
> + /* BLOBLISTT_AREA_ARM */
> + { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
> +
> + /* BLOBLISTT_AREA_OTHER */
> + { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
[...]
Thanks
/Ilias
Re: [PATCH v2 03/18] bloblist: Change the magic value
On Sat, 2 Dec 2023 at 20:33, Simon Glass wrote:
>
> On Mon, 27 Nov 2023 at 12:52, Raymond Mao wrote:
> >
> > From: Simon Glass
> >
> > This uses a new value with spec v0.9 so change it.
> >
> > Signed-off-by: Simon Glass
> > Co-developed-by: Raymond Mao
> > Signed-off-by: Raymond Mao
> > ---
> > Changes in v2
> > - Update the bloblist alignment to align to FW handoff spec v0.9.
> >
> > include/bloblist.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass
>
> But you will need a later patch (or update this one) due to [1]
>
> >
> > diff --git a/include/bloblist.h b/include/bloblist.h
> > index 1e4f1a6342..30441f922b 100644
> > --- a/include/bloblist.h
> > +++ b/include/bloblist.h
> > @@ -75,7 +75,7 @@
> >
> > enum {
> > BLOBLIST_VERSION= 0,
> > - BLOBLIST_MAGIC = 0xb00757a3,
> > + BLOBLIST_MAGIC = 0x6ed0ff,
> >
> > BLOBLIST_ALIGN_LOG2 = 3,
> > BLOBLIST_ALIGN = 1 << BLOBLIST_ALIGN_LOG2,
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
>
> [1] https://github.com/FirmwareHandoff/firmware_handoff/pull/24
With this change
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 04/18] bloblist: Set version to 1
On Mon, 27 Nov 2023 at 21:52, Raymond Mao wrote:
>
> From: Simon Glass
>
> The new bloblist for v0.9 has version 1 so update this value.
>
> Signed-off-by: Simon Glass
> Co-developed-by: Raymond Mao
> Signed-off-by: Raymond Mao
> ---
> Changes in v2
> - Update the bloblist alignment to align to FW handoff spec v0.9.
>
> include/bloblist.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/bloblist.h b/include/bloblist.h
> index 30441f922b..d70a7bad2e 100644
> --- a/include/bloblist.h
> +++ b/include/bloblist.h
> @@ -74,7 +74,7 @@
> #include
>
> enum {
> - BLOBLIST_VERSION= 0,
> + BLOBLIST_VERSION= 1,
> BLOBLIST_MAGIC = 0x6ed0ff,
>
> BLOBLIST_ALIGN_LOG2 = 3,
> --
> 2.25.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 05/18] bloblist: Access record hdr_size and tag via a function
On Mon, 27 Nov 2023 at 21:52, Raymond Mao wrote:
>
> From: Simon Glass
>
> These values currently use a simple field. With spec v0.9 they have moved
> to a packed format. Convert most accesses to use functions, so this change
> can be accommodated.
I don't really understand how the commit message is related to the changes.
What did the packed format affect that we need a function?
Thanks
/Ilias
>
> Signed-off-by: Simon Glass
> Signed-off-by: Raymond Mao
> ---
> common/bloblist.c | 38 +-
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/common/bloblist.c b/common/bloblist.c
> index e744c2b0c0..f084a32cfc 100644
> --- a/common/bloblist.c
> +++ b/common/bloblist.c
> @@ -82,13 +82,23 @@ static struct bloblist_rec *bloblist_first_blob(struct
> bloblist_hdr *hdr)
> return (struct bloblist_rec *)((void *)hdr + hdr->hdr_size);
> }
>
> +static inline uint rec_hdr_size(struct bloblist_rec *rec)
> +{
> + return rec->hdr_size;
> +}
> +
> +static inline uint rec_tag(struct bloblist_rec *rec)
> +{
> + return rec->tag;
> +}
> +
> static ulong bloblist_blob_end_ofs(struct bloblist_hdr *hdr,
>struct bloblist_rec *rec)
> {
> ulong offset;
>
> offset = (void *)rec - (void *)hdr;
> - offset += rec->hdr_size + ALIGN(rec->size, BLOBLIST_ALIGN);
> + offset += rec_hdr_size(rec) + ALIGN(rec->size, BLOBLIST_ALIGN);
>
> return offset;
> }
> @@ -117,7 +127,7 @@ static struct bloblist_rec *bloblist_findrec(uint tag)
> return NULL;
>
> foreach_rec(rec, hdr) {
> - if (rec->tag == tag)
> + if (rec_tag(rec) == tag)
> return rec;
> }
>
> @@ -156,7 +166,7 @@ static int bloblist_addrec(uint tag, int size, int
> align_log2,
> rec->spare = 0;
>
> /* Zero the record data */
> - memset((void *)rec + rec->hdr_size, '\0', rec->size);
> + memset((void *)rec + rec_hdr_size(rec), '\0', rec->size);
>
> hdr->alloced = new_alloced;
> *recp = rec;
> @@ -197,7 +207,7 @@ void *bloblist_find(uint tag, int size)
> if (size && size != rec->size)
> return NULL;
>
> - return (void *)rec + rec->hdr_size;
> + return (void *)rec + rec_hdr_size(rec);
> }
>
> void *bloblist_add(uint tag, int size, int align_log2)
> @@ -207,7 +217,7 @@ void *bloblist_add(uint tag, int size, int align_log2)
> if (bloblist_addrec(tag, size, align_log2, &rec))
> return NULL;
>
> - return (void *)rec + rec->hdr_size;
> + return (void *)rec + rec_hdr_size(rec);
> }
>
> int bloblist_ensure_size(uint tag, int size, int align_log2, void **blobp)
> @@ -218,7 +228,7 @@ int bloblist_ensure_size(uint tag, int size, int
> align_log2, void **blobp)
> ret = bloblist_ensurerec(tag, &rec, size, align_log2);
> if (ret)
> return ret;
> - *blobp = (void *)rec + rec->hdr_size;
> + *blobp = (void *)rec + rec_hdr_size(rec);
>
> return 0;
> }
> @@ -230,7 +240,7 @@ void *bloblist_ensure(uint tag, int size)
> if (bloblist_ensurerec(tag, &rec, size, 0))
> return NULL;
>
> - return (void *)rec + rec->hdr_size;
> + return (void *)rec + rec_hdr_size(rec);
> }
>
> int bloblist_ensure_size_ret(uint tag, int *sizep, void **blobp)
> @@ -243,7 +253,7 @@ int bloblist_ensure_size_ret(uint tag, int *sizep, void
> **blobp)
> *sizep = rec->size;
> else if (ret)
> return ret;
> - *blobp = (void *)rec + rec->hdr_size;
> + *blobp = (void *)rec + rec_hdr_size(rec);
>
> return 0;
> }
> @@ -279,7 +289,7 @@ static int bloblist_resize_rec(struct bloblist_hdr *hdr,
>
> /* Zero the new part of the blob */
> if (expand_by > 0) {
> - memset((void *)rec + rec->hdr_size + rec->size, '\0',
> + memset((void *)rec + rec_hdr_size(rec) + rec->size, '\0',
>new_size - rec->size);
> }
>
> @@ -313,8 +323,9 @@ static u32 bloblist_calc_chksum(struct bloblist_hdr *hdr)
> chksum = crc32(0, (unsigned char *)hdr,
>offsetof(struct bloblist_hdr, chksum));
> foreach_rec(rec, hdr) {
> - chksum = crc32(chksum, (void *)rec, rec->hdr_size);
> - chksum = crc32(chksum, (void *)rec + rec->hdr_size,
> rec->size);
> + chksum = crc32(chksum, (void *)rec, rec_hdr_size(rec));
> + chksum = crc32(chksum, (void *)rec + rec_hdr_size(rec),
> + rec->size);
> }
>
> return chksum;
> @@ -422,8 +433,9 @@ void bloblist_show_list(void)
> for (rec = bloblist_first_blob(hdr); rec;
> rec = bloblist_next_blob(hdr, rec)) {
> printf("%08lx %8x %4x %s\n",
> - (ulong)map_to_sysmem((void *)rec + rec->hdr_
Re: [PATCH v2 06/18] bloblist: Drop the flags value
On Mon, 27 Nov 2023 at 21:52, Raymond Mao wrote:
>
> From: Simon Glass
>
> There is no flags value in spec v0.9 so drop it.
>
> For now it is still present in the header, with an underscore, so that
> tests continue to pass.
Why? Can't we drop it overall?
Thanks
/Ilias
>
> Signed-off-by: Simon Glass
> Signed-off-by: Raymond Mao
> ---
> common/bloblist.c | 5 ++---
> include/bloblist.h | 6 ++
> test/bloblist.c| 45 +++--
> 3 files changed, 23 insertions(+), 33 deletions(-)
>
> diff --git a/common/bloblist.c b/common/bloblist.c
> index f084a32cfc..4d01772c3b 100644
> --- a/common/bloblist.c
> +++ b/common/bloblist.c
> @@ -331,7 +331,7 @@ static u32 bloblist_calc_chksum(struct bloblist_hdr *hdr)
> return chksum;
> }
>
> -int bloblist_new(ulong addr, uint size, uint flags)
> +int bloblist_new(ulong addr, uint size)
> {
> struct bloblist_hdr *hdr;
>
> @@ -343,7 +343,6 @@ int bloblist_new(ulong addr, uint size, uint flags)
> memset(hdr, '\0', sizeof(*hdr));
> hdr->version = BLOBLIST_VERSION;
> hdr->hdr_size = sizeof(*hdr);
> - hdr->flags = flags;
> hdr->magic = BLOBLIST_MAGIC;
> hdr->size = size;
> hdr->alloced = hdr->hdr_size;
> @@ -490,7 +489,7 @@ int bloblist_init(void)
> }
> log_debug("Creating new bloblist size %lx at %lx\n", size,
> addr);
> - ret = bloblist_new(addr, size, 0);
> + ret = bloblist_new(addr, size);
> } else {
> log_debug("Found existing bloblist size %lx at %lx\n", size,
> addr);
> diff --git a/include/bloblist.h b/include/bloblist.h
> index d70a7bad2e..2b898d0c55 100644
> --- a/include/bloblist.h
> +++ b/include/bloblist.h
> @@ -164,7 +164,6 @@ enum bloblist_tag_t {
> * @version: BLOBLIST_VERSION
> * @hdr_size: Size of this header, normally sizeof(struct bloblist_hdr). The
> * first bloblist_rec starts at this offset from the start of the header
> - * @flags: Space for BLOBLISTF... flags (none yet)
> * @size: Total size of the bloblist (non-zero if valid) including this
> header.
> * The bloblist extends for this many bytes from the start of this
> header.
> * When adding new records, the bloblist can grow up to this size.
> @@ -182,7 +181,7 @@ struct bloblist_hdr {
> u32 magic;
> u32 version;
> u32 hdr_size;
> - u32 flags;
> + u32 _flags;
>
> u32 size;
> u32 alloced;
> @@ -317,11 +316,10 @@ int bloblist_resize(uint tag, int new_size);
> *
> * @addr: Address of bloblist
> * @size: Initial size for bloblist
> - * @flags: Flags to use for bloblist
> * Return: 0 if OK, -EFAULT if addr is not aligned correctly, -ENOSPC is the
> * area is not large enough
> */
> -int bloblist_new(ulong addr, uint size, uint flags);
> +int bloblist_new(ulong addr, uint size);
>
> /**
> * bloblist_check() - Check if a bloblist exists
> diff --git a/test/bloblist.c b/test/bloblist.c
> index 8b435e27ca..36994c3dd4 100644
> --- a/test/bloblist.c
> +++ b/test/bloblist.c
> @@ -72,15 +72,15 @@ static int bloblist_test_init(struct unit_test_state *uts)
> hdr = clear_bloblist();
> ut_asserteq(-ENOENT, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> ut_asserteq_ptr(hdr, bloblist_check_magic(TEST_ADDR));
> hdr->version++;
> ut_asserteq(-EPROTONOSUPPORT, bloblist_check(TEST_ADDR,
> TEST_BLOBLIST_SIZE));
>
> - ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10, 0));
> - ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE, 0));
> - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> + ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10));
> + ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE));
> + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
>
> ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> ut_assertok(bloblist_finish());
> @@ -90,9 +90,6 @@ static int bloblist_test_init(struct unit_test_state *uts)
> ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> hdr->magic--;
>
> - hdr->flags++;
> - ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> -
> return 1;
> }
> BLOBLIST_TEST(bloblist_test_init, 0);
> @@ -106,7 +103,7 @@ static int bloblist_test_blob(struct unit_test_state *uts)
> /* At the start there should be no records */
> hdr = clear_bloblist();
> ut_assertnull(bloblist_find(TEST_TAG, TEST_BLOBLIST_SIZE));
> - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> + ut
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
On 12/4/23 09:09, Alessandro Rubini wrote: Hello. pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash. Isn't there some kobs-ng or whatever tool it was to properly initialize the NAND on MXS ? I didn't know. I used what u-boot offers, which works for me without vendor tools -- and dare I say I trust u-boot tools more than vendor tools?. The default environment even has the rule to reflash from any u-boot.nand you manage to put into RAM. The only issue is that u-boot.nand, as created, marks good blocks as bad by prefilling with zeores. But what about the bad block markers , do they get erased when you write this U-Boot image into the NAND ? I think the vendor tool somehow dealt with it (but it might have depended on some weird stuff in GPMI NAND), I don't think I ever used that tool myself.
Re: [PATCH v2 12/18] bloblist: Reduce bloblist header size
Ah I guess this fixes my concerns on patch #6
On Mon, 27 Nov 2023 at 21:53, Raymond Mao wrote:
>
> From: Simon Glass
>
> The v0.9 spec provides for a 16-byte header with fewer fields. Update
> the implementation to match this.
>
> This also adds an alignment field.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Raymond Mao
> ---
> include/bloblist.h | 26 +-
> test/bloblist.c| 6 +++---
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/include/bloblist.h b/include/bloblist.h
> index 745bcdd227..57625ea004 100644
> --- a/include/bloblist.h
> +++ b/include/bloblist.h
> @@ -164,30 +164,30 @@ enum bloblist_tag_t {
> * from the last.
> *
> * @magic: BLOBLIST_MAGIC
> + * @chksum: checksum for the entire bloblist allocated area. Since any of the
> + * blobs can be altered after being created, this checksum is only valid
> + * when the bloblist is finalised before jumping to the next stage of
> boot.
> + * This is the value needed to make all chechksummed bytes sum to 0
typos checksummed and finalized
[...]
With the typos fixed
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 06/18] bloblist: Drop the flags value
I just noticed that's fixed in path #12
On Mon, 4 Dec 2023 at 10:36, Ilias Apalodimas
wrote:
>
> On Mon, 27 Nov 2023 at 21:52, Raymond Mao wrote:
> >
> > From: Simon Glass
> >
> > There is no flags value in spec v0.9 so drop it.
> >
> > For now it is still present in the header, with an underscore, so that
> > tests continue to pass.
>
> Why? Can't we drop it overall?
>
> Thanks
> /Ilias
>
Reviewed-by: Ilias Apalodimas
> >
> > Signed-off-by: Simon Glass
> > Signed-off-by: Raymond Mao
> > ---
> > common/bloblist.c | 5 ++---
> > include/bloblist.h | 6 ++
> > test/bloblist.c| 45 +++--
> > 3 files changed, 23 insertions(+), 33 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index f084a32cfc..4d01772c3b 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -331,7 +331,7 @@ static u32 bloblist_calc_chksum(struct bloblist_hdr
> > *hdr)
> > return chksum;
> > }
> >
> > -int bloblist_new(ulong addr, uint size, uint flags)
> > +int bloblist_new(ulong addr, uint size)
> > {
> > struct bloblist_hdr *hdr;
> >
> > @@ -343,7 +343,6 @@ int bloblist_new(ulong addr, uint size, uint flags)
> > memset(hdr, '\0', sizeof(*hdr));
> > hdr->version = BLOBLIST_VERSION;
> > hdr->hdr_size = sizeof(*hdr);
> > - hdr->flags = flags;
> > hdr->magic = BLOBLIST_MAGIC;
> > hdr->size = size;
> > hdr->alloced = hdr->hdr_size;
> > @@ -490,7 +489,7 @@ int bloblist_init(void)
> > }
> > log_debug("Creating new bloblist size %lx at %lx\n", size,
> > addr);
> > - ret = bloblist_new(addr, size, 0);
> > + ret = bloblist_new(addr, size);
> > } else {
> > log_debug("Found existing bloblist size %lx at %lx\n", size,
> > addr);
> > diff --git a/include/bloblist.h b/include/bloblist.h
> > index d70a7bad2e..2b898d0c55 100644
> > --- a/include/bloblist.h
> > +++ b/include/bloblist.h
> > @@ -164,7 +164,6 @@ enum bloblist_tag_t {
> > * @version: BLOBLIST_VERSION
> > * @hdr_size: Size of this header, normally sizeof(struct bloblist_hdr).
> > The
> > * first bloblist_rec starts at this offset from the start of the
> > header
> > - * @flags: Space for BLOBLISTF... flags (none yet)
> > * @size: Total size of the bloblist (non-zero if valid) including this
> > header.
> > * The bloblist extends for this many bytes from the start of this
> > header.
> > * When adding new records, the bloblist can grow up to this size.
> > @@ -182,7 +181,7 @@ struct bloblist_hdr {
> > u32 magic;
> > u32 version;
> > u32 hdr_size;
> > - u32 flags;
> > + u32 _flags;
> >
> > u32 size;
> > u32 alloced;
> > @@ -317,11 +316,10 @@ int bloblist_resize(uint tag, int new_size);
> > *
> > * @addr: Address of bloblist
> > * @size: Initial size for bloblist
> > - * @flags: Flags to use for bloblist
> > * Return: 0 if OK, -EFAULT if addr is not aligned correctly, -ENOSPC is
> > the
> > * area is not large enough
> > */
> > -int bloblist_new(ulong addr, uint size, uint flags);
> > +int bloblist_new(ulong addr, uint size);
> >
> > /**
> > * bloblist_check() - Check if a bloblist exists
> > diff --git a/test/bloblist.c b/test/bloblist.c
> > index 8b435e27ca..36994c3dd4 100644
> > --- a/test/bloblist.c
> > +++ b/test/bloblist.c
> > @@ -72,15 +72,15 @@ static int bloblist_test_init(struct unit_test_state
> > *uts)
> > hdr = clear_bloblist();
> > ut_asserteq(-ENOENT, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> > - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > ut_asserteq_ptr(hdr, bloblist_check_magic(TEST_ADDR));
> > hdr->version++;
> > ut_asserteq(-EPROTONOSUPPORT, bloblist_check(TEST_ADDR,
> > TEST_BLOBLIST_SIZE));
> >
> > - ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10, 0));
> > - ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE, 0));
> > - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > + ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10));
> > + ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE));
> > + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> >
> > ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > ut_assertok(bloblist_finish());
> > @@ -90,9 +90,6 @@ static int bloblist_test_init(struct unit_test_state *uts)
> > ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> > hdr->magic--;
> >
> > - hdr->flags++;
> > - ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
>
[PATCH v2] clk: zynqmp: enable topsw_lsbus clock
Display port is using topsw_lsbus clock, it is failing while enabling the clock, so enable the topsw_lsbus clock. Signed-off-by: Sreekanth Sunnam Signed-off-by: Venkatesh Yadav Abbarapu --- Changes in v2: - Fixed the name to Sreekanth Sunnam. --- drivers/clk/clk_zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c index 1cfe0e25b1..c059b9e8e6 100644 --- a/drivers/clk/clk_zynqmp.c +++ b/drivers/clk/clk_zynqmp.c @@ -844,6 +844,7 @@ static int zynqmp_clk_enable(struct clk *clk) break; case qspi_ref ... can1_ref: case lpd_lsbus: + case topsw_lsbus: clkact_shift = 24; mask = 0x1; break; -- 2.17.1
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
On 12/4/23 09:42, Alessandro Rubini wrote: But what about the bad block markers , do they get erased when you write this U-Boot image into the NAND ? The image includes OOB data, because the rom-mandated map is different from normal standards. If OOB is zeroed, blocks appear as bad (correctly!). By memsetting to 0xff, before filling data structures and checksums, we get a binary that written with "nand write.raw" works properly (the rom is happy with the format and boots) but doesn't mark blocks as bad. Clearly my recollection of the MXS is not what it once was. Reviewed-by: Marek Vasut Thanks !
[PATCH v2] mtd: spi-nor: Add IS25LP02G flash support
Add support for ISSI 256MB flash IS25LP02G. This part supports 4byte
opcodes. It also supports dual and quad read.
Signed-off-by: Sreekanth Sunnam
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Fixed the name to Sreekanth Sunnam.
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3cb132dcff..9a73198227 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -217,6 +217,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25lp01g", 0x9d601b, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("is25lp02g", 0x9d6022, 0, 64 * 1024, 4096,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25wp008", 0x9d7014, 0, 64 * 1024, 16, SPI_NOR_QUAD_READ) },
{ INFO("is25wp016", 0x9d7015, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ) },
{ INFO("is25wp032", 0x9d7016, 0, 64 * 1024, 64,
--
2.17.1
Re: [PATCH v2] watchdog: Correct watchdog timeout print message
On 12/3/23 09:30, Chanho Park wrote:
The wdt_start function takes timeout_ms as a parameter and starts the
watchdog with this value. However, when you output the message, it shows
the default timeout value for the watchdog device.
So this patch fixes that part to output the correct timeout value.
Before -->
StarFive # wdt start 3000
WDT: Started watchdog@1307 without servicing (60s timeout)
After -->
StarFive # wdt start 3000
WDT: Started watchdog@1307 without servicing (3s timeout)
Fixes: c2fd0ca1a822 ("watchdog: Integrate watchdog triggering into the cyclic
framework")
Signed-off-by: Chanho Park
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
Change from v1:
- Use lldiv to fix a build error of m68k arch
drivers/watchdog/wdt-uclass.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index ed329284decb..417e8d7eef95 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -141,7 +142,7 @@ int wdt_start(struct udevice *dev, u64 timeout_ms, ulong
flags)
printf("WDT: Started %s with%s servicing %s (%ds timeout)\n",
dev->name, IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out",
- str, priv->timeout);
+ str, (u32)lldiv(timeout_ms, 1000));
}
return ret;
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
Please pull u-boot-watchdog/master
Hi Tom, please pull the following watchdog related fix: - Correct watchdog timeout print message (Chanho Park) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=327&view=results Thanks, Stefan The following changes since commit 5c4e9d0c74a8c2f8d0f4e0ab9cf44959298c2bad: Merge branch 'master-rpc-off' of https://source.denx.de/u-boot/custodians/u-boot-sh (2023-12-03 16:30:32 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git for you to fetch changes up to a341a0e01f8087904eccbf3fe7baba63a62f9674: watchdog: Correct watchdog timeout print message (2023-12-04 08:09:09 +0100) Chanho Park (1): watchdog: Correct watchdog timeout print message drivers/watchdog/wdt-uclass.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Re: [PATCH v1 0/8] Convert Tegra pinctrl to DM
On Mon, Dec 04, 2023 at 10:20:46AM +0200, Svyatoslav Ryhel wrote: > Create a DM supported wrapper arround existing Tegra pinmux logic. > This implementation is backwards compatible with all existing board > setups and early stages of setup. All new boards must be device tree > based. Linux dts pinmux nodes are fully compatible with this driver. > > As an example I have converted recently merged T30 boards to this > layout (I have those devices and was able to test them properly) and > Paz00 T20 board which was tested as well by owner. > > Svyatoslav Ryhel (8): > ARM: mach-tegra: rearrange SPL configs > drivers: pinctrl: create Tegra DM pinctrl driver > drivers: pinctrl: tegra: incorporate existing code > board: asus: grouper: switch to DM pinmux > board: lg: x3-t30: switch to DM pinmux > board: asus: transformer: switch to DM pinmux > board: htc: endeavoru: switch to DM pinmux > board: compal: paz00: clean up the board > > arch/arm/dts/tegra20-paz00.dts|4 +- > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 712 ++ > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 113 ++ > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 113 ++ > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 149 +++ > arch/arm/dts/tegra30-asus-p1801-t.dts | 982 ++ > arch/arm/dts/tegra30-asus-tf201.dts | 45 + > arch/arm/dts/tegra30-asus-tf300t.dts | 45 + > arch/arm/dts/tegra30-asus-tf300tg.dts | 128 ++ > arch/arm/dts/tegra30-asus-tf300tl.dts | 163 +++ > arch/arm/dts/tegra30-asus-tf600t.dts | 889 + > arch/arm/dts/tegra30-asus-tf700t.dts | 53 + > arch/arm/dts/tegra30-asus-transformer.dtsi| 984 ++ > arch/arm/dts/tegra30-htc-endeavoru.dts| 1147 + > arch/arm/dts/tegra30-lg-p880.dts | 90 ++ > arch/arm/dts/tegra30-lg-p895.dts | 93 ++ > arch/arm/dts/tegra30-lg-x3.dtsi | 845 > arch/arm/include/asm/arch-tegra114/pinmux.h | 303 + > arch/arm/include/asm/arch-tegra124/pinmux.h | 327 + > arch/arm/include/asm/arch-tegra20/pinmux.h| 291 + > arch/arm/include/asm/arch-tegra210/pinmux.h | 394 ++ > arch/arm/include/asm/arch-tegra30/pinmux.h| 381 ++ > arch/arm/mach-tegra/Kconfig | 16 +- > arch/arm/mach-tegra/Makefile |1 - > arch/arm/mach-tegra/board.c |6 +- > arch/arm/mach-tegra/board2.c |2 +- > arch/arm/mach-tegra/tegra114/Makefile |2 +- > arch/arm/mach-tegra/tegra124/Makefile |2 - > arch/arm/mach-tegra/tegra20/Makefile |2 +- > arch/arm/mach-tegra/tegra210/Makefile |1 - > arch/arm/mach-tegra/tegra30/Makefile |2 +- > board/asus/grouper/grouper.c | 18 - > board/asus/grouper/pinmux-config-grouper.h| 362 -- > .../pinmux-config-transformer.h | 365 -- > board/asus/transformer-t30/transformer-t30.c | 23 - > board/compal/paz00/Makefile |8 - > board/compal/paz00/paz00.c| 53 - > board/htc/endeavoru/endeavoru.c | 14 - > board/htc/endeavoru/pinmux-config-endeavoru.h | 362 -- > board/lg/x3-t30/Kconfig | 12 - > board/lg/x3-t30/configs/p880.config |1 - > board/lg/x3-t30/configs/p895.config |1 - > board/lg/x3-t30/pinmux-config-x3.h| 449 --- > board/lg/x3-t30/x3-t30.c | 23 - > configs/paz00_defconfig |3 + > drivers/pinctrl/Kconfig |1 + > drivers/pinctrl/Makefile |1 + > drivers/pinctrl/tegra/Kconfig | 18 + > drivers/pinctrl/tegra/Makefile| 16 + > .../pinctrl/tegra/funcmux-tegra114.c |0 > .../pinctrl/tegra/funcmux-tegra124.c |0 > .../pinctrl/tegra/funcmux-tegra20.c |0 > .../pinctrl/tegra/funcmux-tegra210.c |0 > .../pinctrl/tegra/funcmux-tegra30.c |0 > drivers/pinctrl/tegra/pinctrl-tegra.c | 248 > drivers/pinctrl/tegra/pinctrl-tegra20.c | 177 +++ > .../pinctrl/tegra}/pinmux-common.c|0 > .../pinctrl/tegra/pinmux-tegra114.c |0 > .../pinctrl/tegra/pinmux-tegra124.c |0 > .../pinctrl/tegra/pinmux-tegra20.c|0 > drivers/pinctrl/tegra/pinmux-tegra210.c | 190 +++ > .../pinctrl/tegra/pinmux-tegra30.c|0 > include/configs/x3-t30.h | 13 +- > 63 files changed, 8920 insertions(+), 1723 deletions(-) So we're adding 7000 extra lines here just to get the same level of functionality? Do we really want this? For things like the kernel this makes a bit more sense because we can have generic kernel images for a
Re: [PATCH 08/14] fastboot: Remove dependencies on CMDLINE
On Mon, Dec 4, 2023 at 1:31 AM Simon Glass wrote:
>
> It is possible to boot a kernel without CMDLINE being enabled. Update
> the implementation to handle this, and drop the condition from the
> FASTBOOT config.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/fastboot/Kconfig | 1 -
> drivers/fastboot/fb_common.c | 26 --
> 2 files changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index 11fc0fe1c800..837c6f1180da 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -1,5 +1,4 @@
> menu "Fastboot support"
> - depends on CMDLINE
>
> config FASTBOOT
> bool
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 07f5946d9ed1..85935380e79d 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -144,20 +145,17 @@ void fastboot_boot(void)
> {
> char *s;
>
> - s = env_get("fastboot_bootcmd");
> - if (s) {
> - run_command(s, CMD_FLAG_ENV);
> - } else if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
> - static char boot_addr_start[20];
> - static char *const bootm_args[] = {
> - "bootm", boot_addr_start, NULL
> - };
> -
> - snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
> -"%lx", fastboot_buf_addr);
> - printf("Booting kernel at %s...\n\n\n", boot_addr_start);
> -
> - do_bootm(NULL, 0, 2, bootm_args);
> + if (IS_ENABLED(CONFIG_CMDLINE)) {
> + s = env_get("fastboot_bootcmd");
> + if (s) {
> + run_command(s, CMD_FLAG_ENV);
> + return;
> + }
> + } else if (IS_ENABLED(CONFIG_BOOTM)) {
> + int ret;
> +
> + printf("Booting kernel at %lx...\n\n\n", fastboot_buf_addr);
> + ret = bootm_boot_start(fastboot_buf_addr, NULL);
>
> /*
> * This only happens if image is somehow faulty so we start
> --
Doesn't this change the logic? Previously if you didn't set
fastboot_bootcmd you'd fall into the bootm path (if CONFIG_BOOTM was
enabled), with this, if CONFIG_CMDLINE is enabled then you will never
hit the bootm path.
--
Alex Kiernan
Re: [PATCH 01/18] bootm: netbds: Drop passing of arguments
> From: Simon Glass
> Date: Sun, 3 Dec 2023 17:26:17 -0700
Hi Simon,
There is a typo in first line of the commit message: s/netbds/netbsd/.
> It isn't clear how useful it is to pass the arguments of bootm to the
> OS. For example, if "bootm 1000 2000 3000" is used, the three arguments
> at the end are passed to the OS. This seems like a strange approach,
> since the argument have already been parsed by U-Boot and processed.
>
> Rely instead on the "bootargs" mechanism, which is the standard
> approach.
It is a very Linuxy approach though.
I suspect this feature was added to pass kernel arguments for
"one-off" boots. For example
bootm -s
could be used to boot NetBSD in single-user mode and is quite a bit
more convenient than:
setenv bootargs -s
bootm
That said, I'm not sure to what extent the bootm command is used to
boot NetBSD these days. So this may not really matter.
Cheers,
Mark
> Signed-off-by: Simon Glass
> ---
>
> boot/bootm_os.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/boot/bootm_os.c b/boot/bootm_os.c
> index b92422171a84..b5055d78706c 100644
> --- a/boot/bootm_os.c
> +++ b/boot/bootm_os.c
> @@ -102,19 +102,9 @@ static int do_bootm_netbsd(int flag, int argc, char
> *const argv[],
> os_hdr = hdr;
> }
>
> - if (argc > 0) {
> - ulong len;
> - int i;
> -
> - for (i = 0, len = 0; i < argc; i += 1)
> - len += strlen(argv[i]) + 1;
> - cmdline = malloc(len);
> - copy_args(cmdline, argc, argv, ' ');
> - } else {
> - cmdline = env_get("bootargs");
> - if (cmdline == NULL)
> - cmdline = "";
> - }
> + cmdline = env_get("bootargs");
> + if (!cmdline)
> + cmdline = "";
>
> loader = (void (*)(struct bd_info *, struct legacy_img_hdr *, char *,
> char *))images->ep;
>
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>
>
[PATCH 1/6] dt-bindings: clock: add Mediatek MT8365 SoC clock bindings
This adds the clock bindings for Mediatek MT8365 SoC based on the dt-bindings in Linux tag v6.7-rc2. (commit c61978175ac1337f028ac1f95f16db84f4e5) Signed-off-by: Julien Masson --- MAINTAINERS | 1 + .../dt-bindings/clock/mediatek,mt8365-clk.h | 375 ++ 2 files changed, 376 insertions(+) create mode 100644 include/dt-bindings/clock/mediatek,mt8365-clk.h diff --git a/MAINTAINERS b/MAINTAINERS index 9f74c0aaca..ec5311c8a2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -411,6 +411,7 @@ F: drivers/watchdog/mtk_wdt.c F: drivers/net/mtk_eth.c F: drivers/net/mtk_eth.h F: drivers/reset/reset-mediatek.c +F: include/dt-bindings/clock/mediatek,* F: tools/mtk_image.c F: tools/mtk_image.h F: tools/mtk_nand_headers.c diff --git a/include/dt-bindings/clock/mediatek,mt8365-clk.h b/include/dt-bindings/clock/mediatek,mt8365-clk.h new file mode 100644 index 00..e5cb8a19ab --- /dev/null +++ b/include/dt-bindings/clock/mediatek,mt8365-clk.h @@ -0,0 +1,375 @@ +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + * + * Copyright (c) 2022 MediaTek Inc. + */ + +#ifndef _DT_BINDINGS_CLK_MT8365_H +#define _DT_BINDINGS_CLK_MT8365_H + +/* TOPCKGEN */ +#define CLK_TOP_CLK_NULL 0 +#define CLK_TOP_I2S0_BCK 1 +#define CLK_TOP_DSI0_LNTC_DSICK2 +#define CLK_TOP_VPLL_DPIX 3 +#define CLK_TOP_LVDSTX_CLKDIG_CTS 4 +#define CLK_TOP_MFGPLL 5 +#define CLK_TOP_SYSPLL_D2 6 +#define CLK_TOP_SYSPLL1_D2 7 +#define CLK_TOP_SYSPLL1_D4 8 +#define CLK_TOP_SYSPLL1_D8 9 +#define CLK_TOP_SYSPLL1_D1610 +#define CLK_TOP_SYSPLL_D3 11 +#define CLK_TOP_SYSPLL2_D2 12 +#define CLK_TOP_SYSPLL2_D4 13 +#define CLK_TOP_SYSPLL2_D8 14 +#define CLK_TOP_SYSPLL_D5 15 +#define CLK_TOP_SYSPLL3_D2 16 +#define CLK_TOP_SYSPLL3_D4 17 +#define CLK_TOP_SYSPLL_D7 18 +#define CLK_TOP_SYSPLL4_D2 19 +#define CLK_TOP_SYSPLL4_D4 20 +#define CLK_TOP_UNIVPLL21 +#define CLK_TOP_UNIVPLL_D2 22 +#define CLK_TOP_UNIVPLL1_D223 +#define CLK_TOP_UNIVPLL1_D424 +#define CLK_TOP_UNIVPLL_D3 25 +#define CLK_TOP_UNIVPLL2_D226 +#define CLK_TOP_UNIVPLL2_D427 +#define CLK_TOP_UNIVPLL2_D828 +#define CLK_TOP_UNIVPLL2_D32 29 +#define CLK_TOP_UNIVPLL_D5 30 +#define CLK_TOP_UNIVPLL3_D231 +#define CLK_TOP_UNIVPLL3_D432 +#define CLK_TOP_MMPLL 33 +#define CLK_TOP_MMPLL_D2 34 +#define CLK_TOP_LVDSPLL_D2 35 +#define CLK_TOP_LVDSPLL_D4 36 +#define CLK_TOP_LVDSPLL_D8 37 +#define CLK_TOP_LVDSPLL_D1638 +#define CLK_TOP_USB20_192M 39 +#define CLK_TOP_USB20_192M_D4 40 +#define CLK_TOP_USB20_192M_D8 41 +#define CLK_TOP_USB20_192M_D16 42 +#define CLK_TOP_USB20_192M_D32 43 +#define CLK_TOP_APLL1 44 +#define CLK_TOP_APLL1_D2 45 +#define CLK_TOP_APLL1_D4 46 +#define CLK_TOP_APLL1_D8 47 +#define CLK_TOP_APLL2 48 +#define CLK_TOP_APLL2_D2 49 +#define CLK_TOP_APLL2_D4 50 +#define CLK_TOP_APLL2_D8 51 +#define CLK_TOP_SYS_26M_D2 52 +#define CLK_TOP_MSDCPLL53 +#define CLK_TOP_MSDCPLL_D2 54 +#define CLK_TOP_DSPPLL 55 +#define CLK_TOP_DSPPLL_D2 56 +#define CLK_TOP_DSPPLL_D4 57 +#define CLK_TOP_DSPPLL_D8 58 +#define CLK_TOP_APUPLL 59 +#define CLK_TOP_CLK26M_D52 60 +#define CLK_TOP_AXI_SEL61 +#define CLK_TOP_MEM_SEL62 +#define CLK_TOP_MM_SEL 63 +#define CLK_TOP_SCP_SEL64 +#define CLK_TOP_MFG_SEL65 +#define CLK_TOP_ATB_SEL66 +#define CLK_TOP_CAMTG_SEL 67 +#define CLK_TOP_CAMTG1_SEL 68 +#define CLK_TOP_UART_SEL 69 +#define CLK_TOP_SPI_SEL70 +#define CLK_TOP_MSDC50_0_HC_SEL71 +#define CLK_TOP_MSDC2_2_HC_SEL 72 +#define CLK_TOP_MSDC50_0_SEL 73 +#define CLK_TOP_MSDC50_2_SEL 74 +#define CLK_TOP_MSDC30_1_SEL 75 +#define CLK_TOP_AUDIO_SEL 76 +#define CLK_TOP_AUD_INTBUS_SEL 77 +#define CLK_TOP_AUD_1_SEL 78 +#define CLK_TOP_AUD_2_SEL 79 +#define CLK_TOP_AUD_ENGEN1_SEL 80 +#define CLK_TOP_AUD_ENGEN2_SEL 81 +#define CLK_TOP_AUD_SPDIF_SEL 82 +#define CLK_TOP_DISP_PWM_SEL 83 +#define CLK_TOP_DXCC_SEL 84 +#define CLK_TOP_SSUSB_SYS
[PATCH 0/6] Add support for MediaTek MT8365 EVK Board
This patch series add the support for the MediaTek MT8365 EVK Board [1]. Most of the code have been copied/adapted from Linux tag v6.7-rc2. For now we only enable/test these features: Boot, UART, Watchdog and MMC. [1] https://www.mediatek.com/products/iot-genio/mediatek-genio-350-evk Julien Masson (6): dt-bindings: clock: add Mediatek MT8365 SoC clock bindings clk: mediatek: add clock driver support for MediaTek MT8365 SoC dt-bindings: power: add power-domain header for MediaTek MT8365 SoC arm: mediatek: add support for MediaTek MT8365 SoC dt-bindings: clock: add Mediatek MT8365 pinctrl bindings board: mediatek: add MT8365 EVK board support MAINTAINERS | 2 + arch/arm/dts/mt6357.dtsi | 282 ++ arch/arm/dts/mt8365-evk.dts | 418 + arch/arm/dts/mt8365.dtsi | 840 + arch/arm/mach-mediatek/Kconfig| 9 + arch/arm/mach-mediatek/Makefile | 1 + arch/arm/mach-mediatek/mt8365/Makefile| 3 + arch/arm/mach-mediatek/mt8365/init.c | 51 ++ board/mediatek/mt8365_evk/MAINTAINERS | 6 + board/mediatek/mt8365_evk/Makefile| 3 + board/mediatek/mt8365_evk/mt8365_evk.c| 33 + configs/mt8365_evk_defconfig | 19 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt8365.c | 766 include/configs/mt8365.h | 12 + .../dt-bindings/clock/mediatek,mt8365-clk.h | 375 include/dt-bindings/pinctrl/mt8365-pinfunc.h | 858 ++ .../dt-bindings/power/mediatek,mt8365-power.h | 19 + 18 files changed, 3698 insertions(+) create mode 100644 arch/arm/dts/mt6357.dtsi create mode 100644 arch/arm/dts/mt8365-evk.dts create mode 100644 arch/arm/dts/mt8365.dtsi create mode 100644 arch/arm/mach-mediatek/mt8365/Makefile create mode 100644 arch/arm/mach-mediatek/mt8365/init.c create mode 100644 board/mediatek/mt8365_evk/MAINTAINERS create mode 100644 board/mediatek/mt8365_evk/Makefile create mode 100644 board/mediatek/mt8365_evk/mt8365_evk.c create mode 100644 configs/mt8365_evk_defconfig create mode 100644 drivers/clk/mediatek/clk-mt8365.c create mode 100644 include/configs/mt8365.h create mode 100644 include/dt-bindings/clock/mediatek,mt8365-clk.h create mode 100644 include/dt-bindings/pinctrl/mt8365-pinfunc.h create mode 100644 include/dt-bindings/power/mediatek,mt8365-power.h -- 2.43.0
[PATCH 2/6] clk: mediatek: add clock driver support for MediaTek MT8365 SoC
This patch adds clock driver support for MediaTek MT8365 SoC.
The changes are based on the Linux source code tag v6.7-rc2.
clk-mt8365.c has been written based on these kernel files:
- clk-mt8365.c (a96cbb146a9736f501fe66ebda6a9018735e5e8a)
- clk-mt8365-apmixedsys.c (65c9ad77cbc0eed78db94d80041aba675cfbdfa9)
And adapted following the clk attributes supported by U-Boot.
Signed-off-by: Julien Masson
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt8365.c | 766 ++
2 files changed, 767 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt8365.c
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index e74c6f9780..e631f79e4d 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_TARGET_MT7986) += clk-mt7986.o
obj-$(CONFIG_TARGET_MT7981) += clk-mt7981.o
obj-$(CONFIG_TARGET_MT7988) += clk-mt7988.o
obj-$(CONFIG_TARGET_MT8183) += clk-mt8183.o
+obj-$(CONFIG_TARGET_MT8365) += clk-mt8365.o
obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
diff --git a/drivers/clk/mediatek/clk-mt8365.c
b/drivers/clk/mediatek/clk-mt8365.c
new file mode 100644
index 00..61ccd4a210
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8365.c
@@ -0,0 +1,766 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT8365 SoC
+ *
+ * Copyright (C) 2023 BayLibre, SAS
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Julien Masson
+ * Author: Fabien Parent
+ * Author: Weiyi Lu
+ */
+
+#include
+#include
+#include "clk-mtk.h"
+
+/* apmixedsys */
+#define MT8365_PLL_FMAX(3800UL * MHZ)
+#define MT8365_PLL_FMIN(1500UL * MHZ)
+#define CON0_MT8365_RST_BARBIT(23)
+#define PLL_AO BIT(1)
+
+#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg, \
+ _pd_shift, _pcw_reg, _pcw_shift, _rst_bar_mask, _pcw_chg_reg) { \
+ .id = _id, \
+ .reg = _reg,\
+ .pwr_reg = _pwr_reg,\
+ .en_mask = _en_mask,\
+ .pd_reg = _pd_reg, \
+ .pd_shift = _pd_shift, \
+ .flags = _flags,\
+ .rst_bar_mask = _rst_bar_mask, \
+ .fmax = MT8365_PLL_FMAX,\
+ .fmin = MT8365_PLL_FMIN,\
+ .pcwbits = _pcwbits,\
+ .pcwibits = 8, \
+ .pcw_reg = _pcw_reg,\
+ .pcw_shift = _pcw_shift,\
+ .pcw_chg_reg = _pcw_chg_reg,\
+ }
+
+static const struct mtk_pll_data apmixed_plls[] = {
+ PLL(CLK_APMIXED_ARMPLL, 0x030C, 0x0318, 0x0001, PLL_AO, 22, 0x0310,
+ 24, 0x0310, 0, 0, 0),
+ PLL(CLK_APMIXED_MAINPLL, 0x0228, 0x0234, 0xFF01, HAVE_RST_BAR, 22,
+ 0x022C, 24, 0x022C, 0, CON0_MT8365_RST_BAR, 0),
+ PLL(CLK_APMIXED_UNIVPLL, 0x0208, 0x0214, 0xFF01, HAVE_RST_BAR, 22,
+ 0x020C, 24, 0x020C, 0, CON0_MT8365_RST_BAR, 0),
+ PLL(CLK_APMIXED_MFGPLL, 0x0218, 0x0224, 0x0001, 0, 22, 0x021C, 24,
+ 0x021C, 0, 0, 0),
+ PLL(CLK_APMIXED_MSDCPLL, 0x0350, 0x035C, 0x0001, 0, 22, 0x0354, 24,
+ 0x0354, 0, 0, 0),
+ PLL(CLK_APMIXED_MMPLL, 0x0330, 0x033C, 0x0001, 0, 22, 0x0334, 24,
+ 0x0334, 0, 0, 0),
+ PLL(CLK_APMIXED_APLL1, 0x031C, 0x032C, 0x0001, 0, 32, 0x0320, 24,
+ 0x0324, 0, 0, 0x0320),
+ PLL(CLK_APMIXED_APLL2, 0x0360, 0x0370, 0x0001, 0, 32, 0x0364, 24,
+ 0x0368, 0, 0, 0x0364),
+ PLL(CLK_APMIXED_LVDSPLL, 0x0374, 0x0380, 0x0001, 0, 22, 0x0378, 24,
+ 0x0378, 0, 0, 0),
+ PLL(CLK_APMIXED_DSPPLL, 0x0390, 0x039C, 0x0001, 0, 22, 0x0394, 24,
+ 0x0394, 0, 0, 0),
+ PLL(CLK_APMIXED_APUPLL, 0x03A0, 0x03AC, 0x0001, 0, 22, 0x03A4, 24,
+ 0x03A4, 0, 0, 0),
+};
+
+/* topckgen */
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+ FIXED_CLK(CLK_TOP_CLK_NULL, CLK_XTAL, 0),
+ FIXED_CLK(CLK_TOP_I2S0_BCK, CLK_XTAL, 2600),
+ FIXED_CLK(CLK_TOP_DSI0_LNTC_DSICK, CLK_TOP_CLK26M, 7500),
+ FIXED_CLK(CLK_TOP_VPLL_DPIX, CLK_TOP_CLK26M, 7500),
+ FIXED_CLK(CLK_TOP_LVDSTX_CLKDIG_CTS, CLK_TOP_CLK26M, 5250),
+};
+
+#define PLL_FACTOR(_id, _name, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mu
[PATCH 3/6] dt-bindings: power: add power-domain header for MediaTek MT8365 SoC
Add power-domain header for MediaTek MT8365 SoC copied from Linux source code tag v6.7-rc2. (commit a1571f1f333c2fced076f0d54ed771d1838d827f) Signed-off-by: Julien Masson --- MAINTAINERS | 1 + .../dt-bindings/power/mediatek,mt8365-power.h | 19 +++ 2 files changed, 20 insertions(+) create mode 100644 include/dt-bindings/power/mediatek,mt8365-power.h diff --git a/MAINTAINERS b/MAINTAINERS index ec5311c8a2..3b13f26e76 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -412,6 +412,7 @@ F: drivers/net/mtk_eth.c F: drivers/net/mtk_eth.h F: drivers/reset/reset-mediatek.c F: include/dt-bindings/clock/mediatek,* +F: include/dt-bindings/power/mediatek,* F: tools/mtk_image.c F: tools/mtk_image.h F: tools/mtk_nand_headers.c diff --git a/include/dt-bindings/power/mediatek,mt8365-power.h b/include/dt-bindings/power/mediatek,mt8365-power.h new file mode 100644 index 00..e6cfd0ec78 --- /dev/null +++ b/include/dt-bindings/power/mediatek,mt8365-power.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */ +/* + * Copyright (c) 2022 MediaTek Inc. + */ + +#ifndef _DT_BINDINGS_POWER_MT8365_POWER_H +#define _DT_BINDINGS_POWER_MT8365_POWER_H + +#define MT8365_POWER_DOMAIN_MM 0 +#define MT8365_POWER_DOMAIN_CONN 1 +#define MT8365_POWER_DOMAIN_MFG2 +#define MT8365_POWER_DOMAIN_AUDIO 3 +#define MT8365_POWER_DOMAIN_CAM4 +#define MT8365_POWER_DOMAIN_DSP5 +#define MT8365_POWER_DOMAIN_VDEC 6 +#define MT8365_POWER_DOMAIN_VENC 7 +#define MT8365_POWER_DOMAIN_APU8 + +#endif /* _DT_BINDINGS_POWER_MT8365_POWER_H */ -- 2.43.0
[PATCH 4/6] arm: mediatek: add support for MediaTek MT8365 SoC
This patch adds basic support for MediaTek MT8365 SoC.
The dtsi has been copied from Linux source code tag v6.7-rc2.
(commit 9b5d64654ea8f51fe1e8e29ca1777b620be8fb7c)
Signed-off-by: Julien Masson
---
arch/arm/dts/mt8365.dtsi | 840 +
arch/arm/mach-mediatek/Kconfig | 9 +
arch/arm/mach-mediatek/Makefile| 1 +
arch/arm/mach-mediatek/mt8365/Makefile | 3 +
arch/arm/mach-mediatek/mt8365/init.c | 51 ++
include/configs/mt8365.h | 12 +
6 files changed, 916 insertions(+)
create mode 100644 arch/arm/dts/mt8365.dtsi
create mode 100644 arch/arm/mach-mediatek/mt8365/Makefile
create mode 100644 arch/arm/mach-mediatek/mt8365/init.c
create mode 100644 include/configs/mt8365.h
diff --git a/arch/arm/dts/mt8365.dtsi b/arch/arm/dts/mt8365.dtsi
new file mode 100644
index 00..24581f7410
--- /dev/null
+++ b/arch/arm/dts/mt8365.dtsi
@@ -0,0 +1,840 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * (C) 2018 MediaTek Inc.
+ * Copyright (C) 2022 BayLibre SAS
+ * Fabien Parent
+ * Bernhard Rosenkränzer
+ */
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8365";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cluster0_opp: opp-table-0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-85000 {
+ opp-hz = /bits/ 64 <85000>;
+ opp-microvolt = <65>;
+ };
+
+ opp-91800 {
+ opp-hz = /bits/ 64 <91800>;
+ opp-microvolt = <668750>;
+ };
+
+ opp-98700 {
+ opp-hz = /bits/ 64 <98700>;
+ opp-microvolt = <687500>;
+ };
+
+ opp-105600 {
+ opp-hz = /bits/ 64 <105600>;
+ opp-microvolt = <706250>;
+ };
+
+ opp-112500 {
+ opp-hz = /bits/ 64 <112500>;
+ opp-microvolt = <725000>;
+ };
+
+ opp-121600 {
+ opp-hz = /bits/ 64 <121600>;
+ opp-microvolt = <75>;
+ };
+
+ opp-130800 {
+ opp-hz = /bits/ 64 <130800>;
+ opp-microvolt = <775000>;
+ };
+
+ opp-14 {
+ opp-hz = /bits/ 64 <14>;
+ opp-microvolt = <80>;
+ };
+
+ opp-146600 {
+ opp-hz = /bits/ 64 <146600>;
+ opp-microvolt = <825000>;
+ };
+
+ opp-153300 {
+ opp-hz = /bits/ 64 <153300>;
+ opp-microvolt = <85>;
+ };
+
+ opp-163300 {
+ opp-hz = /bits/ 64 <163300>;
+ opp-microvolt = <887500>;
+ };
+
+ opp-17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <912500>;
+ };
+
+ opp-176700 {
+ opp-hz = /bits/ 64 <176700>;
+ opp-microvolt = <937500>;
+ };
+
+ opp-183400 {
+ opp-hz = /bits/ 64 <183400>;
+ opp-microvolt = <962500>;
+ };
+
+ opp-191700 {
+ opp-hz = /bits/ 64 <191700>;
+ opp-microvolt = <993750>;
+ };
+
+ opp-200100 {
+ opp-hz = /bits/ 64 <200100>;
+ opp-microvolt = <1025000>;
+ };
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ #cooling-cells = <2>;
+ enable-method = "psci";
+
[PATCH 5/6] dt-bindings: clock: add Mediatek MT8365 pinctrl bindings
This adds the pinctrl bindings for Mediatek MT8365 SoC based on the dt-bindings in Linux tag v6.7-rc2. (commit 8b4c397d88d97d4fd9c3f3527aa66688b1a3387a) Signed-off-by: Julien Masson --- include/dt-bindings/pinctrl/mt8365-pinfunc.h | 858 +++ 1 file changed, 858 insertions(+) create mode 100644 include/dt-bindings/pinctrl/mt8365-pinfunc.h diff --git a/include/dt-bindings/pinctrl/mt8365-pinfunc.h b/include/dt-bindings/pinctrl/mt8365-pinfunc.h new file mode 100644 index 00..e2ec8af57d --- /dev/null +++ b/include/dt-bindings/pinctrl/mt8365-pinfunc.h @@ -0,0 +1,858 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2021 MediaTek Inc. + */ +#ifndef __MT8365_PINFUNC_H +#define __MT8365_PINFUNC_H + +#include + +#define MT8365_PIN_0_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0) +#define MT8365_PIN_0_GPIO0__FUNC_DPI_D0 (MTK_PIN_NO(0) | 1) +#define MT8365_PIN_0_GPIO0__FUNC_PWM_A (MTK_PIN_NO(0) | 2) +#define MT8365_PIN_0_GPIO0__FUNC_I2S2_BCK (MTK_PIN_NO(0) | 3) +#define MT8365_PIN_0_GPIO0__FUNC_EXT_TXD0 (MTK_PIN_NO(0) | 4) +#define MT8365_PIN_0_GPIO0__FUNC_CONN_MCU_TDO (MTK_PIN_NO(0) | 5) +#define MT8365_PIN_0_GPIO0__FUNC_DBG_MON_A0 (MTK_PIN_NO(0) | 7) + +#define MT8365_PIN_1_GPIO1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0) +#define MT8365_PIN_1_GPIO1__FUNC_DPI_D1 (MTK_PIN_NO(1) | 1) +#define MT8365_PIN_1_GPIO1__FUNC_PWM_B (MTK_PIN_NO(1) | 2) +#define MT8365_PIN_1_GPIO1__FUNC_I2S2_LRCK (MTK_PIN_NO(1) | 3) +#define MT8365_PIN_1_GPIO1__FUNC_EXT_TXD1 (MTK_PIN_NO(1) | 4) +#define MT8365_PIN_1_GPIO1__FUNC_CONN_MCU_DBGACK_N (MTK_PIN_NO(1) | 5) +#define MT8365_PIN_1_GPIO1__FUNC_DBG_MON_A1 (MTK_PIN_NO(1) | 7) + +#define MT8365_PIN_2_GPIO2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0) +#define MT8365_PIN_2_GPIO2__FUNC_DPI_D2 (MTK_PIN_NO(2) | 1) +#define MT8365_PIN_2_GPIO2__FUNC_PWM_C (MTK_PIN_NO(2) | 2) +#define MT8365_PIN_2_GPIO2__FUNC_I2S2_MCK (MTK_PIN_NO(2) | 3) +#define MT8365_PIN_2_GPIO2__FUNC_EXT_TXD2 (MTK_PIN_NO(2) | 4) +#define MT8365_PIN_2_GPIO2__FUNC_CONN_MCU_DBGI_N (MTK_PIN_NO(2) | 5) +#define MT8365_PIN_2_GPIO2__FUNC_DBG_MON_A2 (MTK_PIN_NO(2) | 7) + +#define MT8365_PIN_3_GPIO3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0) +#define MT8365_PIN_3_GPIO3__FUNC_DPI_D3 (MTK_PIN_NO(3) | 1) +#define MT8365_PIN_3_GPIO3__FUNC_CLKM0 (MTK_PIN_NO(3) | 2) +#define MT8365_PIN_3_GPIO3__FUNC_I2S2_DI (MTK_PIN_NO(3) | 3) +#define MT8365_PIN_3_GPIO3__FUNC_EXT_TXD3 (MTK_PIN_NO(3) | 4) +#define MT8365_PIN_3_GPIO3__FUNC_CONN_MCU_TCK (MTK_PIN_NO(3) | 5) +#define MT8365_PIN_3_GPIO3__FUNC_CONN_MCU_AICE_TCKC (MTK_PIN_NO(3) | 6) +#define MT8365_PIN_3_GPIO3__FUNC_DBG_MON_A3 (MTK_PIN_NO(3) | 7) + +#define MT8365_PIN_4_GPIO4__FUNC_GPIO4 (MTK_PIN_NO(4) | 0) +#define MT8365_PIN_4_GPIO4__FUNC_DPI_D4 (MTK_PIN_NO(4) | 1) +#define MT8365_PIN_4_GPIO4__FUNC_CLKM1 (MTK_PIN_NO(4) | 2) +#define MT8365_PIN_4_GPIO4__FUNC_I2S1_BCK (MTK_PIN_NO(4) | 3) +#define MT8365_PIN_4_GPIO4__FUNC_EXT_TXC (MTK_PIN_NO(4) | 4) +#define MT8365_PIN_4_GPIO4__FUNC_CONN_MCU_TDI (MTK_PIN_NO(4) | 5) +#define MT8365_PIN_4_GPIO4__FUNC_VDEC_TEST_CK (MTK_PIN_NO(4) | 6) +#define MT8365_PIN_4_GPIO4__FUNC_DBG_MON_A4 (MTK_PIN_NO(4) | 7) + +#define MT8365_PIN_5_GPIO5__FUNC_GPIO5 (MTK_PIN_NO(5) | 0) +#define MT8365_PIN_5_GPIO5__FUNC_DPI_D5 (MTK_PIN_NO(5) | 1) +#define MT8365_PIN_5_GPIO5__FUNC_CLKM2 (MTK_PIN_NO(5) | 2) +#define MT8365_PIN_5_GPIO5__FUNC_I2S1_LRCK (MTK_PIN_NO(5) | 3) +#define MT8365_PIN_5_GPIO5__FUNC_EXT_RXER (MTK_PIN_NO(5) | 4) +#define MT8365_PIN_5_GPIO5__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(5) | 5) +#define MT8365_PIN_5_GPIO5__FUNC_MM_TEST_CK (MTK_PIN_NO(5) | 6) +#define MT8365_PIN_5_GPIO5__FUNC_DBG_MON_A5 (MTK_PIN_NO(5) | 7) + +#define MT8365_PIN_6_GPIO6__FUNC_GPIO6 (MTK_PIN_NO(6) | 0) +#define MT8365_PIN_6_GPIO6__FUNC_DPI_D6 (MTK_PIN_NO(6) | 1) +#define MT8365_PIN_6_GPIO6__FUNC_CLKM3 (MTK_PIN_NO(6) | 2) +#define MT8365_PIN_6_GPIO6__FUNC_I2S1_MCK (MTK_PIN_NO(6) | 3) +#define MT8365_PIN_6_GPIO6__FUNC_EXT_RXC (MTK_PIN_NO(6) | 4) +#define MT8365_PIN_6_GPIO6__FUNC_CONN_MCU_TMS (MTK_PIN_NO(6) | 5) +#define MT8365_PIN_6_GPIO6__FUNC_CONN_MCU_AICE_TMSC (MTK_PIN_NO(6) | 6) +#define MT8365_PIN_6_GPIO6__FUNC_DBG_MON_A6 (MTK_PIN_NO(6) | 7) + +#define MT8365_PIN_7_GPIO7__FUNC_GPIO7 (MTK_PIN_NO(7) | 0) +#define MT8365_PIN_7_GPIO7__FUNC_DPI_D7 (MTK_PIN_NO(7) | 1) +#define MT8365_PIN_7_GPIO7__FUNC_I2S1_DO (MTK_PIN_NO(7) | 3) +#define MT8365_PIN_7_GPIO7__FUNC_EXT_RXDV (MTK_PIN_NO(7) | 4) +#define MT8365_PIN_7_GPIO7__FUNC_CONN_DSP_JCK (MTK_PIN_NO(7) | 5) +#define MT8365_PIN_7_GPIO7__FUNC_DBG_MON_A7 (MTK_PIN_NO(7) | 7) + +#define MT8365_PIN_8_GPIO8__FUNC_GPIO8 (MTK_PIN_NO(8) | 0) +#define MT8365_PIN_8_GPIO8__FUNC_DPI_D8 (MTK_PIN_NO(8) | 1) +#define MT8365_PIN_8_GPIO8__FUNC_SPI_CLK (MTK_PIN_NO(8) | 2) +#define MT8365_PIN_8_GPIO8__FUNC_I2S0_BCK (MTK_PIN_NO(8) | 3) +#define MT8365_PIN_8_GPIO8__FUNC_EXT_RXD0 (MTK_PIN_NO(8) | 4) +#define MT8365_PIN_8_GPIO8__FUNC_CONN_DSP_JINTP (MTK_PIN_NO(8) | 5) +#define MT8365_PIN_8_GPIO8__FUNC_DBG_MON_A8 (MTK_PIN_NO(8) | 7) + +#define MT8365_PIN_9_GPIO9__FUNC_GPIO9 (M
[PATCH 6/6] board: mediatek: add MT8365 EVK board support
This adds support for the MT8365 EVK board with the following
features enabled/tested: Boot, UART, Watchdog and MMC.
Signed-off-by: Julien Masson
---
arch/arm/dts/mt6357.dtsi | 282 +
arch/arm/dts/mt8365-evk.dts| 418 +
board/mediatek/mt8365_evk/MAINTAINERS | 6 +
board/mediatek/mt8365_evk/Makefile | 3 +
board/mediatek/mt8365_evk/mt8365_evk.c | 33 ++
configs/mt8365_evk_defconfig | 19 ++
6 files changed, 761 insertions(+)
create mode 100644 arch/arm/dts/mt6357.dtsi
create mode 100644 arch/arm/dts/mt8365-evk.dts
create mode 100644 board/mediatek/mt8365_evk/MAINTAINERS
create mode 100644 board/mediatek/mt8365_evk/Makefile
create mode 100644 board/mediatek/mt8365_evk/mt8365_evk.c
create mode 100644 configs/mt8365_evk_defconfig
diff --git a/arch/arm/dts/mt6357.dtsi b/arch/arm/dts/mt6357.dtsi
new file mode 100644
index 00..3330a03c2f
--- /dev/null
+++ b/arch/arm/dts/mt6357.dtsi
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Copyright (c) 2023 BayLibre Inc.
+ */
+
+#include
+
+&pwrap {
+ mt6357_pmic: pmic {
+ compatible = "mediatek,mt6357";
+
+ regulators {
+ mt6357_vproc_reg: buck-vproc {
+ regulator-name = "vproc";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+
+ mt6357_vcore_reg: buck-vcore {
+ regulator-name = "vcore";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+
+ mt6357_vmodem_reg: buck-vmodem {
+ regulator-name = "vmodem";
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <1193750>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ };
+
+ mt6357_vs1_reg: buck-vs1 {
+ regulator-name = "vs1";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <220>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+
+ mt6357_vpa_reg: buck-vpa {
+ regulator-name = "vpa";
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <365>;
+ regulator-ramp-delay = <5>;
+ regulator-enable-ramp-delay = <220>;
+ };
+
+ mt6357_vfe28_reg: ldo-vfe28 {
+ compatible = "regulator-fixed";
+ regulator-name = "vfe28";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-enable-ramp-delay = <264>;
+ };
+
+ mt6357_vxo22_reg: ldo-vxo22 {
+ regulator-name = "vxo22";
+ regulator-min-microvolt = <220>;
+ regulator-max-microvolt = <240>;
+ regulator-enable-ramp-delay = <110>;
+ };
+
+ mt6357_vrf18_reg: ldo-vrf18 {
+ compatible = "regulator-fixed";
+ regulator-name = "vrf18";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-enable-ramp-delay = <110>;
+ };
+
+ mt6357_vrf12_reg: ldo-vrf12 {
+ compatible = "regulator-fixed";
+ regulator-name = "vrf12";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ r
Re: [PATCH 01/18] bootm: netbds: Drop passing of arguments
On Mon, Dec 04, 2023 at 11:48:17AM +0100, Mark Kettenis wrote: > That said, I'm not sure to what extent the bootm command is used to > boot NetBSD these days. So this may not really matter. It is used on most 32bit ARM platforms. Martin
Re: [PATCH] common: usb-hub: Reset hub port before scanning
Hi Marek,
On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut wrote:
>
> On 12/3/23 22:42, Shantur Rathore wrote:
> > Hi Marek,
> >
> > On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut wrote:
> >>
> >> On 11/24/23 01:37, Shantur Rathore wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >> sorry for the late reply.
> >>
> >>> In my case RockPro64, the power to usb ports onboard is controlled by
> >>> a regulator.
> >>> This regulator is enabled as part of init as here
> >>> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177
> >>>
> >>> On init, the usb devices connected to the port are powered up, in my
> >>> case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
> >>> But the usb controller is only enabled at 'usb start' and by this time
> >>> the device is in some state that it doesn't get detected.
> >>>
> >>> One way to make sure the devices connected to the ports are in an
> >>> initialising state is by issuing a port reset before scanning the
> >>> port.
> >>
> >> Why not remove this regulator-always-on and let the PHY driver turn the
> >> VBUS ON only when it is needed ?
> >>
> >> Wouldn't that solve the problem too AND remove unnecessarily enabled
> >> regulator ?
> >>
> >> [...]
> >
> > Removing the regulator-always-on does make it work but there are few
> > issues
> >
> > 1. regulator is used to control power to multiple ports ( USB3.0 and
> > USB2.0 in RockPro64 ),
> > so this could lead to all ports turning off if a phy resets / turns off
> > power
>
> I vaguely recall seeing some refcounting patch for regulator subsystem,
> would that help ?
> >>>
> >>> I don't think this would be a problem for u-boot, but linux maybe.
> >>
> >> How so ?
> >
> > Actually, I am wrong. I wasn't sure if there is refcounting for the
> > regulator subsystem
> > in linux. just found it has so this is null and void.
> >
> >>
> > 2. Even with regulator-always-on and without this reset port patch,
> > linux was always
> > able to detect the drive on the port, so there is something missing in
> > u-boot.
> > 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
> > to reset the port before
> > scanning. The comment says
> >
> > /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
> > * Port warm reset is required to recover
> > */
> >
> > i.
> > https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
> > ii.
> > https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836
> >
> > I believe this isn't implemented in u-boot and hence explicit reset of
> > a port fixes the issue.
>
> I feel this is separate issue and what needs to be fixed first is the
> hard-wired VBus control.
> >>>
> >>> I beg to differ on this, couple of reasons for this
> >>>
> >>> 1. The same drive works fine without being reset on the USB2.0 ports -
> >>> this
> >>> confirms that the issue is related to USB3.0 only.
> >>
> >> This is a separate issue from the hard-wired VBus control. I agree the
> >> issue does exist, I would simply like to avoid conflating the hard-wired
> >> VBus control with device reset.
> >>
> >>> 2. Linux is able to detect the same drive on USB3.0 when u-boot fails -
> >>> this
> >>> confirms issue doesn't lie with regulator-always-on
> >>
> >> See above
> >>
> >>> 3. The links I pasted earlier mentions that in USB3.0 the ports need reset
> >>> and this is done before the port is scanned. Adding the similar reset in
> >>> u-boot
> >>> fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
> >>> this special USB3.0 case and maybe this is why I was finding a few posts
> >>> around the drive not being detected in the USB3.0 port in u-boot but
> >>> works in
> >>> a USB2.0 port.
> >>
> >> I am not disputing the need for USB 3.0 device reset, I believe there
> >> are two issues here -- one is the hard-wired VBus regulator -- the other
> >> is this USB 3.0 reset. They should both be fixed.
> >
> > Sure, agreed 100%.
> > Do we need to fix both at the same time?
> > Both patches seem to be independent.
>
> Separate patch for the regulator please .
Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
the typec phy
is configure with wrong regulator and if I do the patch as below
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -22,6 +22,23 @@
};
};
+&vcc5v0_host {
+ /delete-property/ regulator-always-on;
+};
+
+&vcc5v0_typec {
+ /delete-property/ regulator-always-on;
+};
+
+&vcc5v0_usb {
+ /delete-property/ regulator-always-on;
+ /delete-property/ regulator-boot-on;
+};
The typec port won't work until I correct the issue with
Re: [PATCH 00/21] Qualcomm generic board support
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > wrote: > > > > > I've been thinking about and hacking on this for the last week or so, > > > > > sorry for the delayed reply here. > > > > > > > > > > The value is in preventing any of the existing bindings from > > > > > regressing, > > > > > > That is actually best addressed in Linux by checking the DTS against > > > yaml DT bindings. We don't have that testing available in u-boot and > > > only depend on careful reviews. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory? Daniel.
Re: [PATCH] common: usb-hub: Reset hub port before scanning
On 12/4/23 11:59, Shantur Rathore wrote:
Hi Marek,
On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut wrote:
On 12/3/23 22:42, Shantur Rathore wrote:
Hi Marek,
On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut wrote:
On 11/24/23 01:37, Shantur Rathore wrote:
Hi Marek,
Hi,
sorry for the late reply.
In my case RockPro64, the power to usb ports onboard is controlled by
a regulator.
This regulator is enabled as part of init as here
https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177
On init, the usb devices connected to the port are powered up, in my
case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
But the usb controller is only enabled at 'usb start' and by this time
the device is in some state that it doesn't get detected.
One way to make sure the devices connected to the ports are in an
initialising state is by issuing a port reset before scanning the
port.
Why not remove this regulator-always-on and let the PHY driver turn the
VBUS ON only when it is needed ?
Wouldn't that solve the problem too AND remove unnecessarily enabled
regulator ?
[...]
Removing the regulator-always-on does make it work but there are few issues
1. regulator is used to control power to multiple ports ( USB3.0 and
USB2.0 in RockPro64 ),
so this could lead to all ports turning off if a phy resets / turns off power
I vaguely recall seeing some refcounting patch for regulator subsystem,
would that help ?
I don't think this would be a problem for u-boot, but linux maybe.
How so ?
Actually, I am wrong. I wasn't sure if there is refcounting for the
regulator subsystem
in linux. just found it has so this is null and void.
2. Even with regulator-always-on and without this reset port patch,
linux was always
able to detect the drive on the port, so there is something missing in u-boot.
3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
to reset the port before
scanning. The comment says
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
* Port warm reset is required to recover
*/
i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836
I believe this isn't implemented in u-boot and hence explicit reset of
a port fixes the issue.
I feel this is separate issue and what needs to be fixed first is the
hard-wired VBus control.
I beg to differ on this, couple of reasons for this
1. The same drive works fine without being reset on the USB2.0 ports - this
confirms that the issue is related to USB3.0 only.
This is a separate issue from the hard-wired VBus control. I agree the
issue does exist, I would simply like to avoid conflating the hard-wired
VBus control with device reset.
2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this
confirms issue doesn't lie with regulator-always-on
See above
3. The links I pasted earlier mentions that in USB3.0 the ports need reset
and this is done before the port is scanned. Adding the similar reset in u-boot
fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
this special USB3.0 case and maybe this is why I was finding a few posts
around the drive not being detected in the USB3.0 port in u-boot but works in
a USB2.0 port.
I am not disputing the need for USB 3.0 device reset, I believe there
are two issues here -- one is the hard-wired VBus regulator -- the other
is this USB 3.0 reset. They should both be fixed.
Sure, agreed 100%.
Do we need to fix both at the same time?
Both patches seem to be independent.
Separate patch for the regulator please .
Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
the typec phy
is configure with wrong regulator and if I do the patch as below
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -22,6 +22,23 @@
};
};
+&vcc5v0_host {
+ /delete-property/ regulator-always-on;
+};
+
+&vcc5v0_typec {
+ /delete-property/ regulator-always-on;
+};
+
+&vcc5v0_usb {
+ /delete-property/ regulator-always-on;
+ /delete-property/ regulator-boot-on;
+};
The typec port won't work until I correct the issue with
+&u2phy1_host {
+ phy-supply = <&vcc5v0_typec>;
+};
+
What would be acceptable here?
1. Leave regulator for typec as it was
2. disable regulator-always-on and fix phy here.
Is there going to be a matching Linux kernel patch with a Linux side fix ?
If so, include a link to that patch in lore.k.o in the commit message,
and either temporarily fix it up in u-boot.dtsi or backport that patch
to U-Boot DT, either works.
Re: [PATCH] arm: vexpress64: juno: Allow boot from VirtIO
On Thu, 23 Nov 2023 18:22:58 + robert.cather...@foss.arm.com wrote: Hi Robert, > From: Robert Catherall > > The AEM and Juno FVPs (Fixed Virtual Platforms) support a VirtIO I find it odd that the Juno FVP *adds* something on top of the Juno hardware devices, as this kind of defeats the purpose of having an as-close-as-possible software model, but well... Are there more differences than this one? > disc interface. Adding VIRTIO to the list of boot devices allows > these FastModel platforms to boot from 'disc' in the same way > the hardware counterpart can boot from SATA or USB. > > This is a NOP if CONFIG_CMD_VIRTIO is not enabled, so no impact > on Juno hardware (which is built with vexpress_aemv8a_juno_defconfig) So indeed I can confirm that with the vexpress_aemv8a_juno_defconfig there is no difference in the environment, so if that patch helps you: > Signed-off-by: Robert Catherall Reviewed-by: Andre Przywara Cheers, Andre > --- > include/configs/vexpress_aemv8.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/vexpress_aemv8.h > b/include/configs/vexpress_aemv8.h > index 24d8ca0866..8020689e39 100644 > --- a/include/configs/vexpress_aemv8.h > +++ b/include/configs/vexpress_aemv8.h > @@ -187,6 +187,7 @@ > func(USB, usb, 0) \ > func(SATA, sata, 0) \ > func(SATA, sata, 1) \ > + FUNC_VIRTIO(func) \ > func(PXE, pxe, na) \ > func(DHCP, dhcp, na)\ > func(AFS, afs, na)
Re: [PATCH 1/4] clk: starfive: jh7110: Add watchdog clocks
On Mon, Nov 06, 2023 at 08:13:15AM +0900, Chanho Park wrote: > Add JH7110_SYSCLK_WDT_APB and JH7110_SYSCLK_WDT_CORE clocks for JH7110 > watchdog device. > > Signed-off-by: Chanho Park > --- > drivers/clk/starfive/clk-jh7110.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Leo Yu-Chi Liang
[PATCH 0/3] binman: Add support for TI_DM entry
This series adds support for the TI_DM entry and moves all K3 platforms to using the same. With this feature introduced, if TI_DM argument is provided binman picks the pathname it provides; else, it defaults to picking up the ti-dm.bin file. This makes it flexible for users to build tispl.bin with custom DM binaries. Boot logs: https://gist.github.com/nehamalcom/37ce8a32e37ddf3e1afcc4c8bd941159 Neha Malcom Francis (3): binman: etype: dm: Add entry type for TI DM arm: dts: k3-*-binman: Move to using ti-dm entry type doc: board: ti: k3: Mention TI_DM argument Makefile | 1 + arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++-- .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++-- arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++-- arch/arm/dts/k3-j7200-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721e-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++-- doc/board/ti/k3.rst | 7 ++ tools/binman/entries.rst | 14 tools/binman/etype/ti_dm.py | 22 +++ tools/binman/ftest.py | 7 ++ tools/binman/test/225_ti_dm.dts | 13 +++ 12 files changed, 76 insertions(+), 12 deletions(-) create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/test/225_ti_dm.dts -- 2.34.1
[PATCH 1/3] binman: etype: dm: Add entry type for TI DM
K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.
The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin
Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.
Signed-off-by: Neha Malcom Francis
---
Makefile| 1 +
tools/binman/entries.rst| 14 ++
tools/binman/etype/ti_dm.py | 22 ++
tools/binman/ftest.py | 7 +++
tools/binman/test/225_ti_dm.dts | 13 +
5 files changed, 57 insertions(+)
create mode 100644 tools/binman/etype/ti_dm.py
create mode 100644 tools/binman/test/225_ti_dm.dts
diff --git a/Makefile b/Makefile
index 1b347f4dfd..7b599ca130 100644
--- a/Makefile
+++ b/Makefile
@@ -1349,6 +1349,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+ -a ti-dm-path=${TI_DM} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 61de7f1f4a..254afe7607 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1906,6 +1906,20 @@ the included board config binaries. Example::
+.. _etype_ti_dm:
+
+Entry: ti-dm: TI Device Manager (DM) blob
+-
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+
+
+
.. _etype_ti_secure:
Entry: ti-secure: Entry containing a TI x509 certificate binary
diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
new file mode 100644
index 00..0faa0bf0ca
--- /dev/null
+++ b/tools/binman/etype/ti_dm.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis
+#
+# Entry-type module for TI Device Manager (DM)
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_ti_dm(Entry_blob_named_by_arg):
+"""TI Device Manager (DM) blob
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically
ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-dm')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5ace2a825d..a273120d9f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -88,6 +88,7 @@ FSP_S_DATA= b'fsp_s'
FSP_T_DATA= b'fsp_t'
ATF_BL31_DATA = b'bl31'
TEE_OS_DATA = b'this is some tee OS data'
+TI_DM_DATA= b'tidmtidm'
ATF_BL2U_DATA = b'bl2u'
OPENSBI_DATA = b'opensbi'
SCP_DATA = b'scp'
@@ -221,6 +222,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
+TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -5455,6 +5457,11 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('222_tee_os.dts')
self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
+def testPackTiDm(self):
+"""Test that an image with a TI DM binary can be created"""
+data = self._DoReadFile('225_ti_dm.dts')
+self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
+
def testFitFdtOper(self):
"""Check handling of a specified FIT operation"""
entry_args = {
diff --git a/tools/binman/test/225_ti_dm.dts b/tools/binman/test/225_ti_dm.dts
new file mode 100644
index 00..3ab754131e
--- /dev/null
+++ b/tools/
[PATCH 2/3] arm: dts: k3-*-binman: Move to using ti-dm entry type
Move the DM entry in tispl.bin FIT image from default fetching an
external blob entry to fetching using ti-dm entry type. This way, the
DM entry will be populated by the TI_DM pathname if provided. Else it
will resort to the ti-dm.bin file.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++--
arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-j7200-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721e-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index b7b5368886..5b058bd03a 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -161,7 +161,7 @@
content = <&dm>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -248,7 +248,7 @@
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index ed2c4482ef..78c371529a 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -227,7 +227,7 @@
content = <&dm>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -310,7 +310,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index c5e027d44d..ec3bf7ce91 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -164,7 +164,7 @@
content = <&dm>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -250,7 +250,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index 10c9d6cba7..38cccabaa7 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -200,7 +200,7 @@
content = <&dm>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -285,7 +285,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 5ddb474e3a..dbc385a852 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
[PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument
Mention TI_DM argument can be used to fetch a custom DM binary in the A72 build instructions for K3 devices. Signed-off-by: Neha Malcom Francis --- doc/board/ti/k3.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a127215ce5..15916b088f 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -320,6 +320,13 @@ use the `lite` option. make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \ BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \ TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin + +.. note:: + It is also possible to pick up a custom DM binary by adding TI_DM argument + pointing to the file. If not provided, it defaults to picking up the DM + binary from ti-linux-firmware. This is only applicable to devices that + utilize split firmware. + .. k3_rst_include_end_build_steps_uboot At this point you should have every binary needed initialize both the -- 2.34.1
Re: [PATCH 2/4] watchdog: Add StarFive Watchdog driver
On Mon, Nov 06, 2023 at 08:13:16AM +0900, Chanho Park wrote: > Add to support StarFive watchdog driver. The driver is imported from > linux kernel's drivers/watchdog/starfive-wdt.c without jh7100 support > because there is no support of jh7100 SoC in u-boot yet. > Howver, this patch has been kept the variant coding style because JH7100 > can be added later and have a consistency with the linux driver. > > Signed-off-by: Chanho Park > --- > drivers/watchdog/Kconfig| 7 + > drivers/watchdog/Makefile | 1 + > drivers/watchdog/starfive_wdt.c | 329 > 3 files changed, 337 insertions(+) > create mode 100644 drivers/watchdog/starfive_wdt.c Reviewed-by: Leo Yu-Chi Liang
Re: [u-boot-gitdm PATCH 2/2] Add some more employers
Hi Simon, On 12/3/23 05:46, Simon Glass wrote: This looks at the top unknowns: git log --pretty=%ae v2023.01.. |sed 's/.*@//' |sort |uniq -c | sort -nr | (while read count email; do if ! grep -q $email u-boot-config/domain-map; then echo "$count $email"; fi; done ) It reduces the (Unknown) count from a third to a fifth. Signed-off-by: Simon Glass --- u-boot-config/domain-map | 38 ++ 1 file changed, 38 insertions(+) diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map index 63cb60f..27f1a7e 100644 --- a/u-boot-config/domain-map +++ b/u-boot-config/domain-map @@ -18,6 +18,7 @@ amd.com AMD anagramm.de Anagramm GmbH analog.comAnalog Devices android.com Google LLC +andestech.com Andes Technology arastra.com Arastra Inc areca.com.tw Areca argos-messtechnik.de Argos Meßtechnik GmbH @@ -44,6 +45,7 @@ bluewatersys.com Bluewater Systems boeing.comBoeing bootlin.com Bootlin boundarydevices.com Boundary Devices +bp.renesas.com Renesas Electronics Corporation broadcom.com Broadcom brontes3d.com Brontes Technologies bt.comBT Group @@ -51,6 +53,7 @@ bull.net Bull SAS bus-elektronik.de BuS Elektronik calxeda.com Calxeda cam.ac.uk University of Cambridge +canonical.com Canonical Ltd. ccur.com Concurrent Computer Corporation cdi.czCDI.CZ celestrius.comCelestrius @@ -58,6 +61,7 @@ celunite.com Azingo centtech.com Centaur Technology cesa.opbu.xerox.com Xerox chelsio.com Chelsio +chromium.org Google LLC cideas.comCustom IDEAS cisco.com Cisco citi.umich.eduUniv. of Michigan CITI @@ -78,6 +82,7 @@ cosmosbay.com Cosmosbay Vectis cozybit.com cozybit cray.com Cray cse-semaphore.com CSE Semaphore, Inc. +csgroup.eu CS Group csr.com CSR cyberguard.comSecure Computing cybernetics.com Cybernetics @@ -89,11 +94,13 @@ dell.comDell denx.de DENX Software Engineering devicescape.com Devicescape digi.com Digi International +dimonoff.com Dimonoff inc. doredevelopment.dkDore Development dti2.net DTI2 - Desarrollo de la tecnologia de las comunicaciones e-coninfotech.com e-con Infotech ecitele.com ECI Telecom edesix.comEdesix Ltd +edgeble.ai Edgeble AI einstruction.com eInstruction eke.fiEKE-Electronics elandigitalsystems.comElan Digital Systems @@ -119,10 +126,13 @@ feig.de Feig Electronic fixstars.com Fixstars Technologies free-electrons.comBootlin freescale.com NXP +foss.st.comST Microelectronics +foundries.io Foundries.io fujitsu.com Fujitsu gaisler.com Gaisler Research ganssloser.comIngenieurbuero Ganssloser garzik.orgRed Hat +gateworks.com Gateworks Corporation gdsys.cc Guntermann & Drunck gdsys.de Guntermann & Drunck ge.comGeneral Electric @@ -140,6 +150,7 @@ hevs.ch HES-SO Valais Wallis highpoint-tech.comHighPoint Technologies hitachi.co.jp Hitachi hitachi.com Hitachi +hitachienergy.com Hitachi hitachisoft.jpHitachi hp.comHP huawei.comHuawei Technologies @@ -164,10 +175,13 @@ jmicron.com jmicron.com jp.fujitsu.comFujitsu juniper.net Juniper Networks katalix.com Katalix Systems +kernel-space.org kernelspace keymile.com Keymile keyspan.com InnoSys +kwiboo.se Kwiboo kiethp.comIntel konsulko.com Konsulko Group +kontron.de Kontron labxtechnologies.com Lab X Technologies laptop.orgOLPC laurelnetworks.comECI Telecom @@ -176,9 +190,11 @@ linaro.org Linaro linutronix.de linutronix linux-foundation.org Linux Foundation linuxant.com Linuxant +linux.microsoft.comMicrosoft Corporation linx.net London Internet Exchange lippert-at.de LiPPERT Embedded Computers GmbH lippertembedded.deLiPPERT Embedded Computers GmbH +lionizers.com Lionizers llnl.gov Lawrence Livermore National Laboratory lnxi.com Linux Networx logitech.com Logitech @@ -194,10 +210,14 @@ mandriva.com.br Mandriva marvell.com Marvel
Re: [PATCH 3/4] riscv: dts: jh7110: Add watchdog device tree node
On Mon, Nov 06, 2023 at 08:13:17AM +0900, Chanho Park wrote: > Adds jh7110 watchdog device tree node. > > Signed-off-by: Chanho Park > --- > arch/riscv/dts/jh7110.dtsi | 10 ++ > 1 file changed, 10 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 4/4] configs: visionfive2: Enable watchdog driver
On Mon, Nov 06, 2023 at 08:13:18AM +0900, Chanho Park wrote: > Enables StarFive Watchdog driver and WDT command. > > Signed-off-by: Chanho Park > --- > configs/starfive_visionfive2_defconfig | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v2] riscv: Add support for AMD/Xilinx MicroBlaze V
On Mon, Nov 06, 2023 at 12:56:47PM +0100, Michal Simek wrote: > MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP. > It is hardware compatible with classic MicroBlaze processor. > > The patch contains initial wiring and configuration for initial HW design > with memory, cpu, interrupt controller, timers and uartlite console > (interrupt controller is listed but U-Boot is not using it). > > Provided DT is just describing one configuration and should be taken only > as example. > > Signed-off-by: Michal Simek > --- > > Changes in v2: > - Extend commit message > - DT changes, add interrupt controller, check agains dt schema > - The patch for amd,mbv32 compatible string is here > https://lore.kernel.org/r/d442d916204d26f82c1c3a924a4cdfb117960e1b.1699270661.git.michal.si...@amd.com > - The patch for board compatibility is here > https://lore.kernel.org/r/50c277c92c41a582ef171fb75efc6a6a4f860be2.1699271616.git.michal.si...@amd.com > > xlnx,xps-intc-1.00.a driver exists in the Linux kernel but DT binding is > missing. That's something what we need to work on. > arch/arm64/boot/dts/xilinx/xilinx-mbv32.dtb: > /axi/interrupt-controller@4120: failed to match any schema with > compatible: ['xlnx,xps-intc-1.00.a'] > > Public annoucement is available here if someone is interested. > https://www.xilinx.com/products/design-tools/microblaze-v.html?utm_source=marketo&utm_medium=email&utm_campaign=EN-EM-2023-11-02-New-MicroBlaze-V-Processor&utm_term=btn&mkt_tok=NDA5LVdZWC03MjQAAAGPMMJYuPPscCags7WdvOeUSWy-_mC9aOwrobFaZRf5ok_eHoQUvTLBzJdHrkcBId9tQ4a-odfnU91WjUkIxx-iSG4OKGofjK5iZcAiK_VN8_xK > > --- > arch/riscv/Kconfig | 4 + > arch/riscv/dts/Makefile | 2 + > arch/riscv/dts/xilinx-mbv32.dts | 106 +++ > board/xilinx/Kconfig | 3 +- > board/xilinx/common/board.c | 5 ++ > board/xilinx/mbv/Kconfig | 28 +++ > board/xilinx/mbv/MAINTAINERS | 7 ++ > board/xilinx/mbv/Makefile| 5 ++ > board/xilinx/mbv/board.c | 11 +++ > configs/xilinx_mbv32_defconfig | 30 > configs/xilinx_mbv32_smode_defconfig | 32 > include/configs/xilinx_mbv.h | 6 ++ > 12 files changed, 238 insertions(+), 1 deletion(-) > create mode 100644 arch/riscv/dts/xilinx-mbv32.dts > create mode 100644 board/xilinx/mbv/Kconfig > create mode 100644 board/xilinx/mbv/MAINTAINERS > create mode 100644 board/xilinx/mbv/Makefile > create mode 100644 board/xilinx/mbv/board.c > create mode 100644 configs/xilinx_mbv32_defconfig > create mode 100644 configs/xilinx_mbv32_smode_defconfig > create mode 100644 include/configs/xilinx_mbv.h Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH] efi_loader: use event callback for initrd deregistration
Thanks for cleaning this up!
On Mon, 4 Dec 2023 at 06:31, Masahisa Kojima wrote:
>
> Currently efi_initrd_deregister() is called in bootefi.c
> when the image started from bootefi command returns.
> Since efi_guid_event_group_return_to_efibootmgr event is
> implemented, so let's use this event for invoking
> initrd deregistration.
>
> Signed-off-by: Masahisa Kojima
> ---
> Note that this patch can be applied to u-boot/next.
> This patch requires the patch e0d1a1ea68("efi_loader: add return to
> efibootmgr event group")
>
> cmd/bootefi.c| 5 --
> lib/efi_loader/efi_load_initrd.c | 82 +---
> 2 files changed, 55 insertions(+), 32 deletions(-)
Reviewed-by: Ilias Apalodimas
Tested-by: Ilias Apalodimas
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 4d74969ad6..e52bd3f743 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -390,11 +390,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle,
> void *load_options)
> out:
> free(load_options);
>
> - if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD)) {
> - if (efi_initrd_deregister() != EFI_SUCCESS)
> - log_err("Failed to remove loadfile2 for initrd\n");
> - }
> -
> /* Notify EFI_EVENT_GROUP_RETURN_TO_EFIBOOTMGR event group. */
> list_for_each_entry(evt, &efi_events, link) {
> if (evt->group &&
> diff --git a/lib/efi_loader/efi_load_initrd.c
> b/lib/efi_loader/efi_load_initrd.c
> index 193433782c..7ca7785c04 100644
> --- a/lib/efi_loader/efi_load_initrd.c
> +++ b/lib/efi_loader/efi_load_initrd.c
> @@ -184,6 +184,50 @@ out:
> return ret;
> }
>
> +/**
> + * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> + *
> + * This will delete the handle containing the Linux specific vendor device
> + * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> + *
> + * Return: status code
> + */
> +efi_status_t efi_initrd_deregister(void)
> +{
> + efi_status_t ret;
> +
> + if (!efi_initrd_handle)
> + return EFI_SUCCESS;
> +
> + ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
> +/* initramfs */
> +
> &efi_guid_device_path,
> +&dp_lf2_handle,
> +/* LOAD_FILE2 */
> +
> &efi_guid_load_file2_protocol,
> +&efi_lf2_protocol,
> +NULL);
> + efi_initrd_handle = NULL;
> +
> + return ret;
> +}
> +
> +/**
> + * efi_initrd_return_notify() - return to efibootmgr callback
> + *
> + * @event: the event for which this notification function is registered
> + * @context: event context
> + */
> +static void EFIAPI efi_initrd_return_notify(struct efi_event *event,
> + void *context)
> +{
> + efi_status_t ret;
> +
> + EFI_ENTRY("%p, %p", event, context);
> + ret = efi_initrd_deregister();
> + EFI_EXIT(ret);
> +}
> +
> /**
> * efi_initrd_register() - create handle for loading initial RAM disk
> *
> @@ -197,6 +241,7 @@ out:
> efi_status_t efi_initrd_register(void)
> {
> efi_status_t ret;
> + struct efi_event *event;
>
> /*
> * Allow the user to continue if Boot file path is not set for
> @@ -215,34 +260,17 @@ efi_status_t efi_initrd_register(void)
>
> &efi_guid_load_file2_protocol,
>&efi_lf2_protocol,
>NULL);
> + if (ret != EFI_SUCCESS) {
> + log_err("installing EFI_LOAD_FILE2_PROTOCOL failed\n");
> + return ret;
> + }
>
> - return ret;
> -}
> -
> -/**
> - * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> - *
> - * This will delete the handle containing the Linux specific vendor device
> - * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> - *
> - * Return: status code
> - */
> -efi_status_t efi_initrd_deregister(void)
> -{
> - efi_status_t ret;
> -
> - if (!efi_initrd_handle)
> - return EFI_SUCCESS;
> -
> - ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
> -/* initramfs */
> -
> &efi_guid_device_path,
> -&dp_lf2_handle,
> -/* LOAD_FILE2 */
> -
> &efi_guid_load_file2_p
Re: EFI memory allocation
Hi Simon On Sun, 3 Dec 2023 at 19:44, Simon Glass wrote: > > Hi Heinrich, Ilias, > > I had a bit of a look at how memory is allocated in EFI. > > I see that efi_memory_init() is called quite early in U-Boot. It > sometimes allocates memory for a bounce buffer, placing it somewhere > in memory. How do we know that that memory is free and not being used > by U-Boot? > > To answer my own question, it excludes U-Boot's malloc() region from > the map, so that it cannot overwrite that. > > But then, what if we use lmb and start loading images into memory. > Won't that conflict with EFI? Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and we have a 'todo' in the efi subsystem for a few years now [0] Michal (+cc'ed) has also pinged me for similar issues in the past. > > I also see that efi_allocate_pages() is called to allocate memory in > the EFI code. But this just grabs memory from 'anywhere'...it doesn't > respect the U-Boot malloc region. > > It seems to me that most of the memory allocation in EFI should be > done using malloc(). Of course the boot services need to > efi_allocate_pages(), etc., but I am not sure that the internal tables > should be skipping malloc()? > > What do you think? I think that LMB, EFI and the whole memory reservations is a bit of a mess. Tom and I discussed this a bit in the past but I'll start working on it. It needs fixing, but without looking at the code first, I can't provide any useful feedback [0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2 Thanks /Ilias > > Regards, > Simon
[PATHv1 0/9] net fixes prior lwip
Add small net fixes prior lwip patch. CI for this patch set: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7460&view=results Maxim Uvarov (9): test_net: print out net list net: sandbox: fix NULL pointer derefences net/smc911x: fix return from smc911x_send sandbox: eth-raw-os: successful return code is 0 driver/net/rtl8139: remove debug print mach-socfpga: do not overlap defines with lwip bcm_ns3: fix overlap define with lwip omap3: rename mem_init Makefile: add dtbs to clean Makefile | 3 ++- arch/arm/include/asm/arch-omap3/mem.h | 2 +- arch/arm/mach-omap2/omap3/board.c | 2 +- arch/arm/mach-omap2/omap3/emif4.c | 4 ++-- arch/arm/mach-omap2/omap3/sdrc.c | 6 +++--- arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 6 -- arch/arm/mach-socfpga/wrap_handoff_soc64.c | 9 + arch/sandbox/cpu/eth-raw-os.c | 2 +- drivers/net/rtl8139.c | 2 +- drivers/net/sandbox.c | 3 +++ drivers/net/smc911x.c | 2 +- include/configs/bcm_ns3.h | 6 +++--- test/py/tests/test_net.py | 2 ++ 13 files changed, 29 insertions(+), 20 deletions(-) -- 2.30.2
[PATHv1 1/9] test_net: print out net list
Printing net list is useful in CI log files.
Signed-off-by: Maxim Uvarov
---
test/py/tests/test_net.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index b2241ae6a4..cd5b791a6a 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -96,6 +96,8 @@ def test_net_pre_commands(u_boot_console):
if init_pci:
u_boot_console.run_command('pci enum')
+u_boot_console.run_command('net list')
+
@pytest.mark.buildconfigspec('cmd_dhcp')
def test_net_dhcp(u_boot_console):
"""Test the dhcp command.
--
2.30.2
[PATHv1 2/9] net: sandbox: fix NULL pointer derefences
Add additional checks for NULL pointers. Signed-off-by: Maxim Uvarov --- drivers/net/sandbox.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c index 13022addb6..d91935e032 100644 --- a/drivers/net/sandbox.c +++ b/drivers/net/sandbox.c @@ -65,6 +65,9 @@ int sandbox_eth_arp_req_to_reply(struct udevice *dev, void *packet, struct ethernet_hdr *eth_recv; struct arp_hdr *arp_recv; + if (!priv) + return -EAGAIN; + if (ntohs(eth->et_protlen) != PROT_ARP) return -EAGAIN; -- 2.30.2
[PATHv1 3/9] net/smc911x: fix return from smc911x_send
return value of smc911x_send is ignored, but on sucesseful send we need return 0 and or error -ETIMEOUT, not opposite. Signed-off-by: Maxim Uvarov Reviewed-by: Tom Rini --- drivers/net/smc911x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c index 5c5ad8b84a..616b7ce174 100644 --- a/drivers/net/smc911x.c +++ b/drivers/net/smc911x.c @@ -403,7 +403,7 @@ static int smc911x_send(struct udevice *dev, void *packet, int length) ret = smc911x_send_common(priv, packet, length); - return ret ? 0 : -ETIMEDOUT; + return ret ? -ETIMEDOUT : 0; } static int smc911x_recv(struct udevice *dev, int flags, uchar **packetp) -- 2.30.2
[PATHv1 4/9] sandbox: eth-raw-os: successful return code is 0
all network drivers return 0 on the successful transmission. Signed-off-by: Maxim Uvarov Reviewed-by: Simon Glass --- arch/sandbox/cpu/eth-raw-os.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sandbox/cpu/eth-raw-os.c b/arch/sandbox/cpu/eth-raw-os.c index e59b96be5f..92c35aed95 100644 --- a/arch/sandbox/cpu/eth-raw-os.c +++ b/arch/sandbox/cpu/eth-raw-os.c @@ -256,7 +256,7 @@ int sandbox_eth_raw_os_send(void *packet, int length, strerror(errno)); return -errno; } - return retval; + return 0; } int sandbox_eth_raw_os_recv(void *packet, int *length, -- 2.30.2
[PATHv1 5/9] driver/net/rtl8139: remove debug print
debug print delays reset of the driver. Finally I see
bunch of "rx error " errors in the screen. CI can
not handle many prints. While network works fine there
Reproduced with:
make CROSS_COMPILE=sh2-linux- r2dplus_defconfig all
qemu-system-sh4 -M r2d -nographic -serial null \
-serial mon:stdio -net user,tftp=`pwd` \
-net nic,model=rtl8139 -kernel ./u-boot.bin
Signed-off-by: Maxim Uvarov
---
drivers/net/rtl8139.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/rtl8139.c b/drivers/net/rtl8139.c
index 106bc1c7ae..d8f24ec81a 100644
--- a/drivers/net/rtl8139.c
+++ b/drivers/net/rtl8139.c
@@ -453,7 +453,7 @@ static int rtl8139_recv_common(struct rtl8139_priv *priv,
unsigned char *rxdata,
RTL_STS_RXBADALIGN)) ||
(rx_size < ETH_ZLEN) ||
(rx_size > ETH_FRAME_LEN + 4)) {
- printf("rx error %hX\n", rx_status);
+ debug("rx error %hX\n", rx_status);
/* this clears all interrupts still pending */
rtl8139_reset(priv);
return 0;
--
2.30.2
[PATHv1 6/9] mach-socfpga: do not overlap defines with lwip
Fix compilation issue with overlapping lwip and march defines.
Signed-off-by: Maxim Uvarov
---
arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 6 --
arch/arm/mach-socfpga/wrap_handoff_soc64.c | 9 +
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
index 902fc6bfb5..9b85e5865b 100644
--- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
@@ -78,12 +78,6 @@
#ifndef __ASSEMBLY__
#include
-enum endianness {
- LITTLE_ENDIAN = 0,
- BIG_ENDIAN,
- UNKNOWN_ENDIANNESS
-};
-
int socfpga_get_handoff_size(void *handoff_address);
int socfpga_handoff_read(void *handoff_address, void *table, u32 table_len);
#endif
diff --git a/arch/arm/mach-socfpga/wrap_handoff_soc64.c
b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
index e7cb5ea89c..df0701ec85 100644
--- a/arch/arm/mach-socfpga/wrap_handoff_soc64.c
+++ b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
@@ -10,6 +10,15 @@
#include
#include "log.h"
+#ifndef __ASSEMBLY__
+#include
+enum endianness {
+ LITTLE_ENDIAN = 0,
+ BIG_ENDIAN,
+ UNKNOWN_ENDIANNESS
+};
+#endif
+
static enum endianness check_endianness(u32 handoff)
{
switch (handoff) {
--
2.30.2
[PATHv1 7/9] bcm_ns3: fix overlap define with lwip
Rename declaration to not overlap with lwip.
aarch64: + bcm_ns3
+In file included from net/lwip/lwip-external/src/include/lwip/etharp.h:53,
+ from net/lwip/lwip-external/src/core/init.c:55:
+net/lwip/lwip-external/src/include/lwip/prot/ethernet.h:69:
error: "ETH_ADDR" redefined [-Werror]
+ 69 | #define ETH_ADDR(b0, b1, b2, b3, b4, b5) {{b0, b1, b2, b3, b4, b5}}
+ |
+In file included from include/config.h:3,
+ from arch/arm/include/asm/string.h:4,
+ from include/linux/string.h:21,
+ from include/malloc.h:369,
+ from include/stdlib.h:9,
+ from net/lwip/lwip-external/src/include/lwip/arch.h:83,
+ from net/lwip/lwip-external/src/include/lwip/debug.h:40,
+ from net/lwip/lwipopts.h:93,
+ from net/lwip/lwip-external/src/include/lwip/opt.h:51,
+ from net/lwip/lwip-external/src/core/init.c:38:
+include/configs/bcm_ns3.h:52: note: this is the location of the previous
definition
+ 52 | #define ETH_ADDR
Signed-off-by: Maxim Uvarov
Reviewed-by: Tom Rini
---
include/configs/bcm_ns3.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/bcm_ns3.h b/include/configs/bcm_ns3.h
index 47de4bc201..7c6e0725a6 100644
--- a/include/configs/bcm_ns3.h
+++ b/include/configs/bcm_ns3.h
@@ -45,11 +45,11 @@
#define PCIE_ARGS "pcie_args=pci=pcie_bus_safe pcie_ports=native
vfio_pci.disable_idle_d3=1\0"
#ifdef CONFIG_BCM_SF2_ETH
-#define ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
+#define BCM_ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
#define NET_ARGS "bgmac_platform.ethaddr=${ethaddr} " \
"ip=${ipaddr}::${gatewayip}:${netmask}::${ethif}:off"
#else
-#define ETH_ADDR
+#define BMC_ETH_ADDR
#define NET_ARGS
#endif
@@ -749,7 +749,7 @@
OS_LOG_LEVEL \
EXTRA_ARGS \
PCIE_ARGS \
- ETH_ADDR \
+ BMC_ETH_ADDR \
RESERVED_MEM \
SETBOOTARGS \
UPDATEME_FLASH_PARAMS \
--
2.30.2
[PATHv1 8/9] omap3: rename mem_init
Rename mem_init to solve following compilation error with lwip
integrated code:
+arm-linux-gnueabi-ld.bfd: net/lwip/lwip-external/src/core/mem.o: in
function `mem_init':
+net/lwip/lwip-external/src/core/mem.c:162: multiple definition
of `mem_init';
arch/arm/mach-omap2/omap3/sdrc.o:arch/arm/mach-omap2/omap3/
sdrc.c:240: first defined here
+make[1]: *** [Makefile:1764: u-boot] Error 1
+/opt/gcc-13.1.0-nolibc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-
gnueabi/13.1.0/../../
../../arm-linux-gnueabi/bin/ld: net/lwip/lwip-external/src/core/
mem.o (symbol from
plugin): in function `mem_init':
+(.text+0x0): multiple definition of `mem_init'; arch/arm/mach-omap2/
omap3/emif4.o
(symbol from plugin):(.text+0x0): first defined here
+collect2: error: ld returned 1 exit status
+(.text+0x0): multiple definition of `mem_init'; arch/arm/mach-omap2/
omap3/sdrc.o
(symbol from plugin):(.text+0x0): first defined here
+Image 'simple-bin' is missing external blobs and is non-functional:
tee-os
+/binman/simple-bin/fit/images/op-tee/tee-os (tee-os):
Signed-off-by: Maxim Uvarov
Reviewed-by: Tom Rini
---
arch/arm/include/asm/arch-omap3/mem.h | 2 +-
arch/arm/mach-omap2/omap3/board.c | 2 +-
arch/arm/mach-omap2/omap3/emif4.c | 4 ++--
arch/arm/mach-omap2/omap3/sdrc.c | 6 +++---
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index 569779c55e..fce3568eca 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -475,7 +475,7 @@ enum {
#ifndef __ASSEMBLY__
/* Function prototypes */
-void mem_init(void);
+void omap3_mem_init(void);
u32 is_mem_sdr(void);
u32 mem_ok(u32 cs);
diff --git a/arch/arm/mach-omap2/omap3/board.c
b/arch/arm/mach-omap2/omap3/board.c
index 8b70251457..c76a95dd5d 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -216,7 +216,7 @@ void s_init(void)
void board_init_f(ulong dummy)
{
early_system_init();
- mem_init();
+ omap3_mem_init();
/*
* Save the boot parameters passed from romcode.
* We cannot delay the saving further than this,
diff --git a/arch/arm/mach-omap2/omap3/emif4.c
b/arch/arm/mach-omap2/omap3/emif4.c
index 7e5a281922..4fbfb387ab 100644
--- a/arch/arm/mach-omap2/omap3/emif4.c
+++ b/arch/arm/mach-omap2/omap3/emif4.c
@@ -159,10 +159,10 @@ int dram_init_banksize(void)
}
/*
- * mem_init() -
+ * omap3_mem_init() -
* - Initialize memory subsystem
*/
-void mem_init(void)
+void omap3_mem_init(void)
{
do_emif4_init();
}
diff --git a/arch/arm/mach-omap2/omap3/sdrc.c b/arch/arm/mach-omap2/omap3/sdrc.c
index 5d43e7c9cf..f2a0769b9d 100644
--- a/arch/arm/mach-omap2/omap3/sdrc.c
+++ b/arch/arm/mach-omap2/omap3/sdrc.c
@@ -4,7 +4,7 @@
*
* This file has been created after exctracting and consolidating
* the SDRC related content from mem.c and board.c, also created
- * generic init function (mem_init).
+ * generic init function (omap3_mem_init).
*
* Copyright (C) 2004-2010
* Texas Instruments Incorporated - https://www.ti.com/
@@ -232,11 +232,11 @@ int dram_init_banksize(void)
}
/*
- * mem_init -
+ * map3_mem_init -
* - Init the sdrc chip,
* - Selects CS0 and CS1,
*/
-void mem_init(void)
+void omap3_mem_init(void)
{
/* only init up first bank here */
do_sdrc_init(CS0, EARLY_INIT);
--
2.30.2
[PATHv1 9/9] Makefile: add dtbs to clean
CI test checks that generated dtb has to be cleaned up. Signed-off-by: Maxim Uvarov --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 08604ed3c7..8dd6990584 100644 --- a/Makefile +++ b/Makefile @@ -2165,7 +2165,8 @@ CLEAN_FILES += include/autoconf.mk* include/bmp_logo.h include/bmp_logo_data.h \ mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \ itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \ mkimage.rom.mkimage mkimage-in-simple-bin* rom.map simple-bin* \ - idbloader-spi.img lib/efi_loader/helloworld_efi.S *.itb + idbloader-spi.img lib/efi_loader/helloworld_efi.S *.itb \ + ./*/*.dtb *.dtb # Directories & files removed with 'make mrproper' MRPROPER_DIRS += include/config include/generated spl tpl vpl \ -- 2.30.2
Re: [PATCH] common: usb-hub: Reset hub port before scanning
On Mon, Dec 4, 2023 at 11:05 AM Marek Vasut wrote: > > On 12/4/23 11:59, Shantur Rathore wrote: > > Hi Marek, > > > > On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut wrote: > >> > >> On 12/3/23 22:42, Shantur Rathore wrote: > >>> Hi Marek, > >>> > >>> On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut wrote: > > On 11/24/23 01:37, Shantur Rathore wrote: > > Hi Marek, > > Hi, > > sorry for the late reply. > > > In my case RockPro64, the power to usb ports onboard is controlled > > by > > a regulator. > > This regulator is enabled as part of init as here > > https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177 > > > > On init, the usb devices connected to the port are powered up, in my > > case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS. > > But the usb controller is only enabled at 'usb start' and by this > > time > > the device is in some state that it doesn't get detected. > > > > One way to make sure the devices connected to the ports are in an > > initialising state is by issuing a port reset before scanning the > > port. > > Why not remove this regulator-always-on and let the PHY driver turn > the > VBUS ON only when it is needed ? > > Wouldn't that solve the problem too AND remove unnecessarily enabled > regulator ? > > [...] > >>> > >>> Removing the regulator-always-on does make it work but there are few > >>> issues > >>> > >>> 1. regulator is used to control power to multiple ports ( USB3.0 and > >>> USB2.0 in RockPro64 ), > >>> so this could lead to all ports turning off if a phy resets / turns > >>> off power > >> > >> I vaguely recall seeing some refcounting patch for regulator subsystem, > >> would that help ? > > > > I don't think this would be a problem for u-boot, but linux maybe. > > How so ? > >>> > >>> Actually, I am wrong. I wasn't sure if there is refcounting for the > >>> regulator subsystem > >>> in linux. just found it has so this is null and void. > >>> > > >>> 2. Even with regulator-always-on and without this reset port patch, > >>> linux was always > >>> able to detect the drive on the port, so there is something missing > >>> in u-boot. > >>> 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries > >>> to reset the port before > >>> scanning. The comment says > >>> > >>> /* Is a USB 3.0 port in the Inactive or Compliance Mode state? > >>> * Port warm reset is required to recover > >>> */ > >>> > >>> i. > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736 > >>> ii. > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836 > >>> > >>> I believe this isn't implemented in u-boot and hence explicit reset of > >>> a port fixes the issue. > >> > >> I feel this is separate issue and what needs to be fixed first is the > >> hard-wired VBus control. > > > > I beg to differ on this, couple of reasons for this > > > > 1. The same drive works fine without being reset on the USB2.0 ports - > > this > > confirms that the issue is related to USB3.0 only. > > This is a separate issue from the hard-wired VBus control. I agree the > issue does exist, I would simply like to avoid conflating the hard-wired > VBus control with device reset. > > > 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - > > this > > confirms issue doesn't lie with regulator-always-on > > See above > > > 3. The links I pasted earlier mentions that in USB3.0 the ports need > > reset > > and this is done before the port is scanned. Adding the similar reset > > in u-boot > > fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle > > this special USB3.0 case and maybe this is why I was finding a few posts > > around the drive not being detected in the USB3.0 port in u-boot but > > works in > > a USB2.0 port. > > I am not disputing the need for USB 3.0 device reset, I believe there > are two issues here -- one is the hard-wired VBus regulator -- the other > is this USB 3.0 reset. They should both be fixed. > >>> > >>> Sure, agreed 100%. > >>> Do we need to fix both at the same time? > >>> Both patches seem to be independent. > >> > >> Separate patch for the regulator please . > > > > Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but > > there seems to be a bug in the rk3399-rockpro64.dtsi from linux where > > the typec phy > > is configure with wrong regulator and if I do the patch as below > > > > --- a/arch/arm/dts/rk3399-r
Re: [PATCH v4 0/4] bootflow: bootmeth_efi: Fix network efi boot.
Hi Simon, On Sun, Nov 19, 2023 at 4:56 PM Shantur Rathore wrote: > > > Currently bootmeth_efi crashes while doing a network (dhcp) boot. > This patch series fixes issues and both network and disk boot works. > How can I help to get this patch series merged in? Kind Regards Shantur
Re: [PATCH] starfive: visionfive2: add device tree overlay support
On Mon, Nov 20, 2023 at 02:35:31AM +, John Clark wrote: > device tree overlay support requires fdtoverlay_addr_r to be set > > before > ~~ > Invalid fdtoverlay_addr_r for loading overlays > > after > ~ > Retrieving file: /boot/overlay/rtc-ds3231.dtbo > > Signed-off-by: John Clark > --- > > include/configs/starfive-visionfive2.h | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH V3 1/3] doc: falcon: riscv: Falcon Mode boot on RISC-V
On Thu, Nov 16, 2023 at 09:01:34PM +0800, Randolph wrote: > Add documentation to introduce the Falcon Mode on RISC-V. > In this mode, the boot sequence is SPL -> OpenSBI -> Linux kernel. > > Signed-off-by: Randolph > --- > doc/develop/falcon.rst | 171 + > 1 file changed, 171 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH V3 2/3] spl: riscv: falcon: move fdt blob to specified address
On Thu, Nov 16, 2023 at 09:01:35PM +0800, Randolph wrote: > In Falcon Boot mode, the fdt blob should be move to the RAM from > kernel BSS section. To avoid being cleared by BSS initialisation. > SPL_PAYLOAD_ARGS_ADDR is the address where SPL copies. > > Signed-off-by: Randolph > --- > board/AndesTech/ae350/ae350.c | 25 - > common/spl/Kconfig| 2 +- > common/spl/spl_opensbi.c | 16 > 3 files changed, 17 insertions(+), 26 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH V3 3/3] configs: andes: add the fdt blob address for SPL copy to
On Thu, Nov 16, 2023 at 09:01:36PM +0800, Randolph wrote: > Add the address where the FDT blob should be moved. > > Signed-off-by: Randolph > --- > configs/ae350_rv32_falcon_defconfig | 1 + > configs/ae350_rv32_falcon_xip_defconfig | 1 + > configs/ae350_rv64_falcon_defconfig | 1 + > configs/ae350_rv64_falcon_xip_defconfig | 1 + > 4 files changed, 4 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 2/4] watchdog: Add StarFive Watchdog driver
On 11/6/23 00:13, Chanho Park wrote:
Add to support StarFive watchdog driver. The driver is imported from
linux kernel's drivers/watchdog/starfive-wdt.c without jh7100 support
because there is no support of jh7100 SoC in u-boot yet.
Howver, this patch has been kept the variant coding style because JH7100
can be added later and have a consistency with the linux driver.
Signed-off-by: Chanho Park
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/watchdog/Kconfig| 7 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/starfive_wdt.c | 329
3 files changed, 337 insertions(+)
create mode 100644 drivers/watchdog/starfive_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 07fc4940e918..569726119ca1 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -344,6 +344,13 @@ config WDT_STM32MP
Enable the STM32 watchdog (IWDG) driver. Enable support to
configure STM32's on-SoC watchdog.
+config WDT_STARFIVE
+ bool "StarFive watchdog timer support"
+ depends on WDT
+ imply WATCHDOG
+ help
+ Enable support for the watchdog timer of StarFive JH7110 SoC.
+
config WDT_SUNXI
bool "Allwinner sunxi watchdog timer support"
depends on WDT && ARCH_SUNXI
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index eef786f5e74e..5520d3d9ae8a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
obj-$(CONFIG_WDT_SL28CPLD) += sl28cpld-wdt.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
+obj-$(CONFIG_WDT_STARFIVE) += starfive_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_SUNXI) += sunxi_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/starfive_wdt.c b/drivers/watchdog/starfive_wdt.c
new file mode 100644
index ..ee9ec4cdc3a4
--- /dev/null
+++ b/drivers/watchdog/starfive_wdt.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Starfive Watchdog driver
+ *
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* JH7110 Watchdog register define */
+#define STARFIVE_WDT_JH7110_LOAD 0x000
+#define STARFIVE_WDT_JH7110_VALUE 0x004
+#define STARFIVE_WDT_JH7110_CONTROL0x008 /*
+* [0]: reset enable;
+* [1]: interrupt enable &&
watchdog enable
+* [31:2]: reserved.
+*/
+#define STARFIVE_WDT_JH7110_INTCLR 0x00c /* clear intterupt and reload
the counter */
+#define STARFIVE_WDT_JH7110_IMS0x014
+#define STARFIVE_WDT_JH7110_LOCK 0xc00 /* write 0x1ACCE551 to unlock */
+
+/* WDOGCONTROL */
+#define STARFIVE_WDT_ENABLE0x1
+#define STARFIVE_WDT_EN_SHIFT 0
+#define STARFIVE_WDT_RESET_EN 0x1
+#define STARFIVE_WDT_JH7110_RST_EN_SHIFT 1
+
+/* WDOGLOCK */
+#define STARFIVE_WDT_JH7110_UNLOCK_KEY 0x1acce551
+
+/* WDOGINTCLR */
+#define STARFIVE_WDT_INTCLR0x1
+#define STARFIVE_WDT_JH7100_INTCLR_AVA_SHIFT 1 /* Watchdog can clear
interrupt when 0 */
+
+#define STARFIVE_WDT_MAXCNT0x
+#define STARFIVE_WDT_DEFAULT_TIME (15)
+#define STARFIVE_WDT_DELAY_US 0
+#define STARFIVE_WDT_TIMEOUT_US1
+
+/* module parameter */
+#define STARFIVE_WDT_EARLY_ENA 0
+
+struct starfive_wdt_variant {
+ unsigned int control; /* Watchdog Control Resgister for reset
enable */
+ unsigned int load; /* Watchdog Load register */
+ unsigned int reload;/* Watchdog Reload Control register */
+ unsigned int enable;/* Watchdog Enable Register */
+ unsigned int value; /* Watchdog Counter Value Register */
+ unsigned int int_clr; /* Watchdog Interrupt Clear Register */
+ unsigned int unlock;/* Watchdog Lock Register */
+ unsigned int int_status;/* Watchdog Interrupt Status Register */
+
+ u32 unlock_key;
+ char enrst_shift;
+ char en_shift;
+ bool intclr_check; /* whether need to check it before
clearing interrupt */
+ char intclr_ava_shift;
+ bool double_timeout;/* The watchdog need twice timeout to
reboot */
+};
+
+struct starfive_wdt_priv {
+ void __iomem *base;
+ struct clk *core_clk;
+ struct clk *apb_clk;
+ struct reset_ctl_bulk *rst;
+ const struct starfive_wdt_variant *variant;
+ unsigned long freq;
+ u32 count; /* count of timeout */
+ u32 reload;
Re: [PATCH 00/21] Qualcomm generic board support
On Mon, 4 Dec 2023 at 16:30, Daniel Thompson wrote: > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > > wrote: > > > > > > I've been thinking about and hacking on this for the last week or > > > > > > so, > > > > > > sorry for the delayed reply here. > > > > > > > > > > > > The value is in preventing any of the existing bindings from > > > > > > regressing, > > > > > > > > That is actually best addressed in Linux by checking the DTS against > > > > yaml DT bindings. We don't have that testing available in u-boot and > > > > only depend on careful reviews. > > > > > > I would absolutely love for someone to make another attempt at updating > > > our kbuild infrastucture so that we can run the validation targets. > > > > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > > not OS to supply the devicetree, it becomes evident that > > firmware/bootloaders import DTS from Linux kernel (where it is > > maintained). > > > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > The kernel is regularly released in multiple forms (including git > tags and tarball). Why isn't the kernel itself sufficient to be a > versioned release of the DT bindings directory? > The Linux kernel may come in various forms (upstream vs stable vs vendor). It's difficult to decide from where the DT bindings should come from. Should they come from upstream or should they come from the kernel which is actually booted onto a particular device? IOW, as of now which kernel version should u-boot pick up for DT validation checks? If we can have a separate release cadence for DT bindings then the platform (firmware/bootloader) can attest the DTB against that. Later one should be able to boot any kernel with the DTB provided by platform. -Sumit > > Daniel.
Re: [PATCH 00/21] Qualcomm generic board support
On 04/12/2023 14:24, Sumit Garg wrote: > On Mon, 4 Dec 2023 at 16:30, Daniel Thompson > wrote: >> >> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >>> + Linux kernel DT bindings maintainers, EBBR ML >>> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > wrote: >>> I've been thinking about and hacking on this for the last week or so, >>> sorry for the delayed reply here. >>> >>> The value is in preventing any of the existing bindings from regressing, > > That is actually best addressed in Linux by checking the DTS against > yaml DT bindings. We don't have that testing available in u-boot and > only depend on careful reviews. I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets. >>> >>> Given that EBBR requires [1] the platform (firmware/bootloader) and >>> not OS to supply the devicetree, it becomes evident that >>> firmware/bootloaders import DTS from Linux kernel (where it is >>> maintained). >>> >>> But currently u-boot doesn't have a proper way to validate those DTS >>> against DT bindings (maintained in Linux kernel). Although there are >>> Devicetree schema tools available here [2], there isn't a versioned >>> release package of DT bindings which one should use to validate DTS >>> files. >> >> The kernel is regularly released in multiple forms (including git >> tags and tarball). Why isn't the kernel itself sufficient to be a >> versioned release of the DT bindings directory? >> > > The Linux kernel may come in various forms (upstream vs stable vs > vendor). It's difficult to decide from where the DT bindings should > come from. Should they come from upstream or should they come from the > kernel which is actually booted onto a particular device? > > IOW, as of now which kernel version should u-boot pick up for DT > validation checks? The same version as in case of release from separate DT bindings repo. > > If we can have a separate release cadence for DT bindings then the > platform (firmware/bootloader) can attest the DTB against that. Later > one should be able to boot any kernel with the DTB provided by > platform. Separate releases of DT bindings change nothing here - you are going to ask the same question: "which release shall I take"? So the answer could be the same for both: take latest mainline kernel release. You really don't need separate repo just to know which release to take. Best regards, Krzysztof
[PATCH] mmc: mediatek: set b_max according CONFIG_SYS_MMC_MAX_BLK_COUNT
The block count limit on MMC based devices should be set according to CONFIG_SYS_MMC_MAX_BLK_COUNT instead of hardcoding value. Signed-off-by: Julien Masson --- drivers/mmc/mtk-sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c index d21a30c954..5a0c61daed 100644 --- a/drivers/mmc/mtk-sd.c +++ b/drivers/mmc/mtk-sd.c @@ -1665,7 +1665,7 @@ static int msdc_drv_probe(struct udevice *dev) if (cfg->f_max < cfg->f_min || cfg->f_max > host->src_clk_freq) cfg->f_max = host->src_clk_freq; - cfg->b_max = 1024; + cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT; cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34; host->mmc = &plat->mmc; -- 2.43.0
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
Hello. >>> pre-filling with 0xff creates a proper boot loader image, but no >>> bad-block marker is there when written to flash. > Isn't there some kobs-ng or whatever tool it was to properly initialize > the NAND on MXS ? I didn't know. I used what u-boot offers, which works for me without vendor tools -- and dare I say I trust u-boot tools more than vendor tools?. The default environment even has the rule to reflash from any u-boot.nand you manage to put into RAM. The only issue is that u-boot.nand, as created, marks good blocks as bad by prefilling with zeores. thanks /alessandro
[PATCH v1 6/8] board: asus: transformer: switch to DM pinmux
Drop the pinmux setup in the board in favor of setting it up in
the device tree. Device tree nodes match nodes used in the Linux
device tree.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra30-asus-p1801-t.dts | 982 +
arch/arm/dts/tegra30-asus-tf201.dts | 45 +
arch/arm/dts/tegra30-asus-tf300t.dts | 45 +
arch/arm/dts/tegra30-asus-tf300tg.dts | 128 +++
arch/arm/dts/tegra30-asus-tf300tl.dts | 163 +++
arch/arm/dts/tegra30-asus-tf600t.dts | 889
arch/arm/dts/tegra30-asus-tf700t.dts | 53 +
arch/arm/dts/tegra30-asus-transformer.dtsi| 984 ++
.../pinmux-config-transformer.h | 365 ---
board/asus/transformer-t30/transformer-t30.c | 23 -
10 files changed, 3289 insertions(+), 388 deletions(-)
delete mode 100644 board/asus/transformer-t30/pinmux-config-transformer.h
diff --git a/arch/arm/dts/tegra30-asus-p1801-t.dts
b/arch/arm/dts/tegra30-asus-p1801-t.dts
index 19de984d5f..350443d55e 100644
--- a/arch/arm/dts/tegra30-asus-p1801-t.dts
+++ b/arch/arm/dts/tegra30-asus-p1801-t.dts
@@ -60,6 +60,988 @@
};
};
+ pinmux@7868 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+
+ state_default: pinmux {
+ /* SDMMC1 pinmux */
+ sdmmc1_clk {
+ nvidia,pins = "sdmmc1_clk_pz0";
+ nvidia,function = "sdmmc1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc1_cmd {
+ nvidia,pins = "sdmmc1_dat3_py4",
+ "sdmmc1_dat2_py5",
+ "sdmmc1_dat1_py6",
+ "sdmmc1_dat0_py7",
+ "sdmmc1_cmd_pz1";
+ nvidia,function = "sdmmc1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc1_cd {
+ nvidia,pins = "gmi_iordy_pi5";
+ nvidia,function = "rsvd1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc1_wp {
+ nvidia,pins = "vi_d11_pt3";
+ nvidia,function = "rsvd2";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+
+ /* SDMMC2 pinmux */
+ vi_d1_pd5 {
+ nvidia,pins = "vi_d1_pd5",
+ "vi_d2_pl0",
+ "vi_d3_pl1",
+ "vi_d5_pl3",
+ "vi_d7_pl5";
+ nvidia,function = "sdmmc2";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ vi_d8_pl6 {
+ nvidia,pins = "vi_d8_pl6",
+ "vi_d9_pl7";
+ nvidia,function = "sdmmc2";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ nvidia,lock = <0>;
+ nvidia,ioreset = <0>;
+ };
+
+ /* SDMMC3 pinmux */
+ sdmmc3_clk {
+ nvidia,pins = "sdmmc3_clk_pa6";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ sdmmc3_cmd {
+ nvidia,pins = "sdmmc3_cmd_pa7",
+ "sdmmc3_dat0_pb7",
+ "sdmmc3_dat1_pb6",
+ "sdmmc3_dat2_pb5",
+ "sdmmc3_dat3_pb4",
+ "sdmmc3_dat4_pd1",
+
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
> But what about the bad block markers , do they get erased when you write > this U-Boot image into the NAND ? The image includes OOB data, because the rom-mandated map is different from normal standards. If OOB is zeroed, blocks appear as bad (correctly!). By memsetting to 0xff, before filling data structures and checksums, we get a binary that written with "nand write.raw" works properly (the rom is happy with the format and boots) but doesn't mark blocks as bad. [actually, only the first half-a-meg is with-oob, the trailing part is not, and the image is partly written with "nand write.raw" and partly with "nand write". Hairy things based on hairy vendor choices in hw/rom] But tools/mxsboot works fine, and saved my day (or more). thanks /alessandro
Re: Setting up boot chain ACPI on ARM with STM32MPU
> > Sort-of...the refactoring to allow ACPI tables on ARM is completed, > but I don't think any U-Boot board uses this. Hello, could you tell me more details about this topic? Which platform ARM are ACPI tables enabled for? Le mer. 29 nov. 2023 à 20:28, Simon Glass a écrit : > +Heinrich Schuchardt > > Hi, > > On Wed, 29 Nov 2023 at 08:29, Ba Gia Bao Phan > wrote: > > > > Hello everyone, > > > > I am a trainee at STMicroelectronics France. I am working on a project > "Setting up a boot chain ACPI" for STM32MPU, which is based on ARM Cortex-A > . The objective of my project is to add a way of booting (with ACPI) > besides Device Tree available on STM32MPU. > > > > I found that ACPI was enabled on some x86 platforms but I don't know > whether it was set up on ARM or not. I found a PATCH that discussed > Enabling ACPI booting on ARM with Raspberry Pi 4 but I don't know if it > functioned or not. Did anyone here succeed in setting up ACPI on ARM by > U-boot? > > Sort-of...the refactoring to allow ACPI tables on ARM is completed, > but I don't think any U-Boot board uses this. > > > > > What are the differences between x86 and ARM platforms when enabling > ACPI? The architecture of my board STM32PMU is ARM so can I apply the > technique used on platform x86 for my board? > > Firstly I wonder why you want ACPI? > > Secondly, if you have the tables somewhere it should be easy enough to > build them, building on the series you pointed to. Heinrich is > interested in this, I think. I can help with advice. I have been > toying with going back to that rpi series but have not done so yet. > > Regards, > Simon > -- PHAN Ba Gia Bao Etudiant en 5A STI - INSA Centre Val de Loire
Re: [PATCH 00/21] Qualcomm generic board support
Hi Summit, Here are additional elements that you may want to consider. This topic should be thought of with « who provides what » question in mind. For quite a long time, one single entity was providing secure firmware, firmware, boot loader (I think of Grub when I use this overloaded term), and OS. This explains why the Linux kernel community has been maintaining DT (not justifying it is now still a good model). For Software Defined Vehicle and many other scenarios this supply chain is not working. In the context of this separation, OS/Hypervisor supplying any DTB is a non-sense. (Translated in real life: as a French driver, my DTB description of a car is that the steering wheel is on the left hand side. If I get on a UK car, I will complain that my hardware description does not match reality. Conclusion: better use DTB given from the platform!). If I am not mistaken Fedora IOT 39 does not come with any DTBs: that was a theme hinted by Peter Robinson a while ago (Peter you may want to comment on this). My understanding is that SystemReady was proposed and developed to address such a different supply chain where: - the OS may be supplied by a party not controlling the underlying layers - have standard contract between OS and previous entities - The entity controlling the hardware is not an OS but a type-1 hypervisor In all this context, the DT should be consumed by OSes (Linux, Zephyr, Eclipse ThreadX (donated by Microsoft), commercial ones…) and hypervisors. The "DT » passed to a Linux (be it equivalent to Dom0) may not be the definitive vision of the whole platform. You may want to talk with the System Device Tree folks. So there is no such a thing as « THE » device tree of the platform. There can be a DT for BL33 firmware, a DT for OS/Hypervisor, a DT for TrustZone (highly decorated with clocks and power nodes that are often irrelevant to BL33 and OS/Hypervisor). The BL33 and OS/Hypervisor DTs location is not defined by EBBR but my view is that the OS/Hypervisor DT can be located in the HW_CONFIG section of a FIP (this section is made for holding the OS DT). The FIP can come from the SoC vendor, later updated by the Board vendor: fiptool --hw-config With a separate signing key. So, you should take into account which markets are targeted by the SoC for which you posted your message. If it is traditional embedded, one-entity provides all. You can surely choose any scheme you want. If it is automotive and other markets where there will be separation in the firmware/OS/Hypervisor supply chain, then you should clearly attach the DT to Secure Firmware. Cheers FF PS1: I see an analogy with Google project Trebble which set clear responsibilities in who can provide/modify what. Before it, it was the jungle and pushing a security fix required months of delays. Now a Google security fix can make its way to smartphones in matter of days. Constraining a little bit the Linux driver developers to what should they focus on (nice drivers and not hardware description) will just make things better. Failure to do so will just push for ACPI and its horrible complex, fragile virtual machine to push out DT from those markets... PS2: By « nice" drivers I mean, for instance, drivers that do not assume they are alone in the world and can do whatever they want with clocks that feed the device: they should use proper clock control such as SCMI (trouble for device assignment to a VM for instance). Le 4 déc. 2023 à 06:32, Sumit Garg a écrit : + Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: On Wed, 29 Nov 2023 at 22:06, Neil Armstrong wrote: On 29/11/2023 16:34, Caleb Connolly wrote: On 23/11/2023 07:04, Sumit Garg wrote: On Wed, 22 Nov 2023 at 21:34, Caleb Connolly wrote: On 22/11/2023 14:27, Tom Rini wrote: On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: On Wed, 22 Nov 2023 at 19:31, Tom Rini wrote: On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: Hi Caleb, On Tue, 21 Nov 2023 at 22:39, Caleb Connolly wrote: [snip] == DT loading == Previously, boards used the FDT blob embedded into U-Boot (via OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary bootloader, so we can instead rely on the first-stage bootloader to populate some useful FDT properties for us (notably the /memory node and KASLR seed) and fetch the DTB that it provides. Combined with the memory map changes above, this let's us entirely avoid configuring the memory map explicitly. Since with this change, we don't need to embed FDT blob in the u-boot binary, so I was thinking if we really need to import DTs from Linux for different platforms and then play a catchup game? For now, yes. But why? Is there any value added by larger u-boot specific DT (most of the nodes being unused by u-boot) than what currently u-boot supports? The more important part is to get al
Re: [PATCH 00/21] Qualcomm generic board support
> Le 4 déc. 2023 à 12:00, Daniel Thompson a écrit : > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >> + Linux kernel DT bindings maintainers, EBBR ML >> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: >>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: On Wed, 29 Nov 2023 at 22:06, Neil Armstrong wrote: >> I've been thinking about and hacking on this for the last week or so, >> sorry for the delayed reply here. >> >> The value is in preventing any of the existing bindings from regressing, That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews. >>> >>> I would absolutely love for someone to make another attempt at updating >>> our kbuild infrastucture so that we can run the validation targets. >>> >> >> Given that EBBR requires [1] the platform (firmware/bootloader) and >> not OS to supply the devicetree, it becomes evident that >> firmware/bootloaders import DTS from Linux kernel (where it is >> maintained). >> >> But currently u-boot doesn't have a proper way to validate those DTS >> against DT bindings (maintained in Linux kernel). Although there are >> Devicetree schema tools available here [2], there isn't a versioned >> release package of DT bindings which one should use to validate DTS >> files. > > The kernel is regularly released in multiple forms (including git > tags and tarball). Why isn't the kernel itself sufficient to be a > versioned release of the DT bindings directory? > The Linux kernel may not see all devices. For instance it could see a PCI port while the firmware sees a SERDES that is configured to match the board implementation and touting. The firmware shall be responsible to, statically or dynamically make those things available to the kernel. An OS distribution (not necessarily Linux) should not embedded all possible combinations and know all derived boards. > > Daniel. > ___ > boot-architecture mailing list -- boot-architect...@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
Re: [PATCH 00/21] Qualcomm generic board support
On 04/12/2023 15:38, ff wrote: > > >> Le 4 déc. 2023 à 12:00, Daniel Thompson a écrit >> : >> >> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >>> + Linux kernel DT bindings maintainers, EBBR ML >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > wrote: >>> I've been thinking about and hacking on this for the last week or so, >>> sorry for the delayed reply here. >>> >>> The value is in preventing any of the existing bindings from regressing, > > That is actually best addressed in Linux by checking the DTS against > yaml DT bindings. We don't have that testing available in u-boot and > only depend on careful reviews. I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets. >>> >>> Given that EBBR requires [1] the platform (firmware/bootloader) and >>> not OS to supply the devicetree, it becomes evident that >>> firmware/bootloaders import DTS from Linux kernel (where it is >>> maintained). >>> >>> But currently u-boot doesn't have a proper way to validate those DTS >>> against DT bindings (maintained in Linux kernel). Although there are >>> Devicetree schema tools available here [2], there isn't a versioned >>> release package of DT bindings which one should use to validate DTS >>> files. >> >> The kernel is regularly released in multiple forms (including git >> tags and tarball). Why isn't the kernel itself sufficient to be a >> versioned release of the DT bindings directory? >> > The Linux kernel may not see all devices. For instance it could see a PCI > port while the firmware sees a SERDES that is configured to match the board > implementation and touting. The firmware shall be responsible to, statically > or dynamically make those things available to the kernel. > An OS distribution (not necessarily Linux) should not embedded all possible > combinations and know all derived boards. Which is nothing related to the discussion here: bindings. The bindings *MUST* cover PCI port and serdes. P.S. Please wrap your replies to match mailing list style / netiquette. Best regards, Krzysztof
Re: [PATCH v1 0/8] Convert Tegra pinctrl to DM
пн, 4 груд. 2023 р. о 12:26 Thierry Reding пише: > > On Mon, Dec 04, 2023 at 10:20:46AM +0200, Svyatoslav Ryhel wrote: > > Create a DM supported wrapper arround existing Tegra pinmux logic. > > This implementation is backwards compatible with all existing board > > setups and early stages of setup. All new boards must be device tree > > based. Linux dts pinmux nodes are fully compatible with this driver. > > > > As an example I have converted recently merged T30 boards to this > > layout (I have those devices and was able to test them properly) and > > Paz00 T20 board which was tested as well by owner. > > > > Svyatoslav Ryhel (8): > > ARM: mach-tegra: rearrange SPL configs > > drivers: pinctrl: create Tegra DM pinctrl driver > > drivers: pinctrl: tegra: incorporate existing code > > board: asus: grouper: switch to DM pinmux > > board: lg: x3-t30: switch to DM pinmux > > board: asus: transformer: switch to DM pinmux > > board: htc: endeavoru: switch to DM pinmux > > board: compal: paz00: clean up the board > > > > arch/arm/dts/tegra20-paz00.dts|4 +- > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 712 ++ > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 113 ++ > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 113 ++ > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 149 +++ > > arch/arm/dts/tegra30-asus-p1801-t.dts | 982 ++ > > arch/arm/dts/tegra30-asus-tf201.dts | 45 + > > arch/arm/dts/tegra30-asus-tf300t.dts | 45 + > > arch/arm/dts/tegra30-asus-tf300tg.dts | 128 ++ > > arch/arm/dts/tegra30-asus-tf300tl.dts | 163 +++ > > arch/arm/dts/tegra30-asus-tf600t.dts | 889 + > > arch/arm/dts/tegra30-asus-tf700t.dts | 53 + > > arch/arm/dts/tegra30-asus-transformer.dtsi| 984 ++ > > arch/arm/dts/tegra30-htc-endeavoru.dts| 1147 + > > arch/arm/dts/tegra30-lg-p880.dts | 90 ++ > > arch/arm/dts/tegra30-lg-p895.dts | 93 ++ > > arch/arm/dts/tegra30-lg-x3.dtsi | 845 > > arch/arm/include/asm/arch-tegra114/pinmux.h | 303 + > > arch/arm/include/asm/arch-tegra124/pinmux.h | 327 + > > arch/arm/include/asm/arch-tegra20/pinmux.h| 291 + > > arch/arm/include/asm/arch-tegra210/pinmux.h | 394 ++ > > arch/arm/include/asm/arch-tegra30/pinmux.h| 381 ++ > > arch/arm/mach-tegra/Kconfig | 16 +- > > arch/arm/mach-tegra/Makefile |1 - > > arch/arm/mach-tegra/board.c |6 +- > > arch/arm/mach-tegra/board2.c |2 +- > > arch/arm/mach-tegra/tegra114/Makefile |2 +- > > arch/arm/mach-tegra/tegra124/Makefile |2 - > > arch/arm/mach-tegra/tegra20/Makefile |2 +- > > arch/arm/mach-tegra/tegra210/Makefile |1 - > > arch/arm/mach-tegra/tegra30/Makefile |2 +- > > board/asus/grouper/grouper.c | 18 - > > board/asus/grouper/pinmux-config-grouper.h| 362 -- > > .../pinmux-config-transformer.h | 365 -- > > board/asus/transformer-t30/transformer-t30.c | 23 - > > board/compal/paz00/Makefile |8 - > > board/compal/paz00/paz00.c| 53 - > > board/htc/endeavoru/endeavoru.c | 14 - > > board/htc/endeavoru/pinmux-config-endeavoru.h | 362 -- > > board/lg/x3-t30/Kconfig | 12 - > > board/lg/x3-t30/configs/p880.config |1 - > > board/lg/x3-t30/configs/p895.config |1 - > > board/lg/x3-t30/pinmux-config-x3.h| 449 --- > > board/lg/x3-t30/x3-t30.c | 23 - > > configs/paz00_defconfig |3 + > > drivers/pinctrl/Kconfig |1 + > > drivers/pinctrl/Makefile |1 + > > drivers/pinctrl/tegra/Kconfig | 18 + > > drivers/pinctrl/tegra/Makefile| 16 + > > .../pinctrl/tegra/funcmux-tegra114.c |0 > > .../pinctrl/tegra/funcmux-tegra124.c |0 > > .../pinctrl/tegra/funcmux-tegra20.c |0 > > .../pinctrl/tegra/funcmux-tegra210.c |0 > > .../pinctrl/tegra/funcmux-tegra30.c |0 > > drivers/pinctrl/tegra/pinctrl-tegra.c | 248 > > drivers/pinctrl/tegra/pinctrl-tegra20.c | 177 +++ > > .../pinctrl/tegra}/pinmux-common.c|0 > > .../pinctrl/tegra/pinmux-tegra114.c |0 > > .../pinctrl/tegra/pinmux-tegra124.c |0 > > .../pinctrl/tegra/pinmux-tegra20.c|0 > > drivers/pinctrl/tegra/pinmux-tegra210.c | 190 +++ > > .../pinctrl/tegra/pinmux-tegra30.c|0 > > include/configs/x3-t30.h | 13 +- > > 63 files changed, 8920 insertions(+), 1723 deletio
Re: [PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument
On 12/4/23 5:21 AM, Neha Malcom Francis wrote: Mention TI_DM argument can be used to fetch a custom DM binary in the A72 build instructions for K3 devices. Signed-off-by: Neha Malcom Francis --- doc/board/ti/k3.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a127215ce5..15916b088f 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -320,6 +320,13 @@ use the `lite` option. make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \ BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \ TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin + +.. note:: + It is also possible to pick up a custom DM binary by adding TI_DM argument + pointing to the file. If not provided, it defaults to picking up the DM + binary from ti-linux-firmware. This is only applicable to devices that It would only be "ti-linux-firmware" if that is what you had set as BINMAN_INDIRS. s/ti-linux-firmware/BINMAN_INDIRS Otherwise whole series LGTM, Reviewed-by: Andrew Davis + utilize split firmware. + .. k3_rst_include_end_build_steps_uboot At this point you should have every binary needed initialize both the
Re: [PATCH 0/2] serial: msm-geni: rework oversampling and fix clk API bug
On Tue, 14 Nov 2023 12:51:10 +, Caleb Connolly wrote: > These patches improve GENI UART support during init by implementing the > parent property read directly rather than via a misc device, and fixing > the error path when the clock can't be found. > > In my testing, the first few lines of UART output on platforms with > non-default oversampling values is often garbled, this is because the > parent misc device hasn't yet probed and so the clock rate is incorrect. > > [...] Applied, thanks! [1/2] serial: msm-geni: don't rely on parent misc device commit: 393825c304411c6483dbfbc45ea09c577365ddb9 [2/2] serial: msm-geni: handle devm_clk_get() errors commit: afd9dcf23cb232dd5f352336c6b389691682be47 Best regards, -- // Caleb (they/them)
Re: [PATCH v2 01/18] bloblist: Update the tag numbering
Hi Ilias,
BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW
Handoff spec for TF-A project only.
The TPM eventlog related ones are undefined in the spec yet, they stay in
the group BLOBLISTT_AREA_FIRMWARE.
> /* BLOBLISTT_AREA_FIRMWARE */
>- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> { BLOBLISTT_TCPA_LOG, "TPM log space" },
>- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
Thanks and regards,
Raymond
On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas
wrote:
> Hi all,
>
> [...]
>
> > common/bloblist.c | 16 +---
> > include/bloblist.h | 65 --
> > test/bloblist.c| 4 +--
> > 3 files changed, 48 insertions(+), 37 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index a22f6c12b0..349ceddea5 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -36,16 +36,24 @@ static struct tag_name {
> > enum bloblist_tag_t tag;
> > const char *name;
> > } tag_name[] = {
> > - { BLOBLISTT_NONE, "(none)" },
> > + { BLOBLISTT_VOID, "(void)" },
> >
> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
> > + { BLOBLISTT_CONTROL_FDT, "Control FDT" },
> > + { BLOBLISTT_HOB_BLOCK, "HOB block" },
> > + { BLOBLISTT_HOB_LIST, "HOB list" },
> > + { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >
> > /* BLOBLISTT_AREA_FIRMWARE */
> > - { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > - { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> > - { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>
> There are some TPM Eventlog related entries that are missing here.
> Can we add them?
>
> > + { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > +
> > + /* BLOBLISTT_AREA_ARM */
> > + { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
> > +
> > + /* BLOBLISTT_AREA_OTHER */
> > + { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> [...]
>
> Thanks
> /Ilias
>
Re: [PATCH v2 05/18] bloblist: Access record hdr_size and tag via a function
Hi Ilias,
This patch is for later grouping the tag and hdr_size in
'0011-bloblist-Reduce-blob-header-size.patch'.
I can update the commit message.
Thanks and regards,
Raymond
On Mon, 4 Dec 2023 at 03:31, Ilias Apalodimas
wrote:
> On Mon, 27 Nov 2023 at 21:52, Raymond Mao wrote:
> >
> > From: Simon Glass
> >
> > These values currently use a simple field. With spec v0.9 they have moved
> > to a packed format. Convert most accesses to use functions, so this
> change
> > can be accommodated.
>
> I don't really understand how the commit message is related to the changes.
> What did the packed format affect that we need a function?
>
> Thanks
> /Ilias
> >
> > Signed-off-by: Simon Glass
> > Signed-off-by: Raymond Mao
> > ---
> > common/bloblist.c | 38 +-
> > 1 file changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index e744c2b0c0..f084a32cfc 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -82,13 +82,23 @@ static struct bloblist_rec
> *bloblist_first_blob(struct bloblist_hdr *hdr)
> > return (struct bloblist_rec *)((void *)hdr + hdr->hdr_size);
> > }
> >
> > +static inline uint rec_hdr_size(struct bloblist_rec *rec)
> > +{
> > + return rec->hdr_size;
> > +}
> > +
> > +static inline uint rec_tag(struct bloblist_rec *rec)
> > +{
> > + return rec->tag;
> > +}
> > +
> > static ulong bloblist_blob_end_ofs(struct bloblist_hdr *hdr,
> >struct bloblist_rec *rec)
> > {
> > ulong offset;
> >
> > offset = (void *)rec - (void *)hdr;
> > - offset += rec->hdr_size + ALIGN(rec->size, BLOBLIST_ALIGN);
> > + offset += rec_hdr_size(rec) + ALIGN(rec->size, BLOBLIST_ALIGN);
> >
> > return offset;
> > }
> > @@ -117,7 +127,7 @@ static struct bloblist_rec *bloblist_findrec(uint
> tag)
> > return NULL;
> >
> > foreach_rec(rec, hdr) {
> > - if (rec->tag == tag)
> > + if (rec_tag(rec) == tag)
> > return rec;
> > }
> >
> > @@ -156,7 +166,7 @@ static int bloblist_addrec(uint tag, int size, int
> align_log2,
> > rec->spare = 0;
> >
> > /* Zero the record data */
> > - memset((void *)rec + rec->hdr_size, '\0', rec->size);
> > + memset((void *)rec + rec_hdr_size(rec), '\0', rec->size);
> >
> > hdr->alloced = new_alloced;
> > *recp = rec;
> > @@ -197,7 +207,7 @@ void *bloblist_find(uint tag, int size)
> > if (size && size != rec->size)
> > return NULL;
> >
> > - return (void *)rec + rec->hdr_size;
> > + return (void *)rec + rec_hdr_size(rec);
> > }
> >
> > void *bloblist_add(uint tag, int size, int align_log2)
> > @@ -207,7 +217,7 @@ void *bloblist_add(uint tag, int size, int
> align_log2)
> > if (bloblist_addrec(tag, size, align_log2, &rec))
> > return NULL;
> >
> > - return (void *)rec + rec->hdr_size;
> > + return (void *)rec + rec_hdr_size(rec);
> > }
> >
> > int bloblist_ensure_size(uint tag, int size, int align_log2, void
> **blobp)
> > @@ -218,7 +228,7 @@ int bloblist_ensure_size(uint tag, int size, int
> align_log2, void **blobp)
> > ret = bloblist_ensurerec(tag, &rec, size, align_log2);
> > if (ret)
> > return ret;
> > - *blobp = (void *)rec + rec->hdr_size;
> > + *blobp = (void *)rec + rec_hdr_size(rec);
> >
> > return 0;
> > }
> > @@ -230,7 +240,7 @@ void *bloblist_ensure(uint tag, int size)
> > if (bloblist_ensurerec(tag, &rec, size, 0))
> > return NULL;
> >
> > - return (void *)rec + rec->hdr_size;
> > + return (void *)rec + rec_hdr_size(rec);
> > }
> >
> > int bloblist_ensure_size_ret(uint tag, int *sizep, void **blobp)
> > @@ -243,7 +253,7 @@ int bloblist_ensure_size_ret(uint tag, int *sizep,
> void **blobp)
> > *sizep = rec->size;
> > else if (ret)
> > return ret;
> > - *blobp = (void *)rec + rec->hdr_size;
> > + *blobp = (void *)rec + rec_hdr_size(rec);
> >
> > return 0;
> > }
> > @@ -279,7 +289,7 @@ static int bloblist_resize_rec(struct bloblist_hdr
> *hdr,
> >
> > /* Zero the new part of the blob */
> > if (expand_by > 0) {
> > - memset((void *)rec + rec->hdr_size + rec->size, '\0',
> > + memset((void *)rec + rec_hdr_size(rec) + rec->size, '\0',
> >new_size - rec->size);
> > }
> >
> > @@ -313,8 +323,9 @@ static u32 bloblist_calc_chksum(struct bloblist_hdr
> *hdr)
> > chksum = crc32(0, (unsigned char *)hdr,
> >offsetof(struct bloblist_hdr, chksum));
> > foreach_rec(rec, hdr) {
> > - chksum = crc32(chksum, (void *)rec, rec->hdr_size);
> > - chksum = crc32(chksum, (void *)rec + rec->hdr_size,
> rec->size);
> > +
Re: [PATCH 00/21] Qualcomm generic board support
On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > wrote: > > > > > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly > > > > >> wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 22/11/2023 14:27, Tom Rini wrote: > > > > On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > > > > > On Wed, 22 Nov 2023 at 19:31, Tom Rini wrote: > > > > >> > > > > >> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > > > >>> Hi Caleb, > > > > >>> > > > > >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly > > > > >>> wrote: > > > > >> [snip] > > > > == DT loading == > > > > > > > > Previously, boards used the FDT blob embedded into U-Boot (via > > > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a > > > > secondary > > > > bootloader, so we can instead rely on the first-stage > > > > bootloader to > > > > populate some useful FDT properties for us (notably the > > > > /memory node and > > > > KASLR seed) and fetch the DTB that it provides. Combined with > > > > the memory > > > > map changes above, this let's us entirely avoid configuring > > > > the memory > > > > map explicitly. > > > > >>> > > > > >>> Since with this change, we don't need to embed FDT blob in the > > > > >>> u-boot > > > > >>> binary, so I was thinking if we really need to import DTs from > > > > >>> Linux > > > > >>> for different platforms and then play a catchup game? > > > > >>> > > > > >>> For now, yes. > > > > >> > > > > >> But why? Is there any value added by larger u-boot specific DT (most > > > > >> of the nodes being unused by u-boot) than what currently u-boot > > > > >> supports? The more important part is to get alignment with Linux DT > > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot > > > > >> DT for generalization purposes then you should import those > > > > >> particular > > > > >> nodes only. > > > > > > > > > > I've been thinking about and hacking on this for the last week or so, > > > > > sorry for the delayed reply here. > > > > > > > > > > The value is in preventing any of the existing bindings from > > > > > regressing, > > > > > > That is actually best addressed in Linux by checking the DTS against > > > yaml DT bindings. We don't have that testing available in u-boot and > > > only depend on careful reviews. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. > > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Note that I would like to revamp this repo to use some modern CI job, use git_filter_repo python module rather than git-filter-branch, and move to devicetree.org GH, but if projects aren't relying on this repo, I'm not motivated to do that work. Rob
Re: [PATCH v2 01/18] bloblist: Update the tag numbering
On Mon, 4 Dec 2023 at 18:25, Raymond Mao wrote:
>
> Hi Ilias,
>
> BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW
> Handoff spec for TF-A project only.
> The TPM eventlog related ones are undefined in the spec yet, they stay in the
> group BLOBLISTT_AREA_FIRMWARE.
We did define them past 0.9 [0]. So I think we should add them regardless.
They are part of the main doc now [1]
[0] https://github.com/FirmwareHandoff/firmware_handoff/pull/16/files
[1]
https://github.com/FirmwareHandoff/firmware_handoff/blob/main/source/transfer_list.rst#tpm-event-log-table-entry-layout-xferlist_evlog
Regards
/Ilias
>
> > /* BLOBLISTT_AREA_FIRMWARE */
> >- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> >- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>
> Thanks and regards,
> Raymond
>
> On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas
> wrote:
>>
>> Hi all,
>>
>> [...]
>>
>> > common/bloblist.c | 16 +---
>> > include/bloblist.h | 65 --
>> > test/bloblist.c| 4 +--
>> > 3 files changed, 48 insertions(+), 37 deletions(-)
>> >
>> > diff --git a/common/bloblist.c b/common/bloblist.c
>> > index a22f6c12b0..349ceddea5 100644
>> > --- a/common/bloblist.c
>> > +++ b/common/bloblist.c
>> > @@ -36,16 +36,24 @@ static struct tag_name {
>> > enum bloblist_tag_t tag;
>> > const char *name;
>> > } tag_name[] = {
>> > - { BLOBLISTT_NONE, "(none)" },
>> > + { BLOBLISTT_VOID, "(void)" },
>> >
>> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
>> > + { BLOBLISTT_CONTROL_FDT, "Control FDT" },
>> > + { BLOBLISTT_HOB_BLOCK, "HOB block" },
>> > + { BLOBLISTT_HOB_LIST, "HOB list" },
>> > + { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>> >
>> > /* BLOBLISTT_AREA_FIRMWARE */
>> > - { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>> > - { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
>> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
>> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
>> > - { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>>
>> There are some TPM Eventlog related entries that are missing here.
>> Can we add them?
>>
>> > + { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>> > +
>> > + /* BLOBLISTT_AREA_ARM */
>> > + { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
>> > +
>> > + /* BLOBLISTT_AREA_OTHER */
>> > + { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
>> [...]
>>
>> Thanks
>> /Ilias
Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
Hi, On Sat, Dec 2, 2023 at 8:37 AM Simon Glass wrote: > > Hi Ahmad, > > On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum wrote: > > > > Hello Simon, > > > > On 30.11.23 21:30, Simon Glass wrote: > > > On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum > > > wrote: > > >> On 29.11.23 20:44, Simon Glass wrote: > > >>> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum > > >>> wrote: > > > > On 29.11.23 20:27, Simon Glass wrote: > > > On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum > > > wrote: > > >> On 29.11.23 20:02, Simon Glass wrote: > > >>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum > > >>> wrote: > > The specification says that this is the root U-Boot compatible, > > which I presume to mean the top-level compatible, which makes > > sense to me. > > > > The code here though adds all compatible strings from the device > > tree though, > > is this intended? > > >>> > > >>> Yes, since it saves needing to read in each DT just to get the > > >>> compatible stringlist. > > >> > > >> The spec reads as if only one string (root) is supposed to be in the > > >> list. > > >> The script adds all compatibles though. This is not really useful as > > >> a bootloader > > >> that's compatible with e.g. fsl,imx8mm would just take the first > > >> device tree > > >> with that SoC, which is most likely to be wrong. It would be better > > >> to just > > >> specify the top-level compatible, so the bootloader fails instead of > > >> taking > > >> the first DT it finds. > > > > > > We do need to have a list, since we have to support different board > > > revs, etc. > > > > Can you give me an example? The way I see it, a bootloader with > > compatible "vendor,board" and a FIT with configuration with > > compatibles: > > > > "vendor,board-rev-a", "vendor,board" > > "vendor,board-rev-b", "vendor,board" > > > > would just result in the bootloader booting the first configuration, > > even if > > the device is actually rev-b. > > >>> > > >>> You need to find the best match, not just any match. This is > > >>> documented in the function comment for fit_conf_find_compat(). > > >> > > >> In my above example, both configuration are equally good. > > >> Can you give me an example where it makes sense to have multiple > > >> compatibles automatically extracted from the device tree compatible? > > >> > > >> The way I see it having more than one compatible here just has > > >> downsides. > > > > > > I don't have an example to hand, but this is the required mechanism of > > > FIT. This feature has been in place for many years and is used by > > > ChromeOS, at least. > > > > I see the utility of a FIT configuration with > > > > compatible = "vendor,board-rev-a", "vendor,board-rev-b"; > > > > I fail to see a utility for a configuration with > > > > compatible = "vendor,board", "vendor,SoM", "vendor,SoC"; > > > > Any configuration that ends up being booted because "vendor,SoC" was > > matched is > > most likely doomed to fail. Therefore, I would suggest that only the top > > level > > configuration is written into the FIT configurations automatically. > > Firstly, I am not an expert on this. > > Say you have a board with variants. The compatible string in U-Boot > may be something like: > > "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", > "rockchip,rk3288"; > > If you then have several FIT configurations, they may be something like: > > "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron", > "rockchip,rk3288"; > "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", > "rockchip,rk3288"; > "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron", > "rockchip,rk3288"; > > You want to choose the second one, since it is a better match than the others. > > +Doug Anderson who knows a lot more about this than me. Hopefully this is all explained by: https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
Hi Laurent, On Sun, 3 Dec 2023 at 08:33, Laurent Pinchart wrote: > > Hi Simon, > > Thank you for the patch. > > 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. OK, sounds good! > > 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 > meant to be used stand-alone as well, in which case its command line > arguments need to remain backward-compatible, or do you see it as being > internal to the kernel ? The script as written is internal to the kernel, but I am sure it could be expanded in some ways. I am waiting to see it merged before worrying too much about what might happen in the future! [..] Regards, Simon
Re: [PATCH 1/1] efi_loader: generated SMBIOS table below 4 GiB
On Mon, 20 Nov 2023 23:25:58 +0100, Heinrich Schuchardt wrote: > We currently use an outdated format 32-bit format for SMBIOS tables. > So we must allocate SMBIOS tables below 4 GiB. > > As this is reflects what has been done the longest, applied to u-boot/master, thanks! And we shall revisit all of these topics for v2024.04 or later. -- Tom
[ANN] U-Boot v2024.01-rc4 released
Hey all, It's release day and here is -rc4. There's just a few fixes I know of outstanding at this point, and only one of them (NAND for AM335x platforms) I think isn't something that can be said to be provably correct, to try and borrow mathematical terms. In terms of a changelog, git log --merges v2024.01-rc3..v2024.01-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. I hope to remain on schedule and that means the rest of the rcs every other Monday, and with final release on January 8th, 2024. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 01/18] bloblist: Update the tag numbering
Hi Ilias,
What is the difference between the new added XFERLIST_EVLOG and the
existing BLOBLISTT_TPM2_TCG_LOG and BLOBLISTT_TCPA_LOG in U-Boot?
Thanks and regards,
Raymond
On Mon, 4 Dec 2023 at 12:52, Ilias Apalodimas
wrote:
> On Mon, 4 Dec 2023 at 18:25, Raymond Mao wrote:
> >
> > Hi Ilias,
> >
> > BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW
> Handoff spec for TF-A project only.
> > The TPM eventlog related ones are undefined in the spec yet, they stay
> in the group BLOBLISTT_AREA_FIRMWARE.
>
> We did define them past 0.9 [0]. So I think we should add them regardless.
> They are part of the main doc now [1]
>
> [0] https://github.com/FirmwareHandoff/firmware_handoff/pull/16/files
> [1]
> https://github.com/FirmwareHandoff/firmware_handoff/blob/main/source/transfer_list.rst#tpm-event-log-table-entry-layout-xferlist_evlog
>
> Regards
> /Ilias
>
> >
> > > /* BLOBLISTT_AREA_FIRMWARE */
> > >- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > >- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> > > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> > > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> > >- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> > >+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >
> > Thanks and regards,
> > Raymond
> >
> > On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas <
> ilias.apalodi...@linaro.org> wrote:
> >>
> >> Hi all,
> >>
> >> [...]
> >>
> >> > common/bloblist.c | 16 +---
> >> > include/bloblist.h | 65
> --
> >> > test/bloblist.c| 4 +--
> >> > 3 files changed, 48 insertions(+), 37 deletions(-)
> >> >
> >> > diff --git a/common/bloblist.c b/common/bloblist.c
> >> > index a22f6c12b0..349ceddea5 100644
> >> > --- a/common/bloblist.c
> >> > +++ b/common/bloblist.c
> >> > @@ -36,16 +36,24 @@ static struct tag_name {
> >> > enum bloblist_tag_t tag;
> >> > const char *name;
> >> > } tag_name[] = {
> >> > - { BLOBLISTT_NONE, "(none)" },
> >> > + { BLOBLISTT_VOID, "(void)" },
> >> >
> >> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
> >> > + { BLOBLISTT_CONTROL_FDT, "Control FDT" },
> >> > + { BLOBLISTT_HOB_BLOCK, "HOB block" },
> >> > + { BLOBLISTT_HOB_LIST, "HOB list" },
> >> > + { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >> >
> >> > /* BLOBLISTT_AREA_FIRMWARE */
> >> > - { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >> > - { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> >> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> >> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> >> > - { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >>
> >> There are some TPM Eventlog related entries that are missing here.
> >> Can we add them?
> >>
> >> > + { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >> > +
> >> > + /* BLOBLISTT_AREA_ARM */
> >> > + { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
> >> > +
> >> > + /* BLOBLISTT_AREA_OTHER */
> >> > + { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> >> [...]
> >>
> >> Thanks
> >> /Ilias
>
Re: [PATCH v2 06/18] bloblist: Drop the flags value
Hi Ilias and Simon,
I just realized that the latest FW Handoff spec introduced 'flags'.
I will remove this patch from the series of next rev.
Regards,
Raymond
On Mon, 4 Dec 2023 at 03:40, Ilias Apalodimas
wrote:
> I just noticed that's fixed in path #12
>
>
> On Mon, 4 Dec 2023 at 10:36, Ilias Apalodimas
> wrote:
> >
> > On Mon, 27 Nov 2023 at 21:52, Raymond Mao
> wrote:
> > >
> > > From: Simon Glass
> > >
> > > There is no flags value in spec v0.9 so drop it.
> > >
> > > For now it is still present in the header, with an underscore, so that
> > > tests continue to pass.
> >
> > Why? Can't we drop it overall?
> >
> > Thanks
> > /Ilias
> >
>
> Reviewed-by: Ilias Apalodimas
>
>
> > >
> > > Signed-off-by: Simon Glass
> > > Signed-off-by: Raymond Mao
> > > ---
> > > common/bloblist.c | 5 ++---
> > > include/bloblist.h | 6 ++
> > > test/bloblist.c| 45 +++--
> > > 3 files changed, 23 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/common/bloblist.c b/common/bloblist.c
> > > index f084a32cfc..4d01772c3b 100644
> > > --- a/common/bloblist.c
> > > +++ b/common/bloblist.c
> > > @@ -331,7 +331,7 @@ static u32 bloblist_calc_chksum(struct
> bloblist_hdr *hdr)
> > > return chksum;
> > > }
> > >
> > > -int bloblist_new(ulong addr, uint size, uint flags)
> > > +int bloblist_new(ulong addr, uint size)
> > > {
> > > struct bloblist_hdr *hdr;
> > >
> > > @@ -343,7 +343,6 @@ int bloblist_new(ulong addr, uint size, uint flags)
> > > memset(hdr, '\0', sizeof(*hdr));
> > > hdr->version = BLOBLIST_VERSION;
> > > hdr->hdr_size = sizeof(*hdr);
> > > - hdr->flags = flags;
> > > hdr->magic = BLOBLIST_MAGIC;
> > > hdr->size = size;
> > > hdr->alloced = hdr->hdr_size;
> > > @@ -490,7 +489,7 @@ int bloblist_init(void)
> > > }
> > > log_debug("Creating new bloblist size %lx at %lx\n",
> size,
> > > addr);
> > > - ret = bloblist_new(addr, size, 0);
> > > + ret = bloblist_new(addr, size);
> > > } else {
> > > log_debug("Found existing bloblist size %lx at %lx\n",
> size,
> > > addr);
> > > diff --git a/include/bloblist.h b/include/bloblist.h
> > > index d70a7bad2e..2b898d0c55 100644
> > > --- a/include/bloblist.h
> > > +++ b/include/bloblist.h
> > > @@ -164,7 +164,6 @@ enum bloblist_tag_t {
> > > * @version: BLOBLIST_VERSION
> > > * @hdr_size: Size of this header, normally sizeof(struct
> bloblist_hdr). The
> > > * first bloblist_rec starts at this offset from the start of the
> header
> > > - * @flags: Space for BLOBLISTF... flags (none yet)
> > > * @size: Total size of the bloblist (non-zero if valid) including
> this header.
> > > * The bloblist extends for this many bytes from the start of
> this header.
> > > * When adding new records, the bloblist can grow up to this size.
> > > @@ -182,7 +181,7 @@ struct bloblist_hdr {
> > > u32 magic;
> > > u32 version;
> > > u32 hdr_size;
> > > - u32 flags;
> > > + u32 _flags;
> > >
> > > u32 size;
> > > u32 alloced;
> > > @@ -317,11 +316,10 @@ int bloblist_resize(uint tag, int new_size);
> > > *
> > > * @addr: Address of bloblist
> > > * @size: Initial size for bloblist
> > > - * @flags: Flags to use for bloblist
> > > * Return: 0 if OK, -EFAULT if addr is not aligned correctly, -ENOSPC
> is the
> > > * area is not large enough
> > > */
> > > -int bloblist_new(ulong addr, uint size, uint flags);
> > > +int bloblist_new(ulong addr, uint size);
> > >
> > > /**
> > > * bloblist_check() - Check if a bloblist exists
> > > diff --git a/test/bloblist.c b/test/bloblist.c
> > > index 8b435e27ca..36994c3dd4 100644
> > > --- a/test/bloblist.c
> > > +++ b/test/bloblist.c
> > > @@ -72,15 +72,15 @@ static int bloblist_test_init(struct
> unit_test_state *uts)
> > > hdr = clear_bloblist();
> > > ut_asserteq(-ENOENT, bloblist_check(TEST_ADDR,
> TEST_BLOBLIST_SIZE));
> > > ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> > > - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > > + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > > ut_asserteq_ptr(hdr, bloblist_check_magic(TEST_ADDR));
> > > hdr->version++;
> > > ut_asserteq(-EPROTONOSUPPORT, bloblist_check(TEST_ADDR,
> > >
> TEST_BLOBLIST_SIZE));
> > >
> > > - ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10, 0));
> > > - ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE, 0));
> > > - ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > > + ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10));
> > > + ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE));
> > > + ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > >
> > > ut_assert
Re: [PATCH 05/18] treewide: bootm: Drop command-line args to boot_os_fn
Hi Simon,
looks like i cannot apply this patch:
~/dev-k/u-boot-coldfire on master *2 git am
Complete-decoupling-of-bootm-logic-from-commands.patch
Applying: bootm: netbds: Drop passing of arguments
Applying: bootm: plan: Drop passing of arguments
Applying: bootm: qnxelf: Drop passing of arguments
Applying: nios2: Drop separate parsing of bootm args
Applying: treewide: bootm: Drop command-line args to boot_os_fn
error: patch failed: boot/bootm_os.c:441
error: boot/bootm_os.c: patch does not apply
Patch failed at 0005 treewide: bootm: Drop command-line args to boot_os_fn
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
And getting similar issues for the "pxe: Allow extlinux booting without
CMDLINE enabled"
Am i doing something wrong ?
Thanks,
Regards
angelo
On 04/12/23 1:26 AM, Simon Glass wrote:
These arguments are not used now. They cannot be provided when there is
no bootm command invoked to provide arguments. Drop the argc and argv
parameters.
Signed-off-by: Simon Glass
---
arch/arc/lib/bootm.c| 2 +-
arch/arm/lib/bootm.c| 3 +--
arch/m68k/lib/bootm.c | 3 +--
arch/microblaze/lib/bootm.c | 3 +--
arch/mips/lib/bootm.c | 3 +--
arch/nios2/lib/bootm.c | 3 +--
arch/powerpc/lib/bootm.c| 3 +--
arch/riscv/lib/bootm.c | 5 ++--
arch/sandbox/lib/bootm.c| 2 +-
arch/sh/lib/bootm.c | 3 +--
arch/x86/lib/bootm.c| 3 +--
arch/xtensa/lib/bootm.c | 2 +-
boot/bootm.c| 6 ++---
boot/bootm_os.c | 46 ++---
include/bootm.h | 7 +-
15 files changed, 34 insertions(+), 60 deletions(-)
diff --git a/arch/arc/lib/bootm.c b/arch/arc/lib/bootm.c
index 44ec5864a1c6..0ae7a21b24b6 100644
--- a/arch/arc/lib/bootm.c
+++ b/arch/arc/lib/bootm.c
@@ -78,7 +78,7 @@ static void boot_jump_linux(struct bootm_headers *images, int
flag)
board_jump_and_run(kernel_entry, r0, 0, r2);
}
-int do_bootm_linux(int flag, int argc, char *argv[], struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on ARC */
if ((flag & BOOTM_STATE_OS_BD_T) || (flag & BOOTM_STATE_OS_CMDLINE))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c56285738a26..ebaac029e094 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -378,8 +378,7 @@ static void boot_jump_linux(struct bootm_headers *images,
int flag)
* DIFFERENCE: Instead of calling prep and go at the end
* they are called if subcommand is equal 0.
*/
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on ARM */
if (flag & BOOTM_STATE_OS_BD_T || flag & BOOTM_STATE_OS_CMDLINE)
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c
index 79d8b34c0d56..0720861ae9cc 100644
--- a/arch/m68k/lib/bootm.c
+++ b/arch/m68k/lib/bootm.c
@@ -34,8 +34,7 @@ void arch_lmb_reserve(struct lmb *lmb)
arch_lmb_reserve_generic(lmb, get_sp(), gd->ram_top, 1024);
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
int ret;
struct bd_info *kbd;
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index f3ec4b741b88..93cdf62e18cf 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -81,8 +81,7 @@ static void boot_prep_linux(struct bootm_headers *images)
}
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
images->cmdline_start = (ulong)env_get("bootargs");
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index d6d2f7d9d031..05dbe6131728 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -300,8 +300,7 @@ static void boot_jump_linux(struct bootm_headers *images)
linux_extra);
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on MIPS */
if (flag & BOOTM_STATE_OS_BD_T)
diff --git a/arch/nios2/lib/bootm.c b/arch/nios2/lib/bootm.c
index 823d524c9a2d..040a806bc75e 100644
--- a/arch/nios2/lib/bootm.c
+++ b/arch/nios2/lib/bootm.c
@@ -16,8 +16,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define NIOS_MAGIC 0x534f494e /* enable command line and initrd passing */
-int do_bootm_linux(int flag, int argc,
Re: [PATCH v2 15/18] fdt: Allow the devicetree to come from a bloblist
Hi Simon, When `OF_BOARD` is defined, the FDT should be from one of the board-specific mechanisms: 1. FDT from a bloblist via boot args 2. FDT in memory I don't think we need a new build option to distinguish these two, since it can be done in runtime by checking whether the boot args follow the FW Handoff spec conventions and the FDT exists in the bloblist. If it fulfills the above conditions, we can take the FDT from bloblist, otherwise from the predefined memory address. This is fully backward compatible without adding a new build option. Regards, Raymond On Sat, 2 Dec 2023 at 13:32, Simon Glass wrote: > Hi Raymond, > > On Mon, 27 Nov 2023 at 12:53, Raymond Mao wrote: > > > > From: Simon Glass > > > > Standard passage provides for a bloblist to be passed from one firmware > > phase to the next. That can be used to pass the devicetree along as well. > > If CONFIG_OF_BOARD is defined, a board custom routine will provide a > > bloblist or a specified memory address to retrieve the devicetree at > > runtime. > > A devicetree from a bloblist is prioritized than the one from specified > > memory region. > > > > Tests for this will be added as part of the Universal Payload work. > > > > Signed-off-by: Simon Glass > > Co-developed-by: Raymond Mao > > Signed-off-by: Raymond Mao > > --- > > Changes in v2 > > - New patch file created for v2. > > Amended from the original patch > > "[v2,30/32] fdt: Allow the devicetree to come from a bloblist". > > Remove CONFIG_OF_BLOBLIST and FDTSRC_BLOBLIST, a DTB from a previous > > loader is defined by CONFIG_OF_BOARD. The DTB can be located either in > the > > bloblist or from a specified memory address. > > > > doc/develop/devicetree/control.rst | 8 +++-- > > dts/Kconfig| 9 -- > > include/fdtdec.h | 3 +- > > lib/fdtdec.c | 52 +++--- > > 4 files changed, 53 insertions(+), 19 deletions(-) > > This is a bit mangled. I spoke to Ilias about this as osfc and thought > we had it figured out, but it was a bit rushed so perhaps not. > > OF_BOARD refers to a board-specific mechanism > > We should have OF_BLOBLIST to reference to this, a standard mechanism > and not board-specific. > > Ideally all boards should use a bloblist to send their DT to U-Boot. > E.g. Raspberry Pi. > > So I believe my original patch was closer to what we want. > > Regards, > SImon >
Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE
On 15:59-20231201, Dhruva Gole wrote: > Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot > requirement for this SoC > > Signed-off-by: Dhruva Gole > --- > doc/board/beagle/am62x_beagleplay.rst | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/doc/board/beagle/am62x_beagleplay.rst > b/doc/board/beagle/am62x_beagleplay.rst > index 7784e62b0b71..50d7d3c620d7 100644 > --- a/doc/board/beagle/am62x_beagleplay.rst > +++ b/doc/board/beagle/am62x_beagleplay.rst > @@ -63,7 +63,6 @@ Set the variables corresponding to this platform: ># we dont use any extra TFA parameters >unset TFA_EXTRA_ARGS >export OPTEE_PLATFORM=k3-am62x > - export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" > > .. include:: ../ti/am62x_sk.rst > :start-after: .. am62x_evm_rst_include_start_build_steps > -- > 2.34.1 > NAK. RNG is needed to seed standard distros. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/2] docs: AM62x: Remove SW_PRNG Flag for OPTEE
On 15:59-20231201, Dhruva Gole wrote: > The CFG_WITH_SOFTWARE_PRNG option was needed once when there were some > issues with system crashes/ hangs after a suspend-resume cycle. However > this seems to no longer be the case with newer firmwares, and this > config is not needed for basic boot support of the SoC either, hence > remove it from the docs. > > Cc: Kamlesh > Cc: Vibhore Vardhan > Cc: Wadim Egorov > > Dhruva Gole (2): > doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE > doc: board: ti: am62x_sk: Remove SW_PRNG Flag for OPTEE > > doc/board/beagle/am62x_beagleplay.rst | 1 - > doc/board/ti/am62x_sk.rst | 1 - > 2 files changed, 2 deletions(-) > NAK to the series. RNG seed is needed for KASLR. either enable h/w RNG or at least enable S/W RNG in OPTEE. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v1] mtd: rawnand: Meson NAND controller support
cc: Miquel Raynal On 30.11.2023 14:21, Arseniy Krasnov wrote: > Basic support for Amlogic Meson NAND controller on AXG. > > Signed-off-by: Arseniy Krasnov > --- > drivers/mtd/nand/raw/Kconfig |9 + > drivers/mtd/nand/raw/Makefile |1 + > drivers/mtd/nand/raw/meson_nand.c | 1231 + > 3 files changed, 1241 insertions(+) > create mode 100644 drivers/mtd/nand/raw/meson_nand.c > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index d624589a89..7b7b0226ab 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -488,6 +488,15 @@ config NAND_ARASAN > controller. This uses the hardware ECC for read and > write operations. > > +config NAND_MESON > + bool "Meson NAND support" > + select SYS_NAND_SELF_INIT > + depends on DM_MTD && ARCH_MESON > + imply CMD_NAND > + help > + This enables Nand driver support for Meson raw NAND flash > + controller. > + > config NAND_MXC > bool "MXC NAND support" > depends on CPU_ARM926EJS || CPU_ARM1136 || MX5 > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > index add2b4cf65..5b4efd52c9 100644 > --- a/drivers/mtd/nand/raw/Makefile > +++ b/drivers/mtd/nand/raw/Makefile > @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o > obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o > obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o > obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o > +obj-$(CONFIG_NAND_MESON) += meson_nand.o > obj-$(CONFIG_NAND_MXC) += mxc_nand.o > obj-$(CONFIG_NAND_MXS) += mxs_nand.o > obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o > diff --git a/drivers/mtd/nand/raw/meson_nand.c > b/drivers/mtd/nand/raw/meson_nand.c > new file mode 100644 > index 00..f1d49887ee > --- /dev/null > +++ b/drivers/mtd/nand/raw/meson_nand.c > @@ -0,0 +1,1231 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Amlogic Meson Nand Flash Controller Driver > + * > + * Copyright (c) 2023 SaluteDevices, Inc. > + * Author: Arseniy Krasnov > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NFC_CMD_IDLE (0xc << 14) > +#define NFC_CMD_CLE (0x5 << 14) > +#define NFC_CMD_ALE (0x6 << 14) > +#define NFC_CMD_DWR (0x4 << 14) > +#define NFC_CMD_DRD (0x8 << 14) > +#define NFC_CMD_ADL ((0 << 16) | (3 << 20)) > +#define NFC_CMD_ADH ((1 << 16) | (3 << 20)) > +#define NFC_CMD_AIL ((2 << 16) | (3 << 20)) > +#define NFC_CMD_AIH ((3 << 16) | (3 << 20)) > +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) > +#define NFC_CMD_M2N ((0 << 17) | (2 << 20)) > +#define NFC_CMD_N2M ((1 << 17) | (2 << 20)) > +#define NFC_CMD_RB BIT(20) > +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19) > +#define NFC_CMD_SCRAMBLER_DISABLE0 > +#define NFC_CMD_SHORTMODE_DISABLE0 > +#define NFC_CMD_RB_INT BIT(14) > +#define NFC_CMD_RB_INT_NO_PIN((0xb << 10) | BIT(18) | > BIT(16)) > + > +#define NFC_CMD_GET_SIZE(x) (((x) >> 22) & GENMASK(4, 0)) > + > +#define NFC_REG_CMD 0x00 > +#define NFC_REG_CFG 0x04 > +#define NFC_REG_DADR 0x08 > +#define NFC_REG_IADR 0x0c > +#define NFC_REG_BUF 0x10 > +#define NFC_REG_INFO 0x14 > +#define NFC_REG_DC 0x18 > +#define NFC_REG_ADR 0x1c > +#define NFC_REG_DL 0x20 > +#define NFC_REG_DH 0x24 > +#define NFC_REG_CADR 0x28 > +#define NFC_REG_SADR 0x2c > +#define NFC_REG_PINS 0x30 > +#define NFC_REG_VER 0x38 > + > +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\ > + ( \ > + (cmd_dir) | \ > + ((ran) << 19) | \ > + ((bch) << 14) | \ > + ((short_mode) << 13)| \ > + (((page_size) & 0x7f) << 6) | \ > + ((pages) & 0x3f)\ > + ) > + > +#define GENCMDDADDRL(adl, addr) ((adl) | ((addr) & 0x)) > +#define GENCMDDADDRH(adh, addr) ((adh) | (((addr) >> 16) & > 0x)) > +#define GENCMDIADDRL(ail, addr) ((ail) | ((addr) & 0x)) > +#define GENCMDIADDRH(aih, addr) ((aih) | (((addr) >> 16) & > 0x)) > + > +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) > + > +#define ECC_CHECK_RETURN_FF -1 > + > +#define NA
Re: [PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
cc: Miquel Raynal
On 30.11.2023 14:24, Arseniy Krasnov wrote:
> Support for OTP area access on MX30LFxG18AC chip series.
>
> Signed-off-by: Arseniy Krasnov
> ---
> drivers/mtd/nand/raw/nand_macronix.c | 170 +++
> 1 file changed, 170 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_macronix.c
> b/drivers/mtd/nand/raw/nand_macronix.c
> index dc972e5909..4c6ddd9233 100644
> --- a/drivers/mtd/nand/raw/nand_macronix.c
> +++ b/drivers/mtd/nand/raw/nand_macronix.c
> @@ -16,13 +16,183 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
>
> +#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
> +#define MACRONIX_30LFXG18AC_OTP_START_PAGE 2
> +#define MACRONIX_30LFXG18AC_OTP_PAGES30
> +#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE2112
> +#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES \
> + (MACRONIX_30LFXG18AC_OTP_PAGES *\
> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> +
> +#define MACRONIX_30LFXG18AC_OTP_EN BIT(0)
> +
> +static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t len,
> + size_t *retlen,
> + struct otp_info *buf)
> +{
> + if (len < sizeof(*buf))
> + return -EINVAL;
> +
> + /* Always report that OTP is unlocked. Reason is that this
> + * type of flash chip doesn't provide way to check that OTP
> + * is locked or not: subfeature parameter is implemented as
> + * volatile register. Technically OTP region could be locked
> + * and become readonly, but as there is no way to check it,
> + * don't allow to lock it ('_lock_user_prot_reg' callback
> + * always returns -EOPNOTSUPP) and thus we report that OTP
> + * is unlocked.
> + */
> + buf->locked = 0;
> + buf->start = 0;
> + buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
> +
> + *retlen = sizeof(*buf);
> +
> + return 0;
> +}
> +
> +static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
> +{
> + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> + struct mtd_info *mtd;
> +
> + mtd = nand_to_mtd(nand);
> + feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
> +
> + return nand->onfi_set_features(mtd, nand,
> ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf);
> +}
> +
> +static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand)
> +{
> + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> + struct mtd_info *mtd;
> +
> + mtd = nand_to_mtd(nand);
> + return nand->onfi_set_features(mtd, nand,
> ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf);
> +}
> +
> +static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd,
> + loff_t offs_in_flash,
> + size_t len, size_t *retlen,
> + u_char *buf, bool write)
> +{
> + struct nand_chip *nand;
> + size_t bytes_handled;
> + off_t offs_in_page;
> + u64 page;
> + int ret;
> +
> + nand = mtd_to_nand(mtd);
> + nand->select_chip(mtd, 0);
> +
> + ret = macronix_30lfxg18ac_otp_enable(nand);
> + if (ret)
> + goto out_otp;
> +
> + page = offs_in_flash;
> + /* 'page' will be result of division. */
> + offs_in_page = do_div(page, MACRONIX_30LFXG18AC_OTP_PAGE_SIZE);
> + bytes_handled = 0;
> +
> + while (bytes_handled < len &&
> +page < MACRONIX_30LFXG18AC_OTP_PAGES) {
> + size_t bytes_to_handle;
> + u64 phys_page = page + MACRONIX_30LFXG18AC_OTP_START_PAGE;
> +
> + bytes_to_handle = min_t(size_t, len - bytes_handled,
> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE -
> + offs_in_page);
> +
> + if (write)
> + ret = nand_prog_page_op(nand, phys_page, offs_in_page,
> + &buf[bytes_handled],
> bytes_to_handle);
> + else
> + ret = nand_read_page_op(nand, phys_page, offs_in_page,
> + &buf[bytes_handled],
> bytes_to_handle);
> + if (ret)
> + goto out_otp;
> +
> + bytes_handled += bytes_to_handle;
> + offs_in_page = 0;
> + page++;
> + }
> +
> + *retlen = bytes_handled;
> +
> +out_otp:
> + if (ret)
> + dev_err(mtd->dev, "failed to perform OTP IO: %i\n", ret);
> +
> + ret = macronix_30lfxg18ac_otp_disable(nand);
> + if (ret)
> + dev_err(mtd->dev, "failed to leave OTP mode after %s\n",
> + write ? "write" : "read");
> +
> + nand->select_chip(mtd, -1);
> +
> + return ret;
> +}
> +
> +static int macronix_30lfxg18ac_write_otp(struct mtd_info *mtd, loff_t to,
> + size_t len, size_t *rlen,
> +
