Re: [PATCH 0/4] arm: bcmbca: add basic support for more Broadcom BCA SoCs

[William Zhang]

Hi Florian,

Thanks for the review!  Please see my comments inline blow,

On 08/08/2022 08:29 PM, Florian Fainelli wrote:



On 8/5/2022 6:33 PM, William Zhang wrote:

Broadcom BCA (Broadband Carrier Access origin) chipset family includes
DSL, PON and WLAN access point and gateway SoC. Now that the ARCH_BCMBCA
architecture and its first SoC BCM47622 are supported in u-boot 2022.07,
this patch series add the basic support for following BCA chips under
ARCH_BCMBCA: BCM4908, BCM4912, BCM63146 and BCM6813.

This patch series applies on top of the my previous patch [1].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/491060.html


Looks good to me, thanks William! On the mmu_table.c implementation 
maybe just a few nits:


- should not we do an early parsing of the memory node for the given 
board(s) to ensure that we map no more than the amount of available DRAM?


Yes there will be a patch after all these SoC patches to set the ddr 
size during the dram_init based on the actually memory size.


- the exact same file is currently being re-used, so it would make sense 
to make it a common object
For these initial soc support patches,  I just include the ddr and 
periph block and they happen to be the same range. But different SoC has 
different ip block address as we add more more blocks/drivers late. To 
avoid many ifdef,  I would prefer to have one file per chip.




- you could create a memory mapping for the AXI bus region right away to 
avoid forgetting about it later if you start bringing up drivers that 
make use of that peripheral region


Yeah I could but we won't forget either because system will crash if we 
miss that entry in the mmu table.  IMHO it is better to limit the access 
than opening a wide range that we don't use.  We can catch 
invalid/unintended access by only allowing the regions that we need to 
access.



Thanks!


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/4] arm: bcmbca: add basic support for more Broadcom BCA SoCs

[Florian Fainelli]

On 8/5/2022 6:33 PM, William Zhang wrote:

Broadcom BCA (Broadband Carrier Access origin) chipset family includes
DSL, PON and WLAN access point and gateway SoC. Now that the ARCH_BCMBCA
architecture and its first SoC BCM47622 are supported in u-boot 2022.07,
this patch series add the basic support for following BCA chips under
ARCH_BCMBCA: BCM4908, BCM4912, BCM63146 and BCM6813.

This patch series applies on top of the my previous patch [1].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/491060.html


Looks good to me, thanks William! On the mmu_table.c implementation 
maybe just a few nits:


- should not we do an early parsing of the memory node for the given 
board(s) to ensure that we map no more than the amount of available DRAM?


- the exact same file is currently being re-used, so it would make sense 
to make it a common object


- you could create a memory mapping for the AXI bus region right away to 
avoid forgetting about it later if you start bringing up drivers that 
make use of that peripheral region


Thanks!
--
Florian

Re: [PATCH 4/4] arm: bcmbca: add bcm4908 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM4908 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added
under ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux git repository so the dts and dtsi
files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 


Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 3/4] arm: bcmbca: add bcm6813 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM6813 is a Broadcom B53 based PON and WLAN AP router SoC. It is part
of the BCA (Broadband Carrier Access origin) chipset family so it's
added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 
---

  MAINTAINERS  |   1 +
  arch/arm/dts/Makefile|   2 +
  arch/arm/dts/bcm6813.dtsi| 128 +++
  arch/arm/dts/bcm96813.dts|  30 ++
  arch/arm/mach-bcmbca/Kconfig |   8 ++
  arch/arm/mach-bcmbca/Makefile|   1 +
  arch/arm/mach-bcmbca/bcm6813/Kconfig |  17 +++
  arch/arm/mach-bcmbca/bcm6813/Makefile|   5 +
  arch/arm/mach-bcmbca/bcm6813/mmu_table.c |  32 ++


OK, so after seeing the same mmu_table.c 4 times, maybe we could share a 
common implementation that is configurable enough, even if there may not 
be any need for configuration other than the DRAM size.


Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 2/4] arm: bcmbca: add bcm4912 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM4912 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts
and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang 


Same question as in patch #1, but otherwise:

Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 1/4] arm: bcmbca: add bcm63146 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM63146 is a Broadcom B53 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 
---


[snip]


+#include 
+#include 
+#include 
+
+static struct mm_region bcm963146_mem_map[] = {
+   {
+   .virt = 0xUL,
+   .phys = 0xUL,
+   .size = 1UL * SZ_1G,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+   PTE_BLOCK_INNER_SHARE
+   },
+   {


Should you create a mapping for the AXI bus portion at PA 0x8100 
just so it is already in place for when you might need it?


Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH] arm: kirkwood: nsa310s: Add Distro boot capability

[Tony Dinh]

Hi Stefan,

I need to resend this patch. Sorry for the noise!

Thanks,
Tony

On Mon, Aug 8, 2022 at 7:35 PM Tony Dinh  wrote:
>
> - Add distro boot to board include file and deconfig file
> - Miscellaneous changes:
> - Remove Gerald from maintainer list (email bounced)
> - Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
> kernel method of booting (e.g. OpenWrt) with appended DTB.
> - Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
>
> Note that this patch is depended on the following patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
>
> Signed-off-by: Tony Dinh 
> ---
>
>  board/zyxel/nsa310s/MAINTAINERS |  1 -
>  configs/nsa310s_defconfig   | 17 
>  include/configs/nsa310s.h   | 48 +
>  3 files changed, 48 insertions(+), 18 deletions(-)
>
> diff --git a/board/zyxel/nsa310s/MAINTAINERS b/board/zyxel/nsa310s/MAINTAINERS
> index d153758c21..11106acf3e 100644
> --- a/board/zyxel/nsa310s/MAINTAINERS
> +++ b/board/zyxel/nsa310s/MAINTAINERS
> @@ -1,5 +1,4 @@
>  NSA310S BOARD
> -M: Gerald Kerma 
>  M: Tony Dinh 
>  M: Luka Perkov 
>  S: Maintained
> diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
> index 2b39ae74b3..a5f01ef88e 100644
> --- a/configs/nsa310s_defconfig
> +++ b/configs/nsa310s_defconfig
> @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
>  CONFIG_ARCH_CPU_INIT=y
>  CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_KIRKWOOD=y
> +CONFIG_SUPPORT_PASSING_ATAGS=y
> +CONFIG_CMDLINE_TAG=y
> +CONFIG_INITRD_TAG=y
>  CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
>  CONFIG_SYS_TEXT_BASE=0x60
>  CONFIG_SYS_MALLOC_F_LEN=0x400
> @@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
>  CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
>  CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
>  CONFIG_SYS_LOAD_ADDR=0x80
> +CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
>  CONFIG_BOOTDELAY=3
> -CONFIG_USE_BOOTCOMMAND=y
> -CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root}; 
> ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; ubifsload 
> 0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt resize; fdt chosen; 
> bootz 0x80 - 0x70"
>  CONFIG_USE_PREBOOT=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
> -CONFIG_HUSH_PARSER=y
>  CONFIG_SYS_PROMPT="NSA310s> "
>  CONFIG_SYS_MAXARGS=32
>  CONFIG_SYS_PBSIZE=1050
> -CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_NAND=y
>  CONFIG_CMD_SATA=y
>  CONFIG_CMD_USB=y
>  # CONFIG_CMD_SETEXPR is not set
> -CONFIG_CMD_DHCP=y
> -CONFIG_CMD_MII=y
> -CONFIG_CMD_PING=y
> -CONFIG_CMD_EXT2=y
> -CONFIG_CMD_FAT=y
> -CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_JFFS2=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
>  CONFIG_CMD_UBI=y
> -CONFIG_ISO_PARTITION=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_ENV_IS_IN_NAND=y
> @@ -65,6 +58,6 @@ CONFIG_MII=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
> -CONFIG_USB_STORAGE=y
> +CONFIG_UBIFS_SILENCE_MSG=y
>  CONFIG_LZMA=y
>  CONFIG_BZIP2=y
> diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
> index 027a47b5a3..a538721c45 100644
> --- a/include/configs/nsa310s.h
> +++ b/include/configs/nsa310s.h
> @@ -9,15 +9,53 @@
>  #ifndef _CONFIG_NSA310S_H
>  #define _CONFIG_NSA310S_H
>
> +/*
> + * mv-common.h should be defined after CMD configs since it used them
> + * to enable certain macros
> + */
>  #include "mv-common.h"
>
> -/* default environment variables */
> +/* Include the common distro boot environment */
> +#ifndef CONFIG_SPL_BUILD
> +
> +#ifdef CONFIG_SATA
> +#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_SATA(func)
> +#endif
> +
> +#ifdef CONFIG_USB_STORAGE
> +#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_USB(func)
> +#endif
> +
> +#define BOOT_TARGET_DEVICES(func) \
> +   BOOT_TARGET_DEVICES_USB(func) \
> +   BOOT_TARGET_DEVICES_SATA(func) \
> +   func(DHCP, dhcp, na)
> +
> +#define KERNEL_ADDR_R  __stringify(0x80)
> +#define FDT_ADDR_R __stringify(0x2c0)
> +#define RAMDISK_ADDR_R __stringify(0x0110)
> +#define SCRIPT_ADDR_R  __stringify(0x20)
> +
> +#define LOAD_ADDRESS_ENV_SETTINGS \
> +   "kernel_addr_r=" KERNEL_ADDR_R "\0" \
> +   "fdt_addr_r=" FDT_ADDR_R "\0" \
> +   "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
> +   "scriptaddr=" SCRIPT_ADDR_R "\0"
> +
> +#include 
>
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> -   "console=console=ttyS0,115200\0" \
> -   "kernel=/boot/zImage\0" \
> -   "fdt=/boot/nsa310s.dtb\0" \
> -   "bootargs_root=ubi.mtd=3 

[PATCH] arm: kirkwood: pogo_v4: Add Distro boot capability

[Tony Dinh]

- Add distro boot to board include file and deconfig file
- Miscellaneous changes:
- Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
kernel method of booting (e.g. OpenWrt) with appended DTB.
- Add CONFIG_LTO and CONFIG_UBIFS_SILENCE_MSG, and disable some
unused configs  to reduce binary size.

Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/

Signed-off-by: Tony Dinh 
---

 configs/pogo_v4_defconfig | 25 --
 include/configs/pogo_v4.h | 54 +--
 2 files changed, 57 insertions(+), 22 deletions(-)

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index c62c88f1b5..748842100e 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SUPPORT_PASSING_ATAGS=y
+CONFIG_CMDLINE_TAG=y
+CONFIG_INITRD_TAG=y
 CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_v4/kwbimage.cfg"
 CONFIG_SYS_TEXT_BASE=0x60
 CONFIG_SYS_MALLOC_F_LEN=0x400
@@ -13,23 +16,24 @@ CONFIG_ENV_OFFSET=0xC
 CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4"
 CONFIG_IDENT_STRING="\nPogoplug V4"
 CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_LTO=y
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
 CONFIG_BOOTSTAGE=y
 CONFIG_SHOW_BOOT_PROGRESS=y
 CONFIG_BOOTDELAY=10
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="setenv bootargs ${bootargs_console}; run bootcmd_usb; 
bootm 0x0080 0x0110 0x2c0"
 CONFIG_USE_PREBOOT=y
 CONFIG_BOARD_LATE_INIT=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Pogo_V4> "
 CONFIG_SYS_MAXARGS=32
 CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_BOOTZ=y
 # CONFIG_BOOTM_PLAN9 is not set
 # CONFIG_BOOTM_RTEMS is not set
 # CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MTD=y
@@ -37,22 +41,14 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SATA=y
 CONFIG_CMD_USB=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_CMD_BLOCK_CACHE is not set
 CONFIG_CMD_JFFS2=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)"
 CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
-CONFIG_EFI_PARTITION=y
 CONFIG_PARTITION_TYPE_GUID=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
@@ -62,6 +58,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NETCONSOLE=y
 CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y
 CONFIG_DM=y
+# CONFIG_DM_WARN is not set
 CONFIG_SATA_MV=y
 CONFIG_SYS_SATA_MAX_DEVICE=1
 CONFIG_LBA48=y
@@ -84,6 +81,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_PCI=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
 CONFIG_JFFS2_LZO=y
 CONFIG_JFFS2_NAND=y
+CONFIG_UBIFS_SILENCE_MSG=y
diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h
index 7fff78b7b5..b5ce2dd13d 100644
--- a/include/configs/pogo_v4.h
+++ b/include/configs/pogo_v4.h
@@ -21,15 +21,53 @@
  */
 #include "mv-common.h"
 
-/*
- * Default environment variables
- */
+/* Include the common distro boot environment */
+#ifndef CONFIG_SPL_BUILD
+
+#ifdef CONFIG_MMC
+#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
+#else
+#define BOOT_TARGET_DEVICES_MMC(func)
+#endif
+
+#ifdef CONFIG_SATA
+#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
+#else
+#define BOOT_TARGET_DEVICES_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_DEVICES_MMC(func) \
+   BOOT_TARGET_DEVICES_USB(func) \
+   BOOT_TARGET_DEVICES_SATA(func) \
+   func(DHCP, dhcp, na)
+
+#define KERNEL_ADDR_R  __stringify(0x80)
+#define FDT_ADDR_R __stringify(0x2c0)
+#define RAMDISK_ADDR_R __stringify(0x0110)
+#define SCRIPT_ADDR_R  __stringify(0x20)
+
+#define LOAD_ADDRESS_ENV_SETTINGS \
+   "kernel_addr_r=" KERNEL_ADDR_R "\0" \
+   "fdt_addr_r=" FDT_ADDR_R "\0" \
+   "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
+   "scriptaddr=" SCRIPT_ADDR_R "\0"
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "dtb_file=/boot/dts/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
-   "bootargs_console=console=ttyS0,115200\0" \
-   "bootcmd_usb=usb start; load usb 0:1 0x0080 /boot/uImage; " \
-   "load usb 0:1 0x0110 /boot/uInitrd; " \
-   "load usb 0:1 0x2c0 $dtb_file\0"
+   LOAD_ADDRESS_ENV_SETTINGS \
+   "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+   

RE: [PATCH 016/347] FogBugz #516535: Fix QSPI write issues

[Chee, Tien Fong]

Hi Jit Loon,

> -Original Message-
> From: Lim, Jit Loon 
> Sent: Tuesday, 2 August, 2022 9:55 PM
> To: u-boot@lists.denx.de
> Cc: Jagan Teki ; Vignesh R ;
> Vasut, Marek ; Simon ;
> Chaplin, Kris ; Chee, Tien Fong
> ; Hea, Kok Kiang ; Lim,
> Elly Siew Chin ; Kho, Sin Hui
> ; Lokanathan, Raaj ;
> Maniyam, Dinesh ; Ng, Boon Khai
> ; Yuslaimi, Alif Zakuan
> ; Chong, Teik Heng
> ; Zamri, Muhammad Hazim Izzat
> ; Lim, Jit Loon
> ; Chee Hong Ang 
> Subject: [PATCH 016/347] FogBugz #516535: Fix QSPI write issues

Please drop the "[PATCH 016/347]" and replace "FogBugz #516535" with 
appropriate tag.

> 
> From: Chee Hong Ang 
> 
> QSPI driver perform chip select on every flash read/write access. The driver 
> need
> to disable/enable the QSPI controller while performing chip select. This may
> cause some data lost especially the QSPI controller is configured to run at
> slower speed as it may take longer time to access the flash device.
> This patch prevent the driver from disable/enable the QSPI controller too soon
> and inadvertently halting any ongoing flash read/write access by ensuring the
> QSPI controller is always in idle mode after each read/write access.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  drivers/spi/cadence_qspi_apb.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index 2cdf4c9c9f..5e03495f45 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -858,13 +858,9 @@ cadence_qspi_apb_indirect_read_execute(struct
> cadence_spi_plat *plat,
>   writel(CQSPI_REG_INDIRECTRD_DONE,
>  plat->regbase + CQSPI_REG_INDIRECTRD);
> 
> - /* Check indirect done status */
> - ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
> - CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
> - if (ret) {
> - printf("Indirect read clear completion error (%i)\n", ret);
> - goto failrd;
> - }
> + /* Wait til QSPI is idle */
> + if (!cadence_qspi_wait_idle(plat->regbase))
> + return -EIO;
> 
>   return 0;
> 
> @@ -1031,6 +1027,11 @@ cadence_qspi_apb_indirect_write_execute(struct
> cadence_spi_plat *plat,
> 
>   if (bounce_buf)
>   free(bounce_buf);
> +
> + /* Wait til QSPI is idle */
> + if (!cadence_qspi_wait_idle(plat->regbase))
> + return -EIO;
> +
>   return 0;
> 
>  failwr:
> --
> 2.25.1

Regards,
Tien Fong

[PATCH] CI: Azure: Move to Ubuntu 22.04 image

[Tom Rini]

As per https://github.com/actions/runner-images/issues/6002 the Ubuntu
18.04 image is deprecated and will be removed by December 1, 2022.
Move to the Ubuntu 22.04 image as our base for launching our containers
from.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 36ca3cb46264..47bf3b5e01ec 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -1,6 +1,6 @@
 variables:
   windows_vm: windows-2019
-  ubuntu_vm: ubuntu-18.04
+  ubuntu_vm: ubuntu-22.04
   macos_vm: macOS-10.15
   ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20220302-15Mar2022
   # Add '-u 0' options for Azure pipelines, otherwise we get "permission
-- 
2.25.1

[PATCH] arm: kirkwood: nsa310s: Add Distro boot capability

[Tony Dinh]

- Add distro boot to board include file and deconfig file
- Miscellaneous changes:
- Remove Gerald from maintainer list (email bounced)
- Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
kernel method of booting (e.g. OpenWrt) with appended DTB.
- Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.

Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/

Signed-off-by: Tony Dinh 
---

 board/zyxel/nsa310s/MAINTAINERS |  1 -
 configs/nsa310s_defconfig   | 17 
 include/configs/nsa310s.h   | 48 +
 3 files changed, 48 insertions(+), 18 deletions(-)

diff --git a/board/zyxel/nsa310s/MAINTAINERS b/board/zyxel/nsa310s/MAINTAINERS
index d153758c21..11106acf3e 100644
--- a/board/zyxel/nsa310s/MAINTAINERS
+++ b/board/zyxel/nsa310s/MAINTAINERS
@@ -1,5 +1,4 @@
 NSA310S BOARD
-M: Gerald Kerma 
 M: Tony Dinh 
 M: Luka Perkov 
 S: Maintained
diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
index 2b39ae74b3..a5f01ef88e 100644
--- a/configs/nsa310s_defconfig
+++ b/configs/nsa310s_defconfig
@@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SUPPORT_PASSING_ATAGS=y
+CONFIG_CMDLINE_TAG=y
+CONFIG_INITRD_TAG=y
 CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
 CONFIG_SYS_TEXT_BASE=0x60
 CONFIG_SYS_MALLOC_F_LEN=0x400
@@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
 CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
 CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
 CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
 CONFIG_BOOTDELAY=3
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root}; 
ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; ubifsload 
0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt resize; fdt chosen; bootz 
0x80 - 0x70"
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="NSA310s> "
 CONFIG_SYS_MAXARGS=32
 CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_NAND=y
 CONFIG_CMD_SATA=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_JFFS2=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
 CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_NAND=y
@@ -65,6 +58,6 @@ CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
+CONFIG_UBIFS_SILENCE_MSG=y
 CONFIG_LZMA=y
 CONFIG_BZIP2=y
diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
index 027a47b5a3..a538721c45 100644
--- a/include/configs/nsa310s.h
+++ b/include/configs/nsa310s.h
@@ -9,15 +9,53 @@
 #ifndef _CONFIG_NSA310S_H
 #define _CONFIG_NSA310S_H
 
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
 #include "mv-common.h"
 
-/* default environment variables */
+/* Include the common distro boot environment */
+#ifndef CONFIG_SPL_BUILD
+
+#ifdef CONFIG_SATA
+#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
+#else
+#define BOOT_TARGET_DEVICES_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_DEVICES_USB(func) \
+   BOOT_TARGET_DEVICES_SATA(func) \
+   func(DHCP, dhcp, na)
+
+#define KERNEL_ADDR_R  __stringify(0x80)
+#define FDT_ADDR_R __stringify(0x2c0)
+#define RAMDISK_ADDR_R __stringify(0x0110)
+#define SCRIPT_ADDR_R  __stringify(0x20)
+
+#define LOAD_ADDRESS_ENV_SETTINGS \
+   "kernel_addr_r=" KERNEL_ADDR_R "\0" \
+   "fdt_addr_r=" FDT_ADDR_R "\0" \
+   "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
+   "scriptaddr=" SCRIPT_ADDR_R "\0"
+
+#include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "console=console=ttyS0,115200\0" \
-   "kernel=/boot/zImage\0" \
-   "fdt=/boot/nsa310s.dtb\0" \
-   "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0"
+   LOAD_ADDRESS_ENV_SETTINGS \
+   "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+   "console=ttyS0,115200\0" \
+   BOOTENV
+
+#endif /* CONFIG_SPL_BUILD */
 
 /* Ethernet driver configuration */
 #define CONFIG_MVGBE_PORTS {1, 0}  /* enable port 0 only */
-- 
2.30.2

Re: ethernet dt aliases implications in U-Boot and Linux

[Stephen Hemminger]

On Mon, 8 Aug 2022 23:09:45 +0200
Michal Suchánek  wrote:

> On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> > Hi Tim,
> > 
> > On 8/8/22 3:18 PM, Tim Harvey wrote:  
> > > Greetings,
> > > 
> > > I'm trying to understand if there is any implication of 'ethernet'
> > > aliases in Linux such as:
> > > aliases {
> > > ethernet0 = 
> > > ethernet1 = 
> > > ethernet2 = 
> > > ethernet3 = 
> > > ethernet4 = 
> > > ethernet5 = 
> > > ethernet6 = 
> > > };
> > > 
> > > I know U-Boot boards that use device-tree will use these aliases to
> > > name the devices in U-Boot such that the device with alias 'ethernet0'
> > > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > > appears that the naming of network devices that are embedded (ie SoC)
> > > vs enumerated (ie pci/usb) are always based on device registration
> > > order which for static drivers depends on Makefile linking order and
> > > has nothing to do with device-tree.
> > > 
> > > Is there currently any way to control network device naming in Linux
> > > other than udev?  
> > 
> > You can also use systemd-networkd et al. (but that is the same kind of 
> > mechanism)
> >   
> > > Does Linux use the ethernet aliases for anything at all?  
> > 
> > No :l  
> 
> Maybe it's a great opportunity for porting biosdevname to DT based
> platforms ;-)

Sorry, biosdevname was wrong way to do things.
Did you look at the internals, it was dumpster diving as root into BIOS.

Systemd-networkd does things in much more supportable manner using existing
sysfs API's.

[ANN] U-Boot v2022.10-rc2 released

[Tom Rini]

Hey all,

It's release day and so here's v2022.10-rc2. I hope that we're now
approaching the stabilization period with this release, but I think
we'll see a few more things still come in before -rc3.

In terms of a changelog, 
git log --merges v2022.10-rc1..v2022.10-rc2
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

