May 2022 - U-Boot

[PATCH] phy: Fix phy_string_for_interface() function
by Pali Rohár 19 May '22

19 May '22

Commit c677fb1e3196 ("phy: Move PHY_INTERFACE_MODE_NA to the beginning of the enum definition") broke function phy_string_for_interface(). And therefore completely broke support for 2500base-x mode in Armada 3720 comphy driver. Since that commit function phy_string_for_interface() returns constant value PHY_INTERFACE_MODE_NA because PHY_INTERFACE_MODE_NA from moved from end to the beginning. Previous value of PHY_INTERFACE_MODE_NA was PHY_INTERFACE_MODE_MAX-1. So change phy_string_for_interface() code to check upper bound via previous value. This patch fixes 2500base-x mode on Armada 3720 Fixes: c677fb1e3196 ("phy: Move PHY_INTERFACE_MODE_NA to the beginning of the enum definition") Signed-off-by: Pali Rohár <pali(a)kernel.org> --- include/phy_interface.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/phy_interface.h b/include/phy_interface.h index ce3b5004ec22..fed3357b9a26 100644 --- a/include/phy_interface.h +++ b/include/phy_interface.h @@ -85,7 +85,7 @@ static const char * const backplane_mode_strings[] = { static inline const char *phy_string_for_interface(phy_interface_t i) { /* Default to unknown */ - if (i > PHY_INTERFACE_MODE_NA) + if (i >= PHY_INTERFACE_MODE_MAX) i = PHY_INTERFACE_MODE_NA; return phy_interface_strings[i]; -- 2.20.1

2 2

[PATCH v2 0/8] Add MV88E61xx DSA driver and use on gwventana
by Tim Harvey 19 May '22

19 May '22

This series adds a DSA driver for the MV88E61xx based on drivers/net/phy/mv88e61xx and uses in on the gwventana_gw5904_defconfig. The hope is that the other three boards that use the MV88E61xx driver can move to this as well eventually so that we can remove the non-dm driver and the 4 Kconfig options it requires. The MV88E61xx has an MDIO interface thus DM_MDIO must be used so support for a UCLASS_MDIO driver is added to the fec_mxc ethernet driver in a way that allows a fallback to the previous non DM_MDIO case as there are many boards out there using this driver that define DM_MDIO but do not have the required dt props for a DM_MDIO driver which would cause a regression. Additionally some other patches are here suggested by Vladimir: - ensure MDIO children are scanned on post-bind is needed - sanity check DSA driver required ops are present - allow DSA drivers to not require xmit/recv functions - remove unecessary xmit/recv functions from ksz9477 driver v2: - added Ramon's rb tag's to first two patches - add patches for dsa-uclass to sanity check ops and make xmit/recv optional - fec: fix fallback for non conforming DM_MDIO dts - mv88e61xx: - rebase on v2022.07-rc2 (use ofnode_get_phy_node) - remove unused commented out fields from struct - remove unused PORT_MASK macro - remove phy from priv struct name - refactor code from original drivers/net/phy/mv88e61xx with suggestions from review to consolidate some functions into mv88e61xx_dsa_port_enable - remove unecessary skiping of disabling of CPU port - remove unecessary dev_set_parent_priv - remove unnecessary static init flag - replace debug with a dev_warn if switch device-id unsupported - remove unnecessary xmit/recv functions as we rely on the fact that only a single port is active instead of mangling packets Tested on a Gateworks GW5904 which has a Marvell 88E6176 switch hanging off the IMX6 FEC. Best Regards, Tim Tim Harvey (8): net: mdio-uclass: scan for dm mdio children on post-bind net: dsa: move cpu port probe to dsa_post_probe net: dsa: ensure dsa driver has proper ops net: dsa: allow rcv() and xmit() to be optional net: ksz9477: remove unnecessary xmit and recv functions net: fec: add support for DM_MDIO net: add MV88E61xx DSA driver board: gw_ventana: enable MV88E61XX DSA support arch/arm/dts/imx6qdl-gw5904.dtsi | 35 + board/gateworks/gw_ventana/gw_ventana.c | 50 +- configs/gwventana_gw5904_defconfig | 7 +- drivers/net/Kconfig | 7 + drivers/net/Makefile | 1 + drivers/net/fec_mxc.c | 90 ++- drivers/net/ksz9477.c | 23 - drivers/net/mv88e61xx.c | 843 ++++++++++++++++++++++++ net/dsa-uclass.c | 58 +- net/mdio-uclass.c | 4 + 10 files changed, 1045 insertions(+), 73 deletions(-) create mode 100644 drivers/net/mv88e61xx.c -- 2.17.1

2 16

[PATCH 0/8] ARM: imx: Add support for iMX6QDL DHCOM DRC02 and DH picoITX
by Philip Oberfichtner 19 May '22

19 May '22

This patch series adds support for the DHCOM DRC02 and DH picoITX baseboards by DH electronics. The two boards can be equipped with different SoMs. The STM32MP15xx based versions are already mainlined. This patch adds support for the iMX6QDL based variants. Philip Oberfichtner (8): ARM: imx6: Fix broken DT path in DH board file ARM: dts: imx: Migrate iMX6QDL DRC02 DTs from Linux ARM: dts: imx: Migrate iMX6QDL picoITX DTs from Linux ARM: imx6: Remove CONFIG_FEC_MXC_PHYADDR from DH header ARM: dts: imx: Simplify fec node for iMX6QDL DHCOM boards ARM: dts: imx: Configure FEC for iMX6QDL picoITX ARM: dts: imx: Configure FEC for iMX6QDL DRC02 ARM: imx6: Adapt device tree selection in DH board file arch/arm/dts/Makefile | 2 + arch/arm/dts/imx6dl-dhcom-picoitx-u-boot.dtsi | 10 ++ arch/arm/dts/imx6dl-dhcom-picoitx.dts | 20 +++ arch/arm/dts/imx6qdl-dhcom-drc02.dtsi | 143 ++++++++++++++++++ arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi | 13 -- arch/arm/dts/imx6qdl-dhcom-picoitx.dtsi | 69 +++++++++ arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi | 18 +++ arch/arm/dts/imx6s-dhcom-drc02-u-boot.dtsi | 10 ++ arch/arm/dts/imx6s-dhcom-drc02.dts | 30 ++++ board/dhelectronics/dh_imx6/dh_imx6.c | 26 ++-- configs/dh_imx6_defconfig | 2 +- include/configs/dh_imx6.h | 3 - 12 files changed, 319 insertions(+), 27 deletions(-) create mode 100644 arch/arm/dts/imx6dl-dhcom-picoitx-u-boot.dtsi create mode 100644 arch/arm/dts/imx6dl-dhcom-picoitx.dts create mode 100644 arch/arm/dts/imx6qdl-dhcom-drc02.dtsi create mode 100644 arch/arm/dts/imx6qdl-dhcom-picoitx.dtsi create mode 100644 arch/arm/dts/imx6s-dhcom-drc02-u-boot.dtsi create mode 100644 arch/arm/dts/imx6s-dhcom-drc02.dts -- 2.34.1

4 14

[RFC PATCH 0/8] Build Rockchip final images using binman
by Andrew Abbott 19 May '22

19 May '22

My original goal was to produce SPI images for Rockchip platforms (specifically for me, ROCKPro64, and in the future ROCK64). Looking into it, it seemed nicer to just switch the SD/MMC image generation over to binman as well in the process. This is my attempt to move Rockchip final full image generation to binman, adding the option to make full SPI images as well. I'm sending this as RFC patches because I'm not sure whether this is the ideal way to do this, whether this is even something we'd even want to do, and exactly what I might be breaking by doing this. Other questions: - I noticed that ATF generation for ARM64 Rockchip is done via a Python script instead of binman. I don't currently know how to change that over to binman, but is that something worth pursuing as part of this? Please give me your feedback! Andrew Abbott (8): binman: mkimage: Support ':'-separated inputs rockchip: Add binman definitions for final images soc: rockchip: Include common U-Boot dtsi file board: rockchip: Move SPI U-Boot offset to config rockchip: Remove obsolete Makefile targets rockchip: Enable binman for ARM64 doc: rockchip: Update for new binman image generation board: rockpro64: Enable building SPI image Kconfig | 4 +- Makefile | 31 +--------- arch/arm/Kconfig | 2 +- arch/arm/dts/rk3308-u-boot.dtsi | 2 + arch/arm/dts/rk3328-u-boot.dtsi | 2 + arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 1 - arch/arm/dts/rk3368-u-boot.dtsi | 1 + arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4 -- arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 1 - arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 -- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 -- arch/arm/dts/rk3568-u-boot.dtsi | 2 + arch/arm/dts/rockchip-u-boot.dtsi | 59 ++++++++++++++++++-- arch/arm/mach-rockchip/Kconfig | 7 +-- arch/arm/mach-rockchip/rk3399/Kconfig | 1 + configs/lion-rk3368_defconfig | 1 + configs/pinebook-pro-rk3399_defconfig | 1 + configs/puma-rk3399_defconfig | 2 +- configs/roc-pc-rk3399_defconfig | 1 + configs/rockpro64-rk3399_defconfig | 1 + doc/board/rockchip/rockchip.rst | 34 ++++------- tools/binman/etype/mkimage.py | 33 +++++++---- 22 files changed, 107 insertions(+), 91 deletions(-) -- 2.35.3

3 11

[PATCH v2] cmd: bootefi: restore ability to boot arbitrary blob
by kevans＠FreeBSD.org 19 May '22

19 May '22

From: Kyle Evans <kevans(a)FreeBSD.org> Up until commit 5f59518a7b1ae ("efi_loader: setting boot device"), we could boot an arbitrary blob with bootefi. Indeed, efi_run_image() even has a special case for missing device paths indicating a payload that was directly loaded via JTAG, for example. Restore the ability to inject a UEFI payload into memory and `bootefi` it. If the address passed isn't the last PE-COFF loaded, then we'll wipe out the pre-existing DP/Image information and let efi_run_image() synthesize a memory device path. An image size is required if we're booting an arbitrary payload, and the FDT argument has been changed to accept `-`. The size could be deduced from the image header, but it's required anyways as an explicit acknowledgment that one's trying to boot an arbitrary payload rather than accidentally using the wrong address in the single-addr form. If the image address matches the last loaded PE_COFF, it is an error to pass the incorrect size (but the size may be omitted). Signed-off-by: Kyle Evans <kevans(a)FreeBSD.org> --- Changes since v1: - Specifying an address that isn't the last-known without a size produces the same error as in the past ("No UEFI binary known at ...") - Specifying a size with the last known address that doesn't match the last recorded size will get: Size does not match known UEFI binary at %s cmd/bootefi.c | 42 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 53d9f0e0dc..0d3aecb2a1 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -425,7 +425,7 @@ static int do_efibootmgr(void) * @image_opt: string of image start address * Return: status code */ -static int do_bootefi_image(const char *image_opt) +static int do_bootefi_image(const char *image_opt, const char *size_opt) { void *image_buf; unsigned long addr, size; @@ -444,13 +444,35 @@ static int do_bootefi_image(const char *image_opt) if (!addr) return CMD_RET_USAGE; + size = 0; + if (size_opt) { + size = strtoul(size_opt, NULL, 16); + /* Check that a numeric value was passed */ + if (!size) + return CMD_RET_USAGE; + } + image_buf = map_sysmem(addr, 0); if (image_buf != image_addr) { - log_err("No UEFI binary known at %s\n", image_opt); - return CMD_RET_FAILURE; + /* Fake device path -- we must have a size. */ + + if (size == 0) { + printf("No UEFI binary known at %s\n", image_opt); + return CMD_RET_FAILURE; + } + + if (image_addr) + efi_clear_bootdev(); + } else { + if (size != 0 && size != image_size) { + printf("Size does not match known UEFI binary at %s\n", + image_opt); + return CMD_RET_FAILURE; + } + + size = image_size; } - size = image_size; } ret = efi_run_image(image_buf, size); @@ -654,7 +676,7 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag, int argc, return CMD_RET_FAILURE; } - if (argc > 2) { + if (argc > 2 && strcmp(argv[2], "-") != 0) { uintptr_t fdt_addr; fdt_addr = hextoul(argv[2], NULL); @@ -677,15 +699,19 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag, int argc, return do_efi_selftest(); #endif - return do_bootefi_image(argv[1]); + return do_bootefi_image(argv[1], argc > 3 ? argv[3] : NULL); } #ifdef CONFIG_SYS_LONGHELP static char bootefi_help_text[] = - "<image address> [fdt address]\n" + "<image address> [fdt address [image size]]\n" " - boot EFI payload stored at address <image address>.\n" " If specified, the device tree located at <fdt address> gets\n" " exposed as EFI configuration table.\n" + " The image size is required if this is not a preloaded image, but\n" + " it must be omitted if the image was preloaded.\n" + " The <fdt address> parameter accepts '-' to indicate FDT already\n" + " installed or pre-specified in fdt_addr or fdtcontroladdr.\n" #ifdef CONFIG_CMD_BOOTEFI_HELLO "bootefi hello\n" " - boot a sample Hello World application stored within U-Boot\n" @@ -707,7 +733,7 @@ static char bootefi_help_text[] = #endif U_BOOT_CMD( - bootefi, 3, 0, do_bootefi, + bootefi, 4, 0, do_bootefi, "Boots an EFI payload from memory", bootefi_help_text ); -- 2.33.0

4 4

Broken support for 4GB DDR on 32-bit platforms
by Pali Rohár 19 May '22

19 May '22

Hello! I tried to enable support for 2GB+ of DDR memory (with 4GB DDR3) on powerpc P2020 board in 32-bit addressing mode and U-Boot crashed during startup. I figured out that issue is not powerpc specific, but rather generic to all 32-bit platforms. U-Boot stores memory size into phys_size_t type (gd->ram_size) and last mapped memory address increased by one byte into phys_addr_t type (gd->ram_top). Despite size 4GB fits into 32-bit addressing mode, it does not fit into above two variables, and it overflows to zero. U-Boot then see zero RAM size and crashes. I tried to workaround this issue by changing both phys_size_t and phys_addr_t types to 64-bit. But it did not helped because U-Boot on many places cast gd->ram_size or gd->ram_top to ulong type, which is 32-bit on 32-bit platforms. Next I changed ulong parameters of board_get_usable_ram_top() function to u64. This still was not enough because config value CONFIG_MAX_MEM_MAPPED is ignored on one important place -- in function get_effective_memsize(). This config value takes effect only when also CONFIG_VERY_BIG_RAM is set. Finally With this change I was able to start U-Boot with more than 2GB of DDR memory inserted in SODIMM slot on P2020. How to fix issues with gd->ram_size and gd->ram_top? That +1 byte is really stupid limitation. Changing phys_size_t and phys_addr_t types unconditionally to 64-bit? Or something else? And what is the purpose of CONFIG_VERY_BIG_RAM config option? Why is CONFIG_MAX_MEM_MAPPED check skipped in get_effective_memsize() function, but is not skipped on many more places?

2 14

[PATCH 0/5] mx6cuboxi: add eth support for SoMs revision 1.9+
by Josua Mayer 19 May '22

19 May '22

As of Revision 1.9 the SolidRun i.MX6 SoMs ship with a new PHY - an ADIN1300 at address 1. This patchset carries many small parts to facilitate proper operation of the ethernet port in U-Boot as well as Linux: 1. Fix a compile error in the recently phy driver 2. Add support for configuring the clock output pins to the phy driver 3. update device-tree with support for the neew phy 4. support runtime patching of device-tree for Linux: enables only the phy node detected during boot, to avoid warning messages during boot. 5. finally enable the phy driver in the cuboxi defconfig Josua Mayer (5): phy: adin: remove broken support for adi,phy-mode-override phy: adin: add support for clock output ARM: dts: imx6qdl-sr-som: add support for alternate phy addresses mx6cuboxi: fixup dtb ethernet phy nodes before booting an OS mx6cuboxi: enable driver for adin1300 phy arch/arm/dts/imx6qdl-sr-som.dtsi | 17 +++++- board/solidrun/mx6cuboxi/mx6cuboxi.c | 78 +++++++++++++++++++++++++++ configs/mx6cuboxi_defconfig | 2 + drivers/net/phy/adin.c | 80 ++++++++++++++++------------ 4 files changed, 141 insertions(+), 36 deletions(-) -- 2.34.1

2 11

[PATCH v2, 1/1] riscv: Clean up asm/io.h
by Leo Yu-Chi Liang 19 May '22

19 May '22

Clean up asm/io.h by - removing commented code - removing outdated comments - removing unused definitions (for mem_isa, mem_pci) This massively improves the readability of the file. Suggested by commits: 7ab2e47d27c9 ("arm: Clean up asm/io.h") 909d0399a519 ("ARM: asm/io.h: kill off confusing #ifdef __mem_pci block") Signed-off-by: Leo Yu-Chi Liang <ycliang(a)andestech.com> Reviewed-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/riscv/include/asm/io.h | 117 +----------------------------------- 1 file changed, 1 insertion(+), 116 deletions(-) diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h index fc39bb2c70..49bffac03c 100644 --- a/arch/riscv/include/asm/io.h +++ b/arch/riscv/include/asm/io.h @@ -7,8 +7,6 @@ #ifndef __ASM_RISCV_IO_H #define __ASM_RISCV_IO_H -#ifdef __KERNEL__ - #include <linux/types.h> #include <asm/barrier.h> #include <asm/byteorder.h> @@ -39,11 +37,7 @@ static inline phys_addr_t map_to_sysmem(const void *ptr) } #endif -/* - * Generic virtual read/write. Note that we don't support half-word - * read/writes. We define __arch_*[bl] here, and leave __arch_*w - * to the architecture specific code. - */ +/* Generic virtual read/write. */ #define __arch_getb(a) (*(volatile unsigned char *)(a)) #define __arch_getw(a) (*(volatile unsigned short *)(a)) #define __arch_getl(a) (*(volatile unsigned int *)(a)) @@ -352,115 +346,6 @@ static inline void writesl(unsigned int *addr, const void *data, int longlen) #define insw_p(port, to, len) insw(port, to, len) #define insl_p(port, to, len) insl(port, to, len) -/* - * DMA-consistent mapping functions. These allocate/free a region of - * uncached, unwrite-buffered mapped memory space for use with DMA - * devices. This is the "generic" version. The PCI specific version - * is in pci.h - */ - -/* - * String version of IO memory access ops: - */ - -/* - * If this architecture has PCI memory IO, then define the read/write - * macros. These should only be used with the cookie passed from - * ioremap. - */ -#ifdef __mem_pci - -#define readb(c) ({ unsigned int __v = \ - __raw_readb(__mem_pci(c)); __v; }) -#define readw(c) ({ unsigned int __v = \ - le16_to_cpu(__raw_readw(__mem_pci(c))); __v; }) -#define readl(c) ({ unsigned int __v = \ - le32_to_cpu(__raw_readl(__mem_pci(c))); __v; }) - -#define writeb(v, c) __raw_writeb(v, __mem_pci(c)) -#define writew(v, c) __raw_writew(cpu_to_le16(v), __mem_pci(c)) -#define writel(v, c) __raw_writel(cpu_to_le32(v), __mem_pci(c)) - -#define memset_io(c, v, l) _memset_io(__mem_pci(c), (v), (l)) -#define memcpy_fromio(a, c, l) _memcpy_fromio((a), __mem_pci(c), (l)) -#define memcpy_toio(c, a, l) _memcpy_toio(__mem_pci(c), (a), (l)) - -#define eth_io_copy_and_sum(s, c, l, b) \ - eth_copy_and_sum((s), __mem_pci(c), (l), (b)) - -static inline int check_signature(ulong io_addr, const uchar *s, int len) -{ - int retval = 0; - - do { - if (readb(io_addr) != *s) - goto out; - io_addr++; - s++; - len--; - } while (len); - retval = 1; -out: - return retval; -} -#endif /* __mem_pci */ - -/* - * If this architecture has ISA IO, then define the isa_read/isa_write - * macros. - */ -#ifdef __mem_isa - -#define isa_readb(addr) __raw_readb(__mem_isa(addr)) -#define isa_readw(addr) __raw_readw(__mem_isa(addr)) -#define isa_readl(addr) __raw_readl(__mem_isa(addr)) -#define isa_writeb(val, addr) __raw_writeb(val, __mem_isa(addr)) -#define isa_writew(val, addr) __raw_writew(val, __mem_isa(addr)) -#define isa_writel(val, addr) __raw_writel(val, __mem_isa(addr)) -#define isa_memset_io(a, b, c) _memset_io(__mem_isa(a), (b), (c)) -#define isa_memcpy_fromio(a, b, c) _memcpy_fromio((a), __mem_isa(b), (c)) -#define isa_memcpy_toio(a, b, c) _memcpy_toio(__mem_isa((a)), (b), (c)) - -#define isa_eth_io_copy_and_sum(a, b, c, d) \ - eth_copy_and_sum((a), __mem_isa(b), (c), (d)) - -static inline int -isa_check_signature(ulong io_addr, const uchar *s, int len) -{ - int retval = 0; - - do { - if (isa_readb(io_addr) != *s) - goto out; - io_addr++; - s++; - len--; - } while (len); - retval = 1; -out: - return retval; -} - -#else /* __mem_isa */ - -#define isa_readb(addr) (__readwrite_bug("isa_readb"), 0) -#define isa_readw(addr) (__readwrite_bug("isa_readw"), 0) -#define isa_readl(addr) (__readwrite_bug("isa_readl"), 0) -#define isa_writeb(val, addr) __readwrite_bug("isa_writeb") -#define isa_writew(val, addr) __readwrite_bug("isa_writew") -#define isa_writel(val, addr) __readwrite_bug("isa_writel") -#define isa_memset_io(a, b, c) __readwrite_bug("isa_memset_io") -#define isa_memcpy_fromio(a, b, c) __readwrite_bug("isa_memcpy_fromio") -#define isa_memcpy_toio(a, b, c) __readwrite_bug("isa_memcpy_toio") - -#define isa_eth_io_copy_and_sum(a, b, c, d) \ - __readwrite_bug("isa_eth_io_copy_and_sum") - -#define isa_check_signature(io, sig, len) (0) - -#endif /* __mem_isa */ -#endif /* __KERNEL__ */ - #include <asm-generic/io.h> #endif /* __ASM_RISCV_IO_H */ -- 2.34.1.390.g2ae0a9cb82

1 0

VMWare crashes with U-boot EFI Payload
by Sean Nyekjaer 19 May '22

19 May '22

Hi, As described in the subject. We have an x86 image with U-boot as a EFI Payload. It crashes the VM in VMware (Player 16) with a x86 triple fault. I have tried with a clean U-boot build with efi-x86_payload64_defconfig. I can see in the VM it prints U-boot EFI Payload and then throws the triple fault. Both a clean and our modified U-boot is working fine in qemu and on our real x86 hardware. Any idea's how to proceed with debuging this? /Sean

1 0

PATCH] Add support for the Digilent Arty-Z7 Xilinx ZYNQ based board
by Christopher Bowman 19 May '22

19 May '22

Patch to add support for the Diligent Arty-Z7 Xilinx ZYNQ based board. This work fine booting FreeBSD 13.1 on my board. First time submitter, so I appreciate feedback. Regards, Christopher Signed-off-by: crb(a)ChrisBowman.com

2 1