February 2022 - U-Boot

[PATCH v3 0/6] imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards
by Ariel D'Alessandro 21 Mar '22

21 Mar '22

Introduce BSH SystemMaster (SMM) S2 board family, which consists of: iMX8MN SMM S2 and iMX8MN SMM S2 PRO boards. This patchset also adds support for NXP TJA11xx Ethernet PHYs. Changes in v3: * Added nxp-c45-tja11xx driver. * Added ethernet support to iMX8MN BSH SMM S2 boards. Changes in v2: * Properly added MAINTAINERS entry. * Fixed binman configuration. * Picked device tree from kernel. * Removed CONFIG_SPL_BUILD anti-pattern in board config. * Removed downstream stuff in bootargs. * Added board documentation. Ariel D'Alessandro (4): phy: nxp-c45-tja11xx: Rename functions to be c45 tja11xx specific iopoll: Extend read_poll_timeout macro to support variable parameters net: phy: Add phy_modify() accessor bsh: imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards Michael Trimarchi (2): imx8m: add regs used by GPMI net: phy: nxp-tja11xx: Add NXP TJA11xx PHY driver arch/arm/dts/Makefile | 2 + arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi | 423 ++++++++ .../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi | 225 +++++ arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi | 15 + arch/arm/dts/imx8mn-bsh-smm-s2.dts | 48 + arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi | 15 + arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 80 ++ arch/arm/include/asm/arch-imx8m/imx-regs.h | 7 + arch/arm/mach-imx/imx8m/Kconfig | 15 + arch/arm/mach-socfpga/reset_manager_s10.c | 20 +- board/bsh/imx8mn_smm_s2/Kconfig | 49 + board/bsh/imx8mn_smm_s2/MAINTAINERS | 8 + board/bsh/imx8mn_smm_s2/Makefile | 13 + board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c | 941 ++++++++++++++++++ board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c | 941 ++++++++++++++++++ board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c | 23 + board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg | 10 + board/bsh/imx8mn_smm_s2/spl.c | 93 ++ configs/imx8mn_bsh_smm_s2_defconfig | 97 ++ configs/imx8mn_bsh_smm_s2pro_defconfig | 94 ++ doc/board/bsh/imx8mn_bsh_smm_s2.rst | 62 ++ doc/board/bsh/index.rst | 9 + doc/board/index.rst | 1 + drivers/mmc/rockchip_sdhci.c | 9 +- drivers/net/phy/Kconfig | 5 + drivers/net/phy/Makefile | 1 + drivers/net/phy/nxp-c45-tja11xx.c | 6 +- drivers/net/phy/nxp-tja11xx.c | 277 ++++++ drivers/net/phy/phy.c | 23 + include/configs/imx8mn_bsh_smm_s2.h | 52 + include/configs/imx8mn_bsh_smm_s2_common.h | 62 ++ include/configs/imx8mn_bsh_smm_s2pro.h | 35 + include/linux/iopoll.h | 12 +- include/phy.h | 3 + 34 files changed, 3654 insertions(+), 22 deletions(-) create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro.dts create mode 100644 board/bsh/imx8mn_smm_s2/Kconfig create mode 100644 board/bsh/imx8mn_smm_s2/MAINTAINERS create mode 100644 board/bsh/imx8mn_smm_s2/Makefile create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c create mode 100644 board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c create mode 100644 board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg create mode 100644 board/bsh/imx8mn_smm_s2/spl.c create mode 100644 configs/imx8mn_bsh_smm_s2_defconfig create mode 100644 configs/imx8mn_bsh_smm_s2pro_defconfig create mode 100644 doc/board/bsh/imx8mn_bsh_smm_s2.rst create mode 100644 doc/board/bsh/index.rst create mode 100644 drivers/net/phy/nxp-tja11xx.c create mode 100644 include/configs/imx8mn_bsh_smm_s2.h create mode 100644 include/configs/imx8mn_bsh_smm_s2_common.h create mode 100644 include/configs/imx8mn_bsh_smm_s2pro.h -- 2.34.1