So we're now looking at regular releases every other Monday, and with
final release on October 3rd, 2022.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: ethernet dt aliases implications in U-Boot and Linux

[Michal Suchánek]

On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> On Mon, 8 Aug 2022 23:09:45 +0200
> Michal Suchánek  wrote:
> 
> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> > > Hi Tim,
> > > 
> > > On 8/8/22 3:18 PM, Tim Harvey wrote:  
> > > > Greetings,
> > > > 
> > > > I'm trying to understand if there is any implication of 'ethernet'
> > > > aliases in Linux such as:
> > > > aliases {
> > > > ethernet0 = 
> > > > ethernet1 = 
> > > > ethernet2 = 
> > > > ethernet3 = 
> > > > ethernet4 = 
> > > > ethernet5 = 
> > > > ethernet6 = 
> > > > };
> > > > 
> > > > I know U-Boot boards that use device-tree will use these aliases to
> > > > name the devices in U-Boot such that the device with alias 'ethernet0'
> > > > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > > > appears that the naming of network devices that are embedded (ie SoC)
> > > > vs enumerated (ie pci/usb) are always based on device registration
> > > > order which for static drivers depends on Makefile linking order and
> > > > has nothing to do with device-tree.
> > > > 
> > > > Is there currently any way to control network device naming in Linux
> > > > other than udev?  
> > > 
> > > You can also use systemd-networkd et al. (but that is the same kind of 
> > > mechanism)
> > >   
> > > > Does Linux use the ethernet aliases for anything at all?  
> > > 
> > > No :l  
> > 
> > Maybe it's a great opportunity for porting biosdevname to DT based
> > platforms ;-)
> 
> Sorry, biosdevname was wrong way to do things.
> Did you look at the internals, it was dumpster diving as root into BIOS.

When it's BIOS what defines the names then you have to read them from
the BIOS. Recently it was updated to use some sysfs file or whatver.
It's not like you would use any of that code with DT, anyway.

> Systemd-networkd does things in much more supportable manner using existing
> sysfs API's.

Which is a dumpster of systemd code, no thanks.

I want my device naming independent of the init system, especially if
it's systemd.

Thanks

Michal

Re: ethernet dt aliases implications in U-Boot and Linux

[Tim Harvey]

On Mon, Aug 8, 2022 at 2:34 PM Florian Fainelli  wrote:
>
> On 8/8/22 14:28, Tim Harvey wrote:
> > On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli  
> > wrote:
> >>
> >> On 8/8/22 12:57, Sean Anderson wrote:
> >>> Hi Tim,
> >>>
> >>> On 8/8/22 3:18 PM, Tim Harvey wrote:
>  Greetings,
> 
>  I'm trying to understand if there is any implication of 'ethernet'
>  aliases in Linux such as:
>    aliases {
>    ethernet0 = 
>    ethernet1 = 
>    ethernet2 = 
>    ethernet3 = 
>    ethernet4 = 
>    ethernet5 = 
>    ethernet6 = 
>    };
> 
>  I know U-Boot boards that use device-tree will use these aliases to
>  name the devices in U-Boot such that the device with alias 'ethernet0'
>  becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
>  appears that the naming of network devices that are embedded (ie SoC)
>  vs enumerated (ie pci/usb) are always based on device registration
>  order which for static drivers depends on Makefile linking order and
>  has nothing to do with device-tree.
> 
>  Is there currently any way to control network device naming in Linux
>  other than udev?
> >>>
> >>> You can also use systemd-networkd et al. (but that is the same kind of 
> >>> mechanism)
> >>>
>  Does Linux use the ethernet aliases for anything at all?
> >>>
> >>> No :l
> >>
> >> It is actually used, but by individual drivers, not by the networking
> >> stack AFAICT:
> >>
> >> git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
> >> drivers/net/ethernet/broadcom/genet/bcmmii.c:   id =
> >> of_alias_get_id(dn, "eth");
> >> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >> drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >>
> >> There were discussions about using that alias to name ethernet network
> >> devices in the past (cannot quite point to the thread), the current
> >> consensus appears to be that if you use the "label" property (which was
> >> primed by DSA) then your network device will follow that name, still not
> >> something the networking stack does for you within the guts of
> >> register_netdev().
> >
> > Right, I recall several discussions and debates about this.
> >
> > I did find a few references:
> > - failed attempt at using dt for naming:
> > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezil...@free-electrons.com/
> > - systemd predicatable interface names:
> > https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
> >
> > I do find it odd that for DSA devices the port names are defined in dt
> > yet the cpu uplink port can not be.
>
> There is no network interface created for the CPU port on the switch
> side, and the other network device (named the DSA conduit) is just a
> conduit, so its name does not matter so much except for making sure that
> it is brought up before the DSA ports that are dependent upon it and
> that can be resolved via "ip link show (the interface after the '@'). It
> matter even less nowadays that it gets brought up automatically by any
> of the user facing ports of the DSA switch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974
>

Florian,

Thanks for pointing this out - I had not noticed that addition which
looks like it made it in at v5.12.

Tim

> >
> > The issue I was trying to work through is an IMX8MP board which has
> > IMX8MP FEC as the cpu uplink port to a GbE switch and IMX8MP EQOS as
> > an additional GbE. In this case the FEC enumerates first becoming eth0
> > and the EQOS second becoming eth1. I wanted to make the EQOS eth0 as
> > it is the first RJ45 on the board physically followed by
> > lan1/lan2/lan3/lan4/lan5. While I can do this in U-Boot by controlling
> > the aliases for fec/eqos the same doesn't work for Linux so it's not
> > worth doing as that would add user confusion.
>
> None of that should matter in Linux anymore however, the names of the
> Ethernet controller(s) connected to your switch have no significance,
> see above.
>
> >
> > I have never liked the idea of using systemd to deal with network
> > interface re-naming as that's just another dependency where embedded
> > Linux users typically want to strip things down to the bare minimum.
>
> Fair enough.
> --
> Florian

Re: ethernet dt aliases implications in U-Boot and Linux

[Florian Fainelli]

On 8/8/22 14:28, Tim Harvey wrote:

On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli  wrote:


On 8/8/22 12:57, Sean Anderson wrote:

Hi Tim,

On 8/8/22 3:18 PM, Tim Harvey wrote:

Greetings,

I'm trying to understand if there is any implication of 'ethernet'
aliases in Linux such as:
  aliases {
  ethernet0 = 
  ethernet1 = 
  ethernet2 = 
  ethernet3 = 
  ethernet4 = 
  ethernet5 = 
  ethernet6 = 
  };

I know U-Boot boards that use device-tree will use these aliases to
name the devices in U-Boot such that the device with alias 'ethernet0'
becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
appears that the naming of network devices that are embedded (ie SoC)
vs enumerated (ie pci/usb) are always based on device registration
order which for static drivers depends on Makefile linking order and
has nothing to do with device-tree.

Is there currently any way to control network device naming in Linux
other than udev?


You can also use systemd-networkd et al. (but that is the same kind of 
mechanism)


Does Linux use the ethernet aliases for anything at all?


No :l


It is actually used, but by individual drivers, not by the networking
stack AFAICT:

git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
drivers/net/ethernet/broadcom/genet/bcmmii.c:   id =
of_alias_get_id(dn, "eth");
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id =
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id =
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id =
of_alias_get_id(np, "ethernet");

There were discussions about using that alias to name ethernet network
devices in the past (cannot quite point to the thread), the current
consensus appears to be that if you use the "label" property (which was
primed by DSA) then your network device will follow that name, still not
something the networking stack does for you within the guts of
register_netdev().


Right, I recall several discussions and debates about this.

I did find a few references:
- failed attempt at using dt for naming:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezil...@free-electrons.com/
- systemd predicatable interface names:
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/

I do find it odd that for DSA devices the port names are defined in dt
yet the cpu uplink port can not be.


There is no network interface created for the CPU port on the switch 
side, and the other network device (named the DSA conduit) is just a 
conduit, so its name does not matter so much except for making sure that 
it is brought up before the DSA ports that are dependent upon it and 
that can be resolved via "ip link show (the interface after the '@'). It 
matter even less nowadays that it gets brought up automatically by any 
of the user facing ports of the DSA switch:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974



The issue I was trying to work through is an IMX8MP board which has
IMX8MP FEC as the cpu uplink port to a GbE switch and IMX8MP EQOS as
an additional GbE. In this case the FEC enumerates first becoming eth0
and the EQOS second becoming eth1. I wanted to make the EQOS eth0 as
it is the first RJ45 on the board physically followed by
lan1/lan2/lan3/lan4/lan5. While I can do this in U-Boot by controlling
the aliases for fec/eqos the same doesn't work for Linux so it's not
worth doing as that would add user confusion.


None of that should matter in Linux anymore however, the names of the 
Ethernet controller(s) connected to your switch have no significance, 
see above.




I have never liked the idea of using systemd to deal with network
interface re-naming as that's just another dependency where embedded
Linux users typically want to strip things down to the bare minimum.


Fair enough.
--
Florian

Re: ethernet dt aliases implications in U-Boot and Linux

[Tim Harvey]

On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli  wrote:
>
> On 8/8/22 12:57, Sean Anderson wrote:
> > Hi Tim,
> >
> > On 8/8/22 3:18 PM, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I'm trying to understand if there is any implication of 'ethernet'
> >> aliases in Linux such as:
> >>  aliases {
> >>  ethernet0 = 
> >>  ethernet1 = 
> >>  ethernet2 = 
> >>  ethernet3 = 
> >>  ethernet4 = 
> >>  ethernet5 = 
> >>  ethernet6 = 
> >>  };
> >>
> >> I know U-Boot boards that use device-tree will use these aliases to
> >> name the devices in U-Boot such that the device with alias 'ethernet0'
> >> becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> >> appears that the naming of network devices that are embedded (ie SoC)
> >> vs enumerated (ie pci/usb) are always based on device registration
> >> order which for static drivers depends on Makefile linking order and
> >> has nothing to do with device-tree.
> >>
> >> Is there currently any way to control network device naming in Linux
> >> other than udev?
> >
> > You can also use systemd-networkd et al. (but that is the same kind of 
> > mechanism)
> >
> >> Does Linux use the ethernet aliases for anything at all?
> >
> > No :l
>
> It is actually used, but by individual drivers, not by the networking
> stack AFAICT:
>
> git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
> drivers/net/ethernet/broadcom/genet/bcmmii.c:   id =
> of_alias_get_id(dn, "eth");
> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id =
> of_alias_get_id(np, "ethernet");
> drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id =
> of_alias_get_id(np, "ethernet");
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id =
> of_alias_get_id(np, "ethernet");
>
> There were discussions about using that alias to name ethernet network
> devices in the past (cannot quite point to the thread), the current
> consensus appears to be that if you use the "label" property (which was
> primed by DSA) then your network device will follow that name, still not
> something the networking stack does for you within the guts of
> register_netdev().

Right, I recall several discussions and debates about this.

I did find a few references:
- failed attempt at using dt for naming:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezil...@free-electrons.com/
- systemd predicatable interface names:
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/

I do find it odd that for DSA devices the port names are defined in dt
yet the cpu uplink port can not be.

The issue I was trying to work through is an IMX8MP board which has
IMX8MP FEC as the cpu uplink port to a GbE switch and IMX8MP EQOS as
an additional GbE. In this case the FEC enumerates first becoming eth0
and the EQOS second becoming eth1. I wanted to make the EQOS eth0 as
it is the first RJ45 on the board physically followed by
lan1/lan2/lan3/lan4/lan5. While I can do this in U-Boot by controlling
the aliases for fec/eqos the same doesn't work for Linux so it's not
worth doing as that would add user confusion.

I have never liked the idea of using systemd to deal with network
interface re-naming as that's just another dependency where embedded
Linux users typically want to strip things down to the bare minimum.

Best Regards,

Tim

Re: ethernet dt aliases implications in U-Boot and Linux

[Florian Fainelli]

On 8/8/22 12:57, Sean Anderson wrote:

Hi Tim,

On 8/8/22 3:18 PM, Tim Harvey wrote:

Greetings,

I'm trying to understand if there is any implication of 'ethernet'
aliases in Linux such as:
 aliases {
 ethernet0 = 
 ethernet1 = 
 ethernet2 = 
 ethernet3 = 
 ethernet4 = 
 ethernet5 = 
 ethernet6 = 
 };

I know U-Boot boards that use device-tree will use these aliases to
name the devices in U-Boot such that the device with alias 'ethernet0'
becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
appears that the naming of network devices that are embedded (ie SoC)
vs enumerated (ie pci/usb) are always based on device registration
order which for static drivers depends on Makefile linking order and
has nothing to do with device-tree.

Is there currently any way to control network device naming in Linux
other than udev?


You can also use systemd-networkd et al. (but that is the same kind of 
mechanism)


Does Linux use the ethernet aliases for anything at all?


No :l


It is actually used, but by individual drivers, not by the networking 
stack AFAICT:


git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
drivers/net/ethernet/broadcom/genet/bcmmii.c:   id = 
of_alias_get_id(dn, "eth");
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id = 
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id = 
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id = 
of_alias_get_id(np, "ethernet");


There were discussions about using that alias to name ethernet network 
devices in the past (cannot quite point to the thread), the current 
consensus appears to be that if you use the "label" property (which was 
primed by DSA) then your network device will follow that name, still not 
something the networking stack does for you within the guts of 
register_netdev().

--
Florian

Re: ethernet dt aliases implications in U-Boot and Linux

[Tim Harvey]

On Mon, Aug 8, 2022 at 12:58 PM Sean Anderson  wrote:
>
> Hi Tim,
>
> On 8/8/22 3:18 PM, Tim Harvey wrote:
> > Greetings,
> >
> > I'm trying to understand if there is any implication of 'ethernet'
> > aliases in Linux such as:
> > aliases {
> > ethernet0 = 
> > ethernet1 = 
> > ethernet2 = 
> > ethernet3 = 
> > ethernet4 = 
> > ethernet5 = 
> > ethernet6 = 
> > };
> >
> > I know U-Boot boards that use device-tree will use these aliases to
> > name the devices in U-Boot such that the device with alias 'ethernet0'
> > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > appears that the naming of network devices that are embedded (ie SoC)
> > vs enumerated (ie pci/usb) are always based on device registration
> > order which for static drivers depends on Makefile linking order and
> > has nothing to do with device-tree.
> >
> > Is there currently any way to control network device naming in Linux
> > other than udev?
>
> You can also use systemd-networkd et al. (but that is the same kind of 
> mechanism)
>
> > Does Linux use the ethernet aliases for anything at all?
>
> No :l
>

Sean,

Ok - thanks for the confirmation!

Best Regards,

Tim

Re: ethernet dt aliases implications in U-Boot and Linux

[Michal Suchánek]

On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> Hi Tim,
> 
> On 8/8/22 3:18 PM, Tim Harvey wrote:
> > Greetings,
> > 
> > I'm trying to understand if there is any implication of 'ethernet'
> > aliases in Linux such as:
> > aliases {
> > ethernet0 = 
> > ethernet1 = 
> > ethernet2 = 
> > ethernet3 = 
> > ethernet4 = 
> > ethernet5 = 
> > ethernet6 = 
> > };
> > 
> > I know U-Boot boards that use device-tree will use these aliases to
> > name the devices in U-Boot such that the device with alias 'ethernet0'
> > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > appears that the naming of network devices that are embedded (ie SoC)
> > vs enumerated (ie pci/usb) are always based on device registration
> > order which for static drivers depends on Makefile linking order and
> > has nothing to do with device-tree.
> > 
> > Is there currently any way to control network device naming in Linux
> > other than udev?
> 
> You can also use systemd-networkd et al. (but that is the same kind of 
> mechanism)
> 
> > Does Linux use the ethernet aliases for anything at all?
> 
> No :l

Maybe it's a great opportunity for porting biosdevname to DT based
platforms ;-)

Thanks

Michal

Re: [PATCH] power: pmic: rk8xx: Workaround pmic failure when probed before relocation

[Michal Suchánek]

On Mon, Aug 08, 2022 at 01:26:23PM -0600, Simon Glass wrote:
> Hi Michal,
> 
> On Sat, 6 Aug 2022 at 13:54, Michal Suchánek  wrote:
> >
> > On Sat, Aug 06, 2022 at 12:21:29PM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Fri, 5 Aug 2022 at 14:07, Michal Suchánek  wrote:
> > > >
> > > > On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote:
> > > > > Hi Michal,
> > > > >
> > > > > On Fri, 5 Aug 2022 at 05:32, Michal Suchanek  
> > > > > wrote:
> > > > > >
> > > > > > When the sysreset is added as child of the pmic the pmic is probed
> > > > > > before relocation. That probe fails, and subsequent attempts to 
> > > > > > probe
> > > > > > after reloaction fail as well.
> > > > > >
> > > > > > As a workaround do not bind the sysreset before relocation.
> > > > > >
> > > > > > Signed-off-by: Michal Suchanek 
> > > > > > ---
> > > > > >  drivers/power/pmic/rk8xx.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > > > > > index a239a18674..d12263c4f2 100644
> > > > > > --- a/drivers/power/pmic/rk8xx.c
> > > > > > +++ b/drivers/power/pmic/rk8xx.c
> > > > > > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, uint 
> > > > > > reg, uint8_t *buff, int len)
> > > > > >
> > > > > >  static int rk8xx_bind(struct udevice *dev)
> > > > > >  {
> > > > > > -   if (CONFIG_IS_ENABLED(SYSRESET)) {
> > > > > > +   if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags & 
> > > > > > GD_FLG_RELOC)) {
> > > > > > device_bind_driver(dev, "rk8xx_sysreset",
> > > > > >"rk8xx_sysreset", NULL);
> > > > > > }
> > > > > > --
> > > > > > 2.37.1
> > > > > >
> > > > >
> > > > > I think it is OK to avoid starting a device before relocation, or make
> > > > > that device do something different. I really don't like the binding
> > > > > being optional though...we have the 'u-boot,dm-pre-reloc' for that.
> > > >
> > > > So perhaps the flag should be dropped from rk8xx then.
> > > >
> > > > >
> > > > > But missing from your commit message is exactly what fails?
> > > >
> > > > The pmic is an i2c device, all i2c tranferss fail if initialized
> > > > pre-relocation. I supect it's the i2c bus that fails if initialized
> > > > before reloc - the regulatorss that share the i2c bus also report i2c
> > > > transfer failure.
> > >
> > > OK, I wonder why i2c fails? It works OK on the rockchip devices I'm
> > > familiar with, e.g. chromebooks.
> >
> > It worksss fine here as well - so long as it is not initialized before
> > relocation.
> 
> I wonder if the clock driver is doing something different then, or has
> a limited number of clocks?

Looks like it is not the clocks.

There is something slightly fishy going on there with them:

In the broken case the i2c clock is not initialized before reloc

TICE:  BL31: v2.6(debug):
NOTICE:  BL31: Built : 14:50:40, Jul  1 2022
INFO:GICv3 with legacy support detected.
INFO:ARM GICv3 driver initialized in EL3
INFO:Maximum SPI INTID supported: 287
INFO:plat_rockchip_pmu_init(1624): pd status 3e
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x20
INFO:SPSR = 0x3c9
rk8xx_bind
global flags 0 relocaddr 0
rk8xx_sysreset_bind
rk8xx_bind: 'pmic@1b' - found regulators subnode
rk3399_clk_get_rate: clk clock-controller@ff76 83
clock-controller@ff76 83: clock rate 2400


U-Boot 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 19:53:20 +0200)

U-Boot PLL at ff75: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1, 
vco=1344000 khz, output=672000 khz
i2c@ff3c: Got clock pmu-clock-controller@ff75 9
rockchip_i2c_probe: clk: pmu-clock-controller@ff75 9 rate 0 count 0 flags 0
rockchip_i2c_set_bus_speed: 40
rk3399_i2c_get_pmuclk: clk 9, con 771, div 3
rk3399_pmuclk_get_rate: clk pmu-clock-controller@ff75 9 -> 16900 <<< 
different freqency
pmu-clock-controller@ff75 9: clock rate 16900
rk_i2c_set_clk: clk pmu-clock-controller@ff75 9, i2c rate = 16900, scl 
rate = 40
set i2c clk div = 51, divh = 26, divl = 25
set clk(I2C_CLKDIV: 0x001a0019)
rk8xx_probe
original ID register
i2c_xfer: 2 messages
i2c_xfer: chip=0x1b, len=0x1
rk_i2c_write: chip = 27, reg = 0, r_len = 0, b_len = 1
I2c Send Start bit.
I2C Send Start Bit Timeout
i2c_con: 0x00010009
i2c_clkdiv: 0x001a0019
i2c_mrxaddr: 0x
i2c_mrxraddR: 0x
i2c_mtxcnt: 0x
i2c_mrxcnt: 0x
i2c_ien: 0x0010
i2c_ipd: 0x
i2c_fcnt: 0x
i2c_txdata0: 0x
i2c_txdata1: 0x
i2c_txdata2: 0x
i2c_txdata3: 0x
i2c_txdata4: 0x
i2c_txdata5: 0x
i2c_txdata6: 0x
i2c_txdata7: 0x
i2c_rxdata0: 0x
i2c_rxdata1: 

[PATCH] Restore pcm051_rev3_defconfig config

[Matwey V. Kornilov]

pcm051_rev3_defconfig config (Phytec Wega board) has been dropped in 

64efd11d ("arm: Remove pcm051 board")

due to expired migration deadlines. Here, pcm051_rev3_defconfig support is
reintroduced.

Signed-off-by: Matwey V. Kornilov 
---
 arch/arm/dts/am335x-wega-rdk-u-boot.dtsi | 12 
 board/phytec/phycore_am335x_r2/board.c   | 26 +
 configs/pcm051_rev3_defconfig| 70 
 scripts/config_whitelist.txt |  1 +
 4 files changed, 109 insertions(+)
 create mode 100644 configs/pcm051_rev3_defconfig

diff --git a/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi 
b/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
index 28fd62e231..b3f21e7f52 100644
--- a/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
+++ b/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
@@ -16,6 +16,18 @@
 
ocp {
u-boot,dm-pre-reloc;
+
+   l4_wkup@44c0 {
+   u-boot,dm-pre-reloc;
+
+   segment@20 {
+   u-boot,dm-pre-reloc;
+
+   target-module@9000 {
+   u-boot,dm-pre-reloc;
+   };
+   };
+   };
};
 };
 
diff --git a/board/phytec/phycore_am335x_r2/board.c 
b/board/phytec/phycore_am335x_r2/board.c
index 5ca9415204..d600cc85c4 100644
--- a/board/phytec/phycore_am335x_r2/board.c
+++ b/board/phytec/phycore_am335x_r2/board.c
@@ -31,7 +31,11 @@ DECLARE_GLOBAL_DATA_PTR;
 static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
 
 /* DDR RAM defines */
+#if defined(CONFIG_REV13)
+#define DDR_CLK_MHZ303 /* DDR_DPLL_MULT value */
+#else
 #define DDR_CLK_MHZ400 /* DDR_DPLL_MULT value */
