June 2021 - U-Boot

[PATCH u-boot-marvell 1/2] arm: mvebu: turris_omnia: update rescue mode boot command
by Marek Behún 04 Jun '21

04 Jun '21

Update rescue mode boot command on Turris Omnia. We are compressing the image with lzma now. Signed-off-by: Marek Behún <marek.behun(a)nic.cz> --- board/CZ.NIC/turris_omnia/turris_omnia.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index 1d3cefe703..d3de8004eb 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -349,10 +349,15 @@ static int set_regdomain(void) "mw.l 0x01000000 0x00ff000c; " \ "i2c write 0x01000000 0x2a.1 0x5 4 -s; " \ "setenv bootargs \"earlyprintk console=ttyS0,115200" \ - " omniarescue=$omnia_reset\"; " \ + " omniarescue=$omnia_reset rescue_mode=$omnia_reset\"; " \ "sf probe; " \ "sf read 0x1000000 0x100000 0x700000; " \ - "bootm 0x1000000; " \ + "lzmadec 0x1000000 0x1700000; " \ + "if gpio input gpio@71_4; then " \ + "bootm 0x1700000#sfp; " \ + "else " \ + "bootm 0x1700000; " \ + "fi; " \ "bootz 0x1000000" static void handle_reset_button(void) -- 2.26.3

3 7

[PATCH 1/6] arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe
by Pali Rohár 04 Jun '21

04 Jun '21

During our debugging of the Aardvark driver in Linux we have discovered that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard PCIe Link Control Register for PCIe Root Bridge. This led us to discover that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding comment by this macro's usage is misleading; this bit in fact controls Retrain Link, which, according to PCIe base spec is defined as: A write of 1b to this bit initiates Link retraining by directing the Physical Layer LTSSM to the Recovery state. If the LTSSM is already in Recovery or Configuration, re-entering Recovery is permitted but not required. Entering Recovery state is normally done from LTSSM L0, L0s and L1 states. But since the pci-aardvark.c driver enables Link Training just a few lines above, the controller is not in L0 ready state yet. So setting aardvark bit PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this place. Moreover, trying to enter LTSSM Recovery state without other configuration is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since Recovery state is not entered, these issues are not triggered. Remove code which tries to enter LTSSM Recovery state completely. Signed-off-by: Pali Rohár <pali(a)kernel.org> Reviewed-by: Marek Behún <marek.behun(a)nic.cz> --- drivers/pci/pci-aardvark.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index c43d4f309b19..06c567e236f9 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -613,11 +613,6 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie) reg |= PIO_CTRL_ADDR_WIN_DISABLE; advk_writel(pcie, reg, PIO_CTRL); - /* Start link training */ - reg = advk_readl(pcie, PCIE_CORE_LINK_CTRL_STAT_REG); - reg |= PCIE_CORE_LINK_TRAINING; - advk_writel(pcie, reg, PCIE_CORE_LINK_CTRL_STAT_REG); - /* Wait for PCIe link up */ if (pcie_advk_wait_for_link(pcie)) return -ENXIO; -- 2.20.1

3 25

RE: [PATCH v2] net: tsec: add option to set device max-speed via dts
by Aleksandar Gerasimovski 04 Jun '21

04 Jun '21

