Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 09:57-20230503, Tom Rini wrote: > On Wed, May 03, 2023 at 12:57:13PM +0530, Neha Malcom Francis wrote: > > Hi Tom > > > > On 27/04/23 04:07, Tom Rini wrote: > > > On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: > > > > > > > This series aims to eliminate the use of additional custom repositories > > > > such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 > > > > Security Development Tools) that was plumbed into the U-Boot build flow > > > > to generate boot images for TI K3 platform devices. And instead, we move > > > > towards using binman that aligns better with the community standard > > > > build > > > > flow. > > > > > > > > This series uses binman for all K3 platforms supported on U-Boot > > > > currently; > > > > both HS (High Security, both SE and FS) and GP (General Purpose) > > > > devices. > > > > > > > > Background on using k3-image-gen: > > > > * TI K3 devices require a SYSFW (System Firmware) image > > > > consisting > > > > of a signed system firmware image and board configuration > > > > binaries, > > > > this is needed to bring up system firmware during U-Boot R5 SPL > > > > startup. > > > > * Board configuration data contain board-specific information > > > > such as resource management, power management and security. > > > > > > > > Background on using core-secdev-k3: > > > > * Contains resources to sign x509 certificates for HS devices > > > > > > > > Series intends to use binman to take over the packaging and signing for > > > > the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined > > > > boot flow) instead of k3-image-gen. > > > > > > > > Series also packages the A72/A53 bootloader images (tispl.bin and > > > > u-boot.img) using ATF, OPTEE and DM (Device Manager) > > > > > > So, next up is fixing this in CI. After taking Andrew's patch to fix the > > > typedef issue, and after my patches to ensure we can get > > > pyyaml/jsonschema for python, there's problems still: > > > > > > Thanks for checking this! Couple things: > > > > > Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: > > > binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input > > > path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) > > > (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') > > > > 1. This is dependent on the patch merging J721S2 HS and GP configs [1]. > > However it has been reverted on -next, seen in the same thread. > > OK. I'm not sure the priority order here. I would like to see this > series get in first, and get everything else rebased on top of it. > > -- Hi Tom, I aligned with Neha on the order which will be easier for us both in terms of handling both the series, 1. J721S2 and J7200 HS defconfig merge ( https://lore.kernel.org/r/20230405-j721s2-hs-evm-upstream-v2-0-c0f10a410...@ti.com ) 2. Binman can go after that 3. J721E HS defconfig patches ( https://lore.kernel.org/u-boot/20230324-j721e-upstream-hs-v6-0-5aa43a481...@ti.com ) Will re-roll once binman is merged Thanks and regards, Manorit > Tom
[PATCH v2 3/3] configs: j7200: Merge the HS and non-HS defconfigs
K3 devices have runtime type board detection. Make the default defconfig
include the secure configuration. Then remove the HS specific config.
Non-HS devices will continue to boot due to runtime device type detection.
If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS
devices these can be ignored.
Reviewed-by: Kamlesh Gurudasani
Signed-off-by: Manorit Chawdhry
---
MAINTAINERS| 2 -
configs/j7200_evm_a72_defconfig| 3 +-
configs/j7200_evm_r5_defconfig | 1 +
configs/j7200_hs_evm_a72_defconfig | 205 -
configs/j7200_hs_evm_r5_defconfig | 170 --
5 files changed, 3 insertions(+), 378 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb3d927a335b..9d203d5f42d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1494,8 +1494,6 @@ F:configs/k2g_hs_evm_defconfig
F: configs/k2l_hs_evm_defconfig
F: configs/am65x_hs_evm_r5_defconfig
F: configs/am65x_hs_evm_a53_defconfig
-F: configs/j7200_hs_evm_a72_defconfig
-F: configs/j7200_hs_evm_r5_defconfig
TPM DRIVERS
M: Ilias Apalodimas
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 058e33149684..e40900fffa49 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x8000
CONFIG_SPL_GPIO=y
@@ -34,7 +35,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig
index 00ec48b83b78..dd4454943c36 100644
--- a/configs/j7200_evm_r5_defconfig
+++ b/configs/j7200_evm_r5_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x7
CONFIG_SPL_GPIO=y
diff --git a/configs/j7200_hs_evm_a72_defconfig
b/configs/j7200_hs_evm_a72_defconfig
deleted file mode 100644
index d9560727edb3..
--- a/configs/j7200_hs_evm_a72_defconfig
+++ /dev/null
@@ -1,205 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_K3=y
-CONFIG_TI_SECURE_DEVICE=y
-CONFIG_SYS_MALLOC_LEN=0x200
-CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_SPL_GPIO=y
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_J721E=y
-CONFIG_TARGET_J7200_A72_EVM=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
-CONFIG_ENV_SIZE=0x2
-CONFIG_ENV_OFFSET=0x68
-CONFIG_DM_GPIO=y
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-j7200-common-proc-board"
-CONFIG_SPL_TEXT_BASE=0x8008
-CONFIG_OF_LIBFDT_OVERLAY=y
-CONFIG_DM_RESET=y
-CONFIG_SPL_MMC=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_DRIVERS_MISC=y
-CONFIG_SPL_STACK_R_ADDR=0x8200
-CONFIG_ENV_OFFSET_REDUND=0x6A
-CONFIG_SPL_FS_FAT=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-# CONFIG_PSCI_RESET is not set
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_OF_BOARD_SETUP=y
-CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_fit_${boot}; run get_overlaystring; run run_fit"
-CONFIG_LOGLEVEL=7
-CONFIG_SPL_MAX_SIZE=0xc
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x80a0
-CONFIG_SPL_BSS_MAX_SIZE=0x8
-CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SYS_SPL_MALLOC_SIZE=0x80
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
-CONFIG_SPL_DMA=y
-CONFIG_SPL_ENV_SUPPORT=y
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
-CONFIG_SPL_I2C=y
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_NOR_SUPPORT=y
-CONFIG_SPL_DM_RESET=y
-CONFIG_SPL_POWER_DOMAIN=y
-CONFIG_SPL_RAM_SUPPORT=y
-CONFIG_SPL_RAM_DEVICE=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
-CONFIG_SPL_USB_GADGET=y
-CONFIG_SPL_DFU=y
-CONFIG_SPL_YMODEM_SUPPORT=y
-CONFIG_SYS_MAXARGS=64
-CONFIG_CMD_ASKENV=y
-CONFIG_CMD_DFU=y
-# CONFIG_CMD_FLASH is not set
[PATCH v2 2/3] Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On K3 HS-SE devices all the firewalls are locked by default until sysfw comes up. Rom configures some of the firewall for its usage along with the SRAM for R5 but the PSRAM region is still locked. The K3 MCU Scratchpad for j721s2 was set to a PSRAM region triggering the firewall exception before sysfw came up. The exception started happening after adding multi dtb support that accesses the scratchpad for reading EEPROM contents. Old map: ┌─┐ 0x41c0 │ SPL │ ├─┤ 0x41c61f20 (approx) │STACK│ ├─┤ 0x41c65f20 │ Global data │ │ sizeof(struct global_data) = 0xd8 │ ├─┤ gd->malloc_base = 0x41c66000 │HEAP │ │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ ├─┤ CONFIG_SPL_BSS_START_ADDR │ SPL BSS │ (0x41c76000) │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ ├─┤ (0x41c8) │ DM DATA │ ├─┤ (0x41c84130) (approx) │EMPTY│ └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX (0x41cffbfc) New map: ┌─┐ 0x41c0 │ SPL │ ├─┤ 0x41c61f20 (approx) │STACK│ ├─┤ 0x41c65f20 │ Global data │ │ sizeof(struct global_data) = 0xd8 │ ├─┤ gd->malloc_base = 0x41c66000 │HEAP │ │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ ├─┤ CONFIG_SPL_BSS_START_ADDR │ SPL BSS │ (0x41c76000) │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ ├─┤ (0x41c8) │ DM DATA │ ├─┤ (0x41c84130) (approx) │EMPTY│ ├─┤ SYS_K3_MCU_SCRATCHPAD_BASE │ SCRATCHPAD │ (0x41cff9fc) │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │ └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX (0x41cffbfc) Reviewed-by: Kamlesh Gurudasani Signed-off-by: Manorit Chawdhry --- arch/arm/mach-k3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index bae0a827c29f..bf1c3c51a41c 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -52,7 +52,7 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE config SYS_K3_MCU_SCRATCHPAD_BASE hex default 0x4028 if SOC_K3_AM654 - default 0x4028 if SOC_K3_J721S2 + default 0x41cff9fc if SOC_K3_J721S2 default 0x41cff9fc if SOC_K3_J721E help Describes the base address of MCU Scratchpad RAM. -- 2.34.1
[PATCH v2 1/3] configs: j721s2: Merge the HS and non-HS defconfigs
K3 devices have runtime type board detection. Make the default defconfig
include the secure configuration. Then remove the HS specific config.
Non-HS devices will continue to boot due to runtime device type detection.
If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS
devices these can be ignored.
Reviewed-by: Kamlesh Gurudasani
Signed-off-by: Manorit Chawdhry
---
MAINTAINERS | 2 -
configs/j721s2_evm_a72_defconfig| 3 +-
configs/j721s2_evm_r5_defconfig | 1 +
configs/j721s2_hs_evm_a72_defconfig | 212
configs/j721s2_hs_evm_r5_defconfig | 175 -
5 files changed, 3 insertions(+), 390 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2feb500aa39f..cb3d927a335b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1496,8 +1496,6 @@ F:configs/am65x_hs_evm_r5_defconfig
F: configs/am65x_hs_evm_a53_defconfig
F: configs/j7200_hs_evm_a72_defconfig
F: configs/j7200_hs_evm_r5_defconfig
-F: configs/j721s2_hs_evm_a72_defconfig
-F: configs/j721s2_hs_evm_r5_defconfig
TPM DRIVERS
M: Ilias Apalodimas
diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index addae9f6a290..594c8dad2cae 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x8000
CONFIG_SPL_GPIO=y
@@ -31,7 +32,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig
index 343e3c16305f..7416ba2d38d7 100644
--- a/configs/j721s2_evm_r5_defconfig
+++ b/configs/j721s2_evm_r5_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x1
CONFIG_SPL_GPIO=y
diff --git a/configs/j721s2_hs_evm_a72_defconfig
b/configs/j721s2_hs_evm_a72_defconfig
deleted file mode 100644
index d8089cb7dbc1..
--- a/configs/j721s2_hs_evm_a72_defconfig
+++ /dev/null
@@ -1,212 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_K3=y
-CONFIG_TI_SECURE_DEVICE=y
-CONFIG_SYS_MALLOC_LEN=0x200
-CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_SPL_GPIO=y
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_J721S2=y
-CONFIG_TARGET_J721S2_A72_EVM=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
-CONFIG_ENV_SIZE=0x2
-CONFIG_ENV_OFFSET=0x68
-CONFIG_DM_GPIO=y
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-j721s2-common-proc-board"
-CONFIG_SPL_TEXT_BASE=0x8008
-CONFIG_OF_LIBFDT_OVERLAY=y
-CONFIG_DM_RESET=y
-CONFIG_SPL_MMC=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_DRIVERS_MISC=y
-CONFIG_SPL_STACK_R_ADDR=0x8200
-CONFIG_ENV_OFFSET_REDUND=0x6A
-CONFIG_SPL_FS_FAT=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-# CONFIG_PSCI_RESET is not set
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_fit_${boot}; run get_overlaystring; run run_fit"
-CONFIG_LOGLEVEL=7
-CONFIG_SPL_MAX_SIZE=0xc
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x80a0
-CONFIG_SPL_BSS_MAX_SIZE=0x8
-CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SYS_SPL_MALLOC_SIZE=0x80
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
-CONFIG_SPL_DMA=y
-CONFIG_SPL_ENV_SUPPORT=y
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
-CONFIG_SPL_I2C=y
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_NOR_SUPPORT=y
-CONFIG_SPL_DM_RESET=y
-CONFIG_SPL_POWER_DOMAIN=y
-CONFIG_SPL_RAM_SUPPORT=y
-CONFIG_SPL_RAM_DEVICE=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
-CONFIG_SPL_THERMAL=y
-CONFIG_SPL_USB_GADGET=y
-CONFIG_SPL_DFU=y
-CONFIG_SPL_YMODEM_SUPPORT=y
-CONFIG_SYS_MAXARGS=64
-CONFIG_CMD_ASKENV=y
-CONFIG_CMD_DFU=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_GPT=y
[PATCH v2 0/3] J7 merge HS configs
This series depends on the fixes provided for j721e as that series also includes some base support for running the other HS platforms. Link for dependent series - https://lore.kernel.org/u-boot/20230324-j721e-upstream-hs-v6-0-5aa43a481...@ti.com/ ( This can be ignored due to the change on how the series is being merged with binman ) Signed-off-by: Manorit Chawdhry --- Changes in v2: - Rebased on top of master - Link to v1: https://lore.kernel.org/r/20230405-j721s2-hs-evm-upstream-v1-0-de446c5fa...@ti.com --- Manorit Chawdhry (3): configs: j721s2: Merge the HS and non-HS defconfigs Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region configs: j7200: Merge the HS and non-HS defconfigs MAINTAINERS | 4 - arch/arm/mach-k3/Kconfig| 2 +- configs/j7200_evm_a72_defconfig | 3 +- configs/j7200_evm_r5_defconfig | 1 + configs/j7200_hs_evm_a72_defconfig | 205 -- configs/j7200_hs_evm_r5_defconfig | 170 - configs/j721s2_evm_a72_defconfig| 3 +- configs/j721s2_evm_r5_defconfig | 1 + configs/j721s2_hs_evm_a72_defconfig | 212 configs/j721s2_hs_evm_r5_defconfig | 175 - 10 files changed, 7 insertions(+), 769 deletions(-) --- base-commit: bb2dcbf052051953297778bd0e62a017d83c8f6b change-id: 20230405-j721s2-hs-evm-upstream-bad9551303cd Best regards, -- Manorit Chawdhry
Re: [PATCH v3 00/19] Migration to using binman for bootloader
Hi Jan, On 03/05/23 22:04, Jan Kiszka wrote: On 03.05.23 14:56, Neha Malcom Francis wrote: Hi Jan, On 03/05/23 12:57, Neha Malcom Francis wrote: Hi Tom On 27/04/23 04:07, Tom Rini wrote: On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) So, next up is fixing this in CI. After taking Andrew's patch to fix the typedef issue, and after my patches to ensure we can get pyyaml/jsonschema for python, there's problems still: Thanks for checking this! Couple things: Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') 1. This is dependent on the patch merging J721S2 HS and GP configs [1]. However it has been reverted on -next, seen in the same thread. And then: https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error I've fixed this, minor but serious change. 2. Regarding iot2050, build fails since it uses arch/arm/mach-k3/config.mk which is now entirely binman based. Will try moving iot2050 to binman as well. I'll need some help with this, might need to know the bootloader flow to make a clean migration. Where do I have to look at? Is there a git repo with that experiment somewhere? Jan There's no experiment yet, I will send one today; but I do not have complete understanding of the booting; whether the tispl.bin (which I assume is the only boot component that is affecting iot2050 boot since k3_fit_atf.sh is no longer there) has any concept of signing? Is core-secdev-k3 ever used? -- Thanking You Neha Malcom Francis
Re: [PATCH 2/2] CI: Make use of buildman requirements.txt
Hi Tom, On 03/05/23 18:34, Tom Rini wrote: On Wed, May 03, 2023 at 11:27:20AM +0530, Neha Malcom Francis wrote: Hi Tom Thanks for these patches! On 27/04/23 01:14, Tom Rini wrote: Now that buildman has a requirements.txt file we need to make use of it. Signed-off-by: Tom Rini --- .azure-pipelines.yml | 3 +++ .gitlab-ci.yml | 4 2 files changed, 7 insertions(+) However, while trying to ensure CI/CD coverage, I'm running into this " error 'No module named 'jsonschema'" for am62ax [1], any idea why after building successfully for other devices? [1] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=6236=logs=6fe7c803-7a3b-5b46-f057-c1c62fd89ba1=22dc4ac5-ae35-5978-08ac-5f386151834e=fae48c67-4bb5-5f06-119f-00d23f780e3c o We need to have the requirements.txt file installed in any job that's using this part of binman now and I guess my patch above wasn't complete? I didn't fully check what happened on Azure due to the other problems (ie iot2050 boards not building). Probably, I'm not sure about how to rectify this. Could you have a look if possible? Regarding iot2050, I have started working on it. -- Thanking You Neha Malcom Francis
Mainline Linux on gru / bob
Hi, I haven't had any luck booting mainline U-Boot and Linux on Bobafter booting Linux the display shows a strange pattern and I don't see anything on the serial console despite trying various earlycon things. Does anyone know a recipe that works? Thanks, Simon
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 2023/5/2 21:24, Heinrich Schuchardt wrote: > On 5/2/23 15:11, Andreas Schwab wrote: >> On Mai 02 2023, Matthias Brugger wrote: >> >>> I'm not sure I get your point. The devicetree will be passed to the kernel >>> via a pointer in a register, the kernel does not need to load the >>> devicetree into memory, it will use the one passed by U-Boot. >> >> But U-Boot needs to load it, and the kernel is the authority in >> providing it. >> > > To make it a bit clearer: > > Several U-Boot boot methods use the value of environment variable $fdtfile to > load a device-tree from file. The same holds true for the boot.scr file > created by Debian's flash-kernel package. > > A good solution would be to read the EEPROM to determine the exact board > version, to set $fdtfile accordingly and update U-Boots control dtb as needed. > The patcheset have implemented the reading of PCB versions from EEPROM and the configuration of gmac device tree nodes according to different PCB versions, which can achieve a bin file compatible with both versions 1.2A and 1.3B. The patcheset link: https://patchwork.ozlabs.org/project/uboot/cover/20230428022515.29393-1-yanhong.w...@starfivetech.com/ > Best regards > > Heinrich
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Wed, May 03, 2023 at 04:56:18PM -0600, Simon Glass wrote: > Hi Rasmus, > > On Wed, 3 May 2023 at 02:25, Rasmus Villemoes > wrote: > > > > On 01/05/2023 18.32, Simon Glass wrote: > > > Hi Rasmus, > > > > > > On Mon, 1 May 2023 at 02:49, Rasmus Villemoes > > > wrote: > > >> > > >> On 27/04/2023 19.31, Tom Rini wrote: > > > > Well, I'm not sure there's a use case for building all of the extra > > device trees. I think what I'll do right now is fire off a CI run (or a > > few, in the event of problems) where we just use the logic of > > 3609e1dc5f4d and see what falls down. > > >>> > > >>> So this gets us a few failures. You can see them on > > >>> https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > > >>> failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > > >>> contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > > >>> case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > > >>> because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > > >>> arch/.../foo.dtb and so we don't have the dtb file around. > > >>> > > >> > > >> Hm, the former sounds like a bug in the defconfig, the second sounds > > >> like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > > >> should be fixable by just changing the logic of scripts/Makefile.dts a > > >> little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > > >> SPL_OF_LIST to dtb-y. Something like > > >> > > >> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > > >> index 2561025da8..5e2429c617 100644 > > >> --- a/scripts/Makefile.dts > > >> +++ b/scripts/Makefile.dts > > >> @@ -1,3 +1,3 @@ > > >> # SPDX-License-Identifier: GPL-2.0+ > > >> > > >> -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > > >> +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > > >> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > > > > > > I think we should require that all the DTs in the list are already > > > built using the standard rule. > > > > > > i.e. Makefile.dts should just have a check that OF_LIST doesn't bring > > > in anything new. If it does, then the build should fail. > > > > I disagree. > > > > IMO, having those enourmous lists is unmaintainable, and > > as I've pointed out, actively misleading because (like it or not), the > > result of building foo.dtb depends (or to be pedantically correct, _may > > depend_) on whether we're building foo_defconfig or bar_defconfig, > > despite both foo and bar being members of the same SOC family or vendor > > or however foo.dtb and bar.dtb have been categorized. > > That's actually not how it is supposed to work, though. Er, what do you mean? The Makefiles are supposed to produce functional binaries. Which they mostly only do not due to the logic in arch/*/dts/Makefile but the logic in scripts/Makefile.dts that ensure the dtbs the config file says it needs are built. > > > The list is really about which ones should be put into the FIT. We > > > shouldn't be putting in things that don't exist normally for that SoC. > > > > Yes, and I'm not talking about changing any of _that_. I'm just saying: > > The board, in the form of the defconfig, already provides information on > > which dtbs can be relevant for any bootphase, so let's just build the > > union of those, _but nothing else_. > > But then we end up with lots of TARGET rules. Plus the Makefile > no-longer describes which DTs are built?? Perhaps I just misunderstand > where you are heading. Yes, what we're doing is getting rid of all of the TARGET rules, and all of the SOC rules and so forth, as the config file needs (and almost always does) say what dtbs are going to be used. > > > Meanwhile I think we should move towards prohibiting CONFIG_TARGET_... > > > in Makefile rules, > > > > I think we can get rid of all of it, or perhaps with some exceptions for > > sandbox and the like. I mean, Tom's quick test didn't show that many > > problems from just nuking almost all of arch/*/dts/Makefile. > > since this is creating some of this problem. i.e. > > > we should do what Linux does. > > > > I don't think so. Linux (and in general an OS kernel) is in a completely > > different situation than a bootloader. It's possible to build one kernel > > that will boot on many different boards with just an appropriate dtb > > being passed. A bootloader will always need to be built for the specific > > target (or for a very close family of targets); you can't really imagine > > building an imx_defconfig u-boot binary and expect that to run on all > > imx-boards. > > Actually that's really not true, at least not as broadly as you have > said it. The original purpose of bringing DT into U-Boot was to allow > an exynos5 build to run on 3-4 different boards, just with the DT. As > you have seen we have boards that provide an SPL_OF_LIST to deal with > differences relevant to U-Boot. The DEFAULT_DEVICE_TREE for a board is > really just that.
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/2/23 13:18, Eugen Hristev wrote: On 5/2/23 13:53, Marek Vasut wrote: On 5/2/23 12:41, Eugen Hristev wrote: On 5/2/23 12:18, Marek Vasut wrote: On 5/2/23 08:51, Eugen Hristev wrote: regulator_set_enable_if_allowed already handles cases when the regulator is already enabled, or already disabled, and does not treat these as errors. With this change, the driver can work correctly even if the regulator is already taken or already disabled by another consumer. Can that ever happen for Vbus supply (the 5V coming out of USB port) ? Can you elaborate how ? Hi Marek, Hi, Recently I developed a series of patches to add a reference counter for regulators : https://marc.info/?l=u-boot=168191189309879=2 Ah yes, this is super cool stuff, thanks ! But with this series, having a regulator already enabled or already disabled results in an error returned by regulator_set_enable Hence, one option is to replace calls with regulator_set_enable_if_allowed There is a discussion ongoing here: https://marc.info/?l=u-boot=168295920316621=2 Pardon my ignorance, but uh ... how does Linux deal with regulators which are enabled by prior stage, like U-Boot ? Does it set their enable refcount to =1 or =0 ? Please correct me if I am wrong, I did not dig too much into regulators, but , from my understanding : Normally software(in this case Linux) reads the state of the regulator when it's probed, and sets the refcount accordingly. If the state cannot be read then regulator-boot-on tells Linux that it should have been left enabled by prior stage In Uboot I believe that regulators that have 'regulator-boot-on' are added to a list and set to enable during probe, and the probe is forced even if Uboot normally uses lazy probing (should have the same behavior for regulator-always-on property) So if a regulator is enabled by an initial stage but it's not described with 'regulator-boot-on' , appears to be a bad hardware description in DT. Thanks for checking this. It seems like Tim found the root cause of the problem in the meantime, so let's see where that discussion moves on to.
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/2/23 18:13, Tim Harvey wrote:
On Mon, May 1, 2023 at 11:51 PM Eugen Hristev
wrote:
regulator_set_enable_if_allowed already handles cases when the
regulator is already enabled, or already disabled, and does not
treat these as errors.
With this change, the driver can work correctly even if the regulator
is already taken or already disabled by another consumer.
Signed-off-by: Eugen Hristev
---
Hi Tim,
I have not tested this as I do not have a mx6 board. can you please
try it ?
Thanks,
Eugen
Eugen,
This does resolve the issue that occurs after your refcount series [1].
However after thinking about this more and seeing Marek's responses
this wasn't an issue of multiple consumers sharing the same regulator.
Instead this particular issue was that the vbus regulator is getting
enabled twice without being disabled. Adding a print in
regulator_set_enable shows me:
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -165,6 +165,7 @@ int regulator_set_enable(struct udevice *dev, bool enable)
struct dm_regulator_uclass_plat *uc_pdata;
int ret, old_enable = 0;
+printf("%s %s %s\n", __func__, dev->name, enable ? "enable" : "disable");
if (!ops || !ops->set_enable)
return -ENOSYS;
u-boot=> usb start
starting USB...
Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
^^^ from ehci_usb_probe
Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
^^^ from ehci_usb_probe
regulator_set_enable regulator-usb-otg2 enable
^^^ from mx6_init_after_reset - 2nd enable without a disable
So while I think this patch does make sense to cover the case where a
regulator could be shared
Does such a case really still exist after the discovery you made above ?
there probably is a follow-on patch needed
to balance the regulator calls (unrelated to your series).
Marek,
Should vbus regulator enable really be in init_after_reset call?
Yes, but I am not entirely convinced the VBUS should be enabled in
ehci_usb_probe(), because in ehci_usb_probe() resp. in ehci_register()
which is called at the end, we might detect that the port is configured
as PERIPHERAL and we don't want to enable VBUS in that case .
So I suspect regulator_set_enable() should rather be dropped from
ehci_usb_probe() . What do you think ?
Re: [PATCH 1/1] doc: man-page for cp
On Wed, 3 May 2023 at 10:47, Heinrich Schuchardt wrote: > > Add a man-page for the cp command. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > replace the 'word' by 'chunk' > fix typos > --- > doc/usage/cmd/cp.rst | 83 > doc/usage/index.rst | 1 + > 2 files changed, 84 insertions(+) > create mode 100644 doc/usage/cmd/cp.rst > Reviewed-by: Simon Glass
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
Hi Rasmus, On Wed, 3 May 2023 at 02:25, Rasmus Villemoes wrote: > > On 01/05/2023 18.32, Simon Glass wrote: > > Hi Rasmus, > > > > On Mon, 1 May 2023 at 02:49, Rasmus Villemoes > > wrote: > >> > >> On 27/04/2023 19.31, Tom Rini wrote: > > Well, I'm not sure there's a use case for building all of the extra > device trees. I think what I'll do right now is fire off a CI run (or a > few, in the event of problems) where we just use the logic of > 3609e1dc5f4d and see what falls down. > >>> > >>> So this gets us a few failures. You can see them on > >>> https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > >>> failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > >>> contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > >>> case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > >>> because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > >>> arch/.../foo.dtb and so we don't have the dtb file around. > >>> > >> > >> Hm, the former sounds like a bug in the defconfig, the second sounds > >> like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > >> should be fixable by just changing the logic of scripts/Makefile.dts a > >> little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > >> SPL_OF_LIST to dtb-y. Something like > >> > >> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > >> index 2561025da8..5e2429c617 100644 > >> --- a/scripts/Makefile.dts > >> +++ b/scripts/Makefile.dts > >> @@ -1,3 +1,3 @@ > >> # SPDX-License-Identifier: GPL-2.0+ > >> > >> -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > >> +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > >> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > > > > I think we should require that all the DTs in the list are already > > built using the standard rule. > > > > i.e. Makefile.dts should just have a check that OF_LIST doesn't bring > > in anything new. If it does, then the build should fail. > > I disagree. > > IMO, having those enourmous lists is unmaintainable, and > as I've pointed out, actively misleading because (like it or not), the > result of building foo.dtb depends (or to be pedantically correct, _may > depend_) on whether we're building foo_defconfig or bar_defconfig, > despite both foo and bar being members of the same SOC family or vendor > or however foo.dtb and bar.dtb have been categorized. That's actually not how it is supposed to work, though. > > > The list is really about which ones should be put into the FIT. We > > shouldn't be putting in things that don't exist normally for that SoC. > > Yes, and I'm not talking about changing any of _that_. I'm just saying: > The board, in the form of the defconfig, already provides information on > which dtbs can be relevant for any bootphase, so let's just build the > union of those, _but nothing else_. But then we end up with lots of TARGET rules. Plus the Makefile no-longer describes which DTs are built?? Perhaps I just misunderstand where you are heading. > > > Meanwhile I think we should move towards prohibiting CONFIG_TARGET_... > > in Makefile rules, > > I think we can get rid of all of it, or perhaps with some exceptions for > sandbox and the like. I mean, Tom's quick test didn't show that many > problems from just nuking almost all of arch/*/dts/Makefile. > since this is creating some of this problem. i.e. > > we should do what Linux does. > > I don't think so. Linux (and in general an OS kernel) is in a completely > different situation than a bootloader. It's possible to build one kernel > that will boot on many different boards with just an appropriate dtb > being passed. A bootloader will always need to be built for the specific > target (or for a very close family of targets); you can't really imagine > building an imx_defconfig u-boot binary and expect that to run on all > imx-boards. Actually that's really not true, at least not as broadly as you have said it. The original purpose of bringing DT into U-Boot was to allow an exynos5 build to run on 3-4 different boards, just with the DT. As you have seen we have boards that provide an SPL_OF_LIST to deal with differences relevant to U-Boot. The DEFAULT_DEVICE_TREE for a board is really just that. It should be possible to use a different DT with the same U-Boot binary and have it work on a different board (with the same SoC). If you think about the implications of that, it means that we need to use compatible strings for board features, not #ifdefs and special C files. What sort of things are ending up in the DT that make it build differently from other boards? Is it Kconfig options? I am aware of this on x86, since there is a common u-boot.dtsi for all boards. We definitely take a risk by including Kconfig options in the DT, but I would hope that DT differences are in the board's .dts, not in shared .dtsi files. > > That said, there's another thing "Linux does", at
[PATCH] bk4r1: Enable LTO
In order to allow for general platform growth due to fixes, enable LTO here to give us more room. Signed-off-by: Tom Rini --- configs/bk4r1_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig index 66adeac725ce..95f0c30cde63 100644 --- a/configs/bk4r1_defconfig +++ b/configs/bk4r1_defconfig @@ -18,6 +18,7 @@ CONFIG_TARGET_BK4R1=y CONFIG_SYS_LOAD_ADDR=0x8200 CONFIG_SYS_MEMTEST_START=0x8001 CONFIG_SYS_MEMTEST_END=0x87c0 +CONFIG_LTO=y CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=520192 CONFIG_FIT=y -- 2.34.1
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Wed, May 03, 2023 at 11:43:57PM +0200, Marek Vasut wrote: > On 5/1/23 23:18, Tom Rini wrote: > > On Mon, May 01, 2023 at 10:49:37PM +0200, Marek Vasut wrote: > > > On 5/1/23 20:53, Tom Rini wrote: > > > > On Mon, May 01, 2023 at 07:40:57PM +0200, Marek Vasut wrote: > > > > > On 5/1/23 19:23, Tom Rini wrote: > > > > > > On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: > > > > > > > On 5/1/23 15:47, Tom Rini wrote: > > > > > > > > On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > > > In case NET networking is not enabled, it is not possible to > > > > > > > > > compile > > > > > > > > > the USB ethernet gadget. Protect the symbols in Makefile to > > > > > > > > > avoid build > > > > > > > > > failure. Such build failure may occur e.g. in case NET and > > > > > > > > > USB ethernet > > > > > > > > > gadget is enabled in U-Boot proper, but not in SPL. > > > > > > > > > > > > > > > > > > Signed-off-by: Marek Vasut > > > > > > > > > --- > > > > > > > > > Cc: Lukasz Majewski > > > > > > > > > --- > > > > > > > > > drivers/usb/gadget/Makefile | 2 ++ > > > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/drivers/usb/gadget/Makefile > > > > > > > > > b/drivers/usb/gadget/Makefile > > > > > > > > > index 6cfe0f3a041..36f65e7eb95 100644 > > > > > > > > > --- a/drivers/usb/gadget/Makefile > > > > > > > > > +++ b/drivers/usb/gadget/Makefile > > > > > > > > > @@ -34,8 +34,10 @@ endif > > > > > > > > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > > > > > > > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > > > > > > > > > obj-$(CONFIG_USB_ETHER) += ether.o > > > > > > > > > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > > > > > > > > > +endif > > > > > > > > > # Devices not related to the new gadget layer depend on > > > > > > > > > CONFIG_USB_DEVICE > > > > > > > > > # This is really only N900 and USBTTY now. > > > > > > > > > > > > > > > > Why can't we just enforce this via Kconfig? > > > > > > > > > > > > > > Because there is no SPL/TPL USB_ETHER Kconfig . > > > > > > > Do we want to grow the Kconfig file with those instead ? > > > > > > > > > > > > Ah right. Yes, we have SPL_USB_ETHER today > > > > > > > > > > This is exactly the opposite of what I wrote. > > > > > > > > > > And no, we do NOT have this symbol, see: > > > > > > > > > > $ git grep SPL_USB_ETHER drivers/usb | wc -l > > > > > 0 > > > > > > > > Yes, it resides in common/spl/Kconfig > > > > > > Uh, such USB symbol is not supposed to be there in the first place. > > > > There's long running debate on where some symbols should be for a better > > overall experience of enabling features. > > Putting my USB maintainer hat on, USB drivers related symbols should be in > drivers/usb/ . With everything in Kconfig finally, I have no objection to someone making patches to clean up and make the menus more consistent. However you'd like to move all of SPL*USB* out of common/spl/Kconfig and under drivers/usb/ is OK with me. > > > However, looking at the meaning of that symbol, it seems it governs > > > something else -- USB ethernet device(s) (like the USB-ethernet adapter > > > which you plug into USB host port). So, the SPL_USB_ETHER symbol name is > > > incorrectly named too and should be renamed to something else first I > > > think > > > ? > > > > > > Do I read it right ? > > > > > > And if so, then, back to my original reply -- there is no SPL_USB_ETHER > > > symbol. Does it make more sense to really add one (not misnamed one) or > > > not > > > ? > > > > We should re-work things as needed so that we have more Kconfig symbols, > > as needed. There's some overlap / overloading of things today as > > platforms have been able to (and I think am335x_evm is still one that > > builds for) supporting making a USB RNDIS gadget device happen in SPL, > > so that we can then be fed the next stage of U-Boot. > > I have a hardware where I only want USB ethernet support in U-Boot, not in > SPL, hence this patch. > > But the symbol which is currently named SPL_USB_ETHER as defined in common/ > does NOT ungate SPL CDC ethernet support, it ungates SPL USB host ethernet > (like those ASIX USB-ethernet adapters), do you agree ? > > If yes, then the symbol itself should be renamed . What I see in terms of wording in common/spl/Kconfig doesn't match what it builds, which is what it's intended to build. Fire up a build of am335x_evm_defconfig and look at what's under drivers/usb/ which is what the platform wants. Gadget ethernet via RNDIS. So the help is wrong on SPL_USB_ETHER. -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On 5/1/23 23:18, Tom Rini wrote: On Mon, May 01, 2023 at 10:49:37PM +0200, Marek Vasut wrote: On 5/1/23 20:53, Tom Rini wrote: On Mon, May 01, 2023 at 07:40:57PM +0200, Marek Vasut wrote: On 5/1/23 19:23, Tom Rini wrote: On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: On 5/1/23 15:47, Tom Rini wrote: On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: In case NET networking is not enabled, it is not possible to compile the USB ethernet gadget. Protect the symbols in Makefile to avoid build failure. Such build failure may occur e.g. in case NET and USB ethernet gadget is enabled in U-Boot proper, but not in SPL. Signed-off-by: Marek Vasut --- Cc: Lukasz Majewski --- drivers/usb/gadget/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 6cfe0f3a041..36f65e7eb95 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,8 +34,10 @@ endif obj-$(CONFIG_CI_UDC) += ci_udc.o +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) obj-$(CONFIG_USB_ETHER) += ether.o obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o +endif # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Why can't we just enforce this via Kconfig? Because there is no SPL/TPL USB_ETHER Kconfig . Do we want to grow the Kconfig file with those instead ? Ah right. Yes, we have SPL_USB_ETHER today This is exactly the opposite of what I wrote. And no, we do NOT have this symbol, see: $ git grep SPL_USB_ETHER drivers/usb | wc -l 0 Yes, it resides in common/spl/Kconfig Uh, such USB symbol is not supposed to be there in the first place. There's long running debate on where some symbols should be for a better overall experience of enabling features. Putting my USB maintainer hat on, USB drivers related symbols should be in drivers/usb/ . However, looking at the meaning of that symbol, it seems it governs something else -- USB ethernet device(s) (like the USB-ethernet adapter which you plug into USB host port). So, the SPL_USB_ETHER symbol name is incorrectly named too and should be renamed to something else first I think ? Do I read it right ? And if so, then, back to my original reply -- there is no SPL_USB_ETHER symbol. Does it make more sense to really add one (not misnamed one) or not ? We should re-work things as needed so that we have more Kconfig symbols, as needed. There's some overlap / overloading of things today as platforms have been able to (and I think am335x_evm is still one that builds for) supporting making a USB RNDIS gadget device happen in SPL, so that we can then be fed the next stage of U-Boot. I have a hardware where I only want USB ethernet support in U-Boot, not in SPL, hence this patch. But the symbol which is currently named SPL_USB_ETHER as defined in common/ does NOT ungate SPL CDC ethernet support, it ungates SPL USB host ethernet (like those ASIX USB-ethernet adapters), do you agree ? If yes, then the symbol itself should be renamed .
Re: Pull request: please pull u-boot-imx-20230503
Hi Tom,
On Wed, May 3, 2023 at 4:01 PM Tom Rini wrote:
> So, both my HW test and CI is fine, so I've applied this. But please
> note we now have this scary message to fix:
> +(imx8qm_dmsse20a1) aarch64-linux-ld.bfd: invalid origin for memory region
> .sdram
I compared the imx8qm_dmsse20a1 against imx8qm_mek_defconfig and with
the following changes the warning is gone:
--- a/configs/imx8qm_dmsse20a1_defconfig
+++ b/configs/imx8qm_dmsse20a1_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL_SERIAL=y
CONFIG_SPL_DRIVERS_MISC=y
CONFIG_ENV_OFFSET=0x8
CONFIG_ENV_SECT_SIZE=0x2
+CONFIG_SPL_STACK=0x13e000
CONFIG_SPL=y
CONFIG_SYS_LOAD_ADDR=0x8028
CONFIG_SYS_MEMTEST_START=0xA000
@@ -38,11 +39,17 @@ CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run
mmcboot; else run netboot; fi; fi; else booti ${loadaddr} -
${fdt_addr}; fi"
CONFIG_LOG=y
CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_SPL_BSS_START_ADDR=0x00128000
CONFIG_SPL_MAX_SIZE=0x1f000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x128000
CONFIG_SPL_BSS_MAX_SIZE=0x1000
CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x12
+CONFIG_SYS_SPL_MALLOC_SIZE=0x3000
CONFIG_SPL_POWER_SUPPORT=y
CONFIG_SPL_POWER_DOMAIN=y
CONFIG_SPL_WATCHDOG_SUPPORT=y
Oliver, could you please test this change?
I can submit it formally if it works for you.
[RFC PATCH v2 6/7] clk: treewide: switch to clock dump from clk_ops
Switch to using new dump operation in clock provider drivers instead of
overriding soc_clk_dump.
Signed-off-by: Igor Prusov
---
arch/mips/mach-pic32/cpu.c | 23 ---
drivers/clk/aspeed/clk_ast2600.c | 13 -
drivers/clk/clk_k210.c | 11 +++-
drivers/clk/clk_pic32.c| 39 ++
drivers/clk/clk_versal.c | 7 -
drivers/clk/clk_zynq.c | 19 -
drivers/clk/clk_zynqmp.c | 13 -
drivers/clk/imx/clk-imx8.c | 11 +++-
drivers/clk/mvebu/armada-37xx-periph.c | 5 +++-
drivers/clk/stm32/clk-stm32mp1.c | 29 ++-
10 files changed, 83 insertions(+), 87 deletions(-)
diff --git a/arch/mips/mach-pic32/cpu.c b/arch/mips/mach-pic32/cpu.c
index de449e3c6a..2875a1ec7c 100644
--- a/arch/mips/mach-pic32/cpu.c
+++ b/arch/mips/mach-pic32/cpu.c
@@ -148,26 +148,3 @@ const char *get_core_name(void)
return str;
}
#endif
-#ifdef CONFIG_CMD_CLK
-
-int soc_clk_dump(void)
-{
- int i;
-
- printf("PLL Speed: %lu MHz\n",
- CLK_MHZ(rate(PLLCLK)));
-
- printf("CPU Speed: %lu MHz\n", CLK_MHZ(rate(PB7CLK)));
-
- printf("MPLL Speed: %lu MHz\n", CLK_MHZ(rate(MPLL)));
-
- for (i = PB1CLK; i <= PB7CLK; i++)
- printf("PB%d Clock Speed: %lu MHz\n", i - PB1CLK + 1,
- CLK_MHZ(rate(i)));
-
- for (i = REF1CLK; i <= REF5CLK; i++)
- printf("REFO%d Clock Speed: %lu MHz\n", i - REF1CLK + 1,
- CLK_MHZ(rate(i)));
- return 0;
-}
-#endif
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index b3cc8392fa..e1365d3f81 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1109,6 +1109,7 @@ struct aspeed_clks {
const char *name;
};
+#if IS_ENABLED(CONFIG_CMD_CLK)
static struct aspeed_clks aspeed_clk_names[] = {
{ ASPEED_CLK_HPLL, "hpll" },
{ ASPEED_CLK_MPLL, "mpll" },
@@ -1123,18 +1124,12 @@ static struct aspeed_clks aspeed_clk_names[] = {
{ ASPEED_CLK_HUARTX, "huxclk" },
};
-int soc_clk_dump(void)
+static int ast2600_clk_dump(struct udevice *dev)
{
- struct udevice *dev;
struct clk clk;
unsigned long rate;
int i, ret;
- ret = uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(aspeed_scu),
- );
- if (ret)
- return ret;
-
printf("Clk\t\tHz\n");
for (i = 0; i < ARRAY_SIZE(aspeed_clk_names); i++) {
@@ -1167,11 +1162,15 @@ int soc_clk_dump(void)
return 0;
}
+#endif
struct clk_ops ast2600_clk_ops = {
.get_rate = ast2600_clk_get_rate,
.set_rate = ast2600_clk_set_rate,
.enable = ast2600_clk_enable,
+#if IS_ENABLED(CONFIG_CMD_CLK)
+ .dump = ast2600_clk_dump,
+#endif
};
static int ast2600_clk_probe(struct udevice *dev)
diff --git a/drivers/clk/clk_k210.c b/drivers/clk/clk_k210.c
index 2f17152021..058940b828 100644
--- a/drivers/clk/clk_k210.c
+++ b/drivers/clk/clk_k210.c
@@ -1276,16 +1276,10 @@ static void show_clks(struct k210_clk_priv *priv, int
id, int depth)
}
}
-int soc_clk_dump(void)
+static int k210_clk_dump(struct udevice *dev)
{
- int ret;
- struct udevice *dev;
struct k210_clk_priv *priv;
- ret = uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(k210_clk),
- );
- if (ret)
- return ret;
priv = dev_get_priv(dev);
puts(" Rate Enabled Name\n");
@@ -1304,6 +1298,9 @@ static const struct clk_ops k210_clk_ops = {
.set_parent = k210_clk_set_parent,
.enable = k210_clk_enable,
.disable = k210_clk_disable,
+#if IS_ENABLED(CONFIG_CMD_CLK)
+ .dump = k210_clk_dump,
+#endif
};
static int k210_clk_probe(struct udevice *dev)
diff --git a/drivers/clk/clk_pic32.c b/drivers/clk/clk_pic32.c
index ef06a7fb9f..f756fc88f0 100644
--- a/drivers/clk/clk_pic32.c
+++ b/drivers/clk/clk_pic32.c
@@ -20,6 +20,8 @@
DECLARE_GLOBAL_DATA_PTR;
+#define CLK_MHZ(x) ((x) / 100)
+
/* Primary oscillator */
#define SYS_POSC_CLK_HZ2400
@@ -385,9 +387,46 @@ static ulong pic32_set_rate(struct clk *clk, ulong rate)
return rate;
}
+#if IS_ENABLED(CONFIG_CMD_CLK)
+static int pic32_dump(struct udevice *dev)
+{
+ int i;
+ struct clk clk;
+
+ clk.dev = dev;
+
+ clk.id = PLLCLK;
+ printf("PLL Speed: %lu MHz\n",
+ CLK_MHZ(pic32_get_rate()));
+
+ clk.id = PB7CLK;
+ printf("CPU Speed: %lu MHz\n", CLK_MHZ(pic32_get_rate()));
+
+ clk.id = MPLL;
+ printf("MPLL Speed: %lu MHz\n", CLK_MHZ(pic32_get_rate()));
+
+ for (i = PB1CLK; i <= PB7CLK; i++) {
+ clk.id = i;
+ printf("PB%d Clock Speed: %lu MHz\n", i - PB1CLK + 1,
+
[RFC PATCH v2 7/7] cmd: clk: Remove __weak from soc_clk_dump
After introducing dump to clk_ops there is no need to override this
symbol anymore.
Signed-off-by: Igor Prusov
---
cmd/clk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/clk.c b/cmd/clk.c
index 55fb96e631..54491ac577 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -59,7 +59,7 @@ static void show_clks(struct udevice *dev, int depth, int
last_flag)
}
}
-int __weak soc_clk_dump(void)
+int soc_clk_dump(void)
{
struct udevice *dev;
const struct clk_ops *ops;
@@ -81,7 +81,7 @@ int __weak soc_clk_dump(void)
return 0;
}
#else
-int __weak soc_clk_dump(void)
+int soc_clk_dump(void)
{
puts("Not implemented\n");
return 1;
--
2.34.1
[RFC PATCH v2 5/7] cmd: clk: Use dump function from clk_ops
Add another loop to dump additional info from clock providers that
implement dump operation.
Signed-off-by: Igor Prusov
---
cmd/clk.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/cmd/clk.c b/cmd/clk.c
index ff7c7649a1..55fb96e631 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -62,6 +62,7 @@ static void show_clks(struct udevice *dev, int depth, int
last_flag)
int __weak soc_clk_dump(void)
{
struct udevice *dev;
+ const struct clk_ops *ops;
printf(" Rate Usecnt Name\n");
printf("--\n");
@@ -69,6 +70,14 @@ int __weak soc_clk_dump(void)
uclass_foreach_dev_probe(UCLASS_CLK, dev)
show_clks(dev, -1, 0);
+ uclass_foreach_dev_probe(UCLASS_CLK, dev) {
+ ops = dev_get_driver_ops(dev);
+ if (ops && ops->dump) {
+ printf("--\n");
+ ops->dump(dev);
+ }
+ }
+
return 0;
}
#else
--
2.34.1
[RFC PATCH v2 4/7] clk: Add dump operation to clk_ops
This adds dump function to struct clk_ops which should replace
soc_clk_dump. It allows clock drivers to provide custom dump
implementation without overriding generic CCF dump function.
Signed-off-by: Igor Prusov
---
include/clk-uclass.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/clk-uclass.h b/include/clk-uclass.h
index 65ebff9ed2..f29f4c0d01 100644
--- a/include/clk-uclass.h
+++ b/include/clk-uclass.h
@@ -39,6 +39,9 @@ struct clk_ops {
int (*set_parent)(struct clk *clk, struct clk *parent);
int (*enable)(struct clk *clk);
int (*disable)(struct clk *clk);
+#if IS_ENABLED(CONFIG_CMD_CLK)
+ int (*dump)(struct udevice *dev);
+#endif
};
#if 0 /* For documentation only */
--
2.34.1
[RFC PATCH v2 3/7] clk: k210: Move soc_clk_dump function
Move clock dump function to avoid forward declaration after switching to
dump in clk_ops.
Signed-off-by: Igor Prusov
---
drivers/clk/clk_k210.c | 92 +-
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/clk/clk_k210.c b/drivers/clk/clk_k210.c
index c534cc07e0..2f17152021 100644
--- a/drivers/clk/clk_k210.c
+++ b/drivers/clk/clk_k210.c
@@ -1238,52 +1238,6 @@ static int k210_clk_request(struct clk *clk)
return 0;
}
-static const struct clk_ops k210_clk_ops = {
- .request = k210_clk_request,
- .set_rate = k210_clk_set_rate,
- .get_rate = k210_clk_get_rate,
- .set_parent = k210_clk_set_parent,
- .enable = k210_clk_enable,
- .disable = k210_clk_disable,
-};
-
-static int k210_clk_probe(struct udevice *dev)
-{
- int ret;
- struct k210_clk_priv *priv = dev_get_priv(dev);
-
- priv->base = dev_read_addr_ptr(dev_get_parent(dev));
- if (!priv->base)
- return -EINVAL;
-
- ret = clk_get_by_index(dev, 0, >in0);
- if (ret)
- return ret;
-
- /*
-* Force setting defaults, even before relocation. This is so we can
-* set the clock rate for PLL1 before we relocate into aisram.
-*/
- if (!(gd->flags & GD_FLG_RELOC))
- clk_set_defaults(dev, CLK_DEFAULTS_POST_FORCE);
-
- return 0;
-}
-
-static const struct udevice_id k210_clk_ids[] = {
- { .compatible = "canaan,k210-clk" },
- { },
-};
-
-U_BOOT_DRIVER(k210_clk) = {
- .name = "k210_clk",
- .id = UCLASS_CLK,
- .of_match = k210_clk_ids,
- .ops = _clk_ops,
- .probe = k210_clk_probe,
- .priv_auto = sizeof(struct k210_clk_priv),
-};
-
#if IS_ENABLED(CONFIG_CMD_CLK)
static char show_enabled(struct k210_clk_priv *priv, int id)
{
@@ -1342,3 +1296,49 @@ int soc_clk_dump(void)
return 0;
}
#endif
+
+static const struct clk_ops k210_clk_ops = {
+ .request = k210_clk_request,
+ .set_rate = k210_clk_set_rate,
+ .get_rate = k210_clk_get_rate,
+ .set_parent = k210_clk_set_parent,
+ .enable = k210_clk_enable,
+ .disable = k210_clk_disable,
+};
+
+static int k210_clk_probe(struct udevice *dev)
+{
+ int ret;
+ struct k210_clk_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr_ptr(dev_get_parent(dev));
+ if (!priv->base)
+ return -EINVAL;
+
+ ret = clk_get_by_index(dev, 0, >in0);
+ if (ret)
+ return ret;
+
+ /*
+* Force setting defaults, even before relocation. This is so we can
+* set the clock rate for PLL1 before we relocate into aisram.
+*/
+ if (!(gd->flags & GD_FLG_RELOC))
+ clk_set_defaults(dev, CLK_DEFAULTS_POST_FORCE);
+
+ return 0;
+}
+
+static const struct udevice_id k210_clk_ids[] = {
+ { .compatible = "canaan,k210-clk" },
+ { },
+};
+
+U_BOOT_DRIVER(k210_clk) = {
+ .name = "k210_clk",
+ .id = UCLASS_CLK,
+ .of_match = k210_clk_ids,
+ .ops = _clk_ops,
+ .probe = k210_clk_probe,
+ .priv_auto = sizeof(struct k210_clk_priv),
+};
--
2.34.1
[RFC PATCH v2 2/7] clk: ast2600: Move soc_clk_dump function
Move clock dump function to avoid forward declaration after switching to
dump in clk_ops.
Signed-off-by: Igor Prusov
---
drivers/clk/aspeed/clk_ast2600.c | 70
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index e5ada5b6d4..b3cc8392fa 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1104,41 +1104,6 @@ static int ast2600_clk_enable(struct clk *clk)
return 0;
}
-struct clk_ops ast2600_clk_ops = {
- .get_rate = ast2600_clk_get_rate,
- .set_rate = ast2600_clk_set_rate,
- .enable = ast2600_clk_enable,
-};
-
-static int ast2600_clk_probe(struct udevice *dev)
-{
- struct ast2600_clk_priv *priv = dev_get_priv(dev);
-
- priv->scu = devfdt_get_addr_ptr(dev);
- if (IS_ERR(priv->scu))
- return PTR_ERR(priv->scu);
-
- ast2600_init_rgmii_clk(priv->scu, _clk_defconfig);
- ast2600_init_rmii_clk(priv->scu, _clk_defconfig);
- ast2600_configure_mac12_clk(priv->scu);
- ast2600_configure_mac34_clk(priv->scu);
- ast2600_configure_rsa_ecc_clk(priv->scu);
-
- return 0;
-}
-
-static int ast2600_clk_bind(struct udevice *dev)
-{
- int ret;
-
- /* The reset driver does not have a device node, so bind it here */
- ret = device_bind_driver(gd->dm_root, "ast_sysreset", "reset", );
- if (ret)
- debug("Warning: No reset driver: ret=%d\n", ret);
-
- return 0;
-}
-
struct aspeed_clks {
ulong id;
const char *name;
@@ -1203,6 +1168,41 @@ int soc_clk_dump(void)
return 0;
}
+struct clk_ops ast2600_clk_ops = {
+ .get_rate = ast2600_clk_get_rate,
+ .set_rate = ast2600_clk_set_rate,
+ .enable = ast2600_clk_enable,
+};
+
+static int ast2600_clk_probe(struct udevice *dev)
+{
+ struct ast2600_clk_priv *priv = dev_get_priv(dev);
+
+ priv->scu = devfdt_get_addr_ptr(dev);
+ if (IS_ERR(priv->scu))
+ return PTR_ERR(priv->scu);
+
+ ast2600_init_rgmii_clk(priv->scu, _clk_defconfig);
+ ast2600_init_rmii_clk(priv->scu, _clk_defconfig);
+ ast2600_configure_mac12_clk(priv->scu);
+ ast2600_configure_mac34_clk(priv->scu);
+ ast2600_configure_rsa_ecc_clk(priv->scu);
+
+ return 0;
+}
+
+static int ast2600_clk_bind(struct udevice *dev)
+{
+ int ret;
+
+ /* The reset driver does not have a device node, so bind it here */
+ ret = device_bind_driver(gd->dm_root, "ast_sysreset", "reset", );
+ if (ret)
+ debug("Warning: No reset driver: ret=%d\n", ret);
+
+ return 0;
+}
+
static const struct udevice_id ast2600_clk_ids[] = {
{ .compatible = "aspeed,ast2600-scu", },
{ },
--
2.34.1
[RFC PATCH v2 0/7] clk: Switch from soc_clk_dump to clk_ops function
Currently clock providers may override default implementation of soc_clk_dump function to replace clk dump command output. This causes confusing behaviour when u-boot is built with one of such drivers enabled but still has clocks defined using CCF. For example, enabling CMD_CLK and using clk dump on sandbox target will not show CCF clocks because k210 driver overrides common soc_clk_dump. Changelog: v1 -> v2: - Add missing static to dump functions Igor Prusov (7): clk: zynq: Move soc_clk_dump to Zynq clock driver clk: ast2600: Move soc_clk_dump function clk: k210: Move soc_clk_dump function clk: Add dump operation to clk_ops cmd: clk: Use dump function from clk_ops clk: treewide: switch to clock dump from clk_ops cmd: clk: Remove __weak from soc_clk_dump arch/arm/mach-zynq/clk.c | 57 -- arch/mips/mach-pic32/cpu.c | 23 -- cmd/clk.c | 13 +++- drivers/clk/aspeed/clk_ast2600.c | 83 ++-- drivers/clk/clk_k210.c | 103 - drivers/clk/clk_pic32.c| 39 ++ drivers/clk/clk_versal.c | 7 +- drivers/clk/clk_zynq.c | 51 drivers/clk/clk_zynqmp.c | 13 ++-- drivers/clk/imx/clk-imx8.c | 11 +-- drivers/clk/mvebu/armada-37xx-periph.c | 5 +- drivers/clk/stm32/clk-stm32mp1.c | 29 ++- include/clk-uclass.h | 3 + 13 files changed, 223 insertions(+), 214 deletions(-) -- 2.34.1
[RFC PATCH v2 1/7] clk: zynq: Move soc_clk_dump to Zynq clock driver
Move clock dump function in preparation for switching to dump function
in clk_ops.
Signed-off-by: Igor Prusov
---
arch/arm/mach-zynq/clk.c | 57 ---
drivers/clk/clk_zynq.c | 58
2 files changed, 58 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-zynq/clk.c b/arch/arm/mach-zynq/clk.c
index 1945f60e08..e6a67326dd 100644
--- a/arch/arm/mach-zynq/clk.c
+++ b/arch/arm/mach-zynq/clk.c
@@ -13,20 +13,6 @@
DECLARE_GLOBAL_DATA_PTR;
-static const char * const clk_names[clk_max] = {
- "armpll", "ddrpll", "iopll",
- "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x",
- "ddr2x", "ddr3x", "dci",
- "lqspi", "smc", "pcap", "gem0", "gem1",
- "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
- "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma",
- "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper",
- "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper",
- "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
- "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper",
- "smc_aper", "swdt", "dbg_trc", "dbg_apb"
-};
-
/**
* set_cpu_clk_info() - Setup clock information
*
@@ -65,46 +51,3 @@ int set_cpu_clk_info(void)
return 0;
}
-
-/**
- * soc_clk_dump() - Print clock frequencies
- * Returns zero on success
- *
- * Implementation for the clk dump command.
- */
-int soc_clk_dump(void)
-{
- struct udevice *dev;
- int i, ret;
-
- ret = uclass_get_device_by_driver(UCLASS_CLK,
- DM_DRIVER_GET(zynq_clk), );
- if (ret)
- return ret;
-
- printf("clk\t\tfrequency\n");
- for (i = 0; i < clk_max; i++) {
- const char *name = clk_names[i];
- if (name) {
- struct clk clk;
- unsigned long rate;
-
- clk.id = i;
- ret = clk_request(dev, );
- if (ret < 0)
- return ret;
-
- rate = clk_get_rate();
-
- clk_free();
-
- if ((rate == (unsigned long)-ENOSYS) ||
- (rate == (unsigned long)-ENXIO))
- printf("%10s%20s\n", name, "unknown");
- else
- printf("%10s%20lu\n", name, rate);
- }
- }
-
- return 0;
-}
diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index e80500e382..be5226175f 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -454,6 +454,64 @@ static int dummy_enable(struct clk *clk)
return 0;
}
+static const char * const clk_names[clk_max] = {
+ "armpll", "ddrpll", "iopll",
+ "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x",
+ "ddr2x", "ddr3x", "dci",
+ "lqspi", "smc", "pcap", "gem0", "gem1",
+ "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+ "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma",
+ "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper",
+ "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper",
+ "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
+ "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper",
+ "smc_aper", "swdt", "dbg_trc", "dbg_apb"
+};
+
+/**
+ * soc_clk_dump() - Print clock frequencies
+ * Returns zero on success
+ *
+ * Implementation for the clk dump command.
+ */
+int soc_clk_dump(void)
+{
+ struct udevice *dev;
+ int i, ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(zynq_clk), );
+ if (ret)
+ return ret;
+
+ printf("clk\t\tfrequency\n");
+ for (i = 0; i < clk_max; i++) {
+ const char *name = clk_names[i];
+
+ if (name) {
+ struct clk clk;
+ unsigned long rate;
+
+ clk.id = i;
+ ret = clk_request(dev, );
+ if (ret < 0)
+ return ret;
+
+ rate = clk_get_rate();
+
+ clk_free();
+
+ if ((rate == (unsigned long)-ENOSYS) ||
+ (rate == (unsigned long)-ENXIO))
+ printf("%10s%20s\n", name, "unknown");
+ else
+ printf("%10s%20lu\n", name, rate);
+ }
+ }
+
+ return 0;
+}
+
static struct clk_ops zynq_clk_ops = {
.get_rate = zynq_clk_get_rate,
#ifndef CONFIG_SPL_BUILD
--
2.34.1
Re: [PATCH] pci: ecm generic: use dev_read_() interface
On Sat, Feb 18, 2023 at 05:55:25PM +0530, Mayuresh Chitale wrote: > Use dev_read_() api instead of the fdtdec API to fetch the host > controller's reg property value. This is similar to the other host > controller drivers such as Sifive, Rockchip etc. Without this change, > enabling CONFIG_OF_LIVE breaks the PCIe enumeration on Qemu Risc-V virt > machine. The issue is described in the link below: > > Link: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/1 > Signed-off-by: Mayuresh Chitale > Reviewed-by: Simon Glass > --- > drivers/pci/pcie_ecam_generic.c | 21 - > 1 file changed, 8 insertions(+), 13 deletions(-) This breaks some platforms such as qemu_arm at a minimum. -- Tom signature.asc Description: PGP signature
Re: [PATCH] build_bug.h: Also define static_assert() when __CHECKER__ is defined
On Thu, Jan 26, 2023 at 07:17:48PM +0100, Christophe Leroy wrote: > When doing a build with C=2, the following failure is encountered on > several files: > > CHECK arch/powerpc/cpu/mpc8xxx/fsl_lbc.c > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c: note: in included file (through > arch/powerpc/include/asm/global_data.h, include/init.h): > include/asm-generic/global_data.h:494:21: error: Expected ) in function > declarator > include/asm-generic/global_data.h:494:21: error: got ( > > And because of the error, the interesting part which are the > warnings don't appear. This is because static_assert() is defined > only when __CHECKER__ is not defined. > > Add a stub when __CHECKER__ is defined. With that fix, the expected > warnings are now seen: > > CHECK arch/powerpc/cpu/mpc8xxx/fsl_lbc.c > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49:got unsigned int * > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26:expected unsigned int > volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26:got unsigned int > [usertype] *mxmr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:41: warning: incorrect type in > argument 1 (different address spaces) > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:41:expected unsigned int > const volatile [noderef] *addr > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:41:got
Re: Pull request: please pull u-boot-imx-20230503
On Wed, May 03, 2023 at 01:37:28PM +0200, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > > The following changes since commit 50f64026f7a4c2d0a101c93916e01782e4fbbe7f: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-spi (2023-05-01 13:29:52 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20230503 > > for you to fetch changes up to bb6ea0fe9290b4d64df8e716b58515b5325c2ea5: > > usb: ehci-mx6: move phy setup before register access (2023-05-02 10:57:32 > +0200) > So, both my HW test and CI is fine, so I've applied this. But please note we now have this scary message to fix: +(imx8qm_dmsse20a1) aarch64-linux-ld.bfd: invalid origin for memory region .sdram -- Tom signature.asc Description: PGP signature
Re: [PATCH v11 06/10] arm_ffa: introduce sandbox FF-A support
Hi Simon,
> Hi Abdellatif,
>
> On Wed, 12 Apr 2023 at 03:43, Abdellatif El Khlifi
> wrote:
> >
> > Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
> >
> > Features of the sandbox FF-A support:
> >
> > - Introduce an FF-A emulator
> > - Introduce an FF-A device driver for FF-A comms with emulated Secure World
> > - Provides test methods allowing to read the status of the inspected ABIs
> >
> > The sandbox FF-A emulator supports only 64-bit direct messaging.
> >
> > Signed-off-by: Abdellatif El Khlifi
> > Cc: Tom Rini
> > Cc: Simon Glass
> > Cc: Ilias Apalodimas
> > Cc: Jens Wiklander
> > Cc: Heinrich Schuchardt
> >
> > ---
> > Changelog:
> > ===
> >
> > v11:
> >
> > * rename ffa_try_discovery() to sandbox_ffa_discover()
> > * rename sandbox_ffa_query_core_state() to sandbox_query_ffa_emul_state()
> > * store the sandbox emulator pointer in the FF-A device uc_priv (struct
> > ffa_priv)
> > * set the emulator as parent of the sandbox FF-A device
>
> This is close, but not quite what I expected.
>
> I suspect the emulator should be the child of the FF-A device, not the
> parent? You should update the devicetree to show that. You should not
> need to reparent anything.
>
> Then you put this in your FFA uclass so it binds the emulator:
>
> .post_bind = dm_scan_fdt_dev,
>
Thanks. Sorry for the late reply, I was in holidays.
I made few tweaks based on your suggestion and this will be in v12 patchset
(work in progress).
In v12, reparenting will be removed and DT will be used to reflect the
relationship between
the emulator and the FF-A device. Also, dm_scan_fdt_dev() is used to bind the
child.
However, in case of FF-A the emulator should be the parent.
Please refer to the explanation below for more details.
DT nodes: (tested and works)
arm-ffa-emul {
compatible = "sandbox,arm-ffa-emul";
sandbox-arm-ffa {
compatible = "sandbox,arm-ffa";
};
};
In real HW, the secure side exists before the FF-A device is set up.
The FF-A device needs the secure side up and running so it can query the FF-A
framework version during FF-A discovery.
The same concept is followed in sandbox mode:
- The emulator device is the parent of the FF-A device. So, the emulator priv
exists in memory before the FF-A device is bound.
The emulator priv contains the secure side data (i.e: FF-A framework version)
- The FF-A device is the child, when bound it discovers FF-A framework by
querying the version from the emulator
I hope this suggestion makes sense to you.
Cheers,
Abdellatif
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Wed, May 3, 2023 at 9:37 AM Ilias Apalodimas wrote: > > Hi Krzysztof, > > On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: > > On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: > > > From: Jassi Brar > > > > > > Any requirement of FWU should not require changes to bindings > > > of other subsystems. For example, for mtd-backed storage we > > > can do without requiring 'fixed-partitions' children to also > > > carry 'uuid', a property which is non-standard and not in the > > > bindings. > > > > > > There exists no code yet, so we can change the fwu-mtd bindings > > > to contain all properties within the fwu-mdata node. > > > > > > Signed-off-by: Jassi Brar > > > --- > > > > > > Hi Rob, Hi Krzysztof, > > > > > > I was suggested, and I agree, it would be a good idea to get your > > > blessings > > > for the location and meta-data (fwu-mdata) bindings for the FWU. > > > > > > The FWU images can be located in GPT partitions or MTD backed storage. > > > The basic bindings for fwu-mdata has already been merged in uboot > > > (ideally they > > > too should have had your review). Now I am trying to fully support MTD > > > backed > > > storage and hence looking for your review. The proposed bindings are > > > totally > > > self-contained and don't require changes to any other subsystem. > > > > > > Thanks. > > > > I think we do not review U-Boot bindings usually, except these put in > > the Linux kernel. There were few targeting U-Boot specifically (e.g. > > Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and > > Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want > > our blessing, the bindings should be done in Linux kernel repo. > > > > I am pretty sure that reviewing other project bindings would be too much > > of work for me. > > Sure that makes sense. But an answer here of whether the bindings make > sense to the DT maintainers or not would help to move forward. I have lots of comments on the bindings, but I'm missing what is the problem to solve. Yes, it's 'A/B firmware updates', but what configuration data do you need, why and when do you need it. IOW, give me enough information to understand why a binding is designed the way it is and be able to propose alternatives. That's easy enough to deduce for the GPT case. It's just needing to know which device has the f/w update GPT? That's easily solved with an alias, a boolean property in the device, or property with the disk GUID. All of those options are much more simple than a whole node and compatible. > These bindings are trying to define a standardized interface for A/B > *firmware* > updates [0] which is not what traditionally goes into a device tree. OTOH we > already have some U-Boot specific bindings as you already mentioned. As we > move forward we need to be very precise on what is allowed or not on the DT > since it's now tested and verified on SystemReady certifications. IOW if > we add those binding in U-Boot only, we would need to strip them before > handing the DT to linux, otherwise certification would fail. If you do > think that having them in the kernel repo makes sense, it would help > standardizing other boot loaders (at least it would standardize where that > metadata lives) if they want to implement something similar. I think it is fine if u-boot has things in DT which aren't an ABI, so private and bundled, but I agree those should be stripped before passing. To put it another way, if it's not an ABI nor shared amongst projects, I don't think we need a schema nor to care outside of u-boot. However, it doesn't seem to me that needs for A/B updates would be unique to u-boot. > Just keep in mind we would need a schema per storage medium. IOW this tries > to > standardize devices which keep the firmware binary in an mtd. There's also > another biding which describes firmware files on a GPT [1]. I'm assuming it's per partition type rather than storage medium (e.g. SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT partition bindings, etc. If so, then I'm really wondering why it's a standalone tree rather than integrated into those existing partition bindings. Rob
Re: Please pull u-boot-marvell/master
On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull this next batch of mostly Marvell related patches: NAK. With commit: commit 461fa17970de418a93832f734a595031c0b72128 Author: Pali Rohár Date: Thu Apr 13 22:57:48 2023 +0200 mmc: Read eMMC partition access bits before card reset eMMC specification in section "Access partitions" says that all reset events will restore the access bits in PARTITION_CONFIG CSD register to default User Data Area value (0b000). So read partition access bits from PARTITION_CONFIG CSD register before issuing card reset. This allows SPL/U-Boot to get information which eMMC partition was in use before SPL/U-Boot was booted. For some platforms this is the way how to determinate boot partition from which BootROM loaded SPL. Signed-off-by: Pali Rohár My am335x_evm now fails to boot with: U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) Trying to boot from MMC1 omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed with error: -110 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I can provide more details / test patches as needed. -- Tom signature.asc Description: PGP signature
[PATCH 1/1] doc: man-page for cp
Add a man-page for the cp command. Signed-off-by: Heinrich Schuchardt --- v2: replace the 'word' by 'chunk' fix typos --- doc/usage/cmd/cp.rst | 83 doc/usage/index.rst | 1 + 2 files changed, 84 insertions(+) create mode 100644 doc/usage/cmd/cp.rst diff --git a/doc/usage/cmd/cp.rst b/doc/usage/cmd/cp.rst new file mode 100644 index 00..24c5fdae6d --- /dev/null +++ b/doc/usage/cmd/cp.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +cp command +== + +Synopsis + + +:: + +cp source target count +cp.b source target count +cp.w source target count +cp.l source target count +cp.q source target count + +Description +--- + +The cp command is used to copy *count* chunks of memory from the *source* +address to the *target* address. If the *target* address points to NOR flash, +the flash is programmed. + +The number bytes in one chunk is defined by the suffix defaulting to 4 bytes: + +== == +suffix chunk size +== == +.b 1 byte +.w 2 bytes +.l 4 bytes +.q 8 bytes + 4 bytes +== + +source +source address, hexadecimal + +target +target address, hexadecimal + +count +number of words to be copied, hexadecimal + +Examples + + +The example device has a NOR flash where the lower part of the flash is +protected. We first copy to RAM, then to unprotected flash. Last we try to +write to protectd flash. + +:: + +=> mtd list +List of MTD devices: +* nor0 + - device: flash@0 + - parent: root_driver + - driver: cfi_flash + - path: /flash@0 + - type: NOR flash + - block size: 0x2 bytes + - min I/O: 0x1 bytes + - 0x-0x0200 : "nor0" +=> cp.b 402 500 20 +=> cp.b 402 1e0 2 +Copy to Flash... done +=> cp.b 402 0 2 +Copy to Flash... Can't write to protected Flash sectors +=> + +Configuration +- + +The cp command is available if CONFIG_CMD_MEMORY=y. Support for 64 bit words +(cp.q) depends on CONFIG_MEM_SUPPORT_64BIT_DATA=y. Copying to flash depends on +CONFIG_MTD_NOR_FLASH=y. + +Return value + + +The return value $? is set to 0 (true) if the command was successfully, +1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index cdf710919a..0fde130a54 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -41,6 +41,7 @@ Shell commands cmd/cmp cmd/coninfo cmd/conitrace + cmd/cp cmd/cyclic cmd/dm cmd/ebtupdate -- 2.39.2
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 03.05.23 14:56, Neha Malcom Francis wrote: > Hi Jan, > > On 03/05/23 12:57, Neha Malcom Francis wrote: >> Hi Tom >> >> On 27/04/23 04:07, Tom Rini wrote: >>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>> This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) >>> >>> So, next up is fixing this in CI. After taking Andrew's patch to fix the >>> typedef issue, and after my patches to ensure we can get >>> pyyaml/jsonschema for python, there's problems still: >> >> >> Thanks for checking this! Couple things: >> >>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input >>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >> >> 1. This is dependent on the patch merging J721S2 HS and GP configs >> [1]. However it has been reverted on -next, seen in the same thread. >> >>> >>> And then: >>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>> I've fixed this, minor but serious change. >> >> 2. Regarding iot2050, build fails since it uses >> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >> try moving iot2050 to binman as well. > > I'll need some help with this, might need to know the bootloader flow to > make a clean migration. Where do I have to look at? Is there a git repo with that experiment somewhere? Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On 03/05/2023 18:26, Tom Rini wrote: I think we do not review U-Boot bindings usually, except these put in the Linux kernel. There were few targeting U-Boot specifically (e.g. Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want our blessing, the bindings should be done in Linux kernel repo. I am pretty sure that reviewing other project bindings would be too much of work for me. >>> >>> Sure that makes sense. But an answer here of whether the bindings make >>> sense to the DT maintainers or not would help to move forward. >> >> I am not a DT maintainer of other systems, components etc. Answering >> anything for these other systems and components means nothing. I will >> take no responsibility of whatever I say because I will bear no costs of >> it. :) IOW, to me you can make any invalid binding inside U-Boot and it >> will not matter for the Linux kernel. It will of course matter to U-Boot >> in many aspects. >> >>> >>> These bindings are trying to define a standardized interface for A/B >>> *firmware* >>> updates [0] which is not what traditionally goes into a device tree. OTOH >>> we >>> already have some U-Boot specific bindings as you already mentioned. As we >>> move forward we need to be very precise on what is allowed or not on the DT >>> since it's now tested and verified on SystemReady certifications. >>> IOW if >>> we add those binding in U-Boot only, we would need to strip them before >>> handing the DT to linux, otherwise certification would fail. >> >> Which you can. >> >> Or propose to add the bindings to the Linux kernel and to the Linux >> kernel DTS, which then will get our review. >> >>> If you do >>> think that having them in the kernel repo makes sense, it would help >>> standardizing other boot loaders (at least it would standardize where that >>> metadata lives) if they want to implement something similar. >> >> I cannot speak for Rob, but that's the only way I can make a review. I >> cannot review or try to maintain all possible projects in the world and >> their bindings. How would this even work in practice? >> >>> >>> Just keep in mind we would need a schema per storage medium. IOW this >>> tries to >>> standardize devices which keep the firmware binary in an mtd. There's also >>> another biding which describes firmware files on a GPT [1]. >>> >>> [0] https://developer.arm.com/documentation/den0118/a >>> [1] >>> https://source.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml > > This is one of the bindings that we need to upstream to > https://github.com/devicetree-org/dt-schema/ Sure, this works as well. Best regards, Krzysztof
Re: [PATCH 1/1] arm64: dts: ti: k3-j721s2: Add reserved status in msmc
On 03/05/2023 16:51, Nishanth Menon wrote: > On 20:17-20230503, Udit Kumar wrote: >> Mark atf, l3-cache and tifs node as reserved. > > why? (I am not reading the cover-letter for a 1 patch) And you should not have to. :) The commit msg should explain why it is useful. Best regards, Krzysztof
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Wed, May 03, 2023 at 04:54:45PM +0200, Krzysztof Kozlowski wrote: > On 03/05/2023 16:37, Ilias Apalodimas wrote: > > Hi Krzysztof, > > > > On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: > >> On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: > >>> From: Jassi Brar > >>> > >>> Any requirement of FWU should not require changes to bindings > >>> of other subsystems. For example, for mtd-backed storage we > >>> can do without requiring 'fixed-partitions' children to also > >>> carry 'uuid', a property which is non-standard and not in the > >>> bindings. > >>> > >>> There exists no code yet, so we can change the fwu-mtd bindings > >>> to contain all properties within the fwu-mdata node. > >>> > >>> Signed-off-by: Jassi Brar > >>> --- > >>> > >>> Hi Rob, Hi Krzysztof, > >>> > >>> I was suggested, and I agree, it would be a good idea to get your > >>> blessings > >>> for the location and meta-data (fwu-mdata) bindings for the FWU. > >>> > >>> The FWU images can be located in GPT partitions or MTD backed storage. > >>> The basic bindings for fwu-mdata has already been merged in uboot > >>> (ideally they > >>> too should have had your review). Now I am trying to fully support MTD > >>> backed > >>> storage and hence looking for your review. The proposed bindings are > >>> totally > >>> self-contained and don't require changes to any other subsystem. > >>> > >>> Thanks. > >> > >> I think we do not review U-Boot bindings usually, except these put in > >> the Linux kernel. There were few targeting U-Boot specifically (e.g. > >> Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and > >> Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want > >> our blessing, the bindings should be done in Linux kernel repo. > >> > >> I am pretty sure that reviewing other project bindings would be too much > >> of work for me. > > > > Sure that makes sense. But an answer here of whether the bindings make > > sense to the DT maintainers or not would help to move forward. > > I am not a DT maintainer of other systems, components etc. Answering > anything for these other systems and components means nothing. I will > take no responsibility of whatever I say because I will bear no costs of > it. :) IOW, to me you can make any invalid binding inside U-Boot and it > will not matter for the Linux kernel. It will of course matter to U-Boot > in many aspects. > > > > > These bindings are trying to define a standardized interface for A/B > > *firmware* > > updates [0] which is not what traditionally goes into a device tree. OTOH > > we > > already have some U-Boot specific bindings as you already mentioned. As we > > move forward we need to be very precise on what is allowed or not on the DT > > since it's now tested and verified on SystemReady certifications. > > IOW if > > we add those binding in U-Boot only, we would need to strip them before > > handing the DT to linux, otherwise certification would fail. > > Which you can. > > Or propose to add the bindings to the Linux kernel and to the Linux > kernel DTS, which then will get our review. > > > If you do > > think that having them in the kernel repo makes sense, it would help > > standardizing other boot loaders (at least it would standardize where that > > metadata lives) if they want to implement something similar. > > I cannot speak for Rob, but that's the only way I can make a review. I > cannot review or try to maintain all possible projects in the world and > their bindings. How would this even work in practice? > > > > > Just keep in mind we would need a schema per storage medium. IOW this > > tries to > > standardize devices which keep the firmware binary in an mtd. There's also > > another biding which describes firmware files on a GPT [1]. > > > > [0] https://developer.arm.com/documentation/den0118/a > > [1] > > https://source.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml This is one of the bindings that we need to upstream to https://github.com/devicetree-org/dt-schema/ and so in this case there's less likely to be interest from purely Linux kernel centric reviewers. Once it's there, the dts nodes and so forth can be in the trees that end up in the kernel, since they will pass validation. In so far as I understand what the plan for everything is, at least. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] arm: dts: imx8mn: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 11:08 AM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Sync imx8mn.dtsi with Linux 6.3.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/dts/imx8mn.dtsi | 46 ++--
> 1 file changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mn.dtsi b/arch/arm/dts/imx8mn.dtsi
> index cb2836bfbd95..9e0ddd6b7a32 100644
> --- a/arch/arm/dts/imx8mn.dtsi
> +++ b/arch/arm/dts/imx8mn.dtsi
> @@ -139,6 +139,7 @@
> A53_L2: l2-cache0 {
> compatible = "cache";
> cache-level = <2>;
> + cache-unified;
> cache-size = <0x8>;
> cache-line-size = <64>;
> cache-sets = <512>;
> @@ -295,6 +296,7 @@
> sai2: sai@3002 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3002 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = < IMX8MN_CLK_SAI2_IPG>,
> < IMX8MN_CLK_DUMMY>,
> @@ -309,6 +311,7 @@
> sai3: sai@3003 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3003 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = < IMX8MN_CLK_SAI3_IPG>,
> < IMX8MN_CLK_DUMMY>,
> @@ -323,6 +326,7 @@
> sai5: sai@3005 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3005 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = < IMX8MN_CLK_SAI5_IPG>,
> < IMX8MN_CLK_DUMMY>,
> @@ -339,6 +343,7 @@
> sai6: sai@3006 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3006 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = < IMX8MN_CLK_SAI6_IPG>,
> < IMX8MN_CLK_DUMMY>,
> @@ -396,6 +401,7 @@
> sai7: sai@300b {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x300b 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = < IMX8MN_CLK_SAI7_IPG>,
> < IMX8MN_CLK_DUMMY>,
> @@ -497,6 +503,8 @@
> compatible = "fsl,imx8mn-tmu",
> "fsl,imx8mm-tmu";
> reg = <0x3026 0x1>;
> clocks = < IMX8MN_CLK_TMU_ROOT>;
> + nvmem-cells = <_calib>;
> + nvmem-cell-names = "calib";
> #thermal-sensor-cells = <0>;
> };
>
> @@ -551,7 +559,7 @@
> reg = <0x3033 0x1>;
> };
>
> - gpr: iomuxc-gpr@3034 {
> + gpr: syscon@3034 {
> compatible = "fsl,imx8mn-iomuxc-gpr",
> "syscon";
> reg = <0x3034 0x1>;
> };
> @@ -563,23 +571,40 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - imx8mn_uid: unique-id@410 {
> + /*
> +* The register address below maps to the MX8M
> +* Fusemap Description Table entries this way.
> +* Assuming
> +* reg = ;
> +* then
> +* Fuse Address = (ADDR * 4) + 0x400
> +* Note that if SIZE is greater than 4, then
> +
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 11:09 AM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Sync imx8mp.dtsi and imx8mp-clock.h with Linux 6.3.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/dts/imx8mp.dtsi | 374 ---
> include/dt-bindings/clock/imx8mp-clock.h | 14 +-
> 2 files changed, 270 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
> index bb916a0948a8..a237275ee017 100644
> --- a/arch/arm/dts/imx8mp.dtsi
> +++ b/arch/arm/dts/imx8mp.dtsi
> @@ -123,6 +123,7 @@
>
> A53_L2: l2-cache0 {
> compatible = "cache";
> + cache-unified;
> cache-level = <2>;
> cache-size = <0x8>;
> cache-line-size = <64>;
> @@ -379,6 +380,8 @@
> compatible = "fsl,imx8mp-tmu";
> reg = <0x3026 0x1>;
> clocks = < IMX8MP_CLK_TSENSOR_ROOT>;
> + nvmem-cells = <_calib>;
> + nvmem-cell-names = "calib";
> #thermal-sensor-cells = <1>;
> };
>
> @@ -411,7 +414,7 @@
> reg = <0x3033 0x1>;
> };
>
> - gpr: iomuxc-gpr@3034 {
> + gpr: syscon@3034 {
> compatible = "fsl,imx8mp-iomuxc-gpr",
> "syscon";
> reg = <0x3034 0x1>;
> };
> @@ -424,27 +427,44 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - imx8mp_uid: unique-id@420 {
> + /*
> +* The register address below maps to the MX8M
> +* Fusemap Description Table entries this way.
> +* Assuming
> +* reg = ;
> +* then
> +* Fuse Address = (ADDR * 4) + 0x400
> +* Note that if SIZE is greater than 4, then
> +* each subsequent fuse is located at offset
> +* +0x10 in Fusemap Description Table (e.g.
> +* reg = <0x8 0x8> describes fuses 0x420 and
> +* 0x430).
> +*/
> + imx8mp_uid: unique-id@8 { /* 0x420-0x430 */
> reg = <0x8 0x8>;
> };
>
> - cpu_speed_grade: speed-grade@10 {
> + cpu_speed_grade: speed-grade@10 { /* 0x440 */
> reg = <0x10 4>;
> };
>
> - eth_mac1: mac-address@90 {
> + eth_mac1: mac-address@90 { /* 0x640 */
> reg = <0x90 6>;
> };
>
> - eth_mac2: mac-address@96 {
> + eth_mac2: mac-address@96 { /* 0x658 */
> reg = <0x96 6>;
> };
> +
> + tmu_calib: calib@264 { /* 0xd90-0xdc0 */
> + reg = <0x264 0x10>;
> + };
> };
>
> - anatop: anatop@3036 {
> - compatible = "fsl,imx8mp-anatop",
> "fsl,imx8mm-anatop",
> -"syscon";
> + anatop: clock-controller@3036 {
> + compatible = "fsl,imx8mp-anatop",
> "fsl,imx8mm-anatop";
> reg = <0x3036 0x1>;
> + #clock-cells = <1>;
> };
>
> snvs: snvs@3037 {
> @@ -523,6 +543,7 @@
> compatible = "fsl,imx8mp-gpc";
> reg = <0x303a 0x1000>;
> interrupt-parent = <>;
> + interrupts = ;
> interrupt-controller;
> #interrupt-cells = <3>;
>
> @@ -589,7 +610,7 @@
> reg =
> ;
> };
>
> - pgc_hsiomix: power-domains@17 {
> + pgc_hsiomix: power-domain@17 {
>
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 11:19 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Fri, Apr 28, 2023 at 2:59 PM Tim Harvey wrote:
>
> > I believe the fix we need is the following which moves phy setup
> > before the register access (where it should have been along with the
> > case for !defined(CONFIG_PHY):
> ...
> > If everyone agrees here I'll submit a formal patch which should get
> > applied through Marek via the usb tree before the dt sync.
>
> This works for me, thanks.
>
> When you submit it, feel free to add:
>
> Tested-by: Fabio Estevam
Fabio,
with commit bb6ea0fe9290 ("usb: ehci-mx6: move phy setup before
register access") now in imx/master:
Tested-by: Tim Harvey #imx8mm-venice-gw73xx-0x
Best Regards,
Tim
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On 03/05/2023 16:37, Ilias Apalodimas wrote: > Hi Krzysztof, > > On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: >> On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: >>> From: Jassi Brar >>> >>> Any requirement of FWU should not require changes to bindings >>> of other subsystems. For example, for mtd-backed storage we >>> can do without requiring 'fixed-partitions' children to also >>> carry 'uuid', a property which is non-standard and not in the >>> bindings. >>> >>> There exists no code yet, so we can change the fwu-mtd bindings >>> to contain all properties within the fwu-mdata node. >>> >>> Signed-off-by: Jassi Brar >>> --- >>> >>> Hi Rob, Hi Krzysztof, >>> >>> I was suggested, and I agree, it would be a good idea to get your >>> blessings >>> for the location and meta-data (fwu-mdata) bindings for the FWU. >>> >>> The FWU images can be located in GPT partitions or MTD backed storage. >>> The basic bindings for fwu-mdata has already been merged in uboot (ideally >>> they >>> too should have had your review). Now I am trying to fully support MTD >>> backed >>> storage and hence looking for your review. The proposed bindings are totally >>> self-contained and don't require changes to any other subsystem. >>> >>> Thanks. >> >> I think we do not review U-Boot bindings usually, except these put in >> the Linux kernel. There were few targeting U-Boot specifically (e.g. >> Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and >> Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want >> our blessing, the bindings should be done in Linux kernel repo. >> >> I am pretty sure that reviewing other project bindings would be too much >> of work for me. > > Sure that makes sense. But an answer here of whether the bindings make > sense to the DT maintainers or not would help to move forward. I am not a DT maintainer of other systems, components etc. Answering anything for these other systems and components means nothing. I will take no responsibility of whatever I say because I will bear no costs of it. :) IOW, to me you can make any invalid binding inside U-Boot and it will not matter for the Linux kernel. It will of course matter to U-Boot in many aspects. > > These bindings are trying to define a standardized interface for A/B > *firmware* > updates [0] which is not what traditionally goes into a device tree. OTOH we > already have some U-Boot specific bindings as you already mentioned. As we > move forward we need to be very precise on what is allowed or not on the DT > since it's now tested and verified on SystemReady certifications. > IOW if > we add those binding in U-Boot only, we would need to strip them before > handing the DT to linux, otherwise certification would fail. Which you can. Or propose to add the bindings to the Linux kernel and to the Linux kernel DTS, which then will get our review. > If you do > think that having them in the kernel repo makes sense, it would help > standardizing other boot loaders (at least it would standardize where that > metadata lives) if they want to implement something similar. I cannot speak for Rob, but that's the only way I can make a review. I cannot review or try to maintain all possible projects in the world and their bindings. How would this even work in practice? > > Just keep in mind we would need a schema per storage medium. IOW this tries > to > standardize devices which keep the firmware binary in an mtd. There's also > another biding which describes firmware files on a GPT [1]. > > [0] https://developer.arm.com/documentation/den0118/a > [1] > https://source.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml Best regards, Krzysztof
Re: [PATCH v2 30/30] CI: Enable sandbox build for Windows
Hi Simon,
On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote:
>
> Add a new rule to build sandbox for Windows. For now, no tests are run in
> this configuration.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Update the cover letter to better explain the motivation
>
> .azure-pipelines.yml | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index 76ffdeebd667..d15a86ff3650 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -39,6 +39,33 @@ stages:
># Tell MSYS2 not to ‘cd’ our startup directory to HOME
>CHERE_INVOKING: yes
>
> + - job: sandbox_windows
> +displayName: 'Ensure sandbox build for Windows'
> +pool:
> + vmImage: $(windows_vm)
> +steps:
> + - powershell: |
> + (New-Object
> Net.WebClient).DownloadFile("https://github.com/msys2/msys2-installer/releases/download/2021-06-04/msys2-base-x86_64-20210604.sfx.exe;,
> "sfx.exe")
> +displayName: 'Install MSYS2'
> + - script: |
> + sfx.exe -y -o%CD:~0,2%\
> + %CD:~0,2%\msys64\usr\bin\bash -lc " "
> + %CD:~0,2%\msys64\usr\bin\bash -lc "pacman --noconfirm -Syuu"
> + %CD:~0,2%\msys64\usr\bin\bash -lc "pacman --noconfirm -Syuu"
> +displayName: 'Update MSYS2'
> + - script: |
> + %CD:~0,2%\msys64\usr\bin\bash -lc "pacman --noconfirm --needed -Sy
> bc bison diffutils flex gcc libgnutls-devel libutil-linux-devel make
> openssl-devel python python-setuptools swig"
> +displayName: 'Install Toolchain'
> + - script: |
> + echo make sandbox_defconfig all > build-tools.sh
nits: build-sandbox.sh
> + %CD:~0,2%\msys64\usr\bin\bash -lc "bash build-tools.sh"
> +displayName: 'Build sandbox'
> +env:
> + # Tell MSYS2 we need a POSIX emulation layer
> + MSYSTEM: MSYS
> + # Tell MSYS2 not to ‘cd’ our startup directory to HOME
> + CHERE_INVOKING: yes
Missed turning on symbolic link config for MSYS2
MSYS: winsymlinks:native
> +
>- job: tools_only_macOS
> displayName: 'Ensure host tools build for macOS X'
> pool:
Regards,
Bin
Re: [PATCH 05/14] arch: arm: dts: k3-j7200: Configure pinctrl for timer IO pad
Thanks Nishanth On 5/3/2023 8:01 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: [..] Needs to get to k.org master. Noted for whole series
Re: [PATCH 02/14] arch: arm: dts: k3-j7200: Fix physical address of pin
Thanks Nishanth On 5/3/2023 7:46 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: [..] Not in upstream k.org. NAK. i will hold this series till updated in k.org
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Wed, May 03, 2023 at 09:51:58AM -0400, Tom Rini wrote: > On Mon, May 01, 2023 at 10:49:22AM +0200, Rasmus Villemoes wrote: > > On 27/04/2023 19.31, Tom Rini wrote: > > >> > > >> Well, I'm not sure there's a use case for building all of the extra > > >> device trees. I think what I'll do right now is fire off a CI run (or a > > >> few, in the event of problems) where we just use the logic of > > >> 3609e1dc5f4d and see what falls down. > > > > > > So this gets us a few failures. You can see them on > > > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > > > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > > > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > > > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > > > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > > > arch/.../foo.dtb and so we don't have the dtb file around. > > > > > > > Hm, the former sounds like a bug in the defconfig, the second sounds > > like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > > should be fixable by just changing the logic of scripts/Makefile.dts a > > little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > > SPL_OF_LIST to dtb-y. Something like > > > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > > index 2561025da8..5e2429c617 100644 > > --- a/scripts/Makefile.dts > > +++ b/scripts/Makefile.dts > > @@ -1,3 +1,3 @@ > > # SPDX-License-Identifier: GPL-2.0+ > > > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > > +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > > OK, lemme see what happens now. Assuming this is enough, please post as > a proper patch, thanks! The one last problem now is on stm32mp15_dhcor_basic which is a defconfig missing one from OF_LIST but including it in the its file, so the above is the patch we need. -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/14] arm: dts: k3-j7200: Update devicetree to sync with v6.3-rc6
On 5/3/2023 7:45 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: From: Nishanth Menon Sync with Kernel.org v6.3-rc6 tag. we are few days away from rc1 tag. I'd rather we refresh. Thanks [..]
Re: [PATCH 1/1] arm64: dts: ti: k3-j721s2: Add reserved status in msmc
On 20:17-20230503, Udit Kumar wrote:
> Mark atf, l3-cache and tifs node as reserved.
why? (I am not reading the cover-letter for a 1 patch)
>
> Signed-off-by: Udit Kumar
> ---
> arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> index 2dd7865f7654..791993060f44 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> @@ -14,14 +14,17 @@ msmc_ram: sram@7000 {
> ranges = <0x0 0x0 0x7000 0x40>;
>
> atf-sram@0 {
> + status = "reserved";
> reg = <0x0 0x2>;
> };
>
> tifs-sram@1f {
> + status = "reserved";
> reg = <0x1f 0x1>;
> };
>
> l3cache-sram@20 {
> + status = "reserved";
> reg = <0x20 0x20>;
> };
> };
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH 1/1] arm64: dts: ti: k3-j721s2: Add reserved status in msmc
mark atf, l3-cache and tifs node as reserved.
Signed-off-by: Udit Kumar
---
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 2dd7865f7654..791993060f44 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -14,14 +14,17 @@ msmc_ram: sram@7000 {
ranges = <0x0 0x0 0x7000 0x40>;
atf-sram@0 {
+ status = "reserved";
reg = <0x0 0x2>;
};
tifs-sram@1f {
+ status = "reserved";
reg = <0x1f 0x1>;
};
l3cache-sram@20 {
+ status = "reserved";
reg = <0x20 0x20>;
};
};
--
2.34.1
[RFC PATCH 0/1] arm64: dts: ti: k3-j721s2: handling subnode of msmc node
TI K3 SOCs have msmc sram, part of it can be configured as L3 cache depending upon system firmware configuration file. This could be possible to have no L3 cache or variable size of L3 cache. In either case top of 64KB of SRAM has to be reserved for system firmware called tifs. https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html?highlight=msmc Section: TISCI_MSG_QUERY_MSMC. But u-boot as part of fix up is deleting sysfw and l3cache node before passing DT to OS https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-k3/common.c#L412 In my view we can handle in two ways 1) delete tifs node as well In this case, only accessible sram will be visible to OS https://lore.kernel.org/all/20230420081128.3617214-1-u-kum...@ti.com/ 2) make these nodes (tifs, atf and l3cache) as reserved, so that OS has complete view of memory. This is patch for option 2. Nishanth suggested to discuss in k.org group https://lore.kernel.org/all/20230502230022.5pjywy6h7oqrkmwh@elusive/ So sending this patch for suggestion for selection right option. Also other options are welcome. Udit Kumar (1): arm64: dts: ti: k3-j721s2: Add reserved status in msmc node. arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1
Re: [PATCH] configs: j7200: correct mmc offset
On 10:58-20230503, Udit Kumar wrote:
> This patch corrects the MMC raw mode sector offset as
> per documentation.
>
> https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/08_06_00_11/exports/docs/j7200/linux/Foundational_Components/U-Boot/UG-Memory.html
>
> Section: eMMC layout
Please drop these TI specific documentation. Instead ADD documentation
into u-boot source explaining these eMMC layout.
NOTE: emmc raw mode for boot partition is one way of using SPL. it is
also very restrictive. u-boot and TIFS, OPTEE all packed into EMMC boot
partition has limits to which it can scale.
On beagle family for example, we choose this is tooo constraining and
chose to go down a different path where the uda partition in fs mode is
used for u-boot, tfa, optee etc.. allowing more maintainable system
instead of having to constantly refactoring the image offsets and sizes
involved.
>
> Without this correct offset eMMC boot with UDA partition will fail.
Where this fails is looking for the next segment of u-boot image in boot
partition, not UDA.
>
> Fixes: f8c1e893c82 (configs: j7200_evm_a72: Add Initial suppot)
> Fixes: 02dff65efe7 (configs: j7200_evm_r5: Add initial support)
> Fixes: 360c7f46f39 (configs: Add configs for J7200 High Security EVM)
>
> Way to test with eMMC UDA partition
>
> => mmc dev 0 0
> => fatload mmc 1 ${loadaddr} tiboot3.bin
> => mmc write ${loadaddr} 0x0 0x800
> => fatload mmc 1 ${loadaddr} tispl.bin
> => mmc write ${loadaddr} 0x800 0x1000
> => fatload mmc 1 ${loadaddr} u-boot.img
> => mmc write ${loadaddr} 0x1800 0x2000
> => mmc partconf 0 1 7 1
> => mmc bootbus 0 2 0 0
>
> Cc: Bhavya Kapoor
> Cc: Diwakar Dhyani
> Cc: KEERTHY
> Signed-off-by: Udit Kumar
> ---
> configs/j7200_evm_a72_defconfig| 2 +-
> configs/j7200_evm_r5_defconfig | 2 +-
> configs/j7200_hs_evm_a72_defconfig | 2 +-
> configs/j7200_hs_evm_r5_defconfig | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
> index fa5ea2aecd..8a810f8f48 100644
> --- a/configs/j7200_evm_a72_defconfig
> +++ b/configs/j7200_evm_a72_defconfig
> @@ -46,7 +46,7 @@ CONFIG_SPL_STACK_R=y
> CONFIG_SYS_SPL_MALLOC=y
> CONFIG_SYS_SPL_MALLOC_SIZE=0x80
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1800
> CONFIG_SPL_DMA=y
> CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
> diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig
> index 00ec48b83b..908cfaf402 100644
> --- a/configs/j7200_evm_r5_defconfig
> +++ b/configs/j7200_evm_r5_defconfig
> @@ -43,7 +43,7 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
> CONFIG_SYS_SPL_MALLOC_SIZE=0x100
> CONFIG_SPL_EARLY_BSS=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800
> CONFIG_SPL_DMA=y
> CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_FS_EXT4=y
> diff --git a/configs/j7200_hs_evm_a72_defconfig
> b/configs/j7200_hs_evm_a72_defconfig
> index d9560727ed..c234a58a7a 100644
> --- a/configs/j7200_hs_evm_a72_defconfig
> +++ b/configs/j7200_hs_evm_a72_defconfig
> @@ -47,7 +47,7 @@ CONFIG_SPL_STACK_R=y
> CONFIG_SYS_SPL_MALLOC=y
> CONFIG_SYS_SPL_MALLOC_SIZE=0x80
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1800
> CONFIG_SPL_DMA=y
> CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
> diff --git a/configs/j7200_hs_evm_r5_defconfig
> b/configs/j7200_hs_evm_r5_defconfig
> index 94a6523f06..74015db1af 100644
> --- a/configs/j7200_hs_evm_r5_defconfig
> +++ b/configs/j7200_hs_evm_r5_defconfig
> @@ -43,7 +43,7 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
> CONFIG_SYS_SPL_MALLOC_SIZE=0x100
> CONFIG_SPL_EARLY_BSS=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800
> CONFIG_SPL_DMA=y
> CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_FS_EXT4=y
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 14/14] arch: arm: dts: k3-j7200: Add MCSPI nodes
On 09:43-20230503, Udit Kumar wrote:
> From: Vaishnav Achath
>
> Upstream Linux commit id 8f6c475f4ca7a
>
> J7200 has 8 MCSPI instances in the main domain and 3 instances
> in the MCU domain. Add the DT nodes for all the 11 instances and
> keep them disabled. MAIN_MCSPI4 is connected as a slave to MCU_MCSPI2
> by default at power-up, MAIN_MCSPI4 and MCU_MCSPI2 are not pinned out
> externally.
>
> Signed-off-by: Vaishnav Achath
> Reviewed-by: Keerthy
> Link: https://lore.kernel.org/r/20230321082827.14274-3-vaishna...@ti.com
> Signed-off-by: Nishanth Menon
NAK. I have'nt signed-off on u-boot patches. As my first message went -
you will get this for free and save a bunch of the patch repeat by
waiting a few days.. (we are 3-4 days away from 6.4-rc1)..
> ---
> arch/arm/dts/k3-j7200-main.dtsi | 88 +++
> arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 33 ++
> 2 files changed, 121 insertions(+)
>
> diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
> index 3dfbeca4ef..be8034bf5b 100644
> --- a/arch/arm/dts/k3-j7200-main.dtsi
> +++ b/arch/arm/dts/k3-j7200-main.dtsi
> @@ -798,6 +798,94 @@
> clock-names = "gpio";
> };
>
> + main_spi0: spi@210 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0210 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 266 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 266 1>;
> + status = "disabled";
> + };
> +
> + main_spi1: spi@211 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0211 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 267 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 267 1>;
> + status = "disabled";
> + };
> +
> + main_spi2: spi@212 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0212 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 268 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 268 1>;
> + status = "disabled";
> + };
> +
> + main_spi3: spi@213 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0213 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 269 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 269 1>;
> + status = "disabled";
> + };
> +
> + main_spi4: spi@214 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0214 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 270 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 270 1>;
> + status = "disabled";
> + };
> +
> + main_spi5: spi@215 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0215 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 271 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 271 1>;
> + status = "disabled";
> + };
> +
> + main_spi6: spi@216 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0216 0x00 0x400>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <_pds 272 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 272 1>;
> + status = "disabled";
> + };
> +
> + main_spi7: spi@217 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x0217 0x00
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
Hi Krzysztof, On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: > On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: > > From: Jassi Brar > > > > Any requirement of FWU should not require changes to bindings > > of other subsystems. For example, for mtd-backed storage we > > can do without requiring 'fixed-partitions' children to also > > carry 'uuid', a property which is non-standard and not in the > > bindings. > > > > There exists no code yet, so we can change the fwu-mtd bindings > > to contain all properties within the fwu-mdata node. > > > > Signed-off-by: Jassi Brar > > --- > > > > Hi Rob, Hi Krzysztof, > > > > I was suggested, and I agree, it would be a good idea to get your > > blessings > > for the location and meta-data (fwu-mdata) bindings for the FWU. > > > > The FWU images can be located in GPT partitions or MTD backed storage. > > The basic bindings for fwu-mdata has already been merged in uboot (ideally > > they > > too should have had your review). Now I am trying to fully support MTD > > backed > > storage and hence looking for your review. The proposed bindings are totally > > self-contained and don't require changes to any other subsystem. > > > > Thanks. > > I think we do not review U-Boot bindings usually, except these put in > the Linux kernel. There were few targeting U-Boot specifically (e.g. > Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and > Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want > our blessing, the bindings should be done in Linux kernel repo. > > I am pretty sure that reviewing other project bindings would be too much > of work for me. Sure that makes sense. But an answer here of whether the bindings make sense to the DT maintainers or not would help to move forward. These bindings are trying to define a standardized interface for A/B *firmware* updates [0] which is not what traditionally goes into a device tree. OTOH we already have some U-Boot specific bindings as you already mentioned. As we move forward we need to be very precise on what is allowed or not on the DT since it's now tested and verified on SystemReady certifications. IOW if we add those binding in U-Boot only, we would need to strip them before handing the DT to linux, otherwise certification would fail. If you do think that having them in the kernel repo makes sense, it would help standardizing other boot loaders (at least it would standardize where that metadata lives) if they want to implement something similar. Just keep in mind we would need a schema per storage medium. IOW this tries to standardize devices which keep the firmware binary in an mtd. There's also another biding which describes firmware files on a GPT [1]. [0] https://developer.arm.com/documentation/den0118/a [1] https://source.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml Thanks /Ilias > > Best regards, > Krzysztof >
Re: [PATCH 06/14] arch: arm: dts: k3-j7200 move main_pmx to common file
On 09:43-20230503, Udit Kumar wrote:
> This patch moves pin mux from r5 dts to common dts file.
> Along with removing duplicated defines.
>
> Signed-off-by: Udit Kumar
> ---
> arch/arm/dts/k3-j7200-common-proc-board.dts | 16 --
> .../arm/dts/k3-j7200-r5-common-proc-board.dts | 51 +--
> arch/arm/dts/k3-j7200-som-p0.dtsi | 3 ++
> 3 files changed, 17 insertions(+), 53 deletions(-)
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-common-proc-board.dts
> index 63633e4f6c..98d1fde4db 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
> @@ -107,10 +107,15 @@
> };
>
> _pmx0 {
> - main_i2c0_pins_default: main-i2c0-pins-default {
> + bootph-pre-ram;
> +
> + main_uart0_pins_default: main_uart0_pins_default {
> + bootph-pre-ram;
> pinctrl-single,pins = <
> - J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
> */
> - J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
> */
> + J721E_IOPAD(0xb0, PIN_INPUT, 0) /* (T16) UART0_RXD */
> + J721E_IOPAD(0xb4, PIN_OUTPUT, 0) /* (T17) UART0_TXD */
> + J721E_IOPAD(0xc0, PIN_INPUT, 2) /* (W3)
> SPI0_CS0.UART0_CTSn */
> + J721E_IOPAD(0xc4, PIN_OUTPUT, 2) /* (U5)
> SPI0_CS1.UART0_RTSn */
> >;
> };
>
> @@ -122,6 +127,7 @@
> };
>
> main_mmc1_pins_default: main-mmc1-pins-default {
> + bootph-pre-ram;
> pinctrl-single,pins = <
> J721E_IOPAD(0x104, PIN_INPUT, 0) /* (M20) MMC1_CMD */
> J721E_IOPAD(0x100, PIN_INPUT, 0) /* (P21) MMC1_CLK */
> @@ -142,7 +148,9 @@
> };
>
> _pmx1 {
> + bootph-pre-ram;
> main_usbss0_pins_default: main-usbss0-pins-default {
> + bootph-pre-ram;
> pinctrl-single,pins = <
> J721E_IOPAD(0x04, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS */
> >;
> @@ -163,6 +171,8 @@
> status = "okay";
> /* Shared with ATF on this platform */
> power-domains = <_pds 146 TI_SCI_PD_SHARED>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart0_pins_default>;
> };
>
> _uart1 {
> diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> index 9d9ffcbb89..9b42e4d2ca 100644
> --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> @@ -5,7 +5,7 @@
>
> /dts-v1/;
>
> -#include "k3-j7200-som-p0.dtsi"
> +#include "k3-j7200-common-proc-board.dts"
> #include "k3-j7200-ddr-evm-lp4-2666.dtsi"
> #include "k3-j721e-ddr.dtsi"
>
> @@ -152,47 +152,6 @@
> };
> };
>
> -_pmx0 {
> - bootph-pre-ram;
> -
> - main_uart0_pins_default: main_uart0_pins_default {
> - bootph-pre-ram;
> - pinctrl-single,pins = <
> - J721E_IOPAD(0xb0, PIN_INPUT, 0) /* (T16) UART0_RXD */
> - J721E_IOPAD(0xb4, PIN_OUTPUT, 0) /* (T17) UART0_TXD */
> - J721E_IOPAD(0xc0, PIN_INPUT, 2) /* (W3)
> SPI0_CS0.UART0_CTSn */
> - J721E_IOPAD(0xc4, PIN_OUTPUT, 2) /* (U5)
> SPI0_CS1.UART0_RTSn */
> - >;
> - };
> -
> - main_i2c0_pins_default: main-i2c0-pins-default {
> - bootph-pre-ram;
> - pinctrl-single,pins = <
> - J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
> */
> - J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
> */
> - >;
> - };
> -
> - main_mmc1_pins_default: main_mmc1_pins_default {
> - pinctrl-single,pins = <
> - J721E_IOPAD(0x104, PIN_INPUT, 0) /* (M20) MMC1_CMD */
> - J721E_IOPAD(0x100, PIN_INPUT, 0) /* (P21) MMC1_CLK */
> - J721E_IOPAD(0xfc, PIN_INPUT, 0) /* (P25) MMC1_CLKLB */
> - J721E_IOPAD(0xf8, PIN_INPUT, 0) /* (M19) MMC1_DAT0 */
> - J721E_IOPAD(0xf4, PIN_INPUT, 0) /* (N21) MMC1_DAT1 */
> - J721E_IOPAD(0xf0, PIN_INPUT, 0) /* (N20) MMC1_DAT2 */
> - J721E_IOPAD(0xec, PIN_INPUT, 0) /* (N19) MMC1_DAT3 */
> - J721E_IOPAD(0xe4, PIN_INPUT, 8) /* (V1)
> TIMER_IO0.MMC1_SDCD */
> - >;
> - };
> -
> - main_usb
Re: [PATCH 05/14] arch: arm: dts: k3-j7200: Configure pinctrl for timer IO pad
On 09:43-20230503, Udit Kumar wrote:
> There are timer IO pads in the MCU domain, and in the MAIN domain. These
> pads can be muxed for the related timers.
>
> There are timer IO control registers for input and output. The registers
> for CTRLMMR_TIMER*_CTRL and CTRLMMR_MCU_TIMER*_CTRL are used to control
> the input. The registers for CTCTRLMMR_TIMERIO*_CTRL and
> CTRLMMR_MCU_TIMERIO*_CTRL the output.
>
> The multiplexing is documented in TRM "5.1.2.3.1.4 Timer IO Muxing Control
> Registers" and "5.1.3.3.1.5 Timer IO Muxing Control Registers", and the
> CASCADE_EN bit is documented in TRM "12.6.3.1 Timers Overview".
>
> For chaining timers, the timer IO control registers also have a CASCADE_EN
> input bit in the CTRLMMR_TIMER*_CTRL in the registers. The CASCADE_EN bit
> muxes the previous timer output, or possibly and external TIMER_IO pad
> source, to the input clock of the selected timer instance for odd numered
> timers. For the even numbered timers, the CASCADE_EN bit does not do
> anything. The timer cascade input routing options are shown in TRM
> "Figure 12-3224. Timers Overview". For handling beyond multiplexing, the
> driver support for timer cascading should be likely be handled via the
> clock framework.
>
> Cc: Nishanth Menon
> Cc: Vignesh Raghavendra
> Cc: Tony Lindgren
> Signed-off-by: Udit Kumar
> ---
> arch/arm/dts/k3-j7200-main.dtsi | 18 ++
> arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 18 ++
> 2 files changed, 36 insertions(+)
>
> diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
> index 54795db9c3..fb9e4842c1 100644
> --- a/arch/arm/dts/k3-j7200-main.dtsi
> +++ b/arch/arm/dts/k3-j7200-main.dtsi
> @@ -304,6 +304,24 @@
> };
> };
>
> + /* TIMERIO pad input CTRLMMR_TIMER*_CTRL registers */
> + main_timerio_input: pinctrl@104200 {
> + compatible = "pinctrl-single";
> + reg = <0x0 0x104200 0x0 0x50>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x01ff>;
> + };
> +
> + /* TIMERIO pad output CTCTRLMMR_TIMERIO*_CTRL registers */
> + main_timerio_output: pinctrl@104280 {
> + compatible = "pinctrl-single";
> + reg = <0x0 0x104280 0x0 0x20>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x001f>;
> + };
> +
> main_pmx0: pinctrl@11c000 {
> compatible = "pinctrl-single";
> /* Proxy 0 addressing */
> diff --git a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
> b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
> index 02c2493064..7ed6c31c7c 100644
> --- a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
> @@ -183,6 +183,24 @@
> reg = <0x00 0x4314 0x00 0x4>;
> };
>
> + /* MCU_TIMERIO pad input CTRLMMR_MCU_TIMER*_CTRL registers */
> + mcu_timerio_input: pinctrl@40f04200 {
> + compatible = "pinctrl-single";
> + reg = <0x0 0x40f04200 0x0 0x28>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x000F>;
> + };
> +
> + /* MCU_TIMERIO pad output CTRLMMR_MCU_TIMERIO*_CTRL registers */
> + mcu_timerio_output: pinctrl@40f04280 {
> + compatible = "pinctrl-single";
> + reg = <0x0 0x40f04280 0x0 0x28>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x000F>;
> + };
> +
> wkup_pmx0: pinctrl@4301c000 {
> compatible = "pinctrl-single";
> /* Proxy 0 addressing */
> --
> 2.34.1
>
Needs to get to k.org master.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 04/14] arch: arm: dts: k3-j7200: Add general purpose timers
On 09:43-20230503, Udit Kumar wrote:
> There are 20 general purpose timers on j7200 that can be used for things
> like PWM using pwm-omap-dmtimer driver. There are also additional ten
> timers in the MCU domain.
>
> MCU timer 0 is used by R5 uboot as always on. So change properties
> in u-boot specific files
>
> Signed-off-by: Udit Kumar
> ---
NAK. upstream k.org first.
> .../k3-j7200-common-proc-board-u-boot.dtsi| 7 +
> arch/arm/dts/k3-j7200-main.dtsi | 240 ++
> arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 130 ++
> 3 files changed, 377 insertions(+)
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> index f57c2306ba..789dc54617 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> @@ -30,7 +30,14 @@
> bootph-pre-ram;
>
> timer1: timer@4040 {
> + /delete-property/ clocks;
> + /delete-property/ clock-name;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ power-domains;
> + /delete-property/ ti,timer-pwm;
> compatible = "ti,omap5430-timer";
> + status = "okay";
Curious: Do we need to delete all these properties, cant we get the R5 SPL to
work with these?
> reg = <0x0 0x4040 0x0 0x80>;
> ti,timer-alwon;
> clock-frequency = <25000>;
> diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
> index 138381f43c..54795db9c3 100644
> --- a/arch/arm/dts/k3-j7200-main.dtsi
> +++ b/arch/arm/dts/k3-j7200-main.dtsi
> @@ -795,6 +795,246 @@
> assigned-clock-parents = <_clks 253 5>;
> };
>
> + main_timer0: timer@240 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x240 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 49 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 49 1>;
> + assigned-clock-parents = <_clks 49 2>;
> + power-domains = <_pds 49 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer1: timer@241 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x241 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 50 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 50 1>;
> + assigned-clock-parents = <_clks 50 2>;
> + power-domains = <_pds 50 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer2: timer@242 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x242 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 51 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 51 1>;
> + assigned-clock-parents = <_clks 51 2>;
> + power-domains = <_pds 49 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer3: timer@243 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x243 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 52 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 52 1>;
> + assigned-clock-parents = <_clks 52 2>;
> + power-domains = <_pds 52 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer4: timer@244 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x244 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 53 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 53 1>;
> + assigned-clock-parents = <_clks 53 2>;
> + power-domains = <_pds 53 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer5: timer@245 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x245 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 54 1>;
&g
Re: [PATCH] Revert "mmc: rockchip_sdhci: Limit number of blocks read in a single command"
Hi Jonas, On Wed, 3 May 2023 at 08:17, Jonas Karlman wrote: > > Hi Simon, > > On 2023-05-03 14:41, Simon Glass wrote: > > This makes MMC extremely slow on bob. Even reading the environment takes > > ages. > > > > If there is a bug on a particular controller, it should be worked around > > using the compatible string, e.g. with ->flags in struct sdhci_data - > > althought I don't see any docs for the flags. > > This revert will break booting from emmc on rock5b-rk3588. > > An alternative to this revert could be to enable CONFIG_MMC_SDHCI_SDMA > for more rk3399 defconfigs. Using DMA should improve/restore performance. > > I have a followup patch in the works that changes this slightly, can > include a change to only apply this workaround for rk35xx. OK, but please use the compatible string for any workarounds. Regards, Simon
Re: [PATCH 03/14] arch: arm: dts: k3-j7200-som: Enable I2C
On 09:43-20230503, Udit Kumar wrote:
> Upstream linux patch posted at
> https://lore.kernel.org/all/20230419040007.3022780-3-u-kum...@ti.com/
>
a) link here does'nt belong to commit message.
b) Let this be accepted into k.org master prior to u-boot sync.
>
> This patch enables wkup_i2c0 node in board dts file
> along with pin mux and speed.
> Also enables underneath eeprom CAV24C256WE.
>
> J7200 Datasheet (Table 6-106, Section 6.4 Pin Multiplexing) :
> https://www.ti.com/lit/ds/symlink/dra821u.pdf
>
> J7200 User Guide (Section 4.3, Table 4-2) :
> https://www.ti.com/lit/ug/spruiw7a/spruiw7a.pdf
>
> Signed-off-by: Udit Kumar
> ---
> .../arm/dts/k3-j7200-r5-common-proc-board.dts | 7 ---
> arch/arm/dts/k3-j7200-som-p0.dtsi | 21 +++
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> index e62f9218e8..9d9ffcbb89 100644
> --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> @@ -126,13 +126,6 @@
> >;
> };
>
> - wkup_i2c0_pins_default: wkup-i2c0-pins-default {
> - pinctrl-single,pins = <
> - J721E_WKUP_IOPAD(0x100, PIN_INPUT_PULLUP, 0) /* (F20)
> WKUP_I2C0_SCL */
> - J721E_WKUP_IOPAD(0x104, PIN_INPUT_PULLUP, 0) /* (H21)
> WKUP_I2C0_SDA */
> - >;
> - };
> -
> mcu_fss0_hpb0_pins_default: mcu-fss0-hpb0-pins-default {
> pinctrl-single,pins = <
> J721E_WKUP_IOPAD(0x0, PIN_OUTPUT, 1) /* (E20)
> MCU_OSPI0_CLK.MCU_HYPERBUS0_CK */
> diff --git a/arch/arm/dts/k3-j7200-som-p0.dtsi
> b/arch/arm/dts/k3-j7200-som-p0.dtsi
> index fa44ed4c17..2694241547 100644
> --- a/arch/arm/dts/k3-j7200-som-p0.dtsi
> +++ b/arch/arm/dts/k3-j7200-som-p0.dtsi
> @@ -118,6 +118,15 @@
> };
> };
>
> +_pmx2 {
> + wkup_i2c0_pins_default: wkup-i2c0-pins-default {
> + pinctrl-single,pins = <
> + J721E_WKUP_IOPAD(0x98, PIN_INPUT_PULLUP, 0) /* (F20)
> WKUP_I2C0_SCL */
> + J721E_WKUP_IOPAD(0x9c, PIN_INPUT_PULLUP, 0) /* (H21)
> WKUP_I2C0_SDA */
> + >;
> + };
> +};
> +
> _pmx0 {
> main_i2c0_pins_default: main-i2c0-pins-default {
> pinctrl-single,pins = <
> @@ -214,6 +223,18 @@
> };
> };
>
> +_i2c0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + eeprom@50 {
> + compatible = "atmel,24c256";
> + reg = <0x50>;
> + };
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_fss0_ospi0_pins_default>;
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 02/14] arch: arm: dts: k3-j7200: Fix physical address of pin
On 09:43-20230503, Udit Kumar wrote:
> From: Keerthy
>
> wkup_pmx splits into multiple regions. Like
>
> wkup_pmx0 -> 13 pins (WKUP_PADCONFIG 0 - 12)
> wkup_pmx1 -> 2 pins (WKUP_PADCONFIG 14 - 15)
> wkup_pmx2 -> 59 pins (WKUP_PADCONFIG 26 - 84)
> wkup_pmx3 -> 8 pins (WKUP_PADCONFIG 93 - 100)
>
> With this split, pin offset needs to be adjusted to
> match with new pmx for all pins above wkup_pmx0.
>
> Example a pin under wkup_pmx1 should start from 0 instead of
> old offset(0x38 WKUP_PADCONFIG 14 offset)
>
> J7200 Datasheet (Table 6-106, Section 6.4 Pin Multiplexing) :
> https://www.ti.com/lit/ds/symlink/dra821u.pdf
>
> Signed-off-by: Keerthy
> Signed-off-by: Udit Kumar
> ---
> arch/arm/dts/k3-j7200-common-proc-board.dts | 28 ++---
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-common-proc-board.dts
> index 0d39d6b8cc..63633e4f6c 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
> @@ -83,25 +83,25 @@
> _pmx2 {
> mcu_cpsw_pins_default: mcu-cpsw-pins-default {
> pinctrl-single,pins = <
> - J721E_WKUP_IOPAD(0x0068, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TX_CTL */
> - J721E_WKUP_IOPAD(0x006c, PIN_INPUT, 0) /*
> MCU_RGMII1_RX_CTL */
> - J721E_WKUP_IOPAD(0x0070, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD3 */
> - J721E_WKUP_IOPAD(0x0074, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD2 */
> - J721E_WKUP_IOPAD(0x0078, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD1 */
> - J721E_WKUP_IOPAD(0x007c, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD0 */
> - J721E_WKUP_IOPAD(0x0088, PIN_INPUT, 0) /*
> MCU_RGMII1_RD3 */
> - J721E_WKUP_IOPAD(0x008c, PIN_INPUT, 0) /*
> MCU_RGMII1_RD2 */
> - J721E_WKUP_IOPAD(0x0090, PIN_INPUT, 0) /*
> MCU_RGMII1_RD1 */
> - J721E_WKUP_IOPAD(0x0094, PIN_INPUT, 0) /*
> MCU_RGMII1_RD0 */
> - J721E_WKUP_IOPAD(0x0080, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TXC */
> - J721E_WKUP_IOPAD(0x0084, PIN_INPUT, 0) /*
> MCU_RGMII1_RXC */
> + J721E_WKUP_IOPAD(0x, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TX_CTL */
> + J721E_WKUP_IOPAD(0x0004, PIN_INPUT, 0) /*
> MCU_RGMII1_RX_CTL */
> + J721E_WKUP_IOPAD(0x0008, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD3 */
> + J721E_WKUP_IOPAD(0x000c, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD2 */
> + J721E_WKUP_IOPAD(0x0010, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD1 */
> + J721E_WKUP_IOPAD(0x0014, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TD0 */
> + J721E_WKUP_IOPAD(0x0020, PIN_INPUT, 0) /*
> MCU_RGMII1_RD3 */
> + J721E_WKUP_IOPAD(0x0024, PIN_INPUT, 0) /*
> MCU_RGMII1_RD2 */
> + J721E_WKUP_IOPAD(0x0028, PIN_INPUT, 0) /*
> MCU_RGMII1_RD1 */
> + J721E_WKUP_IOPAD(0x002c, PIN_INPUT, 0) /*
> MCU_RGMII1_RD0 */
> + J721E_WKUP_IOPAD(0x0018, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TXC */
> + J721E_WKUP_IOPAD(0x001c, PIN_INPUT, 0) /*
> MCU_RGMII1_RXC */
> >;
> };
>
> mcu_mdio_pins_default: mcu-mdio1-pins-default {
> pinctrl-single,pins = <
> - J721E_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0) /* (L1)
> MCU_MDIO0_MDC */
> - J721E_WKUP_IOPAD(0x0098, PIN_INPUT, 0) /* (L4)
> MCU_MDIO0_MDIO */
> + J721E_WKUP_IOPAD(0x0034, PIN_OUTPUT, 0) /* (L1)
> MCU_MDIO0_MDC */
> + J721E_WKUP_IOPAD(0x0030, PIN_INPUT, 0) /* (L4)
> MCU_MDIO0_MDIO */
> >;
> };
> };
> --
> 2.34.1
>
Not in upstream k.org. NAK.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] Revert "mmc: rockchip_sdhci: Limit number of blocks read in a single command"
Hi Simon, On 2023-05-03 14:41, Simon Glass wrote: > This makes MMC extremely slow on bob. Even reading the environment takes > ages. > > If there is a bug on a particular controller, it should be worked around > using the compatible string, e.g. with ->flags in struct sdhci_data - > althought I don't see any docs for the flags. This revert will break booting from emmc on rock5b-rk3588. An alternative to this revert could be to enable CONFIG_MMC_SDHCI_SDMA for more rk3399 defconfigs. Using DMA should improve/restore performance. I have a followup patch in the works that changes this slightly, can include a change to only apply this workaround for rk35xx. Regards, Jonas > > This reverts commit 2cc6cde647e2cf61a29f389e8d263bf19672f0f5. > > Signed-off-by: Simon Glass > --- > > configs/rock5b-rk3588_defconfig | 1 - > drivers/mmc/rockchip_sdhci.c| 8 > 2 files changed, 9 deletions(-) > > diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig > index d3136ac850fe..3fcc6a26bb51 100644 > --- a/configs/rock5b-rk3588_defconfig > +++ b/configs/rock5b-rk3588_defconfig > @@ -58,7 +58,6 @@ CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > -# CONFIG_SPL_MMC_SDHCI_SDMA is not set > CONFIG_MMC_SDHCI_ROCKCHIP=y > CONFIG_ETH_DESIGNWARE=y > CONFIG_GMAC_ROCKCHIP=y > diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c > index 4f110976f4e8..2857dcc9ec4f 100644 > --- a/drivers/mmc/rockchip_sdhci.c > +++ b/drivers/mmc/rockchip_sdhci.c > @@ -589,14 +589,6 @@ static int rockchip_sdhci_probe(struct udevice *dev) > if (ret) > return ret; > > - /* > - * Reading more than 4 blocks with a single CMD18 command in PIO mode > - * triggers Data End Bit Error on RK3568 and RK3588. Limit to reading > - * max 4 blocks in one command when using PIO mode. > - */ > - if (!(host->flags & USE_DMA)) > - cfg->b_max = 4; > - > return sdhci_probe(dev); > } >
Re: [PATCH 01/14] arm: dts: k3-j7200: Update devicetree to sync with v6.3-rc6
On 09:43-20230503, Udit Kumar wrote:
> From: Nishanth Menon
>
> Sync with Kernel.org v6.3-rc6 tag.
we are few days away from rc1 tag. I'd rather we refresh.
>
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/dts/k3-j7200-common-proc-board.dts | 63 +++---
> arch/arm/dts/k3-j7200-main.dtsi | 72 +++--
> arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 59 +++--
> arch/arm/dts/k3-j7200-som-p0.dtsi | 46 +
> arch/arm/dts/k3-j7200.dtsi | 10 ++-
> 5 files changed, 154 insertions(+), 96 deletions(-)
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-common-proc-board.dts
> index d14f3c18b6..0d39d6b8cc 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
> @@ -12,6 +12,9 @@
> #include
>
> / {
> + compatible = "ti,j7200-evm", "ti,j7200";
> + model = "Texas Instruments J7200 EVM";
> +
> chosen {
> stdout-path = "serial2:115200n8";
> bootargs = "console=ttyS2,115200n8
> earlycon=ns16550a,mmio32,0x0280";
> @@ -77,7 +80,7 @@
> };
> };
>
> -_pmx0 {
> +_pmx2 {
> mcu_cpsw_pins_default: mcu-cpsw-pins-default {
> pinctrl-single,pins = <
> J721E_WKUP_IOPAD(0x0068, PIN_OUTPUT, 0) /*
> MCU_RGMII1_TX_CTL */
> @@ -131,15 +134,17 @@
> >;
> };
>
> - main_usbss0_pins_default: main-usbss0-pins-default {
> + vdd_sd_dv_pins_default: vdd-sd-dv-pins-default {
> pinctrl-single,pins = <
> - J721E_IOPAD(0x120, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS
> */
> + J721E_IOPAD(0xd0, PIN_OUTPUT, 7) /* (T5)
> SPI0_D1.GPIO0_55 */
> >;
> };
> +};
>
> - vdd_sd_dv_pins_default: vdd-sd-dv-pins-default {
> +_pmx1 {
> + main_usbss0_pins_default: main-usbss0-pins-default {
> pinctrl-single,pins = <
> - J721E_IOPAD(0xd0, PIN_OUTPUT, 7) /* (T5)
> SPI0_D1.GPIO0_55 */
> + J721E_IOPAD(0x04, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS */
> >;
> };
> };
> @@ -149,51 +154,27 @@
> status = "reserved";
> };
>
> +_uart0 {
> + status = "okay";
> + /* Default pinmux */
> +};
> +
> _uart0 {
> + status = "okay";
> /* Shared with ATF on this platform */
> power-domains = <_pds 146 TI_SCI_PD_SHARED>;
> };
>
> +_uart1 {
> + status = "okay";
> + /* Default pinmux */
> +};
> +
> _uart2 {
> /* MAIN UART 2 is used by R5F firmware */
> status = "reserved";
> };
>
> -_uart3 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart4 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart5 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart6 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart7 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart8 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> -_uart9 {
> - /* UART not brought out */
> - status = "disabled";
> -};
> -
> _gpio2 {
> status = "disabled";
> };
> @@ -229,6 +210,7 @@
> };
>
> _i2c0 {
> + status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_i2c0_pins_default>;
> clock-frequency = <40>;
> @@ -256,6 +238,7 @@
> * The i2c1 of the CPB (as it is labeled) is not connected to j7200.
> */
> _i2c1 {
> + status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_i2c1_pins_default>;
> clock-frequency = <40>;
> diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
> index e8a41d09b4..138381f43c 100644
> --- a/arch/arm/dts/k3-j7200-main.dtsi
> +++ b/arch/arm/dts/k3-j7200-main.dtsi
> @@ -32,7 +32,7 @@
> #size-cells = <1>;
> ranges = <0x00 0x00 0x0010 0x1c000>;
>
> - serdes_ln_ctrl: serdes-ln-ctrl@4080 {
> + serdes_ln_ctrl: mux-controller@4080 {
> compatible = "mmio-mux";
>
Re: [PATCH 1/4] arm: add support for Hisilicon HiSTB family SoCs
On Wed, May 03, 2023 at 09:39:41PM +0800, Yang Xiwen wrote: > On 5/3/2023 9:26 PM, Tom Rini wrote: > > On Sat, Apr 01, 2023 at 07:17:33PM +0800, Yang Xiwen wrote: > > > >> First supported chip is hi3798mv200 (which is similar to Hi3798cv200 > >> used by poplar). > >> > >> Signed-off-by: Yang Xiwen > > > > For the series, applied to u-boot/master, thanks! > > > Oops, I almost forgot this and had done a lot of updates since then. > There are still many things to do and I will send them out when I think > it is ready. Anyway, thanks for your reply, Tom. I guess next time I can > request for you to pull instead of mailing a series of patches, right? A series of patches is still the best path forward, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On Wed, May 03, 2023 at 12:57:13PM +0530, Neha Malcom Francis wrote: > Hi Tom > > On 27/04/23 04:07, Tom Rini wrote: > > On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: > > > > > This series aims to eliminate the use of additional custom repositories > > > such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 > > > Security Development Tools) that was plumbed into the U-Boot build flow > > > to generate boot images for TI K3 platform devices. And instead, we move > > > towards using binman that aligns better with the community standard build > > > flow. > > > > > > This series uses binman for all K3 platforms supported on U-Boot > > > currently; > > > both HS (High Security, both SE and FS) and GP (General Purpose) devices. > > > > > > Background on using k3-image-gen: > > > * TI K3 devices require a SYSFW (System Firmware) image consisting > > > of a signed system firmware image and board configuration binaries, > > > this is needed to bring up system firmware during U-Boot R5 SPL > > > startup. > > > * Board configuration data contain board-specific information > > > such as resource management, power management and security. > > > > > > Background on using core-secdev-k3: > > > * Contains resources to sign x509 certificates for HS devices > > > > > > Series intends to use binman to take over the packaging and signing for > > > the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined > > > boot flow) instead of k3-image-gen. > > > > > > Series also packages the A72/A53 bootloader images (tispl.bin and > > > u-boot.img) using ATF, OPTEE and DM (Device Manager) > > > > So, next up is fixing this in CI. After taking Andrew's patch to fix the > > typedef issue, and after my patches to ensure we can get > > pyyaml/jsonschema for python, there's problems still: > > > Thanks for checking this! Couple things: > > > Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: > > binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input > > path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) > > (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') > > 1. This is dependent on the patch merging J721S2 HS and GP configs [1]. > However it has been reverted on -next, seen in the same thread. OK. I'm not sure the priority order here. I would like to see this series get in first, and get everything else rebased on top of it. -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Mon, May 01, 2023 at 10:49:22AM +0200, Rasmus Villemoes wrote: > On 27/04/2023 19.31, Tom Rini wrote: > >> > >> Well, I'm not sure there's a use case for building all of the extra > >> device trees. I think what I'll do right now is fire off a CI run (or a > >> few, in the event of problems) where we just use the logic of > >> 3609e1dc5f4d and see what falls down. > > > > So this gets us a few failures. You can see them on > > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > > arch/.../foo.dtb and so we don't have the dtb file around. > > > > Hm, the former sounds like a bug in the defconfig, the second sounds > like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > should be fixable by just changing the logic of scripts/Makefile.dts a > little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > SPL_OF_LIST to dtb-y. Something like > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > index 2561025da8..5e2429c617 100644 > --- a/scripts/Makefile.dts > +++ b/scripts/Makefile.dts > @@ -1,3 +1,3 @@ > # SPDX-License-Identifier: GPL-2.0+ > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) OK, lemme see what happens now. Assuming this is enough, please post as a proper patch, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: phy: Request rgmii-id phy reset gpio as output
On 5/2/23 14:50, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Request the reset gpio of the rgmii-id phy as output to be consistent
with the eth-phy-uclass driver.
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/net/phy/ethernet_id.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/ethernet_id.c b/drivers/net/phy/ethernet_id.c
index 8864f99bb3..a715e83db9 100644
--- a/drivers/net/phy/ethernet_id.c
+++ b/drivers/net/phy/ethernet_id.c
@@ -39,7 +39,7 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus,
struct udevice *dev,
if (!IS_ENABLED(CONFIG_DM_ETH_PHY)) {
ret = gpio_request_by_name_nodev(node, "reset-gpios", 0, ,
-GPIOD_ACTIVE_LOW);
+GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW);
if (!ret) {
assert = ofnode_read_u32_default(node,
"reset-assert-us", 0);
Reviewed-by: Michal Simek
M
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Wed, May 03, 2023 at 10:25:21AM +0200, Rasmus Villemoes wrote: [snip] > That said, there's another thing "Linux does", at least right now for > arm64 and soonish also for arm32, namely putting dts files in individual > vendor directories. _That_ I'd really love to see happen in U-Boot as > well, because it's not just the 1400 line Makefile that's unmaintanable, > it's also the 2600+ files in one directory. I would like to see this, but it also means we need to make more progress on getting our device trees in sync with upstream. -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Mon, May 01, 2023 at 10:32:44AM -0600, Simon Glass wrote: > Hi Rasmus, > > On Mon, 1 May 2023 at 02:49, Rasmus Villemoes > wrote: > > > > On 27/04/2023 19.31, Tom Rini wrote: > > >> > > >> Well, I'm not sure there's a use case for building all of the extra > > >> device trees. I think what I'll do right now is fire off a CI run (or a > > >> few, in the event of problems) where we just use the logic of > > >> 3609e1dc5f4d and see what falls down. > > > > > > So this gets us a few failures. You can see them on > > > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > > > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > > > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > > > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > > > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > > > arch/.../foo.dtb and so we don't have the dtb file around. > > > > > > > Hm, the former sounds like a bug in the defconfig, the second sounds > > like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > > should be fixable by just changing the logic of scripts/Makefile.dts a > > little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > > SPL_OF_LIST to dtb-y. Something like > > > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > > index 2561025da8..5e2429c617 100644 > > --- a/scripts/Makefile.dts > > +++ b/scripts/Makefile.dts > > @@ -1,3 +1,3 @@ > > # SPDX-License-Identifier: GPL-2.0+ > > > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > > +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > > I think we should require that all the DTs in the list are already > built using the standard rule. No, that's the opposite of what we're finally able to do. We don't need a huge list of build-this-maybe-use-it, we can: - Build only and all of the dtb files that will get used - make to build a given device tree while developing it. > i.e. Makefile.dts should just have a check that OF_LIST doesn't bring > in anything new. If it does, then the build should fail. > > The list is really about which ones should be put into the FIT. We > shouldn't be putting in things that don't exist normally for that SoC. But that's not how it's been used. And especially given how the SPL logic (oddly but maybe not intentionally) works, we list many more dtbs there than a given config will use, so that all configs will work. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/2] Update mailmap ids
On 4/26/23 08:01, Ashok Reddy Soma wrote: In this patch series - Sort mailmap ids according to dictionary order - Update all Xilinx users mail ids to AMD Changes in v2: - Updated the missing mailids - Removed the space after mail id - Added closing brace for Vikhyat Goyal email id Algapally Santosh Sagar (2): .mailmap: Sort the mailmap ids in dictionary order .mailmap: Map all Xilinx users mail ids to AMD .mailmap | 81 +--- 1 file changed, 65 insertions(+), 16 deletions(-) Applied. M
Re: [PATCH 1/4] arm: add support for Hisilicon HiSTB family SoCs
On 5/3/2023 9:26 PM, Tom Rini wrote: > On Sat, Apr 01, 2023 at 07:17:33PM +0800, Yang Xiwen wrote: > >> First supported chip is hi3798mv200 (which is similar to Hi3798cv200 >> used by poplar). >> >> Signed-off-by: Yang Xiwen > > For the series, applied to u-boot/master, thanks! > Oops, I almost forgot this and had done a lot of updates since then. There are still many things to do and I will send them out when I think it is ready. Anyway, thanks for your reply, Tom. I guess next time I can request for you to pull instead of mailing a series of patches, right? -- Best regards, Yang Xiwen
Re: [PATCH v4 1/3] dm: extcon: add an uclass for extcon
On Tue, Apr 25, 2023 at 10:57:20AM +0300, Svyatoslav Ryhel wrote: > Add a new simple uclass for extcon. Currently all setup is done > in the probe. Uclass struct and ops are empty for now. > > Signed-off-by: Svyatoslav Ryhel > Reviewed-by: Simon Glass For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded
On Wed, Apr 12, 2023 at 09:36:43PM +0100, Daniel Golle wrote:
> Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and
> related functions") changed the logic deciding to set R0 and R1
> registers for V1 devices.
>
> Before:
> /* Also set PUPD/R0/R1 if the pin has them */
> err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup);
> if (err != -EINVAL) {
> mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0);
> mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1);
> }
>
> After:
> /* try pupd_r1_r0 if pullen_pullsel return error */
> err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
> val);
> if (err)
> return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
> pullup, val);
>
> Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function
> always either returns 0 in case of success or -EINVAL in case any error
> has occurred. Hence the logic responsible of the decision to program R0
> and R1 has been inverted.
>
> This leads to problems on BananaPi R2 (MT7623N) when booting from
> SDMMC, it turns out accessing eMMC no longer works since
> U-Boot 2022.07:
>
> MT7623> mmc dev 0
> Card did not respond to voltage select! : -110
>
> The problem wasn't detected for a long time as both eMMC and SDMMC work
> fine if they are used to boot from, and hence R0 and R1 were already
> setup by the bootrom and/or preloader.
>
> Fix the logic to restore the originally intended and correct behavior
> and also change the descriptive comment accordingly.
>
> Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related
> functions")
> Signed-off-by: Daniel Golle
> Tested-By: Frank Wunderlich
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] configs: change bpi-r3 to board specific dts and change prompt
On Tue, Apr 11, 2023 at 05:19:47PM +0200, Frank Wunderlich wrote: > From: Frank Wunderlich > > Use own devicetree for the board and change the prompt. > > Signed-off-by: Frank Wunderlich Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] board: mediatek: add Bananapi-R3 devicetree
On Tue, Apr 11, 2023 at 05:19:46PM +0200, Frank Wunderlich wrote: > From: Daniel Golle > > Add board specific devicetree for Bananapi R3 SBC. > > Signed-off-by: Daniel Golle > Signed-off-by: Frank Wunderlich Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 1/3] arm: dts: Import device tree for Broadcom Northstar
On Mon, Apr 24, 2023 at 09:38:28AM +0200, Linus Walleij wrote: > This brings in the main SoC device tree used by the > Broadcom Northstar chipset, i.e. BCM4709x and BCM5301x. > This is taken from the v6.3 Linux kernel. > > Cc: Rafał Miłecki > Signed-off-by: Linus Walleij For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/9] misc: add Qualcomm GENI SE QUP device driver
On Fri, Apr 21, 2023 at 08:50:33PM +0300, Vladimir Zapolskiy wrote: > This change adds a Qualcomm GENI SE QUP device driver as a wrapper for > actually enabled and used serial devices found on a board. > > At the moment the driver is pretty simple, its intention is to populate > childred devices and provide I/O mem read interface to them as clients, > this is needed for GENI UART driver to set up a proper clock divider > and provide the actually asked baud rate. > > Signed-off-by: Vladimir Zapolskiy > Reviewed-by: Konrad Dybcio For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] board: Fix documentation for Snapdragon based Samsung and Qualcomm boards
On Thu, Apr 20, 2023 at 04:58:48PM +0530, Bhupesh Sharma wrote: > The current documentation for Snapdragon based Samsung > and Qualcomm boards is vague in the sense that at one place > it mentions that u-boot can be used as a replacement for ABL > bootloader and at another it mentions that u-boot is loaded > as an Android boot image through ABL. > > Fix the same. > > Signed-off-by: Bhupesh Sharma Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] board: Fix board file path for sdm845.c for Samsung and Qualcomm boards
On Thu, Apr 20, 2023 at 04:58:47PM +0530, Bhupesh Sharma wrote: > Currently a few 'board/qualcomm/../Makefile' point to incorrect > path of sdm845 board file. > > Fix the same. > > Signed-off-by: Bhupesh Sharma Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: common: Default to non fitImage boot on HS-FS
On Thu, Apr 20, 2023 at 09:42:21PM +0530, Vignesh Raghavendra wrote: > Allow non fitImage bootflow on Field Securable (HS-FS) devices in > addition to GP, force fitImage boot only on Security enforced (HS-SE) > devices where signed images are necessary to maintain chain of trust. > > Signed-off-by: Vignesh Raghavendra > Reviewed-by: Kamlesh Gurudasani Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: common: don't reconfigure background firewalls
On Thu, Apr 20, 2023 at 05:16:24PM +0530, Manorit Chawdhry wrote: > K3 devices have some firewalls set up by ROM that we usually remove so > that the development is easy in HS devices. > > While removing the firewalls disabling a background region before > disabling the foreground regions keeps the firewall in a state where all > the transactions will be blacklisted until all the regions are disabled. > This causes a race for some other entity trying to access that memory > region before all the firewalls are disabled and causes an exception. > > Since the background regions configured by ROM are in such a manner > that they allow all transactions, don't touch the background regions at > all. > > Signed-off-by: Manorit Chawdhry > Reviewed-by: Kamlesh Gurudasani Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: am62a7: Enable QoS for DSS
On Fri, Apr 14, 2023 at 12:57:25PM +0530, Aradhya Bhatia wrote: > Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by > servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is > done by setting the DSS DMA orderID to 8. > > The C7x and VPAC have been overwhelming the DSS's access to the DDR > (when it was accessing via the Non Real-Time (NRT) Queue), primarily > because their functional frequencies, and hence DDR accesses, were > significantly higher than that of DSS. This led the display to flicker > when certain edgeAI models were being run. > > With the DSS traffic serviced from the RT queue, the flickering issue > has been found to be mitigated. > > The am62a qos files are auto generated from the k3 resource partitioning > tool. > > Section-3.1.12, "QoS Programming Guide", in the AM62A TRM[1], provides > more information about the QoS, and section-14.1, "System Interconnect > Registers", provides the register descriptions. > > [1] AM62A Tech Ref Manual: https://www.ti.com/lit/pdf/spruj16 > > Signed-off-by: Aradhya Bhatia Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: j7200: Fix firewall warnings at boot time
On Mon, Apr 17, 2023 at 12:04:09PM +0530, Manorit Chawdhry wrote: > J721E and J7200 have same file j721e_init.c which had the firewall > configs for J721E being applied on J7200 causing the warnings. Split the > firewalls for both the boards to remove those warnings. > > Signed-off-by: Manorit Chawdhry Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY
On Tue, Apr 11, 2023 at 03:18:37PM +0530, Siddharth Vadapalli wrote: > From: Kishon Vijay Abraham I > > Update the default BOOTCOMMAND to provide an automatic and easier way > to configure ethernet PHY before loading the firmware. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Siddharth Vadapalli Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: Workaround errata ID i2331
On Thu, Apr 06, 2023 at 01:29:36PM +0530, Vignesh Raghavendra wrote: > From: Nitin Yadav > > Errata doc: https://www.ti.com/lit/pdf/sprz457 > Errata ID i2331 CPSW: Device lockup when reading CPSW registers > > Details: A device lockup can occur during the second read of any CPSW > subsystem register after any MAIN domain power on reset (POR). A MAIN > domain POR occurs using the hardware MCU_PORz signal, or via software > using CTRLMMR_RST_CTRL.SW_MAIN_POR or CTRLMMR_MCU_RST_CTRL.SW_MAIN_POR. > After these resets, the processor and internal bus structures may get > into a state which is only recoverable with full device reset using > MCU_PORz. > Due to this errata, Ethernet boot should not be used on this device. > > Workaround(s): To avoid the lockup, a warm reset should be issued after > a MAIN domain POR and before any access to the CPSW registers. The warm > reset realigns internal clocks and prevents the lockup from happening. > Workaround above errata by calling do_reset() in case of cold boot in > order to trigger warm reset. This needs enabling SYSRESET driver in R5 > SPL to enable TI SCI reset driver. > > Signed-off-by: Nitin Yadav > Signed-off-by: Vignesh Raghavendra > Reviewed-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: ti: j721s2: Add support to detect daughtercards
On Mon, Apr 10, 2023 at 11:40:15AM +0530, Siddharth Vadapalli wrote: > From: Kishon Vijay Abraham I > > Add support to detect daughtercards (GESI Ethernet card) in-order > to set the MAC address of the main CPSW2G interface. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Siddharth Vadapalli Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Remove omap5_uevm board
On Tue, Apr 04, 2023 at 11:47:25AM -0400, Tom Rini wrote: > This platform is unsupported by TI and was never widely distributed. As > this is untested for a long while and missing some DM conversions, > remove it and related device tree files. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] arm: add support for Hisilicon HiSTB family SoCs
On Sat, Apr 01, 2023 at 07:17:33PM +0800, Yang Xiwen wrote: > First supported chip is hi3798mv200 (which is similar to Hi3798cv200 > used by poplar). > > Signed-off-by: Yang Xiwen For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] starqltechn: use 16x32 font
On Sat, Apr 01, 2023 at 12:28:42PM +0300, Dzmitry Sankouski wrote: > This font is more readable on high ppi display > > Signed-off-by: Dzmitry Sankouski > Reviewed-by: Simon Glass For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] configs: j721s2: Merge the HS and non-HS defconfigs
On Mon, Apr 10, 2023 at 01:11:45PM +0530, Manorit Chawdhry wrote: > K3 devices have runtime type board detection. Make the default defconfig > include the secure configuration. Then remove the HS specific config. > > Non-HS devices will continue to boot due to runtime device type detection. > If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS > devices these can be ignored. > > Signed-off-by: Manorit Chawdhry Please rebase this series on top of tree, thanks. -- Tom signature.asc Description: PGP signature
Re: Pull request for tpm-master-02052023
On Tue, May 02, 2023 at 03:26:47PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > The following changes since commit 50f64026f7a4c2d0a101c93916e01782e4fbbe7f: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-spi (2023-05-01 13:29:52 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/ > tags/tpm-master-02052023 > > for you to fetch changes up to a390050b4112a1e4a378a1ffba95bd92c49cf75f: > > MAINTAINERS: assign include/tpm*, cmd/tpm* (2023-05-02 14:09:19 +0300) > > The pipeline seems fine > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/16210 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] CI: Make use of buildman requirements.txt
On Wed, May 03, 2023 at 11:27:20AM +0530, Neha Malcom Francis wrote: > Hi Tom > > Thanks for these patches! > > On 27/04/23 01:14, Tom Rini wrote: > > Now that buildman has a requirements.txt file we need to make use of it. > > > > Signed-off-by: Tom Rini > > --- > > .azure-pipelines.yml | 3 +++ > > .gitlab-ci.yml | 4 > > 2 files changed, 7 insertions(+) > > > > However, while trying to ensure CI/CD coverage, I'm running into this " > error 'No module named 'jsonschema'" for am62ax [1], any idea why after > building successfully for other devices? > > > [1] > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=6236=logs=6fe7c803-7a3b-5b46-f057-c1c62fd89ba1=22dc4ac5-ae35-5978-08ac-5f386151834e=fae48c67-4bb5-5f06-119f-00d23f780e3c o We need to have the requirements.txt file installed in any job that's using this part of binman now and I guess my patch above wasn't complete? I didn't fully check what happened on Azure due to the other problems (ie iot2050 boards not building). -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/19] Migration to using binman for bootloader
Hi Jan, On 03/05/23 12:57, Neha Malcom Francis wrote: Hi Tom On 27/04/23 04:07, Tom Rini wrote: On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) So, next up is fixing this in CI. After taking Andrew's patch to fix the typedef issue, and after my patches to ensure we can get pyyaml/jsonschema for python, there's problems still: Thanks for checking this! Couple things: Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') 1. This is dependent on the patch merging J721S2 HS and GP configs [1]. However it has been reverted on -next, seen in the same thread. And then: https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error I've fixed this, minor but serious change. 2. Regarding iot2050, build fails since it uses arch/arm/mach-k3/config.mk which is now entirely binman based. Will try moving iot2050 to binman as well. I'll need some help with this, might need to know the bootloader flow to make a clean migration. [1] https://lore.kernel.org/all/20230224050749.13145-1-m-chawd...@ti.com/ -- Thanking You Neha Malcom Francis
[PATCH] Revert "mmc: rockchip_sdhci: Limit number of blocks read in a single command"
This makes MMC extremely slow on bob. Even reading the environment takes ages. If there is a bug on a particular controller, it should be worked around using the compatible string, e.g. with ->flags in struct sdhci_data - althought I don't see any docs for the flags. This reverts commit 2cc6cde647e2cf61a29f389e8d263bf19672f0f5. Signed-off-by: Simon Glass --- configs/rock5b-rk3588_defconfig | 1 - drivers/mmc/rockchip_sdhci.c| 8 2 files changed, 9 deletions(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index d3136ac850fe..3fcc6a26bb51 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -58,7 +58,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -# CONFIG_SPL_MMC_SDHCI_SDMA is not set CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c index 4f110976f4e8..2857dcc9ec4f 100644 --- a/drivers/mmc/rockchip_sdhci.c +++ b/drivers/mmc/rockchip_sdhci.c @@ -589,14 +589,6 @@ static int rockchip_sdhci_probe(struct udevice *dev) if (ret) return ret; - /* -* Reading more than 4 blocks with a single CMD18 command in PIO mode -* triggers Data End Bit Error on RK3568 and RK3588. Limit to reading -* max 4 blocks in one command when using PIO mode. -*/ - if (!(host->flags & USE_DMA)) - cfg->b_max = 4; - return sdhci_probe(dev); } -- 2.40.1.495.gc816e09b53d-goog
Pull request: please pull u-boot-imx-20230503
Hi Tom, please pull from u-boot-imx, thanks ! The following changes since commit 50f64026f7a4c2d0a101c93916e01782e4fbbe7f: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-spi (2023-05-01 13:29:52 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20230503 for you to fetch changes up to bb6ea0fe9290b4d64df8e716b58515b5325c2ea5: usb: ehci-mx6: move phy setup before register access (2023-05-02 10:57:32 +0200) u-boot-imx-20230503 --- - Fixes for : pico-imx6ul, smegw01 - new boards: DMSSE20, Reform 2 - fix: get_boot_device, PLL video rate CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/16211 Dario Binacchi (3): imx6: clock: improve calculations to get the PLL video rate imx6: clock: add support to get LCD pixel clock rate imx6: clock: print real pixel clock rate Eduard Strehlau (12): smegw01: Enable setting additional boot params smegw01: Select CONFIG_CMD_SQUASHFS smegw01: Select bootcount support smegw01: Add altbootcmd smegw01: Run altbootcmd in the case of failure smegw01: Only commit to new partition if update was successful smegw01: Enable EMMC boot from multiple partitions smegw01: Change default boot device to eMMC smegw01: Switch to fitImage smegw01: Add lockdown U-Boot env support smegw01: Disable additional boot menu options smegw01: Fix fallback to altbootcmd Fabio Estevam (3): pico-imx6ul: Convert to CONFIG_DM_SERIAL smegw01: Read the second MAC address smegw01: Convert CFG_EXTRA_ENV_SETTINGS to an env file Heinrich Schuchardt (1): imx8mn: buffer overflow in low_drive_gpu_freq() Hugo Villeneuve (1): arm: imx8m: remove unused and obsolete board_fix_fdt() in SOC context Oliver Graute (1): imx: support i.MX8QM DMSSE20 a1 board Patrick Wildt (1): board: mntre: imx8mq: Add MNT Reform 2 board support Tim Harvey (2): imx: fix get_boot_device() for imx8 usb: ehci-mx6: move phy setup before register access arch/arm/dts/Makefile |1 + arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 +++ arch/arm/dts/imx8qm-dmsse20-a1.dts | 397 arch/arm/include/asm/arch-mx6/clock.h |2 + arch/arm/mach-imx/imx8/Kconfig |8 ++ arch/arm/mach-imx/imx8m/Kconfig |7 ++ arch/arm/mach-imx/imx8m/soc.c | 36 +-- arch/arm/mach-imx/mx6/clock.c | 66 - arch/arm/mach-imx/romapi.c |2 + board/advantech/imx8qm_dmsse20_a1/Kconfig | 15 +++ board/advantech/imx8qm_dmsse20_a1/MAINTAINERS |7 ++ board/advantech/imx8qm_dmsse20_a1/Makefile |8 ++ board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20-a1.env | 48 ++ board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c | 188 board/advantech/imx8qm_dmsse20_a1/imximage.cfg | 23 + board/advantech/imx8qm_dmsse20_a1/spl.c | 223 +++ board/mntre/imx8mq_reform2/Kconfig | 15 +++ board/mntre/imx8mq_reform2/MAINTAINERS |7 ++ board/mntre/imx8mq_reform2/Makefile | 12 +++ board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 + board/mntre/imx8mq_reform2/lpddr4_timing.c | 1014 ++ board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 +++ board/mntre/imx8mq_reform2/spl.c| 260 ++ board/storopack/smegw01/Kconfig |7 ++ board/storopack/smegw01/smegw01.c | 33 +++ board/storopack/smegw01/smegw01.env | 89 + common/Kconfig |2 +- configs/imx8mq_reform2_defconfig| 107 + configs/imx8qm_dmsse20a1_defconfig | 129 + configs/pico-imx6ul_defconfig |1 + configs/smegw01_defconfig | 18 +++- doc/board/advantech/imx8qm-dmsse20-a1.rst | 58 doc/board/advantech
Re: [PATCH v2 26/30] build: Disable weak symbols for MSYS2
On Tue, May 2, 2023 at 11:30 PM Bin Meng wrote:
>
> Hi Simon,
>
> On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote:
> >
> > Weak symbols are not well supported by the PE format, so disable them.
> > We need to manually ensure that only one function is present in the source
> > code.
> >
> > Add a Kconfig option to control this and enable it when building for
> > Windows.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > Kconfig | 12
> > include/linux/compiler_attributes.h | 4
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 9ac816abef1c..985b09680934 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -75,6 +75,18 @@ config CLANG_VERSION
> > config CC_IS_MSYS
> > def_bool $(success,uname -o | grep -q Msys)
> >
> > +config WEAK_SYMBOLS
> > + bool "Enable use of weak symbols"
> > + default y if !CC_IS_MSYS
> > + help
> > + The Portable Executable (PE) format used by Windows does not
> > support
> > + weak symbols very well. Even where it can be made to work, the
> > __weak
> > + function attribute cannot be made to work with PE. Supporting weak
> > + symbols would involve changing the source code in undesirable
> > ways.
> > +
> > + This option controls whether weak symbols are used, or not. When
> > + disabled, the __weak function attribute does nothing.
> > +
> > choice
> > prompt "Optimization level"
> > default CC_OPTIMIZE_FOR_SIZE
> > diff --git a/include/linux/compiler_attributes.h
> > b/include/linux/compiler_attributes.h
> > index 44c9a08d7346..c954109a065b 100644
> > --- a/include/linux/compiler_attributes.h
> > +++ b/include/linux/compiler_attributes.h
> > @@ -268,6 +268,10 @@
> > * gcc:
> > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-weak-function-attribute
> > * gcc:
> > https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-weak-variable-attribute
> > */
> > +#ifdef CONFIG_WEAK_SYMBOLS
> > #define __weak __attribute__((__weak__))
> > +#else
> > +#define __weak
> > +#endif
> >
> > #endif /* __LINUX_COMPILER_ATTRIBUTES_H */
> > --
>
> I am adding Fangrui who is a toolchain expert to this thread.
>
> I chatted with him off-line, he thought we could probably go with the
> GCC+lld-link route. GNU ld's PE/COFF support is quite out of date.
>
> Maybe switching to lld-link could also solve the linker script issue
> you are trying to resolve in patch#23 "sandbox: Augment the linker
> script for MSYS2" ?
>
> Regards,
> Bin
https://maskray.me/blog/2021-04-25-weak-symbol#pecoff has some notes
about weak symbol support for PE/COFF.
The "undefined reference" issue is like the following:
printf 'void f(); int main() { f(); }' > a.c
printf '__attribute__((weak)) void f() {} void unused() {}' > b.c
x86_64-w64-mingw32-gcc -c a.c b.c
% x86_64-w64-mingw32-gcc a.o b.o
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccyRH2ap.o:a.c:(.text+0xe):
undefined reference to `f'
collect2: error: ld returned 1 exit status
Making the __weak macro a no-op drops all the semantics about weak,
which would likely lead to some pitfalls.
I suggest that u-boot doesn't add support for a linker that doesn't
the above case.
If u-boot is willing to refactor some code to avoid the above
situation, I think it'd be fine as well.
--
宋方睿
[PATCH] scripts: dtc-version: support git version strings too
Building dtc from git causes the version number to start with a 'v'
(e.g. v1.7.0). printf then fails to parse 'v1' as a decimal value, and
prints '000700' instead of '010700'. Subsequently, the build fails,
because '000700' is less than the required '010400' version.
Signed-off-by: Martin Hundebøll
---
scripts/dtc-version.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/dtc-version.sh b/scripts/dtc-version.sh
index bfb514e179..53ff868bcd 100755
--- a/scripts/dtc-version.sh
+++ b/scripts/dtc-version.sh
@@ -20,7 +20,7 @@ if ! which $dtc >/dev/null ; then
exit 1
fi
-MAJOR=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 1)
+MAJOR=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 1 | tr -d v)
MINOR=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 2)
PATCH=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 3 | cut -d - -f 1)
--
2.40.1
Re: [PATCH v2 u-boot-mvebu 4/4] arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
On 5/3/23 12:01, Eugen Hristev wrote: So CI build fails and I can't send a pull request. I'm sending a patch though, to fix this image overflow by enabling LTO. Stay tuned... I see... LTO helped. So can be this patch series now applied? No problems with this series now in master, so: Applied to u-boot-marvell/master Hi Stefan, This patch is still pending as it was not tested by anyone yet : https://patchwork.ozlabs.org/project/uboot/patch/20230427085945.475619-1...@denx.de/ so , this series still breaks the sama5d2_icp board ? No. Azure CI build has run w/o any problems. Otherwise I would not have been able to send a pull request for these patches. Nice, but, how was the SRAM problem solved ? Anything changed in the patches ? No, the patches are the same. So how is this problem solved? Frankly, I have no idea. My best guess is that the common code has shrunken a bit in the meantime. So the few bytes more of these patches would fit now. Thanks, Stefan
Re: [PATCH v2 u-boot-mvebu 4/4] arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
On 5/3/23 12:57, Stefan Roese wrote: Hi Eugen, On 5/3/23 11:43, Eugen Hristev wrote: On 5/3/23 12:17, Stefan Roese wrote: On 4/29/23 13:08, Pali Rohár wrote: On Thursday 27 April 2023 10:56:17 Stefan Roese wrote: Hi Pali, On 4/27/23 01:44, Pali Rohár wrote: On Thursday 13 April 2023 22:43:25 Martin Rowe wrote: On Thu, 13 Apr 2023 at 20:58, Pali Rohár wrote: BootROM and neither SPL does not use eMMC boot acknowledgement or boot enable bits in EXT_CSD_PART_CONF eMMC register. And also fixed SATA disk sector 0x141 is not used at all. Signed-off-by: Pali Rohár SPL successfully loads u-boot from the same partition as SPL. SD card and UART continue to boot. Thanks Pali! Tested-by: Martin Rowe Ok, is something more needed for this patch series? Unfortunately yes. As at least this board breaks with this patchset added: $ make sama5d2_icp_mmc_defconfig $ make -sj /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `__u_boot_list' will not fit in region `.sram' /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 32 bytes make[1]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 make: *** [Makefile:2049: spl/u-boot-spl] Error 2 So CI build fails and I can't send a pull request. I'm sending a patch though, to fix this image overflow by enabling LTO. Stay tuned... I see... LTO helped. So can be this patch series now applied? No problems with this series now in master, so: Applied to u-boot-marvell/master Hi Stefan, This patch is still pending as it was not tested by anyone yet : https://patchwork.ozlabs.org/project/uboot/patch/20230427085945.475619-1...@denx.de/ so , this series still breaks the sama5d2_icp board ? No. Azure CI build has run w/o any problems. Otherwise I would not have been able to send a pull request for these patches. Nice, but, how was the SRAM problem solved ? Anything changed in the patches ? Thanks, Stefan Thanks, Eugen Thanks, Stefan Thanks, Stefan --- board/solidrun/clearfog/README | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README index ed4a712c5aa2..c86b37061a30 100644 --- a/board/solidrun/clearfog/README +++ b/board/solidrun/clearfog/README @@ -1,7 +1,7 @@ Update from original Marvell U-Boot to mainline U-Boot: --- -Generate the U-Boot image with these commands: +Generate the U-Boot image for eMMC/SD with these commands: $ make clearfog_defconfig $ make @@ -9,7 +9,7 @@ $ make The resulting image including the SPL binary with the full DDR setup is "u-boot-with-spl.kwb". -Now all you need to do is copy this image on a SD card. +Now all you need to do is copy this image on a SD card's sector 1. For example with this command: $ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 @@ -20,12 +20,6 @@ of "/dev/sdX" here! Install U-Boot on eMMC: --- -To make SPL load the main U-Boot image from the eMMC boot partition enable -eMMC boot acknowledgement and boot partition with the following U-Boot -command: - - mmc partconf 0 1 1 0 - Install U-Boot on eMMC boot partition from Linux running on Clearfog: echo 0 > /sys/block/mmcblk0boot0/force_ro @@ -37,8 +31,14 @@ Consider initial boot from UART (see below). Install U-Boot on SATA: --- -When loading the main U-Boot image from raw SATA sector, set -CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141. +Generate the U-Boot image for SATA with these commands: + +$ make clearfog_sata_defconfig +$ make + +Copy image on a SATA disk's sector 1: + +$ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 Boot selection: --- -- 2.20.1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de Viele Grüße, Stefan Roese Viele Grüße, Stefan Roese
Re: [PATCH v2 u-boot-mvebu 4/4] arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
Hi Eugen, On 5/3/23 11:43, Eugen Hristev wrote: On 5/3/23 12:17, Stefan Roese wrote: On 4/29/23 13:08, Pali Rohár wrote: On Thursday 27 April 2023 10:56:17 Stefan Roese wrote: Hi Pali, On 4/27/23 01:44, Pali Rohár wrote: On Thursday 13 April 2023 22:43:25 Martin Rowe wrote: On Thu, 13 Apr 2023 at 20:58, Pali Rohár wrote: BootROM and neither SPL does not use eMMC boot acknowledgement or boot enable bits in EXT_CSD_PART_CONF eMMC register. And also fixed SATA disk sector 0x141 is not used at all. Signed-off-by: Pali Rohár SPL successfully loads u-boot from the same partition as SPL. SD card and UART continue to boot. Thanks Pali! Tested-by: Martin Rowe Ok, is something more needed for this patch series? Unfortunately yes. As at least this board breaks with this patchset added: $ make sama5d2_icp_mmc_defconfig $ make -sj /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `__u_boot_list' will not fit in region `.sram' /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 32 bytes make[1]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 make: *** [Makefile:2049: spl/u-boot-spl] Error 2 So CI build fails and I can't send a pull request. I'm sending a patch though, to fix this image overflow by enabling LTO. Stay tuned... I see... LTO helped. So can be this patch series now applied? No problems with this series now in master, so: Applied to u-boot-marvell/master Hi Stefan, This patch is still pending as it was not tested by anyone yet : https://patchwork.ozlabs.org/project/uboot/patch/20230427085945.475619-1...@denx.de/ so , this series still breaks the sama5d2_icp board ? No. Azure CI build has run w/o any problems. Otherwise I would not have been able to send a pull request for these patches. Thanks, Stefan Thanks, Eugen Thanks, Stefan Thanks, Stefan --- board/solidrun/clearfog/README | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README index ed4a712c5aa2..c86b37061a30 100644 --- a/board/solidrun/clearfog/README +++ b/board/solidrun/clearfog/README @@ -1,7 +1,7 @@ Update from original Marvell U-Boot to mainline U-Boot: --- -Generate the U-Boot image with these commands: +Generate the U-Boot image for eMMC/SD with these commands: $ make clearfog_defconfig $ make @@ -9,7 +9,7 @@ $ make The resulting image including the SPL binary with the full DDR setup is "u-boot-with-spl.kwb". -Now all you need to do is copy this image on a SD card. +Now all you need to do is copy this image on a SD card's sector 1. For example with this command: $ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 @@ -20,12 +20,6 @@ of "/dev/sdX" here! Install U-Boot on eMMC: --- -To make SPL load the main U-Boot image from the eMMC boot partition enable -eMMC boot acknowledgement and boot partition with the following U-Boot -command: - - mmc partconf 0 1 1 0 - Install U-Boot on eMMC boot partition from Linux running on Clearfog: echo 0 > /sys/block/mmcblk0boot0/force_ro @@ -37,8 +31,14 @@ Consider initial boot from UART (see below). Install U-Boot on SATA: --- -When loading the main U-Boot image from raw SATA sector, set -CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141. +Generate the U-Boot image for SATA with these commands: + +$ make clearfog_sata_defconfig +$ make + +Copy image on a SATA disk's sector 1: + +$ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 Boot selection: --- -- 2.20.1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de Viele Grüße, Stefan Roese Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] configs: at91: sama5d2_icp_mmc: Enable CONFIG_LTO
On 4/27/23 19:55, Pali Rohár wrote: On Thursday 27 April 2023 12:30:43 Stefan Roese wrote: On 4/27/23 11:51, Eugen Hristev wrote: On 4/27/23 12:26, Stefan Roese wrote: Hi Eugen, On 4/27/23 11:19, Eugen Hristev wrote: Hi Stefan, Thank you for the patch. This I guess is a workaround such that you can add a bit more of code. In the end, it's not scalable, and we have to find a better way, probably by removing some of the code to make the SPL smaller. U-Boot image size increase resulting in overflowing some limits is a common problem, especially in SPL. Enabling LTO gives quite some good improvements in image size decrease. So I don't think it's an workaround. If this was not needed until today, and not adding any new functionality, I would call this a workaround to avoid shrinking the size to fit in the SRAM. When we are adding more and more, and eventually hit this problem again, LTO already enabled, what we will do ? That's why I call this a workaround because we are not solving the problem, just postponing so we can add more things today. This is what's happening since many years. But okay, let's call it a workaround. How does this impact the size? How much we are gaining ? I did not measure this. I just checked that this target compiles clean again with LTO enabled and the MMC related patches applied. Could you (or some college?) please investigate here, how the results are in image size? No, you are submitting the patch, I assume you could give some numbers to support your patch. Sorry, my time is limited and frankly, I don't feel very much motivated (any more) to do additional work here. Even if it's not that much of effort. We can perhaps have a look to see which code is removed and guard it by #ifndef SPL_BUILD and that might lower the size. (if ofcourse, this code should really be removed) Sure, other improvements in image size decrease are of course always a good idea. Also, I don't have a board at hand to test this, so it has to be tested first to make sure the board doesn't break. Agreed. I assume/hope that one of your colleges will be able to test this? Someone from Microchip can, or other people using the board from the community I no longer work for Microchip, but I am still maintaining the AT91 custodian tree Okay. Let's see, where this goes. Well, if nobody wants to care about this board, go ahead with this change and if it is not enough that drop support for this board. Hi Pali, I kind of dislike this attitude. If a patchset breaks a board, a patchset should be changed. Or rejected. I don't agree with removing boards just because in a few days nobody tested one patch. And applying untested patches is again something which I disagree upon. Thanks, Stefan Eugen Thanks, Stefan Eugen On 4/27/23 11:59, Stefan Roese wrote: Adding just a tiny bit more code for sama5d2_icp_mmc leads to a SRAM image overflow. Fix this by enabling LTO for this board, so that such changes still can be made to the common U-Boot code. Signed-off-by: Stefan Roese Cc: Tudor Ambarus Cc: Eugen Hristev Cc: Sergiu Moga Cc: Pali Rohár --- configs/sama5d2_icp_mmc_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/sama5d2_icp_mmc_defconfig b/configs/sama5d2_icp_mmc_defconfig index e1b602d8e5ec..a3c57a3f1250 100644 --- a/configs/sama5d2_icp_mmc_defconfig +++ b/configs/sama5d2_icp_mmc_defconfig @@ -9,9 +9,11 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20003ef0 +CONFIG_SF_DEFAULT_SPEED=6600 CONFIG_ENV_SIZE=0x4000 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="at91-sama5d2_icp" +CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y @@ -24,6 +26,7 @@ CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_SYS_LOAD_ADDR=0x2200 CONFIG_DEBUG_UART=y +CONFIG_LTO=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_FIT=y @@ -86,7 +89,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ATMEL=y CONFIG_DM_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=2 -CONFIG_SF_DEFAULT_SPEED=6600 CONFIG_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_MACRONIX=y @@ -110,5 +112,4 @@ CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_ATMEL_TCB_TIMER=y CONFIG_SPL_ATMEL_TCB_TIMER=y -CONFIG_OF_LIBFDT_OVERLAY=y # CONFIG_EFI_LOADER_HII is not set Viele Grüße, Stefan Roese Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 u-boot-mvebu 4/4] arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
On 5/3/23 12:17, Stefan Roese wrote: On 4/29/23 13:08, Pali Rohár wrote: On Thursday 27 April 2023 10:56:17 Stefan Roese wrote: Hi Pali, On 4/27/23 01:44, Pali Rohár wrote: On Thursday 13 April 2023 22:43:25 Martin Rowe wrote: On Thu, 13 Apr 2023 at 20:58, Pali Rohár wrote: BootROM and neither SPL does not use eMMC boot acknowledgement or boot enable bits in EXT_CSD_PART_CONF eMMC register. And also fixed SATA disk sector 0x141 is not used at all. Signed-off-by: Pali Rohár SPL successfully loads u-boot from the same partition as SPL. SD card and UART continue to boot. Thanks Pali! Tested-by: Martin Rowe Ok, is something more needed for this patch series? Unfortunately yes. As at least this board breaks with this patchset added: $ make sama5d2_icp_mmc_defconfig $ make -sj /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `__u_boot_list' will not fit in region `.sram' /opt/kernel.org/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 32 bytes make[1]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 make: *** [Makefile:2049: spl/u-boot-spl] Error 2 So CI build fails and I can't send a pull request. I'm sending a patch though, to fix this image overflow by enabling LTO. Stay tuned... I see... LTO helped. So can be this patch series now applied? No problems with this series now in master, so: Applied to u-boot-marvell/master Hi Stefan, This patch is still pending as it was not tested by anyone yet : https://patchwork.ozlabs.org/project/uboot/patch/20230427085945.475619-1...@denx.de/ so , this series still breaks the sama5d2_icp board ? Thanks, Eugen Thanks, Stefan Thanks, Stefan --- board/solidrun/clearfog/README | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README index ed4a712c5aa2..c86b37061a30 100644 --- a/board/solidrun/clearfog/README +++ b/board/solidrun/clearfog/README @@ -1,7 +1,7 @@ Update from original Marvell U-Boot to mainline U-Boot: --- -Generate the U-Boot image with these commands: +Generate the U-Boot image for eMMC/SD with these commands: $ make clearfog_defconfig $ make @@ -9,7 +9,7 @@ $ make The resulting image including the SPL binary with the full DDR setup is "u-boot-with-spl.kwb". -Now all you need to do is copy this image on a SD card. +Now all you need to do is copy this image on a SD card's sector 1. For example with this command: $ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 @@ -20,12 +20,6 @@ of "/dev/sdX" here! Install U-Boot on eMMC: --- -To make SPL load the main U-Boot image from the eMMC boot partition enable -eMMC boot acknowledgement and boot partition with the following U-Boot -command: - - mmc partconf 0 1 1 0 - Install U-Boot on eMMC boot partition from Linux running on Clearfog: echo 0 > /sys/block/mmcblk0boot0/force_ro @@ -37,8 +31,14 @@ Consider initial boot from UART (see below). Install U-Boot on SATA: --- -When loading the main U-Boot image from raw SATA sector, set -CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141. +Generate the U-Boot image for SATA with these commands: + +$ make clearfog_sata_defconfig +$ make + +Copy image on a SATA disk's sector 1: + +$ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 Boot selection: --- -- 2.20.1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de Viele Grüße, Stefan Roese
Re: [PATCH 2/2] board: Fix documentation for Snapdragon based Samsung and Qualcomm boards
On Thu, 20 Apr 2023 at 16:59, Bhupesh Sharma wrote: > > The current documentation for Snapdragon based Samsung > and Qualcomm boards is vague in the sense that at one place > it mentions that u-boot can be used as a replacement for ABL > bootloader and at another it mentions that u-boot is loaded > as an Android boot image through ABL. > > Fix the same. > > Signed-off-by: Bhupesh Sharma > --- > doc/board/qualcomm/qcs404.rst | 4 ++-- > doc/board/qualcomm/sdm845.rst | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Sumit Garg -Sumit > diff --git a/doc/board/qualcomm/qcs404.rst b/doc/board/qualcomm/qcs404.rst > index bbb40b043b..0cb71d97c9 100644 > --- a/doc/board/qualcomm/qcs404.rst > +++ b/doc/board/qualcomm/qcs404.rst > @@ -9,8 +9,8 @@ About this > This document describes the information about Qualcomm QCS404 evaluation > board > and it's usage steps. > > -U-Boot can be used as a replacement for Qualcomm's original ABL (UEFI) > bootloader. > -It is loaded as an Android boot image through ABL > +The current boot flow support loading u-boot as an Android boot image via > +Qualcomm's UEFI-based ABL (Android) Bootloader. > > Installation > > diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst > index 8ef4749287..71879c2a6e 100644 > --- a/doc/board/qualcomm/sdm845.rst > +++ b/doc/board/qualcomm/sdm845.rst > @@ -12,8 +12,8 @@ supported boards and it's usage steps. > SDM845 - hi-end qualcomm chip, introduced in late 2017. > Mostly used in flagship phones and tablets of 2018. > > -U-Boot can be used as a replacement for Qualcomm's original ABL (UEFI) > bootloader. > -It is loaded as an Android boot image through ABL > +The current boot flow support loading u-boot as an Android boot image via > +Qualcomm's UEFI-based ABL (Android) Bootloader. > > Installation > > -- > 2.38.1 >