+#endif // CONFIG_REV13
 
 #define OSC(V_OSCK / 100)
 const struct dpll_params dpll_ddr = {
@@ -65,6 +69,7 @@ enum {
PHYCORE_R2_MT41K128M16JT_256MB,
PHYCORE_R2_MT41K256M16TW107IT_512MB,
PHYCORE_R2_MT41K512M16HA125IT_1024MB,
+   PHYCORE_R13_MT41K256M16HA125E_256MB,
 };
 
 struct am335x_sdram_timings {
@@ -127,10 +132,30 @@ static struct am335x_sdram_timings physom_timings[] = {
.datawrsratio0 = 0x82,
},
},
+   [PHYCORE_R13_MT41K256M16HA125E_256MB] = {
+   .ddr3_emif_reg_data = {
+   .sdram_config = MT41K256M16HA125E_EMIF_SDCFG,
+   .ref_ctrl = MT41K256M16HA125E_EMIF_SDREF,
+   .sdram_tim1 = MT41K256M16HA125E_EMIF_TIM1,
+   .sdram_tim2 = MT41K256M16HA125E_EMIF_TIM2,
+   .sdram_tim3 = MT41K256M16HA125E_EMIF_TIM3,
+   .zq_config = MT41K256M16HA125E_ZQ_CFG,
+   .emif_ddr_phy_ctlr_1 = 
MT41K256M16HA125E_EMIF_READ_LATENCY | PHY_EN_DYN_PWRDN,
+   },
+   .ddr3_data = {
+   .datardsratio0 = MT41K256M16HA125E_RD_DQS,
+   .datawdsratio0 = MT41K256M16HA125E_WR_DQS,
+   .datafwsratio0 = MT41K256M16HA125E_PHY_FIFO_WE,
+   .datawrsratio0 = MT41K256M16HA125E_PHY_WR_DATA,
+   },
+   },
 };
 
 void sdram_init(void)
 {
+#if defined(CONFIG_REV13)
+   int ram_type_index = PHYCORE_R13_MT41K256M16HA125E_256MB;
+#else
/* Configure memory to maximum supported size for detection */
int ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
 
@@ -157,6 +182,7 @@ void sdram_init(void)
ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
break;
}
+#endif
config_ddr(DDR_CLK_MHZ, ,
   _timings[ram_type_index].ddr3_data,
   _cmd_ctrl_data,
diff --git a/configs/pcm051_rev3_defconfig b/configs/pcm051_rev3_defconfig
new file mode 100644
index 00..b4d128b1d0
--- /dev/null
+++ b/configs/pcm051_rev3_defconfig
@@ -0,0 +1,70 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="am335x-wega-rdk"
+CONFIG_AM33XX=y
+CONFIG_TARGET_PHYCORE_AM335X_R2=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL=y
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="REV13"
+CONFIG_DEFAULT_FDT_FILE="am335x-wega-rdk.dtb"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_ARCH_MISC_INIT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_FS_EXT4=y
+CONFIG_SPL_I2C=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_POWER=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_SPL=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_EEPROM=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 

Re: [SPAM] rk3399 TPL memory setup code triggers clock frequency limit assertion

[Xavier Drudis Ferran]

El Mon, Aug 08, 2022 at 11:22:49PM +0530, Jagan Teki deia:
> 
> If I remember correctly when I work with YouMin on LPDDR4 the initial
> code to start to check with was 50MHz (It was not working at that time
> with 48MHz). Not sure what to make other changes to fix that to try on
> 48MHz.
> 

Not sure I understand.

Do you mean when you and YouMin worked in this (thanks for your work) 
you had mesured that the code gave 50MHz ? Maybe. It seems out of spec, so it
doesn't have to give 48MHz, I guess it can give whatever. 48MHz is the concluion
of a theory for which we haven't satisfied the hypothesis.

Or do you mean the code for this clock was different when you worked initially,
and that code gave 50MHz theoretically ? I haven't looked at the git log.

> Better resend the patch again and add YouMin and others to see for comments.
> 

I don't have much time right now to pull, see if it applies still and
test again.  Michal just tried, not sure how clean it might have been
for him, or what base he used, so anyone feel free to resend if you
think it's useful or know better who to put in cc. Who would "others" be ?
If I got my Cc: wrong the first time I fear I'll fail again. Michal
just sent a tested-by to my orignal patch[1]. Should a resend fare
better ? Or how many resends?  I may resend this one line patch when I
have time if nobody has resent yet or merged the original.

YouMin helped me confirm and said something unconclusive in private,
not opposing to change it.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut/

Re: ethernet dt aliases implications in U-Boot and Linux

[Sean Anderson]

Hi Tim,

On 8/8/22 3:18 PM, Tim Harvey wrote:
> Greetings,
> 
> I'm trying to understand if there is any implication of 'ethernet'
> aliases in Linux such as:
> aliases {
> ethernet0 = 
> ethernet1 = 
> ethernet2 = 
> ethernet3 = 
> ethernet4 = 
> ethernet5 = 
> ethernet6 = 
> };
> 
> I know U-Boot boards that use device-tree will use these aliases to
> name the devices in U-Boot such that the device with alias 'ethernet0'
> becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> appears that the naming of network devices that are embedded (ie SoC)
> vs enumerated (ie pci/usb) are always based on device registration
> order which for static drivers depends on Makefile linking order and
> has nothing to do with device-tree.
> 
> Is there currently any way to control network device naming in Linux
> other than udev?

You can also use systemd-networkd et al. (but that is the same kind of 
mechanism)

> Does Linux use the ethernet aliases for anything at all?

No :l

--Sean

[PATCH 1/1] git-mailrc: remove invalid entry 'efi'

[Heinrich Schuchardt]

Remove alias 'efi' with invalid data.

Signed-off-by: Heinrich Schuchardt 
---
 doc/git-mailrc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index b00c278190..96623c3b4e 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -111,7 +111,6 @@ alias x86uboot, sjg, bmeng
 alias dm uboot, sjg
 alias cfiuboot, stroese
 alias dfuuboot, lukma
-alias efiuboot, agraf
 alias ethuboot, jhersh
 alias kerneldoc  uboot, marex
 alias fdtuboot, sjg
-- 
2.36.1

Re: [PATCH 1/2] doc: Drop a reference to travis

[Heinrich Schuchardt]

On 8/7/22 15:24, Simon Glass wrote:

This was widely used by U-Boot for a long time, but is not used anymore,
with Gitlab and Azure taking over.

Drop the text.

Signed-off-by: Simon Glass 
---

  doc/develop/codingstyle.rst | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index a6bc37bbb44..3aa10dd99f0 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -248,5 +248,5 @@ will be much faster (10-100x or more) if they can directly 
call run_command()
  and ut_check_console_line() instead of using Python to send commands over a
  pipe to U-Boot.

-Tests run all supported CI systems (gitlab, travis, azure) using scripts in the
-root of the U-Boot tree.
+Tests run all supported CI systems (gitlab, azure) using scripts in the root of


%s/gitlab/GitLab/
%s/azure/Azure/

Proper names should be capitalized. I will adjust this when merging.

Reviewed-by: Heinrich Schuchardt 


+the U-Boot tree.

Re: [PATCH 2/2] patman: Add documentation to doc/

[Ralph Siemsen]

Hi Simon,

On Sun, Aug 7, 2022 at 9:25 AM Simon Glass  wrote:
>
> Link to patman's documentation from the doc/ directory so that it appears
> in the 'make htmldocs' output.

Presumably this will show up on readthedocs? Seems like a nice addition.

The rename of README to README.rst would break "patman -H" feature.
Perhaps sed s/README/README.rst/ -i toosl/patman/main.py ?

Ralph

Re: [PATCH 03/21] arm: Remove snapper9260 board

[Simon Glass]

On Tue, 2 Aug 2022 at 05:34, Tom Rini  wrote:
>
> This board is behind on several mandatory DM migrations and is missing
> OF_CONTROL support that makes other conversions impossible. Remove it.
>
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-at91/Kconfig|  10 --
>  board/bluewater/snapper9260/Kconfig   |  12 --
>  board/bluewater/snapper9260/MAINTAINERS   |   7 -
>  board/bluewater/snapper9260/Makefile  |   9 --
>  board/bluewater/snapper9260/snapper9260.c | 154 --
>  configs/snapper9260_defconfig |  58 
>  configs/snapper9g20_defconfig |  57 
>  include/configs/snapper9260.h |  80 ---
>  8 files changed, 387 deletions(-)
>  delete mode 100644 board/bluewater/snapper9260/Kconfig
>  delete mode 100644 board/bluewater/snapper9260/MAINTAINERS
>  delete mode 100644 board/bluewater/snapper9260/Makefile
>  delete mode 100644 board/bluewater/snapper9260/snapper9260.c
>  delete mode 100644 configs/snapper9260_defconfig
>  delete mode 100644 configs/snapper9g20_defconfig
>  delete mode 100644 include/configs/snapper9260.h
>

Reviewed-by: Simon Glass 

Re: [PATCH] disk: part: remove dependency to ubifs for spl

[Simon Glass]

Hi Stefan,

On Mon, 8 Aug 2022 at 08:45, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> The spl doesn't support ubifs and thereby doesn't provide the
> ubifs_is_mounted function. Remove the dependency to ubifs for the spl.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
>  disk/part.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index 79955c7fb0..de1b917e84 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -479,7 +479,7 @@ int blk_get_device_part_str(const char *ifname, const 
> char *dev_part_str,
> }
>  #endif
>
> -#ifdef CONFIG_CMD_UBIFS
> +#if IS_ENABLED(CONFIG_CMD_UBIFS) && !IS_ENABLED(CONFIG_SPL_BUILD)
> /*
>  * Special-case ubi, ubi goes through a mtd, rather than through
>  * a regular block device.
> --
> 2.30.2
>

A CMD config should not be used outside cmd/ - can we add a proper
CONFIG_UBIFS ?

Regards,
Simon

Re: [PATCH] arm64: explicitly disable pointer authentication instructions

[Simon Glass]

On Mon, 8 Aug 2022 at 08:12, Rasmus Villemoes
 wrote:
>
> The Yocto project builds their aarch64 cross-compiler with the
> configure knob --enable-standard-branch-protection, which means that
> their gcc behaves as if -mbranch-protection=standard is passed; the
> default (lacking that configure knob) is -mbranch-protection=none.
>
> This means that when building U-Boot using the Yocto toolchain, most
> functions end up containing paciasp/autiasp/bti instructions. However,
> since U-Boot is not an ordinary userspace application, there's no OS
> kernel which has set up the required authentication keys, so these
> instructions do nothing at all (even on arm64 hardware that does have
> the pointer authentication capability). They do however make the image
> larger.
>
> It is theoretically possible for U-Boot to make use of the pointer
> authentication protection - cf. the linux kernel's
> CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's
> hard to see just what threat model it would protect against in a
> bootloader context. Regardless, we certainly have none of the required
> infrastructure now, so explictly pass -mbranch-protection=none to
> ensure those useless instructions do not get emitted.
>
> For a toolchain not configured with
> --enable-standard-branch-protection, this changes nothing. For the
> Yocto toolchain, this reduces the size of both SPL and U-Boot proper
> by about 3% for my imx8mp target.
>
> If you don't have a Yocto toolchain, the effect can easily be
> reproduced by applying this patch and changing =none to =standard.
>
> Signed-off-by: Rasmus Villemoes 
> ---
> Not sure who to cc, there's no overall arm64 maintainer listed in
> MAINTAINERS, but Tom is listed as generally handling arch/arm/.
>
>  arch/arm/cpu/armv8/config.mk | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH 10/31] serial: mtk: add support for using dynamic baud clock souce

[Simon Glass]

Hi Weijie,

On Sun, 7 Aug 2022 at 20:36, Weijie Gao  wrote:
>
> On Thu, 2022-08-04 at 07:56 -0600, Simon Glass wrote:
> > Hi Weijie,
> >
> > On Wed, 3 Aug 2022 at 21:36, Weijie Gao 
> > wrote:
> > >
> > > The baud clock on some platform may change due to assigned-clock-
> > > parent
> > > set in DT. In current flow the baud clock is only retrieved during
> > > probe
> > > stage. If the parent of the source clock changes after probe stage,
> > > the
> > > setbrg will set wrong baudrate.
> > >
> > > To get the right clock rate, this patch records the baud clk struct
> > > to the
> > > driver's priv, and changes the driver's flow to get the clock rate
> > > before
> > > calling _mtk_serial_setbrg().
> > >
> > > Signed-off-by: Weijie Gao 
> > > ---
> > >  drivers/serial/serial_mtk.c | 72 -
> > > 
> > >  1 file changed, 39 insertions(+), 33 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > please see below
> >
> > >
> > > diff --git a/drivers/serial/serial_mtk.c
> > > b/drivers/serial/serial_mtk.c
> > > index a84f39b3fa..99cf62b8d9 100644
> > > --- a/drivers/serial/serial_mtk.c
> > > +++ b/drivers/serial/serial_mtk.c
> > > @@ -10,6 +10,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -72,25 +73,27 @@ struct mtk_serial_regs {
> > >
> > >  struct mtk_serial_priv {
> >
> > please add a full comment for this struct
>
> OK.
>
> >
> > > struct mtk_serial_regs __iomem *regs;
> > > -   u32 clock;
> > > +   struct clk clk;
> > > +   u32 fixed_clk_rate;
> > > bool force_highspeed;
> > >  };
> > >
> > > -static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int
> > > baud)
> > > +static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int
> > > baud,
> > > +  u32 clk_rate)
> >
> > Why u32? Can you use uint? Generally it is better for parameters to
> > use natural types unless there is a good reason.
>
> In fact u32 is identical to uint.
>
> : typedef __u32 u32;
> : typedef unsigned int __u32;
>
> : typedef unsigned int uint;

It's not about the eventual type...if u32 is the same as uint, why not
just use uint? It is simpler and does the right thing on 64-bit, where
u32 is different. The clock interface uses long.  In some cases the
compiler must mask the values so it adds to code size.

Regards,
SImon

Re: [PATCH 02/31] arm: mediatek: add support for MediaTek MT7981 SoC

[Simon Glass]

Hi Weijie,

On Sun, 7 Aug 2022 at 20:17, Weijie Gao  wrote:
>
> On Thu, 2022-08-04 at 07:57 -0600, Simon Glass wrote:
> > Hi Weijie,
> >
> > On Wed, 3 Aug 2022 at 21:35, Weijie Gao 
> > wrote:
> > >
> > > This patch adds basic support for MediaTek MT7981 SoC.
> > > This include the file that will initialize the SoC after boot and
> > > its
> > > device tree.
> > >
> > > Signed-off-by: Weijie Gao 
> > > ---
> > >  arch/arm/dts/mt7981.dtsi  | 288
> > > ++
> > >  arch/arm/mach-mediatek/Kconfig|  12 +-
> > >  arch/arm/mach-mediatek/Makefile   |   1 +
> > >  arch/arm/mach-mediatek/mt7981/Makefile|   4 +
> > >  arch/arm/mach-mediatek/mt7981/init.c  |  52 
> > >  arch/arm/mach-mediatek/mt7981/lowlevel_init.S |  30 ++
> > >  6 files changed, 386 insertions(+), 1 deletion(-)
> > >  create mode 100644 arch/arm/dts/mt7981.dtsi
> > >  create mode 100644 arch/arm/mach-mediatek/mt7981/Makefile
> > >  create mode 100644 arch/arm/mach-mediatek/mt7981/init.c
> > >  create mode 100644 arch/arm/mach-mediatek/mt7981/lowlevel_init.S
> > >
> >
> >
> > [..]
> >
> > > diff --git a/arch/arm/mach-mediatek/mt7981/init.c
> > >  b/arch/arm/mach-mediatek/mt7981/init.c
> > > new file mode 100644
> > > index 00..f503bb804b
> > > --- /dev/null
> > > +++ b/arch/arm/mach-mediatek/mt7981/init.c
> > > @@ -0,0 +1,52 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2022 MediaTek Inc.
> > > + * Author: Sam Shih 
> > > + */
> > > +
> > > +#include 
> >
> > Do you need that?
>
> This was used during testing, and should be remove now.
>
> >
> > > +#include 
> > > +#include 
> >
> > Move up one
>
> ok.
>
> >
> > > +#include 
> > > +#include 
> > > +
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > +int print_cpuinfo(void)
> >
> > Can you use the CPU uclass and DISPLAY_CPUINFO instead/
>
> Basically there's nothing to do for print_cpuinfo other than printing a
> fixed CPU model string. Not sure if it's worth using a CPU uclass.
>
> Besides, Using a cpu uclass involves modifying other chips, and some
> of them cann't be tested by me.

Something to consider for the future as it is nice to list the CPUs
and their status. You can enable CONFIG_CPU for one Soc and not
another.

Regards,
Simon

Re: [PATCH] power: pmic: rk8xx: Workaround pmic failure when probed before relocation

[Simon Glass]

Hi Michal,

On Sat, 6 Aug 2022 at 13:54, Michal Suchánek  wrote:
>
> On Sat, Aug 06, 2022 at 12:21:29PM -0600, Simon Glass wrote:
> > Hi Michal,
> >
> > On Fri, 5 Aug 2022 at 14:07, Michal Suchánek  wrote:
> > >
> > > On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote:
> > > > Hi Michal,
> > > >
> > > > On Fri, 5 Aug 2022 at 05:32, Michal Suchanek  wrote:
> > > > >
> > > > > When the sysreset is added as child of the pmic the pmic is probed
> > > > > before relocation. That probe fails, and subsequent attempts to probe
> > > > > after reloaction fail as well.
> > > > >
> > > > > As a workaround do not bind the sysreset before relocation.
> > > > >
> > > > > Signed-off-by: Michal Suchanek 
> > > > > ---
> > > > >  drivers/power/pmic/rk8xx.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > > > > index a239a18674..d12263c4f2 100644
> > > > > --- a/drivers/power/pmic/rk8xx.c
> > > > > +++ b/drivers/power/pmic/rk8xx.c
> > > > > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, uint 
> > > > > reg, uint8_t *buff, int len)
> > > > >
> > > > >  static int rk8xx_bind(struct udevice *dev)
> > > > >  {
> > > > > -   if (CONFIG_IS_ENABLED(SYSRESET)) {
> > > > > +   if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags & 
> > > > > GD_FLG_RELOC)) {
> > > > > device_bind_driver(dev, "rk8xx_sysreset",
> > > > >"rk8xx_sysreset", NULL);
> > > > > }
> > > > > --
> > > > > 2.37.1
> > > > >
> > > >
> > > > I think it is OK to avoid starting a device before relocation, or make
> > > > that device do something different. I really don't like the binding
> > > > being optional though...we have the 'u-boot,dm-pre-reloc' for that.
> > >
> > > So perhaps the flag should be dropped from rk8xx then.
> > >
> > > >
> > > > But missing from your commit message is exactly what fails?
> > >
> > > The pmic is an i2c device, all i2c tranferss fail if initialized
> > > pre-relocation. I supect it's the i2c bus that fails if initialized
> > > before reloc - the regulatorss that share the i2c bus also report i2c
> > > transfer failure.
> >
> > OK, I wonder why i2c fails? It works OK on the rockchip devices I'm
> > familiar with, e.g. chromebooks.
>
> It worksss fine here as well - so long as it is not initialized before
> relocation.

I wonder if the clock driver is doing something different then, or has
a limited number of clocks?

Regards,
Simon

Re: [PATCH 00/21] Finish migration to DM_ETH

[Tom Rini]

On Tue, Aug 02, 2022 at 07:51:18AM -0400, Tom Rini wrote:
> On Tue, Aug 02, 2022 at 07:33:26AM -0400, Tom Rini wrote:
> 
> > As I've noted before, with v2022.07 being released, we have gone 2 years
> > past the DM_ETH migration deadline. What this series does is a few
> > things:
> > - Remove some boards that either lack DM migration at all, or lack
> >   OF_CONTROL. DM migration has had an explicit deadline, and OF_CONTROL
> >   an implict one.
> > - Remove some un-migrated ethernet drivers. I had reached out in private
> >   to some people about this and they had hoped to have done the
> >   conversion by now. Unfortunately, here we now are.
> > - Perform some minor forceful migrations on boards. These boards use
> >   OF_CONTROL and drivers which use DM_ETH, so I am hopeful that just
> >   removing or guarding the code here is fine and works.
> > - Disable networkgin on some other boards. Unlike boards in the above
> >   case, it looks like the board code itself needs some updates, as was
> >   done on the platforms that have already been migrated.
> > - Finally, select DM_ETH for all NETDEVICES and update dependencies.
> > 
> > This series depends on
> > https://patchwork.ozlabs.org/project/uboot/patch/8ae444f17dc5db69a1da809875a16462049857c7.1652363162.git.christophe.le...@csgroup.eu/
> > being applied and in practical terms depennds on my current outstanding
> > Kconfig migrations as well.
> 
> Adding back the CC list git send-email dropped...

Just following up here as I got some acks/feedback on the platforms that
will be loosing functionality, but not as much as I hoped. I will be
applying this series soon.

-- 
Tom


signature.asc
Description: PGP signature

ethernet dt aliases implications in U-Boot and Linux

[Tim Harvey]

Greetings,

I'm trying to understand if there is any implication of 'ethernet'
aliases in Linux such as:
aliases {
ethernet0 = 
ethernet1 = 
ethernet2 = 
ethernet3 = 
ethernet4 = 
ethernet5 = 
ethernet6 = 
};

I know U-Boot boards that use device-tree will use these aliases to
name the devices in U-Boot such that the device with alias 'ethernet0'
becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
appears that the naming of network devices that are embedded (ie SoC)
vs enumerated (ie pci/usb) are always based on device registration
order which for static drivers depends on Makefile linking order and
has nothing to do with device-tree.

Is there currently any way to control network device naming in Linux
other than udev?

Does Linux use the ethernet aliases for anything at all?

Best Regards,

Tim

Re: [PATCH 2/2] net: dwc_eth_qos: Add eqos_get_enetaddr callback for stm32

[Tom Rini]

On Tue, Aug 02, 2022 at 10:55:26AM +0200, Patrice Chotard wrote:

> Add .eqos_get_enetaddr callback defined as eqos_null_ops() to avoid
> illegal access.
> 
> Fixes: a624251461bf ("net: dwc_eth_qos: introduce eqos hook 
> eqos_get_enetaddr")
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] net: dwc_eth_qos: Add eqos_get_enetaddr callback for tegra186

[Tom Rini]

On Tue, Aug 02, 2022 at 10:55:25AM +0200, Patrice Chotard wrote:

> Add .eqos_get_enetaddr callback defined as eqos_null_ops() to avoid
> illegal access.
> 
> Fixes: a624251461bf ("net: dwc_eth_qos: introduce eqos hook 
> eqos_get_enetaddr")
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins

[Tom Rini]

On Wed, Jul 13, 2022 at 10:59:45AM +0900, Kunihiko Hayashi wrote:

> UniPhier LD20, PXs2 and PXs3 boards have ethernet phy that has RX/TX delays
> of RGMII interface using pull-ups on the RXDLY and TXDLY pins.
> 
> So should set the phy-mode to "rgmii-id" to show that RX/TX delays are
> enabled.
> 
> Signed-off-by: Kunihiko Hayashi 
> Reviewed-by: Ramon  Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] net: ave: Add capability of rgmii-id mode

