Re: [PATCH 1/2] ARM: dts: stm32: Drop nWP GPIO hog on DHSOM
Hi Marek
On 10/23/21 8:33 PM, Marek Vasut wrote:
> The nWP GPIO hog was used to unlock the SPI NOR write protect when U-Boot
> used to operate the SPI NOR in 1-1-1 mode. Now that the SPI NOR is operated
> in 1-1-4 mode, the hog has adverse effects and causes transfer corruption,
> since the hogged pin is also the IO2 pin. Remove the hogs.
>
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> ---
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 9 -
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 9 -
> 2 files changed, 18 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 11bc247065b..71b0486f02a 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -50,15 +50,6 @@
> };
> };
>
> - {
> - snor-nwp {
> - gpio-hog;
> - gpios = <7 0>;
> - output-high;
> - line-name = "spi-nor-nwp";
> - };
> -};
> -
> {
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> index 9d3db208769..502cd95da05 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> @@ -25,15 +25,6 @@
> u-boot,dm-spl;
> };
>
> - {
> - snor-nwp {
> - gpio-hog;
> - gpios = <7 0>;
> - output-high;
> - line-name = "spi-nor-nwp";
> - };
> -};
> -
> {
> u-boot,dm-pre-reloc;
> };
>
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
On 24/10/2021 21.54, Simon Glass wrote: > Hi Rasmus, > > On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes > wrote: >> >> On 21/10/2021 18.03, Tom Rini wrote: >>> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote: Hi Marek, On Thu, 21 Oct 2021 at 07:28, Marek Behún wrote: > > On Thu, 21 Oct 2021 15:25:37 +0200 > Marek Behún wrote: > >> Hello, >> >> On Thu, 21 Oct 2021 15:06:51 +0200 >> Wolfgang Denk wrote: >> >>> I confirm that '+=' looks better. But '+=" is technically broken. >> >> a bit of my opinion: >> I think =+ will confuse far more people than + as last character of var >> name working weirdly. But I also think that + should be supported as >> last character. Therefore I propose backslash escaping in variable name, >> i.e. >> var+=value >> appends value to var, while >> var\+=value >> sets variable with name "var+" My first preference is to disallow + at the end of an end var. Perhaps we can start printing a warning if people do it, for a few releases. My distance second preference is what Marek has here, using a backslash to escape the + character. >>> >>> How bad does it make the parser look if we allow trailing + in variable >>> names, by escaping them? It's seemingly the substantive objection at >>> this point. >>> >> >> So I don't understand all the bruhahaha around a + at the end of the >> varname. Nobody suggests (that I have seen) changing anything about how >> U-Boot at runtime interprets and handles variables, so all variable >> names that used to be valid continue to be so. >> >> It's just that this _new_ method of generating the environment places >> certain restrictions on what can be done. The old-fashioned ways >> (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and >> run-time 'env set') continue to allow people to define whatever env vars >> they want. This new method is meant for transitioning in-tree boards' >> default environment, and no in-tree boards need anything exotic. >> >> Also, completely independent of whether the subsequent parser is >> implemented in awk or python or rust, or what syntax it accepts and the >> semantics of that syntax, the fact that we first pass the input through >> cpp already means some things just won't work the same way as when given >> to mkenvimage, and that applies to both sides of the =: >> >> printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive >> spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp - >> >> x y= >> msg=I like 1 >> five spaces=5spaces >> >> [In case its broken by the email, there are actually five spaces in the >> printf string between the words "five" and "spaces", the above should >> illustrate that cpp collapses those to a single space]. >> >> So, I'd much rather we do a cleaner break, and accept (and ignore) >> whitespace on either side of the assignment operator - that's how Make >> variable assignments work IIRC. And since a lot of people making use of >> this will already be familiar with Yocto, I think we should have two >> compound assignment operators, .= and +=. That still allows one to use >> any non-whitespace, non-= characters (modulo the restrictions imposed by >> the whole thing passing through cpp) in variable names, so >> >> foo+=abc >> >> means >> >> foo+ = abc >> >> while could append to foo by saying >> >> foo += abc >> >> That whitespace around the assignment operators would also make the >> input files somewhat more readable - there really is no point in having >> human-readable, human-editable text files having a format >> almost-but-not-quite be that of the on-disk format. > > I am OK with this on the name front, as I assume we don't want to > allow space in a var name! Exactly, there's really never any case where that would be sensible. But I would probably go a bit further and simply restrict varnames to the usual alphanumerics plus [_.+-] - in particular, exclude single and double quotes and backslash. That leaves the door open for somebody to later support "arbitrary" variable names by defining what it would mean to say e.g. "abc \n'\"\tfoo" = hahaha or whatever syntax they'd propose, but there's absolutely no point in implementing anything like that initially. > But how do I do this? > > bootargs=console=fred > #ifdef SOMETHING > bootargs+= dm-verity=... > #endif > > We need the space between the bootargs. Exactly like that, and for the case where you want to append something _without_ an extra space there's the .= operator I also suggested. FWIW, I like the idea that an indented line represents a continuation of the value of the current assignment. I don't think I've seen it addressed, but how do you deal with CONFIG_ string items? In the config.h file, the macro definition includes the double quotes, but I don't think one wants that in the env values. conf = CONFIG_DEFAULT_CONF bootcmd = bootm $loadaddr#$conf
Re: [PATCH] board: stmp32mp1: split board and SOC STM32MP15 configuration
Hi Patrick
On 10/22/21 10:19 AM, Patrick Delaunay wrote:
> Add a configuration file "stm32mp15_st_common.h" to handle the
> STMicroelectronics boards configuration and rename stm32mp1.h to
> "stm32mp15_common.h" to handle the generic STM32MP15x series configuration.
>
> The configuration file "dh_stm32mp1.h" is also renamed to
> "stm32mp15_dh_dhcom" for the configuration of board based on the
> dhelectronics STM32MP15x SOM.
>
> In the STMicroelectronics board configuration the default bootcmd
> "bootcmd_stm32mp" is updated to only select the extlinux file found on
> SD-Card on STM32MP15x EV1 for boot from NOR device.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> board/dhelectronics/dh_stm32mp1/Kconfig | 2 +-
> board/dhelectronics/dh_stm32mp1/MAINTAINERS | 2 +-
> board/engicam/stm32mp1/Kconfig| 2 +-
> board/st/stm32mp1/Kconfig | 2 +-
> board/st/stm32mp1/MAINTAINERS | 3 +-
> .../{stm32mp1.h => stm32mp15_common.h}| 51 ---
> .../{dh_stm32mp1.h => stm32mp15_dh_dhsom.h} | 6 +--
> include/configs/stm32mp15_st_common.h | 46 +
> 8 files changed, 87 insertions(+), 27 deletions(-)
> rename include/configs/{stm32mp1.h => stm32mp15_common.h} (78%)
> rename include/configs/{dh_stm32mp1.h => stm32mp15_dh_dhsom.h} (65%)
> create mode 100644 include/configs/stm32mp15_st_common.h
>
> diff --git a/board/dhelectronics/dh_stm32mp1/Kconfig
> b/board/dhelectronics/dh_stm32mp1/Kconfig
> index 1fc792c9d1..dc707c2753 100644
> --- a/board/dhelectronics/dh_stm32mp1/Kconfig
> +++ b/board/dhelectronics/dh_stm32mp1/Kconfig
> @@ -7,7 +7,7 @@ config SYS_VENDOR
> default "dhelectronics"
>
> config SYS_CONFIG_NAME
> - default "dh_stm32mp1"
> + default "stm32mp15_dh_dhsom"
>
> config ENV_SECT_SIZE
> default 0x1 if ENV_IS_IN_SPI_FLASH
> diff --git a/board/dhelectronics/dh_stm32mp1/MAINTAINERS
> b/board/dhelectronics/dh_stm32mp1/MAINTAINERS
> index 9ce21c3ab2..865588f5b8 100644
> --- a/board/dhelectronics/dh_stm32mp1/MAINTAINERS
> +++ b/board/dhelectronics/dh_stm32mp1/MAINTAINERS
> @@ -6,4 +6,4 @@ F:arch/arm/dts/stm32mp15xx-dhcom*
> F: board/dhelectronics/dh_stm32mp1/
> F: configs/stm32mp15_dhcom_basic_defconfig
> F: configs/stm32mp15_dhcor_basic_defconfig
> -F: include/configs/stm32mp1.h
> +F: include/configs/stm32mp15_dh_dhsom.h
> diff --git a/board/engicam/stm32mp1/Kconfig b/board/engicam/stm32mp1/Kconfig
> index c800fd4e60..3802d44cef 100644
> --- a/board/engicam/stm32mp1/Kconfig
> +++ b/board/engicam/stm32mp1/Kconfig
> @@ -7,6 +7,6 @@ config SYS_VENDOR
> default "engicam"
>
> config SYS_CONFIG_NAME
> - default "stm32mp1"
> + default "stm32mp15_common"
>
> endif
> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> index c5ab7553d4..89e97aec2b 100644
> --- a/board/st/stm32mp1/Kconfig
> +++ b/board/st/stm32mp1/Kconfig
> @@ -7,7 +7,7 @@ config SYS_VENDOR
> default "st"
>
> config SYS_CONFIG_NAME
> - default "stm32mp1"
> + default "stm32mp15_st_common"
>
> source "board/st/common/Kconfig"
> endif
> diff --git a/board/st/stm32mp1/MAINTAINERS b/board/st/stm32mp1/MAINTAINERS
> index 0e6d80fb45..6451195269 100644
> --- a/board/st/stm32mp1/MAINTAINERS
> +++ b/board/st/stm32mp1/MAINTAINERS
> @@ -8,4 +8,5 @@ F:board/st/stm32mp1/
> F: configs/stm32mp15_defconfig
> F: configs/stm32mp15_basic_defconfig
> F: configs/stm32mp15_trusted_defconfig
> -F: include/configs/stm32mp1.h
> +F: include/configs/stm32mp15_common.h
> +F: include/configs/stm32mp15_st_common.h
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp15_common.h
> similarity index 78%
> rename from include/configs/stm32mp1.h
> rename to include/configs/stm32mp15_common.h
> index 30d4e8ff1f..46a92a06e5 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp15_common.h
> @@ -5,8 +5,8 @@
> * Configuration settings for the STM32MP15x CPU
> */
>
> -#ifndef __CONFIG_H
> -#define __CONFIG_H
> +#ifndef __CONFIG_STM32MP15_COMMMON_H
> +#define __CONFIG_STM32MP15_COMMMON_H
> #include
> #include
>
> @@ -104,11 +104,11 @@
> BOOT_TARGET_PXE(func)
>
> /*
> - * bootcmd for stm32mp1:
> + * default bootcmd for stm32mp1:
> * for serial/usb: execute the stm32prog command
> - * for mmc boot (eMMC, SD card), boot only on the same device
> - * for nand or spi-nand boot, boot with on ubifs partition on UBI partition
> - * for nor boot, use the default order
> + * for mmc boot (eMMC, SD card), distro boot on the same mmc device
> + * for nand or spi-nand boot, distro boot with ubifs on UBI partition
> + * for nor boot, use the default distro order in ${boot_targets}
> */
> #define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
> "echo \"Boot over ${boot_device}${boot_instance}!\";" \
> @@ -126,7 +126,7 @@
>
> #ifdef CONFIG_FASTBOOT_CMD_OEM_FORMAT
> /* eMMC default partitions for fastboot command: oem
[PATCH v2] xilinx: zynqmp: Save multiboot as variable
Save multiboot register as u-boot variable. And use it as primary source
for composing dfu_alt_info for capsule update. If variable is not defined
Signed-off-by: Michal Simek
---
Changes in v2:
- Handle also error values from mult_boot() - Reported by Oleksandr Suvorov
board/xilinx/zynqmp/zynqmp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 5a1f8153409c..dfb5dab7afa3 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -640,7 +640,7 @@ int board_late_init(void)
const char *mode;
char *new_targets;
char *env_targets;
- int ret;
+ int ret, multiboot;
#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
usb_ether_init();
@@ -658,6 +658,10 @@ int board_late_init(void)
if (ret)
return ret;
+ multiboot = multi_boot();
+ if (multiboot >= 0)
+ env_set_hex("multiboot", multiboot);
+
bootmode = zynqmp_get_bootmode();
puts("Bootmode: ");
@@ -864,6 +868,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
memset(buf, 0, sizeof(buf));
multiboot = multi_boot();
+ if (multiboot < 0)
+ multiboot = 0;
+
+ multiboot = env_get_hex("multiboot", multiboot);
debug("Multiboot: %d\n", multiboot);
switch (zynqmp_get_bootmode()) {
--
2.33.1
Re: [PATCH] xilinx: zynqmp: Save multiboot as variable
On 10/21/21 16:23, Oleksandr Suvorov wrote:
On Thu, Oct 21, 2021 at 9:59 AM Michal Simek wrote:
Save multiboot register as u-boot variable. And use it as primary source
for composing dfu_alt_info for capsule update. If variable is not defined
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index ed6c287df221..5fce74d6085a 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -658,6 +658,8 @@ int board_late_init(void)
if (ret)
return ret;
+ env_set_hex("multiboot", multi_boot());
multi_boot() can return error -EINVAL. Probably it would be better to
handle this
before setting the env variable?
Sent v2 to fix this.
Thanks,
Michal
Re: [PATCH 1/2] ARM: dts: stm32: Drop nWP GPIO hog on DHSOM
Hi, On 10/23/21 8:33 PM, Marek Vasut wrote: The nWP GPIO hog was used to unlock the SPI NOR write protect when U-Boot used to operate the SPI NOR in 1-1-1 mode. Now that the SPI NOR is operated in 1-1-4 mode, the hog has adverse effects and causes transfer corruption, since the hogged pin is also the IO2 pin. Remove the hogs. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 9 - arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 9 - 2 files changed, 18 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] ARM: stm32: Enable DFU MTD support on DHSOM
Hi Marek, On 10/23/21 8:32 PM, Marek Vasut wrote: All the STM32MP1 based DHSOM have SPI NOR from which they boot, enable DFU_MTD support to make it possible to expose that SPI NOR via the DFU. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 2 ++ configs/stm32mp15_dhcor_basic_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index 5b85f6ad03b..083e199e511 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -81,6 +81,7 @@ CONFIG_TFTP_BLOCKSIZE=1536 CONFIG_STM32_ADC=y CONFIG_SPL_BLOCK_CACHE=y CONFIG_DFU_MMC=y +CONFIG_DFU_MTD=y CONFIG_DFU_RAM=y CONFIG_DFU_VIRT=y CONFIG_SET_DFU_ALT_INFO=y @@ -98,6 +99,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x50 CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_STM32_SDMMC2=y CONFIG_MTD=y +CONFIG_DM_MTD=y CONFIG_SYS_MTDPARTS_RUNTIME=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 37dd2754c03..01ac3edb93e 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -79,6 +79,7 @@ CONFIG_STM32_ADC=y CONFIG_SPL_BLOCK_CACHE=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y +CONFIG_DFU_MTD=y CONFIG_DFU_VIRT=y CONFIG_GPIO_HOG=y CONFIG_DM_HWSPINLOCK=y @@ -94,6 +95,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x53 CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_STM32_SDMMC2=y CONFIG_MTD=y +CONFIG_DM_MTD=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y minor, detected by grep -l stm32mp15 configs/* | ./tools/moveconfig.py -s -d - index 083e199e51..9df475d156 100644 @@ -81,8 +81,8 @@ CONFIG_TFTP_BLOCKSIZE=1536 CONFIG_STM32_ADC=y CONFIG_SPL_BLOCK_CACHE=y CONFIG_DFU_MMC=y -CONFIG_DFU_MTD=y CONFIG_DFU_RAM=y +CONFIG_DFU_MTD=y CONFIG_DFU_VIRT=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_GPIO_HOG=y Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 1/1] doc: remove AMCC PPC405 processor references
On 23/10/2021 13.14, Heinrich Schuchardt wrote: Support for PPC4XX processors has been removed. So we should not mention it in the documentation. Signed-off-by: Heinrich Schuchardt --- doc/README.bedbug | 22 -- 1 file changed, 22 deletions(-) Reviewed-by: Thomas Huth
[PATCH v2 2/3] arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node
Enable sdhci and sdmmc0 node in rk3568-u-boot.dtsi
Signed-off-by: Nico Cheng
---
(no changes since v1)
arch/arm/dts/rk3568-u-boot.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/dts/rk3568-u-boot.dtsi b/arch/arm/dts/rk3568-u-boot.dtsi
index 1570f13fc7..5a80dda275 100644
--- a/arch/arm/dts/rk3568-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-u-boot.dtsi
@@ -9,6 +9,10 @@
mmc1 =
};
+ chosen {
+ u-boot,spl-boot-order = ,
+ };
+
dmc: dmc {
compatible = "rockchip,rk3568-dmc";
u-boot,dm-pre-reloc;
@@ -35,3 +39,16 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ u-boot,dm-spl;
+ status = "okay";
+};
+
+ {
+ bus-width = <8>;
+ u-boot,dm-spl;
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
--
2.17.1
[PATCH v2 3/3] rockchip: rk3568: add arch_cpu_init()
We configured the drive strength and security of EMMC in
arch_cpu_init().
Signed-off-by: Nico Cheng
---
Changes in v2:
We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to
secure.
Modify comments to make them more explicit.
arch/arm/mach-rockchip/rk3568/rk3568.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 973b4f9dcb..1a62052731 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -13,6 +13,14 @@
#define PMUGRF_BASE0xfdc2
#define GRF_BASE 0xfdc6
+#define GRF_GPIO1B_DS_20x218
+#define GRF_GPIO1B_DS_30x21c
+#define GRF_GPIO1C_DS_00x220
+#define GRF_GPIO1C_DS_10x224
+#define GRF_GPIO1C_DS_20x228
+#define GRF_GPIO1C_DS_30x22c
+#define SGRF_BASE 0xFDD18000
+#define SGRF_SOC_CON4 0x10
/* PMU_GRF_GPIO0D_IOMUX_L */
enum {
@@ -81,5 +89,16 @@ void board_debug_uart_init(void)
int arch_cpu_init(void)
{
+#ifdef CONFIG_SPL_BUILD
+ /* Set the emmc sdmmc0 to secure */
+ rk_clrreg(SGRF_BASE + SGRF_SOC_CON4, (0x3 << 11 | 0x1 << 4));
+ /* set the emmc driver strength to level 2 */
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_2);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_3);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_0);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_1);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_2);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_3);
+#endif
return 0;
}
--
2.17.1
Re: [PATCH v3] driver: spi: add bcm iproc qspi support.
On Thu, Oct 21, 2021 at 4:01 AM Roman Bacik wrote: > > From: Rayagonda Kokatanur > > IPROC qspi driver supports both BSPI and MSPI modes. > > Signed-off-by: Rayagonda Kokatanur > Signed-off-by: Bharat Gooty > Acked-by: Rayagonda Kokatanur > > Signed-off-by: Roman Bacik > --- > > Changes in v3: > - fix warning by including linux/delay.h > - change ofdata_to_platdata to of_to_plat > - change priv_auto_alloc_size to priv_auto > > Changes in v2: > - remove include spi-nor.h > - define and use named BITs for writing register values > - remove bspi_set_4byte_mode() method > > drivers/spi/Kconfig | 6 + > drivers/spi/Makefile | 1 + > drivers/spi/iproc_qspi.c | 713 +++ > drivers/spi/iproc_qspi.h | 20 ++ > 4 files changed, 740 insertions(+) > create mode 100644 drivers/spi/iproc_qspi.c > create mode 100644 drivers/spi/iproc_qspi.h > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index d07e9a28af82..e76fadef32dd 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -178,6 +178,12 @@ config ICH_SPI > access the SPI NOR flash on platforms embedding this Intel > ICH IP core. > > +config IPROC_QSPI > + bool "QSPI driver for BCM iProc QSPI Controller" > + help > + This selects the BCM iProc QSPI controller. > + This driver support spi flash single, quad and memory reads. > + > config KIRKWOOD_SPI > bool "Marvell Kirkwood SPI Driver" > help > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index d2f24bccefd3..869763187062 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o > obj-$(CONFIG_FSL_ESPI) += fsl_espi.o > obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o > obj-$(CONFIG_ICH_SPI) += ich.o > +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o > obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o > obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o > obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o > diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c > new file mode 100644 > index ..08881bf61764 > --- /dev/null > +++ b/drivers/spi/iproc_qspi.c > @@ -0,0 +1,713 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2020-2021 Broadcom > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "iproc_qspi.h" > + > +/* 175MHz */ > +#define QSPI_AXI_CLK 17500 > +#define QSPI_DEF_SCK_FREQ 5000 > +#define QSPI_WAIT_TIMEOUT_MS 200U > +#define DWORD_ALIGNED(a) (!(((ulong)(a)) & 3)) > + > +/* Chip attributes */ > +#define SPBR_MIN 8U > +#define SPBR_MAX 255U > +#define NUM_CDRAM 16U > + > +#define CDRAM_PCS0 2 > +#define CDRAM_CONT BIT(7) > +#define CDRAM_BITS_EN BIT(6) > +#define CDRAM_QUAD_MODEBIT(8) > +#define CDRAM_RBIT_INPUT BIT(10) > +#define MSPI_SPE BIT(6) > +#define MSPI_CONT_AFTER_CMDBIT(7) > + > +/* Register fields */ > +#define MSPI_SPCR0_MSB_BITS_8 0x0020 > +#define BSPI_RAF_CONTROL_START_MASK0x0001 > +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK 0x0001 > +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002 > +#define BSPI_BITS_PER_PHASE_ADDR_MARK 0x0001 > +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0 > +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16 > +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3 > +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1 > +#define BSPI_STRAP_OVERRIDE_SHIFT 0 > + > +/* MSPI registers */ > +#define MSPI_SPCR0_LSB_REG 0x000 > +#define MSPI_SPCR0_MSB_REG 0x004 > +#define MSPI_SPCR1_LSB_REG 0x008 > +#define MSPI_SPCR1_MSB_REG 0x00c > +#define MSPI_NEWQP_REG 0x010 > +#define MSPI_ENDQP_REG 0x014 > +#define MSPI_SPCR2_REG 0x018 > +#define MSPI_STATUS_REG0x020 > +#define MSPI_CPTQP_REG 0x024 > +#define MSPI_TXRAM_REG 0x040 > +#define MSPI_RXRAM_REG 0x0c0 > +#define MSPI_CDRAM_REG 0x140 > +#define MSPI_WRITE_LOCK_REG0x180 > +#define MSPI_DISABLE_FLUSH_GEN_REG 0x184 > + > +/* BSPI registers */ > +#define BSPI_REVISION_ID_REG 0x000 > +#define BSPI_SCRATCH_REG 0x004 > +#define BSPI_MAST_N_BOOT_CTRL_REG 0x008 > +#define BSPI_BUSY_STATUS_REG 0x00c > +#define
Re: [PATCH] gpio: stm32: create include file for driver private data
Hi Patrick
On 10/22/21 8:12 PM, Patrick Delaunay wrote:
> The stm32 gpio driver private data are not needed in arch include files,
> they are not used by code except for stm32 gpio and pincontrol drivers,
> using the same IP; the defines for this IP is moved in a new file
> "stm32_gpio_priv.h" in driver/gpio.
>
> This patch avoids to have duplicated file gpio.h for each SOC
> in MPU directory mach-stm32mp and in each MCU directory arch-stm32*
> and allows to remove CONFIG_GPIO_EXTRA_HEADER for all STM32.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/Kconfig | 2 -
> arch/arm/include/asm/arch-stm32f4/gpio.h | 15
> arch/arm/include/asm/arch-stm32f7/gpio.h | 12 ---
> arch/arm/include/asm/arch-stm32h7/gpio.h | 12 ---
> arch/arm/mach-stm32mp/include/mach/gpio.h | 87 ---
> board/st/stm32f746-disco/stm32f746-disco.c| 1 -
> drivers/gpio/stm32_gpio.c | 3 +-
> .../gpio.h => drivers/gpio/stm32_gpio_priv.h | 6 +-
> drivers/pinctrl/pinctrl_stm32.c | 3 +-
> drivers/video/dw_mipi_dsi.c | 1 -
> drivers/video/stm32/stm32_dsi.c | 1 -
> drivers/video/stm32/stm32_ltdc.c | 1 -
> 12 files changed, 7 insertions(+), 137 deletions(-)
> delete mode 100644 arch/arm/include/asm/arch-stm32f4/gpio.h
> delete mode 100644 arch/arm/include/asm/arch-stm32f7/gpio.h
> delete mode 100644 arch/arm/include/asm/arch-stm32h7/gpio.h
> delete mode 100644 arch/arm/mach-stm32mp/include/mach/gpio.h
> rename arch/arm/include/asm/arch-stm32/gpio.h =>
> drivers/gpio/stm32_gpio_priv.h (94%)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 504abca0b7..0f33f9aa9a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1789,7 +1789,6 @@ config ARCH_STM32
> select CPU_V7M
> select DM
> select DM_SERIAL
> - select GPIO_EXTRA_HEADER
> imply CMD_DM
>
> config ARCH_STI
> @@ -1815,7 +1814,6 @@ config ARCH_STM32MP
> select DM_GPIO
> select DM_RESET
> select DM_SERIAL
> - select GPIO_EXTRA_HEADER
> select MISC
> select OF_CONTROL
> select OF_LIBFDT
> diff --git a/arch/arm/include/asm/arch-stm32f4/gpio.h
> b/arch/arm/include/asm/arch-stm32f4/gpio.h
> deleted file mode 100644
> index 490f686a85..00
> --- a/arch/arm/include/asm/arch-stm32f4/gpio.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * (C) Copyright 2011
> - * Yuri Tikhonov, Emcraft Systems, y...@emcraft.com
> - *
> - * (C) Copyright 2015
> - * Kamil Lulko,
> - */
> -
> -#ifndef _STM32_GPIO_H_
> -#define _STM32_GPIO_H_
> -
> -#include
> -
> -#endif /* _STM32_GPIO_H_ */
> diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h
> b/arch/arm/include/asm/arch-stm32f7/gpio.h
> deleted file mode 100644
> index 21f4e0fd27..00
> --- a/arch/arm/include/asm/arch-stm32f7/gpio.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
> - * Author(s): Vikas Manocha, for STMicroelectronics.
> - */
> -
> -#ifndef _STM32_GPIO_H_
> -#define _STM32_GPIO_H_
> -
> -#include
> -
> -#endif /* _STM32_GPIO_H_ */
> diff --git a/arch/arm/include/asm/arch-stm32h7/gpio.h
> b/arch/arm/include/asm/arch-stm32h7/gpio.h
> deleted file mode 100644
> index 4f57f175ff..00
> --- a/arch/arm/include/asm/arch-stm32h7/gpio.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
> - * Author(s): Patrice Chotard, for
> STMicroelectronics.
> - */
> -
> -#ifndef _STM32_GPIO_H_
> -#define _STM32_GPIO_H_
> -
> -#include
> -
> -#endif /* _STM32_GPIO_H_ */
> diff --git a/arch/arm/mach-stm32mp/include/mach/gpio.h
> b/arch/arm/mach-stm32mp/include/mach/gpio.h
> deleted file mode 100644
> index 7a0f293519..00
> --- a/arch/arm/mach-stm32mp/include/mach/gpio.h
> +++ /dev/null
> @@ -1,87 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * (C) Copyright 2016
> - * Vikas Manocha,
> - */
> -
> -#ifndef _STM32_GPIO_H_
> -#define _STM32_GPIO_H_
> -#include
> -
> -enum stm32_gpio_mode {
> - STM32_GPIO_MODE_IN = 0,
> - STM32_GPIO_MODE_OUT,
> - STM32_GPIO_MODE_AF,
> - STM32_GPIO_MODE_AN
> -};
> -
> -enum stm32_gpio_otype {
> - STM32_GPIO_OTYPE_PP = 0,
> - STM32_GPIO_OTYPE_OD
> -};
> -
> -enum stm32_gpio_speed {
> - STM32_GPIO_SPEED_2M = 0,
> - STM32_GPIO_SPEED_25M,
> - STM32_GPIO_SPEED_50M,
> - STM32_GPIO_SPEED_100M
> -};
> -
> -enum stm32_gpio_pupd {
> - STM32_GPIO_PUPD_NO = 0,
> - STM32_GPIO_PUPD_UP,
> - STM32_GPIO_PUPD_DOWN
> -};
> -
> -enum stm32_gpio_af {
> - STM32_GPIO_AF0 = 0,
> - STM32_GPIO_AF1,
> - STM32_GPIO_AF2,
> - STM32_GPIO_AF3,
> - STM32_GPIO_AF4,
> - STM32_GPIO_AF5,
> - STM32_GPIO_AF6,
> - STM32_GPIO_AF7,
> -
Re: [PATCH] ARM: stm32: Enable DFU MTD support on DHSOM
Hi Marek On 10/23/21 8:32 PM, Marek Vasut wrote: > All the STM32MP1 based DHSOM have SPI NOR from which they boot, > enable DFU_MTD support to make it possible to expose that SPI NOR > via the DFU. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > configs/stm32mp15_dhcom_basic_defconfig | 2 ++ > configs/stm32mp15_dhcor_basic_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 5b85f6ad03b..083e199e511 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -81,6 +81,7 @@ CONFIG_TFTP_BLOCKSIZE=1536 > CONFIG_STM32_ADC=y > CONFIG_SPL_BLOCK_CACHE=y > CONFIG_DFU_MMC=y > +CONFIG_DFU_MTD=y > CONFIG_DFU_RAM=y > CONFIG_DFU_VIRT=y > CONFIG_SET_DFU_ALT_INFO=y > @@ -98,6 +99,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x50 > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_STM32_SDMMC2=y > CONFIG_MTD=y > +CONFIG_DM_MTD=y > CONFIG_SYS_MTDPARTS_RUNTIME=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SPI_FLASH_MACRONIX=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 37dd2754c03..01ac3edb93e 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -79,6 +79,7 @@ CONFIG_STM32_ADC=y > CONFIG_SPL_BLOCK_CACHE=y > CONFIG_DFU_MMC=y > CONFIG_DFU_RAM=y > +CONFIG_DFU_MTD=y > CONFIG_DFU_VIRT=y > CONFIG_GPIO_HOG=y > CONFIG_DM_HWSPINLOCK=y > @@ -94,6 +95,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x53 > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_STM32_SDMMC2=y > CONFIG_MTD=y > +CONFIG_DM_MTD=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_SPANSION=y > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
On 28/09/2021 10.56, Rasmus Villemoes wrote: > The build system already automatically looks for and includes an > in-tree *-u-boot.dtsi when building the control .dtb. However, there > are some things that are awkward to maintain in such an in-tree file, > most notably the metadata associated to public keys used for verified > boot. > > The only "official" API to get that metadata into the .dtb is via > mkimage, as a side effect of building an actual signed image. But > there are multiple problems with that. First of all, the final U-Boot > (be it U-Boot proper or an SPL) image is built based on a binary > image, the .dtb, and possibly some other binary artifacts. So > modifying the .dtb after the build requires the meta-buildsystem > (Yocto, buildroot, whatnot) to know about and repeat some of the steps > that are already known to and handled by U-Boot's build system, > resulting in needless duplication of code. I should add that it's one thing when dealing with U-Boot proper and that just needs to be generated by cat'ing u-boot-nodtb.bin and a modified .dtb. But when the final generation is more complicated than that, e.g. involving black magic binman (which doesn't care to write out .cmd files so one can figure out what exactly happened under the hood), it's really really cumbersome. It's also somewhat annoying > and inconsistent to have a .dtb file in the build folder which is not > generated by the command listed in the corresponding .cmd file (that > of course applies to any generated file). > > So the contents of the /signature node really needs to be baked into > the .dtb file when it is first created, which means providing the > relevant data in the form of a .dtsi file. One could in theory put > that data into the *-u-boot.dtsi file, but it's more convenient to be > able to provide it externally: For example, when developing for a > customer, it's common to use a set of dummy keys for development, > while the consultants do not (and should not) have access to the > actual keys used in production. For such a setup, it's easier if the > keys used are chosen via the meta-buildsystem and the path(s) patched > in during the configure step. And of course, nothing prevents anybody > from having DEVICE_TREE_INCLUDES point at files maintained in git, or > for that matter from including the public key metadata in the > *-u-boot.dtsi directly and ignore this feature. > > There are other uses for this, e.g. in combination with ENV_IMPORT_FDT > it can be used for providing the contents of the /config/environment > node, so I don't want to tie this exclusively to use for verified > boot. ping
Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
On 10/25/21 09:54, Heinrich Schuchardt wrote: On 10/24/21 21:54, Simon Glass wrote: Hi Heinrich, On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt wrote: The block descriptor contains the if_type. There is no need to first look up the uclass for the if_type and then to check the parent device's uclass to know if the device has the correct if_type. Signed-off-by: Heinrich Schuchardt --- drivers/block/blk-uclass.c | 35 +-- 1 file changed, 1 insertion(+), 34 deletions(-) This seems to be heading in the wrong direction though. The IF_TYPE should really go away and be replaced with the UCLASS ID, I think. At present we have lots of calls to blk_create_device_f() which specify the type. I think we should drop the IF_TYPE_.. arg to that function and have it figured out from the uclass, in the interim. But why do we need IF_TYPE now? I admit that this patch is just an intermediate step. We can replace IF_TYPE by ULASS ID once SPL block devices are always using the driver model. Have we reached this point yet? I have not seen drivers/block/blk_legacy.c being deleted. qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of defconfigs requiring drivers/block/blk_legacy.c Best regards Heinrich Removing if_type_uclass_id[] is anyway on the right path. Best regards Heinrich
Re: [PATCH] ARM: stm32: Enable DFU MTD support on DHSOM
On 10/25/21 10:24 AM, Patrick DELAUNAY wrote: Hi Marek, On 10/23/21 8:32 PM, Marek Vasut wrote: All the STM32MP1 based DHSOM have SPI NOR from which they boot, enable DFU_MTD support to make it possible to expose that SPI NOR via the DFU. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 2 ++ configs/stm32mp15_dhcor_basic_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index 5b85f6ad03b..083e199e511 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -81,6 +81,7 @@ CONFIG_TFTP_BLOCKSIZE=1536 CONFIG_STM32_ADC=y CONFIG_SPL_BLOCK_CACHE=y CONFIG_DFU_MMC=y +CONFIG_DFU_MTD=y CONFIG_DFU_RAM=y CONFIG_DFU_VIRT=y CONFIG_SET_DFU_ALT_INFO=y @@ -98,6 +99,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x50 CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_STM32_SDMMC2=y CONFIG_MTD=y +CONFIG_DM_MTD=y CONFIG_SYS_MTDPARTS_RUNTIME=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 37dd2754c03..01ac3edb93e 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -79,6 +79,7 @@ CONFIG_STM32_ADC=y CONFIG_SPL_BLOCK_CACHE=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y +CONFIG_DFU_MTD=y CONFIG_DFU_VIRT=y CONFIG_GPIO_HOG=y CONFIG_DM_HWSPINLOCK=y @@ -94,6 +95,7 @@ CONFIG_SYS_I2C_EEPROM_ADDR=0x53 CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_STM32_SDMMC2=y CONFIG_MTD=y +CONFIG_DM_MTD=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y minor, detected by grep -l stm32mp15 configs/* | ./tools/moveconfig.py -s -d - I'll rather send Kconfig patch to sort the symbols in drivers/dfu/Kconfig alphabetically likely today, then this patch would be fine as-is.
Re: [PATCH 2/2] efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot
On 10/25/21 09:59, Masahisa Kojima wrote: On Sat, 23 Oct 2021 at 18:42, Heinrich Schuchardt wrote: On 10/22/21 13:24, Masahisa Kojima wrote: This commit adds the missing EFI_TCG2_PROTOCOL selftest and Measured Boot selftest in lib/efi_selftest. Signed-off-by: Masahisa Kojima --- lib/efi_selftest/Makefile | 10 + .../efi_selftest_miniapp_measuredboot.c | 93 ++ lib/efi_selftest/efi_selftest_tcg2.c | 804 +- 3 files changed, 906 insertions(+), 1 deletion(-) create mode 100644 lib/efi_selftest/efi_selftest_miniapp_measuredboot.c diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile index 9ff6e1760c..09950ee028 100644 --- a/lib/efi_selftest/Makefile +++ b/lib/efi_selftest/Makefile @@ -14,6 +14,8 @@ CFLAGS_efi_selftest_miniapp_exception.o := $(CFLAGS_EFI) -Os -ffreestanding CFLAGS_REMOVE_efi_selftest_miniapp_exception.o := $(CFLAGS_NON_EFI) CFLAGS_efi_selftest_miniapp_exit.o := $(CFLAGS_EFI) -Os -ffreestanding CFLAGS_REMOVE_efi_selftest_miniapp_exit.o := $(CFLAGS_NON_EFI) +CFLAGS_efi_selftest_miniapp_measuredboot.o := $(CFLAGS_EFI) -Os -ffreestanding +CFLAGS_REMOVE_efi_selftest_miniapp_measuredboot.o := $(CFLAGS_NON_EFI) CFLAGS_efi_selftest_miniapp_return.o := $(CFLAGS_EFI) -Os -ffreestanding CFLAGS_REMOVE_efi_selftest_miniapp_return.o := $(CFLAGS_NON_EFI) CFLAGS_initrddump_exit.o := $(CFLAGS_EFI) -Os -ffreestanding @@ -78,9 +80,11 @@ obj-$(CONFIG_EFI_ESRT) += efi_selftest_esrt.o targets += \ efi_miniapp_file_image_exception.h \ efi_miniapp_file_image_exit.h \ +efi_miniapp_file_image_measuredboot.h \ efi_miniapp_file_image_return.h \ efi_selftest_miniapp_exception.efi \ efi_selftest_miniapp_exit.efi \ +efi_selftest_miniapp_measuredboot.efi \ efi_selftest_miniapp_return.efi ifeq ($(CONFIG_GENERATE_ACPI_TABLE),) @@ -99,6 +103,10 @@ $(obj)/efi_miniapp_file_image_exit.h: $(obj)/efi_selftest_miniapp_exit.efi $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_exit.efi > \ $(obj)/efi_miniapp_file_image_exit.h +$(obj)/efi_miniapp_file_image_measuredboot.h: $(obj)/efi_selftest_miniapp_measuredboot.efi + $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_measuredboot.efi > \ + $(obj)/efi_miniapp_file_image_measuredboot.h + $(obj)/efi_miniapp_file_image_return.h: $(obj)/efi_selftest_miniapp_return.efi $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_return.efi > \ $(obj)/efi_miniapp_file_image_return.h @@ -112,3 +120,5 @@ $(obj)/efi_selftest_loadimage.o: $(obj)/efi_miniapp_file_image_exit.h $(obj)/efi_selftest_startimage_exit.o: $(obj)/efi_miniapp_file_image_exit.h $(obj)/efi_selftest_startimage_return.o: $(obj)/efi_miniapp_file_image_return.h + +$(obj)/efi_selftest_tcg2.o: $(obj)/efi_miniapp_file_image_measuredboot.h diff --git a/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c Thank you for going the extra mile and adding the test. Which image is actually loaded seems to be irrelevant for the test. Can we reuse an existing one, e.g. efi_miniapp_file_image_return.h? I guess the PCR related to the loaded image is not checked as it will depend on the build tools and date. Sorry, I'm doing wrong. Actually this selftest verifies the PE/COFF image measurement, so measuremt will be different depending on the build tools and date. # In my build environment, timestamp is set to all zero. To test the PE/COFF image measurement, I must prepare the static PE/COFF image. I plan to add efi_miniapp_file_image_measuredboot.h as a pre-compiled small static PE/COFF image for the measurement test, instead of adding efi_selftest_miniapp_measuredboot.c or reusing existing one. You will need one image per UEFI architecture (ia32, x64, arm, aa64, riscv32, riscv64). You could present the image via the EFI_LOAD_FILE2_PROTOCOL, see lib/efi_selftest/efi_selftest_load_file.c. Here is how to detect the target architecture: #if defined(__arm__) #include efi_miniapp_tcg2_arm.h #elif defined(__aarch64__) #include efi_miniapp_tcg2_aarch64.h #elif defined(__i386__) #include efi_miniapp_tcg2_ia32.h #elif defined(__x86_64__) #include efi_miniapp_tcg2_x64.h #elif defined(__riscv) && (__riscv_xlen == 32) #include efi_miniapp_tcg2_riscv32.h #elif defined(__riscv) && (__riscv_xlen == 64) #include efi_miniapp_tcg2_riscv64.h #endif Best regards Heinrich new file mode 100644 index 00..926713c1c2 --- /dev/null +++ b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c @@ -0,0 +1,93 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * efi_selftest_miniapp_measuredboot + * + * Copyright (c) 2018 Heinrich Schuchardt + * Copyright (c) 2021 Masahisa Kojima + * + * This EFI application is run by the StartImage selftest. This is incorrect due to copy and paste. + * It uses the Exit boot service to return and used for + * Measured Boot selftest. + */ + +#include
Re: [PATCH] dfu: dfu_sf: Read the SPI flash in 16 MiB chunks
Hi Marek,
> On 9/14/21 11:31 AM, Lukasz Majewski wrote:
> > On Tue, 14 Sep 2021 05:26:51 +0200
> > Marek Vasut wrote:
> >
> >> Not all SPI flashes and controllers can do continuous transfer
> >> longer than 16 MiB, so perform the DFU read in 16 MiB chunks.
> >>
> >> Signed-off-by: Marek Vasut
> >> Cc: Lukasz Majewski
> >> ---
> >> drivers/dfu/dfu_sf.c | 14 --
> >> 1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
> >> index 7e64ab772f0..b72493ced86 100644
> >> --- a/drivers/dfu/dfu_sf.c
> >> +++ b/drivers/dfu/dfu_sf.c
> >> @@ -24,8 +24,18 @@ static int dfu_get_medium_size_sf(struct
> >> dfu_entity *dfu, u64 *size) static int dfu_read_medium_sf(struct
> >> dfu_entity *dfu, u64 offset, void *buf, long *len)
> >> {
> >> - return spi_flash_read(dfu->data.sf.dev,
> >> dfu->data.sf.start + offset,
> >> - *len, buf);
> >> + long seglen = *len;
> >> + int ret;
> >> +
> >> + if (seglen > (16 << 20))
> >> + seglen = (16 << 20);
> >> +
> >> + ret = spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start
> >> + offset,
> >> + seglen, buf);
> >> + if (!ret)
> >> + *len = seglen;
> >> +
> >> + return ret;
> >> }
> >>
> >> static u64 find_sector(struct dfu_entity *dfu, u64 start, u64
> >> offset)
> >
> > Reviewed-by: Lukasz Majewski
>
> Is there going to be a PR with this or shall Tom pick it directly,
> since it is just one patch ?
Please, Tom pick it up...
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpe2rvMAAT5J.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: stm32: Disable video output on DHSOM
Hi Marek On 10/23/21 8:33 PM, Marek Vasut wrote: > The video output support is unused and disabling it saves about 20 kiB of > space. > In case video output support is required, it can be re-enabled. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > configs/stm32mp15_dhcom_basic_defconfig | 14 +- > configs/stm32mp15_dhcor_basic_defconfig | 14 +- > 2 files changed, 2 insertions(+), 26 deletions(-) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index ae9c3cdc25f..5ecc91c7c1b 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -22,6 +22,7 @@ > CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its" > # CONFIG_USE_SPL_FIT_GENERATOR is not set > CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > +CONFIG_CONSOLE_MUX=y > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y > @@ -53,7 +54,6 @@ CONFIG_CMD_REMOTEPROC=y > CONFIG_CMD_SPI=y > CONFIG_CMD_USB=y > CONFIG_CMD_USB_MASS_STORAGE=y > -CONFIG_CMD_BMP=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_TIMER=y > @@ -147,18 +147,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483 > CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 > CONFIG_USB_GADGET_DWC2_OTG=y > CONFIG_USB_GADGET_DOWNLOAD=y > -CONFIG_DM_VIDEO=y > -CONFIG_BACKLIGHT_GPIO=y > -CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y > -CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y > -CONFIG_VIDEO_STM32=y > -CONFIG_VIDEO_STM32_DSI=y > -CONFIG_VIDEO_STM32_MAX_XRES=1280 > -CONFIG_VIDEO_STM32_MAX_YRES=800 > -CONFIG_VIDEO_BMP_RLE8=y > -CONFIG_BMP_16BPP=y > -CONFIG_BMP_24BPP=y > -CONFIG_BMP_32BPP=y > CONFIG_FAT_WRITE=y > CONFIG_LZO=y > CONFIG_FDT_FIXUP_PARTITIONS=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 98ba37c750e..7c410b8224a 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -20,6 +20,7 @@ > CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its" > # CONFIG_USE_SPL_FIT_GENERATOR is not set > CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > +CONFIG_CONSOLE_MUX=y > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y > @@ -51,7 +52,6 @@ CONFIG_CMD_REMOTEPROC=y > CONFIG_CMD_SPI=y > CONFIG_CMD_USB=y > CONFIG_CMD_USB_MASS_STORAGE=y > -CONFIG_CMD_BMP=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_TIMER=y > @@ -141,18 +141,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483 > CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 > CONFIG_USB_GADGET_DWC2_OTG=y > CONFIG_USB_GADGET_DOWNLOAD=y > -CONFIG_DM_VIDEO=y > -CONFIG_BACKLIGHT_GPIO=y > -CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y > -CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y > -CONFIG_VIDEO_STM32=y > -CONFIG_VIDEO_STM32_DSI=y > -CONFIG_VIDEO_STM32_MAX_XRES=1280 > -CONFIG_VIDEO_STM32_MAX_YRES=800 > -CONFIG_VIDEO_BMP_RLE8=y > -CONFIG_BMP_16BPP=y > -CONFIG_BMP_24BPP=y > -CONFIG_BMP_32BPP=y > CONFIG_FAT_WRITE=y > CONFIG_LZO=y > CONFIG_FDT_FIXUP_PARTITIONS=y > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote:
>
> Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> 8D-8D-8D
> in the begging of probe.
>
> Command extension type is not standardized across flash vendors in DTR mode.
>
> For suiting different vendor flash devices, adding a flag to seperate types
> for
> soft reset on boot.
>
> Signed-off-by: JaimeLiao
> ---
> drivers/mtd/spi/Kconfig| 7 +++
> drivers/mtd/spi/spi-nor-core.c | 7 ++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index 67599b32c9..8304d6c973 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> can support a type of operation in a much more refined way compared
> to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
>
> +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> + bool "Command extension type is INVERT for Software Reset on boot"
> + default n
> + help
> +Because of SFDP information can not be get before boot.
> +So define command extension type is INVERT when Software Reset on
> boot only.
> +
> config SPI_FLASH_SOFT_RESET
> bool "Software Reset support for SPI NOR flashes"
> default n
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index fdaca0a0d3..87a7de7d60 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> enum spi_nor_cmd_ext ext;
>
> ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try
it that way instead of new macro?
Jagan.
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Le lun. 25 oct. 2021 à 09:05, Masami Hiramatsu
a écrit :
> Hi Francois,
>
> 2021年10月25日(月) 15:28 François Ozog :
> >
> >
> >
> > Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro <
> takahiro.aka...@linaro.org> a écrit :
> >>
> >> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
> >> > Hi Masami,
> >> >
> >> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
> >> > wrote:
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > 2021年10月15日(金) 9:40 Simon Glass :
> >> > > >
> >> > > > Hi Takahiro,
> >> > > >
> >> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro <
> takahiro.aka...@linaro.org> wrote:
> >> > > > >
> >> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature
> from DTB to
> >> > > > > .rodata"") failed to revert the removal of
> efi_get_public_key_data().
> >> > > > >
> >> > > > > Add back this function and move it under lib/efi_loader so that
> other
> >> > > > > platforms can utilize it. It is now declared as a weak function
> so that
> >> > > > > it can be replaced with a platform-specific implementation.
> >> > > > >
> >> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from
> DTB to
> >> > > > > .rodata"")
> >> > > > > Signed-off-by: AKASHI Takahiro
> >> > > > > ---
> >> > > > > lib/efi_loader/efi_capsule.c | 36
>
> >> > > > > 1 file changed, 36 insertions(+)
> >> > > > >
> >> > > > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> >> > > > > index b75e4bcba1a9..44f5da61a9be 100644
> >> > > > > --- a/lib/efi_loader/efi_capsule.c
> >> > > > > +++ b/lib/efi_loader/efi_capsule.c
> >> > > > > @@ -11,15 +11,20 @@
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > +#include
> >> > > > > +#include
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > +#include
> >> > > > >
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > >
> >> > > > > +DECLARE_GLOBAL_DATA_PTR;
> >> > > > > +
> >> > > > > const efi_guid_t efi_guid_capsule_report =
> EFI_CAPSULE_REPORT_GUID;
> >> > > > > static const efi_guid_t
> efi_guid_firmware_management_capsule_id =
> >> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> >> > > > > @@ -251,6 +256,37 @@ out:
> >> > > > > }
> >> > > > >
> >> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> >> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
> *pkey_len)
> >> > > >
> >> > > > I don't think this should be weak. What other way is there of
> handling
> >> > > > this and why would it be platform-specific?
> >> > >
> >> > > I have a question about the current design of the capsule auth key.
> >> > > If the platform has its own key-storage, how can the platform use
> the
> >> > > platform specific storage? Does such platform load the key from the
> storage
> >> > > and generate the dtb node in the platform initialization code? (or
> >> > > device driver?)
> >> >
> >> > Are we talking about a public key (which I assume from the function
> >> > naming) or some secret key. What is an auth key?
> >>
> >> Surely, a public key (more strictly, x509 certificate under the current
> >> implementation)
> >>
> >> > As I understand it, the public key should be provided by the platform
> >> > in devicetree that U-Boot uses, by whatever prior stage has access to
> >> > the key.
> >>
> >> I still believe that some platform provider may want to save the key
> >> in a *safer* storage, which should be at least read-only for
> non-authorized
> >> writers.
> >
> >
> > indeed. And U-Boot may not be entitled at all to check the capsule
> signature. For example updating SCP firmware with a key that is in secure
> world and will never leave this world.
>
> I think secure world firmware updates should be discussed in another
> thread, like with FWU. At this point, the capsule signature will be
> only authenticated by U-Boot, because we haven't passed the capsule
> image to the secure world yet.
i took a wrong example. The choice of authentication is to be done by the
capsule driver designer and is outside scope of U-Boot. And the key may be
in a separate storage or even the driver may invoke secure world for the
authentication (FF-A API or other platform specific). U-Boot may have a
capsule driver to update U-Boot components such as external env file. The
location of the key can be in a u-boot specific device tree.
>
> >> But if this issue (__weak or not) is the only blocking factor
> >> for my entire patch series, I'm willing to drop __weak for now since
> >> someone with production system may change it in the future when he has
> >> a good reason for that :)
> >
> >
> > If that need be….
>
> Agreed.
>
> Thank you,
>
> >
> >>
> >>
> >> -Takahiro Akashi
> >>
> >>
> >> > Regards,
> >> > Simon
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.o...@linaro.org | Skype: ffozog
> >
>
Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
On 10/24/21 21:54, Simon Glass wrote: Hi Heinrich, On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt wrote: The block descriptor contains the if_type. There is no need to first look up the uclass for the if_type and then to check the parent device's uclass to know if the device has the correct if_type. Signed-off-by: Heinrich Schuchardt --- drivers/block/blk-uclass.c | 35 +-- 1 file changed, 1 insertion(+), 34 deletions(-) This seems to be heading in the wrong direction though. The IF_TYPE should really go away and be replaced with the UCLASS ID, I think. At present we have lots of calls to blk_create_device_f() which specify the type. I think we should drop the IF_TYPE_.. arg to that function and have it figured out from the uclass, in the interim. But why do we need IF_TYPE now? I admit that this patch is just an intermediate step. We can replace IF_TYPE by ULASS ID once SPL block devices are always using the driver model. Have we reached this point yet? I have not seen drivers/block/blk_legacy.c being deleted. Removing if_type_uclass_id[] is anyway on the right path. Best regards Heinrich
Re: [PATCH 2/2] ARM: stm32: Increase default SF bus frequency to 50 MHz and enable SFDP
Hi, On 10/23/21 8:33 PM, Marek Vasut wrote: Increase default SPI NOR bus frequency from 1 MHz to 50 MHz and enable SFDP parsing to obtain more accurate SPI NOR configuration. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 4 +++- configs/stm32mp15_dhcor_basic_defconfig | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 1/2] ARM: stm32: Disable EFI on DHSOM
Hi, On 10/23/21 8:33 PM, Marek Vasut wrote: The EFI support is unused and disabling it saves about 70 kiB of space. In case EFI support is required, it can be re-enabled. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 4 configs/stm32mp15_dhcor_basic_defconfig | 4 2 files changed, 8 insertions(+) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 2/2] ARM: stm32: Disable video output on DHSOM
Hi, On 10/23/21 8:33 PM, Marek Vasut wrote: The video output support is unused and disabling it saves about 20 kiB of space. In case video output support is required, it can be re-enabled. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 14 +- configs/stm32mp15_dhcor_basic_defconfig | 14 +- 2 files changed, 2 insertions(+), 26 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
[PATCH v2 1/3] rockchip: Kconfig: Enable SPL support for rk3568
Enable SPL support in Kconfig and add some related option in rk3568_common.h Signed-off-by: Nico Cheng Signed-off-by: Jason Zhu --- (no changes since v1) arch/arm/mach-rockchip/Kconfig | 2 ++ configs/evb-rk3568_defconfig| 25 - include/configs/rk3568_common.h | 4 3 files changed, 30 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index b164afb529..21b9c381cf 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -260,6 +260,8 @@ config ROCKCHIP_RK3399 config ROCKCHIP_RK3568 bool "Support Rockchip RK3568" select ARM64 + select SUPPORT_SPL + select SPL select CLK select PINCTRL select RAM diff --git a/configs/evb-rk3568_defconfig b/configs/evb-rk3568_defconfig index a102a5a999..a145b71ac2 100644 --- a/configs/evb-rk3568_defconfig +++ b/configs/evb-rk3568_defconfig @@ -1,20 +1,42 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x00a0 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 -CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb" CONFIG_ROCKCHIP_RK3568=y +CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_TARGET_EVB_RK3568=y CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb" CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-evb.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_CRC32_SUPPORT=y +CONFIG_SPL_ATF=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y # CONFIG_CMD_SETEXPR is not set +# CONFIG_SPL_DOS_PARTITION is not set +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_REGMAP=y +CONFIG_SPL_SYSCON=y +CONFIG_SPL_CLK=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -28,6 +50,7 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y +CONFIG_SPL_RAM=y CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 diff --git a/include/configs/rk3568_common.h b/include/configs/rk3568_common.h index b6568917ea..47fc91779e 100644 --- a/include/configs/rk3568_common.h +++ b/include/configs/rk3568_common.h @@ -18,6 +18,10 @@ #define CONFIG_SYS_INIT_SP_ADDR0x00c0 #define CONFIG_SYS_LOAD_ADDR 0x00c00800 +#define CONFIG_SPL_STACK 0x0040 +#define CONFIG_SPL_MAX_SIZE0x2 +#define CONFIG_SPL_BSS_START_ADDR 0x400 +#define CONFIG_SPL_BSS_MAX_SIZE0x4000 #define CONFIG_SYS_BOOTM_LEN (64 << 20) /* 64M */ #define CONFIG_SYS_SDRAM_BASE 0 -- 2.17.1
[PATCH v2 0/3] Add SPL build support for RK3568
This series adds support for the rk3568 SOC, SPL load next-stage image from eMMC will be supported after this series of patches. Changes in v2: We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to secure. Modify comments to make them more explicit. Nico Cheng (3): rockchip: Kconfig: Enable SPL support for rk3568 arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node rockchip: rk3568: add arch_cpu_init() arch/arm/dts/rk3568-u-boot.dtsi| 17 + arch/arm/mach-rockchip/Kconfig | 2 ++ arch/arm/mach-rockchip/rk3568/rk3568.c | 19 +++ configs/evb-rk3568_defconfig | 25 - include/configs/rk3568_common.h| 4 5 files changed, 66 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
Dear Tom, In message <20211024164404.GQ3577824@bill-the-cat> you wrote: > > > It is a convenience tool, and it is OK if it has a few restrictions, > > like for the character set of supported variable names. > > > > But: > > > > 1) These restrictions must be clearly documented, both in the commit > >message and in the related documentation/readme. > > 2) There should be another, more primitive way to generate > >environment settings without these restrictions.. > > First, in that we don't have tests today for any of the "interesting" > possible variable options, I have no clue which ones even work as > intended. > > Second, yes, an end result here should be that yes, the default > environment should be more easily buildable and integrated with > arbitrary tools, so if something else can parse it (libubootenv?) it can > be done. Actually I have an even more low-level approach in mind, like the capability to include (or rather import) binary U-Boot environment data given in the usual =\0...=\0\0 form. This might come in handy if your data comes from exporting the environmentof a running system. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An expert is a person who avoids the small errors while sweeping on to the grand fallacy.
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > wrote: > > > > The dsdt.asl is usually combined out of several files that are included > > in the main one. Whenever we change the content of any of such files, > > build system is not able to recognize them. Hence the easiest way is to > > force DSDT rebuild each time we run make. > Ick. Since it uses #include, doesn't the dependency generation work with this? How? -- With Best Regards, Andy Shevchenko
Re: [PATCH v2] xilinx: zynqmp: Save multiboot as variable
On Mon, Oct 25, 2021 at 11:11 AM Michal Simek wrote:
>
> Save multiboot register as u-boot variable. And use it as primary source
> for composing dfu_alt_info for capsule update. If variable is not defined
>
> Signed-off-by: Michal Simek
Reviewed-by: Oleksandr Suvorov
> ---
>
> Changes in v2:
> - Handle also error values from mult_boot() - Reported by Oleksandr Suvorov
>
>
> board/xilinx/zynqmp/zynqmp.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index 5a1f8153409c..dfb5dab7afa3 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -640,7 +640,7 @@ int board_late_init(void)
> const char *mode;
> char *new_targets;
> char *env_targets;
> - int ret;
> + int ret, multiboot;
>
> #if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
> usb_ether_init();
> @@ -658,6 +658,10 @@ int board_late_init(void)
> if (ret)
> return ret;
>
> + multiboot = multi_boot();
> + if (multiboot >= 0)
> + env_set_hex("multiboot", multiboot);
> +
> bootmode = zynqmp_get_bootmode();
>
> puts("Bootmode: ");
> @@ -864,6 +868,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
> memset(buf, 0, sizeof(buf));
>
> multiboot = multi_boot();
> + if (multiboot < 0)
> + multiboot = 0;
> +
> + multiboot = env_get_hex("multiboot", multiboot);
> debug("Multiboot: %d\n", multiboot);
>
> switch (zynqmp_get_bootmode()) {
> --
> 2.33.1
>
--
Best regards
Oleksandr
Oleksandr Suvorov
cryo...@gmail.com
Re: [PATCH] ARM: stm32: Align mtdparts with SPI NOR layout on DHSOM
Hi, On 10/24/21 12:46 AM, Marek Vasut wrote: The DHSOM uses different SPI NOR layout than the ST devkit, stop pulling in the ST specific runtime mtdparts settings and adjust the mtdparts accordingly. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- board/dhelectronics/dh_stm32mp1/Makefile | 1 - configs/stm32mp15_dhcom_basic_defconfig | 3 ++- configs/stm32mp15_dhcor_basic_defconfig | 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro
a écrit :
> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
> > Hi Masami,
> >
> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > 2021年10月15日(金) 9:40 Simon Glass :
> > > >
> > > > Hi Takahiro,
> > > >
> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro <
> takahiro.aka...@linaro.org> wrote:
> > > > >
> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from
> DTB to
> > > > > .rodata"") failed to revert the removal of
> efi_get_public_key_data().
> > > > >
> > > > > Add back this function and move it under lib/efi_loader so that
> other
> > > > > platforms can utilize it. It is now declared as a weak function so
> that
> > > > > it can be replaced with a platform-specific implementation.
> > > > >
> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB
> to
> > > > > .rodata"")
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > lib/efi_loader/efi_capsule.c | 36
>
> > > > > 1 file changed, 36 insertions(+)
> > > > >
> > > > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> > > > > index b75e4bcba1a9..44f5da61a9be 100644
> > > > > --- a/lib/efi_loader/efi_capsule.c
> > > > > +++ b/lib/efi_loader/efi_capsule.c
> > > > > @@ -11,15 +11,20 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > #include
> > > > > #include
> > > > > #include
> > > > >
> > > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > > +
> > > > > const efi_guid_t efi_guid_capsule_report =
> EFI_CAPSULE_REPORT_GUID;
> > > > > static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > > > @@ -251,6 +256,37 @@ out:
> > > > > }
> > > > >
> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
> *pkey_len)
> > > >
> > > > I don't think this should be weak. What other way is there of
> handling
> > > > this and why would it be platform-specific?
> > >
> > > I have a question about the current design of the capsule auth key.
> > > If the platform has its own key-storage, how can the platform use the
> > > platform specific storage? Does such platform load the key from the
> storage
> > > and generate the dtb node in the platform initialization code? (or
> > > device driver?)
> >
> > Are we talking about a public key (which I assume from the function
> > naming) or some secret key. What is an auth key?
>
> Surely, a public key (more strictly, x509 certificate under the current
> implementation)
>
> > As I understand it, the public key should be provided by the platform
> > in devicetree that U-Boot uses, by whatever prior stage has access to
> > the key.
>
> I still believe that some platform provider may want to save the key
> in a *safer* storage, which should be at least read-only for non-authorized
> writers.
indeed. And U-Boot may not be entitled at all to check the capsule
signature. For example updating SCP firmware with a key that is in secure
world and will never leave this world.
But if this issue (__weak or not) is the only blocking factor
> for my entire patch series, I'm willing to drop __weak for now since
> someone with production system may change it in the future when he has
> a good reason for that :)
If that need be….
>
> -Takahiro Akashi
>
>
> > Regards,
> > Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH] ARM: stm32: Align mtdparts with SPI NOR layout on DHSOM
Hi Marek On 10/24/21 12:46 AM, Marek Vasut wrote: > The DHSOM uses different SPI NOR layout than the ST devkit, stop > pulling in the ST specific runtime mtdparts settings and adjust > the mtdparts accordingly. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > board/dhelectronics/dh_stm32mp1/Makefile | 1 - > configs/stm32mp15_dhcom_basic_defconfig | 3 ++- > configs/stm32mp15_dhcor_basic_defconfig | 2 ++ > 3 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/board/dhelectronics/dh_stm32mp1/Makefile > b/board/dhelectronics/dh_stm32mp1/Makefile > index b368b396a46..30db1dee807 100644 > --- a/board/dhelectronics/dh_stm32mp1/Makefile > +++ b/board/dhelectronics/dh_stm32mp1/Makefile > @@ -5,5 +5,4 @@ > > obj-y += ../../st/common/stpmic1.o board.o > > -obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += ../../st/common/stm32mp_mtdparts.o > obj-$(CONFIG_SET_DFU_ALT_INFO) += ../../st/common/stm32mp_dfu.o > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 5ecc91c7c1b..f51896ed472 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -61,6 +61,8 @@ CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_MTDPARTS=y > +CONFIG_MTDIDS_DEFAULT="nor0=nor0" > +CONFIG_MTDPARTS_DEFAULT="mtdparts=nor0:256k(fsbl1),256k(fsbl2),1408k(uboot),64k(env1),64k(env2)" > # CONFIG_SPL_DOS_PARTITION is not set > # CONFIG_ISO_PARTITION is not set > # CONFIG_SPL_PARTITION_UUIDS is not set > @@ -102,7 +104,6 @@ CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_STM32_SDMMC2=y > CONFIG_MTD=y > CONFIG_DM_MTD=y > -CONFIG_SYS_MTDPARTS_RUNTIME=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SF_DEFAULT_SPEED=5000 > CONFIG_SPI_FLASH_SFDP_SUPPORT=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 7c410b8224a..13e4553ac82 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -59,6 +59,8 @@ CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_MTDPARTS=y > +CONFIG_MTDIDS_DEFAULT="nor0=nor0" > +CONFIG_MTDPARTS_DEFAULT="mtdparts=nor0:256k(fsbl1),256k(fsbl2),1408k(uboot),64k(env1),64k(env2)" > # CONFIG_SPL_DOS_PARTITION is not set > # CONFIG_ISO_PARTITION is not set > # CONFIG_SPL_PARTITION_UUIDS is not set > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 2/2] ARM: stm32: Increase default SF bus frequency to 50 MHz and enable SFDP
Hi Marek On 10/23/21 8:33 PM, Marek Vasut wrote: > Increase default SPI NOR bus frequency from 1 MHz to 50 MHz and > enable SFDP parsing to obtain more accurate SPI NOR configuration. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > configs/stm32mp15_dhcom_basic_defconfig | 4 +++- > configs/stm32mp15_dhcor_basic_defconfig | 4 +++- > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 083e199e511..8fe0456a56d 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -70,7 +70,7 @@ CONFIG_ENV_SPI_BUS=0 > CONFIG_USE_ENV_SPI_CS=y > CONFIG_ENV_SPI_CS=0 > CONFIG_USE_ENV_SPI_MAX_HZ=y > -CONFIG_ENV_SPI_MAX_HZ=1000 > +CONFIG_ENV_SPI_MAX_HZ=5000 > CONFIG_USE_ENV_SPI_MODE=y > CONFIG_ENV_SPI_MODE=0x0 > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > @@ -102,6 +102,8 @@ CONFIG_MTD=y > CONFIG_DM_MTD=y > CONFIG_SYS_MTDPARTS_RUNTIME=y > CONFIG_DM_SPI_FLASH=y > +CONFIG_SF_DEFAULT_SPEED=5000 > +CONFIG_SPI_FLASH_SFDP_SUPPORT=y > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_SPANSION=y > CONFIG_SPI_FLASH_STMICRO=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 01ac3edb93e..21f5c9e01b2 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -67,7 +67,7 @@ CONFIG_ENV_SPI_BUS=0 > CONFIG_USE_ENV_SPI_CS=y > CONFIG_ENV_SPI_CS=0 > CONFIG_USE_ENV_SPI_MAX_HZ=y > -CONFIG_ENV_SPI_MAX_HZ=1000 > +CONFIG_ENV_SPI_MAX_HZ=5000 > CONFIG_USE_ENV_SPI_MODE=y > CONFIG_ENV_SPI_MODE=0x0 > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > @@ -97,6 +97,8 @@ CONFIG_STM32_SDMMC2=y > CONFIG_MTD=y > CONFIG_DM_MTD=y > CONFIG_DM_SPI_FLASH=y > +CONFIG_SF_DEFAULT_SPEED=5000 > +CONFIG_SPI_FLASH_SFDP_SUPPORT=y > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_SPANSION=y > CONFIG_SPI_FLASH_STMICRO=y > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote: > > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding > Macronix flash in Octal DTR mode. > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > maximum supported frequency. > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > Signed-off-by: JaimeLiao > --- > drivers/mtd/spi/Kconfig| 7 +++ > drivers/mtd/spi/spi-nor-core.c | 83 ++ > include/linux/mtd/spi-nor.h| 13 +- > 3 files changed, 101 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > index 1b2ef37e92..67599b32c9 100644 > --- a/drivers/mtd/spi/Kconfig > +++ b/drivers/mtd/spi/Kconfig > @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX > help > Add support for various Macronix SPI flash chips (MX25Lxxx) > > +config SPI_FLASH_MACRONIX_OCTAL What if we use exiting SPI_FLASH_MACRONIX for it? does it increasing size much? if not go for exiting macro.
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Hi Francois,
2021年10月25日(月) 15:28 François Ozog :
>
>
>
> Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro a
> écrit :
>>
>> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
>> > Hi Masami,
>> >
>> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
>> > wrote:
>> > >
>> > > Hi Simon,
>> > >
>> > > 2021年10月15日(金) 9:40 Simon Glass :
>> > > >
>> > > > Hi Takahiro,
>> > > >
>> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro
>> > > > wrote:
>> > > > >
>> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from
>> > > > > DTB to
>> > > > > .rodata"") failed to revert the removal of efi_get_public_key_data().
>> > > > >
>> > > > > Add back this function and move it under lib/efi_loader so that other
>> > > > > platforms can utilize it. It is now declared as a weak function so
>> > > > > that
>> > > > > it can be replaced with a platform-specific implementation.
>> > > > >
>> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
>> > > > > .rodata"")
>> > > > > Signed-off-by: AKASHI Takahiro
>> > > > > ---
>> > > > > lib/efi_loader/efi_capsule.c | 36
>> > > > >
>> > > > > 1 file changed, 36 insertions(+)
>> > > > >
>> > > > > diff --git a/lib/efi_loader/efi_capsule.c
>> > > > > b/lib/efi_loader/efi_capsule.c
>> > > > > index b75e4bcba1a9..44f5da61a9be 100644
>> > > > > --- a/lib/efi_loader/efi_capsule.c
>> > > > > +++ b/lib/efi_loader/efi_capsule.c
>> > > > > @@ -11,15 +11,20 @@
>> > > > > #include
>> > > > > #include
>> > > > > #include
>> > > > > +#include
>> > > > > +#include
>> > > > > #include
>> > > > > #include
>> > > > > #include
>> > > > > #include
>> > > > > +#include
>> > > > >
>> > > > > #include
>> > > > > #include
>> > > > > #include
>> > > > >
>> > > > > +DECLARE_GLOBAL_DATA_PTR;
>> > > > > +
>> > > > > const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
>> > > > > static const efi_guid_t efi_guid_firmware_management_capsule_id =
>> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>> > > > > @@ -251,6 +256,37 @@ out:
>> > > > > }
>> > > > >
>> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
>> > > > > *pkey_len)
>> > > >
>> > > > I don't think this should be weak. What other way is there of handling
>> > > > this and why would it be platform-specific?
>> > >
>> > > I have a question about the current design of the capsule auth key.
>> > > If the platform has its own key-storage, how can the platform use the
>> > > platform specific storage? Does such platform load the key from the
>> > > storage
>> > > and generate the dtb node in the platform initialization code? (or
>> > > device driver?)
>> >
>> > Are we talking about a public key (which I assume from the function
>> > naming) or some secret key. What is an auth key?
>>
>> Surely, a public key (more strictly, x509 certificate under the current
>> implementation)
>>
>> > As I understand it, the public key should be provided by the platform
>> > in devicetree that U-Boot uses, by whatever prior stage has access to
>> > the key.
>>
>> I still believe that some platform provider may want to save the key
>> in a *safer* storage, which should be at least read-only for non-authorized
>> writers.
>
>
> indeed. And U-Boot may not be entitled at all to check the capsule signature.
> For example updating SCP firmware with a key that is in secure world and will
> never leave this world.
I think secure world firmware updates should be discussed in another
thread, like with FWU. At this point, the capsule signature will be
only authenticated by U-Boot, because we haven't passed the capsule
image to the secure world yet.
>> But if this issue (__weak or not) is the only blocking factor
>> for my entire patch series, I'm willing to drop __weak for now since
>> someone with production system may change it in the future when he has
>> a good reason for that :)
>
>
> If that need be….
Agreed.
Thank you,
>
>>
>>
>> -Takahiro Akashi
>>
>>
>> > Regards,
>> > Simon
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
--
Masami Hiramatsu
Re: [PATCH 1/1] smbios: amend the description of smbios_string()
On 10/24/21 21:54, Simon Glass wrote: Hi Heinrich, On Thu, 21 Oct 2021 at 03:16, Heinrich Schuchardt wrote: Add a warning that this function only works for strings preceding the first non-string field. What is a non-string field? If you mean an int field, for example, then that would not have an entry in the string table, so I'm a bit unsure about what exactly the problem is? https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf Table 6 – BIOS Information (Type 0) structure "Vendor", "BIOS Version" are strings. The are followed by "BIOS Starting Address Segment" is a word which may contain a zero byte or not. You can not use smbios_string() to find the string "BIOS Release Date". Best regards Heinrich Regards, Simon Signed-off-by: Heinrich Schuchardt --- include/smbios.h | 4 1 file changed, 4 insertions(+) diff --git a/include/smbios.h b/include/smbios.h index aa6b6f3849..b7a1b8e412 100644 --- a/include/smbios.h +++ b/include/smbios.h @@ -258,6 +258,10 @@ const struct smbios_header *smbios_header(const struct smbios_entry *entry, int /** * smbios_string() - Return string from SMBIOS * + * This function counts the zero bytes at the end of strings to identify the + * string to retrieve. This only works up to the first non-string field in the + * table. + * * @header:pointer to struct smbios_header * @index: string index * @return:NULL or a valid const char pointer -- 2.32.0
Re: [PATCH] spi: zynqmp_gqspi: Fix write issue at low frequencies
On 10/19/21 16:13, Ashok Reddy Soma wrote:
With current implementation we are seeing write issues at low frequencies
below 15Mhz. Make below changes to fix the issue.
1. Remove dummy genfifo entry in zynqmp_qspi_chipselect() which was
incorrectly added in the past
2. Enable and poll for TX_FIFO_Empty after Tx data is filled in FIFO in
zynqmp_qspi_fill_tx_fifo().
Signed-off-by: Ashok Reddy Soma
---
drivers/spi/zynqmp_gqspi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index 2db4ae20f1..c772bae3cc 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -37,6 +37,7 @@
*/
#define GQSPI_IXR_TXNFULL_MASK0x0004 /* QSPI TX FIFO
Overflow */
#define GQSPI_IXR_TXFULL_MASK 0x0008 /* QSPI TX FIFO is full */
+#define GQSPI_IXR_TXFIFOEMPTY_MASK 0x0100 /* QSPI TX FIFO is Empty */
#define GQSPI_IXR_RXNEMTY_MASK0x0010 /* QSPI RX FIFO Not
Empty */
#define GQSPI_IXR_GFEMTY_MASK 0x0080 /* QSPI Generic FIFO Empty */
#define GQSPI_IXR_GFNFULL_MASK0x0200 /* QSPI GENFIFO not
full */
@@ -279,9 +280,6 @@ static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv
*priv, int is_on)
debug("GFIFO_CMD_CS: 0x%x\n", gqspi_fifo_reg);
- /* Dummy generic FIFO entry */
- zynqmp_qspi_fill_gen_fifo(priv, 0);
-
zynqmp_qspi_fill_gen_fifo(priv, gqspi_fifo_reg);
}
@@ -470,6 +468,13 @@ static int zynqmp_qspi_fill_tx_fifo(struct zynqmp_qspi_priv *priv, u32 size)
}
}
+ ret = wait_for_bit_le32(>isr, GQSPI_IXR_TXFIFOEMPTY_MASK, 1,
+ GQSPI_TIMEOUT, 1);
+ if (ret) {
+ printf("%s: Timeout\n", __func__);
+ return ret;
+ }
+
priv->tx_buf += len;
return 0;
}
applied.
M
[PATCH v2] arm: xea: Modify board code to generate single binary u-boot
This change provides the possibility to build XEA (imx287 based) board
U-Boot as a single binary (without support for CONFIG_SPL_FRAMEWORK).
The generated u-boot.sb can be used in the factory environment to for
example perform initial setup or HW testing.
It can be used with 'uuu' utility
(SDPS: boot -f /srv/tftp/xea/u-boot.sb)
In the configs/imx28_xea_defconfig one needs to disable following configs:
# CONFIG_SPL_BLK is not set
# CONFIG_SPL_FRAMEWORK is not set
The board_init_ll() is used in arch/arm/cpu/arm926ejs/mxs/start.S, which
is utilized when CONFIG_SPL_FRAMEWORK is disabled.
However, when it is enabled - the arch/arm/cpu/arm926ejs/start.S is used,
which requires the lowlevel_init() function.
Signed-off-by: Lukasz Majewski
---
Changes in v2:
- Use CONFIG_IS_ENABLED(FRAMEWORK) instead of #ifdef CONFIG_SPL_FRAMEWORK
(previous version used CONFIG_IS_ENABLED(SPL_FRAMEWORK), which was
wrong).
- Restructure spl_xea.c code to be more readable
board/liebherr/xea/spl_xea.c | 8
board/liebherr/xea/xea.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 192f68fca5f..5ee561b8b78 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -290,6 +290,13 @@ u32 mxs_dram_vals[] = {
0x, 0x
};
+/* #ifndef CONFIG_SPL_FRAMEWORK */
+#if !CONFIG_IS_ENABLED(FRAMEWORK)
+void board_init_ll(const u32 arg, const uint32_t *resptr)
+{
+ mxs_common_spl_init(arg, resptr, iomux_setup, ARRAY_SIZE(iomux_setup));
+}
+#else
void lowlevel_init(void)
{
struct mxs_pinctrl_regs *pinctrl_regs =
@@ -301,3 +308,4 @@ void lowlevel_init(void)
mxs_common_spl_init(0, NULL, iomux_setup, ARRAY_SIZE(iomux_setup));
}
+#endif
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index cd11b0ada77..685e2e26a18 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -58,7 +58,8 @@ static void init_clocks(void)
mxs_set_sspclk(MXC_SSPCLK3, 96000, 0);
}
-#ifdef CONFIG_SPL_BUILD
+/* #if CONFIG_SPL_BUILD && CONFIG_SPL_FRAMEWORK */
+#if CONFIG_IS_ENABLED(BUILD) && CONFIG_IS_ENABLED(FRAMEWORK)
void board_init_f(ulong arg)
{
init_clocks();
--
2.20.1
Re: [PATCH v4 05/11] tools: mkeficapsule: add firmwware image signing
On Mon, Oct 25, 2021 at 02:40:11PM +0900, Masami Hiramatsu wrote: > Hi Takahiro, > > 2021年10月25日(月) 12:12 AKASHI Takahiro : > > > > Hi, Masami, > > > > On Wed, Oct 20, 2021 at 05:17:12PM +0900, Masami Hiramatsu wrote: > > > Hello Akashi-san, > > > > > > Can you split this patch out from this series? > > > It seems that the series is doing several different things. This > > > capsule signing has no alternatives, but others are modifying or > > > replacing the current existing feature. In other words, this capsule > > > signing feature has no alternatives, but others we can continue to > > > use. > > > > What do you specifically mean by "existing feature" or "others we can > > continue to use"? > > > > All the commits, I think, in this series are closely related with > > each other. > > I meant I can use the devicetree to embed the authentication key in the > U-Boot itself (currently U-Boot expects that.) Or is there any issue with > putting the key in the devicetree? I don't get why this particular patch be separated from the others. Some are prerequisite "revert" commits, some are updates on documents, and some are test scriptsa All changes can and should be merged at one time. > Without this patch, I can not sign the capsule file for U-Boot, since > the GenerateCapsule in EDK2 supports old format (is that updated?) I don't know, but Sughosh was working on the issue, he might have a patch for EDK2? -Takahiro Akashi > Thank you, > > > > > > -Takahiro Akashi > > > > > Thank you, > > > > > > 2021年10月7日(木) 15:25 AKASHI Takahiro : > > > > > > > > With this enhancement, mkeficapsule will be able to sign a capsule > > > > file when it is created. A signature added will be used later > > > > in the verification at FMP's SetImage() call. > > > > > > > > To do that, We need specify additional command parameters: > > > > -monotonic-cout : monotonic count > > > > -private-key : private key file > > > > -certificate : certificate file > > > > Only when all of those parameters are given, a signature will be added > > > > to a capsule file. > > > > > > > > Users are expected to maintain and increment the monotonic count at > > > > every time of the update for each firmware image. > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > --- > > > > tools/Kconfig| 7 + > > > > tools/Makefile | 8 +- > > > > tools/mkeficapsule.c | 435 +++ > > > > 3 files changed, 416 insertions(+), 34 deletions(-) > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig > > > > index d6f82cd949b5..9a37ed035311 100644 > > > > --- a/tools/Kconfig > > > > +++ b/tools/Kconfig > > > > @@ -20,4 +20,11 @@ config TOOLS_LIBCRYPTO > > > > This selection does not affect target features, such as > > > > runtime FIT > > > > signature verification. > > > > > > > > +config TOOLS_MKEFICAPSULE > > > > + bool "Build efimkcapsule command" > > > > + default y if EFI_CAPSULE_ON_DISK > > > > + help > > > > + This command allows users to create a UEFI capsule file and, > > > > + optionally sign that file. If you want to enable UEFI capsule > > > > + update feature on your target, you certainly need this. > > > > endmenu > > > > diff --git a/tools/Makefile b/tools/Makefile > > > > index 4a86321f6467..6ea3033dbfb8 100644 > > > > --- a/tools/Makefile > > > > +++ b/tools/Makefile > > > > @@ -237,8 +237,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs > > > > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler > > > > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include > > > > > > > > -mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS) > > > > -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule > > > > +HOSTLDLIBS_mkeficapsule += -luuid > > > > +ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y) > > > > +HOSTLDLIBS_mkeficapsule += \ > > > > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo > > > > "-lssl -lcrypto") > > > > +endif > > > > +hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule > > > > > > > > # We build some files with extra pedantic flags to try to minimize > > > > things > > > > # that won't build on some weird host compiler -- though there are > > > > lots of > > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c > > > > index 4995ba4e0c2a..5541e4bda894 100644 > > > > --- a/tools/mkeficapsule.c > > > > +++ b/tools/mkeficapsule.c > > > > @@ -15,6 +15,16 @@ > > > > #include > > > > #include > > > > > > > > +#include > > > > +#ifdef CONFIG_TOOLS_LIBCRYPTO > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#endif > > > > + > > > > typedef __u8 u8; > > > > typedef __u16 u16; > > > > typedef __u32 u32; > > > > @@ -38,12 +48,25 @@ efi_guid_t efi_guid_image_type_uboot_fit = > > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; > > > > efi_guid_t efi_guid_image_type_uboot_raw = > >
Re: [PATCH 1/2] ARM: stm32: Disable EFI on DHSOM
Hi Marek On 10/23/21 8:33 PM, Marek Vasut wrote: > The EFI support is unused and disabling it saves about 70 kiB of space. > In case EFI support is required, it can be re-enabled. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > configs/stm32mp15_dhcom_basic_defconfig | 4 > configs/stm32mp15_dhcor_basic_defconfig | 4 > 2 files changed, 8 insertions(+) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 8fe0456a56d..ae9c3cdc25f 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -62,6 +62,8 @@ CONFIG_CMD_REGULATOR=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_MTDPARTS=y > # CONFIG_SPL_DOS_PARTITION is not set > +# CONFIG_ISO_PARTITION is not set > +# CONFIG_SPL_PARTITION_UUIDS is not set > CONFIG_OF_LIST="stm32mp15xx-dhcom-pdk2 stm32mp15xx-dhcom-drc02 > stm32mp15xx-dhcom-picoitx" > CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-names interrupts-extended > interrupt-controller \\\#interrupt-cells interrupt-parent dmas dma-names > assigned-clocks assigned-clock-rates assigned-clock-parents hwlocks" > CONFIG_ENV_IS_IN_SPI_FLASH=y > @@ -157,5 +159,7 @@ CONFIG_VIDEO_BMP_RLE8=y > CONFIG_BMP_16BPP=y > CONFIG_BMP_24BPP=y > CONFIG_BMP_32BPP=y > +CONFIG_FAT_WRITE=y > CONFIG_LZO=y > CONFIG_FDT_FIXUP_PARTITIONS=y > +# CONFIG_EFI_LOADER is not set > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 21f5c9e01b2..98ba37c750e 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -60,6 +60,8 @@ CONFIG_CMD_REGULATOR=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_MTDPARTS=y > # CONFIG_SPL_DOS_PARTITION is not set > +# CONFIG_ISO_PARTITION is not set > +# CONFIG_SPL_PARTITION_UUIDS is not set > CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-names interrupts-extended > interrupt-controller \\\#interrupt-cells interrupt-parent dmas dma-names > assigned-clocks assigned-clock-rates assigned-clock-parents hwlocks" > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_USE_ENV_SPI_BUS=y > @@ -151,5 +153,7 @@ CONFIG_VIDEO_BMP_RLE8=y > CONFIG_BMP_16BPP=y > CONFIG_BMP_24BPP=y > CONFIG_BMP_32BPP=y > +CONFIG_FAT_WRITE=y > CONFIG_LZO=y > CONFIG_FDT_FIXUP_PARTITIONS=y > +# CONFIG_EFI_LOADER is not set > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH v4 05/11] tools: mkeficapsule: add firmwware image signing
Hi Takahiro, 2021年10月25日(月) 15:09 AKASHI Takahiro : > > On Mon, Oct 25, 2021 at 02:40:11PM +0900, Masami Hiramatsu wrote: > > Hi Takahiro, > > > > 2021年10月25日(月) 12:12 AKASHI Takahiro : > > > > > > Hi, Masami, > > > > > > On Wed, Oct 20, 2021 at 05:17:12PM +0900, Masami Hiramatsu wrote: > > > > Hello Akashi-san, > > > > > > > > Can you split this patch out from this series? > > > > It seems that the series is doing several different things. This > > > > capsule signing has no alternatives, but others are modifying or > > > > replacing the current existing feature. In other words, this capsule > > > > signing feature has no alternatives, but others we can continue to > > > > use. > > > > > > What do you specifically mean by "existing feature" or "others we can > > > continue to use"? > > > > > > All the commits, I think, in this series are closely related with > > > each other. > > > > I meant I can use the devicetree to embed the authentication key in the > > U-Boot itself (currently U-Boot expects that.) Or is there any issue with > > putting the key in the devicetree? > > I don't get why this particular patch be separated from the others. > Some are prerequisite "revert" commits, some are updates on documents, > and some are test scriptsa All changes can and should be merged at one time. Ah, OK. I got it. I just thought, adding lacked feature and update documents for that should not be decoupled, but I thought the "revert" part can be decoupled. Thank you, > > > Without this patch, I can not sign the capsule file for U-Boot, since > > the GenerateCapsule in EDK2 supports old format (is that updated?) > > I don't know, but Sughosh was working on the issue, he might have a patch > for EDK2? > > -Takahiro Akashi > > > Thank you, > > > > > > > > > > -Takahiro Akashi > > > > > > > Thank you, > > > > > > > > 2021年10月7日(木) 15:25 AKASHI Takahiro : > > > > > > > > > > With this enhancement, mkeficapsule will be able to sign a capsule > > > > > file when it is created. A signature added will be used later > > > > > in the verification at FMP's SetImage() call. > > > > > > > > > > To do that, We need specify additional command parameters: > > > > > -monotonic-cout : monotonic count > > > > > -private-key : private key file > > > > > -certificate : certificate file > > > > > Only when all of those parameters are given, a signature will be added > > > > > to a capsule file. > > > > > > > > > > Users are expected to maintain and increment the monotonic count at > > > > > every time of the update for each firmware image. > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > --- > > > > > tools/Kconfig| 7 + > > > > > tools/Makefile | 8 +- > > > > > tools/mkeficapsule.c | 435 > > > > > +++ > > > > > 3 files changed, 416 insertions(+), 34 deletions(-) > > > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig > > > > > index d6f82cd949b5..9a37ed035311 100644 > > > > > --- a/tools/Kconfig > > > > > +++ b/tools/Kconfig > > > > > @@ -20,4 +20,11 @@ config TOOLS_LIBCRYPTO > > > > > This selection does not affect target features, such as > > > > > runtime FIT > > > > > signature verification. > > > > > > > > > > +config TOOLS_MKEFICAPSULE > > > > > + bool "Build efimkcapsule command" > > > > > + default y if EFI_CAPSULE_ON_DISK > > > > > + help > > > > > + This command allows users to create a UEFI capsule file and, > > > > > + optionally sign that file. If you want to enable UEFI > > > > > capsule > > > > > + update feature on your target, you certainly need this. > > > > > endmenu > > > > > diff --git a/tools/Makefile b/tools/Makefile > > > > > index 4a86321f6467..6ea3033dbfb8 100644 > > > > > --- a/tools/Makefile > > > > > +++ b/tools/Makefile > > > > > @@ -237,8 +237,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs > > > > > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler > > > > > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include > > > > > > > > > > -mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS) > > > > > -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule > > > > > +HOSTLDLIBS_mkeficapsule += -luuid > > > > > +ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y) > > > > > +HOSTLDLIBS_mkeficapsule += \ > > > > > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || > > > > > echo "-lssl -lcrypto") > > > > > +endif > > > > > +hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule > > > > > > > > > > # We build some files with extra pedantic flags to try to minimize > > > > > things > > > > > # that won't build on some weird host compiler -- though there are > > > > > lots of > > > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c > > > > > index 4995ba4e0c2a..5541e4bda894 100644 > > > > > --- a/tools/mkeficapsule.c > > > > > +++ b/tools/mkeficapsule.c > > > > > @@ -15,6 +15,16 @@ > > > > > #include > > > > > #include > >
Re: [PATCH 2/2] efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot
On Sat, 23 Oct 2021 at 18:42, Heinrich Schuchardt wrote: > > > > On 10/22/21 13:24, Masahisa Kojima wrote: > > This commit adds the missing EFI_TCG2_PROTOCOL selftest > > and Measured Boot selftest in lib/efi_selftest. > > > > Signed-off-by: Masahisa Kojima > > --- > > lib/efi_selftest/Makefile | 10 + > > .../efi_selftest_miniapp_measuredboot.c | 93 ++ > > lib/efi_selftest/efi_selftest_tcg2.c | 804 +- > > 3 files changed, 906 insertions(+), 1 deletion(-) > > create mode 100644 lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > > > diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile > > index 9ff6e1760c..09950ee028 100644 > > --- a/lib/efi_selftest/Makefile > > +++ b/lib/efi_selftest/Makefile > > @@ -14,6 +14,8 @@ CFLAGS_efi_selftest_miniapp_exception.o := $(CFLAGS_EFI) > > -Os -ffreestanding > > CFLAGS_REMOVE_efi_selftest_miniapp_exception.o := $(CFLAGS_NON_EFI) > > CFLAGS_efi_selftest_miniapp_exit.o := $(CFLAGS_EFI) -Os -ffreestanding > > CFLAGS_REMOVE_efi_selftest_miniapp_exit.o := $(CFLAGS_NON_EFI) > > +CFLAGS_efi_selftest_miniapp_measuredboot.o := $(CFLAGS_EFI) -Os > > -ffreestanding > > +CFLAGS_REMOVE_efi_selftest_miniapp_measuredboot.o := $(CFLAGS_NON_EFI) > > CFLAGS_efi_selftest_miniapp_return.o := $(CFLAGS_EFI) -Os -ffreestanding > > CFLAGS_REMOVE_efi_selftest_miniapp_return.o := $(CFLAGS_NON_EFI) > > CFLAGS_initrddump_exit.o := $(CFLAGS_EFI) -Os -ffreestanding > > @@ -78,9 +80,11 @@ obj-$(CONFIG_EFI_ESRT) += efi_selftest_esrt.o > > targets += \ > > efi_miniapp_file_image_exception.h \ > > efi_miniapp_file_image_exit.h \ > > +efi_miniapp_file_image_measuredboot.h \ > > efi_miniapp_file_image_return.h \ > > efi_selftest_miniapp_exception.efi \ > > efi_selftest_miniapp_exit.efi \ > > +efi_selftest_miniapp_measuredboot.efi \ > > efi_selftest_miniapp_return.efi > > > > ifeq ($(CONFIG_GENERATE_ACPI_TABLE),) > > @@ -99,6 +103,10 @@ $(obj)/efi_miniapp_file_image_exit.h: > > $(obj)/efi_selftest_miniapp_exit.efi > > $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_exit.efi > > > \ > > $(obj)/efi_miniapp_file_image_exit.h > > > > +$(obj)/efi_miniapp_file_image_measuredboot.h: > > $(obj)/efi_selftest_miniapp_measuredboot.efi > > + $(obj)/../../tools/file2include > > $(obj)/efi_selftest_miniapp_measuredboot.efi > \ > > + $(obj)/efi_miniapp_file_image_measuredboot.h > > + > > $(obj)/efi_miniapp_file_image_return.h: > > $(obj)/efi_selftest_miniapp_return.efi > > $(obj)/../../tools/file2include > > $(obj)/efi_selftest_miniapp_return.efi > \ > > $(obj)/efi_miniapp_file_image_return.h > > @@ -112,3 +120,5 @@ $(obj)/efi_selftest_loadimage.o: > > $(obj)/efi_miniapp_file_image_exit.h > > $(obj)/efi_selftest_startimage_exit.o: > > $(obj)/efi_miniapp_file_image_exit.h > > > > $(obj)/efi_selftest_startimage_return.o: > > $(obj)/efi_miniapp_file_image_return.h > > + > > +$(obj)/efi_selftest_tcg2.o: $(obj)/efi_miniapp_file_image_measuredboot.h > > diff --git a/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > Thank you for going the extra mile and adding the test. > > Which image is actually loaded seems to be irrelevant for the test. Can > we reuse an existing one, e.g. efi_miniapp_file_image_return.h? > > I guess the PCR related to the loaded image is not checked as it will > depend on the build tools and date. Sorry, I'm doing wrong. Actually this selftest verifies the PE/COFF image measurement, so measuremt will be different depending on the build tools and date. # In my build environment, timestamp is set to all zero. To test the PE/COFF image measurement, I must prepare the static PE/COFF image. I plan to add efi_miniapp_file_image_measuredboot.h as a pre-compiled small static PE/COFF image for the measurement test, instead of adding efi_selftest_miniapp_measuredboot.c or reusing existing one. > > > new file mode 100644 > > index 00..926713c1c2 > > --- /dev/null > > +++ b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > @@ -0,0 +1,93 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * efi_selftest_miniapp_measuredboot > > + * > > + * Copyright (c) 2018 Heinrich Schuchardt > > + * Copyright (c) 2021 Masahisa Kojima > > + * > > + * This EFI application is run by the StartImage selftest. > > This is incorrect due to copy and paste. > > > + * It uses the Exit boot service to return and used for > > + * Measured Boot selftest. > > + */ > > + > > +#include > > +#include > > + > > +static efi_guid_t loaded_image_protocol_guid = > > EFI_LOADED_IMAGE_PROTOCOL_GUID; > > + > > +/** > > + * check_loaded_image_protocol() - check image_base/image_size > > + * > > + * Try to open the loaded image protocol. Check that this function is > > located > > + * between image_base and image_base + image_size. > > + * > > + * @image_handle:handle of the loaded image >
Re: [PATCH v4 05/11] tools: mkeficapsule: add firmwware image signing
hi Masami, On Mon, 25 Oct 2021 at 11:10, Masami Hiramatsu wrote: > Hi Takahiro, > > 2021年10月25日(月) 12:12 AKASHI Takahiro : > > > > Hi, Masami, > > > > On Wed, Oct 20, 2021 at 05:17:12PM +0900, Masami Hiramatsu wrote: > > > Hello Akashi-san, > > > > > > Can you split this patch out from this series? > > > It seems that the series is doing several different things. This > > > capsule signing has no alternatives, but others are modifying or > > > replacing the current existing feature. In other words, this capsule > > > signing feature has no alternatives, but others we can continue to > > > use. > > > > What do you specifically mean by "existing feature" or "others we can > > continue to use"? > > > > All the commits, I think, in this series are closely related with > > each other. > > I meant I can use the devicetree to embed the authentication key in the > U-Boot itself (currently U-Boot expects that.) Or is there any issue with > putting the key in the devicetree? > > Without this patch, I can not sign the capsule file for U-Boot, since > the GenerateCapsule in EDK2 supports old format (is that updated?) > If you are referring to using Version 3 of the FMP Image Header structure, yes this has been upstreamed in EDK2. You can rebase and use the current GenerateCapsule script. Thanks. -sughosh > > Thank you, > > > > > > -Takahiro Akashi > > > > > Thank you, > > > > > > 2021年10月7日(木) 15:25 AKASHI Takahiro : > > > > > > > > With this enhancement, mkeficapsule will be able to sign a capsule > > > > file when it is created. A signature added will be used later > > > > in the verification at FMP's SetImage() call. > > > > > > > > To do that, We need specify additional command parameters: > > > > -monotonic-cout : monotonic count > > > > -private-key : private key file > > > > -certificate : certificate file > > > > Only when all of those parameters are given, a signature will be > added > > > > to a capsule file. > > > > > > > > Users are expected to maintain and increment the monotonic count at > > > > every time of the update for each firmware image. > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > --- > > > > tools/Kconfig| 7 + > > > > tools/Makefile | 8 +- > > > > tools/mkeficapsule.c | 435 > +++ > > > > 3 files changed, 416 insertions(+), 34 deletions(-) > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig > > > > index d6f82cd949b5..9a37ed035311 100644 > > > > --- a/tools/Kconfig > > > > +++ b/tools/Kconfig > > > > @@ -20,4 +20,11 @@ config TOOLS_LIBCRYPTO > > > > This selection does not affect target features, such as > runtime FIT > > > > signature verification. > > > > > > > > +config TOOLS_MKEFICAPSULE > > > > + bool "Build efimkcapsule command" > > > > + default y if EFI_CAPSULE_ON_DISK > > > > + help > > > > + This command allows users to create a UEFI capsule file > and, > > > > + optionally sign that file. If you want to enable UEFI > capsule > > > > + update feature on your target, you certainly need this. > > > > endmenu > > > > diff --git a/tools/Makefile b/tools/Makefile > > > > index 4a86321f6467..6ea3033dbfb8 100644 > > > > --- a/tools/Makefile > > > > +++ b/tools/Makefile > > > > @@ -237,8 +237,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs > > > > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler > > > > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include > > > > > > > > -mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS) > > > > -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule > > > > +HOSTLDLIBS_mkeficapsule += -luuid > > > > +ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y) > > > > +HOSTLDLIBS_mkeficapsule += \ > > > > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || > echo "-lssl -lcrypto") > > > > +endif > > > > +hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule > > > > > > > > # We build some files with extra pedantic flags to try to minimize > things > > > > # that won't build on some weird host compiler -- though there are > lots of > > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c > > > > index 4995ba4e0c2a..5541e4bda894 100644 > > > > --- a/tools/mkeficapsule.c > > > > +++ b/tools/mkeficapsule.c > > > > @@ -15,6 +15,16 @@ > > > > #include > > > > #include > > > > > > > > +#include > > > > +#ifdef CONFIG_TOOLS_LIBCRYPTO > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#endif > > > > + > > > > typedef __u8 u8; > > > > typedef __u16 u16; > > > > typedef __u32 u32; > > > > @@ -38,12 +48,25 @@ efi_guid_t efi_guid_image_type_uboot_fit = > > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; > > > > efi_guid_t efi_guid_image_type_uboot_raw = > > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID; > > > > +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID; > > > > + >
Re: [PATCH v2 1/3] rockchip: Kconfig: Enable SPL support for rk3568
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote: > > Enable SPL support in Kconfig and add some related option in > rk3568_common.h > > Signed-off-by: Nico Cheng > Signed-off-by: Jason Zhu Acked-by: Philipp Tomsich
[PATCH 0/2] cmd: sbi: show SBI implementation version
The sbi command can already show the SBI implementation (e.g. OpenSBI). But the implementation version is no displayed. Heinrich Schuchardt (2): riscv: function to retrieve SBI implementation version cmd: sbi: show SBI implementation version arch/riscv/include/asm/sbi.h | 1 + arch/riscv/lib/sbi.c | 19 +++ cmd/riscv/sbi.c | 26 ++ 3 files changed, 38 insertions(+), 8 deletions(-) -- 2.32.0
[PATCH 2/2] cmd: sbi: show SBI implementation version
Let the sbi command show the SBI implementation version
Signed-off-by: Heinrich Schuchardt
---
cmd/riscv/sbi.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/cmd/riscv/sbi.c b/cmd/riscv/sbi.c
index 90c0811e14..ed0960c2f2 100644
--- a/cmd/riscv/sbi.c
+++ b/cmd/riscv/sbi.c
@@ -49,24 +49,34 @@ static struct sbi_ext extensions[] = {
static int do_sbi(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- int i;
+ int i, impl_id;
long ret;
ret = sbi_get_spec_version();
if (ret >= 0)
- printf("SBI %ld.%ld\n", ret >> 24, ret & 0xff);
- ret = sbi_get_impl_id();
- if (ret >= 0) {
+ printf("SBI %ld.%ld", ret >> 24, ret & 0xff);
+ impl_id = sbi_get_impl_id();
+ if (impl_id >= 0) {
for (i = 0; i < ARRAY_SIZE(implementations); ++i) {
- if (ret == implementations[i].id) {
- printf("%s\n", implementations[i].name);
+ if (impl_id == implementations[i].id) {
+ long vers;
+
+ printf("\n%s ", implementations[i].name);
+ ret = sbi_get_impl_version();
+ if (ret < 0)
+ break;
+ if (impl_id == 1)
+ printf("%ld.%ld",
+ vers >> 16, vers & 0x);
+ else
+ printf("0x%lx", vers);
break;
}
}
if (i == ARRAY_SIZE(implementations))
- printf("Unknown implementation ID %ld\n", ret);
+ printf("Unknown implementation ID %ld", ret);
}
- printf("Extensions:\n");
+ printf("\nExtensions:\n");
for (i = 0; i < ARRAY_SIZE(extensions); ++i) {
ret = sbi_probe_extension(extensions[i].id);
if (ret > 0)
--
2.32.0
[PATCH 1/2] riscv: function to retrieve SBI implementation version
Provide function sbi_get_impl_version() to retrieve the SBI implementation
version.
Signed-off-by: Heinrich Schuchardt
---
arch/riscv/include/asm/sbi.h | 1 +
arch/riscv/lib/sbi.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 53ca316180..110ec28ef5 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -117,6 +117,7 @@ void sbi_remote_sfence_vma_asid(const unsigned long
*hart_mask,
void sbi_set_timer(uint64_t stime_value);
long sbi_get_spec_version(void);
int sbi_get_impl_id(void);
+int sbi_get_impl_version(long *version);
int sbi_probe_extension(int ext);
#endif
diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c
index 77845a73ca..cf13a2f17e 100644
--- a/arch/riscv/lib/sbi.c
+++ b/arch/riscv/lib/sbi.c
@@ -89,6 +89,25 @@ int sbi_get_impl_id(void)
return -ENOTSUPP;
}
+/**
+ * sbi_get_impl_version() - get SBI implementation version
+ *
+ * @version: pointer to receive version
+ * Return: 0 on success, -ENOTSUPP otherwise
+ */
+int sbi_get_impl_version(long *version)
+{
+ struct sbiret ret;
+
+ ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_GET_IMP_VERSION,
+ 0, 0, 0, 0, 0, 0);
+ if (ret.error)
+ return -ENOTSUPP;
+ if (version)
+ *version = ret.value;
+ return 0;
+}
+
/**
* sbi_probe_extension() - Check if an SBI extension ID is supported or not.
* @extid: The extension ID to be probed.
--
2.32.0
[PATCH u-boot-marvell 10/13] tools: kwboot: Do not modify kwbimage header before increasing its size
From: Pali Rohár
This ensures that kwboot_img_grow_hdr() function still sees valid kwbimage
header.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index adec4ec97d..bb7555369c 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1352,17 +1352,18 @@ kwboot_add_bin_ohdr_v1(void *img, size_t *size,
uint32_t binsz)
uint32_t num_args;
uint32_t offset;
uint32_t ohdrsz;
+ uint8_t *prev_ext;
if (hdr->ext & 0x1) {
for_each_opt_hdr_v1 (ohdr, img)
if (opt_hdr_v1_next(ohdr) == NULL)
break;
- *opt_hdr_v1_ext(ohdr) |= 1;
- ohdr = opt_hdr_v1_next(ohdr);
+ prev_ext = opt_hdr_v1_ext(ohdr);
+ ohdr = _opt_hdr_v1_next(ohdr);
} else {
- hdr->ext |= 1;
ohdr = (void *)(hdr + 1);
+ prev_ext = >ext;
}
/*
@@ -1377,6 +1378,8 @@ kwboot_add_bin_ohdr_v1(void *img, size_t *size, uint32_t
binsz)
ohdrsz = sizeof(*ohdr) + 4 + 4 * num_args + binsz + 4;
kwboot_img_grow_hdr(hdr, size, ohdrsz);
+ *prev_ext |= 1;
+
ohdr->headertype = OPT_HDR_V1_BINARY_TYPE;
ohdr->headersz_msb = ohdrsz >> 16;
ohdr->headersz_lsb = cpu_to_le16(ohdrsz & 0x);
--
2.32.0
[PATCH u-boot-marvell 09/13] tools: kwboot: Simplify code for aligning image header
From: Pali Rohár
Expression (hdrsz % KWBOOT_XM_BLKSZ) is non-zero therefore expression
(KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) is always less than value
KWBOOT_XM_BLKSZ. So there is no need to add another modulo. Also rename
variable `offset` to `grow` which better describes what is stored in
this variable.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7fd28aa754..adec4ec97d 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1563,8 +1563,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
}
if (hdrsz % KWBOOT_XM_BLKSZ) {
- size_t offset = (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) %
- KWBOOT_XM_BLKSZ;
+ size_t grow = KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ;
if (is_secure) {
fprintf(stderr, "Cannot align image with secure
header\n");
@@ -1572,7 +1571,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
}
kwboot_printv("Aligning image header to Xmodem block size\n");
- kwboot_img_grow_hdr(img, size, offset);
+ kwboot_img_grow_hdr(img, size, grow);
}
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
--
2.32.0
[PATCH u-boot-marvell 12/13] tools: kwboot: Change retry loop from decreasing to increasing
From: Pali Rohár
This patch does not change behavior of the code, just allows to implement
new changes more easily.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 5d7cb7a774..16c5a84825 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -925,7 +925,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
*done_print = 0;
- retries = 16;
+ retries = 0;
do {
rc = kwboot_tty_send(fd, block, sizeof(*block));
if (rc)
@@ -944,7 +944,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
if (!allow_non_xm && c != ACK)
kwboot_progress(-1, '+');
- } while (c == NAK && retries-- > 0);
+ } while (c == NAK && retries++ < 16);
if (non_xm_print)
kwboot_printv("\n");
@@ -973,7 +973,7 @@ kwboot_xm_finish(int fd)
kwboot_printv("Finishing transfer\n");
- retries = 16;
+ retries = 0;
do {
rc = kwboot_tty_send_char(fd, EOT);
if (rc)
@@ -982,7 +982,7 @@ kwboot_xm_finish(int fd)
rc = kwboot_xm_recv_reply(fd, , 0, NULL, 0, NULL);
if (rc)
return rc;
- } while (c == NAK && retries-- > 0);
+ } while (c == NAK && retries++ < 16);
return _xm_reply_to_error(c);
}
--
2.32.0
[PATCH u-boot-marvell 11/13] tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr()
From: Pali Rohár
Size of the header stored in kwbimage may be larger than real used size in
the kwbimage header. If there is unused space in kwbimage header then use
it for growing it. So update code to calculate used space of kwbimage
header.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index bb7555369c..5d7cb7a774 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1318,11 +1318,20 @@ kwboot_img_grow_hdr(void *img, size_t *size, size_t
grow)
{
uint32_t hdrsz, datasz, srcaddr;
struct main_hdr_v1 *hdr = img;
+ struct opt_hdr_v1 *ohdr;
uint8_t *data;
srcaddr = le32_to_cpu(hdr->srcaddr);
- hdrsz = kwbheader_size(img);
+ /* calculate real used space in kwbimage header */
+ if (kwbimage_version(img) == 0) {
+ hdrsz = kwbheader_size(img);
+ } else {
+ hdrsz = sizeof(*hdr);
+ for_each_opt_hdr_v1 (ohdr, hdr)
+ hdrsz += opt_hdr_v1_size(ohdr);
+ }
+
data = (uint8_t *)img + srcaddr;
datasz = *size - srcaddr;
@@ -1339,8 +1348,10 @@ kwboot_img_grow_hdr(void *img, size_t *size, size_t grow)
if (kwbimage_version(img) == 1) {
hdrsz += grow;
- hdr->headersz_msb = hdrsz >> 16;
- hdr->headersz_lsb = cpu_to_le16(hdrsz & 0x);
+ if (hdrsz > kwbheader_size(img)) {
+ hdr->headersz_msb = hdrsz >> 16;
+ hdr->headersz_lsb = cpu_to_le16(hdrsz & 0x);
+ }
}
}
--
2.32.0
[PATCH u-boot-marvell 13/13] tools: kwboot: Resend first 3 xmodem retry packets immediately
From: Pali Rohár
Currently when kwboot receive some garbage reply which does not understand,
it waits 1s before it tries to resend packet again.
The most common error on UART is that receiver sees some bit flipped which
results in invalid reply.
This behavior slows down xmodem transfer over UART as basically on every
error kwboot is waiting one second.
To fix this, try to resend xmodem packet for first 3 attempts immediately
without any delay. If broken reply is received also after the 3 attempts,
continue retrying with 1s delay like it was before.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 16c5a84825..bb7cae9f05 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -851,7 +851,8 @@ kwboot_baud_magic_handle(int fd, char c, int baudrate)
}
static int
-kwboot_xm_recv_reply(int fd, char *c, int allow_non_xm, int *non_xm_print,
+kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
+int allow_non_xm, int *non_xm_print,
int baudrate, int *baud_changed)
{
int timeout = allow_non_xm ? KWBOOT_HDR_RSP_TIMEO : blk_rsp_timeo;
@@ -904,6 +905,10 @@ kwboot_xm_recv_reply(int fd, char *c, int allow_non_xm,
int *non_xm_print,
*non_xm_print = 1;
}
} else {
+ if (nak_on_non_xm) {
+ *c = NAK;
+ break;
+ }
timeout = recv_until - _now();
if (timeout < 0) {
errno = ETIMEDOUT;
@@ -937,7 +942,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
*done_print = 1;
}
- rc = kwboot_xm_recv_reply(fd, , allow_non_xm, _xm_print,
+ rc = kwboot_xm_recv_reply(fd, , retries < 3,
+ allow_non_xm, _xm_print,
baudrate, _changed);
if (rc)
goto can;
@@ -979,7 +985,8 @@ kwboot_xm_finish(int fd)
if (rc)
return rc;
- rc = kwboot_xm_recv_reply(fd, , 0, NULL, 0, NULL);
+ rc = kwboot_xm_recv_reply(fd, , retries < 3,
+ 0, NULL, 0, NULL);
if (rc)
return rc;
} while (c == NAK && retries++ < 16);
--
2.32.0
[PATCH u-boot-marvell 07/13] tools: kwboot: Correctly set configuration of UART for BootROM messages
From: Pali Rohár
For kwbimage v1, tell BootROM to send BootROM messages to UART port number
0 (used also for UART booting) with default baudrate (which should be
115200) and do not touch UART MPP configuration.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1131c2eb1c..6228838228 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1507,6 +1507,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
}
if (!is_secure) {
+ if (image_ver == 1) {
+ /*
+* Tell BootROM to send BootROM messages to UART port
+* number 0 (used also for UART booting) with default
+* baudrate (which should be 115200) and do not touch
+* UART MPP configuration.
+*/
+ hdr->options &= ~0x1F;
+ hdr->options |= MAIN_HDR_V1_OPT_BAUD_DEFAULT;
+ hdr->options |= 0 << 3;
+ }
if (image_ver == 0)
((struct main_hdr_v0 *)img)->nandeccmode =
IBR_HDR_ECC_DISABLED;
hdr->nandpagesize = 0;
--
2.32.0
[PATCH u-boot-marvell 08/13] tools: kwboot: Show verbose message when waiting for baudrate change magic
From: Pali Rohár
It is hard to debug why kwboot is failing when the last message is
'Finishing transfer' and no additional output. So show verbose message when
kwboot finished transfer and is waiting for baudrate change magic sequence.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 6228838228..7fd28aa754 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1065,7 +1065,7 @@ kwboot_xmodem(int tty, const void *_img, size_t size, int
baudrate)
if (baudrate) {
char buf[sizeof(kwb_baud_magic)];
- /* Wait 1s for baudrate change magic */
+ kwboot_printv("Waiting 1s for baudrate change magic\n");
rc = kwboot_tty_recv(tty, buf, sizeof(buf), 1000);
if (rc)
return rc;
--
2.32.0
Re: [PATCH 2/3] phy: sun4i-usb: Refactor VBUS detection to match Linux
On Sun, 12 Sep 2021 09:22:41 -0500
Samuel Holland wrote:
Hi,
> The Linux driver checks the VBUS detection GPIO first; then VBUS power
> supply; then finally assumes VBUS is present. When adding VBUS power
> supply support, we want to match that order, so we get the same behavior
> in case both a GPIO and a power supply are provided in the device tree.
>
> So refactor the function a bit to remove the early return, and use the
> same "assume VBUS is present" final fallback.
>
> Signed-off-by: Samuel Holland
Let's see if testing reveals any subtle issues ;-)
Acked-by: Andre Przywara
Cheers,
Andre
> ---
>
> drivers/phy/allwinner/phy-sun4i-usb.c | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 5302b809ee6..827ecd70f27 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -391,20 +391,19 @@ int sun4i_usb_phy_vbus_detect(struct phy *phy)
> {
> struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
> struct sun4i_usb_phy_plat *usb_phy = >usb_phy[phy->id];
> - int err, retries = 3;
> -
> - if (usb_phy->gpio_vbus_det < 0)
> - return usb_phy->gpio_vbus_det;
> -
> - err = gpio_get_value(usb_phy->gpio_vbus_det);
> - /*
> - * Vbus may have been provided by the board and just been turned of
> - * some milliseconds ago on reset, what we're measuring then is a
> - * residual charge on Vbus, sleep a bit and try again.
> - */
> - while (err > 0 && retries--) {
> - mdelay(100);
> + int err = 1, retries = 3;
> +
> + if (usb_phy->gpio_vbus_det >= 0) {
> err = gpio_get_value(usb_phy->gpio_vbus_det);
> + /*
> + * Vbus may have been provided by the board and just turned off
> + * some milliseconds ago on reset. What we're measuring then is
> + * a residual charge on Vbus. Sleep a bit and try again.
> + */
> + while (err > 0 && retries--) {
> + mdelay(100);
> + err = gpio_get_value(usb_phy->gpio_vbus_det);
> + }
> }
>
> return err;
Re: [PATCH 3/3] phy: sun4i-usb: Support VBUS detection via power supply
On Sun, 12 Sep 2021 09:22:42 -0500
Samuel Holland wrote:
> The device tree binding provides for getting VBUS state from a device
> referenced by phandle, as an optional alternative to using a GPIO. In
> U-Boot, where there is no power supply class, this VBUS detection will
> be implemented using a regulator device and its get_enable method.
> Let's hook this up to the PHY driver.
>
> Signed-off-by: Samuel Holland
Looks good, but curious if that works on all those boards ...
Acked-by: Andre Przywara
Cheers,
Andre
> ---
>
> drivers/phy/allwinner/Kconfig | 1 +
> drivers/phy/allwinner/phy-sun4i-usb.c | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig
> index dba3bae61c4..aa9d0e7e6a5 100644
> --- a/drivers/phy/allwinner/Kconfig
> +++ b/drivers/phy/allwinner/Kconfig
> @@ -4,6 +4,7 @@
> config PHY_SUN4I_USB
> bool "Allwinner Sun4I USB PHY driver"
> depends on ARCH_SUNXI
> + select DM_REGULATOR
> select PHY
> help
> Enable this to support the transceiver that is part of Allwinner
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 827ecd70f27..ab2a5d17fcf 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #define REG_ISCR 0x00
> #define REG_PHYCTL_A10 0x04
> @@ -137,6 +138,7 @@ struct sun4i_usb_phy_data {
> void __iomem *base;
> const struct sun4i_usb_phy_cfg *cfg;
> struct sun4i_usb_phy_plat *usb_phy;
> + struct udevice *vbus_power_supply;
> };
>
> static int initial_usb_scan_delay = CONFIG_INITIAL_USB_SCAN_DELAY;
> @@ -404,6 +406,8 @@ int sun4i_usb_phy_vbus_detect(struct phy *phy)
> mdelay(100);
> err = gpio_get_value(usb_phy->gpio_vbus_det);
> }
> + } else if (data->vbus_power_supply) {
> + err = regulator_get_enable(data->vbus_power_supply);
> }
>
> return err;
> @@ -447,6 +451,9 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
> if (IS_ERR(data->base))
> return PTR_ERR(data->base);
>
> + device_get_supply_regulator(dev, "usb0_vbus_power-supply",
> + >vbus_power_supply);
> +
> data->usb_phy = plat;
> for (i = 0; i < data->cfg->num_phys; i++) {
> struct sun4i_usb_phy_plat *phy = [i];
Re: [PATCH] sunxi: A23/A33/H3: Actually move the secure monitor
On Tue, 12 Oct 2021 18:54:56 -0500
Samuel Holland wrote:
> commit 1ebfc0c631e3 ("sunxi: A23/A33/H3: Move sun8i secure monitor to
> SRAM A2") attempted to move the secure monitor to SRAM A2. But not all
> sun8i SoCs have SRAM A2, so a check was put in for SUNXI_SRAM_A2_SIZE to
> avoid breaking the other SoCs.
>
> However, because the header providing SUNXI_SRAM_A2_SIZE was not
> included, this unintentionally skipped the new definitions on all SoCs.
> Fix this by including the right header.
>
> Fixes: 1ebfc0c631e3 ("sunxi: A23/A33/H3: Move sun8i secure monitor to SRAM
> A2")
> Signed-off-by: Samuel Holland
Indeed. Weird, I thought I checked the readelf output.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> include/configs/sun8i.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
> index 27c9808a49..5636356366 100644
> --- a/include/configs/sun8i.h
> +++ b/include/configs/sun8i.h
> @@ -12,6 +12,8 @@
> * A23 specific configuration
> */
>
> +#include
> +
> #ifdef SUNXI_SRAM_A2_SIZE
> /*
> * If the SoC has enough SRAM A2, use that for the secure monitor.
Re: [PATCH] clk: sunxi: Extend DM_RESET selection to SPL
On Sat, 11 Sep 2021 14:45:31 -0500 Samuel Holland wrote: > The sunxi clock driver exposes a reset controller, so it selects the > reset controller framework. Ensure that dependency is also satisfied > when building the driver for the SPL. > > Signed-off-by: Samuel Holland Reviewed-by: Andre Przywara Cheers, Andre > --- > > drivers/clk/sunxi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig > index bf084fa7a84..43c321692cf 100644 > --- a/drivers/clk/sunxi/Kconfig > +++ b/drivers/clk/sunxi/Kconfig > @@ -2,6 +2,7 @@ config CLK_SUNXI > bool "Clock support for Allwinner SoCs" > depends on CLK && ARCH_SUNXI > select DM_RESET > + select SPL_DM_RESET if SPL_CLK > default y > help > This enables support for common clock driver API on Allwinner
[PATCH] Avoid possible NULL dereference in XHCI driver
In the recovery function abort_td run after timed out XHCI transfers, there's a possible NULL pointer dereference. Instead, explicitly BUG_ON that condition. Signed-off-by: Jim Posen --- drivers/usb/host/xhci-ring.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 35bd5cd29e..1635d03ece 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -499,6 +499,7 @@ static void abort_td(struct usb_device *udev, int ep_index) xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); event = xhci_wait_for_event(ctrl, TRB_TRANSFER); + BUG_ON(!event); field = le32_to_cpu(event->trans_event.flags); BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id); BUG_ON(TRB_TO_EP_INDEX(field) != ep_index); -- 2.25.1
Re: [PATCH] ppc: mpc8xx: Drop -mstring from PLATFORM_CPPFLAGS
On 04/10/2021 20.01, Tom Rini wrote: This has not been supported by toolchains for some time and has been putting out a warning. Drop this. Signed-off-by: Tom Rini --- arch/powerpc/cpu/mpc8xx/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc8xx/config.mk b/arch/powerpc/cpu/mpc8xx/config.mk index 00b7ed50a9d3..5a64665a6180 100644 --- a/arch/powerpc/cpu/mpc8xx/config.mk +++ b/arch/powerpc/cpu/mpc8xx/config.mk @@ -3,4 +3,4 @@ # (C) Copyright 2000-2010 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -PLATFORM_CPPFLAGS += -mstring -mcpu=860 -msoft-float +PLATFORM_CPPFLAGS += -mcpu=860 -msoft-float Reviewed-by: Thomas Huth
[PATCH] doc: Remove the obsolete README.mpc74xx file
Support for the PPC74xx processors has been removed in commit
d928664f41 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
more than 6 years ago already. So the corresponding README file
can now be removed, too.
Signed-off-by: Thomas Huth
---
doc/README.mpc74xx | 22 --
1 file changed, 22 deletions(-)
delete mode 100644 doc/README.mpc74xx
diff --git a/doc/README.mpc74xx b/doc/README.mpc74xx
deleted file mode 100644
index f81f1c2e89..00
--- a/doc/README.mpc74xx
+++ /dev/null
@@ -1,22 +0,0 @@
-This file contains status information for the port of U-Boot to the
-Motorola mpc74xx series of CPUs.
-
-Author: Josh Huber
- Mission Critical Linux, Inc.
-
-Currently the support for these CPUs is pretty minimal, but enough to
-get things going. (much like the support for the Galileo Eval Board)
-
-There is a framework in place to enable the L2 cache, and to program
-the BATs. Currently, there are still problems with the code which
-sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be
-anyway). Additionally, there is support for enabling the MMU, which
-we also don't do. The BATs are programmed just for the benefit of
-jumping into Linux in a sane configuration.
-
-Most of the code was based on other cpus supported by U-Boot.
-
-If you find any errors in the CPU setup code, please send us a note.
-
-Thanks,
-Josh
--
2.27.0
[PATCH u-boot-marvell 00/13] Yet another kwboot improvements
From: Marek Behún Hello Stefan, these are another improvements for kwboot, please apply only after series arm: mvebu: nandpagesize support for kwbimage v1 The main improvement is in patch 5, which changes where we inject the code for changing baudrate back to 115200 Baud after fast upload. Instead of injecting it before the main data image, we now inject it after. This is because there are some kwb images that upload at address 0, and injecting the code before that doesn't work, since there is no RAM mapped at 0xf000. Marek & Pali Pali Rohár (13): tools: kwboot: Initialize rfds to zero tools: kwboot: Fix initialization of tty device tools: kwboot: Reserve enough space for patching kwbimage in memory tools: kwboot: Validate 4-byte image data checksum tools: kwboot: Inject baudrate change back code after data part tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code tools: kwboot: Correctly set configuration of UART for BootROM messages tools: kwboot: Show verbose message when waiting for baudrate change magic tools: kwboot: Simplify code for aligning image header tools: kwboot: Do not modify kwbimage header before increasing its size tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr() tools: kwboot: Change retry loop from decreasing to increasing tools: kwboot: Resend first 3 xmodem retry packets immediately tools/kwboot.c | 178 + 1 file changed, 120 insertions(+), 58 deletions(-) -- 2.32.0
[PATCH u-boot-marvell 02/13] tools: kwboot: Fix initialization of tty device
From: Pali Rohár Explicitly disable 2 stop bits by clearing CSTOPB flag, disable modem control flow by clearing CRTSCTS flag and do not send hangup after closing device by clearing HUPCL flag. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- tools/kwboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index 695d433b96..c55b41025b 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -657,6 +657,7 @@ kwboot_open_tty(const char *path, int baudrate) cfmakeraw(); tio.c_cflag |= CREAD | CLOCAL; + tio.c_cflag &= ~(CSTOPB | HUPCL | CRTSCTS); tio.c_cc[VMIN] = 1; tio.c_cc[VTIME] = 0; -- 2.32.0
Re: [PATCH v2 2/3] arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote: > > Enable sdhci and sdmmc0 node in rk3568-u-boot.dtsi > > Signed-off-by: Nico Cheng Reviewed-by: Philipp Tomsich
[PATCH u-boot-marvell 04/13] tools: kwboot: Validate 4-byte image data checksum
From: Pali Rohár
Data part of the image contains 4-byte checksum. Validate it when
processing the image.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 4e29317f10..bc44301535 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1251,6 +1251,37 @@ kwboot_hdr_csum8(const void *hdr)
return csum;
}
+static uint32_t *
+kwboot_img_csum32_ptr(void *img)
+{
+ struct main_hdr_v1 *hdr = img;
+ uint32_t datasz;
+
+ datasz = le32_to_cpu(hdr->blocksize) - sizeof(uint32_t);
+
+ return img + le32_to_cpu(hdr->srcaddr) + datasz;
+}
+
+static uint32_t
+kwboot_img_csum32(const void *img)
+{
+ const struct main_hdr_v1 *hdr = img;
+ uint32_t datasz, csum = 0;
+ const uint32_t *data;
+
+ datasz = le32_to_cpu(hdr->blocksize) - sizeof(csum);
+ if (datasz % sizeof(uint32_t))
+ return 0;
+
+ data = img + le32_to_cpu(hdr->srcaddr);
+ while (datasz > 0) {
+ csum += le32_to_cpu(*data++);
+ datasz -= 4;
+ }
+
+ return cpu_to_le32(csum);
+}
+
static int
kwboot_img_is_secure(void *img)
{
@@ -1462,6 +1493,9 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
goto err;
+ if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img))
+ goto err;
+
is_secure = kwboot_img_is_secure(img);
if (hdr->blockid != IBR_HDR_UART_ID) {
--
2.32.0
[PATCH u-boot-marvell 05/13] tools: kwboot: Inject baudrate change back code after data part
From: Pali Rohár
Some vendor U-Boot kwbimage binaries (e.g. those for A375) have load
address set to zero. Therefore it is not possible to inject code which
changes baudrate back to 115200 Bd before the data part.
So instead inject it after the data part and change kwbimage execution
address to that offset. Also store original execution address into
baudrate change code, so after it changes baudrate back to 115200 Bd, it
can jump to orignal address.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 72 ++
1 file changed, 31 insertions(+), 41 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index bc44301535..bf26a667b7 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1295,34 +1295,22 @@ kwboot_img_is_secure(void *img)
}
static void *
-kwboot_img_grow_data_left(void *img, size_t *size, size_t grow)
+kwboot_img_grow_data_right(void *img, size_t *size, size_t grow)
{
- uint32_t hdrsz, datasz, srcaddr;
struct main_hdr_v1 *hdr = img;
- uint8_t *data;
-
- srcaddr = le32_to_cpu(hdr->srcaddr);
-
- hdrsz = kwbheader_size(hdr);
- data = (uint8_t *)img + srcaddr;
- datasz = *size - srcaddr;
-
- /* only move data if there is not enough space */
- if (hdrsz + grow > srcaddr) {
- size_t need = hdrsz + grow - srcaddr;
-
- /* move data by enough bytes */
- memmove(data + need, data, datasz);
- *size += need;
- srcaddr += need;
- }
+ void *result;
- srcaddr -= grow;
- hdr->srcaddr = cpu_to_le32(srcaddr);
- hdr->destaddr = cpu_to_le32(le32_to_cpu(hdr->destaddr) - grow);
+ /*
+* 32-bit checksum comes after end of image code, so we will be putting
+* new code there. So we get this pointer and then increase data size
+* (since increasing data size changes kwboot_img_csum32_ptr() return
+* value).
+*/
+ result = kwboot_img_csum32_ptr(img);
hdr->blocksize = cpu_to_le32(le32_to_cpu(hdr->blocksize) + grow);
+ *size += grow;
- return (uint8_t *)img + srcaddr;
+ return result;
}
static void
@@ -1400,14 +1388,20 @@ kwboot_add_bin_ohdr_v1(void *img, size_t *size,
uint32_t binsz)
}
static void
-_copy_baudrate_change_code(struct main_hdr_v1 *hdr, void *dst, int pre,
- int old_baud, int new_baud)
+_inject_baudrate_change_code(void *img, size_t *size, int pre,
+int old_baud, int new_baud)
{
- size_t codesz = sizeof(kwboot_baud_code);
- uint8_t *code = dst;
+ uint32_t codesz = sizeof(kwboot_baud_code);
+ struct main_hdr_v1 *hdr = img;
+ uint8_t *code;
if (pre) {
- size_t presz = sizeof(kwboot_pre_baud_code);
+ uint32_t presz = sizeof(kwboot_pre_baud_code);
+ uint32_t orig_datasz;
+
+ orig_datasz = le32_to_cpu(hdr->blocksize) - sizeof(uint32_t);
+
+ code = kwboot_img_grow_data_right(img, size, presz + codesz);
/*
* We need to prepend code that loads lr register with original
@@ -1421,9 +1415,12 @@ _copy_baudrate_change_code(struct main_hdr_v1 *hdr, void
*dst, int pre,
memcpy(code, kwboot_pre_baud_code, presz);
*(uint32_t *)code = hdr->execaddr;
- hdr->execaddr = cpu_to_le32(le32_to_cpu(hdr->destaddr) + 4);
+ hdr->execaddr = cpu_to_le32(le32_to_cpu(hdr->destaddr) +
+ orig_datasz + 4);
code += presz;
+ } else {
+ code = kwboot_add_bin_ohdr_v1(img, size, codesz);
}
memcpy(code, kwboot_baud_code, codesz - 8);
@@ -1516,9 +1513,6 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
}
if (baudrate) {
- uint32_t codesz = sizeof(kwboot_baud_code);
- void *code;
-
if (image_ver == 0) {
fprintf(stderr,
"Cannot inject code for changing baudrate into
v0 image header\n");
@@ -1539,20 +1533,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
*/
kwboot_printv("Injecting binary header code for changing
baudrate to %d Bd\n",
baudrate);
-
- code = kwboot_add_bin_ohdr_v1(img, size, codesz);
- _copy_baudrate_change_code(hdr, code, 0, 115200, baudrate);
+ _inject_baudrate_change_code(img, size, 0, 115200, baudrate);
/*
* Now inject code that changes the baudrate back to 115200 Bd.
-* This code is prepended to the data part of the image, so it
-* is executed before U-Boot proper.
+* This code is appended after the data part of the image,
[PATCH u-boot-marvell 06/13] tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code
From: Pali Rohár
If data part of image is modified, update 4-byte data checksum.
It looks like A385 BootROM does not verify this checksum for image
loaded via UART, but we do not know if other BootROMs are also ignoring
it. It is always better to provide correct checksum.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index bf26a667b7..1131c2eb1c 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1544,6 +1544,9 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Injecting code for changing baudrate back\n");
_inject_baudrate_change_code(img, size, 1, baudrate, 115200);
+ /* Update the 32-bit data checksum */
+ *kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img);
+
/* recompute header size */
hdrsz = kwbheader_size(hdr);
}
--
2.32.0
[PATCH u-boot-marvell 03/13] tools: kwboot: Reserve enough space for patching kwbimage in memory
From: Pali Rohár
SPI image header and data parts do not have to be aligned to 128 byte
xmodem block size. So reserve additional memory for aligning header part
and additional memory for aligning data part.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index c55b41025b..4e29317f10 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1672,8 +1672,10 @@ main(int argc, char **argv)
else
/* ensure we have enough space for baudrate change code */
after_img_rsv += KWBOOT_BAUDRATE_BIN_HEADER_SZ +
+KWBOOT_XM_BLKSZ +
sizeof(kwboot_pre_baud_code) +
-sizeof(kwboot_baud_code);
+sizeof(kwboot_baud_code) +
+KWBOOT_XM_BLKSZ;
if (imgpath) {
img = kwboot_read_image(imgpath, , after_img_rsv);
--
2.32.0
[PATCH u-boot-marvell 01/13] tools: kwboot: Initialize rfds to zero
From: Pali Rohár Explicitly zero out the rfds fd_set with FD_ZERO() before using it. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- tools/kwboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index 7e1be29623..695d433b96 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -1151,6 +1151,7 @@ kwboot_terminal(int tty) fd_set rfds; int nfds = 0; + FD_ZERO(); FD_SET(tty, ); nfds = nfds < tty ? tty : nfds; -- 2.32.0
Pull request: u-boot-imx u-boot-imx-20211022
Hi Tom, please pull from u-boot-imx, thanks ! The following changes since commit 79b8849d4c1e73df2a79a1d5a5f6166d0dd67a12: Merge tag 'u-boot-imx-20211020' of https://source.denx.de/u-boot/custodians/u-boot-imx (2021-10-20 14:24:09 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20211022 for you to fetch changes up to 56ced770999bd14cd940e07239f4197852460142: tools: imx8m_image: Support ddr3 firmware (2021-10-21 13:59:26 +0200) u-boot-imx-20211022 --- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9561 - i.MX8: - Toradex Verdin (switch to binman, cleanup, etc.) - Phytec phycore_imx8mm (fixes, boot from SPI-NOR) - fixes for imx8mp_evk - doc (i.MX): MX8MM with Fast boot - i.MX6: - Toradex : colibri-imx6ull with eMMC, fixes - i.MX7ULP : - preparation for OPTEE + Serial Number - generic: - imx8m_image: Support ddr3 firmware Ariel D'Alessandro (1): tools: imx8m_image: Support ddr3 firmware Denys Drozdov (1): toradex: configblock: fix interactive mode it handling Fabio Estevam (1): imx8mm-evk: Generate a single bootable flash.bin again Igor Opaniuk (1): verdin-imx8mm: use preboot for fdtfile evaluation Marcel Ziswiler (9): imx8m: clean-up kconfig indentation verdin-imx8mm: fix ethernet ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation arm64: dts: imx8mm-verdin-u-boot.dtsi: alphabetically re-order verdin-imx8mm: switch to use binman to pack images verdin-imx8mm: clean-up include order verdin-imx8mm: fix watchdog pinctrl issue toradex: take over maintainership toradex: tdx-cfg-block: add new i.mx 6ull and 8m plus skus Marek Vasut (2): doc: imx: psb: Fix PERSIST_SECONDARY_BOOT bit location in GPR10 doc: imx: psb: Add documentation for MX8MM behavior with Fast Boot fuse blown Max Krummenacher (3): verdin-imx8mm: enable sleep_moci output verdin-imx8mm: drop support for v1.0 hardware colibri-imx6ull: add emmc variant Oleksandr Suvorov (1): include/configs: apalis-imx8/verdin-imx8mm: rename kernel image variable Philippe Schenker (2): colibri-imx6ull: fix setup of nand gpmi clock colibri-imx6ull: imximage.cfg: integrate new 1GiB RAM variant Ricardo Salveti (2): board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE mx7ulp: add getting a board serial number Stefano Babic (1): Merge branch 'master' of git://git.denx.de/u-boot Teresa Remmet (9): board: phytec: phycore_imx8mm: Clean up spl include: configs: phycore_imx8mm: Remove hard coded network settings include: configs: phycore-imx8mm: Remove not needed defines include: configs: phycore-imx8mm: Do not use macro for address arm: dts: phycore-imx8mm-u-boot: Add wdog pinctrl entry arm: dts: phycore-imx8mm: Fix property board: phytec: phycore-imx8mm: Add SPI-NOR flash support configs: phycore-imx8mm_defconfig: Enable clk command board: phytec: imx8mm-phycore: Switch to binman Ye Li (8): arm: mach-imx: Update MAC fuse for i.MX8MP arm: mach-imx: Allow to build mac.c for EQoS driver arm: dts: imx8mp-evk: Enable the EQoS ethernet port imx8mp_evk: Fix incorrect cascade for FEC and EQOS setup imx8mp_evk: Remove EQoS PHY reset codes imx8mp_evk: Delete noncached memory config imx8mp_evk: Enable the DWC EQoS iMX driver arm: dts: imx8mp: Delete default clocks for clock controller node arch/arm/dts/Makefile | 1 + arch/arm/dts/imx6ull-colibri-emmc.dts | 49 + arch/arm/dts/imx6ull-colibri.dts | 34 +- arch/arm/dts/imx6ull-colibri.dtsi | 32 +--- arch/arm/dts/imx8mm-evk-u-boot.dtsi| 19 ++- arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 147 --- arch/arm/dts/imx8mm-verdin.dts | 18 ++ arch/arm/dts/imx8mp-evk-u-boot.dtsi| 13 + arch/arm/dts/imx8mp-evk.dts| 40 arch/arm/dts/imx8mp-u-boot.dtsi| 3 +++ arch/arm/dts/phycore-imx8mm-u-boot.dtsi| 126 ++ arch/arm/dts/phycore-imx8mm.dts| 30 +-
Re: [PATCH v2 2/2] cmd: brcm: netXtreme commands
On Fri, 22 Oct 2021 16:23:33 -0700 Roman Bacik wrote: > From: Bharat Gooty > > Following netXtreme commands are supported:- > Device probe, remove, supported speeds, get/set speeds and > get/set MAC address. NAK. - "bnxt get mac U-Boot uses the ethaddr and ethNaddr environment variables for MAC addresses. You don't need a new custom command for that when there is a generic mechanism for this. - " probe" / " remove" You also shouldn't need a command for driver probe / remove. DM should probe your driver automatically. And if you need it for debugging, please add such subcommand to the dm command. - "bnxt get supported_speed" "bnxt get link_speed" These should be available via the mdio command when you register your PHY driver via appropriate API. Marek
Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
Hi Tom, please pull the second sunxi PR for the 2021.10 merge window. I decided to merge most of Samuel's rework and some smaller patches that pave the way for more DM transitions and for accommodating the RISC-V SoC in the future. Merging them now gives us the opportunity to get some wider testing, since those subtle changes tend to break things. Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS and OrangePi Zero. Summary: - Add and enable watchdog driver - Prepare for SYSRESET driven AXP poweroff - Prepare for SoCs without MMC2 - Some fixes for extending SPL (SPL-DM for RISC-V) - Some preparations for proper VBUS management - Fix secure monitor move Thanks, Andre The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c: Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23 10:49:28 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d: mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25 14:54:57 +0100) Andre Przywara (1): sunxi: SPL SPI: Allow larger SPL Icenowy Zheng (2): sunxi: only include alias for eMMC when mmc2 used mmc: sunxi: conditionally include MMC2 initialization code Samuel Holland (14): sunxi: Select SPL_SEPARATE_BSS phy: sun4i-usb: Remove a couple of debug messages phy: sun4i-usb: Refactor VBUS detection to match Linux phy: sun4i-usb: Support VBUS detection via power supply sunxi: A23/A33/H3: Actually move the secure monitor tools: mksunxiboot: Use sunxi_image header directly include: axp_pmic: Add missing header guard definition include: axp_pmic: Include headers for all variants power: axp: Avoid do_poweroff conflict with sysreset power: pmic: axp: Implement poweroff via sysreset clk: sunxi: Extend DM_RESET selection to SPL watchdog: Add a driver for the sunxi watchdog sunxi: Enable watchdog timer support by default sunxi: dts: H616: Enable the watchdog arch/arm/Kconfig | 2 + arch/arm/dts/sun50i-h616.dtsi | 1 - arch/arm/dts/sunxi-u-boot.dtsi| 2 + arch/arm/mach-sunxi/spl_spi_sunxi.c | 10 +- drivers/clk/sunxi/Kconfig | 1 + drivers/mmc/sunxi_mmc.c | 2 + drivers/phy/allwinner/Kconfig | 1 + drivers/phy/allwinner/phy-sun4i-usb.c | 34 +++--- drivers/power/axp152.c| 2 + drivers/power/axp209.c| 2 + drivers/power/axp221.c| 2 + drivers/power/axp305.c| 2 +- drivers/power/axp809.c| 2 + drivers/power/axp818.c| 2 + drivers/power/pmic/Kconfig| 2 + drivers/power/pmic/axp.c | 49 - drivers/watchdog/Kconfig | 8 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sunxi_wdt.c | 188 ++ include/axp152.h | 2 + include/axp209.h | 2 + include/axp221.h | 2 + include/axp809.h | 2 + include/axp818.h | 2 + include/axp_pmic.h| 13 +-- include/configs/sun8i.h | 2 + tools/mksunxiboot.c | 2 +- 27 files changed, 305 insertions(+), 35 deletions(-) create mode 100644 drivers/watchdog/sunxi_wdt.c
Re: [PATCH] sunxi: Select SPL_SEPARATE_BSS
On Sun, 22 Aug 2021 13:23:53 -0500 Samuel Holland wrote: > sunxi-common.h defines CONFIG_SPL_BSS_START_ADDR to put SPL's BSS in > DRAM. Due to this, we must select SPL_SEPARATE_BSS, or else SPL will > attempt to load its DTB from the wrong address (after BSS in DRAM). > > This change fixes booting with SPL_OF_CONTROL=y. > > Signed-off-by: Samuel Holland Makes sense, although I think we don't use that atm? Anyway: Reviewed-by: Andre Przywara Cheers, Andre > --- > > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index d692139199c..67011208a00 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1008,6 +1008,7 @@ config ARCH_SUNXI > select OF_CONTROL > select OF_SEPARATE > select SPECIFY_CONSOLE_INDEX > + select SPL_SEPARATE_BSS if SPL > select SPL_STACK_R if SPL > select SPL_SYS_MALLOC_SIMPLE if SPL > select SPL_SYS_THUMB_BUILD if !ARM64
Re: [PATCH v4 05/11] tools: mkeficapsule: add firmwware image signing
Hi Sughosh, 2021年10月25日(月) 18:59 Sughosh Ganu : > > hi Masami, > > On Mon, 25 Oct 2021 at 11:10, Masami Hiramatsu > wrote: >> >> Hi Takahiro, >> >> 2021年10月25日(月) 12:12 AKASHI Takahiro : >> > >> > Hi, Masami, >> > >> > On Wed, Oct 20, 2021 at 05:17:12PM +0900, Masami Hiramatsu wrote: >> > > Hello Akashi-san, >> > > >> > > Can you split this patch out from this series? >> > > It seems that the series is doing several different things. This >> > > capsule signing has no alternatives, but others are modifying or >> > > replacing the current existing feature. In other words, this capsule >> > > signing feature has no alternatives, but others we can continue to >> > > use. >> > >> > What do you specifically mean by "existing feature" or "others we can >> > continue to use"? >> > >> > All the commits, I think, in this series are closely related with >> > each other. >> >> I meant I can use the devicetree to embed the authentication key in the >> U-Boot itself (currently U-Boot expects that.) Or is there any issue with >> putting the key in the devicetree? >> >> Without this patch, I can not sign the capsule file for U-Boot, since >> the GenerateCapsule in EDK2 supports old format (is that updated?) > > > If you are referring to using Version 3 of the FMP Image Header structure, > yes this has been upstreamed in EDK2. You can rebase and use the current > GenerateCapsule script. Thanks. Good information! Thank you for update me :) > > -sughosh > >> >> >> Thank you, >> >> >> > >> > -Takahiro Akashi >> > >> > > Thank you, >> > > >> > > 2021年10月7日(木) 15:25 AKASHI Takahiro : >> > > > >> > > > With this enhancement, mkeficapsule will be able to sign a capsule >> > > > file when it is created. A signature added will be used later >> > > > in the verification at FMP's SetImage() call. >> > > > >> > > > To do that, We need specify additional command parameters: >> > > > -monotonic-cout : monotonic count >> > > > -private-key : private key file >> > > > -certificate : certificate file >> > > > Only when all of those parameters are given, a signature will be added >> > > > to a capsule file. >> > > > >> > > > Users are expected to maintain and increment the monotonic count at >> > > > every time of the update for each firmware image. >> > > > >> > > > Signed-off-by: AKASHI Takahiro >> > > > --- >> > > > tools/Kconfig| 7 + >> > > > tools/Makefile | 8 +- >> > > > tools/mkeficapsule.c | 435 +++ >> > > > 3 files changed, 416 insertions(+), 34 deletions(-) >> > > > >> > > > diff --git a/tools/Kconfig b/tools/Kconfig >> > > > index d6f82cd949b5..9a37ed035311 100644 >> > > > --- a/tools/Kconfig >> > > > +++ b/tools/Kconfig >> > > > @@ -20,4 +20,11 @@ config TOOLS_LIBCRYPTO >> > > > This selection does not affect target features, such as >> > > > runtime FIT >> > > > signature verification. >> > > > >> > > > +config TOOLS_MKEFICAPSULE >> > > > + bool "Build efimkcapsule command" >> > > > + default y if EFI_CAPSULE_ON_DISK >> > > > + help >> > > > + This command allows users to create a UEFI capsule file and, >> > > > + optionally sign that file. If you want to enable UEFI capsule >> > > > + update feature on your target, you certainly need this. >> > > > endmenu >> > > > diff --git a/tools/Makefile b/tools/Makefile >> > > > index 4a86321f6467..6ea3033dbfb8 100644 >> > > > --- a/tools/Makefile >> > > > +++ b/tools/Makefile >> > > > @@ -237,8 +237,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs >> > > > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler >> > > > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include >> > > > >> > > > -mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS) >> > > > -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule >> > > > +HOSTLDLIBS_mkeficapsule += -luuid >> > > > +ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y) >> > > > +HOSTLDLIBS_mkeficapsule += \ >> > > > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || >> > > > echo "-lssl -lcrypto") >> > > > +endif >> > > > +hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule >> > > > >> > > > # We build some files with extra pedantic flags to try to minimize >> > > > things >> > > > # that won't build on some weird host compiler -- though there are >> > > > lots of >> > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c >> > > > index 4995ba4e0c2a..5541e4bda894 100644 >> > > > --- a/tools/mkeficapsule.c >> > > > +++ b/tools/mkeficapsule.c >> > > > @@ -15,6 +15,16 @@ >> > > > #include >> > > > #include >> > > > >> > > > +#include >> > > > +#ifdef CONFIG_TOOLS_LIBCRYPTO >> > > > +#include >> > > > +#include >> > > > +#include >> > > > +#include >> > > > +#include >> > > > +#include >> > > > +#endif >> > > > + >> > > > typedef __u8 u8; >> > > > typedef __u16 u16; >> > > > typedef __u32 u32; >> > > > @@ -38,12 +48,25 @@ efi_guid_t efi_guid_image_type_uboot_fit =
Re: [PATCH v2 3/3] rockchip: rk3568: add arch_cpu_init()
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote:
>
> We configured the drive strength and security of EMMC in
> arch_cpu_init().
>
> Signed-off-by: Nico Cheng
> ---
>
> Changes in v2:
> We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to
> secure.
> Modify comments to make them more explicit.
>
> arch/arm/mach-rockchip/rk3568/rk3568.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> b/arch/arm/mach-rockchip/rk3568/rk3568.c
> index 973b4f9dcb..1a62052731 100644
> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> @@ -13,6 +13,14 @@
>
> #define PMUGRF_BASE0xfdc2
> #define GRF_BASE 0xfdc6
> +#define GRF_GPIO1B_DS_20x218
> +#define GRF_GPIO1B_DS_30x21c
> +#define GRF_GPIO1C_DS_00x220
> +#define GRF_GPIO1C_DS_10x224
> +#define GRF_GPIO1C_DS_20x228
> +#define GRF_GPIO1C_DS_30x22c
> +#define SGRF_BASE 0xFDD18000
> +#define SGRF_SOC_CON4 0x10
>
> /* PMU_GRF_GPIO0D_IOMUX_L */
> enum {
> @@ -81,5 +89,16 @@ void board_debug_uart_init(void)
>
> int arch_cpu_init(void)
> {
> +#ifdef CONFIG_SPL_BUILD
> + /* Set the emmc sdmmc0 to secure */
> + rk_clrreg(SGRF_BASE + SGRF_SOC_CON4, (0x3 << 11 | 0x1 << 4));
Please introduce symbolic constants (or at least a C99 'const'
expressions with a suitable names) to clarify what bits[12:11]
and bit[4] control?
> + /* set the emmc driver strength to level 2 */
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_3);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_0);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_1);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_3);
> +#endif
> return 0;
> }
> --
> 2.17.1
>
>
>
Re: [PATCH v2 1/2] net: brcm: netXtreme driver
NAK for this driver.
- display_banner() spams the output unnecessarily, the information
should be printed with debug()
- you are introducing custom mechanism for setting / getting PHY
parameters, via custom specific env variables, for example in the
set_phy_speed() and set_phy_link() functions, i.e.:
sprintf(name1, "bnxt_eth%u_phy_speed", bp->cardnum);
env_set(name1, name);
The whole point of several people in the past few years was to create
generic mechanisms for such things. We have ethernet PHY DM class,
you should use this. That way you won't need to introduce custom
mechanisms to get the infromation, since there are mii/mdio commands.
- print_mac() - the driver shouldn't even have this function, it should
just set appropriate ethNaddr variable
- in bnxt_eth_probe() you are looking at the variable "ethaddr":
if (env_get("ethaddr"))
secondary = 1;
a driver should never look itself at this variable.
Since your driver should be of UCLASS_ETH, the generic mechanism
should use appropriate env variable by calling you .write_hwaddr
method
Basically you are going against all the points of the whole idea to
have a generic API to set network driver parameters, and instead you
are adding driver-specific custom mechanisms.
Please change that in next version.
Marek
Re: [PATCH 1/3] phy: sun4i-usb: Remove a couple of debug messages
On Sun, 12 Sep 2021 09:22:40 -0500
Samuel Holland wrote:
> Both of these messages log the GPIO number of the ID detection GPIO,
> which is not terribly useful, especially in the VBUS detection function.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> drivers/phy/allwinner/phy-sun4i-usb.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 82713b83815..5302b809ee6 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -393,8 +393,6 @@ int sun4i_usb_phy_vbus_detect(struct phy *phy)
> struct sun4i_usb_phy_plat *usb_phy = >usb_phy[phy->id];
> int err, retries = 3;
>
> - debug("%s: id_det = %d\n", __func__, usb_phy->gpio_id_det);
> -
> if (usb_phy->gpio_vbus_det < 0)
> return usb_phy->gpio_vbus_det;
>
> @@ -417,8 +415,6 @@ int sun4i_usb_phy_id_detect(struct phy *phy)
> struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
> struct sun4i_usb_phy_plat *usb_phy = >usb_phy[phy->id];
>
> - debug("%s: id_det = %d\n", __func__, usb_phy->gpio_id_det);
> -
> if (usb_phy->gpio_id_det < 0)
> return usb_phy->gpio_id_det;
>
Re: [PATCH] arm64: relocate-rela: Add support for ld.lld
On Wed, Oct 20, 2021 at 09:31:32PM +, Alistair Delva wrote: > Cap end of relocations by the binary size. > > Linkers like to insert some auxiliary sections between .rela.dyn and > .bss_start. These sections don't make their way to the final binary, but > reloc_rela still tries to relocate them, resulting in attempted read > past the end of file. > > When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by > default on arm64) breaks the build. After this patch, U-Boot can be > linked successfully with and without CONFIG_STATIC_RELA. > > Originally-from: Elena Petrova > Signed-off-by: Alistair Delva > Cc: David Brazdil > Cc: Scott Wood > Cc: Tom Rini Thanks for the patch. Do you have any other changes for LLVM/LLDB support on arm64 platforms? I think I've had a few stumbles whenever I've tried and not been able to cycle back to them. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/4] power: pmic: axp: Implement poweroff via sysreset
On Sun, 24 Oct 2021 21:00:10 -0500
Samuel Holland wrote:
> The AXP PMICs have the ability to power off the system. The existing
> code for this is duplicated for each PMIC variant, and uses the legacy
> non-DM "pmic_bus" interface. When SYSRESET is enabled, this can all be
> replaced with a sysreset device using the DM_PMIC interface.
>
> Since the trigger bit is the same on all PMIC variants, use the register
> definitions from the oldest supported PMIC.
>
> Signed-off-by: Samuel Holland
Thanks for the quick turnaround!
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> Changes in v2:
> - Rebased on top of u-boot/master (axp_pmic_bind)
>
> drivers/power/pmic/Kconfig | 2 ++
> drivers/power/pmic/axp.c | 49 +-
> 2 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 92e2ace279..b9fda428df 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -66,6 +66,8 @@ config PMIC_ACT8846
> config PMIC_AXP
> bool "Enable Driver Model for X-Powers AXP PMICs"
> depends on DM_I2C
> + select SYSRESET_CMD_POWEROFF if SYSRESET && CMD_POWEROFF
> + imply CMD_POWEROFF if SYSRESET
> help
> This config enables driver-model PMIC uclass features for
> X-Powers AXP152, AXP2xx, and AXP8xx PMICs.
> diff --git a/drivers/power/pmic/axp.c b/drivers/power/pmic/axp.c
> index 74c94bdb47..0f2b24a8b5 100644
> --- a/drivers/power/pmic/axp.c
> +++ b/drivers/power/pmic/axp.c
> @@ -1,8 +1,37 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> +#include
> #include
> +#include
> #include
> #include
> +#include
> +
> +#if CONFIG_IS_ENABLED(SYSRESET)
> +static int axp_sysreset_request(struct udevice *dev, enum sysreset_t type)
> +{
> + int ret;
> +
> + if (type != SYSRESET_POWER_OFF)
> + return -EPROTONOSUPPORT;
> +
> + ret = pmic_clrsetbits(dev->parent, AXP152_SHUTDOWN, 0, AXP152_POWEROFF);
> + if (ret < 0)
> + return ret;
> +
> + return -EINPROGRESS;
> +}
> +
> +static struct sysreset_ops axp_sysreset_ops = {
> + .request= axp_sysreset_request,
> +};
> +
> +U_BOOT_DRIVER(axp_sysreset) = {
> + .name = "axp_sysreset",
> + .id = UCLASS_SYSRESET,
> + .ops= _sysreset_ops,
> +};
> +#endif
>
> static int axp_pmic_reg_count(struct udevice *dev)
> {
> @@ -16,6 +45,24 @@ static struct dm_pmic_ops axp_pmic_ops = {
> .write = dm_i2c_write,
> };
>
> +static int axp_pmic_bind(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = dm_scan_fdt_dev(dev);
> + if (ret)
> + return ret;
> +
> + if (CONFIG_IS_ENABLED(SYSRESET)) {
> + ret = device_bind_driver_to_node(dev, "axp_sysreset",
> "axp_sysreset",
> + dev_ofnode(dev), NULL);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static const struct udevice_id axp_pmic_ids[] = {
> { .compatible = "x-powers,axp152" },
> { .compatible = "x-powers,axp202" },
> @@ -33,6 +80,6 @@ U_BOOT_DRIVER(axp_pmic) = {
> .name = "axp_pmic",
> .id = UCLASS_PMIC,
> .of_match = axp_pmic_ids,
> - .bind = dm_scan_fdt_dev,
> + .bind = axp_pmic_bind,
> .ops= _pmic_ops,
> };
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
Hi Marek, On 25.10.21 15:12, Marek Behún wrote: From: Marek Behún Hello Stefan, these are another improvements for kwboot, please apply only after series arm: mvebu: nandpagesize support for kwbimage v1 I'm checking right now and have applied the 3 NAND patches on current master. But this patchset fails at this one: tools: kwboot: Do not modify kwbimage header before increasing its size [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 ~/tmp/kwboot2/* Applying: tools: kwboot: Initialize rfds to zero Applying: tools: kwboot: Fix initialization of tty device Applying: tools: kwboot: Reserve enough space for patching kwbimage in memory Applying: tools: kwboot: Validate 4-byte image data checksum Applying: tools: kwboot: Inject baudrate change back code after data part Applying: tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code Applying: tools: kwboot: Correctly set configuration of UART for BootROM messages Applying: tools: kwboot: Show verbose message when waiting for baudrate change magic Applying: tools: kwboot: Simplify code for aligning image header Applying: tools: kwboot: Do not modify kwbimage header before increasing its size error: sha1 information is lacking or useless (tools/kwboot.c). error: could not build fake ancestor Patch failed at 0010 tools: kwboot: Do not modify kwbimage header before increasing its size hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Any idea what's missing here? Thanks, Stefan The main improvement is in patch 5, which changes where we inject the code for changing baudrate back to 115200 Baud after fast upload. Instead of injecting it before the main data image, we now inject it after. This is because there are some kwb images that upload at address 0, and injecting the code before that doesn't work, since there is no RAM mapped at 0xf000. Marek & Pali Pali Rohár (13): tools: kwboot: Initialize rfds to zero tools: kwboot: Fix initialization of tty device tools: kwboot: Reserve enough space for patching kwbimage in memory tools: kwboot: Validate 4-byte image data checksum tools: kwboot: Inject baudrate change back code after data part tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code tools: kwboot: Correctly set configuration of UART for BootROM messages tools: kwboot: Show verbose message when waiting for baudrate change magic tools: kwboot: Simplify code for aligning image header tools: kwboot: Do not modify kwbimage header before increasing its size tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr() tools: kwboot: Change retry loop from decreasing to increasing tools: kwboot: Resend first 3 xmodem retry packets immediately tools/kwboot.c | 178 + 1 file changed, 120 insertions(+), 58 deletions(-) Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 1/1] blk: simplify blk_get_devnum_by_typename()
On Mon, Oct 25, 2021 at 09:18:49AM -0600, Simon Glass wrote: > Hi Heinrich, > > On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt > wrote: > > > > On 10/25/21 09:54, Heinrich Schuchardt wrote: > > > On 10/24/21 21:54, Simon Glass wrote: > > >> Hi Heinrich, > > >> > > >> On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt > > >> wrote: > > >>> > > >>> The block descriptor contains the if_type. There is no need to first > > >>> look > > >>> up the uclass for the if_type and then to check the parent device's > > >>> uclass > > >>> to know if the device has the correct if_type. > > >>> > > >>> Signed-off-by: Heinrich Schuchardt > > >>> --- > > >>> drivers/block/blk-uclass.c | 35 +-- > > >>> 1 file changed, 1 insertion(+), 34 deletions(-) > > >> > > >> This seems to be heading in the wrong direction though. > > >> > > >> The IF_TYPE should really go away and be replaced with the UCLASS ID, > > >> I think. > > >> > > >> At present we have lots of calls to blk_create_device_f() which > > >> specify the type. I think we should drop the IF_TYPE_.. arg to that > > >> function and have it figured out from the uclass, in the interim. > > >> > > >> But why do we need IF_TYPE now? > > > > > > I admit that this patch is just an intermediate step. > > > > > > We can replace IF_TYPE by ULASS ID once SPL block devices are always > > > using the driver model. Have we reached this point yet? I have not seen > > > drivers/block/blk_legacy.c being deleted. > > > > qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of > > defconfigs requiring drivers/block/blk_legacy.c > > Yes, we seem to have BLK on only for MMC and USB, but malta64 (for > example) uses IDE. > > The problem seems to be HAVE_BLOCK_DEVICE which should not be used. > > +Tom Rini > > Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on BROKEN? Daniel, do you know what's up with malta and what needs to be migrated to DM, possibly, at this point still, wrt storage devices? Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
Hi Heinrich, On Mon, 25 Oct 2021 at 09:44, Heinrich Schuchardt wrote: > > On 10/25/21 17:18, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt > > wrote: > >> > >> On 10/25/21 09:54, Heinrich Schuchardt wrote: > >>> On 10/24/21 21:54, Simon Glass wrote: > Hi Heinrich, > > On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt > wrote: > > > > The block descriptor contains the if_type. There is no need to first > > look > > up the uclass for the if_type and then to check the parent device's > > uclass > > to know if the device has the correct if_type. > > > > Signed-off-by: Heinrich Schuchardt > > --- > >drivers/block/blk-uclass.c | 35 +-- > >1 file changed, 1 insertion(+), 34 deletions(-) > > This seems to be heading in the wrong direction though. > > The IF_TYPE should really go away and be replaced with the UCLASS ID, > I think. > > At present we have lots of calls to blk_create_device_f() which > specify the type. I think we should drop the IF_TYPE_.. arg to that > function and have it figured out from the uclass, in the interim. > > But why do we need IF_TYPE now? > >>> > >>> I admit that this patch is just an intermediate step. > >>> > >>> We can replace IF_TYPE by ULASS ID once SPL block devices are always > >>> using the driver model. Have we reached this point yet? I have not seen > >>> drivers/block/blk_legacy.c being deleted. > >> > >> qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of > >> defconfigs requiring drivers/block/blk_legacy.c > > > > Yes, we seem to have BLK on only for MMC and USB, but malta64 (for > > example) uses IDE. > > > > The problem seems to be HAVE_BLOCK_DEVICE which should not be used. > > > > +Tom Rini > > > > Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on > > BROKEN? > > > >> > >> Best regards > >> > >> Heinrich > >> > >>> > >>> Removing if_type_uclass_id[] is anyway on the right path. > > > > Are you sure? Instead, could we use the uclass ID in more places? > > Yes, you want to get rid of if_type. This means the table will become > obsolete. Yes. > Once the legacy drivers are removed we can replace all occurrences of > if_type by uclass_id. That uclass_id we should not take from blk_desc > but from udevice. How do we get from a blk_desc to a udevice, though? Could you instead look at moving from using blk_desc to using udevice? If we had that, I think I can see your point with this patch. At present, it looks like a backwards step because you are reducing the usage of the uclass and in fact removing it altogether. Can you see what I am getting at? Let's move towards migration incrementally, not destroy the bridges we have built towards the goal. Regards, Simon
RE: [PATCH v2 2/2] cmd: brcm: netXtreme commands
> -Original Message- > From: Marek Behún > Sent: Monday, October 25, 2021 7:01 AM > To: Roman Bacik > Cc: U-Boot Mailing List ; Bharat Gooty > ; Bin Meng ; Franck > LENORMAND ; Heinrich Schuchardt > ; Kory Maincent ; > Michal Simek ; Patrick Delaunay > ; Peng Fan ; Priyanka > Jain ; Rayagonda Kokatanur > ; Sean Anderson > ; Simon Glass > Subject: Re: [PATCH v2 2/2] cmd: brcm: netXtreme commands > > On Fri, 22 Oct 2021 16:23:33 -0700 > Roman Bacik wrote: > > > From: Bharat Gooty > > > > Following netXtreme commands are supported:- > > Device probe, remove, supported speeds, get/set speeds and > > get/set MAC address. > > NAK. > > - "bnxt get mac > > U-Boot uses the ethaddr and ethNaddr environment variables for MAC > addresses. You don't need a new custom command for that when there is > a generic mechanism for this. > > - " probe" / " remove" > > You also shouldn't need a command for driver probe / remove. DM should > probe your driver automatically. And if you need it for debugging, > please add such subcommand to the dm command. > > - "bnxt get supported_speed" > "bnxt get link_speed" > > These should be available via the mdio command when you register your > PHY driver via appropriate API. > > Marek Hi Marek, Thank you very much for your feedback. We have two Ethernet drivers. One is 10/100/1000 MB rmii driver, which is being used as you have described. The second one is this 10/100 GB bnxt driver, which is probed and managed on demand with these netXtreme commands. We will have a look and address your comments. Thanks, Roman -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 1/1] smbios: amend the description of smbios_string()
Hi Heinrich, On Mon, 25 Oct 2021 at 01:26, Heinrich Schuchardt wrote: > > On 10/24/21 21:54, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 21 Oct 2021 at 03:16, Heinrich Schuchardt > > wrote: > >> > >> Add a warning that this function only works for strings preceding the first > >> non-string field. > > > > What is a non-string field? If you mean an int field, for example, > > then that would not have an entry in the string table, so I'm a bit > > unsure about what exactly the problem is? > > https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf > Table 6 – BIOS Information (Type 0) structure > > "Vendor", "BIOS Version" are strings. > The are followed by "BIOS Starting Address Segment" is a word which may > contain a zero byte or not. > > You can not use smbios_string() to find the string "BIOS Release Date". I'm still lost...what does this have to do with the string table? As I understand it, in the archaic format for SMBIOS, type 0 can have entries in the string table for: vendor (string 1) bios version (2) bios release (3) So if you want those you have a string table like: my_vendor\0my_bios_v\0my_release\0\0 ? Regards, SImon > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> include/smbios.h | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/include/smbios.h b/include/smbios.h > >> index aa6b6f3849..b7a1b8e412 100644 > >> --- a/include/smbios.h > >> +++ b/include/smbios.h > >> @@ -258,6 +258,10 @@ const struct smbios_header *smbios_header(const > >> struct smbios_entry *entry, int > >> /** > >>* smbios_string() - Return string from SMBIOS > >>* > >> + * This function counts the zero bytes at the end of strings to identify > >> the > >> + * string to retrieve. This only works up to the first non-string field > >> in the > >> + * table. > >> + * > >>* @header:pointer to struct smbios_header > >>* @index: string index > >>* @return:NULL or a valid const char pointer > >> -- > >> 2.32.0 > >> >
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
Hi Rasmus, On Mon, 25 Oct 2021 at 01:06, Rasmus Villemoes wrote: > > On 24/10/2021 21.54, Simon Glass wrote: > > Hi Rasmus, > > > > On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes > > wrote: > >> > >> On 21/10/2021 18.03, Tom Rini wrote: > >>> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote: > Hi Marek, > > On Thu, 21 Oct 2021 at 07:28, Marek Behún wrote: > > > > On Thu, 21 Oct 2021 15:25:37 +0200 > > Marek Behún wrote: > > > >> Hello, > >> > >> On Thu, 21 Oct 2021 15:06:51 +0200 > >> Wolfgang Denk wrote: > >> > >>> I confirm that '+=' looks better. But '+=" is technically broken. > >> > >> a bit of my opinion: > >> I think =+ will confuse far more people than + as last character of var > >> name working weirdly. But I also think that + should be supported as > >> last character. Therefore I propose backslash escaping in variable > >> name, > >> i.e. > >> var+=value > >> appends value to var, while > >> var\+=value > >> sets variable with name "var+" > > My first preference is to disallow + at the end of an end var. Perhaps > we can start printing a warning if people do it, for a few releases. > > My distance second preference is what Marek has here, using a > backslash to escape the + character. > >>> > >>> How bad does it make the parser look if we allow trailing + in variable > >>> names, by escaping them? It's seemingly the substantive objection at > >>> this point. > >>> > >> > >> So I don't understand all the bruhahaha around a + at the end of the > >> varname. Nobody suggests (that I have seen) changing anything about how > >> U-Boot at runtime interprets and handles variables, so all variable > >> names that used to be valid continue to be so. > >> > >> It's just that this _new_ method of generating the environment places > >> certain restrictions on what can be done. The old-fashioned ways > >> (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and > >> run-time 'env set') continue to allow people to define whatever env vars > >> they want. This new method is meant for transitioning in-tree boards' > >> default environment, and no in-tree boards need anything exotic. > >> > >> Also, completely independent of whether the subsequent parser is > >> implemented in awk or python or rust, or what syntax it accepts and the > >> semantics of that syntax, the fact that we first pass the input through > >> cpp already means some things just won't work the same way as when given > >> to mkenvimage, and that applies to both sides of the =: > >> > >> printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive > >> spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp - > >> > >> x y= > >> msg=I like 1 > >> five spaces=5spaces > >> > >> [In case its broken by the email, there are actually five spaces in the > >> printf string between the words "five" and "spaces", the above should > >> illustrate that cpp collapses those to a single space]. > >> > >> So, I'd much rather we do a cleaner break, and accept (and ignore) > >> whitespace on either side of the assignment operator - that's how Make > >> variable assignments work IIRC. And since a lot of people making use of > >> this will already be familiar with Yocto, I think we should have two > >> compound assignment operators, .= and +=. That still allows one to use > >> any non-whitespace, non-= characters (modulo the restrictions imposed by > >> the whole thing passing through cpp) in variable names, so > >> > >> foo+=abc > >> > >> means > >> > >> foo+ = abc > >> > >> while could append to foo by saying > >> > >> foo += abc > >> > >> That whitespace around the assignment operators would also make the > >> input files somewhat more readable - there really is no point in having > >> human-readable, human-editable text files having a format > >> almost-but-not-quite be that of the on-disk format. > > > > I am OK with this on the name front, as I assume we don't want to > > allow space in a var name! > > Exactly, there's really never any case where that would be sensible. But > I would probably go a bit further and simply restrict varnames to the > usual alphanumerics plus [_.+-] - in particular, exclude single and > double quotes and backslash. That leaves the door open for somebody to > later support "arbitrary" variable names by defining what it would mean > to say e.g. > > "abc \n'\"\tfoo" = hahaha > > or whatever syntax they'd propose, but there's absolutely no point in > implementing anything like that initially. > > > But how do I do this? > > > > bootargs=console=fred > > #ifdef SOMETHING > > bootargs+= dm-verity=... > > #endif > > > > We need the space between the bootargs. > > Exactly like that, and for the case where you want to append something > _without_ an extra space there's the .= operator I also suggested. Do you have a link to the docs for that? Perhaps we should get
Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
Hi Heinrich, On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt wrote: > > On 10/25/21 09:54, Heinrich Schuchardt wrote: > > On 10/24/21 21:54, Simon Glass wrote: > >> Hi Heinrich, > >> > >> On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt > >> wrote: > >>> > >>> The block descriptor contains the if_type. There is no need to first > >>> look > >>> up the uclass for the if_type and then to check the parent device's > >>> uclass > >>> to know if the device has the correct if_type. > >>> > >>> Signed-off-by: Heinrich Schuchardt > >>> --- > >>> drivers/block/blk-uclass.c | 35 +-- > >>> 1 file changed, 1 insertion(+), 34 deletions(-) > >> > >> This seems to be heading in the wrong direction though. > >> > >> The IF_TYPE should really go away and be replaced with the UCLASS ID, > >> I think. > >> > >> At present we have lots of calls to blk_create_device_f() which > >> specify the type. I think we should drop the IF_TYPE_.. arg to that > >> function and have it figured out from the uclass, in the interim. > >> > >> But why do we need IF_TYPE now? > > > > I admit that this patch is just an intermediate step. > > > > We can replace IF_TYPE by ULASS ID once SPL block devices are always > > using the driver model. Have we reached this point yet? I have not seen > > drivers/block/blk_legacy.c being deleted. > > qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of > defconfigs requiring drivers/block/blk_legacy.c Yes, we seem to have BLK on only for MMC and USB, but malta64 (for example) uses IDE. The problem seems to be HAVE_BLOCK_DEVICE which should not be used. +Tom Rini Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on BROKEN? > > Best regards > > Heinrich > > > > > Removing if_type_uclass_id[] is anyway on the right path. Are you sure? Instead, could we use the uclass ID in more places? Regards, Simon
Re: [PATCH v2] bootstage: Add SPL support
Hi Marek, On Sun, 24 Oct 2021 at 14:44, Marek Vasut wrote: > > On 10/24/21 9:54 PM, Simon Glass wrote: > > On Fri, 22 Oct 2021 at 19:06, Marek Vasut wrote: > >> > >> Allow usage of the bootstage facilities in SPL. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Simon Glass > >> --- > >> V2: Fix multiple misuses of BOOTSTAGE vs SHOW_BOOT_PROGRESS > >> --- > >> arch/x86/cpu/cpu.c| 2 +- > >> board/siemens/iot2050/board.c | 2 +- > >> common/Kconfig.boot | 9 + > >> common/init/board_init.c | 2 +- > >> common/spl/spl.c | 2 +- > >> include/bootstage.h | 2 +- > >> 6 files changed, 14 insertions(+), 5 deletions(-) > > > > Reviewed-by: Simon Glass > > > > Can you enable this for sandbox_spl so we get build coverage? > > Isn't that the case already ? I recall sandbox was one of the machines > which failed to build and where I found these board issues. If not, then > please send a separate patch. Apparently it is not enabled for sandbox_spl Regards, Simon
Re: Pull request: u-boot-imx u-boot-imx-20211022
On Mon, Oct 25, 2021 at 03:17:21PM +0200, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > > The following changes since commit 79b8849d4c1e73df2a79a1d5a5f6166d0dd67a12: > > Merge tag 'u-boot-imx-20211020' of > https://source.denx.de/u-boot/custodians/u-boot-imx (2021-10-20 14:24:09 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20211022 > > for you to fetch changes up to 56ced770999bd14cd940e07239f4197852460142: > > tools: imx8m_image: Support ddr3 firmware (2021-10-21 13:59:26 +0200) > With a quick pytest run on my mx6cuboxi as well, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH v3] driver: spi: add bcm iproc qspi support.
> -Original Message- > From: Jagan Teki > Sent: Sunday, October 24, 2021 11:44 PM > To: Roman Bacik > Cc: U-Boot Mailing List ; Rayagonda Kokatanur > ; Bharat Gooty > > Subject: Re: [PATCH v3] driver: spi: add bcm iproc qspi support. > > On Thu, Oct 21, 2021 at 4:01 AM Roman Bacik > wrote: > > > > From: Rayagonda Kokatanur > > > > IPROC qspi driver supports both BSPI and MSPI modes. > > > > Signed-off-by: Rayagonda Kokatanur > > > Signed-off-by: Bharat Gooty > > Acked-by: Rayagonda Kokatanur > > > > Signed-off-by: Roman Bacik > > --- > > > > Changes in v3: > > - fix warning by including linux/delay.h > > - change ofdata_to_platdata to of_to_plat > > - change priv_auto_alloc_size to priv_auto > > > > Changes in v2: > > - remove include spi-nor.h > > - define and use named BITs for writing register values > > - remove bspi_set_4byte_mode() method > > > > drivers/spi/Kconfig | 6 + > > drivers/spi/Makefile | 1 + > > drivers/spi/iproc_qspi.c | 713 > +++ > > drivers/spi/iproc_qspi.h | 20 ++ > > 4 files changed, 740 insertions(+) > > create mode 100644 drivers/spi/iproc_qspi.c > > create mode 100644 drivers/spi/iproc_qspi.h > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > > index d07e9a28af82..e76fadef32dd 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -178,6 +178,12 @@ config ICH_SPI > > access the SPI NOR flash on platforms embedding this Intel > > ICH IP core. > > > > +config IPROC_QSPI > > + bool "QSPI driver for BCM iProc QSPI Controller" > > + help > > + This selects the BCM iProc QSPI controller. > > + This driver support spi flash single, quad and memory reads. > > + > > config KIRKWOOD_SPI > > bool "Marvell Kirkwood SPI Driver" > > help > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > > index d2f24bccefd3..869763187062 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o > > obj-$(CONFIG_FSL_ESPI) += fsl_espi.o > > obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o > > obj-$(CONFIG_ICH_SPI) += ich.o > > +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o > > obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o > > obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o > > obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o > > diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c > > new file mode 100644 > > index ..08881bf61764 > > --- /dev/null > > +++ b/drivers/spi/iproc_qspi.c > > @@ -0,0 +1,713 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright 2020-2021 Broadcom > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include "iproc_qspi.h" > > + > > +/* 175MHz */ > > +#define QSPI_AXI_CLK 17500 > > +#define QSPI_DEF_SCK_FREQ 5000 > > +#define QSPI_WAIT_TIMEOUT_MS 200U > > +#define DWORD_ALIGNED(a) (!(((ulong)(a)) & 3)) > > + > > +/* Chip attributes */ > > +#define SPBR_MIN 8U > > +#define SPBR_MAX 255U > > +#define NUM_CDRAM 16U > > + > > +#define CDRAM_PCS0 2 > > +#define CDRAM_CONT BIT(7) > > +#define CDRAM_BITS_EN BIT(6) > > +#define CDRAM_QUAD_MODEBIT(8) > > +#define CDRAM_RBIT_INPUT BIT(10) > > +#define MSPI_SPE BIT(6) > > +#define MSPI_CONT_AFTER_CMDBIT(7) > > + > > +/* Register fields */ > > +#define MSPI_SPCR0_MSB_BITS_8 0x0020 > > +#define BSPI_RAF_CONTROL_START_MASK0x0001 > > +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK 0x0001 > > +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002 > > +#define BSPI_BITS_PER_PHASE_ADDR_MARK 0x0001 > > +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0 > > +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16 > > +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3 > > +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1 > > +#define BSPI_STRAP_OVERRIDE_SHIFT 0 > > + > > +/* MSPI registers */ > > +#define MSPI_SPCR0_LSB_REG 0x000 > > +#define MSPI_SPCR0_MSB_REG 0x004 > > +#define MSPI_SPCR1_LSB_REG 0x008 > > +#define MSPI_SPCR1_MSB_REG 0x00c > > +#define MSPI_NEWQP_REG 0x010 > > +#define MSPI_ENDQP_REG 0x014 > > +#define MSPI_SPCR2_REG 0x018 > > +#define MSPI_STATUS_REG0x020 > > +#define MSPI_CPTQP_REG 0x024 > > +#define MSPI_TXRAM_REG
RE: [PATCH v2 2/2] cmd: brcm: netXtreme commands
> -Original Message-
> From: Heinrich Schuchardt
> Sent: Saturday, October 23, 2021 1:02 AM
> To: Roman Bacik ; U-Boot Mailing List b...@lists.denx.de>
> Cc: Bharat Gooty ; Bin Meng
> ; Franck LENORMAND
> ; Kory Maincent
> ; Michal Simek ;
> Patrick Delaunay ; Peng Fan
> ; Priyanka Jain ; Rayagonda
> Kokatanur ; Sean Anderson
> ; Simon Glass
> Subject: Re: [PATCH v2 2/2] cmd: brcm: netXtreme commands
>
>
>
> On 10/23/21 01:23, Roman Bacik wrote:
> > From: Bharat Gooty
> >
> > Following netXtreme commands are supported:-
> > Device probe, remove, supported speeds, get/set speeds and
> > get/set MAC address.
> >
> > Signed-off-by: Bharat Gooty
> >
> > Signed-off-by: Roman Bacik
>
> Please, add a man-page for the new command in doc/usage/.
> Here is an example: doc/usage/loady.rst
> Add the new man-page to doc/usage/index.rst
> Test building with 'make htmldocs'.
>
> > ---
> >
> > (no changes since v1)
> >
> > cmd/Kconfig | 2 +
> > cmd/broadcom/Kconfig | 10 ++
> > cmd/broadcom/Makefile | 3 +-
> > cmd/broadcom/bnxt.c | 237
> ++
> > 4 files changed, 251 insertions(+), 1 deletion(-)
> > create mode 100644 cmd/broadcom/Kconfig
> > create mode 100644 cmd/broadcom/bnxt.c
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 5b30b13e438f..e054292dbcd0 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1953,6 +1953,8 @@ endmenu
> >
> > source "cmd/ti/Kconfig"
> >
> > +source "cmd/broadcom/Kconfig"
> > +
> > config CMD_BOOTSTAGE
> > bool "Enable the 'bootstage' command"
> > depends on BOOTSTAGE
> > diff --git a/cmd/broadcom/Kconfig b/cmd/broadcom/Kconfig
> > new file mode 100644
> > index ..6f16b09d1425
> > --- /dev/null
> > +++ b/cmd/broadcom/Kconfig
> > @@ -0,0 +1,10 @@
> > +menu "Broadcom specific command line interface"
> > +
> > +config BNXT_ETH_CMD
> > + bool "BNXT commands"
> > + depends on BNXT_ETH
> > + help
> > + Broadcom NXS ethernet controller commands. Commands
> supported are:-
> > + Driver probe, Driver remove, Supported speeds, get/set MAC
> address and get/set Link speeds.
> > +
> > +endmenu
> > diff --git a/cmd/broadcom/Makefile b/cmd/broadcom/Makefile
> > index 62268d98d0dd..0027c1c15e5a 100644
> > --- a/cmd/broadcom/Makefile
> > +++ b/cmd/broadcom/Makefile
> > @@ -1,6 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0+
> > -# Copyright 2020 Broadcom
> > +# Copyright 2020-2021 Broadcom
> >
> > obj-y += chimp_boot.o
> > obj-y += nitro_image_load.o
> > obj-y += chimp_handshake.o
> > +obj-$(CONFIG_BNXT_ETH_CMD) += bnxt.o
> > diff --git a/cmd/broadcom/bnxt.c b/cmd/broadcom/bnxt.c
> > new file mode 100644
> > index ..b9d1e59a74fb
> > --- /dev/null
> > +++ b/cmd/broadcom/bnxt.c
> > @@ -0,0 +1,237 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2021 Broadcom
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int do_bnxt_set_link(struct bnxt *bp, char *link_str)
> > +{
> > + bp->link_set = simple_strtoul(link_str, NULL, 16);
> > +
> > + switch (bp->link_set) {
> > + case LINK_SPEED_DRV_AUTONEG:
> > + printf("- AutoNeg Not Supported\n");
> > + return 0;
>
> Please, remove the leading '- '. It just increases code size.
> In case of an error, please, return CMD_RET_FAILURE.
> Please, remove captitalization of 'Not Supported'
>
> > + case LINK_SPEED_DRV_1G:
> > + if (!(bp->support_speeds &
> PORT_QCFG_SUPPORT_SPEEDS_1GB)) {
> > + printf("- 1 GBPS: Link Speed is not supported\n");
>
> ditto
>
> > + return 0;
> > + }
> > +
> > + break;
> > + case LINK_SPEED_DRV_10G:
> > + if (!(bp->support_speeds &
> PORT_QCFG_SUPPORT_SPEEDS_10GB)) {
> > + printf("- 10 GBPS: Link Speed is not supported\n");
> > + return 0;
>
> ditto
>
>
> > + }
> > +
> > + break;
> > + case LINK_SPEED_DRV_25G:
> > + if (!(bp->support_speeds &
> PORT_QCFG_SUPPORT_SPEEDS_25GB)) {
> > + printf("- 25 GBPS: Link Speed is not supported\n");
> > + return 0;
>
> ditto
>
> > + }
> > +
> > + break;
> > + case LINK_SPEED_DRV_40G:
> > + printf("- 40 GBPS Not Supported\n");
> > + return 0;
>
> ditto
>
> > + case LINK_SPEED_DRV_50G:
> > + if (!(bp->support_speeds &
> PORT_QCFG_SUPPORT_SPEEDS_50GB)) {
> > + printf("- 50 GBPS: Link Speed is not supported\n");
> > + return 0;
>
> ditto
>
> > + }
> > +
> > + break;
> > + case LINK_SPEED_DRV_100G:
> > + if (!(bp->support_speeds &
> PORT_QCFG_SUPPORT_SPEEDS_100GB)) {
> > +
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
Hi Pali, On 25.10.21 16:42, Pali Rohár wrote: On Monday 25 October 2021 16:39:44 Stefan Roese wrote: Hi Marek, On 25.10.21 15:12, Marek Behún wrote: From: Marek Behún Hello Stefan, these are another improvements for kwboot, please apply only after series arm: mvebu: nandpagesize support for kwbimage v1 I'm checking right now and have applied the 3 NAND patches on current master. But this patchset fails at this one: tools: kwboot: Do not modify kwbimage header before increasing its size [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 ~/tmp/kwboot2/* Applying: tools: kwboot: Initialize rfds to zero Applying: tools: kwboot: Fix initialization of tty device Applying: tools: kwboot: Reserve enough space for patching kwbimage in memory Applying: tools: kwboot: Validate 4-byte image data checksum Applying: tools: kwboot: Inject baudrate change back code after data part Applying: tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code Applying: tools: kwboot: Correctly set configuration of UART for BootROM messages Applying: tools: kwboot: Show verbose message when waiting for baudrate change magic Applying: tools: kwboot: Simplify code for aligning image header Applying: tools: kwboot: Do not modify kwbimage header before increasing its size error: sha1 information is lacking or useless (tools/kwboot.c). error: could not build fake ancestor Patch failed at 0010 tools: kwboot: Do not modify kwbimage header before increasing its size hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Any idea what's missing here? Hello! I'm using also this patch: https://patchwork.ozlabs.org/project/uboot/patch/20211021144609.9319-2-p...@kernel.org/ Ah, yes. That does the trick. Now all patches apply clean. Thanks. Testing with all these patches on my AXP target does show, it still does not work with baudrate > 115k: [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b u-boot-spl.kwb -t /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 Patching image boot signature to UART Injecting binary header code for changing baudrate to 230400 Bd Injecting code for changing baudrate back Sending boot message. Please reboot the target...| Waiting 2s and flushing tty Sending boot image header (90112 bytes)... 0 % [..] 10 % [..] 20 % [..] 29 % [..] 39 % [..] 49 % [..] 59 % [..] 69 % [..] 79 % [..] 89 % [..] 99 % [ ] Done U-Boot SPL 2021.10-00908-gc129aa2f173a (Oct 25 2021 - 17:10:55 +0200) High speed PHY - Version: 2.1.5 (COM-PHY-V20) High speed PHY - Ended Successfully DDR3 Training Sequence - Ver 5.7.4 DDR3 Training Sequence - Ended Successfully Trying to boot from BOOTROM Returning to BootROM (return address 0x0aa0)... Changing baudrate to 230400 Bd Baudrate was not changed xmodem: Protocol error [stefan@ryzen u-boot-marvell (kwboot-test1)]$ Not changing the baudrate still works. Any idea what I should test? Or do you have further changes in the queue that I should wait upon? Thanks, Stefan
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Hi François,
On Mon, 25 Oct 2021 at 01:14, François Ozog wrote:
>
>
>
> Le lun. 25 oct. 2021 à 09:05, Masami Hiramatsu
> a écrit :
>>
>> Hi Francois,
>>
>> 2021年10月25日(月) 15:28 François Ozog :
>> >
>> >
>> >
>> > Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro
>> > a écrit :
>> >>
>> >> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
>> >> > Hi Masami,
>> >> >
>> >> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
>> >> > wrote:
>> >> > >
>> >> > > Hi Simon,
>> >> > >
>> >> > > 2021年10月15日(金) 9:40 Simon Glass :
>> >> > > >
>> >> > > > Hi Takahiro,
>> >> > > >
>> >> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro
>> >> > > > wrote:
>> >> > > > >
>> >> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature
>> >> > > > > from DTB to
>> >> > > > > .rodata"") failed to revert the removal of
>> >> > > > > efi_get_public_key_data().
>> >> > > > >
>> >> > > > > Add back this function and move it under lib/efi_loader so that
>> >> > > > > other
>> >> > > > > platforms can utilize it. It is now declared as a weak function
>> >> > > > > so that
>> >> > > > > it can be replaced with a platform-specific implementation.
>> >> > > > >
>> >> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from
>> >> > > > > DTB to
>> >> > > > > .rodata"")
>> >> > > > > Signed-off-by: AKASHI Takahiro
>> >> > > > > ---
>> >> > > > > lib/efi_loader/efi_capsule.c | 36
>> >> > > > >
>> >> > > > > 1 file changed, 36 insertions(+)
>> >> > > > >
>> >> > > > > diff --git a/lib/efi_loader/efi_capsule.c
>> >> > > > > b/lib/efi_loader/efi_capsule.c
>> >> > > > > index b75e4bcba1a9..44f5da61a9be 100644
>> >> > > > > --- a/lib/efi_loader/efi_capsule.c
>> >> > > > > +++ b/lib/efi_loader/efi_capsule.c
>> >> > > > > @@ -11,15 +11,20 @@
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > +#include
>> >> > > > > +#include
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > +#include
>> >> > > > >
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > > #include
>> >> > > > >
>> >> > > > > +DECLARE_GLOBAL_DATA_PTR;
>> >> > > > > +
>> >> > > > > const efi_guid_t efi_guid_capsule_report =
>> >> > > > > EFI_CAPSULE_REPORT_GUID;
>> >> > > > > static const efi_guid_t efi_guid_firmware_management_capsule_id =
>> >> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>> >> > > > > @@ -251,6 +256,37 @@ out:
>> >> > > > > }
>> >> > > > >
>> >> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>> >> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
>> >> > > > > *pkey_len)
>> >> > > >
>> >> > > > I don't think this should be weak. What other way is there of
>> >> > > > handling
>> >> > > > this and why would it be platform-specific?
>> >> > >
>> >> > > I have a question about the current design of the capsule auth key.
>> >> > > If the platform has its own key-storage, how can the platform use the
>> >> > > platform specific storage? Does such platform load the key from the
>> >> > > storage
>> >> > > and generate the dtb node in the platform initialization code? (or
>> >> > > device driver?)
>> >> >
>> >> > Are we talking about a public key (which I assume from the function
>> >> > naming) or some secret key. What is an auth key?
>> >>
>> >> Surely, a public key (more strictly, x509 certificate under the current
>> >> implementation)
>> >>
>> >> > As I understand it, the public key should be provided by the platform
>> >> > in devicetree that U-Boot uses, by whatever prior stage has access to
>> >> > the key.
>> >>
>> >> I still believe that some platform provider may want to save the key
>> >> in a *safer* storage, which should be at least read-only for
>> >> non-authorized
>> >> writers.
>> >
>> >
>> > indeed. And U-Boot may not be entitled at all to check the capsule
>> > signature. For example updating SCP firmware with a key that is in secure
>> > world and will never leave this world.
>>
>> I think secure world firmware updates should be discussed in another
>> thread, like with FWU. At this point, the capsule signature will be
>> only authenticated by U-Boot, because we haven't passed the capsule
>> image to the secure world yet.
>
> i took a wrong example. The choice of authentication is to be done by the
> capsule driver designer and is outside scope of U-Boot. And the key may be in
> a separate storage or even the driver may invoke secure world for the
> authentication (FF-A API or other platform specific). U-Boot may have a
> capsule driver to update U-Boot components such as external env file. The
> location of the key can be in a u-boot specific device tree.
There is no such thing, in practice. There is just one devicetree. We
need to resolve this as we are still not aligned on this, after many
months. I think in fact there is difference of opinion about the
nature of the firmware
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
Hi Andy, On Mon, 25 Oct 2021 at 01:34, Andy Shevchenko wrote: > > On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > > wrote: > > > > > > The dsdt.asl is usually combined out of several files that are included > > > in the main one. Whenever we change the content of any of such files, > > > build system is not able to recognize them. Hence the easiest way is to > > > force DSDT rebuild each time we run make. > > > Ick. Since it uses #include, doesn't the dependency generation work with > > this? > > How? If you do a sandbox build you will see this file: arch/sandbox/dts/.sandbox.dtb.cmd It contains the dependencies used to compile the device tree. Can we use the same mechanism? There is a .cmd file for the dsdt file but it does not seem to have the correct contents. Regards, Simon
Re: [PATCH] clk: introduce u-boot,ignore-clk-defaults
Hi Sean, On Sun, 24 Oct 2021 at 18:13, Sean Anderson wrote: > > On 10/14/21 10:19 PM, Simon Glass wrote: > > Hi Peng, Sean, > > > > On Thu, 14 Oct 2021 at 19:17, Peng Fan wrote: > >> > >>> Subject: Re: [PATCH] clk: introduce u-boot,ignore-clk-defaults > >>> > >>> > >>> On 10/13/21 5:37 AM, Peng Fan (OSS) wrote: > From: Peng Fan > > Current code has a force clk_set_defaults in multiple stages, U-Boot > reuse the same device tree and Linux Kernel device tree, but we not > register all the clks as Linux Kernel, so clk_set_defaults will fail > and cause the clk provider registeration fail. > > So introduce a new property to ignore the default settings which could > be used by any node that wanna ignore default settings. > > Signed-off-by: Peng Fan > --- > doc/device-tree-bindings/device.txt | 3 +++ > drivers/clk/clk-uclass.c| 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/doc/device-tree-bindings/device.txt > b/doc/device-tree-bindings/device.txt > index 73ce2a3b5b..fe34ced268 100644 > --- a/doc/device-tree-bindings/device.txt > +++ b/doc/device-tree-bindings/device.txt > @@ -28,6 +28,9 @@ the acpi,compatible property. > Linux will only load the driver if the device can be detected > (e.g. on > >>> I2C > bus). Note that this is an out-of-tree Linux feature. > > +Common device bindings that could be shared listed below: > + - u-boot,ignore-clk-defaults : ignore the assigned-clock-parents > + and assigned-clock-rates for a device that has the property. > > Example > --- > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index > 493018b33e..6bf3179e7b 100644 > --- a/drivers/clk/clk-uclass.c > +++ b/drivers/clk/clk-uclass.c > @@ -376,6 +376,9 @@ int clk_set_defaults(struct udevice *dev, enum > >>> clk_defaults_stage stage) > if (!dev_has_ofnode(dev)) > return 0; > > + if (ofnode_get_property(dev_ofnode(dev), > "u-boot,ignore-clk-defaults", > >>> NULL)) > + return 0; > + > /* > * To avoid setting defaults twice, don't set them before > relocation. > * However, still set them for SPL. And still set them if > explicitly > > >>> > >>> Why not just have the property ignore errors? > >> > >> I think the force err return was done by Simon? > >> > >>> > >>> In the long term, it may be better to standardize that e.g. ENOENT means > >>> that > >>> the clock doesn't exist. That way we can skip setting the defaults. > >>> ENOSYS should probably be treated the same way (warn, but don't fail). > >> > >> I am not sure whether people expect force error for ENOENT/ENOSYS in > >> U-Boot. > >> For i.MX, I not expect force error. > > > > Yes that is me, indeed. It's just that we should not silently ignore > > errors. If we know the clock is optional, then the driver that knows > > that can handle it. But if we start having things quietly fail, > > debugging becomes a pain. > > Can't we have them loudly fail instead? > That is how it works today, as I understand it. But some boards want the defaults to be there but not to implement them in U-Boot. This seems fair enough to me. Perhaps we could add something to each node instead, to disable it? Regards, Simon > --Sean
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Monday 25 October 2021 16:39:44 Stefan Roese wrote: > Hi Marek, > > On 25.10.21 15:12, Marek Behún wrote: > > From: Marek Behún > > > > Hello Stefan, > > > > these are another improvements for kwboot, please apply only after series > >arm: mvebu: nandpagesize support for kwbimage v1 > > I'm checking right now and have applied the 3 NAND patches on current > master. But this patchset fails at this one: > > tools: kwboot: Do not modify kwbimage header before increasing its size > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 ~/tmp/kwboot2/* > Applying: tools: kwboot: Initialize rfds to zero > Applying: tools: kwboot: Fix initialization of tty device > Applying: tools: kwboot: Reserve enough space for patching kwbimage in > memory > Applying: tools: kwboot: Validate 4-byte image data checksum > Applying: tools: kwboot: Inject baudrate change back code after data part > Applying: tools: kwboot: Recalculate 4-byte data checksum after injecting > baudrate code > Applying: tools: kwboot: Correctly set configuration of UART for BootROM > messages > Applying: tools: kwboot: Show verbose message when waiting for baudrate > change magic > Applying: tools: kwboot: Simplify code for aligning image header > Applying: tools: kwboot: Do not modify kwbimage header before increasing its > size > error: sha1 information is lacking or useless (tools/kwboot.c). > error: could not build fake ancestor > Patch failed at 0010 tools: kwboot: Do not modify kwbimage header before > increasing its size > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > Any idea what's missing here? Hello! I'm using also this patch: https://patchwork.ozlabs.org/project/uboot/patch/20211021144609.9319-2-p...@kernel.org/ > Thanks, > Stefan > > > The main improvement is in patch 5, which changes where we inject the code > > for changing baudrate back to 115200 Baud after fast upload. Instead of > > injecting it before the main data image, we now inject it after. > > > > This is because there are some kwb images that upload at address 0, and > > injecting the code before that doesn't work, since there is no RAM mapped > > at 0xf000. > > > > Marek & Pali > > > > Pali Rohár (13): > >tools: kwboot: Initialize rfds to zero > >tools: kwboot: Fix initialization of tty device > >tools: kwboot: Reserve enough space for patching kwbimage in memory > >tools: kwboot: Validate 4-byte image data checksum > >tools: kwboot: Inject baudrate change back code after data part > >tools: kwboot: Recalculate 4-byte data checksum after injecting > > baudrate code > >tools: kwboot: Correctly set configuration of UART for BootROM > > messages > >tools: kwboot: Show verbose message when waiting for baudrate change > > magic > >tools: kwboot: Simplify code for aligning image header > >tools: kwboot: Do not modify kwbimage header before increasing its > > size > >tools: kwboot: Calculate real used space in kwbimage header when > > calling kwboot_img_grow_hdr() > >tools: kwboot: Change retry loop from decreasing to increasing > >tools: kwboot: Resend first 3 xmodem retry packets immediately > > > > tools/kwboot.c | 178 + > > 1 file changed, 120 insertions(+), 58 deletions(-) > > > > > Viele Grüße, > Stefan > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > 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 1/1] blk: simplify blk_get_devnum_by_typename()
On 10/25/21 17:18, Simon Glass wrote: Hi Heinrich, On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt wrote: On 10/25/21 09:54, Heinrich Schuchardt wrote: On 10/24/21 21:54, Simon Glass wrote: Hi Heinrich, On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt wrote: The block descriptor contains the if_type. There is no need to first look up the uclass for the if_type and then to check the parent device's uclass to know if the device has the correct if_type. Signed-off-by: Heinrich Schuchardt --- drivers/block/blk-uclass.c | 35 +-- 1 file changed, 1 insertion(+), 34 deletions(-) This seems to be heading in the wrong direction though. The IF_TYPE should really go away and be replaced with the UCLASS ID, I think. At present we have lots of calls to blk_create_device_f() which specify the type. I think we should drop the IF_TYPE_.. arg to that function and have it figured out from the uclass, in the interim. But why do we need IF_TYPE now? I admit that this patch is just an intermediate step. We can replace IF_TYPE by ULASS ID once SPL block devices are always using the driver model. Have we reached this point yet? I have not seen drivers/block/blk_legacy.c being deleted. qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of defconfigs requiring drivers/block/blk_legacy.c Yes, we seem to have BLK on only for MMC and USB, but malta64 (for example) uses IDE. The problem seems to be HAVE_BLOCK_DEVICE which should not be used. +Tom Rini Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on BROKEN? Best regards Heinrich Removing if_type_uclass_id[] is anyway on the right path. Are you sure? Instead, could we use the uclass ID in more places? Yes, you want to get rid of if_type. This means the table will become obsolete. Once the legacy drivers are removed we can replace all occurrences of if_type by uclass_id. That uclass_id we should not take from blk_desc but from udevice. Best regards Heinrich Regards, Simon
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote: > Hi Tom, > > please pull the second sunxi PR for the 2021.10 merge window. > I decided to merge most of Samuel's rework and some smaller patches that > pave the way for more DM transitions and for accommodating the RISC-V SoC > in the future. Merging them now gives us the opportunity to get some wider > testing, since those subtle changes tend to break things. > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS > and OrangePi Zero. > > Summary: > - Add and enable watchdog driver > - Prepare for SYSRESET driven AXP poweroff > - Prepare for SoCs without MMC2 > - Some fixes for extending SPL (SPL-DM for RISC-V) > - Some preparations for proper VBUS management > - Fix secure monitor move > > Thanks, > Andre > > > The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c: > > Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23 > 10:49:28 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master > > for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d: > > mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25 > 14:54:57 +0100) > So first, up, this is now applied to u-boot/master. Next, I dug out my original Kickstarted Pine A64 board (as it's the only sunxi platform I have), and I see it's detected with 1GB memory and as Pine64+ which seems wrong, with the pine64_plus_defconfig (which is what I thought handled all of the A64 platforms). I've not booted this up in forever, and Armbian (the first binary I grabbed) does this as well with v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the answer is I should just e-waste this board and pick up something else? Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
On 25/10/21 12:30PM, Jagan Teki wrote:
> On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote:
> >
> > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> > 8D-8D-8D
> > in the begging of probe.
> >
> > Command extension type is not standardized across flash vendors in DTR mode.
> >
> > For suiting different vendor flash devices, adding a flag to seperate types
> > for
> > soft reset on boot.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/Kconfig| 7 +++
> > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index 67599b32c9..8304d6c973 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > can support a type of operation in a much more refined way compared
> > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> >
> > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> > + bool "Command extension type is INVERT for Software Reset on boot"
> > + default n
> > + help
> > +Because of SFDP information can not be get before boot.
> > +So define command extension type is INVERT when Software Reset on
> > boot only.
> > +
> > config SPI_FLASH_SOFT_RESET
> > bool "Software Reset support for SPI NOR flashes"
> > default n
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index fdaca0a0d3..87a7de7d60 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> > enum spi_nor_cmd_ext ext;
> >
> > ext = nor->cmd_ext_type;
> > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
>
> I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try
> it that way instead of new macro?
The problem is that for OSPI boot mode the ROM can often leave the flash
in 8D-8D-8D mode. So when U-Boot first starts executing the flash is
already in 8D-8D-8D mode and there is no easy and reliable way to detect
this mode. So we must blindly perform a soft reset before probing the
flash and reading SFDP so that it is reset back to a usable state.
This is why we can't detect the extension via BFPT since the flash is in
an unknown state. This is not the case when resetting before booting the
OS since at that point we have fully probed the flash. So I think this
config must only be used for the reset at boot time. For later resets we
should indeed use the extension provided by BFPT.
This is a kinda hacky but I can't come up with a better alternative.
Jamie,
Below diff is what I have been suggesting you in my earlier replies.
Note that this is just a quick and dirty implementation, I have not
tested this at all. That is up to you to do. Please also test soft reset
_after_ the probe is finished so we know that it works correctly when
using data from BFPT as well.
-- 8< --
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 4388a08a90..b0f22e0ce5 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
{
struct spi_mem_op op;
int ret;
- enum spi_nor_cmd_ext ext;
-
- ext = nor->cmd_ext_type;
- nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
SPI_MEM_OP_NO_DUMMY,
@@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
ret = spi_mem_exec_op(nor->spi, );
if (ret) {
dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
- goto out;
+ return ret;
}
op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0),
@@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
ret = spi_mem_exec_op(nor->spi, );
if (ret) {
dev_warn(nor->dev, "Software reset failed: %d\n", ret);
- goto out;
+ return ret;
}
/*
@@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
*/
udelay(SPI_NOR_SRST_SLEEP_LEN);
-out:
- nor->cmd_ext_type = ext;
- return ret;
+ return 0;
}
#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
@@ -3698,6 +3692,44 @@ void spi_nor_set_fixups(struct spi_nor *nor)
#endif
}
+/*
+ * When the flash is handed to us in a stateful mode like 8D-8D-8D, it is
+ * difficult to detect the
Re: [PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
On 10/25/21 21:37, Heinrich Schuchardt wrote: On 10/25/21 21:03, Simon Glass wrote: Hi Heinrich, On Mon, 25 Oct 2021 at 12:41, Heinrich Schuchardt wrote: On 10/25/21 19:29, Simon Glass wrote: Hi Heinrich, On Mon, 25 Oct 2021 at 09:44, Heinrich Schuchardt wrote: On 10/25/21 17:18, Simon Glass wrote: Hi Heinrich, On Mon, 25 Oct 2021 at 02:00, Heinrich Schuchardt wrote: On 10/25/21 09:54, Heinrich Schuchardt wrote: On 10/24/21 21:54, Simon Glass wrote: Hi Heinrich, On Sat, 23 Oct 2021 at 08:06, Heinrich Schuchardt wrote: The block descriptor contains the if_type. There is no need to first look up the uclass for the if_type and then to check the parent device's uclass to know if the device has the correct if_type. Signed-off-by: Heinrich Schuchardt --- drivers/block/blk-uclass.c | 35 +-- 1 file changed, 1 insertion(+), 34 deletions(-) This seems to be heading in the wrong direction though. The IF_TYPE should really go away and be replaced with the UCLASS ID, I think. At present we have lots of calls to blk_create_device_f() which specify the type. I think we should drop the IF_TYPE_.. arg to that function and have it figured out from the uclass, in the interim. But why do we need IF_TYPE now? I admit that this patch is just an intermediate step. We can replace IF_TYPE by ULASS ID once SPL block devices are always using the driver model. Have we reached this point yet? I have not seen drivers/block/blk_legacy.c being deleted. qemu_malta64, qemu_malta64el, qemu_malta, qemu_maltael are examples of defconfigs requiring drivers/block/blk_legacy.c Yes, we seem to have BLK on only for MMC and USB, but malta64 (for example) uses IDE. The problem seems to be HAVE_BLOCK_DEVICE which should not be used. +Tom Rini Should we remove HAVE_BLOCK_DEVICE at this point, or make it depend on BROKEN? Best regards Heinrich Removing if_type_uclass_id[] is anyway on the right path. Are you sure? Instead, could we use the uclass ID in more places? Yes, you want to get rid of if_type. This means the table will become obsolete. Yes. Once the legacy drivers are removed we can replace all occurrences of if_type by uclass_id. That uclass_id we should not take from blk_desc but from udevice. How do we get from a blk_desc to a udevice, though? Could you instead look at moving from using blk_desc to using udevice? If we had that, I think I can see your point with this patch. At present, it looks like a backwards step because you are reducing the usage of the uclass and in fact removing it altogether. Can you see what I am getting at? Let's move towards migration incrementally, not destroy the bridges we have built towards the goal. Once you move from if_type to uclass_id you will simply replace if (desc->if_type != if_type) by if (device_get_uclass_id(dev->uclass->uclass_id) != uclass_id) Except for this line this patch brings you to the final code. device_get_uclass_id() BTW But where does uclass_id come from?! You are removing the function that produces it! In future you will pass uclass_id as parameter instead of if_type because if_type will be replaced by uclass_id! uclass_get_by_name() should be able to find the uclass_id if you pass in an interface name. Best regards Heinrich How about, instead, you update blk_create_devicef() to drop the if_type parameter and just use the device's uclass? That would actually head forwards towards migration, rather than away from it. Regards, Simon