4 11

[PATCH 0/2] enable DM_SERIAL on imx8mn-evk and imx8mn-ddr4-evk
by Heiko Thiery 21 Mar '22

21 Mar '22

I was only able to test it on a 8MNANOD3L-EVK board. Please help testing this change on the other 2 eval boards (8MNANOLPD4-EVK, 8MNANOD4-EVK). Heiko Thiery (2): ARM: imx: imx8mn-evk: enable DM_SERIAL ARM: imx: imx8mn-ddr4-evk: enable DM_SERIAL configs/imx8mn_ddr4_evk_defconfig | 2 ++ configs/imx8mn_evk_defconfig | 2 ++ 2 files changed, 4 insertions(+) -- 2.30.2

3 5

ARM A53 and initial MMU mapping for EL0/1/2/3 ?
by Joakim Tjernlund 18 Mar '22

18 Mar '22

Trying to figure out how I should map the MMU for normal RAM so it acessible from all ELx security states. So far I have this mem_map: /* memory mapped RAM. 32MB */ .virt = 0x60000000UL, .phys = 0x60000000UL, .size = 0x02000000UL, .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE but starting to doubt that is correct, can someone suggest what to put in the .attrs field? Jocke

3 20

[PATCH 0/2] Add pmic bootcount driver
by Philip Oberfichtner 18 Mar '22

18 Mar '22

This series adds a new bootcount driver. The required register definitions and the actual driver are separated in two patches. Philip Oberfichtner (2): power: pfuze100: Add MEMx register definitions bootcount: Add pmic pfuze100 bootcount driver drivers/bootcount/Kconfig | 7 ++ drivers/bootcount/Makefile | 1 + drivers/bootcount/bootcount_pmic_pfuze100.c | 83 +++++++++++++++++++++ include/power/pfuze100_pmic.h | 5 ++ 4 files changed, 96 insertions(+) create mode 100644 drivers/bootcount/bootcount_pmic_pfuze100.c -- 2.34.1

2 4

[PATCH 00/14] mtd: nand: i.MX update
by Peng Fan 18 Mar '22

18 Mar '22

This is to upstream NXP downstream mtd nand patches, including DT/CLK/i.MX8M/i.MX8/SPL Alice Guo (2): nand: mxs_nand: make imx8mm can use hardware BCH and randomizer nand: enable the Randomizer module for i.mx7 and i.mx8 Han Xu (3): mtd: nand: mxs_nand: add i.MX6QP compatible string mtd: mxs_nand: fix the gf_13/14 definition issue mxs_nand: don't check zero count when ECC reading with randomizer Peng Fan (3): nand: mxs: fix the bitflips for erased page when uncorrectable error nand: mxs: correct bitflip for erased NAND page mtd: nand: support GPMI NAND driver for i.MX8 Ye Li (6): mtd: gpmi: change the BCH layout setting for large oob NAND mtd: gpmi: provide the option to use legacy bch geometry mxs_nand: Add support for i.MX8M nand: Update SPL MXS NAND mini driver mxs_nand: Update compatible string for i.MX6SX MXS_NAND: Add clock support for iMX8 arch/arm/include/asm/mach-imx/dma.h | 15 +- arch/arm/include/asm/mach-imx/regs-apbh.h | 9 +- arch/arm/include/asm/mach-imx/regs-bch.h | 20 +- drivers/dma/Kconfig | 2 +- drivers/dma/apbh_dma.c | 13 +- drivers/mtd/nand/raw/Kconfig | 6 +- drivers/mtd/nand/raw/mxs_nand.c | 291 ++++++++++++++++++++++-------- drivers/mtd/nand/raw/mxs_nand_dt.c | 91 ++++++++++ drivers/mtd/nand/raw/mxs_nand_spl.c | 41 ++++- include/mxs_nand.h | 15 +- 10 files changed, 387 insertions(+), 116 deletions(-) -- 2.16.4

7 36