[Tom Rini]

On Wed, Jul 13, 2022 at 10:59:44AM +0900, Kunihiko Hayashi wrote:

> This allows you to specify the type of rgmii-id that will enable phy
> internal delay in ethernet phy-mode.
> 
> This adds all RGMII cases to all of get_pinmode() except LD11, because LD11
> SoC doesn't support RGMII due to the constraint of the hardware. When RGMII
> phy mode is specified in the devicetree for LD11, the driver will abort
> with an error.
> 
> Signed-off-by: Kunihiko Hayashi 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] net: phy: possible NULL dereference in fixed_phy_create()

[Tom Rini]

On Mon, Jul 11, 2022 at 07:40:13PM +0200, Heinrich Schuchardt wrote:

> We check if phydev is NULL. Only but if it is non-NULL we set one
> component of phydev. But even if it is NULL we set another. We should not
> dereference NULL in either case.
> 
> Fixes: e24b58f5ed4f ("net: phy: don't require PHY interface mode during PHY 
> creation")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] net: dwc_eth_qos: cosmetic: reorder include files

[Tom Rini]

On Thu, Jun 30, 2022 at 11:09:41AM +0200, Patrick Delaunay wrote:

> Reorder include files in the U-Boot expected order.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: phy: Remove inline definitions from convinience functions

[Tom Rini]

On Sun, Jun 05, 2022 at 03:44:15AM +0300, Ramon Fried wrote:

> The convinience functions are not that small and they caused
> bloated text segments because of their usage.
> There was no need to inline them in the first place, as
> they're not part of a fastpath.
> 
> Signed-off-by: Ramon Fried 
> Reviewed-by: Michael Trimarchi 
> Reviewed-by: Marek Behún 
> Reviewed-by: Vladimir Oltean 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: ftgmac100: use bus name in mdio error messages

[Tom Rini]

On Tue, May 17, 2022 at 03:16:39PM -0700, Zev Weiss wrote:

> Previously we'd been using a device name retrieved via
> ftgmac100_data->phydev, but the mdio read/write functions may be
> called before that member is initialized in ftgmac100_phy_init(),
> leading to a NULL pointer dereference while printing the error message
> issued if the mdio access fails.  We can instead use bus->name, which
> is already available at that point.
> 
> Signed-off-by: Zev Weiss 
> Fixes: 538e75d3fc54 ("net: ftgmac100: add MDIO bus and phylib support")
> Reviewed-by: Cédric Le Goater 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1] net: nuvoton : Add NPCM7xx EMAC driver

[Tom Rini]

On Tue, May 17, 2022 at 04:28:11PM +0800, Jim Liu wrote:

> NPCM750 provides identical ethernet MAC controllers for WAN/LAN applications.
> 
> Signed-off-by: Jim Liu 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: mpc8xx_fec: Migrate to DM_ETH

[Tom Rini]

On Thu, May 12, 2022 at 03:48:51PM +0200, Christophe Leroy wrote:

> Migrate mpc8xx_fec driver to DM_ETH.
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: dwc_eth_qos: lift parsing of max-speed DT property to common code

[Tom Rini]

On Wed, May 11, 2022 at 04:58:41PM +0200, Rasmus Villemoes wrote:

> I have an iMX8MP with a ti,dp83867 phy in front of the eqos
> interface. The phy is Gbit capable - however, the C and D differential
> pairs are not physically routed to the RJ45 connector. So I need to
> prevent the phy from advertising 1000Mbps.
> 
> The necessary code is almost already there in the form of a
> phy_set_supported() call in eqos_start(), but the max-speed DT
> property is currently only parsed in
> eqos_probe_resources_stm32(). Lift that parsing to eqos_probe().
> 
> Signed-off-by: Rasmus Villemoes 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: dwc_eth_qos: fix double resource leak in eqos_remove()

[Tom Rini]

On Wed, May 11, 2022 at 04:12:50PM +0200, Rasmus Villemoes wrote:

> Not only does eqos_remove() fail to free the buffers that have been
> allocated by eqos_probe_resources_core(), it repeats those allocations
> and thus drops twice as much memory on the floor.
> 
> Signed-off-by: Rasmus Villemoes 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: dm9000: Correctly handle empty FIFO

[Tom Rini]

On Mon, Apr 25, 2022 at 08:28:05PM +0200, Marek Vasut wrote:

> Assign packet pointer only in case the MAC reports anything in the FIFO.
> In case the MAC indicates empty FIFO, return 0 to pass that information
> to the network stack.
> 
> Signed-off-by: Marek Vasut 
> Cc: Joe Hershberger 
> Cc: Ramon Fried 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] net: phy: marvell: Add support for 88E1240 PHY

[Tom Rini]

On Thu, Mar 31, 2022 at 11:43:07AM +0200, Stefan Roese wrote:

> This patch adds basic support for the Marvell 88E1240 PHY.
> 
> This will be used by the upcoming ethernet support addition for the
> Marvell MIPS Octeon EBB7304 platform.
> 
> Signed-off-by: Stefan Roese 
> Cc: Ramon Fried 
> Cc: Joe Hershberger 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> Reviewed-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] net: phy: marvell: Support reg config via "marvell, reg-init" DT property

[Tom Rini]

On Thu, Mar 31, 2022 at 11:43:06AM +0200, Stefan Roese wrote:

> This patch adds support for the "marvell,reg-init" DT property, which
> is used to describe board specific Marvell PHY register configurations
> in the board dts file. This DT property is supported in the Linux Kernel
> since a longer time. Adding it to U-Boot now, enables the boards which
> describe the register settings in their DT files here as well.
> 
> I've included calling this marvell_of_reg_init() to all foo_config()
> functions in this patch as well. If CONFIG_DM_ETH is not set, there is
> no ofnode, or no "marvell,reg-init" property, the PHY initialization is
> unchanged.
> 
> The function marvell_of_reg_init() is a port of the Linux version.
> Please note that I explicitly did not add error checking and handling
> to the U-Boot version, as this is basically not done for phy_read/write
> in this Marvell PHY code.
> 
> This will be used by the upcoming ethernet support on the MIPS
> Octeon EBB 7304 board.
> 
> Signed-off-by: Stefan Roese 
> Cc: Ramon Fried 
> Cc: Joe Hershberger 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> Cc: Marek Behún 
> Reviewed-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: bootp: Make root path (option 17) length configurable

[Tom Rini]

On Fri, Jan 28, 2022 at 09:40:32AM +0100, Andre Kalb wrote:

> to adjust the root path length.
> Eg to 256 from Linux Kernel
> 
> Signed-off-by: Andre Kalb 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] net: dwc_eth_qos: restore support of not cache-aligned descriptor

[Tom Rini]

On Thu, Jun 30, 2022 at 11:09:40AM +0200, Patrick Delaunay wrote:

> Solve an issue with AXI_WIDTH_32 on a the 64 bytes cache line platform;
> in this case the requested descriptor padding length should be 12 but the
> associated parameter EQOS_DMA_CH0_CONTROL.DSL is limited to 3bits = 7.
> 
> As the DMA descriptor can't be correctly aligned with the cache line,
> the maintenance of each descriptor can't be guaranteed by a simple cache
> line operation: flush or invalid.
> 
> To avoid all the maintenance issues, these descriptors need to be allocated
> in a NOT CACHEABLE memory by noncached_alloc() when
> CONFIG_SYS_NONCACHED_MEMORY is enable.
> 
> This patch doesn't change the current behavior when the descriptors
> can be cache-aligned with the field "Descriptor Skip Length" of
> the DMA channel control register, when eqos->desc_pad = true.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Ramon Fried 

Please rebase this on top of current master, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] net: dwc_eth_qos: set proper DT node for phy device

[Tom Rini]

On Thu, May 12, 2022 at 09:33:09AM +0200, Rasmus Villemoes wrote:

> Similar to what was done for the FEC driver in commit
> 89b5bd54c1a4 (net: fec: Allow the PHY node to be retrieved), make sure
> the PHY is associated with the right device tree node, so that phy
> specific DT properties is accessible by the phy driver.
> 
> This is required on a custom iMX8MP board with a ti,dp83867 phy
> sitting in front of the eqos interface.
> 
> Signed-off-by: Rasmus Villemoes 
> Reviewed-by: Ramon Fried 
> ---
>  drivers/net/dwc_eth_qos.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 27b3f98e0e..af35960b42 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -1078,9 +1078,11 @@ static int eqos_start(struct udevice *dev)
>* don't need to reconnect/reconfigure again
>*/
>   if (!eqos->phy) {
> + ofnode phy_node = ofnode_null();
>   int addr = -1;
> +
>  #ifdef CONFIG_DM_ETH_PHY
> - addr = eth_phy_get_addr(dev);
> + addr = eth_phy_get_node_and_addr(dev, _node);
>  #endif
>   eqos->phy = phy_connect(eqos->mii, addr, dev,
>   eqos->config->interface(dev));
> @@ -1088,6 +1090,8 @@ static int eqos_start(struct udevice *dev)
>   pr_err("phy_connect() failed");
>   goto err_stop_resets;
>   }
> + if (ofnode_valid(phy_node))
> + eqos->phy->node = phy_node;
>  
>   if (eqos->max_speed) {
>   ret = phy_set_supported(eqos->phy, eqos->max_speed);

I'm deferring 2/3 and now for 3/3, given a6acf95508e2 ("net: eqos: add
function to get phy node and address") (which yes, sigh, came after your
series but has been applied already, sorry) I don't see the obvious way
to migrate the changes in without testing. If needed still, can you
please rebase and resend? Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] net: dwc_eth_qos: remove use of DWC_NET_PHYADDR

[Tom Rini]

On Thu, May 12, 2022 at 09:33:07AM +0200, Rasmus Villemoes wrote:

> Only two boards in the tree set the macro DWC_NET_PHYADDR. Both have
> CONFIG_DM_ETH_PHY=y, so should set the phy address in DT if necessary.
> 
> The imx8mp_evk does set the correct address in device tree.
> 
> The other board seems to be a copy-paste-adapt from an old
> version of the imx8mp_evk config header, given the "#ifdef
> CONFIG_DWC_ETH_QOS" block that has been removed from imx8mp_evk header
> in commit 127fb454955. Its device tree doesn't even enable (i.e., set
> 'status = "okay"') the  node. But the other ethernet device,
> , does get enabled, and does have a phy sitting at address 4 (and
> it also has a corresponding legacy #define CONFIG_FEC_MXC_PHYADDR
> 4). So I believe it should be completely safe to remove it from there
> as well.
> 
> Signed-off-by: Rasmus Villemoes 
> Reviewed-by: Ramon Fried 

As this part of the series is dead code removal, I've made it apply to
top of tree and applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 1/4] net: NC-SI setup and handling

[Ramon Fried]

On Mon, Aug 8, 2022 at 3:16 PM Joel Stanley  wrote:
>
> From: Samuel Mendoza-Jonas 
>
> Add the handling of NC-SI ethernet frames, and add a check at the start
> of net_loop() to configure NC-SI before starting other network commands.
>
> Signed-off-by: Samuel Mendoza-Jonas 
> Signed-off-by: Joel Stanley 
> ---
> v4: split out cmd addition into a separate patch
> v3:
>  - Fix compilation. There were no configs that enabled the NCSI phy code
>so it had bitrotted
>  - Use NCSI_PHY instead of CMD_NCSI so NCSI can work without the command
>  - Add phy_interface_is_ncsi() helper, thanks Cédric for this suggestion
>  - Only create NCSI phy device when driver is configured for it
>
>  include/net.h  |  2 +-
>  include/phy.h  |  2 ++
>  drivers/net/phy/ncsi.c |  1 +
>  drivers/net/phy/phy.c  |  9 -
>  net/net.c  | 26 +-
>  5 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/include/net.h b/include/net.h
> index e3889a0bc85e..0681b8246323 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -558,7 +558,7 @@ extern int  net_restart_wrap;   /* Tried all 
> network devices */
>
>  enum proto_t {
> BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
> -   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP
> +   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI
>  };
>
>  extern charnet_boot_file_name[1024];/* Boot File name */
> diff --git a/include/phy.h b/include/phy.h
> index b32959571069..1e0f8856f629 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -583,6 +583,8 @@ static inline bool phy_interface_is_sgmii(struct 
> phy_device *phydev)
> phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
>  }
>
> +bool phy_interface_is_ncsi(void);
> +
>  /* PHY UIDs for various PHYs that are referenced in external code */
>  #define PHY_UID_CS4340 0x13e51002
>  #define PHY_UID_CS4223 0x03e57003
> diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
> index bf1e832be9f1..bb7ecebed382 100644
> --- a/drivers/net/phy/ncsi.c
> +++ b/drivers/net/phy/ncsi.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 1121b99abff5..d04538838852 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1026,7 +1026,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
> addr,
>  #endif
>
>  #ifdef CONFIG_PHY_NCSI
> -   if (!phydev)
> +   if (!phydev && interface == PHY_INTERFACE_MODE_NCSI)
> phydev = phy_device_create(bus, 0, PHY_NCSI_ID, false);
>  #endif
>
> @@ -1101,3 +1101,10 @@ int phy_modify(struct phy_device *phydev, int devad, 
> int regnum, u16 mask,
>
> return phy_write(phydev, devad, regnum, (ret & ~mask) | set);
>  }
> +
> +bool phy_interface_is_ncsi(void)
> +{
> +   struct eth_pdata *pdata = dev_get_plat(eth_get_dev());
> +
> +   return pdata->phy_interface == PHY_INTERFACE_MODE_NCSI;
> +}
> diff --git a/net/net.c b/net/net.c
> index 81905f631592..f0faf33d0d77 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -93,6 +93,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #if defined(CONFIG_CMD_PCAP)
>  #include 
>  #endif
> @@ -410,6 +411,16 @@ int net_loop(enum proto_t protocol)
> net_try_count = 1;
> debug_cond(DEBUG_INT_STATE, "--- net_loop Entry\n");
>
> +#ifdef CONFIG_PHY_NCSI
> +   if (phy_interface_is_ncsi() && protocol != NCSI && !ncsi_active()) {
> +   printf("%s: configuring NCSI first\n", __func__);
> +   if (net_loop(NCSI) < 0)
> +   return ret;
> +   eth_init_state_only();
> +   goto restart;
> +   }
> +#endif
> +
> bootstage_mark_name(BOOTSTAGE_ID_ETH_START, "eth_start");
> net_init();
> if (eth_is_on_demand_init()) {
> @@ -526,6 +537,11 @@ restart:
> case WOL:
> wol_start();
> break;
> +#endif
> +#if defined(CONFIG_PHY_NCSI)
> +   case NCSI:
> +   ncsi_probe_packages();
> +   break;
>  #endif
> default:
> break;
> @@ -637,7 +653,7 @@ restart:
> env_set_hex("filesize", net_boot_file_size);
> env_set_hex("fileaddr", image_load_addr);
> }
> -   if (protocol != NETCONS)
> +   if (protocol != NETCONS && protocol != NCSI)
> eth_halt();
> else
> eth_halt_state_only();
> @@ -1321,6 +1337,11 @@ void net_process_received_packet(uchar *in_packet, int 
> len)
> case PROT_WOL:
> wol_receive(ip, len);
> break;
> +#endif
> +#ifdef CONFIG_PHY_NCSI
> + 

Re: [PATCH] arm: rockchip: rk3399: Program PLL clock for DDR at 50 MHz in documented range

[Michal Suchánek]

On Sat, Jul 16, 2022 at 12:31:45PM +0200, Xavier Drudis Ferran wrote:
> The original code set up the DDR clock to 48 MHz, not 50MHz as
> requested, and did it in a way that didn't satisfy the Application
> Notes in RK3399 TRM [1]. 2.9.2.B says:
> 
>PLL frequency range requirement
>[...]
>FOUTVCO: 800MHz to 3.2GHz
> 
> 2.9.2.A :
>PLL output frequency configuration
>[...]
>FOUTVCO = FREF / REFDIV * FBDIV
>FOUTPOSTDIV = FOUTVCO / POSTDIV1 / POSTDIV2
> 
> FREF = 24 MHz
> 
> The original code gives FOUTVCO: 24MHz/1 * 12 = 288MHz < 800MHz
> And the resulting FOUTPOSTDIV is 288MHz / 3 / 2 = 48MHz
> but the requested frequency was 50MHz
> 
> Note:
> 2.7.2 Detail Register Description
> PMUCRU_PPLL_CON0 says
> 
>fbdiv
>Feedback Divide Value
>Valid divider settings are:
>[16, 3200] in integer mode
> 
> So .fbdiv = 12 wouldn't be right. But 2.9.2.C says:
> 
>PLL setting consideration
>[...]
>The following settings are valid for FBDIV:
>DSMPD=1 (Integer Mode):
>12,13,14,16-4095 (practical value is limited to 3200, 2400, or 1600
>(FVCOMAX / FREFMIN))
>[...]
> 
> So .fbdiv = 12 would be right.
> 
> In any case FOUTVCO is still wrong. I thank YouMin Chen for
> confirmation and explanation.
> 
> Despite documentation, I don't seem to be able to reproduce a
> practical problem with the wrong FOUTVCO. When I initially found it I
> thought some problems with detecting the RAM capacity in my Rock Pi 4B
> could be related to it and my patch seemed to help. But since I'm no
> longer able to reproduce the issue, it works with or without this
> patch. And meanwhile a patch[2] by Lee Jones and YouMin Chen addresses
> this issue. Btw, shouldn't that be commited?
> 
> So this patches solves no visible problem.  Yet, to prevent future
> problems, I think it'd be best to stick to spec.
> 
> An alternative to this patch could be
> 
> {.refdiv = 1, .fbdiv = 75, .postdiv1 = 6, .postdiv2 = 6};
> 
> This would theoretically consume more power and yield less jitter,
> according to 2.9.2.C :
> 
>PLL setting consideration
>[...]
>For lowest power operation, the minimum VCO and FREF frequencies
>should be used. For minimum jitter operation, the highest VCO and
>FREF frequencies should be used.
>[...]
> 
> But I haven't tried it because I don't think it matters much. 50MHz
> for DDR is only shortly used by TPL at RAM init. Normal operation is
> at 800MHz.  Maybe it's better to use less power until later when more
> complex software can control batteries or charging or whatever ?
> 
> Cc: Simon Glass 
> Cc: Philipp Tomsich 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Sean Anderson 
> 
> Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
> 
> Link: [2] https://patchwork.ozlabs.org/project/uboot/list/?series=305766
> 
> Signed-off-by: Xavier Drudis Ferran 

The incorrect clock settings trigger an assert and prevent the board
from booting when clock debugging is enabled.

Fix works for me on Pinebook Pro.

Thanks

Michal

Tested-by: Michal Suchánek 

> ---
>  drivers/clk/rockchip/clk_rk3399.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk_rk3399.c 
> b/drivers/clk/rockchip/clk_rk3399.c
> index 7d31a9f22a..4762462b04 100644
> --- a/drivers/clk/rockchip/clk_rk3399.c
> +++ b/drivers/clk/rockchip/clk_rk3399.c
> @@ -840,7 +840,7 @@ static ulong rk3399_ddr_set_clk(struct rockchip_cru *cru,
>   switch (set_rate) {
>   case 50 * MHz:
>   dpll_cfg = (struct pll_div)
> - {.refdiv = 1, .fbdiv = 12, .postdiv1 = 3, .postdiv2 = 2};
> + {.refdiv = 2, .fbdiv = 75, .postdiv1 = 3, .postdiv2 = 6};
>   break;
>   case 200 * MHz:
>   dpll_cfg = (struct pll_div)
> -- 
> 2.20.1
> 

Re: [SPAM] rk3399 TPL memory setup code triggers clock frequency limit assertion

[Jagan Teki]

On Mon, Aug 8, 2022 at 9:46 PM Michal Suchánek  wrote:
>
> On Mon, Aug 08, 2022 at 04:28:33PM +0200, Xavier Drudis Ferran wrote:
> > El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
> > > Hello,
> > >
> > > when compiled with clock debug rk3399 cannot be booted because memory
> > > setup code triggers clock assertion:
> > >
> > > U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17)
> > > TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, 
> > > vco=120 khz, output=60 khz
> > > TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, 
> > > vco=120 khz, output=60 khz
> > > TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, 
> > > vco=1188000 khz, output=594000 khz
> > > TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, 
> > > vco=1536000 khz, output=384000 khz
> > > TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, 
> > > vco=288000 khz, output=48000 khz
> > > drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz 
> > > >= VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ 
> > > && output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && 
> > > div->fbdiv <= PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz
> >
> > Sorry, I don't have time now. But It might be related to
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut/
> >
> > Apparently this clock is wrong but nobody finds any consequence of it being 
> > wrong.
> > If one asks for a 50MHz clock and gets a 48MHz clockthings might work 
> > anyway, but
> > it's nice that at least when one asks to be told of problems one is told.
>
> Yes, that's exactly what I was looking for. It resolves the discrepancy
> between the asssert and the set clock by adjusting the clock settings.

If I remember correctly when I work with YouMin on LPDDR4 the initial
code to start to check with was 50MHz (It was not working at that time
with 48MHz). Not sure what to make other changes to fix that to try on
48MHz.

Better resend the patch again and add YouMin and others to see for comments.

Jagan.

[PATCH] arm: mvebu: Define env_sf_get_env_addr() for all Armada boards in SPL

[Pali Rohár]

SPI0 CS0 Flash is mapped to address range 0xD400 - 0xD7FF by BootROM.
Proper U-Boot removes this direct mapping. So it is available only in SPL.
This applies for all 32-bit Armada BootROMs. SPL mvebu code is used only on
32-bit Armada SoCs. So move env_sf_get_env_addr() function from Turris
Omnia board to common SPL mvebu code and add proper checks for SPI0 CS0.

Signed-off-by: Pali Rohár 
---
 arch/arm/mach-mvebu/spl.c| 13 +
 board/CZ.NIC/turris_omnia/turris_omnia.c | 10 --
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 13c99913c380..866e0ac62345 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -292,6 +292,19 @@ int board_return_to_bootrom(struct spl_image_info 
*spl_image,
hang();
 }
 
+/*
+ * SPI0 CS0 Flash is mapped to address range 0xD400 - 0xD7FF by 
BootROM.
+ * Proper U-Boot removes this direct mapping. So it is available only in SPL.
+ */
+#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
+CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
+CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
+void *env_sf_get_env_addr(void)
+{
+   return (void *)0xD400 + CONFIG_ENV_OFFSET;
+}
+#endif
+
 void board_init_f(ulong dummy)
 {
int ret;
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 5921769f1e1d..3180305f8031 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -255,16 +255,6 @@ static bool omnia_detect_wwan_usb3(const char *wwan_slot)
return false;
 }
 
-void *env_sf_get_env_addr(void)
-{
-   /* SPI Flash is mapped to address 0xD400 only in SPL */
-#ifdef CONFIG_SPL_BUILD
-   return (void *)0xD400 + CONFIG_ENV_OFFSET;
-#else
-   return NULL;
-#endif
-}
-
 int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 {
 #ifdef CONFIG_SPL_ENV_SUPPORT
-- 
2.20.1

Re: [SPAM] rk3399 TPL memory setup code triggers clock frequency limit assertion

[Michal Suchánek]

On Mon, Aug 08, 2022 at 04:28:33PM +0200, Xavier Drudis Ferran wrote:
> El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
> > Hello,
> > 
> > when compiled with clock debug rk3399 cannot be booted because memory
> > setup code triggers clock assertion:
> > 
> > U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17)
> > TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, 
> > vco=120 khz, output=60 khz
> > TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, 
> > vco=120 khz, output=60 khz
> > TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, 
> > vco=1188000 khz, output=594000 khz
> > TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, 
> > vco=1536000 khz, output=384000 khz
> > TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 
> > khz, output=48000 khz
> > drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= 
> > VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && 
> > output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= 
> > PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz
> 
> Sorry, I don't have time now. But It might be related to 
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut/
> 
> Apparently this clock is wrong but nobody finds any consequence of it being 
> wrong. 
> If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, 
> but 
> it's nice that at least when one asks to be told of problems one is told.

Yes, that's exactly what I was looking for. It resolves the discrepancy
between the asssert and the set clock by adjusting the clock settings.

Thanks

Michal

U-Boot TPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27)
TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
khz, output=60 khz
TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
khz, output=60 khz
TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 
khz, output=594000 khz
TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 
khz, output=384000 khz
TPL PLL at ff760040: fbdiv=75, refdiv=2, postdiv1=3, postdiv2=6, vco=90 
khz, output=5 khz
rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 5000 -> 5000
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
TPL PLL at ff760040: fbdiv=50, refdiv=1, postdiv1=3, postdiv2=1, vco=120 
khz, output=40 khz
rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 4 -> 
4
lpddr4_set_rate: change freq to 4 mhz 0, 1
TPL PLL at ff760040: fbdiv=100, refdiv=1, postdiv1=3, postdiv2=1, vco=240 
khz, output=80 khz
rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 8 -> 
8
lpddr4_set_rate: change freq to 8 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
SPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
khz, output=60 khz
SPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
khz, output=60 khz
SPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 
khz, output=594000 khz
SPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 
khz, output=384000 khz
rk3399_clk_get_rate: clk clock-controller@ff76 83

