October 2024 - U-Boot

[PATCH v2 00/14] Support OF_UPSTREAM for StarFive JH7110
by Hal Feng 28 Oct '24

28 Oct '24

This patchset add OF_STREAM support for StarFive JH7110 based boards. All the JH7110 based boards can use the DT from upstreaming linux kernel. The v1.3b board device tree is set as the default device tree. Support CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the EEPROM information. Changes since v1: - Drop patch 12. - Modify patch 11 and add three new patches to support CONFIG_MULTI_DTB_FIT. The SPL selects the correct U-Boot dtb using the EEPROM information. Hal Feng (14): Makefile: Add OF_UPSTREAM Makefile for RISC-V dts: starfive: Switch to using upstream DT riscv: dts: jh7110: Drop redundant devicetree files dt-bindings: Remove StarFive JH7110 clock and reset definitions riscv: dts: jh7110: Make u-boot device trees adapting to upstream DT clk: starfive: jh7110: Sync clock definitions with upstream dt-bindings pcie: starfive: Make the driver compatible with upstream DT riscv: dts: jh7110: Move common code to the new jh7110-common-u-boot.dtsi riscv: dts: jh7110: Add u-boot device tree for JH7110 based boards board: starfive: spl: Drop the unneeded DT modification code configs: visionfive2: Enable MULTI_DTB_FIT for JH7110 based board DT riscv: dts: jh7110: Support multiple DTBs in a Fit image board: starfive: spl: Fix the wrong use of CONFIG_IS_ENABLED() board: starfive: spl: Support multiple DTBs for JH7110 based boards arch/riscv/cpu/jh7110/Kconfig | 1 + arch/riscv/dts/Makefile | 1 - arch/riscv/dts/jh7110-common-u-boot.dtsi | 204 +++++ arch/riscv/dts/jh7110-milkv-mars-u-boot.dtsi | 11 + .../dts/jh7110-pine64-star64-u-boot.dtsi | 6 + .../jh7110-starfive-visionfive-2-u-boot.dtsi | 117 --- ...10-starfive-visionfive-2-v1.2a-u-boot.dtsi | 6 + ...10-starfive-visionfive-2-v1.3b-u-boot.dtsi | 14 + .../dts/jh7110-starfive-visionfive-2.dts | 11 - .../dts/jh7110-starfive-visionfive-2.dtsi | 380 --------- arch/riscv/dts/jh7110-u-boot.dtsi | 36 +- arch/riscv/dts/jh7110.dtsi | 761 ------------------ board/starfive/visionfive2/spl.c | 385 +-------- configs/starfive_visionfive2_defconfig | 4 +- drivers/clk/starfive/clk-jh7110-pll.c | 6 +- drivers/clk/starfive/clk-jh7110.c | 44 +- drivers/pci/pcie_starfive_jh7110.c | 59 +- dts/upstream/src/riscv/Makefile | 14 + .../dt-bindings/clock/starfive,jh7110-crg.h | 258 ------ .../dt-bindings/reset/starfive,jh7110-crg.h | 183 ----- 20 files changed, 373 insertions(+), 2128 deletions(-) create mode 100644 arch/riscv/dts/jh7110-common-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-milkv-mars-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-pine64-star64-u-boot.dtsi delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b-u-boot.dtsi delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2.dts delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi delete mode 100644 arch/riscv/dts/jh7110.dtsi create mode 100644 dts/upstream/src/riscv/Makefile delete mode 100644 include/dt-bindings/clock/starfive,jh7110-crg.h delete mode 100644 include/dt-bindings/reset/starfive,jh7110-crg.h base-commit: deafcdc8e014dc83f154cc448cf8cf6a24b29136 -- 2.43.2

2 15

Fwd: New Defects reported by Coverity Scan for Das U-Boot
by Tom Rini 28 Oct '24

28 Oct '24