[PATCH] firmware: zynqmp: Do not bind PD driver in SPL if disabled
by Michal Simek 18 Mar '22

18 Mar '22

Change if condition to cover SPL flow. SPL needs to have CONFIG_SPL_POWER_DOMAIN enabled to be able to bind CONFIG_ZYNQMP_POWER_DOMAIN driver. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/firmware/firmware-zynqmp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/firmware-zynqmp.c b/drivers/firmware/firmware-zynqmp.c index 8916c5589635..78da5abc5d3e 100644 --- a/drivers/firmware/firmware-zynqmp.c +++ b/drivers/firmware/firmware-zynqmp.c @@ -334,7 +334,11 @@ static int zynqmp_firmware_bind(struct udevice *dev) int ret; struct udevice *child; - if (IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN)) { + if ((IS_ENABLED(CONFIG_SPL_BUILD) && + IS_ENABLED(CONFIG_SPL_POWER_DOMAIN) && + IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN)) || + (!IS_ENABLED(CONFIG_SPL_BUILD) && + IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN))) { ret = device_bind_driver_to_node(dev, "zynqmp_power_domain", "zynqmp_power_domain", dev_ofnode(dev), &child); -- 2.35.1

2 1

[PATCH] arm64: zynqmp: Add resets property to sdhci nodes
by Michal Simek 18 Mar '22

18 Mar '22

From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com> Add "resets" property to sdhci nodes. resets property is used to reset the SD host controller when dynamic configuration support is enabled. Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- arch/arm/dts/zynqmp.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 755a4ed2e515..c44260885023 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -742,6 +742,7 @@ #clock-cells = <1>; clock-output-names = "clk_out_sd0", "clk_in_sd0"; power-domains = <&zynqmp_firmware PD_SD_0>; + resets = <&zynqmp_reset ZYNQMP_RESET_SDIO0>; }; sdhci1: mmc@ff170000 { @@ -758,6 +759,7 @@ #clock-cells = <1>; clock-output-names = "clk_out_sd1", "clk_in_sd1"; power-domains = <&zynqmp_firmware PD_SD_1>; + resets = <&zynqmp_reset ZYNQMP_RESET_SDIO1>; }; smmu: iommu@fd800000 { -- 2.35.1

2 1

Question/issues about i.MX6 DDR configuration
by Francesco Dolcini 17 Mar '22

17 Mar '22

Hello Fabio, Tim and all, in the last few weeks I have been debugging some sporadic i.MX6 board boot failures (2020.07 U-Boot, if that matters) and we have some loose indication that they could be RAM related. The effect is that SPL is not able to load U-Boot from the eMMC to DDR and dqs|write_level calibration is failing. We do write the memory configuration in a pretty simple way, SPL is just iterating thought a list of register address/value, in a very similar way to what was done using the DCD table. Today most of the boards however use a more programmatic approach as introduced by Tim in 2014 [1]. Contrary to that, however, Fabio moved away from this new approach to just raw registers writing for the sabre board [2][3]. I'm a little bit puzzled at the moment, according to the iMX6 reference manual[4], 44.4.2 MMDC initialization, a specific sequence is required to be followed and this is implemented by the `mx6_dram_cfg()`[5] function, but according to what Fabio wrote the raw initialization of registers was just more reliable for mx6sabresd. Fabio, what was the reason? I would expect that using `mx6_dram_cfg()` is the correct approach and I would expect issue if doing in a different way from what is described in the reference manual. Regarding that I found also this note in the manual interesting: "A Precharge All command must be issued prior to the MRW command to ensure robust DDR initialization. This command is required to be issued to both chip selects if two chip selects are utilized in the system." In my tests adding 1ms delay after each MMDC register write seems to have a positive effect and this is going into the direction that using `mx6_dram_cfg()` is the way to go. Any suggestion? Do I miss something? Francesco [1] https://lore.kernel.org/all/1401750807-5975-7-git-send-email-tharvey@gatewo… [2] https://lore.kernel.org/all/1474892066-32005-1-git-send-email-festevam@gmai… [3] https://source.denx.de/u-boot/u-boot/-/commit/3b30eece271cfc4096c2d20048c89… [4] https://www.nxp.com/webapp/Download?colCode=IMX6DQRM [5] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/mx6/dd…

3 8

[PATCH v4 0/2] EFI: Reset system after capsule-on-disk
by Masami Hiramatsu 17 Mar '22

17 Mar '22

Hi, Here is the 4th version of the reset after capsule-on-disk. This version updates the patch description and use do_reset() and halt or reset_cpu() if available, according to Takahiro and Sughosh's comment. The reset after completing the capsule-on-disk is stated in the UEFI specification 2.9, section 8.5.5 "Delivery of Capsules via file on Mass Storage device" as below, In all cases that a capsule is identified for processing the system is restarted after capsule processing is completed. Thank you, --- Masami Hiramatsu (2): efi_loader: use efi_update_capsule_firmware() for capsule on disk efi_loader: Reset system after CapsuleUpdate on disk lib/efi_loader/efi_capsule.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- Masami Hiramatsu <masami.hiramatsu(a)linaro.org>

5 58

[PATCH v2 1/5] doc: binding: scmi: link to latest Linux kernel binding
by Etienne Carriere 16 Mar '22

16 Mar '22

Changes SCMI bindings documentation to relate to Linux kernel source tree that recently changed the bindings description to YAML format. Reviewed-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- Changes since v1: - Apply R-b tag. --- doc/device-tree-bindings/arm/arm,scmi.txt | 236 +--------------------- 1 file changed, 2 insertions(+), 234 deletions(-) diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt b/doc/device-tree-bindings/arm/arm,scmi.txt index 92572eabb5..0a7886da24 100644 --- a/doc/device-tree-bindings/arm/arm,scmi.txt +++ b/doc/device-tree-bindings/arm/arm,scmi.txt @@ -1,234 +1,2 @@ -System Control and Management Interface (SCMI) Message Protocol ----------------------------------------------------------- - -The SCMI is intended to allow agents such as OSPM to manage various functions -that are provided by the hardware platform it is running on, including power -and performance functions. - -This binding is intended to define the interface the firmware implementing -the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control -and Management Interface Platform Design Document")[0] provide for OSPM in -the device tree. - -Required properties: - -The scmi node with the following properties shall be under the /firmware/ node. - -- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports, - or "linaro,scmi-optee" for OP-TEE transport. -- mboxes: List of phandle and mailbox channel specifiers. It should contain - exactly one or two mailboxes, one for transmitting messages("tx") - and another optional for receiving the notifications("rx") if - supported. -- shmem : List of phandle pointing to the shared memory(SHM) area as per - generic mailbox client binding. -- #address-cells : should be '1' if the device has sub-nodes, maps to - protocol identifier for a given sub-node. -- #size-cells : should be '0' as 'reg' property doesn't have any size - associated with it. -- arm,smc-id : SMC id required when using smc or hvc transports -- linaro,optee-channel-id : Channel specifier required when using OP-TEE - transport. - -Optional properties: - -- mbox-names: shall be "tx" or "rx" depending on mboxes entries. - -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details -about the generic mailbox controller and client driver bindings. -Mailbox doorbell is used as a mechanism to alert the presence of a -messages and/or notification. - -Each protocol supported shall have a sub-node with corresponding compatible -as described in the following sections. If the platform supports dedicated -communication channel for a particular protocol, properties shall be present -in the sub-node corresponding to that protocol. These properties are: -- mboxes, mbox-names and shmem for mailbox transport -- arm,smc-id and shmem for smc/hvc transport -- linaro,optee-channel-id and possibly shmem for OP-TEE transport - -Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Required properties: -- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands. - -Power domain bindings for the power domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI power domain providers uses the generic power -domain binding[2]. - -Required properties: - - #power-domain-cells : Should be 1. Contains the device or the power - domain ID value used by SCMI commands. - -Regulator bindings for the SCMI Regulator based on SCMI Message Protocol ------------------------------------------------------------- -An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain, -and should be always positioned as a root regulator. -It does not support any current operation. - -SCMI Regulators are grouped under a 'regulators' node which in turn is a child -of the SCMI Voltage protocol node inside the desired SCMI instance node. - -This binding uses the common regulator binding[6]. - -Required properties: - - reg : shall identify an existent SCMI Voltage Domain. - -Sensor bindings for the sensors based on SCMI Message Protocol --------------------------------------------------------------- -SCMI provides an API to access the various sensors on the SoC. - -Required properties: -- #thermal-sensor-cells: should be set to 1. This property follows the - thermal device tree bindings[3]. - - Valid cell values are raw identifiers (Sensor ID) - as used by the firmware. Refer to platform details - for your implementation for the IDs to use. - -Reset signal bindings for the reset domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI reset domain providers uses the generic reset -signal binding[5]. - -Required properties: - - #reset-cells : Should be 1. Contains the reset domain ID value used - by SCMI commands. - -SRAM and Shared Memory for SCMI -------------------------------- - -A small area of SRAM is reserved for SCMI communication between application -processors and SCP. - -The properties should follow the generic mmio-sram description found in [4] - -Each sub-node represents the reserved area for SCMI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based - shared memory - -[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal.txt -[4] Documentation/devicetree/bindings/sram/sram.yaml -[5] Documentation/devicetree/bindings/reset/reset.txt -[6] Documentation/devicetree/bindings/regulator/regulator.yaml - -Example: - -sram@50000000 { - compatible = "mmio-sram"; - reg = <0x0 0x50000000 0x0 0x10000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x0 0x50000000 0x10000>; - - cpu_scp_lpri: scp-shmem@0 { - compatible = "arm,scmi-shmem"; - reg = <0x0 0x200>; - }; - - cpu_scp_hpri: scp-shmem@200 { - compatible = "arm,scmi-shmem"; - reg = <0x200 0x200>; - }; -}; - -mailbox@40000000 { - .... - #mbox-cells = <1>; - reg = <0x0 0x40000000 0x0 0x10000>; -}; - -firmware { - - ... - - scmi { - compatible = "arm,scmi"; - mboxes = <&mailbox 0 &mailbox 1>; - mbox-names = "tx", "rx"; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; - #address-cells = <1>; - #size-cells = <0>; - - scmi_devpd: protocol@11 { - reg = <0x11>; - #power-domain-cells = <1>; - }; - - scmi_dvfs: protocol@13 { - reg = <0x13>; - #clock-cells = <1>; - }; - - scmi_clk: protocol@14 { - reg = <0x14>; - #clock-cells = <1>; - }; - - scmi_sensors0: protocol@15 { - reg = <0x15>; - #thermal-sensor-cells = <1>; - }; - - scmi_reset: protocol@16 { - reg = <0x16>; - #reset-cells = <1>; - }; - - scmi_voltage: protocol@17 { - reg = <0x17>; - - regulators { - regulator_devX: regulator@0 { - reg = <0x0>; - regulator-max-microvolt = <3300000>; - }; - - regulator_devY: regulator@9 { - reg = <0x9>; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <4200000>; - }; - - ... - }; - }; - }; -}; - -cpu@0 { - ... - reg = <0 0>; - clocks = <&scmi_dvfs 0>; -}; - -hdlcd@7ff60000 { - ... - reg = <0 0x7ff60000 0 0x1000>; - clocks = <&scmi_clk 4>; - power-domains = <&scmi_devpd 1>; - resets = <&scmi_reset 10>; -}; - -thermal-zones { - soc_thermal { - polling-delay-passive = <100>; - polling-delay = <1000>; - /* sensor ID */ - thermal-sensors = <&scmi_sensors0 3>; - ... - }; -}; +See Binding in Linux documentation: +Documentation/devicetree/bindings/firmware/arm,scmi.yaml -- 2.17.1

3 12