U-Boot SPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27 +0200)

Re: [PATCH] distroboot: ubifs: Add support for specifying UBI header offset

[Tom Rini]

On Sun, Aug 07, 2022 at 09:04:22PM +0200, Pali Rohár wrote:

> Some UBI partitions may use non-standard UBI header offset. For attaching
> these UBI partitions it is required to pass second argument with offset to
> "ubi part" command.
> 
> Therefore extend distroboot to allow specifying additional optional 6th
> argument with UBI header offset. This offset is set in new distroboot
> variable ${bootubioff} which may be used by distroboot script to e.g.
> properly pass this value to linux kernel command line for proper mounting
> of rootfs by kernel. This variable is set to empty string (cleared) when
> UBI header offset is not specified into distroboot BOOT_TARGET_DEVICES
> macro.
> 
> Usage of helper macro BOOTENV_DEV_UBIFS_BOOTUBIOFF in this change is there
> as a type check. It ensures that in BOOT_TARGET_DEVICES macro was specified
> UBIFS func with either 5 or 6 arguments. If not then cpp throws compile
> error.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 2/2] ci: Add a test for a non-LTO build

[Tom Rini]

On Sun, Aug 07, 2022 at 09:48:01AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 3 Aug 2022 at 12:13, Simon Glass  wrote:
> >
> > Check that sandbox builds and runs tests OK with LTO disabled.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >  .azure-pipelines.yml | 4 
> >  .gitlab-ci.yml   | 7 +++
> >  2 files changed, 11 insertions(+)
> >
> 
> Another little snippet - it seems that CI performance for the world
> builds has dropped 20% - 30% with LTO enabled. With tui I used to see
> just over 1 build a second; now it is running at about 0.78 and kaki
> has gone from close to 0.5 to 0.29.
> 
> I wonder if ,in CI, we should just build a selection of boards with
> LTO, switching the world builds to non-LTO? The problem is that we may
> hit code size limits in SPL.

I'm not sure how you're measuring this. We don't enable LTO by default
anywhere other than sandbox, it's opt-in for a few platforms still.

-- 
Tom


signature.asc
Description: PGP signature

Re: [SPAM] [PATCH 2/2] binman: Add more documentation about binman usage

[Xavier Drudis Ferran]

El Sun, Aug 07, 2022 at 04:33:26PM -0600, Simon Glass deia:
> This is an attempt to answer the comments provided by Xavier [1].
> 

Thank you. Sorry if I point out silly things too. No agony intended.

>  
> +Note that binman can itself can create a FIT. This helps to move mkimage

one "can" too much

> +invocations out of the Makefile and into binman image descriptions. It also
> +helps by removing the need for ad-hoc tools like `make_fit_atf.py`.
> +
>

Maybe in future tense?
We're not there yet?, because of tee.bin, see Jerome's message.
Or is tee.bin not officialy supported yet in U-Boot?


> +How do you know how to incorporate ATF? It is handled by the atf-bl31 entry 
> type
> +(etype). An etype is an implementation of reading a binary into binman, in 
> this
> +case the `bl31.bin` file. When you build U-Boot but do not set the BL31
> +environment variable, binman provides a help message, which comes from
> +`missing-blob-help`::
> +
> +See the documentation for your board. You may need to build ARM Trusted
> +Firmware and build with BL31=/path/to/bl31.bin
> +
> +The mechanism by which binman is advised of this is also in the Makefile. See
> +the `-a atf-bl31-path=${BL31}` piece in `cmd_binman`. This tells binman to
> +set the EntryArg `atf-bl31-path` to the value of the `BL31` environment
> +variable. Within binman, this EntryArg is picked up by the `Entry_atf_bl31`
> +etype. An EntryArg is simply an argument to the entry. The `atf-bl31-path`
> +name is documented in :ref:`etype_atf_bl31`.
> +

Still confused. Shouldn't you mention split-elf ?
The way I use it bl31.elf is not simply copied into an image (atf_bl31.py
is just a Entry_blob_named_by_arg). It is sliced in pieces and put into 
u-boot.itb. Each piece carries a little metadada like the load address,
extracted from the elf by make_fit_atf.py or binman with split-elf. 

The problem is binman cannot incorporate an image it produced as a binary into
another, so we must still use make_fit_atf.py. But then binman does not use
atf-bl31, it simply includes a blob with filename="u-boot.itb".

Maybe it's not the best way to do it and people should just add a atf-bl31 {} 
section in their binman image and it somehow works ? Because that's what
I would assume from your text.

Or maybe you're talking of other boards, but then try not to write it as this
is the method one uses always when one has atf (TF-A)?

Anyway, thank you for writing it. The docs help understand many of the issues
and are a good improvement.

Re: Why is arm64 built with -ffixed-r9 ?

[Tom Rini]

On Mon, Aug 08, 2022 at 04:34:00PM +0200, Rasmus Villemoes wrote:

> Looking at one of the .o.cmd files, I noticed that we build arm64 with
> both -ffixed-r9 and -ffixed-x18. The latter is obviously what we use for
> gd, but the former doesn't seem to serve any purpose on arm64, and just
> seems to be an accident of the makefile fragment organization.
> 
> When I just remove -ffixed-r9 from arch/arm/config.mk, it builds and
> boots just fine (a real patch would of course do some ifndef
> CONFIG_ARM64 thing). The code does change, generally of the form "use x9
> instead of x10, x10 instead of x11" etc., i.e. the expected register
> allocation changes. But the total space saving from having that extra
> scratch reg is almost non-existing; a mere 44 bytes for u-boot proper;
> apparently aarch64 has plenty of scratch registers even if one is
> reserved-and-never-used.
> 
> Still, it's somewhat confusing, so if for some reason this is really
> needed in some cases (calling into some 32 bit firmware???), I'd like a
> comment somewhere.

I strongly suspect this is just a remnant of how the Makefile logic is,
and that since nothing failed with -ffixed-r9 it just kept being used.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 7/8] net: add MV88E61xx DSA driver

[Tim Harvey]

On Sat, Aug 6, 2022 at 5:07 PM Ramon Fried  wrote:
>
> On Thu, Jun 23, 2022 at 3:43 PM Vladimir Oltean  
> wrote:
> >
> > On Tue, Jun 21, 2022 at 08:11:06AM -0700, Tim Harvey wrote:
> > > On Tue, Jun 21, 2022 at 12:21 AM Vladimir Oltean
> > >  wrote:
> > > >
> > > > On Mon, Jun 20, 2022 at 04:37:45PM -0700, Tim Harvey wrote:
> > > > > On Mon, Jun 20, 2022 at 4:58 AM Vladimir Oltean
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, May 23, 2022 at 11:25:48AM -0700, Tim Harvey wrote:
> > > > > > > +/* bind and probe the switch mdios */
> > > > > > > +static int mv88e61xx_dsa_probe_mdio(struct udevice *dev)
> > > > > > > +{
> > > > > > > + struct udevice *pdev;
> > > > > > > + ofnode node, mdios;
> > > > > > > + const char *name;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + /* bind phy ports of mdios child node to mv88e61xx_mdio 
> > > > > > > device */
> > > > > > > + mdios = dev_read_subnode(dev, "mdios");
> > > > > > > + if (ofnode_valid(mdios)) {
> > > > > > > + ofnode_for_each_subnode(node, mdios) {
> > > > > > > + name = ofnode_get_name(node);
> > > > > > > + ret = device_bind_driver_to_node(dev,
> > > > > > > +  
> > > > > > > "mv88e61xx_mdio",
> > > > > > > +  name, 
> > > > > > > node, );
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "failed to bind %s: 
> > > > > > > %d\n", name, ret);
> > > > > > > + continue;
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* need to probe it as there is no 
> > > > > > > compatible to do so */
> > > > > > > + ret = 
> > > > > > > uclass_get_device_by_ofnode(UCLASS_MDIO, node, );
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "failed to probe %s: 
> > > > > > > %d\n", name, ret);
> > > > > > > + continue;
> > > > > > > + }
> > > > > >
> > > > > > What do you do with this pdev once you get it? Are you missing a 
> > > > > > device_probe() call?
> > > > > > Also, why "pdev" and not "dev"? What does the "p" stand for?
> > > > >
> > > > > struct udevice *dev is passed into the function so I use pdev to
> > > > > iterate over the ports in the mdios node so 'pdev' means 'port' here.
> > > >
> > > > Yes, but those under the mdios node aren't ports, they're MDIO
> > > > controllers, hence my comment.
> > >
> > > how about devp (dev pointer) or subdev or mdio?
> >
> > The terminology problem I have with "mdio" is that it would be a
> > struct udevice *, whereas the plural variable, "mdios", is an ofnode.
> > How about mdev, for mdio device?
> Tim ?

Hi Ramon,

I haven't had time to get back to this yet. I hope to do so in the
next few weeks.

Best Regards,

Tim

[PATCH] fpga: zynq: Remove post config info message for SPL

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The drivers informs the user that a post config was not run after FPGA
configuration. This message is unnecessary in SPL because the
ps7_post_config function is called via spl_board_prepare_for_boot
function before jump_to_image_no_args function from board_init_r
function.

Signed-off-by: Stefan Herbrechtsmeier 

---

 drivers/fpga/zynqpl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index d8ebd542ab..0c83df46da 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -413,7 +413,8 @@ static int zynq_load(xilinx_desc *desc, const void *buf, 
size_t bsize,
if (bstype != BIT_PARTIAL)
zynq_slcr_devcfg_enable();
 
-   puts("INFO:post config was not run, please run manually if needed\n");
+   if (!IS_ENABLED(CONFIG_SPL_BUILD))
+   puts("INFO:post config was not run, please run manually if 
needed\n");
 
return FPGA_SUCCESS;
 }
-- 
2.30.2

[PATCH] disk: part: remove dependency to ubifs for spl

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The spl doesn't support ubifs and thereby doesn't provide the
ubifs_is_mounted function. Remove the dependency to ubifs for the spl.

Signed-off-by: Stefan Herbrechtsmeier 

---

 disk/part.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part.c b/disk/part.c
index 79955c7fb0..de1b917e84 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -479,7 +479,7 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
}
 #endif
 
-#ifdef CONFIG_CMD_UBIFS
+#if IS_ENABLED(CONFIG_CMD_UBIFS) && !IS_ENABLED(CONFIG_SPL_BUILD)
/*
 * Special-case ubi, ubi goes through a mtd, rather than through
 * a regular block device.
-- 
2.30.2

Why is arm64 built with -ffixed-r9 ?

[Rasmus Villemoes]

Looking at one of the .o.cmd files, I noticed that we build arm64 with
both -ffixed-r9 and -ffixed-x18. The latter is obviously what we use for
gd, but the former doesn't seem to serve any purpose on arm64, and just
seems to be an accident of the makefile fragment organization.

When I just remove -ffixed-r9 from arch/arm/config.mk, it builds and
boots just fine (a real patch would of course do some ifndef
CONFIG_ARM64 thing). The code does change, generally of the form "use x9
instead of x10, x10 instead of x11" etc., i.e. the expected register
allocation changes. But the total space saving from having that extra
scratch reg is almost non-existing; a mere 44 bytes for u-boot proper;
apparently aarch64 has plenty of scratch registers even if one is
reserved-and-never-used.

Still, it's somewhat confusing, so if for some reason this is really
needed in some cases (calling into some 32 bit firmware???), I'd like a
comment somewhere.

Rasmus

Re: [SPAM] rk3399 TPL memory setup code triggers clock frequency limit assertion

[Xavier Drudis Ferran]

El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
> Hello,
> 
> when compiled with clock debug rk3399 cannot be booted because memory
> setup code triggers clock assertion:
> 
> U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17)
> TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
> khz, output=60 khz
> TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 
> khz, output=60 khz
> TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 
> khz, output=594000 khz
> TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 
> khz, output=384000 khz
> TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 
> khz, output=48000 khz
> drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= 
> VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && 
> output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= 
> PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz

Sorry, I don't have time now. But It might be related to 

https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut/

Apparently this clock is wrong but nobody finds any consequence of it being 
wrong. 
If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, 
but 
it's nice that at least when one asks to be told of problems one is told.


> 
> What would be a resonable way to make rk3399 bootable with clock debug
> enabled?
>

Try my patch, I don't think it can hurt ?

[PATCH] arm64: explicitly disable pointer authentication instructions

[Rasmus Villemoes]

The Yocto project builds their aarch64 cross-compiler with the
configure knob --enable-standard-branch-protection, which means that
their gcc behaves as if -mbranch-protection=standard is passed; the
default (lacking that configure knob) is -mbranch-protection=none.

This means that when building U-Boot using the Yocto toolchain, most
functions end up containing paciasp/autiasp/bti instructions. However,
since U-Boot is not an ordinary userspace application, there's no OS
kernel which has set up the required authentication keys, so these
instructions do nothing at all (even on arm64 hardware that does have
the pointer authentication capability). They do however make the image
larger.

It is theoretically possible for U-Boot to make use of the pointer
authentication protection - cf. the linux kernel's
CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's
hard to see just what threat model it would protect against in a
bootloader context. Regardless, we certainly have none of the required
infrastructure now, so explictly pass -mbranch-protection=none to
ensure those useless instructions do not get emitted.

For a toolchain not configured with
--enable-standard-branch-protection, this changes nothing. For the
Yocto toolchain, this reduces the size of both SPL and U-Boot proper
by about 3% for my imx8mp target.

If you don't have a Yocto toolchain, the effect can easily be
reproduced by applying this patch and changing =none to =standard.

Signed-off-by: Rasmus Villemoes 
---
Not sure who to cc, there's no overall arm64 maintainer listed in
MAINTAINERS, but Tom is listed as generally handling arch/arm/.

 arch/arm/cpu/armv8/config.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
index 6f9093109f..ca06ed3d4f 100644
--- a/arch/arm/cpu/armv8/config.mk
+++ b/arch/arm/cpu/armv8/config.mk
@@ -3,6 +3,7 @@
 # (C) Copyright 2002
 # Gary Jennejohn, DENX Software Engineering, 
 PLATFORM_RELFLAGS += -fno-common -ffixed-x18
+PLATFORM_RELFLAGS += $(call cc-option,-mbranch-protection=none)
 
 PF_NO_UNALIGNED := $(call cc-option, -mstrict-align)
 PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
-- 
2.31.1

RE: "Synchronous Abort" handler, esr 0x96000004 with AGL (Yocto Based)

[Sole Mendi Carles (PS-EC/ECC7)]

Dear u-boot mailing list,

As no one has provided any feedback regarding my question I am trying my luck 
again. 

As described below depending on the DT's I overlay using an AGL build for RPi4 
I get a "Synchronous Abort" handler error. Any hints on what this error means 
and why u-boot cannot load the overlays would be much appreciated.

I provided the log files of the boot process with CONFIG_LOG enabled. I can 
send them again if required.

Best Regards,
Carles

Mit freundlichen Grüßen / Best regards

 Carles Sole Mendi

Engineering Customer Platform Ford Diesel, Customer Projects Ford Diesel EU 
(PS-EC/ECU2)
Robert Bosch GmbH | Postfach 30 02 40 | 70442 Stuttgart | GERMANY | 
www.bosch.com
Tel. +49 711 811-20593 | Fax +49 711 811 | carles.soleme...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Prof. Dr. Stefan Asenkerschbaumer; Managing 
Directors: Dr. Stefan Hartung, 
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, 
Rolf Najork

-Original Message-
From: U-Boot  On Behalf Of Sole Mendi Carles 
(PS-EC/ECC7)
Sent: Montag, 25. Juli 2022 11:31
To: u-boot@lists.denx.de
Cc: and...@gherzan.com
Subject: "Synchronous Abort" handler, esr 0x9604 with AGL (Yocto Based)

Dear U-boot mailing list,


My name is Carles and I have been trying for a while to use a Yocto based 
distribution (AGL) image for RPi4 to control automotive HW using pwm signals. 
Unfortunately I have been struggling with this when the boot procedure is 
configured to use u-boot.



I am basically building the minimal image doing following change in the 
configuration to enable pwm.dtbo:



In 
/conf/machine/include/rpi-base.inc
 I add the pwm dtbo’s.



RPI_KERNEL_DEVICETREE_OVERLAYS: Add following dtbo‘s:

   overlays/pwm.dtbo

   overlays/pwm-2chan.dtbo



With this changes the image builds and boots without issues. However once I add 
dtoverlay=pwm in config.txt the boot process does not work anymore and shows 
following error:



mmc0 is current device

Scanning mmc 0:1...

Found U-Boot script /boot.scr

262 bytes read in 5 ms (50.8 KiB/s)

## Executing script at 0240

"Synchronous Abort" handler, esr 0x9604

elr: 000a2afc lr : 000a2b34 (reloc)

elr: 2ef6fafc lr : 2ef6fb34

x0 : 2eb5a780 x1 : 1218121712161215

x2 : 2eb48e50 x3 : 0015

x4 : 1224122312221221 x5 : 0015

x6 : 2efc3b88 x7 : 2efc3b88

x8 : 0001 x9 : 0008

x10: 0006 x11: 2eb529d0

x12: 2022 x13: 0001

x14: 0008 x15: 2eb3cfb0

x16: 2ef77858 x17: 

x18: 2eb48d90 x19: 

x20: 0006 x21: 0006

x22:  x23: 2eb3ac68

x24: 2efac8a8 x25: 2eb615c0

x26: 00bff800 x27: 2ebe3d40

x28: 1800 x29: 2eb3abe0



Code: 5461 d280 d65f03c0 f9400401 (b9400821)

Resetting CPU ...



If I disable U-boot using RPI_USE_U_BOOT = „0“ then all works good and I can 
use the pwm driver and generate pwm signals, but I would really like to be able 
to use u-boot.


I am not sure how I need to update the u-boot addresses with the added dtbo’s 
so that u-boot is able to recognize these and boot successfully. Any hints from 
your side would be much appreciated.

I have enabled logging in u-boot and stored the boot process without 
dtoverlay=pwm vs.with dtoverlay=pwm. I attach both files for reference. I hope 
this is helpful.

Mit freundlichen Grüßen / Best regards

Carles Sole Mendi

Engineering Customer Platform Ford Diesel, Customer Projects Ford Diesel EU 
(PS-EC/ECU2) Robert Bosch GmbH | Postfach 30 02 40 | 70442 Stuttgart | GERMANY 
| www.bosch.com Tel. +49 711 811-20593 | Fax +49 711 811 | 
carles.soleme...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000; Chairman of the Supervisory Board: Prof. Dr. Stefan Asenkerschbaumer; 
Managing Directors: Dr. Stefan Hartung, Dr. Christian Fischer, Filiz Albrecht, 
Dr. Markus Forschner, Dr. Markus Heyn, Rolf Najork ​

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> On Fri, 5 Aug 2022 18:20:19 -0400
> Tom Rini  wrote:
> 
> > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote: 
> > > > > > > > > >  
> > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár 
> > > > > > > > > > > > wrote:  
> > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali 
> > > > > > > > > > > > > > Rohár wrote:
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Your commit 
> > > > > > > > > > > > > > > de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems 
> > > > > > > > > > > > > > > to be broken.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full 
> > > > > > > > > > > > > > usage that was there
> > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > 
> > > > > > > > > > > > As the config files were just unclear, but you seem to 
> > > > > > > > > > > > understand what
> > > > > > > > > > > > it's supposed to be, a patch to clean it up would be 
> > > > > > > > > > > > most appreciated,
> > > > > > > > > > > > thanks.
> > > > > > > > > > > > 
> > > > > > > > > > > > -- 
> > > > > > > > > > > > Tom  
> > > > > > > > > > > 
> > > > > > > > > > > Broken is also commit 
> > > > > > > > > > > d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > that all kconfig migration changes done after that commit 
> > > > > > > > > > > are broken.
> > > > > > > > > > > 
> > > > > > > > > > > I really do not have energy to investigate what and how 
> > > > > > > > > > > was broken due
> > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > >  
> > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > +#error
> > > > > > > > > > > +#endif
> > > > > > > > > > > 
> > > > > > > > > > > And then called:
> > > > > > > > > > > 
> > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- 
> > > > > > > > > > > P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > 
> > > > > > > > > > > And it failed, even when this defconfig file is not SD 
> > > > > > > > > > > card builds.  
> > > > > > > > > > 
> > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > 
> > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP 
> > > > > > > > > PBL
> > > > > > > > > header.  
> > > > > > > > 
> > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from 
> > > > > > > > the choice
> > > > > > > > on "Freescale PBL load location".
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Tom  
> > > > > > > 
> > > > > > > I just do not understand.
> > > > > > > 
> > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL 
> > > > > > > and
> > > > > > > for SD card pre-PBL support I added option 
> > > > > > > FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > 
> > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS 
> > > > > > > contains
> > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and 
> > > > > > > P20**
> > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > 
> > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's 
> > > > > > what
> > > > > > needs to be corrected then.  
> > > > > 
> > > > > But it was correct, no? CONFIG_SDCARD 

Re: [PATCH v2 1/2] ARM: cache: Allow SPL to build cache-pl310.c

[Tom Rini]

On Mon, Aug 08, 2022 at 02:29:02PM +0200, Philip Oberfichtner wrote:
> 
> 
> On Thu, 2022-08-04 at 07:05 -0400, Tom Rini wrote:
> > On Thu, Aug 04, 2022 at 12:56:45PM +0200, Philip Oberfichtner wrote:
> > 
> > > Before this commit, the SPL could enable the PL310 L2 cache [1],
> > > but the
> > > cache maintenance functions from cache-pl310.c were only useable
> > > for
> > > non-SPL builds.
> > > 
> > > After enabling the cache one must be able to flush it, too. Thus
> > > this
> > > commit allows cache-pl310.c to be included in the SPL build.
> > > 
> > > [1] See for example arch/arm/mach-imx/cache.c:
> > > v7_outer_cache_enable()
> > > 
> > > Signed-off-by: Philip Oberfichtner 
> > 
> > It should be rather direct to migrate this to Kconfig, please do that
> > first, and introduce CONFIG_SPL_SYS_L2_PL310.  Thanks!
> > 
> 
> Hi,
> 
> converting CONFIG_SYS_L2_PL310 - no problem. For SYS_PL310_BASE the
> moveconfig tool just hangs indefinitely on every defconfig that needs
> conversion. Do you have any hints on this issue?
> 
> Below the Kconfig entry, that I used.
> 
> config SYS_PL310_BASE
>depends on SYS_L2_PL310
>hex "Base address of PL310"
>help
>  Physical base address of PL310 controller register space

We can just skip that one for the moment, it's a bit tricky. It
shouldn't be asked for as it's not configurable, it needs to be a list
of default X if ARCH_Y. Thanks for looking at this one too!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 1/4] net: NC-SI setup and handling

[Cédric Le Goater]

On 8/8/22 14:16, Joel Stanley wrote:

From: Samuel Mendoza-Jonas 

Add the handling of NC-SI ethernet frames, and add a check at the start
of net_loop() to configure NC-SI before starting other network commands.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 


---
v4: split out cmd addition into a separate patch
v3:
  - Fix compilation. There were no configs that enabled the NCSI phy code
so it had bitrotted
  - Use NCSI_PHY instead of CMD_NCSI so NCSI can work without the command
  - Add phy_interface_is_ncsi() helper, thanks Cédric for this suggestion
  - Only create NCSI phy device when driver is configured for it

  include/net.h  |  2 +-
  include/phy.h  |  2 ++
  drivers/net/phy/ncsi.c |  1 +
  drivers/net/phy/phy.c  |  9 -
  net/net.c  | 26 +-
  5 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/include/net.h b/include/net.h
index e3889a0bc85e..0681b8246323 100644
--- a/include/net.h
+++ b/include/net.h
@@ -558,7 +558,7 @@ extern int  net_restart_wrap;   /* Tried all 
network devices */
  
  enum proto_t {

BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
-   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP
+   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI
  };
  
  extern char	net_boot_file_name[1024];/* Boot File name */

diff --git a/include/phy.h b/include/phy.h
index b32959571069..1e0f8856f629 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -583,6 +583,8 @@ static inline bool phy_interface_is_sgmii(struct phy_device 
*phydev)
phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
  }
  
+bool phy_interface_is_ncsi(void);

+
  /* PHY UIDs for various PHYs that are referenced in external code */
  #define PHY_UID_CS43400x13e51002
  #define PHY_UID_CS42230x03e57003
diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
index bf1e832be9f1..bb7ecebed382 100644
--- a/drivers/net/phy/ncsi.c
+++ b/drivers/net/phy/ncsi.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1121b99abff5..d04538838852 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1026,7 +1026,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
addr,
  #endif
  
  #ifdef CONFIG_PHY_NCSI

-   if (!phydev)
+   if (!phydev && interface == PHY_INTERFACE_MODE_NCSI)
phydev = phy_device_create(bus, 0, PHY_NCSI_ID, false);
  #endif
  
@@ -1101,3 +1101,10 @@ int phy_modify(struct phy_device *phydev, int devad, int regnum, u16 mask,
  
  	return phy_write(phydev, devad, regnum, (ret & ~mask) | set);

  }
+
+bool phy_interface_is_ncsi(void)
+{
+   struct eth_pdata *pdata = dev_get_plat(eth_get_dev());
+
+   return pdata->phy_interface == PHY_INTERFACE_MODE_NCSI;
+}
diff --git a/net/net.c b/net/net.c
index 81905f631592..f0faf33d0d77 100644
--- a/net/net.c
+++ b/net/net.c
@@ -93,6 +93,7 @@
  #include 
  #include 
  #include 
+#include 
  #if defined(CONFIG_CMD_PCAP)
  #include 
  #endif
@@ -410,6 +411,16 @@ int net_loop(enum proto_t protocol)
net_try_count = 1;
debug_cond(DEBUG_INT_STATE, "--- net_loop Entry\n");
  
+#ifdef CONFIG_PHY_NCSI

+   if (phy_interface_is_ncsi() && protocol != NCSI && !ncsi_active()) {
+   printf("%s: configuring NCSI first\n", __func__);
+   if (net_loop(NCSI) < 0)
+   return ret;
+   eth_init_state_only();
+   goto restart;
+   }
+#endif
+
bootstage_mark_name(BOOTSTAGE_ID_ETH_START, "eth_start");
net_init();
if (eth_is_on_demand_init()) {
@@ -526,6 +537,11 @@ restart:
case WOL:
wol_start();
break;
+#endif
+#if defined(CONFIG_PHY_NCSI)
+   case NCSI:
+   ncsi_probe_packages();
+   break;
  #endif
default:
break;
@@ -637,7 +653,7 @@ restart:
env_set_hex("filesize", net_boot_file_size);
env_set_hex("fileaddr", image_load_addr);
}
-   if (protocol != NETCONS)
+   if (protocol != NETCONS && protocol != NCSI)
eth_halt();
else
eth_halt_state_only();
@@ -1321,6 +1337,11 @@ void net_process_received_packet(uchar *in_packet, int 
len)
case PROT_WOL:
wol_receive(ip, len);
break;
+#endif
+#ifdef CONFIG_PHY_NCSI
+   case PROT_NCSI:
+   ncsi_receive(et, ip, len);
+   break;
  #endif
}
  }
