[PATCH] imx8mq_evk: Remove FEC and Ethernet PHY board code
With Ethernet DM in place, there is no longer the need for having the board_phy_config() and setup_fec() functions anymore. Remove them. Successfully tested a TFTP transfer after these changes. Signed-off-by: Fabio Estevam --- board/freescale/imx8mq_evk/imx8mq_evk.c | 30 - 1 file changed, 30 deletions(-) diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c b/board/freescale/imx8mq_evk/imx8mq_evk.c index e39480585609..e577e4d9ccaa 100644 --- a/board/freescale/imx8mq_evk/imx8mq_evk.c +++ b/board/freescale/imx8mq_evk/imx8mq_evk.c @@ -54,38 +54,8 @@ int board_early_init_f(void) return 0; } -#ifdef CONFIG_FEC_MXC -static int setup_fec(void) -{ - struct iomuxc_gpr_base_regs *gpr = - (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR; - - /* Use 125M anatop REF_CLK1 for ENET1, not from external */ - clrsetbits_le32(>gpr[1], BIT(13) | BIT(17), 0); - return set_clk_enet(ENET_125MHZ); -} - -int board_phy_config(struct phy_device *phydev) -{ - /* enable rgmii rxc skew and phy mode select to RGMII copper */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x1f); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x8); - - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100); - - if (phydev->drv->config) - phydev->drv->config(phydev); - return 0; -} -#endif - int board_init(void) { -#ifdef CONFIG_FEC_MXC - setup_fec(); -#endif - #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_DWC3) init_usb_clk(); #endif -- 2.34.1
Re: [PATCH 2/6] arm: xea: Add support for reading SoM (CPU) and base board HW revision
Hi Lukasz, On Thu, Mar 28, 2024 at 12:34 PM Lukasz Majewski wrote: > +static inline u8 get_som_rev(void) There is no need for 'inline' here. Also, get_som_rev() is only used 5/6, so I suggest to squash this patch with 5/6. Besides that, the series looks good.
Re: [PATCH] mx6cuboxi: Do not print devicetree model
Hi Christian, On Thu, Mar 28, 2024 at 4:18 AM Christian Gmeiner wrote: > This is not what this patch is doing. show_board_info() is the only > caller of checkboard() > so we end with the following output: You're right. The attached patch should do what we want. From b74a410127cabc100a8993840a3b00d403a316ad Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Thu, 28 Mar 2024 10:39:29 -0300 Subject: [PATCH v2] mx6cuboxi: Do not print devicetree model The mx6cuboxi_defconfig target supports several board variants. All of these variants use the hummingboard devicetree in U-Boot. Currently, the devicetree model as well as the board variant name are shown: ... Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) Board: MX6 Cubox-i ... Printing the devicetree model that is used internally by U-Boot may confuse users. Unselect the CONFIG_DISPLAY_BOARDINFO option so that only the board name is printed in board_late_init() instead. Signed-off-by: Fabio Estevam --- Changes since v1: - Remove checkboard and print the board name in board_late_init(). board/solidrun/mx6cuboxi/mx6cuboxi.c | 40 ++-- configs/mx6cuboxi_defconfig | 1 + 2 files changed, 9 insertions(+), 32 deletions(-) diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 8edabf4404c2..31d30cfbbd7b 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -381,37 +381,6 @@ static bool has_emmc(void) return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1; } -/* Override the default implementation, DT model is not accurate */ -int checkboard(void) -{ - request_detect_gpios(); - - switch (board_type()) { - case CUBOXI: - puts("Board: MX6 Cubox-i"); - break; - case HUMMINGBOARD: - puts("Board: MX6 HummingBoard"); - break; - case HUMMINGBOARD2: - puts("Board: MX6 HummingBoard2"); - break; - case UNKNOWN: - default: - puts("Board: Unknown\n"); - goto out; - } - - if (is_rev_15_som()) - puts(" (som rev 1.5)\n"); - else - puts("\n"); - - free_detect_gpios(); -out: - return 0; -} - static int find_ethernet_phy(void) { struct mii_dev *bus = NULL; @@ -505,12 +474,15 @@ int board_late_init(void) switch (board_type()) { case CUBOXI: env_set("board_name", "CUBOXI"); + puts("Board: MX6 Cubox-i"); break; case HUMMINGBOARD: env_set("board_name", "HUMMINGBOARD"); + puts("Board: MX6 HummingBoard"); break; case HUMMINGBOARD2: env_set("board_name", "HUMMINGBOARD2"); + puts("Board: MX6 HummingBoard2"); break; case UNKNOWN: default: @@ -522,8 +494,12 @@ int board_late_init(void) else env_set("board_rev", "MX6DL"); - if (is_rev_15_som()) + if (is_rev_15_som()) { env_set("som_rev", "V15"); + puts(" (som rev 1.5)\n"); + } else { + puts("\n"); + } if (has_emmc()) env_set("has_emmc", "yes"); diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index 27ceb22599a6..e3aba715aa58 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -28,6 +28,7 @@ CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vidconsole; setenv stderr serial,vidconsole; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;" CONFIG_SYS_PBSIZE=532 +# CONFIG_DISPLAY_BOARDINFO is not set CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_SYS_MALLOC=y CONFIG_SPL_FS_EXT4=y -- 2.34.1
Re: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
Hi Josua, On Thu, Mar 28, 2024 at 10:03 AM Josua Mayer wrote: > I suggest changing their status to disabled, and keeping the nodes. > >> + > >> +phy: ethernet-phy@0 { > > This node name is shared with upstream imx6qdl-sr-som.dtsi > Give this one a u-boot-only internal name, maybe ethernet-phy@ff ... > Just disable the u-boot-internal phy node unconditionally, or delete it. > Because u-boot DTB is synced with upstream, the code below will update status > properties > for the standard etherent-phy@[0,1,4] nodes used by Linux. Thanks for the suggestions. My imx6-cuboxi board does not turn on anymore, unfortunately. As I cannot test it, I am not comfortable doing the changes. I hope you or Christian can submit a proper fix.
[PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
From: Josua Mayer The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying addresses. U-Boot needs to auto-detect which phy is actually present, and at which address it is responding. Auto-detection from multiple phy nodes specified in device-tree does not currently work correct. As a work-around merge all three possible phys into one node with the special address 0x which indicates to the generic phy driver to probe all addresses. Also fixup this fake address before booting Linux, *if* booting with U-Boot's internal dtb. Signed-off-by: Josua Mayer [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.] Signed-off-by: Fabio Estevam Tested-by: Christian Gmeiner --- ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 + arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 40 +++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +++- 3 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi index e9b188ed6587..358cf8abc4ff 100644 --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ #include "imx6qdl-u-boot.dtsi" +#include "imx6qdl-sr-som-u-boot.dtsi" / { board-detect { diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi new file mode 100644 index ..4c5f043ea92a --- /dev/null +++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi @@ -0,0 +1,40 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) + +#include + + { + pinctrl-names = "default"; + pinctrl-0 = <_microsom_enet_ar8035>; + phy-handle = <>; + phy-mode = "rgmii-id"; + + /* +* The PHY seems to require a long-enough reset duration to avoid +* some rare issues where the PHY gets stuck in an inconsistent and +* non-functional state at boot-up. 10ms proved to be fine . +*/ + phy-reset-duration = <10>; + phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + /delete-node/ ethernet-phy@1; + /delete-node/ ethernet-phy@4; + + phy: ethernet-phy@0 { + /* +* The PHY can appear either: +* - AR8035: at address 0 or 4 +* - ADIN1300: at address 1 +* Actual address being detected at runtime. +*/ + reg = <0x>; + qca,clk-out-frequency = <12500>; + qca,smarteee-tw-us-1g = <24>; + adi,phy-output-clock = "125mhz-free-running"; + }; + }; +}; diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 8edabf4404c2..fbab39e800a6 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -447,7 +447,7 @@ static int find_ethernet_phy(void) */ int ft_board_setup(void *fdt, struct bd_info *bd) { - int node_phy0, node_phy1, node_phy4; + int node_phy, node_phy0, node_phy1, node_phy4; int ret, phy; bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false; enum board_type board; @@ -479,6 +479,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd) return 0; } + // update U-Boot's own unified phy node phy address, if present + node_phy = fdt_path_offset(fdt, "/soc/bus@210/ethernet@2188000/mdio/phy"); + ret = fdt_setprop_u32(fdt, node_phy, "reg", phy); + if (ret < 0) + pr_err("%s: failed to update unified PHY node address\n", __func__); + // update all phy nodes status node_phy0 = fdt_path_offset(fdt, "/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0"); ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay" : "disabled"); -- 2.34.1
Re: Thoughts about U-boot binary size increase
Hi Lukasz, On Thu, Mar 28, 2024 at 6:20 AM Lukasz Majewski wrote: > > Dear Community, > > I'd like to share with you some thoughts about growth of u-boot's > binary size for SPL and u-boot proper. > > Board: XEA > SoC : imx287 (still in active production) > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). > Board design constraints u-boot proper size to less than ~448 > KiB > > > When XEA was added (2019.07): > - u-boot.sb (SPL): 37 KiB > - u-boot.img : 401 KiB > > Now (2024.04): > - u-boot.sb (SPL): 40 KiB > - u-boot.img : 427 KiB > > (With a _lot_ of effort put to reduce the size) > > Hence, the question - would it be possible to take more concern about > the binary size growth? > > Maybe CI could catch patches, which enable by default some features and > the size is unintentionally increased? > > I'm open for any feedback and thoughts on "stopping" the binary size > increase. In addition to adding CONFIG_BOARD_SIZE_LIMIT and CONFIG_SPL_SIZE_LIMIT checks, could you try the change below? diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig index d2e4205c5ce5..ee8c23d0e04f 100644 --- a/arch/arm/mach-imx/mxs/Kconfig +++ b/arch/arm/mach-imx/mxs/Kconfig @@ -32,6 +32,7 @@ if ARCH_MX28 config MX28 bool + select LTO default y I did a quick imx28_xea_defconfig build test here: U-Boot mainline --- $ ls -al u-boot.img -rw-rw-r-- 1 fabio fabio 444128 mar 28 09:11 u-boot.img $ ls -al spl/u-boot-spl.bin -rwxrwxr-x 1 fabio fabio 39800 mar 28 09:12 spl/u-boot-spl.bin U-Boot mainline + LTO - $ ls -al u-boot.img -rw-rw-r-- 1 fabio fabio 424144 mar 28 09:14 u-boot.img $ ls -al spl/u-boot-spl.bin -rw-rw-r-- 1 fabio fabio 37664 mar 28 09:14 spl/u-boot-spl.bin
Re: [PATCH 4/4] imx: imx8mp_evk: convert to OF_UPSTREAM
Hi Peng, On Wed, Mar 27, 2024 at 10:27 PM Peng Fan (OSS) wrote: > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -1105,7 +1105,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \ > imx8mp-dhcom-pdk2.dtb \ > imx8mp-dhcom-pdk3.dtb \ > imx8mp-dhcom-pdk3-overlay-rev100.dtbo \ > - imx8mp-evk.dtb \ Here you removed imx8mp-evk.dtb from the Makefile, which is correct. You should do the same on the other patches. Have you boot-tested all these boards?
Re: [PATCH v3 6/6] imx: imx93-11x11-evk: convert to OF_UPSTREAM
Hi Peng, On Wed, Mar 27, 2024 at 9:40 PM Peng Fan wrote: > I could help convert all imx93 boards, but I could only test nxp > imx93 boards, not able to test others. Just copy the board maintainers in your patch and they could help test the conversion to OF_UPSTREAM. Thanks!
Re: [PATCH v3 6/6] imx: imx93-11x11-evk: convert to OF_UPSTREAM
On Wed, Mar 27, 2024 at 8:53 PM Peng Fan (OSS) wrote: > + { > + #address-cells = <1>; > + #size-cells = <0>; > + clock-frequency = <40>; > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <_lpi2c2>; > + pinctrl-1 = <_lpi2c2>; > + status = "okay"; > + > + pmic@25 { > + adp5585gpio: gpio@34 { > + compatible = "adp5585"; > + reg = <0x34>; > + gpio-controller; > + #gpio-cells = <2>; Please add a comment saying these nodes are already available in 6.9-rc1. > --- a/arch/arm/mach-imx/imx9/Kconfig > +++ b/arch/arm/mach-imx/imx9/Kconfig > @@ -31,6 +31,7 @@ choice > config TARGET_IMX93_11X11_EVK > bool "imx93_11x11_evk" > select IMX93 > + imply OF_UPSTREAM Sumit and I asked you to add OF_UPSTREAM to all imx93 boards, not just this one. Please don't ignore review comments.
Re: [PATCH v3 2/6] serial: lpuart: use ipg clk for i.MX7ULP
On Wed, Mar 27, 2024 at 8:53 PM Peng Fan (OSS) wrote: > + struct lpuart_serial_plat *plat = dev_get_plat(dev); > struct clk per_clk; Please rename from "per_clk" to "clk".
Re: [PATCH] mx6cuboxi: fix ethernet after synchronise device-tree
On Wed, Mar 27, 2024 at 6:04 PM Fabio Estevam wrote: > I took Josua's patch and modified it a bit. > > Does the attached patch fix Ethernet? I forgot to delete the old ethernet-phy nodes. Please try this one instead. If it works in U-Boot, please also test Ethernet in Linux as we are touching ft_board_setup(). From 5af15e698ad89fac3cc3433ac4ac87bb10bc014d Mon Sep 17 00:00:00 2001 From: Josua Mayer Date: Wed, 27 Mar 2024 17:58:47 -0300 Subject: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying addresses. U-Boot needs to auto-detect which phy is actually present, and at which address it is responding. Auto-detection from multiple phy nodes specified in device-tree does not currently work correct. As a work-around merge all three possible phys into one node with the special address 0x which indicates to the generic phy driver to probe all addresses. Also fixup this fake address before booting Linux, *if* booting with U-Boot's internal dtb. Signed-off-by: Josua Mayer [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.] Signed-off-by: Fabio Estevam --- ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 + arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 40 +++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +++- 3 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi index e9b188ed6587..358cf8abc4ff 100644 --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ #include "imx6qdl-u-boot.dtsi" +#include "imx6qdl-sr-som-u-boot.dtsi" / { board-detect { diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi new file mode 100644 index ..4c5f043ea92a --- /dev/null +++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi @@ -0,0 +1,40 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) + +#include + + { + pinctrl-names = "default"; + pinctrl-0 = <_microsom_enet_ar8035>; + phy-handle = <>; + phy-mode = "rgmii-id"; + + /* + * The PHY seems to require a long-enough reset duration to avoid + * some rare issues where the PHY gets stuck in an inconsistent and + * non-functional state at boot-up. 10ms proved to be fine . + */ + phy-reset-duration = <10>; + phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + /delete-node/ ethernet-phy@1; + /delete-node/ ethernet-phy@4; + + phy: ethernet-phy@0 { + /* + * The PHY can appear either: + * - AR8035: at address 0 or 4 + * - ADIN1300: at address 1 + * Actual address being detected at runtime. + */ + reg = <0x>; + qca,clk-out-frequency = <12500>; + qca,smarteee-tw-us-1g = <24>; + adi,phy-output-clock = "125mhz-free-running"; + }; + }; +}; diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 8edabf4404c2..fbab39e800a6 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -447,7 +447,7 @@ static int find_ethernet_phy(void) */ int ft_board_setup(void *fdt, struct bd_info *bd) { - int node_phy0, node_phy1, node_phy4; + int node_phy, node_phy0, node_phy1, node_phy4; int ret, phy; bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false; enum board_type board; @@ -479,6 +479,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd) return 0; } + // update U-Boot's own unified phy node phy address, if present + node_phy = fdt_path_offset(fdt, "/soc/bus@210/ethernet@2188000/mdio/phy"); + ret = fdt_setprop_u32(fdt, node_phy, "reg", phy); + if (ret < 0) + pr_err("%s: failed to update unified PHY node address\n", __func__); + // update all phy nodes status node_phy0 = fdt_path_offset(fdt, "/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0"); ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay" : "disabled"); -- 2.34.1
Re: [PATCH] mx6cuboxi: fix ethernet after synchronise device-tree
Hi Christian, On Wed, Mar 27, 2024 at 4:29 PM Fabio Estevam wrote: > Please make these changes in a new imx6qdl-sr-som-u-boot.dtsi file instead. I took Josua's patch and modified it a bit. Does the attached patch fix Ethernet? From 24f57c3cd8b1a2b113bcffad26e2bb1b9b582e35 Mon Sep 17 00:00:00 2001 From: Josua Mayer Date: Wed, 27 Mar 2024 17:58:47 -0300 Subject: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying addresses. U-Boot needs to auto-detect which phy is actually present, and at which address it is responding. Auto-detection from multiple phy nodes specified in device-tree does not currently work correct. As a work-around merge all three possible phys into one node with the special address 0x which indicates to the generic phy driver to probe all addresses. Also fixup this fake address before booting Linux, *if* booting with U-Boot's internal dtb. Signed-off-by: Josua Mayer [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.] Signed-off-by: Fabio Estevam --- ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 + arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 76 +++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +- 3 files changed, 84 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi index e9b188ed6587..358cf8abc4ff 100644 --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ #include "imx6qdl-u-boot.dtsi" +#include "imx6qdl-sr-som-u-boot.dtsi" / { board-detect { diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi new file mode 100644 index ..3f2d92be7061 --- /dev/null +++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi @@ -0,0 +1,76 @@ +/* + * Copyright (C) 2013,2014 Russell King + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ +#include + + { + pinctrl-names = "default"; + pinctrl-0 = <_microsom_enet_ar8035>; + phy-handle = <>; + phy-mode = "rgmii-id"; + + /* + * The PHY seems to require a long-enough reset duration to avoid + * some rare issues where the PHY gets stuck in an inconsistent and + * non-functional state at boot-up. 10ms proved to be fine . + */ + phy-reset-duration = <10>; + phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + + phy: ethernet-phy@0 { + /* + * The PHY can appear either: + * - AR8035: at address 0 or 4 + * - ADIN1300: at address 1 + * Actual address being detected at runtime. + */ + reg = <0x>; + qca,clk-out-frequency = <12500>; + qca,smarteee-tw-us-1g = <24>; + adi,phy-output-clock = "125mhz-free-running"; + }; + }; +}; dif
Re: [PATCH] mx6cuboxi: fix ethernet after synchronise device-tree
Hi Christian, On Wed, Mar 27, 2024 at 9:06 AM Josua Mayer wrote: > > Cc: christian.gmei...@gmail.com > > Hi Christian, > > please take a look at this patch, I suspect it will (hack-)fix your > ethernet issue. > > Unfortunately I had no time to revisit this yet and implement a correct > solution. > > arch/arm/dts/imx6qdl-sr-som.dtsi | 30 +--- > > board/solidrun/mx6cuboxi/mx6cuboxi.c | 6 +- > > 2 files changed, 14 insertions(+), 22 deletions(-) > > > > diff --git a/arch/arm/dts/imx6qdl-sr-som.dtsi > > b/arch/arm/dts/imx6qdl-sr-som.dtsi > > index ce543e325c..2d7cbc26b3 100644 > > ---_a/arch/arm/dts/imx6qdl-sr-som.dtsi > > +++ b/arch/arm/dts/imx6qdl-sr-som.dtsi Please make these changes in a new imx6qdl-sr-som-u-boot.dtsi file instead. This way, the changes will not get lost after a new sync with Linux or if OF_UPSTREAM is used.
[PATCH] mx6cuboxi: Do not print devicetree model
The mx6cuboxi_defconfig target supports several board variants. All of these variants use the hummingboard devicetree in U-Boot. Currently, the devicetree model as well as the board variant name are shown: U-Boot 2024.04-rc5-3-g774ec4fda8 (Mar 27 2024 - 16:48:35 +0100) ... Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) Board: MX6 Cubox-i ... Printing the devicetree model that is used internally by U-Boot may confuse users. Unselect the CONFIG_DISPLAY_BOARDINFO option so that only the board name is printed instead. Signed-off-by: Fabio Estevam --- configs/mx6cuboxi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index 27ceb22599a6..e3aba715aa58 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -28,6 +28,7 @@ CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vidconsole; setenv stderr serial,vidconsole; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;" CONFIG_SYS_PBSIZE=532 +# CONFIG_DISPLAY_BOARDINFO is not set CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_SYS_MALLOC=y CONFIG_SPL_FS_EXT4=y -- 2.34.1
[PATCH] mx6cuboxi: Convert to watchdog driver model
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused the 'reset' command in U-Boot to not cause a board reset. Fix it by switching to the watchdog driver model via sysreset, which is the preferred method for implementing the watchdog reset. Signed-off-by: Fabio Estevam --- Christian, Can you test this, please? .../dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 10 ++ configs/mx6cuboxi_defconfig| 3 +++ 2 files changed, 13 insertions(+) diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi index 23a05773b579..e9b188ed6587 100644 --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi @@ -13,6 +13,12 @@ 4 0 >; }; + + wdt-reboot { + compatible = "wdt-reboot"; + wdt = <>; + bootph-pre-ram; + }; }; { @@ -58,3 +64,7 @@ { bootph-all; }; + + { + bootph-pre-ram; +}; diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index 66d4aaeda2d9..27ceb22599a6 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -71,6 +71,8 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_THERMAL=y CONFIG_USB=y @@ -89,3 +91,4 @@ CONFIG_IMX_HDMI=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y CONFIG_BMP_16BPP=y +CONFIG_IMX_WATCHDOG=y -- 2.34.1
Re: [PATCH 5/6] Makefile: tune the include order
Peng, On Wed, Mar 27, 2024 at 11:07 AM Sumit Garg wrote: > That's the real reason why we should try to migrate to OF_UPSTREAM at > SoC level rather than at board level. If a particular board isn't > supported upstream then they can opt out for the time being. All the imx93 boards in U-Boot are supported by the upstream kernel, so, yes, please migrate all of them to OF_UPSTREAM.
[PATCH] warp7: Convert to watchdog driver model
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused the 'reset' command in U-Boot to not cause a board reset. Fix it by switching to the watchdog driver model via sysreset, which is the preferred method for implementing the watchdog reset. Signed-off-by: Fabio Estevam --- arch/arm/dts/imx7s-warp-u-boot.dtsi | 10 ++ configs/warp7_defconfig | 3 +++ 2 files changed, 13 insertions(+) diff --git a/arch/arm/dts/imx7s-warp-u-boot.dtsi b/arch/arm/dts/imx7s-warp-u-boot.dtsi index 4f44598c9a27..98784fd7a2ef 100644 --- a/arch/arm/dts/imx7s-warp-u-boot.dtsi +++ b/arch/arm/dts/imx7s-warp-u-boot.dtsi @@ -7,6 +7,12 @@ chosen { stdout-path = }; + + wdt-reboot { + compatible = "wdt-reboot"; + wdt = <>; + bootph-pre-ram; + }; }; { @@ -24,3 +30,7 @@ { bootph-all; }; + + { + bootph-pre-ram; +}; diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 9b518a121be6..48042b702c22 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -67,6 +67,8 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_WATCHDOG=y CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y @@ -80,5 +82,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_ETHER=y CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" +CONFIG_IMX_WATCHDOG=y CONFIG_OPTEE_TZDRAM_SIZE=0x300 CONFIG_BOOTM_OPTEE=y -- 2.34.1
Re: mx6cuboxi: failes to detect model
Hi Christian, On Wed, Mar 27, 2024 at 3:54 AM Christian Gmeiner wrote: > It does help \o/ Ok, great! > When you send out a proper patch feel free to add Tested-by: Christian > Gmeiner I have sent a more complete fix, so I have not included your Tested-by. Please test the formal version and reply with your Tested-by tag. > Time to look into the next broken thing on the device: network :) If you still have issues with Ethernet, please share the details on a new thread.
[PATCH] mx6cuboxi: Fix board revision detection
Currently, an i.MX6 Cuboxi board is incorrectly detected as the HummingBoard model: U-Boot 2024.04-rc5 (Mar 26 2024 - 15:59:22 +0100) CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 26C Reset cause: POR Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) gpio@20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved gpio@20a4000: get_value: error: gpio GPIO3_8 not reserved gpio@20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved gpio@20a8000: get_value: error: gpio GPIO4_4 not reserved gpio@20b: set_dir_flags: error: gpio GPIO6_9 not reserved gpio@20b: get_value: error: gpio GPIO6_9 not reserved Board: MX6 HummingBoard DRAM: 2 GiB ... This error happens because request_detect_gpios() uses the GPIO DM API, but board_type() still uses the legacy non-DM GPIO API. Fix it by using the GPIO DM API in board_type() to read the board revision pins in SPL. Reported-by: Christian Gmeiner Signed-off-by: Fabio Estevam --- board/solidrun/mx6cuboxi/mx6cuboxi.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 8edabf4404c2..7fe515f928a0 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,20 +336,17 @@ static enum board_type board_type(void) * HB 1 1x */ - gpio_direction_input(IMX_GPIO_NR(2, 8)); - val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); + val3 = !!dm_gpio_get_value(_detect_desc[0]); if (val3 == 0) return HUMMINGBOARD2; - gpio_direction_input(IMX_GPIO_NR(3, 4)); - val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); + val2 = !!dm_gpio_get_value(_detect_desc[1]); if (val2 == 0) return HUMMINGBOARD; - gpio_direction_input(IMX_GPIO_NR(4, 9)); - val1 = gpio_get_value(IMX_GPIO_NR(4, 9)); + val1 = !!dm_gpio_get_value(_detect_desc[2]); if (val1 == 0) { return CUBOXI; @@ -363,8 +360,8 @@ static bool is_rev_15_som(void) int val1, val2; SETUP_IOMUX_PADS(som_rev_detect); - val1 = gpio_get_value(IMX_GPIO_NR(6, 0)); - val2 = gpio_get_value(IMX_GPIO_NR(6, 4)); + val1 = !!dm_gpio_get_value(_detect_desc[3]); + val2 = !!dm_gpio_get_value(_detect_desc[4]); if (val1 == 1 && val2 == 0) return true; -- 2.34.1
Re: [PATCH] arm: imx: fix signature_block_hdr struct fields order
Hi Javier, On Tue, Mar 26, 2024 at 8:07 AM Javier Viguera wrote: > > According to the documentation (for example AN13994), for AHAB-enabled > devices the format of the signature block is: > > +--+--+--+-+ > | Tag | Length - msb | Length - lsb | Version | > +--+--+--+-+ > | SRK Table offset| Certificate offset | > +-++ > | Blob offset | Signature offset | > +-++ Could you elaborate more about this and share more details? Have you seen a run-time error or did you catch it by code inspection? Please clarify. Thanks
Re: [PATCH 5/7] arm64: imx: imx8mm-beacon: Migrate to OF_UPSTREAM
Hi Adam, On Tue, Mar 26, 2024 at 5:25 PM Adam Ford wrote: > > The imx8mm-beacon boards can migrate to OF_UPSTREAM which also > allows for the removal the device tree files. > > Signed-off-by: Adam Ford Please split the series by SoC family, thanks.
Re: [PATCH v3 2/3] imx: imx93_evk: add rtc pcf2131
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote: > + { > + #address-cells = <1>; > + #size-cells = <0>; > + clock-frequency = <40>; > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <_lpi2c3>; > + pinctrl-1 = <_lpi2c3>; > + status = "okay"; > + > + pcf2131: rtc@53 { > + compatible = "nxp,pcf2131"; > + reg = <0x53>; > + interrupt-parent = <>; > + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; > + status = "okay"; Please submit the RTC support to Linux first, then you can sync the devicetree with Linux in U-Boot. In the meantime, you can add the RTC support to the -u-boot.dtsi. Please consider using OF_UPSTREAM available in the U-Boot next branch.
Re: [PATCH v3 3/3] configs: Enable RTC pcf2131 support
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote: > > Enable CONFIG_RTC_PCF2127 configs to support pcf2131. Subject should be imx93_11x11_evk specific: imx93_11x11_evk: Add PCF2131 RTC support
Re: [PATCH v3 1/3] drivers: rtc: add pcf2131 rtc driver
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote: > +bool is_pcf2131_type(struct udevice *dev) static bool > static int pcf2127_rtc_read(struct udevice *dev, uint offset, u8 *buffer, > uint len) > { > struct dm_i2c_chip *chip = dev_get_parent_plat(dev); > @@ -43,10 +75,64 @@ static int pcf2127_rtc_read(struct udevice *dev, uint > offset, u8 *buffer, uint l > return dm_i2c_xfer(dev, , 1); > } > > +static int pcf2131_rtc_lock(struct udevice *dev) > +{ > + int ret = 0; No need to initialize ret with 0. > +static int pcf2131_rtc_unlock(struct udevice *dev) > +{ > + int ret = 0; Ditto. > static int pcf2127_rtc_write(struct udevice *dev, uint offset, > const u8 *buffer, uint len) > { > - return dm_i2c_write(dev, offset, buffer, len); > + int ret = 0; Ditto.
Re: mx6cuboxi: failes to detect model
On Tue, Mar 26, 2024 at 1:11 PM Christian Gmeiner wrote: > It got better but the model is (still) wrong: > > U-Boot 2024.04-rc5-dirty (Mar 26 2024 - 17:03:41 +0100) > > CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) > CPU: Extended Commercial temperature grade (-20C to 105C) at 20C > Reset cause: POR > Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) > Board: MX6 HummingBoard2 > DRAM: 2 GiB > Core: 82 devices, 17 uclasses, devicetree: fit > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment It seems to me that there is a mix of DM GPIO and non-DM GPIO. Does the change below help? --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,20 +336,16 @@ static enum board_type board_type(void) * HB 1 1x */ - gpio_direction_input(IMX_GPIO_NR(2, 8)); - val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); + val3 = !!dm_gpio_get_value(&(board_detect_desc[0])); if (val3 == 0) return HUMMINGBOARD2; - gpio_direction_input(IMX_GPIO_NR(3, 4)); - val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); + val2 = !!dm_gpio_get_value(&(board_detect_desc[1])); if (val2 == 0) return HUMMINGBOARD; - - gpio_direction_input(IMX_GPIO_NR(4, 9)); - val1 = gpio_get_value(IMX_GPIO_NR(4, 9)); + val1 = !!dm_gpio_get_value(&(board_detect_desc[2])); if (val1 == 0) { return CUBOXI;
Re: mx6cuboxi: failes to detect model
Hi Christian, On Tue, Mar 26, 2024 at 12:17 PM Christian Gmeiner wrote: > > I am seeing model detection problems with the current git master. > > U-Boot 2024.04-rc5 (Mar 26 2024 - 15:59:22 +0100) > > CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) > CPU: Extended Commercial temperature grade (-20C to 105C) at 26C > Reset cause: POR > Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) > gpio@20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved > gpio@20a4000: get_value: error: gpio GPIO3_8 not reserved > gpio@20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved > gpio@20a8000: get_value: error: gpio GPIO4_4 not reserved > gpio@20b: set_dir_flags: error: gpio GPIO6_9 not reserved > gpio@20b: get_value: error: gpio GPIO6_9 not reserved > Board: MX6 HummingBoard Unfortunately, my mx6cuboxi no longer works, so I can't test it myself. I am adding Baruch on Cc. Hopefully, Baruch or Josua can take a look. The 'not reserved' errors may be caused by the lack of gpio_request(). Do the changes below help? --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,18 +336,21 @@ static enum board_type board_type(void) * HB 1 1x */ + gpio_request(IMX_GPIO_NR(2, 8), "val3"); gpio_direction_input(IMX_GPIO_NR(2, 8)); val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); if (val3 == 0) return HUMMINGBOARD2; + gpio_request(IMX_GPIO_NR(3, 4), "val2"); gpio_direction_input(IMX_GPIO_NR(3, 4)); val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); if (val2 == 0) return HUMMINGBOARD; + gpio_request(IMX_GPIO_NR(4, 9), "val1"); gpio_direction_input(IMX_GPIO_NR(4, 9)); val1 = gpio_get_value(IMX_GPIO_NR(4, 9)); > DRAM: 2 GiB > Core: 82 devices, 17 uclasses, devicetree: fit > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In:serial > Out: serial > Err: serial > Net: eth0: ethernet@2188000 > > > I did a git bisect to find the commit that broke model detection: > > # good: [4459ed60cb1e0562bc5b40405e2b4b9bbf766d57] Prepare v2023.10 > git bisect good 4459ed60cb1e0562bc5b40405e2b4b9bbf766d57 > # bad: [873791433602281ed230486606e326983c97a285] Merge > https://source.denx.de/u-boot/custodians/u-boot-riscv > git bisect bad 873791433602281ed230486606e326983c97a285 > # bad: [6e0a75d3162a024cb0cdedd871d435e6ee782447] configs: Resync with > savedefconfig > git bisect bad 6e0a75d3162a024cb0cdedd871d435e6ee782447 > # good: [99b46477e3495f819f6826d11470d46f12a4f9f7] clk: Dont return > error when assigned-clocks is empty or missing > git bisect good 99b46477e3495f819f6826d11470d46f12a4f9f7 > # bad: [50fa67d091b6ffbc1d77d3100d7b31795bf64928] arm: mach-k3: > j721e_init: Move clk_k3 probe before loading TIFS > git bisect bad 50fa67d091b6ffbc1d77d3100d7b31795bf64928 > # bad: [827cece3aa550d41e9c08c640b3a73372c8fb14a] pinctrl: renesas: > Synchronize R8A77980 V3H PFC tables with Linux 6.5.3 > git bisect bad 827cece3aa550d41e9c08c640b3a73372c8fb14a > # good: [623b3e8f9718a1fbd612b3e42451859e9f98a947] x86: spl: Change > the condition for copying U-Boot to RAM > git bisect good 623b3e8f9718a1fbd612b3e42451859e9f98a947 > # good: [ad57b98e212bd15492398cea3a8d4df6297e16fd] x86: doc: Split out > manual booting into its own file > git bisect good ad57b98e212bd15492398cea3a8d4df6297e16fd > # bad: [6d53b50888315252cdd3251551add7a9108a1300] ARM: renesas: Enable > DM_ETH_PHY on 64-bit R-Car boards > git bisect bad 6d53b50888315252cdd3251551add7a9108a1300 > # bad: [283dcb63cb7d124fa427938f39aa9362872e02fc] buildman: Show > progress when regenerating the board.cfg file > git bisect bad 283dcb63cb7d124fa427938f39aa9362872e02fc > # bad: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report > bootph-pre-ram/sram node as pre-reloc after relocation > git bisect bad 9e644284ab812f2db23f6185af77c0e771b0be73 > # good: [b05a184379631d13c4a49e423aa1324dc1ae6158] Merge tag > 'x86-pull-20230922' of > https://source.denx.de/u-boot/custodians/u-boot-x86 into next > git bisect good b05a184379631d13c4a49e423aa1324dc1ae6158 > # first bad commit: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: > core: Report bootph-pre-ram/sram node as pre-reloc after relocation > > If I revert 9e644284ab812f2db23f6185af77c0e771b0be73 on top of git > master everything is fine again. As I am not an export in that area I > am seeking > some directions on how to fix this issue. > > -- > greets > -- > Christian Gmeiner, MSc > > https://christian-gmeiner.info/privacypolicy
Re: U-boot fails for khadas-edge -v
Hi Vivek, [Please don't top-post and do not post HTML] On Mon, Mar 25, 2024 at 1:37 PM Vivek Jaiswal wrote: > > Hello Fabio, > I tried using the this github repository. > https://github.com/u-boot/u-boot.git > > And the configuration used was following > > rockchip-rk3399-khadas-edge-v.conf > > UBOOT_MACHINE = "khadas-edge-v-rk3399_defconfig" > > I got some error during the build from the u-boot. > > Please check the attachment BuildError1.txt or BuildError2.txt > > make[2]: *** > [/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/scripts/Makefile.build:280: > cmd/bootm.o] Error 1 > make[1]: *** > [/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/Makefile:1317: > cmd] Error 2 > make: *** [Makefile:157: sub-make] Error 2 You are trying to build U-Boot 2017.09. U-Boot 2024.01 builds khadas-edge-v-rk3399_defconfig just fine.
[PATCH] imx8: Add a default reset_cpu() implementation
From: Fabio Estevam Add a weak default reset_cpu() implementation just like it is done on arch/arm/mach-imx/cpu.c. This allows the removal of the empty reset_cpu() in several board files. Signed-off-by: Fabio Estevam --- arch/arm/mach-imx/imx8/cpu.c | 4 board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c | 11 --- board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 8 board/congatec/cgtqmx8/cgtqmx8.c | 7 --- board/freescale/imx8qm_mek/imx8qm_mek.c | 8 board/freescale/imx8qxp_mek/imx8qxp_mek.c | 8 board/toradex/apalis-imx8/apalis-imx8.c | 8 board/toradex/colibri-imx8x/colibri-imx8x.c | 8 8 files changed, 4 insertions(+), 58 deletions(-) diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c index 0b91e448a5d..6e643188f40 100644 --- a/arch/arm/mach-imx/imx8/cpu.c +++ b/arch/arm/mach-imx/imx8/cpu.c @@ -84,6 +84,10 @@ static char *get_reset_cause(void) } } +__weak void reset_cpu(void) +{ +} + int arch_cpu_init(void) { #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_RECOVER_DATA_SECTION) diff --git a/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c b/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c index 8b4d73052eb..56b7bdb57c9 100644 --- a/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c +++ b/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c @@ -136,17 +136,6 @@ void detail_board_ddr_info(void) puts("\nDDR"); } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - puts("SCI reboot request"); - - while (1) - putc('.'); -} - #ifdef CONFIG_OF_BOARD_SETUP int ft_board_setup(void *blob, struct bd_info *bd) { diff --git a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c index 206ce7d5c13..7f766a688bb 100644 --- a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c +++ b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c @@ -112,14 +112,6 @@ int board_init(void) return 0; } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} - int board_mmc_get_env_dev(int devno) { return devno; diff --git a/board/congatec/cgtqmx8/cgtqmx8.c b/board/congatec/cgtqmx8/cgtqmx8.c index 26189ff66f5..3b01354bb6b 100644 --- a/board/congatec/cgtqmx8/cgtqmx8.c +++ b/board/congatec/cgtqmx8/cgtqmx8.c @@ -371,13 +371,6 @@ void detail_board_ddr_info(void) puts("\nDDR"); } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} #ifdef CONFIG_OF_BOARD_SETUP int ft_board_setup(void *blob, struct bd_info *bd) diff --git a/board/freescale/imx8qm_mek/imx8qm_mek.c b/board/freescale/imx8qm_mek/imx8qm_mek.c index d96d1d07bb1..2b209c8886f 100644 --- a/board/freescale/imx8qm_mek/imx8qm_mek.c +++ b/board/freescale/imx8qm_mek/imx8qm_mek.c @@ -102,14 +102,6 @@ int board_init(void) return 0; } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} - #ifdef CONFIG_OF_BOARD_SETUP int ft_board_setup(void *blob, struct bd_info *bd) { diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c b/board/freescale/imx8qxp_mek/imx8qxp_mek.c index 516cefd2f24..833bee55462 100644 --- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c +++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c @@ -126,14 +126,6 @@ int board_init(void) return 0; } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} - #ifdef CONFIG_OF_BOARD_SETUP int ft_board_setup(void *blob, struct bd_info *bd) { diff --git a/board/toradex/apalis-imx8/apalis-imx8.c b/board/toradex/apalis-imx8/apalis-imx8.c index 49719f2f553..0f993e644d7 100644 --- a/board/toradex/apalis-imx8/apalis-imx8.c +++ b/board/toradex/apalis-imx8/apalis-imx8.c @@ -291,14 +291,6 @@ int board_init(void) return 0; } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} - #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) int ft_board_setup(void *blob, struct bd_info *bd) { diff --git a/board/toradex/colibri-imx8x/colibri-imx8x.c b/board/toradex/colibri-imx8x/colibri-imx8x.c index 6fc8076163c..a507d666c07 100644 --- a/board/toradex/colibri-imx8x/colibri-imx8x.c +++ b/board/toradex/colibri-imx8x/colibri-imx8x.c @@ -140,14 +140,6 @@ int board_init(void) return 0; } -/* - * Board specific reset that is system reset. - */ -void reset_cpu(void) -{ - /* TODO */ -} - #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) int ft_board_setup(void *blob, struct bd_info *bd) { -- 2.34.1
Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions
Hi Lukasz, On Mon, Mar 25, 2024 at 5:48 AM Lukasz Majewski wrote: > The case here is that I'm modifying the *-u-boot.dts{i} files only. In The diff below shows that you are creating imx28-xea-1.dts and imx28-xea-2.dts for U-Boot consumption and renaming the upstream imx28-xea.dts to imx28-xea.dts. create mode 100644 arch/arm/dts/imx28-xea-1.dts create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi create mode 100644 arch/arm/dts/imx28-xea-2.dts rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%) > other words, u-boot will not support features described in Linux DTS. That's OK and this happens frequently. For example, upstream devicetree may describes audio codec, but U-Boot does not support audio playback. Devicetree should be OS agnostic. In U-Boot, we want to re-use the upstream Linux devicetree files 'as-is'. Adding -u-boot.dtsi files is OK though. Can you convert the imx28-xea board to OF_UPSTREAM available in the U-Boot next branch? > Hence, the rename of files (which would be in sync with Linux at some > point) looks like not related to Linux DTS (as even after re-sync with > upstream Linux those changes will not be in Linux DTS). I did not understand this part, do you mean that Linux will also do the imx28-xea.dts => imx28-xea.dtsi rename and will also have the new imx28-xea-1.dts and imx28-xea-2.dts? Regards, Fabio Estevam
[PATCH] phycore_pcl063: Drop leading zero from USB vendor number
CONFIG_USB_GADGET_VENDOR_NUM is a 16-bit number, so remove the leading zero. Reported-by: Marek Vasut Signed-off-by: Fabio Estevam --- configs/phycore_pcl063_defconfig | 2 +- configs/phycore_pcl063_ull_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig index 6b00df1cffb3..017054a8e12b 100644 --- a/configs/phycore_pcl063_defconfig +++ b/configs/phycore_pcl063_defconfig @@ -63,7 +63,7 @@ CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Phytec" -CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_pcl063_ull_defconfig b/configs/phycore_pcl063_ull_defconfig index 6195fcfb73df..b3da43a5bf1e 100644 --- a/configs/phycore_pcl063_ull_defconfig +++ b/configs/phycore_pcl063_ull_defconfig @@ -54,7 +54,7 @@ CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Phytec" -CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y -- 2.34.1
Re: [PATCH v1 1/3] crypto/fsl: allow accessing Job Ring from non-TrustZone
Hi Emanuele, On Mon, Mar 25, 2024 at 8:47 AM Emanuele Ghidoli wrote: > +config FSL_CAAM_JR_NTZ_ACCESS > + bool "Give caam Job Ring access to non-secure world" Please spell CAAM instead. > + default n 'default n' is already the default, please drop this line.
Re: [PATCH] board: phytec: phycore_imx8mp.env fix netboot issues
On Fri, Mar 22, 2024 at 9:55 AM Yannic Moog wrote: > > The "run netargs" command should come later in the "netboot" command > order when using dhcp since it sets the server and client ip addresses. > The previous order led to misconfigured kernel boot params and thus > kernel panic when serverip was not manually set. > Further, following Linux FHS 3.0, change the nfsroot default directory > to /srv/nfs. > > Fixes: 60f64bec414e ("board: phytec: phycore_imx8mp: Add fec support") > Signed-off-by: Yannic Moog Applied to u-boot-imx/next, thanks.
Re: [PATCH v3 2/3] configs: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > $ git grep -i usb.*phytec configs > configs/phycore_pcl063_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > configs/phycore_pcl063_ull_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > > It would be good to be consistent. > > Also, what is the vendor/product number those two boards use ? They both use: CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff configs/phycore-imx8mp_defconfig has: CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 I agree we should make this consistent. To not block this series, I applied it, but it would be great if Phytec could submit a separate series making it consistent across their boards. Thanks
Re: [PATCH v3 1/3] arm: dts: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > > On 3/21/24 3:45 PM, Mathieu Othacehe wrote: > > Enable both usbotg1 and usbotg2 ports. Disable over-current as OC pins are > > not connected to the SoC. > > > > This > > "This addition to ...-u-boot.dtsi is temporary, ..." would be clearer. I fixed as Marek's suggestion and applied it to u-boot-imx/next, thanks.
Re: [PATCH] imx: ele_ahab: Add ahab_commit command support
On Thu, Mar 21, 2024 at 4:20 AM Mathieu Othacehe wrote: > > This message is used to commit into the fuses any new SRK revocation and > FW version information that have been found into the NXP (ELE FW) and > OEM containers. > > Signed-off-by: Mathieu Othacehe Applied to u-boot-imx/next, thanks.
Re: [PATCH v4 00/11] imx8mp: Enable PCIe/NVMe support
On Fri, Mar 22, 2024 at 10:51 AM Fabio Estevam wrote: > > Hi Sumit, > > On Thu, Mar 21, 2024 at 11:55 AM Sumit Garg wrote: > > > Changes in v4: > > - Incorporated misc comments from Marek and added his review tag. > > - Dropped patch #4 (imx8mp: power-domain: Don't power off pd_bus) > > since power domain off path is never excercised for DT based devices. > > - Added patch#8 as suggested by Peter to describe older pcie_imx.c > > driver as legacy one. > > v4 looks good, thanks. > > I'll wait a few days and will queue it to next. Applied to u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240324
Hi Tom, Please pull this material for next from u-boot-imx, thanks. The following changes since commit fb49d6c289d942ff7de309a5c5eaa37a7f4235db: remoteproc: uclass: Add methods to load firmware to rproc and boot rproc (2024-03-22 15:50:28 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-next-20240324 for you to fetch changes up to 9d27e441bb14dd526c60c13d5ff16353ca322eb3: board: phytec: phycore_imx8mp.env fix netboot issues (2024-03-24 13:42:10 -0300) u-boot-imx-next-20240324 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20056 - Add ahab_commit command support. - Add USB support for the imx93-phyboard-segin board. - Add i.MX8MP PCIe support. - Fix netboot environment on phycore_imx8mp. Mathieu Othacehe (4): imx: ele_ahab: Add ahab_commit command support arm: dts: imx93-phyboard-segin: Add USB support configs: imx93-phyboard-segin: Add USB support configs: imx93-phyboard-segin: Add fastboot support Sumit Garg (10): clk: imx8mp: Add support for PCIe clocks reset: imx: Refactor driver to simplify function names reset: imx: Add support for i.MX8MP reset controller imx8mp: power-domain: Add PCIe support imx8mp: power-domain: Expose high performance PLL clock phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY pci: Add DW PCIe controller support for iMX8MP SoC pcie_imx: Update header to describe it as a legacy driver verdin-imx8mp_defconfig: Enable PCIe/NVMe support MAINTAINERS: Add entry for PCIe DWC IMX driver Tim Harvey (1): imx8mp_venice_defconfig: Enable PCIe/NVMe support Yannic Moog (1): board: phytec: phycore_imx8mp.env fix netboot issues MAINTAINERS| 6 + arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi | 15 ++ arch/arm/include/asm/mach-imx/ele_api.h| 2 + arch/arm/mach-imx/ele_ahab.c | 29 +++ board/phytec/phycore_imx8mp/phycore_imx8mp.env | 4 +- configs/imx8mp_venice_defconfig| 8 + configs/imx93-phyboard-segin_defconfig | 14 + configs/verdin-imx8mp_defconfig| 6 + drivers/clk/imx/clk-imx8mp.c | 6 + drivers/misc/imx_ele/ele_api.c | 32 +++ drivers/pci/Kconfig| 11 + drivers/pci/Makefile | 1 + drivers/pci/pcie_dw_imx.c | 338 + drivers/pci/pcie_imx.c | 8 + drivers/phy/Kconfig| 11 + drivers/phy/Makefile | 1 + drivers/phy/phy-imx8m-pcie.c | 283 + drivers/power/domain/imx8mp-hsiomix.c | 190 +++--- drivers/reset/reset-imx7.c | 143 +-- 19 files changed, 1049 insertions(+), 59 deletions(-) create mode 100644 drivers/pci/pcie_dw_imx.c create mode 100644 drivers/phy/phy-imx8m-pcie.c
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
On Fri, Mar 22, 2024 at 4:31 PM Fabio Estevam wrote: > As Pierre's explanation addresses Marc's concern, > do you think this can go to 2024.01 to fix the boot regression on imx8qxp/8qm? I meant 2024.04, sorry.
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Tom, On Tue, Mar 19, 2024 at 9:39 AM Pierre-Clément Tosi wrote: > For most AArch64 U-Boot ports (including the i.MX family), the answer is > trivial > because they use the arch code i.e. setup_all_pgtables(). However, as > fsl-layerscape re-implements mmu_setup(), it had to be looked at separately, > hence my question, which you answered above. As Pierre's explanation addresses Marc's concern, do you think this can go to 2024.01 to fix the boot regression on imx8qxp/8qm? Thanks
Re: inconsistent wget behavior
Hi Paul, On Sun, Feb 11, 2024 at 4:42 PM Paul Liu wrote: > > Hi Fabio, > > I'm on vacation now (Chinese new year). I hope I'll find some time to revive > my imx8 board. > I've tried sandbox and qemu. Both of them are not reproducible. I'm wondering > if it could be some packet loss that causes the issue. Because sandbox and > qemu there won't be any missing packets because of loopback devices. Have you had a chance to reproduce the issue on your imx8mm board?
Re: [PATCH v4 00/11] imx8mp: Enable PCIe/NVMe support
Hi Sumit, On Thu, Mar 21, 2024 at 11:55 AM Sumit Garg wrote: > Changes in v4: > - Incorporated misc comments from Marek and added his review tag. > - Dropped patch #4 (imx8mp: power-domain: Don't power off pd_bus) > since power domain off path is never excercised for DT based devices. > - Added patch#8 as suggested by Peter to describe older pcie_imx.c > driver as legacy one. v4 looks good, thanks. I'll wait a few days and will queue it to next.
Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions
Hi Lukasz, On Fri, Mar 22, 2024 at 8:43 AM Lukasz Majewski wrote: > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/imx28-xea-1-u-boot.dtsi | 11 > arch/arm/dts/imx28-xea-1.dts | 8 +++ > arch/arm/dts/imx28-xea-2-u-boot.dtsi | 11 > arch/arm/dts/imx28-xea-2.dts | 8 +++ > arch/arm/dts/imx28-xea-u-boot.dtsi| 1 - > .../arm/dts/{imx28-xea.dts => imx28-xea.dtsi} | 0 This rename deviates from the upstream devicetree name. Ideally, we should convert to OF_UPSTREAM available in U-Boot next. > board/liebherr/xea/spl_xea.c | 21 +++--- > board/liebherr/xea/xea.c | 65 +++ > board/liebherr/xea/xea.env| 4 +- > configs/imx28_xea_defconfig | 5 +- > configs/imx28_xea_sb_defconfig| 5 +- > 12 files changed, 128 insertions(+), 14 deletions(-) > create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi > create mode 100644 arch/arm/dts/imx28-xea-1.dts > create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi > create mode 100644 arch/arm/dts/imx28-xea-2.dts > rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%) You should upstream imx28-xea-1.dts and imx28-xea-2.dts first.
Re: [PATCH v3 1/3] arm: dts: imx93-phyboard-segin: Add USB support
Hi Mathieu, On Thu, Mar 21, 2024 at 11:46 AM Mathieu Othacehe wrote: > > Enable both usbotg1 and usbotg2 ports. Disable over-current as OC pins are > not connected to the SoC. > > This is temporary, until USB support is added to imx93-phyboard-segin.dts > in Linux. > > Signed-off-by: Mathieu Othacehe Thanks, this looks better: Reviewed-by: Fabio Estevam
Re: [PATCH v2 0/3] imx93-phyboard-segin: Add USB support.
Hi Mathieu, On Thu, Mar 21, 2024 at 3:57 AM Mathieu Othacehe wrote: > Mathieu Othacehe (3): > arm: dts: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add fastboot support > > arch/arm/dts/imx93-phyboard-segin.dts | 13 + The addition of the i.MX93 USB support in the kernel devicetree is taking longer than expected: https://lore.kernel.org/linux-arm-kernel/20240321081439.541799-8-xu.yan...@nxp.com/T/#u To avoid getting out of sync with the upstream dts, please add the USB nodes inside imx93-phyboard-segin-u-boot.dtsi for now. Thanks
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Pierre, On Tue, Mar 19, 2024 at 8:39 AM Pierre-Clément Tosi wrote: > This means gd->arch.tlb_addr pointing to the live PTs during setup_pgtables(). > > In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset. > > In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice: > > - early_mmu_setup() calls it with SCTLR_ELx.M unset; > - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff >CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if > CONFIG_SYS_SOC="fsl-layerscape" >so that gets auto-included through >. > > So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != "fsl-layerscape"? No, this cannot happen. Only the following Layerscape SoCs select CONFIG_FSL_LAYERSCAPE in arch/arm/cpu/armv8/fsl-layerscape/Kconfig: LS1012A, LS1028A, LS1043A, LS1046A, LS1088A, LS2080A, LX2162A and LX2160A I saw the original boot problem with the i.MX8QX. The i.MX8QX is part of the i.MX family, not the Layerscape family. > I suppose Fabio and Stefano can answer this and/or help with ensuring that > setup_pgtables() is never called on live PTs. Let me know if you need any clarification. Thanks, Fabio Estevam
Re: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries
Hi Tom and Sean, On Fri, Mar 8, 2024 at 5:13 PM Fabio Estevam wrote: > > Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") > the colibri-imx8qxp board no longer boots. > > The reason is that the imx8qxp clock driver does not handle the > LPUART IPG clocks inside get_rate(), set_rate() and enable() functions. > > Fix the boot regression by adding the LPUART IPG entries. > > Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") > Reported-by: Marcel Ziswiler > Signed-off-by: Fabio Estevam Please consider applying this series to 2024.04. It fixes a boot regression on imx8qxp and imx8qm. Thanks!
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Mon, Mar 18, 2024 at 4:59 PM Pierre-Clément Tosi wrote: > I notice that the mem_map in these logs have overlapping ranges, which results > in unnecessary work when creating the PTs. For this reason, it would make > sense > to prune it in arch/arm/mach-imx/imx8/cpu.c before calling dcache_enable(), > IMO. > On this point, you also have contiguous ranges with identical attributes > (mem_map[0] and mem_map[6]), which could be merged into a single entry. This > could result in more efficient MMU mappings if the mem_map entries can share a > block mapping. Also note that mem_map[4].size=0 so could be dropped. > > In any case, if we assume that overlapping mem_map entries are a valid input > to > the arch code (maybe not as it leads to potentially ambiguous behavior?), then > 41e2787f5ec4 had removed support for splitting existing block mappings. > > In your case, my assumption is that the function was then treating block > mappings in the range 0x1c00-0x8000 (which get mapped, at least > partially, by mem_map[0], mem_map[1], then mem_map[2]) as table mappings and > was > issuing read/write instructions in that range (accessing them as PTEs). As > those > seem to be device memory (I see they get mapped as MT_DEVICE_NGNRNE), these > accesses might explain the SError you were experiencing. > > Would you mind testing [1] and giving it "Tested-by:" if it addresses the > issue? Your patch fixed the boot regression. Thanks for your fix, appreciated it! I have replied with my Tested-by tag. Cheers, Fabio Estevam
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Pierre, On Mon, Mar 18, 2024 at 4:35 PM Pierre-Clément Tosi wrote: > > The implementation of map_range() creates the requested mapping by > walking the page tables, iterating over multiple PTEs and/or descending > into existing table mappings as needed. When doing so, it assumes any > pre-existing valid PTE to be a table mapping. This assumption is wrong > if the platform code attempts to successively map two overlapping ranges > where the latter intersects a block mapping created for the former. > > As a result, map_range() treats the existing block mapping as a table > mapping and descends into it i.e. starts interpreting the > previously-mapped range as an array of PTEs, writing to them and > potentially even descending further (extra fun with MMIO ranges!). > > Instead, pass any valid non-table mapping to split_block(), which > ensures that it actually was a block mapping (calls panic() otherwise) > before splitting it. > > Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity") > Signed-off-by: Pierre-Clément Tosi This fixes the boot regression on colibri-imx8x. Thanks a lot for your fix! Tested-by: Fabio Estevam
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On Mon, Mar 18, 2024 at 10:31 AM Fabio Estevam wrote: > I tried dumping the page table entries, but could not notice anything > that looked suspicious. This looks suspicious: With 41e2787f5ec4 reverted: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=6400 blocksize=20 Checking if pte fits for virt=1c20 size=63e0 blocksize=4000 Checking if pte fits for virt=1c20 size=63e0 blocksize=20 Checking if pte fits for virt=1c40 size=63c0 blocksize=4000 In U-Boot master: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=2400 blocksize=20 Checking if pte fits for virt=1c20 size=23e0 blocksize=20 Checking if pte fits for virt=1c40 size=23c0 blocksize=20 The second entry has size=2400 instead of size=6400.
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Fri, Mar 15, 2024 at 12:13 PM Pierre-Clément Tosi wrote: > I had a quick look through your logs and notice that U-Boot master attempts to > map addresses in the high VA range e.g. > > Checking if pte fits for virt=e400 [...] > > while the logs that boot successfully only use the low VA range e.g. > > Checking if pte fits for virt=80193000 [...] > > Unless that has recently changed (since I last worked with U-Boot), U-Boot on > AArch64 only supports identity mappings and therefore was only taught how to > program TTBR0_ELx (i.e. is only able to map low virtual addresses). This means > that the code - with or without 41e2787f5ec4 - would be unable to map > addresses > such as 0xe400. Yes, I found it strange too. I may have done something wrong the last time I instrumented the code. I tried it again and no longer see these unexpected high virtual addresses. Please find the new logs here: https://pastebin.com/raw/qF3GbJry > Now, given that 41e2787f5ec4 only affects implementation details of add_map(), > I am surprised that reverting that commit changes the arguments received by > the > function such as virt. As a reminder, add_map() is exclusively used on > mem_map: > > for (i = 0; mem_map[i].size || mem_map[i].attrs; i++) > add_map(_map[i]); > > > > > That's the only issue preventing colibri-imx8x from booting mainline U-Boot. > > If I read the U-Boot configs right i.e. > > - configs/colibri-imx8x_defconfig: CONFIG_ARCH_IMX8=y > - arch/arm/mach-imx/imx8/Makefile: obj-y += cpu.o > - arch/arm/mach-imx/imx8/cpu.c: struct mm_region *mem_map = imx8_mem_map; Correct, these are the relevant files for the i.MXQ8XP. > There is a possibility that your mem_map is getting modified by MACH-specific > code. In particular, enable_caches() seems to dynamically get the MMU mappings > from some RPC mechanism (see get_owned_memreg() and sc_rm_get_memreg_info()). > > Could it be that whatever services those requests might be returning > unexpected > values? Instrumenting arch/arm/mach-imx/imx8/cpu.c and dumping mem_map (and > the RPC messages) with/without the patch would help clear this up. I tried dumping the page table entries, but could not notice anything that looked suspicious. Please let me know if you have any suggestions. Thanks
Re: [PATCH v1] arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup
On Fri, Mar 15, 2024 at 11:45 AM Vitor Soares wrote: > > From: Vitor Soares > > On imx8m[m|p|q].dtsi, upstream Linux uses different names for NPU/VPU > IP block nodes. It leads variants without such HW block having it > enabled by default. > > This patch adds the upstream Linux node's paths to the disable list while > keep the compatibility with downstream Linux. > > Signed-off-by: Vitor Soares Applied for u-boot-imx/master, thanks.
Re: [PATCH] apalis-imx8: Fix sc_misc_otp_fuse_read() error check
On Tue, Mar 12, 2024 at 9:59 PM Fabio Estevam wrote: > > Commit bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") > made an incorrect logic change in the error code check of > sc_misc_otp_fuse_read(): > > - if (scierr == SC_ERR_NONE) { > + if (scierr) { > /* QP has one A72 core disabled */ > is_quadplus = ((val >> 4) & 0x3) != 0x0; > } > > The other changes in this commit are correct. > > sc_misc_otp_fuse_read() returns 0 on a successful fuse read. > > This inversion causes board_mem_get_layout() to report incorrect RAM size. > > Go back the original error check logic to fix the problem. > > Fixes: bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") > Signed-off-by: Fabio Estevam Applied for u-boot-imx/master, thanks.
Re: [PATCH] colibri-imx8x: Fix sc_misc_otp_fuse_read() error check
On Tue, Mar 12, 2024 at 9:36 PM Fabio Estevam wrote: > > Commit aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") > made an incorrect logic change in the error code check of > sc_misc_otp_fuse_read(): > > - if (sc_err == SC_ERR_NONE) { > + if (sc_err) { > /* DX has two A35 cores disabled */ > return (val & 0xf) != 0x0; > } > > The other changes in this commit are correct. > > sc_misc_otp_fuse_read() returns 0 on a successful fuse read. > > This inversion causes board_mem_get_layout() to report incorrect RAM size. > > Go back the original error check logic to fix the problem. > > Fixes: aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") > Reported-by: Hiago De Franco > Signed-off-by: Fabio Estevam Applied for u-boot-imx/master, thanks.
Re: [PATCH] imx8m*_venice: move venice to OF_UPSTREAM
On Tue, Mar 12, 2024 at 10:16 PM Fabio Estevam wrote: > > Hi Tim, > > On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey wrote: > > > > Move to imx8m{m,n,p}-venice to OF_UPSTREAM: > > - replace the non-upstream generic imx8m{m,n,p}-venice dt with one of the > >dt's from the OF_LIST > > - handle the fact that dtbs now have a 'freescale/' prefix > > - imply OF_UPSTREAM > > - remove rudundant files from arch/arm/dts leaving only the > >*-u-boot.dtsi files > > > > Signed-off-by: Tim Harvey > ... > > 33 files changed, 13 insertions(+), 10658 deletions(-) > > This diff looks great :-) > > Reviewed-by: Fabio Estevam Applied for u-boot-imx/next, thanks.
Re: [PATCH v2 0/5] Add RAUC boot logic for phycore_imx8mp
On Tue, Mar 12, 2024 at 6:00 AM Leonard Anderweit wrote: > > This series adds RAUC boot logic for the phycore_imx8mp. > The first patch converts the environment from a CFG_EXTRA_ENV_SETTINGS #define > to a text environment for better readability and maintainability. > The second patch moves the default bootcmd from the defconfig to the board > environment. > The third patch enables the redundant environment on phycore_imx8mp. > Patch 4 adds RAUC boot logic common to all phytec boards. > Patch 5 adds the RAUC boot logic to phycore_imx8mp. > > v2: > - rebase on next Applied series for u-boot-imx/next, thanks.
Re: [PATCH] board: phytec: define get_som_type also when SoM detection is disabled
On Tue, Mar 12, 2024 at 6:39 AM Benjamin Hahn wrote: > > define the phytec_get_som_type function also when the SoM detection is > disabled. > > Fixes: > commit 110d321a56c3 ("board: phytec: common: phytec_som_detection: Add > phytec_get_som_type") > > Signed-off-by: Benjamin Hahn Applied for u-boot-imx/master, thanks.
Re: [PATCH v1] configs: colibri-imx7: enable watchdog
On Thu, Mar 7, 2024 at 12:23 PM Parth Pancholi wrote: > > From: Parth Pancholi > > Enable watchdog functionality for Toradex's Colibri iMX7 (NAND/EMMC) > modules. > > Signed-off-by: Parth Pancholi Applied for u-boot-imx/next, thanks.
Re: [PATCH] drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node
On Mon, Mar 4, 2024 at 8:49 AM Benjamin Hahn wrote: > > The polling rate is already specified in some devicetrees, like > imx8mp.dtsi for example, but was not selected so far. For the > trippoints, the cpu-thermal node is used. Also get the polling rate from > this node. Use the default of 5000ms if the polling rate should not be > specified in the devicetree. > > NOTE: The polling rate from the devicetree will be used after this > patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for > example. > > Signed-off-by: Benjamin Hahn Applied for u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240317
Hi Tom, Please pull this material for next from u-boot-imx, thank The following changes since commit 099c94b7613bb10d97936447f5136f3a36694325: Merge tag 'u-boot-rockchip-20240315' of https://source.denx.de/u-boot/custodians/u-boot-rockchip into next (2024-03-15 09:15:31 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-next-20240317 for you to fetch changes up to 86b79cf131b64eadae023a127921893d30503093: imx8m*_venice: move venice to OF_UPSTREAM (2024-03-17 18:39:54 -0300) u-boot-imx-next-20240317 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19975 - Select polling-rate from cpu-thermal devicetree node on imx_tmu. - Re-organize the U-Boot environment and add RAUC logic for phycore_imx8mp. - Enable watchdog on colibri-imx7. - Move imx8mm-venice to use OF_UPSTREAM. Benjamin Hahn (1): drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node Leonard Anderweit (5): phycore_imx8mp: Move environment from include/config to board phycore_imx8mp: Move default bootcmd to board env configs: phycore-imx8mp_defconfig: Use redundant environment include: env: Add phytec RAUC boot logic board: phytec: phycore_imx8mp: Add RAUC boot logic to environment Parth Pancholi (1): configs: colibri-imx7: enable watchdog Tim Harvey (1): imx8m*_venice: move venice to OF_UPSTREAM arch/arm/dts/Makefile | 17 - arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi |4 + arch/arm/dts/imx8mm-venice-gw700x.dtsi | 525 --- arch/arm/dts/imx8mm-venice-gw71xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw71xx.dtsi | 239 - arch/arm/dts/imx8mm-venice-gw72xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw72xx.dtsi | 400 - arch/arm/dts/imx8mm-venice-gw73xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw73xx.dtsi | 452 -- arch/arm/dts/imx8mm-venice-gw7901.dts | 1137 arch/arm/dts/imx8mm-venice-gw7902.dts | 1052 -- arch/arm/dts/imx8mm-venice-gw7903.dts | 869 -- arch/arm/dts/imx8mm-venice-gw7904.dts | 928 --- arch/arm/dts/imx8mm-venice-gw7905-0x.dts | 28 - arch/arm/dts/imx8mm-venice-gw7905.dtsi | 303 --- arch/arm/dts/imx8mm-venice.dts | 169 arch/arm/dts/imx8mn-venice-gw7902.dts | 980 arch/arm/dts/imx8mn-venice.dts | 169 arch/arm/dts/imx8mp-venice-gw702x.dtsi | 587 arch/arm/dts/imx8mp-venice-gw71xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw71xx.dtsi | 236 - arch/arm/dts/imx8mp-venice-gw72xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw72xx.dtsi | 378 arch/arm/dts/imx8mp-venice-gw73xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw73xx.dtsi | 421 - arch/arm/dts/imx8mp-venice-gw74xx.dts | 1125 --- arch/arm/dts/imx8mp-venice-gw7905-2x.dts | 28 - arch/arm/dts/imx8mp-venice-gw7905.dtsi | 309 --- arch/arm/dts/imx8mp-venice.dts | 183 arch/arm/mach-imx/imx8m/Kconfig|3 + board/gateworks/venice/venice.c|7 +- board/phytec/phycore_imx8mp/phycore_imx8mp.env | 62 ++ configs/colibri_imx7_defconfig |2 + configs/colibri_imx7_emmc_defconfig|2 + configs/imx8mm_venice_defconfig|4 +- configs/imx8mn_venice_defconfig|4 +- configs/imx8mp_venice_defconfig|4 +- configs/phycore-imx8mp_defconfig |4 +- drivers/thermal/imx_tmu.c |6 +- include/configs/phycore_imx8mp.h | 43 - include/env/phytec/rauc.env| 52 ++ 41 files changed, 141 insertions(+), 10705 deletions(-) delete mode 100644 arch/arm/dts/imx8mm-venice-gw700x.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw71xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw71xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw72xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw72xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw73xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw73xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw7901.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7902.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7903.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7904.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7905-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7905.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice.dts delete mode 100644
[GIT PULL] Please pull u-boot-imx-master-20240317
Hi Tom, Please pull these fixes from u-boot-imx, thanks. The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496: Merge tag 'efi-2024-04-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240317 for you to fetch changes up to e648c4a3455a4d1880efe121602ed90a0bc9b53f: arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup (2024-03-17 18:00:04 -0300) u-boot-imx-master-20240317 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19974 - Fix build error when SoM detection on Phytec board. - Fix sc_misc_otp_fuse_read() error check on colibri-imx8x/apalis-imx8. - Fix NPU/VPU fdt disable fixup on i.MX8M. Benjamin Hahn (1): board: phytec: define get_som_type also when SoM detection is disabled Fabio Estevam (2): colibri-imx8x: Fix sc_misc_otp_fuse_read() error check apalis-imx8: Fix sc_misc_otp_fuse_read() error check Vitor Soares (1): arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup arch/arm/mach-imx/imx8m/soc.c | 18 ++ board/phytec/common/phytec_som_detection.c | 5 + board/toradex/apalis-imx8/apalis-imx8.c | 2 +- board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- 4 files changed, 21 insertions(+), 6 deletions(-)
Re: [PATCH v1] doc: board: colibri-imx8x: Update and improve documentation
Hi Hiago, On Fri, Mar 15, 2024 at 11:39 AM Hiago De Franco wrote: > > From: Hiago De Franco > > Update and improve the building documentation of Colibri iMX8X. > The following changes were made: > - imx-atf repository changed to nxp-imx GitHub. > - imx-atf branch updated to 'lf_v2.6'. > - imx-seco updated to version 5.8.7. > - nxp-imx mfgtools link updated to GitHub releases. > - General writing improvements. Thanks for improving the documentation. One minor suggestion. I have recently followed this document and noticed that the instruction to copy the mx8qm-apalis-scfw-tcm.bin to the U-Boot source is missing. Please add it. Also, since you are updating several components, shouldn't mx8qm-apalis-scfw-tcm.bin be updated? Currently, the version is from toradex-sumo-4.14.78-1.0.0_ga-bringup which looks quite ancient.
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Marc, On Sat, Mar 9, 2024 at 11:36 AM Fabio Estevam wrote: > Does the log below help? > > https://pastebin.com/raw/1i1VBA0a > > If not, please send me a debug patch and I will be glad to run it here. I'm sorry to bother you, but have you had a chance to look at the log I shared with you? That's the only issue preventing colibri-imx8x from booting mainline U-Boot. We would like to get this fixed for U-Boot 2024.04. Thanks for your help
Re: [PATCH] imx8m*_venice: move venice to OF_UPSTREAM
Hi Tim, On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey wrote: > > Move to imx8m{m,n,p}-venice to OF_UPSTREAM: > - replace the non-upstream generic imx8m{m,n,p}-venice dt with one of the >dt's from the OF_LIST > - handle the fact that dtbs now have a 'freescale/' prefix > - imply OF_UPSTREAM > - remove rudundant files from arch/arm/dts leaving only the >*-u-boot.dtsi files > > Signed-off-by: Tim Harvey ... > 33 files changed, 13 insertions(+), 10658 deletions(-) This diff looks great :-) Reviewed-by: Fabio Estevam I will queue it to u-boot-imx/next soon.
[PATCH] apalis-imx8: Fix sc_misc_otp_fuse_read() error check
Commit bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") made an incorrect logic change in the error code check of sc_misc_otp_fuse_read(): - if (scierr == SC_ERR_NONE) { + if (scierr) { /* QP has one A72 core disabled */ is_quadplus = ((val >> 4) & 0x3) != 0x0; } The other changes in this commit are correct. sc_misc_otp_fuse_read() returns 0 on a successful fuse read. This inversion causes board_mem_get_layout() to report incorrect RAM size. Go back the original error check logic to fix the problem. Fixes: bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") Signed-off-by: Fabio Estevam --- board/toradex/apalis-imx8/apalis-imx8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/toradex/apalis-imx8/apalis-imx8.c b/board/toradex/apalis-imx8/apalis-imx8.c index 2483a63c6733..49719f2f5533 100644 --- a/board/toradex/apalis-imx8/apalis-imx8.c +++ b/board/toradex/apalis-imx8/apalis-imx8.c @@ -133,7 +133,7 @@ void board_mem_get_layout(u64 *phys_sdram_1_start, struct tdx_user_fuses tdxramfuses; int scierr = sc_misc_otp_fuse_read(-1, 6, ); - if (scierr) { + if (!scierr) { /* QP has one A72 core disabled */ is_quadplus = ((val >> 4) & 0x3) != 0x0; } -- 2.34.1
Re: [PATCH] ARM: imx: stm32: Test whether ethernet node is enabled before reading MAC EEPROM on DHSOM
Hi Marek, On Tue, Mar 12, 2024 at 6:16 PM Marek Vasut wrote: > NOTE: It is probably best if this goes in via either imx or stm32 tree, > I can break the patch up, but that would introduce dependency > between two PRs in different trees. Let me know what you prefer. I can apply it to u-boot-imx next if Patrice and Patrick are OK.
[PATCH] colibri-imx8x: Fix sc_misc_otp_fuse_read() error check
Commit aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") made an incorrect logic change in the error code check of sc_misc_otp_fuse_read(): - if (sc_err == SC_ERR_NONE) { + if (sc_err) { /* DX has two A35 cores disabled */ return (val & 0xf) != 0x0; } The other changes in this commit are correct. sc_misc_otp_fuse_read() returns 0 on a successful fuse read. This inversion causes board_mem_get_layout() to report incorrect RAM size. Go back the original error check logic to fix the problem. Fixes: aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") Reported-by: Hiago De Franco Signed-off-by: Fabio Estevam --- board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/toradex/colibri-imx8x/colibri-imx8x.c b/board/toradex/colibri-imx8x/colibri-imx8x.c index 2c673a4a6b06..6fc8076163c6 100644 --- a/board/toradex/colibri-imx8x/colibri-imx8x.c +++ b/board/toradex/colibri-imx8x/colibri-imx8x.c @@ -46,7 +46,7 @@ static int is_imx8dx(void) u32 val = 0; int sc_err = sc_misc_otp_fuse_read(-1, 6, ); - if (sc_err) { + if (!sc_err) { /* DX has two A35 cores disabled */ return (val & 0xf) != 0x0; } -- 2.34.1
Re: [PATCH 3/5] configs: phycore-imx8mp_defconfig: Use redundant environment
Hi Leonard, On Mon, Mar 11, 2024 at 11:32 AM Leonard Anderweit wrote: > I also got an error while applying this to next. To apply cleanly this > series requires the commit 19f657600781 (configs: Resync with > savedefconfig) which is on master but not on next. > > If this missing commit is intended I'll resend this series based on > next. At this point, the master branch is open only for bug fixes. This series is targeted at the next branch, so please send a v2 based on next and I will apply it.
Re: [PATCH 3/5] configs: phycore-imx8mp_defconfig: Use redundant environment
Hi Leonard, On Mon, Mar 11, 2024 at 10:04 AM Leonard Anderweit wrote: > > Add support for the redundant environment. > > Signed-off-by: Leonard Anderweit Please rebase this series against U-Boot next branch and resend. There is an error while applying this patch against next. Thanks
Re: [PATCH] arm: dts: imx8mp-beacon-kit: Resync DTS with Linux 6.8
On Sun, Mar 10, 2024 at 1:59 PM Adam Ford wrote: > > The device tree has evolved over time, so re-sync. This also > partial reverts one change on the PCIe, because U-Boot doesn't > have a proper driver. However, since the clock is configured > to generate a 100MHz reference clock by default, a proper driver > isn't really necessary. > > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH] toradex: tdx-cfg-block: add 0087 i.mx8m mini product variant
On Fri, Mar 8, 2024 at 11:18 AM Joao Paulo Goncalves wrote: > > From: Joao Paulo Goncalves > > Add new product id 0087 Verdin iMX8M Mini Quad 2GB IT. > > Signed-off-by: Joao Paulo Goncalves Applied, thanks.
Re: [PATCH] configs: imx8mp_beacon: Fall back to using TF-A
On Thu, Mar 7, 2024 at 8:59 AM Adam Ford wrote: > > When the board was originally added, it enabled some features which > allowed it to bypass Trusted Firmware, but as the feature set of > Linux grew and more features became available, the U-Boot config > options which bypassed TF-A caused issues, so it needs to return > to the standard operating mode of using TF-A or the system no > longer boots. > > Fixes: ab53bd43dbde ("arm64: imx: Add support for imx8mp-beacon-kit") > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH v3 0/2] board: phytec_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1
On Wed, Mar 6, 2024 at 1:18 PM Benjamin Hahn wrote: > > PCL-070 supports 2GHz RAM-timings from pcb_rev 1 and newer. PCM-070 > supports 2GHz RAM-timings only from pcb_rev 3 and newer. > > Signed-off-by: Benjamin Hahn Applied all, thanks.
[GIT PULL] Please pull u-boot-imx-master-20240311
Hi Tom, Please pull from u-boot-imx, thanks. The following changes since commit 0981f8900f2b1f45a3f282b704012b5374fdd7a6: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2024-03-09 11:29:48 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240311 for you to fetch changes up to 4484c7b3c38dcb21244a882d0b81d141db1ed162: arm: dts: imx8mp-beacon-kit: Resync DTS with Linux 6.8 (2024-03-11 08:43:42 -0300) u-boot-imx-master-20240311 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19896 - Use TF-A on imx8mp_beacon to fix boot regression. - Use latest 6.8 dts for imx8mp_beacon. - Fix the RAM initialization for phycore_imx8mp PCL-070 rev 1. - Describe the 0087 i.mx8m mini product variant in tdx-cfg-block. Adam Ford (2): configs: imx8mp_beacon: Fall back to using TF-A arm: dts: imx8mp-beacon-kit: Resync DTS with Linux 6.8 Benjamin Hahn (2): board: phytec: common: phytec_som_detection: Add phytec_get_som_type board: phycore_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1 Joao Paulo Goncalves (1): toradex: tdx-cfg-block: add 0087 i.mx8m mini product variant arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi | 11 ++ arch/arm/dts/imx8mp-beacon-kit.dts | 245 - arch/arm/dts/imx8mp-beacon-som.dtsi| 71 + board/phytec/common/phytec_som_detection.c | 10 ++ board/phytec/common/phytec_som_detection.h | 8 + board/phytec/phycore_imx8mp/spl.c | 6 +- board/toradex/common/tdx-cfg-block.c | 1 + board/toradex/common/tdx-cfg-block.h | 1 + configs/imx8mp_beacon_defconfig| 7 - 9 files changed, 345 insertions(+), 15 deletions(-)
Re: [PATCH v1] configs: colibri-imx7: enable watchdog
Hi Francesco, On Mon, Mar 11, 2024 at 8:34 AM Francesco Dolcini wrote: > No, on colibri-imx7 the reset is already working, it uses the PMIC so > it's not affected by the issue that was affecting most of our other > boards. > > The reason for enabling the watchdog here is just an improvement to > improve reliability, given we have it enabled on other boards with no > drawback it seems nice and consistent to enable it. Thanks for the clarification. In this case, I will apply it to u-boot-imx next branch.
Re: [PATCH v1] configs: colibri-imx7: enable watchdog
Hi Parth, On Thu, Mar 7, 2024 at 12:23 PM Parth Pancholi wrote: > > From: Parth Pancholi > > Enable watchdog functionality for Toradex's Colibri iMX7 (NAND/EMMC) > modules. You described what the patch does, but the reason is missing. Is the reason for this patch to fix the 'reset' command regression like you did at: https://gitlab.com/u-boot/u-boot/-/commit/be23b1331fb35b7d5a095ef2c0b522c1f241eee9 ? Please send a v2 with an improved commit log.
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On Sat, Mar 9, 2024 at 9:39 AM Marc Zyngier wrote: > Can you figure out what memory access is triggering it? Even at > narrowing it to the subsystem level would be a good indication. The problem happens so early that I am not able to narrow it down at subsystem level. > You could just dump the entries as they are written. The order may not > be the same, but for a given VA you should observe the same entries > being written. Does the log below help? https://pastebin.com/raw/1i1VBA0a If not, please send me a debug patch and I will be glad to run it here. Thanks
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Marc, On Sat, Mar 9, 2024 at 6:53 AM Marc Zyngier wrote: > It would be good to narrow down which access is generating this. It is > an asynchronous error, so the code above won't help. > > Alternatively, and if you are sure that this is due to this change, > dumping the page tables and comparing them before and after would > help. Yes, I am sure the error is due to this change. It is 100% reproducible. I am not familiar with this part of the code, so I would appreciate it if you could tell me how to dump the page tables so I can compare them before and after. Thanks, Fabio Estevam
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Paul and Tom, On Tue, Feb 14, 2023 at 10:38 AM Ying-Chun Liu (PaulLiu) wrote: > > From: Marc Zyngier > > In the add_map() function, for each level it populates, it iterates from > the root of the PT tree, making it ineficient if a mapping needs to occur > past level 1. > > Instead, replace it with a recursive (and much simpler) algorithm > that keeps the complexity as low as possible. With this, mapping > 512GB at level 2 goes from several seconds down to not measurable > on an A55 machine. > > We keep the block mappings at level 1 for now though. > > Signed-off-by: Marc Zyngier > Signed-off-by: Pierre-Clément Tosi > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the > upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Tom Rini > Link: > https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6 > Link: > https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059 I know this is an old thread, but this commit causes the following boot regression on a colibri-imx8qxp board: U-Boot 2024.04-rc3-00070-gecc9298a893b (Mar 08 2024 - 17:15:31 -0300) CPU: NXP i.MX8QXP RevC A35 at 1200 MHz at 51C DRAM: 2 GiB "Error" handler, esr 0xbf00 elr: 80020914 lr : 800209c0 (reloc) elr: ffec4914 lr : ffec49c0 x0 : 006070800401 x1 : 7000 x2 : 1000 x3 : 0002 x4 : 4000 x5 : 00600401 x6 : 0c00 x7 : fff45140 x8 : 0060 x9 : fff45100 x10: 0a200023 x11: 0002 x12: 0002 x13: 800a10e8 x14: x15: ffec4cb8 x16: 80056a88 x17: x18: fd6c1d70 x19: 0f60 x20: x21: 00600401 x22: 70a0 x23: 0020 x24: 4c28 x25: 001f x26: 0003 x27: 70a0 x28: 0002 x29: fd6bbfd0 Code: 1100047a a90573fb aa0103fb 2a0303fc (b5000113) Resetting CPU ... resetting ... Reverting this commit on top of master fixes the boot regression. Any ideas? Thanks
[PATCH 2/2] clk: clk-imx8qm: Add LPUART IPG entries
Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") the apalis-imx8qm board no longer boots. The reason is that the imx8qm clock driver does not handle the LPUART IPG clocks inside get_rate(), set_rate() and enable() functions. Fix the boot regression by adding the LPUART IPG entries. Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") Reported-by: Marcel Ziswiler Signed-off-by: Fabio Estevam --- drivers/clk/imx/clk-imx8qm.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c index 6c05d07c340..01e33de9d63 100644 --- a/drivers/clk/imx/clk-imx8qm.c +++ b/drivers/clk/imx/clk-imx8qm.c @@ -95,20 +95,23 @@ ulong imx8_clk_get_rate(struct clk *clk) resource = SC_R_SDHC_2; pm_clk = SC_PM_CLK_PER; break; - case IMX8QM_UART0_IPG_CLK: case IMX8QM_UART0_CLK: + case IMX8QM_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART1_CLK: + case IMX8QM_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART2_CLK: + case IMX8QM_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART3_CLK: + case IMX8QM_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; @@ -181,18 +184,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long rate) pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART0_CLK: + case IMX8QM_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART1_CLK: + case IMX8QM_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART2_CLK: + case IMX8QM_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART3_CLK: + case IMX8QM_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; @@ -283,18 +290,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable) pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART0_CLK: + case IMX8QM_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART1_CLK: + case IMX8QM_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART2_CLK: + case IMX8QM_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QM_UART3_CLK: + case IMX8QM_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; -- 2.34.1
[PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries
Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") the colibri-imx8qxp board no longer boots. The reason is that the imx8qxp clock driver does not handle the LPUART IPG clocks inside get_rate(), set_rate() and enable() functions. Fix the boot regression by adding the LPUART IPG entries. Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") Reported-by: Marcel Ziswiler Signed-off-by: Fabio Estevam --- drivers/clk/imx/clk-imx8qxp.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c index 8bf7e325481..d900d4cd528 100644 --- a/drivers/clk/imx/clk-imx8qxp.c +++ b/drivers/clk/imx/clk-imx8qxp.c @@ -88,20 +88,23 @@ ulong imx8_clk_get_rate(struct clk *clk) resource = SC_R_SDHC_1; pm_clk = SC_PM_CLK_PER; break; - case IMX8QXP_UART0_IPG_CLK: case IMX8QXP_UART0_CLK: + case IMX8QXP_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART1_CLK: + case IMX8QXP_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART2_CLK: + case IMX8QXP_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART3_CLK: + case IMX8QXP_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; @@ -170,18 +173,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long rate) pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART0_CLK: + case IMX8QXP_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART1_CLK: + case IMX8QXP_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART2_CLK: + case IMX8QXP_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART3_CLK: + case IMX8QXP_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; @@ -263,18 +270,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable) pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART0_CLK: + case IMX8QXP_UART0_IPG_CLK: resource = SC_R_UART_0; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART1_CLK: + case IMX8QXP_UART1_IPG_CLK: resource = SC_R_UART_1; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART2_CLK: + case IMX8QXP_UART2_IPG_CLK: resource = SC_R_UART_2; pm_clk = SC_PM_CLK_PER; break; case IMX8QXP_UART3_CLK: + case IMX8QXP_UART3_IPG_CLK: resource = SC_R_UART_3; pm_clk = SC_PM_CLK_PER; break; -- 2.34.1
Re: U-boot fails for khadas-edge -v
On Thu, Mar 7, 2024 at 2:43 PM Vivek Jaiswal wrote: > are you saying to use this one? > https://github.com/u-boot/u-boot/blob/master/configs/khadas-edge-v-rk3399_defconfig Yes, this one.
Re: [PATCH] configs: imx8mp_beacon: Fall back to using TF-A
Hi Adam, On Thu, Mar 7, 2024 at 8:59 AM Adam Ford wrote: > > When the board was originally added, it enabled some features which > allowed it to bypass Trusted Firmware, but as the feature set of > Linux grew and more features became available, the U-Boot config > options which bypassed TF-A caused issues, so it needs to return > to the standard operating mode of using TF-A or the system no > longer boots. > > Fixes: ab53bd43dbde ("arm64: imx: Add support for imx8mp-beacon-kit") > Signed-off-by: Adam Ford Reviewed-by: Fabio Estevam I will queue it as a fix soon.
Re: [PATCH v3 0/2] board: phytec_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1
Hi Benjamin, On Wed, Mar 6, 2024 at 1:18 PM Benjamin Hahn wrote: > > PCL-070 supports 2GHz RAM-timings from pcb_rev 1 and newer. PCM-070 > supports 2GHz RAM-timings only from pcb_rev 3 and newer. > > Signed-off-by: Benjamin Hahn v3 looks good. Is this material for U-Boot 2024.04 or 2024.07?
Re: U-boot fails for khadas-edge -v
Hi Vivek, On Thu, Mar 7, 2024 at 11:56 AM Vivek Jaiswal wrote: > > Hello U-boot Team, > I am using the u-boot for Khadas Edge-v rk3399 rockchip: > https://github.com/khadas/u-boot/tree/khadas-edges-v2017.09-release-v1.0.0?tab=readme-ov-file > And I am using configuration file : > https://github.com/khadas/u-boot/blob/khadas-edges-v2017.09-release-v1.0.0/configs/rk3399_defconfig That's an old out-of-tree repository, not supported by the U-Boot community. Try khadas-edge-v-rk3399_defconfig which is supported in mainline U-Boot.
Re: FEAT_CCIDX not tested when parsing ccsidr_el1
Hi Łukasz, On Wed, Mar 6, 2024 at 3:21 PM Łukasz Więcaszek wrote: > I have already prepared a patch for our work related product and now I > am thinking of mainstreaming that piece of work. What do you think > about that? Please send a formal patch via git send-email.
Re: [PATCH v2 2/2] board: phycore_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1
On Mon, Mar 4, 2024 at 1:04 PM Benjamin Hahn wrote: > - ret = phytec_get_rev(NULL); > - if (ret >= 3 && ret != PHYTEC_EEPROM_INVAL) { > + u8 rev = phytec_get_rev(NULL); > + u8 somtyp = phytec_get_som_type(NULL); Nitpick: Better to spell out 'somtype' or 'som_type' to make it clearer. "typ" usually means 'typical'.
Re: [PATCH v2 1/2] board: phytec: common: phytec_som_detection: Add phytec_get_som_type
On Mon, Mar 4, 2024 at 1:04 PM Benjamin Hahn wrote: > +enum phytec_som_type_str { > + PCM = 0, > + PCL, > + KSM, > + KSP, > +}; To avoid potential name clashes in the future, I suggest adding a prefix like: SOM_TYPE_PCM = 0, SOM_TYPE_PCL, ... > + > static const char * const phytec_som_type_str[] = { > "PCM", > "PCL", > @@ -67,5 +74,6 @@ void __maybe_unused phytec_print_som_info(struct > phytec_eeprom_data *data); > > char * __maybe_unused phytec_get_opt(struct phytec_eeprom_data *data); > u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data *data); > +u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data); > > #endif /* _PHYTEC_SOM_DETECTION_H */ > > -- > 2.34.1 >
Re: [PATCH] drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node
On Mon, Mar 4, 2024 at 8:49 AM Benjamin Hahn wrote: > > The polling rate is already specified in some devicetrees, like > imx8mp.dtsi for example, but was not selected so far. For the > trippoints, the cpu-thermal node is used. Also get the polling rate from > this node. Use the default of 5000ms if the polling rate should not be > specified in the devicetree. > > NOTE: The polling rate from the devicetree will be used after this > patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for > example. > > Signed-off-by: Benjamin Hahn Reviewed-by: Fabio Estevam
Re: [PATCH 1/2] opos6uldev: make the LCD work again
On Tue, Feb 27, 2024 at 12:40 PM Sébastien Szymanski wrote: > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with > linux") removed the display timings from the board device tree whereas > they are still needed by the mxsfb driver. > Add the timings back (the correct ones) in the > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the > opos6uldev.env file. > > Update the opos6uldev_defconfig file so that the LCD turns on at boot. > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with linux") > Signed-off-by: Sébastien Szymanski Applied all, thanks.
Re: [PATCH] imx9: Update to mx93 A1 chip revision.
On Mon, Feb 26, 2024 at 2:48 PM Mathieu Othacehe wrote: > > Use the latest, mx93a1-ahab-container.img that is compatible with the > i.MX93 A1 revision. > > Using mx93a1-ahab-container.img on an A0 chip and conversely causes a boot > failure without any traces on the UART. > > Signed-off-by: Mathieu Othacehe Applied, thanks.
Re: [PATCH 0/2] Fix OP-TEE support
On Mon, Feb 26, 2024 at 2:37 PM Mathieu Othacehe wrote: > > Hello, > > This series fixes OP-TEE support on all imx9 boards by starting the ELE RNG > and adding the optional tee.bin binary to the ATF container. > > Thanks, > > Mathieu > > Mathieu Othacehe (2): > imx9: Fix OP-TEE support > tools: imx9_image: Reword warning message. Applied all, thanks.
[GIT PULL] Please pull u-boot-imx-master-20240304
Hi Tom, Please pull from u-boot-imx, thanks. The following changes since commit eac52e4be4e234d563d6911737ee7ccdc0ada1f1: Merge patch series "ARM: renesas: Rename R-Mobile to Renesas" (2024-03-02 14:30:25 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240304 for you to fetch changes up to 9b9f022e7368cacafa368beaa7fadd931f2cfcdb: video: mxsfb: add back imx6ul/imx6ull support (2024-03-04 08:18:48 -0300) u-boot-imx-master-20240304 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19817 - Fix i.MX93 OP-TEE support. - Use the container image for i.MX93 revision A1. - Fix display regression on opos6uldev. Mathieu Othacehe (3): imx9: Fix OP-TEE support tools: imx9_image: Reword warning message. imx9: Update to mx93 A1 chip revision. Sébastien Szymanski (2): opos6uldev: make the LCD work again video: mxsfb: add back imx6ul/imx6ull support arch/arm/dts/imx6ul-opos6uldev-u-boot.dtsi | 28 ++-- arch/arm/mach-imx/imx9/container.cfg | 3 ++- arch/arm/mach-imx/imx9/imximage.cfg| 2 +- board/armadeus/opos6uldev/opos6uldev.env | 1 - board/freescale/imx93_evk/spl.c| 7 +++ board/phytec/phycore_imx93/spl.c | 7 +++ board/variscite/imx93_var_som/spl.c| 6 ++ configs/opos6uldev_defconfig | 3 --- doc/board/nxp/imx93_11x11_evk.rst | 8 doc/board/phytec/imx93-phyboard-segin.rst | 8 doc/board/variscite/imx93_var_som.rst | 8 drivers/video/mxsfb.c | 1 + tools/imx9_image.sh| 2 +- 13 files changed, 59 insertions(+), 25 deletions(-)
Re: [PATCH 1/2] board: phytec: common: phytec_som_detection: Add phytec_get_som_type
On Mon, Mar 4, 2024 at 9:31 AM Benjamin Hahn wrote: > > Add a function that gets the som_type from the EEPROM. > Add an enum for the som_type. > > Signed-off-by: Benjamin Hahn Your series does not even build: board/phytec/common/phytec_som_detection.c: In function ‘phytec_get_som_type’: board/phytec/common/phytec_som_detection.c:210:18: error: ‘struct phytec_eeprom_data’ has no member named ‘valid’ 210 | if (!data->valid || data->data.api_rev < PHYTEC_API_REV2) | ^~ board/phytec/common/phytec_som_detection.c:210:39: error: ‘union ’ has no member named ‘api_rev’ 210 | if (!data->valid || data->data.api_rev < PHYTEC_API_REV2) | ^ board/phytec/common/phytec_som_detection.c:213:26: error: ‘union ’ has no member named ‘data’ 213 | return data->data.data.data_api2.som_type; | ^ board/phytec/common/phytec_som_detection.c:214:1: warning: control reaches end of non-void function [-Wreturn-type] 214 | } | ^
Re: [PATCH 1/2] opos6uldev: make the LCD work again
On Mon, Mar 4, 2024 at 10:35 AM Tom Rini wrote: > For v2024.04 yes, this is fine. For long term, we should parse the new > timing properties that the simple panel driver takes in our simple panel > driver instead. Sounds good. Sébastien, please follow Tom's suggestion when you have a chance. Thanks.
Re: [PATCH 1/2] opos6uldev: make the LCD work again
Hi Tom, On Tue, Feb 27, 2024 at 12:42 PM Tom Rini wrote: > What's the long term fix here? Why aren't these needed in Linux anymore, > and perhaps why was it OK to remove them? This is perhaps another case > where we as the U-Boot community need to go and talk with some Linux > Kernel community people. Thanks. To fix the issue for 2024.04 I suggest that this series gets applied. In the long term, I suggest Sébastien send a patch to the Linux DT to add back the panel timings. Do you agree? If so, I can apply it to u-boot-imx master. Thanks
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
On Mon, Mar 4, 2024 at 9:15 AM Sumit Garg wrote: > I suppose the earlier reference patch wasn't complete, can you rather > try its v4 [1] instead? > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20240304121257.3551104-1-sumit.g...@linaro.org/ This one works, thanks!
Re: [PATCH v4] Makefile: remove hardcoded device tree source directory
On Mon, Mar 4, 2024 at 9:13 AM Sumit Garg wrote: > > From: Bryan Brattlof > > Some boards that choose to utilize the OF_UPSTREAM directory for their > device tree files will need to specify that directory instead of the > traditional arch/$(ARCH)/dts/* path. > > Include the correct path to the board's dtbs depending on if OF_UPSTREAM > is selected or not. > > Signed-off-by: Bryan Brattlof > Signed-off-by: Sumit Garg Tested-by: Fabio Estevam
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Sumit, On Mon, Mar 4, 2024 at 3:33 AM Sumit Garg wrote: > I think you also need Bryan's patch [1] to be incorporated as well. > Give it a try and let me know if you still see any further issues. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20240205-am62px-wip-rebasing-v3-11-04cbb42ea...@ti.com/ I applied this patch, but now I get a different error: BINMAN .binman_stamp Wrote map file './itb.map' to show errors binman: Filename 'freescale/imx8mp-evk.dtb' not found in input path (.,.,./board/freescale/imx8mp_evk,arch/arm/dts) (cwd='/home/fabio/denx/u-boot') make: *** [Makefile:1126: .binman_stamp] Error 1
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Sumit, On Fri, Mar 1, 2024 at 9:57 AM Tom Rini wrote: > > On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: > > > Changes in v6: > > -- > > - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > > - Patch #3: Incorporate fix for sandbox CI failure. > > - Patch #6: Incorporate shell script comments from Marek. > > - Patch #8: Incorporate documentation review comments from Paul. > > > > [...] > > Applied to u-boot/next, thanks! I am trying to use OF_UPSTREAM with imx8mp_evk_defconfig: diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index 328c3e388051..29d0c5ce6485 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -8,6 +8,7 @@ config IMX8M select LTO select ROM_UNIFIED_SECTIONS select ARMV8_CRYPTO + imply OF_UPSTREAM config IMX8MQ bool diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig index 2350d2f409b7..cdf840c683c0 100644 --- a/configs/imx8mp_evk_defconfig +++ b/configs/imx8mp_evk_defconfig @@ -8,7 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x40 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk" +CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mp-evk" CONFIG_SPL_TEXT_BASE=0x92 CONFIG_TARGET_IMX8MP_EVK=y CONFIG_SYS_MONITOR_LEN=524288 I ran "./dts/update-dts-subtree.sh pull v6.8-rc6-dts". make mrproper make imx8mp_evk_defconfig make The dtb is built: dts/upstream/src/arm64/freescale/imx8mp-evk.dtb but mkimage still looks for the old path: MKIMAGE u-boot.img ./tools/mkimage: Can't open arch/arm/dts/freescale/imx8mp-evk.dtb: No such file or directory ./tools/mkimage: failed to build FIT Any suggestions? Thanks
[GIT PULL] Please pull u-boot-imx-master-20240224
Hi Tom, Please pull from u-boot-imx, thanks. The following changes since commit bb9d6c7f4f6a598e8856b2e19e58c7de078a0d6e: Merge tag 'u-boot-amlogic-fixes-20240223' of https://source.denx.de/u-boot/custodians/u-boot-amlogic (2024-02-23 12:54:03 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240224 for you to fetch changes up to 7c76b1b91bf67cd09fdf5dbd71590f9e580590fa: opos6uldev: Convert to watchdog driver model (2024-02-24 16:29:24 -0300) u-boot-imx-master-20240224 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19725 - Enable the thermal driver for the imx8m phycore boards. - Convert imx53-qsb to watchdog driver to fix the 'reset' command. - Remove multiline string from imx6dl-sielaff. - Add SPI boot support for imxrt1050-evk. - Convert opos6uldev to watchdog driver to fix the 'reset' command. Benjamin Hahn (3): phycore-imx8mp_defconfig: Enable CONFIG_IMX_TMU phycore-imx8mm_defconfig: Enable CONFIG_IMX_TMU imx8mm-phygate-tauri-l_defconfig: Enable CONFIG_IMX_TMU Fabio Estevam (1): imx53-qsb: Convert to watchdog driver model Frieder Schrempf (1): board: imx6dl-sielaff: spl.c: Remove multiline string Jesse Taube (2): imx: imxrt1050-evk: Add support for SPI flash booting imx: imxrt1050-evk: Add documentation for SPI boot Mathieu Othacehe (4): arm: dts: imx93: Add USB support. arm: dts: imx93-var-som-symphony: Add USB support. configs: imx93_var_som: Add USB support. configs: imx93_var_som: Add fastboot support. Sébastien Szymanski (1): opos6uldev: Convert to watchdog driver model arch/arm/dts/imx53-qsb-u-boot.dtsi | 13 arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi| 10 +++ arch/arm/dts/imx93-var-som-symphony.dts| 18 + arch/arm/dts/imx93.dtsi| 58 ++ arch/arm/dts/imxrt1020-evk-u-boot.dtsi | 4 + arch/arm/dts/imxrt1050-evk-u-boot.dtsi | 31 arch/arm/dts/imxrt1170-evk-u-boot.dtsi | 4 + arch/arm/mach-imx/imxrt/Kconfig| 1 + board/freescale/imxrt1050-evk/MAINTAINERS | 1 + board/freescale/imxrt1050-evk/imximage-nor.cfg | 41 ++ board/freescale/imxrt1050-evk/imximage.cfg | 10 ++- board/freescale/imxrt1050-evk/imxrt1050-evk.c | 7 +- board/sielaff/imx6dl-sielaff/spl.c | 4 +- configs/imx8mm-phygate-tauri-l_defconfig | 1 + configs/imx93_var_som_defconfig| 15 configs/imxrt1050-evk_defconfig| 8 +- configs/imxrt1050-evk_fspi_defconfig | 100 + configs/mx53loco_defconfig | 3 + configs/opos6uldev_defconfig | 3 + configs/phycore-imx8mm_defconfig | 1 + configs/phycore-imx8mp_defconfig | 1 + doc/board/nxp/imxrt1050-evk.rst| 30 include/configs/imxrt1050-evk.h| 6 ++ 23 files changed, 362 insertions(+), 8 deletions(-) create mode 100644 arch/arm/dts/imx53-qsb-u-boot.dtsi create mode 100644 board/freescale/imxrt1050-evk/imximage-nor.cfg create mode 100644 configs/imxrt1050-evk_fspi_defconfig