Here's the latest report. ---------- Forwarded message --------- From: <scan-admin(a)coverity.com> Date: Sun, Oct 27, 2024 at 9:05 PM Subject: New Defects reported by Coverity Scan for Das U-Boot To: <tom.rini(a)gmail.com> Hi, Please find the latest report on new defect(s) introduced to Das U-Boot found with Coverity Scan. 1 new defect(s) introduced to Das U-Boot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 511435: Integer handling issues (SIGN_EXTENSION) /lib/acpi/acpi_table.c: 476 in acpi_write_spcr() ________________________________________________________________________________________________________ *** CID 511435: Integer handling issues (SIGN_EXTENSION) /lib/acpi/acpi_table.c: 476 in acpi_write_spcr() 470 default: 471 space_id = ACPI_ADDRESS_SPACE_IO; 472 break; 473 } 474 475 serial_width = serial_info.reg_width * 8; >>> CID 511435: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "serial_info.reg_offset" with type "u8" (8 bits, unsigned) is promoted in "serial_info.reg_offset << serial_info.reg_shift" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "serial_info.reg_offset << serial_info.reg_shift" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 476 serial_offset = serial_info.reg_offset << serial_info.reg_shift; 477 serial_address = serial_info.addr + serial_offset; 478 479 /* Encode register access size */ 480 switch (serial_info.reg_shift) { 481 case 0: ----- End forwarded message ----- -- Tom

1 0

[PATCH] x86: Missed removal of CMD_BOOTEFI_HELLO_COMPILE
by Andrew Goodbody 28 Oct '24

28 Oct '24

The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour of BOOTEFI_HELLO_COMPILE but the usage in this Makefile was not updated. Fix it. Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody(a)linaro.org> --- arch/x86/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 7677c0c352..43e6a1de77 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -97,7 +97,7 @@ endif else ifndef CONFIG_XPL_BUILD -ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST)$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),) +ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST)$(CONFIG_BOOTEFI_HELLO_COMPILE),) extra-y += $(EFI_CRT0) $(EFI_RELOC) endif endif -- 2.39.5

2 2

[PATCH] test: efi_loader: Fix dependency for http test
by Andrew Goodbody 28 Oct '24

28 Oct '24