Current tsec adapter sets adapter gigabit capabilities by default, and in reality this must not always be the case. It is possible that tsec adapter is used for 100Mbit connection, and in this case setting 1000Mbit capabilities can lead to some side effects such longer autoneg process. In our ls102x designs this problem leads to long autoneg times (> 4 sec) in case board rgmii link is 100Mbs capble only. Limiting the rgmii link capabilities provides smother and faster link establishment. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> Reviewed-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> --- Changes for v2: - keep the variable sort order in a decreasing order of line length - fix comment typo --- drivers/net/tsec.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index c68e4b7..ee820aa 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -828,6 +828,7 @@ int tsec_probe(struct udevice *dev) const char *phy_mode; ofnode parent, child; fdt_addr_t reg; + u32 max_speed; int ret; data = (struct tsec_data *)dev_get_driver_data(dev); @@ -893,8 +894,12 @@ int tsec_probe(struct udevice *dev) } priv->interface = pdata->phy_interface; + /* Check for speed limit, default is 1000Mbps */ + max_speed = dev_read_u32_default(dev, "max-speed", 1000); + /* Initialize flags */ - priv->flags = TSEC_GIGABIT; + if (max_speed == 1000) + priv->flags = TSEC_GIGABIT; if (priv->interface == PHY_INTERFACE_MODE_SGMII) priv->flags |= TSEC_SGMII; -- 1.8.3.1 -----Original Message----- From: Vladimir Oltean <vladimir.oltean(a)nxp.com> Sent: Freitag, 4. Juni 2021 13:29 To: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> Cc: u-boot(a)lists.denx.de; Priyanka Jain (OSS) <priyanka.jain(a)oss.nxp.com>; Rainer Boschung <rainer.boschung(a)hitachi-powergrids.com>; Ramon Fried <rfried.dev(a)gmail.com> Subject: Re: [PATCH] net: tsec: add option to set device max-speed via dts CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, Jun 04, 2021 at 11:13:36AM +0000, Aleksandar Gerasimovski wrote: > Current tsec adapter sets adapter gigabit capabilities by default, and > in reality this must not always be the case. > It is possible that tsec adapter is used for 100Mbit connection, and > in this case setting 1000Mbit capabilities can lead to some side > effects such longer autoneg process. > > In our ls102x designs this problem leads to long autoneg times (> 4 > sec) in case board rgmii link is 100Mbs capble only. > Limiting the rgmii link capabilities provides smother and faster link > establishment. > > Signed-off-by: Aleksandar Gerasimovski > <aleksandar.gerasimovski(a)hitachi-powergrids.com> > --- Reviewed-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Just one comment below: > drivers/net/tsec.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index > c68e4b7..501390f 100644 > --- a/drivers/net/tsec.c > +++ b/drivers/net/tsec.c > @@ -824,6 +824,7 @@ int tsec_probe(struct udevice *dev) > struct tsec_private *priv = dev_get_priv(dev); > struct ofnode_phandle_args phandle_args; > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE; > + u32 max_speed; It would be nice if you could keep the variable sort order, which is in decreasing order of line length (so-called "reverse Christmas tree notation"). > struct tsec_data *data; > const char *phy_mode; > ofnode parent, child; > @@ -893,8 +894,12 @@ int tsec_probe(struct udevice *dev) > } > priv->interface = pdata->phy_interface; > > + /* Check for speed limis, default is 1000Mbps */ > + max_speed = dev_read_u32_default(dev, "max-speed", 1000); > + > /* Initialize flags */ > - priv->flags = TSEC_GIGABIT; > + if (max_speed == 1000) > + priv->flags = TSEC_GIGABIT; > if (priv->interface == PHY_INTERFACE_MODE_SGMII) > priv->flags |= TSEC_SGMII; > > -- > 1.8.3.1 Thanks.

2 1

[PATCH] net: tsec: add option to set device max-speed via dts
by Aleksandar Gerasimovski 04 Jun '21

04 Jun '21

Current tsec adapter sets adapter gigabit capabilities by default, and in reality this must not always be the case. It is possible that tsec adapter is used for 100Mbit connection, and in this case setting 1000Mbit capabilities can lead to some side effects such longer autoneg process. In our ls102x designs this problem leads to long autoneg times (> 4 sec) in case board rgmii link is 100Mbs capble only. Limiting the rgmii link capabilities provides smother and faster link establishment. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> --- drivers/net/tsec.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index c68e4b7..501390f 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -824,6 +824,7 @@ int tsec_probe(struct udevice *dev) struct tsec_private *priv = dev_get_priv(dev); struct ofnode_phandle_args phandle_args; u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE; + u32 max_speed; struct tsec_data *data; const char *phy_mode; ofnode parent, child; @@ -893,8 +894,12 @@ int tsec_probe(struct udevice *dev) } priv->interface = pdata->phy_interface; + /* Check for speed limis, default is 1000Mbps */ + max_speed = dev_read_u32_default(dev, "max-speed", 1000); + /* Initialize flags */ - priv->flags = TSEC_GIGABIT; + if (max_speed == 1000) + priv->flags = TSEC_GIGABIT; if (priv->interface == PHY_INTERFACE_MODE_SGMII) priv->flags |= TSEC_SGMII; -- 1.8.3.1