@@ -1381,6 +1402,9 @@ common:
  
  #ifdef CONFIG_CMD_RARP

case RARP:
+#endif
+#ifdef 

Re: [PATCH v4 2/4] cmd: Add ncsi command

[Cédric Le Goater]

On 8/8/22 14:16, Joel Stanley wrote:

From: Samuel Mendoza-Jonas 

Adds an "ncsi" command to manually start NC-SI configuration.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 


---
v4: New patch, split from patch 1

  cmd/net.c   | 22 ++
  net/net.c   |  1 +
  cmd/Kconfig |  8 
  3 files changed, 31 insertions(+)

diff --git a/cmd/net.c b/cmd/net.c
index 3619c843d838..2863fe768118 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  
  static int netboot_common(enum proto_t, struct cmd_tbl *, int, char * const []);
  
@@ -524,3 +525,24 @@ U_BOOT_CMD(

"list - list available devices\n"
  );
  #endif // CONFIG_DM_ETH
+
+#if defined(CONFIG_CMD_NCSI)
+static int do_ncsi(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   if (!phy_interface_is_ncsi() || !ncsi_active()) {
+   printf("Device not configured for NC-SI\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (net_loop(NCSI) < 0)
+   return CMD_RET_FAILURE;
+
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+   ncsi,   1,  1,  do_ncsi,
+   "Configure attached NIC via NC-SI",
+   ""
+);
+#endif  /* CONFIG_CMD_NCSI */
diff --git a/net/net.c b/net/net.c
index f0faf33d0d77..a4e645ac4425 100644
--- a/net/net.c
+++ b/net/net.c
@@ -434,6 +434,7 @@ int net_loop(enum proto_t protocol)
} else {
eth_init_state_only();
}
+
  restart:
  #ifdef CONFIG_USB_KEYBOARD
net_busy_flag = 0;
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3625ff2a50b3..3a5d1bba78a8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1813,6 +1813,14 @@ config CMD_LINK_LOCAL
help
  Acquire a network IP address using the link-local protocol
  
+config CMD_NCSI

+   bool "ncsi"
+   depends on PHY_NCSI
+   help
+ Manually configure the attached NIC via NC-SI.
+ Normally this happens automatically before other network
+ operations.
+
  endif
  
  config CMD_ETHSW

Re: [PATCH v2 1/2] ARM: cache: Allow SPL to build cache-pl310.c

[Marek Vasut]

On 8/8/22 14:29, Philip Oberfichtner wrote:



On Thu, 2022-08-04 at 07:05 -0400, Tom Rini wrote:

On Thu, Aug 04, 2022 at 12:56:45PM +0200, Philip Oberfichtner wrote:


Before this commit, the SPL could enable the PL310 L2 cache [1],
but the
cache maintenance functions from cache-pl310.c were only useable
for
non-SPL builds.

After enabling the cache one must be able to flush it, too. Thus
this
commit allows cache-pl310.c to be included in the SPL build.

[1] See for example arch/arm/mach-imx/cache.c:
v7_outer_cache_enable()

Signed-off-by: Philip Oberfichtner 


It should be rather direct to migrate this to Kconfig, please do that
first, and introduce CONFIG_SPL_SYS_L2_PL310.  Thanks!



Hi,

converting CONFIG_SYS_L2_PL310 - no problem. For SYS_PL310_BASE the
moveconfig tool just hangs indefinitely on every defconfig that needs
conversion. Do you have any hints on this issue?

Below the Kconfig entry, that I used.

config SYS_PL310_BASE
depends on SYS_L2_PL310
hex "Base address of PL310"


Try adding default values for known architectures/socs (use git grep in 
include/configs/ and sort -u to find out)

default 0x1234ab00 if ARCH_FOO
default 0x4321cd00 if ARCH_BAR


help
  Physical base address of PL310 controller register space

Re: [PATCH v2 1/2] ARM: cache: Allow SPL to build cache-pl310.c

[Philip Oberfichtner]

On Thu, 2022-08-04 at 07:05 -0400, Tom Rini wrote:
> On Thu, Aug 04, 2022 at 12:56:45PM +0200, Philip Oberfichtner wrote:
> 
> > Before this commit, the SPL could enable the PL310 L2 cache [1],
> > but the
> > cache maintenance functions from cache-pl310.c were only useable
> > for
> > non-SPL builds.
> > 
> > After enabling the cache one must be able to flush it, too. Thus
> > this
> > commit allows cache-pl310.c to be included in the SPL build.
> > 
> > [1] See for example arch/arm/mach-imx/cache.c:
> > v7_outer_cache_enable()
> > 
> > Signed-off-by: Philip Oberfichtner 
> 
> It should be rather direct to migrate this to Kconfig, please do that
> first, and introduce CONFIG_SPL_SYS_L2_PL310.  Thanks!
> 

Hi,

converting CONFIG_SYS_L2_PL310 - no problem. For SYS_PL310_BASE the
moveconfig tool just hangs indefinitely on every defconfig that needs
conversion. Do you have any hints on this issue?

Below the Kconfig entry, that I used.

config SYS_PL310_BASE
   depends on SYS_L2_PL310
   hex "Base address of PL310"
   help
 Physical base address of PL310 controller register space

[PATCH v4 4/4] config/aspeed: Enable NC-SI support

[Joel Stanley]

Aspeed BMCs are commonly used with NC-SI. A system indicates the driver
should configure the link over NC-SI using the device tree.

Add it to the defconfig so we get compile coverage of the driver, even
if the EVBs do not normally use it.

Signed-off-by: Joel Stanley 
Reviewed-by: Ramon Fried 
Reviewed-by: Cédric Le Goater 
---
v4: Add r-b from Cédric and Ramon

 configs/evb-ast2500_defconfig | 2 ++
 configs/evb-ast2600_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
index e7d93ec48bf0..1ed0c4dee76b 100644
--- a/configs/evb-ast2500_defconfig
+++ b/configs/evb-ast2500_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_NCSI=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
@@ -40,6 +41,7 @@ CONFIG_I2C_EEPROM=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ASPEED=y
 CONFIG_PHY_REALTEK=y
+CONFIG_PHY_NCSI=y
 CONFIG_DM_ETH=y
 CONFIG_FTGMAC100=y
 CONFIG_PHY=y
diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index d07d3c41fef6..e6cfef1137bb 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -66,6 +66,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_NCSI=y
 CONFIG_CMD_EXT4=y
 CONFIG_DOS_PARTITION=y
 # CONFIG_SPL_DOS_PARTITION is not set
@@ -88,6 +89,7 @@ CONFIG_I2C_EEPROM=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ASPEED=y
 CONFIG_PHY_REALTEK=y
+CONFIG_PHY_NCSI=y
 CONFIG_DM_ETH=y
 CONFIG_DM_MDIO=y
 CONFIG_FTGMAC100=y
-- 
2.35.1

[PATCH v4 3/4] net/ftgmac100: Add NC-SI mode support

[Joel Stanley]

From: Samuel Mendoza-Jonas 

Update the ftgmac100 driver to support NC-SI instead of an mdio phy
where available. This is a common setup for Aspeed AST2x00 platforms.

NC-SI mode is determined from the device-tree if either phy-mode sets it
or the use-ncsi property exists. If set then normal mdio setup is
skipped in favour of the NC-SI phy.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: Joel Stanley 
Reviewed-by: Cédric Le Goater 
Reviewed-by: Ramon Fried 
---
v4: Add r-b from Cédric and Ramon
v3:
 - Simplify ncsi enable by re-using pdata->phy_interface parsing.
   use-ncsi still overrides this value.
 - Fix up freeing in remove callback per Joe's review

 drivers/net/ftgmac100.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 78779d7d60b9..69370ea5cca2 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -188,7 +188,7 @@ static int ftgmac100_phy_adjust_link(struct ftgmac100_data 
*priv)
struct phy_device *phydev = priv->phydev;
u32 maccr;
 
-   if (!phydev->link) {
+   if (!phydev->link && priv->phy_mode != PHY_INTERFACE_MODE_NCSI) {
dev_err(phydev->dev, "No link\n");
return -EREMOTEIO;
}
@@ -228,7 +228,8 @@ static int ftgmac100_phy_init(struct udevice *dev)
if (!phydev)
return -ENODEV;
 
-   phydev->supported &= PHY_GBIT_FEATURES;
+   if (priv->phy_mode != PHY_INTERFACE_MODE_NCSI)
+   phydev->supported &= PHY_GBIT_FEATURES;
if (priv->max_speed) {
ret = phy_set_supported(phydev, priv->max_speed);
if (ret)
@@ -308,7 +309,8 @@ static void ftgmac100_stop(struct udevice *dev)
 
writel(0, >maccr);
 
-   phy_shutdown(priv->phydev);
+   if (priv->phy_mode != PHY_INTERFACE_MODE_NCSI)
+   phy_shutdown(priv->phydev);
 }
 
 static int ftgmac100_start(struct udevice *dev)
@@ -580,6 +582,9 @@ static int ftgmac100_probe(struct udevice *dev)
priv->max_speed = pdata->max_speed;
priv->phy_addr = 0;
 
+   if (dev_read_bool(dev, "use-ncsi"))
+   priv->phy_mode = PHY_INTERFACE_MODE_NCSI;
+
 #ifdef CONFIG_PHY_ADDR
priv->phy_addr = CONFIG_PHY_ADDR;
 #endif
@@ -592,7 +597,8 @@ static int ftgmac100_probe(struct udevice *dev)
 * If DM MDIO is enabled, the MDIO bus will be initialized later in
 * dm_eth_phy_connect
 */
-   if (!IS_ENABLED(CONFIG_DM_MDIO)) {
+   if (priv->phy_mode != PHY_INTERFACE_MODE_NCSI &&
+   !IS_ENABLED(CONFIG_DM_MDIO)) {
ret = ftgmac100_mdio_init(dev);
if (ret) {
dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
-- 
2.35.1

[PATCH v4 2/4] cmd: Add ncsi command

[Joel Stanley]

From: Samuel Mendoza-Jonas 

Adds an "ncsi" command to manually start NC-SI configuration.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: Joel Stanley 
---
v4: New patch, split from patch 1

 cmd/net.c   | 22 ++
 net/net.c   |  1 +
 cmd/Kconfig |  8 
 3 files changed, 31 insertions(+)

diff --git a/cmd/net.c b/cmd/net.c
index 3619c843d838..2863fe768118 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int netboot_common(enum proto_t, struct cmd_tbl *, int, char * const 
[]);
 
@@ -524,3 +525,24 @@ U_BOOT_CMD(
"list - list available devices\n"
 );
 #endif // CONFIG_DM_ETH
+
+#if defined(CONFIG_CMD_NCSI)
+static int do_ncsi(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   if (!phy_interface_is_ncsi() || !ncsi_active()) {
+   printf("Device not configured for NC-SI\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (net_loop(NCSI) < 0)
+   return CMD_RET_FAILURE;
+
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+   ncsi,   1,  1,  do_ncsi,
+   "Configure attached NIC via NC-SI",
+   ""
+);
+#endif  /* CONFIG_CMD_NCSI */
diff --git a/net/net.c b/net/net.c
index f0faf33d0d77..a4e645ac4425 100644
--- a/net/net.c
+++ b/net/net.c
@@ -434,6 +434,7 @@ int net_loop(enum proto_t protocol)
} else {
eth_init_state_only();
}
+
 restart:
 #ifdef CONFIG_USB_KEYBOARD
net_busy_flag = 0;
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3625ff2a50b3..3a5d1bba78a8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1813,6 +1813,14 @@ config CMD_LINK_LOCAL
help
  Acquire a network IP address using the link-local protocol
 
+config CMD_NCSI
+   bool "ncsi"
+   depends on PHY_NCSI
+   help
+ Manually configure the attached NIC via NC-SI.
+ Normally this happens automatically before other network
+ operations.
+
 endif
 
 config CMD_ETHSW
-- 
2.35.1

[PATCH v4 1/4] net: NC-SI setup and handling

[Joel Stanley]

From: Samuel Mendoza-Jonas 

Add the handling of NC-SI ethernet frames, and add a check at the start
of net_loop() to configure NC-SI before starting other network commands.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: Joel Stanley 
---
v4: split out cmd addition into a separate patch
v3:
 - Fix compilation. There were no configs that enabled the NCSI phy code
   so it had bitrotted
 - Use NCSI_PHY instead of CMD_NCSI so NCSI can work without the command
 - Add phy_interface_is_ncsi() helper, thanks Cédric for this suggestion
 - Only create NCSI phy device when driver is configured for it

 include/net.h  |  2 +-
 include/phy.h  |  2 ++
 drivers/net/phy/ncsi.c |  1 +
 drivers/net/phy/phy.c  |  9 -
 net/net.c  | 26 +-
 5 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/include/net.h b/include/net.h
index e3889a0bc85e..0681b8246323 100644
--- a/include/net.h
+++ b/include/net.h
@@ -558,7 +558,7 @@ extern int  net_restart_wrap;   /* Tried all 
network devices */
 
 enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
-   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP
+   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI
 };
 
 extern charnet_boot_file_name[1024];/* Boot File name */
diff --git a/include/phy.h b/include/phy.h
index b32959571069..1e0f8856f629 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -583,6 +583,8 @@ static inline bool phy_interface_is_sgmii(struct phy_device 
*phydev)
phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
 }
 
+bool phy_interface_is_ncsi(void);
+
 /* PHY UIDs for various PHYs that are referenced in external code */
 #define PHY_UID_CS4340 0x13e51002
 #define PHY_UID_CS4223 0x03e57003
diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
index bf1e832be9f1..bb7ecebed382 100644
--- a/drivers/net/phy/ncsi.c
+++ b/drivers/net/phy/ncsi.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1121b99abff5..d04538838852 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1026,7 +1026,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
addr,
 #endif
 
 #ifdef CONFIG_PHY_NCSI
-   if (!phydev)
+   if (!phydev && interface == PHY_INTERFACE_MODE_NCSI)
phydev = phy_device_create(bus, 0, PHY_NCSI_ID, false);
 #endif
 
@@ -1101,3 +1101,10 @@ int phy_modify(struct phy_device *phydev, int devad, int 
regnum, u16 mask,
 
return phy_write(phydev, devad, regnum, (ret & ~mask) | set);
 }
+
+bool phy_interface_is_ncsi(void)
+{
+   struct eth_pdata *pdata = dev_get_plat(eth_get_dev());
+
+   return pdata->phy_interface == PHY_INTERFACE_MODE_NCSI;
+}
diff --git a/net/net.c b/net/net.c
index 81905f631592..f0faf33d0d77 100644
--- a/net/net.c
+++ b/net/net.c
@@ -93,6 +93,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(CONFIG_CMD_PCAP)
 #include 
 #endif
@@ -410,6 +411,16 @@ int net_loop(enum proto_t protocol)
net_try_count = 1;
debug_cond(DEBUG_INT_STATE, "--- net_loop Entry\n");
 
+#ifdef CONFIG_PHY_NCSI
+   if (phy_interface_is_ncsi() && protocol != NCSI && !ncsi_active()) {
+   printf("%s: configuring NCSI first\n", __func__);
+   if (net_loop(NCSI) < 0)
+   return ret;
+   eth_init_state_only();
+   goto restart;
+   }
+#endif
+
bootstage_mark_name(BOOTSTAGE_ID_ETH_START, "eth_start");
net_init();
if (eth_is_on_demand_init()) {
@@ -526,6 +537,11 @@ restart:
case WOL:
wol_start();
break;
+#endif
+#if defined(CONFIG_PHY_NCSI)
+   case NCSI:
+   ncsi_probe_packages();
+   break;
 #endif
default:
break;
@@ -637,7 +653,7 @@ restart:
env_set_hex("filesize", net_boot_file_size);
env_set_hex("fileaddr", image_load_addr);
}
-   if (protocol != NETCONS)
+   if (protocol != NETCONS && protocol != NCSI)
eth_halt();
else
eth_halt_state_only();
@@ -1321,6 +1337,11 @@ void net_process_received_packet(uchar *in_packet, int 
len)
case PROT_WOL:
wol_receive(ip, len);
break;
+#endif
+#ifdef CONFIG_PHY_NCSI
+   case PROT_NCSI:
+   ncsi_receive(et, ip, len);
+   break;
 #endif
}
 }
@@ -1381,6 +1402,9 @@ common:
 
 #ifdef CONFIG_CMD_RARP
case RARP:
+#endif
+#ifdef CONFIG_PHY_NCSI
+   case NCSI:
 #endif
case BOOTP:
case CDP:
-- 
2.35.1

[PATCH v4 0/4] net: Enable NC-SI support

[Joel Stanley]

Back in 2019 Sam submitted NC-SI support. The NC-SI PHY driver was
merged (patches 1 and 2), but we never got around to merging patches 3
and 4:

 https://lore.kernel.org/u-boot/20190618013720.2823-1-...@mendozajonas.com/

Sam as long since moved on from working on the Aspeed BMCs, but the code
has been in use in the vendor fork for some time.

This refreshes his patches and enables support in the Aspeed defconfigs,
giving compile coverage to the NC-SI phy.

v4 splits the ncsi integration and cmd code into separate patches, and
adds r-b from Ramon and Cédric to patches 3 and 4.

Joel Stanley (1):
  config/aspeed: Enable NC-SI support

Samuel Mendoza-Jonas (3):
  net: NC-SI setup and handling
  cmd: Add ncsi command
  net/ftgmac100: Add NC-SI mode support

 include/net.h |  2 +-
 include/phy.h |  2 ++
 cmd/net.c | 22 ++
 drivers/net/ftgmac100.c   | 14 ++
 drivers/net/phy/ncsi.c|  1 +
 drivers/net/phy/phy.c |  9 -
 net/net.c | 27 ++-
 cmd/Kconfig   |  8 
 configs/evb-ast2500_defconfig |  2 ++
 configs/evb-ast2600_defconfig |  2 ++
 10 files changed, 82 insertions(+), 7 deletions(-)

-- 
2.35.1

Re: [PATCH] spl: opensbi: convert scratch options to config

[Anup Patel]

On Mon, Aug 8, 2022 at 3:58 PM Nikita Shubin  wrote:
>
> From: Nikita Shubin 
>
> Convert hardcoded "opensbi_info.options" to config provided value, this
> allows changing options passed to OpenSBI.
>
> SPL_OPENSBI_SCRATCH_OPTIONS is defaulted to SBI_SCRATCH_NO_BOOT_PRINTS.
>
> Link: 
> https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_dynamic.md
> Signed-off-by: Nikita Shubin 

Looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup

> ---
>  common/spl/Kconfig   | 8 
>  common/spl/spl_opensbi.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 2352fc9d6d..07c03d611d 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -1486,6 +1486,14 @@ config SPL_OPENSBI_LOAD_ADDR
> help
>   Load address of the OpenSBI binary.
>
> +config SPL_OPENSBI_SCRATCH_OPTIONS
> +   hex "Scratch options passed to OpenSBI"
> +   default 0x1
> +   depends on SPL_OPENSBI
> +   help
> + Options passed to fw_dynamic, for example 
> SBI_SCRATCH_NO_BOOT_PRINTS or
> + SBI_SCRATCH_DEBUG_PRINTS.
> +
>  config SPL_TARGET
> string "Addtional build targets for 'make'"
> default "spl/u-boot-spl.srec" if RCAR_GEN2
> diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> index 7fe0b5e158..b0f40076c3 100644
> --- a/common/spl/spl_opensbi.c
> +++ b/common/spl/spl_opensbi.c
> @@ -71,7 +71,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
> opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
> opensbi_info.next_addr = uboot_entry;
> opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
> -   opensbi_info.options = SBI_SCRATCH_NO_BOOT_PRINTS;
> +   opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
> opensbi_info.boot_hart = gd->arch.boot_hart;
>
> opensbi_entry = (void (*)(ulong, ulong, ulong))spl_image->entry_point;
> --
> 2.35.1
>

Re: [PATCH 2/3] binman: Remove header from compressed data

[Stefan Herbrechtsmeier]

Hi Simon,

Am 05.08.2022 um 18:48 schrieb Simon Glass:

Hi Stefan,

On Fri, 5 Aug 2022 at 01:51, Stefan Herbrechtsmeier
 wrote:


Hi Simon,

Am 04.08.2022 um 15:57 schrieb Simon Glass:

Hi Stefan,

On Thu, 4 Aug 2022 at 01:50, Stefan Herbrechtsmeier
 wrote:


Hi Simon,

Am 03.08.2022 um 20:14 schrieb Simon Glass:

Hi Stefan,

On Tue, 2 Aug 2022 at 07:45, Stefan Herbrechtsmeier
 wrote:


Hi Simon,

Am 02.08.2022 um 14:41 schrieb Simon Glass:

Hi Stefan,

On Tue, 2 Aug 2022 at 06:29, Stefan Herbrechtsmeier
 wrote:


From: Stefan Herbrechtsmeier 

Remove header from compressed data because this is uncommon, not
supported by U-Boot and incompatible with external compressed artifacts.

The header was introduced as part of commit eb0f4a4cb402 ("binman:
Support replacing data in a cbfs") to allow device tree entries to be
larger that the compressed contents. Regarding the commit "this is
necessary to cope with a compressed device tree being updated in such a
way that it shrinks after the entry size is already set (an obscure
case)". This case need to be fixed without influence the compressed data
by itself.


I was not able to find a way around this due to the chicken-and egg
problem. Compressed data has an unpredictable size and adding an extra
uncompressed byte may increase or decrease the compressed size.


Is it possible to use the `pad-after` attribute to record the unused
space. In this case it is possible to calculate the size of the
compressed data.


Well if you update that attribute it can change the size of the DTB
which is the chicken-and-egg problem again. As far as I know, if
people set the size of the region to something a bit larger than
needed, the problem is avoided. But the image generation does need to
be deterministic.


Does this means the size is only needed for the creation of the fitImage
and not for decompression in u-boot?


Possibly, but of course we cannot do that. As you say, U-Boot mainline
does not expect or support the header, at present.







Do you have a test for this use case?


There are various ones, e.g. testCompressDtb()


Thanks. Now I understand the problem and why you call it a
chicken-and-egg problem. It wasn't clear to me that the attributes are
inside the DTB.


OK good.



But I wonder how the decompression of the DTB works if the fitImage
implementation doesn't support the header.


It doesn't. Something needs to change here for compression to work.




So my solution was to add the header.


Is the header used outside of binman? I don't spot it in the decompress
fitImage implementation.


It is used in the Chromium OS verified boot implementation, but not elsewhere.





It is optional though, so can we perhaps have a property in the
description to enable it?


Is this header needed and supported outside of binman?

At the moment the header is incompatible and not well documented. It
took me some time to find out why my gzip compression via binman doesn't
work as expected because I assume a compatibility between binman
compress and fitImage decompress.


Yes I understand that, however you can pass a parameter to not include
the size value.


Do we need the header outside of the DTB? Otherwise we could handle this
special or we could add a special compression type.


It would also be possible to add a property to the image (top-level
section) that indicates whether this field is present, such property
to apply to the whole image. We could have it default to off, if you
like.


Do we really need the header outside of the DTB entry?


That's an interesting question. It is possible that we only need it if
DTB is present and is compressed. It should be possible to check this
by adjusting the tests and checking for failures.

But I am not sure it is a good idea, since it is wildly inconsistent.
I do prefer things to be deterministic - i.e.  you specify what you
want and you get it. If binman starts adopting obscure conventions it
could be confusing.


I add tests for gzip, lz4 and lzma_alone and all support padding at the
end and don't need the header. Even the testCompressDtb works without
the header. Furthermore I add bzip2, lzop, xz and zstd support to
bintool and only zstd doesn't support padding. Do we really need the
header or could we add an error if DTB is used together with zstd?


OK great!

Yes, I tried pretty hard to avoid it, but could not make it work.
Would you like me to take a look at the situations that spark it? It
might be around replacing things, too.

I really tried to avoid banning things, since it is such a pain and
confusing for people. But since this is error (and a corner case) I
think it would be fine to require a particular property to enable the
advanced functionality.


I have send a new version. Would be nice if you could check if you need 
the new attribute to append the length header.



Should I commit bzip2, lzop, xz and zstd support to bintool?


I have add the tools to the series. Maybe the test environment need an 
update to 

[PATCH v2 10/10] binman: Add zstd bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add zstd bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/btool/zstd.py | 30 ++
 tools/binman/comp_util.py  | 18 +-
 tools/binman/etype/blob_dtb.py |  4 
 tools/binman/ftest.py  |  3 ++-
 4 files changed, 45 insertions(+), 10 deletions(-)
 create mode 100644 tools/binman/btool/zstd.py

diff --git a/tools/binman/btool/zstd.py b/tools/binman/btool/zstd.py
new file mode 100644
index 00..299bd37126
--- /dev/null
+++ b/tools/binman/btool/zstd.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for zstd
+
+zstd allows compression and decompression of files.
+
+Documentation is available via::
+
+   man zstd
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolzstd(bintool.BintoolPacker):
+"""Compression/decompression using the zstd algorithm
+
+This bintool supports running `zstd` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man zstd
+"""
+def __init__(self, name):
+super().__init__(name)
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 35835450e2..0f15fae600 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,7 +11,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compressions
-COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz']
+COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz', 'zstd']
 
 bintools = {}
 
@@ -34,14 +34,14 @@ def compress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' 'lzop' and 'xz' tools.
-It also requires an output directory to be previously set up, by calling
-PrepareOutputDir().
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' 'lzop', 'xz' and 'zstd'
+tools. It also requires an output directory to be previously set up, by
+calling PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to compress
 algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma',
-'lzo' or 'xz')
+'lzo', 'xz' or 'zstd')
 
 Returns:
 bytes: Compressed data
@@ -62,14 +62,14 @@ def decompress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone', 'lzop' and 'xz' tools.
-It also requires an output directory to be previously set up, by calling
-PrepareOutputDir().
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone', 'lzop', 'xz' and 'zstd'
+tools. It also requires an output directory to be previously set up, by
+calling PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to decompress
 algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma',
-'lzo' or 'xz')
+'lzo', 'xz' or 'zstd')
 
 Returns:
 (bytes) Compressed data