The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour of BOOTEFI_HELLO_COMPILE but the dependency for test_efi_helloworld_net_http was not updated and so is now incorrect preventing the test from ever running. Fix it. Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody(a)linaro.org> --- test/py/tests/test_efi_loader.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py index 707b2c9e79..33434935fe 100644 --- a/test/py/tests/test_efi_loader.py +++ b/test/py/tests/test_efi_loader.py @@ -182,7 +182,7 @@ def test_efi_helloworld_net_tftp(u_boot_console): do_test_efi_helloworld_net(u_boot_console, PROTO_TFTP); @pytest.mark.buildconfigspec('of_control') -(a)pytest.mark.buildconfigspec('cmd_bootefi_hello_compile') +(a)pytest.mark.buildconfigspec('bootefi_hello_compile') @pytest.mark.buildconfigspec('cmd_wget') def test_efi_helloworld_net_http(u_boot_console): """Run the helloworld.efi binary via HTTP. -- 2.39.5

3 4

[PATCH 0/2] eth: asix88179: Fixes for ASIX AX88179A variant
by Khoa Hoang 28 Oct '24

28 Oct '24

Hello U-Boot Maintainers, I am submitting two patches that address issues with the ASIX AX88179A Ethernet driver in U-Boot. These patches resolve problems related to PHY hang during auto-negotiation and stalling when handling large fragmented packets for the ASIX AX88179A variant. --- Example of AX88179A hang issue: => dhcp Waiting for Ethernet connection... unable to connect. Reset Ethernet Device Waiting for Ethernet connection... unable to connect. => --- Thanks, Khoa Khoa Hoang (2): eth: asix88179: Fix ASIX AX88179A PHY hang eth: asix88179: Fix drop of large fragmented packets drivers/usb/eth/asix88179.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) --

2 8

[PATCH] sunxi: power: axp809: Fix DCDC4 programming
by Andre Przywara 28 Oct '24

28 Oct '24

When trying to set the DCDC4 regulator, the code was accidentally setting the voltage register for DCDC5 (VCC-DRAM). The higher voltage doesn't harm the DRAM chips, but upsets the Linux regulator driver: when it tried to correct that, it tripped over a separate DT bug. The DCDC5 DT limits are 1.425 and 1.575V, which cannot bet set with the rail's resolution of 50mV. The kernel driver gave up, and made in turn the system hang, as the PMIC powers essential devices. Fix the copy&paste bug by using the correct PMIC voltage register. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- drivers/power/axp809.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/axp809.c b/drivers/power/axp809.c index 9e38e1a7450..ec3eca1ac4b 100644 --- a/drivers/power/axp809.c +++ b/drivers/power/axp809.c @@ -93,7 +93,7 @@ int axp_set_dcdc4(unsigned int mvolt) return pmic_bus_clrbits(AXP809_OUTPUT_CTRL1, AXP809_OUTPUT_CTRL1_DCDC4_EN); - ret = pmic_bus_write(AXP809_DCDC5_CTRL, cfg); + ret = pmic_bus_write(AXP809_DCDC4_CTRL, cfg); if (ret) return ret; -- 2.46.2

3 2

[PATCH 1/8] net: dc2114x: add support for platforms that don't have pci controllers
by Hanyuan Zhao 28 Oct '24

28 Oct '24

There're a few ethernet IP cores which have the same functions with dc2114x, and can be connected to CPU by AXI or other buses. This commit adds support for the platforms that do not have PCI controllers, using MMIO to communicate with the dc2114x IP core. Signed-off-by: Hanyuan Zhao <zhaohy22(a)mails.tsinghua.edu.cn> --- drivers/net/Kconfig | 8 ++++++++ drivers/net/dc2114x.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 69ae7c0750..41b7c66105 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -740,6 +740,14 @@ config TULIP help This driver supports DEC DC2114x Fast ethernet chips. +config TULIP_SUPPORT_NON_PCI + bool "No PCI controller" + depends on TULIP + default n + help + Say Y to this and you can run this driver on platforms that do not + have PCI controllers. + config XILINX_AXIEMAC select PHYLIB select MII diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c index ce028f451f..3704d2e655 100644 --- a/drivers/net/dc2114x.c +++ b/drivers/net/dc2114x.c @@ -72,7 +72,12 @@ #define POLL_DEMAND 1 +#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) +#define phys_to_bus(dev, a) virt_to_phys((volatile const void *)(a)) +#else #define phys_to_bus(dev, a) dm_pci_phys_to_mem((dev), (a)) +#endif +#endif #define NUM_RX_DESC PKTBUFSRX #define NUM_TX_DESC 1 /* Number of TX descriptors */ @@ -461,11 +466,13 @@ static void read_hw_addr(struct dc2114x_priv *priv) } } +#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) static struct pci_device_id supported[] = { { PCI_DEVICE(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_TULIP_FAST) }, { PCI_DEVICE(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21142) }, { } }; +#endif static int dc2114x_start(struct udevice *dev) { @@ -474,8 +481,10 @@ static int dc2114x_start(struct udevice *dev) memcpy(priv->enetaddr, plat->enetaddr, sizeof(plat->enetaddr)); +#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) /* Ensure we're not sleeping. */ dm_pci_write_config8(dev, PCI_CFDA_PSM, WAKEUP); +#endif return dc21x4x_init_common(priv); } @@ -485,8 +494,9 @@ static void dc2114x_stop(struct udevice *dev) struct dc2114x_priv *priv = dev_get_priv(dev); dc21x4x_halt_common(priv); - +#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) dm_pci_write_config8(dev, PCI_CFDA_PSM, SLEEP); +#endif } static int dc2114x_send(struct udevice *dev, void *packet, int length) @@ -555,6 +565,8 @@ static int dc2114x_probe(struct udevice *dev) { struct eth_pdata *plat = dev_get_plat(dev); struct dc2114x_priv *priv = dev_get_priv(dev); + +#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) u16 command, status; u32 iobase; @@ -576,9 +588,22 @@ static int dc2114x_probe(struct udevice *dev) } dm_pci_write_config8(dev, PCI_LATENCY_TIMER, 0x60); +#endif + return 0; +} + +#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) +static int dc2114x_of_to_plat(struct udevice *dev) +{ + struct eth_pdata *plat = dev_get_plat(dev); + struct dc2114x_priv *priv = dev_get_priv(dev); + + plat->iobase = (phys_addr_t)map_physmem((phys_addr_t)devfdt_get_addr(dev), 0, MAP_NOCACHE); + priv->iobase = (void*)plat->iobase; return 0; } +#endif static const struct eth_ops dc2114x_ops = { .start = dc2114x_start, @@ -589,9 +614,23 @@ static const struct eth_ops dc2114x_ops = { .read_rom_hwaddr = dc2114x_read_rom_hwaddr, }; +#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) +static const struct udevice_id dc2114x_eth_ids[] = { + { .compatible = "dec,dmfe" }, + { .compatible = "tulip,dmfe" }, + { .compatible = "dec,dc2114x" }, + { .compatible = "tulip,dc2114x" }, + { } +}; +#endif + U_BOOT_DRIVER(eth_dc2114x) = { .name = "eth_dc2114x", .id = UCLASS_ETH, +#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) + .of_match = dc2114x_eth_ids, + .of_to_plat = dc2114x_of_to_plat, +#endif .bind = dc2114x_bind, .probe = dc2114x_probe, .ops = &dc2114x_ops, @@ -599,4 +638,6 @@ U_BOOT_DRIVER(eth_dc2114x) = { .plat_auto = sizeof(struct eth_pdata), }; +#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI) U_BOOT_PCI_DEVICE(eth_dc2114x, supported); +#endif -- 2.39.2

2 1

[PATCH v2] net: recv(): return -EAGAIN instead of 0 when no cleanup is expected
by Jerome Forissier 28 Oct '24

28 Oct '24

Some drivers do not behave properly when free_pkt() is called with a length of zero. It is an issue I observed when developing the lwIP series [1] (see "QEMU CI tests for r2dplus_i82557c, r2dplus_rtl8139" in the change log) and which I fixed incorrectly by not calling free_pkt() when recv() returns 0. That turned out to be wrong for two reasons: 1. The DM documentation [2] clearly requires it: "The **recv** function polls for availability of a new packet. [...] If there is an error [...], return 0 if you require the packet to be cleaned up normally, or a negative error code otherwise (cleanup not necessary or already done). If **free_pkt** is defined, U-Boot will call it after a received packet has been processed [...]. free_pkt() will be called after recv(), for the same packet [...]" 2. The imx8mp_evk platform will fail with OOM errors if free_pkt() is not called after recv() returns 0: u-boot=> tftp 192.168.0.16:50M Using ethernet@30be0000 device TFTP from server 192.168.0.16; our IP address is 192.168.0.48 Filename '50M'. Load address: 0x40480000 Loading: #######################fecmxc_recv: error allocating packetp fecmxc_recv: error allocating packetp fecmxc_recv: error allocating packetp ... Therefore, make recv() return -EAGAIN instead of 0 when no packet is available and the driver doesn't expect free_pkt() to be called subsequently. [1] https://lists.denx.de/pipermail/u-boot/2024-August/562861.html [2] doc/develop/driver-model/ethernet.rst Signed-off-by: Jerome Forissier <jerome.forissier(a)linaro.org> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- drivers/net/eepro100.c | 2 +- drivers/net/rtl8139.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/eepro100.c b/drivers/net/eepro100.c index d18a8d577ca..f64dbb7d6a1 100644 --- a/drivers/net/eepro100.c +++ b/drivers/net/eepro100.c @@ -678,7 +678,7 @@ static int eepro100_recv_common(struct eepro100_priv *priv, uchar **packetp) status = le16_to_cpu(desc->status); if (!(status & RFD_STATUS_C)) - return 0; + return -EAGAIN; /* Valid frame status. */ if (status & RFD_STATUS_OK) { diff --git a/drivers/net/rtl8139.c b/drivers/net/rtl8139.c index 2e0afad089f..5f4b1e2d3a0 100644 --- a/drivers/net/rtl8139.c +++ b/drivers/net/rtl8139.c @@ -433,7 +433,7 @@ static int rtl8139_recv_common(struct rtl8139_priv *priv, unsigned char *rxdata, int length = 0; if (inb(priv->ioaddr + RTL_REG_CHIPCMD) & RTL_REG_CHIPCMD_RXBUFEMPTY) - return 0; + return -EAGAIN; priv->rxstatus = inw(priv->ioaddr + RTL_REG_INTRSTATUS); /* See below for the rest of the interrupt acknowledges. */ -- 2.40.1

2 1

[PATCH 0/9] net: ksz9477: add support for KSZ GbE switches using SPI bus
by Romain Naour 28 Oct '24

28 Oct '24

Hello, We are using a custom board where an ethernet switch device KSZ9896 is available. This family of devices can use several types of serial bus as management interface: mdio, i2c or SPI. Due to board design constraints and because we initially planned to use this device only from Linux, the SPI bus was used. Luckily we are using a recent enough u-boot release where KSZ9477 driver is available... but only for the i2c interface. Indeed, unlike the kernel driver, the KSZ9477 driver doesn't use the regmap API to access the underlying bus since the regmap API is limited to direct memory access [1]. Until regmap API with bus support is available in U-boot, we introduced struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI). This series has been tested on the current master branch (after v2024.10 release). [1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.10-rc5/drivers/core/Kconf… Best regards, Romain Romain Naour (9): net: ksz9477: move struct ksz_dsa_priv *priv declaration net: ksz9477: remove dev_set_parent_priv() call net: ksz9477: add KSZ9896 switch support net: ksz9477: rename udevice_id tab to ksz_ids net: ksz9477: set i2c bus offset length only when needed net: ksz9477: store ksz bus operations functions net: ksz9477: rename ksz_i2c_probe() to ksz_probe() net: ksz9477: prepare ksz9477 without I2C support net: ksz9477: add support for KSZ GbE switches using SPI bus drivers/net/Kconfig | 6 +- drivers/net/ksz9477.c | 241 ++++++++++++++++++++++++++++++++++++++---- 2 files changed, 223 insertions(+), 24 deletions(-) -- 2.45.0

2 10

[PATCH v1 0/2] Add driver for Motorcomm YT8821 2.5G ethernet phy
by Frank Sae 28 Oct '24

28 Oct '24

YT8531 as Gigabit transceiver uses bit15:14(bit9 reserved default 0) as phy speed mask, YT8821 as 2.5 Gigabit transceiver uses bit9 bit15:14 as phy speed mask. Be compatible to YT8821, reform phy speed mask and phy speed macro. Based on update above, add YT8821 2.5G phy driver. Frank Sae (2): net: phy: motorcomm: Optimize phy speed mask to be compatible to YT8821 net: phy: motorcomm: Add driver for Motorcomm YT8821 2.5G ethernet phy drivers/net/phy/motorcomm.c | 505 +++++++++++++++++++++++++++++++++++- 1 file changed, 499 insertions(+), 6 deletions(-) -- 2.34.1

2 3