2 1

[PATCH] keymile: common: fix hexadecimal env variable format
by Aleksandar Gerasimovski 04 Jun '21

04 Jun '21

Commit df86d32 breaks linux kernel and product application boot. Linux kernel and our product application scripts are expecting 0x prefix for hexadecimal values, while env_set_hex writes them without a prefix. This patch partially revert env_set_hex usage for affected env variables. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> --- board/keymile/common/common.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c index 2ce7462..016806a 100644 --- a/board/keymile/common/common.c +++ b/board/keymile/common/common.c @@ -46,12 +46,14 @@ int set_km_env(void) unsigned int pram; unsigned int varaddr; unsigned int kernelmem; - char *p; unsigned long rootfssize = 0; + char envval[16]; + char *p; pnvramaddr = CONFIG_SYS_SDRAM_BASE + gd->ram_size - CONFIG_KM_RESERVED_PRAM - CONFIG_KM_PHRAM - CONFIG_KM_PNVRAM; - env_set_hex("pnvramaddr", pnvramaddr); + sprintf(envval, "0x%x", pnvramaddr); + env_set("pnvramaddr", envval); /* try to read rootfssize (ram image) from environment */ p = env_get("rootfssize"); @@ -64,9 +66,12 @@ int set_km_env(void) varaddr = CONFIG_SYS_SDRAM_BASE + gd->ram_size - CONFIG_KM_RESERVED_PRAM - CONFIG_KM_PHRAM; env_set_hex("varaddr", varaddr); + sprintf(envval, "0x%x", varaddr); + env_set("varaddr", envval); kernelmem = gd->ram_size - 0x400 * pram; - env_set_hex("kernelmem", kernelmem); + sprintf(envval, "0x%x", kernelmem); + env_set("kernelmem", envval); return 0; } -- 1.8.3.1

1 0

[PATCH] configs: seli8: set envsize to 0x4000
by Aleksandar Gerasimovski 04 Jun '21

04 Jun '21

During the mainlining of the board this was by mistake set to sector size. Our user space env scripts are expecting envsize of 0x4000, and setting this differently will break our cross-platform compatibility. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> --- configs/pg_wcom_seli8_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/pg_wcom_seli8_defconfig b/configs/pg_wcom_seli8_defconfig index a61b826..a00334b 100644 --- a/configs/pg_wcom_seli8_defconfig +++ b/configs/pg_wcom_seli8_defconfig @@ -7,7 +7,7 @@ CONFIG_KM_COMMON_ETH_INIT=y CONFIG_PIGGY_MAC_ADDRESS_OFFSET=3 CONFIG_SYS_MEMTEST_START=0x80000000 CONFIG_SYS_MEMTEST_END=0x9fffffff -CONFIG_ENV_SIZE=0x20000 +CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_SECT_SIZE=0x20000 CONFIG_SYS_I2C_MXC_I2C1=y CONFIG_SYS_I2C_MXC_I2C2=y -- 1.8.3.1

1 0

[PATCH] sunxi: h3: Add initial ZeroPi support
by Yu-Tung Chang 04 Jun '21

04 Jun '21