diff --git a/tools/binman/etype/blob_dtb.py b/tools/binman/etype/blob_dtb.py
index 652b8abd8f..8d0b88d5b0 100644
--- a/tools/binman/etype/blob_dtb.py
+++ b/tools/binman/etype/blob_dtb.py
@@ -45,6 +45,10 @@ class Entry_blob_dtb(Entry_blob):
 def ProcessContents(self):
 """Re-read the DTB contents so that we get any calculated properties"""
 _, indata = state.GetFdtContents(self.GetFdtEtype())
+
+if self.compress == 'zstd' and self.prepend != 'length':
+self.Raise('The zstd compression requires a length header')
+
 data = self.CompressData(indata)
 if self.prepend == 'length':
 hdr = struct.pack('

[PATCH v2 09/10] binman: Add xz bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add xz bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/btool/xz.py  | 31 +++
 tools/binman/comp_util.py | 18 +-
 2 files changed, 40 insertions(+), 9 deletions(-)
 create mode 100644 tools/binman/btool/xz.py

diff --git a/tools/binman/btool/xz.py b/tools/binman/btool/xz.py
new file mode 100644
index 00..e2b413d18b
--- /dev/null
+++ b/tools/binman/btool/xz.py
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for xz
+
+xz allows compression and decompression of files.
+
+Documentation is available via::
+
+   man xz
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolxz(bintool.BintoolPacker):
+"""Compression/decompression using the xz algorithm
+
+This bintool supports running `xz` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man xz
+"""
+def __init__(self, name):
+super().__init__(name, fetch_package='xz-utils',
+ version_regex=r'xz \(XZ Utils\) ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index e7cba23aa8..35835450e2 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,7 +11,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compressions
-COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo']
+COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz']
 
 bintools = {}
 
@@ -34,14 +34,14 @@ def compress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' and 'lzop' tools. It
-also requires an output directory to be previously set up, by calling
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' 'lzop' and 'xz' tools.
+It also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to compress
-algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma' or
-'lzo')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma',
+'lzo' or 'xz')
 
 Returns:
 bytes: Compressed data
@@ -62,14 +62,14 @@ def decompress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' and 'lzop' tools. It
-also requires an output directory to be previously set up, by calling
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone', 'lzop' and 'xz' tools.
+It also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to decompress
-algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma' or
-'lzo')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma',
+'lzo' or 'xz')
 
 Returns:
 (bytes) Compressed data
-- 
2.30.2

[PATCH v2 08/10] binman: Add lzop bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add lzop bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/btool/lzop.py | 30 ++
 tools/binman/comp_util.py  | 18 ++
 2 files changed, 40 insertions(+), 8 deletions(-)
 create mode 100644 tools/binman/btool/lzop.py

diff --git a/tools/binman/btool/lzop.py b/tools/binman/btool/lzop.py
new file mode 100644
index 00..f6903b4db7
--- /dev/null
+++ b/tools/binman/btool/lzop.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for lzop
+
+lzop allows compression and decompression of files.
+
+Documentation is available via::
+
+   man lzop
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoollzop(bintool.BintoolPacker):
+"""Compression/decompression using the lzop algorithm
+
+This bintool supports running `lzop` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man lzop
+"""
+def __init__(self, name):
+super().__init__(name, 'lzo', compress_args=[])
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 4fbd80e2ff..e7cba23aa8 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,12 +11,12 @@ from binman import bintool
 from patman import tools
 
 # Supported compressions
-COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma']
+COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo']
 
 bintools = {}
 
 def _get_tool_name(algo):
-names = {'lzma': 'lzma_alone'}
+names = {'lzma': 'lzma_alone', 'lzo': 'lzop'}
 return names.get(algo, algo)
 
 def _get_tool(algo):
@@ -34,13 +34,14 @@ def compress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4' and 'lzma_alone' tools. It also
-requires an output directory to be previously set up, by calling
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' and 'lzop' tools. It
+also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to compress
-algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma' or
+'lzo')
 
 Returns:
 bytes: Compressed data
@@ -61,13 +62,14 @@ def decompress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'gzip', 'lz4' and 'lzma_alone' tools. It also
-requires an output directory to be previously set up, by calling
+This requires 'bzip2', 'gzip', 'lz4', 'lzma_alone' and 'lzop' tools. It
+also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to decompress
-algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4', 'lzma' or
+'lzo')
 
 Returns:
 (bytes) Compressed data
-- 
2.30.2

[PATCH v2 05/10] binman: Add BintoolPacker class to bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add a bintools base class for packers which compression / decompression
entry contents.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/bintool.py | 94 +
 1 file changed, 94 insertions(+)

diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 8435b29749..1d22962790 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright 2022 Google LLC
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
 #
 """Base class for all bintools
 
@@ -464,3 +466,95 @@ binaries. It is fairly easy to create new bintools. Just 
add a new file to the
 str: Version string for this bintool
 """
 return 'unknown'
+
+class BintoolPacker(Bintool):
+"""Tool which compression / decompression entry contents
+
+This is a bintools base class for compression / decompression packer
+"""
+def __init__(self, name, compression=None, compress_args=None,
+ decompress_args=None, fetch_package=None,
+ version_regex=r'(v[0-9.]+)'):
+desc = '%s compression' % (compression if compression else name)
+super().__init__(name, desc)
+if compress_args is None:
+compress_args = ['--compress']
+self.compress_args = compress_args
+if decompress_args is None:
+decompress_args = ['--decompress']
+self.decompress_args = decompress_args
+if fetch_package is None:
+fetch_package = name
+self.fetch_package = fetch_package
+self.version_regex = version_regex
+
+def compress(self, indata):
+"""Compress data
+
+Args:
+indata (bytes): Data to compress
+
+Returns:
+bytes: Compressed data
+"""
+with tempfile.NamedTemporaryFile(prefix='comp.tmp',
+ dir=tools.get_output_dir()) as tmp:
+tools.write_file(tmp.name, indata)
+args = self.compress_args + ['--stdout', tmp.name]
+return self.run_cmd(*args, binary=True)
+
+def decompress(self, indata):
+"""Decompress data
+
+Args:
+indata (bytes): Data to decompress
+
+Returns:
+bytes: Decompressed data
+"""
+with tempfile.NamedTemporaryFile(prefix='decomp.tmp',
+ dir=tools.get_output_dir()) as inf:
+tools.write_file(inf.name, indata)
+args = self.decompress_args + ['--stdout', inf.name]
+return self.run_cmd(*args, binary=True)
+
+def fetch(self, method):
+"""Fetch handler
+
+This installs the gzip package using the apt utility.
+
+Args:
+method (FETCH_...): Method to use
+
+Returns:
+True if the file was fetched and now installed, None if a method
+other than FETCH_BIN was requested
+
+Raises:
+Valuerror: Fetching could not be completed
+"""
+if method != FETCH_BIN:
+return None
+pkg = self.fetch_package if self.fetch_package else self.name
+return self.apt_install(pkg)
+
+def version(self):
+"""Version handler
+
+Returns:
+str: Version number
+"""
+import re
+
+result = self.run_cmd_result('-V')
+if not result:
+return super().version()
+
+out = result.stdout.strip()
+if not out:
+out = result.stderr.strip()
+if not out:
+return super().version()
+
+m_version = re.search(self.version_regex, out)
+return m_version.group(1) if m_version else out
-- 
2.30.2

[PATCH v2 06/10] binman: Add bzip2 bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add bzip2 bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/btool/bzip2.py | 30 ++
 tools/binman/comp_util.py   | 14 +++---
 2 files changed, 37 insertions(+), 7 deletions(-)
 create mode 100644 tools/binman/btool/bzip2.py

