[PATCH v4 0/7] Add SE HMBSC board support
SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major difference from db410c is serial port where HMIBSC board uses UART1 as the debug console with an RS232 port, patch #2 - #5 adds corresponding driver support. Patch #6 adds main HMIBSC board specific bits, features: - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306) - 2GiB RAM - 64GiB eMMC, SD slot - WiFi and Bluetooth - 2x Host, 1x Device USB port - HDMI - Discrete TPM2 chip over SPI Features enabled in U-Boot: - RAUC updates (refer [2] for more details) - Environment protection - USB based ethernet adaptors Feedback is very much welcome. Changes in v4: - Rebased on top of qcom-main [4]. - Split out board DTS patch as #6. - Convert to text based environment as hmibsc.env. - MMC regression has been reported for qcom-main branch here [5]. - Collected further review tag. Changes in v3: - Rebased on top of qcom-next [1]. - Collected some review tags. - Incorporated misc. comments from Caleb and Stephen. - Split patch#4 as requested. - Linux HMIBSC board DTS has already been reviewed here [3], I have incorporated that for U-Boot too. Changes in v2: - Rebased on top on qcom-next [1]. - Added patch#1 as a fix for generic qcom board support. - Added patch#4 to enable driving GPIO pins based on pinctrl configuration. This replaces the custom GPIO configuration. - Added proper DTS file for HMIBSC board based on Linux DT pattern. - Merged board support patches into a single patch#5. [1] https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads [2] https://rauc.readthedocs.io/en/latest/ [3] https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/ [4] https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-main/?ref_type=heads [5] https://lore.kernel.org/all/cafa6wyo+3vroudfuvh390taviqx8pmqroqdtsn0yu6bd5yy...@mail.gmail.com/ Sumit Garg (7): qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default apq8016: Add support for UART1 clocks and pinmux serial_msm: Enable RS232 flow control pinctrl: qcom: Add support for driving GPIO pins output pinctrl: qcom: apq8016: Add GPIO pinctrl function arm: dts: qcom: Add Schneider HMIBSC board dts board: add support for Schneider HMIBSC board arch/arm/Kconfig | 2 +- arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++ board/schneider/hmibsc/MAINTAINERS| 6 + board/schneider/hmibsc/hmibsc.env | 40 ++ configs/hmibsc_defconfig | 87 doc/board/index.rst | 1 + doc/board/schneider/hmibsc.rst| 45 ++ doc/board/schneider/index.rst | 9 + drivers/clk/qcom/clock-apq8016.c | 38 +- drivers/pinctrl/qcom/pinctrl-apq8016.c| 2 + drivers/pinctrl/qcom/pinctrl-qcom.c | 25 +- drivers/serial/serial_msm.c | 24 +- include/configs/hmibsc.h | 16 + 13 files changed, 760 insertions(+), 26 deletions(-) create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts create mode 100644 board/schneider/hmibsc/MAINTAINERS create mode 100644 board/schneider/hmibsc/hmibsc.env create mode 100644 configs/hmibsc_defconfig create mode 100644 doc/board/schneider/hmibsc.rst create mode 100644 doc/board/schneider/index.rst create mode 100644 include/configs/hmibsc.h -- 2.34.1
Re: [PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5
On Fri, 12 Apr 2024 at 14:06, Neil Armstrong wrote:
>
> On 11/04/2024 15:59, Sumit Garg wrote:
> > On Tue, 9 Apr 2024 at 23:33, Caleb Connolly
> > wrote:
> >>
> >> The V4 and V5 controllers have quite varied register layouts. Inherit
> >> the register offsets and naming from the Linux driver. More version
> >> specific offsets can be inherited from Linux as needed.
> >>
> >> Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
> >> Signed-off-by: Caleb Connolly
> >> ---
> >> drivers/mmc/msm_sdhci.c | 11 +++
> >> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>
> >
> > This patch broke booting on the HMIBSC board, have you tested it on
> > db410c? It's very likely that this has caused regression there too.
> >
> > Error observed:
> >
> > sdhci_send_command: Timeout for status update: 0001
>
> Indeed swapping the core_vendor_spec_capabilities0 between msm_sdhc_v5_var &
> msm_sdhc_mci_var
> fixes this and I'm now able to enable SDCard on the SM8550-HDK
Yeah this fixed the problem for me too. I am unsure how it worked for
Caleb on db845c.
Caleb,
Can you fix up this patch which is already in your tree already?
-Sumit
>
> Neil
>
> >
> > -Sumit
> >
> >> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> >> index 059cb3da77c5..f23d425144ef 100644
> >> --- a/drivers/mmc/msm_sdhci.c
> >> +++ b/drivers/mmc/msm_sdhci.c
> >> @@ -32,11 +32,8 @@
> >> #define SDCC_MCI_STATUS2 0x6C
> >> #define SDCC_MCI_STATUS2_MCI_ACT 0x1
> >> #define SDCC_MCI_HC_MODE 0x78
> >>
> >> -/* Non standard (?) SDHCI register */
> >> -#define SDHCI_VENDOR_SPEC_CAPABILITIES0 0x11c
> >> -
> >> struct msm_sdhc_plat {
> >> struct mmc_config cfg;
> >> struct mmc mmc;
> >> };
> >> @@ -48,8 +45,10 @@ struct msm_sdhc {
> >> };
> >>
> >> struct msm_sdhc_variant_info {
> >> bool mci_removed;
> >> +
> >> + u32 core_vendor_spec_capabilities0;
> >> };
> >>
> >> DECLARE_GLOBAL_DATA_PTR;
> >>
> >> @@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
> >> */
> >> if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
> >> caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
> >> caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
> >> - writel(caps, host->ioaddr +
> >> SDHCI_VENDOR_SPEC_CAPABILITIES0);
> >> + writel(caps, host->ioaddr +
> >> var_info->core_vendor_spec_capabilities0);
> >> }
> >>
> >> ret = mmc_of_parse(dev, >cfg);
> >> if (ret)
> >> @@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
> >> }
> >>
> >> static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
> >> .mci_removed = false,
> >> +
> >> + .core_vendor_spec_capabilities0 = 0x21c,
> >> };
> >>
> >> static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
> >> .mci_removed = true,
> >> +
> >> + .core_vendor_spec_capabilities0 = 0x11c,
> >> };
> >>
> >> static const struct udevice_id msm_mmc_ids[] = {
> >> { .compatible = "qcom,sdhci-msm-v4", .data =
> >> (ulong)_sdhc_mci_var },
> >>
> >> --
> >> 2.44.0
> >>
>
[PATCH v4 1/7] qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default
Enabling LINUX_KERNEL_IMAGE_HEADER by default doesn't allow
ENABLE_ARM_SOC_BOOT0_HOOK to work properly on db410c when U-Boot is
loaded as a first stage bootloader. It leads to secondary CPUs bringup
failure and later causing the Linux kernel to freeze.
So fix it via selectively enabling LINUX_KERNEL_IMAGE_HEADER where it's
actually required.
Fixes: 059d526af312 ("mach-snapdragon: generalise board support")
Reviewed-by: Caleb Connolly
Signed-off-by: Sumit Garg
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 23ee25269a2..1d451c46d32 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1088,7 +1088,7 @@ config ARCH_SNAPDRAGON
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
- select LINUX_KERNEL_IMAGE_HEADER
+ select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
imply CMD_DM
config ARCH_SOCFPGA
--
2.34.1
[PATCH v4 6/7] arm: dts: qcom: Add Schneider HMIBSC board dts
Schneider HMIBSC board dts has already been reviewed upstream on the
linux-arm-msm mailing list. So once it comes through the Linux kernel
release cycle into the U-Boot dts/upstream subtree, a switch to
OF_UPSTREAM can be made. For the time being maintain the U-Boot copy.
Link:
https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/
Signed-off-by: Sumit Garg
---
arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
1 file changed, 491 insertions(+)
create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
diff --git a/arch/arm/dts/apq8016-schneider-hmibsc.dts
b/arch/arm/dts/apq8016-schneider-hmibsc.dts
new file mode 100644
index 000..75c6137e5a1
--- /dev/null
+++ b/arch/arm/dts/apq8016-schneider-hmibsc.dts
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+#include
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ model = "Schneider Electric HMIBSC Board";
+ compatible = "schneider,apq8016-hmibsc", "qcom,apq8016";
+
+ aliases {
+ i2c1 = _i2c6;
+ i2c3 = _i2c4;
+ i2c4 = _i2c3;
+ mmc0 = _1; /* eMMC */
+ mmc1 = _2; /* SD card */
+ serial0 = _uart1;
+ serial1 = _uart2;
+ spi0 = _spi5;
+ usid0 = _0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-0 = <_key_volp_n_default>;
+ pinctrl-names = "default";
+
+ button {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = < 107 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_mpps_leds>;
+ pinctrl-names = "default";
+
+ led-1 {
+ function = LED_FUNCTION_WLAN;
+ color = ;
+ gpios = <_mpps 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ default-state = "off";
+ };
+
+ led-2 {
+ function = LED_FUNCTION_BLUETOOTH;
+ color = ;
+ gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "bluetooth-power";
+ default-state = "off";
+ };
+ };
+
+ memory@8000 {
+ reg = <0 0x8000 0 0x4000>;
+ };
+
+ reserved-memory {
+ ramoops@bff0 {
+ compatible = "ramoops";
+ reg = <0x0 0xbff0 0x0 0x10>;
+ record-size = <0x2>;
+ console-size = <0x2>;
+ ftrace-size = <0x2>;
+ ecc-size = <16>;
+ };
+ };
+
+ usb-hub {
+ compatible = "smsc,usb3503";
+ reset-gpios = <_gpios 1 GPIO_ACTIVE_LOW>;
+ initial-mode = <1>;
+ };
+
+ usb_id: usb-id {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = < 110 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_id_default>;
+ pinctrl-names = "default";
+ };
+};
+
+_i2c3 {
+ status = "okay";
+
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+};
+
+_i2c4 {
+ status = "okay";
+
+ adv_bridge: bridge@39 {
+ compatible = "adi,adv7533";
+ reg = <0x39>;
+ interrupts-extended = < 31 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,dsi-lanes = <4>;
+ clocks = < RPM_SMD_BB_CLK2>;
+ clock-names = "cec";
+ pd-gpios = < 32 GPIO_ACTIVE_HIGH>;
+
+ avdd-supply = <_l6>;
+ a2vdd-supply = <_l6>;
+ dvdd-supply = <_l6>;
+ pvdd-supply = <_l6>;
+ v1p2-supply = <_l6>;
+ v3p3-supply = <_l17>;
+
+ pinctrl-0 = <_int_active _switch_active>;
+ pinctrl-1 = <_int_suspend _switch_suspend>;
+ pinctrl-names = "default","sleep";
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+
[PATCH v4 2/7] apq8016: Add support for UART1 clocks and pinmux
SE HMIBSC board uses UART1 as the main debug console, so add
corresponding clocks and pinmux support. Along with that update
instructions to enable clocks for debug UART support.
Reviewed-by: Caleb Connolly
Signed-off-by: Sumit Garg
---
drivers/clk/qcom/clock-apq8016.c | 38 ++
drivers/pinctrl/qcom/pinctrl-apq8016.c | 1 +
drivers/serial/serial_msm.c| 11 ++--
3 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index 5a5868169c8..9556b94774a 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -31,7 +31,8 @@
#define BLSP1_AHB_CBCR 0x1008
/* Uart clock control registers */
-#define BLSP1_UART2_BCR(0x3028)
+#define BLSP1_UART1_APPS_CBCR (0x203C)
+#define BLSP1_UART1_APPS_CMD_RCGR (0x2044)
#define BLSP1_UART2_APPS_CBCR (0x302C)
#define BLSP1_UART2_APPS_CMD_RCGR (0x3034)
@@ -52,7 +53,7 @@ static struct vote_clk gcc_blsp1_ahb_clk = {
};
/* SDHCI */
-static int clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
+static int apq8016_clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
{
int div = 15; /* 100MHz default */
@@ -70,20 +71,35 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int
slot, uint rate)
}
/* UART: 115200 */
-int apq8016_clk_init_uart(phys_addr_t base)
+int apq8016_clk_init_uart(phys_addr_t base, unsigned long id)
{
+ u32 cmd_rcgr, apps_cbcr;
+
+ switch (id) {
+ case GCC_BLSP1_UART1_APPS_CLK:
+ cmd_rcgr = BLSP1_UART1_APPS_CMD_RCGR;
+ apps_cbcr = BLSP1_UART1_APPS_CBCR;
+ break;
+ case GCC_BLSP1_UART2_APPS_CLK:
+ cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR;
+ apps_cbcr = BLSP1_UART2_APPS_CBCR;
+ break;
+ default:
+ return 0;
+ }
+
/* Enable AHB clock */
clk_enable_vote_clk(base, _blsp1_ahb_clk);
/* 7372800 uart block clock @ GPLL0 */
- clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
-CFG_CLK_SRC_GPLL0, 16);
+ clk_rcg_set_rate_mnd(base, cmd_rcgr, 1, 144, 15625, CFG_CLK_SRC_GPLL0,
+16);
/* Vote for gpll0 clock */
clk_enable_gpll0(base, _vote_clk);
/* Enable core clk */
- clk_enable_cbc(base + BLSP1_UART2_APPS_CBCR);
+ clk_enable_cbc(base + apps_cbcr);
return 0;
}
@@ -94,14 +110,12 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong
rate)
switch (clk->id) {
case GCC_SDCC1_APPS_CLK: /* SDC1 */
- return clk_init_sdc(priv, 0, rate);
- break;
+ return apq8016_clk_init_sdc(priv, 0, rate);
case GCC_SDCC2_APPS_CLK: /* SDC2 */
- return clk_init_sdc(priv, 1, rate);
- break;
+ return apq8016_clk_init_sdc(priv, 1, rate);
+ case GCC_BLSP1_UART1_APPS_CLK: /* UART1 */
case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
- return apq8016_clk_init_uart(priv->base);
- break;
+ return apq8016_clk_init_uart(priv->base, clk->id);
default:
return 0;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index a9a00f4b081..1ee8b7db1a2 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
};
static const struct pinctrl_function msm_pinctrl_functions[] = {
+ {"blsp_uart1", 2},
{"blsp_uart2", 2},
};
diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index ac4280c6c4c..4de10e75191 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -248,12 +248,17 @@ static struct msm_serial_data init_serial_data = {
#include
/* Uncomment to turn on UART clocks when debugging U-Boot as aboot on MSM8916
*/
-//int apq8016_clk_init_uart(phys_addr_t gcc_base);
+//int apq8016_clk_init_uart(phys_addr_t gcc_base, unsigned long id);
static inline void _debug_uart_init(void)
{
- /* Uncomment to turn on UART clocks when debugging U-Boot as aboot on
MSM8916 */
- //apq8016_clk_init_uart(0x180);
+ /*
+* Uncomment to turn on UART clocks when debugging U-Boot as aboot
+* on MSM8916. Supported debug UART clock IDs:
+* - db410c: GCC_BLSP1_UART2_APPS_CLK
+* - HMIBSC: GCC_BLSP1_UART1_APPS_CLK
+*/
+ //apq8016_clk_init_uart(0x180, );
uart_dm_init(_serial_data);
}
--
2.34.1
[PATCH v4 3/7] serial_msm: Enable RS232 flow control
SE HMIBSC board debug console requires RS232 flow control, so enable corresponding support if RS232 gpios are present. Reviewed-by: Caleb Connolly Signed-off-by: Sumit Garg --- drivers/serial/serial_msm.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c index 4de10e75191..3142ecf7362 100644 --- a/drivers/serial/serial_msm.c +++ b/drivers/serial/serial_msm.c @@ -53,10 +53,11 @@ #define UARTDM_TF 0x100 /* UART Transmit FIFO register */ #define UARTDM_RF 0x140 /* UART Receive FIFO register */ -#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC -#define MSM_BOOT_UART_DM_8_N_1_MODE 0x34 -#define MSM_BOOT_UART_DM_CMD_RESET_RX 0x10 -#define MSM_BOOT_UART_DM_CMD_RESET_TX 0x20 +#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC +#define MSM_BOOT_UART_DM_8_N_1_MODE0x34 +#define MSM_BOOT_UART_DM_CMD_RESET_RX 0x10 +#define MSM_BOOT_UART_DM_CMD_RESET_TX 0x20 +#define MSM_UART_MR1_RX_RDY_CTLBIT(7) DECLARE_GLOBAL_DATA_PTR; @@ -182,7 +183,9 @@ static void uart_dm_init(struct msm_serial_data *priv) mdelay(5); writel(priv->clk_bit_rate, priv->base + UARTDM_CSR); - writel(0x0, priv->base + UARTDM_MR1); + + /* Enable RS232 flow control to support RS232 db9 connector */ + writel(MSM_UART_MR1_RX_RDY_CTL, priv->base + UARTDM_MR1); writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2); writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR); writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR); -- 2.34.1
[PATCH v4 4/7] pinctrl: qcom: Add support for driving GPIO pins output
Add support for driving the GPIO pins as output low or high.
Signed-off-by: Sumit Garg
---
drivers/pinctrl/qcom/pinctrl-qcom.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index 909e566acf5..e68971b37ff 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -29,15 +29,24 @@ struct msm_pinctrl_priv {
#define GPIO_CONFIG_REG(priv, x) \
(qcom_pin_offset((priv)->data->pin_data.pin_offsets, x))
-#define TLMM_GPIO_PULL_MASK GENMASK(1, 0)
-#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
-#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
-#define TLMM_GPIO_DISABLE BIT(9)
+#define GPIO_IN_OUT_REG(priv, x) \
+ (GPIO_CONFIG_REG(priv, x) + 0x4)
+
+#define TLMM_GPIO_PULL_MASKGENMASK(1, 0)
+#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
+#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
+#define TLMM_GPIO_OUTPUT_MASK BIT(1)
+#define TLMM_GPIO_OE_MASK BIT(9)
+
+/* GPIO register shifts. */
+#define GPIO_OUT_SHIFT 1
static const struct pinconf_param msm_conf_params[] = {
{ "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 2 },
{ "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 3 },
+ { "output-high", PIN_CONFIG_OUTPUT, 1, },
+ { "output-low", PIN_CONFIG_OUTPUT, 0, },
};
static int msm_get_functions_count(struct udevice *dev)
@@ -90,7 +99,7 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int
pin_selector,
return 0;
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
- TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
+ TLMM_FUNC_SEL_MASK | TLMM_GPIO_OE_MASK, func << 2);
return 0;
}
@@ -117,6 +126,12 @@ static int msm_pinconf_set(struct udevice *dev, unsigned
int pin_selector,
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv,
pin_selector),
TLMM_GPIO_PULL_MASK, argument);
break;
+ case PIN_CONFIG_OUTPUT:
+ writel(argument << GPIO_OUT_SHIFT,
+ priv->base + GPIO_IN_OUT_REG(priv, pin_selector));
+ setbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
+TLMM_GPIO_OE_MASK);
+ break;
default:
return 0;
}
--
2.34.1
[PATCH v4 5/7] pinctrl: qcom: apq8016: Add GPIO pinctrl function
Add GPIO pinctrl function to enable driving GPIO pins as output low or
high.
Signed-off-by: Sumit Garg
---
drivers/pinctrl/qcom/pinctrl-apq8016.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index 1ee8b7db1a2..b14a8921af4 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
};
static const struct pinctrl_function msm_pinctrl_functions[] = {
+ {"gpio", 0},
{"blsp_uart1", 2},
{"blsp_uart2", 2},
};
--
2.34.1
Re: [PATCH v2 02/16] board: am64x: Define capsule update firmware info
Hi Tom >From a capsule update POV the patch looks correct Acked-by: Ilias Apalodimas On Wed, 10 Apr 2024 at 02:44, Tom Rini wrote: > > On Tue, Apr 09, 2024 at 06:31:02AM +0200, Heinrich Schuchardt wrote: > > On 4/9/24 00:31, Jonathan Humphreys wrote: > [snip] > > The series has been assigned to me in Patchwork. > > > > But changes should be tested and reviewed by the respective board > > maintainers (Vignesh, Tom for AM64x) as I have no access to TI boards. > > I'll pick it up once you're happy with the capsule side of things if you > like, but in my mind it's more important to emphasize that this is what > capsule support looks like as it rolls out to more platforms, is > everyone happy with this? > > -- > Tom
Re: [PATCH v5 2/5] serial: lpuart: use ipg clk for i.MX7ULP
Hi Peng,
On Thu, Apr 11, 2024 at 12:23 AM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> To i.MX7ULP compatible lpuart, there is only ipg clk, no per clk.
> So add a devtype check for i.MX7ULP.
>
> Signed-off-by: Peng Fan
> ---
> drivers/serial/serial_lpuart.c | 28 +++-
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
> index ce08a6b4486..891352293f9 100644
> --- a/drivers/serial/serial_lpuart.c
> +++ b/drivers/serial/serial_lpuart.c
> @@ -111,11 +111,18 @@ u32 __weak get_lpuart_clk(void)
> #if CONFIG_IS_ENABLED(CLK)
> static int get_lpuart_clk_rate(struct udevice *dev, u32 *clk)
> {
> + struct lpuart_serial_plat *plat = dev_get_plat(dev);
> struct clk per_clk;
You ignored my previous comment. Here I go again:
Please rename 'per_clk' to 'clk'.
> ulong rate;
> int ret;
> + char *name;
> +
> + if (plat->devtype == DEV_MX7ULP)
> + name = "ipg";
> + else
> + name = "per";
>
> - ret = clk_get_by_name(dev, "per", _clk);
> + ret = clk_get_by_name(dev, name, _clk);
... because it is confusing that per_clk can be ipg or per clock.
> if (ret) {
> dev_err(dev, "Failed to get per clk: %d\n", ret);
And then also change the error message to "clk".
Re: [PATCH] usb: dwc3: support USB 3.1 controllers
On 11/04/2024 18:05, Caleb Connolly wrote:
The revision is different for these, add the additional check as in
xhci-dwc3 core_init code.
Signed-off-by: Caleb Connolly
---
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 96e850b7170f..db045f5822d4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -594,9 +594,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
int ret;
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
/* This should read as U3 followed by revision number */
- if ((reg & DWC3_GSNPSID_MASK) != 0x5533) {
+ if ((reg & DWC3_GSNPSID_MASK) != 0x5533 &&
+ (reg & DWC3_GSNPSID_MASK) != 0x3331) {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
ret = -ENODEV;
goto err0;
}
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong # on SM8550
Re: [PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5
On 11/04/2024 15:59, Sumit Garg wrote:
On Tue, 9 Apr 2024 at 23:33, Caleb Connolly wrote:
The V4 and V5 controllers have quite varied register layouts. Inherit
the register offsets and naming from the Linux driver. More version
specific offsets can be inherited from Linux as needed.
Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
This patch broke booting on the HMIBSC board, have you tested it on
db410c? It's very likely that this has caused regression there too.
Error observed:
sdhci_send_command: Timeout for status update: 0001
Indeed swapping the core_vendor_spec_capabilities0 between msm_sdhc_v5_var &
msm_sdhc_mci_var
fixes this and I'm now able to enable SDCard on the SM8550-HDK
Neil
-Sumit
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 059cb3da77c5..f23d425144ef 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -32,11 +32,8 @@
#define SDCC_MCI_STATUS2 0x6C
#define SDCC_MCI_STATUS2_MCI_ACT 0x1
#define SDCC_MCI_HC_MODE 0x78
-/* Non standard (?) SDHCI register */
-#define SDHCI_VENDOR_SPEC_CAPABILITIES0 0x11c
-
struct msm_sdhc_plat {
struct mmc_config cfg;
struct mmc mmc;
};
@@ -48,8 +45,10 @@ struct msm_sdhc {
};
struct msm_sdhc_variant_info {
bool mci_removed;
+
+ u32 core_vendor_spec_capabilities0;
};
DECLARE_GLOBAL_DATA_PTR;
@@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
*/
if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
- writel(caps, host->ioaddr + SDHCI_VENDOR_SPEC_CAPABILITIES0);
+ writel(caps, host->ioaddr +
var_info->core_vendor_spec_capabilities0);
}
ret = mmc_of_parse(dev, >cfg);
if (ret)
@@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
}
static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
.mci_removed = false,
+
+ .core_vendor_spec_capabilities0 = 0x21c,
};
static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
.mci_removed = true,
+
+ .core_vendor_spec_capabilities0 = 0x11c,
};
static const struct udevice_id msm_mmc_ids[] = {
{ .compatible = "qcom,sdhci-msm-v4", .data = (ulong)_sdhc_mci_var
},
--
2.44.0
[PATCH v4 7/7] board: add support for Schneider HMIBSC board
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI
Features enabled in U-Boot:
- RAUC updates
- Environment protection
- USB based ethernet adaptors
Signed-off-by: Sumit Garg
---
board/schneider/hmibsc/MAINTAINERS | 6 +++
board/schneider/hmibsc/hmibsc.env | 40 ++
configs/hmibsc_defconfig | 87 ++
doc/board/index.rst| 1 +
doc/board/schneider/hmibsc.rst | 45
doc/board/schneider/index.rst | 9
include/configs/hmibsc.h | 16 ++
7 files changed, 204 insertions(+)
create mode 100644 board/schneider/hmibsc/MAINTAINERS
create mode 100644 board/schneider/hmibsc/hmibsc.env
create mode 100644 configs/hmibsc_defconfig
create mode 100644 doc/board/schneider/hmibsc.rst
create mode 100644 doc/board/schneider/index.rst
create mode 100644 include/configs/hmibsc.h
diff --git a/board/schneider/hmibsc/MAINTAINERS
b/board/schneider/hmibsc/MAINTAINERS
new file mode 100644
index 000..0f31bbda966
--- /dev/null
+++ b/board/schneider/hmibsc/MAINTAINERS
@@ -0,0 +1,6 @@
+HMIBSC BOARD
+M: Sumit Garg
+S: Maintained
+F: board/schneider/hmibsc/
+F: include/configs/hmibsc.h
+F: configs/hmibsc_defconfig
diff --git a/board/schneider/hmibsc/hmibsc.env
b/board/schneider/hmibsc/hmibsc.env
new file mode 100644
index 000..da3d892f91d
--- /dev/null
+++ b/board/schneider/hmibsc/hmibsc.env
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+loadaddr=0x9000
+bootcmd=
+ echo "Booting RAUC A/B system";
+ setenv devtype mmc; setenv devnum 0;
+ test -n "${BOOT_ORDER}" || setenv BOOT_ORDER "A B";
+ test -n "${BOOT_A_LEFT}" || setenv BOOT_A_LEFT 3;
+ test -n "${BOOT_B_LEFT}" || setenv BOOT_B_LEFT 3;
+ setenv raucslot;
+ for BOOT_SLOT in "${BOOT_ORDER}"; do
+ if test "x${raucslot}" != "x"; then
+ echo "skip remaining slots...";
+ elif test "x${BOOT_SLOT}" = "xA"; then
+ if test ${BOOT_A_LEFT} -gt 0; then
+ setexpr BOOT_A_LEFT ${BOOT_A_LEFT} - 1;
+ echo "Found valid RAUC slot A";
+ setenv raucslot "rauc.slot=A";
+ setenv raucpart A; setenv distro_bootpart 6;
+ fi;
+ elif test "x${BOOT_SLOT}" = "xB"; then
+ if test ${BOOT_B_LEFT} -gt 0; then
+ setexpr BOOT_B_LEFT ${BOOT_B_LEFT} - 1;
+ echo "Found valid RAUC slot B";
+ setenv raucslot "rauc.slot=B";
+ setenv raucpart B; setenv distro_bootpart 7;
+ fi;
+ fi;
+ done;
+ if test -n "${raucslot}"; then
+ setenv bootargs console=ttyMSM1
root=PARTLABEL=rootfs_${raucpart} rw rootwait ${raucslot};
+ saveenv;
+ else
+ echo "No valid RAUC slot found. Resetting tries to 3";
+ setenv BOOT_A_LEFT 3;
+ setenv BOOT_B_LEFT 3;
+ saveenv;
+ reset;
+ fi;
+ load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} /boot/fitImage
&& bootm;
diff --git a/configs/hmibsc_defconfig b/configs/hmibsc_defconfig
new file mode 100644
index 000..a07689894ef
--- /dev/null
+++ b/configs/hmibsc_defconfig
@@ -0,0 +1,87 @@
+CONFIG_ARM=y
+CONFIG_SYS_VENDOR="schneider"
+CONFIG_SYS_BOARD="hmibsc"
+CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
+CONFIG_ARCH_SNAPDRAGON=y
+CONFIG_TEXT_BASE=0x8f60
+CONFIG_SYS_MALLOC_LEN=0x802000
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0
+CONFIG_ENV_SIZE=0x2000
+CONFIG_ENV_OFFSET=0x0
+CONFIG_DEFAULT_DEVICE_TREE="apq8016-schneider-hmibsc"
+# CONFIG_OF_UPSTREAM is not set
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_IDENT_STRING="\nSchneider Electric-HMIBSC"
+CONFIG_SYS_LOAD_ADDR=0x8008
+CONFIG_REMAKE_ELF=y
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_FIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_CBSIZE=2048
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_SYS_PROMPT="hmibsc => "
+CONFIG_SYS_MAXARGS=64
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_USB=y
+CONFIG_BOOTP_BOOTFILESIZE=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_ENV_FLAGS=y
+CONFIG_CMD_ENV_EXISTS=y
+CONFIG_CMD_NVEDIT_INFO=y
+CONFIG_ENV_WRITEABLE_LIST=y
+CONFIG_ENV_ACCESS_IGNORE_FORCE=y
+CONFIG_ENV_IS_IN_MMC=y
Re: [PATCH 01/13] ti:keys Add EFI signature list
Hi Jon,
On Wed, 10 Apr 2024 at 20:35, Jon Humphreys wrote:
>
> Ilias Apalodimas writes:
>
> > On Tue, 9 Apr 2024 at 23:14, Andrew Davis wrote:
> >>
> >> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
> >> > On 4/9/24 14:14, Andrew Davis wrote:
> >> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
> >> >>> On 4/8/24 23:33, Jonathan Humphreys wrote:
> >> EFI signature list using TI dummy keys.
> >> >>>
> >> >>> Adding vendor public keys into the code base to lock down generated
> >> >>> binaries to the vendors unpublished private key does not match well
> >> >>> with
> >> >>> the intent of the GNU public license.
> >> >>>
> >> >>
> >> >> The matching private keys are already published in this same
> >> >> repo/directory (arch/arm/mach-k3/keys).
> >> >>
> >> >> Andrew
> >> >
> >> > Why should we create signed capsules which are already compromised by
> >> > publishing the private key?
> >> >
> >>
> >> If you buy these devices you have two options, you can burn real
> >> keys, or you can burn these dummy keys. If you burn dummy keys
> >> then these images will boot and so will any image you or anyone
> >> else wants to boot on the device. (since the keys are published
> >> anyone can make images for them, that is how we do GP (general
> >> purpose) devices these days)
> >>
> >> If you burn your own keys, then you switch out these keys here
> >> and your device will only boot images that you permit by signing
> >> with your keys.
> >
> > I am not sure I am following you here. We don't burn anything in the
> > case of EFI keys. They are placed in an elf section and we assume the
> > device will have a chain of trust enabled, naturally verifying those
> > keys along with the u-boot binary.
> >
> >>
> >> You'll find plenty of open source projects do the same and
> >> give out example keys to show how to use real keys, even
> >> official GNU projects.
> >
> > Yes, but the keys defined here are useless unless you have a default
> > defconfig that uses them and embeds them in the binary. I am not cc'ed
> > in all the patches of the series, is that added somewhere? And if you
>
> Yes, they are part of this series
> https://lore.kernel.org/r/20240408213349.96610-1-j-humphr...@ti.com.
> Thanks for the reviews.
>
> > unconditionally enable secure boot It would be far more interesting to
> > embed the MS SHIM key along with that special key you are trying to
> > define, so that firmware can boot COTS distros as well
>
> Yes, we should consider. But since that is outside of the EFI capsule
> use case, I would rather take it up in a separate patch.
Ok, the commit message wasn't clear, and based on Andrews's initial
response I thought you wanted to use those for UEFI secure boot, not
capsule updates.
Those are your boards so I won't NAK this, but I'd strongly advise
*not* to add this. I assume you want capsule auth by default because
SystemReady-IR >=2.0 mandates it?
In that case, it would be a far better idea to document the process of
creating signed capsules clearly either in U-Boots EFI docs and/or
your board docs.
I am pretty confident that if we merge this now we will have future
products using the keys above
Thanks
/Ilias
>
> >
> > Thanks
> > /Ilias
> >
> >
> >>
> >> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
> >>
> >> Andrew
> >>
> >> > Best regards
> >> >
> >> > Heinrich
> >> >
> >> >>
> >> >>> Best regards
> >> >>>
> >> >>> Heinrich
> >> >>>
> >>
> >> Signed-off-by: Jonathan Humphreys
> >> ---
> >> arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
> >> 1 file changed, 0 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
> >>
> >> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
> >> b/arch/arm/mach-k3/keys/custMpk.esl
> >> new file mode 100644
> >> index
> >> ..2feb704e0a5fd126410de451d3c0fa4d3edccc52
> >> GIT binary patch
> >> literal 1523
> >> zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
> >> z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
> >> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
> >> zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO >> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
> >> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
> >> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
> >> z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
> >> z{LIBUzm_CMw_SIFfPdcT#zmg6g >> zFUCK{#b(Lp`M3Uj
> >> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
> >> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
> >> z8dh8T-~Dmrp2?yk3O6Gqbz7O@ >> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
> >> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
> >>
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi, On Fri Apr 12, 2024 at 5:03 AM CEST, Neha Malcom Francis wrote: > On 05/04/24 13:12, Michael Walle wrote: > > On Thu Apr 4, 2024 at 11:10 AM CEST, Neha Malcom Francis wrote: > >> But again in the interest of time... this would mean this cleaning up > >> effort be > >> kept on hold. If we can agree to move to using the generator later as the > >> final > >> solution, can we pick up this series for now? > > > > Agreed. I just saw the new RFC for the j722s support. It should also > > make use of this cleanup then, btw. > > > > Right, I'll sync with J722S efforts as well. > > So is this series good to go? If the ultimate goal is to support the generator, sure. -michael
[PATCH v6 5/5] imx93: convert to OF_UPSTREAM
From: Peng Fan
Convert all i.MX93 boards to OF_UPSTREAM.
Add lpi2c2 nodes for imx93-11x11-evk-u-boot.dtsi.
Add usbotg1 nodes in imx93-u-boot.dtsi and board u-boot.dtsi.
The nodes could be removed after upstream linux supports them.
Signed-off-by: Peng Fan
---
arch/arm/dts/Makefile | 5 -
arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119
arch/arm/dts/imx93-11x11-evk.dts| 322 -
arch/arm/dts/imx93-phyboard-segin.dts | 117 ---
arch/arm/dts/imx93-phycore-som.dtsi | 126
arch/arm/dts/imx93-pinfunc.h| 623
arch/arm/dts/imx93-u-boot.dtsi | 80 +++
arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 +
arch/arm/dts/imx93-var-som-symphony.dts | 323 -
arch/arm/dts/imx93-var-som.dtsi | 111 ---
arch/arm/dts/imx93.dtsi | 906
arch/arm/mach-imx/imx9/Kconfig | 1 +
configs/imx93-phyboard-segin_defconfig | 2 +-
configs/imx93_11x11_evk_defconfig | 2 +-
configs/imx93_11x11_evk_ld_defconfig| 2 +-
configs/imx93_var_som_defconfig | 2 +-
include/dt-bindings/clock/imx93-clock.h | 208 --
include/dt-bindings/power/fsl,imx93-power.h | 15 -
18 files changed, 226 insertions(+), 2760 deletions(-)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2634bb4c9ac..0b6a92e36e9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1046,11 +1046,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-kontron-pitx-imx8m.dtb \
imx8mq-librem5-r4.dtb
-dtb-$(CONFIG_ARCH_IMX9) += \
- imx93-11x11-evk.dtb \
- imx93-var-som-symphony.dtb \
- imx93-phyboard-segin.dtb
-
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
imxrt1170-evk.dtb \
diff --git a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
index a99ba99bfb4..4a834ded44c 100644
--- a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
@@ -26,6 +26,112 @@
bootph-pre-ram;
};
+/* The node should be removed after upstream supports it */
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <40>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_lpi2c2>;
+ pinctrl-1 = <_lpi2c2>;
+ status = "okay";
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+ interrupt-parent = <>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <65>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4{
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5{
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <160>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+
Re: [PATCH 0/3] arm: Add Analog Devices SC5xx Machine Type
On Thu, 2024-04-11 at 20:18 -0400, Greg Malysa wrote: > I'm afraid I have to admit I don't know. I'll work with our IT team to > make sure we can run CI locally, and when v2 comes around the answer > will be yes. > AFAIR, I think you the only exception to open a PR in the github fork is to run CI. - Nuno Sá
Re: [U-Boot] [PATCH] mmc: dw-mmc: support DesignWare MMC controller
Dear Mr. Jaehoon Chung, Hello! I am learning to write an mmc driver, I saw this driver code you wrote in 2012 in U-boot source code, I can't download the documentation of DesignWare MMC controller, so I can't work on my driver development. I hope you can provide some help! Have a nice life!
[PATCH v6 3/5] cpu: drop imx9_cpu
From: Peng Fan
This was wrongly committed, no user, remove it.
Signed-off-by: Peng Fan
---
drivers/cpu/imx9_cpu.c | 224 -
1 file changed, 224 deletions(-)
diff --git a/drivers/cpu/imx9_cpu.c b/drivers/cpu/imx9_cpu.c
deleted file mode 100644
index 66534fe6d17..000
--- a/drivers/cpu/imx9_cpu.c
+++ /dev/null
@@ -1,224 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2019 NXP
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-DECLARE_GLOBAL_DATA_PTR;
-
-struct cpu_imx_plat {
- const char *name;
- const char *rev;
- const char *type;
- u32 cpu_rsrc;
- u32 cpurev;
- u32 freq_mhz;
- u32 mpidr;
-};
-
-const char *get_imx9_type(u32 imxtype)
-{
- switch (imxtype) {
- case MXC_CPU_IMX93:
- return "93";
- default:
- return "??";
- }
-}
-
-const char *get_imx9_rev(u32 rev)
-{
- switch (rev) {
- case CHIP_REV_1_0:
- return "1.";
- case CHIP_REV_B:
- return "B";
- case CHIP_REV_C:
- return "C";
- default:
- return "?";
- }
-}
-
-static void set_core_data(struct udevice *dev)
-{
- struct cpu_imx_plat *plat = dev_get_plat(dev);
-
- if (device_is_compatible(dev, "arm,cortex-a35"))
- plat->name = "A35";
- else
- plat->name = "?";
-}
-
-#if IS_ENABLED(CONFIG_IMX_SCU_THERMAL)
-static int cpu_imx_get_temp(struct cpu_imx_plat *plat)
-{
- struct udevice *thermal_dev;
- int cpu_tmp, ret;
- int idx = 1; /* use "cpu-thermal0" device */
-
- if (plat->cpu_rsrc == SC_R_A72)
- idx = 2; /* use "cpu-thermal1" device */
-
- ret = uclass_get_device(UCLASS_THERMAL, idx, _dev);
- if (!ret) {
- ret = thermal_get_temp(thermal_dev, _tmp);
- if (ret)
- return 0xdeadbeef;
- } else {
- return 0xdeadbeef;
- }
-
- return cpu_tmp;
-}
-#else
-static int cpu_imx_get_temp(struct cpu_imx_plat *plat)
-{
- return 0;
-}
-#endif
-
-int cpu_imx_get_desc(const struct udevice *dev, char *buf, int size)
-{
- struct cpu_imx_plat *plat = dev_get_plat(dev);
- int ret, temp;
-
- if (size < 100)
- return -ENOSPC;
-
- ret = snprintf(buf, size, "NXP i.MX8%s Rev%s %s at %u MHz",
- plat->type, plat->rev, plat->name, plat->freq_mhz);
-
- if (IS_ENABLED(CONFIG_IMX_SCU_THERMAL)) {
- temp = cpu_imx_get_temp(plat);
- buf = buf + ret;
- size = size - ret;
- if (temp != 0xdeadbeef)
- ret = snprintf(buf, size, " at %dC", temp);
- else
- ret = snprintf(buf, size, " - invalid sensor data");
- }
-
- snprintf(buf + ret, size - ret, "\n");
-
- return 0;
-}
-
-static int cpu_imx_get_info(const struct udevice *dev, struct cpu_info *info)
-{
- struct cpu_imx_plat *plat = dev_get_plat(dev);
-
- info->cpu_freq = plat->freq_mhz * 1000;
- info->features = BIT(CPU_FEAT_L1_CACHE) | BIT(CPU_FEAT_MMU);
- return 0;
-}
-
-static int cpu_imx_get_count(const struct udevice *dev)
-{
- ofnode node;
- int num = 0;
-
- ofnode_for_each_subnode(node, dev_ofnode(dev->parent)) {
- const char *device_type;
-
- if (!ofnode_is_enabled(node))
- continue;
-
- device_type = ofnode_read_string(node, "device_type");
- if (!device_type)
- continue;
-
- if (!strcmp(device_type, "cpu"))
- num++;
- }
-
- return num;
-}
-
-static int cpu_imx_get_vendor(const struct udevice *dev, char *buf, int size)
-{
- snprintf(buf, size, "NXP");
- return 0;
-}
-
-static int cpu_imx_is_current(struct udevice *dev)
-{
- struct cpu_imx_plat *plat = dev_get_plat(dev);
-
- if (plat->mpidr == (read_mpidr() & 0x))
- return 1;
-
- return 0;
-}
-
-static const struct cpu_ops cpu_imx9_ops = {
- .get_desc = cpu_imx_get_desc,
- .get_info = cpu_imx_get_info,
- .get_count = cpu_imx_get_count,
- .get_vendor = cpu_imx_get_vendor,
- .is_current = cpu_imx_is_current,
-};
-
-static const struct udevice_id cpu_imx9_ids[] = {
- { .compatible = "arm,cortex-a35" },
- { .compatible = "arm,cortex-a53" },
- { .compatible = "arm,cortex-a72" },
- { }
-};
-
-static ulong imx9_get_cpu_rate(struct udevice *dev)
-{
- struct cpu_imx_plat *plat = dev_get_plat(dev);
- ulong rate;
- int ret;
-
- ret = sc_pm_get_clock_rate(-1, plat->cpu_rsrc, SC_PM_CLK_CPU,
- (sc_pm_clock_rate_t *));
-
[PATCH v6 4/5] clk: imx93: fix anatop base
From: Peng Fan
The PLL clk needs use anatop base, otherwise wrong PLL address will
be used.
Fixes: 9c153e46661b ("clk: imx: add i.MX93 CCF driver")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx93.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx93.c b/drivers/clk/imx/clk-imx93.c
index ce10d795316..f0cb797d975 100644
--- a/drivers/clk/imx/clk-imx93.c
+++ b/drivers/clk/imx/clk-imx93.c
@@ -289,7 +289,7 @@ static int imx93_clk_probe(struct udevice *dev)
clk_dm(IMX93_CLK_SYS_PLL_PFD2_DIV2,
imx_clk_fixed_factor("sys_pll_pfd2_div2", "sys_pll_pfd2", 1, 2));
- base = (void *)ANATOP_BASE_ADDR;
+ anatop_base = (void *)ANATOP_BASE_ADDR;
clk_dm(IMX93_CLK_ARM_PLL,
imx_clk_fracn_gppll_integer("arm_pll", "clock-osc-24m",
--
2.35.3
Re: [PATCH 0/2] Remove ti,sci-sysreset
On Tue, 02 Apr 2024 11:09:06 -0500, Andrew Davis wrote: > Idea here is to remove one more delta between the U-Boot and Linux > DTB files: ti,sci-sysreset. We currently have to add this to every > board's -u-boot.dtsi file as this is not a standard node. Instead do > what we are moving the kernel towards[0] and remove this node. > > Thanks, > Andrew > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/2] Add TIFS Stub support in AM62x
On Wed, 03 Apr 2024 17:33:08 +0530, Dhruva Gole wrote: > Add support for signing, detection and loading of TIFSSTUB images for > for HSSE, HSFS and GP AM62x devices. > > Boot tested and Deepsleep entry exist tested with ti-linux: > https://gist.github.com/DhruvaG2000/036010f6ae75aa6443fc77f61fd74893 > > Patches are based on top of tag: v2024.04 > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] verdin-am62: move verdin am62 to OF_UPSTREAM
On Wed, 03 Apr 2024 09:15:10 +0200, Marcel Ziswiler wrote: > Move verdin-am62 to OF_UPSTREAM: > - handle the fact that dtbs now have a 'ti/' prefix > - imply OF_UPSTREAM > - remove redundant files from arch/arm/dts leaving only the > *-u-boot.dtsi files > - update MAINTAINERS file > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH] doc/sphinx: Bump idna to 3.7
While we unlikely to have an issue with CVE-2024-3651, it is simple enough to bump our version of idna to receive the fix, do so. Cc: Heinrich Schuchardt Reported-by: GitHub dependabot Signed-off-by: Tom Rini --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 840c6cedfde4..5b4df36804b5 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -3,7 +3,7 @@ Babel==2.14.0 certifi==2023.11.17 charset-normalizer==3.3.2 docutils==0.20.1 -idna==3.6 +idna==3.7 imagesize==1.4.1 Jinja2==3.1.3 MarkupSafe==2.1.3 -- 2.34.1
Re: [PATCH v4 4/7] pinctrl: qcom: Add support for driving GPIO pins output
On 12/04/2024 11:54, Sumit Garg wrote:
Add support for driving the GPIO pins as output low or high.
Signed-off-by: Sumit Garg
---
drivers/pinctrl/qcom/pinctrl-qcom.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index 909e566acf5..e68971b37ff 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -29,15 +29,24 @@ struct msm_pinctrl_priv {
#define GPIO_CONFIG_REG(priv, x) \
(qcom_pin_offset((priv)->data->pin_data.pin_offsets, x))
-#define TLMM_GPIO_PULL_MASK GENMASK(1, 0)
-#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
-#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
-#define TLMM_GPIO_DISABLE BIT(9)
+#define GPIO_IN_OUT_REG(priv, x) \
+ (GPIO_CONFIG_REG(priv, x) + 0x4)
+
+#define TLMM_GPIO_PULL_MASKGENMASK(1, 0)
+#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
+#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
+#define TLMM_GPIO_OUTPUT_MASK BIT(1)
+#define TLMM_GPIO_OE_MASK BIT(9)
+
+/* GPIO register shifts. */
+#define GPIO_OUT_SHIFT 1
static const struct pinconf_param msm_conf_params[] = {
{ "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 2 },
{ "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 3 },
+ { "output-high", PIN_CONFIG_OUTPUT, 1, },
+ { "output-low", PIN_CONFIG_OUTPUT, 0, },
};
static int msm_get_functions_count(struct udevice *dev)
@@ -90,7 +99,7 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int
pin_selector,
return 0;
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
- TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
+ TLMM_FUNC_SEL_MASK | TLMM_GPIO_OE_MASK, func << 2);
return 0;
}
@@ -117,6 +126,12 @@ static int msm_pinconf_set(struct udevice *dev, unsigned int pin_selector,
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv,
pin_selector),
TLMM_GPIO_PULL_MASK, argument);
break;
+ case PIN_CONFIG_OUTPUT:
+ writel(argument << GPIO_OUT_SHIFT,
+ priv->base + GPIO_IN_OUT_REG(priv, pin_selector));
+ setbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
+TLMM_GPIO_OE_MASK);
+ break;
default:
return 0;
}
Reviewed-by: Neil Armstrong
Re: [PATCH v2 0/3] *** Introduce get_boot_device() for K3 platform ***
On Wed, Apr 03, 2024 at 03:59:08PM +0200, Wadim Egorov wrote: > It is handy to have some u-boot environment variables set based on > the current booting device. > Provide a way to obtain the boot device for non SPLs by factoring out > spl_boot_device() into an own function get_boot_device(). Applied to u-boot/master now (but I seem to have missed this in b4 ty), thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 0/6] USB keyboard improvements for asahi / desktop systems
On 4/8/24 9:46 AM, Janne Grunau wrote:
On Sun, Apr 07, 2024 at 03:05:59AM +0200, Marek Vasut wrote:
On 4/6/24 10:04 PM, Janne Grunau wrote:
On Sat, Apr 06, 2024 at 08:52:17PM +0200, Marek Vasut wrote:
On 4/5/24 9:05 PM, Janne Grunau wrote:
On Fri, Apr 05, 2024 at 04:52:32PM +0200, Marek Vasut wrote:
On 4/4/24 8:25 AM, Janne Grunau via B4 Relay wrote:
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
descriptor but the second. This needs several changes. The USB keyboard
driver has to look at all (2) interface descriptors during probing.
Since I didn't want to rebuild the USB driver probe code the Apple
keyboards are bound to the keyboard driver via USB vendor and product
IDs.
To make the keyboards useable on Apple silicon devices the xhci driver
needs to initializes rings for the endpoints of the first two interface
descriptors. If this is causes concerns regarding regressions or memory
use the USB_MAX_ACTIVE_INTERFACES define could be turned into a CONFIG
option.
Even after this changes the keyboards still do not probe successfully
since they apparently do not behave HID standard compliant. They only
generate reports on key events. This leads the final check whether the
keyboard is operational to fail unless the user presses keys during the
probe. Skip this check for known keyboards.
Keychron seems to emulate Apple keyboards (some models even "re-use"
Apple's USB vendor ID) so apply this quirk as well.
Some devices like Yubikeys emulate a keyboard. since u-boot only binds a
single keyboard block this kind of devices from the USB keyboard driver.
Signed-off-by: Janne Grunau
I picked the series, but CI indicates build errors, can you have a look ?
https://source.denx.de/u-boot/custodians/u-boot-usb/-/pipelines/20215
The issue seems to be that the field dev in struct usb_device exists
only for DM_USB. That means we can't use dev_dbg.
Either take the following fixup patch or I can resend the series.
I squashed the extra patch in, but I think the CI still complains:
Pipeline #20236 (
https://source.denx.de/u-boot/custodians/u-boot-usb/-/pipelines/20236 )
triggered by Marek Vasut ( https://source.denx.de/marex )
had 1 failed job.
Job #812215 (
https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/812215/raw )
env_get() missing without CONFIG_ENV_SUPPORT. I'm too accustomed to the
kernel's stub functions. Best option seems to to just #if the
functionality out in this case. See attached fixup patch.
Sorry,
No worries.
Does it work if you do this instead ?
static int usb_device_is_ignored(u16 id_vendor, u16 id_product)
{
ulong vid, pid;
+ /* No env support, nothing can be ignored */
+ if (CONFIG_IS_ENABLED(ENV_SUPPORT))
+ return 0;
That way, the function is always compiled and if it is unreachable, then
compiler throws it out. This should improve code compile coverage.
Seems to work here with a broken imx8 config from the CI. Is it ok to
rely on dead code elimination? Apparently it is, build with KCFLAGS=-O0
has already several other missing symbols.
See attached fixup
Thanks, squashed, let's see how CI likes this.
Re: [PATCH] usb: musb-new: sunxi: support usage with DM_USB_GADGET
On 12/31/23 9:38 PM, Aren Moynihan wrote:
Add support for building the sunxi-musb driver with DM_USB_GADGET
including adding a separate IRQ handling function and registering the
driver with the musb system differently.
The implementation of usb_gadget_register_driver from
musb-new/musb_uboot.c only works when the gadget driver for the device
has already been probed and has called musb_register. On the pinephone
(using a allwinner a64 processor) this causes issues when trying to use
usb gadget mode (such as from the ums command) and CONFIG_USB_ETHER is
disabled.
The implementation of usb_gadget_register_driver provided when
DM_USB_GADGET is enabled will probe the necessary drivers when it's
called.
Without the patch, this is what the error condition looks like:
=> ums 0 mmc 1
UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x3a3e000
Controller uninitialized
g_dnl_register: failed!, error: -6
g_dnl_register failed
based on:
commit 2e4865bc6486 ("musb-new: omap2430: fix compiling in DM_USB_GADGET
config")
Signed-off-by: Aren Moynihan
---
I don't fully understand what's going on here. Some gadget mode drivers,
such as usb ether (in usb_ether_init) will initialize the usb gadget
driver, but others (ums, fastboot) don't seem to do this, or don't do it
early enough, so they don't work.
drivers/usb/musb-new/sunxi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 91f082fe05e..9b06f49ce47 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -429,6 +429,17 @@ static struct musb_hdrc_config musb_config_h3 = {
.ram_bits = SUNXI_MUSB_RAM_BITS,
};
+#ifdef CONFIG_DM_USB_GADGET
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+ int n = 0;
Is this used for anything?
+CC Mattijs
Re: [PATCH v6 0/5] imx93: Conver to OF_UPSTREAM
On Fri, Apr 12, 2024 at 10:24 AM Peng Fan (OSS) wrote: > > A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), those > nodes > could be dropped after upstream linux supports them. > > To support OF_UPSTREAM, a few driver changes are included. > For TMU, still use U-Boot node, I will prepare a kernel update, > then back to U-Boot support. > > Mathieu: please help test the boards you maintain when you have time. The series looks good. I will apply it after Mathieu or the Phytec folks confirm this series does not break imx93-phyboard-segin.
[RFC] pci: mediatek: add PCIe controller support for Filogic
From: John Crispin
This adds PCIe controller support for the MediaTek Filogic family..
Signed-off-by: John Crispin
Signed-off-by: Frank Wunderlich
---
Note for mt7988: pcie2 needs a dedicated phy which has no driver
in uboot yet, so this pcie port is not enabled in the board device-
trees.
Note for mt7981: i have no board and have no dts nodes yet for it,
so only clock change first.
---
arch/arm/dts/mt7986.dtsi | 46 +++
arch/arm/dts/mt7988-rfb.dts| 12 +
arch/arm/dts/mt7988-sd-rfb.dts | 12 +
arch/arm/dts/mt7988.dtsi | 164 +++
drivers/clk/mediatek/clk-mt7986.c | 5 +-
drivers/pci/Kconfig| 7 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_mediatek_gen3.c | 382 +
include/dt-bindings/clock/mt7981-clk.h | 3 +-
include/dt-bindings/clock/mt7986-clk.h | 3 +-
10 files changed, 631 insertions(+), 4 deletions(-)
create mode 100644 drivers/pci/pcie_mediatek_gen3.c
diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
index c9aeeaca2b11..9a9b0b64cc68 100644
--- a/arch/arm/dts/mt7986.dtsi
+++ b/arch/arm/dts/mt7986.dtsi
@@ -375,5 +375,51 @@
#phy-cells = <1>;
status = "okay";
};
+
+ pcie_port: pcie-phy@11c0 {
+ reg = <0x11c0 0x2>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
+ pcie: pcie@1128 {
+ compatible = "mediatek,mt7986-pcie",
+"mediatek,mt8192-pcie";
+ device_type = "pci";
+ reg = <0x1128 0x4000>;
+ reg-names = "pcie-mac";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <_ao CK_INFRA_IPCIE_PIPE_CK>,
+<_ao CK_INFRA_IPCIE_CK>,
+<_ao CK_INFRA_IPCIER_CK>,
+<_ao CK_INFRA_IPCIEB_CK>;
+ clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
+
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2000 0x2000 0 0x1000>;
+
+ interrupts = ;
+ #interrupt-cells = <2>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 0>, /* INTA */
+ <0 0 0 2 _intc 1>, /* INTB */
+ <0 0 0 3 _intc 2>, /* INTC */
+ <0 0 0 4 _intc 3>; /* INTD */
+
+ phy-names = "pcie-phy";
+ phys = <_port PHY_TYPE_PCIE>;
+
+ status = "okay";
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
};
};
diff --git a/arch/arm/dts/mt7988-rfb.dts b/arch/arm/dts/mt7988-rfb.dts
index 2c1142843091..2f0d00b6950b 100644
--- a/arch/arm/dts/mt7988-rfb.dts
+++ b/arch/arm/dts/mt7988-rfb.dts
@@ -180,3 +180,15 @@
non-removable;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7988-sd-rfb.dts b/arch/arm/dts/mt7988-sd-rfb.dts
index a3df37d252de..0a3eb5360d21 100644
--- a/arch/arm/dts/mt7988-sd-rfb.dts
+++ b/arch/arm/dts/mt7988-sd-rfb.dts
@@ -132,3 +132,15 @@
vqmmc-supply = <_3p3v>;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7988.dtsi b/arch/arm/dts/mt7988.dtsi
index ac476d5cdd7f..b2e2724732fc 100644
--- a/arch/arm/dts/mt7988.dtsi
+++ b/arch/arm/dts/mt7988.dtsi
@@ -194,6 +194,152 @@
status = "okay";
};
+ pcie2: pcie@1128 {
+ compatible = "mediatek,mt7988-pcie",
+"mediatek,mt7986-pcie",
+"mediatek,mt8192-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0 0x1128 0 0x2000>;
+ reg-names = "pcie-mac";
+ linux,pci-domain = <3>;
+ interrupts = ;
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2020 0 0x2020 0 0x07e0>;
+ clocks = <_ao_cgs CK_INFRA_PCIE_PIPE_P2>,
+<_ao_cgs CK_INFRA_PCIE_GFMUX_TL_P2>,
+<_ao_cgs CK_INFRA_PCIE_PERI_26M_CK_P2>,
+<_ao_cgs CK_INFRA_133M_PCIE_CK_P2>;
+ clock-names = "pl_250m", "tl_26m", "peri_26m",
+ "top_133m";
+ phys = <
Re: [PATCH 0/4] Cleanup K3 binman templating
On Fri, Mar 22, 2024 at 06:40:07PM +0530, Neha Malcom Francis wrote: > This series does primarily three things: > 1. Split out the common J721E defconfig for both EVM and SK > 2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman nodes > and -u-boot.dtsi files of the respective boards can pick and > edit according to their board. This is based on the > discussion [1] and this is the primary goal of this series > 3. Move J721E EVM and SK to using OF_UPSTREAM > > This series depends on series [2] and patch [3] which implement > OF_UPSTREAM. > > Also received input from Nishanth to clean up the unnecessary artifacts > in the final build directory (maybe populate them in another directory), > working on that as well but didn't want to delay v1 further considering > I'm modifying a bunch of board builds and would like some friendly build > tests and boot tests for them. Please rebase this on top of current master, thanks. -- Tom signature.asc Description: PGP signature
RE: [PATCH v5 2/5] serial: lpuart: use ipg clk for i.MX7ULP
> Subject: Re: [PATCH v5 2/5] serial: lpuart: use ipg clk for i.MX7ULP
>
> Hi Peng,
>
> On Thu, Apr 11, 2024 at 12:23 AM Peng Fan (OSS)
> wrote:
> >
> > From: Peng Fan
> >
> > To i.MX7ULP compatible lpuart, there is only ipg clk, no per clk.
> > So add a devtype check for i.MX7ULP.
> >
> > Signed-off-by: Peng Fan
> > ---
> > drivers/serial/serial_lpuart.c | 28 +++-
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/serial/serial_lpuart.c
> > b/drivers/serial/serial_lpuart.c index ce08a6b4486..891352293f9 100644
> > --- a/drivers/serial/serial_lpuart.c
> > +++ b/drivers/serial/serial_lpuart.c
> > @@ -111,11 +111,18 @@ u32 __weak get_lpuart_clk(void) #if
> > CONFIG_IS_ENABLED(CLK) static int get_lpuart_clk_rate(struct udevice
> > *dev, u32 *clk) {
> > + struct lpuart_serial_plat *plat = dev_get_plat(dev);
> > struct clk per_clk;
>
> You ignored my previous comment. Here I go again:
>
> Please rename 'per_clk' to 'clk'.
Sorry for that. I will fix in v6.
>
> > ulong rate;
> > int ret;
> > + char *name;
> > +
> > + if (plat->devtype == DEV_MX7ULP)
> > + name = "ipg";
> > + else
> > + name = "per";
> >
> > - ret = clk_get_by_name(dev, "per", _clk);
> > + ret = clk_get_by_name(dev, name, _clk);
>
> ... because it is confusing that per_clk can be ipg or per clock.
Yeah.
>
> > if (ret) {
> > dev_err(dev, "Failed to get per clk: %d\n", ret);
>
> And then also change the error message to "clk".
Fix in v6.
Thanks,
Peng.
[PATCH v6 0/5] imx93: Conver to OF_UPSTREAM
A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), those nodes could be dropped after upstream linux supports them. To support OF_UPSTREAM, a few driver changes are included. For TMU, still use U-Boot node, I will prepare a kernel update, then back to U-Boot support. Mathieu: please help test the boards you maintain when you have time. Thanks, Peng. To: Stefano Babic To: Fabio Estevam To: "NXP i.MX U-Boot Team" To: Mathieu Othacehe Cc: u-boot@lists.denx.de Signed-off-by: Peng Fan Changes in v6: - Update the serial lpuart patch, to rename per_clk to clk, also change the input parameter u32 *clk to u32 *clk_rate. - Link to v5: https://lore.kernel.org/r/20240411-imx93-of-v2-v5-0-9eb3c64ff...@nxp.com Changes in v5: - Correct uart clk checking - Link to v4: https://lore.kernel.org/r/20240328-imx93-of-v2-v4-0-338d15a65...@nxp.com Changes in v4: - Convert all i.MX93 boards - Link to v3: https://lore.kernel.org/r/20240328-imx93-of-v3-0-4e7f341ed...@nxp.com Changes in v3: - Update patch 5, to drop the imx8mp-evk changes which are wrongly included - Link to v2: https://lore.kernel.org/r/20240328-imx93-of-v2-0-909f5d37d...@nxp.com Changes in v2: - Add a new patch to sync clock header to avoid breaking - Drop the Makefile change which change including order - Link to v1: https://lore.kernel.org/r/20240327-imx93-of-v1-0-afab6b314...@nxp.com --- Peng Fan (5): gpio: imx_rgpio2p: support one address serial: lpuart: use ipg clk for i.MX7ULP cpu: drop imx9_cpu clk: imx93: fix anatop base imx93: convert to OF_UPSTREAM arch/arm/dts/Makefile | 5 - arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119 arch/arm/dts/imx93-11x11-evk.dts| 322 - arch/arm/dts/imx93-phyboard-segin.dts | 117 --- arch/arm/dts/imx93-phycore-som.dtsi | 126 arch/arm/dts/imx93-pinfunc.h| 623 arch/arm/dts/imx93-u-boot.dtsi | 80 +++ arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 + arch/arm/dts/imx93-var-som-symphony.dts | 323 - arch/arm/dts/imx93-var-som.dtsi | 111 --- arch/arm/dts/imx93.dtsi | 906 arch/arm/mach-imx/imx9/Kconfig | 1 + configs/imx93-phyboard-segin_defconfig | 2 +- configs/imx93_11x11_evk_defconfig | 2 +- configs/imx93_11x11_evk_ld_defconfig| 2 +- configs/imx93_var_som_defconfig | 2 +- drivers/clk/imx/clk-imx93.c | 2 +- drivers/cpu/imx9_cpu.c | 224 -- drivers/gpio/imx_rgpio2p.c | 42 +- drivers/serial/serial_lpuart.c | 42 +- include/dt-bindings/clock/imx93-clock.h | 208 -- include/dt-bindings/power/fsl,imx93-power.h | 15 - 22 files changed, 291 insertions(+), 3005 deletions(-) --- base-commit: 777c28460947371ada40868dc994dfe8537d7115 change-id: 20240328-imx93-of-v2-f879efef737d Best regards, -- Peng Fan
[PATCH v6 2/5] serial: lpuart: use ipg clk for i.MX7ULP
From: Peng Fan
To i.MX7ULP compatible lpuart, there is only ipg clk, no per clk.
So add a devtype check for i.MX7ULP.
Signed-off-by: Peng Fan
---
drivers/serial/serial_lpuart.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index ce08a6b4486..3f2be72b830 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -109,28 +109,35 @@ u32 __weak get_lpuart_clk(void)
}
#if CONFIG_IS_ENABLED(CLK)
-static int get_lpuart_clk_rate(struct udevice *dev, u32 *clk)
+static int get_lpuart_clk_rate(struct udevice *dev, u32 *clk_rate)
{
- struct clk per_clk;
+ struct lpuart_serial_plat *plat = dev_get_plat(dev);
+ struct clk clk;
ulong rate;
int ret;
+ char *name;
- ret = clk_get_by_name(dev, "per", _clk);
+ if (plat->devtype == DEV_MX7ULP)
+ name = "ipg";
+ else
+ name = "per";
+
+ ret = clk_get_by_name(dev, name, );
if (ret) {
- dev_err(dev, "Failed to get per clk: %d\n", ret);
+ dev_err(dev, "Failed to get clk: %d\n", ret);
return ret;
}
- rate = clk_get_rate(_clk);
+ rate = clk_get_rate();
if ((long)rate <= 0) {
- dev_err(dev, "Failed to get per clk rate: %ld\n", (long)rate);
+ dev_err(dev, "Failed to get clk rate: %ld\n", (long)rate);
return ret;
}
- *clk = rate;
+ *clk_rate = rate;
return 0;
}
#else
-static inline int get_lpuart_clk_rate(struct udevice *dev, u32 *clk)
+static inline int get_lpuart_clk_rate(struct udevice *dev, u32 *clk_rate)
{ return -ENOSYS; }
#endif
@@ -479,19 +486,22 @@ static int lpuart_serial_pending(struct udevice *dev,
bool input)
static int lpuart_serial_probe(struct udevice *dev)
{
#if CONFIG_IS_ENABLED(CLK)
+ struct lpuart_serial_plat *plat = dev_get_plat(dev);
struct clk per_clk;
struct clk ipg_clk;
int ret;
- ret = clk_get_by_name(dev, "per", _clk);
- if (!ret) {
- ret = clk_enable(_clk);
- if (ret) {
- dev_err(dev, "Failed to enable per clk: %d\n", ret);
- return ret;
+ if (plat->devtype != DEV_MX7ULP) {
+ ret = clk_get_by_name(dev, "per", _clk);
+ if (!ret) {
+ ret = clk_enable(_clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable per clk: %d\n",
ret);
+ return ret;
+ }
+ } else {
+ debug("%s: Failed to get per clk: %d\n", __func__, ret);
}
- } else {
- debug("%s: Failed to get per clk: %d\n", __func__, ret);
}
ret = clk_get_by_name(dev, "ipg", _clk);
--
2.35.3
[PATCH v6 1/5] gpio: imx_rgpio2p: support one address
From: Peng Fan
The i.MX8ULP/93 gpio dt-schema have been updated to only have one
address entry, update the driver to support it.
Signed-off-by: Peng Fan
---
drivers/gpio/imx_rgpio2p.c | 42 ++
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/imx_rgpio2p.c b/drivers/gpio/imx_rgpio2p.c
index 175e460aff5..3227a8d5b57 100644
--- a/drivers/gpio/imx_rgpio2p.c
+++ b/drivers/gpio/imx_rgpio2p.c
@@ -21,6 +21,12 @@ enum imx_rgpio2p_direction {
#define GPIO_PER_BANK 32
+struct imx_rgpio2p_soc_data {
+ bool have_dual_base;
+};
+
+#define IMX8ULP_GPIO_BASE_OFF 0x40
+
struct imx_rgpio2p_data {
struct gpio_regs *regs;
};
@@ -165,6 +171,9 @@ static int imx_rgpio2p_probe(struct udevice *dev)
static int imx_rgpio2p_bind(struct udevice *dev)
{
struct imx_rgpio2p_plat *plat = dev_get_plat(dev);
+ struct imx_rgpio2p_soc_data *data =
+ (struct imx_rgpio2p_soc_data *)dev_get_driver_data(dev);
+ bool dual_base = data->have_dual_base;
fdt_addr_t addr;
/*
@@ -176,9 +185,26 @@ static int imx_rgpio2p_bind(struct udevice *dev)
if (plat)
return 0;
- addr = devfdt_get_addr_index(dev, 1);
- if (addr == FDT_ADDR_T_NONE)
- return -EINVAL;
+ /*
+* Handle legacy compatible combinations which used two reg values
+* for the i.MX8ULP and i.MX93.
+*/
+ if (device_is_compatible(dev, "fsl,imx7ulp-gpio") &&
+ (device_is_compatible(dev, "fsl,imx93-gpio") ||
+ (device_is_compatible(dev, "fsl,imx8ulp-gpio"
+ dual_base = true;
+
+ if (dual_base) {
+ addr = devfdt_get_addr_index(dev, 1);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+ } else {
+ addr = devfdt_get_addr_index(dev, 0);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ addr += IMX8ULP_GPIO_BASE_OFF;
+ }
/*
* TODO:
@@ -202,9 +228,17 @@ static int imx_rgpio2p_bind(struct udevice *dev)
return 0;
}
+static struct imx_rgpio2p_soc_data imx7ulp_data = {
+ .have_dual_base = true,
+};
+
+static struct imx_rgpio2p_soc_data imx8ulp_data = {
+ .have_dual_base = false,
+};
static const struct udevice_id imx_rgpio2p_ids[] = {
- { .compatible = "fsl,imx7ulp-gpio" },
+ { .compatible = "fsl,imx7ulp-gpio", .data = (ulong)_data },
+ { .compatible = "fsl,imx8ulp-gpio", .data = (ulong)_data },
{ }
};
--
2.35.3
Re: [PATCH] doc/sphinx: Bump idna to 3.7
On 4/12/24 16:23, Tom Rini wrote: While we unlikely to have an issue with CVE-2024-3651, it is simple enough to bump our version of idna to receive the fix, do so. Cc: Heinrich Schuchardt Reported-by: GitHub dependabot Signed-off-by: Tom Rini Tested-by: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 840c6cedfde4..5b4df36804b5 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -3,7 +3,7 @@ Babel==2.14.0 certifi==2023.11.17 charset-normalizer==3.3.2 docutils==0.20.1 -idna==3.6 +idna==3.7 imagesize==1.4.1 Jinja2==3.1.3 MarkupSafe==2.1.3
Re: [PATCH v4 0/6] USB keyboard improvements for asahi / desktop systems
On 4/12/24 8:37 PM, Tom Rini wrote: On Fri, Apr 12, 2024 at 08:26:18PM +0200, Marek Vasut wrote: On 4/12/24 2:53 PM, Marek Vasut wrote: Hi, Seems to work here with a broken imx8 config from the CI. Is it ok to rely on dead code elimination? Apparently it is, build with KCFLAGS=-O0 has already several other missing symbols. See attached fixup Thanks, squashed, let's see how CI likes this. I think we are getting closer, but still ... Pipeline #20308 has failed! Project: USB U-Boot Custodian Tree ( https://source.denx.de/u-boot/custodians/u-boot-usb ) Branch: master ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/commits/master ) Commit: 63f6a449 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/commit/63f6a449bffe46beca89580d3efa48e5d041025c ) Commit Message: usb: kbd: Add probe quirk for Apple and Keychro... Commit Author: Janne Grunau Committed by: Marek Vasut ( https://source.denx.de/marex ) Pipeline #20308 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/pipelines/20308 ) triggered by Marek Vasut ( https://source.denx.de/marex ) had 1 failed job. Job #815411 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/815411/raw ) Stage: world build Name: build all 64bit ARM platforms That looks like the machine doing the build failed, I've kicked the retry button. And now it passed, PR is coming real soon now, thanks all !
[PATCH v2 1/2] lmb: Avoid to add identical region in lmb_add_region_flags()
In case lmb_add_region_flags() is called with the same parameter than
an already existing lmb and this lmb is adjacent to its previous lmb with
different flag, this lmb is added again.
Instead breaking the loop, continue, at the next iteration, we are able
to detect that this region already exist.
Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
shows:
Before this patch, the last LMB [0xde00-0xdfff] is duplicated:
...
lmb_dump_all:nnn
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
reserved[5][0xde00-0xdfff], 0x0200 bytes flags: 4
...
After this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
Fixes: 59c0ea5df33f ("lmb: Add support of flags for no-map properties")
Signed-off-by: Patrice Chotard
---
(no changes since v1)
lib/lmb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 44f98205310..b6afb731440 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -285,14 +285,14 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
if (adjacent > 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].base -= size;
rgn->region[i].size += size;
coalesced++;
break;
} else if (adjacent < 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].size += size;
coalesced++;
break;
--
2.25.1
[PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
In case a new region is adjacent to a previous region with
similar flag, this region is merged with its predecessor, but no
check are done if this new added region is overlapping another region
present in lmb (see reserved[3] which overlaps reserved[4]).
This occurs when the LMB [0xdaafd000-0xddb18000] is added and overlaps
the LMB [0xdbaf4380-0xddff].
Call lmb_overlaps_region() before merging the new region with the
adjacent region already present in lmb.
In case of adjacent region found, code is 90% similar in case
adjacent region is located before/after the new region.
Factorize adjacent region management in lmb_add_region_flags().
Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
shows:
before this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaae1000-0xdfff], 0x0551f000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
after this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaae1000-0xddff], 0x0351f000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
Fixes: 4ed6552f7159 ("[new uImage] Introduce lmb from linux kernel for memory
mgmt of boot images")
Signed-off-by: Patrice Chotard
---
Changes in v2:
_ Fix lmb_add_region_flags() by updating test which leads to
extend an existing region
lib/lmb.c | 57 +--
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index b6afb731440..4ed60f4a843 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -130,6 +130,22 @@ static void lmb_fix_over_lap_regions(struct lmb_region
*rgn, unsigned long r1,
lmb_remove_region(rgn, r2);
}
+static long lmb_overlaps_region(struct lmb_region *rgn, phys_addr_t base,
+ phys_size_t size)
+{
+ unsigned long i;
+
+ for (i = 0; i < rgn->cnt; i++) {
+ phys_addr_t rgnbase = rgn->region[i].base;
+ phys_size_t rgnsize = rgn->region[i].size;
+
+ if (lmb_addrs_overlap(base, size, rgnbase, rgnsize))
+ break;
+ }
+
+ return (i < rgn->cnt) ? i : -1;
+}
+
void lmb_init(struct lmb *lmb)
{
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
@@ -257,7 +273,7 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
phys_size_t size, enum lmb_flags flags)
{
unsigned long coalesced = 0;
- long adjacent, i;
+ long adjacent, i, overlap;
if (rgn->cnt == 0) {
rgn->region[0].base = base;
@@ -283,19 +299,21 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
}
adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
- if (adjacent > 0) {
- if (flags != rgnflags)
- continue;
- rgn->region[i].base -= size;
- rgn->region[i].size += size;
- coalesced++;
- break;
- } else if (adjacent < 0) {
+ if (adjacent != 0) {
if (flags != rgnflags)
continue;
- rgn->region[i].size += size;
- coalesced++;
- break;
+ overlap = lmb_overlaps_region(rgn, base, size);
+ if (overlap < 0 || flags == rgn->region[overlap].flags)
{
+ /*
+* no overlap detected or overlap with same
flags detected,
+* extend region
+*/
+ if (adjacent > 0)
+ rgn->region[i].base -= size;
+ rgn->region[i].size += size;
+ coalesced++;
+ break;
+ }
} else if (lmb_addrs_overlap(base, size, rgnbase, rgnsize)) {
/* regions overlap */
return -1;
@@ -420,21 +438,6 @@ long lmb_reserve(struct lmb *lmb, phys_addr_t base,
phys_size_t size)
return lmb_reserve_flags(lmb,
Re: [PATCH 1/5] zfs: Fix malloc() success check
On Sunday, April 7th, 2024 at 4:22 AM, Igor Opaniuk
wrote:
> Hi Phaedrus,
>
> On Sun, Apr 7, 2024 at 4:00 AM mwle...@mailtundra.com wrote:
>
> > This code was hitting the error code path whenever malloc() succeeded
> > rather than when it failed, so presumably this part of the code hasn't
> > been tested. I had to apply this fix (and others) to get U-Boot to boot
> > from ZFS on an Nvidia Jetson TX2 NX SoM (an aarch64 computer).
> >
> > Signed-off-by: Phaedrus Leeds mwle...@mailtundra.com
> > Tested-by: Phaedrus Leeds mwle...@mailtundra.com
>
> It's an abuse of the Tested-by tag. If you are the author of the patch,
> that obviously implies that you tested it before sending to ML.
> Signed-off-by is enough in this case.
>
That makes sense. Sorry I'm a bit new to this way of submitting patches and
more accustomed to pull requests. It seems like a minor thing though; should I
re-submit the patches?
> ---
>
> > fs/zfs/zfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
> > index 1fec96cd5c..14779dee32 100644
> > --- a/fs/zfs/zfs.c
> > +++ b/fs/zfs/zfs.c
> > @@ -648,21 +648,21 @@ dmu_read(dnode_end_t *dn, uint64_t blkid, void **buf,
> > if (bp_array != dn->dn.dn_blkptr) {
> > free(bp_array);
> > bp_array = 0;
> > }
> >
> > if (BP_IS_HOLE(bp)) {
> > size_t size = zfs_to_cpu16(dn->dn.dn_datablkszsec,
> >
> > dn->endian)
> > << SPA_MINBLOCKSHIFT;
> > *buf = malloc(size);
> > - if (*buf) {
> > + if (!*buf) {
> > err = ZFS_ERR_OUT_OF_MEMORY;
> > break;
> > }
> > memset(*buf, 0, size);
> > endian = (zfs_to_cpu64(bp->blk_prop, endian) >>
> > 63) & 1;
> > break;
> > }
> > if (level == 0) {
> > err = zio_read(bp, endian, buf, 0, data);
> > endian = (zfs_to_cpu64(bp->blk_prop, endian) >>
> > 63) & 1;
> > --
> > 2.44.0
>
>
> --
> Best regards - Atentamente - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> https://www.linkedin.com/in/iopaniuk http://ua.linkedin.com/in/iopaniuk
[PATCH v11 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties
Add three properties for controlling alignment of partitions, aka 'entries' in fixed-partition. For now there is no explicit mention of hierarchy, so a 'section' is just the 'fixed-partitions' node. These new properties are inputs to the Binman packaging process, but are also needed if the firmware is repacked, to ensure that alignment constraints are not violated. Therefore they are provided as part of the schema. Signed-off-by: Simon Glass Reviewed-by: Rob Herring --- Changes in v11: - Drop mention of Binman - Use 'content' instead of 'contents' Changes in v10: - Update the minimum to 2 Changes in v9: - Move binding example to next batch to avoid build error Changes in v7: - Drop patch 'Add binman compatible' - Put the alignment properties into the fixed-partition binding Changes in v6: - Correct schema-validation errors missed due to older dt-schema (enum fix and reg addition) Changes in v5: - Add value ranges - Consistently mention alignment must be power-of-2 - Mention that alignment refers to bytes Changes in v2: - Fix 'a' typo in commit message .../bindings/mtd/partitions/partition.yaml| 51 +++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml index 1ebe9e2347ea..31bbeb161396 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -57,6 +57,57 @@ properties: user space from type: boolean + align: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 2 +maximum: 0x8000 +multipleOf: 2 +description: + This sets the alignment of the entry in bytes. + + The entry offset is adjusted so that the entry starts on an aligned + boundary within the containing section or image. For example ‘align = + <16>’ means that the entry will start on a 16-byte boundary. This may + mean that padding is added before the entry. The padding is part of + the containing section but is not included in the entry, meaning that + an empty space may be created before the entry starts. Alignment + must be a power of 2. If ‘align’ is not provided, no alignment is + performed. + + align-size: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 2 +maximum: 0x8000 +multipleOf: 2 +description: + This sets the alignment of the entry size in bytes. It must be a power + of 2. + + For example, to ensure that the size of an entry is a multiple of 64 + bytes, set this to 64. While this does not affect the content of the + entry itself (the padding is performed only when its parent section is + assembled), the end result is that the entry ends with the padding + bytes, so may grow. If ‘align-size’ is not provided, no alignment is + performed. + + align-end: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 2 +maximum: 0x8000 +multipleOf: 2 +description: + This sets the alignment (in bytes) of the end of an entry with respect + to the containing section. It must be a power of 2. + + Some entries require that they end on an alignment boundary, + regardless of where they start. This does not move the start of the + entry, so the content of the entry will still start at the beginning. + But there may be padding at the end. While this does not affect the + content of the entry itself (the padding is performed only when its + parent section is assembled), the end result is that the entry ends + with the padding bytes, so may grow. If ‘align-end’ is not provided, + no alignment is performed. + if: not: required: [ reg ] -- 2.34.1
[PATCH v11 2/2] dt-bindings: mtd: fixed-partition: Add binman compatibles
Add two compatibles for binman entries, as a starting point for the
schema.
Note that, after discussion on v2, we decided to keep the existing
meaning of label so as not to require changes to existing userspace
software when moving to use binman nodes to specify the firmware
layout.
Note also that, after discussion on v6, we decided to use the same
'fixed-partition' schema for the binman features, so this version
adds a new 'binman.yaml' file providing the new compatibles to the
existing partition.yaml binding.
Signed-off-by: Simon Glass
Reviewed-by: Rob Herring
---
(no changes since v10)
Changes in v10:
- Drop binman,entry since it is likely not necessary
- Put the description back
Changes in v8:
- Switch the patch ordering so the partition change comes first
Changes in v7:
- Adjust MAINTAINERS entry
- Put compatible strings into the 'fixed-partition' binding
Changes in v5:
- Add mention of why 'binman' is the vendor
- Drop 'select: false'
- Tidy up the compatible setings
- Use 'tfa-bl31' instead of 'atf-bl31'
Changes in v4:
- Correct selection of multiple compatible strings
Changes in v3:
- Drop fixed-partitions from the example
- Use compatible instead of label
Changes in v2:
- Use plain partition@xxx for the node name
.../bindings/mtd/partitions/binman.yaml | 53 +++
.../bindings/mtd/partitions/partition.yaml| 21
MAINTAINERS | 5 ++
3 files changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index ..bb4b08546184
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman entries
+
+description: |
+ This corresponds to a binman 'entry'. It is a single partition which holds
+ data of a defined type.
+
+ Binman uses the type to indicate what data file / type to place in the
+ partition. There are quite a number of binman-specific entry types, such as
+ section, fill and files, to be added later.
+
+maintainers:
+ - Simon Glass
+
+allOf:
+ - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+ compatible:
+enum:
+ - u-boot # u-boot.bin from U-Boot project
+ - tfa-bl31 # bl31.bin or bl31.elf from TF-A project
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+compatible = "u-boot";
+reg = <0x10 0xf0>;
+align-size = <0x1000>;
+align-end = <0x1>;
+};
+
+partition@20 {
+compatible = "tfa-bl31";
+reg = <0x20 0x10>;
+align = <0x4000>;
+};
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index 31bbeb161396..80d0452a2a33 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -118,3 +118,24 @@ then:
# This is a generic file other binding inherit from and extend
additionalProperties: true
+
+examples:
+ - |
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+compatible = "u-boot";
+reg = <0x10 0xf0>;
+align-size = <0x1000>;
+align-end = <0x1>;
+};
+
+partition@20 {
+compatible = "tfa-bl31";
+reg = <0x20 0x10>;
+align = <0x4000>;
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index b1b074ce2cf3..b1a4ca692578 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3684,6 +3684,11 @@ F: Documentation/filesystems/bfs.rst
F: fs/bfs/
F: include/uapi/linux/bfs_fs.h
+BINMAN
+M: Simon Glass
+S: Supported
+F: Documentation/devicetree/bindings/mtd/partitions/binman*
+
BITMAP API
M: Yury Norov
R: Rasmus Villemoes
--
2.34.1
Re: [PATCH v10 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties
Hi Miquel, On Mon, 8 Apr 2024 at 07:11, Miquel Raynal wrote: > > Hi Simon, > > s...@chromium.org wrote on Tue, 26 Mar 2024 14:06:44 -0600: > > > Add three properties for controlling alignment of partitions, aka > > 'entries' in fixed-partition. > > > > For now there is no explicit mention of hierarchy, so a 'section' is > > just the 'fixed-partitions' node. > > > > These new properties are inputs to the Binman packaging process, but are > > also needed if the firmware is repacked, to ensure that alignment > > constraints are not violated. Therefore they are provided as part of > > the schema. > > > > Signed-off-by: Simon Glass > > Reviewed-by: Rob Herring > > --- > > > > Changes in v10: > > - Update the minimum to 2 > > > > Changes in v9: > > - Move binding example to next batch to avoid build error > > > > Changes in v7: > > - Drop patch 'Add binman compatible' > > - Put the alignment properties into the fixed-partition binding > > > > Changes in v6: > > - Correct schema-validation errors missed due to older dt-schema > > (enum fix and reg addition) > > > > Changes in v5: > > - Add value ranges > > - Consistently mention alignment must be power-of-2 > > - Mention that alignment refers to bytes > > > > Changes in v2: > > - Fix 'a' typo in commit message > > > > .../bindings/mtd/partitions/partition.yaml| 51 +++ > > 1 file changed, 51 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > index 1ebe9e2347ea..656ca3db1762 100644 > > --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > @@ -57,6 +57,57 @@ properties: > >user space from > > type: boolean > > > > + align: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +minimum: 2 > > +maximum: 0x8000 > > +multipleOf: 2 > > +description: > > + This sets the alignment of the entry in bytes. > > + > > + The entry offset is adjusted so that the entry starts on an aligned > > + boundary within the containing section or image. For example ‘align = > > + <16>’ means that the entry will start on a 16-byte boundary. This may > > + mean that padding is added before the entry. The padding is part of > > + the containing section but is not included in the entry, meaning that > > + an empty space may be created before the entry starts. Alignment > > + must be a power of 2. If ‘align’ is not provided, no alignment is > > + performed. > > + > > + align-size: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +minimum: 2 > > +maximum: 0x8000 > > +multipleOf: 2 > > +description: > > + This sets the alignment of the entry size in bytes. It must be a > > power > > + of 2. > > + > > + For example, to ensure that the size of an entry is a multiple of 64 > > + bytes, set this to 64. While this does not affect the contents of the > > + entry within binman itself (the padding is performed only when its > > + parent section is assembled), the end result is that the entry ends > > + with the padding bytes, so may grow. If ‘align-size’ is not provided, > > + no alignment is performed. > > I don't think we should mention binman here. Can we have a software > agnostic description? This should be understandable from anyone playing > with mtd partitions I guess. OK > > > + > > + align-end: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +minimum: 2 > > +maximum: 0x8000 > > +multipleOf: 2 > > seems not to perfectly match the constraint, but I don't know if there > is a powerOf keyword? (same above) I believe this was discussed earlier. No there is no such option! > > > +description: > > + This sets the alignment (in bytes) of the end of an entry with > > respect > > + to the containing section. It must be a power of 2. > > + > > + Some entries require that they end on an alignment boundary, > > + regardless of where they start. This does not move the start of the > > + entry, so the contents of the entry will still start at the > > beginning. > > + But there may be padding at the end. While this does not affect the > > + contents of the entry within binman itself (the padding is performed > > content?same comment about binman? OK > > > + only when its parent section is assembled), the end result is that > > the > > + entry ends with the padding bytes, so may grow. If ‘align-end’ is not > > + provided, no alignment is performed. > > + > > if: > >not: > > required: [ reg ] Regards, SImon
Re: [PATCH] mmc: msm_sdhci: fix vendor_spec_cap0 registers
On Fri, 12 Apr 2024 20:10:21 +0200, Caleb Connolly wrote: > The addresses were mistakenly swapped. Put them right. > > Applied, thanks! [1/1] mmc: msm_sdhci: fix vendor_spec_cap0 registers commit: f09537bdd940c051b851c235e8906f1ba83233d1 Best regards, -- Caleb Connolly
Re: [PATCH 1/1] cli: always show cursor
On Fri, Mar 29, 2024 at 05:09:22PM +0100, Heinrich Schuchardt wrote: > We may enter the command line interface in a state where on the remote > console the cursor is not shown. Send an escape sequence to enable it. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fdt: Fix fdt_pack_reg() on 64-bit platforms
On Fri, Mar 29, 2024 at 07:55:53PM -0500, Sam Protsenko wrote:
> When "memory" node is being processed in fdt_pack_reg() on ARM64
> platforms, an unaligned bus access might happen, which leads to
> "synchronous abort" CPU exception. Consider next dts example:
>
> / {
> #address-cells = <2>;
> #size-cells = <1>;
>
> memory@8000 {
> device_type = "memory";
> reg = <0x0 0x8000 0x3ab0>,
> <0x0 0xc000 0x4000>,
> <0x8 0x8000 0x8000>;
> };
> };
>
> After fdt_pack_reg() reads the first addr/size entry from such memory
> node, the "p" pointer becomes 12 bytes shifted from its original value
> (8 bytes for two address cells + 4 bytes for one size cell). So now it's
> not 64-bit aligned, and an attempt to do 64-bit bus access to that
> address will cause an abort like this:
>
> "Synchronous Abort" handler, esr 0x9621, far 0xba235efc
>
> This issue was originally reported by David Virag [1] who observed it
> happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
> was observed on Samsung Exynos850 (ARM64).
>
> Fix the issue by using put_unaligned_be64() helper, which takes care of
> possible unaligned 64-bit accesses. That solution was proposed by Simon
> Glass in the original thread [1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
>
> Fixes: 739a01ed8e02 ("fdt_support: fix an endian bug of
> fdt_fixup_memory_banks")
> Suggested-by: Simon Glass
> Reported-by: David Virag
> Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
> Signed-off-by: Sam Protsenko
> Reviewed-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] test: remove unused import from pkg_resources
On Wed, Apr 03, 2024 at 01:11:41PM +0200, Heinrich Schuchardt wrote: > load_entry_point is not used. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: uniphier: Move uniphier_mem_map_init() call into dram_init()
On Fri, Apr 05, 2024 at 05:37:15PM +0900, Kunihiko Hayashi wrote: > The function uniphier_mem_map_init() is to change global variable > 'mem_map', which is referenced to get_page_table_size() to calculate > the size of page table. > > However, uniphier_mem_map_init() is called after get_page_table_size(), > so the size of page table and 'mem_map' become inconsist each other. > After all, U-Boot fails to boot on chip with memory map different from > default map, > > uniphier_mem_map_init() should be moved to dram_init(), which is > called before get_page_table_size(). > > Signed-off-by: Kunihiko Hayashi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] disk: simplify print_part_header()
On Wed, Apr 03, 2024 at 01:40:47PM +0200, Heinrich Schuchardt wrote: > Using uclass_get_name() reduces the code size. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sandbox: improve description of CONFIG_SANDBOX_CRASH_RESET
On Mon, Feb 12, 2024 at 09:37:30AM +0100, Heinrich Schuchardt wrote: > Mentions that command line option --signal is needed to make use of this > configuration option. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] sandbox: move sandbox specifics to booti_setup()
On Thu, Jan 11, 2024 at 09:03:43AM +0100, Heinrich Schuchardt wrote: > Instead of checking a configuration setting in booti_start() adjust the > sandbox implementation of booti_setup(). > > Write a console message when trying to run the booti command on the sandbox > indicating that it is not supported. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] part: Check all partitions in part_get_info_by_name()
On Thu, Mar 28, 2024 at 05:29:50PM -0500, Sam Protsenko wrote:
> In part_get_info_by_name() the inability to get some partition info
> shouldn't be a reason for dropping out of the loop. That might happen
> e.g. if the partition is hidden or unused. An example of such case are
> Samsung devices, where they use the "unused" GUID type
> (----) to indicate that the partition
> should be hidden from the OS. Such partitions might not be seen in
> "part list" output, which creates "gaps" in numbering in between of the
> visible partitions:
>
> PartStart LBA End LBA Name
> 1 0x0400 0xa3ff "efs"
> 5 0x00026420 0x00026c1f "dtbo"
> 12 0x0003f390 0x0074738f "super"
>
> In that case, the loop in part_get_info_by_name() would break after
> partition #1, so any attempt to obtain "dtbo" or "super" partition will
> fail. Fix that by continuing to iterate over the remaining partitions to
> make sure none of the visible ones is missed. That makes "part" command
> (e.g. "part start", "part size") able to work with such tables.
>
> Fixes: 87b8530fe244 ("disk: part: implement generic function
> part_get_info_by_name()")
> Signed-off-by: Sam Protsenko
> Reviewed-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] image-host: Fix error value paths and emit error messages to stderr.
On Thu, Mar 21, 2024 at 12:22:22PM +0100, Hugo Cornelis wrote: > A recent refactoring in image-host.c messed up the return values of > the function that reads the encryptiong keys. This patch fixes this > and also makes sure that error output goes to stderr instead of to > stdout. > > Signed-off-by: Hugo Cornelis Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] sandbox: missing return value checks in eth-raw-os
On Sun, Jan 07, 2024 at 09:27:12AM +0100, Heinrich Schuchardt wrote:
> We should check the return value of fcntl().
>
> Addresses-Coverity-ID: 131108 ("Unchecked return value from library")
> Addresses-Coverity-ID: 131109 ("Unchecked return value from library")
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH] event: add an event for livetree fixups
Introduce a new EVT_OF_LIVE event to allow for the livetree to be
modified before dm_init_and_scan(). Boards can perform fixups here to
handle incompatibilities between U-Boot drivers and upstream DT.
This will be used by Qualcomm platforms in future patches to enable
setting the dr_mode property if the board doesn't provide one. This has to be
set before dm_init_and_scan() is called as this property effects the binding of
drivers.
Signed-off-by: Caleb Connolly
---
common/board_r.c | 1 +
common/event.c | 2 ++
include/event.h | 12
3 files changed, 15 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index da0b80f24ff0..7d2da51193ab 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -217,8 +217,9 @@ static int initr_of_live(void)
(struct device_node **)gd_of_root_ptr());
bootstage_accum(BOOTSTAGE_ID_ACCUM_OF_LIVE);
if (ret)
return ret;
+ event_notify_null(EVT_OF_LIVE);
}
return 0;
}
diff --git a/common/event.c b/common/event.c
index 16c2ba6cc921..db32ea0d06f8 100644
--- a/common/event.c
+++ b/common/event.c
@@ -45,8 +45,10 @@ const char *const type_name[] = {
/* fdt hooks */
"ft_fixup",
+ "of_live",
+
/* main loop events */
"main_loop",
};
diff --git a/include/event.h b/include/event.h
index a8f046da3c32..c6436c07d16f 100644
--- a/include/event.h
+++ b/include/event.h
@@ -144,8 +144,20 @@ enum event_t {
* images fail.
*/
EVT_FT_FIXUP,
+ /**
+* @EVT_OF_LIVE:
+* This event is triggered when using CONFIG_OF_LIVE immediately after
+* the live tree has been created. It has no parameters, the live tree
+* can be accessed from gd->of_root, or using the of_* helpers.
+*
+* This is intended to be used for performing board specific fixups
+* on the tree before it is used by U-Boot. It is much more efficient
+* to access and modify than the FDT.
+*/
+ EVT_OF_LIVE,
+
/**
* @EVT_MAIN_LOOP:
* This event is triggered immediately before calling main_loop() which
* is the entry point of the command line. Its parameter is NULL.
--
2.44.0
Re: [PATCH 1/1] bootflow: always initialize bootflow_iter_set_dev parameters
On 2024-04-11 Nam Cao wrote:
> On 11/Apr/2024 Heinrich Schuchardt wrote:
> > method_flags may be passed uninitialized to bootflow_iter_set_dev()
> > if dev is not NULL.
> >
> > Always initialize method_flags.
> >
> > Addresses-Coverity-ID: 467057 Uninitialized scalar variable
> > Signed-off-by: Heinrich Schuchardt
>
> Reviewed-by: Nam Cao
Wait hold up.
I was curious about the Addresses-Coverity-ID thing at looked it up.
And I discovered that this patch was sent a few months a ago already [1].
What's the story here? Why is this patch resent? There was a test
failure report the last time this patch was sent, has that been
resolved yet?
Best regards,
Nam
[1] https://lore.kernel.org/u-boot/20240118173802.GA2695740@bill-the-cat/T/
> > ---
> > boot/bootflow.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/boot/bootflow.c b/boot/bootflow.c
> > index 68bf99329ab..f659a414c79 100644
> > --- a/boot/bootflow.c
> > +++ b/boot/bootflow.c
> > @@ -244,7 +244,7 @@ static int iter_incr(struct bootflow_iter *iter)
> > if (iter->flags & BOOTFLOWIF_SINGLE_DEV) {
> > ret = -ENOENT;
> > } else {
> > - int method_flags;
> > + int method_flags = 0;
> >
> > ret = 0;
> > dev = iter->dev;
> > @@ -263,7 +263,6 @@ static int iter_incr(struct bootflow_iter *iter)
> > } else if (IS_ENABLED(CONFIG_BOOTSTD_FULL) &&
> >iter->flags & BOOTFLOWIF_SINGLE_MEDIA) {
> > log_debug("next in single\n");
> > - method_flags = 0;
> > do {
> > /*
> > * Move to the next bootdev child of this media
> > @@ -305,7 +304,6 @@ static int iter_incr(struct bootflow_iter *iter)
> > }
> > } else {
> > ret = bootdev_next_prio(iter, );
> > - method_flags = 0;
> > }
> > }
> > log_debug("ret=%d, dev=%p %s\n", ret, dev,
>
Re: [PATCH] event: add an event for livetree fixups
On Fri, Apr 12, 2024 at 08:04:02PM +0100, Caleb Connolly wrote: > Introduce a new EVT_OF_LIVE event to allow for the livetree to be > modified before dm_init_and_scan(). Boards can perform fixups here to > handle incompatibilities between U-Boot drivers and upstream DT. > > This will be used by Qualcomm platforms in future patches to enable > setting the dr_mode property if the board doesn't provide one. This has to be > set before dm_init_and_scan() is called as this property effects the binding > of > drivers. This doesn't quite explain why the answer isn't "fix the device tree source" and instead "perform a live fixup". Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] net: add support to parse the NIS domain for the dhcp options
On Mon, Apr 01, 2024 at 12:13:19PM -0700, Charles Hardin wrote:
> There is code in the bootp parsing for NIS domain and add the
> same support for the dhcp options as well. This allows the same
> usage of the data when the dhcp command is used in the boot
> command.
>
> Signed-off-by: Charles Hardin
> ---
> net/bootp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/net/bootp.c b/net/bootp.c
> index 6800290963..046caf3685 100644
> --- a/net/bootp.c
> +++ b/net/bootp.c
> @@ -883,6 +883,14 @@ static void dhcp_process_options(uchar *popt, uchar *end)
> break;
> case 28:/* Ignore Broadcast Address Option */
> break;
> + case 40:/* NIS Domain name */
> + if (net_nis_domain[0] == 0) {
> + size = truncate_sz("NIS Domain Name",
> + sizeof(net_nis_domain), size);
> + memcpy(_nis_domain, ext + 2, size);
> + net_nis_domain[size] = 0;
> + }
> + break;
> #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
> case 42:/* NTP server IP */
> net_copy_ip(_ntp_server, (popt + 2));
This fails to build:
net/bootp.c: In function 'dhcp_process_options':
net/bootp.c:890:57: error: 'ext' undeclared (first use in this function)
890 | memcpy(_nis_domain, ext + 2, size);
| ^~~
net/bootp.c:890:57: note: each undeclared identifier is reported only once for
each function it appears in
--
Tom
signature.asc
Description: PGP signature
[PATCH 0/6] usb: dwc3: gadget: avoid EP command timeout
From: Alexander Sverdlin While there are happy users who successfully have been using DFU on TI AM62x [1][2], there are also others who were not so lucky up to now [3]. I felt into latter category and was wondering why I observe this: -- U-Boot SPL 2024.04-61876f393762 (Apr 11 2024 - 09:27:15 +) ... Trying to boot from DFU dwc3-generic-peripheral usb@3100: found 16 IN and 16 OUT endpoints dwc3-generic-peripheral usb@3100: Event buf 81e0a200 dma x length -2115984896 ... dwc3-generic-peripheral usb@3100: initializing ep0out ... dwc3-generic-peripheral usb@3100: initializing ep15in registering UDC driver [] dwc3-generic-peripheral usb@3100: gadget no-function data soft-connect dwc3-generic-peripheral usb@3100: Enabling ep0out dwc3-generic-peripheral usb@3100: Command Complete --> 0 dwc3-generic-peripheral usb@3100: failed to enable ep0out failed to start : -110 g_dnl_register: failed!, error: -110 g_dnl_register failedSPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### -- It turned out the timeout happened in dwc3_send_gadget_ep_cmd() on DWC3_DEPCMD_SETEPCONFIG command and while the "timeout" has been increased in Linux from 500 to 1000 and later 5000, in my case it took more than 77000 1us cycles to successfully complete. It turns out that Linux DWC3 gadget code has been improved in the meanwhile to follow DWC3 programming guide more precisely. Porting the following Linux patches solved the timeout issue in U-Boot SPL on TI AM6232. Strictly speaking "usb: dwc3: gadget: Disable GUSB2PHYCFG.SUSPHY for End Transfer" and "usb: dwc3: gadget: properly check ep cmd" are not required to tackle the observed timeout, but it keeps the whole code block in sync with Linux v6.8. Felipe Balbi (4): usb: dwc3: gadget: combine return points into a single one usb: dwc3: gadget: clear SUSPHY bit before ep cmds usb: dwc3: gadget: only resume USB2 PHY in <=HIGHSPEED usb: dwc3: gadget: properly check ep cmd Thinh Nguyen (2): usb: dwc3: gadget: Check ENBLSLPM before sending ep command usb: dwc3: gadget: Disable GUSB2PHYCFG.SUSPHY for End Transfer drivers/usb/dwc3/core.h | 2 ++ drivers/usb/dwc3/gadget.c | 47 --- 2 files changed, 46 insertions(+), 3 deletions(-) 1: https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/configs/am62x_evm_r5_usbdfu_defconfig?h=09.02.00.009 2: https://lore.kernel.org/all/20240112085317.1866449-1-sjo...@collabora.com/T/ 3: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1162644/sk-am62-am62-android-fastboot-0-issue?tisearch=e2e-sitesearch=SK-AM62 -- 2.44.0
[PATCH 4/6] usb: dwc3: gadget: Check ENBLSLPM before sending ep command
From: Thinh Nguyen
Upstream Linux commit 87dd96111b0b.
When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint
command.
Current implementation only save and restore GUSB2PHYCFG.SUSPHY
configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and
GUSB2PHYCFG.SUSPHY settings. Restore them after the command is
completed.
DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
Signed-off-by: Thinh Nguyen
Signed-off-by: Felipe Balbi
Signed-off-by: Alexander Sverdlin
---
drivers/usb/dwc3/gadget.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 00845dbadd27a..c14d7870b9461 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -301,26 +301,35 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
unsigned cmd, struct dwc3_gadget_ep_cmd_params *params)
{
u32 timeout = 500;
+ u32 saved_config = 0;
u32 reg;
- int susphy = false;
int ret = -EINVAL;
/*
-* Synopsys Databook 2.60a states, on section 6.3.2.5.[1-8], that if
-* we're issuing an endpoint command, we must check if
-* GUSB2PHYCFG.SUSPHY bit is set. If it is, then we need to clear it.
+* When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
+* GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an
+* endpoint command.
*
-* We will also set SUSPHY bit to what it was before returning as stated
-* by the same section on Synopsys databook.
+* Save and clear both GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY
+* settings. Restore them after the command is completed.
+*
+* DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
*/
if (dwc->gadget.speed <= USB_SPEED_HIGH) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
- susphy = true;
+ saved_config |= DWC3_GUSB2PHYCFG_SUSPHY;
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
}
+
+ if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) {
+ saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM;
+ reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+ }
+
+ if (saved_config)
+ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
}
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
@@ -350,9 +359,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
udelay(1);
} while (1);
- if (unlikely(susphy)) {
+ if (saved_config) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg |= DWC3_GUSB2PHYCFG_SUSPHY;
+ reg |= saved_config;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
}
--
2.44.0
[PATCH 1/6] usb: dwc3: gadget: combine return points into a single one
From: Felipe Balbi
Upstream Linux commit c0ca324d09a0.
dwc3_send_gadget_ep_cmd() had three return
points. That becomes a pain to track when we need to
debug something or if we need to add more code
before returning.
Let's combine all three return points into a single
one just by introducing a local 'ret' variable.
Signed-off-by: Felipe Balbi
Signed-off-by: Alexander Sverdlin
---
drivers/usb/dwc3/gadget.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 69d9fe40e2f87..17c19285f1c24 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -302,6 +302,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
{
u32 timeout = 500;
u32 reg;
+ int ret = -EINVAL;
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR1(ep), params->param1);
@@ -313,7 +314,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
if (!(reg & DWC3_DEPCMD_CMDACT)) {
dev_vdbg(dwc->dev, "Command Complete --> %d\n",
DWC3_DEPCMD_STATUS(reg));
- return 0;
+ ret = 0;
+ break;
}
/*
@@ -321,11 +323,15 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
* interrupt context.
*/
timeout--;
- if (!timeout)
- return -ETIMEDOUT;
+ if (!timeout) {
+ ret = -ETIMEDOUT;
+ break;
+ }
udelay(1);
} while (1);
+
+ return ret;
}
static dma_addr_t dwc3_trb_dma_offset(struct dwc3_ep *dep,
--
2.44.0
[PATCH 2/6] usb: dwc3: gadget: clear SUSPHY bit before ep cmds
From: Felipe Balbi
Upstream Linux commit 2b0f11df84bb.
Synopsys Databook 2.60a has a note that if we're
sending an endpoint command we _must_ make sure that
DWC3_GUSB2PHY(n).SUSPHY bit is cleared.
This patch implements that particular detail.
Signed-off-by: Felipe Balbi
Signed-off-by: Alexander Sverdlin
---
drivers/usb/dwc3/gadget.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 17c19285f1c24..8f6513752f085 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -302,8 +302,25 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
{
u32 timeout = 500;
u32 reg;
+
+ int susphy = false;
int ret = -EINVAL;
+ /*
+* Synopsys Databook 2.60a states, on section 6.3.2.5.[1-8], that if
+* we're issuing an endpoint command, we must check if
+* GUSB2PHYCFG.SUSPHY bit is set. If it is, then we need to clear it.
+*
+* We will also set SUSPHY bit to what it was before returning as stated
+* by the same section on Synopsys databook.
+*/
+ reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+ if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
+ susphy = true;
+ reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ }
+
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR1(ep), params->param1);
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR2(ep), params->param2);
@@ -331,6 +348,12 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
udelay(1);
} while (1);
+ if (unlikely(susphy)) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+ reg |= DWC3_GUSB2PHYCFG_SUSPHY;
+ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ }
+
return ret;
}
--
2.44.0
[PATCH 3/6] usb: dwc3: gadget: only resume USB2 PHY in <=HIGHSPEED
From: Felipe Balbi
Upstream Linux commit ab2a92e7a608.
As a micro-power optimization, let's only resume the
USB2 PHY if we're working on <=HIGHSPEED. If we're
gonna work on SUPERSPEED or SUPERSPEED+, there's no
point in resuming the USB2 PHY.
Fixes: 2b0f11df84bb ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds")
Signed-off-by: Felipe Balbi
Signed-off-by: Alexander Sverdlin
---
drivers/usb/dwc3/gadget.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8f6513752f085..00845dbadd27a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -314,11 +314,13 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
* We will also set SUSPHY bit to what it was before returning as stated
* by the same section on Synopsys databook.
*/
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
- susphy = true;
- reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ if (dwc->gadget.speed <= USB_SPEED_HIGH) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+ if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
+ susphy = true;
+ reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ }
}
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
--
2.44.0
[PATCH 6/6] usb: dwc3: gadget: Disable GUSB2PHYCFG.SUSPHY for End Transfer
From: Thinh Nguyen
Upstream Linux commit 3aa07f72894d.
If there's a disconnection while operating in eSS, there may be a delay
in VBUS drop response from the connector. In that case, the internal
link state may drop to operate in usb2 speed while the controller thinks
the VBUS is still high. The driver must make sure to disable
GUSB2PHYCFG.SUSPHY when sending endpoint command while in usb2 speed.
The End Transfer command may be called, and only that command needs to
go through at this point. Let's keep it simple and unconditionally
disable GUSB2PHYCFG.SUSPHY whenever we issue the command.
This scenario is not seen in real hardware. In a rare case, our
prototype type-c controller/interface may have a slow response
triggerring this issue.
Signed-off-by: Thinh Nguyen
Link:
https://lore.kernel.org/r/5651117207803c26e2f22ddf4e5ce9e865dcf7c7.1668045468.git.thinh.ngu...@synopsys.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Alexander Sverdlin
---
drivers/usb/dwc3/gadget.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c14d7870b9461..debfd4d6781db 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -316,7 +316,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
*
* DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
*/
- if (dwc->gadget.speed <= USB_SPEED_HIGH) {
+ if (dwc->gadget.speed <= USB_SPEED_HIGH ||
+ DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_ENDTRANSFER) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
saved_config |= DWC3_GUSB2PHYCFG_SUSPHY;
--
2.44.0
[PATCH 5/6] usb: dwc3: gadget: properly check ep cmd
From: Felipe Balbi Upstream Linux commit 514f227b. The cmd argument we pass to dwc3_send_gadget_ep_cmd() could contain extra arguments embedded. When checking for StartTransfer command, we need to make sure to match only lower 4 bits which contain the actual command and ignore the rest. Reported-by: Janusz Dziedzic Signed-off-by: Felipe Balbi [A. Sverdlin: cherry-picked only DWC3_DEPCMD_CMD() define] Signed-off-by: Alexander Sverdlin --- drivers/usb/dwc3/core.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 1e7eda89a34c9..7709ab793f36d 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -405,6 +405,8 @@ #define DWC3_DEPCMD_SETTRANSFRESOURCE (0x02 << 0) #define DWC3_DEPCMD_SETEPCONFIG(0x01 << 0) +#define DWC3_DEPCMD_CMD(x) ((x) & 0xf) + /* The EP number goes 0..31 so ep0 is always out and ep1 is always in */ #define DWC3_DALEPENA_EP(n)(1 << n) -- 2.44.0
Re: [PATCH v4 4/7] arm: dts: k3-am625-sk: Enable usb port in u-boot
Hi Sjoerd!
On Fri, 2024-01-12 at 09:52 +0100, Sjoerd Simons wrote:
> Enable usb0 in all boot phases for use with DFU
>
> Signed-off-by: Sjoerd Simons
Reviewed-by: Alexander Sverdlin
> ---
>
> Changes in v4:
> - Don't force usb0 into peripheral mode
>
> Changes in v3:
> - Enable usb nodes in all boot phases
>
> Changes in v2:
> - Only enable usb port 0 DFU in SPL
>
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index fa778b0ff4c..67c9fa2bbc3 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -46,3 +46,11 @@
> _port2 {
> status = "disabled";
> };
> +
> + {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +};
--
Alexander Sverdlin
Siemens AG
www.siemens.com
Re: [PATCH v4 2/7] usb: dwc3: Switch to device mode on gadget start
Hi Sjoerd! On Fri, 2024-01-12 at 09:52 +0100, Sjoerd Simons wrote: > When dr_mode is "otg" the dwc3 is initially configured in _OTG mode; > However in this mode the gadget functionality doesn't work without > further configuration. To resolve that on gadget start switch to _DEVICE > mode globally and go back to _OTG on stop again. > > For this the dwc3_set_mode is renamed to dwc3_core_set_mode to avoid a > conflict with the same function exposed by xhci-dwc3 > > Signed-off-by: Sjoerd Simons > Reviewed-by: Mattijs Korpershoek Works for me with both dr_mode "otg" and "peripheral" on AM6232: Tested-by: Alexander Sverdlin > --- > > Changes in v4: > - New patch > > drivers/usb/dwc3/core.c | 10 +- > drivers/usb/dwc3/core.h | 1 + > drivers/usb/dwc3/gadget.c | 6 ++ > 3 files changed, 12 insertions(+), 5 deletions(-) -- Alexander Sverdlin Siemens AG www.siemens.com
[PATCH] mmc: msm_sdhci: fix vendor_spec_cap0 registers
The addresses were mistakenly swapped. Put them right.
Reported-by: Sumit Garg
Fixes: a737d8962cae ("mmc: msm_sdhci: correct vendor_spec_cap0 register for v5")
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 2144772ac325..5e9d66526a83 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -255,15 +255,15 @@ static int msm_sdc_bind(struct udevice *dev)
static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
.mci_removed = false,
- .core_vendor_spec_capabilities0 = 0x21c,
+ .core_vendor_spec_capabilities0 = 0x11c,
};
static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
.mci_removed = true,
- .core_vendor_spec_capabilities0 = 0x11c,
+ .core_vendor_spec_capabilities0 = 0x21c,
};
static const struct udevice_id msm_mmc_ids[] = {
{ .compatible = "qcom,sdhci-msm-v4", .data = (ulong)_sdhc_mci_var },
--
2.44.0
Re: [PATCH v4 0/6] USB keyboard improvements for asahi / desktop systems
On 4/12/24 2:53 PM, Marek Vasut wrote: Hi, Seems to work here with a broken imx8 config from the CI. Is it ok to rely on dead code elimination? Apparently it is, build with KCFLAGS=-O0 has already several other missing symbols. See attached fixup Thanks, squashed, let's see how CI likes this. I think we are getting closer, but still ... Pipeline #20308 has failed! Project: USB U-Boot Custodian Tree ( https://source.denx.de/u-boot/custodians/u-boot-usb ) Branch: master ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/commits/master ) Commit: 63f6a449 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/commit/63f6a449bffe46beca89580d3efa48e5d041025c ) Commit Message: usb: kbd: Add probe quirk for Apple and Keychro... Commit Author: Janne Grunau Committed by: Marek Vasut ( https://source.denx.de/marex ) Pipeline #20308 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/pipelines/20308 ) triggered by Marek Vasut ( https://source.denx.de/marex ) had 1 failed job. Job #815411 ( https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/815411/raw ) Stage: world build Name: build all 64bit ARM platforms
Re: [PATCH v4 0/6] USB keyboard improvements for asahi / desktop systems
On Fri, Apr 12, 2024 at 08:26:18PM +0200, Marek Vasut wrote: > On 4/12/24 2:53 PM, Marek Vasut wrote: > > Hi, > > > > Seems to work here with a broken imx8 config from the CI. Is it ok to > > > rely on dead code elimination? Apparently it is, build with KCFLAGS=-O0 > > > has already several other missing symbols. > > > > > > See attached fixup > > > > Thanks, squashed, let's see how CI likes this. > > I think we are getting closer, but still ... > > Pipeline #20308 has failed! > > Project: USB U-Boot Custodian Tree ( > https://source.denx.de/u-boot/custodians/u-boot-usb ) > Branch: master ( > https://source.denx.de/u-boot/custodians/u-boot-usb/-/commits/master ) > > Commit: 63f6a449 ( > https://source.denx.de/u-boot/custodians/u-boot-usb/-/commit/63f6a449bffe46beca89580d3efa48e5d041025c > ) > Commit Message: usb: kbd: Add probe quirk for Apple and Keychro... > Commit Author: Janne Grunau > Committed by: Marek Vasut ( https://source.denx.de/marex ) > > > Pipeline #20308 ( > https://source.denx.de/u-boot/custodians/u-boot-usb/-/pipelines/20308 ) > triggered by Marek Vasut ( https://source.denx.de/marex ) > had 1 failed job. > > Job #815411 ( > https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/815411/raw ) > > Stage: world build > Name: build all 64bit ARM platforms That looks like the machine doing the build failed, I've kicked the retry button. -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] zfs: Fix unaligned read of uint64
Hi Phaedrus,
On 07/04/2024 03:47, mwle...@mailtundra.com wrote:
Without this patch, when trying to boot zfs using U-Boot on a Jetson TX2
NX (which is aarch64), I get a CPU reset error like so:
"Synchronous Abort" handler, esr 0x9621
elr: 800c9000 lr : 800c8ffc (reloc)
elr: fff77000 lr : fff76ffc
x0 : ffb40f04 x1 :
x2 : 000a x3 : 0310
x4 : 0310 x5 : 0034
x6 : fff9cc6e x7 : 000f
x8 : ff7f84a0 x9 : 0008
x10: ffb40f04 x11: 0006
x12: 0001869f x13: 0001
x14: ff7f84bc x15: 0010
x16: 2080 x17: 001f
x18: ff7fbdd8 x19: ffb405f8
x20: ffb40dd0 x21: fffabe5e
x22: 00ea7794 x23: ffb42090
x24: x25:
x26: x27:
x28: 00bab10c x29: ff7f85f0
Code: d1a0 9103a000 94006ac6 f9401ba0 (f940)
Resetting CPU ...
This happens when be64_to_cpu() is called on a value that exists at a
memory address that's 4 byte aligned but not 8 byte aligned (e.g. an
address ending in 04). The call stack where that happens is:
check_pool_label() ->
zfs_nvlist_lookup_uint64(vdevnvlist, ZPOOL_CONFIG_ASHIFT,...) ->
be64_to_cpu()
This is very odd, aarch64 doesn't generally have these restrictions. I
got a bit nerdsniped when I saw this so I did some digging and figured this:
1. Your abort exception doesn't include the FAR_ELx register (which
should contain the address that was being accessed when the abort
occured). This means your board is running in EL3.
2. It turns out there is an "A" flag in the SCTLR_ELx register, when set
this flag causes a fault when trying to load from an address that isn't
aligned to the size of the data element (see "A, bit" on
https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/SCTLR-EL3--System-Control-Register--EL3-
I'm not sure who's in the "wrong" here, maybe the driver should avoid
unaligned accesses? But then again, I don't think you should be running
a ZFS driver in EL3.
I'm not familiar with the Jetson Nano, but maybe there's a documented
way to run U-Boot so that it isn't executing in EL3? Or if not you could
also try unsetting the A flag.
If this really is something to fix in the driver, I don't think
hotpatching every unaligned access with a malloc() is the right solution.
Signed-off-by: Phaedrus Leeds
Tested-by: Phaedrus Leeds
regarding your question about re-sending to remove these tags, I'd say
probably yes, and especially if you're going to send a new revision anyway.
fwiw you seem to have gotten pretty much everything else about the patch
submission process spot on :)
Kind regards,
---
fs/zfs/zfs.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
index 61d58fce68..9a50deac18 100644
--- a/fs/zfs/zfs.c
+++ b/fs/zfs/zfs.c
@@ -1552,35 +1552,53 @@ nvlist_find_value(char *nvlist, char *name, int
valtype, char **val,
if (nelm_out)
*nelm_out = nelm;
return 1;
}
nvlist += encode_size; /* goto the next nvpair */
}
return 0;
}
+int is_word_aligned_ptr(void *ptr) {
+ return ((uintptr_t)ptr & (sizeof(void *) - 1)) == 0;
+}
+
int
zfs_nvlist_lookup_uint64(char *nvlist, char *name, uint64_t *out)
{
char *nvpair;
size_t size;
int found;
found = nvlist_find_value(nvlist, name, DATA_TYPE_UINT64, , , 0);
if (!found)
return 0;
if (size < sizeof(uint64_t)) {
printf("invalid uint64\n");
return ZFS_ERR_BAD_FS;
}
+ /* On arm64, calling be64_to_cpu() on a value stored at a memory address
+* that's not 8-byte aligned causes the CPU to reset. Avoid that by
copying the
+* value somewhere else if needed.
+*/
+ if (!is_word_aligned_ptr((void *)nvpair)) {
+ uint64_t *alignedptr = malloc(sizeof(uint64_t));
+ if (!alignedptr)
+ return 0;
+ memcpy(alignedptr, nvpair, sizeof(uint64_t));
+ *out = be64_to_cpu(*alignedptr);
+ free(alignedptr);
+ return 1;
+ }
+
*out = be64_to_cpu(*(uint64_t *) nvpair);
return 1;
}
char *
zfs_nvlist_lookup_string(char *nvlist, char *name)
{
char *nvpair;
char *ret;
size_t slen;
--
// Caleb (they/them)
Re: [PATCH 3/5] zfs: Fix unaligned read of uint64
On 12/04/2024 20:50, Caleb Connolly wrote:
Hi Phaedrus,
On 07/04/2024 03:47, mwle...@mailtundra.com wrote:
Without this patch, when trying to boot zfs using U-Boot on a Jetson TX2
NX (which is aarch64), I get a CPU reset error like so:
"Synchronous Abort" handler, esr 0x9621
elr: 800c9000 lr : 800c8ffc (reloc)
elr: fff77000 lr : fff76ffc
x0 : ffb40f04 x1 :
x2 : 000a x3 : 0310
x4 : 0310 x5 : 0034
x6 : fff9cc6e x7 : 000f
x8 : ff7f84a0 x9 : 0008
x10: ffb40f04 x11: 0006
x12: 0001869f x13: 0001
x14: ff7f84bc x15: 0010
x16: 2080 x17: 001f
x18: ff7fbdd8 x19: ffb405f8
x20: ffb40dd0 x21: fffabe5e
x22: 00ea7794 x23: ffb42090
x24: x25:
x26: x27:
x28: 00bab10c x29: ff7f85f0
Code: d1a0 9103a000 94006ac6 f9401ba0 (f940)
Resetting CPU ...
This happens when be64_to_cpu() is called on a value that exists at a
memory address that's 4 byte aligned but not 8 byte aligned (e.g. an
address ending in 04). The call stack where that happens is:
check_pool_label() ->
zfs_nvlist_lookup_uint64(vdevnvlist, ZPOOL_CONFIG_ASHIFT,...) ->
be64_to_cpu()
This is very odd, aarch64 doesn't generally have these restrictions. I
got a bit nerdsniped when I saw this so I did some digging and figured
this:
1. Your abort exception doesn't include the FAR_ELx register (which
should contain the address that was being accessed when the abort
occured). This means your board is running in EL3.
2. It turns out there is an "A" flag in the SCTLR_ELx register, when set
this flag causes a fault when trying to load from an address that isn't
aligned to the size of the data element (see "A, bit" on
https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/SCTLR-EL3--System-Control-Register--EL3-
I'm not sure who's in the "wrong" here, maybe the driver should avoid
unaligned accesses? But then again, I don't think you should be running
a ZFS driver in EL3.
I'm not familiar with the Jetson Nano, but maybe there's a documented
way to run U-Boot so that it isn't executing in EL3? Or if not you could
also try unsetting the A flag.
If this really is something to fix in the driver, I don't think
hotpatching every unaligned access with a malloc() is the right solution.
Signed-off-by: Phaedrus Leeds
Tested-by: Phaedrus Leeds
regarding your question about re-sending to remove these tags, I'd say
probably yes, and especially if you're going to send a new revision anyway.
fwiw you seem to have gotten pretty much everything else about the patch
submission process spot on :)
Oh, by the way, instead of Tested-by tags, can you add Fixes tags on the
patches that contain bug fixes?
In case you're unfamiliar, you can generate them like this:
$ git config --global pretty.fixes = "Fixes: %h (\"%s\")"
$ git log --oneline --pretty=fixes
Probably for all of yours that will be:
Fixes: 4d3c95f5ea7c ("zfs: Add ZFS filesystem support")
Kind regards,
---
fs/zfs/zfs.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
index 61d58fce68..9a50deac18 100644
--- a/fs/zfs/zfs.c
+++ b/fs/zfs/zfs.c
@@ -1552,35 +1552,53 @@ nvlist_find_value(char *nvlist, char *name,
int valtype, char **val,
if (nelm_out)
*nelm_out = nelm;
return 1;
}
nvlist += encode_size; /* goto the next nvpair */
}
return 0;
}
+int is_word_aligned_ptr(void *ptr) {
+ return ((uintptr_t)ptr & (sizeof(void *) - 1)) == 0;
+}
+
int
zfs_nvlist_lookup_uint64(char *nvlist, char *name, uint64_t *out)
{
char *nvpair;
size_t size;
int found;
found = nvlist_find_value(nvlist, name, DATA_TYPE_UINT64,
, , 0);
if (!found)
return 0;
if (size < sizeof(uint64_t)) {
printf("invalid uint64\n");
return ZFS_ERR_BAD_FS;
}
+ /* On arm64, calling be64_to_cpu() on a value stored at a memory
address
+ * that's not 8-byte aligned causes the CPU to reset. Avoid that
by copying the
+ * value somewhere else if needed.
+ */
+ if (!is_word_aligned_ptr((void *)nvpair)) {
+ uint64_t *alignedptr = malloc(sizeof(uint64_t));
+ if (!alignedptr)
+ return 0;
+ memcpy(alignedptr, nvpair, sizeof(uint64_t));
+ *out = be64_to_cpu(*alignedptr);
+ free(alignedptr);
+ return 1;
+ }
+
*out = be64_to_cpu(*(uint64_t *) nvpair);
return 1;
}
char *
zfs_nvlist_lookup_string(char *nvlist, char *name)
{
char *nvpair;
char *ret;
size_t slen;
--
// Caleb (they/them)
Re: [PATCH v4 3/7] board: ti: am62x: am62x: include env for DFU
Hi Sjoerd! On Fri, 2024-01-12 at 09:52 +0100, Sjoerd Simons wrote: > Include standard TI K3 dfu environment > > Signed-off-by: Sjoerd Simons > Reviewed-by: Mattijs Korpershoek Reviewed-by: Alexander Sverdlin > --- > > (no changes since v3) > > Changes in v3: > - Add dfu via environment rather then config headers > > Changes in v2: > - Minimize config changes to just DFU configuration > > board/ti/am62x/am62x.env | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env > index e53a55c38fb..0651b9cd7cb 100644 > --- a/board/ti/am62x/am62x.env > +++ b/board/ti/am62x/am62x.env > @@ -1,6 +1,7 @@ > #include > #include > #include > +#include > > name_kern=Image > console=ttyS2,115200n8 -- Alexander Sverdlin Siemens AG www.siemens.com
Re: [PATCH v4 1/7] usb: dwc3: Add dwc3 glue driver for am62
Hi Sjoerd! Thank you for your efforts on the topic! On Fri, 2024-01-12 at 09:52 +0100, Sjoerd Simons wrote: > Add glue code for TI AM62 to the dwc3 driver; Most code adopted from > TI vendor u-boot code. > > Signed-off-by: Sjoerd Simons > Reviewed-by: Mattijs Korpershoek Works for me on AM6232: Tested-by: Alexander Sverdlin > --- > > Changes in v4: > - Add config dependency on SYSCON > - Move defines and constants outside out of function scope > > Changes in v2: > - Switch dwc3 glue to a seperate driver rather then in dwc-generic > > drivers/usb/dwc3/Kconfig | 14 > drivers/usb/dwc3/Makefile | 1 + > drivers/usb/dwc3/dwc3-am62.c | 125 +++ > 3 files changed, 140 insertions(+) > create mode 100644 drivers/usb/dwc3/dwc3-am62.c -- Alexander Sverdlin Siemens AG www.siemens.com
Re: Can't get U-Boot working on Geniatech XPI-3566-ZERO
Hi Jonas,
thank You, i tried my best to follow your hints as good as possible. This is
what i did:
- git clone https://github.com/rockchip-linux/rkbin
- git clone https://github.com/u-boot/u-boot
- modified the following files:
```
diff --git a/arch/arm/dts/rk3568-generic.dts b/arch/arm/dts/rk3568-generic.dts
index 88eb1bfd..847ebd51 100644
--- a/arch/arm/dts/rk3568-generic.dts
+++ b/arch/arm/dts/rk3568-generic.dts
@@ -16,7 +16,7 @@
};
chosen {
- stdout-path = "serial2:150n8";
+ stdout-path = "serial1:150n8";
};
};
@@ -43,6 +43,7 @@
status = "okay";
};
- {
+ {
status = "okay";
};
+
diff --git a/configs/generic-rk3568_defconfig b/configs/generic-rk3568_defconfig
index e7d5e55b..aeb117e7 100644
--- a/configs/generic-rk3568_defconfig
+++ b/configs/generic-rk3568_defconfig
@@ -6,7 +6,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_DEFAULT_DEVICE_TREE="rk3568-generic"
CONFIG_ROCKCHIP_RK3568=y
CONFIG_SPL_SERIAL=y
-CONFIG_DEBUG_UART_BASE=0xFE66
+CONFIG_DEBUG_UART_BASE=0xFE65
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_SYS_LOAD_ADDR=0xc00800
CONFIG_DEBUG_UART=y
```
- modified this file:
```
diff --git a/tools/ddrbin_param.txt b/tools/ddrbin_param.txt
index 0dfdd31..826f927 100644
--- a/tools/ddrbin_param.txt
+++ b/tools/ddrbin_param.txt
@@ -9,7 +9,7 @@ lp4_freq=
lp4x_freq=
lp5_freq=
-uart id=
+uart id=1
uart iomux=
uart baudrate=
```
- Runned the following command:
# ./ddrbin_tool rk3566 ddrbin_param.txt
~/rkbin/bin/rk35/rk3566_ddr_920MHz_v1.21.bin
version v1.19 20240117
chip rk3566
version 5
new bin config:
uart id: 1
modify end
The file modification date changed, so i assume it should be ok.
- Runned the following commands:
# CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make generic-rk3568_defconfig
O="build/generic-rk3568_defconfig"
#ROCKCHIP_TPL='~/rkbin/bin/rk35/rk3566_ddr_920MHz_v1.21.bin'
BL31='~/rkbin/bin/rk35/rk3568_bl31_v1.44.elf' CROSS_COMPILE=aarch64-linux-gnu-
make O="build/generic-rk3568_defconfig"
I have acquired the MiniLoaderAll.bin via extracting the official update.img
from the vendor.
# rkdeveloptool db MiniLoaderAll.bin
# rkdeveloptool wl 64
'~/u-boot/build/generic-rk3568_defconfig/u-boot-rockchip.bin'
- Then i have connected my USB-UART adapter to
BOARD PIN 8 (GND) -> USB UART PIN GND
BOARD PIN 10 (UART1_TX) -> USB UART PIN RX
BOARD PIN 12 (UART1_RX) -> USB UART PIN TX
- Started minicom:
# minicom -D /dev/ttyUSB0 -b 150
But i still don't get any output at all.
Any idea what iam i doing wrong here?
Best Regards,
-- ext
Jonas Karlman írta 2024. ápr.. 8, H-n 21:31 órakor:
> Hi Z,
>
> On 2024-04-08 09:40, Mizsei Zoltán wrote:
>> Hi,
>>
>> I'm trying to get a mainline U-Boot running on the Geniatech XPI-3566-ZERO
>> RK3566 based SBC [1], but all my attempts have failed so far.
>>
>> The SBC doesn't have any SD-Card slot, please keep this in mind!
>>
>> I can build U-Boot, but when I write the resulting binary to the eMMC using
>> rkdeveloptool, the boot stops and I see no output on the UART pins using
>> 150 baud transfer rate.
>>
>> My steps were the following:
>>
>> - git clone https://github.com/u-boot/u-boot
>> - cd u-boot
>> - CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rk3568_defconfig
>
> There is no rk3568_defconfig target but generic-rk3568_defconfig may
> work better.
>
>> - ROCKCHIP_TPL='rkbin/bin/rk35/rk3566_ddr_1056MHz_v1.21.bin'
>> BL31='rkbin/bin/rk35/rk3568_bl31_v1.44.elf' CROSS_COMPILE=aarch64-linux-gnu-
>> make
>> - rkdeveloptool db MiniLoaderAll.bin
>> - rkdeveloptool wl 64 u-boot-rockchip.bin
>>
>> After that I can no longer communicate with the board via UART and it no
>> longer boots.
>
> After looking at the specification for this board it looks like GPIO
> pin 8 and 10 is connected to uart1 and not uart2 that is typically used
> for debug uart on rockchip devices.
>
>>
>> I've built uboot countless times, I've followed all sorts of guides, I've
>> tried modifying FDT and transplanting the DTS from the official SDK, I have
>> tried vanilla defconfigs and tried to modify them aswell, I think I've tried
>> everything, but no matter what I do I just can't get it working.
>> The vendored U-Boot works ok, but I plant to run OpenBSD, for which an
>> upstream U-Boot would be better situated (according to the OBSD mailing
>> list).
>>
>> Please give me some hints because I'm running out of ideas. I've spent
>> countless hours trying to get this to work but haven't succeeded.
>
> You can try changing stdout-path to "serial1:150n8" and enable the
> uart1 node in generic-rk3568.dts.
> Also change to CONFIG_DEBUG_UART_BASE=0xFE65, and also use rkbin
> tools/ddrbin_tool and change to use uart1 on ddr bin.
>
> After that you should probably start seeing something on uart and that
> may help you get a little bit further.
>
> Regards,
> Jonas
>
>>
>> Thank You very much!
>>
>> Best Regards,
>>
>> --Z--
>>
>> [1]
[PATCH] mmc: sdhci: programmable clock calculation needs multiplier +1
From: cmachida
According to the SD Host Controller Simplified Specification v4.20,
the multiplier value M is one more than the Clock Multiplier field.
Copied code from Linux project. drivers/mmc/host/sdhci.c line 4405
Signed-off-by: cmachida
---
drivers/mmc/sdhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0178ed8a11..a8476ec4e9 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -929,6 +929,15 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
debug("%s, caps_1: 0x%x\n", __func__, caps_1);
host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
SDHCI_CLOCK_MUL_SHIFT;
+
+ /*
+* In case the value in Clock Multiplier is 0, then programmable
+* clock mode is not supported, otherwise the actual clock
+* multiplier is one more than the value of Clock Multiplier
+* in the Capabilities Register.
+*/
+ if (host->clk_mul)
+ host->clk_mul += 1;
}
if (host->max_clk == 0) {
--
2.43.2
[PATCHv2] net: add support to parse the NIS domain for the dhcp options
There is code in the bootp parsing for NIS domain and add the
same support for the dhcp options as well. This allows the same
usage of the data when the dhcp command is used in the boot
command.
Signed-off-by: Charles Hardin
---
net/bootp.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/bootp.c b/net/bootp.c
index 6800290963..c15472f5d3 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -883,6 +883,14 @@ static void dhcp_process_options(uchar *popt, uchar *end)
break;
case 28:/* Ignore Broadcast Address Option */
break;
+ case 40:/* NIS Domain name */
+ if (net_nis_domain[0] == 0) {
+ size = truncate_sz("NIS Domain Name",
+ sizeof(net_nis_domain), size);
+ memcpy(_nis_domain, popt + 2, size);
+ net_nis_domain[size] = 0;
+ }
+ break;
#if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
case 42:/* NTP server IP */
net_copy_ip(_ntp_server, (popt + 2));
--
2.39.3 (Apple Git-146)
Re: [PATCH v1] net: designware: Pass all multicast frames in designware driver
On Mon, 08 Apr 2024 16:50:17 +0800, Jim Liu wrote: > Allowing multicast packets is required for IPv6 neighbor discovery > protocol. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] net: designware: Invalidate RX buffer cache before freeing the DMA descriptor
On Mon, 08 Apr 2024 16:49:02 +0800, Jim Liu wrote: > In IPv6 context, the ICMP and UDP checksum byte in the RX packet > is initially set to 0, recaclculated, and then re-inserted. > This process can result in a dirty cache line. To prevent issues, > it is essential to invalidate cache for the RX buffer before freeing > the descriptor for next DMA transfer. > This ensure that the dirty cache line doesn't inadvertently written back > due to cache eviction, there by corrupting the RX buffer > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] net: dwc_eth_qos: Fix compilation warning in eqos_free_pkt()
On Fri, 05 Apr 2024 18:15:29 +0200, Patrice Chotard wrote:
> Fix compilation warning:
>
> ../arch/arm/include/asm/io.h: In function 'eqos_free_pkt':
> ../arch/arm/include/asm/io.h:103:32: warning: 'rx_desc' may be used
> uninitialized [-Wmaybe-uninitialized]
> 103 | #define writel(v,c) ({ u32 __v = v; __iowmb();
> __arch_putl(__v,c); __v; })
> |^~~
> ../drivers/net/dwc_eth_qos.c:1220:27: note: 'rx_desc' was declared here
> 1220 | struct eqos_desc *rx_desc;
> | ^~~
>
> [...]
Applied to u-boot/master, thanks!
--
Tom
Re: [PATCH v5 0/5] Introduce ICSSG Ethernet driver
On Thu, 04 Apr 2024 12:37:58 +0530, MD Danish Anwar wrote: > Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI > AM654 SR2.0. > > The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces > support for ICSSG driver in uboot. > > This series has been tested on AM65x SR2.0, and the ICSSG interface is > able to ping / dhcp and boot kernel using tftp in uboot. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 01/13] ti:keys Add EFI signature list
Ilias Apalodimas writes: > Hi Jon, > > > On Wed, 10 Apr 2024 at 20:35, Jon Humphreys wrote: >> >> Ilias Apalodimas writes: >> >> > On Tue, 9 Apr 2024 at 23:14, Andrew Davis wrote: >> >> >> >> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote: >> >> > On 4/9/24 14:14, Andrew Davis wrote: >> >> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote: >> >> >>> On 4/8/24 23:33, Jonathan Humphreys wrote: >> >> EFI signature list using TI dummy keys. >> >> >>> >> >> >>> Adding vendor public keys into the code base to lock down generated >> >> >>> binaries to the vendors unpublished private key does not match well >> >> >>> with >> >> >>> the intent of the GNU public license. >> >> >>> >> >> >> >> >> >> The matching private keys are already published in this same >> >> >> repo/directory (arch/arm/mach-k3/keys). >> >> >> >> >> >> Andrew >> >> > >> >> > Why should we create signed capsules which are already compromised by >> >> > publishing the private key? >> >> > >> >> >> >> If you buy these devices you have two options, you can burn real >> >> keys, or you can burn these dummy keys. If you burn dummy keys >> >> then these images will boot and so will any image you or anyone >> >> else wants to boot on the device. (since the keys are published >> >> anyone can make images for them, that is how we do GP (general >> >> purpose) devices these days) >> >> >> >> If you burn your own keys, then you switch out these keys here >> >> and your device will only boot images that you permit by signing >> >> with your keys. >> > >> > I am not sure I am following you here. We don't burn anything in the >> > case of EFI keys. They are placed in an elf section and we assume the >> > device will have a chain of trust enabled, naturally verifying those >> > keys along with the u-boot binary. >> > >> >> >> >> You'll find plenty of open source projects do the same and >> >> give out example keys to show how to use real keys, even >> >> official GNU projects. >> > >> > Yes, but the keys defined here are useless unless you have a default >> > defconfig that uses them and embeds them in the binary. I am not cc'ed >> > in all the patches of the series, is that added somewhere? And if you >> >> Yes, they are part of this series >> https://lore.kernel.org/r/20240408213349.96610-1-j-humphr...@ti.com. >> Thanks for the reviews. >> >> > unconditionally enable secure boot It would be far more interesting to >> > embed the MS SHIM key along with that special key you are trying to >> > define, so that firmware can boot COTS distros as well >> >> Yes, we should consider. But since that is outside of the EFI capsule >> use case, I would rather take it up in a separate patch. > > Ok, the commit message wasn't clear, and based on Andrews's initial > response I thought you wanted to use those for UEFI secure boot, not > capsule updates. > Those are your boards so I won't NAK this, but I'd strongly advise > *not* to add this. I assume you want capsule auth by default because > SystemReady-IR >=2.0 mandates it? > > In that case, it would be a far better idea to document the process of > creating signed capsules clearly either in U-Boots EFI docs and/or > your board docs. > I am pretty confident that if we merge this now we will have future > products using the keys above Thanks Ilias. If I understand you correctly, I don't agree with the approach of not having a working implementation so that developers are forced to think through their support. Not having a feature enabled in upstream leads to latent bugs, bit rot, lack of coordination and openess, etc. It worries me that there are so many claims of authenticated capsule support but nothing in upstream on those devices. But I absolutely acknowledge your concern that if we make this 'just work' then developers will overlook the details and not properly secure their solutions. What I suggest to mitigate this: 1) as you say, add documentation, including a 'porting guide' section so developers know what steps they need to take, and 2) Add a developer config that is set by default. With this config set, during capsule updates, emit a warning message that instructs them to read the porting section of the doc to ensure they have secured their solution. To remove the warning, a developer would follow the porting guidelines and then unset the "developer config" configuration to signify they have secured the solution. This is what optee does, emitting the below during boot, until the config is unset: I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html Last, I am pondering the idea of not including the actual .esl certificate, but rather adding a make step that would generate the certificate from a given keypair. For the TI upstream implementation, we would point to the open developer keys already being used to demonstrate secure boot. As part of porting, the
Re: [PATCH v2 01/16] board: Define GUIDs for firmware images
Ilias Apalodimas writes: > Hi both > > On Wed, 10 Apr 2024 at 10:36, Heinrich Schuchardt wrote: >> >> On 09.04.24 23:05, Jon Humphreys wrote: >> > Heinrich Schuchardt writes: >> > >> >> On 4/9/24 00:31, Jonathan Humphreys wrote: >> >>> Define GUIDs for the different firmware images (tiboot3.bin, tispl.bin, >> >>> u-boot.img, sysfw). > >> >>> Signed-off-by: Jonathan Humphreys >> >>> --- >> >>>include/configs/ti_armv7_common.h | 17 + >> >>>1 file changed, 17 insertions(+) >> >>> >> >>> diff --git a/include/configs/ti_armv7_common.h >> >>> b/include/configs/ti_armv7_common.h >> >>> index 3def7b1027e..4ce14a9b84c 100644 >> >>> --- a/include/configs/ti_armv7_common.h >> >>> +++ b/include/configs/ti_armv7_common.h >> >>> @@ -16,6 +16,23 @@ >> >>>#ifndef __CONFIG_TI_ARMV7_COMMON_H__ >> >>>#define __CONFIG_TI_ARMV7_COMMON_H__ >> >>> >> >>> +/* GUIDs for capsule updatable firmware images */ >> >> >> >> Please, provide code comments for the GUIDs, e.g. >> >> >> >> /** >> >>* define K3_TIBOOT3_IMAGE_GUID - firmware GUID for K3 tiboot3.bin >> >>* >> >>* This GUID is used in capsules updates to identify the tiboot3.bin >> >>* binary. >> >>*/ > > I'd go one step further tbh. Those GUIDs can be used by OEMs/ODMs > producing capsules for their future products. > Currently, we don't have a documented way to allow users to redefine > this (but Linaro is working on it). If both TI and an OEM use the > same GUID and try to upload the firmware to LVFS, we will have a GUID > clash. > I think we should have that on the comment as well, until we can > properly sort it out Ilias, I realized I may have defined the GUID's a bit incorrectly. I was thinking that the GUID's identify the firmware type (eg, SPL vs Uboot for TI devices). However, the SPL binary for say am62 will be different than the SPL binary for say am64, so I should have unique GUID's per firmware type *per board*. Correct? If so, I'll need to move these definitions to the board .h files, and my generic capsule binman nodes will need to have each board override the image GUID used. thanks Jon > > Thanks > /Ilias >> >> >> >> Cf. >> >> https://docs.kernel.org/doc-guide/kernel-doc.html#object-like-macro-documentation >> >> >> >> Best regards >> >> >> >> Heinrich >> >> >> > >> > Heinrich, thanks for reviewing! >> > >> > I modelled the GUID macros after how other boards and even core code >> > defined there's. (eg, include/configs/kontron-sl-mx8mm.h or >> > include/efi_api.h). >> > >> > However, if this is the new direction, I will format as you suggest. >> > Please confirm. >> >> Hello Jon, >> >> Without properly documenting macros we make the live of developers more >> difficult. Yes, we still have a lot of missing code documentation. But >> we should not follow poor example. >> >> Best regards >> >> Heinrich >> >> > >> > thanks >> > Jon >> > >> >>> +#define K3_TIBOOT3_IMAGE_GUID \ >> >>> + EFI_GUID(0xe672b518, 0x7cd7, 0x4014, 0xbd, 0x8d, \ >> >>> +0x40, 0x72, 0x4d, 0x0a, 0xd4, 0xdc) >> >>> + >> >>> +#define K3_SPL_IMAGE_GUID \ >> >>> + EFI_GUID(0x86f710ad, 0x10cf, 0x46ea, 0xac, 0x67, \ >> >>> +0x85, 0x6a, 0xe0, 0x6e, 0xfa, 0xd2) >> >>> + >> >>> +#define K3_UBOOT_IMAGE_GUID \ >> >>> + EFI_GUID(0x81b58fb0, 0x3b00, 0x4add, 0xa2, 0x0a, \ >> >>> +0xc1, 0x85, 0xbb, 0xac, 0xa1, 0xed) >> >>> + >> >>> +#define K3_SYSFW_IMAGE_GUID \ >> >>> + EFI_GUID(0x6fd10680, 0x361b, 0x431f, 0x80, 0xaa, \ >> >>> +0x89, 0x94, 0x55, 0x81, 0x9e, 0x11) >> >>> + >> >>>/* >> >>> * We setup defaults based on constraints from the Linux kernel, >> >>> which should >> >>> * also be safe elsewhere. We have the default load at 32MB into DDR >> >>> (for >>
Re: [PATCH 1/1] net: add support to parse the NIS domain for the dhcp options
On Mon, 01 Apr 2024 12:13:19 -0700, Charles Hardin wrote: > There is code in the bootp parsing for NIS domain and add the > same support for the dhcp options as well. This allows the same > usage of the data when the dhcp command is used in the boot > command. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/4] zlib: Address CVE-2016-9841
On Wed, 27 Mar 2024 15:14:49 +0100, Michal Simek wrote: > it looks like that only CVE-2016-9841 is not fixed and this series is > trying to address it. The first two patches are just preparation based on > changes which happened in past. The third one is actual fix and the last > one is following what has been done in Linux kernel long time ago and don't > use incorrect zlib version string. > > I tested it with and I can't see any issue. > ./test/py/test.py --bd sandbox --build -s > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] usb: musb-new: sunxi: support usage with DM_USB_GADGET
On Thu, Apr 11, 2024 at 04:46:17PM +1000, John Watts wrote:
> On Sun, Dec 31, 2023 at 03:38:37PM -0500, Aren Moynihan wrote:
> > Add support for building the sunxi-musb driver with DM_USB_GADGET
> > including adding a separate IRQ handling function and registering the
> > driver with the musb system differently.
>
> Hi there,
>
> Were you aware of this similar patch?
>
> https://lore.kernel.org/u-boot/20230608195631.55364-1-cfswo...@gmail.com/
>
> If not you might want to test it and compare it.
>
> John.
I was not aware of that patch, it looks like it does the same thing as
this one, but without some of the bugs. When comparing with it I
realized that my dm_usb_gadget_handle_interrupts function is just plain
wrong.
I'll try to find time to test it soon.
Thanks for the link
- Aren
> > The implementation of usb_gadget_register_driver from
> > musb-new/musb_uboot.c only works when the gadget driver for the device
> > has already been probed and has called musb_register. On the pinephone
> > (using a allwinner a64 processor) this causes issues when trying to use
> > usb gadget mode (such as from the ums command) and CONFIG_USB_ETHER is
> > disabled.
> >
> > The implementation of usb_gadget_register_driver provided when
> > DM_USB_GADGET is enabled will probe the necessary drivers when it's
> > called.
> >
> > Without the patch, this is what the error condition looks like:
> > => ums 0 mmc 1
> > UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x3a3e000
> > Controller uninitialized
> > g_dnl_register: failed!, error: -6
> > g_dnl_register failed
> >
> > based on:
> > commit 2e4865bc6486 ("musb-new: omap2430: fix compiling in DM_USB_GADGET
> > config")
> >
> > Signed-off-by: Aren Moynihan