ZeroPi is a new board of high performance with low cost designed by FriendlyElec., using the Allwinner H3 SOC. ZeroPi features - Allwinner H3, Quad-core Cortex-A7(a)1.2GHz - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by: Yu-Tung Chang <mtwget(a)gmail.com> --- arch/arm/dts/Makefile | 3 +- arch/arm/dts/sun8i-h3-zeropi.dts | 48 ++++++++++++++++++++++++++++++++ board/sunxi/MAINTAINERS | 6 ++++ configs/zeropi_defconfig | 13 +++++++++ 4 files changed, 69 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/sun8i-h3-zeropi.dts create mode 100644 configs/zeropi_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 096068261d..7c8e253350 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -607,7 +607,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \ sun8i-h3-orangepi-plus.dtb \ sun8i-h3-orangepi-plus2e.dtb \ sun8i-h3-orangepi-zero-plus2.dtb \ - sun8i-h3-rervision-dvk.dtb + sun8i-h3-rervision-dvk.dtb \ + sun8i-h3-zeropi.dtb dtb-$(CONFIG_MACH_SUN8I_R40) += \ sun8i-r40-bananapi-m2-ultra.dtb \ sun8i-v40-bananapi-m2-berry.dtb diff --git a/arch/arm/dts/sun8i-h3-zeropi.dts b/arch/arm/dts/sun8i-h3-zeropi.dts new file mode 100644 index 0000000000..e36381f11b --- /dev/null +++ b/arch/arm/dts/sun8i-h3-zeropi.dts @@ -0,0 +1,48 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2021 Yu-Tung Chang <mtwget(a)gmail.com> + */ + +#include "sun8i-h3-nanopi.dtsi" + +/ { + model = "FriendlyARM ZeroPi"; + compatible = "friendlyarm,zeropi", "allwinner,sun8i-h3"; + + aliases { + ethernet0 = &emac; + }; + + reg_gmac_3v3: gmac-3v3 { + compatible = "regulator-fixed"; + regulator-name = "gmac-3v3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + startup-delay-us = <100000>; + enable-active-high; + gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */ + }; +}; + +&external_mdio { + ext_rgmii_phy: ethernet-phy@7 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <7>; + }; +}; + +&emac { + pinctrl-names = "default"; + pinctrl-0 = <&emac_rgmii_pins>; + phy-supply = <&reg_gmac_3v3>; + phy-handle = <&ext_rgmii_phy>; + phy-mode = "rgmii-id"; + + allwinner,leds-active-low; + status = "okay"; +}; + +&usb_otg { + status = "okay"; + dr_mode = "host"; +}; diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 76eba2ad20..4fc26077b2 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -529,3 +529,9 @@ YONES TOPTECH BS1078 V2 BOARD M: Peter Korsgaard <peter(a)korsgaard.com> S: Maintained F: configs/Yones_Toptech_BS1078_V2_defconfig + +ZEROPI BOARD +M: Yu-Tung Chang <mtwget(a)gmail.com> +S: Maintained +F: configs/zeropi_defconfig +F: arch/arm/dts/sun8i-h3-zeropi.dts diff --git a/configs/zeropi_defconfig b/configs/zeropi_defconfig new file mode 100644 index 0000000000..f921b09892 --- /dev/null +++ b/configs/zeropi_defconfig @@ -0,0 +1,13 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN8I_H3=y +CONFIG_DRAM_CLK=408 +CONFIG_MACPWR="PD6" +# CONFIG_VIDEO_DE2 is not set +CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-zeropi" +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_CONSOLE_MUX=y +CONFIG_SUN8I_EMAC=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y -- 2.31.1

1 0

[PATCH V5 0/2] Add OpenPiton board support
by Tianrui Wei 04 Jun '21

04 Jun '21