diff --git a/tools/binman/btool/bzip2.py b/tools/binman/btool/bzip2.py
new file mode 100644
index 00..9be87a621f
--- /dev/null
+++ b/tools/binman/btool/bzip2.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for bzip2
+
+bzip2 allows compression and decompression of files.
+
+Documentation is available via::
+
+   man bzip2
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolbzip2(bintool.BintoolPacker):
+"""Compression/decompression using the bzip2 algorithm
+
+This bintool supports running `bzip2` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man bzip2
+"""
+def __init__(self, name):
+super().__init__(name, version_regex=r'bzip2.*Version ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index faa08a7f8a..fa75911e58 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,7 +11,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compressions
-COMPRESSIONS = ['lz4', 'lzma']
+COMPRESSIONS = ['bzip2', 'lz4', 'lzma']
 
 bintools = {}
 
@@ -34,12 +34,12 @@ def compress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'lz4' and 'lzma_alone' tools. It also requires an output
-directory to be previously set up, by calling PrepareOutputDir().
+This requires 'bzip2', 'lz4' and 'lzma_alone' tools. It also requires an
+output directory to be previously set up, by calling PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to compress
-algo (str): Algorithm to use ('none', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'lz4' or 'lzma')
 
 Returns:
 bytes: Compressed data
@@ -60,12 +60,12 @@ def decompress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'lz4' and 'lzma_alone' tools. It also requires an output
-directory to be previously set up, by calling PrepareOutputDir().
+This requires 'bzip2', 'lz4' and 'lzma_alone' tools. It also requires an
+output directory to be previously set up, by calling PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to decompress
-algo (str): Algorithm to use ('none', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'lz4' or 'lzma')
 
 Returns:
 (bytes) Compressed data
-- 
2.30.2

[PATCH v2 07/10] binman: Add gzip bintool

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add gzip bintool to binman to support on-the-fly compression of Linux
kernel images and FPGA bitstreams. The SPL basic fitImage implementation
supports only gzip decompression.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/btool/gzip.py | 31 +++
 tools/binman/comp_util.py  | 16 +---
 2 files changed, 40 insertions(+), 7 deletions(-)
 create mode 100644 tools/binman/btool/gzip.py

diff --git a/tools/binman/btool/gzip.py b/tools/binman/btool/gzip.py
new file mode 100644
index 00..0d75028120
--- /dev/null
+++ b/tools/binman/btool/gzip.py
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for gzip
+
+gzip allows compression and decompression of files.
+
+Documentation is available via::
+
+   man gzip
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolgzip(bintool.BintoolPacker):
+"""Compression/decompression using the gzip algorithm
+
+This bintool supports running `gzip` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man gzip
+"""
+def __init__(self, name):
+super().__init__(name, compress_args=[],
+ version_regex=r'gzip ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index fa75911e58..4fbd80e2ff 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,7 +11,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compressions
-COMPRESSIONS = ['bzip2', 'lz4', 'lzma']
+COMPRESSIONS = ['bzip2', 'gzip', 'lz4', 'lzma']
 
 bintools = {}
 
@@ -34,12 +34,13 @@ def compress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'lz4' and 'lzma_alone' tools. It also requires an
-output directory to be previously set up, by calling PrepareOutputDir().
+This requires 'bzip2', 'gzip', 'lz4' and 'lzma_alone' tools. It also
+requires an output directory to be previously set up, by calling
+PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to compress
-algo (str): Algorithm to use ('none', 'bzip2', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4' or 'lzma')
 
 Returns:
 bytes: Compressed data
@@ -60,12 +61,13 @@ def decompress(indata, algo):
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
 
-This requires 'bzip2', 'lz4' and 'lzma_alone' tools. It also requires an
-output directory to be previously set up, by calling PrepareOutputDir().
+This requires 'bzip2', 'gzip', 'lz4' and 'lzma_alone' tools. It also
+requires an output directory to be previously set up, by calling
+PrepareOutputDir().
 
 Args:
 indata (bytes): Input data to decompress
-algo (str): Algorithm to use ('none', 'bzip2', 'lz4' or 'lzma')
+algo (str): Algorithm to use ('none', 'bzip2', 'gzip', 'lz4' or 'lzma')
 
 Returns:
 (bytes) Compressed data
-- 
2.30.2

[PATCH v2 04/10] binman: Add compression tests

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Add common test functions to test all supported compressions.

Signed-off-by: Stefan Herbrechtsmeier 

---
Instead of the for loop it is possible to use Parameterized [1] testing.

[1] https://github.com/wolever/parameterized

Changes in v2:
- Added

 tools/binman/ftest.py | 24 
 1 file changed, 24 insertions(+)

diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 96c15cff77..c9b67c48d6 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -5248,6 +5248,30 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 comp_util.decompress(b'1234', 'invalid')
 self.assertIn("Unknown algorithm 'invalid'", str(e.exception))
 
+def testCompressions(self):
+"""Test compression algorithms"""
+for algo in comp_util.COMPRESSIONS:
+data = comp_util.compress(COMPRESS_DATA, algo)
+self.assertNotEqual(COMPRESS_DATA, data)
+orig = comp_util.decompress(data, algo)
+self.assertEquals(COMPRESS_DATA, orig)
+
+def testVersions(self):
+"""Test tool version of compression algorithms"""
+for algo in comp_util.COMPRESSIONS:
+tool = comp_util._get_tool(algo)
+version = tool.version()
+print('%s - %s' % (algo, version))
+self.assertRegex(version, '^v?[0-9]+[0-9.]*')
+
+def testPadding(self):
+"""Test padding of compression algorithms"""
+for algo in comp_util.COMPRESSIONS:
+data = comp_util.compress(COMPRESS_DATA, algo)
+data = data + bytes([0]) * 64
+orig = comp_util.decompress(data, algo)
+self.assertEquals(COMPRESS_DATA, orig)
+
 def testBintoolDocs(self):
 """Test for creation of bintool documentation"""
 with test_util.capture_sys_output() as (stdout, stderr):
-- 
2.30.2

[PATCH v2 03/10] binman: Simplify comp_util class

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Simplify the comp_util class by remove duplicate code as preparation for
additional compress algorithms.

Signed-off-by: Stefan Herbrechtsmeier 
---

(no changes since v1)

 tools/binman/cbfs_util_test.py |  2 +-
 tools/binman/comp_util.py  | 46 +++---
 tools/binman/ftest.py  |  2 +-
 3 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/tools/binman/cbfs_util_test.py b/tools/binman/cbfs_util_test.py
index f86b295149..44ebd04278 100755
--- a/tools/binman/cbfs_util_test.py
+++ b/tools/binman/cbfs_util_test.py
@@ -50,7 +50,7 @@ class TestCbfs(unittest.TestCase):
 cls.cbfstool = bintool.Bintool.create('cbfstool')
 cls.have_cbfstool = cls.cbfstool.is_present()
 
-cls.have_lz4 = comp_util.HAVE_LZ4
+cls.have_lz4 = comp_util.is_present('lz4')
 
 @classmethod
 def tearDownClass(cls):
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 269bbf7975..faa08a7f8a 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright 2022 Google LLC
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
 #
 """Utilities to compress and decompress data"""
 
@@ -8,12 +10,23 @@ import tempfile
 from binman import bintool
 from patman import tools
 
-LZ4 = bintool.Bintool.create('lz4')
-HAVE_LZ4 = LZ4.is_present()
+# Supported compressions
+COMPRESSIONS = ['lz4', 'lzma']
 
-LZMA_ALONE = bintool.Bintool.create('lzma_alone')
-HAVE_LZMA_ALONE = LZMA_ALONE.is_present()
+bintools = {}
 
+def _get_tool_name(algo):
+names = {'lzma': 'lzma_alone'}
+return names.get(algo, algo)
+
+def _get_tool(algo):
+global bintools
+name = _get_tool_name(algo)
+tool = bintools.get(name)
+if not tool:
+tool = bintool.Bintool.create(name)
+bintools[name] = tool
+return tool
 
 def compress(indata, algo):
 """Compress some data using a given algorithm
@@ -33,13 +46,12 @@ def compress(indata, algo):
 """
 if algo == 'none':
 return indata
-if algo == 'lz4':
-data = LZ4.compress(indata)
-# cbfstool uses a very old version of lzma
-elif algo == 'lzma':
-data = LZMA_ALONE.compress(indata)
-else:
+if algo not in COMPRESSIONS:
 raise ValueError("Unknown algorithm '%s'" % algo)
+
+tool = _get_tool(algo)
+data = tool.compress(indata)
+
 return data
 
 def decompress(indata, algo):
@@ -60,10 +72,14 @@ def decompress(indata, algo):
 """
 if algo == 'none':
 return indata
-if algo == 'lz4':
-data = LZ4.decompress(indata)
-elif algo == 'lzma':
-data = LZMA_ALONE.decompress(indata)
-else:
+if algo not in COMPRESSIONS:
 raise ValueError("Unknown algorithm '%s'" % algo)
+
+tool = _get_tool(algo)
+data = tool.decompress(indata)
+
 return data
+
+def is_present(algo):
+ tool = _get_tool(algo)
+ return tool.is_present()
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 057b4e28b7..96c15cff77 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -212,7 +212,7 @@ class TestFunctional(unittest.TestCase):
 TestFunctional._MakeInputFile('tee.elf',
 tools.read_file(cls.ElfTestFile('elf_sections')))
 
-cls.have_lz4 = comp_util.HAVE_LZ4
+cls.have_lz4 = comp_util.is_present('lz4')
 
 @classmethod
 def tearDownClass(cls):
-- 
2.30.2

[PATCH v2 02/10] binman: Make compressed data header optional

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Move the compressed data header handling into the dtb blob entry class
and make it optional. The header is uncommon, not supported by U-Boot
and incompatible with external compressed artifacts.

If needed the header could be enabled with the following
attribute beside the compress attribute:
  prepend = "length";

The header was introduced as part of commit eb0f4a4cb402 ("binman:
Support replacing data in a cbfs") to allow device tree entries to be
larger that the compressed contents. Regarding the commit "this is
necessary to cope with a compressed device tree being updated in such a
way that it shrinks after the entry size is already set (an obscure
case)". This case need to be fixed without influence any compressed data
by itself.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Reworked to make the feature optional.

 tools/binman/cbfs_util.py |  8 ++---
 tools/binman/comp_util.py | 11 ++
 tools/binman/entries.rst  |  4 +++
 tools/binman/entry.py |  2 +-
 tools/binman/etype/blob_dtb.py| 21 
 tools/binman/ftest.py | 34 ---
 .../test/235_compress_prepend_length_dtb.dts  | 17 ++
 7 files changed, 78 insertions(+), 19 deletions(-)
 create mode 100644 tools/binman/test/235_compress_prepend_length_dtb.dts

diff --git a/tools/binman/cbfs_util.py b/tools/binman/cbfs_util.py
index 9cad03886f..a1836f4ad3 100644
--- a/tools/binman/cbfs_util.py
+++ b/tools/binman/cbfs_util.py
@@ -241,9 +241,9 @@ class CbfsFile(object):
 """Handle decompressing data if necessary"""
 indata = self.data
 if self.compress == COMPRESS_LZ4:
-data = comp_util.decompress(indata, 'lz4', with_header=False)
+data = comp_util.decompress(indata, 'lz4')
 elif self.compress == COMPRESS_LZMA:
-data = comp_util.decompress(indata, 'lzma', with_header=False)
+data = comp_util.decompress(indata, 'lzma')
 else:
 data = indata
 self.memlen = len(data)
@@ -362,9 +362,9 @@ class CbfsFile(object):
 elif self.ftype == TYPE_RAW:
 orig_data = data
 if self.compress == COMPRESS_LZ4:
-data = comp_util.compress(orig_data, 'lz4', with_header=False)
+data = comp_util.compress(orig_data, 'lz4')
 elif self.compress == COMPRESS_LZMA:
-data = comp_util.compress(orig_data, 'lzma', with_header=False)
+data = comp_util.compress(orig_data, 'lzma')
 self.memlen = len(orig_data)
 self.data_len = len(data)
 attr = struct.pack(ATTR_COMPRESSION_FORMAT,
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index dc76adab35..269bbf7975 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -3,7 +3,6 @@
 #
 """Utilities to compress and decompress data"""
 
-import struct
 import tempfile
 
 from binman import bintool
@@ -16,7 +15,7 @@ LZMA_ALONE = bintool.Bintool.create('lzma_alone')
 HAVE_LZMA_ALONE = LZMA_ALONE.is_present()
 
 
-def compress(indata, algo, with_header=True):
+def compress(indata, algo):
 """Compress some data using a given algorithm
 
 Note that for lzma this uses an old version of the algorithm, not that
@@ -41,12 +40,9 @@ def compress(indata, algo, with_header=True):
 data = LZMA_ALONE.compress(indata)
 else:
 raise ValueError("Unknown algorithm '%s'" % algo)
-if with_header:
-hdr = struct.pack(';
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-dtb {
+   compress = "lz4";
+   prepend = "length";
+   };
+   };
+};
-- 
2.30.2

[PATCH v2 01/10] binman: Skip elf tests if python elftools is not available

[Stefan Herbrechtsmeier]

From: Stefan Herbrechtsmeier 

Skip tests which requires python elftools if the tool is not available.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v2:
- Added

 tools/binman/elf_test.py | 14 ++
 tools/binman/ftest.py| 18 ++
 2 files changed, 32 insertions(+)

diff --git a/tools/binman/elf_test.py b/tools/binman/elf_test.py
index 5a51c64cfe..75b867c2be 100644
--- a/tools/binman/elf_test.py
+++ b/tools/binman/elf_test.py
@@ -122,6 +122,8 @@ class TestElf(unittest.TestCase):
 
 def testOutsideFile(self):
 """Test a symbol which extends outside the entry area is detected"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(10)
 section = FakeSection()
 elf_fname = self.ElfTestFile('u_boot_binman_syms')
@@ -147,6 +149,8 @@ class TestElf(unittest.TestCase):
 Only 32 and 64 bits are supported, since we need to store an offset
 into the image.
 """
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(10)
 section = FakeSection()
 elf_fname =self.ElfTestFile('u_boot_binman_syms_size')
@@ -161,6 +165,8 @@ class TestElf(unittest.TestCase):
 This should produce -1 values for all thress symbols, taking up the
 first 16 bytes of the image.
 """
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(28)
 section = FakeSection(sym_value=None)
 elf_fname = self.ElfTestFile('u_boot_binman_syms')
@@ -172,6 +178,8 @@ class TestElf(unittest.TestCase):
 
 def testDebug(self):
 """Check that enabling debug in the elf module produced debug output"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 try:
 tout.init(tout.DEBUG)
 entry = FakeEntry(24)
@@ -281,6 +289,8 @@ class TestElf(unittest.TestCase):
 
 def test_read_segments_bad_data(self):
 """Test for read_loadable_segments() with an invalid ELF file"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('embed_data')
 with self.assertRaises(ValueError) as e:
 elf.read_loadable_segments(tools.get_bytes(100, 100))
@@ -288,6 +298,8 @@ class TestElf(unittest.TestCase):
 
 def test_get_file_offset(self):
 """Test GetFileOffset() gives the correct file offset for a symbol"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('embed_data')
 syms = elf.GetSymbols(fname, ['embed'])
 addr = syms['embed'].address
@@ -314,6 +326,8 @@ class TestElf(unittest.TestCase):
 
 def test_get_symbol_from_address(self):
 """Test GetSymbolFromAddress()"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('elf_sections')
 sym_name = 'calculate'
 syms = elf.GetSymbols(fname, [sym_name])
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index fa1f421c05..da9aa9e679 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -4807,6 +4807,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElf(self):
 """Test that we can update the devicetree in an ELF file"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
 outfile = os.path.join(self._indir, 'u-boot.out')
 begin_sym = 'dtb_embed_begin'
@@ -4858,6 +4860,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElfNoSyms(self):
 """Test that missing symbols are detected with --update-fdt-in-elf"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
 outfile = ''
 begin_sym = 'wrong_begin'
@@ -4871,6 +4875,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElfTooSmall(self):
 """Test that an over-large dtb is detected with --update-fdt-in-elf"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed_sm')
 outfile = os.path.join(self._indir, 'u-boot.out')
 begin_sym = 'dtb_embed_begin'
@@ -5344,6 +5350,8 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 
 def testFitSplitElf(self):
 """Test an image with an FIT with an split-elf operation"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry_args = {
 'of-list': 'test-fdt1 test-fdt2',
 

[PATCH] spl: opensbi: convert scratch options to config

[Nikita Shubin]

From: Nikita Shubin 

Convert hardcoded "opensbi_info.options" to config provided value, this
allows changing options passed to OpenSBI.

SPL_OPENSBI_SCRATCH_OPTIONS is defaulted to SBI_SCRATCH_NO_BOOT_PRINTS.

Link: 
https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_dynamic.md
Signed-off-by: Nikita Shubin 
---
 common/spl/Kconfig   | 8 
 common/spl/spl_opensbi.c | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 2352fc9d6d..07c03d611d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1486,6 +1486,14 @@ config SPL_OPENSBI_LOAD_ADDR
help
  Load address of the OpenSBI binary.
 
+config SPL_OPENSBI_SCRATCH_OPTIONS
+   hex "Scratch options passed to OpenSBI"
+   default 0x1
+   depends on SPL_OPENSBI
+   help
+ Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS 
or
+ SBI_SCRATCH_DEBUG_PRINTS.
+
 config SPL_TARGET
string "Addtional build targets for 'make'"
default "spl/u-boot-spl.srec" if RCAR_GEN2
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 7fe0b5e158..b0f40076c3 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -71,7 +71,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
opensbi_info.next_addr = uboot_entry;
opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
-   opensbi_info.options = SBI_SCRATCH_NO_BOOT_PRINTS;
+   opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
opensbi_info.boot_hart = gd->arch.boot_hart;
 
opensbi_entry = (void (*)(ulong, ulong, ulong))spl_image->entry_point;
-- 
2.35.1

[PATCH] spl: opensbi: fix typo

[Nikita Shubin]

From: Nikita Shubin 

s/obensbi_info/opensbi_info/

Signed-off-by: Nikita Shubin 
---
 common/spl/spl_opensbi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 1c0abf8553..7fe0b5e158 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -66,7 +66,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
if (ret)
ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, 
_entry);
 
-   /* Prepare obensbi_info object */
+   /* Prepare opensbi_info object */
opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE;
opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
opensbi_info.next_addr = uboot_entry;
-- 
2.35.1

Re: [PATCH] misc: atsha204a: Don't check for error when waking up the device

[Paweł Anikiel]

Hi Pali,

I applied the patch and it works fine on my board. Log from atsha204a_wakeup():
  Waking up ATSHA204A
  Try 1... success

Tested-by: Paweł Anikiel 

Regards,
Paweł

On Sun, Aug 7, 2022 at 9:30 PM Pali Rohár  wrote:
>
> Paweł, could you please test this change if it works on your board? I
> was that you were fixing another wakeup issue in patch "misc: atsha204a:
> Increase wake delay by tWHI".
>
> On Thursday 04 August 2022 13:03:44 Pali Rohár wrote:
> > The device ignores any levels or transitions on the SCL pin when the device
> > is idle, asleep or during waking up.
> >
> > Linux kernel driver for atsha204a (atmel-sha204a.ko) also ignores return
> > value from i2c wakeup send command, see:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/atmel-i2c.c?h=v5.19#n174
> >
> > And also userspace Turris libatsha204 library ignores return value from
> > wakeup send command, see:
> > https://gitlab.nic.cz/turris/libatsha204/-/blob/v29.2/src/libatsha204/layer_ni2c.c#L75-76
> >
> > U-Boot driver should do same thing.
> >
> > Fixes waking up ATSHA204 on Turris 1.x boards.
> >
> > Signed-off-by: Pali Rohár 
> > ---
> >  drivers/misc/atsha204a-i2c.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/misc/atsha204a-i2c.c b/drivers/misc/atsha204a-i2c.c
> > index 81ecb5b6177b..fa2d5948f128 100644
> > --- a/drivers/misc/atsha204a-i2c.c
> > +++ b/drivers/misc/atsha204a-i2c.c
> > @@ -103,12 +103,13 @@ int atsha204a_wakeup(struct udevice *dev)
> >   for (try = 1; try <= 10; ++try) {
> >   debug("Try %i... ", try);
> >
> > + /*
> > +  * The device ignores any levels or transitions on the SCL pin
> > +  * when the device is idle, asleep or during waking up.
> > +  * Don't check for error when waking up the device.
> > +  */
> >   memset(req, 0, 4);
> > - res = atsha204a_send(dev, req, 4);
> > - if (res) {
> > - debug("failed on I2C send, trying again\n");
> > - continue;
> > - }
> > + atsha204a_send(dev, req, 4);
> >
> >   udelay(ATSHA204A_TWLO_US + ATSHA204A_TWHI_US);
> >
> > --
> > 2.20.1
> >

Re: [PATCH 1/1] usb: storage: stop probe on "Invalid device"

[Simon Glass]

Hi Takahiro,

On Sun, 7 Aug 2022 at 20:18, AKASHI Takahiro 
wrote:
>
> Hi Simon,
>
> On Sun, Aug 07, 2022 at 09:47:56AM -0600, Simon Glass wrote:
> > Hi Marek,
> >
> > On Thu, 21 Jul 2022 at 11:29, Janne Grunau  wrote:
> > >
> > > Fixes a crash during probing of sd card readers without medium
present.
> > >
> > > Link: https://github.com/AsahiLinux/linux/issues/44
> > > Signed-off-by: Janne Grunau 
> > > ---
> > >  common/usb_storage.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > Reviewed-by: Simon Glass 
>
> I made this comment on another bug report:
> https://lists.denx.de/pipermail/u-boot/2022-July/489717.html
>
> I think we should continue to scan the *bus* even if detecting/activating
> a specific device fails.
>
> Moreover, we would better do full recovery from blk_create_device(f)()
> as it has some side-effects, including an increased "devnum".

OK I didn't see that. Can you please send an alternative patch?

>
> -Takahiro Akashi
>
> > Shall I pick this one up?

Regards,
Simon

Re: [PATCH v3 1/3] net: NC-SI setup and handling

[Ramon Fried]

On Mon, Aug 8, 2022 at 9:18 AM Joel Stanley  wrote:
>
> On Sat, 6 Aug 2022 at 23:54, Ramon Fried  wrote:
> >
> > On Mon, Jul 4, 2022 at 11:20 AM Cédric Le Goater  wrote:
> > >
> > > On 7/4/22 09:58, Joel Stanley wrote:
> > > > From: Samuel Mendoza-Jonas 
> > > >
> > > > Add the handling of NC-SI ethernet frames, and add a check at the start
> > > > of net_loop() to configure NC-SI before starting other network commands.
> > > > This also adds an "ncsi" command to manually start NC-SI configuration.
> > > >
> > > > Signed-off-by: Samuel Mendoza-Jonas 
> > > > Signed-off-by: Joel Stanley 
> > >
> > >
> > > Reviewed-by: Cédric Le Goater 
> > >
> > > Thanks,
> > >
> > > C.
> > >
> > > > ---
> > > > v3:
> > > >   - Fix compilation. There were no configs that enabled the NCSI phy 
> > > > code
> > > > so it had bitrotted
> > > >   - Use NCSI_PHY instead of CMD_NCSI so NCSI can work without the 
> > > > command
> > > >   - Add phy_interface_is_ncsi() helper, thanks Cédric for this 
> > > > suggestion
> > > >   - Only create NCSI phy device when driver is configured for it
> > > >
> > > >   include/net.h  |  2 +-
> > > >   include/phy.h  |  2 ++
> > > >   cmd/net.c  | 22 ++
> > > >   drivers/net/phy/ncsi.c |  1 +
> > > >   drivers/net/phy/phy.c  |  9 -
> > > >   net/net.c  | 27 ++-
> > > >   cmd/Kconfig|  8 
> > > >   7 files changed, 68 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/net.h b/include/net.h
> > > > index e3889a0bc85e..0681b8246323 100644
> > > > --- a/include/net.h
> > > > +++ b/include/net.h
> > > > @@ -558,7 +558,7 @@ extern intnet_restart_wrap;   
> > > > /* Tried all network devices */
> > > >
> > > >   enum proto_t {
> > > >   BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, 
> > > > SNTP,
> > > > - TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP
> > > > + TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI
> > > >   };
> > > >
> > > >   extern char net_boot_file_name[1024];/* Boot File name */
> > > > diff --git a/include/phy.h b/include/phy.h
> > > > index b32959571069..1e0f8856f629 100644
> > > > --- a/include/phy.h
> > > > +++ b/include/phy.h
> > > > @@ -583,6 +583,8 @@ static inline bool phy_interface_is_sgmii(struct 
> > > > phy_device *phydev)
> > > >   phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
> > > >   }
> > > >
> > > > +bool phy_interface_is_ncsi(void);
> > > > +
> > > >   /* PHY UIDs for various PHYs that are referenced in external code */
> > > >   #define PHY_UID_CS4340  0x13e51002
> > > >   #define PHY_UID_CS4223  0x03e57003
> > > > diff --git a/cmd/net.c b/cmd/net.c
> > > > index 3619c843d838..2863fe768118 100644
> > > > --- a/cmd/net.c
> > > > +++ b/cmd/net.c
> > > > @@ -16,6 +16,7 @@
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > +#include 
> > > >
> > > >   static int netboot_common(enum proto_t, struct cmd_tbl *, int, char * 
> > > > const []);
> > > >
> > > > @@ -524,3 +525,24 @@ U_BOOT_CMD(
> > > >   "list - list available devices\n"
> > > >   );
> > > >   #endif // CONFIG_DM_ETH
> > > > +
> > > > +#if defined(CONFIG_CMD_NCSI)
> > > > +static int do_ncsi(struct cmd_tbl *cmdtp, int flag, int argc, char * 
> > > > const argv[])
> > > > +{
> > > > + if (!phy_interface_is_ncsi() || !ncsi_active()) {
> > > > + printf("Device not configured for NC-SI\n");
> > > > + return CMD_RET_FAILURE;
> > > > + }
> > > > +
> > > > + if (net_loop(NCSI) < 0)
> > > > + return CMD_RET_FAILURE;
> > > > +
> > > > + return CMD_RET_SUCCESS;
> > > > +}
> > > > +
> > > > +U_BOOT_CMD(
> > > > + ncsi,   1,  1,  do_ncsi,
> > > > + "Configure attached NIC via NC-SI",
> > > > + ""
> > > > +);
> > > > +#endif  /* CONFIG_CMD_NCSI */
> > > > diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
> > > > index bf1e832be9f1..bb7ecebed382 100644
> > > > --- a/drivers/net/phy/ncsi.c
> > > > +++ b/drivers/net/phy/ncsi.c
> > > > @@ -9,6 +9,7 @@
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > +#include 
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> > > > index 1121b99abff5..d04538838852 100644
> > > > --- a/drivers/net/phy/phy.c
> > > > +++ b/drivers/net/phy/phy.c
> > > > @@ -1026,7 +1026,7 @@ struct phy_device *phy_connect(struct mii_dev 
> > > > *bus, int addr,
> > > >   #endif
> > > >
> > > >   #ifdef CONFIG_PHY_NCSI
> > > > - if (!phydev)
> > > > + if (!phydev && interface == PHY_INTERFACE_MODE_NCSI)
> > > >   phydev = phy_device_create(bus, 0, PHY_NCSI_ID, false);
> > > >   #endif
> > > >
> > > > @@ -1101,3 +1101,10 @@ int phy_modify(struct phy_device *phydev, int 
> > > > devad, int regnum, u16 mask,
> > > >
> > > >   return phy_write(phydev, devad, regnum, (ret 

Re: [PATCH] ARM: meson: fixup error on efuse commands return

[Neil Armstrong]

Hi,

On Thu, 4 Aug 2022 16:41:38 +0200, Jerome Brunet wrote:
> All `sm efuseread/efusewrite` commands exit with an error, even if the fuse
> have actually been dealt with correctly.
> 
> This is because the smc call return the size it actually processed but this
> result is checked against 0.
> 
> Return failure in do_efuse_read/write if the return value of
> meson_sm_read/write_efuse() is not the requested size.
> 
> [...]

Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic 
(u-boot-amlogic-test)

[1/1] ARM: meson: fixup error on efuse commands return
  
https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/3145e0d0ff0837647351f2ca261b4cde779f83e0

-- 
Neil

Re: [PATCH 13/23] blk: Hide the BLK and SPL_LEGACY_BLOCK options

[Heinrich Schuchardt]

On 8/7/22 17:46, Simon Glass wrote:

We don't want boards to be able to change these. They can be handled
as dependencies of options that need them, such as SPL_MMC. There is no
point in enabling the block interface without any storage devices to
create a block device.

Hide both options from the 'menuconfig' display and deny their use in
defconfig files.

Signed-off-by: Simon Glass 
---

  drivers/block/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 7bd37f760ca..b8ed3ef8d1f 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -1,5 +1,5 @@
  config BLK
-   bool "Support block devices"
+   bool # "Support block devices"


This needs be merged into patch 3 to avoid misconfigurations when
applying only patch 1-3.

Best regards

Heinrich


depends on DM
default y if MMC || USB || SCSI || NVME || IDE || AHCI
default y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK
@@ -12,7 +12,7 @@ config BLK
  A filesystem can be placed in each partition.

  config SPL_LEGACY_BLOCK
-   bool "Enable Legacy Block Device"
+   bool # "Enable Legacy Block Device"
depends on SPL && !DM_SPL
default y if SPL_MMC || SPL_USB_STORAGE || SCSI || NVME || IDE
default y if SPL_AHCI_PCI