This patch set is to add OpenPiton board support. Patches are split into several parts: - [PATCH 1/2] add OpenPiton support to mmc driver - [PATCH 2/2] add support for OpenPiton board Description - for mmc driver, it's settings are automatically configured at hardware level. We only need to expose the memory mapped interface through U-Boot driver model - For OpenPiton, as we need to embed the device tree blob into the bitstream, there is currently no itb support Tests checks - Able to boot Debian Linux from SD card on Digilent Genesys 2 - Checkpatch is performed, with some warnings ignored Changelogs - V2 . fix styles and typos in [1/2] and [2/2] . add board documentation in [2/2] - V3 . fix styles in [1/2] - V4 . fix checkpatch warnings in [1/2] except MAINTAINERS - V5 . major changes in device tree . changed to OF_SEPARATE . formatting update for mmc arch/riscv/Kconfig | 4 + arch/riscv/dts/Makefile | 1 + arch/riscv/dts/openpiton-riscv64.dts | 160 +++++ board/openpiton/riscv/Kconfig | 42 ++ board/openpiton/riscv/MAINTAINERS | 6 + board/openpiton/riscv/Makefile | 5 + board/openpiton/riscv/openpiton-riscv.c | 41 ++ configs/openpiton_riscv64_defconfig | 132 ++++ doc/board/index.rst | 1 + doc/board/openpiton/index.rst | 9 + doc/board/openpiton/riscv64.rst | 885 ++++++++++++++++++++++++ drivers/mmc/Kconfig | 7 + drivers/mmc/Makefile | 1 + drivers/mmc/piton_mmc.c | 174 +++++ include/configs/openpiton-riscv.h | 58 ++ 15 files changed, 1526 insertions(+) create mode 100644 arch/riscv/dts/openpiton-riscv64.dts create mode 100644 board/openpiton/riscv/Kconfig create mode 100644 board/openpiton/riscv/MAINTAINERS create mode 100644 board/openpiton/riscv/Makefile create mode 100644 board/openpiton/riscv/openpiton-riscv.c create mode 100644 configs/openpiton_riscv64_defconfig create mode 100644 doc/board/openpiton/index.rst create mode 100644 doc/board/openpiton/riscv64.rst create mode 100644 drivers/mmc/piton_mmc.c create mode 100644 include/configs/openpiton-riscv.h -- 2.31.1

1 0

[v3, 0/3] Drop CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT
by Yangbo Lu 04 Jun '21

04 Jun '21

For eSDHC, power supply is through peripheral circuit. Some eSDHC versions have value 0 of the bit but that does not reflect the truth. 3.3V is common for SD/MMC, and is supported for all boards with eSDHC in current u-boot. So, make 3.3V is supported in default in code. CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT can be enabled if future board does not support 3.3V. Then CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 can be dropped. And i.MX eSDHC driver should drop it too, since it's not used by any one of i.MX board. Changes for v2: - Updated copyright. Changes for v3: - Fixed code logic in patch#1. - Dropped wrong copyright. Yangbo Lu (3): mmc: fsl_esdhc: convert to CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT mmc: fsl_esdhc_imx: drop CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 armv8: layerscape: drop CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 drivers/mmc/Kconfig | 7 +++++++ drivers/mmc/fsl_esdhc.c | 17 ++++++++++++++--- drivers/mmc/fsl_esdhc_imx.c | 7 +------ include/configs/T208xQDS.h | 3 +-- include/configs/T208xRDB.h | 3 +-- include/configs/T4240RDB.h | 3 +-- include/configs/kontron_sl28.h | 5 ----- include/configs/ls1012a2g5rdb.h | 7 +------ include/configs/ls1012afrwy.h | 7 +------ include/configs/ls1012aqds.h | 6 +----- include/configs/ls1012ardb.h | 8 +------- include/configs/ls1028a_common.h | 7 +------ include/configs/ls1043a_common.h | 9 +-------- include/configs/ls1046a_common.h | 9 +-------- include/configs/ls1088aqds.h | 3 +-- include/configs/ls1088ardb.h | 7 +------ include/configs/ls2080aqds.h | 7 +------ include/configs/ls2080ardb.h | 7 +------ include/configs/lx2160a_common.h | 7 +------ scripts/config_whitelist.txt | 1 - 20 files changed, 37 insertions(+), 93 deletions(-) base-commit: 89be8e31ccd1c53b010385ed0807eb00f0eec06a -- 2.25.1

3 5

[BUG] network is broken on Orange Pi PC
by Heinrich Schuchardt 03 Jun '21

03 Jun '21

Dear all, network is broken in U-Boot on orangepi_pc_defconfig: U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +0000) Allwinner Technology eth0: ethernet@1c30000 => dhcp sun8i_emac_eth_start: Timeout Best regards Heinrich

4 10